Re: [sipcore] Proposal: Call for adoption & WGLC: draft-roach-sipcore-priority-00

Adam Roach <adam@nostrum.com> Tue, 13 November 2012 02:04 UTC

Return-Path: <adam@nostrum.com>
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 40EA721F8804 for <sipcore@ietfa.amsl.com>; Mon, 12 Nov 2012 18:04:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.98
X-Spam-Level:
X-Spam-Status: No, score=-101.98 tagged_above=-999 required=5 tests=[AWL=0.620, BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100]
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 RiHD7GtFXjTj for <sipcore@ietfa.amsl.com>; Mon, 12 Nov 2012 18:04:14 -0800 (PST)
Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 3627221F877F for <sipcore@ietf.org>; Mon, 12 Nov 2012 18:04:14 -0800 (PST)
Received: from Orochi.local (99-152-144-32.lightspeed.dllstx.sbcglobal.net [99.152.144.32]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id qAD249jQ001290 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Mon, 12 Nov 2012 20:04:09 -0600 (CST) (envelope-from adam@nostrum.com)
Message-ID: <50A1AA98.7080402@nostrum.com>
Date: Mon, 12 Nov 2012 20:04:08 -0600
From: Adam Roach <adam@nostrum.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:16.0) Gecko/20121026 Thunderbird/16.0.2
MIME-Version: 1.0
To: Dan Wing <dwing@cisco.com>
References: <50A160D8.8030602@alum.mit.edu> <05b001cdc13a$8a8f3f40$9fadbdc0$@cisco.com>
In-Reply-To: <05b001cdc13a$8a8f3f40$9fadbdc0$@cisco.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Received-SPF: pass (nostrum.com: 99.152.144.32 is authenticated by a trusted mechanism)
Cc: 'SIPCORE' <sipcore@ietf.org>, sipcore-ads@tools.ietf.org
Subject: Re: [sipcore] Proposal: Call for adoption & WGLC: draft-roach-sipcore-priority-00
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: Tue, 13 Nov 2012 02:04:15 -0000

[as an individual]

I would *really* like to keep protocol semantics out of the IANA 
registry. The referenced RFC (3261 in this case) is supposed to define 
the semantics for the Priority values.

In particular, there isn't any clear indication in RFC 3261 that 
Priority is supposed to be a strictly ordered set. If we want to go down 
the path of redefining semantics for parts of RFC 3261, then we're 
looking at a much, much larger effort than I envisioned for this document.

All I'm intending to do here is set up an IANA registry.

/a

On 11/12/12 19:02, Dan Wing wrote:
> Can something be said about the difference between "non-urgent"
> and "normal"?   I sort of get the feeling that non-urgent is
> intended to have a lower priority than "normal" (just based on
> the ordering), but that is not clear.  Just saying "have the
> priority in the listed order" would help.
>
> -d
>
>> -----Original Message-----
>> From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On
>> Behalf Of Paul Kyzivat
>> Sent: Monday, November 12, 2012 12:49 PM
>> To: SIPCORE; sipcore-ads@tools.ietf.org
>> Subject: [sipcore] Proposal: Call for adoption & WGLC: draft-roach-
>> sipcore-priority-00
>>
>> PLEASE RESPOND TO THIS MESSAGE
>>
>> This is a request to the sipcore wg to adopt the new individual draft
>> draft-roach-sipcore-priority-00, and a start of WGLC on that document,
>> to end on Sunday, November 25, 2012. (This is a trivial doc to review,
>> but people may be slow getting back to work after the meeting and there
>> is a holiday coming in the US, so I'm giving more time than I otherwise
>> would.)
>>
>> The reason for this is that the ecrit wg wants to define a new value for
>> the Priority header field. RFC 3261 defines that header field and an
>> initial set of values. It also mentions the possibility of extension.
>> But it failed to establish an IANA registry for that purpose, and didn't
>> otherwise define a process for extension.
>>
>> The intro to *this* document explains its purpose:
>>
>>      This document defines a new IANA registry to keep track of the
>> values
>>      defined for the Session Initiation Protocol (SIP) "Priority" header
>>      field.  This header field was defined in [RFC3261], section 20.26.
>>      It was clearly specified in a way that allows for the creation of
>> new
>>      values beyond those originally specified; however, no registry has
>>      been established for it.
>>
>> Once that is done, ecrit will be able to make their extension in accord
>> with the registration procedures that have been defined. The
>> registration policy is "IETF Review", so discussion of the merits of
>> that new value can be discussed as part of the review of *that*
>> document: draft-ietf-ecrit-psap-callback.
>>
>> REQUESTED ACTIONS:
>>
>> - indicate (ASAP) willingness, or not, for the sipcore wg to work on
>>     this problem, and adopt this draft as the basis for that work.
>>
>> - provide any comments you have on this document before the end of
>>     the WGLC period (Friday, November 25.)
>>
>> 	Thanks,
>> 	Paul
>> _______________________________________________
>> 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