RE: [rohc] Updating the Formal Notation draft

["Price, Richard" <richard.price@roke.co.uk>]

> Richard,
> 
> > >     3. The "labels" should be renamed "temporary variables" to
> > >        make it clearer what they actually do!
> > > 
> > > Hmm, this creates the impression the notation has imperative
> > > semantics.  I thought we were trying to avoid this.  Bindings?
> > 
> > The term "labels" (or "bindings") implies that each label name refers
> > to a fixed value for each header.  This isn't currently the case -
> > labels can change their value as the header is parsed, so the term
> > "variable" is more appropriate.
> > 
> > Obviously it would be nicer to avoid having variables in a notational
> > language - it's an open issue whether we can do this or not.
> 
> What do you mean with "header is parsed"? We are talking about a 
> "language" to describe how header fields are to be compressed (not
> field data from a specific packet header), and to me "parsing" sounds
> like something you do with an actual packet header.

Hi,

Yes, I meant "parsing" as in compressing actual packet headers.  The
temporary variables are used by the notation to store certain fields
from a header - I've had a go at explaining why this is useful below:

It's often the case that two fields in a header have related behaviour
(e.g. RTP Sequence Number and Timestamp).  Obviously these dependencies
need to be taken into account when encoding the fields - this means that
the encoding method for the RTP Timestamp must have the RTP Sequence
Number available before it can work out the compressed version of the
Timestamp.

ROHC-FN captures these field dependencies using "temporary variables".
In a description of RTP, the encoding method for the RTP Sequence
Number would create a new temporary variable called, say, "RTP_Seq"
for storing the RTP Sequence Number.  The encoding method for the RTP
Timestamp would retrieve the Sequence Number from the variable "RTP_Seq"
and use it when compressing the Timestamp.

When parsing a specific RTP header, the temporary variable "RTP_Seq"
would contain the specific value of the RTP Sequence Number for that
particular header.  If we want to parse two different RTP headers then
the temporary variable will generally take a different value in each
case - hence the term "variable" is appropriate.

> I have to re-read the draft, but I will wait for the updated version.

I've just submitted the updated version of the draft.  It might be
worth checking out the worked example for IPv6, which makes use of two
temporary variables called "Next_Header" and "Remaining_Data".

Regards,

Richard
_______________________________________________
Rohc mailing list
Rohc@ietf.org
https://www1.ietf.org/mailman/listinfo/rohc