RE: [rohc] Updating the Formal Notation draft

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

> > > >    The ROHC framework is common to all profiles, and
> > > >    provides generic features such as padding and
> > > >    segmentation of the compressed packets (useful if
> > > >    the link layer can only handle a limited range of
> > > >    packet sizes).
> 
> I noticed that you did not manage to get this paragraph enhanced
> in the submitted draft. That is fine for now, just make sure to
> do it in the next revision, using e.g. material from below...

Oops!  Thanks for reminding me - I've added your text to the
source file so that it will be in the next revision of the draft.

> > > Well, the framework provides the base for all ROHC
> > > compression. It defines the profile concept, which makes
> > > ROHC a general platform for compression schemes. It sets
> > > link layer requirements, and especially negotiation
> > > requirements for all ROHC profiles. It defines a set of
> > > common functions, as segmentation, CID's, and padding.
> > > It also defines common packet formats (IR, IR-DYN,
> > > Feedback, Short-CID expander, etc), and it defines a
> > > generic, profile independent, handling of feedback.
> > > One can also say that it defines the general principles
> > > for doing ROHC compression.
> 
> 
> > > >    a)  Packet formats for compressing and decompressing
> > > >        headers
> > > 
> > > I would say "compressed packet formats"
> > 
> > As I'm not 100% sure what exactly is meant by a "packet
> > format" (compressed or otherwise), it might be useful to
> > capture in more detail what information needs to be defined
> > to get interoperable ROHC profiles:
> 
> I think all existing header compression schemes should serve
> as rather good references for what a compressed header format
> is.

I'm still not 100% clear about this - e.g. does a compressed
header format include a description of which fields update the
context?

> Regarding capturing all that is needed to get interoperable
> ROHC profiles, that is the role of the profile specification 
> and not within scope for the notation.

However, the notation could itself be part of a normative
profile specification.  In this case it's important to
understand exactly what it does and does not define (so we
know how much else needs to be done before we have a complete
ROHC profile).

> > What we're really trying to define is a *function*, whose
> > inputs are the uncompressed header and the context, and
> > whose outputs are the compressed header and a (possibly
> > updated) version of the context:
> > 
> >                           function
> > uncompressed header   <-------------->   compressed header
> > context                                  updated context
> 
> There is an inconsistency here. We have already agreed that
> generating packet formats are not within scope for the notation.

Yes, the notation itself doesn't help us to generate packet
formats (only to capture what's been generated afterwards).

> The notation defines the content of the compressed header "body"
> (using Carsten's terminology)

Unfortunately, I think that there might be a mistake in Carsten's
email which is causing some confusion:

> > I believe Richard's/Mark's idea is that the notation defines
> > all the bits in the compressed packet (its "body"), apart from
> > an initial discriminator.  This discriminator is what differs
> > between EPIC and EPIC-Lite.

This isn't the case - in fact the compressed headers generated by
EPIC and EPIC-lite have completely different bodies as well.

> but to compress the header and get a compressed output, one have
> to generate the compressed header format, and that is another step.