Subject: ROHC-FN mod/comment style [was RE: [rohc] FN I-D WGLC proposed way forward]

From: "Finking, Robert" <[email-masked]>
Date: Wed, 30 Nov 2005 10:10:10 -0000

Hi All,
 
Whilst looking at syntax changes, one thing that's occured to me is that
the mod() operator is somewhat unusual in that it looks like an encoding
method (i.e. an identifier followed by arguments inside brackets) the
only reason for this is that we used % as the comment character, which
was inherited from the years old Prolog implementation. Can I suggest
that we use % for modulo as is conventional and use // for comments?
 
The only other operator that falls into this category (that I can think
of) is "log2", which was proposed to become "numbits" or some similar.
We may want to change this to an infix operator also, using #, which is
often used to mean "number of". I'm not so sure about this one, but it
seems to fit.
 
If you have strong feelings about either of these two suggstions, please
shout.
 
Thanks
 
Raffles
 
-----Original Message-----
From: Finking, Robert 
Sent: 17 November 2005 11:06
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 analog 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-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