Re: [rtcweb] API draft: draft-kaplan-rtcweb-api-reqs-00

Harald Alvestrand <> Fri, 21 October 2011 12:27 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1641221F8C5D for <>; Fri, 21 Oct 2011 05:27:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -110.448
X-Spam-Status: No, score=-110.448 tagged_above=-999 required=5 tests=[AWL=-0.076, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, SARE_SUB_OBFU_Q1=0.227, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 6N13q2ORkuEw for <>; Fri, 21 Oct 2011 05:27:49 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 3CDB221F8C36 for <>; Fri, 21 Oct 2011 05:27:49 -0700 (PDT)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 802FF39E19F; Fri, 21 Oct 2011 14:27:48 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 8uiB2gUPcJQD; Fri, 21 Oct 2011 14:27:48 +0200 (CEST)
Received: from [] ( []) by (Postfix) with ESMTPS id C1FD139E190; Fri, 21 Oct 2011 14:27:47 +0200 (CEST)
Message-ID: <>
Date: Fri, 21 Oct 2011 14:27:49 +0200
From: Harald Alvestrand <>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv: Gecko/20110921 Thunderbird/3.1.15
MIME-Version: 1.0
To: Dan Burnett <>
References: <> <> <>
In-Reply-To: <>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: "<>" <>
Subject: Re: [rtcweb] API draft: draft-kaplan-rtcweb-api-reqs-00
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 21 Oct 2011 12:27:50 -0000

On 10/21/2011 02:14 PM, Dan Burnett wrote:
> On Oct 21, 2011, at 7:40 AM, Harald Alvestrand wrote:
>> On 10/21/2011 11:39 AM, Hadriel Kaplan wrote:
>>> Howdy,
>>> we've posted an initial strawman for "API requirements" for "no signaling" as our chairs have asked for for the con call.
>>> I'm still not sure why we need to provide this in an I-D, but given only a few days notice and having other day jobs, we've tried our best in the short timeframe.
>>> Note: given the announced conf call for Friday (today?), I've submitted this version without getting final proof-reading from the other authors.  So some new bits I wrote they may not agree with... in fact some bits I wrote *I* may not agree with, given how late it is at night for me (well I guess early in the morning technically).  Caveat emptor. :)
>> Thank you, this document was most informative to me, and illustrated the position taken well (although I disagree with its conclusions).
>> It also served very nicely to illustrate the breadth of functionality that a "low level API" needs to expose.
>> One note (speaking as a W3C WG chair): While it's very nice to imagine that one can toss a task like "design an API" over to another organization and having it performed, in practice, the W3C functions much like the IETF; it's not a place where you throw work in order to get work done, it's a place where people who need the work done go to work on the problem.
> And speaking as an editor in the W3C group to which you are referring, the point here is that protocol discussions are leading API discussions, and both are happening in the RTCWeb group, when the API discussions should all be happening in the W3C WebRTC group.  But, since JS API discussions are happening here, we now have a "no-signaling" draft in the IETF that lists requirements on the WebRTC API, *because the chairs asked for it*.
sorry, not my intention to sound critical of the people that have 
volunteered already...

what I was reacting to was the statement in the draft that said

> 5.6. API Design Recommendations
>    Technically the API design is the role of the W3C.  That hasn't
>    stopped people in the IETF RTCWEB mailing list from discussing it ad
>    nauseum, however, and even defining a protocol for it.  This
>    document therefore recommends the following to W3C:
>    4) That when a IETF documents start telling you how to build
>      Javascript APIs, you should run far away... quickly.  :)

which SOUNDED like the requirements here were being "tossed over the wall".
I know that both you and Neil have worked on this on the "W3C side", too!


(Parenthesis: My current understanding is that the W3C group is going to 
create the API that fits what the IETF says should be the model - which 
depends, in part, on the result of this discussion.)