[rohc] Updating the Formal Notation draft

[cabo@Informatik.Uni-Bremen.DE (Dr. Carsten Bormann)]

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?

    2. The "rules" should be called "encoding methods" to bring the 
       terminology in line with RFC 3095.

d/c (don't care).

    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?

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

    Parsing the notation using Haskell:

    A drawback with the current notation draft is that even though
    it's based on a well-known language (namely BNF from RFC 2234),
    some proprietary extensions are needed to make the notation
    powerful enough to describe the headers we're interested in.
    This means that off-the-shelf BNF parsers like yacc can't handle
    the notation in its current form.

    A simpler approach would be to base the notation on a more
    powerful language, which already offers all of the features we
    need as standard.  A number of sufficiently powerful languages
    are already available (Prolog, Haskell, Mercury etc.) - we propose
    to use Haskell because its syntax is closest to the notation
    currently documented in <draft-ietf-rohc-formal-notation-00.txt>.

This is a quite weak argument for the choice of notational basis.
Obviously, we need to have a better one.  (I'm making this argument
not only because I did my first prototype in Prolog...)

    Only a handful of changes are needed to convert the notation
    into executable Haskell code:

    1. We should create new encoding methods using the symbol "="
       rather than "::=".

d/c (in Prolog, it's something different again).

    2. In a list expression (e.g. [2 * j for j in 0..n]) the reserved
       words "for" and "in" should be replaced by the symbols "|"
       and "<-".

The base language wins.

    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.

    3. We should make the notation more readable by removing the
       unnecessary parentheses and commas, and just delimiting the
       parameters of an encoding method using whitespace instead.

Readability is in the eye of the beholder...
In contrast to the lambda crowd, I prefer the assignment of roles to
things to be clearly visible.
In the end, of course, the base language we choose wins...

    4. Lists of elements should be clearly marked using a well-known
       symbol (e.g. square braces).

    5. Currently the lower bound for the number of elements in a
       list is inclusive but the upper bound is exclusive.  This is
       confusing - for consistency, both bounds should be inclusive.

    6. The "floor" function should be renamed "div" (because "floor"
       is a well-known term that means something completely different).

    7. The "Null" keyword should be renamed "Nil" (because "Null" is
       a well-known term that means something completely different).

    8. When we need the integer value of a field, we currently just
       quote the field name and assume that readers know that we want
       the integer value rather than the bits.  This might get
       confusing, so for clarity we propose to explicitly indicate
       whenever we need the integer value of a field (e.g. by writing
       "val" before the field name).

This is obviously required.

    9. In the current notation, when we define new parameters we
       need to explicitly state the parameter type (integer, text
       string etc.).  It isn't actually necessary to do this, because
       a compiler can infer the parameter types just by looking at the
       expressions in which the parameters are used.  For example, if
       we encounter the expression "m + n" then we know that m and n
       must both be integers.  So for simplicity, we should make
       parameter types optional (or not bother with them at all).

Stating the types may increase understandability.
Again, of course, the base language wins.

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