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

[Flemming Andreasen <[e-mail]>]

On 3/3/16 8:46 AM, Juergen Stoetzer-Bradler wrote:
> 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)?
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.
> 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?
>
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:
>> 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.
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)


> Thanks,
> Juergen
>
>
> On 01.03.2016 23:26, EXT Flemming Andreasen wrote:
>>
>>
>> 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
>>>>>>>>>>>>>>>
>>>
>>>
>>> .
>>>
>>
>
> .
>