Subject: RE: [rohc] Re: FW: [tcpm] WG last-call of TCP header compression

From: "Finking, Robert" <[email-masked]>
Date: Thu, 29 Sep 2005 09:22:03 +0100

Joe,

Apologies. There's a recurring theme in your replies, which I must admit
I've dodged so far, but which I can see we're going to have to face up
to:

> 
> What does "it _works_" mean if the notation lacks something
> so fundamental that there are pseudo normative ways of 
> commenting the notation that end up being used throughout?
> 

You are of course referring to the formatted end of line comments, which
indicate how wide a field is. An example for the sake of those who
haven't followed this:

  uc_format   =   discriminator,    %[  8 ]
                  tcp_seq_number,   %[ 32 ]
                  tcp_flags_ecn,    %[  2 ]

The values in square brackets indicate the field width in bits. Here's
the history behind them. Due to the ease with which the information in
box notation is read, and the relative difficulty with which that same
information can be determined from looking at FN, my predecessor
(Richard Price) added an indication of field widths, which would
indicate their width. They looked like this:

  uc_format   =   discriminator  : 8 bits,
                  tcp_seq_number : 32 bits, 
                  tcp_flags_ecn  : 2 bits,

Note the they are not comments (see comma placing) but are in fact part
of the notation. When it came to reviewing the new notation, for reasons
which were argued long and hard, but which now escape me (you know how
the longest arguments always stem from the most trivial of causes), we
downgraded their importance, first to be annotations, and then to
ordinary comments (albeit with special formatting to allow tool
support). The fact is that the checking tool which Carsten and Eilert
produced still reads these formatted comments to check that they agree
with the normative part of the profile (and therefore that they don't
mislead the user due to typing errors etc.). I think perhaps the reason
we made them non-normative was to avoid putting the onus of checking
them onto all developers.

One thing to be absolutely clear on though: they are entirely redundant
from a formal point of view. They add zero information to an FN profile.
Their sole purpose is to improve readability. With them, you get all the
information you get in an ASCII box diagram, leaving the rest of the FN
to specify all the things it was meant to, which neither the formatted
comments, nor the box notation specify.

Personally, I'd be perfectly happy to make the bit field lengths
normative once more, but I'm not sure everybody will agree, and since
their point is really to aid readability, it makes little difference
whether they are comments or normative. It's just that the latter forces
the implementer to do more work than if they are simply comments.
However, if we are going to follow your excellent suggestion of
disallowing ambiguous packet formats (which I'm still not sure is
possible to compute in the general case) then we're going to be putting
this kind of thing on the implementer anyway.

I think the real issue here though is that because they're currently
comments only, there is no explanation of them in the draft, and no
requirement for users of the notation to employ them. Since these fields
are so key to the notation being more readable to humans, I am thinking
we should maybe restore them to being annotations at least, so that they
can be documented in the FN draft.

Long winded I know, but I thought you deserved more of an explanation. I
hope this helps.

Regards

Raffles

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

---

From: Joe Touch <[email-masked]>
Date: Thu, 29 Sep 2005 03:54:12 -0700

Note at end....

> Long winded I know, but I thought you deserved more of an explanation. I

It does. IMO they help - precisely because they put all the information
that's scattered elsewhere in a single place, a place that protocol
designers are used to relying upon. It may ensure that things 'fit'
(redundency).

There is a case that doesn't seem as much 'redundent' as 'constrained' -
i.e., you could define 'underfilled' fields (spec'd as N bits, but later
filled with M [where M<N] bits of data) to be lsb-shifted and
zero-filled in the high bits.

Joe