RE: [rohc] Updating the Formal Notation draft

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

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

Both yes and no. The format is the "bits on the wire", but how
to interpret these might of course depend on the state of the
context(s). As an example, in the RTP profile, some formats are
interpreted different depending on the current mode of operation.

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

Well, the notation is just a notation, right? A profile 
specification might define new "encoding rules" in addition to
more general ones, but the notation document we are now working
with should be generally applicable. 


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

Afterwards? Rather what should be used as input to the actual 
format generation, I think.

 
> I'll try to explain this using an example.  Suppose we define how
> to compress the TCP Source Port using the formal notation:
> 
> tcp_source_port   ::=   static / irregular (16)
> 
> On its own this description means nothing.  However, once we've
> defined how the three encoding methods (static, irregular and "/")
> actually work, then the notation specifies the exact bits on the
> wire that need to be sent to compress the TCP Source Port.

Yes, but the "/" encoding method is rather different from the
other two. static and irregular are only about the content to be
compressed, while "/" would also define how to combine things
together, i.e. create discriminators.


> The only additional step needed to get "bits on the wire" is
> to define all of the basic encoding methods that the notation
> draft invokes. 

Let me know if you have a different view, but the notation draft 
defines a notation "language", used to notate things. An
implementation of a notated profile might invoke encoding methods
described by the notation draft, but not the opposite.

/L-E

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