From rjsparks@nostrum.com Sun Nov 4 09:28:46 2012 Return-Path: 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 F3B4D21F8755 for ; Sun, 4 Nov 2012 09:28:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 jSCQsNiHsGZa for ; Sun, 4 Nov 2012 09:28:45 -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 2C43921F8724 for ; Sun, 4 Nov 2012 09:28:44 -0800 (PST) Received: from dhcp-603d.meeting.ietf.org (dhcp-603d.meeting.ietf.org [130.129.96.61]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id qA4HShj8027543 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Sun, 4 Nov 2012 11:28:43 -0600 (CST) (envelope-from rjsparks@nostrum.com) Message-ID: <5096A5CC.5020307@nostrum.com> Date: Sun, 04 Nov 2012 12:28:44 -0500 From: Robert Sparks 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: <20120726164109.2A538621A1@rfc-editor.org> In-Reply-To: <20120726164109.2A538621A1@rfc-editor.org> X-Forwarded-Message-Id: <20120726164109.2A538621A1@rfc-editor.org> Content-Type: multipart/mixed; boundary="------------050102040907050107020604" Received-SPF: pass (nostrum.com: 130.129.96.61 is authenticated by a trusted mechanism) Subject: [sipcore] Fwd: [Technical Errata Reported] RFC3665 (3295) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Nov 2012 17:28:46 -0000 This is a multi-part message in MIME format. --------------050102040907050107020604 Content-Type: multipart/alternative; boundary="------------010303040906010904080506" --------------010303040906010904080506 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit I am planning to approve this errata. Does anyone think that's the wrong thing to do? RjS -------- Original Message -------- Subject: [Technical Errata Reported] RFC3665 (3295) Date: Thu, 26 Jul 2012 09:41:09 -0700 (PDT) From: RFC Errata System To: alan.johnston@mci.com, sdonovan@dynamicsoft.com, rsparks@dynamicsoft.com, ccunningham@dynamicsoft.com, kevin.summers@sonusnet.com, gonzalo.camarillo@ericsson.com, rjsparks@nostrum.com, gonzalo.camarillo@ericsson.com, mary.ietf.barnes@gmail.com CC: dwaiting@gmail.com, sipping@ietf.org, rfc-editor@rfc-editor.org The following errata report has been submitted for RFC3665, "Session Initiation Protocol (SIP) Basic Call Flow Examples". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=3665&eid=3295 -------------------------------------- Type: Technical Reported by: David Waiting Section: 3.8. Original Text ------------- F18 ACK Proxy 1 -> Proxy 2 ACK sip:bob@biloxi.example.com SIP/2.0 Via: SIP/2.0/UDP ss2.biloxi.example.com:5060;branch=z9hG4bK721e4.1 Max-Forwards: 70 From: Alice ;tag=9fxced76sl To: Bob ;tag=314159 Call-ID: 2xTb9vxSit55XU7p8@atlanta.example.com CSeq: 1 ACK Content-Length: 0 Corrected Text -------------- F18 ACK Proxy 1 -> Proxy 2 ACK sip:bob@biloxi.example.com SIP/2.0 Via: SIP/2.0/UDP ss1.atlanta.example.com:5060;branch=z9hG4bK2d4790.1 Max-Forwards: 70 From: Alice ;tag=9fxced76sl To: Bob ;tag=314159 Call-ID: 2xTb9vxSit55XU7p8@atlanta.example.com CSeq: 1 ACK Content-Length: 0 Notes ----- Proxy 1 includes an incorrect Via header in the ACK. Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC3665 (draft-ietf-sipping-basic-call-flows-02) -------------------------------------- Title : Session Initiation Protocol (SIP) Basic Call Flow Examples Publication Date : December 2003 Author(s) : A. Johnston, S. Donovan, R. Sparks, C. Cunningham, K. Summers Category : BEST CURRENT PRACTICE Source : Session Initiation Proposal Investigation Area : Real-time Applications and Infrastructure Stream : IETF Verifying Party : IESG --------------010303040906010904080506 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit I am planning to approve this errata. Does anyone think that's the wrong thing to do?

RjS


-------- Original Message --------
Subject: [Technical Errata Reported] RFC3665 (3295)
Date: Thu, 26 Jul 2012 09:41:09 -0700 (PDT)
From: RFC Errata System <rfc-editor@rfc-editor.org>
To: alan.johnston@mci.com, sdonovan@dynamicsoft.com, rsparks@dynamicsoft.com, ccunningham@dynamicsoft.com, kevin.summers@sonusnet.com, gonzalo.camarillo@ericsson.com, rjsparks@nostrum.com, gonzalo.camarillo@ericsson.com, mary.ietf.barnes@gmail.com
CC: dwaiting@gmail.com, sipping@ietf.org, rfc-editor@rfc-editor.org 


The following errata report has been submitted for RFC3665,
"Session Initiation Protocol (SIP) Basic Call Flow Examples".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=3665&eid=3295

--------------------------------------
Type: Technical
Reported by: David Waiting <dwaiting@gmail.com>

Section: 3.8.

Original Text
-------------
F18 ACK Proxy 1 -> Proxy 2

ACK sip:bob@biloxi.example.com SIP/2.0
Via: SIP/2.0/UDP ss2.biloxi.example.com:5060;branch=z9hG4bK721e4.1
Max-Forwards: 70
From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl
To: Bob <sip:bob@biloxi.example.com>;tag=314159
Call-ID: 2xTb9vxSit55XU7p8@atlanta.example.com
CSeq: 1 ACK
Content-Length: 0

Corrected Text
--------------
F18 ACK Proxy 1 -> Proxy 2

ACK sip:bob@biloxi.example.com SIP/2.0
Via: SIP/2.0/UDP ss1.atlanta.example.com:5060;branch=z9hG4bK2d4790.1
Max-Forwards: 70
From: Alice <sip:alice@atlanta.example.com>;tag=9fxced76sl
To: Bob <sip:bob@biloxi.example.com>;tag=314159
Call-ID: 2xTb9vxSit55XU7p8@atlanta.example.com
CSeq: 1 ACK
Content-Length: 0

Notes
-----
Proxy 1 includes an incorrect Via header in the ACK.

Instructions:
-------------
This errata is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party (IESG)
can log in to change the status and edit the report, if necessary. 

--------------------------------------
RFC3665 (draft-ietf-sipping-basic-call-flows-02)
--------------------------------------
Title               : Session Initiation Protocol (SIP) Basic Call Flow Examples
Publication Date    : December 2003
Author(s)           : A. Johnston, S. Donovan, R. Sparks, C. Cunningham, K. Summers
Category            : BEST CURRENT PRACTICE
Source              : Session Initiation Proposal Investigation
Area                : Real-time Applications and Infrastructure
Stream              : IETF
Verifying Party     : IESG



--------------010303040906010904080506-- --------------050102040907050107020604 Content-Type: text/plain; charset=UTF-8; x-mac-type="0"; x-mac-creator="0"; name="Attached Message Part" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="Attached Message Part" --------------050102040907050107020604-- From internet-drafts@ietf.org Tue Nov 6 02:26:29 2012 Return-Path: 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 BF98B21F8862; Tue, 6 Nov 2012 02:26:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.558 X-Spam-Level: X-Spam-Status: No, score=-102.558 tagged_above=-999 required=5 tests=[AWL=0.041, BAYES_00=-2.599, 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 BGKmBfVPhLA5; Tue, 6 Nov 2012 02:26:23 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 673AC21F892E; Tue, 6 Nov 2012 02:26:23 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.35 Message-ID: <20121106102623.32615.27820.idtracker@ietfa.amsl.com> Date: Tue, 06 Nov 2012 02:26:23 -0800 Cc: sipcore@ietf.org Subject: [sipcore] I-D Action: draft-ietf-sipcore-sip-websocket-06.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Nov 2012 10:26:29 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Session Initiation Protocol Core Working = Group of the IETF. Title : The WebSocket Protocol as a Transport for the Session In= itiation Protocol (SIP) Author(s) : Inaki Baz Castillo Jose Luis Millan Villegas Victor Pascual Filename : draft-ietf-sipcore-sip-websocket-06.txt Pages : 21 Date : 2012-11-06 Abstract: The WebSocket protocol enables two-way realtime communication between clients and servers. This document specifies a new WebSocket sub- protocol as a reliable transport mechanism between SIP (Session Initiation Protocol) entities to enable usage of SIP in new scenarios. This document normatively updates RFC 3261. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-sipcore-sip-websocket There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-sipcore-sip-websocket-06 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sipcore-sip-websocket-06 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From ibc@aliax.net Tue Nov 6 02:35:49 2012 Return-Path: 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 474FE21F8661 for ; Tue, 6 Nov 2012 02:35:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-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 EgJa8GK1dwvC for ; Tue, 6 Nov 2012 02:35:48 -0800 (PST) Received: from mail-la0-f44.google.com (mail-la0-f44.google.com [209.85.215.44]) by ietfa.amsl.com (Postfix) with ESMTP id 6C77421F865C for ; Tue, 6 Nov 2012 02:35:48 -0800 (PST) Received: by mail-la0-f44.google.com with SMTP id b11so245675lam.31 for ; Tue, 06 Nov 2012 02:35:47 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type:content-transfer-encoding:x-gm-message-state; bh=fGLs3T1yyew1bxo1ifKQC4xklZrOUrU1nDRk5MSFaMA=; b=hzgrS3rRp2Rc1Msj7y4DyWoxPD8r3ppO3sHEkQUJP4IAuN6zS6XcDEIFmNrRffjOXf HQA0T9jkxiis3VzBDSL9tHI5Bst/2MqTUXeC/AaO1DcUyKBJUtnXTzflCaEnYSS2RRUE 6GYATXiX1lIFawdoqqOKL3kFmQgT9SZqyu1e1wLEyKiHpCg67xbfePgssxAC07ApUMNN z6K7a3Ee0LheexGEQ2quP2JeA6VeW24aE9ej2zbp4nXYaFvx3QxnxeDagJuYPegbPTKk EiKLKYMyS00weVqoulBsnqzBtBtvKCFtGfni1JMQpXwobMOTY0SHHpGk08sKr4k8Z8PP /YvQ== Received: by 10.152.135.41 with SMTP id pp9mr640600lab.7.1352198147117; Tue, 06 Nov 2012 02:35:47 -0800 (PST) MIME-Version: 1.0 Received: by 10.114.2.71 with HTTP; Tue, 6 Nov 2012 02:35:26 -0800 (PST) In-Reply-To: <20121106102623.32615.27820.idtracker@ietfa.amsl.com> References: <20121106102623.32615.27820.idtracker@ietfa.amsl.com> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Tue, 6 Nov 2012 11:35:26 +0100 Message-ID: To: "SIPCORE (Session Initiation Protocol Core) WG" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQlSIygnObwP3pGKX8uMc3pOK2qRoFJrHUbTccfciTGobZ5CsdTD7jRAhmXz/dJ1bCgg219l Subject: Re: [sipcore] I-D Action: draft-ietf-sipcore-sip-websocket-06.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Nov 2012 10:35:49 -0000 2012/11/6 : > > A New Internet-Draft is available from the on-line Internet-Drafts direct= ories. > This draft is a work item of the Session Initiation Protocol Core Workin= g Group of the IETF. > > Title : The WebSocket Protocol as a Transport for the S= ession Initiation Protocol (SIP) > Author(s) : Inaki Baz Castillo > Jose Luis Millan Villegas > Victor Pascual > Filename : draft-ietf-sipcore-sip-websocket-06.txt > Pages : 21 > Date : 2012-11-06 > > Abstract: > The WebSocket protocol enables two-way realtime communication between > clients and servers. This document specifies a new WebSocket sub- > protocol as a reliable transport mechanism between SIP (Session > Initiation Protocol) entities to enable usage of SIP in new > scenarios. This document normatively updates RFC 3261. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-sipcore-sip-websocket > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-sipcore-sip-websocket-06 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-sipcore-sip-websocket-06 Hi all, Changes from version 05 are the following: - In section 10.2 the registry name "Registry for the SIP SRV Resource Record Services Field" has been renamed to "Registry for the Session Initiation Protocol (SIP) NAPTR Resource Record Services Field" (thanks to Paul). - Table in section 10.2 has been improved. Protocol value for Services Field "SIPS+D2W" is now "WS" instead of "WSS" (in the same way Protocol value for Services Field "SIPS+D2T" is "TCP" in RFC 3263 instead of "TLS", and Protocol value for "SIPS+D2S" is "SCTP" in RFC 4168 instead of "TLS-SCTP"). Thanks a lot. -- I=C3=B1aki Baz Castillo From adam@nostrum.com Tue Nov 6 07:53:51 2012 Return-Path: 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 3B7D821F89B5; Tue, 6 Nov 2012 07:53:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[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 E0Q7BlKJoV70; Tue, 6 Nov 2012 07:53:50 -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 14B3821F89A1; Tue, 6 Nov 2012 07:53:48 -0800 (PST) Received: from dhcp-5037.meeting.ietf.org (dhcp-5037.meeting.ietf.org [130.129.80.55]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id qA6FrfdN005493 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 6 Nov 2012 09:53:47 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <50993285.4020408@nostrum.com> Date: Tue, 06 Nov 2012 10:53:41 -0500 From: Adam Roach 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: sipcore@ietf.org, ecrit@ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 130.129.80.55 is authenticated by a trusted mechanism) Subject: [sipcore] Establishing a "Priority" header field registry X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: sipcore@ietf.org List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Nov 2012 15:53:51 -0000 [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 From christer.holmberg@ericsson.com Tue Nov 6 08:04:47 2012 Return-Path: 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 094E921F89E5 for ; Tue, 6 Nov 2012 08:04:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] 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 UPc6x0Xqcw1k for ; Tue, 6 Nov 2012 08:04:46 -0800 (PST) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id CDCC921F8957 for ; Tue, 6 Nov 2012 08:04:45 -0800 (PST) X-AuditID: c1b4fb30-b7f936d0000018b3-f5-5099351cd72b Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 13.18.06323.C1539905; Tue, 6 Nov 2012 17:04:44 +0100 (CET) Received: from ESESSHC007.ericsson.se (153.88.183.39) by esessmw0256.eemea.ericsson.se (153.88.115.96) with Microsoft SMTP Server (TLS) id 8.3.279.1; Tue, 6 Nov 2012 17:04:42 +0100 Received: from ESESSMB209.ericsson.se ([169.254.9.182]) by ESESSHC007.ericsson.se ([153.88.183.39]) with mapi id 14.02.0318.001; Tue, 6 Nov 2012 17:04:36 +0100 From: Christer Holmberg To: "'sipcore@ietf.org'" Thread-Topic: [sipcore] Establishing a "Priority" header field registry Thread-Index: AQHNvDbuuoM9Lt4nQ06Ax8MMY/UWz5fc+C+g Date: Tue, 6 Nov 2012 16:04:36 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B026914@ESESSMB209.ericsson.se> References: <50993285.4020408@nostrum.com> In-Reply-To: <50993285.4020408@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.18] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrHLMWRmVeSWpSXmKPExsUyM+Jvja6M6cwAg6fvDCy+/tjE5sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujKYpc9gKLvFW7Nmd3cA4kbuLkZNDQsBEYv2PH0wQtpjEhXvr 2boYuTiEBE4ySvy4vIwVwtnBKNGyrocJwlnMKPGuG6SMg4NNwEKi+582SLeIgLbEt2MrGUFs YQE3ibeztrBAxN0lvl2/xwphG0kcOf6WDcRmEVCRWP5lP1gNr4C3xIbTk8FsIQEtiWN314Jd xAk0c0PXJ3YQmxHouu+n1oDFmQXEJW49mQ91tYDEkj3nmSFsUYmXj/+xQtiKEh9f7WOEqNeR WLD7ExuErS2xbOFrZoi9ghInZz6B2qst0bJ4AvsERvFZSFbMQtI+C0n7LCTtCxhZVjGy5yZm 5qSXm29iBMbJwS2/DXYwbrovdohRmoNFSZxXT3W/v5BAemJJanZqakFqUXxRaU5q8SFGJg5O qQZGMZlZ17sleFgf6Ou+PJb/pc1EPNFOkHfZ/KrJj5017D3vr9JJ0d3wZSOv8YM3NgIrK3q2 qe2b8zEy+u4KEcGHez9yshgua8270ZNQ5sw/5VZZ4KmXh8PYIpm+CTKsOR/nz3Jjm/UNAT1J uxnTFn/2eGLJ8dFMtXt9u+8Hs7Ps3qubV3oxf+xXYinOSDTUYi4qTgQADmzfiWECAAA= 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Nov 2012 16:04:47 -0000 Hi, I support this work.=20 My only question on the draft is whether there should be a registration tem= plate, which is used when registering a value. Regards, Christer -----Original Message----- From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behalf = Of Adam Roach Sent: 6. marraskuuta 2012 17: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 defin= e a registry of such values. To address this oversight, I have put together a small draft that defines s= uch a registry and populates it with the values defined by RFC 3261. Becaus= e 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 th= at should apply to new "Priority" header field values. To avoid blocking an= y work in ECRIT, we need to move this work (or something equivalent) forward very quickly. If you have any interest in the topic, pl= ease 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 SIPC= ORE matter, please discuss it on the SIPCORE list rather than the ECRIT lis= t. Thanks! /a _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore From brian.rosen@neustar.biz Tue Nov 6 10:22:26 2012 Return-Path: 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 0F9D621F8A89; Tue, 6 Nov 2012 10:22:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.489 X-Spam-Level: X-Spam-Status: No, score=-5.489 tagged_above=-999 required=5 tests=[AWL=0.557, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, RCVD_IN_DNSWL_MED=-4] 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 lsQo0HZWixd8; Tue, 6 Nov 2012 10:22:25 -0800 (PST) Received: from neustar.com (keys.neustar.biz [156.154.17.104]) by ietfa.amsl.com (Postfix) with ESMTP id BE19A21F8A8A; Tue, 6 Nov 2012 10:22:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1352226460; x=1667576447; q=dns/txt; h=From:Date:Subject:Message-ID:Content-Language: Content-Type:Content-Transfer-Encoding; bh=oo1fyiTw+bfADwJEEqvW1 FANUAoI6xzRyFIvBc+KiVs=; b=dbRiUfG4Ylv1OQYuYhkiYehpfem90kqu3AAzd rdplDisIRJFNs/UomzrYhAyVsx+4UnLJc5hmhaHPG7keaL/pQ== Received: from ([10.31.13.228]) by stihiron1.va.neustar.com with ESMTP with TLS id J041124052.16362994; Tue, 06 Nov 2012 13:27:39 -0500 Received: from STNTEXCH01.cis.neustar.com ([fe80::31b6:4d09:2ada:e6c0]) by STNTEXCHHT01.cis.neustar.com ([::1]) with mapi; Tue, 6 Nov 2012 13:22:21 -0500 From: "Rosen, Brian" To: "sipcore@ietf.org" Date: Tue, 6 Nov 2012 13:22:19 -0500 Thread-Topic: [sipcore] Establishing a "Priority" header field registry Thread-Index: Ac28S6kxIv8b1cKGTcmMUjtYiz7Z8Q== Message-ID: <7D126AA8-CCA4-4D88-82FA-796ADC0FFEB0@neustar.biz> References: <50993285.4020408@nostrum.com> In-Reply-To: <50993285.4020408@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: TRPIsVikd83p4UwBx0GENA== Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "ecrit@ietf.org" 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Nov 2012 18:22:26 -0000 I support this work. I agree with Christer about a registration template. = While it is obvious what is requested, I think it's better to have it. I am happy with "IETF Review" as the management policy. Brian On Nov 6, 2012, at 10:53 AM, Adam Roach wrote: > [as an individual] >=20 > The document draft-ietf-ecrit-psap-callback has identified a desire to ad= d a new value to the "Priority" header field for SIP. While RFC 3261 clearl= y intended the values in this header field to be extensible, it did not def= ine a registry of such values. >=20 > 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. Beca= use this is a correction to the core SIP specification, it is my belief tha= t it falls within the charter of the SIPCORE working group. >=20 > 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) forw= ard very quickly. If you have any interest in the topic, please review and = comment with some urgency. >=20 > http://www.ietf.org/id/draft-roach-sipcore-priority-00.txt >=20 >=20 > [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. >=20 > Thanks! >=20 > /a > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From worley@shell01.TheWorld.com Tue Nov 6 10:42:04 2012 Return-Path: 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 355FA21F8A8A for ; Tue, 6 Nov 2012 10:42:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.552 X-Spam-Level: X-Spam-Status: No, score=-2.552 tagged_above=-999 required=5 tests=[AWL=0.428, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_SORBS_WEB=0.619] 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 H5AUl5j-HKk3 for ; Tue, 6 Nov 2012 10:42:03 -0800 (PST) Received: from TheWorld.com (pcls5.std.com [192.74.137.145]) by ietfa.amsl.com (Postfix) with ESMTP id 97FD921F8A5A for ; Tue, 6 Nov 2012 10:42:03 -0800 (PST) Received: from shell.TheWorld.com (root@shell01.theworld.com [192.74.137.71]) by TheWorld.com (8.14.5/8.14.5) with ESMTP id qA6IfYUm026028 for ; Tue, 6 Nov 2012 13:41:36 -0500 Received: from shell01.TheWorld.com (localhost.theworld.com [127.0.0.1]) by shell.TheWorld.com (8.13.6/8.12.8) with ESMTP id qA6IfYqQ458868 for ; Tue, 6 Nov 2012 13:41:34 -0500 (EST) Received: (from worley@localhost) by shell01.TheWorld.com (8.13.6/8.13.6/Submit) id qA6IfXpK458481; Tue, 6 Nov 2012 13:41:33 -0500 (EST) Date: Tue, 6 Nov 2012 13:41:33 -0500 (EST) Message-Id: <201211061841.qA6IfXpK458481@shell01.TheWorld.com> From: worley@ariadne.com (Dale R. Worley) Sender: worley@ariadne.com (Dale R. Worley) To: sipcore@ietf.org In-reply-to: (mary.ietf.barnes@gmail.com) Subject: Re: [sipcore] "Gaps" in call flows X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Nov 2012 18:42:04 -0000 > From: Mary Barnes > > [MB] The hi-entries are added in order of the message processing which MUST > be maintained per the requirements and per the definition of the index > (same for 4244). We could add a note in that definition that it is possible > in cases of gaps to have the same index but the chronological order must > still be maintained. [/MB] I may be misunderstanding you, but I think this is incorrect. In an ordinary case of parallel forking, a proxy sends the request labeled 1.2.3.1 before it sends the request labeled 1.2.3.2. But even if the response to 1.2.3.2 arrives before the response to 1.2.3.1, in the response to the incoming request (1.2.3), the hi-entries for 1.2.3.1.* will appear before the hi-entries for 1.2.3.2.*. Dale From dan-ietf@danyork.org Tue Nov 6 10:47:40 2012 Return-Path: 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 36A5D21F88B5 for ; Tue, 6 Nov 2012 10:47:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.998 X-Spam-Level: X-Spam-Status: No, score=-2.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_57=0.6, RCVD_IN_DNSWL_LOW=-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 R+GPavaPufQv for ; Tue, 6 Nov 2012 10:47:39 -0800 (PST) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id 3268F21F88A1 for ; Tue, 6 Nov 2012 10:47:39 -0800 (PST) Received: by mail-ie0-f172.google.com with SMTP id 9so1262461iec.31 for ; Tue, 06 Nov 2012 10:47:38 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to:x-mailer:x-gm-message-state; bh=raSmnxFDMfyUBWhNQK19J3IlItwW3O6VZBEq+rboOqo=; b=aWfBs0yOH2mqSqFRf82OS9WHVHHYPczu/zNUXyuhC+uP9+XwtpA4qU82xjinf2MpoX qJjpGDaPlWSBC/OQ3s6x7VAFQ/Avu0wbp7gN7rRwR9iURInZY3ZRuVqynoUplWugvh12 oInMjWZTgwe1zGNF6d76G7kndroQKpRY6u8lyiPKMl+nDkR0kRftlohyYeIYyg1cg4ro n7ahiPvpIbP39UlOLiWiC9gTJ5aju8QoGgMdBcQ7Eg/2aztt8bJNDvQJMmnICQhCKTBe Rldr8i6AUlqhKT1Aivco7b9xiY9gDuRQAzDISxwvjOFT/xCvpN9rJaJk5iEf7ampW00l HGqQ== Received: by 10.50.213.99 with SMTP id nr3mr2147732igc.16.1352227658751; Tue, 06 Nov 2012 10:47:38 -0800 (PST) Received: from [172.20.12.152] (cpe-74-75-92-114.maine.res.rr.com. [74.75.92.114]) by mx.google.com with ESMTPS id xn10sm8664156igb.4.2012.11.06.10.47.37 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 06 Nov 2012 10:47:38 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/alternative; boundary="Apple-Mail=_48FEB9C6-C36F-4BE2-9817-99C703EE2AB3" From: Dan York In-Reply-To: <7D126AA8-CCA4-4D88-82FA-796ADC0FFEB0@neustar.biz> Date: Tue, 6 Nov 2012 13:47:36 -0500 Message-Id: References: <50993285.4020408@nostrum.com> <7D126AA8-CCA4-4D88-82FA-796ADC0FFEB0@neustar.biz> To: "Rosen, Brian" X-Mailer: Apple Mail (2.1283) X-Gm-Message-State: ALoCoQmUWSBpBQvZ40v+0yqLpMvXOc/dzYmThs6G0eVMnFvmRpvh22DDjDmSlvTZeSC7IvUPLfH4 Cc: sipcore@ietf.org 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Nov 2012 18:47:40 -0000 --Apple-Mail=_48FEB9C6-C36F-4BE2-9817-99C703EE2AB3 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii +1 to Brian and Christer's comments and I support this work. This = seems a straightforward thing to do . Dan On Nov 6, 2012, at 1:22 PM, Rosen, Brian wrote: > I support this work. I agree with Christer about a registration = template. While it is obvious what is requested, I think it's better to = have it. >=20 > I am happy with "IETF Review" as the management policy. >=20 > Brian >=20 > On Nov 6, 2012, at 10:53 AM, Adam Roach wrote: >=20 >> [as an individual] >>=20 >> 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. >>=20 >> 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. >>=20 >> 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. >>=20 >> http://www.ietf.org/id/draft-roach-sipcore-priority-00.txt >>=20 >>=20 >> [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. >>=20 >> Thanks! >>=20 >> /a >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore --=20 Dan York dyork@lodestar2.com http://www.danyork.me/ skype:danyork Phone: +1-802-735-1624 Twitter - http://twitter.com/danyork --Apple-Mail=_48FEB9C6-C36F-4BE2-9817-99C703EE2AB3 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii +1 to = Brian and Christer's comments and I support this work.    This = seems a straightforward thing to do = .

Dan

On Nov 6, 2012, at 1:22 = PM, Rosen, Brian wrote:

I = support this work.  I agree with Christer about a registration = template.  While it is obvious what is requested, I think it's = better to have it.

I am happy with "IETF Review" as the = management policy.

Brian

On Nov 6, 2012, at 10:53 AM, Adam = Roach <adam@nostrum.com> = wrote:

[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
<= blockquote type=3D"cite">

[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.or= g/mailman/listinfo/sipcore

_______________________= ________________________
sipcore mailing list
sipcore@ietf.org
https://www.ietf.= org/mailman/listinfo/sipcore

-- 
Dan York  dyork@lodestar2.com
http://www.danyork.me/  &nb= sp;skype:danyork
Phone: = +1-802-735-1624
Twitter - http://twitter.com/danyork

= --Apple-Mail=_48FEB9C6-C36F-4BE2-9817-99C703EE2AB3-- From oej@edvina.net Tue Nov 6 10:50:51 2012 Return-Path: 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 674ED21F88B5 for ; Tue, 6 Nov 2012 10:50:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.149 X-Spam-Level: X-Spam-Status: No, score=-2.149 tagged_above=-999 required=5 tests=[AWL=-0.151, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_57=0.6] 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 NVCi4nQ6zwNz for ; Tue, 6 Nov 2012 10:50:49 -0800 (PST) Received: from smtp7.webway.se (smtp7.webway.se [IPv6:2a02:920:212e::205]) by ietfa.amsl.com (Postfix) with ESMTP id 9AB6421F8906 for ; Tue, 6 Nov 2012 10:50:47 -0800 (PST) Received: from [192.168.122.128] (unknown [63.149.124.133]) by smtp7.webway.se (Postfix) with ESMTPA id 0949C754A8A7; Tue, 6 Nov 2012 18:50:44 +0000 (UTC) Content-Type: multipart/alternative; boundary="Apple-Mail=_E9A9F33F-ADCD-416C-B301-E8AD94843912" Mime-Version: 1.0 (Mac OS X Mail 6.0 \(1486\)) From: "Olle E. Johansson" In-Reply-To: Date: Tue, 6 Nov 2012 19:50:38 +0100 Message-Id: <6071BDFC-6BCF-42EE-A3E8-93578F1FD27B@edvina.net> References: <50993285.4020408@nostrum.com> <7D126AA8-CCA4-4D88-82FA-796ADC0FFEB0@neustar.biz> To: Dan York X-Mailer: Apple Mail (2.1486) Cc: "Rosen, Brian" , sipcore@ietf.org 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Nov 2012 18:50:51 -0000 --Apple-Mail=_E9A9F33F-ADCD-416C-B301-E8AD94843912 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii 6 nov 2012 kl. 19:47 skrev Dan York : > +1 to Brian and Christer's comments and I support this work. This = seems a straightforward thing to do . Agree with this. /O >=20 > Dan >=20 > On Nov 6, 2012, at 1:22 PM, Rosen, Brian wrote: >=20 >> I support this work. I agree with Christer about a registration = template. While it is obvious what is requested, I think it's better to = have it. >>=20 >> I am happy with "IETF Review" as the management policy. >>=20 >> Brian >>=20 >> On Nov 6, 2012, at 10:53 AM, Adam Roach wrote: >>=20 >>> [as an individual] >>>=20 >>> 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. >>>=20 >>> 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. >>>=20 >>> 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. >>>=20 >>> http://www.ietf.org/id/draft-roach-sipcore-priority-00.txt >>>=20 >>>=20 >>> [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. >>>=20 >>> Thanks! >>>=20 >>> /a >>> _______________________________________________ >>> sipcore mailing list >>> sipcore@ietf.org >>> https://www.ietf.org/mailman/listinfo/sipcore >>=20 >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore >=20 > --=20 > Dan York dyork@lodestar2.com > http://www.danyork.me/ skype:danyork > Phone: +1-802-735-1624 > Twitter - http://twitter.com/danyork >=20 >=20 >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore --- * Olle E Johansson - oej@edvina.net * Cell phone +46 70 593 68 51, Office +46 8 96 40 20, Sweden --Apple-Mail=_E9A9F33F-ADCD-416C-B301-E8AD94843912 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii dan-ietf@danyork.org>:
+1 to Brian and Christer's = comments and I support this work.    This seems a = straightforward thing to do .
Agree with = this.

/O
I support = this work.  I agree with Christer about a registration template. =  While it is obvious what is requested, I think it's better to have = it.

I am happy with "IETF Review" as the management = policy.

Brian

On Nov 6, 2012, at 10:53 AM, Adam Roach = <adam@nostrum.com> = wrote:

[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
<= blockquote type=3D"cite">

[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.or= g/mailman/listinfo/sipcore

_______________________= ________________________
sipcore mailing list
sipcore@ietf.org
https://www.ietf.or= g/mailman/listinfo/sipcore

-- 
Dan York  dyork@lodestar2.com
http://www.danyork.me/  &nb= sp;skype:danyork
Phone: = +1-802-735-1624
Twitter - http://twitter.com/danyork
=
_______________________________________________
sipcore= mailing list
sipcore@ietf.org
https://www.ietf.= org/mailman/listinfo/sipcore

---
* Olle E = Johansson - oej@edvina.net
* Cell phone = +46 70 593 68 51, Office +46 8 96 40 20, Sweden



= --Apple-Mail=_E9A9F33F-ADCD-416C-B301-E8AD94843912-- From worley@shell01.TheWorld.com Tue Nov 6 10:51:09 2012 Return-Path: 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 10E6B21F8906 for ; Tue, 6 Nov 2012 10:51:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.659 X-Spam-Level: X-Spam-Status: No, score=-2.659 tagged_above=-999 required=5 tests=[AWL=0.321, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_SORBS_WEB=0.619] 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 OXYn4NRvMEDQ for ; Tue, 6 Nov 2012 10:51:08 -0800 (PST) Received: from TheWorld.com (pcls5.std.com [192.74.137.145]) by ietfa.amsl.com (Postfix) with ESMTP id 743D221F8AAF for ; Tue, 6 Nov 2012 10:51:08 -0800 (PST) Received: from shell.TheWorld.com (root@shell01.theworld.com [192.74.137.71]) by TheWorld.com (8.14.5/8.14.5) with ESMTP id qA6IoqbR013100 for ; Tue, 6 Nov 2012 13:50:54 -0500 Received: from shell01.TheWorld.com (localhost.theworld.com [127.0.0.1]) by shell.TheWorld.com (8.13.6/8.12.8) with ESMTP id qA6IoqGO459050 for ; Tue, 6 Nov 2012 13:50:52 -0500 (EST) Received: (from worley@localhost) by shell01.TheWorld.com (8.13.6/8.13.6/Submit) id qA6IoqSl459109; Tue, 6 Nov 2012 13:50:52 -0500 (EST) Date: Tue, 6 Nov 2012 13:50:52 -0500 (EST) Message-Id: <201211061850.qA6IoqSl459109@shell01.TheWorld.com> From: worley@ariadne.com (Dale R. Worley) Sender: worley@ariadne.com (Dale R. Worley) To: sipcore@ietf.org In-reply-to: <50896676.7050909@alum.mit.edu> (pkyzivat@alum.mit.edu) Subject: Re: [sipcore] WGLC for draft-ietf-sipcore-rfc4244bis-callflows-01 Section 3.11 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Nov 2012 18:51:09 -0000 > From: Paul Kyzivat > > If the response was small enough to reach the proxy, then it should be > small enough to reach the UAC. (It gets smaller with each hop due to > removal of Via header fields.) > > I guess this might not be true if link characteristics are different, or > if the first hop was UDP and the subsequent hops were TCP. If I remember correctly, the worry was that link characteristics of the last-hop were different from those of the "core" network. Either the last-hop was UDP and the core hops were TCP, or the last-hop link was much less reliable, leading to a desire to avoid packet fragmentation for fear of increasing the lost-packet rate unacceptably. > But if PDU size is a concern, why isn't it a concern on every hop? > Should there have been some dispensation that H-I can be pruned in > responses if necessary to reduce PDU size? > > One concern I had was if the first proxy is dialog-stateless. Then it > will have to go to extra work to remember that the H-I should not be > passed in the response. (Dale remineded me that a stateless proxy can do > this by putting a flag in its Via.) This wouldn't be such an issue if > returning the H-I in this case is optional. Dale From keith.drage@alcatel-lucent.com Tue Nov 6 11:33:53 2012 Return-Path: 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 5821021F8A17 for ; Tue, 6 Nov 2012 11:33:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.749 X-Spam-Level: X-Spam-Status: No, score=-109.749 tagged_above=-999 required=5 tests=[AWL=0.500, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8, 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 9PAbGMb6Woix for ; Tue, 6 Nov 2012 11:33:52 -0800 (PST) Received: from smail5.alcatel.fr (smail5.alcatel.fr [64.208.49.27]) by ietfa.amsl.com (Postfix) with ESMTP id 8676D21F8A14 for ; Tue, 6 Nov 2012 11:33:52 -0800 (PST) Received: from FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (FRMRSSXCHHUB01.dc-m.alcatel-lucent.com [135.120.45.61]) by smail5.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id qA6JXl1d018178 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Tue, 6 Nov 2012 20:33:51 +0100 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.46]) by FRMRSSXCHHUB01.dc-m.alcatel-lucent.com ([135.120.45.61]) with mapi; Tue, 6 Nov 2012 20:33:30 +0100 From: "DRAGE, Keith (Keith)" To: "sipcore@ietf.org" Date: Tue, 6 Nov 2012 20:33:29 +0100 Thread-Topic: [sipcore] Establishing a "Priority" header field registry Thread-Index: Ac28NvOrbUWItqiIRqSTYX5lc2XL1AAHC/Ag Message-ID: References: <50993285.4020408@nostrum.com> In-Reply-To: <50993285.4020408@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.13 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Nov 2012 19:33:53 -0000 I have reviewed the document and saw no issues with the current contents. I= t performs a useful function and should be proceeded with. As the document stands, I still see no reason why the document should updat= e RFC 3261. It makes no normative changes within the scope of RFC 3261, whi= ch is to define the protocol between two entities. Part of this discussion may relate to whether one sees the creation and ent= ry of material into IANA registries as being a normative action or not. I d= on'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 throu= gh IETF community review. There will be enough people around in this proces= s to ensure that all the information that people need to see outside the IA= NA table actually exists. Conversely where we are allocating values on expe= rt review, a template could be essential if only to ensure the expert doing= the review has enough information available to perform the review; that in= formation may well exceed the information that needs to appear in the templ= ate itself. Note that I did have a discussion with IANA on both these issues, and it wo= uld be wrong to say an opinion was expressed, Michelle seemed to be in alig= nment with these points. Regards Keith > -----Original Message----- > From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behal= f > Of Adam Roach > Sent: 06 November 2012 15:54 > To: sipcore@ietf.org; ecrit@ietf.org > Subject: [sipcore] Establishing a "Priority" header field registry >=20 > [as an individual] >=20 > 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. >=20 > 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. >=20 > 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. >=20 > http://www.ietf.org/id/draft-roach-sipcore-priority-00.txt >=20 >=20 > [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. >=20 > Thanks! >=20 > /a > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From radhika.r.roy.civ@mail.mil Tue Nov 6 12:12:52 2012 Return-Path: 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 223F521F8B13 for ; Tue, 6 Nov 2012 12:12:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.201 X-Spam-Level: X-Spam-Status: No, score=-2.201 tagged_above=-999 required=5 tests=[AWL=0.398, BAYES_00=-2.599] 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 aGvKtDx5L-N2 for ; Tue, 6 Nov 2012 12:12:47 -0800 (PST) Received: from edge-cols.mail.mil (edge-cols.mail.mil [131.64.100.9]) by ietfa.amsl.com (Postfix) with ESMTP id 0EB4621F8B0D for ; Tue, 6 Nov 2012 12:12:46 -0800 (PST) Received: from UCOLHP3A.easf.csd.disa.mil (131.64.100.148) by ucolhp2w.easf.csd.disa.mil (131.64.100.9) with Microsoft SMTP Server (TLS) id 14.2.309.2; Tue, 6 Nov 2012 20:12:37 +0000 Received: from UCOLHP9H.easf.csd.disa.mil ([169.254.5.171]) by UCOLHP3A.easf.csd.disa.mil ([131.64.100.148]) with mapi id 14.02.0309.003; Tue, 6 Nov 2012 20:12:36 +0000 From: "Roy, Radhika R CIV (US)" To: "DRAGE, Keith (Keith)" , "sipcore@ietf.org" Thread-Topic: [sipcore] Establishing a "Priority" header field registry Thread-Index: Ac28NvOrIv8b1cKGTcmMUjtYiz7Z8QAHC/AgAAGOMzA= Date: Tue, 6 Nov 2012 20:12:36 +0000 Message-ID: <8486C8728176924BAF5BDB2F7D7EEDDF48652767@ucolhp9h.easf.csd.disa.mil> References: <50993285.4020408@nostrum.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [131.64.62.4] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0068_01CDBC31.23455C60" MIME-Version: 1.0 X-Mailman-Approved-At: Tue, 06 Nov 2012 12:36:08 -0800 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Nov 2012 20:12:52 -0000 ------=_NextPart_000_0068_01CDBC31.23455C60 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Folks: I have another point to explain: +------------+-----------+ | Priority | Reference | +------------+-----------+ | non-urgent | RFC 3261 | | normal | RFC 3261 | | urgent | RFC 3261 | | emergency | RFC 3261 | +------------+-----------+ The definition of each value needs to be provided. It is not clear how one label will differ with all others. Also, come confusions arise with respect when priority labels are applied related to call, media, and others. RFCs 4411 and 4412, 5478, 6433, 6061, 5031, and 3689 need to be seen for some guidance before explaining the labels so that terminologies and definitions do not overlap or contradict. BR/Radhika -----Original Message----- From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behalf Of DRAGE, Keith (Keith) Sent: Tuesday, November 06, 2012 2:33 PM To: sipcore@ietf.org Subject: Re: [sipcore] Establishing a "Priority" header field registry 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 ------=_NextPart_000_0068_01CDBC31.23455C60 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIISizCCA3Aw ggJYoAMCAQICAQUwDQYJKoZIhvcNAQEFBQAwWzELMAkGA1UEBhMCVVMxGDAWBgNVBAoTD1UuUy4g R292ZXJubWVudDEMMAoGA1UECxMDRG9EMQwwCgYDVQQLEwNQS0kxFjAUBgNVBAMTDURvRCBSb290 IENBIDIwHhcNMDQxMjEzMTUwMDEwWhcNMjkxMjA1MTUwMDEwWjBbMQswCQYDVQQGEwJVUzEYMBYG A1UEChMPVS5TLiBHb3Zlcm5tZW50MQwwCgYDVQQLEwNEb0QxDDAKBgNVBAsTA1BLSTEWMBQGA1UE AxMNRG9EIFJvb3QgQ0EgMjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMAswfaNO6z/ PzzWcb64dCIH7HBBFfyrQOMHqsHD2J/+2kw6vz/I2Ch7SzYBwKxFJcPSDgqPhRhkED0aE3Aqb47X 3I2Ts0EPOCHNravCPSoF01cRNw3NjFH5k+PMRkkhjhS0zcsUPjjNcjHuqxLyZeo0LlZd/+5jdctt upE0/J7z9C0cvlDEQt9ZiP9qs/qobD3LVnFxBZa7n4DlgEVZZ0Gw68OtYKSAdQYXnA70Q+CZDhv7 f/WzzLKBgrH9MsG4vkGkZLVgOlpRMIzO3kEsGUdcSRBkuXSph0GvfW66wbihv2UxOgRn+bW7jpKK AGO4seaMOF+D/1DVO6Jda7IQzGMCAwEAAaM/MD0wHQYDVR0OBBYEFEl0uwxeunr+AlTve6DGlcYJ gHCWMAsGA1UdDwQEAwIBhjAPBgNVHRMBAf8EBTADAQH/MA0GCSqGSIb3DQEBBQUAA4IBAQCYkY0/ ici79cBpcyk7Nay6swh2PXAJkumERCEBfRR2G+5RbB2NFTctezFp9JpEuK9GzDT6I8sDJxnSgyF1 K+fgG5km3IRAleio0sz2WFxm7z9KlxCCHboKot1bBiudp2RO6y4BNaS0PxOtVeTVc6hpmxHxmPIx Hm9A1Ph4n46RoG9wBJBmqgYrzuF6krV94eDRluehOi3MsZ0fBUTth5nTTRpwOcEEDOV+2fGv1yAO 8SJ6JaRzmcw/pAcnlqiile2CuRbTnguHwsHyiPVi32jfx7xpUe2xXNxUVCkPCTmarAPB2wxNrm8K ehZJ8b+R0jiU0/aVLLdsyUK2jcqQjYXZMIIEtzCCA5+gAwIBAgIDHzzKMA0GCSqGSIb3DQEBBQUA MF0xCzAJBgNVBAYTAlVTMRgwFgYDVQQKEw9VLlMuIEdvdmVybm1lbnQxDDAKBgNVBAsTA0RvRDEM MAoGA1UECxMDUEtJMRgwFgYDVQQDEw9ET0QgRU1BSUwgQ0EtMjkwHhcNMTIwOTIwMDAwMDAwWhcN MTUwOTE5MjM1OTU5WjB5MQswCQYDVQQGEwJVUzEYMBYGA1UEChMPVS5TLiBHb3Zlcm5tZW50MQww CgYDVQQLEwNEb0QxDDAKBgNVBAsTA1BLSTEMMAoGA1UECxMDVVNBMSYwJAYDVQQDEx1ST1kuUkFE SElLQS5SQU5KQU4uMTI5MTkzOTgwMTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAKw9 ymde30NtacDt8neYCBWDyA+Hlsk3dNwV23IVgH7vSWJx4zCFT5ojDHACm3lthvOOtJ0CzkjwQy8V hEHvL0eK03hZy0hJrZxQSYcao7Y0Yv9yDAFvxa6LJ1fUImUj9edMf1l08LZkjh3ybs20Bk+MLySR 9F/flRzjtCwVUeqq8NS3to4nPXSIgViP6H0YJrBjf9IDZQGgcO8LxLbNENOWrXILeCCCngnHBgHV lJWak9YndpMOs+CeLXk5oUV8xUAM/UjyS+/gFCjABBRt30VJVN6pqARmIht850iK8TDeqlWwF3O9 eQBBwKQPJ7nVl0kmGItYGoYb+4t2Mkwalh8CAwEAAaOCAWIwggFeMB8GA1UdIwQYMBaAFLhDg2Qh eu5wgd6l3gxgKId4rl54MDoGA1UdHwQzMDEwL6AtoCuGKWh0dHA6Ly9jcmwuZGlzYS5taWwvY3Js L0RPREVNQUlMQ0FfMjkuY3JsMA4GA1UdDwEB/wQEAwIFIDAjBgNVHSAEHDAaMAsGCWCGSAFlAgEL CTALBglghkgBZQIBCxMwHQYDVR0OBBYEFGRWf703swy+9hvoDujsb+ZPwC9MMGgGCCsGAQUFBwEB BFwwWjA2BggrBgEFBQcwAoYqaHR0cDovL2NybC5kaXNhLm1pbC9zaWduL0RPREVNQUlMQ0FfMjku Y2VyMCAGCCsGAQUFBzABhhRodHRwOi8vb2NzcC5kaXNhLm1pbDAkBgNVHREEHTAbgRlyYWRoaWth LnIucm95QHVzLmFybXkubWlsMBsGA1UdCQQUMBIwEAYIKwYBBQUHCQQxBBMCVVMwDQYJKoZIhvcN AQEFBQADggEBAE9PU63Rc/bneYoxI6sAZi+oXBiwneOiI03+J3pSZWIbwrOnj7qGoH5ZoeO+dZ8E wvKszd+vacYnO8SqEXsvIKvBGPchKg1oV5b24+tCSeiCXtcX5EDtpJQGS4W9G+7r7f+mdEHU0NuF NI7HNHRY/q4C+FGhchPoKPcKeyWxJMwp+9NJQsx1AoC5isvydZHHlNkV917dLMuMEqyCCAAbJAOp 8SDQTiiIVa1I7NlMSlkzNRUtFoO9nsEttMH699V9JH5jcwWPlWdyb5B6yRzoM/iFsI/hA9pHHukh iWVul3FX/6Ez8Jt/A1j/CFsl3S2y2TBRCdqIQEP+/H6j4RFxa9MwggUCMIID6qADAgECAgMfPMkw DQYJKoZIhvcNAQEFBQAwXTELMAkGA1UEBhMCVVMxGDAWBgNVBAoTD1UuUy4gR292ZXJubWVudDEM MAoGA1UECxMDRG9EMQwwCgYDVQQLEwNQS0kxGDAWBgNVBAMTD0RPRCBFTUFJTCBDQS0yOTAeFw0x MjA5MjAwMDAwMDBaFw0xNTA5MTkyMzU5NTlaMHkxCzAJBgNVBAYTAlVTMRgwFgYDVQQKEw9VLlMu IEdvdmVybm1lbnQxDDAKBgNVBAsTA0RvRDEMMAoGA1UECxMDUEtJMQwwCgYDVQQLEwNVU0ExJjAk BgNVBAMTHVJPWS5SQURISUtBLlJBTkpBTi4xMjkxOTM5ODAxMIIBIjANBgkqhkiG9w0BAQEFAAOC AQ8AMIIBCgKCAQEAyr7Ttduf1mHx22erLvkwPOZL02imdiimrmXITVrdUHsynK383NY6a4ye07Jm b0spr8hzmfM6JSCEgtbZevWfJg4NmNDjEEe53+7EvEMRHfh46GGxOckj98QmQwngbQaAIcKI1gJd Do2vB3mOtFp5hNKqsxibZAvpPb3OsR762vrx2QYQX+p8+psLwe95CSt56IfC39GZD+Otus3Sq1Ma 9e0NdRhqg5ch8FYpL2ONbmEw9+DTqk24Zh2lQuOvpo4FhpvXnNghCS4CfuiE6YgvKdombc1BGT5u rkDFep5IH7Rk7EnK4CVVzNq3gxT0B+hDoJT0AuQfrkxI9223mUJoywIDAQABo4IBrTCCAakwHwYD VR0jBBgwFoAUuEODZCF67nCB3qXeDGAoh3iuXngwOgYDVR0fBDMwMTAvoC2gK4YpaHR0cDovL2Ny bC5kaXNhLm1pbC9jcmwvRE9ERU1BSUxDQV8yOS5jcmwwDgYDVR0PAQH/BAQDAgbAMCMGA1UdIAQc MBowCwYJYIZIAWUCAQsJMAsGCWCGSAFlAgELEzAdBgNVHQ4EFgQUrV8KnskfJHURS19In/mX0d2y 9pgwaAYIKwYBBQUHAQEEXDBaMDYGCCsGAQUFBzAChipodHRwOi8vY3JsLmRpc2EubWlsL3NpZ24v RE9ERU1BSUxDQV8yOS5jZXIwIAYIKwYBBQUHMAGGFGh0dHA6Ly9vY3NwLmRpc2EubWlsMEQGA1Ud EQQ9MDuBGXJhZGhpa2Euci5yb3lAdXMuYXJteS5taWygHgYKKwYBBAGCNxQCA6AQDA4xMjkxOTM5 ODAxQG1pbDAbBgNVHQkEFDASMBAGCCsGAQUFBwkEMQQTAlVTMCkGA1UdJQQiMCAGCisGAQQBgjcU AgIGCCsGAQUFBwMCBggrBgEFBQcDBDANBgkqhkiG9w0BAQUFAAOCAQEAggVw28drobHRF6Zr7wQZ G/ShO0BE6jEddlmlqj9ln2mC5HoTTXkl2ZOqjUoh2Wq2d55KvbZk9b73bIzWK+RnnoU+zOHagyB/ VnEbSpdofTm50zJYISK7Ws92KCt8viNetFkS2CTNSc302cqmwejpTwKAxkLDM0wU7ECNopN87F0O vPU2AJnITH32PrAvTVOeCxsDdEnzzXYxvKtNE5K6zBVVumSOGLMfnyFAq+4dlhg7i25B8Goh+fIF eRGiwxsXOyEMPalWHt5wWDDmUlIK0Qmg95mZ7f6UJCmj15zzSxgliR+JyVlFGH6/HYzIAU4lv8b5 uU5qyxANtVCvuGDruDCCBVIwggQ6oAMCAQICAgG4MA0GCSqGSIb3DQEBBQUAMFsxCzAJBgNVBAYT AlVTMRgwFgYDVQQKEw9VLlMuIEdvdmVybm1lbnQxDDAKBgNVBAsTA0RvRDEMMAoGA1UECxMDUEtJ MRYwFAYDVQQDEw1Eb0QgUm9vdCBDQSAyMB4XDTExMDkwODE2MDIxNFoXDTE3MDkwODE2MDIxNFow XTELMAkGA1UEBhMCVVMxGDAWBgNVBAoTD1UuUy4gR292ZXJubWVudDEMMAoGA1UECxMDRG9EMQww CgYDVQQLEwNQS0kxGDAWBgNVBAMTD0RPRCBFTUFJTCBDQS0yOTCCASIwDQYJKoZIhvcNAQEBBQAD ggEPADCCAQoCggEBAJJiL0HCIAAWBlVkn72niBVugptIwYV3vQKrDNnxK2CBAbo+dXCOEqanOISQ s+lAgBLcaspRza0thhDMRLwOxVg4GbIUMiVBVFhcQw7IbHMPwwwYGBYEmlI9gaJxzjwyAJ9xVbr4 zjZ3HiG3KJTnPT6m9sB6MWCRKJd3IlDyxpNushvFQcb5oTf7EL/aVqb7Uk1fv+/Elnco5TL/6OEY zENSGKyNd5pyTOidA16wou/k3dLn5qemUq3hmAiWSkPMcz1Loo2J79yCTLhKgCRlKx6RgvUE9nIf VxhAF/A5UbaP84k7Z/dYTkq82vkOwcAMvfMIcfiDD8kugJX0hQ7OrqkCAwEAAaOCAhwwggIYMA4G A1UdDwEB/wQEAwIBhjAfBgNVHSMEGDAWgBRJdLsMXrp6/gJU73ugxpXGCYBwljAdBgNVHQ4EFgQU uEODZCF67nCB3qXeDGAoh3iuXngwEgYDVR0TAQH/BAgwBgEB/wIBADAMBgNVHSQEBTADgAEAMGYG A1UdIARfMF0wCwYJYIZIAWUCAQsFMAsGCWCGSAFlAgELCTALBglghkgBZQIBCxEwCwYJYIZIAWUC AQsSMAsGCWCGSAFlAgELEzAMBgpghkgBZQMCAQMaMAwGCmCGSAFlAwIBAxswNwYDVR0fBDAwLjAs oCqgKIYmaHR0cDovL2NybC5kaXNhLm1pbC9jcmwvRE9EUk9PVENBMi5jcmwwggEBBggrBgEFBQcB AQSB9DCB8TA6BggrBgEFBQcwAoYuaHR0cDovL2NybC5kaXNhLm1pbC9pc3N1ZWR0by9ET0RST09U Q0EyX0lULnA3YzAgBggrBgEFBQcwAYYUaHR0cDovL29jc3AuZGlzYS5taWwwgZAGCCsGAQUFBzAC hoGDbGRhcDovL2NybC5nZHMuZGlzYS5taWwvY24lM2REb0QlMjBSb290JTIwQ0ElMjAyJTJjb3Ul M2RQS0klMmNvdSUzZERvRCUyY28lM2RVLlMuJTIwR292ZXJubWVudCUyY2MlM2RVUz9jcm9zc0Nl cnRpZmljYXRlUGFpcjtiaW5hcnkwDQYJKoZIhvcNAQEFBQADggEBACxrLHk12/AeHId7q+HoaWo3 i9t6T1VgaZUvU53GykO21DeR1gNdflqxuB33noHTrlBUMKRvSy67FBsXqlwQ05R6MTmWpFR59elW LlXDGxbqqgLIz1H3MoEixjQ6qc2aqkiTx+n7HjJ+ccR28EVUEh1V6r1cMoc6rpOabpkiX6hRNe6y U2Bf9k9FuBaEHWVVzRXKEAEfqdKcp1eRo9fnsIY9LfSJOtjJd3BQxmzv8uuY+BCqPdrIXCmtzrhz SUyhkrvm7c26ghpjIRll9AYZv4Oqc+XTG7GY/0Xf+0nMc+ji5weWADHpf9kkCOfKRHpIBsNC2D/5 eYelN5IWqYQgkmMxggMyMIIDLgIBATBkMF0xCzAJBgNVBAYTAlVTMRgwFgYDVQQKEw9VLlMuIEdv dmVybm1lbnQxDDAKBgNVBAsTA0RvRDEMMAoGA1UECxMDUEtJMRgwFgYDVQQDEw9ET0QgRU1BSUwg Q0EtMjkCAx88yTAJBgUrDgMCGgUAoIIBozAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG SIb3DQEJBTEPFw0xMjExMDYyMDEyMjlaMCMGCSqGSIb3DQEJBDEWBBTI+7XO5LMt70HWBRolHGBZ 6UOuKjBYBgkqhkiG9w0BCQ8xSzBJMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDAHBgUrDgMC BzANBggqhkiG9w0DAgIBKDAHBgUrDgMCGjAKBggqhkiG9w0CBTBzBgkrBgEEAYI3EAQxZjBkMF0x CzAJBgNVBAYTAlVTMRgwFgYDVQQKEw9VLlMuIEdvdmVybm1lbnQxDDAKBgNVBAsTA0RvRDEMMAoG A1UECxMDUEtJMRgwFgYDVQQDEw9ET0QgRU1BSUwgQ0EtMjkCAx88yjB1BgsqhkiG9w0BCRACCzFm oGQwXTELMAkGA1UEBhMCVVMxGDAWBgNVBAoTD1UuUy4gR292ZXJubWVudDEMMAoGA1UECxMDRG9E MQwwCgYDVQQLEwNQS0kxGDAWBgNVBAMTD0RPRCBFTUFJTCBDQS0yOQIDHzzKMA0GCSqGSIb3DQEB AQUABIIBABQpyicXULa34nLsoYCQs9Af5h2np5dszgKRPfSt9L1OM1BiM5eEwrZjbW0p2dDzZRfL XgM4NYPoMDUZc1x4k7jVwYfBmURmfPWqLGWT4jyepUWw4RZ0ijy878ZN5XZGdL8LV3xDq3KpTD8g Pw01cJ12NoExJSZ2K3cf2Qf/ftH38rHPZCrfGE3i7gga8CPPQzw5VkoohILpb0qIUFVwul6qoV+9 sO3+wi+D0iPbs0Q31GBKZjZ0exgfzgtqf4Pzeqdgbksy8WsC23/a+4HmCfdMvpX0xrn8PI2jv7Yy llASkDwrRolJaq2CQKRvvaOF9i4H6a9if2R9PKmGPjAoY34AAAAAAAA= ------=_NextPart_000_0068_01CDBC31.23455C60-- From adam@nostrum.com Tue Nov 6 12:50:18 2012 Return-Path: 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 7AF2321F8AF3 for ; Tue, 6 Nov 2012 12:50:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[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 abx7XQEYJOqk for ; Tue, 6 Nov 2012 12:50:18 -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 D6E1821F84FA for ; Tue, 6 Nov 2012 12:50:17 -0800 (PST) Received: from dhcp-5037.meeting.ietf.org (dhcp-5037.meeting.ietf.org [130.129.80.55]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id qA6KoGU1034438 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 6 Nov 2012 14:50:17 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <50997809.7050306@nostrum.com> Date: Tue, 06 Nov 2012 15:50:17 -0500 From: Adam Roach 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: "Roy, Radhika R CIV (US)" References: <50993285.4020408@nostrum.com> <8486C8728176924BAF5BDB2F7D7EEDDF48652767@ucolhp9h.easf.csd.disa.mil> In-Reply-To: <8486C8728176924BAF5BDB2F7D7EEDDF48652767@ucolhp9h.easf.csd.disa.mil> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 130.129.80.55 is authenticated by a trusted mechanism) Cc: sipcore@ietf.org 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Nov 2012 20:50:18 -0000 [as an individual] On 11/6/12 15:12, Roy, Radhika R CIV (US) wrote: > Folks: > > I have another point to explain: > > +------------+-----------+ > | Priority | Reference | > +------------+-----------+ > | non-urgent | RFC 3261 | > | normal | RFC 3261 | > | urgent | RFC 3261 | > | emergency | RFC 3261 | > +------------+-----------+ > > The definition of each value needs to be provided. I would argue that that's what the "Reference" column is for. The technical description of what a priority means may be somewhat complicated or include some subtle points that would require more text than would be appropriate for a registry. > It is not clear how one label will differ with all others. And that's why you need to look at RFC 3261. It explains the difference. In particular, read section 20.26. > Also, come confusions arise with respect when priority labels are applied > related to call, media, and others. Priority... labels... media? What? > RFCs 4411 and 4412, 5478, 6433, 6061, 5031, and 3689 need to be seen for > some guidance before explaining the labels so that terminologies and > definitions do not overlap or contradict. Aha! I think I see the confusion. You've mixed up "Priority" (RFC 3261, section 20.26) with "Resource-Priority" (RFC 4412). Please carefully read RFC 3261 section 20.26 and reconsider your comments. Thanks. /a From pkyzivat@alum.mit.edu Tue Nov 6 16:26:31 2012 Return-Path: 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 48C1B21F8A14 for ; Tue, 6 Nov 2012 16:26:31 -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 GX4sJxwWePri for ; Tue, 6 Nov 2012 16:26:30 -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 9901D21F8473 for ; Tue, 6 Nov 2012 16:26:30 -0800 (PST) Received: from omta21.westchester.pa.mail.comcast.net ([76.96.62.72]) by qmta03.westchester.pa.mail.comcast.net with comcast id LQ0u1k0071ZXKqc53QSa7S; Wed, 07 Nov 2012 00:26:34 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([216.138.103.10]) by omta21.westchester.pa.mail.comcast.net with comcast id LQRd1k00f0DU8JY3hQRg7Q; Wed, 07 Nov 2012 00:25:45 +0000 Message-ID: <5099AA97.5000003@alum.mit.edu> Date: Tue, 06 Nov 2012 19:25:59 -0500 From: Paul Kyzivat 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> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [sipcore] Establishing a "Priority" header field registry - Update 3261? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Nov 2012 00:26:31 -0000 On 11/6/12 2:33 PM, DRAGE, Keith (Keith) wrote: > 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. I had a discussion with Keith on this and we fundamentally disagree on the point of whether introducing a new registry for an element defined in an existing document (in this case 3261) constitutes a revision. I believe it does. Previously, when there was no registry, 3261 was authoritative regarding what values are valid for the header. If a new draft wanted to add a new value without there being a registry, then that new draft would itself be an update to 3261. The draft that defines the registry changes the authoritative source for valid values for the field. Subsequently, new drafts that want to define new values only need update the registry, and don't constitute updates to 3261. The record that the draft introducing the registry updates 3261 is the link that preserves tracability. Consider a newbie who is analyzing a message log. In that log he finds "Priority:psap-callback". He wonders what that means. Where does he go to find out? 1) he probably starts by looking in 3261 as his authoritative source for sip. He looks at the description of the Priority header and finds that "psap-callback" isn't there. So where does he look next? 2) I assert the next thing he should do is looked at the header of 3261, at "Obsoleted by" and "Updated by" references. In this case he will unfortunately have to examine a number of "Updated by" RFCs. Ideally he will find a reference to Adam's draft (then RFC) that introduces the registry. 3) Given the registry reference, he can then go to IANA, look in the registry for the Priority header, and find the reference to the RFC defining "psap-callback". Without that sort of tracability he will need to have done a *lot* of RFC reading, or know to troll the IANA registry for things that sound relevant. IMO we should endeavor to always maintain such tracability. Sadly we haven't always done so in the past. For instance, RFC 3968 established the Header Field Parameter Registry, but it does not indicate that it updates 3261, and so 3261 doesn't show that it is updated by 3968. (Instead 3968 indicates that it updates 3427, which also doesn't update 3261.) Thanks, Paul (I guess I'm speaking as an individual here rather than a chair of sipcore, because this is about my interpretation of proper process, not anything that ought to be specific to sipcore.) From pkyzivat@alum.mit.edu Tue Nov 6 16:29:23 2012 Return-Path: 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 ; 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 ; 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 ; 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 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> In-Reply-To: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 > From jmpolk@cisco.com Tue Nov 6 20:05:22 2012 Return-Path: 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 AA00E21F8A60; Tue, 6 Nov 2012 20:05:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.565 X-Spam-Level: X-Spam-Status: No, score=-110.565 tagged_above=-999 required=5 tests=[AWL=0.034, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 4Re1DGoYAwIQ; Tue, 6 Nov 2012 20:05:22 -0800 (PST) Received: from rcdn-iport-5.cisco.com (rcdn-iport-5.cisco.com [173.37.86.76]) by ietfa.amsl.com (Postfix) with ESMTP id CBA4021F889D; Tue, 6 Nov 2012 20:05:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1903; q=dns/txt; s=iport; t=1352261122; x=1353470722; h=message-id:date:to:from:subject:cc:in-reply-to: references:mime-version; bh=aItKMiivrTUKw4XfSAlTlY605Qscm1y6Rxve5sEo2Uc=; b=cX83ETqkW5edXH5s65+7CgqjR/Z+fExmKYk8RSk+kA5AjRyv2mXeFG4/ gHpTmnvmAxflMzKktE7p7U9teiSysDjs/3xjFH11Cu0PAf93eICFFyOyC mySsJ4B4rPIBwOO89yUv3pWAMuzW6OWv0EHeyLGg/PJytJa6GgRjNT/yv c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av4EAGTcmVCtJXG9/2dsb2JhbABEw2CBCIIeAQEBBAEBAQ8BJQI0CxAHBBgeEBkOMAYBEgkZh2gLmy+PYpA+jAOGVQOIWpt6gWuDDg X-IronPort-AV: E=Sophos;i="4.80,725,1344211200"; d="scan'208";a="139572912" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-5.cisco.com with ESMTP; 07 Nov 2012 04:05:21 +0000 Received: from jmpolk-WS.cisco.com (rtp-vpn5-873.cisco.com [10.82.235.108]) (authenticated bits=0) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id qA745JVS004352 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 7 Nov 2012 04:05:21 GMT Message-Id: <201211070405.qA745JVS004352@rcdn-core2-2.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 06 Nov 2012 22:05:20 -0600 To: "Rosen, Brian" , "sipcore@ietf.org" From: James Polk In-Reply-To: <7D126AA8-CCA4-4D88-82FA-796ADC0FFEB0@neustar.biz> References: <50993285.4020408@nostrum.com> <7D126AA8-CCA4-4D88-82FA-796ADC0FFEB0@neustar.biz> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Authenticated-User: jmpolk Cc: "ecrit@ietf.org" Subject: Re: [sipcore] [Ecrit] 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Nov 2012 04:05:22 -0000 I support this work James At 12:22 PM 11/6/2012, Rosen, Brian wrote: >I support this work. I agree with Christer about a registration >template. While it is obvious what is requested, I think it's >better to have it. > >I am happy with "IETF Review" as the management policy. > >Brian > >On Nov 6, 2012, at 10:53 AM, Adam Roach wrote: > > > [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 > >_______________________________________________ >Ecrit mailing list >Ecrit@ietf.org >https://www.ietf.org/mailman/listinfo/ecrit From jgunn6@csc.com Wed Nov 7 06:07:58 2012 Return-Path: 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 B1B7821F875C; Wed, 7 Nov 2012 06:07:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.952 X-Spam-Level: X-Spam-Status: No, score=-5.952 tagged_above=-999 required=5 tests=[AWL=0.646, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] 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 z13fEEH50r0U; Wed, 7 Nov 2012 06:07:57 -0800 (PST) Received: from mail85.messagelabs.com (mail85.messagelabs.com [216.82.241.211]) by ietfa.amsl.com (Postfix) with ESMTP id 784CF21F8742; Wed, 7 Nov 2012 06:07:57 -0800 (PST) X-Env-Sender: jgunn6@csc.com X-Msg-Ref: server-14.tower-85.messagelabs.com!1352297276!36749630!1 X-Originating-IP: [20.137.2.87] X-StarScan-Received: X-StarScan-Version: 6.6.1.8; banners=-,-,- X-VirusChecked: Checked Received: (qmail 595 invoked from network); 7 Nov 2012 14:07:56 -0000 Received: from amer-mta101.csc.com (HELO amer-mta101.csc.com) (20.137.2.87) by server-14.tower-85.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 7 Nov 2012 14:07:56 -0000 Received: from amer-gw09.amer.csc.com (amer-gw09.amer.csc.com [20.6.39.245]) by amer-mta101.csc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id qA7E7sc0025836; Wed, 7 Nov 2012 09:07:54 -0500 In-Reply-To: <201211070405.qA745JVS004352@rcdn-core2-2.cisco.com> References: <50993285.4020408@nostrum.com> <7D126AA8-CCA4-4D88-82FA-796ADC0FFEB0@neustar.biz> <201211070405.qA745JVS004352@rcdn-core2-2.cisco.com> To: James Polk MIME-Version: 1.0 X-KeepSent: B909FEAE:A277906E-85257AAF:004D90C7; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.2FP4 SHF97 March 26, 2012 From: Janet P Gunn Message-ID: Date: Wed, 7 Nov 2012 09:07:50 -0500 X-MIMETrack: Serialize by Router on AMER-GW09/SRV/CSC(Release 8.5.2FP3 HF204|September 20, 2011) at 11/07/2012 09:03:22 AM, Serialize complete at 11/07/2012 09:03:22 AM Content-Type: multipart/alternative; boundary="=_alternative 004DA15685257AAF_=" Cc: "Rosen, Brian" , "sipcore@ietf.org" , "ecrit@ietf.org" , ecrit-bounces@ietf.org Subject: Re: [sipcore] [Ecrit] 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Nov 2012 14:07:58 -0000 This is a multipart message in MIME format. --=_alternative 004DA15685257AAF_= Content-Type: text/plain; charset="US-ASCII" I also support this work Janet This is a PRIVATE message. If you are not the intended recipient, please delete without copying and kindly advise us by e-mail of the mistake in delivery. NOTE: Regardless of content, this e-mail shall not operate to bind CSC to any order or other contract unless pursuant to explicit written agreement or government initiative expressly permitting the use of e-mail for such purpose. From: James Polk To: "Rosen, Brian" , "sipcore@ietf.org" Cc: "ecrit@ietf.org" Date: 11/06/2012 11:05 PM Subject: Re: [Ecrit] [sipcore] Establishing a "Priority" header field registry Sent by: ecrit-bounces@ietf.org I support this work James At 12:22 PM 11/6/2012, Rosen, Brian wrote: >I support this work. I agree with Christer about a registration >template. While it is obvious what is requested, I think it's >better to have it. > >I am happy with "IETF Review" as the management policy. > >Brian > >On Nov 6, 2012, at 10:53 AM, Adam Roach wrote: > > > [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 > >_______________________________________________ >Ecrit mailing list >Ecrit@ietf.org >https://www.ietf.org/mailman/listinfo/ecrit _______________________________________________ Ecrit mailing list Ecrit@ietf.org https://www.ietf.org/mailman/listinfo/ecrit --=_alternative 004DA15685257AAF_= Content-Type: text/html; charset="US-ASCII" I also support this work
Janet

This is a PRIVATE message. If you are not the intended recipient, please delete without copying and kindly advise us by e-mail of the mistake in delivery. NOTE: Regardless of content, this e-mail shall not operate to bind CSC to any order or other contract unless pursuant to explicit written agreement or government initiative expressly permitting the use of e-mail for such purpose.



From:        James Polk <jmpolk@cisco.com>
To:        "Rosen, Brian" <Brian.Rosen@neustar.biz>, "sipcore@ietf.org" <sipcore@ietf.org>
Cc:        "ecrit@ietf.org" <ecrit@ietf.org>
Date:        11/06/2012 11:05 PM
Subject:        Re: [Ecrit] [sipcore] Establishing a "Priority" header field registry
Sent by:        ecrit-bounces@ietf.org



I support this work

James

At 12:22 PM 11/6/2012, Rosen, Brian wrote:
>I support this work.  I agree with Christer about a registration
>template.  While it is obvious what is requested, I think it's
>better to have it.
>
>I am happy with "IETF Review" as the management policy.
>
>Brian
>
>On Nov 6, 2012, at 10:53 AM, Adam Roach <adam@nostrum.com> wrote:
>
> > [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
>
>_______________________________________________
>Ecrit mailing list
>Ecrit@ietf.org
>https://www.ietf.org/mailman/listinfo/ecrit

_______________________________________________
Ecrit mailing list
Ecrit@ietf.org
https://www.ietf.org/mailman/listinfo/ecrit
--=_alternative 004DA15685257AAF_=-- From rjsparks@nostrum.com Wed Nov 7 07:16:41 2012 Return-Path: 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 9628721F8BDF for ; Wed, 7 Nov 2012 07:16:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[AWL=0.000, 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 epnL3mfTZNWA for ; Wed, 7 Nov 2012 07:16:40 -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 64DBD21F8BAE for ; Wed, 7 Nov 2012 07:16:40 -0800 (PST) Received: from dhcp-6421.meeting.ietf.org (dhcp-6421.meeting.ietf.org [130.129.100.33]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id qA7FGFDD047181 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Wed, 7 Nov 2012 09:16:16 -0600 (CST) (envelope-from rjsparks@nostrum.com) Message-ID: <509A7B3F.6020603@nostrum.com> Date: Wed, 07 Nov 2012 10:16:15 -0500 From: Robert Sparks 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: "DRAGE, Keith (Keith)" References: <50993285.4020408@nostrum.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 130.129.100.33 is authenticated by a trusted mechanism) Cc: "sipcore@ietf.org" 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Nov 2012 15:16:41 -0000 In this particular case, I think using UPDATES is the right thing to do. As Adam has noted, RFC3261 left _how_ to exercise this particular extension point less well-defined than it did for most. In clearing up the ambiguity that left, this document is changing the (what had to be implicitly inferred) consensus on what needs to be done to add a recognized value for this header field. (We would be using UPDATES if there had been a registry defined for this in RFC3261 and we were changing its registration policy). RjS 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 From ben@nostrum.com Wed Nov 7 15:03:58 2012 Return-Path: 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 D0B2521F8A5D for ; Wed, 7 Nov 2012 15:03:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.135 X-Spam-Level: X-Spam-Status: No, score=-102.135 tagged_above=-999 required=5 tests=[AWL=0.465, 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 33sgSnSJtSHC for ; Wed, 7 Nov 2012 15:03:58 -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 97D9021F8A13 for ; Wed, 7 Nov 2012 15:03:56 -0800 (PST) Received: from dhcp-6471.meeting.ietf.org (dhcp-6471.meeting.ietf.org [130.129.100.113]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id qA7N3sAx091716 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 7 Nov 2012 17:03:55 -0600 (CST) (envelope-from ben@nostrum.com) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Ben Campbell In-Reply-To: <5099AA97.5000003@alum.mit.edu> Date: Wed, 7 Nov 2012 18:03:53 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <03140467-29B6-4B60-9215-36D9BF5710AA@nostrum.com> References: <50993285.4020408@nostrum.com> <5099AA97.5000003@alum.mit.edu> To: Paul Kyzivat X-Mailer: Apple Mail (2.1499) Received-SPF: pass (nostrum.com: 130.129.100.113 is authenticated by a trusted mechanism) Cc: sipcore@ietf.org Subject: Re: [sipcore] Establishing a "Priority" header field registry - Update 3261? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Nov 2012 23:03:59 -0000 On Nov 6, 2012, at 7:25 PM, Paul Kyzivat wrote: >=20 > I had a discussion with Keith on this and we fundamentally disagree on = the point of whether introducing a new registry for an element defined = in an existing document (in this case 3261) constitutes a revision. I = believe it does. >=20 > Previously, when there was no registry, 3261 was authoritative = regarding what values are valid for the header. If a new draft wanted to = add a new value without there being a registry, then that new draft = would itself be an update to 3261. >=20 > The draft that defines the registry changes the authoritative source = for valid values for the field. Subsequently, new drafts that want to = define new values only need update the registry, and don't constitute = updates to 3261. +1.=20 Additionally, I think the creation or change of a registration policy is = definitely a normative update. From keith.drage@alcatel-lucent.com Wed Nov 7 15:08:20 2012 Return-Path: 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 2300621F8495 for ; Wed, 7 Nov 2012 15:08:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.885 X-Spam-Level: X-Spam-Status: No, score=-109.885 tagged_above=-999 required=5 tests=[AWL=0.364, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8, 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 zY2z8PHWasL4 for ; Wed, 7 Nov 2012 15:08:16 -0800 (PST) Received: from smail2.alcatel.fr (smail2.alcatel.fr [64.208.49.57]) by ietfa.amsl.com (Postfix) with ESMTP id D060921F847B for ; Wed, 7 Nov 2012 15:08:15 -0800 (PST) Received: from FRMRSSXCHHUB04.dc-m.alcatel-lucent.com (FRMRSSXCHHUB04.dc-m.alcatel-lucent.com [135.120.45.64]) by smail2.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id qA7N8BBm008349 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 8 Nov 2012 00:08:12 +0100 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.46]) by FRMRSSXCHHUB04.dc-m.alcatel-lucent.com ([135.120.45.64]) with mapi; Thu, 8 Nov 2012 00:08:11 +0100 From: "DRAGE, Keith (Keith)" To: Ben Campbell , Paul Kyzivat Date: Thu, 8 Nov 2012 00:08:09 +0100 Thread-Topic: [sipcore] Establishing a "Priority" header field registry - Update 3261? Thread-Index: Ac29PDX040+t4lbNTqqTYiCKofpiiwAADeAw Message-ID: References: <50993285.4020408@nostrum.com> <5099AA97.5000003@alum.mit.edu> <03140467-29B6-4B60-9215-36D9BF5710AA@nostrum.com> In-Reply-To: <03140467-29B6-4B60-9215-36D9BF5710AA@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.80 Cc: "sipcore@ietf.org" Subject: Re: [sipcore] Establishing a "Priority" header field registry - Update 3261? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Nov 2012 23:08:20 -0000 The creation of a registration policy certainly does not create an update a= nd none of the people I have talked to have come to that conclusion either. The change of a registration policy, maybe, but in this case I actually dis= pute that there is an implied registration policy in RFC 3261. All RFC 3261= defines is an extension mechanism. Regards Keith > -----Original Message----- > From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behal= f > Of Ben Campbell > Sent: 07 November 2012 23:04 > To: Paul Kyzivat > Cc: sipcore@ietf.org > Subject: Re: [sipcore] Establishing a "Priority" header field registry - > Update 3261? >=20 >=20 > On Nov 6, 2012, at 7:25 PM, Paul Kyzivat wrote: >=20 > > > > I had a discussion with Keith on this and we fundamentally disagree on > the point of whether introducing a new registry for an element defined in > an existing document (in this case 3261) constitutes a revision. I believ= e > it does. > > > > Previously, when there was no registry, 3261 was authoritative regardin= g > what values are valid for the header. If a new draft wanted to add a new > value without there being a registry, then that new draft would itself be > an update to 3261. > > > > The draft that defines the registry changes the authoritative source fo= r > valid values for the field. Subsequently, new drafts that want to define > new values only need update the registry, and don't constitute updates to > 3261. >=20 > +1. >=20 > Additionally, I think the creation or change of a registration policy is > definitely a normative update. >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From ben@nostrum.com Wed Nov 7 15:09:44 2012 Return-Path: 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 D813A21F8508 for ; Wed, 7 Nov 2012 15:09:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.251 X-Spam-Level: X-Spam-Status: No, score=-102.251 tagged_above=-999 required=5 tests=[AWL=0.349, 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 26bRSRFJhccX for ; Wed, 7 Nov 2012 15:09:44 -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 6994121F8543 for ; Wed, 7 Nov 2012 15:09:44 -0800 (PST) Received: from dhcp-6471.meeting.ietf.org (dhcp-6471.meeting.ietf.org [130.129.100.113]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id qA7N9fkB092252 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 7 Nov 2012 17:09:41 -0600 (CST) (envelope-from ben@nostrum.com) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Ben Campbell In-Reply-To: Date: Wed, 7 Nov 2012 18:09:40 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <50993285.4020408@nostrum.com> <5099AA97.5000003@alum.mit.edu> <03140467-29B6-4B60-9215-36D9BF5710AA@nostrum.com> To: "DRAGE, Keith (Keith)" X-Mailer: Apple Mail (2.1499) Received-SPF: pass (nostrum.com: 130.129.100.113 is authenticated by a trusted mechanism) Cc: "sipcore@ietf.org" Subject: Re: [sipcore] Establishing a "Priority" header field registry - Update 3261? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Nov 2012 23:09:45 -0000 On Nov 7, 2012, at 6:08 PM, "DRAGE, Keith (Keith)" = wrote: > The creation of a registration policy certainly does not create an = update and none of the people I have talked to have come to that = conclusion either. >=20 > The change of a registration policy, maybe, but in this case I = actually dispute that there is an implied registration policy in RFC = 3261. All RFC 3261 defines is an extension mechanism. How is going from no policy to having a policy _not_ a change? From keith.drage@alcatel-lucent.com Wed Nov 7 15:11:20 2012 Return-Path: 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 652BD21F8543 for ; Wed, 7 Nov 2012 15:11:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.916 X-Spam-Level: X-Spam-Status: No, score=-109.916 tagged_above=-999 required=5 tests=[AWL=0.333, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8, 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 3BPOj1DV3qlf for ; Wed, 7 Nov 2012 15:11:16 -0800 (PST) Received: from smail3.alcatel.fr (smail3.alcatel.fr [64.208.49.56]) by ietfa.amsl.com (Postfix) with ESMTP id 3CB4721F8508 for ; Wed, 7 Nov 2012 15:11:16 -0800 (PST) Received: from FRMRSSXCHHUB02.dc-m.alcatel-lucent.com (FRMRSSXCHHUB02.dc-m.alcatel-lucent.com [135.120.45.62]) by smail3.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id qA7NBBNM010415 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 8 Nov 2012 00:11:13 +0100 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.46]) by FRMRSSXCHHUB02.dc-m.alcatel-lucent.com ([135.120.45.62]) with mapi; Thu, 8 Nov 2012 00:11:13 +0100 From: "DRAGE, Keith (Keith)" To: Ben Campbell Date: Thu, 8 Nov 2012 00:11:11 +0100 Thread-Topic: [sipcore] Establishing a "Priority" header field registry - Update 3261? Thread-Index: Ac29PPtsMQOQ2zlFSTW7MVKR0+WLmQAABvSA Message-ID: References: <50993285.4020408@nostrum.com> <5099AA97.5000003@alum.mit.edu> <03140467-29B6-4B60-9215-36D9BF5710AA@nostrum.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.83 Cc: "sipcore@ietf.org" Subject: Re: [sipcore] Establishing a "Priority" header field registry - Update 3261? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Nov 2012 23:11:20 -0000 You follow that argument through to its logical conclusion and every new RF= C updates the previous 6000. Keith > -----Original Message----- > From: Ben Campbell [mailto:ben@nostrum.com] > Sent: 07 November 2012 23:10 > To: DRAGE, Keith (Keith) > Cc: Paul Kyzivat; sipcore@ietf.org > Subject: Re: [sipcore] Establishing a "Priority" header field registry - > Update 3261? >=20 >=20 > On Nov 7, 2012, at 6:08 PM, "DRAGE, Keith (Keith)" lucent.com> wrote: >=20 > > The creation of a registration policy certainly does not create an > update and none of the people I have talked to have come to that > conclusion either. > > > > The change of a registration policy, maybe, but in this case I actually > dispute that there is an implied registration policy in RFC 3261. All RFC > 3261 defines is an extension mechanism. >=20 > How is going from no policy to having a policy _not_ a change? >=20 From radhika.r.roy.civ@mail.mil Wed Nov 7 07:07:20 2012 Return-Path: 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 AC6D321F8C02 for ; Wed, 7 Nov 2012 07:07:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.3 X-Spam-Level: X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5 tests=[AWL=0.299, BAYES_00=-2.599] 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 Ax35f6wnH87o for ; Wed, 7 Nov 2012 07:07:20 -0800 (PST) Received: from edge-cols.mail.mil (edge-cols.mail.mil [131.64.100.11]) by ietfa.amsl.com (Postfix) with ESMTP id B7BC821F8C06 for ; Wed, 7 Nov 2012 07:07:19 -0800 (PST) Received: from UCOLHP3Q.easf.csd.disa.mil (131.64.100.156) by ucolhp3l.easf.csd.disa.mil (131.64.100.11) with Microsoft SMTP Server (TLS) id 14.2.309.2; Wed, 7 Nov 2012 15:07:06 +0000 Received: from UCOLHP9H.easf.csd.disa.mil ([169.254.5.171]) by UCOLHP3Q.easf.csd.disa.mil ([131.64.100.156]) with mapi id 14.02.0309.003; Wed, 7 Nov 2012 15:07:06 +0000 From: "Roy, Radhika R CIV (US)" To: Adam Roach Thread-Topic: [sipcore] Establishing a "Priority" header field registry Thread-Index: Ac28NvOrIv8b1cKGTcmMUjtYiz7Z8QAHC/AgAAGOMzAAAb3cgAAl93/A Date: Wed, 7 Nov 2012 15:07:05 +0000 Message-ID: <8486C8728176924BAF5BDB2F7D7EEDDF4865824D@ucolhp9h.easf.csd.disa.mil> References: <50993285.4020408@nostrum.com> <8486C8728176924BAF5BDB2F7D7EEDDF48652767@ucolhp9h.easf.csd.disa.mil> <50997809.7050306@nostrum.com> In-Reply-To: <50997809.7050306@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [131.64.62.4] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_0016_01CDBCCF.9EE592B0" MIME-Version: 1.0 X-Mailman-Approved-At: Wed, 07 Nov 2012 15:40:25 -0800 Cc: "sipcore@ietf.org" 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Nov 2012 15:07:20 -0000 ------=_NextPart_000_0016_01CDBCCF.9EE592B0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, Adam: You are right that you are referring to RFC 3261 semantics that also refer to RFC 2976. It is the SIP call level priority, that is, how a given call will be handled with relative to other calls. The issues that I have been trying to relate are the following: 1. Other RFCs that I referred also deal with call level priority including emergency calls. 2. A SIP call also contain media: Audio, Video, and/or Data. 3. Other RFCs also deal with resources priority that include media. Did anyone ever try to relate all these priority semantics from the SIP call to the media level knowing the semantics of all priority headers? BR/Radhika -----Original Message----- From: Adam Roach [mailto:adam@nostrum.com] Sent: Tuesday, November 06, 2012 3:50 PM To: Roy, Radhika R CIV (US) Cc: sipcore@ietf.org Subject: Re: [sipcore] Establishing a "Priority" header field registry [as an individual] On 11/6/12 15:12, Roy, Radhika R CIV (US) wrote: > Folks: > > I have another point to explain: > > +------------+-----------+ > | Priority | Reference | > +------------+-----------+ > | non-urgent | RFC 3261 | > | normal | RFC 3261 | > | urgent | RFC 3261 | > | emergency | RFC 3261 | > +------------+-----------+ > > The definition of each value needs to be provided. I would argue that that's what the "Reference" column is for. The technical description of what a priority means may be somewhat complicated or include some subtle points that would require more text than would be appropriate for a registry. > It is not clear how one label will differ with all others. And that's why you need to look at RFC 3261. It explains the difference. In particular, read section 20.26. > Also, come confusions arise with respect when priority labels are > applied related to call, media, and others. Priority... labels... media? What? > RFCs 4411 and 4412, 5478, 6433, 6061, 5031, and 3689 need to be seen > for some guidance before explaining the labels so that terminologies > and definitions do not overlap or contradict. Aha! I think I see the confusion. You've mixed up "Priority" (RFC 3261, section 20.26) with "Resource-Priority" (RFC 4412). Please carefully read RFC 3261 section 20.26 and reconsider your comments. Thanks. /a ------=_NextPart_000_0016_01CDBCCF.9EE592B0 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIISizCCA3Aw ggJYoAMCAQICAQUwDQYJKoZIhvcNAQEFBQAwWzELMAkGA1UEBhMCVVMxGDAWBgNVBAoTD1UuUy4g R292ZXJubWVudDEMMAoGA1UECxMDRG9EMQwwCgYDVQQLEwNQS0kxFjAUBgNVBAMTDURvRCBSb290 IENBIDIwHhcNMDQxMjEzMTUwMDEwWhcNMjkxMjA1MTUwMDEwWjBbMQswCQYDVQQGEwJVUzEYMBYG A1UEChMPVS5TLiBHb3Zlcm5tZW50MQwwCgYDVQQLEwNEb0QxDDAKBgNVBAsTA1BLSTEWMBQGA1UE AxMNRG9EIFJvb3QgQ0EgMjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMAswfaNO6z/ PzzWcb64dCIH7HBBFfyrQOMHqsHD2J/+2kw6vz/I2Ch7SzYBwKxFJcPSDgqPhRhkED0aE3Aqb47X 3I2Ts0EPOCHNravCPSoF01cRNw3NjFH5k+PMRkkhjhS0zcsUPjjNcjHuqxLyZeo0LlZd/+5jdctt upE0/J7z9C0cvlDEQt9ZiP9qs/qobD3LVnFxBZa7n4DlgEVZZ0Gw68OtYKSAdQYXnA70Q+CZDhv7 f/WzzLKBgrH9MsG4vkGkZLVgOlpRMIzO3kEsGUdcSRBkuXSph0GvfW66wbihv2UxOgRn+bW7jpKK AGO4seaMOF+D/1DVO6Jda7IQzGMCAwEAAaM/MD0wHQYDVR0OBBYEFEl0uwxeunr+AlTve6DGlcYJ gHCWMAsGA1UdDwQEAwIBhjAPBgNVHRMBAf8EBTADAQH/MA0GCSqGSIb3DQEBBQUAA4IBAQCYkY0/ ici79cBpcyk7Nay6swh2PXAJkumERCEBfRR2G+5RbB2NFTctezFp9JpEuK9GzDT6I8sDJxnSgyF1 K+fgG5km3IRAleio0sz2WFxm7z9KlxCCHboKot1bBiudp2RO6y4BNaS0PxOtVeTVc6hpmxHxmPIx Hm9A1Ph4n46RoG9wBJBmqgYrzuF6krV94eDRluehOi3MsZ0fBUTth5nTTRpwOcEEDOV+2fGv1yAO 8SJ6JaRzmcw/pAcnlqiile2CuRbTnguHwsHyiPVi32jfx7xpUe2xXNxUVCkPCTmarAPB2wxNrm8K ehZJ8b+R0jiU0/aVLLdsyUK2jcqQjYXZMIIEtzCCA5+gAwIBAgIDHzzKMA0GCSqGSIb3DQEBBQUA MF0xCzAJBgNVBAYTAlVTMRgwFgYDVQQKEw9VLlMuIEdvdmVybm1lbnQxDDAKBgNVBAsTA0RvRDEM MAoGA1UECxMDUEtJMRgwFgYDVQQDEw9ET0QgRU1BSUwgQ0EtMjkwHhcNMTIwOTIwMDAwMDAwWhcN MTUwOTE5MjM1OTU5WjB5MQswCQYDVQQGEwJVUzEYMBYGA1UEChMPVS5TLiBHb3Zlcm5tZW50MQww CgYDVQQLEwNEb0QxDDAKBgNVBAsTA1BLSTEMMAoGA1UECxMDVVNBMSYwJAYDVQQDEx1ST1kuUkFE SElLQS5SQU5KQU4uMTI5MTkzOTgwMTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAKw9 ymde30NtacDt8neYCBWDyA+Hlsk3dNwV23IVgH7vSWJx4zCFT5ojDHACm3lthvOOtJ0CzkjwQy8V hEHvL0eK03hZy0hJrZxQSYcao7Y0Yv9yDAFvxa6LJ1fUImUj9edMf1l08LZkjh3ybs20Bk+MLySR 9F/flRzjtCwVUeqq8NS3to4nPXSIgViP6H0YJrBjf9IDZQGgcO8LxLbNENOWrXILeCCCngnHBgHV lJWak9YndpMOs+CeLXk5oUV8xUAM/UjyS+/gFCjABBRt30VJVN6pqARmIht850iK8TDeqlWwF3O9 eQBBwKQPJ7nVl0kmGItYGoYb+4t2Mkwalh8CAwEAAaOCAWIwggFeMB8GA1UdIwQYMBaAFLhDg2Qh eu5wgd6l3gxgKId4rl54MDoGA1UdHwQzMDEwL6AtoCuGKWh0dHA6Ly9jcmwuZGlzYS5taWwvY3Js L0RPREVNQUlMQ0FfMjkuY3JsMA4GA1UdDwEB/wQEAwIFIDAjBgNVHSAEHDAaMAsGCWCGSAFlAgEL CTALBglghkgBZQIBCxMwHQYDVR0OBBYEFGRWf703swy+9hvoDujsb+ZPwC9MMGgGCCsGAQUFBwEB BFwwWjA2BggrBgEFBQcwAoYqaHR0cDovL2NybC5kaXNhLm1pbC9zaWduL0RPREVNQUlMQ0FfMjku Y2VyMCAGCCsGAQUFBzABhhRodHRwOi8vb2NzcC5kaXNhLm1pbDAkBgNVHREEHTAbgRlyYWRoaWth LnIucm95QHVzLmFybXkubWlsMBsGA1UdCQQUMBIwEAYIKwYBBQUHCQQxBBMCVVMwDQYJKoZIhvcN AQEFBQADggEBAE9PU63Rc/bneYoxI6sAZi+oXBiwneOiI03+J3pSZWIbwrOnj7qGoH5ZoeO+dZ8E wvKszd+vacYnO8SqEXsvIKvBGPchKg1oV5b24+tCSeiCXtcX5EDtpJQGS4W9G+7r7f+mdEHU0NuF NI7HNHRY/q4C+FGhchPoKPcKeyWxJMwp+9NJQsx1AoC5isvydZHHlNkV917dLMuMEqyCCAAbJAOp 8SDQTiiIVa1I7NlMSlkzNRUtFoO9nsEttMH699V9JH5jcwWPlWdyb5B6yRzoM/iFsI/hA9pHHukh iWVul3FX/6Ez8Jt/A1j/CFsl3S2y2TBRCdqIQEP+/H6j4RFxa9MwggUCMIID6qADAgECAgMfPMkw DQYJKoZIhvcNAQEFBQAwXTELMAkGA1UEBhMCVVMxGDAWBgNVBAoTD1UuUy4gR292ZXJubWVudDEM MAoGA1UECxMDRG9EMQwwCgYDVQQLEwNQS0kxGDAWBgNVBAMTD0RPRCBFTUFJTCBDQS0yOTAeFw0x MjA5MjAwMDAwMDBaFw0xNTA5MTkyMzU5NTlaMHkxCzAJBgNVBAYTAlVTMRgwFgYDVQQKEw9VLlMu IEdvdmVybm1lbnQxDDAKBgNVBAsTA0RvRDEMMAoGA1UECxMDUEtJMQwwCgYDVQQLEwNVU0ExJjAk BgNVBAMTHVJPWS5SQURISUtBLlJBTkpBTi4xMjkxOTM5ODAxMIIBIjANBgkqhkiG9w0BAQEFAAOC AQ8AMIIBCgKCAQEAyr7Ttduf1mHx22erLvkwPOZL02imdiimrmXITVrdUHsynK383NY6a4ye07Jm b0spr8hzmfM6JSCEgtbZevWfJg4NmNDjEEe53+7EvEMRHfh46GGxOckj98QmQwngbQaAIcKI1gJd Do2vB3mOtFp5hNKqsxibZAvpPb3OsR762vrx2QYQX+p8+psLwe95CSt56IfC39GZD+Otus3Sq1Ma 9e0NdRhqg5ch8FYpL2ONbmEw9+DTqk24Zh2lQuOvpo4FhpvXnNghCS4CfuiE6YgvKdombc1BGT5u rkDFep5IH7Rk7EnK4CVVzNq3gxT0B+hDoJT0AuQfrkxI9223mUJoywIDAQABo4IBrTCCAakwHwYD VR0jBBgwFoAUuEODZCF67nCB3qXeDGAoh3iuXngwOgYDVR0fBDMwMTAvoC2gK4YpaHR0cDovL2Ny bC5kaXNhLm1pbC9jcmwvRE9ERU1BSUxDQV8yOS5jcmwwDgYDVR0PAQH/BAQDAgbAMCMGA1UdIAQc MBowCwYJYIZIAWUCAQsJMAsGCWCGSAFlAgELEzAdBgNVHQ4EFgQUrV8KnskfJHURS19In/mX0d2y 9pgwaAYIKwYBBQUHAQEEXDBaMDYGCCsGAQUFBzAChipodHRwOi8vY3JsLmRpc2EubWlsL3NpZ24v RE9ERU1BSUxDQV8yOS5jZXIwIAYIKwYBBQUHMAGGFGh0dHA6Ly9vY3NwLmRpc2EubWlsMEQGA1Ud EQQ9MDuBGXJhZGhpa2Euci5yb3lAdXMuYXJteS5taWygHgYKKwYBBAGCNxQCA6AQDA4xMjkxOTM5 ODAxQG1pbDAbBgNVHQkEFDASMBAGCCsGAQUFBwkEMQQTAlVTMCkGA1UdJQQiMCAGCisGAQQBgjcU AgIGCCsGAQUFBwMCBggrBgEFBQcDBDANBgkqhkiG9w0BAQUFAAOCAQEAggVw28drobHRF6Zr7wQZ G/ShO0BE6jEddlmlqj9ln2mC5HoTTXkl2ZOqjUoh2Wq2d55KvbZk9b73bIzWK+RnnoU+zOHagyB/ VnEbSpdofTm50zJYISK7Ws92KCt8viNetFkS2CTNSc302cqmwejpTwKAxkLDM0wU7ECNopN87F0O vPU2AJnITH32PrAvTVOeCxsDdEnzzXYxvKtNE5K6zBVVumSOGLMfnyFAq+4dlhg7i25B8Goh+fIF eRGiwxsXOyEMPalWHt5wWDDmUlIK0Qmg95mZ7f6UJCmj15zzSxgliR+JyVlFGH6/HYzIAU4lv8b5 uU5qyxANtVCvuGDruDCCBVIwggQ6oAMCAQICAgG4MA0GCSqGSIb3DQEBBQUAMFsxCzAJBgNVBAYT AlVTMRgwFgYDVQQKEw9VLlMuIEdvdmVybm1lbnQxDDAKBgNVBAsTA0RvRDEMMAoGA1UECxMDUEtJ MRYwFAYDVQQDEw1Eb0QgUm9vdCBDQSAyMB4XDTExMDkwODE2MDIxNFoXDTE3MDkwODE2MDIxNFow XTELMAkGA1UEBhMCVVMxGDAWBgNVBAoTD1UuUy4gR292ZXJubWVudDEMMAoGA1UECxMDRG9EMQww CgYDVQQLEwNQS0kxGDAWBgNVBAMTD0RPRCBFTUFJTCBDQS0yOTCCASIwDQYJKoZIhvcNAQEBBQAD ggEPADCCAQoCggEBAJJiL0HCIAAWBlVkn72niBVugptIwYV3vQKrDNnxK2CBAbo+dXCOEqanOISQ s+lAgBLcaspRza0thhDMRLwOxVg4GbIUMiVBVFhcQw7IbHMPwwwYGBYEmlI9gaJxzjwyAJ9xVbr4 zjZ3HiG3KJTnPT6m9sB6MWCRKJd3IlDyxpNushvFQcb5oTf7EL/aVqb7Uk1fv+/Elnco5TL/6OEY zENSGKyNd5pyTOidA16wou/k3dLn5qemUq3hmAiWSkPMcz1Loo2J79yCTLhKgCRlKx6RgvUE9nIf VxhAF/A5UbaP84k7Z/dYTkq82vkOwcAMvfMIcfiDD8kugJX0hQ7OrqkCAwEAAaOCAhwwggIYMA4G A1UdDwEB/wQEAwIBhjAfBgNVHSMEGDAWgBRJdLsMXrp6/gJU73ugxpXGCYBwljAdBgNVHQ4EFgQU uEODZCF67nCB3qXeDGAoh3iuXngwEgYDVR0TAQH/BAgwBgEB/wIBADAMBgNVHSQEBTADgAEAMGYG A1UdIARfMF0wCwYJYIZIAWUCAQsFMAsGCWCGSAFlAgELCTALBglghkgBZQIBCxEwCwYJYIZIAWUC AQsSMAsGCWCGSAFlAgELEzAMBgpghkgBZQMCAQMaMAwGCmCGSAFlAwIBAxswNwYDVR0fBDAwLjAs oCqgKIYmaHR0cDovL2NybC5kaXNhLm1pbC9jcmwvRE9EUk9PVENBMi5jcmwwggEBBggrBgEFBQcB AQSB9DCB8TA6BggrBgEFBQcwAoYuaHR0cDovL2NybC5kaXNhLm1pbC9pc3N1ZWR0by9ET0RST09U Q0EyX0lULnA3YzAgBggrBgEFBQcwAYYUaHR0cDovL29jc3AuZGlzYS5taWwwgZAGCCsGAQUFBzAC hoGDbGRhcDovL2NybC5nZHMuZGlzYS5taWwvY24lM2REb0QlMjBSb290JTIwQ0ElMjAyJTJjb3Ul M2RQS0klMmNvdSUzZERvRCUyY28lM2RVLlMuJTIwR292ZXJubWVudCUyY2MlM2RVUz9jcm9zc0Nl cnRpZmljYXRlUGFpcjtiaW5hcnkwDQYJKoZIhvcNAQEFBQADggEBACxrLHk12/AeHId7q+HoaWo3 i9t6T1VgaZUvU53GykO21DeR1gNdflqxuB33noHTrlBUMKRvSy67FBsXqlwQ05R6MTmWpFR59elW LlXDGxbqqgLIz1H3MoEixjQ6qc2aqkiTx+n7HjJ+ccR28EVUEh1V6r1cMoc6rpOabpkiX6hRNe6y U2Bf9k9FuBaEHWVVzRXKEAEfqdKcp1eRo9fnsIY9LfSJOtjJd3BQxmzv8uuY+BCqPdrIXCmtzrhz SUyhkrvm7c26ghpjIRll9AYZv4Oqc+XTG7GY/0Xf+0nMc+ji5weWADHpf9kkCOfKRHpIBsNC2D/5 eYelN5IWqYQgkmMxggMyMIIDLgIBATBkMF0xCzAJBgNVBAYTAlVTMRgwFgYDVQQKEw9VLlMuIEdv dmVybm1lbnQxDDAKBgNVBAsTA0RvRDEMMAoGA1UECxMDUEtJMRgwFgYDVQQDEw9ET0QgRU1BSUwg Q0EtMjkCAx88yTAJBgUrDgMCGgUAoIIBozAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG SIb3DQEJBTEPFw0xMjExMDcxNTA2NTdaMCMGCSqGSIb3DQEJBDEWBBQb+2LB9SsvUe7fn+/AAJ+S BcxTljBYBgkqhkiG9w0BCQ8xSzBJMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDAHBgUrDgMC BzANBggqhkiG9w0DAgIBKDAHBgUrDgMCGjAKBggqhkiG9w0CBTBzBgkrBgEEAYI3EAQxZjBkMF0x CzAJBgNVBAYTAlVTMRgwFgYDVQQKEw9VLlMuIEdvdmVybm1lbnQxDDAKBgNVBAsTA0RvRDEMMAoG A1UECxMDUEtJMRgwFgYDVQQDEw9ET0QgRU1BSUwgQ0EtMjkCAx88yjB1BgsqhkiG9w0BCRACCzFm oGQwXTELMAkGA1UEBhMCVVMxGDAWBgNVBAoTD1UuUy4gR292ZXJubWVudDEMMAoGA1UECxMDRG9E MQwwCgYDVQQLEwNQS0kxGDAWBgNVBAMTD0RPRCBFTUFJTCBDQS0yOQIDHzzKMA0GCSqGSIb3DQEB AQUABIIBAJ4lxuVj5Iq+lyj83+Zp90m/VSU/FbZNzv7Cny4bNaMrAJiiETqVwU/BWZ/vwtajefBN GEi+u8Js1bf6MD8AdBzZxWK5PqXceCOIhP5HuWgqwgrAGo7DPm1fQ4WrFIIAprzVSLuXzr5rNISN HEV+4muUDwYT+MhDehCWKiR5T7wNfXF15dN4+rEXPJG3y9OARRj0mA8TeGp7yetAyv3X15KHb4mH YAq8qF8s39irGGAYSP5tnLpL3H7twmEzS1PqGGe7zRiqsYV6/++a5kVzEXD+/+0GtcVbnrRW9Mn+ dNsCUe2iy6+uC/n6swR9q6kS53J0X9fu4Gt8ODGGMQrRDw4AAAAAAAA= ------=_NextPart_000_0016_01CDBCCF.9EE592B0-- From keith.drage@alcatel-lucent.com Wed Nov 7 16:46:25 2012 Return-Path: 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 097D321F8C05 for ; Wed, 7 Nov 2012 16:46:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.941 X-Spam-Level: X-Spam-Status: No, score=-109.941 tagged_above=-999 required=5 tests=[AWL=0.308, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8, 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 eE95VvkD2n9E for ; Wed, 7 Nov 2012 16:46:24 -0800 (PST) Received: from smail2.alcatel.fr (smail2.alcatel.fr [64.208.49.57]) by ietfa.amsl.com (Postfix) with ESMTP id 1DA8A21F8BAC for ; Wed, 7 Nov 2012 16:46:23 -0800 (PST) Received: from FRMRSSXCHHUB04.dc-m.alcatel-lucent.com (FRMRSSXCHHUB04.dc-m.alcatel-lucent.com [135.120.45.64]) by smail2.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id qA80kLOR024185 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 8 Nov 2012 01:46:23 +0100 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.46]) by FRMRSSXCHHUB04.dc-m.alcatel-lucent.com ([135.120.45.64]) with mapi; Thu, 8 Nov 2012 01:46:21 +0100 From: "DRAGE, Keith (Keith)" To: "Roy, Radhika R CIV (US)" , Adam Roach Date: Thu, 8 Nov 2012 01:46:19 +0100 Thread-Topic: [sipcore] Establishing a "Priority" header field registry Thread-Index: Ac28NvOrIv8b1cKGTcmMUjtYiz7Z8QAHC/AgAAGOMzAAAb3cgAAl93/AABRG+pA= Message-ID: References: <50993285.4020408@nostrum.com> <8486C8728176924BAF5BDB2F7D7EEDDF48652767@ucolhp9h.easf.csd.disa.mil> <50997809.7050306@nostrum.com> <8486C8728176924BAF5BDB2F7D7EEDDF4865824D@ucolhp9h.easf.csd.disa.mil> In-Reply-To: <8486C8728176924BAF5BDB2F7D7EEDDF4865824D@ucolhp9h.easf.csd.disa.mil> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.80 Cc: "sipcore@ietf.org" 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Nov 2012 00:46:25 -0000 The Priority header field is rendered to the user or recipient application,= and in my view has no impact on the SIP processing directly. The Resource-Priority header field can impact usage of signaling resources = themselves, media resources and access resources. It does not necessarily i= mpact all of these, and which it impacts is defined by the namespaces used,= and how those namespaces are implemented in individual operators domains. Regards Keith > -----Original Message----- > From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behal= f > Of Roy, Radhika R CIV (US) > Sent: 07 November 2012 15:07 > To: Adam Roach > Cc: sipcore@ietf.org > Subject: Re: [sipcore] Establishing a "Priority" header field registry >=20 > Hi, Adam: >=20 > You are right that you are referring to RFC 3261 semantics that also refe= r > to RFC 2976. >=20 > It is the SIP call level priority, that is, how a given call will be > handled > with relative to other calls. >=20 > The issues that I have been trying to relate are the following: >=20 > 1. Other RFCs that I referred also deal with call level priority includin= g > emergency calls. >=20 > 2. A SIP call also contain media: Audio, Video, and/or Data. >=20 > 3. Other RFCs also deal with resources priority that include media. >=20 > Did anyone ever try to relate all these priority semantics from the SIP > call > to the media level knowing the semantics of all priority headers? >=20 > BR/Radhika >=20 > -----Original Message----- > From: Adam Roach [mailto:adam@nostrum.com] > Sent: Tuesday, November 06, 2012 3:50 PM > To: Roy, Radhika R CIV (US) > Cc: sipcore@ietf.org > Subject: Re: [sipcore] Establishing a "Priority" header field registry >=20 > [as an individual] >=20 > On 11/6/12 15:12, Roy, Radhika R CIV (US) wrote: > > Folks: > > > > I have another point to explain: > > > > +------------+-----------+ > > | Priority | Reference | > > +------------+-----------+ > > | non-urgent | RFC 3261 | > > | normal | RFC 3261 | > > | urgent | RFC 3261 | > > | emergency | RFC 3261 | > > +------------+-----------+ > > > > The definition of each value needs to be provided. >=20 > I would argue that that's what the "Reference" column is for. The > technical > description of what a priority means may be somewhat complicated or > include > some subtle points that would require more text than would be appropriate > for a registry. >=20 > > It is not clear how one label will differ with all others. >=20 > And that's why you need to look at RFC 3261. It explains the difference. > In particular, read section 20.26. >=20 > > Also, come confusions arise with respect when priority labels are > > applied related to call, media, and others. >=20 > Priority... labels... media? What? >=20 > > RFCs 4411 and 4412, 5478, 6433, 6061, 5031, and 3689 need to be seen > > for some guidance before explaining the labels so that terminologies > > and definitions do not overlap or contradict. >=20 > Aha! I think I see the confusion. You've mixed up "Priority" (RFC 3261, > section 20.26) with "Resource-Priority" (RFC 4412). >=20 > Please carefully read RFC 3261 section 20.26 and reconsider your comments= . > Thanks. >=20 > /a From jgunn6@csc.com Wed Nov 7 17:06:39 2012 Return-Path: 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 68A1A21F8A12; Wed, 7 Nov 2012 17:06:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.146 X-Spam-Level: X-Spam-Status: No, score=-6.146 tagged_above=-999 required=5 tests=[AWL=0.452, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] 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 oIai0wIZOnHk; Wed, 7 Nov 2012 17:06:38 -0800 (PST) Received: from mail171.messagelabs.com (mail171.messagelabs.com [216.82.253.243]) by ietfa.amsl.com (Postfix) with ESMTP id 1E68121F8B26; Wed, 7 Nov 2012 17:06:30 -0800 (PST) X-Env-Sender: jgunn6@csc.com X-Msg-Ref: server-9.tower-171.messagelabs.com!1352336789!15190436!1 X-Originating-IP: [20.137.2.87] X-StarScan-Received: X-StarScan-Version: 6.6.1.8; banners=-,-,- X-VirusChecked: Checked Received: (qmail 1250 invoked from network); 8 Nov 2012 01:06:30 -0000 Received: from amer-mta101.csc.com (HELO amer-mta101.csc.com) (20.137.2.87) by server-9.tower-171.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 8 Nov 2012 01:06:30 -0000 Received: from amer-gw09.amer.csc.com (amer-gw09.amer.csc.com [20.6.39.245]) by amer-mta101.csc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id qA816SKj013483; Wed, 7 Nov 2012 20:06:28 -0500 In-Reply-To: References: <50993285.4020408@nostrum.com> <8486C8728176924BAF5BDB2F7D7EEDDF48652767@ucolhp9h.easf.csd.disa.mil> <50997809.7050306@nostrum.com> <8486C8728176924BAF5BDB2F7D7EEDDF4865824D@ucolhp9h.easf.csd.disa.mil> To: "DRAGE, Keith (Keith)" MIME-Version: 1.0 X-KeepSent: AA60F043:B7829E57-85257AB0:00052424; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.2FP4 SHF97 March 26, 2012 From: Janet P Gunn Message-ID: Date: Wed, 7 Nov 2012 20:05:48 -0500 X-MIMETrack: Serialize by Router on AMER-GW09/SRV/CSC(Release 8.5.2FP3 HF204|September 20, 2011) at 11/07/2012 08:01:56 PM, Serialize complete at 11/07/2012 08:01:56 PM Content-Type: multipart/alternative; boundary="=_alternative 0006087985257AB0_=" Cc: "Roy, Radhika R CIV \(US\)" , "sipcore@ietf.org" , sipcore-bounces@ietf.org 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Nov 2012 01:06:39 -0000 This is a multipart message in MIME format. --=_alternative 0006087985257AB0_= Content-Type: text/plain; charset="US-ASCII" I agree. the SIP Priority header is only used by the destination user or application. It does not affect on SIP processing. That is why we needed to develop SIP Resource- Priority. The distinction between "Priority" and "Resource-Priority" is described in Section 1 (Introduction) of RFC 4412. Janet From: "DRAGE, Keith (Keith)" To: "Roy, Radhika R CIV (US)" , Adam Roach Cc: "sipcore@ietf.org" Date: 11/07/2012 07:46 PM Subject: Re: [sipcore] Establishing a "Priority" header field registry Sent by: sipcore-bounces@ietf.org The Priority header field is rendered to the user or recipient application, and in my view has no impact on the SIP processing directly. The Resource-Priority header field can impact usage of signaling resources themselves, media resources and access resources. It does not necessarily impact all of these, and which it impacts is defined by the namespaces used, and how those namespaces are implemented in individual operators domains. Regards Keith > -----Original Message----- > From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behalf > Of Roy, Radhika R CIV (US) > Sent: 07 November 2012 15:07 > To: Adam Roach > Cc: sipcore@ietf.org > Subject: Re: [sipcore] Establishing a "Priority" header field registry > > Hi, Adam: > > You are right that you are referring to RFC 3261 semantics that also refer > to RFC 2976. > > It is the SIP call level priority, that is, how a given call will be > handled > with relative to other calls. > > The issues that I have been trying to relate are the following: > > 1. Other RFCs that I referred also deal with call level priority including > emergency calls. > > 2. A SIP call also contain media: Audio, Video, and/or Data. > > 3. Other RFCs also deal with resources priority that include media. > > Did anyone ever try to relate all these priority semantics from the SIP > call > to the media level knowing the semantics of all priority headers? > > BR/Radhika > > -----Original Message----- > From: Adam Roach [mailto:adam@nostrum.com] > Sent: Tuesday, November 06, 2012 3:50 PM > To: Roy, Radhika R CIV (US) > Cc: sipcore@ietf.org > Subject: Re: [sipcore] Establishing a "Priority" header field registry > > [as an individual] > > On 11/6/12 15:12, Roy, Radhika R CIV (US) wrote: > > Folks: > > > > I have another point to explain: > > > > +------------+-----------+ > > | Priority | Reference | > > +------------+-----------+ > > | non-urgent | RFC 3261 | > > | normal | RFC 3261 | > > | urgent | RFC 3261 | > > | emergency | RFC 3261 | > > +------------+-----------+ > > > > The definition of each value needs to be provided. > > I would argue that that's what the "Reference" column is for. The > technical > description of what a priority means may be somewhat complicated or > include > some subtle points that would require more text than would be appropriate > for a registry. > > > It is not clear how one label will differ with all others. > > And that's why you need to look at RFC 3261. It explains the difference. > In particular, read section 20.26. > > > Also, come confusions arise with respect when priority labels are > > applied related to call, media, and others. > > Priority... labels... media? What? > > > RFCs 4411 and 4412, 5478, 6433, 6061, 5031, and 3689 need to be seen > > for some guidance before explaining the labels so that terminologies > > and definitions do not overlap or contradict. > > Aha! I think I see the confusion. You've mixed up "Priority" (RFC 3261, > section 20.26) with "Resource-Priority" (RFC 4412). > > Please carefully read RFC 3261 section 20.26 and reconsider your comments. > Thanks. > > /a _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore --=_alternative 0006087985257AB0_= Content-Type: text/html; charset="US-ASCII" I agree.  the SIP Priority header is only used by the destination user or application.  It does not affect on SIP processing.

That is why we needed to develop SIP Resource- Priority.

The distinction between "Priority" and "Resource-Priority" is described in Section 1 (Introduction) of RFC 4412.

Janet



From:        "DRAGE, Keith (Keith)" <keith.drage@alcatel-lucent.com>
To:        "Roy, Radhika R CIV (US)" <radhika.r.roy.civ@mail.mil>, Adam Roach <adam@nostrum.com>
Cc:        "sipcore@ietf.org" <sipcore@ietf.org>
Date:        11/07/2012 07:46 PM
Subject:        Re: [sipcore] Establishing a "Priority" header field registry
Sent by:        sipcore-bounces@ietf.org



The Priority header field is rendered to the user or recipient application, and in my view has no impact on the SIP processing directly.

The Resource-Priority header field can impact usage of signaling resources themselves, media resources and access resources. It does not necessarily impact all of these, and which it impacts is defined by the namespaces used, and how those namespaces are implemented in individual operators domains.

Regards

Keith

> -----Original Message-----
> From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behalf
> Of Roy, Radhika R CIV (US)
> Sent: 07 November 2012 15:07
> To: Adam Roach
> Cc: sipcore@ietf.org
> Subject: Re: [sipcore] Establishing a "Priority" header field registry
>
> Hi, Adam:
>
> You are right that you are referring to RFC 3261 semantics that also refer
> to RFC 2976.
>
> It is the SIP call level priority, that is, how a given call will be
> handled
> with relative to other calls.
>
> The issues that I have been trying to relate are the following:
>
> 1. Other RFCs that I referred also deal with call level priority including
> emergency calls.
>
> 2. A SIP call also contain media: Audio, Video, and/or Data.
>
> 3. Other RFCs also deal with resources priority that include media.
>
> Did anyone ever try to relate all these priority semantics from the SIP
> call
> to the media level knowing the semantics of all priority headers?
>
> BR/Radhika
>
> -----Original Message-----
> From: Adam Roach [mailto:adam@nostrum.com]
> Sent: Tuesday, November 06, 2012 3:50 PM
> To: Roy, Radhika R CIV (US)
> Cc: sipcore@ietf.org
> Subject: Re: [sipcore] Establishing a "Priority" header field registry
>
> [as an individual]
>
> On 11/6/12 15:12, Roy, Radhika R CIV (US) wrote:
> > Folks:
> >
> > I have another point to explain:
> >
> >                          +------------+-----------+
> >                          | Priority   | Reference |
> >                          +------------+-----------+
> >                          | non-urgent | RFC 3261  |
> >                          | normal     | RFC 3261  |
> >                          | urgent     | RFC 3261  |
> >                          | emergency  | RFC 3261  |
> >                          +------------+-----------+
> >
> > The definition of each value needs to be provided.
>
> I would argue that that's what the "Reference" column is for. The
> technical
> description of what a priority means may be somewhat complicated or
> include
> some subtle points that would require more text than would be appropriate
> for a registry.
>
> > It is not clear how one label will differ with all others.
>
> And that's why you need to look at RFC 3261. It explains the difference.
> In particular, read section 20.26.
>
> > Also, come confusions arise with respect when priority labels are
> > applied related to call, media, and others.
>
> Priority... labels... media? What?
>
> > RFCs 4411 and 4412, 5478, 6433, 6061, 5031, and 3689 need to be seen
> > for some guidance before explaining the labels so that terminologies
> > and definitions do not overlap or contradict.
>
> Aha! I think I see the confusion. You've mixed up "Priority" (RFC 3261,
> section 20.26) with "Resource-Priority" (RFC 4412).
>
> Please carefully read RFC 3261 section 20.26 and reconsider your comments.
> Thanks.
>
> /a
_______________________________________________
sipcore mailing list
sipcore@ietf.org
https://www.ietf.org/mailman/listinfo/sipcore
--=_alternative 0006087985257AB0_=-- From jmpolk@cisco.com Wed Nov 7 19:22:15 2012 Return-Path: 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 AA9AE21F8A72 for ; Wed, 7 Nov 2012 19:22:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.568 X-Spam-Level: X-Spam-Status: No, score=-110.568 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 wSA4pikK3kOb for ; Wed, 7 Nov 2012 19:22:15 -0800 (PST) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id D4C2121F8A69 for ; Wed, 7 Nov 2012 19:22:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4103; q=dns/txt; s=iport; t=1352344935; x=1353554535; h=message-id:date:to:from:subject:cc:in-reply-to: references:mime-version; bh=oTiEqt54MQQULzC17muqpDmd1uSMvv9el9m8LRxddoM=; b=G/c0L7ohoiOO3w4WTl7tLIuxYftWOfaNW5aw1zTrZFzFhGRwXdKnRHV7 faHsDjur9uqrieLoCkH23WiSCx95EYOKMjR5LCQsW7k22O0UdHAWsvyas Voishy8GwrJLPLWup9aLruPg/Fi4zasVXlZImsPJYZ6Q6P2L93meEGk16 w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAD8km1CtJXG+/2dsb2JhbABEw2qBCIIeAQEBBAEBAQ8BJQI0CwwEBwQRBAEBAR4JBxkOHwkIBgESIodoC5xmoC8EjA2GRwOIWpt6gWuDDg X-IronPort-AV: E=Sophos;i="4.80,735,1344211200"; d="scan'208";a="139974365" Received: from rcdn-core2-3.cisco.com ([173.37.113.190]) by rcdn-iport-7.cisco.com with ESMTP; 08 Nov 2012 03:22:13 +0000 Received: from jmpolk-WS.cisco.com (rtp-vpn2-158.cisco.com [10.82.240.158]) (authenticated bits=0) by rcdn-core2-3.cisco.com (8.14.5/8.14.5) with ESMTP id qA83M90O012355 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 8 Nov 2012 03:22:13 GMT Message-Id: <201211080322.qA83M90O012355@rcdn-core2-3.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 07 Nov 2012 21:22:09 -0600 To: "DRAGE, Keith (Keith)" , "Roy, Radhika R CIV (US)" , Adam Roach From: James Polk In-Reply-To: References: <50993285.4020408@nostrum.com> <8486C8728176924BAF5BDB2F7D7EEDDF48652767@ucolhp9h.easf.csd.disa.mil> <50997809.7050306@nostrum.com> <8486C8728176924BAF5BDB2F7D7EEDDF4865824D@ucolhp9h.easf.csd.disa.mil> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Authenticated-User: jmpolk Cc: "sipcore@ietf.org" 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Nov 2012 03:22:15 -0000 The SIP Priority header has zero impact on message processing, it's all for what the sending user believes is the importance of that call to the destination user; nothing more. This is why RFC 4412 was written - to have an impact, when used and supported, on message processing. James At 06:46 PM 11/7/2012, DRAGE, Keith (Keith) wrote: >The Priority header field is rendered to the user or recipient >application, and in my view has no impact on the SIP processing directly. > >The Resource-Priority header field can impact usage of signaling >resources themselves, media resources and access resources. It does >not necessarily impact all of these, and which it impacts is defined >by the namespaces used, and how those namespaces are implemented in >individual operators domains. > >Regards > >Keith > > > -----Original Message----- > > From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behalf > > Of Roy, Radhika R CIV (US) > > Sent: 07 November 2012 15:07 > > To: Adam Roach > > Cc: sipcore@ietf.org > > Subject: Re: [sipcore] Establishing a "Priority" header field registry > > > > Hi, Adam: > > > > You are right that you are referring to RFC 3261 semantics that also refer > > to RFC 2976. > > > > It is the SIP call level priority, that is, how a given call will be > > handled > > with relative to other calls. > > > > The issues that I have been trying to relate are the following: > > > > 1. Other RFCs that I referred also deal with call level priority including > > emergency calls. > > > > 2. A SIP call also contain media: Audio, Video, and/or Data. > > > > 3. Other RFCs also deal with resources priority that include media. > > > > Did anyone ever try to relate all these priority semantics from the SIP > > call > > to the media level knowing the semantics of all priority headers? > > > > BR/Radhika > > > > -----Original Message----- > > From: Adam Roach [mailto:adam@nostrum.com] > > Sent: Tuesday, November 06, 2012 3:50 PM > > To: Roy, Radhika R CIV (US) > > Cc: sipcore@ietf.org > > Subject: Re: [sipcore] Establishing a "Priority" header field registry > > > > [as an individual] > > > > On 11/6/12 15:12, Roy, Radhika R CIV (US) wrote: > > > Folks: > > > > > > I have another point to explain: > > > > > > +------------+-----------+ > > > | Priority | Reference | > > > +------------+-----------+ > > > | non-urgent | RFC 3261 | > > > | normal | RFC 3261 | > > > | urgent | RFC 3261 | > > > | emergency | RFC 3261 | > > > +------------+-----------+ > > > > > > The definition of each value needs to be provided. > > > > I would argue that that's what the "Reference" column is for. The > > technical > > description of what a priority means may be somewhat complicated or > > include > > some subtle points that would require more text than would be appropriate > > for a registry. > > > > > It is not clear how one label will differ with all others. > > > > And that's why you need to look at RFC 3261. It explains the difference. > > In particular, read section 20.26. > > > > > Also, come confusions arise with respect when priority labels are > > > applied related to call, media, and others. > > > > Priority... labels... media? What? > > > > > RFCs 4411 and 4412, 5478, 6433, 6061, 5031, and 3689 need to be seen > > > for some guidance before explaining the labels so that terminologies > > > and definitions do not overlap or contradict. > > > > Aha! I think I see the confusion. You've mixed up "Priority" (RFC 3261, > > section 20.26) with "Resource-Priority" (RFC 4412). > > > > Please carefully read RFC 3261 section 20.26 and reconsider your comments. > > Thanks. > > > > /a >_______________________________________________ >sipcore mailing list >sipcore@ietf.org >https://www.ietf.org/mailman/listinfo/sipcore From acmorton@att.com Sun Nov 11 09:25:37 2012 Return-Path: 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 C71AD21F855B; Sun, 11 Nov 2012 09:25:37 -0800 (PST) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "Message-ID" X-Spam-Flag: NO X-Spam-Score: -106.34 X-Spam-Level: X-Spam-Status: No, score=-106.34 tagged_above=-999 required=5 tests=[AWL=0.259, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 CZ8nqdvmFvmI; Sun, 11 Nov 2012 09:25:36 -0800 (PST) Received: from nbfkord-smmo06.seg.att.com (nbfkord-smmo06.seg.att.com [209.65.160.94]) by ietfa.amsl.com (Postfix) with ESMTP id 3149F21F853A; Sun, 11 Nov 2012 09:25:36 -0800 (PST) Received: from unknown [144.160.20.145] (EHLO mlpd192.enaf.sfdc.sbc.com) by nbfkord-smmo06.seg.att.com(mxl_mta-6.11.0-12) over TLS secured channel with ESMTP id f8fdf905.0.70982.00-482.179485.nbfkord-smmo06.seg.att.com (envelope-from ); Sun, 11 Nov 2012 17:25:36 +0000 (UTC) X-MXL-Hash: 509fdf902cd2c168-3f0d1aabad6fce3f5decfcb4a984a159804f50a6 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id qABHPY1n010780; Sun, 11 Nov 2012 12:25:35 -0500 Received: from sflint02.pst.cso.att.com (sflint02.pst.cso.att.com [144.154.234.229]) by mlpd192.enaf.sfdc.sbc.com (8.14.5/8.14.5) with ESMTP id qABHPOT2010614 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 11 Nov 2012 12:25:27 -0500 Received: from alpd052.aldc.att.com (alpd052.aldc.att.com [130.8.42.31]) by sflint02.pst.cso.att.com (RSA Interceptor); Sun, 11 Nov 2012 08:48:05 -0500 Received: from aldc.att.com (localhost.localdomain [127.0.0.1]) by alpd052.aldc.att.com (8.14.4/8.14.4) with ESMTP id qABDkeQ9014874; Sun, 11 Nov 2012 08:46:40 -0500 Received: from dns.maillennium.att.com (maillennium.att.com [135.25.114.99]) by alpd052.aldc.att.com (8.14.4/8.14.4) with ESMTP id qABDkUxU014757; Sun, 11 Nov 2012 08:46:35 -0500 Received: from lt-hp1044652.att.com (vpn-135-70-71-120.vpn.swst.att.com[135.70.71.120](misconfigured sender)) by maillennium.att.com (mailgw1) with SMTP id <20121111134649gw10063302e>; Sun, 11 Nov 2012 13:46:49 +0000 X-Originating-IP: [135.70.71.120] Message-Id: <7.0.1.0.0.20121111082840.09070110@att.com> Message-Id: <7.1.0.9.0.20120419144130.0225fca8@att.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Sun, 11 Nov 2012 08:45:00 -0500 To: bmwg@ietf.org From: Al Morton Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-RSA-Inspected: yes X-RSA-Classifications: public X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.20.145] X-AnalysisOut: [v=2.0 cv=VI9qaazX c=1 sm=0 a=ZRNLZ4dFUbCvG8UMqPvVAA==:17 a] X-AnalysisOut: [=rgbTadvDeT8A:10 a=oGaApbiJSAcA:10 a=ofMgfj31e3cA:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=kj9zAlcOel0A:10 a=zQP7CpKOAAAA:8 a=9BMhzaEi] X-AnalysisOut: [eWIA:10 a=48vgC7mUAAAA:8 a=EvCAPxRZiaC5j925DkUA:9 a=CjuIK1] X-AnalysisOut: [q_8ugA:10 a=qg_hPROt29YA:10 a=Hz7IrDYlS0cA:10 a=NWVoK91CQy] X-AnalysisOut: [QA:10] X-Mailman-Approved-At: Sun, 11 Nov 2012 09:57:02 -0800 Cc: "Worley, Dale R \(Dale\)" , sipcore@ietf.org Subject: [sipcore] WGLC on SIP Benchmarking Drafts (04) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Nov 2012 17:25:37 -0000 TO: BMWG, CC: RAI Dir Reviewer Dale Worley, sipcore wg, A WG Last Call period for the Internet-Drafts on SIP Device Benchmarking: http://datatracker.ietf.org/doc/draft-ietf-bmwg-sip-bench-term/ http://datatracker.ietf.org/doc/draft-ietf-bmwg-sip-bench-meth/ will be open from 11 Nov 2012 through 10 Dec 2012. These drafts are continuing the BMWG Last Call Process. See http://www1.ietf.org/mail-archive/web/bmwg/current/msg00846.html The first WGLC was completed on 5 April 2010 with comments. The second WGLC was completed on 18 May 2012 with comments. Please read and express your opinion on whether or not these Internet-Drafts should be forwarded to the Area Directors for publication as Informational RFCs. Send your comments to this list or acmorton@att.com Al bmwg chair From acmorton@att.com Sun Nov 11 14:14:43 2012 Return-Path: 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 13C6B21F84E6; Sun, 11 Nov 2012 14:14:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.361 X-Spam-Level: X-Spam-Status: No, score=-106.361 tagged_above=-999 required=5 tests=[AWL=0.238, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 wQrYSVftdwWH; Sun, 11 Nov 2012 14:14:42 -0800 (PST) Received: from nbfkord-smmo08.seg.att.com (nbfkord-smmo08.seg.att.com [209.65.160.95]) by ietfa.amsl.com (Postfix) with ESMTP id 26E2B21F84DF; Sun, 11 Nov 2012 14:14:42 -0800 (PST) Received: from unknown [144.160.128.153] (EHLO flpi408.enaf.ffdc.sbc.com) by nbfkord-smmo08.seg.att.com(mxl_mta-6.11.0-12) over TLS secured channel with ESMTP id 15320a05.0.113279.00-452.294732.nbfkord-smmo08.seg.att.com (envelope-from ); Sun, 11 Nov 2012 22:14:42 +0000 (UTC) X-MXL-Hash: 50a0235268c3c11a-1ddb66dbc4742be3aa9333c3ea50e0ab7aa8f902 Received: from enaf.ffdc.sbc.com (localhost.localdomain [127.0.0.1]) by flpi408.enaf.ffdc.sbc.com (8.14.5/8.14.5) with ESMTP id qABMEem5002853; Sun, 11 Nov 2012 14:14:41 -0800 Received: from fflint04.pst.cso.att.com (fflint04.pst.cso.att.com [150.234.39.64]) by flpi408.enaf.ffdc.sbc.com (8.14.5/8.14.5) with ESMTP id qABMEYla002821 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 11 Nov 2012 14:14:35 -0800 Received: from alpd052.aldc.att.com (alpd052.aldc.att.com [130.8.42.31]) by fflint04.pst.cso.att.com (RSA Interceptor); Sun, 11 Nov 2012 14:14:16 -0800 Received: from aldc.att.com (localhost.localdomain [127.0.0.1]) by alpd052.aldc.att.com (8.14.4/8.14.4) with ESMTP id qABMEG2v004589; Sun, 11 Nov 2012 17:14:16 -0500 Received: from mailgw1.maillennium.att.com (maillennium.att.com [135.25.114.99]) by alpd052.aldc.att.com (8.14.4/8.14.4) with ESMTP id qABME1uk004377; Sun, 11 Nov 2012 17:14:10 -0500 Received: from lt-hp1044652.att.com (vpn-135-70-207-18.vpn.east.att.com[135.70.207.18](misconfigured sender)) by maillennium.att.com (mailgw1) with SMTP id <20121111221420gw1006328se>; Sun, 11 Nov 2012 22:14:21 +0000 X-Originating-IP: [135.70.207.18] Message-Id: <7.0.1.0.0.20121111171100.04d17eb0@att.com> X-Mailer: QUALCOMM Windows Eudora Version 7.0.1.0 Date: Sun, 11 Nov 2012 17:12:30 -0500 To: bmwg@ietf.org From: Al Morton In-Reply-To: <7.0.1.0.0.20121111082840.09070110@att.com> References: <7.0.1.0.0.20121111082840.09070110@att.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-RSA-Inspected: yes X-RSA-Classifications: public X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.128.153] X-AnalysisOut: [v=2.0 cv=N+ee4RBB c=1 sm=0 a=xwOvzTHDVLE4u4nGvK72ag==:17 a] X-AnalysisOut: [=lwiFHQTfgUAA:10 a=W2hlYBC8_kYA:10 a=ofMgfj31e3cA:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=kj9zAlcOel0A:10 a=zQP7CpKOAAAA:8 a=e1xCkD5h] X-AnalysisOut: [TCUA:10 a=48vgC7mUAAAA:8 a=Gk4fFlnYBuJkGfQiNC4A:9 a=CjuIK1] X-AnalysisOut: [q_8ugA:10 a=qg_hPROt29YA:10 a=Hz7IrDYlS0cA:10 a=lZB815dzVv] X-AnalysisOut: [QA:10 a=NWVoK91CQyQA:10] Cc: worley@ariadne.com, sipcore@ietf.org Subject: Re: [sipcore] [bmwg] WGLC on SIP Benchmarking Drafts (04) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Nov 2012 22:14:43 -0000 Re-sending to Dale's new address. At 08:45 AM 11/11/2012, Al Morton wrote: >TO: BMWG, >CC: RAI Dir Reviewer Dale Worley, sipcore wg, > >A WG Last Call period for the Internet-Drafts on SIP Device >Benchmarking: > > http://datatracker.ietf.org/doc/draft-ietf-bmwg-sip-bench-term/ > http://datatracker.ietf.org/doc/draft-ietf-bmwg-sip-bench-meth/ > >will be open from 11 Nov 2012 through 10 Dec 2012. > >These drafts are continuing the BMWG Last Call Process. See >http://www1.ietf.org/mail-archive/web/bmwg/current/msg00846.html >The first WGLC was completed on 5 April 2010 with comments. >The second WGLC was completed on 18 May 2012 with comments. > >Please read and express your opinion on whether or not these >Internet-Drafts should be forwarded to the Area Directors for >publication as Informational RFCs. Send your comments >to this list or acmorton@att.com > >Al >bmwg chair >_______________________________________________ >bmwg mailing list >bmwg@ietf.org >https://www.ietf.org/mailman/listinfo/bmwg From pkyzivat@alum.mit.edu Mon Nov 12 12:49:31 2012 Return-Path: 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 387DD21F877C for ; Mon, 12 Nov 2012 12:49:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.382 X-Spam-Level: X-Spam-Status: No, score=-0.382 tagged_above=-999 required=5 tests=[AWL=0.055, 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 wI9oVCZf+J5X for ; Mon, 12 Nov 2012 12:49:30 -0800 (PST) Received: from qmta12.westchester.pa.mail.comcast.net (qmta12.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:227]) by ietfa.amsl.com (Postfix) with ESMTP id AF0EF21F8765 for ; Mon, 12 Nov 2012 12:49:30 -0800 (PST) Received: from omta12.westchester.pa.mail.comcast.net ([76.96.62.44]) by qmta12.westchester.pa.mail.comcast.net with comcast id NjKA1k0030xGWP85CkpWzc; Mon, 12 Nov 2012 20:49:30 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta12.westchester.pa.mail.comcast.net with comcast id NkpV1k00c3ZTu2S3YkpVhw; Mon, 12 Nov 2012 20:49:30 +0000 Message-ID: <50A160D8.8030602@alum.mit.edu> Date: Mon, 12 Nov 2012 15:49:28 -0500 From: Paul Kyzivat 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 , sipcore-ads@tools.ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Nov 2012 20:49:31 -0000 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 From christer.holmberg@ericsson.com Mon Nov 12 13:52:44 2012 Return-Path: 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 A140D21F8625 for ; Mon, 12 Nov 2012 13:52:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] 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 ng6E2Prw42l6 for ; Mon, 12 Nov 2012 13:52:44 -0800 (PST) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 83F9721F844C for ; Mon, 12 Nov 2012 13:52:43 -0800 (PST) X-AuditID: c1b4fb30-b7f936d0000018b3-6d-50a16faab496 Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 08.2A.06323.AAF61A05; Mon, 12 Nov 2012 22:52:42 +0100 (CET) Received: from ESESSHC002.ericsson.se (153.88.183.24) by esessmw0256.eemea.ericsson.se (153.88.115.96) with Microsoft SMTP Server (TLS) id 8.3.279.1; Mon, 12 Nov 2012 22:52:42 +0100 Received: from ESESSMB209.ericsson.se ([169.254.9.182]) by ESESSHC002.ericsson.se ([153.88.183.24]) with mapi id 14.02.0318.001; Mon, 12 Nov 2012 22:52:41 +0100 From: Christer Holmberg To: Paul Kyzivat , SIPCORE , "sipcore-ads@tools.ietf.org" Thread-Topic: [sipcore] Proposal: Call for adoption & WGLC: draft-roach-sipcore-priority-00 Thread-Index: AQHNwRc5D5NKZt/KZ0Gbr0k4dSgPfpfmvW2z Date: Mon, 12 Nov 2012 21:52:41 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B02AD26@ESESSMB209.ericsson.se> References: <50A160D8.8030602@alum.mit.edu> In-Reply-To: <50A160D8.8030602@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.17] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrILMWRmVeSWpSXmKPExsUyM+Jvje6q/IUBBpP2SVus2HCA1WLaSWeL rz82sTkwe/x9/4HJY8mSn0weXy5/ZgtgjuKySUnNySxLLdK3S+DKOHTtJUtBu3DFvDdf2RsY l/J3MXJySAiYSCx794UZwhaTuHBvPVsXIxeHkMBJRolJjdcYIZydjBKv+xcwQThLGCW2T90C 5HBwsAlYSHT/0waJiwg0Mkqc/dnOChIXFoiRuDdLGmSqiECsxKT7L9khbCOJNefng21jEVCV uPbuBZjNK+At8ervMzBbSEBbounPBiYQm1NAR+LT/9lsIDYj0HXfT60BizMLiEvcejKfCeJq AYkle85DfSAq8fLxP7ATJAQUJZb3y0GU60gs2P2JDcLWlli28DXUWkGJkzOfsMCsbVk8gX0C o/gsJBtmIWmfhaR9FpL2BYwsqxjZcxMzc9LLzTcxAqPp4JbfBjsYN90XO8QozcGiJM6rp7rf X0ggPbEkNTs1tSC1KL6oNCe1+BAjEwenVAOjZrtc7owzJwUf3rFXfrShfs0DyTDee2rfo0Ry 9IT1q+XYHjFdF3gfelp0ck7hP0me+elMSnWfnqyK6IyO3nXEQDXh5OW0WRIuZYu2pPgXX3J1 /Xd9woe2L/d2q308pDLDZHfanV2/ZTLuvXp81/cel/WJuzOOBIXLHFz7LNA3eJrastKndSGx SizFGYmGWsxFxYkADQl+wXQCAAA= 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Nov 2012 21:52:44 -0000 Hi, I support the adoption. As I have indicated before, I think there should be some kind of template f= or the registration. Regards, Christer ________________________________________ From: sipcore-bounces@ietf.org [sipcore-bounces@ietf.org] on behalf of Paul= Kyzivat [pkyzivat@alum.mit.edu] Sent: Monday, 12 November 2012 10: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 From pkyzivat@alum.mit.edu Mon Nov 12 14:33:19 2012 Return-Path: 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 B557B21F877E for ; Mon, 12 Nov 2012 14:33:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.384 X-Spam-Level: X-Spam-Status: No, score=-0.384 tagged_above=-999 required=5 tests=[AWL=0.053, 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 wde0w81WG31q for ; Mon, 12 Nov 2012 14:33:15 -0800 (PST) Received: from qmta15.westchester.pa.mail.comcast.net (qmta15.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:228]) by ietfa.amsl.com (Postfix) with ESMTP id D8D6C21F8625 for ; Mon, 12 Nov 2012 14:33:14 -0800 (PST) Received: from omta12.westchester.pa.mail.comcast.net ([76.96.62.44]) by qmta15.westchester.pa.mail.comcast.net with comcast id Ncav1k0030xGWP85FmZEwx; Mon, 12 Nov 2012 22:33:14 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta12.westchester.pa.mail.comcast.net with comcast id NmZD1k00d3ZTu2S3YmZDsv; Mon, 12 Nov 2012 22:33:14 +0000 Message-ID: <50A17929.5060005@alum.mit.edu> Date: Mon, 12 Nov 2012 17:33:13 -0500 From: Paul Kyzivat 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: Christer Holmberg References: <50A160D8.8030602@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B02AD26@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B02AD26@ESESSMB209.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: SIPCORE , "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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Nov 2012 22:33:19 -0000 On 11/12/12 4:52 PM, Christer Holmberg wrote: > > Hi, > > I support the adoption. > > As I have indicated before, I think there should be some kind of template for the registration. I guess that means you aren't ready to approve it. Can you suggest some text? Thanks, Paul > Regards, > > Christer > > ________________________________________ > From: sipcore-bounces@ietf.org [sipcore-bounces@ietf.org] on behalf of Paul Kyzivat [pkyzivat@alum.mit.edu] > Sent: Monday, 12 November 2012 10: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 > From keith.drage@alcatel-lucent.com Mon Nov 12 14:46:57 2012 Return-Path: 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 8994D21F862E for ; Mon, 12 Nov 2012 14:46:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.038 X-Spam-Level: X-Spam-Status: No, score=-110.038 tagged_above=-999 required=5 tests=[AWL=0.211, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8, 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 r-LLad9TWNG5 for ; Mon, 12 Nov 2012 14:46:56 -0800 (PST) Received: from smail3.alcatel.fr (smail3.alcatel.fr [64.208.49.56]) by ietfa.amsl.com (Postfix) with ESMTP id 5FD6121F8626 for ; Mon, 12 Nov 2012 14:46:55 -0800 (PST) Received: from FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (FRMRSSXCHHUB01.dc-m.alcatel-lucent.com [135.120.45.61]) by smail3.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id qACMkmVj012087 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 12 Nov 2012 23:46:49 +0100 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.46]) by FRMRSSXCHHUB01.dc-m.alcatel-lucent.com ([135.120.45.61]) with mapi; Mon, 12 Nov 2012 23:46:48 +0100 From: "DRAGE, Keith (Keith)" To: Paul Kyzivat , Christer Holmberg Date: Mon, 12 Nov 2012 23:46:47 +0100 Thread-Topic: [sipcore] Proposal: Call for adoption & WGLC: draft-roach-sipcore-priority-00 Thread-Index: Ac3BJbt9IvsKGBidSsuMFBnEc/Yy3wAAce4g Message-ID: References: <50A160D8.8030602@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B02AD26@ESESSMB209.ericsson.se> <50A17929.5060005@alum.mit.edu> In-Reply-To: <50A17929.5060005@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.83 Cc: SIPCORE , "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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Nov 2012 22:46:57 -0000 It might also be appropriate to answer the points I made in response, rathe= r than just repeating the demand. Keith > -----Original Message----- > From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behal= f > Of Paul Kyzivat > Sent: 12 November 2012 22:33 > To: Christer Holmberg > Cc: SIPCORE; sipcore-ads@tools.ietf.org > Subject: Re: [sipcore] Proposal: Call for adoption & WGLC: draft-roach- > sipcore-priority-00 >=20 > On 11/12/12 4:52 PM, Christer Holmberg wrote: > > > > Hi, > > > > I support the adoption. > > > > As I have indicated before, I think there should be some kind of > template for the registration. >=20 > I guess that means you aren't ready to approve it. > Can you suggest some text? >=20 > Thanks, > Paul >=20 > > Regards, > > > > Christer > > > > ________________________________________ > > From: sipcore-bounces@ietf.org [sipcore-bounces@ietf.org] on behalf of > Paul Kyzivat [pkyzivat@alum.mit.edu] > > Sent: Monday, 12 November 2012 10: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 fo= r > > 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" heade= r > > 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 > > >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From christer.holmberg@ericsson.com Mon Nov 12 14:54:26 2012 Return-Path: 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 8EC2321F85A8 for ; Mon, 12 Nov 2012 14:54:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] 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 NiZvoCB7HOao for ; Mon, 12 Nov 2012 14:54:25 -0800 (PST) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 3D7F421F860C for ; Mon, 12 Nov 2012 14:54:18 -0800 (PST) X-AuditID: c1b4fb30-b7f936d0000018b3-06-50a17e183af7 Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id D2.9D.06323.81E71A05; Mon, 12 Nov 2012 23:54:16 +0100 (CET) Received: from ESESSHC024.ericsson.se (153.88.183.90) by esessmw0247.eemea.ericsson.se (153.88.115.93) with Microsoft SMTP Server (TLS) id 8.3.279.1; Mon, 12 Nov 2012 23:54:16 +0100 Received: from ESESSMB209.ericsson.se ([169.254.9.182]) by ESESSHC024.ericsson.se ([153.88.183.90]) with mapi id 14.02.0318.001; Mon, 12 Nov 2012 23:54:15 +0100 From: Christer Holmberg To: Paul Kyzivat Thread-Topic: [sipcore] Proposal: Call for adoption & WGLC: draft-roach-sipcore-priority-00 Thread-Index: AQHNwSW4bT4YM/PVGE+kks/ieQdR5ZfmzmOz Date: Mon, 12 Nov 2012 22:54:15 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B02AE7E@ESESSMB209.ericsson.se> References: <50A160D8.8030602@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B02AD26@ESESSMB209.ericsson.se>, <50A17929.5060005@alum.mit.edu> In-Reply-To: <50A17929.5060005@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.17] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrNLMWRmVeSWpSXmKPExsUyM+Jvja5E3cIAg4srpSxWbDjAajHtpLPF 1x+b2ByYPf6+/8DksWTJTyaPL5c/swUwR3HZpKTmZJalFunbJXBl7G1oYSy4Kl7x+9cltgbG o0JdjJwcEgImEgsPzWSGsMUkLtxbz9bFyMUhJHCSUeLWu+1gCSGBnYwSFy+WQiSWMEo0n/vP 2sXIwcEmYCHR/U8bxBQR0JCYtFUNpJxZIFpi7uo9LCC2sECMRNPF7+wQJbESj9v0QMIiAkYS h5esZAWxWQRUJTaf+gG2iVfAW2L5y2OsEJt6GSXaVn5gBElwCuhI9FyfyAZiMwLd+f3UGiaI XeISt57MZ4K4X0BiyZ7zUL+ISrx8/A/sSgkBRYnl/XIQ5ToSC3Z/YoOwtSWWLXwNtVdQ4uTM JywQ32pLtCyewD6BUWIWkg2zkLTPQtI+C0n7AkaWVYzsuYmZOenl5psYgRF2cMtvgx2Mm+6L HWKU5mBREufVU93vLySQnliSmp2aWpBaFF9UmpNafIiRiYNTqoGx8r/T2RyHsLe2HP+ZZSqa d934xbXwjp3DhFJBo5YTvQaF137++sg1sdr048IVj33jb8xo1fhZKqowebfelPlvfZh2Tfu0 cL7zrbSP957aTbEuPHgmuX+LsUD6jaYs8TaenpbkKZ8vxzaYRbSu+eL9qWzzpi/bunzaXzdL hC8Janq9o1v9b/82JZbijERDLeai4kQAzfizSn4CAAA= Cc: SIPCORE , "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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Nov 2012 22:54:26 -0000 Hi, >> I support the adoption. >> >> As I have indicated before, I think there should be some kind of templat= e for the registration. > > I guess that means you aren't ready to approve it. What do you mean by approve? I assumed that adopting the draft would mean t= hat it becomes draft-ietf-sipcore-priority. I think we can do that even if = the template text yet does not exist. Of course, before we finalize WGLC and send the draft to IESG, we would nee= d to have the template text. > Can you suggest some text? I'll try to come up with something. Regards, Christer > Regards, > > Christer > > ________________________________________ > From: sipcore-bounces@ietf.org [sipcore-bounces@ietf.org] on behalf of Pa= ul Kyzivat [pkyzivat@alum.mit.edu] > Sent: Monday, 12 November 2012 10:49 PM > To: SIPCORE; sipcore-ads@tools.ietf.org > Subject: [sipcore] Proposal: Call for adoption & WGLC: draft-roach-sipco= re-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 value= s > 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 ne= w > 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 > From christer.holmberg@ericsson.com Mon Nov 12 15:51:01 2012 Return-Path: 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 34BD421F8488 for ; Mon, 12 Nov 2012 15:51:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] 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 8PxLKPMpuMNu for ; Mon, 12 Nov 2012 15:51:00 -0800 (PST) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 83E0221F8580 for ; Mon, 12 Nov 2012 15:50:59 -0800 (PST) X-AuditID: c1b4fb2d-b7f1e6d000002d2c-30-50a18b624e44 Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 28.6F.11564.26B81A05; Tue, 13 Nov 2012 00:50:58 +0100 (CET) Received: from ESESSHC015.ericsson.se (153.88.183.63) by esessmw0237.eemea.ericsson.se (153.88.115.90) with Microsoft SMTP Server (TLS) id 8.3.279.1; Tue, 13 Nov 2012 00:50:57 +0100 Received: from ESESSMB209.ericsson.se ([169.254.9.182]) by ESESSHC015.ericsson.se ([153.88.183.63]) with mapi id 14.02.0318.001; Tue, 13 Nov 2012 00:50:57 +0100 From: Christer Holmberg To: Paul Kyzivat Thread-Topic: [sipcore] Proposal: Call for adoption & WGLC: draft-roach-sipcore-priority-00 - Registration Template text Thread-Index: AQHNwTCPWCq2g+s2NkOn911D9CA/dg== Date: Mon, 12 Nov 2012 23:50:57 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B02AEC9@ESESSMB209.ericsson.se> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.17] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrELMWRmVeSWpSXmKPExsUyM+JvjW5S98IAg5aLwhYrNhxgtZh20tni 649NbA7MHn/ff2DyWLLkJ5PHl8uf2QKYo7hsUlJzMstSi/TtErgyHv37wVLwia3iS/dt9gbG haxdjJwcEgImEvsnfYSyxSQu3FvP1sXIxSEkcJJRovPBJmaQhJDATkaJS+fNIBJLGCU+njgP VMXBwSZgIdH9TxvEFBHQkJi0VQ2knFkgWmLu6j0sILawQKVE4812MFtEoEqi/9EORghbT2JS zzOwOIuAqsTDb0tYQcbwCnhLTN4VDRJmBDrn+6k1TBAjxSVuPZnPBHGmgMSSPeeZIWxRiZeP /4G1SggoSizvl4Mo15FYsPsTG4StLbFs4Wuwcl4BQYmTM5+wQDylLdGyeAL7BEaxWUg2zELS PgtJ+ywk7QsYWVYxsucmZuaklxtuYgTGy8Etv3V3MJ46J3KIUZqDRUmclytpv7+QQHpiSWp2 ampBalF8UWlOavEhRiYOTqkGRkunavtSlz+VR/NlmlRuFU5jDM/+MdFInbfZeuuKVc2mAvt3 OUVLbFnGvs1z1W4n34/uq5gurI1qfXppqnCrUJT7xvPZW65K8gf2LmDm7vBYpn9yY8su6fcb tao2PLff+DAqVzA/9ouv3EMxhZPWn8sfhbLK5etndsYyOi6M+3gyr9XNpK1HiaU4I9FQi7mo OBEAUMJ1p2UCAAA= Cc: SIPCORE , "sipcore-ads@tools.ietf.org" Subject: Re: [sipcore] Proposal: Call for adoption & WGLC: draft-roach-sipcore-priority-00 - Registration Template text X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Nov 2012 23:51:01 -0000 Hi, Below is some initial suggested registration template text (based on the fc= i template text). Regards, Christer ---------------------------- x. Priority Header Field Value Registration Template Registration requests for Priority header field values requires submitting an Internet-Draft to the IESG. | Instructions are preceded by '|'. All fields are mandatory. Priority header field value: Description: | The description should be no longer than 4 lines. More | detailed information can be provided in the specification | that defines the header field value. Priority header field value specification reference: | The reference to the speicification the defines the=20 | header field value. Contact: | Name(s) & email address(es) of person(s) to | contact for further information." From dwing@cisco.com Mon Nov 12 17:02:25 2012 Return-Path: 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 5671421F857C for ; Mon, 12 Nov 2012 17:02:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.562 X-Spam-Level: X-Spam-Status: No, score=-110.562 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 hkMC-TSpYeAx for ; Mon, 12 Nov 2012 17:02:24 -0800 (PST) Received: from mtv-iport-1.cisco.com (mtv-iport-1.cisco.com [173.36.130.12]) by ietfa.amsl.com (Postfix) with ESMTP id A0EFC21F856B for ; Mon, 12 Nov 2012 17:02:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2647; q=dns/txt; s=iport; t=1352768544; x=1353978144; h=from:to:references:in-reply-to:subject:date:message-id: mime-version:content-transfer-encoding; bh=ALE6JxyyhnOALp5IZsSzNh/LX9rwd/91RSSffY/SWj0=; b=D5sf1sZsZ4lEZ2xRHpJFMaXrhwv7aoW+DzOgBD5aqWQKSc7X9XTSLiD3 csRW0jGCw4geSeWZ3AomOUtiiBAVRXbLwXPZUjE+k6G+K4bJW3M7xdFA+ piV5kf4ogbCUya7uZrZYnGIrWiLW5Uc83YtbvuqdeMesACcIdcsqUap0N Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EADOboVCrRDoG/2dsb2JhbABEDsNVgQiCHgEBAQQBAQEFAggBCh00FwEDAgkOAwQBASgHGQ4fCQgCBAESCwUSh2cMmXigDwSMFYZKA4hahRqEVoMyjliBa4IyXg X-IronPort-AV: E=McAfee;i="5400,1158,6894"; a="60778127" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-1.cisco.com with ESMTP; 13 Nov 2012 01:02:24 +0000 Received: from DWINGWS01 ([10.32.240.194]) by mtv-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id qAD12NEN013078; Tue, 13 Nov 2012 01:02:23 GMT From: "Dan Wing" To: "'Paul Kyzivat'" , "'SIPCORE'" , References: <50A160D8.8030602@alum.mit.edu> In-Reply-To: <50A160D8.8030602@alum.mit.edu> Date: Mon, 12 Nov 2012 17:02:23 -0800 Message-ID: <05b001cdc13a$8a8f3f40$9fadbdc0$@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQHFM/Iwc2ecGGdIGPLzhxms3WbAjJf4DNZA Content-Language: en-us 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Nov 2012 01:02:25 -0000 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 From adam@nostrum.com Mon Nov 12 18:04:15 2012 Return-Path: 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 ; 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 ; 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 ; 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 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 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-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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 From worley@shell01.TheWorld.com Mon Nov 12 18:34:07 2012 Return-Path: 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 10D5D21F8830 for ; Mon, 12 Nov 2012 18:34:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.672 X-Spam-Level: X-Spam-Status: No, score=-2.672 tagged_above=-999 required=5 tests=[AWL=0.308, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_SORBS_WEB=0.619] 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 C-ps5PcUMAMm for ; Mon, 12 Nov 2012 18:34:06 -0800 (PST) Received: from TheWorld.com (pcls4.std.com [192.74.137.144]) by ietfa.amsl.com (Postfix) with ESMTP id 0F5B021F882B for ; Mon, 12 Nov 2012 18:34:05 -0800 (PST) Received: from shell.TheWorld.com (root@shell01.theworld.com [192.74.137.71]) by TheWorld.com (8.14.5/8.14.5) with ESMTP id qAD2XSKw007615; Mon, 12 Nov 2012 21:33:30 -0500 Received: from shell01.TheWorld.com (localhost.theworld.com [127.0.0.1]) by shell.TheWorld.com (8.13.6/8.12.8) with ESMTP id qAD2XR2r934128; Mon, 12 Nov 2012 21:33:27 -0500 (EST) Received: (from worley@localhost) by shell01.TheWorld.com (8.13.6/8.13.6/Submit) id qAD2XQUZ938095; Mon, 12 Nov 2012 21:33:26 -0500 (EST) Date: Mon, 12 Nov 2012 21:33:26 -0500 (EST) Message-Id: <201211130233.qAD2XQUZ938095@shell01.TheWorld.com> From: worley@ariadne.com (Dale R. Worley) Sender: worley@ariadne.com (Dale R. Worley) To: "Dan Wing" In-reply-to: <05b001cdc13a$8a8f3f40$9fadbdc0$@cisco.com> (dwing@cisco.com) Cc: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Nov 2012 02:34:07 -0000 > From: "Dan Wing" > > 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. I support adopting draft-roach-sipcore-priority as a WG item. It would be nice if there was an English word meaning "anti-urgent", but there doesn't seem to be one. And "non-urgent" is fixed is RFC 3261. Do the initial registry entries define the meaning of the initial values? I notice that RFC 3261 doesn't provide meanings, even though it is given as the reference. Dale From adam@nostrum.com Mon Nov 12 18:35:12 2012 Return-Path: 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 9A18421F846D for ; Mon, 12 Nov 2012 18:35:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.083 X-Spam-Level: X-Spam-Status: No, score=-102.083 tagged_above=-999 required=5 tests=[AWL=0.516, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 5eZ9YwUaBTxV for ; Mon, 12 Nov 2012 18:35:12 -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 1A1A021F846B for ; Mon, 12 Nov 2012 18:35:12 -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 qAD2Z8Qc004145 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Mon, 12 Nov 2012 20:35:09 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <50A1B1DC.8010008@nostrum.com> Date: Mon, 12 Nov 2012 20:35:08 -0600 From: Adam Roach 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: "DRAGE, Keith (Keith)" References: <50993285.4020408@nostrum.com> <8486C8728176924BAF5BDB2F7D7EEDDF48652767@ucolhp9h.easf.csd.disa.mil> <50997809.7050306@nostrum.com> <8486C8728176924BAF5BDB2F7D7EEDDF4865824D@ucolhp9h.easf.csd.disa.mil> In-Reply-To: Content-Type: multipart/alternative; boundary="------------070808040306000607050909" Received-SPF: pass (nostrum.com: 99.152.144.32 is authenticated by a trusted mechanism) Cc: "Roy, Radhika R CIV \(US\)" , "sipcore@ietf.org" 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Nov 2012 02:35:12 -0000 This is a multi-part message in MIME format. --------------070808040306000607050909 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit [as a participant] On 11/7/12 18:46, DRAGE, Keith (Keith) wrote: > The Priority header field is rendered to the user or recipient application, and in my view has no impact on the SIP processing directly. For a long time, I was under that same impression until I (as part of this effort) went back and carefully re-read RFC 3261 section 20.26. The interesting statement that disabused me of this notion is: " For example, [the Priority header field] may be factored into decisions about call routing..." Now, I do think it's a stretch to believe that this can be parlayed into how a call is handled relative to other calls, as Radhika was claiming. But there is no blanket prohibition against using Priority in routing elements. /a --------------070808040306000607050909 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
[as a participant]

On 11/7/12 18:46, DRAGE, Keith (Keith) wrote:
The Priority header field is rendered to the user or recipient application, and in my view has no impact on the SIP processing directly.

For a long time, I was under that same impression until I (as part of this effort) went back and carefully re-read RFC 3261 section 20.26. The interesting statement that disabused me of this notion is: " For example, [the Priority header field] may be factored into decisions about call routing..."

Now, I do think it's a stretch to believe that this can be parlayed into how a call is handled relative to other calls, as Radhika was claiming. But there is no blanket prohibition against using Priority in routing elements.

/a
--------------070808040306000607050909-- From adam@nostrum.com Mon Nov 12 18:58:06 2012 Return-Path: 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 E252F21F884A for ; Mon, 12 Nov 2012 18:58:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.157 X-Spam-Level: X-Spam-Status: No, score=-102.157 tagged_above=-999 required=5 tests=[AWL=0.443, 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 GIhdNmeXn4Op for ; Mon, 12 Nov 2012 18:58:06 -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 534CE21F8847 for ; Mon, 12 Nov 2012 18:58:06 -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 qAD2vxun006319 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Mon, 12 Nov 2012 20:58:00 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <50A1B736.7070708@nostrum.com> Date: Mon, 12 Nov 2012 20:57:58 -0600 From: Adam Roach 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: "DRAGE, Keith (Keith)" References: <50A160D8.8030602@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B02AD26@ESESSMB209.ericsson.se> <50A17929.5060005@alum.mit.edu> In-Reply-To: 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-ads@tools.ietf.org" , SIPCORE 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Nov 2012 02:58:07 -0000 On 11/12/12 16:46, DRAGE, Keith (Keith) wrote: > It might also be appropriate to answer the points I made in response, rather than just repeating the demand. Are you meaning to indicate the question of whether this document updates 3261? That seems to be the only point of contention you've raised, and I've heard scant support for your position on that topic. By way of contrast, Paul, Ben, Robert and I -- the only others who have engaged on this rather esoteric bit of IETF arcana -- have all stated what *I* believe are lucid and defensible reasons that this draft is required to update 3261. I'm certainly willing to consider the conversation to be ongoing, if there are new points to be made. Otherwise, this is clearly a non-technical matter of opinion about which people seem to have already reached their own conclusions, and the preponderance of the expressed opinion seems to put you in a minority class of size one. /a From laura.liess.dt@googlemail.com Tue Nov 13 00:54:02 2012 Return-Path: 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 14AB321F860D for ; Tue, 13 Nov 2012 00:54:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.976 X-Spam-Level: X-Spam-Status: No, score=-2.976 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-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 7ZEX-CtuAjXJ for ; Tue, 13 Nov 2012 00:53:56 -0800 (PST) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) by ietfa.amsl.com (Postfix) with ESMTP id F0B4321F8624 for ; Tue, 13 Nov 2012 00:53:54 -0800 (PST) Received: by mail-ie0-f172.google.com with SMTP id 9so11461937iec.31 for ; Tue, 13 Nov 2012 00:53:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=itzxS70g8OQBBxfZeU8WSt4rnnENLEYVSd9GLbuhpUI=; b=aHUHtrrUSXJQH2yRYwXOQMPpPurrGL+/Iru28bcTFcOu7AAZoNDQGmxdyzWYNMK+nC uzsCX86k+1+vwgaKrxXYOmv/Y/F0DTNpg0Tq7UFifu/q+IT3eP8fYsGlN2qB4ijJuWTj UJskjnrCH8llcGFxD/sUqps0e2iYVxiUmKZXWbtEiOFtfXUuxNGUumNKg/ZUrPKteYjX QsF/faHaAXrZvIuDUT8+8nf7LTptr+WUOAFNjBSJ2uuA6fwp2DG7nF5PimdFzzNmaLNE q8IakmJ/5UzhPnqy8t4dGCD8IxpgJKB6g4A2achAUxW7M5SxwQLhLevog10QRdcCVk7B vcxg== MIME-Version: 1.0 Received: by 10.42.50.6 with SMTP id y6mr20929234icf.35.1352796834002; Tue, 13 Nov 2012 00:53:54 -0800 (PST) Received: by 10.231.58.80 with HTTP; Tue, 13 Nov 2012 00:53:53 -0800 (PST) In-Reply-To: <7594FB04B1934943A5C02806D1A2204B02AE7E@ESESSMB209.ericsson.se> References: <50A160D8.8030602@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B02AD26@ESESSMB209.ericsson.se> <50A17929.5060005@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B02AE7E@ESESSMB209.ericsson.se> Date: Tue, 13 Nov 2012 09:53:53 +0100 Message-ID: From: Laura Liess To: Paul Kyzivat , SIPCORE Content-Type: multipart/alternative; boundary=90e6ba10b07dbe78b004ce5c8efd 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Nov 2012 08:54:02 -0000 --90e6ba10b07dbe78b004ce5c8efd Content-Type: text/plain; charset=ISO-8859-1 I support addopting the draft as a WG item. Regargs Laura 2012/11/12 Christer Holmberg > > Hi, > > >> I support the adoption. > >> > >> As I have indicated before, I think there should be some kind of > template for the registration. > > > > I guess that means you aren't ready to approve it. > > What do you mean by approve? I assumed that adopting the draft would mean > that it becomes draft-ietf-sipcore-priority. I think we can do that even if > the template text yet does not exist. > > Of course, before we finalize WGLC and send the draft to IESG, we would > need to have the template text. > > > Can you suggest some text? > > I'll try to come up with something. > > Regards, > > Christer > > > > > > Regards, > > > > Christer > > > > ________________________________________ > > From: sipcore-bounces@ietf.org [sipcore-bounces@ietf.org] on behalf of > Paul Kyzivat [pkyzivat@alum.mit.edu] > > Sent: Monday, 12 November 2012 10: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 > --90e6ba10b07dbe78b004ce5c8efd Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I support addopting the draft as a WG item.

Regargs
Laura

2012/11/12 Christer Holmberg <christer.holmberg@ericsson.com>

Hi,

>> I support the adoption.
>>
>> As I have indicated before, I think there should be some kind of t= emplate for the registration.
>
> I guess that means you aren't ready to approve it.

What do you mean by approve? I assumed that adopting the draft would = mean that it becomes draft-ietf-sipcore-priority. I think we can do that ev= en if the template text yet does not exist.

Of course, before we finalize WGLC and send the draft to IESG, we would nee= d to have the template text.

> Can you suggest some text?

I'll try to come up with something.

Regards,

Christer




> Regards,
>
> Christer
>
> ________________________________________
> From: sipcore-bounces@ietf= .org [sipcore-bounces@ietf.= org] on behalf of Paul Kyzivat [pkyzivat@alum.mit.edu]
> Sent: Monday, 12 November 2012 10:49 PM
> To: SIPCORE; sipcore-ads= @tools.ietf.org
> Subject: [sipcore] Proposal: Call for adoption & WGLC: =A0draft-ro= ach-sipcore-priority-00
>
> PLEASE RESPOND TO THIS MESSAGE
>
> This is a request to the sipcore wg to adopt the new individual draft<= br> > 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 ther= e
> is a holiday coming in the US, so I'm giving more time than I othe= rwise
> would.)
>
> The reason for this is that the ecrit wg wants to define a new value f= or
> the Priority header field. RFC 3261 defines that header field and an > initial set of values. It also mentions the possibility of extension.<= br> > 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:
>
> =A0 =A0 =A0This document defines a new IANA registry to keep track of = the values
> =A0 =A0 =A0defined for the Session Initiation Protocol (SIP) "Pri= ority" header
> =A0 =A0 =A0field. =A0This header field was defined in [RFC3261], secti= on 20.26.
> =A0 =A0 =A0It was clearly specified in a way that allows for the creat= ion of new
> =A0 =A0 =A0values beyond those originally specified; however, no regis= try has
> =A0 =A0 =A0been established for it.
>
> Once that is done, ecrit will be able to make their extension in accor= d
> with the registration procedures that have been defined. The
> registration policy is "IETF Review", so discussion of the m= erits 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 > =A0 =A0 this problem, and adopt this draft as the basis for that work.=
>
> - provide any comments you have on this document before the end of
> =A0 =A0 the WGLC period (Friday, November 25.)
>
> =A0 =A0 =A0 =A0 =A0Thanks,
> =A0 =A0 =A0 =A0 =A0Paul
> _______________________________________________
> 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

--90e6ba10b07dbe78b004ce5c8efd-- From oej@edvina.net Tue Nov 13 01:34:36 2012 Return-Path: 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 5BE2C21F8665 for ; Tue, 13 Nov 2012 01:34:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] 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 dzAcK0ubOvOX for ; Tue, 13 Nov 2012 01:34:35 -0800 (PST) Received: from smtp7.webway.se (smtp7.webway.se [IPv6:2a02:920:212e::205]) by ietfa.amsl.com (Postfix) with ESMTP id 98AED21F8624 for ; Tue, 13 Nov 2012 01:34:33 -0800 (PST) Received: from [IPv6:2001:16d8:cc57:1000::42:1005] (unknown [IPv6:2001:16d8:cc57:1000::42:1005]) by smtp7.webway.se (Postfix) with ESMTPA id 03DD0754A8A7; Tue, 13 Nov 2012 09:34:31 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: "Olle E. Johansson" In-Reply-To: <05b001cdc13a$8a8f3f40$9fadbdc0$@cisco.com> Date: Tue, 13 Nov 2012 10:34:33 +0100 Content-Transfer-Encoding: 7bit Message-Id: References: <50A160D8.8030602@alum.mit.edu> <05b001cdc13a$8a8f3f40$9fadbdc0$@cisco.com> To: "Dan Wing" X-Mailer: Apple Mail (2.1499) Cc: 'SIPCORE' , "Olle E. Johansson" , 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Nov 2012 09:34:36 -0000 13 nov 2012 kl. 02:02 skrev "Dan Wing" : > 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. > Adam's draft seems to only be focused on adding the missing registry, not trying to change the text in RFC 3261. I agree that RFC 3261 lacks a specification of the values, except for emergency: "It is RECOMMENDED that the value of "emergency" only be used when life, limb, or property are in imminent danger. Otherwise, there are no semantics defined for this header field." You know more about IETF procedures, but should we mix the two? - Adding definitions of the values and the missing registry. /O > -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 From oej@edvina.net Tue Nov 13 01:40:42 2012 Return-Path: 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 2BDE921F8659 for ; Tue, 13 Nov 2012 01:40:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] 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 IMutFMGYztNR for ; Tue, 13 Nov 2012 01:40:41 -0800 (PST) Received: from smtp7.webway.se (smtp7.webway.se [IPv6:2a02:920:212e::205]) by ietfa.amsl.com (Postfix) with ESMTP id CE5DF21F8479 for ; Tue, 13 Nov 2012 01:40:39 -0800 (PST) Received: from [IPv6:2001:16d8:cc57:1000::42:1005] (unknown [IPv6:2001:16d8:cc57:1000::42:1005]) by smtp7.webway.se (Postfix) with ESMTPA id D3C53754A8A7; Tue, 13 Nov 2012 09:40:35 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: "Olle E. Johansson" In-Reply-To: <50A1AA98.7080402@nostrum.com> Date: Tue, 13 Nov 2012 10:35:28 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <480A874D-73BC-4FEB-BA59-6809D63D6EAC@edvina.net> References: <50A160D8.8030602@alum.mit.edu> <05b001cdc13a$8a8f3f40$9fadbdc0$@cisco.com> <50A1AA98.7080402@nostrum.com> To: Adam Roach X-Mailer: Apple Mail (2.1499) Cc: 'SIPCORE' , "Olle E. Johansson" , 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Nov 2012 09:40:42 -0000 13 nov 2012 kl. 03:04 skrev Adam Roach : > [as an individual] >=20 > 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. >=20 > 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. >=20 > All I'm intending to do here is set up an IANA registry. And that answered my previous mail... Should read all mail before = starting to answer ;-) I do support wg adoption of this draft. /O >=20 > /a >=20 > 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. >>=20 >> -d >>=20 >>> -----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 >>>=20 >>> PLEASE RESPOND TO THIS MESSAGE >>>=20 >>> 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.) >>>=20 >>> 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. >>>=20 >>> The intro to *this* document explains its purpose: >>>=20 >>> 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. >>>=20 >>> 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. >>>=20 >>> REQUESTED ACTIONS: >>>=20 >>> - indicate (ASAP) willingness, or not, for the sipcore wg to work on >>> this problem, and adopt this draft as the basis for that work. >>>=20 >>> - provide any comments you have on this document before the end of >>> the WGLC period (Friday, November 25.) >>>=20 >>> 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 >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From ben@nostrum.com Tue Nov 13 07:27:10 2012 Return-Path: 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 B93A821F8577 for ; Tue, 13 Nov 2012 07:27:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.559 X-Spam-Level: X-Spam-Status: No, score=-102.559 tagged_above=-999 required=5 tests=[AWL=0.041, 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 5EUVh9jsO0jU for ; Tue, 13 Nov 2012 07:27:01 -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 BB01F21F844A for ; Tue, 13 Nov 2012 07:26:58 -0800 (PST) Received: from [10.0.1.6] (cpe-76-187-92-156.tx.res.rr.com [76.187.92.156]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id qADFQmnp081284 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 13 Nov 2012 09:26:51 -0600 (CST) (envelope-from ben@nostrum.com) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Ben Campbell In-Reply-To: <50A160D8.8030602@alum.mit.edu> Date: Tue, 13 Nov 2012 09:26:48 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <50A160D8.8030602@alum.mit.edu> To: Paul Kyzivat X-Mailer: Apple Mail (2.1499) Received-SPF: pass (nostrum.com: 76.187.92.156 is authenticated by a trusted mechanism) Cc: SIPCORE , 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Nov 2012 15:27:10 -0000 I support adoption. I will provide WGLC comments separately. On Nov 12, 2012, at 2:49 PM, Paul Kyzivat wrote: > PLEASE RESPOND TO THIS MESSAGE >=20 > 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.) >=20 > 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. >=20 > The intro to *this* document explains its purpose: >=20 > 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. >=20 > 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. >=20 > REQUESTED ACTIONS: >=20 > - indicate (ASAP) willingness, or not, for the sipcore wg to work on > this problem, and adopt this draft as the basis for that work. >=20 > - provide any comments you have on this document before the end of > the WGLC period (Friday, November 25.) >=20 > Thanks, > Paul > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From keith.drage@alcatel-lucent.com Tue Nov 13 08:03:41 2012 Return-Path: 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 16DF921F85B6 for ; Tue, 13 Nov 2012 08:03:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.049 X-Spam-Level: X-Spam-Status: No, score=-110.049 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8, 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 Of8Lxc2ITp4N for ; Tue, 13 Nov 2012 08:03:40 -0800 (PST) Received: from smail3.alcatel.fr (smail3.alcatel.fr [64.208.49.56]) by ietfa.amsl.com (Postfix) with ESMTP id D365721F8754 for ; Tue, 13 Nov 2012 08:03:39 -0800 (PST) Received: from FRMRSSXCHHUB04.dc-m.alcatel-lucent.com (FRMRSSXCHHUB04.dc-m.alcatel-lucent.com [135.120.45.64]) by smail3.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id qADG1nml012607 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 13 Nov 2012 17:03:14 +0100 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.46]) by FRMRSSXCHHUB04.dc-m.alcatel-lucent.com ([135.120.45.64]) with mapi; Tue, 13 Nov 2012 17:03:13 +0100 From: "DRAGE, Keith (Keith)" To: "Dale R. Worley" , Dan Wing Date: Tue, 13 Nov 2012 17:03:11 +0100 Thread-Topic: [sipcore] Proposal: Call for adoption & WGLC: draft-roach-sipcore-priority-00 Thread-Index: Ac3BR1+168ruwQPLRpa8wFEFv16RMwAcNijQ Message-ID: References: <05b001cdc13a$8a8f3f40$9fadbdc0$@cisco.com> (dwing@cisco.com) <201211130233.qAD2XQUZ938095@shell01.TheWorld.com> In-Reply-To: <201211130233.qAD2XQUZ938095@shell01.TheWorld.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.83 Cc: "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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Nov 2012 16:03:41 -0000 The action of putting something in an IANA registry defines nothing. If you want to assign meaning to a value, it is the RFC text itself that do= es that. Keith > -----Original Message----- > From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behal= f > Of Dale R. Worley > Sent: 13 November 2012 02:33 > To: Dan Wing > Cc: sipcore@ietf.org; sipcore-ads@tools.ietf.org > Subject: Re: [sipcore] Proposal: Call for adoption & WGLC: draft-roach- > sipcore-priority-00 >=20 > > From: "Dan Wing" > > > > 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. >=20 > I support adopting draft-roach-sipcore-priority as a WG item. >=20 > It would be nice if there was an English word meaning "anti-urgent", > but there doesn't seem to be one. And "non-urgent" is fixed is RFC > 3261. >=20 > Do the initial registry entries define the meaning of the initial > values? I notice that RFC 3261 doesn't provide meanings, even though > it is given as the reference. >=20 > Dale > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From dwing@cisco.com Tue Nov 13 08:12:35 2012 Return-Path: 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 E3DE521F843B for ; Tue, 13 Nov 2012 08:12:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.564 X-Spam-Level: X-Spam-Status: No, score=-110.564 tagged_above=-999 required=5 tests=[AWL=0.035, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 XS5jdniM0bQg for ; Tue, 13 Nov 2012 08:12:29 -0800 (PST) Received: from mtv-iport-4.cisco.com (mtv-iport-4.cisco.com [173.36.130.15]) by ietfa.amsl.com (Postfix) with ESMTP id 7C51321F88B9 for ; Tue, 13 Nov 2012 08:12:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2054; q=dns/txt; s=iport; t=1352823149; x=1354032749; h=from:to:cc:references:in-reply-to:subject:date: message-id:mime-version:content-transfer-encoding; bh=6ZOSCZtw2jo7Oo5pby2JEDJlNppCwISRLAHOc1eK4Ow=; b=A+XV9oBCTNxg+l6R2CyDV87FQOzuWwWDqIJIJ4zOcTs9WWg9wzoiJo5G lor2RBIdpGWk/q75X/3P+E3JmstOv7bmeFXdhaPgCncqRRtW6gSsNeNyP ZfwlO1x0uD4Q85ggFn/M+t3llFKcdKB1eyJesutlcEAwRXmKOxWo3pVjE g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av8EAOlwolCrRDoG/2dsb2JhbABEw22BCIIeAQEBAwEBAQEFAggBCh00CwUHAQMCCREEAQEoBxkOHwkIAgQBEgsFEodiBQyaCo9lkC0EjCqGVAOIWoUahFaDMo5YgWuDEA X-IronPort-AV: E=McAfee;i="5400,1158,6894"; a="63858906" Received: from mtv-core-1.cisco.com ([171.68.58.6]) by mtv-iport-4.cisco.com with ESMTP; 13 Nov 2012 16:12:26 +0000 Received: from DWINGWS01 ([10.32.240.194]) by mtv-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id qADGCPuF009661; Tue, 13 Nov 2012 16:12:25 GMT From: "Dan Wing" To: "'DRAGE, Keith \(Keith\)'" , "'Dale R. Worley'" References: <05b001cdc13a$8a8f3f40$9fadbdc0$@cisco.com> (dwing@cisco.com) <201211130233.qAD2XQUZ938095@shell01.TheWorld.com> In-Reply-To: Date: Tue, 13 Nov 2012 08:12:25 -0800 Message-ID: <071401cdc1b9$abbf8ba0$033ea2e0$@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQLFiIy4+KkzC1jWV5WNQy+oSr0azQHCqQVHAjyW7LOV2Gc6wA== Content-Language: en-us Cc: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Nov 2012 16:12:36 -0000 > -----Original Message----- > From: DRAGE, Keith (Keith) [mailto:keith.drage@alcatel-lucent.com] > Sent: Tuesday, November 13, 2012 8:03 AM > To: Dale R. Worley; Dan Wing > Cc: sipcore@ietf.org; sipcore-ads@tools.ietf.org > Subject: RE: [sipcore] Proposal: Call for adoption & WGLC: draft-roach- > sipcore-priority-00 > > The action of putting something in an IANA registry defines nothing. > > If you want to assign meaning to a value, it is the RFC text itself that > does that. RFC3261 made two mistakes: (a) it provided no meanings for the four terms, and (b) it neglected to create a registry. I find it valuable to fix both (a) and (b), but draft-roach-sipcore-priority only fixes (b). -d > Keith > > > -----Original Message----- > > From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On > > Behalf Of Dale R. Worley > > Sent: 13 November 2012 02:33 > > To: Dan Wing > > Cc: sipcore@ietf.org; sipcore-ads@tools.ietf.org > > Subject: Re: [sipcore] Proposal: Call for adoption & WGLC: > > draft-roach- > > sipcore-priority-00 > > > > > From: "Dan Wing" > > > > > > 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. > > > > I support adopting draft-roach-sipcore-priority as a WG item. > > > > It would be nice if there was an English word meaning "anti-urgent", > > but there doesn't seem to be one. And "non-urgent" is fixed is RFC > > 3261. > > > > Do the initial registry entries define the meaning of the initial > > values? I notice that RFC 3261 doesn't provide meanings, even though > > it is given as the reference. > > > > Dale > > _______________________________________________ > > sipcore mailing list > > sipcore@ietf.org > > https://www.ietf.org/mailman/listinfo/sipcore From jmpolk@cisco.com Tue Nov 13 11:32:34 2012 Return-Path: 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 E848C21F8644 for ; Tue, 13 Nov 2012 11:32:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.569 X-Spam-Level: X-Spam-Status: No, score=-110.569 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 EZU7tgYFnjqf for ; Tue, 13 Nov 2012 11:32:34 -0800 (PST) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 7827D21F877D for ; Tue, 13 Nov 2012 11:32:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3948; q=dns/txt; s=iport; t=1352835153; x=1354044753; h=message-id:date:to:from:subject:cc:in-reply-to: references:mime-version; bh=JGwf0EQHGTRi2FQ+DfNxSVahKm1sGlUeqOp7mfianE4=; b=BvAry0+vp4sKsXfk/XJ2N40quXsha+M8ivepWIFQx/ZJXWZ+bIitF1U6 bKWdE3SMbbeKx5BtwIuhyhcTUN2iESXYIz6LzKMFiWRyKSDrg+vLSStGC FWY3Mz075b3BwSHJzLaCu5J7QVu98e0SAPQYVQXhuI7syvHfTTGKekdqW Q=; X-IronPort-AV: E=McAfee;i="5400,1158,6895"; a="142039508" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-4.cisco.com with ESMTP; 13 Nov 2012 19:32:33 +0000 Received: from jmpolk-WS.cisco.com (rcdn-jmpolk-8716.cisco.com [10.99.80.23]) (authenticated bits=0) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id qADJWW9d008205 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 13 Nov 2012 19:32:33 GMT Message-Id: <201211131932.qADJWW9d008205@rcdn-core-3.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 13 Nov 2012 13:32:33 -0600 To: Dan Wing , "'DRAGE, Keith (Keith)'" , "'Dale R. Worley'" From: James Polk In-Reply-To: <071401cdc1b9$abbf8ba0$033ea2e0$@cisco.com> References: <05b001cdc13a$8a8f3f40$9fadbdc0$@cisco.com> <201211130233.qAD2XQUZ938095@shell01.TheWorld.com> <071401cdc1b9$abbf8ba0$033ea2e0$@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-Authenticated-User: jmpolk Cc: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Nov 2012 19:32:35 -0000 At 10:12 AM 11/13/2012, Dan Wing wrote: > > -----Original Message----- > > From: DRAGE, Keith (Keith) [mailto:keith.drage@alcatel-lucent.com] > > Sent: Tuesday, November 13, 2012 8:03 AM > > To: Dale R. Worley; Dan Wing > > Cc: sipcore@ietf.org; sipcore-ads@tools.ietf.org > > Subject: RE: [sipcore] Proposal: Call for adoption & WGLC: draft-roach- > > sipcore-priority-00 > > > > The action of putting something in an IANA registry defines nothing. > > > > If you want to assign meaning to a value, it is the RFC text itself that > > does that. > >RFC3261 made two mistakes: (a) it provided no meanings for the four terms, >and (b) it neglected to create a registry. I find it valuable to fix >both (a) and (b), but draft-roach-sipcore-priority only fixes (b). I have to agree with Dan here. In the proposed registry within this ID, it gives 4 terms and lists RFC 3261 as the reference, but it doesn't define what any of those terms are (which is bad). "psap-callback" should have a definitive definition within its ID to describe what it is used for. Lacking the ability to update RFC 3261 (anytime) soon, I would prefer an option-tag style new registry in which the term/string definition is within the registry, such as this: Registry: Name Description Reference ----------- ------------------------------------------ --------- non-urgent This Priority header-value means ... [RFCxxxx] normal This Priority header-value means ... [RFCxxxx] urgent This Priority header-value means ... [RFCxxxx] emergency This Priority header-value means ... [RFCxxxx] note: where RFCxxxx is Adam's document, because it provides the meaning of the terms, which are more important than which doc picked the undefined terms (which is what RFC 3261 did). From this, I am suggesting this ID's section 2 be changed to the above (in case that wasn't obvious). I know this is making a bigger deal out of a little used header, but RFC 3261 didn't do what it was supposed to do here, and this is a good make-up. then we just have to agree on the definitions that RFC 3261 didn't discuss. I know this will add a bunch of time (like 2 whole weeks) to reach consensus, but then psap-callback would fit nicely into this registry. James >-d > > > > Keith > > > > > -----Original Message----- > > > From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On > > > Behalf Of Dale R. Worley > > > Sent: 13 November 2012 02:33 > > > To: Dan Wing > > > Cc: sipcore@ietf.org; sipcore-ads@tools.ietf.org > > > Subject: Re: [sipcore] Proposal: Call for adoption & WGLC: > > > draft-roach- > > > sipcore-priority-00 > > > > > > > From: "Dan Wing" > > > > > > > > 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. > > > > > > I support adopting draft-roach-sipcore-priority as a WG item. > > > > > > It would be nice if there was an English word meaning "anti-urgent", > > > but there doesn't seem to be one. And "non-urgent" is fixed is RFC > > > 3261. > > > > > > Do the initial registry entries define the meaning of the initial > > > values? I notice that RFC 3261 doesn't provide meanings, even though > > > it is given as the reference. > > > > > > Dale > > > _______________________________________________ > > > 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 From keith.drage@alcatel-lucent.com Tue Nov 13 11:42:29 2012 Return-Path: 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 536BC21F86D9 for ; Tue, 13 Nov 2012 11:42:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -108.058 X-Spam-Level: X-Spam-Status: No, score=-108.058 tagged_above=-999 required=5 tests=[AWL=-1.809, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4, 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 1rq7qd7u5Mt6 for ; Tue, 13 Nov 2012 11:42:28 -0800 (PST) Received: from smail2.alcatel.fr (smail2.alcatel.fr [62.23.212.57]) by ietfa.amsl.com (Postfix) with ESMTP id 6B0E421F856C for ; Tue, 13 Nov 2012 11:42:28 -0800 (PST) Received: from FRMRSSXCHHUB02.dc-m.alcatel-lucent.com (FRMRSSXCHHUB02.dc-m.alcatel-lucent.com [135.120.45.62]) by smail2.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id qADJfoZR018250 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 13 Nov 2012 20:42:13 +0100 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.46]) by FRMRSSXCHHUB02.dc-m.alcatel-lucent.com ([135.120.45.62]) with mapi; Tue, 13 Nov 2012 20:42:05 +0100 From: "DRAGE, Keith (Keith)" To: James Polk , Dan Wing , "'Dale R. Worley'" Date: Tue, 13 Nov 2012 20:42:03 +0100 Thread-Topic: [sipcore] Proposal: Call for adoption & WGLC: draft-roach-sipcore-priority-00 Thread-Index: Ac3B1agmoC6V938BS5un6bVFv1xNGgAAPycw Message-ID: References: <05b001cdc13a$8a8f3f40$9fadbdc0$@cisco.com> <201211130233.qAD2XQUZ938095@shell01.TheWorld.com> <071401cdc1b9$abbf8ba0$033ea2e0$@cisco.com> <201211131932.qADJWW9d008205@rcdn-core-3.cisco.com> In-Reply-To: <201211131932.qADJWW9d008205@rcdn-core-3.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.80 Cc: "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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Nov 2012 19:42:29 -0000 Whatever you write in the registry has no impact on the semantics, and writ= ing this stuff in the registry carries the wrong message as to the source o= f the definition. The normative source of the semantics is the RFC text. Dan understood this, but you are disagreeing with Dan by asking for it to a= ppear in the registry. Keith > -----Original Message----- > From: James Polk [mailto:jmpolk@cisco.com] > Sent: 13 November 2012 19:33 > To: Dan Wing; DRAGE, Keith (Keith); 'Dale R. Worley' > Cc: sipcore@ietf.org; sipcore-ads@tools.ietf.org > Subject: Re: [sipcore] Proposal: Call for adoption & WGLC: draft-roach- > sipcore-priority-00 >=20 > At 10:12 AM 11/13/2012, Dan Wing wrote: > > > -----Original Message----- > > > From: DRAGE, Keith (Keith) [mailto:keith.drage@alcatel-lucent.com] > > > Sent: Tuesday, November 13, 2012 8:03 AM > > > To: Dale R. Worley; Dan Wing > > > Cc: sipcore@ietf.org; sipcore-ads@tools.ietf.org > > > Subject: RE: [sipcore] Proposal: Call for adoption & WGLC: draft- > roach- > > > sipcore-priority-00 > > > > > > The action of putting something in an IANA registry defines nothing. > > > > > > If you want to assign meaning to a value, it is the RFC text itself > that > > > does that. > > > >RFC3261 made two mistakes: (a) it provided no meanings for the four > terms, > >and (b) it neglected to create a registry. I find it valuable to fix > >both (a) and (b), but draft-roach-sipcore-priority only fixes (b). >=20 > I have to agree with Dan here. In the proposed registry within this > ID, it gives 4 terms and lists RFC 3261 as the reference, but it > doesn't define what any of those terms are (which is bad). > "psap-callback" should have a definitive definition within its ID to > describe what it is used for. Lacking the ability to update RFC 3261 > (anytime) soon, I would prefer an option-tag style new registry in > which the term/string definition is within the registry, such as this: >=20 >=20 > Registry: > Name Description Reference > ----------- ------------------------------------------ --------- > non-urgent This Priority header-value means ... [RFCxxxx] >=20 > normal This Priority header-value means ... [RFCxxxx] >=20 > urgent This Priority header-value means ... [RFCxxxx] >=20 > emergency This Priority header-value means ... [RFCxxxx] >=20 > note: where RFCxxxx is Adam's document, because it provides the > meaning of the terms, which are more important than which doc picked > the undefined terms (which is what RFC 3261 did). >=20 > From this, I am suggesting this ID's section 2 be changed to the > above (in case that wasn't obvious). I know this is making a bigger > deal out of a little used header, but RFC 3261 didn't do what it was > supposed to do here, and this is a good make-up. >=20 > then we just have to agree on the definitions that RFC 3261 didn't > discuss. I know this will add a bunch of time (like 2 whole weeks) to > reach consensus, but then psap-callback would fit nicely into this > registry. >=20 > James >=20 >=20 > >-d > > > > > > > Keith > > > > > > > -----Original Message----- > > > > From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On > > > > Behalf Of Dale R. Worley > > > > Sent: 13 November 2012 02:33 > > > > To: Dan Wing > > > > Cc: sipcore@ietf.org; sipcore-ads@tools.ietf.org > > > > Subject: Re: [sipcore] Proposal: Call for adoption & WGLC: > > > > draft-roach- > > > > sipcore-priority-00 > > > > > > > > > From: "Dan Wing" > > > > > > > > > > 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 th= e > > > > > ordering), but that is not clear. Just saying "have the priority > in > > > > > the listed order" would help. > > > > > > > > I support adopting draft-roach-sipcore-priority as a WG item. > > > > > > > > It would be nice if there was an English word meaning "anti-urgent"= , > > > > but there doesn't seem to be one. And "non-urgent" is fixed is RFC > > > > 3261. > > > > > > > > Do the initial registry entries define the meaning of the initial > > > > values? I notice that RFC 3261 doesn't provide meanings, even > though > > > > it is given as the reference. > > > > > > > > Dale > > > > _______________________________________________ > > > > 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 From keith.drage@alcatel-lucent.com Tue Nov 13 11:50:33 2012 Return-Path: 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 40CE821F8718 for ; Tue, 13 Nov 2012 11:50:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.976 X-Spam-Level: X-Spam-Status: No, score=-109.976 tagged_above=-999 required=5 tests=[AWL=0.273, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8, 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 mc2JidCtdtRS for ; Tue, 13 Nov 2012 11:50:32 -0800 (PST) Received: from smail2.alcatel.fr (smail2.alcatel.fr [64.208.49.57]) by ietfa.amsl.com (Postfix) with ESMTP id 4B48B21F84D2 for ; Tue, 13 Nov 2012 11:50:31 -0800 (PST) Received: from FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (FRMRSSXCHHUB01.dc-m.alcatel-lucent.com [135.120.45.61]) by smail2.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id qADJnjND022298 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 13 Nov 2012 20:50:26 +0100 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.46]) by FRMRSSXCHHUB01.dc-m.alcatel-lucent.com ([135.120.45.61]) with mapi; Tue, 13 Nov 2012 20:50:20 +0100 From: "DRAGE, Keith (Keith)" To: Adam Roach Date: Tue, 13 Nov 2012 20:50:19 +0100 Thread-Topic: [sipcore] Proposal: Call for adoption & WGLC: draft-roach-sipcore-priority-00 Thread-Index: Ac3BSrQVnQ6zOI3cSLy5IgJ6uCTlrAAjTwZg Message-ID: References: <50A160D8.8030602@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B02AD26@ESESSMB209.ericsson.se> <50A17929.5060005@alum.mit.edu> <50A1B736.7070708@nostrum.com> In-Reply-To: <50A1B736.7070708@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.80 Cc: "sipcore-ads@tools.ietf.org" , SIPCORE 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Nov 2012 19:50:33 -0000 I'm referring to these comments I made on the template proposal on 6th Nove= mber which I copy here: " As regards the template (which other mails have suggested), we possibly d= o 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 throu= gh IETF community review. There will be enough people around in this proces= s to ensure that all the information that people need to see outside the IA= NA table actually exists. Conversely where we are allocating values on expe= rt review, a template could be essential if only to ensure the expert doing= the review has enough information available to perform the review; that in= formation may well exceed the information that needs to appear in the templ= ate itself. Note that I did have a discussion with IANA on both these issues, and it wo= uld be wrong to say an opinion was expressed, Michelle seemed to be in alig= nment with these points." Keith > -----Original Message----- > From: Adam Roach [mailto:adam@nostrum.com] > Sent: 13 November 2012 02:58 > To: DRAGE, Keith (Keith) > Cc: Paul Kyzivat; Christer Holmberg; SIPCORE; sipcore-ads@tools.ietf.org > Subject: Re: [sipcore] Proposal: Call for adoption & WGLC: draft-roach- > sipcore-priority-00 >=20 > On 11/12/12 16:46, DRAGE, Keith (Keith) wrote: > > It might also be appropriate to answer the points I made in response, > rather than just repeating the demand. >=20 > Are you meaning to indicate the question of whether this document > updates 3261? That seems to be the only point of contention you've > raised, and I've heard scant support for your position on that topic. >=20 > By way of contrast, Paul, Ben, Robert and I -- the only others who have > engaged on this rather esoteric bit of IETF arcana -- have all stated > what *I* believe are lucid and defensible reasons that this draft is > required to update 3261. I'm certainly willing to consider the > conversation to be ongoing, if there are new points to be made. > Otherwise, this is clearly a non-technical matter of opinion about which > people seem to have already reached their own conclusions, and the > preponderance of the expressed opinion seems to put you in a minority > class of size one. >=20 > /a From pkyzivat@alum.mit.edu Tue Nov 13 13:27:10 2012 Return-Path: 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 DD90B21F853F for ; Tue, 13 Nov 2012 13:27:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.388 X-Spam-Level: X-Spam-Status: No, score=-0.388 tagged_above=-999 required=5 tests=[AWL=0.049, 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 IuCgFa+KcNft for ; Tue, 13 Nov 2012 13:27:10 -0800 (PST) Received: from qmta02.westchester.pa.mail.comcast.net (qmta02.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:24]) by ietfa.amsl.com (Postfix) with ESMTP id 474C421F844E for ; Tue, 13 Nov 2012 13:27:10 -0800 (PST) Received: from omta08.westchester.pa.mail.comcast.net ([76.96.62.12]) by qmta02.westchester.pa.mail.comcast.net with comcast id Nz2p1k0020Fqzac519T9aC; Tue, 13 Nov 2012 21:27:09 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta08.westchester.pa.mail.comcast.net with comcast id P9T91k00q3ZTu2S3U9T9ww; Tue, 13 Nov 2012 21:27:09 +0000 Message-ID: <50A2BB2B.2040301@alum.mit.edu> Date: Tue, 13 Nov 2012 16:27:07 -0500 From: Paul Kyzivat 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: <05b001cdc13a$8a8f3f40$9fadbdc0$@cisco.com> (dwing@cisco.com) <201211130233.qAD2XQUZ938095@shell01.TheWorld.com> <071401cdc1b9$abbf8ba0$033ea2e0$@cisco.com> In-Reply-To: <071401cdc1b9$abbf8ba0$033ea2e0$@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Nov 2012 21:27:11 -0000 (as individual) On 11/13/12 11:12 AM, Dan Wing wrote: > > RFC3261 made two mistakes: (a) it provided no meanings for the four terms, > and (b) it neglected to create a registry. I find it valuable to fix > both (a) and (b), but draft-roach-sipcore-priority only fixes (b). The question is how to do these things. - we could decide to fix (b) and not (a) - this draft could be enhanced to do both - this draft could be left as is, and an errata filed against 3261 regarding (a) - we could leave this draft as is and submit another draft to fix (a). Ecrit *needs* a way to add a new value, so they need (b) *soon*. AFAIK nobody is currently suffering for lack of a fix for (a). If we could do (a) *quickly* then doing them both in the same draft would be attractive. I just fear that we might end up squabbling for a long time of this mundane thing. If so, then I think the errata approach for (a) is more attractive. Thanks, Paul From radhika.r.roy.civ@mail.mil Wed Nov 14 04:45:08 2012 Return-Path: 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 EDAA521F849B for ; Wed, 14 Nov 2012 04:45:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.4 X-Spam-Level: X-Spam-Status: No, score=-2.4 tagged_above=-999 required=5 tests=[AWL=0.199, BAYES_00=-2.599] 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 6-O1IjiNvU-F for ; Wed, 14 Nov 2012 04:45:07 -0800 (PST) Received: from edge-cols.mail.mil (edge-cols.mail.mil [131.64.100.9]) by ietfa.amsl.com (Postfix) with ESMTP id 196B321F8465 for ; Wed, 14 Nov 2012 04:45:06 -0800 (PST) Received: from UCOLHP3N.easf.csd.disa.mil (131.64.100.153) by ucolhp2w.easf.csd.disa.mil (131.64.100.9) with Microsoft SMTP Server (TLS) id 14.2.309.2; Wed, 14 Nov 2012 12:44:42 +0000 Received: from UCOLHP9H.easf.csd.disa.mil ([169.254.5.171]) by UCOLHP3N.easf.csd.disa.mil ([131.64.100.153]) with mapi id 14.02.0309.003; Wed, 14 Nov 2012 12:44:42 +0000 From: "Roy, Radhika R CIV (US)" To: Paul Kyzivat Thread-Topic: [sipcore] Proposal: Call for adoption & WGLC: draft-roach-sipcore-priority-00 Thread-Index: AQHNweWqCnlenuma00CJ0LCXdy90K5fpRaog Date: Wed, 14 Nov 2012 12:44:41 +0000 Message-ID: <8486C8728176924BAF5BDB2F7D7EEDDF4865E763@ucolhp9h.easf.csd.disa.mil> References: <05b001cdc13a$8a8f3f40$9fadbdc0$@cisco.com> (dwing@cisco.com) <201211130233.qAD2XQUZ938095@shell01.TheWorld.com> <071401cdc1b9$abbf8ba0$033ea2e0$@cisco.com> <50A2BB2B.2040301@alum.mit.edu> In-Reply-To: <50A2BB2B.2040301@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [131.64.62.4] Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=SHA1; boundary="----=_NextPart_000_000D_01CDC23B.E9422E60" MIME-Version: 1.0 X-Mailman-Approved-At: Wed, 14 Nov 2012 06:00:42 -0800 Cc: "sipcore@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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Nov 2012 12:45:08 -0000 ------=_NextPart_000_000D_01CDC23B.E9422E60 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, Paul: It is not true. We are suffering for not fixing (a) because of incompatibility in implementations from the SIP application layer to the IP/MPLS network (RSVP, DiffServ DSCP code points) layer along with dealings of emergency (E911) calls. We have to see all RFCs as I mentioned to an email to Adam that our explanations and semantics of RFC 3261 must be consistent with respect to other RFCs as well: "RFCs 4411 and 4412, 5478, 6433, 6061, 5031, and 3689 need to be seen for some guidance before explaining the labels so that terminologies and definitions do not overlap or contradict." BR/Radhika -----Original Message----- From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behalf Of Paul Kyzivat Sent: Tuesday, November 13, 2012 4:27 PM To: sipcore@ietf.org Subject: Re: [sipcore] Proposal: Call for adoption & WGLC: draft-roach-sipcore-priority-00 (as individual) .... nobody is currently suffering for lack of a fix for (a). .... Thanks, Paul ------=_NextPart_000_000D_01CDC23B.E9422E60 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIISizCCA3Aw ggJYoAMCAQICAQUwDQYJKoZIhvcNAQEFBQAwWzELMAkGA1UEBhMCVVMxGDAWBgNVBAoTD1UuUy4g R292ZXJubWVudDEMMAoGA1UECxMDRG9EMQwwCgYDVQQLEwNQS0kxFjAUBgNVBAMTDURvRCBSb290 IENBIDIwHhcNMDQxMjEzMTUwMDEwWhcNMjkxMjA1MTUwMDEwWjBbMQswCQYDVQQGEwJVUzEYMBYG A1UEChMPVS5TLiBHb3Zlcm5tZW50MQwwCgYDVQQLEwNEb0QxDDAKBgNVBAsTA1BLSTEWMBQGA1UE AxMNRG9EIFJvb3QgQ0EgMjCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMAswfaNO6z/ PzzWcb64dCIH7HBBFfyrQOMHqsHD2J/+2kw6vz/I2Ch7SzYBwKxFJcPSDgqPhRhkED0aE3Aqb47X 3I2Ts0EPOCHNravCPSoF01cRNw3NjFH5k+PMRkkhjhS0zcsUPjjNcjHuqxLyZeo0LlZd/+5jdctt upE0/J7z9C0cvlDEQt9ZiP9qs/qobD3LVnFxBZa7n4DlgEVZZ0Gw68OtYKSAdQYXnA70Q+CZDhv7 f/WzzLKBgrH9MsG4vkGkZLVgOlpRMIzO3kEsGUdcSRBkuXSph0GvfW66wbihv2UxOgRn+bW7jpKK AGO4seaMOF+D/1DVO6Jda7IQzGMCAwEAAaM/MD0wHQYDVR0OBBYEFEl0uwxeunr+AlTve6DGlcYJ gHCWMAsGA1UdDwQEAwIBhjAPBgNVHRMBAf8EBTADAQH/MA0GCSqGSIb3DQEBBQUAA4IBAQCYkY0/ ici79cBpcyk7Nay6swh2PXAJkumERCEBfRR2G+5RbB2NFTctezFp9JpEuK9GzDT6I8sDJxnSgyF1 K+fgG5km3IRAleio0sz2WFxm7z9KlxCCHboKot1bBiudp2RO6y4BNaS0PxOtVeTVc6hpmxHxmPIx Hm9A1Ph4n46RoG9wBJBmqgYrzuF6krV94eDRluehOi3MsZ0fBUTth5nTTRpwOcEEDOV+2fGv1yAO 8SJ6JaRzmcw/pAcnlqiile2CuRbTnguHwsHyiPVi32jfx7xpUe2xXNxUVCkPCTmarAPB2wxNrm8K ehZJ8b+R0jiU0/aVLLdsyUK2jcqQjYXZMIIEtzCCA5+gAwIBAgIDHzzKMA0GCSqGSIb3DQEBBQUA MF0xCzAJBgNVBAYTAlVTMRgwFgYDVQQKEw9VLlMuIEdvdmVybm1lbnQxDDAKBgNVBAsTA0RvRDEM MAoGA1UECxMDUEtJMRgwFgYDVQQDEw9ET0QgRU1BSUwgQ0EtMjkwHhcNMTIwOTIwMDAwMDAwWhcN MTUwOTE5MjM1OTU5WjB5MQswCQYDVQQGEwJVUzEYMBYGA1UEChMPVS5TLiBHb3Zlcm5tZW50MQww CgYDVQQLEwNEb0QxDDAKBgNVBAsTA1BLSTEMMAoGA1UECxMDVVNBMSYwJAYDVQQDEx1ST1kuUkFE SElLQS5SQU5KQU4uMTI5MTkzOTgwMTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAKw9 ymde30NtacDt8neYCBWDyA+Hlsk3dNwV23IVgH7vSWJx4zCFT5ojDHACm3lthvOOtJ0CzkjwQy8V hEHvL0eK03hZy0hJrZxQSYcao7Y0Yv9yDAFvxa6LJ1fUImUj9edMf1l08LZkjh3ybs20Bk+MLySR 9F/flRzjtCwVUeqq8NS3to4nPXSIgViP6H0YJrBjf9IDZQGgcO8LxLbNENOWrXILeCCCngnHBgHV lJWak9YndpMOs+CeLXk5oUV8xUAM/UjyS+/gFCjABBRt30VJVN6pqARmIht850iK8TDeqlWwF3O9 eQBBwKQPJ7nVl0kmGItYGoYb+4t2Mkwalh8CAwEAAaOCAWIwggFeMB8GA1UdIwQYMBaAFLhDg2Qh eu5wgd6l3gxgKId4rl54MDoGA1UdHwQzMDEwL6AtoCuGKWh0dHA6Ly9jcmwuZGlzYS5taWwvY3Js L0RPREVNQUlMQ0FfMjkuY3JsMA4GA1UdDwEB/wQEAwIFIDAjBgNVHSAEHDAaMAsGCWCGSAFlAgEL CTALBglghkgBZQIBCxMwHQYDVR0OBBYEFGRWf703swy+9hvoDujsb+ZPwC9MMGgGCCsGAQUFBwEB BFwwWjA2BggrBgEFBQcwAoYqaHR0cDovL2NybC5kaXNhLm1pbC9zaWduL0RPREVNQUlMQ0FfMjku Y2VyMCAGCCsGAQUFBzABhhRodHRwOi8vb2NzcC5kaXNhLm1pbDAkBgNVHREEHTAbgRlyYWRoaWth LnIucm95QHVzLmFybXkubWlsMBsGA1UdCQQUMBIwEAYIKwYBBQUHCQQxBBMCVVMwDQYJKoZIhvcN AQEFBQADggEBAE9PU63Rc/bneYoxI6sAZi+oXBiwneOiI03+J3pSZWIbwrOnj7qGoH5ZoeO+dZ8E wvKszd+vacYnO8SqEXsvIKvBGPchKg1oV5b24+tCSeiCXtcX5EDtpJQGS4W9G+7r7f+mdEHU0NuF NI7HNHRY/q4C+FGhchPoKPcKeyWxJMwp+9NJQsx1AoC5isvydZHHlNkV917dLMuMEqyCCAAbJAOp 8SDQTiiIVa1I7NlMSlkzNRUtFoO9nsEttMH699V9JH5jcwWPlWdyb5B6yRzoM/iFsI/hA9pHHukh iWVul3FX/6Ez8Jt/A1j/CFsl3S2y2TBRCdqIQEP+/H6j4RFxa9MwggUCMIID6qADAgECAgMfPMkw DQYJKoZIhvcNAQEFBQAwXTELMAkGA1UEBhMCVVMxGDAWBgNVBAoTD1UuUy4gR292ZXJubWVudDEM MAoGA1UECxMDRG9EMQwwCgYDVQQLEwNQS0kxGDAWBgNVBAMTD0RPRCBFTUFJTCBDQS0yOTAeFw0x MjA5MjAwMDAwMDBaFw0xNTA5MTkyMzU5NTlaMHkxCzAJBgNVBAYTAlVTMRgwFgYDVQQKEw9VLlMu IEdvdmVybm1lbnQxDDAKBgNVBAsTA0RvRDEMMAoGA1UECxMDUEtJMQwwCgYDVQQLEwNVU0ExJjAk BgNVBAMTHVJPWS5SQURISUtBLlJBTkpBTi4xMjkxOTM5ODAxMIIBIjANBgkqhkiG9w0BAQEFAAOC AQ8AMIIBCgKCAQEAyr7Ttduf1mHx22erLvkwPOZL02imdiimrmXITVrdUHsynK383NY6a4ye07Jm b0spr8hzmfM6JSCEgtbZevWfJg4NmNDjEEe53+7EvEMRHfh46GGxOckj98QmQwngbQaAIcKI1gJd Do2vB3mOtFp5hNKqsxibZAvpPb3OsR762vrx2QYQX+p8+psLwe95CSt56IfC39GZD+Otus3Sq1Ma 9e0NdRhqg5ch8FYpL2ONbmEw9+DTqk24Zh2lQuOvpo4FhpvXnNghCS4CfuiE6YgvKdombc1BGT5u rkDFep5IH7Rk7EnK4CVVzNq3gxT0B+hDoJT0AuQfrkxI9223mUJoywIDAQABo4IBrTCCAakwHwYD VR0jBBgwFoAUuEODZCF67nCB3qXeDGAoh3iuXngwOgYDVR0fBDMwMTAvoC2gK4YpaHR0cDovL2Ny bC5kaXNhLm1pbC9jcmwvRE9ERU1BSUxDQV8yOS5jcmwwDgYDVR0PAQH/BAQDAgbAMCMGA1UdIAQc MBowCwYJYIZIAWUCAQsJMAsGCWCGSAFlAgELEzAdBgNVHQ4EFgQUrV8KnskfJHURS19In/mX0d2y 9pgwaAYIKwYBBQUHAQEEXDBaMDYGCCsGAQUFBzAChipodHRwOi8vY3JsLmRpc2EubWlsL3NpZ24v RE9ERU1BSUxDQV8yOS5jZXIwIAYIKwYBBQUHMAGGFGh0dHA6Ly9vY3NwLmRpc2EubWlsMEQGA1Ud EQQ9MDuBGXJhZGhpa2Euci5yb3lAdXMuYXJteS5taWygHgYKKwYBBAGCNxQCA6AQDA4xMjkxOTM5 ODAxQG1pbDAbBgNVHQkEFDASMBAGCCsGAQUFBwkEMQQTAlVTMCkGA1UdJQQiMCAGCisGAQQBgjcU AgIGCCsGAQUFBwMCBggrBgEFBQcDBDANBgkqhkiG9w0BAQUFAAOCAQEAggVw28drobHRF6Zr7wQZ G/ShO0BE6jEddlmlqj9ln2mC5HoTTXkl2ZOqjUoh2Wq2d55KvbZk9b73bIzWK+RnnoU+zOHagyB/ VnEbSpdofTm50zJYISK7Ws92KCt8viNetFkS2CTNSc302cqmwejpTwKAxkLDM0wU7ECNopN87F0O vPU2AJnITH32PrAvTVOeCxsDdEnzzXYxvKtNE5K6zBVVumSOGLMfnyFAq+4dlhg7i25B8Goh+fIF eRGiwxsXOyEMPalWHt5wWDDmUlIK0Qmg95mZ7f6UJCmj15zzSxgliR+JyVlFGH6/HYzIAU4lv8b5 uU5qyxANtVCvuGDruDCCBVIwggQ6oAMCAQICAgG4MA0GCSqGSIb3DQEBBQUAMFsxCzAJBgNVBAYT AlVTMRgwFgYDVQQKEw9VLlMuIEdvdmVybm1lbnQxDDAKBgNVBAsTA0RvRDEMMAoGA1UECxMDUEtJ MRYwFAYDVQQDEw1Eb0QgUm9vdCBDQSAyMB4XDTExMDkwODE2MDIxNFoXDTE3MDkwODE2MDIxNFow XTELMAkGA1UEBhMCVVMxGDAWBgNVBAoTD1UuUy4gR292ZXJubWVudDEMMAoGA1UECxMDRG9EMQww CgYDVQQLEwNQS0kxGDAWBgNVBAMTD0RPRCBFTUFJTCBDQS0yOTCCASIwDQYJKoZIhvcNAQEBBQAD ggEPADCCAQoCggEBAJJiL0HCIAAWBlVkn72niBVugptIwYV3vQKrDNnxK2CBAbo+dXCOEqanOISQ s+lAgBLcaspRza0thhDMRLwOxVg4GbIUMiVBVFhcQw7IbHMPwwwYGBYEmlI9gaJxzjwyAJ9xVbr4 zjZ3HiG3KJTnPT6m9sB6MWCRKJd3IlDyxpNushvFQcb5oTf7EL/aVqb7Uk1fv+/Elnco5TL/6OEY zENSGKyNd5pyTOidA16wou/k3dLn5qemUq3hmAiWSkPMcz1Loo2J79yCTLhKgCRlKx6RgvUE9nIf VxhAF/A5UbaP84k7Z/dYTkq82vkOwcAMvfMIcfiDD8kugJX0hQ7OrqkCAwEAAaOCAhwwggIYMA4G A1UdDwEB/wQEAwIBhjAfBgNVHSMEGDAWgBRJdLsMXrp6/gJU73ugxpXGCYBwljAdBgNVHQ4EFgQU uEODZCF67nCB3qXeDGAoh3iuXngwEgYDVR0TAQH/BAgwBgEB/wIBADAMBgNVHSQEBTADgAEAMGYG A1UdIARfMF0wCwYJYIZIAWUCAQsFMAsGCWCGSAFlAgELCTALBglghkgBZQIBCxEwCwYJYIZIAWUC AQsSMAsGCWCGSAFlAgELEzAMBgpghkgBZQMCAQMaMAwGCmCGSAFlAwIBAxswNwYDVR0fBDAwLjAs oCqgKIYmaHR0cDovL2NybC5kaXNhLm1pbC9jcmwvRE9EUk9PVENBMi5jcmwwggEBBggrBgEFBQcB AQSB9DCB8TA6BggrBgEFBQcwAoYuaHR0cDovL2NybC5kaXNhLm1pbC9pc3N1ZWR0by9ET0RST09U Q0EyX0lULnA3YzAgBggrBgEFBQcwAYYUaHR0cDovL29jc3AuZGlzYS5taWwwgZAGCCsGAQUFBzAC hoGDbGRhcDovL2NybC5nZHMuZGlzYS5taWwvY24lM2REb0QlMjBSb290JTIwQ0ElMjAyJTJjb3Ul M2RQS0klMmNvdSUzZERvRCUyY28lM2RVLlMuJTIwR292ZXJubWVudCUyY2MlM2RVUz9jcm9zc0Nl cnRpZmljYXRlUGFpcjtiaW5hcnkwDQYJKoZIhvcNAQEFBQADggEBACxrLHk12/AeHId7q+HoaWo3 i9t6T1VgaZUvU53GykO21DeR1gNdflqxuB33noHTrlBUMKRvSy67FBsXqlwQ05R6MTmWpFR59elW LlXDGxbqqgLIz1H3MoEixjQ6qc2aqkiTx+n7HjJ+ccR28EVUEh1V6r1cMoc6rpOabpkiX6hRNe6y U2Bf9k9FuBaEHWVVzRXKEAEfqdKcp1eRo9fnsIY9LfSJOtjJd3BQxmzv8uuY+BCqPdrIXCmtzrhz SUyhkrvm7c26ghpjIRll9AYZv4Oqc+XTG7GY/0Xf+0nMc+ji5weWADHpf9kkCOfKRHpIBsNC2D/5 eYelN5IWqYQgkmMxggMyMIIDLgIBATBkMF0xCzAJBgNVBAYTAlVTMRgwFgYDVQQKEw9VLlMuIEdv dmVybm1lbnQxDDAKBgNVBAsTA0RvRDEMMAoGA1UECxMDUEtJMRgwFgYDVQQDEw9ET0QgRU1BSUwg Q0EtMjkCAx88yTAJBgUrDgMCGgUAoIIBozAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqG SIb3DQEJBTEPFw0xMjExMTQxMjQ0NDNaMCMGCSqGSIb3DQEJBDEWBBROQINbvPkrVx1S077/K3WV dQdUPDBYBgkqhkiG9w0BCQ8xSzBJMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDAHBgUrDgMC BzANBggqhkiG9w0DAgIBKDAHBgUrDgMCGjAKBggqhkiG9w0CBTBzBgkrBgEEAYI3EAQxZjBkMF0x CzAJBgNVBAYTAlVTMRgwFgYDVQQKEw9VLlMuIEdvdmVybm1lbnQxDDAKBgNVBAsTA0RvRDEMMAoG A1UECxMDUEtJMRgwFgYDVQQDEw9ET0QgRU1BSUwgQ0EtMjkCAx88yjB1BgsqhkiG9w0BCRACCzFm oGQwXTELMAkGA1UEBhMCVVMxGDAWBgNVBAoTD1UuUy4gR292ZXJubWVudDEMMAoGA1UECxMDRG9E MQwwCgYDVQQLEwNQS0kxGDAWBgNVBAMTD0RPRCBFTUFJTCBDQS0yOQIDHzzKMA0GCSqGSIb3DQEB AQUABIIBAL2EGscQy5G9WpC0b20lYiXZK8ojiYtMx3h8M2rM7ZYVHi3kRNPDeK0zGFagWMlVPqq6 09ukpGn5jk9EnbG2O55w1yB0bEP0qHXXfRCDpblDrq6K4tSPY/aWhP1xZJnkg76v6RzM975hrKqb bwpBgbX/oirtXSbfaOkWLGI13mhbZsnT20uKV5pzmtnbGmQ3W/fStiXpymCRDuOuuAt8jWUAZFsN C1h92kspmqZnD6AD2DBLUL1l2VVxEsulb3MdOSeBbTFYEmwQusaXUYsxPFCsGC+sbPcMeR5v3DFq wGGy9w4pW54eDikrGKKgfv6Q42QtTFdnnfc7qk/1dqAIYsQAAAAAAAA= ------=_NextPart_000_000D_01CDC23B.E9422E60-- From pkyzivat@alum.mit.edu Wed Nov 14 08:05:25 2012 Return-Path: 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 EFEF021F858E for ; Wed, 14 Nov 2012 08:05:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.391 X-Spam-Level: X-Spam-Status: No, score=-0.391 tagged_above=-999 required=5 tests=[AWL=0.046, 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 CqVhJM1y-VQH for ; Wed, 14 Nov 2012 08:05:25 -0800 (PST) Received: from QMTA11.westchester.pa.mail.comcast.net (qmta11.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:211]) by ietfa.amsl.com (Postfix) with ESMTP id 4C55121F84CF for ; Wed, 14 Nov 2012 08:05:25 -0800 (PST) Received: from omta24.westchester.pa.mail.comcast.net ([76.96.62.76]) by QMTA11.westchester.pa.mail.comcast.net with comcast id PQu01k0031ei1Bg5BU5Qre; Wed, 14 Nov 2012 16:05:24 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta24.westchester.pa.mail.comcast.net with comcast id PU5Q1k00T3ZTu2S3kU5Q6l; Wed, 14 Nov 2012 16:05:24 +0000 Message-ID: <50A3C142.5050002@alum.mit.edu> Date: Wed, 14 Nov 2012 11:05:22 -0500 From: Paul Kyzivat 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: "Roy, Radhika R CIV (US)" References: <05b001cdc13a$8a8f3f40$9fadbdc0$@cisco.com> (dwing@cisco.com) <201211130233.qAD2XQUZ938095@shell01.TheWorld.com> <071401cdc1b9$abbf8ba0$033ea2e0$@cisco.com> <50A2BB2B.2040301@alum.mit.edu> <8486C8728176924BAF5BDB2F7D7EEDDF4865E763@ucolhp9h.easf.csd.disa.mil> In-Reply-To: <8486C8728176924BAF5BDB2F7D7EEDDF4865E763@ucolhp9h.easf.csd.disa.mil> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "sipcore@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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Nov 2012 16:05:26 -0000 Roy, On 11/14/12 7:44 AM, Roy, Radhika R CIV (US) wrote: > Hi, Paul: > > It is not true. We are suffering for not fixing (a) because of > incompatibility in implementations from the SIP application layer to the > IP/MPLS network (RSVP, DiffServ DSCP code points) layer along with dealings > of emergency (E911) calls. > > We have to see all RFCs as I mentioned to an email to Adam that our > explanations and semantics of RFC 3261 must be consistent with respect to > other RFCs as well: > > "RFCs 4411 and 4412, 5478, 6433, 6061, 5031, and 3689 need to be seen for > some guidance before explaining the labels so that terminologies and > definitions do not overlap or contradict." IMO what you are talking about is different from (a). What (a) is about is the meaning of each individual priority value - they way that they differ from one another. I'm not aware of any reports of problems due to this lack, though there certainly could be some. (I was of the opinion that Priority:emergency was suitable for use in the psap-callback case, but others hypothesized that this would cause confusion. This is why we are preparing for the definition of a new value. But that is the *only* case I have heard of where the meaning of the Priority values has come up.) What you are talking about is the difference between Priority and Resource-Priority. Resource-Priority and all the things built around it are *extensions* to SIP. If you find it difficult to distinguish the responsibilities of the extensions from those of the core, then I would consider that an inadequacy of the extension, not of the core. Perhaps the ECRIT docs need to document further what the role is for the Resource-Priority header in emergency calls. But that is separate from *this* draft. Thanks, Paul (as co-chair) > BR/Radhika > > -----Original Message----- > From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behalf > Of Paul Kyzivat > Sent: Tuesday, November 13, 2012 4:27 PM > To: sipcore@ietf.org > Subject: Re: [sipcore] Proposal: Call for adoption & WGLC: > draft-roach-sipcore-priority-00 > > (as individual) > .... > nobody is currently suffering for lack of a fix for (a). > .... > Thanks, > Paul > > From adam@nostrum.com Wed Nov 14 11:57:02 2012 Return-Path: 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 5947E21F8798 for ; Wed, 14 Nov 2012 11:57:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.205 X-Spam-Level: X-Spam-Status: No, score=-102.205 tagged_above=-999 required=5 tests=[AWL=0.395, 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 k2GTLbMbvfGW for ; Wed, 14 Nov 2012 11:57:01 -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 A25F021F8600 for ; Wed, 14 Nov 2012 11:57:01 -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 qAEJupiP048282 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Wed, 14 Nov 2012 13:56:51 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <50A3F783.3020806@nostrum.com> Date: Wed, 14 Nov 2012 13:56:51 -0600 From: Adam Roach 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: "DRAGE, Keith (Keith)" References: <50A160D8.8030602@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B02AD26@ESESSMB209.ericsson.se> <50A17929.5060005@alum.mit.edu> <50A1B736.7070708@nostrum.com> In-Reply-To: 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-ads@tools.ietf.org" , SIPCORE 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Nov 2012 19:57:02 -0000 I don't think you're being ignored; I'm waiting to hear from other participants about whether we need a registration template. I really don't have a strong opinion on the topic. /a On 11/13/12 13:50, DRAGE, Keith (Keith) wrote: > I'm referring to these comments I made on the template proposal on 6th November which I copy here: > > " 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." > > Keith > >> -----Original Message----- >> From: Adam Roach [mailto:adam@nostrum.com] >> Sent: 13 November 2012 02:58 >> To: DRAGE, Keith (Keith) >> Cc: Paul Kyzivat; Christer Holmberg; SIPCORE; sipcore-ads@tools.ietf.org >> Subject: Re: [sipcore] Proposal: Call for adoption & WGLC: draft-roach- >> sipcore-priority-00 >> >> On 11/12/12 16:46, DRAGE, Keith (Keith) wrote: >>> It might also be appropriate to answer the points I made in response, >> rather than just repeating the demand. >> >> Are you meaning to indicate the question of whether this document >> updates 3261? That seems to be the only point of contention you've >> raised, and I've heard scant support for your position on that topic. >> >> By way of contrast, Paul, Ben, Robert and I -- the only others who have >> engaged on this rather esoteric bit of IETF arcana -- have all stated >> what *I* believe are lucid and defensible reasons that this draft is >> required to update 3261. I'm certainly willing to consider the >> conversation to be ongoing, if there are new points to be made. >> Otherwise, this is clearly a non-technical matter of opinion about which >> people seem to have already reached their own conclusions, and the >> preponderance of the expressed opinion seems to put you in a minority >> class of size one. >> >> /a From christer.holmberg@ericsson.com Wed Nov 14 14:32:48 2012 Return-Path: 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 6220A21F8809 for ; Wed, 14 Nov 2012 14:32:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] 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 1JSiinzi3YUo for ; Wed, 14 Nov 2012 14:32:47 -0800 (PST) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 4C80521F86D1 for ; Wed, 14 Nov 2012 14:32:47 -0800 (PST) X-AuditID: c1b4fb30-b7f936d0000018b3-08-50a41c0db42b Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 74.65.06323.D0C14A05; Wed, 14 Nov 2012 23:32:46 +0100 (CET) Received: from ESESSHC006.ericsson.se (153.88.183.36) by esessmw0191.eemea.ericsson.se (153.88.115.84) with Microsoft SMTP Server (TLS) id 8.3.279.1; Wed, 14 Nov 2012 23:32:45 +0100 Received: from ESESSMB209.ericsson.se ([169.254.9.182]) by ESESSHC006.ericsson.se ([153.88.183.36]) with mapi id 14.02.0318.001; Wed, 14 Nov 2012 23:32:45 +0100 From: Christer Holmberg To: Adam Roach , "DRAGE, Keith (Keith)" Thread-Topic: [sipcore] Proposal: Call for adoption & WGLC: draft-roach-sipcore-priority-00 Thread-Index: AQHNwqI2sCcvkSpi80iyQSXt219Sg5fp6kne Date: Wed, 14 Nov 2012 22:32:44 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B02B755@ESESSMB209.ericsson.se> References: <50A160D8.8030602@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B02AD26@ESESSMB209.ericsson.se> <50A17929.5060005@alum.mit.edu> <50A1B736.7070708@nostrum.com> , <50A3F783.3020806@nostrum.com> In-Reply-To: <50A3F783.3020806@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.17] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpgkeLIzCtJLcpLzFFi42KZGfG3RpdPZkmAwdbLzBZ7/i5it3jaeJbR YsWGA6wW0046W3z9sYnNgdWj9dleVo+/7z8weSxZ8pPJY9bOJyweXy5/ZgtgjeKySUnNySxL LdK3S+DK2P7hE2PBRYmKJyc2sTcwvhLuYuTkkBAwkbi24BErhC0mceHeerYuRi4OIYGTjBJT 57SyQjg7GSVaXq9khnCWMEp0XH3N1MXIwcEmYCHR/U8bpFtEIEaiZfpxRhCbWaCRUWJ6rwuI LQwUb7r4nR2kXEQgVuJxmx5EuZHE/zkv2UFsFgFViY1PPoG18gp4S0x71Aa19zeTxP1DnYwg vZwC2hKtc91BahiBDv1+ag0TxCpxiVtP5jNBPCAgsWTPeWYIW1Ti5eN/rCCtEgKKEsv75SDK dSQW7P7EBmFrSyxb+JoZYq2gxMmZT1hAbCGgeMviCewTGCVmIdkwC0n7LCTts5C0L2BkWcXI npuYmZNebr6JERiLB7f8NtjBuOm+2CFGaQ4WJXFePdX9/kIC6YklqdmpqQWpRfFFpTmpxYcY mTg4pRoYpYX+zvl+7Fg+t+vhdc/EApdoHLh62LLF9J9UvqvvvA6/uXWzs//eUTqkkLF0Bn/3 obcvWq1lLlXGrs/ZVdtjfDm+NuQLk7NoxtJP4hJRn+UiJIJdPnuZMZoc5Xr1vkJ1Rn+gfmzO aesgX33Ni0seVTN1hRmkT74dxNnvv0lnhWrGKt/u1ZOUWIozEg21mIuKEwHI5ATIkwIAAA== Cc: SIPCORE , "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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 14 Nov 2012 22:32:48 -0000 Hi, If others don't think a template is needed, I will not argue for it. The im= portant thing is that the process for defining and registering new values i= s clear to the readers. Regards, Christer ________________________________________ From: Adam Roach [adam@nostrum.com] Sent: Wednesday, 14 November 2012 9:56 PM To: DRAGE, Keith (Keith) Cc: Paul Kyzivat; Christer Holmberg; SIPCORE; sipcore-ads@tools.ietf.org Subject: Re: [sipcore] Proposal: Call for adoption & WGLC: draft-roach-sipc= ore-priority-00 I don't think you're being ignored; I'm waiting to hear from other participants about whether we need a registration template. I really don't have a strong opinion on the topic. /a On 11/13/12 13:50, DRAGE, Keith (Keith) wrote: > I'm referring to these comments I made on the template proposal on 6th No= vember which I copy here: > > " 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 documen= t this is set as IETF review. At this level, an RFC has to exist and go thr= ough IETF community review. There will be enough people around in this proc= ess to ensure that all the information that people need to see outside the = IANA table actually exists. Conversely where we are allocating values on ex= pert review, a template could be essential if only to ensure the expert doi= ng the review has enough information available to perform the review; that = information may well exceed the information that needs to appear in the tem= plate 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 al= ignment with these points." > > Keith > >> -----Original Message----- >> From: Adam Roach [mailto:adam@nostrum.com] >> Sent: 13 November 2012 02:58 >> To: DRAGE, Keith (Keith) >> Cc: Paul Kyzivat; Christer Holmberg; SIPCORE; sipcore-ads@tools.ietf.org >> Subject: Re: [sipcore] Proposal: Call for adoption & WGLC: draft-roach- >> sipcore-priority-00 >> >> On 11/12/12 16:46, DRAGE, Keith (Keith) wrote: >>> It might also be appropriate to answer the points I made in response, >> rather than just repeating the demand. >> >> Are you meaning to indicate the question of whether this document >> updates 3261? That seems to be the only point of contention you've >> raised, and I've heard scant support for your position on that topic. >> >> By way of contrast, Paul, Ben, Robert and I -- the only others who have >> engaged on this rather esoteric bit of IETF arcana -- have all stated >> what *I* believe are lucid and defensible reasons that this draft is >> required to update 3261. I'm certainly willing to consider the >> conversation to be ongoing, if there are new points to be made. >> Otherwise, this is clearly a non-technical matter of opinion about which >> people seem to have already reached their own conclusions, and the >> preponderance of the expressed opinion seems to put you in a minority >> class of size one. >> >> /a From ben@nostrum.com Thu Nov 15 14:35:16 2012 Return-Path: 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 AAAB021F8A77 for ; Thu, 15 Nov 2012 14:35:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.568 X-Spam-Level: X-Spam-Status: No, score=-102.568 tagged_above=-999 required=5 tests=[AWL=0.032, 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 MAQNzeISBTi4 for ; Thu, 15 Nov 2012 14:35:16 -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 E8CFA21F84C8 for ; Thu, 15 Nov 2012 14:35:15 -0800 (PST) Received: from [10.0.1.9] (cpe-76-187-92-156.tx.res.rr.com [76.187.92.156]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id qAFMZDwZ005147 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 15 Nov 2012 16:35:14 -0600 (CST) (envelope-from ben@nostrum.com) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\)) From: Ben Campbell In-Reply-To: Date: Thu, 15 Nov 2012 16:35:16 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <50A160D8.8030602@alum.mit.edu> To: Paul Kyzivat X-Mailer: Apple Mail (2.1499) Received-SPF: pass (nostrum.com: 76.187.92.156 is authenticated by a trusted mechanism) Cc: SIPCORE , 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Nov 2012 22:35:16 -0000 On Nov 13, 2012, at 9:26 AM, Ben Campbell wrote: > I support adoption. I will provide WGLC comments separately. >=20 And here's that promised followup: I think the draft is pretty much ready to go as is. I've already stated = my position on updating 3261, and I have no opinion on the template = question. I concur with Adam that this draft should not attempt to fix the meaning = of any existing values. If it's important to do so, I think that should = be a separate effort. > On Nov 12, 2012, at 2:49 PM, Paul Kyzivat = wrote: >=20 >> PLEASE RESPOND TO THIS MESSAGE >>=20 >> 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.) >>=20 >> 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. >>=20 >> The intro to *this* document explains its purpose: >>=20 >> 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. >>=20 >> 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. >>=20 >> REQUESTED ACTIONS: >>=20 >> - indicate (ASAP) willingness, or not, for the sipcore wg to work on >> this problem, and adopt this draft as the basis for that work. >>=20 >> - provide any comments you have on this document before the end of >> the WGLC period (Friday, November 25.) >>=20 >> Thanks, >> Paul >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From christer.holmberg@ericsson.com Thu Nov 15 14:41:48 2012 Return-Path: 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 28BDC21F8A5A for ; Thu, 15 Nov 2012 14:41:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] 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 HbYwK0+Ual6y for ; Thu, 15 Nov 2012 14:41:47 -0800 (PST) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 5E38F21F8A21 for ; Thu, 15 Nov 2012 14:41:47 -0800 (PST) X-AuditID: c1b4fb2d-b7f1e6d000002d2c-2a-50a56fa93062 Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id CC.1F.11564.9AF65A05; Thu, 15 Nov 2012 23:41:46 +0100 (CET) Received: from ESESSHC009.ericsson.se (153.88.183.45) by esessmw0237.eemea.ericsson.se (153.88.115.90) with Microsoft SMTP Server (TLS) id 8.3.279.1; Thu, 15 Nov 2012 23:41:45 +0100 Received: from ESESSMB209.ericsson.se ([169.254.9.182]) by ESESSHC009.ericsson.se ([153.88.183.45]) with mapi id 14.02.0318.001; Thu, 15 Nov 2012 23:41:45 +0100 From: Christer Holmberg To: Ben Campbell , Paul Kyzivat Thread-Topic: [sipcore] Proposal: Call for adoption & WGLC: draft-roach-sipcore-priority-00 Thread-Index: AQHNwRc5D5NKZt/KZ0Gbr0k4dSgPfpfn06UAgAOcYACAABJgwg== Date: Thu, 15 Nov 2012 22:41:45 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B02C1C1@ESESSMB209.ericsson.se> References: <50A160D8.8030602@alum.mit.edu> , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.18] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrBLMWRmVeSWpSXmKPExsUyM+Jvje6q/KUBBk2/2Szmd55mt1ix4QCr xbSTzhZff2xic2Dx+Pv+A5PHkiU/mTxm7XzC4vHl8me2AJYoLpuU1JzMstQifbsErozjR6Yz FZxjrDhz+yJjA+Mcxi5GTg4JAROJrfNvs0DYYhIX7q1n62Lk4hASOMkocXbeRGYIZyejxJYN fVCZJYwS7bteMnUxcnCwCVhIdP/TBukWEfCQmPXwHCuIzSwQLTF39R4WkBJhgRiJe7OkIUpi JSbdf8kOYTtJvPhzjBnEZhFQlbh8ZT9YK6+At8Tfnl9QqyYzSmyf/B+siFPAXmLGszNgNiPQ pd9PrWGC2CUucevJfCaIDwQkluw5zwxhi0q8fPyPFcJWlPj4ah8jRL2OxILdn9ggbG2JZQtf M0MsFpQ4OfMJOCSEgOItiyewT2CUmIVkxSwk7bOQtM9C0r6AkWUVI3tuYmZOernhJkZg7B3c 8lt3B+OpcyKHGKU5WJTEebmS9vsLCaQnlqRmp6YWpBbFF5XmpBYfYmTi4JRqYOTIFotW22+n X6izU1Q/p4k/x7H77qnbRvHhtq9blxV9Dz+sZvPTtUhrvkGY1s0Jr7aGKAoXH9+8x/Jj6awL VpX3fx3Ibw2MnZrTWpmXNVlIdPXMh4equT1tFtXN+unTfYZpaUbJ9CZNx2sL7/XNzUuw0ilW mrplzxPeCZlHglZUNdh89D00S4mlOCPRUIu5qDgRANZAHxqLAgAA Cc: SIPCORE , "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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Nov 2012 22:41:48 -0000 >I concur with Adam that this draft should not attempt to fix the meaning o= f any existing values. If it's important to do so, I think that should be a= separate effort. + 1 Regards, Christer From hannes.tschofenig@gmx.net Mon Nov 19 01:04:58 2012 Return-Path: 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 F193521F8462 for ; Mon, 19 Nov 2012 01:04:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.554 X-Spam-Level: X-Spam-Status: No, score=-102.554 tagged_above=-999 required=5 tests=[AWL=0.045, BAYES_00=-2.599, 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 W6fkiYOP59Yf for ; Mon, 19 Nov 2012 01:04:58 -0800 (PST) Received: from mailout-de.gmx.net (mailout-de.gmx.net [213.165.64.22]) by ietfa.amsl.com (Postfix) with SMTP id 14F2B21F847C for ; Mon, 19 Nov 2012 01:04:57 -0800 (PST) Received: (qmail invoked by alias); 19 Nov 2012 09:04:09 -0000 Received: from a88-115-216-191.elisa-laajakaista.fi (EHLO [192.168.100.114]) [88.115.216.191] by mail.gmx.net (mp034) with SMTP; 19 Nov 2012 10:04:09 +0100 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX19CFq1UPLhCIoEesbvg1h5enzsXKsPkBGmoX/GzNy mnManBC2pjCGfj Mime-Version: 1.0 (Apple Message framework v1085) Content-Type: text/plain; charset=us-ascii From: Hannes Tschofenig In-Reply-To: <50A160D8.8030602@alum.mit.edu> Date: Mon, 19 Nov 2012 11:04:05 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <995BCBA0-032D-4928-82CB-1FEF91F8FCF5@gmx.net> References: <50A160D8.8030602@alum.mit.edu> To: Paul Kyzivat X-Mailer: Apple Mail (2.1085) X-Y-GMX-Trusted: 0 Cc: SIPCORE , 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Nov 2012 09:04:59 -0000 So, what's the status of the document?=20 When does it become a WG item (given the support it has received)? When will the WGLC be started? On Nov 12, 2012, at 10:49 PM, Paul Kyzivat wrote: > PLEASE RESPOND TO THIS MESSAGE >=20 > 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.) >=20 > 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. >=20 > The intro to *this* document explains its purpose: >=20 > 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. >=20 > 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. >=20 > REQUESTED ACTIONS: >=20 > - indicate (ASAP) willingness, or not, for the sipcore wg to work on > this problem, and adopt this draft as the basis for that work. >=20 > - provide any comments you have on this document before the end of > the WGLC period (Friday, November 25.) >=20 > Thanks, > Paul > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From pkyzivat@alum.mit.edu Mon Nov 19 08:18:53 2012 Return-Path: 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 D1B0A21F86A8 for ; Mon, 19 Nov 2012 08:18:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.397 X-Spam-Level: X-Spam-Status: No, score=-0.397 tagged_above=-999 required=5 tests=[AWL=0.040, 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 HSZor0E-ZohN for ; Mon, 19 Nov 2012 08:18:52 -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 4FF7121F862B for ; Mon, 19 Nov 2012 08:18:51 -0800 (PST) Received: from omta11.westchester.pa.mail.comcast.net ([76.96.62.36]) by qmta03.westchester.pa.mail.comcast.net with comcast id RTEk1k08d0mv7h053UJq7n; Mon, 19 Nov 2012 16:18:50 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta11.westchester.pa.mail.comcast.net with comcast id RUJp1k01G3ZTu2S3XUJqhZ; Mon, 19 Nov 2012 16:18:50 +0000 Message-ID: <50AA5BE9.2000605@alum.mit.edu> Date: Mon, 19 Nov 2012 11:18:49 -0500 From: Paul Kyzivat 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: Hannes Tschofenig References: <50A160D8.8030602@alum.mit.edu> <995BCBA0-032D-4928-82CB-1FEF91F8FCF5@gmx.net> In-Reply-To: <995BCBA0-032D-4928-82CB-1FEF91F8FCF5@gmx.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: SIPCORE , 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Nov 2012 16:18:53 -0000 On 11/19/12 4:04 AM, Hannes Tschofenig wrote: > So, what's the status of the document? > When does it become a WG item (given the support it has received)? > When will the WGLC be started? I called a simultaneous request for approval to adopt and WGLC. It is to be completed Sunday Nov 25. There have been a number of comments. (Thanks to those who have commented.) I have seen no objections to adoption, so I expect that to happen as soon as the period is over. We will have to look at the comments to see what changes, if any, need to be made to the draft. Depending on the extent of those we may or may not need another review. But based on what I have seen I doubt we will need a lot of time after Nov 25 to finalize it. Thanks, Paul (as co-chair) > On Nov 12, 2012, at 10:49 PM, Paul Kyzivat wrote: > >> 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 > > From wwwrun@rfc-editor.org Fri Nov 23 09:50:50 2012 Return-Path: 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 9600321F85A1; Fri, 23 Nov 2012 09:50:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.084 X-Spam-Level: X-Spam-Status: No, score=-102.084 tagged_above=-999 required=5 tests=[AWL=-0.084, BAYES_00=-2.599, J_CHICKENPOX_93=0.6, NO_RELAYS=-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 59hXTgLZx9hF; Fri, 23 Nov 2012 09:50:49 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id ABED021F8441; Fri, 23 Nov 2012 09:50:48 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 909F3B1E00A; Fri, 23 Nov 2012 09:43:14 -0800 (PST) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20121123174314.909F3B1E00A@rfc-editor.org> Date: Fri, 23 Nov 2012 09:43:14 -0800 (PST) Cc: sipcore@ietf.org, rfc-editor@rfc-editor.org Subject: [sipcore] RFC 6809 on Mechanism to Indicate Support of Features and Capabilities in the Session Initiation Protocol (SIP) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Nov 2012 17:50:50 -0000 A new Request for Comments is now available in online RFC libraries. RFC 6809 Title: Mechanism to Indicate Support of Features and Capabilities in the Session Initiation Protocol (SIP) Author: C. Holmberg, I. Sedlacek, H. Kaplan Status: Standards Track Stream: IETF Date: November 2012 Mailbox: christer.holmberg@ericsson.com, ivo.sedlacek@ericsson.com, hkaplan@acmepacket.com Pages: 19 Characters: 40053 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-sipcore-proxy-feature-12.txt URL: http://www.rfc-editor.org/rfc/rfc6809.txt This specification defines a new SIP header field, Feature-Caps. The Feature-Caps header field conveys feature-capability indicators that are used to indicate support of features and capabilities for SIP entities that are not represented by the Uniform Resource Identifier (URI) of the Contact header field. SIP entities that are represented by the URI of the SIP Contact header field can convey media feature tags in the Contact header field to indicate support of features and capabilities. This specification also defines feature-capability indicators and creates a new IANA registry, "Proxy-Feature Feature-Capability Indicator Trees", for registering feature-capability indicators. [STANDARDS-TRACK] This document is a product of the Session Initiation Protocol Core Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From christer.holmberg@ericsson.com Sat Nov 24 05:20:59 2012 Return-Path: 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 1B3FB21F84DD for ; Sat, 24 Nov 2012 05:20:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.724 X-Spam-Level: X-Spam-Status: No, score=-5.724 tagged_above=-999 required=5 tests=[AWL=-0.075, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_93=0.6, RCVD_IN_DNSWL_MED=-4] 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 6c75CO+mVY0y for ; Sat, 24 Nov 2012 05:20:58 -0800 (PST) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 00E6121F8449 for ; Sat, 24 Nov 2012 05:20:57 -0800 (PST) X-AuditID: c1b4fb30-b7f936d0000018b3-47-50b0c9b7b330 Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 7C.4A.06323.7B9C0B05; Sat, 24 Nov 2012 14:20:56 +0100 (CET) Received: from ESESSHC010.ericsson.se (153.88.183.48) by esessmw0197.eemea.ericsson.se (153.88.115.87) with Microsoft SMTP Server (TLS) id 8.3.279.1; Sat, 24 Nov 2012 14:20:55 +0100 Received: from ESESSMB209.ericsson.se ([169.254.9.119]) by ESESSHC010.ericsson.se ([153.88.183.48]) with mapi id 14.02.0318.001; Sat, 24 Nov 2012 14:20:54 +0100 From: Christer Holmberg To: "'sipcore@ietf.org'" Thread-Topic: [sipcore] RFC 6809 on Mechanism to Indicate Support of Features and Capabilities in the Session Initiation Protocol (SIP) Thread-Index: AQHNyaOPPm8az+k0k0q1ZlrxyXJz6pf4+Obg Date: Sat, 24 Nov 2012 13:20:54 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B0442AF@ESESSMB209.ericsson.se> References: <20121123174314.909F3B1E00A@rfc-editor.org> In-Reply-To: <20121123174314.909F3B1E00A@rfc-editor.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.18] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrHLMWRmVeSWpSXmKPExsUyM+Jvje6OkxsCDH5OZLH4+mMTmwOjx5Il P5kCGKO4bFJSczLLUov07RK4MlZMZCvYKF2x5s409gbGDaJdjJwcEgImEo/2L2KCsMUkLtxb zwZiCwmcZJS4Myupi5ELyN7JKLH3zV4mCGcJo8SxHzMZuxg5ONgELCS6/2mDNIgIaEt8O7aS EaRGWKCDUaJ92zswR0Sgk1Hi/o/dLBBVRhJT/h9mBmlmEVCVuNMnCxLmFfCW6H95gRFis7nE 26OtrCA2J9D8HVcbwGxGoOu+n1oDdimzgLjErSfzoa4WkFiy5zwzhC0q8fLxP1YIW1Hi46t9 jBD1OhILdn9ig7C1JZYtfM0MsVdQ4uTMJywQe7UlWhZPYJ/AKD4LyYpZSNpnIWmfhaR9ASPL Kkb23MTMnPRy802MwDg5uOW3wQ7GTffFDjFKc7AoifPqqe73FxJITyxJzU5NLUgtii8qzUkt PsTIxMEp1cAYb2J4oeRwiUYaW5ZUwzXeiKP2ZVP5PvYn2MauKbrE3Fext6Be8NsizmN/b5Xp hG37d+zenLOJJpv+PY3e8nGH+GwO1eqc+b0d1w8elOaSSHsu84Z5H6/CyTXMEvx+q46c3nbn tELz7j9C0b/KtHmn7Ui2lXzd9o7h0vwDy35WCy8/+qPX7GuwEktxRqKhFnNRcSIA1cE8WmEC AAA= Subject: Re: [sipcore] RFC 6809 on Mechanism to Indicate Support of Features and Capabilities in the Session Initiation Protocol (SIP) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Nov 2012 13:20:59 -0000 =20 Hi, I would like to say Thank You to everyone who provided comments and input a= s part of the work on proxy-feature (first the requirements, and then the m= echanism). Best regards, Christer -----Original Message----- From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behalf = Of rfc-editor@rfc-editor.org Sent: 23. marraskuuta 2012 19:43 To: ietf-announce@ietf.org; rfc-dist@rfc-editor.org Cc: sipcore@ietf.org; rfc-editor@rfc-editor.org Subject: [sipcore] RFC 6809 on Mechanism to Indicate Support of Features an= d Capabilities in the Session Initiation Protocol (SIP) A new Request for Comments is now available in online RFC libraries. =20 RFC 6809 Title: Mechanism to Indicate Support of=20 Features and Capabilities in the Session=20 Initiation Protocol (SIP)=20 Author: C. Holmberg, I. Sedlacek, H. Kaplan Status: Standards Track Stream: IETF Date: November 2012 Mailbox: christer.holmberg@ericsson.com,=20 ivo.sedlacek@ericsson.com,=20 hkaplan@acmepacket.com Pages: 19 Characters: 40053 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-sipcore-proxy-feature-12.txt URL: http://www.rfc-editor.org/rfc/rfc6809.txt This specification defines a new SIP header field, Feature-Caps. The Featu= re-Caps header field conveys feature-capability indicators that are used to= indicate support of features and capabilities for SIP entities that are no= t represented by the Uniform Resource Identifier (URI) of the Contact header field. SIP entities that are represented by the URI of the SIP Contact header fiel= d can convey media feature tags in the Contact header field to indicate sup= port of features and capabilities. This specification also defines feature-capability indicators and creates a= new IANA registry, "Proxy-Feature Feature-Capability Indicator Trees", for= registering feature-capability indicators. [STANDARDS-TRACK] This document is a product of the Session Initiation Protocol Core Working = Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protoc= ol for the Internet community,and requests discussion and suggestions for i= mprovements. Please refer to the current edition of the Internet Official = Protocol Standards (STD 1) for the standardization state and status of this= protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author = of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifical= ly noted otherwise on the RFC itself, all RFCs are for unlimited distributi= on. The RFC Editor Team Association Management Solutions, LLC _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore From pkyzivat@alum.mit.edu Mon Nov 26 07:23:19 2012 Return-Path: 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 EB6B721F8542 for ; Mon, 26 Nov 2012 07:23:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.137 X-Spam-Level: X-Spam-Status: No, score=-0.137 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_NET=0.611, J_CHICKENPOX_93=0.6, 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 d9Ax8fQMjowj for ; Mon, 26 Nov 2012 07:23:18 -0800 (PST) Received: from qmta13.westchester.pa.mail.comcast.net (qmta13.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:243]) by ietfa.amsl.com (Postfix) with ESMTP id DB39121F852A for ; Mon, 26 Nov 2012 07:23:16 -0800 (PST) Received: from omta13.westchester.pa.mail.comcast.net ([76.96.62.52]) by qmta13.westchester.pa.mail.comcast.net with comcast id UDfL1k00517dt5G5DFPFRL; Mon, 26 Nov 2012 15:23:15 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta13.westchester.pa.mail.comcast.net with comcast id UFPF1k00A3ZTu2S3ZFPF6R; Mon, 26 Nov 2012 15:23:15 +0000 Message-ID: <50B38961.8050601@alum.mit.edu> Date: Mon, 26 Nov 2012 10:23:13 -0500 From: Paul Kyzivat 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: <20121123174314.909F3B1E00A@rfc-editor.org> <7594FB04B1934943A5C02806D1A2204B0442AF@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B0442AF@ESESSMB209.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [sipcore] RFC 6809 on Mechanism to Indicate Support of Features and Capabilities in the Session Initiation Protocol (SIP) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Nov 2012 15:23:19 -0000 Congratulations Christer. Paul On 11/24/12 8:20 AM, Christer Holmberg wrote: > > Hi, > > I would like to say Thank You to everyone who provided comments and input as part of the work on proxy-feature (first the requirements, and then the mechanism). > > Best regards, > > Christer > > > > -----Original Message----- > From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behalf Of rfc-editor@rfc-editor.org > Sent: 23. marraskuuta 2012 19:43 > To: ietf-announce@ietf.org; rfc-dist@rfc-editor.org > Cc: sipcore@ietf.org; rfc-editor@rfc-editor.org > Subject: [sipcore] RFC 6809 on Mechanism to Indicate Support of Features and Capabilities in the Session Initiation Protocol (SIP) > > > A new Request for Comments is now available in online RFC libraries. > > > RFC 6809 > > Title: Mechanism to Indicate Support of > Features and Capabilities in the Session > Initiation Protocol (SIP) > Author: C. Holmberg, I. Sedlacek, > H. Kaplan > Status: Standards Track > Stream: IETF > Date: November 2012 > Mailbox: christer.holmberg@ericsson.com, > ivo.sedlacek@ericsson.com, > hkaplan@acmepacket.com > Pages: 19 > Characters: 40053 > Updates/Obsoletes/SeeAlso: None > > I-D Tag: draft-ietf-sipcore-proxy-feature-12.txt > > URL: http://www.rfc-editor.org/rfc/rfc6809.txt > > This specification defines a new SIP header field, Feature-Caps. The Feature-Caps header field conveys feature-capability indicators that are used to indicate support of features and capabilities for SIP entities that are not represented by the Uniform Resource Identifier > (URI) of the Contact header field. > > SIP entities that are represented by the URI of the SIP Contact header field can convey media feature tags in the Contact header field to indicate support of features and capabilities. > > This specification also defines feature-capability indicators and creates a new IANA registry, "Proxy-Feature Feature-Capability Indicator Trees", for registering feature-capability indicators. > [STANDARDS-TRACK] > > This document is a product of the Session Initiation Protocol Core Working Group of the IETF. > > This is now a Proposed Standard Protocol. > > STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. > > This announcement is sent to the IETF-Announce and rfc-dist lists. > To subscribe or unsubscribe, see > http://www.ietf.org/mailman/listinfo/ietf-announce > http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist > > For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. > For downloading RFCs, see http://www.rfc-editor.org/rfc.html. > > Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. > > > The RFC Editor Team > Association Management Solutions, LLC > > > _______________________________________________ > 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 > From rjsparks@nostrum.com Mon Nov 26 07:35:13 2012 Return-Path: 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 B7B0621F85B4 for ; Mon, 26 Nov 2012 07:35:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[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 kINBZ7bS-uls for ; Mon, 26 Nov 2012 07:35:12 -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 0E91E21F85B3 for ; Mon, 26 Nov 2012 07:35:10 -0800 (PST) Received: from unnumerable.local (pool-173-71-45-100.dllstx.fios.verizon.net [173.71.45.100]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id qAQFYxix027044 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Mon, 26 Nov 2012 09:35:05 -0600 (CST) (envelope-from rjsparks@nostrum.com) Message-ID: <50B38C22.9080307@nostrum.com> Date: Mon, 26 Nov 2012 09:34:58 -0600 From: Robert Sparks User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: "sipcore@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 173.71.45.100 is authenticated by a trusted mechanism) Subject: [sipcore] Registration for SIPit 30 is open X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Nov 2012 15:35:13 -0000 Registration for SIPit 30 is open at http://www.regonline.com/sipit30 SIPit 30 will be hosted by Cisco in Raleigh-Durham, North Carolina, February 18-22 2013. Additional details are available at http://www.sipit.net. See you there! RjS From rjsparks@nostrum.com Tue Nov 27 14:36:05 2012 Return-Path: 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 5D73821F84DD for ; Tue, 27 Nov 2012 14:36:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.3 X-Spam-Level: X-Spam-Status: No, score=-102.3 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_92=0.6, 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 cRWowSVaucvQ for ; Tue, 27 Nov 2012 14:36:04 -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 BDC2021F84BA for ; Tue, 27 Nov 2012 14:36:03 -0800 (PST) Received: from unnumerable.local (pool-173-71-45-100.dllstx.fios.verizon.net [173.71.45.100]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id qARMZtwt014850 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Tue, 27 Nov 2012 16:35:59 -0600 (CST) (envelope-from rjsparks@nostrum.com) Message-ID: <50B5404A.20807@nostrum.com> Date: Tue, 27 Nov 2012 16:35:54 -0600 From: Robert Sparks User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:16.0) Gecko/20121026 Thunderbird/16.0.2 MIME-Version: 1.0 To: "sipcore@ietf.org" , draft-ietf-sipcore-sip-websocket@tools.ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 173.71.45.100 is authenticated by a trusted mechanism) Subject: [sipcore] AD Review: draft-ietf-sipcore-sip-websocket-06.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Nov 2012 22:36:05 -0000 AD Review: draft-ietf-sipcore-sip-websocket-06.txt Summary: There are a few issues to address with a revised ID before progressing to IETF LC Overall, this is a very well written, easy to read draft. Thank you for making it this clear. There are a couple of small problems to correct, and a few issues to consider before moving forward: * Section 6 starts with "_This section is non-normative_", but then contains normative statements. RECOMMENDED is the same as SHOULD. This is a stronger requirement for Ping than RFC 6455 places on websockets. If it was the intent to restate what RFC 6455 required, the language should be "RFC 6455 says to...". If it was the intent to make a stronger requirement, then this section _is_ normative. To avoid the appearance of placing a new normative requirement on the implementation of keep-alives, I suggest replacing the next to last paragraph of this section with "The indication and use of the CRLF NAT keep-alive mechanism defined for SIP connection-oriented transports in RFC5626 section 3.5.1 or RFC6223 are, of course, usable over the transport defined in this specification." * Section 7 starts with "_This section is non-normative_" but then contain normative statements. Section 7 could be rewritten to not use 2119, but that would take more than changing the words to lower case. The gist is 'the SIP and WebSocket specs tell you these things.' It also currently confuses SIP Digest with HTTP Digest, and incorrectly suggests that SIP Digest is a SHOULD strength requirement in 3261 (it is a MUST there). It would be better to say "This section describes how authentication is acheived through the requirements in RFCs 6445, 6265, and 3261." The MAY in paragraph 3 can be changed to "is allowed to". The last paragraph can say ...", authentication can be requested at the SIP protocol level. Note that RFC3261 requires that all SIP implementations (which includes implementations of this specification) implement Digest Authorization (see RFC3261, Section 26.3.1)." * The document should more explicitly call out that none of SIP TLS certificate checks specified in RFC3261 or RFC5922 will be made when using this transport. Instead, only the checks specified by RFC6455 will be made. The certificates that are appropriate for SIP over TLS over TCP will probably not be appropriate for SIP over secure websockets (it would only be coincidence if the same cert worked - the two checks will look in different places in the certificate). * Should there be some additional discussion of what an element should do if someone clicks on "sip:foo.example.com;transport=ws" or receives that in a contact in a 302 or in a Refer-To: header field? To: header field? Taken to an extreme, what's a proxy that understands sip over websockets supposed to do if it gets a message containing Route header fields (think preloaded routes) where the next route value is for a transport=ws hop that a connection doesn't yet exist for? * I'm ok proceeding with the IANA Considerations sections as they currently stand, but I wonder if instead of what's in 10.3 and 10.4, this document should create a new registry for the transport values. That way someone could search the registry for the strings "WS" or "WSS" and find something meaningful. Nits: - RFCs never change. Years from now, this won't be "new". Please consider removing "new" from the abstract and the Introduction. The abstract would be stronger if you replaced "enable usage of SIP in new scenarios" with "enable usage of SIP in web-oriented deployments." - In the introduction, you say "a [new] reliable and message boundary transport". Did you mean "a reliable, and message-boundary preserving, transport" ? - At the end of 5.2.3, s/regardless the Via/regardless of whether the Via/ - In A.1, to further avoid this section appearing to be normative, I suggest changing "Therefore the SIP WebSocket Client constructs" to "A SIP WebSocket client running in such an environment can construct". - In section 6, what is the value of the sentence "A future WebSocket protocol extension providing a similar keep alive mechanism could also be used"? This specification says the same thing if the sentence is removed, and I suggest removing it. - (no change suggested - just pointing something out for future work) The ABNF in 5.2.1 could have used =/ and not have restated the other values. It would have been nice if 5.2.2 could have as well, but the way transport-param is defined in RFC3261 prevents it. It's probably better to keep the form of 5.2.1 and 5.2.2 the same. From pkyzivat@alum.mit.edu Wed Nov 28 09:30:14 2012 Return-Path: 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 7D75521F888F for ; Wed, 28 Nov 2012 09:30:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.4 X-Spam-Level: X-Spam-Status: No, score=-0.4 tagged_above=-999 required=5 tests=[AWL=0.038, 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 QwxjtCum22XA for ; Wed, 28 Nov 2012 09:30:12 -0800 (PST) Received: from qmta05.westchester.pa.mail.comcast.net (qmta05.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:48]) by ietfa.amsl.com (Postfix) with ESMTP id D6C6F21F8880 for ; Wed, 28 Nov 2012 09:30:11 -0800 (PST) Received: from omta15.westchester.pa.mail.comcast.net ([76.96.62.87]) by qmta05.westchester.pa.mail.comcast.net with comcast id V10H1k00B1swQuc555WBjf; Wed, 28 Nov 2012 17:30:11 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta15.westchester.pa.mail.comcast.net with comcast id V5WB1k0083ZTu2S3b5WBsT; Wed, 28 Nov 2012 17:30:11 +0000 Message-ID: <50B64A22.3090102@alum.mit.edu> Date: Wed, 28 Nov 2012 12:30:10 -0500 From: Paul Kyzivat 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: <50B5404A.20807@nostrum.com> In-Reply-To: <50B5404A.20807@nostrum.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1354123811; bh=p6LYJup4u1QgRLfr0y5HnFllsjnQX+jm3bsl3WFmoKg=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=oVuG0zvW+rV44JNNNe3HNmQlhITVdn1JJJhSHQhUgfjS0gdBSYDAVPEl6qwMTTHwy N0O0dUIsOraI1lwNLxFrIXkd/0azovSi3nr09a2qK7cl9HtwQKu8HpvkXg8jwdMRmj kn4u05VhG2how17cvN5Cpr9qomBENN20aggdf6LiTnfUrYeLt1fdRDBAUYam8fZQL1 ldETw+gqW+JL1ra6x5eRiojoDvVXeCDhhZ27hlkTey1BqSnwE29q+4fLXHAktRE0NC HTk/C3gtGxli+V75lG6xp2Bsf37rWRL6Ykhm4q3gNc1+5qmo4RjkoZXtjEeUB8h8HX Wp4kI7TTfv4tA== Subject: Re: [sipcore] AD Review: draft-ietf-sipcore-sip-websocket-06.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Nov 2012 17:30:14 -0000 On 11/27/12 5:35 PM, Robert Sparks wrote: > - (no change suggested - just pointing something out for future work) > The ABNF in 5.2.1 could have used =/ and not have restated the other > values. > It would have been nice if 5.2.2 could have as well, but the way > transport-param > is defined in RFC3261 prevents it. It's probably better to keep the > form of 5.2.1 > and 5.2.2 the same. There is a way to use =/ for both: transport =/ "WS" / "WSS" transport-param =/ "transport=" "ws" This isn't pretty for transport-param, but it works and repeats less. Whether this is better or worse than what is currently in the draft is a matter of taste. IMO it is marginally better. This is definitely a lesson for writing ABNF in the future, so that it is extensible. (Maybe we need an ABNF directorate and an ABNF review of each RFC.) Thanks, Paul From pkyzivat@alum.mit.edu Wed Nov 28 14:03:51 2012 Return-Path: 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 8511021F885C for ; Wed, 28 Nov 2012 14:03:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.373 X-Spam-Level: X-Spam-Status: No, score=-0.373 tagged_above=-999 required=5 tests=[AWL=0.064, 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 GpDN+hfMO5Lu for ; Wed, 28 Nov 2012 14:03:51 -0800 (PST) Received: from qmta14.westchester.pa.mail.comcast.net (qmta14.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:212]) by ietfa.amsl.com (Postfix) with ESMTP id 09A3221F8823 for ; Wed, 28 Nov 2012 14:03:48 -0800 (PST) Received: from omta13.westchester.pa.mail.comcast.net ([76.96.62.52]) by qmta14.westchester.pa.mail.comcast.net with comcast id V8xv1k00317dt5G5EA3oJ9; Wed, 28 Nov 2012 22:03:48 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta13.westchester.pa.mail.comcast.net with comcast id VA3n1k01G3ZTu2S3ZA3nkN; Wed, 28 Nov 2012 22:03:48 +0000 Message-ID: <50B68A43.8040605@alum.mit.edu> Date: Wed, 28 Nov 2012 17:03:47 -0500 From: Paul Kyzivat 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: <50A160D8.8030602@alum.mit.edu> In-Reply-To: <50A160D8.8030602@alum.mit.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1354140228; bh=W59T89PYQMyVHV9oltFCAYVL2jqL6VEwHmeiyF3WC+M=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=c8YWWn0QfVQpjZVjVCryUvPwtLgFxMW6Z+BCjjIPy3uTCQe7s8N9fdMnzvVc0k+sH JVxtp8N/aJ5Jow6uWH0IYF2e19VdAoJaZAphjdqdT4tiBfAtP0s8OBwP/RG2fLTzAy wJgw8nMbH+ftLXMHykSKwFubzl2EVVtKepforWFzFs3FfMEnSWAeuS7wG6RfYS6gcn iwgQAPnOckLnBCYB2JJo/xEs9gKErC5dxGu1xoOc9baOVCuA7LDC5rfPzAtoo+QMAb BH/zQUcTPGIa5isyPxlpq2MhPjufY/clLoOEmT45HL5QyYx4IrmaIqxfjmYjTed40a 9AjZ/V2i08zpw== 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Nov 2012 22:03:51 -0000 The WGLC and adoption deadline has now passed for draft-roach-sipcore-priority-00. Nine people (other than chairs and authors) made meaningful comments. I conclude there is consensus to adopt this draft as a wg document. Regarding WGLC, two notable issues were raised, and I don't yet see a clear consensus on those issues: - should there be a registration template? Christer advocates this, Keith opposes, Adam finds it unnecessary. - should this document also spell out the semantics of all the priority values defined in 3261? (Currently it only defines "emergency".) Dan, James, and Roy in favor, Adam and I prefer not to do it *in this document*. So, I will ask Adam to submit a wg draft version of this document, otherwise unchanged. While he is doing that, I would like to get a broader consensus on the issues above. I'll post a separate question on each of those, to keep the discussions separate. Thanks, Paul On 11/12/12 3:49 PM, Paul Kyzivat wrote: > 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 > From pkyzivat@alum.mit.edu Wed Nov 28 14:21:43 2012 Return-Path: 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 633B321F8940 for ; Wed, 28 Nov 2012 14:21:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.377 X-Spam-Level: X-Spam-Status: No, score=-0.377 tagged_above=-999 required=5 tests=[AWL=0.060, 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 T64HYQ9QDVyF for ; Wed, 28 Nov 2012 14:21:42 -0800 (PST) Received: from qmta13.westchester.pa.mail.comcast.net (qmta13.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:44:76:96:59:243]) by ietfa.amsl.com (Postfix) with ESMTP id EC3BA21F893B for ; Wed, 28 Nov 2012 14:21:41 -0800 (PST) Received: from omta12.westchester.pa.mail.comcast.net ([76.96.62.44]) by qmta13.westchester.pa.mail.comcast.net with comcast id V2kS1k0020xGWP85DAMhxF; Wed, 28 Nov 2012 22:21:41 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta12.westchester.pa.mail.comcast.net with comcast id VAMh1k00C3ZTu2S3YAMhDl; Wed, 28 Nov 2012 22:21:41 +0000 Message-ID: <50B68E74.3060307@alum.mit.edu> Date: Wed, 28 Nov 2012 17:21:40 -0500 From: Paul Kyzivat 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: <50A160D8.8030602@alum.mit.edu> <50B68A43.8040605@alum.mit.edu> In-Reply-To: <50B68A43.8040605@alum.mit.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1354141301; bh=LXx4VJskhcZuKnNp/tQmHsymQNzNvAdrpBHcRWnbgdo=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=gDexE8ZXo14lZ8Eyo/DuuaoSuKKTDqBo0zqT5pTBdROwf5I9DyGan2hhh/+0/wN6h FC7e733uGwMMi0K5TNg+LHjGcBXyZam3BWLmJUk2mGxCXB37IxfckPA6+mP/jxRlju dfyIYAp5G3QTg4z8ZGLmBurbCwPWxFf/N3Z829sONpLeyr+XKI82qoDi/IG2zOV4Ux 0jysfVJGgYihsqPXB4gY2owxlg6UQJHpPHy8oPJ092+QYnA8wLW7MNAeqXp7ufa9ue JmNs+Dg7tRYHryXpyiKYi0BoaiQaOPn3M0rkbSNJWAmltv9cGyjCQO12QBZlcoL3Qp WRbmaUAAZ+xzQ== Subject: [sipcore] consensus call: draft-roach-sipcore-priority-00: IANA registration template needed? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Nov 2012 22:21:43 -0000 We are in the process of adopting draft-roach-sipcore-priority-00 as a wg document. We already ran a WGLC on it in anticipation of the adoption. One issue raised during the WGLC was whether the document should include some sort of IANA registration template. Christer proposed this, and Keith opposed it. Christer failed to specify what he wanted to see in this template. The existing document specifies what the registry should contain: A "priority" name and a document reference. "IETF Review" is required for adding new values, which ensures that there will be an RFC to reference. So presumably the template would include at least these two values. Please indicate if you think the draft is ok as-is, or should be revised to include a registration template. If you favor a template, please indicate what you think it should contain. Thanks, Paul On 11/28/12 5:03 PM, Paul Kyzivat wrote: > The WGLC and adoption deadline has now passed for > draft-roach-sipcore-priority-00. Nine people (other than chairs and > authors) made meaningful comments. > > I conclude there is consensus to adopt this draft as a wg document. > > Regarding WGLC, two notable issues were raised, and I don't yet see a > clear consensus on those issues: > > - should there be a registration template? > Christer advocates this, Keith opposes, Adam finds it unnecessary. > > - should this document also spell out the semantics of all the priority > values defined in 3261? (Currently it only defines "emergency".) > Dan, James, and Roy in favor, Adam and I prefer not to do it *in this > document*. > > So, I will ask Adam to submit a wg draft version of this document, > otherwise unchanged. > > While he is doing that, I would like to get a broader consensus on the > issues above. I'll post a separate question on each of those, to keep > the discussions separate. > > Thanks, > Paul > > On 11/12/12 3:49 PM, Paul Kyzivat wrote: >> 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 > From pkyzivat@alum.mit.edu Wed Nov 28 14:41:10 2012 Return-Path: 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 E97FE21F8852 for ; Wed, 28 Nov 2012 14:41:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.381 X-Spam-Level: X-Spam-Status: No, score=-0.381 tagged_above=-999 required=5 tests=[AWL=0.056, 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 LfbaH0XoQG7p for ; Wed, 28 Nov 2012 14:41:10 -0800 (PST) Received: from qmta08.westchester.pa.mail.comcast.net (qmta08.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:80]) by ietfa.amsl.com (Postfix) with ESMTP id 2436021F849F for ; Wed, 28 Nov 2012 14:41:09 -0800 (PST) Received: from omta02.westchester.pa.mail.comcast.net ([76.96.62.19]) by qmta08.westchester.pa.mail.comcast.net with comcast id VA6A1k0030QuhwU58Ah9fT; Wed, 28 Nov 2012 22:41:09 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta02.westchester.pa.mail.comcast.net with comcast id VAh91k00C3ZTu2S3NAh9VE; Wed, 28 Nov 2012 22:41:09 +0000 Message-ID: <50B69304.3060602@alum.mit.edu> Date: Wed, 28 Nov 2012 17:41:08 -0500 From: Paul Kyzivat 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: <50A160D8.8030602@alum.mit.edu> <50B68A43.8040605@alum.mit.edu> In-Reply-To: <50B68A43.8040605@alum.mit.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1354142469; bh=goudWIlKszjyuAtXhl3vkFMy2oL6CXOJKx4pOH7A4Z8=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=eeZEHfUk86L6/9ne4CIlwiX/QzId849J7zKpKBDNaZwf2TYGT6+8L2/MG2xqUxGAF zI2+rrvgzURj6p/kXybPe+A68qray1Dzpv91tZNBE/UYztv6DmAgH4SHFGQBeM2uwx y7qNF81qQ4IK6ijI38hBtIatxr3Kc4a3+QWOTffiGy6+BmF64wEKNL7mtmHZAEHKAu qWn85rBDYUA7xX2rim0LAnu5zq9HMqA/nk7HBL8HVm9sNOJLtMYDGTy8lAykYawZEG XgUGMkNGFLA7NTNqXGo2B8/N2qYv7qsDGI/Xv05ph0FFx0K15k6DscUoHX3GOY2oJX 2qREIKlmBMouQ== Subject: [sipcore] consensus call: draft-roach-sipcore-priority-00: define semantics of values? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Nov 2012 22:41:11 -0000 We are in the process of adopting draft-roach-sipcore-priority-00 as a wg document. We already ran a WGLC on it in anticipation of the adoption. One issue raised during the WGLC was whether the document should spell out the semantics of all the priority values defined in 3261. (Currently 3261 only defines "emergency".) Dan, James, and Roy were in favor, Adam and I prefered not to do it *in this document*. I think everyone agrees that 3261 is lacking in this regard, and it would be good to have these defined. The question is whether to do that in *this* document. The answer to that depends on a number of factors: - the urgency of getting the iana registry established, so that ecrit won't be blocked in defining a new value for their work. - how much pain is lack of semantics for these values causing right now? - how long would it take to to agree on definitions of the semantics? - acceptability of alternatives to this document for defining the semantics. Please indicate your preference on this issue: - NO: do not add semantic definitions to this draft. (That means they will be done some other way or not at all) - YES: this document should be delayed while semantic defintions of existing priority values are added to it. If you vote NO, feel free to indicate what mechanism you would like have used to define the semantics. (E.g. errata / another draft.) Thanks, Paul On 11/28/12 5:03 PM, Paul Kyzivat wrote: > The WGLC and adoption deadline has now passed for > draft-roach-sipcore-priority-00. Nine people (other than chairs and > authors) made meaningful comments. > > I conclude there is consensus to adopt this draft as a wg document. > > Regarding WGLC, two notable issues were raised, and I don't yet see a > clear consensus on those issues: > > - should there be a registration template? > Christer advocates this, Keith opposes, Adam finds it unnecessary. > > - should this document also spell out the semantics of all the priority > values defined in 3261? (Currently it only defines "emergency".) > Dan, James, and Roy in favor, Adam and I prefer not to do it *in this > document*. > > So, I will ask Adam to submit a wg draft version of this document, > otherwise unchanged. > > While he is doing that, I would like to get a broader consensus on the > issues above. I'll post a separate question on each of those, to keep > the discussions separate. > > Thanks, > Paul > > On 11/12/12 3:49 PM, Paul Kyzivat wrote: >> 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 > From prvs=06805e4f3e=aallen@rim.com Wed Nov 28 17:38:18 2012 Return-Path: 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 24B141F0C5C for ; Wed, 28 Nov 2012 17:38:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.203 X-Spam-Level: X-Spam-Status: No, score=-5.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] 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 59AN5dELPuRL for ; Wed, 28 Nov 2012 17:38:17 -0800 (PST) Received: from mhs061cnc.rim.net (mhs061cnc.rim.net [208.65.73.35]) by ietfa.amsl.com (Postfix) with ESMTP id DBA221F0C4A for ; Wed, 28 Nov 2012 17:38:16 -0800 (PST) X-AuditID: 0a412830-b7f1d6d00000466e-25-50b6bc80764a Received: from XCT105ADS.rim.net (xct105ads.rim.net [10.67.111.46]) (using TLS with cipher AES128-SHA (128/128 bits)) (Client did not present a certificate) by mhs061cnc.rim.net (SBG) with SMTP id 63.AE.18030.08CB6B05; Wed, 28 Nov 2012 19:38:08 -0600 (CST) Received: from XMB104ADS.rim.net ([fe80::2494:a63d:e3:723b]) by XCT105ADS.rim.net ([fe80::2d01:2041:eea3:819b%22]) with mapi id 14.02.0318.001; Wed, 28 Nov 2012 19:38:07 -0600 From: Andrew Allen To: "pkyzivat@alum.mit.edu" , "sipcore@ietf.org" Thread-Topic: [sipcore] consensus call: draft-roach-sipcore-priority-00: define semantics of values? Thread-Index: AQHNzbl+AiQGDhenuEi6BY83DJuv2pgACOnP Date: Thu, 29 Nov 2012 01:38:07 +0000 Message-ID: In-Reply-To: <50B69304.3060602@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.67.110.253] Content-Type: text/plain; charset="iso-8859-1" content-transfer-encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrJKsWRmVeSWpSXmKPExsXC5Zyvp9uwZ1uAwZL/khYrNhxgtfj6YxOb A5PH3/cfmDyWLPnJFMAU1cBok5RYUhacmZ6nb2eTmJeXX5JYkqqQklqcbKvkk5qemKMQUJRZ lphcqeCSWZyck5iZm1qkpJCZYqtkoqRQkJOYnJqbmldiq5RYUJCal6Jkx6WAAWyAyjLzFFLz kvNTMvPSbZU8g/11LSxMLXUNlex0Ezp5Mpq/fGAvuKlbsfWTewPjTpUuRk4OCQETibmbrzBD 2GISF+6tZ+ti5OIQEmhjktj48Tc7hLOZUeJs4zU2kCo2AWWJ5b9nMILYIgIxEi8Ov2ABsYUF UiV6V7eyQMTTJM7OvsYMYRtJPFj9ACzOIqAqcX3KDbA5vAIeEjNm/Aer4RTQkbh46SpYnBHo iu+n1jCB2MwC4hK3nsxngrhOQGLJnvNQl4pKvHz8jxXCVpT4u/c7K0S9nsSNqVPYIGxtiWUL XzND7BKUODnzCcsERpFZSMbOQtIyC0nLLCQtCxhZVjEK5mYUG5gZJucl6xVl5urlpZZsYgTF vaOGwQ7G9+8tDjEKcDAq8fD6LNoWIMSaWFZcmXuIUYKDWUmE17IaKMSbklhZlVqUH19UmpNa fIjRFRgSE5mluJPzgSkpryTe2MAAN0dJnPdy0boAIYF0YJLJTk0tSC2CmcPEwQmyh0tKpBiY KlKLEktLMuJBCS2+GJjSpBoY9/UbNOZaFhm1/L1ZOyOMO8kjwtzUh2n7mzJB0XuhBnlPGf8b 2ez/3uZTfufz/OVp5r7286Plw7K5tjoce2Qq431jpvHMCVFCD/lklx51mFxuZlXiZKxl4npy ml5cC/f7PWKNv6tK1avcpDZ2nFAOXvD/QvRhhvYEn9a8iKC2swe26MtnvVdiKc5INNRiLipO BACauNc5PAMAAA== Subject: Re: [sipcore] consensus call: draft-roach-sipcore-priority-00: define semantics of values? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Nov 2012 01:38:18 -0000 NO - that's feature creep that takes something that's already been discussed= and on which there is consensus and adds a boatload more discussion that wi= ll likely be a long discussion (see how much discussion we have had just on= whether to use a new or existing value for PSAP callback) and delay the IAN= A registration of the new value. I know it is Christmas season but let's not create a snowball that grows and= grows as it rolls along! If there are people willing to do the additional work of defining and discus= sing the semantics of these values then that can be a follow on draft. Andrew ----- Original Message ----- From: Paul Kyzivat [mailto:pkyzivat@alum.mit.edu] Sent: Wednesday, November 28, 2012 04:41 PM Central Standard Time=0A= To: sipcore@ietf.org Subject: [sipcore] consensus call: draft-roach-sipcore-priority-00: define s= emantics of values? We are in the process of adopting draft-roach-sipcore-priority-00 as a wg document. We already ran a WGLC on it in anticipation of the adoption. One issue raised during the WGLC was whether the document should spell out the semantics of all the priority values defined in 3261. (Currently 3261 only defines "emergency".) Dan, James, and Roy were in favor, Adam and I prefered not to do it *in this document*. I think everyone agrees that 3261 is lacking in this regard, and it would be good to have these defined. The question is whether to do that in *this* document. The answer to that depends on a number of factors: - the urgency of getting the iana registry established, so that ecrit won't be blocked in defining a new value for their work. - how much pain is lack of semantics for these values causing right now? - how long would it take to to agree on definitions of the semantics? - acceptability of alternatives to this document for defining the semantics. Please indicate your preference on this issue: - NO: do not add semantic definitions to this draft. (That means they will be done some other way or not at all) - YES: this document should be delayed while semantic defintions of existing priority values are added to it. If you vote NO, feel free to indicate what mechanism you would like have used to define the semantics. (E.g. errata / another draft.) Thanks, Paul On 11/28/12 5:03 PM, Paul Kyzivat wrote: > The WGLC and adoption deadline has now passed for > draft-roach-sipcore-priority-00. Nine people (other than chairs and > authors) made meaningful comments. > > I conclude there is consensus to adopt this draft as a wg document. > > Regarding WGLC, two notable issues were raised, and I don't yet see a > clear consensus on those issues: > > - should there be a registration template? > Christer advocates this, Keith opposes, Adam finds it unnecessary. > > - should this document also spell out the semantics of all the priority > values defined in 3261? (Currently it only defines "emergency".) > Dan, James, and Roy in favor, Adam and I prefer not to do it *in this > document*. > > So, I will ask Adam to submit a wg draft version of this document, > otherwise unchanged. > > While he is doing that, I would like to get a broader consensus on the > issues above. I'll post a separate question on each of those, to keep > the discussions separate. > > Thanks, > Paul > > On 11/12/12 3:49 PM, Paul Kyzivat wrote: >> 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 > _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore --------------------------------------------------------------------- This transmission (including any attachments) may contain confidential infor= mation, privileged material (including material protected by the solicitor-c= lient or other applicable privileges), or constitute non-public information.= Any use of this information by anyone other than the intended recipient is= prohibited. If you have received this transmission in error, please immedia= tely reply to the sender and delete this information from your system. Use,= dissemination, distribution, or reproduction of this transmission by uninte= nded recipients is not authorized and may be unlawful. From christer.holmberg@ericsson.com Wed Nov 28 23:33:10 2012 Return-Path: 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 B822821F8A58 for ; Wed, 28 Nov 2012 23:33:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.102 X-Spam-Level: X-Spam-Status: No, score=-6.102 tagged_above=-999 required=5 tests=[AWL=0.147, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] 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 o49qxnHzWCv4 for ; Wed, 28 Nov 2012 23:33:10 -0800 (PST) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id B27AC21F85CE for ; Wed, 28 Nov 2012 23:33:09 -0800 (PST) X-AuditID: c1b4fb30-b7f936d0000018b3-47-50b70fb31e9b Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 63.65.06323.3BF07B05; Thu, 29 Nov 2012 08:33:08 +0100 (CET) Received: from ESESSHC021.ericsson.se (153.88.183.81) by esessmw0191.eemea.ericsson.se (153.88.115.84) with Microsoft SMTP Server (TLS) id 8.3.279.1; Thu, 29 Nov 2012 08:33:07 +0100 Received: from ESESSMB209.ericsson.se ([169.254.9.119]) by ESESSHC021.ericsson.se ([153.88.183.81]) with mapi id 14.02.0318.001; Thu, 29 Nov 2012 08:33:07 +0100 From: Christer Holmberg To: Paul Kyzivat , "sipcore@ietf.org" Thread-Topic: [sipcore] consensus call: draft-roach-sipcore-priority-00: IANA registration template needed? Thread-Index: AQHNzbbBe6sci1iEWUqAvhw1W5u4NZgAadkw Date: Thu, 29 Nov 2012 07:33:07 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B048D89@ESESSMB209.ericsson.se> References: <50A160D8.8030602@alum.mit.edu> <50B68A43.8040605@alum.mit.edu> <50B68E74.3060307@alum.mit.edu> In-Reply-To: <50B68E74.3060307@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.16] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrJLMWRmVeSWpSXmKPExsUyM+Jvje4W/u0BBj0X2S1WbDjAavH1xyY2 ByaPv+8/MHksWfKTKYApissmJTUnsyy1SN8ugSvj/rvv7AWdghXnPk1gaWDczNvFyMkhIWAi 8WbNK1YIW0ziwr31bF2MXBxCAicZJda8m88M4exklJj/rpsdwlnCKDGp+QBTFyMHB5uAhUT3 P22QbhGBQImrSyYwg9jCAjkSy1v72CDiuRL9Lx6zQNhGEuf7GsBqWARUJZbOWgVm8wp4SzRe 3wV2hRBQ/ZmLs8HinAI6EmumHwOzGYGu+35qDROIzSwgLnHryXwmiKsFJJbsOc8MYYtKvHz8 D+obRYmdZ9uZIep1JBbs/sQGYWtLLFv4GmqvoMTJmU9YIPZqS7QsnsA+gVF8FpIVs5C0z0LS PgtJ+wJGllWM7LmJmTnp5eabGIHRc3DLb4MdjJvuix1ilOZgURLn1VPd7y8kkJ5YkpqdmlqQ WhRfVJqTWnyIkYmDU6qBMfaoQFjpi6P77ffX1hwWNl8gMrF70ruMIxNcDLN397+ffzb17CWh G3P2z/8t69J4g6H8+MQr6146WmssOXV5E6dM+tcfVRnPTqVe8W6+aXZZ/8xyuQeeFpGSYjwG h15NzUgO6vDZqZvr9ofj47/da6rbrC0ZyrS/V9x6GRSb/EE93udtWcPao0osxRmJhlrMRcWJ AAJ1Q29sAgAA Subject: Re: [sipcore] consensus call: draft-roach-sipcore-priority-00: IANA registration template needed? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Nov 2012 07:33:11 -0000 Hi Paul, >We are in the process of adopting draft-roach-sipcore-priority-00 as a wg = document. We already ran a WGLC on it in anticipation of the adoption. > >One issue raised during the WGLC was whether the document should include s= ome sort of IANA registration template. Christer proposed this, and Keith o= pposed it. > >Christer failed to specify what he wanted to see in this template. The exi= sting document specifies what the registry should contain: A "priority" nam= e and a document=20 >reference. "IETF Review" is required for adding new values, which ensures = that there will be an RFC to reference.=20 >So presumably the template would include at least these two values. > >Please indicate if you think the draft is ok as-is, or should be revised t= o include a registration template. > >If you favor a template, please indicate what you think it should contain. What do you mean by "Christer failed to specify"?=20 13th November I DID send text proposal to the list for the registration tem= plate. It contained Description, Reference and Contact. See copy at the end= of this reply. However, 15th November I indicated on the list that, if nobody else think a= template is needed, I'll step down :) The important thing is that it is clear to a person who want to register a = value WHAT information to provide, and WHERE to send it. Regards, Christer ------------------- x. Priority Header Field Value Registration Template Registration requests for Priority header field values requires submitting an Internet-Draft to the IESG. | Instructions are preceded by '|'. All fields are mandatory. Priority header field value: Description: | The description should be no longer than 4 lines. More | detailed information can be provided in the specification | that defines the header field value. Priority header field value specification reference: | The reference to the speicification the defines the=20 | header field value. Contact: | Name(s) & email address(es) of person(s) to | contact for further information." ------------------- From christer.holmberg@ericsson.com Wed Nov 28 23:39:16 2012 Return-Path: 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 47A7521F8946 for ; Wed, 28 Nov 2012 23:39:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.116 X-Spam-Level: X-Spam-Status: No, score=-6.116 tagged_above=-999 required=5 tests=[AWL=0.133, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] 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 HGkLWi8Q5iHv for ; Wed, 28 Nov 2012 23:39:15 -0800 (PST) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id A5A8321F88C2 for ; Wed, 28 Nov 2012 23:39:14 -0800 (PST) X-AuditID: c1b4fb25-b7f926d00000661f-5f-50b7111f4951 Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 03.90.26143.F1117B05; Thu, 29 Nov 2012 08:39:12 +0100 (CET) Received: from ESESSHC013.ericsson.se (153.88.183.57) by esessmw0184.eemea.ericsson.se (153.88.115.81) with Microsoft SMTP Server (TLS) id 8.3.279.1; Thu, 29 Nov 2012 08:39:11 +0100 Received: from ESESSMB209.ericsson.se ([169.254.9.119]) by ESESSHC013.ericsson.se ([153.88.183.57]) with mapi id 14.02.0318.001; Thu, 29 Nov 2012 08:39:11 +0100 From: Christer Holmberg To: Paul Kyzivat , "sipcore@ietf.org" Thread-Topic: [sipcore] consensus call: draft-roach-sipcore-priority-00: define semantics of values? Thread-Index: AQHNzbl5ss4cS5Nrhkq6lc+qz9ru65gAbTng Date: Thu, 29 Nov 2012 07:39:11 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B048D9C@ESESSMB209.ericsson.se> References: <50A160D8.8030602@alum.mit.edu> <50B68A43.8040605@alum.mit.edu> <50B69304.3060602@alum.mit.edu> In-Reply-To: <50B69304.3060602@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.16] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrOLMWRmVeSWpSXmKPExsUyM+Jvja6C4PYAg8VH2S1WbDjAavH1xyY2 ByaPv+8/MHksWfKTKYApissmJTUnsyy1SN8ugStj36GFzAU/tSo2/trI3sC4QKmLkZNDQsBE 4uWBs+wQtpjEhXvr2boYuTiEBE4ySszvnMcI4exklJjXf4MJwlnCKLFg8W+WLkYODjYBC4nu f9og3SICgRJXl0xgBrGFBVIlDn8/wAQRT5M4O/saM0i5iICRxLFFaiBhFgFViTVXdzOChHkF vCWeLNYDCQsJ5Eqsnd8Gdg+ngI7ExUtX2UBsRqDbvp9aAzaRWUBc4taT+UwQNwtILNlznhnC FpV4+fgfK4StKLHzbDszRL2OxILdn9ggbG2JZQtfg8V5BQQlTs58wgKxV1uiZfEE9gmM4rOQ rJiFpH0WkvZZSNoXMLKsYmTPTczMSS832sQIjJyDW36r7mC8c07kEKM0B4uSOK/11j3+QgLp iSWp2ampBalF8UWlOanFhxiZODilGhil963rfbLyF/d7eR32DpEtfQbb99vqmylk9it2tN2o kb667ZiFmOzJfz+PX/T7d5Jtte09GdHpx3cHh+VdP9G/SrWt15hf4+0lf51Pc2Sm7EzdePzt 65uLHRcWcIjzTUjz9btkMkN5zrZXCfvCLMtKuCe4qqiZsT53LA1q/7z0VWnhFJ6iwHNKLMUZ iYZazEXFiQCHDHqxagIAAA== Subject: Re: [sipcore] consensus call: draft-roach-sipcore-priority-00: define semantics of values? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Nov 2012 07:39:16 -0000 NO. (We can have a separate discussion whether we want to, as part of another d= raft/errata, want to define the semantics for existing value(s), but let's = not that stop the progress of the registry work.) Regards, Christer -----Original Message----- From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behalf = Of Paul Kyzivat Sent: 29. marraskuuta 2012 0:41 To: sipcore@ietf.org Subject: [sipcore] consensus call: draft-roach-sipcore-priority-00: define = semantics of values? We are in the process of adopting draft-roach-sipcore-priority-00 as a wg d= ocument. We already ran a WGLC on it in anticipation of the adoption. One issue raised during the WGLC was whether the document should spell out = the semantics of all the priority values defined in 3261. (Currently 3261 only defines "emergency".) Dan, James, and Roy were in favor, Adam and= I prefered not to do it *in this document*. I think everyone agrees that 3261 is lacking in this regard, and it would b= e good to have these defined. The question is whether to do that in *this* = document. The answer to that depends on a number of factors: - the urgency of getting the iana registry established, so that ecrit won't be blocked in defining a new value for their work. - how much pain is lack of semantics for these values causing right now? - how long would it take to to agree on definitions of the semantics? - acceptability of alternatives to this document for defining the semantics. Please indicate your preference on this issue: - NO: do not add semantic definitions to this draft. (That means they will be done some other way or not at all) - YES: this document should be delayed while semantic defintions of existing priority values are added to it. If you vote NO, feel free to indicate what mechanism you would like have us= ed to define the semantics. (E.g. errata / another draft.) Thanks, Paul On 11/28/12 5:03 PM, Paul Kyzivat wrote: > The WGLC and adoption deadline has now passed for=20 > draft-roach-sipcore-priority-00. Nine people (other than chairs and > authors) made meaningful comments. > > I conclude there is consensus to adopt this draft as a wg document. > > Regarding WGLC, two notable issues were raised, and I don't yet see a=20 > clear consensus on those issues: > > - should there be a registration template? > Christer advocates this, Keith opposes, Adam finds it unnecessary. > > - should this document also spell out the semantics of all the priority > values defined in 3261? (Currently it only defines "emergency".) > Dan, James, and Roy in favor, Adam and I prefer not to do it *in this > document*. > > So, I will ask Adam to submit a wg draft version of this document,=20 > otherwise unchanged. > > While he is doing that, I would like to get a broader consensus on the=20 > issues above. I'll post a separate question on each of those, to keep=20 > the discussions separate. > > Thanks, > Paul > > On 11/12/12 3:49 PM, Paul Kyzivat wrote: >> PLEASE RESPOND TO THIS MESSAGE >> >> This is a request to the sipcore wg to adopt the new individual draft=20 >> draft-roach-sipcore-priority-00, and a start of WGLC on that=20 >> document, to end on Sunday, November 25, 2012. (This is a trivial doc=20 >> to review, but people may be slow getting back to work after the=20 >> meeting and there is a holiday coming in the US, so I'm giving more=20 >> time than I otherwise >> would.) >> >> The reason for this is that the ecrit wg wants to define a new value=20 >> for the Priority header field. RFC 3261 defines that header field and=20 >> an initial set of values. It also mentions the possibility of extension. >> But it failed to establish an IANA registry for that purpose, and=20 >> 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 value= s >> 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 ne= w >> 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=20 >> accord with the registration procedures that have been defined. The=20 >> registration policy is "IETF Review", so discussion of the merits of=20 >> 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 > _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore From michael@voip.co.uk Thu Nov 29 02:27:29 2012 Return-Path: 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 0406E21F89DB for ; Thu, 29 Nov 2012 02:27:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.977 X-Spam-Level: X-Spam-Status: No, score=-5.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4] 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 nCCE3KHe+w2N for ; Thu, 29 Nov 2012 02:27:28 -0800 (PST) Received: from na3sys009aog103.obsmtp.com (na3sys009aog103.obsmtp.com [74.125.149.71]) by ietfa.amsl.com (Postfix) with SMTP id 575E021F89D7 for ; Thu, 29 Nov 2012 02:27:28 -0800 (PST) Received: from mail-gh0-f198.google.com ([209.85.160.198]) (using TLSv1) by na3sys009aob103.postini.com ([74.125.148.12]) with SMTP ID DSNKULc4j/7CuiUGmBe4kJtEyrKaPeYHVoz1@postini.com; Thu, 29 Nov 2012 02:27:28 PST Received: by mail-gh0-f198.google.com with SMTP id r18so21004708ghr.1 for ; Thu, 29 Nov 2012 02:27:27 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=ZostCMZd5h+skUlEhO4kdZjN6t1mbE8iOLHHCQRN324=; b=VMUdLxzUDz8KKi4qsH+ee55VRdT2UGzVzbm7edQ3VdE+NhWKpbiJ0BKSAYuP4Ko8NE eO2dNTYPDN2Gs4K5akakygc2Jfmp4EadzRLN6iBEhgqtGX9Gf8UFb5IP4FwKsEGZDAjX klXPMlvAP39M+6zBLkVGYH/JaJIml22leNujnkahOMPqWpsmIXPWFwE73qkbax5KLrFV gcOk5wZpPNaYTAIZZBievZpnZLNBiI3MudpQPNlnkhXTMGrkS++qYfIlWqK8YTKkcSae BuZm/u01aLoXxuuzycHeVQSc068EPkL/vBPnB3nkwHZX1yOgcvP4+AQbtvNqC/AwWnaB 4tZA== Received: by 10.58.162.130 with SMTP id ya2mr32645259veb.2.1354184847067; Thu, 29 Nov 2012 02:27:27 -0800 (PST) MIME-Version: 1.0 Received: by 10.58.162.130 with SMTP id ya2mr32645253veb.2.1354184846936; Thu, 29 Nov 2012 02:27:26 -0800 (PST) Received: by 10.58.244.132 with HTTP; Thu, 29 Nov 2012 02:27:26 -0800 (PST) In-Reply-To: <50B69304.3060602@alum.mit.edu> References: <50A160D8.8030602@alum.mit.edu> <50B68A43.8040605@alum.mit.edu> <50B69304.3060602@alum.mit.edu> Date: Thu, 29 Nov 2012 10:27:26 +0000 Message-ID: From: Michael Procter To: Paul Kyzivat Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQkLwqza0NQMNDlS2QCvyoWa/CMSZNSoT7m0ZjXeTxGljqKvoWZ6dVch6Ojq6adLHFZJLKwUMO3PFQKGl+xyOfQd4Q1LwNHFr2uYpWMDFQX7RKsERCAKG5G3YPEiLMI6TarGBIQ/tFdt12RZpX5vN/FwoaPVVQ== Cc: sipcore@ietf.org Subject: Re: [sipcore] consensus call: draft-roach-sipcore-priority-00: define semantics of values? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Nov 2012 10:27:29 -0000 NO I'm happy to defer defining the semantics of 'urgent', 'non-urgent' and 'normal' until not having the semantics defined causes interoperability problems. Given the limited impact the priority header can have on a session, I suspect that the natural meanings of the tokens are adequate for the time being. Michael From keith.drage@alcatel-lucent.com Thu Nov 29 03:44:23 2012 Return-Path: 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 3014F21F89D7 for ; Thu, 29 Nov 2012 03:44:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.874 X-Spam-Level: X-Spam-Status: No, score=-109.874 tagged_above=-999 required=5 tests=[AWL=0.375, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8, 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 XrwFzB7LJchJ for ; Thu, 29 Nov 2012 03:44:22 -0800 (PST) Received: from smail3.alcatel.fr (smail3.alcatel.fr [64.208.49.56]) by ietfa.amsl.com (Postfix) with ESMTP id 0F75E21F89D1 for ; Thu, 29 Nov 2012 03:44:21 -0800 (PST) Received: from FRMRSSXCHHUB02.dc-m.alcatel-lucent.com (FRMRSSXCHHUB02.dc-m.alcatel-lucent.com [135.120.45.62]) by smail3.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id qATBhpxu020637 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 29 Nov 2012 12:44:15 +0100 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.48]) by FRMRSSXCHHUB02.dc-m.alcatel-lucent.com ([135.120.45.62]) with mapi; Thu, 29 Nov 2012 12:44:00 +0100 From: "DRAGE, Keith (Keith)" To: Paul Kyzivat , "sipcore@ietf.org" Date: Thu, 29 Nov 2012 12:43:59 +0100 Thread-Topic: [sipcore] Proposal: Call for adoption & WGLC: draft-roach-sipcore-priority-00 Thread-Index: Ac3NtEWyh8Rwc/33T9OTqixs/o8imwAcSjwQ Message-ID: References: <50A160D8.8030602@alum.mit.edu> <50B68A43.8040605@alum.mit.edu> In-Reply-To: <50B68A43.8040605@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.83 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Nov 2012 11:44:23 -0000 Regarding 1), noone has yet responded as to why we need a template for a do= cument where registration requires IETF work. The template is in my view th= ere to ensure all the information that is needed is available for expert re= view. The document management of an internet draft means that if informatio= n is needed for review the next revision can provide it. We only need a tem= plate if someone decides a different registration policy is needed. Regarding 2), I think defining more precise semantics of the existing value= s is too late in the game. Fine for new values, and in many ways, this is w= hy we have a new value for the callback proposed elsewhere. So do not add t= hese. Keith > -----Original Message----- > From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behal= f > Of Paul Kyzivat > Sent: 28 November 2012 22:04 > To: sipcore@ietf.org > Subject: Re: [sipcore] Proposal: Call for adoption & WGLC: draft-roach- > sipcore-priority-00 >=20 > The WGLC and adoption deadline has now passed for > draft-roach-sipcore-priority-00. Nine people (other than chairs and > authors) made meaningful comments. >=20 > I conclude there is consensus to adopt this draft as a wg document. >=20 > Regarding WGLC, two notable issues were raised, and I don't yet see a > clear consensus on those issues: >=20 > - should there be a registration template? > Christer advocates this, Keith opposes, Adam finds it unnecessary. >=20 > - should this document also spell out the semantics of all the priority > values defined in 3261? (Currently it only defines "emergency".) > Dan, James, and Roy in favor, Adam and I prefer not to do it *in this > document*. >=20 > So, I will ask Adam to submit a wg draft version of this document, > otherwise unchanged. >=20 > While he is doing that, I would like to get a broader consensus on the > issues above. I'll post a separate question on each of those, to keep > the discussions separate. >=20 > Thanks, > Paul >=20 > On 11/12/12 3:49 PM, Paul Kyzivat wrote: > > 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 fo= r > > 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 > > >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From ibc@aliax.net Thu Nov 29 03:44:25 2012 Return-Path: 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 163B521F89D7 for ; Thu, 29 Nov 2012 03:44:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.077 X-Spam-Level: X-Spam-Status: No, score=-2.077 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, J_CHICKENPOX_92=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_LOW=-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 PjmMUfjxaGeT for ; Thu, 29 Nov 2012 03:44:24 -0800 (PST) Received: from mail-lb0-f172.google.com (mail-lb0-f172.google.com [209.85.217.172]) by ietfa.amsl.com (Postfix) with ESMTP id A6C0B21F89D1 for ; Thu, 29 Nov 2012 03:44:23 -0800 (PST) Received: by mail-lb0-f172.google.com with SMTP id y2so12322492lbk.31 for ; Thu, 29 Nov 2012 03:44:22 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type:content-transfer-encoding:x-gm-message-state; bh=1zL1lZTJIB2IwdYf4BUWk3NmQlr5Xa+etyfs5sU+Hdo=; b=A/uFX8RgSEAKEwcMzDR4o+Gx9z/LeP680N7cKpv4wfOw7nhZFZZ89u74urvqwUd3wF OvLs4os0KaEhkederDx40o4a2v7oJLiw04pmDFDwwLeaSdGTHO2wFw19VtRYcVlK0zUu fHAzfxeJ5WXUr3m7Yg7rgyoihFmr7oHzRP0RNXSD/PI5+CPVOTh9fbEvyFfeWBOysuZF ohCMY23fZNWZniMSOdWlq+VkaB3HijHEBbCuqKJAu1ERVdn/Gj5kkDdzJJASKDsjBUqs ggbR+hZIP1oTPukYBY1C9Ocn1vsgc6KZw5TEE56s5u0ciMVtCC6wKggbNdnrh0unIsRz 5Upw== Received: by 10.112.38.226 with SMTP id j2mr9506323lbk.128.1354189462410; Thu, 29 Nov 2012 03:44:22 -0800 (PST) MIME-Version: 1.0 Received: by 10.114.1.237 with HTTP; Thu, 29 Nov 2012 03:44:02 -0800 (PST) In-Reply-To: <50B5404A.20807@nostrum.com> References: <50B5404A.20807@nostrum.com> From: =?UTF-8?Q?I=C3=B1aki_Baz_Castillo?= Date: Thu, 29 Nov 2012 12:44:02 +0100 Message-ID: To: Robert Sparks Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Gm-Message-State: ALoCoQlh1IqkBVtnlOFpICAPZIpOXaOP23ujGYva0xArn/D1PmmMht8RNTLGFh+yvb+lmn9ZKfir Cc: "sipcore@ietf.org" , draft-ietf-sipcore-sip-websocket@tools.ietf.org Subject: Re: [sipcore] AD Review: draft-ietf-sipcore-sip-websocket-06.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Nov 2012 11:44:25 -0000 Robert, thanks a lot for your useful comments. Please let's some days until we can comment and address them into a new revision of the draft. Best regards. 2012/11/27 Robert Sparks : > AD Review: draft-ietf-sipcore-sip-websocket-06.txt > > Summary: There are a few issues to address with a revised ID before > progressing to IETF LC > > Overall, this is a very well written, easy to read draft. Thank you for > making it this clear. > There are a couple of small problems to correct, and a few issues to > consider before moving > forward: > > * Section 6 starts with "_This section is non-normative_", but then conta= ins > normative statements. RECOMMENDED is the same as SHOULD. This is a > stronger > requirement for Ping than RFC 6455 places on websockets. If it was the > intent > to restate what RFC 6455 required, the language should be "RFC 6455 say= s > to...". > If it was the intent to make a stronger requirement, then this section > _is_ > normative. > > To avoid the appearance of placing a new normative requirement on the > implementation > of keep-alives, I suggest replacing the next to last paragraph of this > section with > "The indication and use of the CRLF NAT keep-alive mechanism defined fo= r > SIP > connection-oriented transports in RFC5626 section 3.5.1 or RFC6223 are= , > of course, > usable over the transport defined in this specification." > > * Section 7 starts with "_This section is non-normative_" but then > contain normative statements. > > Section 7 could be rewritten to not use 2119, but that would take more > than > changing the words to lower case. The gist is 'the SIP and WebSocket sp= ecs > tell you these things.' > > It also currently confuses SIP Digest with HTTP Digest, and incorrectly > suggests > that SIP Digest is a SHOULD strength requirement in 3261 (it is a MUST > there). > > It would be better to say "This section describes how authentication is > acheived through the requirements in RFCs 6445, 6265, and 3261." > The MAY in paragraph 3 can be changed to "is allowed to". > The last paragraph can say > ...", authentication can be requested at the SIP protocol level. Note > that RFC3261 requires that all SIP implementations (which includes > implementations of this specification) implement Digest Authorization > (see RFC3261, Section 26.3.1)." > > * The document should more explicitly call out that none of SIP TLS > certificate > checks specified in RFC3261 or RFC5922 will be made when using this > transport. > Instead, only the checks specified by RFC6455 will be made. The > certificates > that are appropriate for SIP over TLS over TCP will probably not be > appropriate > for SIP over secure websockets (it would only be coincidence if the sam= e > cert > worked - the two checks will look in different places in the certificat= e). > > * Should there be some additional discussion of what an element should do= if > someone clicks on "sip:foo.example.com;transport=3Dws" or receives that= in a > contact in a 302 or in a Refer-To: header field? To: header field? > Taken to an extreme, what's a proxy that understands sip over websocket= s > supposed to do if it gets a message containing Route header fields (thi= nk > preloaded routes) where the next route value is for a transport=3Dws ho= p > that > a connection doesn't yet exist for? > > * I'm ok proceeding with the IANA Considerations sections as they current= ly > stand, but I wonder if instead of what's in 10.3 and 10.4, this documen= t > should create a new registry for the transport values. That way someone > could search the registry for the strings "WS" or "WSS" and find someth= ing > meaningful. > > Nits: > > - RFCs never change. Years from now, this won't be "new". Please conside= r > removing "new" from the abstract and the Introduction. The abstract wo= uld > be stronger if you replaced "enable usage of SIP in new scenarios" wit= h > "enable usage of SIP in web-oriented deployments." > > - In the introduction, you say "a [new] reliable and message boundary > transport". > Did you mean "a reliable, and message-boundary preserving, transport" = ? > > - At the end of 5.2.3, s/regardless the Via/regardless of whether the Vi= a/ > > - In A.1, to further avoid this section appearing to be normative, I > suggest > changing "Therefore the SIP WebSocket Client constructs" to "A SIP > WebSocket > client running in such an environment can construct". > > - In section 6, what is the value of the sentence "A future WebSocket > protocol > extension providing a similar keep alive mechanism could also be used"= ? > This > specification says the same thing if the sentence is removed, and I > suggest > removing it. > > - (no change suggested - just pointing something out for future work) > The ABNF in 5.2.1 could have used =3D/ and not have restated the other > values. > It would have been nice if 5.2.2 could have as well, but the way > transport-param > is defined in RFC3261 prevents it. It's probably better to keep the fo= rm > of 5.2.1 > and 5.2.2 the same. > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore --=20 I=C3=B1aki Baz Castillo From christer.holmberg@ericsson.com Thu Nov 29 03:50:41 2012 Return-Path: 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 D6E6C21F89FC for ; Thu, 29 Nov 2012 03:50:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.147 X-Spam-Level: X-Spam-Status: No, score=-6.147 tagged_above=-999 required=5 tests=[AWL=0.102, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] 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 4GSY9tg5ihZT for ; Thu, 29 Nov 2012 03:50:41 -0800 (PST) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id A3D1121F89F4 for ; Thu, 29 Nov 2012 03:50:40 -0800 (PST) X-AuditID: c1b4fb2d-b7f1e6d000002d2c-07-50b74c0b59ad Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id F1.7E.11564.B0C47B05; Thu, 29 Nov 2012 12:50:36 +0100 (CET) Received: from ESESSHC004.ericsson.se (153.88.183.30) by esessmw0191.eemea.ericsson.se (153.88.115.84) with Microsoft SMTP Server (TLS) id 8.3.279.1; Thu, 29 Nov 2012 12:50:35 +0100 Received: from ESESSMB209.ericsson.se ([169.254.9.119]) by ESESSHC004.ericsson.se ([153.88.183.30]) with mapi id 14.02.0318.001; Thu, 29 Nov 2012 12:50:35 +0100 From: Christer Holmberg To: "DRAGE, Keith (Keith)" , Paul Kyzivat , "sipcore@ietf.org" Thread-Topic: [sipcore] Proposal: Call for adoption & WGLC: draft-roach-sipcore-priority-00 Thread-Index: AQHNzibk1HK3qgXMgkaEs3fc67a3ZpgAskLw Date: Thu, 29 Nov 2012 11:50:34 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B0493C3@ESESSMB209.ericsson.se> References: <50A160D8.8030602@alum.mit.edu> <50B68A43.8040605@alum.mit.edu> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.16] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrCLMWRmVeSWpSXmKPExsUyM+JvjS6Pz/YAgy/dvBZPG88yWqzYcIDV 4uuPTWwOzB6tz/ayevx9/4HJY8mSn0wBzFFcNimpOZllqUX6dglcGXPWr2IpOKhU8WPBJfYG xq3SXYycHBICJhKdq84wQdhiEhfurWfrYuTiEBI4ySjR3/IJytnJKPH4UAszSJWQwBJGiY3r arsYOTjYBCwkuv9pg9SICHQxSvw8fg6sRlggRuJP8ySwqSICsRKdc2+wQ9hGEpfajoDFWQRU Jb7PaWcBsXkFvCU+X5jLDrFsIaPEpz0QzZwCCRJ/Tp1iBLEZgc77fmoNWJxZQFzi1pP5UGcL SCzZc54ZwhaVePn4HyuErSix82w7M0S9jsSC3SDfgNjaEssWvmaGWCwocXLmExaIx7QlWhZP YJ/AKD4LyYpZSNpnIWmfhaR9ASPLKkb23MTMnPRyw02MwJg6uOW37g7GU+dEDjFKc7AoifNy Je33FxJITyxJzU5NLUgtii8qzUktPsTIxMEp1cDoodh62L7ZwoqvXPPiRoZ4/jcHdkhtCQkL +xf/NKc/WIn54It9/St01oQLGz3+Etog/Pb8x7vT7A73VFlnL+ybIWrZt4X5/Hzd+e/FvTxj HGaIV2qzGXtd4ds4cdv6y94XDD4dktT20ZKXXT8lSqF32esdq1ft31qUtGC1xbrkIg8xiXgx x8VKLMUZiYZazEXFiQCUmEXMdwIAAA== 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Nov 2012 11:50:42 -0000 Hi, >Regarding 1), noone has yet responded as to why we need a template for a d= ocument where registration requires IETF work. The template=20 >is in my view there to ensure all the information that is needed is availa= ble for expert review. The document management of an internet=20 >draft means that if information is needed for review the next revision can= provide it. We only need a template if someone decides a different=20 >registration policy is needed. Fair enough. I hereby withdraw my request for a template :) Regards, Christer > -----Original Message----- > From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On=20 > Behalf Of Paul Kyzivat > Sent: 28 November 2012 22:04 > To: sipcore@ietf.org > Subject: Re: [sipcore] Proposal: Call for adoption & WGLC:=20 > draft-roach- > sipcore-priority-00 >=20 > The WGLC and adoption deadline has now passed for=20 > draft-roach-sipcore-priority-00. Nine people (other than chairs and > authors) made meaningful comments. >=20 > I conclude there is consensus to adopt this draft as a wg document. >=20 > Regarding WGLC, two notable issues were raised, and I don't yet see a=20 > clear consensus on those issues: >=20 > - should there be a registration template? > Christer advocates this, Keith opposes, Adam finds it unnecessary. >=20 > - should this document also spell out the semantics of all the priority > values defined in 3261? (Currently it only defines "emergency".) > Dan, James, and Roy in favor, Adam and I prefer not to do it *in this > document*. >=20 > So, I will ask Adam to submit a wg draft version of this document,=20 > otherwise unchanged. >=20 > While he is doing that, I would like to get a broader consensus on the=20 > issues above. I'll post a separate question on each of those, to keep=20 > the discussions separate. >=20 > Thanks, > Paul >=20 > On 11/12/12 3:49 PM, Paul Kyzivat wrote: > > PLEASE RESPOND TO THIS MESSAGE > > > > This is a request to the sipcore wg to adopt the new individual=20 > > draft draft-roach-sipcore-priority-00, and a start of WGLC on that=20 > > document, to end on Sunday, November 25, 2012. (This is a trivial=20 > > doc to review, but people may be slow getting back to work after the=20 > > meeting and there is a holiday coming in the US, so I'm giving more=20 > > time than I otherwise > > would.) > > > > The reason for this is that the ecrit wg wants to define a new value=20 > > for the Priority header field. RFC 3261 defines that header field=20 > > and an initial set of values. It also mentions the possibility of exten= sion. > > But it failed to establish an IANA registry for that purpose, and=20 > > 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=20 > > 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=20 > > accord with the registration procedures that have been defined. The=20 > > registration policy is "IETF Review", so discussion of the merits of=20 > > 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 > > >=20 > _______________________________________________ > 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 From hannes.tschofenig@nsn.com Thu Nov 29 04:21:51 2012 Return-Path: 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 2D9E121F8A12 for ; Thu, 29 Nov 2012 04:21:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 zriNJbI1kfth for ; Thu, 29 Nov 2012 04:21:50 -0800 (PST) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id AC81A21F8A19 for ; Thu, 29 Nov 2012 04:21:49 -0800 (PST) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id qATCLcgt005421 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 29 Nov 2012 13:21:38 +0100 Received: from DEMUEXC048.nsn-intra.net ([10.159.32.94]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id qATCLYvb012763; Thu, 29 Nov 2012 13:21:38 +0100 Received: from FIESEXC035.nsn-intra.net ([10.159.0.25]) by DEMUEXC048.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Thu, 29 Nov 2012 13:21:35 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 29 Nov 2012 14:20:58 +0200 Message-ID: <999913AB42CC9341B05A99BBF358718D0229B91C@FIESEXC035.nsn-intra.net> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B0493C3@ESESSMB209.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] Proposal: Call for adoption& WGLC: draft-roach-sipcore-priority-00 Thread-Index: AQHNzibk1HK3qgXMgkaEs3fc67a3ZpgAskLwgAAGCjA= References: <50A160D8.8030602@alum.mit.edu> <50B68A43.8040605@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B0493C3@ESESSMB209.ericsson.se> From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: "ext Christer Holmberg" , "DRAGE, Keith (Keith)" , "Paul Kyzivat" , X-OriginalArrivalTime: 29 Nov 2012 12:21:35.0329 (UTC) FILETIME=[12D2A510:01CDCE2C] X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 5902 X-purgate-ID: 151667::1354191700-00006291-4DDF88A9/0-0/0-0 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Nov 2012 12:21:51 -0000 I fear you guys read a bit too much into the term "template".=20 IANA typically wants to know what information a request for adding a new value into an existing registry should contain. This is called the template. As mentioned, here the required info is pretty obvious: a label and a reference to a document that contains the semantic. If you want to make it 100% clear add a sentence: "Registration requests to IANA must include a label (value for the priority header field) and a reference to a document that explains the semantic of that label."=20 What is, however, missing from the IANA consideration is an indication whether you envision entries to be updated, deleted, or deprecated. I would write "Updating, deleting, or deprecating of entries in the registry is not envisioned."=20 Ciao Hannes > -----Original Message----- > From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On > Behalf Of ext Christer Holmberg > Sent: Thursday, November 29, 2012 1:51 PM > To: DRAGE, Keith (Keith); Paul Kyzivat; sipcore@ietf.org > Subject: Re: [sipcore] Proposal: Call for adoption& WGLC: draft-roach- > sipcore-priority-00 >=20 > Hi, >=20 > >Regarding 1), noone has yet responded as to why we need a template for > a document where registration requires IETF work. The template > >is in my view there to ensure all the information that is needed is > available for expert review. The document management of an internet > >draft means that if information is needed for review the next revision > can provide it. We only need a template if someone decides a different > >registration policy is needed. >=20 > Fair enough. I hereby withdraw my request for a template :) >=20 > Regards, >=20 > Christer >=20 >=20 > > -----Original Message----- > > From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On > > Behalf Of Paul Kyzivat > > Sent: 28 November 2012 22:04 > > To: sipcore@ietf.org > > Subject: Re: [sipcore] Proposal: Call for adoption & WGLC: > > draft-roach- > > sipcore-priority-00 > > > > The WGLC and adoption deadline has now passed for > > draft-roach-sipcore-priority-00. Nine people (other than chairs and > > authors) made meaningful comments. > > > > I conclude there is consensus to adopt this draft as a wg document. > > > > Regarding WGLC, two notable issues were raised, and I don't yet see a > > clear consensus on those issues: > > > > - should there be a registration template? > > Christer advocates this, Keith opposes, Adam finds it unnecessary. > > > > - should this document also spell out the semantics of all the > priority > > values defined in 3261? (Currently it only defines "emergency".) > > Dan, James, and Roy in favor, Adam and I prefer not to do it *in > this > > document*. > > > > So, I will ask Adam to submit a wg draft version of this document, > > otherwise unchanged. > > > > While he is doing that, I would like to get a broader consensus on > the > > issues above. I'll post a separate question on each of those, to keep > > the discussions separate. > > > > Thanks, > > Paul > > > > On 11/12/12 3:49 PM, Paul Kyzivat wrote: > > > 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 > _______________________________________________ > 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 From pkyzivat@alum.mit.edu Thu Nov 29 08:41:18 2012 Return-Path: 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 F358B21F89A9 for ; Thu, 29 Nov 2012 08:41:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.387 X-Spam-Level: X-Spam-Status: No, score=-0.387 tagged_above=-999 required=5 tests=[AWL=0.050, 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 8uSLpa7kbuUl for ; Thu, 29 Nov 2012 08:41:17 -0800 (PST) Received: from qmta02.westchester.pa.mail.comcast.net (qmta02.westchester.pa.mail.comcast.net [IPv6:2001:558:fe14:43:76:96:62:24]) by ietfa.amsl.com (Postfix) with ESMTP id 18AA221F84C5 for ; Thu, 29 Nov 2012 08:41:16 -0800 (PST) Received: from omta04.westchester.pa.mail.comcast.net ([76.96.62.35]) by qmta02.westchester.pa.mail.comcast.net with comcast id VPfA1k0050ldTLk51UhGsV; Thu, 29 Nov 2012 16:41:16 +0000 Received: from Paul-Kyzivats-MacBook-Pro.local ([50.138.229.164]) by omta04.westchester.pa.mail.comcast.net with comcast id VUhG1k0083ZTu2S3QUhGin; Thu, 29 Nov 2012 16:41:16 +0000 Message-ID: <50B7902B.2040103@alum.mit.edu> Date: Thu, 29 Nov 2012 11:41:15 -0500 From: Paul Kyzivat 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: Christer Holmberg References: <50A160D8.8030602@alum.mit.edu> <50B68A43.8040605@alum.mit.edu> <50B68E74.3060307@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B048D89@ESESSMB209.ericsson.se> In-Reply-To: <7594FB04B1934943A5C02806D1A2204B048D89@ESESSMB209.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1354207276; bh=JKXRS/aiiT9YNKYgfQZ0y5vAZIio6Th9Zd2amtr5qHc=; h=Received:Received:Message-ID:Date:From:MIME-Version:To:Subject: Content-Type; b=d5mBpGDG8+5bHHzs+Kh9w+ENYYVxuXBqw5JB5+kB6VBSGVdOs0c69K/PDqNtr+QMA sM2282txC7wg3ZqjXbDLE2TkTplxY8fphRs7PWUTevObzhnk/LwYlyCPsb/EiQWNCX 4FfsB+eEPSVtAWibVOMUGtf1GmuM+oWPBlJrSHLFxskImXnj3yfH9ElZSMH6kyEqAE DMxsK6DBhebRkGUFUpJhiqKUMcpAZsSbu60SH0MFXpeebPnHl2jLXcIxWFCa6TpSwU m9ge36t2O7pAPfoTW1uBN6mU9cnscbJJVh3bcpH8FFRGE9BQuDJCljnpQmZAG10xz5 djeehvlfzy/yA== Cc: "sipcore@ietf.org" Subject: Re: [sipcore] consensus call: draft-roach-sipcore-priority-00: IANA registration template needed? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Nov 2012 16:41:18 -0000 On 11/29/12 2:33 AM, Christer Holmberg wrote: > Hi Paul, > >> We are in the process of adopting draft-roach-sipcore-priority-00 as a wg document. We already ran a WGLC on it in anticipation of the adoption. >> >> One issue raised during the WGLC was whether the document should include some sort of IANA registration template. Christer proposed this, and Keith opposed it. >> >> Christer failed to specify what he wanted to see in this template. The existing document specifies what the registry should contain: A "priority" name and a document >> reference. "IETF Review" is required for adding new values, which ensures that there will be an RFC to reference. >> So presumably the template would include at least these two values. >> >> Please indicate if you think the draft is ok as-is, or should be revised to include a registration template. >> >> If you favor a template, please indicate what you think it should contain. > > What do you mean by "Christer failed to specify"? > > 13th November I DID send text proposal to the list for the registration template. It contained Description, Reference and Contact. See copy at the end of this reply. Oh, sorry. I must have looked at the wrong message. > However, 15th November I indicated on the list that, if nobody else think a template is needed, I'll step down :) > > The important thing is that it is clear to a person who want to register a value WHAT information to provide, and WHERE to send it. What's necessary is to supply the info that is in the IANA registry. As currently proposed, that is only the name of the value and a reference to the RFC that defines it. There is no need to send it anywhere, because it calls for IETF Review, which requires an RFC, and the IETF RFC process deals with IANA considerations. It is really hard to write an RFC that defines a new Priority value without specifying the name of that value. I think people will remember to do this even without a template. :-) Thanks, Paul > Regards, > > Christer > > > ------------------- > > x. Priority Header Field Value Registration Template > > Registration requests for Priority header field values > requires submitting an Internet-Draft to the IESG. > > | Instructions are preceded by '|'. All fields are mandatory. > > Priority header field value: > > Description: > > | The description should be no longer than 4 lines. More > | detailed information can be provided in the specification > | that defines the header field value. > > Priority header field value specification reference: > > | The reference to the speicification the defines the > | header field value. > > Contact: > > | Name(s) & email address(es) of person(s) to > | contact for further information." > > ------------------- > > From christer.holmberg@ericsson.com Thu Nov 29 11:15:22 2012 Return-Path: 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 44D1621F8B9D for ; Thu, 29 Nov 2012 11:15:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.154 X-Spam-Level: X-Spam-Status: No, score=-6.154 tagged_above=-999 required=5 tests=[AWL=0.095, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] 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 lf1MUYjFAtT0 for ; Thu, 29 Nov 2012 11:15:15 -0800 (PST) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 529B721F8B9A for ; Thu, 29 Nov 2012 11:15:15 -0800 (PST) X-AuditID: c1b4fb30-b7f936d0000018b3-e4-50b7b44218fe Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 5F.18.06323.244B7B05; Thu, 29 Nov 2012 20:15:14 +0100 (CET) Received: from ESESSHC024.ericsson.se (153.88.183.90) by esessmw0191.eemea.ericsson.se (153.88.115.84) with Microsoft SMTP Server (TLS) id 8.3.279.1; Thu, 29 Nov 2012 20:15:13 +0100 Received: from ESESSMB209.ericsson.se ([169.254.9.119]) by ESESSHC024.ericsson.se ([153.88.183.90]) with mapi id 14.02.0318.001; Thu, 29 Nov 2012 20:15:13 +0100 From: Christer Holmberg To: Paul Kyzivat Thread-Topic: [sipcore] consensus call: draft-roach-sipcore-priority-00: IANA registration template needed? Thread-Index: AQHNzbbBe6sci1iEWUqAvhw1W5u4NZgAadkwgACKqICAADuEjA== Date: Thu, 29 Nov 2012 19:15:12 +0000 Message-ID: <7594FB04B1934943A5C02806D1A2204B049A70@ESESSMB209.ericsson.se> References: <50A160D8.8030602@alum.mit.edu> <50B68A43.8040605@alum.mit.edu> <50B68E74.3060307@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B048D89@ESESSMB209.ericsson.se>, <50B7902B.2040103@alum.mit.edu> In-Reply-To: <50B7902B.2040103@alum.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.18] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrELMWRmVeSWpSXmKPExsUyM+Jvja7Tlu0BBp2fxSxWbDjAavH1xyY2 ByaPv+8/MHksWfKTKYApissmJTUnsyy1SN8ugStj9oYJTAXPWCt+H/rM0sC4h6WLkZNDQsBE 4vzSl0wQtpjEhXvr2UBsIYGTjBKfXrFA2DsZJTbvCeli5AKylzBKNP+cCVTEwcEmYCHR/U8b xBQR0JCYtFUNpJxZQFPi0c69YCOFBXIklrf2gY0UEciV6H/xmAXCdpK4vrifHcRmEVCVWH/8 HzvIGF4Bb4k3V+IgNp1nlJhzeDtYPaeAjkT79dtgNiPQmd9PrWGC2CUucevJfKjzBSSW7DnP DGGLSrx8/I8VwlaU+PhqHyNEvY7Egt2f2CBsbYllC1+D1fMKCEqcnPkE6l1tiZbFE9gnMErM QrJiFpL2WUjaZyFpX8DIsoqRPTcxMye93HwTIzCeDm75bbCDcdN9sUOM0hwsSuK8eqr7/YUE 0hNLUrNTUwtSi+KLSnNSiw8xMnFwSjUwTi334M1XWfZgb2gb+yEe3mfic56rBTZ/7tiQGsu9 a7eZy9qtDzvNDirU++5pfjbz4Ptbc/UXJS9R+1nncciCe9GXT3UyT7Z7P8q+1rTh2QIZTnsu 94sPU35+3M1gtm1T69lC9we1Sm9M9q058rxX+flvYYOEUhUm64Ip9St6pE8fCYp76fpnrhJL cUaioRZzUXEiAC78Glx1AgAA Cc: "sipcore@ietf.org" Subject: Re: [sipcore] consensus call: draft-roach-sipcore-priority-00: IANA registration template needed? X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Nov 2012 19:15:22 -0000 Hi, >> The important thing is that it is clear to a person who want to register= a value WHAT information to provide, and WHERE to send it. > > What's necessary is to supply the info that is in the IANA registry. As > currently proposed, that is only the name of the value and a reference > to the RFC that defines it. > > There is no need to send it anywhere, because it calls for IETF Review, > which requires an RFC, and the IETF RFC process deals with IANA > considerations. > > It is really hard to write an RFC that defines a new Priority value > without specifying the name of that value. I think people will remember > to do this even without a template. :-) I'll take your word for it :) Regards, Christer From worley@shell01.TheWorld.com Thu Nov 29 12:59:31 2012 Return-Path: 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 22D9D21F8C56 for ; Thu, 29 Nov 2012 12:59:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.48 X-Spam-Level: X-Spam-Status: No, score=-2.48 tagged_above=-999 required=5 tests=[AWL=0.500, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_SORBS_WEB=0.619] 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 cEUSalUgu6Ck for ; Thu, 29 Nov 2012 12:59:30 -0800 (PST) Received: from TheWorld.com (pcls5.std.com [192.74.137.145]) by ietfa.amsl.com (Postfix) with ESMTP id C69C521F8B9A for ; Thu, 29 Nov 2012 12:59:29 -0800 (PST) Received: from shell.TheWorld.com (root@shell01.theworld.com [192.74.137.71]) by TheWorld.com (8.14.5/8.14.5) with ESMTP id qATKxBJG005519 for ; Thu, 29 Nov 2012 15:59:13 -0500 Received: from shell01.TheWorld.com (localhost.theworld.com [127.0.0.1]) by shell.TheWorld.com (8.13.6/8.12.8) with ESMTP id qATKxAjc2024279 for ; Thu, 29 Nov 2012 15:59:11 -0500 (EST) Received: (from worley@localhost) by shell01.TheWorld.com (8.13.6/8.13.6/Submit) id qATKxA3B2027357; Thu, 29 Nov 2012 15:59:10 -0500 (EST) Date: Thu, 29 Nov 2012 15:59:10 -0500 (EST) Message-Id: <201211292059.qATKxA3B2027357@shell01.TheWorld.com> From: worley@ariadne.com (Dale R. Worley) Sender: worley@ariadne.com (Dale R. Worley) To: sipcore@ietf.org Subject: [sipcore] 4244bis time-ordering X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Nov 2012 20:59:31 -0000 After discussing 4244bis with Mary Barnes at the IETF, I now know that the intention of draft-ietf-sipcore-rfc4244bis is that History-Info entries are to be accumulated in a proxy's cache more-or-less in the *time* order that they are received from downstream, not in the tree order based on their index values. I'm now working out the consequences of this. In a previous message (http://www.ietf.org/mail-archive/web/sipcore/current/msg05220.html) I considered the case of a proxy ("atlanta") that supports History-Info sending an INVITE to a proxy ("biloxi") that does not support History-Info, but biloxi forks the INVITE to two targets which both support History-Info. This is to correct that example according to the time-order principle (and fix some minor problems). This is an example where a proxy/registrar forks the call to several alternative destinations. The proxy/registrar does not support History-Info but the destinations do. Alice atlanta.example.com biloxi.example.com Bob Office | | | | | | INVITE F1 | | | | |--------------->| | | | | | | | | | | INVITE F2 | | | | |--------------->| | | | | | | | | | | INVITE F3 | | | | |--------------->| | | | | | | | | | 180 Ringing F4 | | | | |<---------------| | | | | | | | | 180 Ringing F5 | | | |<---------------| | | | | | | | | 180 Ringing F6 | | | |<---------------| | | | | | | | | | | | 408 Timeout F7 | | | | |<---------------| | | | | | | | | | INVITE F8 | | | | |------------------------>| | | | | | | | | 180 Ringing F9 | | | | |<------------------------| | | | | | | | 180 Ringing F10 | | | |<---------------| | | | | | | | | 180 Ringing F11 | | | |<---------------| | | | | | | | | | | | 200 OK F12 | | | | |<------------------------| | | | | | | | 200 OK F13 | | | | |<---------------| | | | | | | | | 200 OK F14 | | | | |<---------------| | | | | | | | | | ACK | | | | |--------------->| ACK | | | | |--------------->| ACK | | | | |------------------------>| Example with forking by non-supporting proxy Note that atlanta.example.com and all the UAs support History-Info; biloxi.example.com does not. F1 INVITE alice -> atlanta.example.com INVITE sip:bob@biloxi.example.com SIP/2.0 Via: SIP/2.0/TCP 192.0.2.3:5060;branch=z9hG4bK4321 From: Alice ;tag=22 To: Bob Supported: histinfo Call-Id: 12345600@atlanta.example.com CSeq: 1 INVITE History-Info: ;index=1 Contact: Alice Content-Type: application/sdp Content-Length: F2 INVITE atlanta.example.com -> biloxi.example.com INVITE sip:bob@biloxi.example.com SIP/2.0 Via: SIP/2.0/TCP proxy.atlanta.example.com:5060;branch=z9hG4bKbst2 Via: SIP/2.0/TCP 192.0.2.3:5060;branch=z9hG4bK4321 From: Alice ;tag=22 To: Bob Supported: histinfo Call-Id: 12345600@atlanta.example.com CSeq: 1 INVITE History-Info: ;index=1 History-Info: ;index=1.1;rc=1 Contact: Alice Content-Type: application/sdp Content-Length: F3 INVITE biloxi.example.com -> Bob INVITE sip:bob@192.0.1.11 SIP/2.0 Via: SIP/2.0/TCP proxy.biloxi.example.com:5060;branch=z9hG4bK Via: SIP/2.0/TCP proxy.atlanta.example.com:5060;branch=z9hG4bKbst2 Via: SIP/2.0/TCP 192.0.2.3:5060;branch=z9hG4bK4321 From: Alice ;tag=22 To: Bob Supported: histinfo Call-Id: 12345600@atlanta.example.com CSeq: 1 INVITE Expires: 30 History-Info: ;index=1 History-Info: ;index=1.1;rc=1 Contact: Alice Content-Type: application/sdp Content-Length: Response F4 contains an hi-entry with index 1.1.0.1 because UI Bob detects a gap in the hi-entries. F4 180 Ringing bob -> biloxi.example.com SIP/2.0 180 Ringing Via: SIP/2.0/TCP proxy.biloxi.example.com:5060;branch=z9hG4bK Via: SIP/2.0/TCP proxy.atlanta.example.com:5060;branch=z9hG4bKbst2 Via: SIP/2.0/TCP 192.0.2.3:5060;branch=z9hG4bK4321 From: Alice ;tag=22 To: Bob ;tag=33 Supported: histinfo Call-Id: 12345600@atlanta.example.com CSeq: 1 INVITE History-Info: ;index=1 History-Info: ;index=1.1;rc=1 History-Info: ;index=1.1.0.1 Contact: Bob Content-Type: application/sdp Content-Length: atlanta adds the hi-entry 1.1.0.1 to its cache *at the end*: It is added because atlanta hasn't seen that entry before, and new entries are always added at the end. F5 180 Ringing biloxi.example.com -> atlanta.example.com SIP/2.0 180 Ringing Via: SIP/2.0/TCP proxy.atlanta.example.com:5060;branch=z9hG4bKbst2 Via: SIP/2.0/TCP 192.0.2.3:5060;branch=z9hG4bK4321 From: Alice ;tag=22 To: Bob ;tag=33 Supported: histinfo Call-Id: 12345600@atlanta.example.com CSeq: 1 INVITE History-Info: ;index=1 History-Info: ;index=1.1;rc=1 History-Info: ;index=1.1.0.1 Contact: Bob Content-Type: application/sdp Content-Length: atlanta adds a Reason parameter to entry 1.1, due to receiving a 180 from that branch of the call. [Is this what we intend? The text in section 9.3 is clear that 1xx responses cause "Reason" header values, but examples in draft-ietf-sipcore-rfc4244bis-callflows-01 show that not being done (e.g., F8 in 3.1), and it's not clear how useful it would be.] F6 180 Ringing atlanta.example.com -> alice SIP/2.0 180 Ringing Via: SIP/2.0/TCP 192.0.2.3:5060;branch=z9hG4bK4321 From: Alice ;tag=22 To: Bob ;tag=33 Supported: histinfo Call-Id: 12345600@atlanta.example.com CSeq: 1 INVITE History-Info: ;index=1 History-Info: ;index=1.1;rc=1 History-Info: ;index=1.1.0.1 Contact: Bob Content-Type: application/sdp Content-Length: F7 408 Timeout bob -> biloxi.example.com SIP/2.0 408 Timeout Via: SIP/2.0/TCP proxy.biloxi.example.com:5060;branch=z9hG4bK Via: SIP/2.0/TCP proxy.atlanta.example.com:5060;branch=z9hG4bKbst2 Via: SIP/2.0/TCP 192.0.2.3:5060;branch=z9hG4bK4321 From: Alice ;tag=22 To: Bob ;tag=33 Supported: histinfo Call-Id: 12345600@atlanta.example.com CSeq: 1 INVITE History-Info: ;index=1 History-Info: ;index=1.1;rc=1 History-Info: ;index=1.1.0.1 Contact: Bob Content-Type: application/sdp Content-Length: F8 INVITE biloxi.example.com -> office INVITE sip:office@192.0.1.123 SIP/2.0 Via: SIP/2.0/TCP proxy.biloxi.example.com:5060;branch=z9hG4bKxyz Via: SIP/2.0/TCP proxy.atlanta.example.com:5060;branch=z9hG4bKbst2 Via: SIP/2.0/TCP 192.0.2.3:5060;branch=z9hG4bK4321 From: Alice ;tag=22 To: Bob Supported: histinfo Call-Id: 12345600@atlanta.example.com CSeq: 1 INVITE Expires: 30 History-Info: ;index=1 History-Info: ;index=1.1;rc=1 Contact: Alice Content-Type: application/sdp Content-Length: Response F9 contains an hi-entry with index 1.1.0.1 because UI Office detects a gap in the hi-entries. F9 180 Ringing office -> biloxi.example.com SIP/2.0 180 Ringing Via: SIP/2.0/TCP proxy.biloxi.example.com:5060;branch=z9hG4bKxyz Via: SIP/2.0/TCP proxy.atlanta.example.com:5060;branch=z9hG4bKbst2 Via: SIP/2.0/TCP 192.0.2.3:5060;branch=z9hG4bK4321 From: Alice ;tag=22 To: Bob ;tag=44 Supported: histinfo Call-Id: 12345600@atlanta.example.com CSeq: 1 INVITE History-Info: ;index=1 History-Info: ;index=1.1;rc=1 History-Info: ;index=1.1.0.1 Contact: Office Content-Type: application/sdp Content-Length: F10 180 Ringing biloxi.example.com -> atlanta.example.com SIP/2.0 180 Ringing Via: SIP/2.0/TCP proxy.atlanta.example.com:5060;branch=z9hG4bKbst2 Via: SIP/2.0/TCP 192.0.2.3:5060;branch=z9hG4bK4321 From: Alice ;tag=22 To: Bob ;tag=44 Supported: histinfo Call-Id: 12345600@atlanta.example.com CSeq: 1 INVITE History-Info: ;index=1 History-Info: ;index=1.1;rc=1 History-Info: ;index=1.1.0.1 Contact: Office Content-Type: application/sdp Content-Length: atlanta adds the second hi-entry with index 1.1.0.1 to its cache *at the end*: It is added because atlanta hasn't seen that entry before, and new entries are always added at the end. atlanta needs to record a Reason specifying response 180 in index 1.1. It presumably replaces the previous Reason 180 in that entry. F11 180 Ringing atlanta.example.com -> alice SIP/2.0 180 Ringing Via: SIP/2.0/TCP 192.0.2.3:5060;branch=z9hG4bK4321 From: Alice ;tag=22 To: Bob ;tag=44 Supported: histinfo Call-Id: 12345600@atlanta.example.com CSeq: 1 INVITE History-Info: ;index=1 History-Info: ;index=1.1;rc=1 History-Info: ;index=1.1.0.1 History-Info: ;index=1.1.0.1 Contact: Office Content-Type: application/sdp Content-Length: Under the principle that hi-entries are accumulated in the cache in time order, there are two hi-entries with index 1.1.0.1, recorded in the order in which they were received by atlanta. In this case, the UAC can connect the hi-entries correctly, since it knows that the parent of 1.1.0.1 is always 1.1. Dale From worley@shell01.TheWorld.com Thu Nov 29 13:19:06 2012 Return-Path: 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 1E46521F8C3F for ; Thu, 29 Nov 2012 13:19:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.563 X-Spam-Level: X-Spam-Status: No, score=-2.563 tagged_above=-999 required=5 tests=[AWL=0.417, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, RCVD_IN_SORBS_WEB=0.619] 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 FEj+fwE3kZfy for ; Thu, 29 Nov 2012 13:19:05 -0800 (PST) Received: from TheWorld.com (pcls4.std.com [192.74.137.144]) by ietfa.amsl.com (Postfix) with ESMTP id 8F3C921F8C3E for ; Thu, 29 Nov 2012 13:19:05 -0800 (PST) Received: from shell.TheWorld.com (root@shell01.theworld.com [192.74.137.71]) by TheWorld.com (8.14.5/8.14.5) with ESMTP id qATLIOLu019994 for ; Thu, 29 Nov 2012 16:18:26 -0500 Received: from shell01.TheWorld.com (localhost.theworld.com [127.0.0.1]) by shell.TheWorld.com (8.13.6/8.12.8) with ESMTP id qATLIO9J2023234 for ; Thu, 29 Nov 2012 16:18:24 -0500 (EST) Received: (from worley@localhost) by shell01.TheWorld.com (8.13.6/8.13.6/Submit) id qATLINTj2028230; Thu, 29 Nov 2012 16:18:23 -0500 (EST) Date: Thu, 29 Nov 2012 16:18:23 -0500 (EST) Message-Id: <201211292118.qATLINTj2028230@shell01.TheWorld.com> From: worley@ariadne.com (Dale R. Worley) Sender: worley@ariadne.com (Dale R. Worley) To: sipcore@ietf.org Subject: [sipcore] 4244bis callflows X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Nov 2012 21:19:06 -0000 While working on callflows, I see that in draft-ietf-sipcore-rfc4244bis-10 it is clear that (non-100) 1xx responses require logging the response code in the corresponding hi-entry: 9.3. Receiving a Response with History-Info or Request Timeouts When a SIP entity receives a non-100 response or a request times out, the SIP entity performs the following steps: Step 1: Add hi-entry to cache [...] Step 2: Add Reason header field [...] I have a vague memory that we explicitly discussed this issue at some time, and that recording 1xx responses is intended. But in draft-ietf-sipcore-rfc4244bis-callflows-01, Reason header values for 1xx responses are not generated. See message F8 in section 3.1. (In a previous message, I referred to this incorrectly as "message F8 in section 3.2".) I can't find anyone's critique addressing this as an error in rfc4244bis-callflows. Do we intend for 1xx response codes to be logged in hi-entry Reason values? Dale From keith.drage@alcatel-lucent.com Thu Nov 29 18:25:05 2012 Return-Path: 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 2720421F8496 for ; Thu, 29 Nov 2012 18:25:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.999 X-Spam-Level: X-Spam-Status: No, score=-109.999 tagged_above=-999 required=5 tests=[AWL=0.250, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8, 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 5DTv+Hm3l6zP for ; Thu, 29 Nov 2012 18:25:04 -0800 (PST) Received: from smail3.alcatel.fr (smail3.alcatel.fr [64.208.49.56]) by ietfa.amsl.com (Postfix) with ESMTP id D011421F847F for ; Thu, 29 Nov 2012 18:25:03 -0800 (PST) Received: from FRMRSSXCHHUB04.dc-m.alcatel-lucent.com (FRMRSSXCHHUB04.dc-m.alcatel-lucent.com [135.120.45.64]) by smail3.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id qAU2P1K2009170 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 30 Nov 2012 03:25:01 +0100 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.48]) by FRMRSSXCHHUB04.dc-m.alcatel-lucent.com ([135.120.45.64]) with mapi; Fri, 30 Nov 2012 03:25:01 +0100 From: "DRAGE, Keith (Keith)" To: "Tschofenig, Hannes (NSN - FI/Espoo)" , "sipcore@ietf.org" Date: Fri, 30 Nov 2012 03:25:00 +0100 Thread-Topic: [sipcore] Proposal: Call for adoption& WGLC: draft-roach-sipcore-priority-00 Thread-Index: AQHNzibk1HK3qgXMgkaEs3fc67a3ZpgAskLwgAAGCjCAANpSkA== Message-ID: References: <50A160D8.8030602@alum.mit.edu> <50B68A43.8040605@alum.mit.edu> <7594FB04B1934943A5C02806D1A2204B0493C3@ESESSMB209.ericsson.se> <999913AB42CC9341B05A99BBF358718D0229B91C@FIESEXC035.nsn-intra.net> In-Reply-To: <999913AB42CC9341B05A99BBF358718D0229B91C@FIESEXC035.nsn-intra.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.69 on 155.132.188.83 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 30 Nov 2012 02:25:05 -0000 If you look at some IANA tables, you will see a link to template, where the= template contains more information than the IANA registry. My assumption has been that this is to allow the gathering of extra informa= tion beyond the bare table, where an expert is designated to review the ent= ry to ensure it makes sense. This of course depends on the guidance given t= o the expert who is performing the expert review from the original RFC that= established the registry. If the expert is just expected to make sure all = the table entries are present then you probably don't need one. If the expe= rt is required to investigate in a more technical sense, then they need mor= e information.=20 Additionally RFC 3265 and its successor have a template for documenting eve= nt packages for example, which carries much more information than is needed= for the IANA registry. Keith > -----Original Message----- > From: Tschofenig, Hannes (NSN - FI/Espoo) > [mailto:hannes.tschofenig@nsn.com] > Sent: 29 November 2012 12:21 > To: ext Christer Holmberg; DRAGE, Keith (Keith); Paul Kyzivat; > sipcore@ietf.org > Subject: RE: [sipcore] Proposal: Call for adoption& WGLC: draft-roach- > sipcore-priority-00 >=20 > I fear you guys read a bit too much into the term "template". >=20 > IANA typically wants to know what information a request for adding a new > value into an existing registry should contain. This is called the > template. As mentioned, here the required info is pretty obvious: a > label and a reference to a document that contains the semantic. If you > want to make it 100% clear add a sentence: "Registration requests to > IANA must include a label (value for the priority header field) and a > reference to a document that explains the semantic of that label." >=20 > What is, however, missing from the IANA consideration is an indication > whether you envision entries to be updated, deleted, or deprecated. I > would write "Updating, deleting, or deprecating of entries in the > registry is not envisioned." >=20 > Ciao > Hannes >=20 > > -----Original Message----- > > From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On > > Behalf Of ext Christer Holmberg > > Sent: Thursday, November 29, 2012 1:51 PM > > To: DRAGE, Keith (Keith); Paul Kyzivat; sipcore@ietf.org > > Subject: Re: [sipcore] Proposal: Call for adoption& WGLC: draft-roach- > > sipcore-priority-00 > > > > Hi, > > > > >Regarding 1), noone has yet responded as to why we need a template > for > > a document where registration requires IETF work. The template > > >is in my view there to ensure all the information that is needed is > > available for expert review. The document management of an internet > > >draft means that if information is needed for review the next > revision > > can provide it. We only need a template if someone decides a different > > >registration policy is needed. > > > > Fair enough. I hereby withdraw my request for a template :) > > > > Regards, > > > > Christer > > > > > > > -----Original Message----- > > > From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On > > > Behalf Of Paul Kyzivat > > > Sent: 28 November 2012 22:04 > > > To: sipcore@ietf.org > > > Subject: Re: [sipcore] Proposal: Call for adoption & WGLC: > > > draft-roach- > > > sipcore-priority-00 > > > > > > The WGLC and adoption deadline has now passed for > > > draft-roach-sipcore-priority-00. Nine people (other than chairs and > > > authors) made meaningful comments. > > > > > > I conclude there is consensus to adopt this draft as a wg document. > > > > > > Regarding WGLC, two notable issues were raised, and I don't yet see > a > > > clear consensus on those issues: > > > > > > - should there be a registration template? > > > Christer advocates this, Keith opposes, Adam finds it > unnecessary. > > > > > > - should this document also spell out the semantics of all the > > priority > > > values defined in 3261? (Currently it only defines "emergency".) > > > Dan, James, and Roy in favor, Adam and I prefer not to do it *in > > this > > > document*. > > > > > > So, I will ask Adam to submit a wg draft version of this document, > > > otherwise unchanged. > > > > > > While he is doing that, I would like to get a broader consensus on > > the > > > issues above. I'll post a separate question on each of those, to > keep > > > the discussions separate. > > > > > > Thanks, > > > Paul > > > > > > On 11/12/12 3:49 PM, Paul Kyzivat wrote: > > > > 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 > > _______________________________________________ > > 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