Subject: Re: [rohc] FN I-D WGLC proposed way forward

From: Joe Touch <[email-masked]>
Date: Fri, 02 Dec 2005 08:56:48 -0800

FWIW, I like the result below...

Joe

Finking, Robert wrote:
> Hi Again,
> 
> OK here's a revised proposal. Please somebody respond to this so that I
> can proceed with this (or some revision of it)! Note that all of the
> below are syntax changes, there is no change proposed to the way the FN
> actually works here.
> 
> One problem with the scheme I originally suggested is what to do about
> control_fields and default_methods. If they become keywords, then you have
> 
>     <keyword> = ...
> 
> Which looks kind of strange (assignment to keyword). "default_methods"
> doesn't have a field order list, so we could just drop the equals sign
> to get
> 
>     default_methods
>     {
>         blah;
>     }
> 
> "control_fields" does have a field order list, but the ordering
> information is irrelevant (in fact the draft states so), so we could get
> rid of it, along with the "=", and use the same syntax as for
> default_methods.
> 
> This approach would also nail down something which we've never
> specified, which is how many control_fields blocks are you allowed -
> this makes sure it's restricted to 1.
> 
> A couple of other things which Joe mentioned
> 1. he didn't like the case sensitivity - I'm happy  to drop the case
> sensitivity if everybody else is.
> 2. how about a convention of capitalising reserved words so that they
> stand out (in line with Joe's original suggestion
> 
>>               i.e., why use co_format as a prefix, rather than
>>               say:
>>
>>                       header === {
>>                               <base format>
>>                               COMPRESSED
>>                               cf1 = ...
>>                               cf2 = ...
>>                       }
> ).
> 
> Since UNCOMP_VALUE is a reserved word, this also solves:
> 
>>19. Try to remove the similarity between the names "uncomp_value" and
>>"uncompressed_value"
> 
> One final issue with this approach - I don't know about you, but having
> keywords with underscores doesn't sit well with me, so I've shortened
> them to single words where possible:
> 
> uncomp_value      -> UVALUE
> uncomp_length     -> ULENGTH
> uncomp_hdr_start  -> USTART
> comp_value        -> CVALUE
> comp_length       -> CLENGTH
> comp_hdr_start    -> CSTART
> 
> Taking all the above into account, we'd have FN that looks like this
> (comments please):
> 
> 
>    eg_header  ===
>    {
>      UNCOMPRESSED uc = version_no,    %[ 2 ]
>                        type,          %[ 2 ]
>                        flow_id,       %[ 4 ]
>                        sequence_no,   %[ 4 ]
>                        abc_flag_bits, %[ 3 ]
>                        reserved_flag; %[ 1 ]
> 
>      CONTROL
>      {
>        % need modulo maths to calculate scaling correctly,
>        % due to 4 bit wrap around
>        BIND(scaled_seq_no:UVALUE
>               == ((MOD(15 - sequence_no:UVALUE, 3) * 16
>                    + sequence_no:UVALUE) / 3));
>      };
> 
>      DEFAULT
>      {
>        version_no          ::=   uncompressed_value(2,1);
>        type                ::=   irregular(2);
>        flow_id             ::=   static;
>        reserved_flag       ::=   uncompressed_value(1,0);
>        scaled_seq_no       ::=   lsb(1,-1);
>      };
> 
>      COMPRESSED irregular  =   discriminator,     %[ 2 ]
>                                type,              %[ 2 ]
>                                flow_id,           %[ 4 ]
>                                scaled_seq_no,     %[ 4 ]
>                                abc_flag_bits      %[ 3 ]
>      {
>        discriminator       ::=   '00';
>        flow_id             ::=   irregular(4);  % overrides default
>        scaled_seq_no       ::=   irregular(4);  % overrides default
>        abc_flag_bits       ::=   irregular(3);
>      };
> 
>      COMPRESSED flags_set  =   discriminator,     %[ 2 ]
>                                type,              %[ 2 ]
>                                scaled_seq_no      %[ 1 ]
>      {
>        discriminator       ::=   '01';
>        abc_flag_bits       ::=   uncompressed_value(3,7);
>      };
> 
>      COMPRESSED flags_static  =   discriminator,     %[ 1 ]
>                                   type,              %[ 2 ]
>                                   scaled_seq_no      %[ 1 ]
>      {
>        discriminator       ::=   '1';
>        abc_flag_bits       ::=   static;
>      };
>    };
> 
> Regards
> 
> Raffles
> 
> -----Original Message-----
> From: Finking, Robert
> Sent: Thursday, November 17, 2005 11:06 AM
> To: Finking, Robert; [email-masked]
> Cc: Joe Touch; West, Mark
> Subject: RE: [rohc] FN I-D WGLC proposed way forward
> 
> 
> Hi Everybody,
> 
> I've had a thought that would allow us to accommodate another of Joe's
> requests: to separate out some keywords from uc_format_blah and
> co_format_blah. Joes original suggestion was to have dedicated sections
> something like this:
> 
> uncompressed:
>      blah = ...
> 
> compressed:
>      blah = ...
> 
> Instead of marking out sections like this, we could make a much simpler
> change and have "compressed" and "uncompressed" keywords for each format:
> 
>    uncompressed blah = ...
> 
>    compressed   blah = ...
> 
> This would be easily achievable by doing a search and replace, and would
> still allow us to use Carsten/Eilert's checking tool provided there was
> a simple pre-processor to convert the input back to the original form,
> which the tool understands.
> 
> What do you think?
> 
> I'd be happy to do the pre-processor.
> 
> Raffles
> 
> PS if you're looking for a precedent, the obvious analogy here is the
> difference between the way Java/C# and C++ specify the privacy of class
> members.
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Finking, Robert
> Sent: Friday, October 21, 2005 12:57 PM
> To: [email-masked]
> Cc: Joe Touch
> Subject: [rohc] FN I-D WGLC proposed way forward
> 
> 
> Hi Guys,
> Based on the discussions we had with Joe on the list, here's what the
> authors are proposing for updates to the FN draft. The main theme is to
> reassess the draft from a point of view of readability of somebody like
> Joe and make as many improvements to the accessibility of the draft as
> possible. In particular:
> 1. Spell out the importance of understanding what fields, values and
> encoding methods are, and the relationship between them. Make their role
> clear and explicit at each point where they're used, instead of assuming
> that the reader has fully understood their relationship already.
> 2. Add a note that the zero IP-ID is "observed" behavior, and that for
> header compression the choice of the behavior to assume is entirely up
> to the profile designer - i.e. it can handle non standard behaviour...
> but make it clear that Zero IP-IDs are actually illegal from the IETF's
> point of view.
> 3. Put into relation the FN and the principles used for achieving
> robustness against losses and reordering, mention reordering as a
> possibility in the draft (currently no mention of reordering at all).
> But make it clear that the FN only defines packet formats, i.e. bits on
> the wire, and anything else related to robustness and tolerance to
> reordering is outside the scope of FN.
> 4. We need to include something about the comments which indicate the
> field widths in bits. We clearly don’t want another huge debate about
> this, but Joe is right that these are a very important part of the
> notation, in that they tell you what the field widths are - without them
> it's non-trivial to gather this important information. This means either
> making the current style of comments a part of the FN, or else reverting
> to them not being comments - either way we do need to describe them in
> the draft. If we take the "not comments" approach, my suggestion is that
> a search and replace (or failing that a quick python script) can
> auto-convert them to the new syntax. A key issue here is that they must
> be annotations, not mandatory since some fields have undefined length
> and we don't have the resources to handle that right now! If we can
> produce a FN-to-box Notation compiler though this problem may go away,
> but we can't count on that right now!
> 5. Consider changing the "::=" operator, due to it's use in BNF and the
> confusion that can cause. Again, whatever replacement we come up with
> (e.g "encoded") can be fixed in the current drafts by use of global
> search and replace.
> 6. It would be great if Carsten/Eilert could update the tool to deal
> with any syntax changes and/or to meet Joe's request that it "would be
> nice if the current notation could be 'compiled' into the layout
> diagrams" (i.e. ASCII box notation).
> 7. Need to be explicit about the 1:1 mapping between compressed and
> uncompressed messages and describe that defining the handling of blanks
> to produce a many:1 mapping is beyond the scope of the FN.
> 8. In the body of the draft in the let statement section, need to state
> that it is possible to make any field conditional.
> 9. Need to address whether the ROHC group is happy to have a name change
> for things like "static" from their historical names to more accurate,
> easy to read ones, if so need to gather suggestions for the
> counter-intuitive ones - suggestions please (e.g. "unchanged" instead of
> "static").
> 10. Clarify "7-bit ASCII", indicate whether 'alphabetic' is case
> sensitive or not.
> 11. Add explicit text about language not being like C and the
> implications of that
> 12. Make it explicit in the draft that uncompressed field lengths are
> almost exclusively constrained by the encoding method used to encode
> them. The only other way is to specify the length using a let statement.
> 13. Consider changing "let" to "bind". The problem with "let" is that
> the reader thinks they know what it means, when in reality they don't.
> They certainly don't expect that it could mean "if" sometimes.
> 14. Clarify in A.5 that the example protocol contains a version number
> 15. Make it illegal to specify two ambiguous packet formats.
> 16. revisit all examples to see if they can be made clearer. In
> particular do we really need an example to show the exception to the
> rule, rather than to show the norm?
> 17. Clarify 4.9.4.2
> 18. Change "log2" to "bitsize"
> 19. Try to remove the similarity between the names "uncomp_value" and
> "uncompressed_value"
> 20. Give the author/reader the option of specifying the polynomial as
> "x^7+x^4+x^3" (but don't use this in the TCP I-D) - Joe can you clarify
> this, we authors are struggling to see why the above is any different
> from setting bits 7, 4 and 3?
> Thanks again to Joe for taking the time to review the draft and for the
> many interesting points he raised and also to the authors for helping to
> arrive at the above list.
> Cheers
> Raffles
> Robert Finking (01794 833189)
> Roke Manor Research (http://www.roke.co.uk)
> Romsey, Hampshire SO51 0ZN
> 

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

---

From: Joe Touch <[email-masked]>
Date: Fri, 02 Dec 2005 08:59:02 -0800

FWIW, the reason I'm not thrilled about case sensitivity is that I don't
see it doing much except adding confusion. In particular, the difference
between cap'd and un'cap'd versions of identifiers is hard for humans to
keep track of, and allows (in a bad way) reuse of reserved words.

I'd argue at the least that all capitalizations of reserved words are
	a) equivalent
	b) reserved

Joe

Finking, Robert wrote:
> Hi,
> 
> Yes that makes sense, and since we really can't afford to debate these
> things right now, sure let's go with that. Over the weekend, it occurred
> to me that we have a problemette with the new syntax. Control fields now
> look like this:
> 
>    CONTROL
>    {
>       field_floo ::= encoding(params);
>       etc.
>    };
> 
> However, not all control field sections specify encoding methods for all
> their fields, rather they leave the definition of the encoding to the
> compressed packet formats. To get round this, I propose simply that we
> allow their field encodings to remain unspecified, like this:
> 
>    CONTROL
>    {
>       field_floo ::= encoding(params);
>       field_blah;
>       etc.
>    };
> 
> Obviously this isn't a simple search and replace job for you TCP guys,
> so I'm looking at writing a tool to transform the FN from one form to
> the other. I'll let you know when it's available =)
> 
> I think it's good for us to be doing these sorts of things if you can
> stomach it, because on reflection most of Joe's issues were with the FN
> itself rather than the I-D. I think it's worth doing these sorts of
> changes where we can.
> 
> Let me know your thoughts.
> 
> Cheers
> 
> Raffles
> 
>> What I'd like to see:
>> --------
>> - Case-sensitive
>> - Legal to use uppercase for anything
>> - All reserved keywords defined in FN-draft are (MUST BE) upper-case
>> - Recommend that local defined names start with lower-case,
>>   but that I can do foo_DYNAMIC as a convention locally in ROHC-TCP
>>
>> Does this make any sense?

---

From: "Finking, Robert" <[email-masked]>
Date: Mon, 5 Dec 2005 09:00:26 -0000

Joe,

Many thanks for your responses - much appreciated. Given Kris' wish to
keep case sensitivity, I think

Keeping all capitalisations of reserved words as reserved is an
excellent compromise - I'll work on that basis. This approach seems to
meet everybody's requirements (including mine) so I'll take that as
consensus unless I here objections.

Regards

Raffles