IETF Logo Mail Archive

Re: [MMUSIC] Draft new version: BUNDLE-21

Paul Kyzivat <pkyzivat@alum.mit.edu> Mon, 15 June 2015 18:52 UTC

Return-Path: <pkyzivat@alum.mit.edu>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6E6C1A3BA3 for <mmusic@ietfa.amsl.com>; Mon, 15 Jun 2015 11:52:55 -0700 (PDT)
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 QkhYquigU95w for <mmusic@ietfa.amsl.com>; Mon, 15 Jun 2015 11:52:54 -0700 (PDT)
Received: from resqmta-po-09v.sys.comcast.net (resqmta-po-09v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:168]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B5D951A6EEC for <mmusic@ietf.org>; Mon, 15 Jun 2015 11:52:53 -0700 (PDT)
Received: from resomta-po-08v.sys.comcast.net ([96.114.154.232]) by resqmta-po-09v.sys.comcast.net with comcast id giqJ1q005516pyw01istJu; Mon, 15 Jun 2015 18:52:53 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.151]) by resomta-po-08v.sys.comcast.net with comcast id giss1q00V3Ge9ey01issxP; Mon, 15 Jun 2015 18:52:53 +0000
Message-ID: <557F1F03.4010009@alum.mit.edu>
Date: Mon, 15 Jun 2015 14:52:51 -0400
From: Paul Kyzivat <pkyzivat@alum.mit.edu>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.7.0
MIME-Version: 1.0
To: Christer Holmberg <christer.holmberg@ericsson.com>, "mmusic@ietf.org" <mmusic@ietf.org>
References: <7594FB04B1934943A5C02806D1A2204B1D8D9E55@ESESSMB209.ericsson.se> <557F07E2.8020404@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D8DB3C8@ESESSMB209.ericsson.se> <557F1C81.9070100@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1D8DB4A2@ESESSMB209.ericsson.se>
In-Reply-To: <7594FB04B1934943A5C02806D1A2204B1D8DB4A2@ESESSMB209.ericsson.se>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1434394373; bh=bwKqqkvMaMmvzfCylzkA0aQzZ1p671LR3lNCoO4JawM=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=ifwhqkyqg7L5t1/FRhgcK6oZvJdvCjt9yiM7es4Qhtu5HVywGvG+muMgF3dPIzvT+ 64e7KBHzBBCd420hjuO/Ox5JCPlZ2OYFyuWzgfzygmZDm1DaGROUj1NnXPAnKlXZxZ klFX0yT6jAy4iX2fezlIrhbONCVvX1UiQr0+nOvgmSHekRMPP6BXsYV1VAUUwgHgwC wt4QYx6Bv53XIRAfujVsSGcrQpWfYd+j9v6ibh9OF6RmQylrD2TCb8tUZFLclUw+uO 0Ivjid8SV5QDyDgTjZSfTOrBPQt1SpG8xq39F3WlmalYClq9zNNCMUg+6mrV4LodlK KjLApboFfFYhA==
Archived-At: <http://mailarchive.ietf.org/arch/msg/mmusic/GxIotjWjK4VStaa0NHzGk6ysz1M>
Subject: Re: [MMUSIC] Draft new version: BUNDLE-21
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.15
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: <http://www.ietf.org/mail-archive/web/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: Mon, 15 Jun 2015 18:52:56 -0000

On 6/15/15 2:47 PM, Christer Holmberg wrote:
> Hi,
>
>>> But, I hear what you are saying, so perhaps we instead should say "received data"?
>>
>> That would fix it here. But the usage is elsewhere, with the same concern.
>
> The only other place where I can find "packets" being used is in relation to RTP/RTCP, and as far as I know we always talk about "RTP packets" and "RTCP packets", don't we?

It also is used at least in the prior (old) paragraph of this section. 
The change you propose would work throughout this section.

	Thanks,
	Paul

> Regards,
>
> Christer
>
>
>> -----Original Message-----
>> From: mmusic [mailto:mmusic-bounces@ietf.org] On Behalf Of Paul Kyzivat
>> Sent: 15 June 2015 20:14
>> To: mmusic@ietf.org
>> Subject: Re: [MMUSIC] Draft new version: BUNDLE-21
>>
>> One comment, on section 9.1:
>>
>>       This document describes a mechanism to identify the protocol of a
>>       received packet among the STUN, DTLS and SRTP protocols (in any
>>       combination), when UDP is used as transport-layer protocol, but does
>>       not describe how to identify different protocols transported on DTLS.
>>       While the mechanism is generally applicable to other protocols and
>>       transport-layers protocols, any such use requires further
>>       specification around how to multiplex multiple protocols on a given
>>       transport-layer protocols, and how to associate received packets with
>>       the correct protocols.
>>
>> ISTM that something is still missing from this section. It *assumes* that the transport protocol packages things into packets, and that each such packet can be associated with one of the application protocols sharing it.
>>
>> Consider TCP: while it uses packets on the network, it is a stream oriented transport. Upper layers built for TCP may not have any notion of packets. It is probably infeasible to multiplex m-lines for such protocols using BUNDLE.
>>
>> The protocols we have been thinking of either don't work over stream oriented protocols, or else define a way to packetize.
>>
>> This could get complex. The simple thing to do is to specify that stream-oriented transports are out of scope for this document.
>>
>> 	Thanks,
>> 	Paul
>>
>> _______________________________________________
>> mmusic mailing list
>> mmusic@ietf.org
>> https://www.ietf.org/mailman/listinfo/mmusic
>>
>
>

v2.23.0 | Report a Bug | By Email