Re: [rtcweb] Comment on Straw Poll replies

[Harald Alvestrand <[e-mail]>]

On 01/11/2014 05:42 PM, Dave Crocker wrote:
> On 1/11/2014 7:16 AM, Enrico Marocco wrote:
>> On 11/01/14 15:47, Dave Crocker wrote:
>>>       I am curious about the claim of large-scale, existing WebRTC
>>> support, given that none of this working group's drafts has yet 
>>> received
>>> IETF approval nor been published as an RFC.
>>
>> Dave, unfortunately for us who spend a big chunk of our lives in, the
>> IETF does not have any exclusive right over the term "WebRTC". What the
>> rest of the world call "WebRTC" can be roughly defined as a media stack
>> that is implemented in two of the four major desktop and mobile
>> browsers. It's hard to estimate the size of the installed base, but the
>> numbers floating around are in the order of 10**9.
>>
>> The IETF role in this as vast as controversial field is -- as it should
>> be -- document running code and help the search of rough consensus to
>> smooth the rough edges that prevent interoperability. Video codecs being
>> one of them.
>
>
> Enrico,
>
> Thanks for your response It was, unfortunately, quite helpful.
>
> That is, your note was helpful but the reality you describe highlights 
> an apparently deep and long-standing problem for the working group.
>
> I do see the non-IETF references to webrtc and implementations for it, 
> such as [1][2].

At the outset, there was a decision to use "RTCWEB" as a name for the 
IETF effort and "WEBRTC" as a name for the W3C effort that mirrors it. 
Somewhat later, the discussion arose on what we should call the whole 
effort (IETF, W3C and company implementations), and the consensus seemed 
to be to use the term "WebRTC" (note the different capitalizations).

For someone who enters the group at a time long after the initial 
discussions, I can see why the terminology would be confusing, even when 
it is applied consistently (something that doesn't always happen).

> (That I, as a Firefox user, have no idea how to try to use rtcweb from 
> my browser speaks to some packaging and usability issues, but doesn't 
> counter what you and the firefox documentation have said...)

Once you learn to program Javascript, it is actually quite simple to use 
it from your browser. Simpler, in my opinion, than, for instance, using 
TCP through a BSD Sockets interface.

The sentence "using TCP from my browser" is, of course, not particularly 
interesting; either it's built-in (as a substrate for what you're 
already doing), or it's unavailable (browsers cannot, by design, allow 
clients access to raw TCP sockets).

>
> There have been many IETF efforts that represented continuation of 
> existing industry efforts, with the goal of documenting and enhancing 
> that existing work.
>
>      This working group's discussion record and document-development
>      history look very little like one of those "document existing code
>      and enhance the spec" efforts.
>
> Such efforts might have considerable controversy, but they retain a 
> foundation of the existing work.
>
> However the working group's history matches one of a /new/ effort 
> working on a complex topic and gaining relatively poor group 
> coherence.  The current impasse on an MTI component looks like an 
> example, to me.
>
> Note that I'm not disagreeing with what you've said, but am noting the 
> disparity between that apparent reality outside the IETF, versus the 
> history (and present) for the IETF's rtcweb working group.

That's what happens when IETF efforts take longer than implementation 
efforts.
These things started in parallel, with the intent of arriving together. 
At the moment, the implementations seem to be in the lead.

> If this group is documenting and building upon existing services, it 
> needs group agreement that is what it is doing, in which case 
> compatibility with that existing operational base is a fundamental 
> requirement.  Exceptions might make sense but they need very strong 
> justification and massive consensus.
>
> If this group is using the existing work merely for input and advice 
> to a new effort -- that is, if the group feels to produce an 
> incompatible service -- then that, too, needs group consensus and the 
> effort needs a different name, so there is no (further) 'brand' 
> confusion.

The group is definitely creating work that was new and incompatible to 
what existed at the time the group started working.

If the group *at this time* chooses to crash and burn, and produce 
nothing, that will not make the existing implementations go away.