Re: [rtcweb] Time allocation for video discussion (Re: Proposed Agenda For WG Meetings)

[Ron <[e-mail]>]

On Fri, Feb 22, 2013 at 08:18:28AM -0800, Matthew Kaufman wrote:
> On 2/22/2013 7:42 AM, Ted Hardie wrote:
> >Hi Matthew,
> >
> >>But just because the charter mistakenly calls this out as something for the
> >>IETF to solve doesn't mean that the IETF is the right place to have the
> >>discussion. I will note that several other IETF protocols for A/V
> >>interoperability, such as SIP, have enjoyed wide success without wasting any
> >>valuable meeting time trying to standardize on a single audio and video
> >>codec...
> >You may have heard the chairs use the term "negotiation failure" in the context
> >of selecting mandatory to implement codecs.   This phrase was taken from one of
> >Henning's talking points on practical interoperability in SIP contexts
> 
> Yes, but it is also a good description for what's going to happen
> when this actually gets discussed. There are parties in the room who
> cannot under any circumstances ship one of the two options, and
> parties in the room who cannot under any circumstances ship the
> other. At least given the current IPR issues associated with each
> option.

You still seem to be conflating "cannot" and "will not" as if they are
somehow equivalent and positions of equal merit.  And for extra irony,
doing it in the same breath as you accuse a liaison statement that
simply outlines "a few background facts" of being misleading.

VP8 offers the same poison-pill indemnity as Opus.  Since we've already
seen people who were around since the very beginning of the CODEC WG
(to strenuously oppose its formation, and resist its later progress)
submit very late (and also apparently very spurious) IPR claims against
it, I don't see how the real world situation is actually any different
between them.

Both offer stronger protection against hostile IPR assertions, equally
to *all* users, than H.264 does - and neither fundamentally excludes
the enormous market of developers whose distribution model makes it
impossible to track and count and extort royalties from users.

That's a very different and more intractable problem to "my company
doesn't like or want to support that developer model".  Since it
already uses that model too for some of its products, saying that it
"cannot under any circumstances support it", goes beyond misleading
to plainly disingenuous.

It's fine for different groups to have different preferences, and
for organisations to want to protect their profit mechanisms.
But that is not a relevant concern of the IETF - while underwriting
the success prospects of a standard through broad availability and
best practice for interoperability, quite definitely is.

  Ron