Re: [sipcore] Draft new version: draft-holmberg-sipcore-proxy-feature-03 (featuring the Feature-Caps header field)

Paul Kyzivat <pkyzivat@alum.mit.edu> Wed, 02 November 2011 15:29 UTC

Return-Path: <pkyzivat@alum.mit.edu>
X-Original-To: sipcore@ietfa.amsl.com
Delivered-To: sipcore@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 27AEE21F8997 for <sipcore@ietfa.amsl.com>; Wed, 2 Nov 2011 08:29:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.396
X-Spam-Level:
X-Spam-Status: No, score=-2.396 tagged_above=-999 required=5 tests=[AWL=0.203, BAYES_00=-2.599]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7xxkIfTqGw9D for <sipcore@ietfa.amsl.com>; Wed, 2 Nov 2011 08:29:36 -0700 (PDT)
Received: from qmta14.westchester.pa.mail.comcast.net (qmta14.westchester.pa.mail.comcast.net [76.96.59.212]) by ietfa.amsl.com (Postfix) with ESMTP id 695B721F8876 for <sipcore@ietf.org>; Wed, 2 Nov 2011 08:29:35 -0700 (PDT)
Received: from omta23.westchester.pa.mail.comcast.net ([76.96.62.74]) by qmta14.westchester.pa.mail.comcast.net with comcast id sEF51h0071c6gX85EFVcrF; Wed, 02 Nov 2011 15:29:36 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([24.62.109.41]) by omta23.westchester.pa.mail.comcast.net with comcast id sFVb1h01L0tdiYw3jFVcoA; Wed, 02 Nov 2011 15:29:36 +0000
Message-ID: <4EB161DD.6010307@alum.mit.edu>
Date: Wed, 02 Nov 2011 11:29:33 -0400
From: Paul Kyzivat <pkyzivat@alum.mit.edu>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1
MIME-Version: 1.0
To: Christer Holmberg <christer.holmberg@ericsson.com>
References: <4E8C785D.5080003@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A058522341F50A8@ESESSCMS0356.eemea.ericsson.se> <4EA03904.1010704@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852233D45FEB@ESESSCMS0356.eemea.ericsson.se> <4EA066EB.40701@alum.mit.edu> <8828E4D5-D8C1-4578-A9F4-87B363F0CEE6@acmepacket.com>, <4EA6C3DA.6000605@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852233C3B811@ESESSCMS0356.eemea.ericsson.se> <4EA75F61.8090409@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A0585223428CA5B@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A058522342DDA7E@ESESSCMS0356.eemea.ericsson.se> <E9573C46-FD9A-4E3D-BF77-8F25C64F9030@acmepacket.com> <6CB233EE-CBD0-4319-B46F-1483302263E0@cisco.com> <C6014970-2F88-4902-93D6-AECCBDE47872@acmepacket.com>, <4EAEDEDD.30202@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A05852235717398@ESESSCMS0356.eemea.ericsson.se>, <4EB02B97.5080008@alum.mit.edu> <7F2072F1E0DE894DA4B517B93C6A0585223571739B@ESESSCMS0356.eemea.ericsson.se>
In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A0585223571739B@ESESSCMS0356.eemea.ericsson.se>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Cc: "sipcore@ietf.org" <sipcore@ietf.org>
Subject: Re: [sipcore] Draft new version: draft-holmberg-sipcore-proxy-feature-03 (featuring the Feature-Caps header field)
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: SIP Core Working Group <sipcore.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sipcore>, <mailto:sipcore-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sipcore>
List-Post: <mailto:sipcore@ietf.org>
List-Help: <mailto:sipcore-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sipcore>, <mailto:sipcore-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 02 Nov 2011 15:29:37 -0000

[trimming]

On 11/1/11 4:45 PM, Christer Holmberg wrote:

>>> And, as you also indicated, we can specify what information a feature tag specification, and its associated IANA registration, needs to contain.
>>
>> If we use feature tags, unless we require use of the "sip" tree, or
>> define a new tree, I don't think we can specify what the specification
>> includes, since the registration is defined by RFC 2506.
>
> What is it then that is missing today? For example, alll the currently IANA registered g.3gpp feature tags DO contain a specification reference.

We can't easily (without ammending 2506) change what is required to 
register a feature tag. The document references are optional, and there 
is no required content for referenced documents.

I think its probably possible to craft the normative requirements for a 
new usage of feature-tags (i.e. in Feature-Caps) to restrict usage to 
feature tags that have a referenced document with some specific content.

What that wouldn't do is normatively prohibit the use of those new 
feature tags in other places, such as called out in 3840/3841. To do 
that we would have to revise 3840/3841.

	Thanks,
	Paul