[rtcweb] Comments on draft-ietf-rtcweb-data-protocol-01
Magnus Westerlund <magnus.westerlund@ericsson.com> Tue, 12 November 2013 13:44 UTC
Return-Path: <magnus.westerlund@ericsson.com>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1229221E80D3 for <rtcweb@ietfa.amsl.com>; Tue, 12 Nov 2013 05:44:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.552
X-Spam-Level:
X-Spam-Status: No, score=-105.552 tagged_above=-999 required=5 tests=[AWL=0.697, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x-tehkLRRWAI for <rtcweb@ietfa.amsl.com>; Tue, 12 Nov 2013 05:44:45 -0800 (PST)
Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 4593111E8140 for <rtcweb@ietf.org>; Tue, 12 Nov 2013 05:44:45 -0800 (PST)
X-AuditID: c1b4fb2d-b7f1c8e000005ceb-a0-528230cbdd98
Received: from ESESSHC009.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 3E.07.23787.BC032825; Tue, 12 Nov 2013 14:44:44 +0100 (CET)
Received: from [127.0.0.1] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.47) with Microsoft SMTP Server id 14.2.328.9; Tue, 12 Nov 2013 14:44:43 +0100
Message-ID: <52823111.9010701@ericsson.com>
Date: Tue, 12 Nov 2013 14:45:53 +0100
From: Magnus Westerlund <magnus.westerlund@ericsson.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:24.0) Gecko/20100101 Thunderbird/24.1.0
MIME-Version: 1.0
To: draft-ietf-rtcweb-data-protocol@tools.ietf.org, "rtcweb@ietf.org" <rtcweb@ietf.org>
X-Enigmail-Version: 1.6
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrDJMWRmVeSWpSXmKPExsUyM+Jvre4Zg6Ygg2k7eSxWH97LZrH2Xzu7 A5PHkiU/mTy+XP7MFsAUxWWTkpqTWZZapG+XwJWxdMUkpoInChW3Gt+xNjDulexi5OSQEDCR 6Lt9lBHCFpO4cG89WxcjF4eQwCFGidXzDzBDOMsZJabd3skEUsUroC2x/cx/VhCbRUBV4sj7 O+wgNpuAhcTNH41sILaoQLDE+VeL2SHqBSVOznzCAmKLCERLvF33EqxGWMBcYs6NDUBzOIA2 i0v0NAaBhJkF9CSmXG1hhLDlJZq3zmYGsYWA1jY0dbBOYOSfhWTqLCQts5C0LGBkXsXInpuY mZNebriJERhiB7f81t3BeOqcyCFGaQ4WJXHeD2+dg4QE0hNLUrNTUwtSi+KLSnNSiw8xMnFw SjUwmp8R/X47dENS3WfZk7s3//Trd14Y8lw46ofYwreTPKrPsgjsmu/edudp36rdH+QPLCha PUe3ttZMLFFXyvGYgcf2t/ZvpuySk10qMzn9lirz7ptv1eTfsBzlF7NeYL/5k5act4hV9hTr hqj1/N3fzYQm7267xxgkkyg5oeebVMiC7aKRtppGSizFGYmGWsxFxYkAo8ZY4P8BAAA=
Subject: [rtcweb] Comments on draft-ietf-rtcweb-data-protocol-01
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
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: Tue, 12 Nov 2013 13:44:52 -0000
Hi, I did review the Data Channel Protocol on my way to IETF, and here are my comments. 1. Section 4: o the outgoing SCTP stream. What about incoming SCTP stream? 2. Section 4: The data channel protocol uses a two way handshake to open a data channel. The side wanting to open a data channel selects an unused Stream and sends a DATA_CHANNEL_OPEN message. The peer responds with a DATA_CHANNEL_ACK message. Then the data channel is open. Please note that the opening side can send user messages before the DATA_CHANNEL_ACK is received. These data channel messages are sent on the same Stream as the user messages belonging to the data channel. The demultiplexing is based on the SCTP payload protocol identifier. I find this paragraph a bit confusing on the following things: A. Is the DATA_CHANNEL_OPEN message sent on that selected stream? B. Is the DATA_CHANNEL_ACK sent on the peers corresponding stream number as the DATA_CHANNEL_OPEN was received on? C. "These data channel messages" does this refer to DATA_CHANNEL_OPEN/ACK, maybe be more explicit. D. "The demultiplexing is based on the SCTP payload protocol identifier." Do you mean PPIDs here. And could you be more explicit about of how this works. Am I wrong in the understanding that you have have one PPID for this control protocol. But, you are not explicit about if which PPID user messages could use. 3. Section 4: The protocol field is to ease cross-application interoperation ("federation") by identifying the data being passed with an IANA- registered string, and may be useful for homogenous applications which may create more than one type of Channel. One more case where I think it is fuzzy what is refered to. Is the "protocol field" an identifier for the PPID to use, or something else? What type of IANA registered string is being used here? Which registry and field value are referenced? 4. Section 5.1: Priority: 2 bytes (integer) The priority of the channel. What is the definition of the priority field value? 5. Section 5.1: Reliability Parameter: 4 bytes I would recommend that you make a table under this parameter where you make clear the interpretation of the field under differetn channel types. 6. Section 5.1 Protocol: Variable Length (sequence of characters) The protocol for the channel. This may be an empty string. If used, it is an IANA-registered protocol (see Section 8.4). Can you please be explicit about which IANA registry that is relevant here. What is the meaning of an empty string? 7. Section 6. What PPID shall be used when sending the user data? 8. Section 6. Therefore, receiving an SCTP stream reset request for a stream on which no DATA_CHANNEL_ACK message has been received indicates to the sender of the corresponding DATA_CHANNEL_OPEN message the failure of the data channel setup procedure. What is allowed to do after having received the reset on a DATA_CHANNEL_OPEN? Can one try to send a new OPEN? 9. Section 8.2: | Reserved | 0x00 | [RFCXXXX] | | Reserved | 0x01 | [RFCXXXX] | Why is these values reserved, please include the motivation for this in the description of the registry. 10. Section 8.4: IANA is requested to create a new registration table "Protocol Registry" for the data channel protocol to manage the "Protocol" field of type string in DATA_CHANNEL_OPEN messages (see Section 5.1). "Protocol Registry" is a lousy name on a registry. Secondly, I think the purpose of this registry needs to be better described. Cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ----------------------------------------------------------------------
- [rtcweb] Comments on draft-ietf-rtcweb-data-proto… Magnus Westerlund
- Re: [rtcweb] Comments on draft-ietf-rtcweb-data-p… Michael Tuexen