Subject: Re: [rtcweb] WGLC for data channel drafts - web terminology

From: Christer Holmberg <[email-masked]>
Date: Tue, 10 Jun 2014 19:42:30 +0000

Hi,

A comment (which has been raised before) on draft-ietf-rtcweb-data-channel-10:

The name of the mechanism is "WebRTC Data Channel", and much of the text gives a picture that the mechanism is only to be used within the WebRTC context.

If we want to call it "WebRTC Data Channel", we should make it clear that WebRTC is only one scenario where it can be used, but that it can also be used elsewhere. For example, we are using it in CLUE.

A few places, where I think we need modifications to reflect it.

Section 3:

------------

Q3_1: s/For general use cases see [I-D.ietf-rtcweb-use-cases-and-requirements]./For WebRTC use cases see [I-D.ietf-rtcweb-use-cases-and-requirements].

Q3_2: In sections 3.1 and 3.2, there are a number of WebRTC specific requirements, and "PeerConnection", "JavaScript" etc terminology is used. I think it should be clear that those requirements come from WebRTC.

Section 5:

------------

Q5_1: I suggest to replace:

    "SCTP multihoming will not be used in WebRTC."

...with something like:

    "The WebRTC Data Channel mechanism does not support SCTP multihoming."

Section 6:

------------

Q6_1: In section 6.2, the follwoing sentence:

  "The SCTP association will be set up when the two endpoints of the
   WebRTC PeerConnection agree on opening it, as negotiated by JSEP
   (typically an exchange of SDP) [I-D.ietf-rtcweb-jsep]."

...only applies to WebRTC. But, it needs to be clear that, in other contexts, other mechanisms can be used.

Q6_2: In section 6.4, I suggest to re-order the paragraphs in the following way:

   "The realization of a bidirectional Data Channel is a pair of one
   incoming stream and one outgoing SCTP stream having the same stream
   SCTP identifier.

   How stream values are selected is protocol and implementation
   dependent.

   Each data channel also has a priority, which is an 2 byte unsigned
   integer value.  These priorities MUST be interpreted as weighted-
   fair-queuing scheduling priorities per the definition of the
   corresponding stream scheduler supporting interleaving in
   [I-D.ietf-tsvwg-sctp-ndata].  For use in WebRTC, the values used
   SHOULD be one of 128 ("below normal"), 256 ("normal"), 512 ("high")
   or 1024 ("extra high").

   The W3C has consensus on defining the application API for WebRTC
   DataChannels to be bidirectional.  They also consider the notions of
   in-sequence, out-of-sequence, reliable and unreliable as properties
   of Channels.  One strong wish is for the application-level API to be
   close to the API for WebSockets, which implies bidirectional streams
   of data and waiting for onopen to fire before sending, a textual
   label used to identify the meaning of the stream, among other things."

...because, the realization is the important part :)

Regards,

Christer

________________________________
From: rtcweb [[email-masked]] on behalf of Ted Hardie [[email-masked]]
Sent: Tuesday, 10 June, 2014 9:52 PM
To: [email-masked]
Subject: [rtcweb] WGLC for data channel drafts

Dear WG,

This starts a working group last call for our core Data Channel drafts:

draft-ietf-rtcweb-data-protocol-06.txt
draft-ietf-rtcweb-data-channel-10.txt

Please review them in detail, especially for areas which may be of concern to the broader IETF community.  This WGLC will end on June 27, 2014.

Ted, Sean, Cullen