Re: [MMUSIC] IANA registration of SDP attributes

Christian Groves <Christian.Groves@nteczone.com> Tue, 22 March 2016 20:22 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 054ED12D979 for <mmusic@ietfa.amsl.com>; Tue, 22 Mar 2016 13:22:51 -0700 (PDT)
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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0Mq9p4HHMlHA for <mmusic@ietfa.amsl.com>; Tue, 22 Mar 2016 13:22:48 -0700 (PDT)
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 09DAF12D97F for <mmusic@ietf.org>; Tue, 22 Mar 2016 13:22:47 -0700 (PDT)
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=qy8a/1q2++/VAWR3sK9zIGv1+gxt93fxQjyx/FhK2fk=; b=NRQ/Uhpic6vIDEd2Rrb81bpldn Q52BtkDO+lM/7SPOp9Rr/PCtbcuLr6Mt0vIFOkCQT8huAoFgPQ5jyOJMg4ki/aF2wbF2rEPwMzz06 x/f99q4ZaX1kdQtcKLSAbL96yoEHKQ3PR6UjEJjwV5iaqdPdPslIarAfUqAJgWR7YCzLmn9+7MP5M 9cpl0DikwapBF71XmRUckEI7tFC1HO2aX/eDVoMyiZJ8iVbZ0+wyjucD1bfM2BTEa+odPrAwb8tQb kQWHmbR152ra3+THJtLuSDXX1KPFoODfbDLJxpsYZPtjJnbZOt7BE4kZKzR5pwhJVXJOhbroyQoFl SafSLJow==;
Received: from ppp118-209-30-74.lns20.mel4.internode.on.net ([118.209.30.74]:50599 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 1aiSpA-000rj0-9p; Wed, 23 Mar 2016 07:22:44 +1100
To: Flemming Andreasen <fandreas@cisco.com>, mmusic@ietf.org, Bo Burman <bo.burman@ericsson.com>
References: <56E1C193.1050308@alum.mit.edu> <56E2EF31.2020808@alcatel-lucent.com> <56E2F67D.7060005@alum.mit.edu> <56EE0AA1.3030502@nteczone.com> <56EEE286.5090505@alum.mit.edu> <56F09E03.5020200@nteczone.com> <56F198C9.3080604@cisco.com>
From: Christian Groves <Christian.Groves@nteczone.com>
Message-ID: <56F1A990.9080901@nteczone.com>
Date: Wed, 23 Mar 2016 07:22: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: <56F198C9.3080604@cisco.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/eQmvKfBy6rQmiEXd6ZKAknjLDeI>
Subject: Re: [MMUSIC] IANA registration of SDP attributes
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, 22 Mar 2016 20:22:51 -0000

Hello Flemming,

I thought Paul would be a good person as he seems to have a vision for 
the registry. However if Paul (and Juergen) isn't going to be in the 
room I'm not sure how effective the discussion will be. If you still 
feel if it would be worth it then I can put a couple of slides together.

Regards, Christian

On 23/03/2016 6:11 AM, Flemming Andreasen wrote:
>
>
> On 3/21/16 9:21 PM, Christian Groves wrote:
>> Hello Paul,
>>
>> Yes I think it is fuzzy. draft-ietf-mmusic-sctp-sdp is using a=setup 
>> for SCTP, by the definition below it would need to update the 
>> registry to add a reference. There's probably other attributes where 
>> this is the case also (e.g. a=connection). For consistency all the 
>> existing attributes would need to be checked when reformatting the 
>> registry.
>>
>> I do agree that it would be nice to have a link from each SDP 
>> attribute to the RFCs that are using it but I think the genie is out 
>> of the bottle on this one.
>>
>> With the light agenda maybe this is something to discuss in Argentina?
>>
> Do we have a volunteer to drive the discussion there ?
>
> Thanks
>
> -- Flemming
>
>> Regards, Christian
>>
>> On 21/03/2016 4:48 AM, Paul Kyzivat wrote:
>>> On 3/19/16 10:27 PM, Christian Groves wrote:
>>>> With the current registry don't only documents that introduce NEW
>>>> attributes get included in the registry?
>>>>
>>>> dcsa (MSRP) and dcsa (BFCP) don't define new attributes they use 
>>>> setup.
>>>> This is similar to the fact that multiple protocols at the media level
>>>> use a=setup but we don't add references to them in the registry.
>>>>
>>>> So do we now say that if a draft/RFC uses an existing media level
>>>> attribute in a DCSA that must be added to the registry with a dcsa
>>>> indication?
>>>
>>> ISTM that a document that broadens the applicability of an attribute 
>>> ought to be recorded in the registry.
>>>
>>> I expect that this is a bit fuzzy. For instance, the use of setup 
>>> with TCP was defined. If a new proto of 'TCP/FOO' is defined that 
>>> runs over TCP, and simply uses setup for establishing the TCP part, 
>>> then maybe it doesn't need to be recorded in the registry.
>>>
>>> But if setup is used for something other than TCP, or also used for 
>>> some semantic over and above its use for TCP, then it surely ought 
>>> to be recorded. (For instance, when it is used to control 
>>> initialization of some other protocol over TCP.)
>>>
>>> I expect that this is less than clear, and may be controversial. 
>>> Seems to need more discussion.
>>>
>>>     Thanks,
>>>     Paul
>>>
>>>> Regards, Christian
>>>>
>>>> On 12/03/2016 3:46 AM, Paul Kyzivat wrote:
>>>>> On 3/11/16 11:15 AM, Juergen Stoetzer-Bradler wrote:
>>>>>> Paul,
>>>>>>
>>>>>> The last alternative would have the advantage that different 
>>>>>> subprotocol
>>>>>> documents could be referenced for the same attribute. Like e.g. 
>>>>>> for the
>>>>>> setup attribute (if there were BFCP over data channel transport 
>>>>>> specific
>>>>>> aspects):
>>>>>>
>>>>>> *SDP Name*     *Level(s)*     *Reference(s)*
>>>>>> accept-types
>>>>>>     media,
>>>>>> dcsa(MSRP)
>>>>>>     [RFC4975]
>>>>>> [draft-ietf-mmusic-msrp-usage-data-channel]
>>>>>> cat
>>>>>>     session
>>>>>>     [RFC4566]
>>>>>> fmtp
>>>>>>     media,source     [RFC4566][RFC5576]
>>>>>> mediaclk
>>>>>>     session,media,source
>>>>>>     [RFC7273]
>>>>>> ptime
>>>>>>     media
>>>>>>     [RFC4566]
>>>>>> recvonly
>>>>>>     session,media,
>>>>>> dcsa(MSRP)
>>>>>>     [RFC4566][RFC4975]
>>>>>> [draft-ietf-mmusic-msrp-usage-data-channel]
>>>>>> setup
>>>>>>     session, media
>>>>>> dcsa(MSRP)
>>>>>> dcsa(BFCP)
>>>>>>     [RFC4145]
>>>>>> [draft-ietf-mmusic-msrp-usage-data-channel]
>>>>>> [draft-schwarz-mmusic-bfcp-usage-data-channel]
>>>>>>
>>>>>>
>>>>>> Therefore I'd be in favor of your last alternative.
>>>>>
>>>>> Let's see what other comments we get, especially from Flemming.
>>>>>
>>>>> Then, if this is preferred direction we can work on refining it.
>>>>>
>>>>>     Thanks,
>>>>>     Paul
>>>>>
>>>>>> Thanks,
>>>>>> Juergen
>>>>>>
>>>>>>
>>>>>> On 10.03.2016 19:48, EXT Paul Kyzivat wrote:
>>>>>>> [splitting off from the thread on data-channel-sdpneg]
>>>>>>>
>>>>>>> Currently IANA has five(!) separate registries for sdp attributes:
>>>>>>>
>>>>>>> att-field (session level)
>>>>>>> att-field (both session and media level)
>>>>>>> att-field (media level only)
>>>>>>> att-field (source level)
>>>>>>> att-field (unknown level)
>>>>>>>
>>>>>>> They all have the same format:
>>>>>>>
>>>>>>> *Type**
>>>>>>> *     *SDP Name**
>>>>>>> *     *Reference**
>>>>>>> *
>>>>>>> att-field (session level)     cat     [RFC4566]
>>>>>>> att-field (both session and media level)     recvonly
>>>>>>>     [RFC4566]
>>>>>>> att-field (both session and media level)     mediaclk
>>>>>>>     [RFC7273]
>>>>>>> att-field (media level only)     accept-types
>>>>>>>     [RFC4975]
>>>>>>> att-field (media level only)     fmtp
>>>>>>>     [RFC4566]
>>>>>>> att-field (source level)     fmtp
>>>>>>>     [RFC5576]
>>>>>>>
>>>>>>>
>>>>>>> This format is a pain, because it is hard to look an attribute 
>>>>>>> up if
>>>>>>> you don't know at what level(s) it is valid. It also has the 
>>>>>>> potential
>>>>>>> to allow an attribute name to be registered for unrelated 
>>>>>>> purposes if
>>>>>>> the type is different. (IMO that would be bad.)
>>>>>>>
>>>>>>> A long time ago (several years now), as part of the 4566bis work, I
>>>>>>> proposed that these tables be merged into one. It was my impression
>>>>>>> that this was agreed and would be done. But I don't recall any
>>>>>>> agreement on the logistics of doing so.
>>>>>>>
>>>>>>> My thought was that the combined table would look like:
>>>>>>>
>>>>>>> *SDP Name*     *Level(s)*     *Reference(s)*
>>>>>>> accept-types
>>>>>>>     media
>>>>>>>     [RFC4975]
>>>>>>> cat
>>>>>>>     session
>>>>>>>     [RFC4566]
>>>>>>> fmtp
>>>>>>>     media,source     [RFC4566][RFC5576]
>>>>>>> mediaclk
>>>>>>>     session,media,source
>>>>>>>     [RFC7273]
>>>>>>> ptime
>>>>>>>     media
>>>>>>>     [RFC4566]
>>>>>>> recvonly
>>>>>>>     session,media
>>>>>>>     [RFC4566]
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Then we get to data channel attributes. My thought is to 
>>>>>>> incorporate
>>>>>>> them into this table structure, as yet another "level". E.g.,
>>>>>>>
>>>>>>> *SDP Name*     *Level(s)*     *Reference(s)*
>>>>>>> accept-types
>>>>>>>     media,dcsa
>>>>>>> [RFC4975][draft-ietf-mmusic-msrp-usage-data-channel]
>>>>>>> cat
>>>>>>>     session
>>>>>>>     [RFC4566]
>>>>>>> fmtp
>>>>>>>     media,source     [RFC4566][RFC5576]
>>>>>>> mediaclk
>>>>>>>     session,media,source
>>>>>>>     [RFC7273]
>>>>>>> ptime
>>>>>>>     media
>>>>>>>     [RFC4566]
>>>>>>> recvonly
>>>>>>>     session,media,dcsa
>>>>>>> [RFC4566][RFC4975][draft-ietf-mmusic-msrp-usage-data-channel]
>>>>>>>
>>>>>>>
>>>>>>> (And this could also be extended for websockets if somebody 
>>>>>>> proposes a
>>>>>>> way to negotiate attributes for data channels too.)
>>>>>>>
>>>>>>> Using this format, if you want to know more than the name and the
>>>>>>> level(s) at which it can be used you need to consult the 
>>>>>>> references.
>>>>>>> And when there are multiple references you don't know which 
>>>>>>> one(s) you
>>>>>>> need to consult. This can be "fixed" by including more information
>>>>>>> from the reference into the registry. Conversely, we could strip it
>>>>>>> down further and remove the levels from the registry - so you 
>>>>>>> need to
>>>>>>> consult the references for that too.
>>>>>>>
>>>>>>> For instance, if we wanted to simplify finding the right 
>>>>>>> reference for
>>>>>>> the level you are interested in, we could do:
>>>>>>>
>>>>>>> *SDP Name*     *Level(s)*     *Reference(s)*
>>>>>>> accept-types
>>>>>>>     media,
>>>>>>> dcsa
>>>>>>>     [RFC4975]
>>>>>>> [draft-ietf-mmusic-msrp-usage-data-channel]
>>>>>>> cat
>>>>>>>     session
>>>>>>>     [RFC4566]
>>>>>>> fmtp
>>>>>>>     media,source     [RFC4566][RFC5576]
>>>>>>> mediaclk
>>>>>>>     session,media,source
>>>>>>>     [RFC7273]
>>>>>>> ptime
>>>>>>>     media
>>>>>>>     [RFC4566]
>>>>>>> recvonly
>>>>>>>     session,media,
>>>>>>> dcsa
>>>>>>>     [RFC4566][RFC4975]
>>>>>>> [draft-ietf-mmusic-msrp-usage-data-channel]
>>>>>>>
>>>>>>>
>>>>>>> Or we could go further, and break the dcsa level down by 
>>>>>>> subprotocol:
>>>>>>>
>>>>>>> *SDP Name*     *Level(s)*     *Reference(s)*
>>>>>>> accept-types
>>>>>>>     media,
>>>>>>> dcsa(MSRP)
>>>>>>>     [RFC4975]
>>>>>>> [draft-ietf-mmusic-msrp-usage-data-channel]
>>>>>>> cat
>>>>>>>     session
>>>>>>>     [RFC4566]
>>>>>>> fmtp
>>>>>>>     media,source     [RFC4566][RFC5576]
>>>>>>> mediaclk
>>>>>>>     session,media,source
>>>>>>>     [RFC7273]
>>>>>>> ptime
>>>>>>>     media
>>>>>>>     [RFC4566]
>>>>>>> recvonly
>>>>>>>     session,media,
>>>>>>> dcsa(MSRP)
>>>>>>>     [RFC4566][RFC4975]
>>>>>>> [draft-ietf-mmusic-msrp-usage-data-channel]
>>>>>>>
>>>>>>>
>>>>>>> Thoughts?
>>>>>>>
>>>>>>>     Thanks,
>>>>>>>     Paul
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> mmusic mailing list
>>>>>>> mmusic@ietf.org
>>>>>>> https://www.ietf.org/mailman/listinfo/mmusic
>>>>>>
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> mmusic mailing list
>>>>>> mmusic@ietf.org
>>>>>> https://www.ietf.org/mailman/listinfo/mmusic
>>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> mmusic mailing list
>>>>> mmusic@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/mmusic
>>>>>
>>>>
>>>> _______________________________________________
>>>> mmusic mailing list
>>>> mmusic@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/mmusic
>>>>
>>>
>>> _______________________________________________
>>> mmusic mailing list
>>> mmusic@ietf.org
>>> https://www.ietf.org/mailman/listinfo/mmusic
>>>
>>
>> .
>>
>
>