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

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

> > 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
Rohc@ietf.org
https://www1.ietf.org/mailman/listinfo/rohc