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

Christian Groves <Christian.Groves@nteczone.com> Mon, 15 February 2016 23:41 UTC

Return-Path: <Christian.Groves@nteczone.com>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9C8A51A1DBC for <mmusic@ietfa.amsl.com>; Mon, 15 Feb 2016 15:41:43 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.59
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ovUpw374HGsc for <mmusic@ietfa.amsl.com>; Mon, 15 Feb 2016 15:41:40 -0800 (PST)
Received: from msh03.myshophosting.com (msh03.myshophosting.com [101.0.109.158]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 290ED1A1BF3 for <mmusic@ietf.org>; Mon, 15 Feb 2016 15:41:40 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=nteczone.com; 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 ppp118-209-170-124.lns20.mel8.internode.on.net ([118.209.170.124]:59923 helo=[192.168.1.22]) by msh03.myshophosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.86) (envelope-from <Christian.Groves@nteczone.com>) id 1aVSlt-002OpP-Oj for mmusic@ietf.org; Tue, 16 Feb 2016 10:41:37 +1100
To: mmusic@ietf.org
References: <BBE9739C2C302046BD34B42713A1E2A22E88D533@ESESSMB105.ericsson.se> <565CDF90.7050107@nteczone.com> <565CEA14.2040607@alum.mit.edu> <565CEF7B.7010305@nteczone.com> <949EF20990823C4C85C18D59AA11AD8BADE16A00@FR712WXCHMBA11.zeu.alcatel-lucent.com> <56682B96.9020008@alcatel-lucent.com> <56684C13.9030106@alum.mit.edu> <5668F9C1.4040606@nteczone.com> <566903E3.8020108@alum.mit.edu> <566A16D2.1070108@nteczone.com> <949EF20990823C4C85C18D59AA11AD8BADE22AB4@FR712WXCHMBA11.zeu.alcatel-lucent.com> <566AEB05.3040501@alum.mit.edu> <56AACC37.8090900@cisco.com> <56AB8596.9090304@alum.mit.edu> <56B12F48.409@cisco.com> <56B25159.70002@alum.mit.edu> <56B28240.7080206@cisco.com> <56B2DA8D.2000909@alum.mit.edu> <56B41A47.10901@nteczone.com> <56B63EF8.8080100@alum.mit.edu> <56B8BDA4.7060305@cisco.com> <56B8CBB5.7070507@alum.mit.edu> <56BCF47E.2000603@cisco.com> <56BDB7BC.1060104@alcatel-lucent.com> <56BDF1C6.9080707@cisco.com> <56C05B63.4030007@alcatel-lucent.com>
From: Christian Groves <Christian.Groves@nteczone.com>
Message-ID: <56C2622F.1020807@nteczone.com>
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: <56C05B63.4030007@alcatel-lucent.com>
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 - msh03.myshophosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - nteczone.com
X-Get-Message-Sender-Via: msh03.myshophosting.com: authenticated_id: christian.groves@nteczone.com
X-Authenticated-Sender: msh03.myshophosting.com: christian.groves@nteczone.com
X-Source:
X-Source-Args:
X-Source-Dir:
Archived-At: <http://mailarchive.ietf.org/arch/msg/mmusic/nZ00HxU2XRTs_1zoudE0IXxCWGU>
Subject: Re: [MMUSIC] WGLC for draft-ietf-mmusic-data-channel-sdpneg
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mmusic/>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=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 
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
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic
>