Re: [MMUSIC] IANA registration of SDP attributes

[Flemming Andreasen <[e-mail]>]

On 3/29/16 1:28 AM, Christian Groves wrote:
> Hello Paul,
>
> Please see below.
>
> Regards, Christian
>
> On 24/03/2016 8:59 AM, Paul Kyzivat wrote:
>> On 3/22/16 3:11 PM, Flemming Andreasen wrote:
>
<snip>
>>
>> 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.
> [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.
There is a difference between revising and extending usage. For 
extensions, we normally put a sub-registry and a set of associated 
extension procedures in place. Now, in the case of RFC4145, I don't 
believe it was envisioned to go beyond TCP originally, and hence 
extension procedures weren't actually defined at the time. Other 
protocol uses where later found to be able to use it as well, but again 
without any formal registry structure to make that clear. Do we have 
more examples like this or was this a special case (with relatively old 
origins) ?

>>
>> 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.)
> [CNG] Yes
>>
>> 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.
> [CNG] Agree

If you change either the syntax or semantic of the attribute, then by 
definition you have changed it and the reference would need to be updated.

If the attribute includes an extension mechanism, then as part of its 
definition, it needs to include instructions for how to do so, including 
IANA registration procedures (typically a sub-registry). Normally, this 
is easy to identify because extensions tend to involve new values and/or 
parameters of some sort (something syntactical). When the extension is 
merely semantic (e.g. applying it in a context it was not envisioned 
originally, like TLS rather than TCP), then it's less clear, because the 
attribute in question may not have considered that when it was defined 
originally and hence a formal extension mechanism and registration 
procedures do not exist. In such a case, I do think it's desirable to 
have the registry updated to include this new semantic - it makes it 
easiser to find what they are looking for (or should be looking for).

Thanks

-- Flemming