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: A0BvBgCcTthW/xbLJq1dhAxthDKzZoQJIYUkSgKBdwEBAQEBAWUnhEEBAQEDARoJFToGBgsLGAICBRYLAgIJAwIBAgFFBgEJAwgBAQWIEAgOrjmPMQEBAQEBAQEBAQEBAQEBAQEBGXuFHYQ8hAgRAYMegToFjS10iHuNY4kmhVGOTWKEAh4uAYdvgTIBAQE
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, 03 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 >>>>>>>>>>>>>>> >>> >>> >>> . >>> >> > > . >
- Re: [MMUSIC] WGLC for draft-ietf-mmusic-data-chan… Christian Groves
- Re: [MMUSIC] WGLC for draft-ietf-mmusic-data-chan… Paul Kyzivat
- [MMUSIC] WGLC for draft-ietf-mmusic-data-channel-… Bo Burman
- Re: [MMUSIC] WGLC for draft-ietf-mmusic-data-chan… Christian Groves
- Re: [MMUSIC] WGLC for draft-ietf-mmusic-data-chan… Juergen Stoetzer-Bradler
- Re: [MMUSIC] WGLC for draft-ietf-mmusic-data-chan… Christian Groves
- Re: [MMUSIC] WGLC for draft-ietf-mmusic-data-chan… Juergen Stoetzer-Bradler
- Re: [MMUSIC] WGLC for draft-ietf-mmusic-data-chan… Paul Kyzivat
- Re: [MMUSIC] WGLC for draft-ietf-mmusic-data-chan… Christian Groves
- Re: [MMUSIC] WGLC for draft-ietf-mmusic-data-chan… DRAGE, Keith (Keith)
- Re: [MMUSIC] WGLC for draft-ietf-mmusic-data-chan… Juergen Stoetzer-Bradler
- Re: [MMUSIC] WGLC for draft-ietf-mmusic-data-chan… Paul Kyzivat
- Re: [MMUSIC] WGLC for draft-ietf-mmusic-data-chan… Christian Groves
- Re: [MMUSIC] WGLC for draft-ietf-mmusic-data-chan… Paul Kyzivat
- Re: [MMUSIC] WGLC for draft-ietf-mmusic-data-chan… Christian Groves
- Re: [MMUSIC] WGLC for draft-ietf-mmusic-data-chan… DRAGE, Keith (Keith)
- Re: [MMUSIC] WGLC for draft-ietf-mmusic-data-chan… Paul Kyzivat
- Re: [MMUSIC] WGLC for draft-ietf-mmusic-data-chan… Flemming Andreasen
- Re: [MMUSIC] WGLC for draft-ietf-mmusic-data-chan… Paul Kyzivat
- Re: [MMUSIC] WGLC for draft-ietf-mmusic-data-chan… Flemming Andreasen
- Re: [MMUSIC] WGLC for draft-ietf-mmusic-data-chan… Paul Kyzivat
- Re: [MMUSIC] WGLC for draft-ietf-mmusic-data-chan… Flemming Andreasen
- Re: [MMUSIC] WGLC for draft-ietf-mmusic-data-chan… Paul Kyzivat
- Re: [MMUSIC] WGLC for draft-ietf-mmusic-data-chan… Christian Groves
- Re: [MMUSIC] WGLC for draft-ietf-mmusic-data-chan… Flemming Andreasen
- Re: [MMUSIC] WGLC for draft-ietf-mmusic-data-chan… Paul Kyzivat
- Re: [MMUSIC] WGLC for draft-ietf-mmusic-data-chan… Paul Kyzivat
- Re: [MMUSIC] WGLC for draft-ietf-mmusic-data-chan… Flemming Andreasen
- Re: [MMUSIC] WGLC for draft-ietf-mmusic-data-chan… Paul Kyzivat
- Re: [MMUSIC] WGLC for draft-ietf-mmusic-data-chan… Flemming Andreasen
- Re: [MMUSIC] WGLC for draft-ietf-mmusic-data-chan… Juergen Stoetzer-Bradler
- Re: [MMUSIC] WGLC for draft-ietf-mmusic-data-chan… Flemming Andreasen
- Re: [MMUSIC] WGLC for draft-ietf-mmusic-data-chan… Paul Kyzivat
- Re: [MMUSIC] WGLC for draft-ietf-mmusic-data-chan… Paul Kyzivat
- Re: [MMUSIC] WGLC for draft-ietf-mmusic-data-chan… Juergen Stoetzer-Bradler
- Re: [MMUSIC] WGLC for draft-ietf-mmusic-data-chan… Juergen Stoetzer-Bradler
- Re: [MMUSIC] WGLC for draft-ietf-mmusic-data-chan… Paul Kyzivat
- Re: [MMUSIC] WGLC for draft-ietf-mmusic-data-chan… Christian Groves
- Re: [MMUSIC] WGLC for draft-ietf-mmusic-data-chan… Juergen Stoetzer-Bradler
- Re: [MMUSIC] WGLC for draft-ietf-mmusic-data-chan… Juergen Stoetzer-Bradler
- Re: [MMUSIC] WGLC for draft-ietf-mmusic-data-chan… Juergen Stoetzer-Bradler
- Re: [MMUSIC] WGLC for draft-ietf-mmusic-data-chan… Flemming Andreasen
- Re: [MMUSIC] WGLC for draft-ietf-mmusic-data-chan… Juergen Stoetzer-Bradler
- Re: [MMUSIC] WGLC for draft-ietf-mmusic-data-chan… Paul Kyzivat
- Re: [MMUSIC] WGLC for draft-ietf-mmusic-data-chan… Flemming Andreasen
- Re: [MMUSIC] WGLC for draft-ietf-mmusic-data-chan… Juergen Stoetzer-Bradler
- Re: [MMUSIC] WGLC for draft-ietf-mmusic-data-chan… Juergen Stoetzer-Bradler
- Re: [MMUSIC] WGLC for draft-ietf-mmusic-data-chan… Paul Kyzivat
- Re: [MMUSIC] WGLC for draft-ietf-mmusic-data-chan… Christian Groves
- Re: [MMUSIC] WGLC for draft-ietf-mmusic-data-chan… Paul Kyzivat
- Re: [MMUSIC] WGLC for draft-ietf-mmusic-data-chan… Christian Groves
- Re: [MMUSIC] WGLC for draft-ietf-mmusic-data-chan… Paul Kyzivat
- Re: [MMUSIC] WGLC for draft-ietf-mmusic-data-chan… Juergen Stoetzer-Bradler
- Re: [MMUSIC] WGLC for draft-ietf-mmusic-data-chan… Paul Kyzivat
- Re: [MMUSIC] WGLC for draft-ietf-mmusic-data-chan… Christian Groves
- Re: [MMUSIC] WGLC for draft-ietf-mmusic-data-chan… Schwarz, Albrecht (Nokia - DE)
- Re: [MMUSIC] WGLC for draft-ietf-mmusic-data-chan… Paul Kyzivat
- Re: [MMUSIC] WGLC for draft-ietf-mmusic-data-chan… Flemming Andreasen
- Re: [MMUSIC] WGLC for draft-ietf-mmusic-data-chan… Juergen Stoetzer-Bradler
- Re: [MMUSIC] WGLC for draft-ietf-mmusic-data-chan… Flemming Andreasen
- Re: [MMUSIC] WGLC for draft-ietf-mmusic-data-chan… Christian Groves
- Re: [MMUSIC] WGLC for draft-ietf-mmusic-data-chan… Paul Kyzivat
- Re: [MMUSIC] WGLC for draft-ietf-mmusic-data-chan… Flemming Andreasen
- Re: [MMUSIC] WGLC for draft-ietf-mmusic-data-chan… Juergen Stoetzer-Bradler
- Re: [MMUSIC] WGLC for draft-ietf-mmusic-data-chan… Christian Groves
- Re: [MMUSIC] WGLC for draft-ietf-mmusic-data-chan… Juergen Stoetzer-Bradler
- Re: [MMUSIC] WGLC for draft-ietf-mmusic-data-chan… Paul Kyzivat
- Re: [MMUSIC] WGLC for draft-ietf-mmusic-data-chan… Christian Groves
- Re: [MMUSIC] WGLC for draft-ietf-mmusic-data-chan… Flemming Andreasen
- Re: [MMUSIC] WGLC for draft-ietf-mmusic-data-chan… Flemming Andreasen
- Re: [MMUSIC] WGLC for draft-ietf-mmusic-data-chan… Juergen Stoetzer-Bradler
- Re: [MMUSIC] WGLC for draft-ietf-mmusic-data-chan… Paul Kyzivat
- Re: [MMUSIC] WGLC for draft-ietf-mmusic-data-chan… Paul Kyzivat