[rtcweb] Comments on draft-ietf-rtcweb-data-channel-07
Paul Kyzivat <pkyzivat@alum.mit.edu> Sun, 23 February 2014 00:20 UTC
Return-Path: <pkyzivat@alum.mit.edu>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B11E71A0213 for <rtcweb@ietfa.amsl.com>; Sat, 22 Feb 2014 16:20:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.235
X-Spam-Level:
X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_SOFTFAIL=0.665] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9ATzmDkjlh7q for <rtcweb@ietfa.amsl.com>; Sat, 22 Feb 2014 16:20:12 -0800 (PST)
Received: from qmta15.westchester.pa.mail.comcast.net (qmta15.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:228]) by ietfa.amsl.com (Postfix) with ESMTP id AF73F1A020F for <rtcweb@ietf.org>; Sat, 22 Feb 2014 16:20:11 -0800 (PST)
Received: from omta04.westchester.pa.mail.comcast.net ([76.96.62.35]) by qmta15.westchester.pa.mail.comcast.net with comcast id VcFV1n0050ldTLk5FcL6Me; Sun, 23 Feb 2014 00:20:06 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta04.westchester.pa.mail.comcast.net with comcast id VcL61n00M3ZTu2S01cL6Ny; Sun, 23 Feb 2014 00:20:06 +0000
Message-ID: <53093EB6.5080500@alum.mit.edu>
Date: Sat, 22 Feb 2014 19:20:06 -0500
From: Paul Kyzivat <pkyzivat@alum.mit.edu>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.3.0
MIME-Version: 1.0
To: "rtcweb@ietf.org" <rtcweb@ietf.org>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1393114807; bh=JAqBtS+m6Ro8KnA6bWEbf/9NqwELCLM7nrEwXBcnAkA=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=GohEMtF9eMUnobd6NwCQSP1vrJEtTIJaCyfRv8pTtd39td5a44C6rQC73qnRfmWy/ oPifg4+VoXcjR4cXE5avq1mHh7n6/cuwzq+7uQwXs/e4YH1vEvg45bb3Dc1cGPzeo9 dx4GmIWwBdfgyqYW9B3eIEaIEh2fvDlaOILbeEzz5Cqc/hb2BWb+TQZXSP0VGoyJqK PhExgo1eph6aLDHHEpmCA7u+HFb34v8VA+LoLkymzE/QP36orXsExzes8K8anaCRp8 +LsURpzqT3KjchVGLAYXcLRoySZKeL9GbvYTwXcConHTs+K39CmU15dnKMx785xFJJ Ezp6YYylkvHJg==
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/HFf-OY4P4ke8iTsdxAvgsfaEbk0
Subject: [rtcweb] Comments on draft-ietf-rtcweb-data-channel-07
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb/>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 23 Feb 2014 00:20:14 -0000
(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
- [rtcweb] Comments on draft-ietf-rtcweb-data-chann… Magnus Westerlund
- [rtcweb] Comments on draft-ietf-rtcweb-data-chann… Paul Kyzivat
- Re: [rtcweb] Comments on draft-ietf-rtcweb-data-c… Barry Dingle
- Re: [rtcweb] Comments on draft-ietf-rtcweb-data-c… Magnus Westerlund
- Re: [rtcweb] Comments on draft-ietf-rtcweb-data-c… Barry Dingle
- Re: [rtcweb] Comments on draft-ietf-rtcweb-data-c… Randell Jesup
- Re: [rtcweb] Comments on draft-ietf-rtcweb-data-c… Michael Tuexen
- Re: [rtcweb] Comments on draft-ietf-rtcweb-data-c… Michael Tuexen
- Re: [rtcweb] Comments on draft-ietf-rtcweb-data-c… Michael Tuexen
- Re: [rtcweb] Comments on draft-ietf-rtcweb-data-c… Michael Tuexen