Subject: [MMUSIC] IANA registry structure for IANA attributes

From: "Drage, Keith (Nokia - GB)" <[email-masked]>
Date: Tue, 5 Apr 2016 14:38:45 +0000

Firstly I agree with Cullen that if any RFC updates the semantics of an existing attribute (i.e. makes normative changes to it) then that RFC formally needs to update the prior RFC.

The registry should allow multiple references to RFCs where those RFCs make define additional semantics to an attribute, and MMUSIC should attempt to revise the attribute registry if these are missing.

I think the separation of attributes into multiple subregistries is a bit historical rather than something that is needed. I am not proposing taking it away (although conversely would not object if it did provided this information was normatively clear in the base RFCs), but it goes beyond what is required.

I do not think there is anything special about dcsa usage. Most dcsa usage does not change the semantics of the underlying attributes. Obviously if dcsa usage does change the semantics of an underlying attribute then the dcsa usage document should update the reference list. I do not think the msrp dcsa document makes any semantic change to any MSRP attributes - they can just be used.

I have a problem with a new DCSA level if it implies that an attribute cannot be used within dsca if it does not appear in this list.

Regards

Keith

---

From: "Drage, Keith (Nokia - GB)" <[email-masked]>
Date: Tue, 5 Apr 2016 14:50:17 +0000

I am listening to the discussion as it occurs in the meeting.

I do not really agree that dcsa is a something separate and special.

In general, anything that can be used at the media level can be used in dcsa. Mostly any usage will be determined on whether it still makes sense when used in dcsa.

There will generally be nothing to say about dcsa usage over and above that.

I do not want to create some new draft that has to work through all the existing attributes just to formally defined that.

Keith

-----Original Message-----
From: mmusic [mailto:[email-masked]] On Behalf Of EXT Drage, Keith (Nokia - GB)
Sent: 05 April 2016 15:39
To: [email-masked]
Subject: [MMUSIC] IANA registry structure for IANA attributes

Regards

Keith

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

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 5 Apr 2016 12:18:18 -0400

> The registry should allow multiple references to RFCs where those RFCs make define additional semantics to an attribute, and MMUSIC should attempt to revise the attribute registry if these are miss…

At least we agree on the above. :-)

But there is an ongoing debate on what sorts of things should be 
considered updates.

My desire is, given a sample usage of an attribute, to find the document 
that defines that usage. Preferably, I want to avoid having to read a 
lot of extraneous documents.

> I think the separation of attributes into multiple subregistries is a bit historical rather than something that is needed.

It predates my awareness of SDP, so I can only speculate about the 
thinking that led to it.

> I am not proposing taking it away (although conversely would not object if it did provided this information was normatively clear in the base RFCs), but it goes beyond what is required.

I *think* this info is available in documents for all the existing 
attributes, with regard to the session/media-level distinction.

And I think (without looking) that specifications for attributes that 
can be used at source level say so.

What *isn't* in existing documents in explicit indication that an 
attribute is *not* defined for use at source level.

I suppose this could be dealt with by having 4566bis specify that any 
attribute definition that doesn't explicitly specify validity at source 
level is *not* valid at source level.

(Note: there is only *one* attribute (fmtp) that is defined at source 
level *and* at another level.)

> I have a problem with a new DCSA level if it implies that an attribute cannot be used within dsca if it does not appear in this list.

Can't the same be said about session/media/source level?

In a syntactic sense I can use any attribute at any level. It is just 
that a lot of them won't be valid in many contexts.

Specifically regarding dcsa, it requires a new specification to say how 
a protocol that runs over UDP or TCP will be mapped onto a data channel. 
That mapping MAY say that all the attributes that apply on the original 
transport still apply on the data channel. Or maybe not. And which 
attributes are meaningful will still depend on which (sub)protocol is 
being run on that data channel.

Of course the same is true for the existing protocols. Not all 
attributes are meaningful with all m-line proto values. (For instance, 
many attributes are only meaningful with the RTP family of proto 
values.) And we don't (currently) put that info into the registry. 
(Maybe we should.)

This isn't a big deal if all the relevant documents can be found 
(directly or indirectly) from the references in the registry, and there 
aren't very many of those.

If we start to have numerous documents for an attribute, then having 
*something* in the registry to help choose among them would be helpful.

	Thanks,
	Paul

---

From: "Drage, Keith (Nokia - GB)" <[email-masked]>
Date: Tue, 5 Apr 2016 20:18:17 +0000

Paul said:

" But there is an ongoing debate on what sorts of things should be considered updates."

My view is it is anything that changes the definition of the attribute, i.e. something that extends the attribute or makes new general requirements (not just rescoping). Appearance in an example does not count.

Paul said:

" Can't the same be said about session/media/source level?"

My answer is that in my view we are still talking attributes essentially being used at media level. It just happens to relate to a media that is a subchannel within the datachannel, but it is still media. As such in general the attribute usage does not change, and no harm results. 

So my view is that all attributes that are defined as media attributes can be dcsa attributes (and we can add the caveat that "unless otherwise specified", but I do not think it will come up very often). Yes that needs to be written in a specification somewhere. I'd note that some will be also be disqualified for conditions already specified at source definition, like those any that relate specifically to rtp streams.

Keith

-----Original Message-----
From: mmusic [mailto:[email-masked]] On Behalf Of EXT Paul Kyzivat
Sent: 05 April 2016 17:18
To: [email-masked]
Subject: Re: [MMUSIC] IANA registry structure for IANA attributes

But there is an ongoing debate on what sorts of things should be considered updates.

My desire is, given a sample usage of an attribute, to find the document that defines that usage. Preferably, I want to avoid having to read a lot of extraneous documents.

> I think the separation of attributes into multiple subregistries is a bit historical rather than something that is needed.

It predates my awareness of SDP, so I can only speculate about the thinking that led to it.

> I am not proposing taking it away (although conversely would not object if it did provided this information was normatively clear in the base RFCs), but it goes beyond what is required.

I *think* this info is available in documents for all the existing attributes, with regard to the session/media-level distinction.

And I think (without looking) that specifications for attributes that can be used at source level say so.

What *isn't* in existing documents in explicit indication that an attribute is *not* defined for use at source level.

I suppose this could be dealt with by having 4566bis specify that any attribute definition that doesn't explicitly specify validity at source level is *not* valid at source level.

(Note: there is only *one* attribute (fmtp) that is defined at source level *and* at another level.)

In a syntactic sense I can use any attribute at any level. It is just that a lot of them won't be valid in many contexts.

Specifically regarding dcsa, it requires a new specification to say how a protocol that runs over UDP or TCP will be mapped onto a data channel. 
That mapping MAY say that all the attributes that apply on the original transport still apply on the data channel. Or maybe not. And which attributes are meaningful will still depend on which (sub)protocol is being run on that data channel.

Of course the same is true for the existing protocols. Not all attributes are meaningful with all m-line proto values. (For instance, many attributes are only meaningful with the RTP family of proto
values.) And we don't (currently) put that info into the registry. 
(Maybe we should.)

This isn't a big deal if all the relevant documents can be found (directly or indirectly) from the references in the registry, and there aren't very many of those.

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 5 Apr 2016 17:24:29 -0400

> My view is it is anything that changes the definition of the attribute, i.e. something that extends the attribute or makes new general requirements (not just rescoping). Appearance in an example do…

I'll agree with you that dcsa usage can be considered as a sub-case of 
media level.

> My answer is that in my view we are still talking attributes essentially being used at media level.

Source level also qualifies as a sub-case of media level. So why 
distinguish source level and not dcsa level?

> It just happens to relate to a media that is a subchannel within the datachannel, but it is still media. As such in general the attribute usage does not change, and no harm results.
>

We don't have any yet, but I expect will will eventually get some 
attributes that are only defined for use with data channel protocols, 
and so only with dcsa, not at the other "levels".

And if we are trying to simplify, why distinguish between session level 
and media level? Many attributes can be used both places. And almost all 
attributes have further constraints on where they can be used.

	Thanks,
	Paul