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

[Ralph Giles <[e-mail]>]

Oops, forgot to cc the list.

 -r


---------- Forwarded message ----------
From: Ralph Giles <[e-mail]>
Date: 3 November 2011 17:09
Subject: Re: [rtcweb] New Version Notification for
draft-jesup-rtcweb-data-01.txt
To: Randell Jesup <[e-mail]>


On 31 October 2011 20:18, Randell Jesup <[e-mail]> 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
transmission.

[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
language.

Thanks for putting the draft together,
 -r