[rohc] RE: non-default capabilities

[Lawrence Conroy <[e-mail]>]

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

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

I am surprised at Richard's comment (see second extract) in which he
says that this has been removed due to Hans's IPR concerns. Is this
correct?

I don't understand how anyone can have IPR on capability announcement.
It's a core feature or many protocols (SDP for example, in which an
end point reports that it is ready and willing to accept data streams
compressed using a codec or set of codecs).

I await some clarification with interest - I suspect that somewhere
the lines have been scrambled.

BR,
    Lawrence

At 3:44 pm +0100 19/2/02, Hans Hannu (EPL) wrote:
>Hi,
>
>>  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 think this can be done by using the Requested feedback format as 
>described in draft-ietf-rohc-sigcomp-extended-01.txt.
>
>I have some more issues on how the two drafts (sigcomp and 
>sigcomp-extended) with the mechanisms may interact, e.g. how to 
>perform what is described above. I'll collect those and put them 
>into a separate mail.
>
and...
At 2:21 pm +0000 18/2/02, Price, Richard wrote:
>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?

and much earlier....
At 12:57 pm +0000 11/2/02, Hans Hannu wrote:
>Hi Zhigang,
>
>>  In section 5.1, I think we could add the 3rd option as follows:
>>
>>  3. If there are pre-defined UDVM codes for well-known algorithms,
>>  a compressor only needs to send the code_ID (e.g. some
>>  pre-defined index value or the MD5 hash value of the code) to
>>  its peer decompressor. The decompressor can then populate the code
>>  locally.
>
>As the sigcomp messages are preceded with a state identifier this 
>third option seems to be rather straight forward.
>
>BR
>/Hans H

-- 
[e-mail]: [phone]::<my opinions>:

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