Re: [MMUSIC] UP: Can a partial offer be a full offer?

Paul Kyzivat <pkyzivat@alum.mit.edu> Wed, 21 August 2013 17:24 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 3FE6711E8234 for <mmusic@ietfa.amsl.com>; Wed, 21 Aug 2013 10:24:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.344
X-Spam-Level:
X-Spam-Status: No, score=-0.344 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JuJMmVCtCYk0 for <mmusic@ietfa.amsl.com>; Wed, 21 Aug 2013 10:24:32 -0700 (PDT)
Received: from qmta14.westchester.pa.mail.comcast.net (qmta14.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:212]) by ietfa.amsl.com (Postfix) with ESMTP id 1E24011E8120 for <mmusic@ietf.org>; Wed, 21 Aug 2013 10:24:31 -0700 (PDT)
Received: from omta05.westchester.pa.mail.comcast.net ([76.96.62.43]) by qmta14.westchester.pa.mail.comcast.net with comcast id FRQ41m0060vyq2s5EVQXef; Wed, 21 Aug 2013 17:24:31 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta05.westchester.pa.mail.comcast.net with comcast id FVQW1m00i3ZTu2S3RVQW4F; Wed, 21 Aug 2013 17:24:30 +0000
Message-ID: <5214F7CE.2060506@alum.mit.edu>
Date: Wed, 21 Aug 2013 13:24:30 -0400
From: Paul Kyzivat <pkyzivat@alum.mit.edu>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130801 Thunderbird/17.0.8
MIME-Version: 1.0
To: Hadriel Kaplan <hadriel.kaplan@oracle.com>
References: <7594FB04B1934943A5C02806D1A2204B1C41D8F9@ESESSMB209.ericsson.se> <7594FB04B1934943A5C02806D1A2204B1C41D9A9@ESESSMB209.ericsson.se>, <89C72647-EF4A-4825-A506-A5128DECFD14@oracle.com> <7594FB04B1934943A5C02806D1A2204B1C41DA7A@ESESSMB209.ericsson.se> <C5E08FE080ACFD4DAE31E4BDBF944EB113678D66@xmb-aln-x02.cisco.com> <7594FB04B1934943A5C02806D1A2204B1C44E693@ESESSMB209.ericsson.se> <5213E4A6.3010704@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B1C473198@ESESSMB209.ericsson.se> <5214C1D5.10201@alum.mit.edu> <26E5EE5C-85A6-43BB-80FB-4D05A059A90F@oracle.com>
In-Reply-To: <26E5EE5C-85A6-43BB-80FB-4D05A059A90F@oracle.com>
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=1377105871; bh=bZhtorwfnrZmsR1rDiIpO15Lu7aSS/jwyi8qUdgTGBM=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=gHNfUJcTmfKWyFu+Xyr8SKQGgVVB2VfQcWqycKB4LmSwEZYUs6Gaq1lEV5839znkN 8Bcjmi55ZO8Kmbp/LvdS0LIWjlV00z/OQDO2cJKMrSAG4dbmCoOqWYsDAkXKC+MhyV Tg4p7n+iFG/pB+vui3xWyK9B2nV54ehDqDrxzSIoaK/M1iRsl9mITCRLm0GLyZUhwD LmupTVWLS88yZw3C2oP8rw+CMiS5jT2MwW6n3zc1riJGVZl6ljeCvX3Zr1UfSm8FLD cKkH2fyGgH032MFm81OZHSvt/BFEmx2XBgEXGbhr0iPEDsQFGkfAAO6Hd5fmjDMDkx 8u29JV9s5sn4A==
Cc: "mmusic@ietf.org" <mmusic@ietf.org>, Christer Holmberg <christer.holmberg@ericsson.com>
Subject: Re: [MMUSIC] UP: Can a partial offer be a full offer?
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
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: Wed, 21 Aug 2013 17:24:44 -0000

On 8/21/13 10:33 AM, Hadriel Kaplan wrote:
>
> On Aug 21, 2013, at 9:34 AM, Paul Kyzivat <pkyzivat@alum.mit.edu> wrote:
>
>>> Maybe we should use media level o- lines for POFs/PANs....
>>
>> I don't know how you could do that in a backward compatible way.
>
> Backward compatible to what?  There's no POFs/PANs thing today.  You don't even need to use SDP syntax if you don't want to, or you could use some diff-style format of SDP lines, or use what look and act exactly like SDP lines but aren't technically "SDP" to avoid any legacy RFC rules.

Maybe we are thinking of this differently, but my thinking is that 
consistency with a full SDP must be maintained. If you start off with an 
O/A, then some POFs/PANs, eventually you may need to do another O/A. And 
at that point there needs to be consistency.

I think that means that POFs/PANs always contain a subset of a full SDP, 
and act as deltas, implicitly updating a full SDP. That means everything 
in the POFs/PANs needs to be valid SDP. And when that stuff is used in a 
full O/A, there need to be rules for how those are reconciled.

So, to introduce a media level o-line, it would need to be defined for 
SDP too.

It might be possible to arrange so that it won't be seen by an endpoint 
that doesn't support POFs/PANs, but that will take some care, and is 
likely to be fragile.

	Thanks,
	Paul