[no subject]

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.

Note that the "irregular" encoding method outputs bits that can
be considered to be part of the compressed body, whereas the
"self-describing values" encoding method (denoted by "/") outputs
a 1-bit indicator flag that can be considered to be part of the
discriminator.  However, the notation doesn't care which is which,
because all it does is invoke the encoding method and then stick
whatever bits it generates onto the compressed header.

EPIC and EPIC-lite work in the same manner.  If we want to use
EPIC-lite to compress the TCP Source Port instead, then we can
write the following:

tcp_source_port   ::=   static 90% | irregular (16) 10%

When the notation encounters the symbol "|", it invokes EPIC-lite
to generate a suitable discriminator for the compressed header.

> > I'm not sure whether context replication is within the scope
> > of the state machine - perhaps a more general term that
> > captures all of the above would be "context management" issues?
> 
> Might be ok!
> 
> 
> > A description of, say, TCP/IP in the formal notation will
> > give you exactly what is defined in a) above.  You get 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.
> 
> Once again, this does not make sense. The notation itself only
> defines the content of compressed header, not the actual
> formats. You would have to take additional steps before you
> can actually get a compressed header to send. (see Carsten's
> mail).

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.  However, from the notation's perspective there's
no difference between the "discriminator" and the "compressed body".
If we use LSB encoding, say, to generate the compressed body then
a definition of LSB encoding must of course be provided before
we get the compressed headers.  Equally, if we use EPIC-lite to
generate the discriminator then we have to define how EPIC-lite
encoding works.  Once this is done, the notation defines the exact
bits on the wire for each compressed header.

Regards,

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