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

Flemming Andreasen <fandreas@cisco.com> Thu, 03 March 2016 14:52 UTC

Return-Path: <fandreas@cisco.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 B408D1AD0B9 for <mmusic@ietfa.amsl.com>; Thu, 3 Mar 2016 06:52:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -13.307
X-Spam-Level:
X-Spam-Status: No, score=-13.307 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_14=0.6, J_CHICKENPOX_15=0.6, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
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 SEHxeprMn4WG for <mmusic@ietfa.amsl.com>; Thu, 3 Mar 2016 06:52:44 -0800 (PST)
Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6E4151AD0BB for <mmusic@ietf.org>; Thu, 3 Mar 2016 06:52:43 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=31582; q=dns/txt; s=iport; t=1457016763; x=1458226363; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=RTEDC+K1IaxE5LmIXbTfgFilUDxva4COvG0qZXVHdRQ=; b=mxuqPDlm1ZrcD9qX1QS3CNZ+mrUlZ7aLzMVR1bqflinP7kaQsL7TgB7u FoUzIJcEdJBcyCiRQ1st6PulYp80pdPhU7fl5zEGdCz20x/aNU/dcgmpZ 9W1M7ovdXWE8Sqrls/mUPA8zdH74/lnC2+tBRsjzjtsM5ZkoJIcwxuAfP Q=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BvBgCcTthW/xbLJq1dhAxthDKzZoQJI?= =?us-ascii?q?YUkSgKBdwEBAQEBAWUnhEEBAQEDARoJFToGBgsLGAICBRYLAgIJAwIBAgFFBgE?= =?us-ascii?q?JAwgBAQWIEAgOrjmPMQEBAQEBAQEBAQEBAQEBAQEBGXuFHYQ8hAgRAYMegToFj?= =?us-ascii?q?S10iHuNY4kmhVGOTWKEAh4uAYdvgTIBAQE?=
X-IronPort-AV: E=Sophos;i="5.22,532,1449532800"; d="scan'208";a="635890806"
Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 03 Mar 2016 14:52:40 +0000
Received: from [10.98.149.198] (bxb-fandreas-8815.cisco.com [10.98.149.198]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id u23EqdRD004849; Thu, 3 Mar 2016 14:52:39 GMT
To: Juergen Stoetzer-Bradler <juergen.stoetzer-bradler@nokia.com>, "mmusic@ietf.org" <mmusic@ietf.org>
References: <BBE9739C2C302046BD34B42713A1E2A22E88D533@ESESSMB105.ericsson.se> <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> <56C6156C.2070308@cisco.com> <56C71EF3.6040208@alcatel-lucent.com> <56C74FDE.4040902@cisco.com> <56CC5E9B.5060307@alcatel-lucent.com> <56D61704.70205@cisco.com> <56D84051.4080303@alcatel-lucent.com>
From: Flemming Andreasen <fandreas@cisco.com>
Message-ID: <56D84FB7.4050109@cisco.com>
Date: Thu, 3 Mar 2016 09:52:39 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:38.0) Gecko/20100101 Thunderbird/38.6.0
MIME-Version: 1.0
In-Reply-To: <56D84051.4080303@alcatel-lucent.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/mmusic/vQIeYQNtxJi2hbW8-CvpxquotDA>
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: Thu, 03 Mar 2016 14:52:49 -0000


On 3/3/16 8:46 AM, Juergen Stoetzer-Bradler wrote:
> Flemming,
>
> Thanks for further feedback.
> Trying to summarize this discussion as follows.
>
> Current version 08 of draft-ietf-mmusic-data-channel-sdpneg contains 
> text related to data channel subprotocols and subprotocol attributes 
> as follows.
>
> * Within an SDP offer or answer subprotocols may be identified via the 
> "subprotocol" parameter value in a data channel's a=dcmap attribute. 
> (Section 5.1.1.5)
> * These subprotocol identifiers are registered using the existing IANA 
> "WebSocket Subprotocol Name Registry" table. If a certain protocol may 
> be used as Websocket subprotocol or as data channel subprotocol, then 
> this IANA table is expected to contain two references for this 
> subprotocol identifier - one referring to the corresponding Websocket 
> related document, and one referring to the corresponding data channel 
> related document. (Section 8.1)
> * An SDP offer or answer describing a subprotocol over a data channel 
> may additionally have subprotocol associated attributes, which are 
> embedded in the a=dcsa attribute. Section 5.2.3 recommends an SDP 
> offerer to add a non-empty subprotocol identifier if it also adds dcsa 
> embedded subprotocol attributes to its offer.
> * Section 5.1.2.1 specifies the a=dcsa attribute and says that 
> assumingly 'in general the usages of subprotocol related media level 
> attributes are independent from the subprotocol's transport protocol.  
> Such transport protocol independent subprotocol related attributes are 
> used in the same way as defined in the original subprotocol 
> specification, also if the subprotocol is transported over a data 
> channel and if the attribute is correspondingly embedded in a "a=dcsa" 
> attribute'.
> * Further, section 5.1.2.1 says that a data channel transport 
> depending semantic of a data channel subprotocol is expected to be 
> described in the same document, which adds the subprotocol identifier 
> to the IANA WebSocket Subprotocol Name Registry.
>
> Taking again MSRP as an example, 
> draft-ietf-mmusic-msrp-usage-data-channel-04 requests to add "MSRP" to 
> the IANA WebSocket Subprotocol Name Registry. An SDP offerer, when 
> creating an MSRP over data channel offer, is requested to add the 
> 'subprotocol="MSRP"' parameter to the corresponding a=dcmap attribute. 
> (Section 5.1.1.1 of that draft explicitly requests (using "SHALL") an 
> offerer to add this parameter to the a=dcmap attribute.) That draft 
> has dedicated text in sections 5.1.1.3 and 6, which describe the 
> specific semantic of the setup attribute, if this is a=dcsa embedded 
> and associated with MSRP as data channel subprotocol. (In this 
> specific case there is also text describing the relationship of dcsa 
> embedded setup attributes and non-dcsa embedded setup attributes, if 
> both are present in the same SDP offer or answer.)
>
> Following the above summarized description in 
> draft-ietf-mmusic-data-channel-sdpneg-08, the specific semantic of an 
> a=dcsa embedded setup attribute associated with data channel 
> subprotocol identifier "MSRP" can be retrieved by inspecting the IANA 
> "WebSocket Subprotocol Name Registry" table, and within that by 
> searching for data channel subprotocol identifier "MSRP".
>
> Do I understanding you correctly that you would prefer that 
> draft-ietf-mmusic-msrp-usage-data-channel additionally requests to 
> create a new IANA registry, which lists all those SDP attributes, 
> which can be used for MSRP as data channel subprotocol, and whose 
> semantics deviate from their initial specifications (as compared to 
> when used for MSRP over TCP or over TLS/TCP)?
Yes (for consistency with the second part you have below)
> As per my understanding such an additional MSRP data channel 
> subprotocol specific IANA registry should then contain the setup 
> attribute. And the setup attribute's entry in this registry would 
> refer to draft-ietf-mmusic-msrp-usage-data-channel, as there the data 
> channel transport specific semantic of an MSRP associated setup 
> attribute is described.
> Other MSRP related attributes (as listed in section 5.1.1.2 of 
> draft-ietf-mmusic-msrp-usage-data-channel like the a=accept-types, 
> a=path, a=max-size or the file transfer related attributes introduced 
> in RFC 5547) do not have a data channel transport depending meaning 
> and would not be added to that new IANA registry, would they?
>
Agreed - as long they retain their original meaning/definition 
independently of what the actual subprotocol is, then there is nothing 
special about them and hence no need to register them for any particular 
subprotocol.

> Right now I've got the impression that such a new data channel 
> subprotocol specific IANA registry might be somehow redundant, at 
> least in some cases. If the generic description of 
> draft-ietf-mmusic-data-channel-sdpneg-08 is followed when describing 
> how to use a protocol as data channel subprotocol, then the IANA 
> WebSocket Subprotocol Name Registry would associate the subprotocol 
> identifier with the document, which specifies how to use the protocol 
> as data channel subprotocol and which also describes potential data 
> channel specific (existing or new) subprotocol attributes. And that 
> document then would refer to the subprotocol specific new IANA 
> registry, which again would refer back to that document for all listed 
> subprotocol attributes.
>
> However, I realize that the text in section 5.1.2.1 of current version 
> 08 of draft-ietf-mmusic-data-channel-sdpneg does not explicitly 
> address cases, which you had mentioned earlier in this discussion:
>> 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. 
>
> I agree that in such cases such new attributes could indeed be added 
> to corresponding data channel subprotocol specific attribute 
> registries, which then could refer to the document introducing this 
> new attribute.
Right - and for consistency I think it then makes sense to have all 
subprotocol-specific attributes registered there.

> An alternative might be to only add such a new SDP attribute to the 
> generic IANA SDP attribute registry (which probably would be done 
> anyhow). I assume that the generic SDP attribute registry would also 
> refer to the document introducing this new attribute.
>
Either would work, however my preference would be a complete listing of 
attributes that have subprotocol specific meaning.

I'd be interested in what other people think though


Thanks

-- Flemming (with my individual hat on)


> Thanks,
> Juergen
>
>
> On 01.03.2016 23:26, EXT Flemming Andreasen wrote:
>>
>>
>> On 2/23/16 8:28 AM, Juergen Stoetzer-Bradler wrote:
>>> Flemming,
>>>
>>> Thanks for further feedback. Regarding your comments:
>>>> 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.
>>> and
>>>> 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). 
>>>
>>> Ok, as per my understanding such a new attribute would be introduced 
>>> in a (let's assume) future document. I think that such a future 
>>> document should describe the new attribute's semantic with respect 
>>> to all protocols for which it is intended to be used. And if one of 
>>> these protocols can be transported over data channels, and if the 
>>> new attribute's meaning then also has data channel specific aspects, 
>>> this future document should also describe those aspects. If this new 
>>> attribute is then added to the IANA SDP attribute registry 
>>> (presumably as media level only or media and session level 
>>> attribute), then this document could be found when searching for the 
>>> new attribute.
>>>
>> Agreed.
>>> I am not yet sure I fully understand how such subprotocol specific 
>>> registries could be used. Right now there are already drafts 
>>> describing MSRP, BFCP and T.140 as data channel subprotocols. Do you 
>>> think IANA registry tables for each of these subprotocols should be 
>>> created (and in future for any further protocol, which might be used 
>>> as data channel subprotocol)?
>>> Where then a new attribute might be listed in multiple of these 
>>> subprotocol specific registries, depending on which subprotocol it 
>>> might be used for?
>>> And all already existing attributes, which might also be used for a 
>>> data channel subprotocol - do you think that these should also be 
>>> added to such subprotocol specific registry tables?
>>>
>> Going a few e-mails back in this thread, the below was your proposal:
>> <quote>
>> ...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.
>> </quote>
>>
>> The key part (for me) in the above is to only have the subprotocol 
>> specific registration when the usage or semantic is subprotocol 
>> specific. Thus, I do not envision already existing attributes to be 
>> added here (unless there is subprotocol specific usage in which case 
>> a new document will need to define that).
>>
>>> Coming back to MSRP as an example - RFC 5547 defines several file 
>>> transfer related attributes. Conceivably, a future document could 
>>> define another file transfer protocol unequal to MSRP (and based on 
>>> data channel transport, or based on a transport protocol unequal to 
>>> data channel). And that potential future document might then 
>>> describe how (some of) the file transfer related SDP attributes 
>>> might be re-used for this new file transfer protocol. Would you then 
>>> expect these file transfer related SDP attributes to be added to 
>>> such a new registry associated with the new file transfer protocol? 
>>> Also if data channel transport of this potential new file transfer 
>>> protocol were not defined in that assumed future document?
>>>
>> Only if their usage with this new file transfer protocol differed 
>> from the existing usage. The registry would essentially convey that 
>> there is subprotocol specific behavior with a reference to the 
>> relevant document. Conversely, if there is no entry in the registry, 
>> there is no subprotocol specific behavior defined.
>>
>>> Right now I'm not sure if this topic is only data channel specific. 
>>> E.g. the a=setup attribute was originally introduced in RFC 4145 for 
>>> TCP connection negotiation. Later on, this attribute was reused for 
>>> TLS connection negotiation (RFC 4572) and DTLS association 
>>> negotiation (RFC 5763, draft-ietf-mmusic-sctp-sdp, 
>>> draft-ietf-mmusic-dtls-sdp). As far as I see the IANA SDP parameters 
>>> registry for the a=setup attribute only refers to RFC 4145. And the 
>>> two sctp-sdp and dtls-sdp drafts don't seem to request updating this 
>>> registry. However, all these documents have setup attribute related 
>>> texts describing the extended semantics of the setup attribute.
>>>
>> Fair point - there probably should be some references there.
>>
>>> Somebody seeing an SDP offer like the UDP/DTLS/SCTP related one in 
>>> section 13.1 of draft-ietf-mmusic-sctp-sdp-15, when looking for the 
>>> setup attribute's usage in this SDP offer and when therefore 
>>> searching the related reference in the IANA SDP attribute registry, 
>>> would only find the reference to RFC 4145. However, he/she could 
>>> look up the UDP/DTLS/SCTP m-line proto value in the IANA SDP proto 
>>> registry, and there would find the reference to the future RFC of 
>>> draft-ietf-mmusic-sctp-sdp, where the semantic of the setup 
>>> attribute within this SDP offer instance is specified.
>>>
>>> Somebody seeing an SDP offer like the DTLS-SRTP related one in 
>>> section 7.1 of RFC 5763, again when trying to find the semantic of 
>>> the setup attribute in this SDP offer, would similarly find the 
>>> reference to RFC 4145. When searching the proto registry for 
>>> UDP/TLS/RTP/SAVP he/she would find the reference to RFC 5764. RFC 
>>> 5764 does not mention the setup attribute at all, but RFC 5763 does 
>>> and describes its usage in the DTLS-SRTP case. [But then it might 
>>> not be clear if this setup attribute is used in the original sense 
>>> of RFCs 5763 / 5764, or with the modified semantic described in 
>>> draft-ietf-mmusic-dtls-sdp (which excludes value 'holdconn').]
>>>
>>> In these cases, do you think that subprotocol (TLS and DTLS as 
>>> "subprotocols" of TCP and UDP) specific sub-registries should be 
>>> created? And if yes, how do you envision those would be used?
>>>
>> I don't think we should create those, because in general, attributes 
>> have a well-defined meaning that applies across protocols (unless the 
>> attribute is specifically defined for a single protocol or profile, 
>> e.g. RTP). Once we deviate from that principle (e.g. by explicitly 
>> defining sub-protocol specific usage for a given attribute), then I 
>> do think it's appropriate to have that reflected in a registry so 
>> people can figure out what they need to look at.
>>
>> Thanks
>>
>> -- Flemming
>>
>>
>>
>>
>>> Thanks,
>>> Juergen
>>>
>>>
>>> On 19.02.2016 18:24, EXT Flemming Andreasen wrote:
>>>>
>>>>
>>>> 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
>>>>>>>>>>>>>>>
>>>
>>>
>>> .
>>>
>>
>
> .
>