Re: [MMUSIC] IANA registration of SDP attributes
Paul Kyzivat <pkyzivat@alum.mit.edu> Wed, 23 March 2016 21:59 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 E652212D506 for <mmusic@ietfa.amsl.com>; Wed, 23 Mar 2016 14:59:41 -0700 (PDT)
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 vOx0XhDk4vfO for <mmusic@ietfa.amsl.com>; Wed, 23 Mar 2016 14:59:40 -0700 (PDT)
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 7613712D188 for <mmusic@ietf.org>; Wed, 23 Mar 2016 14:59:40 -0700 (PDT)
Received: from resomta-ch2-15v.sys.comcast.net ([69.252.207.111]) by comcast with SMTP id iqoValszqMjYpiqoVaLKMm; Wed, 23 Mar 2016 21:59:39 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1458770379; bh=btb50X74qX7vHuqFLmyRYewPSpwY1n5UX/I5GoSNyFQ=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=HLEY8FPCDsOZTpqH1357DW9rdo2KvMr80Zg5FYz6obtb9NhrgO9j6cl7QKiVMbNYL l3ss3OmQKvY1LzzkN39bH1eU3J0oJi2P11vZ913dQ4ryeqS/JC7GXXrBUcA75qhYIA 0ic4T6aMnze4U508DS4riT8KkMA++6o64GmZukdEjdVHVNwYcb+29/15Bc85ZM+P5u jHNS2YdCqcmI5wTxCp5L33sRjsax9h3sHVbkW3SHLlbs21BCKvnD14pUirtm+uo4cO jTWHKuvjv66luN+bp1c/ldNN9PVZxNqAQbCg8tICzbYiHORQ6Z1zXln1+WHizUdMo1 FKDN98l/ruiHg==
Received: from Paul-Kyzivats-MacBook-Pro.local ([73.218.51.154]) by resomta-ch2-15v.sys.comcast.net with comcast id ZZze1s00R3KdFy101Zzesu; Wed, 23 Mar 2016 21:59:39 +0000
To: mmusic@ietf.org
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: Paul Kyzivat <pkyzivat@alum.mit.edu>
Message-ID: <56F311CA.4090606@alum.mit.edu>
Date: Wed, 23 Mar 2016 17:59:38 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.7.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
Archived-At: <http://mailarchive.ietf.org/arch/msg/mmusic/rBDgQYBEhzVwnMMoLK7UzTX_Oko>
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: Wed, 23 Mar 2016 21:59:42 -0000
On 3/22/16 3:11 PM, Flemming Andreasen wrote: > Do we have a volunteer to drive the discussion there ? OK. I'll volunteer. The starting point for this discussion is the current text of section 8.2.4 of rfc4566bis-16. Looking at that, one thing leaps out at me: There is a long list of "stuff" that must be provided when defining a new attribute. IMO it is all *good* stuff, that should be provided. But it also strikes me that it will be difficult for IANA to evaluate the adequacy of this stuff itself. So we might want to require an expert review as a gate to registration. The other thing, that this thread has been discussing, is that this only covers definitions of new attributes. What it doesn't cover are *new* usages of existing attributes. What isn't covered are cases that *revise* the definition of an existing attribute. For instance, the IANA registry entries for the 'setup' and 'connection' attributes only reference RFC4145. (For use with TCP.) But these attributes are also used in contexts (with proto values) not covered by that RFC. For instance, RFC4572 defines a new proto TCP/TLS, and reuses 'setup' and 'connection'. The semantics are mostly the same, but additional behavior triggered by these is added on. Perhaps the registry entries for these attributes should also reference this RFC. In principle, in cases where it matters this behavior can be discovered by looking up the references for the TCP/TLS proto. But if you are particularly interested in what the setup attribute is doing then it might not occur to you to look there. In that case, the relationship to the original definition is pretty clear, since it is still TLS over TCP. It is less clear when used with a protocol entirely distinct from TCP. For instance we have active drafts draft-ietf-mmusic-sctp-sdp and draft-ietf-mmusic-dtls-sdp. These both reuse 'setup', and sctp-sdp reuses 'connection', while dtls-sdp has chosen an alternative to 'connection'. They also layer on additional behavior. And dtls-sdp also forbids use of some of the values defined in 4145 for setup. IMO it would be good if the registry for 'setup' referenced all of these, and that for 'connection' referenced these with the exception of dtls-sdp that doesn't use it. This is because these are extending the semantics of the attributes. But it seems less critical as long as these other documents are otherwise discoverable from actual uses. (Such as checking the references for the proto value in the m-line associated with these uses.) But IMO it would be essential if the syntax of the attribute is revised. As you can see, I am a bit ambivalent on this. That is why I think it needs discussion. Thanks, Paul
- [MMUSIC] IANA registration of SDP attributes Paul Kyzivat
- Re: [MMUSIC] IANA registration of SDP attributes Juergen Stoetzer-Bradler
- Re: [MMUSIC] IANA registration of SDP attributes Paul Kyzivat
- Re: [MMUSIC] IANA registration of SDP attributes Christian Groves
- Re: [MMUSIC] IANA registration of SDP attributes Paul Kyzivat
- Re: [MMUSIC] IANA registration of SDP attributes Christian Groves
- Re: [MMUSIC] IANA registration of SDP attributes Paul Kyzivat
- Re: [MMUSIC] IANA registration of SDP attributes Flemming Andreasen
- Re: [MMUSIC] IANA registration of SDP attributes Christian Groves
- Re: [MMUSIC] IANA registration of SDP attributes Paul Kyzivat
- Re: [MMUSIC] IANA registration of SDP attributes Christian Groves
- Re: [MMUSIC] IANA registration of SDP attributes Paul Kyzivat
- Re: [MMUSIC] IANA registration of SDP attributes Flemming Andreasen
- Re: [MMUSIC] IANA registration of SDP attributes Flemming Andreasen
- Re: [MMUSIC] IANA registration of SDP attributes Flemming Andreasen