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

[Flemming Andreasen <[e-mail]>]

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