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

[Adam Roach]

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

[Christer Holmberg]

Hi Adam,

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

Regards,

Christer

-----Original Message-----
From: mmusic [mailto:mmusic-***@ietf.org] On Behalf Of Adam Roach
Sent: 29 December 2016 23:16
To: ***@ietf.org
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

[Christer Holmberg]

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"

Post by Adam Roach
We've recently come across an issue with the way the "bundle-only"
attribute is described in the current document. The current language
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
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
https://www.ietf.org/mailman/listinfo/mmusic

[Christer Holmberg]

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"

Post by Christer Holmberg
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"

Post by Adam Roach
We've recently come across an issue with the way the "bundle-only"
attribute is described in the current document. The current language
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
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
https://www.ietf.org/mailman/listinfo/mmusic

_______________________________________________
mmusic mailing list
https://www.ietf.org/mailman/listinfo/mmusic

[Cullen Jennings]

That works for me.

Post by Christer Holmberg
Hi,
"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."
"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"

Post by Christer Holmberg
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"

Post by Adam Roach
We've recently come across an issue with the way the "bundle-only"
attribute is described in the current document. The current language
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
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
https://www.ietf.org/mailman/listinfo/mmusic

_______________________________________________
mmusic mailing list
https://www.ietf.org/mailman/listinfo/mmusic

_______________________________________________
mmusic mailing list
https://www.ietf.org/mailman/listinfo/mmusic