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

From: Christer Holmberg <[email-masked]>
Date: Mon, 2 Jan 2017 09:48:34 +0000

Hi Adam,

Thanks for your comment! I'll get back to you asap.

Regards,

Christer

-----Original Message-----
From: mmusic [mailto:[email-masked]] On Behalf Of Adam Roach
Sent: 29 December 2016 23:16
To: [email-masked]
Subject: [MMUSIC] BUNDLE: meaning of "unspecified" when describing "bundle-only"

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

_______________________________________________
mmusic mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mmusic

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 10 Jan 2017 13:18:04 +0000

Hi Adam,

My suggestion would be alternative #2. Because, if an endpoint supports
the attribute it doesn¹t really matter what the port value is, so there is
no need to reject the m- line.

Regards,

Christer

On 29/12/16 23:15, "mmusic on behalf of Adam Roach"
<[email-masked] on behalf of [email-masked]> wrote:

>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:
>
>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
>