Re: BUNDLE: meaning of "unspecified" when describing "bundle-only"
Cullen Jennings <[email protected]>
| Newsgroups | gmane.ietf.mmusic |
|---|---|
| Message-ID | <[email protected]> |
That works for me. > On Jul 11, 2017, at 7:46 AM, Christer Holmberg <[email protected]> wrote: > > Hi, > > It took a while, but here is my suggestion (based on alternative #2): > > OLD TEXT: > > "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." > > > NEW TEXT: > > "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. If an implementation receives, within > an offer or answer, a bundled "m=“ line with a non-zero port value > > and an ‘bundle-only’ attribute associated with the “m=“ line, the > implementation MUST ignore the attribute." > > Regards, > > Christer > > > On 10/01/17 15:18, "mmusic on behalf of Christer Holmberg" > <[email protected] on behalf of [email protected]> > wrote: > >> 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 protected] on behalf of [email protected]> wrote: >> >>> 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 protected] >>> https://www.ietf.org/mailman/listinfo/mmusic >> >> _______________________________________________ >> mmusic mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/mmusic > > _______________________________________________ > mmusic mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/mmusic _______________________________________________ mmusic mailing list [email protected] https://www.ietf.org/mailman/listinfo/mmusic