[no subject]

> > In other words, the notation we define (i.e., the library
> > of encoding rules) may favor packet formats that are
> > different from the ones we finally decided to use in 3095.
> > This is of course particularly true if we stick with a
> > single discriminator for the whole packet (I believe that
> > is a mistake and you need some form of cross-product
> > generation of packet formats, which calls for separate
> > discriminators -- something my proposal does not even start
> > to address yet).
> 
> I followed you up to "single discriminator", but there you lost
> me. Can you elaborate on this?

This last point is just talking about a specific feature of
EPIC-lite, which is that it always generates a single
discriminator for the *entire* packet (as opposed to RFC 3095,
where there is usually a discriminator to indicate the overall
packet format, as well as separate discriminators on the front
of each individual compressed protocol header).

The EPIC-lite approach is more efficient than the 3095 approach,
so I don't know why Carsten thinks we need separate discriminators.
However, this is an issue with the EPIC-lite algorithm itself,
and we can always change it to generate separate discriminators
for each protocol if there's a good reason to do so.  The notation
will happily support either approach.

Regards,

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