Re: [rtcweb] Open data channel issues
Michael Tuexen <Michael.Tuexen@lurchi.franken.de> Mon, 03 March 2014 14:41 UTC
Return-Path: <Michael.Tuexen@lurchi.franken.de>
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 D9B991A015C for <rtcweb@ietfa.amsl.com>; Mon, 3 Mar 2014 06:41:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, RP_MATCHES_RCVD=-0.547, SPF_HELO_PASS=-0.001] 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 5SgkdbIq1RYk for <rtcweb@ietfa.amsl.com>; Mon, 3 Mar 2014 06:41:52 -0800 (PST)
Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) by ietfa.amsl.com (Postfix) with ESMTP id 2A71C1A005E for <rtcweb@ietf.org>; Mon, 3 Mar 2014 06:41:52 -0800 (PST)
Received: from dhcp-9fd9.meeting.ietf.org (dhcp-9fd9.meeting.ietf.org [31.133.159.217]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id A7ECA1C1042F5; Mon, 3 Mar 2014 15:41:48 +0100 (CET)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\))
From: Michael Tuexen <Michael.Tuexen@lurchi.franken.de>
In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D1BE0E0@ESESSMB209.ericsson.se>
Date: Mon, 03 Mar 2014 14:41:46 +0000
Content-Transfer-Encoding: quoted-printable
Message-Id: <26814FB1-993E-4F5C-8224-BFB93E4AC44D@lurchi.franken.de>
References: <31B9253D-E826-4D07-A8A1-1B062B50F163@lurchi.franken.de> <530E4568.6090402@alum.mit.edu> <530E564B.9070103@jesup.org> <530E6580.4080804@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D1BE0E0@ESESSMB209.ericsson.se>
To: Christer Holmberg <christer.holmberg@ericsson.com>
X-Mailer: Apple Mail (2.1874)
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/gOvRUWAe3zATfUtTDDDPAZuNpdE
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>
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: Mon, 03 Mar 2014 14:41:54 -0000
On 26 Feb 2014, at 22:21, Christer Holmberg <christer.holmberg@ericsson.com> wrote: > Hi, > >>>> * 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). > > I think the MUST-be-supported-method is a separate question. > >> 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? > > I guess they would both be in-band methods. Maybe using in-band and out-of-band terminology would be more clear - and more aligned with existing terminology. OK, changed to in-band and out-of-band. Best regards Michael > > Regards, > > Christer > > _______________________________________________ > rtcweb mailing list > rtcweb@ietf.org > https://www.ietf.org/mailman/listinfo/rtcweb >
- [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)