Re: [rtcweb] TR : New Version Notification for draft-marcon-rtcweb-data-channel-management-00.txt

Thanks Randell for you review. My replies inline. 

> -----Message d'origine-----
> De : rtcweb-bounces@ietf.org [mailto:rtcweb-bounces@ietf.org] 
> De la part de Randell Jesup
> Envoyé : mardi 19 février 2013 07:49
> À : rtcweb@ietf.org
> Objet : Re: [rtcweb] TR : New Version Notification for 
> draft-marcon-rtcweb-data-channel-management-00.txt
> 
> On 2/18/2013 7:07 PM, MARCON, JEROME (JEROME) wrote:
> > Hi,
> >
> > I have submitted a draft proposing a new way of setting up 
> data channels, based on the concept of data channel 
> configurations. It uses a lightweight SDP signaling coupled 
> with a lightweight in-band signaling (not an in-band 
> protocol). I think it can handle efficiently the most 
> demanding setup scenarios. The proposal is besides designed 
> with the intent to not impact on current browser API.
> 
> Thanks.  Still reading, but an initial comment:
> 
> "Whenever the application creates a new data channel, the 
> browser internally checks if the passed set of parameters 
> strictly matches an existing configuration, and if not 
> generates a new configuration identifier for this set. In the 
> latter case only does the browser trigger the application for 
> an SDP renegotiation."
> 
> Wouldn't this occur on almost every channel because of label 
> values?  Or are you assuming applications won't actually use labels?

In this first version of the proposal, the use of labels is still undefined, but (for the sale of scalability) it would for now remain a local data channel property not transmitted to the peer (should this local property be useful to something).

I would appreciate some clarifications on the usefulness of labels in the context of data channels. W3C says nothing about it. Probably - if transmitted to the peer - it can assist the user consent decision. But then assuming the offer is for opening 100 data channels for file transfer (each channel with a distinct label), would the answerer's consent be asked 100 times (once per distinct label) ? Probably asking once "do you agree on some file transfers" is enough (and better). And the 'file transfer' information is carried by the subprotocol property, not the label.     

> 
> "For each data channel configuration in the offer that is 
> accepted by the answerer, the answerer echoes in the answer 
> the configurations supported and accepted. Once the offerer 
> receives the answer and (in case of an initial offer) the 
> SCTP initialization is complete, each data channel locally 
> created using one of the accepted configurations is signaled 
> to the application as open for transmission."
> 
> There's a bunch of API to surface here in order to support 
> O/A ("for each ... that is accepted by the answerer...").
> 
> "By convention, the inbound and outbound streams of a data 
> channel have the same SCTP stream number. This stream number 
> is selected by the first endpoint sending a user message on 
> this channel. Till this happens, an open data channel has no 
> assigned stream number."
> 
> How do you handle glare? (i.e. both sides start to send on 
> stream 5 at the same time)
> 
There are two methods proposed in section 6.5. You seem to be supportive of the 2nd method (even/odd stream number ownership convention).

> "Data channel messages are sent as SCTP user messages, 
> preceded in the DATA chunk User Data field by two bytes 
> specifying data channel configuration identifier as well as 
> the message data framing type (textual or binary)."
> 
> Aha.  So you've moved this into a true inband protocol with 
> data framing.  The current draft sends data messages with no 
> added framing required.

Please explain why data framing is an issue. WebSocket protocol does this. The proposal also only reserves a unique PPID for the entire RTCWeb data channel functionality. Personally, I find it ackward to reserve a PPID for something like "plain transmission of any binary data or UTF-8 stream". It seemed to me that each PPID today registered with IANA is identifying a true self-contained protocol. 

> 
> --
> Randell Jesup
> randell-ietf@jesup.org
> 
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
> 