Subject: [rtcweb] Comments on draft-ietf-rtcweb-data-channel-07

From: Paul Kyzivat <[email-masked]>
Date: Sat, 22 Feb 2014 19:20:06 -0500

(Catching up before the meeting)
Here are some comments on the latest version. There don't necessarily 
relate to recent changes. Rather they come from my perspective trying to 
use this for CLUE, whether using a webrtc endpoint or not.

* Section 5:

This section says:

    Each SCTP user message contains a so called Payload Protocol
    Identifier (PPID) that is passed to SCTP by its upper layer and sent
    to its peer.  This value can be used to multiplex multiple protocols
    over a single SCTP association.  The sender provides for each
    protocol a specific PPID and the receiver can demultiplex the
    messages based on the received PPID.  The PPID is used to distinguish
    UTF-8 encoded user data and binary encoded userdata.  The Data
    Channel Establishment Protocol defined in
    [I-D.ietf-rtcweb-data-protocol] uses also a specific PPID to be
    distinguished from user data.

The language has proved extremely confusing to several people who 
haven't followed the development and discussion of this from the 
beginning. It is because of the extreme ambiguity in the use of 
"protocol". While I guess we can't rename PPID, the other language could 
be clarified.

The problem is that we have SCTP protocol, "WebRTC Data Channel 
Establishment Protocol", and within the DATA_CHANNEL_OPEN message of the 
WebRTC Data Channel Establishment Protocol we have a "Protocol" field.

We also have layering of protocols and implementations. So it isn't 
clear above who "sender" and "receiver" above apply to. (Could be code 
that is calling the SCTP stack, or code that is calling the "data 
channel stack", or the browser, or a javascript application on top of 
browser.

IIUC, javascript users don't have any visibility to the PPID. But others 
implementing data channels may.

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.

Also in this section is Figure 2 that shows layering. I'm unclear if 
"WEBRTC DATA" in intended to include rtcweb-data-protocol or not. That 
is defined in a separate draft, is mandatory to support but optional to 
use. So it could go either way. Might be good to clarify:

                  +---------+
                  |CHANNEL  |
                  |PROTOCOL |
                  +---------+
                  |DATA     |
                  |CHANNEL  |
                  +---------+
                  | SCTP    |
    +-----------------------+
    | STUN | SRTP | DTLS    |
    +-----------------------+
    |         ICE           |
    +-----------------------+
    | UDP1 | UDP2 | ...     |
    +-----------------------+

* 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?)

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

	Thanks,
	Paul