Re: [rtcweb] Data Channels Proposal: Now in Internet Draft Form

Hi Martin, thanks for your proposal. I have some comments/questions:

1. So the label locally assigned to a data channel created in-band is not transmitted to the peer ? (note that I am fine with this)

2. Whereas defaulting properties like order or reliability is more or less OK, it seems more critical to default the subprotocol property. The app would have to parse the incoming user message to guess if this message is about 'chat' or 'file transfer'

3. Why does StreamID need to be exposed to the app ? I first thought it was to allow in-band data channel creation by a simple message sending. But then:
- either the StreamID is a parameter of send(streamID, data) - and this breaks the alignment with WebSocket API and also the app has no handle on this data channel 
- or streamID is a parameter of createDataChannel and this seems useless as the browser is able to select a new stream number internally

4.  Why does binaryPPID need to be exposed to the app ? The browser is expected to infer the message type from the data passed to send().

5. Finally to decrease the number of mismatching properties situations, you could simply assign a "Default=strict|loose" property to one of the data channels in the SDP.
If set to "strict", endpoints could only create in-band data channels for which the default set of properties applies. To create other types of data channels in-band, renegotiation is required
If set to "loose'", an endpoint receiving a user message on an closed data channel would open the data channel using these default properties. But with the risk of mismatch on subprotocol...
This would make scalable setup scenarios like:
- the SDP offer/answer exchange negotiates one 'chat' data channel, and one 'file transfer' Default data channel
- later on, either endpoint creates in-band 100 data channels for file transfer -> no renegotiation needed, no property mismatch.

This reduces the mismatching situations, in the case where one single set of properties is mostly used at a given time in the session. But the browser (or the app) has to guess at the time of SDP negotiation which set of properties should be the default, i.e. will be used more frequently than the others later on in the session. 

An extended (and deterministic) approach is to restrict the role of SDP offer/answer to the negotiation of some identified set of properties (not data channels). Then data channels are created in-band by the sending of user messages on closed streams, where each user message includes a "set of properties" identifier. You may have a look at the draft I have submitted.

Jerome

> -----Message d'origine-----
> De : rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] 
> De la part de Martin Thomson
> Envoyé : lundi 18 février 2013 18:52
> À : rtcweb@ietf.org
> Objet : [rtcweb] Data Channels Proposal: Now in Internet Draft Form
> 
> I think that we're actually at the point where the involved 
> parties each understand each other's positions.  Now comes 
> the time to provide everyone else with a coherent proposal 
> that they can evaluate.
> 
> http://tools.ietf.org/html/draft-thomson-rtcweb-data-00
> 
> This is intended as an alternative to the mechanisms in 
> draft-ietf-rtcweb-data-channel.  It is also intended to 
> render draft-jesup-rtcweb-data-protocol unnecessary.  That 
> is, of course, as long as it meets with the approval of the 
> working group.
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
> 