Re: [rtcweb] Open data channel issues

[Michael Tuexen <[e-mail]>]

On 26 Feb 2014, at 21:02, Randell Jesup <[e-mail]> wrote:

> On 2/26/2014 2:50 PM, Paul Kyzivat wrote:
>> Michael,
>> 
>> There have been no replies to my comments:
>> 
>> http://www.ietf.org/mail-archive/web/rtcweb/current/msg11518.html
>> http://www.ietf.org/mail-archive/web/rtcweb/current/msg11519.html
>> 
>> The first of those is about channels, the 2nd about DCEP. One of my issues is that the partitioning between those two drafts is awkward. At the least some things from DCEP should be moved to the channel draft. It might be better to just merge those two drafts, or do a serious refactoring.
> 
> There seem to have been a number of responses to your second posting at least.
> 
>> How about:
> 
>   Each SCTP user message contains a so called Payload Protocol
>   Identifier (PPID) that is passed to SCTP by the data channel layer
>   and sent to its peer.  This value is used to multiplex WebRTC Data
>   Channel Establishment Protocol messages (defined in [I-D.ietf-rtcweb-
>   data-protocol]) with messages containing user data on a data
>   channel. The PPID is also used to distinguish UTF-8 encoded user
>   data and binary encoded user data.
> 
> That seems reasonable and clearer.
> 
> 
>> * Section 6.5
>> 
>> This section contains:
> 
>   Data channels can be opened by using internal or external
>   negotiation.  The details are out of scope of this document.
> 
>   A simple protocol for internal negotiation is specified in
>   [I-D.ietf-rtcweb-data-protocol] and MUST be supported.
> 
>> But internal and external negotiation are not defined in this document.
>> 
> 
> > I *thought* that internal negotiation was by definition negotiation by use of
> > rtcweb-data-protocol. (draft-ejzak-mmusic-data-channel-sdpneg-00 thinks so too,
> > but calls it "in-band negotiation".) There should be a good definition of these
> > terms, or reference to one. And more discussion if there can be other kinds of
> > internal negotiation. (If so, how would one be chosen?)
> 
> Well, the text above says that ietf-rtcweb-data-protocol specifies an internal negotiation protocol,
> so it's not that far off.  The split does allow someone to use an alternative negotiation protocol
> (internal or external).
> 
> How about:
> 
>   Data channels can be opened by using negotiation within the SCTP association or external
>   negotiation.  External negotiation is defined as any method which results in an agreement
>   as to the parameters of a channel and the creation thereof.
>   The details are out of scope of this document.
> 
>   A simple protocol for negotiation within the SCTP association is specified in
>   [I-D.ietf-rtcweb-data-protocol] and MUST be supported.
> 
> 
> Perhaps someone can wordsmith "external negotiation" better.
Taken, but with in-band and out-of-band...
> 
> 
>> * Section 6.6:
>> 
>> Say:
> 
>   All data sent on a Channel in both directions MUST be sent over the
>   underlying stream using the reliability defined when the Channel was
>   opened unless the options are changed, or per-message options are
>   specified by a higher level.
> 
> > Is the recipient to consider it an error if messages are received with options different from those
> > defined for the channel? Also, is it an error if messages are received with a PPID that isn't specified
> > in Section 8? (And what about PPID 50?)
> 
>> How are such channel errors to be treated?
> 
> 
> I'd propose that if messages are received with options that don't match the initial definition, that fact should be ignored and the message processed.
> If messages with an unknown PID are received, those messages should be ignored.
I'll bring that up at the WebRTC session.

Best regards
Michael
> 
> In both cases, logging of such an event to the application (or onerror calls in WebRTC W3 JS layers) is allowed but not required. Note that the onerror callback is currently under-defined, so this might change.
> 
> -- 
> Randell Jesup -- rjesup a t mozilla d o t com
> 
> _______________________________________________
> rtcweb mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/rtcweb
>