Re: [MMUSIC] WGLC for draft-ietf-mmusic-data-channel-sdpneg
Juergen Stoetzer-Bradler <juergen.stoetzer-bradler@nokia.com> Tue, 08 March 2016 13:53 UTC
Return-Path: <juergen.stoetzer-bradler@nokia.com>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 67CE512D6E6 for <mmusic@ietfa.amsl.com>; Tue, 8 Mar 2016 05:53:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.921
X-Spam-Level:
X-Spam-Status: No, score=-6.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([127.0.0.1]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5CfkPMz40A5q for <mmusic@ietfa.amsl.com>; Tue, 8 Mar 2016 05:53:45 -0800 (PST)
Received: from smtp-fr.alcatel-lucent.com (fr-hpida-esg-02.alcatel-lucent.com [135.245.210.21]) (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 9A2E612D6EF for <mmusic@ietf.org>; Tue, 8 Mar 2016 05:53:41 -0800 (PST)
Received: from fr712umx4.dmz.alcatel-lucent.com (unknown [135.245.210.45]) by Websense Email Security Gateway with ESMTPS id 3C4508DA2BF1E for <mmusic@ietf.org>; Tue, 8 Mar 2016 13:53:37 +0000 (GMT)
Received: from fr712usmtp2.zeu.alcatel-lucent.com (fr712usmtp2.zeu.alcatel-lucent.com [135.239.2.42]) by fr712umx4.dmz.alcatel-lucent.com (GMO-o) with ESMTP id u28Drd2I001335 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for <mmusic@ietf.org>; Tue, 8 Mar 2016 13:53:39 GMT
Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id u28DqRpc028911 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for <mmusic@ietf.org>; Tue, 8 Mar 2016 14:53:33 +0100
Received: from [149.204.68.190] (135.239.27.38) by FR711WXCHHUB01.zeu.alcatel-lucent.com (135.239.2.111) with Microsoft SMTP Server (TLS) id 14.3.195.1; Tue, 8 Mar 2016 14:51:36 +0100
References: <BBE9739C2C302046BD34B42713A1E2A22E88D533@ESESSMB105.ericsson.se> <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> <56D84FB7.4050109@cisco.com> <56DCC592.2060503@nteczone.com> <56DE4123.3030606@cisco.com>
From: Juergen Stoetzer-Bradler <juergen.stoetzer-bradler@nokia.com>
To: "mmusic@ietf.org" <mmusic@ietf.org>
Message-ID: <56DED8E7.7060705@alcatel-lucent.com>
Date: Tue, 08 Mar 2016 14:51:35 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0
MIME-Version: 1.0
In-Reply-To: <56DE4123.3030606@cisco.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: quoted-printable
X-Originating-IP: [135.239.27.38]
Archived-At: <http://mailarchive.ietf.org/arch/msg/mmusic/spdiTYHw_F7H8l9dMx8zMJ284PQ>
Subject: Re: [MMUSIC] WGLC for draft-ietf-mmusic-data-channel-sdpneg
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.17
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: Tue, 08 Mar 2016 13:53:48 -0000
Flemming, Paul, Christian, Trying to summarize, as per my understanding following three main options (A), (B) and (C) have been discussed in this email thread regarding the IANA registration of SDP attributes. (A) "One new global IANA registry for data channel subprotocol attributes, common for all data channel subprotocols": Similar to IANA's RTP source level attribute registry a global IANA "data channel level" attribute registry could be created. (i) Either, this registry could list all existing (and potential future) attributes, and for each attribute could state if it could also be used as dcsa embedded attribute associated with certain data channel subprotocols. Each attribute within this registry might then be associated with zero, one or multiple document references, where each referenced document should describe this attribute's semantic and usage for a specific subprotocol. (Which would not exclude one document describing an attribute's semantic and usage for more than just one data channel subprotocol.) (ii) Or, this registry could list only those existing (and potential future) attributes, which have already been identified as data channel subprotocol attributes. All such already identified data channel subprotocol attributes could be listed in that registry, regardless of whether or not the usage of these attributes is specific for data channel transport. Each attributes listed in this registry could be associated with one or multiple document references. Each such a reference could point to a document which could either describe the data channel transport specific usage of this attribute for one or several data channel subprotocols. Or such a reference could point to the document, which defines this attribute in a data channel independent / generic way (if usage of this attribute does not have data channel transport specific aspects). (iii) Or, this registry could only list those existing (and potential future) attributes, which have already been identified as data channel subprotocol attributes, and whose usage is indeed data channel transport specific. Similar as in (ii) each attribute listed in this registry could be associated with one or multiple document references. Each such reference could point to a document which could describe the data channel transport specific usage of this attribute for one or several data channel subprotocols. (B) "For each data channel subprotocol one new dedicated attribute registry": The document, which requests to add the data channel subprotocol's identifier to the IANA WebSocket subprotocol name registry, could additionally request to create a new IANA registry, specific for this subprotocol, which could list all attributes, which can be used as a=dcsa embedded attributes for this data channel subprotocol. Similar as in (A) there seem to be (at least) two sub-options: (i) Either, this subprotocol specific registry could list all attributes, which could be used for this subprotocol (and have already been identified as such) in case of data channel transport. Each such attribute could then be associated with exactly one document reference, where this reference either could point to a document, which describes the data channel transport specific usage of this attribute for this specific subprotocol, or could point to a document, which specifies this attribute in a data channel independent way. (ii) Or, this subprotocol specific registry could only list those attributes, which could be used for this subprotocol, and which have a data channel transport specific semantic. Each such attribute could then be associated with a document describing this data channel transport specific semantic for this subprotocol. (C) "No data channel specific registry(s) - re-use of the already existing session and media level or media level only registries": The document, which requests to add the data channel subprotocol's identifier to the IANA Websocket subprotocol id registry, could additionally describe the usages of those attributes, which may be used for this data channel subprotocol, and whose usages and/or semantics have data channel transport specific aspects. However, if those attributes did already exist prior to the creation of this data channel subprotocol document, then the already existing IANA registrations of those attributes would not be modified. If this data channel subprotocol describing document introduced new subprotocol specific attributes, then it could request these to be added to the exiting media level only attribute registry. Subsequently, if a later document introduces new attributes, which could also be used for that subprotocol in the data channel transport case, then that later document could describe this data channel subprotocol specific usage, and could also add these attributes to the existing session and media level or media level only attribute registry. If I am not mistaken then (A)(i) was the option which Paul initially mentioned in this email thread. And Paul also mentioned a variant, where the already existing attribute registries could be merged into just one, where a new field could be added describing the attribute's scope (which then could contain more than just one scope), and where also 'data channel level' could be an attribute's scope. In such a case different scopes might potentially refer to different documents. In his last email Christian did also refer to option (A), I think. Option (B) was mentioned by Flemming, where he expressed a preference for (B)(i), as far as I understood. Option (C) is the one which is (to the most part) described in current version 08 of draft-ietf-mmusic-data-channel-sdpneg. Would there be another option, which I haven't described above? Would there be one (sub-)option, everybody could live with? Based on this discussion, if option (C) isn't agreeable, then I myself would prefer option (B), with a tendency to (B)(ii), as this might provide more flexibility for implementations, which want to use an attribute for a data channel subprotocol with its original (data channel transport independent) semantic, also if this attribute has not been added to the data channel subprotocol specific attribute registry. And as I still think that most of those attributes would be used transport protocol stack independently. Thanks again, Juergen On 08.03.2016 04:04, EXT Flemming Andreasen wrote: > > > On 3/6/16 7:04 PM, Christian Groves wrote: >> Hello Flemming and Juergen, >> >> ..snip.. >>>> 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 >> >> From looking at the existing IANA registry >> http://www.iana.org/assignments/sdp-parameters/sdp-parameters.xhtml >> >> It feels like we should take the approach for att-field (source level) and define att-field (data >> channel). >> > Thanks for the feedback Christian. Just to be clear: We would need to allow for multiple entries > per attribute, since different sub-protocols could each define sub-protocol specific behavior for > an attribute. > > Thanks > > -- Flemming > > >> Regards, Christian >> >>> >>> >>> Thanks >>> >>> -- Flemming (with my individual hat on) >>> >> >> . >> >
- 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