RE: [rohc] Formal notation - "Encoding methods"

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

> > 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.
> 
> Here I would strongly disagree. I rather think we should have a few
> different terms for the different kind of "encoding methods", since
> I think that would heavily simplify understanding, and make it easier
> to separate the various pieces.

However, a single term is still needed for the concept of an "encoding
method" as a whole.  Once this term is defined, nothing prevents us
from having more specific terms for different kinds of encoding
methods.  In fact we already do this - e.g. in the notation draft we
have the "list encoding methods", the "control field encoding methods"
etc.

> > In particular, the term must be equally suitable for describing
> > all of the following:
> > 
> > * LSB encoding
> > * Self-describing variable-length values
> 
> I agree that these two should fall into the same category.
> 
> > * List encoding
> 
> List compression, as defined in 3095, is a rather different compression
> method, so I am not sure this falls into the same group. But this is 
> absolutely an open question.

In the notation draft we have a specific section devoted to "list
encoding methods" which handle lists of items.  However, the notation
language itself doesn't treat these encoding methods differently
from any others.

> > * EPIC-lite
> 
> Methods to use for generating the actual compressed header formats,
> e.g. EPIC-lite, are rather different.

However, from the point of view of the notation language, is there
any reason to treat EPIC-lite differently from the other encoding
methods?

> Which one to use is a profile specification issue, and I am rather
> skeptical to have such methods defined in the general formal notation,
> and a question would be which to document there. I rather think we
> should include THE method used for the profile in the profile
> specification, and the method might be NULL, for cases where we do
> the compressed formats "by hand".

I disagree with the above.  The notation language itself shouldn't
make a distinction between EPIC-lite and any other encoding method.
If we want to use EPIC-lite to design our compressed header formats
then it should be invoked within a ROHC-FN description, in the same
way as LSB encoding, list encoding and so on are invoked when we want
to use these.

This approach is much simpler and more flexible than treating EPIC-
lite separately from the other encoding methods.  For example, as
Carsten mentioned it might be useful to apply EPIC-lite several
times to get different discriminator bits for individual protocols in
the protocol stack.  Or perhaps we might want to encode part of the
header using EPIC-lite and the remainder by hand.  Both of these
are possible if EPIC-lite can be invoked in the same way as the
other encoding methods.

> In any case, these methods should fall into a separate category.