Re: [MMUSIC] BUNDLE Weekly Summary: Assumptions

Paul Kyzivat <pkyzivat@alum.mit.edu> Fri, 10 May 2013 22:26 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 E1E0621F85C3 for <mmusic@ietfa.amsl.com>; Fri, 10 May 2013 15:26:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.159
X-Spam-Level:
X-Spam-Status: No, score=-0.159 tagged_above=-999 required=5 tests=[AWL=0.278, 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 f8IYEX6Bw33H for <mmusic@ietfa.amsl.com>; Fri, 10 May 2013 15:25:58 -0700 (PDT)
Received: from qmta02.westchester.pa.mail.comcast.net (qmta02.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:24]) by ietfa.amsl.com (Postfix) with ESMTP id 5F26221F852D for <mmusic@ietf.org>; Fri, 10 May 2013 15:25:49 -0700 (PDT)
Received: from omta11.westchester.pa.mail.comcast.net ([76.96.62.36]) by qmta02.westchester.pa.mail.comcast.net with comcast id aANp1l00C0mv7h051NRhRH; Fri, 10 May 2013 22:25:41 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta11.westchester.pa.mail.comcast.net with comcast id aNRh1l00f3ZTu2S3XNRheu; Fri, 10 May 2013 22:25:41 +0000
Message-ID: <518D73E4.4090609@alum.mit.edu>
Date: Fri, 10 May 2013 18:25:40 -0400
From: Paul Kyzivat <pkyzivat@alum.mit.edu>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130328 Thunderbird/17.0.5
MIME-Version: 1.0
To: mmusic@ietf.org
References: <7594FB04B1934943A5C02806D1A2204B1C36B485@ESESSMB209.ericsson.se> <C5E08FE080ACFD4DAE31E4BDBF944EB1134DEF4B@xmb-aln-x02.cisco.com> <CABcZeBMrgaHGXFi_NRk+znsT-AGnRS5EDLgFhZgGA+VG81BhZw@mail.gmail.com> <CABkgnnW=4zNgauXc-=pv9j9zGdVntmb=K22wcRr77wfQc-6J3w@mail.gmail.com> <CABcZeBODcyo-JXqs6EZ-F5BY_TaM94+eu+UqNApFnTNjpehUzA@mail.gmail.com>
In-Reply-To: <CABcZeBODcyo-JXqs6EZ-F5BY_TaM94+eu+UqNApFnTNjpehUzA@mail.gmail.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=1368224741; bh=HC6wj0oZG0IH1InblAZlB1qkD2e5gdRxnfXPPaL7i8E=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=sVi5BLgy2WR3LyVZ3trKJMWAA6GKsqtJazvl/XD7CVWzvumLFggj/kp2nv+5WA39W ODmugMPfIDRJCmIolh37IUxvV+YgVCtNpEChq1IDy70pP2CHqn9pSlkGaZuhDchIh6 IR94kE7NgMtpxlc9Yi+zu/Z1k4sa97MEJ2rxC5A522IwPXLoX/AqWQOuTnkMVOuooo x0iirCr+F4vI9DeZh8sfLukMSe1GKqJXlfEWkH1/R92UWMujN1QiDomKSBcZYGOKwV GLaUJdjCBtmIyIzMN3mduMO08UedyaW6WHlm53GcI9pZklYzmuQOp+SXSSFYwdpWcC 11TbofUwNqwfw==
Subject: Re: [MMUSIC] BUNDLE Weekly Summary: Assumptions
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: Fri, 10 May 2013 22:26:19 -0000

On 5/10/13 6:17 PM, Eric Rescorla wrote:
>
>
> On Fri, May 10, 2013 at 3:16 PM, Martin Thomson
> <martin.thomson@gmail.com <mailto:martin.thomson@gmail.com>> wrote:
>
>     On 10 May 2013 15:05, Eric Rescorla <ekr@rtfm.com
>     <mailto:ekr@rtfm.com>> wrote:
>      > I'm sorry to be slow today, but can you point me to the specific
>     MUST NOT in
>      > RFC 5888.
>
>     I struggled to find it too.  It's in 9.2:
>
>         SIP entities refuse media streams by setting the port to zero in the
>         corresponding "m" line. "a=group" lines MUST NOT contain
>         identification-tags that correspond to "m" lines with the port
>     set to
>         zero.
>
>
> This feels like something we could relax for the offer.

We could relax it. The question is if the change will break any existing 
use. That is a hard question to answer.

If we do relax it, then we should do for both offer and answer. Doing 
just for offer is stupid and bound to introduce further complications.

	Thanks,
	Paul