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

From: "Price, Richard" <[email-masked]>
Date: Thu, 6 Mar 2003 14:16:50 -0000

> > Is it always the case that an encoding method compresses
> > exactly one field?  What about list encoding from RFC 3095?
> 
> I would not call list compression itself an encoding method in
> the sense of 3095, but others might have a different opinion in
> that regard. List compression is a rather separate part of 3095,
> while the encoding methods I would refer to are those that are
> listed as encoding methods in section 4.5.

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.

Regards,

Richard
_______________________________________________
Rohc mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/rohc

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 6 Mar 2003 15:36:56 +0100 (CET)

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