RE: SigComp Requirements (was Re: [rohc] RE: Default decompressio n algorithms)

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

> this is not state referencing in the sense it is being used in the UDVM draft.
> (It's not a hash, either.)

Carsten,

I don't understand - what did I propose that contradicts the current SigComp/UDVM
draft?

The key point of my suggestion for how to do algorithm negotiation is that it
only uses mechanisms that are already contained in SigComp (namely "state
referencing" and "state claim"). In fact the mechanisms were originally introduced
for other reasons, but if we can use them to provide algorithm negotiation as well
then so much the better.

> I'm not quite sure I understand your mechanism, but it seems to be the
> worst-of-worlds between the existing state identifier mechanism and a
> registration-based mechanism, in the sense that it inherits all problems of
> both and then some more.

I'm not proposing a new mechanism per se; I'm simply configuring SigComp to
support algorithm negotiation by setting the application-defined parameters of
Section 3.2. In particular, this means that the final decision on whether to use
algorithm negotiation is made by 3GPP.

I make no statement as to whether algorithm negotiation is a good idea or a bad
idea. However, it's important to point out that algorithm negotiation can already
be done within the existing SigComp framework, so that we avoid a debate on
whether we need to add it or not.

> I'm strongly opposed to adding new mechanisms of this kind at this stage.

Nothing needs to be added to SigComp in order to support my proposal.

> (I also have a lot of problems with the approach, which I already have
> detailed on this list, but this does not matter at this point.)

Agreed. Algorithm negotiation is a controversial issue within the ROHC WG, and
we'll end up delaying SigComp if we debate its merits at this late stage.

Regards,

Richard