RE: [rohc] Updating the Formal Notation draft

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

Hi Carsten,

Many thanks for these comments.  I've added some further comments
on the proposed changes that I'd like to make in the next version
of the notation draft.  The remaining issues just relate to the
syntax of the notation - we can finalise these later on (e.g. after
we've chosen between Haskell/Prolog etc.).

Regards,

Richard

> -----Original Message-----
> From: cabo@Informatik.Uni-Bremen.DE
> [mailto:cabo@Informatik.Uni-Bremen.DE]
> Sent: Thursday, February 27, 2003 7:51 PM
> To: rohc@ietf.org
> Subject: [rohc] Updating the Formal Notation draft
> 
> 
> ROHCers,
> 
> some comments (WG chair hat off) on
> http://sigcomp.srmr.co.uk/~rjp/RohcFn_Proposed_Changes.txt below.
> 
> Gruesse, Carsten
> 
>     Based on our implementation experience we'd like to propose a
>     few changes to the current formal notation draft (see
>     <draft-ietf-rohc-formal-notation-00.txt>):
> 
>     Terminology changes:
> 
>     The following changes have no technical effect on the notation,
>     but will hopefully make the draft easier to understand:
> 
>     1. We should give the notation a better name, e.g. ROHC-FN
>        (Formal Notation for Robust Header Compression).
> 
> If, as you explain in a later message, it is just about packet
> formats, it probably should be named ROHC-FNPF or some such?

It might be better to keep the name of the notation more generic, at
least for the time being.  As Lars-Erik pointed out the final scope
of the notation may change...

>     2. The "rules" should be called "encoding methods" to bring the 
>        terminology in line with RFC 3095.
> 
> d/c (don't care).

Ok, I'll use the term "encoding methods" - should make the draft a
bit clearer.

>     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.

>     4. The names of encoding methods and variables should be
>        cleanly separated, e.g. by using lowercase for the names
>        of encoding methods and uppercase for variable names.
> 
> This might conflict with the choice of Haskell (uppercase is reserved
> for specific things in that language).  (It also would conflict with
> Prolog.)

That's ok - it doesn't matter which is uppercase and which is
lowercase, so long as they are cleanly separated.  I'll stick with
what we've currently got (we can always change it later if it
conflicts with our choice of well-known language).

>     Miscellaneous changes:
> 
>     The following changes aren't required to make the notation
>     Haskell-compatible, but we think that they're a good idea anyway:
> 
>     1. We should add "Self-describing variable-length values" from
>        Section 4.5.6 of RFC 3095 to the library of encoding methods.
> 
> Sure. The Library will grow with our use of the notation.
> 
>     2. A function for calculating an n-bit CRC should be added to
>        the maths library.
> 
> Sure.
_______________________________________________
Rohc mailing list
Rohc@ietf.org
https://www1.ietf.org/mailman/listinfo/rohc