From christer.holmberg@ericsson.com Tue Feb 1 08:56:21 2011 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 482183A6BFF for ; Tue, 1 Feb 2011 08:56:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.471 X-Spam-Level: X-Spam-Status: No, score=-6.471 tagged_above=-999 required=5 tests=[AWL=0.128, 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 9FrhZTqkJFYA for ; Tue, 1 Feb 2011 08:56:20 -0800 (PST) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id 268DA3A6E33 for ; Tue, 1 Feb 2011 08:56:08 -0800 (PST) X-AuditID: c1b4fb39-b7cfbae000005c8e-59-4d483bed4a6e Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 2D.6C.23694.DEB384D4; Tue, 1 Feb 2011 17:59:25 +0100 (CET) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.59]) by esessmw0247.eemea.ericsson.se ([10.2.3.116]) with mapi; Tue, 1 Feb 2011 17:59:25 +0100 From: Christer Holmberg To: "sipcore@ietf.org" Date: Tue, 1 Feb 2011 17:59:24 +0100 Thread-Topic: Draft new version: draft-ietf-sipcore-199-05 Thread-Index: AQHLwjFhueCWJUNw6k+W0KCG1OxLGw== Message-ID: <7F2072F1E0DE894DA4B517B93C6A0585194414F74D@ESESSCMS0356.eemea.ericsson.se> 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-Brightmail-Tracker: AAAAAA== Subject: [sipcore] Draft new version: draft-ietf-sipcore-199-05 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, 01 Feb 2011 16:56:21 -0000 Hi, Based on editorial comments from John E and Paul K, I've submitted a new ve= rsion (-05) of the 199 draft. The major change is that previous section 9 has been removed, as it only re= peated text already present elsewhere. Regards, Christer From Internet-Drafts@ietf.org Tue Feb 1 09:00:03 2011 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 3414B3A6959; Tue, 1 Feb 2011 09:00:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.513 X-Spam-Level: X-Spam-Status: No, score=-102.513 tagged_above=-999 required=5 tests=[AWL=0.086, BAYES_00=-2.599, 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 1LLEBBGOdNsi; Tue, 1 Feb 2011 09:00:02 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 379E33A6BFF; Tue, 1 Feb 2011 09:00:02 -0800 (PST) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.11 Message-ID: <20110201170002.8956.25062.idtracker@localhost> Date: Tue, 01 Feb 2011 09:00:02 -0800 Cc: sipcore@ietf.org Subject: [sipcore] I-D Action:draft-ietf-sipcore-199-05.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, 01 Feb 2011 17:00:03 -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 : Session Initiation Protocol (SIP) Response Code for Indication of Terminated Dialog Author(s) : C. Holmberg Filename : draft-ietf-sipcore-199-05.txt Pages : 16 Date : 2011-02-01 This specification defines a new Session Initiation Protocol (SIP) response code, 199 Early Dialog Terminated, that a SIP forking proxy and a User Agent Server (UAS) can use to indicate towards upstream SIP entities (including the User Agent Client (UAC)) that an early dialog has been terminated, before a final response is sent towards the SIP entities. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sipcore-199-05.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-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-02-01085402.I-D@ietf.org> --NextPart-- From adam@nostrum.com Tue Feb 1 16:31:22 2011 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 CE5003A6CA3 for ; Tue, 1 Feb 2011 16:31:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -90.491 X-Spam-Level: X-Spam-Status: No, score=-90.491 tagged_above=-999 required=5 tests=[AWL=-12.192, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_12=0.6, J_CHICKENPOX_38=0.6, J_CHICKENPOX_72=0.6, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, SPF_PASS=-0.001, URIBL_BLACK=20, 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 U42tPBcF5TRL for ; Tue, 1 Feb 2011 16:31:20 -0800 (PST) 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 53EC63A7019 for ; Tue, 1 Feb 2011 16:30:54 -0800 (PST) Received: from hydra-3.local (99-152-144-32.lightspeed.dllstx.sbcglobal.net [99.152.144.32]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id p120Y9ci009129 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Tue, 1 Feb 2011 18:34:11 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <4D48A681.9080803@nostrum.com> Date: Tue, 01 Feb 2011 18:34:09 -0600 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: SIPCORE Content-Type: multipart/alternative; boundary="------------060209030909090905020703" Received-SPF: pass (nostrum.com: 99.152.144.32 is authenticated by a trusted mechanism) Subject: [sipcore] Proposed location conveyance changes 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, 02 Feb 2011 00:31:22 -0000 This is a multi-part message in MIME format. --------------060209030909090905020703 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit [as chair] As a follow up from last-week's ad-hoc call on the topic of location conveyance, the authors have proposed the following technical changes (along with several editorial changes). Please review and comment as soon as possible. If there are no objections, the document will updated accordingly on or after Thursday of this week. Full proposed diffs can be viewed at http://ln-s.net/8T6P and http://ln-s.net/8T6Q In section 3.2: *The example given in this section is only illustrative, not normative. In particular, applications can choose to dereference a location URI at any time, possibly several times, or potentially not at all. Applications receiving a Location URI in a SIP transaction need to be mindful of SIP's transaction timers. In particular, if the means of dereferencing the Location URI might take longer than the SIP transaction timeout (Timer C for INVITE transactions, Timer F for non-INVITE transactions), then it needs to rely on mechanisms other than the transaction's response code to convey location errors, if returning such errors are necessary.* In section 4.3: * A SIP intermediary that requires Alice's location in order to properly process Alice's INVITE also sends a 424 with a Geolocation-Error code. This message flow is shown in Figure 4 of Section 3.4. If more than one locationValue is present in the SIP request and determined to be valid by the LR, the location in that SIP request MUST be considered good as far as location is concerned, and no Geolocation-Error is sent. This is a compromise of complexity vs. accurate information conveyance with respect to informing each location inserter of every bad location. We have gone through the exercise of getting this correct for every scenario, and deemed it not worth the excruciating effort involved. Here is an initial list of location based error ranges for any SIP* non-100 response, including the new 424 (Bad Location Information) response. These error codes are divided into 4 categories, based on how the response receiver should react to these errors.*There can only be one Geolocation-Error code in a SIP response, regardless of how many locationValues there are in the correlating SIP request. There is no guidance given in this document as to which locationValue is formally errored (when more than one was present); meaning that, somehow not defined here, the LR just picks one to error.* o 1XX errors mean the LR cannot process the location within the request. o 2XX errors mean the LR wants *request A non-exclusive list of reasons for returning a 1XX is -* theLS to send new *location was not present* orupdated *could not be found, - there was not enough* locationinformation, perhaps with a delay associated with when *information* tosend *determine where* therequest. *Target was, - the location information was corrupted or known to be inaccurate, - etc...* o3XX *2XX* errors mean some specific permission is necessary to process the included location information. o4XX *3XX* errors mean there was trouble dereferencing the Location URI sent. *It should be noted that for non-INVITE transactions, the SIP response will likely be sent before the dereference response has been received. At this time, this document does not alter that SIP protocol reality. This means that any non-INVITE response to a request containing location SHOULD NOT consider a 200 OK to mean the act of dereferencing has concluded and the dereferencer (i.e., the LR) has successfully parsed the PIDF-LO for errors and found none. This was first brought up in Section 3.2. Additionally, if a SIP entity cannot or chooses not to process location or the SIP request containing location, the existing mechanism of responding with a 503 (Service Unavailable) SHOULD be used with or without a configurable Retry-After header field. There is no special location error code for what already exists within SIP today.* Within these4 *3* number ranges, there is a top level error as follows: Geolocation-Error: 100 "Cannot Process Location" Geolocation-Error: 200"Retry Location Later with device updated location" Geolocation-Error: 300 "Permission To Use Location Information" Geolocation-Error:400 *300* "Dereference Failure" There are two specific Geolocation-Error codes necessary to include in this document, both have to do with permissions necessary to process the SIP request; they are Geolocation-Error:301 *201* "Permission To Retransmit Location Information to a Third Party" This location error is specific to having the Presence Information Data Format (PIDF-LO) [RFC4119] element set to "=no". This location error is stating it requires permission (i.e., PIDF-LO element set to "=yes") to process this SIP request further. If the LS sending the location information does not want to give this permission, it will not reset this permission in a new request. If the LS wants this message processed without this permission reset, it MUST choose another logical path (if oneexists). *exists) for this SIP request.* Geolocation-Error:302 *202* "Permission to Route based on Location Information" This location error is specific to having the locationValue header parameter set to "=no". This location error is stating it requires permission (i.e., a set to "=yes") to process this SIP request further. If the LS sending the location information does not want to give this permission, it will not reset this permission in a new request. If the LS wants this message processed without this permission reset, it MUST choose another logical path (if oneexists). *exists) for this SIP request.* New section 4.5 (previously 4.6): *4.5* LocationURIs Allowed *Profile Negotiation* The following is part of the discussion started in Section 3, Figure 2, which introduced the concept of sending location indirectly. If a location URI is included in a SIP request,it SHOULD be *the sending user agent MUST also include* aSIP-, SIPS- or PRES-URI. When PRES: is used, as *Supported header field indicating which location profiles it supports. Two option tags for location profiles are* defined*by this document: "geolocation-sip" and "geolocation-http". Future specifications may define further location profiles per the IANA policy described* in[RFC3856], if *Section 8.2. The "geolocation-sip" option tag signals support for acquiring location information via* the*presence event package of SIP ([RFC3856]). A location recipient who supports this option can send a SUBSCRIBE request and parse a* resultingresolution resolves to *NOTIFY containing* aSIP: or SIPS: URI, *PIDF-LO object. The URI schemes supported by* this section applies. These *option include "sip", "sips" and "pres". The "geolocation-http" option tag signals support for acquiring location information via an HTTP ([RFC2616]). A location recipient who supports this option can request location with an HTTP GET and parse a resulting 200 response containing a PIDF-LO object. The URI* schemesMUST be implemented according to *supported by* thisdocument. *option include "http" and "https". A failure to parse the 200 response, for whatever reason, will return a "Dereference Failure" indication to the original location sending user agent to inform it that location was not delivered as intended.* See[ID-GEO-FILTERS] *(ID-GEO-FILTERS)* for more details on dereferencinglocation. An HTTP: [RFC2616] or HTTPS: URI [RFC2818] are also allowed, and SHOULD be dereferenced according to [ID-HELD-DEREF]. *location information.* Change in IANA registration: Code Description Reference ---- --------------------------------------------------- --------- 100 "Cannot Process Location" [this doc] 200"Retry Location Later with device updated location" [this doc] 300 "Permission To Use Location Information" [this doc] 301 *201* "Permission To Retransmit Location Information to a Third Party" [this doc] 302 *202* "Permission to Route based on Location Information" [this doc] 400 *300* "Dereference Failure" [this doc] 8.6 IANA Registration of Location URI Schemes This document directs IANA to create a new set of parameters in a separate location from SIP and Geopriv, called the "Location Reference URI" registry, containing the URI scheme, the Content-Type, and the reference, as follows: URI Scheme Content-Type Reference ---------- ------------ --------- SIP: [this doc] SIPS: [this doc] PRES: [this doc] HTTP: [this doc] HTTPS: [this doc] Additions to this registry must be defined in a permanent and readily available specification (this is the "Specification Required" IANA policy defined in [RFC5226]). /a --------------060209030909090905020703 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit [as chair]

As a follow up from last-week's ad-hoc call on the topic of location conveyance, the authors have proposed the following technical changes (along with several editorial changes). Please review and comment as soon as possible. If there are no objections, the document will updated accordingly on or after Thursday of this week.

Full proposed diffs can be viewed at http://ln-s.net/8T6P and http://ln-s.net/8T6Q


In section 3.2:

   The example given in this section is only illustrative, not
   normative. In particular, applications can choose to dereference a
   location URI at any time, possibly several times, or potentially not
   at all. Applications receiving a Location URI in a SIP transaction
   need to be mindful of SIP's transaction timers. In particular, if
   the means of dereferencing the Location URI might take longer than
   the SIP transaction timeout (Timer C for INVITE transactions, Timer
   F for non-INVITE transactions), then it needs to rely on mechanisms
   other than the transaction's response code to convey location
   errors, if returning such errors are necessary.

In section 4.3:

   A SIP intermediary that requires Alice's location in order to
   properly process Alice's INVITE also sends a 424 with a
   Geolocation-Error code. This message flow is shown in Figure 4 of
   Section 3.4.

   If more than one locationValue is present in the SIP request and
   determined to be valid by the LR, the location in that SIP request
   MUST be considered good as far as location is concerned, and no
   Geolocation-Error is sent. This is a compromise of complexity vs.
   accurate information conveyance with respect to informing each
   location inserter of every bad location. We have gone through the
   exercise of getting this correct for every scenario, and deemed it
   not worth the excruciating effort involved.

   Here is an initial list of location based error ranges for any SIP
   non-100 response, including the new 424  (Bad Location Information)
   response.  These error codes are divided into 4 categories, based on
   how the response receiver should react to these errors.  There can
   only be one Geolocation-Error code in a SIP response, regardless of
   how many locationValues there are in the correlating SIP request.
   There is no guidance given in this document as to which
   locationValue is formally errored (when more than one was present);
   meaning that, somehow not defined here, the LR just picks one to
   error.

   o  1XX errors mean the LR cannot process the location within the
      request.

   o  2XX errors mean the LR wants
      request

      A non-exclusive list of reasons for returning a 1XX is

      - the LS to send new location was not present or updated could not be found,
      - there was not enough location information, perhaps with a delay associated with when information to send determine
        where the request. Target was,
      - the location information was corrupted or known to be
        inaccurate,
      - etc...

   o  3XX  2XX errors mean some specific permission is necessary to process
      the included location information.

   o  4XX  3XX errors mean there was trouble dereferencing the Location URI
      sent.

   It should be noted that for non-INVITE transactions, the SIP
   response will likely be sent before the dereference response has
   been received. At this time, this document does not alter that SIP
   protocol reality. This means that any non-INVITE response to a
   request containing location SHOULD NOT consider a 200 OK to mean the
   act of dereferencing has concluded and the dereferencer (i.e., the
   LR) has successfully parsed the PIDF-LO for errors and found none.
   This was first brought up in Section 3.2.

   Additionally, if a SIP entity cannot or chooses not to process
   location or the SIP request containing location, the existing
   mechanism of responding with a 503 (Service Unavailable) SHOULD be
   used with or without a configurable Retry-After header field. There
   is no special location error code for what already exists within SIP
   today.

   Within these 4 3 number ranges, there is a top level error as follows:

   Geolocation-Error: 100 "Cannot Process Location"

   Geolocation-Error: 200 "Retry Location Later with device updated
                           location"

   Geolocation-Error: 300 "Permission To Use Location Information"

   Geolocation-Error: 400 300 "Dereference Failure"

   There are two specific Geolocation-Error codes necessary to include
   in this document, both have to do with permissions necessary to
   process the SIP request; they are

   Geolocation-Error: 301 201 "Permission To Retransmit Location
                           Information to a Third Party"

   This location error is specific to having the Presence Information
   Data Format (PIDF-LO) [RFC4119] <retransmission-allowed> element set
   to "=no". This location error is stating it requires permission
   (i.e., PIDF-LO <retransmission-allowed> element set to "=yes") to
   process this SIP request further.  If the LS sending the location
   information does not want to give this permission, it will not reset
   this permission in a new request. If the LS wants this message
   processed without this permission reset, it MUST choose another
   logical path (if one exists). exists) for this SIP request.

   Geolocation-Error: 302 202 "Permission to Route based on Location
                           Information"

   This location error is specific to having the locationValue header
   parameter <routing-allowed> set to "=no". This location error is
   stating it requires permission (i.e., a <routing-allowed> set to
   "=yes") to process this SIP request further.  If the LS sending the
   location information does not want to give this permission, it will
   not reset this permission in a new request. If the LS wants this
   message processed without this permission reset, it MUST choose
   another logical path (if one exists). exists) for this SIP request.
New section 4.5 (previously 4.6):

4.5 Location URIs Allowed Profile Negotiation

   The following is part of the discussion started in Section 3, Figure
   2, which introduced the concept of sending location indirectly.

   If a location URI is included in a SIP request, it SHOULD be the sending user
   agent MUST also include a SIP-,
   SIPS- or PRES-URI.  When PRES: is used, as Supported header field indicating which
   location profiles it supports. Two option tags for location profiles
   are defined by this document: "geolocation-sip" and
   "geolocation-http". Future specifications may define further
   location profiles per the IANA policy described in [RFC3856], if Section 8.2.

   The "geolocation-sip" option tag signals support for acquiring
   location information via the presence event package of SIP
   ([RFC3856]). A location recipient who supports this option can send
   a SUBSCRIBE request and parse a resulting resolution resolves to NOTIFY containing a SIP: or SIPS: URI,
   PIDF-LO object. The URI schemes supported by this
   section applies.  These option include
   "sip", "sips" and "pres".

   The "geolocation-http" option tag signals support for acquiring
   location information via an HTTP ([RFC2616]). A location recipient
   who supports this option can request location with an HTTP GET and
   parse a resulting 200 response containing a PIDF-LO object. The URI
   schemes MUST be implemented according to supported by this document. option include "http" and "https". A
   failure to parse the 200 response, for whatever reason, will return
   a "Dereference Failure" indication to the original location sending
   user agent to inform it that location was not delivered as intended.

   See [ID-GEO-FILTERS] (ID-GEO-FILTERS) for more details on dereferencing location.

   An HTTP: [RFC2616] or HTTPS: URI [RFC2818] are also allowed, and
   SHOULD be dereferenced according to [ID-HELD-DEREF]. location
   information.
Change in IANA registration:

  Code Description                                          Reference
  ---- ---------------------------------------------------  ---------
  100  "Cannot Process Location"                            [this doc]

  200  "Retry Location Later with device updated location"  [this doc]

  300  "Permission To Use Location Information"             [this doc]

  301

  201  "Permission To Retransmit Location Information to a Third Party"
                                                            [this doc]

  302

  202  "Permission to Route based on Location Information"  [this doc]

  400

  300  "Dereference Failure"                                [this doc]

8.6  IANA Registration of Location URI Schemes

   This document directs IANA to create a new set of parameters in a
   separate location from SIP and Geopriv, called the "Location
   Reference URI" registry, containing the URI scheme, the
   Content-Type, and the reference, as follows:

   URI Scheme   Content-Type           Reference
   ----------   ------------           ---------
      SIP:                             [this doc]
      SIPS:                            [this doc]
      PRES:                            [this doc]
      HTTP:                            [this doc]
      HTTPS:                           [this doc]

   Additions to this registry must be defined in a permanent and
   readily available specification (this is the "Specification
   Required" IANA policy defined in [RFC5226]).


/a
--------------060209030909090905020703-- From john.elwell@siemens-enterprise.com Wed Feb 2 09:50:43 2011 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 041113A6D2C for ; Wed, 2 Feb 2011 09:50:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -91.286 X-Spam-Level: X-Spam-Status: No, score=-91.286 tagged_above=-999 required=5 tests=[AWL=-11.187, BAYES_00=-2.599, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, URIBL_BLACK=20, 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 NTY4U5qLeago for ; Wed, 2 Feb 2011 09:50:41 -0800 (PST) Received: from ms03.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id BB7893A6CE7 for ; Wed, 2 Feb 2011 09:50:40 -0800 (PST) Received: from senmx11-mx ([62.134.46.9] [62.134.46.9]) by ms03.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-3241145; Wed, 2 Feb 2011 18:53:53 +0100 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx11-mx (Server) with ESMTP id 35BB41EB82AB; Wed, 2 Feb 2011 18:53:53 +0100 (CET) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Wed, 2 Feb 2011 18:53:53 +0100 From: "Elwell, John" To: Adam Roach , SIPCORE Date: Wed, 2 Feb 2011 18:53:51 +0100 Thread-Topic: [sipcore] Proposed location conveyance changes Thread-Index: AcvCcQAGqPQOZ+FZS1eEAOZrqNp2vAAj23Dw Message-ID: References: <4D48A681.9080803@nostrum.com> In-Reply-To: <4D48A681.9080803@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 Subject: Re: [sipcore] Proposed location conveyance changes 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, 02 Feb 2011 17:50:43 -0000 This seems to reflect what was discussed. A few points: 1. "If more than one locationValue is present in the SIP request and determined to be valid by the LR, the location in that SIP request MUST be considered good as far as location is concerned, and no Geolocation-Error is sent." Should this say: "If more than one locationValue is present in the SIP request and >>at least one location/Value is<< determined to be valid by the LR, the= location in that SIP request MUST be considered good as far as location is concerned, and no Geolocation-Error is sent." ? 2. "We have gone through the exercise of getting this correct for every scenario, and deemed it not worth the excruciating effort involved." This may be true, but do we really want this in the final document? 3. "These error codes are divided into 4 categories" I only see 3. 4. "... any non-INVITE response to a request containing location SHOULD NOT consider a 200 OK to mean ..." Is a response able to consider? Presumably the subject be the recipient of = such a response. 5. "Within these 4 3 number ranges, there is a top level error as follows:" Should this say "Within each of these..."? John > -----Original Message----- > From: sipcore-bounces@ietf.org=20 > [mailto:sipcore-bounces@ietf.org] On Behalf Of Adam Roach > Sent: 02 February 2011 00:34 > To: SIPCORE > Subject: [sipcore] Proposed location conveyance changes >=20 > [as chair] >=20 > As a follow up from last-week's ad-hoc call on the topic of=20 > location conveyance, the authors have proposed the following=20 > technical changes (along with several editorial changes).=20 > Please review and comment as soon as possible. If there are=20 > no objections, the document will updated accordingly on or=20 > after Thursday of this week. >=20 > Full proposed diffs can be viewed at http://ln-s.net/8T6P and=20 > http://ln-s.net/8T6Q >=20 >=20 > In section 3.2: >=20 >=20 > The example given in this section is only illustrative, not > normative. In particular, applications can choose to dereference a > location URI at any time, possibly several times, or=20 > potentially not > at all. Applications receiving a Location URI in a SIP transaction > need to be mindful of SIP's transaction timers. In particular, if > the means of dereferencing the Location URI might take longer than > the SIP transaction timeout (Timer C for INVITE transactions, Timer > F for non-INVITE transactions), then it needs to rely on mechanisms > other than the transaction's response code to convey location > errors, if returning such errors are necessary. >=20 > In section 4.3: >=20 >=20 > A SIP intermediary that requires Alice's location in order to > properly process Alice's INVITE also sends a 424 with a > Geolocation-Error code. This message flow is shown in Figure 4 of > Section 3.4. >=20 > If more than one locationValue is present in the SIP request and > determined to be valid by the LR, the location in that SIP request > MUST be considered good as far as location is concerned, and no > Geolocation-Error is sent. This is a compromise of complexity vs. > accurate information conveyance with respect to informing each > location inserter of every bad location. We have gone through the > exercise of getting this correct for every scenario, and deemed it > not worth the excruciating effort involved. >=20 > Here is an initial list of location based error ranges for any SIP > non-100 response, including the new 424 (Bad Location Information) > response. These error codes are divided into 4=20 > categories, based on > how the response receiver should react to these errors. There can > only be one Geolocation-Error code in a SIP response, regardless of > how many locationValues there are in the correlating SIP request. > There is no guidance given in this document as to which > locationValue is formally errored (when more than one was present); > meaning that, somehow not defined here, the LR just picks one to > error. >=20 > o 1XX errors mean the LR cannot process the location within the > request. >=20 > o 2XX errors mean the LR wants > request >=20 > A non-exclusive list of reasons for returning a 1XX is >=20 > - the LS to send new location was not present or=20 > updated could not be found, > - there was not enough location information, perhaps=20 > with a delay associated with when information to send determine > where the request. Target was, > - the location information was corrupted or known to be > inaccurate, > - etc... >=20 > o 3XX 2XX errors mean some specific permission is=20 > necessary to process > the included location information. >=20 > o 4XX 3XX errors mean there was trouble dereferencing=20 > the Location URI > sent. >=20 > It should be noted that for non-INVITE transactions, the SIP > response will likely be sent before the dereference response has > been received. At this time, this document does not alter that SIP > protocol reality. This means that any non-INVITE response to a > request containing location SHOULD NOT consider a 200 OK=20 > to mean the > act of dereferencing has concluded and the dereferencer (i.e., the > LR) has successfully parsed the PIDF-LO for errors and found none. > This was first brought up in Section 3.2. >=20 > Additionally, if a SIP entity cannot or chooses not to process > location or the SIP request containing location, the existing > mechanism of responding with a 503 (Service Unavailable) SHOULD be > used with or without a configurable Retry-After header field. There > is no special location error code for what already exists=20 > within SIP > today. >=20 > Within these 4 3 number ranges, there is a top level error=20 > as follows: >=20 > Geolocation-Error: 100 "Cannot Process Location" >=20 > Geolocation-Error: 200 "Retry Location Later with device updated > location" >=20 > Geolocation-Error: 300 "Permission To Use Location Information" >=20 > Geolocation-Error: 400 300 "Dereference Failure" >=20 > There are two specific Geolocation-Error codes necessary to include > in this document, both have to do with permissions necessary to > process the SIP request; they are >=20 > Geolocation-Error: 301 201 "Permission To Retransmit Location > Information to a Third Party" >=20 > This location error is specific to having the Presence Information > Data Format (PIDF-LO) [RFC4119] =20 > element set > to "=3Dno". This location error is stating it requires permission > (i.e., PIDF-LO element set to "=3Dyes") to > process this SIP request further. If the LS sending the location > information does not want to give this permission, it will=20 > not reset > this permission in a new request. If the LS wants this message > processed without this permission reset, it MUST choose another > logical path (if one exists). exists) for this SIP request. >=20 > Geolocation-Error: 302 202 "Permission to Route based on Location > Information" >=20 > This location error is specific to having the locationValue header > parameter set to "=3Dno". This location error is > stating it requires permission (i.e., a set to > "=3Dyes") to process this SIP request further. If the LS sending the > location information does not want to give this permission, it will > not reset this permission in a new request. If the LS wants this > message processed without this permission reset, it MUST choose > another logical path (if one exists). exists) for this SIP request. > New section 4.5 (previously 4.6): >=20 >=20 > 4.5 Location URIs Allowed Profile Negotiation >=20 > The following is part of the discussion started in Section=20 > 3, Figure > 2, which introduced the concept of sending location indirectly. >=20 > If a location URI is included in a SIP request, it SHOULD=20 > be the sending user > agent MUST also include a SIP-, > SIPS- or PRES-URI. When PRES: is used, as Supported=20 > header field indicating which > location profiles it supports. Two option tags for=20 > location profiles > are defined by this document: "geolocation-sip" and > "geolocation-http". Future specifications may define further > location profiles per the IANA policy described in=20 > [RFC3856], if Section 8.2. >=20 > The "geolocation-sip" option tag signals support for acquiring > location information via the presence event package of SIP > ([RFC3856]). A location recipient who supports this option can send > a SUBSCRIBE request and parse a resulting resolution=20 > resolves to NOTIFY containing a SIP: or SIPS: URI, > PIDF-LO object. The URI schemes supported by this > section applies. These option include > "sip", "sips" and "pres". >=20 > The "geolocation-http" option tag signals support for acquiring > location information via an HTTP ([RFC2616]). A location recipient > who supports this option can request location with an HTTP GET and > parse a resulting 200 response containing a PIDF-LO object. The URI > schemes MUST be implemented according to supported by this=20 > document. option include "http" and "https". A > failure to parse the 200 response, for whatever reason, will return > a "Dereference Failure" indication to the original location sending > user agent to inform it that location was not delivered as=20 > intended. >=20 > See [ID-GEO-FILTERS] (ID-GEO-FILTERS) for more details on=20 > dereferencing location. >=20 > An HTTP: [RFC2616] or HTTPS: URI [RFC2818] are also allowed, and > SHOULD be dereferenced according to [ID-HELD-DEREF]. location > information. > Change in IANA registration: >=20 >=20 > Code Description Reference > ---- --------------------------------------------------- --------- > 100 "Cannot Process Location" [this doc] >=20 > 200 "Retry Location Later with device updated location" [this doc] >=20 > 300 "Permission To Use Location Information" [this doc] >=20 > 301 >=20 > 201 "Permission To Retransmit Location Information to a=20 > Third Party" > [this doc] >=20 > 302 >=20 > 202 "Permission to Route based on Location Information" [this doc] >=20 > 400 >=20 > 300 "Dereference Failure" [this doc] >=20 > 8.6 IANA Registration of Location URI Schemes >=20 > This document directs IANA to create a new set of parameters in a > separate location from SIP and Geopriv, called the "Location > Reference URI" registry, containing the URI scheme, the > Content-Type, and the reference, as follows: >=20 > URI Scheme Content-Type Reference > ---------- ------------ --------- > SIP: [this doc] > SIPS: [this doc] > PRES: [this doc] > HTTP: [this doc] > HTTPS: [this doc] >=20 > Additions to this registry must be defined in a permanent and > readily available specification (this is the "Specification > Required" IANA policy defined in [RFC5226]). >=20 >=20 > /a >=20 > = From jmpolk@cisco.com Wed Feb 2 14:03:53 2011 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 9044D3A6DD4 for ; Wed, 2 Feb 2011 14:03:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.281 X-Spam-Level: X-Spam-Status: No, score=-99.281 tagged_above=-999 required=5 tests=[AWL=-11.182, BAYES_00=-2.599, RAZOR2_CF_RANGE_51_100=0.5, RAZOR2_CF_RANGE_E8_51_100=1.5, RAZOR2_CHECK=0.5, RCVD_IN_DNSWL_HI=-8, URIBL_BLACK=20, 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 fbcHRixgmKrp for ; Wed, 2 Feb 2011 14:03:52 -0800 (PST) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id B4D633A6E1C for ; Wed, 2 Feb 2011 14:03:51 -0800 (PST) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAFJkSU2rR7Hu/2dsb2JhbAClH3OgdI1jjUKFUwSEeA Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-6.cisco.com with ESMTP; 02 Feb 2011 22:07:12 +0000 Received: from jmpolk-wxp01.cisco.com (rcdn-jmpolk-8716.cisco.com [10.99.80.23]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id p12M7BbP027934; Wed, 2 Feb 2011 22:07:11 GMT Message-Id: <201102022207.p12M7BbP027934@sj-core-5.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 02 Feb 2011 16:07:09 -0600 To: "Elwell, John" , Adam Roach , SIPCORE From: "James M. Polk" In-Reply-To: References: <4D48A681.9080803@nostrum.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [sipcore] Proposed location conveyance changes 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, 02 Feb 2011 22:03:53 -0000 John Thanks for the review. I have comments in-line below. At 11:53 AM 2/2/2011, Elwell, John wrote: >This seems to reflect what was discussed. A few points: > >1. "If more than one locationValue is present in the SIP request and > determined to be valid by the LR, the location in that SIP request > MUST be considered good as far as location is concerned, and no > Geolocation-Error is sent." >Should this say: >"If more than one locationValue is present in the SIP request and > >>at least one location/Value is<< determined to be valid by the > LR, the location in that SIP request > MUST be considered good as far as location is concerned, and no > Geolocation-Error is sent." ? I like the addition. >2. "We have gone through the > exercise of getting this correct for every scenario, and deemed it > not worth the excruciating effort involved." >This may be true, but do we really want this in the final document? I'm ok with taking this out, but (no offense) want to here others opinions on this. >3. "These error codes are divided into 4 categories" >I only see 3. thought I caught all of these from the most recent reduction (sorry) fixed >4. "... any non-INVITE response to a > request containing location SHOULD NOT consider a 200 OK to mean ..." >Is a response able to consider? Presumably the subject be the >recipient of such a response. changed to "This means the receiver of any non-INVITE response to a ^^^^^^^^^^^^^^^ request containing location SHOULD NOT consider a 200 OK to mean the act of dereferencing has concluded and the dereferencer (i.e., the LR) has successfully received and parsed the PIDF-LO for errors ^^^^^^^^^^^^ and found none." Does this read better? >5. "Within these 4 3 number ranges, there is a top level error as follows:" >Should this say "Within each of these..."? fixed Thanks again James >John > > > > > -----Original Message----- > > From: sipcore-bounces@ietf.org > > [mailto:sipcore-bounces@ietf.org] On Behalf Of Adam Roach > > Sent: 02 February 2011 00:34 > > To: SIPCORE > > Subject: [sipcore] Proposed location conveyance changes > > > > [as chair] > > > > As a follow up from last-week's ad-hoc call on the topic of > > location conveyance, the authors have proposed the following > > technical changes (along with several editorial changes). > > Please review and comment as soon as possible. If there are > > no objections, the document will updated accordingly on or > > after Thursday of this week. > > > > Full proposed diffs can be viewed at http://ln-s.net/8T6P and > > http://ln-s.net/8T6Q > > > > > > In section 3.2: > > > > > > The example given in this section is only illustrative, not > > normative. In particular, applications can choose to dereference a > > location URI at any time, possibly several times, or > > potentially not > > at all. Applications receiving a Location URI in a SIP transaction > > need to be mindful of SIP's transaction timers. In particular, if > > the means of dereferencing the Location URI might take longer than > > the SIP transaction timeout (Timer C for INVITE transactions, Timer > > F for non-INVITE transactions), then it needs to rely on mechanisms > > other than the transaction's response code to convey location > > errors, if returning such errors are necessary. > > > > In section 4.3: > > > > > > A SIP intermediary that requires Alice's location in order to > > properly process Alice's INVITE also sends a 424 with a > > Geolocation-Error code. This message flow is shown in Figure 4 of > > Section 3.4. > > > > If more than one locationValue is present in the SIP request and > > determined to be valid by the LR, the location in that SIP request > > MUST be considered good as far as location is concerned, and no > > Geolocation-Error is sent. This is a compromise of complexity vs. > > accurate information conveyance with respect to informing each > > location inserter of every bad location. We have gone through the > > exercise of getting this correct for every scenario, and deemed it > > not worth the excruciating effort involved. > > > > Here is an initial list of location based error ranges for any SIP > > non-100 response, including the new 424 (Bad Location Information) > > response. These error codes are divided into 4 > > categories, based on > > how the response receiver should react to these errors. There can > > only be one Geolocation-Error code in a SIP response, regardless of > > how many locationValues there are in the correlating SIP request. > > There is no guidance given in this document as to which > > locationValue is formally errored (when more than one was present); > > meaning that, somehow not defined here, the LR just picks one to > > error. > > > > o 1XX errors mean the LR cannot process the location within the > > request. > > > > o 2XX errors mean the LR wants > > request > > > > A non-exclusive list of reasons for returning a 1XX is > > > > - the LS to send new location was not present or > > updated could not be found, > > - there was not enough location information, perhaps > > with a delay associated with when information to send determine > > where the request. Target was, > > - the location information was corrupted or known to be > > inaccurate, > > - etc... > > > > o 3XX 2XX errors mean some specific permission is > > necessary to process > > the included location information. > > > > o 4XX 3XX errors mean there was trouble dereferencing > > the Location URI > > sent. > > > > It should be noted that for non-INVITE transactions, the SIP > > response will likely be sent before the dereference response has > > been received. At this time, this document does not alter that SIP > > protocol reality. This means that any non-INVITE response to a > > request containing location SHOULD NOT consider a 200 OK > > to mean the > > act of dereferencing has concluded and the dereferencer (i.e., the > > LR) has successfully parsed the PIDF-LO for errors and found none. > > This was first brought up in Section 3.2. > > > > Additionally, if a SIP entity cannot or chooses not to process > > location or the SIP request containing location, the existing > > mechanism of responding with a 503 (Service Unavailable) SHOULD be > > used with or without a configurable Retry-After header field. There > > is no special location error code for what already exists > > within SIP > > today. > > > > Within these 4 3 number ranges, there is a top level error > > as follows: > > > > Geolocation-Error: 100 "Cannot Process Location" > > > > Geolocation-Error: 200 "Retry Location Later with device updated > > location" > > > > Geolocation-Error: 300 "Permission To Use Location Information" > > > > Geolocation-Error: 400 300 "Dereference Failure" > > > > There are two specific Geolocation-Error codes necessary to include > > in this document, both have to do with permissions necessary to > > process the SIP request; they are > > > > Geolocation-Error: 301 201 "Permission To Retransmit Location > > Information to a Third Party" > > > > This location error is specific to having the Presence Information > > Data Format (PIDF-LO) [RFC4119] > > element set > > to "=no". This location error is stating it requires permission > > (i.e., PIDF-LO element set to "=yes") to > > process this SIP request further. If the LS sending the location > > information does not want to give this permission, it will > > not reset > > this permission in a new request. If the LS wants this message > > processed without this permission reset, it MUST choose another > > logical path (if one exists). exists) for this SIP request. > > > > Geolocation-Error: 302 202 "Permission to Route based on Location > > Information" > > > > This location error is specific to having the locationValue header > > parameter set to "=no". This location error is > > stating it requires permission (i.e., a set to > > "=yes") to process this SIP request further. If the LS sending the > > location information does not want to give this permission, it will > > not reset this permission in a new request. If the LS wants this > > message processed without this permission reset, it MUST choose > > another logical path (if one exists). exists) for this SIP request. > > New section 4.5 (previously 4.6): > > > > > > 4.5 Location URIs Allowed Profile Negotiation > > > > The following is part of the discussion started in Section > > 3, Figure > > 2, which introduced the concept of sending location indirectly. > > > > If a location URI is included in a SIP request, it SHOULD > > be the sending user > > agent MUST also include a SIP-, > > SIPS- or PRES-URI. When PRES: is used, as Supported > > header field indicating which > > location profiles it supports. Two option tags for > > location profiles > > are defined by this document: "geolocation-sip" and > > "geolocation-http". Future specifications may define further > > location profiles per the IANA policy described in > > [RFC3856], if Section 8.2. > > > > The "geolocation-sip" option tag signals support for acquiring > > location information via the presence event package of SIP > > ([RFC3856]). A location recipient who supports this option can send > > a SUBSCRIBE request and parse a resulting resolution > > resolves to NOTIFY containing a SIP: or SIPS: URI, > > PIDF-LO object. The URI schemes supported by this > > section applies. These option include > > "sip", "sips" and "pres". > > > > The "geolocation-http" option tag signals support for acquiring > > location information via an HTTP ([RFC2616]). A location recipient > > who supports this option can request location with an HTTP GET and > > parse a resulting 200 response containing a PIDF-LO object. The URI > > schemes MUST be implemented according to supported by this > > document. option include "http" and "https". A > > failure to parse the 200 response, for whatever reason, will return > > a "Dereference Failure" indication to the original location sending > > user agent to inform it that location was not delivered as > > intended. > > > > See [ID-GEO-FILTERS] (ID-GEO-FILTERS) for more details on > > dereferencing location. > > > > An HTTP: [RFC2616] or HTTPS: URI [RFC2818] are also allowed, and > > SHOULD be dereferenced according to [ID-HELD-DEREF]. location > > information. > > Change in IANA registration: > > > > > > Code Description Reference > > ---- --------------------------------------------------- --------- > > 100 "Cannot Process Location" [this doc] > > > > 200 "Retry Location Later with device updated location" [this doc] > > > > 300 "Permission To Use Location Information" [this doc] > > > > 301 > > > > 201 "Permission To Retransmit Location Information to a > > Third Party" > > [this doc] > > > > 302 > > > > 202 "Permission to Route based on Location Information" [this doc] > > > > 400 > > > > 300 "Dereference Failure" [this doc] > > > > 8.6 IANA Registration of Location URI Schemes > > > > This document directs IANA to create a new set of parameters in a > > separate location from SIP and Geopriv, called the "Location > > Reference URI" registry, containing the URI scheme, the > > Content-Type, and the reference, as follows: > > > > URI Scheme Content-Type Reference > > ---------- ------------ --------- > > SIP: [this doc] > > SIPS: [this doc] > > PRES: [this doc] > > HTTP: [this doc] > > HTTPS: [this doc] > > > > Additions to this registry must be defined in a permanent and > > readily available specification (this is the "Specification > > Required" IANA policy defined in [RFC5226]). > > > > > > /a > > > > >_______________________________________________ >sipcore mailing list >sipcore@ietf.org >https://www.ietf.org/mailman/listinfo/sipcore From Martin.Thomson@andrew.com Wed Feb 2 14:12:52 2011 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 95EF53A6C72 for ; Wed, 2 Feb 2011 14:12:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.544 X-Spam-Level: X-Spam-Status: No, score=-2.544 tagged_above=-999 required=5 tests=[AWL=0.055, 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 nTO3DeOnapOS for ; Wed, 2 Feb 2011 14:12:52 -0800 (PST) Received: from csmailgw2.commscope.com (csmailgw2.commscope.com [198.135.207.242]) by core3.amsl.com (Postfix) with ESMTP id D42A63A6ABE for ; Wed, 2 Feb 2011 14:12:51 -0800 (PST) Received: from [10.86.20.103] ([10.86.20.103]:1889 "EHLO ACDCE7HC2.commscope.com") by csmailgw2.commscope.com with ESMTP id S544522Ab1BBWQM (ORCPT ); Wed, 2 Feb 2011 16:16:12 -0600 Received: from SISPE7HC2.commscope.com (10.97.4.13) by ACDCE7HC2.commscope.com (10.86.20.103) with Microsoft SMTP Server (TLS) id 8.3.137.0; Wed, 2 Feb 2011 16:16:12 -0600 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC2.commscope.com ([fe80::58c3:2447:f977:57c3%10]) with mapi; Thu, 3 Feb 2011 06:16:08 +0800 From: "Thomson, Martin" To: "James M. Polk" , "Elwell, John" , Adam Roach , SIPCORE Date: Thu, 3 Feb 2011 06:16:03 +0800 Thread-Topic: [sipcore] Proposed location conveyance changes Thread-Index: AcvDJa//QB5IRNsUSgOyhpZ1NdZ2DAAACiyw Message-ID: <8B0A9FCBB9832F43971E38010638454F03FEA152DD@SISPE7MB1.commscope.com> References: <4D48A681.9080803@nostrum.com> <201102022207.p12M7BbP027934@sj-core-5.cisco.com> In-Reply-To: <201102022207.p12M7BbP027934@sj-core-5.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="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-BCN: Meridius 1000 Version 3.4 on csmailgw2.commscope.com X-BCN-Sender: Martin.Thomson@andrew.com Subject: Re: [sipcore] Proposed location conveyance changes 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, 02 Feb 2011 22:12:52 -0000 T24gMjAxMS0wMi0wMyBhdCAwOTowNzowOSwgSmFtZXMgTS4gUG9sayB3cm90ZToNCj4gPjIuICJX ZSBoYXZlIGdvbmUgdGhyb3VnaCB0aGUNCj4gPiAgICBleGVyY2lzZSBvZiBnZXR0aW5nIHRoaXMg Y29ycmVjdCBmb3IgZXZlcnkgc2NlbmFyaW8sIGFuZCBkZWVtZWQgaXQNCj4gPiAgICBub3Qgd29y dGggdGhlIGV4Y3J1Y2lhdGluZyBlZmZvcnQgaW52b2x2ZWQuIg0KPiA+VGhpcyBtYXkgYmUgdHJ1 ZSwgYnV0IGRvIHdlIHJlYWxseSB3YW50IHRoaXMgaW4gdGhlIGZpbmFsIGRvY3VtZW50Pw0KPiAN Cj4gSSdtIG9rIHdpdGggdGFraW5nIHRoaXMgb3V0LCBidXQgKG5vIG9mZmVuc2UpIHdhbnQgdG8g aGVyZSBvdGhlcnMNCj4gb3BpbmlvbnMgb24gdGhpcy4NCg0KU2luY2UgeW91IGFzaywgdGhpcyBz b3J0IG9mIHN0YXRlbWVudCBpcyBvZiB0cmFuc2l0b3J5IHZhbHVlIGF0IGJlc3QuICBJJ20gZ2xh ZCB0aGF0IHlvdSBkaWQgZ28gdG8gdGhlIGVmZm9ydCwgYnV0IEknbSBub3Qgc3VyZSB0aGF0IGZ1 dHVyZSByZWFkZXJzIHdpbGwgYXBwcmVjaWF0ZSBpdCBpbiB0aGUgc2FtZSB3YXkuICBSZW1vdmlu ZyBpdCB3b3VsZCBiZSBuaWNlLg0K From Martin.Thomson@andrew.com Wed Feb 2 16:35:48 2011 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 D07523A63D2 for ; Wed, 2 Feb 2011 16:35:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.545 X-Spam-Level: X-Spam-Status: No, score=-2.545 tagged_above=-999 required=5 tests=[AWL=0.054, 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 n2uDifnEmKKQ for ; Wed, 2 Feb 2011 16:35:48 -0800 (PST) Received: from csmailgw1.commscope.com (csmailgw1.commscope.com [198.135.207.244]) by core3.amsl.com (Postfix) with ESMTP id DF4A33A6359 for ; Wed, 2 Feb 2011 16:35:47 -0800 (PST) Received: from [10.86.20.102] ([10.86.20.102]:17366 "EHLO ACDCE7HC1.commscope.com") by csmailgw1.commscope.com with ESMTP id S42261905Ab1BCAjI (ORCPT ); Wed, 2 Feb 2011 18:39:08 -0600 Received: from SISPE7HC2.commscope.com (10.97.4.13) by ACDCE7HC1.commscope.com (10.86.20.102) with Microsoft SMTP Server (TLS) id 8.3.137.0; Wed, 2 Feb 2011 18:39:08 -0600 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC2.commscope.com ([fe80::58c3:2447:f977:57c3%10]) with mapi; Thu, 3 Feb 2011 08:39:05 +0800 From: "Thomson, Martin" To: Adam Roach , SIPCORE Date: Thu, 3 Feb 2011 08:39:03 +0800 Thread-Topic: [sipcore] Proposed location conveyance changes Thread-Index: AcvCcP7CnUu466DZT5mvNIEUO+YKTwAxiwtg Message-ID: <8B0A9FCBB9832F43971E38010638454F03FEA15300@SISPE7MB1.commscope.com> References: <4D48A681.9080803@nostrum.com> In-Reply-To: <4D48A681.9080803@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-BCN: Meridius 1000 Version 3.4 on csmailgw1.commscope.com X-BCN-Sender: Martin.Thomson@andrew.com Subject: Re: [sipcore] Proposed location conveyance changes 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, 03 Feb 2011 00:35:48 -0000 VGhlc2UgbG9vayBnb29kIHRvIG1lLg0KDQpTb21lIHNtYWxsIHN1Z2dlc3Rpb25zIGJlbG93Lg0K DQpPbiAyMDExLTAyLTAyIGF0IDExOjM0OjA5LCBBZGFtIFJvYWNoIHdyb3RlOg0KPiBJbiBzZWN0 aW9uIDMuMjoNCj4gICAgbmVlZCB0byBiZSBtaW5kZnVsIG9mIFNJUCdzIHRyYW5zYWN0aW9uIHRp bWVycy4gSW4gcGFydGljdWxhciwgaWYNCg0KTml0OiBwb3NzZXNzaXZlIGFwb3N0cm9waGVzIG9u IGluYW5pbWF0ZSBvYmplY3QgYXJlIG5vdCBnb29kOiBzL1NJUCdzIHRyYW5zYWN0aW9uIHRpbWVy cy90aW1lcnMgdXNlZCBieSBkaWZmZXJlbnQgdHJhbnNhY3Rpb25zLw0KDQo+IEluIHNlY3Rpb24g NC4zOg0KLi4uDQo+ICAgIFdlIGhhdmUgZ29uZSB0aHJvdWdoIHRoZQ0KPiAgICBleGVyY2lzZSBv ZiBnZXR0aW5nIHRoaXMgY29ycmVjdCBmb3IgZXZlcnkgc2NlbmFyaW8sIGFuZCBkZWVtZWQgaXQN Cj4gICAgbm90IHdvcnRoIHRoZSBleGNydWNpYXRpbmcgZWZmb3J0IGludm9sdmVkLg0KDQpBZ3Jl ZSB3aXRoIEpvaG4gb24gdGhpcyBvbmU6IHRoaXMgaXMgbm90IG5lY2Vzc2FyeS4NCg0KPiAgICBU aGVyZSBpcyBubyBndWlkYW5jZSBnaXZlbiBpbiB0aGlzIGRvY3VtZW50IGFzIHRvIHdoaWNoDQo+ ICAgIGxvY2F0aW9uVmFsdWUgaXMgZm9ybWFsbHkgZXJyb3JlZCAod2hlbiBtb3JlIHRoYW4gb25l IHdhcyBwcmVzZW50KTsNCj4gICAgbWVhbmluZyB0aGF0LCBzb21laG93IG5vdCBkZWZpbmVkIGhl cmUsIHRoZSBMUiBqdXN0IHBpY2tzIG9uZSB0bw0KPiAgICBlcnJvci4NCg0KImVycm9yZWQiIGlz bid0IGluIG15IGRpY3Rpb25hcnkuICBTdWdnZXN0Og0KDQogIFRoZXJlIGlzIG5vIG1lY2hhbmlz bSBwcm92aWRlZCB0byBpbmRpY2F0ZSB3aGljaCBvZiBtdWx0aXBsZSBsb2NhdGlvblZhbHVlcyBp cyBpbiBlcnJvci4gIElmIGFsbCBsb2NhdGlvblZhbHVlcyBhcmUgaW4gZXJyb3IsIHRoZSBMUiBj YW4gc2VsZWN0IGFueSBsb2NhdGlvblZhbHVlIGZvciB3aGljaCB0byBwcm92aWRlIGFuIGVycm9y Lg0KDQo+ICAgIEl0IHNob3VsZCBiZSBub3RlZCB0aGF0IGZvciBub24tSU5WSVRFIHRyYW5zYWN0 aW9ucywgdGhlIFNJUA0KPiAgICByZXNwb25zZSB3aWxsIGxpa2VseSBiZSBzZW50IGJlZm9yZSB0 aGUgZGVyZWZlcmVuY2UgcmVzcG9uc2UgaGFzDQo+ICAgIGJlZW4gcmVjZWl2ZWQuIEF0IHRoaXMg dGltZSwgdGhpcyBkb2N1bWVudCBkb2VzIG5vdCBhbHRlciB0aGF0IFNJUA0KPiAgICBwcm90b2Nv bCByZWFsaXR5LiBUaGlzIG1lYW5zIHRoYXQgYW55IG5vbi1JTlZJVEUgcmVzcG9uc2UgdG8gYQ0K PiAgICByZXF1ZXN0IGNvbnRhaW5pbmcgbG9jYXRpb24gU0hPVUxEIE5PVCBjb25zaWRlciBhIDIw MCBPSyB0byBtZWFuIHRoZQ0KPiAgICBhY3Qgb2YgZGVyZWZlcmVuY2luZyBoYXMgY29uY2x1ZGVk IGFuZCB0aGUgZGVyZWZlcmVuY2VyIChpLmUuLCB0aGUNCj4gICAgTFIpIGhhcyBzdWNjZXNzZnVs bHkgcGFyc2VkIHRoZSBQSURGLUxPIGZvciBlcnJvcnMgYW5kIGZvdW5kIG5vbmUuDQo+ICAgIFRo aXMgd2FzIGZpcnN0IGJyb3VnaHQgdXAgaW4gU2VjdGlvbiAzLjIuDQoNCkkgZG9uJ3QgdGhpbmsg dGhhdCByZXBlYXRpbmcgdGhpcyBwb2ludCBpcyBuZWNlc3Nhcnkgb3IgdXNlZnVsLiAgVGhlIHBv aW50IHRoYXQgaXMgaW1wb3J0YW50IGlzIHRoYXQgaWYgdGhlIDIwMCBpcyBkZXBlbmRlbnQgb24g dGhlIGxvY2F0aW9uLCB0aGVuIHlvdSBjYW4gc2VuZCB0aGVzZSByZXNwb25zZXM7IGlmIHRoZSAy MDAgaXMgbm90LCB0aGVuIGRvbid0LiAgRm9yIHRob3NlIGNhc2VzIHdoZXJlIHlvdSBjYW4ndCBk ZXJlZmVyZW5jZSBiZWZvcmUgdGhlIDIwMCBpcyBzZW50LCB0aGVuIHRoZSBsb2NhdGlvbiBoYWQg YmV0dGVyIG5vdCBiZSBuZWNlc3NhcnkgZm9yIHRoZSAyMDAgdG8gYmUgc2VudC4NCg0KU2VlIEpv bidzIGVtYWlsIG9uIHRoZSB0b3BpYywgaS5lLiwgIndlIHNob3VsZCBub3QgdHJ5IHRvIGJ1aWxk IHRoZSBleHBlY3RlZCBiZWhhdmlvciBvZiBhcHBsaWNhdGlvbnMgaW50byB0aGUgbG93LWxldmVs IHByb3RvY29sIGJ1aWxkaW5nIGJsb2NrcyIuLi4NCg0KPiBOZXcgc2VjdGlvbiA0LjUgKHByZXZp b3VzbHkgNC42KToNCi4uLg0KPiAgICBUaGUgImdlb2xvY2F0aW9uLWh0dHAiIG9wdGlvbiB0YWcg c2lnbmFscyBzdXBwb3J0IGZvciBhY3F1aXJpbmcNCj4gICAgbG9jYXRpb24gaW5mb3JtYXRpb24g dmlhIGFuIEhUVFAgKFtSRkMyNjE2XSkuIEEgbG9jYXRpb24gcmVjaXBpZW50DQoNClN1Z2dlc3Qg YSByZWZlcmVuY2UgdG8gZHJhZnQtaWV0Zi1nZW9wcml2LWRlcmVmLXByb3RvY29sIGluIGFkZGl0 aW9uIHRvIDI2MTYuDQoNCj4gICAgU2VlIChJRC1HRU8tRklMVEVSUykgZm9yIG1vcmUgZGV0YWls cyBvbiBkZXJlZmVyZW5jaW5nIGxvY2F0aW9uIGluZm9ybWF0aW9uLg0KDQpPciBoZXJlLiAgIFdo eSBkb2VzIHRoaXMgcmVmZXJlbmNlIHVzZSBwYXJlbnRoZXNlcyBub3csIHJhdGhlciB0aGFuIGJy YWNrZXRzPw0KDQo= From jmpolk@cisco.com Wed Feb 2 18:19:23 2011 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 02B253A67B6 for ; Wed, 2 Feb 2011 18:19:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.212 X-Spam-Level: X-Spam-Status: No, score=-110.212 tagged_above=-999 required=5 tests=[AWL=0.387, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 JnkMOOOPxCOv for ; Wed, 2 Feb 2011 18:19:22 -0800 (PST) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 309903A67B3 for ; Wed, 2 Feb 2011 18:19:22 -0800 (PST) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-6.cisco.com with ESMTP; 03 Feb 2011 02:22:43 +0000 Received: from jmpolk-wxp01.cisco.com (rcdn-jmpolk-8716.cisco.com [10.99.80.23]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id p132MgP0002046; Thu, 3 Feb 2011 02:22:42 GMT Message-Id: <201102030222.p132MgP0002046@sj-core-2.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 02 Feb 2011 20:22:41 -0600 To: "Thomson, Martin" , "James M. Polk" , "Elwell, John" , Adam Roach , SIPCORE From: "James M. Polk" In-Reply-To: <8B0A9FCBB9832F43971E38010638454F03FEA152DD@SISPE7MB1.comms cope.com> References: <4D48A681.9080803@nostrum.com> <201102022207.p12M7BbP027934@sj-core-5.cisco.com> <8B0A9FCBB9832F43971E38010638454F03FEA152DD@SISPE7MB1.commscope.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [sipcore] Proposed location conveyance changes 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, 03 Feb 2011 02:19:23 -0000 At 04:16 PM 2/2/2011, Thomson, Martin wrote: >On 2011-02-03 at 09:07:09, James M. Polk wrote: > > >2. "We have gone through the > > > exercise of getting this correct for every scenario, and deemed it > > > not worth the excruciating effort involved." > > >This may be true, but do we really want this in the final document? > > > > I'm ok with taking this out, but (no offense) want to here others > > opinions on this. > >Since you ask, this sort of statement is of transitory value at >best. I'm glad that you did go to the effort, but I'm not sure that >future readers will appreciate it in the same way. Removing it would be nice. ok, done (unless my Jon has heartburn about it) James From jon.peterson@neustar.biz Thu Feb 3 09:43:32 2011 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 7574F3A6A2D for ; Thu, 3 Feb 2011 09:43:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.744 X-Spam-Level: X-Spam-Status: No, score=-104.744 tagged_above=-999 required=5 tests=[AWL=1.855, 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 mKv2CdZcYNBN for ; Thu, 3 Feb 2011 09:43:31 -0800 (PST) Received: from neustar.com (mx1.neustar.com [156.154.17.104]) by core3.amsl.com (Postfix) with ESMTP id 414243A6A32 for ; Thu, 3 Feb 2011 09:43:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1296755210; x=1612113679; q=dns/txt; h=From:Date:Subject:Message-ID:Content-Language: Content-Type:Content-Transfer-Encoding; bh=+8sAOY3fijRZkxAX0fzCq 6nD7VTYleCGBFyuUY9m+74=; b=bLgEZcPu9vZgWZvNxqouKXRSXk4mbHkZ2xvw4 ASvfpwUbdJzs7StJY6skF8SD+hhLmCimLO+Z5dNEKnljPHT/A== Received: from ([10.31.13.228]) by stihiron2.va.neustar.com with ESMTP with TLS id 5202732.42050337; Thu, 03 Feb 2011 12:46:49 -0500 Received: from STNTEXCH01.cis.neustar.com ([fe80::31b6:4d09:2ada:e6c0]) by STNTEXCHHT01.cis.neustar.com ([::1]) with mapi; Thu, 3 Feb 2011 12:46:49 -0500 From: "Peterson, Jon" To: "James M. Polk" Date: Thu, 3 Feb 2011 12:46:48 -0500 Thread-Topic: [sipcore] Proposed location conveyance changes Thread-Index: AcvDylUCAMjAmlzbTf6FvemqaHObIg== Message-ID: <8287EDA9-2C9D-42B6-AA1A-FE248F936BAF@neustar.biz> References: <4D48A681.9080803@nostrum.com> <201102022207.p12M7BbP027934@sj-core-5.cisco.com> <8B0A9FCBB9832F43971E38010638454F03FEA152DD@SISPE7MB1.commscope.com> <201102030222.p132MgP0002046@sj-core-2.cisco.com> In-Reply-To: <201102030222.p132MgP0002046@sj-core-2.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: Iz5I+C8ryJAP80WbLIj+Cw== Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: SIPCORE , "Thomson, Martin" Subject: Re: [sipcore] Proposed location conveyance changes 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, 03 Feb 2011 17:43:32 -0000 I'm fine with removing it. Jon Peterson NeuStar, Inc. On Feb 2, 2011, at 9:22 PM, James M. Polk wrote: > At 04:16 PM 2/2/2011, Thomson, Martin wrote: >> On 2011-02-03 at 09:07:09, James M. Polk wrote: >>>> 2. "We have gone through the >>>> exercise of getting this correct for every scenario, and deemed it >>>> not worth the excruciating effort involved." >>>> This may be true, but do we really want this in the final document? >>>=20 >>> I'm ok with taking this out, but (no offense) want to here others >>> opinions on this. >>=20 >> Since you ask, this sort of statement is of transitory value at=20 >> best. I'm glad that you did go to the effort, but I'm not sure that=20 >> future readers will appreciate it in the same way. Removing it would be= nice. >=20 > ok, done >=20 > (unless my Jon has heartburn about it) >=20 > James >=20 >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From adam@nostrum.com Thu Feb 3 10:42:23 2011 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 3EF803A6A9E for ; Thu, 3 Feb 2011 10:42:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.519 X-Spam-Level: X-Spam-Status: No, score=-102.519 tagged_above=-999 required=5 tests=[AWL=0.081, BAYES_00=-2.599, SPF_PASS=-0.001, 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 hvPl9etmOlc3 for ; Thu, 3 Feb 2011 10:42:22 -0800 (PST) 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 9F8723A6AA1 for ; Thu, 3 Feb 2011 10:42:21 -0800 (PST) Received: from dn3-228.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 p13Ijh68036902 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Thu, 3 Feb 2011 12:45:43 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <4D4AF7D7.5010209@nostrum.com> Date: Thu, 03 Feb 2011 12:45:43 -0600 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: "SIPCORE (Session Initiation Protocol Core) WG" 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) Subject: [sipcore] CANCELED: Today's Location Conveyance Call X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: SIPCORE Chairs List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Feb 2011 18:42:23 -0000 [as chair] Given the somewhat late publication of the proposed diffs, and the fact that one of the main authors of the document cannot make the phone call today, we will not be having a location conveyance call today. Instead: if you haven't already, please take a few moments to review the changes proposed to the document, and briefly confirm your assent or indicate how you think they can be improved. There is one remaining issue on the document, which I will summarize to the list shortly. /a From adam@nostrum.com Thu Feb 3 11:55:28 2011 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 DD6943A6AD7 for ; Thu, 3 Feb 2011 11:55:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.521 X-Spam-Level: X-Spam-Status: No, score=-102.521 tagged_above=-999 required=5 tests=[AWL=0.078, BAYES_00=-2.599, HTML_MESSAGE=0.001, SPF_PASS=-0.001, 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 2mjm8RUfY7Tn for ; Thu, 3 Feb 2011 11:55:27 -0800 (PST) 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 1E8E63A6AD6 for ; Thu, 3 Feb 2011 11:55:26 -0800 (PST) Received: from dn3-228.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 p13JwnqQ043147 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Thu, 3 Feb 2011 13:58:49 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <4D4B08F8.4040502@nostrum.com> Date: Thu, 03 Feb 2011 13:58:48 -0600 From: Adam Roach - SIPCORE Chair User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: "SIPCORE (Session Initiation Protocol Core) WG" Content-Type: multipart/alternative; boundary="------------010408040503030205040801" Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Subject: [sipcore] Call for Consensus: Location Conveyance Syntax X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: SIPCORE Chairs List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Feb 2011 19:55:29 -0000 This is a multi-part message in MIME format. --------------010408040503030205040801 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit [as chair] With the changes around ordinality of Geolocation values in SIP messages, there were a handful of changes made and/or suggested to the Geolocation header field syntax. Back in October, Paul Kyzivat suggested five concrete ABNF proposals. They appear near the bottom of this message: http://www.ietf.org/mail-archive/web/sipcore/current/msg03594.html * James Polk spoke in favor of pursuing option #1, largely because it is closest to the current syntax. * Anders Kristensen favored #4 and #5 as being more consistent with typical SIP header field syntax. * John Elwell expressed a preference for #4, although was willing to accept #1. That's not enough feedback to really inform consensus. As an aside, options #1 and #4 contravene the later consensus expressed by the working group to allow an arbitrary number of location values; both options #1 and #4 enforce a 2-value maximum. Options #2 and #5 are effectively variations on #1 and #4 without such restrictions. In practice, there are really two issues to resolve here, and we should consider them separately: 1. If there are multiple location values in a SIP message, are they: (a) Required to appear in a single Geolocation header field, or (b) Allowed to appear in a single Geolocation header field, but permitted to appear in their own Geolocation header fields? [No one has yet suggested that they be forced to appear each in their own header field, so I'm not listing that as an option] 2. Does the "routing allowed" flag: (a) Appear as a *field* in a Geolocation header field (e.g., "Geolocation: , routing-allowed=yes"), or (b) Appear as its own header field (e.g., "Geolocation-Routing: yes") Please weigh in with opinions on these two choices. Be sure to give the rationale, however brief it might be, for your decision in your response. /a --------------010408040503030205040801 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit [as chair]

With the changes around ordinality of Geolocation values in SIP messages, there were a handful of changes made and/or suggested to the Geolocation header field syntax.

Back in October, Paul Kyzivat suggested five concrete ABNF proposals. They appear near the bottom of this message:

http://www.ietf.org/mail-archive/web/sipcore/current/msg03594.html

  • James Polk spoke in favor of pursuing option #1, largely because it is closest to the current syntax.
  • Anders Kristensen favored #4 and #5 as being more consistent with typical SIP header field syntax.
  • John Elwell expressed a preference for #4, although was willing to accept #1.

That's not enough feedback to really inform consensus.

As an aside, options #1 and #4 contravene the later consensus expressed by the working group to allow an arbitrary number of location values; both options #1 and #4 enforce a 2-value maximum. Options #2 and #5 are effectively variations on #1 and #4 without such restrictions.

In practice, there are really two issues to resolve here, and we should consider them separately:


1. If there are multiple location values in a SIP message, are they:

   (a) Required to appear in a single Geolocation header field, or

   (b) Allowed to appear in a single Geolocation header field, but
       permitted to appear in their own Geolocation header fields?

[No one has yet suggested that they be forced to appear each in their
own header field, so I'm not listing that as an option]


2. Does the "routing allowed" flag:

   (a) Appear as a *field* in a Geolocation header field
       (e.g., "Geolocation: <sip:...>, routing-allowed=yes"), or

   (b) Appear as its own header field
       (e.g., "Geolocation-Routing: yes")


Please weigh in with opinions on these two choices. Be sure to give the rationale, however brief it might be, for your decision in your response.

/a
 --------------010408040503030205040801-- From jmpolk@cisco.com Thu Feb 3 12:24:05 2011 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 DE07F3A6AEA for ; Thu, 3 Feb 2011 12:24:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.522 X-Spam-Level: X-Spam-Status: No, score=-110.522 tagged_above=-999 required=5 tests=[AWL=0.077, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 qfsogAAVbZBO for ; Thu, 3 Feb 2011 12:24:05 -0800 (PST) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 64F3C3A6ADA for ; Thu, 3 Feb 2011 12:24:02 -0800 (PST) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-6.cisco.com with ESMTP; 03 Feb 2011 20:27:25 +0000 Received: from jmpolk-wxp01.cisco.com (rcdn-jmpolk-8716.cisco.com [10.99.80.23]) by sj-core-4.cisco.com (8.13.8/8.14.3) with ESMTP id p13KRO9s014002; Thu, 3 Feb 2011 20:27:24 GMT Message-Id: <201102032027.p13KRO9s014002@sj-core-4.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 03 Feb 2011 14:27:23 -0600 To: "Peterson, Jon" , "James M. Polk" From: "James M. Polk" In-Reply-To: <8287EDA9-2C9D-42B6-AA1A-FE248F936BAF@neustar.biz> References: <4D48A681.9080803@nostrum.com> <201102022207.p12M7BbP027934@sj-core-5.cisco.com> <8B0A9FCBB9832F43971E38010638454F03FEA152DD@SISPE7MB1.commscope.com> <201102030222.p132MgP0002046@sj-core-2.cisco.com> <8287EDA9-2C9D-42B6-AA1A-FE248F936BAF@neustar.biz> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: SIPCORE , "Thomson, Martin" Subject: Re: [sipcore] Proposed location conveyance changes 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, 03 Feb 2011 20:24:06 -0000 At 11:46 AM 2/3/2011, Peterson, Jon wrote: >I'm fine with removing it. done >Jon Peterson >NeuStar, Inc. > >On Feb 2, 2011, at 9:22 PM, James M. Polk wrote: > > > At 04:16 PM 2/2/2011, Thomson, Martin wrote: > >> On 2011-02-03 at 09:07:09, James M. Polk wrote: > >>>> 2. "We have gone through the > >>>> exercise of getting this correct for every scenario, and deemed it > >>>> not worth the excruciating effort involved." > >>>> This may be true, but do we really want this in the final document? > >>> > >>> I'm ok with taking this out, but (no offense) want to here others > >>> opinions on this. > >> > >> Since you ask, this sort of statement is of transitory value at > >> best. I'm glad that you did go to the effort, but I'm not sure that > >> future readers will appreciate it in the same way. Removing it > would be nice. > > > > ok, done > > > > (unless my Jon has heartburn about it) > > > > James > > > > > > _______________________________________________ > > sipcore mailing list > > sipcore@ietf.org > > https://www.ietf.org/mailman/listinfo/sipcore From jmpolk@cisco.com Thu Feb 3 12:39:06 2011 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 016D33A6AE1 for ; Thu, 3 Feb 2011 12:39:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.527 X-Spam-Level: X-Spam-Status: No, score=-110.527 tagged_above=-999 required=5 tests=[AWL=0.072, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 GMv11MIv+kDq for ; Thu, 3 Feb 2011 12:39:05 -0800 (PST) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 1A64E3A6405 for ; Thu, 3 Feb 2011 12:39:05 -0800 (PST) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAOahSk2rRN+K/2dsb2JhbAClNHOiPZsKhVgEhHk Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-6.cisco.com with ESMTP; 03 Feb 2011 20:42:28 +0000 Received: from jmpolk-wxp01.cisco.com (rcdn-jmpolk-8716.cisco.com [10.99.80.23]) by sj-core-4.cisco.com (8.13.8/8.14.3) with ESMTP id p13KgREX020490; Thu, 3 Feb 2011 20:42:28 GMT Message-Id: <201102032042.p13KgREX020490@sj-core-4.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 03 Feb 2011 14:42:26 -0600 To: SIPCORE Chairs , "SIPCORE (Session Initiation Protocol Core) WG" From: "James M. Polk" In-Reply-To: <4D4B08F8.4040502@nostrum.com> References: <4D4B08F8.4040502@nostrum.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [sipcore] Call for Consensus: Location Conveyance Syntax 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, 03 Feb 2011 20:39:06 -0000 At 01:58 PM 2/3/2011, Adam Roach - SIPCORE Chair wrote: >[as chair] > >With the changes around ordinality of Geolocation values in SIP >messages, there were a handful of changes made and/or suggested to >the Geolocation header field syntax. > >Back in October, Paul Kyzivat suggested five concrete ABNF >proposals. They appear near the bottom of this message: > >http://www.ietf.org/mail-archive/web/sipcore/current/msg03594.html > > * James Polk spoke in favor of pursuing option #1, largely > because it is closest to the current syntax. there's another reason: if we separate these two header parameters into separate SIP header fields, with the default behavior remaining , each time a SIP entity receives a Geolocation: header, they will have to search for a "Geolocation-Routing: yes" header value if they are configured as an Location Recipient (meaning they need explicit permission to actually look at the included PIDF-LO message body (part) or dereference the (or any) locationURI in any Geolocation: header field. I have heard some implementers not want to have to do this additional processing. Keeping the "routing-allowed=yes or no" header parameter within the same Geolocation: header field relieves implementers from doing such searches. Multiple locationValues, and therefore multiple Geolocation header values, is NOT RECOMMENDED in the doc (and uses RFC-2119 strength), therefore only bad implementations will have multiple instances of a Geolocation header with Option #1, which seems easiest, and does not really buy us much. I believe the goal lately of this effort is to simplify it, and choosing Options #4 or 5 would complicate it relative to Option #1. My personal concern is that (dare I say) lazy implementers *could* see a Geolocation: header and not look for the explicit permission (if in a separate header value) to view or dereference the location, thereby violating the privacy and security considerations of this effort. James > * Anders Kristensen favored #4 and #5 as being more consistent > with typical SIP header field syntax. > * John Elwell expressed a preference for #4, although was > willing to accept #1. > >That's not enough feedback to really inform consensus. > >As an aside, options #1 and #4 contravene the later consensus >expressed by the working group to allow an arbitrary number of >location values; both options #1 and #4 enforce a 2-value maximum. >Options #2 and #5 are effectively variations on #1 and #4 without >such restrictions. > >In practice, there are really two issues to resolve here, and we >should consider them separately: > > >1. If there are multiple location values in a SIP message, are they: > > (a) Required to appear in a single Geolocation header field, or > > (b) Allowed to appear in a single Geolocation header field, but > permitted to appear in their own Geolocation header fields? > >[No one has yet suggested that they be forced to appear each in their >own header field, so I'm not listing that as an option] > > >2. Does the "routing allowed" flag: > > (a) Appear as a *field* in a Geolocation header field > (e.g., "Geolocation: , routing-allowed=yes"), or > > (b) Appear as its own header field > (e.g., "Geolocation-Routing: yes") > > >Please weigh in with opinions on these two choices. Be sure to give >the rationale, however brief it might be, for your decision in your response. > >/a >_______________________________________________ >sipcore mailing list >sipcore@ietf.org >https://www.ietf.org/mailman/listinfo/sipcore From Martin.Thomson@andrew.com Thu Feb 3 14:05:32 2011 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 586FB3A6B0E for ; Thu, 3 Feb 2011 14:05:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.545 X-Spam-Level: X-Spam-Status: No, score=-2.545 tagged_above=-999 required=5 tests=[AWL=0.054, 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 qPBdHQOXoOoR for ; Thu, 3 Feb 2011 14:05:31 -0800 (PST) Received: from csmailgw2.commscope.com (csmailgw2.commscope.com [198.135.207.242]) by core3.amsl.com (Postfix) with ESMTP id 5A7DB3A6B03 for ; Thu, 3 Feb 2011 14:05:31 -0800 (PST) Received: from [10.86.20.103] ([10.86.20.103]:4155 "EHLO ACDCE7HC2.commscope.com") by csmailgw2.commscope.com with ESMTP id S542630Ab1BCWIv (ORCPT ); Thu, 3 Feb 2011 16:08:51 -0600 Received: from SISPE7HC1.commscope.com (10.97.4.12) by ACDCE7HC2.commscope.com (10.86.20.103) with Microsoft SMTP Server (TLS) id 8.3.137.0; Thu, 3 Feb 2011 16:08:51 -0600 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC1.commscope.com ([fe80::8a9:4724:f6bb:3cdf%10]) with mapi; Fri, 4 Feb 2011 06:08:46 +0800 From: "Thomson, Martin" To: SIPCORE Chairs , "SIPCORE (Session Initiation Protocol Core) WG" Date: Fri, 4 Feb 2011 06:08:42 +0800 Thread-Topic: [sipcore] Call for Consensus: Location Conveyance Syntax Thread-Index: AcvD3N/qGRCejuwET6ebCvIDvxYeSgAEC6CA Message-ID: <8B0A9FCBB9832F43971E38010638454F03FEA1538E@SISPE7MB1.commscope.com> References: <4D4B08F8.4040502@nostrum.com> In-Reply-To: <4D4B08F8.4040502@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-BCN: Meridius 1000 Version 3.4 on csmailgw2.commscope.com X-BCN-Sender: Martin.Thomson@andrew.com Subject: Re: [sipcore] Call for Consensus: Location Conveyance Syntax 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, 03 Feb 2011 22:05:32 -0000 T24gMS4gKGEpIE5vdGhpbmcgbW9yZSB0aGFuIHByZWZlcmVuY2U7IEkgaGF2ZSBpbnN1ZmZpY2ll bnQga25vd2xlZGdlIG9mIG90aGVyIFNJUCBoZWFkZXJzIHRvIGRlY2lkZSBiYXNlZCBvbiB0aGUg YmFzaXMgb2YgcHJlY2VkZW50L2NvbnNpc3RlbmN5LCB3aGljaCBpcyB3aGVyZSBJIHdvdWxkIGxv b2sgd2hlbiBldmVyeXRoaW5nIGVsc2UgaXMgZXF1YWwuDQoNCkV4cGVyaWVuY2Ugd2l0aCBIVFRQ IHN1Z2dlc3RzIHRoYXQgbXVsdGlwbGUgaGVhZGVycyB3aXRoIGRpZmZlcmVudCB2YWx1ZXMgaXMg U1RST05HTFkgZGlzY291cmFnZWQgYmVjYXVzZSBpdCBjYXVzZXMgaW50ZXJvcCBmYWlsdXJlcy4g IChJIGFja25vd2xlZGdlIHRoYXQgdGhpcyBpcyBhIHN1cGVyZmljaWFsIGFyZ3VtZW50IHdoZW4g d2UgY29uc2lkZXIgdGhlIGZhY3QgdGhhdCB3ZSdyZSBpbnZpdGluZyBpbnRlcm9wIGZhaWx1cmUg anVzdCBieSBhbGxvd2luZyBtdWx0aXBsZSB2YWx1ZXMpLg0KDQpPbiAyLiAoYSkgUm91dGluZyBh bGxvd2VkIGluIHRoZSBzYW1lIGhlYWRlciBrZWVwcyByZWxldmFudCBpbmZvcm1hdGlvbiB0b2dl dGhlci4gIFRoZSByb3V0aW5nLWFsbG93ZWQgZmxhZyBpcyBhbiBhdHRyaWJ1dGUgb2YgdGhlIGlu Zm9ybWF0aW9uIGJlaW5nIGNvbnZleWVkLiAgVGhhdCdzIGVxdWFsbHkgdHJ1ZSBmb3IgMCwgMSwg MiBvciAzMDAgbG9jYXRpb24gdmFsdWVzLiAgSW4gdGhpcywgSSBhZ3JlZSB3aXRoIEphbWVzLg0K DQpPbiBtdWx0aXBsaWNpdHk6ICMyIGFuZCAjNSBhcmUgcHJlZmVycmVkIHRvICMxIGFuZCAjNCBi YXNlZCBvbiB3aGF0IHdlJ3ZlIGFscmVhZHkgZGlzY3Vzc2VkLg0KDQotLU1hcnRpbg0KDQpPbiAy MDExLTAyLTA0IGF0IDA2OjU4OjQ4LCBBZGFtIFJvYWNoIC0gU0lQQ09SRSBDaGFpciB3cm90ZToN Cj4gW2FzIGNoYWlyXQ0KPiANCj4gV2l0aCB0aGUgY2hhbmdlcyBhcm91bmQgb3JkaW5hbGl0eSBv ZiBHZW9sb2NhdGlvbiB2YWx1ZXMgaW4gU0lQDQo+IG1lc3NhZ2VzLCB0aGVyZSB3ZXJlIGEgaGFu ZGZ1bCBvZiBjaGFuZ2VzIG1hZGUgYW5kL29yIHN1Z2dlc3RlZCB0byB0aGUNCj4gR2VvbG9jYXRp b24gaGVhZGVyIGZpZWxkIHN5bnRheC4NCj4gDQo+IEJhY2sgaW4gT2N0b2JlciwgUGF1bCBLeXpp dmF0IHN1Z2dlc3RlZCBmaXZlIGNvbmNyZXRlIEFCTkYgcHJvcG9zYWxzLg0KPiBUaGV5IGFwcGVh ciBuZWFyIHRoZSBib3R0b20gb2YgdGhpcyBtZXNzYWdlOg0KPiANCj4gaHR0cDovL3d3dy5pZXRm Lm9yZy9tYWlsLWFyY2hpdmUvd2ViL3NpcGNvcmUvY3VycmVudC9tc2cwMzU5NC5odG1sDQo+IA0K PiANCj4gDQo+ICoJSmFtZXMgUG9sayBzcG9rZSBpbiBmYXZvciBvZiBwdXJzdWluZyBvcHRpb24g IzEsIGxhcmdlbHkgYmVjYXVzZQ0KPiBpdCBpcyBjbG9zZXN0IHRvIHRoZSBjdXJyZW50IHN5bnRh eC4NCj4gKglBbmRlcnMgS3Jpc3RlbnNlbiBmYXZvcmVkICM0IGFuZCAjNSBhcyBiZWluZyBtb3Jl IGNvbnNpc3RlbnQNCj4gd2l0aCB0eXBpY2FsIFNJUCBoZWFkZXIgZmllbGQgc3ludGF4Lg0KPiAq CUpvaG4gRWx3ZWxsIGV4cHJlc3NlZCBhIHByZWZlcmVuY2UgZm9yICM0LCBhbHRob3VnaCB3YXMg d2lsbGluZw0KPiB0byBhY2NlcHQgIzEuDQo+IA0KPiANCj4gVGhhdCdzIG5vdCBlbm91Z2ggZmVl ZGJhY2sgdG8gcmVhbGx5IGluZm9ybSBjb25zZW5zdXMuDQo+IA0KPiBBcyBhbiBhc2lkZSwgb3B0 aW9ucyAjMSBhbmQgIzQgY29udHJhdmVuZSB0aGUgbGF0ZXIgY29uc2Vuc3VzIGV4cHJlc3NlZA0K PiBieSB0aGUgd29ya2luZyBncm91cCB0byBhbGxvdyBhbiBhcmJpdHJhcnkgbnVtYmVyIG9mIGxv Y2F0aW9uIHZhbHVlczsNCj4gYm90aCBvcHRpb25zICMxIGFuZCAjNCBlbmZvcmNlIGEgMi12YWx1 ZSBtYXhpbXVtLiBPcHRpb25zICMyIGFuZCAjNSBhcmUNCj4gZWZmZWN0aXZlbHkgdmFyaWF0aW9u cyBvbiAjMSBhbmQgIzQgd2l0aG91dCBzdWNoIHJlc3RyaWN0aW9ucy4NCj4gDQo+IEluIHByYWN0 aWNlLCB0aGVyZSBhcmUgcmVhbGx5IHR3byBpc3N1ZXMgdG8gcmVzb2x2ZSBoZXJlLCBhbmQgd2Ug c2hvdWxkDQo+IGNvbnNpZGVyIHRoZW0gc2VwYXJhdGVseToNCj4gDQo+IA0KPiAxLiBJZiB0aGVy ZSBhcmUgbXVsdGlwbGUgbG9jYXRpb24gdmFsdWVzIGluIGEgU0lQIG1lc3NhZ2UsIGFyZSB0aGV5 Og0KPiANCj4gICAgKGEpIFJlcXVpcmVkIHRvIGFwcGVhciBpbiBhIHNpbmdsZSBHZW9sb2NhdGlv biBoZWFkZXIgZmllbGQsIG9yDQo+IA0KPiAgICAoYikgQWxsb3dlZCB0byBhcHBlYXIgaW4gYSBz aW5nbGUgR2VvbG9jYXRpb24gaGVhZGVyIGZpZWxkLCBidXQNCj4gICAgICAgIHBlcm1pdHRlZCB0 byBhcHBlYXIgaW4gdGhlaXIgb3duIEdlb2xvY2F0aW9uIGhlYWRlciBmaWVsZHM/DQo+IA0KPiBb Tm8gb25lIGhhcyB5ZXQgc3VnZ2VzdGVkIHRoYXQgdGhleSBiZSBmb3JjZWQgdG8gYXBwZWFyIGVh Y2ggaW4gdGhlaXINCj4gb3duIGhlYWRlciBmaWVsZCwgc28gSSdtIG5vdCBsaXN0aW5nIHRoYXQg YXMgYW4gb3B0aW9uXQ0KPiANCj4gDQo+IDIuIERvZXMgdGhlICJyb3V0aW5nIGFsbG93ZWQiIGZs YWc6DQo+IA0KPiAgICAoYSkgQXBwZWFyIGFzIGEgKmZpZWxkKiBpbiBhIEdlb2xvY2F0aW9uIGhl YWRlciBmaWVsZA0KPiAgICAgICAgKGUuZy4sICJHZW9sb2NhdGlvbjogPHNpcDouLi4+IDxzaXA6 Li4uPiAsIHJvdXRpbmctDQo+IGFsbG93ZWQ9eWVzIiksDQo+IG9yDQo+IA0KPiAgICAoYikgQXBw ZWFyIGFzIGl0cyBvd24gaGVhZGVyIGZpZWxkDQo+ICAgICAgICAoZS5nLiwgIkdlb2xvY2F0aW9u LVJvdXRpbmc6IHllcyIpDQo+IA0KPiANCj4gUGxlYXNlIHdlaWdoIGluIHdpdGggb3BpbmlvbnMg b24gdGhlc2UgdHdvIGNob2ljZXMuIEJlIHN1cmUgdG8gZ2l2ZSB0aGUNCj4gcmF0aW9uYWxlLCBo b3dldmVyIGJyaWVmIGl0IG1pZ2h0IGJlLCBmb3IgeW91ciBkZWNpc2lvbiBpbiB5b3VyDQo+IHJl c3BvbnNlLg0KPiANCj4gL2ENCg0KDQoNCg== From pkyzivat@cisco.com Thu Feb 3 14:42:49 2011 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 C82023A6B22 for ; Thu, 3 Feb 2011 14:42:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.471 X-Spam-Level: X-Spam-Status: No, score=-110.471 tagged_above=-999 required=5 tests=[AWL=0.128, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 H7jaUbkF741U for ; Thu, 3 Feb 2011 14:42:49 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id F26B63A6B16 for ; Thu, 3 Feb 2011 14:42:48 -0800 (PST) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Au4FADK/Sk1AZnwN/2dsb2JhbACXEI4mc6IMmwSFWASEeYZtgy0 Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 03 Feb 2011 22:46:12 +0000 Received: from [161.44.174.114] (dhcp-161-44-174-114.cisco.com [161.44.174.114]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id p13MkC8w005328 for ; Thu, 3 Feb 2011 22:46:12 GMT Message-ID: <4D4B3034.1000508@cisco.com> Date: Thu, 03 Feb 2011 17:46:12 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: sipcore@ietf.org References: <4D4B08F8.4040502@nostrum.com> In-Reply-To: <4D4B08F8.4040502@nostrum.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [sipcore] Call for Consensus: Location Conveyance Syntax 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, 03 Feb 2011 22:42:49 -0000 (as participant, not chair): On 2/3/2011 2:58 PM, Adam Roach - SIPCORE Chair wrote: > 1. If there are multiple location values in a SIP message, are they: > > (a) Required to appear in a single Geolocation header field, or > > (b) Allowed to appear in a single Geolocation header field, but > permitted to appear in their own Geolocation header fields? > > [No one has yet suggested that they be forced to appear each in their > own header field, so I'm not listing that as an option] Requiring them to appear in a single header field is "weird" from a sip syntax perspective. > 2. Does the "routing allowed" flag: > > (a) Appear as a *field* in a Geolocation header field > (e.g., "Geolocation: , routing-allowed=yes"), or > > (b) Appear as its own header field > (e.g., "Geolocation-Routing: yes") Combining these into a single header field is again "weird". It will complicate parsers, which otherwise could use standard patterns. Because of that I prefer option (5). That will simplify parsing, and will allow dropping an additional location into a message without messing with the existing header fields. I don't find the argument compelling that separately searching for the routing allowed header is hard. Obviously this depends on the details of your stack, but in my experience this ought to be *easier* than the alternative. Thanks, Paul From Martin.Thomson@andrew.com Thu Feb 3 15:20:45 2011 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 E0F553A6A17 for ; Thu, 3 Feb 2011 15:20:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.546 X-Spam-Level: X-Spam-Status: No, score=-2.546 tagged_above=-999 required=5 tests=[AWL=0.053, 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 uAShK3-LqrNd for ; Thu, 3 Feb 2011 15:20:45 -0800 (PST) Received: from csmailgw1.commscope.com (csmailgw1.commscope.com [198.135.207.244]) by core3.amsl.com (Postfix) with ESMTP id EC5203A687A for ; Thu, 3 Feb 2011 15:20:44 -0800 (PST) Received: from [10.86.20.102] ([10.86.20.102]:65417 "EHLO ACDCE7HC1.commscope.com") by csmailgw1.commscope.com with ESMTP id S42321941Ab1BCXYI (ORCPT ); Thu, 3 Feb 2011 17:24:08 -0600 Received: from SISPE7HC2.commscope.com (10.97.4.13) by ACDCE7HC1.commscope.com (10.86.20.102) with Microsoft SMTP Server (TLS) id 8.3.137.0; Thu, 3 Feb 2011 17:24:08 -0600 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC2.commscope.com ([fe80::58c3:2447:f977:57c3%10]) with mapi; Fri, 4 Feb 2011 07:24:04 +0800 From: "Thomson, Martin" To: Paul Kyzivat , "sipcore@ietf.org" Date: Fri, 4 Feb 2011 07:24:02 +0800 Thread-Topic: [sipcore] Call for Consensus: Location Conveyance Syntax Thread-Index: AcvD9DotmCmzPPVCTG6mro6Eqio9kwABMgRA Message-ID: <8B0A9FCBB9832F43971E38010638454F03FEA153A2@SISPE7MB1.commscope.com> References: <4D4B08F8.4040502@nostrum.com> <4D4B3034.1000508@cisco.com> In-Reply-To: <4D4B3034.1000508@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="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-BCN: Meridius 1000 Version 3.4 on csmailgw1.commscope.com X-BCN-Sender: Martin.Thomson@andrew.com Subject: Re: [sipcore] Call for Consensus: Location Conveyance Syntax 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, 03 Feb 2011 23:20:46 -0000 SSBzaG91bGQgcG9pbnQgb3V0IHRoYXQgdGhpcyBzb3J0IG9mIGZlZWRiYWNrIGlzIHByb2JhYmx5 IG9mIG1vcmUgdXNlIHRoYW4gbXkgaW50dWl0aW9uLiAgSSBkb24ndCBoYXZlIGEgc3Ryb25nIGlu dmVzdG1lbnQgaW4gdGhpcy4gIElmIHdoYXQgUGF1bCBzdWdnZXN0cyBtYWtlcyBpdCBlYXNpZXIg dG8gaW1wbGVtZW50LCB0aGVuIEknbSBhbGwgZm9yIHRoYXQuDQoNCkJUVywgdGhhdCB3b3VsZG4n dCBiZSAjNSwgdGhhdCB3b3VsZCBiZSB0aGUgc2ltcGxlciBjaGlsZCBvZiAjNSB0aGF0IGhhcyBq dXN0IG9uZSBsb2NhdGlvblZhbHVlIGluIHRoZSBoZWFkZXIuDQoNCi0tTWFydGluDQoNCk9uIDIw MTEtMDItMDQgYXQgMDk6NDY6MTIsIFBhdWwgS3l6aXZhdCB3cm90ZToNCj4gKGFzIHBhcnRpY2lw YW50LCBub3QgY2hhaXIpOg0KPiANCj4gT24gMi8zLzIwMTEgMjo1OCBQTSwgQWRhbSBSb2FjaCAt IFNJUENPUkUgQ2hhaXIgd3JvdGU6DQo+IA0KPiA+IDEuIElmIHRoZXJlIGFyZSBtdWx0aXBsZSBs b2NhdGlvbiB2YWx1ZXMgaW4gYSBTSVAgbWVzc2FnZSwgYXJlIHRoZXk6DQo+ID4NCj4gPiAoYSkg UmVxdWlyZWQgdG8gYXBwZWFyIGluIGEgc2luZ2xlIEdlb2xvY2F0aW9uIGhlYWRlciBmaWVsZCwg b3INCj4gPg0KPiA+IChiKSBBbGxvd2VkIHRvIGFwcGVhciBpbiBhIHNpbmdsZSBHZW9sb2NhdGlv biBoZWFkZXIgZmllbGQsIGJ1dA0KPiA+IHBlcm1pdHRlZCB0byBhcHBlYXIgaW4gdGhlaXIgb3du IEdlb2xvY2F0aW9uIGhlYWRlciBmaWVsZHM/DQo+ID4NCj4gPiBbTm8gb25lIGhhcyB5ZXQgc3Vn Z2VzdGVkIHRoYXQgdGhleSBiZSBmb3JjZWQgdG8gYXBwZWFyIGVhY2ggaW4gdGhlaXINCj4gPiBv d24gaGVhZGVyIGZpZWxkLCBzbyBJJ20gbm90IGxpc3RpbmcgdGhhdCBhcyBhbiBvcHRpb25dDQo+ IA0KPiBSZXF1aXJpbmcgdGhlbSB0byBhcHBlYXIgaW4gYSBzaW5nbGUgaGVhZGVyIGZpZWxkIGlz ICJ3ZWlyZCIgZnJvbSBhIHNpcA0KPiBzeW50YXggcGVyc3BlY3RpdmUuDQo+IA0KPiA+IDIuIERv ZXMgdGhlICJyb3V0aW5nIGFsbG93ZWQiIGZsYWc6DQo+ID4NCj4gPiAoYSkgQXBwZWFyIGFzIGEg KmZpZWxkKiBpbiBhIEdlb2xvY2F0aW9uIGhlYWRlciBmaWVsZA0KPiA+IChlLmcuLCAiR2VvbG9j YXRpb246IDxzaXA6Li4uPiwgcm91dGluZy1hbGxvd2VkPXllcyIpLCBvcg0KPiA+DQo+ID4gKGIp IEFwcGVhciBhcyBpdHMgb3duIGhlYWRlciBmaWVsZA0KPiA+IChlLmcuLCAiR2VvbG9jYXRpb24t Um91dGluZzogeWVzIikNCj4gDQo+IENvbWJpbmluZyB0aGVzZSBpbnRvIGEgc2luZ2xlIGhlYWRl ciBmaWVsZCBpcyBhZ2FpbiAid2VpcmQiLg0KPiBJdCB3aWxsIGNvbXBsaWNhdGUgcGFyc2Vycywg d2hpY2ggb3RoZXJ3aXNlIGNvdWxkIHVzZSBzdGFuZGFyZA0KPiBwYXR0ZXJucy4NCj4gDQo+IEJl Y2F1c2Ugb2YgdGhhdCBJIHByZWZlciBvcHRpb24gKDUpLiBUaGF0IHdpbGwgc2ltcGxpZnkgcGFy c2luZywgYW5kDQo+IHdpbGwgYWxsb3cgZHJvcHBpbmcgYW4gYWRkaXRpb25hbCBsb2NhdGlvbiBp bnRvIGEgbWVzc2FnZSB3aXRob3V0DQo+IG1lc3Npbmcgd2l0aCB0aGUgZXhpc3RpbmcgaGVhZGVy IGZpZWxkcy4NCj4gDQo+IEkgZG9uJ3QgZmluZCB0aGUgYXJndW1lbnQgY29tcGVsbGluZyB0aGF0 IHNlcGFyYXRlbHkgc2VhcmNoaW5nIGZvciB0aGUNCj4gcm91dGluZyBhbGxvd2VkIGhlYWRlciBp cyBoYXJkLiBPYnZpb3VzbHkgdGhpcyBkZXBlbmRzIG9uIHRoZSBkZXRhaWxzDQo+IG9mDQo+IHlv dXIgc3RhY2ssIGJ1dCBpbiBteSBleHBlcmllbmNlIHRoaXMgb3VnaHQgdG8gYmUgKmVhc2llciog dGhhbiB0aGUNCj4gYWx0ZXJuYXRpdmUuDQo+IA0KPiAJVGhhbmtzLA0KPiAJUGF1bA0KPiBfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBzaXBjb3JlIG1h aWxpbmcgbGlzdA0KPiBzaXBjb3JlQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vc2lwY29yZQ0KDQoNCg== From adam@nostrum.com Thu Feb 3 15:30:16 2011 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 08FED3A69DF for ; Thu, 3 Feb 2011 15:30:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.524 X-Spam-Level: X-Spam-Status: No, score=-102.524 tagged_above=-999 required=5 tests=[AWL=0.076, BAYES_00=-2.599, SPF_PASS=-0.001, 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 ogTgX4+INRWy for ; Thu, 3 Feb 2011 15:30:13 -0800 (PST) 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 351DD3A687A for ; Thu, 3 Feb 2011 15:30:12 -0800 (PST) Received: from dn3-228.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 p13NXX6a061683 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Thu, 3 Feb 2011 17:33:33 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <4D4B3B4D.6020606@nostrum.com> Date: Thu, 03 Feb 2011 17:33:33 -0600 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: "Thomson, Martin" References: <4D4B08F8.4040502@nostrum.com> <4D4B3034.1000508@cisco.com> <8B0A9FCBB9832F43971E38010638454F03FEA153A2@SISPE7MB1.commscope.com> In-Reply-To: <8B0A9FCBB9832F43971E38010638454F03FEA153A2@SISPE7MB1.commscope.com> 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: "sipcore@ietf.org" Subject: Re: [sipcore] Call for Consensus: Location Conveyance Syntax 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, 03 Feb 2011 23:30:16 -0000 (as an individual) No, it would be #5. There's a difference between "Allowed to appear in a single Geolocation header field, but permitted to appear in their own Geolocation header fields" and "Forced to appear in their own Geolocation header fields." Having worked on several different SIP stacks, I can say that #5 would be, far and away, the easiest thing to implement. I'd re-use the same parser for "Gelocation" as I do for the myriad other header fields that contain one or more URIs, and then put in another very simple parser type for the "Geolocation-Routing" header field. Under this scheme, it would be very easy for intermediaries who might make routing decisions based on location information to first look for the "Geolocation-Routing" header field. If it's "no" (or absent), they stop, do not pass "Go," do not collect $200, and don't even dream of parsing through the "Geolocation" header field. It it's "Yes," they parse "Geolocation" and go about doing their location logic. Pretty clean, if you ask me. /a On 2/3/11 5:24 PM, Thomson, Martin wrote: > I should point out that this sort of feedback is probably of more use than my intuition. I don't have a strong investment in this. If what Paul suggests makes it easier to implement, then I'm all for that. > > BTW, that wouldn't be #5, that would be the simpler child of #5 that has just one locationValue in the header. > > --Martin > > On 2011-02-04 at 09:46:12, Paul Kyzivat wrote: >> (as participant, not chair): >> >> On 2/3/2011 2:58 PM, Adam Roach - SIPCORE Chair wrote: >> >>> 1. If there are multiple location values in a SIP message, are they: >>> >>> (a) Required to appear in a single Geolocation header field, or >>> >>> (b) Allowed to appear in a single Geolocation header field, but >>> permitted to appear in their own Geolocation header fields? >>> >>> [No one has yet suggested that they be forced to appear each in their >>> own header field, so I'm not listing that as an option] >> Requiring them to appear in a single header field is "weird" from a sip >> syntax perspective. >> >>> 2. Does the "routing allowed" flag: >>> >>> (a) Appear as a *field* in a Geolocation header field >>> (e.g., "Geolocation:, routing-allowed=yes"), or >>> >>> (b) Appear as its own header field >>> (e.g., "Geolocation-Routing: yes") >> Combining these into a single header field is again "weird". >> It will complicate parsers, which otherwise could use standard >> patterns. >> >> Because of that I prefer option (5). That will simplify parsing, and >> will allow dropping an additional location into a message without >> messing with the existing header fields. >> >> I don't find the argument compelling that separately searching for the >> routing allowed header is hard. Obviously this depends on the details >> of >> your stack, but in my experience this ought to be *easier* than the >> alternative. >> >> Thanks, >> Paul >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From rbarnes@bbn.com Thu Feb 3 17:47:43 2011 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 71F8C3A68E7 for ; Thu, 3 Feb 2011 17:47:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.504 X-Spam-Level: X-Spam-Status: No, score=-102.504 tagged_above=-999 required=5 tests=[AWL=0.095, BAYES_00=-2.599, 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 sCtq5IsWTSYa for ; Thu, 3 Feb 2011 17:47:42 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id 66A1A3A6A01 for ; Thu, 3 Feb 2011 17:47:42 -0800 (PST) Received: from [128.89.252.202] (port=54140 helo=[192.168.1.16]) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.74 (FreeBSD)) (envelope-from ) id 1PlApF-000Lok-5U; Thu, 03 Feb 2011 20:51:05 -0500 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: "Richard L. Barnes" In-Reply-To: <4D4B3B4D.6020606@nostrum.com> Date: Thu, 3 Feb 2011 20:51:00 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <18B5AC23-6E82-43CE-A608-D183914ABD5D@bbn.com> References: <4D4B08F8.4040502@nostrum.com> <4D4B3034.1000508@cisco.com> <8B0A9FCBB9832F43971E38010638454F03FEA153A2@SISPE7MB1.commscope.com> <4D4B3B4D.6020606@nostrum.com> To: Adam Roach X-Mailer: Apple Mail (2.1082) Cc: "sipcore@ietf.org" , "Thomson, Martin" Subject: Re: [sipcore] Call for Consensus: Location Conveyance Syntax 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, 04 Feb 2011 01:47:43 -0000 +1 Like Martin, I don't much care what color this bikeshed is, but Adam's = argument seems pretty cogent to me. =20 Maybe just one tiny addendum to the parsing logic: If I were writing the = parser, I would probably just read straight through the headers, = possibly hitting the Geolocation before the Geolocation-Routing. So it = might not just be "no =3D> don't parse", but "no =3D> don't parse || = seek&destroy". This has absolutely no relevance to the syntax, of = course. --Richard On Feb 3, 2011, at 6:33 PM, Adam Roach wrote: > (as an individual) >=20 > No, it would be #5. There's a difference between "Allowed to appear in = a single Geolocation header field, but permitted to appear in their own = Geolocation header fields" and "Forced to appear in their own = Geolocation header fields." >=20 > Having worked on several different SIP stacks, I can say that #5 would = be, far and away, the easiest thing to implement. I'd re-use the same = parser for "Gelocation" as I do for the myriad other header fields that = contain one or more URIs, and then put in another very simple parser = type for the "Geolocation-Routing" header field. >=20 > Under this scheme, it would be very easy for intermediaries who might = make routing decisions based on location information to first look for = the "Geolocation-Routing" header field. If it's "no" (or absent), they = stop, do not pass "Go," do not collect $200, and don't even dream of = parsing through the "Geolocation" header field. It it's "Yes," they = parse "Geolocation" and go about doing their location logic. >=20 > Pretty clean, if you ask me. >=20 > /a >=20 > On 2/3/11 5:24 PM, Thomson, Martin wrote: >> I should point out that this sort of feedback is probably of more use = than my intuition. I don't have a strong investment in this. If what = Paul suggests makes it easier to implement, then I'm all for that. >>=20 >> BTW, that wouldn't be #5, that would be the simpler child of #5 that = has just one locationValue in the header. >>=20 >> --Martin >>=20 >> On 2011-02-04 at 09:46:12, Paul Kyzivat wrote: >>> (as participant, not chair): >>>=20 >>> On 2/3/2011 2:58 PM, Adam Roach - SIPCORE Chair wrote: >>>=20 >>>> 1. If there are multiple location values in a SIP message, are = they: >>>>=20 >>>> (a) Required to appear in a single Geolocation header field, or >>>>=20 >>>> (b) Allowed to appear in a single Geolocation header field, but >>>> permitted to appear in their own Geolocation header fields? >>>>=20 >>>> [No one has yet suggested that they be forced to appear each in = their >>>> own header field, so I'm not listing that as an option] >>> Requiring them to appear in a single header field is "weird" from a = sip >>> syntax perspective. >>>=20 >>>> 2. Does the "routing allowed" flag: >>>>=20 >>>> (a) Appear as a *field* in a Geolocation header field >>>> (e.g., "Geolocation:, routing-allowed=3Dyes"), or >>>>=20 >>>> (b) Appear as its own header field >>>> (e.g., "Geolocation-Routing: yes") >>> Combining these into a single header field is again "weird". >>> It will complicate parsers, which otherwise could use standard >>> patterns. >>>=20 >>> Because of that I prefer option (5). That will simplify parsing, and >>> will allow dropping an additional location into a message without >>> messing with the existing header fields. >>>=20 >>> I don't find the argument compelling that separately searching for = the >>> routing allowed header is hard. Obviously this depends on the = details >>> of >>> your stack, but in my experience this ought to be *easier* than the >>> alternative. >>>=20 >>> Thanks, >>> Paul >>> _______________________________________________ >>> sipcore mailing list >>> sipcore@ietf.org >>> https://www.ietf.org/mailman/listinfo/sipcore >>=20 >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From frankwmiller@frankwmiller.net Sun Feb 6 10:20:03 2011 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 BDC653A6966 for ; Sun, 6 Feb 2011 10:20:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.089 X-Spam-Level: X-Spam-Status: No, score=-2.089 tagged_above=-999 required=5 tests=[AWL=0.510, 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 OZFAxm16XuCu for ; Sun, 6 Feb 2011 10:20:03 -0800 (PST) Received: from smtpauth02.csee.onr.siteprotect.com (smtpauth02.csee.onr.siteprotect.com [64.26.60.136]) by core3.amsl.com (Postfix) with ESMTP id D228F3A6949 for ; Sun, 6 Feb 2011 10:20:02 -0800 (PST) Received: from FrankWMillerPC (unknown [174.51.92.116]) (Authenticated sender: frankwmiller@frankwmiller.net) by smtpauth02.csee.onr.siteprotect.com (Postfix) with ESMTPA id 015E8E38019 for ; Sun, 6 Feb 2011 12:01:40 -0600 (CST) From: "Frank W. Miller" To: Date: Sun, 6 Feb 2011 11:13:43 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcvGKZbY5yrTOEdsSX+NJwjvZDQTEw== X-MimeOLE: Produced By Microsoft MimeOLE V6.1.7600.16543 Message-Id: <20110206180141.015E8E38019@smtpauth02.csee.onr.siteprotect.com> Subject: [sipcore] SIP standards compilation 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: Sun, 06 Feb 2011 18:20:03 -0000 Greetings, Been awhile since I haunted this list... Was wondering, a few years ago Jonathan started a draft that compiled the various standards into a "Hitchhikers's Guide" of sorts. Did that work progress? Thanks, FM From frankwmiller@frankwmiller.net Sun Feb 6 10:25:29 2011 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 4B7CA3A693F for ; Sun, 6 Feb 2011 10:25:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.174 X-Spam-Level: X-Spam-Status: No, score=-2.174 tagged_above=-999 required=5 tests=[AWL=0.425, 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 Il9lAX6-fi7e for ; Sun, 6 Feb 2011 10:25:28 -0800 (PST) Received: from smtpauth02.csee.onr.siteprotect.com (smtpauth02.csee.onr.siteprotect.com [64.26.60.136]) by core3.amsl.com (Postfix) with ESMTP id 4D7563A6949 for ; Sun, 6 Feb 2011 10:25:28 -0800 (PST) Received: from FrankWMillerPC (unknown [174.51.92.116]) (Authenticated sender: frankwmiller@frankwmiller.net) by smtpauth02.csee.onr.siteprotect.com (Postfix) with ESMTPA id 66EE3E38034 for ; Sun, 6 Feb 2011 12:07:06 -0600 (CST) From: "Frank W. Miller" To: In-Reply-To: <20110206180141.015E8E38019@smtpauth02.csee.onr.siteprotect.com> Date: Sun, 6 Feb 2011 11:19:09 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcvGKZbY5yrTOEdsSX+NJwjvZDQTEwAAGd4w X-MimeOLE: Produced By Microsoft MimeOLE V6.1.7600.16543 Message-Id: <20110206180706.66EE3E38034@smtpauth02.csee.onr.siteprotect.com> Subject: Re: [sipcore] SIP standards compilation 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: Sun, 06 Feb 2011 18:25:29 -0000 RFC 5411 I guess. This appears to be a couple years old now. Is there any plan to update it? Is that even necessary? Seems like the pace of standards development has plateaued somewhat. Sorry bout the extra email message. Thanks, FM > -----Original Message----- > From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behalf > Of Frank W. Miller > Sent: Sunday, February 06, 2011 11:14 AM > To: sipcore@ietf.org > Subject: [sipcore] SIP standards compilation > > > Greetings, > > Been awhile since I haunted this list... > > Was wondering, a few years ago Jonathan started a draft that compiled the > various standards into a "Hitchhikers's Guide" of sorts. Did that work > progress? > > Thanks, > FM > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From frankwmiller@frankwmiller.net Sun Feb 6 10:15:47 2011 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 541753A69B4 for ; Sun, 6 Feb 2011 10:15:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.463 X-Spam-Level: X-Spam-Status: No, score=-0.463 tagged_above=-999 required=5 tests=[AWL=0.277, BAYES_20=-0.74] 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 b2YKTWbofvVV for ; Sun, 6 Feb 2011 10:15:46 -0800 (PST) Received: from smtpauth02.csee.onr.siteprotect.com (smtpauth02.csee.onr.siteprotect.com [64.26.60.136]) by core3.amsl.com (Postfix) with ESMTP id A10EB3A6985 for ; Sun, 6 Feb 2011 10:15:46 -0800 (PST) Received: from FrankWMillerPC (unknown [174.51.92.116]) (Authenticated sender: frankwmiller@frankwmiller.net) by smtpauth02.csee.onr.siteprotect.com (Postfix) with ESMTPA id CA617E3801D for ; Sun, 6 Feb 2011 11:57:24 -0600 (CST) From: "Frank W. Miller" To: Date: Sun, 6 Feb 2011 11:09:27 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook, Build 11.0.5510 Thread-Index: AcvGKP4fmx+soK9+R76+Z5dcCX4ulg== X-MimeOLE: Produced By Microsoft MimeOLE V6.1.7600.16543 Message-Id: <20110206175724.CA617E3801D@smtpauth02.csee.onr.siteprotect.com> X-Mailman-Approved-At: Sun, 06 Feb 2011 17:15:19 -0800 Subject: [sipcore] SIP standards compilation 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: Sun, 06 Feb 2011 18:16:23 -0000 Greetings, Been awhile since I haunted this list... Was wondering, a few years ago Jonathan started a draft that compiled the various standards into a "Hitchhikers's Guide" of sorts. Did that work progress? Thanks, FM From iesg-secretary@ietf.org Mon Feb 7 09:02:51 2011 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 5E1463A6E25; Mon, 7 Feb 2011 09:02:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.553 X-Spam-Level: X-Spam-Status: No, score=-102.553 tagged_above=-999 required=5 tests=[AWL=0.046, BAYES_00=-2.599, 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 6MltBroVzuhz; Mon, 7 Feb 2011 09:02:50 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9502F3A6D6E; Mon, 7 Feb 2011 09:02:50 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 3.12 Message-ID: <20110207170250.4107.67897.idtracker@localhost> Date: Mon, 07 Feb 2011 09:02:50 -0800 Cc: sipcore@ietf.org Subject: [sipcore] Last Call: (Session Initiation Protocol (SIP) Response Code for Indication of Terminated Dialog) to Proposed Standard X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: ietf@ietf.org List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Feb 2011 17:02:51 -0000 The IESG has received a request from the Session Initiation Protocol Core WG (sipcore) to consider the following document: - 'Session Initiation Protocol (SIP) Response Code for Indication of Terminated Dialog' as a Proposed Standard This is the second IETF last call for this document. The previous last call was on version -02. While resolving review comments, an issue with the interaction of the 199 response and the 100rel extension was identified and addressed by the SIPCORE working group. A full summary of the changes are available in section 13 of the document. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2011-02-21. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This specification defines a new Session Initiation Protocol (SIP) response code, 199 Early Dialog Terminated, that a SIP forking proxy and a User Agent Server (UAS) can use to indicate towards upstream SIP entities (including the User Agent Client (UAC)) that an early dialog has been terminated, before a final response is sent towards the SIP entities. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-sipcore-199/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-sipcore-199/ No IPR declarations have been submitted directly on this I-D. From jmpolk@cisco.com Tue Feb 8 09:44:29 2011 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 3E1C93A67E7 for ; Tue, 8 Feb 2011 09:44:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 Coo2Zh+P1GMk for ; Tue, 8 Feb 2011 09:44:28 -0800 (PST) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 71A063A67AD for ; Tue, 8 Feb 2011 09:44:28 -0800 (PST) Authentication-Results: sj-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAK8PUU2rRN+J/2dsb2JhbAClM3OgM5s1hVoEhHs Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-1.cisco.com with ESMTP; 08 Feb 2011 17:44:35 +0000 Received: from jmpolk-wxp01.cisco.com (rcdn-jmpolk-8716.cisco.com [10.99.80.23]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id p18HiZMF005128; Tue, 8 Feb 2011 17:44:35 GMT Message-Id: <201102081744.p18HiZMF005128@sj-core-3.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 08 Feb 2011 11:44:34 -0600 To: "Thomson, Martin" , Adam Roach , SIPCORE From: "James M. Polk" In-Reply-To: <8B0A9FCBB9832F43971E38010638454F03FEA15300@SISPE7MB1.comms cope.com> References: <4D48A681.9080803@nostrum.com> <8B0A9FCBB9832F43971E38010638454F03FEA15300@SISPE7MB1.commscope.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [sipcore] Proposed location conveyance changes 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, 08 Feb 2011 17:44:29 -0000 Martin thanks for the comments. My responses are in-line At 06:39 PM 2/2/2011, Thomson, Martin wrote: >These look good to me. > >Some small suggestions below. > >On 2011-02-02 at 11:34:09, Adam Roach wrote: > > In section 3.2: > > need to be mindful of SIP's transaction timers. In particular, if > >Nit: possessive apostrophes on inanimate object are not good: >s/SIP's transaction timers/timers used by different transactions/ done > > In section 4.3: >... > > We have gone through the > > exercise of getting this correct for every scenario, and deemed it > > not worth the excruciating effort involved. > >Agree with John on this one: this is not necessary. removed > > There is no guidance given in this document as to which > > locationValue is formally errored (when more than one was present); > > meaning that, somehow not defined here, the LR just picks one to > > error. > >"errored" isn't in my dictionary. Suggest: > > There is no mechanism provided to indicate which of multiple > locationValues is in error. If all locationValues are in error, > the LR can select any locationValue for which to provide an error. I rewrote out the word errored before I noticed your suggested text. I think the new text says the same thing as what you suggest. > > It should be noted that for non-INVITE transactions, the SIP > > response will likely be sent before the dereference response has > > been received. At this time, this document does not alter that SIP > > protocol reality. This means that any non-INVITE response to a > > request containing location SHOULD NOT consider a 200 OK to mean the > > act of dereferencing has concluded and the dereferencer (i.e., the > > LR) has successfully parsed the PIDF-LO for errors and found none. > > This was first brought up in Section 3.2. > >I don't think that repeating this point is necessary or useful. I disagree, since the first mention of this is in the non-normative section 3. Repeating this point in a normative section matters. Only having this point in 1 of the sections loses context - so I disagree here. >The point that is important is that if the 200 is dependent on the >location, then you can send these responses; if the 200 is not, then >don't. For those cases where you can't dereference before the 200 >is sent, then the location had better not be necessary for the 200 to be sent. > >See Jon's email on the topic, i.e., "we should not try to build the >expected behavior of applications into the low-level protocol >building blocks"... I agree with both of you, and do not rebuild anything - just am using the opportunity in both sections to fill out points to be made. > > New section 4.5 (previously 4.6): >... > > The "geolocation-http" option tag signals support for acquiring > > location information via an HTTP ([RFC2616]). A location recipient > >Suggest a reference to draft-ietf-geopriv-deref-protocol in addition to 2616. > > > See (ID-GEO-FILTERS) for more details on dereferencing > location information. > >Or here. done here >Why does this reference use parentheses now, rather than brackets? oops, fixed. James >_______________________________________________ >sipcore mailing list >sipcore@ietf.org >https://www.ietf.org/mailman/listinfo/sipcore From Internet-Drafts@ietf.org Tue Feb 8 10:15:03 2011 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 0E9263A67B0; Tue, 8 Feb 2011 10:15:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 DIA-K4E1qJk0; Tue, 8 Feb 2011 10:15:02 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 179643A659C; Tue, 8 Feb 2011 10:15:02 -0800 (PST) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.12 Message-ID: <20110208181502.6865.6192.idtracker@localhost> Date: Tue, 08 Feb 2011 10:15:02 -0800 Cc: sipcore@ietf.org Subject: [sipcore] I-D Action:draft-ietf-sipcore-location-conveyance-05.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, 08 Feb 2011 18:15:03 -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 : Location Conveyance for the Session Initiation Protocol Author(s) : J. Polk, et al. Filename : draft-ietf-sipcore-location-conveyance-05.txt Pages : 27 Date : 2011-02-08 This document defines an extension to the Session Initiation Protocol (SIP) to convey geographic location information from one SIP entity to another SIP entity. The SIP extension covers end-to-end conveyance as well as location-based routing, where SIP intermediaries make routing decisions based upon the location of the Location Target. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sipcore-location-conveyance-05.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-location-conveyance-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-02-08100339.I-D@ietf.org> --NextPart-- From Internet-Drafts@ietf.org Wed Feb 9 14:30:08 2011 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 89B393A686A; Wed, 9 Feb 2011 14:30:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.541 X-Spam-Level: X-Spam-Status: No, score=-102.541 tagged_above=-999 required=5 tests=[AWL=0.058, BAYES_00=-2.599, 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 7NIm-HtOShNz; Wed, 9 Feb 2011 14:30:03 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E7D1B3A6849; Wed, 9 Feb 2011 14:30:02 -0800 (PST) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.12 Message-ID: <20110209223002.13285.89370.idtracker@localhost> Date: Wed, 09 Feb 2011 14:30:02 -0800 Cc: sipcore@ietf.org Subject: [sipcore] I-D Action:draft-ietf-sipcore-sec-flows-09.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, 09 Feb 2011 22:30:08 -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 : Example call flows using Session Initiation Protocol (SIP) security mechanisms Author(s) : C. Jennings, et al. Filename : draft-ietf-sipcore-sec-flows-09.txt Pages : 76 Date : 2011-02-09 This document shows example call flows demonstrating the use of Transport Layer Security (TLS), and Secure/Multipurpose Internet Mail Extensions (S/MIME) in Session Initiation Protocol (SIP). It also provides information that helps implementers build interoperable SIP software. To help facilitate interoperability testing, it includes certificates used in the example call flows and processes to create certificates for testing. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sipcore-sec-flows-09.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-sec-flows-09.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-02-09141831.I-D@ietf.org> --NextPart-- From adam@nostrum.com Thu Feb 10 15:18:00 2011 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 E460E3A6A63 for ; Thu, 10 Feb 2011 15:18:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YBfHuG28TYV3 for ; Thu, 10 Feb 2011 15:18:00 -0800 (PST) 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 928683A6849 for ; Thu, 10 Feb 2011 15:17:59 -0800 (PST) Received: from dn3-228.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 p1ANIAE8033781 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Thu, 10 Feb 2011 17:18:11 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <4D547232.7020704@nostrum.com> Date: Thu, 10 Feb 2011 17:18:10 -0600 From: Adam Roach - SIPCORE Chair User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: "SIPCORE (Session Initiation Protocol Core) WG" 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) Subject: [sipcore] Geolocation Call X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: SIPCORE Chairs List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 10 Feb 2011 23:18:01 -0000 The phone call today had exactly one topic of discussion: Syntax and semantics of the SIP header field or fields associated with geolocation conveyance. Of those on the call, there was unanimous agreement to go with what Paul characterized as "Option #5" in his earlier email on the topic. To summarize this option: * We will define a "Geolocation" header field, which can contain one or more location values. * A SIP message may contain zero or more Geolocation header fields. * We will define a "Geolocation-Routing" header field, which contains either "yes" or "no". * The "Geolocation-Routing" header field can appear at most once in a SIP message. * In the absence of a "Geolocation-Routing" header field, intermediaries are to assume a value of "no". The specific ANBF that defines these two header fields is: Geolocation-header = "Geolocation" HCOLON locationValue *( COMMA locationValue ) locationValue = LAQUOT locationURI RAQUOT *(SEMI geoloc-param) locationURI = sip-URI / sips-URI / pres-URI / http-URI / HTTPS-URI / cid-url ; (from RFC 2392) / absoluteURI ; (from RFC 3261) geoloc-param = generic-param; (from RFC 3261) Georouting-header = "Geolocation-Routing" HCOLON ( "yes" / "no" / gen-value ) From adam@nostrum.com Thu Feb 10 15:24:04 2011 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 E99F53A6AEC for ; Thu, 10 Feb 2011 15:24:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6dxYPDRQuKY6 for ; Thu, 10 Feb 2011 15:24:04 -0800 (PST) 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 588663A6AF9 for ; Thu, 10 Feb 2011 15:24:03 -0800 (PST) Received: from dn3-228.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 p1ANOE0w034327 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Thu, 10 Feb 2011 17:24:15 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <4D54739E.5030707@nostrum.com> Date: Thu, 10 Feb 2011 17:24:14 -0600 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: SIPCORE Chairs References: <4D547232.7020704@nostrum.com> In-Reply-To: <4D547232.7020704@nostrum.com> 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: "SIPCORE \(Session Initiation Protocol Core\) WG" Subject: Re: [sipcore] Geolocation Call 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, 10 Feb 2011 23:24:05 -0000 [as chair] Somehow, Thunderbird cut off the remainder of this message. It was supposed to continue after the ABNF with: If there are no objections to these changes on this mailing list, then the authors will produce a new version of the document early next week reflecting these decisions. The plan is to issue a two-week working group last call period immediately after publication. /a On 2/10/11 5:18 PM, Adam Roach - SIPCORE Chair wrote: > The phone call today had exactly one topic of discussion: Syntax and > semantics of the SIP header field or fields associated with > geolocation conveyance. > > Of those on the call, there was unanimous agreement to go with what > Paul characterized as "Option #5" in his earlier email on the topic. > To summarize this option: > > * We will define a "Geolocation" header field, which can contain one > or more location values. > * A SIP message may contain zero or more Geolocation header fields. > * We will define a "Geolocation-Routing" header field, which > contains either "yes" or "no". > * The "Geolocation-Routing" header field can appear at most once in > a SIP message. > * In the absence of a "Geolocation-Routing" header field, > intermediaries are to assume a value of "no". > > > The specific ANBF that defines these two header fields is: > > Geolocation-header = "Geolocation" HCOLON locationValue > *( COMMA locationValue ) > locationValue = LAQUOT locationURI RAQUOT > *(SEMI geoloc-param) > locationURI = sip-URI / sips-URI / pres-URI > / http-URI / HTTPS-URI > / cid-url ; (from RFC 2392) > / absoluteURI ; (from RFC 3261) > geoloc-param = generic-param; (from RFC 3261) > > Georouting-header = "Geolocation-Routing" HCOLON > ( "yes" / "no" / gen-value ) > > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From rbarnes@bbn.com Thu Feb 10 15:29:22 2011 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 C47733A6AFE for ; Thu, 10 Feb 2011 15:29:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.324 X-Spam-Level: X-Spam-Status: No, score=-102.324 tagged_above=-999 required=5 tests=[AWL=0.275, BAYES_00=-2.599, 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 XXEElK-sUXUd for ; Thu, 10 Feb 2011 15:29:20 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id 12EF73A6AEC for ; Thu, 10 Feb 2011 15:29:20 -0800 (PST) Received: from [128.89.252.254] (port=59045 helo=wl-dy-169-228-179-48.ucsd.edu) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.74 (FreeBSD)) (envelope-from ) id 1Pnfx6-000LOb-QY for sipcore@ietf.org; Thu, 10 Feb 2011 18:29:33 -0500 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1082) From: "Richard L. Barnes" In-Reply-To: <4D54739E.5030707@nostrum.com> Date: Thu, 10 Feb 2011 15:29:31 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4D547232.7020704@nostrum.com> <4D54739E.5030707@nostrum.com> To: "SIPCORE (Session Initiation Protocol Core) WG" X-Mailer: Apple Mail (2.1082) Subject: Re: [sipcore] Geolocation Call 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, 10 Feb 2011 23:29:22 -0000 This looks good to me. Onward! On Feb 10, 2011, at 3:24 PM, Adam Roach wrote: > [as chair] >=20 > Somehow, Thunderbird cut off the remainder of this message. It was = supposed to continue after the ABNF with: >=20 > If there are no objections to these changes on this mailing list, then = the authors will produce a new version of the document early next week = reflecting these decisions. The plan is to issue a two-week working = group last call period immediately after publication. >=20 > /a >=20 > On 2/10/11 5:18 PM, Adam Roach - SIPCORE Chair wrote: >> The phone call today had exactly one topic of discussion: Syntax and = semantics of the SIP header field or fields associated with geolocation = conveyance. >>=20 >> Of those on the call, there was unanimous agreement to go with what = Paul characterized as "Option #5" in his earlier email on the topic. To = summarize this option: >>=20 >> * We will define a "Geolocation" header field, which can contain = one >> or more location values. >> * A SIP message may contain zero or more Geolocation header fields. >> * We will define a "Geolocation-Routing" header field, which >> contains either "yes" or "no". >> * The "Geolocation-Routing" header field can appear at most once in >> a SIP message. >> * In the absence of a "Geolocation-Routing" header field, >> intermediaries are to assume a value of "no". >>=20 >>=20 >> The specific ANBF that defines these two header fields is: >>=20 >> Geolocation-header =3D "Geolocation" HCOLON locationValue=0B >> *( COMMA locationValue ) >> =0B locationValue =3D LAQUOT locationURI RAQUOT=0B >> *(SEMI geoloc-param)=0B >> locationURI =3D sip-URI / sips-URI / pres-URI >> =0B / http-URI / HTTPS-URI=0B >> / cid-url ; (from RFC 2392)=0B >> / absoluteURI ; (from RFC 3261) >> =0B geoloc-param =3D generic-param; (from RFC 3261) >>=20 >> Georouting-header =3D "Geolocation-Routing" HCOLON=0B >> ( "yes" / "no" / gen-value )=0B=0B >>=20 >>=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 Martin.Thomson@andrew.com Thu Feb 10 19:06:57 2011 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 CC4E83A682D for ; Thu, 10 Feb 2011 19:06:57 -0800 (PST) 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 VwqJpiPFftkj for ; Thu, 10 Feb 2011 19:06:57 -0800 (PST) Received: from csmailgw1.commscope.com (csmailgw1.commscope.com [198.135.207.244]) by core3.amsl.com (Postfix) with ESMTP id EDAA93A682B for ; Thu, 10 Feb 2011 19:06:56 -0800 (PST) Received: from [10.86.20.103] ([10.86.20.103]:22667 "EHLO ACDCE7HC2.commscope.com") by csmailgw1.commscope.com with ESMTP id S42630786Ab1BKDHK (ORCPT ); Thu, 10 Feb 2011 21:07:10 -0600 Received: from SISPE7HC2.commscope.com (10.97.4.13) by ACDCE7HC2.commscope.com (10.86.20.103) with Microsoft SMTP Server (TLS) id 8.3.137.0; Thu, 10 Feb 2011 21:07:10 -0600 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC2.commscope.com ([fe80::58c3:2447:f977:57c3%10]) with mapi; Fri, 11 Feb 2011 11:06:56 +0800 From: "Thomson, Martin" To: "Richard L. Barnes" , "SIPCORE (Session Initiation Protocol Core) WG" Date: Fri, 11 Feb 2011 11:06:52 +0800 Thread-Topic: [sipcore] Geolocation Call Thread-Index: AcvJemQdulAu+0cET1y9HPcf1X6+cQAHkuVQ Message-ID: <8B0A9FCBB9832F43971E38010638454F03FEB84E82@SISPE7MB1.commscope.com> References: <4D547232.7020704@nostrum.com> <4D54739E.5030707@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="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-BCN: Meridius 1000 Version 3.4 on csmailgw1.commscope.com X-BCN-Sender: Martin.Thomson@andrew.com Subject: Re: [sipcore] Geolocation Call 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, 11 Feb 2011 03:06:57 -0000 U2hpcCBpdC4NCg0KT24gMjAxMS0wMi0xMSBhdCAxMDoyOTozMSwgUmljaGFyZCBMLiBCYXJuZXMg d3JvdGU6DQo+IFRoaXMgbG9va3MgZ29vZCB0byBtZS4gIE9ud2FyZCENCj4gDQo+IE9uIEZlYiAx MCwgMjAxMSwgYXQgMzoyNCBQTSwgQWRhbSBSb2FjaCB3cm90ZToNCj4gDQo+ID4gW2FzIGNoYWly XQ0KPiA+DQo+ID4gU29tZWhvdywgVGh1bmRlcmJpcmQgY3V0IG9mZiB0aGUgcmVtYWluZGVyIG9m IHRoaXMgbWVzc2FnZS4gSXQgd2FzDQo+IHN1cHBvc2VkIHRvIGNvbnRpbnVlIGFmdGVyIHRoZSBB Qk5GIHdpdGg6DQo+ID4NCj4gPiBJZiB0aGVyZSBhcmUgbm8gb2JqZWN0aW9ucyB0byB0aGVzZSBj aGFuZ2VzIG9uIHRoaXMgbWFpbGluZyBsaXN0LA0KPiB0aGVuIHRoZSBhdXRob3JzIHdpbGwgcHJv ZHVjZSBhIG5ldyB2ZXJzaW9uIG9mIHRoZSBkb2N1bWVudCBlYXJseSBuZXh0DQo+IHdlZWsgcmVm bGVjdGluZyB0aGVzZSBkZWNpc2lvbnMuIFRoZSBwbGFuIGlzIHRvIGlzc3VlIGEgdHdvLXdlZWsN Cj4gd29ya2luZyBncm91cCBsYXN0IGNhbGwgcGVyaW9kIGltbWVkaWF0ZWx5IGFmdGVyIHB1Ymxp Y2F0aW9uLg0KPiA+DQo= From john.elwell@siemens-enterprise.com Thu Feb 10 23:32:27 2011 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 B96003A68BB for ; Thu, 10 Feb 2011 23:32:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.589 X-Spam-Level: X-Spam-Status: No, score=-102.589 tagged_above=-999 required=5 tests=[AWL=0.010, BAYES_00=-2.599, 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 A58j-PHyLSqF for ; Thu, 10 Feb 2011 23:32:26 -0800 (PST) Received: from ms03.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id A95C83A6879 for ; Thu, 10 Feb 2011 23:32:25 -0800 (PST) Received: from senmx12-mx ([62.134.46.10] [62.134.46.10]) by ms03.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-3351001; Fri, 11 Feb 2011 08:32:34 +0100 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx12-mx (Server) with ESMTP id D206923F0278; Fri, 11 Feb 2011 08:32:34 +0100 (CET) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Fri, 11 Feb 2011 08:32:34 +0100 From: "Elwell, John" To: SIPCORE Chairs , "SIPCORE (Session Initiation Protocol Core) WG" Date: Fri, 11 Feb 2011 08:32:33 +0100 Thread-Topic: [sipcore] Geolocation Call Thread-Index: AcvJeMzNB+Pl0aomSUqqxzZb2r3aZgAROL7A Message-ID: References: <4D547232.7020704@nostrum.com> In-Reply-To: <4D547232.7020704@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 Subject: Re: [sipcore] Geolocation Call 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, 11 Feb 2011 07:32:27 -0000 Sorry I was unable to make the call, but looks good to me. John=20 > -----Original Message----- > From: sipcore-bounces@ietf.org=20 > [mailto:sipcore-bounces@ietf.org] On Behalf Of Adam Roach -=20 > SIPCORE Chair > Sent: 10 February 2011 23:18 > To: SIPCORE (Session Initiation Protocol Core) WG > Subject: [sipcore] Geolocation Call >=20 > The phone call today had exactly one topic of discussion: Syntax and=20 > semantics of the SIP header field or fields associated with=20 > geolocation=20 > conveyance. >=20 > Of those on the call, there was unanimous agreement to go=20 > with what Paul=20 > characterized as "Option #5" in his earlier email on the topic. To=20 > summarize this option: >=20 > * We will define a "Geolocation" header field, which can=20 > contain one > or more location values. > * A SIP message may contain zero or more Geolocation=20 > header fields. > * We will define a "Geolocation-Routing" header field, which > contains either "yes" or "no". > * The "Geolocation-Routing" header field can appear at=20 > most once in > a SIP message. > * In the absence of a "Geolocation-Routing" header field, > intermediaries are to assume a value of "no". >=20 >=20 > The specific ANBF that defines these two header fields is: >=20 > Geolocation-header =3D "Geolocation" HCOLON locationValue >=20 > *( COMMA locationValue ) >=20 > locationValue =3D LAQUOT locationURI RAQUOT >=20 > *(SEMI geoloc-param) >=20 > locationURI =3D sip-URI / sips-URI / pres-URI >=20 > / http-URI / HTTPS-URI >=20 > / cid-url ; (from RFC 2392) >=20 > / absoluteURI ; (from RFC 3261) >=20 > geoloc-param =3D generic-param; (from RFC 3261) >=20 >=20 >=20 > Georouting-header =3D "Geolocation-Routing" HCOLON >=20 > ( "yes" / "no" / gen-value ) >=20 >=20 >=20 >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > = From john.elwell@siemens-enterprise.com Fri Feb 11 03:29:41 2011 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 57FC63A6947 for ; Fri, 11 Feb 2011 03:29:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.591 X-Spam-Level: X-Spam-Status: No, score=-102.591 tagged_above=-999 required=5 tests=[AWL=0.008, BAYES_00=-2.599, 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 E9Ie1bLcVVyn for ; Fri, 11 Feb 2011 03:29:40 -0800 (PST) Received: from ms04.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id F06CB3A68B7 for ; Fri, 11 Feb 2011 03:29:39 -0800 (PST) Received: from senmx11-mx ([62.134.46.9] [62.134.46.9]) by ms04.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-3365072; Fri, 11 Feb 2011 12:29:43 +0100 Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx11-mx (Server) with ESMTP id 6F17B1EB82B0; Fri, 11 Feb 2011 12:29:43 +0100 (CET) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Fri, 11 Feb 2011 12:29:43 +0100 From: "Elwell, John" To: SIPCORE Chairs , "SIPCORE (Session Initiation Protocol Core) WG" Date: Fri, 11 Feb 2011 12:29:41 +0100 Thread-Topic: [sipcore] Geolocation Call Thread-Index: AcvJeMzNB+Pl0aomSUqqxzZb2r3aZgAZHAVg Message-ID: References: <4D547232.7020704@nostrum.com> In-Reply-To: <4D547232.7020704@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 Subject: Re: [sipcore] Geolocation Call 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, 11 Feb 2011 11:29:41 -0000 Although my previous message indicated all is fine with this proposal, I do= now have a query as to how this will manifest itself in the revised draft.= See below.=20 > -----Original Message----- > From: sipcore-bounces@ietf.org=20 > [mailto:sipcore-bounces@ietf.org] On Behalf Of Adam Roach -=20 > SIPCORE Chair > Sent: 10 February 2011 23:18 > To: SIPCORE (Session Initiation Protocol Core) WG > Subject: [sipcore] Geolocation Call >=20 > The phone call today had exactly one topic of discussion: Syntax and=20 > semantics of the SIP header field or fields associated with=20 > geolocation=20 > conveyance. >=20 > Of those on the call, there was unanimous agreement to go=20 > with what Paul=20 > characterized as "Option #5" in his earlier email on the topic. To=20 > summarize this option: >=20 > * We will define a "Geolocation" header field, which can=20 > contain one > or more location values. > * A SIP message may contain zero or more Geolocation=20 > header fields. > * We will define a "Geolocation-Routing" header field, which > contains either "yes" or "no". > * The "Geolocation-Routing" header field can appear at=20 > most once in > a SIP message. > * In the absence of a "Geolocation-Routing" header field, > intermediaries are to assume a value of "no". [JRE] This last bullet is fine, but what about where there is neither a Geo= location-Routing header field nor a Geolocation header field and the interm= ediary, on behalf of the UA (e.g., a location-unaware UA) inserts a Geoloca= tion header field? I hope we are not intending to compell the intermediary = to use "no". Existing text in 4.1 states: "If no routing-allowed parameter=20 is present in a SIP request, a SIP intermediary MAY insert this=20 value with a RECOMMENDED value of "no" by default." This present text at least permits (even if not recommended) a value of "ye= s). This text at least needs some attention to talk about the Geolocation-R= outing header field rather than the parameter, and in so doing we should gi= ve careful consideration to what it should say about Geolocation-Routing. I= think there are two separate cases: 1. Where there is already a Geolocation header field but no Geolocation-Rou= ting header field. In this case I don't think the intermediary should be al= lowed to add Geolocation-Routing (or if it does, it MUST have a value of "n= o"). 2. Where there is neither a Geolocation header field nor a Geolocation-Rout= ing header field. In this case, I believe it is permissible for the interme= diary to insert both. I don't think even a recommendation to set the value = to "no" is needed. John >=20 >=20 > The specific ANBF that defines these two header fields is: >=20 > Geolocation-header =3D "Geolocation" HCOLON locationValue >=20 > *( COMMA locationValue ) >=20 > locationValue =3D LAQUOT locationURI RAQUOT >=20 > *(SEMI geoloc-param) >=20 > locationURI =3D sip-URI / sips-URI / pres-URI >=20 > / http-URI / HTTPS-URI >=20 > / cid-url ; (from RFC 2392) >=20 > / absoluteURI ; (from RFC 3261) >=20 > geoloc-param =3D generic-param; (from RFC 3261) >=20 >=20 >=20 > Georouting-header =3D "Geolocation-Routing" HCOLON >=20 > ( "yes" / "no" / gen-value ) >=20 >=20 >=20 >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > = From pkyzivat@cisco.com Fri Feb 11 05:59:05 2011 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 5A9EA3A6A5D for ; Fri, 11 Feb 2011 05:59:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 D2wJMLwFmw4I for ; Fri, 11 Feb 2011 05:59:04 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 52D943A6A16 for ; Fri, 11 Feb 2011 05:59:04 -0800 (PST) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAHLPVE1AZnwN/2dsb2JhbACldHOfSZs+hV0EhQGGe4My X-IronPort-AV: E=Sophos;i="4.60,455,1291593600"; d="scan'208";a="214499167" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 11 Feb 2011 13:59:19 +0000 Received: from [10.86.251.15] (bxb-vpn3-783.cisco.com [10.86.251.15]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id p1BDxIhC002471 for ; Fri, 11 Feb 2011 13:59:18 GMT Message-ID: <4D5540B6.1050506@cisco.com> Date: Fri, 11 Feb 2011 08:59:18 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: sipcore@ietf.org References: <4D547232.7020704@nostrum.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [sipcore] Geolocation Call 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, 11 Feb 2011 13:59:05 -0000 Good catch John. I agree with your points. Paul On 2/11/2011 6:29 AM, Elwell, John wrote: > Although my previous message indicated all is fine with this proposal, I do now have a query as to how this will manifest itself in the revised draft. See below. > >> -----Original Message----- >> From: sipcore-bounces@ietf.org >> [mailto:sipcore-bounces@ietf.org] On Behalf Of Adam Roach - >> SIPCORE Chair >> Sent: 10 February 2011 23:18 >> To: SIPCORE (Session Initiation Protocol Core) WG >> Subject: [sipcore] Geolocation Call >> >> The phone call today had exactly one topic of discussion: Syntax and >> semantics of the SIP header field or fields associated with >> geolocation >> conveyance. >> >> Of those on the call, there was unanimous agreement to go >> with what Paul >> characterized as "Option #5" in his earlier email on the topic. To >> summarize this option: >> >> * We will define a "Geolocation" header field, which can >> contain one >> or more location values. >> * A SIP message may contain zero or more Geolocation >> header fields. >> * We will define a "Geolocation-Routing" header field, which >> contains either "yes" or "no". >> * The "Geolocation-Routing" header field can appear at >> most once in >> a SIP message. >> * In the absence of a "Geolocation-Routing" header field, >> intermediaries are to assume a value of "no". > [JRE] This last bullet is fine, but what about where there is neither a Geolocation-Routing header field nor a Geolocation header field and the intermediary, on behalf of the UA (e.g., a location-unaware UA) inserts a Geolocation header field? I hope we are not intending to compell the intermediary to use "no". > > Existing text in 4.1 states: > "If no routing-allowed parameter > is present in a SIP request, a SIP intermediary MAY insert this > value with a RECOMMENDED value of "no" by default." > This present text at least permits (even if not recommended) a value of "yes). This text at least needs some attention to talk about the Geolocation-Routing header field rather than the parameter, and in so doing we should give careful consideration to what it should say about Geolocation-Routing. I think there are two separate cases: > > 1. Where there is already a Geolocation header field but no Geolocation-Routing header field. In this case I don't think the intermediary should be allowed to add Geolocation-Routing (or if it does, it MUST have a value of "no"). > > 2. Where there is neither a Geolocation header field nor a Geolocation-Routing header field. In this case, I believe it is permissible for the intermediary to insert both. I don't think even a recommendation to set the value to "no" is needed. > > John > > >> >> >> The specific ANBF that defines these two header fields is: >> >> Geolocation-header = "Geolocation" HCOLON locationValue >> >> *( COMMA locationValue ) >> >> locationValue = LAQUOT locationURI RAQUOT >> >> *(SEMI geoloc-param) >> >> locationURI = sip-URI / sips-URI / pres-URI >> >> / http-URI / HTTPS-URI >> >> / cid-url ; (from RFC 2392) >> >> / absoluteURI ; (from RFC 3261) >> >> geoloc-param = generic-param; (from RFC 3261) >> >> >> >> Georouting-header = "Geolocation-Routing" HCOLON >> >> ( "yes" / "no" / gen-value ) >> >> >> >> >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore >> > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From jmpolk@cisco.com Fri Feb 11 11:48:20 2011 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 F2FC43A6AFC for ; Fri, 11 Feb 2011 11:48:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 GxachhWbLO4H for ; Fri, 11 Feb 2011 11:48:18 -0800 (PST) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id A3ED93A6A01 for ; Fri, 11 Feb 2011 11:48:18 -0800 (PST) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.60,457,1291593600"; d="scan'208";a="328593996" Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-5.cisco.com with ESMTP; 11 Feb 2011 19:48:33 +0000 Received: from jmpolk-wxp01.cisco.com (rcdn-jmpolk-8716.cisco.com [10.99.80.23]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id p1BJmXxJ011459; Fri, 11 Feb 2011 19:48:34 GMT Message-Id: <201102111948.p1BJmXxJ011459@sj-core-3.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 11 Feb 2011 13:48:32 -0600 To: Paul Kyzivat , sipcore@ietf.org From: "James M. Polk" In-Reply-To: <4D5540B6.1050506@cisco.com> References: <4D547232.7020704@nostrum.com> <4D5540B6.1050506@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [sipcore] Geolocation Call 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, 11 Feb 2011 19:48:20 -0000 At 07:59 AM 2/11/2011, Paul Kyzivat wrote: >Good catch John. I agree with your points. > > Paul Paul/John Several comments and 1 question below >On 2/11/2011 6:29 AM, Elwell, John wrote: >>Although my previous message indicated all is fine with this >>proposal, I do now have a query as to how this will manifest itself >>in the revised draft. See below. >> >>>-----Original Message----- >>>From: sipcore-bounces@ietf.org >>>[mailto:sipcore-bounces@ietf.org] On Behalf Of Adam Roach - >>>SIPCORE Chair >>>Sent: 10 February 2011 23:18 >>>To: SIPCORE (Session Initiation Protocol Core) WG >>>Subject: [sipcore] Geolocation Call >>> >>>The phone call today had exactly one topic of discussion: Syntax and >>>semantics of the SIP header field or fields associated with >>>geolocation >>>conveyance. >>> >>>Of those on the call, there was unanimous agreement to go >>>with what Paul >>>characterized as "Option #5" in his earlier email on the topic. To >>>summarize this option: >>> >>> * We will define a "Geolocation" header field, which can >>>contain one >>> or more location values. >>> * A SIP message may contain zero or more Geolocation >>>header fields. >>> * We will define a "Geolocation-Routing" header field, which >>> contains either "yes" or "no". >>> * The "Geolocation-Routing" header field can appear at >>>most once in >>> a SIP message. >>> * In the absence of a "Geolocation-Routing" header field, >>> intermediaries are to assume a value of "no". >>[JRE] This last bullet is fine, but what about where there is >>neither a Geolocation-Routing header field nor a Geolocation header >>field and the intermediary, on behalf of the UA (e.g., a >>location-unaware UA) inserts a Geolocation header field? I hope we >>are not intending to compell the intermediary to use "no". >> >>Existing text in 4.1 states: >>"If no routing-allowed parameter >> is present in a SIP request, a SIP intermediary MAY insert this >> value with a RECOMMENDED value of "no" by default." >>This present text at least permits (even if not recommended) a >>value of "yes). This text at least needs some attention to talk >>about the Geolocation-Routing header field rather than the parameter, When the parameter becomes a header, all talk about the parameter will convert too. >>and in so doing we should give careful consideration to what it >>should say about Geolocation-Routing. I have thought that once this parameter elevates to a header, the text needs to 'list' more about what it does and what it means depending on whether or not there is a Geolocation-Routing header value and what it is set to (i.e., yes or no or absent (but not null - which won't be allowed), so I'm with you. >>I think there are two separate cases: >> >>1. Where there is already a Geolocation header field but no >>Geolocation-Routing header field. In this case I don't think the >>intermediary should be allowed to add Geolocation-Routing (or if it >>does, it MUST have a value of "no"). I agree, and this is consistent with what's in the draft now by it saying the default when not present is "no". >>2. Where there is neither a Geolocation header field nor a >>Geolocation-Routing header field. In this case, I believe it is >>permissible for the intermediary to insert both. I don't think even >>a recommendation to set the value to "no" is needed. This one is more dicey, but I think I agree with you. if there is neither header is present, this absolutely allows an intermediary to insert location. But here's the question/dicey part - is the default policy from the UAC still "no". Some might say this is true even without a Geolocation header in the original SIP request from the UAC. Others might say that because the original UAC didn't include a Geolocation-Routing header = "no" that this leaves it up in the air for downstream intermediaries to insert the header with either a "no" or "yes". This more of less motivates the original UAC to include the Geolocation-Routing header even if it doesn't include a Geolocation header just to make sure it's policy of "no" is included downstream (at least until one of the 2 existing permissions is required to process the request). What is in this paragraph is implied. Question to you (and others) - should this be stated informally (but certainly not normatively)? I'd hate for this not to be clear in some implementations for customers (individual or administrative) not to have the chance to configure one way or the other. James >>John >> >> >>> >>> >>>The specific ANBF that defines these two header fields is: >>> >>> Geolocation-header = "Geolocation" HCOLON locationValue >>> >>> *( COMMA locationValue ) >>> >>> locationValue = LAQUOT locationURI RAQUOT >>> >>> *(SEMI geoloc-param) >>> >>> locationURI = sip-URI / sips-URI / pres-URI >>> >>> / http-URI / HTTPS-URI >>> >>> / cid-url ; (from RFC 2392) >>> >>> / absoluteURI ; (from RFC 3261) >>> >>> geoloc-param = generic-param; (from RFC 3261) >>> >>> >>> >>> Georouting-header = "Geolocation-Routing" HCOLON >>> >>> ( "yes" / "no" / gen-value ) >>> >>> >>> >>> >>>_______________________________________________ >>>sipcore mailing list >>>sipcore@ietf.org >>>https://www.ietf.org/mailman/listinfo/sipcore >>_______________________________________________ >>sipcore mailing list >>sipcore@ietf.org >>https://www.ietf.org/mailman/listinfo/sipcore >_______________________________________________ >sipcore mailing list >sipcore@ietf.org >https://www.ietf.org/mailman/listinfo/sipcore From pkyzivat@cisco.com Fri Feb 11 12:30:00 2011 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 C84233A6997 for ; Fri, 11 Feb 2011 12:30:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.399 X-Spam-Level: X-Spam-Status: No, score=-110.399 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 cpZ50ELU+SL8 for ; Fri, 11 Feb 2011 12:30:00 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id E75653A6975 for ; Fri, 11 Feb 2011 12:29:59 -0800 (PST) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.60,457,1291593600"; d="scan'208";a="214659819" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 11 Feb 2011 20:30:15 +0000 Received: from [10.86.251.15] (bxb-vpn3-783.cisco.com [10.86.251.15]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id p1BKUE0J021206; Fri, 11 Feb 2011 20:30:15 GMT Message-ID: <4D559C56.1070709@cisco.com> Date: Fri, 11 Feb 2011 15:30:14 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: "James M. Polk" References: <4D547232.7020704@nostrum.com> <4D5540B6.1050506@cisco.com> <201102111948.p1BJmXxJ011459@sj-core-3.cisco.com> In-Reply-To: <201102111948.p1BJmXxJ011459@sj-core-3.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: sipcore@ietf.org Subject: Re: [sipcore] Geolocation Call 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, 11 Feb 2011 20:30:00 -0000 below On 2/11/2011 2:48 PM, James M. Polk wrote: >>> 2. Where there is neither a Geolocation header field nor a >>> Geolocation-Routing header field. In this case, I believe it is >>> permissible for the intermediary to insert both. I don't think even a >>> recommendation to set the value to "no" is needed. > > This one is more dicey, but I think I agree with you. > > if there is neither header is present, this absolutely allows an > intermediary to insert location. But here's the question/dicey part - is > the default policy from the UAC still "no". > > Some might say this is true even without a Geolocation header in the > original SIP request from the UAC. > > Others might say that because the original UAC didn't include a > Geolocation-Routing header = "no" that this leaves it up in the air for > downstream intermediaries to insert the header with either a "no" or "yes". > > This more of less motivates the original UAC to include the > Geolocation-Routing header even if it doesn't include a Geolocation > header just to make sure it's policy of "no" is included downstream (at > least until one of the 2 existing permissions is required to process the > request). What is in this paragraph is implied. Question to you (and > others) - should this be stated informally (but certainly not > normatively)? I'd hate for this not to be clear in some implementations > for customers (individual or administrative) not to have the chance to > configure one way or the other. I hope this doesn't open up old wounds we would rather not revisit... What is the *reason* that someone might specify that routing should/should not be allowed to use the geoloc info??? ISTM this is based on the reason that the geoloc info was inserted in the header at all. - I want this routed normally, and want the recipient to have this location info available - I inserted this location info, at least in part, for the purpose of getting the request routed based on the location. It seems that ultimately then this is driven by whoever inserts the location info. That would argue that if the UAC inserted nothing about location, and something downstream did, then the inserter ought to have the opportunity to decide whether the purpose is for routing or not. If the UAC inserted *some* geoloc info, then it has made the decision of the purpose for it. And in that case an intermediary inserting additional location info needs to honor the intent. Bottom line - I am agreeing with both of you. Thanks, Paul From john.elwell@siemens-enterprise.com Mon Feb 14 03:09:26 2011 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 1D6FA3A6CB3 for ; Mon, 14 Feb 2011 03:09:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.593 X-Spam-Level: X-Spam-Status: No, score=-102.593 tagged_above=-999 required=5 tests=[AWL=0.006, BAYES_00=-2.599, 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 P9uacmm51GrJ for ; Mon, 14 Feb 2011 03:09:25 -0800 (PST) Received: from ms03.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id E4ED93A6CB2 for ; Mon, 14 Feb 2011 03:09:24 -0800 (PST) Received: from senmx12-mx ([62.134.46.10] [62.134.46.10]) by ms03.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-3377440; Mon, 14 Feb 2011 12:09:04 +0100 Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx12-mx (Server) with ESMTP id 6ECA423F02C3; Mon, 14 Feb 2011 12:09:04 +0100 (CET) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Mon, 14 Feb 2011 12:09:04 +0100 From: "Elwell, John" To: Paul Kyzivat , "James M. Polk" Date: Mon, 14 Feb 2011 12:09:02 +0100 Thread-Topic: [sipcore] Geolocation Call Thread-Index: AcvKKoCppZyzPCFVTbmBtH5MhdRvYACDP7tA Message-ID: References: <4D547232.7020704@nostrum.com> <4D5540B6.1050506@cisco.com> <201102111948.p1BJmXxJ011459@sj-core-3.cisco.com> <4D559C56.1070709@cisco.com> In-Reply-To: <4D559C56.1070709@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 Cc: "sipcore@ietf.org" Subject: Re: [sipcore] Geolocation Call 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, 14 Feb 2011 11:09:26 -0000 =20 > -----Original Message----- > From: sipcore-bounces@ietf.org=20 > [mailto:sipcore-bounces@ietf.org] On Behalf Of Paul Kyzivat > Sent: 11 February 2011 20:30 > To: James M. Polk > Cc: sipcore@ietf.org > Subject: Re: [sipcore] Geolocation Call >=20 > below >=20 > On 2/11/2011 2:48 PM, James M. Polk wrote: >=20 > >>> 2. Where there is neither a Geolocation header field nor a > >>> Geolocation-Routing header field. In this case, I believe it is > >>> permissible for the intermediary to insert both. I don't=20 > think even a > >>> recommendation to set the value to "no" is needed. > > > > This one is more dicey, but I think I agree with you. > > > > if there is neither header is present, this absolutely allows an > > intermediary to insert location. But here's the=20 > question/dicey part - is > > the default policy from the UAC still "no". > > > > Some might say this is true even without a Geolocation header in the > > original SIP request from the UAC. > > > > Others might say that because the original UAC didn't include a > > Geolocation-Routing header =3D "no" that this leaves it up in=20 > the air for > > downstream intermediaries to insert the header with either=20 > a "no" or "yes". > > > > This more of less motivates the original UAC to include the > > Geolocation-Routing header even if it doesn't include a Geolocation > > header just to make sure it's policy of "no" is included=20 > downstream (at > > least until one of the 2 existing permissions is required=20 > to process the > > request). What is in this paragraph is implied. Question to you (and > > others) - should this be stated informally (but certainly not > > normatively)? I'd hate for this not to be clear in some=20 > implementations > > for customers (individual or administrative) not to have=20 > the chance to > > configure one way or the other. >=20 > I hope this doesn't open up old wounds we would rather not revisit... >=20 > What is the *reason* that someone might specify that routing=20 > should/should not be allowed to use the geoloc info??? >=20 > ISTM this is based on the reason that the geoloc info was inserted in=20 > the header at all. > - I want this routed normally, and want the recipient to > have this location info available >=20 > - I inserted this location info, at least in part, for the purpose > of getting the request routed based on the location. >=20 > It seems that ultimately then this is driven by whoever inserts the=20 > location info. That would argue that if the UAC inserted=20 > nothing about=20 > location, and something downstream did, then the inserter=20 > ought to have=20 > the opportunity to decide whether the purpose is for routing or not. >=20 > If the UAC inserted *some* geoloc info, then it has made the=20 > decision of=20 > the purpose for it. And in that case an intermediary inserting=20 > additional location info needs to honor the intent. [JRE] Yes, that was my reasoning. John >=20 > Bottom line - I am agreeing with both of you. >=20 > Thanks, > Paul > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > = From Internet-Drafts@ietf.org Mon Feb 14 07:15:02 2011 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 52F843A6D63; Mon, 14 Feb 2011 07:15:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.486 X-Spam-Level: X-Spam-Status: No, score=-102.486 tagged_above=-999 required=5 tests=[AWL=0.113, BAYES_00=-2.599, 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 eSgulVPWEuxl; Mon, 14 Feb 2011 07:15:01 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 974263A6B53; Mon, 14 Feb 2011 07:15:01 -0800 (PST) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.12 Message-ID: <20110214151501.27807.33759.idtracker@localhost> Date: Mon, 14 Feb 2011 07:15:01 -0800 Cc: sipcore@ietf.org Subject: [sipcore] I-D Action:draft-ietf-sipcore-rfc4244bis-03.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, 14 Feb 2011 15: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 the Session Initiation Protocol (SIP) for Request History Information Author(s) : M. Barnes, et al. Filename : draft-ietf-sipcore-rfc4244bis-03.txt Pages : 48 Date : 2011-02-14 This document defines a standard mechanism for capturing the history information associated with a Session Initiation Protocol (SIP) request. This capability enables many enhanced services by providing the information as to how and why a SIP request arrives at a specific application or user. This document defines an optional SIP header field, History-Info, for capturing the history information in requests. The document also defines SIP header field parameters for the History-Info and Contact header fields to tag the method by which the target of a request is determined. In addition, this document defines a value for the Privacy header field specific to the History- Info header field. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sipcore-rfc4244bis-03.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-rfc4244bis-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-02-14070409.I-D@ietf.org> --NextPart-- From mary.ietf.barnes@gmail.com Mon Feb 14 07:41:39 2011 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 CBB883A6D20 for ; Mon, 14 Feb 2011 07:41:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.598 X-Spam-Level: X-Spam-Status: No, score=-103.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, 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 4aQRYz1IeJ7q for ; Mon, 14 Feb 2011 07:41:38 -0800 (PST) Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by core3.amsl.com (Postfix) with ESMTP id 75F693A6D72 for ; Mon, 14 Feb 2011 07:41:38 -0800 (PST) Received: by gwb20 with SMTP id 20so2367540gwb.31 for ; Mon, 14 Feb 2011 07:42:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:content-type; bh=GeY4dNToAOun3OK8fhDTi9BSHX7P0eVhBxyEDq9PavM=; b=ra8EnnMqnzzYl/WmaaYYQC1xbddNd9At7wCfivn8ERUA6SQhAbh8A+nOgzoWmI8kfN 3V0vqPYEX5mMsUip9J2FUVi3KIw+8bVDP23uFiF94MG+R/0lg6193Of/8bPGnjdm0ZtE c4pTEJmEe9LdlOnIOO5oxoo2HuzBtgqmPNIPI= 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 :content-type; b=Wdvn7nwfZsKWnuvogk2loAecQh6dZSQu9BlY8hUlq6iHR58Vf5IBtBVJw/1tqHfPht D34e3W0KH8T/oUXzDCN053lm2lPQE4ozw/NI2/ewCTPpjOMZCmdpnl1Re+jnoHyyaxGE YCzKS+Irw1/hylMY3PbUXDQ8uFDe95DuCP+EE= MIME-Version: 1.0 Received: by 10.236.108.43 with SMTP id p31mr1476235yhg.22.1297698121000; Mon, 14 Feb 2011 07:42:01 -0800 (PST) Received: by 10.236.95.35 with HTTP; Mon, 14 Feb 2011 07:42:00 -0800 (PST) In-Reply-To: <20110214151501.27807.33759.idtracker@localhost> References: <20110214151501.27807.33759.idtracker@localhost> Date: Mon, 14 Feb 2011 09:42:00 -0600 Message-ID: From: Mary Barnes To: SIPCORE Content-Type: multipart/alternative; boundary=90e6ba4fbe2e872a49049c3fe321 Subject: Re: [sipcore] I-D Action:draft-ietf-sipcore-rfc4244bis-03.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, 14 Feb 2011 15:41:39 -0000 --90e6ba4fbe2e872a49049c3fe321 Content-Type: text/plain; charset=ISO-8859-1 Apologies for the very lengthy delay in getting the document updated. The changes are quite extensive based on all the feedback and include the following: 1) Lots of editorial: a) Reorganized sections similar to the RFC 4244 order - i.e., introduce header field parameters and syntax first, then describe how the functional entities use the header. This removes redundant (and often inconsistent) text describing the parameters. b) Expanded use of "header" to "header field" c) More precision in terms of "escaping" of the Privacy and Reason headers in the hi-targeted-to-uri (versus "adding"/"setting"/etc. them to the hi-entry). d) Consistent use of parameter names (i.e., hi-entry versus entry, hi-target versus target, etc.) e) Moved item 6 in the Index section to the section on Response handling f) Removed last remaining vestiges of inline references to requirements. 2) Clarifications of functionality/applicability including: a) which messages may contain History-Info b) removing security text with regards to being able to figure out if there are missing entries when using TLS (issue #44) c) More complete information on the new header field parameters as they relate to the hi-target parameter. d) Changed wording from passive to active for normative statements in many cases and removed superfluous normative language. 3) Rewrite of the Privacy section to address issues and splitting into the setting of the Privacy header fields and the processing/application of the privacy header field priv-values. 4) Rewrite of the Reason header field section - simplifying the text and adding back the RFC 4244 text with regards to the use of the Reason header field in cases of internal retargeting. I did attempt to cover all the comments, but since alot of the relevant text changed, it's possible that I missed some comments. However, we're hoping that folks will find this version to be easier to follow. Regards, Mary. On Mon, Feb 14, 2011 at 9:15 AM, 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 the Session Initiation Protocol > (SIP) for Request History Information > Author(s) : M. Barnes, et al. > Filename : draft-ietf-sipcore-rfc4244bis-03.txt > Pages : 48 > Date : 2011-02-14 > > This document defines a standard mechanism for capturing the history > information associated with a Session Initiation Protocol (SIP) > request. This capability enables many enhanced services by providing > the information as to how and why a SIP request arrives at a specific > application or user. This document defines an optional SIP header > field, History-Info, for capturing the history information in > requests. The document also defines SIP header field parameters for > the History-Info and Contact header fields to tag the method by which > the target of a request is determined. In addition, this document > defines a value for the Privacy header field specific to the History- > Info header field. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-sipcore-rfc4244bis-03.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 > > --90e6ba4fbe2e872a49049c3fe321 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Apologies for the very lengthy delay in getting the document updated.=A0
The changes are quite extensive based on all the feedback = and include the following:
1) Lots of editorial:
a) Reor= ganized sections similar to the RFC 4244 order - i.e., introduce header fie= ld parameters and syntax first, then describe how the functional entities u= se the header. =A0This removes redundant =A0(and often inconsistent) text d= escribing the parameters.
b) Expanded use of "header" to "header field"
c) More precision in terms of "escaping" of the Privacy and= Reason headers in the hi-targeted-to-uri (versus "adding"/"= setting"/etc. them to the hi-entry).
d) Consistent use of parameter names (i.e., hi-entry versus entry, hi-= target versus target, etc.)
e) Moved item 6 in the Index section = to the section on Response handling
f) Removed last remaining ves= tiges of inline references to requirements.


2) Clarifications of functionality/appli= cability including:
a) =A0which messages may contain History-Info=
b) =A0removing security text with regards to being able to figur= e out if there are missing entries when using TLS (issue #44)
c) More complete information on the new header field parameters as the= y relate to the hi-target parameter. =A0
d) Changed wording = from passive to active for normative statements in many cases and removed s= uperfluous normative language.=A0


3) Rewrite of the Privacy section = to address issues and splitting into the setting of the Privacy header fiel= ds and the processing/application of the privacy header field priv-values.= =A0

4) Rewrite of the Reason header field section - simplif= ying the text and adding back the RFC 4244 text with regards to the use of = the Reason header field in cases of internal retargeting.=A0

I did attempt to cover all the comments, but since alot of t= he relevant text changed, it's possible that I missed some comments. = =A0 However, we're hoping that folks will find this version to be easie= r to follow.=A0

Regards,
Mary.=A0

On Mon, Feb 14, 2011 at 9: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 G= roup of the IETF.


=A0 =A0 =A0 =A0Title =A0 =A0 =A0 =A0 =A0 : An Extension to the Session Ini= tiation Protocol (SIP) for Request History Information
=A0 =A0 =A0 =A0Author(s) =A0 =A0 =A0 : M. Barnes, et al.
=A0 =A0 =A0 =A0Filename =A0 =A0 =A0 =A0: draft-ietf-sipcore-rfc4244bis-03.= txt
=A0 =A0 =A0 =A0Pages =A0 =A0 =A0 =A0 =A0 : 48
=A0 =A0 =A0 =A0Date =A0 =A0 =A0 =A0 =A0 =A0: 2011-02-14

This document defines a standard mechanism for capturing the history
information associated with a Session Initiation Protocol (SIP)
request. =A0This capability enables many enhanced services by providing
the information as to how and why a SIP request arrives at a specific
application or user. =A0This document defines an optional SIP header
field, History-Info, for capturing the history information in
requests. =A0The document also defines SIP header field parameters for
the History-Info and Contact header fields to tag the method by which
the target of a request is determined. =A0In addition, this document
defines a value for the Privacy header field specific to the History-
Info header field.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-= sipcore-rfc4244bis-03.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


--90e6ba4fbe2e872a49049c3fe321-- From iesg-secretary@ietf.org Mon Feb 14 08:44:16 2011 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 EFF5A3A699E; Mon, 14 Feb 2011 08:44:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 XAerTERRbbHT; Mon, 14 Feb 2011 08:44:15 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7EC383A6D68; Mon, 14 Feb 2011 08:44:14 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 3.12 Message-ID: <20110214164414.20089.26199.idtracker@localhost> Date: Mon, 14 Feb 2011 08:44:14 -0800 Cc: sipcore chair , Internet Architecture Board , sipcore mailing list , RFC Editor Subject: [sipcore] Document Action: 'Example call flows using Session Initiation Protocol (SIP) security mechanisms' to Informational RFC (draft-ietf-sipcore-sec-flows-09.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, 14 Feb 2011 16:44:16 -0000 The IESG has approved the following document: - 'Example call flows using Session Initiation Protocol (SIP) security mechanisms' (draft-ietf-sipcore-sec-flows-09.txt) as an Informational RFC This document is the product of the Session Initiation Protocol Core Working Group. The IESG contact persons are Gonzalo Camarillo and Robert Sparks. A URL of this Internet Draft is: http://datatracker.ietf.org/doc/draft-ietf-sipcore-sec-flows/ Technical Summary This document shows example call flows demonstrating the use of Transport Layer Security (TLS), and Secure/Multipurpose Internet Mail Extensions (S/MIME) in Session Initiation Protocol (SIP). It also provides information that helps implementers build interoperable SIP software. Working Group Summary This work traces its roots back to 2003, when it was first introduced into the SIP working group. For much of its lifetime, it existed quietly alongside the document "Certificate Management Service for The Session Initiation Protocol," which is currently in the RFC Editors' queue. After moving into SIPCORE, repeated requests by the chairs for review yielded a small number of in-depth reviews. Document Quality According to one of the document authors, he has received "many emails from implementors that use this draft." Using this as our data point, the document's utility as a sanity check for the security aspects of SIP implementations would seem to be very high. Ole Johansson brought back practical feedback from SIPit interoperabilty testing events regarding some of the practical aspects of what needs to appear in TLS certificates. Personnel Adam Roach is the document shepherd. Gonzalo Camarillo is the responsible Area Director. From jmpolk@cisco.com Mon Feb 14 15:22:23 2011 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 BFBE53A6DDA for ; Mon, 14 Feb 2011 15:22:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.563 X-Spam-Level: X-Spam-Status: No, score=-110.563 tagged_above=-999 required=5 tests=[AWL=0.036, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 x6dezo4ihocu for ; Mon, 14 Feb 2011 15:22:22 -0800 (PST) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 8AFAC3A6DCE for ; Mon, 14 Feb 2011 15:22:22 -0800 (PST) Authentication-Results: sj-iport-3.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.60,470,1291593600"; d="scan'208";a="263459839" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-3.cisco.com with ESMTP; 14 Feb 2011 23:22:46 +0000 Received: from jmpolk-wxp01.cisco.com (rcdn-jmpolk-8716.cisco.com [10.99.80.23]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id p1ENMj4D020196; Mon, 14 Feb 2011 23:22:46 GMT Message-Id: <201102142322.p1ENMj4D020196@sj-core-1.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 14 Feb 2011 17:22:44 -0600 To: Paul Kyzivat , "James M. Polk" From: "James M. Polk" In-Reply-To: <4D559C56.1070709@cisco.com> References: <4D547232.7020704@nostrum.com> <4D5540B6.1050506@cisco.com> <201102111948.p1BJmXxJ011459@sj-core-3.cisco.com> <4D559C56.1070709@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: sipcore@ietf.org Subject: Re: [sipcore] Geolocation Call 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, 14 Feb 2011 23:22:23 -0000 At 02:30 PM 2/11/2011, Paul Kyzivat wrote: >below > >On 2/11/2011 2:48 PM, James M. Polk wrote: > >>>>2. Where there is neither a Geolocation header field nor a >>>>Geolocation-Routing header field. In this case, I believe it is >>>>permissible for the intermediary to insert both. I don't think even a >>>>recommendation to set the value to "no" is needed. >> >>This one is more dicey, but I think I agree with you. >> >>if there is neither header is present, this absolutely allows an >>intermediary to insert location. But here's the question/dicey part - is >>the default policy from the UAC still "no". >> >>Some might say this is true even without a Geolocation header in the >>original SIP request from the UAC. >> >>Others might say that because the original UAC didn't include a >>Geolocation-Routing header = "no" that this leaves it up in the air for >>downstream intermediaries to insert the header with either a "no" or "yes". >> >>This more of less motivates the original UAC to include the >>Geolocation-Routing header even if it doesn't include a Geolocation >>header just to make sure it's policy of "no" is included downstream (at >>least until one of the 2 existing permissions is required to process the >>request). What is in this paragraph is implied. Question to you (and >>others) - should this be stated informally (but certainly not >>normatively)? I'd hate for this not to be clear in some implementations >>for customers (individual or administrative) not to have the chance to >>configure one way or the other. > >I hope this doesn't open up old wounds we would rather not revisit... > >What is the *reason* that someone might specify that routing >should/should not be allowed to use the geoloc info??? the existing "routing-allowed" header parameter is a bit of a mislabeling. It doesn't mean "routing" in the L3 or L7 sense of the word, it means "do I (the recipient of this SIP request have permission to view the locally available - or via a dereference transaction that I perform - geolocation information within this SIP request. If "routing-allowed" is set to "=yes", then I have permission to view it and to send the geolocation information to a 3rd party (as many as I want or as many times as I want). If "routing-allowed" is set to "=no", I do not have permission to view or dereference any geolocation information directly or indirectly related to this SIP request, *and* I do not have permission to transmit this location blob to a 3rd party at any time. Based on the above, I think your first "ISTM" point is a little off, but understandably so. It should have "only the recipient" in there, and then it's accurate. the second point is correct as is. >ISTM this is based on the reason that the geoloc info was inserted >in the header at all. >- I want this routed normally, and want the recipient to > have this location info available > >- I inserted this location info, at least in part, for the purpose > of getting the request routed based on the location. > >It seems that ultimately then this is driven by whoever inserts the >location info. or the policy flag (which is the Geolocation-Routing: header, which can be inserted without there being a Geolocation: header) > That would argue that if the UAC inserted nothing about location, > and something downstream did, then the inserter ought to have the > opportunity to decide whether the purpose is for routing or not. I agree with this, unless there is a "Geolocation-Routing: no" header flag setting the policy for location handling for all downstream inband signaling elements. >If the UAC inserted *some* geoloc info, then it has made the >decision of the purpose for it. And in that case an intermediary >inserting additional location info needs to honor the intent. > >Bottom line - I am agreeing with both of you. but do you agree now? James > Thanks, > Paul From pkyzivat@cisco.com Tue Feb 15 06:07:14 2011 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 4AD983A6CAB for ; Tue, 15 Feb 2011 06:07:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 Pak+8DUEEMZ4 for ; Tue, 15 Feb 2011 06:07:13 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 3CB9F3A6C94 for ; Tue, 15 Feb 2011 06:07:13 -0800 (PST) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.60,474,1291593600"; d="scan'208";a="215822771" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 15 Feb 2011 14:07:38 +0000 Received: from [161.44.174.114] (dhcp-161-44-174-114.cisco.com [161.44.174.114]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id p1FE7caf021513; Tue, 15 Feb 2011 14:07:38 GMT Message-ID: <4D5A88AA.6000705@cisco.com> Date: Tue, 15 Feb 2011 09:07:38 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: "James M. Polk" References: <4D547232.7020704@nostrum.com> <4D5540B6.1050506@cisco.com> <201102111948.p1BJmXxJ011459@sj-core-3.cisco.com> <4D559C56.1070709@cisco.com> <201102142322.p1ENMj4D020196@sj-core-1.cisco.com> In-Reply-To: <201102142322.p1ENMj4D020196@sj-core-1.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: sipcore@ietf.org Subject: Re: [sipcore] Geolocation Call 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, 15 Feb 2011 14:07:14 -0000 On 2/14/2011 6:22 PM, James M. Polk wrote: > At 02:30 PM 2/11/2011, Paul Kyzivat wrote: >> below >> >> On 2/11/2011 2:48 PM, James M. Polk wrote: >> >>>>> 2. Where there is neither a Geolocation header field nor a >>>>> Geolocation-Routing header field. In this case, I believe it is >>>>> permissible for the intermediary to insert both. I don't think even a >>>>> recommendation to set the value to "no" is needed. >>> >>> This one is more dicey, but I think I agree with you. >>> >>> if there is neither header is present, this absolutely allows an >>> intermediary to insert location. But here's the question/dicey part - is >>> the default policy from the UAC still "no". >>> >>> Some might say this is true even without a Geolocation header in the >>> original SIP request from the UAC. >>> >>> Others might say that because the original UAC didn't include a >>> Geolocation-Routing header = "no" that this leaves it up in the air for >>> downstream intermediaries to insert the header with either a "no" or >>> "yes". >>> >>> This more of less motivates the original UAC to include the >>> Geolocation-Routing header even if it doesn't include a Geolocation >>> header just to make sure it's policy of "no" is included downstream (at >>> least until one of the 2 existing permissions is required to process the >>> request). What is in this paragraph is implied. Question to you (and >>> others) - should this be stated informally (but certainly not >>> normatively)? I'd hate for this not to be clear in some implementations >>> for customers (individual or administrative) not to have the chance to >>> configure one way or the other. >> >> I hope this doesn't open up old wounds we would rather not revisit... >> >> What is the *reason* that someone might specify that routing >> should/should not be allowed to use the geoloc info??? > > the existing "routing-allowed" header parameter is a bit of a > mislabeling. It doesn't mean "routing" in the L3 or L7 sense of the > word, it means "do I (the recipient of this SIP request have permission > to view the locally available - or via a dereference transaction that I > perform - geolocation information within this SIP request. If > "routing-allowed" is set to "=yes", then I have permission to view it > and to send the geolocation information to a 3rd party (as many as I > want or as many times as I want). If "routing-allowed" is set to "=no", > I do not have permission to view or dereference any geolocation > information directly or indirectly related to this SIP request, *and* I > do not have permission to transmit this location blob to a 3rd party at > any time. Hmm. I thought it was a rule about whether the geoloc info could be used to make retargeting decisions. So, IIUC now, you are saying this has to do with routing of the geoloc info, not routing of the message containing it. Is that right? (Of course, routing the message containing it has the effect of routing the geoloc info too.) > Based on the above, I think your first "ISTM" point is a little off, but > understandably so. It should have "only the recipient" in there, and > then it's accurate. > > the second point is correct as is. > > >> ISTM this is based on the reason that the geoloc info was inserted in >> the header at all. >> - I want this routed normally, and want the recipient to >> have this location info available >> >> - I inserted this location info, at least in part, for the purpose >> of getting the request routed based on the location. >> >> It seems that ultimately then this is driven by whoever inserts the >> location info. > > or the policy flag (which is the Geolocation-Routing: header, which can > be inserted without there being a Geolocation: header) > >> That would argue that if the UAC inserted nothing about location, and >> something downstream did, then the inserter ought to have the >> opportunity to decide whether the purpose is for routing or not. > > I agree with this, unless there is a "Geolocation-Routing: no" header > flag setting the policy for location handling for all downstream inband > signaling elements. > > >> If the UAC inserted *some* geoloc info, then it has made the decision >> of the purpose for it. And in that case an intermediary inserting >> additional location info needs to honor the intent. >> >> Bottom line - I am agreeing with both of you. > > but do you agree now? Your clarification doesn't alter my conclusion. Thanks, Paul From jmpolk@cisco.com Tue Feb 15 15:35:52 2011 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 61F3E3A6B3B for ; Tue, 15 Feb 2011 15:35:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.569 X-Spam-Level: X-Spam-Status: No, score=-110.569 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LYEf8bRzolkk for ; Tue, 15 Feb 2011 15:35:50 -0800 (PST) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id A425C3A6AF1 for ; Tue, 15 Feb 2011 15:35:50 -0800 (PST) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.60,476,1291593600"; d="scan'208";a="330373278" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-5.cisco.com with ESMTP; 15 Feb 2011 23:36:17 +0000 Received: from jmpolk-wxp01.cisco.com (rcdn-jmpolk-8716.cisco.com [10.99.80.23]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id p1FNaGiE007329; Tue, 15 Feb 2011 23:36:17 GMT Message-Id: <201102152336.p1FNaGiE007329@sj-core-1.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 15 Feb 2011 17:36:15 -0600 To: Paul Kyzivat , "James M. Polk" From: "James M. Polk" In-Reply-To: <4D5A88AA.6000705@cisco.com> References: <4D547232.7020704@nostrum.com> <4D5540B6.1050506@cisco.com> <201102111948.p1BJmXxJ011459@sj-core-3.cisco.com> <4D559C56.1070709@cisco.com> <201102142322.p1ENMj4D020196@sj-core-1.cisco.com> <4D5A88AA.6000705@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: sipcore@ietf.org Subject: Re: [sipcore] Geolocation Call 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, 15 Feb 2011 23:35:53 -0000 At 08:07 AM 2/15/2011, Paul Kyzivat wrote: >On 2/14/2011 6:22 PM, James M. Polk wrote: >>At 02:30 PM 2/11/2011, Paul Kyzivat wrote: >>>below >>> >>>On 2/11/2011 2:48 PM, James M. Polk wrote: >>> >>>>>>2. Where there is neither a Geolocation header field nor a >>>>>>Geolocation-Routing header field. In this case, I believe it is >>>>>>permissible for the intermediary to insert both. I don't think even a >>>>>>recommendation to set the value to "no" is needed. >>>> >>>>This one is more dicey, but I think I agree with you. >>>> >>>>if there is neither header is present, this absolutely allows an >>>>intermediary to insert location. But here's the question/dicey part - is >>>>the default policy from the UAC still "no". >>>> >>>>Some might say this is true even without a Geolocation header in the >>>>original SIP request from the UAC. >>>> >>>>Others might say that because the original UAC didn't include a >>>>Geolocation-Routing header = "no" that this leaves it up in the air for >>>>downstream intermediaries to insert the header with either a "no" or >>>>"yes". >>>> >>>>This more of less motivates the original UAC to include the >>>>Geolocation-Routing header even if it doesn't include a Geolocation >>>>header just to make sure it's policy of "no" is included downstream (at >>>>least until one of the 2 existing permissions is required to process the >>>>request). What is in this paragraph is implied. Question to you (and >>>>others) - should this be stated informally (but certainly not >>>>normatively)? I'd hate for this not to be clear in some implementations >>>>for customers (individual or administrative) not to have the chance to >>>>configure one way or the other. >>> >>>I hope this doesn't open up old wounds we would rather not revisit... >>> >>>What is the *reason* that someone might specify that routing >>>should/should not be allowed to use the geoloc info??? >> >>the existing "routing-allowed" header parameter is a bit of a >>mislabeling. It doesn't mean "routing" in the L3 or L7 sense of the >>word, it means "do I (the recipient of this SIP request have permission >>to view the locally available - or via a dereference transaction that I >>perform - geolocation information within this SIP request. If >>"routing-allowed" is set to "=yes", then I have permission to view it >>and to send the geolocation information to a 3rd party (as many as I >>want or as many times as I want). If "routing-allowed" is set to "=no", >>I do not have permission to view or dereference any geolocation >>information directly or indirectly related to this SIP request, *and* I >>do not have permission to transmit this location blob to a 3rd party at >>any time. > >Hmm. I thought it was a rule about whether the geoloc info could be >used to make retargeting decisions. correct, but that's secondary. The primary concern is whether or not SIP intermediaries, as LRs, are even allowed to view (or dereference) location in the message. If they can (i.e., "Geolocation-Routing: yes"), then they view this information to make routing decisions. If, OTOH, "Geolocation-Routing: no" and that intermediary believes (as much as a machine can 'believe') it has to be able to use the location information of the Target to make a proper routing decision, the intermediary must respond with a 424 (Bad Location Information) response including the following: Geolocation-Error: 202 "Permission to Route based on Location Information" This should bubble up to the UI to allow that Target's user to agree (or not) to reveal their location information to that (and all) SIP intermediaries for use in making good routing decisions of the subsequent SIP request. Does this make sense? So, the answer is yes, it has to do with the actual routing of the message, but that's a secondary concern to the revelation of the Target's location information (i.e., it's a little more complicated than you originally put it). >So, IIUC now, you are saying this has to do with routing of the >geoloc info, not routing of the message containing it. Is that right? No, it's a viewability flag for the contained location, then with permission to view the Target's location information, it's making a good routing decision based on that location information. Let me know if I've confused you with this explanation. James >(Of course, routing the message containing it has the effect of >routing the geoloc info too.) > >>Based on the above, I think your first "ISTM" point is a little off, but >>understandably so. It should have "only the recipient" in there, and >>then it's accurate. >> >>the second point is correct as is. >> >> >>>ISTM this is based on the reason that the geoloc info was inserted in >>>the header at all. >>>- I want this routed normally, and want the recipient to >>>have this location info available >>> >>>- I inserted this location info, at least in part, for the purpose >>>of getting the request routed based on the location. >>> >>>It seems that ultimately then this is driven by whoever inserts the >>>location info. >> >>or the policy flag (which is the Geolocation-Routing: header, which can >>be inserted without there being a Geolocation: header) >> >>>That would argue that if the UAC inserted nothing about location, and >>>something downstream did, then the inserter ought to have the >>>opportunity to decide whether the purpose is for routing or not. >> >>I agree with this, unless there is a "Geolocation-Routing: no" header >>flag setting the policy for location handling for all downstream inband >>signaling elements. >> >> >>>If the UAC inserted *some* geoloc info, then it has made the decision >>>of the purpose for it. And in that case an intermediary inserting >>>additional location info needs to honor the intent. >>> >>>Bottom line - I am agreeing with both of you. >> >>but do you agree now? > >Your clarification doesn't alter my conclusion. > > Thanks, > Paul From pkyzivat@cisco.com Tue Feb 15 16:43:12 2011 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 AE8BB3A6DA5 for ; Tue, 15 Feb 2011 16:43:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 ToC3PA3g8YY1 for ; Tue, 15 Feb 2011 16:43:11 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id A97E43A6D63 for ; Tue, 15 Feb 2011 16:43:11 -0800 (PST) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.60,477,1291593600"; d="scan'208";a="216070837" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 16 Feb 2011 00:43:38 +0000 Received: from [161.44.174.114] (dhcp-161-44-174-114.cisco.com [161.44.174.114]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id p1G0hc4E016311; Wed, 16 Feb 2011 00:43:38 GMT Message-ID: <4D5B1DBA.6040209@cisco.com> Date: Tue, 15 Feb 2011 19:43:38 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: "James M. Polk" References: <4D547232.7020704@nostrum.com> <4D5540B6.1050506@cisco.com> <201102111948.p1BJmXxJ011459@sj-core-3.cisco.com> <4D559C56.1070709@cisco.com> <201102142322.p1ENMj4D020196@sj-core-1.cisco.com> <4D5A88AA.6000705@cisco.com> <201102152336.p1FNaGiE007329@sj-core-1.cisco.com> In-Reply-To: <201102152336.p1FNaGiE007329@sj-core-1.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: sipcore@ietf.org Subject: Re: [sipcore] Geolocation Call 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, 16 Feb 2011 00:43:12 -0000 trimming... On 2/15/2011 6:36 PM, James M. Polk wrote: >>> the existing "routing-allowed" header parameter is a bit of a >>> mislabeling. It doesn't mean "routing" in the L3 or L7 sense of the >>> word, it means "do I (the recipient of this SIP request have permission >>> to view the locally available - or via a dereference transaction that I >>> perform - geolocation information within this SIP request. If >>> "routing-allowed" is set to "=yes", then I have permission to view it >>> and to send the geolocation information to a 3rd party (as many as I >>> want or as many times as I want). If "routing-allowed" is set to "=no", >>> I do not have permission to view or dereference any geolocation >>> information directly or indirectly related to this SIP request, *and* I >>> do not have permission to transmit this location blob to a 3rd party at >>> any time. >> >> Hmm. I thought it was a rule about whether the geoloc info could be >> used to make retargeting decisions. > > correct, but that's secondary. The primary concern is whether or not SIP > intermediaries, as LRs, are even allowed to view (or dereference) > location in the message. If they can (i.e., "Geolocation-Routing: yes"), > then they view this information to make routing decisions. If, OTOH, > "Geolocation-Routing: no" and that intermediary believes (as much as a > machine can 'believe') it has to be able to use the location information > of the Target to make a proper routing decision, the intermediary must > respond with a 424 (Bad Location Information) response including the > following: > > Geolocation-Error: 202 "Permission to Route based on Location > Information" > > This should bubble up to the UI to allow that Target's user to agree (or > not) to reveal their location information to that (and all) SIP > intermediaries for use in making good routing decisions of the > subsequent SIP request. > > Does this make sense? > > So, the answer is yes, it has to do with the actual routing of the > message, but that's a secondary concern to the revelation of the > Target's location information (i.e., it's a little more complicated than > you originally put it). > >> So, IIUC now, you are saying this has to do with routing of the geoloc >> info, not routing of the message containing it. Is that right? > > No, it's a viewability flag for the contained location, then with > permission to view the Target's location information, it's making a good > routing decision based on that location information. If so, then maybe the name of the header field used to transmit the flag should be renamed to something more suggestive of its meaning. I guess that wouldn't be a radical last minute change, since this will be the first time it has its own header field name. Thanks, Paul From jon.peterson@neustar.biz Tue Feb 15 17:11:54 2011 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 D17723A6B6F for ; Tue, 15 Feb 2011 17:11:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.046 X-Spam-Level: X-Spam-Status: No, score=-106.046 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, 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 oDHBnkNJOr6Q for ; Tue, 15 Feb 2011 17:11:52 -0800 (PST) Received: from neustar.com (keys.neustar.biz [156.154.17.104]) by core3.amsl.com (Postfix) with ESMTP id E67E93A6CD1 for ; Tue, 15 Feb 2011 17:11:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1297818732; x=1613168290; q=dns/txt; h=From:Date:Subject:Message-ID:Content-Language: Content-Type:Content-Transfer-Encoding; bh=iWuxYRvK1gVGnukfNbdgS qdaZKc9/2Tcbi6MxUQF51A=; b=fywjetBuOQ6jrio/mZPeihXok8XcumgA8hpkz E+vlU9mbP9PhnSz8/WTeRHc3FurbXsxkuQgYfwUgi9UrzJrHQ== Received: from ([10.31.13.242]) by stihiron2.va.neustar.com with ESMTP with TLS id 5202732.42437371; Tue, 15 Feb 2011 20:12:11 -0500 Received: from STNTEXCH01.cis.neustar.com ([fe80::31b6:4d09:2ada:e6c0]) by STNTEXCHHT03.cis.neustar.com ([::1]) with mapi; Tue, 15 Feb 2011 20:12:11 -0500 From: "Peterson, Jon" To: Paul Kyzivat Date: Tue, 15 Feb 2011 20:12:10 -0500 Thread-Topic: [sipcore] Geolocation Call Thread-Index: AcvNdoneY7vlH1yJS+m2HMKwIY00rA== Message-ID: <182CE620-3D8A-457B-A243-43607B0FEB8D@neustar.biz> References: <4D547232.7020704@nostrum.com> <4D5540B6.1050506@cisco.com> <201102111948.p1BJmXxJ011459@sj-core-3.cisco.com> <4D559C56.1070709@cisco.com> <201102142322.p1ENMj4D020196@sj-core-1.cisco.com> <4D5A88AA.6000705@cisco.com> <201102152336.p1FNaGiE007329@sj-core-1.cisco.com> <4D5B1DBA.6040209@cisco.com> In-Reply-To: <4D5B1DBA.6040209@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: eV0hJdQJF9BDyfjVsRDc8g== Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "sipcore@ietf.org" Subject: Re: [sipcore] Geolocation Call 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, 16 Feb 2011 01:11:55 -0000 How did we start down this rabbit hole? See RFC5606, especially section 3.5= : When "Location-Routing-Allowed" is set to "Yes", the Rule Maker is indicating permission to use the included LI for location-based routing. When "Location-Routing-Allowed" is set to "No", the originator is indicating that this use is not permitted. "Location- Routing-Allowed" being set to "No" has no protocol-level mechanism for enforcement of this behavior; like the PIDF-LO being set to "no", it is a way for the Rule Maker to express a preference to the SIP elements, which are LI recipients. It may, however, present a significant optimization. Where a location-by- reference is included with "Location-Routing-Allowed" set to "No", the SIP elements along the path know that they do not need to attempt to dereference the location information; this is significantly faster than attempting the dereference and being denied at the authentication stage. I wouldn't advise reading any more into this Geolocation-Routing header tha= n the semantics of "location-routing-allowed" above. It is not intended to = be some kind of security mechanism that would prevent a proxy from reading = location information (we have other ways to do that). It does however resol= ve the ambiguity of SIP proxies "retransmitting" location information by me= rely forwarding requests, which in a strict reading of RFC4119 could easily= be inferred. Setting a "routing-allowed" bit of some kind clarifies that t= he Ruler Maker doesn't mind retransmission (even when "retransmission-allow= ed" is set to "no" at a PIDF level) as long as it takes place as in the con= text of normal SIP operations, be it bare forwarding, retargeting or what h= ave you. Jon Peterson NeuStar, Inc. On Feb 15, 2011, at 4:43 PM, Paul Kyzivat wrote: > trimming... >=20 > On 2/15/2011 6:36 PM, James M. Polk wrote: >=20 >>>> the existing "routing-allowed" header parameter is a bit of a >>>> mislabeling. It doesn't mean "routing" in the L3 or L7 sense of the >>>> word, it means "do I (the recipient of this SIP request have permissio= n >>>> to view the locally available - or via a dereference transaction that = I >>>> perform - geolocation information within this SIP request. If >>>> "routing-allowed" is set to "=3Dyes", then I have permission to view i= t >>>> and to send the geolocation information to a 3rd party (as many as I >>>> want or as many times as I want). If "routing-allowed" is set to "=3Dn= o", >>>> I do not have permission to view or dereference any geolocation >>>> information directly or indirectly related to this SIP request, *and* = I >>>> do not have permission to transmit this location blob to a 3rd party a= t >>>> any time. >>>=20 >>> Hmm. I thought it was a rule about whether the geoloc info could be >>> used to make retargeting decisions. >>=20 >> correct, but that's secondary. The primary concern is whether or not SIP >> intermediaries, as LRs, are even allowed to view (or dereference) >> location in the message. If they can (i.e., "Geolocation-Routing: yes"), >> then they view this information to make routing decisions. If, OTOH, >> "Geolocation-Routing: no" and that intermediary believes (as much as a >> machine can 'believe') it has to be able to use the location information >> of the Target to make a proper routing decision, the intermediary must >> respond with a 424 (Bad Location Information) response including the >> following: >>=20 >> Geolocation-Error: 202 "Permission to Route based on Location >> Information" >>=20 >> This should bubble up to the UI to allow that Target's user to agree (or >> not) to reveal their location information to that (and all) SIP >> intermediaries for use in making good routing decisions of the >> subsequent SIP request. >>=20 >> Does this make sense? >>=20 >> So, the answer is yes, it has to do with the actual routing of the >> message, but that's a secondary concern to the revelation of the >> Target's location information (i.e., it's a little more complicated than >> you originally put it). >>=20 >>> So, IIUC now, you are saying this has to do with routing of the geoloc >>> info, not routing of the message containing it. Is that right? >>=20 >> No, it's a viewability flag for the contained location, then with >> permission to view the Target's location information, it's making a good >> routing decision based on that location information. >=20 > If so, then maybe the name of the header field used to transmit the flag= =20 > should be renamed to something more suggestive of its meaning. I guess=20 > that wouldn't be a radical last minute change, since this will be the=20 > first time it has its own header field name. >=20 > Thanks, > Paul > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From rbarnes@bbn.com Tue Feb 15 18:03:33 2011 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 86D063A6C24 for ; Tue, 15 Feb 2011 18:03:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.477 X-Spam-Level: X-Spam-Status: No, score=-102.477 tagged_above=-999 required=5 tests=[AWL=0.122, BAYES_00=-2.599, 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 Glz4QoSyVc6T for ; Tue, 15 Feb 2011 18:03:32 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id 6A82C3A6B6F for ; Tue, 15 Feb 2011 18:03:32 -0800 (PST) Received: from [128.89.253.96] (port=52479 helo=[192.168.1.16]) by smtp.bbn.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.74 (FreeBSD)) (envelope-from ) id 1PpWkH-000M51-Nh; Tue, 15 Feb 2011 21:03:58 -0500 Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: "Richard L. Barnes" In-Reply-To: <182CE620-3D8A-457B-A243-43607B0FEB8D@neustar.biz> Date: Tue, 15 Feb 2011 21:03:54 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <5C79666E-4D08-4B94-A817-15F539E5DB75@bbn.com> References: <4D547232.7020704@nostrum.com> <4D5540B6.1050506@cisco.com> <201102111948.p1BJmXxJ011459@sj-core-3.cisco.com> <4D559C56.1070709@cisco.com> <201102142322.p1ENMj4D020196@sj-core-1.cisco.com> <4D5A88AA.6000705@cisco.com> <201102152336.p1FNaGiE007329@sj-core-1.cisco.com> <4D5B1DBA.6040209@cisco.com> <182CE620-3D8A-457B-A243-43607B0FEB8D@neustar.biz> To: "Peterson, Jon" X-Mailer: Apple Mail (2.1082) Cc: "sipcore@ietf.org" Subject: Re: [sipcore] Geolocation Call 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, 16 Feb 2011 02:03:33 -0000 +1=20 This is a problem for which there is WG consensus on a solution, namely = RFC 5606. --Richard On Feb 15, 2011, at 8:12 PM, Peterson, Jon wrote: >=20 > How did we start down this rabbit hole? See RFC5606, especially = section 3.5: >=20 > When "Location-Routing-Allowed" is set to "Yes", the Rule Maker is > indicating permission to use the included LI for location-based > routing. When "Location-Routing-Allowed" is set to "No", the > originator is indicating that this use is not permitted. "Location- > Routing-Allowed" being set to "No" has no protocol-level mechanism > for enforcement of this behavior; like the PIDF-LO allowed> being set to "no", it is a way for the Rule Maker to = express > a preference to the SIP elements, which are LI recipients. It may, > however, present a significant optimization. Where a location-by- > reference is included with "Location-Routing-Allowed" set to "No", > the SIP elements along the path know that they do not need to = attempt > to dereference the location information; this is significantly = faster > than attempting the dereference and being denied at the > authentication stage. > I wouldn't advise reading any more into this Geolocation-Routing = header than the semantics of "location-routing-allowed" above. It is not = intended to be some kind of security mechanism that would prevent a = proxy from reading location information (we have other ways to do that). = It does however resolve the ambiguity of SIP proxies "retransmitting" = location information by merely forwarding requests, which in a strict = reading of RFC4119 could easily be inferred. Setting a "routing-allowed" = bit of some kind clarifies that the Ruler Maker doesn't mind = retransmission (even when "retransmission-allowed" is set to "no" at a = PIDF level) as long as it takes place as in the context of normal SIP = operations, be it bare forwarding, retargeting or what have you. >=20 > Jon Peterson > NeuStar, Inc. >=20 > On Feb 15, 2011, at 4:43 PM, Paul Kyzivat wrote: >=20 >> trimming... >>=20 >> On 2/15/2011 6:36 PM, James M. Polk wrote: >>=20 >>>>> the existing "routing-allowed" header parameter is a bit of a >>>>> mislabeling. It doesn't mean "routing" in the L3 or L7 sense of = the >>>>> word, it means "do I (the recipient of this SIP request have = permission >>>>> to view the locally available - or via a dereference transaction = that I >>>>> perform - geolocation information within this SIP request. If >>>>> "routing-allowed" is set to "=3Dyes", then I have permission to = view it >>>>> and to send the geolocation information to a 3rd party (as many as = I >>>>> want or as many times as I want). If "routing-allowed" is set to = "=3Dno", >>>>> I do not have permission to view or dereference any geolocation >>>>> information directly or indirectly related to this SIP request, = *and* I >>>>> do not have permission to transmit this location blob to a 3rd = party at >>>>> any time. >>>>=20 >>>> Hmm. I thought it was a rule about whether the geoloc info could be >>>> used to make retargeting decisions. >>>=20 >>> correct, but that's secondary. The primary concern is whether or not = SIP >>> intermediaries, as LRs, are even allowed to view (or dereference) >>> location in the message. If they can (i.e., "Geolocation-Routing: = yes"), >>> then they view this information to make routing decisions. If, OTOH, >>> "Geolocation-Routing: no" and that intermediary believes (as much as = a >>> machine can 'believe') it has to be able to use the location = information >>> of the Target to make a proper routing decision, the intermediary = must >>> respond with a 424 (Bad Location Information) response including the >>> following: >>>=20 >>> Geolocation-Error: 202 "Permission to Route based on Location >>> Information" >>>=20 >>> This should bubble up to the UI to allow that Target's user to agree = (or >>> not) to reveal their location information to that (and all) SIP >>> intermediaries for use in making good routing decisions of the >>> subsequent SIP request. >>>=20 >>> Does this make sense? >>>=20 >>> So, the answer is yes, it has to do with the actual routing of the >>> message, but that's a secondary concern to the revelation of the >>> Target's location information (i.e., it's a little more complicated = than >>> you originally put it). >>>=20 >>>> So, IIUC now, you are saying this has to do with routing of the = geoloc >>>> info, not routing of the message containing it. Is that right? >>>=20 >>> No, it's a viewability flag for the contained location, then with >>> permission to view the Target's location information, it's making a = good >>> routing decision based on that location information. >>=20 >> If so, then maybe the name of the header field used to transmit the = flag=20 >> should be renamed to something more suggestive of its meaning. I = guess=20 >> that wouldn't be a radical last minute change, since this will be the=20= >> first time it has its own header field name. >>=20 >> Thanks, >> Paul >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From pkyzivat@cisco.com Tue Feb 15 18:09:19 2011 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 7330F3A6C24 for ; Tue, 15 Feb 2011 18:09:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 orR1xENtHi1D for ; Tue, 15 Feb 2011 18:09:18 -0800 (PST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 26D843A6B6F for ; Tue, 15 Feb 2011 18:09:18 -0800 (PST) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.60,477,1291593600"; d="scan'208";a="215851021" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 16 Feb 2011 02:09:44 +0000 Received: from [161.44.174.114] (dhcp-161-44-174-114.cisco.com [161.44.174.114]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id p1G29i54016622; Wed, 16 Feb 2011 02:09:44 GMT Message-ID: <4D5B31E8.2040909@cisco.com> Date: Tue, 15 Feb 2011 21:09:44 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: "Peterson, Jon" References: <4D547232.7020704@nostrum.com> <4D5540B6.1050506@cisco.com> <201102111948.p1BJmXxJ011459@sj-core-3.cisco.com> <4D559C56.1070709@cisco.com> <201102142322.p1ENMj4D020196@sj-core-1.cisco.com> <4D5A88AA.6000705@cisco.com> <201102152336.p1FNaGiE007329@sj-core-1.cisco.com> <4D5B1DBA.6040209@cisco.com> <182CE620-3D8A-457B-A243-43607B0FEB8D@neustar.biz> In-Reply-To: <182CE620-3D8A-457B-A243-43607B0FEB8D@neustar.biz> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "sipcore@ietf.org" Subject: Re: [sipcore] Geolocation Call 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, 16 Feb 2011 02:09:19 -0000 Thanks Jon. I never followed the details of all this stuff. But looking at -05, I think the existing text is consistent with what you say. Of course it needs to be tweaked for the switch from parameter to header field. But it does seem to be all about routing of the sip, so I think the chosen name is ok. Thanks, Paul On 2/15/2011 8:12 PM, Peterson, Jon wrote: > > How did we start down this rabbit hole? See RFC5606, especially section 3.5: > > When "Location-Routing-Allowed" is set to "Yes", the Rule Maker is > indicating permission to use the included LI for location-based > routing. When "Location-Routing-Allowed" is set to "No", the > originator is indicating that this use is not permitted. "Location- > Routing-Allowed" being set to "No" has no protocol-level mechanism > for enforcement of this behavior; like the PIDF-LO allowed> being set to "no", it is a way for the Rule Maker to express > a preference to the SIP elements, which are LI recipients. It may, > however, present a significant optimization. Where a location-by- > reference is included with "Location-Routing-Allowed" set to "No", > the SIP elements along the path know that they do not need to attempt > to dereference the location information; this is significantly faster > than attempting the dereference and being denied at the > authentication stage. > I wouldn't advise reading any more into this Geolocation-Routing header than the semantics of "location-routing-allowed" above. It is not intended to be some kind of security mechanism that would prevent a proxy from reading location information (we have other ways to do that). It does however resolve the ambiguity of SIP proxies "retransmitting" location information by merely forwarding requests, which in a strict reading of RFC4119 could easily be inferred. Setting a "routing-allowed" bit of some kind clarifies that the Ruler Maker doesn't mind retransmission (even when "retransmission-allowed" is set to "no" at a PIDF level) as long as it takes place as in the context of normal SIP operations, be it bare forwarding, retargeting or what have you. > > Jon Peterson > NeuStar, Inc. > > On Feb 15, 2011, at 4:43 PM, Paul Kyzivat wrote: > >> trimming... >> >> On 2/15/2011 6:36 PM, James M. Polk wrote: >> >>>>> the existing "routing-allowed" header parameter is a bit of a >>>>> mislabeling. It doesn't mean "routing" in the L3 or L7 sense of the >>>>> word, it means "do I (the recipient of this SIP request have permission >>>>> to view the locally available - or via a dereference transaction that I >>>>> perform - geolocation information within this SIP request. If >>>>> "routing-allowed" is set to "=yes", then I have permission to view it >>>>> and to send the geolocation information to a 3rd party (as many as I >>>>> want or as many times as I want). If "routing-allowed" is set to "=no", >>>>> I do not have permission to view or dereference any geolocation >>>>> information directly or indirectly related to this SIP request, *and* I >>>>> do not have permission to transmit this location blob to a 3rd party at >>>>> any time. >>>> >>>> Hmm. I thought it was a rule about whether the geoloc info could be >>>> used to make retargeting decisions. >>> >>> correct, but that's secondary. The primary concern is whether or not SIP >>> intermediaries, as LRs, are even allowed to view (or dereference) >>> location in the message. If they can (i.e., "Geolocation-Routing: yes"), >>> then they view this information to make routing decisions. If, OTOH, >>> "Geolocation-Routing: no" and that intermediary believes (as much as a >>> machine can 'believe') it has to be able to use the location information >>> of the Target to make a proper routing decision, the intermediary must >>> respond with a 424 (Bad Location Information) response including the >>> following: >>> >>> Geolocation-Error: 202 "Permission to Route based on Location >>> Information" >>> >>> This should bubble up to the UI to allow that Target's user to agree (or >>> not) to reveal their location information to that (and all) SIP >>> intermediaries for use in making good routing decisions of the >>> subsequent SIP request. >>> >>> Does this make sense? >>> >>> So, the answer is yes, it has to do with the actual routing of the >>> message, but that's a secondary concern to the revelation of the >>> Target's location information (i.e., it's a little more complicated than >>> you originally put it). >>> >>>> So, IIUC now, you are saying this has to do with routing of the geoloc >>>> info, not routing of the message containing it. Is that right? >>> >>> No, it's a viewability flag for the contained location, then with >>> permission to view the Target's location information, it's making a good >>> routing decision based on that location information. >> >> If so, then maybe the name of the header field used to transmit the flag >> should be renamed to something more suggestive of its meaning. I guess >> that wouldn't be a radical last minute change, since this will be the >> first time it has its own header field name. >> >> Thanks, >> Paul >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore > > From john.elwell@siemens-enterprise.com Wed Feb 16 02:47:55 2011 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 719C13A6C88 for ; Wed, 16 Feb 2011 02:47:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.654 X-Spam-Level: X-Spam-Status: No, score=-102.654 tagged_above=-999 required=5 tests=[AWL=-0.055, BAYES_00=-2.599, 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 4BuQQTbWw6MM for ; Wed, 16 Feb 2011 02:47:54 -0800 (PST) Received: from ms03.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id D79E23A6C87 for ; Wed, 16 Feb 2011 02:47:53 -0800 (PST) Received: from senmx11-mx ([62.134.46.9] [62.134.46.9]) by ms03.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-3409195; Wed, 16 Feb 2011 11:48:20 +0100 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx11-mx (Server) with ESMTP id 0756F1EB82AE; Wed, 16 Feb 2011 11:48:20 +0100 (CET) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Wed, 16 Feb 2011 11:48:19 +0100 From: "Elwell, John" To: Mary Barnes , SIPCORE Date: Wed, 16 Feb 2011 11:48:18 +0100 Thread-Topic: [sipcore] I-D Action:draft-ietf-sipcore-rfc4244bis-03.txt Thread-Index: AcvMXbynFl56AqSITNmCBWg+XdhgwwBZ5PnA Message-ID: References: <20110214151501.27807.33759.idtracker@localhost> 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] I-D Action:draft-ietf-sipcore-rfc4244bis-03.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, 16 Feb 2011 10:47:55 -0000 It will also take me a long time to review it, but one comment with impact = in a lot of places. We use the terms "escape", "escaped" and "escaping" frequently in the draft= when talking about including a Privacy or Reason header field in the Heade= rs component of a SIP or SIPS URI. RFC 3261 does not use any of these terms= for that purpose. On the contrary, these terms are to do with character re= presentation. So I find it very confusing using these terms in 4244bis when= talking about placing a Privacy or Reason header field in a URI. Of course, it is true that within a Privacy or Reason header field within t= he Headers component of a SIP or SIPS URI, certain characters will need esc= aping (as shown in examples). But if we need to talk about this, we should = talk about character escaping - I think in the majority of cases (all cases= ?) we are talking about the entire header field where it fits within the UR= I (i.e., behind "?") - not specifically about character representation. John > -----Original Message----- > From: sipcore-bounces@ietf.org=20 > [mailto:sipcore-bounces@ietf.org] On Behalf Of Mary Barnes > Sent: 14 February 2011 15:42 > To: SIPCORE > Subject: Re: [sipcore] I-D Action:draft-ietf-sipcore-rfc4244bis-03.txt >=20 > Apologies for the very lengthy delay in getting the document=20 > updated. =20 >=20 > The changes are quite extensive based on all the feedback and=20 > include the following:=20 > 1) Lots of editorial: > a) Reorganized sections similar to the RFC 4244 order - i.e.,=20 > introduce header field parameters and syntax first, then=20 > describe how the functional entities use the header. This=20 > removes redundant (and often inconsistent) text describing=20 > the parameters. > b) Expanded use of "header" to "header field" > c) More precision in terms of "escaping" of the Privacy and=20 > Reason headers in the hi-targeted-to-uri (versus=20 > "adding"/"setting"/etc. them to the hi-entry). > d) Consistent use of parameter names (i.e., hi-entry versus=20 > entry, hi-target versus target, etc.) > e) Moved item 6 in the Index section to the section on=20 > Response handling > f) Removed last remaining vestiges of inline references to=20 > requirements. >=20 >=20 > 2) Clarifications of functionality/applicability including: > a) which messages may contain History-Info > b) removing security text with regards to being able to=20 > figure out if there are missing entries when using TLS (issue #44) > c) More complete information on the new header field=20 > parameters as they relate to the hi-target parameter. =20 > d) Changed wording from passive to active for normative=20 > statements in many cases and removed superfluous normative language.=20 >=20 >=20 > 3) Rewrite of the Privacy section to address issues and=20 > splitting into the setting of the Privacy header fields and=20 > the processing/application of the privacy header field priv-values.=20 >=20 > 4) Rewrite of the Reason header field section - simplifying=20 > the text and adding back the RFC 4244 text with regards to=20 > the use of the Reason header field in cases of internal retargeting.=20 >=20 > I did attempt to cover all the comments, but since alot of=20 > the relevant text changed, it's possible that I missed some=20 > comments. However, we're hoping that folks will find this=20 > version to be easier to follow.=20 >=20 > Regards, > Mary.=20 >=20 > On Mon, Feb 14, 2011 at 9:15 AM, wrote: >=20 >=20 > A New Internet-Draft is available from the on-line=20 > Internet-Drafts directories. > This draft is a work item of the Session Initiation=20 > Protocol Core Working Group of the IETF. > =09 > =09 > Title : An Extension to the Session=20 > Initiation Protocol (SIP) for Request History Information > Author(s) : M. Barnes, et al. > Filename : draft-ietf-sipcore-rfc4244bis-03.txt > Pages : 48 > Date : 2011-02-14 > =09 > This document defines a standard mechanism for=20 > capturing the history > information associated with a Session Initiation Protocol (SIP) > request. This capability enables many enhanced=20 > services by providing > the information as to how and why a SIP request arrives=20 > at a specific > application or user. This document defines an optional=20 > SIP header > field, History-Info, for capturing the history information in > requests. The document also defines SIP header field=20 > parameters for > the History-Info and Contact header fields to tag the=20 > method by which > the target of a request is determined. In addition,=20 > this document > defines a value for the Privacy header field specific=20 > to the History- > Info header field. > =09 > A URL for this Internet-Draft is: > =09 > http://www.ietf.org/internet-drafts/draft-ietf-sipcore-rfc4244 > bis-03.txt > =09 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > =09 > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII=20 > version of the > Internet-Draft. > =09 > =09 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > =09 > =09 >=20 >=20 > = From mary.ietf.barnes@gmail.com Wed Feb 16 11:14:25 2011 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 C5F573A6AAE for ; Wed, 16 Feb 2011 11:14:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.598 X-Spam-Level: X-Spam-Status: No, score=-103.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, 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 S37qutNm4CCO for ; Wed, 16 Feb 2011 11:14:24 -0800 (PST) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by core3.amsl.com (Postfix) with ESMTP id 183793A6D4D for ; Wed, 16 Feb 2011 11:14:24 -0800 (PST) Received: by gyd12 with SMTP id 12so827095gyd.31 for ; Wed, 16 Feb 2011 11:14:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=UCuXXf4jvCgzyXKEMI4ocZXjuEgy3eHyk6a2W3OEybs=; b=LmBwQ20ciIGBmn3paxtIkKruy0wUk4Nd8/K1C7a59h7LURS/N9q1Poc37QPdyyKksn un9IR6a73EwlE5t2ARfPUqTc0Cpg8CFFuWSXW7omjyqrmiCtnbYRY6VUMVYzHVPvFtBD 8CCpeiBtrDZXSFRLRM/FxAi+kGVGOQHsx7V4k= 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=x2O+y6EoOZ0SvNNZ7E4Uy8e1NbiZUkZXu4NFqdGoHKiVGuL1Lk9Tt6fRBPrvwTeuI5 QbiiqMO4QGwHXAL7CxW+OiZEgE8LIPLtjXGNGPNSWyIFSIazbXOqR+9tsD5Y98aihl/Y 56REioiXA130lnyX4Gi9ohaPeR+mTCqKFGwQg= MIME-Version: 1.0 Received: by 10.236.105.161 with SMTP id k21mr1580481yhg.87.1297883692670; Wed, 16 Feb 2011 11:14:52 -0800 (PST) Received: by 10.236.95.35 with HTTP; Wed, 16 Feb 2011 11:14:52 -0800 (PST) In-Reply-To: References: <20110214151501.27807.33759.idtracker@localhost> Date: Wed, 16 Feb 2011 13:14:52 -0600 Message-ID: From: Mary Barnes To: "Elwell, John" Content-Type: multipart/alternative; boundary=90e6ba25e53b7622cf049c6b1800 Cc: SIPCORE Subject: Re: [sipcore] I-D Action:draft-ietf-sipcore-rfc4244bis-03.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, 16 Feb 2011 19:14:25 -0000 --90e6ba25e53b7622cf049c6b1800 Content-Type: text/plain; charset=ISO-8859-1 Hi John, I fully agree that RFC 3261 doesn't specifically describe the use of escaping in the manner used in 4244bis (and 4244). But, that was the term that was suggested to describe the behavior in RFC 4244 - it's way too long ago to remember the discussion that led to the use of the term or whether anyone ever raised an issue about the inconsistency before. The previous feedback for 4244bis was that we needed to be clear as to how the Reason and Privacy were "captured" in the History-Info header field. If folks don't think the term escape is appropriate, then what term is preferred? I guess we could just say that the Reason and Privacy header fields are "added" to the hi-targeted-to-uri using the " "?" mechanism" in the hi-targeted-to-uri, which is consistent with the terminology used in RFC 3261. Another thought would be to include a description of "escape" as used in this document in the terminology section. Thanks, Mary. On Wed, Feb 16, 2011 at 4:48 AM, Elwell, John < john.elwell@siemens-enterprise.com> wrote: > It will also take me a long time to review it, but one comment with impact > in a lot of places. > > We use the terms "escape", "escaped" and "escaping" frequently in the draft > when talking about including a Privacy or Reason header field in the Headers > component of a SIP or SIPS URI. RFC 3261 does not use any of these terms for > that purpose. On the contrary, these terms are to do with character > representation. So I find it very confusing using these terms in 4244bis > when talking about placing a Privacy or Reason header field in a URI. > > Of course, it is true that within a Privacy or Reason header field within > the Headers component of a SIP or SIPS URI, certain characters will need > escaping (as shown in examples). But if we need to talk about this, we > should talk about character escaping - I think in the majority of cases (all > cases?) we are talking about the entire header field where it fits within > the URI (i.e., behind "?") - not specifically about character > representation. > > John > > > -----Original Message----- > > From: sipcore-bounces@ietf.org > > [mailto:sipcore-bounces@ietf.org] On Behalf Of Mary Barnes > > Sent: 14 February 2011 15:42 > > To: SIPCORE > > Subject: Re: [sipcore] I-D Action:draft-ietf-sipcore-rfc4244bis-03.txt > > > > Apologies for the very lengthy delay in getting the document > > updated. > > > > The changes are quite extensive based on all the feedback and > > include the following: > > 1) Lots of editorial: > > a) Reorganized sections similar to the RFC 4244 order - i.e., > > introduce header field parameters and syntax first, then > > describe how the functional entities use the header. This > > removes redundant (and often inconsistent) text describing > > the parameters. > > b) Expanded use of "header" to "header field" > > c) More precision in terms of "escaping" of the Privacy and > > Reason headers in the hi-targeted-to-uri (versus > > "adding"/"setting"/etc. them to the hi-entry). > > d) Consistent use of parameter names (i.e., hi-entry versus > > entry, hi-target versus target, etc.) > > e) Moved item 6 in the Index section to the section on > > Response handling > > f) Removed last remaining vestiges of inline references to > > requirements. > > > > > > 2) Clarifications of functionality/applicability including: > > a) which messages may contain History-Info > > b) removing security text with regards to being able to > > figure out if there are missing entries when using TLS (issue #44) > > c) More complete information on the new header field > > parameters as they relate to the hi-target parameter. > > d) Changed wording from passive to active for normative > > statements in many cases and removed superfluous normative language. > > > > > > 3) Rewrite of the Privacy section to address issues and > > splitting into the setting of the Privacy header fields and > > the processing/application of the privacy header field priv-values. > > > > 4) Rewrite of the Reason header field section - simplifying > > the text and adding back the RFC 4244 text with regards to > > the use of the Reason header field in cases of internal retargeting. > > > > I did attempt to cover all the comments, but since alot of > > the relevant text changed, it's possible that I missed some > > comments. However, we're hoping that folks will find this > > version to be easier to follow. > > > > Regards, > > Mary. > > > > On Mon, Feb 14, 2011 at 9:15 AM, 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 the Session > > Initiation Protocol (SIP) for Request History Information > > Author(s) : M. Barnes, et al. > > Filename : draft-ietf-sipcore-rfc4244bis-03.txt > > Pages : 48 > > Date : 2011-02-14 > > > > This document defines a standard mechanism for > > capturing the history > > information associated with a Session Initiation Protocol (SIP) > > request. This capability enables many enhanced > > services by providing > > the information as to how and why a SIP request arrives > > at a specific > > application or user. This document defines an optional > > SIP header > > field, History-Info, for capturing the history information in > > requests. The document also defines SIP header field > > parameters for > > the History-Info and Contact header fields to tag the > > method by which > > the target of a request is determined. In addition, > > this document > > defines a value for the Privacy header field specific > > to the History- > > Info header field. > > > > A URL for this Internet-Draft is: > > > > http://www.ietf.org/internet-drafts/draft-ietf-sipcore-rfc4244 > > bis-03.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 > > > > > > > > > > > --90e6ba25e53b7622cf049c6b1800 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi John,

I fully agree that RFC 3261 doesn't specifi= cally describe the use of escaping in the manner used in 4244bis (and 4244)= . =A0But, that was the term that was suggested to describe the behavior in = RFC 4244 - it's way too long ago to remember the discussion that led to= the use of the term or whether anyone ever raised an issue about the incon= sistency before. =A0 The previous feedback for 4244bis was that we needed t= o be clear as to how the Reason and Privacy were "captured" in th= e History-Info header field. =A0If folks don't think the term escape is= appropriate, then what term is preferred? =A0I guess we could just say tha= t the Reason and Privacy header fields are "added" to the hi-targ= eted-to-uri using the " "?" mechanism" in the hi-target= ed-to-uri, which is consistent with the terminology used in RFC 3261. =A0An= other thought would be to include a description of "escape" as us= ed in this document in the terminology section. =A0

Thanks,
Mary.=A0

On Wed, Feb 16, 2011 at 4:48 AM, Elwell, John <<= a href=3D"mailto:john.elwell@siemens-enterprise.com">john.elwell@siemens-en= terprise.com> wrote:
It will also take me a long time to review = it, but one comment with impact in a lot of places.

We use the terms "escape", "escaped" and "escaping= " frequently in the draft when talking about including a Privacy or Re= ason header field in the Headers component of a SIP or SIPS URI. RFC 3261 d= oes not use any of these terms for that purpose. On the contrary, these ter= ms are to do with character representation. So I find it very confusing usi= ng these terms in 4244bis when talking about placing a Privacy or Reason he= ader field in a URI.

Of course, it is true that within a Privacy or Reason header field within t= he Headers component of a SIP or SIPS URI, certain characters will need esc= aping (as shown in examples). But if we need to talk about this, we should = talk about character escaping - I think in the majority of cases (all cases= ?) we are talking about the entire header field where it fits within the UR= I (i.e., behind "?") - not specifically about character represent= ation.

John

> -----Original Message-----
> From: sipcore-bounces@ietf= .org
> [mailto:sipcore-bounces@ie= tf.org] On Behalf Of Mary Barnes
> Sent: 14 February 2011 15:42
> To: SIPCORE
> Subject: Re: [sipcore] I-D Action:draft-ietf-sipcore-rfc4244bis-03.txt=
>
> Apologies for the very lengthy delay in getting the document
> updated.
>
> The changes are quite extensive based on all the feedback and
> include the following:
> 1) Lots of editorial:
> a) Reorganized sections similar to the RFC 4244 order - i.e.,
> introduce header field parameters and syntax first, then
> describe how the functional entities use the header. =A0This
> removes redundant =A0(and often inconsistent) text describing
> the parameters.
> b) Expanded use of "header" to "header field"
> c) More precision in terms of "escaping" of the Privacy and<= br> > Reason headers in the hi-targeted-to-uri (versus
> "adding"/"setting"/etc. them to the hi-entry).
> d) Consistent use of parameter names (i.e., hi-entry versus
> entry, hi-target versus target, etc.)
> e) Moved item 6 in the Index section to the section on
> Response handling
> f) Removed last remaining vestiges of inline references to
> requirements.
>
>
> 2) Clarifications of functionality/applicability including:
> a) =A0which messages may contain History-Info
> b) =A0removing security text with regards to being able to
> figure out if there are missing entries when using TLS (issue #44)
> c) More complete information on the new header field
> parameters as they relate to the hi-target parameter.
> d) Changed wording from passive to active for normative
> statements in many cases and removed superfluous normative language. >
>
> 3) Rewrite of the Privacy section to address issues and
> splitting into the setting of the Privacy header fields and
> the processing/application of the privacy header field priv-values. >
> 4) Rewrite of the Reason header field section - simplifying
> the text and adding back the RFC 4244 text with regards to
> the use of the Reason header field in cases of internal retargeting. >
> I did attempt to cover all the comments, but since alot of
> the relevant text changed, it's possible that I missed some
> comments. =A0 However, we're hoping that folks will find this
> version to be easier to follow.
>
> Regards,
> Mary.
>
> On Mon, Feb 14, 2011 at 9:15 AM, <Internet-Drafts@ietf.org> wrote:
>
>
> =A0 =A0 =A0 A New Internet-Draft is available from the on-line
> Internet-Drafts directories.
> =A0 =A0 =A0 This draft is a work item of the Session Initiation
> Protocol Core Working Group of the IETF.
>
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0Title =A0 =A0 =A0 =A0 =A0 : An Extension to= the Session
> Initiation Protocol (SIP) for Request History Information
> =A0 =A0 =A0 =A0 =A0 =A0 =A0Author(s) =A0 =A0 =A0 : M. Barnes, et al. > =A0 =A0 =A0 =A0 =A0 =A0 =A0Filename =A0 =A0 =A0 =A0: draft-ietf-sipcor= e-rfc4244bis-03.txt
> =A0 =A0 =A0 =A0 =A0 =A0 =A0Pages =A0 =A0 =A0 =A0 =A0 : 48
> =A0 =A0 =A0 =A0 =A0 =A0 =A0Date =A0 =A0 =A0 =A0 =A0 =A0: 2011-02-14 >
> =A0 =A0 =A0 This document defines a standard mechanism for
> capturing the history
> =A0 =A0 =A0 information associated with a Session Initiation Protocol = (SIP)
> =A0 =A0 =A0 request. =A0This capability enables many enhanced
> services by providing
> =A0 =A0 =A0 the information as to how and why a SIP request arrives > at a specific
> =A0 =A0 =A0 application or user. =A0This document defines an optional<= br> > SIP header
> =A0 =A0 =A0 field, History-Info, for capturing the history information= in
> =A0 =A0 =A0 requests. =A0The document also defines SIP header field > parameters for
> =A0 =A0 =A0 the History-Info and Contact header fields to tag the
> method by which
> =A0 =A0 =A0 the target of a request is determined. =A0In addition,
> this document
> =A0 =A0 =A0 defines a value for the Privacy header field specific
> to the History-
> =A0 =A0 =A0 Info header field.
>
> =A0 =A0 =A0 A URL for this Internet-Draft is:
>
> http://www.ietf.org/internet-drafts/draft-ietf-sipco= re-rfc4244
> bis-03.txt
>
> =A0 =A0 =A0 Internet-Drafts are also available by anonymous FTP at: > =A0 =A0 =A0 ftp://ftp.ietf.org/internet-drafts/
>
> =A0 =A0 =A0 Below is the data which will enable a MIME compliant mail = reader
> =A0 =A0 =A0 implementation to automatically retrieve the ASCII
> version of the
> =A0 =A0 =A0 Internet-Draft.
>
>
> =A0 =A0 =A0 _______________________________________________
> =A0 =A0 =A0 sipcore mailing list
> =A0 =A0 =A0 sipcore@ietf.org > =A0 =A0 =A0 https://www.ietf.org/mailman/listinfo/sipcore
>
>
>
>
>

--90e6ba25e53b7622cf049c6b1800-- From john.elwell@siemens-enterprise.com Wed Feb 16 12:05:50 2011 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 898B33A6D2A for ; Wed, 16 Feb 2011 12:05:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.652 X-Spam-Level: X-Spam-Status: No, score=-102.652 tagged_above=-999 required=5 tests=[AWL=-0.053, BAYES_00=-2.599, 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 4PvNYTBGC7NQ for ; Wed, 16 Feb 2011 12:05:49 -0800 (PST) Received: from ms02.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id E1C093A6CFF for ; Wed, 16 Feb 2011 12:05:48 -0800 (PST) Received: from senmx11-mx ([62.134.46.9] [62.134.46.9]) by ms02.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-3424355; Wed, 16 Feb 2011 21:06:16 +0100 Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx11-mx (Server) with ESMTP id A351E1EB82AB; Wed, 16 Feb 2011 21:06:16 +0100 (CET) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Wed, 16 Feb 2011 21:06:16 +0100 From: "Elwell, John" To: Mary Barnes Date: Wed, 16 Feb 2011 21:06:14 +0100 Thread-Topic: [sipcore] I-D Action:draft-ietf-sipcore-rfc4244bis-03.txt Thread-Index: AcvODcsRunaQizerRx2f95f7v/hgOQABVJFA Message-ID: References: <20110214151501.27807.33759.idtracker@localhost> 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 Cc: SIPCORE Subject: Re: [sipcore] I-D Action:draft-ietf-sipcore-rfc4244bis-03.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, 16 Feb 2011 20:05:50 -0000 Mary, In fact what we are doing is placing these header fields in the Headers com= ponent of the SIP/SIPS URI - isn't that the proper way to describe it? I kn= ow the escape terminology has been in the draft for a long time, and if oth= ers are happy I guess I can live with it. Perhaps there are precedents in o= ther RFCs. But I am not sure how somebody unfamiliar with this terminology = would interpret it. By the way, what if we have a tel: URI? I don't think that supports "escape= d" header fields. Do our requirements for inserting "escaped" header fields= apply only when the URI is SIP or SIPS? John=20 > -----Original Message----- > From: Mary Barnes [mailto:mary.ietf.barnes@gmail.com]=20 > Sent: 16 February 2011 19:15 > To: Elwell, John > Cc: SIPCORE > Subject: Re: [sipcore] I-D Action:draft-ietf-sipcore-rfc4244bis-03.txt >=20 > Hi John,=20 >=20 > I fully agree that RFC 3261 doesn't specifically describe the=20 > use of escaping in the manner used in 4244bis (and 4244). =20 > But, that was the term that was suggested to describe the=20 > behavior in RFC 4244 - it's way too long ago to remember the=20 > discussion that led to the use of the term or whether anyone=20 > ever raised an issue about the inconsistency before. The=20 > previous feedback for 4244bis was that we needed to be clear=20 > as to how the Reason and Privacy were "captured" in the=20 > History-Info header field. If folks don't think the term=20 > escape is appropriate, then what term is preferred? I guess=20 > we could just say that the Reason and Privacy header fields=20 > are "added" to the hi-targeted-to-uri using the " "?"=20 > mechanism" in the hi-targeted-to-uri, which is consistent=20 > with the terminology used in RFC 3261. Another thought would=20 > be to include a description of "escape" as used in this=20 > document in the terminology section. =20 >=20 > Thanks, > Mary.=20 >=20 >=20 > On Wed, Feb 16, 2011 at 4:48 AM, Elwell, John=20 > wrote: >=20 >=20 > It will also take me a long time to review it, but one=20 > comment with impact in a lot of places. > =09 > We use the terms "escape", "escaped" and "escaping"=20 > frequently in the draft when talking about including a=20 > Privacy or Reason header field in the Headers component of a=20 > SIP or SIPS URI. RFC 3261 does not use any of these terms for=20 > that purpose. On the contrary, these terms are to do with=20 > character representation. So I find it very confusing using=20 > these terms in 4244bis when talking about placing a Privacy=20 > or Reason header field in a URI. > =09 > Of course, it is true that within a Privacy or Reason=20 > header field within the Headers component of a SIP or SIPS=20 > URI, certain characters will need escaping (as shown in=20 > examples). But if we need to talk about this, we should talk=20 > about character escaping - I think in the majority of cases=20 > (all cases?) we are talking about the entire header field=20 > where it fits within the URI (i.e., behind "?") - not=20 > specifically about character representation. > =09 > John > =09 >=20 > > -----Original Message----- > > From: sipcore-bounces@ietf.org > > [mailto:sipcore-bounces@ietf.org] On Behalf Of Mary Barnes > > Sent: 14 February 2011 15:42 > > To: SIPCORE > > Subject: Re: [sipcore] I-D=20 > Action:draft-ietf-sipcore-rfc4244bis-03.txt > > > > Apologies for the very lengthy delay in getting the document > > updated. > > > > The changes are quite extensive based on all the feedback and > > include the following: > > 1) Lots of editorial: > > a) Reorganized sections similar to the RFC 4244 order - i.e., > > introduce header field parameters and syntax first, then > > describe how the functional entities use the header. This > > removes redundant (and often inconsistent) text describing > > the parameters. > > b) Expanded use of "header" to "header field" > > c) More precision in terms of "escaping" of the Privacy and > > Reason headers in the hi-targeted-to-uri (versus > > "adding"/"setting"/etc. them to the hi-entry). > > d) Consistent use of parameter names (i.e., hi-entry versus > > entry, hi-target versus target, etc.) > > e) Moved item 6 in the Index section to the section on > > Response handling > > f) Removed last remaining vestiges of inline references to > > requirements. > > > > > > 2) Clarifications of functionality/applicability including: > > a) which messages may contain History-Info > > b) removing security text with regards to being able to > > figure out if there are missing entries when using=20 > TLS (issue #44) > > c) More complete information on the new header field > > parameters as they relate to the hi-target parameter. > > d) Changed wording from passive to active for normative > > statements in many cases and removed superfluous=20 > normative language. > > > > > > 3) Rewrite of the Privacy section to address issues and > > splitting into the setting of the Privacy header fields and > > the processing/application of the privacy header=20 > field priv-values. > > > > 4) Rewrite of the Reason header field section - simplifying > > the text and adding back the RFC 4244 text with regards to > > the use of the Reason header field in cases of=20 > internal retargeting. > > > > I did attempt to cover all the comments, but since alot of > > the relevant text changed, it's possible that I missed some > > comments. However, we're hoping that folks will find this > > version to be easier to follow. > > > > Regards, > > Mary. > > > > On Mon, Feb 14, 2011 at 9:15 AM,=20 > 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 the Session > > Initiation Protocol (SIP) for Request History Information > > Author(s) : M. Barnes, et al. > > Filename :=20 > draft-ietf-sipcore-rfc4244bis-03.txt > > Pages : 48 > > Date : 2011-02-14 > > > > This document defines a standard mechanism for > > capturing the history > > information associated with a Session=20 > Initiation Protocol (SIP) > > request. This capability enables many enhanced > > services by providing > > the information as to how and why a SIP request arrives > > at a specific > > application or user. This document defines an optional > > SIP header > > field, History-Info, for capturing the history=20 > information in > > requests. The document also defines SIP header field > > parameters for > > the History-Info and Contact header fields to tag the > > method by which > > the target of a request is determined. In addition, > > this document > > defines a value for the Privacy header field specific > > to the History- > > Info header field. > > > > A URL for this Internet-Draft is: > > > > http://www.ietf.org/internet-drafts/draft-ietf-sipcore-rfc4244 > > bis-03.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=20 > 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 > > > > > > > > > >=20 >=20 >=20 > = From john.elwell@siemens-enterprise.com Wed Feb 16 12:14:23 2011 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 D49203A6CE3 for ; Wed, 16 Feb 2011 12:14:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.65 X-Spam-Level: X-Spam-Status: No, score=-102.65 tagged_above=-999 required=5 tests=[AWL=-0.051, BAYES_00=-2.599, 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 0CCwuewqR7r1 for ; Wed, 16 Feb 2011 12:14:22 -0800 (PST) Received: from ms02.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id 2F9B93A6C32 for ; Wed, 16 Feb 2011 12:14:22 -0800 (PST) Received: from senmx12-mx ([62.134.46.10] [62.134.46.10]) by ms02.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-3424424; Wed, 16 Feb 2011 21:14:50 +0100 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx12-mx (Server) with ESMTP id B36AA23F0290; Wed, 16 Feb 2011 21:14:50 +0100 (CET) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Wed, 16 Feb 2011 21:14:50 +0100 From: "Elwell, John" To: Mary Barnes , SIPCORE Date: Wed, 16 Feb 2011 21:14:48 +0100 Thread-Topic: Some comments on draft-ietf-sipcore-rfc4244bis-03.txt Thread-Index: AcvMXbynFl56AqSITNmCBWg+XdhgwwBo5AdQ Message-ID: References: <20110214151501.27807.33759.idtracker@localhost> 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: [sipcore] Some comments on draft-ietf-sipcore-rfc4244bis-03.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, 16 Feb 2011 20:14:23 -0000 Mary, Thanks for this major rewrite and addressing very many earlier comments. I = have some initial comments and also a general comment. Comment 1: Request fails (4xx, say) and as a result a proxy retargets. Acco= rding to 7.1.2, the proxy is required to include in the retargeted request = all entries from received responses so far, including, presumably, entries = in the 4xx response that leads to retargeting. However, if the request does= not contain Supported: histinfo, there will be no entries in received resp= onses. Therefore the final UAS will not receive a complete set of entries. = So we seem to have the strange situation that the set of entries received b= y the UAS is dependent on support of History-Info at the UAC. This seems wr= ong. It seems to me that entries should always be sent backwards, subject t= o privacy, and perhaps not on the last hop if the UAC doesn't support it. Comment 2: Suppose a proxy forwards a request to two targets, one with entr= y index 1.1 and the other with entry index 1.2. A provisional or final resp= onse is received to the first forwarded request containing an additional en= try with index 1.1.1. Then a 4xx response is received to the second request= , causing the proxy to retarget, this time with an entry index 1.3. Accordi= ng to 7.1.2 step 1, that retargeted request should contain entries 1, 1.1.1= , 1.2 and 1.3. Note that 1.1 is missing. I see nothing to require the inclu= sion of 1.1, yet step 1 of 7.1.2 seems to require inclusion of 1.1.1. Have = I misinterpreted something? Comment 3: In 7.2 it states: "...MUST forward captured History-Info in subsequent, provisional, and final responses to the request sent by the ultimate UAS (see Section 6.2)..." When a proxy forwards a provisional response, how does it know that this is= from the ultimate UAS? This can only be known when the first 2xx arrives. = In fact the term "ultimate UAS" is also problematic because how does a prox= y know that a response has come from a UAS, as opposed to a proxy? General comment: I found it really hard to understand how all the different procedures in se= ctions 6, 7 and 8 fitted together, and I tried to analyse what exactly is g= oing on. I came to the conclusion that, to a first approximation, we are tr= ying to specify the following: 1. Procedures for receiving a request - Cache the sequence of entries received. - If no entry or if last entry does not match Request-URI, create one and a= dd it to the cache. 2. Procedures for sending a request - Include all cached entries (if any). - Also include an entry reflecting the Request-URI of the sent request (not= quite sure if this should go in the cache at this stage). - In case of recursing, include in that new entry parameters from the Conta= ct header field of the 3XX response. 3. Procedures for receiving a response (other than 100) - Add to the cache any entries in the response not already in the cache. 4. Procedures for sending a response (other than 100) - Include all cached entries. I am sure this is an over simplification. It doesn't take account of the pr= esence of the option tag in Supported (influences response behaviour), priv= acy considerations, populating the index, etc.. Also there are clearly some= issues concerning exactly what a proxy includes from previous targetings w= hen it retargets, what goes in provisional responses, and so on (impacted b= y the comments above, no doubt). However, I can't help feeling there might = be a much simpler way of documenting all this. John =20 > -----Original Message----- > From: sipcore-bounces@ietf.org=20 > [mailto:sipcore-bounces@ietf.org] On Behalf Of Mary Barnes > Sent: 14 February 2011 15:42 > To: SIPCORE > Subject: Re: [sipcore] I-D Action:draft-ietf-sipcore-rfc4244bis-03.txt >=20 > Apologies for the very lengthy delay in getting the document=20 > updated. =20 >=20 > The changes are quite extensive based on all the feedback and=20 > include the following:=20 > 1) Lots of editorial: > a) Reorganized sections similar to the RFC 4244 order - i.e.,=20 > introduce header field parameters and syntax first, then=20 > describe how the functional entities use the header. This=20 > removes redundant (and often inconsistent) text describing=20 > the parameters. > b) Expanded use of "header" to "header field" > c) More precision in terms of "escaping" of the Privacy and=20 > Reason headers in the hi-targeted-to-uri (versus=20 > "adding"/"setting"/etc. them to the hi-entry). > d) Consistent use of parameter names (i.e., hi-entry versus=20 > entry, hi-target versus target, etc.) > e) Moved item 6 in the Index section to the section on=20 > Response handling > f) Removed last remaining vestiges of inline references to=20 > requirements. >=20 >=20 > 2) Clarifications of functionality/applicability including: > a) which messages may contain History-Info > b) removing security text with regards to being able to=20 > figure out if there are missing entries when using TLS (issue #44) > c) More complete information on the new header field=20 > parameters as they relate to the hi-target parameter. =20 > d) Changed wording from passive to active for normative=20 > statements in many cases and removed superfluous normative language.=20 >=20 >=20 > 3) Rewrite of the Privacy section to address issues and=20 > splitting into the setting of the Privacy header fields and=20 > the processing/application of the privacy header field priv-values.=20 >=20 > 4) Rewrite of the Reason header field section - simplifying=20 > the text and adding back the RFC 4244 text with regards to=20 > the use of the Reason header field in cases of internal retargeting.=20 >=20 > I did attempt to cover all the comments, but since alot of=20 > the relevant text changed, it's possible that I missed some=20 > comments. However, we're hoping that folks will find this=20 > version to be easier to follow.=20 >=20 > Regards, > Mary.=20 >=20 > On Mon, Feb 14, 2011 at 9:15 AM, wrote: >=20 >=20 > A New Internet-Draft is available from the on-line=20 > Internet-Drafts directories. > This draft is a work item of the Session Initiation=20 > Protocol Core Working Group of the IETF. > =09 > =09 > Title : An Extension to the Session=20 > Initiation Protocol (SIP) for Request History Information > Author(s) : M. Barnes, et al. > Filename : draft-ietf-sipcore-rfc4244bis-03.txt > Pages : 48 > Date : 2011-02-14 > =09 > This document defines a standard mechanism for=20 > capturing the history > information associated with a Session Initiation Protocol (SIP) > request. This capability enables many enhanced=20 > services by providing > the information as to how and why a SIP request arrives=20 > at a specific > application or user. This document defines an optional=20 > SIP header > field, History-Info, for capturing the history information in > requests. The document also defines SIP header field=20 > parameters for > the History-Info and Contact header fields to tag the=20 > method by which > the target of a request is determined. In addition,=20 > this document > defines a value for the Privacy header field specific=20 > to the History- > Info header field. > =09 > A URL for this Internet-Draft is: > =09 > http://www.ietf.org/internet-drafts/draft-ietf-sipcore-rfc4244 bis-03.txt > =09 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > =09 > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII=20 > version of the > Internet-Draft. > =09 > =09 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > =09 > =09 >=20 >=20 > = From mary.ietf.barnes@gmail.com Wed Feb 16 14:56:12 2011 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 21B353A6D92 for ; Wed, 16 Feb 2011 14:56:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.598 X-Spam-Level: X-Spam-Status: No, score=-103.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, 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 oMyn30tcTEIE for ; Wed, 16 Feb 2011 14:56:10 -0800 (PST) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by core3.amsl.com (Postfix) with ESMTP id E92583A6D6F for ; Wed, 16 Feb 2011 14:56:09 -0800 (PST) Received: by yxt33 with SMTP id 33so931286yxt.31 for ; Wed, 16 Feb 2011 14:56:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=j1ed2177g2l4vmfAm3jMd62dI/YPHdixUlXKqqF/mAM=; b=lgLJ0orPn7RcC4++RivKJhI6Km/Z5/6V/6NHH0FLB8q/SH4RZU1tQ+MGtbwKOsL2WT dOWuWsQiBsvuIdhW6KUv+yN8BXwTijDLO26gMVHmYnV+L8U9WtlNst6vveSpUENqZbwQ gu48IVk+MARXe3YFgc9gllceJV6JI9/p2aFT8= 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=WXoyBPbE4tCZNJrs1HA4Ydq9UdRfV0K+yaAPds84q39IImVL2G092dmKw/JVVrYAjb BEZFtrzn2vprM1AmgRqMfbvQGWR1a3uEb6lJISsTTX7A/rLQ3F5w6265oy2Kv0+I0Jm3 qM/XQkBdrkJ4FNiWdt54pgPt7oI49RH/t2tsc= MIME-Version: 1.0 Received: by 10.236.103.145 with SMTP id f17mr2115199yhg.61.1297896997213; Wed, 16 Feb 2011 14:56:37 -0800 (PST) Received: by 10.236.95.35 with HTTP; Wed, 16 Feb 2011 14:56:37 -0800 (PST) In-Reply-To: References: <20110214151501.27807.33759.idtracker@localhost> Date: Wed, 16 Feb 2011 16:56:37 -0600 Message-ID: From: Mary Barnes To: "Elwell, John" Content-Type: multipart/alternative; boundary=0023547c9023796a2d049c6e3182 Cc: SIPCORE Subject: Re: [sipcore] I-D Action:draft-ietf-sipcore-rfc4244bis-03.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, 16 Feb 2011 22:56:12 -0000 --0023547c9023796a2d049c6e3182 Content-Type: text/plain; charset=ISO-8859-1 Responses inline below [MB]. On Wed, Feb 16, 2011 at 2:06 PM, Elwell, John < john.elwell@siemens-enterprise.com> wrote: > Mary, > > In fact what we are doing is placing these header fields in the Headers > component of the SIP/SIPS URI - isn't that the proper way to describe it? I > know the escape terminology has been in the draft for a long time, and if > others are happy I guess I can live with it. Perhaps there are precedents in > other RFCs. But I am not sure how somebody unfamiliar with this terminology > would interpret it. > [MB] Yes, we are putting the header fields in the "headers" parameter in the SIP/SIPS URI. So, we can change the wording to reflect such. Again, I have no recollection of the logic behind using the term escape. We could probably dig through the archives and see when that was introduced. In looking at some some charts from the IETF-60 discussion of 4244 in its draft for it is quite interesting, as one of the issues was one that you identified [JRE-7] and the chart states that "...the Privacy header is added to the request or escaped as part of the targeted-to-uri". I have no issue with changing the wording as you suggest. [/MB] > > By the way, what if we have a tel: URI? I don't think that supports > "escaped" header fields. Do our requirements for inserting "escaped" header > fields apply only when the URI is SIP or SIPS? > [MB] Correct - the Reason and Privacy header fields can only be used for SIP or SIPS URIs. Hadriel brought up this issue and there is text in there with regards to this issue. [/MB] > > John > > > -----Original Message----- > > From: Mary Barnes [mailto:mary.ietf.barnes@gmail.com] > > Sent: 16 February 2011 19:15 > > To: Elwell, John > > Cc: SIPCORE > > Subject: Re: [sipcore] I-D Action:draft-ietf-sipcore-rfc4244bis-03.txt > > > > Hi John, > > > > I fully agree that RFC 3261 doesn't specifically describe the > > use of escaping in the manner used in 4244bis (and 4244). > > But, that was the term that was suggested to describe the > > behavior in RFC 4244 - it's way too long ago to remember the > > discussion that led to the use of the term or whether anyone > > ever raised an issue about the inconsistency before. The > > previous feedback for 4244bis was that we needed to be clear > > as to how the Reason and Privacy were "captured" in the > > History-Info header field. If folks don't think the term > > escape is appropriate, then what term is preferred? I guess > > we could just say that the Reason and Privacy header fields > > are "added" to the hi-targeted-to-uri using the " "?" > > mechanism" in the hi-targeted-to-uri, which is consistent > > with the terminology used in RFC 3261. Another thought would > > be to include a description of "escape" as used in this > > document in the terminology section. > > > > Thanks, > > Mary. > > > > > > On Wed, Feb 16, 2011 at 4:48 AM, Elwell, John > > wrote: > > > > > > It will also take me a long time to review it, but one > > comment with impact in a lot of places. > > > > We use the terms "escape", "escaped" and "escaping" > > frequently in the draft when talking about including a > > Privacy or Reason header field in the Headers component of a > > SIP or SIPS URI. RFC 3261 does not use any of these terms for > > that purpose. On the contrary, these terms are to do with > > character representation. So I find it very confusing using > > these terms in 4244bis when talking about placing a Privacy > > or Reason header field in a URI. > > > > Of course, it is true that within a Privacy or Reason > > header field within the Headers component of a SIP or SIPS > > URI, certain characters will need escaping (as shown in > > examples). But if we need to talk about this, we should talk > > about character escaping - I think in the majority of cases > > (all cases?) we are talking about the entire header field > > where it fits within the URI (i.e., behind "?") - not > > specifically about character representation. > > > > John > > > > > > > -----Original Message----- > > > From: sipcore-bounces@ietf.org > > > [mailto:sipcore-bounces@ietf.org] On Behalf Of Mary Barnes > > > Sent: 14 February 2011 15:42 > > > To: SIPCORE > > > Subject: Re: [sipcore] I-D > > Action:draft-ietf-sipcore-rfc4244bis-03.txt > > > > > > Apologies for the very lengthy delay in getting the document > > > updated. > > > > > > The changes are quite extensive based on all the feedback and > > > include the following: > > > 1) Lots of editorial: > > > a) Reorganized sections similar to the RFC 4244 order - i.e., > > > introduce header field parameters and syntax first, then > > > describe how the functional entities use the header. This > > > removes redundant (and often inconsistent) text describing > > > the parameters. > > > b) Expanded use of "header" to "header field" > > > c) More precision in terms of "escaping" of the Privacy and > > > Reason headers in the hi-targeted-to-uri (versus > > > "adding"/"setting"/etc. them to the hi-entry). > > > d) Consistent use of parameter names (i.e., hi-entry versus > > > entry, hi-target versus target, etc.) > > > e) Moved item 6 in the Index section to the section on > > > Response handling > > > f) Removed last remaining vestiges of inline references to > > > requirements. > > > > > > > > > 2) Clarifications of functionality/applicability including: > > > a) which messages may contain History-Info > > > b) removing security text with regards to being able to > > > figure out if there are missing entries when using > > TLS (issue #44) > > > c) More complete information on the new header field > > > parameters as they relate to the hi-target parameter. > > > d) Changed wording from passive to active for normative > > > statements in many cases and removed superfluous > > normative language. > > > > > > > > > 3) Rewrite of the Privacy section to address issues and > > > splitting into the setting of the Privacy header fields and > > > the processing/application of the privacy header > > field priv-values. > > > > > > 4) Rewrite of the Reason header field section - simplifying > > > the text and adding back the RFC 4244 text with regards to > > > the use of the Reason header field in cases of > > internal retargeting. > > > > > > I did attempt to cover all the comments, but since alot of > > > the relevant text changed, it's possible that I missed some > > > comments. However, we're hoping that folks will find this > > > version to be easier to follow. > > > > > > Regards, > > > Mary. > > > > > > On Mon, Feb 14, 2011 at 9:15 AM, > > 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 the Session > > > Initiation Protocol (SIP) for Request History Information > > > Author(s) : M. Barnes, et al. > > > Filename : > > draft-ietf-sipcore-rfc4244bis-03.txt > > > Pages : 48 > > > Date : 2011-02-14 > > > > > > This document defines a standard mechanism for > > > capturing the history > > > information associated with a Session > > Initiation Protocol (SIP) > > > request. This capability enables many enhanced > > > services by providing > > > the information as to how and why a SIP request arrives > > > at a specific > > > application or user. This document defines an optional > > > SIP header > > > field, History-Info, for capturing the history > > information in > > > requests. The document also defines SIP header field > > > parameters for > > > the History-Info and Contact header fields to tag the > > > method by which > > > the target of a request is determined. In addition, > > > this document > > > defines a value for the Privacy header field specific > > > to the History- > > > Info header field. > > > > > > A URL for this Internet-Draft is: > > > > > > http://www.ietf.org/internet-drafts/draft-ietf-sipcore-rfc4244 > > > bis-03.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 > > > > > > > > > > > > > > > > > > > > > > --0023547c9023796a2d049c6e3182 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Responses inline below [MB].

On Wed, Feb = 16, 2011 at 2:06 PM, Elwell, John <john.elwell@siemens-enterprise.com&g= t; wrote:
Mary,

In fact what we are doing is placing these header fields in the Headers com= ponent of the SIP/SIPS URI - isn't that the proper way to describe it? = I know the escape terminology has been in the draft for a long time, and if= others are happy I guess I can live with it. Perhaps there are precedents = in other RFCs. But I am not sure how somebody unfamiliar with this terminol= ogy would interpret it.
[MB] Yes, we are putting the header fields in the "h= eaders" parameter =A0in the SIP/SIPS URI. =A0So, we can change the wor= ding to reflect such. Again, I have no recollection of the logic behind usi= ng the term escape. We could probably dig through the archives and see when= that was introduced. In looking at some some charts from the IETF-60 discu= ssion of 4244 in its draft for=A0it is quite interesting, as one of the iss= ues was one that you identified [JRE-7] and the chart states that "...= the Privacy header is added to the request or escaped as part of the target= ed-to-uri". I have no issue with changing the wording as you suggest. = [/MB]

By the way, what if we have a tel: URI? I don't think that supports &qu= ot;escaped" header fields. Do our requirements for inserting "esc= aped" header fields apply only when the URI is SIP or SIPS?
[MB] Correct - the Reason and Privacy header fields can only be used f= or SIP or SIPS URIs. Hadriel brought up this issue and there is text in the= re with regards to this issue. [/MB]=A0

John

> -----Original Message-----
> From: Mary Barnes [mailto:mary.ietf.barnes@gmail.com]
> Sent: 16 February 2011 19:15
> To: Elwell, John
> Cc: SIPCORE
> Subject: Re: [sipcore] I-D Action:draft-ietf-sipcore-rfc4244bis-03.txt=
>
> Hi John,
>
> I fully agree that RFC 3261 doesn't specifically describe the
> use of escaping in the manner used in 4244bis (and 4244).
> But, that was the term that was suggested to describe the
> behavior in RFC 4244 - it's way too long ago to remember the
> discussion that led to the use of the term or whether anyone
> ever raised an issue about the inconsistency before. =A0 The
> previous feedback for 4244bis was that we needed to be clear
> as to how the Reason and Privacy were "captured" in the
> History-Info header field. =A0If folks don't think the term
> escape is appropriate, then what term is preferred? =A0I guess
> we could just say that the Reason and Privacy header fields
> are "added" to the hi-targeted-to-uri using the " "= ;?"
> mechanism" in the hi-targeted-to-uri, which is consistent
> with the terminology used in RFC 3261. =A0Another thought would
> be to include a description of "escape" as used in this
> document in the terminology section.
>
> Thanks,
> Mary.
>
>
> On Wed, Feb 16, 2011 at 4:48 AM, Elwell, John
> <john.elwell@= siemens-enterprise.com> wrote:
>
>
> =A0 =A0 =A0 It will also take me a long time to review it, but one
> comment with impact in a lot of places.
>
> =A0 =A0 =A0 We use the terms "escape", "escaped" a= nd "escaping"
> frequently in the draft when talking about including a
> Privacy or Reason header field in the Headers component of a
> SIP or SIPS URI. RFC 3261 does not use any of these terms for
> that purpose. On the contrary, these terms are to do with
> character representation. So I find it very confusing using
> these terms in 4244bis when talking about placing a Privacy
> or Reason header field in a URI.
>
> =A0 =A0 =A0 Of course, it is true that within a Privacy or Reason
> header field within the Headers component of a SIP or SIPS
> URI, certain characters will need escaping (as shown in
> examples). But if we need to talk about this, we should talk
> about character escaping - I think in the majority of cases
> (all cases?) we are talking about the entire header field
> where it fits within the URI (i.e., behind "?") - not
> specifically about character representation.
>
> =A0 =A0 =A0 John
>
>
> =A0 =A0 =A0 > -----Original Message-----
> =A0 =A0 =A0 > From: sip= core-bounces@ietf.org
> =A0 =A0 =A0 > [mailto:s= ipcore-bounces@ietf.org] On Behalf Of Mary Barnes
> =A0 =A0 =A0 > Sent: 14 February 2011 15:42
> =A0 =A0 =A0 > To: SIPCORE
> =A0 =A0 =A0 > Subject: Re: [sipcore] I-D
> Action:draft-ietf-sipcore-rfc4244bis-03.txt
> =A0 =A0 =A0 >
> =A0 =A0 =A0 > Apologies for the very lengthy delay in getting the d= ocument
> =A0 =A0 =A0 > updated.
> =A0 =A0 =A0 >
> =A0 =A0 =A0 > The changes are quite extensive based on all the feed= back and
> =A0 =A0 =A0 > include the following:
> =A0 =A0 =A0 > 1) Lots of editorial:
> =A0 =A0 =A0 > a) Reorganized sections similar to the RFC 4244 order= - i.e.,
> =A0 =A0 =A0 > introduce header field parameters and syntax first, t= hen
> =A0 =A0 =A0 > describe how the functional entities use the header. = =A0This
> =A0 =A0 =A0 > removes redundant =A0(and often inconsistent) text de= scribing
> =A0 =A0 =A0 > the parameters.
> =A0 =A0 =A0 > b) Expanded use of "header" to "header= field"
> =A0 =A0 =A0 > c) More precision in terms of "escaping" of= the Privacy and
> =A0 =A0 =A0 > Reason headers in the hi-targeted-to-uri (versus
> =A0 =A0 =A0 > "adding"/"setting"/etc. them to t= he hi-entry).
> =A0 =A0 =A0 > d) Consistent use of parameter names (i.e., hi-entry = versus
> =A0 =A0 =A0 > entry, hi-target versus target, etc.)
> =A0 =A0 =A0 > e) Moved item 6 in the Index section to the section o= n
> =A0 =A0 =A0 > Response handling
> =A0 =A0 =A0 > f) Removed last remaining vestiges of inline referenc= es to
> =A0 =A0 =A0 > requirements.
> =A0 =A0 =A0 >
> =A0 =A0 =A0 >
> =A0 =A0 =A0 > 2) Clarifications of functionality/applicability incl= uding:
> =A0 =A0 =A0 > a) =A0which messages may contain History-Info
> =A0 =A0 =A0 > b) =A0removing security text with regards to being ab= le to
> =A0 =A0 =A0 > figure out if there are missing entries when using > TLS (issue #44)
> =A0 =A0 =A0 > c) More complete information on the new header field<= br> > =A0 =A0 =A0 > parameters as they relate to the hi-target parameter.=
> =A0 =A0 =A0 > d) Changed wording from passive to active for normati= ve
> =A0 =A0 =A0 > statements in many cases and removed superfluous
> normative language.
> =A0 =A0 =A0 >
> =A0 =A0 =A0 >
> =A0 =A0 =A0 > 3) Rewrite of the Privacy section to address issues a= nd
> =A0 =A0 =A0 > splitting into the setting of the Privacy header fiel= ds and
> =A0 =A0 =A0 > the processing/application of the privacy header
> field priv-values.
> =A0 =A0 =A0 >
> =A0 =A0 =A0 > 4) Rewrite of the Reason header field section - simpl= ifying
> =A0 =A0 =A0 > the text and adding back the RFC 4244 text with regar= ds to
> =A0 =A0 =A0 > the use of the Reason header field in cases of
> internal retargeting.
> =A0 =A0 =A0 >
> =A0 =A0 =A0 > I did attempt to cover all the comments, but since al= ot of
> =A0 =A0 =A0 > the relevant text changed, it's possible that I m= issed some
> =A0 =A0 =A0 > comments. =A0 However, we're hoping that folks wi= ll find this
> =A0 =A0 =A0 > version to be easier to follow.
> =A0 =A0 =A0 >
> =A0 =A0 =A0 > Regards,
> =A0 =A0 =A0 > Mary.
> =A0 =A0 =A0 >
> =A0 =A0 =A0 > On Mon, Feb 14, 2011 at 9:15 AM,
> <Internet-Drafts@ietf.o= rg> wrote:
> =A0 =A0 =A0 >
> =A0 =A0 =A0 >
> =A0 =A0 =A0 > =A0 =A0 =A0 A New Internet-Draft is available from th= e on-line
> =A0 =A0 =A0 > Internet-Drafts directories.
> =A0 =A0 =A0 > =A0 =A0 =A0 This draft is a work item of the Session = Initiation
> =A0 =A0 =A0 > Protocol Core Working Group of the IETF.
> =A0 =A0 =A0 >
> =A0 =A0 =A0 >
> =A0 =A0 =A0 > =A0 =A0 =A0 =A0 =A0 =A0 =A0Title =A0 =A0 =A0 =A0 =A0 = : An Extension to the Session
> =A0 =A0 =A0 > Initiation Protocol (SIP) for Request History Informa= tion
> =A0 =A0 =A0 > =A0 =A0 =A0 =A0 =A0 =A0 =A0Author(s) =A0 =A0 =A0 : M.= Barnes, et al.
> =A0 =A0 =A0 > =A0 =A0 =A0 =A0 =A0 =A0 =A0Filename =A0 =A0 =A0 =A0:<= br> > draft-ietf-sipcore-rfc4244bis-03.txt
> =A0 =A0 =A0 > =A0 =A0 =A0 =A0 =A0 =A0 =A0Pages =A0 =A0 =A0 =A0 =A0 = : 48
> =A0 =A0 =A0 > =A0 =A0 =A0 =A0 =A0 =A0 =A0Date =A0 =A0 =A0 =A0 =A0 = =A0: 2011-02-14
> =A0 =A0 =A0 >
> =A0 =A0 =A0 > =A0 =A0 =A0 This document defines a standard mechanis= m for
> =A0 =A0 =A0 > capturing the history
> =A0 =A0 =A0 > =A0 =A0 =A0 information associated with a Session
> Initiation Protocol (SIP)
> =A0 =A0 =A0 > =A0 =A0 =A0 request. =A0This capability enables many = enhanced
> =A0 =A0 =A0 > services by providing
> =A0 =A0 =A0 > =A0 =A0 =A0 the information as to how and why a SIP r= equest arrives
> =A0 =A0 =A0 > at a specific
> =A0 =A0 =A0 > =A0 =A0 =A0 application or user. =A0This document def= ines an optional
> =A0 =A0 =A0 > SIP header
> =A0 =A0 =A0 > =A0 =A0 =A0 field, History-Info, for capturing the hi= story
> information in
> =A0 =A0 =A0 > =A0 =A0 =A0 requests. =A0The document also defines SI= P header field
> =A0 =A0 =A0 > parameters for
> =A0 =A0 =A0 > =A0 =A0 =A0 the History-Info and Contact header field= s to tag the
> =A0 =A0 =A0 > method by which
> =A0 =A0 =A0 > =A0 =A0 =A0 the target of a request is determined. = =A0In addition,
> =A0 =A0 =A0 > this document
> =A0 =A0 =A0 > =A0 =A0 =A0 defines a value for the Privacy header fi= eld specific
> =A0 =A0 =A0 > to the History-
> =A0 =A0 =A0 > =A0 =A0 =A0 Info header field.
> =A0 =A0 =A0 >
> =A0 =A0 =A0 > =A0 =A0 =A0 A URL for this Internet-Draft is:
> =A0 =A0 =A0 >
> =A0 =A0 =A0 > http://www.ietf.org/internet-drafts= /draft-ietf-sipcore-rfc4244
> =A0 =A0 =A0 > bis-03.txt
> =A0 =A0 =A0 >
> =A0 =A0 =A0 > =A0 =A0 =A0 Internet-Drafts are also available by ano= nymous FTP at:
> =A0 =A0 =A0 > =A0 =A0 =A0 ftp://ftp.ietf.org/internet-drafts/
> =A0 =A0 =A0 >
> =A0 =A0 =A0 > =A0 =A0 =A0 Below is the data which will enable a MIM= E
> compliant mail reader
> =A0 =A0 =A0 > =A0 =A0 =A0 implementation to automatically retrieve = the ASCII
> =A0 =A0 =A0 > version of the
> =A0 =A0 =A0 > =A0 =A0 =A0 Internet-Draft.
> =A0 =A0 =A0 >
> =A0 =A0 =A0 >
> =A0 =A0 =A0 > =A0 =A0 =A0 _________________________________________= ______
> =A0 =A0 =A0 > =A0 =A0 =A0 sipcore mailing list
> =A0 =A0 =A0 > =A0 =A0 =A0 sipco= re@ietf.org
> =A0 =A0 =A0 > =A0 =A0 =A0 https://www.ietf.org/mailman/listinfo/si= pcore
> =A0 =A0 =A0 >
> =A0 =A0 =A0 >
> =A0 =A0 =A0 >
> =A0 =A0 =A0 >
> =A0 =A0 =A0 >
>
>
>

--0023547c9023796a2d049c6e3182-- From adam@nostrum.com Wed Feb 16 15:03:46 2011 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 E18353A6D92 for ; Wed, 16 Feb 2011 15:03:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.581 X-Spam-Level: X-Spam-Status: No, score=-102.581 tagged_above=-999 required=5 tests=[AWL=0.018, BAYES_00=-2.599, 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 3gbnoYCfm7Kc for ; Wed, 16 Feb 2011 15:03:45 -0800 (PST) Received: from nostrum.com (shaman.nostrum.com [72.232.179.90]) by core3.amsl.com (Postfix) with ESMTP id B2AF23A6AD5 for ; Wed, 16 Feb 2011 15:03:45 -0800 (PST) Received: from dn3-228.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 p1GN2nRe098067 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Wed, 16 Feb 2011 17:02:49 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <4D5C5799.9030203@nostrum.com> Date: Wed, 16 Feb 2011 17:02:49 -0600 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Paul Kyzivat References: <4D547232.7020704@nostrum.com> <4D5540B6.1050506@cisco.com> <201102111948.p1BJmXxJ011459@sj-core-3.cisco.com> <4D559C56.1070709@cisco.com> <201102142322.p1ENMj4D020196@sj-core-1.cisco.com> <4D5A88AA.6000705@cisco.com> <201102152336.p1FNaGiE007329@sj-core-1.cisco.com> <4D5B1DBA.6040209@cisco.com> <182CE620-3D8A-457B-A243-43607B0FEB8D@neustar.biz> <4D5B31E8.2040909@cisco.com> In-Reply-To: <4D5B31E8.2040909@cisco.com> 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: "sipcore@ietf.org" Subject: Re: [sipcore] Geolocation Call 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, 16 Feb 2011 23:03:47 -0000 [as chair] This appears to mostly come down to what intermediaries can do when no "Location-Routing" field is present. What I think I've heard everyone agree to in this thread is: If an intermediary inserts location into a SIP message and finds no "Location-Routing" header field, it may insert its own, with either "yes" or "no," according to its local policy. As a corollary; if a client doesn't insert a location but wants to suppress intermediaries from reading one that may be inserted later, then it explicitly adds a "Location-Routing: no" field. If an intermediary finds a SIP message with a "Location" field but no "Location-Routing" field, it may not dereference the location. Does that accurately summarize everyone's position? If so, I don't think we need a phone call tomorrow. If anyone disagrees, then I'd like to use the call tomorrow to wrestle this issue to the ground. /a On 2/15/11 8:09 PM, Paul Kyzivat wrote: > Thanks Jon. I never followed the details of all this stuff. > > But looking at -05, I think the existing text is consistent with what > you say. Of course it needs to be tweaked for the switch from > parameter to header field. But it does seem to be all about routing of > the sip, so I think the chosen name is ok. > > Thanks, > Paul > > On 2/15/2011 8:12 PM, Peterson, Jon wrote: >> >> How did we start down this rabbit hole? See RFC5606, especially >> section 3.5: >> >> When "Location-Routing-Allowed" is set to "Yes", the Rule Maker is >> indicating permission to use the included LI for location-based >> routing. When "Location-Routing-Allowed" is set to "No", the >> originator is indicating that this use is not permitted. "Location- >> Routing-Allowed" being set to "No" has no protocol-level mechanism >> for enforcement of this behavior; like the PIDF-LO> allowed> being set to "no", it is a way for the Rule Maker to >> express >> a preference to the SIP elements, which are LI recipients. It may, >> however, present a significant optimization. Where a location-by- >> reference is included with "Location-Routing-Allowed" set to "No", >> the SIP elements along the path know that they do not need to >> attempt >> to dereference the location information; this is significantly >> faster >> than attempting the dereference and being denied at the >> authentication stage. >> I wouldn't advise reading any more into this Geolocation-Routing >> header than the semantics of "location-routing-allowed" above. It is >> not intended to be some kind of security mechanism that would prevent >> a proxy from reading location information (we have other ways to do >> that). It does however resolve the ambiguity of SIP proxies >> "retransmitting" location information by merely forwarding requests, >> which in a strict reading of RFC4119 could easily be inferred. >> Setting a "routing-allowed" bit of some kind clarifies that the Ruler >> Maker doesn't mind retransmission (even when "retransmission-allowed" >> is set to "no" at a PIDF level) as long as it takes place as in the >> context of normal SIP operations, be it bare forwarding, retargeting >> or what have you. >> >> Jon Peterson >> NeuStar, Inc. >> >> On Feb 15, 2011, at 4:43 PM, Paul Kyzivat wrote: >> >>> trimming... >>> >>> On 2/15/2011 6:36 PM, James M. Polk wrote: >>> >>>>>> the existing "routing-allowed" header parameter is a bit of a >>>>>> mislabeling. It doesn't mean "routing" in the L3 or L7 sense of the >>>>>> word, it means "do I (the recipient of this SIP request have >>>>>> permission >>>>>> to view the locally available - or via a dereference transaction >>>>>> that I >>>>>> perform - geolocation information within this SIP request. If >>>>>> "routing-allowed" is set to "=yes", then I have permission to >>>>>> view it >>>>>> and to send the geolocation information to a 3rd party (as many as I >>>>>> want or as many times as I want). If "routing-allowed" is set to >>>>>> "=no", >>>>>> I do not have permission to view or dereference any geolocation >>>>>> information directly or indirectly related to this SIP request, >>>>>> *and* I >>>>>> do not have permission to transmit this location blob to a 3rd >>>>>> party at >>>>>> any time. >>>>> >>>>> Hmm. I thought it was a rule about whether the geoloc info could be >>>>> used to make retargeting decisions. >>>> >>>> correct, but that's secondary. The primary concern is whether or >>>> not SIP >>>> intermediaries, as LRs, are even allowed to view (or dereference) >>>> location in the message. If they can (i.e., "Geolocation-Routing: >>>> yes"), >>>> then they view this information to make routing decisions. If, OTOH, >>>> "Geolocation-Routing: no" and that intermediary believes (as much as a >>>> machine can 'believe') it has to be able to use the location >>>> information >>>> of the Target to make a proper routing decision, the intermediary must >>>> respond with a 424 (Bad Location Information) response including the >>>> following: >>>> >>>> Geolocation-Error: 202 "Permission to Route based on Location >>>> Information" >>>> >>>> This should bubble up to the UI to allow that Target's user to >>>> agree (or >>>> not) to reveal their location information to that (and all) SIP >>>> intermediaries for use in making good routing decisions of the >>>> subsequent SIP request. >>>> >>>> Does this make sense? >>>> >>>> So, the answer is yes, it has to do with the actual routing of the >>>> message, but that's a secondary concern to the revelation of the >>>> Target's location information (i.e., it's a little more complicated >>>> than >>>> you originally put it). >>>> >>>>> So, IIUC now, you are saying this has to do with routing of the >>>>> geoloc >>>>> info, not routing of the message containing it. Is that right? >>>> >>>> No, it's a viewability flag for the contained location, then with >>>> permission to view the Target's location information, it's making a >>>> good >>>> routing decision based on that location information. >>> >>> If so, then maybe the name of the header field used to transmit the >>> flag >>> should be renamed to something more suggestive of its meaning. I guess >>> that wouldn't be a radical last minute change, since this will be the >>> first time it has its own header field name. >>> >>> Thanks, >>> Paul >>> _______________________________________________ >>> sipcore mailing list >>> sipcore@ietf.org >>> https://www.ietf.org/mailman/listinfo/sipcore >> >> > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From mary.ietf.barnes@gmail.com Wed Feb 16 15:28:58 2011 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 B4AD23A6CE4 for ; Wed, 16 Feb 2011 15:28:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.298 X-Spam-Level: X-Spam-Status: No, score=-103.298 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_LOW=-1, 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 pc4U3tzP1qPD for ; Wed, 16 Feb 2011 15:28:51 -0800 (PST) Received: from mail-yi0-f44.google.com (mail-yi0-f44.google.com [209.85.218.44]) by core3.amsl.com (Postfix) with ESMTP id 0AEC33A6AB9 for ; Wed, 16 Feb 2011 15:28:50 -0800 (PST) Received: by yie19 with SMTP id 19so943536yie.31 for ; Wed, 16 Feb 2011 15:29:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=Xhhnmf+FE/3vc7WtZsFbVdTvWJpvqK0ZSQMji2UppyI=; b=nGGySrdxTa9eTJmD19C+KY78D1qxXQAV+xBv77s4nAScnTNy2F+TGUibgvSwSs8rDv qgCvx4V4fBUmZ2F++blOyy135yKVaBuJ6ceqNmenZX1DWZhoCnd+eYuL+TkGliUkBqqa 0j8bK7WhCSN+rGLurur1pepF/fGqM0jAPzZfM= 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=TljFBG2Aw70nBLy3MJNSCg6wz7P5qxLe4Zg16FnjPcVFBqamK9ZPwj/XfahH3o6mnj NNOu21J43zyjCs59zCIQBki5ahwG81UPFztVVBRTZvyKuuWUv6CJuTQWb6ndmD8PHRBN uW1y/aoIejbiYDJ1VNUVO77aVNaMNy4fK1qlQ= MIME-Version: 1.0 Received: by 10.236.108.43 with SMTP id p31mr2058188yhg.22.1297898959959; Wed, 16 Feb 2011 15:29:19 -0800 (PST) Received: by 10.236.95.35 with HTTP; Wed, 16 Feb 2011 15:29:19 -0800 (PST) In-Reply-To: References: <20110214151501.27807.33759.idtracker@localhost> Date: Wed, 16 Feb 2011 17:29:19 -0600 Message-ID: From: Mary Barnes To: "Elwell, John" Content-Type: multipart/alternative; boundary=90e6ba4fbe2e767784049c6ea6ce Cc: SIPCORE Subject: Re: [sipcore] Some comments on draft-ietf-sipcore-rfc4244bis-03.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, 16 Feb 2011 23:28:58 -0000 --90e6ba4fbe2e767784049c6ea6ce Content-Type: text/plain; charset=ISO-8859-1 Hi John, Thanks for the comments. Responses inline below [MB]. Mary. On Wed, Feb 16, 2011 at 2:14 PM, Elwell, John < john.elwell@siemens-enterprise.com> wrote: > Mary, > > Thanks for this major rewrite and addressing very many earlier comments. I > have some initial comments and also a general comment. > > Comment 1: Request fails (4xx, say) and as a result a proxy retargets. > According to 7.1.2, the proxy is required to include in the retargeted > request all entries from received responses so far, including, presumably, > entries in the 4xx response that leads to retargeting. However, if the > request does not contain Supported: histinfo, there will be no entries in > received responses. Therefore the final UAS will not receive a complete set > of entries. So we seem to have the strange situation that the set of entries > received by the UAS is dependent on support of History-Info at the UAC. This > seems wrong. It seems to me that entries should always be sent backwards, > subject to privacy, and perhaps not on the last hop if the UAC doesn't > support it. > [MB] > > Comment 2: Suppose a proxy forwards a request to two targets, one with > entry index 1.1 and the other with entry index 1.2. A provisional or final > response is received to the first forwarded request containing an additional > entry with index 1.1.1. Then a 4xx response is received to the second > request, causing the proxy to retarget, this time with an entry index 1.3. > According to 7.1.2 step 1, that retargeted request should contain entries 1, > 1.1.1, 1.2 and 1.3. Note that 1.1 is missing. I see nothing to require the > inclusion of 1.1, yet step 1 of 7.1.2 seems to require inclusion of 1.1.1. > Have I misinterpreted something? > [MB] 1.1 should also be included. Perhaps the wording needs clarification, but the text is attempting to state that in cases where > > Comment 3: In 7.2 it states: > "...MUST forward captured History-Info in > subsequent, provisional, and final responses to the request sent by > the ultimate UAS (see Section 6.2)..." > When a proxy forwards a provisional response, how does it know that this is > from the ultimate UAS? This can only be known when the first 2xx arrives. In > fact the term "ultimate UAS" is also problematic because how does a proxy > know that a response has come from a UAS, as opposed to a proxy? > [MB] It doesn't know that it's the ultimate UAS, so=o we should remove that phrase. It's attempting to highlight that all the information is sent in the responses, but that's really covered elsewhere. [/MB] > > General comment: > I found it really hard to understand how all the different procedures in > sections 6, 7 and 8 fitted together, and I tried to analyse what exactly is > going on. I came to the conclusion that, to a first approximation, we are > trying to specify the following: > > 1. Procedures for receiving a request > - Cache the sequence of entries received. > - If no entry or if last entry does not match Request-URI, create one and > add it to the cache. > > 2. Procedures for sending a request > - Include all cached entries (if any). > - Also include an entry reflecting the Request-URI of the sent request (not > quite sure if this should go in the cache at this stage). > - In case of recursing, include in that new entry parameters from the > Contact header field of the 3XX response. > > 3. Procedures for receiving a response (other than 100) > - Add to the cache any entries in the response not already in the cache. > > 4. Procedures for sending a response (other than 100) > - Include all cached entries. > > I am sure this is an over simplification. It doesn't take account of the > presence of the option tag in Supported (influences response behaviour), > privacy considerations, populating the index, etc.. Also there are clearly > some issues concerning exactly what a proxy includes from previous > targetings when it retargets, what goes in provisional responses, and so on > (impacted by the comments above, no doubt). However, I can't help feeling > there might be a much simpler way of documenting all this. > [MB] At this point, having worked on this document way too long, it's really hard for me to see how to make it more clear. It really is fairly simple. The intent of 7.1.1 was to define the steps similar to your simplified summary above. As far as handling the privacy, that applies to the entirety of the hi-entries being included in an outgoing request per the rules that we tried to highlight in the updated privacy section. The mechanism by which the index is calculated is referenced in the appropriate sections and included all in one place. I could see that we could spread out how all the parameters are determined directly in the processing flow and within the discussion of the specific cases, however, that isn't nearly as modular IMHO. We did have some of it previously, but we also had inconsistencies by doing so (and overuse of normative statements at least as I interpreted WG feedback). IMHO the current form is easier from an implementors perspective. And, the form of this document is not dramatically unlike other RFCs, including RFC 3261 although the ABNF is earlier in the document in 4244bis. 4244bis follows the model of describing processing for each of the functional entities and then has sections that describe the handling for each protocol element. From a quick glance RFC 4028 (Session timer) and RFC 3325 (P-Asserted-Identity) have separate sections for Proxy and UA behaviors, as well although the ABNF is later (but again we got feedback that it should be earlier. It's really a chicken egg thing in my opinion as to whether you see the protocol elements first and whether the normative behavior for each parameter is separate from the processing flow for the SIP entities and whether the latter is separated - i.e., we could have a handling the request section that includes the UAC and SIP intermediary behavior and then have a response section that includes SIP intermediary and UAS processing. But, again I personally feel that have the sections separate is more useful for implementors that are in many cases developing code for only a single functional entity. [/MB] > > John > > > -----Original Message----- > > From: sipcore-bounces@ietf.org > > [mailto:sipcore-bounces@ietf.org] On Behalf Of Mary Barnes > > Sent: 14 February 2011 15:42 > > To: SIPCORE > > Subject: Re: [sipcore] I-D Action:draft-ietf-sipcore-rfc4244bis-03.txt > > > > Apologies for the very lengthy delay in getting the document > > updated. > > > > The changes are quite extensive based on all the feedback and > > include the following: > > 1) Lots of editorial: > > a) Reorganized sections similar to the RFC 4244 order - i.e., > > introduce header field parameters and syntax first, then > > describe how the functional entities use the header. This > > removes redundant (and often inconsistent) text describing > > the parameters. > > b) Expanded use of "header" to "header field" > > c) More precision in terms of "escaping" of the Privacy and > > Reason headers in the hi-targeted-to-uri (versus > > "adding"/"setting"/etc. them to the hi-entry). > > d) Consistent use of parameter names (i.e., hi-entry versus > > entry, hi-target versus target, etc.) > > e) Moved item 6 in the Index section to the section on > > Response handling > > f) Removed last remaining vestiges of inline references to > > requirements. > > > > > > 2) Clarifications of functionality/applicability including: > > a) which messages may contain History-Info > > b) removing security text with regards to being able to > > figure out if there are missing entries when using TLS (issue #44) > > c) More complete information on the new header field > > parameters as they relate to the hi-target parameter. > > d) Changed wording from passive to active for normative > > statements in many cases and removed superfluous normative language. > > > > > > 3) Rewrite of the Privacy section to address issues and > > splitting into the setting of the Privacy header fields and > > the processing/application of the privacy header field priv-values. > > > > 4) Rewrite of the Reason header field section - simplifying > > the text and adding back the RFC 4244 text with regards to > > the use of the Reason header field in cases of internal retargeting. > > > > I did attempt to cover all the comments, but since alot of > > the relevant text changed, it's possible that I missed some > > comments. However, we're hoping that folks will find this > > version to be easier to follow. > > > > Regards, > > Mary. > > > > On Mon, Feb 14, 2011 at 9:15 AM, 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 the Session > > Initiation Protocol (SIP) for Request History Information > > Author(s) : M. Barnes, et al. > > Filename : draft-ietf-sipcore-rfc4244bis-03.txt > > Pages : 48 > > Date : 2011-02-14 > > > > This document defines a standard mechanism for > > capturing the history > > information associated with a Session Initiation Protocol (SIP) > > request. This capability enables many enhanced > > services by providing > > the information as to how and why a SIP request arrives > > at a specific > > application or user. This document defines an optional > > SIP header > > field, History-Info, for capturing the history information in > > requests. The document also defines SIP header field > > parameters for > > the History-Info and Contact header fields to tag the > > method by which > > the target of a request is determined. In addition, > > this document > > defines a value for the Privacy header field specific > > to the History- > > Info header field. > > > > A URL for this Internet-Draft is: > > > > http://www.ietf.org/internet-drafts/draft-ietf-sipcore-rfc4244 > bis-03.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 > > > > > > > > > > --90e6ba4fbe2e767784049c6ea6ce Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi John,

Thanks for the comments. Responses inline below= [MB].

Mary.

On = Wed, Feb 16, 2011 at 2:14 PM, Elwell, John <john.elwell@siemens-enterprise.= com> wrote:
Mary,

Thanks for this major rewrite and addressing very many earlier comments. I = have some initial comments and also a general comment.

Comment 1: Request fails (4xx, say) and as a result a proxy retargets. Acco= rding to 7.1.2, the proxy is required to include in the retargeted request = all entries from received responses so far, including, presumably, entries = in the 4xx response that leads to retargeting. However, if the request does= not contain Supported: histinfo, there will be no entries in received resp= onses. Therefore the final UAS will not receive a complete set of entries. = So we seem to have the strange situation that the set of entries received b= y the UAS is dependent on support of History-Info at the UAC. This seems wr= ong. It seems to me that entries should always be sent backwards, subject t= o privacy, and perhaps not on the last hop if the UAC doesn't support i= t.=A0
=A0[MB]=A0

Comment 2: Suppose a proxy forwards a request to two targets, one with entr= y index 1.1 and the other with entry index 1.2. A provisional or final resp= onse is received to the first forwarded request containing an additional en= try with index 1.1.1. Then a 4xx response is received to the second request= , causing the proxy to retarget, this time with an entry index 1.3. Accordi= ng to 7.1.2 step 1, that retargeted request should contain entries 1, 1.1.1= , 1.2 and 1.3. Note that 1.1 is missing. I see nothing to require the inclu= sion of 1.1, yet step 1 of 7.1.2 seems to require inclusion of 1.1.1. Have = I misinterpreted something?
[MB] 1.1 should also be included. Perhaps the wording nee= ds clarification, but the text is attempting to state that in cases where = =A0

Comment 3: In 7.2 it states:
"...MUST forward captured History-Info in
=A0 subsequent, provisional, and final responses to the request sent by =A0 the ultimate UAS (see Section 6.2)..."
When a proxy forwards a provisional response, how does it know that this is= from the ultimate UAS? This can only be known when the first 2xx arrives. = In fact the term "ultimate UAS" is also problematic because how d= oes a proxy know that a response has come from a UAS, as opposed to a proxy= ?
[MB] It doesn't know that it's the ultimate UAS, = so=3Do we should remove that phrase. =A0It's attempting to highlight th= at all the information is sent in the responses, but that's really cove= red elsewhere. [/MB]

General comment:
I found it really hard to understand how all the different procedures in se= ctions 6, 7 and 8 fitted together, and I tried to analyse what exactly is g= oing on. I came to the conclusion that, to a first approximation, we are tr= ying to specify the following:

1. Procedures for receiving a request
- Cache the sequence of entries received.
- If no entry or if last entry does not match Request-URI, create one and a= dd it to the cache.

2. Procedures for sending a request
- Include all cached entries (if any).
- Also include an entry reflecting the Request-URI of the sent request (not= quite sure if this should go in the cache at this stage).
- In case of recursing, include in that new entry parameters from the Conta= ct header field of the 3XX response.

3. Procedures for receiving a response (other than 100)
- Add to the cache any entries in the response not already in the cache.
4. Procedures for sending a response (other than 100)
- Include all cached entries.

I am sure this is an over simplification. It doesn't take account of th= e presence of the option tag in Supported (influences response behaviour), = privacy considerations, populating the index, etc.. Also there are clearly = some issues concerning exactly what a proxy includes from previous targetin= gs when it retargets, what goes in provisional responses, and so on (impact= ed by the comments above, no doubt). However, I can't help feeling ther= e might be a much simpler way of documenting all this.
[MB] At this point, having worked on this document way to= o long, it's really hard for me to see how to make it more clear. =A0It= really is fairly simple.=A0The intent of 7.1.1 was to define the steps sim= ilar to your simplified summary above.=A0As far as handling the privacy, th= at applies to the entirety of the hi-entries being included in an outgoing = request per the rules that we tried to highlight in the updated privacy sec= tion. =A0The mechanism by which the index is calculated is referenced in th= e appropriate sections and included all in one place. =A0I could see that w= e could spread out how all the parameters are determined directly in the pr= ocessing flow and within the discussion of the specific cases, however, tha= t isn't nearly as modular IMHO. We did have some of it previously, but = we also had inconsistencies by doing so (and overuse of normative statement= s at least as I interpreted WG feedback). =A0 IMHO =A0the current form is e= asier from an implementors perspective. And, the form of this document is n= ot dramatically unlike other RFCs, including RFC 3261 although the ABNF is = earlier in the document in 4244bis. 4244bis follows the model of describing= processing for each of the functional entities and then has sections that = describe the handling for each protocol element. =A0From a quick glance RFC= 4028 (Session timer) and =A0RFC 3325 (P-Asserted-Identity) have separate s= ections for Proxy and UA behaviors, as well although the ABNF is later (but= again we got feedback that it should be earlier. It's really a chicken= egg thing in my opinion as to whether you see the protocol elements first = and whether the normative behavior for each parameter is separate from the = processing flow for the SIP entities and whether the latter is separated - = i.e., we could have a handling the request section that includes the UAC an= d SIP intermediary behavior and then have a response section that includes = SIP intermediary and UAS processing. =A0But, again I personally feel that h= ave the sections separate is more useful for implementors that are in many = cases developing code for only a single functional entity. =A0[/MB]
=A0

John

> -----Original Message-----
> From: sipcore-bounces@ietf= .org
> [mailto:sipcore-bounces@ie= tf.org] On Behalf Of Mary Barnes
> Sent: 14 February 2011 15:42
> To: SIPCORE
> Subject: Re: [sipcore] I-D Action:draft-ietf-sipcore-rfc4244bis-03.txt=
>
> Apologies for the very lengthy delay in getting the document
> updated.
>
> The changes are quite extensive based on all the feedback and
> include the following:
> 1) Lots of editorial:
> a) Reorganized sections similar to the RFC 4244 order - i.e.,
> introduce header field parameters and syntax first, then
> describe how the functional entities use the header. =A0This
> removes redundant =A0(and often inconsistent) text describing
> the parameters.
> b) Expanded use of "header" to "header field"
> c) More precision in terms of "escaping" of the Privacy and<= br> > Reason headers in the hi-targeted-to-uri (versus
> "adding"/"setting"/etc. them to the hi-entry).
> d) Consistent use of parameter names (i.e., hi-entry versus
> entry, hi-target versus target, etc.)
> e) Moved item 6 in the Index section to the section on
> Response handling
> f) Removed last remaining vestiges of inline references to
> requirements.
>
>
> 2) Clarifications of functionality/applicability including:
> a) =A0which messages may contain History-Info
> b) =A0removing security text with regards to being able to
> figure out if there are missing entries when using TLS (issue #44)
> c) More complete information on the new header field
> parameters as they relate to the hi-target parameter.
> d) Changed wording from passive to active for normative
> statements in many cases and removed superfluous normative language. >
>
> 3) Rewrite of the Privacy section to address issues and
> splitting into the setting of the Privacy header fields and
> the processing/application of the privacy header field priv-values. >
> 4) Rewrite of the Reason header field section - simplifying
> the text and adding back the RFC 4244 text with regards to
> the use of the Reason header field in cases of internal retargeting. >
> I did attempt to cover all the comments, but since alot of
> the relevant text changed, it's possible that I missed some
> comments. =A0 However, we're hoping that folks will find this
> version to be easier to follow.
>
> Regards,
> Mary.
>
> On Mon, Feb 14, 2011 at 9:15 AM, <Internet-Drafts@ietf.org> wrote:
>
>
> =A0 =A0 =A0 A New Internet-Draft is available from the on-line
> Internet-Drafts directories.
> =A0 =A0 =A0 This draft is a work item of the Session Initiation
> Protocol Core Working Group of the IETF.
>
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0Title =A0 =A0 =A0 =A0 =A0 : An Extension to= the Session
> Initiation Protocol (SIP) for Request History Information
> =A0 =A0 =A0 =A0 =A0 =A0 =A0Author(s) =A0 =A0 =A0 : M. Barnes, et al. > =A0 =A0 =A0 =A0 =A0 =A0 =A0Filename =A0 =A0 =A0 =A0: draft-ietf-sipcor= e-rfc4244bis-03.txt
> =A0 =A0 =A0 =A0 =A0 =A0 =A0Pages =A0 =A0 =A0 =A0 =A0 : 48
> =A0 =A0 =A0 =A0 =A0 =A0 =A0Date =A0 =A0 =A0 =A0 =A0 =A0: 2011-02-14 >
> =A0 =A0 =A0 This document defines a standard mechanism for
> capturing the history
> =A0 =A0 =A0 information associated with a Session Initiation Protocol = (SIP)
> =A0 =A0 =A0 request. =A0This capability enables many enhanced
> services by providing
> =A0 =A0 =A0 the information as to how and why a SIP request arrives > at a specific
> =A0 =A0 =A0 application or user. =A0This document defines an optional<= br> > SIP header
> =A0 =A0 =A0 field, History-Info, for capturing the history information= in
> =A0 =A0 =A0 requests. =A0The document also defines SIP header field > parameters for
> =A0 =A0 =A0 the History-Info and Contact header fields to tag the
> method by which
> =A0 =A0 =A0 the target of a request is determined. =A0In addition,
> this document
> =A0 =A0 =A0 defines a value for the Privacy header field specific
> to the History-
> =A0 =A0 =A0 Info header field.
>
> =A0 =A0 =A0 A URL for this Internet-Draft is:
>
> http://www.ietf.org/internet-drafts/draft-iet= f-sipcore-rfc4244
bis-03.txt
>
> =A0 =A0 =A0 Internet-Drafts are also available by anonymous FTP at: > =A0 =A0 =A0 ftp://ftp.ietf.org/internet-drafts/
>
> =A0 =A0 =A0 Below is the data which will enable a MIME compliant mail = reader
> =A0 =A0 =A0 implementation to automatically retrieve the ASCII
> version of the
> =A0 =A0 =A0 Internet-Draft.
>
>
> =A0 =A0 =A0 _______________________________________________
> =A0 =A0 =A0 sipcore mailing list
> =A0 =A0 =A0 sipcore@ietf.org > =A0 =A0 =A0 https://www.ietf.org/mailman/listinfo/sipcore
>
>
>
>
>

--90e6ba4fbe2e767784049c6ea6ce-- From jmpolk@cisco.com Wed Feb 16 15:46:11 2011 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 B39F93A6D7C for ; Wed, 16 Feb 2011 15:46:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.574 X-Spam-Level: X-Spam-Status: No, score=-110.574 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 mrL0rqloeGbH for ; Wed, 16 Feb 2011 15:46:10 -0800 (PST) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 383673A6C34 for ; Wed, 16 Feb 2011 15:46:10 -0800 (PST) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.60,482,1291593600"; d="scan'208";a="330996401" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-5.cisco.com with ESMTP; 16 Feb 2011 23:46:39 +0000 Received: from jmpolk-wxp01.cisco.com (rcdn-jmpolk-8716.cisco.com [10.99.80.23]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id p1GNkdDV019674; Wed, 16 Feb 2011 23:46:39 GMT Message-Id: <201102162346.p1GNkdDV019674@sj-core-1.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 16 Feb 2011 17:46:37 -0600 To: Adam Roach , Paul Kyzivat From: "James M. Polk" In-Reply-To: <4D5C5799.9030203@nostrum.com> References: <4D547232.7020704@nostrum.com> <4D5540B6.1050506@cisco.com> <201102111948.p1BJmXxJ011459@sj-core-3.cisco.com> <4D559C56.1070709@cisco.com> <201102142322.p1ENMj4D020196@sj-core-1.cisco.com> <4D5A88AA.6000705@cisco.com> <201102152336.p1FNaGiE007329@sj-core-1.cisco.com> <4D5B1DBA.6040209@cisco.com> <182CE620-3D8A-457B-A243-43607B0FEB8D@neustar.biz> <4D5B31E8.2040909@cisco.com> <4D5C5799.9030203@nostrum.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: "sipcore@ietf.org" Subject: Re: [sipcore] Geolocation Call 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, 16 Feb 2011 23:46:11 -0000 At 05:02 PM 2/16/2011, Adam Roach wrote: >[as chair] > >This appears to mostly come down to what intermediaries can do when >no "Location-Routing" field is present. What I think I've heard >everyone agree to in this thread is: > >If an intermediary inserts location into a SIP message and finds no >"Location-Routing" header field, it may insert its own, with either >"yes" or "no," according to its local policy. As a corollary; if a >client doesn't insert a location but wants to suppress >intermediaries from reading one that may be inserted later, then it >explicitly adds a "Location-Routing: no" field. > >If an intermediary finds a SIP message with a "Location" field but >no "Location-Routing" field, it may not dereference the location. > >Does that accurately summarize everyone's position? Adam (and all) To answer your question above - I think you have it right. I think the only real play (or uncertainty) is when there is no Geolocation header field, and what to do when there is one of the three possibilities for the Geolocation-Routing. With that in mind, I have tentatively added a table in -06 of the 12 possibilities I can think of for the combinations of Geolocation and Geolocation-Routing header fields, focusing on a Geolocation-Routing "=no", "=yes", and when no Gelocation-Routing header field is present (with or without a Geolocation header field). I've come up with the following - that only Jon has seen so far. I'd like to get feedback on this - have I got everything I need in the table? - did I miss anything? - have I gotten anything wrong in the table? - should I expand what I say in the Geolocation-Routing column? and finally: - should this table be included in -06? Here's the table as it currently is in the rough draft of -06: " Based on the above, the following table explains the 12 known combinations of Geo-based header fields. Geo-based header combinations Geolocation-Routing ---------------------------------- ------------------- a single locationValue in a single Implicitly set to "=no" Geolocation header instance within the same SIP request, with no Geolocation-Routing header present. more than one locationValue in a Implicitly set to "=no" single Geolocation header instance within the same SIP request, with no Geolocation-Routing header present. more than one locationValue in more Implicitly set to "=no" than one Geolocation header instance within the same SIP request, with no Geolocation-Routing header present. a single locationValue in a single Explicitly set to "=no" Geolocation header instance within the same SIP request, with single Geolocation-Routing header-value "=no". more than one locationValue in a Explicitly set to "=no" single Geolocation header instance within the same SIP request, with single Geolocation-Routing header-value "=no". more than one locationValue in more Explicitly set to "=no" than one Geolocation header instance within the same SIP request, with single Geolocation-Routing header-value "=no". a single locationValue in a single Explicitly set to "=yes" Geolocation header instance within the same SIP request, with single Geolocation-Routing header-value "=yes". more than one locationValue in a Explicitly set to "=yes" single Geolocation header instance within the same SIP request, with single Geolocation-Routing header-value "=yes". more than one locationValue in more Explicitly set to "=yes" than one Geolocation header instance within the same SIP request, with single Geolocation-Routing header-value "=yes". no Geolocation header instance within Default Geolocation-Routing a SIP request, with no is open and can be set by a Geolocation-Routing header present. downstream entity or not at all. no Geolocation header instance within Location viewing policy set a SIP request, with single already such Geolocation-Routing header-value "=no". Location viewing policy set already such that no intermediaries can view location inserted downstream. no Geolocation header instance within Location viewing policy set a SIP request, with single already such that if Geolocation-Routing header-value location is inserted "=yes". downstream, intermediaries can maintain an open viewing of location policy or can change policy to "=no" for intermediaries further downstream. " James >If so, I don't think we need a phone call tomorrow. If anyone >disagrees, then I'd like to use the call tomorrow to wrestle this >issue to the ground. > >/a > >On 2/15/11 8:09 PM, Paul Kyzivat wrote: >>Thanks Jon. I never followed the details of all this stuff. >> >>But looking at -05, I think the existing text is consistent with >>what you say. Of course it needs to be tweaked for the switch from >>parameter to header field. But it does seem to be all about routing >>of the sip, so I think the chosen name is ok. >> >> Thanks, >> Paul >> >>On 2/15/2011 8:12 PM, Peterson, Jon wrote: >>> >>>How did we start down this rabbit hole? See RFC5606, especially section 3.5: >>> >>> When "Location-Routing-Allowed" is set to "Yes", the Rule Maker is >>> indicating permission to use the included LI for location-based >>> routing. When "Location-Routing-Allowed" is set to "No", the >>> originator is indicating that this use is not permitted. "Location- >>> Routing-Allowed" being set to "No" has no protocol-level mechanism >>> for enforcement of this behavior; like the PIDF-LO>> allowed> being set to "no", it is a way for the Rule Maker to express >>> a preference to the SIP elements, which are LI recipients. It may, >>> however, present a significant optimization. Where a location-by- >>> reference is included with "Location-Routing-Allowed" set to "No", >>> the SIP elements along the path know that they do not need to attempt >>> to dereference the location information; this is significantly faster >>> than attempting the dereference and being denied at the >>> authentication stage. >>>I wouldn't advise reading any more into this Geolocation-Routing >>>header than the semantics of "location-routing-allowed" above. It >>>is not intended to be some kind of security mechanism that would >>>prevent a proxy from reading location information (we have other >>>ways to do that). It does however resolve the ambiguity of SIP >>>proxies "retransmitting" location information by merely forwarding >>>requests, which in a strict reading of RFC4119 could easily be >>>inferred. Setting a "routing-allowed" bit of some kind clarifies >>>that the Ruler Maker doesn't mind retransmission (even when >>>"retransmission-allowed" is set to "no" at a PIDF level) as long >>>as it takes place as in the context of normal SIP operations, be >>>it bare forwarding, retargeting or what have you. >>> >>>Jon Peterson >>>NeuStar, Inc. >>> >>>On Feb 15, 2011, at 4:43 PM, Paul Kyzivat wrote: >>> >>>>trimming... >>>> >>>>On 2/15/2011 6:36 PM, James M. Polk wrote: >>>> >>>>>>>the existing "routing-allowed" header parameter is a bit of a >>>>>>>mislabeling. It doesn't mean "routing" in the L3 or L7 sense of the >>>>>>>word, it means "do I (the recipient of this SIP request have permission >>>>>>>to view the locally available - or via a dereference transaction that I >>>>>>>perform - geolocation information within this SIP request. If >>>>>>>"routing-allowed" is set to "=yes", then I have permission to view it >>>>>>>and to send the geolocation information to a 3rd party (as many as I >>>>>>>want or as many times as I want). If "routing-allowed" is set to "=no", >>>>>>>I do not have permission to view or dereference any geolocation >>>>>>>information directly or indirectly related to this SIP request, *and* I >>>>>>>do not have permission to transmit this location blob to a 3rd party at >>>>>>>any time. >>>>>> >>>>>>Hmm. I thought it was a rule about whether the geoloc info could be >>>>>>used to make retargeting decisions. >>>>> >>>>>correct, but that's secondary. The primary concern is whether or not SIP >>>>>intermediaries, as LRs, are even allowed to view (or dereference) >>>>>location in the message. If they can (i.e., "Geolocation-Routing: yes"), >>>>>then they view this information to make routing decisions. If, OTOH, >>>>>"Geolocation-Routing: no" and that intermediary believes (as much as a >>>>>machine can 'believe') it has to be able to use the location information >>>>>of the Target to make a proper routing decision, the intermediary must >>>>>respond with a 424 (Bad Location Information) response including the >>>>>following: >>>>> >>>>>Geolocation-Error: 202 "Permission to Route based on Location >>>>>Information" >>>>> >>>>>This should bubble up to the UI to allow that Target's user to agree (or >>>>>not) to reveal their location information to that (and all) SIP >>>>>intermediaries for use in making good routing decisions of the >>>>>subsequent SIP request. >>>>> >>>>>Does this make sense? >>>>> >>>>>So, the answer is yes, it has to do with the actual routing of the >>>>>message, but that's a secondary concern to the revelation of the >>>>>Target's location information (i.e., it's a little more complicated than >>>>>you originally put it). >>>>> >>>>>>So, IIUC now, you are saying this has to do with routing of the geoloc >>>>>>info, not routing of the message containing it. Is that right? >>>>> >>>>>No, it's a viewability flag for the contained location, then with >>>>>permission to view the Target's location information, it's making a good >>>>>routing decision based on that location information. >>>> >>>>If so, then maybe the name of the header field used to transmit the flag >>>>should be renamed to something more suggestive of its meaning. I guess >>>>that wouldn't be a radical last minute change, since this will be the >>>>first time it has its own header field name. >>>> >>>> Thanks, >>>> Paul >>>>_______________________________________________ >>>>sipcore mailing list >>>>sipcore@ietf.org >>>>https://www.ietf.org/mailman/listinfo/sipcore >>> >>_______________________________________________ >>sipcore mailing list >>sipcore@ietf.org >>https://www.ietf.org/mailman/listinfo/sipcore > >_______________________________________________ >sipcore mailing list >sipcore@ietf.org >https://www.ietf.org/mailman/listinfo/sipcore From pkyzivat@cisco.com Wed Feb 16 18:29:26 2011 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 73B843A6E98 for ; Wed, 16 Feb 2011 18:29:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 z6erl2FuPiS1 for ; Wed, 16 Feb 2011 18:29:25 -0800 (PST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 11A313A6E81 for ; Wed, 16 Feb 2011 18:29:24 -0800 (PST) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEALsWXE1AZnwN/2dsb2JhbACmE3OhRJtShV4EhQmHA4M5 X-IronPort-AV: E=Sophos;i="4.60,483,1291593600"; d="scan'208";a="216315105" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 17 Feb 2011 02:29:54 +0000 Received: from [161.44.174.114] (dhcp-161-44-174-114.cisco.com [161.44.174.114]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id p1H2TsIu010409; Thu, 17 Feb 2011 02:29:54 GMT Message-ID: <4D5C8822.1070603@cisco.com> Date: Wed, 16 Feb 2011 21:29:54 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Adam Roach References: <4D547232.7020704@nostrum.com> <4D5540B6.1050506@cisco.com> <201102111948.p1BJmXxJ011459@sj-core-3.cisco.com> <4D559C56.1070709@cisco.com> <201102142322.p1ENMj4D020196@sj-core-1.cisco.com> <4D5A88AA.6000705@cisco.com> <201102152336.p1FNaGiE007329@sj-core-1.cisco.com> <4D5B1DBA.6040209@cisco.com> <182CE620-3D8A-457B-A243-43607B0FEB8D@neustar.biz> <4D5B31E8.2040909@cisco.com> <4D5C5799.9030203@nostrum.com> In-Reply-To: <4D5C5799.9030203@nostrum.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "sipcore@ietf.org" Subject: Re: [sipcore] Geolocation Call 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, 17 Feb 2011 02:29:26 -0000 Adam, What you say is consistent with my understanding and with what I think makes sense. Thanks, Paul On 2/16/2011 6:02 PM, Adam Roach wrote: > [as chair] > > This appears to mostly come down to what intermediaries can do when no > "Location-Routing" field is present. What I think I've heard everyone > agree to in this thread is: > > If an intermediary inserts location into a SIP message and finds no > "Location-Routing" header field, it may insert its own, with either > "yes" or "no," according to its local policy. As a corollary; if a > client doesn't insert a location but wants to suppress intermediaries > from reading one that may be inserted later, then it explicitly adds a > "Location-Routing: no" field. > > If an intermediary finds a SIP message with a "Location" field but no > "Location-Routing" field, it may not dereference the location. > > Does that accurately summarize everyone's position? > > If so, I don't think we need a phone call tomorrow. If anyone disagrees, > then I'd like to use the call tomorrow to wrestle this issue to the ground. > > /a > > On 2/15/11 8:09 PM, Paul Kyzivat wrote: >> Thanks Jon. I never followed the details of all this stuff. >> >> But looking at -05, I think the existing text is consistent with what >> you say. Of course it needs to be tweaked for the switch from >> parameter to header field. But it does seem to be all about routing of >> the sip, so I think the chosen name is ok. >> >> Thanks, >> Paul >> >> On 2/15/2011 8:12 PM, Peterson, Jon wrote: >>> >>> How did we start down this rabbit hole? See RFC5606, especially >>> section 3.5: >>> >>> When "Location-Routing-Allowed" is set to "Yes", the Rule Maker is >>> indicating permission to use the included LI for location-based >>> routing. When "Location-Routing-Allowed" is set to "No", the >>> originator is indicating that this use is not permitted. "Location- >>> Routing-Allowed" being set to "No" has no protocol-level mechanism >>> for enforcement of this behavior; like the PIDF-LO>> allowed> being set to "no", it is a way for the Rule Maker to express >>> a preference to the SIP elements, which are LI recipients. It may, >>> however, present a significant optimization. Where a location-by- >>> reference is included with "Location-Routing-Allowed" set to "No", >>> the SIP elements along the path know that they do not need to attempt >>> to dereference the location information; this is significantly faster >>> than attempting the dereference and being denied at the >>> authentication stage. >>> I wouldn't advise reading any more into this Geolocation-Routing >>> header than the semantics of "location-routing-allowed" above. It is >>> not intended to be some kind of security mechanism that would prevent >>> a proxy from reading location information (we have other ways to do >>> that). It does however resolve the ambiguity of SIP proxies >>> "retransmitting" location information by merely forwarding requests, >>> which in a strict reading of RFC4119 could easily be inferred. >>> Setting a "routing-allowed" bit of some kind clarifies that the Ruler >>> Maker doesn't mind retransmission (even when "retransmission-allowed" >>> is set to "no" at a PIDF level) as long as it takes place as in the >>> context of normal SIP operations, be it bare forwarding, retargeting >>> or what have you. >>> >>> Jon Peterson >>> NeuStar, Inc. >>> >>> On Feb 15, 2011, at 4:43 PM, Paul Kyzivat wrote: >>> >>>> trimming... >>>> >>>> On 2/15/2011 6:36 PM, James M. Polk wrote: >>>> >>>>>>> the existing "routing-allowed" header parameter is a bit of a >>>>>>> mislabeling. It doesn't mean "routing" in the L3 or L7 sense of the >>>>>>> word, it means "do I (the recipient of this SIP request have >>>>>>> permission >>>>>>> to view the locally available - or via a dereference transaction >>>>>>> that I >>>>>>> perform - geolocation information within this SIP request. If >>>>>>> "routing-allowed" is set to "=yes", then I have permission to >>>>>>> view it >>>>>>> and to send the geolocation information to a 3rd party (as many as I >>>>>>> want or as many times as I want). If "routing-allowed" is set to >>>>>>> "=no", >>>>>>> I do not have permission to view or dereference any geolocation >>>>>>> information directly or indirectly related to this SIP request, >>>>>>> *and* I >>>>>>> do not have permission to transmit this location blob to a 3rd >>>>>>> party at >>>>>>> any time. >>>>>> >>>>>> Hmm. I thought it was a rule about whether the geoloc info could be >>>>>> used to make retargeting decisions. >>>>> >>>>> correct, but that's secondary. The primary concern is whether or >>>>> not SIP >>>>> intermediaries, as LRs, are even allowed to view (or dereference) >>>>> location in the message. If they can (i.e., "Geolocation-Routing: >>>>> yes"), >>>>> then they view this information to make routing decisions. If, OTOH, >>>>> "Geolocation-Routing: no" and that intermediary believes (as much as a >>>>> machine can 'believe') it has to be able to use the location >>>>> information >>>>> of the Target to make a proper routing decision, the intermediary must >>>>> respond with a 424 (Bad Location Information) response including the >>>>> following: >>>>> >>>>> Geolocation-Error: 202 "Permission to Route based on Location >>>>> Information" >>>>> >>>>> This should bubble up to the UI to allow that Target's user to >>>>> agree (or >>>>> not) to reveal their location information to that (and all) SIP >>>>> intermediaries for use in making good routing decisions of the >>>>> subsequent SIP request. >>>>> >>>>> Does this make sense? >>>>> >>>>> So, the answer is yes, it has to do with the actual routing of the >>>>> message, but that's a secondary concern to the revelation of the >>>>> Target's location information (i.e., it's a little more complicated >>>>> than >>>>> you originally put it). >>>>> >>>>>> So, IIUC now, you are saying this has to do with routing of the >>>>>> geoloc >>>>>> info, not routing of the message containing it. Is that right? >>>>> >>>>> No, it's a viewability flag for the contained location, then with >>>>> permission to view the Target's location information, it's making a >>>>> good >>>>> routing decision based on that location information. >>>> >>>> If so, then maybe the name of the header field used to transmit the >>>> flag >>>> should be renamed to something more suggestive of its meaning. I guess >>>> that wouldn't be a radical last minute change, since this will be the >>>> first time it has its own header field name. >>>> >>>> Thanks, >>>> Paul >>>> _______________________________________________ >>>> sipcore mailing list >>>> sipcore@ietf.org >>>> https://www.ietf.org/mailman/listinfo/sipcore >>> >>> >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore > > From john.elwell@siemens-enterprise.com Wed Feb 16 23:23:43 2011 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 DB85F3A6CD9 for ; Wed, 16 Feb 2011 23:23:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.649 X-Spam-Level: X-Spam-Status: No, score=-102.649 tagged_above=-999 required=5 tests=[AWL=-0.050, BAYES_00=-2.599, 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 SndXjVbjEDyk for ; Wed, 16 Feb 2011 23:23:43 -0800 (PST) Received: from ms03.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id 9D6723A6D56 for ; Wed, 16 Feb 2011 23:23:42 -0800 (PST) Received: from senmx11-mx ([62.134.46.9] [62.134.46.9]) by ms03.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-3422003; Thu, 17 Feb 2011 08:24:12 +0100 Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx11-mx (Server) with ESMTP id E833E1EB82AB; Thu, 17 Feb 2011 08:24:11 +0100 (CET) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Thu, 17 Feb 2011 08:24:11 +0100 From: "Elwell, John" To: Mary Barnes Date: Thu, 17 Feb 2011 08:24:09 +0100 Thread-Topic: [sipcore] I-D Action:draft-ietf-sipcore-rfc4244bis-03.txt Thread-Index: AcvOLMZDXpSLIyqSRjOfWGaACafvsAART/cw Message-ID: References: <20110214151501.27807.33759.idtracker@localhost> 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 Cc: SIPCORE Subject: Re: [sipcore] I-D Action:draft-ietf-sipcore-rfc4244bis-03.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: Thu, 17 Feb 2011 07:23:44 -0000 =20 > -----Original Message----- > From: Mary Barnes [mailto:mary.ietf.barnes@gmail.com]=20 > Sent: 16 February 2011 22:57 > To: Elwell, John > Cc: SIPCORE > Subject: Re: [sipcore] I-D Action:draft-ietf-sipcore-rfc4244bis-03.txt >=20 > Responses inline below [MB]. >=20 >=20 > On Wed, Feb 16, 2011 at 2:06 PM, Elwell, John=20 > wrote: >=20 >=20 > Mary, > =09 > In fact what we are doing is placing these header=20 > fields in the Headers component of the SIP/SIPS URI - isn't=20 > that the proper way to describe it? I know the escape=20 > terminology has been in the draft for a long time, and if=20 > others are happy I guess I can live with it. Perhaps there=20 > are precedents in other RFCs. But I am not sure how somebody=20 > unfamiliar with this terminology would interpret it. > =09 >=20 > [MB] Yes, we are putting the header fields in the "headers"=20 > parameter in the SIP/SIPS URI. So, we can change the=20 > wording to reflect such. Again, I have no recollection of the=20 > logic behind using the term escape. We could probably dig=20 > through the archives and see when that was introduced. In=20 > looking at some some charts from the IETF-60 discussion of=20 > 4244 in its draft for it is quite interesting, as one of the=20 > issues was one that you identified [JRE-7] and the chart=20 > states that "...the Privacy header is added to the request or=20 > escaped as part of the targeted-to-uri". I have no issue with=20 > changing the wording as you suggest. [/MB] [JRE] True, when I submitted earlier comments I was just going along with w= hat appeared to be the convention. However, this time something alerted me,= so I checked in RFC 3261 and found that the term "escape" was used with an= entirely different meaning. I think other experts in the WG should give th= eir opinions - I don't want to force a change if people are happy with the = status quo. >=20 >=20 > By the way, what if we have a tel: URI? I don't think=20 > that supports "escaped" header fields. Do our requirements=20 > for inserting "escaped" header fields apply only when the URI=20 > is SIP or SIPS? > =09 >=20 > [MB] Correct - the Reason and Privacy header fields can only=20 > be used for SIP or SIPS URIs. Hadriel brought up this issue=20 > and there is text in there with regards to this issue. [/MB]=20 [JRE] Yes, and I see now that this is kind of captured. It is a bit inconsi= stent, because 9.2 says you MUST escape the Reason header field - no except= ions. However, if I go back to section 5 (header field structure), I do fin= d a statement about transforming a Tel-URI into a SIP/SIPS-URI, but that is= only SHOULD strength. John From john.elwell@siemens-enterprise.com Thu Feb 17 00:20:04 2011 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 DA6203A6DB1 for ; Thu, 17 Feb 2011 00:20:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.347 X-Spam-Level: X-Spam-Status: No, score=-102.347 tagged_above=-999 required=5 tests=[AWL=-0.348, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, 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 joghEgT5f9U5 for ; Thu, 17 Feb 2011 00:20:03 -0800 (PST) Received: from ms02.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id CA96F3A6D23 for ; Thu, 17 Feb 2011 00:20:02 -0800 (PST) Received: from senmx11-mx ([62.134.46.9] [62.134.46.9]) by ms02.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-3427634; Thu, 17 Feb 2011 09:20:32 +0100 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx11-mx (Server) with ESMTP id EC7F21EB82AB; Thu, 17 Feb 2011 09:20:31 +0100 (CET) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Thu, 17 Feb 2011 09:20:31 +0100 From: "Elwell, John" To: Mary Barnes Date: Thu, 17 Feb 2011 09:20:29 +0100 Thread-Topic: Some comments on draft-ietf-sipcore-rfc4244bis-03.txt Thread-Index: AcvOMVhW5usuW1phTQ+a7UMPCGzkdwAQrHVw Message-ID: References: <20110214151501.27807.33759.idtracker@localhost> 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 Cc: SIPCORE Subject: Re: [sipcore] Some comments on draft-ietf-sipcore-rfc4244bis-03.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: Thu, 17 Feb 2011 08:20:05 -0000 Mary, Thanks - see below: > -----Original Message----- > From: Mary Barnes [mailto:mary.ietf.barnes@gmail.com]=20 > Sent: 16 February 2011 23:29 > To: Elwell, John > Cc: SIPCORE > Subject: Re: Some comments on draft-ietf-sipcore-rfc4244bis-03.txt >=20 > Hi John,=20 >=20 > Thanks for the comments. Responses inline below [MB]. >=20 > Mary. >=20 >=20 > On Wed, Feb 16, 2011 at 2:14 PM, Elwell, John=20 > wrote: >=20 >=20 > Mary, > =09 > Thanks for this major rewrite and addressing very many=20 > earlier comments. I have some initial comments and also a=20 > general comment. > =09 > Comment 1: Request fails (4xx, say) and as a result a=20 > proxy retargets. According to 7.1.2, the proxy is required to=20 > include in the retargeted request all entries from received=20 > responses so far, including, presumably, entries in the 4xx=20 > response that leads to retargeting. However, if the request=20 > does not contain Supported: histinfo, there will be no=20 > entries in received responses. Therefore the final UAS will=20 > not receive a complete set of entries. So we seem to have the=20 > strange situation that the set of entries received by the UAS=20 > is dependent on support of History-Info at the UAC. This=20 > seems wrong. It seems to me that entries should always be=20 > sent backwards, subject to privacy, and perhaps not on the=20 > last hop if the UAC doesn't support it.=20 > =09 >=20 > [MB]=20 >=20 [JRE] Your responses seems to be lost. >=20 > Comment 2: Suppose a proxy forwards a request to two=20 > targets, one with entry index 1.1 and the other with entry=20 > index 1.2. A provisional or final response is received to the=20 > first forwarded request containing an additional entry with=20 > index 1.1.1. Then a 4xx response is received to the second=20 > request, causing the proxy to retarget, this time with an=20 > entry index 1.3. According to 7.1.2 step 1, that retargeted=20 > request should contain entries 1, 1.1.1, 1.2 and 1.3. Note=20 > that 1.1 is missing. I see nothing to require the inclusion=20 > of 1.1, yet step 1 of 7.1.2 seems to require inclusion of=20 > 1.1.1. Have I misinterpreted something? > =09 >=20 > [MB] 1.1 should also be included. Perhaps the wording needs=20 > clarification, but the text is attempting to state that in=20 > cases where =20 [JRE] Your responses seems to have been truncated. >=20 >=20 > Comment 3: In 7.2 it states: > "...MUST forward captured History-Info in > subsequent, provisional, and final responses to the=20 > request sent by > the ultimate UAS (see Section 6.2)..." > When a proxy forwards a provisional response, how does=20 > it know that this is from the ultimate UAS? This can only be=20 > known when the first 2xx arrives. In fact the term "ultimate=20 > UAS" is also problematic because how does a proxy know that a=20 > response has come from a UAS, as opposed to a proxy? > =09 >=20 > [MB] It doesn't know that it's the ultimate UAS, so=3Do we=20 > should remove that phrase. It's attempting to highlight that=20 > all the information is sent in the responses, but that's=20 > really covered elsewhere. [/MB] [JRE] It does seem to make sense to simplify it so that you send all inform= ation in all provisional or final responses (except 100). Just an example t= o help confirm whether this simple rule makes sense: A proxy forks, sending requests with indices 1.1, 1.2 and 1.3. Then the 1.3= branch sends a response (provisional, final) containing additional entry 1= .3.1. In this case the response that the proxy sends upstream would contain= 1, 1.1, 1.2, 1.3 and 1.3.1 - correct? So even though the 1.1 and 1.2 branc= hes have not responded, they are included in the upstream response? >=20 >=20 > General comment: > I found it really hard to understand how all the=20 > different procedures in sections 6, 7 and 8 fitted together,=20 > and I tried to analyse what exactly is going on. I came to=20 > the conclusion that, to a first approximation, we are trying=20 > to specify the following: > =09 > 1. Procedures for receiving a request > - Cache the sequence of entries received. > - If no entry or if last entry does not match=20 > Request-URI, create one and add it to the cache. > =09 > 2. Procedures for sending a request > - Include all cached entries (if any). > - Also include an entry reflecting the Request-URI of=20 > the sent request (not quite sure if this should go in the=20 > cache at this stage). > - In case of recursing, include in that new entry=20 > parameters from the Contact header field of the 3XX response. > =09 > 3. Procedures for receiving a response (other than 100) > - Add to the cache any entries in the response not=20 > already in the cache. > =09 > 4. Procedures for sending a response (other than 100) > - Include all cached entries. > =09 > I am sure this is an over simplification. It doesn't=20 > take account of the presence of the option tag in Supported=20 > (influences response behaviour), privacy considerations,=20 > populating the index, etc.. Also there are clearly some=20 > issues concerning exactly what a proxy includes from previous=20 > targetings when it retargets, what goes in provisional=20 > responses, and so on (impacted by the comments above, no=20 > doubt). However, I can't help feeling there might be a much=20 > simpler way of documenting all this. > =09 >=20 > [MB] At this point, having worked on this document way too=20 > long, it's really hard for me to see how to make it more=20 > clear. It really is fairly simple. The intent of 7.1.1 was=20 > to define the steps similar to your simplified summary above.=20 [JRE] That is not how I see it. 7.1 only deals with requests, not responses= , and 7.1 only deals with proxy/intermediary, not UAC, UAS, redirect server= . I was trying to pull all these together into one set of procedures that i= s common to all (except obviously steps relating to receiving a request and= sending a response will not apply to a UAC and steps relating to sending a= request and receiving a response will not apply to a UAS or redirect serve= r (or a proxy that rejects). In other words, I was trying to pull together = sections 6, 7 and 8 into a single section covering everything. This is beca= use procedures for receiving request, for example, are similar no matter wh= ich entity is involved. > As far as handling the privacy, that applies to the entirety=20 > of the hi-entries being included in an outgoing request per=20 > the rules that we tried to highlight in the updated privacy=20 > section. The mechanism by which the index is calculated is=20 > referenced in the appropriate sections and included all in=20 > one place. I could see that we could spread out how all the=20 > parameters are determined directly in the processing flow and=20 > within the discussion of the specific cases, however, that=20 > isn't nearly as modular IMHO. We did have some of it=20 > previously, but we also had inconsistencies by doing so (and=20 > overuse of normative statements at least as I interpreted WG=20 > feedback).=20 [JRE] I am quite happy with common procedures like privacy, Reason header f= ield and indexing to be kept separate, as we already have in section 9. My = comments referred to sections 6, 7 and 8, and even if we decide to restruct= ure these, we can still refer out to section 9 for the common bits. > IMHO the current form is easier from an=20 > implementors perspective. And, the form of this document is=20 > not dramatically unlike other RFCs, including RFC 3261=20 > although the ABNF is earlier in the document in 4244bis.=20 > 4244bis follows the model of describing processing for each=20 > of the functional entities and then has sections that=20 > describe the handling for each protocol element. From a=20 > quick glance RFC 4028 (Session timer) and RFC 3325=20 > (P-Asserted-Identity) have separate sections for Proxy and UA=20 > behaviors, as well although the ABNF is later (but again we=20 > got feedback that it should be earlier. It's really a chicken=20 > egg thing in my opinion as to whether you see the protocol=20 > elements first and whether the normative behavior for each=20 > parameter is separate from the processing flow for the SIP=20 > entities and whether the latter is separated - i.e., we could=20 > have a handling the request section that includes the UAC and=20 > SIP intermediary behavior and then have a response section=20 > that includes SIP intermediary and UAS processing. But,=20 > again I personally feel that have the sections separate is=20 > more useful for implementors that are in many cases=20 > developing code for only a single functional entity. [/MB] [JRE] Putting aside for the moment the question of whether to restructure s= ections 6, 7 and 8, I would like to try to refine the simplified model I pr= oposed to get a common understanding of what we are trying to achieve. A co= mmonly understood model would help me to review the existing text to ensure= that it is consistent with the model. At present I am finding it difficult= to understand the text. Perhaps that is my fault, not having put enough ti= me into it, but I would appreciate assistance from the WG in trying to get = a better understanding. So here again is the model as I see it (slightly ch= anged from before): 1. Procedures for receiving a request - Cache the sequence of entries received. - If no entry or if last entry does not match Request-URI, create one and a= dd it to the cache. 2. Procedures for sending a request - Generate an additional entry reflecting the Request-URI of the sent reque= st, and add this to the cache. - In case of recursing, include in that new entry parameters from the Conta= ct header field of the 3XX response. - Include all cached entries. 3. Procedures for receiving a response (other than 100) - Add to the cache any entries in the response not already in the cache. - In the case of a 3xx/4xx/5xx/6xx response, add a Reason header field to t= he cached entry that was generated for the corresponding request. 4. Procedures for sending a response (other than 100) - Include all cached entries. All of the above subject to common rules relating to privacy, histinfo opti= on tag, and indices. John= From john.elwell@siemens-enterprise.com Thu Feb 17 01:55:17 2011 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 75AAE3A6DCB for ; Thu, 17 Feb 2011 01:55:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.637 X-Spam-Level: X-Spam-Status: No, score=-102.637 tagged_above=-999 required=5 tests=[AWL=-0.038, BAYES_00=-2.599, 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 JAHe2d6k40th for ; Thu, 17 Feb 2011 01:55:16 -0800 (PST) Received: from ms03.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id 5E1C83A6DAD for ; Thu, 17 Feb 2011 01:55:15 -0800 (PST) Received: from senmx11-mx ([62.134.46.9] [62.134.46.9]) by ms03.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-3423942; Thu, 17 Feb 2011 10:55:14 +0100 Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx11-mx (Server) with ESMTP id 2FE7F1EB82AB; Thu, 17 Feb 2011 10:55:14 +0100 (CET) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Thu, 17 Feb 2011 10:55:14 +0100 From: "Elwell, John" To: "James M. Polk" , Adam Roach , Paul Kyzivat Date: Thu, 17 Feb 2011 10:55:11 +0100 Thread-Topic: [sipcore] Geolocation Call Thread-Index: AcvOM8dMFdP+FwR6S4KUQ6jrjowD+gAVO1xQ Message-ID: References: <4D547232.7020704@nostrum.com> <4D5540B6.1050506@cisco.com> <201102111948.p1BJmXxJ011459@sj-core-3.cisco.com> <4D559C56.1070709@cisco.com> <201102142322.p1ENMj4D020196@sj-core-1.cisco.com> <4D5A88AA.6000705@cisco.com> <201102152336.p1FNaGiE007329@sj-core-1.cisco.com> <4D5B1DBA.6040209@cisco.com> <182CE620-3D8A-457B-A243-43607B0FEB8D@neustar.biz> <4D5B31E8.2040909@cisco.com> <4D5C5799.9030203@nostrum.com> <201102162346.p1GNkdDV019674@sj-core-1.cisco.com> In-Reply-To: <201102162346.p1GNkdDV019674@sj-core-1.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 Cc: "sipcore@ietf.org" Subject: Re: [sipcore] Geolocation Call 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, 17 Feb 2011 09:55:17 -0000 I think this analysis is correct. John=20 > -----Original Message----- > From: sipcore-bounces@ietf.org=20 > [mailto:sipcore-bounces@ietf.org] On Behalf Of James M. Polk > Sent: 16 February 2011 23:47 > To: Adam Roach; Paul Kyzivat > Cc: sipcore@ietf.org > Subject: Re: [sipcore] Geolocation Call >=20 > At 05:02 PM 2/16/2011, Adam Roach wrote: > >[as chair] > > > >This appears to mostly come down to what intermediaries can do when=20 > >no "Location-Routing" field is present. What I think I've heard=20 > >everyone agree to in this thread is: > > > >If an intermediary inserts location into a SIP message and finds no=20 > >"Location-Routing" header field, it may insert its own, with either=20 > >"yes" or "no," according to its local policy. As a corollary; if a=20 > >client doesn't insert a location but wants to suppress=20 > >intermediaries from reading one that may be inserted later, then it=20 > >explicitly adds a "Location-Routing: no" field. > > > >If an intermediary finds a SIP message with a "Location" field but=20 > >no "Location-Routing" field, it may not dereference the location. > > > >Does that accurately summarize everyone's position? >=20 > Adam (and all) >=20 > To answer your question above - I think you have it right. I think=20 > the only real play (or uncertainty) is when there is no Geolocation=20 > header field, and what to do when there is one of the three=20 > possibilities for the Geolocation-Routing. >=20 > With that in mind, I have tentatively added a table in -06 of the 12=20 > possibilities I can think of for the combinations of Geolocation and=20 > Geolocation-Routing header fields, focusing on a Geolocation-Routing=20 > "=3Dno", "=3Dyes", and when no Gelocation-Routing header field is present= =20 > (with or without a Geolocation header field). I've come up with the=20 > following - that only Jon has seen so far. >=20 > I'd like to get feedback on this >=20 > - have I got everything I need in the table? > - did I miss anything? > - have I gotten anything wrong in the table? > - should I expand what I say in the Geolocation-Routing column? >=20 > and finally: > - should this table be included in -06? >=20 > Here's the table as it currently is in the rough draft of -06: > " > Based on the above, the following table explains the 12 known > combinations of Geo-based header fields. >=20 > Geo-based header combinations Geolocation-Routing > ---------------------------------- ------------------- > a single locationValue in a single Implicitly set to "=3Dno" > Geolocation header instance within > the same SIP request, with no > Geolocation-Routing header present. >=20 > more than one locationValue in a Implicitly set to "=3Dno" > single Geolocation header instance > within the same SIP request, with no > Geolocation-Routing header present. >=20 > more than one locationValue in more Implicitly set to "=3Dno" > than one Geolocation header instance > within the same SIP request, with no > Geolocation-Routing header present. >=20 >=20 > a single locationValue in a single Explicitly set to "=3Dno" > Geolocation header instance within > the same SIP request, with single > Geolocation-Routing header-value "=3Dno". >=20 > more than one locationValue in a Explicitly set to "=3Dno" > single Geolocation header instance > within the same SIP request, with > single Geolocation-Routing header-value > "=3Dno". >=20 > more than one locationValue in more Explicitly set to "=3Dno" > than one Geolocation header instance > within the same SIP request, with single > Geolocation-Routing header-value "=3Dno". >=20 >=20 > a single locationValue in a single Explicitly set to "=3Dyes" > Geolocation header instance within the > same SIP request, with single > Geolocation-Routing header-value "=3Dyes". >=20 > more than one locationValue in a Explicitly set to "=3Dyes" > single Geolocation header instance > within the same SIP request, with > single Geolocation-Routing header-value > "=3Dyes". >=20 > more than one locationValue in more Explicitly set to "=3Dyes" > than one Geolocation header instance > within the same SIP request, with single > Geolocation-Routing header-value "=3Dyes". >=20 >=20 > no Geolocation header instance within Default Geolocation-Routing > a SIP request, with no is open and can be set by a > Geolocation-Routing header present. downstream entity or not at > all. >=20 > no Geolocation header instance within Location viewing policy set > a SIP request, with single already such > Geolocation-Routing header-value "=3Dno". Location viewing policy set > already such that no > intermediaries can view > location inserted > downstream. >=20 > no Geolocation header instance within Location viewing policy set > a SIP request, with single already such that if > Geolocation-Routing header-value location is inserted > "=3Dyes". downstream, intermediaries > can maintain an=20 > open viewing > of location policy or can > change policy to "=3Dno" for > intermediaries further > downstream. > " >=20 > James >=20 >=20 > >If so, I don't think we need a phone call tomorrow. If anyone=20 > >disagrees, then I'd like to use the call tomorrow to wrestle this=20 > >issue to the ground. > > > >/a > > > >On 2/15/11 8:09 PM, Paul Kyzivat wrote: > >>Thanks Jon. I never followed the details of all this stuff. > >> > >>But looking at -05, I think the existing text is consistent with=20 > >>what you say. Of course it needs to be tweaked for the switch from=20 > >>parameter to header field. But it does seem to be all about routing=20 > >>of the sip, so I think the chosen name is ok. > >> > >> Thanks, > >> Paul > >> > >>On 2/15/2011 8:12 PM, Peterson, Jon wrote: > >>> > >>>How did we start down this rabbit hole? See RFC5606,=20 > especially section 3.5: > >>> > >>> When "Location-Routing-Allowed" is set to "Yes", the=20 > Rule Maker is > >>> indicating permission to use the included LI for=20 > location-based > >>> routing. When "Location-Routing-Allowed" is set to "No", the > >>> originator is indicating that this use is not=20 > permitted. "Location- > >>> Routing-Allowed" being set to "No" has no=20 > protocol-level mechanism > >>> for enforcement of this behavior; like the=20 > PIDF-LO >>> allowed> being set to "no", it is a way for the Rule=20 > Maker to express > >>> a preference to the SIP elements, which are LI=20 > recipients. It may, > >>> however, present a significant optimization. Where a=20 > location-by- > >>> reference is included with "Location-Routing-Allowed"=20 > set to "No", > >>> the SIP elements along the path know that they do not=20 > need to attempt > >>> to dereference the location information; this is=20 > significantly faster > >>> than attempting the dereference and being denied at the > >>> authentication stage. > >>>I wouldn't advise reading any more into this Geolocation-Routing=20 > >>>header than the semantics of "location-routing-allowed" above. It=20 > >>>is not intended to be some kind of security mechanism that would=20 > >>>prevent a proxy from reading location information (we have other=20 > >>>ways to do that). It does however resolve the ambiguity of SIP=20 > >>>proxies "retransmitting" location information by merely forwarding=20 > >>>requests, which in a strict reading of RFC4119 could easily be=20 > >>>inferred. Setting a "routing-allowed" bit of some kind clarifies=20 > >>>that the Ruler Maker doesn't mind retransmission (even when=20 > >>>"retransmission-allowed" is set to "no" at a PIDF level) as long=20 > >>>as it takes place as in the context of normal SIP operations, be=20 > >>>it bare forwarding, retargeting or what have you. > >>> > >>>Jon Peterson > >>>NeuStar, Inc. > >>> > >>>On Feb 15, 2011, at 4:43 PM, Paul Kyzivat wrote: > >>> > >>>>trimming... > >>>> > >>>>On 2/15/2011 6:36 PM, James M. Polk wrote: > >>>> > >>>>>>>the existing "routing-allowed" header parameter is a bit of a > >>>>>>>mislabeling. It doesn't mean "routing" in the L3 or L7=20 > sense of the > >>>>>>>word, it means "do I (the recipient of this SIP=20 > request have permission > >>>>>>>to view the locally available - or via a dereference=20 > transaction that I > >>>>>>>perform - geolocation information within this SIP request. If > >>>>>>>"routing-allowed" is set to "=3Dyes", then I have=20 > permission to view it > >>>>>>>and to send the geolocation information to a 3rd party=20 > (as many as I > >>>>>>>want or as many times as I want). If "routing-allowed"=20 > is set to "=3Dno", > >>>>>>>I do not have permission to view or dereference any geolocation > >>>>>>>information directly or indirectly related to this SIP=20 > request, *and* I > >>>>>>>do not have permission to transmit this location blob=20 > to a 3rd party at > >>>>>>>any time. > >>>>>> > >>>>>>Hmm. I thought it was a rule about whether the geoloc=20 > info could be > >>>>>>used to make retargeting decisions. > >>>>> > >>>>>correct, but that's secondary. The primary concern is=20 > whether or not SIP > >>>>>intermediaries, as LRs, are even allowed to view (or dereference) > >>>>>location in the message. If they can (i.e.,=20 > "Geolocation-Routing: yes"), > >>>>>then they view this information to make routing=20 > decisions. If, OTOH, > >>>>>"Geolocation-Routing: no" and that intermediary believes=20 > (as much as a > >>>>>machine can 'believe') it has to be able to use the=20 > location information > >>>>>of the Target to make a proper routing decision, the=20 > intermediary must > >>>>>respond with a 424 (Bad Location Information) response=20 > including the > >>>>>following: > >>>>> > >>>>>Geolocation-Error: 202 "Permission to Route based on Location > >>>>>Information" > >>>>> > >>>>>This should bubble up to the UI to allow that Target's=20 > user to agree (or > >>>>>not) to reveal their location information to that (and all) SIP > >>>>>intermediaries for use in making good routing decisions of the > >>>>>subsequent SIP request. > >>>>> > >>>>>Does this make sense? > >>>>> > >>>>>So, the answer is yes, it has to do with the actual=20 > routing of the > >>>>>message, but that's a secondary concern to the revelation of the > >>>>>Target's location information (i.e., it's a little more=20 > complicated than > >>>>>you originally put it). > >>>>> > >>>>>>So, IIUC now, you are saying this has to do with=20 > routing of the geoloc > >>>>>>info, not routing of the message containing it. Is that right? > >>>>> > >>>>>No, it's a viewability flag for the contained location, then with > >>>>>permission to view the Target's location information,=20 > it's making a good > >>>>>routing decision based on that location information. > >>>> > >>>>If so, then maybe the name of the header field used to=20 > transmit the flag > >>>>should be renamed to something more suggestive of its=20 > meaning. I guess > >>>>that wouldn't be a radical last minute change, since this=20 > will be the > >>>>first time it has its own header field name. > >>>> > >>>> Thanks, > >>>> Paul > >>>>_______________________________________________ > >>>>sipcore mailing list > >>>>sipcore@ietf.org > >>>>https://www.ietf.org/mailman/listinfo/sipcore > >>> > >>_______________________________________________ > >>sipcore mailing list > >>sipcore@ietf.org > >>https://www.ietf.org/mailman/listinfo/sipcore > > > >_______________________________________________ > >sipcore mailing list > >sipcore@ietf.org > >https://www.ietf.org/mailman/listinfo/sipcore >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > = From pkyzivat@cisco.com Thu Feb 17 05:53:15 2011 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 0401A3A6C8B for ; Thu, 17 Feb 2011 05:53:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 3Olv17wSOUwc for ; Thu, 17 Feb 2011 05:53:14 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id C102A3A6CB8 for ; Thu, 17 Feb 2011 05:53:13 -0800 (PST) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAEa3XE1AZnwM/2dsb2JhbACmGHOgO5tMhV4EhQqHBoM6gw8 X-IronPort-AV: E=Sophos;i="4.60,486,1291593600"; d="scan'208";a="216761499" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 17 Feb 2011 13:53:44 +0000 Received: from [161.44.174.114] (dhcp-161-44-174-114.cisco.com [161.44.174.114]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id p1HDrifX020035 for ; Thu, 17 Feb 2011 13:53:44 GMT Message-ID: <4D5D2868.5040308@cisco.com> Date: Thu, 17 Feb 2011 08:53:44 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: sipcore@ietf.org References: <20110214151501.27807.33759.idtracker@localhost> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [sipcore] I-D Action:draft-ietf-sipcore-rfc4244bis-03.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: Thu, 17 Feb 2011 13:53:15 -0000 I think the use of "escaped" in the sense used in 4244bis has become informal colloquial usage, and I am probably as guilty of using it as anyone. But I agree it is problematic as formal language in a normative document. IMO the wording changes offered by John are an improvement. Thanks, Paul On 2/17/2011 2:24 AM, Elwell, John wrote: > > > >> -----Original Message----- >> From: Mary Barnes [mailto:mary.ietf.barnes@gmail.com] >> Sent: 16 February 2011 22:57 >> To: Elwell, John >> Cc: SIPCORE >> Subject: Re: [sipcore] I-D Action:draft-ietf-sipcore-rfc4244bis-03.txt >> >> Responses inline below [MB]. >> >> >> On Wed, Feb 16, 2011 at 2:06 PM, Elwell, John >> wrote: >> >> >> Mary, >> >> In fact what we are doing is placing these header >> fields in the Headers component of the SIP/SIPS URI - isn't >> that the proper way to describe it? I know the escape >> terminology has been in the draft for a long time, and if >> others are happy I guess I can live with it. Perhaps there >> are precedents in other RFCs. But I am not sure how somebody >> unfamiliar with this terminology would interpret it. >> >> >> [MB] Yes, we are putting the header fields in the "headers" >> parameter in the SIP/SIPS URI. So, we can change the >> wording to reflect such. Again, I have no recollection of the >> logic behind using the term escape. We could probably dig >> through the archives and see when that was introduced. In >> looking at some some charts from the IETF-60 discussion of >> 4244 in its draft for it is quite interesting, as one of the >> issues was one that you identified [JRE-7] and the chart >> states that "...the Privacy header is added to the request or >> escaped as part of the targeted-to-uri". I have no issue with >> changing the wording as you suggest. [/MB] > [JRE] True, when I submitted earlier comments I was just going along with what appeared to be the convention. However, this time something alerted me, so I checked in RFC 3261 and found that the term "escape" was used with an entirely different meaning. I think other experts in the WG should give their opinions - I don't want to force a change if people are happy with the status quo. > >> >> >> By the way, what if we have a tel: URI? I don't think >> that supports "escaped" header fields. Do our requirements >> for inserting "escaped" header fields apply only when the URI >> is SIP or SIPS? >> >> >> [MB] Correct - the Reason and Privacy header fields can only >> be used for SIP or SIPS URIs. Hadriel brought up this issue >> and there is text in there with regards to this issue. [/MB] > [JRE] Yes, and I see now that this is kind of captured. It is a bit inconsistent, because 9.2 says you MUST escape the Reason header field - no exceptions. However, if I go back to section 5 (header field structure), I do find a statement about transforming a Tel-URI into a SIP/SIPS-URI, but that is only SHOULD strength. > > John > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From adam@nostrum.com Thu Feb 17 10:21:43 2011 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 6B3A53A6D60 for ; Thu, 17 Feb 2011 10:21:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.583 X-Spam-Level: X-Spam-Status: No, score=-102.583 tagged_above=-999 required=5 tests=[AWL=0.016, BAYES_00=-2.599, 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 0hqTs6Oh-KAn for ; Thu, 17 Feb 2011 10:21:42 -0800 (PST) Received: from nostrum.com (shaman.nostrum.com [72.232.179.90]) by core3.amsl.com (Postfix) with ESMTP id E800D3A6D6C for ; Thu, 17 Feb 2011 10:21:41 -0800 (PST) Received: from dn3-228.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 p1HIKvnQ094020 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO) for ; Thu, 17 Feb 2011 12:20:58 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <4D5D6709.8050104@nostrum.com> Date: Thu, 17 Feb 2011 12:20:57 -0600 From: Adam Roach - SIPCORE Chair User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: "SIPCORE (Session Initiation Protocol Core) WG" 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) Subject: [sipcore] No Location Conveyance Call Today X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: SIPCORE Chairs List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Feb 2011 18:21:43 -0000 It looks like we don't really have any pending open issues to discuss, so I'm canceling today's ad-hoc discussion on Location Conveyance. /a From mary.ietf.barnes@gmail.com Thu Feb 17 10:31:43 2011 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 D369D3A6E4E for ; Thu, 17 Feb 2011 10:31:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.268 X-Spam-Level: X-Spam-Status: No, score=-103.268 tagged_above=-999 required=5 tests=[AWL=-0.270, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_LOW=-1, 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 87ZQyVWwpvx9 for ; Thu, 17 Feb 2011 10:31:42 -0800 (PST) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by core3.amsl.com (Postfix) with ESMTP id 14F4F3A6E3E for ; Thu, 17 Feb 2011 10:31:41 -0800 (PST) Received: by yxt33 with SMTP id 33so1380020yxt.31 for ; Thu, 17 Feb 2011 10:32:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:date:message-id:subject:from:to:cc :content-type; bh=v+tfm+J4Occo6njiTwaXcsejATYLzeu/aSvyEP15cfA=; b=Il5sSu1F0E4BJKwZyQiLmPiS1K/gtr9bDI3kyG/p3qydUy/IdLgIwDpgcSzawXeo2A 5WYZ0YLEVooPXtZD5GValxA2aXHwQRDtlpeQzJq0/4lUEe9TuNJxFYCsF9YHB8xRlOub Qj1q4IfXEqP15SwSfKADLZqWryDn699wtFEdA= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type; b=GmQfqHRLiuSfqadjZQyMpWLjbB4jfFMFcjVi7icnxbK0fWmwhGDocpOKfQBxHzt3J6 tWx3mWgkk2v8Ge42gudw1NjSSpC6Fd09aU6qed8XtLVt0YQwSFVf61YtOT6WGrbSP+JD 3Z0pG8if5sjKNrHnoOeexYGRqGTw98eX09+1s= MIME-Version: 1.0 Received: by 10.236.95.143 with SMTP id p15mr3292488yhf.9.1297967533219; Thu, 17 Feb 2011 10:32:13 -0800 (PST) Received: by 10.236.95.35 with HTTP; Thu, 17 Feb 2011 10:32:13 -0800 (PST) Date: Thu, 17 Feb 2011 12:32:13 -0600 Message-ID: From: Mary Barnes To: "Elwell, John" Content-Type: multipart/alternative; boundary=0023547c895bbf61a7049c7e9dd0 Cc: SIPCORE Subject: [sipcore] Part1: Some comments on draft-ietf-sipcore-rfc4244bis-03.txt - Including all hi-entries 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, 17 Feb 2011 18:31:44 -0000 --0023547c895bbf61a7049c7e9dd0 Content-Type: text/plain; charset=ISO-8859-1 HI John, Responses inline below [MB2]. I'm separating the thread into two separate emails as I think there are two distinct issues within this thread, so it will be easier to track. Thanks, Mary. On Thu, Feb 17, 2011 at 2:20 AM, Elwell, John < john.elwell@siemens-enterprise.com> wrote: > Mary, > > Thanks - see below: > > > -----Original Message----- > > From: Mary Barnes [mailto:mary.ietf.barnes@gmail.com] > > Sent: 16 February 2011 23:29 > > To: Elwell, John > > Cc: SIPCORE > > Subject: Re: Some comments on draft-ietf-sipcore-rfc4244bis-03.txt > > > > Hi John, > > > > Thanks for the comments. Responses inline below [MB]. > > > > Mary. > > > > > > On Wed, Feb 16, 2011 at 2:14 PM, Elwell, John > > wrote: > > > > > > Mary, > > > > Thanks for this major rewrite and addressing very many > > earlier comments. I have some initial comments and also a > > general comment. > > > > Comment 1: Request fails (4xx, say) and as a result a > > proxy retargets. According to 7.1.2, the proxy is required to > > include in the retargeted request all entries from received > > responses so far, including, presumably, entries in the 4xx > > response that leads to retargeting. However, if the request > > does not contain Supported: histinfo, there will be no > > entries in received responses. Therefore the final UAS will > > not receive a complete set of entries. So we seem to have the > > strange situation that the set of entries received by the UAS > > is dependent on support of History-Info at the UAC. This > > seems wrong. It seems to me that entries should always be > > sent backwards, subject to privacy, and perhaps not on the > > last hop if the UAC doesn't support it. > > > > > > [MB] > > > [JRE] Your responses seems to be lost. > > > > > Comment 2: Suppose a proxy forwards a request to two > > targets, one with entry index 1.1 and the other with entry > > index 1.2. A provisional or final response is received to the > > first forwarded request containing an additional entry with > > index 1.1.1. Then a 4xx response is received to the second > > request, causing the proxy to retarget, this time with an > > entry index 1.3. According to 7.1.2 step 1, that retargeted > > request should contain entries 1, 1.1.1, 1.2 and 1.3. Note > > that 1.1 is missing. I see nothing to require the inclusion > > of 1.1, yet step 1 of 7.1.2 seems to require inclusion of > > 1.1.1. Have I misinterpreted something? > > > > > > [MB] 1.1 should also be included. Perhaps the wording needs > > clarification, but the text is attempting to state that in > > cases where > [JRE] Your responses seems to have been truncated. > [MB2] I'm not sure if that was me or the cat. The text is attempting to state that all the hi-entries that were sent in previous requests, along with all the hi-entries in responses to those requests is included when the request is again retargeted. But, I can see that the current wording could be read that only the hi-entries in the original request versus the original request + any other requests for which responses have been received, as well as the hi-entries contained in all responses. However, I had thought the qualification that it states "in the original request that received the error response", so perhaps just removing the word "original" will suffice? [/MB2] > > > > > > > Comment 3: In 7.2 it states: > > "...MUST forward captured History-Info in > > subsequent, provisional, and final responses to the > > request sent by > > the ultimate UAS (see Section 6.2)..." > > When a proxy forwards a provisional response, how does > > it know that this is from the ultimate UAS? This can only be > > known when the first 2xx arrives. In fact the term "ultimate > > UAS" is also problematic because how does a proxy know that a > > response has come from a UAS, as opposed to a proxy? > > > > > > [MB] It doesn't know that it's the ultimate UAS, so=o we > > should remove that phrase. It's attempting to highlight that > > all the information is sent in the responses, but that's > > really covered elsewhere. [/MB] > [JRE] It does seem to make sense to simplify it so that you send all > information in all provisional or final responses (except 100). Just an > example to help confirm whether this simple rule makes sense: > A proxy forks, sending requests with indices 1.1, 1.2 and 1.3. Then the 1.3 > branch sends a response (provisional, final) containing additional entry > 1.3.1. In this case the response that the proxy sends upstream would contain > 1, 1.1, 1.2, 1.3 and 1.3.1 - correct? So even though the 1.1 and 1.2 > branches have not responded, they are included in the upstream response? > [MB2] The current approach is consistent with RFC 4244 whereby only the hi-entries for requests for which responses have been received are included in the upstream response. Again, it's hard for me to totally recall the logic, but I think it was because at that point in time, you don't know what will happen to that request - i.e., it's more misleading than helpful. We'd have to consider whether it would cause an issue with backwards compatibility if we change this now. IMHO, those entries only have value if you could accurately tag that they were outstanding or had timed out rather than infer that because they have no reason header means that the retargeting entity has not yet received a response. Also, per the comment above you would also have an hi-entry with an index of 1.1.1 and that hi-entry would have a Reason header field "escaped" in the hi-targeted-to-uri. Whereas, neither the 1.2 or 1.3.1 hi-entry would have a Reason header field in the hi-targeted-to-uri. I don't see that to cause so much confusion as there might be if it was 1.1., 1.2 and 1.3 requests had been issued at the same time and the only response comes from 1.2, which has an hi-entry of 1.2.1. Thus, the last hi-entry (i.e., 1.3) in the response isn't one for which the request has received a response. [/MB2] > > ---- Remainder snipped and put into Part 2: Document structure > > --0023547c895bbf61a7049c7e9dd0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable HI John,

Responses inline below [MB2]. =A0 I'm separ= ating the thread into two separate emails as I think there are two distinct= issues within this thread, so it will be easier to track.

Thanks,
Mary.=A0

On Thu, F= eb 17, 2011 at 2:20 AM, Elwell, John <john.elwell@siemens= -enterprise.com> wrote:
Mary,

Thanks - see below:

> -----Original Message-----
> From: Mary Barnes [mailto:mary.ietf.barnes@gmail.com]
> Sent: 16 February 2011 23:29
> To: Elwell, John
> Cc: SIPCORE
> Subject: Re: Some comments on draft-ietf-sipcore-rfc4244bis-03.txt
>
> Hi John,
>
> Thanks for the comments. Responses inline below [MB].
>
> Mary.
>
>
> On Wed, Feb 16, 2011 at 2:14 PM, Elwell, John
> <john.elwell@siemens-enterprise.com> wrote:
>
>
> =A0 =A0 =A0 Mary,
>
> =A0 =A0 =A0 Thanks for this major rewrite and addressing very many
> earlier comments. I have some initial comments and also a
> general comment.
>
> =A0 =A0 =A0 Comment 1: Request fails (4xx, say) and as a result a
> proxy retargets. According to 7.1.2, the proxy is required to
> include in the retargeted request all entries from received
> responses so far, including, presumably, entries in the 4xx
> response that leads to retargeting. However, if the request
> does not contain Supported: histinfo, there will be no
> entries in received responses. Therefore the final UAS will
> not receive a complete set of entries. So we seem to have the
> strange situation that the set of entries received by the UAS
> is dependent on support of History-Info at the UAC. This
> seems wrong. It seems to me that entries should always be
> sent backwards, subject to privacy, and perhaps not on the
> last hop if the UAC doesn't support it.
>
>
> =A0[MB]
>
[JRE] Your responses seems to be lost.

>
> =A0 =A0 =A0 Comment 2: Suppose a proxy forwards a request to two
> targets, one with entry index 1.1 and the other with entry
> index 1.2. A provisional or final response is received to the
> first forwarded request containing an additional entry with
> index 1.1.1. Then a 4xx response is received to the second
> request, causing the proxy to retarget, this time with an
> entry index 1.3. According to 7.1.2 step 1, that retargeted
> request should contain entries 1, 1.1.1, 1.2 and 1.3. Note
> that 1.1 is missing. I see nothing to require the inclusion
> of 1.1, yet step 1 of 7.1.2 seems to require inclusion of
> 1.1.1. Have I misinterpreted something?
>
>
> [MB] 1.1 should also be included. Perhaps the wording needs
> clarification, but the text is attempting to state that in
> cases where
[JRE] Your responses seems to have been truncated.
[MB2] I'm not sure if that was me or the cat. =A0 =A0The text is att= empting to state that all the hi-entries that were sent in previous request= s, along with all the hi-entries in responses to those requests is included= when the request is again retargeted. =A0 But, I can see that the current = wording could be read that only the hi-entries in the original request vers= us the original request + any other requests for which responses have been = received, as well as the hi-entries contained in all responses. =A0However,= I had thought the qualification that it states "in the original reque= st that received the error response", so perhaps just removing the wor= d "original" will suffice? [/MB2]

>
>
> =A0 =A0 =A0 Comment 3: In 7.2 it states:
> =A0 =A0 =A0 "...MUST forward captured History-Info in
> =A0 =A0 =A0 =A0 subsequent, provisional, and final responses to the > request sent by
> =A0 =A0 =A0 =A0 the ultimate UAS (see Section 6.2)..."
> =A0 =A0 =A0 When a proxy forwards a provisional response, how does
> it know that this is from the ultimate UAS? This can only be
> known when the first 2xx arrives. In fact the term "ultimate
> UAS" is also problematic because how does a proxy know that a
> response has come from a UAS, as opposed to a proxy?
>
>
> [MB] It doesn't know that it's the ultimate UAS, so=3Do we
> should remove that phrase. =A0It's attempting to highlight that > all the information is sent in the responses, but that's
> really covered elsewhere. [/MB]
[JRE] It does seem to make sense to simplify it so that you send all = information in all provisional or final responses (except 100). Just an exa= mple to help confirm whether this simple rule makes sense:
A proxy forks, sending requests with indices 1.1, 1.2 and 1.3. Then the 1.3= branch sends a response (provisional, final) containing additional entry 1= .3.1. In this case the response that the proxy sends upstream would contain= 1, 1.1, 1.2, 1.3 and 1.3.1 - correct? So even though the 1.1 and 1.2 branc= hes have not responded, they are included in the upstream response?

[MB2] The current approach is consistent w= ith RFC 4244 whereby only the hi-entries for requests for which responses h= ave been received are included in the upstream response. =A0Again, it's= hard for me to totally recall the logic, but I think it was because at tha= t point in time, you don't know what will happen to that request - i.e.= , it's more misleading than helpful. =A0 =A0We'd have to consider w= hether it would cause an issue with backwards compatibility if we change th= is now. IMHO, those entries only have value if you could accurately tag tha= t they were outstanding or had timed out rather than infer that because the= y have no reason header means that the retargeting entity has not yet recei= ved a response. Also, per the comment above you would also have an hi-entry= with an index of =A01.1.1 and that hi-entry would have a Reason header fie= ld "escaped" in the hi-targeted-to-uri. =A0Whereas, neither the 1= .2 or 1.3.1 hi-entry would have a Reason header field in the hi-targeted-to= -uri. I don't see that to cause so much confusion as there might be if = it was 1.1., 1.2 and 1.3 requests had been issued at the same time and the = only response comes from 1.2, which has an hi-entry of 1.2.1. Thus, the las= t hi-entry (i.e., 1.3) in the response isn't one for which the request = has received a response. [/MB2]

---- Remainder snipped and put into Part 2: Document structure


--0023547c895bbf61a7049c7e9dd0-- From mary.ietf.barnes@gmail.com Thu Feb 17 10:32:04 2011 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 2F25D3A6E1F for ; Thu, 17 Feb 2011 10:32:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.543 X-Spam-Level: X-Spam-Status: No, score=-103.543 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, 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 wfen5OO-R6b5 for ; Thu, 17 Feb 2011 10:32:02 -0800 (PST) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by core3.amsl.com (Postfix) with ESMTP id 1DEC53A6D9D for ; Thu, 17 Feb 2011 10:32:02 -0800 (PST) Received: by gxk27 with SMTP id 27so1252037gxk.31 for ; Thu, 17 Feb 2011 10:32:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:date:message-id:subject:from:to:cc :content-type; bh=csVFzj4DpLRBKFhwTNpRuOl7AH8wx3aq3KKBE4MFsqU=; b=RocuT788X9Q3wC0DFjFt+V6aJbFR/MZv2jPLqVEAMMrUP8dDDvbZA0uC590/Go0nZy aBHh5Uk1ubWfD+SqsUAXih2/AUufGaUOOfPj+lVpO9HV4U2KoKIvOG1Znd2n7HOQDYsb U+RbA875MDe8dp0wc/d/OX/SdLM8mHScQlK44= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type; b=cBEqGFau6gMBOScHitWJ2CrfR9s0SQUMVfgj4qf/2cpeOvDQ+yBcdY/UucN10m0I8m pz0ZB1sJDqZY1H9YNgo1HJ5Y50ZHT51O0QJ4xPvu65zubQlWF3mtJtRJCzFC66nwkgoI URegSlW5Yb5DJFZ4oPuPn/A5bur/vxXKAuRno= MIME-Version: 1.0 Received: by 10.236.109.168 with SMTP id s28mr3954094yhg.74.1297967553171; Thu, 17 Feb 2011 10:32:33 -0800 (PST) Received: by 10.236.95.35 with HTTP; Thu, 17 Feb 2011 10:32:32 -0800 (PST) Date: Thu, 17 Feb 2011 12:32:32 -0600 Message-ID: From: Mary Barnes To: "Elwell, John" Content-Type: multipart/alternative; boundary=0023547c8b43efd59c049c7e9e17 Cc: SIPCORE Subject: [sipcore] Part2: Some comments on draft-ietf-sipcore-rfc4244bis-03.txt - Document structure 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, 17 Feb 2011 18:32:04 -0000 --0023547c8b43efd59c049c7e9e17 Content-Type: text/plain; charset=ISO-8859-1 Hi John, See comments inline below [MB2]. Thanks, Mary. > ------ Earlier part snipped - see Part 1: Including all hi-entries in > responses > > > > > General comment: > > I found it really hard to understand how all the > > different procedures in sections 6, 7 and 8 fitted together, > > and I tried to analyse what exactly is going on. I came to > > the conclusion that, to a first approximation, we are trying > > to specify the following: > > > > 1. Procedures for receiving a request > > - Cache the sequence of entries received. > > - If no entry or if last entry does not match > > Request-URI, create one and add it to the cache. > > > > 2. Procedures for sending a request > > - Include all cached entries (if any). > > - Also include an entry reflecting the Request-URI of > > the sent request (not quite sure if this should go in the > > cache at this stage). > > - In case of recursing, include in that new entry > > parameters from the Contact header field of the 3XX response. > > > > 3. Procedures for receiving a response (other than 100) > > - Add to the cache any entries in the response not > > already in the cache. > > > > 4. Procedures for sending a response (other than 100) > > - Include all cached entries. > > > > I am sure this is an over simplification. It doesn't > > take account of the presence of the option tag in Supported > > (influences response behaviour), privacy considerations, > > populating the index, etc.. Also there are clearly some > > issues concerning exactly what a proxy includes from previous > > targetings when it retargets, what goes in provisional > > responses, and so on (impacted by the comments above, no > > doubt). However, I can't help feeling there might be a much > > simpler way of documenting all this. > > > > > > [MB] At this point, having worked on this document way too > > long, it's really hard for me to see how to make it more > > clear. It really is fairly simple. The intent of 7.1.1 was > > to define the steps similar to your simplified summary above. > [JRE] That is not how I see it. 7.1 only deals with requests, not > responses, and 7.1 only deals with proxy/intermediary, not UAC, UAS, > redirect server. I was trying to pull all these together into one set of > procedures that is common to all (except obviously steps relating to > receiving a request and sending a response will not apply to a UAC and steps > relating to sending a request and receiving a response will not apply to a > UAS or redirect server (or a proxy that rejects). In other words, I was > trying to pull together sections 6, 7 and 8 into a single section covering > everything. This is because procedures for receiving request, for example, > are similar no matter which entity is involved. > [MB2] Correct 7.1 only deals with requests, but that section does comprise your items 1 and 2. Per my response below, it was a conscious decision to split the processing as I noted has been done with other RFCs. And, there are slight differences for the processing for receipt of requests by a UAS versus an intermediary and responses at a UAC versus and intermediary. I do not see that there is a significant amount of redundant text as is. We could rewrite certainly (yet again) if there is consensus that it is not possible to understand normative behavior from this version. I can see value in adding an overview section that summarizes the overall processing (per the end of your email) and then we can leave 6, 7 and 8 as is. We can also consider that previous feedback was that we need more of an overview of processing, which is why some additional text was added to section in a previous update. [/MB2] > > > As far as handling the privacy, that applies to the entirety > > of the hi-entries being included in an outgoing request per > > the rules that we tried to highlight in the updated privacy > > section. The mechanism by which the index is calculated is > > referenced in the appropriate sections and included all in > > one place. I could see that we could spread out how all the > > parameters are determined directly in the processing flow and > > within the discussion of the specific cases, however, that > > isn't nearly as modular IMHO. We did have some of it > > previously, but we also had inconsistencies by doing so (and > > overuse of normative statements at least as I interpreted WG > > feedback). > [JRE] I am quite happy with common procedures like privacy, Reason header > field and indexing to be kept separate, as we already have in section 9. My > comments referred to sections 6, 7 and 8, and even if we decide to > restructure these, we can still refer out to section 9 for the common bits. > > > IMHO the current form is easier from an > > implementors perspective. And, the form of this document is > > not dramatically unlike other RFCs, including RFC 3261 > > although the ABNF is earlier in the document in 4244bis. > > 4244bis follows the model of describing processing for each > > of the functional entities and then has sections that > > describe the handling for each protocol element. From a > > quick glance RFC 4028 (Session timer) and RFC 3325 > > (P-Asserted-Identity) have separate sections for Proxy and UA > > behaviors, as well although the ABNF is later (but again we > > got feedback that it should be earlier. It's really a chicken > > egg thing in my opinion as to whether you see the protocol > > elements first and whether the normative behavior for each > > parameter is separate from the processing flow for the SIP > > entities and whether the latter is separated - i.e., we could > > have a handling the request section that includes the UAC and > > SIP intermediary behavior and then have a response section > > that includes SIP intermediary and UAS processing. But, > > again I personally feel that have the sections separate is > > more useful for implementors that are in many cases > > developing code for only a single functional entity. [/MB] > [JRE] Putting aside for the moment the question of whether to restructure > sections 6, 7 and 8, I would like to try to refine the simplified model I > proposed to get a common understanding of what we are trying to achieve. A > commonly understood model would help me to review the existing text to > ensure that it is consistent with the model. At present I am finding it > difficult to understand the text. Perhaps that is my fault, not having put > enough time into it, but I would appreciate assistance from the WG in trying > to get a better understanding. So here again is the model as I see it > (slightly changed from before): > > > 1. Procedures for receiving a request > - Cache the sequence of entries received. > - If no entry or if last entry does not match Request-URI, create one and > add it to the cache. > > 2. Procedures for sending a request > - Generate an additional entry reflecting the Request-URI of the sent > request, and add this to the cache. > - In case of recursing, include in that new entry parameters from the > Contact header field of the 3XX response. > - Include all cached entries. > > 3. Procedures for receiving a response (other than 100) > - Add to the cache any entries in the response not already in the cache. > - In the case of a 3xx/4xx/5xx/6xx response, add a Reason header field to > the cached entry that was generated for the corresponding request. > > 4. Procedures for sending a response (other than 100) > - Include all cached entries. > > All of the above subject to common rules relating to privacy, histinfo > option tag, and indices. > [MB2] Per my comment above, I also think it could add value to have an overview of the processing, but I still think it's better to have separate UAC, UAS, etc. processing per my comments above. My one fear, however, is that this would take the document back to the point that folks are saying there is too much redundant text, the doc is too big, etc. We do explain the structure of the doc in section 5 in an attempt to set the appropriate context for folks in reading the sections. And, we did previously add a bit more detail on the overall flow of handling the header. Thus, I think there might be a middle ground and we beef up the text in section 5 or we update section 6 to include sub-sections for what is now 6, 7 & 8 and include an overview of operation in body of section 6. [/MB2] > > John --0023547c8b43efd59c049c7e9e17 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi John,

See comments inline below [MB2].

Thanks,
Mary.=A0

= =A0
------ Earlier part snipped - see Part 1: Including = all hi-entries in responses

=A0=
>
> =A0 =A0 =A0 General comment:
> = =A0 =A0 =A0 I found it really hard to understand how all the
> differ= ent procedures in sections 6, 7 and 8 fitted together,
> and I tried = to analyse what exactly is going on. I came to
> the conclusion that, to a first approximation, we are trying
> t= o specify the following:
>
> =A0 =A0 =A0 1. Procedures for rece= iving a request
> =A0 =A0 =A0 - Cache the sequence of entries receive= d.
> =A0 =A0 =A0 - If no entry or if last entry does not match
> Request-URI, create one and add it to the cache.
>
> =A0 = =A0 =A0 2. Procedures for sending a request
> =A0 =A0 =A0 - Include a= ll cached entries (if any).
> =A0 =A0 =A0 - Also include an entry ref= lecting the Request-URI of
> the sent request (not quite sure if this should go in the
> cach= e at this stage).
> =A0 =A0 =A0 - In case of recursing, include in th= at new entry
> parameters from the Contact header field of the 3XX re= sponse.
>
> =A0 =A0 =A0 3. Procedures for receiving a response (other than= 100)
> =A0 =A0 =A0 - Add to the cache any entries in the response no= t
> already in the cache.
>
> =A0 =A0 =A0 4. Procedures f= or sending a response (other than 100)
> =A0 =A0 =A0 - Include all cached entries.
>
> =A0 =A0 =A0 = I am sure this is an over simplification. It doesn't
> take accou= nt of the presence of the option tag in Supported
> (influences respo= nse behaviour), privacy considerations,
> populating the index, etc.. Also there are clearly some
> issues= concerning exactly what a proxy includes from previous
> targetings = when it retargets, what goes in provisional
> responses, and so on (i= mpacted by the comments above, no
> doubt). However, I can't help feeling there might be a much
>= ; simpler way of documenting all this.
>
>
> [MB] At this= point, having worked on this document way too
> long, it's reall= y hard for me to see how to make it more
> clear. =A0It really is fairly simple. The intent of 7.1.1 was
> = to define the steps similar to your simplified summary above.
[JRE] That is not how I see it. 7.1 only deals with requests, not respons= es, and 7.1 only deals with proxy/intermediary, not UAC, UAS, redirect serv= er. I was trying to pull all these together into one set of procedures that= is common to all (except obviously steps relating to receiving a request a= nd sending a response will not apply to a UAC and steps relating to sending= a request and receiving a response will not apply to a UAS or redirect ser= ver (or a proxy that rejects). In other words, I was trying to pull togethe= r sections 6, 7 and 8 into a single section covering everything. This is be= cause procedures for receiving request, for example, are similar no matter = which entity is involved.

[MB2] Correct 7.1 only deals with requests= , but that section does comprise your items 1 and 2.=A0
Per my re= sponse below, it was a conscious decision to split the processing as I note= d has been done with other RFCs. =A0 =A0And, there are slight differences f= or the processing for receipt of requests by a UAS versus an intermediary a= nd responses at a UAC versus and intermediary. =A0I do not see that there i= s a significant amount of redundant text as is. =A0We could rewrite certain= ly (yet again) if there is consensus that it is not possible to understand = normative behavior from this version. I can see value in adding an overview= section that summarizes the overall processing (per the end of your email)= and then we can leave 6, 7 and 8 as is. =A0We can also consider that previ= ous feedback was that we need more of an overview of processing, which is w= hy some additional text was added to section =A0 =A0 in a previous update. = [/MB2]

> As far as handling the privacy, that applies to = the entirety
> of the hi-entries being included in an outgoing reques= t per
> the rules that we tried to highlight in the updated privacy > section. =A0The mechanism by which the index is calculated is
> = referenced in the appropriate sections and included all in
> one plac= e. =A0I could see that we could spread out how all the
> parameters a= re determined directly in the processing flow and
> within the discussion of the specific cases, however, that
> isn= 't nearly as modular IMHO. We did have some of it
> previously, b= ut we also had inconsistencies by doing so (and
> overuse of normativ= e statements at least as I interpreted WG
> feedback).
[JRE] I am quite happy with common procedures like= privacy, Reason header field and indexing to be kept separate, as we alrea= dy have in section 9. My comments referred to sections 6, 7 and 8, and even= if we decide to restructure these, we can still refer out to section 9 for= the common bits.

> IMHO =A0the current form is easier from an
&g= t; implementors perspective. And, the form of this document is
> not = dramatically unlike other RFCs, including RFC 3261
> although the ABN= F is earlier in the document in 4244bis.
> 4244bis follows the model of describing processing for each
> of= the functional entities and then has sections that
> describe the ha= ndling for each protocol element. =A0From a
> quick glance RFC 4028 (= Session timer) and =A0RFC 3325
> (P-Asserted-Identity) have separate sections for Proxy and UA
> = behaviors, as well although the ABNF is later (but again we
> got fee= dback that it should be earlier. It's really a chicken
> egg thin= g in my opinion as to whether you see the protocol
> elements first and whether the normative behavior for each
> par= ameter is separate from the processing flow for the SIP
> entities an= d whether the latter is separated - i.e., we could
> have a handling = the request section that includes the UAC and
> SIP intermediary behavior and then have a response section
> tha= t includes SIP intermediary and UAS processing. =A0But,
> again I per= sonally feel that have the sections separate is
> more useful for imp= lementors that are in many cases
> developing code for only a single functional entity. =A0[/MB]
[JRE] Putting aside for the moment the question of whether to restructure = sections 6, 7 and 8, I would like to try to refine the simplified model I p= roposed to get a common understanding of what we are trying to achieve. A c= ommonly understood model would help me to review the existing text to ensur= e that it is consistent with the model. At present I am finding it difficul= t to understand the text. Perhaps that is my fault, not having put enough t= ime into it, but I would appreciate assistance from the WG in trying to get= a better understanding. So here again is the model as I see it (slightly c= hanged from before):


1. Procedures for receiving a request
- Cache = the sequence of entries received.
- If no entry or if last entry does no= t match Request-URI, create one and add it to the cache.

2. Procedur= es for sending a request
- Generate an additional entry reflecting the Request-URI of the sent= request, and add this to the cache.
- In case of recu= rsing, include in that new entry parameters from the Contact header field o= f the 3XX response.
- Include all cached entries.

3. Procedures = for receiving a response (other than 100)
- Add to the cache any entries= in the response not already in the cache.
- In the case of a 3xx/= 4xx/5xx/6xx response, add a Reason header field to the cached entry that wa= s generated for the corresponding request.

4. Procedures for sending a response (other than 100)=
- Include all cached entries.

All of the above subject to = common rules relating to privacy, histinfo option tag, and indices.
[MB2] Per my comment above, I also think it could add value to have an= overview of the processing, but I still think it's better to have sepa= rate UAC, UAS, etc. processing per my comments above. =A0My one fear, howev= er, is that this would take the document back to the point that folks are s= aying there is too much redundant text, the doc is too big, etc.=A0We do ex= plain the structure of the doc in section 5 in an attempt to set the approp= riate context for folks in reading the sections. And, we did previously add= a bit more detail on the overall flow of handling the header.=A0=A0Thus, I= think there might be a middle ground and we beef up the text in section 5 = or we update section 6 to include sub-sections for what is now 6, 7 & 8= and include an overview of operation in body of section 6. =A0 =A0[/MB2]= =A0

John
--0023547c8b43efd59c049c7e9e17-- From john.elwell@siemens-enterprise.com Thu Feb 17 13:08:34 2011 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 E07103A6E8F for ; Thu, 17 Feb 2011 13:08:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.336 X-Spam-Level: X-Spam-Status: No, score=-102.336 tagged_above=-999 required=5 tests=[AWL=-0.337, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, 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 ZsgvScWdjrJ2 for ; Thu, 17 Feb 2011 13:08:33 -0800 (PST) Received: from ms03.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id 39F493A6D73 for ; Thu, 17 Feb 2011 13:08:32 -0800 (PST) Received: from senmx11-mx ([62.134.46.9] [62.134.46.9]) by ms03.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-3435565; Thu, 17 Feb 2011 22:09:04 +0100 Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx11-mx (Server) with ESMTP id EFECB1EB82B0; Thu, 17 Feb 2011 22:09:03 +0100 (CET) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Thu, 17 Feb 2011 22:09:03 +0100 From: "Elwell, John" To: Mary Barnes Date: Thu, 17 Feb 2011 22:09:01 +0100 Thread-Topic: Part1: Some comments on draft-ietf-sipcore-rfc4244bis-03.txt - Including all hi-entries in responses Thread-Index: AcvO0P/BcJMr2g7cSkWlP4qAe2QEFQAD946g Message-ID: References: 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 Cc: SIPCORE Subject: Re: [sipcore] Part1: Some comments on draft-ietf-sipcore-rfc4244bis-03.txt - Including all hi-entries 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, 17 Feb 2011 21:08:35 -0000 =20 > -----Original Message----- > From: Mary Barnes [mailto:mary.ietf.barnes@gmail.com]=20 > Sent: 17 February 2011 18:32 > To: Elwell, John > Cc: SIPCORE > Subject: Part1: Some comments on=20 > draft-ietf-sipcore-rfc4244bis-03.txt - Including all=20 > hi-entries in responses >=20 > HI John,=20 >=20 > Responses inline below [MB2]. I'm separating the thread=20 > into two separate emails as I think there are two distinct=20 > issues within this thread, so it will be easier to track. >=20 > Thanks, > Mary.=20 >=20 >=20 > On Thu, Feb 17, 2011 at 2:20 AM, Elwell, John=20 > wrote: >=20 >=20 > Mary, > =09 > Thanks - see below: > =09 >=20 > > -----Original Message----- > > From: Mary Barnes [mailto:mary.ietf.barnes@gmail.com] > > Sent: 16 February 2011 23:29 > > To: Elwell, John > > Cc: SIPCORE > > Subject: Re: Some comments on=20 > draft-ietf-sipcore-rfc4244bis-03.txt > > > > Hi John, > > > > Thanks for the comments. Responses inline below [MB]. > > > > Mary. > > > > > > On Wed, Feb 16, 2011 at 2:14 PM, Elwell, John > > wrote: > > > > > > Mary, > > > > Thanks for this major rewrite and addressing very many > > earlier comments. I have some initial comments and also a > > general comment. > > > > Comment 1: Request fails (4xx, say) and as a result a > > proxy retargets. According to 7.1.2, the proxy is required to > > include in the retargeted request all entries from received > > responses so far, including, presumably, entries in the 4xx > > response that leads to retargeting. However, if the request > > does not contain Supported: histinfo, there will be no > > entries in received responses. Therefore the final UAS will > > not receive a complete set of entries. So we seem to have the > > strange situation that the set of entries received by the UAS > > is dependent on support of History-Info at the UAC. This > > seems wrong. It seems to me that entries should always be > > sent backwards, subject to privacy, and perhaps not on the > > last hop if the UAC doesn't support it. > > > > > > [MB] > > > =09 > [JRE] Your responses seems to be lost. [JRE] I still don't see your response to this one. > > > > Comment 2: Suppose a proxy forwards a request to two > > targets, one with entry index 1.1 and the other with entry > > index 1.2. A provisional or final response is received to the > > first forwarded request containing an additional entry with > > index 1.1.1. Then a 4xx response is received to the second > > request, causing the proxy to retarget, this time with an > > entry index 1.3. According to 7.1.2 step 1, that retargeted > > request should contain entries 1, 1.1.1, 1.2 and 1.3. Note > > that 1.1 is missing. I see nothing to require the inclusion > > of 1.1, yet step 1 of 7.1.2 seems to require inclusion of > > 1.1.1. Have I misinterpreted something? > > > > > > [MB] 1.1 should also be included. Perhaps the wording needs > > clarification, but the text is attempting to state that in > > cases where > =09 > [JRE] Your responses seems to have been truncated. > =09 >=20 > [MB2] I'm not sure if that was me or the cat. The text is=20 > attempting to state that all the hi-entries that were sent in=20 > previous requests, along with all the hi-entries in responses=20 > to those requests is included when the request is again=20 > retargeted. But, I can see that the current wording could=20 > be read that only the hi-entries in the original request=20 > versus the original request + any other requests for which=20 > responses have been received, as well as the hi-entries=20 > contained in all responses. However, I had thought the=20 > qualification that it states "in the original request that=20 > received the error response", so perhaps just removing the=20 > word "original" will suffice? [/MB2] [JRE] I am still confused by your explanation. Let me put the question a di= fferent way: When I fork a request to several different targets, and when one of those b= ranches returns a response which leads me to retarget, what is included in = the retargeted request? 1. Clearly all entries received from upstream. 2. Clearly a new entry for the new target. 3. Clearly the entry for the request whose response caused me to retarget, = and any additional entries in that response. 4. Do I include entries for other requests on other branches that have resp= onded finally, and any additional entries in those responses, even though t= hey have not led to retargeting? I think your intention is "yes". 5. Do I include entries for other requests on other branches that have resp= onded provisionally, and any additional entries in those responses, even th= ough they have not led to retargeting? I think your intention is "yes", but= I am not certain (see also my comments further down concerning Reason head= er field - an answer of "no" might make more sense). 6. Do I include entries for other requests on other branches that have not = yet responded? I think your intention is "no". Please confirm my assumptions above. Depending on that we can try to addres= s the wording, but I am not sure just deleting "original" from the previous= text really helps. > > > > Comment 3: In 7.2 it states: > > "...MUST forward captured History-Info in > > subsequent, provisional, and final responses to the > > request sent by > > the ultimate UAS (see Section 6.2)..." > > When a proxy forwards a provisional response, how does > > it know that this is from the ultimate UAS? This can only be > > known when the first 2xx arrives. In fact the term "ultimate > > UAS" is also problematic because how does a proxy know that a > > response has come from a UAS, as opposed to a proxy? > > > > > > [MB] It doesn't know that it's the ultimate UAS, so=3Do we > > should remove that phrase. It's attempting to highlight that > > all the information is sent in the responses, but that's > > really covered elsewhere. [/MB] > =09 > [JRE] It does seem to make sense to simplify it so that=20 > you send all information in all provisional or final=20 > responses (except 100). Just an example to help confirm=20 > whether this simple rule makes sense: > A proxy forks, sending requests with indices 1.1, 1.2=20 > and 1.3. Then the 1.3 branch sends a response (provisional,=20 > final) containing additional entry 1.3.1. In this case the=20 > response that the proxy sends upstream would contain 1, 1.1,=20 > 1.2, 1.3 and 1.3.1 - correct? So even though the 1.1 and 1.2=20 > branches have not responded, they are included in the=20 > upstream response? > =09 >=20 >=20 > [MB2] The current approach is consistent with RFC 4244=20 > whereby only the hi-entries for requests for which responses=20 > have been received are included in the upstream response. =20 [JRE] So you are saying that in my example above, indices 1.1 and 1.2 would= not be sent upstream, because they have not responded? I am not asking for= an explanation of how we got there - just asking what the model is intende= d to be. > Again, it's hard for me to totally recall the logic, but I=20 > think it was because at that point in time, you don't know=20 > what will happen to that request - i.e., it's more misleading=20 > than helpful. We'd have to consider whether it would cause=20 > an issue with backwards compatibility if we change this now.=20 > IMHO, those entries only have value if you could accurately=20 > tag that they were outstanding or had timed out rather than=20 > infer that because they have no reason header means that the=20 > retargeting entity has not yet received a response. [JRE] You have brought to my attention something I missed before. When you = put a Reason header field into an hi-entry, you now only convey that Reason= header field in that hi-entry in the retargeted request downstream, but al= so in that same hi-entry when it gets sent upstream for any reason. So it b= egins to make sense to me now why you would exclude entries for requests th= at have not produced a response. However, this leads me to a couple of furt= her questions: 1. According to 9.2, it is only failed requests that lead to retargeting th= at cause a Reason header field to be placed in their hi-entry, not failed r= equests that do not directly lead to retargeting. From what you say above, = it seems that any failed request (3xx, 4xx, 5xx, 6xx) should cause a Reason= header field to be placed into its hi-entry, even if that request does not= lead to retargeting. 2. What about requests that so far have only produced a provisional respons= e and have not been the cause of retargeting. Does that 1xx response code g= et put in the hi-entry as a Reason header field, and are those entries incl= uded in any upstream responses or retargeted requests that might be sent be= fore the branch concerned issues a final response? > Also, per=20 > the comment above you would also have an hi-entry with an=20 > index of 1.1.1 and that hi-entry would have a Reason header=20 > field "escaped" in the hi-targeted-to-uri. Whereas, neither=20 > the 1.2 or 1.3.1 hi-entry would have a Reason header field in=20 > the hi-targeted-to-uri. I don't see that to cause so much=20 > confusion as there might be if it was 1.1., 1.2 and 1.3=20 > requests had been issued at the same time and the only=20 > response comes from 1.2, which has an hi-entry of 1.2.1.=20 > Thus, the last hi-entry (i.e., 1.3) in the response isn't one=20 > for which the request has received a response. [/MB2] [JRE] I am lost on this one - I don't see the relevance of 1.1.1, which was= not in my example. But anyway, if you answer the questions above, it shoul= d help. John= From john.elwell@siemens-enterprise.com Thu Feb 17 13:26:32 2011 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 1A4E83A6C32 for ; Thu, 17 Feb 2011 13:26:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.626 X-Spam-Level: X-Spam-Status: No, score=-102.626 tagged_above=-999 required=5 tests=[AWL=-0.027, BAYES_00=-2.599, 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 Fq+RpptpWCS1 for ; Thu, 17 Feb 2011 13:26:30 -0800 (PST) Received: from ms01.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id 3C7133A6CC3 for ; Thu, 17 Feb 2011 13:26:29 -0800 (PST) Received: from senmx11-mx ([62.134.46.9] [62.134.46.9]) by ms01.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-3446405; Thu, 17 Feb 2011 22:27:01 +0100 Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx11-mx (Server) with ESMTP id 346151EB82AB; Thu, 17 Feb 2011 22:27:01 +0100 (CET) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Thu, 17 Feb 2011 22:27:01 +0100 From: "Elwell, John" To: Mary Barnes Date: Thu, 17 Feb 2011 22:26:58 +0100 Thread-Topic: Part2: Some comments on draft-ietf-sipcore-rfc4244bis-03.txt - Document structure Thread-Index: AcvO0Qv4mDs+5JozRG+oL8aCtPBYpgAFeQ1w Message-ID: References: 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 Cc: SIPCORE Subject: Re: [sipcore] Part2: Some comments on draft-ietf-sipcore-rfc4244bis-03.txt - Document structure 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, 17 Feb 2011 21:26:32 -0000 =20 > -----Original Message----- > From: Mary Barnes [mailto:mary.ietf.barnes@gmail.com]=20 > Sent: 17 February 2011 18:33 > To: Elwell, John > Cc: SIPCORE > Subject: Part2: Some comments on=20 > draft-ietf-sipcore-rfc4244bis-03.txt - Document structure >=20 > Hi John, >=20 > See comments inline below [MB2]. >=20 > Thanks, > Mary.=20 >=20 > =20 >=20 > ------ Earlier part snipped - see Part 1: Including all=20 > hi-entries in responses >=20 >=20 > =20 >=20 > > > > General comment: > > I found it really hard to understand how all the > > different procedures in sections 6, 7 and 8 fitted together, > > and I tried to analyse what exactly is going on. I came to > > the conclusion that, to a first approximation, we are trying > > to specify the following: > > > > 1. Procedures for receiving a request > > - Cache the sequence of entries received. > > - If no entry or if last entry does not match > > Request-URI, create one and add it to the cache. > > > > 2. Procedures for sending a request > > - Include all cached entries (if any). > > - Also include an entry reflecting the Request-URI of > > the sent request (not quite sure if this should go in the > > cache at this stage). > > - In case of recursing, include in that new entry > > parameters from the Contact header field of the 3XX response. > > > > 3. Procedures for receiving a response (other than 100) > > - Add to the cache any entries in the response not > > already in the cache. > > > > 4. Procedures for sending a response (other than 100) > > - Include all cached entries. > > > > I am sure this is an over simplification. It doesn't > > take account of the presence of the option tag in Supported > > (influences response behaviour), privacy considerations, > > populating the index, etc.. Also there are clearly some > > issues concerning exactly what a proxy includes from previous > > targetings when it retargets, what goes in provisional > > responses, and so on (impacted by the comments above, no > > doubt). However, I can't help feeling there might be a much > > simpler way of documenting all this. > > > > > > [MB] At this point, having worked on this document way too > > long, it's really hard for me to see how to make it more > > clear. It really is fairly simple. The intent of 7.1.1 was > > to define the steps similar to your simplified summary above. > =09 > [JRE] That is not how I see it. 7.1 only deals with=20 > requests, not responses, and 7.1 only deals with=20 > proxy/intermediary, not UAC, UAS, redirect server. I was=20 > trying to pull all these together into one set of procedures=20 > that is common to all (except obviously steps relating to=20 > receiving a request and sending a response will not apply to=20 > a UAC and steps relating to sending a request and receiving a=20 > response will not apply to a UAS or redirect server (or a=20 > proxy that rejects). In other words, I was trying to pull=20 > together sections 6, 7 and 8 into a single section covering=20 > everything. This is because procedures for receiving request,=20 > for example, are similar no matter which entity is involved. > =09 >=20 >=20 > [MB2] Correct 7.1 only deals with requests, but that section=20 > does comprise your items 1 and 2.=20 > Per my response below, it was a conscious decision to split=20 > the processing as I noted has been done with other RFCs. =20 > And, there are slight differences for the processing for=20 > receipt of requests by a UAS versus an intermediary and=20 > responses at a UAC versus and intermediary. I do not see=20 > that there is a significant amount of redundant text as is. =20 > We could rewrite certainly (yet again) if there is consensus=20 > that it is not possible to understand normative behavior from=20 > this version. I can see value in adding an overview section=20 > that summarizes the overall processing (per the end of your=20 > email) and then we can leave 6, 7 and 8 as is. We can also=20 > consider that previous feedback was that we need more of an=20 > overview of processing, which is why some additional text was=20 > added to section in a previous update. [/MB2] >=20 >=20 > > As far as handling the privacy, that applies to the entirety > > of the hi-entries being included in an outgoing request per > > the rules that we tried to highlight in the updated privacy > > section. The mechanism by which the index is calculated is > > referenced in the appropriate sections and included all in > > one place. I could see that we could spread out how all the > > parameters are determined directly in the processing flow and > > within the discussion of the specific cases, however, that > > isn't nearly as modular IMHO. We did have some of it > > previously, but we also had inconsistencies by doing so (and > > overuse of normative statements at least as I interpreted WG > > feedback). > =09 > [JRE] I am quite happy with common procedures like=20 > privacy, Reason header field and indexing to be kept=20 > separate, as we already have in section 9. My comments=20 > referred to sections 6, 7 and 8, and even if we decide to=20 > restructure these, we can still refer out to section 9 for=20 > the common bits. > =09 >=20 > > IMHO the current form is easier from an > > implementors perspective. And, the form of this document is > > not dramatically unlike other RFCs, including RFC 3261 > > although the ABNF is earlier in the document in 4244bis. > > 4244bis follows the model of describing processing for each > > of the functional entities and then has sections that > > describe the handling for each protocol element. From a > > quick glance RFC 4028 (Session timer) and RFC 3325 > > (P-Asserted-Identity) have separate sections for Proxy and UA > > behaviors, as well although the ABNF is later (but again we > > got feedback that it should be earlier. It's really a chicken > > egg thing in my opinion as to whether you see the protocol > > elements first and whether the normative behavior for each > > parameter is separate from the processing flow for the SIP > > entities and whether the latter is separated - i.e., we could > > have a handling the request section that includes the UAC and > > SIP intermediary behavior and then have a response section > > that includes SIP intermediary and UAS processing. But, > > again I personally feel that have the sections separate is > > more useful for implementors that are in many cases > > developing code for only a single functional entity. [/MB] > =09 > [JRE] Putting aside for the moment the question of=20 > whether to restructure sections 6, 7 and 8, I would like to=20 > try to refine the simplified model I proposed to get a common=20 > understanding of what we are trying to achieve. A commonly=20 > understood model would help me to review the existing text to=20 > ensure that it is consistent with the model. At present I am=20 > finding it difficult to understand the text. Perhaps that is=20 > my fault, not having put enough time into it, but I would=20 > appreciate assistance from the WG in trying to get a better=20 > understanding. So here again is the model as I see it=20 > (slightly changed from before): > =09 >=20 >=20 > 1. Procedures for receiving a request > - Cache the sequence of entries received. > - If no entry or if last entry does not match=20 > Request-URI, create one and add it to the cache. > =09 > 2. Procedures for sending a request > =09 > - Generate an additional entry reflecting the=20 > Request-URI of the sent request, and add this to the cache. > =09 > - In case of recursing, include in that new entry=20 > parameters from the Contact header field of the 3XX response. > =09 > - Include all cached entries. > =09 >=20 > 3. Procedures for receiving a response (other than 100) > - Add to the cache any entries in the response not=20 > already in the cache. > =09 > - In the case of a 3xx/4xx/5xx/6xx response, add a=20 > Reason header field to the cached entry that was generated=20 > for the corresponding request. > =09 >=20 > 4. Procedures for sending a response (other than 100) > - Include all cached entries. > =09 > =09 > All of the above subject to common rules relating to=20 > privacy, histinfo option tag, and indices. > =09 >=20 > [MB2] Per my comment above, I also think it could add value=20 > to have an overview of the processing, but I still think it's=20 > better to have separate UAC, UAS, etc. processing per my=20 > comments above. My one fear, however, is that this would=20 > take the document back to the point that folks are saying=20 > there is too much redundant text, the doc is too big, etc. We=20 > do explain the structure of the doc in section 5 in an=20 > attempt to set the appropriate context for folks in reading=20 > the sections. And, we did previously add a bit more detail on=20 > the overall flow of handling the header. Thus, I think there=20 > might be a middle ground and we beef up the text in section 5=20 > or we update section 6 to include sub-sections for what is=20 > now 6, 7 & 8 and include an overview of operation in body of=20 > section 6. [/MB2]=20 [JRE] The simple model I am trying to capture by email is just for understa= nding. When I fully understand what we are trying to achieve technically (I= thought I understood it months ago during the previous review, but clearly= not) I can then try to determine whether there are holes that need fixing = in the current text and whether these just require patches or something mor= e substantial. I will start a new thread on the model. John >=20 > =09 > John >=20 > = From john.elwell@siemens-enterprise.com Thu Feb 17 13:28:16 2011 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 017DB3A6D73 for ; Thu, 17 Feb 2011 13:28:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.626 X-Spam-Level: X-Spam-Status: No, score=-102.626 tagged_above=-999 required=5 tests=[AWL=-0.027, BAYES_00=-2.599, 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 izDH3G9+7Swu for ; Thu, 17 Feb 2011 13:28:15 -0800 (PST) Received: from ms04.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id D9A6A3A6C32 for ; Thu, 17 Feb 2011 13:28:14 -0800 (PST) Received: from senmx12-mx ([62.134.46.10] [62.134.46.10]) by ms04.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-3448859 for sipcore@ietf.org; Thu, 17 Feb 2011 22:28:46 +0100 Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx12-mx (Server) with ESMTP id 32C3823F0278 for ; Thu, 17 Feb 2011 22:28:46 +0100 (CET) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Thu, 17 Feb 2011 22:28:46 +0100 From: "Elwell, John" To: SIPCORE Date: Thu, 17 Feb 2011 22:28:44 +0100 Thread-Topic: Model for manipulating hi-entries Thread-Index: AcvO6ad0mjoUWivhSDeKITqDKvAPcA== Message-ID: 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: [sipcore] Model for manipulating hi-entries 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, 17 Feb 2011 21:28:16 -0000 In trying to review the rfc4244bis-03, I have tried to write down the model= I have in my mind as to what we are trying to achieve at any of the entiti= es involved (UAC, UAS, redirect, proxy). Based on what is in the draft and = clarifications Mary has given in response to my comments, this is my curren= t understanding: 1. Procedures for receiving a request - Cache the sequence of entries received. - If no entry or if last entry does not match Request-URI, create one and a= dd it to the cache. 2. Procedures for sending a request - Include all cached entries in the request. - Generate an additional entry reflecting the Request-URI of the sent reque= st, and add this to the request (but not the cache). - In case of recursing, include in that new entry parameters from the Conta= ct header field of the 3XX response. 3. Procedures for receiving a response (other than 100) - Add to the cache the entry that was placed in the request and include in = that cached entry a Reason header field containing the received response co= de (does this include 2xx too?). - Add to the cache any entries in the response not already in the cache (i.= e., any entries added by downstream entities). 4. Procedures for sending a response (other than 100) - Include all cached entries. All of the above subject to common rules relating to privacy, histinfo opti= on tag, and indices. John= From pkyzivat@cisco.com Fri Feb 18 16:19:08 2011 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 EA3263A6D6F for ; Fri, 18 Feb 2011 16:19:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 k5yATBqDRlTU for ; Fri, 18 Feb 2011 16:19:07 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 3CE753A6D37 for ; Fri, 18 Feb 2011 16:19:07 -0800 (PST) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.62,190,1297036800"; d="scan'208";a="217495808" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 19 Feb 2011 00:19:41 +0000 Received: from [161.44.174.114] (dhcp-161-44-174-114.cisco.com [161.44.174.114]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id p1J0Jeuu004640; Sat, 19 Feb 2011 00:19:40 GMT Message-ID: <4D5F0C9C.5000308@cisco.com> Date: Fri, 18 Feb 2011 19:19:40 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: "James M. Polk" References: <4D547232.7020704@nostrum.com> <4D5540B6.1050506@cisco.com> <201102111948.p1BJmXxJ011459@sj-core-3.cisco.com> <4D559C56.1070709@cisco.com> <201102142322.p1ENMj4D020196@sj-core-1.cisco.com> <4D5A88AA.6000705@cisco.com> <201102152336.p1FNaGiE007329@sj-core-1.cisco.com> <4D5B1DBA.6040209@cisco.com> <182CE620-3D8A-457B-A243-43607B0FEB8D@neustar.biz> <4D5B31E8.2040909@cisco.com> <4D5C5799.9030203@nostrum.com> <201102162346.p1GNkdDV019674@sj-core-1.cisco.com> In-Reply-To: <201102162346.p1GNkdDV019674@sj-core-1.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "sipcore@ietf.org" Subject: Re: [sipcore] Geolocation Call 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: Sat, 19 Feb 2011 00:19:09 -0000 James, I think your enumeration of cases is correct, but I find Adam's two paragraphs say the same thing in a way that is more sparing of the reader's time and effort. Thanks, Paul On 2/16/2011 6:46 PM, James M. Polk wrote: > At 05:02 PM 2/16/2011, Adam Roach wrote: >> [as chair] >> >> This appears to mostly come down to what intermediaries can do when no >> "Location-Routing" field is present. What I think I've heard everyone >> agree to in this thread is: >> >> If an intermediary inserts location into a SIP message and finds no >> "Location-Routing" header field, it may insert its own, with either >> "yes" or "no," according to its local policy. As a corollary; if a >> client doesn't insert a location but wants to suppress intermediaries >> from reading one that may be inserted later, then it explicitly adds a >> "Location-Routing: no" field. >> >> If an intermediary finds a SIP message with a "Location" field but no >> "Location-Routing" field, it may not dereference the location. >> >> Does that accurately summarize everyone's position? > > Adam (and all) > > To answer your question above - I think you have it right. I think the > only real play (or uncertainty) is when there is no Geolocation header > field, and what to do when there is one of the three possibilities for > the Geolocation-Routing. > > With that in mind, I have tentatively added a table in -06 of the 12 > possibilities I can think of for the combinations of Geolocation and > Geolocation-Routing header fields, focusing on a Geolocation-Routing > "=no", "=yes", and when no Gelocation-Routing header field is present > (with or without a Geolocation header field). I've come up with the > following - that only Jon has seen so far. > > I'd like to get feedback on this > > - have I got everything I need in the table? > - did I miss anything? > - have I gotten anything wrong in the table? > - should I expand what I say in the Geolocation-Routing column? > > and finally: > - should this table be included in -06? > > Here's the table as it currently is in the rough draft of -06: > " > Based on the above, the following table explains the 12 known > combinations of Geo-based header fields. > > Geo-based header combinations Geolocation-Routing > ---------------------------------- ------------------- > a single locationValue in a single Implicitly set to "=no" > Geolocation header instance within > the same SIP request, with no > Geolocation-Routing header present. > > more than one locationValue in a Implicitly set to "=no" > single Geolocation header instance > within the same SIP request, with no > Geolocation-Routing header present. > > more than one locationValue in more Implicitly set to "=no" > than one Geolocation header instance > within the same SIP request, with no > Geolocation-Routing header present. > > > a single locationValue in a single Explicitly set to "=no" > Geolocation header instance within > the same SIP request, with single > Geolocation-Routing header-value "=no". > > more than one locationValue in a Explicitly set to "=no" > single Geolocation header instance > within the same SIP request, with > single Geolocation-Routing header-value > "=no". > > more than one locationValue in more Explicitly set to "=no" > than one Geolocation header instance > within the same SIP request, with single > Geolocation-Routing header-value "=no". > > > a single locationValue in a single Explicitly set to "=yes" > Geolocation header instance within the > same SIP request, with single > Geolocation-Routing header-value "=yes". > > more than one locationValue in a Explicitly set to "=yes" > single Geolocation header instance > within the same SIP request, with > single Geolocation-Routing header-value > "=yes". > > more than one locationValue in more Explicitly set to "=yes" > than one Geolocation header instance > within the same SIP request, with single > Geolocation-Routing header-value "=yes". > > > no Geolocation header instance within Default Geolocation-Routing > a SIP request, with no is open and can be set by a > Geolocation-Routing header present. downstream entity or not at > all. > > no Geolocation header instance within Location viewing policy set > a SIP request, with single already such > Geolocation-Routing header-value "=no". Location viewing policy set > already such that no > intermediaries can view > location inserted > downstream. > > no Geolocation header instance within Location viewing policy set > a SIP request, with single already such that if > Geolocation-Routing header-value location is inserted > "=yes". downstream, intermediaries > can maintain an open viewing > of location policy or can > change policy to "=no" for > intermediaries further > downstream. > " > > James > > >> If so, I don't think we need a phone call tomorrow. If anyone >> disagrees, then I'd like to use the call tomorrow to wrestle this >> issue to the ground. >> >> /a >> >> On 2/15/11 8:09 PM, Paul Kyzivat wrote: >>> Thanks Jon. I never followed the details of all this stuff. >>> >>> But looking at -05, I think the existing text is consistent with what >>> you say. Of course it needs to be tweaked for the switch from >>> parameter to header field. But it does seem to be all about routing >>> of the sip, so I think the chosen name is ok. >>> >>> Thanks, >>> Paul >>> >>> On 2/15/2011 8:12 PM, Peterson, Jon wrote: >>>> >>>> How did we start down this rabbit hole? See RFC5606, especially >>>> section 3.5: >>>> >>>> When "Location-Routing-Allowed" is set to "Yes", the Rule Maker is >>>> indicating permission to use the included LI for location-based >>>> routing. When "Location-Routing-Allowed" is set to "No", the >>>> originator is indicating that this use is not permitted. "Location- >>>> Routing-Allowed" being set to "No" has no protocol-level mechanism >>>> for enforcement of this behavior; like the PIDF-LO>>> allowed> being set to "no", it is a way for the Rule Maker to express >>>> a preference to the SIP elements, which are LI recipients. It may, >>>> however, present a significant optimization. Where a location-by- >>>> reference is included with "Location-Routing-Allowed" set to "No", >>>> the SIP elements along the path know that they do not need to attempt >>>> to dereference the location information; this is significantly faster >>>> than attempting the dereference and being denied at the >>>> authentication stage. >>>> I wouldn't advise reading any more into this Geolocation-Routing >>>> header than the semantics of "location-routing-allowed" above. It is >>>> not intended to be some kind of security mechanism that would >>>> prevent a proxy from reading location information (we have other >>>> ways to do that). It does however resolve the ambiguity of SIP >>>> proxies "retransmitting" location information by merely forwarding >>>> requests, which in a strict reading of RFC4119 could easily be >>>> inferred. Setting a "routing-allowed" bit of some kind clarifies >>>> that the Ruler Maker doesn't mind retransmission (even when >>>> "retransmission-allowed" is set to "no" at a PIDF level) as long as >>>> it takes place as in the context of normal SIP operations, be it >>>> bare forwarding, retargeting or what have you. >>>> >>>> Jon Peterson >>>> NeuStar, Inc. >>>> >>>> On Feb 15, 2011, at 4:43 PM, Paul Kyzivat wrote: >>>> >>>>> trimming... >>>>> >>>>> On 2/15/2011 6:36 PM, James M. Polk wrote: >>>>> >>>>>>>> the existing "routing-allowed" header parameter is a bit of a >>>>>>>> mislabeling. It doesn't mean "routing" in the L3 or L7 sense of the >>>>>>>> word, it means "do I (the recipient of this SIP request have >>>>>>>> permission >>>>>>>> to view the locally available - or via a dereference transaction >>>>>>>> that I >>>>>>>> perform - geolocation information within this SIP request. If >>>>>>>> "routing-allowed" is set to "=yes", then I have permission to >>>>>>>> view it >>>>>>>> and to send the geolocation information to a 3rd party (as many >>>>>>>> as I >>>>>>>> want or as many times as I want). If "routing-allowed" is set to >>>>>>>> "=no", >>>>>>>> I do not have permission to view or dereference any geolocation >>>>>>>> information directly or indirectly related to this SIP request, >>>>>>>> *and* I >>>>>>>> do not have permission to transmit this location blob to a 3rd >>>>>>>> party at >>>>>>>> any time. >>>>>>> >>>>>>> Hmm. I thought it was a rule about whether the geoloc info could be >>>>>>> used to make retargeting decisions. >>>>>> >>>>>> correct, but that's secondary. The primary concern is whether or >>>>>> not SIP >>>>>> intermediaries, as LRs, are even allowed to view (or dereference) >>>>>> location in the message. If they can (i.e., "Geolocation-Routing: >>>>>> yes"), >>>>>> then they view this information to make routing decisions. If, OTOH, >>>>>> "Geolocation-Routing: no" and that intermediary believes (as much >>>>>> as a >>>>>> machine can 'believe') it has to be able to use the location >>>>>> information >>>>>> of the Target to make a proper routing decision, the intermediary >>>>>> must >>>>>> respond with a 424 (Bad Location Information) response including the >>>>>> following: >>>>>> >>>>>> Geolocation-Error: 202 "Permission to Route based on Location >>>>>> Information" >>>>>> >>>>>> This should bubble up to the UI to allow that Target's user to >>>>>> agree (or >>>>>> not) to reveal their location information to that (and all) SIP >>>>>> intermediaries for use in making good routing decisions of the >>>>>> subsequent SIP request. >>>>>> >>>>>> Does this make sense? >>>>>> >>>>>> So, the answer is yes, it has to do with the actual routing of the >>>>>> message, but that's a secondary concern to the revelation of the >>>>>> Target's location information (i.e., it's a little more >>>>>> complicated than >>>>>> you originally put it). >>>>>> >>>>>>> So, IIUC now, you are saying this has to do with routing of the >>>>>>> geoloc >>>>>>> info, not routing of the message containing it. Is that right? >>>>>> >>>>>> No, it's a viewability flag for the contained location, then with >>>>>> permission to view the Target's location information, it's making >>>>>> a good >>>>>> routing decision based on that location information. >>>>> >>>>> If so, then maybe the name of the header field used to transmit the >>>>> flag >>>>> should be renamed to something more suggestive of its meaning. I guess >>>>> that wouldn't be a radical last minute change, since this will be the >>>>> first time it has its own header field name. >>>>> >>>>> Thanks, >>>>> Paul >>>>> _______________________________________________ >>>>> sipcore mailing list >>>>> sipcore@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/sipcore >>>> >>> _______________________________________________ >>> sipcore mailing list >>> sipcore@ietf.org >>> https://www.ietf.org/mailman/listinfo/sipcore >> >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore > > From mary.ietf.barnes@gmail.com Tue Feb 22 12:20:53 2011 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 9710E3A68A3 for ; Tue, 22 Feb 2011 12:20:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.248 X-Spam-Level: X-Spam-Status: No, score=-103.248 tagged_above=-999 required=5 tests=[AWL=-0.250, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_LOW=-1, 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 brVR3JkyKjXB for ; Tue, 22 Feb 2011 12:20:47 -0800 (PST) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by core3.amsl.com (Postfix) with ESMTP id E73E33A67B0 for ; Tue, 22 Feb 2011 12:20:46 -0800 (PST) Received: by vws6 with SMTP id 6so1491892vws.31 for ; Tue, 22 Feb 2011 12:21:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=/LbKZufldCUEOI7zqqnMSy5w3nvWhje7ERa+rclfzCE=; b=DREBDorYnVKXvgGEHLjpyNaW6uw4chND2VuITuko0Rm2NmgWsWqQHEPnVTTu4By9hD 0Zpu+eIFqqExqCiFOzJJ66OFExZEbj4YzGykapvMS5uELw1fZggXhGVcOxTTZO0jD9Oy JEgIoJtBfMWEVmoIUafpBK+QFCGmsJL8ewmrs= 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=N5gPwgNOOe3yQamISTDdwhrCTHrfGNNbfUbLGm8Cvj6qo8DAi2KEGdxzQhYIzvvLCk RTb+lXoFFFdBo4eP6CIcfNTAF8IcCU3NJBcB6UlcbdAqMsUU0Z3GbKyt8KZF7UkDTla+ 80fKe/FWomYdANAXfTbwm+07Uzi8UN1ECxG38= MIME-Version: 1.0 Received: by 10.52.163.73 with SMTP id yg9mr4791440vdb.84.1298406090863; Tue, 22 Feb 2011 12:21:30 -0800 (PST) Received: by 10.52.162.202 with HTTP; Tue, 22 Feb 2011 12:21:30 -0800 (PST) In-Reply-To: References: Date: Tue, 22 Feb 2011 14:21:30 -0600 Message-ID: From: Mary Barnes To: "Elwell, John" Content-Type: multipart/alternative; boundary=bcaec53f90bdd1f9e7049ce4b908 Cc: SIPCORE Subject: Re: [sipcore] Part1: Some comments on draft-ietf-sipcore-rfc4244bis-03.txt - Including all hi-entries 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, 22 Feb 2011 20:20:53 -0000 --bcaec53f90bdd1f9e7049ce4b908 Content-Type: text/plain; charset=ISO-8859-1 Hi John, Responses inline below [MB3]. Mary. On Thu, Feb 17, 2011 at 3:09 PM, Elwell, John < john.elwell@siemens-enterprise.com> wrote: > > > > -----Original Message----- > > From: Mary Barnes [mailto:mary.ietf.barnes@gmail.com] > > Sent: 17 February 2011 18:32 > > To: Elwell, John > > Cc: SIPCORE > > Subject: Part1: Some comments on > > draft-ietf-sipcore-rfc4244bis-03.txt - Including all > > hi-entries in responses > > > > HI John, > > > > Responses inline below [MB2]. I'm separating the thread > > into two separate emails as I think there are two distinct > > issues within this thread, so it will be easier to track. > > > > Thanks, > > Mary. > > > > > > On Thu, Feb 17, 2011 at 2:20 AM, Elwell, John > > wrote: > > > > > > Mary, > > > > Thanks - see below: > > > > > > > -----Original Message----- > > > From: Mary Barnes [mailto:mary.ietf.barnes@gmail.com] > > > Sent: 16 February 2011 23:29 > > > To: Elwell, John > > > Cc: SIPCORE > > > Subject: Re: Some comments on > > draft-ietf-sipcore-rfc4244bis-03.txt > > > > > > Hi John, > > > > > > Thanks for the comments. Responses inline below [MB]. > > > > > > Mary. > > > > > > > > > On Wed, Feb 16, 2011 at 2:14 PM, Elwell, John > > > wrote: > > > > > > > > > Mary, > > > > > > Thanks for this major rewrite and addressing very many > > > earlier comments. I have some initial comments and also a > > > general comment. > > > > > > Comment 1: Request fails (4xx, say) and as a result a > > > proxy retargets. According to 7.1.2, the proxy is required to > > > include in the retargeted request all entries from received > > > responses so far, including, presumably, entries in the 4xx > > > response that leads to retargeting. However, if the request > > > does not contain Supported: histinfo, there will be no > > > entries in received responses. Therefore the final UAS will > > > not receive a complete set of entries. So we seem to have the > > > strange situation that the set of entries received by the UAS > > > is dependent on support of History-Info at the UAC. This > > > seems wrong. It seems to me that entries should always be > > > sent backwards, subject to privacy, and perhaps not on the > > > last hop if the UAC doesn't support it. > > > > > > > > > [MB] > > > > > > > [JRE] Your responses seems to be lost. > [JRE] I still don't see your response to this one. > [MB3] This goes back to core RFC 4244 behavior, although I think we might have broken that as RFC 4244 only limited the UAS from not including HI in responses rather than SIP intermediaries (although the behavior for an intermediary wasn't totally clear in RFC 4244). So, I can certainly see your point. And, making that change is consistent with other normative behavior that we have changed (i.e., SHOULD add -> MUST add, not removing headers for privacy, etc.). It shouldn't break any current implementations to make this change. [/MB3] > > > > Comment 2: Suppose a proxy forwards a request to two > > targets, one with entry index 1.1 and the other with entry > > index 1.2. A provisional or final response is received to the > > first forwarded request containing an additional entry with > > index 1.1.1. Then a 4xx response is received to the second > > request, causing the proxy to retarget, this time with an > > entry index 1.3. According to 7.1.2 step 1, that retargeted > > request should contain entries 1, 1.1.1, 1.2 and 1.3. Note > > that 1.1 is missing. I see nothing to require the inclusion > > of 1.1, yet step 1 of 7.1.2 seems to require inclusion of > > 1.1.1. Have I misinterpreted something? > > > > > > [MB] 1.1 should also be included. Perhaps the wording needs > > clarification, but the text is attempting to state that in > > cases where > > [JRE] Your responses seems to have been truncated. > > > [MB2] I'm not sure if that was me or the cat. The text is > attempting to state that all the hi-entries that were sent in > previous requests, along with all the hi-entries in responses > to those requests is included when the request is again > retargeted. But, I can see that the current wording could > be read that only the hi-entries in the original request > versus the original request + any other requests for which > responses have been received, as well as the hi-entries > contained in all responses. However, I had thought the > qualification that it states "in the original request that > received the error response", so perhaps just removing the > word "original" will suffice? [/MB2] > [JRE] I am still confused by your explanation. Let me put the question a > different way: > When I fork a request to several different targets, and when one of those > branches returns a response which leads me to retarget, what is included in > the retargeted request? > 1. Clearly all entries received from upstream. > 2. Clearly a new entry for the new target. > 3. Clearly the entry for the request whose response caused me to retarget, > and any additional entries in that response. > 4. Do I include entries for other requests on other branches that have > responded finally, and any additional entries in those responses, even > though they have not led to retargeting? I think your intention is "yes". > 5. Do I include entries for other requests on other branches that have > responded provisionally, and any additional entries in those responses, even > though they have not led to retargeting? I think your intention is "yes", > but I am not certain (see also my comments further down concerning Reason > header field - an answer of "no" might make more sense). > 6. Do I include entries for other requests on other branches that have not > yet responded? I think your intention is "no". > > Please confirm my assumptions above. Depending on that we can try to > address the wording, but I am not sure just deleting "original" from the > previous text really helps. > [MB3] Yes - the intent is exactly as you state above. [/MB3] > > > > Comment 3: In 7.2 it states: > > "...MUST forward captured History-Info in > > subsequent, provisional, and final responses to the > > request sent by > > the ultimate UAS (see Section 6.2)..." > > When a proxy forwards a provisional response, how does > > it know that this is from the ultimate UAS? This can only be > > known when the first 2xx arrives. In fact the term "ultimate > > UAS" is also problematic because how does a proxy know that a > > response has come from a UAS, as opposed to a proxy? > > > > > > [MB] It doesn't know that it's the ultimate UAS, so=o we > > should remove that phrase. It's attempting to highlight that > > all the information is sent in the responses, but that's > > really covered elsewhere. [/MB] > > [JRE] It does seem to make sense to simplify it so that > you send all information in all provisional or final > responses (except 100). Just an example to help confirm > whether this simple rule makes sense: > A proxy forks, sending requests with indices 1.1, 1.2 > and 1.3. Then the 1.3 branch sends a response (provisional, > final) containing additional entry 1.3.1. In this case the > response that the proxy sends upstream would contain 1, 1.1, > 1.2, 1.3 and 1.3.1 - correct? So even though the 1.1 and 1.2 > branches have not responded, they are included in the > upstream response? > > > > [MB2] The current approach is consistent with RFC 4244 > whereby only the hi-entries for requests for which responses > have been received are included in the upstream response. > [JRE] So you are saying that in my example above, indices 1.1 and 1.2 would > not be sent upstream, because they have not responded? I am not asking for > an explanation of how we got there - just asking what the model is intended > to be. > [MB3] Correct.[/MB3] > > > Again, it's hard for me to totally recall the logic, but I > > think it was because at that point in time, you don't know > > what will happen to that request - i.e., it's more misleading > > than helpful. We'd have to consider whether it would cause > > an issue with backwards compatibility if we change this now. > > IMHO, those entries only have value if you could accurately > > tag that they were outstanding or had timed out rather than > > infer that because they have no reason header means that the > > retargeting entity has not yet received a response. > [JRE] You have brought to my attention something I missed before. When you > put a Reason header field into an hi-entry, you now only convey that Reason > header field in that hi-entry in the retargeted request downstream, but also > in that same hi-entry when it gets sent upstream for any reason. So it > begins to make sense to me now why you would exclude entries for requests > that have not produced a response. However, this leads me to a couple of > further questions: > 1. According to 9.2, it is only failed requests that lead to retargeting > that cause a Reason header field to be placed in their hi-entry, not failed > requests that do not directly lead to retargeting. From what you say above, > it seems that any failed request (3xx, 4xx, 5xx, 6xx) should cause a Reason > header field to be placed into its hi-entry, even if that request does not > lead to retargeting. [MB3] That is the intent - the Reason should be reflecting why the request did not successfully terminate at the target (and thus why the request might be retargeted or a response generated). That all said, I think we need more text around this as adding the Reason to the hi-entry is described entirely in the context of retargeting and not specifically around sending HI in responses. So, I think we need to add some more text to the definition of Reason. And, I think we need to ensure that when we are describing the Reason header that we also include the case in which the URI that is being retargeted isn't the one with which the Reason is being associated, as well as in cases where the Request was unsuccessful and a response is generated.[/MB3] 2. What about requests that so far have only produced a provisional response and have not been the cause of retargeting. Does that 1xx response code get put in the hi-entry as a Reason header field, and are those entries included in any upstream responses or retargeted requests that might be sent before the branch concerned issues a final response? [MB3] Yes, per my response above. [/MB3] > > > Also, per > > the comment above you would also have an hi-entry with an > > index of 1.1.1 and that hi-entry would have a Reason header > > field "escaped" in the hi-targeted-to-uri. Whereas, neither > > the 1.2 or 1.3.1 hi-entry would have a Reason header field in > > the hi-targeted-to-uri. I don't see that to cause so much > > confusion as there might be if it was 1.1., 1.2 and 1.3 > > requests had been issued at the same time and the only > > response comes from 1.2, which has an hi-entry of 1.2.1. > > Thus, the last hi-entry (i.e., 1.3) in the response isn't one > > for which the request has received a response. [/MB2] > [JRE] I am lost on this one - I don't see the relevance of 1.1.1, which was > not in my example. But anyway, if you answer the questions above, it should > help. > [MB3] You had a 1.1.1 in your example under Comment 2. Per my responses above, I was highlighting that only the hi-entries for which responses have been received are added (i.e., I changed your example such that 1.3 didn't have a response and thus was trying to highlight that it would be confusing to have a 1.3 entry since you really don't know what is going to happen with that branch (i.e., it's not yet "complete"). [/MB3] > > John --bcaec53f90bdd1f9e7049ce4b908 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi John,
=A0
Responses inline below [MB3].
=A0
Mary.

On Thu, Feb 17, 2011 at 3:09 PM, Elwell, John <j= ohn.elwell@siemens-enterprise.com> wrote:


> -----Original Message-----
> From: Mar= y Barnes [mailto:mary.ietf.ba= rnes@gmail.com]
> Sent: 17 February 2011 18:32
> To: Elwell, Joh= n
> Cc: SIPCORE
> Subject: Part1: Some comments on
> draft-ietf-= sipcore-rfc4244bis-03.txt - Including all
> hi-entries in responses>
> HI John,
>
> Responses inline below [MB2]. =A0 I= 'm separating the thread
> into two separate emails as I think there are two distinct
> iss= ues within this thread, so it will be easier to track.
>
> Than= ks,
> Mary.
>
>
> On Thu, Feb 17, 2011 at 2:20 AM, = Elwell, John
> <john.elwell@= siemens-enterprise.com> wrote:
>
>
> =A0 =A0 =A0 M= ary,
>
> =A0 =A0 =A0 Thanks - see below:
>
>
>= ; =A0 =A0 =A0 > -----Original Message-----
> =A0 =A0 =A0 > From: Mary Barnes [mailto:mary.ietf.barnes@gmail.com]
> =A0 =A0 =A0 >= Sent: 16 February 2011 23:29
> =A0 =A0 =A0 > To: Elwell, John
= > =A0 =A0 =A0 > Cc: SIPCORE
> =A0 =A0 =A0 > Subject: Re: Some comments on
> draft-ietf-sipc= ore-rfc4244bis-03.txt
> =A0 =A0 =A0 >
> =A0 =A0 =A0 > Hi = John,
> =A0 =A0 =A0 >
> =A0 =A0 =A0 > Thanks for the comm= ents. Responses inline below [MB].
> =A0 =A0 =A0 >
> =A0 =A0 =A0 > Mary.
> =A0 =A0 =A0 &g= t;
> =A0 =A0 =A0 >
> =A0 =A0 =A0 > On Wed, Feb 16, 2011 a= t 2:14 PM, Elwell, John
> =A0 =A0 =A0 > <john.elwell@siemens-enterprise.com> = wrote:
> =A0 =A0 =A0 >
> =A0 =A0 =A0 >
> =A0 =A0 =A0 > =A0= =A0 =A0 Mary,
> =A0 =A0 =A0 >
> =A0 =A0 =A0 > =A0 =A0 = =A0 Thanks for this major rewrite and addressing very many
> =A0 =A0 = =A0 > earlier comments. I have some initial comments and also a
> =A0 =A0 =A0 > general comment.
> =A0 =A0 =A0 >
> =A0= =A0 =A0 > =A0 =A0 =A0 Comment 1: Request fails (4xx, say) and as a resu= lt a
> =A0 =A0 =A0 > proxy retargets. According to 7.1.2, the prox= y is required to
> =A0 =A0 =A0 > include in the retargeted request= all entries from received
> =A0 =A0 =A0 > responses so far, including, presumably, entries in t= he 4xx
> =A0 =A0 =A0 > response that leads to retargeting. However= , if the request
> =A0 =A0 =A0 > does not contain Supported: histi= nfo, there will be no
> =A0 =A0 =A0 > entries in received responses. Therefore the final UA= S will
> =A0 =A0 =A0 > not receive a complete set of entries. So w= e seem to have the
> =A0 =A0 =A0 > strange situation that the set = of entries received by the UAS
> =A0 =A0 =A0 > is dependent on support of History-Info at the UAC. T= his
> =A0 =A0 =A0 > seems wrong. It seems to me that entries shoul= d always be
> =A0 =A0 =A0 > sent backwards, subject to privacy, an= d perhaps not on the
> =A0 =A0 =A0 > last hop if the UAC doesn't support it.
> = =A0 =A0 =A0 >
> =A0 =A0 =A0 >
> =A0 =A0 =A0 > =A0[MB]<= br>> =A0 =A0 =A0 >
>
> =A0 =A0 =A0 [JRE] Your responses s= eems to be lost.
[JRE] I still don't see your response t= o this one.
[MB3]=A0This goes back to core RFC 4244 behavior, although I think we = might have broken that as RFC 4244 only limited the UAS from not including = HI in responses=A0rather than SIP intermediaries (although=A0the behavior f= or an intermediary wasn't totally clear in RFC 4244). =A0 So,=A0I can c= ertainly see your point.=A0=A0And, making that change is consistent with ot= her normative behavior that we have changed (i.e., SHOULD add -> MUST ad= d, not removing headers for privacy, etc.).=A0 It=A0shouldn't break any= current implementations to make this change.=A0 [/MB3]
> =A0 =A0 =A0 >
> =A0 =A0 =A0 > =A0 =A0 =A0 Comment 2: = Suppose a proxy forwards a request to two
> =A0 =A0 =A0 > targets,= one with entry index 1.1 and the other with entry
> =A0 =A0 =A0 >= index 1.2. A provisional or final response is received to the
> =A0 =A0 =A0 > first forwarded request containing an additional entr= y with
> =A0 =A0 =A0 > index 1.1.1. Then a 4xx response is receive= d to the second
> =A0 =A0 =A0 > request, causing the proxy to reta= rget, this time with an
> =A0 =A0 =A0 > entry index 1.3. According to 7.1.2 step 1, that reta= rgeted
> =A0 =A0 =A0 > request should contain entries 1, 1.1.1, 1.= 2 and 1.3. Note
> =A0 =A0 =A0 > that 1.1 is missing. I see nothing= to require the inclusion
> =A0 =A0 =A0 > of 1.1, yet step 1 of 7.1.2 seems to require inclusio= n of
> =A0 =A0 =A0 > 1.1.1. Have I misinterpreted something?
&g= t; =A0 =A0 =A0 >
> =A0 =A0 =A0 >
> =A0 =A0 =A0 > [MB] = 1.1 should also be included. Perhaps the wording needs
> =A0 =A0 =A0 > clarification, but the text is attempting to state th= at in
> =A0 =A0 =A0 > cases where
>
> =A0 =A0 =A0 [JRE= ] Your responses seems to have been truncated.
>
>
> [MB2= ] I'm not sure if that was me or the cat. =A0 =A0The text is
> attempting to state that all the hi-entries that were sent in
> = previous requests, along with all the hi-entries in responses
> to th= ose requests is included when the request is again
> retargeted. =A0 = But, I can see that the current wording could
> be read that only the hi-entries in the original request
> versu= s the original request + any other requests for which
> responses hav= e been received, as well as the hi-entries
> contained in all respons= es. =A0However, I had thought the
> qualification that it states "in the original request that
>= ; received the error response", so perhaps just removing the
> w= ord "original" will suffice? [/MB2]
[JRE] I am still confused by you= r explanation. Let me put the question a different way:
When I fork a re= quest to several different targets, and when one of those branches returns = a response which leads me to retarget, what is included in the retargeted r= equest?
1. Clearly all entries received from upstream.
2. Clearly a new entry fo= r the new target.
3. Clearly the entry for the request whose response ca= used me to retarget, and any additional entries in that response.
4. Do = I include entries for other requests on other branches that have responded = finally, and any additional entries in those responses, even though they ha= ve not led to retargeting? I think your intention is "yes".
5. Do I include entries for other requests on other branches that have resp= onded provisionally, and any additional entries in those responses, even th= ough they have not led to retargeting? I think your intention is "yes&= quot;, but I am not certain (see also my comments further down concerning R= eason header field - an answer of "no" might make more sense). 6. Do I include entries for other requests on other branches that have not = yet responded? I think your intention is "no".

Please conf= irm my assumptions above. Depending on that we can try to address the wordi= ng, but I am not sure just deleting "original" from the previous = text really helps.
[MB3] Yes - the intent is exactly as you state above. [/MB3]

&g= t; =A0 =A0 =A0 >
> =A0 =A0 =A0 > =A0 =A0 =A0 Comment 3: In 7.2 = it states:
> =A0 =A0 =A0 > =A0 =A0 =A0 "...MUST forward captu= red History-Info in
> =A0 =A0 =A0 > =A0 =A0 =A0 =A0 subsequent, pr= ovisional, and final responses to the
> =A0 =A0 =A0 > request sent by
> =A0 =A0 =A0 > =A0 =A0 =A0 = =A0 the ultimate UAS (see Section 6.2)..."
> =A0 =A0 =A0 > = =A0 =A0 =A0 When a proxy forwards a provisional response, how does
> = =A0 =A0 =A0 > it know that this is from the ultimate UAS? This can only = be
> =A0 =A0 =A0 > known when the first 2xx arrives. In fact the term &q= uot;ultimate
> =A0 =A0 =A0 > UAS" is also problematic because= how does a proxy know that a
> =A0 =A0 =A0 > response has come fr= om a UAS, as opposed to a proxy?
> =A0 =A0 =A0 >
> =A0 =A0 =A0 >
> =A0 =A0 =A0 > [MB= ] It doesn't know that it's the ultimate UAS, so=3Do we
> =A0= =A0 =A0 > should remove that phrase. =A0It's attempting to highligh= t that
> =A0 =A0 =A0 > all the information is sent in the response= s, but that's
> =A0 =A0 =A0 > really covered elsewhere. [/MB]
>
> =A0 = =A0 =A0 [JRE] It does seem to make sense to simplify it so that
> you= send all information in all provisional or final
> responses (except= 100). Just an example to help confirm
> whether this simple rule makes sense:
> =A0 =A0 =A0 A proxy fork= s, sending requests with indices 1.1, 1.2
> and 1.3. Then the 1.3 bra= nch sends a response (provisional,
> final) containing additional ent= ry 1.3.1. In this case the
> response that the proxy sends upstream would contain 1, 1.1,
> 1= .2, 1.3 and 1.3.1 - correct? So even though the 1.1 and 1.2
> branche= s have not responded, they are included in the
> upstream response? >
>
>
> [MB2] The current approach is consistent with = RFC 4244
> whereby only the hi-entries for requests for which respons= es
> have been received are included in the upstream response.
[JRE] So you are saying that in = my example above, indices 1.1 and 1.2 would not be sent upstream, because t= hey have not responded? I am not asking for an explanation of how we got th= ere - just asking what the model is intended to be.
[MB3] Correct.[/MB3]

> Again, it's hard for me to totally recall th= e logic, but I
> think it was because at that point in time, you don&= #39;t know
> what will happen to that request - i.e., it's more m= isleading
> than helpful. =A0 =A0We'd have to consider whether it would cause<= br>> an issue with backwards compatibility if we change this now.
>= ; IMHO, those entries only have value if you could accurately
> tag t= hat they were outstanding or had timed out rather than
> infer that because they have no reason header means that the
> r= etargeting entity has not yet received a response.
[JRE] You have = brought to my attention something I missed before. When you put a Reason he= ader field into an hi-entry, you now only convey that Reason header field i= n that hi-entry in the retargeted request downstream, but also in that same= hi-entry when it gets sent upstream for any reason. So it begins to make s= ense to me now why you would exclude entries for requests that have not pro= duced a response. However, this leads me to a couple of further questions:<= br> 1. According to 9.2, it is only failed requests that lead to retargeting th= at cause a Reason header field to be placed in their hi-entry, not failed r= equests that do not directly lead to retargeting. From what you say above, = it seems that any failed request (3xx, 4xx, 5xx, 6xx) should cause a Reason= header field to be placed into its hi-entry, even if that request does not= lead to retargeting.
[MB3]=A0 That is the intent - the Reason should be reflecting why the = request did not successfully terminate at the target (and thus why the requ= est might=A0be retargeted or a response generated). =A0=A0 That all said, I= think we need more text around this as adding the Reason to the hi-entry i= s described entirely in the context of retargeting and not specifically aro= und sending HI in responses.=A0 So, I think we need to add some more text t= o the definition of Reason.=A0 And, I think we need to ensure that when we = are describing the Reason header that we also include the case in which the= URI that is being retargeted isn't the one with which the Reason is be= ing associated, as well as in cases where the Request was unsuccessful and = a response is generated.[/MB3]
=A0
2. What about requests that so far have only produced a provisional re= sponse and have not been the cause of retargeting. Does that 1xx response c= ode get put in the hi-entry as a Reason header field, and are those entries= included in any upstream responses or retargeted requests that might be se= nt before the branch concerned issues a final response?
[MB3] Yes, per my response above. [/MB3]

> Also, per
> the comment above you would al= so have an hi-entry with an
> index of =A01.1.1 and that hi-entry wou= ld have a Reason header
> field "escaped" in the hi-targete= d-to-uri. =A0Whereas, neither
> the 1.2 or 1.3.1 hi-entry would have a Reason header field in
> = the hi-targeted-to-uri. I don't see that to cause so much
> confu= sion as there might be if it was 1.1., 1.2 and 1.3
> requests had bee= n issued at the same time and the only
> response comes from 1.2, which has an hi-entry of 1.2.1.
> Thus,= the last hi-entry (i.e., 1.3) in the response isn't one
> for wh= ich the request has received a response. [/MB2]
[JRE] I am lost on= this one - I don't see the relevance of 1.1.1, which was not in my exa= mple. But anyway, if you answer the questions above, it should help.
[MB3]=A0 You had a=A01.1.1 in your example under Comment 2.=A0=A0=A0Pe= r my responses above, I was highlighting that only the hi-entries for which= responses have been received are added (i.e., I changed your example such = that 1.3 didn't have a response and thus was trying to highlight that i= t would be confusing to have a 1.3 entry since you really don't know wh= at is going to happen with that branch (i.e., it's not yet "comple= te"). [/MB3]

John=

--bcaec53f90bdd1f9e7049ce4b908-- From pkyzivat@cisco.com Tue Feb 22 13:13:52 2011 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 77E0F3A697A for ; Tue, 22 Feb 2011 13:13:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.299 X-Spam-Level: X-Spam-Status: No, score=-110.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_HI=-8, 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 DbrsDloUxUCo for ; Tue, 22 Feb 2011 13:13:50 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 3048E3A6916 for ; Tue, 22 Feb 2011 13:13:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pkyzivat@cisco.com; l=14515; q=dns/txt; s=iport; t=1298409275; x=1299618875; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=GM10Io4uc91Pu4gIXjHk5tZaQuKQg8GZcC1/GagFnns=; b=N9Gi3C5MiFEb2rp7/CzQ801zqR3A+8CxD84PI3SWOWxe84J19tSKqa/d alxRpgu0owao7tPTMwthRuh0ymhY1Dis8qamBym+BfP43f8G+SA58QRJZ 3IxdVOIsc8dGCbox0UH3CxlPV4d4sedi6+4UgdA6CgbZAA5TPgTiEdZ2Y s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAPG1Y01AZnwM/2dsb2JhbACmI3OiHJtWhV4EhQ2HBoM7gxA X-IronPort-AV: E=Sophos;i="4.62,207,1297036800"; d="scan'208";a="218744993" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 22 Feb 2011 21:14:30 +0000 Received: from [161.44.174.114] (dhcp-161-44-174-114.cisco.com [161.44.174.114]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id p1MLEUQO018833 for ; Tue, 22 Feb 2011 21:14:30 GMT Message-ID: <4D642735.30401@cisco.com> Date: Tue, 22 Feb 2011 16:14:29 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: sipcore@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [sipcore] Part1: Some comments on draft-ietf-sipcore-rfc4244bis-03.txt - Including all hi-entries 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, 22 Feb 2011 21:13:52 -0000 (as individual) I have been "loosely" following this. What I am taking away from this discussion is that the bookkeeping and header flogging necessary to properly implement this, and then to interpret the results, are so extreme that its unlikely that it will be implemented correctly, if anyone even bothers to try. What I fear most is that implementors will conclude that it is too hard to get right, but that they are required to support it, and so they will implement some approximation/subset/hack version of it. In some respects this is like offer/answer, where there were a lot of loose ends, and closing them has brought a lot of complexity to something that was previously considered relatively simple. But o/a is a lot more important to sip than H-I is, so people are (I assume) more motivated. And I expect that nobody has tried to implement *all* of o/a as it is currently understood. I don't have an answer here, just a concern. Maybe if I studied it all in excruciating detail, as if I were implementing it, I would feel better. But I doubt it. Thanks, Paul On 2/22/2011 3:21 PM, Mary Barnes wrote: > Hi John, > Responses inline below [MB3]. > Mary. > > On Thu, Feb 17, 2011 at 3:09 PM, Elwell, John > > wrote: > > > > > -----Original Message----- > > From: Mary Barnes [mailto:mary.ietf.barnes@gmail.com > ] > > Sent: 17 February 2011 18:32 > > To: Elwell, John > > Cc: SIPCORE > > Subject: Part1: Some comments on > > draft-ietf-sipcore-rfc4244bis-03.txt - Including all > > hi-entries in responses > > > > HI John, > > > > Responses inline below [MB2]. I'm separating the thread > > into two separate emails as I think there are two distinct > > issues within this thread, so it will be easier to track. > > > > Thanks, > > Mary. > > > > > > On Thu, Feb 17, 2011 at 2:20 AM, Elwell, John > > > wrote: > > > > > > Mary, > > > > Thanks - see below: > > > > > > > -----Original Message----- > > > From: Mary Barnes [mailto:mary.ietf.barnes@gmail.com > ] > > > Sent: 16 February 2011 23:29 > > > To: Elwell, John > > > Cc: SIPCORE > > > Subject: Re: Some comments on > > draft-ietf-sipcore-rfc4244bis-03.txt > > > > > > Hi John, > > > > > > Thanks for the comments. Responses inline below [MB]. > > > > > > Mary. > > > > > > > > > On Wed, Feb 16, 2011 at 2:14 PM, Elwell, John > > > > wrote: > > > > > > > > > Mary, > > > > > > Thanks for this major rewrite and addressing very many > > > earlier comments. I have some initial comments and also a > > > general comment. > > > > > > Comment 1: Request fails (4xx, say) and as a result a > > > proxy retargets. According to 7.1.2, the proxy is required to > > > include in the retargeted request all entries from received > > > responses so far, including, presumably, entries in the 4xx > > > response that leads to retargeting. However, if the request > > > does not contain Supported: histinfo, there will be no > > > entries in received responses. Therefore the final UAS will > > > not receive a complete set of entries. So we seem to have the > > > strange situation that the set of entries received by the UAS > > > is dependent on support of History-Info at the UAC. This > > > seems wrong. It seems to me that entries should always be > > > sent backwards, subject to privacy, and perhaps not on the > > > last hop if the UAC doesn't support it. > > > > > > > > > [MB] > > > > > > > [JRE] Your responses seems to be lost. > [JRE] I still don't see your response to this one. > > [MB3] This goes back to core RFC 4244 behavior, although I think we > might have broken that as RFC 4244 only limited the UAS from not > including HI in responses rather than SIP intermediaries (although the > behavior for an intermediary wasn't totally clear in RFC 4244). So, I > can certainly see your point. And, making that change is consistent > with other normative behavior that we have changed (i.e., SHOULD add -> > MUST add, not removing headers for privacy, etc.). It shouldn't break > any current implementations to make this change. [/MB3] > > > > > > Comment 2: Suppose a proxy forwards a request to two > > > targets, one with entry index 1.1 and the other with entry > > > index 1.2. A provisional or final response is received to the > > > first forwarded request containing an additional entry with > > > index 1.1.1. Then a 4xx response is received to the second > > > request, causing the proxy to retarget, this time with an > > > entry index 1.3. According to 7.1.2 step 1, that retargeted > > > request should contain entries 1, 1.1.1, 1.2 and 1.3. Note > > > that 1.1 is missing. I see nothing to require the inclusion > > > of 1.1, yet step 1 of 7.1.2 seems to require inclusion of > > > 1.1.1. Have I misinterpreted something? > > > > > > > > > [MB] 1.1 should also be included. Perhaps the wording needs > > > clarification, but the text is attempting to state that in > > > cases where > > > > [JRE] Your responses seems to have been truncated. > > > > > > [MB2] I'm not sure if that was me or the cat. The text is > > attempting to state that all the hi-entries that were sent in > > previous requests, along with all the hi-entries in responses > > to those requests is included when the request is again > > retargeted. But, I can see that the current wording could > > be read that only the hi-entries in the original request > > versus the original request + any other requests for which > > responses have been received, as well as the hi-entries > > contained in all responses. However, I had thought the > > qualification that it states "in the original request that > > received the error response", so perhaps just removing the > > word "original" will suffice? [/MB2] > > [JRE] I am still confused by your explanation. Let me put the > question a different way: > When I fork a request to several different targets, and when one of > those branches returns a response which leads me to retarget, what > is included in the retargeted request? > 1. Clearly all entries received from upstream. > 2. Clearly a new entry for the new target. > 3. Clearly the entry for the request whose response caused me to > retarget, and any additional entries in that response. > 4. Do I include entries for other requests on other branches that > have responded finally, and any additional entries in those > responses, even though they have not led to retargeting? I think > your intention is "yes". > 5. Do I include entries for other requests on other branches that > have responded provisionally, and any additional entries in those > responses, even though they have not led to retargeting? I think > your intention is "yes", but I am not certain (see also my comments > further down concerning Reason header field - an answer of "no" > might make more sense). > 6. Do I include entries for other requests on other branches that > have not yet responded? I think your intention is "no". > > Please confirm my assumptions above. Depending on that we can try to > address the wording, but I am not sure just deleting "original" from > the previous text really helps. > > [MB3] Yes - the intent is exactly as you state above. [/MB3] > > > > > > > Comment 3: In 7.2 it states: > > > "...MUST forward captured History-Info in > > > subsequent, provisional, and final responses to the > > > request sent by > > > the ultimate UAS (see Section 6.2)..." > > > When a proxy forwards a provisional response, how does > > > it know that this is from the ultimate UAS? This can only be > > > known when the first 2xx arrives. In fact the term "ultimate > > > UAS" is also problematic because how does a proxy know that a > > > response has come from a UAS, as opposed to a proxy? > > > > > > > > > [MB] It doesn't know that it's the ultimate UAS, so=o we > > > should remove that phrase. It's attempting to highlight that > > > all the information is sent in the responses, but that's > > > really covered elsewhere. [/MB] > > > > [JRE] It does seem to make sense to simplify it so that > > you send all information in all provisional or final > > responses (except 100). Just an example to help confirm > > whether this simple rule makes sense: > > A proxy forks, sending requests with indices 1.1, 1.2 > > and 1.3. Then the 1.3 branch sends a response (provisional, > > final) containing additional entry 1.3.1. In this case the > > response that the proxy sends upstream would contain 1, 1.1, > > 1.2, 1.3 and 1.3.1 - correct? So even though the 1.1 and 1.2 > > branches have not responded, they are included in the > > upstream response? > > > > > > > > [MB2] The current approach is consistent with RFC 4244 > > whereby only the hi-entries for requests for which responses > > have been received are included in the upstream response. > > [JRE] So you are saying that in my example above, indices 1.1 and > 1.2 would not be sent upstream, because they have not responded? I > am not asking for an explanation of how we got there - just asking > what the model is intended to be. > > [MB3] Correct.[/MB3] > > > > Again, it's hard for me to totally recall the logic, but I > > think it was because at that point in time, you don't know > > what will happen to that request - i.e., it's more misleading > > than helpful. We'd have to consider whether it would cause > > an issue with backwards compatibility if we change this now. > > IMHO, those entries only have value if you could accurately > > tag that they were outstanding or had timed out rather than > > infer that because they have no reason header means that the > > retargeting entity has not yet received a response. > [JRE] You have brought to my attention something I missed before. > When you put a Reason header field into an hi-entry, you now only > convey that Reason header field in that hi-entry in the retargeted > request downstream, but also in that same hi-entry when it gets sent > upstream for any reason. So it begins to make sense to me now why > you would exclude entries for requests that have not produced a > response. However, this leads me to a couple of further questions: > 1. According to 9.2, it is only failed requests that lead to > retargeting that cause a Reason header field to be placed in their > hi-entry, not failed requests that do not directly lead to > retargeting. From what you say above, it seems that any failed > request (3xx, 4xx, 5xx, 6xx) should cause a Reason header field to > be placed into its hi-entry, even if that request does not lead to > retargeting. > > [MB3] That is the intent - the Reason should be reflecting why the > request did not successfully terminate at the target (and thus why the > request might be retargeted or a response generated). That all said, > I think we need more text around this as adding the Reason to the > hi-entry is described entirely in the context of retargeting and not > specifically around sending HI in responses. So, I think we need to add > some more text to the definition of Reason. And, I think we need to > ensure that when we are describing the Reason header that we also > include the case in which the URI that is being retargeted isn't the one > with which the Reason is being associated, as well as in cases where the > Request was unsuccessful and a response is generated.[/MB3] > 2. What about requests that so far have only produced a provisional > response and have not been the cause of retargeting. Does that 1xx > response code get put in the hi-entry as a Reason header field, and are > those entries included in any upstream responses or retargeted requests > that might be sent before the branch concerned issues a final response? > [MB3] Yes, per my response above. [/MB3] > > > > Also, per > > the comment above you would also have an hi-entry with an > > index of 1.1.1 and that hi-entry would have a Reason header > > field "escaped" in the hi-targeted-to-uri. Whereas, neither > > the 1.2 or 1.3.1 hi-entry would have a Reason header field in > > the hi-targeted-to-uri. I don't see that to cause so much > > confusion as there might be if it was 1.1., 1.2 and 1.3 > > requests had been issued at the same time and the only > > response comes from 1.2, which has an hi-entry of 1.2.1. > > Thus, the last hi-entry (i.e., 1.3) in the response isn't one > > for which the request has received a response. [/MB2] > [JRE] I am lost on this one - I don't see the relevance of 1.1.1, > which was not in my example. But anyway, if you answer the questions > above, it should help. > > [MB3] You had a 1.1.1 in your example under Comment 2. Per my > responses above, I was highlighting that only the hi-entries for which > responses have been received are added (i.e., I changed your example > such that 1.3 didn't have a response and thus was trying to highlight > that it would be confusing to have a 1.3 entry since you really don't > know what is going to happen with that branch (i.e., it's not yet > "complete"). [/MB3] > > > John > > > > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From mary.ietf.barnes@gmail.com Tue Feb 22 13:23:17 2011 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 06F263A6994 for ; Tue, 22 Feb 2011 13:23:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.229 X-Spam-Level: X-Spam-Status: No, score=-103.229 tagged_above=-999 required=5 tests=[AWL=-0.231, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_LOW=-1, 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 ea-a76sKHiy4 for ; Tue, 22 Feb 2011 13:23:14 -0800 (PST) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by core3.amsl.com (Postfix) with ESMTP id 0A79B3A698F for ; Tue, 22 Feb 2011 13:23:13 -0800 (PST) Received: by vws6 with SMTP id 6so1548401vws.31 for ; Tue, 22 Feb 2011 13:23:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=5wHyT3OPq5cBm4RoDjEub4kCQbQrqQWtxMP9DhbKtqI=; b=ShPdiOEZgTawQJ1bttYPe1tGMQISUmL806BHN2Hz6W7cNgp9pTAc0LpfB2EOJCqH7O p/dU8wOds9MoQjZO7TQIu5oJPSotGLV36xvFsBNCbfUieizA/gItSRLMjSjBeJQqsBK1 dpd3W2e5DFowZ+eI8WimjriyBLUrChsTB2638= 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=Xaz+Me2E9e5A/y2+T2CprV3JLDJnNCWm7SGcAXQErxexTikTZhWoEefDCRBpe/bcdQ Z1uPkQmpROzAGcamoWqR0wfnaa47CV5nfE3X4ucdacArfN+mQod4aY9Vn37peY8XpUO0 aKqlqGJKocqG+kqv9ZAxRjjImedOo4Tjhid7U= MIME-Version: 1.0 Received: by 10.52.167.42 with SMTP id zl10mr4860492vdb.204.1298409837959; Tue, 22 Feb 2011 13:23:57 -0800 (PST) Received: by 10.52.162.202 with HTTP; Tue, 22 Feb 2011 13:23:57 -0800 (PST) In-Reply-To: <4D642735.30401@cisco.com> References: <4D642735.30401@cisco.com> Date: Tue, 22 Feb 2011 15:23:57 -0600 Message-ID: From: Mary Barnes To: Paul Kyzivat Content-Type: multipart/alternative; boundary=bcaec53f943d2a1d04049ce599b0 Cc: sipcore@ietf.org Subject: Re: [sipcore] Part1: Some comments on draft-ietf-sipcore-rfc4244bis-03.txt - Including all hi-entries 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, 22 Feb 2011 21:23:17 -0000 --bcaec53f943d2a1d04049ce599b0 Content-Type: text/plain; charset=ISO-8859-1 The complexity of History-Info directly correlates with the complexity of SIP itself, so there's not much that can be simplified. The most complexity is introduced in cases of parallel forking, which introduces many loose ends as you note. If we weren't dealing with parallel forking, I think alot of the complexity is gone since the collection of the hi-entries happens in a logical, known order. In the case of parallel forking, the indexing is how the information can be logically sorted. As I said early on, I have worked on this way too long to see how things can be clarified. I believe the wording as the capturing of the entries is accurate (or nearly so), although it may not be in the most concise or comprehensible form. I would agree 100% that this document can not be understood if it is read through only once - as I noted in another thread, the layout of the material presents a chicken/egg situation. Also, I have to wonder if it wouldn't help to bring the detailed call flows back into this document? Regards, Mary. On Tue, Feb 22, 2011 at 3:14 PM, Paul Kyzivat wrote: > (as individual) > > I have been "loosely" following this. > > What I am taking away from this discussion is that the bookkeeping and > header flogging necessary to properly implement this, and then to interpret > the results, are so extreme that its unlikely that it will be implemented > correctly, if anyone even bothers to try. > > What I fear most is that implementors will conclude that it is too hard to > get right, but that they are required to support it, and so they will > implement some approximation/subset/hack version of it. > > In some respects this is like offer/answer, where there were a lot of loose > ends, and closing them has brought a lot of complexity to something that was > previously considered relatively simple. But o/a is a lot more important to > sip than H-I is, so people are (I assume) more motivated. And I expect that > nobody has tried to implement *all* of o/a as it is currently understood. > > I don't have an answer here, just a concern. Maybe if I studied it all in > excruciating detail, as if I were implementing it, I would feel better. But > I doubt it. > > Thanks, > Paul > > > On 2/22/2011 3:21 PM, Mary Barnes wrote: > >> Hi John, >> Responses inline below [MB3]. >> Mary. >> >> On Thu, Feb 17, 2011 at 3:09 PM, Elwell, John >> > > wrote: >> >> >> >> > -----Original Message----- >> > From: Mary Barnes [mailto:mary.ietf.barnes@gmail.com >> ] >> > Sent: 17 February 2011 18:32 >> > To: Elwell, John >> > Cc: SIPCORE >> > Subject: Part1: Some comments on >> > draft-ietf-sipcore-rfc4244bis-03.txt - Including all >> > hi-entries in responses >> > >> > HI John, >> > >> > Responses inline below [MB2]. I'm separating the thread >> > into two separate emails as I think there are two distinct >> > issues within this thread, so it will be easier to track. >> > >> > Thanks, >> > Mary. >> > >> > >> > On Thu, Feb 17, 2011 at 2:20 AM, Elwell, John >> > > > wrote: >> > >> > >> > Mary, >> > >> > Thanks - see below: >> > >> > >> > > -----Original Message----- >> > > From: Mary Barnes [mailto:mary.ietf.barnes@gmail.com >> ] >> > > Sent: 16 February 2011 23:29 >> > > To: Elwell, John >> > > Cc: SIPCORE >> > > Subject: Re: Some comments on >> > draft-ietf-sipcore-rfc4244bis-03.txt >> > > >> > > Hi John, >> > > >> > > Thanks for the comments. Responses inline below [MB]. >> > > >> > > Mary. >> > > >> > > >> > > On Wed, Feb 16, 2011 at 2:14 PM, Elwell, John >> > > > > wrote: >> > > >> > > >> > > Mary, >> > > >> > > Thanks for this major rewrite and addressing very many >> > > earlier comments. I have some initial comments and also a >> > > general comment. >> > > >> > > Comment 1: Request fails (4xx, say) and as a result a >> > > proxy retargets. According to 7.1.2, the proxy is required to >> > > include in the retargeted request all entries from received >> > > responses so far, including, presumably, entries in the 4xx >> > > response that leads to retargeting. However, if the request >> > > does not contain Supported: histinfo, there will be no >> > > entries in received responses. Therefore the final UAS will >> > > not receive a complete set of entries. So we seem to have the >> > > strange situation that the set of entries received by the UAS >> > > is dependent on support of History-Info at the UAC. This >> > > seems wrong. It seems to me that entries should always be >> > > sent backwards, subject to privacy, and perhaps not on the >> > > last hop if the UAC doesn't support it. >> > > >> > > >> > > [MB] >> > > >> > >> > [JRE] Your responses seems to be lost. >> [JRE] I still don't see your response to this one. >> >> [MB3] This goes back to core RFC 4244 behavior, although I think we >> might have broken that as RFC 4244 only limited the UAS from not >> including HI in responses rather than SIP intermediaries (although the >> behavior for an intermediary wasn't totally clear in RFC 4244). So, I >> can certainly see your point. And, making that change is consistent >> with other normative behavior that we have changed (i.e., SHOULD add -> >> MUST add, not removing headers for privacy, etc.). It shouldn't break >> any current implementations to make this change. [/MB3] >> > > >> > > Comment 2: Suppose a proxy forwards a request to two >> > > targets, one with entry index 1.1 and the other with entry >> > > index 1.2. A provisional or final response is received to the >> > > first forwarded request containing an additional entry with >> > > index 1.1.1. Then a 4xx response is received to the second >> > > request, causing the proxy to retarget, this time with an >> > > entry index 1.3. According to 7.1.2 step 1, that retargeted >> > > request should contain entries 1, 1.1.1, 1.2 and 1.3. Note >> > > that 1.1 is missing. I see nothing to require the inclusion >> > > of 1.1, yet step 1 of 7.1.2 seems to require inclusion of >> > > 1.1.1. Have I misinterpreted something? >> > > >> > > >> > > [MB] 1.1 should also be included. Perhaps the wording needs >> > > clarification, but the text is attempting to state that in >> > > cases where >> > >> > [JRE] Your responses seems to have been truncated. >> > >> > >> > [MB2] I'm not sure if that was me or the cat. The text is >> > attempting to state that all the hi-entries that were sent in >> > previous requests, along with all the hi-entries in responses >> > to those requests is included when the request is again >> > retargeted. But, I can see that the current wording could >> > be read that only the hi-entries in the original request >> > versus the original request + any other requests for which >> > responses have been received, as well as the hi-entries >> > contained in all responses. However, I had thought the >> > qualification that it states "in the original request that >> > received the error response", so perhaps just removing the >> > word "original" will suffice? [/MB2] >> >> [JRE] I am still confused by your explanation. Let me put the >> question a different way: >> When I fork a request to several different targets, and when one of >> those branches returns a response which leads me to retarget, what >> is included in the retargeted request? >> 1. Clearly all entries received from upstream. >> 2. Clearly a new entry for the new target. >> 3. Clearly the entry for the request whose response caused me to >> retarget, and any additional entries in that response. >> 4. Do I include entries for other requests on other branches that >> have responded finally, and any additional entries in those >> responses, even though they have not led to retargeting? I think >> your intention is "yes". >> 5. Do I include entries for other requests on other branches that >> have responded provisionally, and any additional entries in those >> responses, even though they have not led to retargeting? I think >> your intention is "yes", but I am not certain (see also my comments >> further down concerning Reason header field - an answer of "no" >> might make more sense). >> 6. Do I include entries for other requests on other branches that >> have not yet responded? I think your intention is "no". >> >> Please confirm my assumptions above. Depending on that we can try to >> address the wording, but I am not sure just deleting "original" from >> the previous text really helps. >> >> [MB3] Yes - the intent is exactly as you state above. [/MB3] >> >> > > >> > > Comment 3: In 7.2 it states: >> > > "...MUST forward captured History-Info in >> > > subsequent, provisional, and final responses to the >> > > request sent by >> > > the ultimate UAS (see Section 6.2)..." >> > > When a proxy forwards a provisional response, how does >> > > it know that this is from the ultimate UAS? This can only be >> > > known when the first 2xx arrives. In fact the term "ultimate >> > > UAS" is also problematic because how does a proxy know that a >> > > response has come from a UAS, as opposed to a proxy? >> > > >> > > >> > > [MB] It doesn't know that it's the ultimate UAS, so=o we >> > > should remove that phrase. It's attempting to highlight that >> > > all the information is sent in the responses, but that's >> > > really covered elsewhere. [/MB] >> > >> > [JRE] It does seem to make sense to simplify it so that >> > you send all information in all provisional or final >> > responses (except 100). Just an example to help confirm >> > whether this simple rule makes sense: >> > A proxy forks, sending requests with indices 1.1, 1.2 >> > and 1.3. Then the 1.3 branch sends a response (provisional, >> > final) containing additional entry 1.3.1. In this case the >> > response that the proxy sends upstream would contain 1, 1.1, >> > 1.2, 1.3 and 1.3.1 - correct? So even though the 1.1 and 1.2 >> > branches have not responded, they are included in the >> > upstream response? >> > >> > >> > >> > [MB2] The current approach is consistent with RFC 4244 >> > whereby only the hi-entries for requests for which responses >> > have been received are included in the upstream response. >> >> [JRE] So you are saying that in my example above, indices 1.1 and >> 1.2 would not be sent upstream, because they have not responded? I >> am not asking for an explanation of how we got there - just asking >> what the model is intended to be. >> >> [MB3] Correct.[/MB3] >> >> >> > Again, it's hard for me to totally recall the logic, but I >> > think it was because at that point in time, you don't know >> > what will happen to that request - i.e., it's more misleading >> > than helpful. We'd have to consider whether it would cause >> > an issue with backwards compatibility if we change this now. >> > IMHO, those entries only have value if you could accurately >> > tag that they were outstanding or had timed out rather than >> > infer that because they have no reason header means that the >> > retargeting entity has not yet received a response. >> [JRE] You have brought to my attention something I missed before. >> When you put a Reason header field into an hi-entry, you now only >> convey that Reason header field in that hi-entry in the retargeted >> request downstream, but also in that same hi-entry when it gets sent >> upstream for any reason. So it begins to make sense to me now why >> you would exclude entries for requests that have not produced a >> response. However, this leads me to a couple of further questions: >> 1. According to 9.2, it is only failed requests that lead to >> retargeting that cause a Reason header field to be placed in their >> hi-entry, not failed requests that do not directly lead to >> retargeting. From what you say above, it seems that any failed >> request (3xx, 4xx, 5xx, 6xx) should cause a Reason header field to >> be placed into its hi-entry, even if that request does not lead to >> retargeting. >> >> [MB3] That is the intent - the Reason should be reflecting why the >> request did not successfully terminate at the target (and thus why the >> request might be retargeted or a response generated). That all said, >> I think we need more text around this as adding the Reason to the >> hi-entry is described entirely in the context of retargeting and not >> specifically around sending HI in responses. So, I think we need to add >> some more text to the definition of Reason. And, I think we need to >> ensure that when we are describing the Reason header that we also >> include the case in which the URI that is being retargeted isn't the one >> with which the Reason is being associated, as well as in cases where the >> Request was unsuccessful and a response is generated.[/MB3] >> 2. What about requests that so far have only produced a provisional >> response and have not been the cause of retargeting. Does that 1xx >> response code get put in the hi-entry as a Reason header field, and are >> those entries included in any upstream responses or retargeted requests >> that might be sent before the branch concerned issues a final response? >> [MB3] Yes, per my response above. [/MB3] >> >> >> > Also, per >> > the comment above you would also have an hi-entry with an >> > index of 1.1.1 and that hi-entry would have a Reason header >> > field "escaped" in the hi-targeted-to-uri. Whereas, neither >> > the 1.2 or 1.3.1 hi-entry would have a Reason header field in >> > the hi-targeted-to-uri. I don't see that to cause so much >> > confusion as there might be if it was 1.1., 1.2 and 1.3 >> > requests had been issued at the same time and the only >> > response comes from 1.2, which has an hi-entry of 1.2.1. >> > Thus, the last hi-entry (i.e., 1.3) in the response isn't one >> > for which the request has received a response. [/MB2] >> [JRE] I am lost on this one - I don't see the relevance of 1.1.1, >> which was not in my example. But anyway, if you answer the questions >> above, it should help. >> >> [MB3] You had a 1.1.1 in your example under Comment 2. Per my >> responses above, I was highlighting that only the hi-entries for which >> responses have been received are added (i.e., I changed your example >> such that 1.3 didn't have a response and thus was trying to highlight >> that it would be confusing to have a 1.3 entry since you really don't >> know what is going to happen with that branch (i.e., it's not yet >> "complete"). [/MB3] >> >> >> 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 > --bcaec53f943d2a1d04049ce599b0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
The complexity of History-Info directly correlat= es with the complexity of SIP itself, so there's not much that can be s= implified.=A0 The most complexity is introduced in cases of parallel forkin= g, which introduces many loose ends as you note.=A0 If we weren't deali= ng with parallel forking, I think alot of the complexity is gone since the = collection of the hi-entries happens in a logical, known=A0order. In the ca= se of parallel forking, the indexing is how the information can be logicall= y sorted.=A0=A0
=A0
As I said early on, I have worked on this way to= o long to see how things can be clarified.=A0 I believe the wording as the = capturing of the entries is accurate (or nearly so), although it may not be= in the most concise or comprehensible form.=A0 I would agree 100% that thi= s document can not be understood if it is read through only once - as I not= ed in another thread, the layout of the material presents a chicken/egg sit= uation.=A0 Also, I have to wonder if it wouldn't help to bring the deta= iled call flows back into this document?
=A0
Regards,
Mary.
=A0
On Tue, Feb 22, 2011 at 3:14 PM, Paul Kyzivat <pkyzivat@cisco.co= m> wrote:
(as individual)

I have be= en "loosely" following this.

What I am taking away from th= is discussion is that the bookkeeping and header flogging necessary to prop= erly implement this, and then to interpret the results, are so extreme that= its unlikely that it will be implemented correctly, if anyone even bothers= to try.

What I fear most is that implementors will conclude that it is too hard= to get right, but that they are required to support it, and so they will i= mplement some approximation/subset/hack version of it.

In some respe= cts this is like offer/answer, where there were a lot of loose ends, and cl= osing them has brought a lot of complexity to something that was previously= considered relatively simple. But o/a is a lot more important to sip than = H-I is, so people are (I assume) more motivated. And I expect that nobody h= as tried to implement *all* of o/a as it is currently understood.

I don't have an answer here, just a concern. Maybe if I studied it = all in excruciating detail, as if I were implementing it, I would feel bett= er. But I doubt it.

=A0 =A0 =A0 =A0Thanks,
=A0 =A0 =A0 =A0Paul=20


On 2/22/2011 3:21 PM, Mary Barnes wrote:
Hi John,
Responses inline below [MB3].
Mary.
On Thu, Feb 17, 2011 at 3:09 PM, Elwell, John
<john.elwell@siemens-ente= rprise.com
<mailto:john.elwell@siemens-enterprise.com>> wr= ote:



=A0 =A0 > -----Original Message-----
=A0 =A0 >= From: Mary Barnes [mailto:mary.ietf.barnes@gmail.com
=A0 =A0<mailto:mary.ietf.barnes@gmail.com>]
=A0 =A0 > Sent: 17 Februar= y 2011 18:32
=A0 =A0 > To: Elwell, John
=A0 =A0 > Cc: SIPCORE=A0 =A0 > Subject: Part1: Some comments on
=A0 =A0 > draft-ietf-sipcore-rfc4244bis-03.txt - Including all
=A0 = =A0 > hi-entries in responses
=A0 =A0 >
=A0 =A0 > HI John,=A0 =A0 >
=A0 =A0 > Responses inline below [MB2]. =A0 I'm se= parating the thread
=A0 =A0 > into two separate emails as I think the= re are two distinct
=A0 =A0 > issues within this thread, so it will be easier to track.
= =A0 =A0 >
=A0 =A0 > Thanks,
=A0 =A0 > Mary.
=A0 =A0 ><= br>=A0 =A0 >
=A0 =A0 > On Thu, Feb 17, 2011 at 2:20 AM, Elwell, Jo= hn
=A0 =A0 > <john.elwell@siemens-enterprise.com
=A0 =A0<mailto:john.elwell@siemens-enterprise.com>= > wrote:
=A0 =A0 >
=A0 =A0 >
=A0 =A0 > =A0 =A0 =A0 Mar= y,
=A0 =A0 >
=A0 =A0 > =A0 =A0 =A0 Thanks - see below:
=A0 =A0 >
=A0 =A0 >
=A0 =A0 > > -----Original Message----= -
=A0 =A0 > > From: Mary Barnes [mailto:mary.ietf.barnes@gmail.com
=A0= =A0<mailto:mary.ietf.barnes@gmail.com>]
=A0 =A0 > > Sent: 16 February 2011 23:29
=A0 =A0 > > To: Elw= ell, John
=A0 =A0 > > Cc: SIPCORE
=A0 =A0 > > Subject: Re= : Some comments on
=A0 =A0 > draft-ietf-sipcore-rfc4244bis-03.txt
= =A0 =A0 > >
=A0 =A0 > > Hi John,
=A0 =A0 > >
=A0 =A0 > > Thanks= for the comments. Responses inline below [MB].
=A0 =A0 > >
=A0= =A0 > > Mary.
=A0 =A0 > >
=A0 =A0 > >
=A0 =A0 &= gt; > On Wed, Feb 16, 2011 at 2:14 PM, Elwell, John
=A0 =A0 > > <john.elwell@siemens-enterprise.com
=A0 =A0<mailto:john.elwell@siemens-enterprise.com>= > wrote:
=A0 =A0 > >
=A0 =A0 > >
=A0 =A0 > > = =A0 =A0 =A0 Mary,
=A0 =A0 > >
=A0 =A0 > > =A0 =A0 =A0 Thanks for this major rewrite and addressing = very many
=A0 =A0 > > earlier comments. I have some initial commen= ts and also a
=A0 =A0 > > general comment.
=A0 =A0 > >=A0 =A0 > > =A0 =A0 =A0 Comment 1: Request fails (4xx, say) and as a= result a
=A0 =A0 > > proxy retargets. According to 7.1.2, the proxy is require= d to
=A0 =A0 > > include in the retargeted request all entries fro= m received
=A0 =A0 > > responses so far, including, presumably, en= tries in the 4xx
=A0 =A0 > > response that leads to retargeting. However, if the reque= st
=A0 =A0 > > does not contain Supported: histinfo, there will be= no
=A0 =A0 > > entries in received responses. Therefore the final= UAS will
=A0 =A0 > > not receive a complete set of entries. So we seem to have= the
=A0 =A0 > > strange situation that the set of entries receive= d by the UAS
=A0 =A0 > > is dependent on support of History-Info a= t the UAC. This
=A0 =A0 > > seems wrong. It seems to me that entries should always be=
=A0 =A0 > > sent backwards, subject to privacy, and perhaps not o= n the
=A0 =A0 > > last hop if the UAC doesn't support it.
= =A0 =A0 > >
=A0 =A0 > >
=A0 =A0 > > =A0[MB]
=A0 =A0 > >
=A0 = =A0 >
=A0 =A0 > =A0 =A0 =A0 [JRE] Your responses seems to be lost.=
=A0 =A0[JRE] I still don't see your response to this one.

[M= B3] This goes back to core RFC 4244 behavior, although I think we
might have broken that as RFC 4244 only limited the UAS from not
includi= ng HI in responses rather than SIP intermediaries (although the
behavior= for an intermediary wasn't totally clear in RFC 4244). =A0 So, I
can certainly see your point. =A0And, making that change is consistent
w= ith other normative behavior that we have changed (i.e., SHOULD add ->MUST add, not removing headers for privacy, etc.). =A0It shouldn't br= eak
any current implementations to make this change. =A0[/MB3]
=A0> ><= br>=A0> > =A0 =A0 =A0 Comment 2: Suppose a proxy forwards a request t= o two
=A0> > targets, one with entry index 1.1 and the other with = entry
=A0> > index 1.2. A provisional or final response is receive= d to the
=A0> > first forwarded request containing an additional entry with=A0> > index 1.1.1. Then a 4xx response is received to the second=A0> > request, causing the proxy to retarget, this time with an
= =A0> > entry index 1.3. According to 7.1.2 step 1, that retargeted =A0> > request should contain entries 1, 1.1.1, 1.2 and 1.3. Note
= =A0> > that 1.1 is missing. I see nothing to require the inclusion=A0> > of 1.1, yet step 1 of 7.1.2 seems to require inclusion of
= =A0> > 1.1.1. Have I misinterpreted something?
=A0> >
=A0> >
=A0> > [MB] 1.1 should also be includ= ed. Perhaps the wording needs
=A0> > clarification, but the text i= s attempting to state that in
=A0> > cases where
=A0>
=A0= > =A0 =A0 =A0 [JRE] Your responses seems to have been truncated.
=A0>
=A0>
=A0> [MB2] I'm not sure if that was me or the = cat. =A0 =A0The text is
=A0> attempting to state that all the hi-entr= ies that were sent in
=A0> previous requests, along with all the hi-e= ntries in responses
=A0> to those requests is included when the request is again
=A0> = retargeted. =A0 But, I can see that the current wording could
=A0> be= read that only the hi-entries in the original request
=A0> versus th= e original request + any other requests for which
=A0> responses have been received, as well as the hi-entries
=A0> = contained in all responses. =A0However, I had thought the
=A0> qualif= ication that it states "in the original request that
=A0> receiv= ed the error response", so perhaps just removing the
=A0> word "original" will suffice? [/MB2]

=A0 =A0[JRE] = I am still confused by your explanation. Let me put the
=A0 =A0question = a different way:
=A0 =A0When I fork a request to several different targe= ts, and when one of
=A0 =A0those branches returns a response which leads me to retarget, what=A0 =A0is included in the retargeted request?
=A0 =A01. Clearly all en= tries received from upstream.
=A0 =A02. Clearly a new entry for the new = target.
=A0 =A03. Clearly the entry for the request whose response cause= d me to
=A0 =A0retarget, and any additional entries in that response.
=A0 =A04. = Do I include entries for other requests on other branches that
=A0 =A0ha= ve responded finally, and any additional entries in those
=A0 =A0respons= es, even though they have not led to retargeting? I think
=A0 =A0your intention is "yes".
=A0 =A05. Do I include entries= for other requests on other branches that
=A0 =A0have responded provisi= onally, and any additional entries in those
=A0 =A0responses, even thoug= h they have not led to retargeting? I think
=A0 =A0your intention is "yes", but I am not certain (see also my= comments
=A0 =A0further down concerning Reason header field - an answer= of "no"
=A0 =A0might make more sense).
=A0 =A06. Do I incl= ude entries for other requests on other branches that
=A0 =A0have not yet responded? I think your intention is "no".
=A0 =A0Please confirm my assumptions above. Depending on that we can t= ry to
=A0 =A0address the wording, but I am not sure just deleting "= original" from
=A0 =A0the previous text really helps.

[MB3] Yes - the intent is exa= ctly as you state above. [/MB3]

=A0> >
=A0> > =A0 =A0= =A0 Comment 3: In 7.2 it states:
=A0> > "...MUST forward cap= tured History-Info in
=A0> > =A0 =A0 =A0 =A0 subsequent, provisional, and final responses t= o the
=A0> > request sent by
=A0> > =A0 =A0 =A0 =A0 the u= ltimate UAS (see Section 6.2)..."
=A0> > =A0 =A0 =A0 When a p= roxy forwards a provisional response, how does
=A0> > it know that this is from the ultimate UAS? This can only be=A0> > known when the first 2xx arrives. In fact the term "ult= imate
=A0> > UAS" is also problematic because how does a prox= y know that a
=A0> > response has come from a UAS, as opposed to a proxy?
=A0>= ; >
=A0> >
=A0> > [MB] It doesn't know that it'= ;s the ultimate UAS, so=3Do we
=A0> > should remove that phrase. = =A0It's attempting to highlight that
=A0> > all the information is sent in the responses, but that's=A0> > really covered elsewhere. [/MB]
=A0>
=A0> =A0 = =A0 =A0 [JRE] It does seem to make sense to simplify it so that
=A0> = you send all information in all provisional or final
=A0> responses (except 100). Just an example to help confirm
=A0> = whether this simple rule makes sense:
=A0> =A0 =A0 =A0 A proxy forks,= sending requests with indices 1.1, 1.2
=A0> and 1.3. Then the 1.3 br= anch sends a response (provisional,
=A0> final) containing additional entry 1.3.1. In this case the
=A0&g= t; response that the proxy sends upstream would contain 1, 1.1,
=A0> = 1.2, 1.3 and 1.3.1 - correct? So even though the 1.1 and 1.2
=A0> bra= nches have not responded, they are included in the
=A0> upstream response?
=A0>
=A0>
=A0>
=A0> [MB2= ] The current approach is consistent with RFC 4244
=A0> whereby only = the hi-entries for requests for which responses
=A0> have been receiv= ed are included in the upstream response.

=A0 =A0[JRE] So you are saying that in my example above, indices 1.1 an= d
=A0 =A01.2 would not be sent upstream, because they have not responded= ? I
=A0 =A0am not asking for an explanation of how we got there - just a= sking
=A0 =A0what the model is intended to be.

[MB3] Correct.[/MB3]

=A0 =A0 > Again, it's hard for me to totally recall the logic, = but I
=A0 =A0 > think it was because at that point in time, you don&#= 39;t know
=A0 =A0 > what will happen to that request - i.e., it's more mislead= ing
=A0 =A0 > than helpful. =A0 =A0We'd have to consider whether = it would cause
=A0 =A0 > an issue with backwards compatibility if we = change this now.
=A0 =A0 > IMHO, those entries only have value if you could accurately=A0 =A0 > tag that they were outstanding or had timed out rather than=A0 =A0 > infer that because they have no reason header means that the=
=A0 =A0 > retargeting entity has not yet received a response.
=A0 =A0[JRE] You have brought to my attention something I missed before.=A0 =A0When you put a Reason header field into an hi-entry, you now only=A0 =A0convey that Reason header field in that hi-entry in the retargeted=
=A0 =A0request downstream, but also in that same hi-entry when it gets = sent
=A0 =A0upstream for any reason. So it begins to make sense to me now why=A0 =A0you would exclude entries for requests that have not produced a
= =A0 =A0response. However, this leads me to a couple of further questions:=A0 =A01. According to 9.2, it is only failed requests that lead to
=A0 =A0retargeting that cause a Reason header field to be placed in their=A0 =A0hi-entry, not failed requests that do not directly lead to
=A0 = =A0retargeting. From what you say above, it seems that any failed
=A0 = =A0request (3xx, 4xx, 5xx, 6xx) should cause a Reason header field to
=A0 =A0be placed into its hi-entry, even if that request does not lead to=A0 =A0retargeting.

[MB3] =A0That is the intent - the Reason shoul= d be reflecting why the
request did not successfully terminate at the ta= rget (and thus why the
request might be retargeted or a response generated). =A0 =A0That all said,=
I think we need more text around this as adding the Reason to the
hi= -entry is described entirely in the context of retargeting and not
speci= fically around sending HI in responses. =A0So, I think we need to add
some more text to the definition of Reason. =A0And, I think we need to
e= nsure that when we are describing the Reason header that we also
include= the case in which the URI that is being retargeted isn't the one
with which the Reason is being associated, as well as in cases where theRequest was unsuccessful and a response is generated.[/MB3]
2. What abo= ut requests that so far have only produced a provisional
response and ha= ve not been the cause of retargeting. Does that 1xx
response code get put in the hi-entry as a Reason header field, and are
= those entries included in any upstream responses or retargeted requests
= that might be sent before the branch concerned issues a final response?
[MB3] Yes, per my response above. [/MB3]


=A0 =A0 > Also, per<= br>=A0 =A0 > the comment above you would also have an hi-entry with an=A0 =A0 > index of =A01.1.1 and that hi-entry would have a Reason head= er
=A0 =A0 > field "escaped" in the hi-targeted-to-uri. =A0= Whereas, neither
=A0 =A0 > the 1.2 or 1.3.1 hi-entry would have a Reason header field in<= br>=A0 =A0 > the hi-targeted-to-uri. I don't see that to cause so mu= ch
=A0 =A0 > confusion as there might be if it was 1.1., 1.2 and 1.3<= br>=A0 =A0 > requests had been issued at the same time and the only
=A0 =A0 > response comes from 1.2, which has an hi-entry of 1.2.1.
= =A0 =A0 > Thus, the last hi-entry (i.e., 1.3) in the response isn't = one
=A0 =A0 > for which the request has received a response. [/MB2]=A0 =A0[JRE] I am lost on this one - I don't see the relevance of 1.1= .1,
=A0 =A0which was not in my example. But anyway, if you answer the questions=
=A0 =A0above, it should help.

[MB3] =A0You had a 1.1.1 in your e= xample under Comment 2. =A0 Per my
responses above, I was highlighting t= hat only the hi-entries for which
responses have been received are added (i.e., I changed your example
suc= h that 1.3 didn't have a response and thus was trying to highlight
t= hat it would be confusing to have a 1.3 entry since you really don't know what is going to happen with that branch (i.e., it's not yet
&q= uot;complete"). [/MB3]


=A0 =A0John




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

--bcaec53f943d2a1d04049ce599b0-- From pkyzivat@cisco.com Tue Feb 22 15:05:50 2011 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 CD2813A6983 for ; Tue, 22 Feb 2011 15:05:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.286 X-Spam-Level: X-Spam-Status: No, score=-110.286 tagged_above=-999 required=5 tests=[AWL=-0.287, BAYES_00=-2.599, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_HI=-8, 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 kIbB-eWfqMma for ; Tue, 22 Feb 2011 15:05:48 -0800 (PST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 3CB463A6966 for ; Tue, 22 Feb 2011 15:05:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pkyzivat@cisco.com; l=19293; q=dns/txt; s=iport; t=1298415993; x=1299625593; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=WZf5BYeXKiohOhOYHaomvQ7R8hM77nwlN0x3fytAqBs=; b=c7v1w2mdCXAHHLd8gI5+x4dyWyQnINkd61wsF+k6M+x+dDfrTtYbDjm2 ZLIo7mcv2IHC+A/5rJ88+3B+ITypgDB3rSeeQUmuDNz9Iwp4Ti1hU4z/x frr6cqmt85wu7pDqDmUwvuyxYe/8YznBrZzpzbfaCgIYCwaOLKk6LROQ1 s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAJ7QY01AZnwN/2dsb2JhbACmInOhUJtahV4EhQ2HBoM7gxA X-IronPort-AV: E=Sophos;i="4.62,208,1297036800"; d="scan'208";a="218414834" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 22 Feb 2011 23:06:32 +0000 Received: from [161.44.174.114] (dhcp-161-44-174-114.cisco.com [161.44.174.114]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id p1MN6WDW013573; Tue, 22 Feb 2011 23:06:32 GMT Message-ID: <4D644178.7060500@cisco.com> Date: Tue, 22 Feb 2011 18:06:32 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Mary Barnes References: <4D642735.30401@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: sipcore@ietf.org Subject: Re: [sipcore] Part1: Some comments on draft-ietf-sipcore-rfc4244bis-03.txt - Including all hi-entries 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, 22 Feb 2011 23:05:50 -0000 (as individual) IMO the complexity is intrinsic in the the goals that H-I is attempting to achieve. So I don't think additional wordsmithing will "solve" it. And many people (and organizations such as 3gpp) bought into those goals. So I think there is nothing to be done but push on and complete it, and let it be what it has become. IMO the problem is in thinking that this complex set of information is the right solution to real needs, like deciding what voice mailbox to use for voicemail. There are other solutions to those problems. Thanks, Paul On 2/22/2011 4:23 PM, Mary Barnes wrote: > The complexity of History-Info directly correlates with the complexity > of SIP itself, so there's not much that can be simplified. The most > complexity is introduced in cases of parallel forking, which introduces > many loose ends as you note. If we weren't dealing with parallel > forking, I think alot of the complexity is gone since the collection of > the hi-entries happens in a logical, known order. In the case of > parallel forking, the indexing is how the information can be logically > sorted. > As I said early on, I have worked on this way too long to see how things > can be clarified. I believe the wording as the capturing of the entries > is accurate (or nearly so), although it may not be in the most concise > or comprehensible form. I would agree 100% that this document can not > be understood if it is read through only once - as I noted in another > thread, the layout of the material presents a chicken/egg situation. > Also, I have to wonder if it wouldn't help to bring the detailed call > flows back into this document? > Regards, > Mary. > On Tue, Feb 22, 2011 at 3:14 PM, Paul Kyzivat > wrote: > > (as individual) > > I have been "loosely" following this. > > What I am taking away from this discussion is that the bookkeeping > and header flogging necessary to properly implement this, and then > to interpret the results, are so extreme that its unlikely that it > will be implemented correctly, if anyone even bothers to try. > > What I fear most is that implementors will conclude that it is too > hard to get right, but that they are required to support it, and so > they will implement some approximation/subset/hack version of it. > > In some respects this is like offer/answer, where there were a lot > of loose ends, and closing them has brought a lot of complexity to > something that was previously considered relatively simple. But o/a > is a lot more important to sip than H-I is, so people are (I assume) > more motivated. And I expect that nobody has tried to implement > *all* of o/a as it is currently understood. > > I don't have an answer here, just a concern. Maybe if I studied it > all in excruciating detail, as if I were implementing it, I would > feel better. But I doubt it. > > Thanks, > Paul > > > On 2/22/2011 3:21 PM, Mary Barnes wrote: > > Hi John, > Responses inline below [MB3]. > Mary. > > On Thu, Feb 17, 2011 at 3:09 PM, Elwell, John > > >> wrote: > > > > > -----Original Message----- > > From: Mary Barnes [mailto:mary.ietf.barnes@gmail.com > > >] > > Sent: 17 February 2011 18:32 > > To: Elwell, John > > Cc: SIPCORE > > Subject: Part1: Some comments on > > draft-ietf-sipcore-rfc4244bis-03.txt - Including all > > hi-entries in responses > > > > HI John, > > > > Responses inline below [MB2]. I'm separating the thread > > into two separate emails as I think there are two distinct > > issues within this thread, so it will be easier to track. > > > > Thanks, > > Mary. > > > > > > On Thu, Feb 17, 2011 at 2:20 AM, Elwell, John > > > >> wrote: > > > > > > Mary, > > > > Thanks - see below: > > > > > > > -----Original Message----- > > > From: Mary Barnes [mailto:mary.ietf.barnes@gmail.com > > >] > > > Sent: 16 February 2011 23:29 > > > To: Elwell, John > > > Cc: SIPCORE > > > Subject: Re: Some comments on > > draft-ietf-sipcore-rfc4244bis-03.txt > > > > > > Hi John, > > > > > > Thanks for the comments. Responses inline below [MB]. > > > > > > Mary. > > > > > > > > > On Wed, Feb 16, 2011 at 2:14 PM, Elwell, John > > > > >> wrote: > > > > > > > > > Mary, > > > > > > Thanks for this major rewrite and addressing very many > > > earlier comments. I have some initial comments and also a > > > general comment. > > > > > > Comment 1: Request fails (4xx, say) and as a result a > > > proxy retargets. According to 7.1.2, the proxy is required to > > > include in the retargeted request all entries from received > > > responses so far, including, presumably, entries in the 4xx > > > response that leads to retargeting. However, if the request > > > does not contain Supported: histinfo, there will be no > > > entries in received responses. Therefore the final UAS will > > > not receive a complete set of entries. So we seem to have the > > > strange situation that the set of entries received by the UAS > > > is dependent on support of History-Info at the UAC. This > > > seems wrong. It seems to me that entries should always be > > > sent backwards, subject to privacy, and perhaps not on the > > > last hop if the UAC doesn't support it. > > > > > > > > > [MB] > > > > > > > [JRE] Your responses seems to be lost. > [JRE] I still don't see your response to this one. > > [MB3] This goes back to core RFC 4244 behavior, although I think we > might have broken that as RFC 4244 only limited the UAS from not > including HI in responses rather than SIP intermediaries > (although the > behavior for an intermediary wasn't totally clear in RFC 4244). > So, I > can certainly see your point. And, making that change is consistent > with other normative behavior that we have changed (i.e., SHOULD > add -> > MUST add, not removing headers for privacy, etc.). It shouldn't > break > any current implementations to make this change. [/MB3] > > > > > > Comment 2: Suppose a proxy forwards a request to two > > > targets, one with entry index 1.1 and the other with entry > > > index 1.2. A provisional or final response is received to the > > > first forwarded request containing an additional entry with > > > index 1.1.1. Then a 4xx response is received to the second > > > request, causing the proxy to retarget, this time with an > > > entry index 1.3. According to 7.1.2 step 1, that retargeted > > > request should contain entries 1, 1.1.1, 1.2 and 1.3. Note > > > that 1.1 is missing. I see nothing to require the inclusion > > > of 1.1, yet step 1 of 7.1.2 seems to require inclusion of > > > 1.1.1. Have I misinterpreted something? > > > > > > > > > [MB] 1.1 should also be included. Perhaps the wording needs > > > clarification, but the text is attempting to state that in > > > cases where > > > > [JRE] Your responses seems to have been truncated. > > > > > > [MB2] I'm not sure if that was me or the cat. The text is > > attempting to state that all the hi-entries that were sent in > > previous requests, along with all the hi-entries in responses > > to those requests is included when the request is again > > retargeted. But, I can see that the current wording could > > be read that only the hi-entries in the original request > > versus the original request + any other requests for which > > responses have been received, as well as the hi-entries > > contained in all responses. However, I had thought the > > qualification that it states "in the original request that > > received the error response", so perhaps just removing the > > word "original" will suffice? [/MB2] > > [JRE] I am still confused by your explanation. Let me put the > question a different way: > When I fork a request to several different targets, and when > one of > those branches returns a response which leads me to > retarget, what > is included in the retargeted request? > 1. Clearly all entries received from upstream. > 2. Clearly a new entry for the new target. > 3. Clearly the entry for the request whose response caused me to > retarget, and any additional entries in that response. > 4. Do I include entries for other requests on other branches > that > have responded finally, and any additional entries in those > responses, even though they have not led to retargeting? I think > your intention is "yes". > 5. Do I include entries for other requests on other branches > that > have responded provisionally, and any additional entries in > those > responses, even though they have not led to retargeting? I think > your intention is "yes", but I am not certain (see also my > comments > further down concerning Reason header field - an answer of "no" > might make more sense). > 6. Do I include entries for other requests on other branches > that > have not yet responded? I think your intention is "no". > > Please confirm my assumptions above. Depending on that we > can try to > address the wording, but I am not sure just deleting > "original" from > the previous text really helps. > > [MB3] Yes - the intent is exactly as you state above. [/MB3] > > > > > > > Comment 3: In 7.2 it states: > > > "...MUST forward captured History-Info in > > > subsequent, provisional, and final responses to the > > > request sent by > > > the ultimate UAS (see Section 6.2)..." > > > When a proxy forwards a provisional response, how does > > > it know that this is from the ultimate UAS? This can only be > > > known when the first 2xx arrives. In fact the term "ultimate > > > UAS" is also problematic because how does a proxy know that a > > > response has come from a UAS, as opposed to a proxy? > > > > > > > > > [MB] It doesn't know that it's the ultimate UAS, so=o we > > > should remove that phrase. It's attempting to highlight that > > > all the information is sent in the responses, but that's > > > really covered elsewhere. [/MB] > > > > [JRE] It does seem to make sense to simplify it so that > > you send all information in all provisional or final > > responses (except 100). Just an example to help confirm > > whether this simple rule makes sense: > > A proxy forks, sending requests with indices 1.1, 1.2 > > and 1.3. Then the 1.3 branch sends a response (provisional, > > final) containing additional entry 1.3.1. In this case the > > response that the proxy sends upstream would contain 1, 1.1, > > 1.2, 1.3 and 1.3.1 - correct? So even though the 1.1 and 1.2 > > branches have not responded, they are included in the > > upstream response? > > > > > > > > [MB2] The current approach is consistent with RFC 4244 > > whereby only the hi-entries for requests for which responses > > have been received are included in the upstream response. > > [JRE] So you are saying that in my example above, indices > 1.1 and > 1.2 would not be sent upstream, because they have not > responded? I > am not asking for an explanation of how we got there - just > asking > what the model is intended to be. > > [MB3] Correct.[/MB3] > > > > Again, it's hard for me to totally recall the logic, but I > > think it was because at that point in time, you don't know > > what will happen to that request - i.e., it's more misleading > > than helpful. We'd have to consider whether it would cause > > an issue with backwards compatibility if we change this now. > > IMHO, those entries only have value if you could accurately > > tag that they were outstanding or had timed out rather than > > infer that because they have no reason header means that the > > retargeting entity has not yet received a response. > [JRE] You have brought to my attention something I missed > before. > When you put a Reason header field into an hi-entry, you now > only > convey that Reason header field in that hi-entry in the > retargeted > request downstream, but also in that same hi-entry when it > gets sent > upstream for any reason. So it begins to make sense to me > now why > you would exclude entries for requests that have not produced a > response. However, this leads me to a couple of further > questions: > 1. According to 9.2, it is only failed requests that lead to > retargeting that cause a Reason header field to be placed in > their > hi-entry, not failed requests that do not directly lead to > retargeting. From what you say above, it seems that any failed > request (3xx, 4xx, 5xx, 6xx) should cause a Reason header > field to > be placed into its hi-entry, even if that request does not > lead to > retargeting. > > [MB3] That is the intent - the Reason should be reflecting why the > request did not successfully terminate at the target (and thus > why the > request might be retargeted or a response generated). That > all said, > I think we need more text around this as adding the Reason to the > hi-entry is described entirely in the context of retargeting and not > specifically around sending HI in responses. So, I think we > need to add > some more text to the definition of Reason. And, I think we need to > ensure that when we are describing the Reason header that we also > include the case in which the URI that is being retargeted isn't > the one > with which the Reason is being associated, as well as in cases > where the > Request was unsuccessful and a response is generated.[/MB3] > 2. What about requests that so far have only produced a provisional > response and have not been the cause of retargeting. Does that 1xx > response code get put in the hi-entry as a Reason header field, > and are > those entries included in any upstream responses or retargeted > requests > that might be sent before the branch concerned issues a final > response? > [MB3] Yes, per my response above. [/MB3] > > > > Also, per > > the comment above you would also have an hi-entry with an > > index of 1.1.1 and that hi-entry would have a Reason header > > field "escaped" in the hi-targeted-to-uri. Whereas, neither > > the 1.2 or 1.3.1 hi-entry would have a Reason header field in > > the hi-targeted-to-uri. I don't see that to cause so much > > confusion as there might be if it was 1.1., 1.2 and 1.3 > > requests had been issued at the same time and the only > > response comes from 1.2, which has an hi-entry of 1.2.1. > > Thus, the last hi-entry (i.e., 1.3) in the response isn't one > > for which the request has received a response. [/MB2] > [JRE] I am lost on this one - I don't see the relevance of > 1.1.1, > which was not in my example. But anyway, if you answer the > questions > above, it should help. > > [MB3] You had a 1.1.1 in your example under Comment 2. Per my > responses above, I was highlighting that only the hi-entries for > which > responses have been received are added (i.e., I changed your example > such that 1.3 didn't have a response and thus was trying to > highlight > that it would be confusing to have a 1.3 entry since you really > don't > know what is going to happen with that branch (i.e., it's not yet > "complete"). [/MB3] > > > 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 mary.ietf.barnes@gmail.com Tue Feb 22 15:18:56 2011 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 52EC03A6962 for ; Tue, 22 Feb 2011 15:18:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.212 X-Spam-Level: X-Spam-Status: No, score=-103.212 tagged_above=-999 required=5 tests=[AWL=-0.214, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_21=0.6, RCVD_IN_DNSWL_LOW=-1, 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 4hnf7oayMRiF for ; Tue, 22 Feb 2011 15:18:53 -0800 (PST) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by core3.amsl.com (Postfix) with ESMTP id 03A7F3A6934 for ; Tue, 22 Feb 2011 15:18:52 -0800 (PST) Received: by vws6 with SMTP id 6so1642172vws.31 for ; Tue, 22 Feb 2011 15:19:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=HxLu8NjAQVSjJv1qiURfSycatR5DXROjkpVSTIYZkME=; b=ZWErUGJy7u9CGB1wBKnZeF+GpuppZgskUWGYWB9kPbHh3aOsaoPtAIUzHgoqNDe/xS auYDmUNZ1lYxr1el9bvVHUPtwuaXozw1LGZif1EuguDsK/XLRuh/N5gYtHp5+W3M3Iag qRl5qKe5wFfOrRLIxF5xWdnwtJNyyJB+UnH8A= 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=NJ9PhLEPwlU+A4fUuyM+jLS99FDsCEtrsApg8Gdl1Vwrm+yGaNRSsc0WXc5p3HOUH2 n/JmF640zVqA1pTDbpv+Nn0UlRq+vGaJrlTFGm7Pl9vFSq3IS6QeTh9+M4hZWu8jI+ZB nH2p5XOmjgneRbtuEsp8uvI+naL+0njhgn6oI= MIME-Version: 1.0 Received: by 10.52.167.42 with SMTP id zl10mr5023789vdb.204.1298416777898; Tue, 22 Feb 2011 15:19:37 -0800 (PST) Received: by 10.52.162.202 with HTTP; Tue, 22 Feb 2011 15:19:37 -0800 (PST) In-Reply-To: <4D644178.7060500@cisco.com> References: <4D642735.30401@cisco.com> <4D644178.7060500@cisco.com> Date: Tue, 22 Feb 2011 17:19:37 -0600 Message-ID: From: Mary Barnes To: Paul Kyzivat Content-Type: multipart/alternative; boundary=bcaec53f943dd12e71049ce73608 Cc: sipcore@ietf.org Subject: Re: [sipcore] Part1: Some comments on draft-ietf-sipcore-rfc4244bis-03.txt - Including all hi-entries 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, 22 Feb 2011 23:18:56 -0000 --bcaec53f943dd12e71049ce73608 Content-Type: text/plain; charset=ISO-8859-1 Hi Paul, Your latter point is an excellent one and we are where we are because there was a conscious decision (a decade ago) to define a general mechanism that could be used by multiple applications as opposed to defining purpose built mechanisms for various applications/services. We have this discussion time and again and as a result end up doing nothing in some cases, which is worse that just picking one approach and following through with it. Session ID is a good example IMHO of whether it's best to define solutions for very discrete problems (e.g,. debug) versus defining a solution that could be applied to a variety of problem domains (e.g., logs, disaggregated media, etc.). I don't want to open up a long thread of discussion and agree that we just need to move forward with this and complete it. Thanks, Mary. On Tue, Feb 22, 2011 at 5:06 PM, Paul Kyzivat wrote: > (as individual) > > IMO the complexity is intrinsic in the the goals that H-I is attempting to > achieve. So I don't think additional wordsmithing will "solve" it. And many > people (and organizations such as 3gpp) bought into those goals. So I think > there is nothing to be done but push on and complete it, and let it be what > it has become. > > IMO the problem is in thinking that this complex set of information is the > right solution to real needs, like deciding what voice mailbox to use for > voicemail. There are other solutions to those problems. > > Thanks, > Paul > > > On 2/22/2011 4:23 PM, Mary Barnes wrote: > >> The complexity of History-Info directly correlates with the complexity >> of SIP itself, so there's not much that can be simplified. The most >> complexity is introduced in cases of parallel forking, which introduces >> many loose ends as you note. If we weren't dealing with parallel >> forking, I think alot of the complexity is gone since the collection of >> the hi-entries happens in a logical, known order. In the case of >> parallel forking, the indexing is how the information can be logically >> sorted. >> As I said early on, I have worked on this way too long to see how things >> can be clarified. I believe the wording as the capturing of the entries >> is accurate (or nearly so), although it may not be in the most concise >> or comprehensible form. I would agree 100% that this document can not >> be understood if it is read through only once - as I noted in another >> thread, the layout of the material presents a chicken/egg situation. >> Also, I have to wonder if it wouldn't help to bring the detailed call >> flows back into this document? >> Regards, >> Mary. >> On Tue, Feb 22, 2011 at 3:14 PM, Paul Kyzivat > > wrote: >> >> (as individual) >> >> I have been "loosely" following this. >> >> What I am taking away from this discussion is that the bookkeeping >> and header flogging necessary to properly implement this, and then >> to interpret the results, are so extreme that its unlikely that it >> will be implemented correctly, if anyone even bothers to try. >> >> What I fear most is that implementors will conclude that it is too >> hard to get right, but that they are required to support it, and so >> they will implement some approximation/subset/hack version of it. >> >> In some respects this is like offer/answer, where there were a lot >> of loose ends, and closing them has brought a lot of complexity to >> something that was previously considered relatively simple. But o/a >> is a lot more important to sip than H-I is, so people are (I assume) >> more motivated. And I expect that nobody has tried to implement >> *all* of o/a as it is currently understood. >> >> I don't have an answer here, just a concern. Maybe if I studied it >> all in excruciating detail, as if I were implementing it, I would >> feel better. But I doubt it. >> >> Thanks, >> Paul >> >> >> On 2/22/2011 3:21 PM, Mary Barnes wrote: >> >> Hi John, >> Responses inline below [MB3]. >> Mary. >> >> On Thu, Feb 17, 2011 at 3:09 PM, Elwell, John >> > >> > >> wrote: >> >> >> >> > -----Original Message----- >> > From: Mary Barnes [mailto:mary.ietf.barnes@gmail.com >> >> > >] >> > Sent: 17 February 2011 18:32 >> > To: Elwell, John >> > Cc: SIPCORE >> > Subject: Part1: Some comments on >> > draft-ietf-sipcore-rfc4244bis-03.txt - Including all >> > hi-entries in responses >> > >> > HI John, >> > >> > Responses inline below [MB2]. I'm separating the thread >> > into two separate emails as I think there are two distinct >> > issues within this thread, so it will be easier to track. >> > >> > Thanks, >> > Mary. >> > >> > >> > On Thu, Feb 17, 2011 at 2:20 AM, Elwell, John >> > > >> > >> wrote: >> > >> > >> > Mary, >> > >> > Thanks - see below: >> > >> > >> > > -----Original Message----- >> > > From: Mary Barnes [mailto:mary.ietf.barnes@gmail.com >> >> > >] >> > > Sent: 16 February 2011 23:29 >> > > To: Elwell, John >> > > Cc: SIPCORE >> > > Subject: Re: Some comments on >> > draft-ietf-sipcore-rfc4244bis-03.txt >> > > >> > > Hi John, >> > > >> > > Thanks for the comments. Responses inline below [MB]. >> > > >> > > Mary. >> > > >> > > >> > > On Wed, Feb 16, 2011 at 2:14 PM, Elwell, John >> > > > >> > >> wrote: >> > > >> > > >> > > Mary, >> > > >> > > Thanks for this major rewrite and addressing very many >> > > earlier comments. I have some initial comments and also a >> > > general comment. >> > > >> > > Comment 1: Request fails (4xx, say) and as a result a >> > > proxy retargets. According to 7.1.2, the proxy is required to >> > > include in the retargeted request all entries from received >> > > responses so far, including, presumably, entries in the 4xx >> > > response that leads to retargeting. However, if the request >> > > does not contain Supported: histinfo, there will be no >> > > entries in received responses. Therefore the final UAS will >> > > not receive a complete set of entries. So we seem to have the >> > > strange situation that the set of entries received by the UAS >> > > is dependent on support of History-Info at the UAC. This >> > > seems wrong. It seems to me that entries should always be >> > > sent backwards, subject to privacy, and perhaps not on the >> > > last hop if the UAC doesn't support it. >> > > >> > > >> > > [MB] >> > > >> > >> > [JRE] Your responses seems to be lost. >> [JRE] I still don't see your response to this one. >> >> [MB3] This goes back to core RFC 4244 behavior, although I think we >> might have broken that as RFC 4244 only limited the UAS from not >> including HI in responses rather than SIP intermediaries >> (although the >> behavior for an intermediary wasn't totally clear in RFC 4244). >> So, I >> can certainly see your point. And, making that change is >> consistent >> with other normative behavior that we have changed (i.e., SHOULD >> add -> >> MUST add, not removing headers for privacy, etc.). It shouldn't >> break >> any current implementations to make this change. [/MB3] >> > > >> > > Comment 2: Suppose a proxy forwards a request to two >> > > targets, one with entry index 1.1 and the other with entry >> > > index 1.2. A provisional or final response is received to the >> > > first forwarded request containing an additional entry with >> > > index 1.1.1. Then a 4xx response is received to the second >> > > request, causing the proxy to retarget, this time with an >> > > entry index 1.3. According to 7.1.2 step 1, that retargeted >> > > request should contain entries 1, 1.1.1, 1.2 and 1.3. Note >> > > that 1.1 is missing. I see nothing to require the inclusion >> > > of 1.1, yet step 1 of 7.1.2 seems to require inclusion of >> > > 1.1.1. Have I misinterpreted something? >> > > >> > > >> > > [MB] 1.1 should also be included. Perhaps the wording needs >> > > clarification, but the text is attempting to state that in >> > > cases where >> > >> > [JRE] Your responses seems to have been truncated. >> > >> > >> > [MB2] I'm not sure if that was me or the cat. The text is >> > attempting to state that all the hi-entries that were sent in >> > previous requests, along with all the hi-entries in responses >> > to those requests is included when the request is again >> > retargeted. But, I can see that the current wording could >> > be read that only the hi-entries in the original request >> > versus the original request + any other requests for which >> > responses have been received, as well as the hi-entries >> > contained in all responses. However, I had thought the >> > qualification that it states "in the original request that >> > received the error response", so perhaps just removing the >> > word "original" will suffice? [/MB2] >> >> [JRE] I am still confused by your explanation. Let me put the >> question a different way: >> When I fork a request to several different targets, and when >> one of >> those branches returns a response which leads me to >> retarget, what >> is included in the retargeted request? >> 1. Clearly all entries received from upstream. >> 2. Clearly a new entry for the new target. >> 3. Clearly the entry for the request whose response caused me >> to >> retarget, and any additional entries in that response. >> 4. Do I include entries for other requests on other branches >> that >> have responded finally, and any additional entries in those >> responses, even though they have not led to retargeting? I >> think >> your intention is "yes". >> 5. Do I include entries for other requests on other branches >> that >> have responded provisionally, and any additional entries in >> those >> responses, even though they have not led to retargeting? I >> think >> your intention is "yes", but I am not certain (see also my >> comments >> further down concerning Reason header field - an answer of "no" >> might make more sense). >> 6. Do I include entries for other requests on other branches >> that >> have not yet responded? I think your intention is "no". >> >> Please confirm my assumptions above. Depending on that we >> can try to >> address the wording, but I am not sure just deleting >> "original" from >> the previous text really helps. >> >> [MB3] Yes - the intent is exactly as you state above. [/MB3] >> >> > > >> > > Comment 3: In 7.2 it states: >> > > "...MUST forward captured History-Info in >> > > subsequent, provisional, and final responses to the >> > > request sent by >> > > the ultimate UAS (see Section 6.2)..." >> > > When a proxy forwards a provisional response, how does >> > > it know that this is from the ultimate UAS? This can only be >> > > known when the first 2xx arrives. In fact the term "ultimate >> > > UAS" is also problematic because how does a proxy know that a >> > > response has come from a UAS, as opposed to a proxy? >> > > >> > > >> > > [MB] It doesn't know that it's the ultimate UAS, so=o we >> > > should remove that phrase. It's attempting to highlight that >> > > all the information is sent in the responses, but that's >> > > really covered elsewhere. [/MB] >> > >> > [JRE] It does seem to make sense to simplify it so that >> > you send all information in all provisional or final >> > responses (except 100). Just an example to help confirm >> > whether this simple rule makes sense: >> > A proxy forks, sending requests with indices 1.1, 1.2 >> > and 1.3. Then the 1.3 branch sends a response (provisional, >> > final) containing additional entry 1.3.1. In this case the >> > response that the proxy sends upstream would contain 1, 1.1, >> > 1.2, 1.3 and 1.3.1 - correct? So even though the 1.1 and 1.2 >> > branches have not responded, they are included in the >> > upstream response? >> > >> > >> > >> > [MB2] The current approach is consistent with RFC 4244 >> > whereby only the hi-entries for requests for which responses >> > have been received are included in the upstream response. >> >> [JRE] So you are saying that in my example above, indices >> 1.1 and >> 1.2 would not be sent upstream, because they have not >> responded? I >> am not asking for an explanation of how we got there - just >> asking >> what the model is intended to be. >> >> [MB3] Correct.[/MB3] >> >> >> > Again, it's hard for me to totally recall the logic, but I >> > think it was because at that point in time, you don't know >> > what will happen to that request - i.e., it's more misleading >> > than helpful. We'd have to consider whether it would cause >> > an issue with backwards compatibility if we change this now. >> > IMHO, those entries only have value if you could accurately >> > tag that they were outstanding or had timed out rather than >> > infer that because they have no reason header means that the >> > retargeting entity has not yet received a response. >> [JRE] You have brought to my attention something I missed >> before. >> When you put a Reason header field into an hi-entry, you now >> only >> convey that Reason header field in that hi-entry in the >> retargeted >> request downstream, but also in that same hi-entry when it >> gets sent >> upstream for any reason. So it begins to make sense to me >> now why >> you would exclude entries for requests that have not produced a >> response. However, this leads me to a couple of further >> questions: >> 1. According to 9.2, it is only failed requests that lead to >> retargeting that cause a Reason header field to be placed in >> their >> hi-entry, not failed requests that do not directly lead to >> retargeting. From what you say above, it seems that any failed >> request (3xx, 4xx, 5xx, 6xx) should cause a Reason header >> field to >> be placed into its hi-entry, even if that request does not >> lead to >> retargeting. >> >> [MB3] That is the intent - the Reason should be reflecting why the >> request did not successfully terminate at the target (and thus >> why the >> request might be retargeted or a response generated). That >> all said, >> I think we need more text around this as adding the Reason to the >> hi-entry is described entirely in the context of retargeting and >> not >> specifically around sending HI in responses. So, I think we >> need to add >> some more text to the definition of Reason. And, I think we need >> to >> ensure that when we are describing the Reason header that we also >> include the case in which the URI that is being retargeted isn't >> the one >> with which the Reason is being associated, as well as in cases >> where the >> Request was unsuccessful and a response is generated.[/MB3] >> 2. What about requests that so far have only produced a provisional >> response and have not been the cause of retargeting. Does that 1xx >> response code get put in the hi-entry as a Reason header field, >> and are >> those entries included in any upstream responses or retargeted >> requests >> that might be sent before the branch concerned issues a final >> response? >> [MB3] Yes, per my response above. [/MB3] >> >> >> > Also, per >> > the comment above you would also have an hi-entry with an >> > index of 1.1.1 and that hi-entry would have a Reason header >> > field "escaped" in the hi-targeted-to-uri. Whereas, neither >> > the 1.2 or 1.3.1 hi-entry would have a Reason header field in >> > the hi-targeted-to-uri. I don't see that to cause so much >> > confusion as there might be if it was 1.1., 1.2 and 1.3 >> > requests had been issued at the same time and the only >> > response comes from 1.2, which has an hi-entry of 1.2.1. >> > Thus, the last hi-entry (i.e., 1.3) in the response isn't one >> > for which the request has received a response. [/MB2] >> [JRE] I am lost on this one - I don't see the relevance of >> 1.1.1, >> which was not in my example. But anyway, if you answer the >> questions >> above, it should help. >> >> [MB3] You had a 1.1.1 in your example under Comment 2. Per my >> responses above, I was highlighting that only the hi-entries for >> which >> responses have been received are added (i.e., I changed your >> example >> such that 1.3 didn't have a response and thus was trying to >> highlight >> that it would be confusing to have a 1.3 entry since you really >> don't >> know what is going to happen with that branch (i.e., it's not yet >> "complete"). [/MB3] >> >> >> 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 >> >> >> --bcaec53f943dd12e71049ce73608 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi Paul,
=A0
Your latter point is an excellent one and we are= where we are because there was a conscious decision (a decade ago) to defi= ne a general mechanism that could be used by multiple applications as oppos= ed to defining purpose built mechanisms for various applications/services.= =A0 We have this discussion time and again and as a result end up doing not= hing in some cases, which is worse that just picking one approach=A0and=A0f= ollowing through with it. =A0Session ID is a good example IMHO=A0of whether= it's best to define solutions for very discrete problems (e.g,. debug)= versus defining a solution that could be applied to a variety of problem d= omains (e.g., logs, disaggregated media, etc.).=A0=A0
=A0
I don't want to open up a long thread of dis= cussion and agree that we just need to move forward with this and complete = it.=A0=A0
=A0
Thanks,
Mary. =A0
=A0
On Tue, Feb 22, 2011 at 5:06 PM, Paul Kyzivat <pkyzivat@cisco.co= m> wrote:
(as individual)

IMO the c= omplexity is intrinsic in the the goals that H-I is attempting to achieve. = So I don't think additional wordsmithing will "solve" it. And= many people (and organizations such as 3gpp) bought into those goals. So I= think there is nothing to be done but push on and complete it, and let it = be what it has become.

IMO the problem is in thinking that this complex set of information is = the right solution to real needs, like deciding what voice mailbox to use f= or voicemail. There are other solutions to those problems.

=A0 =A0 = =A0 =A0Thanks,
=A0 =A0 =A0 =A0Paul=20


On 2/22/2011 4:23 PM, Mary Barnes wrote:
The complexity of History-Info directly correlates with t= he complexity
of SIP itself, so there's not much that can be simplif= ied. =A0The most
complexity is introduced in cases of parallel forking, = which introduces
many loose ends as you note. =A0If we weren't dealing with parallel
= forking, I think alot of the complexity is gone since the collection of
= the hi-entries happens in a logical, known order. In the case of
paralle= l forking, the indexing is how the information can be logically
sorted.
As I said early on, I have worked on this way too long to see ho= w things
can be clarified. =A0I believe the wording as the capturing of = the entries
is accurate (or nearly so), although it may not be in the mo= st concise
or comprehensible form. =A0I would agree 100% that this document can notbe understood if it is read through only once - as I noted in another
t= hread, the layout of the material presents a chicken/egg situation.
Also= , I have to wonder if it wouldn't help to bring the detailed call
flows back into this document?
Regards,
Mary.
On Tue, Feb 22, 2011= at 3:14 PM, Paul Kyzivat <pkyzivat@cisco.com
<mailto:pkyzivat@cisco.com>> wrote:

=A0 =A0(as individ= ual)

=A0 =A0I have been "loosely" following this.

= =A0 =A0What I am taking away from this discussion is that the bookkeeping =A0 =A0and header flogging necessary to properly implement this, and then=A0 =A0to interpret the results, are so extreme that its unlikely that it=
=A0 =A0will be implemented correctly, if anyone even bothers to try.
=A0 =A0What I fear most is that implementors will conclude that it is = too
=A0 =A0hard to get right, but that they are required to support it, and so<= br>=A0 =A0they will implement some approximation/subset/hack version of it.=

=A0 =A0In some respects this is like offer/answer, where there were= a lot
=A0 =A0of loose ends, and closing them has brought a lot of complexity to=A0 =A0something that was previously considered relatively simple. But o/= a
=A0 =A0is a lot more important to sip than H-I is, so people are (I as= sume)
=A0 =A0more motivated. And I expect that nobody has tried to implement
= =A0 =A0*all* of o/a as it is currently understood.

=A0 =A0I don'= t have an answer here, just a concern. Maybe if I studied it
=A0 =A0all = in excruciating detail, as if I were implementing it, I would
=A0 =A0feel better. But I doubt it.

=A0 =A0 =A0 =A0 =A0 =A0Thanks,=A0 =A0 =A0 =A0 =A0 =A0Paul


=A0 =A0On 2/22/2011 3:21 PM, Mary = Barnes wrote:

=A0 =A0 =A0 =A0Hi John,
=A0 =A0 =A0 =A0Responses in= line below [MB3].
=A0 =A0 =A0 =A0Mary.

=A0 =A0 =A0 =A0On Thu, Feb= 17, 2011 at 3:09 PM, Elwell, John
=A0 =A0 =A0 =A0<john.elwell@siemens-enterprise.com
=A0 =A0 =A0 =A0&l= t;mailto:john.elwell@siemens-enterprise.com>
=A0 =A0 =A0 =A0<mailto:john.elwell@siemens-enterprise.com
=A0 =A0 = =A0 =A0<mailto:john.elwell@siemens-enterprise.com>>> wrote:


=A0 =A0 =A0 =A0 > -----Original Message-----
=A0 =A0 =A0 = =A0 > From: Mary Barnes [mailto:mary.ietf.barnes@gmail.com
=A0 =A0 =A0 =A0&l= t;mailto:ma= ry.ietf.barnes@gmail.com>
=A0 =A0 =A0 =A0<mailto:mary.ietf.barnes@gmail.com
=A0 =A0 =A0 =A0<mailto:= mary.ietf.b= arnes@gmail.com>>]
=A0 =A0 =A0 =A0 > Sent: 17 February 2011 18:32
=A0 =A0 =A0 =A0 > T= o: Elwell, John
=A0 =A0 =A0 =A0 > Cc: SIPCORE
=A0 =A0 =A0 =A0 >= Subject: Part1: Some comments on
=A0 =A0 =A0 =A0 > draft-ietf-sipcor= e-rfc4244bis-03.txt - Including all
=A0 =A0 =A0 =A0 > hi-entries in responses
=A0 =A0 =A0 =A0 >
=A0= =A0 =A0 =A0 > HI John,
=A0 =A0 =A0 =A0 >
=A0 =A0 =A0 =A0 > = Responses inline below [MB2]. =A0 I'm separating the thread
=A0 =A0 = =A0 =A0 > into two separate emails as I think there are two distinct
=A0 =A0 =A0 =A0 > issues within this thread, so it will be easier to tra= ck.
=A0 =A0 =A0 =A0 >
=A0 =A0 =A0 =A0 > Thanks,
=A0 =A0 =A0 = =A0 > Mary.
=A0 =A0 =A0 =A0 >
=A0 =A0 =A0 =A0 >
=A0 =A0 = =A0 =A0 > On Thu, Feb 17, 2011 at 2:20 AM, Elwell, John
=A0 =A0 =A0 =A0 > <john.elwell@siemens-enterprise.com
=A0 =A0 =A0= =A0<mailto:john.elwell@siemens-enterprise.com>
=A0 =A0 =A0 =A0<mailto:john.elwell@siemens-enterprise.com
=A0 =A0 = =A0 =A0<mailto:john.elwell@siemens-enterprise.com>>> wrote: =A0 =A0 =A0 =A0 >
=A0 =A0 =A0 =A0 >
=A0 =A0 =A0 =A0 > =A0 = =A0 =A0 Mary,
=A0 =A0 =A0 =A0 >
=A0 =A0 =A0 =A0 > =A0 =A0 =A0 T= hanks - see below:
=A0 =A0 =A0 =A0 >
=A0 =A0 =A0 =A0 >
=A0 = =A0 =A0 =A0 > > -----Original Message-----
=A0 =A0 =A0 =A0 > &g= t; From: Mary Barnes [mailto:mary.ietf.barnes@gmail.com
=A0 =A0 =A0 =A0<mailto:mary.ietf.barnes@gmail.com>
=A0 =A0 =A0 =A0<mai= lto:mary.ie= tf.barnes@gmail.com
=A0 =A0 =A0 =A0<mailto:mary.ietf.barnes@gmail.com>>]
=A0 =A0 =A0 =A0 &= gt; > Sent: 16 February 2011 23:29
=A0 =A0 =A0 =A0 > > To: Elwe= ll, John
=A0 =A0 =A0 =A0 > > Cc: SIPCORE
=A0 =A0 =A0 =A0 > > Subject: Re: Some comments on
=A0 =A0 =A0 =A0 = > draft-ietf-sipcore-rfc4244bis-03.txt
=A0 =A0 =A0 =A0 > >
= =A0 =A0 =A0 =A0 > > Hi John,
=A0 =A0 =A0 =A0 > >
=A0 =A0 = =A0 =A0 > > Thanks for the comments. Responses inline below [MB].
=A0 =A0 =A0 =A0 > >
=A0 =A0 =A0 =A0 > > Mary.
=A0 =A0 =A0= =A0 > >
=A0 =A0 =A0 =A0 > >
=A0 =A0 =A0 =A0 > > On= Wed, Feb 16, 2011 at 2:14 PM, Elwell, John
=A0 =A0 =A0 =A0 > > &l= t;j= ohn.elwell@siemens-enterprise.com
=A0 =A0 =A0 =A0<mailto:john.elwell@siemens-enterprise.com>
=A0 = =A0 =A0 =A0<mailto:john.elwell@siemens-enterprise.com
=A0 =A0 =A0 =A0<mailto:john.elwell@siemens-enterprise.com>>> w= rote:
=A0 =A0 =A0 =A0 > >
=A0 =A0 =A0 =A0 > >
=A0 =A0 = =A0 =A0 > > =A0 =A0 =A0 Mary,
=A0 =A0 =A0 =A0 > >
=A0 =A0 =A0 =A0 > > =A0 =A0 =A0 Thanks f= or this major rewrite and addressing very many
=A0 =A0 =A0 =A0 > >= earlier comments. I have some initial comments and also a
=A0 =A0 =A0 = =A0 > > general comment.
=A0 =A0 =A0 =A0 > >
=A0 =A0 =A0 =A0 > > =A0 =A0 =A0 Comment 1: Request fails (4xx, say) a= nd as a result a
=A0 =A0 =A0 =A0 > > proxy retargets. According to= 7.1.2, the proxy is required to
=A0 =A0 =A0 =A0 > > include in th= e retargeted request all entries from received
=A0 =A0 =A0 =A0 > > responses so far, including, presumably, entries = in the 4xx
=A0 =A0 =A0 =A0 > > response that leads to retargeting.= However, if the request
=A0 =A0 =A0 =A0 > > does not contain Supp= orted: histinfo, there will be no
=A0 =A0 =A0 =A0 > > entries in received responses. Therefore the fina= l UAS will
=A0 =A0 =A0 =A0 > > not receive a complete set of entri= es. So we seem to have the
=A0 =A0 =A0 =A0 > > strange situation t= hat the set of entries received by the UAS
=A0 =A0 =A0 =A0 > > is dependent on support of History-Info at the UA= C. This
=A0 =A0 =A0 =A0 > > seems wrong. It seems to me that entri= es should always be
=A0 =A0 =A0 =A0 > > sent backwards, subject to= privacy, and perhaps not on the
=A0 =A0 =A0 =A0 > > last hop if the UAC doesn't support it.
= =A0 =A0 =A0 =A0 > >
=A0 =A0 =A0 =A0 > >
=A0 =A0 =A0 =A0 &= gt; > =A0[MB]
=A0 =A0 =A0 =A0 > >
=A0 =A0 =A0 =A0 >
= =A0 =A0 =A0 =A0 > =A0 =A0 =A0 [JRE] Your responses seems to be lost.
=A0 =A0 =A0 =A0 =A0 =A0[JRE] I still don't see your response to this on= e.

=A0 =A0 =A0 =A0[MB3] This goes back to core RFC 4244 behavior, al= though I think we
=A0 =A0 =A0 =A0might have broken that as RFC 4244 only= limited the UAS from not
=A0 =A0 =A0 =A0including HI in responses rather than SIP intermediaries
= =A0 =A0 =A0 =A0(although the
=A0 =A0 =A0 =A0behavior for an intermediary= wasn't totally clear in RFC 4244).
=A0 =A0 =A0 =A0 =A0 So, I
=A0= =A0 =A0 =A0can certainly see your point. =A0And, making that change is con= sistent
=A0 =A0 =A0 =A0with other normative behavior that we have changed (i.e., SH= OULD
=A0 =A0 =A0 =A0add ->
=A0 =A0 =A0 =A0MUST add, not removing h= eaders for privacy, etc.). =A0It shouldn't
=A0 =A0 =A0 =A0break
= =A0 =A0 =A0 =A0any current implementations to make this change. =A0[/MB3] =A0 =A0 =A0 =A0 > >
=A0 =A0 =A0 =A0 > > =A0 =A0 =A0 Comment = 2: Suppose a proxy forwards a request to two
=A0 =A0 =A0 =A0 > > t= argets, one with entry index 1.1 and the other with entry
=A0 =A0 =A0 = =A0 > > index 1.2. A provisional or final response is received to the=
=A0 =A0 =A0 =A0 > > first forwarded request containing an additional = entry with
=A0 =A0 =A0 =A0 > > index 1.1.1. Then a 4xx response is= received to the second
=A0 =A0 =A0 =A0 > > request, causing the p= roxy to retarget, this time with an
=A0 =A0 =A0 =A0 > > entry index 1.3. According to 7.1.2 step 1, that = retargeted
=A0 =A0 =A0 =A0 > > request should contain entries 1, 1= .1.1, 1.2 and 1.3. Note
=A0 =A0 =A0 =A0 > > that 1.1 is missing. I= see nothing to require the inclusion
=A0 =A0 =A0 =A0 > > of 1.1, yet step 1 of 7.1.2 seems to require incl= usion of
=A0 =A0 =A0 =A0 > > 1.1.1. Have I misinterpreted somethin= g?
=A0 =A0 =A0 =A0 > >
=A0 =A0 =A0 =A0 > >
=A0 =A0 =A0= =A0 > > [MB] 1.1 should also be included. Perhaps the wording needs<= br> =A0 =A0 =A0 =A0 > > clarification, but the text is attempting to stat= e that in
=A0 =A0 =A0 =A0 > > cases where
=A0 =A0 =A0 =A0 ><= br>=A0 =A0 =A0 =A0 > =A0 =A0 =A0 [JRE] Your responses seems to have been= truncated.
=A0 =A0 =A0 =A0 >
=A0 =A0 =A0 =A0 >
=A0 =A0 =A0 =A0 > [MB2] I'm not sure if that was me or the cat. =A0 = =A0The text is
=A0 =A0 =A0 =A0 > attempting to state that all the hi-= entries that were sent in
=A0 =A0 =A0 =A0 > previous requests, along = with all the hi-entries in responses
=A0 =A0 =A0 =A0 > to those requests is included when the request is agai= n
=A0 =A0 =A0 =A0 > retargeted. =A0 But, I can see that the current w= ording could
=A0 =A0 =A0 =A0 > be read that only the hi-entries in th= e original request
=A0 =A0 =A0 =A0 > versus the original request + any other requests for w= hich
=A0 =A0 =A0 =A0 > responses have been received, as well as the h= i-entries
=A0 =A0 =A0 =A0 > contained in all responses. =A0However, I= had thought the
=A0 =A0 =A0 =A0 > qualification that it states "= ;in the original request that
=A0 =A0 =A0 =A0 > received the error response", so perhaps just rem= oving the
=A0 =A0 =A0 =A0 > word "original" will suffice? [= /MB2]

=A0 =A0 =A0 =A0 =A0 =A0[JRE] I am still confused by your expla= nation. Let me put the
=A0 =A0 =A0 =A0 =A0 =A0question a different way:
=A0 =A0 =A0 =A0 =A0 =A0= When I fork a request to several different targets, and when
=A0 =A0 =A0= =A0one of
=A0 =A0 =A0 =A0 =A0 =A0those branches returns a response whic= h leads me to
=A0 =A0 =A0 =A0retarget, what
=A0 =A0 =A0 =A0 =A0 =A0is included in the retargeted request?
=A0 =A0 = =A0 =A0 =A0 =A01. Clearly all entries received from upstream.
=A0 =A0 = =A0 =A0 =A0 =A02. Clearly a new entry for the new target.
=A0 =A0 =A0 = =A0 =A0 =A03. Clearly the entry for the request whose response caused me to=
=A0 =A0 =A0 =A0 =A0 =A0retarget, and any additional entries in that respons= e.
=A0 =A0 =A0 =A0 =A0 =A04. Do I include entries for other requests on = other branches
=A0 =A0 =A0 =A0that
=A0 =A0 =A0 =A0 =A0 =A0have respon= ded finally, and any additional entries in those
=A0 =A0 =A0 =A0 =A0 =A0responses, even though they have not led to retarget= ing? I think
=A0 =A0 =A0 =A0 =A0 =A0your intention is "yes".=A0 =A0 =A0 =A0 =A0 =A05. Do I include entries for other requests on othe= r branches
=A0 =A0 =A0 =A0that
=A0 =A0 =A0 =A0 =A0 =A0have responded = provisionally, and any additional entries in
=A0 =A0 =A0 =A0those
=A0 =A0 =A0 =A0 =A0 =A0responses, even though they = have not led to retargeting? I think
=A0 =A0 =A0 =A0 =A0 =A0your intenti= on is "yes", but I am not certain (see also my
=A0 =A0 =A0 =A0= comments
=A0 =A0 =A0 =A0 =A0 =A0further down concerning Reason header fi= eld - an answer of "no"
=A0 =A0 =A0 =A0 =A0 =A0might make more sense).
=A0 =A0 =A0 =A0 =A0 =A06.= Do I include entries for other requests on other branches
=A0 =A0 =A0 = =A0that
=A0 =A0 =A0 =A0 =A0 =A0have not yet responded? I think your inte= ntion is "no".

=A0 =A0 =A0 =A0 =A0 =A0Please confirm my as= sumptions above. Depending on that we
=A0 =A0 =A0 =A0can try to
=A0 =A0 =A0 =A0 =A0 =A0address the wording, bu= t I am not sure just deleting
=A0 =A0 =A0 =A0"original" from=A0 =A0 =A0 =A0 =A0 =A0the previous text really helps.

=A0 =A0 =A0= =A0[MB3] Yes - the intent is exactly as you state above. [/MB3]

=A0 =A0 =A0 =A0 > >
=A0 =A0 =A0 =A0 > > =A0 =A0 =A0 Comm= ent 3: In 7.2 it states:
=A0 =A0 =A0 =A0 > > "...MUST forward= captured History-Info in
=A0 =A0 =A0 =A0 > > =A0 =A0 =A0 =A0 subs= equent, provisional, and final responses to the
=A0 =A0 =A0 =A0 > > request sent by
=A0 =A0 =A0 =A0 > > =A0 = =A0 =A0 =A0 the ultimate UAS (see Section 6.2)..."
=A0 =A0 =A0 =A0 = > > =A0 =A0 =A0 When a proxy forwards a provisional response, how doe= s
=A0 =A0 =A0 =A0 > > it know that this is from the ultimate UAS? = This can only be
=A0 =A0 =A0 =A0 > > known when the first 2xx arrives. In fact the ter= m "ultimate
=A0 =A0 =A0 =A0 > > UAS" is also problematic= because how does a proxy know that a
=A0 =A0 =A0 =A0 > > response= has come from a UAS, as opposed to a proxy?
=A0 =A0 =A0 =A0 > >
=A0 =A0 =A0 =A0 > >
=A0 =A0 =A0 =A0 &= gt; > [MB] It doesn't know that it's the ultimate UAS, so=3Do we=
=A0 =A0 =A0 =A0 > > should remove that phrase. =A0It's attemp= ting to highlight that
=A0 =A0 =A0 =A0 > > all the information is = sent in the responses, but that's
=A0 =A0 =A0 =A0 > > really covered elsewhere. [/MB]
=A0 =A0 =A0 = =A0 >
=A0 =A0 =A0 =A0 > =A0 =A0 =A0 [JRE] It does seem to make sen= se to simplify it so that
=A0 =A0 =A0 =A0 > you send all information = in all provisional or final
=A0 =A0 =A0 =A0 > responses (except 100).= Just an example to help confirm
=A0 =A0 =A0 =A0 > whether this simple rule makes sense:
=A0 =A0 =A0 = =A0 > =A0 =A0 =A0 A proxy forks, sending requests with indices 1.1, 1.2<= br>=A0 =A0 =A0 =A0 > and 1.3. Then the 1.3 branch sends a response (prov= isional,
=A0 =A0 =A0 =A0 > final) containing additional entry 1.3.1. = In this case the
=A0 =A0 =A0 =A0 > response that the proxy sends upstream would contain 1= , 1.1,
=A0 =A0 =A0 =A0 > 1.2, 1.3 and 1.3.1 - correct? So even though= the 1.1 and 1.2
=A0 =A0 =A0 =A0 > branches have not responded, they = are included in the
=A0 =A0 =A0 =A0 > upstream response?
=A0 =A0 =A0 =A0 >
=A0 =A0 = =A0 =A0 >
=A0 =A0 =A0 =A0 >
=A0 =A0 =A0 =A0 > [MB2] The curr= ent approach is consistent with RFC 4244
=A0 =A0 =A0 =A0 > whereby on= ly the hi-entries for requests for which responses
=A0 =A0 =A0 =A0 > have been received are included in the upstream respon= se.

=A0 =A0 =A0 =A0 =A0 =A0[JRE] So you are saying that in my exampl= e above, indices
=A0 =A0 =A0 =A01.1 and
=A0 =A0 =A0 =A0 =A0 =A01.2 wo= uld not be sent upstream, because they have not
=A0 =A0 =A0 =A0responded? I
=A0 =A0 =A0 =A0 =A0 =A0am not asking for an = explanation of how we got there - just
=A0 =A0 =A0 =A0asking
=A0 =A0 = =A0 =A0 =A0 =A0what the model is intended to be.

=A0 =A0 =A0 =A0[MB3= ] Correct.[/MB3]


=A0 =A0 =A0 =A0 > Again, it's hard for m= e to totally recall the logic, but I
=A0 =A0 =A0 =A0 > think it was because at that point in time, you don= 9;t know
=A0 =A0 =A0 =A0 > what will happen to that request - i.e., i= t's more misleading
=A0 =A0 =A0 =A0 > than helpful. =A0 =A0We'= ;d have to consider whether it would cause
=A0 =A0 =A0 =A0 > an issue with backwards compatibility if we change thi= s now.
=A0 =A0 =A0 =A0 > IMHO, those entries only have value if you c= ould accurately
=A0 =A0 =A0 =A0 > tag that they were outstanding or h= ad timed out rather than
=A0 =A0 =A0 =A0 > infer that because they have no reason header means th= at the
=A0 =A0 =A0 =A0 > retargeting entity has not yet received a re= sponse.
=A0 =A0 =A0 =A0 =A0 =A0[JRE] You have brought to my attention so= mething I missed
=A0 =A0 =A0 =A0before.
=A0 =A0 =A0 =A0 =A0 =A0When you put a Reason header field into an hi-entry,= you now
=A0 =A0 =A0 =A0only
=A0 =A0 =A0 =A0 =A0 =A0convey that Reaso= n header field in that hi-entry in the
=A0 =A0 =A0 =A0retargeted
=A0 = =A0 =A0 =A0 =A0 =A0request downstream, but also in that same hi-entry when = it
=A0 =A0 =A0 =A0gets sent
=A0 =A0 =A0 =A0 =A0 =A0upstream for any reason.= So it begins to make sense to me
=A0 =A0 =A0 =A0now why
=A0 =A0 =A0 = =A0 =A0 =A0you would exclude entries for requests that have not produced a<= br>=A0 =A0 =A0 =A0 =A0 =A0response. However, this leads me to a couple of f= urther
=A0 =A0 =A0 =A0questions:
=A0 =A0 =A0 =A0 =A0 =A01. According to 9.2, it= is only failed requests that lead to
=A0 =A0 =A0 =A0 =A0 =A0retargeting= that cause a Reason header field to be placed in
=A0 =A0 =A0 =A0their=A0 =A0 =A0 =A0 =A0 =A0hi-entry, not failed requests that do not directly= lead to
=A0 =A0 =A0 =A0 =A0 =A0retargeting. From what you say above, it seems that = any failed
=A0 =A0 =A0 =A0 =A0 =A0request (3xx, 4xx, 5xx, 6xx) should ca= use a Reason header
=A0 =A0 =A0 =A0field to
=A0 =A0 =A0 =A0 =A0 =A0be= placed into its hi-entry, even if that request does not
=A0 =A0 =A0 =A0lead to
=A0 =A0 =A0 =A0 =A0 =A0retargeting.

=A0 = =A0 =A0 =A0[MB3] =A0That is the intent - the Reason should be reflecting wh= y the
=A0 =A0 =A0 =A0request did not successfully terminate at the targe= t (and thus
=A0 =A0 =A0 =A0why the
=A0 =A0 =A0 =A0request might be re= targeted or a response generated). =A0 =A0That
=A0 =A0 =A0 =A0all said,
=A0 =A0 =A0 =A0I think we need more text around= this as adding the Reason to the
=A0 =A0 =A0 =A0hi-entry is described e= ntirely in the context of retargeting and not
=A0 =A0 =A0 =A0specificall= y around sending HI in responses. =A0So, I think we
=A0 =A0 =A0 =A0need to add
=A0 =A0 =A0 =A0some more text to the definiti= on of Reason. =A0And, I think we need to
=A0 =A0 =A0 =A0ensure that when= we are describing the Reason header that we also
=A0 =A0 =A0 =A0include= the case in which the URI that is being retargeted isn't
=A0 =A0 =A0 =A0the one
=A0 =A0 =A0 =A0with which the Reason is being ass= ociated, as well as in cases
=A0 =A0 =A0 =A0where the
=A0 =A0 =A0 =A0= Request was unsuccessful and a response is generated.[/MB3]
=A0 =A0 =A0 = =A02. What about requests that so far have only produced a provisional
=A0 =A0 =A0 =A0response and have not been the cause of retargeting. Does th= at 1xx
=A0 =A0 =A0 =A0response code get put in the hi-entry as a Reason = header field,
=A0 =A0 =A0 =A0and are
=A0 =A0 =A0 =A0those entries inc= luded in any upstream responses or retargeted
=A0 =A0 =A0 =A0requests
=A0 =A0 =A0 =A0that might be sent before the bra= nch concerned issues a final
=A0 =A0 =A0 =A0response?
=A0 =A0 =A0 =A0= [MB3] Yes, per my response above. [/MB3]


=A0 =A0 =A0 =A0 > Al= so, per
=A0 =A0 =A0 =A0 > the comment above you would also have an hi= -entry with an
=A0 =A0 =A0 =A0 > index of =A01.1.1 and that hi-entry would have a Reaso= n header
=A0 =A0 =A0 =A0 > field "escaped" in the hi-target= ed-to-uri. =A0Whereas, neither
=A0 =A0 =A0 =A0 > the 1.2 or 1.3.1 hi-= entry would have a Reason header field in
=A0 =A0 =A0 =A0 > the hi-targeted-to-uri. I don't see that to cause = so much
=A0 =A0 =A0 =A0 > confusion as there might be if it was 1.1.,= 1.2 and 1.3
=A0 =A0 =A0 =A0 > requests had been issued at the same t= ime and the only
=A0 =A0 =A0 =A0 > response comes from 1.2, which has an hi-entry of 1.2.= 1.
=A0 =A0 =A0 =A0 > Thus, the last hi-entry (i.e., 1.3) in the respo= nse isn't one
=A0 =A0 =A0 =A0 > for which the request has receive= d a response. [/MB2]
=A0 =A0 =A0 =A0 =A0 =A0[JRE] I am lost on this one - I don't see the re= levance of
=A0 =A0 =A0 =A01.1.1,
=A0 =A0 =A0 =A0 =A0 =A0which was not= in my example. But anyway, if you answer the
=A0 =A0 =A0 =A0questions=A0 =A0 =A0 =A0 =A0 =A0above, it should help.

=A0 =A0 =A0 =A0[MB3] =A0You had a 1.1.1 in your example under Comment 2= . =A0 Per my
=A0 =A0 =A0 =A0responses above, I was highlighting that onl= y the hi-entries for
=A0 =A0 =A0 =A0which
=A0 =A0 =A0 =A0responses ha= ve been received are added (i.e., I changed your example
=A0 =A0 =A0 =A0such that 1.3 didn't have a response and thus was trying= to
=A0 =A0 =A0 =A0highlight
=A0 =A0 =A0 =A0that it would be confusin= g to have a 1.3 entry since you really
=A0 =A0 =A0 =A0don't
=A0 = =A0 =A0 =A0know what is going to happen with that branch (i.e., it's no= t yet
=A0 =A0 =A0 =A0"complete"). [/MB3]


=A0 =A0 =A0 =A0 =A0= =A0John




=A0 =A0 =A0 =A0________________________________= _______________
=A0 =A0 =A0 =A0sipcore mailing list
=A0 = =A0 =A0 =A0sipcore@ie= tf.org <mailto:sipcore@ietf.org>=20

=A0 =A0 =A0 =A0https://www.ietf.org/mailman/listinfo= /sipcore

=A0 =A0_______________________________________________<= br>=A0 =A0sipcore mailing list
=A0 =A0sipcore@= ietf.org <mailto:sipcore@ietf.org>=20

=A0 =A0https://www.ietf.org/mailman/listinfo/sipcore=



--bcaec53f943dd12e71049ce73608-- From marianne.mohali@orange-ftgroup.com Wed Feb 23 05:29:07 2011 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 2A7503A68B6 for ; Wed, 23 Feb 2011 05:29:07 -0800 (PST) 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 aR5kzAgk0jFd for ; Wed, 23 Feb 2011 05:29:06 -0800 (PST) Received: from r-mail2.rd.francetelecom.com (r-mail2.rd.francetelecom.com [217.108.152.42]) by core3.amsl.com (Postfix) with ESMTP id BB0F43A67EC for ; Wed, 23 Feb 2011 05:29:05 -0800 (PST) Received: from r-mail2.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 3E5D8FC400A; Wed, 23 Feb 2011 14:29:56 +0100 (CET) Received: from ftrdsmtp2.rd.francetelecom.fr (unknown [10.192.128.47]) by r-mail2.rd.francetelecom.com (Postfix) with ESMTP id 3041CFC4003; Wed, 23 Feb 2011 14:29:56 +0100 (CET) Received: from ftrdmel1.rd.francetelecom.fr ([10.192.128.40]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Wed, 23 Feb 2011 14:29:50 +0100 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: Wed, 23 Feb 2011 14:29:49 +0100 Message-ID: In-Reply-To: <4D5D2868.5040308@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] I-D Action:draft-ietf-sipcore-rfc4244bis-03.txt Thread-Index: AcvOqiA4Lq0jCoKeT9K77XcojviI+AEl2SQA References: <20110214151501.27807.33759.idtracker@localhost> <4D5D2868.5040308@cisco.com> From: To: , , X-OriginalArrivalTime: 23 Feb 2011 13:29:50.0575 (UTC) FILETIME=[BF56D7F0:01CBD35D] Subject: Re: [sipcore] I-D Action:draft-ietf-sipcore-rfc4244bis-03.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, 23 Feb 2011 13:29:07 -0000 Hello, Comment 1: I have a first comment about the Tel URI question.=20 By definition it is not possible to have de telURI in History-Info : hi-targeted-to-uri =3D name-addr And per RFC3261 name-addr =3D [ display-name ] LAQUOT addr-spec RAQUOT addr-spec =3D SIP-URI / SIPS-URI / absoluteURI A simple note could be used as a remider. Comment 2: About the "escaped" term, I found the following statements in RFC3261 = and RFC2396.=20 I conclude that a correct terminology for including Privacy and Reason = headers in the hi-targeted-to-uri could be:=20 Privacy and Reason Header fields can be present in the = hi-targeted-to-URI parameter as URI "headers" component described in = RFC3261. They MUST be present in an "escaped" form as stated in RFC2396. = In RFC 2396: "A URI is always in an "escaped" form, since escaping or unescaping a = completed URI might change its semantics." "An escaped octet is encoded as a character triplet, consisting of the = percent character "%" followed by the two hexadecimal digits = representing the octet code." In RFC 3261: "sip:user:password@host:port;uri-parameters?headers" "Note, however, that any characters allowed there that are not allowed = in the user part of the SIP URI MUST be escaped." "Headers fields in the SIP request can be specified with the "?" = mechanism within a URI. The header names and values are encoded in = ampersand separated hname =3D hvalue pairs." headers =3D "?" header *( "&" header ) header =3D hname "=3D" hvalue hname =3D 1*( hnv-unreserved / unreserved / escaped ) hvalue =3D *( hnv-unreserved / unreserved / escaped ) hnv-unreserved =3D "[" / "]" / "/" / "?" / ":" / "+" / "$" unreserved =3D alphanum / mark escaped =3D "%" HEXDIG HEXDIG Best Regards, Marianne > -----Message d'origine----- > De : sipcore-bounces@ietf.org=20 > [mailto:sipcore-bounces@ietf.org] De la part de Paul Kyzivat > Envoy=E9 : jeudi 17 f=E9vrier 2011 14:54 > =C0 : sipcore@ietf.org > Objet : Re: [sipcore] I-D Action:draft-ietf-sipcore-rfc4244bis-03.txt >=20 > I think the use of "escaped" in the sense used in 4244bis has=20 > become informal colloquial usage, and I am probably as guilty=20 > of using it as anyone. But I agree it is problematic as=20 > formal language in a normative document. IMO the wording=20 > changes offered by John are an improvement. >=20 > Thanks, > Paul >=20 > On 2/17/2011 2:24 AM, Elwell, John wrote: > > > > > > > >> -----Original Message----- > >> From: Mary Barnes [mailto:mary.ietf.barnes@gmail.com] > >> Sent: 16 February 2011 22:57 > >> To: Elwell, John > >> Cc: SIPCORE > >> Subject: Re: [sipcore] I-D=20 > >> Action:draft-ietf-sipcore-rfc4244bis-03.txt > >> > >> Responses inline below [MB]. > >> > >> > >> On Wed, Feb 16, 2011 at 2:06 PM, Elwell, John=20 > >> wrote: > >> > >> > >> Mary, > >> =09 > >> In fact what we are doing is placing these header fields in the=20 > >> Headers component of the SIP/SIPS URI - isn't that the=20 > proper way to=20 > >> describe it? I know the escape terminology has been in the=20 > draft for=20 > >> a long time, and if others are happy I guess I can live with it.=20 > >> Perhaps there are precedents in other RFCs. But I am not sure how=20 > >> somebody unfamiliar with this terminology would interpret it. > >> =09 > >> > >> [MB] Yes, we are putting the header fields in the "headers" > >> parameter in the SIP/SIPS URI. So, we can change the wording to=20 > >> reflect such. Again, I have no recollection of the logic=20 > behind using=20 > >> the term escape. We could probably dig through the=20 > archives and see=20 > >> when that was introduced. In looking at some some charts from the=20 > >> IETF-60 discussion of > >> 4244 in its draft for it is quite interesting, as one of=20 > the issues=20 > >> was one that you identified [JRE-7] and the chart states=20 > that "...the=20 > >> Privacy header is added to the request or escaped as part of the=20 > >> targeted-to-uri". I have no issue with changing the wording as you=20 > >> suggest. [/MB] > > [JRE] True, when I submitted earlier comments I was just=20 > going along with what appeared to be the convention. However,=20 > this time something alerted me, so I checked in RFC 3261 and=20 > found that the term "escape" was used with an entirely=20 > different meaning. I think other experts in the WG should=20 > give their opinions - I don't want to force a change if=20 > people are happy with the status quo. > > > >> > >> > >> By the way, what if we have a tel: URI? I don't think=20 > that supports=20 > >> "escaped" header fields. Do our requirements for inserting=20 > "escaped"=20 > >> header fields apply only when the URI is SIP or SIPS? > >> =09 > >> > >> [MB] Correct - the Reason and Privacy header fields can=20 > only be used=20 > >> for SIP or SIPS URIs. Hadriel brought up this issue and=20 > there is text=20 > >> in there with regards to this issue. [/MB] > > [JRE] Yes, and I see now that this is kind of captured. It=20 > is a bit inconsistent, because 9.2 says you MUST escape the=20 > Reason header field - no exceptions. However, if I go back to=20 > section 5 (header field structure), I do find a statement=20 > about transforming a Tel-URI into a SIP/SIPS-URI, but that is=20 > only SHOULD strength. > > > > 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 >=20 From pkyzivat@cisco.com Wed Feb 23 06:01:56 2011 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 CC7B63A68AB for ; Wed, 23 Feb 2011 06:01:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.574 X-Spam-Level: X-Spam-Status: No, score=-110.574 tagged_above=-999 required=5 tests=[AWL=0.025, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 AA1MOi5pSkN1 for ; Wed, 23 Feb 2011 06:01:55 -0800 (PST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id A51F83A689D for ; Wed, 23 Feb 2011 06:01:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pkyzivat@cisco.com; l=920; q=dns/txt; s=iport; t=1298469763; x=1299679363; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=0AqavPIPB04Kh8dS2xDKd5DshPXd1OSJ1M8+WrHU4T0=; b=C4nVqzG2WmzDlCga7dDfRnacAjo/oCIVi6JZEOK+eNXZkqEQLdVi3bNO 5zi4YLx8fUgb7ZC9BDuYHvlRx60706v16qwMftCJE7aMPjEp4Ue8S/9El meRn40Ku6iUQnQBA0Ji6y4mc5hzK2MMEpOG2rNvVqCtfir/Gp/RkxM8VX U=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Al0HAKCiZE1AZnwM/2dsb2JhbACYDI4Nc6A+m3WFXgSFDYcJgzs X-IronPort-AV: E=Sophos;i="4.62,212,1297036800"; d="scan'208";a="218627913" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 23 Feb 2011 14:02:42 +0000 Received: from [161.44.174.114] (dhcp-161-44-174-114.cisco.com [161.44.174.114]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id p1NE2gjh016357; Wed, 23 Feb 2011 14:02:42 GMT Message-ID: <4D651382.9080005@cisco.com> Date: Wed, 23 Feb 2011 09:02:42 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: marianne.mohali@orange-ftgroup.com References: <20110214151501.27807.33759.idtracker@localhost> <4D5D2868.5040308@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: sipcore@ietf.org Subject: Re: [sipcore] I-D Action:draft-ietf-sipcore-rfc4244bis-03.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, 23 Feb 2011 14:01:56 -0000 marianne, (as individual) On 2/23/2011 8:29 AM, marianne.mohali@orange-ftgroup.com wrote: > Hello, > > Comment 1: > I have a first comment about the Tel URI question. > By definition it is not possible to have de telURI in History-Info : > hi-targeted-to-uri = name-addr > And per RFC3261 > name-addr = [ display-name ] LAQUOT addr-spec RAQUOT > addr-spec = SIP-URI / SIPS-URI / absoluteURI In the above, a tel: URI matches absoluteURI. Its exactly this same rule that permits tel: URIs in From/To headers. Anything allowed in From/To is allowed in H-I. That also includes pres:. Of course, absoluteURI also permits some things that *may* be nonsense for H-I, such has http:. (OTOH, URIs such as http: that can't be used as targets of sip requests MAY appear as Contacts in a 3xx. So maybe there is some way they could end up in H-I.) Thanks, Paul Thanks, Paul From marianne.mohali@orange-ftgroup.com Wed Feb 23 06:24:48 2011 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 333953A68D5 for ; Wed, 23 Feb 2011 06:24:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, 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 dyrQexkvAye5 for ; Wed, 23 Feb 2011 06:24:47 -0800 (PST) Received: from p-mail2.rd.francetelecom.com (p-mail2.rd.francetelecom.com [195.101.245.16]) by core3.amsl.com (Postfix) with ESMTP id 06CA23A689D for ; Wed, 23 Feb 2011 06:24:47 -0800 (PST) Received: from p-mail2.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id B027C760002; Wed, 23 Feb 2011 15:30:56 +0100 (CET) Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by p-mail2.rd.francetelecom.com (Postfix) with ESMTP id A7977760001; Wed, 23 Feb 2011 15:30:56 +0100 (CET) Received: from ftrdmel1.rd.francetelecom.fr ([10.192.128.40]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Wed, 23 Feb 2011 15:25:33 +0100 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: Wed, 23 Feb 2011 15:25:32 +0100 Message-ID: In-Reply-To: <4D651382.9080005@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] I-D Action:draft-ietf-sipcore-rfc4244bis-03.txt Thread-Index: AcvTYmnY5/RVXvabSDypdzLaP16JlQAAuzLw References: <20110214151501.27807.33759.idtracker@localhost> <4D5D2868.5040308@cisco.com> <4D651382.9080005@cisco.com> From: To: X-OriginalArrivalTime: 23 Feb 2011 14:25:33.0234 (UTC) FILETIME=[87B82120:01CBD365] Cc: sipcore@ietf.org Subject: Re: [sipcore] I-D Action:draft-ietf-sipcore-rfc4244bis-03.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, 23 Feb 2011 14:24:48 -0000 Ok thanks Paul for this clarification. > -----Message d'origine----- > De : Paul Kyzivat [mailto:pkyzivat@cisco.com]=20 > Envoy=E9 : mercredi 23 f=E9vrier 2011 15:03 > =C0 : MOHALI Marianne RD-CORE-ISS > Cc : mary.ietf.barnes@gmail.com; sipcore@ietf.org;=20 > john.elwell@siemens-enterprise.com > Objet : Re: [sipcore] I-D Action:draft-ietf-sipcore-rfc4244bis-03.txt >=20 > marianne, >=20 > (as individual) >=20 > On 2/23/2011 8:29 AM, marianne.mohali@orange-ftgroup.com wrote: > > Hello, > > > > Comment 1: > > I have a first comment about the Tel URI question. > > By definition it is not possible to have de telURI in History-Info : > > hi-targeted-to-uri =3D name-addr > > And per RFC3261 > > name-addr =3D [ display-name ] LAQUOT addr-spec RAQUOT > > addr-spec =3D SIP-URI / SIPS-URI / absoluteURI >=20 > In the above, a tel: URI matches absoluteURI. >=20 > Its exactly this same rule that permits tel: URIs in From/To headers. > Anything allowed in From/To is allowed in H-I. That also=20 > includes pres:. >=20 > Of course, absoluteURI also permits some things that *may* be=20 > nonsense for H-I, such has http:. >=20 > (OTOH, URIs such as http: that can't be used as targets of=20 > sip requests MAY appear as Contacts in a 3xx. So maybe there=20 > is some way they could end up in H-I.) >=20 > Thanks, > Paul >=20 > Thanks, > Paul >=20 From john.elwell@siemens-enterprise.com Wed Feb 23 12:29:53 2011 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 1DA953A6A57 for ; Wed, 23 Feb 2011 12:29:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.625 X-Spam-Level: X-Spam-Status: No, score=-102.625 tagged_above=-999 required=5 tests=[AWL=-0.026, BAYES_00=-2.599, 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 MIZyqKFCDfkT for ; Wed, 23 Feb 2011 12:29:52 -0800 (PST) Received: from ms01.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id A29CF3A697A for ; Wed, 23 Feb 2011 12:29:51 -0800 (PST) Received: from senmx11-mx ([62.134.46.9] [62.134.46.9]) by ms01.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-3520134; Wed, 23 Feb 2011 21:30:36 +0100 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx11-mx (Server) with ESMTP id 8FB351EB82AE; Wed, 23 Feb 2011 21:30:36 +0100 (CET) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Wed, 23 Feb 2011 21:30:36 +0100 From: "Elwell, John" To: SIPCORE , "Barnes, Mary" Date: Wed, 23 Feb 2011 21:30:35 +0100 Thread-Topic: Proposed rewrite of parts of rfc4424bis Thread-Index: AcvTmIaV4I+knUsrT4iwmKekJrT95A== Message-ID: 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: [sipcore] Proposed rewrite of parts of rfc4424bis 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, 23 Feb 2011 20:29:53 -0000 Based on responses from Mary to my recent questions, I am convinced that pr= ocedures could be documented in a much simpler way. Basically I think we ca= n have common procedures for the different entities (UAC, UAS, Proxy, Redir= ect) - how you behave on receipt of a request, forwarding a request, receip= t of a response or forwarding a response is pretty much independent of the = type of entity. In recent emails I developed a model of what I believe we w= ant to happen. I have tried to capture this model in text in a new section = X, which should occur between sections 8 and 9. Sections 6, 7 and 8 essenti= ally just reference section X. I would like WG opinion as to whether this i= s easier to understand, as well as opinions as to whether it accurately ref= lects the intent of the current I-D. 6. User Agent Handling of the History-Info Header Field A B2BUA MAY adopt the behavior of a proxy (section 7) as an alternative to = adopting the behaviour of a UAS (section 6.2) and the behaviour of a UAC (s= ection 6.1). In behaving as a proxy, a B2BUA will carry forward hi-entries = received in requests at the UAS to requests forwarded by the UAC and will c= arry forward hi-entries received in responses at the UAC to responses forwa= rded by the UAS, subject to privacy considerations. 6.1 User Agent Client (UAC) Behavior When issuing a request, a UAC MUST behave in accordance with X.2 for sendin= g a request. Note that the cache of previous requests will be empty and the= index of the hi-entry added to the sent request will be 1, except where th= e UAC issues a retargeted request as a result of a received response. When = receiving a response, a UAC MUST behave in accordance with X.3. In addition= , if a UAC would like to receive the History-Info header field in responses= , it MUST include in the sent request a Supported header field containing o= ption tag histinfo. 6.2 User Agent Server (UAS) Behaviour. When receiving a request, a UAS MUST behave in accordance with X.1. When se= nding a response other than a 3xx response, a UAS MUST behave in accordance= with X.4. When sending a 3xx response, the UAS MUST behave as a redirect s= erver in accordance with section 8. An application at the UAS can make use = of the cached hi-entries, taking into account the considerations of section= 10. 7. Proxy /Intermediary Handling of the History-Info Header Field The following behaviour is applicable to a proxy or a B2BUA that behaves as= a proxy (see section 6). A proxy / intermediary MUST behave: - in accordance with X.1 when receiving a request; - in accordance with X.2 when sending (forwarding) a request; - in accordance with X.3 when receiving a response; - in accordance with X.4 when sending a response. Sometimes the internal design of a proxy or B2BUA will result in a request = being retargeted twice before the request is forwarded, i.e., it is "sent" = to an internal target, which is resolved by that same entity internally by = retargeting to an external target. A proxy or B2BUA in this case MAY behave= as if the request had actually been sent to the internal target before sen= ding to the external target, thereby generating an hi-entry for that intern= al target, in addition to the hi-entry for the external target. Both hi-ent= ries would then be seen "on the wire" in the resulting request sent downstr= eam and any response sent upstream, subject to privacy considerations. 8. Redirect Server Handling of the History-Info Header Field When receiving a request, a Redirect Server MUST behave in accordance with = X.1. When sending a response, a Redirect Server MUST behave in accordance w= ith X.4 and MUST add an "rc" or "mp" header field parameter to the Contact = header field if either of these parameters is applicable according to 9.4. X. Common Handling of the History-Info Header Field X.1 Receiving a Request When receiving a request, an entity MUST create a cache of hi-entries assoc= iated with that request and include in that cache any hi-entries in the rec= eived request. If the Request-URI of the received request does not match the URI in the la= st hi-entry in the cache, the entity MUST add to the end of the cache an hi= -entry containing that URI as the hi-targeted-to-uri. For the added hi-entr= y, the entity MUST behave in accordance with 9.1 if privacy is required, MU= ST populate the hi-index in accordance with 9.3, and MUST NOT include an "r= c" or "mp" header field parameter. X.2 Sending a Request When sending a request, and entity MUST include all cached hi-entries in th= e request. In addition, the entity MUST include in the request an additiona= l hi-entry containing the Request-URI as the hi-targeted-to-uri but MUST NO= T cache this hi-entry. For the new hi-entry, the entity MUST behave in acco= rdance with 9.1 if privacy is required, MUST populate the hi-index in accor= dance with 9.3, and, if applicable, MUST include in the new hi-entry an "rc= " or "mp" parameter in accordance with 9.4. If the sent request is a direct= result of retargeting to a contact URI received in a 3xx response and the = Contact header field in that response contained an "rc" or "mp" header fiel= d parameter, the entity MUST include the corresponding parameter in the new= hi-entry in accordance with 9.4. X.3 Receiving a response When receiving a response other than 100, an entity MUST add to the cache t= he new hi-entry that was added to the sent request that led to that respons= e (if not already in the cache) and include in that cached hi-entry (whethe= r or not it was already cached) a Reason header field in accordance with 9.= 2 denoting the SIP response code in the response. The entity MUST also add = to the cache any hi-entries in the response that are not already in the cac= he (i.e., any hi-entries added by downstream entities). When adding hi-entr= ies to the cache, the entity MUST maintain hi-entries in ascending order of= index (e.g., 1.2.1 comes after 1.2 but before 1.3). Note that the cache wi= ll not contain hi-entries for requests that have not attracted a non-100 re= sponse, so there can be gaps in the indices (e.g., 1.2 and 1.4 could be pre= sent but 1.3 absent). X.4 Procedures for sending a response When sending a response other than 100, an entity MUST include in the respo= nse all cached hi-entries, with the exception that when the received reques= t contained no hi-entries and no histinfo option tag in the Supported heade= r field, the entity MUST NOT include any hi-entries in the response. I think I have covered most of what was in sections 6, 7 and 8, but I have = left out some explanatory material giving reasons (the simplified procedure= s, in my opinion, don't require so much explanation, or if really needed it= can be done in section 5). The original word count of 1719 is reduced to 956, a significant reduction = arising mainly from avoidance of any duplication and also the loss of some = explanation. However, in my opinion behaviour is specified in a more logica= l way, and in a way that makes it a lot more likely that people will implem= ent this. The question is whether the WG feels this is a worthwhile change = at this late stage. I have not checked section 9 in detail to see whether any slight changes ar= e required to align with this new text. John= From Internet-Drafts@ietf.org Thu Feb 24 18:00:03 2011 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 D5F903A679C; Thu, 24 Feb 2011 18:00:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.567 X-Spam-Level: X-Spam-Status: No, score=-102.567 tagged_above=-999 required=5 tests=[AWL=0.032, BAYES_00=-2.599, 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 njAm4ZZf5n-Q; Thu, 24 Feb 2011 18:00:02 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F03E63A6833; Thu, 24 Feb 2011 18:00:01 -0800 (PST) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.12 Message-ID: <20110225020001.9069.34083.idtracker@localhost> Date: Thu, 24 Feb 2011 18:00:01 -0800 Cc: sipcore@ietf.org Subject: [sipcore] I-D Action:draft-ietf-sipcore-location-conveyance-06.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: Fri, 25 Feb 2011 02:00:04 -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 : Location Conveyance for the Session Initiation Protocol Author(s) : J. Polk, et al. Filename : draft-ietf-sipcore-location-conveyance-06.txt Pages : 29 Date : 2011-02-24 This document defines an extension to the Session Initiation Protocol (SIP) to convey geographic location information from one SIP entity to another SIP entity. The SIP extension covers end-to-end conveyance as well as location-based routing, where SIP intermediaries make routing decisions based upon the location of the Location Target. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sipcore-location-conveyance-06.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-location-conveyance-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-02-24175209.I-D@ietf.org> --NextPart-- From jmpolk@cisco.com Thu Feb 24 18:12:20 2011 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 46A8C3A68D8 for ; Thu, 24 Feb 2011 18:12:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.579 X-Spam-Level: X-Spam-Status: No, score=-110.579 tagged_above=-999 required=5 tests=[AWL=0.020, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 5RJ5S+rM5+eW for ; Thu, 24 Feb 2011 18:12:19 -0800 (PST) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 7B2C33A67A3 for ; Thu, 24 Feb 2011 18:12:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jmpolk@cisco.com; l=723; q=dns/txt; s=iport; t=1298599990; x=1299809590; h=message-id:date:to:from:subject:mime-version; bh=GBNaXnq7iwEGZ1od4Smx6ELIpufgB614e/ThKdF/2gk=; b=NCwyG6diDWx4k/sEj+Hik+bYujaYgtRL6FFp1r1flpvDBV/y1LfMQOp5 FBOTAA1ey4jMaMeFI/Bn230vb7bA/Qn0+CHSTJsP0FO1ylgxRPQlD3oCc gdnagWNPt1qvOtxU2UuAfZPIqn0tHMHMwWYg+xlMxiC8awCSrTjVn+Vbj 0=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Aj8GAL6eZk2rR7H+/2dsb2JhbACYHY4VdKIdm2eDEYJPBIUQ X-IronPort-AV: E=Sophos;i="4.62,221,1297036800"; d="scan'208";a="265180668" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-4.cisco.com with ESMTP; 25 Feb 2011 02:13:10 +0000 Received: from jmpolk-wxp01.cisco.com (rcdn-jmpolk-8711.cisco.com [10.99.80.18]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id p1P2D9Lb029289 for ; Fri, 25 Feb 2011 02:13:10 GMT Message-Id: <201102250213.p1P2D9Lb029289@sj-core-2.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 24 Feb 2011 20:13:08 -0600 To: sipcore@ietf.org From: "James M. Polk" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [sipcore] -06 of Location Conveyance submitted 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, 25 Feb 2011 02:12:20 -0000 SIPCORE I've just posted http://www.ietf.org/internet-drafts/draft-ietf-sipcore-location-conveyance-06.txt The changes from -05 are that the design team decided that instead of the Geolocation header field containing the header parameter "routing-allowed", to create a new header field dedicated to carry this meaning (Geolocation-Routing). This separation of indications forced a new subsection within section 4 to be written, as well as new IANA considerations within section 8 to explain and account for this new header field. Less than 10 other words were changed throughout the doc from -05 I believe, so this header split was the focus of this revision. Comments are appreciated James From john.elwell@siemens-enterprise.com Fri Feb 25 03:10:49 2011 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 9E9983A696E for ; Fri, 25 Feb 2011 03:10:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.622 X-Spam-Level: X-Spam-Status: No, score=-102.622 tagged_above=-999 required=5 tests=[AWL=-0.023, BAYES_00=-2.599, 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 VOSiXa1bNKBm for ; Fri, 25 Feb 2011 03:10:46 -0800 (PST) Received: from ms03.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id 5BF193A696D for ; Fri, 25 Feb 2011 03:10:46 -0800 (PST) Received: from senmx12-mx ([62.134.46.10] [62.134.46.10]) by ms03.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-3533249; Fri, 25 Feb 2011 12:11:19 +0100 Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx12-mx (Server) with ESMTP id 132D823F0278; Fri, 25 Feb 2011 12:11:19 +0100 (CET) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Fri, 25 Feb 2011 12:11:18 +0100 From: "Elwell, John" To: "James M. Polk" , "sipcore@ietf.org" Date: Fri, 25 Feb 2011 12:11:17 +0100 Thread-Topic: [sipcore] -06 of Location Conveyance submitted Thread-Index: AcvUkZshzk9iWxKmT7SljM3MBjP9zgANWseg Message-ID: References: <201102250213.p1P2D9Lb029289@sj-core-2.cisco.com> In-Reply-To: <201102250213.p1P2D9Lb029289@sj-core-2.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 Subject: Re: [sipcore] -06 of Location Conveyance submitted 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, 25 Feb 2011 11:10:49 -0000 James, I reviewed the diffs and the new version does seem to capture all that we d= iscussed during last few weeks. As a general remark, explanations concerning the Geolocation-Routing header= field in 4.2 and 4.2.1 are rather verbose, and it is particularly confusin= g that some text talks about it granting/denying permission to view a locat= ion (at an intermediary) whereas other text talks about it granting/denying= permission to route based on the location. I think there is a significant = difference between the two, and we need to be quite clear what is impacted = by the Geolocation-Routing header field: viewing or just routing. Viewing h= as broader implications, e.g., whether you could include in a log file, whe= ther you can attempt to dereference. I can live with what we have rather th= an delay completion of this important document, but if others share my conc= ern it might be worth trying to clean up the text and fix on a single seman= tic for this header field. Some minor points: 1. "The Geolocation header field can have one or more locationValues. A=20 Geolocation header field MUST have at least one header-value." I think "header-value" should be locationValue.=20 2. "Additionally, the first SIP intermediary to add a locationValue adds it as the last locationValue in the header value. A SIP intermediary that adds a locationValue MUST position it as the last locationValue of the last Geolocation header field of the message." Sounds like there is some repetition here. Perhaps the first sentence shoul= d be deleted. 3. "SIP intermediaries are NOT RECOMMENDED to modify existing=20 locationValue(s), and further not to delete any either." "NOT RECOMMENDED" is not RFC 2119 language. Also the double negative "NOT R= ECOMMNDED.....not to delete" is surely wrong. Also is "not to delete" suppo= sed to be part of the normative statement. I suspect what is intended is: "SIP intermediaries SHOULD NOT modify or delete existing locationValue(s)." 4. "Values other than "yes" or "no" are permitted as a =20 mechanism for future extensions, and should be treated the same as = =20 "no"." Should the last part use RFC 2119 language? 5. "If no Geolocation-Routing header field is present in a SIP request, =20 a SIP intermediary MAY insert this header field with a RECOMMENDED = =20 value of "no" by default." I don't see why we need to recommend no - the SIP intermediary should be at= liberty to choose any policy. Also I don't see why "by default" is applica= ble when inserting this header field - the default applies when it is not p= resent. I think we can delete "with a RECOMMENDED value of "no" by default"= , but if not, we should certainly try to improve the words - it is unclear = to me why both "RECOMMENDED" and "by default" are required. 6. " A Geolocation-Routing header-value is set to "no" has no special =20 security properties, this is at most a request for behavior within = =20 SIP intermediaries. " Could not parse - it seems to contain 3 main verbs. Should it say: "A Geolocation-Routing header-value that is set to "no" has no special =20 security properties and is nothing more than a request for behavior = within =20 SIP intermediaries." 7. "If a Geolocation header field exists=20 (meaning a locationValue is already=20 present), MUST interpret the lack of a Geolocation-Routing header field by=20 default as if there were one present=20 and the header-value is set to "no"." There is no subject before "MUST". Perhaps it should say "a SIP intermediar= y MUST". 8. "8.2 IANA Registration for the SIP Geolocation Header Field " This should be "Geolocation-Routing", not "Geolocation". John > -----Original Message----- > From: sipcore-bounces@ietf.org=20 > [mailto:sipcore-bounces@ietf.org] On Behalf Of James M. Polk > Sent: 25 February 2011 02:13 > To: sipcore@ietf.org > Subject: [sipcore] -06 of Location Conveyance submitted >=20 > SIPCORE >=20 > I've just posted > http://www.ietf.org/internet-drafts/draft-ietf-sipcore-locatio > n-conveyance-06.txt >=20 > The changes from -05 are that the design team decided that instead of=20 > the Geolocation header field containing the header parameter=20 > "routing-allowed", to create a new header field dedicated to carry=20 > this meaning (Geolocation-Routing). >=20 > This separation of indications forced a new subsection within section=20 > 4 to be written, as well as new IANA considerations within section 8=20 > to explain and account for this new header field. >=20 > Less than 10 other words were changed throughout the doc from -05 I=20 > believe, so this header split was the focus of this revision. >=20 > Comments are appreciated >=20 > James >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > = From pkyzivat@cisco.com Fri Feb 25 16:09:18 2011 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 E24813A6A84 for ; Fri, 25 Feb 2011 16:09:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.58 X-Spam-Level: X-Spam-Status: No, score=-110.58 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 0O35vG5jqESc for ; Fri, 25 Feb 2011 16:09:17 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id B8A703A6A7F for ; Fri, 25 Feb 2011 16:09:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pkyzivat@cisco.com; l=2046; q=dns/txt; s=iport; t=1298679011; x=1299888611; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=ClEbGky9hNSoVyF619zDNiLmh8j226moorMGczYk5jo=; b=Gv6zLcyhWRf77RWJ01aI9W/1Vl4ZjqJ8OsDr/kNy9xvlXSMd9QcCDDzl odoPrLh98oZdb8YKMc85FThNJU7wLbgDRsouCb8Msa5X4MPSRKI9Cdzzl /Yjeqc619S8mzRFi9iWVT/XsMTtAf+umkq5MfP7X4s7qeWWzVaS9n+6// U=; X-IronPort-AV: E=Sophos;i="4.62,229,1297036800"; d="scan'208";a="220540972" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 26 Feb 2011 00:10:11 +0000 Received: from [161.44.174.114] (dhcp-161-44-174-114.cisco.com [161.44.174.114]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id p1Q0AAPG000194; Sat, 26 Feb 2011 00:10:10 GMT Message-ID: <4D6844E2.2020902@cisco.com> Date: Fri, 25 Feb 2011 19:10:10 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: "James M. Polk (E-mail)" , SIPCORE References: <20110225020001.9069.34083.idtracker@localhost> In-Reply-To: <20110225020001.9069.34083.idtracker@localhost> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [sipcore] I-D Action:draft-ietf-sipcore-location-conveyance-06.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: Sat, 26 Feb 2011 00:09:19 -0000 James, A few things... Section 4.1: Additionally, the first SIP intermediary to add a locationValue adds it as the last locationValue in the header value. A SIP intermediary that adds a locationValue MUST position it as the last locationValue of the last Geolocation header field of the message. John E already called this out, and I agree. The first sentence ("Additionally...header value.") should be removed. The subsequent sentence covers all that and more. (There is nothing special about the *first* intermediary to add locationValue.) In the same section: This document defines the Geolocation header field as valid in the following SIP requests: INVITE [RFC3261], REGISTER [RFC3261], OPTIONS [RFC3261], BYE [RFC3261], UPDATE [RFC3311], INFO [RFC2976], MESSAGE [RFC3428], REFER [RFC3515], SUBSCRIBE [RFC3265], NOTIFY [RFC3265], PUBLISH [RFC3903], PRACK [RFC3262] This isn't new, and maybe it came up before (I don't recall), but was there a reason why PRACK is in this list? I can't think of a good reason to put Geoloc info in PRACK, and PRACK is a message that really should not be rejected. Geoloc info provides another potential reason why a recipient might find a need to reject it. Unless there is some history on this point, and particular reason for including PRACK, I propose that it be removed from the list. Section 4.4: message-header /= Geolocation-Error-header ; (message-header from 3261) Geolocation-Error = "Geolocation-Error" HCOLON locationErrorValue The name used in the two statements is not consistent. Change the first: message-header /= Geolocation-Error ; (message-header from 3261) Section 8: I don't see anything to register the Geolocation-Error header. Did that get missed up till now? Thanks, Paul From yves@zioup.com Sat Feb 26 07:25:46 2011 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 640CF3A6924 for ; Sat, 26 Feb 2011 07:25:46 -0800 (PST) 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 vLLoNaEeHq6l for ; Sat, 26 Feb 2011 07:25:45 -0800 (PST) Received: from idcmail-mo2no.shaw.ca (idcmail-mo2no.shaw.ca [64.59.134.9]) by core3.amsl.com (Postfix) with ESMTP id 65BAD3A687C for ; Sat, 26 Feb 2011 07:25:45 -0800 (PST) Received: from pd5ml2no-ssvc.prod.shaw.ca ([10.0.153.164]) by pd7mo1no-svcs.prod.shaw.ca with ESMTP; 26 Feb 2011 08:24:24 -0700 X-Cloudmark-SP-Filtered: true X-Cloudmark-SP-Result: v=1.1 cv=dyVpuHYQJROgCHwBBw1H+I+7e1rgZIKdHwrI0HSbuo4= c=1 sm=1 a=BLceEmwcHowA:10 a=IkcTkHD0fZMA:10 a=8hTzNagTgvvl8qkcNRYjZA==:17 a=J6b0bBEkAAAA:8 a=B6fndb26AAAA:8 a=OmPMjHJhuRdnaKz-1eIA:9 a=JLjTpZ5YAO7xeH_7kpwA:7 a=CZMRjJKDwa1kw1DkNzZXA9jqMBMA:4 a=QEXdDO2ut3YA:10 a=HpAAvcLHHh0Zw7uRqdWCyQ==:117 Received: from unknown (HELO home.zioup.com) ([68.147.228.171]) by pd5ml2no-dmz.prod.shaw.ca with ESMTP; 26 Feb 2011 08:24:24 -0700 Received: from [192.168.2.173] (aristotle.zioup.net [192.168.2.173]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by home.zioup.com (Postfix) with ESMTPSA id 52D06A02DF for ; Sat, 26 Feb 2011 08:24:24 -0700 (MST) Message-ID: <4D691B28.20702@zioup.com> Date: Sat, 26 Feb 2011 08:24:24 -0700 From: Yves Dorfsman User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.13) Gecko/20101208 Thunderbird/3.1.7 MIME-Version: 1.0 To: sipcore@ietf.org Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: [sipcore] REGISTER, Contact:* 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: Sat, 26 Feb 2011 15:25:46 -0000 Hi, I'd like a clarification. RFC3261, section 10.2.2, page 60 The REGISTER-specific Contact header field value of "*" applies to all registrations, but it MUST NOT be used unless the Expires header field is present with a value of "0". Use of the "*" Contact header field value allows a registering UA to remove all bindings associated with an address-of-record without knowing their precise values. Does "all bindings" here means all bindings registered by that particular UA, or absolutely all bindings with that AOR? In section 10.2.4, the rfc says: previously established. A UA SHOULD NOT refresh bindings set up by other UAs. If two UAs register with the same registrar at the same time (I'm not sure why one would do that, but there is nothing in the RFC preventing it), if one issues a REGISTER, Contact:*, expires:0, should that cancel all bindings from both UAs? I've noticed a lot of UAs out there issue a "de-registration" like this when you close them. Thanks. -- Yves. http://www.SollerS.ca/ http://blog.zioup.org/ From adam@nostrum.com Sat Feb 26 14:47:33 2011 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 B36293A696D for ; Sat, 26 Feb 2011 14:47:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, 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 yN9eLJY39sLp for ; Sat, 26 Feb 2011 14:47:32 -0800 (PST) Received: from nostrum.com (shaman.nostrum.com [72.232.179.90]) by core3.amsl.com (Postfix) with ESMTP id 5EB1A3A6968 for ; Sat, 26 Feb 2011 14:47:32 -0800 (PST) Received: from hydra-3.local (99-152-144-32.lightspeed.dllstx.sbcglobal.net [99.152.144.32]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id p1QMklq4011672 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Sat, 26 Feb 2011 16:47:00 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <4D6982D7.4030503@nostrum.com> Date: Sat, 26 Feb 2011 16:46:47 -0600 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Yves Dorfsman References: <4D691B28.20702@zioup.com> In-Reply-To: <4D691B28.20702@zioup.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 99.152.144.32 is authenticated by a trusted mechanism) Cc: sipcore@ietf.org Subject: Re: [sipcore] REGISTER, Contact:* X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: SIP Implementors List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 26 Feb 2011 22:47:33 -0000 This really is more a question for the sip-implementors mailing list. See https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors The short answer to your question is that it removes all binding from the AOR, regardless of which UA registered them. The UAs you speak of -- the ones that mechanically destroy all AOR bindings when they close -- are misbehaving. Please send any follow-ups to the sip-implementors list. /a On 2/26/11 09:24, Feb 26, Yves Dorfsman wrote: > Hi, > > I'd like a clarification. > > RFC3261, section 10.2.2, page 60 > > The REGISTER-specific Contact header field value of "*" applies to > all registrations, but it MUST NOT be used unless the Expires header > field is present with a value of "0". > > Use of the "*" Contact header field value allows a registering UA > to remove all bindings associated with an address-of-record > without knowing their precise values. > > > Does "all bindings" here means all bindings registered by that > particular UA, or absolutely all bindings with that AOR? > > > In section 10.2.4, the rfc says: > previously established. A UA SHOULD NOT refresh bindings set up by > other UAs. > > If two UAs register with the same registrar at the same time (I'm not > sure why one would do that, but there is nothing in the RFC preventing > it), if one issues a REGISTER, Contact:*, expires:0, should that > cancel all bindings from both UAs? I've noticed a lot of UAs out there > issue a "de-registration" like this when you close them. > > Thanks. > From christer.holmberg@ericsson.com Sun Feb 27 13:26:02 2011 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 2FCDC3A694E for ; Sun, 27 Feb 2011 13:26:02 -0800 (PST) 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 xTxmq25gyUSg for ; Sun, 27 Feb 2011 13:26:01 -0800 (PST) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id E6A9B3A68B1 for ; Sun, 27 Feb 2011 13:26:00 -0800 (PST) X-AuditID: c1b4fb39-b7c6dae0000023f2-41-4d6ac1a248ae Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 25.3D.09202.2A1CA6D4; Sun, 27 Feb 2011 22:26:58 +0100 (CET) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.30]) by esessmw0197.eemea.ericsson.se ([153.88.115.87]) with mapi; Sun, 27 Feb 2011 22:26:58 +0100 From: Christer Holmberg To: Paul Kyzivat , "James M. Polk (E-mail)" , SIPCORE Date: Sun, 27 Feb 2011 22:26:57 +0100 Thread-Topic: [sipcore] I-D Action:draft-ietf-sipcore-location-conveyance-06.txt Thread-Index: AQHL1sUQsuGD0JuIDkuSacsH41+O6Q== Message-ID: <7F2072F1E0DE894DA4B517B93C6A05851948D7E029@ESESSCMS0356.eemea.ericsson.se> 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-Brightmail-Tracker: AAAAAA== Subject: Re: [sipcore] I-D Action:draft-ietf-sipcore-location-conveyance-06.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: Sun, 27 Feb 2011 21:26:02 -0000 Hi, I guess we should use RFC 6086 for INFO, as it obsoletes RFC 2976. I guess RFC 3265 (and potentially RFC 3262) might also going to be obsolete= d at some point, due to 3265bis, but I guess we don't want to wait for that= . Regards, Christer ________________________________________ From: sipcore-bounces@ietf.org [sipcore-bounces@ietf.org] On Behalf Of Paul= Kyzivat [pkyzivat@cisco.com] Sent: Saturday, February 26, 2011 2:10 AM To: James M. Polk (E-mail); SIPCORE Subject: Re: [sipcore] I-D Action:draft-ietf-sipcore-location-conveyan= ce-06.txt James, A few things... Section 4.1: Additionally, the first SIP intermediary to add a locationValue adds it as the last locationValue in the header value. A SIP intermediary that adds a locationValue MUST position it as the last locationValue of the last Geolocation header field of the message. John E already called this out, and I agree. The first sentence ("Additionally...header value.") should be removed. The subsequent sentence covers all that and more. (There is nothing special about the *first* intermediary to add locationValue.) In the same section: This document defines the Geolocation header field as valid in the following SIP requests: INVITE [RFC3261], REGISTER [RFC3261], OPTIONS [RFC3261], BYE [RFC3261], UPDATE [RFC3311], INFO [RFC2976], MESSAGE [RFC3428], REFER [RFC3515], SUBSCRIBE [RFC3265], NOTIFY [RFC3265], PUBLISH [RFC3903], PRACK [RFC3262] This isn't new, and maybe it came up before (I don't recall), but was there a reason why PRACK is in this list? I can't think of a good reason to put Geoloc info in PRACK, and PRACK is a message that really should not be rejected. Geoloc info provides another potential reason why a recipient might find a need to reject it. Unless there is some history on this point, and particular reason for including PRACK, I propose that it be removed from the list. Section 4.4: message-header /=3D Geolocation-Error-header ; (message-header from 3261) Geolocation-Error =3D "Geolocation-Error" HCOLON locationErrorValue The name used in the two statements is not consistent. Change the first: message-header /=3D Geolocation-Error ; (message-header from 3261) Section 8: I don't see anything to register the Geolocation-Error header. Did that get missed up till now? Thanks, Paul _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore= From marianne.mohali@orange-ftgroup.com Mon Feb 28 01:58:30 2011 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 6BEC53A6903 for ; Mon, 28 Feb 2011 01:58:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, 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 sjx59t-CCtrl for ; Mon, 28 Feb 2011 01:58:29 -0800 (PST) Received: from p-mail2.rd.francetelecom.com (p-mail2.rd.francetelecom.com [195.101.245.16]) by core3.amsl.com (Postfix) with ESMTP id 1A0183A69DA for ; Mon, 28 Feb 2011 01:58:29 -0800 (PST) Received: from p-mail2.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id AF5D5760005; Mon, 28 Feb 2011 11:04:56 +0100 (CET) Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by p-mail2.rd.francetelecom.com (Postfix) with ESMTP id 96C47760001; Mon, 28 Feb 2011 11:04:56 +0100 (CET) Received: from ftrdmel1.rd.francetelecom.fr ([10.192.128.40]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Mon, 28 Feb 2011 10:59:28 +0100 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: Mon, 28 Feb 2011 10:59:25 +0100 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] Reason syntax error in draft-ietf-sipcore-rfc4244bis-03 Thread-Index: AcvMXbxTOxlWdcnGTS2j2Y1ad20k6QKzCu+Q References: <20110214151501.27807.33759.idtracker@localhost> From: To: , X-OriginalArrivalTime: 28 Feb 2011 09:59:28.0038 (UTC) FILETIME=[2FC94C60:01CBD72E] Subject: [sipcore] Reason syntax error in draft-ietf-sipcore-rfc4244bis-03 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, 28 Feb 2011 09:58:30 -0000 Hi Mary, In the draft, there is a mistake in the Reason syntax used. The Reason header is written with a "=3D" instead of a ":" (HCOLON) = after the header name, as defined in RFC3326.=20 Regards, Marianne ________________________________ De : sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] De la = part de Mary Barnes Envoy=E9 : lundi 14 f=E9vrier 2011 16:42 =C0 : SIPCORE Objet : Re: [sipcore] I-D Action:draft-ietf-sipcore-rfc4244bis-03.txt =09 =09 Apologies for the very lengthy delay in getting the document updated. =20 The changes are quite extensive based on all the feedback and include = the following:=20 1) Lots of editorial: a) Reorganized sections similar to the RFC 4244 order - i.e., introduce = header field parameters and syntax first, then describe how the = functional entities use the header. This removes redundant (and often = inconsistent) text describing the parameters. b) Expanded use of "header" to "header field" c) More precision in terms of "escaping" of the Privacy and Reason = headers in the hi-targeted-to-uri (versus "adding"/"setting"/etc. them = to the hi-entry). d) Consistent use of parameter names (i.e., hi-entry versus entry, = hi-target versus target, etc.) e) Moved item 6 in the Index section to the section on Response = handling f) Removed last remaining vestiges of inline references to = requirements. 2) Clarifications of functionality/applicability including: a) which messages may contain History-Info b) removing security text with regards to being able to figure out if = there are missing entries when using TLS (issue #44) c) More complete information on the new header field parameters as they = relate to the hi-target parameter. =20 d) Changed wording from passive to active for normative statements in = many cases and removed superfluous normative language.=20 3) Rewrite of the Privacy section to address issues and splitting into = the setting of the Privacy header fields and the processing/application = of the privacy header field priv-values.=20 4) Rewrite of the Reason header field section - simplifying the text = and adding back the RFC 4244 text with regards to the use of the Reason = header field in cases of internal retargeting.=20 I did attempt to cover all the comments, but since alot of the relevant = text changed, it's possible that I missed some comments. However, = we're hoping that folks will find this version to be easier to follow.=20 Regards, Mary.=20 On Mon, Feb 14, 2011 at 9:15 AM, wrote: =09 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. =09 =09 Title : An Extension to the Session Initiation = Protocol (SIP) for Request History Information Author(s) : M. Barnes, et al. Filename : draft-ietf-sipcore-rfc4244bis-03.txt Pages : 48 Date : 2011-02-14 =09 This document defines a standard mechanism for capturing the history information associated with a Session Initiation Protocol (SIP) request. This capability enables many enhanced services by providing the information as to how and why a SIP request arrives at a specific application or user. This document defines an optional SIP header field, History-Info, for capturing the history information in requests. The document also defines SIP header field parameters for the History-Info and Contact header fields to tag the method by which the target of a request is determined. In addition, this document defines a value for the Privacy header field specific to the History- Info header field. =09 A URL for this Internet-Draft is: = http://www.ietf.org/internet-drafts/draft-ietf-sipcore-rfc4244bis-03.txt =09 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ =09 Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. =09 =09 _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore =09 =09 From brett@broadsoft.com Mon Feb 28 03:01:49 2011 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 CB0383A6B16 for ; Mon, 28 Feb 2011 03:01:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.677 X-Spam-Level: X-Spam-Status: No, score=-1.677 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_NET=0.611, HOST_MISMATCH_COM=0.311] 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 ZUGtHitV8a3T for ; Mon, 28 Feb 2011 03:01:49 -0800 (PST) Received: from smtp-out01.seaservers.net (smtpedge.partnerhosted.com [173.225.22.21]) by core3.amsl.com (Postfix) with ESMTP id 2DB073A68EC for ; Mon, 28 Feb 2011 03:01:49 -0800 (PST) Received: from EXMBXCLUS01.citservers.local ([fe80::a488:d1ec:a706:3a6d]) by CASUMHUB02.citservers.local ([::1]) with mapi; Mon, 28 Feb 2011 03:02:49 -0800 From: Brett Tate To: "marianne.mohali@orange-ftgroup.com" Date: Mon, 28 Feb 2011 03:00:18 -0800 Thread-Topic: [sipcore] Reason syntax error in draft-ietf-sipcore-rfc4244bis-03 Thread-Index: AcvMXbxTOxlWdcnGTS2j2Y1ad20k6QKzCu+QAAK5eLA= Message-ID: <7FF1E5E16911C54BB2D57D4C4A2ED35A074AD4F1C7@EXMBXCLUS01.citservers.local> References: <20110214151501.27807.33759.idtracker@localhost> 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 Cc: "sipcore@ietf.org" Subject: Re: [sipcore] Reason syntax error in draft-ietf-sipcore-rfc4244bis-03 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, 28 Feb 2011 11:01:49 -0000 The use of "=3D" (instead of ":") is correct for embedding headers in a SIP= -URI. The following is the "headers" ABNF from RFC 3261. SIP-URI =3D "sip:" [ userinfo ] hostport uri-parameters [ headers ] headers =3D "?" header *( "&" header ) header =3D hname "=3D" hvalue > -----Original Message----- > From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On > Behalf Of marianne.mohali@orange-ftgroup.com > Sent: Monday, February 28, 2011 4:59 AM > To: mary.ietf.barnes@gmail.com; sipcore@ietf.org > Subject: [sipcore] Reason syntax error in draft-ietf-sipcore- > rfc4244bis-03 >=20 > Hi Mary, >=20 > In the draft, there is a mistake in the Reason syntax used. > The Reason header is written with a "=3D" instead of a ":" (HCOLON) after > the header name, as defined in RFC3326. >=20 > Regards, > Marianne From pkyzivat@cisco.com Mon Feb 28 06:05:40 2011 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 ED6033A6A06 for ; Mon, 28 Feb 2011 06:05:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.58 X-Spam-Level: X-Spam-Status: No, score=-110.58 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 HdOte-aCKfin for ; Mon, 28 Feb 2011 06:05:39 -0800 (PST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 467A13A69AF for ; Mon, 28 Feb 2011 06:05:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pkyzivat@cisco.com; l=3295; q=dns/txt; s=iport; t=1298901998; x=1300111598; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=Dh852JvD5D0xc8vvZOvOfduSk608qCu7odSAH2khdP4=; b=UlwRgEoeRDY4OGrH8616J4SsnjgpJJWFwqPVX3ne162qgSshe9ouw9Yd jzktXDOm88cqq5S14j7E6FmsPsDFa38Y4sBVfwHLRrFwdXay8n/oX9ZPW fyPdh4AQuQoZV/YIwJClSjebE38nrM6jFzSfEWwP8pm/XDuz+utBwOwKv c=; X-IronPort-AV: E=Sophos;i="4.62,239,1297036800"; d="scan'208";a="220707163" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 28 Feb 2011 14:06:37 +0000 Received: from [161.44.174.114] (dhcp-161-44-174-114.cisco.com [161.44.174.114]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id p1SE6bFo014260; Mon, 28 Feb 2011 14:06:37 GMT Message-ID: <4D6BABED.6070908@cisco.com> Date: Mon, 28 Feb 2011 09:06:37 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: Christer Holmberg References: <7F2072F1E0DE894DA4B517B93C6A05851948D7E029@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05851948D7E029@ESESSCMS0356.eemea.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: SIPCORE Subject: Re: [sipcore] I-D Action:draft-ietf-sipcore-location-conveyance-06.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, 28 Feb 2011 14:05:41 -0000 On 2/27/2011 4:26 PM, Christer Holmberg wrote: > Hi, > > I guess we should use RFC 6086 for INFO, as it obsoletes RFC 2976. Which one makes no difference to this draft, but yes, it makes sense to reference the latest revision. > I guess RFC 3265 (and potentially RFC 3262) might also going to be obsoleted at some point, due to 3265bis, but I guess we don't want to wait for that. Again it makes no difference to the substance of this draft. And in this case, referencing the bis would make a dependency, which is not a good thing in this case. So these refs should be left as is. Thanks, Paul > Regards, > > Christer > > ________________________________________ > From: sipcore-bounces@ietf.org [sipcore-bounces@ietf.org] On Behalf Of Paul Kyzivat [pkyzivat@cisco.com] > Sent: Saturday, February 26, 2011 2:10 AM > To: James M. Polk (E-mail); SIPCORE > Subject: Re: [sipcore] I-D Action:draft-ietf-sipcore-location-conveyance-06.txt > > James, > > A few things... > > Section 4.1: > > Additionally, the first SIP intermediary to add a locationValue adds > it as the last locationValue in the header value. A SIP intermediary > that adds a locationValue MUST position it as the last locationValue > of the last Geolocation header field of the message. > > John E already called this out, and I agree. > The first sentence ("Additionally...header value.") should be removed. > The subsequent sentence covers all that and more. > > (There is nothing special about the *first* intermediary to add > locationValue.) > > In the same section: > > This document defines the Geolocation header field as valid in the > following SIP requests: > > INVITE [RFC3261], REGISTER [RFC3261], > OPTIONS [RFC3261], BYE [RFC3261], > UPDATE [RFC3311], INFO [RFC2976], > MESSAGE [RFC3428], REFER [RFC3515], > SUBSCRIBE [RFC3265], NOTIFY [RFC3265], > PUBLISH [RFC3903], PRACK [RFC3262] > > This isn't new, and maybe it came up before (I don't recall), but was > there a reason why PRACK is in this list? I can't think of a good reason > to put Geoloc info in PRACK, and PRACK is a message that really should > not be rejected. Geoloc info provides another potential reason why a > recipient might find a need to reject it. > > Unless there is some history on this point, and particular reason for > including PRACK, I propose that it be removed from the list. > > Section 4.4: > > message-header /= Geolocation-Error-header ; > (message-header from 3261) > Geolocation-Error = "Geolocation-Error" HCOLON > locationErrorValue > > > The name used in the two statements is not consistent. Change the first: > > message-header /= Geolocation-Error ; (message-header from 3261) > > Section 8: > > I don't see anything to register the Geolocation-Error header. > Did that get missed up till now? > > Thanks, > Paul > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From marianne.mohali@orange-ftgroup.com Mon Feb 28 06:31:32 2011 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 6CD453A6A06 for ; Mon, 28 Feb 2011 06:31:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, 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 gjCGETyeEEIB for ; Mon, 28 Feb 2011 06:31:31 -0800 (PST) Received: from p-mail2.rd.francetelecom.com (p-mail2.rd.francetelecom.com [195.101.245.16]) by core3.amsl.com (Postfix) with ESMTP id 5C8CB3A6940 for ; Mon, 28 Feb 2011 06:31:31 -0800 (PST) Received: from p-mail2.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id DC8BC760003; Mon, 28 Feb 2011 15:37:59 +0100 (CET) Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by p-mail2.rd.francetelecom.com (Postfix) with ESMTP id D5A6E760001; Mon, 28 Feb 2011 15:37:59 +0100 (CET) Received: from ftrdmel1.rd.francetelecom.fr ([10.192.128.40]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Mon, 28 Feb 2011 15:32:30 +0100 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: Mon, 28 Feb 2011 15:32:28 +0100 Message-ID: In-Reply-To: <7FF1E5E16911C54BB2D57D4C4A2ED35A074AD4F1C7@EXMBXCLUS01.citservers.local> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] Reason syntax error in draft-ietf-sipcore-rfc4244bis-03 Thread-Index: AcvMXbxTOxlWdcnGTS2j2Y1ad20k6QKzCu+QAAK5eLAAB6zI4A== References: <20110214151501.27807.33759.idtracker@localhost> <7FF1E5E16911C54BB2D57D4C4A2ED35A074AD4F1C7@EXMBXCLUS01.citservers.local> From: To: X-OriginalArrivalTime: 28 Feb 2011 14:32:30.0915 (UTC) FILETIME=[54BDF130:01CBD754] Cc: sipcore@ietf.org Subject: Re: [sipcore] Reason syntax error in draft-ietf-sipcore-rfc4244bis-03 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, 28 Feb 2011 14:31:32 -0000 Hi Brett, I saw this text but I though that the header's syntax had precedence. Thank you ! Marianne=20 > -----Message d'origine----- > De : Brett Tate [mailto:brett@broadsoft.com]=20 > Envoy=E9 : lundi 28 f=E9vrier 2011 12:00 > =C0 : MOHALI Marianne RD-CORE-ISS > Cc : sipcore@ietf.org > Objet : RE: [sipcore] Reason syntax error in=20 > draft-ietf-sipcore-rfc4244bis-03 >=20 > The use of "=3D" (instead of ":") is correct for embedding=20 > headers in a SIP-URI. The following is the "headers" ABNF=20 > from RFC 3261. >=20 > SIP-URI =3D "sip:" [ userinfo ] hostport uri-parameters [=20 > headers ] headers =3D "?" header *( "&" header ) header =3D =20 > hname "=3D" hvalue >=20 > > -----Original Message----- > > From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On=20 > > Behalf Of marianne.mohali@orange-ftgroup.com > > Sent: Monday, February 28, 2011 4:59 AM > > To: mary.ietf.barnes@gmail.com; sipcore@ietf.org > > Subject: [sipcore] Reason syntax error in draft-ietf-sipcore- > > rfc4244bis-03 > >=20 > > Hi Mary, > >=20 > > In the draft, there is a mistake in the Reason syntax used. > > The Reason header is written with a "=3D" instead of a ":" (HCOLON)=20 > > after the header name, as defined in RFC3326. > >=20 > > Regards, > > Marianne >=20 >=20 From marianne.mohali@orange-ftgroup.com Mon Feb 28 06:57:57 2011 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 89A0B3A69D2 for ; Mon, 28 Feb 2011 06:57:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[AWL=-1.150, BAYES_00=-2.599, HELO_EQ_FR=0.35, MANGLED_EXTNSN=2.3, 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 22kQkfP8NdK0 for ; Mon, 28 Feb 2011 06:57:56 -0800 (PST) Received: from p-mail1.rd.francetelecom.com (p-mail1.rd.francetelecom.com [195.101.245.15]) by core3.amsl.com (Postfix) with ESMTP id 61A633A6940 for ; Mon, 28 Feb 2011 06:57:56 -0800 (PST) Received: from p-mail1.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 0F4B08B8003 for ; Mon, 28 Feb 2011 15:59:23 +0100 (CET) Received: from ftrdsmtp2.rd.francetelecom.fr (unknown [10.192.128.47]) by p-mail1.rd.francetelecom.com (Postfix) with ESMTP id BE9A08B8002 for ; Mon, 28 Feb 2011 15:59:22 +0100 (CET) Received: from ftrdmel1.rd.francetelecom.fr ([10.192.128.40]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Mon, 28 Feb 2011 15:58:55 +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: Mon, 28 Feb 2011 15:58:55 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] I-D Action: draft-mohali-sipcore-reason-extension-application-01 Thread-Index: AcvUO18D6aIYRUrFRvKpJzR5RTTfrgAL911g From: To: X-OriginalArrivalTime: 28 Feb 2011 14:58:55.0943 (UTC) FILETIME=[057E0570:01CBD758] Subject: [sipcore] I-D Action: draft-mohali-sipcore-reason-extension-application-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: Mon, 28 Feb 2011 14:57:57 -0000 Hello, Here is the new version of the draft. Main changes are following: - More details about the registration procedure for new values - Clearer text in section 3.2 - Add of Public and Private status for registered values. =20 - Add of a range for cause values registration=20 Best Regards, Marianne Mohali -----Message d'origine----- Objet : New Version Notification for draft-mohali-sipcore-reason-extension-application-01=20 A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Extending the Session Initiation Protocol (SIP) Reason Header for Applications Author(s) : M. Mohali, B. Chatras Filename : draft-mohali-sipcore-reason-extension-application-01.txt Pages : 10 Date : 2011-02-24 This document defines a new protocol value "Application" for the Reason Header field and a new IANA Registry for registering application types. This new value enables signaling that a request or response has been issued as a result of a decision made by a particular type of application or that an initial request has been retargeted as a result of an application decision. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-mohali-sipcore-reason-extensio n-application-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. _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From dworley@avaya.com Mon Feb 28 08:26:41 2011 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 3A0153A69F9 for ; Mon, 28 Feb 2011 08:26:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.545 X-Spam-Level: X-Spam-Status: No, score=-102.545 tagged_above=-999 required=5 tests=[AWL=0.054, BAYES_00=-2.599, 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 eH3ELfvnezAX for ; Mon, 28 Feb 2011 08:26:40 -0800 (PST) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by core3.amsl.com (Postfix) with ESMTP id 543E63A693B for ; Mon, 28 Feb 2011 08:26:40 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAK5ba02HCzI1/2dsb2JhbACmR3SjXAKYd4VhBIUQimU X-IronPort-AV: E=Sophos;i="4.62,240,1297054800"; d="scan'208";a="267036419" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by co300216-co-outbound.net.avaya.com with ESMTP; 28 Feb 2011 11:27:40 -0500 X-IronPort-AV: E=Sophos;i="4.62,240,1297054800"; d="scan'208";a="607297712" Received: from dc-us1hcex1.us1.avaya.com (HELO DC-US1HCEX1.global.avaya.com) ([135.11.52.20]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 28 Feb 2011 11:27:40 -0500 Received: from DC-US1MBEX4.global.avaya.com ([169.254.1.187]) by DC-US1HCEX1.global.avaya.com ([2002:870b:3414::870b:3414]) with mapi; Mon, 28 Feb 2011 11:27:39 -0500 From: "Worley, Dale R (Dale)" To: Yves Dorfsman , "sipcore@ietf.org" Date: Mon, 28 Feb 2011 11:26:53 -0500 Thread-Topic: [sipcore] REGISTER, Contact:* Thread-Index: AcvVyZUJ4GwYgqYbRaypPHKl10KCaQBmrpdA Message-ID: References: <4D691B28.20702@zioup.com> In-Reply-To: <4D691B28.20702@zioup.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] REGISTER, Contact:* 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, 28 Feb 2011 16:26:41 -0000 ________________________________________ From: sipcore-bounces@ietf.org [sipcore-bounces@ietf.org] On Behalf Of Yves= Dorfsman [yves@zioup.com] If two UAs register with the same registrar at the same time (I'm not sure = why one would do that, but there is nothing in the RFC preventing it), _______________________________________________ Have you never seen an extension number that rings on two different phones? Dale From jmpolk@cisco.com Mon Feb 28 11:54:20 2011 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 095A73A6C4F for ; Mon, 28 Feb 2011 11:54:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 aYUhyjPHfRBE for ; Mon, 28 Feb 2011 11:54:18 -0800 (PST) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 4AF873A6A24 for ; Mon, 28 Feb 2011 11:54:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=jmpolk@cisco.com; l=3867; q=dns/txt; s=iport; t=1298922919; x=1300132519; h=message-id:date:to:from:subject:cc:in-reply-to: references:mime-version; bh=ZwZgfWXbPPqA2+TGeb6iOCkNjz2yxhwNlAdK+PlKJJw=; b=mVJeJijjVEz6otiukLQdniUSX/mxB8MyO+LZx/83g5WTTLUsaBhVFQsG FHHgQFIPWifiZUGGpFCOdtORqXCpPExNGyLN1zWJ6btdsnH9PDDG/wmue Mdsh+beksKlcZu0Q6z3QdP5S7bW3R/tqx86gr8VwD5Kw9izEMDjaSxmpL A=; X-IronPort-AV: E=Sophos;i="4.62,242,1297036800"; d="scan'208";a="271888911" Received: from sj-core-4.cisco.com ([171.68.223.138]) by sj-iport-3.cisco.com with ESMTP; 28 Feb 2011 19:55:19 +0000 Received: from jmpolk-wxp01.cisco.com (rcdn-jmpolk-8711.cisco.com [10.99.80.18]) by sj-core-4.cisco.com (8.13.8/8.14.3) with ESMTP id p1SJtIaY000853; Mon, 28 Feb 2011 19:55:19 GMT Message-Id: <201102281955.p1SJtIaY000853@sj-core-4.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 28 Feb 2011 13:55:17 -0600 To: Paul Kyzivat , Christer Holmberg From: "James M. Polk" In-Reply-To: <4D6BABED.6070908@cisco.com> References: <7F2072F1E0DE894DA4B517B93C6A05851948D7E029@ESESSCMS0356.eemea.ericsson.se> <4D6BABED.6070908@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: SIPCORE Subject: Re: [sipcore] I-D Action:draft-ietf-sipcore-location-conveyance-06.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, 28 Feb 2011 19:54:20 -0000 Christer I have no record of receiving your message, which is strange. Anyway, I agree with you to change INFO to use RFC 6086, but I agree with Paul that I don't want to replace existing RFCs as references with their bis replacements when I'm not using the updated part of the new ID within my current version of my ID. Does this make sense? I also want to avoid any dependencies that are drafts whenever possible. James At 08:06 AM 2/28/2011, Paul Kyzivat wrote: >On 2/27/2011 4:26 PM, Christer Holmberg wrote: >>Hi, >> >>I guess we should use RFC 6086 for INFO, as it obsoletes RFC 2976. > >Which one makes no difference to this draft, but yes, it makes sense >to reference the latest revision. > >>I guess RFC 3265 (and potentially RFC 3262) might also going to be >>obsoleted at some point, due to 3265bis, but I guess we don't want >>to wait for that. > >Again it makes no difference to the substance of this draft. >And in this case, referencing the bis would make a dependency, which >is not a good thing in this case. So these refs should be left as is. > > Thanks, > Paul > >>Regards, >> >>Christer >> >>________________________________________ >>From: sipcore-bounces@ietf.org [sipcore-bounces@ietf.org] On Behalf >>Of Paul Kyzivat [pkyzivat@cisco.com] >>Sent: Saturday, February 26, 2011 2:10 AM >>To: James M. Polk (E-mail); SIPCORE >>Subject: Re: [sipcore] >>I-D Action:draft-ietf-sipcore-location-conveyance-06.txt >> >>James, >> >>A few things... >> >>Section 4.1: >> >> Additionally, the first SIP intermediary to add a locationValue adds >> it as the last locationValue in the header value. A SIP intermediary >> that adds a locationValue MUST position it as the last locationValue >> of the last Geolocation header field of the message. >> >>John E already called this out, and I agree. >>The first sentence ("Additionally...header value.") should be removed. >>The subsequent sentence covers all that and more. >> >>(There is nothing special about the *first* intermediary to add >>locationValue.) >> >>In the same section: >> >> This document defines the Geolocation header field as valid in the >> following SIP requests: >> >> INVITE [RFC3261], REGISTER [RFC3261], >> OPTIONS [RFC3261], BYE [RFC3261], >> UPDATE [RFC3311], INFO [RFC2976], >> MESSAGE [RFC3428], REFER [RFC3515], >> SUBSCRIBE [RFC3265], NOTIFY [RFC3265], >> PUBLISH [RFC3903], PRACK [RFC3262] >> >>This isn't new, and maybe it came up before (I don't recall), but was >>there a reason why PRACK is in this list? I can't think of a good reason >>to put Geoloc info in PRACK, and PRACK is a message that really should >>not be rejected. Geoloc info provides another potential reason why a >>recipient might find a need to reject it. >> >>Unless there is some history on this point, and particular reason for >>including PRACK, I propose that it be removed from the list. >> >>Section 4.4: >> >> message-header /= Geolocation-Error-header ; >> (message-header from 3261) >> Geolocation-Error = "Geolocation-Error" HCOLON >> locationErrorValue >> >> >>The name used in the two statements is not consistent. Change the first: >> >> message-header /= Geolocation-Error ; (message-header from 3261) >> >>Section 8: >> >>I don't see anything to register the Geolocation-Error header. >>Did that get missed up till now? >> >> Thanks, >> Paul >>_______________________________________________ >>sipcore mailing list >>sipcore@ietf.org >>https://www.ietf.org/mailman/listinfo/sipcore From christer.holmberg@ericsson.com Mon Feb 28 12:29:23 2011 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 582013A6C97 for ; Mon, 28 Feb 2011 12:29:23 -0800 (PST) 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 0ge2XvUiwxgV for ; Mon, 28 Feb 2011 12:29:22 -0800 (PST) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id C4E743A6C92 for ; Mon, 28 Feb 2011 12:29:21 -0800 (PST) X-AuditID: c1b4fb3d-b7bbbae000005311-38-4d6c05dd80da Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 4E.DC.21265.DD50C6D4; Mon, 28 Feb 2011 21:30:21 +0100 (CET) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.30]) by esessmw0256.eemea.ericsson.se ([10.2.3.125]) with mapi; Mon, 28 Feb 2011 21:30:19 +0100 From: Christer Holmberg To: "James M. Polk" , Paul Kyzivat Date: Mon, 28 Feb 2011 21:30:18 +0100 Thread-Topic: [sipcore] I-D Action:draft-ietf-sipcore-location-conveyance-06.txt Thread-Index: AcvXgW6xFS/SR93NRsKepjRCAe7rggABJERQ Message-ID: <7F2072F1E0DE894DA4B517B93C6A05851948EC99EF@ESESSCMS0356.eemea.ericsson.se> References: <7F2072F1E0DE894DA4B517B93C6A05851948D7E029@ESESSCMS0356.eemea.ericsson.se> <4D6BABED.6070908@cisco.com> <201102281955.p1SJtIaY000853@sj-core-4.cisco.com> In-Reply-To: <201102281955.p1SJtIaY000853@sj-core-4.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-Brightmail-Tracker: AAAAAA== Cc: SIPCORE Subject: Re: [sipcore] I-D Action:draft-ietf-sipcore-location-conveyance-06.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, 28 Feb 2011 20:29:23 -0000 Hi,=20 >I have no record of receiving your message, which is strange. >=20 >Anyway, I agree with you to change INFO to use RFC 6086, but=20 >I agree with Paul that I don't want to replace existing RFCs=20 >as references with their bis replacements when I'm not using=20 >the updated part of the new ID within my current version of=20 >my ID. Does this make sense?=20 Yes. My suggestion was not that we should add a reference to a bis draft, o= r to wait until the bis draft becomes an RFC. It was to make people aware, = in case someone would be aware of some impacts. But, as Paul said, from a t= echnical perspective it probably doesn't matter in this case. Regards, Christer > I also want to avoid any dependencies that are drafts=20 > whenever possible. >=20 > James >=20 > At 08:06 AM 2/28/2011, Paul Kyzivat wrote: >=20 >=20 > >On 2/27/2011 4:26 PM, Christer Holmberg wrote: > >>Hi, > >> > >>I guess we should use RFC 6086 for INFO, as it obsoletes RFC 2976. > > > >Which one makes no difference to this draft, but yes, it=20 > makes sense to=20 > >reference the latest revision. > > > >>I guess RFC 3265 (and potentially RFC 3262) might also going to be=20 > >>obsoleted at some point, due to 3265bis, but I guess we=20 > don't want to=20 > >>wait for that. > > > >Again it makes no difference to the substance of this draft. > >And in this case, referencing the bis would make a=20 > dependency, which is=20 > >not a good thing in this case. So these refs should be left as is. > > > > Thanks, > > Paul > > > >>Regards, > >> > >>Christer > >> > >>________________________________________ > >>From: sipcore-bounces@ietf.org [sipcore-bounces@ietf.org]=20 > On Behalf Of=20 > >>Paul Kyzivat [pkyzivat@cisco.com] > >>Sent: Saturday, February 26, 2011 2:10 AM > >>To: James M. Polk (E-mail); SIPCORE > >>Subject: Re: [sipcore]=20 > >>I-D Action:draft-ietf-sipcore-location-conveyance-06.txt > >> > >>James, > >> > >>A few things... > >> > >>Section 4.1: > >> > >> Additionally, the first SIP intermediary to add a=20 > locationValue adds > >> it as the last locationValue in the header value. A=20 > SIP intermediary > >> that adds a locationValue MUST position it as the=20 > last locationValue > >> of the last Geolocation header field of the message. > >> > >>John E already called this out, and I agree. > >>The first sentence ("Additionally...header value.") should=20 > be removed. > >>The subsequent sentence covers all that and more. > >> > >>(There is nothing special about the *first* intermediary to add > >>locationValue.) > >> > >>In the same section: > >> > >> This document defines the Geolocation header field as=20 > valid in the > >> following SIP requests: > >> > >> INVITE [RFC3261], REGISTER [RFC3261], > >> OPTIONS [RFC3261], BYE [RFC3261], > >> UPDATE [RFC3311], INFO [RFC2976], > >> MESSAGE [RFC3428], REFER [RFC3515], > >> SUBSCRIBE [RFC3265], NOTIFY [RFC3265], > >> PUBLISH [RFC3903], PRACK [RFC3262] > >> > >>This isn't new, and maybe it came up before (I don't=20 > recall), but was=20 > >>there a reason why PRACK is in this list? I can't think of a good=20 > >>reason to put Geoloc info in PRACK, and PRACK is a message=20 > that really=20 > >>should not be rejected. Geoloc info provides another=20 > potential reason=20 > >>why a recipient might find a need to reject it. > >> > >>Unless there is some history on this point, and particular=20 > reason for=20 > >>including PRACK, I propose that it be removed from the list. > >> > >>Section 4.4: > >> > >> message-header /=3D Geolocation-Error-header ; > >> (message-header from 3261) > >> Geolocation-Error =3D "Geolocation-Error" HCOLON > >> locationErrorValue > >> > >> > >>The name used in the two statements is not consistent.=20 > Change the first: > >> > >> message-header /=3D Geolocation-Error ; (message-header=20 > from 3261) > >> > >>Section 8: > >> > >>I don't see anything to register the Geolocation-Error header. > >>Did that get missed up till now? > >> > >> Thanks, > >> Paul > >>_______________________________________________ > >>sipcore mailing list > >>sipcore@ietf.org > >>https://www.ietf.org/mailman/listinfo/sipcore >=20 > = From mary.ietf.barnes@gmail.com Mon Feb 28 14:05:18 2011 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 AD3EF3A6CB2 for ; Mon, 28 Feb 2011 14:05:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.98 X-Spam-Level: X-Spam-Status: No, score=-102.98 tagged_above=-999 required=5 tests=[AWL=-0.382, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 BzqumnQvoSkq for ; Mon, 28 Feb 2011 14:05:17 -0800 (PST) Received: from mail-vx0-f172.google.com (mail-vx0-f172.google.com [209.85.220.172]) by core3.amsl.com (Postfix) with ESMTP id 991383A6BEC for ; Mon, 28 Feb 2011 14:05:17 -0800 (PST) Received: by vxg33 with SMTP id 33so3997942vxg.31 for ; Mon, 28 Feb 2011 14:06:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=iapB6hTiWYnreFesbxgWJyRORNLzpFMf5bER81ITU1U=; b=ef3VQNPTo4yLnUSyWrod77iU7//kdO+/L3+PQ2Q6OoVxx4YaVJm2WeKi4GMWp+S4u3 +aglD/hMo/+F5tJou7WjITvktJ2JHFnXswSSAJifziYp4FB9mApSL+gNuNLTiMVJkwA6 7/wD185dhmUtpfykAa9lAxq7vH6btGG3cj8PI= 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=K1NmoQmp1JIHgHS/Daa8wNrTSYpA7U1lGRYooeCwUAAmBN3JrlZPQyEUZBcRHnhPbY 19mnAQ6CUrda4nuW1WduPpFxxDQKKji97B+1KiLHamshu8YhFYeP0yTReC5dIcta9/SZ G/B8t4cNdiN0qhdB7+F3xErFoSZF079Las5Bo= MIME-Version: 1.0 Received: by 10.52.164.168 with SMTP id yr8mr10138213vdb.16.1298930778482; Mon, 28 Feb 2011 14:06:18 -0800 (PST) Received: by 10.52.162.202 with HTTP; Mon, 28 Feb 2011 14:06:18 -0800 (PST) In-Reply-To: References: <4D691B28.20702@zioup.com> Date: Mon, 28 Feb 2011 16:06:18 -0600 Message-ID: From: Mary Barnes To: "Worley, Dale R (Dale)" Content-Type: multipart/alternative; boundary=bcaec53f95c5a3aa12049d5ee34b Cc: Yves Dorfsman , "sipcore@ietf.org" Subject: Re: [sipcore] REGISTER, Contact:* 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, 28 Feb 2011 22:05:18 -0000 --bcaec53f95c5a3aa12049d5ee34b Content-Type: text/plain; charset=ISO-8859-1 Isn't this exactly what you get with a Shared Line Appearance feature? It allows a client to be logged into two different devices. And, AFAIK, it is supported on the Avaya (Nortel CS1K) systems. Mary. On Mon, Feb 28, 2011 at 10:26 AM, Worley, Dale R (Dale) wrote: > ________________________________________ > From: sipcore-bounces@ietf.org [sipcore-bounces@ietf.org] On Behalf Of > Yves Dorfsman [yves@zioup.com] > > If two UAs register with the same registrar at the same time (I'm not sure > why > one would do that, but there is nothing in the RFC preventing it), > _______________________________________________ > > Have you never seen an extension number that rings on two different phones? > > Dale > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > --bcaec53f95c5a3aa12049d5ee34b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Isn't this exactly what you get with a Shared Line Appearance feature? = =A0 It allows a client to be logged into two different devices. And, AFAIK,= it is supported on the Avaya (Nortel CS1K) systems.=A0

= Mary.=A0

On Mon, Feb 28, 2011 at 10:26 AM, Worle= y, Dale R (Dale) <dworley@avaya.com> wrote:
________________________________________
From: sipcore-bounces@ietf.org<= /a> [sipcore-bounces@ietf.org] On Behalf Of Yves Dorfsman [yves@ziou= p.com]

If two UAs register with the same registrar at the same time (I'm not s= ure why
one would do that, but there is nothing in the RFC preventing it),
_______________________________________________

Have you never seen an extension number that rings on two different phones?=

Dale
__________________________________= _____________
sipcore mailing list
sipcore@ietf.org
https://www.ietf.org/mailman/listinfo/sipcore

--bcaec53f95c5a3aa12049d5ee34b-- From pkyzivat@cisco.com Mon Feb 28 15:15:07 2011 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 3CD103A6A21 for ; Mon, 28 Feb 2011 15:15:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.431 X-Spam-Level: X-Spam-Status: No, score=-109.431 tagged_above=-999 required=5 tests=[AWL=-1.132, BAYES_00=-2.599, MANGLED_EXTNSN=2.3, RCVD_IN_DNSWL_HI=-8, 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 DcwdBcVfR3G7 for ; Mon, 28 Feb 2011 15:15:06 -0800 (PST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id F12563A6835 for ; Mon, 28 Feb 2011 15:15:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pkyzivat@cisco.com; l=4176; q=dns/txt; s=iport; t=1298934967; x=1300144567; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=iBE8zrSl0LC828VwundhZYC6J7+3AO/MMI9Ksoc57Pg=; b=LExIUoL3LC2v3tfPZzznc0Vssc5EzsDx2Ox3CZ57lCjysA8Rq2aAifTb HjDIK6o9il5uHvfC3+lxrTtF88L7YeGKCaql1sbf+7DWSrXVmJKwBEo8g BL4LXzfV4ruocqiAAofSlkjH1F3VUISjTv3YEYROuvmcDUB6mdKXXme9f g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAAe7a01AZnwM/2dsb2JhbACmR3SfaZtjgxiCSQSFEocNgz4 X-IronPort-AV: E=Sophos;i="4.62,243,1297036800"; d="scan'208";a="220903809" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 28 Feb 2011 23:16:06 +0000 Received: from [161.44.174.114] (dhcp-161-44-174-114.cisco.com [161.44.174.114]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id p1SNG6pu007903 for ; Mon, 28 Feb 2011 23:16:06 GMT Message-ID: <4D6C2CB6.4040800@cisco.com> Date: Mon, 28 Feb 2011 18:16:06 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: sipcore@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [sipcore] I-D Action: draft-mohali-sipcore-reason-extension-application-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: Mon, 28 Feb 2011 23:15:07 -0000 (As individual) Marianne, I'm still struggling to make sense of this in the form proposed. I look at the various cause values, and all the descriptions are of the form. E.g.: Cause value: 2 Reason text: Freephone Description: A Freephone application has influenced processing of the call (e.g. by translating a dialed Free Phone number to a routable directory number). I can't figure out how to make any actionable decision based on this. Rather, it seems I need to make a number of leaps of faith before I can decide what to do. For instance, if I get an error, it *might* be because I dialed a freephone number, and it isn't supported from my calling location. (E.g. maybe I'm dialing +1-800-555-1234, but I'm doing so from France, and calling that number is only supported in the USA. But getting a application reason code with cause 2 doesn't really tell me that is what happened. It could be that the call indeed was routed through a freephone application, and it properly routed the call, and the call failed for some other reason. But the cause is there because the application *did* influence the call routing. Also, these "applications" are not, AFAIK, mutually exclusive. E.g. I could be using a prepaid service to make a directory assistance call that costs extra $$$ that I don't have credits to cover. But you can't include two cause values for the same protocol. (But it is true that you *can* have a number of servers each put one cause into *their* H-I entry.) So *maybe* I would see that my call failed, and that there is both a reason indicating a prepaid application on one H-I entry, and another indicating a another H-I indicating a directory service application. But what can I conclude from that? Bottom line, I just can't make sense how this could be used in a well defined and interoperable way. Thanks, Paul On 2/28/2011 9:58 AM, marianne.mohali@orange-ftgroup.com wrote: > Hello, > > Here is the new version of the draft. > Main changes are following: > - More details about the registration procedure for new values > - Clearer text in section 3.2 > - Add of Public and Private status for registered values. > - Add of a range for cause values registration > > Best Regards, > Marianne Mohali > > -----Message d'origine----- > Objet : New Version Notification for > draft-mohali-sipcore-reason-extension-application-01 > > A New Internet-Draft is available from the on-line Internet-Drafts > directories. > > Title : Extending the Session Initiation Protocol > (SIP) Reason Header for Applications > Author(s) : M. Mohali, B. Chatras > Filename : > draft-mohali-sipcore-reason-extension-application-01.txt > Pages : 10 > Date : 2011-02-24 > > This document defines a new protocol value "Application" for the > Reason Header field and a new IANA Registry for registering > application types. This new value enables signaling that a request > or response has been issued as a result of a decision made by a > particular type of application or that an initial request has been > retargeted as a result of an application decision. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-mohali-sipcore-reason-extensio > n-application-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. > > n-application-01.txt> > > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From adam@nostrum.com Mon Feb 28 15:38:20 2011 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 557913A69B5 for ; Mon, 28 Feb 2011 15:38:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.587 X-Spam-Level: X-Spam-Status: No, score=-102.587 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599, 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 wSocmudo3zVe for ; Mon, 28 Feb 2011 15:38:19 -0800 (PST) Received: from nostrum.com (shaman.nostrum.com [72.232.179.90]) by core3.amsl.com (Postfix) with ESMTP id 869703A6962 for ; Mon, 28 Feb 2011 15:38:19 -0800 (PST) Received: from dn3-228.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 p1SNc4sj076202 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Mon, 28 Feb 2011 17:38:05 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <4D6C31DC.80005@nostrum.com> Date: Mon, 28 Feb 2011 17:38:04 -0600 From: Adam Roach - SIPCORE Chair User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: "SIPCORE (Session Initiation Protocol Core) WG" 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: "draft-ietf-sipcore-location-conveyance@tools.ietf.org" , Robert Sparks , SIPCORE Chairs Subject: [sipcore] WGLC: draft-ietf-sipcore-location-conveyance X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: SIPCORE Chairs List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Feb 2011 23:38:20 -0000 [as chair] The current editor of draft-ietf-sipcore-location-conveyance believes that the document has no remaining technical issues[1], and is ready for evaluation. Today, we are starting a two-week working group last call period. This last call period ends on Tuesday, March 15th. The latest version of the document can be retrieved here: http://tools.ietf.org/html/draft-ietf-sipcore-location-conveyance Any comments on the document should be sent to the SIPCORE mailing list. /a [1] John Elwell's editorial comments of February 25th have been noted by the authors, and will be treated as WGLC comments.