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

Christian Groves <> Mon, 15 February 2016 23:41 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 9C8A51A1DBC for <>; Mon, 15 Feb 2016 15:41:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.59
X-Spam-Status: No, score=-0.59 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, J_CHICKENPOX_14=0.6, J_CHICKENPOX_15=0.6, T_DKIM_INVALID=0.01] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ovUpw374HGsc for <>; Mon, 15 Feb 2016 15:41:40 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 290ED1A1BF3 for <>; Mon, 15 Feb 2016 15:41:40 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;; s=default; h=Content-Transfer-Encoding:Content-Type: In-Reply-To:MIME-Version:Date:Message-ID:From:References:To:Subject; bh=zAwArnuu+RlseFLHMyaQHUMOsH8K6c/V9niF5c4m/Jo=; b=f7GKK1eiMEXk4EKUJef842qIng 14p/hSE/I2sVUin1Eo76MMNWB06lYlqbiBKCcbBLsaQYgm7B4MBP3N0L9Ag6yb13CwKIdFnQjK5ne H+x6azJMzNpukDFwGtN4if9beXbbtem6iICJ/0kWTlgVN619EBNfKGWxPWaJBuFVlkQVHeH4d1QOD Q3ZdHfFO5uLm9Hd6pMz2HnTdfvZU6uosCSIBHoweeITB2KFwdXUDVBEfittZ+znLf1RkzgGAkcVuV Hafnh+d1wjLY4RdLctJiHb6VcJRjzRpBENluWDRLv60YTvwGFqC4Ovps4NUPl/JRHY2vabCwPT7U1 xmFsoECQ==;
Received: from ([]:59923 helo=[]) by with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.86) (envelope-from <>) id 1aVSlt-002OpP-Oj for; Tue, 16 Feb 2016 10:41:37 +1100
References: <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <> <>
From: Christian Groves <>
Message-ID: <>
Date: Tue, 16 Feb 2016 10:41:35 +1100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 7bit
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname -
X-AntiAbuse: Original Domain -
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain -
X-Get-Message-Sender-Via: authenticated_id:
Archived-At: <>
Subject: Re: [MMUSIC] WGLC for draft-ietf-mmusic-data-channel-sdpneg
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 15 Feb 2016 23:41:43 -0000

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 

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