Re: [rtcweb] Open data channel issues

Paul Kyzivat <pkyzivat@alum.mit.edu> Thu, 27 February 2014 01:15 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 83EEA1A02AA for <rtcweb@ietfa.amsl.com>; Wed, 26 Feb 2014 17:15:11 -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 R6fNqWcIRmoj for <rtcweb@ietfa.amsl.com>; Wed, 26 Feb 2014 17:15:10 -0800 (PST)
Received: from QMTA11.westchester.pa.mail.comcast.net (qmta11.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:211]) by ietfa.amsl.com (Postfix) with ESMTP id AF8971A033D for <rtcweb@ietf.org>; Wed, 26 Feb 2014 17:15:09 -0800 (PST)
Received: from omta02.westchester.pa.mail.comcast.net ([76.96.62.19]) by QMTA11.westchester.pa.mail.comcast.net with comcast id XD0e1n0060QuhwU5BDF8dB; Thu, 27 Feb 2014 01:15:08 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta02.westchester.pa.mail.comcast.net with comcast id XDF71n00W3ZTu2S3NDF7u2; Thu, 27 Feb 2014 01:15:08 +0000
Message-ID: <530E919B.6030208@alum.mit.edu>
Date: Wed, 26 Feb 2014 20:15:07 -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: Christer Holmberg <christer.holmberg@ericsson.com>, "rtcweb@ietf.org" <rtcweb@ietf.org>
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>
In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D1BE0E0@ESESSMB209.ericsson.se>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1393463708; bh=Mnv9FLO3A9ZDquMRHIjQ0VCGAV2XBREAmbg6uyeaM34=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=Dnt8NaPKP9IexFClunKfwLS6cJIp+UhSFNDcZpnGV/VpZ3xj8aYbNic9/Ut3hlUe7 pYu1KLpbYu5ODqd+s77jwz5PfaIRSy4AlfALoZL7dqnfw9YJMf7rIgZw+1VeQza2uy NPWaNQvqxW/TNELC8dDE4mmiyWAn6r2gFc372R9ivOXty9JJYn1jLVds7lqJY5Flew CY3qv6dcbP3VUID3GPSUbiBMSy+j1ScbMw3mFnLYfRL8pW3d0EHuCF+kEzxlOuABhR o9J71Vxl6qqVyUGjZoBH2MfiNLEJtpwUvq9KJsHJl+N5WzB8LAzLOpnNR5a98v/C6X MceCAerwjTUMQ==
Archived-At: http://mailarchive.ietf.org/arch/msg/rtcweb/j9SRDZLiiRd0OsblnvS_UtMMKss
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: Thu, 27 Feb 2014 01:15:11 -0000

On 2/26/14 5:21 PM, Christer Holmberg 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.

My point is that the real distinction is between the one std mechanism 
and everything else. For purposes of discussions here it doesn't matter 
whether the non-std mechanisms are in-band or out of band.

(Of course to the people using them the distinction is significant. But 
it is their problem, not ours.)

	Thanks,
	Paul