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

[Christian Groves <[e-mail]>]

Hello Juergen,

Your proposal seems reasonable to me.

With regards to the IANA registry for websockets I think it should be 
possible to add two references to the row for MSRP. It's only editing a 
table.

Regards, Christian

On 14/02/2016 9:48 PM, 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.
>
> 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?
>
> 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
>>>>>>>>>
>
>
> _______________________________________________
> mmusic mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mmusic
>