Re: [MMUSIC] IANA registration of SDP attributes

Juergen Stoetzer-Bradler <juergen.stoetzer-bradler@nokia.com> Fri, 11 March 2016 16:16 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 653BD12D7AC for <mmusic@ietfa.amsl.com>; Fri, 11 Mar 2016 08:16:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.92
X-Spam-Level:
X-Spam-Status: No, score=-6.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c_BkFFIHXjWK for <mmusic@ietfa.amsl.com>; Fri, 11 Mar 2016 08:16:04 -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 8087E12D615 for <mmusic@ietf.org>; Fri, 11 Mar 2016 08:16:03 -0800 (PST)
Received: from fr712umx3.dmz.alcatel-lucent.com (unknown [135.245.210.42]) by Websense Email Security Gateway with ESMTPS id 888E133782C91 for <mmusic@ietf.org>; Fri, 11 Mar 2016 16:15:58 +0000 (GMT)
Received: from fr711usmtp1.zeu.alcatel-lucent.com (fr711usmtp1.zeu.alcatel-lucent.com [135.239.2.122]) by fr712umx3.dmz.alcatel-lucent.com (GMO-o) with ESMTP id u2BGG1a6003624 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for <mmusic@ietf.org>; Fri, 11 Mar 2016 16:16:01 GMT
Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id u2BGFwmG025183 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for <mmusic@ietf.org>; Fri, 11 Mar 2016 17:16:01 +0100
Received: from [135.224.202.37] (135.239.27.39) by FR711WXCHHUB01.zeu.alcatel-lucent.com (135.239.2.111) with Microsoft SMTP Server (TLS) id 14.3.195.1; Fri, 11 Mar 2016 17:15:47 +0100
To: <mmusic@ietf.org>
References: <56E1C193.1050308@alum.mit.edu>
From: Juergen Stoetzer-Bradler <juergen.stoetzer-bradler@nokia.com>
Message-ID: <56E2EF31.2020808@alcatel-lucent.com>
Date: Fri, 11 Mar 2016 17:15:45 +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: <56E1C193.1050308@alum.mit.edu>
Content-Type: multipart/alternative; boundary="------------020003050002070609090903"
X-Originating-IP: [135.239.27.39]
Archived-At: <http://mailarchive.ietf.org/arch/msg/mmusic/fCPI0C08lk6hpEVZ0wCWzbmXmGI>
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: Fri, 11 Mar 2016 16:16:08 -0000

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.

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