Re: [rtcweb] Open data channel issues
Randell Jesup <randell-ietf@jesup.org> Wed, 26 February 2014 21:03 UTC
Return-Path: <randell-ietf@jesup.org>
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 7AD4B1A071D for <rtcweb@ietfa.amsl.com>; Wed, 26 Feb 2014 13:03:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.8
X-Spam-Level:
X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham
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 lxstObzqJTti for <rtcweb@ietfa.amsl.com>; Wed, 26 Feb 2014 13:03:23 -0800 (PST)
Received: from r2-chicago.webserversystems.com (r2-chicago.webserversystems.com [173.236.101.58]) by ietfa.amsl.com (Postfix) with ESMTP id 0A1561A0718 for <rtcweb@ietf.org>; Wed, 26 Feb 2014 13:03:22 -0800 (PST)
Received: from pool-71-175-4-197.phlapa.fios.verizon.net ([71.175.4.197]:2457 helo=[192.168.1.12]) by r2-chicago.webserversystems.com with esmtpsa (TLSv1:DHE-RSA-AES256-SHA:256) (Exim 4.82) (envelope-from <randell-ietf@jesup.org>) id 1WIldR-0004WR-6e for rtcweb@ietf.org; Wed, 26 Feb 2014 15:03:21 -0600
Message-ID: <530E564B.9070103@jesup.org>
Date: Wed, 26 Feb 2014 16:02:03 -0500
From: Randell Jesup <randell-ietf@jesup.org>
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: rtcweb@ietf.org
References: <31B9253D-E826-4D07-A8A1-1B062B50F163@lurchi.franken.de> <530E4568.6090402@alum.mit.edu>
In-Reply-To: <530E4568.6090402@alum.mit.edu>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - r2-chicago.webserversystems.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - jesup.org
X-Get-Message-Sender-Via: r2-chicago.webserversystems.com: authenticated_id: randell@jesup.org
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/zeVtdmX7LBy2N2ooCz4GPmJtteA
Subject: Re: [rtcweb] Open data channel issues
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: Wed, 26 Feb 2014 21:03:29 -0000
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
- [rtcweb] Open data channel issues Michael Tuexen
- Re: [rtcweb] Open data channel issues Magnus Westerlund
- Re: [rtcweb] Open data channel issues Michael Tuexen
- Re: [rtcweb] Open data channel issues Paul Kyzivat
- Re: [rtcweb] Open data channel issues Randell Jesup
- Re: [rtcweb] Open data channel issues Paul Kyzivat
- Re: [rtcweb] Open data channel issues Christer Holmberg
- Re: [rtcweb] Open data channel issues Paul Kyzivat
- Re: [rtcweb] Open data channel issues Randell Jesup
- Re: [rtcweb] Open data channel issues Justin Uberti
- Re: [rtcweb] Open data channel issues Randell Jesup
- Re: [rtcweb] Open data channel issues Martin Thomson
- Re: [rtcweb] Open data channel issues Michael Tuexen
- Re: [rtcweb] Open data channel issues Michael Tuexen
- Re: [rtcweb] Open data channel issues Martin Thomson
- Re: [rtcweb] Open data channel issues Martin Thomson
- Re: [rtcweb] Open data channel issues Stefan HÃ¥kansson LK
- Re: [rtcweb] Open data channel issues Martin Thomson
- Re: [rtcweb] Open data channel issues Justin Uberti
- Re: [rtcweb] Open data channel issues Randell Jesup
- Re: [rtcweb] Open data channel issues Randell Jesup
- Re: [rtcweb] Open data channel issues Justin Uberti
- Re: [rtcweb] Open data channel issues Randell Jesup
- Re: [rtcweb] Open data channel issues Justin Uberti
- Re: [rtcweb] Open data channel issues Martin Thomson
- Re: [rtcweb] Open data channel issues Michael Tuexen
- Re: [rtcweb] Open data channel issues Karl Stahl
- Re: [rtcweb] Open data channel issues Randell Jesup
- Re: [rtcweb] Open data channel issues Michael Tuexen
- Re: [rtcweb] Open data channel issues Martin Thomson
- Re: [rtcweb] Open data channel issues Justin Uberti
- Re: [rtcweb] Open data channel issues Makaraju, Maridi Raju (Raju)
- Re: [rtcweb] Open data channel issues Michael Tuexen
- Re: [rtcweb] Open data channel issues Randell Jesup
- Re: [rtcweb] Open data channel issues Martin Thomson
- Re: [rtcweb] Open data channel issues Randell Jesup
- Re: [rtcweb] Open data channel issues Michael Tuexen
- Re: [rtcweb] Open data channel issues Randell Jesup
- Re: [rtcweb] Open data channel issues Martin Thomson
- Re: [rtcweb] Open data channel issues Makaraju, Maridi Raju (Raju)
- Re: [rtcweb] Open data channel issues Makaraju, Maridi Raju (Raju)