Re: [rtcweb] Open data channel issues

[Randell Jesup <[e-mail]>]

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.


> * 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.

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