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

Christian Groves <Christian.Groves@nteczone.com> Wed, 09 March 2016 00:53 UTC

Return-Path: <Christian.Groves@nteczone.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 4197212DCE0 for <mmusic@ietfa.amsl.com>; Tue, 8 Mar 2016 16:53:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.79
X-Spam-Level:
X-Spam-Status: No, score=-1.79 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, T_DKIM_INVALID=0.01] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (public key: not available)" header.d=nteczone.com
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 Xo57cAgD8yyt for <mmusic@ietfa.amsl.com>; Tue, 8 Mar 2016 16:53:47 -0800 (PST)
Received: from msh03.myshophosting.com (msh03.myshophosting.com [101.0.109.158]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 680E212DCDE for <mmusic@ietf.org>; Tue, 8 Mar 2016 16:53:47 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=nteczone.com; s=default; h=Content-Transfer-Encoding:Content-Type: In-Reply-To:MIME-Version:Date:Message-ID:From:References:To:Subject; bh=Xv9qsZOnEffX1l6C4RGUkQpHWlmovf/bzDNN5LU/xYE=; b=tAc68iB+yHs8OcK/2j6sszNgur 3UwsPP35utjz2ZgfDrrZdBhsTcOtxV4+4v7TF214pDMpQ4I/rkDAnCUhQAPPbQCFDxTvOrvASNKhc hclxERHvgoMWEHX2Nbryc4M3jEgLh8i6VRMVYdsHVycyW+txCGRqBNEpXa0KpaDjUXSW1ZDSOhWXp UVDbcK767SnNZOBH4SJRf5grH43uP6TP0ndI0/Z2bPIJZI5njuA701tZLjVcLpO2tu/fEpM7Kva6m UVKkfCcevzh7046d4B3XA181cWRos2qzS/098zD407TInfCxDIc1RZFSMYT4h94dqktaiuPBIwUNI pIRVRsUg==;
Received: from ppp118-209-64-163.lns20.mel4.internode.on.net ([118.209.64.163]:53704 helo=[192.168.1.22]) by msh03.myshophosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.86_1) (envelope-from <Christian.Groves@nteczone.com>) id 1adSNk-001W7m-Kw for mmusic@ietf.org; Wed, 09 Mar 2016 11:53:44 +1100
To: mmusic@ietf.org
References: <BBE9739C2C302046BD34B42713A1E2A22E88D533@ESESSMB105.ericsson.se> <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> <56DED8E7.7060705@alcatel-lucent.com>
From: Christian Groves <Christian.Groves@nteczone.com>
Message-ID: <56DF7414.5090604@nteczone.com>
Date: Wed, 9 Mar 2016 11:53:40 +1100
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: <56DED8E7.7060705@alcatel-lucent.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - msh03.myshophosting.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - nteczone.com
X-Get-Message-Sender-Via: msh03.myshophosting.com: authenticated_id: christian.groves@nteczone.com
X-Authenticated-Sender: msh03.myshophosting.com: christian.groves@nteczone.com
X-Source:
X-Source-Args:
X-Source-Dir:
Archived-At: <http://mailarchive.ietf.org/arch/msg/mmusic/vKiWIIm6OLFl-F9qkRjVlo3oOmU>
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: Wed, 09 Mar 2016 00:53:50 -0000

Hello Juergen,

What I was thinking was that:
- If a subprotocol (datachannel) reuses media or session attributes a 
reference to the subprotocol RFC is added to the IANA registration for 
the attribute only I there was some specific behaviour change or 
consideration.
- If a subprotocol RFC defines a data channel specific attribute (i.e. 
cannot be used at the media or session level) then this would go into a 
new global IANA "data channel level" registry.
- The data channel level attribute could be reused by multiple data 
channels so it should be possible to include multiple references (my 
understanding of Flemming's point).

I guess this is your (A)(i) below?

If it is then I don't think its possible for a registry entry to be 
associated with zero document, i.e. there must always be a document 
reference.

Option B(i) seems to be a summary of what the RFC defining the 
sub-protocol would say. People can find out what attributes are used by 
reading the RFC itself rather than an IANA registry. So I'm not 
particularly in favour of that.

Option B(ii) seems to be the same as A(i) with the lookup key being the 
sub-protocol id rather than an attributeID. It seems the convention 
applied to SDP is lookup based on attribute rather than protocol. E.g. 
there are other protocols that use multiple media or session level 
attributes but they don't have their own registry.


Regards, Christian

On 9/03/2016 12:51 AM, Juergen Stoetzer-Bradler wrote:
> 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)
>>>>
>>>
>>> .
>>>
>>
>
>
> _______________________________________________
> mmusic mailing list
> mmusic@ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic
>