RE: [rohc] non-default capabilities

> 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
Rohc@ietf.org
https://www1.ietf.org/mailman/listinfo/rohc