Subject: [rohc] Updating the Formal Notation draft

From: [email-masked] (Dr. Carsten Bormann)
Date: 27 Feb 2003 20:50:54 +0100

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
[email-masked]
https://www1.ietf.org/mailman/listinfo/rohc

---

From: "Lars-Erik Jonsson (EAB)" <[email-masked]>
Date: Fri, 28 Feb 2003 16:14:03 +0100

Richard,

In general, I think we should not make any changes to the
actual notation at this point (although the draft might be
updated for other reasons), as we do not have a common view
either of how to proceed with this, or for example if we 
should do this "Haskell"-step, or something similar using
another functional language. We need to discuss this more,
then we can get a stable ground for the content before we
do the changes.

However, we might want to update it just to change the title,
and maybe some of the "environmental texts". I've provided
some comments on this below.

BR
/L-E

> Section 4.6 on "control fields" is redundant given the
> information contained in <draft-ietf-rohc-tcp-03.txt>.  

Well, it might be worth mentioning that information that
can be noted is either original header fields, or additional
control fields introduced by the compression scheme.

> I propose to leave the ROHC-TCP draft as it is and delete
> Section 4.6 from the formal notation.

Of course, the TCP control field can not be discussed as
part of the general notation.

> Conversely, one issue that the current draft doesn't explain
> very well is the scope of the formal notation - what it does,
> what it doesn't do, how it relates to the ROHC framework and
> to ROHC profiles etc. 

This is indeed very important, and should be done before we
go much further. However, I do not think we do have a common
understanding about that, as it has never been settled.

> I'd like to add a new section to clarify this issue:
> 
> 3.X. Scope of ROHC-FN
> 
>    The following section describes the scope of ROHC-FN, and
>    explains how it relates to the overall ROHC framework and to
>    specific ROHC profiles.
> 
>    The ROHC framework is common to all profiles, and provides
>    generic features such as padding and segmentation of the
>    compressed packets (useful if the link layer can only handle
>    a limited range of packet sizes).

Well, the framework provides the base for all ROHC compression.
It defines the profile concept, which makes ROHC a general platform
for compression schemes. It sets link layer requirements, and 
especially negotiation requirements for all ROHC profiles. It 
defines a set of common functions, as segmentation, CID's, and
padding. It also defines common packet formats (IR, IR-DYN, Feedback,
Short-CID expander, etc), and it defines a generic, profile
independent, handling of feedback. One can also say that it defines
the general principles for doing ROHC compression.

>    A ROHC profile is a description of how to compress a certain
>    protocol stack over a certain type of link.  For example, ROHC
>    profiles are available for RTP/UDP/IP and many other protocol
>    stacks.
> 
>    Each ROHC profile can be further subdivided into the following
>    two components:
> 
>    a)  Packet formats for compressing and decompressing headers

I would say "compressed packet formats"

>    b)  State machine

I am not sure "state machine" captures all the rest that is there,
but I'll think more about this.

>    ROHC-FN is designed to help provide the packet formats for use
>    in new ROHC profiles.

It is a notation form for the information to compress, it is not clear
to me at this point how far you really get with the notation.

> Comments on the above text would be much appreciated!

This is a good start, as I think it is essential that we try to define
what the notation is, what it will be used for, and how it fits in
the "big ROHC picture".