[MMUSIC] BUNDLE: meaning of "unspecified" when describing "bundle-only"

Adam Roach <adam@nostrum.com> Thu, 29 December 2016 21:15 UTC

Return-Path: <adam@nostrum.com>
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 EF6CF129A04 for <mmusic@ietfa.amsl.com>; Thu, 29 Dec 2016 13:15:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5
X-Spam-Level:
X-Spam-Status: No, score=-5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-3.1] autolearn=ham autolearn_force=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 DobwlFzqRo2A for <mmusic@ietfa.amsl.com>; Thu, 29 Dec 2016 13:15:54 -0800 (PST)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BE2C5129673 for <mmusic@ietf.org>; Thu, 29 Dec 2016 13:15:54 -0800 (PST)
Received: from Orochi.local (99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id uBTLFqUp033952 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO) for <mmusic@ietf.org>; Thu, 29 Dec 2016 15:15:53 -0600 (CST) (envelope-from adam@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host 99-152-145-110.lightspeed.dllstx.sbcglobal.net [99.152.145.110] claimed to be Orochi.local
To: "mmusic@ietf.org" <mmusic@ietf.org>
From: Adam Roach <adam@nostrum.com>
Message-ID: <9e5fc493-bfba-1a27-149e-1f566a25b411@nostrum.com>
Date: Thu, 29 Dec 2016 15:15:52 -0600
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:45.0) Gecko/20100101 Thunderbird/45.5.1
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/mmusic/bh5mC85ewNWyh0Ykkh668XV7mJM>
Subject: [MMUSIC] BUNDLE: meaning of "unspecified" when describing "bundle-only"
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.17
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: <https://mailarchive.ietf.org/arch/browse/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: Thu, 29 Dec 2016 21:15:56 -0000

We've recently come across an issue with the way the "bundle-only" 
attribute is described in the current document. The current language 
regarding port handling reads:

    The usage of the 'bundle-only' attribute is only defined for a
    bundled "m=" line with a zero port value, within an offer. Other
    usage is unspecified.

Usually, when we have this kind of language, we still ensure that 
behavior is well defined, to help avoid unnecessary interop failures. I 
see a couple of different options here:

 1. Remove the final sentence and add language saying that creators of
    SDP MUST NOT include a "bundle-only" attribute in an m-section that
    has a non-zero port, and that recipients of such SDP {SHOULD,MUST}
    reject it; or

 2. Retain language saying that including a "bundle-only" attribute in a
    non-zero m-section is unspecified, but add normative language along
    the lines of: "implementations that receive an m-section with a
    non-zero port that also contains a 'bundle-only' attribute MUST
    ignore the {attribute,port}."

I don't have a preference between these choices, but I think we do need 
clarity. To be absolutely clear, this feedback is based on actual 
implementation interop failures in the field. This problem is not 
theoretical.

/a