DataChannel edits/questions from Dan

Answers to the DataChannels issues we didn't get to last night:

"If both the maxRetransmitTime and maxRetransmits attributes are set 
(not null), then throw a SyntaxError exception and abort these steps."
Should there be any limits on these values other than being unsigned 
short integers?

REJ: unsigned 32-bit integers

"If the value of the protocol attribute fails to match the requirements 
of the WebRTC DataChannel Protocol specification, then throw a 
SyntaxError exception and abort these steps."
IS THIS DETAILED ENOUGH? It seems underspecified to me. For example, it 
might be nice to get a useful message about what's wrong with the 
protocol setting.

REJ: Since this isn't expected to be processed by the browsers; it's 
handled by the applications. In IETF land, we need to expand it from 
IANA-registered to IANA-registered plus params in the normal form 
(;x=y;q=w;etc) This will be changed in the IETF. Recommendation: remove, 
or limit to gross errors like string too long.

"if the value of the id attribute is taken by an existing 
RTCDataChannel, throw a TBD exception and abort these steps."
Simple proposal: throw an "IDInUse" exception. The text should probably 
clarify that this only occurs for a non-negotiated channel or for a 
negotiated one that has already been negotiated.

REJ: "only occurs when asking for a negotiated channel with an id= value 
that either already is in use by an internally-negotiated channel or a 
different existing externally negotiated channel.


The spec says "When a RTCDataChannel object's underlying data transport 
has been closed, . . . If the transport was closed with an error, fire 
an error event at channel." This is way way underspecified. What kinds 
of transport errors can occur? Which might matter to JS developers?

REJ: Failure of the underlying DTLS channel (ICE/restart/etc failure). I 
can't see any reasons for distinguishing these errors.

binaryType attribute, section 5.2.1

The spec currently allows arbitrary DOMString values. Is that what we 
want? What entries might be invalid, and should we return an error for them?
Simple proposal: Yes, throw a SyntaxError exception for illegal values.

REJ: Sure. Check to see what WebSockets does!

protocol attribute, section 5.2.1

The spec currently allows arbitrary DOMString values. Is that what we 
want? What entries might be invalid, and should we return an error for them?
Simple proposal: Yes, throw a SyntaxError exception for illegal values.

REJ: Maps to underlying IANA registry, suggestion from Lennox to add 
parameters to the protocols in the "standard" form (or maybe arbitrary 
string). I'm not sure there are any illegal values.

send, section 5.2.2

If the channel was created by the remote peer in negotiated form, there 
might be a data connection that we can receive from but not send to. 
Thus, send() might not work. I'm not sure what to do here, but perhaps 
an exception is appropriate.

REJ: Not sure this is possible

"If channel's readyState attribute is 'connecting', throw an 
InvalidStateError exception and abort these steps."

"Attempt to send data on channel’s underlying data transport; if the 
data cannot be sent, e.g. because it would need to be buffered but the 
buffer is full, the user agent must abruptly close channel’s underlying 
data transport with an error."
This implies that Data channel sends are synchronous. Is that correct? 
Also, the error needs to be defined. Simple proposal: "sendFailure" 
exception.

REJ: Hmmmm. I'm not so certain about the "eg" portion, though it mirrors 
the language in the WebSockets spec. However, you can make a 2GB send 
(or receive) using WebSockets, so I'm not sure this description maps to 
how browsers implement this.

We should use the same error as WebSockets in this case. And the 
"abruptly close" language applies better to WebSockets and the single 
connection/stream than to DataChannels. And it's not clear what errors 
would really cause this, but in any case it should only close the 
DataChannel, not the "underlying transport" (which is confusing in this 
usage).

-- 
Randell Jesup
randell-ietf@jesup.org

Received on Tuesday, 12 November 2013 00:30:19 UTC