Re: [rtcweb] Open data channel issues

[Paul Kyzivat <[e-mail]>]

On 2/26/14 4:02 PM, Randell Jesup 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.

Well - *one*, and my reply. My mistake - I lost track, and only checked 
the first one when I sent this. :-(

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

Thanks.

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

ISTM the issue is that Internal vs. External isn't the key distinction. 
What is key is that there is one method that MUST be *supported* but 
need not be the only one used. Other mechanisms may be used. It doesn't 
really matter whether they are conducted internally (over the SCTP 
association) or externally (anything else).

E.g., I could use DCEP to establish one channel, and then use my own 
private protocol over that to negotiate other channels. Would that be 
internal or external negotiation? Does it matter?


>> * 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 could live with that. It comes to a philosophical issue of whether you 
want to fail soft or fail hard.

Could just explicitly say that behavior when the per-message SCTP 
parameters are inconsistent with the channel is nonconformant to this 
specification and undefined. And that behavior when PPIDS other than 50, 
51, and 54 (did I remember right?) are used is also nonconformant and 
undefined.

Note that the current partitionion makes it hard to specify conforming 
use of PPID 50. From a channel perspective you can use it, but from a 
DCEP perspective you can only use it a certain way.

(This would be easier if the two were merged. Since DCEP is mandatory to 
implement, there seems little reason to keep them separate.

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

If there is a goal to report errors in a defined way then that would 
change things.

	Thanks,
	Paul