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

["Finking, Robert" <[e-mail]>]

Hi Kris,

Many thanks for the rapid response - much appreciated =) On the case
issue, I don't quite understand. The suggestion was to allow any
capitalisation anywhere in the FN. This would allow you to do what you
suggested below.

At present, the _DYNAMIC suffix that you want to use would be illegal.
Currently capitals are for constants, lower case for everything else
(actually I don't think the current draft spells it out quite like that,
but that's what's intended).
What I'm proposing is that we lift that restriction and make the FN
insensitive to capitalisation. However I'm also suggesting that we adopt
a *convention* (non-normative) which makes keywords all capitals:

>   O  "BIND", "THIS"
>   O  "MOD", "LOG2"
>   O  "DEFAULT", "CONTROL"
>   O  "USTART", "ULENGTH", "UVALUE"
>   O  "CSTART", "CLENGTH", "CVALUE"

This means you *could* write FN with what ever capitalisation you wanted
to, e.g. like this, but it wouldn't be conventional:

   eG_hEADeR  ===
   {
     UncOmpResSed uC = VeRSiON_NO,    %[ 2 ]
                       tYpE,          %[ 2 ]
        :
     cOMpREsSEd iRreGular  =   dISCriminaTor,     %[ 2 ]
                               TypE,              %[ 2 ]

etc. Note that "type" has different capitalisations in the compressed
and uncompressed formats, but both still refer to the same field.

Hopefully this gives you the freedom you want whilst still providing an
easily readable capitalisation convention.

Does that make sense? Do we have a vote in favour?

Regards

Raffles



> -----Original Message-----
> From: Kristofer Sandlund (LU/EAB) 
> [mailto:[e-mail]] 
> Sent: Thursday, November 24, 2005 12:23 PM
> To: Finking, Robert; [e-mail]; Ghyslain Pelletier (LU/EAB)
> Cc: West, Mark; Ford, Alan; Joe Touch
> Subject: RE: [rohc] FN I-D WGLC proposed way forward
> 
> 
> Hi Raffles,
> 
> I think the suggested changes are good for improving the 
> clarity of the FN, so I'm all for it (even if it means I'll 
> have to M-x query-replace the TCP draft).
> 
> Regarding case sensitivity, I guess it could be ok with 
> disallowing upper-case letters in "non-reserved" names, but 
> on the other hand, This is a feature that I just realized 
> that I want to use in ROHC-TCP for names that are not 
> reserved at FN level, but would be reserved within the 
> profile (e.g. the _dynamic suffix, I'd like to change to 
> _DYNAMIC within the TCP profile, but I don't want to 
> reserve that name in the notation itself, since it is a local thing).
> 
> So, I think I have to case a weak vote for keeping 
> case-sensitivity, but otherwise I fully support your 
> proposal, which is clearly an improvement over the ambiguous 
> naming schemes we have now.
> 
> BR,
> 	Kristofer
> 
> [e-mail] <mailto:[e-mail]> 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; [e-mail]
> > 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: [e-mail] [mailto:[e-mail]
> > <mailto:[e-mail]> ] On Behalf Of Finking, Robert
> > Sent: Friday, October 21, 2005 12:57 PM
> > To: [e-mail]
> > 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 <http://www.roke.co.uk> )
> > Romsey, Hampshire SO51 0ZN
> 
> 

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