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

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

Hello Christian,

Thanks for your reply.
Please find my comments inserted below.

Thank you,
Juergen


On 09.03.2016 01:53, EXT Christian Groves wrote:
> Hello Juergen,
>
> What I was thinking was that:
> - If a subprotocol (datachannel) reuses media or session attributes a reference to the subprotocol 
> RFC is added to the IANA registration for the attribute only I there was some specific behaviour 
> change or consideration.

Here, do you have the existing "att-field (both session and media level)" and "att-field (media 
level only)" registries in mind? Thus do you think then the "Reference" field of the attribute's 
existing row in the "att-field (both session and media level)" or "att-field (media level only)" 
table would be extended?
In such a case I assume that multiple data channel subprotocol RFC references might be added to an 
existing attribute's "Reference" field, e.g. if two different data channel subprotocol RFCs reuse 
the same attribute and if both contain specific (but different, subprotocol depending) 
considerations for this attribute.  Should then also the corresponding subprotocol ids be added to 
the subprotocol document references? Would that be possible at all in the existing registries? 
(Otherwise somebody searching for a subprotocol specific meaning might need to review several 
documents until finding the one for the subprotocol he is interested in.)

[As an example, the msrp-usage-data-channel document describes data channel transport specific 
aspects of the "setup" attribute, hence the "Reference" field for the "setup" attribute in table 
"att-field (both session and media level)" would be extended with a reference to this 
msrp-usage-data-channel document. The "setup" attribute is also specifically mentioned in RFC 4583 
for BFCP. Potentially, a future version of draft-schwarz-mmusic-bfcp-usage-data-channel might also 
describe BFCP and data channel transport specific aspects for the "setup" attribute. In that case 
I'd assume that a reference to draft-schwarz-mmusic-bfcp-usage-data-channel would then also be added 
to the "Reference" field of the existing "setup" related row in table "att-field (both session and 
media level)".]

And if a data channel subprotocol reuses an existing attribute and keeps this attribute's original 
meaning, then this attribute's "att-field (both session and media level)" or "att-field (media level 
only)" table entry would not be modified, would it?

> - If a subprotocol RFC defines a data channel specific attribute (i.e. cannot be used at the media 
> or session level) then this would go into a new global IANA "data channel level" registry.
> - The data channel level attribute could be reused by multiple data channels so it should be 
> possible to include multiple references (my understanding of Flemming's point).
>
> I guess this is your (A)(i) below?

Actually, as far as I understand your description, I think that would be a variant of (A)(ii), which 
would use different registries - depending on whether an already existing attribute is reused for 
one or more data channel subprotocols (in which case the already existing attribute row is updated), 
or a new attribute is introduced by a data channel subprotocol specifying document (in which case 
the attribute would be added to an "att-field (data channel level)" table.

>
> If it is then I don't think its possible for a registry entry to be associated with zero document, 
> i.e. there must always be a document reference.

I agree that there would at least always be one document reference. (That's why I think that your 
description may be more related with (A)(ii)). When I wrote (A)(i) I was thinking of a registry 
containing all already existing attributes (like the merged registry which Paul mentioned), and 
where then (most of the) attributes would then not be associated with (a) data channel subprotocol 
defining document(s).

>
> Option B(i) seems to be a summary of what the RFC defining the sub-protocol would say. People can 
> find out what attributes are used by reading the RFC itself rather than an IANA registry. So I'm 
> not particularly in favour of that.
>
> Option B(ii) seems to be the same as A(i) with the lookup key being the sub-protocol id rather 
> than an attributeID. It seems the convention applied to SDP is lookup based on attribute rather 
> than protocol. E.g. there are other protocols that use multiple media or session level attributes 
> but they don't have their own registry.

Yes, agree, in both (B)(i) and (ii) the lookup keys would be the subprotocol id. And also agree that 
both (B) options seem to be rather new attribute registration approaches, which would primarily be 
based on subprotocol ids, rather than on the attribute names.

>
>
> Regards, Christian
>
> On 9/03/2016 12:51 AM, Juergen Stoetzer-Bradler wrote:
>> 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)
>>>>>
>>>>
>>>> .
>>>>
>>>