[rohc] IPR situation

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

Hi,

Some background on the IPR situation:

Based on previous mailing list discussions, I concluded that the IPR issues
on the base SigComp solution were due to the informative description of
how to implement a feedback mechanism rather than the technical content of
the solution. So in release 04 of the SigComp draft I defined the following
list of identifiers as a well-known area of the UDVM memory:

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|        id_length 1        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                           |
:        id_value_1         :
|                           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
         :         : 
         :         : 
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|        id_length n        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                           |
:        id_value_n         :
|                           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

If a certain identifier is sent from Endpoint A to Endpoint B, then Endpoint
B knows that the corresponding piece of bytecode is available at Endpoint A
and can be retrieved using the appropriate UDVM instruction.

The aim of the above mechanism was not to provide feedback (although it could
feasibly be used as such) but rather to allow an endpoint to announce support
for a selection of well-known decompression algorithms. Each algorithm would
be given its own unique identifier (e.g. 0 for NULL, 1 for DEFLATE etc.).

I also hoped that the mechanism could be used to indicate support for the
extended operations themselves, by reserving a certain identifier for the
sigcomp-extended draft. Without this ability the extended operations would
have to be negotiated externally to SigComp, or else feedback data would be
sent without knowing whether or not it could be understood by the receiver
(potentially very inefficient).

Unfortunately, including the above mechanism raised IPR concerns from Hans,
so to get the draft out on time I deleted it.

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

It isn't! Currently the ability to send a list of supported decompression
algorithms isn't available in either draft, so it can only be done externally
to SigComp.

[LEJ] 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.

The actual mechanism provided is as described above, with no mention of what
the identifiers are actually for (e.g. they could be used to retrieve well-
known decompression algorithms, dictionaries of SIP phrases, extended
operation mechanisms etc.).

In fact, the draft didn't include the terms "feedback" or "acknowledgement" at
all.

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

This was done offline - I proposed the above list of identifiers for inclusion
in the SigComp draft, but Hans indicated that he had IPR concerns on it so I
didn't bother.

[LEJ] 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.

My understanding of the IETF approach to dealing with IPRs is that an RFC
includes an IPR statement only as a pointer to an official IPR announcement
made at http://www.ietf.org/ipr.html.

The advantage of the above approach is that as authors, we don't need to make
a decision on whether particular patents are applicable to our work or not.
An IPR statement is only required when an official IPR claim is made, so what
we need to find out is whether anyone would put in such a claim on basic
SigComp if the above announcement mechanism were to be included.

[HH]  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.

I think that the above comment is key to the IPR situation. All that SDP can do
is announce a list of algorithms supported at an endpoint, and this is all that
SigComp needs to be able to do as well. Whether the algorithms are predefined
or downloaded on the fly is not specified by either draft.

As far as I can tell, the IPR concerns appear to apply to one possible use for
announcing some identifiers rather than to the concept itself. Whether the
identifiers are used in an IPR-encumbered manner depends on where these identifiers
come from - are they well-known or are they created on the fly? In fact, the
decision on how to use the identifiers (and hence the IPR situation) is made
by the compressor.

Hans: Would the following statement in basic SigComp solve your IPR concerns?

"The capabilities announcement mechanism MUST only be used to announce support
for well-known algorithms."

[HH]  Thus, a capability announcement mechanism including the reserved state 
      identifiers for decompression algorithms, may also be used 
      for other mechanisms in SigComp-extended.

This is certainly the case, but I don't think that it means an IPR statement is
required on the basic SigComp draft even if it includes the ability to send a
list of identifiers from one endpoint to another. After all, the UDVM can run
any algorithm in existence - some encumbered, some not - and the decision on
which algorithms to run is made by the compressor.