Re: [MMUSIC] BUNDLE TEXT: Offerer procedures (June 6th)

Paul Kyzivat <> Thu, 06 June 2013 17:24 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4BD5621F99D5 for <>; Thu, 6 Jun 2013 10:24:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.287
X-Spam-Status: No, score=-0.287 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id pkA0FZYU5aLT for <>; Thu, 6 Jun 2013 10:24:22 -0700 (PDT)
Received: from ( [IPv6:2001:558:fe14:44:76:96:59:227]) by (Postfix) with ESMTP id CECD621F99F0 for <>; Thu, 6 Jun 2013 10:24:08 -0700 (PDT)
Received: from ([]) by with comcast id kzgG1l0020cZkys5C5Pqu8; Thu, 06 Jun 2013 17:23:50 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([]) by with comcast id l5Pq1l0063ZTu2S3W5Pqrf; Thu, 06 Jun 2013 17:23:50 +0000
Message-ID: <>
Date: Thu, 06 Jun 2013 13:23:49 -0400
From: Paul Kyzivat <>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130509 Thunderbird/17.0.6
MIME-Version: 1.0
References: <> <>
In-Reply-To: <>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=q20121106; t=1370539430; bh=7F2Ch7LZnOiW97Vzrz5IOHN8P5yIvFDIq28BWkpoVd8=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=GXl75Etv24KT5XjQ0Oc4rIzZ9FEu3KsvMhZDEve9deBhnwx/bwEnMSfDKqpO3GdkP lKRTK2sF3swZMJBH8oXaWwEoq4xBtEh7gUGLUPrhwt3WIQvQfZp27oFnUH0I39ozxb P8jCu5X8gZRbMXE/lvg6wFyaeUTvBgfwouKrtxt3p+U0e7A6PDU//WpH7UgL6P9xKo i3NMqUIa5F9Y5sc1R/XYGK2/SjtByE138nqXgsM5IsLCpftUA4WDP7oQATdYvTflAi lE/CXvpTi4RhmaXmN/rsJMaKUDL9CeahWaidQjbhXvxtAnJMs02nQFVjyfLd2FPfo6 A/30qlaACEipw==
Subject: Re: [MMUSIC] BUNDLE TEXT: Offerer procedures (June 6th)
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 06 Jun 2013 17:24:27 -0000

Hi Martin,

I see we had some of the same issues, but I think we have formed 
different ideas of how the proposal was intended to work and how to 
improve it.

My conclusion is that trying to characterize full offers into different 
types and impose rules on them breaks down, and that it is better to 
impose constraints that must apply.

I sketched out some proposed constraints in my reply. But if that 
approach seems acceptable then those need some refinement. For instance, 
in general the constraints don't apply to an entire offer or answer, but 
instead apply to a set of m-lines in a bundle group. (If there is more 
than one bundle group then each can be considered separately.) But some 
of the constraints are global - e.g. uniqueness.


On 6/6/13 12:42 PM, Martin Thomson wrote:
> Nice work.  I had too many comments to do an email reply properly, so
> I've done the whole nasty Word doc thing.
> The only big item is that I think that you need to more tightly
> control the conditions for a BSO - in most cases, you could label
> those BSO as BRO without causing any problems.  Given that limitation,
> you could probably eliminate the BRO/BSO labels, which might help with
> readability a little.
> _______________________________________________
> mmusic mailing list