RE: [rohc] Formal notation, combined thread

["Lars-Erik Jonsson (EAB)" <Lars-Erik.Jonsson@epl.ericsson.se>]

Richard,

> > > RP: The notation language itself shouldn't make a distinction
> > > between EPIC-lite and any other encoding method.
> > 
> > As I have said above, I think it is important to make a clear
> > distinction between these, as they are so different. That is also
> > what we said last year, when we talked about field encoding vs.
> > compressed header encoding.
> 
> As above, I can't see any reason to think of the
> discriminator encodings as "special", or to treat them
> differently in some way.  The distinction between the
> various types of encoding method that we made last year
> was only intended to clarify how the notation handles all
> of the different compression techniques needed by ROHC
> profiles.  From a technical perspective the notation has
> never given special treatment to the discriminator
> encodings, and I think that it would be confusing and
> unnecessarily restrictive to do so.

We obviously disagree here. I still believe it is important to
make this distinction. All field encodings that can send 
compressed data in more than one way calls a discriminator
function, but any function could be used, i.e. the notation
for a profile can be written independent of the actual 
discriminator function that is later chosen. 
 

> > > RP: If the compressed header formats are created manually then the
> > > ROHC-FN description captures the exact hand-crafted packet
> > > formats - not just the content of the compressed headers, but the
> > > hand-crafted "discriminator" bits as well.
> > 
> > OK, but then we would not even need the notation as a tool, if
> > the actual formats (in written form) would just mean the same.
> 
> The notation provides a really useful benefit even when
> describing hand-crafted compressed headers, which is the
> extra implementation option of writing a "notation compiler"
> to automatically convert a notated description of the
> packet formats into running code.

First of all, I think it would be useful to have the notation to
describe what to put in hand made formats, i.e. as a tool in such
a process. Further, I think we would make a mistake if we tried to
make the notation capable of describing hand made formats, as that
would make the notation unnecessary complex, while the reason does
not really make sense in my mind. 
 
 
> > > RP: The big advantage of making the adjustments within ROHC-FN
> > > is that the description of the compressed packet formats remain
> > > machine-readable
> > 
> > We are defining standards, which should be human-readable. There 
> > are probably disagreements in this regard, but personally I think
> > human-readability is more important than machine-readability.
> 
> I agree that human-readability is at least as
> important as machine-readability.  However, in
> my opinion a notated set of packet formats is
> actually rather more human-readable than a set
> of packet formats drawn out pictorially.  

Well, protocol headers are usually drawn out pictorially, so that is
what protocol folks are more used to. 


> > 7. EPIC-Lite 
> >  
> > The EPIC and EPIC-Lite terms have been overloaded several times by
> > now, and they actually do not say much about what they really do.
> > If we want to use the "EPIC-Lite" method for "discriminator
> > encoding" and potentially define it in the general notation
> > document, we should come up with a name that tells us what it does. 
> > 
> > Any ideas?
> 
> We originally used the term "EPIC-lite" to mean
> the entire notation-based solution, including
> the notation itself and the complete library of
> encoding methods.  The algorithm for generating
> the discriminator bits is actually nothing more than
> ordinary Huffman encoding, so perhaps we could
> just call it that instead?

Ok, "Ordinary Huffman" (OH), and "Hierarchical Huffman" (HH) then?

/L-E
_______________________________________________
Rohc mailing list
Rohc@ietf.org
https://www1.ietf.org/mailman/listinfo/rohc