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

[Flemming Andreasen <[e-mail]>]

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