From fluffy@cisco.com Tue Apr 14 11:28:30 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4499428C1EA for ; Tue, 14 Apr 2009 11:28:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.591 X-Spam-Level: X-Spam-Status: No, score=-106.591 tagged_above=-999 required=5 tests=[AWL=0.008, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W4YketM0UMLs for ; Tue, 14 Apr 2009 11:28:29 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 940BB28C1E6 for ; Tue, 14 Apr 2009 11:28:29 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,186,1238976000"; d="scan'208";a="153222953" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-3.cisco.com with ESMTP; 14 Apr 2009 18:29:41 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id n3EITfEh022823 for ; Tue, 14 Apr 2009 11:29:41 -0700 Received: from [192.168.4.177] (rcdn-fluffy-8711.cisco.com [10.99.9.18]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id n3EITe1r014172 for ; Tue, 14 Apr 2009 18:29:40 GMT Message-Id: <174A1A28-F34D-47E4-BCA3-518DAC095762@cisco.com> From: Cullen Jennings To: sipcore@ietf.org Impp: xmpp:cullenfluffyjennings@jabber.org Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Tue, 14 Apr 2009 12:29:39 -0600 X-Mailer: Apple Mail (2.930.3) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3; t=1239733781; x=1240597781; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:=20Cullen=20Jennings=20 |Subject:=20test=203 |Sender:=20; bh=JLoemdwGsZNRMjquDXNwJD1YZHWmNLf2/3kn+8cs+u0=; b=Xe/8IjgO6jyAOaVJ8xvp4P+9ViaTbBHtNrWOpnocJjb0x9BxJ3O2QwC45G BdvNNTO72XuR9/eUDeUC6PR4ICHBO/AV677811Mf87h5pPyuZW728K4+Fwgv agF50QZzzG; Authentication-Results: sj-dkim-4; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Subject: [sipcore] test 3 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Apr 2009 18:28:30 -0000 3 From root@core3.amsl.com Tue Apr 14 13:00:02 2009 Return-Path: X-Original-To: sipcore@ietf.org Delivered-To: sipcore@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 341F83A6E10; Tue, 14 Apr 2009 13:00:01 -0700 (PDT) From: IESG Secretary To: ietf-announce@ietf.org Content-Type: text/plain; charset="utf-8" Mime-Version: 1.0 Message-Id: <20090414200002.341F83A6E10@core3.amsl.com> Date: Tue, 14 Apr 2009 13:00:02 -0700 (PDT) Cc: sipcore@ietf.org, Gonzalo.Camarillo@ericsson.com Subject: [sipcore] WG Action: Session Initiation Protocol Core (SIPCore) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Apr 2009 20:00:02 -0000 A new IETF working group has been formed in the Real-time Applications and Infrastructure Area. For additional information, please contact the Area Directors or the WG Chairs. Session Initiation Protocol Core (SIPCore) -------------------------------------------------- Current Status: Active Working Group Last Modified: 2009-04-13 Chairs: Gonzalo Camarillo [Gonzalo.Camarillo@ericsson.com] Adam Roach [adam@nostrum.com] Real-time Applications and Infrastructure Area Directors: Cullen Jennings [fluffy@cisco.com] Robert Sparks [rjsparks@nostrum.com] Real-time Applications and Infrastructure Area Advisor: Robert Sparks [rjsparks@nostrum.com] Mailing Lists: General Discussion: sipcore@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/sipcore Archive: http://www.ietf.org/mail-archive/web/sipcore/ Group Description: The Session Initiation Protocol Core (SIPCore) working group is chartered to maintain and continue the development of the core SIP specifications, currently defined as proposed standard RFCs 3261, 3262, 3263, 3264, and 3265. The SIPCore working group will concentrate on specifications that update or replace the core SIP specifications. In this context, "update" means replacing or modifying protocol elements in the above listed RFCs in ways that would affect most or all implementations of those RFCs alone. Extensions to SIP that add new functionality that would not be required of all implementations will be done outside of this WG. The process and requirements for such extensions are documented in RFC 3427bis, "Change Process for the Session Initiation Protocol". Throughout its work, the group will strive to maintain the basic model and architecture defined by SIP. In particular: 1. Services and features are provided end-to-end whenever possible. 2. Reuse of existing Internet protocols and architectures and integrating with other Internet applications is crucial. The primary source of change requirements will be a) interoperability problems that stem from ambiguous, or under-defined specification, and b) requirements from other working groups in the RAI Area. Although in general the WG will not work on extensions to SIP, it may take on some previous work items from the SIP working group to allow for a smooth transition. The adoption of new items requires explicit agreement from the AD or rechartering. Goals and Milestones: Jul 2009 Delivering request-URI and parameters to UAS via proxy to IESG (PS) Jul 2009 INFO package framework to IESG (PS) Aug 2009 Termination of early dialog prior to final response to IESG (PS) Aug 2009 Location Conveyance with SIP to IESG (PS) Sep 2009 Essential corrections to RFC 3261 (1st batch) to IESG (PS) Oct 2009 Example security flows to IESG (Informational) Oct 2009 Extension for use in etags in conditional notification toIESG (PS) Dec 2009 SIP Events throttling mechanism to IESG (PS) Dec 2009 Mechanism for indicating support for keep-alives (PS) Jan 2010 Presence Scaling Requirements to IESG as Info From dean.willis@softarmor.com Tue Apr 14 14:49:29 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E2BA13A6AF6 for ; Tue, 14 Apr 2009 14:49:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.553 X-Spam-Level: X-Spam-Status: No, score=-2.553 tagged_above=-999 required=5 tests=[AWL=0.046, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uEsrtxMfTd8X for ; Tue, 14 Apr 2009 14:49:29 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 2F8FB3A63D3 for ; Tue, 14 Apr 2009 14:49:26 -0700 (PDT) Received: from [192.168.2.101] (cpe-72-181-150-177.tx.res.rr.com [72.181.150.177] (may be forged)) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id n3ELoa6O016324 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Tue, 14 Apr 2009 16:50:37 -0500 Message-Id: From: Dean Willis To: sipcore@ietf.org Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Tue, 14 Apr 2009 16:50:31 -0500 X-Mailer: Apple Mail (2.930.3) Subject: [sipcore] Test, please ignore X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Apr 2009 21:49:30 -0000 Just checking to make sure I got all my filters set up right. Hope y'all are having a great day! -- Dean From christer.holmberg@ericsson.com Thu Apr 16 01:33:10 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 989723A6AB1; Thu, 16 Apr 2009 01:33:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.796 X-Spam-Level: X-Spam-Status: No, score=-5.796 tagged_above=-999 required=5 tests=[AWL=0.452, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BoUW4VoFEf6Q; Thu, 16 Apr 2009 01:33:09 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 26B333A68B3; Thu, 16 Apr 2009 01:33:09 -0700 (PDT) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id E10F92109C; Thu, 16 Apr 2009 10:34:20 +0200 (CEST) X-AuditID: c1b4fb3c-adfd1bb00000238f-00-49e6ed8cc090 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.253.124]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id BF55C21074; Thu, 16 Apr 2009 10:34:20 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 16 Apr 2009 10:33:26 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C9BE6D.C021EDFF" Date: Thu, 16 Apr 2009 10:31:34 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Draft new version: draft-holmberg-sipcore-keep-00 (previously known as draft-holmberg-sip-keep) Thread-Index: Acm+bcAszQkyqV++Ts+HPG29TfGFgA== From: "Christer Holmberg" To: , X-OriginalArrivalTime: 16 Apr 2009 08:33:26.0227 (UTC) FILETIME=[02F83230:01C9BE6E] X-Brightmail-Tracker: AAAAAA== Cc: Gonzalo Camarillo , Mary Barnes Subject: [sipcore] Draft new version: draft-holmberg-sipcore-keep-00 (previously known as draft-holmberg-sip-keep) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Apr 2009 08:33:10 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9BE6D.C021EDFF Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I've submitted a draft-holmberg-sipcore version of the keep draft. The draft is identical to the previous version (for which Mary sent out the ask-for-support e-mail), but I have added one more example. The draft can also be found at: http://users.piuha.net/cholmber/drafts/draft-holmberg-sipcore-keep-00.tx t Regards, Christer Ps. I applogize for sending this e-mail to both SIP and SIPCORE, but since everyone may not have subscribed to SIPCORE yet... ------_=_NextPart_001_01C9BE6D.C021EDFF Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Draft new version: draft-holmberg-sipcore-keep-00 (previously = known as draft-holmberg-sip-keep)

Hi,

I've submitted a draft-holmberg-sipcore = version of the keep draft.

The draft is identical to the previous = version (for which Mary sent out the ask-for-support e-mail), but I have = added one more example.

The draft can also be found at:

http://users.piuha.net/cholmber/drafts/draft-holmberg-sipc= ore-keep-00.txt


Regards,

Christer

Ps. I applogize for sending this e-mail = to both SIP and SIPCORE, but since everyone may not have subscribed to = SIPCORE yet...

------_=_NextPart_001_01C9BE6D.C021EDFF-- From adam@nostrum.com Thu Apr 16 11:21:36 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A201C3A68B6 for ; Thu, 16 Apr 2009 11:21:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.567 X-Spam-Level: X-Spam-Status: No, score=-2.567 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, SPF_PASS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0y3VmOzU3uQo for ; Thu, 16 Apr 2009 11:21:35 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id B020B3A6A3B for ; Thu, 16 Apr 2009 11:20:59 -0700 (PDT) Received: from [172.16.3.231] (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id n3GIM79I005991 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 16 Apr 2009 13:22:07 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <49E7774F.5090608@nostrum.com> Date: Thu, 16 Apr 2009 13:22:07 -0500 From: Adam Roach User-Agent: Postbox 1.0b11 (Macintosh/2009041423) MIME-Version: 1.0 To: SIPCORE Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Cc: Gonzalo Camarillo Subject: [sipcore] Working Group Documents X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Apr 2009 18:21:36 -0000 [as chair] Hello? Is this thing on? You probably have noticed that all of the current SIPCORE milestones have been imported from other existing working groups in the RAI area. We'll be kicking things off by adopting the documents the RAI community has already agreed upon for these milestones: INFO package framework (PS) draft-ietf-sip-info-events Termination of early dialog prior to final response (PS) draft-ietf-sip-199 Location Conveyance with SIP (PS) draft-ietf-sip-location-conveyance Example security flows (Info) draft-ietf-sip-sec-flows Extension for use in etags in conditional notification (PS) draft-ietf-sip-subnot-etags Presence Scaling Requirements (Info) draft-ietf-sipping-presence-scaling-requirements The chairs will be requesting that the authors of the foregoing documents resubmit them with as draft-ietf-sipcore-* shortly. If you find an error in this list, please inform the SIPCORE chairs immediately so that we may take appropriate action. Thanks. /a From adam@nostrum.com Thu Apr 16 11:25:36 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 01DD23A68B8 for ; Thu, 16 Apr 2009 11:25:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.567 X-Spam-Level: X-Spam-Status: No, score=-2.567 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599, HTML_MESSAGE=0.001, SPF_PASS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uIDglGYzIwvV for ; Thu, 16 Apr 2009 11:25:35 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id 3CF7B3A6C77 for ; Thu, 16 Apr 2009 11:25:25 -0700 (PDT) Received: from [172.16.3.231] (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id n3GIQYPJ006358 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 16 Apr 2009 13:26:34 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <49E7785A.9060808@nostrum.com> Date: Thu, 16 Apr 2009 13:26:34 -0500 From: Adam Roach User-Agent: Postbox 1.0b11 (Macintosh/2009041423) MIME-Version: 1.0 To: SIPCORE References: <49E777BD.9000202@estacado.net> In-Reply-To: <49E777BD.9000202@estacado.net> Content-Type: multipart/alternative; boundary="------------000703090102050009050602" Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Cc: Gonzalo Camarillo Subject: [sipcore] Call for Consensus: Additional Working Group Items X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Apr 2009 18:25:36 -0000 This is a multi-part message in MIME format. --------------000703090102050009050602 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit [as chair] Following on from the previous message, we have a couple of documents that have been tentatively accepted by the RAI community to satisfy a couple of the milestones that have subsequently been moved into SIPCORE. This message is a formal call for consensus to adopt these documents as working group items to satisfy the associated milestones: Delivering request-URI and parameters to UAS via proxy (PS) draft-rosenberg-sip-target-uri-delivery [adopted by SIP WG consensus after IETF 73, still waiting for new version] SIP Events throttling mechanism (PS) draft-niemi-sipping-event-throttle [SIPPING WG indicated desire to adopt in as SIP WG item at IETF 74] Unless objections are raised before April 30th, the foregoing documents will be considered adopted as WG items for SIPCORE, and the chairs will be instructing the authors of these documents to submit new versions with "draft-ietf-sipcore-*" prefixes. /a --------------000703090102050009050602 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
[as chair]

Following on from the previous message, we have a couple of documents that have been tentatively accepted by the RAI community to satisfy a couple of the milestones that have subsequently been moved into SIPCORE. This message is a formal call for consensus to adopt these documents as working group items to satisfy the associated milestones:

Delivering request-URI and parameters to UAS via proxy    (PS)
  draft-rosenberg-sip-target-uri-delivery
  [adopted by SIP WG consensus after IETF 73, still waiting for new version]

SIP Events throttling mechanism    (PS)
  draft-niemi-sipping-event-throttle
  [SIPPING WG indicated desire to adopt in as SIP WG item at IETF 74]

Unless objections are raised before April 30th, the foregoing documents will be considered adopted as WG items for SIPCORE, and the chairs will be instructing the authors of these documents to submit new versions with "draft-ietf-sipcore-*" prefixes.

/a
--------------000703090102050009050602-- From jmpolk@cisco.com Thu Apr 16 11:57:32 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 020663A6C76 for ; Thu, 16 Apr 2009 11:57:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.469 X-Spam-Level: X-Spam-Status: No, score=-6.469 tagged_above=-999 required=5 tests=[AWL=0.130, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MZQd+ORETpCX for ; Thu, 16 Apr 2009 11:57:31 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 218DC3A6993 for ; Thu, 16 Apr 2009 11:57:31 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,200,1238976000"; d="scan'208";a="154046875" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-3.cisco.com with ESMTP; 16 Apr 2009 18:58:44 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n3GIwi4K019128; Thu, 16 Apr 2009 11:58:44 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n3GIwcl4012774; Thu, 16 Apr 2009 18:58:44 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 16 Apr 2009 11:58:42 -0700 Received: from jmpolk-wxp01.cisco.com ([10.21.68.2]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 16 Apr 2009 11:58:41 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 16 Apr 2009 13:58:37 -0500 To: Adam Roach , SIPCORE From: "James M. Polk" In-Reply-To: <49E7785A.9060808@nostrum.com> References: <49E777BD.9000202@estacado.net> <49E7785A.9060808@nostrum.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: X-OriginalArrivalTime: 16 Apr 2009 18:58:42.0293 (UTC) FILETIME=[5C499250:01C9BEC5] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=678; t=1239908324; x=1240772324; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=20=22James=20M.=20Polk=22=20 |Subject:=20Re=3A=20[sipcore]=20Call=20for=20Consensus=3A=2 0Additional=20Working=20Group=0A=20=20Items |Sender:=20; bh=ZeioZn+mMEKByPvA8NIqgOwU+z8qLqtV0PPY+dS7XaA=; b=OHTHjZtIGcCwyDaX83HNKRo5bUxInB9wXTScgcLEkrI8wIlw91jddnUMpA VrrtiKkiMaQaxIsvreyoOq5Agn5mW0685PT0dKh6sxNxu7q4QmrQu8ztIhv0 PD1dHSQHgiO9j0ZhGEIWl0RPjtOe00h+7pNcC7CR0u37sRA4KaPzE=; Authentication-Results: sj-dkim-1; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Subject: Re: [sipcore] Call for Consensus: Additional Working Group Items X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Apr 2009 18:57:32 -0000 At 01:26 PM 4/16/2009, Adam Roach wrote: >Delivering request-URI and parameters to UAS via proxy (PS) > draft-rosenberg-sip-target-uri-delivery > [adopted by SIP WG consensus after IETF 73, still waiting for new version] > >SIP Events throttling mechanism (PS) > draft-niemi-sipping-event-throttle > [SIPPING WG indicated desire to adopt in as SIP WG item at IETF 74] adopt both >Unless objections are raised before April 30th, the foregoing >documents will be considered adopted as WG items for SIPCORE, and >the chairs will be instructing the authors of these documents to >submit new versions with "draft-ietf-sipcore-*" prefixes. > >/a From mary.barnes@nortel.com Thu Apr 16 12:23:59 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CB67D3A6B7F for ; Thu, 16 Apr 2009 12:23:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.456 X-Spam-Level: X-Spam-Status: No, score=-6.456 tagged_above=-999 required=5 tests=[AWL=0.143, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G8tM0vjV1HzV for ; Thu, 16 Apr 2009 12:23:59 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id B4F713A689B for ; Thu, 16 Apr 2009 12:23:58 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id n3GJOgt16546; Thu, 16 Apr 2009 19:24:42 GMT 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, 16 Apr 2009 14:27:04 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF1D7A2BCA@zrc2hxm0.corp.nortel.com> In-Reply-To: <49E77B71.5020608@nostrum.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Sip] SIPCORE -- If you're not subscribed, you're missing stuff Thread-Index: Acm+wsDnBnKa/npOTtubcIFuj+WQgQABL9Tg References: <49E77B71.5020608@nostrum.com> From: "Mary Barnes" To: Subject: Re: [sipcore] [Sip] SIPCORE -- If you're not subscribed, you're missing stuff X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Apr 2009 19:23:59 -0000 I have an issue with the target-uri document being proposed as the WG document for the target-uri deliverable. This was not the consensus in SF per my recollection (which may be biased) nor per the SIP WG minutes: http://www.ietf.org/proceedings/09mar/minutes/sip.html Which state: "Issue: Progress 4244bis, target-uri draft, or both? In the absence of a clear consensus, the chairs proposed that both documents proceed and we'll hope that further discussion gives us a consensus." =20 Now, I realize that there are now new chairs, but I don't think that should change the WG consensus from the SIP WG session.=20 I also think that many of the folks involved in the discussion had not considered (or were not aware) that the 4244bis document includes the normative text from target-uri - i.e., the solution in 4244bis was carefully integrated into base History-Info functionality and is identical to that in the target-uri document with the exception of the naming of the tag. Also an important consideration is that in the end, the target-uri document would need a lot more text to address security and privacy considerations and in the end would duplicate a lot of what's in 4244. =20 It was my understanding from the minutes that the discussion was to continue as to whether we would merge the two documents or agree one or the other as a WG deliverable.=20 Regards, Mary --btw listening to the audio is quite help and amusing... -----Original Message----- From: sip-bounces@ietf.org [mailto:sip-bounces@ietf.org] On Behalf Of Adam Roach Sent: Thursday, April 16, 2009 1:40 PM To: SIP WG Subject: [Sip] SIPCORE -- If you're not subscribed, you're missing stuff This message is for those of you who haven't subscribed to SIPCORE yet.=20 We're doing the heavy lifting of spinning stuff up right now, and you'll probably want to pay attention (both so you understand what's going on, and also to make sure the new chairs don't flub something up in the transition). Because they are of particular import, I'm going to point out the following two messages on the SIP list: http://www.ietf.org/mail-archive/web/sipcore/current/msg00004.html ...and... http://www.ietf.org/mail-archive/web/sipcore/current/msg00005.html If you didn't get your own copy of these messages, please double-check that you're subscribed to the SIPCORE mailing list: https://www.ietf.org/mailman/listinfo/sipcore /a _______________________________________________ Sip mailing list https://www.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use sip-implementors@cs.columbia.edu for questions on current sip Use sipping@ietf.org for new developments on the application of sip From dean.willis@softarmor.com Thu Apr 16 12:34:38 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CC6493A6F1B for ; Thu, 16 Apr 2009 12:34:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.555 X-Spam-Level: X-Spam-Status: No, score=-2.555 tagged_above=-999 required=5 tests=[AWL=0.044, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QYKad3wTOMpp for ; Thu, 16 Apr 2009 12:34:38 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id EE3823A6F19 for ; Thu, 16 Apr 2009 12:34:37 -0700 (PDT) Received: from [192.168.2.104] (cpe-72-181-150-177.tx.res.rr.com [72.181.150.177] (may be forged)) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id n3GJZnaN003557 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 16 Apr 2009 14:35:50 -0500 Message-Id: <905DC54D-B244-49C1-928A-1E25668D8C5B@softarmor.com> From: Dean Willis To: Mary Barnes In-Reply-To: <1ECE0EB50388174790F9694F77522CCF1D7A2BCA@zrc2hxm0.corp.nortel.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Thu, 16 Apr 2009 14:35:43 -0500 References: <49E77B71.5020608@nostrum.com> <1ECE0EB50388174790F9694F77522CCF1D7A2BCA@zrc2hxm0.corp.nortel.com> X-Mailer: Apple Mail (2.930.3) Cc: sipcore@ietf.org Subject: Re: [sipcore] [Sip] SIPCORE -- If you're not subscribed, you're missing stuff X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Apr 2009 19:34:38 -0000 On Apr 16, 2009, at 2:27 PM, Mary Barnes wrote: > I have an issue with the target-uri document being proposed as the WG > document for the target-uri deliverable. This was not the consensus in > SF per my recollection (which may be biased) nor per the SIP WG > minutes: > http://www.ietf.org/proceedings/09mar/minutes/sip.html > > Which state: > "Issue: Progress 4244bis, target-uri draft, or both? > In the absence of a clear consensus, the chairs proposed that both > documents proceed and we'll hope that further discussion gives us a > consensus." > > Now, I realize that there are now new chairs, but I don't think that > should change the WG consensus from the SIP WG session. However, the minutes from IETF 73 read: Topic: URI and Parameter Delivery Led by Jonaathan Rosenberg Slides presented http://tools.ietf.org/id/draft-rosenberg-sip-target-uri-delivery-00.txt ... Poll: Shall WG adopt this draft towards our charter deliverable on the topic? Chairs reported a strong consensus to do so. So which WG consensus of which SIP WG session do you not want to change? > > It was my understanding from the minutes that the discussion was to > continue as to whether we would merge the two documents or agree one > or > the other as a WG deliverable. > That's also consistent with my notes from SIP at 74. My best guess is that RFC 4244bis goes forward, and that target-uri- delivery turns into a "How to use H-I to meet the URI delivery use cases" document. -- Dean From mary.barnes@nortel.com Thu Apr 16 12:58:08 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 366903A6A3E for ; Thu, 16 Apr 2009 12:58:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.459 X-Spam-Level: X-Spam-Status: No, score=-6.459 tagged_above=-999 required=5 tests=[AWL=0.140, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vARoyy6tBPG4 for ; Thu, 16 Apr 2009 12:58:07 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id 1B8A43A67DF for ; Thu, 16 Apr 2009 12:58:06 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id n3GJxGt25748; Thu, 16 Apr 2009 19:59:16 GMT 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, 16 Apr 2009 15:02:05 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF1D7A2D15@zrc2hxm0.corp.nortel.com> In-Reply-To: <905DC54D-B244-49C1-928A-1E25668D8C5B@softarmor.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Target-uri document as SIPCORE WG document? (was RE: [sipcore] [Sip] SIPCORE -- If you're not subscribed, you're missing stuff Thread-Index: Acm+ypg9YJayjSXsQZ+dOAxKy2YoxQAArqkA References: <49E77B71.5020608@nostrum.com> <1ECE0EB50388174790F9694F77522CCF1D7A2BCA@zrc2hxm0.corp.nortel.com> <905DC54D-B244-49C1-928A-1E25668D8C5B@softarmor.com> From: "Mary Barnes" To: "Dean Willis" Cc: sipcore@ietf.org Subject: [sipcore] Target-uri document as SIPCORE WG document? (was RE: [Sip] SIPCORE -- If you're not subscribed, you're missing stuff X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Apr 2009 19:58:08 -0000 I'm suggesting to change the decision from IETF-73 and accept the more recent realization that including normative text in another document rather than 4244bis will be fraught with error and I can't see how that is a good idea from a development perspective - you can't just implement the target-uri document. =20 Now, I don't have a problem if folks can accept that the target-uri document might change such that the normative functionality is in 4244bis. And, this was consensus from IETF-73 per those minutes: "Issue: Normative behavior update for RFC 4244 Consensus noted to revise RFC 4244, and fix some other known problems with it at teh same time. MAry Barnes volunteered to edit the document." =20 So, there is a conflict in terms of accepting target-uri document as the only deliverable for that milestone in the IETF-73 meeting. Mary.=20 -----Original Message----- From: Dean Willis [mailto:dean.willis@softarmor.com]=20 Sent: Thursday, April 16, 2009 2:36 PM To: Barnes, Mary (RICH2:AR00) Cc: sipcore@ietf.org Subject: Re: [sipcore] [Sip] SIPCORE -- If you're not subscribed, you're missing stuff On Apr 16, 2009, at 2:27 PM, Mary Barnes wrote: > I have an issue with the target-uri document being proposed as the WG=20 > document for the target-uri deliverable. This was not the consensus in > SF per my recollection (which may be biased) nor per the SIP WG > minutes: > http://www.ietf.org/proceedings/09mar/minutes/sip.html > > Which state: > "Issue: Progress 4244bis, target-uri draft, or both? > In the absence of a clear consensus, the chairs proposed that both=20 > documents proceed and we'll hope that further discussion gives us a=20 > consensus." > > Now, I realize that there are now new chairs, but I don't think that=20 > should change the WG consensus from the SIP WG session. However, the minutes from IETF 73 read: Topic: URI and Parameter Delivery Led by Jonaathan Rosenberg Slides presented http://tools.ietf.org/id/draft-rosenberg-sip-target-uri-delivery-00.txt ... Poll: Shall WG adopt this draft towards our charter deliverable on the topic? Chairs reported a strong consensus to do so. So which WG consensus of which SIP WG session do you not want to change? > > It was my understanding from the minutes that the discussion was to=20 > continue as to whether we would merge the two documents or agree one=20 > or the other as a WG deliverable. > That's also consistent with my notes from SIP at 74. My best guess is that RFC 4244bis goes forward, and that target-uri- delivery turns into a "How to use H-I to meet the URI delivery use cases" document. -- Dean From ietf.hanserik@gmail.com Thu Apr 16 14:17:29 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6DA623A69CE for ; Thu, 16 Apr 2009 14:17:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.523 X-Spam-Level: X-Spam-Status: No, score=-2.523 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QETFPUPM7EZD for ; Thu, 16 Apr 2009 14:17:28 -0700 (PDT) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.25]) by core3.amsl.com (Postfix) with ESMTP id ED7F83A67AE for ; Thu, 16 Apr 2009 14:17:27 -0700 (PDT) Received: by ey-out-2122.google.com with SMTP id 4so131739eyf.31 for ; Thu, 16 Apr 2009 14:18:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=vCAiFVkP0AOwWUBDuAvzLzFd7Pi9vRbmQhUyT7D92eg=; b=kl1g+PPC1VtmjHOI0raEDqgqUhX8zBjdVKBBaFtPMOX7op9GTatWJ0T/rX09R+Tkus YfN7lCoJzD5+BqNg9dr7xlUFqkoGsZV/3WUuR1seLEryZVaNFPakOrB4FQu52KLBawdc xE1U+EJ031IByokV9v6IkytZJbNGCF4hsBm1Q= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=ag6BzZgIyuOP9t73WwMltKJgXhLF5JwamCrbWDjA41c/0BRzU1aWf2z9j77zsm4t3i 5mMHJNmh5VwPOomlkRWO5A4tDTVFpObX6kGeCjLk5hxwN8S52PysXlcBLESM+TWc293K bwLr+PuX7khbuMYh3jY9MawyrpIpVRKTCDeFs= MIME-Version: 1.0 Received: by 10.216.9.81 with SMTP id 59mr349562wes.181.1239916720067; Thu, 16 Apr 2009 14:18:40 -0700 (PDT) In-Reply-To: <905DC54D-B244-49C1-928A-1E25668D8C5B@softarmor.com> References: <49E77B71.5020608@nostrum.com> <1ECE0EB50388174790F9694F77522CCF1D7A2BCA@zrc2hxm0.corp.nortel.com> <905DC54D-B244-49C1-928A-1E25668D8C5B@softarmor.com> Date: Thu, 16 Apr 2009 23:18:40 +0200 Message-ID: <9ae56b1e0904161418p7753fb9egd9134232f7b66132@mail.gmail.com> From: Hans Erik van Elburg To: Dean Willis Content-Type: multipart/alternative; boundary=0016364c7bc3a695a90467b29b7b Cc: sipcore@ietf.org Subject: Re: [sipcore] [Sip] SIPCORE -- If you're not subscribed, you're missing stuff X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Apr 2009 21:17:29 -0000 --0016364c7bc3a695a90467b29b7b Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi Mary, I believe that in the absence of consensus as the minutes correctly state, the the target-uri document should remain the WG document for the target-uri deliverable. 4424bis has another purpose, namely to fix the 4424. If at a certain moment in time it turns out that 4424bis is the appropriate document to contain normative text for target uri delivery then we can always decide to do so. At this stage it is to early to take that decision, given the confused state of the target-uri discussion. /Hans Erik van Elburg On Thu, Apr 16, 2009 at 9:35 PM, Dean Willis wrote: > > On Apr 16, 2009, at 2:27 PM, Mary Barnes wrote: > > I have an issue with the target-uri document being proposed as the WG >> document for the target-uri deliverable. This was not the consensus in >> SF per my recollection (which may be biased) nor per the SIP WG minutes: >> http://www.ietf.org/proceedings/09mar/minutes/sip.html >> >> Which state: >> "Issue: Progress 4244bis, target-uri draft, or both? >> In the absence of a clear consensus, the chairs proposed that both >> documents proceed and we'll hope that further discussion gives us a >> consensus." >> >> Now, I realize that there are now new chairs, but I don't think that >> should change the WG consensus from the SIP WG session. >> > > However, the minutes from IETF 73 read: > > Topic: URI and Parameter Delivery > Led by Jonaathan Rosenberg > Slides presented > http://tools.ietf.org/id/draft-rosenberg-sip-target-uri-delivery-00.txt > > ... > > Poll: Shall WG adopt this draft towards our charter deliverable on the > topic? Chairs reported a strong consensus to do so. > So which WG consensus of which SIP WG session do you not want to change? > > > > >> It was my understanding from the minutes that the discussion was to >> continue as to whether we would merge the two documents or agree one or >> the other as a WG deliverable. >> >> > > That's also consistent with my notes from SIP at 74. > > My best guess is that RFC 4244bis goes forward, and that > target-uri-delivery turns into a "How to use H-I to meet the URI delivery > use cases" document. > > -- > Dean > > > > > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > --0016364c7bc3a695a90467b29b7b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Mary,

I believe that in the absence of consensus as the minutes c= orrectly state, the the target-uri document should remain the WG document = for the target-uri deliverable.

4424bis has another purpose, namely = to fix the 4424. If at a certain moment in time it turns out that 4424bis i= s the appropriate document to contain normative text for target uri deliver= y then we can always decide to do so. At this stage it is to early to take = that decision, given the confused state of the target-uri discussion.

/Hans Erik van Elburg


On Thu, Apr 16, 2009 at 9:35 PM, Dean Wi= llis <dea= n.willis@softarmor.com> wrote:

On Apr 16, 2009, at 2:27 PM, Mary Barnes wrote:

I have an issue with the target-uri document being proposed as the WG
document for the target-uri deliverable. This was not the consensus in
SF per my recollection (which may be biased) nor per the SIP WG minutes: http://www.ietf.org/proceedings/09mar/minutes/sip.html

Which state:
"Issue: Progress 4244bis, target-uri draft, or both?
In the absence of a clear consensus, the chairs proposed that both
documents proceed and we'll hope that further discussion gives us a
consensus."

Now, I realize that there are now new chairs, but I don't think that should change the WG consensus from the SIP WG session.

However, the minutes from IETF 73 read:

Topic: URI and Parameter Delivery
Led by Jonaathan Rosenberg
Slides presented
http://tools.ietf.org/id/draft-rosenberg-sip-tar= get-uri-delivery-00.txt

...

Poll: Shall WG adopt this draft towards our charter deliverable on the
topic? Chairs reported a strong consensus to do so.
So which WG consensus of which SIP WG session do you not want to change?




It was my understanding from the minutes that the discussion was to
continue as to whether we would merge the two documents or agree one or
the other as a WG deliverable.



That's also consistent with my notes from SIP at 74.

My best guess is that RFC 4244bis goes forward, and that target-uri-deliver= y turns into a "How to use H-I to meet the URI delivery use cases"= ; document.

--
Dean





_______________________________________________
sipcore mailing list
sipcore@ietf.org<= br> https://www.ietf.org/mailman/listinfo/sipcore

--0016364c7bc3a695a90467b29b7b-- From ietf.hanserik@gmail.com Thu Apr 16 14:20:32 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 66EE93A6979 for ; Thu, 16 Apr 2009 14:20:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.788 X-Spam-Level: X-Spam-Status: No, score=-1.788 tagged_above=-999 required=5 tests=[AWL=0.810, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QNrTT9GdlUPt for ; Thu, 16 Apr 2009 14:20:31 -0700 (PDT) Received: from mail-ew0-f165.google.com (mail-ew0-f165.google.com [209.85.219.165]) by core3.amsl.com (Postfix) with ESMTP id 980FA3A67AE for ; Thu, 16 Apr 2009 14:20:30 -0700 (PDT) Received: by ewy9 with SMTP id 9so642788ewy.37 for ; Thu, 16 Apr 2009 14:21:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=FuvBvn4EAiFZj+w/O8plN9PUM1AxRdFDMh+rOI3zBl4=; b=OcUTlHwS2BuhUYZ+qI73eD6LBS+4dLbx+AFPbI87PemzzrX1cQ1eUOO1SGG+1l20W9 Rq+uf6LKUguckumt9hI6yzbDF41qO8FoujxSsqxjlaB1OHD5jIanJwCmClI9oCEPQ91j T/6oFc1iHOaXtHDO2VypoiQOzI6sO2w1JTrMU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=ZQb+MYA9qMFJ2L+t4pKINN89FyAB9hc8kz0SJHXZVyIiFcMFWWahob3BB5B0B9NMX5 JUYMKlY66+MFvTFzTJAjzzdDG0NGW7Qs8yYnV47Ahe2uiuW4RoLDwTW6WGAF44BI9G0X WEuaHwlTieXVWhTGRh45awDGYUjKVKyt4uLMg= MIME-Version: 1.0 Received: by 10.216.21.76 with SMTP id q54mr348816weq.153.1239916902608; Thu, 16 Apr 2009 14:21:42 -0700 (PDT) In-Reply-To: <1ECE0EB50388174790F9694F77522CCF1D7A2D15@zrc2hxm0.corp.nortel.com> References: <49E77B71.5020608@nostrum.com> <1ECE0EB50388174790F9694F77522CCF1D7A2BCA@zrc2hxm0.corp.nortel.com> <905DC54D-B244-49C1-928A-1E25668D8C5B@softarmor.com> <1ECE0EB50388174790F9694F77522CCF1D7A2D15@zrc2hxm0.corp.nortel.com> Date: Thu, 16 Apr 2009 23:21:42 +0200 Message-ID: <9ae56b1e0904161421n6463dfd6ud0b99f1ad05b1963@mail.gmail.com> From: Hans Erik van Elburg To: Mary Barnes Content-Type: multipart/alternative; boundary=0016364d24d387eefa0467b2a690 Cc: sipcore@ietf.org Subject: Re: [sipcore] Target-uri document as SIPCORE WG document? (was RE: [Sip] SIPCORE -- If you're not subscribed, you're missing stuff X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Apr 2009 21:20:32 -0000 --0016364d24d387eefa0467b2a690 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi Mary, I believe that in the absence of consensus as the minutes correctly state, the the target-uri document should remain the WG document for the target-uri deliverable. 4424bis has another purpose, namely to fix the 4424. If at a certain moment in time it turns out that 4424bis is the appropriate document to contain normative text for target uri delivery then we can always decide to do so. At this stage it is to early to take that decision, given the confused state of the target-uri discussion. /Hans Erik van Elburg On Thu, Apr 16, 2009 at 10:02 PM, Mary Barnes wrote: > I'm suggesting to change the decision from IETF-73 and accept the more > recent realization that including normative text in another document > rather than 4244bis will be fraught with error and I can't see how that > is a good idea from a development perspective - you can't just implement > the target-uri document. > > Now, I don't have a problem if folks can accept that the target-uri > document might change such that the normative functionality is in > 4244bis. And, this was consensus from IETF-73 per those minutes: > "Issue: Normative behavior update for RFC 4244 > > Consensus noted to revise RFC 4244, and fix some other known problems > with it at teh same time. MAry Barnes volunteered to edit the > document." > > So, there is a conflict in terms of accepting target-uri document as the > only deliverable for that milestone in the IETF-73 meeting. > > Mary. > > > -----Original Message----- > From: Dean Willis [mailto:dean.willis@softarmor.com] > Sent: Thursday, April 16, 2009 2:36 PM > To: Barnes, Mary (RICH2:AR00) > Cc: sipcore@ietf.org > Subject: Re: [sipcore] [Sip] SIPCORE -- If you're not subscribed, you're > missing stuff > > > On Apr 16, 2009, at 2:27 PM, Mary Barnes wrote: > > > I have an issue with the target-uri document being proposed as the WG > > document for the target-uri deliverable. This was not the consensus in > > > SF per my recollection (which may be biased) nor per the SIP WG > > minutes: > > http://www.ietf.org/proceedings/09mar/minutes/sip.html > > > > Which state: > > "Issue: Progress 4244bis, target-uri draft, or both? > > In the absence of a clear consensus, the chairs proposed that both > > documents proceed and we'll hope that further discussion gives us a > > consensus." > > > > Now, I realize that there are now new chairs, but I don't think that > > should change the WG consensus from the SIP WG session. > > However, the minutes from IETF 73 read: > > Topic: URI and Parameter Delivery > Led by Jonaathan Rosenberg > Slides presented > http://tools.ietf.org/id/draft-rosenberg-sip-target-uri-delivery-00.txt > > ... > > Poll: Shall WG adopt this draft towards our charter deliverable on the > topic? Chairs reported a strong consensus to do so. > So which WG consensus of which SIP WG session do you not want to change? > > > > > > > It was my understanding from the minutes that the discussion was to > > continue as to whether we would merge the two documents or agree one > > or the other as a WG deliverable. > > > > > That's also consistent with my notes from SIP at 74. > > My best guess is that RFC 4244bis goes forward, and that target-uri- > delivery turns into a "How to use H-I to meet the URI delivery use > cases" document. > > -- > Dean > > > > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > --0016364d24d387eefa0467b2a690 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Mary,

I believe that in the absence of consensus as the minutes correctly state, the the target-uri document should remain the WG document for the target-uri deliverable.

4424bis has another purpose, namely to fix the 4424. If at a certain moment in time it turns out that 4424bis is the appropriate document to contain normative text for target uri delivery then we can always decide to do so. At this stage it is to early to take that decision, given the confused state of the target-uri discussion.

/Hans Erik van Elb= urg


On Thu, Apr 16, 2009 at 10:02 PM, Mary B= arnes <mary.= barnes@nortel.com> wrote:
I'm suggesting to change the decision from IETF-73 and accept the more<= br> recent realization that including normative text in another document
rather than 4244bis will be fraught with error and I can't see how that=
is a good idea from a development perspective - you can't just implemen= t
the target-uri document.

Now, I don't have a problem if folks can accept that the target-uri
document might change such that the normative functionality is in
4244bis. =A0 And, this was consensus from IETF-73 per those minutes:
"Issue: Normative behavior update for RFC 4244

Consensus noted to revise RFC 4244, and fix some other known problems
with it at teh same time. MAry Barnes volunteered to edit the
document."

So, there is a conflict in terms of accepting target-uri document as the only deliverable for that milestone in the IETF-73 meeting.

Mary.


-----Original Message-----
From: Dean Willis [mailto:dean= .willis@softarmor.com]
Sent: Thursday, April 16, 2009 2:36 PM
To: Barnes, Mary (RICH2:AR00)
Cc: sipcore@ietf.org
Subject: Re: [sipcore] [Sip] SIPCORE -- If you're not subscribed, you&#= 39;re
missing stuff


On Apr 16, 2009, at 2:27 PM, Mary Barnes wrote:

> I have an issue with the target-uri document being proposed as the WG<= br> > document for the target-uri deliverable. This was not the consensus in=

> SF per my recollection (which may be biased) nor per the SIP WG
> minutes:
> http://www.ietf.org/proceedings/09mar/minutes/sip.html >
> Which state:
> "Issue: Progress 4244bis, target-uri draft, or both?
> In the absence of a clear consensus, the chairs proposed that both
> documents proceed and we'll hope that further discussion gives us = a
> consensus."
>
> Now, I realize that there are now new chairs, but I don't think th= at
> should change the WG consensus from the SIP WG session.

However, the minutes from IETF 73 read:

Topic: URI and Parameter Delivery
Led by Jonaathan Rosenberg
Slides presented
http://tools.ietf.org/id/draft-rosenberg-sip-tar= get-uri-delivery-00.txt

...

Poll: Shall WG adopt this draft towards our charter deliverable on the
topic? Chairs reported a strong consensus to do so.
So which WG consensus of which SIP WG session do you not want to change?


>
> It was my understanding from the minutes that the discussion was to > continue as to whether we would merge the two documents or agree one > or the other as a WG deliverable.
>


That's also consistent with my notes from SIP at 74.

My best guess is that RFC 4244bis goes forward, and that target-uri-
delivery turns into a "How to use H-I to meet the URI delivery use
cases" document.

--
Dean




_______________________________________________
sipcore mailing list
sipcore@ietf.org
https://www.ietf.org/mailman/listinfo/sipcore

--0016364d24d387eefa0467b2a690-- From mary.barnes@nortel.com Thu Apr 16 14:31:47 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F1CC03A6F9C for ; Thu, 16 Apr 2009 14:31:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.46 X-Spam-Level: X-Spam-Status: No, score=-6.46 tagged_above=-999 required=5 tests=[AWL=0.138, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RgkvJLD6GEMT for ; Thu, 16 Apr 2009 14:31:40 -0700 (PDT) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id 50E053A6F8A for ; Thu, 16 Apr 2009 14:31:31 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id n3GLVxw00732; Thu, 16 Apr 2009 21:31:59 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C9BEDA.C99D0CD9" Date: Thu, 16 Apr 2009 16:34:57 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF1D7F9E6D@zrc2hxm0.corp.nortel.com> In-Reply-To: <9ae56b1e0904161421n6463dfd6ud0b99f1ad05b1963@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] Target-uri document as SIPCORE WG document? (was RE: [Sip] SIPCORE -- If you're not subscribed, you're missing stuff Thread-Index: Acm+2VlZABnKJIMzQmy6h7q6thF4/gAAZt8g References: <49E77B71.5020608@nostrum.com> <1ECE0EB50388174790F9694F77522CCF1D7A2BCA@zrc2hxm0.corp.nortel.com> <905DC54D-B244-49C1-928A-1E25668D8C5B@softarmor.com> <1ECE0EB50388174790F9694F77522CCF1D7A2D15@zrc2hxm0.corp.nortel.com> <9ae56b1e0904161421n6463dfd6ud0b99f1ad05b1963@mail.gmail.com> From: "Mary Barnes" To: "Hans Erik van Elburg" Cc: sipcore@ietf.org Subject: Re: [sipcore] Target-uri document as SIPCORE WG document? (was RE: [Sip] SIPCORE -- If you're not subscribed, you're missing stuff X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Apr 2009 21:31:48 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9BEDA.C99D0CD9 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable No - the discussion for 4244(bis) (extracted below) was entirely in the context of the discussion for the target-uri document. You can go back and listen to the audio to verify that. And, I've stated long before IETF-73 that it would be fairly straightforward to update 4244 to accomodate the target-uri requirements and while we were doing that, there were a few other fixes we could do.=20 =20 Mary.=20 ________________________________ From: Hans Erik van Elburg [mailto:ietf.hanserik@gmail.com]=20 Sent: Thursday, April 16, 2009 4:22 PM To: Barnes, Mary (RICH2:AR00) Cc: Dean Willis; sipcore@ietf.org Subject: Re: [sipcore] Target-uri document as SIPCORE WG document? (was RE: [Sip] SIPCORE -- If you're not subscribed, you're missing stuff Hi Mary, I believe that in the absence of consensus as the minutes correctly state, the the target-uri document should remain the WG document for the target-uri deliverable. 4424bis has another purpose, namely to fix the 4424. If at a certain moment in time it turns out that 4424bis is the appropriate document to contain normative text for target uri delivery then we can always decide to do so. At this stage it is to early to take that decision, given the confused state of the target-uri discussion. /Hans Erik van Elburg On Thu, Apr 16, 2009 at 10:02 PM, Mary Barnes wrote: I'm suggesting to change the decision from IETF-73 and accept the more recent realization that including normative text in another document rather than 4244bis will be fraught with error and I can't see how that is a good idea from a development perspective - you can't just implement the target-uri document. =09 Now, I don't have a problem if folks can accept that the target-uri document might change such that the normative functionality is in 4244bis. And, this was consensus from IETF-73 per those minutes: "Issue: Normative behavior update for RFC 4244 =09 Consensus noted to revise RFC 4244, and fix some other known problems with it at teh same time. MAry Barnes volunteered to edit the document." =09 So, there is a conflict in terms of accepting target-uri document as the only deliverable for that milestone in the IETF-73 meeting. =09 Mary. =09 =09 -----Original Message----- From: Dean Willis [mailto:dean.willis@softarmor.com] Sent: Thursday, April 16, 2009 2:36 PM To: Barnes, Mary (RICH2:AR00) Cc: sipcore@ietf.org Subject: Re: [sipcore] [Sip] SIPCORE -- If you're not subscribed, you're missing stuff =09 =09 On Apr 16, 2009, at 2:27 PM, Mary Barnes wrote: =09 > I have an issue with the target-uri document being proposed as the WG > document for the target-uri deliverable. This was not the consensus in =09 > SF per my recollection (which may be biased) nor per the SIP WG > minutes: > http://www.ietf.org/proceedings/09mar/minutes/sip.html > > Which state: > "Issue: Progress 4244bis, target-uri draft, or both? > In the absence of a clear consensus, the chairs proposed that both > documents proceed and we'll hope that further discussion gives us a > consensus." > > Now, I realize that there are now new chairs, but I don't think that > should change the WG consensus from the SIP WG session. =09 However, the minutes from IETF 73 read: =09 Topic: URI and Parameter Delivery Led by Jonaathan Rosenberg Slides presented =09 http://tools.ietf.org/id/draft-rosenberg-sip-target-uri-delivery-00.txt =09 ... =09 Poll: Shall WG adopt this draft towards our charter deliverable on the topic? Chairs reported a strong consensus to do so. So which WG consensus of which SIP WG session do you not want to change? =09 =09 =09 > > It was my understanding from the minutes that the discussion was to > continue as to whether we would merge the two documents or agree one > or the other as a WG deliverable. > =09 =09 That's also consistent with my notes from SIP at 74. =09 My best guess is that RFC 4244bis goes forward, and that target-uri- delivery turns into a "How to use H-I to meet the URI delivery use cases" document. =09 -- Dean =09 =09 =09 =09 _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore =09 ------_=_NextPart_001_01C9BEDA.C99D0CD9 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
No -=20 the discussion for 4244(bis) (extracted below) was entirely in the = context of=20 the discussion for the target-uri document. You can go back and listen = to the=20 audio to verify that.  And, I've stated long before IETF-73 that it = would=20 be fairly straightforward to update 4244 to accomodate the target-uri=20 requirements and while we were doing that, there were a few other fixes = we could=20 do.
 
Mary.=20

From: Hans Erik van Elburg=20 [mailto:ietf.hanserik@gmail.com]
Sent: Thursday, April 16, = 2009 4:22=20 PM
To: Barnes, Mary (RICH2:AR00)
Cc: Dean Willis;=20 sipcore@ietf.org
Subject: Re: [sipcore] Target-uri document as = SIPCORE=20 WG document? (was RE: [Sip] SIPCORE -- If you're not subscribed, you're = missing=20 stuff

Hi Mary,

I believe that in the absence of consensus as = the=20 minutes correctly state, the the target-uri document should remain the = WG=20 document for the target-uri deliverable.

4424bis has another = purpose,=20 namely to fix the 4424. If at a certain moment in time it turns out that = 4424bis=20 is the appropriate document to contain normative text for target uri = delivery=20 then we can always decide to do so. At this stage it is to early to take = that=20 decision, given the confused state of the target-uri discussion.
/Hans Erik van Elburg


On Thu, Apr 16, 2009 at 10:02 PM, Mary Barnes = <mary.barnes@nortel.com>=20 wrote:
I'm=20 suggesting to change the decision from IETF-73 and accept the = more
recent=20 realization that including normative text in another = document
rather than=20 4244bis will be fraught with error and I can't see how that
is a = good idea=20 from a development perspective - you can't just implement
the = target-uri=20 document.

Now, I don't have a problem if folks can accept that = the=20 target-uri
document might change such that the normative = functionality is=20 in
4244bis.   And, this was consensus from IETF-73 per those=20 minutes:
"Issue: Normative behavior update for RFC = 4244

Consensus=20 noted to revise RFC 4244, and fix some other known problems
with it = at teh=20 same time. MAry Barnes volunteered to edit = the
document."

So, there=20 is a conflict in terms of accepting target-uri document as the
only = deliverable for that milestone in the IETF-73=20 meeting.

Mary.


-----Original Message-----
From: = Dean=20 Willis [mailto:dean.willis@softarmor.com]<= BR>Sent:=20 Thursday, April 16, 2009 2:36 PM
To: Barnes, Mary = (RICH2:AR00)
Cc: sipcore@ietf.org
Subject: Re: = [sipcore]=20 [Sip] SIPCORE -- If you're not subscribed, you're
missing=20 stuff


On Apr 16, 2009, at 2:27 PM, Mary Barnes = wrote:

> I=20 have an issue with the target-uri document being proposed as the = WG
>=20 document for the target-uri deliverable. This was not the consensus=20 in

> SF per my recollection (which may be biased) nor per = the SIP=20 WG
> minutes:
> http://www.ietf.org/proceedings/09mar/minutes/sip.html
>
>=20 Which state:
> "Issue: Progress 4244bis, target-uri draft, or=20 both?
> In the absence of a clear consensus, the chairs proposed = that=20 both
> documents proceed and we'll hope that further discussion = gives us=20 a
> consensus."
>
> Now, I realize that there are = now new=20 chairs, but I don't think that
> should change the WG consensus = from the=20 SIP WG session.

However, the minutes from IETF 73 = read:

Topic:=20 URI and Parameter Delivery
Led by Jonaathan Rosenberg
Slides=20 presented
http://tools.ietf.org/id/draft-rosenberg-sip-target-uri-d= elivery-00.txt

...

Poll:=20 Shall WG adopt this draft towards our charter deliverable on = the
topic?=20 Chairs reported a strong consensus to do so.
So which WG consensus = of which=20 SIP WG session do you not want to change?



>
> = It was=20 my understanding from the minutes that the discussion was to
> = continue=20 as to whether we would merge the two documents or agree one
> or = the=20 other as a WG deliverable.
>


That's also consistent = with my=20 notes from SIP at 74.

My best guess is that RFC 4244bis goes = forward,=20 and that target-uri-
delivery turns into a "How to use H-I to meet = the URI=20 delivery use
cases"=20 = document.

--
Dean




__________________________= _____________________
sipcore=20 mailing list
sipcore@ietf.org
https://www.ietf.org/mailman/listinfo/sipcore

------_=_NextPart_001_01C9BEDA.C99D0CD9-- From aallen@rim.com Thu Apr 16 14:48:37 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9B5023A6979 for ; Thu, 16 Apr 2009 14:48:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.547 X-Spam-Level: X-Spam-Status: No, score=-5.547 tagged_above=-999 required=5 tests=[AWL=0.551, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BAD_LINEBREAK=0.5, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p0-gnbdp+dW3 for ; Thu, 16 Apr 2009 14:48:36 -0700 (PDT) Received: from mhs03ykf.rim.net (mhs03ykf.rim.net [216.9.243.80]) by core3.amsl.com (Postfix) with ESMTP id D493E3A67EC for ; Thu, 16 Apr 2009 14:48:35 -0700 (PDT) Received: from mhs03ykf.rim.net (unknown [127.0.0.1]) by mhs03ykf.rim.net (Symantec Brightmail Gateway) with ESMTP id 7FF9C58A46; Thu, 16 Apr 2009 17:49:47 -0400 (EDT) X-AuditID: 0a401fcb-a89b1bb000002ba2-2c-49e7a7fbfaf8 Received: from XCH20YKF.rim.net (unknown [10.102.100.35]) by mhs03ykf.rim.net (Symantec Mail Security) with ESMTP id 315DF58A3F; Thu, 16 Apr 2009 17:49:47 -0400 (EDT) Received: from XCH47YKF.rim.net ([10.64.31.217]) by XCH20YKF.rim.net with Microsoft SMTPSVC(5.0.2195.6713); Thu, 16 Apr 2009 17:49:47 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C9BEDD.42364CA4" Date: Thu, 16 Apr 2009 17:49:46 -0400 Message-ID: <61968779B8AC4C4BAB421D4C12F008C015FEA2B0@XCH47YKF.rim.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] Target-uri document as SIPCORE WG document? (was RE:[Sip] SIPCORE -- If you're not subscribed, you're missing stuff Thread-Index: Acm+2VlZABnKJIMzQmy6h7q6thF4/gAAZt8gAACTQZQ= From: "Andrew Allen" To: , X-OriginalArrivalTime: 16 Apr 2009 21:49:47.0090 (UTC) FILETIME=[42954B20:01C9BEDD] X-Tracking: ONC3m79J7f57zp0jFVtWxPxr7v2VYI3kBbb X-Brightmail-Tracker: AAAAAQ5kh/8= Cc: sipcore@ietf.org Subject: Re: [sipcore] Target-uri document as SIPCORE WG document? (was RE:[Sip] SIPCORE -- If you're not subscribed, you're missing stuff X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Apr 2009 21:48:37 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9BEDD.42364CA4 Content-Type: text/plain; charset="utf-8" content-transfer-encoding: base64 DQpNeSB1bmRlcnN0YW5kaW5nIHdhcyB0aGF0IHdlIHdvdWxkIG1vdmUgZm9yd2FyZCB3aXRo IGJvdGggZHJhZnRzIGFzIFdHIGl0ZW1zLg0KDQpNeSB1bmRlcnN0YW5kaW5nIHdhcyB0aGF0 IGluIER1YmxpbiBUYXJnZXQtdXJpIHdhcyBhZG9wdGVkIGFzIGEgU0lQIFdHIGl0ZW0uIEkg ZG9uJ3Qgd2FudCB0byBzZWUgNDI0NGJpcyBiZWNvbWUgYSBkZXBlbmRlbmN5IGZvciB0aGUg dGFyZ2V0LXVyaSB3b3JrIHdoaWNoIGlzIHVyZ2VudGx5IG5lZWRlZCB0byBzb2x2ZSBzb21l IEdSVVUgcmVsYXRlZCBpc3N1ZXMuDQoNCklmIDQyNDRiaXMgaXMgcmVhZHkgd2hlbiB0YXJn ZXQtdXJpIGlzIHRoZW4gd2UgY2FuIHRhbGsgYWJvdXQgcm9sbGluZyB0aGUgdHdvIGludG8g b25lIGJ1dCBJIGhhdmUgY29uY2VybnMgdGhhdCA0MjQ0YmlzIHdpbGwgdGFrZSBjb25zaWRl cmFibHkgbG9uZ2VyIHRoYW4gdGFyZ2V0LXVyaSBiYXNlZCBvbiB0aGUgZGlzY3Vzc2lvbiBp biBTYW4gRnJhbi4gDQoNClRhcmdldC11cmkgaGFzIGJlZW4gbmVlZGVkIHJlYWxseSBmb3Ig R1JVVSBmb3IgbW9yZSB0aGVuIDIgeWVhcnMgYW5kIGlzIGZhaXJseSBzdHJhaWdodGZvcndh cmQuIEkgZG9uJ3QgdGhpbmsgd2Ugc2hvdWxkIHJpc2sgZGVsYXlpbmcgdGhhdCB3b3JrIHdh aXRpbmcgZm9yIDQyNDRiaXMgd2hpY2ggc2VlbXMgdG8gY29udGFpbiBhIG51bWJlciBvZiBp c3N1ZXMgd2UgZG9uJ3QgaGF2ZSBjb25zZW5zdXMgb24geWV0Lg0KDQpUaGF0IHdhcyBteSB1 bmRlcnN0YW5kaW5nIG9mIHRoZSBhcHByb2FjaCB3ZSBkZXRlcm1pbmVkIGluIFNhbiBGcmFu Y2lzY28uDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCg0KRnJvbTog c2lwY29yZS1ib3VuY2VzQGlldGYub3JnIDxzaXBjb3JlLWJvdW5jZXNAaWV0Zi5vcmc+IA0K VG86IEhhbnMgRXJpayB2YW4gRWxidXJnIDxpZXRmLmhhbnNlcmlrQGdtYWlsLmNvbT4gDQpD Yzogc2lwY29yZUBpZXRmLm9yZyA8c2lwY29yZUBpZXRmLm9yZz4gDQpTZW50OiBUaHUgQXBy IDE2IDE3OjM0OjU3IDIwMDkNClN1YmplY3Q6IFJlOiBbc2lwY29yZV0gVGFyZ2V0LXVyaSBk b2N1bWVudCBhcyBTSVBDT1JFIFdHIGRvY3VtZW50PyAod2FzIFJFOltTaXBdIFNJUENPUkUg LS0gSWYgeW91J3JlIG5vdCBzdWJzY3JpYmVkLCB5b3UncmUgbWlzc2luZyBzdHVmZiANCg0K DQpObyAtIHRoZSBkaXNjdXNzaW9uIGZvciA0MjQ0KGJpcykgKGV4dHJhY3RlZCBiZWxvdykg d2FzIGVudGlyZWx5IGluIHRoZSBjb250ZXh0IG9mIHRoZSBkaXNjdXNzaW9uIGZvciB0aGUg dGFyZ2V0LXVyaSBkb2N1bWVudC4gWW91IGNhbiBnbyBiYWNrIGFuZCBsaXN0ZW4gdG8gdGhl IGF1ZGlvIHRvIHZlcmlmeSB0aGF0LiAgQW5kLCBJJ3ZlIHN0YXRlZCBsb25nIGJlZm9yZSBJ RVRGLTczIHRoYXQgaXQgd291bGQgYmUgZmFpcmx5IHN0cmFpZ2h0Zm9yd2FyZCB0byB1cGRh dGUgNDI0NCB0byBhY2NvbW9kYXRlIHRoZSB0YXJnZXQtdXJpIHJlcXVpcmVtZW50cyBhbmQg d2hpbGUgd2Ugd2VyZSBkb2luZyB0aGF0LCB0aGVyZSB3ZXJlIGEgZmV3IG90aGVyIGZpeGVz IHdlIGNvdWxkIGRvLiANCiANCk1hcnkuIA0KDQpfX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fXw0KDQpGcm9tOiBIYW5zIEVyaWsgdmFuIEVsYnVyZyBbbWFpbHRvOmlldGYuaGFu c2VyaWtAZ21haWwuY29tXSANClNlbnQ6IFRodXJzZGF5LCBBcHJpbCAxNiwgMjAwOSA0OjIy IFBNDQpUbzogQmFybmVzLCBNYXJ5IChSSUNIMjpBUjAwKQ0KQ2M6IERlYW4gV2lsbGlzOyBz aXBjb3JlQGlldGYub3JnDQpTdWJqZWN0OiBSZTogW3NpcGNvcmVdIFRhcmdldC11cmkgZG9j dW1lbnQgYXMgU0lQQ09SRSBXRyBkb2N1bWVudD8gKHdhcyBSRTogW1NpcF0gU0lQQ09SRSAt LSBJZiB5b3UncmUgbm90IHN1YnNjcmliZWQsIHlvdSdyZSBtaXNzaW5nIHN0dWZmDQoNCg0K SGkgTWFyeSwNCg0KSSBiZWxpZXZlIHRoYXQgaW4gdGhlIGFic2VuY2Ugb2YgY29uc2Vuc3Vz IGFzIHRoZSBtaW51dGVzIGNvcnJlY3RseSBzdGF0ZSwgdGhlIHRoZSB0YXJnZXQtdXJpIGRv Y3VtZW50IHNob3VsZCByZW1haW4gdGhlIFdHIGRvY3VtZW50IGZvciB0aGUgdGFyZ2V0LXVy aSBkZWxpdmVyYWJsZS4NCg0KNDQyNGJpcyBoYXMgYW5vdGhlciBwdXJwb3NlLCBuYW1lbHkg dG8gZml4IHRoZSA0NDI0LiBJZiBhdCBhIGNlcnRhaW4gbW9tZW50IGluIHRpbWUgaXQgdHVy bnMgb3V0IHRoYXQgNDQyNGJpcyBpcyB0aGUgYXBwcm9wcmlhdGUgZG9jdW1lbnQgdG8gY29u dGFpbiBub3JtYXRpdmUgdGV4dCBmb3IgdGFyZ2V0IHVyaSBkZWxpdmVyeSB0aGVuIHdlIGNh biBhbHdheXMgZGVjaWRlIHRvIGRvIHNvLiBBdCB0aGlzIHN0YWdlIGl0IGlzIHRvIGVhcmx5 IHRvIHRha2UgdGhhdCBkZWNpc2lvbiwgZ2l2ZW4gdGhlIGNvbmZ1c2VkIHN0YXRlIG9mIHRo ZSB0YXJnZXQtdXJpIGRpc2N1c3Npb24uDQoNCi9IYW5zIEVyaWsgdmFuIEVsYnVyZw0KDQoN Cg0KT24gVGh1LCBBcHIgMTYsIDIwMDkgYXQgMTA6MDIgUE0sIE1hcnkgQmFybmVzIDxtYXJ5 LmJhcm5lc0Bub3J0ZWwuY29tPiB3cm90ZToNCg0KDQoJSSdtIHN1Z2dlc3RpbmcgdG8gY2hh bmdlIHRoZSBkZWNpc2lvbiBmcm9tIElFVEYtNzMgYW5kIGFjY2VwdCB0aGUgbW9yZQ0KCXJl Y2VudCByZWFsaXphdGlvbiB0aGF0IGluY2x1ZGluZyBub3JtYXRpdmUgdGV4dCBpbiBhbm90 aGVyIGRvY3VtZW50DQoJcmF0aGVyIHRoYW4gNDI0NGJpcyB3aWxsIGJlIGZyYXVnaHQgd2l0 aCBlcnJvciBhbmQgSSBjYW4ndCBzZWUgaG93IHRoYXQNCglpcyBhIGdvb2QgaWRlYSBmcm9t IGEgZGV2ZWxvcG1lbnQgcGVyc3BlY3RpdmUgLSB5b3UgY2FuJ3QganVzdCBpbXBsZW1lbnQN Cgl0aGUgdGFyZ2V0LXVyaSBkb2N1bWVudC4NCgkNCglOb3csIEkgZG9uJ3QgaGF2ZSBhIHBy b2JsZW0gaWYgZm9sa3MgY2FuIGFjY2VwdCB0aGF0IHRoZSB0YXJnZXQtdXJpDQoJZG9jdW1l bnQgbWlnaHQgY2hhbmdlIHN1Y2ggdGhhdCB0aGUgbm9ybWF0aXZlIGZ1bmN0aW9uYWxpdHkg aXMgaW4NCgk0MjQ0YmlzLiAgIEFuZCwgdGhpcyB3YXMgY29uc2Vuc3VzIGZyb20gSUVURi03 MyBwZXIgdGhvc2UgbWludXRlczoNCgkiSXNzdWU6IE5vcm1hdGl2ZSBiZWhhdmlvciB1cGRh dGUgZm9yIFJGQyA0MjQ0DQoJDQoJQ29uc2Vuc3VzIG5vdGVkIHRvIHJldmlzZSBSRkMgNDI0 NCwgYW5kIGZpeCBzb21lIG90aGVyIGtub3duIHByb2JsZW1zDQoJd2l0aCBpdCBhdCB0ZWgg c2FtZSB0aW1lLiBNQXJ5IEJhcm5lcyB2b2x1bnRlZXJlZCB0byBlZGl0IHRoZQ0KCWRvY3Vt ZW50LiINCgkNCglTbywgdGhlcmUgaXMgYSBjb25mbGljdCBpbiB0ZXJtcyBvZiBhY2NlcHRp bmcgdGFyZ2V0LXVyaSBkb2N1bWVudCBhcyB0aGUNCglvbmx5IGRlbGl2ZXJhYmxlIGZvciB0 aGF0IG1pbGVzdG9uZSBpbiB0aGUgSUVURi03MyBtZWV0aW5nLg0KCQ0KCU1hcnkuDQoJDQoJ DQoJLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCglGcm9tOiBEZWFuIFdpbGxpcyBbbWFp bHRvOmRlYW4ud2lsbGlzQHNvZnRhcm1vci5jb21dDQoJU2VudDogVGh1cnNkYXksIEFwcmls IDE2LCAyMDA5IDI6MzYgUE0NCglUbzogQmFybmVzLCBNYXJ5IChSSUNIMjpBUjAwKQ0KCUNj OiBzaXBjb3JlQGlldGYub3JnDQoJU3ViamVjdDogUmU6IFtzaXBjb3JlXSBbU2lwXSBTSVBD T1JFIC0tIElmIHlvdSdyZSBub3Qgc3Vic2NyaWJlZCwgeW91J3JlDQoJbWlzc2luZyBzdHVm Zg0KCQ0KCQ0KCU9uIEFwciAxNiwgMjAwOSwgYXQgMjoyNyBQTSwgTWFyeSBCYXJuZXMgd3Jv dGU6DQoJDQoJPiBJIGhhdmUgYW4gaXNzdWUgd2l0aCB0aGUgdGFyZ2V0LXVyaSBkb2N1bWVu dCBiZWluZyBwcm9wb3NlZCBhcyB0aGUgV0cNCgk+IGRvY3VtZW50IGZvciB0aGUgdGFyZ2V0 LXVyaSBkZWxpdmVyYWJsZS4gVGhpcyB3YXMgbm90IHRoZSBjb25zZW5zdXMgaW4NCgkNCgk+ IFNGIHBlciBteSByZWNvbGxlY3Rpb24gKHdoaWNoIG1heSBiZSBiaWFzZWQpIG5vciBwZXIg dGhlIFNJUCBXRw0KCT4gbWludXRlczoNCgk+IGh0dHA6Ly93d3cuaWV0Zi5vcmcvcHJvY2Vl ZGluZ3MvMDltYXIvbWludXRlcy9zaXAuaHRtbA0KCT4NCgk+IFdoaWNoIHN0YXRlOg0KCT4g Iklzc3VlOiBQcm9ncmVzcyA0MjQ0YmlzLCB0YXJnZXQtdXJpIGRyYWZ0LCBvciBib3RoPw0K CT4gSW4gdGhlIGFic2VuY2Ugb2YgYSBjbGVhciBjb25zZW5zdXMsIHRoZSBjaGFpcnMgcHJv cG9zZWQgdGhhdCBib3RoDQoJPiBkb2N1bWVudHMgcHJvY2VlZCBhbmQgd2UnbGwgaG9wZSB0 aGF0IGZ1cnRoZXIgZGlzY3Vzc2lvbiBnaXZlcyB1cyBhDQoJPiBjb25zZW5zdXMuIg0KCT4N Cgk+IE5vdywgSSByZWFsaXplIHRoYXQgdGhlcmUgYXJlIG5vdyBuZXcgY2hhaXJzLCBidXQg SSBkb24ndCB0aGluayB0aGF0DQoJPiBzaG91bGQgY2hhbmdlIHRoZSBXRyBjb25zZW5zdXMg ZnJvbSB0aGUgU0lQIFdHIHNlc3Npb24uDQoJDQoJSG93ZXZlciwgdGhlIG1pbnV0ZXMgZnJv bSBJRVRGIDczIHJlYWQ6DQoJDQoJVG9waWM6IFVSSSBhbmQgUGFyYW1ldGVyIERlbGl2ZXJ5 DQoJTGVkIGJ5IEpvbmFhdGhhbiBSb3NlbmJlcmcNCglTbGlkZXMgcHJlc2VudGVkDQoJaHR0 cDovL3Rvb2xzLmlldGYub3JnL2lkL2RyYWZ0LXJvc2VuYmVyZy1zaXAtdGFyZ2V0LXVyaS1k ZWxpdmVyeS0wMC50eHQNCgkNCgkuLi4NCgkNCglQb2xsOiBTaGFsbCBXRyBhZG9wdCB0aGlz IGRyYWZ0IHRvd2FyZHMgb3VyIGNoYXJ0ZXIgZGVsaXZlcmFibGUgb24gdGhlDQoJdG9waWM/ IENoYWlycyByZXBvcnRlZCBhIHN0cm9uZyBjb25zZW5zdXMgdG8gZG8gc28uDQoJU28gd2hp Y2ggV0cgY29uc2Vuc3VzIG9mIHdoaWNoIFNJUCBXRyBzZXNzaW9uIGRvIHlvdSBub3Qgd2Fu dCB0byBjaGFuZ2U/DQoJDQoJDQoJDQoJPg0KCT4gSXQgd2FzIG15IHVuZGVyc3RhbmRpbmcg ZnJvbSB0aGUgbWludXRlcyB0aGF0IHRoZSBkaXNjdXNzaW9uIHdhcyB0bw0KCT4gY29udGlu dWUgYXMgdG8gd2hldGhlciB3ZSB3b3VsZCBtZXJnZSB0aGUgdHdvIGRvY3VtZW50cyBvciBh Z3JlZSBvbmUNCgk+IG9yIHRoZSBvdGhlciBhcyBhIFdHIGRlbGl2ZXJhYmxlLg0KCT4NCgkN CgkNCglUaGF0J3MgYWxzbyBjb25zaXN0ZW50IHdpdGggbXkgbm90ZXMgZnJvbSBTSVAgYXQg NzQuDQoJDQoJTXkgYmVzdCBndWVzcyBpcyB0aGF0IFJGQyA0MjQ0YmlzIGdvZXMgZm9yd2Fy ZCwgYW5kIHRoYXQgdGFyZ2V0LXVyaS0NCglkZWxpdmVyeSB0dXJucyBpbnRvIGEgIkhvdyB0 byB1c2UgSC1JIHRvIG1lZXQgdGhlIFVSSSBkZWxpdmVyeSB1c2UNCgljYXNlcyIgZG9jdW1l bnQuDQoJDQoJLS0NCglEZWFuDQoJDQoJDQoJDQoJDQoJX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NCglzaXBjb3JlIG1haWxpbmcgbGlzdA0KCXNp cGNvcmVAaWV0Zi5vcmcNCglodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L3NpcGNvcmUNCgkNCg0KDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KVGhpcyB0cmFuc21pc3Npb24g KGluY2x1ZGluZyBhbnkgYXR0YWNobWVudHMpIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBp bmZvcm1hdGlvbiwgcHJpdmlsZWdlZCBtYXRlcmlhbCAoaW5jbHVkaW5nIG1hdGVyaWFsIHBy b3RlY3RlZCBieSB0aGUgc29saWNpdG9yLWNsaWVudCBvciBvdGhlciBhcHBsaWNhYmxlIHBy aXZpbGVnZXMpLCBvciBjb25zdGl0dXRlIG5vbi1wdWJsaWMgaW5mb3JtYXRpb24uIEFueSB1 c2Ugb2YgdGhpcyBpbmZvcm1hdGlvbiBieSBhbnlvbmUgb3RoZXIgdGhhbiB0aGUgaW50ZW5k ZWQgcmVjaXBpZW50IGlzIHByb2hpYml0ZWQuIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMg dHJhbnNtaXNzaW9uIGluIGVycm9yLCBwbGVhc2UgaW1tZWRpYXRlbHkgcmVwbHkgdG8gdGhl IHNlbmRlciBhbmQgZGVsZXRlIHRoaXMgaW5mb3JtYXRpb24gZnJvbSB5b3VyIHN5c3RlbS4g VXNlLCBkaXNzZW1pbmF0aW9uLCBkaXN0cmlidXRpb24sIG9yIHJlcHJvZHVjdGlvbiBvZiB0 aGlzIHRyYW5zbWlzc2lvbiBieSB1bmludGVuZGVkIHJlY2lwaWVudHMgaXMgbm90IGF1dGhv cml6ZWQgYW5kIG1heSBiZSB1bmxhd2Z1bC4NCg== ------_=_NextPart_001_01C9BEDD.42364CA4 Content-Type: text/html; charset="utf-8" content-transfer-encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9u YWwvL0VOIj4NCjxIVE1MPjxIRUFEPg0KDQo8TUVUQSBjb250ZW50PSJNU0hUTUwgNi4wMC4y OTAwLjM0OTIiIG5hbWU9R0VORVJBVE9SPjwvSEVBRD4NCjxCT0RZPjxwPjxmb250IHNpemU9 MiBjb2xvcj1uYXZ5IGZhY2U9QXJpYWw+DQo8YnI+TXkgdW5kZXJzdGFuZGluZyB3YXMgdGhh dCB3ZSB3b3VsZCBtb3ZlIGZvcndhcmQgd2l0aCBib3RoIGRyYWZ0cyBhcyBXRyBpdGVtcy48 YnI+PGJyPk15IHVuZGVyc3RhbmRpbmcgd2FzIHRoYXQgaW4gRHVibGluIFRhcmdldC11cmkg d2FzIGFkb3B0ZWQgYXMgYSBTSVAgV0cgaXRlbS4gSSBkb24ndCB3YW50IHRvIHNlZSA0MjQ0 YmlzIGJlY29tZSBhIGRlcGVuZGVuY3kgZm9yIHRoZSB0YXJnZXQtdXJpIHdvcmsgd2hpY2gg aXMgdXJnZW50bHkgbmVlZGVkIHRvIHNvbHZlIHNvbWUgR1JVVSByZWxhdGVkIGlzc3Vlcy48 YnI+PGJyPklmIDQyNDRiaXMgaXMgcmVhZHkgd2hlbiB0YXJnZXQtdXJpIGlzIHRoZW4gd2Ug Y2FuIHRhbGsgYWJvdXQgcm9sbGluZyB0aGUgdHdvIGludG8gb25lIGJ1dCBJIGhhdmUgY29u Y2VybnMgdGhhdCA0MjQ0YmlzIHdpbGwgdGFrZSBjb25zaWRlcmFibHkgbG9uZ2VyIHRoYW4g dGFyZ2V0LXVyaSBiYXNlZCBvbiB0aGUgZGlzY3Vzc2lvbiBpbiBTYW4gRnJhbi4gPGJyPjxi cj5UYXJnZXQtdXJpIGhhcyBiZWVuIG5lZWRlZCByZWFsbHkgZm9yIEdSVVUgZm9yIG1vcmUg dGhlbiAyIHllYXJzIGFuZCBpcyBmYWlybHkgc3RyYWlnaHRmb3J3YXJkLiBJIGRvbid0IHRo aW5rIHdlIHNob3VsZCByaXNrIGRlbGF5aW5nIHRoYXQgd29yayB3YWl0aW5nIGZvciA0MjQ0 YmlzIHdoaWNoIHNlZW1zIHRvIGNvbnRhaW4gYSBudW1iZXIgb2YgaXNzdWVzIHdlIGRvbid0 IGhhdmUgY29uc2Vuc3VzIG9uIHlldC48YnI+PGJyPlRoYXQgd2FzIG15IHVuZGVyc3RhbmRp bmcgb2YgdGhlIGFwcHJvYWNoIHdlIGRldGVybWluZWQgaW4gU2FuIEZyYW5jaXNjby48YnI+ PC9mb250PjwvcD4NCjxwPjxociBzaXplPTIgd2lkdGg9IjEwMCUiIGFsaWduPWNlbnRlciB0 YWJpbmRleD0tMT4NCjxmb250IGZhY2U9VGFob21hIHNpemU9Mj4NCjxiPkZyb208L2I+OiBz aXBjb3JlLWJvdW5jZXNAaWV0Zi5vcmcgJmx0O3NpcGNvcmUtYm91bmNlc0BpZXRmLm9yZyZn dDsNPGJyPjxiPlRvPC9iPjogSGFucyBFcmlrIHZhbiBFbGJ1cmcgJmx0O2lldGYuaGFuc2Vy aWtAZ21haWwuY29tJmd0Ow08YnI+PGI+Q2M8L2I+OiBzaXBjb3JlQGlldGYub3JnICZsdDtz aXBjb3JlQGlldGYub3JnJmd0Ow08YnI+PGI+U2VudDwvYj46IFRodSBBcHIgMTYgMTc6MzQ6 NTcgMjAwOTxicj48Yj5TdWJqZWN0PC9iPjogUmU6IFtzaXBjb3JlXSBUYXJnZXQtdXJpIGRv Y3VtZW50IGFzIFNJUENPUkUgV0cgZG9jdW1lbnQ/ICh3YXMgUkU6W1NpcF0gU0lQQ09SRSAt LSBJZiB5b3UncmUgbm90IHN1YnNjcmliZWQsIHlvdSdyZSBtaXNzaW5nIHN0dWZmDTxicj48 L2ZvbnQ+PC9wPg0KDQo8RElWPjxGT05UIGZhY2U9QXJpYWwgY29sb3I9IzAwMDBmZiBzaXpl PTI+PFNQQU4gY2xhc3M9NjcxMTczMzIxLTE2MDQyMDA5Pk5vIC0gDQp0aGUgZGlzY3Vzc2lv biBmb3IgNDI0NChiaXMpIChleHRyYWN0ZWQgYmVsb3cpIHdhcyBlbnRpcmVseSBpbiB0aGUg Y29udGV4dCBvZiANCnRoZSBkaXNjdXNzaW9uIGZvciB0aGUgdGFyZ2V0LXVyaSBkb2N1bWVu dC4gWW91IGNhbiBnbyBiYWNrIGFuZCBsaXN0ZW4gdG8gdGhlIA0KYXVkaW8gdG8gdmVyaWZ5 IHRoYXQuJm5ic3A7IEFuZCwgSSd2ZSBzdGF0ZWQgbG9uZyBiZWZvcmUgSUVURi03MyB0aGF0 IGl0IHdvdWxkIA0KYmUgZmFpcmx5IHN0cmFpZ2h0Zm9yd2FyZCB0byB1cGRhdGUgNDI0NCB0 byBhY2NvbW9kYXRlIHRoZSB0YXJnZXQtdXJpIA0KcmVxdWlyZW1lbnRzIGFuZCB3aGlsZSB3 ZSB3ZXJlIGRvaW5nIHRoYXQsIHRoZXJlIHdlcmUgYSBmZXcgb3RoZXIgZml4ZXMgd2UgY291 bGQgDQpkby4gPC9TUEFOPjwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgZmFjZT1BcmlhbCBj b2xvcj0jMDAwMGZmIHNpemU9Mj48U1BBTiANCmNsYXNzPTY3MTE3MzMyMS0xNjA0MjAwOT48 L1NQQU4+PC9GT05UPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBmYWNlPUFyaWFsIGNvbG9y PSMwMDAwZmYgc2l6ZT0yPjxTUEFOIGNsYXNzPTY3MTE3MzMyMS0xNjA0MjAwOT5NYXJ5LiAN CjwvU1BBTj48L0ZPTlQ+PC9ESVY+PEJSPg0KPERJViBjbGFzcz1PdXRsb29rTWVzc2FnZUhl YWRlciBsYW5nPWVuLXVzIGRpcj1sdHIgYWxpZ249bGVmdD4NCjxIUiB0YWJJbmRleD0tMT4N CjxGT05UIGZhY2U9VGFob21hIHNpemU9Mj48Qj5Gcm9tOjwvQj4gSGFucyBFcmlrIHZhbiBF bGJ1cmcgDQpbbWFpbHRvOmlldGYuaGFuc2VyaWtAZ21haWwuY29tXSA8QlI+PEI+U2VudDo8 L0I+IFRodXJzZGF5LCBBcHJpbCAxNiwgMjAwOSA0OjIyIA0KUE08QlI+PEI+VG86PC9CPiBC YXJuZXMsIE1hcnkgKFJJQ0gyOkFSMDApPEJSPjxCPkNjOjwvQj4gRGVhbiBXaWxsaXM7IA0K c2lwY29yZUBpZXRmLm9yZzxCUj48Qj5TdWJqZWN0OjwvQj4gUmU6IFtzaXBjb3JlXSBUYXJn ZXQtdXJpIGRvY3VtZW50IGFzIFNJUENPUkUgDQpXRyBkb2N1bWVudD8gKHdhcyBSRTogW1Np cF0gU0lQQ09SRSAtLSBJZiB5b3UncmUgbm90IHN1YnNjcmliZWQsIHlvdSdyZSBtaXNzaW5n IA0Kc3R1ZmY8QlI+PC9GT05UPjxCUj48L0RJVj4NCjxESVY+PC9ESVY+SGkgTWFyeSw8QlI+ PEJSPkkgYmVsaWV2ZSB0aGF0IGluIHRoZSBhYnNlbmNlIG9mIGNvbnNlbnN1cyBhcyB0aGUg DQptaW51dGVzIGNvcnJlY3RseSBzdGF0ZSwgdGhlIHRoZSB0YXJnZXQtdXJpIGRvY3VtZW50 IHNob3VsZCByZW1haW4gdGhlIFdHIA0KZG9jdW1lbnQgZm9yIHRoZSB0YXJnZXQtdXJpIGRl bGl2ZXJhYmxlLjxCUj48QlI+NDQyNGJpcyBoYXMgYW5vdGhlciBwdXJwb3NlLCANCm5hbWVs eSB0byBmaXggdGhlIDQ0MjQuIElmIGF0IGEgY2VydGFpbiBtb21lbnQgaW4gdGltZSBpdCB0 dXJucyBvdXQgdGhhdCA0NDI0YmlzIA0KaXMgdGhlIGFwcHJvcHJpYXRlIGRvY3VtZW50IHRv IGNvbnRhaW4gbm9ybWF0aXZlIHRleHQgZm9yIHRhcmdldCB1cmkgZGVsaXZlcnkgDQp0aGVu IHdlIGNhbiBhbHdheXMgZGVjaWRlIHRvIGRvIHNvLiBBdCB0aGlzIHN0YWdlIGl0IGlzIHRv IGVhcmx5IHRvIHRha2UgdGhhdCANCmRlY2lzaW9uLCBnaXZlbiB0aGUgY29uZnVzZWQgc3Rh dGUgb2YgdGhlIHRhcmdldC11cmkgZGlzY3Vzc2lvbi48QlI+PEJSIA0KY2xlYXI9YWxsPi9I YW5zIEVyaWsgdmFuIEVsYnVyZzxCUj48QlI+PEJSPg0KPERJViBjbGFzcz1nbWFpbF9xdW90 ZT5PbiBUaHUsIEFwciAxNiwgMjAwOSBhdCAxMDowMiBQTSwgTWFyeSBCYXJuZXMgPFNQQU4g DQpkaXI9bHRyPiZsdDs8QSANCmhyZWY9Im1haWx0bzptYXJ5LmJhcm5lc0Bub3J0ZWwuY29t Ij5tYXJ5LmJhcm5lc0Bub3J0ZWwuY29tPC9BPiZndDs8L1NQQU4+IA0Kd3JvdGU6PEJSPg0K PEJMT0NLUVVPVEUgY2xhc3M9Z21haWxfcXVvdGUgDQpzdHlsZT0iUEFERElORy1MRUZUOiAx ZXg7IE1BUkdJTjogMHB0IDBwdCAwcHQgMC44ZXg7IEJPUkRFUi1MRUZUOiByZ2IoMjA0LDIw NCwyMDQpIDFweCBzb2xpZCI+SSdtIA0KICBzdWdnZXN0aW5nIHRvIGNoYW5nZSB0aGUgZGVj aXNpb24gZnJvbSBJRVRGLTczIGFuZCBhY2NlcHQgdGhlIG1vcmU8QlI+cmVjZW50IA0KICBy ZWFsaXphdGlvbiB0aGF0IGluY2x1ZGluZyBub3JtYXRpdmUgdGV4dCBpbiBhbm90aGVyIGRv Y3VtZW50PEJSPnJhdGhlciB0aGFuIA0KICA0MjQ0YmlzIHdpbGwgYmUgZnJhdWdodCB3aXRo IGVycm9yIGFuZCBJIGNhbid0IHNlZSBob3cgdGhhdDxCUj5pcyBhIGdvb2QgaWRlYSANCiAg ZnJvbSBhIGRldmVsb3BtZW50IHBlcnNwZWN0aXZlIC0geW91IGNhbid0IGp1c3QgaW1wbGVt ZW50PEJSPnRoZSB0YXJnZXQtdXJpIA0KICBkb2N1bWVudC48QlI+PEJSPk5vdywgSSBkb24n dCBoYXZlIGEgcHJvYmxlbSBpZiBmb2xrcyBjYW4gYWNjZXB0IHRoYXQgdGhlIA0KICB0YXJn ZXQtdXJpPEJSPmRvY3VtZW50IG1pZ2h0IGNoYW5nZSBzdWNoIHRoYXQgdGhlIG5vcm1hdGl2 ZSBmdW5jdGlvbmFsaXR5IGlzIA0KICBpbjxCUj40MjQ0YmlzLiAmbmJzcDsgQW5kLCB0aGlz IHdhcyBjb25zZW5zdXMgZnJvbSBJRVRGLTczIHBlciB0aG9zZSANCiAgbWludXRlczo8QlI+ Iklzc3VlOiBOb3JtYXRpdmUgYmVoYXZpb3IgdXBkYXRlIGZvciBSRkMgNDI0NDxCUj48QlI+ Q29uc2Vuc3VzIA0KICBub3RlZCB0byByZXZpc2UgUkZDIDQyNDQsIGFuZCBmaXggc29tZSBv dGhlciBrbm93biBwcm9ibGVtczxCUj53aXRoIGl0IGF0IHRlaCANCiAgc2FtZSB0aW1lLiBN QXJ5IEJhcm5lcyB2b2x1bnRlZXJlZCB0byBlZGl0IHRoZTxCUj5kb2N1bWVudC4iPEJSPjxC Uj5TbywgdGhlcmUgDQogIGlzIGEgY29uZmxpY3QgaW4gdGVybXMgb2YgYWNjZXB0aW5nIHRh cmdldC11cmkgZG9jdW1lbnQgYXMgdGhlPEJSPm9ubHkgDQogIGRlbGl2ZXJhYmxlIGZvciB0 aGF0IG1pbGVzdG9uZSBpbiB0aGUgSUVURi03MyANCiAgbWVldGluZy48QlI+PEJSPk1hcnku PEJSPjxCUj48QlI+LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS08QlI+RnJvbTogRGVhbiAN CiAgV2lsbGlzIFttYWlsdG86PEEgDQogIGhyZWY9Im1haWx0bzpkZWFuLndpbGxpc0Bzb2Z0 YXJtb3IuY29tIj5kZWFuLndpbGxpc0Bzb2Z0YXJtb3IuY29tPC9BPl08QlI+U2VudDogDQog IFRodXJzZGF5LCBBcHJpbCAxNiwgMjAwOSAyOjM2IFBNPEJSPlRvOiBCYXJuZXMsIE1hcnkg KFJJQ0gyOkFSMDApPEJSPkNjOiA8QSANCiAgaHJlZj0ibWFpbHRvOnNpcGNvcmVAaWV0Zi5v cmciPnNpcGNvcmVAaWV0Zi5vcmc8L0E+PEJSPlN1YmplY3Q6IFJlOiBbc2lwY29yZV0gDQog IFtTaXBdIFNJUENPUkUgLS0gSWYgeW91J3JlIG5vdCBzdWJzY3JpYmVkLCB5b3UncmU8QlI+ bWlzc2luZyANCiAgc3R1ZmY8QlI+PEJSPjxCUj5PbiBBcHIgMTYsIDIwMDksIGF0IDI6Mjcg UE0sIE1hcnkgQmFybmVzIHdyb3RlOjxCUj48QlI+Jmd0OyBJIA0KICBoYXZlIGFuIGlzc3Vl IHdpdGggdGhlIHRhcmdldC11cmkgZG9jdW1lbnQgYmVpbmcgcHJvcG9zZWQgYXMgdGhlIFdH PEJSPiZndDsgDQogIGRvY3VtZW50IGZvciB0aGUgdGFyZ2V0LXVyaSBkZWxpdmVyYWJsZS4g VGhpcyB3YXMgbm90IHRoZSBjb25zZW5zdXMgDQogIGluPEJSPjxCUj4mZ3Q7IFNGIHBlciBt eSByZWNvbGxlY3Rpb24gKHdoaWNoIG1heSBiZSBiaWFzZWQpIG5vciBwZXIgdGhlIFNJUCAN CiAgV0c8QlI+Jmd0OyBtaW51dGVzOjxCUj4mZ3Q7IDxBIA0KICBocmVmPSJodHRwOi8vd3d3 LmlldGYub3JnL3Byb2NlZWRpbmdzLzA5bWFyL21pbnV0ZXMvc2lwLmh0bWwiIA0KICB0YXJn ZXQ9X2JsYW5rPmh0dHA6Ly93d3cuaWV0Zi5vcmcvcHJvY2VlZGluZ3MvMDltYXIvbWludXRl cy9zaXAuaHRtbDwvQT48QlI+Jmd0OzxCUj4mZ3Q7IA0KICBXaGljaCBzdGF0ZTo8QlI+Jmd0 OyAiSXNzdWU6IFByb2dyZXNzIDQyNDRiaXMsIHRhcmdldC11cmkgZHJhZnQsIG9yIA0KICBi b3RoPzxCUj4mZ3Q7IEluIHRoZSBhYnNlbmNlIG9mIGEgY2xlYXIgY29uc2Vuc3VzLCB0aGUg Y2hhaXJzIHByb3Bvc2VkIHRoYXQgDQogIGJvdGg8QlI+Jmd0OyBkb2N1bWVudHMgcHJvY2Vl ZCBhbmQgd2UnbGwgaG9wZSB0aGF0IGZ1cnRoZXIgZGlzY3Vzc2lvbiBnaXZlcyB1cyANCiAg YTxCUj4mZ3Q7IGNvbnNlbnN1cy4iPEJSPiZndDs8QlI+Jmd0OyBOb3csIEkgcmVhbGl6ZSB0 aGF0IHRoZXJlIGFyZSBub3cgbmV3IA0KICBjaGFpcnMsIGJ1dCBJIGRvbid0IHRoaW5rIHRo YXQ8QlI+Jmd0OyBzaG91bGQgY2hhbmdlIHRoZSBXRyBjb25zZW5zdXMgZnJvbSB0aGUgDQog IFNJUCBXRyBzZXNzaW9uLjxCUj48QlI+SG93ZXZlciwgdGhlIG1pbnV0ZXMgZnJvbSBJRVRG IDczIHJlYWQ6PEJSPjxCUj5Ub3BpYzogDQogIFVSSSBhbmQgUGFyYW1ldGVyIERlbGl2ZXJ5 PEJSPkxlZCBieSBKb25hYXRoYW4gUm9zZW5iZXJnPEJSPlNsaWRlcyANCiAgcHJlc2VudGVk PEJSPjxBIA0KICBocmVmPSJodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaWQvZHJhZnQtcm9zZW5i ZXJnLXNpcC10YXJnZXQtdXJpLWRlbGl2ZXJ5LTAwLnR4dCIgDQogIHRhcmdldD1fYmxhbms+ aHR0cDovL3Rvb2xzLmlldGYub3JnL2lkL2RyYWZ0LXJvc2VuYmVyZy1zaXAtdGFyZ2V0LXVy aS1kZWxpdmVyeS0wMC50eHQ8L0E+PEJSPjxCUj4uLi48QlI+PEJSPlBvbGw6IA0KICBTaGFs bCBXRyBhZG9wdCB0aGlzIGRyYWZ0IHRvd2FyZHMgb3VyIGNoYXJ0ZXIgZGVsaXZlcmFibGUg b24gdGhlPEJSPnRvcGljPyANCiAgQ2hhaXJzIHJlcG9ydGVkIGEgc3Ryb25nIGNvbnNlbnN1 cyB0byBkbyBzby48QlI+U28gd2hpY2ggV0cgY29uc2Vuc3VzIG9mIHdoaWNoIA0KICBTSVAg V0cgc2Vzc2lvbiBkbyB5b3Ugbm90IHdhbnQgdG8gY2hhbmdlPzxCUj48QlI+PEJSPjxCUj4m Z3Q7PEJSPiZndDsgSXQgd2FzIA0KICBteSB1bmRlcnN0YW5kaW5nIGZyb20gdGhlIG1pbnV0 ZXMgdGhhdCB0aGUgZGlzY3Vzc2lvbiB3YXMgdG88QlI+Jmd0OyBjb250aW51ZSANCiAgYXMg dG8gd2hldGhlciB3ZSB3b3VsZCBtZXJnZSB0aGUgdHdvIGRvY3VtZW50cyBvciBhZ3JlZSBv bmU8QlI+Jmd0OyBvciB0aGUgDQogIG90aGVyIGFzIGEgV0cgZGVsaXZlcmFibGUuPEJSPiZn dDs8QlI+PEJSPjxCUj5UaGF0J3MgYWxzbyBjb25zaXN0ZW50IHdpdGggbXkgDQogIG5vdGVz IGZyb20gU0lQIGF0IDc0LjxCUj48QlI+TXkgYmVzdCBndWVzcyBpcyB0aGF0IFJGQyA0MjQ0 YmlzIGdvZXMgZm9yd2FyZCwgDQogIGFuZCB0aGF0IHRhcmdldC11cmktPEJSPmRlbGl2ZXJ5 IHR1cm5zIGludG8gYSAiSG93IHRvIHVzZSBILUkgdG8gbWVldCB0aGUgVVJJIA0KICBkZWxp dmVyeSB1c2U8QlI+Y2FzZXMiIA0KICBkb2N1bWVudC48QlI+PEJSPi0tPEJSPkRlYW48QlI+ PEJSPjxCUj48QlI+PEJSPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fPEJSPnNpcGNvcmUgDQogIG1haWxpbmcgbGlzdDxCUj48QSBocmVmPSJtYWls dG86c2lwY29yZUBpZXRmLm9yZyI+c2lwY29yZUBpZXRmLm9yZzwvQT48QlI+PEEgDQogIGhy ZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2lwY29yZSIgDQog IHRhcmdldD1fYmxhbms+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9z aXBjb3JlPC9BPjxCUj48L0JMT0NLUVVPVEU+PC9ESVY+PEJSPi0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSA8 YnI+DQpUaGlzIHRyYW5zbWlzc2lvbiAoaW5jbHVkaW5nIGFueSBhdHRhY2htZW50cykgbWF5 IGNvbnRhaW4gY29uZmlkZW50aWFsIGluZm9ybWF0aW9uLCBwcml2aWxlZ2VkIG1hdGVyaWFs IChpbmNsdWRpbmcgbWF0ZXJpYWwgcHJvdGVjdGVkIGJ5IHRoZSBzb2xpY2l0b3ItY2xpZW50 IG9yIG90aGVyIGFwcGxpY2FibGUgcHJpdmlsZWdlcyksIG9yIGNvbnN0aXR1dGUgbm9uLXB1 YmxpYyBpbmZvcm1hdGlvbi4gQW55IHVzZSBvZiB0aGlzIGluZm9ybWF0aW9uIGJ5IGFueW9u ZSBvdGhlciB0aGFuIHRoZSBpbnRlbmRlZCByZWNpcGllbnQgaXMgcHJvaGliaXRlZC4gSWYg eW91IGhhdmUgcmVjZWl2ZWQgdGhpcyB0cmFuc21pc3Npb24gaW4gZXJyb3IsIHBsZWFzZSBp bW1lZGlhdGVseSByZXBseSB0byB0aGUgc2VuZGVyIGFuZCBkZWxldGUgdGhpcyBpbmZvcm1h dGlvbiBmcm9tIHlvdXIgc3lzdGVtLiBVc2UsIGRpc3NlbWluYXRpb24sIGRpc3RyaWJ1dGlv biwgb3IgcmVwcm9kdWN0aW9uIG9mIHRoaXMgdHJhbnNtaXNzaW9uIGJ5IHVuaW50ZW5kZWQg cmVjaXBpZW50cyBpcyBub3QgYXV0aG9yaXplZCBhbmQgbWF5IGJlIHVubGF3ZnVsLg0KPC9C T0RZPjwvSFRNTD4NCg== ------_=_NextPart_001_01C9BEDD.42364CA4-- From mary.barnes@nortel.com Thu Apr 16 15:00:25 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DC7473A6DF4 for ; Thu, 16 Apr 2009 15:00:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.461 X-Spam-Level: X-Spam-Status: No, score=-6.461 tagged_above=-999 required=5 tests=[AWL=0.137, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fe56dIPGhPKZ for ; Thu, 16 Apr 2009 15:00:24 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id BD56A3A6D28 for ; Thu, 16 Apr 2009 15:00:23 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id n3GM1Vt01855; Thu, 16 Apr 2009 22:01:31 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C9BEDE.CDD25067" Date: Thu, 16 Apr 2009 17:03:42 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF1D7F9F40@zrc2hxm0.corp.nortel.com> In-Reply-To: <61968779B8AC4C4BAB421D4C12F008C015FEA2B0@XCH47YKF.rim.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] Target-uri document as SIPCORE WG document? (was RE:[Sip] SIPCORE -- If you're not subscribed, you're missing stuff Thread-Index: Acm+2VlZABnKJIMzQmy6h7q6thF4/gAAZt8gAACTQZQAACG6sA== References: <61968779B8AC4C4BAB421D4C12F008C015FEA2B0@XCH47YKF.rim.net> From: "Mary Barnes" To: "Andrew Allen" , Cc: sipcore@ietf.org Subject: Re: [sipcore] Target-uri document as SIPCORE WG document? (was RE:[Sip] SIPCORE -- If you're not subscribed, you're missing stuff X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Apr 2009 22:00:25 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9BEDE.CDD25067 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable A few comments below [MB].=20 ________________________________ From: Andrew Allen [mailto:aallen@rim.com]=20 Sent: Thursday, April 16, 2009 4:50 PM To: Barnes, Mary (RICH2:AR00); ietf.hanserik@gmail.com Cc: sipcore@ietf.org Subject: Re: [sipcore] Target-uri document as SIPCORE WG document? (was RE:[Sip] SIPCORE -- If you're not subscribed, you're missing stuff My understanding was that we would move forward with both drafts as WG items. My understanding was that in Dublin Target-uri was adopted as a SIP WG item. I don't want to see 4244bis become a dependency for the target-uri work which is urgently needed to solve some GRUU related issues.=20 [MB] Per my original comments below, the changes for a target-uri solution based on 4244 is actually more work than putting the normative functionality in 4244bis - that's because you still need to address security, privacy, how it is processed by a UAC, Proxy and UAS. You would then need duplicate text to set the context, etc. and that text would be identical to what's in 4244 OR you'd be breaking existing implementations and there are some of those. Now, we did have one reasonable suggestion as to adding a recommendation that the Privacy not be applied to the entire message as that limits proxy functionality - that's important for target-uri, but it's also likely an oversight in the original 4244. [/MB] =20 If 4244bis is ready when target-uri is then we can talk about rolling the two into one but I have concerns that 4244bis will take considerably longer than target-uri based on the discussion in San Fran. =20 [MB] Nope - as I noted earlier, I think the discussion was confounded because people were talking about changes to 4244bis (History-Info) that were well beyond what is required for target-uri - i.e., paring down the functionality to only collect the desired entries, which doesn't save a bit of work because you still have to recognize the conditions under which you drop the entries. Please listen to Francois' response to Hadriel's suggestion in the audio - it's towards the end. Also, the same security issues apply - when we completed 4244, the security section was carefully crafted based on security thoughts at the time. Those have changed (obviously) and if they are problematic in 4244bis, they would be a problem for the target-uri usage of 4244, which has the same security requirements as core 4244. [/MB] Target-uri has been needed really for GRUU for more then 2 years and is fairly straightforward. I don't think we should risk delaying that work waiting for 4244bis which seems to contain a number of issues we don't have consensus on yet.=20 [MB] The other changes to 4244bis are minor as compared to the normative functionality that needs to be added to the document to support target-uri. Please look at the diff. I also don't see the GRUU dependency - can you please clarify? I know GRUU is waiting for Outbound (I promise I will give up if 4244bis reaches a point where it is taking longer to finish than Outbound) and that the gruu-reg-event pkg is waiting for GRUU. [/MB]=20 That was my understanding of the approach we determined in San Francisco. ________________________________ From: sipcore-bounces@ietf.org =20 To: Hans Erik van Elburg =20 Cc: sipcore@ietf.org =20 Sent: Thu Apr 16 17:34:57 2009 Subject: Re: [sipcore] Target-uri document as SIPCORE WG document? (was RE:[Sip] SIPCORE -- If you're not subscribed, you're missing stuff=20 No - the discussion for 4244(bis) (extracted below) was entirely in the context of the discussion for the target-uri document. You can go back and listen to the audio to verify that. And, I've stated long before IETF-73 that it would be fairly straightforward to update 4244 to accomodate the target-uri requirements and while we were doing that, there were a few other fixes we could do.=20 =20 Mary.=20 ________________________________ From: Hans Erik van Elburg [mailto:ietf.hanserik@gmail.com]=20 Sent: Thursday, April 16, 2009 4:22 PM To: Barnes, Mary (RICH2:AR00) Cc: Dean Willis; sipcore@ietf.org Subject: Re: [sipcore] Target-uri document as SIPCORE WG document? (was RE: [Sip] SIPCORE -- If you're not subscribed, you're missing stuff Hi Mary, I believe that in the absence of consensus as the minutes correctly state, the the target-uri document should remain the WG document for the target-uri deliverable. 4424bis has another purpose, namely to fix the 4424. If at a certain moment in time it turns out that 4424bis is the appropriate document to contain normative text for target uri delivery then we can always decide to do so. At this stage it is to early to take that decision, given the confused state of the target-uri discussion. /Hans Erik van Elburg On Thu, Apr 16, 2009 at 10:02 PM, Mary Barnes wrote: I'm suggesting to change the decision from IETF-73 and accept the more recent realization that including normative text in another document rather than 4244bis will be fraught with error and I can't see how that is a good idea from a development perspective - you can't just implement the target-uri document. =09 Now, I don't have a problem if folks can accept that the target-uri document might change such that the normative functionality is in 4244bis. And, this was consensus from IETF-73 per those minutes: "Issue: Normative behavior update for RFC 4244 =09 Consensus noted to revise RFC 4244, and fix some other known problems with it at teh same time. MAry Barnes volunteered to edit the document." =09 So, there is a conflict in terms of accepting target-uri document as the only deliverable for that milestone in the IETF-73 meeting. =09 Mary. =09 =09 -----Original Message----- From: Dean Willis [mailto:dean.willis@softarmor.com] Sent: Thursday, April 16, 2009 2:36 PM To: Barnes, Mary (RICH2:AR00) Cc: sipcore@ietf.org Subject: Re: [sipcore] [Sip] SIPCORE -- If you're not subscribed, you're missing stuff =09 =09 On Apr 16, 2009, at 2:27 PM, Mary Barnes wrote: =09 > I have an issue with the target-uri document being proposed as the WG > document for the target-uri deliverable. This was not the consensus in =09 > SF per my recollection (which may be biased) nor per the SIP WG > minutes: > http://www.ietf.org/proceedings/09mar/minutes/sip.html > > Which state: > "Issue: Progress 4244bis, target-uri draft, or both? > In the absence of a clear consensus, the chairs proposed that both > documents proceed and we'll hope that further discussion gives us a > consensus." > > Now, I realize that there are now new chairs, but I don't think that > should change the WG consensus from the SIP WG session. =09 However, the minutes from IETF 73 read: =09 Topic: URI and Parameter Delivery Led by Jonaathan Rosenberg Slides presented =09 http://tools.ietf.org/id/draft-rosenberg-sip-target-uri-delivery-00.txt =09 ... =09 Poll: Shall WG adopt this draft towards our charter deliverable on the topic? Chairs reported a strong consensus to do so. So which WG consensus of which SIP WG session do you not want to change? =09 =09 =09 > > It was my understanding from the minutes that the discussion was to > continue as to whether we would merge the two documents or agree one > or the other as a WG deliverable. > =09 =09 That's also consistent with my notes from SIP at 74. =09 My best guess is that RFC 4244bis goes forward, and that target-uri- delivery turns into a "How to use H-I to meet the URI delivery use cases" document. =09 -- Dean =09 =09 =09 =09 _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore =09 ---------------------------------------------------------------------=20 This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client 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 immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.=20 ------_=_NextPart_001_01C9BEDE.CDD25067 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
A few=20 comments below [MB].

From: Andrew Allen = [mailto:aallen@rim.com]=20
Sent: Thursday, April 16, 2009 4:50 PM
To: Barnes, = Mary=20 (RICH2:AR00); ietf.hanserik@gmail.com
Cc:=20 sipcore@ietf.org
Subject: Re: [sipcore] Target-uri document as = SIPCORE=20 WG document? (was RE:[Sip] SIPCORE -- If you're not subscribed, you're = missing=20 stuff


My understanding was that we would = move forward=20 with both drafts as WG items.

My understanding was that in Dublin = Target-uri was adopted as a SIP WG item. I don't want to see 4244bis = become a=20 dependency for the target-uri work which is urgently needed to solve = some GRUU=20 related issues. 

[MB] Per my original comments below, = the changes for a=20 target-uri solution based on 4244 is actually more work=20 than putting the normative functionality in 4244bis - that's = because=20 you still need to address security, privacy, how it is processed = by a=20 UAC, Proxy and UAS. You would then need duplicate text to set = the=20 context, etc. and that text would be identical to what's in 4244 OR = you'd be=20 breaking existing implementations and there are some of those. Now, we = did have=20 one reasonable suggestion as to adding a recommendation that the Privacy = not be=20 applied to the entire message as that limits proxy functionality - = that's=20 important for target-uri, but it's also likely an oversight in the = original=20 4244. [/MB]  

If 4244bis is ready when = target-uri=20 is then we can talk about rolling the two into one but I have concerns = that=20 4244bis will take considerably longer than target-uri based on the = discussion in=20 San Fran.  

[MB] Nope - as I noted earlier, I think the discussion = was=20 confounded because people were talking about changes to 4244bis=20 (History-Info) that were well beyond what is required for target-uri - = i.e.,=20 paring down the functionality to only collect the desired entries, which = doesn't=20 save a bit of work because you still have to recognize the = conditions under=20 which you drop the entries.  Please listen to Francois' response to = Hadriel's suggestion in the audio - it's towards the end. Also, the same = security issues apply - when we completed 4244, the security section was = carefully crafted based on security thoughts at the time. Those have = changed=20 (obviously) and if they are problematic in 4244bis, they would be a = problem for=20 the target-uri usage of 4244, which has the same security requirements = as core=20 4244.  [/MB]

Target-uri has been needed = really=20 for GRUU for more then 2 years and is fairly straightforward. I don't = think we=20 should risk delaying that work waiting for 4244bis which seems to = contain a=20 number of issues we don't have consensus on yet. 

[MB] The other changes to 4244bis are = minor as=20 compared to the normative functionality that needs to be added to the = document=20 to support target-uri. Please look at the diff.  I also don't see = the GRUU=20 dependency - can you please clarify?  I know GRUU is = waiting for=20 Outbound (I promise I will give up if 4244bis reaches a point where = it is=20 taking longer to finish than Outbound) and that the gruu-reg-event = pkg is=20 waiting for GRUU.  [/MB] 

That was = my=20 understanding of the approach we determined in San=20 Francisco.

From: sipcore-bounces@ietf.org=20 <sipcore-bounces@ietf.org>
To: Hans Erik van Elburg=20 <ietf.hanserik@gmail.com>
Cc: sipcore@ietf.org=20 <sipcore@ietf.org>
Sent: Thu Apr 16 17:34:57=20 2009
Subject: Re: [sipcore] Target-uri document as SIPCORE WG=20 document? (was RE:[Sip] SIPCORE -- If you're not subscribed, you're = missing=20 stuff

No -=20 the discussion for 4244(bis) (extracted below) was entirely in the = context of=20 the discussion for the target-uri document. You can go back and listen = to the=20 audio to verify that.  And, I've stated long before IETF-73 that it = would=20 be fairly straightforward to update 4244 to accomodate the target-uri=20 requirements and while we were doing that, there were a few other fixes = we could=20 do.
 
Mary.=20

From: Hans Erik van Elburg=20 [mailto:ietf.hanserik@gmail.com]
Sent: Thursday, April 16, = 2009 4:22=20 PM
To: Barnes, Mary (RICH2:AR00)
Cc: Dean Willis;=20 sipcore@ietf.org
Subject: Re: [sipcore] Target-uri document as = SIPCORE=20 WG document? (was RE: [Sip] SIPCORE -- If you're not subscribed, you're = missing=20 stuff

Hi Mary,

I believe that in the absence of consensus as = the=20 minutes correctly state, the the target-uri document should remain the = WG=20 document for the target-uri deliverable.

4424bis has another = purpose,=20 namely to fix the 4424. If at a certain moment in time it turns out that = 4424bis=20 is the appropriate document to contain normative text for target uri = delivery=20 then we can always decide to do so. At this stage it is to early to take = that=20 decision, given the confused state of the target-uri discussion.
/Hans Erik van Elburg


On Thu, Apr 16, 2009 at 10:02 PM, Mary Barnes = <mary.barnes@nortel.com>=20 wrote:
I'm=20 suggesting to change the decision from IETF-73 and accept the = more
recent=20 realization that including normative text in another = document
rather than=20 4244bis will be fraught with error and I can't see how that
is a = good idea=20 from a development perspective - you can't just implement
the = target-uri=20 document.

Now, I don't have a problem if folks can accept that = the=20 target-uri
document might change such that the normative = functionality is=20 in
4244bis.   And, this was consensus from IETF-73 per those=20 minutes:
"Issue: Normative behavior update for RFC = 4244

Consensus=20 noted to revise RFC 4244, and fix some other known problems
with it = at teh=20 same time. MAry Barnes volunteered to edit = the
document."

So, there=20 is a conflict in terms of accepting target-uri document as the
only = deliverable for that milestone in the IETF-73=20 meeting.

Mary.


-----Original Message-----
From: = Dean=20 Willis [mailto:dean.willis@softarmor.com]<= BR>Sent:=20 Thursday, April 16, 2009 2:36 PM
To: Barnes, Mary = (RICH2:AR00)
Cc: sipcore@ietf.org
Subject: Re: = [sipcore]=20 [Sip] SIPCORE -- If you're not subscribed, you're
missing=20 stuff


On Apr 16, 2009, at 2:27 PM, Mary Barnes = wrote:

> I=20 have an issue with the target-uri document being proposed as the = WG
>=20 document for the target-uri deliverable. This was not the consensus=20 in

> SF per my recollection (which may be biased) nor per = the SIP=20 WG
> minutes:
> http://www.ietf.org/proceedings/09mar/minutes/sip.html
>
>=20 Which state:
> "Issue: Progress 4244bis, target-uri draft, or=20 both?
> In the absence of a clear consensus, the chairs proposed = that=20 both
> documents proceed and we'll hope that further discussion = gives us=20 a
> consensus."
>
> Now, I realize that there are = now new=20 chairs, but I don't think that
> should change the WG consensus = from the=20 SIP WG session.

However, the minutes from IETF 73 = read:

Topic:=20 URI and Parameter Delivery
Led by Jonaathan Rosenberg
Slides=20 presented
http://tools.ietf.org/id/draft-rosenberg-sip-target-uri-d= elivery-00.txt

...

Poll:=20 Shall WG adopt this draft towards our charter deliverable on = the
topic?=20 Chairs reported a strong consensus to do so.
So which WG consensus = of which=20 SIP WG session do you not want to change?



>
> = It was=20 my understanding from the minutes that the discussion was to
> = continue=20 as to whether we would merge the two documents or agree one
> or = the=20 other as a WG deliverable.
>


That's also consistent = with my=20 notes from SIP at 74.

My best guess is that RFC 4244bis goes = forward,=20 and that target-uri-
delivery turns into a "How to use H-I to meet = the URI=20 delivery use
cases"=20 = document.

--
Dean




__________________________= _____________________
sipcore=20 mailing list
sipcore@ietf.org
https://www.ietf.org/mailman/listinfo/sipcore

------------------------------------------------------= ---------------=20
This transmission (including any attachments) may contain = confidential=20 information, privileged material (including material protected by the=20 solicitor-client or other applicable privileges), or constitute = non-public=20 information. Any use of this information by anyone other than the = intended=20 recipient is prohibited. If you have received this transmission in = error, please=20 immediately reply to the sender and delete this information from your = system.=20 Use, dissemination, distribution, or reproduction of this transmission = by=20 unintended recipients is not authorized and may be unlawful. = ------_=_NextPart_001_01C9BEDE.CDD25067-- From HKaplan@acmepacket.com Thu Apr 16 15:15:28 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0C9A93A6CEC for ; Thu, 16 Apr 2009 15:15:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.542 X-Spam-Level: X-Spam-Status: No, score=-2.542 tagged_above=-999 required=5 tests=[AWL=0.057, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6AxK7FIryIuG for ; Thu, 16 Apr 2009 15:15:27 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 372533A6990 for ; Thu, 16 Apr 2009 15:15:27 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.340.0; Thu, 16 Apr 2009 18:16:39 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Thu, 16 Apr 2009 18:16:39 -0400 From: Hadriel Kaplan To: Adam Roach , SIPCORE Date: Thu, 16 Apr 2009 18:16:38 -0400 Thread-Topic: [sipcore] Call for Consensus: Additional Working Group Items Thread-Index: Acm+xWPd2tZPxqqWRtqxLVp1BP/J/QAFPmuA Message-ID: References: <49E777BD.9000202@estacado.net> <49E7785A.9060808@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 Subject: Re: [sipcore] Call for Consensus: Additional Working Group Items X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Apr 2009 22:15:28 -0000 > At 01:26 PM 4/16/2009, Adam Roach wrote: > Delivering request-URI and parameters to UAS via proxy (PS) > draft-rosenberg-sip-target-uri-delivery > [adopted by SIP WG consensus after IETF 73, still waiting for new > version] >=20 > SIP Events throttling mechanism (PS) > draft-niemi-sipping-event-throttle > [SIPPING WG indicated desire to adopt in as SIP WG item at IETF 74] My vote is to adopt neither in this WG. Neither of them update nor replace= 3261-3265. And DISPATCH may decide target-uri-delivery belongs in a new W= G with 4244bis, or event-throttle may belong in a new WG with overload cont= rols, for example. But I'm not too tied to this position - I just think it= 's a possible litmus test for this new organizational structure. -hadriel From adam@nostrum.com Thu Apr 16 15:38:01 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8C6463A6A11 for ; Thu, 16 Apr 2009 15:38:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.571 X-Spam-Level: X-Spam-Status: No, score=-2.571 tagged_above=-999 required=5 tests=[AWL=0.028, BAYES_00=-2.599, HTML_MESSAGE=0.001, SPF_PASS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TKTvTAH4TEKd for ; Thu, 16 Apr 2009 15:38:00 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id 617143A6961 for ; Thu, 16 Apr 2009 15:38:00 -0700 (PDT) Received: from [172.16.3.231] (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id n3GMd9qZ026990 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 16 Apr 2009 17:39:10 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <49E7B38D.8000603@nostrum.com> Date: Thu, 16 Apr 2009 17:39:09 -0500 From: Adam Roach User-Agent: Postbox 1.0b11 (Macintosh/2009041423) MIME-Version: 1.0 To: Hadriel Kaplan References: <49E777BD.9000202@estacado.net> <49E7785A.9060808@nostrum.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------010206070009090603010608" Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Cc: SIPCORE Subject: Re: [sipcore] Call for Consensus: Additional Working Group Items X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Apr 2009 22:38:01 -0000 This is a multi-part message in MIME format. --------------010206070009090603010608 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit [as chair] Hadriel Kaplan wrote: >> At 01:26 PM 4/16/2009, Adam Roach wrote: >> Delivering request-URI and parameters to UAS via proxy (PS) >> draft-rosenberg-sip-target-uri-delivery >> [adopted by SIP WG consensus after IETF 73, still waiting for new >> version] >> >> SIP Events throttling mechanism (PS) >> draft-niemi-sipping-event-throttle >> [SIPPING WG indicated desire to adopt in as SIP WG item at IETF 74] >> > > My vote is to adopt neither in this WG. Neither of them update nor replace 3261-3265. To be clear, the question we are asking is not "are these milestones okay" (that discussion has already concluded on the RAI list) -- it is "should we take on these specific documents to satisfy the these two milestones that are already part of the SIPCORE charter." /a --------------010206070009090603010608 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 7bit [as chair]

Hadriel Kaplan wrote: 
At 01:26 PM 4/16/2009, Adam Roach wrote:
Delivering request-URI and parameters to UAS via proxy    (PS)
   draft-rosenberg-sip-target-uri-delivery
   [adopted by SIP WG consensus after IETF 73, still waiting for new
version]

SIP Events throttling mechanism    (PS)
   draft-niemi-sipping-event-throttle
   [SIPPING WG indicated desire to adopt in as SIP WG item at IETF 74]
    

My vote is to adopt neither in this WG.  Neither of them update nor replace 3261-3265.

To be clear, the question we are asking is not "are these milestones okay" (that discussion has already concluded on the RAI list) -- it is "should we take on these specific documents to satisfy the these two milestones that are already part of the SIPCORE charter."

/a
--------------010206070009090603010608-- From eburger@standardstrack.com Thu Apr 16 16:02:04 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0325A28C14E for ; Thu, 16 Apr 2009 16:02:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ihhgcpwlwgmq for ; Thu, 16 Apr 2009 16:02:03 -0700 (PDT) Received: from gs19.inmotionhosting.com (gs19.inmotionhosting.com [205.134.252.251]) by core3.amsl.com (Postfix) with ESMTP id 4CF0928C0EB for ; Thu, 16 Apr 2009 16:02:03 -0700 (PDT) Received: from [116.6.21.151] by gs19.inmotionhosting.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1Luabr-0000On-33; Thu, 16 Apr 2009 16:03:07 -0700 Message-Id: From: Eric Burger To: Adam Roach , Hadriel Kaplan In-Reply-To: <49E7B38D.8000603@nostrum.com> Content-Type: multipart/signed; boundary=Apple-Mail-5--377212786; micalg=sha1; protocol="application/pkcs7-signature" Mime-Version: 1.0 (Apple Message framework v930.3) Date: Fri, 17 Apr 2009 07:03:12 +0800 References: <49E777BD.9000202@estacado.net> <49E7785A.9060808@nostrum.com> <49E7B38D.8000603@nostrum.com> X-Mailer: Apple Mail (2.930.3) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gs19.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - standardstrack.com X-Source: X-Source-Args: X-Source-Dir: Cc: SIPCORE Subject: Re: [sipcore] Call for Consensus: Additional Working Group Items X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Apr 2009 23:02:04 -0000 --Apple-Mail-5--377212786 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit And Hadriel is saying they are not Core. On Apr 17, 2009, at 6:39 AM, Adam Roach wrote: > [as chair] > > Hadriel Kaplan wrote: >> >>> At 01:26 PM 4/16/2009, Adam Roach wrote: >>> Delivering request-URI and parameters to UAS via proxy (PS) >>> draft-rosenberg-sip-target-uri-delivery >>> [adopted by SIP WG consensus after IETF 73, still waiting for new >>> version] >>> >>> SIP Events throttling mechanism (PS) >>> draft-niemi-sipping-event-throttle >>> [SIPPING WG indicated desire to adopt in as SIP WG item at IETF >>> 74] >>> >> My vote is to adopt neither in this WG. Neither of them update nor >> replace 3261-3265. > > To be clear, the question we are asking is not "are these milestones > okay" (that discussion has already concluded on the RAI list) -- it > is "should we take on these specific documents to satisfy the these > two milestones that are already part of the SIPCORE charter." > > /a > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore --Apple-Mail-5--377212786 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGPTCCBjkw ggUhoAMCAQICEC+VK1RLWxrF8KJZDR9k8p8wDQYJKoZIhvcNAQEFBQAwga4xCzAJBgNVBAYTAlVT MQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VS VFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQD Ey1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwwHhcNMDgwODEz MDAwMDAwWhcNMDkwODEzMjM1OTU5WjCB4TE1MDMGA1UECxMsQ29tb2RvIFRydXN0IE5ldHdvcmsg LSBQRVJTT05BIE5PVCBWQUxJREFURUQxRjBEBgNVBAsTPVRlcm1zIGFuZCBDb25kaXRpb25zIG9m IHVzZTogaHR0cDovL3d3dy5jb21vZG8ubmV0L3JlcG9zaXRvcnkxHzAdBgNVBAsTFihjKTIwMDMg Q29tb2RvIExpbWl0ZWQxFDASBgNVBAMTC0VyaWMgQnVyZ2VyMSkwJwYJKoZIhvcNAQkBFhplYnVy Z2VyQHN0YW5kYXJkc3RyYWNrLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMTF RRoA4LgOACMFph0aomRC/UpqoA5C/d6DUTOvTMrYSEqkjwnU4zxDtBcHlcB4AxKAov00MYsUvEU4 loz7BHjfDjv76AIkcwu33VYQbzGmarVnyaXsVb6f/cyRL3fPT0VOVO2tQAEEgwg//CX0jN8Kn2jH uXD/HEvko7cmpL3Pwevf3+DwB61v7ca79PpEZfn/WhaqRKA4uVNPj/JbieeaLo2v/0RJzrEElZK0 pHCqxiD3mQ8ossPkA9fUCSxLlbdMcPU3be5x8vt8Q8mYTXF5Z3d9RZmYrmNkvTQtdzVpfYWr/hgV Xqm9tByOOAR+hoN3FKbubR/OrAHL9yDAd4sCAwEAAaOCAhwwggIYMB8GA1UdIwQYMBaAFImCZ33E nSZwAEu0UEh83j2uBG59MB0GA1UdDgQWBBRDWgutb7b8R/L7G3Y3D+molAA3VzAOBgNVHQ8BAf8E BAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJ YIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQECAQEBMCswKQYIKwYBBQUHAgEW HWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BTMIGlBgNVHR8EgZ0wgZowTKBKoEiGRmh0dHA6 Ly9jcmwuY29tb2RvY2EuY29tL1VUTi1VU0VSRmlyc3QtQ2xpZW50QXV0aGVudGljYXRpb25hbmRF bWFpbC5jcmwwSqBIoEaGRGh0dHA6Ly9jcmwuY29tb2RvLm5ldC9VVE4tVVNFUkZpcnN0LUNsaWVu dEF1dGhlbnRpY2F0aW9uYW5kRW1haWwuY3JsMGwGCCsGAQUFBwEBBGAwXjA2BggrBgEFBQcwAoYq aHR0cDovL2NydC5jb21vZG9jYS5jb20vVVROQUFBQ2xpZW50Q0EuY3J0MCQGCCsGAQUFBzABhhho dHRwOi8vb2NzcC5jb21vZG9jYS5jb20wJQYDVR0RBB4wHIEaZWJ1cmdlckBzdGFuZGFyZHN0cmFj ay5jb20wDQYJKoZIhvcNAQEFBQADggEBAGeBR7NPCvrY3GQoIi49JOuciatY2r4st905Jw1etp6J umFFWlaCBl11tFSclk/3S45B+lUv3SEvG4CEjUByPScprVmCqHR+y8BAQaB/CV+N1y14x3MbhJ+Z 8XDGKeUXuuyGd9w0l3/t/QPid6TRXQjQFrLPFs1IALuNpNiFMHEF/xFbMG1Z2vznR/gSPlePekoZ TqcExIDBNZTBebpZqwAXzPpedNNOclbMLFLWDMOAozVRpkfjI0eiFsk8SF1Ho1Gb9Bx8DeG4peE2 KRVOR9FFnZZgBpFjXYRcglsMOSKCY8HgE+NGvbbqbrMoBV/BlYyxRXwfti71RL9Zs2Cq1eQxggP8 MIID+AIBATCBwzCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0IExh a2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRwOi8v d3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhlbnRp Y2F0aW9uIGFuZCBFbWFpbAIQL5UrVEtbGsXwolkNH2TynzAJBgUrDgMCGgUAoIICDTAYBgkqhkiG 9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wOTA0MTYyMzAzMTJaMCMGCSqGSIb3 DQEJBDEWBBRNhGuvB7ACJ5tGOFf/dVt4fqLCVDCB1AYJKwYBBAGCNxAEMYHGMIHDMIGuMQswCQYD VQQGEwJVUzELMAkGA1UECBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVU aGUgVVNFUlRSVVNUIE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2 MDQGA1UEAxMtVVROLVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsAhAv lStUS1saxfCiWQ0fZPKfMIHWBgsqhkiG9w0BCRACCzGBxqCBwzCBrjELMAkGA1UEBhMCVVMxCzAJ BgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVT VCBOZXR3b3JrMSEwHwYDVQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVU Ti1VU0VSRmlyc3QtQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbAIQL5UrVEtbGsXwolkN H2TynzANBgkqhkiG9w0BAQEFAASCAQA8NMtpHWqDd/gtnvS6NQs39vCS2wA/tYYgGaEuOlxl6pNI w4r2CFtCB45vywtxm9LYd3bWT98rY6EhmT1phxUXcE8sy5fQTnDOIdOaMWNzMnnfHvw59KBkcGYT uJfoNXagKmu+6po/NfFmPjcoMCKzG0SYsUZ2SXw1uF0Rytgc+cQoeAYThs3pTLkjjz9s5XtrDTdw dr5BupTcp91/v9rqGhiY/U95ijOxkWfKIgkOnvpMitNm6bAkJnl7EY/h1BL6Z2edYXA5+Q3Art+l 8iJrjr8dl1k95TvPoGwKYawnxZpQopA0/gy0iIdPPonJaCLocK5QdTus81gueIukO1viAAAAAAAA --Apple-Mail-5--377212786-- From adam@nostrum.com Thu Apr 16 16:07:50 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1467D28C164 for ; Thu, 16 Apr 2009 16:07:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.572 X-Spam-Level: X-Spam-Status: No, score=-2.572 tagged_above=-999 required=5 tests=[AWL=0.028, BAYES_00=-2.599, SPF_PASS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kq4c3CgwDuOB for ; Thu, 16 Apr 2009 16:07:49 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id D95173A6EDD for ; Thu, 16 Apr 2009 16:07:48 -0700 (PDT) Received: from [172.16.3.231] (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id n3GN8xUI029335 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 16 Apr 2009 18:08:59 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <49E7BA8B.7060107@nostrum.com> Date: Thu, 16 Apr 2009 18:08:59 -0500 From: Adam Roach User-Agent: Postbox 1.0b11 (Macintosh/2009041423) MIME-Version: 1.0 To: Eric Burger Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Cc: SIPCORE , Hadriel Kaplan Subject: [sipcore] Do we really want to reopen the RAI re-org discussion? (was Re: Call for Consensus: Additional Working Group Items) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Apr 2009 23:07:50 -0000 [as chair] That's a completely different topic. I can't stop you from re-opening the discussion of how to handle SIP and SIPPING milestones that would otherwise be orphaned, but I will ask you to take it elsewhere. The place you would go to re-open the RAI re-org discussion is the RAI mailing list. I suspect many interested parties would view re-opening that particular topic to be unnecessarily disruptive. /a Eric Burger wrote: > And Hadriel is saying they are not Core. > > On Apr 17, 2009, at 6:39 AM, Adam Roach wrote: > >> [as chair] >> >> Hadriel Kaplan wrote: >>>> At 01:26 PM 4/16/2009, Adam Roach wrote: >>>> Delivering request-URI and parameters to UAS via proxy (PS) >>>> draft-rosenberg-sip-target-uri-delivery >>>> [adopted by SIP WG consensus after IETF 73, still waiting for new >>>> version] >>>> >>>> SIP Events throttling mechanism (PS) >>>> draft-niemi-sipping-event-throttle >>>> [SIPPING WG indicated desire to adopt in as SIP WG item at IETF 74] >>> My vote is to adopt neither in this WG. Neither of them update nor >>> replace 3261-3265. >> >> To be clear, the question we are asking is not "are these milestones >> okay" (that discussion has already concluded on the RAI list) -- it >> is "should we take on these specific documents to satisfy the these >> two milestones that are already part of the SIPCORE charter." >> >> /a >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore From HKaplan@acmepacket.com Thu Apr 16 16:20:29 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1F55528C167 for ; Thu, 16 Apr 2009 16:20:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.543 X-Spam-Level: X-Spam-Status: No, score=-2.543 tagged_above=-999 required=5 tests=[AWL=0.056, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uVoopiPldchr for ; Thu, 16 Apr 2009 16:20:28 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 1BD4328C164 for ; Thu, 16 Apr 2009 16:20:28 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.340.0; Thu, 16 Apr 2009 19:21:40 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Thu, 16 Apr 2009 19:21:39 -0400 From: Hadriel Kaplan To: Adam Roach Date: Thu, 16 Apr 2009 19:21:39 -0400 Thread-Topic: [sipcore] Call for Consensus: Additional Working Group Items Thread-Index: Acm+5DHXQzKtqmmKTKCbztewYNM0DQABKe/g Message-ID: References: <49E777BD.9000202@estacado.net> <49E7785A.9060808@nostrum.com> <49E7B38D.8000603@nostrum.com> In-Reply-To: <49E7B38D.8000603@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 Cc: SIPCORE Subject: Re: [sipcore] Call for Consensus: Additional Working Group Items X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Apr 2009 23:20:29 -0000 Oh, sorry, I misunderstood your question. So we've already got milestones = to tackle the problems, and you're just asking about the specific solution = docs for them. Got it. Right, then I rescind my original negative response. Sorry for the confusion. :( -hadriel p.s. though it makes me wonder if we can really decide what goes into SIPCO= RE or not a priori, until we agree on what the right solution is to a probl= em. Target-uri for instance originally started as an update to 3261 when i= t was ua-loose-route I think. But I digress... ________________________________________ From: Adam Roach [mailto:adam@nostrum.com]=20 Sent: Thursday, April 16, 2009 6:39 PM To: Hadriel Kaplan Cc: SIPCORE Subject: Re: [sipcore] Call for Consensus: Additional Working Group Items [as chair] Hadriel Kaplan wrote:=20 At 01:26 PM 4/16/2009, Adam Roach wrote: Delivering request-URI and parameters to UAS via proxy (PS) draft-rosenberg-sip-target-uri-delivery [adopted by SIP WG consensus after IETF 73, still waiting for new version] SIP Events throttling mechanism (PS) draft-niemi-sipping-event-throttle [SIPPING WG indicated desire to adopt in as SIP WG item at IETF 74] =20 My vote is to adopt neither in this WG. Neither of them update nor replace= 3261-3265. To be clear, the question we are asking is not "are these milestones okay" = (that discussion has already concluded on the RAI list) -- it is "should we= take on these specific documents to satisfy the these two milestones that = are already part of the SIPCORE charter." /a From drage@alcatel-lucent.com Thu Apr 16 16:28:00 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A95153A6AE8 for ; Thu, 16 Apr 2009 16:28:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.037 X-Spam-Level: X-Spam-Status: No, score=-6.037 tagged_above=-999 required=5 tests=[AWL=0.212, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZdOofMzoOwGs for ; Thu, 16 Apr 2009 16:27:59 -0700 (PDT) Received: from smail3.alcatel.fr (smail3.alcatel.fr [64.208.49.56]) by core3.amsl.com (Postfix) with ESMTP id 88B803A67C0 for ; Thu, 16 Apr 2009 16:27:58 -0700 (PDT) Received: from FRMRSSXCHHUB04.dc-m.alcatel-lucent.com (FRMRSSXCHHUB04.dc-m.alcatel-lucent.com [135.120.45.64]) by smail3.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id n3GNT7tt003126 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 17 Apr 2009 01:29:07 +0200 Received: from FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com ([135.120.45.39]) by FRMRSSXCHHUB04.dc-m.alcatel-lucent.com ([135.120.45.64]) with mapi; Fri, 17 Apr 2009 01:29:07 +0200 From: "DRAGE, Keith (Keith)" To: Adam Roach , Eric Burger Date: Fri, 17 Apr 2009 01:29:06 +0200 Thread-Topic: [sipcore] Do we really want to reopen the RAI re-org discussion? (was Re: Call for Consensus: Additional Working Group Items) Thread-Index: Acm+6FkdKLh/rEyVSLqOMXkxSdxtUgAASP3Q Message-ID: <28B7C3AA2A7ABA4A841F11217ABE78D6758C605F@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> References: <49E7BA8B.7060107@nostrum.com> In-Reply-To: <49E7BA8B.7060107@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.57 on 155.132.188.83 Cc: SIPCORE , Hadriel Kaplan Subject: Re: [sipcore] Do we really want to reopen the RAI re-org discussion? (was Re: Call for Consensus: Additional Working Group Items) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Apr 2009 23:28:00 -0000 Except that the milestones themselves were a decision of the ADs and did no= t get list discussion. In fact milestones were being added and deleted from= the charters even on Monday evening (my time). The charters themselves wer= e part of the RAI reorg discussions, but the milestones were not. So I do n= ot see how a discussion of them can be a reopening.=20 You can issue a direction about whether the appropriate place to discuss th= e SIPCORE milestones that they have been allocated is the the SIPCORE or RA= I list, but it does not reopen a discussion. I must admit I am a bit bemused by the allocation of the throttling one, be= cause I do remember having a discussion some time back where I asked, if fo= r some reason we were reissuing RFC 3265 would the throttling form part of = it, and I was assured in no uncertain terms that it was a totally separate = and independent extension. Now if the answer to that had been YES rather th= an NO, I could understand it being allocated to SIPCORE. The target-uri one I do understand, because basically if RFC 3261 was ever = reisssued, there is a strong view that History-Info would form part of that= reissue. In my view target-uri is part of that scope. However more on that= in a separate mail. Keith > -----Original Message----- > From: sipcore-bounces@ietf.org=20 > [mailto:sipcore-bounces@ietf.org] On Behalf Of Adam Roach > Sent: Friday, April 17, 2009 12:09 AM > To: Eric Burger > Cc: SIPCORE; Hadriel Kaplan > Subject: [sipcore] Do we really want to reopen the RAI re-org=20 > discussion? (was Re: Call for Consensus: Additional Working=20 > Group Items) >=20 > [as chair] >=20 > That's a completely different topic. I can't stop you from=20 > re-opening the discussion of how to handle SIP and SIPPING=20 > milestones that would otherwise be orphaned, but I will ask=20 > you to take it elsewhere. The place you would go to re-open=20 > the RAI re-org discussion is the RAI mailing list. I suspect=20 > many interested parties would view re-opening that particular=20 > topic to be unnecessarily disruptive. >=20 > /a >=20 > Eric Burger wrote: > > And Hadriel is saying they are not Core. > > > > On Apr 17, 2009, at 6:39 AM, Adam Roach wrote: > > > >> [as chair] > >> > >> Hadriel Kaplan wrote: > >>>> At 01:26 PM 4/16/2009, Adam Roach wrote: > >>>> Delivering request-URI and parameters to UAS via proxy (PS) > >>>> draft-rosenberg-sip-target-uri-delivery > >>>> [adopted by SIP WG consensus after IETF 73, still waiting for=20 > >>>> new version] > >>>> > >>>> SIP Events throttling mechanism (PS) > >>>> draft-niemi-sipping-event-throttle > >>>> [SIPPING WG indicated desire to adopt in as SIP WG=20 > item at IETF=20 > >>>> 74] > >>> My vote is to adopt neither in this WG. Neither of them=20 > update nor=20 > >>> replace 3261-3265. > >> > >> To be clear, the question we are asking is not "are these=20 > milestones=20 > >> okay" (that discussion has already concluded on the RAI=20 > list) -- it=20 > >> is "should we take on these specific documents to satisfy=20 > the these=20 > >> two milestones that are already part of the SIPCORE charter." > >> > >> /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 > = From adam@nostrum.com Thu Apr 16 16:29:29 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D93283A6990 for ; Thu, 16 Apr 2009 16:29:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.573 X-Spam-Level: X-Spam-Status: No, score=-2.573 tagged_above=-999 required=5 tests=[AWL=0.026, BAYES_00=-2.599, HTML_MESSAGE=0.001, SPF_PASS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6f7Pk1EVEOjg for ; Thu, 16 Apr 2009 16:29:29 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id A9C7D3A67C0 for ; Thu, 16 Apr 2009 16:29:28 -0700 (PDT) Received: from [172.16.3.231] (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id n3GNUbk9031014 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 16 Apr 2009 18:30:38 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <49E7BF9D.10706@nostrum.com> Date: Thu, 16 Apr 2009 18:30:37 -0500 From: Adam Roach User-Agent: Postbox 1.0b11 (Macintosh/2009041423) MIME-Version: 1.0 To: SIPCORE Content-Type: multipart/alternative; boundary="------------040506050307050809080206" Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Subject: [sipcore] Call for Consensus: draft-holmberg-sip-keep X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Apr 2009 23:29:29 -0000 This is a multi-part message in MIME format. --------------040506050307050809080206 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit [as chair] There was already a request for consensus around adopting the document draft-holmberg-sip-keep on the SIP working group mailing list. The call was for adopting it "as a WG document in RAI (WG tbd)". The specific call for consensus can be found here: There were 15 messages in support of doing so, and no objections. I'm asking a related but slightly different question: Given that SIPCORE has a charter milestone for "Mechanism for indicating support for keep-alives," do you think we should adopt draft-holmberg-sip-keep as the basis for completing this milestone? As before, a simple "yes" is fine; however, if you don't think we should adopt this document, please provide rationale. /a --------------040506050307050809080206 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit [as chair]

There was already a request for consensus around adopting the document draft-holmberg-sip-keep on the SIP working group mailing list. The call was for adopting it "as a WG document in RAI (WG tbd)". The specific call for consensus can be found here:

  <http://www.ietf.org/mail-archive/web/sip/current/msg27141.html>

There were 15 messages in support of doing so, and no objections.

I'm asking a related but slightly different question: Given that SIPCORE has a charter milestone for "Mechanism for indicating support for keep-alives," do you think we should adopt draft-holmberg-sip-keep as the basis for completing this milestone? As before, a simple "yes" is fine; however, if you don't think we should adopt this document, please provide rationale.

/a
--------------040506050307050809080206-- From drage@alcatel-lucent.com Thu Apr 16 16:40:11 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E9F1B3A691B for ; Thu, 16 Apr 2009 16:40:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.04 X-Spam-Level: X-Spam-Status: No, score=-4.04 tagged_above=-999 required=5 tests=[AWL=-1.791, BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rq0VViFcSqE9 for ; Thu, 16 Apr 2009 16:40:11 -0700 (PDT) Received: from smail2.alcatel.fr (smail2.alcatel.fr [64.208.49.57]) by core3.amsl.com (Postfix) with ESMTP id F36C73A67C0 for ; Thu, 16 Apr 2009 16:40:10 -0700 (PDT) Received: from FRMRSSXCHHUB02.dc-m.alcatel-lucent.com (FRMRSSXCHHUB02.dc-m.alcatel-lucent.com [135.120.45.62]) by smail2.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id n3GNfLtU030024 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 17 Apr 2009 01:41:21 +0200 Received: from FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com ([135.120.45.39]) by FRMRSSXCHHUB02.dc-m.alcatel-lucent.com ([135.120.45.62]) with mapi; Fri, 17 Apr 2009 01:41:21 +0200 From: "DRAGE, Keith (Keith)" To: Adam Roach , SIPCORE Date: Fri, 17 Apr 2009 01:41:18 +0200 Thread-Topic: [sipcore] Call for Consensus: draft-holmberg-sip-keep Thread-Index: Acm+62XcdDn9STxeQ1qQnDx4MrUBQwAAUwmw Message-ID: <28B7C3AA2A7ABA4A841F11217ABE78D6758C6061@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> References: <49E7BF9D.10706@nostrum.com> In-Reply-To: <49E7BF9D.10706@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="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 155.132.188.80 Subject: Re: [sipcore] Call for Consensus: draft-holmberg-sip-keep X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Apr 2009 23:40:12 -0000 V2hpbGUgSSB1bmRlcnN0YW5kIHRoZSBkb2N1bWVudHMgYXJlIHN1YnN0YW50aWFsbHkgdGhlIHNh bWUsIGl0IG11Z2h0IGJlIGJldHRlciB0byBhc2sgdGhlIHF1ZXN0aW9uIG9mOg0KIA0KaHR0cDov L3d3dy5pZXRmLm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtaG9sbWJlcmctc2lwY29yZS1rZWVw LTAwLnR4dA0KDQpyZWdhcmRzDQoNCktlaXRoDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX18NCg0KCUZyb206IHNpcGNvcmUtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOnNpcGNv cmUtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIEFkYW0gUm9hY2gNCglTZW50OiBGcmlk YXksIEFwcmlsIDE3LCAyMDA5IDEyOjMxIEFNDQoJVG86IFNJUENPUkUNCglTdWJqZWN0OiBbc2lw Y29yZV0gQ2FsbCBmb3IgQ29uc2Vuc3VzOiBkcmFmdC1ob2xtYmVyZy1zaXAta2VlcA0KCQ0KCQ0K CVthcyBjaGFpcl0NCgkNCglUaGVyZSB3YXMgYWxyZWFkeSBhIHJlcXVlc3QgZm9yIGNvbnNlbnN1 cyBhcm91bmQgYWRvcHRpbmcgdGhlIGRvY3VtZW50IGRyYWZ0LWhvbG1iZXJnLXNpcC1rZWVwIG9u IHRoZSBTSVAgd29ya2luZyBncm91cCBtYWlsaW5nIGxpc3QuIFRoZSBjYWxsIHdhcyBmb3IgYWRv cHRpbmcgaXQgImFzIGEgV0cgZG9jdW1lbnQgaW4gUkFJIChXRyB0YmQpIi4gVGhlIHNwZWNpZmlj IGNhbGwgZm9yIGNvbnNlbnN1cyBjYW4gYmUgZm91bmQgaGVyZToNCgkNCgkgIDxodHRwOi8vd3d3 LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvc2lwL2N1cnJlbnQvbXNnMjcxNDEuaHRtbD4gPGh0 dHA6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9zaXAvY3VycmVudC9tc2cyNzE0MS5o dG1sPiANCgkNCglUaGVyZSB3ZXJlIDE1IG1lc3NhZ2VzIGluIHN1cHBvcnQgb2YgZG9pbmcgc28s IGFuZCBubyBvYmplY3Rpb25zLg0KCQ0KCUknbSBhc2tpbmcgYSByZWxhdGVkIGJ1dCBzbGlnaHRs eSBkaWZmZXJlbnQgcXVlc3Rpb246IEdpdmVuIHRoYXQgU0lQQ09SRSBoYXMgYSBjaGFydGVyIG1p bGVzdG9uZSBmb3IgIk1lY2hhbmlzbSBmb3IgaW5kaWNhdGluZyBzdXBwb3J0IGZvciBrZWVwLWFs aXZlcywiIGRvIHlvdSB0aGluayB3ZSBzaG91bGQgYWRvcHQgZHJhZnQtaG9sbWJlcmctc2lwLWtl ZXAgYXMgdGhlIGJhc2lzIGZvciBjb21wbGV0aW5nIHRoaXMgbWlsZXN0b25lPyBBcyBiZWZvcmUs IGEgc2ltcGxlICJ5ZXMiIGlzIGZpbmU7IGhvd2V2ZXIsIGlmIHlvdSBkb24ndCB0aGluayB3ZSBz aG91bGQgYWRvcHQgdGhpcyBkb2N1bWVudCwgcGxlYXNlIHByb3ZpZGUgcmF0aW9uYWxlLg0KCQ0K CS9hDQoJDQoNCg== From adam@nostrum.com Thu Apr 16 16:42:09 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 83EB73A6925 for ; Thu, 16 Apr 2009 16:42:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.574 X-Spam-Level: X-Spam-Status: No, score=-2.574 tagged_above=-999 required=5 tests=[AWL=0.026, BAYES_00=-2.599, SPF_PASS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OxK5o2X9bJNb for ; Thu, 16 Apr 2009 16:42:08 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id 64E3A3A68C8 for ; Thu, 16 Apr 2009 16:42:08 -0700 (PDT) Received: from [172.16.3.231] (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id n3GNhIrL032010 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 16 Apr 2009 18:43:19 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <49E7C296.1030501@nostrum.com> Date: Thu, 16 Apr 2009 18:43:18 -0500 From: Adam Roach User-Agent: Postbox 1.0b11 (Macintosh/2009041423) MIME-Version: 1.0 To: Hadriel Kaplan References: <49E777BD.9000202@estacado.net> <49E7785A.9060808@nostrum.com> <49E7B38D.8000603@nostrum.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Cc: SIPCORE Subject: Re: [sipcore] Call for Consensus: Additional Working Group Items X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Apr 2009 23:42:09 -0000 [as chair] Hadriel Kaplan wrote: > p.s. though it makes me wonder if we can really decide what goes into SIPCORE or not a priori, until we agree on what the right solution is to a problem. Target-uri for instance originally started as an update to 3261 when it was ua-loose-route I think. But I digress... > That's a fair point for any new work RAI takes on in the future, and something that DISPATCH will need to pay special attention to. This situation is different, though. The majority of the milestones in the SIPCORE charter are there to avoid orphaning them due to the SIP and SIPPING shutdown. In the RAI reorganization, the consensus was to move most of the active items from SIP and SIPPING into SIPCORE as a special, one-time-only grandfathering action. They would not otherwise belong in SIPCORE. /a From adam@nostrum.com Thu Apr 16 16:44:19 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9A9813A6C2A for ; Thu, 16 Apr 2009 16:44:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.575 X-Spam-Level: X-Spam-Status: No, score=-2.575 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, SPF_PASS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X3bPsKJwXBVz for ; Thu, 16 Apr 2009 16:44:18 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id 770E53A6990 for ; Thu, 16 Apr 2009 16:44:18 -0700 (PDT) Received: from [172.16.3.231] (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id n3GNjTQG032221 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 16 Apr 2009 18:45:29 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <49E7C319.7090602@nostrum.com> Date: Thu, 16 Apr 2009 18:45:29 -0500 From: Adam Roach User-Agent: Postbox 1.0b11 (Macintosh/2009041423) MIME-Version: 1.0 To: "DRAGE, Keith (Keith)" References: <49E7BF9D.10706@nostrum.com> <28B7C3AA2A7ABA4A841F11217ABE78D6758C6061@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> In-Reply-To: <28B7C3AA2A7ABA4A841F11217ABE78D6758C6061@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Cc: SIPCORE Subject: Re: [sipcore] Call for Consensus: draft-holmberg-sipcore-keep X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Apr 2009 23:44:19 -0000 Keith is, of course, correct. The document under discussion should be draft-holmberg-sipcore-keep. I apologize for the confusion. /a DRAGE, Keith (Keith) wrote: > While I understand the documents are substantially the same, it mught be better to ask the question of: > > http://www.ietf.org/internet-drafts/draft-holmberg-sipcore-keep-00.txt > > regards > > Keith > > > ________________________________ > > From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behalf Of Adam Roach > Sent: Friday, April 17, 2009 12:31 AM > To: SIPCORE > Subject: [sipcore] Call for Consensus: draft-holmberg-sip-keep > > > [as chair] > > There was already a request for consensus around adopting the document draft-holmberg-sip-keep on the SIP working group mailing list. The call was for adopting it "as a WG document in RAI (WG tbd)". The specific call for consensus can be found here: > > > > There were 15 messages in support of doing so, and no objections. > > I'm asking a related but slightly different question: Given that SIPCORE has a charter milestone for "Mechanism for indicating support for keep-alives," do you think we should adopt draft-holmberg-sip-keep as the basis for completing this milestone? As before, a simple "yes" is fine; however, if you don't think we should adopt this document, please provide rationale. > > /a > > > From AUDET@nortel.com Thu Apr 16 16:45:13 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CF29B3A6E0B for ; Thu, 16 Apr 2009 16:45:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.327 X-Spam-Level: X-Spam-Status: No, score=-5.327 tagged_above=-999 required=5 tests=[AWL=-0.796, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, RCVD_NUMERIC_HELO=2.067] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uYaKfFdNqt5Y for ; Thu, 16 Apr 2009 16:45:13 -0700 (PDT) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id CDA8F3A6EC1 for ; Thu, 16 Apr 2009 16:45:12 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id n3GNjBw18904; Thu, 16 Apr 2009 23:45:11 GMT Received: from 47.103.119.44 ([47.103.119.44]) by zrc2hxm0.corp.nortel.com ([47.103.119.44]) with Microsoft Exchange Server HTTP-DAV ; Thu, 16 Apr 2009 23:45:12 +0000 References: <49E7BF9D.10706@nostrum.com> Message-ID: <385AF033-31D8-477A-86A4-78414FD2CB46@nortel.com> From: "Francois Audet" To: "Adam Roach" In-Reply-To: <49E7BF9D.10706@nostrum.com> Content-Type: multipart/alternative; boundary="Apple-Mail-1--374692296"; charset="utf-8" thread-index: Acm+7WJdTCp0B1iBRZGKXjhQJL79vg== MIME-Version: 1.0 (iPod Mail 5H11a) Thread-Topic: [sipcore] Call for Consensus: draft-holmberg-sip-keep Date: Thu, 16 Apr 2009 16:45:11 -0700 Cc: SIPCORE Subject: Re: [sipcore] Call for Consensus: draft-holmberg-sip-keep X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Apr 2009 23:45:13 -0000 --Apple-Mail-1--374692296 Content-Type: text/plain; charset=utf-8; format=flowed; delsp=yes Content-Transfer-Encoding: base64 eWVzDQoNCk9uIEFwciAxNiwgMjAwOSwgYXQgMTY6MzEsICJBZGFtIFJvYWNoIiA8YWRhbUBub3N0 cnVtLmNvbT4gd3JvdGU6DQoNCj4gW2FzIGNoYWlyXQ0KPg0KPiBUaGVyZSB3YXMgYWxyZWFkeSBh IHJlcXVlc3QgZm9yIGNvbnNlbnN1cyBhcm91bmQgYWRvcHRpbmcgdGhlICANCj4gZG9jdW1lbnQg ZHJhZnQtaG9sbWJlcmctc2lwLWtlZXAgb24gdGhlIFNJUCB3b3JraW5nIGdyb3VwIG1haWxpbmcg IA0KPiBsaXN0LiBUaGUgY2FsbCB3YXMgZm9yIGFkb3B0aW5nIGl0ICJhcyBhIFdHIGRvY3VtZW50 IGluIFJBSSAoV0cgIA0KPiB0YmQpIi4gVGhlIHNwZWNpZmljIGNhbGwgZm9yIGNvbnNlbnN1cyBj YW4gYmUgZm91bmQgaGVyZToNCj4NCj4gw4IgIDxodHRwOi8vd3d3LmlldGYub3JnL21haWwtYXJj aGl2ZS93ZWIvc2lwL2N1cnJlbnQvbXNnMjcxNDEuaHRtbD4NCj4NCj4gVGhlcmUgd2VyZSAxNSBt ZXNzYWdlcyBpbiBzdXBwb3J0IG9mIGRvaW5nIHNvLCBhbmQgbm8gb2JqZWN0aW9ucy4NCj4NCj4g SSdtIGFza2luZyBhIHJlbGF0ZWQgYnV0IHNsaWdodGx5IGRpZmZlcmVudCBxdWVzdGlvbjogR2l2 ZW4gdGhhdCAgDQo+IFNJUENPUkUgaGFzIGEgY2hhcnRlciBtaWxlc3RvbmUgZm9yICJNZWNoYW5p c20gZm9yIGluZGljYXRpbmcgIA0KPiBzdXBwb3J0IGZvciBrZWVwLWFsaXZlcywiIGRvIHlvdSB0 aGluayB3ZSBzaG91bGQgYWRvcHQgZHJhZnQtIA0KPiBob2xtYmVyZy1zaXAta2VlcCBhcyB0aGUg YmFzaXMgZm9yIGNvbXBsZXRpbmcgdGhpcyBtaWxlc3RvbmU/IEFzICANCj4gYmVmb3JlLCBhIHNp bXBsZSAieWVzIiBpcyBmaW5lOyBob3dldmVyLCBpZiB5b3UgZG9uJ3QgdGhpbmsgd2UgIA0KPiBz aG91bGQgYWRvcHQgdGhpcyBkb2N1bWVudCwgcGxlYXNlIHByb3ZpZGUgcmF0aW9uYWxlLg0KPg0K PiAvYQ0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K PiBzaXBjb3JlIG1haWxpbmcgbGlzdA0KPiBzaXBjb3JlQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2lwY29yZQ0K --Apple-Mail-1--374692296 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: base64 PGh0bWw+PGJvZHkgYmdjb2xvcj0iI0ZGRkZGRiI+PGRpdj55ZXM8YnI+PGJyPk9uIEFwciAxNiwg MjAwOSwgYXQgMTY6MzEsICJBZGFtIFJvYWNoIiAmbHQ7PGEgaHJlZj0ibWFpbHRvOmFkYW1Abm9z dHJ1bS5jb20iPmFkYW1Abm9zdHJ1bS5jb208L2E+PiB3cm90ZTo8YnI+PGJyPjwvZGl2PjxkaXY+ PC9kaXY+PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+PGRpdj4NCg0KW2FzIGNoYWlyXTxicj4NCjxi cj4NClRoZXJlIHdhcyBhbHJlYWR5IGEgcmVxdWVzdCBmb3IgY29uc2Vuc3VzIGFyb3VuZCBhZG9w dGluZyB0aGUgZG9jdW1lbnQNCmRyYWZ0LWhvbG1iZXJnLXNpcC1rZWVwIG9uIHRoZSBTSVAgd29y a2luZyBncm91cCBtYWlsaW5nIGxpc3QuIFRoZSBjYWxsDQp3YXMgZm9yIGFkb3B0aW5nIGl0ICI8 Zm9udCBzaXplPSIyIj5hcyBhIFdHIGRvY3VtZW50IGluIFJBSSAoV0cgdGJkKSIuPC9mb250Pg0K VGhlIHNwZWNpZmljIGNhbGwgZm9yIGNvbnNlbnN1cyBjYW4gYmUgZm91bmQgaGVyZTo8YnI+DQo8 YnI+DQrDgiZuYnNwOyA8YSBjbGFzcz0ibW96LXR4dC1saW5rLXJmYzIzOTZFIiBocmVmPSJodHRw Oi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93ZWIvc2lwL2N1cnJlbnQvbXNnMjcxNDEuaHRt bCI+Jmx0OzxhIGhyZWY9Imh0dHA6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9zaXAv Y3VycmVudC9tc2cyNzE0MS5odG1sIj5odHRwOi8vd3d3LmlldGYub3JnL21haWwtYXJjaGl2ZS93 ZWIvc2lwL2N1cnJlbnQvbXNnMjcxNDEuaHRtbDwvYT4+PC9hPjxicj4NCjxicj4NClRoZXJlIHdl cmUgMTUgbWVzc2FnZXMgaW4gc3VwcG9ydCBvZiBkb2luZyBzbywgYW5kIG5vIG9iamVjdGlvbnMu PGJyPg0KPGJyPg0KSSdtIGFza2luZyBhIHJlbGF0ZWQgYnV0IHNsaWdodGx5IGRpZmZlcmVudCBx dWVzdGlvbjogR2l2ZW4gdGhhdA0KU0lQQ09SRSBoYXMgYSBjaGFydGVyIG1pbGVzdG9uZSBmb3Ig Ik1lY2hhbmlzbSBmb3IgaW5kaWNhdGluZyBzdXBwb3J0DQpmb3Iga2VlcC1hbGl2ZXMsIiBkbyB5 b3UgdGhpbmsgd2Ugc2hvdWxkIGFkb3B0IGRyYWZ0LWhvbG1iZXJnLXNpcC1rZWVwDQphcyB0aGUg YmFzaXMgZm9yIGNvbXBsZXRpbmcgdGhpcyBtaWxlc3RvbmU/IEFzIGJlZm9yZSwgYSBzaW1wbGUg InllcyINCmlzIGZpbmU7IGhvd2V2ZXIsIGlmIHlvdSBkb24ndCB0aGluayB3ZSBzaG91bGQgYWRv cHQgdGhpcyBkb2N1bWVudCwNCnBsZWFzZSBwcm92aWRlIHJhdGlvbmFsZS48YnI+DQo8YnI+DQov YTxicj4NCg0KDQo8L2Rpdj48L2Jsb2NrcXVvdGU+PGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSI+PGRp dj48c3Bhbj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzwv c3Bhbj48YnI+PHNwYW4+c2lwY29yZSBtYWlsaW5nIGxpc3Q8L3NwYW4+PGJyPjxzcGFuPjxhIGhy ZWY9Im1haWx0bzpzaXBjb3JlQGlldGYub3JnIj5zaXBjb3JlQGlldGYub3JnPC9hPjwvc3Bhbj48 YnI+PHNwYW4+PGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9z aXBjb3JlIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NpcGNvcmU8L2E+ PC9zcGFuPjxicj48L2Rpdj48L2Jsb2NrcXVvdGU+PC9ib2R5PjwvaHRtbD4= --Apple-Mail-1--374692296-- From adam@nostrum.com Thu Apr 16 16:50:23 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 73D133A6D34 for ; Thu, 16 Apr 2009 16:50:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.576 X-Spam-Level: X-Spam-Status: No, score=-2.576 tagged_above=-999 required=5 tests=[AWL=0.024, BAYES_00=-2.599, SPF_PASS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ggASQe7GizQF for ; Thu, 16 Apr 2009 16:50:22 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id 20B5F3A6D44 for ; Thu, 16 Apr 2009 16:50:21 -0700 (PDT) Received: from [172.16.3.231] (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id n3GNpVmu032712 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 16 Apr 2009 18:51:31 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <49E7C483.8080400@nostrum.com> Date: Thu, 16 Apr 2009 18:51:31 -0500 From: Adam Roach User-Agent: Postbox 1.0b11 (Macintosh/2009041423) MIME-Version: 1.0 To: "DRAGE, Keith (Keith)" References: <49E7BA8B.7060107@nostrum.com> <28B7C3AA2A7ABA4A841F11217ABE78D6758C605F@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> In-Reply-To: <28B7C3AA2A7ABA4A841F11217ABE78D6758C605F@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Cc: SIPCORE , Hadriel Kaplan Subject: Re: [sipcore] Do we really want to reopen the RAI re-org discussion? (was Re: Call for Consensus: Additional Working Group Items) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Apr 2009 23:50:23 -0000 Keith: I am referring to the following text, which appears in the proposed SIPCORE charter at least as early as February: > Although in general the WG will not work on extensions to SIP, it > may take on some previous work items from the SIP working group > to allow for a smooth transition. /a DRAGE, Keith (Keith) wrote: > Except that the milestones themselves were a decision of the ADs and did not get list discussion. In fact milestones were being added and deleted from the charters even on Monday evening (my time). The charters themselves were part of the RAI reorg discussions, but the milestones were not. So I do not see how a discussion of them can be a reopening. > > You can issue a direction about whether the appropriate place to discuss the SIPCORE milestones that they have been allocated is the the SIPCORE or RAI list, but it does not reopen a discussion. > > I must admit I am a bit bemused by the allocation of the throttling one, because I do remember having a discussion some time back where I asked, if for some reason we were reissuing RFC 3265 would the throttling form part of it, and I was assured in no uncertain terms that it was a totally separate and independent extension. Now if the answer to that had been YES rather than NO, I could understand it being allocated to SIPCORE. > > The target-uri one I do understand, because basically if RFC 3261 was ever reisssued, there is a strong view that History-Info would form part of that reissue. In my view target-uri is part of that scope. However more on that in a separate mail. > > Keith > > > > > > >> -----Original Message----- >> From: sipcore-bounces@ietf.org >> [mailto:sipcore-bounces@ietf.org] On Behalf Of Adam Roach >> Sent: Friday, April 17, 2009 12:09 AM >> To: Eric Burger >> Cc: SIPCORE; Hadriel Kaplan >> Subject: [sipcore] Do we really want to reopen the RAI re-org >> discussion? (was Re: Call for Consensus: Additional Working >> Group Items) >> >> [as chair] >> >> That's a completely different topic. I can't stop you from >> re-opening the discussion of how to handle SIP and SIPPING >> milestones that would otherwise be orphaned, but I will ask >> you to take it elsewhere. The place you would go to re-open >> the RAI re-org discussion is the RAI mailing list. I suspect >> many interested parties would view re-opening that particular >> topic to be unnecessarily disruptive. >> >> /a >> >> Eric Burger wrote: >> >>> And Hadriel is saying they are not Core. >>> >>> On Apr 17, 2009, at 6:39 AM, Adam Roach wrote: >>> >>> >>>> [as chair] >>>> >>>> Hadriel Kaplan wrote: >>>> >>>>>> At 01:26 PM 4/16/2009, Adam Roach wrote: >>>>>> Delivering request-URI and parameters to UAS via proxy (PS) >>>>>> draft-rosenberg-sip-target-uri-delivery >>>>>> [adopted by SIP WG consensus after IETF 73, still waiting for >>>>>> new version] >>>>>> >>>>>> SIP Events throttling mechanism (PS) >>>>>> draft-niemi-sipping-event-throttle >>>>>> [SIPPING WG indicated desire to adopt in as SIP WG >>>>>> >> item at IETF >> >>>>>> 74] >>>>>> >>>>> My vote is to adopt neither in this WG. Neither of them >>>>> >> update nor >> >>>>> replace 3261-3265. >>>>> >>>> To be clear, the question we are asking is not "are these >>>> >> milestones >> >>>> okay" (that discussion has already concluded on the RAI >>>> >> list) -- it >> >>>> is "should we take on these specific documents to satisfy >>>> >> the these >> >>>> two milestones that are already part of the SIPCORE charter." >>>> >>>> /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 drage@alcatel-lucent.com Thu Apr 16 17:03:56 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AA3B43A6990 for ; Thu, 16 Apr 2009 17:03:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.015 X-Spam-Level: X-Spam-Status: No, score=-6.015 tagged_above=-999 required=5 tests=[AWL=0.234, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BfX+m3AfzL1k for ; Thu, 16 Apr 2009 17:03:55 -0700 (PDT) Received: from smail2.alcatel.fr (smail2.alcatel.fr [62.23.212.57]) by core3.amsl.com (Postfix) with ESMTP id CF1E43A6925 for ; Thu, 16 Apr 2009 17:03:53 -0700 (PDT) Received: from FRMRSSXCHHUB04.dc-m.alcatel-lucent.com (FRMRSSXCHHUB04.dc-m.alcatel-lucent.com [135.120.45.64]) by smail2.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id n3H053wQ032315 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 17 Apr 2009 02:05:03 +0200 Received: from FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com ([135.120.45.39]) by FRMRSSXCHHUB04.dc-m.alcatel-lucent.com ([135.120.45.64]) with mapi; Fri, 17 Apr 2009 02:05:03 +0200 From: "DRAGE, Keith (Keith)" To: Mary Barnes , Andrew Allen , "ietf.hanserik@gmail.com" Date: Fri, 17 Apr 2009 02:05:00 +0200 Thread-Topic: [sipcore] Target-uri document as SIPCORE WG document? (was RE:[Sip] SIPCORE -- If you're not subscribed, you're missing stuff Thread-Index: Acm+2VlZABnKJIMzQmy6h7q6thF4/gAAZt8gAACTQZQAACG6sAADxxWw Message-ID: <28B7C3AA2A7ABA4A841F11217ABE78D6758C6062@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> References: <61968779B8AC4C4BAB421D4C12F008C015FEA2B0@XCH47YKF.rim.net> <1ECE0EB50388174790F9694F77522CCF1D7F9F40@zrc2hxm0.corp.nortel.com> In-Reply-To: <1ECE0EB50388174790F9694F77522CCF1D7F9F40@zrc2hxm0.corp.nortel.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.57 on 155.132.188.80 Cc: "sipcore@ietf.org" Subject: Re: [sipcore] Target-uri document as SIPCORE WG document? (was RE:[Sip] SIPCORE -- If you're not subscribed, you're missing stuff X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Apr 2009 00:03:56 -0000 I haven't been back and listened to the archives, but my intent from the ch= air of the SIP WG meeting at IETF 74 was that both documents move forward w= ith their existing status and we would make a decision after some more revi= ew of the contents of the individual documents as to whether material from = one moved into the other. Clearly http://www.ietf.org/internet-drafts/draft-barnes-sip-rfc4244bis-00.= txt is an author draft at the moment, and it can have whatever content the = author wishes. As regards draft-rosenberg-sip-target-uri-delivery in IETF 72 (Dublin) we e= ssentially had a discussion of a set of slides rather than a draft, and my = personal notes say that Jonathan was asked to document his slides as an aut= hor draft. In IETF 73 we did discuss draft-rosenberg-sip-target-uri-deliver= y-00.txt and agreed to adopt it as a working group item. After IETF 73 the = document essentially disappeared off the WG radar, and I have at least two = concerns as to how we got to the -01 document which I will discuss with the= chairs. regards Keith ________________________________ From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behalf= Of Mary Barnes Sent: Thursday, April 16, 2009 11:04 PM To: Andrew Allen; ietf.hanserik@gmail.com Cc: sipcore@ietf.org Subject: Re: [sipcore] Target-uri document as SIPCORE WG document? (was RE= :[Sip] SIPCORE -- If you're not subscribed, you're missing stuff =09 =09 A few comments below [MB].=20 ________________________________ From: Andrew Allen [mailto:aallen@rim.com]=20 Sent: Thursday, April 16, 2009 4:50 PM To: Barnes, Mary (RICH2:AR00); ietf.hanserik@gmail.com Cc: sipcore@ietf.org Subject: Re: [sipcore] Target-uri document as SIPCORE WG document? (was RE= :[Sip] SIPCORE -- If you're not subscribed, you're missing stuff =09 =09 =09 My understanding was that we would move forward with both drafts as WG ite= ms. =09 My understanding was that in Dublin Target-uri was adopted as a SIP WG ite= m. I don't want to see 4244bis become a dependency for the target-uri work = which is urgently needed to solve some GRUU related issues.=20 [MB] Per my original comments below, the changes for a target-uri solution= based on 4244 is actually more work than putting the normative functionali= ty in 4244bis - that's because you still need to address security, privacy,= how it is processed by a UAC, Proxy and UAS. You would then need duplicate= text to set the context, etc. and that text would be identical to what's i= n 4244 OR you'd be breaking existing implementations and there are some of = those. Now, we did have one reasonable suggestion as to adding a recommenda= tion that the Privacy not be applied to the entire message as that limits p= roxy functionality - that's important for target-uri, but it's also likely = an oversight in the original 4244. [/MB] =20 =09 If 4244bis is ready when target-uri is then we can talk about rolling the = two into one but I have concerns that 4244bis will take considerably longer= than target-uri based on the discussion in San Fran. =20 [MB] Nope - as I noted earlier, I think the discussion was confounded beca= use people were talking about changes to 4244bis (History-Info) that were w= ell beyond what is required for target-uri - i.e., paring down the function= ality to only collect the desired entries, which doesn't save a bit of work= because you still have to recognize the conditions under which you drop th= e entries. Please listen to Francois' response to Hadriel's suggestion in = the audio - it's towards the end. Also, the same security issues apply - wh= en we completed 4244, the security section was carefully crafted based on s= ecurity thoughts at the time. Those have changed (obviously) and if they ar= e problematic in 4244bis, they would be a problem for the target-uri usage = of 4244, which has the same security requirements as core 4244. [/MB] =09 Target-uri has been needed really for GRUU for more then 2 years and is fa= irly straightforward. I don't think we should risk delaying that work waiti= ng for 4244bis which seems to contain a number of issues we don't have cons= ensus on yet.=20 [MB] The other changes to 4244bis are minor as compared to the normative f= unctionality that needs to be added to the document to support target-uri. = Please look at the diff. I also don't see the GRUU dependency - can you pl= ease clarify? I know GRUU is waiting for Outbound (I promise I will give u= p if 4244bis reaches a point where it is taking longer to finish than Outbo= und) and that the gruu-reg-event pkg is waiting for GRUU. [/MB]=20 =09 That was my understanding of the approach we determined in San Francisco. =09 ________________________________ From: sipcore-bounces@ietf.org =20 To: Hans Erik van Elburg =20 Cc: sipcore@ietf.org =20 Sent: Thu Apr 16 17:34:57 2009 Subject: Re: [sipcore] Target-uri document as SIPCORE WG document? (was RE= :[Sip] SIPCORE -- If you're not subscribed, you're missing stuff=20 =09 No - the discussion for 4244(bis) (extracted below) was entirely in the c= ontext of the discussion for the target-uri document. You can go back and l= isten to the audio to verify that. And, I've stated long before IETF-73 th= at it would be fairly straightforward to update 4244 to accomodate the targ= et-uri requirements and while we were doing that, there were a few other fi= xes we could do.=20 =20 Mary.=20 ________________________________ From: Hans Erik van Elburg [mailto:ietf.hanserik@gmail.com]=20 Sent: Thursday, April 16, 2009 4:22 PM To: Barnes, Mary (RICH2:AR00) Cc: Dean Willis; sipcore@ietf.org Subject: Re: [sipcore] Target-uri document as SIPCORE WG document? (was RE= : [Sip] SIPCORE -- If you're not subscribed, you're missing stuff =09 =09 Hi Mary, =09 I believe that in the absence of consensus as the minutes correctly state,= the the target-uri document should remain the WG document for the target-u= ri deliverable. =09 4424bis has another purpose, namely to fix the 4424. If at a certain momen= t in time it turns out that 4424bis is the appropriate document to contain = normative text for target uri delivery then we can always decide to do so. = At this stage it is to early to take that decision, given the confused stat= e of the target-uri discussion. =09 /Hans Erik van Elburg =09 =09 =09 On Thu, Apr 16, 2009 at 10:02 PM, Mary Barnes wro= te: =09 I'm suggesting to change the decision from IETF-73 and accept the more recent realization that including normative text in another document rather than 4244bis will be fraught with error and I can't see how that is a good idea from a development perspective - you can't just implement the target-uri document. =09 Now, I don't have a problem if folks can accept that the target-uri document might change such that the normative functionality is in 4244bis. And, this was consensus from IETF-73 per those minutes: "Issue: Normative behavior update for RFC 4244 =09 Consensus noted to revise RFC 4244, and fix some other known problems with it at teh same time. MAry Barnes volunteered to edit the document." =09 So, there is a conflict in terms of accepting target-uri document as the only deliverable for that milestone in the IETF-73 meeting. =09 Mary. =09 =09 -----Original Message----- From: Dean Willis [mailto:dean.willis@softarmor.com] Sent: Thursday, April 16, 2009 2:36 PM To: Barnes, Mary (RICH2:AR00) Cc: sipcore@ietf.org Subject: Re: [sipcore] [Sip] SIPCORE -- If you're not subscribed, you're missing stuff =09 =09 On Apr 16, 2009, at 2:27 PM, Mary Barnes wrote: =09 > I have an issue with the target-uri document being proposed as the WG > document for the target-uri deliverable. This was not the consensus in =09 > SF per my recollection (which may be biased) nor per the SIP WG > minutes: > http://www.ietf.org/proceedings/09mar/minutes/sip.html > > Which state: > "Issue: Progress 4244bis, target-uri draft, or both? > In the absence of a clear consensus, the chairs proposed that both > documents proceed and we'll hope that further discussion gives us a > consensus." > > Now, I realize that there are now new chairs, but I don't think that > should change the WG consensus from the SIP WG session. =09 However, the minutes from IETF 73 read: =09 Topic: URI and Parameter Delivery Led by Jonaathan Rosenberg Slides presented http://tools.ietf.org/id/draft-rosenberg-sip-target-uri-delivery-00.txt =09 ... =09 Poll: Shall WG adopt this draft towards our charter deliverable on the topic? Chairs reported a strong consensus to do so. So which WG consensus of which SIP WG session do you not want to change? =09 =09 =09 > > It was my understanding from the minutes that the discussion was to > continue as to whether we would merge the two documents or agree one > or the other as a WG deliverable. > =09 =09 That's also consistent with my notes from SIP at 74. =09 My best guess is that RFC 4244bis goes forward, and that target-uri- delivery turns into a "How to use H-I to meet the URI delivery use cases" document. =09 -- Dean =09 =09 =09 =09 _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore =09 ---------------------------------------------------------------------=20 This transmission (including any attachments) may contain confidential inf= ormation, privileged material (including material protected by the solicito= r-client or other applicable privileges), or constitute non-public informat= ion. Any use of this information by anyone other than the intended recipien= t is prohibited. If you have received this transmission in error, please im= mediately reply to the sender and delete this information from your system.= Use, dissemination, distribution, or reproduction of this transmission by = unintended recipients is not authorized and may be unlawful.=20 From BPenfield@acmepacket.com Thu Apr 16 17:08:53 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CE7123A6D34 for ; Thu, 16 Apr 2009 17:08:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BXvd8wo+rHtt for ; Thu, 16 Apr 2009 17:08:53 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id E75BC3A6A68 for ; Thu, 16 Apr 2009 17:08:52 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.340.0; Thu, 16 Apr 2009 20:10:05 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Thu, 16 Apr 2009 20:10:05 -0400 From: Bob Penfield To: Adam Roach , SIPCORE Date: Thu, 16 Apr 2009 20:10:04 -0400 Thread-Topic: [sipcore] Call for Consensus: draft-holmberg-sip-keep Thread-Index: Acm+62pmy5HoS0p8T2qmy3tNmBNOgwABW66A Message-ID: References: <49E7BF9D.10706@nostrum.com> In-Reply-To: <49E7BF9D.10706@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_E6C2E8958BA59A4FB960963D475F7AC3151644FA8Fmail_" MIME-Version: 1.0 Subject: Re: [sipcore] Call for Consensus: draft-holmberg-sip-keep X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Apr 2009 00:08:53 -0000 --_000_E6C2E8958BA59A4FB960963D475F7AC3151644FA8Fmail_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable yes ________________________________ From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behalf = Of Adam Roach Sent: Thursday, April 16, 2009 7:31 PM To: SIPCORE Subject: [sipcore] Call for Consensus: draft-holmberg-sip-keep [as chair] There was already a request for consensus around adopting the document draf= t-holmberg-sip-keep on the SIP working group mailing list. The call was for= adopting it "as a WG document in RAI (WG tbd)". The specific call for cons= ensus can be found here: There were 15 messages in support of doing so, and no objections. I'm asking a related but slightly different question: Given that SIPCORE ha= s a charter milestone for "Mechanism for indicating support for keep-alives= ," do you think we should adopt draft-holmberg-sip-keep as the basis for co= mpleting this milestone? As before, a simple "yes" is fine; however, if you= don't think we should adopt this document, please provide rationale. /a --_000_E6C2E8958BA59A4FB960963D475F7AC3151644FA8Fmail_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
yes

From: sipcore-bounces@ietf.org=20 [mailto:sipcore-bounces@ietf.org] On Behalf Of Adam Roach
Sent= :=20 Thursday, April 16, 2009 7:31 PM
To: SIPCORE
Subject:=20 [sipcore] Call for Consensus: draft-holmberg-sip-keep

[as chair]

There was already a request for consensus arou= nd=20 adopting the document draft-holmberg-sip-keep on the SIP working group mail= ing=20 list. The call was for adopting it "as a WG document in RAI = (WG=20 tbd)". The specific call for consensus can be found here:

&nb= sp;=20 <= ;http://www.ietf.org/mail-archive/web/sip/current/msg27141.html>
=
There=20 were 15 messages in support of doing so, and no objections.

I'm aski= ng a=20 related but slightly different question: Given that SIPCORE has a charter=20 milestone for "Mechanism for indicating support for keep-alives," do you th= ink=20 we should adopt draft-holmberg-sip-keep as the basis for completing this=20 milestone? As before, a simple "yes" is fine; however, if you don't think w= e=20 should adopt this document, please provide=20 rationale.

/a
--_000_E6C2E8958BA59A4FB960963D475F7AC3151644FA8Fmail_-- From theo@crazygreek.co.uk Thu Apr 16 17:18:55 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 862163A6DBC for ; Thu, 16 Apr 2009 17:18:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.84 X-Spam-Level: X-Spam-Status: No, score=-5.84 tagged_above=-999 required=5 tests=[AWL=0.137, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QOcOW2cpOLCS for ; Thu, 16 Apr 2009 17:18:54 -0700 (PDT) Received: from exprod7og117.obsmtp.com (exprod7og117.obsmtp.com [64.18.2.6]) by core3.amsl.com (Postfix) with SMTP id 607DE3A6858 for ; Thu, 16 Apr 2009 17:18:54 -0700 (PDT) Received: from source ([72.14.220.152]) by exprod7ob117.postini.com ([64.18.6.12]) with SMTP ID DSNKSefLN4DsZqf/VxrfMarmUFAF/pU3rSBO@postini.com; Thu, 16 Apr 2009 17:20:08 PDT Received: by fg-out-1718.google.com with SMTP id l27so16194fgb.3 for ; Thu, 16 Apr 2009 17:20:07 -0700 (PDT) MIME-Version: 1.0 Received: by 10.86.26.11 with SMTP id 11mr982940fgz.4.1239927607118; Thu, 16 Apr 2009 17:20:07 -0700 (PDT) In-Reply-To: <49E7BF9D.10706@nostrum.com> References: <49E7BF9D.10706@nostrum.com> From: Theo Zourzouvillys Date: Fri, 17 Apr 2009 01:19:52 +0100 Message-ID: <167dfb9b0904161719p73b05ecv542179c532a6a7ec@mail.gmail.com> To: Adam Roach Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: SIPCORE Subject: Re: [sipcore] Call for Consensus: draft-holmberg-sip-keep X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Apr 2009 00:18:55 -0000 On Fri, Apr 17, 2009 at 12:30 AM, Adam Roach wrote: > Given that SIPCORE has a charter milestone for "Mechanism for indicating > support for keep-alives," do you think we should adopt > draft-holmberg-sip-keep as the basis for completing this milestone? yes! ~ Theo From aallen@rim.com Thu Apr 16 17:26:13 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DB0503A691B for ; Thu, 16 Apr 2009 17:26:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.684 X-Spam-Level: X-Spam-Status: No, score=-5.684 tagged_above=-999 required=5 tests=[AWL=0.414, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BAD_LINEBREAK=0.5, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L6AF6zm66rd5 for ; Thu, 16 Apr 2009 17:26:11 -0700 (PDT) Received: from mhs03ykf.rim.net (mhs03ykf.rim.net [216.9.243.80]) by core3.amsl.com (Postfix) with ESMTP id 477713A68D9 for ; Thu, 16 Apr 2009 17:26:11 -0700 (PDT) Received: from mhs03ykf.rim.net (unknown [127.0.0.1]) by mhs03ykf.rim.net (Symantec Brightmail Gateway) with ESMTP id BE77B58855; Thu, 16 Apr 2009 20:27:23 -0400 (EDT) X-AuditID: 0a401fcb-a79afbb000002ba2-08-49e7ccebf032 Received: from XCH20YKF.rim.net (unknown [10.102.100.35]) by mhs03ykf.rim.net (Symantec Mail Security) with ESMTP id 58973587A0; Thu, 16 Apr 2009 20:27:23 -0400 (EDT) Received: from XCH47YKF.rim.net ([10.64.31.217]) by XCH20YKF.rim.net with Microsoft SMTPSVC(5.0.2195.6713); Thu, 16 Apr 2009 20:27:23 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C9BEF3.46701461" Date: Thu, 16 Apr 2009 20:27:22 -0400 Message-ID: <61968779B8AC4C4BAB421D4C12F008C015FEA2B1@XCH47YKF.rim.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] Target-uri document as SIPCORE WG document? (was RE:[Sip] SIPCORE -- If you're not subscribed, you're missing stuff Thread-Index: Acm+2VlZABnKJIMzQmy6h7q6thF4/gAAZt8gAACTQZQAACG6sAAFX0/W From: "Andrew Allen" To: , X-OriginalArrivalTime: 17 Apr 2009 00:27:23.0028 (UTC) FILETIME=[46C2ED40:01C9BEF3] X-Tracking: ONC3m79J7f57zp0jFVtWxPxr7v2VYI3kBbb X-Brightmail-Tracker: AAAAAQ5kh/8= Cc: sipcore@ietf.org Subject: Re: [sipcore] Target-uri document as SIPCORE WG document? (was RE:[Sip] SIPCORE -- If you're not subscribed, you're missing stuff X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Apr 2009 00:26:13 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9BEF3.46701461 Content-Type: text/plain; charset="utf-8" content-transfer-encoding: base64 DQpNeSB1bmRlcnN0YW5kaW5nIG9mIHRoZSBvdXRjb21lIGluIFNhbiBGcmFuY2lzY28gd2Fz IHRoYXQgdGFyZ2V0LXVyaSB3b3VsZCB1cGRhdGUgNDI0NCBhbmQgNDI0NGJpcyB3b3VsZCBi ZSB3b3JrZWQgb24gaW4gcGFyYWxsZWwgYW5kIHBvdGVudGlhbGx5IG9ic29sZXRlIGJvdGgg NDI0NCBhbmQgdGFyZ2V0LXVyaS4gDQoNCldoYXRldmVyIGlzIGRldmVsb3BlZCBmb3IgdGFy Z2V0LXVyaSBvdWdodCB0byBiZSBhYmxlIHRvIGJlIGluY29ycG9yYXRlZCBpbiA0MjQ0Ymlz LiBJZiA0MjQ0IHByb2dyZXNzZXMgd2VsbCB0aGVuIHRhcmdldC11cmkgbWF5IG5vdCBuZWVk IHVsdGltYXRlbHkgdG8gYmUgcHVibGlzaGVkIHNlcGFyYXRlbHkuIA0KDQpJIGFtIGFmcmFp ZCB0aGF0IHRoZSBzZWN1cml0eSBxdWVzdGlvbiB0byBiZSBhZGRyZXNzZWQgYnkgNDI0NGJp cyBpcyBhIGJpZyBjYW4gb2Ygd29ybXMgdGhhdCBpcyBsaWtlbHkgdG8gYmUgYSBsb25nIGRp c2N1c3Npb24uIElzIHRoZXJlIGEgcmVhc29uIHdoeSB0YXJnZXQtdXJpIGNhbid0IHByb2dy ZXNzIHVuZGVyIHRoZSBjdXJyZW50IEhpc3RvcnktSW5mbyBzZWN1cml0eSBmcmFtZXdvcms/ IElzIHRoZSBzZWN1cml0eSBzb2x1dGlvbiBmb3IgNDI0NCBhY3R1YWxseSB0ZWNobmljYWxs eSBicm9rZW4gb3IgaXMgaXQganVzdCB0aGF0IHBlb3BsZSBkb24ndCBpbXBsZW1lbnQgaXQ/ DQoNClRoZXJlIGlzIG5vdCBhIGRyYWZ0IGRlcGVuZGVjeSBvbiB0YXJnZXQtdXJpIGZvciBH UlVVIGJ1dCBpdCB3YXMgY2xlYXJseSBpZGVudGlmaWVkIGR1cmluZyBHUlVVIGRldmVsb3Bt ZW50IHRoYXQgYSBsb3Qgb2YgdXNlIGNhc2VzIGZvciBHUlVVIHJlYWxseSBuZWVkIHRvIGtu b3cgdGhhdCB0aGUgUmVxdWVzdCB3YXMgYWRkcmVzc2VkIHRvIGEgcGFydGljdWxhciBHUlVV IGFuZCB3aXRob3V0IHRhcmdldC11cmkgdGhhdCBmdW5jdGlvbmFsaXR5IGNhbm5vdCBiZSBh Y2hpZXZlZC4gDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCg0KRnJv bTogTWFyeSBCYXJuZXMgPG1hcnkuYmFybmVzQG5vcnRlbC5jb20+IA0KVG86IEFuZHJldyBB bGxlbjsgaWV0Zi5oYW5zZXJpa0BnbWFpbC5jb20gPGlldGYuaGFuc2VyaWtAZ21haWwuY29t PiANCkNjOiBzaXBjb3JlQGlldGYub3JnIDxzaXBjb3JlQGlldGYub3JnPiANClNlbnQ6IFRo dSBBcHIgMTYgMTg6MDM6NDIgMjAwOQ0KU3ViamVjdDogUkU6IFtzaXBjb3JlXSBUYXJnZXQt dXJpIGRvY3VtZW50IGFzIFNJUENPUkUgV0cgZG9jdW1lbnQ/ICh3YXMgUkU6W1NpcF0gU0lQ Q09SRSAtLSBJZiB5b3UncmUgbm90IHN1YnNjcmliZWQsIHlvdSdyZSBtaXNzaW5nIHN0dWZm IA0KDQoNCkEgZmV3IGNvbW1lbnRzIGJlbG93IFtNQl0uIA0KDQpfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KDQpGcm9tOiBBbmRyZXcgQWxsZW4gW21haWx0bzphYWxsZW5A cmltLmNvbV0gDQpTZW50OiBUaHVyc2RheSwgQXByaWwgMTYsIDIwMDkgNDo1MCBQTQ0KVG86 IEJhcm5lcywgTWFyeSAoUklDSDI6QVIwMCk7IGlldGYuaGFuc2VyaWtAZ21haWwuY29tDQpD Yzogc2lwY29yZUBpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtzaXBjb3JlXSBUYXJnZXQtdXJp IGRvY3VtZW50IGFzIFNJUENPUkUgV0cgZG9jdW1lbnQ/ICh3YXMgUkU6W1NpcF0gU0lQQ09S RSAtLSBJZiB5b3UncmUgbm90IHN1YnNjcmliZWQsIHlvdSdyZSBtaXNzaW5nIHN0dWZmDQoN Cg0KDQpNeSB1bmRlcnN0YW5kaW5nIHdhcyB0aGF0IHdlIHdvdWxkIG1vdmUgZm9yd2FyZCB3 aXRoIGJvdGggZHJhZnRzIGFzIFdHIGl0ZW1zLg0KDQpNeSB1bmRlcnN0YW5kaW5nIHdhcyB0 aGF0IGluIER1YmxpbiBUYXJnZXQtdXJpIHdhcyBhZG9wdGVkIGFzIGEgU0lQIFdHIGl0ZW0u IEkgZG9uJ3Qgd2FudCB0byBzZWUgNDI0NGJpcyBiZWNvbWUgYSBkZXBlbmRlbmN5IGZvciB0 aGUgdGFyZ2V0LXVyaSB3b3JrIHdoaWNoIGlzIHVyZ2VudGx5IG5lZWRlZCB0byBzb2x2ZSBz b21lIEdSVVUgcmVsYXRlZCBpc3N1ZXMuIA0KDQpbTUJdIFBlciBteSBvcmlnaW5hbCBjb21t ZW50cyBiZWxvdywgdGhlIGNoYW5nZXMgZm9yIGEgdGFyZ2V0LXVyaSBzb2x1dGlvbiBiYXNl ZCBvbiA0MjQ0IGlzIGFjdHVhbGx5IG1vcmUgd29yayB0aGFuIHB1dHRpbmcgdGhlIG5vcm1h dGl2ZSBmdW5jdGlvbmFsaXR5IGluIDQyNDRiaXMgLSB0aGF0J3MgYmVjYXVzZSB5b3Ugc3Rp bGwgbmVlZCB0byBhZGRyZXNzIHNlY3VyaXR5LCBwcml2YWN5LCBob3cgaXQgaXMgcHJvY2Vz c2VkIGJ5IGEgVUFDLCBQcm94eSBhbmQgVUFTLiBZb3Ugd291bGQgdGhlbiBuZWVkIGR1cGxp Y2F0ZSB0ZXh0IHRvIHNldCB0aGUgY29udGV4dCwgZXRjLiBhbmQgdGhhdCB0ZXh0IHdvdWxk IGJlIGlkZW50aWNhbCB0byB3aGF0J3MgaW4gNDI0NCBPUiB5b3UnZCBiZSBicmVha2luZyBl eGlzdGluZyBpbXBsZW1lbnRhdGlvbnMgYW5kIHRoZXJlIGFyZSBzb21lIG9mIHRob3NlLiBO b3csIHdlIGRpZCBoYXZlIG9uZSByZWFzb25hYmxlIHN1Z2dlc3Rpb24gYXMgdG8gYWRkaW5n IGEgcmVjb21tZW5kYXRpb24gdGhhdCB0aGUgUHJpdmFjeSBub3QgYmUgYXBwbGllZCB0byB0 aGUgZW50aXJlIG1lc3NhZ2UgYXMgdGhhdCBsaW1pdHMgcHJveHkgZnVuY3Rpb25hbGl0eSAt IHRoYXQncyBpbXBvcnRhbnQgZm9yIHRhcmdldC11cmksIGJ1dCBpdCdzIGFsc28gbGlrZWx5 IGFuIG92ZXJzaWdodCBpbiB0aGUgb3JpZ2luYWwgNDI0NC4gWy9NQl0gIA0KDQpJZiA0MjQ0 YmlzIGlzIHJlYWR5IHdoZW4gdGFyZ2V0LXVyaSBpcyB0aGVuIHdlIGNhbiB0YWxrIGFib3V0 IHJvbGxpbmcgdGhlIHR3byBpbnRvIG9uZSBidXQgSSBoYXZlIGNvbmNlcm5zIHRoYXQgNDI0 NGJpcyB3aWxsIHRha2UgY29uc2lkZXJhYmx5IGxvbmdlciB0aGFuIHRhcmdldC11cmkgYmFz ZWQgb24gdGhlIGRpc2N1c3Npb24gaW4gU2FuIEZyYW4uICANCg0KW01CXSBOb3BlIC0gYXMg SSBub3RlZCBlYXJsaWVyLCBJIHRoaW5rIHRoZSBkaXNjdXNzaW9uIHdhcyBjb25mb3VuZGVk IGJlY2F1c2UgcGVvcGxlIHdlcmUgdGFsa2luZyBhYm91dCBjaGFuZ2VzIHRvIDQyNDRiaXMg KEhpc3RvcnktSW5mbykgdGhhdCB3ZXJlIHdlbGwgYmV5b25kIHdoYXQgaXMgcmVxdWlyZWQg Zm9yIHRhcmdldC11cmkgLSBpLmUuLCBwYXJpbmcgZG93biB0aGUgZnVuY3Rpb25hbGl0eSB0 byBvbmx5IGNvbGxlY3QgdGhlIGRlc2lyZWQgZW50cmllcywgd2hpY2ggZG9lc24ndCBzYXZl IGEgYml0IG9mIHdvcmsgYmVjYXVzZSB5b3Ugc3RpbGwgaGF2ZSB0byByZWNvZ25pemUgdGhl IGNvbmRpdGlvbnMgdW5kZXIgd2hpY2ggeW91IGRyb3AgdGhlIGVudHJpZXMuICBQbGVhc2Ug bGlzdGVuIHRvIEZyYW5jb2lzJyByZXNwb25zZSB0byBIYWRyaWVsJ3Mgc3VnZ2VzdGlvbiBp biB0aGUgYXVkaW8gLSBpdCdzIHRvd2FyZHMgdGhlIGVuZC4gQWxzbywgdGhlIHNhbWUgc2Vj dXJpdHkgaXNzdWVzIGFwcGx5IC0gd2hlbiB3ZSBjb21wbGV0ZWQgNDI0NCwgdGhlIHNlY3Vy aXR5IHNlY3Rpb24gd2FzIGNhcmVmdWxseSBjcmFmdGVkIGJhc2VkIG9uIHNlY3VyaXR5IHRo b3VnaHRzIGF0IHRoZSB0aW1lLiBUaG9zZSBoYXZlIGNoYW5nZWQgKG9idmlvdXNseSkgYW5k IGlmIHRoZXkgYXJlIHByb2JsZW1hdGljIGluIDQyNDRiaXMsIHRoZXkgd291bGQgYmUgYSBw cm9ibGVtIGZvciB0aGUgdGFyZ2V0LXVyaSB1c2FnZSBvZiA0MjQ0LCB3aGljaCBoYXMgdGhl IHNhbWUgc2VjdXJpdHkgcmVxdWlyZW1lbnRzIGFzIGNvcmUgNDI0NC4gIFsvTUJdDQoNClRh cmdldC11cmkgaGFzIGJlZW4gbmVlZGVkIHJlYWxseSBmb3IgR1JVVSBmb3IgbW9yZSB0aGVu IDIgeWVhcnMgYW5kIGlzIGZhaXJseSBzdHJhaWdodGZvcndhcmQuIEkgZG9uJ3QgdGhpbmsg d2Ugc2hvdWxkIHJpc2sgZGVsYXlpbmcgdGhhdCB3b3JrIHdhaXRpbmcgZm9yIDQyNDRiaXMg d2hpY2ggc2VlbXMgdG8gY29udGFpbiBhIG51bWJlciBvZiBpc3N1ZXMgd2UgZG9uJ3QgaGF2 ZSBjb25zZW5zdXMgb24geWV0LiANCg0KW01CXSBUaGUgb3RoZXIgY2hhbmdlcyB0byA0MjQ0 YmlzIGFyZSBtaW5vciBhcyBjb21wYXJlZCB0byB0aGUgbm9ybWF0aXZlIGZ1bmN0aW9uYWxp dHkgdGhhdCBuZWVkcyB0byBiZSBhZGRlZCB0byB0aGUgZG9jdW1lbnQgdG8gc3VwcG9ydCB0 YXJnZXQtdXJpLiBQbGVhc2UgbG9vayBhdCB0aGUgZGlmZi4gIEkgYWxzbyBkb24ndCBzZWUg dGhlIEdSVVUgZGVwZW5kZW5jeSAtIGNhbiB5b3UgcGxlYXNlIGNsYXJpZnk/ICBJIGtub3cg R1JVVSBpcyB3YWl0aW5nIGZvciBPdXRib3VuZCAoSSBwcm9taXNlIEkgd2lsbCBnaXZlIHVw IGlmIDQyNDRiaXMgcmVhY2hlcyBhIHBvaW50IHdoZXJlIGl0IGlzIHRha2luZyBsb25nZXIg dG8gZmluaXNoIHRoYW4gT3V0Ym91bmQpIGFuZCB0aGF0IHRoZSBncnV1LXJlZy1ldmVudCBw a2cgaXMgd2FpdGluZyBmb3IgR1JVVS4gIFsvTUJdIA0KDQpUaGF0IHdhcyBteSB1bmRlcnN0 YW5kaW5nIG9mIHRoZSBhcHByb2FjaCB3ZSBkZXRlcm1pbmVkIGluIFNhbiBGcmFuY2lzY28u DQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCg0KRnJvbTogc2lwY29y ZS1ib3VuY2VzQGlldGYub3JnIDxzaXBjb3JlLWJvdW5jZXNAaWV0Zi5vcmc+IA0KVG86IEhh bnMgRXJpayB2YW4gRWxidXJnIDxpZXRmLmhhbnNlcmlrQGdtYWlsLmNvbT4gDQpDYzogc2lw Y29yZUBpZXRmLm9yZyA8c2lwY29yZUBpZXRmLm9yZz4gDQpTZW50OiBUaHUgQXByIDE2IDE3 OjM0OjU3IDIwMDkNClN1YmplY3Q6IFJlOiBbc2lwY29yZV0gVGFyZ2V0LXVyaSBkb2N1bWVu dCBhcyBTSVBDT1JFIFdHIGRvY3VtZW50PyAod2FzIFJFOltTaXBdIFNJUENPUkUgLS0gSWYg eW91J3JlIG5vdCBzdWJzY3JpYmVkLCB5b3UncmUgbWlzc2luZyBzdHVmZiANCg0KDQpObyAt IHRoZSBkaXNjdXNzaW9uIGZvciA0MjQ0KGJpcykgKGV4dHJhY3RlZCBiZWxvdykgd2FzIGVu dGlyZWx5IGluIHRoZSBjb250ZXh0IG9mIHRoZSBkaXNjdXNzaW9uIGZvciB0aGUgdGFyZ2V0 LXVyaSBkb2N1bWVudC4gWW91IGNhbiBnbyBiYWNrIGFuZCBsaXN0ZW4gdG8gdGhlIGF1ZGlv IHRvIHZlcmlmeSB0aGF0LiAgQW5kLCBJJ3ZlIHN0YXRlZCBsb25nIGJlZm9yZSBJRVRGLTcz IHRoYXQgaXQgd291bGQgYmUgZmFpcmx5IHN0cmFpZ2h0Zm9yd2FyZCB0byB1cGRhdGUgNDI0 NCB0byBhY2NvbW9kYXRlIHRoZSB0YXJnZXQtdXJpIHJlcXVpcmVtZW50cyBhbmQgd2hpbGUg d2Ugd2VyZSBkb2luZyB0aGF0LCB0aGVyZSB3ZXJlIGEgZmV3IG90aGVyIGZpeGVzIHdlIGNv dWxkIGRvLiANCiANCk1hcnkuIA0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0KDQpGcm9tOiBIYW5zIEVyaWsgdmFuIEVsYnVyZyBbbWFpbHRvOmlldGYuaGFuc2VyaWtA Z21haWwuY29tXSANClNlbnQ6IFRodXJzZGF5LCBBcHJpbCAxNiwgMjAwOSA0OjIyIFBNDQpU bzogQmFybmVzLCBNYXJ5IChSSUNIMjpBUjAwKQ0KQ2M6IERlYW4gV2lsbGlzOyBzaXBjb3Jl QGlldGYub3JnDQpTdWJqZWN0OiBSZTogW3NpcGNvcmVdIFRhcmdldC11cmkgZG9jdW1lbnQg YXMgU0lQQ09SRSBXRyBkb2N1bWVudD8gKHdhcyBSRTogW1NpcF0gU0lQQ09SRSAtLSBJZiB5 b3UncmUgbm90IHN1YnNjcmliZWQsIHlvdSdyZSBtaXNzaW5nIHN0dWZmDQoNCg0KSGkgTWFy eSwNCg0KSSBiZWxpZXZlIHRoYXQgaW4gdGhlIGFic2VuY2Ugb2YgY29uc2Vuc3VzIGFzIHRo ZSBtaW51dGVzIGNvcnJlY3RseSBzdGF0ZSwgdGhlIHRoZSB0YXJnZXQtdXJpIGRvY3VtZW50 IHNob3VsZCByZW1haW4gdGhlIFdHIGRvY3VtZW50IGZvciB0aGUgdGFyZ2V0LXVyaSBkZWxp dmVyYWJsZS4NCg0KNDQyNGJpcyBoYXMgYW5vdGhlciBwdXJwb3NlLCBuYW1lbHkgdG8gZml4 IHRoZSA0NDI0LiBJZiBhdCBhIGNlcnRhaW4gbW9tZW50IGluIHRpbWUgaXQgdHVybnMgb3V0 IHRoYXQgNDQyNGJpcyBpcyB0aGUgYXBwcm9wcmlhdGUgZG9jdW1lbnQgdG8gY29udGFpbiBu b3JtYXRpdmUgdGV4dCBmb3IgdGFyZ2V0IHVyaSBkZWxpdmVyeSB0aGVuIHdlIGNhbiBhbHdh eXMgZGVjaWRlIHRvIGRvIHNvLiBBdCB0aGlzIHN0YWdlIGl0IGlzIHRvIGVhcmx5IHRvIHRh a2UgdGhhdCBkZWNpc2lvbiwgZ2l2ZW4gdGhlIGNvbmZ1c2VkIHN0YXRlIG9mIHRoZSB0YXJn ZXQtdXJpIGRpc2N1c3Npb24uDQoNCi9IYW5zIEVyaWsgdmFuIEVsYnVyZw0KDQoNCg0KT24g VGh1LCBBcHIgMTYsIDIwMDkgYXQgMTA6MDIgUE0sIE1hcnkgQmFybmVzIDxtYXJ5LmJhcm5l c0Bub3J0ZWwuY29tPiB3cm90ZToNCg0KDQoJSSdtIHN1Z2dlc3RpbmcgdG8gY2hhbmdlIHRo ZSBkZWNpc2lvbiBmcm9tIElFVEYtNzMgYW5kIGFjY2VwdCB0aGUgbW9yZQ0KCXJlY2VudCBy ZWFsaXphdGlvbiB0aGF0IGluY2x1ZGluZyBub3JtYXRpdmUgdGV4dCBpbiBhbm90aGVyIGRv Y3VtZW50DQoJcmF0aGVyIHRoYW4gNDI0NGJpcyB3aWxsIGJlIGZyYXVnaHQgd2l0aCBlcnJv ciBhbmQgSSBjYW4ndCBzZWUgaG93IHRoYXQNCglpcyBhIGdvb2QgaWRlYSBmcm9tIGEgZGV2 ZWxvcG1lbnQgcGVyc3BlY3RpdmUgLSB5b3UgY2FuJ3QganVzdCBpbXBsZW1lbnQNCgl0aGUg dGFyZ2V0LXVyaSBkb2N1bWVudC4NCgkNCglOb3csIEkgZG9uJ3QgaGF2ZSBhIHByb2JsZW0g aWYgZm9sa3MgY2FuIGFjY2VwdCB0aGF0IHRoZSB0YXJnZXQtdXJpDQoJZG9jdW1lbnQgbWln aHQgY2hhbmdlIHN1Y2ggdGhhdCB0aGUgbm9ybWF0aXZlIGZ1bmN0aW9uYWxpdHkgaXMgaW4N Cgk0MjQ0YmlzLiAgIEFuZCwgdGhpcyB3YXMgY29uc2Vuc3VzIGZyb20gSUVURi03MyBwZXIg dGhvc2UgbWludXRlczoNCgkiSXNzdWU6IE5vcm1hdGl2ZSBiZWhhdmlvciB1cGRhdGUgZm9y IFJGQyA0MjQ0DQoJDQoJQ29uc2Vuc3VzIG5vdGVkIHRvIHJldmlzZSBSRkMgNDI0NCwgYW5k IGZpeCBzb21lIG90aGVyIGtub3duIHByb2JsZW1zDQoJd2l0aCBpdCBhdCB0ZWggc2FtZSB0 aW1lLiBNQXJ5IEJhcm5lcyB2b2x1bnRlZXJlZCB0byBlZGl0IHRoZQ0KCWRvY3VtZW50LiIN CgkNCglTbywgdGhlcmUgaXMgYSBjb25mbGljdCBpbiB0ZXJtcyBvZiBhY2NlcHRpbmcgdGFy Z2V0LXVyaSBkb2N1bWVudCBhcyB0aGUNCglvbmx5IGRlbGl2ZXJhYmxlIGZvciB0aGF0IG1p bGVzdG9uZSBpbiB0aGUgSUVURi03MyBtZWV0aW5nLg0KCQ0KCU1hcnkuDQoJDQoJDQoJLS0t LS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCglGcm9tOiBEZWFuIFdpbGxpcyBbbWFpbHRvOmRl YW4ud2lsbGlzQHNvZnRhcm1vci5jb21dDQoJU2VudDogVGh1cnNkYXksIEFwcmlsIDE2LCAy MDA5IDI6MzYgUE0NCglUbzogQmFybmVzLCBNYXJ5IChSSUNIMjpBUjAwKQ0KCUNjOiBzaXBj b3JlQGlldGYub3JnDQoJU3ViamVjdDogUmU6IFtzaXBjb3JlXSBbU2lwXSBTSVBDT1JFIC0t IElmIHlvdSdyZSBub3Qgc3Vic2NyaWJlZCwgeW91J3JlDQoJbWlzc2luZyBzdHVmZg0KCQ0K CQ0KCU9uIEFwciAxNiwgMjAwOSwgYXQgMjoyNyBQTSwgTWFyeSBCYXJuZXMgd3JvdGU6DQoJ DQoJPiBJIGhhdmUgYW4gaXNzdWUgd2l0aCB0aGUgdGFyZ2V0LXVyaSBkb2N1bWVudCBiZWlu ZyBwcm9wb3NlZCBhcyB0aGUgV0cNCgk+IGRvY3VtZW50IGZvciB0aGUgdGFyZ2V0LXVyaSBk ZWxpdmVyYWJsZS4gVGhpcyB3YXMgbm90IHRoZSBjb25zZW5zdXMgaW4NCgkNCgk+IFNGIHBl ciBteSByZWNvbGxlY3Rpb24gKHdoaWNoIG1heSBiZSBiaWFzZWQpIG5vciBwZXIgdGhlIFNJ UCBXRw0KCT4gbWludXRlczoNCgk+IGh0dHA6Ly93d3cuaWV0Zi5vcmcvcHJvY2VlZGluZ3Mv MDltYXIvbWludXRlcy9zaXAuaHRtbA0KCT4NCgk+IFdoaWNoIHN0YXRlOg0KCT4gIklzc3Vl OiBQcm9ncmVzcyA0MjQ0YmlzLCB0YXJnZXQtdXJpIGRyYWZ0LCBvciBib3RoPw0KCT4gSW4g dGhlIGFic2VuY2Ugb2YgYSBjbGVhciBjb25zZW5zdXMsIHRoZSBjaGFpcnMgcHJvcG9zZWQg dGhhdCBib3RoDQoJPiBkb2N1bWVudHMgcHJvY2VlZCBhbmQgd2UnbGwgaG9wZSB0aGF0IGZ1 cnRoZXIgZGlzY3Vzc2lvbiBnaXZlcyB1cyBhDQoJPiBjb25zZW5zdXMuIg0KCT4NCgk+IE5v dywgSSByZWFsaXplIHRoYXQgdGhlcmUgYXJlIG5vdyBuZXcgY2hhaXJzLCBidXQgSSBkb24n dCB0aGluayB0aGF0DQoJPiBzaG91bGQgY2hhbmdlIHRoZSBXRyBjb25zZW5zdXMgZnJvbSB0 aGUgU0lQIFdHIHNlc3Npb24uDQoJDQoJSG93ZXZlciwgdGhlIG1pbnV0ZXMgZnJvbSBJRVRG IDczIHJlYWQ6DQoJDQoJVG9waWM6IFVSSSBhbmQgUGFyYW1ldGVyIERlbGl2ZXJ5DQoJTGVk IGJ5IEpvbmFhdGhhbiBSb3NlbmJlcmcNCglTbGlkZXMgcHJlc2VudGVkDQoJaHR0cDovL3Rv b2xzLmlldGYub3JnL2lkL2RyYWZ0LXJvc2VuYmVyZy1zaXAtdGFyZ2V0LXVyaS1kZWxpdmVy eS0wMC50eHQNCgkNCgkuLi4NCgkNCglQb2xsOiBTaGFsbCBXRyBhZG9wdCB0aGlzIGRyYWZ0 IHRvd2FyZHMgb3VyIGNoYXJ0ZXIgZGVsaXZlcmFibGUgb24gdGhlDQoJdG9waWM/IENoYWly cyByZXBvcnRlZCBhIHN0cm9uZyBjb25zZW5zdXMgdG8gZG8gc28uDQoJU28gd2hpY2ggV0cg Y29uc2Vuc3VzIG9mIHdoaWNoIFNJUCBXRyBzZXNzaW9uIGRvIHlvdSBub3Qgd2FudCB0byBj aGFuZ2U/DQoJDQoJDQoJDQoJPg0KCT4gSXQgd2FzIG15IHVuZGVyc3RhbmRpbmcgZnJvbSB0 aGUgbWludXRlcyB0aGF0IHRoZSBkaXNjdXNzaW9uIHdhcyB0bw0KCT4gY29udGludWUgYXMg dG8gd2hldGhlciB3ZSB3b3VsZCBtZXJnZSB0aGUgdHdvIGRvY3VtZW50cyBvciBhZ3JlZSBv bmUNCgk+IG9yIHRoZSBvdGhlciBhcyBhIFdHIGRlbGl2ZXJhYmxlLg0KCT4NCgkNCgkNCglU aGF0J3MgYWxzbyBjb25zaXN0ZW50IHdpdGggbXkgbm90ZXMgZnJvbSBTSVAgYXQgNzQuDQoJ DQoJTXkgYmVzdCBndWVzcyBpcyB0aGF0IFJGQyA0MjQ0YmlzIGdvZXMgZm9yd2FyZCwgYW5k IHRoYXQgdGFyZ2V0LXVyaS0NCglkZWxpdmVyeSB0dXJucyBpbnRvIGEgIkhvdyB0byB1c2Ug SC1JIHRvIG1lZXQgdGhlIFVSSSBkZWxpdmVyeSB1c2UNCgljYXNlcyIgZG9jdW1lbnQuDQoJ DQoJLS0NCglEZWFuDQoJDQoJDQoJDQoJDQoJX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCglzaXBjb3JlIG1haWxpbmcgbGlzdA0KCXNpcGNvcmVA aWV0Zi5vcmcNCglodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NpcGNv cmUNCgkNCg0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0gDQpUaGlzIHRyYW5zbWlzc2lvbiAoaW5jbHVk aW5nIGFueSBhdHRhY2htZW50cykgbWF5IGNvbnRhaW4gY29uZmlkZW50aWFsIGluZm9ybWF0 aW9uLCBwcml2aWxlZ2VkIG1hdGVyaWFsIChpbmNsdWRpbmcgbWF0ZXJpYWwgcHJvdGVjdGVk IGJ5IHRoZSBzb2xpY2l0b3ItY2xpZW50IG9yIG90aGVyIGFwcGxpY2FibGUgcHJpdmlsZWdl cyksIG9yIGNvbnN0aXR1dGUgbm9uLXB1YmxpYyBpbmZvcm1hdGlvbi4gQW55IHVzZSBvZiB0 aGlzIGluZm9ybWF0aW9uIGJ5IGFueW9uZSBvdGhlciB0aGFuIHRoZSBpbnRlbmRlZCByZWNp cGllbnQgaXMgcHJvaGliaXRlZC4gSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyB0cmFuc21p c3Npb24gaW4gZXJyb3IsIHBsZWFzZSBpbW1lZGlhdGVseSByZXBseSB0byB0aGUgc2VuZGVy IGFuZCBkZWxldGUgdGhpcyBpbmZvcm1hdGlvbiBmcm9tIHlvdXIgc3lzdGVtLiBVc2UsIGRp c3NlbWluYXRpb24sIGRpc3RyaWJ1dGlvbiwgb3IgcmVwcm9kdWN0aW9uIG9mIHRoaXMgdHJh bnNtaXNzaW9uIGJ5IHVuaW50ZW5kZWQgcmVjaXBpZW50cyBpcyBub3QgYXV0aG9yaXplZCBh bmQgbWF5IGJlIHVubGF3ZnVsLiANCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpUaGlzIHRyYW5zbWlz c2lvbiAoaW5jbHVkaW5nIGFueSBhdHRhY2htZW50cykgbWF5IGNvbnRhaW4gY29uZmlkZW50 aWFsIGluZm9ybWF0aW9uLCBwcml2aWxlZ2VkIG1hdGVyaWFsIChpbmNsdWRpbmcgbWF0ZXJp YWwgcHJvdGVjdGVkIGJ5IHRoZSBzb2xpY2l0b3ItY2xpZW50IG9yIG90aGVyIGFwcGxpY2Fi bGUgcHJpdmlsZWdlcyksIG9yIGNvbnN0aXR1dGUgbm9uLXB1YmxpYyBpbmZvcm1hdGlvbi4g QW55IHVzZSBvZiB0aGlzIGluZm9ybWF0aW9uIGJ5IGFueW9uZSBvdGhlciB0aGFuIHRoZSBp bnRlbmRlZCByZWNpcGllbnQgaXMgcHJvaGliaXRlZC4gSWYgeW91IGhhdmUgcmVjZWl2ZWQg dGhpcyB0cmFuc21pc3Npb24gaW4gZXJyb3IsIHBsZWFzZSBpbW1lZGlhdGVseSByZXBseSB0 byB0aGUgc2VuZGVyIGFuZCBkZWxldGUgdGhpcyBpbmZvcm1hdGlvbiBmcm9tIHlvdXIgc3lz dGVtLiBVc2UsIGRpc3NlbWluYXRpb24sIGRpc3RyaWJ1dGlvbiwgb3IgcmVwcm9kdWN0aW9u IG9mIHRoaXMgdHJhbnNtaXNzaW9uIGJ5IHVuaW50ZW5kZWQgcmVjaXBpZW50cyBpcyBub3Qg YXV0aG9yaXplZCBhbmQgbWF5IGJlIHVubGF3ZnVsLg0K ------_=_NextPart_001_01C9BEF3.46701461 Content-Type: text/html; charset="utf-8" content-transfer-encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9u YWwvL0VOIj4NCjxIVE1MPjxIRUFEPg0KDQo8TUVUQSBjb250ZW50PSJNU0hUTUwgNi4wMC4y OTAwLjM0OTIiIG5hbWU9R0VORVJBVE9SPjwvSEVBRD4NCjxCT0RZPjxwPjxmb250IHNpemU9 MiBjb2xvcj1uYXZ5IGZhY2U9QXJpYWw+DQo8YnI+TXkgdW5kZXJzdGFuZGluZyBvZiB0aGUg b3V0Y29tZSBpbiBTYW4gRnJhbmNpc2NvIHdhcyB0aGF0IHRhcmdldC11cmkgd291bGQgdXBk YXRlIDQyNDQgYW5kIDQyNDRiaXMgd291bGQgYmUgd29ya2VkIG9uIGluIHBhcmFsbGVsIGFu ZCBwb3RlbnRpYWxseSBvYnNvbGV0ZSBib3RoIDQyNDQgYW5kIHRhcmdldC11cmkuIDxicj48 YnI+V2hhdGV2ZXIgaXMgZGV2ZWxvcGVkIGZvciB0YXJnZXQtdXJpIG91Z2h0IHRvIGJlIGFi bGUgdG8gYmUgaW5jb3Jwb3JhdGVkIGluIDQyNDRiaXMuIElmIDQyNDQgcHJvZ3Jlc3NlcyB3 ZWxsIHRoZW4gdGFyZ2V0LXVyaSBtYXkgbm90IG5lZWQgdWx0aW1hdGVseSB0byBiZSBwdWJs aXNoZWQgc2VwYXJhdGVseS4gPGJyPjxicj5JIGFtIGFmcmFpZCB0aGF0IHRoZSBzZWN1cml0 eSBxdWVzdGlvbiB0byBiZSBhZGRyZXNzZWQgYnkgNDI0NGJpcyBpcyBhIGJpZyBjYW4gb2Yg d29ybXMgdGhhdCBpcyBsaWtlbHkgdG8gYmUgYSBsb25nIGRpc2N1c3Npb24uIElzIHRoZXJl IGEgcmVhc29uIHdoeSB0YXJnZXQtdXJpIGNhbid0IHByb2dyZXNzIHVuZGVyIHRoZSBjdXJy ZW50IEhpc3RvcnktSW5mbyBzZWN1cml0eSBmcmFtZXdvcms/IElzIHRoZSBzZWN1cml0eSBz b2x1dGlvbiBmb3IgNDI0NCBhY3R1YWxseSB0ZWNobmljYWxseSBicm9rZW4gb3IgaXMgaXQg anVzdCB0aGF0IHBlb3BsZSBkb24ndCBpbXBsZW1lbnQgaXQ/PGJyPjxicj5UaGVyZSBpcyBu b3QgYSBkcmFmdCBkZXBlbmRlY3kgb24gdGFyZ2V0LXVyaSBmb3IgR1JVVSBidXQgaXQgd2Fz IGNsZWFybHkgaWRlbnRpZmllZCBkdXJpbmcgR1JVVSBkZXZlbG9wbWVudCB0aGF0IGEgbG90 IG9mIHVzZSBjYXNlcyBmb3IgR1JVVSByZWFsbHkgbmVlZCB0byBrbm93IHRoYXQgdGhlIFJl cXVlc3Qgd2FzIGFkZHJlc3NlZCB0byBhIHBhcnRpY3VsYXIgR1JVVSBhbmQgd2l0aG91dCB0 YXJnZXQtdXJpIHRoYXQgZnVuY3Rpb25hbGl0eSBjYW5ub3QgYmUgYWNoaWV2ZWQuIDxicj48 L2ZvbnQ+PC9wPg0KPHA+PGhyIHNpemU9MiB3aWR0aD0iMTAwJSIgYWxpZ249Y2VudGVyIHRh YmluZGV4PS0xPg0KPGZvbnQgZmFjZT1UYWhvbWEgc2l6ZT0yPg0KPGI+RnJvbTwvYj46IE1h cnkgQmFybmVzICZsdDttYXJ5LmJhcm5lc0Bub3J0ZWwuY29tJmd0Ow08YnI+PGI+VG88L2I+ OiBBbmRyZXcgQWxsZW47IGlldGYuaGFuc2VyaWtAZ21haWwuY29tICZsdDtpZXRmLmhhbnNl cmlrQGdtYWlsLmNvbSZndDsNPGJyPjxiPkNjPC9iPjogc2lwY29yZUBpZXRmLm9yZyAmbHQ7 c2lwY29yZUBpZXRmLm9yZyZndDsNPGJyPjxiPlNlbnQ8L2I+OiBUaHUgQXByIDE2IDE4OjAz OjQyIDIwMDk8YnI+PGI+U3ViamVjdDwvYj46IFJFOiBbc2lwY29yZV0gVGFyZ2V0LXVyaSBk b2N1bWVudCBhcyBTSVBDT1JFIFdHIGRvY3VtZW50PyAod2FzIFJFOltTaXBdIFNJUENPUkUg LS0gSWYgeW91J3JlIG5vdCBzdWJzY3JpYmVkLCB5b3UncmUgbWlzc2luZyBzdHVmZg08YnI+ PC9mb250PjwvcD4NCg0KPERJVj48Rk9OVCBmYWNlPUFyaWFsIGNvbG9yPSMwMDAwZmYgc2l6 ZT0yPjxTUEFOIGNsYXNzPTIxODMyNTMyMS0xNjA0MjAwOT5BIGZldyANCmNvbW1lbnRzIGJl bG93IFtNQl0uIDwvU1BBTj48L0ZPTlQ+PC9ESVY+PEJSPg0KPERJViBjbGFzcz1PdXRsb29r TWVzc2FnZUhlYWRlciBsYW5nPWVuLXVzIGRpcj1sdHIgYWxpZ249bGVmdD4NCjxIUiB0YWJJ bmRleD0tMT4NCjxGT05UIGZhY2U9VGFob21hIHNpemU9Mj48Qj5Gcm9tOjwvQj4gQW5kcmV3 IEFsbGVuIFttYWlsdG86YWFsbGVuQHJpbS5jb21dIA0KPEJSPjxCPlNlbnQ6PC9CPiBUaHVy c2RheSwgQXByaWwgMTYsIDIwMDkgNDo1MCBQTTxCUj48Qj5Ubzo8L0I+IEJhcm5lcywgTWFy eSANCihSSUNIMjpBUjAwKTsgaWV0Zi5oYW5zZXJpa0BnbWFpbC5jb208QlI+PEI+Q2M6PC9C PiANCnNpcGNvcmVAaWV0Zi5vcmc8QlI+PEI+U3ViamVjdDo8L0I+IFJlOiBbc2lwY29yZV0g VGFyZ2V0LXVyaSBkb2N1bWVudCBhcyBTSVBDT1JFIA0KV0cgZG9jdW1lbnQ/ICh3YXMgUkU6 W1NpcF0gU0lQQ09SRSAtLSBJZiB5b3UncmUgbm90IHN1YnNjcmliZWQsIHlvdSdyZSBtaXNz aW5nIA0Kc3R1ZmY8QlI+PC9GT05UPjxCUj48L0RJVj4NCjxESVY+PC9ESVY+PEZPTlQgY29s b3I9bmF2eT4NCjxQPjxCUj48Rk9OVCBmYWNlPUFyaWFsIHNpemU9Mj5NeSB1bmRlcnN0YW5k aW5nIHdhcyB0aGF0IHdlIHdvdWxkIG1vdmUgZm9yd2FyZCANCndpdGggYm90aCBkcmFmdHMg YXMgV0cgaXRlbXMuPEJSPjxCUj5NeSB1bmRlcnN0YW5kaW5nIHdhcyB0aGF0IGluIER1Ymxp biANClRhcmdldC11cmkgd2FzIGFkb3B0ZWQgYXMgYSBTSVAgV0cgaXRlbS4gSSBkb24ndCB3 YW50IHRvIHNlZSA0MjQ0YmlzIGJlY29tZSBhIA0KZGVwZW5kZW5jeSBmb3IgdGhlIHRhcmdl dC11cmkgd29yayB3aGljaCBpcyB1cmdlbnRseSBuZWVkZWQgdG8gc29sdmUgc29tZSBHUlVV IA0KcmVsYXRlZCBpc3N1ZXMuPFNQQU4gY2xhc3M9MjE4MzI1MzIxLTE2MDQyMDA5PjxGT05U IA0KY29sb3I9IzAwMDBmZj4mbmJzcDs8L0ZPTlQ+PC9TUEFOPjwvRk9OVD48L1A+DQo8UD48 Rk9OVCBmYWNlPUFyaWFsPjxGT05UIHNpemU9Mj48U1BBTiBjbGFzcz0yMTgzMjUzMjEtMTYw NDIwMDk+PEZPTlQgDQpjb2xvcj0jMDAwMGZmPltNQl0gUGVyIG15IG9yaWdpbmFsIGNvbW1l bnRzIGJlbG93LCB0aGUmbmJzcDtjaGFuZ2VzJm5ic3A7Zm9yIGEgDQp0YXJnZXQtdXJpIHNv bHV0aW9uIGJhc2VkIG9uIDQyNDQgaXMmbmJzcDthY3R1YWxseSBtb3JlIHdvcmsgDQp0aGFu Jm5ic3A7cHV0dGluZyZuYnNwO3RoZSBub3JtYXRpdmUgZnVuY3Rpb25hbGl0eSBpbiA0MjQ0 YmlzIC0gdGhhdCdzIGJlY2F1c2UgDQp5b3Ugc3RpbGwgbmVlZCB0byBhZGRyZXNzIHNlY3Vy aXR5LCZuYnNwO3ByaXZhY3ksIGhvdyBpdCBpcyBwcm9jZXNzZWQgYnkmbmJzcDthIA0KVUFD LCBQcm94eSBhbmQgVUFTLiZuYnNwO1lvdSB3b3VsZCB0aGVuJm5ic3A7bmVlZCBkdXBsaWNh dGUgdGV4dCB0byBzZXQgdGhlIA0KY29udGV4dCwgZXRjLiBhbmQgdGhhdCB0ZXh0IHdvdWxk IGJlIGlkZW50aWNhbCB0byB3aGF0J3MgaW4gNDI0NCBPUiB5b3UnZCBiZSANCmJyZWFraW5n IGV4aXN0aW5nIGltcGxlbWVudGF0aW9ucyBhbmQgdGhlcmUgYXJlIHNvbWUgb2YgdGhvc2Uu IE5vdywgd2UgZGlkIGhhdmUgDQpvbmUgcmVhc29uYWJsZSBzdWdnZXN0aW9uIGFzIHRvIGFk ZGluZyBhIHJlY29tbWVuZGF0aW9uIHRoYXQgdGhlIFByaXZhY3kgbm90IGJlIA0KYXBwbGll ZCB0byB0aGUgZW50aXJlIG1lc3NhZ2UgYXMgdGhhdCBsaW1pdHMgcHJveHkgZnVuY3Rpb25h bGl0eSAtIHRoYXQncyANCmltcG9ydGFudCBmb3IgdGFyZ2V0LXVyaSwgYnV0IGl0J3MgYWxz byBsaWtlbHkgYW4gb3ZlcnNpZ2h0IGluIHRoZSBvcmlnaW5hbCANCjQyNDQuIFsvTUJdJm5i c3A7PC9GT05UPiZuYnNwOzwvU1BBTj48QlI+PEJSPklmIDQyNDRiaXMgaXMgcmVhZHkgd2hl biB0YXJnZXQtdXJpIA0KaXMgdGhlbiB3ZSBjYW4gdGFsayBhYm91dCByb2xsaW5nIHRoZSB0 d28gaW50byBvbmUgYnV0IEkgaGF2ZSBjb25jZXJucyB0aGF0IA0KNDI0NGJpcyB3aWxsIHRh a2UgY29uc2lkZXJhYmx5IGxvbmdlciB0aGFuIHRhcmdldC11cmkgYmFzZWQgb24gdGhlIGRp c2N1c3Npb24gaW4gDQpTYW4gRnJhbi4mbmJzcDs8U1BBTiBjbGFzcz0yMTgzMjUzMjEtMTYw NDIwMDk+PEZPTlQgDQpjb2xvcj0jMDAwMGZmPiZuYnNwOzwvRk9OVD48L1NQQU4+PC9GT05U PjwvRk9OVD48L1A+DQo8UD48Rk9OVCBmYWNlPUFyaWFsPjxGT05UIHNpemU9Mj48U1BBTiBj bGFzcz0yMTgzMjUzMjEtMTYwNDIwMDk+PEZPTlQgDQpjb2xvcj0jMDAwMGZmPltNQl0gTm9w ZSAtIGFzIEkgbm90ZWQgZWFybGllciwgSSB0aGluayB0aGUgZGlzY3Vzc2lvbiB3YXMgDQpj b25mb3VuZGVkIGJlY2F1c2UmbmJzcDtwZW9wbGUgd2VyZSB0YWxraW5nIGFib3V0IGNoYW5n ZXMgdG8gNDI0NGJpcyANCihIaXN0b3J5LUluZm8pIHRoYXQgd2VyZSB3ZWxsIGJleW9uZCB3 aGF0IGlzIHJlcXVpcmVkIGZvciB0YXJnZXQtdXJpIC0gaS5lLiwgDQpwYXJpbmcgZG93biB0 aGUgZnVuY3Rpb25hbGl0eSB0byBvbmx5IGNvbGxlY3QgdGhlIGRlc2lyZWQgZW50cmllcywg d2hpY2ggZG9lc24ndCANCnNhdmUgYSZuYnNwO2JpdCBvZiB3b3JrIGJlY2F1c2UgeW91IHN0 aWxsIGhhdmUgdG8gcmVjb2duaXplIHRoZSBjb25kaXRpb25zIHVuZGVyIA0Kd2hpY2ggeW91 IGRyb3AgdGhlIGVudHJpZXMuJm5ic3A7IFBsZWFzZSBsaXN0ZW4gdG8gRnJhbmNvaXMnIHJl c3BvbnNlIHRvIA0KSGFkcmllbCdzIHN1Z2dlc3Rpb24gaW4gdGhlIGF1ZGlvIC0gaXQncyB0 b3dhcmRzIHRoZSBlbmQuIEFsc28sIHRoZSBzYW1lIA0Kc2VjdXJpdHkgaXNzdWVzIGFwcGx5 IC0gd2hlbiB3ZSBjb21wbGV0ZWQgNDI0NCwgdGhlIHNlY3VyaXR5IHNlY3Rpb24gd2FzIA0K Y2FyZWZ1bGx5IGNyYWZ0ZWQgYmFzZWQgb24gc2VjdXJpdHkgdGhvdWdodHMgYXQgdGhlIHRp bWUuIFRob3NlIGhhdmUgY2hhbmdlZCANCihvYnZpb3VzbHkpIGFuZCBpZiB0aGV5IGFyZSBw cm9ibGVtYXRpYyBpbiA0MjQ0YmlzLCB0aGV5IHdvdWxkIGJlIGEgcHJvYmxlbSBmb3IgDQp0 aGUgdGFyZ2V0LXVyaSB1c2FnZSBvZiA0MjQ0LCB3aGljaCBoYXMgdGhlIHNhbWUgc2VjdXJp dHkgcmVxdWlyZW1lbnRzIGFzIGNvcmUgDQo0MjQ0LiZuYnNwOyZuYnNwO1svTUJdPC9GT05U PjwvU1BBTj48QlI+PEJSPlRhcmdldC11cmkgaGFzIGJlZW4gbmVlZGVkIHJlYWxseSANCmZv ciBHUlVVIGZvciBtb3JlIHRoZW4gMiB5ZWFycyBhbmQgaXMgZmFpcmx5IHN0cmFpZ2h0Zm9y d2FyZC4gSSBkb24ndCB0aGluayB3ZSANCnNob3VsZCByaXNrIGRlbGF5aW5nIHRoYXQgd29y ayB3YWl0aW5nIGZvciA0MjQ0YmlzIHdoaWNoIHNlZW1zIHRvIGNvbnRhaW4gYSANCm51bWJl ciBvZiBpc3N1ZXMgd2UgZG9uJ3QgaGF2ZSBjb25zZW5zdXMgb24geWV0LjxTUEFOIA0KY2xh c3M9MjE4MzI1MzIxLTE2MDQyMDA5PjxGT05UIA0KY29sb3I9IzAwMDBmZj4mbmJzcDs8L0ZP TlQ+PC9TUEFOPjwvRk9OVD48L0ZPTlQ+PC9QPg0KPFA+PEZPTlQgZmFjZT1BcmlhbD48Rk9O VCBjb2xvcj0jMDAwMGZmIHNpemU9Mj48U1BBTiANCmNsYXNzPTIxODMyNTMyMS0xNjA0MjAw OT5bTUJdIFRoZSZuYnNwO290aGVyIGNoYW5nZXMgdG8gNDI0NGJpcyBhcmUgbWlub3IgYXMg DQpjb21wYXJlZCB0byB0aGUgbm9ybWF0aXZlIGZ1bmN0aW9uYWxpdHkgdGhhdCBuZWVkcyB0 byBiZSBhZGRlZCB0byB0aGUgZG9jdW1lbnQgDQp0byBzdXBwb3J0IHRhcmdldC11cmkuIFBs ZWFzZSBsb29rIGF0IHRoZSBkaWZmLiZuYnNwOyBJIGFsc28gZG9uJ3Qgc2VlIHRoZSBHUlVV IA0KZGVwZW5kZW5jeSAtIGNhbiB5b3UgcGxlYXNlIGNsYXJpZnk/Jm5ic3A7IEkga25vdyZu YnNwO0dSVVUgaXMgd2FpdGluZyZuYnNwO2ZvciANCk91dGJvdW5kIChJIHByb21pc2UgSSB3 aWxsIGdpdmUgdXAgaWYgNDI0NGJpcyByZWFjaGVzIGEgcG9pbnQgd2hlcmUgaXQmbmJzcDtp cyANCnRha2luZyBsb25nZXIgdG8gZmluaXNoIHRoYW4gT3V0Ym91bmQpIGFuZCB0aGF0IHRo ZSZuYnNwO2dydXUtcmVnLWV2ZW50IHBrZyBpcyANCndhaXRpbmcgZm9yIEdSVVUuJm5ic3A7 Jm5ic3A7Wy9NQl08L1NQQU4+PC9GT05UPjwvRk9OVD48Rk9OVCBmYWNlPUFyaWFsPjxGT05U IA0Kc2l6ZT0yPjxTUEFOIGNsYXNzPTIxODMyNTMyMS0xNjA0MjAwOT4mbmJzcDs8L1NQQU4+ PEJSPjxCUj5UaGF0IHdhcyBteSANCnVuZGVyc3RhbmRpbmcgb2YgdGhlIGFwcHJvYWNoIHdl IGRldGVybWluZWQgaW4gU2FuIA0KRnJhbmNpc2NvLjxCUj48L1A+PC9GT05UPjwvRk9OVD48 L0ZPTlQ+DQo8UD4NCjxIUiB0YWJJbmRleD0tMSBhbGlnbj1jZW50ZXIgd2lkdGg9IjEwMCUi IFNJWkU9Mj4NCjxGT05UIGZhY2U9VGFob21hIHNpemU9Mj48Qj5Gcm9tPC9CPjogc2lwY29y ZS1ib3VuY2VzQGlldGYub3JnIA0KJmx0O3NpcGNvcmUtYm91bmNlc0BpZXRmLm9yZyZndDsg PEJSPjxCPlRvPC9CPjogSGFucyBFcmlrIHZhbiBFbGJ1cmcgDQombHQ7aWV0Zi5oYW5zZXJp a0BnbWFpbC5jb20mZ3Q7IDxCUj48Qj5DYzwvQj46IHNpcGNvcmVAaWV0Zi5vcmcgDQombHQ7 c2lwY29yZUBpZXRmLm9yZyZndDsgPEJSPjxCPlNlbnQ8L0I+OiBUaHUgQXByIDE2IDE3OjM0 OjU3IA0KMjAwOTxCUj48Qj5TdWJqZWN0PC9CPjogUmU6IFtzaXBjb3JlXSBUYXJnZXQtdXJp IGRvY3VtZW50IGFzIFNJUENPUkUgV0cgDQpkb2N1bWVudD8gKHdhcyBSRTpbU2lwXSBTSVBD T1JFIC0tIElmIHlvdSdyZSBub3Qgc3Vic2NyaWJlZCwgeW91J3JlIG1pc3NpbmcgDQpzdHVm ZiA8QlI+PC9GT05UPg0KPFA+PC9QPg0KPERJVj48Rk9OVCBmYWNlPUFyaWFsIGNvbG9yPSMw MDAwZmYgc2l6ZT0yPjxTUEFOIGNsYXNzPTY3MTE3MzMyMS0xNjA0MjAwOT5ObyAtIA0KdGhl IGRpc2N1c3Npb24gZm9yIDQyNDQoYmlzKSAoZXh0cmFjdGVkIGJlbG93KSB3YXMgZW50aXJl bHkgaW4gdGhlIGNvbnRleHQgb2YgDQp0aGUgZGlzY3Vzc2lvbiBmb3IgdGhlIHRhcmdldC11 cmkgZG9jdW1lbnQuIFlvdSBjYW4gZ28gYmFjayBhbmQgbGlzdGVuIHRvIHRoZSANCmF1ZGlv IHRvIHZlcmlmeSB0aGF0LiZuYnNwOyBBbmQsIEkndmUgc3RhdGVkIGxvbmcgYmVmb3JlIElF VEYtNzMgdGhhdCBpdCB3b3VsZCANCmJlIGZhaXJseSBzdHJhaWdodGZvcndhcmQgdG8gdXBk YXRlIDQyNDQgdG8gYWNjb21vZGF0ZSB0aGUgdGFyZ2V0LXVyaSANCnJlcXVpcmVtZW50cyBh bmQgd2hpbGUgd2Ugd2VyZSBkb2luZyB0aGF0LCB0aGVyZSB3ZXJlIGEgZmV3IG90aGVyIGZp eGVzIHdlIGNvdWxkIA0KZG8uIDwvU1BBTj48L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIGZh Y2U9QXJpYWwgY29sb3I9IzAwMDBmZiBzaXplPTI+PFNQQU4gDQpjbGFzcz02NzExNzMzMjEt MTYwNDIwMDk+PC9TUEFOPjwvRk9OVD4mbmJzcDs8L0RJVj4NCjxESVY+PEZPTlQgZmFjZT1B cmlhbCBjb2xvcj0jMDAwMGZmIHNpemU9Mj48U1BBTiBjbGFzcz02NzExNzMzMjEtMTYwNDIw MDk+TWFyeS4gDQo8L1NQQU4+PC9GT05UPjwvRElWPjxCUj4NCjxESVYgY2xhc3M9T3V0bG9v a01lc3NhZ2VIZWFkZXIgbGFuZz1lbi11cyBkaXI9bHRyIGFsaWduPWxlZnQ+DQo8SFIgdGFi SW5kZXg9LTE+DQo8Rk9OVCBmYWNlPVRhaG9tYSBzaXplPTI+PEI+RnJvbTo8L0I+IEhhbnMg RXJpayB2YW4gRWxidXJnIA0KW21haWx0bzppZXRmLmhhbnNlcmlrQGdtYWlsLmNvbV0gPEJS PjxCPlNlbnQ6PC9CPiBUaHVyc2RheSwgQXByaWwgMTYsIDIwMDkgNDoyMiANClBNPEJSPjxC PlRvOjwvQj4gQmFybmVzLCBNYXJ5IChSSUNIMjpBUjAwKTxCUj48Qj5DYzo8L0I+IERlYW4g V2lsbGlzOyANCnNpcGNvcmVAaWV0Zi5vcmc8QlI+PEI+U3ViamVjdDo8L0I+IFJlOiBbc2lw Y29yZV0gVGFyZ2V0LXVyaSBkb2N1bWVudCBhcyBTSVBDT1JFIA0KV0cgZG9jdW1lbnQ/ICh3 YXMgUkU6IFtTaXBdIFNJUENPUkUgLS0gSWYgeW91J3JlIG5vdCBzdWJzY3JpYmVkLCB5b3Un cmUgbWlzc2luZyANCnN0dWZmPEJSPjwvRk9OVD48QlI+PC9ESVY+DQo8RElWPjwvRElWPkhp IE1hcnksPEJSPjxCUj5JIGJlbGlldmUgdGhhdCBpbiB0aGUgYWJzZW5jZSBvZiBjb25zZW5z dXMgYXMgdGhlIA0KbWludXRlcyBjb3JyZWN0bHkgc3RhdGUsIHRoZSB0aGUgdGFyZ2V0LXVy aSBkb2N1bWVudCBzaG91bGQgcmVtYWluIHRoZSBXRyANCmRvY3VtZW50IGZvciB0aGUgdGFy Z2V0LXVyaSBkZWxpdmVyYWJsZS48QlI+PEJSPjQ0MjRiaXMgaGFzIGFub3RoZXIgcHVycG9z ZSwgDQpuYW1lbHkgdG8gZml4IHRoZSA0NDI0LiBJZiBhdCBhIGNlcnRhaW4gbW9tZW50IGlu IHRpbWUgaXQgdHVybnMgb3V0IHRoYXQgNDQyNGJpcyANCmlzIHRoZSBhcHByb3ByaWF0ZSBk b2N1bWVudCB0byBjb250YWluIG5vcm1hdGl2ZSB0ZXh0IGZvciB0YXJnZXQgdXJpIGRlbGl2 ZXJ5IA0KdGhlbiB3ZSBjYW4gYWx3YXlzIGRlY2lkZSB0byBkbyBzby4gQXQgdGhpcyBzdGFn ZSBpdCBpcyB0byBlYXJseSB0byB0YWtlIHRoYXQgDQpkZWNpc2lvbiwgZ2l2ZW4gdGhlIGNv bmZ1c2VkIHN0YXRlIG9mIHRoZSB0YXJnZXQtdXJpIGRpc2N1c3Npb24uPEJSPjxCUiANCmNs ZWFyPWFsbD4vSGFucyBFcmlrIHZhbiBFbGJ1cmc8QlI+PEJSPjxCUj4NCjxESVYgY2xhc3M9 Z21haWxfcXVvdGU+T24gVGh1LCBBcHIgMTYsIDIwMDkgYXQgMTA6MDIgUE0sIE1hcnkgQmFy bmVzIDxTUEFOIA0KZGlyPWx0cj4mbHQ7PEEgDQpocmVmPSJtYWlsdG86bWFyeS5iYXJuZXNA bm9ydGVsLmNvbSI+bWFyeS5iYXJuZXNAbm9ydGVsLmNvbTwvQT4mZ3Q7PC9TUEFOPiANCndy b3RlOjxCUj4NCjxCTE9DS1FVT1RFIGNsYXNzPWdtYWlsX3F1b3RlIA0Kc3R5bGU9IlBBRERJ TkctTEVGVDogMWV4OyBNQVJHSU46IDBwdCAwcHQgMHB0IDAuOGV4OyBCT1JERVItTEVGVDog cmdiKDIwNCwyMDQsMjA0KSAxcHggc29saWQiPkknbSANCiAgc3VnZ2VzdGluZyB0byBjaGFu Z2UgdGhlIGRlY2lzaW9uIGZyb20gSUVURi03MyBhbmQgYWNjZXB0IHRoZSBtb3JlPEJSPnJl Y2VudCANCiAgcmVhbGl6YXRpb24gdGhhdCBpbmNsdWRpbmcgbm9ybWF0aXZlIHRleHQgaW4g YW5vdGhlciBkb2N1bWVudDxCUj5yYXRoZXIgdGhhbiANCiAgNDI0NGJpcyB3aWxsIGJlIGZy YXVnaHQgd2l0aCBlcnJvciBhbmQgSSBjYW4ndCBzZWUgaG93IHRoYXQ8QlI+aXMgYSBnb29k IGlkZWEgDQogIGZyb20gYSBkZXZlbG9wbWVudCBwZXJzcGVjdGl2ZSAtIHlvdSBjYW4ndCBq dXN0IGltcGxlbWVudDxCUj50aGUgdGFyZ2V0LXVyaSANCiAgZG9jdW1lbnQuPEJSPjxCUj5O b3csIEkgZG9uJ3QgaGF2ZSBhIHByb2JsZW0gaWYgZm9sa3MgY2FuIGFjY2VwdCB0aGF0IHRo ZSANCiAgdGFyZ2V0LXVyaTxCUj5kb2N1bWVudCBtaWdodCBjaGFuZ2Ugc3VjaCB0aGF0IHRo ZSBub3JtYXRpdmUgZnVuY3Rpb25hbGl0eSBpcyANCiAgaW48QlI+NDI0NGJpcy4gJm5ic3A7 IEFuZCwgdGhpcyB3YXMgY29uc2Vuc3VzIGZyb20gSUVURi03MyBwZXIgdGhvc2UgDQogIG1p bnV0ZXM6PEJSPiJJc3N1ZTogTm9ybWF0aXZlIGJlaGF2aW9yIHVwZGF0ZSBmb3IgUkZDIDQy NDQ8QlI+PEJSPkNvbnNlbnN1cyANCiAgbm90ZWQgdG8gcmV2aXNlIFJGQyA0MjQ0LCBhbmQg Zml4IHNvbWUgb3RoZXIga25vd24gcHJvYmxlbXM8QlI+d2l0aCBpdCBhdCB0ZWggDQogIHNh bWUgdGltZS4gTUFyeSBCYXJuZXMgdm9sdW50ZWVyZWQgdG8gZWRpdCB0aGU8QlI+ZG9jdW1l bnQuIjxCUj48QlI+U28sIHRoZXJlIA0KICBpcyBhIGNvbmZsaWN0IGluIHRlcm1zIG9mIGFj Y2VwdGluZyB0YXJnZXQtdXJpIGRvY3VtZW50IGFzIHRoZTxCUj5vbmx5IA0KICBkZWxpdmVy YWJsZSBmb3IgdGhhdCBtaWxlc3RvbmUgaW4gdGhlIElFVEYtNzMgDQogIG1lZXRpbmcuPEJS PjxCUj5NYXJ5LjxCUj48QlI+PEJSPi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tPEJSPkZy b206IERlYW4gDQogIFdpbGxpcyBbbWFpbHRvOjxBIA0KICBocmVmPSJtYWlsdG86ZGVhbi53 aWxsaXNAc29mdGFybW9yLmNvbSI+ZGVhbi53aWxsaXNAc29mdGFybW9yLmNvbTwvQT5dPEJS PlNlbnQ6IA0KICBUaHVyc2RheSwgQXByaWwgMTYsIDIwMDkgMjozNiBQTTxCUj5UbzogQmFy bmVzLCBNYXJ5IChSSUNIMjpBUjAwKTxCUj5DYzogPEEgDQogIGhyZWY9Im1haWx0bzpzaXBj b3JlQGlldGYub3JnIj5zaXBjb3JlQGlldGYub3JnPC9BPjxCUj5TdWJqZWN0OiBSZTogW3Np cGNvcmVdIA0KICBbU2lwXSBTSVBDT1JFIC0tIElmIHlvdSdyZSBub3Qgc3Vic2NyaWJlZCwg eW91J3JlPEJSPm1pc3NpbmcgDQogIHN0dWZmPEJSPjxCUj48QlI+T24gQXByIDE2LCAyMDA5 LCBhdCAyOjI3IFBNLCBNYXJ5IEJhcm5lcyB3cm90ZTo8QlI+PEJSPiZndDsgSSANCiAgaGF2 ZSBhbiBpc3N1ZSB3aXRoIHRoZSB0YXJnZXQtdXJpIGRvY3VtZW50IGJlaW5nIHByb3Bvc2Vk IGFzIHRoZSBXRzxCUj4mZ3Q7IA0KICBkb2N1bWVudCBmb3IgdGhlIHRhcmdldC11cmkgZGVs aXZlcmFibGUuIFRoaXMgd2FzIG5vdCB0aGUgY29uc2Vuc3VzIA0KICBpbjxCUj48QlI+Jmd0 OyBTRiBwZXIgbXkgcmVjb2xsZWN0aW9uICh3aGljaCBtYXkgYmUgYmlhc2VkKSBub3IgcGVy IHRoZSBTSVAgDQogIFdHPEJSPiZndDsgbWludXRlczo8QlI+Jmd0OyA8QSANCiAgaHJlZj0i aHR0cDovL3d3dy5pZXRmLm9yZy9wcm9jZWVkaW5ncy8wOW1hci9taW51dGVzL3NpcC5odG1s IiANCiAgdGFyZ2V0PV9ibGFuaz5odHRwOi8vd3d3LmlldGYub3JnL3Byb2NlZWRpbmdzLzA5 bWFyL21pbnV0ZXMvc2lwLmh0bWw8L0E+PEJSPiZndDs8QlI+Jmd0OyANCiAgV2hpY2ggc3Rh dGU6PEJSPiZndDsgIklzc3VlOiBQcm9ncmVzcyA0MjQ0YmlzLCB0YXJnZXQtdXJpIGRyYWZ0 LCBvciANCiAgYm90aD88QlI+Jmd0OyBJbiB0aGUgYWJzZW5jZSBvZiBhIGNsZWFyIGNvbnNl bnN1cywgdGhlIGNoYWlycyBwcm9wb3NlZCB0aGF0IA0KICBib3RoPEJSPiZndDsgZG9jdW1l bnRzIHByb2NlZWQgYW5kIHdlJ2xsIGhvcGUgdGhhdCBmdXJ0aGVyIGRpc2N1c3Npb24gZ2l2 ZXMgdXMgDQogIGE8QlI+Jmd0OyBjb25zZW5zdXMuIjxCUj4mZ3Q7PEJSPiZndDsgTm93LCBJ IHJlYWxpemUgdGhhdCB0aGVyZSBhcmUgbm93IG5ldyANCiAgY2hhaXJzLCBidXQgSSBkb24n dCB0aGluayB0aGF0PEJSPiZndDsgc2hvdWxkIGNoYW5nZSB0aGUgV0cgY29uc2Vuc3VzIGZy b20gdGhlIA0KICBTSVAgV0cgc2Vzc2lvbi48QlI+PEJSPkhvd2V2ZXIsIHRoZSBtaW51dGVz IGZyb20gSUVURiA3MyByZWFkOjxCUj48QlI+VG9waWM6IA0KICBVUkkgYW5kIFBhcmFtZXRl ciBEZWxpdmVyeTxCUj5MZWQgYnkgSm9uYWF0aGFuIFJvc2VuYmVyZzxCUj5TbGlkZXMgDQog IHByZXNlbnRlZDxCUj48QSANCiAgaHJlZj0iaHR0cDovL3Rvb2xzLmlldGYub3JnL2lkL2Ry YWZ0LXJvc2VuYmVyZy1zaXAtdGFyZ2V0LXVyaS1kZWxpdmVyeS0wMC50eHQiIA0KICB0YXJn ZXQ9X2JsYW5rPmh0dHA6Ly90b29scy5pZXRmLm9yZy9pZC9kcmFmdC1yb3NlbmJlcmctc2lw LXRhcmdldC11cmktZGVsaXZlcnktMDAudHh0PC9BPjxCUj48QlI+Li4uPEJSPjxCUj5Qb2xs OiANCiAgU2hhbGwgV0cgYWRvcHQgdGhpcyBkcmFmdCB0b3dhcmRzIG91ciBjaGFydGVyIGRl bGl2ZXJhYmxlIG9uIHRoZTxCUj50b3BpYz8gDQogIENoYWlycyByZXBvcnRlZCBhIHN0cm9u ZyBjb25zZW5zdXMgdG8gZG8gc28uPEJSPlNvIHdoaWNoIFdHIGNvbnNlbnN1cyBvZiB3aGlj aCANCiAgU0lQIFdHIHNlc3Npb24gZG8geW91IG5vdCB3YW50IHRvIGNoYW5nZT88QlI+PEJS PjxCUj48QlI+Jmd0OzxCUj4mZ3Q7IEl0IHdhcyANCiAgbXkgdW5kZXJzdGFuZGluZyBmcm9t IHRoZSBtaW51dGVzIHRoYXQgdGhlIGRpc2N1c3Npb24gd2FzIHRvPEJSPiZndDsgY29udGlu dWUgDQogIGFzIHRvIHdoZXRoZXIgd2Ugd291bGQgbWVyZ2UgdGhlIHR3byBkb2N1bWVudHMg b3IgYWdyZWUgb25lPEJSPiZndDsgb3IgdGhlIA0KICBvdGhlciBhcyBhIFdHIGRlbGl2ZXJh YmxlLjxCUj4mZ3Q7PEJSPjxCUj48QlI+VGhhdCdzIGFsc28gY29uc2lzdGVudCB3aXRoIG15 IA0KICBub3RlcyBmcm9tIFNJUCBhdCA3NC48QlI+PEJSPk15IGJlc3QgZ3Vlc3MgaXMgdGhh dCBSRkMgNDI0NGJpcyBnb2VzIGZvcndhcmQsIA0KICBhbmQgdGhhdCB0YXJnZXQtdXJpLTxC Uj5kZWxpdmVyeSB0dXJucyBpbnRvIGEgIkhvdyB0byB1c2UgSC1JIHRvIG1lZXQgdGhlIFVS SSANCiAgZGVsaXZlcnkgdXNlPEJSPmNhc2VzIiANCiAgZG9jdW1lbnQuPEJSPjxCUj4tLTxC Uj5EZWFuPEJSPjxCUj48QlI+PEJSPjxCUj5fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXzxCUj5zaXBjb3JlIA0KICBtYWlsaW5nIGxpc3Q8QlI+PEEg aHJlZj0ibWFpbHRvOnNpcGNvcmVAaWV0Zi5vcmciPnNpcGNvcmVAaWV0Zi5vcmc8L0E+PEJS PjxBIA0KICBocmVmPSJodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Np cGNvcmUiIA0KICB0YXJnZXQ9X2JsYW5rPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4v bGlzdGluZm8vc2lwY29yZTwvQT48QlI+PC9CTE9DS1FVT1RFPjwvRElWPjxCUj4tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0gDQo8QlI+VGhpcyB0cmFuc21pc3Npb24gKGluY2x1ZGluZyBhbnkgYXR0YWNo bWVudHMpIG1heSBjb250YWluIGNvbmZpZGVudGlhbCANCmluZm9ybWF0aW9uLCBwcml2aWxl Z2VkIG1hdGVyaWFsIChpbmNsdWRpbmcgbWF0ZXJpYWwgcHJvdGVjdGVkIGJ5IHRoZSANCnNv bGljaXRvci1jbGllbnQgb3Igb3RoZXIgYXBwbGljYWJsZSBwcml2aWxlZ2VzKSwgb3IgY29u c3RpdHV0ZSBub24tcHVibGljIA0KaW5mb3JtYXRpb24uIEFueSB1c2Ugb2YgdGhpcyBpbmZv cm1hdGlvbiBieSBhbnlvbmUgb3RoZXIgdGhhbiB0aGUgaW50ZW5kZWQgDQpyZWNpcGllbnQg aXMgcHJvaGliaXRlZC4gSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyB0cmFuc21pc3Npb24g aW4gZXJyb3IsIHBsZWFzZSANCmltbWVkaWF0ZWx5IHJlcGx5IHRvIHRoZSBzZW5kZXIgYW5k IGRlbGV0ZSB0aGlzIGluZm9ybWF0aW9uIGZyb20geW91ciBzeXN0ZW0uIA0KVXNlLCBkaXNz ZW1pbmF0aW9uLCBkaXN0cmlidXRpb24sIG9yIHJlcHJvZHVjdGlvbiBvZiB0aGlzIHRyYW5z bWlzc2lvbiBieSANCnVuaW50ZW5kZWQgcmVjaXBpZW50cyBpcyBub3QgYXV0aG9yaXplZCBh bmQgbWF5IGJlIHVubGF3ZnVsLiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0gPGJyPg0KVGhpcyB0cmFuc21p c3Npb24gKGluY2x1ZGluZyBhbnkgYXR0YWNobWVudHMpIG1heSBjb250YWluIGNvbmZpZGVu dGlhbCBpbmZvcm1hdGlvbiwgcHJpdmlsZWdlZCBtYXRlcmlhbCAoaW5jbHVkaW5nIG1hdGVy aWFsIHByb3RlY3RlZCBieSB0aGUgc29saWNpdG9yLWNsaWVudCBvciBvdGhlciBhcHBsaWNh YmxlIHByaXZpbGVnZXMpLCBvciBjb25zdGl0dXRlIG5vbi1wdWJsaWMgaW5mb3JtYXRpb24u IEFueSB1c2Ugb2YgdGhpcyBpbmZvcm1hdGlvbiBieSBhbnlvbmUgb3RoZXIgdGhhbiB0aGUg aW50ZW5kZWQgcmVjaXBpZW50IGlzIHByb2hpYml0ZWQuIElmIHlvdSBoYXZlIHJlY2VpdmVk IHRoaXMgdHJhbnNtaXNzaW9uIGluIGVycm9yLCBwbGVhc2UgaW1tZWRpYXRlbHkgcmVwbHkg dG8gdGhlIHNlbmRlciBhbmQgZGVsZXRlIHRoaXMgaW5mb3JtYXRpb24gZnJvbSB5b3VyIHN5 c3RlbS4gVXNlLCBkaXNzZW1pbmF0aW9uLCBkaXN0cmlidXRpb24sIG9yIHJlcHJvZHVjdGlv biBvZiB0aGlzIHRyYW5zbWlzc2lvbiBieSB1bmludGVuZGVkIHJlY2lwaWVudHMgaXMgbm90 IGF1dGhvcml6ZWQgYW5kIG1heSBiZSB1bmxhd2Z1bC4NCjwvQk9EWT48L0hUTUw+DQo= ------_=_NextPart_001_01C9BEF3.46701461-- From drage@alcatel-lucent.com Thu Apr 16 17:29:53 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5D5413A691B for ; Thu, 16 Apr 2009 17:29:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.018 X-Spam-Level: X-Spam-Status: No, score=-6.018 tagged_above=-999 required=5 tests=[AWL=0.231, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gwg24qWHi5D8 for ; Thu, 16 Apr 2009 17:29:52 -0700 (PDT) Received: from smail2.alcatel.fr (smail2.alcatel.fr [62.23.212.57]) by core3.amsl.com (Postfix) with ESMTP id DC9AB3A6917 for ; Thu, 16 Apr 2009 17:29:51 -0700 (PDT) Received: from FRMRSSXCHHUB02.dc-m.alcatel-lucent.com (FRMRSSXCHHUB02.dc-m.alcatel-lucent.com [135.120.45.62]) by smail2.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id n3H0Uw6p002303 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 17 Apr 2009 02:30:58 +0200 Received: from FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com ([135.120.45.39]) by FRMRSSXCHHUB02.dc-m.alcatel-lucent.com ([135.120.45.62]) with mapi; Fri, 17 Apr 2009 02:30:57 +0200 From: "DRAGE, Keith (Keith)" To: Adam Roach Date: Fri, 17 Apr 2009 02:30:54 +0200 Thread-Topic: [sipcore] Do we really want to reopen the RAI re-org discussion? (was Re: Call for Consensus: Additional Working Group Items) Thread-Index: Acm+7kegYSxRU5XfTDaXTKNYqwhLAQAA0geA Message-ID: <28B7C3AA2A7ABA4A841F11217ABE78D6758C6064@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> References: <49E7BA8B.7060107@nostrum.com> <28B7C3AA2A7ABA4A841F11217ABE78D6758C605F@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <49E7C483.8080400@nostrum.com> In-Reply-To: <49E7C483.8080400@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="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 155.132.188.80 Cc: SIPCORE , Hadriel Kaplan Subject: Re: [sipcore] Do we really want to reopen the RAI re-org discussion? (was Re: Call for Consensus: Additional Working Group Items) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Apr 2009 00:29:53 -0000 U2FpZCBleHRyYWN0IG9idmlvdXNseSBkb2VzIG5vdCBhcHBseSB0bw0KDQpodHRwOi8vdG9vbHMu aWV0Zi5vcmcvaHRtbC9kcmFmdC1uaWVtaS1zaXBwaW5nLWV2ZW50LXRocm90dGxlLTA4DQoNCk5v dCB0aGF0IEkgYW0gb2JqZWN0aW5nLCBidXQgdGhlIHJhdGlvbmFsZSBkb2VzIGhhdmUgYSBkaXJ0 eSBncmVhdCBob2xlIGluIGl0Lg0KDQpJdHMgc3RhdHVzIGZyb20gSUVURiA3NCBpcyB0aGF0IFNJ UCBhbmQgU0lQUElORyBpbiBzZXNzaW9uIDMgKHdoZXJlIGZvcm1hbGx5IHdlIHdlcmUgU0lQUElO RykgYWdyZWVkIHRvIG1vdmUgZm9yd2FyZCBvbiB0aGUgZG9jdW1lbnQsIGJ1dCBvYnZpb3VzbHkg d2VyZSBub3QgZW1wb3dlcmVkIHRvIG1ha2UgYW55IGRlY2lzaW9ucyBhcyB0byB3aGVyZSBpdCBl bmRlZCB1cC4gSSB2YWd1ZWx5IHJlbWVtYmVyIHByZXZpb3VzIG9mZmxpbmUgZGlzY3Vzc2lvbnMg KGZyb20gYWJvdXQgMTIgbW9udGhzIGFnbykgd2hpY2ggc2FpZCB0aGF0IGlmIGl0IHdlbnQgZm9y d2FyZCBpdCB3b3VsZCBzdGF5IGluIFNJUFBJTkcuDQoNCkFzIEkgc2FpZCwgSSBjb3VsZCB1bmRl cnN0YW5kIGl0IGxhbmRpbmcgaW4gU0lQQ09SRSBpZiBpdCB1cGRhdGVkIFJGQyAzMjY1LCBidXQg SSBoYWQgdGhhdCBkaXNjdXNzaW9uIGFuZCB3YXMgcm91bmRseSBiZWF0ZW4gaW50byBzdWJtaXNz aW9uLg0KDQpLZWl0aCANCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBB ZGFtIFJvYWNoIFttYWlsdG86YWRhbUBub3N0cnVtLmNvbV0gDQo+IFNlbnQ6IEZyaWRheSwgQXBy aWwgMTcsIDIwMDkgMTI6NTIgQU0NCj4gVG86IERSQUdFLCBLZWl0aCAoS2VpdGgpDQo+IENjOiBF cmljIEJ1cmdlcjsgU0lQQ09SRTsgSGFkcmllbCBLYXBsYW4NCj4gU3ViamVjdDogUmU6IFtzaXBj b3JlXSBEbyB3ZSByZWFsbHkgd2FudCB0byByZW9wZW4gdGhlIFJBSSANCj4gcmUtb3JnIGRpc2N1 c3Npb24/ICh3YXMgUmU6IENhbGwgZm9yIENvbnNlbnN1czogQWRkaXRpb25hbCANCj4gV29ya2lu ZyBHcm91cCBJdGVtcykNCj4gDQo+IEtlaXRoOg0KPiANCj4gSSBhbSByZWZlcnJpbmcgdG8gdGhl IGZvbGxvd2luZyB0ZXh0LCB3aGljaCBhcHBlYXJzIGluIHRoZSANCj4gcHJvcG9zZWQgU0lQQ09S RSBjaGFydGVyIGF0IGxlYXN0IGFzIGVhcmx5IGFzIEZlYnJ1YXJ5Og0KPiANCj4gPiAgIEFsdGhv dWdoIGluIGdlbmVyYWwgdGhlIFdHIHdpbGwgbm90IHdvcmsgb24gZXh0ZW5zaW9ucyB0byBTSVAs IGl0DQo+ID4gICBtYXkgdGFrZSBvbiBzb21lIHByZXZpb3VzIHdvcmsgaXRlbXMgZnJvbSB0aGUg U0lQIHdvcmtpbmcgZ3JvdXANCj4gPiAgIHRvIGFsbG93IGZvciBhIHNtb290aCB0cmFuc2l0aW9u LiANCj4gDQo+IC9hDQo+IA0KPiANCj4gRFJBR0UsIEtlaXRoIChLZWl0aCkgd3JvdGU6DQo+ID4g RXhjZXB0IHRoYXQgdGhlIG1pbGVzdG9uZXMgdGhlbXNlbHZlcyB3ZXJlIGEgZGVjaXNpb24gb2Yg DQo+IHRoZSBBRHMgYW5kIGRpZCBub3QgZ2V0IGxpc3QgZGlzY3Vzc2lvbi4gSW4gZmFjdCBtaWxl c3RvbmVzIA0KPiB3ZXJlIGJlaW5nIGFkZGVkIGFuZCBkZWxldGVkIGZyb20gdGhlIGNoYXJ0ZXJz IGV2ZW4gb24gTW9uZGF5IA0KPiBldmVuaW5nIChteSB0aW1lKS4gVGhlIGNoYXJ0ZXJzIHRoZW1z ZWx2ZXMgd2VyZSBwYXJ0IG9mIHRoZSANCj4gUkFJIHJlb3JnIGRpc2N1c3Npb25zLCBidXQgdGhl IG1pbGVzdG9uZXMgd2VyZSBub3QuIFNvIEkgZG8gDQo+IG5vdCBzZWUgaG93IGEgZGlzY3Vzc2lv biBvZiB0aGVtIGNhbiBiZSBhIHJlb3BlbmluZy4NCj4gPg0KPiA+IFlvdSBjYW4gaXNzdWUgYSBk aXJlY3Rpb24gYWJvdXQgd2hldGhlciB0aGUgYXBwcm9wcmlhdGUgDQo+IHBsYWNlIHRvIGRpc2N1 c3MgdGhlIFNJUENPUkUgbWlsZXN0b25lcyB0aGF0IHRoZXkgaGF2ZSBiZWVuIA0KPiBhbGxvY2F0 ZWQgaXMgdGhlIHRoZSBTSVBDT1JFIG9yIFJBSSBsaXN0LCBidXQgaXQgZG9lcyBub3QgDQo+IHJl b3BlbiBhIGRpc2N1c3Npb24uDQo+ID4NCj4gPiBJIG11c3QgYWRtaXQgSSBhbSBhIGJpdCBiZW11 c2VkIGJ5IHRoZSBhbGxvY2F0aW9uIG9mIHRoZSANCj4gdGhyb3R0bGluZyBvbmUsIGJlY2F1c2Ug SSBkbyByZW1lbWJlciBoYXZpbmcgYSBkaXNjdXNzaW9uIA0KPiBzb21lIHRpbWUgYmFjayB3aGVy ZSBJIGFza2VkLCBpZiBmb3Igc29tZSByZWFzb24gd2Ugd2VyZSANCj4gcmVpc3N1aW5nIFJGQyAz MjY1IHdvdWxkIHRoZSB0aHJvdHRsaW5nIGZvcm0gcGFydCBvZiBpdCwgYW5kIA0KPiBJIHdhcyBh c3N1cmVkIGluIG5vIHVuY2VydGFpbiB0ZXJtcyB0aGF0IGl0IHdhcyBhIHRvdGFsbHkgDQo+IHNl cGFyYXRlIGFuZCBpbmRlcGVuZGVudCBleHRlbnNpb24uIE5vdyBpZiB0aGUgYW5zd2VyIHRvIHRo YXQgDQo+IGhhZCBiZWVuIFlFUyByYXRoZXIgdGhhbiBOTywgSSBjb3VsZCB1bmRlcnN0YW5kIGl0 IGJlaW5nIA0KPiBhbGxvY2F0ZWQgdG8gU0lQQ09SRS4NCj4gPg0KPiA+IFRoZSB0YXJnZXQtdXJp IG9uZSBJIGRvIHVuZGVyc3RhbmQsIGJlY2F1c2UgYmFzaWNhbGx5IGlmIA0KPiBSRkMgMzI2MSB3 YXMgZXZlciByZWlzc3N1ZWQsIHRoZXJlIGlzIGEgc3Ryb25nIHZpZXcgdGhhdCANCj4gSGlzdG9y eS1JbmZvIHdvdWxkIGZvcm0gcGFydCBvZiB0aGF0IHJlaXNzdWUuIEluIG15IHZpZXcgDQo+IHRh cmdldC11cmkgaXMgcGFydCBvZiB0aGF0IHNjb3BlLiBIb3dldmVyIG1vcmUgb24gdGhhdCBpbiBh IA0KPiBzZXBhcmF0ZSBtYWlsLg0KPiA+DQo+ID4gS2VpdGgNCj4gPg0KPiA+DQo+ID4NCj4gPg0K PiA+DQo+ID4gICAgDQo+ID4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4+IEZyb206 IHNpcGNvcmUtYm91bmNlc0BpZXRmLm9yZw0KPiA+PiBbbWFpbHRvOnNpcGNvcmUtYm91bmNlc0Bp ZXRmLm9yZ10gT24gQmVoYWxmIE9mIEFkYW0gUm9hY2gNCj4gPj4gU2VudDogRnJpZGF5LCBBcHJp bCAxNywgMjAwOSAxMjowOSBBTQ0KPiA+PiBUbzogRXJpYyBCdXJnZXINCj4gPj4gQ2M6IFNJUENP UkU7IEhhZHJpZWwgS2FwbGFuDQo+ID4+IFN1YmplY3Q6IFtzaXBjb3JlXSBEbyB3ZSByZWFsbHkg d2FudCB0byByZW9wZW4gdGhlIFJBSSByZS1vcmcgDQo+ID4+IGRpc2N1c3Npb24/ICh3YXMgUmU6 IENhbGwgZm9yIENvbnNlbnN1czogQWRkaXRpb25hbCBXb3JraW5nIEdyb3VwIA0KPiA+PiBJdGVt cykNCj4gPj4NCj4gPj4gW2FzIGNoYWlyXQ0KPiA+Pg0KPiA+PiBUaGF0J3MgYSBjb21wbGV0ZWx5 IGRpZmZlcmVudCB0b3BpYy4gSSBjYW4ndCBzdG9wIHlvdSBmcm9tIA0KPiByZS1vcGVuaW5nIA0K PiA+PiB0aGUgZGlzY3Vzc2lvbiBvZiBob3cgdG8gaGFuZGxlIFNJUCBhbmQgU0lQUElORyBtaWxl c3RvbmVzIA0KPiB0aGF0IHdvdWxkIA0KPiA+PiBvdGhlcndpc2UgYmUgb3JwaGFuZWQsIGJ1dCBJ IHdpbGwgYXNrIHlvdSB0byB0YWtlIGl0IA0KPiBlbHNld2hlcmUuIFRoZSANCj4gPj4gcGxhY2Ug eW91IHdvdWxkIGdvIHRvIHJlLW9wZW4gdGhlIFJBSSByZS1vcmcgZGlzY3Vzc2lvbiBpcyB0aGUg UkFJIA0KPiA+PiBtYWlsaW5nIGxpc3QuIEkgc3VzcGVjdCBtYW55IGludGVyZXN0ZWQgcGFydGll cyB3b3VsZCB2aWV3IA0KPiByZS1vcGVuaW5nIA0KPiA+PiB0aGF0IHBhcnRpY3VsYXIgdG9waWMg dG8gYmUgdW5uZWNlc3NhcmlseSBkaXNydXB0aXZlLg0KPiA+Pg0KPiA+PiAvYQ0KPiA+Pg0KPiA+ PiBFcmljIEJ1cmdlciB3cm90ZToNCj4gPj4gICAgICANCj4gPj4+IEFuZCBIYWRyaWVsIGlzIHNh eWluZyB0aGV5IGFyZSBub3QgQ29yZS4NCj4gPj4+DQo+ID4+PiBPbiBBcHIgMTcsIDIwMDksIGF0 IDY6MzkgQU0sIEFkYW0gUm9hY2ggd3JvdGU6DQo+ID4+Pg0KPiA+Pj4gICAgICAgIA0KPiA+Pj4+ IFthcyBjaGFpcl0NCj4gPj4+Pg0KPiA+Pj4+IEhhZHJpZWwgS2FwbGFuIHdyb3RlOg0KPiA+Pj4+ ICAgICAgICAgIA0KPiA+Pj4+Pj4gQXQgMDE6MjYgUE0gNC8xNi8yMDA5LCBBZGFtIFJvYWNoIHdy b3RlOg0KPiA+Pj4+Pj4gRGVsaXZlcmluZyByZXF1ZXN0LVVSSSBhbmQgcGFyYW1ldGVycyB0byBV QVMgdmlhIHByb3h5ICAgIChQUykNCj4gPj4+Pj4+ICAgICBkcmFmdC1yb3NlbmJlcmctc2lwLXRh cmdldC11cmktZGVsaXZlcnkNCj4gPj4+Pj4+ICAgICBbYWRvcHRlZCBieSBTSVAgV0cgY29uc2Vu c3VzIGFmdGVyIElFVEYgNzMsIHN0aWxsIA0KPiB3YWl0aW5nIGZvciANCj4gPj4+Pj4+IG5ldyB2 ZXJzaW9uXQ0KPiA+Pj4+Pj4NCj4gPj4+Pj4+IFNJUCBFdmVudHMgdGhyb3R0bGluZyBtZWNoYW5p c20gICAgKFBTKQ0KPiA+Pj4+Pj4gICAgIGRyYWZ0LW5pZW1pLXNpcHBpbmctZXZlbnQtdGhyb3R0 bGUNCj4gPj4+Pj4+ICAgICBbU0lQUElORyBXRyBpbmRpY2F0ZWQgZGVzaXJlIHRvIGFkb3B0IGlu IGFzIFNJUCBXRw0KPiA+Pj4+Pj4gICAgICAgICAgICAgIA0KPiA+PiBpdGVtIGF0IElFVEYNCj4g Pj4gICAgICANCj4gPj4+Pj4+IDc0XQ0KPiA+Pj4+Pj4gICAgICAgICAgICAgIA0KPiA+Pj4+PiBN eSB2b3RlIGlzIHRvIGFkb3B0IG5laXRoZXIgaW4gdGhpcyBXRy4gIE5laXRoZXIgb2YgdGhlbQ0K PiA+Pj4+PiAgICAgICAgICAgIA0KPiA+PiB1cGRhdGUgbm9yDQo+ID4+ICAgICAgDQo+ID4+Pj4+ IHJlcGxhY2UgMzI2MS0zMjY1Lg0KPiA+Pj4+PiAgICAgICAgICAgIA0KPiA+Pj4+IFRvIGJlIGNs ZWFyLCB0aGUgcXVlc3Rpb24gd2UgYXJlIGFza2luZyBpcyBub3QgImFyZSB0aGVzZQ0KPiA+Pj4+ ICAgICAgICAgIA0KPiA+PiBtaWxlc3RvbmVzDQo+ID4+ICAgICAgDQo+ID4+Pj4gb2theSIgKHRo YXQgZGlzY3Vzc2lvbiBoYXMgYWxyZWFkeSBjb25jbHVkZWQgb24gdGhlIFJBSQ0KPiA+Pj4+ICAg ICAgICAgIA0KPiA+PiBsaXN0KSAtLSBpdA0KPiA+PiAgICAgIA0KPiA+Pj4+IGlzICJzaG91bGQg d2UgdGFrZSBvbiB0aGVzZSBzcGVjaWZpYyBkb2N1bWVudHMgdG8gc2F0aXNmeQ0KPiA+Pj4+ICAg ICAgICAgIA0KPiA+PiB0aGUgdGhlc2UNCj4gPj4gICAgICANCj4gPj4+PiB0d28gbWlsZXN0b25l cyB0aGF0IGFyZSBhbHJlYWR5IHBhcnQgb2YgdGhlIFNJUENPUkUgY2hhcnRlci4iDQo+ID4+Pj4N Cj4gPj4+PiAvYQ0KPiA+Pj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fDQo+ID4+Pj4gc2lwY29yZSBtYWlsaW5nIGxpc3QNCj4gPj4+PiBzaXBjb3JlQGll dGYub3JnDQo+ID4+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zaXBj b3JlDQo+ID4+Pj4gICAgICAgICAgDQo+ID4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQo+ID4+IHNpcGNvcmUgbWFpbGluZyBsaXN0DQo+ID4+IHNpcGNv cmVAaWV0Zi5vcmcNCj4gPj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9z aXBjb3JlDQo+ID4+ICAgICAgDQo+IA0KPiA= From mary.barnes@nortel.com Thu Apr 16 18:26:33 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 78E4E3A69CC for ; Thu, 16 Apr 2009 18:26:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.463 X-Spam-Level: X-Spam-Status: No, score=-6.463 tagged_above=-999 required=5 tests=[AWL=0.135, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pztN6fpPVN7y for ; Thu, 16 Apr 2009 18:26:31 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id D64BF3A6802 for ; Thu, 16 Apr 2009 18:26:30 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id n3H1RdP02736; Fri, 17 Apr 2009 01:27:39 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C9BEFB.98704989" Date: Thu, 16 Apr 2009 20:29:45 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF1D7FA131@zrc2hxm0.corp.nortel.com> In-Reply-To: <61968779B8AC4C4BAB421D4C12F008C015FEA2B1@XCH47YKF.rim.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] Target-uri document as SIPCORE WG document? (was RE:[Sip] SIPCORE -- If you're not subscribed, you're missing stuff Thread-Index: Acm+2VlZABnKJIMzQmy6h7q6thF4/gAAZt8gAACTQZQAACG6sAAFX0/WAAHeVrA= References: <61968779B8AC4C4BAB421D4C12F008C015FEA2B1@XCH47YKF.rim.net> From: "Mary Barnes" To: "Andrew Allen" , Cc: sipcore@ietf.org Subject: Re: [sipcore] Target-uri document as SIPCORE WG document? (was RE:[Sip] SIPCORE -- If you're not subscribed, you're missing stuff X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Apr 2009 01:26:33 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9BEFB.98704989 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Andrew, =20 Thanks for the clarification. On the security point, if the WG would agree that the same security considerations as in 4244 apply to target-uri - i.e., no more/no less, then yes, there's not an issue. As I understand it, the issue is that the bar is quite high in 4244 (e.g., TLS mandated), so the answer is that no one that has implemented it likely meets that security requirement. And, yes it is a big can of worms, just like any other security discussion is for SIP. But, what I'm trying to say is that if folks do believe the current security in 4244 is not adequate or implementable, then target-uri would have the same issue and thus need to address any concerns with 4244 security to be complete. Based on my experience with more recent RFCs, the bar for the security requirements and considerations for documents is significantly higher than it was when 4244 was published.=20 =20 Thus, there is no difference at all between progressing 4244bis versus target-uri, except that I think it is actually more difficult to properly define the normative processing for target-uri in a separate document than rely on the existing structure and text in 4244. =20 =20 Mary. =20 ________________________________ From: Andrew Allen [mailto:aallen@rim.com]=20 Sent: Thursday, April 16, 2009 7:27 PM To: Barnes, Mary (RICH2:AR00); ietf.hanserik@gmail.com Cc: sipcore@ietf.org Subject: Re: [sipcore] Target-uri document as SIPCORE WG document? (was RE:[Sip] SIPCORE -- If you're not subscribed, you're missing stuff My understanding of the outcome in San Francisco was that target-uri would update 4244 and 4244bis would be worked on in parallel and potentially obsolete both 4244 and target-uri.=20 Whatever is developed for target-uri ought to be able to be incorporated in 4244bis. If 4244 progresses well then target-uri may not need ultimately to be published separately.=20 I am afraid that the security question to be addressed by 4244bis is a big can of worms that is likely to be a long discussion. Is there a reason why target-uri can't progress under the current History-Info security framework? Is the security solution for 4244 actually technically broken or is it just that people don't implement it? There is not a draft dependecy on target-uri for GRUU but it was clearly identified during GRUU development that a lot of use cases for GRUU really need to know that the Request was addressed to a particular GRUU and without target-uri that functionality cannot be achieved.=20 ________________________________ From: Mary Barnes =20 To: Andrew Allen; ietf.hanserik@gmail.com =20 Cc: sipcore@ietf.org =20 Sent: Thu Apr 16 18:03:42 2009 Subject: RE: [sipcore] Target-uri document as SIPCORE WG document? (was RE:[Sip] SIPCORE -- If you're not subscribed, you're missing stuff=20 A few comments below [MB].=20 ________________________________ From: Andrew Allen [mailto:aallen@rim.com]=20 Sent: Thursday, April 16, 2009 4:50 PM To: Barnes, Mary (RICH2:AR00); ietf.hanserik@gmail.com Cc: sipcore@ietf.org Subject: Re: [sipcore] Target-uri document as SIPCORE WG document? (was RE:[Sip] SIPCORE -- If you're not subscribed, you're missing stuff My understanding was that we would move forward with both drafts as WG items. My understanding was that in Dublin Target-uri was adopted as a SIP WG item. I don't want to see 4244bis become a dependency for the target-uri work which is urgently needed to solve some GRUU related issues.=20 [MB] Per my original comments below, the changes for a target-uri solution based on 4244 is actually more work than putting the normative functionality in 4244bis - that's because you still need to address security, privacy, how it is processed by a UAC, Proxy and UAS. You would then need duplicate text to set the context, etc. and that text would be identical to what's in 4244 OR you'd be breaking existing implementations and there are some of those. Now, we did have one reasonable suggestion as to adding a recommendation that the Privacy not be applied to the entire message as that limits proxy functionality - that's important for target-uri, but it's also likely an oversight in the original 4244. [/MB] =20 If 4244bis is ready when target-uri is then we can talk about rolling the two into one but I have concerns that 4244bis will take considerably longer than target-uri based on the discussion in San Fran. =20 [MB] Nope - as I noted earlier, I think the discussion was confounded because people were talking about changes to 4244bis (History-Info) that were well beyond what is required for target-uri - i.e., paring down the functionality to only collect the desired entries, which doesn't save a bit of work because you still have to recognize the conditions under which you drop the entries. Please listen to Francois' response to Hadriel's suggestion in the audio - it's towards the end. Also, the same security issues apply - when we completed 4244, the security section was carefully crafted based on security thoughts at the time. Those have changed (obviously) and if they are problematic in 4244bis, they would be a problem for the target-uri usage of 4244, which has the same security requirements as core 4244. [/MB] Target-uri has been needed really for GRUU for more then 2 years and is fairly straightforward. I don't think we should risk delaying that work waiting for 4244bis which seems to contain a number of issues we don't have consensus on yet.=20 [MB] The other changes to 4244bis are minor as compared to the normative functionality that needs to be added to the document to support target-uri. Please look at the diff. I also don't see the GRUU dependency - can you please clarify? I know GRUU is waiting for Outbound (I promise I will give up if 4244bis reaches a point where it is taking longer to finish than Outbound) and that the gruu-reg-event pkg is waiting for GRUU. [/MB]=20 That was my understanding of the approach we determined in San Francisco. ________________________________ From: sipcore-bounces@ietf.org =20 To: Hans Erik van Elburg =20 Cc: sipcore@ietf.org =20 Sent: Thu Apr 16 17:34:57 2009 Subject: Re: [sipcore] Target-uri document as SIPCORE WG document? (was RE:[Sip] SIPCORE -- If you're not subscribed, you're missing stuff=20 No - the discussion for 4244(bis) (extracted below) was entirely in the context of the discussion for the target-uri document. You can go back and listen to the audio to verify that. And, I've stated long before IETF-73 that it would be fairly straightforward to update 4244 to accomodate the target-uri requirements and while we were doing that, there were a few other fixes we could do.=20 =20 Mary.=20 ________________________________ From: Hans Erik van Elburg [mailto:ietf.hanserik@gmail.com]=20 Sent: Thursday, April 16, 2009 4:22 PM To: Barnes, Mary (RICH2:AR00) Cc: Dean Willis; sipcore@ietf.org Subject: Re: [sipcore] Target-uri document as SIPCORE WG document? (was RE: [Sip] SIPCORE -- If you're not subscribed, you're missing stuff Hi Mary, I believe that in the absence of consensus as the minutes correctly state, the the target-uri document should remain the WG document for the target-uri deliverable. 4424bis has another purpose, namely to fix the 4424. If at a certain moment in time it turns out that 4424bis is the appropriate document to contain normative text for target uri delivery then we can always decide to do so. At this stage it is to early to take that decision, given the confused state of the target-uri discussion. /Hans Erik van Elburg On Thu, Apr 16, 2009 at 10:02 PM, Mary Barnes wrote: I'm suggesting to change the decision from IETF-73 and accept the more recent realization that including normative text in another document rather than 4244bis will be fraught with error and I can't see how that is a good idea from a development perspective - you can't just implement the target-uri document. =09 Now, I don't have a problem if folks can accept that the target-uri document might change such that the normative functionality is in 4244bis. And, this was consensus from IETF-73 per those minutes: "Issue: Normative behavior update for RFC 4244 =09 Consensus noted to revise RFC 4244, and fix some other known problems with it at teh same time. MAry Barnes volunteered to edit the document." =09 So, there is a conflict in terms of accepting target-uri document as the only deliverable for that milestone in the IETF-73 meeting. =09 Mary. =09 =09 -----Original Message----- From: Dean Willis [mailto:dean.willis@softarmor.com] Sent: Thursday, April 16, 2009 2:36 PM To: Barnes, Mary (RICH2:AR00) Cc: sipcore@ietf.org Subject: Re: [sipcore] [Sip] SIPCORE -- If you're not subscribed, you're missing stuff =09 =09 On Apr 16, 2009, at 2:27 PM, Mary Barnes wrote: =09 > I have an issue with the target-uri document being proposed as the WG > document for the target-uri deliverable. This was not the consensus in =09 > SF per my recollection (which may be biased) nor per the SIP WG > minutes: > http://www.ietf.org/proceedings/09mar/minutes/sip.html > > Which state: > "Issue: Progress 4244bis, target-uri draft, or both? > In the absence of a clear consensus, the chairs proposed that both > documents proceed and we'll hope that further discussion gives us a > consensus." > > Now, I realize that there are now new chairs, but I don't think that > should change the WG consensus from the SIP WG session. =09 However, the minutes from IETF 73 read: =09 Topic: URI and Parameter Delivery Led by Jonaathan Rosenberg Slides presented =09 http://tools.ietf.org/id/draft-rosenberg-sip-target-uri-delivery-00.txt =09 ... =09 Poll: Shall WG adopt this draft towards our charter deliverable on the topic? Chairs reported a strong consensus to do so. So which WG consensus of which SIP WG session do you not want to change? =09 =09 =09 > > It was my understanding from the minutes that the discussion was to > continue as to whether we would merge the two documents or agree one > or the other as a WG deliverable. > =09 =09 That's also consistent with my notes from SIP at 74. =09 My best guess is that RFC 4244bis goes forward, and that target-uri- delivery turns into a "How to use H-I to meet the URI delivery use cases" document. =09 -- Dean =09 =09 =09 =09 _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore =09 ---------------------------------------------------------------------=20 This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client 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 immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. ---------------------------------------------------------------------=20 This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client 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 immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.=20 ------_=_NextPart_001_01C9BEFB.98704989 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi=20 Andrew,
 
Thanks=20 for the clarification. On the security point,  if the WG = would=20 agree that the same security considerations as in 4244 apply to = target-uri -=20 i.e., no more/no less, then yes, there's not an issue. As I understand = it, the=20 issue is that the bar is quite high in 4244 (e.g., TLS mandated), so the = answer=20 is that no one that has implemented it likely meets that security=20 requirement.  And, yes it is a big can of worms, just like any = other=20 security discussion is for SIP.  But, what I'm trying to say is = that if=20 folks do believe the current security in 4244 is not adequate or = implementable,=20 then target-uri would have the same issue and thus need to address any = concerns=20 with 4244 security to be complete. Based on my experience with = more=20 recent RFCs, the bar for the security requirements and considerations = for=20 documents is significantly higher than it was when 4244 was published.=20
 
Thus,=20  there is no difference at all between progressing 4244bis versus=20 target-uri, except that I think it is actually more difficult to = properly define=20 the normative processing for target-uri in a separate document than rely = on the=20 existing structure and text in 4244. 
 
Mary.
 
From: Andrew Allen = [mailto:aallen@rim.com]=20
Sent: Thursday, April 16, 2009 7:27 PM
To: Barnes, = Mary=20 (RICH2:AR00); ietf.hanserik@gmail.com
Cc:=20 sipcore@ietf.org
Subject: Re: [sipcore] Target-uri document as = SIPCORE=20 WG document? (was RE:[Sip] SIPCORE -- If you're not subscribed, you're = missing=20 stuff


My understanding of the = outcome in San=20 Francisco was that target-uri would update 4244 and 4244bis would be = worked on=20 in parallel and potentially obsolete both 4244 and target-uri. =

Whatever=20 is developed for target-uri ought to be able to be incorporated in = 4244bis. If=20 4244 progresses well then target-uri may not need ultimately to be = published=20 separately.

I am afraid that the security question to be = addressed by=20 4244bis is a big can of worms that is likely to be a long discussion. Is = there a=20 reason why target-uri can't progress under the current History-Info = security=20 framework? Is the security solution for 4244 actually technically broken = or is=20 it just that people don't implement it?

There is not a draft = dependecy on=20 target-uri for GRUU but it was clearly identified during GRUU = development that a=20 lot of use cases for GRUU really need to know that the Request was = addressed to=20 a particular GRUU and without target-uri that functionality cannot be = achieved.=20

From: Mary Barnes = <mary.barnes@nortel.com>=20
To: Andrew Allen; ietf.hanserik@gmail.com=20 <ietf.hanserik@gmail.com>
Cc: sipcore@ietf.org=20 <sipcore@ietf.org>
Sent: Thu Apr 16 18:03:42=20 2009
Subject: RE: [sipcore] Target-uri document as SIPCORE WG=20 document? (was RE:[Sip] SIPCORE -- If you're not subscribed, you're = missing=20 stuff

A few=20 comments below [MB].

From: Andrew Allen = [mailto:aallen@rim.com]=20
Sent: Thursday, April 16, 2009 4:50 PM
To: Barnes, = Mary=20 (RICH2:AR00); ietf.hanserik@gmail.com
Cc:=20 sipcore@ietf.org
Subject: Re: [sipcore] Target-uri document as = SIPCORE=20 WG document? (was RE:[Sip] SIPCORE -- If you're not subscribed, you're = missing=20 stuff


My understanding was that we would = move forward=20 with both drafts as WG items.

My understanding was that in Dublin = Target-uri was adopted as a SIP WG item. I don't want to see 4244bis = become a=20 dependency for the target-uri work which is urgently needed to solve = some GRUU=20 related issues. 

[MB] Per my original comments below, = the changes for a=20 target-uri solution based on 4244 is actually more work=20 than putting the normative functionality in 4244bis - that's = because=20 you still need to address security, privacy, how it is processed = by a=20 UAC, Proxy and UAS. You would then need duplicate text to set = the=20 context, etc. and that text would be identical to what's in 4244 OR = you'd be=20 breaking existing implementations and there are some of those. Now, we = did have=20 one reasonable suggestion as to adding a recommendation that the Privacy = not be=20 applied to the entire message as that limits proxy functionality - = that's=20 important for target-uri, but it's also likely an oversight in the = original=20 4244. [/MB]  

If 4244bis is ready when = target-uri=20 is then we can talk about rolling the two into one but I have concerns = that=20 4244bis will take considerably longer than target-uri based on the = discussion in=20 San Fran.  

[MB] Nope - as I noted earlier, I think the discussion = was=20 confounded because people were talking about changes to 4244bis=20 (History-Info) that were well beyond what is required for target-uri - = i.e.,=20 paring down the functionality to only collect the desired entries, which = doesn't=20 save a bit of work because you still have to recognize the = conditions under=20 which you drop the entries.  Please listen to Francois' response to = Hadriel's suggestion in the audio - it's towards the end. Also, the same = security issues apply - when we completed 4244, the security section was = carefully crafted based on security thoughts at the time. Those have = changed=20 (obviously) and if they are problematic in 4244bis, they would be a = problem for=20 the target-uri usage of 4244, which has the same security requirements = as core=20 4244.  [/MB]

Target-uri has been needed = really=20 for GRUU for more then 2 years and is fairly straightforward. I don't = think we=20 should risk delaying that work waiting for 4244bis which seems to = contain a=20 number of issues we don't have consensus on yet. 

[MB] The other changes to 4244bis are = minor as=20 compared to the normative functionality that needs to be added to the = document=20 to support target-uri. Please look at the diff.  I also don't see = the GRUU=20 dependency - can you please clarify?  I know GRUU is = waiting for=20 Outbound (I promise I will give up if 4244bis reaches a point where = it is=20 taking longer to finish than Outbound) and that the gruu-reg-event = pkg is=20 waiting for GRUU.  [/MB] 

That was = my=20 understanding of the approach we determined in San=20 Francisco.

From: sipcore-bounces@ietf.org=20 <sipcore-bounces@ietf.org>
To: Hans Erik van Elburg=20 <ietf.hanserik@gmail.com>
Cc: sipcore@ietf.org=20 <sipcore@ietf.org>
Sent: Thu Apr 16 17:34:57=20 2009
Subject: Re: [sipcore] Target-uri document as SIPCORE WG=20 document? (was RE:[Sip] SIPCORE -- If you're not subscribed, you're = missing=20 stuff

No -=20 the discussion for 4244(bis) (extracted below) was entirely in the = context of=20 the discussion for the target-uri document. You can go back and listen = to the=20 audio to verify that.  And, I've stated long before IETF-73 that it = would=20 be fairly straightforward to update 4244 to accomodate the target-uri=20 requirements and while we were doing that, there were a few other fixes = we could=20 do.
 
Mary.=20

From: Hans Erik van Elburg=20 [mailto:ietf.hanserik@gmail.com]
Sent: Thursday, April 16, = 2009 4:22=20 PM
To: Barnes, Mary (RICH2:AR00)
Cc: Dean Willis;=20 sipcore@ietf.org
Subject: Re: [sipcore] Target-uri document as = SIPCORE=20 WG document? (was RE: [Sip] SIPCORE -- If you're not subscribed, you're = missing=20 stuff

Hi Mary,

I believe that in the absence of consensus as = the=20 minutes correctly state, the the target-uri document should remain the = WG=20 document for the target-uri deliverable.

4424bis has another = purpose,=20 namely to fix the 4424. If at a certain moment in time it turns out that = 4424bis=20 is the appropriate document to contain normative text for target uri = delivery=20 then we can always decide to do so. At this stage it is to early to take = that=20 decision, given the confused state of the target-uri discussion.
/Hans Erik van Elburg


On Thu, Apr 16, 2009 at 10:02 PM, Mary Barnes = <mary.barnes@nortel.com>=20 wrote:
I'm=20 suggesting to change the decision from IETF-73 and accept the = more
recent=20 realization that including normative text in another = document
rather than=20 4244bis will be fraught with error and I can't see how that
is a = good idea=20 from a development perspective - you can't just implement
the = target-uri=20 document.

Now, I don't have a problem if folks can accept that = the=20 target-uri
document might change such that the normative = functionality is=20 in
4244bis.   And, this was consensus from IETF-73 per those=20 minutes:
"Issue: Normative behavior update for RFC = 4244

Consensus=20 noted to revise RFC 4244, and fix some other known problems
with it = at teh=20 same time. MAry Barnes volunteered to edit = the
document."

So, there=20 is a conflict in terms of accepting target-uri document as the
only = deliverable for that milestone in the IETF-73=20 meeting.

Mary.


-----Original Message-----
From: = Dean=20 Willis [mailto:dean.willis@softarmor.com]<= BR>Sent:=20 Thursday, April 16, 2009 2:36 PM
To: Barnes, Mary = (RICH2:AR00)
Cc: sipcore@ietf.org
Subject: Re: = [sipcore]=20 [Sip] SIPCORE -- If you're not subscribed, you're
missing=20 stuff


On Apr 16, 2009, at 2:27 PM, Mary Barnes = wrote:

> I=20 have an issue with the target-uri document being proposed as the = WG
>=20 document for the target-uri deliverable. This was not the consensus=20 in

> SF per my recollection (which may be biased) nor per = the SIP=20 WG
> minutes:
> http://www.ietf.org/proceedings/09mar/minutes/sip.html
>
>=20 Which state:
> "Issue: Progress 4244bis, target-uri draft, or=20 both?
> In the absence of a clear consensus, the chairs proposed = that=20 both
> documents proceed and we'll hope that further discussion = gives us=20 a
> consensus."
>
> Now, I realize that there are = now new=20 chairs, but I don't think that
> should change the WG consensus = from the=20 SIP WG session.

However, the minutes from IETF 73 = read:

Topic:=20 URI and Parameter Delivery
Led by Jonaathan Rosenberg
Slides=20 presented
http://tools.ietf.org/id/draft-rosenberg-sip-target-uri-d= elivery-00.txt

...

Poll:=20 Shall WG adopt this draft towards our charter deliverable on = the
topic?=20 Chairs reported a strong consensus to do so.
So which WG consensus = of which=20 SIP WG session do you not want to change?



>
> = It was=20 my understanding from the minutes that the discussion was to
> = continue=20 as to whether we would merge the two documents or agree one
> or = the=20 other as a WG deliverable.
>


That's also consistent = with my=20 notes from SIP at 74.

My best guess is that RFC 4244bis goes = forward,=20 and that target-uri-
delivery turns into a "How to use H-I to meet = the URI=20 delivery use
cases"=20 = document.

--
Dean




__________________________= _____________________
sipcore=20 mailing list
sipcore@ietf.org
https://www.ietf.org/mailman/listinfo/sipcore

------------------------------------------------------= ---------------=20
This transmission (including any attachments) may contain = confidential=20 information, privileged material (including material protected by the=20 solicitor-client or other applicable privileges), or constitute = non-public=20 information. Any use of this information by anyone other than the = intended=20 recipient is prohibited. If you have received this transmission in = error, please=20 immediately reply to the sender and delete this information from your = system.=20 Use, dissemination, distribution, or reproduction of this transmission = by=20 unintended recipients is not authorized and may be unlawful.=20 --------------------------------------------------------------------- =
This=20 transmission (including any attachments) may contain confidential = information,=20 privileged material (including material protected by the = solicitor-client or=20 other applicable privileges), or constitute non-public information. Any = use of=20 this information by anyone other than the intended recipient is = prohibited. If=20 you have received this transmission in error, please immediately reply = to the=20 sender and delete this information from your system. Use, dissemination, = distribution, or reproduction of this transmission by unintended = recipients is=20 not authorized and may be unlawful. ------_=_NextPart_001_01C9BEFB.98704989-- From dwillis@peerance.com Thu Apr 16 18:44:13 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D2FE73A6B23 for ; Thu, 16 Apr 2009 18:44:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.728 X-Spam-Level: X-Spam-Status: No, score=-1.728 tagged_above=-999 required=5 tests=[AWL=0.248, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pSRZo+tIabQ2 for ; Thu, 16 Apr 2009 18:44:13 -0700 (PDT) Received: from mail-qy0-f136.google.com (mail-qy0-f136.google.com [209.85.221.136]) by core3.amsl.com (Postfix) with ESMTP id C788D3A6A36 for ; Thu, 16 Apr 2009 18:44:12 -0700 (PDT) Received: by qyk42 with SMTP id 42so277592qyk.29 for ; Thu, 16 Apr 2009 18:45:25 -0700 (PDT) MIME-Version: 1.0 Sender: dwillis@peerance.com Received: by 10.220.45.212 with SMTP id g20mr1548976vcf.43.1239932725138; Thu, 16 Apr 2009 18:45:25 -0700 (PDT) In-Reply-To: References: <49E777BD.9000202@estacado.net> <49E7785A.9060808@nostrum.com> <49E7B38D.8000603@nostrum.com> Date: Thu, 16 Apr 2009 18:45:24 -0700 X-Google-Sender-Auth: 7875425f5ebe6513 Message-ID: <2210d2240904161845w68a13d09s14b6cd88c51da8fc@mail.gmail.com> From: Dean Willis To: Hadriel Kaplan Content-Type: multipart/alternative; boundary=0016363b8824a0a4e00467b655a0 Cc: SIPCORE Subject: Re: [sipcore] Call for Consensus: Additional Working Group Items X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Apr 2009 01:44:13 -0000 --0016363b8824a0a4e00467b655a0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Yeah, this is why I wanted the cruft either clearly punted to DISPATCH or left in a must-finish-things SIP zombie group. This is going to make future application of charter discipline in SIPCORE very hard. But as usual, not enough people believe me . . . -- dean On Thu, Apr 16, 2009 at 4:21 PM, Hadriel Kaplan wrote: > > Oh, sorry, I misunderstood your question. So we've already got milestones > to tackle the problems, and you're just asking about the specific solution > docs for them. Got it. > Right, then I rescind my original negative response. > Sorry for the confusion. :( > > -hadriel > p.s. though it makes me wonder if we can really decide what goes into > SIPCORE or not a priori, until we agree on what the right solution is to a > problem. Target-uri for instance originally started as an update to 3261 > when it was ua-loose-route I think. But I digress... > > ________________________________________ > From: Adam Roach [mailto:adam@nostrum.com] > Sent: Thursday, April 16, 2009 6:39 PM > To: Hadriel Kaplan > Cc: SIPCORE > Subject: Re: [sipcore] Call for Consensus: Additional Working Group Items > > [as chair] > > Hadriel Kaplan wrote: > At 01:26 PM 4/16/2009, Adam Roach wrote: > Delivering request-URI and parameters to UAS via proxy (PS) > draft-rosenberg-sip-target-uri-delivery > [adopted by SIP WG consensus after IETF 73, still waiting for new > version] > > SIP Events throttling mechanism (PS) > draft-niemi-sipping-event-throttle > [SIPPING WG indicated desire to adopt in as SIP WG item at IETF 74] > > > My vote is to adopt neither in this WG. Neither of them update nor replace > 3261-3265. > > To be clear, the question we are asking is not "are these milestones okay" > (that discussion has already concluded on the RAI list) -- it is "should we > take on these specific documents to satisfy the these two milestones that > are already part of the SIPCORE charter." > > /a > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > > --0016363b8824a0a4e00467b655a0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Yeah, this is why I wanted the cruft either clearly punted to DISPATCH or l= eft in a must-finish-things SIP zombie group. This is going to make future = application of charter discipline in SIPCORE very hard. But as usual, not e= nough people believe me . . .

--
dean

On Thu, Apr 16, 2009 at 4:= 21 PM, Hadriel Kaplan <HKaplan@acmepacket.com> wrote:

Oh, sorry, I misunderstood your question. =A0So we've already got miles= tones to tackle the problems, and you're just asking about the specific= solution docs for them. =A0Got it.
Right, then I rescind my original negative response.
Sorry for the confusion. =A0:(

-hadriel
p.s. though it makes me wonder if we can really decide what goes into SIPCO= RE or not a priori, until we agree on what the right solution is to a probl= em. =A0Target-uri for instance originally started as an update to 3261 when= it was ua-loose-route I think. =A0But I digress...

________________________________________
From: Adam Roach [mailto:adam@nostrum.c= om]
Sent: Thursday, April 16, 2009 6:39 PM
To: Hadriel Kaplan
Cc: SIPCORE
Subject: Re: [sipcore] Call for Consensus: Additional Working Group Items

[as chair]

Hadriel Kaplan wrote:
At 01:26 PM 4/16/2009, Adam Roach wrote:
Delivering request-URI and parameters to UAS via proxy =A0 =A0(PS)
=A0 draft-rosenberg-sip-target-uri-delivery
=A0 [adopted by SIP WG consensus after IETF 73, still waiting for new
version]

SIP Events throttling mechanism =A0 =A0(PS)
=A0 draft-niemi-sipping-event-throttle
=A0 [SIPPING WG indicated desire to adopt in as SIP WG item at IETF 74]

My vote is to adopt neither in this WG. =A0Neither of them update nor repla= ce 3261-3265.

To be clear, the question we are asking is not "are these milestones o= kay" (that discussion has already concluded on the RAI list) -- it is = "should we take on these specific documents to satisfy the these two m= ilestones that are already part of the SIPCORE charter."

/a
_____________________________= __________________
sipcore mailing list
sipcore@ietf.org
https://www.ietf.org/mailman/listinfo/sipcore


--0016363b8824a0a4e00467b655a0-- From aallen@rim.com Thu Apr 16 19:33:28 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AE2C73A6A57 for ; Thu, 16 Apr 2009 19:33:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.767 X-Spam-Level: X-Spam-Status: No, score=-5.767 tagged_above=-999 required=5 tests=[AWL=0.331, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BAD_LINEBREAK=0.5, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1ej3xPibQcjE for ; Thu, 16 Apr 2009 19:33:26 -0700 (PDT) Received: from mhs03ykf.rim.net (mhs03ykf.rim.net [216.9.243.80]) by core3.amsl.com (Postfix) with ESMTP id D5F8F3A698C for ; Thu, 16 Apr 2009 19:33:25 -0700 (PDT) Received: from mhs03ykf.rim.net (unknown [127.0.0.1]) by mhs03ykf.rim.net (Symantec Brightmail Gateway) with ESMTP id 9712258A93; Thu, 16 Apr 2009 22:34:37 -0400 (EDT) X-AuditID: 0a401fcb-ac1b8bb000002ba2-c8-49e7eabdb24c Received: from XCH20YKF.rim.net (unknown [10.102.100.35]) by mhs03ykf.rim.net (Symantec Mail Security) with ESMTP id 2708558A96; Thu, 16 Apr 2009 22:34:37 -0400 (EDT) Received: from XCH47YKF.rim.net ([10.64.31.217]) by XCH20YKF.rim.net with Microsoft SMTPSVC(5.0.2195.6713); Thu, 16 Apr 2009 22:34:36 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C9BF05.0C865B0E" Date: Thu, 16 Apr 2009 22:34:36 -0400 Message-ID: <61968779B8AC4C4BAB421D4C12F008C015FEA2B3@XCH47YKF.rim.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] Target-uri document as SIPCORE WG document? (was RE:[Sip] SIPCORE -- If you're not subscribed, you're missing stuff Thread-Index: Acm+2VlZABnKJIMzQmy6h7q6thF4/gAAZt8gAACTQZQAACG6sAAFX0/WAAHeVrAAApNCWw== From: "Andrew Allen" To: , X-OriginalArrivalTime: 17 Apr 2009 02:34:36.0903 (UTC) FILETIME=[0CE7CF70:01C9BF05] X-Tracking: ONC3m79J7f57zp0jFVtWxPxr7v2VYI3kBbb X-Brightmail-Tracker: AAAAAQ5kh/8= Cc: sipcore@ietf.org Subject: Re: [sipcore] Target-uri document as SIPCORE WG document? (was RE:[Sip] SIPCORE -- If you're not subscribed, you're missing stuff X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Apr 2009 02:33:28 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9BF05.0C865B0E Content-Type: text/plain; charset="utf-8" content-transfer-encoding: base64 DQpBdCBsZWFzdCBpbiBteSBtaW5kIHRhcmdldC11cmkgaXMganVzdCBhIG1pbm9yIGVuaGFu Y2VtZW50L2V4dGVuc2lvbiB0byBIaXN0b3J5LUluZm8gdG8gYWRkcmVzcyB0aGUgaXNzdWUg b2YgcmV3cml0aW5nIHRoZSBSZXF1ZXN0LVVSSSB3aXRoIHRoZSBjb250YWN0LiBEb2VzIHRh cmdldC11cmkgdXNhZ2UgaW50cm9kdWNlIHNvbWUgbmV3IHNlY3VyaXR5IGNvbmNlcm4gb3Zl ciBhbmQgYWJvdmUgZXhpc3RpbmcgdXNlcyBvZiBIaXN0b3J5LUluZm8gaW4gUkZDIDQyNDQ/ IElmIG5vdCB0aGVuIEkgZG9uJ3QgdGhpbmsgaXRzIGZhaXIgdG8gZGVsYXkgYSBzb2x1dGlv biB0byB0aGUgdGFyZ2V0LXVyaSBwcm9ibGVtIHNwYWNlIHdoaWxlIHdlIGdvIG9mZiBhbmQg YXR0ZW1wdCB0byBjb21lIHVwIHdpdGggYSBuZXcgaW1wcm92ZWQgc2VjdXJpdHkgc29sdXRp b24gb3ZlciBhbmQgYWJvdmUgd2hhdCBpcyBhbHJlYWR5IGluIDQyNDQgdGhhdCBldmVyeW9u ZSB3aWxsIGxvdmUgc28gbXVjaCB0aGV5IHdpbGwgYWN0dWFsbHkgaW1wbGVtZW50IGl0LiAN Cg0KSSBzdXNwZWN0IHRoYXQgb25lIHJlYXNvbiB3aHkgcGVvcGxlIGhhdmVuJ3QgaW1wbGVt ZW50ZWQgd2hhdCBpcyBhbHJlYWR5IGRlZmluZWQgaW4gNDI0NCBpcyB0aGF0IG1vc3QgY3Vy cmVudCBkZXBsb3ltZW50cyB0aGF0IG1ha2UgdXNlIG9mIEhpc3RvcnktSW5mbyBzZWN1cml0 eSBlaXRoZXIgaXNuJ3Qgc3VjaCBhIGNvbmNlcm4gKHdpdGhpbiBhbiBlbnRlcnByaXNlIGZv ciBleGFtcGxlKSBvciB0aGVyZSBhcmUgb3RoZXIgc2VjdXJpdHkgc29sdXRpb25zIHRoYXQg cHJldmVudCBhdHRhY2tzIChzdWNoIGFzIGluIGEgd2FsbGVkIGdhcmRlbiBjYXJyaWVyIGRl cGxveW1lbnQpLiBJJ20gbm90IGFnYWluc3QgYWRkcmVzc2luZyBzZWN1cml0eSBmb3IgbW9y ZSBnZW5lcmFsIGNhc2VzIGJ1dCBJIHRoaW5rIHRvIGJlIHVzZWZ1bCB0aGUgdGFyZ2V0LXVy aSBzb2x1dGlvbiBuZWVkcyB0byBjb21lIG91dCBpbiBzb21ldGhpbmcgbGlrZSBhIHNpbWls YXIgdGltZSBmcmFtZSB0byB0aGUgcHVibGljYXRpb24gb2YgR1JVVSBhbmQgbm90IG1hbnkg eWVhcnMgbGF0ZXIgd2FpdGluZyBmb3IgdGhvcm55IHNlY3VyaXR5IGlzc3VlcyB0byBiZSBh ZGRyZXNzZWQuDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCg0KRnJv bTogTWFyeSBCYXJuZXMgPG1hcnkuYmFybmVzQG5vcnRlbC5jb20+IA0KVG86IEFuZHJldyBB bGxlbjsgaWV0Zi5oYW5zZXJpa0BnbWFpbC5jb20gPGlldGYuaGFuc2VyaWtAZ21haWwuY29t PiANCkNjOiBzaXBjb3JlQGlldGYub3JnIDxzaXBjb3JlQGlldGYub3JnPiANClNlbnQ6IFRo dSBBcHIgMTYgMjE6Mjk6NDUgMjAwOQ0KU3ViamVjdDogUkU6IFtzaXBjb3JlXSBUYXJnZXQt dXJpIGRvY3VtZW50IGFzIFNJUENPUkUgV0cgZG9jdW1lbnQ/ICh3YXMgUkU6W1NpcF0gU0lQ Q09SRSAtLSBJZiB5b3UncmUgbm90IHN1YnNjcmliZWQsIHlvdSdyZSBtaXNzaW5nIHN0dWZm IA0KDQoNCkhpIEFuZHJldywNCiANClRoYW5rcyBmb3IgdGhlIGNsYXJpZmljYXRpb24uIE9u IHRoZSBzZWN1cml0eSBwb2ludCwgIGlmIHRoZSBXRyB3b3VsZCBhZ3JlZSB0aGF0IHRoZSBz YW1lIHNlY3VyaXR5IGNvbnNpZGVyYXRpb25zIGFzIGluIDQyNDQgYXBwbHkgdG8gdGFyZ2V0 LXVyaSAtIGkuZS4sIG5vIG1vcmUvbm8gbGVzcywgdGhlbiB5ZXMsIHRoZXJlJ3Mgbm90IGFu IGlzc3VlLiBBcyBJIHVuZGVyc3RhbmQgaXQsIHRoZSBpc3N1ZSBpcyB0aGF0IHRoZSBiYXIg aXMgcXVpdGUgaGlnaCBpbiA0MjQ0IChlLmcuLCBUTFMgbWFuZGF0ZWQpLCBzbyB0aGUgYW5z d2VyIGlzIHRoYXQgbm8gb25lIHRoYXQgaGFzIGltcGxlbWVudGVkIGl0IGxpa2VseSBtZWV0 cyB0aGF0IHNlY3VyaXR5IHJlcXVpcmVtZW50LiAgQW5kLCB5ZXMgaXQgaXMgYSBiaWcgY2Fu IG9mIHdvcm1zLCBqdXN0IGxpa2UgYW55IG90aGVyIHNlY3VyaXR5IGRpc2N1c3Npb24gaXMg Zm9yIFNJUC4gIEJ1dCwgd2hhdCBJJ20gdHJ5aW5nIHRvIHNheSBpcyB0aGF0IGlmIGZvbGtz IGRvIGJlbGlldmUgdGhlIGN1cnJlbnQgc2VjdXJpdHkgaW4gNDI0NCBpcyBub3QgYWRlcXVh dGUgb3IgaW1wbGVtZW50YWJsZSwgdGhlbiB0YXJnZXQtdXJpIHdvdWxkIGhhdmUgdGhlIHNh bWUgaXNzdWUgYW5kIHRodXMgbmVlZCB0byBhZGRyZXNzIGFueSBjb25jZXJucyB3aXRoIDQy NDQgc2VjdXJpdHkgdG8gYmUgY29tcGxldGUuIEJhc2VkIG9uIG15IGV4cGVyaWVuY2Ugd2l0 aCBtb3JlIHJlY2VudCBSRkNzLCB0aGUgYmFyIGZvciB0aGUgc2VjdXJpdHkgcmVxdWlyZW1l bnRzIGFuZCBjb25zaWRlcmF0aW9ucyBmb3IgZG9jdW1lbnRzIGlzIHNpZ25pZmljYW50bHkg aGlnaGVyIHRoYW4gaXQgd2FzIHdoZW4gNDI0NCB3YXMgcHVibGlzaGVkLiANCiANClRodXMs ICB0aGVyZSBpcyBubyBkaWZmZXJlbmNlIGF0IGFsbCBiZXR3ZWVuIHByb2dyZXNzaW5nIDQy NDRiaXMgdmVyc3VzIHRhcmdldC11cmksIGV4Y2VwdCB0aGF0IEkgdGhpbmsgaXQgaXMgYWN0 dWFsbHkgbW9yZSBkaWZmaWN1bHQgdG8gcHJvcGVybHkgZGVmaW5lIHRoZSBub3JtYXRpdmUg cHJvY2Vzc2luZyBmb3IgdGFyZ2V0LXVyaSBpbiBhIHNlcGFyYXRlIGRvY3VtZW50IHRoYW4g cmVseSBvbiB0aGUgZXhpc3Rpbmcgc3RydWN0dXJlIGFuZCB0ZXh0IGluIDQyNDQuICANCiAN Ck1hcnkuDQogDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KDQpGcm9tOiBB bmRyZXcgQWxsZW4gW21haWx0bzphYWxsZW5AcmltLmNvbV0gDQpTZW50OiBUaHVyc2RheSwg QXByaWwgMTYsIDIwMDkgNzoyNyBQTQ0KVG86IEJhcm5lcywgTWFyeSAoUklDSDI6QVIwMCk7 IGlldGYuaGFuc2VyaWtAZ21haWwuY29tDQpDYzogc2lwY29yZUBpZXRmLm9yZw0KU3ViamVj dDogUmU6IFtzaXBjb3JlXSBUYXJnZXQtdXJpIGRvY3VtZW50IGFzIFNJUENPUkUgV0cgZG9j dW1lbnQ/ICh3YXMgUkU6W1NpcF0gU0lQQ09SRSAtLSBJZiB5b3UncmUgbm90IHN1YnNjcmli ZWQsIHlvdSdyZSBtaXNzaW5nIHN0dWZmDQoNCg0KDQoNCk15IHVuZGVyc3RhbmRpbmcgb2Yg dGhlIG91dGNvbWUgaW4gU2FuIEZyYW5jaXNjbyB3YXMgdGhhdCB0YXJnZXQtdXJpIHdvdWxk IHVwZGF0ZSA0MjQ0IGFuZCA0MjQ0YmlzIHdvdWxkIGJlIHdvcmtlZCBvbiBpbiBwYXJhbGxl bCBhbmQgcG90ZW50aWFsbHkgb2Jzb2xldGUgYm90aCA0MjQ0IGFuZCB0YXJnZXQtdXJpLiAN Cg0KV2hhdGV2ZXIgaXMgZGV2ZWxvcGVkIGZvciB0YXJnZXQtdXJpIG91Z2h0IHRvIGJlIGFi bGUgdG8gYmUgaW5jb3Jwb3JhdGVkIGluIDQyNDRiaXMuIElmIDQyNDQgcHJvZ3Jlc3NlcyB3 ZWxsIHRoZW4gdGFyZ2V0LXVyaSBtYXkgbm90IG5lZWQgdWx0aW1hdGVseSB0byBiZSBwdWJs aXNoZWQgc2VwYXJhdGVseS4gDQoNCkkgYW0gYWZyYWlkIHRoYXQgdGhlIHNlY3VyaXR5IHF1 ZXN0aW9uIHRvIGJlIGFkZHJlc3NlZCBieSA0MjQ0YmlzIGlzIGEgYmlnIGNhbiBvZiB3b3Jt cyB0aGF0IGlzIGxpa2VseSB0byBiZSBhIGxvbmcgZGlzY3Vzc2lvbi4gSXMgdGhlcmUgYSBy ZWFzb24gd2h5IHRhcmdldC11cmkgY2FuJ3QgcHJvZ3Jlc3MgdW5kZXIgdGhlIGN1cnJlbnQg SGlzdG9yeS1JbmZvIHNlY3VyaXR5IGZyYW1ld29yaz8gSXMgdGhlIHNlY3VyaXR5IHNvbHV0 aW9uIGZvciA0MjQ0IGFjdHVhbGx5IHRlY2huaWNhbGx5IGJyb2tlbiBvciBpcyBpdCBqdXN0 IHRoYXQgcGVvcGxlIGRvbid0IGltcGxlbWVudCBpdD8NCg0KVGhlcmUgaXMgbm90IGEgZHJh ZnQgZGVwZW5kZWN5IG9uIHRhcmdldC11cmkgZm9yIEdSVVUgYnV0IGl0IHdhcyBjbGVhcmx5 IGlkZW50aWZpZWQgZHVyaW5nIEdSVVUgZGV2ZWxvcG1lbnQgdGhhdCBhIGxvdCBvZiB1c2Ug Y2FzZXMgZm9yIEdSVVUgcmVhbGx5IG5lZWQgdG8ga25vdyB0aGF0IHRoZSBSZXF1ZXN0IHdh cyBhZGRyZXNzZWQgdG8gYSBwYXJ0aWN1bGFyIEdSVVUgYW5kIHdpdGhvdXQgdGFyZ2V0LXVy aSB0aGF0IGZ1bmN0aW9uYWxpdHkgY2Fubm90IGJlIGFjaGlldmVkLiANCg0KDQpfX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KDQpGcm9tOiBNYXJ5IEJhcm5lcyA8bWFyeS5i YXJuZXNAbm9ydGVsLmNvbT4gDQpUbzogQW5kcmV3IEFsbGVuOyBpZXRmLmhhbnNlcmlrQGdt YWlsLmNvbSA8aWV0Zi5oYW5zZXJpa0BnbWFpbC5jb20+IA0KQ2M6IHNpcGNvcmVAaWV0Zi5v cmcgPHNpcGNvcmVAaWV0Zi5vcmc+IA0KU2VudDogVGh1IEFwciAxNiAxODowMzo0MiAyMDA5 DQpTdWJqZWN0OiBSRTogW3NpcGNvcmVdIFRhcmdldC11cmkgZG9jdW1lbnQgYXMgU0lQQ09S RSBXRyBkb2N1bWVudD8gKHdhcyBSRTpbU2lwXSBTSVBDT1JFIC0tIElmIHlvdSdyZSBub3Qg c3Vic2NyaWJlZCwgeW91J3JlIG1pc3Npbmcgc3R1ZmYgDQoNCg0KQSBmZXcgY29tbWVudHMg YmVsb3cgW01CXS4gDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQoNCkZy b206IEFuZHJldyBBbGxlbiBbbWFpbHRvOmFhbGxlbkByaW0uY29tXSANClNlbnQ6IFRodXJz ZGF5LCBBcHJpbCAxNiwgMjAwOSA0OjUwIFBNDQpUbzogQmFybmVzLCBNYXJ5IChSSUNIMjpB UjAwKTsgaWV0Zi5oYW5zZXJpa0BnbWFpbC5jb20NCkNjOiBzaXBjb3JlQGlldGYub3JnDQpT dWJqZWN0OiBSZTogW3NpcGNvcmVdIFRhcmdldC11cmkgZG9jdW1lbnQgYXMgU0lQQ09SRSBX RyBkb2N1bWVudD8gKHdhcyBSRTpbU2lwXSBTSVBDT1JFIC0tIElmIHlvdSdyZSBub3Qgc3Vi c2NyaWJlZCwgeW91J3JlIG1pc3Npbmcgc3R1ZmYNCg0KDQoNCk15IHVuZGVyc3RhbmRpbmcg d2FzIHRoYXQgd2Ugd291bGQgbW92ZSBmb3J3YXJkIHdpdGggYm90aCBkcmFmdHMgYXMgV0cg aXRlbXMuDQoNCk15IHVuZGVyc3RhbmRpbmcgd2FzIHRoYXQgaW4gRHVibGluIFRhcmdldC11 cmkgd2FzIGFkb3B0ZWQgYXMgYSBTSVAgV0cgaXRlbS4gSSBkb24ndCB3YW50IHRvIHNlZSA0 MjQ0YmlzIGJlY29tZSBhIGRlcGVuZGVuY3kgZm9yIHRoZSB0YXJnZXQtdXJpIHdvcmsgd2hp Y2ggaXMgdXJnZW50bHkgbmVlZGVkIHRvIHNvbHZlIHNvbWUgR1JVVSByZWxhdGVkIGlzc3Vl cy4gDQoNCltNQl0gUGVyIG15IG9yaWdpbmFsIGNvbW1lbnRzIGJlbG93LCB0aGUgY2hhbmdl cyBmb3IgYSB0YXJnZXQtdXJpIHNvbHV0aW9uIGJhc2VkIG9uIDQyNDQgaXMgYWN0dWFsbHkg bW9yZSB3b3JrIHRoYW4gcHV0dGluZyB0aGUgbm9ybWF0aXZlIGZ1bmN0aW9uYWxpdHkgaW4g NDI0NGJpcyAtIHRoYXQncyBiZWNhdXNlIHlvdSBzdGlsbCBuZWVkIHRvIGFkZHJlc3Mgc2Vj dXJpdHksIHByaXZhY3ksIGhvdyBpdCBpcyBwcm9jZXNzZWQgYnkgYSBVQUMsIFByb3h5IGFu ZCBVQVMuIFlvdSB3b3VsZCB0aGVuIG5lZWQgZHVwbGljYXRlIHRleHQgdG8gc2V0IHRoZSBj b250ZXh0LCBldGMuIGFuZCB0aGF0IHRleHQgd291bGQgYmUgaWRlbnRpY2FsIHRvIHdoYXQn cyBpbiA0MjQ0IE9SIHlvdSdkIGJlIGJyZWFraW5nIGV4aXN0aW5nIGltcGxlbWVudGF0aW9u cyBhbmQgdGhlcmUgYXJlIHNvbWUgb2YgdGhvc2UuIE5vdywgd2UgZGlkIGhhdmUgb25lIHJl YXNvbmFibGUgc3VnZ2VzdGlvbiBhcyB0byBhZGRpbmcgYSByZWNvbW1lbmRhdGlvbiB0aGF0 IHRoZSBQcml2YWN5IG5vdCBiZSBhcHBsaWVkIHRvIHRoZSBlbnRpcmUgbWVzc2FnZSBhcyB0 aGF0IGxpbWl0cyBwcm94eSBmdW5jdGlvbmFsaXR5IC0gdGhhdCdzIGltcG9ydGFudCBmb3Ig dGFyZ2V0LXVyaSwgYnV0IGl0J3MgYWxzbyBsaWtlbHkgYW4gb3ZlcnNpZ2h0IGluIHRoZSBv cmlnaW5hbCA0MjQ0LiBbL01CXSAgDQoNCklmIDQyNDRiaXMgaXMgcmVhZHkgd2hlbiB0YXJn ZXQtdXJpIGlzIHRoZW4gd2UgY2FuIHRhbGsgYWJvdXQgcm9sbGluZyB0aGUgdHdvIGludG8g b25lIGJ1dCBJIGhhdmUgY29uY2VybnMgdGhhdCA0MjQ0YmlzIHdpbGwgdGFrZSBjb25zaWRl cmFibHkgbG9uZ2VyIHRoYW4gdGFyZ2V0LXVyaSBiYXNlZCBvbiB0aGUgZGlzY3Vzc2lvbiBp biBTYW4gRnJhbi4gIA0KDQpbTUJdIE5vcGUgLSBhcyBJIG5vdGVkIGVhcmxpZXIsIEkgdGhp bmsgdGhlIGRpc2N1c3Npb24gd2FzIGNvbmZvdW5kZWQgYmVjYXVzZSBwZW9wbGUgd2VyZSB0 YWxraW5nIGFib3V0IGNoYW5nZXMgdG8gNDI0NGJpcyAoSGlzdG9yeS1JbmZvKSB0aGF0IHdl cmUgd2VsbCBiZXlvbmQgd2hhdCBpcyByZXF1aXJlZCBmb3IgdGFyZ2V0LXVyaSAtIGkuZS4s IHBhcmluZyBkb3duIHRoZSBmdW5jdGlvbmFsaXR5IHRvIG9ubHkgY29sbGVjdCB0aGUgZGVz aXJlZCBlbnRyaWVzLCB3aGljaCBkb2Vzbid0IHNhdmUgYSBiaXQgb2Ygd29yayBiZWNhdXNl IHlvdSBzdGlsbCBoYXZlIHRvIHJlY29nbml6ZSB0aGUgY29uZGl0aW9ucyB1bmRlciB3aGlj aCB5b3UgZHJvcCB0aGUgZW50cmllcy4gIFBsZWFzZSBsaXN0ZW4gdG8gRnJhbmNvaXMnIHJl c3BvbnNlIHRvIEhhZHJpZWwncyBzdWdnZXN0aW9uIGluIHRoZSBhdWRpbyAtIGl0J3MgdG93 YXJkcyB0aGUgZW5kLiBBbHNvLCB0aGUgc2FtZSBzZWN1cml0eSBpc3N1ZXMgYXBwbHkgLSB3 aGVuIHdlIGNvbXBsZXRlZCA0MjQ0LCB0aGUgc2VjdXJpdHkgc2VjdGlvbiB3YXMgY2FyZWZ1 bGx5IGNyYWZ0ZWQgYmFzZWQgb24gc2VjdXJpdHkgdGhvdWdodHMgYXQgdGhlIHRpbWUuIFRo b3NlIGhhdmUgY2hhbmdlZCAob2J2aW91c2x5KSBhbmQgaWYgdGhleSBhcmUgcHJvYmxlbWF0 aWMgaW4gNDI0NGJpcywgdGhleSB3b3VsZCBiZSBhIHByb2JsZW0gZm9yIHRoZSB0YXJnZXQt dXJpIHVzYWdlIG9mIDQyNDQsIHdoaWNoIGhhcyB0aGUgc2FtZSBzZWN1cml0eSByZXF1aXJl bWVudHMgYXMgY29yZSA0MjQ0LiAgWy9NQl0NCg0KVGFyZ2V0LXVyaSBoYXMgYmVlbiBuZWVk ZWQgcmVhbGx5IGZvciBHUlVVIGZvciBtb3JlIHRoZW4gMiB5ZWFycyBhbmQgaXMgZmFpcmx5 IHN0cmFpZ2h0Zm9yd2FyZC4gSSBkb24ndCB0aGluayB3ZSBzaG91bGQgcmlzayBkZWxheWlu ZyB0aGF0IHdvcmsgd2FpdGluZyBmb3IgNDI0NGJpcyB3aGljaCBzZWVtcyB0byBjb250YWlu IGEgbnVtYmVyIG9mIGlzc3VlcyB3ZSBkb24ndCBoYXZlIGNvbnNlbnN1cyBvbiB5ZXQuIA0K DQpbTUJdIFRoZSBvdGhlciBjaGFuZ2VzIHRvIDQyNDRiaXMgYXJlIG1pbm9yIGFzIGNvbXBh cmVkIHRvIHRoZSBub3JtYXRpdmUgZnVuY3Rpb25hbGl0eSB0aGF0IG5lZWRzIHRvIGJlIGFk ZGVkIHRvIHRoZSBkb2N1bWVudCB0byBzdXBwb3J0IHRhcmdldC11cmkuIFBsZWFzZSBsb29r IGF0IHRoZSBkaWZmLiAgSSBhbHNvIGRvbid0IHNlZSB0aGUgR1JVVSBkZXBlbmRlbmN5IC0g Y2FuIHlvdSBwbGVhc2UgY2xhcmlmeT8gIEkga25vdyBHUlVVIGlzIHdhaXRpbmcgZm9yIE91 dGJvdW5kIChJIHByb21pc2UgSSB3aWxsIGdpdmUgdXAgaWYgNDI0NGJpcyByZWFjaGVzIGEg cG9pbnQgd2hlcmUgaXQgaXMgdGFraW5nIGxvbmdlciB0byBmaW5pc2ggdGhhbiBPdXRib3Vu ZCkgYW5kIHRoYXQgdGhlIGdydXUtcmVnLWV2ZW50IHBrZyBpcyB3YWl0aW5nIGZvciBHUlVV LiAgWy9NQl0gDQoNClRoYXQgd2FzIG15IHVuZGVyc3RhbmRpbmcgb2YgdGhlIGFwcHJvYWNo IHdlIGRldGVybWluZWQgaW4gU2FuIEZyYW5jaXNjby4NCg0KDQpfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KDQpGcm9tOiBzaXBjb3JlLWJvdW5jZXNAaWV0Zi5vcmcgPHNp cGNvcmUtYm91bmNlc0BpZXRmLm9yZz4gDQpUbzogSGFucyBFcmlrIHZhbiBFbGJ1cmcgPGll dGYuaGFuc2VyaWtAZ21haWwuY29tPiANCkNjOiBzaXBjb3JlQGlldGYub3JnIDxzaXBjb3Jl QGlldGYub3JnPiANClNlbnQ6IFRodSBBcHIgMTYgMTc6MzQ6NTcgMjAwOQ0KU3ViamVjdDog UmU6IFtzaXBjb3JlXSBUYXJnZXQtdXJpIGRvY3VtZW50IGFzIFNJUENPUkUgV0cgZG9jdW1l bnQ/ICh3YXMgUkU6W1NpcF0gU0lQQ09SRSAtLSBJZiB5b3UncmUgbm90IHN1YnNjcmliZWQs IHlvdSdyZSBtaXNzaW5nIHN0dWZmIA0KDQoNCk5vIC0gdGhlIGRpc2N1c3Npb24gZm9yIDQy NDQoYmlzKSAoZXh0cmFjdGVkIGJlbG93KSB3YXMgZW50aXJlbHkgaW4gdGhlIGNvbnRleHQg b2YgdGhlIGRpc2N1c3Npb24gZm9yIHRoZSB0YXJnZXQtdXJpIGRvY3VtZW50LiBZb3UgY2Fu IGdvIGJhY2sgYW5kIGxpc3RlbiB0byB0aGUgYXVkaW8gdG8gdmVyaWZ5IHRoYXQuICBBbmQs IEkndmUgc3RhdGVkIGxvbmcgYmVmb3JlIElFVEYtNzMgdGhhdCBpdCB3b3VsZCBiZSBmYWly bHkgc3RyYWlnaHRmb3J3YXJkIHRvIHVwZGF0ZSA0MjQ0IHRvIGFjY29tb2RhdGUgdGhlIHRh cmdldC11cmkgcmVxdWlyZW1lbnRzIGFuZCB3aGlsZSB3ZSB3ZXJlIGRvaW5nIHRoYXQsIHRo ZXJlIHdlcmUgYSBmZXcgb3RoZXIgZml4ZXMgd2UgY291bGQgZG8uIA0KIA0KTWFyeS4gDQoN Cl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQoNCkZyb206IEhhbnMgRXJpayB2 YW4gRWxidXJnIFttYWlsdG86aWV0Zi5oYW5zZXJpa0BnbWFpbC5jb21dIA0KU2VudDogVGh1 cnNkYXksIEFwcmlsIDE2LCAyMDA5IDQ6MjIgUE0NClRvOiBCYXJuZXMsIE1hcnkgKFJJQ0gy OkFSMDApDQpDYzogRGVhbiBXaWxsaXM7IHNpcGNvcmVAaWV0Zi5vcmcNClN1YmplY3Q6IFJl OiBbc2lwY29yZV0gVGFyZ2V0LXVyaSBkb2N1bWVudCBhcyBTSVBDT1JFIFdHIGRvY3VtZW50 PyAod2FzIFJFOiBbU2lwXSBTSVBDT1JFIC0tIElmIHlvdSdyZSBub3Qgc3Vic2NyaWJlZCwg eW91J3JlIG1pc3Npbmcgc3R1ZmYNCg0KDQpIaSBNYXJ5LA0KDQpJIGJlbGlldmUgdGhhdCBp biB0aGUgYWJzZW5jZSBvZiBjb25zZW5zdXMgYXMgdGhlIG1pbnV0ZXMgY29ycmVjdGx5IHN0 YXRlLCB0aGUgdGhlIHRhcmdldC11cmkgZG9jdW1lbnQgc2hvdWxkIHJlbWFpbiB0aGUgV0cg ZG9jdW1lbnQgZm9yIHRoZSB0YXJnZXQtdXJpIGRlbGl2ZXJhYmxlLg0KDQo0NDI0YmlzIGhh cyBhbm90aGVyIHB1cnBvc2UsIG5hbWVseSB0byBmaXggdGhlIDQ0MjQuIElmIGF0IGEgY2Vy dGFpbiBtb21lbnQgaW4gdGltZSBpdCB0dXJucyBvdXQgdGhhdCA0NDI0YmlzIGlzIHRoZSBh cHByb3ByaWF0ZSBkb2N1bWVudCB0byBjb250YWluIG5vcm1hdGl2ZSB0ZXh0IGZvciB0YXJn ZXQgdXJpIGRlbGl2ZXJ5IHRoZW4gd2UgY2FuIGFsd2F5cyBkZWNpZGUgdG8gZG8gc28uIEF0 IHRoaXMgc3RhZ2UgaXQgaXMgdG8gZWFybHkgdG8gdGFrZSB0aGF0IGRlY2lzaW9uLCBnaXZl biB0aGUgY29uZnVzZWQgc3RhdGUgb2YgdGhlIHRhcmdldC11cmkgZGlzY3Vzc2lvbi4NCg0K L0hhbnMgRXJpayB2YW4gRWxidXJnDQoNCg0KDQpPbiBUaHUsIEFwciAxNiwgMjAwOSBhdCAx MDowMiBQTSwgTWFyeSBCYXJuZXMgPG1hcnkuYmFybmVzQG5vcnRlbC5jb20+IHdyb3RlOg0K DQoNCglJJ20gc3VnZ2VzdGluZyB0byBjaGFuZ2UgdGhlIGRlY2lzaW9uIGZyb20gSUVURi03 MyBhbmQgYWNjZXB0IHRoZSBtb3JlDQoJcmVjZW50IHJlYWxpemF0aW9uIHRoYXQgaW5jbHVk aW5nIG5vcm1hdGl2ZSB0ZXh0IGluIGFub3RoZXIgZG9jdW1lbnQNCglyYXRoZXIgdGhhbiA0 MjQ0YmlzIHdpbGwgYmUgZnJhdWdodCB3aXRoIGVycm9yIGFuZCBJIGNhbid0IHNlZSBob3cg dGhhdA0KCWlzIGEgZ29vZCBpZGVhIGZyb20gYSBkZXZlbG9wbWVudCBwZXJzcGVjdGl2ZSAt IHlvdSBjYW4ndCBqdXN0IGltcGxlbWVudA0KCXRoZSB0YXJnZXQtdXJpIGRvY3VtZW50Lg0K CQ0KCU5vdywgSSBkb24ndCBoYXZlIGEgcHJvYmxlbSBpZiBmb2xrcyBjYW4gYWNjZXB0IHRo YXQgdGhlIHRhcmdldC11cmkNCglkb2N1bWVudCBtaWdodCBjaGFuZ2Ugc3VjaCB0aGF0IHRo ZSBub3JtYXRpdmUgZnVuY3Rpb25hbGl0eSBpcyBpbg0KCTQyNDRiaXMuICAgQW5kLCB0aGlz IHdhcyBjb25zZW5zdXMgZnJvbSBJRVRGLTczIHBlciB0aG9zZSBtaW51dGVzOg0KCSJJc3N1 ZTogTm9ybWF0aXZlIGJlaGF2aW9yIHVwZGF0ZSBmb3IgUkZDIDQyNDQNCgkNCglDb25zZW5z dXMgbm90ZWQgdG8gcmV2aXNlIFJGQyA0MjQ0LCBhbmQgZml4IHNvbWUgb3RoZXIga25vd24g cHJvYmxlbXMNCgl3aXRoIGl0IGF0IHRlaCBzYW1lIHRpbWUuIE1BcnkgQmFybmVzIHZvbHVu dGVlcmVkIHRvIGVkaXQgdGhlDQoJZG9jdW1lbnQuIg0KCQ0KCVNvLCB0aGVyZSBpcyBhIGNv bmZsaWN0IGluIHRlcm1zIG9mIGFjY2VwdGluZyB0YXJnZXQtdXJpIGRvY3VtZW50IGFzIHRo ZQ0KCW9ubHkgZGVsaXZlcmFibGUgZm9yIHRoYXQgbWlsZXN0b25lIGluIHRoZSBJRVRGLTcz IG1lZXRpbmcuDQoJDQoJTWFyeS4NCgkNCgkNCgktLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0t LQ0KCUZyb206IERlYW4gV2lsbGlzIFttYWlsdG86ZGVhbi53aWxsaXNAc29mdGFybW9yLmNv bV0NCglTZW50OiBUaHVyc2RheSwgQXByaWwgMTYsIDIwMDkgMjozNiBQTQ0KCVRvOiBCYXJu ZXMsIE1hcnkgKFJJQ0gyOkFSMDApDQoJQ2M6IHNpcGNvcmVAaWV0Zi5vcmcNCglTdWJqZWN0 OiBSZTogW3NpcGNvcmVdIFtTaXBdIFNJUENPUkUgLS0gSWYgeW91J3JlIG5vdCBzdWJzY3Jp YmVkLCB5b3UncmUNCgltaXNzaW5nIHN0dWZmDQoJDQoJDQoJT24gQXByIDE2LCAyMDA5LCBh dCAyOjI3IFBNLCBNYXJ5IEJhcm5lcyB3cm90ZToNCgkNCgk+IEkgaGF2ZSBhbiBpc3N1ZSB3 aXRoIHRoZSB0YXJnZXQtdXJpIGRvY3VtZW50IGJlaW5nIHByb3Bvc2VkIGFzIHRoZSBXRw0K CT4gZG9jdW1lbnQgZm9yIHRoZSB0YXJnZXQtdXJpIGRlbGl2ZXJhYmxlLiBUaGlzIHdhcyBu b3QgdGhlIGNvbnNlbnN1cyBpbg0KCQ0KCT4gU0YgcGVyIG15IHJlY29sbGVjdGlvbiAod2hp Y2ggbWF5IGJlIGJpYXNlZCkgbm9yIHBlciB0aGUgU0lQIFdHDQoJPiBtaW51dGVzOg0KCT4g aHR0cDovL3d3dy5pZXRmLm9yZy9wcm9jZWVkaW5ncy8wOW1hci9taW51dGVzL3NpcC5odG1s DQoJPg0KCT4gV2hpY2ggc3RhdGU6DQoJPiAiSXNzdWU6IFByb2dyZXNzIDQyNDRiaXMsIHRh cmdldC11cmkgZHJhZnQsIG9yIGJvdGg/DQoJPiBJbiB0aGUgYWJzZW5jZSBvZiBhIGNsZWFy IGNvbnNlbnN1cywgdGhlIGNoYWlycyBwcm9wb3NlZCB0aGF0IGJvdGgNCgk+IGRvY3VtZW50 cyBwcm9jZWVkIGFuZCB3ZSdsbCBob3BlIHRoYXQgZnVydGhlciBkaXNjdXNzaW9uIGdpdmVz IHVzIGENCgk+IGNvbnNlbnN1cy4iDQoJPg0KCT4gTm93LCBJIHJlYWxpemUgdGhhdCB0aGVy ZSBhcmUgbm93IG5ldyBjaGFpcnMsIGJ1dCBJIGRvbid0IHRoaW5rIHRoYXQNCgk+IHNob3Vs ZCBjaGFuZ2UgdGhlIFdHIGNvbnNlbnN1cyBmcm9tIHRoZSBTSVAgV0cgc2Vzc2lvbi4NCgkN CglIb3dldmVyLCB0aGUgbWludXRlcyBmcm9tIElFVEYgNzMgcmVhZDoNCgkNCglUb3BpYzog VVJJIGFuZCBQYXJhbWV0ZXIgRGVsaXZlcnkNCglMZWQgYnkgSm9uYWF0aGFuIFJvc2VuYmVy Zw0KCVNsaWRlcyBwcmVzZW50ZWQNCglodHRwOi8vdG9vbHMuaWV0Zi5vcmcvaWQvZHJhZnQt cm9zZW5iZXJnLXNpcC10YXJnZXQtdXJpLWRlbGl2ZXJ5LTAwLnR4dA0KCQ0KCS4uLg0KCQ0K CVBvbGw6IFNoYWxsIFdHIGFkb3B0IHRoaXMgZHJhZnQgdG93YXJkcyBvdXIgY2hhcnRlciBk ZWxpdmVyYWJsZSBvbiB0aGUNCgl0b3BpYz8gQ2hhaXJzIHJlcG9ydGVkIGEgc3Ryb25nIGNv bnNlbnN1cyB0byBkbyBzby4NCglTbyB3aGljaCBXRyBjb25zZW5zdXMgb2Ygd2hpY2ggU0lQ IFdHIHNlc3Npb24gZG8geW91IG5vdCB3YW50IHRvIGNoYW5nZT8NCgkNCgkNCgkNCgk+DQoJ PiBJdCB3YXMgbXkgdW5kZXJzdGFuZGluZyBmcm9tIHRoZSBtaW51dGVzIHRoYXQgdGhlIGRp c2N1c3Npb24gd2FzIHRvDQoJPiBjb250aW51ZSBhcyB0byB3aGV0aGVyIHdlIHdvdWxkIG1l cmdlIHRoZSB0d28gZG9jdW1lbnRzIG9yIGFncmVlIG9uZQ0KCT4gb3IgdGhlIG90aGVyIGFz IGEgV0cgZGVsaXZlcmFibGUuDQoJPg0KCQ0KCQ0KCVRoYXQncyBhbHNvIGNvbnNpc3RlbnQg d2l0aCBteSBub3RlcyBmcm9tIFNJUCBhdCA3NC4NCgkNCglNeSBiZXN0IGd1ZXNzIGlzIHRo YXQgUkZDIDQyNDRiaXMgZ29lcyBmb3J3YXJkLCBhbmQgdGhhdCB0YXJnZXQtdXJpLQ0KCWRl bGl2ZXJ5IHR1cm5zIGludG8gYSAiSG93IHRvIHVzZSBILUkgdG8gbWVldCB0aGUgVVJJIGRl bGl2ZXJ5IHVzZQ0KCWNhc2VzIiBkb2N1bWVudC4NCgkNCgktLQ0KCURlYW4NCgkNCgkNCgkN CgkNCglfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K CXNpcGNvcmUgbWFpbGluZyBsaXN0DQoJc2lwY29yZUBpZXRmLm9yZw0KCWh0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2lwY29yZQ0KCQ0KDQoNCi0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLSANClRoaXMgdHJhbnNtaXNzaW9uIChpbmNsdWRpbmcgYW55IGF0dGFjaG1lbnRzKSBt YXkgY29udGFpbiBjb25maWRlbnRpYWwgaW5mb3JtYXRpb24sIHByaXZpbGVnZWQgbWF0ZXJp YWwgKGluY2x1ZGluZyBtYXRlcmlhbCBwcm90ZWN0ZWQgYnkgdGhlIHNvbGljaXRvci1jbGll bnQgb3Igb3RoZXIgYXBwbGljYWJsZSBwcml2aWxlZ2VzKSwgb3IgY29uc3RpdHV0ZSBub24t cHVibGljIGluZm9ybWF0aW9uLiBBbnkgdXNlIG9mIHRoaXMgaW5mb3JtYXRpb24gYnkgYW55 b25lIG90aGVyIHRoYW4gdGhlIGludGVuZGVkIHJlY2lwaWVudCBpcyBwcm9oaWJpdGVkLiBJ ZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIHRyYW5zbWlzc2lvbiBpbiBlcnJvciwgcGxlYXNl IGltbWVkaWF0ZWx5IHJlcGx5IHRvIHRoZSBzZW5kZXIgYW5kIGRlbGV0ZSB0aGlzIGluZm9y bWF0aW9uIGZyb20geW91ciBzeXN0ZW0uIFVzZSwgZGlzc2VtaW5hdGlvbiwgZGlzdHJpYnV0 aW9uLCBvciByZXByb2R1Y3Rpb24gb2YgdGhpcyB0cmFuc21pc3Npb24gYnkgdW5pbnRlbmRl ZCByZWNpcGllbnRzIGlzIG5vdCBhdXRob3JpemVkIGFuZCBtYXkgYmUgdW5sYXdmdWwuIC0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLSANClRoaXMgdHJhbnNtaXNzaW9uIChpbmNsdWRpbmcgYW55IGF0dGFj aG1lbnRzKSBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgaW5mb3JtYXRpb24sIHByaXZpbGVn ZWQgbWF0ZXJpYWwgKGluY2x1ZGluZyBtYXRlcmlhbCBwcm90ZWN0ZWQgYnkgdGhlIHNvbGlj aXRvci1jbGllbnQgb3Igb3RoZXIgYXBwbGljYWJsZSBwcml2aWxlZ2VzKSwgb3IgY29uc3Rp dHV0ZSBub24tcHVibGljIGluZm9ybWF0aW9uLiBBbnkgdXNlIG9mIHRoaXMgaW5mb3JtYXRp b24gYnkgYW55b25lIG90aGVyIHRoYW4gdGhlIGludGVuZGVkIHJlY2lwaWVudCBpcyBwcm9o aWJpdGVkLiBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIHRyYW5zbWlzc2lvbiBpbiBlcnJv ciwgcGxlYXNlIGltbWVkaWF0ZWx5IHJlcGx5IHRvIHRoZSBzZW5kZXIgYW5kIGRlbGV0ZSB0 aGlzIGluZm9ybWF0aW9uIGZyb20geW91ciBzeXN0ZW0uIFVzZSwgZGlzc2VtaW5hdGlvbiwg ZGlzdHJpYnV0aW9uLCBvciByZXByb2R1Y3Rpb24gb2YgdGhpcyB0cmFuc21pc3Npb24gYnkg dW5pbnRlbmRlZCByZWNpcGllbnRzIGlzIG5vdCBhdXRob3JpemVkIGFuZCBtYXkgYmUgdW5s YXdmdWwuIA0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NClRoaXMgdHJhbnNtaXNzaW9uIChpbmNsdWRp bmcgYW55IGF0dGFjaG1lbnRzKSBtYXkgY29udGFpbiBjb25maWRlbnRpYWwgaW5mb3JtYXRp b24sIHByaXZpbGVnZWQgbWF0ZXJpYWwgKGluY2x1ZGluZyBtYXRlcmlhbCBwcm90ZWN0ZWQg YnkgdGhlIHNvbGljaXRvci1jbGllbnQgb3Igb3RoZXIgYXBwbGljYWJsZSBwcml2aWxlZ2Vz KSwgb3IgY29uc3RpdHV0ZSBub24tcHVibGljIGluZm9ybWF0aW9uLiBBbnkgdXNlIG9mIHRo aXMgaW5mb3JtYXRpb24gYnkgYW55b25lIG90aGVyIHRoYW4gdGhlIGludGVuZGVkIHJlY2lw aWVudCBpcyBwcm9oaWJpdGVkLiBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIHRyYW5zbWlz c2lvbiBpbiBlcnJvciwgcGxlYXNlIGltbWVkaWF0ZWx5IHJlcGx5IHRvIHRoZSBzZW5kZXIg YW5kIGRlbGV0ZSB0aGlzIGluZm9ybWF0aW9uIGZyb20geW91ciBzeXN0ZW0uIFVzZSwgZGlz c2VtaW5hdGlvbiwgZGlzdHJpYnV0aW9uLCBvciByZXByb2R1Y3Rpb24gb2YgdGhpcyB0cmFu c21pc3Npb24gYnkgdW5pbnRlbmRlZCByZWNpcGllbnRzIGlzIG5vdCBhdXRob3JpemVkIGFu ZCBtYXkgYmUgdW5sYXdmdWwuDQo= ------_=_NextPart_001_01C9BF05.0C865B0E Content-Type: text/html; charset="utf-8" content-transfer-encoding: base64 PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9u YWwvL0VOIj4NCjxIVE1MPjxIRUFEPg0KDQo8TUVUQSBjb250ZW50PSJNU0hUTUwgNi4wMC4y OTAwLjM0OTIiIG5hbWU9R0VORVJBVE9SPjwvSEVBRD4NCjxCT0RZPjxwPjxmb250IHNpemU9 MiBjb2xvcj1uYXZ5IGZhY2U9QXJpYWw+DQo8YnI+QXQgbGVhc3QgaW4gbXkgbWluZCB0YXJn ZXQtdXJpIGlzIGp1c3QgYSBtaW5vciBlbmhhbmNlbWVudC9leHRlbnNpb24gdG8gSGlzdG9y eS1JbmZvIHRvIGFkZHJlc3MgdGhlIGlzc3VlIG9mIHJld3JpdGluZyB0aGUgUmVxdWVzdC1V Ukkgd2l0aCB0aGUgY29udGFjdC4gRG9lcyB0YXJnZXQtdXJpIHVzYWdlIGludHJvZHVjZSBz b21lIG5ldyBzZWN1cml0eSBjb25jZXJuIG92ZXIgYW5kIGFib3ZlIGV4aXN0aW5nIHVzZXMg b2YgSGlzdG9yeS1JbmZvIGluIFJGQyA0MjQ0PyBJZiBub3QgdGhlbiBJIGRvbid0IHRoaW5r IGl0cyBmYWlyIHRvIGRlbGF5IGEgc29sdXRpb24gdG8gdGhlIHRhcmdldC11cmkgcHJvYmxl bSBzcGFjZSB3aGlsZSB3ZSBnbyBvZmYgYW5kIGF0dGVtcHQgdG8gY29tZSB1cCB3aXRoIGEg bmV3IGltcHJvdmVkIHNlY3VyaXR5IHNvbHV0aW9uIG92ZXIgYW5kIGFib3ZlIHdoYXQgaXMg YWxyZWFkeSBpbiA0MjQ0IHRoYXQgZXZlcnlvbmUgd2lsbCBsb3ZlIHNvIG11Y2ggdGhleSB3 aWxsIGFjdHVhbGx5IGltcGxlbWVudCBpdC4gPGJyPjxicj5JIHN1c3BlY3QgdGhhdCBvbmUg cmVhc29uIHdoeSBwZW9wbGUgaGF2ZW4ndCBpbXBsZW1lbnRlZCB3aGF0IGlzIGFscmVhZHkg ZGVmaW5lZCBpbiA0MjQ0IGlzIHRoYXQgbW9zdCBjdXJyZW50IGRlcGxveW1lbnRzIHRoYXQg bWFrZSB1c2Ugb2YgSGlzdG9yeS1JbmZvIHNlY3VyaXR5IGVpdGhlciBpc24ndCBzdWNoIGEg Y29uY2VybiAod2l0aGluIGFuIGVudGVycHJpc2UgZm9yIGV4YW1wbGUpIG9yIHRoZXJlIGFy ZSBvdGhlciBzZWN1cml0eSBzb2x1dGlvbnMgdGhhdCBwcmV2ZW50IGF0dGFja3MgKHN1Y2gg YXMgaW4gYSB3YWxsZWQgZ2FyZGVuIGNhcnJpZXIgZGVwbG95bWVudCkuIEknbSBub3QgYWdh aW5zdCBhZGRyZXNzaW5nIHNlY3VyaXR5IGZvciBtb3JlIGdlbmVyYWwgY2FzZXMgYnV0IEkg dGhpbmsgdG8gYmUgdXNlZnVsIHRoZSB0YXJnZXQtdXJpIHNvbHV0aW9uIG5lZWRzIHRvIGNv bWUgb3V0IGluIHNvbWV0aGluZyBsaWtlIGEgc2ltaWxhciB0aW1lIGZyYW1lIHRvIHRoZSBw dWJsaWNhdGlvbiBvZiBHUlVVIGFuZCBub3QgbWFueSB5ZWFycyBsYXRlciB3YWl0aW5nIGZv ciB0aG9ybnkgc2VjdXJpdHkgaXNzdWVzIHRvIGJlIGFkZHJlc3NlZC48YnI+PC9mb250Pjwv cD4NCjxwPjxociBzaXplPTIgd2lkdGg9IjEwMCUiIGFsaWduPWNlbnRlciB0YWJpbmRleD0t MT4NCjxmb250IGZhY2U9VGFob21hIHNpemU9Mj4NCjxiPkZyb208L2I+OiBNYXJ5IEJhcm5l cyAmbHQ7bWFyeS5iYXJuZXNAbm9ydGVsLmNvbSZndDsNPGJyPjxiPlRvPC9iPjogQW5kcmV3 IEFsbGVuOyBpZXRmLmhhbnNlcmlrQGdtYWlsLmNvbSAmbHQ7aWV0Zi5oYW5zZXJpa0BnbWFp bC5jb20mZ3Q7DTxicj48Yj5DYzwvYj46IHNpcGNvcmVAaWV0Zi5vcmcgJmx0O3NpcGNvcmVA aWV0Zi5vcmcmZ3Q7DTxicj48Yj5TZW50PC9iPjogVGh1IEFwciAxNiAyMToyOTo0NSAyMDA5 PGJyPjxiPlN1YmplY3Q8L2I+OiBSRTogW3NpcGNvcmVdIFRhcmdldC11cmkgZG9jdW1lbnQg YXMgU0lQQ09SRSBXRyBkb2N1bWVudD8gKHdhcyBSRTpbU2lwXSBTSVBDT1JFIC0tIElmIHlv dSdyZSBub3Qgc3Vic2NyaWJlZCwgeW91J3JlIG1pc3Npbmcgc3R1ZmYNPGJyPjwvZm9udD48 L3A+DQoNCjxESVY+PEZPTlQgZmFjZT1BcmlhbCBjb2xvcj0jMDAwMGZmIHNpemU9Mj48U1BB TiBjbGFzcz0xNTY1MjIwMDEtMTcwNDIwMDk+SGkgDQpBbmRyZXcsPC9TUEFOPjwvRk9OVD48 L0RJVj4NCjxESVY+PEZPTlQgZmFjZT1BcmlhbCBjb2xvcj0jMDAwMGZmIHNpemU9Mj48U1BB TiANCmNsYXNzPTE1NjUyMjAwMS0xNzA0MjAwOT48L1NQQU4+PC9GT05UPiZuYnNwOzwvRElW Pg0KPERJVj48Rk9OVCBmYWNlPUFyaWFsIGNvbG9yPSMwMDAwZmYgc2l6ZT0yPjxTUEFOIGNs YXNzPTE1NjUyMjAwMS0xNzA0MjAwOT5UaGFua3MgDQpmb3ImbmJzcDt0aGUgY2xhcmlmaWNh dGlvbi4gT24gdGhlIHNlY3VyaXR5IHBvaW50LCZuYnNwOyZuYnNwO2lmIHRoZSBXRyB3b3Vs ZCANCmFncmVlIHRoYXQgdGhlIHNhbWUgc2VjdXJpdHkgY29uc2lkZXJhdGlvbnMgYXMgaW4g NDI0NCBhcHBseSB0byB0YXJnZXQtdXJpIC0gDQppLmUuLCBubyBtb3JlL25vIGxlc3MsIHRo ZW4geWVzLCB0aGVyZSdzIG5vdCBhbiBpc3N1ZS4gQXMgSSB1bmRlcnN0YW5kIGl0LCB0aGUg DQppc3N1ZSBpcyB0aGF0IHRoZSBiYXIgaXMgcXVpdGUgaGlnaCBpbiA0MjQ0IChlLmcuLCBU TFMgbWFuZGF0ZWQpLCBzbyB0aGUgYW5zd2VyIA0KaXMgdGhhdCBubyBvbmUgdGhhdCBoYXMg aW1wbGVtZW50ZWQgaXQgbGlrZWx5IG1lZXRzIHRoYXQgc2VjdXJpdHkgDQpyZXF1aXJlbWVu dC4mbmJzcDsmbmJzcDtBbmQsIHllcyBpdCBpcyBhIGJpZyBjYW4gb2Ygd29ybXMsIGp1c3Qg bGlrZSBhbnkgb3RoZXIgDQpzZWN1cml0eSBkaXNjdXNzaW9uIGlzIGZvciBTSVAuICZuYnNw O0J1dCwgd2hhdCBJJ20gdHJ5aW5nIHRvIHNheSBpcyB0aGF0IGlmIA0KZm9sa3MgZG8gYmVs aWV2ZSB0aGUgY3VycmVudCBzZWN1cml0eSBpbiA0MjQ0IGlzIG5vdCBhZGVxdWF0ZSBvciBp bXBsZW1lbnRhYmxlLCANCnRoZW4gdGFyZ2V0LXVyaSB3b3VsZCBoYXZlIHRoZSBzYW1lIGlz c3VlIGFuZCB0aHVzIG5lZWQgdG8gYWRkcmVzcyBhbnkgY29uY2VybnMgDQp3aXRoIDQyNDQg c2VjdXJpdHkmbmJzcDt0byBiZSBjb21wbGV0ZS4mbmJzcDtCYXNlZCBvbiBteSBleHBlcmll bmNlIHdpdGggbW9yZSANCnJlY2VudCBSRkNzLCB0aGUgYmFyIGZvciB0aGUgc2VjdXJpdHkg cmVxdWlyZW1lbnRzIGFuZCBjb25zaWRlcmF0aW9ucyBmb3IgDQpkb2N1bWVudHMgaXMgc2ln bmlmaWNhbnRseSBoaWdoZXIgdGhhbiBpdCB3YXMgd2hlbiA0MjQ0IHdhcyBwdWJsaXNoZWQu IA0KPC9TUEFOPjwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgZmFjZT1BcmlhbCBjb2xvcj0j MDAwMGZmIHNpemU9Mj48U1BBTiANCmNsYXNzPTE1NjUyMjAwMS0xNzA0MjAwOT48L1NQQU4+ PC9GT05UPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBmYWNlPUFyaWFsIGNvbG9yPSMwMDAw ZmYgc2l6ZT0yPjxTUEFOIGNsYXNzPTE1NjUyMjAwMS0xNzA0MjAwOT5UaHVzLCANCiZuYnNw O3RoZXJlIGlzIG5vIGRpZmZlcmVuY2UgYXQgYWxsIGJldHdlZW4gcHJvZ3Jlc3NpbmcgNDI0 NGJpcyB2ZXJzdXMgDQp0YXJnZXQtdXJpLCBleGNlcHQgdGhhdCBJIHRoaW5rIGl0IGlzIGFj dHVhbGx5IG1vcmUgZGlmZmljdWx0IHRvIHByb3Blcmx5IGRlZmluZSANCnRoZSBub3JtYXRp dmUgcHJvY2Vzc2luZyBmb3IgdGFyZ2V0LXVyaSBpbiBhIHNlcGFyYXRlIGRvY3VtZW50IHRo YW4gcmVseSBvbiB0aGUgDQpleGlzdGluZyBzdHJ1Y3R1cmUgYW5kIHRleHQgaW4gNDI0NC4m bmJzcDsgPC9TUEFOPjwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgZmFjZT1BcmlhbCBjb2xv cj0jMDAwMGZmIHNpemU9Mj48U1BBTiANCmNsYXNzPTE1NjUyMjAwMS0xNzA0MjAwOT48L1NQ QU4+PC9GT05UPiZuYnNwOzwvRElWPg0KPERJVj48Rk9OVCBmYWNlPUFyaWFsIGNvbG9yPSMw MDAwZmYgc2l6ZT0yPjxTUEFOIA0KY2xhc3M9MTU2NTIyMDAxLTE3MDQyMDA5Pk1hcnkuPC9T UEFOPjwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgZmFjZT1BcmlhbCBjb2xvcj0jMDAwMGZm IHNpemU9Mj48U1BBTiANCmNsYXNzPTE1NjUyMjAwMS0xNzA0MjAwOT4mbmJzcDs8L1NQQU4+ PC9GT05UPjwvRElWPg0KPERJViBjbGFzcz1PdXRsb29rTWVzc2FnZUhlYWRlciBsYW5nPWVu LXVzIGRpcj1sdHIgYWxpZ249bGVmdD4NCjxIUiB0YWJJbmRleD0tMT4NCjxGT05UIGZhY2U9 VGFob21hIHNpemU9Mj48Qj5Gcm9tOjwvQj4gQW5kcmV3IEFsbGVuIFttYWlsdG86YWFsbGVu QHJpbS5jb21dIA0KPEJSPjxCPlNlbnQ6PC9CPiBUaHVyc2RheSwgQXByaWwgMTYsIDIwMDkg NzoyNyBQTTxCUj48Qj5Ubzo8L0I+IEJhcm5lcywgTWFyeSANCihSSUNIMjpBUjAwKTsgaWV0 Zi5oYW5zZXJpa0BnbWFpbC5jb208QlI+PEI+Q2M6PC9CPiANCnNpcGNvcmVAaWV0Zi5vcmc8 QlI+PEI+U3ViamVjdDo8L0I+IFJlOiBbc2lwY29yZV0gVGFyZ2V0LXVyaSBkb2N1bWVudCBh cyBTSVBDT1JFIA0KV0cgZG9jdW1lbnQ/ICh3YXMgUkU6W1NpcF0gU0lQQ09SRSAtLSBJZiB5 b3UncmUgbm90IHN1YnNjcmliZWQsIHlvdSdyZSBtaXNzaW5nIA0Kc3R1ZmY8QlI+PC9GT05U PjxCUj48L0RJVj4NCjxESVY+PC9ESVY+DQo8UD48Rk9OVCBmYWNlPUFyaWFsIGNvbG9yPW5h dnkgc2l6ZT0yPjxCUj5NeSB1bmRlcnN0YW5kaW5nIG9mIHRoZSBvdXRjb21lIGluIFNhbiAN CkZyYW5jaXNjbyB3YXMgdGhhdCB0YXJnZXQtdXJpIHdvdWxkIHVwZGF0ZSA0MjQ0IGFuZCA0 MjQ0YmlzIHdvdWxkIGJlIHdvcmtlZCBvbiANCmluIHBhcmFsbGVsIGFuZCBwb3RlbnRpYWxs eSBvYnNvbGV0ZSBib3RoIDQyNDQgYW5kIHRhcmdldC11cmkuIDxCUj48QlI+V2hhdGV2ZXIg DQppcyBkZXZlbG9wZWQgZm9yIHRhcmdldC11cmkgb3VnaHQgdG8gYmUgYWJsZSB0byBiZSBp bmNvcnBvcmF0ZWQgaW4gNDI0NGJpcy4gSWYgDQo0MjQ0IHByb2dyZXNzZXMgd2VsbCB0aGVu IHRhcmdldC11cmkgbWF5IG5vdCBuZWVkIHVsdGltYXRlbHkgdG8gYmUgcHVibGlzaGVkIA0K c2VwYXJhdGVseS4gPEJSPjxCUj5JIGFtIGFmcmFpZCB0aGF0IHRoZSBzZWN1cml0eSBxdWVz dGlvbiB0byBiZSBhZGRyZXNzZWQgYnkgDQo0MjQ0YmlzIGlzIGEgYmlnIGNhbiBvZiB3b3Jt cyB0aGF0IGlzIGxpa2VseSB0byBiZSBhIGxvbmcgZGlzY3Vzc2lvbi4gSXMgdGhlcmUgYSAN CnJlYXNvbiB3aHkgdGFyZ2V0LXVyaSBjYW4ndCBwcm9ncmVzcyB1bmRlciB0aGUgY3VycmVu dCBIaXN0b3J5LUluZm8gc2VjdXJpdHkgDQpmcmFtZXdvcms/IElzIHRoZSBzZWN1cml0eSBz b2x1dGlvbiBmb3IgNDI0NCBhY3R1YWxseSB0ZWNobmljYWxseSBicm9rZW4gb3IgaXMgDQpp dCBqdXN0IHRoYXQgcGVvcGxlIGRvbid0IGltcGxlbWVudCBpdD88QlI+PEJSPlRoZXJlIGlz IG5vdCBhIGRyYWZ0IGRlcGVuZGVjeSBvbiANCnRhcmdldC11cmkgZm9yIEdSVVUgYnV0IGl0 IHdhcyBjbGVhcmx5IGlkZW50aWZpZWQgZHVyaW5nIEdSVVUgZGV2ZWxvcG1lbnQgdGhhdCBh IA0KbG90IG9mIHVzZSBjYXNlcyBmb3IgR1JVVSByZWFsbHkgbmVlZCB0byBrbm93IHRoYXQg dGhlIFJlcXVlc3Qgd2FzIGFkZHJlc3NlZCB0byANCmEgcGFydGljdWxhciBHUlVVIGFuZCB3 aXRob3V0IHRhcmdldC11cmkgdGhhdCBmdW5jdGlvbmFsaXR5IGNhbm5vdCBiZSBhY2hpZXZl ZC4gDQo8QlI+PC9GT05UPjwvUD4NCjxQPg0KPEhSIHRhYkluZGV4PS0xIGFsaWduPWNlbnRl ciB3aWR0aD0iMTAwJSIgU0laRT0yPg0KPEZPTlQgZmFjZT1UYWhvbWEgc2l6ZT0yPjxCPkZy b208L0I+OiBNYXJ5IEJhcm5lcyAmbHQ7bWFyeS5iYXJuZXNAbm9ydGVsLmNvbSZndDsgDQo8 QlI+PEI+VG88L0I+OiBBbmRyZXcgQWxsZW47IGlldGYuaGFuc2VyaWtAZ21haWwuY29tIA0K Jmx0O2lldGYuaGFuc2VyaWtAZ21haWwuY29tJmd0OyA8QlI+PEI+Q2M8L0I+OiBzaXBjb3Jl QGlldGYub3JnIA0KJmx0O3NpcGNvcmVAaWV0Zi5vcmcmZ3Q7IDxCUj48Qj5TZW50PC9CPjog VGh1IEFwciAxNiAxODowMzo0MiANCjIwMDk8QlI+PEI+U3ViamVjdDwvQj46IFJFOiBbc2lw Y29yZV0gVGFyZ2V0LXVyaSBkb2N1bWVudCBhcyBTSVBDT1JFIFdHIA0KZG9jdW1lbnQ/ICh3 YXMgUkU6W1NpcF0gU0lQQ09SRSAtLSBJZiB5b3UncmUgbm90IHN1YnNjcmliZWQsIHlvdSdy ZSBtaXNzaW5nIA0Kc3R1ZmYgPEJSPjwvRk9OVD4NCjxQPjwvUD4NCjxESVY+PEZPTlQgZmFj ZT1BcmlhbCBjb2xvcj0jMDAwMGZmIHNpemU9Mj48U1BBTiBjbGFzcz0yMTgzMjUzMjEtMTYw NDIwMDk+QSBmZXcgDQpjb21tZW50cyBiZWxvdyBbTUJdLiA8L1NQQU4+PC9GT05UPjwvRElW PjxCUj4NCjxESVYgY2xhc3M9T3V0bG9va01lc3NhZ2VIZWFkZXIgbGFuZz1lbi11cyBkaXI9 bHRyIGFsaWduPWxlZnQ+DQo8SFIgdGFiSW5kZXg9LTE+DQo8Rk9OVCBmYWNlPVRhaG9tYSBz aXplPTI+PEI+RnJvbTo8L0I+IEFuZHJldyBBbGxlbiBbbWFpbHRvOmFhbGxlbkByaW0uY29t XSANCjxCUj48Qj5TZW50OjwvQj4gVGh1cnNkYXksIEFwcmlsIDE2LCAyMDA5IDQ6NTAgUE08 QlI+PEI+VG86PC9CPiBCYXJuZXMsIE1hcnkgDQooUklDSDI6QVIwMCk7IGlldGYuaGFuc2Vy aWtAZ21haWwuY29tPEJSPjxCPkNjOjwvQj4gDQpzaXBjb3JlQGlldGYub3JnPEJSPjxCPlN1 YmplY3Q6PC9CPiBSZTogW3NpcGNvcmVdIFRhcmdldC11cmkgZG9jdW1lbnQgYXMgU0lQQ09S RSANCldHIGRvY3VtZW50PyAod2FzIFJFOltTaXBdIFNJUENPUkUgLS0gSWYgeW91J3JlIG5v dCBzdWJzY3JpYmVkLCB5b3UncmUgbWlzc2luZyANCnN0dWZmPEJSPjwvRk9OVD48QlI+PC9E SVY+DQo8RElWPjwvRElWPjxGT05UIGNvbG9yPW5hdnk+DQo8UD48QlI+PEZPTlQgZmFjZT1B cmlhbCBzaXplPTI+TXkgdW5kZXJzdGFuZGluZyB3YXMgdGhhdCB3ZSB3b3VsZCBtb3ZlIGZv cndhcmQgDQp3aXRoIGJvdGggZHJhZnRzIGFzIFdHIGl0ZW1zLjxCUj48QlI+TXkgdW5kZXJz dGFuZGluZyB3YXMgdGhhdCBpbiBEdWJsaW4gDQpUYXJnZXQtdXJpIHdhcyBhZG9wdGVkIGFz IGEgU0lQIFdHIGl0ZW0uIEkgZG9uJ3Qgd2FudCB0byBzZWUgNDI0NGJpcyBiZWNvbWUgYSAN CmRlcGVuZGVuY3kgZm9yIHRoZSB0YXJnZXQtdXJpIHdvcmsgd2hpY2ggaXMgdXJnZW50bHkg bmVlZGVkIHRvIHNvbHZlIHNvbWUgR1JVVSANCnJlbGF0ZWQgaXNzdWVzLjxTUEFOIGNsYXNz PTIxODMyNTMyMS0xNjA0MjAwOT48Rk9OVCANCmNvbG9yPSMwMDAwZmY+Jm5ic3A7PC9GT05U PjwvU1BBTj48L0ZPTlQ+PC9QPg0KPFA+PEZPTlQgZmFjZT1BcmlhbD48Rk9OVCBzaXplPTI+ PFNQQU4gY2xhc3M9MjE4MzI1MzIxLTE2MDQyMDA5PjxGT05UIA0KY29sb3I9IzAwMDBmZj5b TUJdIFBlciBteSBvcmlnaW5hbCBjb21tZW50cyBiZWxvdywgdGhlJm5ic3A7Y2hhbmdlcyZu YnNwO2ZvciBhIA0KdGFyZ2V0LXVyaSBzb2x1dGlvbiBiYXNlZCBvbiA0MjQ0IGlzJm5ic3A7 YWN0dWFsbHkgbW9yZSB3b3JrIA0KdGhhbiZuYnNwO3B1dHRpbmcmbmJzcDt0aGUgbm9ybWF0 aXZlIGZ1bmN0aW9uYWxpdHkgaW4gNDI0NGJpcyAtIHRoYXQncyBiZWNhdXNlIA0KeW91IHN0 aWxsIG5lZWQgdG8gYWRkcmVzcyBzZWN1cml0eSwmbmJzcDtwcml2YWN5LCBob3cgaXQgaXMg cHJvY2Vzc2VkIGJ5Jm5ic3A7YSANClVBQywgUHJveHkgYW5kIFVBUy4mbmJzcDtZb3Ugd291 bGQgdGhlbiZuYnNwO25lZWQgZHVwbGljYXRlIHRleHQgdG8gc2V0IHRoZSANCmNvbnRleHQs IGV0Yy4gYW5kIHRoYXQgdGV4dCB3b3VsZCBiZSBpZGVudGljYWwgdG8gd2hhdCdzIGluIDQy NDQgT1IgeW91J2QgYmUgDQpicmVha2luZyBleGlzdGluZyBpbXBsZW1lbnRhdGlvbnMgYW5k IHRoZXJlIGFyZSBzb21lIG9mIHRob3NlLiBOb3csIHdlIGRpZCBoYXZlIA0Kb25lIHJlYXNv bmFibGUgc3VnZ2VzdGlvbiBhcyB0byBhZGRpbmcgYSByZWNvbW1lbmRhdGlvbiB0aGF0IHRo ZSBQcml2YWN5IG5vdCBiZSANCmFwcGxpZWQgdG8gdGhlIGVudGlyZSBtZXNzYWdlIGFzIHRo YXQgbGltaXRzIHByb3h5IGZ1bmN0aW9uYWxpdHkgLSB0aGF0J3MgDQppbXBvcnRhbnQgZm9y IHRhcmdldC11cmksIGJ1dCBpdCdzIGFsc28gbGlrZWx5IGFuIG92ZXJzaWdodCBpbiB0aGUg b3JpZ2luYWwgDQo0MjQ0LiBbL01CXSZuYnNwOzwvRk9OVD4mbmJzcDs8L1NQQU4+PEJSPjxC Uj5JZiA0MjQ0YmlzIGlzIHJlYWR5IHdoZW4gdGFyZ2V0LXVyaSANCmlzIHRoZW4gd2UgY2Fu IHRhbGsgYWJvdXQgcm9sbGluZyB0aGUgdHdvIGludG8gb25lIGJ1dCBJIGhhdmUgY29uY2Vy bnMgdGhhdCANCjQyNDRiaXMgd2lsbCB0YWtlIGNvbnNpZGVyYWJseSBsb25nZXIgdGhhbiB0 YXJnZXQtdXJpIGJhc2VkIG9uIHRoZSBkaXNjdXNzaW9uIGluIA0KU2FuIEZyYW4uJm5ic3A7 PFNQQU4gY2xhc3M9MjE4MzI1MzIxLTE2MDQyMDA5PjxGT05UIA0KY29sb3I9IzAwMDBmZj4m bmJzcDs8L0ZPTlQ+PC9TUEFOPjwvRk9OVD48L0ZPTlQ+PC9QPg0KPFA+PEZPTlQgZmFjZT1B cmlhbD48Rk9OVCBzaXplPTI+PFNQQU4gY2xhc3M9MjE4MzI1MzIxLTE2MDQyMDA5PjxGT05U IA0KY29sb3I9IzAwMDBmZj5bTUJdIE5vcGUgLSBhcyBJIG5vdGVkIGVhcmxpZXIsIEkgdGhp bmsgdGhlIGRpc2N1c3Npb24gd2FzIA0KY29uZm91bmRlZCBiZWNhdXNlJm5ic3A7cGVvcGxl IHdlcmUgdGFsa2luZyBhYm91dCBjaGFuZ2VzIHRvIDQyNDRiaXMgDQooSGlzdG9yeS1JbmZv KSB0aGF0IHdlcmUgd2VsbCBiZXlvbmQgd2hhdCBpcyByZXF1aXJlZCBmb3IgdGFyZ2V0LXVy aSAtIGkuZS4sIA0KcGFyaW5nIGRvd24gdGhlIGZ1bmN0aW9uYWxpdHkgdG8gb25seSBjb2xs ZWN0IHRoZSBkZXNpcmVkIGVudHJpZXMsIHdoaWNoIGRvZXNuJ3QgDQpzYXZlIGEmbmJzcDti aXQgb2Ygd29yayBiZWNhdXNlIHlvdSBzdGlsbCBoYXZlIHRvIHJlY29nbml6ZSB0aGUgY29u ZGl0aW9ucyB1bmRlciANCndoaWNoIHlvdSBkcm9wIHRoZSBlbnRyaWVzLiZuYnNwOyBQbGVh c2UgbGlzdGVuIHRvIEZyYW5jb2lzJyByZXNwb25zZSB0byANCkhhZHJpZWwncyBzdWdnZXN0 aW9uIGluIHRoZSBhdWRpbyAtIGl0J3MgdG93YXJkcyB0aGUgZW5kLiBBbHNvLCB0aGUgc2Ft ZSANCnNlY3VyaXR5IGlzc3VlcyBhcHBseSAtIHdoZW4gd2UgY29tcGxldGVkIDQyNDQsIHRo ZSBzZWN1cml0eSBzZWN0aW9uIHdhcyANCmNhcmVmdWxseSBjcmFmdGVkIGJhc2VkIG9uIHNl Y3VyaXR5IHRob3VnaHRzIGF0IHRoZSB0aW1lLiBUaG9zZSBoYXZlIGNoYW5nZWQgDQoob2J2 aW91c2x5KSBhbmQgaWYgdGhleSBhcmUgcHJvYmxlbWF0aWMgaW4gNDI0NGJpcywgdGhleSB3 b3VsZCBiZSBhIHByb2JsZW0gZm9yIA0KdGhlIHRhcmdldC11cmkgdXNhZ2Ugb2YgNDI0NCwg d2hpY2ggaGFzIHRoZSBzYW1lIHNlY3VyaXR5IHJlcXVpcmVtZW50cyBhcyBjb3JlIA0KNDI0 NC4mbmJzcDsmbmJzcDtbL01CXTwvRk9OVD48L1NQQU4+PEJSPjxCUj5UYXJnZXQtdXJpIGhh cyBiZWVuIG5lZWRlZCByZWFsbHkgDQpmb3IgR1JVVSBmb3IgbW9yZSB0aGVuIDIgeWVhcnMg YW5kIGlzIGZhaXJseSBzdHJhaWdodGZvcndhcmQuIEkgZG9uJ3QgdGhpbmsgd2UgDQpzaG91 bGQgcmlzayBkZWxheWluZyB0aGF0IHdvcmsgd2FpdGluZyBmb3IgNDI0NGJpcyB3aGljaCBz ZWVtcyB0byBjb250YWluIGEgDQpudW1iZXIgb2YgaXNzdWVzIHdlIGRvbid0IGhhdmUgY29u c2Vuc3VzIG9uIHlldC48U1BBTiANCmNsYXNzPTIxODMyNTMyMS0xNjA0MjAwOT48Rk9OVCAN CmNvbG9yPSMwMDAwZmY+Jm5ic3A7PC9GT05UPjwvU1BBTj48L0ZPTlQ+PC9GT05UPjwvUD4N CjxQPjxGT05UIGZhY2U9QXJpYWw+PEZPTlQgY29sb3I9IzAwMDBmZiBzaXplPTI+PFNQQU4g DQpjbGFzcz0yMTgzMjUzMjEtMTYwNDIwMDk+W01CXSBUaGUmbmJzcDtvdGhlciBjaGFuZ2Vz IHRvIDQyNDRiaXMgYXJlIG1pbm9yIGFzIA0KY29tcGFyZWQgdG8gdGhlIG5vcm1hdGl2ZSBm dW5jdGlvbmFsaXR5IHRoYXQgbmVlZHMgdG8gYmUgYWRkZWQgdG8gdGhlIGRvY3VtZW50IA0K dG8gc3VwcG9ydCB0YXJnZXQtdXJpLiBQbGVhc2UgbG9vayBhdCB0aGUgZGlmZi4mbmJzcDsg SSBhbHNvIGRvbid0IHNlZSB0aGUgR1JVVSANCmRlcGVuZGVuY3kgLSBjYW4geW91IHBsZWFz ZSBjbGFyaWZ5PyZuYnNwOyBJIGtub3cmbmJzcDtHUlVVIGlzIHdhaXRpbmcmbmJzcDtmb3Ig DQpPdXRib3VuZCAoSSBwcm9taXNlIEkgd2lsbCBnaXZlIHVwIGlmIDQyNDRiaXMgcmVhY2hl cyBhIHBvaW50IHdoZXJlIGl0Jm5ic3A7aXMgDQp0YWtpbmcgbG9uZ2VyIHRvIGZpbmlzaCB0 aGFuIE91dGJvdW5kKSBhbmQgdGhhdCB0aGUmbmJzcDtncnV1LXJlZy1ldmVudCBwa2cgaXMg DQp3YWl0aW5nIGZvciBHUlVVLiZuYnNwOyZuYnNwO1svTUJdPC9TUEFOPjwvRk9OVD48L0ZP TlQ+PEZPTlQgZmFjZT1BcmlhbD48Rk9OVCANCnNpemU9Mj48U1BBTiBjbGFzcz0yMTgzMjUz MjEtMTYwNDIwMDk+Jm5ic3A7PC9TUEFOPjxCUj48QlI+VGhhdCB3YXMgbXkgDQp1bmRlcnN0 YW5kaW5nIG9mIHRoZSBhcHByb2FjaCB3ZSBkZXRlcm1pbmVkIGluIFNhbiANCkZyYW5jaXNj by48QlI+PC9QPjwvRk9OVD48L0ZPTlQ+PC9GT05UPg0KPFA+DQo8SFIgdGFiSW5kZXg9LTEg YWxpZ249Y2VudGVyIHdpZHRoPSIxMDAlIiBTSVpFPTI+DQo8Rk9OVCBmYWNlPVRhaG9tYSBz aXplPTI+PEI+RnJvbTwvQj46IHNpcGNvcmUtYm91bmNlc0BpZXRmLm9yZyANCiZsdDtzaXBj b3JlLWJvdW5jZXNAaWV0Zi5vcmcmZ3Q7IDxCUj48Qj5UbzwvQj46IEhhbnMgRXJpayB2YW4g RWxidXJnIA0KJmx0O2lldGYuaGFuc2VyaWtAZ21haWwuY29tJmd0OyA8QlI+PEI+Q2M8L0I+ OiBzaXBjb3JlQGlldGYub3JnIA0KJmx0O3NpcGNvcmVAaWV0Zi5vcmcmZ3Q7IDxCUj48Qj5T ZW50PC9CPjogVGh1IEFwciAxNiAxNzozNDo1NyANCjIwMDk8QlI+PEI+U3ViamVjdDwvQj46 IFJlOiBbc2lwY29yZV0gVGFyZ2V0LXVyaSBkb2N1bWVudCBhcyBTSVBDT1JFIFdHIA0KZG9j dW1lbnQ/ICh3YXMgUkU6W1NpcF0gU0lQQ09SRSAtLSBJZiB5b3UncmUgbm90IHN1YnNjcmli ZWQsIHlvdSdyZSBtaXNzaW5nIA0Kc3R1ZmYgPEJSPjwvRk9OVD4NCjxQPjwvUD4NCjxESVY+ PEZPTlQgZmFjZT1BcmlhbCBjb2xvcj0jMDAwMGZmIHNpemU9Mj48U1BBTiBjbGFzcz02NzEx NzMzMjEtMTYwNDIwMDk+Tm8gLSANCnRoZSBkaXNjdXNzaW9uIGZvciA0MjQ0KGJpcykgKGV4 dHJhY3RlZCBiZWxvdykgd2FzIGVudGlyZWx5IGluIHRoZSBjb250ZXh0IG9mIA0KdGhlIGRp c2N1c3Npb24gZm9yIHRoZSB0YXJnZXQtdXJpIGRvY3VtZW50LiBZb3UgY2FuIGdvIGJhY2sg YW5kIGxpc3RlbiB0byB0aGUgDQphdWRpbyB0byB2ZXJpZnkgdGhhdC4mbmJzcDsgQW5kLCBJ J3ZlIHN0YXRlZCBsb25nIGJlZm9yZSBJRVRGLTczIHRoYXQgaXQgd291bGQgDQpiZSBmYWly bHkgc3RyYWlnaHRmb3J3YXJkIHRvIHVwZGF0ZSA0MjQ0IHRvIGFjY29tb2RhdGUgdGhlIHRh cmdldC11cmkgDQpyZXF1aXJlbWVudHMgYW5kIHdoaWxlIHdlIHdlcmUgZG9pbmcgdGhhdCwg dGhlcmUgd2VyZSBhIGZldyBvdGhlciBmaXhlcyB3ZSBjb3VsZCANCmRvLiA8L1NQQU4+PC9G T05UPjwvRElWPg0KPERJVj48Rk9OVCBmYWNlPUFyaWFsIGNvbG9yPSMwMDAwZmYgc2l6ZT0y PjxTUEFOIA0KY2xhc3M9NjcxMTczMzIxLTE2MDQyMDA5PjwvU1BBTj48L0ZPTlQ+Jm5ic3A7 PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9QXJpYWwgY29sb3I9IzAwMDBmZiBzaXplPTI+PFNQ QU4gY2xhc3M9NjcxMTczMzIxLTE2MDQyMDA5Pk1hcnkuIA0KPC9TUEFOPjwvRk9OVD48L0RJ Vj48QlI+DQo8RElWIGNsYXNzPU91dGxvb2tNZXNzYWdlSGVhZGVyIGxhbmc9ZW4tdXMgZGly PWx0ciBhbGlnbj1sZWZ0Pg0KPEhSIHRhYkluZGV4PS0xPg0KPEZPTlQgZmFjZT1UYWhvbWEg c2l6ZT0yPjxCPkZyb206PC9CPiBIYW5zIEVyaWsgdmFuIEVsYnVyZyANClttYWlsdG86aWV0 Zi5oYW5zZXJpa0BnbWFpbC5jb21dIDxCUj48Qj5TZW50OjwvQj4gVGh1cnNkYXksIEFwcmls IDE2LCAyMDA5IDQ6MjIgDQpQTTxCUj48Qj5Ubzo8L0I+IEJhcm5lcywgTWFyeSAoUklDSDI6 QVIwMCk8QlI+PEI+Q2M6PC9CPiBEZWFuIFdpbGxpczsgDQpzaXBjb3JlQGlldGYub3JnPEJS PjxCPlN1YmplY3Q6PC9CPiBSZTogW3NpcGNvcmVdIFRhcmdldC11cmkgZG9jdW1lbnQgYXMg U0lQQ09SRSANCldHIGRvY3VtZW50PyAod2FzIFJFOiBbU2lwXSBTSVBDT1JFIC0tIElmIHlv dSdyZSBub3Qgc3Vic2NyaWJlZCwgeW91J3JlIG1pc3NpbmcgDQpzdHVmZjxCUj48L0ZPTlQ+ PEJSPjwvRElWPg0KPERJVj48L0RJVj5IaSBNYXJ5LDxCUj48QlI+SSBiZWxpZXZlIHRoYXQg aW4gdGhlIGFic2VuY2Ugb2YgY29uc2Vuc3VzIGFzIHRoZSANCm1pbnV0ZXMgY29ycmVjdGx5 IHN0YXRlLCB0aGUgdGhlIHRhcmdldC11cmkgZG9jdW1lbnQgc2hvdWxkIHJlbWFpbiB0aGUg V0cgDQpkb2N1bWVudCBmb3IgdGhlIHRhcmdldC11cmkgZGVsaXZlcmFibGUuPEJSPjxCUj40 NDI0YmlzIGhhcyBhbm90aGVyIHB1cnBvc2UsIA0KbmFtZWx5IHRvIGZpeCB0aGUgNDQyNC4g SWYgYXQgYSBjZXJ0YWluIG1vbWVudCBpbiB0aW1lIGl0IHR1cm5zIG91dCB0aGF0IDQ0MjRi aXMgDQppcyB0aGUgYXBwcm9wcmlhdGUgZG9jdW1lbnQgdG8gY29udGFpbiBub3JtYXRpdmUg dGV4dCBmb3IgdGFyZ2V0IHVyaSBkZWxpdmVyeSANCnRoZW4gd2UgY2FuIGFsd2F5cyBkZWNp ZGUgdG8gZG8gc28uIEF0IHRoaXMgc3RhZ2UgaXQgaXMgdG8gZWFybHkgdG8gdGFrZSB0aGF0 IA0KZGVjaXNpb24sIGdpdmVuIHRoZSBjb25mdXNlZCBzdGF0ZSBvZiB0aGUgdGFyZ2V0LXVy aSBkaXNjdXNzaW9uLjxCUj48QlIgDQpjbGVhcj1hbGw+L0hhbnMgRXJpayB2YW4gRWxidXJn PEJSPjxCUj48QlI+DQo8RElWIGNsYXNzPWdtYWlsX3F1b3RlPk9uIFRodSwgQXByIDE2LCAy MDA5IGF0IDEwOjAyIFBNLCBNYXJ5IEJhcm5lcyA8U1BBTiANCmRpcj1sdHI+Jmx0OzxBIA0K aHJlZj0ibWFpbHRvOm1hcnkuYmFybmVzQG5vcnRlbC5jb20iPm1hcnkuYmFybmVzQG5vcnRl bC5jb208L0E+Jmd0OzwvU1BBTj4gDQp3cm90ZTo8QlI+DQo8QkxPQ0tRVU9URSBjbGFzcz1n bWFpbF9xdW90ZSANCnN0eWxlPSJQQURESU5HLUxFRlQ6IDFleDsgTUFSR0lOOiAwcHQgMHB0 IDBwdCAwLjhleDsgQk9SREVSLUxFRlQ6IHJnYigyMDQsMjA0LDIwNCkgMXB4IHNvbGlkIj5J J20gDQogIHN1Z2dlc3RpbmcgdG8gY2hhbmdlIHRoZSBkZWNpc2lvbiBmcm9tIElFVEYtNzMg YW5kIGFjY2VwdCB0aGUgbW9yZTxCUj5yZWNlbnQgDQogIHJlYWxpemF0aW9uIHRoYXQgaW5j bHVkaW5nIG5vcm1hdGl2ZSB0ZXh0IGluIGFub3RoZXIgZG9jdW1lbnQ8QlI+cmF0aGVyIHRo YW4gDQogIDQyNDRiaXMgd2lsbCBiZSBmcmF1Z2h0IHdpdGggZXJyb3IgYW5kIEkgY2FuJ3Qg c2VlIGhvdyB0aGF0PEJSPmlzIGEgZ29vZCBpZGVhIA0KICBmcm9tIGEgZGV2ZWxvcG1lbnQg cGVyc3BlY3RpdmUgLSB5b3UgY2FuJ3QganVzdCBpbXBsZW1lbnQ8QlI+dGhlIHRhcmdldC11 cmkgDQogIGRvY3VtZW50LjxCUj48QlI+Tm93LCBJIGRvbid0IGhhdmUgYSBwcm9ibGVtIGlm IGZvbGtzIGNhbiBhY2NlcHQgdGhhdCB0aGUgDQogIHRhcmdldC11cmk8QlI+ZG9jdW1lbnQg bWlnaHQgY2hhbmdlIHN1Y2ggdGhhdCB0aGUgbm9ybWF0aXZlIGZ1bmN0aW9uYWxpdHkgaXMg DQogIGluPEJSPjQyNDRiaXMuICZuYnNwOyBBbmQsIHRoaXMgd2FzIGNvbnNlbnN1cyBmcm9t IElFVEYtNzMgcGVyIHRob3NlIA0KICBtaW51dGVzOjxCUj4iSXNzdWU6IE5vcm1hdGl2ZSBi ZWhhdmlvciB1cGRhdGUgZm9yIFJGQyA0MjQ0PEJSPjxCUj5Db25zZW5zdXMgDQogIG5vdGVk IHRvIHJldmlzZSBSRkMgNDI0NCwgYW5kIGZpeCBzb21lIG90aGVyIGtub3duIHByb2JsZW1z PEJSPndpdGggaXQgYXQgdGVoIA0KICBzYW1lIHRpbWUuIE1BcnkgQmFybmVzIHZvbHVudGVl cmVkIHRvIGVkaXQgdGhlPEJSPmRvY3VtZW50LiI8QlI+PEJSPlNvLCB0aGVyZSANCiAgaXMg YSBjb25mbGljdCBpbiB0ZXJtcyBvZiBhY2NlcHRpbmcgdGFyZ2V0LXVyaSBkb2N1bWVudCBh cyB0aGU8QlI+b25seSANCiAgZGVsaXZlcmFibGUgZm9yIHRoYXQgbWlsZXN0b25lIGluIHRo ZSBJRVRGLTczIA0KICBtZWV0aW5nLjxCUj48QlI+TWFyeS48QlI+PEJSPjxCUj4tLS0tLU9y aWdpbmFsIE1lc3NhZ2UtLS0tLTxCUj5Gcm9tOiBEZWFuIA0KICBXaWxsaXMgW21haWx0bzo8 QSANCiAgaHJlZj0ibWFpbHRvOmRlYW4ud2lsbGlzQHNvZnRhcm1vci5jb20iPmRlYW4ud2ls bGlzQHNvZnRhcm1vci5jb208L0E+XTxCUj5TZW50OiANCiAgVGh1cnNkYXksIEFwcmlsIDE2 LCAyMDA5IDI6MzYgUE08QlI+VG86IEJhcm5lcywgTWFyeSAoUklDSDI6QVIwMCk8QlI+Q2M6 IDxBIA0KICBocmVmPSJtYWlsdG86c2lwY29yZUBpZXRmLm9yZyI+c2lwY29yZUBpZXRmLm9y ZzwvQT48QlI+U3ViamVjdDogUmU6IFtzaXBjb3JlXSANCiAgW1NpcF0gU0lQQ09SRSAtLSBJ ZiB5b3UncmUgbm90IHN1YnNjcmliZWQsIHlvdSdyZTxCUj5taXNzaW5nIA0KICBzdHVmZjxC Uj48QlI+PEJSPk9uIEFwciAxNiwgMjAwOSwgYXQgMjoyNyBQTSwgTWFyeSBCYXJuZXMgd3Jv dGU6PEJSPjxCUj4mZ3Q7IEkgDQogIGhhdmUgYW4gaXNzdWUgd2l0aCB0aGUgdGFyZ2V0LXVy aSBkb2N1bWVudCBiZWluZyBwcm9wb3NlZCBhcyB0aGUgV0c8QlI+Jmd0OyANCiAgZG9jdW1l bnQgZm9yIHRoZSB0YXJnZXQtdXJpIGRlbGl2ZXJhYmxlLiBUaGlzIHdhcyBub3QgdGhlIGNv bnNlbnN1cyANCiAgaW48QlI+PEJSPiZndDsgU0YgcGVyIG15IHJlY29sbGVjdGlvbiAod2hp Y2ggbWF5IGJlIGJpYXNlZCkgbm9yIHBlciB0aGUgU0lQIA0KICBXRzxCUj4mZ3Q7IG1pbnV0 ZXM6PEJSPiZndDsgPEEgDQogIGhyZWY9Imh0dHA6Ly93d3cuaWV0Zi5vcmcvcHJvY2VlZGlu Z3MvMDltYXIvbWludXRlcy9zaXAuaHRtbCIgDQogIHRhcmdldD1fYmxhbms+aHR0cDovL3d3 dy5pZXRmLm9yZy9wcm9jZWVkaW5ncy8wOW1hci9taW51dGVzL3NpcC5odG1sPC9BPjxCUj4m Z3Q7PEJSPiZndDsgDQogIFdoaWNoIHN0YXRlOjxCUj4mZ3Q7ICJJc3N1ZTogUHJvZ3Jlc3Mg NDI0NGJpcywgdGFyZ2V0LXVyaSBkcmFmdCwgb3IgDQogIGJvdGg/PEJSPiZndDsgSW4gdGhl IGFic2VuY2Ugb2YgYSBjbGVhciBjb25zZW5zdXMsIHRoZSBjaGFpcnMgcHJvcG9zZWQgdGhh dCANCiAgYm90aDxCUj4mZ3Q7IGRvY3VtZW50cyBwcm9jZWVkIGFuZCB3ZSdsbCBob3BlIHRo YXQgZnVydGhlciBkaXNjdXNzaW9uIGdpdmVzIHVzIA0KICBhPEJSPiZndDsgY29uc2Vuc3Vz LiI8QlI+Jmd0OzxCUj4mZ3Q7IE5vdywgSSByZWFsaXplIHRoYXQgdGhlcmUgYXJlIG5vdyBu ZXcgDQogIGNoYWlycywgYnV0IEkgZG9uJ3QgdGhpbmsgdGhhdDxCUj4mZ3Q7IHNob3VsZCBj aGFuZ2UgdGhlIFdHIGNvbnNlbnN1cyBmcm9tIHRoZSANCiAgU0lQIFdHIHNlc3Npb24uPEJS PjxCUj5Ib3dldmVyLCB0aGUgbWludXRlcyBmcm9tIElFVEYgNzMgcmVhZDo8QlI+PEJSPlRv cGljOiANCiAgVVJJIGFuZCBQYXJhbWV0ZXIgRGVsaXZlcnk8QlI+TGVkIGJ5IEpvbmFhdGhh biBSb3NlbmJlcmc8QlI+U2xpZGVzIA0KICBwcmVzZW50ZWQ8QlI+PEEgDQogIGhyZWY9Imh0 dHA6Ly90b29scy5pZXRmLm9yZy9pZC9kcmFmdC1yb3NlbmJlcmctc2lwLXRhcmdldC11cmkt ZGVsaXZlcnktMDAudHh0IiANCiAgdGFyZ2V0PV9ibGFuaz5odHRwOi8vdG9vbHMuaWV0Zi5v cmcvaWQvZHJhZnQtcm9zZW5iZXJnLXNpcC10YXJnZXQtdXJpLWRlbGl2ZXJ5LTAwLnR4dDwv QT48QlI+PEJSPi4uLjxCUj48QlI+UG9sbDogDQogIFNoYWxsIFdHIGFkb3B0IHRoaXMgZHJh ZnQgdG93YXJkcyBvdXIgY2hhcnRlciBkZWxpdmVyYWJsZSBvbiB0aGU8QlI+dG9waWM/IA0K ICBDaGFpcnMgcmVwb3J0ZWQgYSBzdHJvbmcgY29uc2Vuc3VzIHRvIGRvIHNvLjxCUj5TbyB3 aGljaCBXRyBjb25zZW5zdXMgb2Ygd2hpY2ggDQogIFNJUCBXRyBzZXNzaW9uIGRvIHlvdSBu b3Qgd2FudCB0byBjaGFuZ2U/PEJSPjxCUj48QlI+PEJSPiZndDs8QlI+Jmd0OyBJdCB3YXMg DQogIG15IHVuZGVyc3RhbmRpbmcgZnJvbSB0aGUgbWludXRlcyB0aGF0IHRoZSBkaXNjdXNz aW9uIHdhcyB0bzxCUj4mZ3Q7IGNvbnRpbnVlIA0KICBhcyB0byB3aGV0aGVyIHdlIHdvdWxk IG1lcmdlIHRoZSB0d28gZG9jdW1lbnRzIG9yIGFncmVlIG9uZTxCUj4mZ3Q7IG9yIHRoZSAN CiAgb3RoZXIgYXMgYSBXRyBkZWxpdmVyYWJsZS48QlI+Jmd0OzxCUj48QlI+PEJSPlRoYXQn cyBhbHNvIGNvbnNpc3RlbnQgd2l0aCBteSANCiAgbm90ZXMgZnJvbSBTSVAgYXQgNzQuPEJS PjxCUj5NeSBiZXN0IGd1ZXNzIGlzIHRoYXQgUkZDIDQyNDRiaXMgZ29lcyBmb3J3YXJkLCAN CiAgYW5kIHRoYXQgdGFyZ2V0LXVyaS08QlI+ZGVsaXZlcnkgdHVybnMgaW50byBhICJIb3cg dG8gdXNlIEgtSSB0byBtZWV0IHRoZSBVUkkgDQogIGRlbGl2ZXJ5IHVzZTxCUj5jYXNlcyIg DQogIGRvY3VtZW50LjxCUj48QlI+LS08QlI+RGVhbjxCUj48QlI+PEJSPjxCUj48QlI+X19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188QlI+c2lwY29y ZSANCiAgbWFpbGluZyBsaXN0PEJSPjxBIGhyZWY9Im1haWx0bzpzaXBjb3JlQGlldGYub3Jn Ij5zaXBjb3JlQGlldGYub3JnPC9BPjxCUj48QSANCiAgaHJlZj0iaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zaXBjb3JlIiANCiAgdGFyZ2V0PV9ibGFuaz5odHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NpcGNvcmU8L0E+PEJSPjwvQkxP Q0tRVU9URT48L0RJVj48QlI+LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tIA0KPEJSPlRoaXMgdHJhbnNtaXNz aW9uIChpbmNsdWRpbmcgYW55IGF0dGFjaG1lbnRzKSBtYXkgY29udGFpbiBjb25maWRlbnRp YWwgDQppbmZvcm1hdGlvbiwgcHJpdmlsZWdlZCBtYXRlcmlhbCAoaW5jbHVkaW5nIG1hdGVy aWFsIHByb3RlY3RlZCBieSB0aGUgDQpzb2xpY2l0b3ItY2xpZW50IG9yIG90aGVyIGFwcGxp Y2FibGUgcHJpdmlsZWdlcyksIG9yIGNvbnN0aXR1dGUgbm9uLXB1YmxpYyANCmluZm9ybWF0 aW9uLiBBbnkgdXNlIG9mIHRoaXMgaW5mb3JtYXRpb24gYnkgYW55b25lIG90aGVyIHRoYW4g dGhlIGludGVuZGVkIA0KcmVjaXBpZW50IGlzIHByb2hpYml0ZWQuIElmIHlvdSBoYXZlIHJl Y2VpdmVkIHRoaXMgdHJhbnNtaXNzaW9uIGluIGVycm9yLCBwbGVhc2UgDQppbW1lZGlhdGVs eSByZXBseSB0byB0aGUgc2VuZGVyIGFuZCBkZWxldGUgdGhpcyBpbmZvcm1hdGlvbiBmcm9t IHlvdXIgc3lzdGVtLiANClVzZSwgZGlzc2VtaW5hdGlvbiwgZGlzdHJpYnV0aW9uLCBvciBy ZXByb2R1Y3Rpb24gb2YgdGhpcyB0cmFuc21pc3Npb24gYnkgDQp1bmludGVuZGVkIHJlY2lw aWVudHMgaXMgbm90IGF1dGhvcml6ZWQgYW5kIG1heSBiZSB1bmxhd2Z1bC4gDQotLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0gPEJSPlRoaXMgDQp0cmFuc21pc3Npb24gKGluY2x1ZGluZyBhbnkgYXR0YWNo bWVudHMpIG1heSBjb250YWluIGNvbmZpZGVudGlhbCBpbmZvcm1hdGlvbiwgDQpwcml2aWxl Z2VkIG1hdGVyaWFsIChpbmNsdWRpbmcgbWF0ZXJpYWwgcHJvdGVjdGVkIGJ5IHRoZSBzb2xp Y2l0b3ItY2xpZW50IG9yIA0Kb3RoZXIgYXBwbGljYWJsZSBwcml2aWxlZ2VzKSwgb3IgY29u c3RpdHV0ZSBub24tcHVibGljIGluZm9ybWF0aW9uLiBBbnkgdXNlIG9mIA0KdGhpcyBpbmZv cm1hdGlvbiBieSBhbnlvbmUgb3RoZXIgdGhhbiB0aGUgaW50ZW5kZWQgcmVjaXBpZW50IGlz IHByb2hpYml0ZWQuIElmIA0KeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyB0cmFuc21pc3Npb24g aW4gZXJyb3IsIHBsZWFzZSBpbW1lZGlhdGVseSByZXBseSB0byB0aGUgDQpzZW5kZXIgYW5k IGRlbGV0ZSB0aGlzIGluZm9ybWF0aW9uIGZyb20geW91ciBzeXN0ZW0uIFVzZSwgZGlzc2Vt aW5hdGlvbiwgDQpkaXN0cmlidXRpb24sIG9yIHJlcHJvZHVjdGlvbiBvZiB0aGlzIHRyYW5z bWlzc2lvbiBieSB1bmludGVuZGVkIHJlY2lwaWVudHMgaXMgDQpub3QgYXV0aG9yaXplZCBh bmQgbWF5IGJlIHVubGF3ZnVsLiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0gPGJyPg0KVGhpcyB0cmFuc21p c3Npb24gKGluY2x1ZGluZyBhbnkgYXR0YWNobWVudHMpIG1heSBjb250YWluIGNvbmZpZGVu dGlhbCBpbmZvcm1hdGlvbiwgcHJpdmlsZWdlZCBtYXRlcmlhbCAoaW5jbHVkaW5nIG1hdGVy aWFsIHByb3RlY3RlZCBieSB0aGUgc29saWNpdG9yLWNsaWVudCBvciBvdGhlciBhcHBsaWNh YmxlIHByaXZpbGVnZXMpLCBvciBjb25zdGl0dXRlIG5vbi1wdWJsaWMgaW5mb3JtYXRpb24u IEFueSB1c2Ugb2YgdGhpcyBpbmZvcm1hdGlvbiBieSBhbnlvbmUgb3RoZXIgdGhhbiB0aGUg aW50ZW5kZWQgcmVjaXBpZW50IGlzIHByb2hpYml0ZWQuIElmIHlvdSBoYXZlIHJlY2VpdmVk IHRoaXMgdHJhbnNtaXNzaW9uIGluIGVycm9yLCBwbGVhc2UgaW1tZWRpYXRlbHkgcmVwbHkg dG8gdGhlIHNlbmRlciBhbmQgZGVsZXRlIHRoaXMgaW5mb3JtYXRpb24gZnJvbSB5b3VyIHN5 c3RlbS4gVXNlLCBkaXNzZW1pbmF0aW9uLCBkaXN0cmlidXRpb24sIG9yIHJlcHJvZHVjdGlv biBvZiB0aGlzIHRyYW5zbWlzc2lvbiBieSB1bmludGVuZGVkIHJlY2lwaWVudHMgaXMgbm90 IGF1dGhvcml6ZWQgYW5kIG1heSBiZSB1bmxhd2Z1bC4NCjwvQk9EWT48L0hUTUw+DQo= ------_=_NextPart_001_01C9BF05.0C865B0E-- From HKaplan@acmepacket.com Thu Apr 16 20:01:06 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 551AB3A6C90 for ; Thu, 16 Apr 2009 20:01:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.543 X-Spam-Level: X-Spam-Status: No, score=-2.543 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rnVJD5GNH+wD for ; Thu, 16 Apr 2009 20:01:05 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id E44663A68F6 for ; Thu, 16 Apr 2009 20:00:40 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.1.340.0; Thu, 16 Apr 2009 23:01:53 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Thu, 16 Apr 2009 23:01:53 -0400 From: Hadriel Kaplan To: Adam Roach , SIPCORE Date: Thu, 16 Apr 2009 23:01:53 -0400 Thread-Topic: [sipcore] Call for Consensus: draft-holmberg-sip-keep Thread-Index: Acm+62pmy5HoS0p8T2qmy3tNmBNOgwAHW+iA Message-ID: References: <49E7BF9D.10706@nostrum.com> In-Reply-To: <49E7BF9D.10706@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_E6C2E8958BA59A4FB960963D475F7AC3151797F42Email_" MIME-Version: 1.0 Subject: Re: [sipcore] Call for Consensus: draft-holmberg-sip-keep X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Apr 2009 03:01:06 -0000 --_000_E6C2E8958BA59A4FB960963D475F7AC3151797F42Email_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable yes ________________________________ From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behalf = Of Adam Roach Sent: Thursday, April 16, 2009 7:31 PM To: SIPCORE Subject: [sipcore] Call for Consensus: draft-holmberg-sip-keep [as chair] There was already a request for consensus around adopting the document draf= t-holmberg-sip-keep on the SIP working group mailing list. The call was for= adopting it "as a WG document in RAI (WG tbd)". The specific call for cons= ensus can be found here: There were 15 messages in support of doing so, and no objections. I'm asking a related but slightly different question: Given that SIPCORE ha= s a charter milestone for "Mechanism for indicating support for keep-alives= ," do you think we should adopt draft-holmberg-sip-keep as the basis for co= mpleting this milestone? As before, a simple "yes" is fine; however, if you= don't think we should adopt this document, please provide rationale. /a --_000_E6C2E8958BA59A4FB960963D475F7AC3151797F42Email_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

yes

 

From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.or= g] On Behalf Of Adam Roach
Sent: Thursday, April 16, 20= 09 7:31 PM
To: SIPCORE
Subject: [sipcore] Call for Consensus: draft-holmberg-sip-keep

=  

= [as chair]

There was already a request for consensus around adopting the document draft-holmberg-sip-keep on the SIP working group mailing list. The call was= for adopting it "as a WG document in RAI (WG tbd)". The specific call for consensus can be found here:

  <http://www.ietf.org/mail-archive/web/sip/current/msg27141.html&g= t;

There were 15 messages in support of doing so, and no objections.

I'm asking a related but slightly different question: Given that SIPCORE ha= s a charter milestone for "Mechanism for indicating support for keep-alives," do you think we should adopt draft-holmberg-sip-keep as = the basis for completing this milestone? As before, a simple "yes" is fine; however, if you don't think we should adopt this document, please pro= vide rationale.

/a

--_000_E6C2E8958BA59A4FB960963D475F7AC3151797F42Email_-- From AUDET@nortel.com Thu Apr 16 21:10:15 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 589823A698D for ; Thu, 16 Apr 2009 21:10:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.34 X-Spam-Level: X-Spam-Status: No, score=-6.34 tagged_above=-999 required=5 tests=[AWL=0.258, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zoHoDr2CTlgs for ; Thu, 16 Apr 2009 21:10:14 -0700 (PDT) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id 25CD93A67F7 for ; Thu, 16 Apr 2009 21:10:13 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id n3H4Ae625029; Fri, 17 Apr 2009 04:10:40 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C9BF12.7400E8B7" Date: Thu, 16 Apr 2009 23:10:33 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF1D7FA1E8@zrc2hxm0.corp.nortel.com> In-Reply-To: <61968779B8AC4C4BAB421D4C12F008C015FEA2B3@XCH47YKF.rim.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] Target-uri document as SIPCORE WG document? (wasRE:[Sip] SIPCORE -- If you're not subscribed, you're missing stuff Thread-Index: Acm+2VlZABnKJIMzQmy6h7q6thF4/gAAZt8gAACTQZQAACG6sAAFX0/WAAHeVrAAApNCWwACsIGQ References: <61968779B8AC4C4BAB421D4C12F008C015FEA2B3@XCH47YKF.rim.net> From: "Francois Audet" To: "Andrew Allen" , "Mary Barnes" , Cc: sipcore@ietf.org Subject: Re: [sipcore] Target-uri document as SIPCORE WG document? (wasRE:[Sip] SIPCORE -- If you're not subscribed, you're missing stuff X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Apr 2009 04:10:15 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9BF12.7400E8B7 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 U29tZSBwZW9wbGUgaGF2ZSBpbXBsZW1lbnRlZCBib3RoIFJGQyA0MjQ0IEFORCBUTFMgKHdlIGhh dmUgZm9yIGV4YW1wbGUsIGluIHF1aXRlIGEgZmV3IHNlcGFyYXRlIGltcGxlbWVudGF0aW9ucyku IFRoYXQncyBub3QgYW4gaXNzdWUuDQogDQpIb3dldmVyLCBmb3IgdGhlIGxvdmUgb2YgR29kLCBJ IGRvbid0IHVuZGVyc3RhbmQgd2h5IHRoZXJlIGlzIHNvbWV0aGluZyBzbyBzcGVjaWFsIGluIHRo ZSBIaXN0b3J5LUluZm8gaGVhZGVyIHRoYXQgd2FycmFudHMgYSBoaWdoZXIgYmFyIChpLmUuLCBm b3JjaW5nIFRMUyBvbiBldmVyeSBob3ApIHRoYW4gYW55IG9mIHRoZSBvdGhlciBzaW1pbGFyIGhl YWRlcnMgaW4gU0lQIChWaWEsIEZyb20sIFRvLCBSb3V0ZSwgUmVjb3JkLVJvdXRlIGFuZCBldmVu IHRoZSBSZXF1ZXN0LVVSSSkuIFRoZSBzZWN1cml0eSBzZWN0aW9uIGNlcnRhaW5seSBkb2VzIG5v dCBleHBsYWluIHRoaXMgZ3JhdHVpdG91cyByZXF1aXJlbWVudC4gDQogDQpDb25zZXF1ZW50bHks IEkgcmVhbGx5IGRvbid0IGJlbGlldmUgdGhhdCBhbnlib2R5IHdvdWxkIGltcGxlbWVudCBUTFMg QkVDQVVTRSBpdCBzdXBwb3J0cyA0MjQ0Lg0KIA0KTWF5YmUgSSdtIG1pc3NpbmcgdGhlIHJlYXNv biwgYW5kIHNvbWVib2R5IHdpbGwgZW5saWdodGVuIHVzLiBCdXQgaXQgc2VlbXMgdW5saWtlbHkg dG8gbWUuDQogDQpBcyBkaXNjdXNzZWQgaW4gU2FuIEZyYW5jaXNjbywgaXQgd291bGQgYmUgbXVj aCBtb3JlIHByb2R1Y3RpdmUgdG8gZmlndXJlIG91dCB3aGF0IGFyZSB0aGUgcmVhbCBzZWN1cml0 eSBjb25zaWRlcmF0aW9ucyBmb3IgSGlzdG9yeS1JbmZvLg0KIA0KIA0KUFM6IERvbid0IGdldCBt ZSB3cm9uZzogSSdkIGJlIGluIGZhdm9yIG9mIG1hbmRhdGluZyBUTFMgYWxsIHRoZSB0aW1lIGZv ciBTSVAgMy4wLiBCdXQgbWFuZGF0aW5nIFRMUyBzcGVjaWZpY2FsbHkgZm9yIHRoZSBwdXJwb3Nl IG9mIHVzaW5nIEhpc3RvcnktSW5mbyBpcyBjb21wbGV0ZWx5IHVucmVhc29uYWJsZS4NCg0KDQoJ SSBzdXNwZWN0IHRoYXQgb25lIHJlYXNvbiB3aHkgcGVvcGxlIGhhdmVuJ3QgaW1wbGVtZW50ZWQg d2hhdCBpcyBhbHJlYWR5IGRlZmluZWQgaW4gNDI0NCBpcyB0aGF0IG1vc3QgY3VycmVudCBkZXBs b3ltZW50cyB0aGF0IG1ha2UgdXNlIG9mIEhpc3RvcnktSW5mbyBzZWN1cml0eSBlaXRoZXIgaXNu J3Qgc3VjaCBhIGNvbmNlcm4gKHdpdGhpbiBhbiBlbnRlcnByaXNlIGZvciBleGFtcGxlKSBvciB0 aGVyZSBhcmUgb3RoZXIgc2VjdXJpdHkgc29sdXRpb25zIHRoYXQgcHJldmVudCBhdHRhY2tzIChz dWNoIGFzIGluIGEgd2FsbGVkIGdhcmRlbiBjYXJyaWVyIGRlcGxveW1lbnQpLiBJJ20gbm90IGFn YWluc3QgYWRkcmVzc2luZyBzZWN1cml0eSBmb3IgbW9yZSBnZW5lcmFsIGNhc2VzIGJ1dCBJIHRo aW5rIHRvIGJlIHVzZWZ1bCB0aGUgdGFyZ2V0LXVyaSBzb2x1dGlvbiBuZWVkcyB0byBjb21lIG91 dCBpbiBzb21ldGhpbmcgbGlrZSBhIHNpbWlsYXIgdGltZSBmcmFtZSB0byB0aGUgcHVibGljYXRp b24gb2YgR1JVVSBhbmQgbm90IG1hbnkgeWVhcnMgbGF0ZXIgd2FpdGluZyBmb3IgdGhvcm55IHNl Y3VyaXR5IGlzc3VlcyB0byBiZSBhZGRyZXNzZWQuDQoJDQoNCg== ------_=_NextPart_001_01C9BF12.7400E8B7 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 77u/PCFET0NUWVBFIEhUTUwgUFVCTElDICItLy9XM0MvL0RURCBIVE1MIDQuMCBUcmFuc2l0aW9u YWwvL0VOIj4NCjxIVE1MPjxIRUFEPg0KPE1FVEEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29u dGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxNRVRBIGNvbnRlbnQ9Ik1TSFRNTCA2 LjAwLjI5MDAuMzQ5MiIgbmFtZT1HRU5FUkFUT1I+PC9IRUFEPg0KPEJPRFk+DQo8RElWPjxGT05U IGZhY2U9QXJpYWwgY29sb3I9IzgwMDAwMCBzaXplPTI+PFNQQU4gY2xhc3M9NTU0MzY1MTAzLTE3 MDQyMDA5PlNvbWUgDQpwZW9wbGUgaGF2ZSBpbXBsZW1lbnRlZCBib3RoIFJGQyA0MjQ0IEFORCBU TFMgKHdlIGhhdmUgZm9yIGV4YW1wbGUsIGluIHF1aXRlIGEgDQpmZXcgc2VwYXJhdGUgaW1wbGVt ZW50YXRpb25zKS4gVGhhdCdzIG5vdCBhbiBpc3N1ZS48L1NQQU4+PC9GT05UPjwvRElWPg0KPERJ Vj48Rk9OVCBmYWNlPUFyaWFsIGNvbG9yPSM4MDAwMDAgc2l6ZT0yPjxTUEFOIA0KY2xhc3M9NTU0 MzY1MTAzLTE3MDQyMDA5PjwvU1BBTj48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIGZh Y2U9QXJpYWwgY29sb3I9IzgwMDAwMCBzaXplPTI+PFNQQU4gDQpjbGFzcz01NTQzNjUxMDMtMTcw NDIwMDk+SG93ZXZlciwgZm9yIHRoZSBsb3ZlIG9mIEdvZCwgSSBkb24ndCB1bmRlcnN0YW5kIHdo eSANCnRoZXJlIGlzIHNvbWV0aGluZyBzbyBzcGVjaWFsIGluIHRoZSBIaXN0b3J5LUluZm8gaGVh ZGVyIHRoYXQgd2FycmFudHMgYSBoaWdoZXIgDQpiYXIgKGkuZS4sIGZvcmNpbmcgVExTIG9uIGV2 ZXJ5IGhvcCkgdGhhbiBhbnkgb2YgdGhlIG90aGVyIHNpbWlsYXIgaGVhZGVycyBpbiANClNJUCAo VmlhLCBGcm9tLCBUbywgUm91dGUsIFJlY29yZC1Sb3V0ZSBhbmQgZXZlbiB0aGUgUmVxdWVzdC1V UkkpLiBUaGUgc2VjdXJpdHkgDQpzZWN0aW9uIGNlcnRhaW5seSBkb2VzIG5vdCBleHBsYWluIHRo aXMgZ3JhdHVpdG91cyByZXF1aXJlbWVudC4gDQo8L1NQQU4+PC9GT05UPjwvRElWPg0KPERJVj48 Rk9OVCBmYWNlPUFyaWFsIGNvbG9yPSM4MDAwMDAgc2l6ZT0yPjxTUEFOIA0KY2xhc3M9NTU0MzY1 MTAzLTE3MDQyMDA5PjwvU1BBTj48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9 QXJpYWwgY29sb3I9IzgwMDAwMCBzaXplPTI+PFNQQU4gDQpjbGFzcz01NTQzNjUxMDMtMTcwNDIw MDk+Q29uc2VxdWVudGx5LCBJIHJlYWxseSBkb24ndCBiZWxpZXZlIHRoYXQgYW55Ym9keSB3b3Vs ZCANCmltcGxlbWVudCBUTFMgQkVDQVVTRSBpdCBzdXBwb3J0cyA0MjQ0LjwvU1BBTj48L0ZPTlQ+ PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9QXJpYWwgY29sb3I9IzgwMDAwMCBzaXplPTI+PFNQQU4g DQpjbGFzcz01NTQzNjUxMDMtMTcwNDIwMDk+PC9TUEFOPjwvRk9OVD4mbmJzcDs8L0RJVj4NCjxE SVY+PEZPTlQgZmFjZT1BcmlhbCBjb2xvcj0jODAwMDAwIHNpemU9Mj48U1BBTiBjbGFzcz01NTQz NjUxMDMtMTcwNDIwMDk+TWF5YmUgDQpJJ20gbWlzc2luZyB0aGUgcmVhc29uLCBhbmQgc29tZWJv ZHkgd2lsbCBlbmxpZ2h0ZW4gdXMuIEJ1dCBpdCBzZWVtcyB1bmxpa2VseSB0byANCm1lLjwvU1BB Tj48L0ZPTlQ+PC9ESVY+DQo8RElWPjxGT05UIGZhY2U9QXJpYWwgY29sb3I9IzgwMDAwMCBzaXpl PTI+PFNQQU4gDQpjbGFzcz01NTQzNjUxMDMtMTcwNDIwMDk+PC9TUEFOPjwvRk9OVD4mbmJzcDs8 L0RJVj4NCjxESVY+PEZPTlQgZmFjZT1BcmlhbCBjb2xvcj0jODAwMDAwIHNpemU9Mj48U1BBTiBj bGFzcz01NTQzNjUxMDMtMTcwNDIwMDk+QXMgDQpkaXNjdXNzZWQgaW4gU2FuIEZyYW5jaXNjbywg aXQgd291bGQgYmUgbXVjaCBtb3JlIHByb2R1Y3RpdmUgdG8gZmlndXJlIG91dCB3aGF0IA0KYXJl IHRoZSByZWFsIHNlY3VyaXR5IGNvbnNpZGVyYXRpb25zIGZvciBIaXN0b3J5LUluZm8uPC9TUEFO PjwvRk9OVD48L0RJVj4NCjxESVY+PEZPTlQgZmFjZT1BcmlhbCBjb2xvcj0jODAwMDAwIHNpemU9 Mj48U1BBTiANCmNsYXNzPTU1NDM2NTEwMy0xNzA0MjAwOT48L1NQQU4+PC9GT05UPiZuYnNwOzwv RElWPg0KPERJVj48Rk9OVCBmYWNlPUFyaWFsIGNvbG9yPSM4MDAwMDAgc2l6ZT0yPjxTUEFOIA0K Y2xhc3M9NTU0MzY1MTAzLTE3MDQyMDA5PjwvU1BBTj48L0ZPTlQ+Jm5ic3A7PC9ESVY+DQo8RElW PjxGT05UIGZhY2U9QXJpYWwgY29sb3I9IzgwMDAwMCBzaXplPTI+PFNQQU4gY2xhc3M9NTU0MzY1 MTAzLTE3MDQyMDA5PlBTOiANCkRvbid0IGdldCBtZSB3cm9uZzogSSdkIGJlIGluIGZhdm9yIG9m IG1hbmRhdGluZyBUTFMgYWxsIHRoZSB0aW1lIGZvciBTSVAgMy4wLiANCkJ1dCBtYW5kYXRpbmcg VExTIHNwZWNpZmljYWxseSBmb3IgdGhlIHB1cnBvc2Ugb2YgdXNpbmcgSGlzdG9yeS1JbmZvIGlz IA0KY29tcGxldGVseSB1bnJlYXNvbmFibGUuPC9TUEFOPjwvRk9OVD48L0RJVj48QlI+DQo8QkxP Q0tRVU9URSANCnN0eWxlPSJQQURESU5HLUxFRlQ6IDVweDsgTUFSR0lOLUxFRlQ6IDVweDsgQk9S REVSLUxFRlQ6ICM4MDAwMDAgMnB4IHNvbGlkOyBNQVJHSU4tUklHSFQ6IDBweCI+DQogIDxESVYg Y2xhc3M9T3V0bG9va01lc3NhZ2VIZWFkZXIgbGFuZz1lbi11cyBkaXI9bHRyIGFsaWduPWxlZnQ+ PEZPTlQgZmFjZT1BcmlhbCANCiAgY29sb3I9bmF2eSBzaXplPTI+SSBzdXNwZWN0IHRoYXQgb25l IHJlYXNvbiB3aHkgcGVvcGxlIGhhdmVuJ3QgaW1wbGVtZW50ZWQgDQogIHdoYXQgaXMgYWxyZWFk eSBkZWZpbmVkIGluIDQyNDQgaXMgdGhhdCBtb3N0IGN1cnJlbnQgZGVwbG95bWVudHMgdGhhdCBt YWtlIHVzZSANCiAgb2YgSGlzdG9yeS1JbmZvIHNlY3VyaXR5IGVpdGhlciBpc24ndCBzdWNoIGEg Y29uY2VybiAod2l0aGluIGFuIGVudGVycHJpc2UgZm9yIA0KICBleGFtcGxlKSBvciB0aGVyZSBh cmUgb3RoZXIgc2VjdXJpdHkgc29sdXRpb25zIHRoYXQgcHJldmVudCBhdHRhY2tzIChzdWNoIGFz IA0KICBpbiBhIHdhbGxlZCBnYXJkZW4gY2FycmllciBkZXBsb3ltZW50KS4gSSdtIG5vdCBhZ2Fp bnN0IGFkZHJlc3Npbmcgc2VjdXJpdHkgDQogIGZvciBtb3JlIGdlbmVyYWwgY2FzZXMgYnV0IEkg dGhpbmsgdG8gYmUgdXNlZnVsIHRoZSB0YXJnZXQtdXJpIHNvbHV0aW9uIG5lZWRzIA0KICB0byBj b21lIG91dCBpbiBzb21ldGhpbmcgbGlrZSBhIHNpbWlsYXIgdGltZSBmcmFtZSB0byB0aGUgcHVi bGljYXRpb24gb2YgR1JVVSANCiAgYW5kIG5vdCBtYW55IHllYXJzIGxhdGVyIHdhaXRpbmcgZm9y IHRob3JueSBzZWN1cml0eSBpc3N1ZXMgdG8gYmUgDQogIGFkZHJlc3NlZC48QlI+PC9GT05UPjwv RElWPjwvQkxPQ0tRVU9URT48L0JPRFk+PC9IVE1MPg0K ------_=_NextPart_001_01C9BF12.7400E8B7-- From christian.1.schmidt@nsn.com Thu Apr 16 23:26:07 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EDA8E3A67F8 for ; Thu, 16 Apr 2009 23:26:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.265 X-Spam-Level: X-Spam-Status: No, score=-4.265 tagged_above=-999 required=5 tests=[AWL=-1.667, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pRiOJ-3i2nDr for ; Thu, 16 Apr 2009 23:26:07 -0700 (PDT) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [217.115.75.234]) by core3.amsl.com (Postfix) with ESMTP id 41FA03A6D4E for ; Thu, 16 Apr 2009 23:25:46 -0700 (PDT) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id n3H6QwAO028312 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 17 Apr 2009 08:26:58 +0200 Received: from demuexc024.nsn-intra.net (demuexc024.nsn-intra.net [10.159.32.11]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id n3H6QuOd011225; Fri, 17 Apr 2009 08:26:57 +0200 Received: from DEMUEXC013.nsn-intra.net ([10.150.128.24]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Fri, 17 Apr 2009 08:26:57 +0200 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C9BF25.81C97324" X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Fri, 17 Apr 2009 08:26:56 +0200 Message-ID: In-Reply-To: <49E7BF9D.10706@nostrum.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] Call for Consensus: draft-holmberg-sip-keep Thread-Index: Acm+616TpvXWtFBBQIe+as7Y7apT8gAOhM1w References: <49E7BF9D.10706@nostrum.com> From: "Schmidt, Christian 1. (NSN - DE/Munich)" To: "ext Adam Roach" , "SIPCORE" X-OriginalArrivalTime: 17 Apr 2009 06:26:57.0253 (UTC) FILETIME=[82006950:01C9BF25] Subject: Re: [sipcore] Call for Consensus: draft-holmberg-sip-keep X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Apr 2009 06:26:08 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9BF25.81C97324 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable yes =20 /christian ________________________________ From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behalf Of ext Adam Roach Sent: Friday, April 17, 2009 1:31 AM To: SIPCORE Subject: [sipcore] Call for Consensus: draft-holmberg-sip-keep [as chair] There was already a request for consensus around adopting the document draft-holmberg-sip-keep on the SIP working group mailing list. The call was for adopting it "as a WG document in RAI (WG tbd)". The specific call for consensus can be found here: =20 There were 15 messages in support of doing so, and no objections. I'm asking a related but slightly different question: Given that SIPCORE has a charter milestone for "Mechanism for indicating support for keep-alives," do you think we should adopt draft-holmberg-sip-keep as the basis for completing this milestone? As before, a simple "yes" is fine; however, if you don't think we should adopt this document, please provide rationale. /a ------_=_NextPart_001_01C9BF25.81C97324 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
yes
 
/christian

From: sipcore-bounces@ietf.org=20 [mailto:sipcore-bounces@ietf.org] On Behalf Of ext Adam=20 Roach
Sent: Friday, April 17, 2009 1:31 AM
To:=20 SIPCORE
Subject: [sipcore] Call for Consensus:=20 draft-holmberg-sip-keep

[as chair]

There was already a request for consensus = around=20 adopting the document draft-holmberg-sip-keep on the SIP working group = mailing=20 list. The call was for adopting it "as a WG document in = RAI (WG=20 tbd)". The specific call for consensus can be found = here:

 =20 &= lt;http://www.ietf.org/mail-archive/web/sip/current/msg27141.html>=

There=20 were 15 messages in support of doing so, and no objections.

I'm = asking a=20 related but slightly different question: Given that SIPCORE has a = charter=20 milestone for "Mechanism for indicating support for keep-alives," do you = think=20 we should adopt draft-holmberg-sip-keep as the basis for completing this = milestone? As before, a simple "yes" is fine; however, if you don't = think we=20 should adopt this document, please provide=20 rationale.

/a
------_=_NextPart_001_01C9BF25.81C97324-- From salvatore.loreto@ericsson.com Thu Apr 16 23:38:31 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 955723A69F6 for ; Thu, 16 Apr 2009 23:38:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.391 X-Spam-Level: X-Spam-Status: No, score=-6.391 tagged_above=-999 required=5 tests=[AWL=-0.142, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1nG1UqISE9aT for ; Thu, 16 Apr 2009 23:38:30 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 5BF693A67F3 for ; Thu, 16 Apr 2009 23:38:30 -0700 (PDT) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id AD46D220A1; Fri, 17 Apr 2009 08:39:42 +0200 (CEST) X-AuditID: c1b4fb3e-ae824bb0000024d5-1e-49e82212dcbd Received: from esealmw127.eemea.ericsson.se (unknown [153.88.253.124]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 73B10220F5; Fri, 17 Apr 2009 08:30:42 +0200 (CEST) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 17 Apr 2009 08:29:26 +0200 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 17 Apr 2009 08:29:26 +0200 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 186D0245E; Fri, 17 Apr 2009 09:29:26 +0300 (EEST) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id D779E219F0; Fri, 17 Apr 2009 09:29:25 +0300 (EEST) Received: from localhost.localdomain (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 42F9021961; Fri, 17 Apr 2009 09:29:25 +0300 (EEST) Message-ID: <49E821C4.8010906@ericsson.com> Date: Fri, 17 Apr 2009 09:29:24 +0300 From: Salvatore Loreto User-Agent: Thunderbird 2.0.0.21 (X11/20090320) MIME-Version: 1.0 To: SIPCORE References: <49E7BF9D.10706@nostrum.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-OriginalArrivalTime: 17 Apr 2009 06:29:26.0570 (UTC) FILETIME=[DB0060A0:01C9BF25] X-Brightmail-Tracker: AAAAAA== Subject: Re: [sipcore] Call for Consensus: draft-holmberg-sip-keep X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Apr 2009 06:38:31 -0000 yes /Sal > > ------------------------------------------------------------------------ > *From:* sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] *On > Behalf Of *ext Adam Roach > *Sent:* Friday, April 17, 2009 1:31 AM > *To:* SIPCORE > *Subject:* [sipcore] Call for Consensus: draft-holmberg-sip-keep > > [as chair] > > There was already a request for consensus around adopting the document > draft-holmberg-sip-keep on the SIP working group mailing list. The > call was for adopting it "as a WG document in RAI (WG tbd)". The > specific call for consensus can be found here: > > > > There were 15 messages in support of doing so, and no objections. > > I'm asking a related but slightly different question: Given that > SIPCORE has a charter milestone for "Mechanism for indicating support > for keep-alives," do you think we should adopt draft-holmberg-sip-keep > as the basis for completing this milestone? As before, a simple "yes" > is fine; however, if you don't think we should adopt this document, > please provide rationale. > > /a > ------------------------------------------------------------------------ > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From christer.holmberg@ericsson.com Fri Apr 17 00:42:44 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1D5243A69A1 for ; Fri, 17 Apr 2009 00:42:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.799 X-Spam-Level: X-Spam-Status: No, score=-5.799 tagged_above=-999 required=5 tests=[AWL=0.450, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iH+rbkNdpUFS for ; Fri, 17 Apr 2009 00:42:43 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 0F6173A68DB for ; Fri, 17 Apr 2009 00:42:43 -0700 (PDT) Received: from mailgw3.ericsson.se (unknown [127.0.0.1]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id 1A7A220DC5; Fri, 17 Apr 2009 09:43:55 +0200 (CEST) X-AuditID: c1b4fb3c-aa7cabb00000238f-6e-49e8333a6fc5 Received: from esealmw126.eemea.ericsson.se (unknown [153.88.253.124]) by mailgw3.ericsson.se (Symantec Mail Security) with ESMTP id DC61320DB9; Fri, 17 Apr 2009 09:43:54 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 17 Apr 2009 09:43:52 +0200 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: Fri, 17 Apr 2009 09:43:50 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] Call for Consensus: Additional Working Group Items Thread-Index: Acm+54tTkR4F6GF9RJCC6DYNcGJuKAASGgcA References: <49E777BD.9000202@estacado.net> <49E7785A.9060808@nostrum.com><49E7B38D.8000603@nostrum.com> From: "Christer Holmberg" To: "Eric Burger" , "Adam Roach" , "Hadriel Kaplan" X-OriginalArrivalTime: 17 Apr 2009 07:43:52.0147 (UTC) FILETIME=[40B15A30:01C9BF30] X-Brightmail-Tracker: AAAAAA== Cc: SIPCORE Subject: Re: [sipcore] Call for Consensus: Additional Working Group Items X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Apr 2009 07:42:44 -0000 Hi, I vote for adopting both documents. Eventhough they are not "core", I think the SIPCORE charter does say that "current documents/work" may also be handled by SIPCORE, in order to allow a smooth transition. Or am I wrong? Regards, Christer =20 > -----Original Message----- > From: sipcore-bounces@ietf.org=20 > [mailto:sipcore-bounces@ietf.org] On Behalf Of Eric Burger > Sent: 17. huhtikuuta 2009 2:03 > To: Adam Roach; Hadriel Kaplan > Cc: SIPCORE > Subject: Re: [sipcore] Call for Consensus: Additional Working=20 > Group Items >=20 > And Hadriel is saying they are not Core. >=20 > On Apr 17, 2009, at 6:39 AM, Adam Roach wrote: >=20 > > [as chair] > > > > Hadriel Kaplan wrote: > >> > >>> At 01:26 PM 4/16/2009, Adam Roach wrote: > >>> Delivering request-URI and parameters to UAS via proxy (PS) > >>> draft-rosenberg-sip-target-uri-delivery > >>> [adopted by SIP WG consensus after IETF 73, still=20 > waiting for new=20 > >>> version] > >>> > >>> SIP Events throttling mechanism (PS) > >>> draft-niemi-sipping-event-throttle > >>> [SIPPING WG indicated desire to adopt in as SIP WG=20 > item at IETF=20 > >>> 74] > >>> > >> My vote is to adopt neither in this WG. Neither of them=20 > update nor=20 > >> replace 3261-3265. > > > > To be clear, the question we are asking is not "are these=20 > milestones=20 > > okay" (that discussion has already concluded on the RAI=20 > list) -- it is=20 > > "should we take on these specific documents to satisfy the=20 > these two=20 > > milestones that are already part of the SIPCORE charter." > > > > /a > > _______________________________________________ > > sipcore mailing list > > sipcore@ietf.org > > https://www.ietf.org/mailman/listinfo/sipcore >=20 >=20 From marianne.mohali@orange-ftgroup.com Fri Apr 17 03:07:54 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F059C3A6AED for ; Fri, 17 Apr 2009 03:07:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1x-eJnZtzn1h for ; Fri, 17 Apr 2009 03:07:54 -0700 (PDT) Received: from R-MAIL2.rd.francetelecom.com (r-mail2.rd.francetelecom.com [217.108.152.42]) by core3.amsl.com (Postfix) with ESMTP id D25BF3A69F9 for ; Fri, 17 Apr 2009 03:07:53 -0700 (PDT) Received: from FTRDMEL2.rd.francetelecom.fr ([10.192.128.41]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Fri, 17 Apr 2009 12:09:06 +0200 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: Fri, 17 Apr 2009 12:09:05 +0200 Message-ID: <7DBAFEC6A76F3E42817DF1EBE64CB026065E7F6D@ftrdmel2> In-Reply-To: <49E821C4.8010906@ericsson.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] Call for Consensus: draft-holmberg-sip-keep Thread-Index: Acm/J03htzEw6ohtSQaE6Wfp6fJwswAHRT2A References: <49E7BF9D.10706@nostrum.com> <49E821C4.8010906@ericsson.com> From: To: X-OriginalArrivalTime: 17 Apr 2009 10:09:06.0081 (UTC) FILETIME=[8A9A2910:01C9BF44] Subject: Re: [sipcore] Call for Consensus: draft-holmberg-sip-keep X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Apr 2009 10:07:55 -0000 yes > > ---------------------------------------------------------------------- > -- > *From:* sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] *On > Behalf Of *ext Adam Roach > *Sent:* Friday, April 17, 2009 1:31 AM > *To:* SIPCORE > *Subject:* [sipcore] Call for Consensus: draft-holmberg-sip-keep > > [as chair] > > There was already a request for consensus around adopting the document > draft-holmberg-sip-keep on the SIP working group mailing list. The=20 > call was for adopting it "as a WG document in RAI (WG tbd)". The=20 > specific call for consensus can be found here: > > > > There were 15 messages in support of doing so, and no objections. > > I'm asking a related but slightly different question: Given that=20 > SIPCORE has a charter milestone for "Mechanism for indicating support=20 > for keep-alives," do you think we should adopt draft-holmberg-sip-keep > as the basis for completing this milestone? As before, a simple "yes" > is fine; however, if you don't think we should adopt this document,=20 > please provide rationale. > > /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 From mary.barnes@nortel.com Fri Apr 17 06:26:51 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A03B03A677C for ; Fri, 17 Apr 2009 06:26:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.466 X-Spam-Level: X-Spam-Status: No, score=-6.466 tagged_above=-999 required=5 tests=[AWL=0.132, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KvfSwXYiZACh for ; Fri, 17 Apr 2009 06:26:49 -0700 (PDT) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id 9699D3A67E6 for ; Fri, 17 Apr 2009 06:26:48 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id n3HDREe25140; Fri, 17 Apr 2009 13:27:14 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C9BF60.4E3B3C6F" Date: Fri, 17 Apr 2009 08:30:40 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF1D7FA3B3@zrc2hxm0.corp.nortel.com> In-Reply-To: <61968779B8AC4C4BAB421D4C12F008C015FEA2B3@XCH47YKF.rim.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] Target-uri document as SIPCORE WG document? (was RE:[Sip] SIPCORE -- If you're not subscribed, you're missing stuff Thread-Index: Acm+2VlZABnKJIMzQmy6h7q6thF4/gAAZt8gAACTQZQAACG6sAAFX0/WAAHeVrAAApNCWwAWrC/g References: <61968779B8AC4C4BAB421D4C12F008C015FEA2B3@XCH47YKF.rim.net> From: "Mary Barnes" To: "Andrew Allen" , Cc: sipcore@ietf.org Subject: Re: [sipcore] Target-uri document as SIPCORE WG document? (was RE:[Sip] SIPCORE -- If you're not subscribed, you're missing stuff X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Apr 2009 13:26:51 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9BF60.4E3B3C6F Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The point I was trying to make is that if the current security in 4244 is adequate for target-uri, then it is just as easy to put the normative text in 4244bis and be done with it (and not change current security - I think the scoping is already in there for the type of networks you mention in section 5). However, IF folks believe there is a problem with 4244 security, then that's a problem for target-uri, as well, since it is relying on that security - i.e., transitively it's a problem. Now, the WG might decide to wiggle their way out of that, but again my experience is that wiggle room in security considerations for protocols is non-existent. =20 =20 Mary.=20 ________________________________ From: Andrew Allen [mailto:aallen@rim.com]=20 Sent: Thursday, April 16, 2009 9:35 PM To: Barnes, Mary (RICH2:AR00); ietf.hanserik@gmail.com Cc: sipcore@ietf.org Subject: Re: [sipcore] Target-uri document as SIPCORE WG document? (was RE:[Sip] SIPCORE -- If you're not subscribed, you're missing stuff At least in my mind target-uri is just a minor enhancement/extension to History-Info to address the issue of rewriting the Request-URI with the contact. Does target-uri usage introduce some new security concern over and above existing uses of History-Info in RFC 4244? If not then I don't think its fair to delay a solution to the target-uri problem space while we go off and attempt to come up with a new improved security solution over and above what is already in 4244 that everyone will love so much they will actually implement it.=20 I suspect that one reason why people haven't implemented what is already defined in 4244 is that most current deployments that make use of History-Info security either isn't such a concern (within an enterprise for example) or there are other security solutions that prevent attacks (such as in a walled garden carrier deployment). I'm not against addressing security for more general cases but I think to be useful the target-uri solution needs to come out in something like a similar time frame to the publication of GRUU and not many years later waiting for thorny security issues to be addressed. ________________________________ From: Mary Barnes =20 To: Andrew Allen; ietf.hanserik@gmail.com =20 Cc: sipcore@ietf.org =20 Sent: Thu Apr 16 21:29:45 2009 Subject: RE: [sipcore] Target-uri document as SIPCORE WG document? (was RE:[Sip] SIPCORE -- If you're not subscribed, you're missing stuff=20 Hi Andrew, =20 Thanks for the clarification. On the security point, if the WG would agree that the same security considerations as in 4244 apply to target-uri - i.e., no more/no less, then yes, there's not an issue. As I understand it, the issue is that the bar is quite high in 4244 (e.g., TLS mandated), so the answer is that no one that has implemented it likely meets that security requirement. And, yes it is a big can of worms, just like any other security discussion is for SIP. But, what I'm trying to say is that if folks do believe the current security in 4244 is not adequate or implementable, then target-uri would have the same issue and thus need to address any concerns with 4244 security to be complete. Based on my experience with more recent RFCs, the bar for the security requirements and considerations for documents is significantly higher than it was when 4244 was published.=20 =20 Thus, there is no difference at all between progressing 4244bis versus target-uri, except that I think it is actually more difficult to properly define the normative processing for target-uri in a separate document than rely on the existing structure and text in 4244. =20 =20 Mary. =20 ________________________________ From: Andrew Allen [mailto:aallen@rim.com]=20 Sent: Thursday, April 16, 2009 7:27 PM To: Barnes, Mary (RICH2:AR00); ietf.hanserik@gmail.com Cc: sipcore@ietf.org Subject: Re: [sipcore] Target-uri document as SIPCORE WG document? (was RE:[Sip] SIPCORE -- If you're not subscribed, you're missing stuff My understanding of the outcome in San Francisco was that target-uri would update 4244 and 4244bis would be worked on in parallel and potentially obsolete both 4244 and target-uri.=20 Whatever is developed for target-uri ought to be able to be incorporated in 4244bis. If 4244 progresses well then target-uri may not need ultimately to be published separately.=20 I am afraid that the security question to be addressed by 4244bis is a big can of worms that is likely to be a long discussion. Is there a reason why target-uri can't progress under the current History-Info security framework? Is the security solution for 4244 actually technically broken or is it just that people don't implement it? There is not a draft dependecy on target-uri for GRUU but it was clearly identified during GRUU development that a lot of use cases for GRUU really need to know that the Request was addressed to a particular GRUU and without target-uri that functionality cannot be achieved.=20 ________________________________ From: Mary Barnes =20 To: Andrew Allen; ietf.hanserik@gmail.com =20 Cc: sipcore@ietf.org =20 Sent: Thu Apr 16 18:03:42 2009 Subject: RE: [sipcore] Target-uri document as SIPCORE WG document? (was RE:[Sip] SIPCORE -- If you're not subscribed, you're missing stuff=20 A few comments below [MB].=20 ________________________________ From: Andrew Allen [mailto:aallen@rim.com]=20 Sent: Thursday, April 16, 2009 4:50 PM To: Barnes, Mary (RICH2:AR00); ietf.hanserik@gmail.com Cc: sipcore@ietf.org Subject: Re: [sipcore] Target-uri document as SIPCORE WG document? (was RE:[Sip] SIPCORE -- If you're not subscribed, you're missing stuff My understanding was that we would move forward with both drafts as WG items. My understanding was that in Dublin Target-uri was adopted as a SIP WG item. I don't want to see 4244bis become a dependency for the target-uri work which is urgently needed to solve some GRUU related issues.=20 [MB] Per my original comments below, the changes for a target-uri solution based on 4244 is actually more work than putting the normative functionality in 4244bis - that's because you still need to address security, privacy, how it is processed by a UAC, Proxy and UAS. You would then need duplicate text to set the context, etc. and that text would be identical to what's in 4244 OR you'd be breaking existing implementations and there are some of those. Now, we did have one reasonable suggestion as to adding a recommendation that the Privacy not be applied to the entire message as that limits proxy functionality - that's important for target-uri, but it's also likely an oversight in the original 4244. [/MB] =20 If 4244bis is ready when target-uri is then we can talk about rolling the two into one but I have concerns that 4244bis will take considerably longer than target-uri based on the discussion in San Fran. =20 [MB] Nope - as I noted earlier, I think the discussion was confounded because people were talking about changes to 4244bis (History-Info) that were well beyond what is required for target-uri - i.e., paring down the functionality to only collect the desired entries, which doesn't save a bit of work because you still have to recognize the conditions under which you drop the entries. Please listen to Francois' response to Hadriel's suggestion in the audio - it's towards the end. Also, the same security issues apply - when we completed 4244, the security section was carefully crafted based on security thoughts at the time. Those have changed (obviously) and if they are problematic in 4244bis, they would be a problem for the target-uri usage of 4244, which has the same security requirements as core 4244. [/MB] Target-uri has been needed really for GRUU for more then 2 years and is fairly straightforward. I don't think we should risk delaying that work waiting for 4244bis which seems to contain a number of issues we don't have consensus on yet.=20 [MB] The other changes to 4244bis are minor as compared to the normative functionality that needs to be added to the document to support target-uri. Please look at the diff. I also don't see the GRUU dependency - can you please clarify? I know GRUU is waiting for Outbound (I promise I will give up if 4244bis reaches a point where it is taking longer to finish than Outbound) and that the gruu-reg-event pkg is waiting for GRUU. [/MB]=20 That was my understanding of the approach we determined in San Francisco. ________________________________ From: sipcore-bounces@ietf.org =20 To: Hans Erik van Elburg =20 Cc: sipcore@ietf.org =20 Sent: Thu Apr 16 17:34:57 2009 Subject: Re: [sipcore] Target-uri document as SIPCORE WG document? (was RE:[Sip] SIPCORE -- If you're not subscribed, you're missing stuff=20 No - the discussion for 4244(bis) (extracted below) was entirely in the context of the discussion for the target-uri document. You can go back and listen to the audio to verify that. And, I've stated long before IETF-73 that it would be fairly straightforward to update 4244 to accomodate the target-uri requirements and while we were doing that, there were a few other fixes we could do.=20 =20 Mary.=20 ________________________________ From: Hans Erik van Elburg [mailto:ietf.hanserik@gmail.com]=20 Sent: Thursday, April 16, 2009 4:22 PM To: Barnes, Mary (RICH2:AR00) Cc: Dean Willis; sipcore@ietf.org Subject: Re: [sipcore] Target-uri document as SIPCORE WG document? (was RE: [Sip] SIPCORE -- If you're not subscribed, you're missing stuff Hi Mary, I believe that in the absence of consensus as the minutes correctly state, the the target-uri document should remain the WG document for the target-uri deliverable. 4424bis has another purpose, namely to fix the 4424. If at a certain moment in time it turns out that 4424bis is the appropriate document to contain normative text for target uri delivery then we can always decide to do so. At this stage it is to early to take that decision, given the confused state of the target-uri discussion. /Hans Erik van Elburg On Thu, Apr 16, 2009 at 10:02 PM, Mary Barnes wrote: I'm suggesting to change the decision from IETF-73 and accept the more recent realization that including normative text in another document rather than 4244bis will be fraught with error and I can't see how that is a good idea from a development perspective - you can't just implement the target-uri document. =09 Now, I don't have a problem if folks can accept that the target-uri document might change such that the normative functionality is in 4244bis. And, this was consensus from IETF-73 per those minutes: "Issue: Normative behavior update for RFC 4244 =09 Consensus noted to revise RFC 4244, and fix some other known problems with it at teh same time. MAry Barnes volunteered to edit the document." =09 So, there is a conflict in terms of accepting target-uri document as the only deliverable for that milestone in the IETF-73 meeting. =09 Mary. =09 =09 -----Original Message----- From: Dean Willis [mailto:dean.willis@softarmor.com] Sent: Thursday, April 16, 2009 2:36 PM To: Barnes, Mary (RICH2:AR00) Cc: sipcore@ietf.org Subject: Re: [sipcore] [Sip] SIPCORE -- If you're not subscribed, you're missing stuff =09 =09 On Apr 16, 2009, at 2:27 PM, Mary Barnes wrote: =09 > I have an issue with the target-uri document being proposed as the WG > document for the target-uri deliverable. This was not the consensus in =09 > SF per my recollection (which may be biased) nor per the SIP WG > minutes: > http://www.ietf.org/proceedings/09mar/minutes/sip.html > > Which state: > "Issue: Progress 4244bis, target-uri draft, or both? > In the absence of a clear consensus, the chairs proposed that both > documents proceed and we'll hope that further discussion gives us a > consensus." > > Now, I realize that there are now new chairs, but I don't think that > should change the WG consensus from the SIP WG session. =09 However, the minutes from IETF 73 read: =09 Topic: URI and Parameter Delivery Led by Jonaathan Rosenberg Slides presented =09 http://tools.ietf.org/id/draft-rosenberg-sip-target-uri-delivery-00.txt =09 ... =09 Poll: Shall WG adopt this draft towards our charter deliverable on the topic? Chairs reported a strong consensus to do so. So which WG consensus of which SIP WG session do you not want to change? =09 =09 =09 > > It was my understanding from the minutes that the discussion was to > continue as to whether we would merge the two documents or agree one > or the other as a WG deliverable. > =09 =09 That's also consistent with my notes from SIP at 74. =09 My best guess is that RFC 4244bis goes forward, and that target-uri- delivery turns into a "How to use H-I to meet the URI delivery use cases" document. =09 -- Dean =09 =09 =09 =09 _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore =09 ---------------------------------------------------------------------=20 This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client 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 immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. ---------------------------------------------------------------------=20 This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client 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 immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful. ---------------------------------------------------------------------=20 This transmission (including any attachments) may contain confidential information, privileged material (including material protected by the solicitor-client 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 immediately reply to the sender and delete this information from your system. Use, dissemination, distribution, or reproduction of this transmission by unintended recipients is not authorized and may be unlawful.=20 ------_=_NextPart_001_01C9BF60.4E3B3C6F Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
The=20 point I was trying to make is that if the current security in 4244 is = adequate=20 for target-uri, then it is just as easy to put the normative text in = 4244bis and=20 be done with it (and not change current security - I think the = scoping=20 is already in there for the type of networks you mention in = section=20 5).   However,  IF folks believe there is a problem with = 4244=20 security, then that's a problem for target-uri, as well, since it is = relying on=20 that security - i.e., transitively it's a problem.  Now, the WG = might=20 decide to wiggle their way out of that, but again my experience is that = wiggle=20 room in security considerations for protocols is non-existent. =20
 
Mary.=20

From: Andrew Allen = [mailto:aallen@rim.com]=20
Sent: Thursday, April 16, 2009 9:35 PM
To: Barnes, = Mary=20 (RICH2:AR00); ietf.hanserik@gmail.com
Cc:=20 sipcore@ietf.org
Subject: Re: [sipcore] Target-uri document as = SIPCORE=20 WG document? (was RE:[Sip] SIPCORE -- If you're not subscribed, you're = missing=20 stuff


At least in my mind = target-uri is just=20 a minor enhancement/extension to History-Info to address the issue of = rewriting=20 the Request-URI with the contact. Does target-uri usage introduce some = new=20 security concern over and above existing uses of History-Info in RFC = 4244? If=20 not then I don't think its fair to delay a solution to the target-uri = problem=20 space while we go off and attempt to come up with a new improved = security=20 solution over and above what is already in 4244 that everyone will love = so much=20 they will actually implement it.

I suspect that one reason why = people=20 haven't implemented what is already defined in 4244 is that most current = deployments that make use of History-Info security either isn't such a = concern=20 (within an enterprise for example) or there are other security solutions = that=20 prevent attacks (such as in a walled garden carrier deployment). I'm not = against=20 addressing security for more general cases but I think to be useful the=20 target-uri solution needs to come out in something like a similar time = frame to=20 the publication of GRUU and not many years later waiting for thorny = security=20 issues to be addressed.

From: Mary Barnes = <mary.barnes@nortel.com>=20
To: Andrew Allen; ietf.hanserik@gmail.com=20 <ietf.hanserik@gmail.com>
Cc: sipcore@ietf.org=20 <sipcore@ietf.org>
Sent: Thu Apr 16 21:29:45=20 2009
Subject: RE: [sipcore] Target-uri document as SIPCORE WG=20 document? (was RE:[Sip] SIPCORE -- If you're not subscribed, you're = missing=20 stuff

Hi=20 Andrew,
 
Thanks=20 for the clarification. On the security point,  if the WG = would=20 agree that the same security considerations as in 4244 apply to = target-uri -=20 i.e., no more/no less, then yes, there's not an issue. As I understand = it, the=20 issue is that the bar is quite high in 4244 (e.g., TLS mandated), so the = answer=20 is that no one that has implemented it likely meets that security=20 requirement.  And, yes it is a big can of worms, just like any = other=20 security discussion is for SIP.  But, what I'm trying to say is = that if=20 folks do believe the current security in 4244 is not adequate or = implementable,=20 then target-uri would have the same issue and thus need to address any = concerns=20 with 4244 security to be complete. Based on my experience with = more=20 recent RFCs, the bar for the security requirements and considerations = for=20 documents is significantly higher than it was when 4244 was published.=20
 
Thus,=20  there is no difference at all between progressing 4244bis versus=20 target-uri, except that I think it is actually more difficult to = properly define=20 the normative processing for target-uri in a separate document than rely = on the=20 existing structure and text in 4244. 
 
Mary.
 
From: Andrew Allen = [mailto:aallen@rim.com]=20
Sent: Thursday, April 16, 2009 7:27 PM
To: Barnes, = Mary=20 (RICH2:AR00); ietf.hanserik@gmail.com
Cc:=20 sipcore@ietf.org
Subject: Re: [sipcore] Target-uri document as = SIPCORE=20 WG document? (was RE:[Sip] SIPCORE -- If you're not subscribed, you're = missing=20 stuff


My understanding of the = outcome in San=20 Francisco was that target-uri would update 4244 and 4244bis would be = worked on=20 in parallel and potentially obsolete both 4244 and target-uri. =

Whatever=20 is developed for target-uri ought to be able to be incorporated in = 4244bis. If=20 4244 progresses well then target-uri may not need ultimately to be = published=20 separately.

I am afraid that the security question to be = addressed by=20 4244bis is a big can of worms that is likely to be a long discussion. Is = there a=20 reason why target-uri can't progress under the current History-Info = security=20 framework? Is the security solution for 4244 actually technically broken = or is=20 it just that people don't implement it?

There is not a draft = dependecy on=20 target-uri for GRUU but it was clearly identified during GRUU = development that a=20 lot of use cases for GRUU really need to know that the Request was = addressed to=20 a particular GRUU and without target-uri that functionality cannot be = achieved.=20

From: Mary Barnes = <mary.barnes@nortel.com>=20
To: Andrew Allen; ietf.hanserik@gmail.com=20 <ietf.hanserik@gmail.com>
Cc: sipcore@ietf.org=20 <sipcore@ietf.org>
Sent: Thu Apr 16 18:03:42=20 2009
Subject: RE: [sipcore] Target-uri document as SIPCORE WG=20 document? (was RE:[Sip] SIPCORE -- If you're not subscribed, you're = missing=20 stuff

A few=20 comments below [MB].

From: Andrew Allen = [mailto:aallen@rim.com]=20
Sent: Thursday, April 16, 2009 4:50 PM
To: Barnes, = Mary=20 (RICH2:AR00); ietf.hanserik@gmail.com
Cc:=20 sipcore@ietf.org
Subject: Re: [sipcore] Target-uri document as = SIPCORE=20 WG document? (was RE:[Sip] SIPCORE -- If you're not subscribed, you're = missing=20 stuff


My understanding was that we would = move forward=20 with both drafts as WG items.

My understanding was that in Dublin = Target-uri was adopted as a SIP WG item. I don't want to see 4244bis = become a=20 dependency for the target-uri work which is urgently needed to solve = some GRUU=20 related issues. 

[MB] Per my original comments below, = the changes for a=20 target-uri solution based on 4244 is actually more work=20 than putting the normative functionality in 4244bis - that's = because=20 you still need to address security, privacy, how it is processed = by a=20 UAC, Proxy and UAS. You would then need duplicate text to set = the=20 context, etc. and that text would be identical to what's in 4244 OR = you'd be=20 breaking existing implementations and there are some of those. Now, we = did have=20 one reasonable suggestion as to adding a recommendation that the Privacy = not be=20 applied to the entire message as that limits proxy functionality - = that's=20 important for target-uri, but it's also likely an oversight in the = original=20 4244. [/MB]  

If 4244bis is ready when = target-uri=20 is then we can talk about rolling the two into one but I have concerns = that=20 4244bis will take considerably longer than target-uri based on the = discussion in=20 San Fran.  

[MB] Nope - as I noted earlier, I think the discussion = was=20 confounded because people were talking about changes to 4244bis=20 (History-Info) that were well beyond what is required for target-uri - = i.e.,=20 paring down the functionality to only collect the desired entries, which = doesn't=20 save a bit of work because you still have to recognize the = conditions under=20 which you drop the entries.  Please listen to Francois' response to = Hadriel's suggestion in the audio - it's towards the end. Also, the same = security issues apply - when we completed 4244, the security section was = carefully crafted based on security thoughts at the time. Those have = changed=20 (obviously) and if they are problematic in 4244bis, they would be a = problem for=20 the target-uri usage of 4244, which has the same security requirements = as core=20 4244.  [/MB]

Target-uri has been needed = really=20 for GRUU for more then 2 years and is fairly straightforward. I don't = think we=20 should risk delaying that work waiting for 4244bis which seems to = contain a=20 number of issues we don't have consensus on yet. 

[MB] The other changes to 4244bis are = minor as=20 compared to the normative functionality that needs to be added to the = document=20 to support target-uri. Please look at the diff.  I also don't see = the GRUU=20 dependency - can you please clarify?  I know GRUU is = waiting for=20 Outbound (I promise I will give up if 4244bis reaches a point where = it is=20 taking longer to finish than Outbound) and that the gruu-reg-event = pkg is=20 waiting for GRUU.  [/MB] 

That was = my=20 understanding of the approach we determined in San=20 Francisco.

From: sipcore-bounces@ietf.org=20 <sipcore-bounces@ietf.org>
To: Hans Erik van Elburg=20 <ietf.hanserik@gmail.com>
Cc: sipcore@ietf.org=20 <sipcore@ietf.org>
Sent: Thu Apr 16 17:34:57=20 2009
Subject: Re: [sipcore] Target-uri document as SIPCORE WG=20 document? (was RE:[Sip] SIPCORE -- If you're not subscribed, you're = missing=20 stuff

No -=20 the discussion for 4244(bis) (extracted below) was entirely in the = context of=20 the discussion for the target-uri document. You can go back and listen = to the=20 audio to verify that.  And, I've stated long before IETF-73 that it = would=20 be fairly straightforward to update 4244 to accomodate the target-uri=20 requirements and while we were doing that, there were a few other fixes = we could=20 do.
 
Mary.=20

From: Hans Erik van Elburg=20 [mailto:ietf.hanserik@gmail.com]
Sent: Thursday, April 16, = 2009 4:22=20 PM
To: Barnes, Mary (RICH2:AR00)
Cc: Dean Willis;=20 sipcore@ietf.org
Subject: Re: [sipcore] Target-uri document as = SIPCORE=20 WG document? (was RE: [Sip] SIPCORE -- If you're not subscribed, you're = missing=20 stuff

Hi Mary,

I believe that in the absence of consensus as = the=20 minutes correctly state, the the target-uri document should remain the = WG=20 document for the target-uri deliverable.

4424bis has another = purpose,=20 namely to fix the 4424. If at a certain moment in time it turns out that = 4424bis=20 is the appropriate document to contain normative text for target uri = delivery=20 then we can always decide to do so. At this stage it is to early to take = that=20 decision, given the confused state of the target-uri discussion.
/Hans Erik van Elburg


On Thu, Apr 16, 2009 at 10:02 PM, Mary Barnes = <mary.barnes@nortel.com>=20 wrote:
I'm=20 suggesting to change the decision from IETF-73 and accept the = more
recent=20 realization that including normative text in another = document
rather than=20 4244bis will be fraught with error and I can't see how that
is a = good idea=20 from a development perspective - you can't just implement
the = target-uri=20 document.

Now, I don't have a problem if folks can accept that = the=20 target-uri
document might change such that the normative = functionality is=20 in
4244bis.   And, this was consensus from IETF-73 per those=20 minutes:
"Issue: Normative behavior update for RFC = 4244

Consensus=20 noted to revise RFC 4244, and fix some other known problems
with it = at teh=20 same time. MAry Barnes volunteered to edit = the
document."

So, there=20 is a conflict in terms of accepting target-uri document as the
only = deliverable for that milestone in the IETF-73=20 meeting.

Mary.


-----Original Message-----
From: = Dean=20 Willis [mailto:dean.willis@softarmor.com]<= BR>Sent:=20 Thursday, April 16, 2009 2:36 PM
To: Barnes, Mary = (RICH2:AR00)
Cc: sipcore@ietf.org
Subject: Re: = [sipcore]=20 [Sip] SIPCORE -- If you're not subscribed, you're
missing=20 stuff


On Apr 16, 2009, at 2:27 PM, Mary Barnes = wrote:

> I=20 have an issue with the target-uri document being proposed as the = WG
>=20 document for the target-uri deliverable. This was not the consensus=20 in

> SF per my recollection (which may be biased) nor per = the SIP=20 WG
> minutes:
> http://www.ietf.org/proceedings/09mar/minutes/sip.html
>
>=20 Which state:
> "Issue: Progress 4244bis, target-uri draft, or=20 both?
> In the absence of a clear consensus, the chairs proposed = that=20 both
> documents proceed and we'll hope that further discussion = gives us=20 a
> consensus."
>
> Now, I realize that there are = now new=20 chairs, but I don't think that
> should change the WG consensus = from the=20 SIP WG session.

However, the minutes from IETF 73 = read:

Topic:=20 URI and Parameter Delivery
Led by Jonaathan Rosenberg
Slides=20 presented
http://tools.ietf.org/id/draft-rosenberg-sip-target-uri-d= elivery-00.txt

...

Poll:=20 Shall WG adopt this draft towards our charter deliverable on = the
topic?=20 Chairs reported a strong consensus to do so.
So which WG consensus = of which=20 SIP WG session do you not want to change?



>
> = It was=20 my understanding from the minutes that the discussion was to
> = continue=20 as to whether we would merge the two documents or agree one
> or = the=20 other as a WG deliverable.
>


That's also consistent = with my=20 notes from SIP at 74.

My best guess is that RFC 4244bis goes = forward,=20 and that target-uri-
delivery turns into a "How to use H-I to meet = the URI=20 delivery use
cases"=20 = document.

--
Dean




__________________________= _____________________
sipcore=20 mailing list
sipcore@ietf.org
https://www.ietf.org/mailman/listinfo/sipcore

------------------------------------------------------= ---------------=20
This transmission (including any attachments) may contain = confidential=20 information, privileged material (including material protected by the=20 solicitor-client or other applicable privileges), or constitute = non-public=20 information. Any use of this information by anyone other than the = intended=20 recipient is prohibited. If you have received this transmission in = error, please=20 immediately reply to the sender and delete this information from your = system.=20 Use, dissemination, distribution, or reproduction of this transmission = by=20 unintended recipients is not authorized and may be unlawful.=20 --------------------------------------------------------------------- =
This=20 transmission (including any attachments) may contain confidential = information,=20 privileged material (including material protected by the = solicitor-client or=20 other applicable privileges), or constitute non-public information. Any = use of=20 this information by anyone other than the intended recipient is = prohibited. If=20 you have received this transmission in error, please immediately reply = to the=20 sender and delete this information from your system. Use, dissemination, = distribution, or reproduction of this transmission by unintended = recipients is=20 not authorized and may be unlawful.=20 --------------------------------------------------------------------- =
This=20 transmission (including any attachments) may contain confidential = information,=20 privileged material (including material protected by the = solicitor-client or=20 other applicable privileges), or constitute non-public information. Any = use of=20 this information by anyone other than the intended recipient is = prohibited. If=20 you have received this transmission in error, please immediately reply = to the=20 sender and delete this information from your system. Use, dissemination, = distribution, or reproduction of this transmission by unintended = recipients is=20 not authorized and may be unlawful. ------_=_NextPart_001_01C9BF60.4E3B3C6F-- From mary.barnes@nortel.com Fri Apr 17 07:05:16 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A3BB23A6892 for ; Fri, 17 Apr 2009 07:05:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.468 X-Spam-Level: X-Spam-Status: No, score=-6.468 tagged_above=-999 required=5 tests=[AWL=0.130, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hAlnelqEiujH for ; Fri, 17 Apr 2009 07:05:15 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id D58483A6836 for ; Fri, 17 Apr 2009 07:05:14 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id n3HE6Bj14416; Fri, 17 Apr 2009 14:06:11 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C9BF65.A6B77F07" Date: Fri, 17 Apr 2009 09:08:57 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF1D7FA483@zrc2hxm0.corp.nortel.com> In-Reply-To: <1ECE0EB50388174790F9694F77522CCF1D7FA1E8@zrc2hxm0.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] Target-uri document as SIPCORE WG document? (wasRE:[Sip] SIPCORE -- If you're not subscribed, you're missing stuff Thread-Index: Acm+2VlZABnKJIMzQmy6h7q6thF4/gAAZt8gAACTQZQAACG6sAAFX0/WAAHeVrAAApNCWwACsIGQABUACFA= References: <61968779B8AC4C4BAB421D4C12F008C015FEA2B3@XCH47YKF.rim.net> <1ECE0EB50388174790F9694F77522CCF1D7FA1E8@zrc2hxm0.corp.nortel.com> From: "Mary Barnes" To: "Francois Audet" , "Andrew Allen" , Cc: sipcore@ietf.org Subject: Re: [sipcore] Target-uri document as SIPCORE WG document? (wasRE:[Sip] SIPCORE -- If you're not subscribed, you're missing stuff X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 17 Apr 2009 14:05:16 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9BF65.A6B77F07 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I don't disagree that we could loosen the mandating of TLS, but per my response to Andrew, there is a modicum of wiggle room in section 5 - for applications that may not have a need for TLS. Also, earlier versions of the history-info draft did have less restrictive security requirements, but again this was based on WG consensus at the time.=20 =20 Here is the old document where we were trying to build a robust m2m security solution that would support history-info and other headers that are added by intermediaries: http://www.softarmor.com/wgdb/docs/draft-barnes-sipping-sec-inserted-inf o-02.txt =20 =20 While the document is focused on a solution for the m2m and m2e security specific to History-Info, one objective was to raise the bar for other similar headers. We gave up on providing a generalized solution, as the scope was really too large and predates alot of the more current security work, but it at least gives the background. We can find more details as to why we gave up in the minutes from IETF-60 (Aug 2004):=20 http://www.softarmor.com/sipwg/meets/ietf60/notes/minutes.html I think it was really due to the current state of Identity, which didn't complete until over a year later - History-Info completed WGLC just after IETF-61 (Nov 2004). =20 I do think we can make some fairly modest changes to the 4244 security section and get that to the status quo for other similar headers. =20 Mary.=20 ________________________________ From: Audet, Francois (SC100:3055)=20 Sent: Thursday, April 16, 2009 11:11 PM To: Andrew Allen; Barnes, Mary (RICH2:AR00); ietf.hanserik@gmail.com Cc: sipcore@ietf.org Subject: RE: [sipcore] Target-uri document as SIPCORE WG document? (wasRE:[Sip] SIPCORE -- If you're not subscribed, you're missing stuff Some people have implemented both RFC 4244 AND TLS (we have for example, in quite a few separate implementations). That's not an issue. =20 However, for the love of God, I don't understand why there is something so special in the History-Info header that warrants a higher bar (i.e., forcing TLS on every hop) than any of the other similar headers in SIP (Via, From, To, Route, Record-Route and even the Request-URI). The security section certainly does not explain this gratuitous requirement. =20 Consequently, I really don't believe that anybody would implement TLS BECAUSE it supports 4244. =20 Maybe I'm missing the reason, and somebody will enlighten us. But it seems unlikely to me. =20 As discussed in San Francisco, it would be much more productive to figure out what are the real security considerations for History-Info. =20 =20 PS: Don't get me wrong: I'd be in favor of mandating TLS all the time for SIP 3.0. But mandating TLS specifically for the purpose of using History-Info is completely unreasonable. I suspect that one reason why people haven't implemented what is already defined in 4244 is that most current deployments that make use of History-Info security either isn't such a concern (within an enterprise for example) or there are other security solutions that prevent attacks (such as in a walled garden carrier deployment). I'm not against addressing security for more general cases but I think to be useful the target-uri solution needs to come out in something like a similar time frame to the publication of GRUU and not many years later waiting for thorny security issues to be addressed. =09 ------_=_NextPart_001_01C9BF65.A6B77F07 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
I=20 don't disagree that we could loosen the mandating of TLS, but per my = response to=20 Andrew, there is a modicum of wiggle room in section 5 - for = applications that=20 may not have a need for TLS.  Also, earlier versions of the = history-info=20 draft did have less restrictive security requirements, but again this = was based=20 on WG consensus at the time.
 
Here=20 is the old document where we were trying to build a robust m2m security = solution=20 that would support history-info and other headers that are added by=20 intermediaries:
http://www.softarmor.com/wgdb/docs/draft-barnes-sipping-= sec-inserted-info-02.txt =20
 
While=20 the document is focused on a solution for the m2m and m2e security = specific=20 to History-Info, one objective was to raise the bar for other = similar=20 headers.  We gave up on providing = a=20 generalized solution, as the scope was really too large and = predates alot=20 of the more current security work, but it at least gives the = background. =20 We can find more details as to why we gave up in the minutes from = IETF-60 (Aug=20 2004):
h= ttp://www.softarmor.com/sipwg/meets/ietf60/notes/minutes.html<= /SPAN>
I think it was really due to the current = state of=20 Identity, which didn't complete until over a year later - = History-Info=20 completed WGLC just after IETF-61 (Nov=20 2004).
 
I do=20 think we can make some fairly modest changes to the 4244 security = section and=20 get that to the status quo for other similar = headers.
 
Mary.=20

From: Audet, Francois (SC100:3055)=20
Sent: Thursday, April 16, 2009 11:11 PM
To: Andrew = Allen;=20 Barnes, Mary (RICH2:AR00); ietf.hanserik@gmail.com
Cc:=20 sipcore@ietf.org
Subject: RE: [sipcore] Target-uri document as = SIPCORE=20 WG document? (wasRE:[Sip] SIPCORE -- If you're not subscribed, you're = missing=20 stuff

Some=20 people have implemented both RFC 4244 AND TLS (we have for example, in = quite a=20 few separate implementations). That's not an issue.
 
However, for the love of God, I don't = understand why=20 there is something so special in the History-Info header that warrants a = higher=20 bar (i.e., forcing TLS on every hop) than any of the other similar = headers in=20 SIP (Via, From, To, Route, Record-Route and even the Request-URI). The = security=20 section certainly does not explain this gratuitous requirement.=20
 
Consequently, I really don't believe that = anybody would=20 implement TLS BECAUSE it supports 4244.
 
Maybe=20 I'm missing the reason, and somebody will enlighten us. But it seems = unlikely to=20 me.
 
As=20 discussed in San Francisco, it would be much more productive to figure = out what=20 are the real security considerations for = History-Info.
 
 
PS:=20 Don't get me wrong: I'd be in favor of mandating TLS all the time for = SIP 3.0.=20 But mandating TLS specifically for the purpose of using History-Info is=20 completely unreasonable.

I suspect that one reason why people haven't = implemented=20 what is already defined in 4244 is that most current deployments that = make use=20 of History-Info security either isn't such a concern (within an = enterprise for=20 example) or there are other security solutions that prevent attacks = (such as=20 in a walled garden carrier deployment). I'm not against addressing = security=20 for more general cases but I think to be useful the target-uri = solution needs=20 to come out in something like a similar time frame to the publication = of GRUU=20 and not many years later waiting for thorny security issues to be=20 addressed.
------_=_NextPart_001_01C9BF65.A6B77F07-- From root@core3.amsl.com Mon Apr 20 03:15:02 2009 Return-Path: X-Original-To: sipcore@ietf.org Delivered-To: sipcore@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 0D1AB3A6D0E; Mon, 20 Apr 2009 03:15:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090420101502.0D1AB3A6D0E@core3.amsl.com> Date: Mon, 20 Apr 2009 03:15:02 -0700 (PDT) X-Mailman-Approved-At: Mon, 20 Apr 2009 08:16:40 -0700 Cc: sipcore@ietf.org Subject: [sipcore] I-D Action:draft-ietf-sipcore-subnot-etags-00.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Apr 2009 10:15:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session Initiation Protocol Core Working Group of the IETF. Title : An Extension to Session Initiation Protocol (SIP) Events for Conditional Event Notification Author(s) : A. Niemi Filename : draft-ietf-sipcore-subnot-etags-00.txt Pages : 24 Date : 2009-04-19 The Session Initiation Protocol (SIP) events framework enables receiving asynchronous notification of various events from other SIP user agents. This framework defines the procedures for creating, refreshing and terminating subscriptions, as well as fetching and periodic polling of resource state. These procedures have a serious deficiency in that they provide no tools to avoid replaying event notifications that have already been received by a user agent. This memo defines an extension to SIP events that allows the subscriber to condition the subscription request to whether the state has changed since the previous notification was received. When such a condition is true, either the body of a resulting event notification or the entire notification message is suppressed. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sipcore-subnot-etags-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-sipcore-subnot-etags-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-04-20030648.I-D@ietf.org> --NextPart-- From dean.willis@softarmor.com Mon Apr 20 11:47:23 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 597943A6E96 for ; Mon, 20 Apr 2009 11:47:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.556 X-Spam-Level: X-Spam-Status: No, score=-2.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aM7X0+ioxyYn for ; Mon, 20 Apr 2009 11:47:22 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 73CDB3A6F81 for ; Mon, 20 Apr 2009 11:47:22 -0700 (PDT) Received: from [192.168.2.102] (cpe-72-181-150-177.tx.res.rr.com [72.181.150.177]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id n3KImaVm006856 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Mon, 20 Apr 2009 13:48:38 -0500 Message-Id: <28ECBC7C-AD82-4F29-A774-5316D818A3BB@softarmor.com> From: Dean Willis To: sipcore@ietf.org In-Reply-To: <20090420101502.0D1AB3A6D0E@core3.amsl.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Mon, 20 Apr 2009 13:48:31 -0500 References: <20090420101502.0D1AB3A6D0E@core3.amsl.com> X-Mailer: Apple Mail (2.930.3) Subject: Re: [sipcore] I-D Action:draft-ietf-sipcore-subnot-etags-00.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Apr 2009 18:47:23 -0000 This document replaces the old draft-ietf-sip-subnot-etags-04 document. I had been working on the proto writeup for it in SIP, but found some idnits-level bugs and asked the author to revise it appropriately. I believe it to be "past WGLC" and ready for publication request. -- Dean On Apr 20, 2009, at 5:15 AM, internet-drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > This draft is a work item of the Session Initiation Protocol Core > Working Group of the IETF. > > > Title : An Extension to Session Initiation Protocol (SIP) > Events for Conditional Event Notification > Author(s) : A. Niemi > Filename : draft-ietf-sipcore-subnot-etags-00.txt > Pages : 24 > Date : 2009-04-19 > > The Session Initiation Protocol (SIP) events framework enables > receiving asynchronous notification of various events from other SIP > user agents. This framework defines the procedures for creating, > refreshing and terminating subscriptions, as well as fetching and > periodic polling of resource state. These procedures have a serious > deficiency in that they provide no tools to avoid replaying event > notifications that have already been received by a user agent. This > memo defines an extension to SIP events that allows the subscriber to > condition the subscription request to whether the state has changed > since the previous notification was received. When such a condition > is true, either the body of a resulting event notification or the > entire notification message is suppressed. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-sipcore-subnot-etags-00.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From root@core3.amsl.com Mon Apr 20 12:45:01 2009 Return-Path: X-Original-To: sipcore@ietf.org Delivered-To: sipcore@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 9B4C73A6C6F; Mon, 20 Apr 2009 12:45:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090420194501.9B4C73A6C6F@core3.amsl.com> Date: Mon, 20 Apr 2009 12:45:01 -0700 (PDT) X-Mailman-Approved-At: Mon, 20 Apr 2009 13:15:03 -0700 Cc: sipcore@ietf.org Subject: [sipcore] I-D Action:draft-ietf-sipcore-presence-scaling-requirements-00.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Apr 2009 19:45:01 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session Initiation Protocol Core Working Group of the IETF. Title : Scaling Requirements for Presence in SIP/SIMPLE Author(s) : A. Houri, et al. Filename : draft-ietf-sipcore-presence-scaling-requirements-00.txt Pages : 9 Date : 2009-04-20 The document provides a set of requirements for enabling interdomain scaling in presence for SIP/SIMPLE. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sipcore-presence-scaling-requirements-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-sipcore-presence-scaling-requirements-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-04-20123041.I-D@ietf.org> --NextPart-- From dean.willis@softarmor.com Tue Apr 21 11:57:19 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0688328C1A6 for ; Tue, 21 Apr 2009 11:57:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.556 X-Spam-Level: X-Spam-Status: No, score=-2.556 tagged_above=-999 required=5 tests=[AWL=0.043, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ruDvfnIj4GnK for ; Tue, 21 Apr 2009 11:57:12 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 8F80A28C13D for ; Tue, 21 Apr 2009 11:57:11 -0700 (PDT) Received: from [192.168.2.102] (cpe-72-181-150-177.tx.res.rr.com [72.181.150.177]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id n3LIwQS3018405 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Tue, 21 Apr 2009 13:58:27 -0500 Message-Id: <75B7C19A-FE04-4B03-9E2C-AC213C007FB9@softarmor.com> From: Dean Willis To: sipcore@ietf.org In-Reply-To: <28ECBC7C-AD82-4F29-A774-5316D818A3BB@softarmor.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Tue, 21 Apr 2009 13:58:21 -0500 References: <20090420101502.0D1AB3A6D0E@core3.amsl.com> <28ECBC7C-AD82-4F29-A774-5316D818A3BB@softarmor.com> X-Mailer: Apple Mail (2.930.3) Subject: Re: [sipcore] I-D Action:draft-ietf-sipcore-subnot-etags-00.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Apr 2009 18:57:19 -0000 On Apr 20, 2009, at 1:48 PM, Dean Willis wrote: > This document replaces the old draft-ietf-sip-subnot-etags-04 > document. I had been working on the proto writeup for it in SIP, but > found some idnits-level bugs and asked the author to revise it > appropriately. > > I believe it to be "past WGLC" and ready for publication request. > Ok, I was wrong. On further review, I found a couple of trivial typos and was fixing them for IETFLC when Adam called me with a more serious bug for which he thinks he has a workaround. He will send me text, I will fold his workaround in with the typo-fixes, and submit the result as -01 so that we can discuss it on-list. -- Dean From dean.willis@softarmor.com Tue Apr 21 15:18:07 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E81173A6E69 for ; Tue, 21 Apr 2009 15:18:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.557 X-Spam-Level: X-Spam-Status: No, score=-2.557 tagged_above=-999 required=5 tests=[AWL=0.042, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7SaHawRUDQOs for ; Tue, 21 Apr 2009 15:18:07 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 0E1523A6EFB for ; Tue, 21 Apr 2009 15:18:06 -0700 (PDT) Received: from [192.168.2.102] (cpe-72-181-150-177.tx.res.rr.com [72.181.150.177]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id n3LMJMTb019889 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for ; Tue, 21 Apr 2009 17:19:23 -0500 Message-Id: <90F90B9D-2791-4B60-A5EF-F89114C9453E@softarmor.com> From: Dean Willis To: sipcore@ietf.org Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Tue, 21 Apr 2009 17:19:16 -0500 X-Mailer: Apple Mail (2.930.3) Subject: [sipcore] ABNF discussion on draft-ietf-subnot-etags X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Apr 2009 22:18:08 -0000 I'm looking at the proto writeup for subnot-etags, and doing the required validation of the ABNF using BAP. I'm not Mr. Grammar (lately, even simple English escapes me), so double-check me please. The draft says: Suppress-If-Match = "Suppress-If-Match" ":" entity-tag / "*" BAP canonicalizes this to: Suppress-If-Match = ( "Suppress-If-Match:" entity-tag ) / "*" Note the added parentheses. AFAIK, this is effectively a null-op; the canonical ABNF is equivalent to the original. But sometimes the priority of ABNF operators escapes me, hence I ask: Anybody disagree? Now for a matter of style: Would it be better to have the draft use the canonical form, since it relieves this poor reader's ambiguity? Side note: BAP is cool! See: http://tools.ietf.org/tools/bap/abnf.cgi -- Dean From scott.lawrence@nortel.com Tue Apr 21 16:12:03 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6246128C32A for ; Tue, 21 Apr 2009 16:12:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.609 X-Spam-Level: X-Spam-Status: No, score=-4.609 tagged_above=-999 required=5 tests=[AWL=1.991, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8cXHj71+KPqI for ; Tue, 21 Apr 2009 16:12:02 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id EAC7328C1D6 for ; Tue, 21 Apr 2009 16:12:01 -0700 (PDT) Received: from zrtphxs1.corp.nortel.com (zrtphxs1.corp.nortel.com [47.140.202.46]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id n3LNDFH22424; Tue, 21 Apr 2009 23:13:15 GMT Received: from [127.0.0.1] ([47.17.25.99]) by zrtphxs1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 21 Apr 2009 19:13:14 -0400 From: "Scott Lawrence" To: Dean Willis In-Reply-To: <90F90B9D-2791-4B60-A5EF-F89114C9453E@softarmor.com> References: <90F90B9D-2791-4B60-A5EF-F89114C9453E@softarmor.com> Content-Type: text/plain Organization: Nortel Networks Date: Tue, 21 Apr 2009 19:13:13 -0400 Message-Id: <1240355593.3473.5.camel@scott> Mime-Version: 1.0 X-Mailer: Evolution 2.24.5 (2.24.5-1.fc10) Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 21 Apr 2009 23:13:14.0335 (UTC) FILETIME=[BF32FEF0:01C9C2D6] Cc: sipcore@ietf.org Subject: Re: [sipcore] ABNF discussion on draft-ietf-subnot-etags X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Apr 2009 23:12:03 -0000 On Tue, 2009-04-21 at 17:19 -0500, Dean Willis wrote: > I'm looking at the proto writeup for subnot-etags, and doing the > required validation of the ABNF using BAP. I'm not Mr. Grammar > (lately, even simple English escapes me), so double-check me please. > > > The draft says: > > Suppress-If-Match = "Suppress-If-Match" ":" entity-tag / "*" > > > BAP canonicalizes this to: > > Suppress-If-Match = ( "Suppress-If-Match:" entity-tag ) / "*" > Note the added parentheses. > > AFAIK, this is effectively a null-op; the canonical ABNF is equivalent > to the original. But sometimes the priority of ABNF operators escapes > me, hence I ask: Anybody disagree? I believe they are equivalent. > Now for a matter of style: Would it be better to have the draft use > the canonical form, since it relieves this poor reader's ambiguity? I think that the draft form is clearer in the context of the existing body of SIP specs, since that's the way all other header fields are specified. From pkyzivat@cisco.com Tue Apr 21 16:12:44 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C2D2228C33B for ; Tue, 21 Apr 2009 16:12:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.011 X-Spam-Level: X-Spam-Status: No, score=-6.011 tagged_above=-999 required=5 tests=[AWL=0.588, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sUqUoULMeth9 for ; Tue, 21 Apr 2009 16:12:43 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 59C4528C1D6 for ; Tue, 21 Apr 2009 16:12:43 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,226,1238976000"; d="scan'208";a="290415981" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by sj-iport-6.cisco.com with ESMTP; 21 Apr 2009 23:14:00 +0000 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n3LNDwXm015365; Tue, 21 Apr 2009 19:13:58 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n3LNDwim022841; Tue, 21 Apr 2009 23:13:58 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 21 Apr 2009 19:13:58 -0400 Received: from [161.44.174.156] ([161.44.174.156]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 21 Apr 2009 19:13:58 -0400 Message-ID: <49EE532D.9050602@cisco.com> Date: Tue, 21 Apr 2009 19:13:49 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Dean Willis References: <90F90B9D-2791-4B60-A5EF-F89114C9453E@softarmor.com> In-Reply-To: <90F90B9D-2791-4B60-A5EF-F89114C9453E@softarmor.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 21 Apr 2009 23:13:58.0214 (UTC) FILETIME=[D95A6660:01C9C2D6] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1377; t=1240355638; x=1241219638; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[sipcore]=20ABNF=20discussion=20on=20dr aft-ietf-subnot-etags |Sender:=20 |To:=20Dean=20Willis=20; bh=O+gwMmKjZqWzltRhB7ECvUoSxrG2WuLhNy4GS/5hurU=; b=d/0pMK8Jv7NVZHl95y+MeLsk6/jsTL5Vo7uzfdl0kAupvn1e1bbQRMPEcz tTUa5Y0KmUkJX7vwDrnHbYRZgFa3kNgJnrHqCKFGlbfxyln5CHuqgPT3W+Nx JO9zfLWjZZ; Authentication-Results: rtp-dkim-2; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Cc: sipcore@ietf.org Subject: Re: [sipcore] ABNF discussion on draft-ietf-subnot-etags X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Apr 2009 23:12:44 -0000 Dean Willis wrote: > > I'm looking at the proto writeup for subnot-etags, and doing the > required validation of the ABNF using BAP. I'm not Mr. Grammar (lately, > even simple English escapes me), so double-check me please. > > > The draft says: > > Suppress-If-Match = "Suppress-If-Match" ":" entity-tag / "*" > > > BAP canonicalizes this to: > > Suppress-If-Match = ( "Suppress-If-Match:" entity-tag ) / "*" > Note the added parentheses. > AFAIK, this is effectively a null-op; the canonical ABNF is equivalent > to the original. But sometimes the priority of ABNF operators escapes > me, hence I ask: Anybody disagree? I believe the cannonicalization is "correct" in that the two statements have the same meaning according to the rules of ABNF. BUT, I think this exposes an error in the original text. I'm pretty sure what was intended was: Suppress-If-Match = "Suppress-If-Match:" ( entity-tag / "*" ) Thanks, Paul > Now for a matter of style: Would it be better to have the draft use the > canonical form, since it relieves this poor reader's ambiguity? > > Side note: BAP is cool! > > See: http://tools.ietf.org/tools/bap/abnf.cgi > -- > Dean > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From hisham.khartabil@gmail.com Tue Apr 21 16:25:37 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AAB8B28C346 for ; Tue, 21 Apr 2009 16:25:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F63VNuO+1zbZ for ; Tue, 21 Apr 2009 16:25:36 -0700 (PDT) Received: from mail-gx0-f214.google.com (mail-gx0-f214.google.com [209.85.217.214]) by core3.amsl.com (Postfix) with ESMTP id 2E3C028C345 for ; Tue, 21 Apr 2009 16:25:36 -0700 (PDT) Received: by gxk10 with SMTP id 10so2257496gxk.13 for ; Tue, 21 Apr 2009 16:26:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=HkaVi1mcc6YrQ5wByR5atqd6OBTHG2Nw+q12x2mHuMU=; b=iNaFqVWzSwpAyjTfb+eTZqpceHmf5Hs6I+LW3gElMQa33VSNaggBmathM1lr5WKRDG eucjN6VCOmj5Jn3xA27LUqKCUl4WfgKTN6Xmew6TEK7oEU0eWXh0gQRME0Q56KD/3XO1 3dKC3UZRMz84oax/IW/rrwks5mAx9n8M7u4Ik= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=JEiNhHn22tG2QdOzlkORV9hLHUR3wknFI4BfDVDjtDO1Bl4SO3+kWZXcO5L2ZXTz1l MIZNyFEDR7K9RYlTbf/aI4bxtTx9XxLMpVZa8I5f6A4uzTDeplo5BpMFmIqBS8bht0iX PSUaGJc34B1tMBh3tmP60fnY8O42AGWZMCyrU= MIME-Version: 1.0 Received: by 10.151.48.20 with SMTP id a20mr9376513ybk.91.1240356412583; Tue, 21 Apr 2009 16:26:52 -0700 (PDT) In-Reply-To: <49EE532D.9050602@cisco.com> References: <90F90B9D-2791-4B60-A5EF-F89114C9453E@softarmor.com> <49EE532D.9050602@cisco.com> Date: Wed, 22 Apr 2009 09:26:52 +1000 Message-ID: <66cd252f0904211626t1cafdf20oe87af8a962428107@mail.gmail.com> From: Hisham Khartabil To: Paul Kyzivat Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: sipcore@ietf.org Subject: Re: [sipcore] ABNF discussion on draft-ietf-subnot-etags X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Apr 2009 23:25:37 -0000 Don't the brackets make whatever is inside them optioanl? 2009/4/22 Paul Kyzivat : > > > Dean Willis wrote: >> >> I'm looking at the proto writeup for subnot-etags, and doing the require= d >> validation of the ABNF using BAP. =A0I'm not Mr. Grammar (lately, even s= imple >> English escapes me), so double-check me please. >> >> >> The draft says: >> >> Suppress-If-Match =A0 =3D =A0"Suppress-If-Match" ":" entity-tag / "*" >> >> >> BAP canonicalizes this to: >> >> Suppress-If-Match =3D =A0( "Suppress-If-Match:" entity-tag ) / "*" >> Note the added parentheses. > >> AFAIK, this is effectively a null-op; the canonical ABNF is equivalent t= o >> the original. But sometimes the priority of ABNF operators escapes me, h= ence >> I ask: =A0Anybody disagree? > > I believe the cannonicalization is "correct" in that the two statements h= ave > the same meaning according to the rules of ABNF. > > BUT, I think this exposes an error in the original text. I'm pretty sure > what was intended was: > > Suppress-If-Match =3D =A0"Suppress-If-Match:" ( entity-tag / "*" ) > > =A0 =A0 =A0 =A0Thanks, > =A0 =A0 =A0 =A0Paul > >> Now for a matter of style: Would it be better to have the draft use the >> canonical form, since it relieves this poor reader's ambiguity? >> >> Side note: BAP is cool! >> >> See: http://tools.ietf.org/tools/bap/abnf.cgi >> -- >> Dean >> >> _______________________________________________ >> 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 tom.taylor@rogers.com Tue Apr 21 16:35:07 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 549193A7073 for ; Tue, 21 Apr 2009 16:35:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2Wku0Rzi2VUs for ; Tue, 21 Apr 2009 16:35:06 -0700 (PDT) Received: from smtp105.rog.mail.re2.yahoo.com (smtp105.rog.mail.re2.yahoo.com [206.190.36.83]) by core3.amsl.com (Postfix) with SMTP id 5E5273A7057 for ; Tue, 21 Apr 2009 16:35:06 -0700 (PDT) Received: (qmail 65924 invoked from network); 21 Apr 2009 23:36:22 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=rogers.com; h=Received:X-YMail-OSG:X-Yahoo-Newman-Property:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=zTFBNL3ri3y9/Z1MKs/g4inq3Ro042LMAl5qNIeNZgLDzqyTJjW5aJHWrwap7jOtbHxk9PTiGekb1vhQBPW/48Qu7n39n88B/4pi0sTtbpXQmWQTcKfLaGbmoL+NBJfBuEgcLlKtYTtdcUOQSs+dI8bOkL0f67007DZsOaBfHTQ= ; Received: from unknown (HELO ?192.192.20.87?) (tom.taylor@123.65.217.65 with plain) by smtp105.rog.mail.re2.yahoo.com with SMTP; 21 Apr 2009 23:36:22 -0000 X-YMail-OSG: lJhjPx8VM1kZdLFIJAstFjHp3WIe1OLRkjOmS2gamiuR5Fhf9mv4veTiLJRuwrghOA-- X-Yahoo-Newman-Property: ymail-3 Message-ID: <49EE5873.40203@rogers.com> Date: Tue, 21 Apr 2009 19:36:19 -0400 From: Tom Taylor User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Hisham Khartabil References: <90F90B9D-2791-4B60-A5EF-F89114C9453E@softarmor.com> <49EE532D.9050602@cisco.com> <66cd252f0904211626t1cafdf20oe87af8a962428107@mail.gmail.com> In-Reply-To: <66cd252f0904211626t1cafdf20oe87af8a962428107@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: sipcore@ietf.org Subject: Re: [sipcore] ABNF discussion on draft-ietf-subnot-etags X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Apr 2009 23:35:07 -0000 Round brackets just group. Square brackets show options. And I'd say Paul is right about the intent of the expression. A header field with no name, just an asterisk, as allowed by the current ABNF, won't parse in SIP. Hisham Khartabil wrote: > Don't the brackets make whatever is inside them optioanl? > > 2009/4/22 Paul Kyzivat : >> >> Dean Willis wrote: >>> I'm looking at the proto writeup for subnot-etags, and doing the required >>> validation of the ABNF using BAP. I'm not Mr. Grammar (lately, even simple >>> English escapes me), so double-check me please. >>> >>> >>> The draft says: >>> >>> Suppress-If-Match = "Suppress-If-Match" ":" entity-tag / "*" >>> >>> >>> BAP canonicalizes this to: >>> >>> Suppress-If-Match = ( "Suppress-If-Match:" entity-tag ) / "*" >>> Note the added parentheses. >>> AFAIK, this is effectively a null-op; the canonical ABNF is equivalent to >>> the original. But sometimes the priority of ABNF operators escapes me, hence >>> I ask: Anybody disagree? >> I believe the cannonicalization is "correct" in that the two statements have >> the same meaning according to the rules of ABNF. >> >> BUT, I think this exposes an error in the original text. I'm pretty sure >> what was intended was: >> >> Suppress-If-Match = "Suppress-If-Match:" ( entity-tag / "*" ) >> >> Thanks, >> Paul >> >>> Now for a matter of style: Would it be better to have the draft use the >>> canonical form, since it relieves this poor reader's ambiguity? >>> >>> Side note: BAP is cool! >>> >>> See: http://tools.ietf.org/tools/bap/abnf.cgi >>> -- >>> Dean >>> >>> _______________________________________________ >>> 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 dean.willis@softarmor.com Tue Apr 21 18:46:31 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 154643A6F1B for ; Tue, 21 Apr 2009 18:46:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.558 X-Spam-Level: X-Spam-Status: No, score=-2.558 tagged_above=-999 required=5 tests=[AWL=0.041, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 01hyI9W4Pmo4 for ; Tue, 21 Apr 2009 18:46:30 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 291CA3A69DB for ; Tue, 21 Apr 2009 18:46:27 -0700 (PDT) Received: from [192.168.2.102] (cpe-72-181-150-177.tx.res.rr.com [72.181.150.177]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id n3M1lVDr021109 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 21 Apr 2009 20:47:32 -0500 Message-Id: <203FB20D-BCD6-4D2C-A5A2-85D77A9B1594@softarmor.com> From: Dean Willis To: Paul Kyzivat In-Reply-To: <49EE532D.9050602@cisco.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Tue, 21 Apr 2009 20:47:25 -0500 References: <90F90B9D-2791-4B60-A5EF-F89114C9453E@softarmor.com> <49EE532D.9050602@cisco.com> X-Mailer: Apple Mail (2.930.3) Cc: sipcore@ietf.org Subject: Re: [sipcore] ABNF discussion on draft-ietf-subnot-etags X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Apr 2009 01:46:31 -0000 On Apr 21, 2009, at 6:13 PM, Paul Kyzivat wrote: > > > Dean Willis wrote: >> I'm looking at the proto writeup for subnot-etags, and doing the >> required validation of the ABNF using BAP. I'm not Mr. Grammar >> (lately, even simple English escapes me), so double-check me please. >> The draft says: >> Suppress-If-Match = "Suppress-If-Match" ":" entity-tag / "*" >> BAP canonicalizes this to: >> Suppress-If-Match = ( "Suppress-If-Match:" entity-tag ) / "*" >> Note the added parentheses. > >> AFAIK, this is effectively a null-op; the canonical ABNF is >> equivalent to the original. But sometimes the priority of ABNF >> operators escapes me, hence I ask: Anybody disagree? > > I believe the cannonicalization is "correct" in that the two > statements have the same meaning according to the rules of ABNF. > > BUT, I think this exposes an error in the original text. I'm pretty > sure what was intended was: > > Suppress-If-Match = "Suppress-If-Match:" ( entity-tag / "*" ) > Ok, from the canonical suggested by BAP, we could produce: Suppress-If-Match:a34e56 or we could produce * and as Tom points out, a * by itself is not much use. We WANT to be able to produce: Suppress-If-Match:a34e56 or Suppress-If-Match:* So I think the proposed grammar as written by Paul here is right, the canonicalization proposed by BAP is wrong, and the original grammar is misleading as it reading it requires a specific understanding of ABNF operator scoping that isn't shared by BAP. Maybe BAP's scoping rules are wrong, or maybe Scott's and mine are wrong, but we don't benefit from the ambiguity when a more definitive syntax is available. -- Dean From adam@nostrum.com Tue Apr 21 19:23:44 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BC0E93A7099 for ; Tue, 21 Apr 2009 19:23:44 -0700 (PDT) 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=[AWL=0.000, BAYES_00=-2.599, SPF_PASS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7XLkhefisYlN for ; Tue, 21 Apr 2009 19:23:44 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id AA81A3A6C06 for ; Tue, 21 Apr 2009 19:23:43 -0700 (PDT) Received: from hydra-3.local (ppp-70-242-118-153.dsl.rcsntx.swbell.net [70.242.118.153]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id n3M2OuF3000941 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 21 Apr 2009 21:24:56 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <49EE7FF8.4040501@nostrum.com> Date: Tue, 21 Apr 2009 21:24:56 -0500 From: Adam Roach User-Agent: Postbox 1.0b11 (Macintosh/2009041623) MIME-Version: 1.0 To: Hisham Khartabil References: <90F90B9D-2791-4B60-A5EF-F89114C9453E@softarmor.com> <49EE532D.9050602@cisco.com> <66cd252f0904211626t1cafdf20oe87af8a962428107@mail.gmail.com> In-Reply-To: <66cd252f0904211626t1cafdf20oe87af8a962428107@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 70.242.118.153 is authenticated by a trusted mechanism) Cc: sipcore@ietf.org Subject: Re: [sipcore] ABNF discussion on draft-ietf-subnot-etags X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Apr 2009 02:23:44 -0000 Hisham Khartabil wrote: > Don't the brackets make whatever is inside them optioanl? > You're thinking of the *(foo) construct we use a lot in SIP, which means "one or more of foo". Without the "*", the parentheses are just a grouping operator. /a From adam@nostrum.com Tue Apr 21 19:28:01 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4C6803A6BE4 for ; Tue, 21 Apr 2009 19:28:01 -0700 (PDT) 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=[AWL=0.000, BAYES_00=-2.599, SPF_PASS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gVSaS3gWd-Yg for ; Tue, 21 Apr 2009 19:28:00 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id B80263A6AE0 for ; Tue, 21 Apr 2009 19:27:56 -0700 (PDT) Received: from hydra-3.local (ppp-70-242-118-153.dsl.rcsntx.swbell.net [70.242.118.153]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id n3M2TAri001261 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 21 Apr 2009 21:29:11 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <49EE80F6.3080407@nostrum.com> Date: Tue, 21 Apr 2009 21:29:10 -0500 From: Adam Roach User-Agent: Postbox 1.0b11 (Macintosh/2009041623) MIME-Version: 1.0 To: Hisham Khartabil References: <90F90B9D-2791-4B60-A5EF-F89114C9453E@softarmor.com> <49EE532D.9050602@cisco.com> <66cd252f0904211626t1cafdf20oe87af8a962428107@mail.gmail.com> <49EE7FF8.4040501@nostrum.com> In-Reply-To: <49EE7FF8.4040501@nostrum.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 70.242.118.153 is authenticated by a trusted mechanism) Cc: sipcore@ietf.org Subject: Re: [sipcore] ABNF discussion on draft-ietf-subnot-etags X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Apr 2009 02:28:01 -0000 Adam Roach wrote: > Hisham Khartabil wrote: >> Don't the brackets make whatever is inside them optioanl? > > You're thinking of the *(foo) construct we use a lot in SIP, which > means "one or more of foo". Without the "*", the parentheses are just > a grouping operator. > Gack. I meant "zero or more of foo", not "one or more of foo". I clearly need to get to sleep now. /a From root@core3.amsl.com Tue Apr 21 23:15:01 2009 Return-Path: X-Original-To: sipcore@ietf.org Delivered-To: sipcore@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 6A71E3A6B34; Tue, 21 Apr 2009 23:15:00 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090422061501.6A71E3A6B34@core3.amsl.com> Date: Tue, 21 Apr 2009 23:15:01 -0700 (PDT) Cc: sipcore@ietf.org Subject: [sipcore] I-D Action:draft-ietf-sipcore-subnot-etags-01.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Apr 2009 06:15:01 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session Initiation Protocol Core Working Group of the IETF. Title : An Extension to Session Initiation Protocol (SIP) Events for Conditional Event Notification Author(s) : A. Niemi Filename : draft-ietf-sipcore-subnot-etags-01.txt Pages : 25 Date : 2009-04-21 The Session Initiation Protocol (SIP) events framework enables receiving asynchronous notification of various events from other SIP user agents. This framework defines the procedures for creating, refreshing and terminating subscriptions, as well as fetching and periodic polling of resource state. These procedures provide no tools to avoid replaying event notifications that have already been received by a user agent. This memo defines an extension to SIP events that allows the subscriber to condition the subscription request to whether the state has changed since the previous notification was received. When such a condition is true, either the body of a resulting event notification or the entire notification message is suppressed. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sipcore-subnot-etags-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-sipcore-subnot-etags-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-04-21231312.I-D@ietf.org> --NextPart-- From pkyzivat@cisco.com Wed Apr 22 06:00:37 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8200A28C423 for ; Wed, 22 Apr 2009 06:00:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.024 X-Spam-Level: X-Spam-Status: No, score=-6.024 tagged_above=-999 required=5 tests=[AWL=0.575, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2YtvCgi74i-J for ; Wed, 22 Apr 2009 06:00:36 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 5E7F528C3EE for ; Wed, 22 Apr 2009 06:00:36 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,230,1238976000"; d="scan'208";a="42400465" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 22 Apr 2009 13:01:51 +0000 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n3MD1pS5022602; Wed, 22 Apr 2009 09:01:51 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n3MD1pVQ014199; Wed, 22 Apr 2009 13:01:51 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 22 Apr 2009 09:01:51 -0400 Received: from [161.44.174.156] ([161.44.174.156]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Wed, 22 Apr 2009 09:01:50 -0400 Message-ID: <49EF153A.8040400@cisco.com> Date: Wed, 22 Apr 2009 09:01:46 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Dean Willis References: <90F90B9D-2791-4B60-A5EF-F89114C9453E@softarmor.com> <49EE532D.9050602@cisco.com> <203FB20D-BCD6-4D2C-A5A2-85D77A9B1594@softarmor.com> In-Reply-To: <203FB20D-BCD6-4D2C-A5A2-85D77A9B1594@softarmor.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 22 Apr 2009 13:01:50.0877 (UTC) FILETIME=[809144D0:01C9C34A] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2624; t=1240405311; x=1241269311; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[sipcore]=20ABNF=20discussion=20on=20dr aft-ietf-subnot-etags |Sender:=20 |To:=20Dean=20Willis=20; bh=jV3IKKLhpsiFRS8evMRunu6otwNNDWEKB1OQLj6iyHY=; b=CbdKFKLMX/7KvodItDmPzvuZgrvXScnwi25N7kN+d+82M6zJl1Oi9OJbnl u5MhXnKuddATpYmRqrcSDq5yQSwNtm+7hgquQUc9COixnHFVUm5emtjT/6bB YPff/qEA4A; Authentication-Results: rtp-dkim-1; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Cc: sipcore@ietf.org Subject: Re: [sipcore] ABNF discussion on draft-ietf-subnot-etags X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Apr 2009 13:00:37 -0000 I just took another look, because this ABNF still looked a bit odd. To be consistent with the way other headers are defined in 3261, it ought to be specified as: Suppress-If-Match = "Suppress-If-Match" HCOLON ( entity-tag / "*" ) The difference being the treatment of whitespace. While some think the allowance of whitespace in 3261 is more liberal than necessary, IMO its unwise to alter this piecemeal. Consistency across headers is important, so that generalized parsers can be constructed. If you don't make this change, then Suppress-If_Match:* will be parsed as a suppress-if-match header, while Suppress-If_Match :* Suppress-If_Match: * Suppress-If_Match : * Will all also be "valid" but parsed as 'extention-header'. Thanks, Paul Dean Willis wrote: > > On Apr 21, 2009, at 6:13 PM, Paul Kyzivat wrote: > >> >> >> Dean Willis wrote: >>> I'm looking at the proto writeup for subnot-etags, and doing the >>> required validation of the ABNF using BAP. I'm not Mr. Grammar >>> (lately, even simple English escapes me), so double-check me please. >>> The draft says: >>> Suppress-If-Match = "Suppress-If-Match" ":" entity-tag / "*" >>> BAP canonicalizes this to: >>> Suppress-If-Match = ( "Suppress-If-Match:" entity-tag ) / "*" >>> Note the added parentheses. >> >>> AFAIK, this is effectively a null-op; the canonical ABNF is >>> equivalent to the original. But sometimes the priority of ABNF >>> operators escapes me, hence I ask: Anybody disagree? >> >> I believe the cannonicalization is "correct" in that the two >> statements have the same meaning according to the rules of ABNF. >> >> BUT, I think this exposes an error in the original text. I'm pretty >> sure what was intended was: >> >> Suppress-If-Match = "Suppress-If-Match:" ( entity-tag / "*" ) >> > > Ok, from the canonical suggested by BAP, we could produce: > > Suppress-If-Match:a34e56 > > or we could produce > > * > > and as Tom points out, a * by itself is not much use. > > We WANT to be able to produce: > > Suppress-If-Match:a34e56 > > or > > Suppress-If-Match:* > > > So I think the proposed grammar as written by Paul here is right, the > canonicalization proposed by BAP is wrong, and the original grammar is > misleading as it reading it requires a specific understanding of ABNF > operator scoping that isn't shared by BAP. Maybe BAP's scoping rules are > wrong, or maybe Scott's and mine are wrong, but we don't benefit from > the ambiguity when a more definitive syntax is available. > > -- > Dean > From adam@nostrum.com Wed Apr 22 07:41:55 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E72603A6F29 for ; Wed, 22 Apr 2009 07:41:55 -0700 (PDT) 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=[AWL=0.000, BAYES_00=-2.599, SPF_PASS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7Fa7PoyAGx4J for ; Wed, 22 Apr 2009 07:41:54 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id 6E40F3A6D80 for ; Wed, 22 Apr 2009 07:41:54 -0700 (PDT) Received: from hydra-3.local (ppp-70-242-118-153.dsl.rcsntx.swbell.net [70.242.118.153]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id n3MEh8B2060083 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 22 Apr 2009 09:43:08 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <49EF2CFC.7050401@nostrum.com> Date: Wed, 22 Apr 2009 09:43:08 -0500 From: Adam Roach User-Agent: Postbox 1.0b11 (Macintosh/2009041623) MIME-Version: 1.0 To: Paul Kyzivat References: <90F90B9D-2791-4B60-A5EF-F89114C9453E@softarmor.com> <49EE532D.9050602@cisco.com> <203FB20D-BCD6-4D2C-A5A2-85D77A9B1594@softarmor.com> <49EF153A.8040400@cisco.com> In-Reply-To: <49EF153A.8040400@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 70.242.118.153 is authenticated by a trusted mechanism) Cc: sipcore@ietf.org Subject: Re: [sipcore] ABNF discussion on draft-ietf-subnot-etags X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Apr 2009 14:41:56 -0000 I agree with Paul. /a Paul Kyzivat wrote: > I just took another look, because this ABNF still looked a bit odd. > > To be consistent with the way other headers are defined in 3261, it > ought to be specified as: > > Suppress-If-Match = "Suppress-If-Match" HCOLON ( entity-tag / "*" ) > > The difference being the treatment of whitespace. > > While some think the allowance of whitespace in 3261 is more liberal > than necessary, IMO its unwise to alter this piecemeal. Consistency > across headers is important, so that generalized parsers can be > constructed. If you don't make this change, then > > Suppress-If_Match:* > > will be parsed as a suppress-if-match header, while > > Suppress-If_Match :* > Suppress-If_Match: * > Suppress-If_Match : * > > Will all also be "valid" but parsed as 'extention-header'. > > Thanks, > Paul > > Dean Willis wrote: >> On Apr 21, 2009, at 6:13 PM, Paul Kyzivat wrote: >> >>> Dean Willis wrote: >>>> I'm looking at the proto writeup for subnot-etags, and doing the >>>> required validation of the ABNF using BAP. I'm not Mr. Grammar >>>> (lately, even simple English escapes me), so double-check me please. >>>> The draft says: >>>> Suppress-If-Match = "Suppress-If-Match" ":" entity-tag / "*" >>>> BAP canonicalizes this to: >>>> Suppress-If-Match = ( "Suppress-If-Match:" entity-tag ) / "*" >>>> Note the added parentheses. >>> >>>> AFAIK, this is effectively a null-op; the canonical ABNF is >>>> equivalent to the original. But sometimes the priority of ABNF >>>> operators escapes me, hence I ask: Anybody disagree? >>> >>> I believe the cannonicalization is "correct" in that the two >>> statements have the same meaning according to the rules of ABNF. >>> >>> BUT, I think this exposes an error in the original text. I'm pretty >>> sure what was intended was: >>> >>> Suppress-If-Match = "Suppress-If-Match:" ( entity-tag / "*" ) >> >> Ok, from the canonical suggested by BAP, we could produce: >> >> Suppress-If-Match:a34e56 >> >> or we could produce >> >> * >> >> and as Tom points out, a * by itself is not much use. >> >> We WANT to be able to produce: >> >> Suppress-If-Match:a34e56 >> >> or >> >> Suppress-If-Match:* >> >> >> So I think the proposed grammar as written by Paul here is right, the >> canonicalization proposed by BAP is wrong, and the original grammar >> is misleading as it reading it requires a specific understanding of >> ABNF operator scoping that isn't shared by BAP. Maybe BAP's scoping >> rules are wrong, or maybe Scott's and mine are wrong, but we don't >> benefit from the ambiguity when a more definitive syntax is available. >> >> -- >> Dean > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From adam@nostrum.com Wed Apr 22 09:12:36 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A131428C59C for ; Wed, 22 Apr 2009 09:12:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.576 X-Spam-Level: X-Spam-Status: No, score=-2.576 tagged_above=-999 required=5 tests=[AWL=0.024, BAYES_00=-2.599, SPF_PASS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qqBB1BQIZCCc for ; Wed, 22 Apr 2009 09:12:35 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id 6A9E328C1C1 for ; Wed, 22 Apr 2009 09:12:35 -0700 (PDT) Received: from [172.16.3.231] (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id n3MGDnh9066874 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Wed, 22 Apr 2009 11:13:50 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <49EF423D.3080700@nostrum.com> Date: Wed, 22 Apr 2009 11:13:49 -0500 From: Adam Roach User-Agent: Postbox 1.0b11 (Macintosh/2009041623) MIME-Version: 1.0 To: SIPCORE Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Subject: [sipcore] Forking and draft-ietf-sipcore-subnot-etags X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Apr 2009 16:12:36 -0000 [as an individual participant] You've probably noticed a new version of the subnot-etags document just came out. This version incorporates some changes to resolve a last-minute technical issue with the way this document interacts with request forking. (There's also an ABNF change, but there's a separate thread going on that topic). In previous versions of the document, the language allowed complete suppression of NOTIFY messages except when there were "reportable changes in the NOTIFY header". This criteria was somewhat ambiguous in the general case of establishing a new subscription (the transition of subscription state to "active" technically qualifies as a "reportable change in the NOTIFY header", but implementors were left to figure this out independently). To complicate matters, there were at least two passages in the document that strongly suggested that there may be circumstances in which the first NOTIFY in a subscription would be completely suppressed, which causes some serious issues with forking. The complete suppression of NOTIFY messages was also explicit for resource state polling, which gives rise to similar issues. The issue with suppressing the first NOTIFY message in a dialog is that a forked SUBSCRIBE message can land on several notifiers, each of whom may well accept the subscription. However, due to SIP forking processing, only one final response to the SUBSCRIBE will arrive at the subscriber. Under the 3265 model, this is resolved by the use of an immediate NOTIFY in the reverse direction -- the subscriber learns about all the resulting subscriptions because it receives a NOTIFY message for each one. Removing this aspect of subscription establishment basically re-creates a variant of the HERFP problem, except much worse: instead of failing to learn about various request failures, the subscriber fails to learn about various successful dialog establishments. The most recent version of the document addresses this by: 1. Cleaning up the passages that implied suppression of the initial NOTIFY message in a dialog 2. Making explicit the previously implicit behavior of not suppressing initial NOTIFY message in a dialog 3. Changing poll behavior to require empty NOTIFY messages instead of completely suppressed NOTIFY messages Only the third change is an actual change in behavior. The first two are simply making previously implied behavior explicit. I realize that this is a bit of deep RFC 3265 arcana, but please weigh in on the changes so we can move the document over the finish line soon. Thanks! /a From dean.willis@softarmor.com Wed Apr 22 12:09:04 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6FD403A6BC7 for ; Wed, 22 Apr 2009 12:09:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.558 X-Spam-Level: X-Spam-Status: No, score=-2.558 tagged_above=-999 required=5 tests=[AWL=0.041, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6d7uuktwaYlQ for ; Wed, 22 Apr 2009 12:09:03 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 9BD2D3A6B57 for ; Wed, 22 Apr 2009 12:09:03 -0700 (PDT) Received: from [192.168.2.102] (cpe-72-181-150-177.tx.res.rr.com [72.181.150.177]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id n3MJAIuV029054 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 22 Apr 2009 14:10:19 -0500 Message-Id: From: Dean Willis To: Paul Kyzivat In-Reply-To: <49EF153A.8040400@cisco.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Wed, 22 Apr 2009 14:10:12 -0500 References: <90F90B9D-2791-4B60-A5EF-F89114C9453E@softarmor.com> <49EE532D.9050602@cisco.com> <203FB20D-BCD6-4D2C-A5A2-85D77A9B1594@softarmor.com> <49EF153A.8040400@cisco.com> X-Mailer: Apple Mail (2.930.3) Cc: sipcore@ietf.org Subject: Re: [sipcore] ABNF discussion on draft-ietf-subnot-etags X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Apr 2009 19:09:04 -0000 On Apr 22, 2009, at 8:01 AM, Paul Kyzivat wrote: > I just took another look, because this ABNF still looked a bit odd. > > To be consistent with the way other headers are defined in 3261, it > ought to be specified as: > > Suppress-If-Match = "Suppress-If-Match" HCOLON ( entity-tag / "*" ) > > The difference being the treatment of whitespace. > > While some think the allowance of whitespace in 3261 is more liberal > than necessary, IMO its unwise to alter this piecemeal. Consistency > across headers is important, so that generalized parsers can be > constructed. If you don't make this change, then > > Suppress-If_Match:* > > will be parsed as a suppress-if-match header, while > > Suppress-If_Match :* > Suppress-If_Match: * > Suppress-If_Match : * > > Will all also be "valid" but parsed as 'extention-header'. > Huh. According to the (evidently flawed) SIP parser in my head, "Suppress-If-Match :*" is broken. But that goes to the excessively liberal treatment of whitespace in RFC 3261. I'll add HCOLON in -02. -- Dean From root@core3.amsl.com Wed Apr 22 14:15:01 2009 Return-Path: X-Original-To: sipcore@ietf.org Delivered-To: sipcore@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 4CA0428C673; Wed, 22 Apr 2009 14:15:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090422211501.4CA0428C673@core3.amsl.com> Date: Wed, 22 Apr 2009 14:15:01 -0700 (PDT) Cc: sipcore@ietf.org Subject: [sipcore] I-D Action:draft-ietf-sipcore-subnot-etags-02.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Apr 2009 21:15:01 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session Initiation Protocol Core Working Group of the IETF. Title : An Extension to Session Initiation Protocol (SIP) Events for Conditional Event Notification Author(s) : A. Niemi Filename : draft-ietf-sipcore-subnot-etags-02.txt Pages : 25 Date : 2009-04-22 The Session Initiation Protocol (SIP) events framework enables receiving asynchronous notification of various events from other SIP user agents. This framework defines the procedures for creating, refreshing and terminating subscriptions, as well as fetching and periodic polling of resource state. These procedures provide no tools to avoid replaying event notifications that have already been received by a user agent. This memo defines an extension to SIP events that allows the subscriber to condition the subscription request to whether the state has changed since the previous notification was received. When such a condition is true, either the body of a resulting event notification or the entire notification message is suppressed. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sipcore-subnot-etags-02.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-sipcore-subnot-etags-02.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-04-22140304.I-D@ietf.org> --NextPart-- From dean.willis@softarmor.com Wed Apr 22 16:53:46 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 62DD728C518 for ; Wed, 22 Apr 2009 16:53:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.32 X-Spam-Level: X-Spam-Status: No, score=-2.32 tagged_above=-999 required=5 tests=[AWL=-0.199, BAYES_00=-2.599, WHOIS_DMNBYPROXY=0.478] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v0F6ObKWwRec for ; Wed, 22 Apr 2009 16:53:38 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 49E093A71AC for ; Wed, 22 Apr 2009 16:51:53 -0700 (PDT) Received: from [192.168.2.102] (cpe-72-181-150-177.tx.res.rr.com [72.181.150.177]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id n3MNqqfp031020 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 22 Apr 2009 18:53:05 -0500 Message-Id: From: Dean Willis To: sipcore@ietf.org In-Reply-To: <20090422211501.4CA0428C673@core3.amsl.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Wed, 22 Apr 2009 18:52:45 -0500 References: <20090422211501.4CA0428C673@core3.amsl.com> X-Mailer: Apple Mail (2.930.3) Cc: Aki Niemi Subject: Re: [sipcore] I-D Action:draft-ietf-sipcore-subnot-etags-02.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Apr 2009 23:53:46 -0000 Ok, this version has Paul's latest ABNF fix, as well as all the other changes we have discussed. You can see a side-by-side rfcdiff between this and -00 (-01 is now redundant) at: http://snurl.com/ghlt8 Please pay special attention to the non-trivial changes related to initial notification. -- Dean From eburger@standardstrack.com Thu Apr 23 08:14:30 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 74D4528C31F for ; Thu, 23 Apr 2009 08:14:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.297 X-Spam-Level: X-Spam-Status: No, score=-2.297 tagged_above=-999 required=5 tests=[AWL=0.302, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L9HZquqWc0zw for ; Thu, 23 Apr 2009 08:14:29 -0700 (PDT) Received: from gs19.inmotionhosting.com (gs19.inmotionhosting.com [205.134.252.251]) by core3.amsl.com (Postfix) with ESMTP id 960E128C298 for ; Thu, 23 Apr 2009 08:14:29 -0700 (PDT) Received: from c-75-68-112-157.hsd1.nh.comcast.net ([75.68.112.157] helo=[192.168.45.103]) by gs19.inmotionhosting.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1Lx0eK-0008MP-Rv for sipcore@ietf.org; Thu, 23 Apr 2009 08:15:41 -0700 Message-Id: <6F22117A-3D14-4170-8E8D-83EB57B0B795@standardstrack.com> From: Eric Burger To: SIPCORE Content-Type: multipart/signed; boundary=Apple-Mail-69-199537933; micalg=sha1; protocol="application/pkcs7-signature" Mime-Version: 1.0 (Apple Message framework v930.3) Date: Thu, 23 Apr 2009 11:15:42 -0400 X-Mailer: Apple Mail (2.930.3) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gs19.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - standardstrack.com X-Source: X-Source-Args: X-Source-Dir: Subject: [sipcore] What is Coming in INFO X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Apr 2009 15:14:30 -0000 --Apple-Mail-69-199537933 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Nits: changed most (but not all) "dialogs" to "sessions". We never talked about REFER, so we will not start now Big thing: There is enough stuff out there on 489 that I now, too, agree that reusing 489 would be confusing. Please +1 or whine now on the new text. Thanks. Here is the proposed new text: Section 4.3 Responses to the INFO Request Method If the INFO request indicates an Info Package type the server does not understand, then the server MUST respond with a 469 Bad INFO Package. In the terminology of Multiple Dialog Usages [RFC5057], this represents a Transaction Only failure. If a server receives an INFO request with a body it understands, but it has no Info-Package header, the UAS MAY use the body as it sees fit. If the UAS accepts the INFO request, the UAS MUST respond to the INFO request with a 200 OK. This enables legacy use of INFO. If the UAS needs to enforce strict compliance with the current INFO framework described here, the UAS MUST reject the request with a 469. Section 9.6 Registration Please register the 469 response code in the Session Initiation Protocol Parameters - Response Codes registry as follows. Response Code: 469 Default Reason Phrase: Bad INFO Package Reference: &rfcxxxx; --Apple-Mail-69-199537933 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGPTCCBjkw ggUhoAMCAQICEC+VK1RLWxrF8KJZDR9k8p8wDQYJKoZIhvcNAQEFBQAwga4xCzAJBgNVBAYTAlVT MQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VS VFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQD Ey1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwwHhcNMDgwODEz MDAwMDAwWhcNMDkwODEzMjM1OTU5WjCB4TE1MDMGA1UECxMsQ29tb2RvIFRydXN0IE5ldHdvcmsg LSBQRVJTT05BIE5PVCBWQUxJREFURUQxRjBEBgNVBAsTPVRlcm1zIGFuZCBDb25kaXRpb25zIG9m IHVzZTogaHR0cDovL3d3dy5jb21vZG8ubmV0L3JlcG9zaXRvcnkxHzAdBgNVBAsTFihjKTIwMDMg Q29tb2RvIExpbWl0ZWQxFDASBgNVBAMTC0VyaWMgQnVyZ2VyMSkwJwYJKoZIhvcNAQkBFhplYnVy Z2VyQHN0YW5kYXJkc3RyYWNrLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMTF RRoA4LgOACMFph0aomRC/UpqoA5C/d6DUTOvTMrYSEqkjwnU4zxDtBcHlcB4AxKAov00MYsUvEU4 loz7BHjfDjv76AIkcwu33VYQbzGmarVnyaXsVb6f/cyRL3fPT0VOVO2tQAEEgwg//CX0jN8Kn2jH uXD/HEvko7cmpL3Pwevf3+DwB61v7ca79PpEZfn/WhaqRKA4uVNPj/JbieeaLo2v/0RJzrEElZK0 pHCqxiD3mQ8ossPkA9fUCSxLlbdMcPU3be5x8vt8Q8mYTXF5Z3d9RZmYrmNkvTQtdzVpfYWr/hgV Xqm9tByOOAR+hoN3FKbubR/OrAHL9yDAd4sCAwEAAaOCAhwwggIYMB8GA1UdIwQYMBaAFImCZ33E nSZwAEu0UEh83j2uBG59MB0GA1UdDgQWBBRDWgutb7b8R/L7G3Y3D+molAA3VzAOBgNVHQ8BAf8E BAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJ YIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQECAQEBMCswKQYIKwYBBQUHAgEW HWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BTMIGlBgNVHR8EgZ0wgZowTKBKoEiGRmh0dHA6 Ly9jcmwuY29tb2RvY2EuY29tL1VUTi1VU0VSRmlyc3QtQ2xpZW50QXV0aGVudGljYXRpb25hbmRF bWFpbC5jcmwwSqBIoEaGRGh0dHA6Ly9jcmwuY29tb2RvLm5ldC9VVE4tVVNFUkZpcnN0LUNsaWVu dEF1dGhlbnRpY2F0aW9uYW5kRW1haWwuY3JsMGwGCCsGAQUFBwEBBGAwXjA2BggrBgEFBQcwAoYq aHR0cDovL2NydC5jb21vZG9jYS5jb20vVVROQUFBQ2xpZW50Q0EuY3J0MCQGCCsGAQUFBzABhhho dHRwOi8vb2NzcC5jb21vZG9jYS5jb20wJQYDVR0RBB4wHIEaZWJ1cmdlckBzdGFuZGFyZHN0cmFj ay5jb20wDQYJKoZIhvcNAQEFBQADggEBAGeBR7NPCvrY3GQoIi49JOuciatY2r4st905Jw1etp6J umFFWlaCBl11tFSclk/3S45B+lUv3SEvG4CEjUByPScprVmCqHR+y8BAQaB/CV+N1y14x3MbhJ+Z 8XDGKeUXuuyGd9w0l3/t/QPid6TRXQjQFrLPFs1IALuNpNiFMHEF/xFbMG1Z2vznR/gSPlePekoZ TqcExIDBNZTBebpZqwAXzPpedNNOclbMLFLWDMOAozVRpkfjI0eiFsk8SF1Ho1Gb9Bx8DeG4peE2 KRVOR9FFnZZgBpFjXYRcglsMOSKCY8HgE+NGvbbqbrMoBV/BlYyxRXwfti71RL9Zs2Cq1eQxggP8 MIID+AIBATCBwzCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0IExh a2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRwOi8v d3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhlbnRp Y2F0aW9uIGFuZCBFbWFpbAIQL5UrVEtbGsXwolkNH2TynzAJBgUrDgMCGgUAoIICDTAYBgkqhkiG 9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wOTA0MjMxNTE1NDNaMCMGCSqGSIb3 DQEJBDEWBBQBpMN2Inm9ha0nKMwP2ovNTPRytTCB1AYJKwYBBAGCNxAEMYHGMIHDMIGuMQswCQYD VQQGEwJVUzELMAkGA1UECBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVU aGUgVVNFUlRSVVNUIE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2 MDQGA1UEAxMtVVROLVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsAhAv lStUS1saxfCiWQ0fZPKfMIHWBgsqhkiG9w0BCRACCzGBxqCBwzCBrjELMAkGA1UEBhMCVVMxCzAJ BgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVT VCBOZXR3b3JrMSEwHwYDVQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVU Ti1VU0VSRmlyc3QtQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbAIQL5UrVEtbGsXwolkN H2TynzANBgkqhkiG9w0BAQEFAASCAQAodyKl2h5rTsPRsJzxsbvh8qaAQUf48sWAiM5iV6TmKP9C T0g4d8Olq3NpED2S2KpUTacNI7oiLTVUxFnX77Pcej9cGZRXlzJEBmbJ+868taemoBPWFZsYLrhP 7vuu/RUBuiuzGBNRwCANAEd6kemZ8dsh5sPQZY9jMpgjv9TwVTx9kd5+UWpLxXCAmYN7YdNHxTfZ WvP/zvzpIyPtIYYfWEACbQ0LhyGoqbo5L0nuqEYkQHbXlsGkzqxDS85uF67norT/SZpcd57ktf4z UDvl3ngYJ/MwZEg5zWNHoTjK8T14+keIRuJLH8+5noJK9RRGM6HKXj6XCS91Nb4EJHmNAAAAAAAA --Apple-Mail-69-199537933-- From gonzalo.camarillo@ericsson.com Fri Apr 24 01:32:47 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1A64B3A6A35 for ; Fri, 24 Apr 2009 01:32:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.391 X-Spam-Level: X-Spam-Status: No, score=-4.391 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_20=-0.74, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DQ4Fnb38sXGi for ; Fri, 24 Apr 2009 01:32:46 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 36E803A6931 for ; Fri, 24 Apr 2009 01:30:45 -0700 (PDT) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id BA5CB21199; Fri, 24 Apr 2009 10:32:01 +0200 (CEST) X-AuditID: c1b4fb3e-a5981bb000007c2c-1b-49f179015b62 Received: from esealmw128.eemea.ericsson.se (unknown [153.88.253.124]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 7A6EF2064C; Fri, 24 Apr 2009 10:32:01 +0200 (CEST) Received: from esealmw128.eemea.ericsson.se ([153.88.254.176]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 24 Apr 2009 10:31:10 +0200 Received: from [131.160.126.177] ([131.160.126.177]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 24 Apr 2009 10:31:10 +0200 Message-ID: <49F178CE.8000809@ericsson.com> Date: Fri, 24 Apr 2009 11:31:10 +0300 From: Gonzalo Camarillo User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: SIPCORE Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 24 Apr 2009 08:31:10.0500 (UTC) FILETIME=[055FE640:01C9C4B7] X-Brightmail-Tracker: AAAAAA== Subject: [sipcore] Target URI and History Info bis X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Apr 2009 08:32:47 -0000 Hi, discussions about the target URI and history info bis work has focused too much on the historical background and not enough on the best way to proceed with this work. I would like to have discussions on what we think would be the best and fastest way to specify what needs to be specified. Mary claims that having the following draft tackle both the target URI issue and the revision of History Info would be the fastest and cleanest way to be done with everything we want to specify. http://tools.ietf.org/html/draft-barnes-sip-rfc4244bis-00 Others claim that tackling the target URI issue in an independent draft that does not depend on the revision of History info would be the fastest way to proceed with the target URI issue. http://tools.ietf.org/html/draft-rosenberg-sip-target-uri-delivery-01 I would like to hear opinions on how we should proceed and why. I would prefer to get reasons related to clearness of the specifications, speed of the process, etc., instead of about the historical background on these two drafts. Thanks, Gonzalo From gonzalo.camarillo@ericsson.com Fri Apr 24 01:45:27 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9EC893A6879 for ; Fri, 24 Apr 2009 01:45:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.171 X-Spam-Level: X-Spam-Status: No, score=-4.171 tagged_above=-999 required=5 tests=[AWL=-0.222, BAYES_00=-2.599, HELO_EQ_SE=0.35, MANGLED_TOOL=2.3, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id t3ja7MaMPMSo for ; Fri, 24 Apr 2009 01:45:26 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id C65D03A67A3 for ; Fri, 24 Apr 2009 01:45:26 -0700 (PDT) Received: from mailgw4.ericsson.se (unknown [127.0.0.1]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id 41397214DD; Fri, 24 Apr 2009 10:44:58 +0200 (CEST) X-AuditID: c1b4fb3e-a9188bb000007c2c-74-49f17c09150e Received: from esealmw129.eemea.ericsson.se (unknown [153.88.253.124]) by mailgw4.ericsson.se (Symantec Mail Security) with ESMTP id AAB0F214DB; Fri, 24 Apr 2009 10:44:57 +0200 (CEST) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 24 Apr 2009 10:44:57 +0200 Received: from [131.160.126.177] ([131.160.126.177]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Fri, 24 Apr 2009 10:44:57 +0200 Message-ID: <49F17C09.8060107@ericsson.com> Date: Fri, 24 Apr 2009 11:44:57 +0300 From: Gonzalo Camarillo User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: draft-rosenberg-sip-target-uri-delivery@tools.ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 24 Apr 2009 08:44:57.0433 (UTC) FILETIME=[F243DC90:01C9C4B8] X-Brightmail-Tracker: AAAAAA== Cc: SIPCORE Subject: [sipcore] Target URI draft from 00 to 01 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Apr 2009 08:45:27 -0000 Authors of the target URI draft, the SIP WG agreed to take the 00 version of the draft below as a WG item. http://tools.ietf.org/html/draft-rosenberg-sip-target-uri-delivery-01 From that moment on, change control should have been in the hands of the SIP WG, which includes the contents of the draft and its editor(s). The SIP chairs have expressed concerns in the way the draft evolved from 00 to 01 (see an email from Keith on this list on this topic). http://tools.ietf.org/rfcdiff?difftype=--hwdiff&url2=http://tools.ietf.org/id/draft-rosenberg-sip-target-uri-delivery-01.txt Therefore, we would like to ask the authors of this draft to summarize and explain the changes from 00 to 01. Note that I sent a different note to the list about how to proceed with the specification work we need to do. This note is just a request for clarification so that we all understand what are the contents of this version of the draft. Thanks, Gonzalo From john.elwell@siemens-enterprise.com Fri Apr 24 02:35:03 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0AEC13A6C89 for ; Fri, 24 Apr 2009 02:35:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.465 X-Spam-Level: X-Spam-Status: No, score=-2.465 tagged_above=-999 required=5 tests=[AWL=0.134, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NhEwxoS66tqe for ; Fri, 24 Apr 2009 02:35:02 -0700 (PDT) Received: from mailgate.siemenscomms.co.uk (mailgate.siemenscomms.co.uk [195.171.110.225]) by core3.amsl.com (Postfix) with ESMTP id 153573A69DE for ; Fri, 24 Apr 2009 02:35:02 -0700 (PDT) Received: from GBNTHT12009MSX.gb002.siemens.net ([137.223.219.235]) by siemenscomms.co.uk (PMDF V6.3-x14 #31430) with ESMTP id <0KIL001DZMOIQ7@siemenscomms.co.uk> for sipcore@ietf.org; Fri, 24 Apr 2009 10:36:19 +0100 (BST) Date: Fri, 24 Apr 2009 10:36:16 +0100 From: "Elwell, John" In-reply-to: <49F178CE.8000809@ericsson.com> To: Gonzalo Camarillo , SIPCORE Message-id: <0D5F89FAC29E2C41B98A6A762007F5D001CF8141@GBNTHT12009MSX.gb002.siemens.net> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: quoted-printable Thread-Topic: [sipcore] Target URI and History Info bis thread-index: AcnEt3tlieW8J+vHQQ+TDHiRIeQm+AACFNpA Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <49F178CE.8000809@ericsson.com> Subject: Re: [sipcore] Target URI and History Info bis X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Apr 2009 09:35:03 -0000 I would prefer to move forward with a single draft covering all the enhancements necessary to History-Info. John > -----Original Message----- > From: sipcore-bounces@ietf.org=20 > [mailto:sipcore-bounces@ietf.org] On Behalf Of Gonzalo Camarillo > Sent: 24 April 2009 09:31 > To: SIPCORE > Subject: [sipcore] Target URI and History Info bis >=20 > Hi, >=20 > discussions about the target URI and history info bis work=20 > has focused=20 > too much on the historical background and not enough on the=20 > best way to=20 > proceed with this work. I would like to have discussions on what we=20 > think would be the best and fastest way to specify what needs to be=20 > specified. >=20 > Mary claims that having the following draft tackle both the=20 > target URI=20 > issue and the revision of History Info would be the fastest=20 > and cleanest=20 > way to be done with everything we want to specify. >=20 > http://tools.ietf.org/html/draft-barnes-sip-rfc4244bis-00 >=20 > Others claim that tackling the target URI issue in an=20 > independent draft=20 > that does not depend on the revision of History info would be the=20 > fastest way to proceed with the target URI issue. >=20 > http://tools.ietf.org/html/draft-rosenberg-sip-target-uri-delivery-01 >=20 > I would like to hear opinions on how we should proceed and=20 > why. I would=20 > prefer to get reasons related to clearness of the=20 > specifications, speed=20 > of the process, etc., instead of about the historical background on=20 > these two drafts. >=20 > Thanks, >=20 > Gonzalo >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore >=20 From shida@ntt-at.com Fri Apr 24 02:44:04 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 201BC3A68BB for ; Fri, 24 Apr 2009 02:44:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.115 X-Spam-Level: X-Spam-Status: No, score=-1.115 tagged_above=-999 required=5 tests=[AWL=-1.150, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, MANGLED_TOOL=2.3] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EDKCPeAX51sn for ; Fri, 24 Apr 2009 02:44:03 -0700 (PDT) Received: from gateway04.websitewelcome.com (gateway04.websitewelcome.com [69.56.148.5]) by core3.amsl.com (Postfix) with SMTP id 35DDE3A691F for ; Fri, 24 Apr 2009 02:44:03 -0700 (PDT) Received: (qmail 32554 invoked from network); 24 Apr 2009 09:47:56 -0000 Received: from gator465.hostgator.com (69.56.174.130) by gateway04.websitewelcome.com with SMTP; 24 Apr 2009 09:47:56 -0000 Received: from fl1-122-135-121-241.tky.mesh.ad.jp ([122.135.121.241]:61471 helo=[192.168.1.3]) by gator465.hostgator.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1LxHyA-0003Px-Vp; Fri, 24 Apr 2009 04:45:19 -0500 Message-Id: From: Shida Schubert To: Gonzalo Camarillo In-Reply-To: <49F17C09.8060107@ericsson.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Fri, 24 Apr 2009 18:45:17 +0900 References: <49F17C09.8060107@ericsson.com> X-Mailer: Apple Mail (2.930.3) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator465.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ntt-at.com Cc: SIPCORE , draft-rosenberg-sip-target-uri-delivery@tools.ietf.org Subject: Re: [sipcore] Target URI draft from 00 to 01 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Apr 2009 09:44:04 -0000 I did check the minutes to retrieve changes that were needed based on the WG consensus but must have overlooked the fact that draft was supposed to be submitted as a sip-00 (WG document).. Anyhow, the current version of the draft reflects the changes that were agreed at the IETF 73 based on the minutes. * Please refer to the IETF 73 SIP minutes for details. ** Changes from 00 ** 1. Adding Free Phone Number back to the use-case. 2. Adding the definition of "retarget" operation. 3. Removal of reference to URN. - Reference to URN was made in the section 4 in the 00 version. 4. Discussion of P-Called-Party-Id. - Explanation of why P-Called-Party-Id is not sufficient. 5. Parameter name conflict . - Target is already used in RFC4458 As for my involvement, I asked Jonathan if I could be of any help to progress the draft after IETF73, and he asked me to help him edit the draft. Regards Shida On 24-Apr-09, at 5:44 PM, Gonzalo Camarillo wrote: > Authors of the target URI draft, > > the SIP WG agreed to take the 00 version of the draft below as a WG > item. > > http://tools.ietf.org/html/draft-rosenberg-sip-target-uri-delivery-01 > > From that moment on, change control should have been in the hands of > the SIP WG, which includes the contents of the draft and its > editor(s). The SIP chairs have expressed concerns in the way the > draft evolved from 00 to 01 (see an email from Keith on this list on > this topic). > > http://tools.ietf.org/rfcdiff?difftype=--hwdiff&url2=http://tools.ietf.org/id/draft-rosenberg-sip-target-uri-delivery-01.txt > > Therefore, we would like to ask the authors of this draft to > summarize and explain the changes from 00 to 01. > > Note that I sent a different note to the list about how to proceed > with the specification work we need to do. This note is just a > request for clarification so that we all understand what are the > contents of this version of the draft. > > Thanks, > > Gonzalo > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From mary.barnes@nortel.com Fri Apr 24 07:15:16 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A02CF3A6CA5 for ; Fri, 24 Apr 2009 07:15:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.466 X-Spam-Level: X-Spam-Status: No, score=-6.466 tagged_above=-999 required=5 tests=[AWL=0.133, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Rxt0pqMnGlYT for ; Fri, 24 Apr 2009 07:15:15 -0700 (PDT) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id 504563A6BCC for ; Fri, 24 Apr 2009 07:15:15 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id n3OEFhW27143; Fri, 24 Apr 2009 14:15:44 GMT 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: Fri, 24 Apr 2009 09:18:48 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF1DA433D3@zrc2hxm0.corp.nortel.com> In-Reply-To: <49F178CE.8000809@ericsson.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] Target URI and History Info bis Thread-Index: AcnEt3f3DHIIpzIOQiWDqsZ/Lh234wAKNPEg References: <49F178CE.8000809@ericsson.com> From: "Mary Barnes" To: "Gonzalo Camarillo" , "SIPCORE" Subject: Re: [sipcore] Target URI and History Info bis X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Apr 2009 14:15:16 -0000 Just one clarification, I do not necessarily think there should be one document - my primary concern has been that normative History-Info header processing should be in a single document. Even in that case, it might still be useful to have target-uri provide the usecases and details as to how those use cases are accomodated using History-Info - i.e., informational. =20 As far as keeping the normative text in target-URI, that increases the potential for inconsistencies and there will be duplication of text to comprehensively describe the use of the extensions - what's in the document right now is incomplete. And, the point about speed is really moot IF the WG can agree the scope of changes to 4244 now - i.e., if we can agree we will make normative changes to support target-uri and keep the other core History-Info requirements, there is no problem. There is an error in the ABNF that should be fixed and we've already discussed a few other issues such as making a recommendation not to apply privacy to the entire message. And, that change is really required to support target-uri. So, I believe that if you were to complete the target-uri solution in a separate document, you will find more things like this at which time the most sensible thing to do would be to bis 4244. So, to me, it seems much easier to make the decision now. The changes to add a tag to support target-uri are minimal, but they have been carefully integrated into the current processing for RFC 4244. Note, this does not yet address the point about privacy above, which will be added to the revision. The other changes to 4244 were previously summarized along with target-uri changes in an email that Shida sent that was from him and myself: http://www.ietf.org/mail-archive/web/sip/current/msg26880.html As I previously sent to the list, here's the diff between 4244 and 4244bis: http://tools.ietf.org//rfcdiff?url1=3Dhttp://tools.ietf.org/rfc/rfc4244.t= x t&url2=3Dhttp://tools.ietf.org/id/draft-barnes-sip-rfc4244bis-00.txt And, please note that the normative text for handling what's called the "retarget" tag in 4244bis is a superset of that in the target-uri document - i.e., the normative functionality in target-uri was pulled into 4244bis with additional text added to complete the solution.=20 Personally, I don't think we need to debate documents as much as we need to discuss the issues that were summarized in the email and that Francois attempted to discuss during the meeting Issue 1: Marking hi-entries Issue 2: Pruning of hi-entries Issue 3: TLS And, these are pretty much the same points that we tried to get discussed in the threads before the meeting, with a little discussion post-meeting on SIP WG mailing list. Issue 1 is really the most important as that's what is needed for the target-uri uses cases and that gets us into the terminology issue.=20 The issue folks have with the current security in RFC 4244 (Issue 3 above) is that the bar is higher than it is for any other header (that's where we get into the "history" of "History-Info"). It would be nice if the WG could agree that this text can be loosened slightly - i.e., TLS RECOMMENDED vs mandated. There is the slightest amount of wiggle room in there now, but it's not obvious. The plan is to make the changes in the next version.=20 And, I honestly have a hard time understanding why folks are so resistant to updating an RFC that was published 4 years ago. This is the norm, is it not, to update documents that have been out for a while once we have more implementation experience and additional use cases to consider? =20 Regards, Mary.=20 -----Original Message----- From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behalf Of Gonzalo Camarillo Sent: Friday, April 24, 2009 3:31 AM To: SIPCORE Subject: [sipcore] Target URI and History Info bis Hi, discussions about the target URI and history info bis work has focused too much on the historical background and not enough on the best way to proceed with this work. I would like to have discussions on what we think would be the best and fastest way to specify what needs to be specified. Mary claims that having the following draft tackle both the target URI issue and the revision of History Info would be the fastest and cleanest way to be done with everything we want to specify. http://tools.ietf.org/html/draft-barnes-sip-rfc4244bis-00 Others claim that tackling the target URI issue in an independent draft that does not depend on the revision of History info would be the fastest way to proceed with the target URI issue. http://tools.ietf.org/html/draft-rosenberg-sip-target-uri-delivery-01 I would like to hear opinions on how we should proceed and why. I would prefer to get reasons related to clearness of the specifications, speed of the process, etc., instead of about the historical background on these two drafts. Thanks, Gonzalo _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore From AUDET@nortel.com Fri Apr 24 08:35:08 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D805F3A6AFE for ; Fri, 24 Apr 2009 08:35:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.353 X-Spam-Level: X-Spam-Status: No, score=-6.353 tagged_above=-999 required=5 tests=[AWL=0.246, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ihl0RI1wLDVy for ; Fri, 24 Apr 2009 08:35:08 -0700 (PDT) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id BB1803A69DD for ; Fri, 24 Apr 2009 08:35:07 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id n3OFZZW14651; Fri, 24 Apr 2009 15:35:36 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 24 Apr 2009 10:36:19 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF1DA43660@zrc2hxm0.corp.nortel.com> In-Reply-To: <0D5F89FAC29E2C41B98A6A762007F5D001CF8141@GBNTHT12009MSX.gb002.siemens.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] Target URI and History Info bis Thread-Index: AcnEt3tlieW8J+vHQQ+TDHiRIeQm+AACFNpAAAxL4XA= References: <49F178CE.8000809@ericsson.com> <0D5F89FAC29E2C41B98A6A762007F5D001CF8141@GBNTHT12009MSX.gb002.siemens.net> From: "Francois Audet" To: "Elwell, John" , "Gonzalo Camarillo" , "SIPCORE" Subject: Re: [sipcore] Target URI and History Info bis X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Apr 2009 15:35:08 -0000 I agree with John. Document fragmentation for something like History-Info will result in implementations that are not interoperable. I can not imagine anybody would want to implement Target-URI on top of the current 4244, and then do a bis. Here is what I propose on how to go FORWARD: 1) There is a bunch of non-controversial things we agreed to in=20 San Francisco that I can tackle right away on 4244bis (cleanup=20 stuff), starting on Monday. Nothing controversial. 2) Then, I would say the highest priority will be rolling in the agreed-to content of Target-URI into 4244bis. Again, I don't believe there is anything controversial (this will=20 cover only the "last hop" original intent of Target-URI). 3) And then last, the marking of or mid-stream redirect. That's I believe the only place where there is still some issues to sort out. By following those steps in that order, I think we can achieve progress. The reason I'm confident about this is that the thorny topic (3) is not blocking the non-thorny ones (1-2).=20 > -----Original Message----- > From: sipcore-bounces@ietf.org=20 > [mailto:sipcore-bounces@ietf.org] On Behalf Of Elwell, John > Sent: Friday, April 24, 2009 02:36 > To: Gonzalo Camarillo; SIPCORE > Subject: Re: [sipcore] Target URI and History Info bis >=20 > I would prefer to move forward with a single draft covering=20 > all the enhancements necessary to History-Info. >=20 > John >=20 > > -----Original Message----- > > From: sipcore-bounces@ietf.org > > [mailto:sipcore-bounces@ietf.org] On Behalf Of Gonzalo Camarillo > > Sent: 24 April 2009 09:31 > > To: SIPCORE > > Subject: [sipcore] Target URI and History Info bis > >=20 > > Hi, > >=20 > > discussions about the target URI and history info bis work=20 > has focused=20 > > too much on the historical background and not enough on the=20 > best way=20 > > to proceed with this work. I would like to have discussions=20 > on what we=20 > > think would be the best and fastest way to specify what needs to be=20 > > specified. > >=20 > > Mary claims that having the following draft tackle both the=20 > target URI=20 > > issue and the revision of History Info would be the fastest and=20 > > cleanest way to be done with everything we want to specify. > >=20 > > http://tools.ietf.org/html/draft-barnes-sip-rfc4244bis-00 > >=20 > > Others claim that tackling the target URI issue in an independent=20 > > draft that does not depend on the revision of History info would be=20 > > the fastest way to proceed with the target URI issue. > >=20 > >=20 > http://tools.ietf.org/html/draft-rosenberg-sip-target-uri-delivery-01 > >=20 > > I would like to hear opinions on how we should proceed and why. I=20 > > would prefer to get reasons related to clearness of the=20 > > specifications, speed of the process, etc., instead of about the=20 > > historical background on these two drafts. > >=20 > > Thanks, > >=20 > > Gonzalo > >=20 > > _______________________________________________ > > 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 From mary.barnes@nortel.com Fri Apr 24 09:33:20 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 067933A6966 for ; Fri, 24 Apr 2009 09:33:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.467 X-Spam-Level: X-Spam-Status: No, score=-6.467 tagged_above=-999 required=5 tests=[AWL=0.132, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fCu50BvB2Ur5 for ; Fri, 24 Apr 2009 09:33:19 -0700 (PDT) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id D9F5B3A6403 for ; Fri, 24 Apr 2009 09:33:18 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id n3OGXkW25591 for ; Fri, 24 Apr 2009 16:33:46 GMT 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: Fri, 24 Apr 2009 11:36:25 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF1DA43840@zrc2hxm0.corp.nortel.com> In-Reply-To: <1ECE0EB50388174790F9694F77522CCF1DA43660@zrc2hxm0.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] Target URI and History Info bis Thread-Index: AcnEt3tlieW8J+vHQQ+TDHiRIeQm+AACFNpAAAxL4XAAAkp+sA== References: <49F178CE.8000809@ericsson.com><0D5F89FAC29E2C41B98A6A762007F5D001CF8141@GBNTHT12009MSX.gb002.siemens.net> <1ECE0EB50388174790F9694F77522CCF1DA43660@zrc2hxm0.corp.nortel.com> From: "Mary Barnes" To: "Francois Audet" Cc: SIPCORE Subject: Re: [sipcore] Target URI and History Info bis X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Apr 2009 16:33:20 -0000 2) is already done based on current target-uri content and honestly, I think it makes no sense to add anything more normative to that document since it is less than what is in 4244bis. We just need to change the name of the tag to whatever.=20 I agree 3) is the remaining issue from a technical perspective as long as we can agree that updates to the security are covered by 1). Mary.=20 -----Original Message----- From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behalf Of Audet, Francois (SC100:3055) Sent: Friday, April 24, 2009 10:36 AM To: Elwell, John; Gonzalo Camarillo; SIPCORE Subject: Re: [sipcore] Target URI and History Info bis I agree with John. Document fragmentation for something like History-Info will result in implementations that are not interoperable. I can not imagine anybody would want to implement Target-URI on top of the current 4244, and then do a bis. Here is what I propose on how to go FORWARD: 1) There is a bunch of non-controversial things we agreed to in San Francisco that I can tackle right away on 4244bis (cleanup stuff), starting on Monday. Nothing controversial. 2) Then, I would say the highest priority will be rolling in the agreed-to content of Target-URI into 4244bis. Again, I don't believe there is anything controversial (this will cover only the "last hop" original intent of Target-URI). 3) And then last, the marking of or mid-stream redirect. That's I believe the only place where there is still some issues to sort out. By following those steps in that order, I think we can achieve progress. The reason I'm confident about this is that the thorny topic (3) is not blocking the non-thorny ones (1-2).=20 > -----Original Message----- > From: sipcore-bounces@ietf.org > [mailto:sipcore-bounces@ietf.org] On Behalf Of Elwell, John > Sent: Friday, April 24, 2009 02:36 > To: Gonzalo Camarillo; SIPCORE > Subject: Re: [sipcore] Target URI and History Info bis >=20 > I would prefer to move forward with a single draft covering all the=20 > enhancements necessary to History-Info. >=20 > John >=20 > > -----Original Message----- > > From: sipcore-bounces@ietf.org > > [mailto:sipcore-bounces@ietf.org] On Behalf Of Gonzalo Camarillo > > Sent: 24 April 2009 09:31 > > To: SIPCORE > > Subject: [sipcore] Target URI and History Info bis > >=20 > > Hi, > >=20 > > discussions about the target URI and history info bis work > has focused > > too much on the historical background and not enough on the > best way > > to proceed with this work. I would like to have discussions > on what we > > think would be the best and fastest way to specify what needs to be=20 > > specified. > >=20 > > Mary claims that having the following draft tackle both the > target URI > > issue and the revision of History Info would be the fastest and=20 > > cleanest way to be done with everything we want to specify. > >=20 > > http://tools.ietf.org/html/draft-barnes-sip-rfc4244bis-00 > >=20 > > Others claim that tackling the target URI issue in an independent=20 > > draft that does not depend on the revision of History info would be=20 > > the fastest way to proceed with the target URI issue. > >=20 > >=20 > http://tools.ietf.org/html/draft-rosenberg-sip-target-uri-delivery-01 > >=20 > > I would like to hear opinions on how we should proceed and why. I=20 > > would prefer to get reasons related to clearness of the=20 > > specifications, speed of the process, etc., instead of about the=20 > > historical background on these two drafts. > >=20 > > Thanks, > >=20 > > Gonzalo > >=20 > > _______________________________________________ > > 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 _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore From AUDET@nortel.com Fri Apr 24 09:34:49 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D53D73A6CE1 for ; Fri, 24 Apr 2009 09:34:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.37 X-Spam-Level: X-Spam-Status: No, score=-6.37 tagged_above=-999 required=5 tests=[AWL=0.229, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gaztQyduRYZ9 for ; Fri, 24 Apr 2009 09:34:48 -0700 (PDT) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id 930613A6403 for ; Fri, 24 Apr 2009 09:34:48 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id n3OGZHW25808 for ; Fri, 24 Apr 2009 16:35:17 GMT 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: Fri, 24 Apr 2009 11:35:17 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF1DA4384E@zrc2hxm0.corp.nortel.com> In-Reply-To: <1ECE0EB50388174790F9694F77522CCF1DA43840@zrc2hxm0.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] Target URI and History Info bis Thread-Index: AcnEt3tlieW8J+vHQQ+TDHiRIeQm+AACFNpAAAxL4XAAAkp+sAAAGLBg References: <49F178CE.8000809@ericsson.com><0D5F89FAC29E2C41B98A6A762007F5D001CF8141@GBNTHT12009MSX.gb002.siemens.net> <1ECE0EB50388174790F9694F77522CCF1DA43660@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1DA43840@zrc2hxm0.corp.nortel.com> From: "Francois Audet" To: "Mary Barnes" Cc: SIPCORE Subject: Re: [sipcore] Target URI and History Info bis X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Apr 2009 16:34:49 -0000 Yes, I'm just saying let's roll it into 4244bis.=20 > -----Original Message----- > From: Barnes, Mary (RICH2:AR00)=20 > Sent: Friday, April 24, 2009 09:36 > To: Audet, Francois (SC100:3055) > Cc: SIPCORE > Subject: RE: [sipcore] Target URI and History Info bis >=20 > 2) is already done based on current target-uri content and=20 > honestly, I think it makes no sense to add anything more=20 > normative to that document since it is less than what is in=20 > 4244bis. We just need to change the name of the tag to whatever.=20 >=20 > I agree 3) is the remaining issue from a technical=20 > perspective as long as we can agree that updates to the=20 > security are covered by 1). >=20 > Mary.=20 >=20 > -----Original Message----- > From: sipcore-bounces@ietf.org=20 > [mailto:sipcore-bounces@ietf.org] On Behalf Of Audet,=20 > Francois (SC100:3055) > Sent: Friday, April 24, 2009 10:36 AM > To: Elwell, John; Gonzalo Camarillo; SIPCORE > Subject: Re: [sipcore] Target URI and History Info bis >=20 > I agree with John. >=20 > Document fragmentation for something like History-Info will=20 > result in implementations that are not interoperable. I can=20 > not imagine anybody would want to implement Target-URI on top=20 > of the current 4244, and then do a bis. >=20 > Here is what I propose on how to go FORWARD: >=20 > 1) There is a bunch of non-controversial things we agreed to=20 > in San Francisco that I can tackle right away on 4244bis=20 > (cleanup stuff), starting on Monday. Nothing controversial. >=20 > 2) Then, I would say the highest priority will be rolling in=20 > the agreed-to content of Target-URI into 4244bis. Again, I=20 > don't believe there is anything controversial (this will=20 > cover only the "last hop" original intent of Target-URI). >=20 > 3) And then last, the marking of or mid-stream redirect.=20 > That's I believe the only place where there is still some=20 > issues to sort out. >=20 > By following those steps in that order, I think we can=20 > achieve progress. The reason I'm confident about this is that=20 > the thorny topic (3) is not blocking the non-thorny ones (1-2).=20 >=20 > > -----Original Message----- > > From: sipcore-bounces@ietf.org > > [mailto:sipcore-bounces@ietf.org] On Behalf Of Elwell, John > > Sent: Friday, April 24, 2009 02:36 > > To: Gonzalo Camarillo; SIPCORE > > Subject: Re: [sipcore] Target URI and History Info bis > >=20 > > I would prefer to move forward with a single draft covering all the=20 > > enhancements necessary to History-Info. > >=20 > > John > >=20 > > > -----Original Message----- > > > From: sipcore-bounces@ietf.org > > > [mailto:sipcore-bounces@ietf.org] On Behalf Of Gonzalo Camarillo > > > Sent: 24 April 2009 09:31 > > > To: SIPCORE > > > Subject: [sipcore] Target URI and History Info bis > > >=20 > > > Hi, > > >=20 > > > discussions about the target URI and history info bis work > > has focused > > > too much on the historical background and not enough on the > > best way > > > to proceed with this work. I would like to have discussions > > on what we > > > think would be the best and fastest way to specify what=20 > needs to be=20 > > > specified. > > >=20 > > > Mary claims that having the following draft tackle both the > > target URI > > > issue and the revision of History Info would be the fastest and=20 > > > cleanest way to be done with everything we want to specify. > > >=20 > > > http://tools.ietf.org/html/draft-barnes-sip-rfc4244bis-00 > > >=20 > > > Others claim that tackling the target URI issue in an independent=20 > > > draft that does not depend on the revision of History=20 > info would be=20 > > > the fastest way to proceed with the target URI issue. > > >=20 > > >=20 > >=20 > http://tools.ietf.org/html/draft-rosenberg-sip-target-uri-delivery-01 > > >=20 > > > I would like to hear opinions on how we should proceed and why. I=20 > > > would prefer to get reasons related to clearness of the=20 > > > specifications, speed of the process, etc., instead of about the=20 > > > historical background on these two drafts. > > >=20 > > > Thanks, > > >=20 > > > Gonzalo > > >=20 > > > _______________________________________________ > > > 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 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore >=20 From rjsparks@nostrum.com Fri Apr 24 11:47:59 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 645D03A6966; Fri, 24 Apr 2009 11:47:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, SPF_PASS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PLcXO2UxfgMp; Fri, 24 Apr 2009 11:47:58 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id C5EA73A6CFA; Fri, 24 Apr 2009 11:47:57 -0700 (PDT) Received: from [192.168.2.2] (pool-173-57-111-84.dllstx.fios.verizon.net [173.57.111.84]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id n3OInE0K099874 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 24 Apr 2009 13:49:14 -0500 (CDT) (envelope-from rjsparks@nostrum.com) Message-Id: From: Robert Sparks To: SIP IETF , sipcore@ietf.org, rai@ietf.org Content-Type: multipart/alternative; boundary=Apple-Mail-203-298749059 Mime-Version: 1.0 (Apple Message framework v930.3) Date: Fri, 24 Apr 2009 13:49:13 -0500 X-Mailer: Apple Mail (2.930.3) Received-SPF: pass (nostrum.com: 173.57.111.84 is authenticated by a trusted mechanism) Subject: [sipcore] Registration for SIPit 24 closes next week X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Apr 2009 18:47:59 -0000 --Apple-Mail-203-298749059 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Registration for SIPit 24 closes April 30. If you are not yet registered, but plan to attend, please register now. SIPit 24 will be held May 18-22, 2009 in Akihabara, Tokyo, Japan hosted by JPNIC and NICT. Additional information is available at http://www.sipit.net and http://www.nic.ad.jp/en/sipit24/ --Apple-Mail-203-298749059 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: 7bit Registration for SIPit 24 closes April 30. If you are not yet registered, but plan to attend, please register now.

SIPit 24 will be held May 18-22, 2009 in Akihabara, Tokyo, Japan  
hosted by JPNIC and NICT.
Additional information is available at http://www.sipit.net and http://www.nic.ad.jp/en/sipit24/
--Apple-Mail-203-298749059-- From ietf.hanserik@gmail.com Fri Apr 24 13:42:09 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DC9F43A6E7A for ; Fri, 24 Apr 2009 13:42:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.494 X-Spam-Level: X-Spam-Status: No, score=-2.494 tagged_above=-999 required=5 tests=[AWL=0.105, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lWsAEQaAKOhK for ; Fri, 24 Apr 2009 13:42:09 -0700 (PDT) Received: from mail-ew0-f176.google.com (mail-ew0-f176.google.com [209.85.219.176]) by core3.amsl.com (Postfix) with ESMTP id 33CA428C2A0 for ; Fri, 24 Apr 2009 13:41:28 -0700 (PDT) Received: by ewy24 with SMTP id 24so1218740ewy.37 for ; Fri, 24 Apr 2009 13:42:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=hiOuidmEhKsCYcNU0ZNd5OGByk03yoAg33TMYfjzpcI=; b=lxBCqwms+7udwA0lMraX5oE3MHANUKmBsbefGTB7t/0BWEXviJO2rO0b3mFDEgQF3+ L9+WG/bjQw9lvxW7GV1gaAwQrbYw10QHUa/fyr6o1qwUot7HAoYt0HiRzIKDInHBODln zVkbqxZOJ2fDfsbgKTgnAZ6nQNsvMYJ6GFPaE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=cQkbHmEJZ0apSS84PoFXi4VKgnPWTgXF8A7420JWjGnBvTSIRspMJFQpe599k2nCKm IVWvbbl8VcyZFJYKGFM0IrAQh8fPE93fT7VV2yz6jl5y6L3liQcdjd03AkYcviX07b7s UK6nkS8wYViUuotV0khIrLw0fwkJLothf9J/c= Received: by 10.210.130.13 with SMTP id c13mr1813169ebd.21.1240605766237; Fri, 24 Apr 2009 13:42:46 -0700 (PDT) Received: from ?192.168.1.5? (212-182-129-30.ip.telfort.nl [212.182.129.30]) by mx.google.com with ESMTPS id 28sm2318524eye.46.2009.04.24.13.42.44 (version=SSLv3 cipher=RC4-MD5); Fri, 24 Apr 2009 13:42:45 -0700 (PDT) Message-ID: <49F22443.7010706@gmail.com> Date: Fri, 24 Apr 2009 22:42:43 +0200 From: Hans Erik van Elburg User-Agent: Thunderbird 2.0.0.21 (X11/20090409) MIME-Version: 1.0 To: Gonzalo Camarillo References: <49F178CE.8000809@ericsson.com> In-Reply-To: <49F178CE.8000809@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: SIPCORE Subject: Re: [sipcore] Target URI and History Info bis X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Apr 2009 20:42:09 -0000 Lets finish the target-uri document first independently, before dragging it into another endless 4244bis discussion. It can focus on the topic for which it was created. If 4244bis can work on the other issues it seems to instantiated for and it is ready in time, we can always decide to merge the then provided target-uri solution in to 4244bis. This would speed up the process as several people have expressed that they need the target-uri solution in due time. The target-uri draft has a very clear scope, the 4244bis seems an open ended attractor for History-Info issues... Best Regards, /Hans Erik Gonzalo Camarillo wrote: > Hi, > > discussions about the target URI and history info bis work has focused > too much on the historical background and not enough on the best way > to proceed with this work. I would like to have discussions on what we > think would be the best and fastest way to specify what needs to be > specified. > > Mary claims that having the following draft tackle both the target URI > issue and the revision of History Info would be the fastest and > cleanest way to be done with everything we want to specify. > > http://tools.ietf.org/html/draft-barnes-sip-rfc4244bis-00 > > Others claim that tackling the target URI issue in an independent > draft that does not depend on the revision of History info would be > the fastest way to proceed with the target URI issue. > > http://tools.ietf.org/html/draft-rosenberg-sip-target-uri-delivery-01 > > I would like to hear opinions on how we should proceed and why. I > would prefer to get reasons related to clearness of the > specifications, speed of the process, etc., instead of about the > historical background on these two drafts. > > Thanks, > > Gonzalo > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From mary.barnes@nortel.com Fri Apr 24 13:51:41 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E92273A6AC8 for ; Fri, 24 Apr 2009 13:51:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.466 X-Spam-Level: X-Spam-Status: No, score=-6.466 tagged_above=-999 required=5 tests=[AWL=0.133, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d3OfjIRSDIDr for ; Fri, 24 Apr 2009 13:51:41 -0700 (PDT) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id D0D9E3A684A for ; Fri, 24 Apr 2009 13:51:40 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id n3OKq9W05971; Fri, 24 Apr 2009 20:52:09 GMT 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: Fri, 24 Apr 2009 15:54:38 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF1DA43F5F@zrc2hxm0.corp.nortel.com> In-Reply-To: <49F22443.7010706@gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] Target URI and History Info bis Thread-Index: AcnFHVnNRSw1PA4EQmW33ETABtXuQwAANVhw References: <49F178CE.8000809@ericsson.com> <49F22443.7010706@gmail.com> From: "Mary Barnes" To: "Hans Erik van Elburg" , "Gonzalo Camarillo" Cc: SIPCORE Subject: Re: [sipcore] Target URI and History Info bis X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Apr 2009 20:51:42 -0000 Just to re-iterate once more, 4244bis already contains a superset of the normative text for History-Info header from the current target-uri document. Francois has proposed a fairly straightforward path for 4244bis that should allow us to avoid any of the hurdles and open ended debates as to History-Info issues - the known issues are quite straight-forward to solve and the issues at hand really are providing a solution for target-uri. The idea that the target-uri document would progress much quicker than 4244bis is a red herring - in particular based on my comments that you need more changes to 4244 to support target-uri than just the new tags.=20 Mary.=20 -----Original Message----- From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behalf Of Hans Erik van Elburg Sent: Friday, April 24, 2009 3:43 PM To: Gonzalo Camarillo Cc: SIPCORE Subject: Re: [sipcore] Target URI and History Info bis Lets finish the target-uri document first independently, before dragging it into another endless 4244bis discussion. It can focus on the topic for which it was created. If 4244bis can work on the other issues it seems to instantiated for and it is ready in time, we can always decide to merge the then provided target-uri solution in to 4244bis. This would speed up the process as several people have expressed that they need the target-uri solution in due time. The target-uri draft has a very clear scope, the 4244bis seems an open ended attractor for History-Info issues... Best Regards, /Hans Erik Gonzalo Camarillo wrote: > Hi, > > discussions about the target URI and history info bis work has focused > too much on the historical background and not enough on the best way=20 > to proceed with this work. I would like to have discussions on what we > think would be the best and fastest way to specify what needs to be=20 > specified. > > Mary claims that having the following draft tackle both the target URI > issue and the revision of History Info would be the fastest and=20 > cleanest way to be done with everything we want to specify. > > http://tools.ietf.org/html/draft-barnes-sip-rfc4244bis-00 > > Others claim that tackling the target URI issue in an independent=20 > draft that does not depend on the revision of History info would be=20 > the fastest way to proceed with the target URI issue. > > http://tools.ietf.org/html/draft-rosenberg-sip-target-uri-delivery-01 > > I would like to hear opinions on how we should proceed and why. I=20 > would prefer to get reasons related to clearness of the=20 > specifications, speed of the process, etc., instead of about the=20 > historical background on these two drafts. > > Thanks, > > Gonzalo > > _______________________________________________ > 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 dean.willis@softarmor.com Fri Apr 24 14:57:24 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3EAF43A684C for ; Fri, 24 Apr 2009 14:57:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.018 X-Spam-Level: X-Spam-Status: No, score=-2.018 tagged_above=-999 required=5 tests=[AWL=-0.497, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, WHOIS_DMNBYPROXY=0.478] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n8aeBP+YTtQR for ; Fri, 24 Apr 2009 14:57:17 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 926703A6AEC for ; Fri, 24 Apr 2009 14:55:54 -0700 (PDT) Received: from [192.168.2.102] (cpe-72-181-150-177.tx.res.rr.com [72.181.150.177]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id n3OLv9Qq017389 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Fri, 24 Apr 2009 16:57:10 -0500 Message-Id: <0ECC036E-2B21-49D5-AC42-1FEC8EC447BE@softarmor.com> From: Dean Willis To: Gonzalo Camarillo In-Reply-To: <49F178CE.8000809@ericsson.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Fri, 24 Apr 2009 16:57:04 -0500 References: <49F178CE.8000809@ericsson.com> X-Mailer: Apple Mail (2.930.3) Cc: SIPCORE Subject: [sipcore] Long reply to: Target URI and History Info bis X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Apr 2009 21:57:24 -0000 On Apr 24, 2009, at 3:31 AM, Gonzalo Camarillo wrote: > Hi, > > discussions about the target URI and history info bis work has > focused too much on the historical background and not enough on the > best way to proceed with this work. I would like to have discussions > on what we think would be the best and fastest way to specify what > needs to be specified. I'd like to take this back to getting a clear statement on what needs to be SOLVED, rather than what needs to be specified. I strongly suspect we have lost track of our mission as we progressed through the vast labyrinth of complexity that litters our back-trail. So let's go back to the fundamental problem and see if we can regain consensus on what we're trying to fix. One model of application structure derives from the way that HTTP CGI applications are written. In this model, the request-URI encodes not only the target (in this case, the application), but also any parameters being delivered to the application. For example, let's take the expansion of a URL I recently sent to the sipcore list: http://snurl.com/ghlt8 which expands into (yes, the lines are going to get wrapped by the email system) http://tools.ietf.org/rfcdiff?url1=http://tools.ietf.org/id/draft-ietf-sipcore-subnot-etags-00.txt&url2=http://tools.ietf.org/id/draft-ietf-sipcore-subnot-etags-02.txt Here the application-identifying portion of the URL is "http://tools.ietf.org/rfcdiff ". The first parameter is "url1=http://tools.ietf.org/id/draft-ietf-sipcore-subnot-etags-00.txt " and the second is "url2=http://tools.ietf.org/id/draft-ietf-sipcore-subnot-etags-02.txt ". The application (which you can exercise with a browser) generates a side-by-side diff of the two IETF-style documents referenced by the URLs that are sent as parameters. In SIP, we might encode the parameters onto the request URI slightly differently, but the same basic approach applies. This philosophy of application design is described in RFC 3087. This approach works very nicely for SIP applications that are directly addressable. RFC 2543 broke it for any SIP applications that required traversing a proxy to reach the application, because RFC 2543 rather stupidly (and yes, I complained about it at the time) rewrote the request-URI on every proxy hop. We sort of fixed this in RFC 3261 with "loose routing", but it was STILL broken for any target that used "contact routing", that is, where the contact stored by a registrar replaced the AOR in the request URI. This defect made URI application and parameter encoding useless for most user-to-user applications, because somewhere in there, a contact- routing proxy is probably going to replace the request-URI and break things. Jonathan's ua-loose-route draft was an attempt to fix the problem by making SIP proxies stop rewriting the request URI entirely. We thought this wasn't all that backward compatible (it's hard to be backward compatible with something that's pretty much broken), so it didn't make the cut. We've also proposed that the destination might be able to retrieve the original URI and parameters from the seething mass of History-Info entries and parameters, but that's also unappetizing in certain respects. So what was the original goal again? We're trying to convey, from UAC to UAS enough information about an application to enable the UAS to select the correct application and pass the request to that application, along with any parameters supplied by the UAC. And we're trying to do this in a way that survives all sorts of proxy processing, It doesn't have to survive redirect processing, UNLESS a proxy acts on the redirect on behalf of the UAC. And we're trying to do it in a way that doesn't require extending the SIP specification for every new application, because even though we know our layering model is all messed up, we don't really want to make it exponentially worse. This basic problem of "application invocation" keeps coming up again and again. The whole service-indicator context-guessing thing is tied up in it. Explicit service indicators encoded as SIP extensions are VERY VERY BAD, because they tie the SIP protocol to the application in ways that keep requiring us to extend SIP to support new applications. Consider what would have happened to the world wide web if it required an HTTP extension for every new web application. Going down that path would be profoundly stupid, which we mostly know and have been trying to avoid. We've further complicated the problem with the idea that maybe middleboxes (ala proxies or SBCs) might need to "meddle" with the application-to-application information. The main problem here is that there are really two sorts of applications: those in the middle, that operate by rewriting the app-to-app information, and those on the ends, that rely on pristine app-to-app information. Prevent interactions between these two sorts of applications is IMPOSSIBLE, as their scopes, by definition, overlap. Consider for example the interaction of a speed-dial application with a voicemail application. The speed dial application might take "sip:6@softarmor.com ", when the authenticated user is "dean.willis@softarmor.com", and translate it to "sip:voicemail-dean@softarmor.com". This works fine -- it;s an easy string replacement at the proxy, we can code it in CPL, and so on. But assume that the voice-mail application needs parameters For example, let's say that it has "record" and "play" modalities, and "sip:voicemail-dean@softarmor.com&play " tells it to play my messages, whereas "sip:voicemail-dean@softarmor.com&record " tells it to record a new greeting. Barring subtle variations on parameter-encoding separators (we're still arguing about how that works), this is easy to implement in a voice-mail server. But the speed-dial application is going to break it. Trying to figure out which, if any, parameters need to be copied from the incoming request- URI and into the outgoing request-URI is difficult. Given that we've encoded some of the application context in the user-part (voicemail- dean vs voicemail-alice) , the problem is an even bigger furball. So here's my suggestion: Let's stop arguing about history-info, ua- loose-route, diversion, etc. and go back to the REAL underlying problem: How, in a consistent, predictable, and programmable way, do we pass application context from UAC to UAS? And we need to pay attention to the inversely-related question: What limitations do we allow the transport-support mechanism (proxies, sbcs, whatever) do we expect to place on the expressive range of this mechanism? Here's a hint: HTTP clearly defines what the transport-support mechanisms (proxies) can and cannot do. With HTTPS proxies, they can't do much except convey the info end to end. So HTTP applications can use request URI for parameter passing, they can use SOAP, they can use AJAX to funnel XML back-and-forth over a long lived connection, and so on. HTTP applications can do all this without adding new HTTP methods, new HTTP headers, new HTTP request types, and so on. So the HTTP model is, I argue "That which is not reserved to the HTTP protocol is available to the application". What's the SIP model? Is it possible to define one that is backward compatible with the hash we've made of our applications space with all these app-specific functions in our transport protocol? -- Dean From root@core3.amsl.com Sun Apr 26 23:15:02 2009 Return-Path: X-Original-To: sipcore@ietf.org Delivered-To: sipcore@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 165143A6E16; Sun, 26 Apr 2009 23:15:02 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090427061502.165143A6E16@core3.amsl.com> Date: Sun, 26 Apr 2009 23:15:02 -0700 (PDT) Cc: sipcore@ietf.org Subject: [sipcore] I-D Action:draft-ietf-sipcore-199-00.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Apr 2009 06:15:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session Initiation Protocol Core Working Group of the IETF. Title : Response Code for Indication of Terminated Dialog Author(s) : C. Holmberg Filename : draft-ietf-sipcore-199-00.txt Pages : 16 Date : 2009-04-26 This specification defines a new SIP response code, 199 Early Dialog Terminated, which a SIP forking proxy and a UAS can use to indicate upstream towards the UAC that an early dialog has been terminated, before a final response is sent towards the UAC. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sipcore-199-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-sipcore-199-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-04-26231154.I-D@ietf.org> --NextPart-- From christer.holmberg@ericsson.com Sun Apr 26 23:15:26 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B725F3A6EAB for ; Sun, 26 Apr 2009 23:15:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.805 X-Spam-Level: X-Spam-Status: No, score=-5.805 tagged_above=-999 required=5 tests=[AWL=0.443, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nHGsLkPB2Ah2 for ; Sun, 26 Apr 2009 23:15:25 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 188F23A6CEB for ; Sun, 26 Apr 2009 23:15:24 -0700 (PDT) X-AuditID: c1b4fb3e-b7ba8ae000006c2a-1f-49f54dcb1cdd Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw4.ericsson.se (Symantec Mail Security) with SMTP id 74.70.27690.BCD45F94; Mon, 27 Apr 2009 08:16:44 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 27 Apr 2009 08:16:43 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C9C6FF.BC3C13D3" Date: Mon, 27 Apr 2009 08:16:49 +0200 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Draft new version: draft-ietf-sipcore-199-00 Thread-Index: AcnG/7+Vxpf5fYowQbavsGMSzImshg== From: "Christer Holmberg" To: "SIPCORE" X-OriginalArrivalTime: 27 Apr 2009 06:16:43.0867 (UTC) FILETIME=[BC86A2B0:01C9C6FF] X-Brightmail-Tracker: AAAAAA== Cc: Gonzalo Camarillo Subject: [sipcore] Draft new version: draft-ietf-sipcore-199-00 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Apr 2009 06:15:26 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9C6FF.BC3C13D3 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, I've submitted the SIPCORE -00 version of the 199 draft. I removed a " character from the text, but otherwise the text is identical to the latest SIP version of the draft. The draft can also be found at: http://users.piuha.net/cholmber/drafts/draft-ietf-sipcore-199-00.txt Regards, Christer ------_=_NextPart_001_01C9C6FF.BC3C13D3 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Draft new version: draft-ietf-sipcore-199-00

Hi,

I've submitted the SIPCORE -00 version = of the 199 draft.

I removed a " character from the = text, but otherwise the text is identical to the latest SIP version of = the draft.

The draft can also be found at: = http://users.piuha.net/cholmber/drafts/draft-ietf-sipcore-= 199-00.txt

Regards,

Christer

------_=_NextPart_001_01C9C6FF.BC3C13D3-- From christer.holmberg@ericsson.com Sun Apr 26 23:27:17 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AC9C43A6EAB for ; Sun, 26 Apr 2009 23:27:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.808 X-Spam-Level: X-Spam-Status: No, score=-5.808 tagged_above=-999 required=5 tests=[AWL=0.441, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2FQbC2XvVdP9 for ; Sun, 26 Apr 2009 23:27:16 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 99BAA3A6DA2 for ; Sun, 26 Apr 2009 23:27:15 -0700 (PDT) X-AuditID: c1b4fb3e-b7ba8ae000006c2a-78-49f550923c15 Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw4.ericsson.se (Symantec Mail Security) with SMTP id 89.81.27690.29055F94; Mon, 27 Apr 2009 08:28:35 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 27 Apr 2009 08:28:34 +0200 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: Mon, 27 Apr 2009 08:28:39 +0200 Message-ID: In-Reply-To: <1ECE0EB50388174790F9694F77522CCF1DA43F5F@zrc2hxm0.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] Target URI and History Info bis Thread-Index: AcnFHVnNRSw1PA4EQmW33ETABtXuQwAANVhwAHiapTA= References: <49F178CE.8000809@ericsson.com> <49F22443.7010706@gmail.com> <1ECE0EB50388174790F9694F77522CCF1DA43F5F@zrc2hxm0.corp.nortel.com> From: "Christer Holmberg" To: "Mary Barnes" , "Hans Erik van Elburg" , "Gonzalo Camarillo" X-OriginalArrivalTime: 27 Apr 2009 06:28:34.0633 (UTC) FILETIME=[642CEB90:01C9C701] X-Brightmail-Tracker: AAAAAA== Cc: SIPCORE Subject: Re: [sipcore] Target URI and History Info bis X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Apr 2009 06:27:17 -0000 Hi, I can't remember that, when we agreed to use H-I for target delivery, a "precondition" would have been that we also must update 4244. I DO support the work on 4244bis, but that is a separate issue. Mary, could you please re-indicate why the target-uri draft doesn't work with 4244? Regards, Christer =20 > -----Original Message----- > From: sipcore-bounces@ietf.org=20 > [mailto:sipcore-bounces@ietf.org] On Behalf Of Mary Barnes > Sent: 24. huhtikuuta 2009 23:55 > To: Hans Erik van Elburg; Gonzalo Camarillo > Cc: SIPCORE > Subject: Re: [sipcore] Target URI and History Info bis >=20 > Just to re-iterate once more, 4244bis already contains a=20 > superset of the normative text for History-Info header from=20 > the current target-uri document. Francois has proposed a=20 > fairly straightforward path for 4244bis that should allow us=20 > to avoid any of the hurdles and open ended debates as to=20 > History-Info issues - the known issues are quite=20 > straight-forward to solve and the issues at hand really are=20 > providing a solution for target-uri. The idea that the=20 > target-uri document would progress much quicker than 4244bis=20 > is a red herring - in particular based on my comments that=20 > you need more changes to 4244 to support target-uri than just=20 > the new tags.=20 >=20 > Mary.=20 >=20 > -----Original Message----- > From: sipcore-bounces@ietf.org=20 > [mailto:sipcore-bounces@ietf.org] On Behalf Of Hans Erik van Elburg > Sent: Friday, April 24, 2009 3:43 PM > To: Gonzalo Camarillo > Cc: SIPCORE > Subject: Re: [sipcore] Target URI and History Info bis >=20 > Lets finish the target-uri document first independently,=20 > before dragging it into another endless 4244bis discussion.=20 > It can focus on the topic for which it was created. >=20 > If 4244bis can work on the other issues it seems to=20 > instantiated for and it is ready in time, we can always=20 > decide to merge the then provided target-uri solution in to 4244bis. >=20 > This would speed up the process as several people have=20 > expressed that they need the target-uri solution in due time.=20 > The target-uri draft has a very clear scope, the 4244bis=20 > seems an open ended attractor for History-Info issues... >=20 > Best Regards, > /Hans Erik >=20 > Gonzalo Camarillo wrote: > > Hi, > > > > discussions about the target URI and history info bis work=20 > has focused >=20 > > too much on the historical background and not enough on the=20 > best way=20 > > to proceed with this work. I would like to have discussions=20 > on what we >=20 > > think would be the best and fastest way to specify what needs to be=20 > > specified. > > > > Mary claims that having the following draft tackle both the=20 > target URI >=20 > > issue and the revision of History Info would be the fastest and=20 > > cleanest way to be done with everything we want to specify. > > > > http://tools.ietf.org/html/draft-barnes-sip-rfc4244bis-00 > > > > Others claim that tackling the target URI issue in an independent=20 > > draft that does not depend on the revision of History info would be=20 > > the fastest way to proceed with the target URI issue. > > > >=20 > http://tools.ietf.org/html/draft-rosenberg-sip-target-uri-delivery-01 > > > > I would like to hear opinions on how we should proceed and why. I=20 > > would prefer to get reasons related to clearness of the=20 > > specifications, speed of the process, etc., instead of about the=20 > > historical background on these two drafts. > > > > Thanks, > > > > Gonzalo > > > > _______________________________________________ > > 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 >=20 From eburger@standardstrack.com Mon Apr 27 04:31:08 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 06A9B3A6B29 for ; Mon, 27 Apr 2009 04:31:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.355 X-Spam-Level: X-Spam-Status: No, score=-2.355 tagged_above=-999 required=5 tests=[AWL=0.244, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CoDYGYvnGiWK for ; Mon, 27 Apr 2009 04:31:07 -0700 (PDT) Received: from gs19.inmotionhosting.com (gs19.inmotionhosting.com [205.134.252.251]) by core3.amsl.com (Postfix) with ESMTP id A908F3A6CEE for ; Mon, 27 Apr 2009 04:30:48 -0700 (PDT) Received: from c-75-68-112-157.hsd1.nh.comcast.net ([75.68.112.157] helo=[192.168.45.103]) by gs19.inmotionhosting.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1LyP48-0004Oy-Jn for sipcore@ietf.org; Mon, 27 Apr 2009 04:32:04 -0700 Message-Id: <65A71093-A94E-4E5D-AFBA-B3C5963CEA47@standardstrack.com> From: Eric Burger To: SIPCORE Content-Type: multipart/signed; boundary=Apple-Mail-53-531720349; micalg=sha1; protocol="application/pkcs7-signature" Mime-Version: 1.0 (Apple Message framework v930.3) Date: Mon, 27 Apr 2009 07:32:05 -0400 X-Mailer: Apple Mail (2.930.3) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gs19.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - standardstrack.com X-Source: X-Source-Args: X-Source-Dir: Subject: [sipcore] INFO Tables X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Apr 2009 11:31:08 -0000 --Apple-Mail-53-531720349 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Please, please, please go over this table and make sure it is correct. If I hear nothing now, yet people say stuff during WGLC or later, we will not be happy. Table 1: Summary of Header Fields Header Where INFO ------ ----- ---- Accept R o Accept-Encoding R o Accept-Encoding 2xx o Accept-Encoding 415 c Accept-Language R o Accept-Language 2xx o Accept-Language 415 c Allow R o Allow 200 - Allow 405 o Allow-Events R o Allow-Events r o Authentication-Info 2xx o Authorization R o Call-ID gc m Call-Info R o Call-Info r o Contact R - Contact 1xx - Contact 2xx - Contact 3xx - Contact 485 - Content-Disposition e o Content-Encoding e o Content-Language e o Content-Length e o Content-Type e * CSeq gc m Date g o Error-Info 3xx-6xx o Expires g - From gc m Geolocation R o Max-Breadth R - Max-Forwards R o MIME-Version R o MIME-Version r o Organization g o Privacy R o Proxy-Authenticate 407 o Proxy-Authorization R o Proxy-Require R o Reason R o Record-Route R o Record-Route 2xx o Require R o Require r o Retry-After R - Retry-After 404,480,486 o Retry-After 503 o Retry-After 600,603 o Route R o Security-Client R o Security-Server 421,494 o Security-Verify R o Server r o Subject R o Supported R o Supported 2xx o Timestamp g o To gc(1) m Unsupported 420 o User-Agent g o Via gc(2) m Warning r o WWW-Authenticate 401 o 5.2. INFO Headers This table expands on tables 2 and 3 in [RFC3261]. Header field where ACK BYE CAN INV OPT REG PRA INF MSG UPD SUB NOT -------------------------------------------------------------------- Info-Package R - - - - - - - m - - - - Recv-Info R o - - o o o o - - o - - Recv-Info 2xx o - - o o - o - - o - - Recv-Info 1xx o - - o o - o - - o - - Recv-Info r o - - - o - o - - o - - --Apple-Mail-53-531720349 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGPTCCBjkw ggUhoAMCAQICEC+VK1RLWxrF8KJZDR9k8p8wDQYJKoZIhvcNAQEFBQAwga4xCzAJBgNVBAYTAlVT MQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VS VFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQD Ey1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwwHhcNMDgwODEz MDAwMDAwWhcNMDkwODEzMjM1OTU5WjCB4TE1MDMGA1UECxMsQ29tb2RvIFRydXN0IE5ldHdvcmsg LSBQRVJTT05BIE5PVCBWQUxJREFURUQxRjBEBgNVBAsTPVRlcm1zIGFuZCBDb25kaXRpb25zIG9m IHVzZTogaHR0cDovL3d3dy5jb21vZG8ubmV0L3JlcG9zaXRvcnkxHzAdBgNVBAsTFihjKTIwMDMg Q29tb2RvIExpbWl0ZWQxFDASBgNVBAMTC0VyaWMgQnVyZ2VyMSkwJwYJKoZIhvcNAQkBFhplYnVy Z2VyQHN0YW5kYXJkc3RyYWNrLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMTF RRoA4LgOACMFph0aomRC/UpqoA5C/d6DUTOvTMrYSEqkjwnU4zxDtBcHlcB4AxKAov00MYsUvEU4 loz7BHjfDjv76AIkcwu33VYQbzGmarVnyaXsVb6f/cyRL3fPT0VOVO2tQAEEgwg//CX0jN8Kn2jH uXD/HEvko7cmpL3Pwevf3+DwB61v7ca79PpEZfn/WhaqRKA4uVNPj/JbieeaLo2v/0RJzrEElZK0 pHCqxiD3mQ8ossPkA9fUCSxLlbdMcPU3be5x8vt8Q8mYTXF5Z3d9RZmYrmNkvTQtdzVpfYWr/hgV Xqm9tByOOAR+hoN3FKbubR/OrAHL9yDAd4sCAwEAAaOCAhwwggIYMB8GA1UdIwQYMBaAFImCZ33E nSZwAEu0UEh83j2uBG59MB0GA1UdDgQWBBRDWgutb7b8R/L7G3Y3D+molAA3VzAOBgNVHQ8BAf8E BAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJ YIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQECAQEBMCswKQYIKwYBBQUHAgEW HWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BTMIGlBgNVHR8EgZ0wgZowTKBKoEiGRmh0dHA6 Ly9jcmwuY29tb2RvY2EuY29tL1VUTi1VU0VSRmlyc3QtQ2xpZW50QXV0aGVudGljYXRpb25hbmRF bWFpbC5jcmwwSqBIoEaGRGh0dHA6Ly9jcmwuY29tb2RvLm5ldC9VVE4tVVNFUkZpcnN0LUNsaWVu dEF1dGhlbnRpY2F0aW9uYW5kRW1haWwuY3JsMGwGCCsGAQUFBwEBBGAwXjA2BggrBgEFBQcwAoYq aHR0cDovL2NydC5jb21vZG9jYS5jb20vVVROQUFBQ2xpZW50Q0EuY3J0MCQGCCsGAQUFBzABhhho dHRwOi8vb2NzcC5jb21vZG9jYS5jb20wJQYDVR0RBB4wHIEaZWJ1cmdlckBzdGFuZGFyZHN0cmFj ay5jb20wDQYJKoZIhvcNAQEFBQADggEBAGeBR7NPCvrY3GQoIi49JOuciatY2r4st905Jw1etp6J umFFWlaCBl11tFSclk/3S45B+lUv3SEvG4CEjUByPScprVmCqHR+y8BAQaB/CV+N1y14x3MbhJ+Z 8XDGKeUXuuyGd9w0l3/t/QPid6TRXQjQFrLPFs1IALuNpNiFMHEF/xFbMG1Z2vznR/gSPlePekoZ TqcExIDBNZTBebpZqwAXzPpedNNOclbMLFLWDMOAozVRpkfjI0eiFsk8SF1Ho1Gb9Bx8DeG4peE2 KRVOR9FFnZZgBpFjXYRcglsMOSKCY8HgE+NGvbbqbrMoBV/BlYyxRXwfti71RL9Zs2Cq1eQxggP8 MIID+AIBATCBwzCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0IExh a2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRwOi8v d3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhlbnRp Y2F0aW9uIGFuZCBFbWFpbAIQL5UrVEtbGsXwolkNH2TynzAJBgUrDgMCGgUAoIICDTAYBgkqhkiG 9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wOTA0MjcxMTMyMDVaMCMGCSqGSIb3 DQEJBDEWBBRwp/qTXNckRksXjrzwe3IqerZBYTCB1AYJKwYBBAGCNxAEMYHGMIHDMIGuMQswCQYD VQQGEwJVUzELMAkGA1UECBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVU aGUgVVNFUlRSVVNUIE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2 MDQGA1UEAxMtVVROLVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsAhAv lStUS1saxfCiWQ0fZPKfMIHWBgsqhkiG9w0BCRACCzGBxqCBwzCBrjELMAkGA1UEBhMCVVMxCzAJ BgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVT VCBOZXR3b3JrMSEwHwYDVQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVU Ti1VU0VSRmlyc3QtQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbAIQL5UrVEtbGsXwolkN H2TynzANBgkqhkiG9w0BAQEFAASCAQBUpGXGzy7VevZyRcn7KPWWcwlKzSCr1tQsWzGpzD6MHw2E Ja7MQ4U5jM1WcW0k+v8V/x24mP7+s5iDUBpvVU2sy2Jr/de6jyCbgsOTmk7yKEI/die3lTSUsmKu 7YLzCmjeQVsijxZaBpFIWGSC8d+M99CwAJgFen/gpBGvvQJFlUnKZ4NaKDBfkof+jGRUGMyXc3qo uufSCTCHhWXYc1e610scGNDXWKnZzdws15APHc/6F2qWWEJyHojjZV37y6FqMzyuVQvaSve7F+Mn 9HpjJKcpzPhaRMxbb/wGyM7yokTkspFyiZPNsfU6bHcHttYXIJw8+HO4B0POxfQgEv4qAAAAAAAA --Apple-Mail-53-531720349-- From john.elwell@siemens-enterprise.com Mon Apr 27 06:21:49 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3C2093A69FA for ; Mon, 27 Apr 2009 06:21:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.724 X-Spam-Level: X-Spam-Status: No, score=-1.724 tagged_above=-999 required=5 tests=[AWL=-0.614, BAYES_05=-1.11] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CgopCzS5uk+J for ; Mon, 27 Apr 2009 06:21:48 -0700 (PDT) Received: from mailgate.siemenscomms.co.uk (mailgate.siemenscomms.co.uk [195.171.110.225]) by core3.amsl.com (Postfix) with ESMTP id 51D8A3A6917 for ; Mon, 27 Apr 2009 06:21:48 -0700 (PDT) Received: from GBNTHT12009MSX.gb002.siemens.net ([137.223.219.235]) by siemenscomms.co.uk (PMDF V6.3-x14 #31430) with ESMTP id <0KIR00HELH5PSE@siemenscomms.co.uk> for sipcore@ietf.org; Mon, 27 Apr 2009 14:23:05 +0100 (BST) Date: Mon, 27 Apr 2009 14:22:40 +0100 From: "Elwell, John" To: SIPCORE Message-id: <0D5F89FAC29E2C41B98A6A762007F5D001D4A39A@GBNTHT12009MSX.gb002.siemens.net> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: quoted-printable Thread-Topic: Question on Require in responses Thread-Index: AcnHOz10mtM4qRUIQZW9Hj1RGKNVvQ== Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: Subject: [sipcore] Question on Require in responses X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Apr 2009 13:21:49 -0000 What is the meaning of the Require header field in responses (in general - not the specific use in RFC 3262)? The table in section 20 of RFC 3261 does not limit the field to requests, but the description in 20.32 only describes meaning for the field when used in requests. John From pkyzivat@cisco.com Mon Apr 27 06:32:27 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 94E3B3A6F6A for ; Mon, 27 Apr 2009 06:32:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.036 X-Spam-Level: X-Spam-Status: No, score=-6.036 tagged_above=-999 required=5 tests=[AWL=0.563, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MteuR4MPYRjT for ; Mon, 27 Apr 2009 06:32:26 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id C803228C119 for ; Mon, 27 Apr 2009 06:31:27 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,254,1238976000"; d="scan'208";a="293591081" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 27 Apr 2009 13:32:48 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id n3RDWmCJ016633; Mon, 27 Apr 2009 06:32:48 -0700 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id n3RDWlKH023790; Mon, 27 Apr 2009 13:32:48 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 27 Apr 2009 09:32:48 -0400 Received: from [161.44.174.156] ([161.44.174.156]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 27 Apr 2009 09:32:47 -0400 Message-ID: <49F5B3FE.8030104@cisco.com> Date: Mon, 27 Apr 2009 09:32:46 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: "Elwell, John" References: <0D5F89FAC29E2C41B98A6A762007F5D001D4A39A@GBNTHT12009MSX.gb002.siemens.net> In-Reply-To: <0D5F89FAC29E2C41B98A6A762007F5D001D4A39A@GBNTHT12009MSX.gb002.siemens.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 27 Apr 2009 13:32:47.0737 (UTC) FILETIME=[A7685E90:01C9C73C] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=808; t=1240839168; x=1241703168; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[sipcore]=20Question=20on=20Require=20i n=20responses |Sender:=20; bh=0S0GYh0ac/vPV7KGt+RwPHGmMW602Gp49TTVK+B0By8=; b=l/jOhvhu8s003uTRYKqFij41JEnSum1uRx82TmayvY1Jieu8WGunSu0DGY hl8tv2FEqbq86i8tx5uWAsZ1RgKNEXuUxCAI8uXI2xXu/zuP2RdK/gEzltn9 aLiEdRjA9X; Authentication-Results: sj-dkim-4; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Cc: SIPCORE Subject: Re: [sipcore] Question on Require in responses X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Apr 2009 13:32:27 -0000 John, I don't have a general answer for you. IMO the answer to this is closely related to the definition of the scope of the negotiated agreement, which AFAIK is never defined in a general way, but may be defined for certain options. As a example, 3262 defines the use of Require:100rel in responses. Thanks, Paul Elwell, John wrote: > What is the meaning of the Require header field in responses (in general > - not the specific use in RFC 3262)? > > The table in section 20 of RFC 3261 does not limit the field to > requests, but the description in 20.32 only describes meaning for the > field when used in requests. > > John > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From mary.barnes@nortel.com Mon Apr 27 06:34:33 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C7D643A6F7E for ; Mon, 27 Apr 2009 06:34:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.468 X-Spam-Level: X-Spam-Status: No, score=-6.468 tagged_above=-999 required=5 tests=[AWL=0.131, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Svpwrf+SpnKA for ; Mon, 27 Apr 2009 06:34:32 -0700 (PDT) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id 546C73A6E7D for ; Mon, 27 Apr 2009 06:34:32 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id n3RDZ0c06869; Mon, 27 Apr 2009 13:35:00 GMT 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: Mon, 27 Apr 2009 08:37:44 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF1DAA242B@zrc2hxm0.corp.nortel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] Target URI and History Info bis Thread-Index: AcnFHVnNRSw1PA4EQmW33ETABtXuQwAANVhwAHiapTAADr0MEA== References: <49F178CE.8000809@ericsson.com> <49F22443.7010706@gmail.com> <1ECE0EB50388174790F9694F77522CCF1DA43F5F@zrc2hxm0.corp.nortel.com> From: "Mary Barnes" To: "Christer Holmberg" , "Hans Erik van Elburg" , "Gonzalo Camarillo" Cc: SIPCORE Subject: Re: [sipcore] Target URI and History Info bis X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Apr 2009 13:34:33 -0000 Christer, Based on your response in the first paragraph, I'm not sure I understand your second question, since you seem to be agreeing with the approach I've been suggesting in terms of putting the normative text to support the requirements and use cases identified in the target-uri in 4244bis. As far as my email response below, I'm not so much saying that the target-uri draft currently doesn't work with 4244, so much as that the current solution in terms of normative History-Info text is incomplete. In my opinion, to add enough text to make that solution complete, and alter the normative text for the Privacy header to ensure you actually get the headers, requires bringing in additional text for context from 4244. In the end you would need to at least "update" 4244, so my suggestion is to start with 4244bis now and save ourselves some pain down the road. So, I'm disagreeing with the suggestion that it is so much faster to progress target-uri than 4244bis. Mary.=20 -----Original Message----- From: Christer Holmberg [mailto:christer.holmberg@ericsson.com]=20 Sent: Monday, April 27, 2009 1:29 AM To: Barnes, Mary (RICH2:AR00); Hans Erik van Elburg; Gonzalo Camarillo Cc: SIPCORE Subject: RE: [sipcore] Target URI and History Info bis Hi, I can't remember that, when we agreed to use H-I for target delivery, a "precondition" would have been that we also must update 4244. I DO support the work on 4244bis, but that is a separate issue. Mary, could you please re-indicate why the target-uri draft doesn't work with 4244? Regards, Christer =20 > -----Original Message----- > From: sipcore-bounces@ietf.org > [mailto:sipcore-bounces@ietf.org] On Behalf Of Mary Barnes > Sent: 24. huhtikuuta 2009 23:55 > To: Hans Erik van Elburg; Gonzalo Camarillo > Cc: SIPCORE > Subject: Re: [sipcore] Target URI and History Info bis >=20 > Just to re-iterate once more, 4244bis already contains a superset of=20 > the normative text for History-Info header from the current target-uri > document. Francois has proposed a fairly straightforward path for=20 > 4244bis that should allow us to avoid any of the hurdles and open=20 > ended debates as to History-Info issues - the known issues are quite=20 > straight-forward to solve and the issues at hand really are providing=20 > a solution for target-uri. The idea that the target-uri document=20 > would progress much quicker than 4244bis is a red herring - in=20 > particular based on my comments that you need more changes to 4244 to=20 > support target-uri than just the new tags. >=20 > Mary.=20 >=20 > -----Original Message----- > From: sipcore-bounces@ietf.org > [mailto:sipcore-bounces@ietf.org] On Behalf Of Hans Erik van Elburg > Sent: Friday, April 24, 2009 3:43 PM > To: Gonzalo Camarillo > Cc: SIPCORE > Subject: Re: [sipcore] Target URI and History Info bis >=20 > Lets finish the target-uri document first independently, before=20 > dragging it into another endless 4244bis discussion. > It can focus on the topic for which it was created. >=20 > If 4244bis can work on the other issues it seems to instantiated for=20 > and it is ready in time, we can always decide to merge the then=20 > provided target-uri solution in to 4244bis. >=20 > This would speed up the process as several people have expressed that=20 > they need the target-uri solution in due time. > The target-uri draft has a very clear scope, the 4244bis seems an open > ended attractor for History-Info issues... >=20 > Best Regards, > /Hans Erik >=20 > Gonzalo Camarillo wrote: > > Hi, > > > > discussions about the target URI and history info bis work > has focused >=20 > > too much on the historical background and not enough on the > best way > > to proceed with this work. I would like to have discussions > on what we >=20 > > think would be the best and fastest way to specify what needs to be=20 > > specified. > > > > Mary claims that having the following draft tackle both the > target URI >=20 > > issue and the revision of History Info would be the fastest and=20 > > cleanest way to be done with everything we want to specify. > > > > http://tools.ietf.org/html/draft-barnes-sip-rfc4244bis-00 > > > > Others claim that tackling the target URI issue in an independent=20 > > draft that does not depend on the revision of History info would be=20 > > the fastest way to proceed with the target URI issue. > > > >=20 > http://tools.ietf.org/html/draft-rosenberg-sip-target-uri-delivery-01 > > > > I would like to hear opinions on how we should proceed and why. I=20 > > would prefer to get reasons related to clearness of the=20 > > specifications, speed of the process, etc., instead of about the=20 > > historical background on these two drafts. > > > > Thanks, > > > > Gonzalo > > > > _______________________________________________ > > 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 >=20 From brett@broadsoft.com Mon Apr 27 06:58:35 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 44E573A6BF0 for ; Mon, 27 Apr 2009 06:58:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.987 X-Spam-Level: X-Spam-Status: No, score=-1.987 tagged_above=-999 required=5 tests=[AWL=0.612, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4yfzogogWvX9 for ; Mon, 27 Apr 2009 06:58:34 -0700 (PDT) Received: from smtp-out01.seaservers.net (smtp-out01.seaservers.net [72.37.232.66]) by core3.amsl.com (Postfix) with ESMTP id 456B83A6B12 for ; Mon, 27 Apr 2009 06:58:34 -0700 (PDT) Received: from mbx02.citservers.local ([172.16.98.24]) by casumhub01.citservers.local ([172.16.98.57]) with mapi; Mon, 27 Apr 2009 06:59:53 -0700 From: Brett Tate To: Eric Burger , SIPCORE Date: Mon, 27 Apr 2009 06:59:52 -0700 Thread-Topic: [sipcore] INFO Tables Thread-Index: AcnHK/GSjGe/FLNOT5mNrIUGExZWJAACAO8g Message-ID: <9B2A061A1137254BBE4F4B2CD843646A1117383B03@mbx02.citservers.local> References: <65A71093-A94E-4E5D-AFBA-B3C5963CEA47@standardstrack.com> In-Reply-To: <65A71093-A94E-4E5D-AFBA-B3C5963CEA47@standardstrack.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 Subject: Re: [sipcore] INFO Tables X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Apr 2009 13:58:35 -0000 Hi Eric, My prior comments concerning Table 1 appearing to be based upon RFC 2543 in= stead of RFC 3261 appears to still apply. The usage of "g" seems potential= ly outdated since discussed within RFC 2543 instead of RFC 3261; the same a= pplies to Via row usage concerning "(2)". Unsure if my "incorrectly refere= nced" comment still applies since I can't tell if you plan to remove or adj= ust "This table expands on tables 2 and 3 in [RFC3261]" which preceded Tabl= e 1. http://www.ietf.org/mail-archive/web/sip/current/msg26820.html Section 5.2 table: Missing table number in case you want to add one for ref= erence. Section 5.2 table: Since it appears to be the only request missing, I prefe= r REFER be shown unless the working group wants to pretend it doesn't exist= . Section 5.2 table: The last 3 rows of ACK should be "-" instead of "o". Section 5.2 table: Because of RFC 4320 and lack of use within 100, the 1xx = row should likely indicate optional for INVITE and dash for others. Section 5.2 table: Assuming that there is a reason for the last row, why is= INVITE less flexible than the other shown requests? Section 5.2 table: Concerning INFO 469, should it be include within the tab= le? If so, is Recv-Info mandatory? As previously mentioned, there are numerous locations where I prefer new/up= dated Recv-Info not be used because of race condition ambiguities; these in= clude ACK, PRACK, and PRACK 2xx. However if the working group doesn't thin= k such race conditions are a problem, leaving it is ok with me. Thanks, Brett > -----Original Message----- > From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behal= f > Of Eric Burger > Sent: Monday, April 27, 2009 7:32 AM > To: SIPCORE > Subject: [sipcore] INFO Tables >=20 > Please, please, please go over this table and make sure it is > correct. If I hear nothing now, yet people say stuff during WGLC or > later, we will not be happy. >=20 >=20 > Table 1: Summary of Header Fields > Header Where INFO > ------ ----- ---- > Accept R o > Accept-Encoding R o > Accept-Encoding 2xx o > Accept-Encoding 415 c > Accept-Language R o > Accept-Language 2xx o > Accept-Language 415 c > Allow R o > Allow 200 - > Allow 405 o > Allow-Events R o > Allow-Events r o > Authentication-Info 2xx o > Authorization R o > Call-ID gc m > Call-Info R o > Call-Info r o > Contact R - > Contact 1xx - > Contact 2xx - > Contact 3xx - > Contact 485 - > Content-Disposition e o > Content-Encoding e o > Content-Language e o > Content-Length e o > Content-Type e * > CSeq gc m > Date g o > Error-Info 3xx-6xx o > Expires g - > From gc m > Geolocation R o > Max-Breadth R - > Max-Forwards R o > MIME-Version R o > MIME-Version r o > Organization g o > Privacy R o > Proxy-Authenticate 407 o > Proxy-Authorization R o > Proxy-Require R o > Reason R o > Record-Route R o > Record-Route 2xx o > Require R o > Require r o > Retry-After R - > Retry-After 404,480,486 o > Retry-After 503 o > Retry-After 600,603 o > Route R o > Security-Client R o > Security-Server 421,494 o > Security-Verify R o > Server r o > Subject R o > Supported R o > Supported 2xx o > Timestamp g o > To gc(1) m > Unsupported 420 o > User-Agent g o > Via gc(2) m > Warning r o > WWW-Authenticate 401 o >=20 > 5.2. INFO Headers >=20 > This table expands on tables 2 and 3 in [RFC3261]. >=20 > Header field where ACK BYE CAN INV OPT REG PRA INF MSG UPD SUB NOT > -------------------------------------------------------------------- > Info-Package R - - - - - - - m - - - - > Recv-Info R o - - o o o o - - o - - > Recv-Info 2xx o - - o o - o - - o - - > Recv-Info 1xx o - - o o - o - - o - - > Recv-Info r o - - - o - o - - o - - From drage@alcatel-lucent.com Mon Apr 27 06:59:55 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B054D3A68AF for ; Mon, 27 Apr 2009 06:59:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.956 X-Spam-Level: X-Spam-Status: No, score=-5.956 tagged_above=-999 required=5 tests=[AWL=0.293, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZELJmpW6UPwg for ; Mon, 27 Apr 2009 06:59:54 -0700 (PDT) Received: from smail3.alcatel.fr (smail3.alcatel.fr [62.23.212.56]) by core3.amsl.com (Postfix) with ESMTP id 8E3AB28C151 for ; Mon, 27 Apr 2009 06:59:54 -0700 (PDT) Received: from FRMRSSXCHHUB04.dc-m.alcatel-lucent.com (FRMRSSXCHHUB04.dc-m.alcatel-lucent.com [135.120.45.64]) by smail3.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id n3RE1Axr016099 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 27 Apr 2009 16:01:10 +0200 Received: from FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com ([135.120.45.39]) by FRMRSSXCHHUB04.dc-m.alcatel-lucent.com ([135.120.45.64]) with mapi; Mon, 27 Apr 2009 16:01:10 +0200 From: "DRAGE, Keith (Keith)" To: Paul Kyzivat , "Elwell, John" Date: Mon, 27 Apr 2009 16:01:09 +0200 Thread-Topic: [sipcore] Question on Require in responses Thread-Index: AcnHPT08Ly6vmvGaQr2h6BzDL+jANwAAur9g Message-ID: <28B7C3AA2A7ABA4A841F11217ABE78D67590BF97@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> References: <0D5F89FAC29E2C41B98A6A762007F5D001D4A39A@GBNTHT12009MSX.gb002.siemens.net> <49F5B3FE.8030104@cisco.com> In-Reply-To: <49F5B3FE.8030104@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.57 on 155.132.188.83 Cc: SIPCORE Subject: Re: [sipcore] Question on Require in responses X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Apr 2009 13:59:55 -0000 But I think the essence of the question is that Require in requests is a co= mpatibility mechanism. As such, a receiver performs actions if it DOES NOT = understand the option tag. I would understand that the RFC 3262 usage is that the receiver performs NO= ACTION if it does not understand the option tag. Would it be reasonably to= assume that is a general usage of Require when received in responses.=20 regards Keith > -----Original Message----- > From: sipcore-bounces@ietf.org=20 > [mailto:sipcore-bounces@ietf.org] On Behalf Of Paul Kyzivat > Sent: Monday, April 27, 2009 2:33 PM > To: Elwell, John > Cc: SIPCORE > Subject: Re: [sipcore] Question on Require in responses >=20 > John, >=20 > I don't have a general answer for you. IMO the answer to this=20 > is closely related to the definition of the scope of the=20 > negotiated agreement, which AFAIK is never defined in a=20 > general way, but may be defined for certain options. >=20 > As a example, 3262 defines the use of Require:100rel in responses. >=20 > Thanks, > Paul >=20 > Elwell, John wrote: > > What is the meaning of the Require header field in responses (in=20 > > general > > - not the specific use in RFC 3262)? > >=20 > > The table in section 20 of RFC 3261 does not limit the field to=20 > > requests, but the description in 20.32 only describes=20 > meaning for the=20 > > field when used in requests. > >=20 > > John > > _______________________________________________ > > 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 brett@broadsoft.com Mon Apr 27 07:18:01 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AD0343A68FD for ; Mon, 27 Apr 2009 07:18:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.011 X-Spam-Level: X-Spam-Status: No, score=-2.011 tagged_above=-999 required=5 tests=[AWL=0.588, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rI20UYKnOqtL for ; Mon, 27 Apr 2009 07:18:01 -0700 (PDT) Received: from smtp-out01.seaservers.net (smtp-out01.seaservers.net [72.37.232.66]) by core3.amsl.com (Postfix) with ESMTP id D01503A6EE2 for ; Mon, 27 Apr 2009 07:17:01 -0700 (PDT) Received: from mbx02.citservers.local ([172.16.98.24]) by casumhub01.citservers.local ([172.16.98.57]) with mapi; Mon, 27 Apr 2009 07:18:20 -0700 From: Brett Tate To: "Elwell, John" , SIPCORE Date: Mon, 27 Apr 2009 07:18:21 -0700 Thread-Topic: Question on Require in responses Thread-Index: AcnHOz10mtM4qRUIQZW9Hj1RGKNVvQABv83w Message-ID: <9B2A061A1137254BBE4F4B2CD843646A1117383B14@mbx02.citservers.local> References: <0D5F89FAC29E2C41B98A6A762007F5D001D4A39A@GBNTHT12009MSX.gb002.siemens.net> In-Reply-To: <0D5F89FAC29E2C41B98A6A762007F5D001D4A39A@GBNTHT12009MSX.gb002.siemens.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 Subject: Re: [sipcore] Question on Require in responses X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Apr 2009 14:18:01 -0000 The following is a snippet from RFC 3261 section 8.2.4:=20 "Any extensions applied to a non-421 response MUST be listed in a Require h= eader field included in the response. Of course, the server MUST NOT apply= extensions not listed in the Supported header field in the request." > -----Original Message----- > From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behal= f > Of Elwell, John > Sent: Monday, April 27, 2009 9:23 AM > To: SIPCORE > Subject: [sipcore] Question on Require in responses >=20 >=20 > What is the meaning of the Require header field in responses (in general > - not the specific use in RFC 3262)? >=20 > The table in section 20 of RFC 3261 does not limit the field to > requests, but the description in 20.32 only describes meaning for the > field when used in requests. >=20 > John From pkyzivat@cisco.com Mon Apr 27 07:34:29 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9A9DD3A6B72 for ; Mon, 27 Apr 2009 07:34:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.448 X-Spam-Level: X-Spam-Status: No, score=-5.448 tagged_above=-999 required=5 tests=[AWL=-0.049, BAYES_00=-2.599, J_CHICKENPOX_73=0.6, J_CHICKENPOX_93=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k95uDrjds-N8 for ; Mon, 27 Apr 2009 07:34:28 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id A86FA3A67CF for ; Mon, 27 Apr 2009 07:34:28 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,254,1238976000"; d="scan'208";a="159269087" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-2.cisco.com with ESMTP; 27 Apr 2009 14:35:49 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id n3REZnRv029790; Mon, 27 Apr 2009 07:35:49 -0700 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id n3REZjTW014650; Mon, 27 Apr 2009 14:35:49 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 27 Apr 2009 10:35:49 -0400 Received: from [161.44.174.156] ([161.44.174.156]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Mon, 27 Apr 2009 10:35:48 -0400 Message-ID: <49F5C2C4.70501@cisco.com> Date: Mon, 27 Apr 2009 10:35:48 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: "DRAGE, Keith (Keith)" References: <0D5F89FAC29E2C41B98A6A762007F5D001D4A39A@GBNTHT12009MSX.gb002.siemens.net> <49F5B3FE.8030104@cisco.com> <28B7C3AA2A7ABA4A841F11217ABE78D67590BF97@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> In-Reply-To: <28B7C3AA2A7ABA4A841F11217ABE78D67590BF97@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 27 Apr 2009 14:35:48.0761 (UTC) FILETIME=[7512D890:01C9C745] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3527; t=1240842949; x=1241706949; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[sipcore]=20Question=20on=20Require=20i n=20responses |Sender:=20; bh=Ralh4LKPeEh2YQcC41pr/UYU7ds2JdOETxsNNcXJuho=; b=bRBc6oI6SW6K0uqoo3Fsl6Yaj+mobO11G9UNoouITSCZY+OWgLsyDguBve 7AHOxs/PpuHCogquUih5LRaTd/TvplKSzKtEqlxPZgEHoUWaeSOADZVeMLJu 6dzG00WL0N; Authentication-Results: sj-dkim-3; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Cc: SIPCORE Subject: Re: [sipcore] Question on Require in responses X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Apr 2009 14:34:29 -0000 Keith, I don't think I understand the point you are making. DRAGE, Keith (Keith) wrote: > But I think the essence of the question is that Require in requests is a compatibility mechanism. > As such, a receiver performs actions if it DOES NOT understand the option tag. That is at least *part* of the behavior for Require. Nominally its definition was carried over from http, and it only required behavior of the recipient for the one request. In that view it would make no sense in responses. But the usage and behavior has been overloaded for particular event types. > I would understand that the RFC 3262 usage is that the receiver performs NO ACTION > if it does not understand the option tag. If there is Require:100rel in a request, and the UAS doesn't understand it, then it will return a 420 response. If it receives Supported:100rel, and doesn't understand it, then it ignores it. If it receives Require:100rel and *does* understand it, then it is supposed to do something. And among the things it is supposed to do is to include Require:100rel in provisional responses. > Would it be reasonably to assume that is a general usage of Require when received in responses. Presumably, if the UAC included Supported:foo or Require:foo in a request, then it ought to understand if it receives Require:foo in a response to that request. So it ought not *ignore* it. But what it ought to do isn't defined generically. Presumably it ought to do whatever the specification of the foo event says it should do. If the UAC didn't indicate support for, and doesn't understand, the foo option, then what should it do if it receives Require:foo in a response? It can't do as the UAS would, and return a 420 to indicate its lack of support. So I guess it only has a couple of choices: - ignore it - tear down the session. But that doesn't really answer the question of what the *meaning* of a Require header in a response is. I think the answer must be "the meaning is defined on an opion-specific basis". That's not very satisfying. Overloading the behavior was, IMO, a mistake. But that is where we are. Thanks, Paul > regards > > Keith > >> -----Original Message----- >> From: sipcore-bounces@ietf.org >> [mailto:sipcore-bounces@ietf.org] On Behalf Of Paul Kyzivat >> Sent: Monday, April 27, 2009 2:33 PM >> To: Elwell, John >> Cc: SIPCORE >> Subject: Re: [sipcore] Question on Require in responses >> >> John, >> >> I don't have a general answer for you. IMO the answer to this >> is closely related to the definition of the scope of the >> negotiated agreement, which AFAIK is never defined in a >> general way, but may be defined for certain options. >> >> As a example, 3262 defines the use of Require:100rel in responses. >> >> Thanks, >> Paul >> >> Elwell, John wrote: >>> What is the meaning of the Require header field in responses (in >>> general >>> - not the specific use in RFC 3262)? >>> >>> The table in section 20 of RFC 3261 does not limit the field to >>> requests, but the description in 20.32 only describes >> meaning for the >>> field when used in requests. >>> >>> John >>> _______________________________________________ >>> 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 john.elwell@siemens-enterprise.com Mon Apr 27 07:34:54 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5D3483A6C7A for ; Mon, 27 Apr 2009 07:34:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.451 X-Spam-Level: X-Spam-Status: No, score=-2.451 tagged_above=-999 required=5 tests=[AWL=0.148, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cqWsqkzH8X1c for ; Mon, 27 Apr 2009 07:34:53 -0700 (PDT) Received: from mailgate.siemenscomms.co.uk (mailgate.siemenscomms.co.uk [195.171.110.225]) by core3.amsl.com (Postfix) with ESMTP id 8DB5D3A6BC2 for ; Mon, 27 Apr 2009 07:34:53 -0700 (PDT) Received: from GBNTHT12009MSX.gb002.siemens.net ([137.223.219.235]) by siemenscomms.co.uk (PMDF V6.3-x14 #31430) with ESMTP id <0KIR00M1XKAYVB@siemenscomms.co.uk> for sipcore@ietf.org; Mon, 27 Apr 2009 15:31:16 +0100 (BST) Date: Mon, 27 Apr 2009 15:30:41 +0100 From: "Elwell, John" In-reply-to: <9B2A061A1137254BBE4F4B2CD843646A1117383B14@mbx02.citservers.local> To: Brett Tate , SIPCORE Message-id: <0D5F89FAC29E2C41B98A6A762007F5D001D4A44A@GBNTHT12009MSX.gb002.siemens.net> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: quoted-printable Thread-Topic: Question on Require in responses Thread-Index: AcnHOz10mtM4qRUIQZW9Hj1RGKNVvQABv83wAACQXOA= Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <0D5F89FAC29E2C41B98A6A762007F5D001D4A39A@GBNTHT12009MSX.gb002.siemens.net> <9B2A061A1137254BBE4F4B2CD843646A1117383B14@mbx02.citservers.local> Subject: Re: [sipcore] Question on Require in responses X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Apr 2009 14:34:54 -0000 Brett, Thanks, that seems to help. It is a pity 20.32 doesn't mention this extended meaning of the Require header field. John=20 > -----Original Message----- > From: Brett Tate [mailto:brett@broadsoft.com]=20 > Sent: 27 April 2009 15:18 > To: Elwell, John; SIPCORE > Subject: RE: Question on Require in responses >=20 > The following is a snippet from RFC 3261 section 8.2.4:=20 >=20 > "Any extensions applied to a non-421 response MUST be listed=20 > in a Require header field included in the response. Of=20 > course, the server MUST NOT apply extensions not listed in=20 > the Supported header field in the request." >=20 >=20 > > -----Original Message----- > > From: sipcore-bounces@ietf.org=20 > [mailto:sipcore-bounces@ietf.org] On Behalf > > Of Elwell, John > > Sent: Monday, April 27, 2009 9:23 AM > > To: SIPCORE > > Subject: [sipcore] Question on Require in responses > >=20 > >=20 > > What is the meaning of the Require header field in=20 > responses (in general > > - not the specific use in RFC 3262)? > >=20 > > The table in section 20 of RFC 3261 does not limit the field to > > requests, but the description in 20.32 only describes=20 > meaning for the > > field when used in requests. > >=20 > > John >=20 >=20 From adam@nostrum.com Mon Apr 27 08:59:22 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 30B6328C107 for ; Mon, 27 Apr 2009 08:59:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.522 X-Spam-Level: X-Spam-Status: No, score=-1.522 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_21=0.6, SPF_PASS=-0.001, WHOIS_DMNBYPROXY=0.478] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jeSKy5kdEKsD for ; Mon, 27 Apr 2009 08:59:13 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id 623D128C0DE for ; Mon, 27 Apr 2009 08:59:12 -0700 (PDT) Received: from [25.233.126.67] (m690e36d0.tmodns.net [208.54.14.105]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id n3RFxEGm001031 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 27 Apr 2009 10:59:29 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <49F5D64B.20008@nostrum.com> Date: Mon, 27 Apr 2009 10:59:07 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1b3pre) Gecko/20090223 Lightning/1.0pre Thunderbird/3.0b2 MIME-Version: 1.0 To: Dean Willis References: <49F178CE.8000809@ericsson.com> <0ECC036E-2B21-49D5-AC42-1FEC8EC447BE@softarmor.com> In-Reply-To: <0ECC036E-2B21-49D5-AC42-1FEC8EC447BE@softarmor.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 208.54.14.105 is authenticated by a trusted mechanism) Cc: SIPCORE Subject: Re: [sipcore] Long reply to: Target URI and History Info bis X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Apr 2009 15:59:22 -0000 [as a participant] Dean: You've described about half the requirements (getting parameters from a UAC to a UAS). There is a complementary, and just as important, set of requirements we need to keep in mind: getting the parameters to the UAC in the first place. I'll use your analogy. While it's possible, it's not very likely that you manually typed "http://tools.ietf.org/rfcdiff?url1=http://tools.ietf.org/id/draft-ietf-sipcore-subnot-etags-00.txt&url2=http://tools.ietf.org/id/draft-ietf-sipcore-subnot-etags-02.txt " into a web browser somewhere. In all likelihood, that was generated programmatically by some web application, and sent to your browser in an HTML body somewhere. In SIP, of course, we don't have HTML bodies. We have Contact header fields, Refer-To header fields, information in UA profiles, and a large number of similar constructs. They uniformly contain SIP URIs. So, for the other half of this puzzle, we need to make sure that the parameters you're talking about can be expressed as part of a SIP URI, so that they can be communicated to the UAC in the first place. /a Dean Willis wrote: > On Apr 24, 2009, at 3:31 AM, Gonzalo Camarillo wrote: > >> Hi, >> >> discussions about the target URI and history info bis work has >> focused too much on the historical background and not enough on the >> best way to proceed with this work. I would like to have discussions >> on what we think would be the best and fastest way to specify what >> needs to be specified. > > > I'd like to take this back to getting a clear statement on what needs > to be SOLVED, rather than what needs to be specified. I strongly > suspect we have lost track of our mission as we progressed through the > vast labyrinth of complexity that litters our back-trail. > > So let's go back to the fundamental problem and see if we can regain > consensus on what we're trying to fix. > > One model of application structure derives from the way that HTTP CGI > applications are written. In this model, the request-URI encodes not > only the target (in this case, the application), but also any > parameters being delivered to the application. > > For example, let's take the expansion of a URL I recently sent to the > sipcore list: > > http://snurl.com/ghlt8 > > which expands into (yes, the lines are going to get wrapped by the > email system) > > http://tools.ietf.org/rfcdiff?url1=http://tools.ietf.org/id/draft-ietf-sipcore-subnot-etags-00.txt&url2=http://tools.ietf.org/id/draft-ietf-sipcore-subnot-etags-02.txt > > > > Here the application-identifying portion of the URL is > "http://tools.ietf.org/rfcdiff". The first parameter is > "url1=http://tools.ietf.org/id/draft-ietf-sipcore-subnot-etags-00.txt" > and the second is > "url2=http://tools.ietf.org/id/draft-ietf-sipcore-subnot-etags-02.txt". The > application (which you can exercise with a browser) generates a > side-by-side diff of the two IETF-style documents referenced by the > URLs that are sent as parameters. > > In SIP, we might encode the parameters onto the request URI slightly > differently, but the same basic approach applies. This philosophy of > application design is described in RFC 3087. > > This approach works very nicely for SIP applications that are directly > addressable. RFC 2543 broke it for any SIP applications that required > traversing a proxy to reach the application, because RFC 2543 rather > stupidly (and yes, I complained about it at the time) rewrote the > request-URI on every proxy hop. We sort of fixed this in RFC 3261 with > "loose routing", but it was STILL broken for any target that used > "contact routing", that is, where the contact stored by a registrar > replaced the AOR in the request URI. > > This defect made URI application and parameter encoding useless for > most user-to-user applications, because somewhere in there, a > contact-routing proxy is probably going to replace the request-URI and > break things. > > Jonathan's ua-loose-route draft was an attempt to fix the problem by > making SIP proxies stop rewriting the request URI entirely. We thought > this wasn't all that backward compatible (it's hard to be backward > compatible with something that's pretty much broken), so it didn't > make the cut. We've also proposed that the destination might be able > to retrieve the original URI and parameters from the seething mass of > History-Info entries and parameters, but that's also unappetizing in > certain respects. > > So what was the original goal again? We're trying to convey, from UAC > to UAS enough information about an application to enable the UAS to > select the correct application and pass the request to that > application, along with any parameters supplied by the UAC. And we're > trying to do this in a way that survives all sorts of proxy > processing, It doesn't have to survive redirect processing, UNLESS a > proxy acts on the redirect on behalf of the UAC. And we're trying to > do it in a way that doesn't require extending the SIP specification > for every new application, because even though we know our layering > model is all messed up, we don't really want to make it exponentially > worse. > > This basic problem of "application invocation" keeps coming up again > and again. The whole service-indicator context-guessing thing is tied > up in it. Explicit service indicators encoded as SIP extensions are > VERY VERY BAD, because they tie the SIP protocol to the application in > ways that keep requiring us to extend SIP to support new applications. > Consider what would have happened to the world wide web if it required > an HTTP extension for every new web application. Going down that path > would be profoundly stupid, which we mostly know and have been trying > to avoid. > > We've further complicated the problem with the idea that maybe > middleboxes (ala proxies or SBCs) might need to "meddle" with the > application-to-application information. The main problem here is that > there are really two sorts of applications: those in the middle, that > operate by rewriting the app-to-app information, and those on the > ends, that rely on pristine app-to-app information. Prevent > interactions between these two sorts of applications is IMPOSSIBLE, as > their scopes, by definition, overlap. > > > Consider for example the interaction of a speed-dial application with > a voicemail application. The speed dial application might take > "sip:6@softarmor.com", when the authenticated user is > "dean.willis@softarmor.com", and translate it to > "sip:voicemail-dean@softarmor.com". This works fine -- it;s an easy > string replacement at the proxy, we can code it in CPL, and so on. > > But assume that the voice-mail application needs parameters For > example, let's say that it has "record" and "play" modalities, and > "sip:voicemail-dean@softarmor.com&play" tells it to play my messages, > whereas "sip:voicemail-dean@softarmor.com&record" tells it to record a > new greeting. Barring subtle variations on parameter-encoding > separators (we're still arguing about how that works), this is easy to > implement in a voice-mail server. But the speed-dial application is > going to break it. Trying to figure out which, if any, parameters need > to be copied from the incoming request-URI and into the outgoing > request-URI is difficult. Given that we've encoded some of the > application context in the user-part (voicemail-dean vs > voicemail-alice) , the problem is an even bigger furball. > > > So here's my suggestion: Let's stop arguing about history-info, > ua-loose-route, diversion, etc. and go back to the REAL underlying > problem: How, in a consistent, predictable, and programmable way, do > we pass application context from UAC to UAS? And we need to pay > attention to the inversely-related question: What limitations do we > allow the transport-support mechanism (proxies, sbcs, whatever) do we > expect to place on the expressive range of this mechanism? > > Here's a hint: HTTP clearly defines what the transport-support > mechanisms (proxies) can and cannot do. With HTTPS proxies, they can't > do much except convey the info end to end. So HTTP applications can > use request URI for parameter passing, they can use SOAP, they can use > AJAX to funnel XML back-and-forth over a long lived connection, and so > on. HTTP applications can do all this without adding new HTTP methods, > new HTTP headers, new HTTP request types, and so on. So the HTTP model > is, I argue "That which is not reserved to the HTTP protocol is > available to the application". > > What's the SIP model? Is it possible to define one that is backward > compatible with the hash we've made of our applications space with all > these app-specific functions in our transport protocol? > > > -- > Dean > > > > > > > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From dean.willis@softarmor.com Mon Apr 27 12:43:49 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 233D93A6D53 for ; Mon, 27 Apr 2009 12:43:49 -0700 (PDT) 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.047, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9GJzVXbHDEbi for ; Mon, 27 Apr 2009 12:43:48 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 4B0493A69CB for ; Mon, 27 Apr 2009 12:43:48 -0700 (PDT) Received: from [192.168.2.102] (cpe-72-181-150-177.tx.res.rr.com [72.181.150.177]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id n3RJj4Cd007024 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 27 Apr 2009 14:45:06 -0500 Message-Id: From: Dean Willis To: Adam Roach In-Reply-To: <49F5D64B.20008@nostrum.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Mon, 27 Apr 2009 14:44:59 -0500 References: <49F178CE.8000809@ericsson.com> <0ECC036E-2B21-49D5-AC42-1FEC8EC447BE@softarmor.com> <49F5D64B.20008@nostrum.com> X-Mailer: Apple Mail (2.930.3) Cc: SIPCORE Subject: Re: [sipcore] Long reply to: Target URI and History Info bis X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Apr 2009 19:43:49 -0000 On Apr 27, 2009, at 10:59 AM, Adam Roach wrote: > > So, for the other half of this puzzle, we need to make sure that the > parameters you're talking about can be expressed as part of a SIP > URI, so that they can be communicated to the UAC in the first place. > Ah, but they can. It's not any harder than doing it with HTTP. We just don't use it much since it doesn't work well due to contact-routing. Instead, we use all sorts of ugly hacks with new SIP headers and protocol extensions. That's why SIP WG never had a charter item on expressing the parameters as part of the URI, just on fixing the transport mechanism. -- Dean From adam@nostrum.com Mon Apr 27 13:43:46 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AB56B3A69C4 for ; Mon, 27 Apr 2009 13:43:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.577 X-Spam-Level: X-Spam-Status: No, score=-2.577 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599, SPF_PASS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id smE6U8VeQ4Bd for ; Mon, 27 Apr 2009 13:43:46 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id A91543A6A79 for ; Mon, 27 Apr 2009 13:43:45 -0700 (PDT) Received: from [172.16.3.231] (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id n3RKj2LZ023014 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 27 Apr 2009 15:45:02 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <49F6194E.40006@nostrum.com> Date: Mon, 27 Apr 2009 15:45:02 -0500 From: Adam Roach User-Agent: Postbox 1.0b11 (Macintosh/2009041623) MIME-Version: 1.0 To: Dean Willis References: <49F178CE.8000809@ericsson.com> <0ECC036E-2B21-49D5-AC42-1FEC8EC447BE@softarmor.com> <49F5D64B.20008@nostrum.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Cc: SIPCORE Subject: Re: [sipcore] Long reply to: Target URI and History Info bis X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Apr 2009 20:43:46 -0000 Dean Willis wrote: > > On Apr 27, 2009, at 10:59 AM, Adam Roach wrote: >> >> So, for the other half of this puzzle, we need to make sure that the >> parameters you're talking about can be expressed as part of a SIP URI, >> so that they can be communicated to the UAC in the first place. >> > > Ah, but they can. With the mechanisms under discussion, yes, they can. But you stripped it down to base principles. Your summary missed this aspect of the problem. I could easily design mechanisms that meet the requirements you state, but would be cumbersome to encode in a URI (e.g., encoding parameters in request body, a la HTTP POST requests). I just want to make certain that we don't end up taking things in that direction. /a From drage@alcatel-lucent.com Mon Apr 27 14:22:59 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 593E63A6933 for ; Mon, 27 Apr 2009 14:22:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.36 X-Spam-Level: X-Spam-Status: No, score=-5.36 tagged_above=-999 required=5 tests=[AWL=-0.311, BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_73=0.6, J_CHICKENPOX_93=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m3OuF5+GKMER for ; Mon, 27 Apr 2009 14:22:58 -0700 (PDT) Received: from smail3.alcatel.fr (smail3.alcatel.fr [62.23.212.56]) by core3.amsl.com (Postfix) with ESMTP id E01863A680D for ; Mon, 27 Apr 2009 14:22:57 -0700 (PDT) Received: from FRMRSSXCHHUB04.dc-m.alcatel-lucent.com (FRMRSSXCHHUB04.dc-m.alcatel-lucent.com [135.120.45.64]) by smail3.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id n3RLO9h0019104 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 27 Apr 2009 23:24:09 +0200 Received: from FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com ([135.120.45.39]) by FRMRSSXCHHUB04.dc-m.alcatel-lucent.com ([135.120.45.64]) with mapi; Mon, 27 Apr 2009 23:24:09 +0200 From: "DRAGE, Keith (Keith)" To: Paul Kyzivat Date: Mon, 27 Apr 2009 23:24:07 +0200 Thread-Topic: [sipcore] Question on Require in responses Thread-Index: AcnHRYB8SwhX/QbSTdO+yOaFUuchXQANtpZA Message-ID: <28B7C3AA2A7ABA4A841F11217ABE78D67590C063@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> References: <0D5F89FAC29E2C41B98A6A762007F5D001D4A39A@GBNTHT12009MSX.gb002.siemens.net> <49F5B3FE.8030104@cisco.com> <28B7C3AA2A7ABA4A841F11217ABE78D67590BF97@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <49F5C2C4.70501@cisco.com> In-Reply-To: <49F5C2C4.70501@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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 155.132.188.83 Cc: SIPCORE Subject: Re: [sipcore] Question on Require in responses X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Apr 2009 21:22:59 -0000 I wrote: > I would understand that the RFC 3262 usage is that the receiver=20 > performs NO ACTION if it does not understand the option tag. In this I was specifically referring to the response usage, and not to the = request usage, but forgot to say so.=20 Paul wrote, and I think managed to answer my question in doing so: > If the UAC didn't indicate support for, and doesn't=20 > understand, the foo option, then what should it do if it=20 > receives Require:foo in a response?=20 > It can't do as the UAS would, and return a 420 to indicate=20 > its lack of support. So I guess it only has a couple of choices: > - ignore it > - tear down the session. > > But that doesn't really answer the question of what the=20 > *meaning* of a Require header in a response is. I think the=20 > answer must be "the meaning is defined on an opion-specific basis". >=20 > That's not very satisfying. Overloading the behavior was,=20 > IMO, a mistake. But that is where we are. >=20 Which is essentially saying there is no possible action on an option-unspec= ific basis, which is where I was hoping we would get to, i.e. ignore. But I wanted to make sure because this is overloaded. Anyone want to vote for tear down the session instead? Anyone think this is worthy of a correction to add that the above understan= ding? regards Keith > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com]=20 > Sent: Monday, April 27, 2009 3:36 PM > To: DRAGE, Keith (Keith) > Cc: Elwell, John; SIPCORE > Subject: Re: [sipcore] Question on Require in responses >=20 > Keith, >=20 > I don't think I understand the point you are making. >=20 > DRAGE, Keith (Keith) wrote: > > But I think the essence of the question is that Require in=20 > requests is a compatibility mechanism. > > As such, a receiver performs actions if it DOES NOT=20 > understand the option tag. >=20 > That is at least *part* of the behavior for Require. > Nominally its definition was carried over from http, and it=20 > only required behavior of the recipient for the one request.=20 > In that view it would make no sense in responses. >=20 > But the usage and behavior has been overloaded for particular=20 > event types. >=20 > > I would understand that the RFC 3262 usage is that the receiver=20 > > performs NO ACTION if it does not understand the option tag. >=20 > If there is Require:100rel in a request, and the UAS doesn't=20 > understand it, then it will return a 420 response. >=20 > If it receives Supported:100rel, and doesn't understand it,=20 > then it ignores it. >=20 > If it receives Require:100rel and *does* understand it, then=20 > it is supposed to do something. And among the things it is=20 > supposed to do is to include Require:100rel in provisional responses. >=20 > > Would it be reasonably to assume that is a general usage of=20 > Require when received in responses.=20 >=20 > Presumably, if the UAC included Supported:foo or Require:foo=20 > in a request, then it ought to understand if it receives=20 > Require:foo in a response to that request. So it ought not=20 > *ignore* it. But what it ought to do isn't defined=20 > generically. Presumably it ought to do whatever the=20 > specification of the foo event says it should do. >=20 > If the UAC didn't indicate support for, and doesn't=20 > understand, the foo option, then what should it do if it=20 > receives Require:foo in a response?=20 > It can't do as the UAS would, and return a 420 to indicate=20 > its lack of support. So I guess it only has a couple of choices: > - ignore it > - tear down the session. >=20 > But that doesn't really answer the question of what the=20 > *meaning* of a Require header in a response is. I think the=20 > answer must be "the meaning is defined on an opion-specific basis". >=20 > That's not very satisfying. Overloading the behavior was,=20 > IMO, a mistake. But that is where we are. >=20 > Thanks, > Paul >=20 > > regards > >=20 > > Keith > >=20 > >> -----Original Message----- > >> From: sipcore-bounces@ietf.org > >> [mailto:sipcore-bounces@ietf.org] On Behalf Of Paul Kyzivat > >> Sent: Monday, April 27, 2009 2:33 PM > >> To: Elwell, John > >> Cc: SIPCORE > >> Subject: Re: [sipcore] Question on Require in responses > >> > >> John, > >> > >> I don't have a general answer for you. IMO the answer to this is=20 > >> closely related to the definition of the scope of the negotiated=20 > >> agreement, which AFAIK is never defined in a general way,=20 > but may be=20 > >> defined for certain options. > >> > >> As a example, 3262 defines the use of Require:100rel in responses. > >> > >> Thanks, > >> Paul > >> > >> Elwell, John wrote: > >>> What is the meaning of the Require header field in responses (in=20 > >>> general > >>> - not the specific use in RFC 3262)? > >>> > >>> The table in section 20 of RFC 3261 does not limit the field to=20 > >>> requests, but the description in 20.32 only describes > >> meaning for the > >>> field when used in requests. > >>> > >>> John > >>> _______________________________________________ > >>> 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 adam@nostrum.com Mon Apr 27 15:01:42 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CD34228C0FE for ; Mon, 27 Apr 2009 15:01:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.578 X-Spam-Level: X-Spam-Status: No, score=-2.578 tagged_above=-999 required=5 tests=[AWL=0.022, BAYES_00=-2.599, SPF_PASS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DO94CmuNDGh1 for ; Mon, 27 Apr 2009 15:01:42 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id 9EF2E3A6FBA for ; Mon, 27 Apr 2009 15:01:34 -0700 (PDT) Received: from [172.16.3.231] (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id n3RM2QvV028746 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 27 Apr 2009 17:02:26 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <49F62B72.1080606@nostrum.com> Date: Mon, 27 Apr 2009 17:02:26 -0500 From: Adam Roach User-Agent: Postbox 1.0b11 (Macintosh/2009041623) MIME-Version: 1.0 To: "DRAGE, Keith (Keith)" References: <0D5F89FAC29E2C41B98A6A762007F5D001D4A39A@GBNTHT12009MSX.gb002.siemens.net> <49F5B3FE.8030104@cisco.com> <28B7C3AA2A7ABA4A841F11217ABE78D67590BF97@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <49F5C2C4.70501@cisco.com> <28B7C3AA2A7ABA4A841F11217ABE78D67590C063@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> In-Reply-To: <28B7C3AA2A7ABA4A841F11217ABE78D67590C063@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Cc: SIPCORE Subject: Re: [sipcore] Question on Require in responses X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Apr 2009 22:01:42 -0000 DRAGE, Keith (Keith) wrote: > Anyone think this is worthy of a correction to add that the above understanding? Not unless we're going to add corrections for all the other bizzare, noncompliant, bone-headed things that implementations can get wrong. Personally, I don't think we need to get into the business of specifying things this far outside the realm of reasonable behavior -- we have much more pressing things to do with the limited RAI resources. But, if we go down this path, we'd better make it complete. I'd suggest starting by clarifying how a UAC reacts to a 700-class response. /a From dean.willis@softarmor.com Mon Apr 27 17:21:44 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BA3B33A696E for ; Mon, 27 Apr 2009 17:21:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.553 X-Spam-Level: X-Spam-Status: No, score=-2.553 tagged_above=-999 required=5 tests=[AWL=0.046, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3Ivq8qyWUh23 for ; Mon, 27 Apr 2009 17:21:44 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id F1C983A6835 for ; Mon, 27 Apr 2009 17:21:43 -0700 (PDT) Received: from [192.168.2.102] (cpe-72-181-150-177.tx.res.rr.com [72.181.150.177]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id n3S0MusV009031 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 27 Apr 2009 19:22:57 -0500 Message-Id: From: Dean Willis To: Brett Tate In-Reply-To: <9B2A061A1137254BBE4F4B2CD843646A1117383B14@mbx02.citservers.local> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Mon, 27 Apr 2009 19:22:50 -0500 References: <0D5F89FAC29E2C41B98A6A762007F5D001D4A39A@GBNTHT12009MSX.gb002.siemens.net> <9B2A061A1137254BBE4F4B2CD843646A1117383B14@mbx02.citservers.local> X-Mailer: Apple Mail (2.930.3) Cc: SIPCORE Subject: Re: [sipcore] Question on Require in responses X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Apr 2009 00:21:44 -0000 On Apr 27, 2009, at 9:18 AM, Brett Tate wrote: > The following is a snippet from RFC 3261 section 8.2.4: > > "Any extensions applied to a non-421 response MUST be listed in a > Require header field included in the response. Of course, the > server MUST NOT apply extensions not listed in the Supported header > field in the request." Of course, we often don't do that. For example, RFC 5373 (AnswerMode) uses its own header fields to indicate, in responses, whether the extension was applied. I suspect this behavior was held-over from when iANSwerMode was a P-header draft, and therefore wasn't allowed to have an option tag. So by the logic of RFC 3261 8.2.4, EVERY SIP extension MUST have an Option-Tag. This rather conflicts with RFC 3427. -- Dean From dean.willis@softarmor.com Mon Apr 27 17:28:04 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C22423A6BC5 for ; Mon, 27 Apr 2009 17:28:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.553 X-Spam-Level: X-Spam-Status: No, score=-2.553 tagged_above=-999 required=5 tests=[AWL=0.046, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RoQGhAdD1TOU for ; Mon, 27 Apr 2009 17:28:03 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id C44413A6ECE for ; Mon, 27 Apr 2009 17:28:03 -0700 (PDT) Received: from [192.168.2.102] (cpe-72-181-150-177.tx.res.rr.com [72.181.150.177]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id n3S0TKfF009108 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Mon, 27 Apr 2009 19:29:22 -0500 Message-Id: From: Dean Willis To: Adam Roach In-Reply-To: <49F6194E.40006@nostrum.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Mon, 27 Apr 2009 19:29:15 -0500 References: <49F178CE.8000809@ericsson.com> <0ECC036E-2B21-49D5-AC42-1FEC8EC447BE@softarmor.com> <49F5D64B.20008@nostrum.com> <49F6194E.40006@nostrum.com> X-Mailer: Apple Mail (2.930.3) Cc: SIPCORE Subject: Re: [sipcore] Long reply to: Target URI and History Info bis X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Apr 2009 00:28:04 -0000 On Apr 27, 2009, at 3:45 PM, Adam Roach wrote: > Dean Willis wrote: >> >> On Apr 27, 2009, at 10:59 AM, Adam Roach wrote: >>> >>> So, for the other half of this puzzle, we need to make sure that the >>> parameters you're talking about can be expressed as part of a SIP >>> URI, >>> so that they can be communicated to the UAC in the first place. >>> >> >> Ah, but they can. > > With the mechanisms under discussion, yes, they can. But you > stripped it down to base principles. Your summary missed this aspect > of the problem. I could easily design mechanisms that meet the > requirements you state, but would be cumbersome to encode in a URI > (e.g., encoding parameters in request body, a la HTTP POST requests). > > I just want to make certain that we don't end up taking things in > that direction. The URI-parameter approach is one we got from HTTP, and have had a rough standing consensus on all along, but it hasn't achieved world domination by any means. And given that the URI mechanism in RFC 3261 is "just broken", if we assume a backwards-compatibility requirement, it may well be that some other mechanism might be more suitable. So, despite my having been a long-standing proponent of the URI approach, I now have to say that I'd be open to considering an alternative. For example, perhaps slapping user-to-user parameters into a new header field (as Alan proposed for UUI) or into a body part WOULD be easier than untangling the spider-web of URI revisions that could ostensibly be stacked-up in using History-Info. Do we need to have an entire SVN revision history on the parameter set as it traverses the SIP relay chain? Certainly we COULD solve the parameter problem thusly, but is it the best way? Certainly H-I is a reasonable approach of the problem is "knowing everything that has happened to the Request-URI". However, that's one- step removed from what I think the actual problem is (delivery of parameters to the application). I think we've lost focus on that underlying problem in our quest for a solution, and I think this is why we've gotten all wrapped around the axle in our debate. -- Dean From christer.holmberg@ericsson.com Mon Apr 27 22:08:32 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3723C3A6FEA for ; Mon, 27 Apr 2009 22:08:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.812 X-Spam-Level: X-Spam-Status: No, score=-5.812 tagged_above=-999 required=5 tests=[AWL=0.437, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SqdJtxkhq1Mc for ; Mon, 27 Apr 2009 22:08:29 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 5E2F63A6A2A for ; Mon, 27 Apr 2009 22:08:28 -0700 (PDT) X-AuditID: c1b4fb3e-b7bb8ae000006a07-ac-49f68f9bc2ba Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw4.ericsson.se (Symantec Mail Security) with SMTP id 7C.3A.27143.B9F86F94; Tue, 28 Apr 2009 07:09:48 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 28 Apr 2009 07:09:47 +0200 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: Tue, 28 Apr 2009 07:09:53 +0200 Message-ID: In-Reply-To: <1ECE0EB50388174790F9694F77522CCF1DAA242B@zrc2hxm0.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] Target URI and History Info bis Thread-Index: AcnFHVnNRSw1PA4EQmW33ETABtXuQwAANVhwAHiapTAADr0MEAAg9PcQ References: <49F178CE.8000809@ericsson.com> <49F22443.7010706@gmail.com> <1ECE0EB50388174790F9694F77522CCF1DA43F5F@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1DAA242B@zrc2hxm0.corp.nortel.com> From: "Christer Holmberg" To: "Mary Barnes" , "Hans Erik van Elburg" , "Gonzalo Camarillo" X-OriginalArrivalTime: 28 Apr 2009 05:09:47.0752 (UTC) FILETIME=[8D25DE80:01C9C7BF] X-Brightmail-Tracker: AAAAAA== Cc: SIPCORE Subject: Re: [sipcore] Target URI and History Info bis X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Apr 2009 05:08:32 -0000 Hi Mary, To clarify, I think we can work on both documents at the same time. Regards, Christer =20 > -----Original Message----- > From: Mary Barnes [mailto:mary.barnes@nortel.com]=20 > Sent: 27. huhtikuuta 2009 16:38 > To: Christer Holmberg; Hans Erik van Elburg; Gonzalo Camarillo > Cc: SIPCORE > Subject: RE: [sipcore] Target URI and History Info bis >=20 > Christer, >=20 > Based on your response in the first paragraph, I'm not sure I=20 > understand your second question, since you seem to be=20 > agreeing with the approach I've been suggesting in terms of=20 > putting the normative text to support the requirements and=20 > use cases identified in the target-uri in 4244bis. >=20 >=20 > As far as my email response below, I'm not so much saying=20 > that the target-uri draft currently doesn't work with 4244,=20 > so much as that the current solution in terms of normative=20 > History-Info text is incomplete. > In my opinion, to add enough text to make that solution=20 > complete, and alter the normative text for the Privacy header=20 > to ensure you actually get the headers, requires bringing in=20 > additional text for context from 4244. In the end you would=20 > need to at least "update" 4244, so my suggestion is to start=20 > with 4244bis now and save ourselves some pain down the road.=20 > So, I'm disagreeing with the suggestion that it is so much=20 > faster to progress target-uri than 4244bis. >=20 > Mary.=20 >=20 > -----Original Message----- > From: Christer Holmberg [mailto:christer.holmberg@ericsson.com] > Sent: Monday, April 27, 2009 1:29 AM > To: Barnes, Mary (RICH2:AR00); Hans Erik van Elburg; Gonzalo Camarillo > Cc: SIPCORE > Subject: RE: [sipcore] Target URI and History Info bis >=20 >=20 > Hi, >=20 > I can't remember that, when we agreed to use H-I for target=20 > delivery, a > "precondition" would have been that we also must update 4244. I DO > support the work on 4244bis, but that is a separate issue. >=20 > Mary, could you please re-indicate why the target-uri draft=20 > doesn't work > with 4244? >=20 > Regards, >=20 > Christer >=20 > =20 >=20 > > -----Original Message----- > > From: sipcore-bounces@ietf.org > > [mailto:sipcore-bounces@ietf.org] On Behalf Of Mary Barnes > > Sent: 24. huhtikuuta 2009 23:55 > > To: Hans Erik van Elburg; Gonzalo Camarillo > > Cc: SIPCORE > > Subject: Re: [sipcore] Target URI and History Info bis > >=20 > > Just to re-iterate once more, 4244bis already contains a=20 > superset of=20 > > the normative text for History-Info header from the current=20 > target-uri >=20 > > document. Francois has proposed a fairly straightforward path for=20 > > 4244bis that should allow us to avoid any of the hurdles and open=20 > > ended debates as to History-Info issues - the known issues=20 > are quite=20 > > straight-forward to solve and the issues at hand really are=20 > providing=20 > > a solution for target-uri. The idea that the target-uri document=20 > > would progress much quicker than 4244bis is a red herring - in=20 > > particular based on my comments that you need more changes=20 > to 4244 to=20 > > support target-uri than just the new tags. > >=20 > > Mary.=20 > >=20 > > -----Original Message----- > > From: sipcore-bounces@ietf.org > > [mailto:sipcore-bounces@ietf.org] On Behalf Of Hans Erik van Elburg > > Sent: Friday, April 24, 2009 3:43 PM > > To: Gonzalo Camarillo > > Cc: SIPCORE > > Subject: Re: [sipcore] Target URI and History Info bis > >=20 > > Lets finish the target-uri document first independently, before=20 > > dragging it into another endless 4244bis discussion. > > It can focus on the topic for which it was created. > >=20 > > If 4244bis can work on the other issues it seems to=20 > instantiated for=20 > > and it is ready in time, we can always decide to merge the then=20 > > provided target-uri solution in to 4244bis. > >=20 > > This would speed up the process as several people have=20 > expressed that=20 > > they need the target-uri solution in due time. > > The target-uri draft has a very clear scope, the 4244bis=20 > seems an open >=20 > > ended attractor for History-Info issues... > >=20 > > Best Regards, > > /Hans Erik > >=20 > > Gonzalo Camarillo wrote: > > > Hi, > > > > > > discussions about the target URI and history info bis work > > has focused > >=20 > > > too much on the historical background and not enough on the > > best way > > > to proceed with this work. I would like to have discussions > > on what we > >=20 > > > think would be the best and fastest way to specify what=20 > needs to be=20 > > > specified. > > > > > > Mary claims that having the following draft tackle both the > > target URI > >=20 > > > issue and the revision of History Info would be the fastest and=20 > > > cleanest way to be done with everything we want to specify. > > > > > > http://tools.ietf.org/html/draft-barnes-sip-rfc4244bis-00 > > > > > > Others claim that tackling the target URI issue in an independent=20 > > > draft that does not depend on the revision of History=20 > info would be=20 > > > the fastest way to proceed with the target URI issue. > > > > > >=20 > >=20 > http://tools.ietf.org/html/draft-rosenberg-sip-target-uri-delivery-01 > > > > > > I would like to hear opinions on how we should proceed and why. I=20 > > > would prefer to get reasons related to clearness of the=20 > > > specifications, speed of the process, etc., instead of about the=20 > > > historical background on these two drafts. > > > > > > Thanks, > > > > > > Gonzalo > > > > > > _______________________________________________ > > > 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 > >=20 >=20 From christer.holmberg@ericsson.com Mon Apr 27 22:19:56 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 29CE93A7025 for ; Mon, 27 Apr 2009 22:19:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.214 X-Spam-Level: X-Spam-Status: No, score=-5.214 tagged_above=-999 required=5 tests=[AWL=-0.165, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_73=0.6, J_CHICKENPOX_93=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jycm8Lk9eItZ for ; Mon, 27 Apr 2009 22:19:53 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id E3B0E3A6812 for ; Mon, 27 Apr 2009 22:19:52 -0700 (PDT) X-AuditID: c1b4fb3e-b7bb8ae000006a07-bb-49f692485f0d Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw4.ericsson.se (Symantec Mail Security) with SMTP id 35.CA.27143.84296F94; Tue, 28 Apr 2009 07:21:13 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 28 Apr 2009 07:21:12 +0200 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: Tue, 28 Apr 2009 07:21:18 +0200 Message-ID: In-Reply-To: <49F5C2C4.70501@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] Question on Require in responses Thread-Index: AcnHRXqI5vfs9zxDQwKrkPnktTBpowAeof1Q References: <0D5F89FAC29E2C41B98A6A762007F5D001D4A39A@GBNTHT12009MSX.gb002.siemens.net><49F5B3FE.8030104@cisco.com><28B7C3AA2A7ABA4A841F11217ABE78D67590BF97@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <49F5C2C4.70501@cisco.com> From: "Christer Holmberg" To: "Paul Kyzivat" , "DRAGE, Keith (Keith)" X-OriginalArrivalTime: 28 Apr 2009 05:21:12.0750 (UTC) FILETIME=[257044E0:01C9C7C1] X-Brightmail-Tracker: AAAAAA== Cc: SIPCORE Subject: Re: [sipcore] Question on Require in responses X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Apr 2009 05:19:56 -0000 Hi, One question I sometimes get is whether 'Require:foo' only applies to the specific request where it is carried, or to the whole session. For example, if I include 'Require:100rel' in the initial INVITE, I assume it doesn't mean that I automatically also require reliable provisional responses also for future re-INVITEs within the session (I wuold have to include 'Require:100rel' also in the re-INVITEs for that). But, if I include 'Require:timer' in the initial INVITE, that applies to the whole session. Regards, Christer =20 > -----Original Message----- > From: sipcore-bounces@ietf.org=20 > [mailto:sipcore-bounces@ietf.org] On Behalf Of Paul Kyzivat > Sent: 27. huhtikuuta 2009 17:36 > To: DRAGE, Keith (Keith) > Cc: SIPCORE > Subject: Re: [sipcore] Question on Require in responses >=20 > Keith, >=20 > I don't think I understand the point you are making. >=20 > DRAGE, Keith (Keith) wrote: > > But I think the essence of the question is that Require in=20 > requests is a compatibility mechanism. > > As such, a receiver performs actions if it DOES NOT=20 > understand the option tag. >=20 > That is at least *part* of the behavior for Require. > Nominally its definition was carried over from http, and it=20 > only required behavior of the recipient for the one request.=20 > In that view it would make no sense in responses. >=20 > But the usage and behavior has been overloaded for particular=20 > event types. >=20 > > I would understand that the RFC 3262 usage is that the receiver=20 > > performs NO ACTION if it does not understand the option tag. >=20 > If there is Require:100rel in a request, and the UAS doesn't=20 > understand it, then it will return a 420 response. >=20 > If it receives Supported:100rel, and doesn't understand it,=20 > then it ignores it. >=20 > If it receives Require:100rel and *does* understand it, then=20 > it is supposed to do something. And among the things it is=20 > supposed to do is to include Require:100rel in provisional responses. >=20 > > Would it be reasonably to assume that is a general usage of=20 > Require when received in responses.=20 >=20 > Presumably, if the UAC included Supported:foo or Require:foo=20 > in a request, then it ought to understand if it receives=20 > Require:foo in a response to that request. So it ought not=20 > *ignore* it. But what it ought to do isn't defined=20 > generically. Presumably it ought to do whatever the=20 > specification of the foo event says it should do. >=20 > If the UAC didn't indicate support for, and doesn't=20 > understand, the foo option, then what should it do if it=20 > receives Require:foo in a response?=20 > It can't do as the UAS would, and return a 420 to indicate=20 > its lack of support. So I guess it only has a couple of choices: > - ignore it > - tear down the session. >=20 > But that doesn't really answer the question of what the=20 > *meaning* of a Require header in a response is. I think the=20 > answer must be "the meaning is defined on an opion-specific basis". >=20 > That's not very satisfying. Overloading the behavior was,=20 > IMO, a mistake. But that is where we are. >=20 > Thanks, > Paul >=20 > > regards > >=20 > > Keith > >=20 > >> -----Original Message----- > >> From: sipcore-bounces@ietf.org > >> [mailto:sipcore-bounces@ietf.org] On Behalf Of Paul Kyzivat > >> Sent: Monday, April 27, 2009 2:33 PM > >> To: Elwell, John > >> Cc: SIPCORE > >> Subject: Re: [sipcore] Question on Require in responses > >> > >> John, > >> > >> I don't have a general answer for you. IMO the answer to this is=20 > >> closely related to the definition of the scope of the negotiated=20 > >> agreement, which AFAIK is never defined in a general way,=20 > but may be=20 > >> defined for certain options. > >> > >> As a example, 3262 defines the use of Require:100rel in responses. > >> > >> Thanks, > >> Paul > >> > >> Elwell, John wrote: > >>> What is the meaning of the Require header field in responses (in=20 > >>> general > >>> - not the specific use in RFC 3262)? > >>> > >>> The table in section 20 of RFC 3261 does not limit the field to=20 > >>> requests, but the description in 20.32 only describes > >> meaning for the > >>> field when used in requests. > >>> > >>> John > >>> _______________________________________________ > >>> 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 >=20 From john.elwell@siemens-enterprise.com Mon Apr 27 23:47:48 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8CDD43A6B85 for ; Mon, 27 Apr 2009 23:47:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.455 X-Spam-Level: X-Spam-Status: No, score=-2.455 tagged_above=-999 required=5 tests=[AWL=0.144, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I6wjBU+B38xk for ; Mon, 27 Apr 2009 23:47:47 -0700 (PDT) Received: from mailgate.siemenscomms.co.uk (mailgate.siemenscomms.co.uk [195.171.110.225]) by core3.amsl.com (Postfix) with ESMTP id B89643A6A3C for ; Mon, 27 Apr 2009 23:47:47 -0700 (PDT) Received: from GBNTHT12009MSX.gb002.siemens.net ([137.223.219.235]) by siemenscomms.co.uk (PMDF V6.3-x14 #31430) with ESMTP id <0KIS00B0XTLVR9@siemenscomms.co.uk> for sipcore@ietf.org; Tue, 28 Apr 2009 07:49:07 +0100 (BST) Date: Tue, 28 Apr 2009 07:49:06 +0100 From: "Elwell, John" In-reply-to: To: Dean Willis , Brett Tate Message-id: <0D5F89FAC29E2C41B98A6A762007F5D001D4A5F3@GBNTHT12009MSX.gb002.siemens.net> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: quoted-printable Thread-Topic: [sipcore] Question on Require in responses Thread-Index: AcnHl4NXwkdpLqQ3RiKd5DgBrIH6NwANc9DA Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <0D5F89FAC29E2C41B98A6A762007F5D001D4A39A@GBNTHT12009MSX.gb002.siemens.net> <9B2A061A1137254BBE4F4B2CD843646A1117383B14@mbx02.citservers.local> Cc: SIPCORE Subject: Re: [sipcore] Question on Require in responses X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Apr 2009 06:47:48 -0000 Only extensions that are present in the response. However, even this I don't think we do, e.g., when sending History-Info in a response. John=20 > -----Original Message----- > From: Dean Willis [mailto:dean.willis@softarmor.com]=20 > Sent: 28 April 2009 01:23 > To: Brett Tate > Cc: Elwell, John; SIPCORE > Subject: Re: [sipcore] Question on Require in responses >=20 >=20 > On Apr 27, 2009, at 9:18 AM, Brett Tate wrote: >=20 > > The following is a snippet from RFC 3261 section 8.2.4: > > > > "Any extensions applied to a non-421 response MUST be listed in a =20 > > Require header field included in the response. Of course, the =20 > > server MUST NOT apply extensions not listed in the=20 > Supported header =20 > > field in the request." >=20 > Of course, we often don't do that. For example, RFC 5373=20 > (AnswerMode) =20 > uses its own header fields to indicate, in responses, whether the =20 > extension was applied. I suspect this behavior was held-over from =20 > when iANSwerMode was a P-header draft, and therefore wasn't=20 > allowed to =20 > have an option tag. >=20 > So by the logic of RFC 3261 8.2.4, EVERY SIP extension MUST have an =20 > Option-Tag. This rather conflicts with RFC 3427. >=20 > -- > Dean >=20 >=20 >=20 >=20 From pkyzivat@cisco.com Tue Apr 28 07:37:41 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1AB523A6E84 for ; Tue, 28 Apr 2009 07:37:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.447 X-Spam-Level: X-Spam-Status: No, score=-5.447 tagged_above=-999 required=5 tests=[AWL=-0.048, BAYES_00=-2.599, J_CHICKENPOX_73=0.6, J_CHICKENPOX_93=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3i9Sw+hn7bkO for ; Tue, 28 Apr 2009 07:37:40 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 109F23A6B91 for ; Tue, 28 Apr 2009 07:37:40 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,260,1238976000"; d="scan'208";a="159738085" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-2.cisco.com with ESMTP; 28 Apr 2009 14:39:01 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id n3SEd13t002851; Tue, 28 Apr 2009 07:39:01 -0700 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n3SEcwmt016366; Tue, 28 Apr 2009 14:39:01 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 28 Apr 2009 10:39:00 -0400 Received: from [161.44.174.156] ([161.44.174.156]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 28 Apr 2009 10:39:00 -0400 Message-ID: <49F71501.2020300@cisco.com> Date: Tue, 28 Apr 2009 10:38:57 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Christer Holmberg References: <0D5F89FAC29E2C41B98A6A762007F5D001D4A39A@GBNTHT12009MSX.gb002.siemens.net><49F5B3FE.8030104@cisco.com><28B7C3AA2A7ABA4A841F11217ABE78D67590BF97@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <49F5C2C4.70501@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 28 Apr 2009 14:39:00.0510 (UTC) FILETIME=[11C72BE0:01C9C80F] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=5372; t=1240929541; x=1241793541; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[sipcore]=20Question=20on=20Require=20i n=20responses |Sender:=20; bh=2llfFNyJ/l+XpHO+LnSBiFZOIKCNrOzdY5NyszLmlR4=; b=KYxQvcXB2g+ZTmsn2YSJRu6Vr4ImKVnRhLM6EUqCXz+JlsOvxuGCq0gA/U tsTp0ZjCuBxsQveqP6f6aTlGi3tAi9+HjLagPPm1tZq9c+9z4zY/8TxSsZyd DsEuMPSMzM; Authentication-Results: sj-dkim-4; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Cc: SIPCORE Subject: Re: [sipcore] Question on Require in responses X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Apr 2009 14:37:41 -0000 Christer Holmberg wrote: > Hi, > > One question I sometimes get is whether 'Require:foo' only applies to > the specific request where it is carried, or to the whole session. > > For example, if I include 'Require:100rel' in the initial INVITE, I > assume it doesn't mean that I automatically also require reliable > provisional responses also for future re-INVITEs within the session (I > wuold have to include 'Require:100rel' also in the re-INVITEs for that). > > But, if I include 'Require:timer' in the initial INVITE, that applies to > the whole session. Actually, I think it is much clearer with Timer. That option only says you are capable of supporting the feature, and does not say if you want to use it or not. Headers are used to negotiate the use of the feature. Once the use of the timer is negotiated, it remains only until the next reINVITE or UPDATE, where it must be renegotiated. 100rel is less clear. I think your position is a reasonable one, but I don't know if it is universally held. Thanks, Paul > Regards, > > Christer > > > > > > > > > > > > > > >> -----Original Message----- >> From: sipcore-bounces@ietf.org >> [mailto:sipcore-bounces@ietf.org] On Behalf Of Paul Kyzivat >> Sent: 27. huhtikuuta 2009 17:36 >> To: DRAGE, Keith (Keith) >> Cc: SIPCORE >> Subject: Re: [sipcore] Question on Require in responses >> >> Keith, >> >> I don't think I understand the point you are making. >> >> DRAGE, Keith (Keith) wrote: >>> But I think the essence of the question is that Require in >> requests is a compatibility mechanism. >>> As such, a receiver performs actions if it DOES NOT >> understand the option tag. >> >> That is at least *part* of the behavior for Require. >> Nominally its definition was carried over from http, and it >> only required behavior of the recipient for the one request. >> In that view it would make no sense in responses. >> >> But the usage and behavior has been overloaded for particular >> event types. >> >>> I would understand that the RFC 3262 usage is that the receiver >>> performs NO ACTION if it does not understand the option tag. >> If there is Require:100rel in a request, and the UAS doesn't >> understand it, then it will return a 420 response. >> >> If it receives Supported:100rel, and doesn't understand it, >> then it ignores it. >> >> If it receives Require:100rel and *does* understand it, then >> it is supposed to do something. And among the things it is >> supposed to do is to include Require:100rel in provisional responses. >> >>> Would it be reasonably to assume that is a general usage of >> Require when received in responses. >> >> Presumably, if the UAC included Supported:foo or Require:foo >> in a request, then it ought to understand if it receives >> Require:foo in a response to that request. So it ought not >> *ignore* it. But what it ought to do isn't defined >> generically. Presumably it ought to do whatever the >> specification of the foo event says it should do. >> >> If the UAC didn't indicate support for, and doesn't >> understand, the foo option, then what should it do if it >> receives Require:foo in a response? >> It can't do as the UAS would, and return a 420 to indicate >> its lack of support. So I guess it only has a couple of choices: >> - ignore it >> - tear down the session. >> >> But that doesn't really answer the question of what the >> *meaning* of a Require header in a response is. I think the >> answer must be "the meaning is defined on an opion-specific basis". >> >> That's not very satisfying. Overloading the behavior was, >> IMO, a mistake. But that is where we are. >> >> Thanks, >> Paul >> >>> regards >>> >>> Keith >>> >>>> -----Original Message----- >>>> From: sipcore-bounces@ietf.org >>>> [mailto:sipcore-bounces@ietf.org] On Behalf Of Paul Kyzivat >>>> Sent: Monday, April 27, 2009 2:33 PM >>>> To: Elwell, John >>>> Cc: SIPCORE >>>> Subject: Re: [sipcore] Question on Require in responses >>>> >>>> John, >>>> >>>> I don't have a general answer for you. IMO the answer to this is >>>> closely related to the definition of the scope of the negotiated >>>> agreement, which AFAIK is never defined in a general way, >> but may be >>>> defined for certain options. >>>> >>>> As a example, 3262 defines the use of Require:100rel in responses. >>>> >>>> Thanks, >>>> Paul >>>> >>>> Elwell, John wrote: >>>>> What is the meaning of the Require header field in responses (in >>>>> general >>>>> - not the specific use in RFC 3262)? >>>>> >>>>> The table in section 20 of RFC 3261 does not limit the field to >>>>> requests, but the description in 20.32 only describes >>>> meaning for the >>>>> field when used in requests. >>>>> >>>>> John >>>>> _______________________________________________ >>>>> 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 brett@broadsoft.com Tue Apr 28 07:39:57 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 096F13A70A2 for ; Tue, 28 Apr 2009 07:39:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.734 X-Spam-Level: X-Spam-Status: No, score=-1.734 tagged_above=-999 required=5 tests=[AWL=0.265, BAYES_00=-2.599, J_CHICKENPOX_75=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WAP+PaaHtdRv for ; Tue, 28 Apr 2009 07:39:56 -0700 (PDT) Received: from smtp-out01.seaservers.net (smtp-out01.seaservers.net [72.37.232.66]) by core3.amsl.com (Postfix) with ESMTP id 370693A6B21 for ; Tue, 28 Apr 2009 07:39:56 -0700 (PDT) Received: from mbx02.citservers.local ([172.16.98.24]) by casumhub01.citservers.local ([172.16.98.57]) with mapi; Tue, 28 Apr 2009 07:41:17 -0700 From: Brett Tate To: Dean Willis , SIPCORE Date: Tue, 28 Apr 2009 07:41:16 -0700 Thread-Topic: [sipcore] Question on Require in responses Thread-Index: AcnHl4EnFiiTq+qTS5yOyCvtlU1bWQAZeIdQ Message-ID: <9B2A061A1137254BBE4F4B2CD843646A1117383D71@mbx02.citservers.local> References: <0D5F89FAC29E2C41B98A6A762007F5D001D4A39A@GBNTHT12009MSX.gb002.siemens.net> <9B2A061A1137254BBE4F4B2CD843646A1117383B14@mbx02.citservers.local> 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 Subject: Re: [sipcore] Question on Require in responses X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Apr 2009 14:39:57 -0000 Concerning RFC 3261 section 8.2.4, I don't think the section was attempting= to mandate the use of option-tags to extend SIP. If it was, it obviously = failed. And I'm definitely not attempting to defend the first sentence of my sectio= n 8.2.4 snippet. When I previously attempted to get draft-ietf-sip-session= -timer altered to remove the useless adding of Require:timer to responses, = Jonathan's argument for leaving it was that it made it easier for proxies, = UAC, and etcetera to quickly glance at the response's Require instead of ju= st looking for the Session-Expires. In my opinion, the RFC extending SIP s= pecifies if appropriate to echo option-tag from request's Supported into re= sponse's Require; thus there are likely some SIP extension RFCs that intent= ionally (or accidentally) don't follow RFC 3261's MUST for useless echoing = of option-tag. > -----Original Message----- > From: Dean Willis [mailto:dean.willis@softarmor.com] > Sent: Monday, April 27, 2009 8:23 PM > To: Brett Tate > Cc: Elwell, John; SIPCORE > Subject: Re: [sipcore] Question on Require in responses >=20 >=20 > On Apr 27, 2009, at 9:18 AM, Brett Tate wrote: >=20 > > The following is a snippet from RFC 3261 section 8.2.4: > > > > "Any extensions applied to a non-421 response MUST be listed in a > > Require header field included in the response. Of course, the > > server MUST NOT apply extensions not listed in the Supported header > > field in the request." >=20 > Of course, we often don't do that. For example, RFC 5373 (AnswerMode) > uses its own header fields to indicate, in responses, whether the > extension was applied. I suspect this behavior was held-over from > when iANSwerMode was a P-header draft, and therefore wasn't allowed to > have an option tag. >=20 > So by the logic of RFC 3261 8.2.4, EVERY SIP extension MUST have an > Option-Tag. This rather conflicts with RFC 3427. >=20 > -- > Dean >=20 >=20 From christer.holmberg@ericsson.com Tue Apr 28 10:26:24 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 85A433A6927 for ; Tue, 28 Apr 2009 10:26:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.913 X-Spam-Level: X-Spam-Status: No, score=-4.913 tagged_above=-999 required=5 tests=[AWL=-0.464, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_73=0.6, J_CHICKENPOX_75=0.6, J_CHICKENPOX_93=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0ogh6zLhSwWs for ; Tue, 28 Apr 2009 10:26:23 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id D97B528C1F6 for ; Tue, 28 Apr 2009 10:25:55 -0700 (PDT) X-AuditID: c1b4fb3c-b7b4bae000001105-70-49f73c73130b Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw3.ericsson.se (Symantec Mail Security) with SMTP id 68.1A.04357.47C37F94; Tue, 28 Apr 2009 19:27:16 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 28 Apr 2009 19:27:15 +0200 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: Tue, 28 Apr 2009 19:27:14 +0200 Message-ID: In-Reply-To: <49F71501.2020300@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] Question on Require in responses Thread-Index: AcnIDxUahWByKa3VTd2mm4XTTdTd9gAFTuCw References: <0D5F89FAC29E2C41B98A6A762007F5D001D4A39A@GBNTHT12009MSX.gb002.siemens.net><49F5B3FE.8030104@cisco.com><28B7C3AA2A7ABA4A841F11217ABE78D67590BF97@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <49F5C2C4.70501@cisco.com> <49F71501.2020300@cisco.com> From: "Christer Holmberg" To: "Paul Kyzivat" X-OriginalArrivalTime: 28 Apr 2009 17:27:15.0271 (UTC) FILETIME=[92B97570:01C9C826] X-Brightmail-Tracker: AAAAAA== Cc: SIPCORE Subject: Re: [sipcore] Question on Require in responses X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Apr 2009 17:26:24 -0000 Hi,=20 >>One question I sometimes get is whether 'Require:foo' only applies to the specific request where it is carried, or to the whole session. >>=20 >>For example, if I include 'Require:100rel' in the initial INVITE, I=20 >>assume it doesn't mean that I automatically also require reliable=20 >>provisional responses also for future re-INVITEs within the session (I >>wuold have to include 'Require:100rel' also in the re-INVITEs for that). >>=20 >>But, if I include 'Require:timer' in the initial INVITE, that applies=20 >>to the whole session. > >Actually, I think it is much clearer with Timer. >That option only says you are capable of supporting the feature, and does not say if you want to use it or not. True. Require:timer only requires the other party to support the extension. But, never the less, the scope is still wider than a single transaction.=20 >Headers are used to negotiate the use of the feature. Once the use of the timer is negotiated, it remains only until the next reINVITE or UPDATE, where it must be renegotiated. I think 4028 is actually a little confusing and unclear about that. First, it does talk about "initial session refresh requests", but the word initial and refresh in the same definition is a little confusing... Second, it only says that headers etc must be included in session refresh requests - not in target refresh requests, and the RFC explicitly says that those are two different things. But, we've had enough discussions about the session-timer during the years, so I don't want to start a new one :) >100rel is less clear. I think your position is a reasonable one, but I don't know if it is universally held. Maybe that is something that should be added to the potential issues to fix in RFC3262, toghether with the reject-an-offer-in-PRACK and does-4xx-cease-retransmission one... Regards, Christer >> -----Original Message----- >> From: sipcore-bounces@ietf.org >> [mailto:sipcore-bounces@ietf.org] On Behalf Of Paul Kyzivat >> Sent: 27. huhtikuuta 2009 17:36 >> To: DRAGE, Keith (Keith) >> Cc: SIPCORE >> Subject: Re: [sipcore] Question on Require in responses >> >> Keith, >> >> I don't think I understand the point you are making. >> >> DRAGE, Keith (Keith) wrote: >>> But I think the essence of the question is that Require in >> requests is a compatibility mechanism. >>> As such, a receiver performs actions if it DOES NOT >> understand the option tag. >> >> That is at least *part* of the behavior for Require. >> Nominally its definition was carried over from http, and it only=20 >> required behavior of the recipient for the one request. >> In that view it would make no sense in responses. >> >> But the usage and behavior has been overloaded for particular event=20 >> types. >> >>> I would understand that the RFC 3262 usage is that the receiver=20 >>> performs NO ACTION if it does not understand the option tag. >> If there is Require:100rel in a request, and the UAS doesn't=20 >> understand it, then it will return a 420 response. >> >> If it receives Supported:100rel, and doesn't understand it, then it=20 >> ignores it. >> >> If it receives Require:100rel and *does* understand it, then it is=20 >> supposed to do something. And among the things it is supposed to do=20 >> is to include Require:100rel in provisional responses. >> >>> Would it be reasonably to assume that is a general usage of >> Require when received in responses.=20 >> >> Presumably, if the UAC included Supported:foo or Require:foo in a=20 >> request, then it ought to understand if it receives Require:foo in a=20 >> response to that request. So it ought not >> *ignore* it. But what it ought to do isn't defined generically.=20 >> Presumably it ought to do whatever the specification of the foo event >> says it should do. >> >> If the UAC didn't indicate support for, and doesn't understand, the=20 >> foo option, then what should it do if it receives Require:foo in a=20 >> response? >> It can't do as the UAS would, and return a 420 to indicate its lack=20 >> of support. So I guess it only has a couple of choices: >> - ignore it >> - tear down the session. >> >> But that doesn't really answer the question of what the >> *meaning* of a Require header in a response is. I think the answer=20 >> must be "the meaning is defined on an opion-specific basis". >> >> That's not very satisfying. Overloading the behavior was, IMO, a=20 >> mistake. But that is where we are. >> >> Thanks, >> Paul >> >>> regards >>> >>> Keith >>> >>>> -----Original Message----- >>>> From: sipcore-bounces@ietf.org >>>> [mailto:sipcore-bounces@ietf.org] On Behalf Of Paul Kyzivat >>>> Sent: Monday, April 27, 2009 2:33 PM >>>> To: Elwell, John >>>> Cc: SIPCORE >>>> Subject: Re: [sipcore] Question on Require in responses >>>> >>>> John, >>>> >>>> I don't have a general answer for you. IMO the answer to this is=20 >>>> closely related to the definition of the scope of the negotiated=20 >>>> agreement, which AFAIK is never defined in a general way, >> but may be >>>> defined for certain options. >>>> >>>> As a example, 3262 defines the use of Require:100rel in responses. >>>> >>>> Thanks, >>>> Paul >>>> >>>> Elwell, John wrote: >>>>> What is the meaning of the Require header field in responses (in=20 >>>>> general >>>>> - not the specific use in RFC 3262)? >>>>> >>>>> The table in section 20 of RFC 3261 does not limit the field to=20 >>>>> requests, but the description in 20.32 only describes >>>> meaning for the >>>>> field when used in requests. >>>>> >>>>> John >>>>> _______________________________________________ >>>>> 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 >> >=20 From dean.willis@softarmor.com Tue Apr 28 10:53:45 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C85693A711C for ; Tue, 28 Apr 2009 10:53:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.554 X-Spam-Level: X-Spam-Status: No, score=-2.554 tagged_above=-999 required=5 tests=[AWL=0.045, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZB8cXSOmiFgL for ; Tue, 28 Apr 2009 10:53:45 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id EFDEE3A711B for ; Tue, 28 Apr 2009 10:53:44 -0700 (PDT) Received: from [192.168.2.106] (cpe-72-181-150-177.tx.res.rr.com [72.181.150.177]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id n3SHt0X8015533 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 28 Apr 2009 12:55:02 -0500 Message-ID: <49F742EE.30504@softarmor.com> Date: Tue, 28 Apr 2009 12:54:54 -0500 From: Dean Willis User-Agent: Thunderbird 2.0.0.21 (X11/20090409) MIME-Version: 1.0 To: Paul Kyzivat References: <0D5F89FAC29E2C41B98A6A762007F5D001D4A39A@GBNTHT12009MSX.gb002.siemens.net><49F5B3FE.8030104@cisco.com><28B7C3AA2A7ABA4A841F11217ABE78D67590BF97@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <49F5C2C4.70501@cisco.com> <49F71501.2020300@cisco.com> In-Reply-To: <49F71501.2020300@cisco.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: SIPCORE Subject: Re: [sipcore] Question on Require in responses X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Apr 2009 17:53:45 -0000 Paul Kyzivat wrote: > Actually, I think it is much clearer with Timer. > That option only says you are capable of supporting the feature, and > does not say if you want to use it or not. Headers are used to negotiate > the use of the feature. Once the use of the timer is negotiated, it > remains only until the next reINVITE or UPDATE, where it must be > renegotiated. > A Supported or Require usage of an option ALWAYS says only that someone (sender or receiver) is capable of supporting the extension. Some extension definitions define when the extension will and will not be used (for exampple "A UA supporting this extension will engage the extension whenever it receives a request having the option tag for this extension in a Supported header field") but this is outside of the semantic of Require. A "Require" header is just a shortcut for doing an "OPIONS", and then sending the extension-requiring request only if the result of the OPTIONS request indicates support for the required extension. People clearly don't get this, and we've had to push the issue on almost every extension. People clearly want inclusion of an option-tag in a require to force the other end to engage the "required behavior", but it just doesn't work that way. It's a mechanism for negotiating a common understanding of the protocol, not for authorization control. I think this is why we had the confusion about option-tag definitions that led to precluding informational-track extensions from registering options tags. -- Dean Willis From christer.holmberg@ericsson.com Tue Apr 28 10:54:48 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 088FA28C27B for ; Tue, 28 Apr 2009 10:54:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.811 X-Spam-Level: X-Spam-Status: No, score=-5.811 tagged_above=-999 required=5 tests=[AWL=0.438, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TqFtOH6oGPMb for ; Tue, 28 Apr 2009 10:54:44 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 864C23A70D5 for ; Tue, 28 Apr 2009 10:54:43 -0700 (PDT) X-AuditID: c1b4fb3c-b7b4bae000001105-0c-49f74333c6fa Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw3.ericsson.se (Symantec Mail Security) with SMTP id 75.4B.04357.33347F94; Tue, 28 Apr 2009 19:56:04 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 28 Apr 2009 19:56:03 +0200 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: Tue, 28 Apr 2009 19:56:03 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] Long reply to: Target URI and History Info bis Thread-Index: AcnHmGSwbca5Ki6VR/eJzndLh9chOgAkN1zw References: <49F178CE.8000809@ericsson.com><0ECC036E-2B21-49D5-AC42-1FEC8EC447BE@softarmor.com><49F5D64B.20008@nostrum.com><49F6194E.40006@nostrum.com> From: "Christer Holmberg" To: "Dean Willis" , "Adam Roach" X-OriginalArrivalTime: 28 Apr 2009 17:56:03.0603 (UTC) FILETIME=[98E3FE30:01C9C82A] X-Brightmail-Tracker: AAAAAA== Cc: SIPCORE Subject: Re: [sipcore] Long reply to: Target URI and History Info bis X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Apr 2009 17:54:48 -0000 Hi, I don't think the problem we are trying to solve is "delivery of parameters", or "user-to-user parameters". The problem we are tying to solve is to deliver the original target URI (which, of course, may include parameters). The proposal from me and Hans Erik could have been to use a dedicated Target header. That would have solved the problem, only the problem and nothing but the problem. But, the discussion outcome, and WG decission, was then to use History-Info. Good or bad, but that is the decission the WG made. Regards, Christer =20 -----Original Message----- From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behalf Of Dean Willis Sent: Tuesday, April 28, 2009 3:29 AM To: Adam Roach Cc: SIPCORE Subject: Re: [sipcore] Long reply to: Target URI and History Info bis On Apr 27, 2009, at 3:45 PM, Adam Roach wrote: > Dean Willis wrote: >> >> On Apr 27, 2009, at 10:59 AM, Adam Roach wrote: >>> >>> So, for the other half of this puzzle, we need to make sure that the >>> parameters you're talking about can be expressed as part of a SIP=20 >>> URI, so that they can be communicated to the UAC in the first place. >>> >> >> Ah, but they can. > > With the mechanisms under discussion, yes, they can. But you stripped=20 > it down to base principles. Your summary missed this aspect of the=20 > problem. I could easily design mechanisms that meet the requirements=20 > you state, but would be cumbersome to encode in a URI (e.g., encoding=20 > parameters in request body, a la HTTP POST requests). > > I just want to make certain that we don't end up taking things in that > direction. The URI-parameter approach is one we got from HTTP, and have had a =20 rough standing consensus on all along, but it hasn't achieved world =20 domination by any means. And given that the URI mechanism in RFC 3261 is "just broken", if we =20 assume a backwards-compatibility requirement, it may well be that some =20 other mechanism might be more suitable. So, despite my having been a =20 long-standing proponent of the URI approach, I now have to say that =20 I'd be open to considering an alternative. For example, perhaps slapping user-to-user parameters into a new =20 header field (as Alan proposed for UUI) or into a body part WOULD be =20 easier than untangling the spider-web of URI revisions that could =20 ostensibly be stacked-up in using History-Info. Do we need to have an =20 entire SVN revision history on the parameter set as it traverses the =20 SIP relay chain? Certainly we COULD solve the parameter problem =20 thusly, but is it the best way? Certainly H-I is a reasonable approach of the problem is "knowing =20 everything that has happened to the Request-URI". However, that's one-=20 step removed from what I think the actual problem is (delivery of =20 parameters to the application). I think we've lost focus on that =20 underlying problem in our quest for a solution, and I think this is =20 why we've gotten all wrapped around the axle in our debate. -- Dean _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore From christer.holmberg@ericsson.com Tue Apr 28 11:16:24 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7E0A23A6359 for ; Tue, 28 Apr 2009 11:16:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.813 X-Spam-Level: X-Spam-Status: No, score=-5.813 tagged_above=-999 required=5 tests=[AWL=0.436, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bf0vQniwaAsn for ; Tue, 28 Apr 2009 11:16:23 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id C0B5E3A6A8D for ; Tue, 28 Apr 2009 11:16:01 -0700 (PDT) X-AuditID: c1b4fb3c-b7b4bae000001105-e9-49f748316f59 Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw3.ericsson.se (Symantec Mail Security) with SMTP id E3.2C.04357.13847F94; Tue, 28 Apr 2009 20:17:21 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Tue, 28 Apr 2009 20:17:21 +0200 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: Tue, 28 Apr 2009 20:16:51 +0200 Message-ID: In-Reply-To: <65A71093-A94E-4E5D-AFBA-B3C5963CEA47@standardstrack.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] INFO Tables Thread-Index: AcnHK9vTz4wTsVQxRsSWmy8IGJl+9gBAUzug References: <65A71093-A94E-4E5D-AFBA-B3C5963CEA47@standardstrack.com> From: "Christer Holmberg" To: "Eric Burger" , "SIPCORE" X-OriginalArrivalTime: 28 Apr 2009 18:17:21.0531 (UTC) FILETIME=[929854B0:01C9C82D] X-Brightmail-Tracker: AAAAAA== Subject: Re: [sipcore] INFO Tables X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Apr 2009 18:16:24 -0000 Hi, Q1: The table in 5.2 mandates Info-Package in INFO. But, since we still allow for legacy usage of INFO, without the header, I think we need to indiate that somehow. Q2: Do we allow 1xx responses for non-INV requests, or do I missunderstand the able? At least for ACK there are no responses at all. Regards, Christer =20 -----Original Message----- From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behalf Of Eric Burger Sent: Monday, April 27, 2009 2:32 PM To: SIPCORE Subject: [sipcore] INFO Tables Please, please, please go over this table and make sure it is correct. If I hear nothing now, yet people say stuff during WGLC or later, we will not be happy. Table 1: Summary of Header Fields Header Where INFO ------ ----- ---- Accept R o Accept-Encoding R o Accept-Encoding 2xx o Accept-Encoding 415 c Accept-Language R o Accept-Language 2xx o Accept-Language 415 c Allow R o Allow 200 - Allow 405 o Allow-Events R o Allow-Events r o Authentication-Info 2xx o Authorization R o Call-ID gc m Call-Info R o Call-Info r o Contact R - Contact 1xx - Contact 2xx - Contact 3xx - Contact 485 - Content-Disposition e o Content-Encoding e o Content-Language e o Content-Length e o Content-Type e * CSeq gc m Date g o Error-Info 3xx-6xx o Expires g - From gc m Geolocation R o Max-Breadth R - Max-Forwards R o MIME-Version R o MIME-Version r o Organization g o Privacy R o Proxy-Authenticate 407 o Proxy-Authorization R o Proxy-Require R o Reason R o Record-Route R o Record-Route 2xx o Require R o Require r o Retry-After R - Retry-After 404,480,486 o Retry-After 503 o Retry-After 600,603 o Route R o Security-Client R o Security-Server 421,494 o Security-Verify R o Server r o Subject R o Supported R o Supported 2xx o Timestamp g o To gc(1) m Unsupported 420 o User-Agent g o Via gc(2) m Warning r o WWW-Authenticate 401 o 5.2. INFO Headers This table expands on tables 2 and 3 in [RFC3261]. Header field where ACK BYE CAN INV OPT REG PRA INF MSG UPD SUB NOT -------------------------------------------------------------------- Info-Package R - - - - - - - m - - - - Recv-Info R o - - o o o o - - o - - Recv-Info 2xx o - - o o - o - - o - - Recv-Info 1xx o - - o o - o - - o - - Recv-Info r o - - - o - o - - o - - From pkyzivat@cisco.com Tue Apr 28 11:50:15 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EBB423A7081 for ; Tue, 28 Apr 2009 11:50:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.046 X-Spam-Level: X-Spam-Status: No, score=-8.046 tagged_above=-999 required=5 tests=[AWL=2.553, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id E-PB-153xW3K for ; Tue, 28 Apr 2009 11:50:14 -0700 (PDT) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by core3.amsl.com (Postfix) with ESMTP id 64FBC3A6C62 for ; Tue, 28 Apr 2009 11:50:14 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,261,1238976000"; d="scan'208";a="39350548" Received: from ams-dkim-1.cisco.com ([144.254.224.138]) by ams-iport-1.cisco.com with ESMTP; 28 Apr 2009 18:51:22 +0000 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by ams-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n3SIpFIX005089; Tue, 28 Apr 2009 20:51:16 +0200 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id n3SIpFNq019906; Tue, 28 Apr 2009 18:51:15 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 28 Apr 2009 14:51:15 -0400 Received: from [161.44.174.156] ([161.44.174.156]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Tue, 28 Apr 2009 14:51:15 -0400 Message-ID: <49F75022.4010905@cisco.com> Date: Tue, 28 Apr 2009 14:51:14 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Dean Willis References: <0D5F89FAC29E2C41B98A6A762007F5D001D4A39A@GBNTHT12009MSX.gb002.siemens.net><49F5B3FE.8030104@cisco.com><28B7C3AA2A7ABA4A841F11217ABE78D67590BF97@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <49F5C2C4.70501@cisco.com> <49F71501.2020300@cisco.com> <49F742EE.30504@softarmor.com> In-Reply-To: <49F742EE.30504@softarmor.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 28 Apr 2009 18:51:15.0288 (UTC) FILETIME=[4ECF0580:01C9C832] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3246; t=1240944676; x=1241808676; c=relaxed/simple; s=amsdkim1002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[sipcore]=20Question=20on=20Require=20i n=20responses |Sender:=20; bh=uW3qwqzFIotZOTVtnwhNg7BWUxDXO2U9cPhLDIe387M=; b=i1Yt5X3TA4N1c2K5c3YoODW80+Pn1Mro+Q9vCRa4bmsjkAqYbl37CxCB8F 3vw/dcEyA1ZFIpJUyRoHV7CNPBJapi+lbR5YcCDGYWktMt0Uehptt2BIpCsR yoigmkTZsH; Authentication-Results: ams-dkim-1; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/amsdkim1002 verified; ); Cc: SIPCORE Subject: Re: [sipcore] Question on Require in responses X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Apr 2009 18:50:16 -0000 Dean Willis wrote: > Paul Kyzivat wrote: > >> Actually, I think it is much clearer with Timer. >> That option only says you are capable of supporting the feature, and >> does not say if you want to use it or not. Headers are used to negotiate >> the use of the feature. Once the use of the timer is negotiated, it >> remains only until the next reINVITE or UPDATE, where it must be >> renegotiated. >> > > A Supported or Require usage of an option ALWAYS says only that someone > (sender or receiver) is capable of supporting the extension. Good theory, but not entirely true. This thread has already pointed out the use of Require:100rel in a response. 3262 says: If a provisional response is received for an initial request, and that response contains a Require header field containing the option tag 100rel, the response is to be sent reliably. If the response is a 100 (Trying) (as opposed to 101 to 199), this option tag MUST be ignored, and the procedures below MUST NOT be used. The provisional response MUST establish a dialog if one is not yet created. Assuming the response is to be transmitted reliably, the UAC MUST create a new request with method PRACK. This request is sent within the dialog associated with the provisional response (indeed, the provisional response may have created the dialog). PRACK requests MAY contain bodies, which are interpreted according to their type and disposition. This phrasing certainly says to me that the Require:100rel means that the UAC MUST enable the feature. Of course it didn't need to be written that way. There is something else in a response that indicates it is reliable: the RSeq header. It would have been sufficient to say that if the UAC Supports 100rel, and receives a response with an RSeq header, then it must send a PRACK. And the Require:100rel in the response would simply have been one more assurance that the UAC in fact supports it. (In addition to it having indicated Support in the request.) > Some extension definitions define when the extension will and will not > be used (for exampple "A UA supporting this extension will engage the > extension whenever it receives a request having the option tag for this > extension in a Supported header field") but this is outside of the > semantic of Require. > > A "Require" header is just a shortcut for doing an "OPIONS", and then > sending the extension-requiring request only if the result of the > OPTIONS request indicates support for the required extension. > > People clearly don't get this, and we've had to push the issue on almost > every extension. People clearly want inclusion of an option-tag in a > require to force the other end to engage the "required behavior", but it > just doesn't work that way. It's a mechanism for negotiating a common > understanding of the protocol, not for authorization control. > > I think this is why we had the confusion about option-tag definitions > that led to precluding informational-track extensions from registering > options tags. I agree with you, but our own specs have helped to create this confusion. Thanks, Paul From sgarg@cedarpointcom.com Tue Apr 28 12:15:19 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4A6AB3A6B9F for ; Tue, 28 Apr 2009 12:15:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qkg0xep4I+22 for ; Tue, 28 Apr 2009 12:15:18 -0700 (PDT) Received: from web65605.mail.ac4.yahoo.com (web65605.mail.ac4.yahoo.com [76.13.9.73]) by core3.amsl.com (Postfix) with SMTP id 598643A6B05 for ; Tue, 28 Apr 2009 12:15:18 -0700 (PDT) Received: (qmail 12546 invoked by uid 60001); 28 Apr 2009 19:16:39 -0000 Message-ID: <874544.99408.qm@web65605.mail.ac4.yahoo.com> X-YMail-OSG: SCDjbN8VM1nhzrV6iQW6duQXWl5_hlUaMRMSG4AB8vAiDEZWqXgXowtUW2te2sx_iUPpVcEUP2xZlZjOcz3eXN3egL4pPSk3ryJamppL0ZzsxP4YbTkON7_dobzzaphEtcUOOxPMFl2s_FYIoxNZlsmob3XWa3pU0MmT.8_FC7lEuZ6cdukTAdSQt0P0JO8aEHVy7HWqmMDSBMNOGoL9j4BaIK4RLsjGjvdjBIkVDeMBpuv0_Ir3BbQUSZ_BgZu1i.y32MbjUkxnheANBe7mMg4KPmch0WbxFifW_pMMxxAGvnfTyzay Received: from [67.151.79.74] by web65605.mail.ac4.yahoo.com via HTTP; Tue, 28 Apr 2009 12:16:39 PDT X-RocketYMMF: emailsumitgarg X-Mailer: YahooMailWebService/0.7.289.1 Date: Tue, 28 Apr 2009 12:16:39 -0700 (PDT) From: Sumit Garg To: sipcore@ietf.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [sipcore] Target URI and History Info bis X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: sgarg@cedarpointcom.com List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Apr 2009 19:15:19 -0000 It would be nice if the examples section included PSTN interworking too.. My problem: ISUP to SIP: Incoming redirection count is say 3. A redirection occurs... The new count should be? 3.1 OR 4 OR 1.1.1.1 Also, we may not have enough information to create the complete hierarchy of History-Info headers... Similarly, how to interpret the data in SIP to ISUP scenarios? Lack of this clarity in interworking is one reason why Diversion is in use even after all these years... -Sumit -----Original Message----- From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behalf Of Mary Barnes Sent: Friday, April 24, 2009 4:55 PM To: Hans Erik van Elburg; Gonzalo Camarillo Cc: SIPCORE Subject: Re: [sipcore] Target URI and History Info bis Just to re-iterate once more, 4244bis already contains a superset of the normative text for History-Info header from the current target-uri document. Francois has proposed a fairly straightforward path for 4244bis that should allow us to avoid any of the hurdles and open ended debates as to History-Info issues - the known issues are quite straight-forward to solve and the issues at hand really are providing a solution for target-uri. The idea that the target-uri document would progress much quicker than 4244bis is a red herring - in particular based on my comments that you need more changes to 4244 to support target-uri than just the new tags. Mary. Forever, Sumit "The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man." -- George Bernard Shaw From dworley@nortel.com Tue Apr 28 13:49:22 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 424E728C1F6 for ; Tue, 28 Apr 2009 13:49:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.649 X-Spam-Level: X-Spam-Status: No, score=-6.649 tagged_above=-999 required=5 tests=[AWL=-0.050, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O2facbEVWK9r for ; Tue, 28 Apr 2009 13:49:21 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id 59B893A6D69 for ; Tue, 28 Apr 2009 13:49:21 -0700 (PDT) Received: from zrtphxs1.corp.nortel.com (casmtp.ca.nortel.com [47.140.202.46]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id n3SKobv27098; Tue, 28 Apr 2009 20:50:38 GMT Received: from [47.141.31.239] ([47.141.31.239]) by zrtphxs1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 28 Apr 2009 16:50:21 -0400 From: "Dale Worley" To: Dean Willis In-Reply-To: <49F742EE.30504@softarmor.com> References: <0D5F89FAC29E2C41B98A6A762007F5D001D4A39A@GBNTHT12009MSX.gb002.siemens.net> <49F5B3FE.8030104@cisco.com> <28B7C3AA2A7ABA4A841F11217ABE78D67590BF97@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <49F5C2C4.70501@cisco.com> <49F71501.2020300@cisco.com> <49F742EE.30504@softarmor.com> Content-Type: text/plain Organization: Nortel Networks Date: Tue, 28 Apr 2009 16:50:20 -0400 Message-Id: <1240951820.18691.51.camel@victoria-pingtel-com.us.nortel.com> Mime-Version: 1.0 X-Mailer: Evolution 2.12.3 (2.12.3-5.fc8) Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 28 Apr 2009 20:50:21.0195 (UTC) FILETIME=[F219E5B0:01C9C842] Cc: SIPCORE Subject: Re: [sipcore] Question on Require in responses X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Apr 2009 20:49:22 -0000 On Tue, 2009-04-28 at 12:54 -0500, Dean Willis wrote: > A Supported or Require usage of an option ALWAYS says only that someone > (sender or receiver) is capable of supporting the extension. > > Some extension definitions define when the extension will and will not > be used (for exampple "A UA supporting this extension will engage the > extension whenever it receives a request having the option tag for this > extension in a Supported header field") but this is outside of the > semantic of Require. That is what they *should* mean, but we've often overloaded them with additional semantics. Usually, Supported in a request means "apply this extension if you understand it" and Supported in a response means "I have applied this extension to processing this request". Dale From dworley@nortel.com Tue Apr 28 15:34:04 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DF34D3A6D3E for ; Tue, 28 Apr 2009 15:34:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.648 X-Spam-Level: X-Spam-Status: No, score=-6.648 tagged_above=-999 required=5 tests=[AWL=-0.049, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2u7y4lkfJbcB for ; Tue, 28 Apr 2009 15:34:03 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id 2489D3A6C47 for ; Tue, 28 Apr 2009 15:34:03 -0700 (PDT) Received: from zrtphxs1.corp.nortel.com (zrtphxs1.corp.nortel.com [47.140.202.46]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id n3SMZMv18500 for ; Tue, 28 Apr 2009 22:35:22 GMT Received: from [47.141.31.239] ([47.141.31.239]) by zrtphxs1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 28 Apr 2009 18:35:15 -0400 From: "Dale Worley" To: SIPCORE Content-Type: text/plain Organization: Nortel Networks Date: Tue, 28 Apr 2009 18:35:14 -0400 Message-Id: <1240958114.18691.54.camel@victoria-pingtel-com.us.nortel.com> Mime-Version: 1.0 X-Mailer: Evolution 2.12.3 (2.12.3-5.fc8) Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 28 Apr 2009 22:35:15.0730 (UTC) FILETIME=[99EFB720:01C9C851] Subject: [sipcore] Comments on draft-roach-sipcore-rfc3265bis-00 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Apr 2009 22:34:05 -0000 I'm glad we're cleaning up how we define events. But there are a few things left to clean up: ** Technical * What is a resource? It looks like the draft cleans up the question of what is a resource, in that section 3.1.2 paragraph 2 states that the request-URI identifies the resource in question. However, given the error in the first sentence of that paragraph (discussed below), I'd suggest promoting the statement that the request-URI identifies the resource to the beginning of the paragraph. * What is state? There is a lot of ambiguity over what constitutes the "state" that the event system transmits. These ambiguities bedevil attempts to implement generic event system "toolkits" as well as complicating the definition of new event packages. (In the call-completion committee we've run into trouble with this.) In theory, we want the resource to have a certain set of state information, and that state information progresses through a series of different values over time. Each time the state changes, every subscriber to that state would be notified of the new state value. We further envision that a subscriber might supply a "filter" which is applied to every state value; then only the output of the filter would be sent to the subscriber, and the subscriber would be notified when the filtered state changed. Layered onto this nice, clean system are a set of issues, most of which we haven't addressed systematically: - If we want to be able to send state deltas, there needs to be a defined way of taking the difference between two state values. (This is well-described in the draft.) - In most event package definitions, we include the version number and the partial/full indication *in* the state, rather than treating them as *attributes of* the state value contained in a NOTIFY. Since most definitions require the version number to start counting from 0 independently for each subscription, the version number is clearly not part of the state itself. - We haven't been clear about the difference between "state" (which possesses values over time) and "events" (which happen instantly). Generally, the event packages have been consistent in using state rather than events. (E.g., the dialog package's element has an attribute telling how a dialog entered its current state, but that value is actually state, since it is "historical information", a new subscriber could properly see the same value.) State-orientation makes implementation easier, although it has some unspoken implications; e.g., since notifications may be missed in some way, the subscriber may see fewer state transitions than did thenotifier, and so the event package must be organized so that this is not a problem. But we still have a tendency to use the word "event" too much, even in the name of the mechanism. For instance, in the abstract: The purpose of this extension is to provide an extensible framework by which SIP nodes can request notification from remote nodes indicating that certain events have occurred. Similarly, 3.2.1 says: NOTIFY bodies are expected to provide additional details about the nature of the event which has occurred and the resultant resource state. The essential point is that the only *events* that can be reported are the changes in an ongoing *state value*. Though we've been consistent about that fact, it's not clearly stated anywhere. - Many event packages contain data which is expected to change frequently, but we do not expect each change to cause sending of the state value. For example, the dialog event package contains "duration" elements telling how long each dialog has been established, in seconds. Clearly, this value changes every second. Similarly, the "reg" event package contains the CSeq value of the most-recent registration of a contact. Changes in either of these values are not intended to cause notification, but that is not stated in the package definitions, nor is the possibility made clear in the event framework. - In principle, the state should not be affected by who has subscribed to received notifications for it. But there are circumstances where we want to be aware of the set of subscribers, and to be able to present differing information to them. The first job can probably be done (in principle) by examining the "winfo" state, but I don't know of a solution to the second. * Expiration time There is a problem regarding how the expiration time of a subscription is indicated that I don't think has ever been resolved. It probably isn't a problem in practice, but it would help if we agreed on a solution. The difficulty regards how the subscriber should track the end-of-subscription time that is established when a re-subscribe is done. The subscriber will receive a response to its SUBSCRIBE, and also the NOTIFY that it stimulates. It may also receive other NOTIFYs stimulated by state changes. All of these carry expiration times, or rather, the length of time from the present that the subscription will last. The various NOTIFYs can be put in order by their CSeqs, and the latest one clearly supersedes the others. But the relationship between a received NOTIFY and a success response to a SUBSCRIBE is harder to discern, as the subscriber does not know the order in which they were sent, and so does not know which represents the most recent state of the notifier. I think this problem is obviated by the fact that the notifier must always send a NOTIFY after receiving any SUBSCRIBE, so that the subscriber can in pratice disregard SUBSCRIBE responses, assuming that the network is reliable. But if we take this interpretation, then the wording in the draft should be adjusted in a number of places where it gives equal respect to the expiration time reported in a SUBSCRIBE response and that in a NOTIFY. If we do not assume that the subscriber can reliably get a NOTIFY from every SUBSCRIBE, then working out a reliable solution is more difficult, due to the race condition. There are related problems regarding terminology. The "length of a subscription" can mean two things, the "time from present" that it expires, or the absolute endpoint of the subscription. The draft says in various circumstances that a subscription cannot be lengthened without being specific what this means. As far as I can tell: when processing a SUBSCRIBE, a notifier must update the subscription endpoint of the subscription so that the time from present is no larger than what the subscriber requested (which is likely later than the previous endpoint); a notifier may unilaterally bring sooner the endpoint of a subscription so long as it notifies the subscriber; a subscriber's refresh duration request is unconstrained (in that it may require bringing forward the endpoint of the subscription, as well as postponing it). Note that if we tighten up some of the previously-stated rules, the race condition problem becomes easier to solve. For instance, if we demand that a re-subscribe can never bring forward the endpoint (excepting if it makes the endpoint be now, i.e., terminating the subscription), then the subscriber can always trust the *furthest* endpoint that it has been informed of (unless it sees a termination). * Notifier migration Notifier migration is an interesting concept and seems like it might be very useful. But how does a subscriber take advantage of it? The text in 4.4.2 assumes that the subscriber will send a new out-of-dialog SUBSCRIBE to whatever URI it did originally. But will that obtain an alternative notifier for the resource whose notifier just ceased? The possibilities of SIP routing make that doubtful. What we want is for the notifier to give the subscriber a globally-routable URI that will reach an alternative notifier, but there seems to be no mechanism to carry the URI. ** Editorial * section 2 The definition of "subscription" doesn't mention that the existence of a subscription means that the notifier will send state updates to the subscriber. * section 3.1 This paragraph should say something like "The SUBSCRIBE method is used to requrest the creation of a subscription which will send current state and state updates from a remote node." * section 3.1.2 The Request URI of a SUBSCRIBE request, most importantly, contains enough information to route the request to the appropriate entity per the request routing procedures outlined in SIP [RFC3261]. This is not necessarily true -- the routing is also affected by any Route headers in the request. In sipX, we use that feature so that we can present to the notifier a resource name (request-URI) that need not be the same as the SIP URI of the notifier. * section 4.1.3 NOTIFY requests MUST contain "Subscription-State" header fields which indicate the status of the subscription. This is an instance where plurals should be made singular for clarity: A NOTIFY request MUST contain a "Subscription-State" header field which indicates the status of the subscription. * section 4.1.3 giveup: The subscription has been terminated because the notifier could not obtain authorization in a timely fashion. If a "retry- after" parameter is also present, the client SHOULD wait at least the number of seconds specified by that parameter before attempting to re-subscribe; otherwise, the client MAY retry immediately, but will likely get put back into pending state. The last clause would read better as: the client MAY retry immediately, although the new subscription will likely go into the pending state. The subscription doesn't really "get put back" into pending, since it is now in terminated. * section 4.2.1.2 Note that a NOTIFY message is always sent immediately after any 200- class response to a SUBSCRIBE request, regardless of whether the subscription has already been authorized. Perhaps it is better to say: Note that a NOTIFY message is always sent immediately after any 200-class response to a SUBSCRIBE request, regardless of the state of the created subscription (e.g., pending). * section 4.2.1.4. Refreshing of Subscriptions When a notifier receives a subscription refresh, assuming that the subscriber is still authorized, the notifier updates the expiration time for subscription. As with the initial subscription, the server MAY shorten the amount of time until expiration, but MUST NOT increase it. Here is one of the places where the discussion of "shortening expiration time" is ambiguous. Reading it literally, it means that the notifier cannot increase the absolute expiration time *relative to what it was before the SUBSCRIBE arrived*, as "the amount of time until expiration" is an attribute of the subscription. Of course, what is meant, the notifier sets a new expiration time which may be no longer-from-present that the duration requested in the SUBSCRIBE. * section 4.4.1 NOTIFY requests are matched to such SUBSCRIBE requests if they contain the same "Call-ID", a "To" header field "tag" parameter which matches the "From" header field "tag" parameter of the SUBSCRIBE, and the same "Event" header field. Rules for comparisons of the "Event" header fields are described in Section 8.2.1. This is awkward. How about: NOTIFY and SUBSCRIBE requests are within the same subscription usage if they contain the same "Call-ID", a "To" header field "tag" parameter which matches the "From" header field "tag" parameter of the SUBSCRIBE, and the same "Event" header field. Rules for comparisons of the "Event" header fields are described in Section 8.2.1. * section 4.4.2. Notifier migration is an interesting concept. But note that the text is incorrect: Upon receipt of this NOTIFY message, the subscriber SHOULD attempt to re-subscribe (as described in the preceding sections). Note that this subscription is established on a new dialog, and does not re-use the route set from the previous subscription dialog. It's not correct to say the subscriber is "re-subscribing" (in the sense of the draft). There is also the technical question of what request-URI the subscriber should use to re-subscribe. (see above) * section 4.5.1 Because GRUUs are guaranteed to route to a *** a specific device, this Contains duplicate word "a". * section 5.1 When designing an event package using the methods described in this document for event notification, it is important to consider: is SIP an appropriate mechanism for the problem set? Is SIP being selected The initial "is" of the clauses are not consistently capitalized. * section 5.3 Any event package that supports delta changes to states MUST include a version number that increases by exactly one for each NOTIFY transaction in a subscription. And it must include a full/partial state indicator. * section 5.4 Event packages are not required to reiterate any of the behavior described in this document, although they may choose to do so for clarity or emphasis. In general, though, such packages are expected to describe only the behavior that extends or modifies the behavior described in this document. This reads strangely, as it suggests that an event package description might contradict the RFC. * sectin 5.4.3 It is expected that most, but not all, event packages will define syntax and semantics for SUBSCRIBE method bodies; This reads strangely, since only one defined event package has SUBSCRIBE bodies. * section 5.4.7 and whether state information is complete or deltas for notifications This is awkwardly phrased. Perhaps end the sentence before this clause and continue: It also includes whether state deltas can be used, and if so, how they are interpreted by the subscriber to update its record of the state; see Section 5.3. * section 7 The IANA Considerations section does not name the new SUBSCRIBE and NOTIFY methods, which is needs to do in order to register the methods. (RFC 3265 doesn't do this either, although the IANA database entries for SUBSCRIBE and NOTIFY references RFC 3265.) Dale From dean.willis@softarmor.com Tue Apr 28 16:01:35 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C6C323A6B27 for ; Tue, 28 Apr 2009 16:01:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.554 X-Spam-Level: X-Spam-Status: No, score=-2.554 tagged_above=-999 required=5 tests=[AWL=0.045, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hEy9qCU2vB6j for ; Tue, 28 Apr 2009 16:01:35 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 5BE313A6ACE for ; Tue, 28 Apr 2009 16:01:34 -0700 (PDT) Received: from [192.168.2.102] (cpe-72-181-150-177.tx.res.rr.com [72.181.150.177]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id n3SN2phO004489 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 28 Apr 2009 18:02:53 -0500 Message-Id: <969BE13A-AEC4-4475-9B0E-04C8CC84A26F@softarmor.com> From: Dean Willis To: Christer Holmberg In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Tue, 28 Apr 2009 18:02:46 -0500 References: <49F178CE.8000809@ericsson.com><0ECC036E-2B21-49D5-AC42-1FEC8EC447BE@softarmor.com><49F5D64B.20008@nostrum.com><49F6194E.40006@nostrum.com> X-Mailer: Apple Mail (2.930.3) Cc: SIPCORE Subject: Re: [sipcore] Long reply to: Target URI and History Info bis X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Apr 2009 23:01:35 -0000 On Apr 28, 2009, at 12:56 PM, Christer Holmberg wrote: > > Hi, > > I don't think the problem we are trying to solve is "delivery of > parameters", or "user-to-user parameters". The problem we are tying to > solve is to deliver the original target URI (which, of course, may > include parameters). Why do we need to deliver the original target URI and its parameters? What useful purpose does this serve? Could that purpose be better served by a different mechanism? > The proposal from me and Hans Erik could have been to use a dedicated > Target header. That would have solved the problem, only the problem > and > nothing but the problem. Yet we know that sometimes, the "server in the middle" legitimately needs to replace some part of the parameter set. > But, the discussion outcome, and WG decission, was then to use > History-Info. Good or bad, but that is the decission the WG made. I suspect a large part of the WG was confused by the discussion leading up to the decision point. We have a tendency to get caught up in polishing the bull's horn while we are being gored . . . the problem is not "the horn", it's the "standing in front of a charging bull" part.. -- Dean From dean.willis@softarmor.com Tue Apr 28 16:12:20 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6CD653A6A62 for ; Tue, 28 Apr 2009 16:12:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.555 X-Spam-Level: X-Spam-Status: No, score=-2.555 tagged_above=-999 required=5 tests=[AWL=0.044, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F8ZH6dcewd0N for ; Tue, 28 Apr 2009 16:12:19 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 544973A6970 for ; Tue, 28 Apr 2009 16:12:19 -0700 (PDT) Received: from [192.168.2.102] (cpe-72-181-150-177.tx.res.rr.com [72.181.150.177]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id n3SNDZjE004583 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 28 Apr 2009 18:13:37 -0500 Message-Id: <6B78E793-0C48-427E-8895-337D5F592957@softarmor.com> From: Dean Willis To: Paul Kyzivat In-Reply-To: <49F75022.4010905@cisco.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Tue, 28 Apr 2009 18:13:30 -0500 References: <0D5F89FAC29E2C41B98A6A762007F5D001D4A39A@GBNTHT12009MSX.gb002.siemens.net><49F5B3FE.8030104@cisco.com><28B7C3AA2A7ABA4A841F11217ABE78D67590BF97@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <49F5C2C4.70501@cisco.com> <49F71501.2020300@cisco.com> <49F742EE.30504@softarmor.com> <49F75022.4010905@cisco.com> X-Mailer: Apple Mail (2.930.3) Cc: SIPCORE Subject: Re: [sipcore] Question on Require in responses X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Apr 2009 23:12:20 -0000 On Apr 28, 2009, at 1:51 PM, Paul Kyzivat wrote: > > > Dean Willis wrote: >> Paul Kyzivat wrote: >>> Actually, I think it is much clearer with Timer. >>> That option only says you are capable of supporting the feature, and >>> does not say if you want to use it or not. Headers are used to >>> negotiate >>> the use of the feature. Once the use of the timer is negotiated, it >>> remains only until the next reINVITE or UPDATE, where it must be >>> renegotiated. >>> >> A Supported or Require usage of an option ALWAYS says only that >> someone >> (sender or receiver) is capable of supporting the extension. > > Good theory, but not entirely true. > > This thread has already pointed out the use of Require:100rel in a > response. 3262 says: > > If a provisional response is received for an initial request, and > that response contains a Require header field containing the option > tag 100rel, the response is to be sent reliably. If the response is > a 100 (Trying) (as opposed to 101 to 199), this option tag MUST be > ignored, and the procedures below MUST NOT be used. > > The provisional response MUST establish a dialog if one is not yet > created. > > Assuming the response is to be transmitted reliably, the UAC MUST > create a new request with method PRACK. This request is sent within > the dialog associated with the provisional response (indeed, the > provisional response may have created the dialog). PRACK requests > MAY contain bodies, which are interpreted according to their type > and > disposition. > > This phrasing certainly says to me that the Require:100rel means > that the UAC MUST enable the feature. No, it's simply telling the UAC that 100-rel was applied by the UAS. A 100-rel compliant UAC responds to this knowledge by generating a PRACK transaction. It was not the Require:100-rel that compelled this behavior; rather it was specified behavior of RFC 3262 that compelled it. As you point out, any other technique that revealed the usage of 100-rel by the UAS could have informed the UAC to generate the PRACK. One could quite reasonably argue that this was not well executed in the text of RFC 3262. But then again, just looking at the 100-REL state machine is enough to argue for tossing that whole spec and all its little friends (preconditions, early-session, ad nausea) in the dustbin. -- Dean > > > Of course it didn't need to be written that way. There is something > else in a response that indicates it is reliable: the RSeq header. > It would have been sufficient to say that if the UAC Supports > 100rel, and receives a response with an RSeq header, then it must > send a PRACK. And the Require:100rel in the response would simply > have been one more assurance that the UAC in fact supports it. (In > addition to it having indicated Support in the request.) > >> Some extension definitions define when the extension will and will >> not >> be used (for exampple "A UA supporting this extension will engage the >> extension whenever it receives a request having the option tag for >> this >> extension in a Supported header field") but this is outside of the >> semantic of Require. >> A "Require" header is just a shortcut for doing an "OPIONS", and then >> sending the extension-requiring request only if the result of the >> OPTIONS request indicates support for the required extension. >> People clearly don't get this, and we've had to push the issue on >> almost >> every extension. People clearly want inclusion of an option-tag in a >> require to force the other end to engage the "required behavior", >> but it >> just doesn't work that way. It's a mechanism for negotiating a common >> understanding of the protocol, not for authorization control. >> I think this is why we had the confusion about option-tag definitions >> that led to precluding informational-track extensions from >> registering >> options tags. > > I agree with you, but our own specs have helped to create this > confusion. > > Thanks, > Paul > From christer.holmberg@ericsson.com Wed Apr 29 00:46:09 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8CCA33A687B for ; Wed, 29 Apr 2009 00:46:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.817 X-Spam-Level: X-Spam-Status: No, score=-5.817 tagged_above=-999 required=5 tests=[AWL=0.432, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ewLoffcw5l5g for ; Wed, 29 Apr 2009 00:46:08 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id CD3783A686D for ; Wed, 29 Apr 2009 00:45:51 -0700 (PDT) X-AuditID: c1b4fb3c-b7b4bae000001105-1a-49f806008972 Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw3.ericsson.se (Symantec Mail Security) with SMTP id 77.52.04357.00608F94; Wed, 29 Apr 2009 09:47:12 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 29 Apr 2009 09:47:12 +0200 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: Wed, 29 Apr 2009 09:47:17 +0200 Message-ID: In-Reply-To: <969BE13A-AEC4-4475-9B0E-04C8CC84A26F@softarmor.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] Long reply to: Target URI and History Info bis Thread-Index: AcnIVXeumZdho4uDQguOYBFH2EE5yQASCD5w References: <49F178CE.8000809@ericsson.com><0ECC036E-2B21-49D5-AC42-1FEC8EC447BE@softarmor.com><49F5D64B.20008@nostrum.com><49F6194E.40006@nostrum.com> <969BE13A-AEC4-4475-9B0E-04C8CC84A26F@softarmor.com> From: "Christer Holmberg" To: "Dean Willis" X-OriginalArrivalTime: 29 Apr 2009 07:47:12.0231 (UTC) FILETIME=[B4E8BF70:01C9C89E] X-Brightmail-Tracker: AAAAAA== Cc: SIPCORE Subject: Re: [sipcore] Long reply to: Target URI and History Info bis X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Apr 2009 07:46:09 -0000 Hi,=20 >>I don't think the problem we are trying to solve is "delivery of=20 >>parameters", or "user-to-user parameters". The problem we=20 >>are tying to solve is to deliver the original target URI (which, of course, may=20 >>include parameters). > >Why do we need to deliver the original target URI and its parameters? =20 >What useful purpose does this serve?=20 Chapter 4 of the draft contains use cases where it is needed. >Could that purpose be better served by a different mechanism? I don't know. The proposals we had on the table were the ua-loose-route draft and the target-draft, and then it was decided to use H-I. Anyone could have provided different mechanism proposals. In fact, you and/or Keith even explicitly gave a deadline for mechanism proposals, if I remember correctly. Regards, Christer From christer.holmberg@ericsson.com Wed Apr 29 01:01:35 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 04EC93A6A63 for ; Wed, 29 Apr 2009 01:01:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.519 X-Spam-Level: X-Spam-Status: No, score=-5.519 tagged_above=-999 required=5 tests=[AWL=0.130, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_75=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7z0REzGRBYX5 for ; Wed, 29 Apr 2009 01:01:34 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id AF7563A6893 for ; Wed, 29 Apr 2009 01:01:33 -0700 (PDT) X-AuditID: c1b4fb3e-b7bb8ae000006a07-9f-49f809ad59ea Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw4.ericsson.se (Symantec Mail Security) with SMTP id BC.BA.27143.DA908F94; Wed, 29 Apr 2009 10:02:54 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 29 Apr 2009 10:02:53 +0200 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: Wed, 29 Apr 2009 10:02:59 +0200 Message-ID: In-Reply-To: <6B78E793-0C48-427E-8895-337D5F592957@softarmor.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] Question on Require in responses Thread-Index: AcnIVwAUj9f82yX/Tx+Ysp96MSaQpAASPa8Q References: <0D5F89FAC29E2C41B98A6A762007F5D001D4A39A@GBNTHT12009MSX.gb002.siemens.net><49F5B3FE.8030104@cisco.com><28B7C3AA2A7ABA4A841F11217ABE78D67590BF97@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <49F5C2C4.70501@cisco.com> <49F71501.2020300@cisco.com> <49F742EE.30504@softarmor.com> <49F75022.4010905@cisco.com> <6B78E793-0C48-427E-8895-337D5F592957@softarmor.com> From: "Christer Holmberg" To: "Dean Willis" , "Paul Kyzivat" X-OriginalArrivalTime: 29 Apr 2009 08:02:53.0888 (UTC) FILETIME=[E62E3400:01C9C8A0] X-Brightmail-Tracker: AAAAAA== Cc: SIPCORE Subject: Re: [sipcore] Question on Require in responses X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Apr 2009 08:01:35 -0000 Hi,=20 >>>A Supported or Require usage of an option ALWAYS says only that=20 >>>someone (sender or receiver) is capable of supporting the extension. >> >>Good theory, but not entirely true. >> >>This thread has already pointed out the use of Require:100rel in a=20 >>response. 3262 says: >> >> If a provisional response is received for an initial request, and >> that response contains a Require header field containing the option >> tag 100rel, the response is to be sent reliably. If the response is >> a 100 (Trying) (as opposed to 101 to 199), this option tag MUST be >> ignored, and the procedures below MUST NOT be used. >> >> The provisional response MUST establish a dialog if one is not yet >> created. >> >> Assuming the response is to be transmitted reliably, the UAC MUST >> create a new request with method PRACK. This request is sent within >> the dialog associated with the provisional response (indeed, the >> provisional response may have created the dialog). PRACK requests >> MAY contain bodies, which are interpreted according to their type and >> disposition. >> >>This phrasing certainly says to me that the Require:100rel means that=20 >>the UAC MUST enable the feature. >=20 >No, it's simply telling the UAC that 100-rel was applied by=20 >the UAS. A 100-rel compliant UAC responds to this knowledge=20 >by generating a PRACK transaction. It was not the=20 >Require:100-rel that compelled this behavior; rather it was=20 >specified behavior of RFC 3262 that compelled it. As you=20 >point out, any other technique that revealed the usage of=20 >100-rel by the UAS could have informed the UAC to generate the PRACK. >=20 >One could quite reasonably argue that this was not well=20 >executed in the text of RFC 3262. But then again, just=20 >looking at the 100-REL state machine is enough to argue for=20 >tossing that whole spec and all its little friends=20 >(preconditions, early-session, ad nausea) in the dustbin. I was talking more about the meaning of Require in REQUESTs. In my opinion, Require:100rel in the REQUEST means that the UAS not only must support it, but that the UAS must only use it if sending non-100 provisional responses. The same thing goes for preconditions. If the UAC in the REQUEST require preconditions, it does not only mean that UAS must support it, but that the UAS must also use it. In fact, I think the same thing also goes for timer. Require:timer in the REQUEST means that the UAS must not only support session-timer, but that the UAS must start the session timer negotiation. What is the use in requireing the UAS to support foo, if you don't also require it to use foo (if applicable)? Regards, Christer From ietf.hanserik@gmail.com Wed Apr 29 01:13:59 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 89AEA3A6A63 for ; Wed, 29 Apr 2009 01:13:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.823 X-Spam-Level: X-Spam-Status: No, score=-1.823 tagged_above=-999 required=5 tests=[AWL=0.775, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZO+SrIw6l1zu for ; Wed, 29 Apr 2009 01:13:58 -0700 (PDT) Received: from mail-ew0-f176.google.com (mail-ew0-f176.google.com [209.85.219.176]) by core3.amsl.com (Postfix) with ESMTP id 412F63A681E for ; Wed, 29 Apr 2009 01:13:58 -0700 (PDT) Received: by ewy24 with SMTP id 24so1073844ewy.37 for ; Wed, 29 Apr 2009 01:15:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=kV11iMGMmv5riMNqDWPmymv1IHJtM4dsL7mwoPQH0AE=; b=giwntX1S7xoGxKYokCcW76deQaqfqT9hVCdG1sKpZDM7A1Gcsut9/U1EeZrcNIWlH7 f14YmnNgY3K79XmsjrCyOQypgJ6EOBRs1uFTNwEibz7bjY9DMqDfbgOdV+rxIoGThvzl Vv/fHys8q87Ca6aXgXRHCab1T32MkuHf1R/DM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=kKb3V05mLPfmz/JTweb5GMb/Pfwmff/Wa0JSIRgmxRuwPNvJWqswCF0uNR3ncxGZdx Rvn22nougN+84jpvFv1p7pVh+H2sQ4i/47n2toBfPHkSPD2aahchO3KN39I2HV9ZpuM2 Uyxd0/DI522oHvDPXWlQ4P4pOQ0bPTg1W07h0= MIME-Version: 1.0 Received: by 10.216.70.205 with SMTP id p55mr16762wed.55.1240992919598; Wed, 29 Apr 2009 01:15:19 -0700 (PDT) In-Reply-To: <969BE13A-AEC4-4475-9B0E-04C8CC84A26F@softarmor.com> References: <49F178CE.8000809@ericsson.com> <0ECC036E-2B21-49D5-AC42-1FEC8EC447BE@softarmor.com> <49F5D64B.20008@nostrum.com> <49F6194E.40006@nostrum.com> <969BE13A-AEC4-4475-9B0E-04C8CC84A26F@softarmor.com> Date: Wed, 29 Apr 2009 10:15:19 +0200 Message-ID: <9ae56b1e0904290115x82304d3y2daad5cb1dd74eaf@mail.gmail.com> From: Hans Erik van Elburg To: Dean Willis Content-Type: multipart/alternative; boundary=00504502c74e2438040468ad2e1f Cc: SIPCORE Subject: Re: [sipcore] Long reply to: Target URI and History Info bis X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Apr 2009 08:13:59 -0000 --00504502c74e2438040468ad2e1f Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Dean, I truely think that you are trying to solve a different problem then was set out in the target-uri discussion. Of course this is a usefull discussion but I think it deserves a separate draft/discussion item of its own. Best Regards, /Hans Erik van Elburg On Wed, Apr 29, 2009 at 1:02 AM, Dean Willis wrote: > > On Apr 28, 2009, at 12:56 PM, Christer Holmberg wrote: > > >> Hi, >> >> I don't think the problem we are trying to solve is "delivery of >> parameters", or "user-to-user parameters". The problem we are tying to >> solve is to deliver the original target URI (which, of course, may >> include parameters). >> > > Why do we need to deliver the original target URI and its parameters? What > useful purpose does this serve? Could that purpose be better served by a > different mechanism? > > The proposal from me and Hans Erik could have been to use a dedicated >> Target header. That would have solved the problem, only the problem and >> nothing but the problem. >> > > Yet we know that sometimes, the "server in the middle" legitimately needs > to replace some part of the parameter set. > > But, the discussion outcome, and WG decission, was then to use >> History-Info. Good or bad, but that is the decission the WG made. >> > > I suspect a large part of the WG was confused by the discussion leading up > to the decision point. We have a tendency to get caught up in polishing the > bull's horn while we are being gored . . . the problem is not "the horn", > it's the "standing in front of a charging bull" part.. > > > -- > Dean > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > --00504502c74e2438040468ad2e1f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Dean,

I truely think that you are trying to solve a different probl= em then was set out in the target-uri discussion. Of course this is a usefu= ll discussion but I think it deserves a separate draft/discussion item of i= ts own.

Best Regards,
/Hans Erik van Elburg


On Wed, Apr 29, 2009 at 1:02 AM, Dean Wi= llis <dea= n.willis@softarmor.com> wrote:

On Apr 28, 2009, at 12:56 PM, Christer Holmberg wrote:


Hi,

I don't think the problem we are trying to solve is "delivery of parameters", or "user-to-user parameters". The problem we ar= e tying to
solve is to deliver the original target URI (which, of course, may
include parameters).

Why do we need to deliver the original target URI and its parameters? What = useful purpose does this serve? Could that purpose be better served by a di= fferent mechanism?


The proposal from me and Hans Erik could have been to use a dedicated
Target header. That would have solved the problem, only the problem and
nothing but the problem.

Yet we know that sometimes, the "server in the middle" legitimate= ly needs to replace some part of the parameter set.


But, the discussion outcome, and WG decission, was then to use
History-Info. Good or bad, but that is the decission the WG made.

I suspect a large part of the WG was confused by the discussion leading up = to the decision point. We have a tendency to get caught up in polishing the= bull's horn while we are being gored . . . the problem is not "th= e horn", it's the "standing in front of a charging bull"= part..


--
Dean
_______________________________________________
sipcore mailing list
sipcore@ietf.org<= br> https://www.ietf.org/mailman/listinfo/sipcore

--00504502c74e2438040468ad2e1f-- From fluffy@cisco.com Wed Apr 29 10:11:59 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5B1A73A69F8 for ; Wed, 29 Apr 2009 10:11:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.593 X-Spam-Level: X-Spam-Status: No, score=-106.593 tagged_above=-999 required=5 tests=[AWL=0.006, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nmo4eO1XY7Tq for ; Wed, 29 Apr 2009 10:11:58 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 958F93A6ED5 for ; Wed, 29 Apr 2009 10:11:52 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,267,1238976000"; d="scan'208";a="34620776" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-4.cisco.com with ESMTP; 29 Apr 2009 17:13:15 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id n3THDFP9018337; Wed, 29 Apr 2009 10:13:15 -0700 Received: from [192.168.4.177] (rcdn-fluffy-8711.cisco.com [10.99.9.18]) by sj-core-5.cisco.com (8.13.8/8.13.8) with ESMTP id n3THDC0p014341; Wed, 29 Apr 2009 17:13:13 GMT Message-Id: <26896AF9-3AB9-4523-B133-72179A2D68F4@cisco.com> From: Cullen Jennings To: sipcore@ietf.org Impp: xmpp:cullenfluffyjennings@jabber.org Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Wed, 29 Apr 2009 11:13:12 -0600 X-Mailer: Apple Mail (2.930.3) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2682; t=1241025195; x=1241889195; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=fluffy@cisco.com; z=From:=20Cullen=20Jennings=20 |Subject:=20Summary=20of=20issues=20around=20registering=20 feature=20tags |Sender:=20; bh=iIZksCYUcyL02+63rd0gW1hs1wE9nk30Oy+hcvAlWWQ=; b=XoZ1dtFD//ah9yfXpv8n7iudP3KOTWe8pMMfhpNSXS5MF3CFbr9s14lsdP N+LF7wVvBWEVHoLQTpPNwe8Qd8BmrhYgE0iPnVPDkIJ5pJv50ZBjNact9eNu u6vuJlo8tq; Authentication-Results: sj-dkim-4; header.From=fluffy@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Cc: Gonzalo Camarillo , Hannu Hietalahti Subject: [sipcore] Summary of issues around registering feature tags X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Apr 2009 17:11:59 -0000 3GPP has requested that IANA register two new feature tags (g.3gpp.icsi-ref and g.3gpp.iari-ref) in the global tree. Per RFC 2506 (Section 3.1.2), the policy for registrations in the global tree is expert review. This is the description of the feature tags to be registered: "Each value of the Application Reference media feature-tag indicates the software applications supported by the agent. The values for this tag equal the IMS communication Service Identifier (ICSI) and IMS Application Reference Identifier (IARI) values supported by the agent. The Application Reference media feature tag is defined to fulfill the requirements for forking to an appropriate UE when multiple UEs are registered and dispatch to an appropriate application within the UE based upon the IMS communication Service Identifier (ICSI) and IMS Application Reference Identifier (IARI) values as stated in 3GPP TS 23.228. Multiple tag-values can be included in the Application Reference media feature-tag." Section 12.1 of RFC 3840 states that feature tags that are applicable to SIP and whose meaning is only defined within that usage are to be registered in the SIP tree. Since these feature tags are to be used only within the context of SIP, they would need to be registered in the SIP tree and not in the global tree. The policy for registrations in the SIP tree is IETF Consensus. That is, registrations need to be documented in an RFC approved by the IESG. Regardless of the tree these feature tags would need to be registered in, the expert reviewer indicated that this tags will not contain simple features but rather more complex services or feature sets. Therefore, the expert reviewer did not find it appropriate to register them because Section 2.1 of RFC 2506 states that "media feature tags represent individual and simple characteristics" and that "each media feature tag identifies a single characteristic". Additionally, Section 6 of draft-ietf-sipping-service-identification-03.txt describes the perils of performing declarative service identifications. The way these feature tags are described make them look as if they were going to be used to perform such declarative service identifications. Consequently, 3GPP is encouraged to submit an Internet Draft describing the use of these feature tags so that they can be registered in the SIP tree. Such Internet Draft needs to address the issues discussed in draft-ietf-sipping-service-identification-03.txt clarifying why these tags will not be used to perform declarative service identifications. Cullen Thank you to the people that helped prepare this summary. From dean.willis@softarmor.com Wed Apr 29 12:24:48 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 26D923A706C for ; Wed, 29 Apr 2009 12:24:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.555 X-Spam-Level: X-Spam-Status: No, score=-2.555 tagged_above=-999 required=5 tests=[AWL=0.044, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R2XbEnIZTApF for ; Wed, 29 Apr 2009 12:24:47 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 52CB43A6DD0 for ; Wed, 29 Apr 2009 12:24:47 -0700 (PDT) Received: from [192.168.2.102] (cpe-72-181-150-177.tx.res.rr.com [72.181.150.177]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id n3TJQ3n2013245 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 29 Apr 2009 14:26:04 -0500 Message-Id: <192D1DF8-B444-4FBD-AAA7-7C2F08AE2BC4@softarmor.com> From: Dean Willis To: Hans Erik van Elburg In-Reply-To: <9ae56b1e0904290115x82304d3y2daad5cb1dd74eaf@mail.gmail.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Wed, 29 Apr 2009 14:25:57 -0500 References: <49F178CE.8000809@ericsson.com> <0ECC036E-2B21-49D5-AC42-1FEC8EC447BE@softarmor.com> <49F5D64B.20008@nostrum.com> <49F6194E.40006@nostrum.com> <969BE13A-AEC4-4475-9B0E-04C8CC84A26F@softarmor.com> <9ae56b1e0904290115x82304d3y2daad5cb1dd74eaf@mail.gmail.com> X-Mailer: Apple Mail (2.930.3) Cc: SIPCORE Subject: Re: [sipcore] Long reply to: Target URI and History Info bis X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Apr 2009 19:24:48 -0000 On Apr 29, 2009, at 3:15 AM, Hans Erik van Elburg wrote: > Dean, > > I truely think that you are trying to solve a different problem then > was set out in the target-uri discussion. Of course this is a > usefull discussion but I think it deserves a separate draft/ > discussion item of its own. > That's possible. Historically, the target-URI discussion was started in order to solve the problem I set out initially many many years ago. It's possible I didn't clearly state the problem at that time, and that as a result we have been going down the wrong rabbit hole ever since. -- Dean From dean.willis@softarmor.com Wed Apr 29 12:56:45 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 67B563A6BA0 for ; Wed, 29 Apr 2009 12:56:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.256 X-Spam-Level: X-Spam-Status: No, score=-2.256 tagged_above=-999 required=5 tests=[AWL=-0.257, BAYES_00=-2.599, J_CHICKENPOX_75=0.6] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bJsDNp1FVF9j for ; Wed, 29 Apr 2009 12:56:44 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id ACBA83A7199 for ; Wed, 29 Apr 2009 12:56:41 -0700 (PDT) Received: from [192.168.2.102] (cpe-72-181-150-177.tx.res.rr.com [72.181.150.177]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id n3TJvwnJ013488 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 29 Apr 2009 14:58:00 -0500 Message-Id: <7C450C3A-33F9-450D-B424-4DCD86D5D99A@softarmor.com> From: Dean Willis To: Christer Holmberg In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Wed, 29 Apr 2009 14:57:53 -0500 References: <0D5F89FAC29E2C41B98A6A762007F5D001D4A39A@GBNTHT12009MSX.gb002.siemens.net><49F5B3FE.8030104@cisco.com><28B7C3AA2A7ABA4A841F11217ABE78D67590BF97@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <49F5C2C4.70501@cisco.com> <49F71501.2020300@cisco.com> <49F742EE.30504@softarmor.com> <49F75022.4010905@cisco.com> <6B78E793-0C48-427E-8895-337D5F592957@softarmor.com> X-Mailer: Apple Mail (2.930.3) Cc: SIPCORE Subject: Re: [sipcore] Question on Require in responses X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Apr 2009 19:56:45 -0000 On Apr 29, 2009, at 3:02 AM, Christer Holmberg wrote: >> > > I was talking more about the meaning of Require in REQUESTs. OK. That definition is fairly clear in RFC 3261 20.32 "The Require header field contains a list of option tags, described in Section 19.2. Each option tag defines a SIP extension that MUST be understood to process the request. Frequently, this is used to indicate that a specific set of extension header fields need to be understood. A UAC compliant to this specification MUST only include option tags corresponding to standards-track RFCs" Note that this does not say that the extension must be applied to the request, only that the UAC must understand the extension in order to be able to process the request. > > In my opinion, Require:100rel in the REQUEST means that the UAS not > only > must support it, but that the UAS must only use it if sending non-100 > provisional responses. There's a semantic difference. The Require: 100rel in the request means that the UAS must understand 100rel in order to process the request, and that if it does not, then it must reject the request. RFC 3262 is badly worded, where it says in section 3, UAS behavior: "The UAS MUST send any non-100 provisional response reliably if the initial request contained a Require header field with the option tag 100rel." This should key off the option-tag in the "Supported" header field, not the "Require", and be worded "The UAS SHOULD send any non-100 provisional response reliably if the initial request contained a Supported header field with the option tag 100rel." After all, what happens if the 180 is not sent reliably and doesn't contain an SDP? Does the protocol break? Or do we just wait for the 200 (OK) to complete offer/answer? > > The same thing goes for preconditions. If the UAC in the REQUEST > require > preconditions, it does not only mean that UAS must support it, but > that > the UAS must also use it. Again, what does it break if the UAS understands preconditions, but doesn't actually need to exercise them on its end of the circuit? RFC 3312 is kind of mixed up in its use of Require and Supported, and in fact contradicts RFC 3261 by conflating the two (#261 says you would always put the option tag in Supported and might also put in in Require.). 3312 says: "We define the option tag "precondition" for use in the Require and Supported header fields. An offerer MUST include this tag in the Require header field if the offer contains one or more "mandatory" strength-tags. If all the strength-tags in the description are "optional" or "none", the offerer MUST include this tag in either a Supported header field or in a Require header field. It is, however, RECOMMENDED that the Supported header field be used in this case. The lack of preconditions in the answer would indicate that the answerer did not support this extension." But even here, it's not the presence of the option tag in a Require that drives the UAS to use preconditions, it's the strength-tags in the precondition description. The use in the Require field is only to cause the transaction to fail if the UAS does not support preconditions, and the recommendation is to force this failure only if the preconditions are mandatory, and it encourages call-completion for a non-3312 UAS if the preconditions are optional. > In fact, I think the same thing also goes for timer. Require:timer in > the REQUEST means that the UAS must not only support session-timer, > but > that the UAS must start the session timer negotiation. RFC 4028 specifically says: "The UAC MAY include a Require header field in the request with the value 'timer' to indicate that the UAS must support the session timer to participate in the session. This does not mean that the UAC is requiring the UAS to perform the refreshes, only that it is requiring the UAS to support the extension." So I think you're wrong on that one. > What is the use in requireing the UAS to support foo, if you don't > also > require it to use foo (if applicable)? Because "wanting it to use foo" and "knowing that it is capable of using foo" are two different things, and the difference is frequently dependent on the specfic foo in question. For example, in AnswerMode, we might require that the far end support AutoAnswer, which (even though it supports it), it might not choose to do due to policy. And we clearly say that it's the presence of the Answer-Mode header field that triggers the automatic answering behavior, not the "Require". Otherwise we wouldn't need header fields, we'd just need option tags for all SIP extensions. Let's hammer on that point: The option tag is a means of 1) discovering whether or not the far-end supports a specific extension and of 2) declaring the criticality of understanding that extension relative to satisfying a request and 3) informing the UAC of what extensions were applied to the request in order to generate the response. This is purely a function of capability negotiation, not one of invocation. The extension itself (typically, an extension header field, although there are other types of extensions) is what causes the extension to be invoked. If we did it your way, then we wouldn't need SIP extension header fields. We'd just use option-tags, and extend them with parameters. For example, instead of Referred-By as its own header field, we'd just say "Require: referred-by=bozo@example.com" -- Dean From dworley@nortel.com Wed Apr 29 14:48:00 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2E74528C0E5 for ; Wed, 29 Apr 2009 14:48:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.646 X-Spam-Level: X-Spam-Status: No, score=-6.646 tagged_above=-999 required=5 tests=[AWL=-0.047, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZVrdcxYjvKJb for ; Wed, 29 Apr 2009 14:47:59 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id 2C1C33A71BE for ; Wed, 29 Apr 2009 14:47:59 -0700 (PDT) Received: from zrtphxs1.corp.nortel.com (casmtp.ca.nortel.com [47.140.202.46]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id n3TLnI408495 for ; Wed, 29 Apr 2009 21:49:18 GMT Received: from [47.141.31.239] ([47.141.31.239]) by zrtphxs1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 29 Apr 2009 17:49:03 -0400 From: "Dale Worley" To: sipcore@ietf.org In-Reply-To: <203FB20D-BCD6-4D2C-A5A2-85D77A9B1594@softarmor.com> References: <90F90B9D-2791-4B60-A5EF-F89114C9453E@softarmor.com> <49EE532D.9050602@cisco.com> <203FB20D-BCD6-4D2C-A5A2-85D77A9B1594@softarmor.com> Content-Type: text/plain Organization: Nortel Networks Date: Wed, 29 Apr 2009 17:49:02 -0400 Message-Id: <1241041742.19498.55.camel@victoria-pingtel-com.us.nortel.com> Mime-Version: 1.0 X-Mailer: Evolution 2.12.3 (2.12.3-5.fc8) Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 29 Apr 2009 21:49:03.0437 (UTC) FILETIME=[4FEF1FD0:01C9C914] Subject: Re: [sipcore] ABNF discussion on draft-ietf-subnot-etags X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Apr 2009 21:48:00 -0000 On Tue, 2009-04-21 at 20:47 -0500, Dean Willis wrote: > So I think the proposed grammar as written by Paul here is right, the > canonicalization proposed by BAP is wrong, and the original grammar is > misleading as it reading it requires a specific understanding of ABNF > operator scoping that isn't shared by BAP. Maybe BAP's scoping rules > are wrong, or maybe Scott's and mine are wrong, but we don't benefit > from the ambiguity when a more definitive syntax is available. Uh, what? The precedence rules for IETF ABNF are quite clearly spelled out in section 10 of RFC 5234: 3.10. Operator Precedence The various mechanisms described above have the following precedence, from highest (binding tightest) at the top, to lowest (loosest) at the bottom: Rule name, prose-val, Terminal value Comment Value range Repetition Grouping, Optional Concatenation Alternative Use of the alternative operator, freely mixed with concatenations, can be confusing. Indeed, in every ABNF notation that I've ever seen, concatenation binds tighter than alternation. Relative to what we intend, the original ABNF is wrong and needs to be fixed. Dale From ben@nostrum.com Wed Apr 29 14:49:39 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DF64828C2D5 for ; Wed, 29 Apr 2009 14:49:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.327 X-Spam-Level: X-Spam-Status: No, score=-2.327 tagged_above=-999 required=5 tests=[AWL=0.273, BAYES_00=-2.599, SPF_PASS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id asU7MoT2r90Z for ; Wed, 29 Apr 2009 14:49:39 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id B1ECC28C160 for ; Wed, 29 Apr 2009 14:49:38 -0700 (PDT) Received: from dn3-213.estacado.net (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id n3TLowsc042650 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 29 Apr 2009 16:50:59 -0500 (CDT) (envelope-from ben@nostrum.com) Message-Id: <193E3797-2C8D-44EB-A869-DDDE39B303D9@nostrum.com> From: Ben Campbell To: Dean Willis In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Wed, 29 Apr 2009 16:50:58 -0500 References: <49F178CE.8000809@ericsson.com> <0ECC036E-2B21-49D5-AC42-1FEC8EC447BE@softarmor.com> <49F5D64B.20008@nostrum.com> X-Mailer: Apple Mail (2.930.3) Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Cc: SIPCORE Subject: Re: [sipcore] Long reply to: Target URI and History Info bis X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Apr 2009 21:49:40 -0000 On Apr 27, 2009, at 2:44 PM, Dean Willis wrote: > > On Apr 27, 2009, at 10:59 AM, Adam Roach wrote: >> >> So, for the other half of this puzzle, we need to make sure that >> the parameters you're talking about can be expressed as part of a >> SIP URI, so that they can be communicated to the UAC in the first >> place. >> > > Ah, but they can. It's not any harder than doing it with HTTP. We > just don't use it much since it doesn't work well due to contact- > routing. > Assuming you mean to say that, if we choose to send application parameters in some non URI mechanism (e.g. new headers, bodies, etc), we can still encode that in URIs, in the same way you can encode any arbitrary SIP bits into a URI? If so, that is true--but it makes for an insanely complicated URI, and I wouldn't bet on any given UA handling it correctly. > Instead, we use all sorts of ugly hacks with new SIP headers and > protocol extensions. > > That's why SIP WG never had a charter item on expressing the > parameters as part of the URI, just on fixing the transport mechanism. > -- > Dean > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From dean.willis@softarmor.com Wed Apr 29 17:26:53 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 393543A6EC2 for ; Wed, 29 Apr 2009 17:26:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.553 X-Spam-Level: X-Spam-Status: No, score=-2.553 tagged_above=-999 required=5 tests=[AWL=0.046, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mJg8pCk5HV-N for ; Wed, 29 Apr 2009 17:26:52 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 0341D3A7160 for ; Wed, 29 Apr 2009 17:26:49 -0700 (PDT) Received: from [192.168.2.102] (cpe-72-181-150-177.tx.res.rr.com [72.181.150.177]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id n3U0SAUs015123 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 29 Apr 2009 19:28:12 -0500 Message-Id: <06F3B3D8-BEA3-4B5A-990D-B9E8DCAB1FF1@softarmor.com> From: Dean Willis To: Ben Campbell In-Reply-To: <193E3797-2C8D-44EB-A869-DDDE39B303D9@nostrum.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Wed, 29 Apr 2009 19:28:05 -0500 References: <49F178CE.8000809@ericsson.com> <0ECC036E-2B21-49D5-AC42-1FEC8EC447BE@softarmor.com> <49F5D64B.20008@nostrum.com> <193E3797-2C8D-44EB-A869-DDDE39B303D9@nostrum.com> X-Mailer: Apple Mail (2.930.3) Cc: SIPCORE Subject: Re: [sipcore] Long reply to: Target URI and History Info bis X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Apr 2009 00:26:53 -0000 On Apr 29, 2009, at 4:50 PM, Ben Campbell wrote: > > On Apr 27, 2009, at 2:44 PM, Dean Willis wrote: > >> >> On Apr 27, 2009, at 10:59 AM, Adam Roach wrote: >>> >>> So, for the other half of this puzzle, we need to make sure that >>> the parameters you're talking about can be expressed as part of a >>> SIP URI, so that they can be communicated to the UAC in the first >>> place. >>> >> >> Ah, but they can. It's not any harder than doing it with HTTP. We >> just don't use it much since it doesn't work well due to contact- >> routing. >> > > Assuming you mean to say that, if we choose to send application > parameters in some non URI mechanism (e.g. new headers, bodies, > etc), we can still encode that in URIs, in the same way you can > encode any arbitrary SIP bits into a URI? > > If so, that is true--but it makes for an insanely complicated URI, > and I wouldn't bet on any given UA handling it correctly. No, not what I was saying. I was saying that we know how to encode arbitrary things in the request URI (without encoding them as embedded headers in the request URI) , which makes me sure that what Adam called "the parameters you're talking about" can be expressed as part of a SIP URI. If we can express the parameters in any way, then we can express them as parts of SIP Request-URI , since Request-URI is linguistically complete and has a well-defined grammar for encoding things. I believe what Adam was worrying about was the specification of those things which I wish to encode as parameters; that is, that they be specified as parameters and not as body parts, header fields, or something else. We in fact have an IANA registry for just exactly this task. Let's cast this back in the light of my 11+ year-old fight with the Diversion header -- I thought it should have been encoded in the Request-URI, not encoded in a transport-layer header field. Making it a header field conflated the application with the transport. We should not have needed to extend SIP as a transport protocol and modify the core SIP ABNF just to handle this new application. I feel this way about a LOT of the functionality we've grafted onto SIP through the years, or are still talking about grafting on. The "service identifier" is one example that comes to mind. -- Dean From dean.willis@softarmor.com Wed Apr 29 19:29:35 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 367E428B797 for ; Wed, 29 Apr 2009 19:29:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.554 X-Spam-Level: X-Spam-Status: No, score=-2.554 tagged_above=-999 required=5 tests=[AWL=0.045, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6k8c6mN47041 for ; Wed, 29 Apr 2009 19:29:34 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 752643A6CED for ; Wed, 29 Apr 2009 19:29:34 -0700 (PDT) Received: from [192.168.2.102] (cpe-72-181-150-177.tx.res.rr.com [72.181.150.177]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id n3U2Us0S015633 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Wed, 29 Apr 2009 21:30:56 -0500 Message-Id: <9943B78B-F0A3-4820-9247-9688AE157929@softarmor.com> From: Dean Willis To: Dale Worley In-Reply-To: <1241041742.19498.55.camel@victoria-pingtel-com.us.nortel.com> Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Wed, 29 Apr 2009 21:30:48 -0500 References: <90F90B9D-2791-4B60-A5EF-F89114C9453E@softarmor.com> <49EE532D.9050602@cisco.com> <203FB20D-BCD6-4D2C-A5A2-85D77A9B1594@softarmor.com> <1241041742.19498.55.camel@victoria-pingtel-com.us.nortel.com> X-Mailer: Apple Mail (2.930.3) Cc: sipcore@ietf.org Subject: Re: [sipcore] ABNF discussion on draft-ietf-subnot-etags X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Apr 2009 02:29:35 -0000 On Apr 29, 2009, at 4:49 PM, Dale Worley wrote: > > > Relative to what we intend, the original ABNF is wrong and needs to be > fixed. > That's what I was trying to say in a friendlier way . . . -- Dean From sanjsinh@cisco.com Wed Apr 29 23:02:32 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AC9493A6DE7 for ; Wed, 29 Apr 2009 23:02:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.586 X-Spam-Level: X-Spam-Status: No, score=-6.586 tagged_above=-999 required=5 tests=[AWL=0.013, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FtlwPLtUi0OG for ; Wed, 29 Apr 2009 23:02:31 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 169BB3A6F28 for ; Wed, 29 Apr 2009 23:02:31 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,270,1238976000"; d="scan'208";a="42985984" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 30 Apr 2009 06:03:53 +0000 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n3U63rYr028940; Thu, 30 Apr 2009 02:03:53 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.13.8/8.13.8) with ESMTP id n3U63rb3002486; Thu, 30 Apr 2009 06:03:53 GMT Received: from xmb-rtp-201.amer.cisco.com ([64.102.31.13]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 30 Apr 2009 02:03:53 -0400 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, 30 Apr 2009 02:03:51 -0400 Message-ID: In-Reply-To: <7C450C3A-33F9-450D-B424-4DCD86D5D99A@softarmor.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] Question on Require in responses Thread-Index: AcnJBNOCwBNFTAdEQGm8w4nI7RXgxQAUpRGg References: <0D5F89FAC29E2C41B98A6A762007F5D001D4A39A@GBNTHT12009MSX.gb002.siemens.net><49F5B3FE.8030104@cisco.com><28B7C3AA2A7ABA4A841F11217ABE78D67590BF97@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <49F5C2C4.70501@cisco.com> <49F71501.2020300@cisco.com> <49F742EE.30504@softarmor.com><49F75022.4010905@cisco.com><6B78E793-0C48-427E-8895-337D5F592957@softarmor.com> <7C450C3A-33F9-450D-B424-4DCD86D5D99A@softarmor.com> From: "Sanjay Sinha (sanjsinh)" To: "Dean Willis" , "Christer Holmberg" X-OriginalArrivalTime: 30 Apr 2009 06:03:53.0241 (UTC) FILETIME=[706FB090:01C9C959] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=7178; t=1241071433; x=1241935433; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sanjsinh@cisco.com; z=From:=20=22Sanjay=20Sinha=20(sanjsinh)=22=20 |Subject:=20RE=3A=20[sipcore]=20Question=20on=20Require=20i n=20responses |Sender:=20 |To:=20=22Dean=20Willis=22=20,=0 A=20=20=20=20=20=20=20=20=22Christer=20Holmberg=22=20; bh=Pk125fzt2ygSywxv1p/1hbGMZn/ADyFgoz/sycUGFNQ=; b=iuP/arBHj3SVkJLi6p2JVnWORdGRo3Dn4J5jkcT9bynSm0gLCXZ2hi6v94 /XOU/4gedBPFeZgSJ+2u8pKStBWRaFPXdaQ/DbFU1IoleHmSKYBBEDPae7/s 1MkASZPwIC; Authentication-Results: rtp-dkim-1; header.From=sanjsinh@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Cc: SIPCORE Subject: Re: [sipcore] Question on Require in responses X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Apr 2009 06:02:32 -0000 =20 >-----Original Message----- >From: sipcore-bounces@ietf.org=20 >[mailto:sipcore-bounces@ietf.org] On Behalf Of Dean Willis >Sent: Thursday, April 30, 2009 1:28 AM >To: Christer Holmberg >Cc: SIPCORE >Subject: Re: [sipcore] Question on Require in responses > > >On Apr 29, 2009, at 3:02 AM, Christer Holmberg wrote: > >>> >> >> I was talking more about the meaning of Require in REQUESTs. > >OK. That definition is fairly clear in RFC 3261 20.32 > >"The Require header field contains a list of option tags,=20 >described in Section 19.2. Each option tag defines a SIP=20 >extension that MUST be understood to process the request.=20 >Frequently, this is used to indicate that a specific set of=20 >extension header fields need to be understood. A UAC compliant=20 >to this specification MUST only include option tags=20 >corresponding to standards-track RFCs" >Note that this does not say that the extension must be applied=20 >to the request, only that the UAC must understand the=20 >extension in order to be able to process the request. >> >> In my opinion, Require:100rel in the REQUEST means that the UAS not=20 >> only must support it, but that the UAS must only use it if sending=20 >> non-100 provisional responses. > >There's a semantic difference. The Require: 100rel in the=20 >request means that the UAS must understand 100rel in order to=20 >process the request, and that if it does not, then it must=20 >reject the request. > >RFC 3262 is badly worded, where it says in section 3, UAS behavior: > >"The UAS MUST send any non-100 provisional response reliably=20 >if the initial request contained a Require header field with=20 >the option tag 100rel." >This should key off the option-tag in the "Supported" header=20 >field, not the "Require", and be worded "The UAS SHOULD send=20 >any non-100 provisional response reliably if the initial=20 >request contained a Supported header field with the option tag 100rel." Yeah, and just to be clear I would also like to add that the "UAS supports option tag 100rel". If UAS does not support it, then it can ignore that extension. > >After all, what happens if the 180 is not sent reliably and=20 >doesn't contain an SDP? Does the protocol break? >Or do we just=20 >wait for the 200 (OK) to complete offer/answer? No that does not break protocol and sdp in 200 OK completes offer-answer exchange. But if 180 is sent reliably and does not contain sdp, that breaks the protocol. Not exactly sure why this limitation has been there. But in some cases, UAS does not have sdp to send in reliable non-100 response and then it uses other ways to get around that rule, like sending sdp with inactive attributes, dummy port numbers etc. > >> >> The same thing goes for preconditions. If the UAC in the REQUEST=20 >> require preconditions, it does not only mean that UAS must=20 >support it,=20 >> but that the UAS must also use it. > >Again, what does it break if the UAS understands=20 >preconditions, but doesn't actually need to exercise them on=20 >its end of the circuit? > >RFC 3312 is kind of mixed up in its use of Require and=20 >Supported, and in fact contradicts RFC 3261 by conflating the=20 >two (#261 says you =20 >would always put the option tag in Supported and might also=20 >put in in =20 >Require.). 3312 says: >"We define the option tag "precondition" for use in the=20 >Require and Supported header fields. An offerer MUST include=20 >this tag in the Require header field if the offer contains one=20 >or more "mandatory" =20 >strength-tags. If all the strength-tags in the description are=20 >"optional" or "none", the offerer MUST include this tag in=20 >either a Supported header field or in a Require header field.=20 >It is, however, RECOMMENDED that the Supported header field be=20 >used in this case. The lack of preconditions in the answer=20 >would indicate that the answerer did not support this extension." >But even here, it's not the presence of the option tag in a=20 >Require that drives the UAS to use preconditions, it's the=20 >strength-tags in the precondition description. The use in the=20 >Require field is only to cause the transaction to fail if the=20 >UAS does not support preconditions, and the recommendation is=20 >to force this failure only if the preconditions are mandatory,=20 >and it encourages call-completion for a non-3312 UAS if the=20 >preconditions are optional. > >> In fact, I think the same thing also goes for timer.=20 >Require:timer in=20 >> the REQUEST means that the UAS must not only support session-timer,=20 >> but that the UAS must start the session timer negotiation. > >RFC 4028 specifically says: > >"The UAC MAY include a Require header field in the request=20 >with the value 'timer' to indicate that the UAS must support=20 >the session timer to participate in the session. This does not=20 >mean that the UAC is requiring the UAS to perform the=20 >refreshes, only that it is requiring the UAS to support the extension." >So I think you're wrong on that one. > > >> What is the use in requireing the UAS to support foo, if you don't=20 >> also require it to use foo (if applicable)? > > >Because "wanting it to use foo" and "knowing that it is=20 >capable of using foo" are two different things, and the=20 >difference is frequently dependent on the specfic foo in question. > >For example, in AnswerMode, we might require that the far end=20 >support AutoAnswer, which (even though it supports it), it=20 >might not choose to do due to policy. And we clearly say that=20 >it's the presence of the Answer-Mode header field that=20 >triggers the automatic answering behavior, not the "Require".=20 >Otherwise we wouldn't need header fields, we'd just need=20 >option tags for all SIP extensions. > >Let's hammer on that point: > >The option tag is a means of 1) discovering whether or not the=20 >far-end supports a specific extension and of 2) declaring the=20 >criticality of understanding that extension relative to=20 >satisfying a request and 3) informing the UAC of what=20 >extensions were applied to the request in order to generate=20 >the response. This is purely a function of capability=20 >negotiation, not one of invocation. > >The extension itself (typically, an extension header field,=20 >although there are other types of extensions) is what causes=20 >the extension to be invoked. > >If we did it your way, then we wouldn't need SIP extension=20 >header fields. We'd just use option-tags, and extend them with=20 >parameters. > >For example, instead of Referred-By as its own header field,=20 >we'd just say "Require: referred-by=3Dbozo@example.com" Yeah in some cases, the tag in Require/Supported header, just reinforces behavior of some extension without having anything to do with actual usage. Actual value that the UA has to use is in some other header, parameter etc. Sanjay > >-- >Dean > > > > > > >_______________________________________________ >sipcore mailing list >sipcore@ietf.org >https://www.ietf.org/mailman/listinfo/sipcore > From christer.holmberg@ericsson.com Wed Apr 29 23:22:11 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 90AC63A6A41 for ; Wed, 29 Apr 2009 23:22:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.524 X-Spam-Level: X-Spam-Status: No, score=-5.524 tagged_above=-999 required=5 tests=[AWL=0.125, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_75=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HSvDxgHelpXF for ; Wed, 29 Apr 2009 23:22:10 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id CA5213A696B for ; Wed, 29 Apr 2009 23:22:09 -0700 (PDT) X-AuditID: c1b4fb3e-b7bb8ae000006a07-31-49f943e2cd8c Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw4.ericsson.se (Symantec Mail Security) with SMTP id 00.6C.27143.2E349F94; Thu, 30 Apr 2009 08:23:31 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 30 Apr 2009 08:23:30 +0200 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, 30 Apr 2009 08:23:36 +0200 Message-ID: In-Reply-To: <7C450C3A-33F9-450D-B424-4DCD86D5D99A@softarmor.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Question on Require in requests (was: RE: [sipcore] Question on Require in responses) Thread-Index: AcnJBM7H/2NCLA0KQyKEWwKbSgEiDAATOEow References: <0D5F89FAC29E2C41B98A6A762007F5D001D4A39A@GBNTHT12009MSX.gb002.siemens.net><49F5B3FE.8030104@cisco.com><28B7C3AA2A7ABA4A841F11217ABE78D67590BF97@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <49F5C2C4.70501@cisco.com> <49F71501.2020300@cisco.com> <49F742EE.30504@softarmor.com> <49F75022.4010905@cisco.com> <6B78E793-0C48-427E-8895-337D5F592957@softarmor.com> <7C450C3A-33F9-450D-B424-4DCD86D5D99A@softarmor.com> From: "Christer Holmberg" To: "Dean Willis" X-OriginalArrivalTime: 30 Apr 2009 06:23:30.0752 (UTC) FILETIME=[2E499C00:01C9C95C] X-Brightmail-Tracker: AAAAAA== Cc: SIPCORE Subject: [sipcore] Question on Require in requests (was: RE: Question on Require in responses) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Apr 2009 06:22:11 -0000 Hi,=20 Changed the subject, so we can keep the request- and response issues separate. >>I was talking more about the meaning of Require in REQUESTs. >=20 >OK. That definition is fairly clear in RFC 3261 20.32 >=20 >"The Require header field contains a list of option tags,=20 >described in Section 19.2. Each option tag defines a SIP=20 >extension that MUST be understood to process the request.=20 >Frequently, this is used to indicate that a specific set of=20 >extension header fields need to be understood. A UAC=20 >compliant to this specification MUST only include option tags=20 >corresponding to standards-track RFCs" >Note that this does not say that the extension must be=20 >applied to the request, only that the UAC must understand the=20 >extension in order to be able to process the request. > >>In my opinion, Require:100rel in the REQUEST means that the UAS not=20 >>only must support it, but that the UAS must only use it if sending=20 >>non-100 provisional responses. >=20 >There's a semantic difference. The Require: 100rel in the=20 >request means that the UAS must understand 100rel in order to=20 >process the request, and that if it does not, then it must=20 >reject the request. Well, if the UAS doesn't understand 100rel it can't send reliable responses, which means it can't process the request correctly. The meaning of "must be able to process the request" is kinda difuse, and I think the meaning is different depending on which option-tag/extension we're talking about... >RFC 3262 is badly worded, where it says in section 3, UAS behavior: >=20 >"The UAS MUST send any non-100 provisional response reliably=20 >if the initial request contained a Require header field with=20 >the option tag 100rel." >This should key off the option-tag in the "Supported" header=20 >field, not the "Require", and be worded "The UAS SHOULD send=20 >any non-100 provisional response reliably if the initial=20 >request contained a Supported header field with the option=20 >tag 100rel." >=20 >After all, what happens if the 180 is not sent reliably and=20 >doesn't contain an SDP? Does the protocol break? Or do we=20 >just wait for the 200 (OK) to complete offer/answer? In my understanding it is an error if the 180 is not sent reliably (it doesn't always need to contain SDP, though). Am I the only one who has that understanding? >>The same thing goes for preconditions. If the UAC in the REQUEST require preconditions, it does not only mean that UAS must support it,=20 >>but that the UAS must also use it. >=20 >Again, what does it break if the UAS understands preconditions, but doesn't actually need to exercise them on its end of the circuit? Well, for one thing the UAS may not send an SDP answer before 200 OK, which means that the UAC is not able to update its precondition status before 200 OK. That maybe doesn't break the protocol, but it may have impact on early media, may cause clipping when the call has been answered etc. And, as for 100rel, I think that many UACs would see it as an error if preconditions aren't used. But, again, I'd be happy to hear that I am the only one who thinks so :) >RFC 3312 is kind of mixed up in its use of Require and=20 >Supported, and in fact contradicts RFC 3261 by conflating the=20 >two (#261 says you would always put the option tag in Supported and might also=20 >put in in Require.). 3312 says: >"We define the option tag "precondition" for use in the=20 >Require and Supported header fields. An offerer MUST include=20 >this tag in the Require header field if the offer contains=20 >one or more "mandatory" strength-tags. If all the strength-tags in the description=20 >are "optional" or "none", the offerer MUST include this tag=20 >in either a Supported header field or in a Require header=20 >field. It is, however, RECOMMENDED that the Supported header=20 >field be used in this case. The lack of preconditions in the=20 >answer would indicate that the answerer did not support this=20 >extension." >But even here, it's not the presence of the option tag in a=20 >Require that drives the UAS to use preconditions, it's the=20 >strength-tags in the precondition description. The use in the=20 >Require field is only to cause the transaction to fail if the=20 >UAS does not support preconditions, and the recommendation is=20 >to force this failure only if the preconditions are=20 >mandatory, and it encourages call-completion for a non-3312=20 >UAS if the preconditions are optional. > >>In fact, I think the same thing also goes for timer. Require:timer in=20 >>the REQUEST means that the UAS must not only support session-timer,=20 >>but that the UAS must start the session timer negotiation. >=20 >RFC 4028 specifically says: >=20 >"The UAC MAY include a Require header field in the request=20 >with the value 'timer' to indicate that the UAS must support=20 >the session timer to participate in the session. This does=20 >not mean that the UAC is requiring the UAS to perform the=20 >refreshes, only that it is requiring the UAS to support the=20 >extension." >So I think you're wrong on that one. I didn't say that the UAS was required to actually perform the refreshes. But, I assume that "must support the extension" in this case means that the UAS must participate in the negotiation on who is going to do the refreshes etc. Otherwise, if nothing is really required by the UAS, why does it matter whether it supports the extension or not? >>What is the use in requireing the UAS to support foo, if you don't also require it to use foo (if applicable)? >=20 >=20 >Because "wanting it to use foo" and "knowing that it is=20 >capable of using foo" are two different things, and the=20 >difference is frequently dependent on the specfic foo in question. >=20 >For example, in AnswerMode, we might require that the far end=20 >support AutoAnswer, which (even though it supports it), it=20 >might not choose to do due to policy. And we clearly say that=20 >it's the presence of the Answer-Mode header field that=20 >triggers the automatic answering behavior, not the "Require".=20 >Otherwise we wouldn't need header fields, we'd just need=20 >option tags for all SIP extensions. So, then I think that Require has different meanings depending on the extension. Because, my understanding is still that e.g. Require:100rel actually sends prov resps reliably. Of course, the UAS can choose whether it's going to send prov resps in the first place, but if it does so it is required to use the extension. Another example: RFC 3329 requires servers which receive Require/Proxy-Require:sec-agree to actually perform some actions. >Let's hammer on that point: >=20 >The option tag is a means of 1) discovering whether or not=20 >the far-end supports a specific extension and of 2) declaring=20 >the criticality of understanding that extension relative to=20 >satisfying a request and 3) informing the UAC of what=20 >extensions were applied to the request in order to generate=20 >the response. This is purely a function of capability=20 >negotiation, not one of invocation. >=20 >The extension itself (typically, an extension header field,=20 >although there are other types of extensions) is what causes=20 >the extension to be invoked. > >If we did it your way, then we wouldn't need SIP extension=20 >header fields. We'd just use option-tags, and extend them=20 >with parameters. >=20 >For example, instead of Referred-By as its own header field,=20 >we'd just say "Require: referred-by=3Dbozo@example.com" Sure, but that's just an encoding issue. However, it's not about "my way" versus some other way. I just want everyone to have a common understanding. Regards, Christer From attila.sipos@vegastream.com Wed Apr 29 23:29:18 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 85E933A6E0B for ; Wed, 29 Apr 2009 23:29:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UwiNKR1VT9ww for ; Wed, 29 Apr 2009 23:29:17 -0700 (PDT) Received: from cluster-f.mailcontrol.com (cluster-f.mailcontrol.com [85.115.62.190]) by core3.amsl.com (Postfix) with ESMTP id 60EAB3A69D3 for ; Wed, 29 Apr 2009 23:29:17 -0700 (PDT) Received: from exsmtp02.nasstar-t1.net (exsmtp02.nasstar-t1.net [89.28.233.152]) by rly27f.srv.mailcontrol.com (MailControl) with ESMTP id n3U6UckF012378 for ; Thu, 30 Apr 2009 07:30:38 +0100 Received: from EXVS02.nasstar-t1.net ([10.2.10.106]) by exsmtp02.nasstar-t1.net with Microsoft SMTPSVC(6.0.3790.1830); Thu, 30 Apr 2009 07:31:16 +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, 30 Apr 2009 07:30:37 +0100 Message-ID: <680808427CF931459462C3D78CB5EC6005739F71@EXVS02.nasstar-t1.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] info-03 draft and "session negotiation exchange" Thread-Index: AcnJXSzeDvYn/MQwTMayNh/Q4WEhqw== From: "Attila Sipos" To: X-OriginalArrivalTime: 30 Apr 2009 06:31:16.0722 (UTC) FILETIME=[4406FD20:01C9C95D] X-Scanned-By: MailControl A_08_51_00 (www.mailcontrol.com) on 10.70.0.137 Subject: [sipcore] info-03 draft and "session negotiation exchange" X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Apr 2009 06:29:18 -0000 Hi,=20 Sorry for questions late in the day but I'm not clear on the negotiation methods of the info package draft. The draft mentions "session negotiation exchange" several times. Can someone tell me where this is defined? Section 3.1 (UA Behavior) shows INVITE/OK/ACK as an exchange. I see from section "5.2. INFO Headers" of the "INFO tables" e-mail that PRACK and UPDATE are allowed to carry the Recv-Info header. So what is the "exchange" if say, INVITE and PRACK are involved? >From section 3.1, it seems that the initial "offer" is in the INVITE and then "confirmed" in the ACK. So if PRACK is received, can one "confirm" in a PRACK? Also, if Recv-Info is allowed in UPDATE, how does that get "confirmed"? Or is it that UPDATE just lists the packages already negotiated? Or is it that package renegotiation is only ever done in INVITE/re-INVITE? If so, I would like to see some text explicitly stating this. If not, what renegotiation combinations are there? =20 Then there is this... The limitation on requiring the negotiation to occur within the context of a session negotiation exchange means that if the initiating UA issues a re-INVITE (after the above ACK) with the following. INVITE ... ... Recv-Info: P, R, T ... The target UA MUST NOT send any package P INFO methods until the target UA sees P in the final ACK from the initiating UA. So, let's say P was being sent by the target. Then when the re-INVITE arrives, P has to be stopped (or queued), until P is seen again in the ACK. So what happens if there is a re-INVITE/INFO(package P) crossover? I think we need to say that if the initiating UA receives the INFO for package P, it should either: 1. still process it as normal or 2. issue a 4xx response (something like 491 Request Pending) so that the package P event can be re-attempted once the ACK has been received. Regards, Attila From christer.holmberg@ericsson.com Wed Apr 29 23:29:37 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8DDFA3A6F10 for ; Wed, 29 Apr 2009 23:29:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.824 X-Spam-Level: X-Spam-Status: No, score=-5.824 tagged_above=-999 required=5 tests=[AWL=0.425, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IHCfjTPrRLY7 for ; Wed, 29 Apr 2009 23:29:36 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id A4A363A6EC2 for ; Wed, 29 Apr 2009 23:29:35 -0700 (PDT) X-AuditID: c1b4fb3c-b7b4bae000001105-a6-49f9459e2905 Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw3.ericsson.se (Symantec Mail Security) with SMTP id 29.D4.04357.E9549F94; Thu, 30 Apr 2009 08:30:54 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 30 Apr 2009 08:30:51 +0200 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, 30 Apr 2009 08:30:57 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] Question on Require in responses Thread-Index: AcnJBNOCwBNFTAdEQGm8w4nI7RXgxQAUpRGgAAFWCJA= References: <0D5F89FAC29E2C41B98A6A762007F5D001D4A39A@GBNTHT12009MSX.gb002.siemens.net><49F5B3FE.8030104@cisco.com><28B7C3AA2A7ABA4A841F11217ABE78D67590BF97@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <49F5C2C4.70501@cisco.com> <49F71501.2020300@cisco.com> <49F742EE.30504@softarmor.com><49F75022.4010905@cisco.com><6B78E793-0C48-427E-8895-337D5F592957@softarmor.com> <7C450C3A-33F9-450D-B424-4DCD86D5D99A@softarmor.com> From: "Christer Holmberg" To: "Sanjay Sinha (sanjsinh)" , "Dean Willis" X-OriginalArrivalTime: 30 Apr 2009 06:30:51.0286 (UTC) FILETIME=[34DDC360:01C9C95D] X-Brightmail-Tracker: AAAAAA== Cc: SIPCORE Subject: Re: [sipcore] Question on Require in responses X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Apr 2009 06:29:37 -0000 Hi,=20 >>After all, what happens if the 180 is not sent reliably and doesn't=20 >>contain an SDP? Does the protocol break? >>Or do we just >>wait for the 200 (OK) to complete offer/answer? >=20 >No that does not break protocol and sdp in 200 OK completes=20 >offer-answer exchange. But if 180 is sent reliably and does=20 >not contain sdp, that breaks the protocol. Only if the INVITE didn't contain SDP :) Regards, Christer From sanjsinh@cisco.com Wed Apr 29 23:37:58 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 62E5A3A696B for ; Wed, 29 Apr 2009 23:37:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.587 X-Spam-Level: X-Spam-Status: No, score=-6.587 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nK+ZzTtFit5d for ; Wed, 29 Apr 2009 23:37:57 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 7F02F3A6D60 for ; Wed, 29 Apr 2009 23:37:57 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,270,1238976000"; d="scan'208";a="157876435" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by sj-iport-3.cisco.com with ESMTP; 30 Apr 2009 06:39:20 +0000 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n3U6dJqX012085; Thu, 30 Apr 2009 02:39:19 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id n3U6dJp9023975; Thu, 30 Apr 2009 06:39:19 GMT Received: from xmb-rtp-201.amer.cisco.com ([64.102.31.13]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 30 Apr 2009 02:39:19 -0400 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, 30 Apr 2009 02:39:17 -0400 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] Question on Require in responses Thread-Index: AcnJBNOCwBNFTAdEQGm8w4nI7RXgxQAUpRGgAAFWCJAAAGNykA== References: <0D5F89FAC29E2C41B98A6A762007F5D001D4A39A@GBNTHT12009MSX.gb002.siemens.net><49F5B3FE.8030104@cisco.com><28B7C3AA2A7ABA4A841F11217ABE78D67590BF97@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <49F5C2C4.70501@cisco.com> <49F71501.2020300@cisco.com> <49F742EE.30504@softarmor.com><49F75022.4010905@cisco.com><6B78E793-0C48-427E-8895-337D5F592957@softarmor.com> <7C450C3A-33F9-450D-B424-4DCD86D5D99A@softarmor.com> From: "Sanjay Sinha (sanjsinh)" To: "Christer Holmberg" , "Dean Willis" X-OriginalArrivalTime: 30 Apr 2009 06:39:19.0505 (UTC) FILETIME=[63C9D410:01C9C95E] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=817; t=1241073559; x=1241937559; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sanjsinh@cisco.com; z=From:=20=22Sanjay=20Sinha=20(sanjsinh)=22=20 |Subject:=20RE=3A=20[sipcore]=20Question=20on=20Require=20i n=20responses |Sender:=20 |To:=20=22Christer=20Holmberg=22=20,=0A=20=20=20=20=20=20=20=20=22Dean=20Willis=22=20; bh=/ALZJVmiEMxwi7m6LVANp4hZdvBAf3sHoYfowq+stuk=; b=kQx7O+k4ZJVarkxoqPlkV2qhMXqHa8i+LcBsIFN3HI4CXJ/L8GzIgpKpLa bWDqEdj1GQOPnL8s0RrfG8n+aXLJhGjSJUMy2xNcn9xy4KynZjJo9963sX8h PoOLMBbS7O; Authentication-Results: rtp-dkim-2; header.From=sanjsinh@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Cc: SIPCORE Subject: Re: [sipcore] Question on Require in responses X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Apr 2009 06:37:58 -0000 =20 >-----Original Message----- >From: Christer Holmberg [mailto:christer.holmberg@ericsson.com]=20 >Sent: Thursday, April 30, 2009 12:01 PM >To: Sanjay Sinha (sanjsinh); Dean Willis >Cc: SIPCORE >Subject: RE: [sipcore] Question on Require in responses > > >Hi,=20 > >>>After all, what happens if the 180 is not sent reliably and doesn't=20 >>>contain an SDP? Does the protocol break? >>>Or do we just >>>wait for the 200 (OK) to complete offer/answer? >>=20 >>No that does not break protocol and sdp in 200 OK completes=20 >>offer-answer exchange. But if 180 is sent reliably and does=20 >not contain=20 >>sdp, that breaks the protocol. > >Only if the INVITE didn't contain SDP :) Yeah that's correct, my statement should be qualified with that. Thanks > >Regards, > >Christer > From ietf.hanserik@gmail.com Thu Apr 30 02:37:04 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 34C993A69B7 for ; Thu, 30 Apr 2009 02:37:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.517 X-Spam-Level: X-Spam-Status: No, score=-2.517 tagged_above=-999 required=5 tests=[AWL=0.082, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MKr6nvVWD+zA for ; Thu, 30 Apr 2009 02:37:03 -0700 (PDT) Received: from mail-ew0-f176.google.com (mail-ew0-f176.google.com [209.85.219.176]) by core3.amsl.com (Postfix) with ESMTP id D3EDD3A68C3 for ; Thu, 30 Apr 2009 02:37:02 -0700 (PDT) Received: by ewy24 with SMTP id 24so1776059ewy.37 for ; Thu, 30 Apr 2009 02:38:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=MLNKqyEFQ2OI0o/WpDBc7K0OpIGkAsB9h7AeOQ2d8VM=; b=XBop2kq3JhW4JuAR4aLlhZ3Df2QbJQ7/p4uhLiziuzecGqI3EF/w4JFX+gK6Pp3Hk8 tV7RL3sSfL3B+vcbOMQQ9ISqq1VNrG1BItsbwp39gfu7uzXXaSL/kP45d/zqDR2QL/2W yW8Tr9JnUqCOIc4L5GBMGIr1xSx7fSfzL2qa8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=s6kst8mhpYHkBx1dk0S8J8CMX5ZDElb4BQW8raM3IfdR6X9nb5oYMeuKuST9z5llnH uKVr5k7U4rg/o1MespbPzDhnfVhGapESU4QnfecmM/MnBNfH5OA9h/9V+RyyImaGhusZ lt1oOxvTYS6Q0sY96HjzaTMp+T/fJTkcZ+0sg= Received: by 10.216.54.83 with SMTP id h61mr392781wec.69.1241084304691; Thu, 30 Apr 2009 02:38:24 -0700 (PDT) Received: from ?192.168.1.5? (212-182-129-30.ip.telfort.nl [212.182.129.30]) by mx.google.com with ESMTPS id 7sm1163612eyg.17.2009.04.30.02.38.23 (version=SSLv3 cipher=RC4-MD5); Thu, 30 Apr 2009 02:38:24 -0700 (PDT) Message-ID: <49F9718E.4070707@gmail.com> Date: Thu, 30 Apr 2009 11:38:22 +0200 From: Hans Erik van Elburg User-Agent: Thunderbird 2.0.0.21 (X11/20090409) MIME-Version: 1.0 To: Dean Willis References: <49F178CE.8000809@ericsson.com> <0ECC036E-2B21-49D5-AC42-1FEC8EC447BE@softarmor.com> <49F5D64B.20008@nostrum.com> <193E3797-2C8D-44EB-A869-DDDE39B303D9@nostrum.com> <06F3B3D8-BEA3-4B5A-990D-B9E8DCAB1FF1@softarmor.com> In-Reply-To: <06F3B3D8-BEA3-4B5A-990D-B9E8DCAB1FF1@softarmor.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: SIPCORE Subject: Re: [sipcore] Long reply to: Target URI and History Info bis X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Apr 2009 09:37:04 -0000 Overloading in general is not a good design strategy, why do you think that trying to mold everything (diversion/history info) into Request URI is a good idea?? The problem here is that this information has nothing to do with application invocation, but tells something about how the signalling reached the callee (target). And this information is only relevant to the callee if that decides that it is. /Hans Erik Dean Willis wrote: > > On Apr 29, 2009, at 4:50 PM, Ben Campbell wrote: > >> >> On Apr 27, 2009, at 2:44 PM, Dean Willis wrote: >> >>> >>> On Apr 27, 2009, at 10:59 AM, Adam Roach wrote: >>>> >>>> So, for the other half of this puzzle, we need to make sure that >>>> the parameters you're talking about can be expressed as part of a >>>> SIP URI, so that they can be communicated to the UAC in the first >>>> place. >>>> >>> >>> Ah, but they can. It's not any harder than doing it with HTTP. We >>> just don't use it much since it doesn't work well due to >>> contact-routing. >>> >> >> Assuming you mean to say that, if we choose to send application >> parameters in some non URI mechanism (e.g. new headers, bodies, etc), >> we can still encode that in URIs, in the same way you can encode any >> arbitrary SIP bits into a URI? >> >> If so, that is true--but it makes for an insanely complicated URI, >> and I wouldn't bet on any given UA handling it correctly. > > No, not what I was saying. I was saying that we know how to encode > arbitrary things in the request URI (without encoding them as embedded > headers in the request URI) , which makes me sure that what Adam > called "the parameters you're talking about" can be expressed as part > of a SIP URI. If we can express the parameters in any way, then we > can express them as parts of SIP Request-URI , since Request-URI is > linguistically complete and has a well-defined grammar for encoding > things. > > I believe what Adam was worrying about was the specification of those > things which I wish to encode as parameters; that is, that they be > specified as parameters and not as body parts, header fields, or > something else. We in fact have an IANA registry for just exactly this > task. > > Let's cast this back in the light of my 11+ year-old fight with the > Diversion header -- I thought it should have been encoded in the > Request-URI, not encoded in a transport-layer header field. Making it > a header field conflated the application with the transport. We should > not have needed to extend SIP as a transport protocol and modify the > core SIP ABNF just to handle this new application. I feel this way > about a LOT of the functionality we've grafted onto SIP through the > years, or are still talking about grafting on. The "service > identifier" is one example that comes to mind. > > -- > Dean > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From ietf.hanserik@gmail.com Thu Apr 30 08:05:38 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 197623A6ADB for ; Thu, 30 Apr 2009 08:05:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.522 X-Spam-Level: X-Spam-Status: No, score=-2.522 tagged_above=-999 required=5 tests=[AWL=0.077, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XpTQiZevLikJ for ; Thu, 30 Apr 2009 08:05:37 -0700 (PDT) Received: from mail-ew0-f176.google.com (mail-ew0-f176.google.com [209.85.219.176]) by core3.amsl.com (Postfix) with ESMTP id 056E43A6834 for ; Thu, 30 Apr 2009 08:05:36 -0700 (PDT) Received: by ewy24 with SMTP id 24so1957459ewy.37 for ; Thu, 30 Apr 2009 08:06:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=J2MaA9HFFkPzmr/4Ymz1H/nIJZ9oN6aNmRV3D9SGbO0=; b=S/OQHyrzJ4t4dms1twA5Yj9YtfANvPSPAcifyswsGCrj/Zkr2M2Iy+CdBfhtPPtVFh m+r4LD7Anku03cTnPGbE5+YW7k5KBcy0U+RSQv6u8fEVI5Vtz6RRSvPV/QSmLkuDmxZy //sVHCBG5G3p+YaoBWoAmU5KznkmYyFTPTQ2I= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=hc1cscZOBvKesJibEJR8/QLbBW2TGaROD5nodpcOE8FYof6AvhC45kVhalKbvmZUXh OjleZiuSbk/d49EwFZGfXY1aiQgTDw/pbVW2Nfpnzw06h8n2ft2DgHNgIGGOuooWUgCH VUqbgjbNbcIbOCXhOO/dRK7mmcM3pnbGOtrEE= Received: by 10.216.23.72 with SMTP id u50mr521251weu.178.1241104019275; Thu, 30 Apr 2009 08:06:59 -0700 (PDT) Received: from ?192.168.1.5? (212-182-129-30.ip.telfort.nl [212.182.129.30]) by mx.google.com with ESMTPS id 7sm4079485eyg.47.2009.04.30.08.06.58 (version=SSLv3 cipher=RC4-MD5); Thu, 30 Apr 2009 08:06:58 -0700 (PDT) Message-ID: <49F9BE92.1050601@gmail.com> Date: Thu, 30 Apr 2009 17:06:58 +0200 From: Hans Erik van Elburg User-Agent: Thunderbird 2.0.0.21 (X11/20090409) MIME-Version: 1.0 To: Dean Willis References: <0D5F89FAC29E2C41B98A6A762007F5D001D4A39A@GBNTHT12009MSX.gb002.siemens.net><49F5B3FE.8030104@cisco.com><28B7C3AA2A7ABA4A841F11217ABE78D67590BF97@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <49F5C2C4.70501@cisco.com> <49F71501.2020300@cisco.com> <49F742EE.30504@softarmor.com> <49F75022.4010905@cisco.com> <6B78E793-0C48-427E-8895-337D5F592957@softarmor.com> <7C450C3A-33F9-450D-B424-4DCD86D5D99A@softarmor.com> In-Reply-To: <7C450C3A-33F9-450D-B424-4DCD86D5D99A@softarmor.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: SIPCORE Subject: Re: [sipcore] Question on Require in responses X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Apr 2009 15:05:38 -0000 Dean Willis wrote: > The option tag is a means of 1) discovering whether or not the far-end > supports a specific extension and of 2) declaring the criticality of > understanding that extension relative to satisfying a request and 3) > informing the UAC of what extensions were applied to the request in > order to generate the response. This is purely a function of > capability negotiation, not one of invocation. > > The extension itself (typically, an extension header field, although > there are other types of extensions) is what causes the extension to > be invoked. Depends a bit how you define extension, but I would argue that if I require an extension to be supported on a transaction/dialog by the UAS and the UAS accepts the request that this means that for this call the UAS behaves as it should according to the extensions specification. Saying that an extensions invokes itself is meaningless to me. A UAS may choose to only invoke the extension behaviour if it finds that the extension is required. That comes close to saying that the require:extension invokes the behaviour in the UAS, but it is not at all the same. /Hans Erik From ietf.hanserik@gmail.com Thu Apr 30 08:17:11 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 61B013A67D4 for ; Thu, 30 Apr 2009 08:17:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.527 X-Spam-Level: X-Spam-Status: No, score=-2.527 tagged_above=-999 required=5 tests=[AWL=0.072, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 47N9SqCOWjnr for ; Thu, 30 Apr 2009 08:17:10 -0700 (PDT) Received: from mail-ew0-f176.google.com (mail-ew0-f176.google.com [209.85.219.176]) by core3.amsl.com (Postfix) with ESMTP id 521463A6971 for ; Thu, 30 Apr 2009 08:17:10 -0700 (PDT) Received: by ewy24 with SMTP id 24so1967666ewy.37 for ; Thu, 30 Apr 2009 08:18:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=1RAeSiKjLWCDDjuSgopBWUS+pEm1sGlKoPinSN1b56k=; b=hFQFDtTHz1mTacnrj3JAgsJsatGezogj9nT45UJu1y/59cl1rJpoCUXzXV6vtbl1lD t/7LwykKITzhJEofMY15dgfaISgNnojGbHJJZsmKLf+A3U7MdPWwt/tJd6qRLI1oz40a 7ErB37PbryjZ2hwvagAav96EwN5Bhu2j6inAc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=hvZ4omcNNN9yUUgRvMMMESEKhM2Y3PA8ux8vtADzBff0lh/qRxDiwoSSBFzDPS1pmN PtO3MVesx9l5ftwhQ9l30ekpbD29XbL9HBOYQOH4nutAz0tAR/+6de70qo+Zq/wuQ4ko pYJA4ZrRc7gQ2hpWbAE5ds9gMXlcyj7ilyJSA= Received: by 10.210.82.13 with SMTP id f13mr7889679ebb.48.1241104712684; Thu, 30 Apr 2009 08:18:32 -0700 (PDT) Received: from ?192.168.1.5? (212-182-129-30.ip.telfort.nl [212.182.129.30]) by mx.google.com with ESMTPS id 7sm1745659eyg.17.2009.04.30.08.18.31 (version=SSLv3 cipher=RC4-MD5); Thu, 30 Apr 2009 08:18:32 -0700 (PDT) Message-ID: <49F9C147.1020100@gmail.com> Date: Thu, 30 Apr 2009 17:18:31 +0200 From: Hans Erik van Elburg User-Agent: Thunderbird 2.0.0.21 (X11/20090409) MIME-Version: 1.0 To: Christer Holmberg References: <0D5F89FAC29E2C41B98A6A762007F5D001D4A39A@GBNTHT12009MSX.gb002.siemens.net><49F5B3FE.8030104@cisco.com><28B7C3AA2A7ABA4A841F11217ABE78D67590BF97@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <49F5C2C4.70501@cisco.com> <49F71501.2020300@cisco.com> <49F742EE.30504@softarmor.com> <49F75022.4010905@cisco.com> <6B78E793-0C48-427E-8895-337D5F592957@softarmor.com> <7C450C3A-33F9-450D-B424-4DCD86D5D99A@softarmor.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: SIPCORE Subject: Re: [sipcore] Question on Require in requests X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Apr 2009 15:17:11 -0000 Christer Holmberg wrote: > > So, then I think that Require has different meanings depending on the > extension. > The Require does not have different meanings, the extensions are different. Different extensions expose different behaviour. > Because, my understanding is still that e.g. Require:100rel actually > sends prov resps reliably. Require: 100rel does not send responses ;-) > Another example: RFC 3329 requires servers which receive > Require/Proxy-Require:sec-agree to actually perform some actions. > > This is because the assumption is that when the extension is supported that it will also be active. From mary.barnes@nortel.com Thu Apr 30 09:17:52 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id ACDC53A68AF for ; Thu, 30 Apr 2009 09:17:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.477 X-Spam-Level: X-Spam-Status: No, score=-6.477 tagged_above=-999 required=5 tests=[AWL=0.122, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C2pKuQlF3wv5 for ; Thu, 30 Apr 2009 09:17:51 -0700 (PDT) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id 837563A67F7 for ; Thu, 30 Apr 2009 09:17:51 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id n3UGIJQ13188; Thu, 30 Apr 2009 16:18:20 GMT 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, 30 Apr 2009 11:21:55 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF1DBE56C1@zrc2hxm0.corp.nortel.com> In-Reply-To: <874544.99408.qm@web65605.mail.ac4.yahoo.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] Target URI and History Info bis Thread-Index: AcnINeOydImGrHrHSe2tPos5cdCgcgBd13mQ References: <874544.99408.qm@web65605.mail.ac4.yahoo.com> From: "Mary Barnes" To: , Subject: Re: [sipcore] Target URI and History Info bis X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Apr 2009 16:17:52 -0000 Hi Sumit, In general, we do not include ISUP I/W flows in standards track SIP protocol documents. There are a few cases where that has been done in Informational documents in the past, but my understanding was that the decision was made quite some time ago that the I/W is more appropriately defined by other SDOs. There is nothing normative from a SIP protocol perspective for the History-Info header in terms of what the index should be when interworking with ISUP (or any other PSTN protocol) - other than it is recommended to start at "1". Also, note it is an index in the History-Info header and not a count - you can derive the count by looking at the tree produced by the indices in the History-Info header. This is discussed in the draft-mohali-draft-mohali-diversion-history-info-02, which is a more appropriate document (or a similar document produced by another SDO) for describing this interworking.=20 Yes, you are absolutely correct that there will be a loss of information when you interwork SIP->ISUP. That is something identified in the thread with regards to the draft-mohali-draft-mohali-diversion-history-info-02: http://www.ietf.org/mail-archive/web/bliss/current/msg00923.html Regards, Mary.=20 -----Original Message----- From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behalf Of Sumit Garg Sent: Tuesday, April 28, 2009 2:17 PM To: sipcore@ietf.org Subject: [sipcore] Target URI and History Info bis It would be nice if the examples section included PSTN interworking too.. My problem: ISUP to SIP: Incoming redirection count is say 3. A redirection occurs... The new count should be? 3.1 OR 4 OR 1.1.1.1 Also, we may not have enough information to create the complete hierarchy of History-Info headers... Similarly, how to interpret the data in SIP to ISUP scenarios? Lack of this clarity in interworking is one reason why Diversion is in use even after all these years... -Sumit -----Original Message----- From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behalf Of Mary Barnes Sent: Friday, April 24, 2009 4:55 PM To: Hans Erik van Elburg; Gonzalo Camarillo Cc: SIPCORE Subject: Re: [sipcore] Target URI and History Info bis Just to re-iterate once more, 4244bis already contains a superset of the normative text for History-Info header from the current target-uri document. Francois has proposed a fairly straightforward path for 4244bis that should allow us to avoid any of the hurdles and open ended debates as to History-Info issues - the known issues are quite straight-forward to solve and the issues at hand really are providing a solution for target-uri. The idea that the target-uri document would progress much quicker than 4244bis is a red herring - in particular based on my comments that you need more changes to 4244 to support target-uri than just the new tags.=20 Mary.=20 Forever, Sumit "The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man." -- George Bernard Shaw =20 _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore From mdolly@att.com Thu Apr 30 09:30:26 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0BC5728C137 for ; Thu, 30 Apr 2009 09:30:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.583 X-Spam-Level: X-Spam-Status: No, score=-106.583 tagged_above=-999 required=5 tests=[AWL=0.016, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9qsdEpac3tK9 for ; Thu, 30 Apr 2009 09:30:24 -0700 (PDT) Received: from mail120.messagelabs.com (mail120.messagelabs.com [216.82.250.83]) by core3.amsl.com (Postfix) with ESMTP id B391E3A6D4E for ; Thu, 30 Apr 2009 09:30:24 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: mdolly@att.com X-Msg-Ref: server-9.tower-120.messagelabs.com!1241109106!47161907!1 X-StarScan-Version: 6.0.0; banners=-,-,- X-Originating-IP: [144.160.20.54] Received: (qmail 22040 invoked from network); 30 Apr 2009 16:31:47 -0000 Received: from sbcsmtp7.sbc.com (HELO mlpi135.enaf.sfdc.sbc.com) (144.160.20.54) by server-9.tower-120.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 30 Apr 2009 16:31:47 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpi135.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id n3UGVkK5024432 for ; Thu, 30 Apr 2009 12:31:46 -0400 Received: from gaalpa1msgusr7e.ugd.att.com (gaalpa1msgusr7e.ugd.att.com [135.53.26.19]) by mlpi135.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id n3UGVd2v024361 for ; Thu, 30 Apr 2009 12:31:40 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Date: Thu, 30 Apr 2009 12:31:39 -0400 Message-ID: <14C85D6CCBE92743AF33663BF5D24EBA02BD46D3@gaalpa1msgusr7e.ugd.att.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] Target URI and History Info bis Thread-Index: AcnINeOydImGrHrHSe2tPos5cdCgcgBd13mQAAD4bME= From: "DOLLY, MARTIN C, ATTLABS" To: , Subject: Re: [sipcore] Target URI and History Info bis X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Apr 2009 16:30:26 -0000 TWFyeSwNCg0KQ291bGQgeW91IHBsZWFzZSBzdW1tYXJpemUgd2hlcmUgdGhpcyB0aHJlYWQgaXMg YXQ/DQoNCkkgYmVsaWV2ZSB0aGF0IHRhcmdldCBhbmQgSEkgc2hvdWxkIGJlIGxpbmtlZCBmcm9t IGEgcHJvY2VzcyBwb2ludCBvZiB2aWV3LCBpZiBub3QgYnkgbm9ybWF0aXZlIHJlZmVyZW5jZXMg c3VjaCB0aGF0IHRoZXkgcHJvZ3Jlc3MgYXMgaW5kZXBlbmRlbnQgZG9jdW1lbnRzIHRvZ2V0aGVy LiBXaXRoIHRoZSBlbXBoYXNpcyBvbiB0b2dldGhlci4NCg0KVGhhbmtzDQoNCk1hcnRpbg0KDQot LS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tDQpGcm9tOiBzaXBjb3JlLWJvdW5jZXNAaWV0Zi5v cmcgPHNpcGNvcmUtYm91bmNlc0BpZXRmLm9yZz4NClRvOiBzZ2FyZ0BjZWRhcnBvaW50Y29tLmNv bSA8c2dhcmdAY2VkYXJwb2ludGNvbS5jb20+OyBzaXBjb3JlQGlldGYub3JnIDxzaXBjb3JlQGll dGYub3JnPg0KU2VudDogVGh1IEFwciAzMCAxMjoyMTo1NSAyMDA5DQpTdWJqZWN0OiBSZTogW3Np cGNvcmVdIFRhcmdldCBVUkkgYW5kIEhpc3RvcnkgSW5mbyBiaXMNCg0KSGkgU3VtaXQsDQoNCklu IGdlbmVyYWwsIHdlIGRvIG5vdCBpbmNsdWRlIElTVVAgSS9XIGZsb3dzIGluIHN0YW5kYXJkcyB0 cmFjayBTSVANCnByb3RvY29sIGRvY3VtZW50cy4gVGhlcmUgYXJlIGEgZmV3IGNhc2VzIHdoZXJl IHRoYXQgaGFzIGJlZW4gZG9uZSBpbg0KSW5mb3JtYXRpb25hbCBkb2N1bWVudHMgaW4gdGhlIHBh c3QsIGJ1dCBteSB1bmRlcnN0YW5kaW5nIHdhcyB0aGF0IHRoZQ0KZGVjaXNpb24gd2FzIG1hZGUg cXVpdGUgc29tZSB0aW1lIGFnbyB0aGF0IHRoZSBJL1cgaXMgbW9yZSBhcHByb3ByaWF0ZWx5DQpk ZWZpbmVkIGJ5IG90aGVyIFNET3MuDQoNClRoZXJlIGlzIG5vdGhpbmcgbm9ybWF0aXZlIGZyb20g YSBTSVAgcHJvdG9jb2wgcGVyc3BlY3RpdmUgZm9yIHRoZQ0KSGlzdG9yeS1JbmZvIGhlYWRlciBp biB0ZXJtcyBvZiB3aGF0IHRoZSBpbmRleCBzaG91bGQgYmUgd2hlbg0KaW50ZXJ3b3JraW5nIHdp dGggSVNVUCAob3IgYW55IG90aGVyIFBTVE4gcHJvdG9jb2wpIC0gb3RoZXIgdGhhbiBpdCBpcw0K cmVjb21tZW5kZWQgdG8gc3RhcnQgYXQgIjEiLiAgIEFsc28sIG5vdGUgaXQgaXMgYW4gaW5kZXgg aW4gdGhlDQpIaXN0b3J5LUluZm8gaGVhZGVyIGFuZCBub3QgYSBjb3VudCAtIHlvdSBjYW4gZGVy aXZlIHRoZSBjb3VudCBieQ0KbG9va2luZyBhdCB0aGUgdHJlZSBwcm9kdWNlZCBieSB0aGUgaW5k aWNlcyBpbiB0aGUgSGlzdG9yeS1JbmZvIGhlYWRlci4NClRoaXMgaXMgZGlzY3Vzc2VkIGluIHRo ZQ0KZHJhZnQtbW9oYWxpLWRyYWZ0LW1vaGFsaS1kaXZlcnNpb24taGlzdG9yeS1pbmZvLTAyLCB3 aGljaCBpcyBhIG1vcmUNCmFwcHJvcHJpYXRlIGRvY3VtZW50IChvciBhIHNpbWlsYXIgZG9jdW1l bnQgcHJvZHVjZWQgYnkgYW5vdGhlciBTRE8pIGZvcg0KZGVzY3JpYmluZyB0aGlzIGludGVyd29y a2luZy4gDQoNClllcywgeW91IGFyZSBhYnNvbHV0ZWx5IGNvcnJlY3QgdGhhdCB0aGVyZSB3aWxs IGJlIGEgbG9zcyBvZiBpbmZvcm1hdGlvbg0Kd2hlbiB5b3UgaW50ZXJ3b3JrIFNJUC0+SVNVUC4g IFRoYXQgaXMgc29tZXRoaW5nIGlkZW50aWZpZWQgaW4gdGhlDQp0aHJlYWQgd2l0aCByZWdhcmRz IHRvIHRoZQ0KZHJhZnQtbW9oYWxpLWRyYWZ0LW1vaGFsaS1kaXZlcnNpb24taGlzdG9yeS1pbmZv LTAyOg0KaHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL2JsaXNzL2N1cnJlbnQv bXNnMDA5MjMuaHRtbA0KDQpSZWdhcmRzLA0KTWFyeS4gDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2Fn ZS0tLS0tDQpGcm9tOiBzaXBjb3JlLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpzaXBjb3JlLWJv dW5jZXNAaWV0Zi5vcmddIE9uDQpCZWhhbGYgT2YgU3VtaXQgR2FyZw0KU2VudDogVHVlc2RheSwg QXByaWwgMjgsIDIwMDkgMjoxNyBQTQ0KVG86IHNpcGNvcmVAaWV0Zi5vcmcNClN1YmplY3Q6IFtz aXBjb3JlXSBUYXJnZXQgVVJJIGFuZCBIaXN0b3J5IEluZm8gYmlzDQoNCg0KSXQgd291bGQgYmUg bmljZSBpZiB0aGUgZXhhbXBsZXMgc2VjdGlvbiBpbmNsdWRlZCBQU1ROIGludGVyd29ya2luZw0K dG9vLi4NCg0KTXkgcHJvYmxlbToNCg0KSVNVUCB0byBTSVA6DQpJbmNvbWluZyByZWRpcmVjdGlv biBjb3VudCBpcyBzYXkgMy4NCkEgcmVkaXJlY3Rpb24gb2NjdXJzLi4uDQoNClRoZSBuZXcgY291 bnQgc2hvdWxkIGJlPw0KMy4xIE9SIDQgT1IgMS4xLjEuMQ0KQWxzbywgd2UgbWF5IG5vdCBoYXZl IGVub3VnaCBpbmZvcm1hdGlvbiB0byBjcmVhdGUgdGhlIGNvbXBsZXRlDQpoaWVyYXJjaHkgb2Yg SGlzdG9yeS1JbmZvIGhlYWRlcnMuLi4NCg0KU2ltaWxhcmx5LCBob3cgdG8gaW50ZXJwcmV0IHRo ZSBkYXRhIGluIFNJUCB0byBJU1VQIHNjZW5hcmlvcz8NCg0KTGFjayBvZiB0aGlzIGNsYXJpdHkg aW4gaW50ZXJ3b3JraW5nIGlzIG9uZSByZWFzb24gd2h5IERpdmVyc2lvbiBpcyBpbg0KdXNlIGV2 ZW4gYWZ0ZXIgYWxsIHRoZXNlIHllYXJzLi4uDQoNCi1TdW1pdA0KDQotLS0tLU9yaWdpbmFsIE1l c3NhZ2UtLS0tLQ0KRnJvbTogc2lwY29yZS1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86c2lwY29y ZS1ib3VuY2VzQGlldGYub3JnXSBPbg0KQmVoYWxmIE9mIE1hcnkgQmFybmVzDQpTZW50OiBGcmlk YXksIEFwcmlsIDI0LCAyMDA5IDQ6NTUgUE0NClRvOiBIYW5zIEVyaWsgdmFuIEVsYnVyZzsgR29u emFsbyBDYW1hcmlsbG8NCkNjOiBTSVBDT1JFDQpTdWJqZWN0OiBSZTogW3NpcGNvcmVdIFRhcmdl dCBVUkkgYW5kIEhpc3RvcnkgSW5mbyBiaXMNCg0KSnVzdCB0byByZS1pdGVyYXRlIG9uY2UgbW9y ZSwgNDI0NGJpcyBhbHJlYWR5IGNvbnRhaW5zIGEgc3VwZXJzZXQgb2YgdGhlDQpub3JtYXRpdmUg dGV4dCBmb3IgSGlzdG9yeS1JbmZvIGhlYWRlciBmcm9tIHRoZSBjdXJyZW50IHRhcmdldC11cmkN CmRvY3VtZW50LiAgRnJhbmNvaXMgaGFzIHByb3Bvc2VkIGEgZmFpcmx5IHN0cmFpZ2h0Zm9yd2Fy ZCBwYXRoIGZvcg0KNDI0NGJpcyB0aGF0IHNob3VsZCBhbGxvdyB1cyB0byBhdm9pZCBhbnkgb2Yg dGhlIGh1cmRsZXMgYW5kIG9wZW4gZW5kZWQNCmRlYmF0ZXMgYXMgdG8gSGlzdG9yeS1JbmZvIGlz c3VlcyAtIHRoZSBrbm93biBpc3N1ZXMgYXJlIHF1aXRlDQpzdHJhaWdodC1mb3J3YXJkIHRvIHNv bHZlIGFuZCB0aGUgaXNzdWVzIGF0IGhhbmQgcmVhbGx5IGFyZSBwcm92aWRpbmcgYQ0Kc29sdXRp b24gZm9yIHRhcmdldC11cmkuICBUaGUgaWRlYSB0aGF0IHRoZSB0YXJnZXQtdXJpIGRvY3VtZW50 IHdvdWxkDQpwcm9ncmVzcyBtdWNoIHF1aWNrZXIgdGhhbiA0MjQ0YmlzIGlzIGEgcmVkIGhlcnJp bmcgLSBpbiBwYXJ0aWN1bGFyDQpiYXNlZCBvbiBteSBjb21tZW50cyB0aGF0IHlvdSBuZWVkIG1v cmUgY2hhbmdlcyB0byA0MjQ0IHRvIHN1cHBvcnQNCnRhcmdldC11cmkgdGhhbiBqdXN0IHRoZSBu ZXcgdGFncy4gDQoNCk1hcnkuIA0KDQoNCkZvcmV2ZXIsDQpTdW1pdA0KIlRoZSByZWFzb25hYmxl IG1hbiBhZGFwdHMgaGltc2VsZiB0byB0aGUgd29ybGQ7IHRoZSB1bnJlYXNvbmFibGUgb25lDQpw ZXJzaXN0cyBpbiB0cnlpbmcgdG8gYWRhcHQgdGhlIHdvcmxkIHRvIGhpbXNlbGYuIFRoZXJlZm9y ZSBhbGwgcHJvZ3Jlc3MNCmRlcGVuZHMgb24gdGhlIHVucmVhc29uYWJsZSBtYW4uIg0KLS0gR2Vv cmdlIEJlcm5hcmQgU2hhdw0KDQoNCiAgICAgIA0KX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCnNpcGNvcmUgbWFpbGluZyBsaXN0DQpzaXBjb3JlQGlldGYu b3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NpcGNvcmUNCl9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpzaXBjb3JlIG1haWxp bmcgbGlzdA0Kc2lwY29yZUBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9zaXBjb3JlDQo= From mary.barnes@nortel.com Thu Apr 30 09:43:01 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8DAAE3A6EB4 for ; Thu, 30 Apr 2009 09:43:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.478 X-Spam-Level: X-Spam-Status: No, score=-6.478 tagged_above=-999 required=5 tests=[AWL=0.121, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gLo4WOdKawh2 for ; Thu, 30 Apr 2009 09:43:00 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id 5740C3A6B72 for ; Thu, 30 Apr 2009 09:43:00 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id n3UGiGV28648; Thu, 30 Apr 2009 16:44:16 GMT 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, 30 Apr 2009 11:46:59 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF1DBE5794@zrc2hxm0.corp.nortel.com> In-Reply-To: <14C85D6CCBE92743AF33663BF5D24EBA02BD46D3@gaalpa1msgusr7e.ugd.att.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] Target URI and History Info bis Thread-Index: AcnINeOydImGrHrHSe2tPos5cdCgcgBd13mQAAD4bMEAACRcMA== References: <14C85D6CCBE92743AF33663BF5D24EBA02BD46D3@gaalpa1msgusr7e.ugd.att.com> From: "Mary Barnes" To: "DOLLY, MARTIN C, ATTLABS" , Subject: Re: [sipcore] Target URI and History Info bis X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Apr 2009 16:43:01 -0000 Martin, Sumit's point is independent of whether we have one or two docs.=20 But, I certainly agree with your point that the target-uri and 4244bis doucments should progress together, with the target-uri document being informational and the normative text in 4244bis (which is as it is in the -00). =20 We (Francois and myself) will update 4244bis based on this thread: http://www.ietf.org/mail-archive/web/sipcore/current/msg00070.html So, it might be better for folks to see those changes and then the WG could decide whether they are okay with progressing the documents together. There had also been a suggestion in the past that we could pull the requirements and call flows into 4244bis (right now, there is one new requirement in 4244bis and just a summary of the use cases) AND that was the gist of the original poll posted by Gonzalo, which may be where there is lack of clarity on what has been agreed. I think we can decide that later and my preference obviously is to keep them separate as I think 4244bis would get too large (beyond the too large that Christer already thinks it is ;) if we do that.=20 Regards, Mary.=20 -----Original Message----- From: DOLLY, MARTIN C, ATTLABS [mailto:mdolly@att.com]=20 Sent: Thursday, April 30, 2009 11:32 AM To: Barnes, Mary (RICH2:AR00); sipcore@ietf.org Subject: Re: [sipcore] Target URI and History Info bis Mary, Could you please summarize where this thread is at? I believe that target and HI should be linked from a process point of view, if not by normative references such that they progress as independent documents together. With the emphasis on together. Thanks Martin ----- Original Message ----- From: sipcore-bounces@ietf.org To: sgarg@cedarpointcom.com ; sipcore@ietf.org Sent: Thu Apr 30 12:21:55 2009 Subject: Re: [sipcore] Target URI and History Info bis Hi Sumit, In general, we do not include ISUP I/W flows in standards track SIP protocol documents. There are a few cases where that has been done in Informational documents in the past, but my understanding was that the decision was made quite some time ago that the I/W is more appropriately defined by other SDOs. There is nothing normative from a SIP protocol perspective for the History-Info header in terms of what the index should be when interworking with ISUP (or any other PSTN protocol) - other than it is recommended to start at "1". Also, note it is an index in the History-Info header and not a count - you can derive the count by looking at the tree produced by the indices in the History-Info header. This is discussed in the draft-mohali-draft-mohali-diversion-history-info-02, which is a more appropriate document (or a similar document produced by another SDO) for describing this interworking.=20 Yes, you are absolutely correct that there will be a loss of information when you interwork SIP->ISUP. That is something identified in the thread with regards to the draft-mohali-draft-mohali-diversion-history-info-02: http://www.ietf.org/mail-archive/web/bliss/current/msg00923.html Regards, Mary.=20 -----Original Message----- From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behalf Of Sumit Garg Sent: Tuesday, April 28, 2009 2:17 PM To: sipcore@ietf.org Subject: [sipcore] Target URI and History Info bis It would be nice if the examples section included PSTN interworking too.. My problem: ISUP to SIP: Incoming redirection count is say 3. A redirection occurs... The new count should be? 3.1 OR 4 OR 1.1.1.1 Also, we may not have enough information to create the complete hierarchy of History-Info headers... Similarly, how to interpret the data in SIP to ISUP scenarios? Lack of this clarity in interworking is one reason why Diversion is in use even after all these years... -Sumit -----Original Message----- From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behalf Of Mary Barnes Sent: Friday, April 24, 2009 4:55 PM To: Hans Erik van Elburg; Gonzalo Camarillo Cc: SIPCORE Subject: Re: [sipcore] Target URI and History Info bis Just to re-iterate once more, 4244bis already contains a superset of the normative text for History-Info header from the current target-uri document. Francois has proposed a fairly straightforward path for 4244bis that should allow us to avoid any of the hurdles and open ended debates as to History-Info issues - the known issues are quite straight-forward to solve and the issues at hand really are providing a solution for target-uri. The idea that the target-uri document would progress much quicker than 4244bis is a red herring - in particular based on my comments that you need more changes to 4244 to support target-uri than just the new tags.=20 Mary.=20 Forever, Sumit "The reasonable man adapts himself to the world; the unreasonable one persists in trying to adapt the world to himself. Therefore all progress depends on the unreasonable man." -- George Bernard Shaw =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 mdolly@att.com Thu Apr 30 09:52:00 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7E4703A6D83 for ; Thu, 30 Apr 2009 09:52:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.584 X-Spam-Level: X-Spam-Status: No, score=-106.584 tagged_above=-999 required=5 tests=[AWL=0.015, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sInm5UKL-98g for ; Thu, 30 Apr 2009 09:51:59 -0700 (PDT) Received: from mail167.messagelabs.com (mail167.messagelabs.com [216.82.253.179]) by core3.amsl.com (Postfix) with ESMTP id 0C60B3A723C for ; Thu, 30 Apr 2009 09:51:53 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: mdolly@att.com X-Msg-Ref: server-15.tower-167.messagelabs.com!1241110395!9919115!1 X-StarScan-Version: 6.0.0; banners=-,-,- X-Originating-IP: [144.160.20.54] Received: (qmail 22580 invoked from network); 30 Apr 2009 16:53:15 -0000 Received: from sbcsmtp7.sbc.com (HELO mlpi135.enaf.sfdc.sbc.com) (144.160.20.54) by server-15.tower-167.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 30 Apr 2009 16:53:15 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpi135.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id n3UGrFxE006764 for ; Thu, 30 Apr 2009 12:53:15 -0400 Received: from gaalpa1msgusr7e.ugd.att.com (gaalpa1msgusr7e.ugd.att.com [135.53.26.19]) by mlpi135.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id n3UGr955006702 for ; Thu, 30 Apr 2009 12:53:09 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Date: Thu, 30 Apr 2009 12:53:08 -0400 Message-ID: <14C85D6CCBE92743AF33663BF5D24EBA02BD46D4@gaalpa1msgusr7e.ugd.att.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] Target URI and History Info bis Thread-Index: AcnINeOydImGrHrHSe2tPos5cdCgcgBd13mQAAD4bMEAACRcMAAAm7Rc From: "DOLLY, MARTIN C, ATTLABS" To: , Subject: Re: [sipcore] Target URI and History Info bis X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Apr 2009 16:52:00 -0000 U29ycnkgbXkgcG9zdCB3YXMgbm90IHRvIGhpcyBwb2ludC4gUGxlYXNlIHJlYWQgYXMgaWYgaXQg d2VyZSBub3QgYSByZXBseQ0KDQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tDQpGcm9tOiBN YXJ5IEJhcm5lcyA8bWFyeS5iYXJuZXNAbm9ydGVsLmNvbT4NClRvOiBET0xMWSwgTUFSVElOIEMs IEFUVExBQlM7IHNpcGNvcmVAaWV0Zi5vcmcgPHNpcGNvcmVAaWV0Zi5vcmc+DQpTZW50OiBUaHUg QXByIDMwIDEyOjQ2OjU5IDIwMDkNClN1YmplY3Q6IFJFOiBbc2lwY29yZV0gVGFyZ2V0IFVSSSBh bmQgSGlzdG9yeSBJbmZvIGJpcw0KDQpNYXJ0aW4sDQoNClN1bWl0J3MgcG9pbnQgaXMgaW5kZXBl bmRlbnQgb2Ygd2hldGhlciB3ZSBoYXZlIG9uZSBvciB0d28gZG9jcy4gDQoNCkJ1dCwgSSBjZXJ0 YWlubHkgYWdyZWUgd2l0aCB5b3VyIHBvaW50IHRoYXQgdGhlIHRhcmdldC11cmkgYW5kIDQyNDRi aXMNCmRvdWNtZW50cyBzaG91bGQgcHJvZ3Jlc3MgdG9nZXRoZXIsIHdpdGggdGhlIHRhcmdldC11 cmkgZG9jdW1lbnQgYmVpbmcNCmluZm9ybWF0aW9uYWwgYW5kIHRoZSBub3JtYXRpdmUgdGV4dCBp biA0MjQ0YmlzICh3aGljaCBpcyBhcyBpdCBpcyBpbg0KdGhlIC0wMCkuICAgDQoNCldlIChGcmFu Y29pcyBhbmQgbXlzZWxmKSB3aWxsIHVwZGF0ZSA0MjQ0YmlzIGJhc2VkIG9uIHRoaXMgdGhyZWFk Og0KaHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL3NpcGNvcmUvY3VycmVudC9t c2cwMDA3MC5odG1sDQoNClNvLCBpdCBtaWdodCBiZSBiZXR0ZXIgZm9yIGZvbGtzIHRvIHNlZSB0 aG9zZSBjaGFuZ2VzIGFuZCB0aGVuIHRoZSBXRw0KY291bGQgZGVjaWRlIHdoZXRoZXIgdGhleSBh cmUgb2theSB3aXRoIHByb2dyZXNzaW5nIHRoZSBkb2N1bWVudHMNCnRvZ2V0aGVyLiAgVGhlcmUg aGFkIGFsc28gYmVlbiBhIHN1Z2dlc3Rpb24gaW4gdGhlIHBhc3QgdGhhdCB3ZSBjb3VsZA0KcHVs bCB0aGUgcmVxdWlyZW1lbnRzIGFuZCBjYWxsIGZsb3dzIGludG8gNDI0NGJpcyAocmlnaHQgbm93 LCB0aGVyZSBpcw0Kb25lIG5ldyByZXF1aXJlbWVudCBpbiA0MjQ0YmlzIGFuZCBqdXN0IGEgc3Vt bWFyeSBvZiB0aGUgdXNlIGNhc2VzKSBBTkQNCnRoYXQgd2FzIHRoZSBnaXN0IG9mIHRoZSBvcmln aW5hbCBwb2xsIHBvc3RlZCBieSBHb256YWxvLCB3aGljaCBtYXkgYmUNCndoZXJlIHRoZXJlIGlz IGxhY2sgb2YgY2xhcml0eSBvbiB3aGF0IGhhcyBiZWVuIGFncmVlZC4gSSB0aGluayB3ZSBjYW4N CmRlY2lkZSB0aGF0IGxhdGVyIGFuZCBteSBwcmVmZXJlbmNlIG9idmlvdXNseSBpcyB0byBrZWVw IHRoZW0gc2VwYXJhdGUNCmFzIEkgdGhpbmsgNDI0NGJpcyB3b3VsZCBnZXQgdG9vIGxhcmdlIChi ZXlvbmQgdGhlIHRvbyBsYXJnZSB0aGF0DQpDaHJpc3RlciBhbHJlYWR5IHRoaW5rcyBpdCBpcyA7 KSBpZiB3ZSBkbyB0aGF0LiANCg0KUmVnYXJkcywNCk1hcnkuIA0KDQotLS0tLU9yaWdpbmFsIE1l c3NhZ2UtLS0tLQ0KRnJvbTogRE9MTFksIE1BUlRJTiBDLCBBVFRMQUJTIFttYWlsdG86bWRvbGx5 QGF0dC5jb21dIA0KU2VudDogVGh1cnNkYXksIEFwcmlsIDMwLCAyMDA5IDExOjMyIEFNDQpUbzog QmFybmVzLCBNYXJ5IChSSUNIMjpBUjAwKTsgc2lwY29yZUBpZXRmLm9yZw0KU3ViamVjdDogUmU6 IFtzaXBjb3JlXSBUYXJnZXQgVVJJIGFuZCBIaXN0b3J5IEluZm8gYmlzDQoNCk1hcnksDQoNCkNv dWxkIHlvdSBwbGVhc2Ugc3VtbWFyaXplIHdoZXJlIHRoaXMgdGhyZWFkIGlzIGF0Pw0KDQpJIGJl bGlldmUgdGhhdCB0YXJnZXQgYW5kIEhJIHNob3VsZCBiZSBsaW5rZWQgZnJvbSBhIHByb2Nlc3Mg cG9pbnQgb2YNCnZpZXcsIGlmIG5vdCBieSBub3JtYXRpdmUgcmVmZXJlbmNlcyBzdWNoIHRoYXQg dGhleSBwcm9ncmVzcyBhcw0KaW5kZXBlbmRlbnQgZG9jdW1lbnRzIHRvZ2V0aGVyLiBXaXRoIHRo ZSBlbXBoYXNpcyBvbiB0b2dldGhlci4NCg0KVGhhbmtzDQoNCk1hcnRpbg0KDQotLS0tLSBPcmln aW5hbCBNZXNzYWdlIC0tLS0tDQpGcm9tOiBzaXBjb3JlLWJvdW5jZXNAaWV0Zi5vcmcgPHNpcGNv cmUtYm91bmNlc0BpZXRmLm9yZz4NClRvOiBzZ2FyZ0BjZWRhcnBvaW50Y29tLmNvbSA8c2dhcmdA Y2VkYXJwb2ludGNvbS5jb20+OyBzaXBjb3JlQGlldGYub3JnDQo8c2lwY29yZUBpZXRmLm9yZz4N ClNlbnQ6IFRodSBBcHIgMzAgMTI6MjE6NTUgMjAwOQ0KU3ViamVjdDogUmU6IFtzaXBjb3JlXSBU YXJnZXQgVVJJIGFuZCBIaXN0b3J5IEluZm8gYmlzDQoNCkhpIFN1bWl0LA0KDQpJbiBnZW5lcmFs LCB3ZSBkbyBub3QgaW5jbHVkZSBJU1VQIEkvVyBmbG93cyBpbiBzdGFuZGFyZHMgdHJhY2sgU0lQ DQpwcm90b2NvbCBkb2N1bWVudHMuIFRoZXJlIGFyZSBhIGZldyBjYXNlcyB3aGVyZSB0aGF0IGhh cyBiZWVuIGRvbmUgaW4NCkluZm9ybWF0aW9uYWwgZG9jdW1lbnRzIGluIHRoZSBwYXN0LCBidXQg bXkgdW5kZXJzdGFuZGluZyB3YXMgdGhhdCB0aGUNCmRlY2lzaW9uIHdhcyBtYWRlIHF1aXRlIHNv bWUgdGltZSBhZ28gdGhhdCB0aGUgSS9XIGlzIG1vcmUgYXBwcm9wcmlhdGVseQ0KZGVmaW5lZCBi eSBvdGhlciBTRE9zLg0KDQpUaGVyZSBpcyBub3RoaW5nIG5vcm1hdGl2ZSBmcm9tIGEgU0lQIHBy b3RvY29sIHBlcnNwZWN0aXZlIGZvciB0aGUNCkhpc3RvcnktSW5mbyBoZWFkZXIgaW4gdGVybXMg b2Ygd2hhdCB0aGUgaW5kZXggc2hvdWxkIGJlIHdoZW4NCmludGVyd29ya2luZyB3aXRoIElTVVAg KG9yIGFueSBvdGhlciBQU1ROIHByb3RvY29sKSAtIG90aGVyIHRoYW4gaXQgaXMNCnJlY29tbWVu ZGVkIHRvIHN0YXJ0IGF0ICIxIi4gICBBbHNvLCBub3RlIGl0IGlzIGFuIGluZGV4IGluIHRoZQ0K SGlzdG9yeS1JbmZvIGhlYWRlciBhbmQgbm90IGEgY291bnQgLSB5b3UgY2FuIGRlcml2ZSB0aGUg Y291bnQgYnkNCmxvb2tpbmcgYXQgdGhlIHRyZWUgcHJvZHVjZWQgYnkgdGhlIGluZGljZXMgaW4g dGhlIEhpc3RvcnktSW5mbyBoZWFkZXIuDQpUaGlzIGlzIGRpc2N1c3NlZCBpbiB0aGUNCmRyYWZ0 LW1vaGFsaS1kcmFmdC1tb2hhbGktZGl2ZXJzaW9uLWhpc3RvcnktaW5mby0wMiwgd2hpY2ggaXMg YSBtb3JlDQphcHByb3ByaWF0ZSBkb2N1bWVudCAob3IgYSBzaW1pbGFyIGRvY3VtZW50IHByb2R1 Y2VkIGJ5IGFub3RoZXIgU0RPKSBmb3INCmRlc2NyaWJpbmcgdGhpcyBpbnRlcndvcmtpbmcuIA0K DQpZZXMsIHlvdSBhcmUgYWJzb2x1dGVseSBjb3JyZWN0IHRoYXQgdGhlcmUgd2lsbCBiZSBhIGxv c3Mgb2YgaW5mb3JtYXRpb24NCndoZW4geW91IGludGVyd29yayBTSVAtPklTVVAuICBUaGF0IGlz IHNvbWV0aGluZyBpZGVudGlmaWVkIGluIHRoZQ0KdGhyZWFkIHdpdGggcmVnYXJkcyB0byB0aGUN CmRyYWZ0LW1vaGFsaS1kcmFmdC1tb2hhbGktZGl2ZXJzaW9uLWhpc3RvcnktaW5mby0wMjoNCmh0 dHA6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9ibGlzcy9jdXJyZW50L21zZzAwOTIz Lmh0bWwNCg0KUmVnYXJkcywNCk1hcnkuIA0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0K RnJvbTogc2lwY29yZS1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86c2lwY29yZS1ib3VuY2VzQGll dGYub3JnXSBPbg0KQmVoYWxmIE9mIFN1bWl0IEdhcmcNClNlbnQ6IFR1ZXNkYXksIEFwcmlsIDI4 LCAyMDA5IDI6MTcgUE0NClRvOiBzaXBjb3JlQGlldGYub3JnDQpTdWJqZWN0OiBbc2lwY29yZV0g VGFyZ2V0IFVSSSBhbmQgSGlzdG9yeSBJbmZvIGJpcw0KDQoNCkl0IHdvdWxkIGJlIG5pY2UgaWYg dGhlIGV4YW1wbGVzIHNlY3Rpb24gaW5jbHVkZWQgUFNUTiBpbnRlcndvcmtpbmcNCnRvby4uDQoN Ck15IHByb2JsZW06DQoNCklTVVAgdG8gU0lQOg0KSW5jb21pbmcgcmVkaXJlY3Rpb24gY291bnQg aXMgc2F5IDMuDQpBIHJlZGlyZWN0aW9uIG9jY3Vycy4uLg0KDQpUaGUgbmV3IGNvdW50IHNob3Vs ZCBiZT8NCjMuMSBPUiA0IE9SIDEuMS4xLjENCkFsc28sIHdlIG1heSBub3QgaGF2ZSBlbm91Z2gg aW5mb3JtYXRpb24gdG8gY3JlYXRlIHRoZSBjb21wbGV0ZQ0KaGllcmFyY2h5IG9mIEhpc3Rvcnkt SW5mbyBoZWFkZXJzLi4uDQoNClNpbWlsYXJseSwgaG93IHRvIGludGVycHJldCB0aGUgZGF0YSBp biBTSVAgdG8gSVNVUCBzY2VuYXJpb3M/DQoNCkxhY2sgb2YgdGhpcyBjbGFyaXR5IGluIGludGVy d29ya2luZyBpcyBvbmUgcmVhc29uIHdoeSBEaXZlcnNpb24gaXMgaW4NCnVzZSBldmVuIGFmdGVy IGFsbCB0aGVzZSB5ZWFycy4uLg0KDQotU3VtaXQNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0t LS0NCkZyb206IHNpcGNvcmUtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOnNpcGNvcmUtYm91bmNl c0BpZXRmLm9yZ10gT24NCkJlaGFsZiBPZiBNYXJ5IEJhcm5lcw0KU2VudDogRnJpZGF5LCBBcHJp bCAyNCwgMjAwOSA0OjU1IFBNDQpUbzogSGFucyBFcmlrIHZhbiBFbGJ1cmc7IEdvbnphbG8gQ2Ft YXJpbGxvDQpDYzogU0lQQ09SRQ0KU3ViamVjdDogUmU6IFtzaXBjb3JlXSBUYXJnZXQgVVJJIGFu ZCBIaXN0b3J5IEluZm8gYmlzDQoNCkp1c3QgdG8gcmUtaXRlcmF0ZSBvbmNlIG1vcmUsIDQyNDRi aXMgYWxyZWFkeSBjb250YWlucyBhIHN1cGVyc2V0IG9mIHRoZQ0Kbm9ybWF0aXZlIHRleHQgZm9y IEhpc3RvcnktSW5mbyBoZWFkZXIgZnJvbSB0aGUgY3VycmVudCB0YXJnZXQtdXJpDQpkb2N1bWVu dC4gIEZyYW5jb2lzIGhhcyBwcm9wb3NlZCBhIGZhaXJseSBzdHJhaWdodGZvcndhcmQgcGF0aCBm b3INCjQyNDRiaXMgdGhhdCBzaG91bGQgYWxsb3cgdXMgdG8gYXZvaWQgYW55IG9mIHRoZSBodXJk bGVzIGFuZCBvcGVuIGVuZGVkDQpkZWJhdGVzIGFzIHRvIEhpc3RvcnktSW5mbyBpc3N1ZXMgLSB0 aGUga25vd24gaXNzdWVzIGFyZSBxdWl0ZQ0Kc3RyYWlnaHQtZm9yd2FyZCB0byBzb2x2ZSBhbmQg dGhlIGlzc3VlcyBhdCBoYW5kIHJlYWxseSBhcmUgcHJvdmlkaW5nIGENCnNvbHV0aW9uIGZvciB0 YXJnZXQtdXJpLiAgVGhlIGlkZWEgdGhhdCB0aGUgdGFyZ2V0LXVyaSBkb2N1bWVudCB3b3VsZA0K cHJvZ3Jlc3MgbXVjaCBxdWlja2VyIHRoYW4gNDI0NGJpcyBpcyBhIHJlZCBoZXJyaW5nIC0gaW4g cGFydGljdWxhcg0KYmFzZWQgb24gbXkgY29tbWVudHMgdGhhdCB5b3UgbmVlZCBtb3JlIGNoYW5n ZXMgdG8gNDI0NCB0byBzdXBwb3J0DQp0YXJnZXQtdXJpIHRoYW4ganVzdCB0aGUgbmV3IHRhZ3Mu IA0KDQpNYXJ5LiANCg0KDQpGb3JldmVyLA0KU3VtaXQNCiJUaGUgcmVhc29uYWJsZSBtYW4gYWRh cHRzIGhpbXNlbGYgdG8gdGhlIHdvcmxkOyB0aGUgdW5yZWFzb25hYmxlIG9uZQ0KcGVyc2lzdHMg aW4gdHJ5aW5nIHRvIGFkYXB0IHRoZSB3b3JsZCB0byBoaW1zZWxmLiBUaGVyZWZvcmUgYWxsIHBy b2dyZXNzDQpkZXBlbmRzIG9uIHRoZSB1bnJlYXNvbmFibGUgbWFuLiINCi0tIEdlb3JnZSBCZXJu YXJkIFNoYXcNCg0KDQogICAgICANCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fDQpzaXBjb3JlIG1haWxpbmcgbGlzdA0Kc2lwY29yZUBpZXRmLm9yZw0KaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zaXBjb3JlDQpfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0Kc2lwY29yZSBtYWlsaW5nIGxpc3QN CnNpcGNvcmVAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v c2lwY29yZQ0K From dean.willis@softarmor.com Thu Apr 30 10:28:53 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 21CAA3A6829 for ; Thu, 30 Apr 2009 10:28:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.554 X-Spam-Level: X-Spam-Status: No, score=-2.554 tagged_above=-999 required=5 tests=[AWL=0.045, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TSKmUNReMcRV for ; Thu, 30 Apr 2009 10:28:52 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 3AFD63A6767 for ; Thu, 30 Apr 2009 10:28:52 -0700 (PDT) Received: from [192.168.2.102] (cpe-72-181-150-177.tx.res.rr.com [72.181.150.177]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id n3UHUBkJ024918 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 30 Apr 2009 12:30:13 -0500 Message-Id: <9A564A10-3F22-471A-832B-28117412AD93@softarmor.com> From: Dean Willis To: Hans Erik van Elburg In-Reply-To: <49F9718E.4070707@gmail.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Thu, 30 Apr 2009 12:30:05 -0500 References: <49F178CE.8000809@ericsson.com> <0ECC036E-2B21-49D5-AC42-1FEC8EC447BE@softarmor.com> <49F5D64B.20008@nostrum.com> <193E3797-2C8D-44EB-A869-DDDE39B303D9@nostrum.com> <06F3B3D8-BEA3-4B5A-990D-B9E8DCAB1FF1@softarmor.com> <49F9718E.4070707@gmail.com> X-Mailer: Apple Mail (2.930.3) Cc: SIPCORE Subject: Re: [sipcore] Long reply to: Target URI and History Info bis X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Apr 2009 17:28:53 -0000 On Apr 30, 2009, at 4:38 AM, Hans Erik van Elburg wrote: > Overloading in general is not a good design strategy, why do you > think that trying to mold everything (diversion/history info) into > Request URI is a good idea?? The reason that we're having this conversation is that we have proposals, History-Info being one, for 1) putting our parameters in to the original request-URI, and 2) recovering that original request-URI after it has been contact-routed (and otherwise mangled) so that the parameters can be used at the UAS. So the presumption exists that the original request URI is useful to the UAS. SIP did, and now SIPCORE has, a chartered item for making that happen. I'm trying to back up and make sure that we know WHY we're trying to deliver the original request URI to the UAS, and then asking if some other approach that meets the same requirements might actually be easier to do. > The problem here is that this information has nothing to do with > application invocation, but tells something about how the signalling > reached the callee (target). And this information is only relevant > to the callee if that decides that it is. That's a profound philosophical assertion. HTTP, for example, makes no consideration for "how the signaling reaches the target" in determining how to process a request. The fact that some think SIP should take this into consideration indicates to me that we have a layering problem in our design. From one perspective, this makes the application invocation implicit; the UAS has to guess what to do based on clues sprinkled throughout the communication and across several layers of the ISO stack. It's much better to have this sort of determination made based on explicit indicators at a single application layer. -- Dean From dean.willis@softarmor.com Thu Apr 30 10:36:51 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 240A13A68F4 for ; Thu, 30 Apr 2009 10:36:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.555 X-Spam-Level: X-Spam-Status: No, score=-2.555 tagged_above=-999 required=5 tests=[AWL=0.044, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P-2RrmO156e0 for ; Thu, 30 Apr 2009 10:36:50 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 2F6C73A6AA1 for ; Thu, 30 Apr 2009 10:36:50 -0700 (PDT) Received: from [192.168.2.102] (cpe-72-181-150-177.tx.res.rr.com [72.181.150.177]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id n3UHc7sK025004 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Thu, 30 Apr 2009 12:38:09 -0500 Message-Id: From: Dean Willis To: Hans Erik van Elburg In-Reply-To: <49F9BE92.1050601@gmail.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Thu, 30 Apr 2009 12:38:02 -0500 References: <0D5F89FAC29E2C41B98A6A762007F5D001D4A39A@GBNTHT12009MSX.gb002.siemens.net><49F5B3FE.8030104@cisco.com><28B7C3AA2A7ABA4A841F11217ABE78D67590BF97@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <49F5C2C4.70501@cisco.com> <49F71501.2020300@cisco.com> <49F742EE.30504@softarmor.com> <49F75022.4010905@cisco.com> <6B78E793-0C48-427E-8895-337D5F592957@softarmor.com> <7C450C3A-33F9-450D-B424-4DCD86D5D99A@softarmor.com> <49F9BE92.1050601@gmail.com> X-Mailer: Apple Mail (2.930.3) Cc: SIPCORE Subject: Re: [sipcore] Question on Require in responses X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Apr 2009 17:36:51 -0000 On Apr 30, 2009, at 10:06 AM, Hans Erik van Elburg wrote: > > Dean Willis wrote: >> The option tag is a means of 1) discovering whether or not the far- >> end supports a specific extension and of 2) declaring the >> criticality of understanding that extension relative to satisfying >> a request and 3) informing the UAC of what extensions were applied >> to the request in order to generate the response. This is purely a >> function of capability negotiation, not one of invocation. >> >> The extension itself (typically, an extension header field, >> although there are other types of extensions) is what causes the >> extension to be invoked. > Depends a bit how you define extension, but I would argue that if I > require an extension to be supported on a transaction/dialog by the > UAS and the UAS accepts the request that this means that for this > call the UAS behaves as it should according to the extensions > specification. > > Saying that an extensions invokes itself is meaningless to me. > > A UAS may choose to only invoke the extension behaviour if it finds > that the extension is required. That comes close to saying that the > require:extension invokes the behaviour in the UAS, but it is not at > all the same. > The Require doesn't control whether the UAS invokes the extension. The UAS may invoke the extension on its own recognizance. Most likely, it chooses to do so based on 1) the presence of a Supported indicator for the extension in a request as evidence that the UAC supports the extension or the presence of an extension header in the request that also indicates support in the UAC and 2) support for that extension in the UAS. Other extensions may not require support in the UAC, so may be enacted by this UAS purely on local policy. For example, consider any SIP extension, such as Answer-Mode. If a UAS gets a request with an Answer-Mode header, it knows that the UAC supports Answer-Mode. The UAS then decides based on local policy (probably authorization policy) how it is going to handle the request, that is, whether or not it will auto-answer. Since the UAS supports the extension, the presence or absence of a Require: answer-mode makes absolutely no difference to it. The only time the presence of a Require properly impacts the behavior of a UAS is if that UAS does NOT support the extension indicated by the Require. -- Dean From ietf.hanserik@gmail.com Thu Apr 30 11:50:26 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C9FCF3A6B66 for ; Thu, 30 Apr 2009 11:50:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.531 X-Spam-Level: X-Spam-Status: No, score=-2.531 tagged_above=-999 required=5 tests=[AWL=0.068, BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i0D3UlKGo3mo for ; Thu, 30 Apr 2009 11:50:26 -0700 (PDT) Received: from mail-ew0-f176.google.com (mail-ew0-f176.google.com [209.85.219.176]) by core3.amsl.com (Postfix) with ESMTP id 8BA953A6A7A for ; Thu, 30 Apr 2009 11:50:25 -0700 (PDT) Received: by ewy24 with SMTP id 24so2095510ewy.37 for ; Thu, 30 Apr 2009 11:51:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=D7Ls1YEbCIez8uT7F9pYJwBubnDfiomu0oV13SVziTg=; b=J63r7M3LUFcw7jE5axIFqIMy9J2b5DlzxDVCcql+6UDoS0orp7Bxd22OYhxxi3sKvE YV7UThq7YU2IlwDOZ9x7qvvrlVxiz6359wm46NLE3+Qwxjs0tjrSmws6sRMOcdXQx2mv DccHBOnSCYaQwl+rJYIF/oMy94obJbJPu+1V4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=DcylA7N69nEzprDDa5D9FC8VsTlN1+E5zWeNSTq++gfGuoYsULPAabgj5QQn4LKLvv TDewi2FtMde4xjgNqaj53CWNzT6/UAb0hBugavg/eEvvbEH+YbhL89fMoBw1xVLUMk8X 6JUHyNKrI6CfHV5GF5tKPhj86vvFqXxjks2W4= Received: by 10.210.88.3 with SMTP id l3mr1040016ebb.81.1241117507841; Thu, 30 Apr 2009 11:51:47 -0700 (PDT) Received: from ?192.168.1.5? (212-182-129-30.ip.telfort.nl [212.182.129.30]) by mx.google.com with ESMTPS id 10sm4545681eyd.12.2009.04.30.11.51.46 (version=SSLv3 cipher=RC4-MD5); Thu, 30 Apr 2009 11:51:47 -0700 (PDT) Message-ID: <49F9F343.6090901@gmail.com> Date: Thu, 30 Apr 2009 20:51:47 +0200 From: Hans Erik van Elburg User-Agent: Thunderbird 2.0.0.21 (X11/20090409) MIME-Version: 1.0 To: Dean Willis References: <49F178CE.8000809@ericsson.com> <0ECC036E-2B21-49D5-AC42-1FEC8EC447BE@softarmor.com> <49F5D64B.20008@nostrum.com> <193E3797-2C8D-44EB-A869-DDDE39B303D9@nostrum.com> <06F3B3D8-BEA3-4B5A-990D-B9E8DCAB1FF1@softarmor.com> <49F9718E.4070707@gmail.com> <9A564A10-3F22-471A-832B-28117412AD93@softarmor.com> In-Reply-To: <9A564A10-3F22-471A-832B-28117412AD93@softarmor.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: SIPCORE Subject: Re: [sipcore] Long reply to: Target URI and History Info bis X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Apr 2009 18:50:26 -0000 Dean Willis wrote: > > On Apr 30, 2009, at 4:38 AM, Hans Erik van Elburg wrote: > >> Overloading in general is not a good design strategy, why do you >> think that trying to mold everything (diversion/history info) into >> Request URI is a good idea?? > > The reason that we're having this conversation is that we have > proposals, History-Info being one, for 1) putting our parameters in to > the original request-URI, and 2) recovering that original request-URI > after it has been contact-routed (and otherwise mangled) so that the > parameters can be used at the UAS. > > So the presumption exists that the original request URI is useful to > the UAS. SIP did, and now SIPCORE has, a chartered item for making > that happen. > > I'm trying to back up and make sure that we know WHY we're trying to > deliver the original request URI to the UAS, and then asking if some > other approach that meets the same requirements might actually be > easier to do. > That is fine of course, but the point is that we are not talking about delivering parameters to an application, but about recovering a complete URI that has gone lost on the way. >> The problem here is that this information has nothing to do with >> application invocation, but tells something about how the signalling >> reached the callee (target). And this information is only relevant to >> the callee if that decides that it is. > > > That's a profound philosophical assertion. HTTP, for example, makes no > consideration for "how the signaling reaches the target" in > determining how to process a request. The fact that some think SIP > should take this into consideration indicates to me that we have a > layering problem in our design. > I don't think SIP and HTTP are comparable at all in this respect. In HTTP you directly address the server that you like to get (post, delete, update) information from. In SIP you adress the URI of a user, that will lead you to the home proxy in most cases and which is then forwarded to the UAS by overwriting the Request URI. No layering problem, just a flaw in SIP's design that causes usefull information to be destroyed for no good reason. We're just trying to fix that, no more no less. > From one perspective, this makes the application invocation implicit; > the UAS has to guess what to do based on clues sprinkled throughout > the communication and across several layers of the ISO stack. It's > much better to have this sort of determination made based on explicit > indicators at a single application layer. > No. The goal of the target-uri discussion is to have all the relevant target-uri information readily available in the SIP request received by the UAS. That is all on the same OSI layer, layer 7. /Hans Erik From adam@nostrum.com Thu Apr 30 14:03:19 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 808F83A6885 for ; Thu, 30 Apr 2009 14:03:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.573 X-Spam-Level: X-Spam-Status: No, score=-2.573 tagged_above=-999 required=5 tests=[AWL=0.027, BAYES_00=-2.599, SPF_PASS=-0.001] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3-VaxFUjhUzT for ; Thu, 30 Apr 2009 14:03:18 -0700 (PDT) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id 656093A6767 for ; Thu, 30 Apr 2009 14:03:18 -0700 (PDT) Received: from [172.16.3.231] (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id n3UL4dtZ042512 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 30 Apr 2009 16:04:39 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <49FA1267.5040204@nostrum.com> Date: Thu, 30 Apr 2009 16:04:39 -0500 From: Adam Roach User-Agent: Postbox 1.0b11 (Macintosh/2009041623) MIME-Version: 1.0 To: SIPCORE , draft-niemi-sipping-event-throttle@tools.ietf.org, draft-holmberg-sipcore-keep@tools.ietf.org Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Subject: [sipcore] Document Adoption X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Apr 2009 21:03:19 -0000 [as chair] This message announces the formal adoption of two additional documents as SIPCORE working group items to satisfy two of our chartered milestones. Two weeks ago, the document draft-niemi-sipping-event-throttle, which was accepted by the RAI community at the San Franciso SIPPING meeting, was proposed by the chairs as a candidate to satisfy the milestone "SIP Events throttling mechanism"[1]. There was one affirmation of this decision. There was one objection, which was withdrawn after the question under consideration was clarified[2]. Given the "previously adopted" status of this document, and the lack of any remaining objections, the chairs now consider this a working group document. We also had eight positive responses and no objections to adopting draft-holmberg-sipcore-keep as a working group item [3] to satisfy the milestone "Mechanism for indicating support for keep-alives". Authors: please submit a draft-ietf-sipcore version of your document as soon as practical. Also, please keep in mind that change control now resides with the working group -- you are advised to make no substantive changes without discussion on the working group mailing list. Thanks! /a -- [1] http://www.ietf.org/mail-archive/web/sipcore/current/msg00005.html [2] http://www.ietf.org/mail-archive/web/sipcore/current/msg00019.html [3] http://www.ietf.org/mail-archive/web/sipcore/current/msg00021.html From pkyzivat@cisco.com Thu Apr 30 16:22:04 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3F64D3A6ED9 for ; Thu, 30 Apr 2009 16:22:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.096 X-Spam-Level: X-Spam-Status: No, score=-6.096 tagged_above=-999 required=5 tests=[AWL=0.503, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MZOe44tnBJwk for ; Thu, 30 Apr 2009 16:22:01 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 52BBD3A63D3 for ; Thu, 30 Apr 2009 16:22:01 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.40,275,1238976000"; d="scan'208";a="158167324" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by sj-iport-3.cisco.com with ESMTP; 30 Apr 2009 23:23:24 +0000 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n3UNNOv2017789; Thu, 30 Apr 2009 19:23:24 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.13.8/8.13.8) with ESMTP id n3UNNNgV007228; Thu, 30 Apr 2009 23:23:24 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 30 Apr 2009 19:23:24 -0400 Received: from [161.44.174.156] ([161.44.174.156]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 30 Apr 2009 19:23:23 -0400 Message-ID: <49FA32E9.3070509@cisco.com> Date: Thu, 30 Apr 2009 19:23:21 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) MIME-Version: 1.0 To: Hans Erik van Elburg References: <0D5F89FAC29E2C41B98A6A762007F5D001D4A39A@GBNTHT12009MSX.gb002.siemens.net><49F5B3FE.8030104@cisco.com><28B7C3AA2A7ABA4A841F11217ABE78D67590BF97@FRMRSSXCHMBSB3.dc-m.alcatel-lucent.com> <49F5C2C4.70501@cisco.com> <49F71501.2020300@cisco.com> <49F742EE.30504@softarmor.com> <49F75022.4010905@cisco.com> <6B78E793-0C48-427E-8895-337D5F592957@softarmor.com> <7C450C3A-33F9-450D-B424-4DCD86D5D99A@softarmor.com> <49F9BE92.1050601@gmail.com> In-Reply-To: <49F9BE92.1050601@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 30 Apr 2009 23:23:23.0568 (UTC) FILETIME=[A80C5300:01C9C9EA] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2681; t=1241133804; x=1241997804; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[sipcore]=20Question=20on=20Require=20i n=20responses |Sender:=20 |To:=20Hans=20Erik=20van=20Elburg=20; bh=9zEZiMc1OQxBo4UfOQRd+D2v/hovo8kgmCgdpMnxpJc=; b=kkpblJF7Cn0duiaVyPuLKOSn70JFAPf7rVmnyW4slS1vLu3QVOrRsRWWI4 39x5IZwZaddBlXVNApyRhxzxHbJC2oGsu3b0leGuWrAW4/Ibh4P9XmNxCxLm V84XqyXft+; Authentication-Results: rtp-dkim-2; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Cc: SIPCORE Subject: Re: [sipcore] Question on Require in responses X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 30 Apr 2009 23:22:04 -0000 Hans Erik van Elburg wrote: > > Dean Willis wrote: >> The option tag is a means of 1) discovering whether or not the far-end >> supports a specific extension and of 2) declaring the criticality of >> understanding that extension relative to satisfying a request and 3) >> informing the UAC of what extensions were applied to the request in >> order to generate the response. This is purely a function of >> capability negotiation, not one of invocation. >> >> The extension itself (typically, an extension header field, although >> there are other types of extensions) is what causes the extension to >> be invoked. > Depends a bit how you define extension, but I would argue that if I > require an extension to be supported on a transaction/dialog by the UAS > and the UAS accepts the request that this means that for this call the > UAS behaves as it should according to the extensions specification. There are several issues in what you say above: "if I require an extension to be supported on a transaction/*dialog* by the UAS" supported for a transaction, and supported for a dialog are two very different things. We certainly don't have a way to say whether you want one or the other. These headers were derived from http, and there they really only apply for one transaction. Nominally that is all they mean for sip too. In practice, particular features really have a broader scope than that, but there is little/no formality about that. "if... and the UAS accepts the request that means that *for this call* the UAS behaves as it should according to the extensions specification" There you have assumed that the scope is, depending on your terminology, - the call - the session - the dialog - the dialog usage But in general you cannot assume that. The support may cease on the next transaction, explicitly or implicitly. It is far from clear that support, or requirements to support, continue if not restated in every transaction. Nor is there any guarantee that support, if indicated in the response to a transaction, will continue even momentarily before the next transaction. And of course there is no guarantee that features that are indicated as supported in response to an OPTIONS will continue to be supported when a call is made to the same address. Thanks, Paul > Saying that an extensions invokes itself is meaningless to me. > > A UAS may choose to only invoke the extension behaviour if it finds that > the extension is required. That comes close to saying that the > require:extension invokes the behaviour in the UAS, but it is not at all > the same. From dean.willis@softarmor.com Thu Apr 30 18:29:34 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E54A73A69E2 for ; Thu, 30 Apr 2009 18:29:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 15kuf3EoM4LA for ; Thu, 30 Apr 2009 18:29:34 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id E8F213A6808 for ; Thu, 30 Apr 2009 18:29:33 -0700 (PDT) Received: from [10.10.10.192] (pool-173-71-53-112.dllstx.fios.verizon.net [173.71.53.112]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id n411UrwI027794 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 30 Apr 2009 20:30:55 -0500 Message-ID: <49FA50CD.1080406@softarmor.com> Date: Thu, 30 Apr 2009 20:30:53 -0500 From: Dean Willis User-Agent: Thunderbird 2.0.0.21 (X11/20090409) MIME-Version: 1.0 To: Hans Erik van Elburg References: <49F178CE.8000809@ericsson.com> <0ECC036E-2B21-49D5-AC42-1FEC8EC447BE@softarmor.com> <49F5D64B.20008@nostrum.com> <193E3797-2C8D-44EB-A869-DDDE39B303D9@nostrum.com> <06F3B3D8-BEA3-4B5A-990D-B9E8DCAB1FF1@softarmor.com> <49F9718E.4070707@gmail.com> <9A564A10-3F22-471A-832B-28117412AD93@softarmor.com> <49F9F343.6090901@gmail.com> In-Reply-To: <49F9F343.6090901@gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: SIPCORE Subject: Re: [sipcore] Long reply to: Target URI and History Info bis X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 May 2009 01:29:35 -0000 Hans Erik van Elburg wrote: > > > Dean Willis wrote: >> >> On Apr 30, 2009, at 4:38 AM, Hans Erik van Elburg wrote: >> >>> Overloading in general is not a good design strategy, why do you >>> think that trying to mold everything (diversion/history info) into >>> Request URI is a good idea?? >> >> The reason that we're having this conversation is that we have >> proposals, History-Info being one, for 1) putting our parameters in to >> the original request-URI, and 2) recovering that original request-URI >> after it has been contact-routed (and otherwise mangled) so that the >> parameters can be used at the UAS. >> >> So the presumption exists that the original request URI is useful to >> the UAS. SIP did, and now SIPCORE has, a chartered item for making >> that happen. >> >> I'm trying to back up and make sure that we know WHY we're trying to >> deliver the original request URI to the UAS, and then asking if some >> other approach that meets the same requirements might actually be >> easier to do. >> > That is fine of course, but the point is that we are not talking about > delivering parameters to an application, but about recovering a complete > URI that has gone lost on the way. but why exactly do we need to recover the URI? What is it that is special about the URI or is likely to get used in some useful sort of way downstream? If it isn't the "Request URI-ness" that is important, maybe we can find some more convenient way to deliver that information. >>> The problem here is that this information has nothing to do with >>> application invocation, but tells something about how the signalling >>> reached the callee (target). And this information is only relevant to >>> the callee if that decides that it is. >> >> >> That's a profound philosophical assertion. HTTP, for example, makes no >> consideration for "how the signaling reaches the target" in >> determining how to process a request. The fact that some think SIP >> should take this into consideration indicates to me that we have a >> layering problem in our design. >> > I don't think SIP and HTTP are comparable at all in this respect. In > HTTP you directly address the server that you like to get (post, delete, > update) information from. In SIP you adress the URI of a user, that will > lead you to the home proxy in most cases and which is then forwarded to > the UAS by overwriting the Request URI. Well, HTTP has proxies too, and SIP were originally intended to be comparable. '> No layering problem, just a flaw in SIP's design that causes usefull > information to be destroyed for no good reason. We're just trying to fix > that, no more no less. >> From one perspective, this makes the application invocation implicit; >> the UAS has to guess what to do based on clues sprinkled throughout >> the communication and across several layers of the ISO stack. It's >> much better to have this sort of determination made based on explicit >> indicators at a single application layer. >> > No. The goal of the target-uri discussion is to have all the relevant > target-uri information readily available in the SIP request received by > the UAS. That is all on the same OSI layer, layer 7. > I disgaree -- the goal is to make the information that was encoded into the requestURI (and maybe as modified by intermediates, that use case is open) available to the UAS. -- dean From SBharrat@sonusnet.com Thu Apr 30 19:20:27 2009 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 959D63A68DE for ; Thu, 30 Apr 2009 19:20:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XfiyUL5g89CB for ; Thu, 30 Apr 2009 19:20:26 -0700 (PDT) Received: from mail-ma01.sonusnet.com (sonussf2.sonusnet.com [208.45.178.27]) by core3.amsl.com (Postfix) with ESMTP id 426CF3A6A96 for ; Thu, 30 Apr 2009 19:20:26 -0700 (PDT) Received: from sonusmail05.sonusnet.com (sonusmail05.sonusnet.com [10.128.32.155]) by sonuspps2.sonusnet.com (8.14.3/8.14.3) with ESMTP id n412Ll4f013163; Thu, 30 Apr 2009 22:21:47 -0400 x-mimeole: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 30 Apr 2009 22:21:51 -0400 Message-ID: <637C77B6763BB54ABF989B6B21D5323502981F99@sonusmail05.sonusnet.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Draft new version: draft-holmberg-sipcore-keep-00 (previouslyknown as draft-holmberg-sip-keep) Thread-Index: Acm+bcAszQkyqV++Ts+HPG29TfGFgALlQSop References: From: "Bharrat, Shaun" To: "Christer Holmberg" , Subject: Re: [sipcore] [Sip] Draft new version: draft-holmberg-sipcore-keep-00 (previouslyknown as draft-holmberg-sip-keep) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 May 2009 02:20:27 -0000 > When a UAS that supports the method defined in this specification recieves an initial SIP request which contains a "keep" parameter in the topmost Via header, and the UAS wants to allow the sender of the initial SIP request to send keep-alives towards the UAS during the duration of the call, the UAS proxy MUST add a "yes" value to the "keep" parameter. In addition the UAS MAY include a Flow-Timer header field if the associated initial SIP response. Which response is this text referring to when this is for a call? Does this include the 100 trying? If in the 100 trying, does the keep need to be in all responses to the INVITE? WHat about the = Flow-Timer? The reason I'm asking is that 100 trying is often generated at a very different place than the other responses. It may or may not be feasible to provide the relevant information in that response. I'm trying to understand the intent... Thanks and cheers, Shaun -----Original Message----- From: sip-bounces@ietf.org on behalf of Christer Holmberg Sent: Thu 4/16/2009 4:31 AM To: sipcore@ietf.org; sip@ietf.org Cc: Adam Roach; Gonzalo Camarillo; Mary Barnes Subject: [Sip] Draft new version: draft-holmberg-sipcore-keep-00 = (previouslyknown as draft-holmberg-sip-keep) =20 Hi, I've submitted a draft-holmberg-sipcore version of the keep draft. The draft is identical to the previous version (for which Mary sent out the ask-for-support e-mail), but I have added one more example. The draft can also be found at: http://users.piuha.net/cholmber/drafts/draft-holmberg-sipcore-keep-00.tx t Regards, Christer Ps. I applogize for sending this e-mail to both SIP and SIPCORE, but since everyone may not have subscribed to SIPCORE yet...