Re: [MMUSIC] WGLC for draft-ietf-mmusic-data-channel-sdpneg

[Juergen Stoetzer-Bradler <[e-mail]>]

Flemming, Paul, Christian,

Trying to summarize, as per my understanding following three main options (A), (B) and (C) have been 
discussed in this email thread regarding the IANA registration of SDP attributes.

(A) "One new global IANA registry for data channel subprotocol attributes, common for all data 
channel subprotocols":
Similar to IANA's RTP source level attribute registry a global IANA "data channel level" attribute 
registry could be created.
     (i) Either, this registry could list all existing (and potential future) attributes, and for 
each attribute could state if it could also be used as dcsa embedded attribute associated with 
certain data channel subprotocols. Each attribute within this registry might then be associated with 
zero, one or multiple document references, where each referenced document should describe this 
attribute's semantic and usage for a specific subprotocol. (Which would not exclude one document 
describing an attribute's semantic and usage for more than just one data channel subprotocol.)
     (ii) Or, this registry could list only those existing (and potential future) attributes, which 
have already been identified as data channel subprotocol attributes. All such already  identified 
data channel subprotocol attributes could be listed in that registry, regardless of whether or not 
the usage of these attributes is specific for data channel transport. Each attributes listed in this 
registry could be associated with one or multiple document references. Each such a reference could 
point to a document which could either describe the data channel transport specific usage of this 
attribute for one or several data channel subprotocols. Or such a reference could point to the 
document, which defines this attribute in a data channel independent / generic way (if usage of this 
attribute does not have data channel transport specific aspects).
     (iii) Or, this registry could only list those existing (and potential future) attributes, which 
have already been identified as data channel subprotocol attributes, and whose usage is indeed data 
channel transport specific. Similar as in (ii) each attribute listed in this registry could be 
associated with one or multiple document references. Each such reference could point to a document 
which could describe the data channel transport specific usage of this attribute for one or several 
data channel subprotocols.

(B) "For each data channel subprotocol one new dedicated attribute registry":
The document, which requests to add the data channel subprotocol's identifier to the IANA WebSocket 
subprotocol name registry, could additionally request to create a new IANA registry, specific for 
this subprotocol, which could list all attributes, which can be used as a=dcsa embedded attributes 
for this data channel subprotocol. Similar as in (A) there seem to be (at least) two sub-options:
     (i) Either, this subprotocol specific registry could list all attributes, which could be used 
for this subprotocol (and have already been identified as such) in case of data channel transport. 
Each such attribute could then be associated with exactly one document reference, where this 
reference either could point to a document, which describes the data channel transport specific 
usage of this attribute for this specific subprotocol, or could point to a document, which specifies 
this attribute in a data channel independent way.
     (ii) Or, this subprotocol specific registry could only list those attributes, which could be 
used for this subprotocol, and which have a data channel transport specific semantic. Each such 
attribute could then be associated with a document describing this data channel transport specific 
semantic for this subprotocol.

(C) "No data channel specific registry(s) - re-use of the already existing session and media level 
or media level only registries":
The document, which requests to add the data channel subprotocol's identifier to the IANA Websocket 
subprotocol id registry, could additionally describe the usages of those attributes, which may be 
used for this data channel subprotocol, and whose usages and/or semantics have data channel 
transport specific aspects. However, if those attributes did already exist prior to the creation of 
this data channel subprotocol document, then the already existing IANA registrations of those 
attributes would not be modified. If this data channel subprotocol describing document introduced 
new subprotocol specific attributes, then it could request these to be added to the exiting media 
level only attribute registry. Subsequently, if a later document introduces new attributes, which 
could also be used for that subprotocol in the data channel transport case, then that later document 
could describe this data channel subprotocol specific usage, and could also add these attributes to 
the existing session and media level or media level only attribute registry.


If I am not mistaken then (A)(i) was the option which Paul initially mentioned in this email thread. 
And Paul also mentioned a variant, where the already existing attribute registries could be merged 
into just one, where a new field could be added describing the attribute's scope (which then could 
contain more than just one scope), and where also 'data channel level' could be an attribute's 
scope. In such a case different scopes might potentially refer to different documents.
In his last email Christian did also refer to option (A), I think.
Option (B) was mentioned by Flemming, where he expressed a preference for (B)(i), as far as I 
understood.
Option (C) is the one which is (to the most part) described in current version 08 of 
draft-ietf-mmusic-data-channel-sdpneg.

Would there be another option, which I haven't described above?

Would there be one (sub-)option, everybody could live with?

Based on this discussion, if option (C) isn't agreeable, then I myself would prefer option (B), with 
a tendency to (B)(ii), as this might provide more flexibility for implementations, which want to use 
an attribute for a data channel subprotocol with its original (data channel transport independent) 
semantic, also if this attribute has not been added to the data channel subprotocol specific 
attribute registry. And as I still think that most of those attributes would be used transport 
protocol stack independently.

Thanks again,
Juergen



On 08.03.2016 04:04, EXT Flemming Andreasen wrote:
>
>
> On 3/6/16 7:04 PM, Christian Groves wrote:
>> Hello Flemming and Juergen,
>>
>> ..snip..
>>>> I agree that in such cases such new attributes could indeed be added to corresponding data 
>>>> channel subprotocol specific attribute registries, which then could refer to the document 
>>>> introducing this new attribute.
>>> Right - and for consistency I think it then makes sense to have all subprotocol-specific 
>>> attributes registered there.
>>>
>>>> An alternative might be to only add such a new SDP attribute to the generic IANA SDP attribute 
>>>> registry (which probably would be done anyhow). I assume that the generic SDP attribute 
>>>> registry would also refer to the document introducing this new attribute.
>>>>
>>> Either would work, however my preference would be a complete listing of attributes that have 
>>> subprotocol specific meaning.
>>>
>>> I'd be interested in what other people think though
>>
>> From looking at the existing IANA registry 
>> http://www.iana.org/assignments/sdp-parameters/sdp-parameters.xhtml
>>
>> It feels like we should take the approach for att-field (source level) and define att-field (data 
>> channel).
>>
> Thanks for the feedback Christian. Just to be clear: We would need to allow for multiple entries 
> per attribute, since different sub-protocols could each define sub-protocol specific behavior for 
> an attribute.
>
> Thanks
>
> -- Flemming
>
>
>> Regards, Christian
>>
>>>
>>>
>>> Thanks
>>>
>>> -- Flemming (with my individual hat on)
>>>
>>
>> .
>>
>