[MMUSIC] IANA registration of SDP attributes

Paul Kyzivat <pkyzivat@alum.mit.edu> Thu, 10 March 2016 18:48 UTC

Return-Path: <prvs=68779ba63f=pkyzivat@alum.mit.edu>
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 0F2B112DB66 for <mmusic@ietfa.amsl.com>; Thu, 10 Mar 2016 10:48:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level:
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, 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 784uMFdsNzzz for <mmusic@ietfa.amsl.com>; Thu, 10 Mar 2016 10:48:56 -0800 (PST)
Received: from alum-mailsec-scanner-7.mit.edu (alum-mailsec-scanner-7.mit.edu [18.7.68.19]) by ietfa.amsl.com (Postfix) with ESMTP id C84A712DB46 for <mmusic@ietf.org>; Thu, 10 Mar 2016 10:48:55 -0800 (PST)
X-AuditID: 12074413-f03ff7000000516b-c9-56e1c19678bd
Received: from outgoing-alum.mit.edu (OUTGOING-ALUM.MIT.EDU [18.7.68.33]) by (Symantec Messaging Gateway) with SMTP id 1C.B2.20843.691C1E65; Thu, 10 Mar 2016 13:48:54 -0500 (EST)
Received: from Paul-Kyzivats-MacBook-Pro.local (c-73-218-51-154.hsd1.ma.comcast.net [73.218.51.154]) (authenticated bits=0) (User authenticated as pkyzivat@ALUM.MIT.EDU) by outgoing-alum.mit.edu (8.13.8/8.12.4) with ESMTP id u2AImq0c024091 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT) for <mmusic@ietf.org>; Thu, 10 Mar 2016 13:48:54 -0500
From: Paul Kyzivat <pkyzivat@alum.mit.edu>
To: IETF MMUSIC WG <mmusic@ietf.org>
Message-ID: <56E1C193.1050308@alum.mit.edu>
Date: Thu, 10 Mar 2016 13:48:51 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.6.0
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="------------040303050607000000050509"
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrKIsWRmVeSWpSXmKPExsUixO6iqDvt4MMwg4uf9S2mLn/M4sDosWTJ T6YAxihum6TEkrLgzPQ8fbsE7ozWuQcYC+7kVjSsPMrWwDjNu4uRk0NCwETizYVfLF2MXBxC AlsZJVb+/sQG4fxmkpj0fTkbSBWbgJbEnEP/WUBsEQEViX/vHoDFhQV0JO7O+MrcxcjBwSug LbHxJA9ImEVAVeJx+0cmEFtUIE1iVt8EsFZeAUGJkzOfgNnMAmES7TubGScwcs9CkpqFJAVh m0nM2/yQGcKWl9j+dg6QzQFkq0ksa1WCCTdvnc28gJFtFaNcYk5prm5uYmZOcWqybnFyYl5e apGuuV5uZoleakrpJkZIkAnvYNx1Uu4QowAHoxIPr0DNgzAh1sSy4srcQ4ySHExKorxr9j8M E+JLyk+pzEgszogvKs1JLT7EKMHBrCTC678WKMebklhZlVqUD5OS5mBREudVW6LuJySQnliS mp2aWpBaBJOV4eBQkuCddwCoUbAoNT21Ii0zpwQhzcTBCTKcS0qkODUvJbUosbQkIx4Ud/HF wMgDSfEA7a0GaectLkjMBYpCtJ5iVJQS5y0HSQiAJDJK8+DGwlLHK0ZxoC+FeXtAqniAaQeu +xXQYCagwS9a74EMLklESEk1MBo0pSmtuDlJ9HiCY7+0Xeu+abdaWE6YS3xez/5I+xavwkGJ uQqV11ZPfc8v+Gd/68X3D1ex8C51zp3aFyrPxf5mwUODknw2+7M7VVYdrZHfoBp/eaLEP5dv tYff/n5Vs/T12wXdvOde/r68wviZ2rpW9b0Lrn7NnTxHzrzh5t/I+p/K3ctvcsxWYinOSDTU Yi4qTgQAtdMFofgCAAA=
Archived-At: <http://mailarchive.ietf.org/arch/msg/mmusic/m1cLR0BsgLNyEneoO5QZfdO1Fpc>
Subject: [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: Thu, 10 Mar 2016 18:48:58 -0000

[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