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

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

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

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