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

["Miguel A. Garcia" <[e-mail]>]

Richard:

As I have been involved in these discussions, I noticed that I made a small 
mistake with the terminology.

At least, I have been always thinking of "algorithm announcement", rather than
"algorithm negotiation".

I am not sure if you mean "negotiation" or "announcement". At least, in my 
previous e-mails I meant that the decompressor should be able to announce 
the algorithms that are already uploaded, and therefore, don't require
a "UDVM upload" message. There is not negotiation between two parties.

/Miguel

"Price, Richard" wrote:
> 
> > 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
> 
>                                                   ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>                           Name: RMRL-Disclaimer.txt
>    RMRL-Disclaimer.txt    Type: Plain Text (text/plain)
>                       Encoding: 7bit

-- 
Miguel-Angel Garcia                     Oy LM Ericsson AB
                                        Jorvas, Finland
mailto:[e-mail]     Phone:  [phone]
mailto:[e-mail]        Mobile: [phone]

_______________________________________________
Rohc mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/rohc