Re: [sipcore] Establishing a "Priority" header field registry

Paul Kyzivat <pkyzivat@alum.mit.edu> Wed, 07 November 2012 00: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 6F0AA21F8B5C for <sipcore@ietfa.amsl.com>; Tue, 6 Nov 2012 16:29:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.437
X-Spam-Level:
X-Spam-Status: No, score=-0.437 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, RDNS_NONE=0.1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f4bSkSd5Kds2 for <sipcore@ietfa.amsl.com>; Tue, 6 Nov 2012 16:29:22 -0800 (PST)
Received: from qmta03.westchester.pa.mail.comcast.net (qmta03.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:32]) by ietfa.amsl.com (Postfix) with ESMTP id 983BA21F8B55 for <sipcore@ietf.org>; Tue, 6 Nov 2012 16:29:22 -0800 (PST)
Received: from omta23.westchester.pa.mail.comcast.net ([76.96.62.74]) by qmta03.westchester.pa.mail.comcast.net with comcast id LBtd1k00J1c6gX853QVTT5; Wed, 07 Nov 2012 00:29:27 +0000
Received: from Paul-Kyzivats-MacBook-Pro.local ([216.138.103.10]) by omta23.westchester.pa.mail.comcast.net with comcast id LQSP1k01F0DU8JY3jQSSHW; Wed, 07 Nov 2012 00:26:30 +0000
Message-ID: <5099AB45.5050708@alum.mit.edu>
Date: Tue, 06 Nov 2012 19:28:53 -0500
From: Paul Kyzivat <pkyzivat@alum.mit.edu>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:16.0) Gecko/20121010 Thunderbird/16.0.1
MIME-Version: 1.0
To: sipcore@ietf.org
References: <50993285.4020408@nostrum.com> <EDC0A1AE77C57744B664A310A0B23AE202D2F701CB@FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com>
In-Reply-To: <EDC0A1AE77C57744B664A310A0B23AE202D2F701CB@FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Subject: Re: [sipcore] Establishing a "Priority" header field registry
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, 07 Nov 2012 00:29:23 -0000

Aside from my disagreement regarding updating 3261 I agree with Keith below.

	Thanks,
	Paul

On 11/6/12 2:33 PM, DRAGE, Keith (Keith) wrote:
> I have reviewed the document and saw no issues with the current contents. It performs a useful function and should be proceeded with.
>
> As the document stands, I still see no reason why the document should update RFC 3261. It makes no normative changes within the scope of RFC 3261, which is to define the protocol between two entities.
>
> Part of this discussion may relate to whether one sees the creation and entry of material into IANA registries as being a normative action or not. I don't. To me they are just the housekeeping that has to be done.
>
> As regards the template (which other mails have suggested), we possibly do not need one.
>
> Part of this down to the level of review that is required; in the document this is set as IETF review. At this level, an RFC has to exist and go through IETF community review. There will be enough people around in this process to ensure that all the information that people need to see outside the IANA table actually exists. Conversely where we are allocating values on expert review, a template could be essential if only to ensure the expert doing the review has enough information available to perform the review; that information may well exceed the information that needs to appear in the template itself.
>
> Note that I did have a discussion with IANA on both these issues, and it would be wrong to say an opinion was expressed, Michelle seemed to be in alignment with these points.
>
> Regards
>
> Keith
>
>> -----Original Message-----
>> From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behalf
>> Of Adam Roach
>> Sent: 06 November 2012 15:54
>> To: sipcore@ietf.org; ecrit@ietf.org
>> Subject: [sipcore] Establishing a "Priority" header field registry
>>
>> [as an individual]
>>
>> The document draft-ietf-ecrit-psap-callback has identified a desire to
>> add a new value to the "Priority" header field for SIP. While RFC 3261
>> clearly intended the values in this header field to be extensible, it
>> did not define a registry of such values.
>>
>> To address this oversight, I have put together a small draft that
>> defines such a registry and populates it with the values defined by RFC
>> 3261. Because this is a correction to the core SIP specification, it is
>> my belief that it falls within the charter of the SIPCORE working group.
>>
>> The only real open issue, in my opinion, is the IANA registration policy
>> that should apply to new "Priority" header field values. To avoid
>> blocking any work in ECRIT, we need to move this work (or something
>> equivalent) forward very quickly. If you have any interest in the topic,
>> please review and comment with some urgency.
>>
>> http://www.ietf.org/id/draft-roach-sipcore-priority-00.txt
>>
>>
>> [The following request is being made in my WG chair role]
>> As this is a SIPCORE matter, please discuss it on the SIPCORE list
>> rather than the ECRIT list.
>>
>> Thanks!
>>
>> /a
>> _______________________________________________
>> sipcore mailing list
>> sipcore@ietf.org
>> https://www.ietf.org/mailman/listinfo/sipcore
> _______________________________________________
> sipcore mailing list
> sipcore@ietf.org
> https://www.ietf.org/mailman/listinfo/sipcore
>