Subject: RE: [rohc] TCP packet formats

From: "Finking, Robert" <[email-masked]>
Date: Wed, 6 Oct 2004 13:55:58 +0100

You don't wanna do that ;-) You wanna do this...

   optional32 (flag) === {

           uncompressed_format = item; %[ 32 * flag ]

           format_present = item, %[ 32 ]
           {
                 let (flag == 1);

                 item ::= irregular (32);
           };

           format_not_present = item, %[ 0 ]
           {
                 let (flag == 0);

                 item ::= compressed_value (0, 0);
           };
   };

....or even....

   optional32 (flag) ===
   {
           uncompressed_format = item; %[ 32 * flag ]

           compressed_format = item, %[ 32 * flag ]
           {
                 item ::= irregular(32 * flag);
           };
   };

Noting that:
 1. "flag" is a parameter, not a field, so it doesn't have any attributes
(just an intrinsic value),
 2. there is no reason not to use expression syntax within annotations?
 3. there is no reason not to use expression syntax to specify the length of
the irregular encoding.

I'm sure I've missed something here, so let me know =)

Raffles

-----Original Message-----
From: Kristofer Sandlund [mailto:[email-masked]] 
Sent: Wednesday, October 06, 2004 1:13 PM
To: Carsten Bormann
Cc: Eilert Brinkmann; [email-masked]'
Subject: Re: [rohc] TCP packet formats

Carsten,

Thanks for your clarifications.
I'll rewrite the structure using "compressed_value" in the not_present part
so 
that nothing is actually transmitted here. I also change the annotation to
being 
"% 0 or 32" bits in the uncompressed_format

   optional32 (flag) === {

           uncompressed_format = item; % 0 or 32 bits

           format_present = item, %[ 32 ]
           {
                 let (flag:uncomp_value == 1);

                 item ::= irregular (32);
           };

           format_not_present = item, %[ 0 ]
           {
                   let (flag:uncomp_value == 0);

                   item ::= compressed_value (0, 0);
           };
   };

Will this satisfy the parser?

/Kristofer

Carsten Bormann wrote:
> 
> On Oct 06 2004, at 13:50 Uhr, Kristofer Sandlund wrote:
> 
>> Ok, so now I know what is wrong, but I don't know how I'm supposed to 
>> fix this.
>> Mark wrote this structure to indicate that this field will be 
>> compressed either as 0 bits or as 32 bits (a variable-length encoding).
>> How should this be written according to the FN? Should I use static 
>> instead?
> 
> 
> I think optional32 was meant to either include a value or not, based on 
> a discriminator somewhere (which is given as a parameter).
> If the flag is off, both the uncompressed and the compressed side are 
> zero-length.
> If the flag is on, we have an irregular 32-bit field.
> 
> So what is wrong here is the annotation of the uncompressed_format.
> If you look at the places where this is used, there is no formal 
> annotation, instead there is a comment saying
> 
>                                    orig_src,       %  0 or 32 bits
> 
> The same should be true for optional32, i.e.:
> 
>     uncompressed_format = item; %  0 or 32 bits, depending on "flag"
> 
> This, of course, is a rather boring inconsistency, but it at least 
> identified incorrect documentation of the uncompressed_format of 
> optional32.
> 
> Gruesse, Carsten

_______________________________________________
Rohc mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rohc

_______________________________________________
Rohc mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rohc

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 6 Oct 2004 16:03:47 +0200

>  2. there is no reason not to use expression syntax within annotations?

You have just killed any remaining free time that Eilert may have had 
:-)

>  3. there is no reason not to use expression syntax to specify the 

Sounds good, but makes building an implementation so much harder.

> I'm sure I've missed something here, so let me know =)

Well, you created what we call "gratuitous generality".
In your second solution, you lost the property that flag can be either 
0 or 1.
So, for a flag value of 4, you now have a 128 bit field.

I do like your first proposal, but Eilert may not :-)

Gruesse, Carsten