Re: [MMUSIC] IANA registration of SDP attributes

Paul Kyzivat <pkyzivat@alum.mit.edu> Fri, 11 March 2016 16:46 UTC

Return-Path: <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 99CC912D95C for <mmusic@ietfa.amsl.com>; Fri, 11 Mar 2016 08:46:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.935
X-Spam-Level:
X-Spam-Status: No, score=-1.935 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcast.net
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 JQVKdFOSQk45 for <mmusic@ietfa.amsl.com>; Fri, 11 Mar 2016 08:46:57 -0800 (PST)
Received: from resqmta-ch2-01v.sys.comcast.net (resqmta-ch2-01v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:33]) (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 481A512D94F for <mmusic@ietf.org>; Fri, 11 Mar 2016 08:46:55 -0800 (PST)
Received: from resomta-ch2-05v.sys.comcast.net ([69.252.207.101]) by comcast with SMTP id eQC5avHXfBGW6eQDGall2v; Fri, 11 Mar 2016 16:46:54 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1457714814; bh=OdC9RuGnpvTQzEtbcq5YYrTUyMm8dBeORhDsg7qGCao=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=hITf6Jl8KRM2FkapbtztYW72ufSsjizpFBRompN/1Ra3qsnc50uOegR3XC914bn2G NdaJ9nxE/LO6Py9k0DE76Z27HyhXu++kXqnlKc+SLNddtzGmV88HrVGM1rHeounKzq hFdn50tnSN3W5e7fQZ+03yrG11FCxKNCK554odaZg0BzhoHvJobThz+JQT5kQIP480 APooiw3mMbzPWLw0Ln84kiaQQy2PQIxTg6M44Xpo8RPbQFMg7tnQN9tbg5QfOmvCd9 nT9TyGirwEcCqmVK68i1IfpKBys0XiNyGurS1sYUVRnbv9173wGNvwjyxpx3hMHpSM A8p/UBthI2HCw==
Received: from Paul-Kyzivats-MacBook-Pro.local ([73.218.51.154]) by resomta-ch2-05v.sys.comcast.net with comcast id Ugmu1s0053KdFy101gmuns; Fri, 11 Mar 2016 16:46:54 +0000
To: mmusic@ietf.org
References: <56E1C193.1050308@alum.mit.edu> <56E2EF31.2020808@alcatel-lucent.com>
From: Paul Kyzivat <pkyzivat@alum.mit.edu>
Message-ID: <56E2F67D.7060005@alum.mit.edu>
Date: Fri, 11 Mar 2016 11:46:53 -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
In-Reply-To: <56E2EF31.2020808@alcatel-lucent.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/mmusic/luTWnDJshgrEhFF_BYpv_SO78c0>
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:46:59 -0000

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
>