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

From: "Finking, Robert" <[email-masked]>
Date: Fri, 21 Oct 2005 12:56:40 +0100

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-boxNotation 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
[email-masked]
https://www1.ietf.org/mailman/listinfo/rohc

---

From: Joe Touch <[email-masked]>
Date: Fri, 21 Oct 2005 11:07:30 -0700

Hi, all,

Two notes below; thanks for compiling my notes down to a much simpler
list ;-)

Joe

Finking, Robert wrote:
> 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:
> 

As per my other note, IMO it's inappropriate to discuss 'observed'
behavior that violates spec except to address whether to endorse ('spec
change') or correct it ('known problems'). For this doc, it'd be more
useful to avoid that altogether, or note it as an example of
"nonstandard behavior that can adversely affect compression". I don't
think it's appropriate to support it as a compression mode; it should be
treated, at best, as an unpredictable if you allow the rest of
compression to continue once it is noticed.

I don't see the need for another example of compressing zeroes, as noted
in my other email.

> field widths in bits. We clearly don?t want another huge debate about
> uncompressed messages and describe that defining the handling
> of blanks to produce a many:1 mapping is beyond the scope of the FN.
> 

It's not different, but it's a lot easier to read than 0x10011000.

> Roke Manor Research (http://www.roke.co.uk <http://www.roke.co.uk/>)