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
>