RE: [rohc] Role and approach of the ROHC formal notation

[Carsten Bormann <cabo@tzi.org>]

I liked "rule".  Short, sweet, but does not mean to much (i.e., does not
get in the way of understanding).  (For the same reason, I prefer "label" or
maybe "binding" over "variable".)  It is completely OK to define a *small*
number of "new" terms for *core* concepts of the FN.

Some typical mistakes when choosing terminology:
1) trying to be super-precise and inventing a whole new alphabet soup of
abbreviations which you *have* to memorize before you can understand
anything (unfair example: MPLS).
2) adopting terms from a different domain and using them in an
ever-so-slightly different sense so casual readers knowing the original
domain are misled to no end (unfair example: SIP).

Applied to the question how to call the component statements of the FN:
Example for error number one: FDER.
Example for error number two: production.

Gruesse, Carsten

On Thu, 6 Mar 2003, Price, Richard wrote:

> In this case we may need to pick a more general term to avoid
> confusion with 3095.  What we're looking for is a term to describe
> a general "compression function", which converts uncompressed
> data into compressed data (relative to a context).  It shouldn't
> matter whether the function compresses a single field, a whole
> protocol header, or even the entire packet.  Also, it shouldn't
> matter whether the function outputs compressed bits that are
> considered to lie in the "discriminator" or in the "compressed
> body" part of the header.
>
> In particular, the term must be equally suitable for describing
> all of the following:
>
> * LSB encoding
> * Self-describing variable-length values
> * List encoding
> * EPIC-lite
>
> Any ideas for a good term to use?  Once we have one, I suspect
> that the scope of the formal notation will be *much* easier to
> define.
_______________________________________________
Rohc mailing list
Rohc@ietf.org
https://www1.ietf.org/mailman/listinfo/rohc