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
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic
>