[rtcweb] Fwd: New Version Notification for draft-jesup-rtcweb-data-01.txt

Ralph Giles <giles@thaumas.net> Fri, 04 November 2011 00:10 UTC

Return-Path: <giles@thaumas.net>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 1D53811E8089 for <rtcweb@ietfa.amsl.com>; Thu, 3 Nov 2011 17:10:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.827
X-Spam-Status: No, score=-2.827 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id vLAo4Zn6pdUn for <rtcweb@ietfa.amsl.com>; Thu, 3 Nov 2011 17:10:36 -0700 (PDT)
Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com []) by ietfa.amsl.com (Postfix) with ESMTP id 0979711E80F0 for <rtcweb@ietf.org>; Thu, 3 Nov 2011 17:09:59 -0700 (PDT)
Received: by vcbfl11 with SMTP id fl11so1918111vcb.31 for <rtcweb@ietf.org>; Thu, 03 Nov 2011 17:09:59 -0700 (PDT)
MIME-Version: 1.0
Received: by with SMTP id h14mr12041529vdg.132.1320365398026; Thu, 03 Nov 2011 17:09:58 -0700 (PDT)
Received: by with HTTP; Thu, 3 Nov 2011 17:09:57 -0700 (PDT)
X-Originating-IP: []
In-Reply-To: <CAEW_RkuLSLWVjHOVHXbz+tMVt996dbkhhEp3yiWPJhWXWCxwvw@mail.gmail.com>
References: <20111031211134.8188.49554.idtracker@ietfa.amsl.com> <4EAF64FF.8020101@jesup.org> <CAEW_RkuLSLWVjHOVHXbz+tMVt996dbkhhEp3yiWPJhWXWCxwvw@mail.gmail.com>
Date: Thu, 3 Nov 2011 17:09:57 -0700
Message-ID: <CAEW_Rkt_wzEMcHM8C+-+yyWXod__p_urLxptSPd0MNj5wf6FNw@mail.gmail.com>
From: Ralph Giles <giles@thaumas.net>
To: rtcweb@ietf.org
Content-Type: multipart/mixed; boundary=20cf307cffa685ead504b0dd860a
Subject: [rtcweb] Fwd: New Version Notification for draft-jesup-rtcweb-data-01.txt
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 04 Nov 2011 00:10:38 -0000

Oops, forgot to cc the list.


---------- Forwarded message ----------
From: Ralph Giles <giles@thaumas.net>
Date: 3 November 2011 17:09
Subject: Re: [rtcweb] New Version Notification for
To: Randell Jesup <randell-ietf@jesup.org>

On 31 October 2011 20:18, Randell Jesup <randell-ietf@jesup.org> wrote:

> A new version of I-D, draft-jesup-rtcweb-data-01.txt has been successfully
> submitted by Randell Jesup and posted to the IETF repository.

Some feedback on the draft, more editorial than technical.

Please see the attached patch for a number of formatting, spelling,
grammar and wording improvements. I don't think any of these change
meaning, but if you want a more granular report, you can pull my edit
history from http://thaumas.net/~giles/git/draft-foo.git. Or ask and I
can send separate patches.

Note that there are two 'Req. 10's. I didn't fix that because
renumbering makes it harder to discuss the draft, that they should be
updated before publishing another.

More content-oriented comments:

In Req. 1, the wording is a little unclear. Is it the media streams,
data streams, or both which MUST be able to change at any time?

In Req. 7 and 10 (the first one), I worry that referring specifically
to javascript may end up dated and/or too browser-centric. Can we just
refer to application or webapp? There are places where the distinction
between the user-agent and the content which is requesting the call is
important, but I'm not sure javascript's ubiquity as a vehicle for the
later is relevant.

For example:

[Req. 7] Data streams MUST provide message fragmentation support such
that IP-layer fragmentation does not occur no matter how large a
message or buffer the application passes to the Browser for

[Req. 10] The data stream packet format/encoding MUST be such that it
is impossible for a malicious applications to generate a crafted
message which would be interpreted as another native protocol over UDP
- such as UPnP, RTP, SNMP, STUN, etc.

In the "User Space vs Kernel implementation" section, you talk about
deployability, but not about the relative difficulty of implementing
SCTP-on-DTLS vs DTLS-on-SCTP with current kernel stacks. At least a
reference to the discussion lower down (section 5.2) would be helpful
here, I think.

In turn, that section, "User Space vs Kernel implementation," rather
assumes the solution. That might be fine, but instead of saying it
must be possible to implement SCTP and DTLS in user space, you could
rather say, "It MUST be possible to implement the data protocol
without increasing the footprint for system-level calls, i.e. using
UDP sockets."

Since browser vendors support a small handful of platforms, but that's
a poorly defined notion, I suggest this actually be a SHOULD. E.g. do
we know if other browsers currently have sufficient access to UDP to
implement even RTP? We can get the meaning across with less rigid

Thanks for putting the draft together,