[rohc] RE: Default decompression algorithms

["Price, Richard" <[e-mail]>]

> > So for the wireless environment 3GPP will be
> > able to choose their own list of mandatory and optional algorithms.
> 
> Yes, they use to do it that way, but why should WE make any algorithm
> mandatory at the decompressor.

We shouldn't - in my opinion it would be a mistake for the ROHC Working
Group to do more than standardise the algorithms themselves. The final
decision on whether algorithms are mandatory or optional should be made
in the context of a particular application.

The ability to make certain algorithms mandatory is available "for free"
as part of the secure state reference mechanism, so no additional
standardisation is required on our part.

> As you say yourself, the decompressor can announce what resources it has,
> and the compressor decides what to use based on that, but the decompressor
> does not have to announce any available algorithms. If it does not, the
> compressor just do not have any other choice than to download its own
> algorithm.

We should leave the decision as to whether or not mandatory algorithms are
required to particular applications (e.g. 3GPP can decide this for SIP in
the mobile environment).

> > I would be very happy to include both approaches in the SigComp
> > solution and leave the decision on which to use to the compressor.
> 
> Simple and well defined solutions with few options are usually
> preferable when making standards, at least in the IETF. 

With the UDVM approach the SigComp solution can certainly be simple and
well-defined, but few options is one thing that we won't have! A compressor
with the ability to download bytecode already has complete flexibility to
choose any algorithm it likes; in my opinion this is a strength of SigComp
rather than a weakness.

The ability to announce a list of supported algorithms at the decompressor
does not introduce more flexibility but instead just saves downloading the
chosen algorithm when it is already available at the decompressor.

Regards,

Richard