IETF Logo Mail Archive

Re: [MMUSIC] AD Evaluation of draft-ietf-mmusic-data-channel-sdpneg-20

Paul Kyzivat <pkyzivat@alum.mit.edu> Tue, 27 November 2018 19:40 UTC

Return-Path: <pkyzivat@alum.mit.edu>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B55ED1286E7 for <mmusic@ietfa.amsl.com>; Tue, 27 Nov 2018 11:40:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level:
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 TJch05lQHfoC for <mmusic@ietfa.amsl.com>; Tue, 27 Nov 2018 11:40:58 -0800 (PST)
Received: from alum-mailsec-scanner-8.mit.edu (alum-mailsec-scanner-8.mit.edu [18.7.68.20]) by ietfa.amsl.com (Postfix) with ESMTP id 2A0EA1276D0 for <mmusic@ietf.org>; Tue, 27 Nov 2018 11:40:58 -0800 (PST)
X-AuditID: 12074414-347ff70000006380-b6-5bfd9dc9e9f4
Received: from outgoing-alum.mit.edu (OUTGOING-ALUM.MIT.EDU [18.7.68.33]) (using TLS with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by alum-mailsec-scanner-8.mit.edu (Symantec Messaging Gateway) with SMTP id 8E.16.25472.9CD9DFB5; Tue, 27 Nov 2018 14:40:57 -0500 (EST)
Received: from PaulKyzivatsMBP.localdomain (c-24-62-227-142.hsd1.ma.comcast.net [24.62.227.142]) (authenticated bits=0) (User authenticated as pkyzivat@ALUM.MIT.EDU) by outgoing-alum.mit.edu (8.14.7/8.12.4) with ESMTP id wARJeuQ3005066 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for <mmusic@ietf.org>; Tue, 27 Nov 2018 14:40:57 -0500
To: mmusic@ietf.org
References: <E028869C-2FE4-44D1-985B-7B3FD58D352A@nostrum.com> <C454212D-B8FF-4E21-B6ED-67EB6BB96A88@nostrum.com>
From: Paul Kyzivat <pkyzivat@alum.mit.edu>
Message-ID: <1eb405ee-e9ab-d428-a472-7cad77ecfacc@alum.mit.edu>
Date: Tue, 27 Nov 2018 14:40:56 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:52.0) Gecko/20100101 Thunderbird/52.9.1
MIME-Version: 1.0
In-Reply-To: <C454212D-B8FF-4E21-B6ED-67EB6BB96A88@nostrum.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrDIsWRmVeSWpSXmKPExsUixO6iqHty7t9og2OHJS2mLn/M4sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujOeTP7MX/GKpmNz5nKmBsZGli5GTQ0LAROLtqYWMXYxcHEIC B5kkTq5YzgrhfGeSWP1oHXMXIweHsECgxL+vqiANIgLCEjPe/mUDsYUEiiX6Lu1kBbHZBLQk 5hz6zwJSzitgL9HTng4SZhFQlWi6dQesXFQgTeJv5xJGEJtXQFDi5MwnYOWcQOVNJ/1BwswC ZhLzNj9khrDFJW49mc8EYctLNG+dzTyBkX8Wku5ZSFpmIWmZhaRlASPLKka5xJzSXN3cxMyc 4tRk3eLkxLy81CJdC73czBK91JTSTYyQgBTZwXjkpNwhRgEORiUe3oDUv9FCrIllxZW5hxgl OZiURHlfzgAK8SXlp1RmJBZnxBeV5qQWH2KU4GBWEuG1KgbK8aYkVlalFuXDpKQ5WJTEeZlN 9kYJCaQnlqRmp6YWpBbBZGU4OJQkeGPmADUKFqWmp1akZeaUIKSZODhBhvMADfcAqeEtLkjM Lc5Mh8ifYtTl2PO1aQazEEtefl6qlDjvIZAiAZCijNI8uDmwRPKKURzoLWFeS5AqHmASgpv0 CmgJE9CSaxN/gywpSURISTUwTqybNWldyyo7k2/bHfnkXC3cC2869zFftey5lrRcVmO6ypkY zwoDJYbdKxJnHT0torLWoUUmdH5l9cOaOQlhK3oun3s1ibPD5kfQ7ouF3z62rb1VrXwy/8+J 4uIvoRI7Q2QqMk9fOXe5VLhfTvvkv6XHH5h3n3M4Kb7Rz7zY6tDpHe2+a6//VmIpzkg01GIu Kk4EAAJLijH/AgAA
Archived-At: <https://mailarchive.ietf.org/arch/msg/mmusic/WececWv9L-IM7OqMkUxnbFR-cFI>
Subject: Re: [MMUSIC] AD Evaluation of draft-ietf-mmusic-data-channel-sdpneg-20
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mmusic/>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 27 Nov 2018 19:41:00 -0000

On 11/26/18 5:32 PM, Ben Campbell wrote:

>> §9.1: What is the rational for sharing the websocket subprotocol registry rather than creating a new one for data channels? The websocket subprotocol name registry has a policy of “First Come First Served”. This draft seems to state requirements for subprotocol specifications, but FCFS does not require specifications.

IIRC this choice was made by the rtcweb wg. I don't recall how it was made.

It is my impression there is an expectation that many websocket 
protocols could also be used over data channels in order to get 
multiplexing of the socket.

	Thanks,
	Paul

v2.23.0 | Report a Bug | By Email