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

From: Flemming Andreasen <[email-masked]>
Date: Tue, 1 Mar 2016 17:26:12 -0500

On 2/23/16 8:28 AM, Juergen Stoetzer-Bradler wrote:
> Flemming,
>
> Thanks for further feedback. Regarding your comments:
>> So far so good, however the case I had in mind is one where the new 
>> attribute would apply to one or more existing subprotocols.
> and
>> While that is certainly a valid use case, I wasn't thinking of 
>> restricting it to that and hence the request for an actual 
>> sub-registry for each of these subprotocols to register attributes 
>> that can be used with each of them (some attributes may apply to 
>> multiple). 
>
> Ok, as per my understanding such a new attribute would be introduced 
> in a (let's assume) future document. I think that such a future 
> document should describe the new attribute's semantic with respect to 
> all protocols for which it is intended to be used. And if one of these 
> protocols can be transported over data channels, and if the new 
> attribute's meaning then also has data channel specific aspects, this 
> future document should also describe those aspects. If this new 
> attribute is then added to the IANA SDP attribute registry (presumably 
> as media level only or media and session level attribute), then this 
> document could be found when searching for the new attribute.
>
Agreed.
> I am not yet sure I fully understand how such subprotocol specific 
> registries could be used. Right now there are already drafts 
> describing MSRP, BFCP and T.140 as data channel subprotocols. Do you 
> think IANA registry tables for each of these subprotocols should be 
> created (and in future for any further protocol, which might be used 
> as data channel subprotocol)?
> Where then a new attribute might be listed in multiple of these 
> subprotocol specific registries, depending on which subprotocol it 
> might be used for?
> And all already existing attributes, which might also be used for a 
> data channel subprotocol - do you think that these should also be 
> added to such subprotocol specific registry tables?
>
Going a few e-mails back in this thread, the below was your proposal:
<quote>
...the sdpneg draft might recommend SDP offerers and answerers to always 
add a subprotocol identifier to a data channel's dcmap attribute if dcsa 
embedded attributes are also negotiated for the data channel's 
subprotocol. I also think we could explicitly add text to sdpneg saying 
that subprotocol identifiers should be added to the IANA Websocket (and 
in future combined data channel) registry. And that this registration 
should be done via a document, which then explicitly describes the 
usages and semantics of dcsa embedded subprotocol attributes, _if_ those 
usages or semantics deviate from cases, where these attributes are not 
dcsa encapsulated. I think that in those cases, where the usage and 
meaning of an attribute (always related to the data channel's 
subprotocol) does not deviate from the non-dcsa encapsulated use cases, 
such an attribute may not explicitly need to be described for data 
channel usage. But I think it might be helpful to explicitly say so in 
the sdpneg draft.
</quote>

The key part (for me) in the above is to only have the subprotocol 
specific registration when the usage or semantic is subprotocol 
specific. Thus, I do not envision already existing attributes to be 
added here (unless there is subprotocol specific usage in which case a 
new document will need to define that).

> Coming back to MSRP as an example - RFC 5547 defines several file 
> transfer related attributes. Conceivably, a future document could 
> define another file transfer protocol unequal to MSRP (and based on 
> data channel transport, or based on a transport protocol unequal to 
> data channel). And that potential future document might then describe 
> how (some of) the file transfer related SDP attributes might be 
> re-used for this new file transfer protocol. Would you then expect 
> these file transfer related SDP attributes to be added to such a new 
> registry associated with the new file transfer protocol? Also if data 
> channel transport of this potential new file transfer protocol were 
> not defined in that assumed future document?
>
Only if their usage with this new file transfer protocol differed from 
the existing usage. The registry would essentially convey that there is 
subprotocol specific behavior with a reference to the relevant document. 
Conversely, if there is no entry in the registry, there is no 
subprotocol specific behavior defined.

> Right now I'm not sure if this topic is only data channel specific. 
> E.g. the a=setup attribute was originally introduced in RFC 4145 for 
> TCP connection negotiation. Later on, this attribute was reused for 
> TLS connection negotiation (RFC 4572) and DTLS association negotiation 
> (RFC 5763, draft-ietf-mmusic-sctp-sdp, draft-ietf-mmusic-dtls-sdp). As 
> far as I see the IANA SDP parameters registry for the a=setup 
> attribute only refers to RFC 4145. And the two sctp-sdp and dtls-sdp 
> drafts don't seem to request updating this registry. However, all 
> these documents have setup attribute related texts describing the 
> extended semantics of the setup attribute.
>
Fair point - there probably should be some references there.

> Somebody seeing an SDP offer like the UDP/DTLS/SCTP related one in 
> section 13.1 of draft-ietf-mmusic-sctp-sdp-15, when looking for the 
> setup attribute's usage in this SDP offer and when therefore searching 
> the related reference in the IANA SDP attribute registry, would only 
> find the reference to RFC 4145. However, he/she could look up the 
> UDP/DTLS/SCTP m-line proto value in the IANA SDP proto registry, and 
> there would find the reference to the future RFC of 
> draft-ietf-mmusic-sctp-sdp, where the semantic of the setup attribute 
> within this SDP offer instance is specified.
>
> Somebody seeing an SDP offer like the DTLS-SRTP related one in section 
> 7.1 of RFC 5763, again when trying to find the semantic of the setup 
> attribute in this SDP offer, would similarly find the reference to RFC 
> 4145. When searching the proto registry for UDP/TLS/RTP/SAVP he/she 
> would find the reference to RFC 5764. RFC 5764 does not mention the 
> setup attribute at all, but RFC 5763 does and describes its usage in 
> the DTLS-SRTP case. [But then it might not be clear if this setup 
> attribute is used in the original sense of RFCs 5763 / 5764, or with 
> the modified semantic described in draft-ietf-mmusic-dtls-sdp (which 
> excludes value 'holdconn').]
>
> In these cases, do you think that subprotocol (TLS and DTLS as 
> "subprotocols" of TCP and UDP) specific sub-registries should be 
> created? And if yes, how do you envision those would be used?
>
I don't think we should create those, because in general, attributes 
have a well-defined meaning that applies across protocols (unless the 
attribute is specifically defined for a single protocol or profile, e.g. 
RTP). Once we deviate from that principle (e.g. by explicitly defining 
sub-protocol specific usage for a given attribute), then I do think it's 
appropriate to have that reflected in a registry so people can figure 
out what they need to look at.

Thanks

-- Flemming

> Thanks,
> Juergen
>
>
> On 19.02.2016 18:24, EXT Flemming Andreasen wrote:
>>
>>
>> On 2/19/16 8:56 AM, Juergen Stoetzer-Bradler wrote:
>>> Flemming,
>>>
>>> Regarding
>>>> Sounds reasonable with the caveat that you may have attributes 
>>>> defined for use with a particular sub-protocol outside the 
>>>> subprotocol draft itself (e.g. because such an attribute was either 
>>>> defined subsequently or its use with a specific subprotocol is 
>>>> defined subsequently). If so, we would need an IANA registry 
>>>> structure (under SDP) that for each subprotocol defines the set of 
>>>> attributes that have been defined with specific semantics for that 
>>>> subprotocol. 
>>>
>>> Let's assume a future document defines how to establish MSRP 
>>> sessions over a transport protocol unequal to TCP, TLS, or data 
>>> channel, and that this document also defines a new MSRP related 
>>> attribute, whose semantic is only defined for this new transport 
>>> case (like a maximal MSRP chunk size specific for the new 
>>> transport). I assume that this future document would request to add 
>>> this new attribute to one of the existing IANA SDP attribute tables 
>>> (assumingly to the "att-field (media level only)" table).
>> So far so good, however the case I had in mind is one where the new 
>> attribute would apply to one or more existing subprotocols .
>>> Let's further assume that an implementation creates an SDP offer for 
>>> an MSRP session over a data channel and adds this new attribute as 
>>> dcsa embedded MSRP subprotocol attribute (for whatever reasons).
>>>
>>> Somebody seeing and inspecting this SDP offer could use the dcmap 
>>> attribute's subprotocol value "MSRP" to get a reference to the 
>>> msrp-usage-data-channel document. That document would not mention 
>>> that new attribute at all. The next step could then be to consult 
>>> the IANA SDP tables, and there this new attribute would be found 
>>> together with a reference to this future document.
>>> As assumingly this new MSRP related attribute would only be defined 
>>> for this new transport,
>> While that is certainly a valid use case, I wasn't thinking of 
>> restricting it to that and hence the request for an actual 
>> sub-registry for each of these subprotocols to register attributes 
>> that can be used with each of them (some attributes may apply to 
>> multiple).
>>
>>> I think this new attribute should then be ignored by the recipient 
>>> of this SDP offer.
>>> Section 5.2.5 of most recent 
>>> draft-ietf-mmusic-data-channel-sdpneg-08 now contains two related 
>>> recommendations:
>>>
>>> 'SDP offer or answer has an "a=dcsa" attribute, whose subprotocol 
>>> attribute is unknown.
>>>  *  The receiver of such an SDP offer or answer SHOULD ignore this 
>>> entire "a=dcsa" attribute line.
>>>
>>> SDP offer or answer has an "a=dcsa" attribute, whose subprotocol 
>>> attribute is known, but whose subprotocol attribute semantic is not 
>>> known for the data channel transport case.
>>>  *  The receiver of such an SDP offer or answer SHOULD ignore this 
>>> entire "a=dcsa" attribute line.'
>>>
>>> Would these recommendations address the case you are describing?
>>>
>> They only address the case(s) partally per the above.
>>
>> Thanks
>>
>> -- Flemming
>>
>>
>>> Thanks,
>>> Juergen
>>>
>>>
>>>
>>> On 18.02.2016 20:03, EXT Flemming Andreasen wrote:
>>>>
>>>>
>>>> On 2/14/16 5:48 AM, Juergen Stoetzer-Bradler wrote:
>>>>> Flemming,
>>>>>
>>>>> Regarding
>>>>>> It would probably simplify the overall SDP negotiation part, but 
>>>>>> I don't know if it would constrain the way data channels were 
>>>>>> envisioned to be used. 
>>>>>
>>>>> On Friday Paul mentioned in his email two potential use cases, 
>>>>> where no subprotocol identifiers might be added to a data 
>>>>> channel's dcmap attribute. In my last email I hadn't thought of 
>>>>> such cases. If we don't want to exclude such cases, then requiring 
>>>>> the subprotocol ids always to be present might indeed be too 
>>>>> restrictive.
>>>>>
>>>>> Regarding
>>>>>> Ok. Going back to discussion between Paul and I, do you believe 
>>>>>> that in for an attribute to be encapsulated in dcsa, the 
>>>>>> attribute MUST have been explicitly define to support this 
>>>>>> (Paul's suggestion below) or do you believe that this is overly 
>>>>>> constraining, and if so, how shoud we relax it ? 
>>>>>
>>>>> I now think that the sdpneg draft might recommend SDP offerers and 
>>>>> answerers to always add a subprotocol identifier to a data 
>>>>> channel's dcmap attribute if dcsa embedded attributes are also 
>>>>> negotiated for the data channel's subprotocol. I also think we 
>>>>> could explicitly add text to sdpneg saying that subprotocol 
>>>>> identifiers should be added to the IANA Websocket (and in future 
>>>>> combined data channel) registry. And that this registration should 
>>>>> be done via a document, which then explicitly describes the usages 
>>>>> and semantics of dcsa embedded subprotocol attributes, _if_ those 
>>>>> usages or semantics deviate from cases, where these attributes are 
>>>>> not dcsa encapsulated. I think that in those cases, where the 
>>>>> usage and meaning of an attribute (always related to the data 
>>>>> channel's subprotocol) does not deviate from the non-dcsa 
>>>>> encapsulated use cases, such an attribute may not explicitly need 
>>>>> to be described for data channel usage. But I think it might be 
>>>>> helpful to explicitly say so in the sdpneg draft.
>>>>>
>>>>> Somebody inspecting an SDP offer or answer, which was generated by 
>>>>> an implementation following these two recommendations (and which 
>>>>> hence contains an IANA registered subprotocol id if it contains 
>>>>> any dcsa embedded attributes), could then refer to that IANA 
>>>>> table, would then find the reference to the document, which 
>>>>> defines this subprotocol id for data channel usage, and there 
>>>>> could check if any of the dcsa embedded attributes has a data 
>>>>> channel specific semantic. If yes, that specific semantic would be 
>>>>> described in that document. If such a specific semantic were not 
>>>>> described in that document, then the default usage and semantic of 
>>>>> the attribute would apply also to that data channel transport case.
>>>>>
>>>> Sounds reasonable with the caveat that you may have attributes 
>>>> defined for use with a particular sub-protocol outside the 
>>>> subprotocol draft itself (e.g. because such an attribute was either 
>>>> defined subsequently or its use with a specific subprotocol is 
>>>> defined subsequently). If so, we would need an IANA registry 
>>>> structure (under SDP) that for each subprotocol defines the set of 
>>>> attributes that have been defined with specific semantics for that 
>>>> subprotocol.
>>>>
>>>>
>>>>> But in that context I'd have an IANA table related question.
>>>>> A certain subprotocol might be defined for Websocket usage as well 
>>>>> as for data channel usage. MSRP is already such a case, where 
>>>>> draft-ietf-mmusic-msrp-usage-data-channel defines how to use MSRP 
>>>>> over data channels, and where draft-pd-dispatch-msrp-websocket 
>>>>> defines how to use MSRP over Websockets.
>>>>> Would the IANA WebSocket Subprotocol Name Registry on 
>>>>> http://www.iana.org/assignments/websocket/websocket.xml then 
>>>>> contain two MSRP related rows? Or just one row containing 
>>>>> references to both the Websocket and data channel documents?
>>>>> Should we add related text to the IANA registration section of the 
>>>>> sdpneg draft?
>>>> See above.
>>>>
>>>> Thanks
>>>>
>>>> -- Flemming
>>>>>
>>>>> Thanks,
>>>>> Juergen
>>>>>
>>>>>
>>>>> On 12.02.2016 15:52, EXT Flemming Andreasen wrote:
>>>>>>
>>>>>>
>>>>>> On 2/12/16 5:45 AM, Juergen Stoetzer-Bradler wrote:
>>>>>>> Flemming, Paul,
>>>>>>>
>>>>>>> The current a=dcmap related text in 
>>>>>>> draft-ietf-mmusic-data-channel-sdpneg doesn't require that the 
>>>>>>> 'subprotocol' parameter must always be present - rather it is 
>>>>>>> specified as an optional parameter. Thus, current sdpneg text 
>>>>>>> would allow to create an SDP offer for a data channel, which 
>>>>>>> contains one a=dcmap attribute and potentially multiple a=dcsa 
>>>>>>> attributes without the subprotocol actually being given. Based 
>>>>>>> on this discussion I am wondering if the subprotocol parameter 
>>>>>>> should actually be mandatory.
>>>>>>>
>>>>>> It would probably simplify the overall SDP negotiation part, but 
>>>>>> I don't know if it would constrain the way data channels were 
>>>>>> envisioned to be used.
>>>>>>
>>>>>>
>>>>>>> In the specific case of MSRP, the msrp-usage-data-channel draft 
>>>>>>> says in 5.1.1.1 that the dcmap attribute includes the label and 
>>>>>>> subprotocol parameters. The current text could possible be made 
>>>>>>> more explicit by saying that the 'subprotocol="MSRP"' parameter 
>>>>>>> must always be present.
>>>>>>> Have just submitted version 04 of the msrp-usage-data-channel 
>>>>>>> draft, which proposes to add subprotocol identifier "MSRP" to 
>>>>>>> the WebSocket Subprotocol Name registry. This registry would 
>>>>>>> then associate subprotocol id "MSRP" with the 
>>>>>>> msrp-usage-data-channel document.
>>>>>>> There, in section 5.1.1.2 the MSRP specific usages of the a=dcsa 
>>>>>>> attribute are specified. And there the MSRP specific SDP 
>>>>>>> attributes, which can be dcsa embedded, are described.
>>>>>>> 'setup' is an attribute, whose semantic changes when being dcsa 
>>>>>>> embedded and associated with subprotocol MSRP, as compared to 
>>>>>>> the meaning of an "a=setup" media level attribute of a TCP/MSRP 
>>>>>>> m-line. Hence these semantical differences are explicitly 
>>>>>>> addressed in the msrp-usage-data-channel draft.
>>>>>>>
>>>>>>> Regarding sdpneg, I also think that the current text in sdpneg 
>>>>>>> seems to be sufficient regarding the usage of dcsa encapsulated 
>>>>>>> SDP attributes as being bound to the data channel's subprotocol. 
>>>>>>> But as the semantic of a dcsa encapsulated attribute may be 
>>>>>>> subprotocol specific (like 'setup'), I'd now tend to consider 
>>>>>>> the subprotocol parameter in the dcmap attribute as being 
>>>>>>> mandatory, as mentioned above. As already discussed, the 
>>>>>>> Websocket subprotocol registry would then refer to the document, 
>>>>>>> which specifies the subprotocol specific usage of dcsa 
>>>>>>> encapsulated parameters.
>>>>>>>
>>>>>> Ok. Going back to discussion between Paul and I, do you believe 
>>>>>> that in for an attribute to be encapsulated in dcsa, the 
>>>>>> attribute MUST have been explicitly define to support this 
>>>>>> (Paul's suggestion below) or do you believe that this is overly 
>>>>>> constraining, and if so, how shoud we relax it ?
>>>>>>
>>>>>> Thanks
>>>>>>
>>>>>> -- Flemming
>>>>>>
>>>>>>
>>>>>>> Thanks,
>>>>>>> Juergen
>>>>>>>
>>>>>>>
>>>>>>> On 11.02.2016 21:52, Flemming Andreasen wrote:
>>>>>>>>
>>>>>>>>
>>>>>>>> On 2/8/16 12:09 PM, Paul Kyzivat wrote:
>>>>>>>>> On 2/8/16 11:09 AM, Flemming Andreasen wrote:
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On 2/6/16 1:44 PM, Paul Kyzivat wrote:
>>>>>>>>>>> On 2/4/16 10:43 PM, Christian Groves wrote:
>>>>>>>>>>>> Isn't this the approach we're taking today?
>>>>>>>>>>>> draft-ietf-mmusic-data-channel-sdpneg has general text and 
>>>>>>>>>>>> specific
>>>>>>>>>>>> drafts are used to describe protocols that use the 
>>>>>>>>>>>> mechanism (i.e.
>>>>>>>>>>>> draft-ietf-mmusic-msrp-usage-data-channel &
>>>>>>>>>>>> draft-ietf-clue-datachannel).
>>>>>>>>>>>
>>>>>>>>>>> It remains to be seen if that will be enough. E.g., there 
>>>>>>>>>>> currently
>>>>>>>>>>> aren't any iana considerations in
>>>>>>>>>>> draft-ietf-mmusic-msrp-usage-data-channel.
>>>>>>>>>>>
>>>>>>>>>>> Suppose I encounter some sdp that uses msrp over a data 
>>>>>>>>>>> channel, but
>>>>>>>>>>> that usage is unknown to me. How do I find the spec (the 
>>>>>>>>>>> reference to
>>>>>>>>>>> draft-ietf-mmusic-msrp-usage-data-channel) that defines that 
>>>>>>>>>>> usage?
>>>>>>>>>>>
>>>>>>>>>>> I would like to think that the iana registries will allow me 
>>>>>>>>>>> to trace
>>>>>>>>>>> back to the relevant specs.
>>>>>>>>>>>
>>>>>>>>>> No disagreement on that part, however having taken another 
>>>>>>>>>> look at both
>>>>>>>>>> sdpneg and the msrp-usage documents, I still don't agree with 
>>>>>>>>>> your
>>>>>>>>>> original request for all (existing and new) attributes to 
>>>>>>>>>> specify how
>>>>>>>>>> they may or may not be used with the dcsa attribute defined 
>>>>>>>>>> by sdpneg.
>>>>>>>>>>
>>>>>>>>>> As Christian noted, the sub-protocol specifics are defined in 
>>>>>>>>>> individual
>>>>>>>>>> documents (like msrp-usage), which calls your the parameters 
>>>>>>>>>> that are at
>>>>>>>>>> least needed to be supported for that usage. Taking MSRP as 
>>>>>>>>>> an example,
>>>>>>>>>> why isn't that enough, and how do you see the resulting set of
>>>>>>>>>> attributes that may or may not be used with MSRP differ 
>>>>>>>>>> between use in a
>>>>>>>>>> data-channel (and hence encapsulated in dcsa) or as a regular 
>>>>>>>>>> media
>>>>>>>>>> stream ?
>>>>>>>>>
>>>>>>>>> Based on this discussion, I conclude that it should be 
>>>>>>>>> sufficient for this draft to say that before an attribute can 
>>>>>>>>> be used with dcsa, such usage must be defined somewhere. This 
>>>>>>>>> could be either:
>>>>>>>>> - as part of the definition of the attribute, OR
>>>>>>>>> - as part of the definition of the protocol referenced on the 
>>>>>>>>> m-line.
>>>>>>>>>
>>>>>>>> We are getting closer, but it's still not obvious to me that 
>>>>>>>> you cannot use an attribute with dcsa if it has not been 
>>>>>>>> explicitly defined for the attribute in question. Clearly, 
>>>>>>>> there are attributes that wouldn't make sense over data 
>>>>>>>> channels, just like there are attributes that don't make sense 
>>>>>>>> over particular media descriptions.
>>>>>>>>
>>>>>>>> Again, I'd like to hear from more people on this, including the 
>>>>>>>> authors.
>>>>>>>>
>>>>>>>> Thanks
>>>>>>>>
>>>>>>>> -- Flemming
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>>     Thanks,
>>>>>>>>>     Paul
>>>>>>>>>
>>>>>>>>>> Also, it would be good to hear from more people on this, 
>>>>>>>>>> including the
>>>>>>>>>> document authors.
>>>>>>>>>>
>>>>>>>>>> Thanks
>>>>>>>>>>
>>>>>>>>>> -- Flemming
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>>     Thanks,
>>>>>>>>>>>     Paul
>>>>>>>>>>>
>>>>>>>>>>>> Regards, Christian
>>>>>>>>>>>>
>>>>>>>>>>>> On 4/02/2016 3:58 PM, Paul Kyzivat wrote:
>>>>>>>>>>>>> On 2/3/16 5:42 PM, Flemming Andreasen wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> I'm not concerned about the IANA part. I agree that *if* 
>>>>>>>>>>>>>> we need to
>>>>>>>>>>>>>> expliclty specify attribute interactions for "dcsa", then 
>>>>>>>>>>>>>> it should be
>>>>>>>>>>>>>> part of the IANA registry. What I am not agreeing with at 
>>>>>>>>>>>>>> this
>>>>>>>>>>>>>> point is
>>>>>>>>>>>>>> that there is indeed a need to explicitly speficy these
>>>>>>>>>>>>>> interactions as
>>>>>>>>>>>>>> opposed to relying on a more general algorithmic approach 
>>>>>>>>>>>>>> (plus the
>>>>>>>>>>>>>> offerer being responsible for generating a valid offer if 
>>>>>>>>>>>>>> he wants to
>>>>>>>>>>>>>> establish a data channel).
>>>>>>>>>>>>>
>>>>>>>>>>>>> Well, an obvious one is that the protocol(s) the attribute 
>>>>>>>>>>>>> pertains to
>>>>>>>>>>>>> need to be defined to work over data channels.
>>>>>>>>>>>>>
>>>>>>>>>>>>>     Thanks,
>>>>>>>>>>>>>     Paul
>>>>>>>>>>>>>
>
>
> .
>

---

From: Juergen Stoetzer-Bradler <[email-masked]>
Date: Thu, 3 Mar 2016 14:46:57 +0100

Flemming,

Thanks for further feedback.
Trying to summarize this discussion as follows.

Current version 08 of draft-ietf-mmusic-data-channel-sdpneg contains text related to data channel 
subprotocols and subprotocol attributes as follows.

* Within an SDP offer or answer subprotocols may be identified via the "subprotocol" parameter value 
in a data channel's a=dcmap attribute. (Section 5.1.1.5)
* These subprotocol identifiers are registered using the existing IANA "WebSocket Subprotocol Name 
Registry" table. If a certain protocol may be used as Websocket subprotocol or as data channel 
subprotocol, then this IANA table is expected to contain two references for this subprotocol 
identifier - one referring to the corresponding Websocket related document, and one referring to the 
corresponding data channel related document. (Section 8.1)
* An SDP offer or answer describing a subprotocol over a data channel may additionally have 
subprotocol associated attributes, which are embedded in the a=dcsa attribute. Section 5.2.3 
recommends an SDP offerer to add a non-empty subprotocol identifier if it also adds dcsa embedded 
subprotocol attributes to its offer.
* Section 5.1.2.1 specifies the a=dcsa attribute and says that assumingly 'in general the usages of 
subprotocol related media level attributes are independent from the subprotocol's transport 
protocol.  Such transport protocol independent subprotocol related attributes are used in the same 
way as defined in the original subprotocol specification, also if the subprotocol is transported 
over a data channel and if the attribute is correspondingly embedded in a "a=dcsa" attribute'.
* Further, section 5.1.2.1 says that a data channel transport depending semantic of a data channel 
subprotocol is expected to be described in the same document, which adds the subprotocol identifier 
to the IANA WebSocket Subprotocol Name Registry.

Taking again MSRP as an example, draft-ietf-mmusic-msrp-usage-data-channel-04 requests to add "MSRP" 
to the IANA WebSocket Subprotocol Name Registry. An SDP offerer, when creating an MSRP over data 
channel offer, is requested to add the 'subprotocol="MSRP"' parameter to the corresponding a=dcmap 
attribute. (Section 5.1.1.1 of that draft explicitly requests (using "SHALL") an offerer to add this 
parameter to the a=dcmap attribute.) That draft has dedicated text in sections 5.1.1.3 and 6, which 
describe the specific semantic of the setup attribute, if this is a=dcsa embedded and associated 
with MSRP as data channel subprotocol. (In this specific case there is also text describing the 
relationship of dcsa embedded setup attributes and non-dcsa embedded setup attributes, if both are 
present in the same SDP offer or answer.)

Following the above summarized description in draft-ietf-mmusic-data-channel-sdpneg-08, the specific 
semantic of an a=dcsa embedded setup attribute associated with data channel subprotocol identifier 
"MSRP" can be retrieved by inspecting the IANA "WebSocket Subprotocol Name Registry" table, and 
within that by searching for data channel subprotocol identifier "MSRP".

Do I understanding you correctly that you would prefer that 
draft-ietf-mmusic-msrp-usage-data-channel additionally requests to create a new IANA registry, which 
lists all those SDP attributes, which can be used for MSRP as data channel subprotocol, and whose 
semantics deviate from their initial specifications (as compared to when used for MSRP over TCP or 
over TLS/TCP)?
As per my understanding such an additional MSRP data channel subprotocol specific IANA registry 
should then contain the setup attribute. And the setup attribute's entry in this registry would 
refer to draft-ietf-mmusic-msrp-usage-data-channel, as there the data channel transport specific 
semantic of an MSRP associated setup attribute is described.
Other MSRP related attributes (as listed in section 5.1.1.2 of 
draft-ietf-mmusic-msrp-usage-data-channel like the a=accept-types, a=path, a=max-size or the file 
transfer related attributes introduced in RFC 5547) do not have a data channel transport depending 
meaning and would not be added to that new IANA registry, would they?

Right now I've got the impression that such a new data channel subprotocol specific IANA registry 
might be somehow redundant, at least in some cases. If the generic description of 
draft-ietf-mmusic-data-channel-sdpneg-08 is followed when describing how to use a protocol as data 
channel subprotocol, then the IANA WebSocket Subprotocol Name Registry would associate the 
subprotocol identifier with the document, which specifies how to use the protocol as data channel 
subprotocol and which also describes potential data channel specific (existing or new) subprotocol 
attributes. And that document then would refer to the subprotocol specific new IANA registry, which 
again would refer back to that document for all listed subprotocol attributes.

However, I realize that the text in section 5.1.2.1 of current version 08 of 
draft-ietf-mmusic-data-channel-sdpneg does not explicitly address cases, which you had mentioned 
earlier in this discussion:
> Sounds reasonable with the caveat that you may have attributes defined for use with a particular 
> sub-protocol outside the subprotocol draft itself (e.g. because such an attribute was either 
> defined subsequently or its use with a specific subprotocol is defined subsequently). If so, we 
> would need an IANA registry structure (under SDP) that for each subprotocol defines the set of 
> attributes that have been defined with specific semantics for that subprotocol. 

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

Thanks,
Juergen

On 01.03.2016 23:26, EXT Flemming Andreasen wrote:
>>> So far so good, however the case I had in mind is one where the new attribute would apply to one 
>>> or more existing subprotocols.
>> and
>>> While that is certainly a valid use case, I wasn't thinking of restricting it to that and hence 
>>> the request for an actual sub-registry for each of these subprotocols to register attributes 
>>> that can be used with each of them (some attributes may apply to multiple). 
>>
>> Ok, as per my understanding such a new attribute would be introduced in a (let's assume) future 
>> document. I think that such a future document should describe the new attribute's semantic with 
>> respect to all protocols for which it is intended to be used. And if one of these protocols can 
>> be transported over data channels, and if the new attribute's meaning then also has data channel 
>> specific aspects, this future document should also describe those aspects. If this new attribute 
>> is then added to the IANA SDP attribute registry (presumably as media level only or media and 
>> session level attribute), then this document could be found when searching for the new attribute.
>>
> Agreed.
>> I am not yet sure I fully understand how such subprotocol specific registries could be used. 
>> Right now there are already drafts describing MSRP, BFCP and T.140 as data channel subprotocols. 
>> Do you think IANA registry tables for each of these subprotocols should be created (and in future 
>> for any further protocol, which might be used as data channel subprotocol)?
>> Where then a new attribute might be listed in multiple of these subprotocol specific registries, 
>> depending on which subprotocol it might be used for?
>> And all already existing attributes, which might also be used for a data channel subprotocol - do 
>> you think that these should also be added to such subprotocol specific registry tables?
>>
> ...the sdpneg draft might recommend SDP offerers and answerers to always add a subprotocol 
> identifier to a data channel's dcmap attribute if dcsa embedded attributes are also negotiated for 
> the data channel's subprotocol. I also think we could explicitly add text to sdpneg saying that 
> subprotocol identifiers should be added to the IANA Websocket (and in future combined data 
> channel) registry. And that this registration should be done via a document, which then explicitly 
> describes the usages and semantics of dcsa embedded subprotocol attributes, _if_ those usages or 
> semantics deviate from cases, where these attributes are not dcsa encapsulated. I think that in 
> those cases, where the usage and meaning of an attribute (always related to the data channel's 
> subprotocol) does not deviate from the non-dcsa encapsulated use cases, such an attribute may not 
> explicitly need to be described for data channel usage. But I think it might be helpful to 
> explicitly say so in the sdpneg draft.
> </quote>
>
> The key part (for me) in the above is to only have the subprotocol specific registration when the 
> usage or semantic is subprotocol specific. Thus, I do not envision already existing attributes to 
> be added here (unless there is subprotocol specific usage in which case a new document will need 
> to define that).
>
>> Coming back to MSRP as an example - RFC 5547 defines several file transfer related attributes. 
>> Conceivably, a future document could define another file transfer protocol unequal to MSRP (and 
>> based on data channel transport, or based on a transport protocol unequal to data channel). And 
>> that potential future document might then describe how (some of) the file transfer related SDP 
>> attributes might be re-used for this new file transfer protocol. Would you then expect these file 
>> transfer related SDP attributes to be added to such a new registry associated with the new file 
>> transfer protocol? Also if data channel transport of this potential new file transfer protocol 
>> were not defined in that assumed future document?
>>
> Only if their usage with this new file transfer protocol differed from the existing usage. The 
> registry would essentially convey that there is subprotocol specific behavior with a reference to 
> the relevant document. Conversely, if there is no entry in the registry, there is no subprotocol 
> specific behavior defined.
>
>> Right now I'm not sure if this topic is only data channel specific. E.g. the a=setup attribute 
>> was originally introduced in RFC 4145 for TCP connection negotiation. Later on, this attribute 
>> was reused for TLS connection negotiation (RFC 4572) and DTLS association negotiation (RFC 5763, 
>> draft-ietf-mmusic-sctp-sdp, draft-ietf-mmusic-dtls-sdp). As far as I see the IANA SDP parameters 
>> registry for the a=setup attribute only refers to RFC 4145. And the two sctp-sdp and dtls-sdp 
>> drafts don't seem to request updating this registry. However, all these documents have setup 
>> attribute related texts describing the extended semantics of the setup attribute.
>>
>> Somebody seeing an SDP offer like the UDP/DTLS/SCTP related one in section 13.1 of 
>> draft-ietf-mmusic-sctp-sdp-15, when looking for the setup attribute's usage in this SDP offer and 
>> when therefore searching the related reference in the IANA SDP attribute registry, would only 
>> find the reference to RFC 4145. However, he/she could look up the UDP/DTLS/SCTP m-line proto 
>> value in the IANA SDP proto registry, and there would find the reference to the future RFC of 
>> draft-ietf-mmusic-sctp-sdp, where the semantic of the setup attribute within this SDP offer 
>> instance is specified.
>>
>> Somebody seeing an SDP offer like the DTLS-SRTP related one in section 7.1 of RFC 5763, again 
>> when trying to find the semantic of the setup attribute in this SDP offer, would similarly find 
>> the reference to RFC 4145. When searching the proto registry for UDP/TLS/RTP/SAVP he/she would 
>> find the reference to RFC 5764. RFC 5764 does not mention the setup attribute at all, but RFC 
>> 5763 does and describes its usage in the DTLS-SRTP case. [But then it might not be clear if this 
>> setup attribute is used in the original sense of RFCs 5763 / 5764, or with the modified semantic 
>> described in draft-ietf-mmusic-dtls-sdp (which excludes value 'holdconn').]
>>
>> In these cases, do you think that subprotocol (TLS and DTLS as "subprotocols" of TCP and UDP) 
>> specific sub-registries should be created? And if yes, how do you envision those would be used?
>>
> I don't think we should create those, because in general, attributes have a well-defined meaning 
> that applies across protocols (unless the attribute is specifically defined for a single protocol 
> or profile, e.g. RTP). Once we deviate from that principle (e.g. by explicitly defining 
> sub-protocol specific usage for a given attribute), then I do think it's appropriate to have that 
> reflected in a registry so people can figure out what they need to look at.
>
> Thanks
>
> -- Flemming
>
>
>
>
>> Thanks,
>> Juergen
>>
>>
>>>>> Sounds reasonable with the caveat that you may have attributes defined for use with a 
>>>>> particular sub-protocol outside the subprotocol draft itself (e.g. because such an attribute 
>>>>> was either defined subsequently or its use with a specific subprotocol is defined 
>>>>> subsequently). If so, we would need an IANA registry structure (under SDP) that for each 
>>>>> subprotocol defines the set of attributes that have been defined with specific semantics for 
>>>>> that subprotocol. 
>>>>
>>>> Let's assume a future document defines how to establish MSRP sessions over a transport protocol 
>>>> unequal to TCP, TLS, or data channel, and that this document also defines a new MSRP related 
>>>> attribute, whose semantic is only defined for this new transport case (like a maximal MSRP 
>>>> chunk size specific for the new transport). I assume that this future document would request to 
>>>> add this new attribute to one of the existing IANA SDP attribute tables (assumingly to the 
>>>> "att-field (media level only)" table).
>>> So far so good, however the case I had in mind is one where the new attribute would apply to one 
>>> or more existing subprotocols .
>>>> Let's further assume that an implementation creates an SDP offer for an MSRP session over a 
>>>> data channel and adds this new attribute as dcsa embedded MSRP subprotocol attribute (for 
>>>> whatever reasons).
>>>>
>>>> Somebody seeing and inspecting this SDP offer could use the dcmap attribute's subprotocol value 
>>>> "MSRP" to get a reference to the msrp-usage-data-channel document. That document would not 
>>>> mention that new attribute at all. The next step could then be to consult the IANA SDP tables, 
>>>> and there this new attribute would be found together with a reference to this future document.
>>>> As assumingly this new MSRP related attribute would only be defined for this new transport,
>>> While that is certainly a valid use case, I wasn't thinking of restricting it to that and hence 
>>> the request for an actual sub-registry for each of these subprotocols to register attributes 
>>> that can be used with each of them (some attributes may apply to multiple).
>>>
>>>> I think this new attribute should then be ignored by the recipient of this SDP offer.
>>>> Section 5.2.5 of most recent draft-ietf-mmusic-data-channel-sdpneg-08 now contains two related 
>>>> recommendations:
>>>>
>>>> 'SDP offer or answer has an "a=dcsa" attribute, whose subprotocol attribute is unknown.
>>>>  *  The receiver of such an SDP offer or answer SHOULD ignore this entire "a=dcsa" attribute line.
>>>>
>>>> SDP offer or answer has an "a=dcsa" attribute, whose subprotocol attribute is known, but whose 
>>>> subprotocol attribute semantic is not known for the data channel transport case.
>>>>  *  The receiver of such an SDP offer or answer SHOULD ignore this entire "a=dcsa" attribute 
>>>> line.'
>>>>
>>>>>>> It would probably simplify the overall SDP negotiation part, but I don't know if it would 
>>>>>>> constrain the way data channels were envisioned to be used. 
>>>>>>
>>>>>> On Friday Paul mentioned in his email two potential use cases, where no subprotocol 
>>>>>> identifiers might be added to a data channel's dcmap attribute. In my last email I hadn't 
>>>>>> thought of such cases. If we don't want to exclude such cases, then requiring the subprotocol 
>>>>>> ids always to be present might indeed be too restrictive.
>>>>>>
>>>>>> Regarding
>>>>>>> Ok. Going back to discussion between Paul and I, do you believe that in for an attribute to 
>>>>>>> be encapsulated in dcsa, the attribute MUST have been explicitly define to support this 
>>>>>>> (Paul's suggestion below) or do you believe that this is overly constraining, and if so, how 
>>>>>>> shoud we relax it ? 
>>>>>>
>>>>>> I now think that the sdpneg draft might recommend SDP offerers and answerers to always add a 
>>>>>> subprotocol identifier to a data channel's dcmap attribute if dcsa embedded attributes are 
>>>>>> also negotiated for the data channel's subprotocol. I also think we could explicitly add text 
>>>>>> to sdpneg saying that subprotocol identifiers should be added to the IANA Websocket (and in 
>>>>>> future combined data channel) registry. And that this registration should be done via a 
>>>>>> document, which then explicitly describes the usages and semantics of dcsa embedded 
>>>>>> subprotocol attributes, _if_ those usages or semantics deviate from cases, where these 
>>>>>> attributes are not dcsa encapsulated. I think that in those cases, where the usage and 
>>>>>> meaning of an attribute (always related to the data channel's subprotocol) does not deviate 
>>>>>> from the non-dcsa encapsulated use cases, such an attribute may not explicitly need to be 
>>>>>> described for data channel usage. But I think it might be helpful to explicitly say so in the 
>>>>>> sdpneg draft.
>>>>>>
>>>>>> Somebody inspecting an SDP offer or answer, which was generated by an implementation 
>>>>>> following these two recommendations (and which hence contains an IANA registered subprotocol 
>>>>>> id if it contains any dcsa embedded attributes), could then refer to that IANA table, would 
>>>>>> then find the reference to the document, which defines this subprotocol id for data channel 
>>>>>> usage, and there could check if any of the dcsa embedded attributes has a data channel 
>>>>>> specific semantic. If yes, that specific semantic would be described in that document. If 
>>>>>> such a specific semantic were not described in that document, then the default usage and 
>>>>>> semantic of the attribute would apply also to that data channel transport case.
>>>>>>
>>>>> Sounds reasonable with the caveat that you may have attributes defined for use with a 
>>>>> particular sub-protocol outside the subprotocol draft itself (e.g. because such an attribute 
>>>>> was either defined subsequently or its use with a specific subprotocol is defined 
>>>>> subsequently). If so, we would need an IANA registry structure (under SDP) that for each 
>>>>> subprotocol defines the set of attributes that have been defined with specific semantics for 
>>>>> that subprotocol.
>>>>>
>>>>>
>>>>>> A certain subprotocol might be defined for Websocket usage as well as for data channel usage. 
>>>>>> MSRP is already such a case, where draft-ietf-mmusic-msrp-usage-data-channel defines how to 
>>>>>> use MSRP over data channels, and where draft-pd-dispatch-msrp-websocket defines how to use 
>>>>>> MSRP over Websockets.
>>>>>> http://www.iana.org/assignments/websocket/websocket.xml then contain two MSRP related rows? 
>>>>>> Or just one row containing references to both the Websocket and data channel documents?
>>>>>> Should we add related text to the IANA registration section of the sdpneg draft?
>>>>> See above.
>>>>>
>>>>> Thanks
>>>>>
>>>>> -- Flemming
>>>>>>
>>>>>> Thanks,
>>>>>> Juergen
>>>>>>
>>>>>>
>>>>>>>> The current a=dcmap related text in draft-ietf-mmusic-data-channel-sdpneg doesn't require 
>>>>>>>> that the 'subprotocol' parameter must always be present - rather it is specified as an 
>>>>>>>> optional parameter. Thus, current sdpneg text would allow to create an SDP offer for a data 
>>>>>>>> channel, which contains one a=dcmap attribute and potentially multiple a=dcsa attributes 
>>>>>>>> without the subprotocol actually being given. Based on this discussion I am wondering if 
>>>>>>>> the subprotocol parameter should actually be mandatory.
>>>>>>>>
>>>>>>> It would probably simplify the overall SDP negotiation part, but I don't know if it would 
>>>>>>> constrain the way data channels were envisioned to be used.
>>>>>>>
>>>>>>>
>>>>>>>> In the specific case of MSRP, the msrp-usage-data-channel draft says in 5.1.1.1 that the 
>>>>>>>> dcmap attribute includes the label and subprotocol parameters. The current text could 
>>>>>>>> possible be made more explicit by saying that the 'subprotocol="MSRP"' parameter must 
>>>>>>>> always be present.
>>>>>>>> Have just submitted version 04 of the msrp-usage-data-channel draft, which proposes to add 
>>>>>>>> subprotocol identifier "MSRP" to the WebSocket Subprotocol Name registry. This registry 
>>>>>>>> would then associate subprotocol id "MSRP" with the msrp-usage-data-channel document.
>>>>>>>> There, in section 5.1.1.2 the MSRP specific usages of the a=dcsa attribute are specified. 
>>>>>>>> And there the MSRP specific SDP attributes, which can be dcsa embedded, are described.
>>>>>>>> 'setup' is an attribute, whose semantic changes when being dcsa embedded and associated 
>>>>>>>> with subprotocol MSRP, as compared to the meaning of an "a=setup" media level attribute of 
>>>>>>>> a TCP/MSRP m-line. Hence these semantical differences are explicitly addressed in the 
>>>>>>>> msrp-usage-data-channel draft.
>>>>>>>>
>>>>>>>> Regarding sdpneg, I also think that the current text in sdpneg seems to be sufficient 
>>>>>>>> regarding the usage of dcsa encapsulated SDP attributes as being bound to the data 
>>>>>>>> channel's subprotocol. But as the semantic of a dcsa encapsulated attribute may be 
>>>>>>>> subprotocol specific (like 'setup'), I'd now tend to consider the subprotocol parameter in 
>>>>>>>> the dcmap attribute as being mandatory, as mentioned above. As already discussed, the 
>>>>>>>> Websocket subprotocol registry would then refer to the document, which specifies the 
>>>>>>>> subprotocol specific usage of dcsa encapsulated parameters.
>>>>>>>>
>>>>>>> Ok. Going back to discussion between Paul and I, do you believe that in for an attribute to 
>>>>>>> be encapsulated in dcsa, the attribute MUST have been explicitly define to support this 
>>>>>>> (Paul's suggestion below) or do you believe that this is overly constraining, and if so, how 
>>>>>>> shoud we relax it ?
>>>>>>>
>>>>>>> Thanks
>>>>>>>
>>>>>>> -- Flemming
>>>>>>>
>>>>>>>
>>>>>>>> Thanks,
>>>>>>>> Juergen
>>>>>>>>
>>>>>>>>
>>>>>>>>>>>>> draft-ietf-mmusic-data-channel-sdpneg has general text and specific
>>>>>>>>>>>>> drafts are used to describe protocols that use the mechanism (i.e.
>>>>>>>>>>>> It remains to be seen if that will be enough. E.g., there currently
>>>>>>>>>>>> Suppose I encounter some sdp that uses msrp over a data channel, but
>>>>>>>>>>>> that usage is unknown to me. How do I find the spec (the reference to
>>>>>>>>>>>> draft-ietf-mmusic-msrp-usage-data-channel) that defines that usage?
>>>>>>>>>>>>
>>>>>>>>>>>> I would like to think that the iana registries will allow me to trace
>>>>>>>>>>> No disagreement on that part, however having taken another look at both
>>>>>>>>>>> sdpneg and the msrp-usage documents, I still don't agree with your
>>>>>>>>>>> original request for all (existing and new) attributes to specify how
>>>>>>>>>>> they may or may not be used with the dcsa attribute defined by sdpneg.
>>>>>>>>>>>
>>>>>>>>>>> As Christian noted, the sub-protocol specifics are defined in individual
>>>>>>>>>>> documents (like msrp-usage), which calls your the parameters that are at
>>>>>>>>>>> least needed to be supported for that usage. Taking MSRP as an example,
>>>>>>>>>>> attributes that may or may not be used with MSRP differ between use in a
>>>>>>>>>>> data-channel (and hence encapsulated in dcsa) or as a regular media
>>>>>>>>>>> stream ?
>>>>>>>>>>
>>>>>>>>>> Based on this discussion, I conclude that it should be sufficient for this draft to say 
>>>>>>>>>> that before an attribute can be used with dcsa, such usage must be defined somewhere. 
>>>>>>>>>> This could be either:
>>>>>>>>>> - as part of the definition of the protocol referenced on the m-line.
>>>>>>>>>>
>>>>>>>>> We are getting closer, but it's still not obvious to me that you cannot use an attribute 
>>>>>>>>> with dcsa if it has not been explicitly defined for the attribute in question. Clearly, 
>>>>>>>>> there are attributes that wouldn't make sense over data channels, just like there are 
>>>>>>>>> attributes that don't make sense over particular media descriptions.
>>>>>>>>>
>>>>>>>>> Again, I'd like to hear from more people on this, including the authors.
>>>>>>>>>
>>>>>>>>> Thanks
>>>>>>>>>
>>>>>>>>> -- Flemming
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>     Thanks,
>>>>>>>>>>     Paul
>>>>>>>>>>
>>>>>>>>>>> Also, it would be good to hear from more people on this, including the
>>>>>>>>>>> document authors.
>>>>>>>>>>>
>>>>>>>>>>> Thanks
>>>>>>>>>>>
>>>>>>>>>>> -- Flemming
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>>     Thanks,
>>>>>>>>>>>>     Paul
>>>>>>>>>>>>
>>>>>>>>>>>>> Regards, Christian
>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I'm not concerned about the IANA part. I agree that *if* we need to
>>>>>>>>>>>>>>> expliclty specify attribute interactions for "dcsa", then it should be
>>>>>>>>>>>>>>> part of the IANA registry. What I am not agreeing with at this
>>>>>>>>>>>>>>> point is
>>>>>>>>>>>>>>> opposed to relying on a more general algorithmic approach (plus the
>>>>>>>>>>>>>>> offerer being responsible for generating a valid offer if he wants to
>>>>>>>>>>>>>> Well, an obvious one is that the protocol(s) the attribute pertains to

---

From: Flemming Andreasen <[email-masked]>
Date: Thu, 3 Mar 2016 09:52:39 -0500

On 3/3/16 8:46 AM, Juergen Stoetzer-Bradler wrote:
> Current version 08 of draft-ietf-mmusic-data-channel-sdpneg contains 
> text related to data channel subprotocols and subprotocol attributes 
> as follows.
>
> * Within an SDP offer or answer subprotocols may be identified via the 
> "subprotocol" parameter value in a data channel's a=dcmap attribute. 
> (Section 5.1.1.5)
> * These subprotocol identifiers are registered using the existing IANA 
> "WebSocket Subprotocol Name Registry" table. If a certain protocol may 
> be used as Websocket subprotocol or as data channel subprotocol, then 
> this IANA table is expected to contain two references for this 
> subprotocol identifier - one referring to the corresponding Websocket 
> related document, and one referring to the corresponding data channel 
> related document. (Section 8.1)
> * An SDP offer or answer describing a subprotocol over a data channel 
> may additionally have subprotocol associated attributes, which are 
> embedded in the a=dcsa attribute. Section 5.2.3 recommends an SDP 
> offerer to add a non-empty subprotocol identifier if it also adds dcsa 
> embedded subprotocol attributes to its offer.
> * Section 5.1.2.1 specifies the a=dcsa attribute and says that 
> assumingly 'in general the usages of subprotocol related media level 
> attributes are independent from the subprotocol's transport protocol.  
> Such transport protocol independent subprotocol related attributes are 
> used in the same way as defined in the original subprotocol 
> specification, also if the subprotocol is transported over a data 
> channel and if the attribute is correspondingly embedded in a "a=dcsa" 
> attribute'.
> * Further, section 5.1.2.1 says that a data channel transport 
> depending semantic of a data channel subprotocol is expected to be 
> described in the same document, which adds the subprotocol identifier 
> Taking again MSRP as an example, 
> draft-ietf-mmusic-msrp-usage-data-channel-04 requests to add "MSRP" to 
> the IANA WebSocket Subprotocol Name Registry. An SDP offerer, when 
> creating an MSRP over data channel offer, is requested to add the 
> 'subprotocol="MSRP"' parameter to the corresponding a=dcmap attribute. 
> (Section 5.1.1.1 of that draft explicitly requests (using "SHALL") an 
> offerer to add this parameter to the a=dcmap attribute.) That draft 
> has dedicated text in sections 5.1.1.3 and 6, which describe the 
> specific semantic of the setup attribute, if this is a=dcsa embedded 
> and associated with MSRP as data channel subprotocol. (In this 
> specific case there is also text describing the relationship of dcsa 
> embedded setup attributes and non-dcsa embedded setup attributes, if 
> both are present in the same SDP offer or answer.)
>
> Following the above summarized description in 
> draft-ietf-mmusic-data-channel-sdpneg-08, the specific semantic of an 
> a=dcsa embedded setup attribute associated with data channel 
> subprotocol identifier "MSRP" can be retrieved by inspecting the IANA 
> "WebSocket Subprotocol Name Registry" table, and within that by 
> searching for data channel subprotocol identifier "MSRP".
>
> draft-ietf-mmusic-msrp-usage-data-channel additionally requests to 
> create a new IANA registry, which lists all those SDP attributes, 
> which can be used for MSRP as data channel subprotocol, and whose 
> semantics deviate from their initial specifications (as compared to 
> when used for MSRP over TCP or over TLS/TCP)?
Yes (for consistency with the second part you have below)
> As per my understanding such an additional MSRP data channel 
> subprotocol specific IANA registry should then contain the setup 
> attribute. And the setup attribute's entry in this registry would 
> refer to draft-ietf-mmusic-msrp-usage-data-channel, as there the data 
> channel transport specific semantic of an MSRP associated setup 
> attribute is described.
> draft-ietf-mmusic-msrp-usage-data-channel like the a=accept-types, 
> a=path, a=max-size or the file transfer related attributes introduced 
> in RFC 5547) do not have a data channel transport depending meaning 
> and would not be added to that new IANA registry, would they?
>
Agreed - as long they retain their original meaning/definition 
independently of what the actual subprotocol is, then there is nothing 
special about them and hence no need to register them for any particular 
subprotocol.

> Right now I've got the impression that such a new data channel 
> subprotocol specific IANA registry might be somehow redundant, at 
> least in some cases. If the generic description of 
> draft-ietf-mmusic-data-channel-sdpneg-08 is followed when describing 
> how to use a protocol as data channel subprotocol, then the IANA 
> WebSocket Subprotocol Name Registry would associate the subprotocol 
> identifier with the document, which specifies how to use the protocol 
> as data channel subprotocol and which also describes potential data 
> channel specific (existing or new) subprotocol attributes. And that 
> document then would refer to the subprotocol specific new IANA 
> registry, which again would refer back to that document for all listed 
> subprotocol attributes.
>
> However, I realize that the text in section 5.1.2.1 of current version 
> 08 of draft-ietf-mmusic-data-channel-sdpneg does not explicitly 
> address cases, which you had mentioned earlier in this discussion:
> 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

Thanks

-- Flemming (with my individual hat on)

>>> document should describe the new attribute's semantic with respect 
>>> to all protocols for which it is intended to be used. And if one of 
>>> these protocols can be transported over data channels, and if the 
>>> new attribute's meaning then also has data channel specific aspects, 
>>> this future document should also describe those aspects. If this new 
>>> attribute is then added to the IANA SDP attribute registry 
>>> (presumably as media level only or media and session level 
>>> attribute), then this document could be found when searching for the 
>>> new attribute.
>>>
>> Agreed.
>> ...the sdpneg draft might recommend SDP offerers and answerers to 
>> always add a subprotocol identifier to a data channel's dcmap 
>> attribute if dcsa embedded attributes are also negotiated for the 
>> data channel's subprotocol. I also think we could explicitly add text 
>> to sdpneg saying that subprotocol identifiers should be added to the 
>> IANA Websocket (and in future combined data channel) registry. And 
>> that this registration should be done via a document, which then 
>> explicitly describes the usages and semantics of dcsa embedded 
>> subprotocol attributes, _if_ those usages or semantics deviate from 
>> cases, where these attributes are not dcsa encapsulated. I think that 
>> in those cases, where the usage and meaning of an attribute (always 
>> related to the data channel's subprotocol) does not deviate from the 
>> non-dcsa encapsulated use cases, such an attribute may not explicitly 
>> need to be described for data channel usage. But I think it might be 
>> added here (unless there is subprotocol specific usage in which case 
>> a new document will need to define that).
>>
>>> data channel). And that potential future document might then 
>>> describe how (some of) the file transfer related SDP attributes 
>>> might be re-used for this new file transfer protocol. Would you then 
>>> expect these file transfer related SDP attributes to be added to 
>>> such a new registry associated with the new file transfer protocol? 
>>> Also if data channel transport of this potential new file transfer 
>>> protocol were not defined in that assumed future document?
>>>
>> Only if their usage with this new file transfer protocol differed 
>> from the existing usage. The registry would essentially convey that 
>> there is subprotocol specific behavior with a reference to the 
>> relevant document. Conversely, if there is no entry in the registry, 
>> there is no subprotocol specific behavior defined.
>>
>>> TLS connection negotiation (RFC 4572) and DTLS association 
>>> negotiation (RFC 5763, draft-ietf-mmusic-sctp-sdp, 
>>> draft-ietf-mmusic-dtls-sdp). As far as I see the IANA SDP parameters 
>>> registry for the a=setup attribute only refers to RFC 4145. And the 
>>> two sctp-sdp and dtls-sdp drafts don't seem to request updating this 
>>> registry. However, all these documents have setup attribute related 
>>> texts describing the extended semantics of the setup attribute.
>>>
>>> setup attribute's usage in this SDP offer and when therefore 
>>> searching the related reference in the IANA SDP attribute registry, 
>>> would only find the reference to RFC 4145. However, he/she could 
>>> look up the UDP/DTLS/SCTP m-line proto value in the IANA SDP proto 
>>> registry, and there would find the reference to the future RFC of 
>>> draft-ietf-mmusic-sctp-sdp, where the semantic of the setup 
>>> attribute within this SDP offer instance is specified.
>>>
>>> Somebody seeing an SDP offer like the DTLS-SRTP related one in 
>>> section 7.1 of RFC 5763, again when trying to find the semantic of 
>>> the setup attribute in this SDP offer, would similarly find the 
>>> reference to RFC 4145. When searching the proto registry for 
>>> UDP/TLS/RTP/SAVP he/she would find the reference to RFC 5764. RFC 
>>> 5764 does not mention the setup attribute at all, but RFC 5763 does 
>>> and describes its usage in the DTLS-SRTP case. [But then it might 
>>> not be clear if this setup attribute is used in the original sense 
>>> of RFCs 5763 / 5764, or with the modified semantic described in 
>>> draft-ietf-mmusic-dtls-sdp (which excludes value 'holdconn').]
>>>
>> attribute is specifically defined for a single protocol or profile, 
>> e.g. RTP). Once we deviate from that principle (e.g. by explicitly 
>> defining sub-protocol specific usage for a given attribute), then I 
>> do think it's appropriate to have that reflected in a registry so 
>> people can figure out what they need to look at.
>>
>> Thanks
>>
>> -- Flemming
>>
>>
>>
>>
>>> Thanks,
>>> Juergen
>>>
>>>
>>>>>> subprotocol draft itself (e.g. because such an attribute was 
>>>>>> either defined subsequently or its use with a specific 
>>>>>> subprotocol is defined subsequently). If so, we would need an 
>>>>>> IANA registry structure (under SDP) that for each subprotocol 
>>>>>> defines the set of attributes that have been defined with 
>>>>>> specific semantics for that subprotocol. 
>>>>>
>>>>> transport). I assume that this future document would request to 
>>>>> add this new attribute to one of the existing IANA SDP attribute 
>>>>> tables (assumingly to the "att-field (media level only)" table).
>>>>> Let's further assume that an implementation creates an SDP offer 
>>>>> for an MSRP session over a data channel and adds this new 
>>>>> attribute as dcsa embedded MSRP subprotocol attribute (for 
>>>>> whatever reasons).
>>>>>
>>>>> attribute is known, but whose subprotocol attribute semantic is 
>>>>> not known for the data channel transport case.
>>>>>>>> It would probably simplify the overall SDP negotiation part, 
>>>>>>>> but I don't know if it would constrain the way data channels 
>>>>>>>> were envisioned to be used. 
>>>>>>>
>>>>>>> such cases. If we don't want to exclude such cases, then 
>>>>>>> requiring the subprotocol ids always to be present might indeed 
>>>>>>> be too restrictive.
>>>>>>>
>>>>>>> Regarding
>>>>>>> I now think that the sdpneg draft might recommend SDP offerers 
>>>>>>> and answerers to always add a subprotocol identifier to a data 
>>>>>>> combined data channel) registry. And that this registration 
>>>>>>> should be done via a document, which then explicitly describes 
>>>>>>> the usages and semantics of dcsa embedded subprotocol 
>>>>>>> attributes, _if_ those usages or semantics deviate from cases, 
>>>>>>> where these attributes are not dcsa encapsulated. I think that 
>>>>>>> in those cases, where the usage and meaning of an attribute 
>>>>>>> (always related to the data channel's subprotocol) does not 
>>>>>>> deviate from the non-dcsa encapsulated use cases, such an 
>>>>>>> attribute may not explicitly need to be described for data 
>>>>>>> channel usage. But I think it might be helpful to explicitly say 
>>>>>>> so in the sdpneg draft.
>>>>>>>
>>>>>>> Somebody inspecting an SDP offer or answer, which was generated 
>>>>>>> by an implementation following these two recommendations (and 
>>>>>>> which hence contains an IANA registered subprotocol id if it 
>>>>>>> contains any dcsa embedded attributes), could then refer to that 
>>>>>>> IANA table, would then find the reference to the document, which 
>>>>>>> channel specific semantic. If yes, that specific semantic would 
>>>>>>> be described in that document. If such a specific semantic were 
>>>>>>> not described in that document, then the default usage and 
>>>>>> subprotocol draft itself (e.g. because such an attribute was 
>>>>>> either defined subsequently or its use with a specific 
>>>>>> subprotocol is defined subsequently). If so, we would need an 
>>>>>> IANA registry structure (under SDP) that for each subprotocol 
>>>>>> defines the set of attributes that have been defined with 
>>>>>> specific semantics for that subprotocol.
>>>>>>
>>>>>>
>>>>>>> A certain subprotocol might be defined for Websocket usage as 
>>>>>>> well as for data channel usage. MSRP is already such a case, 
>>>>>>> where draft-ietf-mmusic-msrp-usage-data-channel defines how to 
>>>>>>> use MSRP over data channels, and where 
>>>>>>> draft-pd-dispatch-msrp-websocket defines how to use MSRP over 
>>>>>>> Websockets.
>>>>>>>> It would probably simplify the overall SDP negotiation part, 
>>>>>>>> but I don't know if it would constrain the way data channels 
>>>>>>>> were envisioned to be used.
>>>>>>>>
>>>>>>>>
>>>>>>>>> In the specific case of MSRP, the msrp-usage-data-channel 
>>>>>>>>> draft says in 5.1.1.1 that the dcmap attribute includes the 
>>>>>>>>> label and subprotocol parameters. The current text could 
>>>>>>>>> possible be made more explicit by saying that the 
>>>>>>>>> 'subprotocol="MSRP"' parameter must always be present.
>>>>>>>>> There, in section 5.1.1.2 the MSRP specific usages of the 
>>>>>>>>> a=dcsa attribute are specified. And there the MSRP specific 
>>>>>>>>> SDP attributes, which can be dcsa embedded, are described.
>>>>>>>>> 'setup' is an attribute, whose semantic changes when being 
>>>>>>>>> dcsa embedded and associated with subprotocol MSRP, as 
>>>>>>>>> compared to the meaning of an "a=setup" media level attribute 
>>>>>>>>> of a TCP/MSRP m-line. Hence these semantical differences are 
>>>>>>>>> explicitly addressed in the msrp-usage-data-channel draft.
>>>>>>>>>
>>>>>>>>> seems to be sufficient regarding the usage of dcsa 
>>>>>>>>> encapsulated SDP attributes as being bound to the data 
>>>>>>>>> channel's subprotocol. But as the semantic of a dcsa 
>>>>>>>>> encapsulated attribute may be subprotocol specific (like 
>>>>>>>>> 'setup'), I'd now tend to consider the subprotocol parameter 
>>>>>>>>> in the dcmap attribute as being mandatory, as mentioned above. 
>>>>>>>>> As already discussed, the Websocket subprotocol registry would 
>>>>>>>>> then refer to the document, which specifies the subprotocol 
>>>>>>>>> specific usage of dcsa encapsulated parameters.
>>>>>>>>>
>>>>>>>>>>> sufficient for this draft to say that before an attribute 
>>>>>>>>>>> can be used with dcsa, such usage must be defined somewhere. 
>>>>>>>>>>> This could be either:
>>>>>>>>>> channels, just like there are attributes that don't make 
>>>>>>>>>> sense over particular media descriptions.
>>>>>>>>>>

---

From: Christian Groves <[email-masked]>
Date: Mon, 7 Mar 2016 11:04:34 +1100

Hello Flemming and Juergen,

..snip..
> Either would work, however my preference would be a complete listing 
> of attributes that have subprotocol specific meaning.
>

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

Regards, Christian

---

From: Paul Kyzivat <[email-masked]>
Date: Sun, 6 Mar 2016 19:32:33 -0500

> and define att-field (data channel).

I have previously proposed (and I think it was approved) that the use of 
separate sub-registries for session-only, media-only, session-and-media, 
and source level is a pain, and error prone, and should be replaced by a 
single registry with another column where session, media, and/or source 
level can be specified.

And, this particular discussion started when I proposed that yet another 
option for that new field ought to be data-channel.

Flemming disagreed - IIUC he felt it was unnecessary. I still think it 
is at least as necessary as is having a registry for source level.

An argument can be made that *none* of these need to be specified in the 
registry (that it is sufficient for them to be defined in the document), 
but if this info *is* to be in a registry then it makes just as much 
sense to include it for data-channels as for the others.

	Thanks,
	Paul.

---

From: Flemming Andreasen <[email-masked]>
Date: Mon, 7 Mar 2016 22:04:03 -0500

> 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

---

From: Juergen Stoetzer-Bradler <[email-masked]>
Date: Tue, 8 Mar 2016 14:51:35 +0100

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

---

From: Christian Groves <[email-masked]>
Date: Wed, 9 Mar 2016 11:53:40 +1100

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

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.

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.

Regards, Christian

On 9/03/2016 12:51 AM, Juergen Stoetzer-Bradler wrote:
> 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.
>
> 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.
> 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.
>
> 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
>
>
>
>>>>> 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.
>>>>> 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 
>>>> Either would work, however my preference would be a complete 
>>>> listing of attributes that have subprotocol specific meaning.
>>>>
>>> It feels like we should take the approach for att-field (source 
>>> level) and define att-field (data channel).
>>>
>> 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
>>>>
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic
>

---

From: Juergen Stoetzer-Bradler <[email-masked]>
Date: Wed, 9 Mar 2016 13:32:50 +0100

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

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.

>> 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.
>>
>> Similar to IANA's RTP source level attribute registry a global IANA "data channel level" 
>> attribute registry could be created.
>> 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.
>>
>> 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:
>> 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, 
>> 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.
>> 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
>>
>>
>>

>>>>>> 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.
>>>>>>
>>>> It feels like we should take the approach for att-field (source level) and define att-field 
>>>> (data channel).
>>>>
>>> per attribute, since different sub-protocols could each define sub-protocol specific behavior 
>>> for an attribute.
>>>
>>> Thanks
>>>
>>> -- Flemming
>>>
>>>
>>>> Regards, Christian
>>>>
>>>>>
>>>>>
>>>>> Thanks
>>>>>

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 9 Mar 2016 13:55:51 -0500

In my opinion we should start out assuming that the existing attribute 
registries are consolidated into one, with an extra column, as has been 
planned.

Then we consider how to build on that.

My thought is that "dcsa" simply becomes another context, alongside 
"session", "media", and "source". A given attribute could be valid in 
any combination of those.

And then the reference section of that entry should get a reference to 
every document that pertains to that attribute.

That does leave the issue Juergen raises: you might need to read a bunch 
of documents to find which ones pertain to usage in dcsa, and to a 
particular subprotocol.

We could consider further enhancements to the registry to make that sort 
of query easier. Or we could just assume it won't be a problem often 
enough to bother.

	Thanks,
	Paul

On 3/9/16 7:32 AM, Juergen Stoetzer-Bradler wrote:
> 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?
>
>> cannot be used at the media or session level) then this would go into
>> a new global IANA "data channel level" registry.
> 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.
>
>>
> 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).
>
>>
>> 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
>> 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
>>
>>> each referenced document should describe this attribute's semantic
>>> and usage for a specific subprotocol. (Which would not exclude one
>>> 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
>>> 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.
>>> attributes, which could be used for this subprotocol, and which have
>>> a data channel transport specific semantic. Each such attribute could
>>> Option (C) is the one which is (to the most part) described in
>>> current version 08 of draft-ietf-mmusic-data-channel-sdpneg.
>>>
>>> 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
>>>>>>> added to corresponding data channel subprotocol specific
>>>>>>> attribute registries, which then could refer to the document
>>>>>> Right - and for consistency I think it then makes sense to have
>>>>>> all subprotocol-specific attributes registered there.
>>>>>>
>
>>>> 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
>>>>>>

---

From: Christian Groves <[email-masked]>
Date: Thu, 10 Mar 2016 10:18:01 +1100

Hello Paul, all,

On 10/03/2016 5:55 AM, Paul Kyzivat wrote:
> registries are consolidated into one, with an extra column, as has 
> been planned.
>

> every document that pertains to that attribute.
[CNG] I'm happy to go with that suggestion.

>
> That does leave the issue Juergen raises: you might need to read a 
> bunch of documents to find which ones pertain to usage in dcsa, and to 
> a particular subprotocol.
[CNG] An implementor should read these documents anyway if they're going 
to implement a sub-protocol.
>
> We could consider further enhancements to the registry to make that 
> sort of query easier. Or we could just assume it won't be a problem 
> often enough to bother.

Regards, Christian

..snip

---

From: Flemming Andreasen <[email-masked]>
Date: Thu, 10 Mar 2016 10:43:27 -0500

Hi Juergen

Thanks for putting together the summary. Option B(ii) below would indeed 
be my preference.

-- Flemming (as individual)

---

From: Flemming Andreasen <[email-masked]>
Date: Thu, 10 Mar 2016 10:45:59 -0500

On 3/9/16 6:18 PM, Christian Groves wrote:
>> In my opinion we should start out assuming that the existing 
>> attribute registries are consolidated into one, with an extra column, 
>> as has been planned.
>>
>> And then the reference section of that entry should get a reference 
>> to every document that pertains to that attribute.
I can live with that as well, but do see below.

>> bunch of documents to find which ones pertain to usage in dcsa, and 
>> to a particular subprotocol.
> [CNG] An implementor should read these documents anyway if they're 
> going to implement a sub-protocol.
>>

I think it is highly desirable to have the registry clearly indicate 
which documents are relevant for a given sub-protocol.

Thanks

-- Flemming

---

From: Juergen Stoetzer-Bradler <[email-masked]>
Date: Thu, 10 Mar 2016 16:21:00 +0100

Paul, Christian,

In such a consolidated registry, assumingly the "source" and "dcsa" contexts of most attributes, 
which are registered today in any of the existing IANA tables, would stay empty, as most attributes 
would not specifically be described or specified for these two context?

Thanks,
Juergen

On 10.03.2016 00:18, EXT Christian Groves wrote:
>> In my opinion we should start out assuming that the existing attribute registries are 
>> consolidated into one, with an extra column, as has been planned.
>>
>> My thought is that "dcsa" simply becomes another context, alongside "session", "media", and 
>> "source". A given attribute could be valid in any combination of those.
>
>> And then the reference section of that entry should get a reference to every document that 
>> pertains to that attribute.
>> That does leave the issue Juergen raises: you might need to read a bunch of documents to find 
>> which ones pertain to usage in dcsa, and to a particular subprotocol.
> [CNG] An implementor should read these documents anyway if they're going to implement a sub-protocol.
>>
>> We could consider further enhancements to the registry to make that sort of query easier. Or we 
>> could just assume it won't be a problem often enough to bother.
>
> Regards, Christian
>
> ..snip
>

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 10 Mar 2016 11:57:16 -0500

On 3/10/16 10:21 AM, Juergen Stoetzer-Bradler wrote:
> Paul, Christian,
>
> In such a consolidated registry, assumingly the "source" and "dcsa"
> contexts of most attributes, which are registered today in any of the
> existing IANA tables, would stay empty, as most attributes would not
> specifically be described or specified for these two context?

Yes, that is my thinking.

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 10 Mar 2016 11:58:39 -0500

> which documents are relevant for a given sub-protocol.

I'll try to come up with some possible examples of how to do this, and 
post them as a new thread.

	Thanks,
	Paul