Subject: Re: [MMUSIC] WGLC comments on draft-ietf-mmusic-sdp-bundle-negotiation-12 - Paul's comments - bundle-only attribute

From: Christer Holmberg <[email-masked]>
Date: Wed, 22 Oct 2014 13:03:16 +0000

Hi,

-------------------------

>>* Section 6: SDP 'bundle-only' Attribute
>>
>> I would like to see the definition follow the new style introduced in draft-ietf-mmusic-rfc4566bis-12. 
>> This draft is nearer to completion to that one, and there is some risk that the new style will be revised 
>> in that draft. I don't propose to hold this draft up for that one - there should not be any formal dependency.
>
> I'll look into that.

Below is a suggested modification to the SDP 'bundle-only' attribute definition, based on the  structure suggested by Paul in 4566bis.

I have also added the "Category", as defined in draft-ietf-mmusic-sdp-mux-attributes, which I have also suggested should be part of 4566bis.

Note that the syntax is a little different than currently suggested by Paul, and I will provide a comment on 4566bis regarding that.

I have NOT added the ABNF to the IANA registrations, as suggested by Paul, because I don't think it is needed there, and I will provide a comment on 4566bis regarding that.

Section 6:
========

6.  SDP 'bundle-only' Attribute

6.1.  General

   This section defines a new SDP media-level attribute [RFC4566],
   'bundle-only'.

6.2.  bundle-only

      Name: bundle-only

      Value:

      Usage Level: media

      Charset Dependent: no

      Category: NORMAL

      Syntax:

         attribute               =/ bundle-only-attribute

         bundle-only-attribute   = "bundle-only"

      Example:

         a=bundle-only

   The 'bundle-only' attribute can be associated with a bundled "m="
   line in an offer, to request that the answerer only accepts the "m="
   line if the answerer keeps the "m=" line within the associated BUNDLE
   group.  In order to ensure that an answerer that does not supports
   the BUNDLE extension always *** rejects a 'bundle-only' "m=" line,
   the offerer can assign a zero port value to the "m=" line.  According
   to [RFC4566] an answerer will reject such "m=" line.  The usage of
   the 'bundle-only' attribute is only defined for a bundled "m=" line
   within an offer.  Other usage is unspecified.

   [Section 8] defines the detailed SDP Offer/Answer procedures for the
   'bundle-only' attribute.

-------------------------

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 22 Oct 2014 10:18:33 -0400

> I have NOT added the ABNF to the IANA registrations, as suggested by Paul, because I don't think it is needed there, and I will provide a comment on 4566bis regarding that.
...
>           bundle-only-attribute   = "bundle-only"

The above looks like ABNF to me. Just not of the form I have proposed in 
4566bis.

Since this attribute has no value, the form in 4566bis would have no ABNF.

And using an ABNF quoted string to define the name of the attribute 
causes it to be case-insensitive, which is not expected for attributes.
See Adam's comment on the msid draft for more on that:

https://mailarchive.ietf.org/arch/msg/mmusic/02BXt6UYiw370oQs6Rwpoccknr4

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 22 Oct 2014 14:38:15 +0000

Hi,

>> I have NOT added the ABNF to the IANA registrations, as suggested by Paul, because I don't think 
>> it is needed there, and I will provide a comment on 4566bis regarding that.
>>...
>>        Syntax:
>>
> The above looks like ABNF to me. Just not of the form I have proposed in 4566bis.

I know - I intend to give a comment on 4566bis, saying that I think the syntax shall be in ABNF form. The only place 4566bis currently suggest to put the ABNF is in the IANA registration, but I'd rather see it in the attribute definition. 

> And using an ABNF quoted string to define the name of the attribute causes it to be case-insensitive, which is not expected for attributes.

Ok. So, based on the suggestion in that thread, the ABNF would be:

           bundle-only-attribute   = %s"bundle-only"

....right?

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 22 Oct 2014 10:55:06 -0400

> I know - I intend to give a comment on 4566bis, saying that I think the syntax shall be in ABNF form. The only place 4566bis currently suggest to put the ABNF is in the IANA registration, but I'd r…

Why do you say that? Maybe I have more work to do on the IANA 
considerations section. Note that for the attributes defined in 4566bis, 
all the info describing an attribute is in the body of the rfc, in 
section 6, not in the IANA considerations section.

The iana considerations section of 4566bis can't look like it would in 
an extension draft because it also has all the instructions on how to do 
it in extension drafts.

I would expect a draft like yours to have a section defining the 
attribute, in a form like those in 4566bis have, and then an IANA 
considerations section that references the SDP Attributes table and 
references where in the draft the definition is.

>             bundle-only-attribute   = %s"bundle-only"

No. Because I don't want to use ABNF to define the *name* of the 
attribute. So no 'attribute =/ ...'. Just ABNF for the *value* of the 
attribute. When the attribute has no value, then no ABNF at all. See now 
sendrecv is defined.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 22 Oct 2014 18:12:39 +0000

Hi,

>>>> I have NOT added the ABNF to the IANA registrations, as suggested by 
>>>> Paul, because I don't think it is needed there, and I will provide a comment on 4566bis regarding that.
>>>> ...
>>>>         Syntax:
>>>>
>> I know - I intend to give a comment on 4566bis, saying that I think the syntax shall be in 
>> ABNF form. The only place 4566bis currently suggest to put the ABNF is in the IANA registration, 
>> but I'd rather see it in the attribute definition.
>
> Why do you say that? Maybe I have more work to do on the IANA considerations section. Note that for the attributes defined in 4566bis, all the info describing an attribute > is in the body of the rfc, in section 6, not in the IANA considerations section.
>
> The iana considerations section of 4566bis can't look like it would in an extension draft because it also has all the instructions on how to do it in extension drafts.

Sorry, I was unclear. I am not talking about the IANA considerations of 4566bis, but what information would be in the IANA considerations of a draft defining an SDP attribute.

Section 8.2.4 of 4566bis, which contains the information that someone defining an attribute sends to IANA, contains the following:

	"o  An ABNF definition of the attribute value rule.  The rule MUST NOT
      	match anything that is not also matched by <att-value>.  The rule
      	name SHOULD [MUST?]  NOT be defined as an Incremental Alternative
      	to <att-value>."

I don't think we need the ABNF in the information sent to IANA when registering an attribute.

>I would expect a draft like yours to have a section defining the attribute, in a form like those in 4566bis have, and 
>then an IANA considerations section that references the SDP Attributes table and references where in the draft the definition is.

Yes, that is how I also would like to have it :) 

But, as described above, my understanding of section 8.2.4 is that I will now have to send the ABNF to IANA when registering the attribute.

> No. Because I don't want to use ABNF to define the *name* of the attribute. So no 'attribute =/ ...'.

Why not? It's not too long ago that it was decided that one shall use that format for defining new SIP header fields, header field parameters etc.

> Just ABNF for the *value* of the attribute. When the attribute has no value, then no ABNF at all. See now sendrecv is defined.

I'll do it that way, in order to be aligned with 4566bis, but I am not sure I agree it is the best way. But, let's discuss that within the scope of 4566bis, as it's not BUNDLE specific.

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 22 Oct 2014 15:00:56 -0400

> But, as described above, my understanding of section 8.2.4 is that I will now have to send the ABNF to IANA when registering the attribute.

It was not my intent that you have to send *anything* to IANA separately 
from your draft. The information needs to be in the draft, and your IANA 
considerations should only need to point to the section of your draft 
where the information is.

> Why not? It's not too long ago that it was decided that one shall use that format for defining new SIP header fields, header field parameters etc.

A few reasons:

1) 4566 never had ABNF including the names of specific attributes in the 
definition of <attribute>.

2) if ABNF is used to define the attribute name, then the use of a 
quoted string causes the name to be case insensitive, while 4566 expects 
it to be case sensitive. (Of course this is less of a problem with my 
ABNF extension.)

3) Defining the attributes as extensions to the 4566 ABNF makes it 
difficult to validate the ABNF. You need to merge the two ABNFs 
together. In principle you need to merge *all* of the attribute 
definitions, and ensure that they don't conflict with each other.

> I'll do it that way, in order to be aligned with 4566bis, but I am not sure I agree it is the best way. But, let's discuss that within the scope of 4566bis, as it's not BUNDLE specific.

The -12 version has been posted for awhile now. And I've made multiple 
requests for review, but there have as yet been none.

I fully expect that it will need some tweaking. And it is possible that 
the consensus will be for a different approach. But until some comments 
come in it is what it is.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 22 Oct 2014 21:52:11 +0000

Hi,

I'll drop the ABNF discussion - I think we have more important things to focus on (IF I still have some comments, I'll provide them within the context of my SDP directorate review of 4566bis). As long as it is clear to everyone how to define, register and implement the attributes, that's what matters :)

Tomorrow I'll generate new BUNDLE text for the bundle-only definition/IANA considerations, according to 4566bis-12.

Thanks!

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 23 Oct 2014 09:37:09 +0000

Hi,

Below is new suggested text for the bundle-only attribute definition, following the structure in 4566bis-12:

SECTION 6:
---------------

6.1.  General

6.2.  bundle-only

      Name: bundle-only

      Value:

      Usage Level: media

      Charset Dependent: no

      Example:

         a=bundle-only

SECTION 14.3 (IANA Considerations):
-------------------------------------------------

14.3.  New SDP Attribute

   [RFC EDITOR NOTE: Please replace RFCXXXX with the RFC number of this
   document.]

   This document defines a new SDP media-level attribute, according to
   the following data:

    Attribute name:     bundle-only
    Type of attribute:  media
    Subject to charset: No
    Purpose:            Request a media description to be accepted
                        in the answer only if kept within a BUNDLE group
                        by the answerer.
    Appropriate values: N/A
    Contact name:       Christer Holmberg
    Contact e-mail:     [email-masked]
    Reference:          RFCXXXX

Regards,

Christer