Subject: Alternative decision process in RTCWeb

From: Gonzalo Camarillo <[email-masked]>
Date: Thu, 28 Nov 2013 11:17:42 +0200

Folks,

as you may know, the RTCWeb WG is trying to select a
mandatory-to-implement video codec. So far, the WG has been unable to
reach consensus using traditional consensus calls. Now, the WG is
considering alternative options to make that decision.

If you are interested in following that discussion on the RTCWeb list,
this would be a good place to start:

http://www.ietf.org/mail-archive/web/rtcweb/current/msg09909.html

Cheers,

Gonzalo

---

From: Eliot Lear <[email-masked]>
Date: Thu, 28 Nov 2013 11:24:23 +0100

Hi Gonzalo,

> http://www.ietf.org/mail-archive/web/rtcweb/current/msg09909.html

Let's be clear on what is being suggested: a form preferential voting
rather than continuing to seek rough consensus through other
alternatives.  The ramifications of what is being proposed extend well
beyond the working group.  That is not how our organization operates. 
As Bernard Aboba wrote:

> [BA] It strikes me that once we venture beyond consensus and running
> code into voting, we have left our home behind for someplace else
> whose principles should at the least be articulated.

And I would go further.  I would expect a very rough process ride if
this path is taken, and it should require IETF consensus given the
potential moral hazards it introduces to other activities.  Failing that
consensus, the working group should find a way to sort themselves within
the bounds of our existing processes.

Eliot

---

From: Dave Cridland <[email-masked]>
Date: Thu, 28 Nov 2013 11:18:22 +0000

> beyond the working group.  That is not how our organization operates.

Quite.

Both Arrow's Theorum and and willingness to appeal have both rightly been
raised. If nobody else appeals the decision, then I will - assuming I'm
allowed to - if it gets this far.

I think that two consensus calls should be taken at this stage:

1) Does the working group (and, possibly, the IETF) actually want to
mandate a single codec at this stage, or merely advise implementors that
both H.264 and VP8 are deployed in the field?

2) If the Working Group does want to mandate a single codec, is there
consensus for one of the alternate decision-making processes described in
RFC 3929? This is our best guess at what to do here; despite it being a
(presumably expired) Experimental track RFC.

Allowing working groups to create new process on the fly without involving
IETF-wide consensus seems like a veyr dangerous precedent to set, and one
that would invite substantial abuse.

Dave.

---

From: Eric Burger <[email-masked]>
Date: Thu, 28 Nov 2013 06:29:14 -0500

More to the point, if the WG cannot come to IETF consensus, that itself is sufficient to let the IESG know the WG (a bunch of close experts) is not *READY* to select a single codec. If the WG is not *READY* to pick a single codec, neither is the IETF.

The proposal is DOA.

BTW, per the rules, I am eligible to vote. Sigh.

On Nov 28, 2013, at 6:18 AM, Dave Cridland <[email-masked]> wrote:

> Both Arrow's Theorum and and willingness to appeal have both rightly been raised. If nobody else appeals the decision, then I will - assuming I'm allowed to - if it gets this far.
> 
> 1) Does the working group (and, possibly, the IETF) actually want to mandate a single codec at this stage, or merely advise implementors that both H.264 and VP8 are deployed in the field?
> 
> 2) If the Working Group does want to mandate a single codec, is there consensus for one of the alternate decision-making processes described in RFC 3929? This is our best guess at what to do here; despite it being a (presumably expired) Experimental track RFC.
> 
> Allowing working groups to create new process on the fly without involving IETF-wide consensus seems like a veyr dangerous precedent to set, and one that would invite substantial abuse.
> 
> Dave.

---

From: Dave Cridland <[email-masked]>
Date: Thu, 28 Nov 2013 12:17:39 +0000

On Thu, Nov 28, 2013 at 11:29 AM, Eric Burger <[email-masked]>wrote:

> More to the point, if the WG cannot come to IETF consensus, that itself is
> sufficient to let the IESG know the WG (a bunch of close experts) is not
> *READY* to select a single codec. If the WG is not *READY* to pick a single
> codec, neither is the IETF.
>
>
That's the point of my (1).

But in any case, much of the discussion is now centering around selecting
more complex choices, such as whether to implement any three of VP8,
Theora, and H.261, but only on Sundays in July (rain permitting).

My favourite exchange from this is
http://www.ietf.org/mail-archive/web/rtcweb/current/msg09958.html by the
way.

> The proposal is DOA.
As someone merely following the debate rather than with a stake (or oar) in
it, that's my personal opinion too. I suspect a de-facto codec selection
will emerge within a year, and this will occur whether or not the IETF
mandates any particular option as de jure.

But I'm not involved, really, I'm only following along in my somewhat
obscure (but impressively titled) capacity of "XSF Future Jingle SIG
Chair". FWIW, the XSF formally gave up trying to pick an MTI video codec
some time back, *and* came to a parallel conclusion WRT audio too - both
decisions (XEP-0299 and XEP-0266) we'll be revisiting in the light of the
RTCWEB decisions. There was much excessive warmth in those discussions, too.

> BTW, per the rules, I am eligible to vote. Sigh.
That depends on whether the vote, or for that matter, the rules, are within
the jurisdiction of the working group, though.

Even assuming that is the case, it's not clear to me that there is a
consensus surrounding the voting rules - they've certainly yet to be
summarised in one place based on the discussion that has occurred so far.

There's so many points on which an appeal can be made, we'll all be spoilt
for choice.

Dave.

---

From: Eric Burger <[email-masked]>
Date: Thu, 28 Nov 2013 08:30:37 -0500

Interestingly, this is precisely the figure I had in my head (one year), but I was not as bold as you to say it out loud. Now that you have said it, I’ll say it too.

Wait a year and see if the industry is not closer to consensus. 

On Nov 28, 2013, at 7:17 AM, Dave Cridland <[email-masked]> wrote:

> As someone merely following the debate rather than with a stake (or oar) in it, that's my personal opinion too. I suspect a de-facto codec selection will emerge within a year, and this will occur whether or not the IETF mandates any particular option as de jure.
>

---

From: Dave Crocker <[email-masked]>
Date: Thu, 28 Nov 2013 06:40:54 -0800

> I think that two consensus calls should be taken at this stage:

I concur with the precedence concerns that have already been raised, and 
also wonder about trying to orchestrate a sequence of consensus calls 
designed to move the group through a process that will get some folk to 
change their positions, in order to get the matter resolved.

The simplest form of such a sequence that I've heard about is to note 
the impasse, then ask whether the group does want to get the matter 
resolve.  That's likely to get a strong rough consensus yes.  Then note 
it's not going to resolve until folk change their current positions. 
The example I heard about did then produce a preferred choice.

No doubt, the current situation has folk who are more tenacious, so 
perhaps the sequence of calls needs to be a bit more elaborate.

BTW, as distasteful as it might be, is there a reason that making /both/ 
MTI would not work?

d/

-- 
Dave Crocker
Brandenburg InternetWorking
bbiw.net

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 28 Nov 2013 06:57:10 -0800

On Thu, Nov 28, 2013 at 6:40 AM, Dave Crocker <[email-masked]> wrote:
> The simplest form of such a sequence that I've heard about is to note the
> impasse, then ask whether the group does want to get the matter resolve.
> That's likely to get a strong rough consensus yes.  Then note it's not going
> to resolve until folk change their current positions. The example I heard
> about did then produce a preferred choice.
>
> No doubt, the current situation has folk who are more tenacious, so perhaps
> the sequence of calls needs to be a bit more elaborate.
>
> BTW, as distasteful as it might be, is there a reason that making /both/ MTI
> would not work?

It's one of the proposed choices. However, it's important to understand that in
in this case, many people more don't want X than do want Y.

-Ekr

---

From: Dave Cridland <[email-masked]>
Date: Thu, 28 Nov 2013 15:04:17 +0000

> BTW, as distasteful as it might be, is there a reason that making /both/

Speaking as a third party to this, so I may have misinterpreted, then yes.
My (possibly simplistic and/or plain wrong) summary follows:

The problem appears to be largely driven by actual IPR issues surrounding
H.264, though it has strong hardware support particularly within the
incumbent VOIP market players.

My impression is that VP8 is largely (though not entirely) thought to be
free from IPR headaches, but lacks the hardware support that is baked into
the market. [I have seen exchanges suggesting that other people suspect VP8
of having IPR issues, but nobody I've seen in the posts I've reviewed has
claimed that position for themselves, so it's not clear to me how IPR-free
it's really perceived]

It's possible to make H.264 an MTI only if you're willing to ignore the
"true" open-source browsers (by which I mean IceWeasel rather than Firefox,
and Chromium rather than Chrome) - Cisco have somewhat mitigated the IPR
issues with their OpenH264 effort, though the precise licensing details
don't align fully with open source, and it's clear they will cause
significant headaches to at least some parties.

It's possible to use VP8 as an MTI only if you're willing to turn a blind
eye to the phenomenal deployed running silicon. (To gain some idea of the
level of investment in the silicon, it's worth thinking about how much
actual cash Cisco are committing to in MPEG-LA fees to cover their
OpenH264).

The problem is simply that both codecs on the table as front-runners have
significant and insoluble downsides for non-intersecting portions of the
market. Both sides are negotiating in good faith, and both sides' concerns
are real and valid.

To make matters more complex, it appears that the encoding side may have
entirely different IPR issues than the decoder for video in general.

The whole situation is undoubtedly a mire of complexity, and I don't for a
minute envy the chairs - FWIW, when XEP-0266 and XEP-0299 were produced, I
was serving on the XMPP Council (read: IESG/WG Chair analogue), and so I've
more than a little sympathy, and no few scars.

Dave.

---

From: Sam Hartman <[email-masked]>
Date: Thu, 28 Nov 2013 10:35:09 -0500

>>>>> "Gonzalo" == Gonzalo Camarillo <[email-masked]> writes:

Hi.  I've thought about the general issue of alternative decision making
a lot, and it did come up a number of times while I was an AD, although
none with such significant stakeholder interest as this.

The issue I'm most concerned about is confirming that there is rough
consensus to make a decision.  I think any variance from rough consensus
for decision making must itself meet a fairly high consensus bar.

"But we can't make a decision; we have to make a decision, so of course
we're going to do something alternative," you might say.

You don't have to make a decision though.  You can decide the IETF is
not the right forum for your decision.  You can decide not to
standardize.  You can decide to run experiments, get  data, try to
implement.  You can give up.
You can redefine the problem.  You can for example decide to have two
mandatory-to-implement options, or require receivers to implement both
and not mandate which senders must pick.

In many cases it does turn out to be easier to get consensus that a
decision must be made than it is to get consensus on a decision.
However without chairs being able to clearly show that consensus to
decide has been reached I'd expect an appeal and expect that appeal to
be successful.

Next, it's strongly desirable to get consensus on your process for
making the decision.
If you can get that, or lacking that, get consensus  on someone who will
decide the process (chairs or AD), I think you are coming along
reasonably.

Obviously concerns of fairness are important.  A process that inherently
advantaged one company or viewpoint would be suspect.

I'd personally favor coin-flips, external arbitors or similar over
voting.  We don't want to encourage voting because we could get into
situations where people block the consensus process in order to force a
vote.  Absent things like well-defined membership and procedures to
avoid one company stuffing the ballot box, going there seems
problematic.

Coin flips are nice.  They really create pressure among anyone who
actually cares about the outcome to compromise, to explore whether a
consensus can be built.  However for the frequent situations where a
decision is critical but it really doesn't matter (even if some people
think it does), they get the job done.

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 28 Nov 2013 07:57:05 -0800

> significant headaches to at least some parties.

Dave,

It's actually not clear to me why IceWeasel and Chromium can't use OpenH264
in exactly the same way that Firefox can, i.e., by doing download from Cisco's
site. I appreciate that people may have philosophical objections to doing
this, but I haven't actually heard any reason why this is a practical problem
as opposed to a philosophical one. This isn't to say that there aren't
situations
in which a downloaded module doesn't work, but I don't see that those are
any different for Chromium or IceWeasel then they are for Firefox.
(And

As a side note, the relationship between the Firefox binaries distributed by
Mozilla and the Firefox source isn't quite the same as between Chromium
and Chrome. The Firefox that is distributed by Mozilla is basically the same
as that you would get if you compiled the source yourself. By contrast, Chrome
contains a bunch of extra bits that are not in Chromium (e.g., Flash).

-Ekr

---

From: Dave Cridland <[email-masked]>
Date: Thu, 28 Nov 2013 16:38:09 +0000

> any different for Chromium or IceWeasel then they are for Firefox.

I think there's various issues of greater or lesser degree; logistics,
licensing compatibility, IPR concerns, and concerns about monoculture. Some
issues could be pigeon-holed as more than one; I don't know if the lack of
support on iOS counts as logistical, licensing, or IPR, for example.

But yes, I think the most vocal objections are from those who follow the
general spirit of the GPL, in as much as having a strong desire to ship
source. But I hesitate to brush that off as purely a philosophical debate
on how many codecs can fit on a pin - eliminating open source
implementations across many jurisdictions has a practical basis as well as
a philosophical one. Equally, eliminating barriers to open source
essentially eliminates all the other objections.

Don't take this as being a heavy bias against H.264 from me - I entirely
understand the reasoning behind wanting H.264 too. But it's easier to
express - deployed silicon is a simple, but powerful, argument.

> contains a bunch of extra bits that are not in Chromium (e.g., Flash).

Sorry, I'm aware of this but was simplifying somewhat too liberally. I also
simplified in implying there weren't those who were perfectly happy with
both H.264 and VP8 - but I do think there are significant chunks of the
market unhappy with one or the other.

Dave.

---

From: Melinda Shore <[email-masked]>
Date: Thu, 28 Nov 2013 08:50:15 -0900

On 11/28/13 2:29 AM, Eric Burger wrote:
> More to the point, if the WG cannot come to IETF consensus, that
> itself is sufficient to let the IESG know the WG (a bunch of close
> experts) is not *READY* to select a single codec. If the WG is not
> *READY* to pick a single codec, neither is the IETF.

This strikes me as precisely the issue.  If there's no
consensus there's no consensus.

Melinda

---

From: Tim Bray <[email-masked]>
Date: Thu, 28 Nov 2013 10:10:53 -0800

It seems to me that if there are sane strongly-held objections to both of
the alternatives on the table, then neither alternative is suitable for a
standards-track RFC.

---

From: Yoav Nir <[email-masked]>
Date: Thu, 28 Nov 2013 21:24:43 +0200

On 28/11/13 8:10 PM, Tim Bray wrote:
> It seems to me that if there are sane strongly-held objections to both 
> of the alternatives on the table, then neither alternative is suitable 
> for a standards-track RFC.
So, does that mean that there should not be a standardized codec for 
WebRTC, or that we should come up with with a new alternative that 
nobody wants?

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 28 Nov 2013 17:45:01 -0500

> the bounds of our existing processes.

It might surprise people to find that I support Eliot's position on this.

I still believe that the NOMCON process is a liability that should be
replaced by a democratic system The issue there is whether there is going
to be accountability and whether people who speak on behalf of the IETF can
do so with authority.

The issue here is different, the question is whether the people who write
an deploy code can come to a consensus. A vote is not  going to make that
happen. If the WG votes for X but a browser provider with 30% of the market
insists that they won't do X, a vote is not going to change matters.

-- 
Website: http://hallambaker.com/

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Thu, 28 Nov 2013 17:53:12 -0500

> claimed that position for themselves, so it's not clear to me how IPR-free

The issues for vendors are litigation risk and cost.

If you are a commercial vendor with an existing H.264 license there is no
cost and no litigation risk for using that codec but the licenses you have
acquired are almost certainly specific to H.264. So using any other CODEC
is likely to create a substantial liability risk.

If you are an open source provider without a H.264 license the situation is
very different.

This is not going to be settled by a vote. I am not speaking for any of the
parties but if I did have a dog in this fight I would have my corporate
counsel write a letter to the WG stating that we are not going to be bound
on the WG decision in this case.

We are talking about a decision that could result in a hundred million
dollar lawsuit. The issue is not who is going to write code but who is
likely to get hit with a suit.

---

From: Cullen Jennings <[email-masked]>
Date: Thu, 28 Nov 2013 16:05:35 -0700

On Nov 28, 2013, at 3:45 PM, Phillip Hallam-Baker <[email-masked]> wrote:

> The issue here is different, the question is whether the people who write an deploy code can come to a consensus. A vote is not  going to make that happen. If the WG votes for X but a browser provider with 30% of the market insists that they won't do X, a vote is not going to change matters.

As a quick cheat sheet to where browser vendors might stand on this matter...

There are four major browsers. Firefox has said they will implement the standard and everyone I have talked to in the WG believe they will regardless of this video codec choice. Chrome awhile back said they will implement the standards but they have not updated that opinion recently. Many people believe they will implement the standard regardless of this choice (keep in mind Chrome already has both 264 and VP8 in it for the video tag). IE and Safari has not said if they will do WebRTC at all.

Mozilla plans to support both VP8 and H.264 and as far as I can tell prefers Daala. Google prefers VP8. Apple and Microsoft prefer H.264. 

From an IPR point of view. Mozilla plans to support both VP8 and H.264. Chrome, IE, and Safari already use 264 and license the IPR. And Chrome also uses VP8.

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 29 Nov 2013 04:27:21 +0100

> As a quick cheat sheet to where browser vendors might stand on this matter...

Thanks.

In a similar vein, can anyone point out what we get if the IETF were to agree on a single MTI video codec for WebRTC?
What is the upside to making this herculean effort?

Grüße, Carsten

---

From: Dave Cridland <[email-masked]>
Date: Fri, 29 Nov 2013 11:41:20 +0000

> As a quick cheat sheet to where browser vendors might stand on this

I think this is stating the obvious, but just for the record, there's a
much broader community than just the four leading browser vendors.

Pretty much all the existing Jingle/XMPP community is tracking this work
very closely, for example, and I think it'd be fair to say that any MTI
affecting WebRTC will essentially be transcribed into XEP-0266/XEP-0299 as
the MTI for Jingle.

I don't think it's be a stretch to assume that most VOIP players are in a
similar situation - WebRTC will essentially define the baseline for voice
and video over the internet.

This is, of course, just following the simple fact that there are many more
browsers deployed than desktop XMPP clients, for example, and efforts such
as http://otalk.im/ and http://go.estos.de/ take advantage of interop
between Jingle and the browser.

As a further note, the XMPP/Jingle community has done perfectly well, so
far, with no MTI, but I'm asking their opinion at the moment - an early,
and particular well-written, response from Emil Ivov is here:

http://mail.jabber.org/pipermail/jingle/2013-November/002041.html

Dave.

---

From: Stephan Wenger <[email-masked]>
Date: Fri, 29 Nov 2013 18:22:14 +0000

Hi,
I agree with the basic sentiment of Philip’s email.  However, in the (perhaps forlorn) hope to shed some light into the IPR situation, allow me to correct inline below some aspects of it that were painted in an overly broad brush.  I hope my characterization is reasonably impartial.  All aspects below were discussed on the rtcweb list ad nauseam, and in much greater detail.
Stephan

From: Phillip Hallam-Baker <[email-masked]<mailto:[email-masked]>>
Date: Thursday, 28 November, 2013 at 14:53
To: Dave Cridland <[email-masked]<mailto:[email-masked]>>
Cc: IETF Discussion <[email-masked]<mailto:[email-masked]>>, Dave Crocker <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: Alternative decision process in RTCWeb

On Thu, Nov 28, 2013 at 10:04 AM, Dave Cridland <[email-masked]<mailto:[email-masked]>> wrote:
On Thu, Nov 28, 2013 at 2:40 PM, Dave Crocker <[email-masked]<mailto:[email-masked]>> wrote:
BTW, as distasteful as it might be, is there a reason that making /both/ MTI would not work?

[…]

If you are a commercial vendor with an existing H.264 license there is no cost and no litigation risk for using that codec but the licenses you have acquired are almost certainly specific to H.264. So using any other CODEC is likely to create a substantial liability risk.

StW: A commercial vendor with an obtained pool license and current on your reports and your bill has a license and insofar there is virtually no litigation risk from the 30 pool members.  I write “virtually no risk”, because fraudulent lawsuits are not exactly unheard of, and there is nothing one can do about those.  The cost is $0.00 or $0.20 or $0.10 per codec, depending on volume.  According to Cisco, even without a license of your own, the cost can be $0 if your product implements the download mechanism they offer.  Note that the definition of “codec” in the MPEG-LA agreements is hardware centric and difficult to interpret in a software environment.  So there is cost (although potentially not for you).
Even with an MPEG-LA license, there also is litigation risk from those rightholders who are not pool members, which is a not insignificant percentage.  However, the monetary damages that can reasonably be expected from licensing or litigation are, according to recent rulings, some of which are under appeal right now, quite low.  This is because H.264 and its patents were developed by a very broad community which agreed to license under RAND terms.  As there is not so much money to be made, the chance that a rightholder would litigate outside of a strategic context (smartphone wars, pool enforcement) is perhaps not overly high.  Of course, that is of little consequence once the multimillion $$$ bill from your lawyer rolls in.  H.264 essential patents have been litigated at least 4 times since 2003, sometimes as pool enforcement actions, and sometimes in the context of smartphone wars.  There are some 1200 licensees of the H.264 pool, including mega companies and little guys one has never heard of.

In terms of patentable technologies, VP8 is considered by many (including myself) mostly a subset of H.264.  (It contains a few additional features over H.264 but allow me to ignore those here.)  Insofar, one can expect that a subset of the H.264 essential patents may also ready on VP8, in addition to a few VP8 specific patents.  As far as licensing goes, Google has agreed to compensate 11 rightholders (that also happen to be H.264 rightholders) an undisclosed amount, and obtained a license from them which they generously make available to us, along with a license under their own patents, and subject to certain conditions which most people consider bearable.  So I think it’s safe to assume that these rightholders and google are not going to litigate over VP8.  As VP8 was not developed in an organization under RAND IPR policy terms, there is no RAND safety net.  Anyone other but the 12 companies above could theoretically sue over a VP8 patent and demand sun/moon/stars and/or injunctive relief.  Nokia has announced that they are not willing to license patents they believe read on VP8, see here:   https://datatracker.ietf.org/ipr/2035/.  Nokia has also asserted allegedly VP8 essential patents against HTC in (at least) two distinct lawsuits in Germany and one ITC complaint.  One of the lawsuits is dismissed and under appeal and the second is stayed pending an invalidation procedure (something the German courts do only if they consider it likely that the patent is invalid as granted).  AFAIK, the ITC complaint is still in the procedural warm-up phase.  My personal take on these lawsuits is that they have to be seen in the greater context of the smartphone patent wars.  I may be wrong.   However, if I’m right, then there will probably be a settlement in the not too distant future, with terms unpublished, the lawsuits go away, and we would all be none the wiser. /StW

If you are an open source provider without a H.264 license the situation is very different.

StW: Yes, it is different.  H.264 implementations have been available in open source form, since at least 2006.  They have been part of major Linux distributions forever.  I’m following the litigation environment related to video codecs quite closely, and I have not heard of a single lawsuit against an open source developer or distributor regarding video codecs, including H.264.  All that  is also true for VP8, except that VP8 is newer.  /StW

This is not going to be settled by a vote. I am not speaking for any of the parties but if I did have a dog in this fight I would have my corporate counsel write a letter to the WG stating that we are not going to be bound on the WG decision in this case.

StW: I don’t think that such a letter is needed.  IETF RFCs, or parts thereof, are regularly ignored by the implementer community, sometimes to the detriment and sometimes to the benefit of the Internet at large.  There’s no standard’s police that could enforce compliant implementations. /StW

We are talking about a decision that could result in a hundred million dollar lawsuit. The issue is not who is going to write code but who is likely to get hit with a suit.

---

From: Harald Alvestrand <[email-masked]>
Date: Sat, 30 Nov 2013 15:53:51 +0100

> What is the upside to making this herculean effort?
The relevant section is section 2.3 of draft-ietf-rtcweb-overview.

2.3.  On interoperability and innovation

    The "Mission statement of the IETF" [RFC3935] states that "The
    benefit of a standard to the Internet is in interoperability - that
    multiple products implementing a standard are able to work together
    in order to deliver valuable functions to the Internet's users."

    Communication on the Internet frequently occurs in two phases:

    o  Two parties communicate, through some mechanism, what
       functionality they both are able to support

    o  They use that shared communicative functionality to communicate,
       or, failing to find anything in common, give up on communication.

    There are often many choices that can be made for communicative
    functionality; the history of the Internet is rife with the proposal,
    standardization, implementation, and success or failure of many types
    of options, in all sorts of protocols.

    The goal of having a mandatory to implement function set is to
    prevent negotiation failure, not to preempt or prevent negotiation.

    The presence of a mandatory to implement function set serves as a
    strong changer of the marketplace of deployment - in that it gives a
    guarantee that, as long as you conform to a specification, and the
    other party is willing to accept communication at the base level of
    that specification, you can communicate successfully.

    The alternative - that of having no mandatory to implement - does not
    mean that you cannot communicate, it merely means that in order to be
    part of the communications partnership, you have to implement the
    standard "and then some" - that "and then some" usually being called
    a profile of some sort; in the version most antithetical to the
    Internet ethos, that "and then some" consists of having to use a
    specific vendor's product only.

---

From: Dave Crocker <[email-masked]>
Date: Sat, 30 Nov 2013 07:08:45 -0800

> What is the upside to making this herculean effort?

basic interoperability, without prior agreement.

but perhaps you are asking a deeper question?

d/

---

From: Bjoern Hoehrmann <[email-masked]>
Date: Sat, 30 Nov 2013 16:38:36 +0100

* Carsten Bormann wrote:
>In a similar vein, can anyone point out what we get if the IETF were to 
>agree on a single MTI video codec for WebRTC?

There are a number of conflicting goals I have seen people express. Some
for example want compatibility with legacy endpoints without transcoding
video data. Others want to ensure that Free software implementations can
interoperate with commercial products (without unacceptable sacrifices
in terms of video quality and coding performance). Some simply do not
want that WebRTC becomes known for negotiation failures, which could do
serious damage to the protocol. And so on. I am not aware of anyone in-
sisting there be only a single codec though.

I do not know whether the Working Group's Requirements specification
denies some of the arguments (e.g., it could say compatibility with
legacy endpoints is a non-goal).
-- 
Björn Höhrmann · mailto:[email-masked] · http://bjoern.hoehrmann.de
Am Badedeich 7 · Telefon: +49(0)160/4415681 · http://www.bjoernsworld.de
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 · http://www.websitedev.de/

---

From: Eric Burger <[email-masked]>
Date: Sat, 30 Nov 2013 10:28:56 -0500

Correct me if I am mistaken. I think the following two messages say is:
	(1) just about everyone has IMPLEMENTED both H.264 and VP8
	(2) people are worried about the availability or lack thereof of H.264 free licensing
	(3) people are [should be] worried about lawsuits resulting from the use of H.264 or VP8

Frankly, I am now fully in Sam’s camp:
> think it does), they get the job done.

We are way beyond picking a technically better solution. They smell like even trade-offs. We are way beyond picking a businessly better solution. They are both promised to be either free, nearly free, or you-might-have-to-license-but-the-platform-you-run-on-already-has-a-paid-license-so-it-is-free. We cannot tell which codec has less legal liability. Well, it is clear H.264 has more deterministic liability, but VP8’s liability today is literally unbounded.

At this point, the King Solomon Solution <http://en.wikipedia.org/wiki/Judgment_of_Solomon> is the solution. Cut the baby in half. See who blinks. I need practice with my Tai QI sword - I will be happy to provide the blade.

On Nov 29, 2013, at 1:22 PM, Stephan Wenger <[email-masked]> wrote:

> From: Phillip Hallam-Baker <[email-masked]>
> To: Dave Cridland <[email-masked]>
> Cc: IETF Discussion <[email-masked]>, Dave Crocker <[email-masked]>, "[email-masked]" <[email-masked]>

---

From: Ofer Inbar <[email-masked]>
Date: Sat, 30 Nov 2013 11:20:58 -0500

On Thu, Nov 28, 2013 at 04:38:09PM +0000,
> express - deployed silicon is a simple, but powerful, argument.

Pardon this possibly naive question: How is deployed silicon
an argument *against* implementing VP8 alongside H.264?
  -- Cos