Re: [MMUSIC] Bundle rejection oddities

Paul Kyzivat <> Sun, 06 March 2016 22:28 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 540D91B3B11 for <>; Sun, 6 Mar 2016 14:28:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.235
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ieCQxQ9vjGq5 for <>; Sun, 6 Mar 2016 14:28:20 -0800 (PST)
Received: from ( [IPv6:2001:558:fe21:29:69:252:207:34]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id BD8E81B3B10 for <>; Sun, 6 Mar 2016 14:28:20 -0800 (PST)
Received: from ([]) by with comcast id SmUK1s00C2Ka2Q501mUKYv; Sun, 06 Mar 2016 22:28:19 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([]) by with comcast id SmUK1s0073KdFy101mUKLR; Sun, 06 Mar 2016 22:28:19 +0000
References: <> <> <> <> <> <> <> <> <>
From: Paul Kyzivat <>
Message-ID: <>
Date: Sun, 6 Mar 2016 17:28:18 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.6.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=q20140121; t=1457303299; bh=eQ7dBTro+fQNbZtVMp79S+1l7Pt7+xbPGDIsDtZyEZ0=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=l8b9iB6uidGtXhpU4U0+H9F3uudOWY+Qouv0zePqKNzLqrgkMlSFcnQIbeakkukjm zhaGazh9y6+Lyi3U2IasFqlhJmlG1lUM2Fky3DVnbUIJDG2/5vsz7oO4a1QcBph4zp lQhZ/QkdWf1DQydlXMWJxUqGK21ERnpfhFJ7k0fmVSyzAipx7a1ZYOvSqORwYs5pAI tq8cYu39G5Pc6VKg4CaIG9TKhlJo6v1ZnYEK1tAriKhPthohcM0hUIPTxRsozkD/8i YAwDark0ZVMttA4mlyueI0w1nVlaGGbDQDhreAly+rHaK15Hc88+mcr82kvsYHb0dd souCPRWCQHucg==
Archived-At: <>
Subject: Re: [MMUSIC] Bundle rejection oddities
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 06 Mar 2016 22:28:22 -0000

On 3/5/16 1:59 PM, Christer Holmberg wrote:

>> S1.
>>     The offerer and answerer [RFC3264] use the BUNDLE extension to
>>     negotiate the BUNDLE addresses, one for the offerer (offerer BUNDLE
>>     address) and one for the answerer (answerer BUNDLE address), to be
>>     used for receiving the bundled media associated with a BUNDLE group.
>> S 5.
>>     All media associated with a BUNDLE group share a single 5-tuple, i.e.
>>     in addition to using a single address:port combination all bundled
>>     media MUST be transported using the same transport-layer protocol
> In those cases the text talks about the MEDIA, not SDP parameters. I am happy to change it to something else, but I am not sure whether we could say "media attached to the bundle group", "media that appears in the bundle group" or "media that is a member of the bundle group"?

How about "media {described / identified / specified} by the bundle group"?

>>> - You suggest saying "attribute appearing in m- line". Such terminology has been used in the past, and I was asked to change it, because attributes are not part of m- lines.
>> I would recommend the JSEP terminology of "appearing within an m= section"
>> In any case, the problem is the use of "associated" here. Feel free to use
>> another term that's not "associated"
> "m= line" is used throughout the document, so I don't want to change that to "m= section", because I don't think it can be done with a simple search/replace.
> At one point I think I suggested "media description", which would include both the "m=" line and the attributes. Then we could have said "within the media description", "add to the media description", etc. But, people weren't happy with that either.
> Whatever change I do, it has to be something that EVERYONE agrees with. Otherwise, when X reviews the document, I may end up having to change it all again...
> I know that at least Paul and Flemming have had comments on the terminology, so I'd like to get some input from them.

Yes, I was one of the people that had problems with prior terminology. 
And "associated" seemed to work at the time.

I agree that now we do have a problem with "associated" being used in 
other contexts to mean something different, and the result again being 

I am not attached to "associated", as long as we end up with something 
clear, that uses the same terminology consistently for a concept, and 
clearly different terminology for *different* concepts. But it is hard. 
So I share Christer's desire to be conservative about making changes now.

So I guess I would prefer to keep with "associated with an m= line" for 
attributes and the like that follow an m-line, and something different 
for other uses of "associated", especially in the same sentence or