Re: [MMUSIC] IANA registry structure for IANA attributes

["Drage, Keith (Nokia - GB)" <[e-mail]>]

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:[e-mail]] On Behalf Of EXT Paul Kyzivat
Sent: 05 April 2016 17:18
To: [e-mail]
Subject: Re: [MMUSIC] IANA registry structure for IANA attributes

On 4/5/16 10:38 AM, Drage, Keith (Nokia - GB) wrote:
> 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.

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 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.

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

> Regards
>
> Keith
>
> _______________________________________________
> mmusic mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mmusic
>

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