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

Hadriel Kaplan <> Fri, 21 October 2011 13:00 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 466BB21F8C68 for <>; Fri, 21 Oct 2011 06:00:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.303
X-Spam-Status: No, score=-2.303 tagged_above=-999 required=5 tests=[AWL=0.069, BAYES_00=-2.599, SARE_SUB_OBFU_Q1=0.227]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Jvw8mWlDASyD for <>; Fri, 21 Oct 2011 06:00:13 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 8F56D21F8C53 for <>; Fri, 21 Oct 2011 06:00:13 -0700 (PDT)
Received: from ( by ( with Microsoft SMTP Server (TLS) id; Fri, 21 Oct 2011 09:00:11 -0400
Received: from ([]) by ([]) with mapi id 14.01.0270.001; Fri, 21 Oct 2011 09:00:11 -0400
From: Hadriel Kaplan <>
To: Harald Alvestrand <>
Thread-Topic: [rtcweb] API draft: draft-kaplan-rtcweb-api-reqs-00
Thread-Index: AQHMj/FdIBIgT7vyv0mUy24pb+/t+A==
Date: Fri, 21 Oct 2011 13:00:10 +0000
Message-ID: <>
References: <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="Windows-1252"
Content-ID: <>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: AAAAAQAAAWE=
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 13:00:14 -0000

On Oct 21, 2011, at 7:40 AM, Harald Alvestrand wrote:

> It also served very nicely to illustrate the breadth of functionality that a "low level API" needs to expose.

Actually I'm 100% sure I've forgotten/missed some things it needs to expose.  BUT, some of the things I listed need to be exposed even for a ROAP model, yet for some reason aren't in the WG use-case-and-requirements draft; and some  already exist exposed in the current W3C draft I think.

> 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.
> But we all knew that, I think….

Actually I don't know anything about the W3C.  What I meant in the draft by saying "it's really up to W3C" was that I thought it was highly presumptuous of us in the IETF to tell the W3C what to do as the API.  I figured they do APIs for a living, while IETF does protocols for a living. (which might explain why we're now talking in the IETF about defining a protocol as an API, eh? ;)