Subject: [MMUSIC] IANA registration of SDP attributes

From: Paul Kyzivat <[email-masked]>
Date: Thu, 10 Mar 2016 13:48:51 -0500

[splitting off from the thread on data-channel-sdpneg]

Currently IANA has five(!) separate registries for sdp attributes:

att-field (session level)
att-field (both session and media level)
att-field (media level only)
att-field (source level)
att-field (unknown level)

They all have the same format:

*Type**
* 	*SDP Name**
* 	*Reference**
*
att-field (session level) 	cat 	[RFC4566]
att-field (both session and media level) 	recvonly
	[RFC4566]
att-field (both session and media level) 	mediaclk
	[RFC7273]
att-field (media level only) 	accept-types
	[RFC4975]
att-field (media level only) 	fmtp
	[RFC4566]
att-field (source level) 	fmtp
	[RFC5576]

This format is a pain, because it is hard to look an attribute up if you 
don't know at what level(s) it is valid. It also has the potential to 
allow an attribute name to be registered for unrelated purposes if the 
type is different. (IMO that would be bad.)

A long time ago (several years now), as part of the 4566bis work, I 
proposed that these tables be merged into one. It was my impression that 
this was agreed and would be done. But I don't recall any agreement on 
the logistics of doing so.

My thought was that the combined table would look like:

*SDP Name* 	*Level(s)* 	*Reference(s)*
accept-types
	media
	[RFC4975]
cat
	session
	[RFC4566]
fmtp
	media,source 	[RFC4566][RFC5576]
mediaclk
	session,media,source
	[RFC7273]
ptime
	media
	[RFC4566]
recvonly
	session,media
	[RFC4566]

Then we get to data channel attributes. My thought is to incorporate 
them into this table structure, as yet another "level". E.g.,

*SDP Name* 	*Level(s)* 	*Reference(s)*
accept-types
	media,dcsa
	[RFC4975][draft-ietf-mmusic-msrp-usage-data-channel]
cat
	session
	[RFC4566]
fmtp
	media,source 	[RFC4566][RFC5576]
mediaclk
	session,media,source
	[RFC7273]
ptime
	media
	[RFC4566]
recvonly
	session,media,dcsa
	[RFC4566][RFC4975][draft-ietf-mmusic-msrp-usage-data-channel]

(And this could also be extended for websockets if somebody proposes a 
way to negotiate attributes for data channels too.)

Using this format, if you want to know more than the name and the 
level(s) at which it can be used you need to consult the references. And 
when there are multiple references you don't know which one(s) you need 
to consult. This can be "fixed" by including more information from the 
reference into the registry. Conversely, we could strip it down further 
and remove the levels from the registry - so you need to consult the 
references for that too.

For instance, if we wanted to simplify finding the right reference for 
the level you are interested in, we could do:

*SDP Name* 	*Level(s)* 	*Reference(s)*
accept-types
	media,
dcsa
	[RFC4975]
[draft-ietf-mmusic-msrp-usage-data-channel]
cat
	session
	[RFC4566]
fmtp
	media,source 	[RFC4566][RFC5576]
mediaclk
	session,media,source
	[RFC7273]
ptime
	media
	[RFC4566]
recvonly
	session,media,
dcsa
	[RFC4566][RFC4975]
[draft-ietf-mmusic-msrp-usage-data-channel]

Or we could go further, and break the dcsa level down by subprotocol:

*SDP Name* 	*Level(s)* 	*Reference(s)*
accept-types
	media,
dcsa(MSRP)
	[RFC4975]
[draft-ietf-mmusic-msrp-usage-data-channel]
cat
	session
	[RFC4566]
fmtp
	media,source 	[RFC4566][RFC5576]
mediaclk
	session,media,source
	[RFC7273]
ptime
	media
	[RFC4566]
recvonly
	session,media,
dcsa(MSRP)
	[RFC4566][RFC4975]
[draft-ietf-mmusic-msrp-usage-data-channel]

Thoughts?

     Thanks,
     Paul

---

From: Juergen Stoetzer-Bradler <[email-masked]>
Date: Fri, 11 Mar 2016 17:15:45 +0100

Paul,

The last alternative would have the advantage that different subprotocol documents could be 
referenced for the same attribute. Like e.g. for the setup attribute (if there were BFCP over data 
channel transport specific aspects):

*SDP Name* 	*Level(s)* 	*Reference(s)*
accept-types
	media,
dcsa(MSRP)
	[RFC4975]
[draft-ietf-mmusic-msrp-usage-data-channel]
cat
	session
	[RFC4566]
fmtp
	media,source 	[RFC4566][RFC5576]
mediaclk
	session,media,source
	[RFC7273]
ptime
	media
	[RFC4566]
recvonly
	session,media,
dcsa(MSRP)
	[RFC4566][RFC4975]
[draft-ietf-mmusic-msrp-usage-data-channel]
setup
	session, media
dcsa(MSRP)
dcsa(BFCP)
	[RFC4145]
[draft-ietf-mmusic-msrp-usage-data-channel]
[draft-schwarz-mmusic-bfcp-usage-data-channel]

Therefore I'd be in favor of your last alternative.

Thanks,
Juergen

On 10.03.2016 19:48, EXT Paul Kyzivat wrote:
> This format is a pain, because it is hard to look an attribute up if you don't know at what 
> level(s) it is valid. It also has the potential to allow an attribute name to be registered for 
> unrelated purposes if the type is different. (IMO that would be bad.)
>
> A long time ago (several years now), as part of the 4566bis work, I proposed that these tables be 
> merged into one. It was my impression that this was agreed and would be done. But I don't recall 
> any agreement on the logistics of doing so.
>
> Then we get to data channel attributes. My thought is to incorporate them into this table 
> structure, as yet another "level". E.g.,
>
> (And this could also be extended for websockets if somebody proposes a way to negotiate attributes 
> for data channels too.)
>
> Using this format, if you want to know more than the name and the level(s) at which it can be used 
> you need to consult the references. And when there are multiple references you don't know which 
> one(s) you need to consult. This can be "fixed" by including more information from the reference 
> into the registry. Conversely, we could strip it down further and remove the levels from the 
> registry - so you need to consult the references for that too.
>
> For instance, if we wanted to simplify finding the right reference for the level you are 
> interested in, we could do:
>
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 11 Mar 2016 11:46:53 -0500

On 3/11/16 11:15 AM, Juergen Stoetzer-Bradler wrote:
> Paul,
>
> The last alternative would have the advantage that different subprotocol
> documents could be referenced for the same attribute. Like e.g. for the
> setup attribute (if there were BFCP over data channel transport specific
> aspects):
>

Let's see what other comments we get, especially from Flemming.

Then, if this is preferred direction we can work on refining it.

	Thanks,
	Paul

>> This format is a pain, because it is hard to look an attribute up if
>> you don't know at what level(s) it is valid. It also has the potential
>> to allow an attribute name to be registered for unrelated purposes if
>> the type is different. (IMO that would be bad.)
>>
>> proposed that these tables be merged into one. It was my impression
>> that this was agreed and would be done. But I don't recall any
>> agreement on the logistics of doing so.
>>
>> level(s) at which it can be used you need to consult the references.
>> And when there are multiple references you don't know which one(s) you
>> need to consult. This can be "fixed" by including more information
>> from the reference into the registry. Conversely, we could strip it
>> down further and remove the levels from the registry - so you need to
>> consult the references for that too.
>>

---

From: Christian Groves <[email-masked]>
Date: Sun, 20 Mar 2016 13:27:45 +1100

With the current registry don't only documents that introduce NEW 
attributes get included in the registry?

dcsa (MSRP) and dcsa (BFCP) don't define new attributes they use setup. 
This is similar to the fact that multiple protocols at the media level 
use a=setup but we don't add references to them in the registry.

So do we now say that if a draft/RFC uses an existing media level 
attribute in a DCSA that must be added to the registry with a dcsa 
indication?

Regards, Christian

---

From: Paul Kyzivat <[email-masked]>
Date: Sun, 20 Mar 2016 13:48:54 -0400

> attribute in a DCSA that must be added to the registry with a dcsa

ISTM that a document that broadens the applicability of an attribute 
ought to be recorded in the registry.

I expect that this is a bit fuzzy. For instance, the use of setup with 
TCP was defined. If a new proto of 'TCP/FOO' is defined that runs over 
TCP, and simply uses setup for establishing the TCP part, then maybe it 
doesn't need to be recorded in the registry.

But if setup is used for something other than TCP, or also used for some 
semantic over and above its use for TCP, then it surely ought to be 
recorded. (For instance, when it is used to control initialization of 
some other protocol over TCP.)

I expect that this is less than clear, and may be controversial. Seems 
to need more discussion.

	Thanks,
	Paul

---

From: Christian Groves <[email-masked]>
Date: Tue, 22 Mar 2016 12:21:07 +1100

Hello Paul,

Yes I think it is fuzzy. draft-ietf-mmusic-sctp-sdp is using a=setup for 
SCTP, by the definition below it would need to update the registry to 
add a reference. There's probably other attributes where this is the 
case also (e.g. a=connection). For consistency all the existing 
attributes would need to be checked when reformatting the registry.

I do agree that it would be nice to have a link from each SDP attribute 
to the RFCs that are using it but I think the genie is out of the bottle 
on this one.

With the light agenda maybe this is something to discuss in Argentina?

Regards, Christian

On 21/03/2016 4:48 AM, Paul Kyzivat wrote:
> TCP, and simply uses setup for establishing the TCP part, then maybe 
> it doesn't need to be recorded in the registry.
>
> But if setup is used for something other than TCP, or also used for 
> some semantic over and above its use for TCP, then it surely ought to 
> be recorded. (For instance, when it is used to control initialization 
> of some other protocol over TCP.)
>

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 22 Mar 2016 11:19:02 -0400

> With the light agenda maybe this is something to discuss in Argentina?

I won't be there, but will try to call in. For once the time difference 
isn't much for me!

	Thanks,
	Paul

---

From: Flemming Andreasen <[email-masked]>
Date: Tue, 22 Mar 2016 15:11:05 -0400

On 3/21/16 9:21 PM, Christian Groves wrote:
> Hello Paul,
>
> Yes I think it is fuzzy. draft-ietf-mmusic-sctp-sdp is using a=setup 
> for SCTP, by the definition below it would need to update the registry 
> to add a reference. There's probably other attributes where this is 
> the case also (e.g. a=connection). For consistency all the existing 
> I do agree that it would be nice to have a link from each SDP 
> attribute to the RFCs that are using it but I think the genie is out 
> of the bottle on this one.
>
Do we have a volunteer to drive the discussion there ?

Thanks

-- Flemming

>> I expect that this is a bit fuzzy. For instance, the use of setup 
>> with TCP was defined. If a new proto of 'TCP/FOO' is defined that 
>> runs over TCP, and simply uses setup for establishing the TCP part, 
>> then maybe it doesn't need to be recorded in the registry.
>>
>> I expect that this is less than clear, and may be controversial. 
>> Seems to need more discussion.
>>
>>     Thanks,
>>     Paul
>>
>>> Regards, Christian
>>>
> .

---

From: Christian Groves <[email-masked]>
Date: Wed, 23 Mar 2016 07:22:40 +1100

Hello Flemming,

I thought Paul would be a good person as he seems to have a vision for 
the registry. However if Paul (and Juergen) isn't going to be in the 
room I'm not sure how effective the discussion will be. If you still 
feel if it would be worth it then I can put a couple of slides together.

Regards, Christian

On 23/03/2016 6:11 AM, Flemming Andreasen wrote:
>> for SCTP, by the definition below it would need to update the 
>> registry to add a reference. There's probably other attributes where 
>> this is the case also (e.g. a=connection). For consistency all the 
>> existing attributes would need to be checked when reformatting the 
>> registry.
>>
>>> some semantic over and above its use for TCP, then it surely ought 
>>> to be recorded. (For instance, when it is used to control 
>>> initialization of some other protocol over TCP.)
>>>

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 23 Mar 2016 17:59:38 -0400

> Do we have a volunteer to drive the discussion there ?

OK. I'll volunteer.

The starting point for this discussion is the current text of section 
8.2.4 of rfc4566bis-16.

Looking at that, one thing leaps out at me:

There is a long list of "stuff" that must be provided when defining a 
new attribute. IMO it is all *good* stuff, that should be provided. But 
it also strikes me that it will be difficult for IANA to evaluate the 
adequacy of this stuff itself. So we might want to require an expert 
review as a gate to registration.

The other thing, that this thread has been discussing, is that this only 
covers definitions of new attributes.

What it doesn't cover are *new* usages of existing attributes. What 
isn't covered are cases that *revise* the definition of an existing 
attribute. For instance, the IANA registry entries for the 'setup' and 
'connection' attributes only reference RFC4145. (For use with TCP.) But 
these attributes are also used in contexts (with proto values) not 
covered by that RFC. For instance, RFC4572 defines a new proto TCP/TLS, 
and reuses 'setup' and 'connection'. The semantics are mostly the same, 
but additional behavior triggered by these is added on. Perhaps the 
registry entries for these attributes should also reference this RFC. In 
principle, in cases where it matters this behavior can be discovered by 
looking up the references for the TCP/TLS proto. But if you are 
particularly interested in what the setup attribute is doing then it 
might not occur to you to look there.

In that case, the relationship to the original definition is pretty 
clear, since it is still TLS over TCP. It is less clear when used with a 
protocol entirely distinct from TCP. For instance we have active drafts 
draft-ietf-mmusic-sctp-sdp and draft-ietf-mmusic-dtls-sdp. These both 
reuse 'setup', and sctp-sdp reuses 'connection', while dtls-sdp has 
chosen an alternative to 'connection'. They also layer on additional 
behavior. And dtls-sdp also forbids use of some of the values defined in 
4145 for setup.

IMO it would be good if the registry for 'setup' referenced all of 
these, and that for 'connection' referenced these with the exception of 
dtls-sdp that doesn't use it. This is because these are extending the 
semantics of the attributes.

But it seems less critical as long as these other documents are 
otherwise discoverable from actual uses. (Such as checking the 
references for the proto value in the m-line associated with these uses.)

But IMO it would be essential if the syntax of the attribute is revised.

As you can see, I am a bit ambivalent on this. That is why I think it 
needs discussion.

	Thanks,
	Paul

---

From: Christian Groves <[email-masked]>
Date: Tue, 29 Mar 2016 16:28:14 +1100

Hello Paul,

Please see below.

Regards, Christian

On 24/03/2016 8:59 AM, Paul Kyzivat wrote:
> new attribute. IMO it is all *good* stuff, that should be provided. 
> But it also strikes me that it will be difficult for IANA to evaluate 
> the adequacy of this stuff itself. So we might want to require an 
> expert review as a gate to registration.
[CNG] What's the role of the SDP directorate in relation to this? I 
guess they would check any RFC defined attributes but that non-RFCs 
would also need to be checked? How much of this should be visible on the 
IANA registry page?

[CNG] Also in 8.2.4 there's bullet points for "Attribute Name" and "An 
ABNF definition..." both these mention ABNF definitions. What's the 
distinction?

>
> The other thing, that this thread has been discussing, is that this 
> only covers definitions of new attributes.
>
> 'connection' attributes only reference RFC4145. (For use with TCP.) 
> But these attributes are also used in contexts (with proto values) not 
> covered by that RFC. For instance, RFC4572 defines a new proto 
> TCP/TLS, and reuses 'setup' and 'connection'. The semantics are mostly 
> the same, but additional behavior triggered by these is added on. 
> Perhaps the registry entries for these attributes should also 
> reference this RFC. In principle, in cases where it matters this 
> behavior can be discovered by looking up the references for the 
> TCP/TLS proto. But if you are particularly interested in what the 
> setup attribute is doing then it might not occur to you to look there.
>
> clear, since it is still TLS over TCP. It is less clear when used with 
> a protocol entirely distinct from TCP. For instance we have active 
> drafts draft-ietf-mmusic-sctp-sdp and draft-ietf-mmusic-dtls-sdp. 
> These both reuse 'setup', and sctp-sdp reuses 'connection', while 
> dtls-sdp has chosen an alternative to 'connection'. They also layer on 
> additional behavior. And dtls-sdp also forbids use of some of the 
> values defined in 4145 for setup.
>
> these, and that for 'connection' referenced these with the exception 
> of dtls-sdp that doesn't use it. This is because these are extending 
> the semantics of the attributes.
[CNG] This is the big issue. It will mean an effort to bring the 
registry up to the current state and more effort to ensure that it 
remains current. It probably comes down to whether people see the 
registry as a simple tool to register unique names or something more.
> references for the proto value in the m-line associated with these uses.)
[CNG] Yes
> As you can see, I am a bit ambivalent on this. That is why I think it 
[CNG] Agree

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 29 Mar 2016 13:48:32 -0400

> would also need to be checked? How much of this should be visible on the

The SDP directorate will only be invoked for ietf documents. The policy 
for attributes is Specification Required, so it might be a document from 
another SDO, ore even no SDO. In those cases there would be no SDP 
directorate review.

After refreshing my memory about the definition of Specification 
Required, I see that it implies Expert Review. (Flemming is currently 
listed as the expert.) That may be good enough, though we might want to 
beef up the requirements in section 8.2.4 of 4566bis.

The hard part is seeing to any new actions when *existing* attributes 
are used in new ways. For that I think the SDP Directorate is all we 
have to check for that sort of thing. I wonder if there ought to be a 
checklist of things for SDP Directorate reviews.

And of course *that* also will only work for IETF documents. If somebody 
outside the IETF defines a new use for an existing attribute then we 
have no mechanism to notice that and trigger an update to the registry.

> ABNF definition..." both these mention ABNF definitions. What's the

You are referring to:

    o  Attribute value: The name of an ABNF syntax rule defining the
       syntax of the value.  Absence of a rule name indicates that the
       attribute takes no value.  Enclosing the rule name in "[" and "]"
       indicates that a value is optional.
...
    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 MUST NOT be defined as an Incremental Alternative to <att-
       value>.

The first of those is the *name* of an ABNF rule. The 2nd is the 
*definition* of that rule.

I split it up that way in order to avoid including an ABNF rule for the 
whole attribute (including the "a=") because that has been a problem.

	Thanks,
	Paul