Subject: [rohc] RE: non-default capabilities

From: "Price, Richard" <[email-masked]>
Date: Mon, 18 Feb 2002 14:21:47 -0000

Hi,

For the well-known but optional decompression algorithms, we need to assign a certain
identifier to each algorithm and then send a list of these identifiers from the
decompressor to the compressor. The compressor can then pick an algorithm from the list
or choose to download its own.

A mechanism to perform the above task was intended to be part of the SigComp draft, but
had to be deleted due to Hans' IPR concerns. Currently the compressor can only choose
between mandatory default decompression algorithms (supported at all decompressors) and
downloading new algorithms in the form of bytecode.

Hans: Would it be possible to provide some alternative text for the above algorithm
negotiation mechanism, such that your IPR concerns disappear?

Regards,

Richard

> -----Original Message-----
> From: Conroy, Lawrence (SMTP) 
> Sent: Monday, February 18, 2002 12:54 PM
> To: Price, Richard; [email-masked]
> Cc: [email-masked]
> Subject: non-default capabilities
> 
> 
> Hi Learned Authors, Folks,
>     I note that the new versions of the drafts (extended and the grand unified draft
> SigComp-04) draft *are* available, via links on the charter page; I didn't see
> ietf-announce messages for these, but they are there.
> 
> Having had a (very) quick look at the SigComp draft, I don't see how the capabilities
> for non-default algorithms are supported - these were discussed on the list recently,
> but how does an end point report the algorithms it supports (i.e. the states it has
> available) to its peer (remote) entity?
> 
> I ASSUME that there will be a default, mandatory unencumbered algorithm that is known
> to be supported and so this doesn't need to be reported; for the others, however...
> 
> Thus, a question - why is this not mentioned in the SigComp draft?
> (or is it, in which case, where?).
> 
> all the best,
>    Lawrence
> -- 
> [email-masked]: +44 1794 833666::<my opinions>:
>

---

From: "Lars-Erik Jonsson (EPL)" <[email-masked]>
Date: Wed, 20 Feb 2002 12:06:29 +0100

> In all cases in my previous posting, I was talking only about
> ->DECOMPRESSION<- algorithm support (default or otherwise).
> 
> I had assumed that choosing a default decompression algorithm
> was still ongoing - Is there strong disagreement that there
> should be one (albeit *which* one is still under consideration)?

Lawrence,

The major argument for defining the UDVM was to avoid this discussion
about decompressor algorithms. By defining the UDVM, we do not need to
standardize the decompression algorithms, but if we start this over
again I think we may start questioning the UDVM approach. Especially
if we start to discuss requiring a "default algorithm", I think we are
once again opening a can of worms.

> Why the heck is sending a list of identifiers of available
> decompression algorithms in the extended draft?

I do not think this is what is there. I agree that the principle you
mention may probably not be an IPR-problem, but if this is done by 
sending acknowledges of established state ("pre-loaded"), I guess there
might be IPR concerns about that. Without having an opinion on that, I
can see a difference between the general principle and how the mechanism
is provided. 

> Did I miss some comment in the postings (see third extract below),
> in which someone mentioned that they thought they had IPR on this?

Note:
When someone indicates that they know of potential IPR, it does not
necessary mean that it is their own IPR. I hope we are all looking for
potential IPR's on the technology we are standardizing, so that we can
indicate this, or avoid the technology when that is desirable.

Rgds,
/L-E

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

---

From: "Hans Hannu (EPL)" <[email-masked]>
Date: Wed, 20 Feb 2002 12:10:44 +0100

Hi, 

The proposal that is somewhat described in SigComp and SigComp-extended is not exactly like the mechanism in SDP as this proposal can be interpreted as an explicit acknowledgement for an established state, which is one feature described in SigComp extended. Thus, a capability announcement mechanism including the reserved state identifiers for decompression algorithms, may also be used for other mechanisms in SigComp-extended. 

The IPR considerations chapter in SigComp-extended is there to notify that there might possible be IPRs related to the features described in that draft. Then it is up to the people who implement those feature to make the call whether they think that there may or may not be any IPRs on those features. But, please stop trying to convince people what to think about IPRs. If you do not think that there might possible be IPRs on a specific feature why do you not just go ahead and implement it.

>     Why the heck is sending a list of identifiers of 
> available decompression
> algorithms in the extended draft?

Well, that mechanism is not really in any of the drafts. The two drafts are not exactly fully compliant yet, but I'm working on this and will get a suggestion out to the list soon.

BR
/Hans H