Subject: [rohc] Formal notation - "Encoding methods" (Was: Role and approach of t he ROHC formal notation)

From: "Lars-Erik Jonsson (EAB)" <[email-masked]>
Date: Thu, 6 Mar 2003 15:37:14 +0100

> 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.

> 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.

> * EPIC-lite

Methods to use for generating the actual compressed header formats,
e.g. EPIC-lite, are rather different. 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".

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

> 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.

"Encoding method" is ok for the formal notation, I think. But that
assumes the formal notation would not include everything.

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