SIP
SIPCORE Working Group                                        James Polk
Internet Draft                                            Cisco Systems
Expires: December 18, January 13, 2009                                   Brian Rosen
Intended Status: Standards Track (PS)                           NeuStar
                                                          June 18,
                                                          July 13, 2009

         Location Conveyance for the Session Initiation Protocol
              draft-ietf-sipcore-location-conveyance-00.txt
              draft-ietf-sipcore-location-conveyance-01.txt

Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with
   the provisions of BCP 78 and BCP 79.  This document may contain
   material from IETF Documents or IETF Contributions published or made
   publicly available before November 10, 2008.  The person(s)
   controlling the copyright in some of this material may not have
   granted the IETF Trust the right to allow modifications of such
   material outside the IETF Standards Process.  Without obtaining an
   adequate license from the person(s) controlling the copyright in
   such materials, this document may not be modified outside the IETF
   Standards Process, and derivative works of it may not be created
   outside the IETF Standards Process, except to format it for
   publication as an RFC or to translate it into languages other than
   English.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six
   months and may be updated, replaced, or obsoleted by other documents
   at any time.  It is inappropriate to use Internet-Drafts as
   reference material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on December 18, January 13, 2009.

Copyright Notice

   Copyright (c) 2009 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents in effect on the date of
   publication of this document (http://trustee.ietf.org/license-info).
   Please review these documents carefully, as they describe your
   rights and restrictions with respect to this document.

Legal

   This documents and the information contained therein are provided on
   an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
   REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE
   IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL
   WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY
   WARRANTY THAT THE USE OF THE INFORMATION THEREIN WILL NOT INFRINGE
   ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS
   FOR A PARTICULAR PURPOSE.

Abstract

   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 extension covers end to end end-to-end
   conveyance as well as location-based routing, where SIP servers
   make routing decisions based on the location of the user agent
   clients.
   client.

Table of Contents

   1.  Conventions and Terminology used in this document . . . . . .  3
   2.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .  3  4
   3.  Overview of SIP Location Conveyance . . . . . . . . . . . . .  4
   4.  SIP Modifications for Geolocation Conveyance  . . . . . . . .  7
       4.1 The Geolocation Header  . . . . . . . . . . . . . . . . .  7
       4.2 424 (Bad Location Information) Response Code  . . . . . . 10
       4.3 The Geolocation-Error Header  . . . . . . . . . . . . . . 11
       4.4 The 'geolocation' Option Tag  . . . . . . . . . . . . . . 19 20
       4.5 Using sip/sips/pres as a Dereference Scheme . . . . . . . 19 20
   5.  Geolocation Examples  . . . . . . . . . . . . . . . . . . . . 21 22
       5.1 Location-by-value (Coordinate Format) . . . . . . . . . . 21 22
       5.2 Location-by-reference . . . . . . . . . . . . . . . . . . 23 24
   6.  SIP Element Behavior  . . . . . . . . . . . . . . . . . . . . 23 24
       6.1 UAC Behavior  . . . . . . . . . . . . . . . . . . . . . . 24 25
       6.2 UAS Behavior  . . . . . . . . . . . . . . . . . . . . . . 27 29
       6.3 Proxy Behavior  . . . . . . . . . . . . . . . . . . . . . 32 34
   7.  Geopriv Privacy Considerations  . . . . . . . . . . . . . . . 36 38
   8.  Security Considerations . . . . . . . . . . . . . . . . . . . 37 39
   9.  IANA Considerations   . . . . . . . . . . . . . . . . . . . . 38 40
       9.1 IANA Registration for New SIP Geolocation Header  . . . . 38 41
       9.2 IANA Registration for New SIP 'geolocation' Option Tag  . 39 41
       9.3 IANA Registration for New 424 Response Code . . . . . . . 39 41
       9.4 IANA Registration for New SIP Geolocation-Error Header  . 39 41
       9.5 IANA Registration for New SIP Geolocation-Error Codes . . 39 42
       9.6 IANA Registration of LbyR Schemes   . . . . . . . . . . . 40 43
   10. Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . 40 43
   11. References  . . . . . . . . . . . . . . . . . . . . . . . . . 41 43
       11.1 Normative References   . . . . . . . . . . . . . . . . . 41 43
       11.2 Informative References . . . . . . . . . . . . . . . . . 42 45
       Author Information  . . . . . . . . . . . . . . . . . . . . . 42 45
       Appendix A. Requirements for SIP Location Conveyance  . . . . 43 45

1.  Conventions and Terminology used in this document

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
   NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
   "OPTIONAL" in this document are to be interpreted as described
   in [RFC2119].

   The following terms and acronyms used throughout this document are
   defined here:

   LbyR = Location-by-Reference

   LbyV = Location-by-Value

   Location Generator (LG): The entity that initially determines or
      gathers the location of the Target and creates Location
      Objects describing the location of the Target [RFC3693].

   Location Information Server (LIS) - Inserter: a logical server role created in this document describing the
      entity that stores
      geolocation records of Targets, which correspond to LbyR URIs. included location in a SIP request, either by-value
      or by-reference (i.e., including a location URI).

   Location Object (LO): An object conveying location information
      (and possibly privacy rules) to which Geopriv security
      mechanisms and privacy rules are to be applied [RFC3693].

   Location Recipient (LR): The entity that receives location
      information.  It may have asked for this location explicitly
      (by sending a query to a location server), or it may receive
      this location asynchronously [RFC3693].

   Location Server (LS): The entity to which a LG publishes location
      objects, the recipient of queries from location receivers, and
      the entity that applies rules designed by the rule maker
      [RFC3693].

      A Location Server is also an entity that retains Target Location
      Objects that are dereferenced by Location Recipients via SIP
      SUB/NOT transactions.

   Target: A person or other entity whose location is communicated by
      a Geopriv Location Object [RFC3693].

   Using Protocol: A protocol that carries a Location Object [RFC3693].

2.  Introduction

   This document describes how Location geolocation can be "conveyed" in a SIP
   request from one SIP entity unsolicited to another entity using SIP
   [RFC3261].  Here, "Location" is a description of the physical
   geographical area where something currently exists.  Note that this
   information is not solicited by the entity that receives it.  The phrase "location conveyance"
   describes scenarios
   mechanism in which a this document does not allow one SIP user agent client (UAC) is
   informing a user agent server (UAS) or intermediate SIP server
   without being previously asked where the UAC is.

   Location Conveyance is different from a UAC, Alice, seeking to request
   the location the UAS, Bob.  Location conveyance, using SIP, never asks
   for of another entity's location SIP user to be returned in a response.  Asking for someone
   else's location is not discussed in this document.

   Geographic location in the IETF is discussed in RFC 3693 (Geopriv
   Requirements) [RFC3693].  It defines a "Target" as the entity whose
   location is being transmitted over IP.  A [RFC3693] defined [RFC3693]-defined "Using
   Protocol" describes how a "Location Server" transmits a "Location
   Object" to a "Location Recipient" while maintaining the contained
   privacy intentions of the Target intact. This document describes the a
   SIP extension to SIP for carry a Location Object and how it complies with
   the Using Protocol
   requirements, where the location server is a UA or Proxy Server and
   the Location Recipient is another UA or Proxy Server. requirements in RFC 3693.

   Common terms are in Section 1. Section 3 provides an overview of SIP
   location conveyance.  Section 4 details the modifications extensions to SIP
   necessary to accomplish location conveyance.  Section 5 gives decode
   examples of geolocation within SIP requests, both LbyV and LbyR.
   Section 6 articulates the SIP element type behaviors for location
   conveyance. Section 7 discusses Geopriv privacy considerations.
   Section 8 discusses security considerations.  Section 9 IANA
   registers the modifications made to SIP by this document from in section
   4.

3.  Overview of SIP Location Conveyance

   The concept of conveying location in SIP is fairly straightforward.
   Location is conveyed directly or indirectly from a transmitting SIP
   entity to a receiving SIP entity.  If  When location is conveyed
   directly, then it is conveyed as a value contained within the SIP
   request, see as in Figure 1., 1.

      Alice                      Bob                     LIS
        |                         |                       |
        |  Request w/ Location    |                       |
        |------------------------>|                       |
        |                         |                       |
        |       Response          |                       |
        |<------------------------|                       |
        |                         |                       |

   Figure 1. Location Conveyed by Value

   If

   When location is conveyed indirectly, analogous to Content
   Indirection [RFC4483], this is a case where Bob receives (from Alice) an LbyR a location URI that requires and
   must make an additional transaction request - here called a dereference - to
   learn Alice's location by requesting that actual location from a LIS, see Location Server (LS)
   identified in the location URI, as in Figure 2., 2.

      Alice                      Bob                     LIS                     LS
        |                         |                       |
        | Request w/ Location URI |                       |
        |------------------------>|                       |
        |                         |     Fetch  Dereference Request  |
        |                         |---------------------->|
        |                         |                       |
        |                         |     Fetch  Dereference Response |
        |                         |<----------------------|
        |        Response         |  (includes location)  |
        |<------------------------|                       |
        |                         |                       |

   Figure 2. Location Conveyed by Reference

   Many protocols can be used for this fetch dereference transaction, but
   this is usually bounded determined by the scheme of the location URI in the
   SIP request. In other works, words, if the location URI is a SIPS: URI,
   then SIPS would be used to contact the LIS LS to make the dereference.

   The location "value" in this SIP extension is in the form of a
   Presence
   "Presence Information Data Format - Location Object, Object", or PIDF-LO, as
   described in [RFC4119].  A PIDF-LO is an XML scheme specifically for
   carrying the geographic location of a Target.  LbyV refers to a UA
   including a PIDF-LO as a message body part of a SIP request, sending
   that Location Object to another SIP element.  LbyR refers to a UA
   including a location URI in a SIP request header field which can be
 dereferenced by a Location Recipient to receive retrieve Alice's Location
 Object, in the form of a PIDF-LO.  Dereferencing is done by a
   Location Recipient.

   To accomplish location conveyance in SIP, a new SIP header, header field,
   Geolocation, is created and described in this document.  The
   Geolocation header field contains a URI that points to the where the
   location is for that the location target, either in the body of the SIP
   request itself (LbyV), or on an external server a Location Server (LbyR).  A location
   URI that points to a message body is always a "cid:" URI (Content
   Identification), as defined in [RFC2392].

   If the URI in the Geolocation header field is a scheme other than
   "cid:", a fetch dereference transaction (see Figure 2) is necessary. This
   document describes how a SIP presence subscription [RFC3856] can be
   used as a dereference protocol.

   Including location

   Location can be inserted in a SIP request is not limited to insertion by a
   UA. There are times where a SIP server wants to insert location of a
   location target into as well as
   by a request from that target towards the
   request's destination. UA. This document offers guidance on this practice. This
   document also describes how a location recipient can determine which
   entity included what a specific location, as it is allowed for more than one location to can
   be conveyed in a given SIP request. Section 4 gets into guidance and
   limitations of this behavior.

   A new error response (424 Bad Location Information) is also defined
   in this document. Within this response is a new header field
   indicating location-based errors, call called the Geolocation-Error header.
   header field.  This header field has various codes that provide
   additional information about the type of location error experienced
   by a Location Recipient. Recipient, separated into actionable categories to be
   taken by the UAC.

   Because more than one SIP entity can insert location, when
   considering SIP as an end-to-end protocol, there needs to be a means
   of identifying which location within a message of multiple locations
   was considered bad by a location recipient - if that were to occur.
   The ability to tell by host-id which entity (identified by host-id) inserted which a
   specific location is extremely important. Not only does this allow
   each location error to be targeted at a particular inserter of particular location, a
   specific location object, but it also allows error recipients to
   understand when their inserted the location they inserted was not at fault, and when
   that a received error is not meant for them.  This optimization is
   necessary, otherwise each location error would be a blanket error to
   every entity upstream in this the signaling path.

   Just as location can be conveyed by more than one entity about the
   same target, there can be more than one location recipient along a
   message's
   request's path.  It is possible, and it fact, planned in certain
   circumstances possible to have route SIP requests routed based on the
   location of the target. target (i.e., source based routing, instead of
   normal destination based routing).  This means SIP servers can be
   location recipients. If this is not desired by a location inserter - the act of including
   location into this request, Location Inserter,
   then the Location Inserter can also include a separate indication is given in
   the Geolocation header it field showing that this usage is allowed.

   There is no mechanism by which not desired.

   Location Inserters have the veracity of these ability to provide instructional
   parameters can
   be verified.  They about location it has inserted.  These are hints to
   downstream entities on how the location information in the message
   was originated, intended and is to be used.

   Transport Layer Security is expected when a request contains a
   target's location.  Some implementations will choose to have S/MIME
   for integrity protection, or to encrypt message bodies from source
   to destination. destination(s).

   This document creates a new option tag: geolocation, to indicate
   support for this extension by UAs.

   The new headers, header field, the header parameters, the new option tag, the
   new error response, and Geolocation-Error codes, which codes are defined in
   Section 4., 4, each of which are IANA registered by this document.

   RFC 3693 demands that a transmitted location must be required to maintain
   privacy considerations.  This document maintains all of the privacy
   considerations defined by RFC 3693, plus adds an intended usage
   indication within the SIP Geolocation header. header field. This increases
   the considerations for recipients not to inspect a target's location
   when they are not the intended location recipient.

4.  SIP Modifications for Geolocation Conveyance

   The following are sections detail the standards track modifications
   to SIP for Location Conveyance.

4.1 The Geolocation Header Field

   This document defines and IANA registers Geolocation as a new SIP header:
   Geolocation, header field
   registered by IANA, with the following ABNF [RFC5234]:

   Geolocation        =  "Geolocation" HCOLON (locationValue *(COMMA
                          locationValue)) (COMMA retrans-param)
   locationValue      =  LAQUOT locationURI RAQUOT *(SEMI geoloc-param)
   locationURI        =  sip-URI / sips-URI / pres-URI
                          / cid-url ; (from RFC 2392)
                          / absoluteURI ; (from RFC 3261)
   geoloc-param       =  "inserted-by" EQUAL geoloc-inserter
                          / "used-for-routing"
                          / generic-param ; (from RFC 3261)
   geoloc-inserter    =  DQUOTE hostport DQUOTE
                          / gen-value ; (from RFC 3261)
   retrans-param      =  "routing-allowed" EQUAL "yes" / "no"

   sip-URI, sips-URI and absoluteURI are defined according to RFC 3261. [RFC3261].

   The pres-URI is defined in RFC 3859 [RFC3859].

   The cid-url is defined in [RFC2392] to locate message body
   parts.  This URI type MUST be is present in a SIP request if where location
   is transmitted LbyV only. conveyed as a value.

   Other protocols used in the Location location URI MUST be reviewed against
   the RFC 3693 criteria for a Using Protocol.

   The Geolocation header field MAY have one or more locationValues.
   SIP servers inserting a locationValue MUST add the new value as the
   last locationValue in the Geolocation header field (i.e., the last
   locationValue in the header field is the most recent one added to
   the message).  Placement of the "routing-allowed" parameter, when
   present, MUST be the last header field value in the Geolocation header.
   header field.

   A locationValue has the following independent header field
   parameters,

   o  the "inserted-by=" parameter provides the hostport
      (alice.example.com -- which is the same as the "sent-by"
      parameter in a Via header, header field, with or without a port number)
      of the SIP entity that inserted this locationValue into the
      request. If a Location Recipient has determined a supplied
      location is in error, as there can be more than one location in
      any request, the "inserted-by=" parameter is copied into the
      locationErrorValue in the response indicating the location error,
      and to whom the error is for.  Hence, this "inserted-by="
      parameter MUST be present in each locationValue. If an entity
      receives an Geolocation-Error with a hostport that does not identifying
      identify this entity, the Geolocation-Error MUST be ignored.

   o  the "used-for-routing" parameter to inform recipients that the
      location in this locationValue was used to route the message
      towards the ultimate destination UAS.  "used-for-routing" can
      occur more than once along the request's path.  Because
      locationValues are inserted as last inserted is last in the
      header,
      header field, the last locationValue is the most recent one added
      to the message.  This also gives the "used-for-routing" header
      field parameter added meaning - as the receiving SIP entity knows
      which
      locationURI location URI the message was routed upon.

   Each locationValue MUST contain exactly one "inserted-by" parameter,
   indicating which SIP entity added the locationValue to the SIP
   request.

   There MUST NOT be more than one "inserted-by=" parameter or one
   "used-for-routing" parameter in the same locationValue.  However,
   there can be more than one locationValue in the same Geolocation
   header.
   header field.

   The "routing-allowed" header field parameter is a global parameter
   over any (and all/each) locationValues in the Geolocation header. header
   field.  This is the reason why the placement of the header field
   parameter is outside any locationValue, and appears only once, and is
   always last in the header field value.

   This header field parameter only has the values "=yes" or "=no" only. "=no".
   When this parameter is "=yes", any locationValue can be used for
   routing decisions along the downstream signaling path by
   intermediaries.  When this parameter is "=no", this means no
   locationValue (inserted by the originating UAC or any (or
   subsequent) intermediary(ies) along the signaling path) can be used
   by any SIP intermediary to make routing decisions.  This behavior
   MUST be adhered to.  Section 4.3 describes the details on what a
   routing intermediary does if it believes it needs to use the
   location in the SIP request in order to process the message further.

   The practical implication is that when the "routing-allowed"
   parameter is set to "no", if an LbyV is present in the SIP request,
   intermediaries SHOULD MUST NOT view the location (because it is not
   for intermediaries to view), and if an LbyR is present, SHOULD MUST NOT
   dereference it.  UASs are allowed to view location in the SIP
   request even when the "routing-allowed" header field parameter is
   set to "no".

   The default behavior when this header field parameter is not present
   in a message is to treat the SIP request as if the parameter were
   present and its value is set to "no".

   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] and         PRACK [RFC3262]

   Discussing location using the PUBLISH request is out of scope
   for this document since it is part of Presence, therefore, for
   completeness, Table 1 shows PUBLISH is to support Location
   Conveyance via this extension, but is not discussed further.

   The following table extends the values in Table 2&3 Tables 2 and 3 of RFC 3261
   [RFC3261].

      Header field             where proxy INV ACK CAN BYE REG OPT PRA
      ----------------------------------------------------------------
      Geolocation              R     ar     o   -   -   o   o   o   o

      Header field             where proxy SUB NOT UPD MSG REF INF PUB
      ----------------------------------------------------------------
      Geolocation              R     ar     o   o   o   o   o   o   o

               Table 1: Summary of the Geolocation Header Field

   The Geolocation header field MAY be included in any one of the above
   requests by a UAC.  A proxy MAY add the Geolocation header, header field,
   but MUST NOT modify any pre-existing locationValue, including any
   associated header field parameters within an existing Geolocation
   header field value, unless one of the existing locationValues is
   used to retarget the request towards a new destination UAS.  This is
   discussed in section 6.3.

   [RFC3261] states message bodies cannot be added by proxies.
   Therefore, any Geolocation header field added by a proxy MUST be in
   the form of an LbyR location URI, in its own locationValue header field
   value.

   A SIP proxy MAY add a Geolocation header field if one is not
   present, and MAY add the "routing-allowed" parameter if not yet
   present in the SIP request.  When a "routing-allowed" parameter is
   already present in the SIP request, a SIP server MUST NOT change the
   value of the parameter (i.e., from 'yes' to 'no', or from 'no' to
   'yes').  This would override the policy set by an upstream SIP
   entity (i.e., likely the UAC).

   Adding a new locationValue to an in-transit request is NOT
   RECOMMENDED to occur for at least two reasons,

   #1 -  SIP Servers are not the best locators geographically of where a
       UAC is; meaning the location information is that a SIP server knows may
       not necessarily the
        greatest.  There MAY be exceptions, but this SHOULD be the rule
        of thumb. best location information available.

   #2 - without appropriate caution to the fact that Location
        Recipients might not understand how to process more than one
        location, given  this document's document gives limited guidance as to what a Location
       Recipient should do when receiving more than one location  (i.e., currently no priority (no
       instructions are given
        for about which locationValue to use if there are when
       more than one).  A
        Location Recipient can easily be confused by too much location
        information, producing one is present), so adding a new locationValue may
       lead to undesirable results.  The <dm:device id>
        element [RFC5491] in the PIDF-LO XML indicates whose location
        is contained in the PIDF-LO.

   Location Recipients receiving a location object, whether received
   directly or as the result of a dereference, MUST honor the usage
   element rules within that XML document, as defined in [RFC4119].
   Such entities MUST NOT alter the rule set.

4.2 424 (Bad Location Information) Response Code

   This SIP extension creates a new Location location specific response code,
   defined as follows.

      424 (Bad Location Information)

   The 424 (Bad Location Information) response code is a rejection of
   the request, request due to its location contents, indicating the location
   information was malformed or not satisfactory for the recipient's
   purpose, or could not be dereferenced.

   Section 4.3 creates the Geolocation-Error header field to provide
   more detail about what was wrong with the location information in
   the request.  This header field MUST be in the 424 response,
   containing a locationErrorValue for each invalid locationValue in
   the request  (i.e., and one-for-one matching if all locationValues
   in the request were bad).

   If more than one location is present in a request (LbyV or LbyR),
   and any of the locationValues is good for the Location Recipient to
   process, can process any of the locationValues, a
   424 MUST NOT be sent.  The 424 is only appropriate when the Location
   Recipient needs a locationValue and there are no locationValues
   included in a SIP request that are usable by a recipient.

   A 424 (Bad Location Information) response is a final response within
   a transaction, and does not terminate a usage or a an existing dialog.

   The UAC can use whatever means it knows of to verify/refresh its
   location information before attempting a new request that includes
   location. There is no cross-transaction awareness expected by either
   the UAS or any SIP intermediary as a result of this error message.
   The new 424 (Bad Location Information) error code is IANA registered with
   IANA in Section 8 of this document.  An initial set of location error of
   IANA registered
   IANA-registered Geolocation-Error codes are in Section 4.3 of this
   document.

4.3 The Geolocation-Error Header Field

   As discussed in Section 4.2, more granular error notifications,
   specific to location errors within a received request, are required
   if the UAC is to know what was wrong within the original request.
   The Geolocation-Error header field is created here used for this purpose.

   The Geolocation-Error header field is used to convey location specific
   location-specific errors within a response.  Additions to this IANA registered header require  Additional
   IANA-registered values must be defined in an RFC be published. (this is the "RFC
   Required" IANA policy defined in [RFC5226]). The Geolocation-Error
   header field has the following ABNF [RFC5234]:

   Geolocation-Error        = "Geolocation-Error" HCOLON
                                locationErrorValue
                               *(COMMA locationErrorValue)
   locationErrorValue       = location-error-code *(SEMI
                               location-error-params)
   location-error-code      = 1*3DIGIT
   location-error-params    = location-error-node-id
                              / location-error-host-id
                              / location-error-code-text
                              / generic-param ; from RFC3261
   location-error-node-id   = "node" EQUAL
                                 DQOUTE hostport DQOUTE ; from RFC3261
   location-error-host-id   = "inserter" EQUAL
                                 DQOUTE hostport DQOUTE ; from RFC3261
   location-error-code-text = "code" EQUAL quoted-string ; from RFC3261

   The Geolocation-Error header field MUST contain at least one
   locationErrorValue to indicate what was wrong with the original locationValue
   in the corresponding request. If a request the Location Recipient
   experienced more than one error a particular locationValue of the
   corresponding SIP request, there can be one locationErrorValue per
   problem with the locationValue in the request. determined was
   bad. Each locationErrorValue contains one a 3-digit error code
   indicating what was wrong with the location in the request.  Each
   error type has a corresponding quoted error text string that is
   human understandable.  If there was something wrong with more than one
   locationValue in a request, a corresponding locationErrorValue would
   be sent, one per error, in the response.

   Each locationErrorValue contains the Location Recipient identifier
   (the "node=" parameter) which experienced the location error, as
   well as an identifier of which SIP entity (the "inserter="
   parameter) the Location Recipient is told (in the locationValue)
   added this problematic locationValue to the request.  The "node="
   and "inserter=" are the domain identifier of a SIP entity, with the
   ability to have the same host communicate on different ports - and
   have port specific identification. This is the same as is information that
   would be entered in the "sent-by" parameter of the Via header field
   for that entity  [RFC3261].  As stated in section 18 of RFC 3261,
   the usage of FQDN is RECOMMENDED.  Here are examples of both
   locationErrorValue
   parameters parameters,

      node="bob.example.com"

      inserter="alice.example.com"

   Both the "node=" and "inserter=" parameters MUST be present in all
   locationErrorValues in a response, unless the "inserted-by="
   parameter was not in the locationValue of a the
   request did not include the "inserted-by=" parameter (which is a
   violation of this document).  The "inserter=" parameter value is
   copied from the "inserted-by=" parameter within the locationValue of
   the request.  No manipulation or calculation is necessary to
   accomplish this.

   Here's why this

   This is necessary, required because a Location Recipient that experienced
   the location a
   problem with the location included in a request needs to tell the
   specific SIP entity which added the locationValue in error into the
   original request.  Since more than one SIP entity can insert
   location into a request in transit, all other SIP elements may be
   confused by receiving this error header, header field, were it to remain
   generic to all entities in the response path.  So,  This requirement
   means that the  header has to identify field identifies the Location Inserter who
   it is for,
   inserted the problematic locationValue, so that all other SIP
   entities that read the header field know to ignore it, since it is not for them. it.  This is of
   particular use if the original UAC did not include a locationValue
   in the original SIP request, but a SIP server along the path did
   insert a locationValue.  The locationErrorValue would travel to be interpreted
   by each SIP entity along the original path upstream and tell be processed
   by both the server that included the invalid locationValue what was wrong with the location and the
   UAC who that did not know what the error meant.  This will cause not, resulting in confusion if left without this indication. at the UAC.

   A worse case is when both the original UAC and a SIP server along
   the path included a locationValue, but there was only something
   wrong with only one of the locationValues.  Without this an
   identification of which the specific locationValue was in error, both entities
   would react react, and one would do so react incorrectly.

   More

   When more than one locationErrorValue is present in a
   Geolocation-Error header is field, they are separated by a comma. commas.

   If more than one locationErrorValue is present in a response, and
   intended for the same "inserter=", each error code MUST be unique to
   this "inserter=" entity, and the error codes SHOULD MUST NOT conflict in
   meaning.  In other words, two error codes (within separate
   locationErrorValues of the same response) SHOULD NOT give misleading
   or inconsistent indications to the location "inserter=".

   Here is an example of a Geolocation-Error header field:

   Geolocation-Error: 200; code="Retry Location Later";
                            node="bob.example.com";
                            inserter="alice.example.com";

   The following table extends the values in Table 2&3 of RFC 3261
   [RFC3261].

      Header field             where proxy INV ACK CAN BYE REG OPT PRA
      ----------------------------------------------------------------
      Geolocation-Error         r     ar    o   -   -   o   o   o   o

      Header field             where proxy SUB NOT UPD MSG REF INF PUB
      ----------------------------------------------------------------
      Geolocation-Error         r     ar    o   o   o   o   o   o   o

            Table 2: Summary of the Geolocation-Error Header Field

   The Geolocation-Error header field MAY be included in any response
   to one of the above SIP requests, so long as Geolocation was in the
   request part of the transaction.  For example, Alice includes her
   location in an INVITE to Bob. Bob can accept this INVITE, thus
   creating a dialog, even though his UA determined the location
   contained in the INVITE was bad.  There is a Geolocation-Error
   header value in the 200 OK to the INVITE informing Alice the INVITE
   was accepted but the location provided was bad. The choice of which SIP requests
   are
   included in table 2 above come from which Methods can are the ones allowed to optionally have contain
   the Geolocation header field (see section 4.1).  That said, a UAC
   MUST ignore a Geolocation-Error header field value if it that did not include a Geolocation
   header value in the request part of the transaction.
   contain its host-id..

   Here is an example of a transaction that has a location error.  In
   this case, Bob responds with a 424 (Bad Location Information)
   response, including a Geolocation-Error header, header field, is in Figure 3.

      Alice                                              Bob
        |                                                 |
        |       Request w/ Location                       |
        |------------------------------------------------>|
        |                                                 |
        |                                                 |
        |  424 (Bad Location Information)                 |
        |  with Geolocation-Error containing              |
        |  200 ("Retry Location Later" (with Later with same data)) data")    |
        |<------------------------------------------------|
        |                                                 |

   Figure 3. Basic Transaction with 424 and Geolocation-Error Header
             Field

   The following subsections provide an initial list of location
   based errors for any SIP non-100 response, including the new 424
   (Bad Location Information) response.  These error codes are divided
   into 5 categories, each based on receiver (of how the response)
   actionable reactions response receiver should react
   to these errors.

   o  100  1XX "Cannot Process Location"

   o  200  2XX "Retry Location Later" (with Later with same data) data"

   o  300  3XX "Retry Location Later" (with device Later with updated location) device location"

   o  400  4XX "Permission Necessary" To Reveal Location Information to a Third Party"

   o  500  5XX "Location Information Denial"

   All 5 of the above error codes MUST be implemented to comply with
   this specification.  Each of these actionable errors is given a 3
   digit error code category, meaning any future 1XX, 2XX, 3XX, 4XX,
   and 5XX error codes defined will have the same action expected by
   X00 categories - just increase categories, although the future error code may provide more
   granular meaning. information.  If another action is expected to occur with a
   newly defined error code, it MUST outside the 100-599 range.  100 unit ranges are OPTIONAL for future
   error codes, but they apply here.

4.3.1 Location Error: 100 "Cannot Process Location"

   The location error 100 "Cannot Process Location" indicates to a
   Geolocation-Error recipient that what they the locationValue supplied in a request, as
   far as location is concerned,
   request cannot be processed at this time.  This only has to do with
   the location that the location "inserter=" added to the request, and
   not about the overall request that was sent.

   Action(s) to be taken by Geolocation-Error receiver to for a 1XX:
         This error gives no guidance on what to do next.  It is a
         general information indication to a SIP "inserter=" entity
         that there was an unspecific problem with the location
         supplied in the SIP request.

   Implementations MAY choose to react in a way as if this the "inserter="
   entity received a 2XX or 3XX location error. A 4XX error Implementations MUST
   NOT be
   misunderstood here, react as if the "inserter=" entity received a 4XX location
   error, as that error category involves human intervention to grant,
   or not, permission to reveal "inserter=" location when this is
   likely not desired.

   The text string of "Cannot Process Location" is RECOMMENDED, but not
   mandatory for usage in this error.  Implementations MAY use another
   text string.

   An example of this 100 location error is here: is:

   Geolocation-Error: 100; code="Cannot Process Location";
                            node="bob.example.com";
                            inserter="alice.example.com";
   This category covers all 1XX location errors 1XX. errors.  The same basic actionable
   reaction is expected by when a location "inserter=" entity to receives any
   1XX location error.

4.3.2 Location Error: 200 "Retry Location Later" (same data) Later same data"

   The location error 200 "Retry Location Later" (same data) Later same data" indicates
   to a Geolocation-Error recipient that what they supplied in a
   request, as far as location is concerned, cannot be processed at
   this time, but there is no need to retry this request, without changing update the location
   information, at a later
   time - in a new SIP request.  It  For example, this location error is possible
   that
   appropriate when the Location Recipient cannot process location at this a
   specific time, or when there is there was a timeout during dereferencing, if an LbyR were sent. when a location
   URI is dereferenced.

   Action(s) to be taken by Geolocation-Error receiver to for a 2XX:
         Reactions to a 2XX location error are to try again, without
         having to update again after some
         period of time has elapsed. The "inserter=" has not identified
         problems with the location supplied originally.  There provided in the original request,
         so there is no constraints on how long this new try has need to wait, update this location unless
         there is a the
         requestor moves. A Retry-After header field MUST be present in a
         the 424 response. response indicating after how long the LR thinks it
         can process the location, the error recipient MUST obey this
         instruction.

   Implementations SHOULD choose to react by preparing, however this
   "inserter=" does or can, to queue queuing another message
   with the same location information, provided unless the "inserter=" does not move between
   the time of the original request and the transmission time of the
   new request. entity
   knows it has changed locations.

   Implementations MAY choose whether or not to inform the user of this error.  The text string
   of "Retry Location Later" Later same data" is RECOMMENDED, but not
   mandatory for usage in this error.  Implementations MAY use another text
   string to inform the user that location was not received by the UAS
   (i.e., the called party).

   An example of this 200 location error is here: is:

   Geolocation-Error: 200; code="Retry Location Later"; Later same data";
                            node="bob.example.com";
                            inserter="alice.example.com";

   This category covers all 2XX location errors 2XX. errors.  The same basic actionable
   reaction is expected by when a location "inserter=" entity to receives any
   2XX location error.

   If a SIP request has the "routing-allowed" header field parameter
   set to "no", and the SIP server believes processing location within the
   request is
   required in order to service the request properly, a 2XX location
   error is sent towards the recipient. This error is the proper error
   even when there is no location in the SIP request, but the SIP
   request contains a policy statement that location is not to be
   viewed during transit towards the ultimate destination.

4.3.3

4.3.2.1 Location Error: 300 "Retry Location Later" (device updated
      location) 201 "Linkable Target Identity Required"

   The location error 300 "Retry Location Later" (device updated
   location) indicates to a Geolocation-Error recipient that what they
   supplied in a request, as far as location code 201 "Linkable Target Identity Required" is concerned, cannot be
   processed at this time, but to retry this request, once
   specifically for the location
   information has been updated, event in which a new SIP request.

   Action(s) request requires a binding
   of the Target's identity to be taken by Geolocation-Error receiver the presence document in order to a 3XX:

         3XX location errors indicate know
   this is the "inserter=" SIP entity needs Target's location to refresh its location, or make the an appropriate routing
   decision.  Because Alice could include Bob's location information
         supplied more complete, without notifying in her SIP
   request, the user of SIP server - in this
         error.  3XX error are specific case - needs to be solved by without user
         intervention.

   This document gives no guidance how
   understand this message is accomplished, given the
   number of ways a UAC can learn its routed based on Alice's location, or a and not
   Bob's.  There is no absolute binding between presence documents and
   SIP intermediary
   can Sight signaling, hence a UAC, as defined in [RFC3693].

   This 300 location separate error currently does not indicate what exactly was
   wrong with specific behaviors are
   necessary.

   It is of particular importance is the location supplied, according emergency calling case,
   described here [ID-PHONE].  The presence document has a <presence>
   element containing an "entity=" attribute identifying who the
   presence document is about.  The PIDF-LO is a presence document.
   [RFC3693] allows unlinkable pseudonyms to be in the Location
   Recipient.  That "entity="
   attribute. This is left problematic for a future effort.

   Implementations MAY choose whether or not some (all?) source location based
   call routing situations.

   The node= routing intermediary makes this locationErrorValue a 201
   to inform the user of resolve this
   error.  The text string problem. In the 424 response, the Retry-After header
   value of "Retry Location Later" '0' is RECOMMENDED, REQUIRED, indicating the new request be sent
   immediately, but not mandatory for usage with a target identification resolved in this error.  Implementation MAY use
   another text string to inform the user that location was not
   received by
   PIDF-LO and SIP request. In presence, the UAS (i.e., entity= attribute is
   typically the called party).

   A 3XX location error would be used where URI of the Location Recipient
   cannot find or cannot parse presentity, meaning something like the location supplied, believing that a
   automated refresh and retry could fix
   Contact address of the problem.  Also, UAC here.

   If there is no Retry-After header value, the default is to resend
   the SIP request immediately with the corrected entity= attribute
   (i.e., emulating a 3XX
   location error would Retry-After: 0 header value).

   Action(s) to be used when taken by Geolocation-Error receiver for a Location Recipient did not find
   any 201:

         201 location in a SIP request, but was expecting it.  Perhaps an
   emergency request was made that error indicate the "inserter=" did not contain location.  The retry
   in this case would be in properly
         identify the form of an UPDATE Method request,
   containing location (LbyV or LbyR).

   An example Target of this location error is here:

   Geolocation-Error: 300; code="Retry Location Later";
                            node="bob.example.com";
                            inserter="alice.example.com";

   This category covers location errors 3XX. presence document.  The same basic actionable
   reaction
         Retry-After has been received - or is expected by a location "inserter=" entity assumed to any 3XX
   location error.

4.3.4 be 0 -
         meaning the new SIP request is to be sent immediately.

4.3.3 Location Error: 400 "Permission Necessary"

   The location error 400 "Permission Necessary" 300 "Retry Location Later with device updated
      location"

   The location error 300 "Retry Location Later with device updated
   location" indicates to a Geolocation-Error recipient that when what they sent
   supplied in a particular SIP request, they included as far as location in that is concerned, cannot be
   processed. In order to retry this request without giving
   permission in the request for a (or any) new SIP server to look at that request, the
   location information (i.e., the <retransmission-allowed> was set to
   "no" in the PIDF-LO for B2BUAs, or "routing-allowed=no" as a
   Geolocation header parameter for proxy servers) to route the message
   at the intended recipient (i.e., the UAS, or the called party). must be updated.

   Action(s) to be taken by Geolocation-Error receiver to for a 4XX:

         4XX 3XX:

         3XX location errors indicate to the UAC (i.e., the calling
         party) that they need to grant permission to a "inserter=" SIP
         intermediary server entity needs
         to look at refresh its location, or make the supplied location to
         complete information
         supplied more complete, without notifying the message routing.  This indication MUST require
         human user intervention, as the rulemaker of the policy on
         whether or not their location is to this
         error.  3XX errors may be revealed.

   The resolved without user of intervention.

   This document gives no guidance how this is accomplished, given the location "inserter=" device
   number of ways a UAC can choose to grant
   permission to this learn its location, or a SIP intermediary server to allow this request to
   be routed, or the user
   can deny this Sight a UAC, as defined in [RFC3693].

   This 300 location revelation (request by error currently does not indicate what exactly was
   wrong with the server).  It is location supplied, according to the user's choice as rulemaker. Location
   Recipient.  That is left for a future effort.

   Implementations MUST provide MAY choose whether or not to inform the user, as rulemaker, a clear
   indication that permission to consume their location is sought by an
   entity other than who that user is calling. of this
   error.  The text string of
   "Permission Necessary" "Retry Location Later with device updated
   location" is RECOMMENDED, but not mandatory for usage in this
   error.  Implementation MAY use another text string to inform the
   user that location is being sought was not received by an intermediary the UAS (i.e., not the called
   party).

   This document gives no guidance how this intervention is
   accomplished, given

   A 3XX location error would be used where the number of ways a UAC can accomplish this
   (i.e., audio prompt or toggle Location Recipient
   cannot find or keystroke on their UA).

   This 400 cannot parse the location error currently does not indicate exactly supplied. 3XX location
   errors should cause a requestor to retry with refreshed location
   information, which
   SIP server indicates it needs might be sufficient to fix the problem.  Also, a
   3XX location revealed.  That said, the
   "node=" FQDN address could error would be supplied, telling the user (via audio
   or video indication) which used when a Location Recipient was
   expecting to find location in a SIP entity wants this request, but did not find it -
   perhaps an emergency request was made that did not contain location.  Perhaps
   the user can know
   The retry in some circumstances whether this is an
   appropriate "node=" (domain).  All case would be in the form of this is left for an UPDATE Method
   request, containing location.  If the 424 response contains a future
   effort(s).
   Retry-After value, there SHOULD NOT be a long delay associated with
   a new request - under the guise that if the location had been good,
   there would not have been an error to this request.

   An example of this 300 location error is here: is:

   Geolocation-Error: 400; code="Permission Necessary"; 300; code="Retry Location Later with device
                            updated location";
                            node="bob.example.com";
                            inserter="alice.example.com";

   This category covers all 3XX location errors 4XX. errors.  The same actionable
   solution basic
   reaction is expected to be afforded to the UAC user, as rulemaker,
   to when a location "inserter=" entity receives any 4XX
   3XX location error.

4.3.5

4.3.4 Location Error: 500 "Location 400 "Permission to Reveal Location Information Denial" to
                           a Third Party"
   The location error 500 "Location 400 "Permission to Reveal Location Information Denial" to
   a Third Party" indicates to a Geolocation-Error recipient that what they supplied in
   sent a request, as
   far as location is concerned, has been denied at this time.
   This only has to do with the particular SIP Request including location in that the location "inserter="
   added to the request, and not about
   without giving permission in the overall request for an intermediary SIP
   entity to look at that location information (i.e., the
   <retransmission-allowed> was
   sent.  If this were applied set to "no" in the SIP request itself, this would
   equate to PIDF-LO for B2BUAs,
   or "routing-allowed=no" as a 6XX Global error. Geolocation header field parameter for
   proxy servers) to route the request toward the intended recipient
   (i.e., the UAS, or the called party).

   Action(s) to be taken by Geolocation-Error receiver to for a 1XX:
         This error gives no guidance on what to do next, other than to
         not try again with this same 4XX:

         4XX location supplied.

   If errors indicate to the Location Recipient believed UAC (i.e., the calling
         party) that merely refreshing, or in
   some other way alter or augment they need to grant permission to a SIP
         intermediary server to look at the location supplied would work in
   a new request, then a 3XX location error SHOULD have been returned
   (to to
         complete the "inserter=").  An example of why this 5XX could have been
   returned is if location were sent message routing.  This indication MUST require
         human user intervention, acting as an LbyR, and the LIS denied the
   dereference request from ruleholder of the Location (reference) Recipient, this is
   the expected
         policy on whether or not location error returned is to be revealed.

   The user of the location "inserter=" entity.

   Implementations MUST NOT interpret anything else into device can choose to grant
   permission to this location
   error other than it is considered a location based denial error.
   This does not mean the SIP intermediary server to allow this request was denied, to
   be routed, or even had an error,
   unless the response was a 424.  Otherwise, this only has to do with user can deny permission.  It is the location part of user's choice
   as ruleholder.

   Implementations MUST provide the request.

   The difference between a 1XX and user, as ruleholder, a 5XX clear
   indication that permission to consume their location error is simple.  A
   1XX location error sought by an
   entity that is a case of a Location Recipient either not
   knowing or not being able to tell the "inserter=" entity what was
   wrong with the location supplied in a SIP request.  Whereas, a 5XX
   location error is where the location was purposely, and actively
   denied (or declined) from being received by the Location Recipient
   entity, or its user.  This could occur in a UAS or SIP server.

   If implementations choose to inform that the UAC user of this error, the is calling.  The text
   string of "Location "Permission To Reveal Location Information Denial" to a Third
   Party" is RECOMMENDED, but not mandatory for usage in this error.
   Implementations MAY use another text string.

   An example of this location error is here:

   Geolocation-Error: 500; code="Location Information Denial";
                            node="bob.example.com";
                            inserter="alice.example.com";

   This category covers string to inform the user that
   location errors 5XX.  The same basic actionable
   reaction is expected being sought by an intermediary (i.e., not the called
   party).

   This document gives no guidance how the UAC can seek permission from
   the user, given the number of ways a location "inserter=" entity to any 5XX
   location error.

4.3.6 Which Scenario Matches Which Error Code?

   The following are some additional failure scenarios, with which
   error code SHOULD be used for consistency,

   - Scheme (sip:, or sips:, or pres:, or another one) of the LbyR URI
        isn't supported (100)
   - Format (geo or civic) isn't supported   (100)
   - Cannot parse location  (100)
   - Can't find LIS (no access UAC can accomplish this (i.e.,
   audio prompt or no path (100) toggle or denied access(500))
   - Dereference failed (timeout)   (200)
   - Insufficient keystroke on a UA).

   This 400 location info supplied   (300)
   - Cannot find error indicates exactly which SIP server indicates
   that it needs the location in message   (300)

4.4  The 'geolocation' Option Tag

   This document creates and IANA registers one new option tag:
   "geolocation".  This option tag is to be used, as defined in RFC
   3261, in by the Require, Supported and Unsupported headers.  Whenever a
   UA "node=" FQDN address supplied,
   perhaps telling the user (via audio or video indication) which SIP
   entity wants to indicate support for this SIP extension, location.  Perhaps the geolocation
   option tag is included user can know in a Supported header of the SIP request.

4.5 Using sip/sips/pres as a Dereference Scheme

   If some
   circumstances whether this is an LbyR URI appropriate "node=" (domain).  This
   latter feature is included not described in this document.

   An example 400 location error is:

   Geolocation-Error: 400; code="Permission to Reveal Location
                            Information to a SIP request, it MUST be a SIP-,
   SIPS- or PRES-URI.  When PRES: Third Party";
                            node="bob.example.com";
                            inserter="alice.example.com";

   This category covers all 4XX location errors.  The same resolution
   is used, if expected to be afforded to the resulting resolution, UAC user, as defined in [RFC3856], resolves to a SIP: or SIPS: URI, this
   section applies.

   This document IANA registers 3 mandatory to implement URI schemes
   for LbyR:

      o  SIP:
      o  SIPS:
      o  PRES:

   These 3 are IANA registered in Section 9.6.

   These schemes MUST be implemented according to this document.
   absoluteURI is not mandatory ruleholder, to implement.

   Dereferencing a Target's any
   4XX location using SIP- or SIPS-URI is
   accomplished by treating the URI as a PRES-URI and generating a
   SUBSCRIBE request to a presence server as defined in [RFC3856]
   using the 'presence' event package.  The resulting NOTIFY will
   contain the PIDF, rather MUST contain a PIDF-LO. See Figure 4. for a
   basic message flow for a dereference. error.

4.3.5 Location Error: 500 "Location Information Denial"

   The NOTIFY contains Alice's
   PIDF-LO in Figure 4.

   When used in this manner, SIP is a Using Protocol as defined in
   [RFC3693] and elements receiving location MUST honor the
   'usage-element' rules as defined in this extension.

     Alice                 Location Server                      Bob
       |                                                         |
       |                  INVITE w/ LbyR URI                     |
       |-------------------------------------------------------->|
       |                          |                              |
       |                       200 (OK)                          |
       |<--------------------------------------------------------|
       |                          |                              |
       |                          |  SUBSCRIBE error 500 "Location Information Denial" indicates to LbyR URI       |
       |                          |<-----------------------------|
       |                          |  200 (OK)                    |
       |                          |----------------------------->|
       |                          |                              |
       |                          |  NOTIFY   w/ PIDF-LO         |
       |                          |----------------------------->|
       |                          |  200 (OK)                    |
       |                          |<-----------------------------|
       |                          |                              |

           Figure 4. Location-by-Reference and Dereferencing

   In Figure 4., Alice sends Bob her location in an LbyR URI.  Bob
   receives this LbyR URI a
   Geolocation-Error recipient that what they supplied in the INVITE and generates a new transaction
   (SUBSCRIBE) to retrieve the PIDF-LO of Alice.  If accepted, the
   PIDF-LO will be in the NOTIFY request from the Location Server back
   to Bob's UA.  This is the first instance between Alice and Bob that
   Alice's location is in any message, therefore it is sent only once,
   from the Location Server to Bob.

   The SUBSCRIBE contains a geolocation option tag in either the
   Supported or Require header (depending on what strength of support
   the UAC wants to apply).  The NOTIFY MUST match the subscribing
   UAC's option-tag strength for geolocation.

   A dereference of an LbyR URI using SUBSCRIBE is not violating a
   PIDF-LO 'retransmission-allowed' element value set to 'no', as the
   NOTIFY is the only message in this multi-message set of transactions
   that contains the Target's location, with the location recipient
   being the only SIP element to receive this PIDF-LO. This is the
   purpose of this extension to SIP - to convey location to a specific
   destination.

5. Geolocation Examples

   This section contains are two examples of messages providing
   location.  One shows LbyV with coordinates, the other shows LbyR.
   The example for (Coordinate format) is taken from [RFC3825]. A
   civic format example of the same position on the earth request, as
   far as location is in the
   coordinate format example is in appendix B, which is taken from
   [RFC4776].  The differences between the two formats are within the
   <gp:location-info> of the examples.  Other than this portion of each
   PIDF-LO, the rest is the same for both location formats.

   The key to the provided samples is in the Geolocation header, which
   has a different type of URI, based on the different means of
   location conveyance.  Section 5.1 shows a "cid:" URI, indicating
   this SIP request contains an LbyV message body - which is in the
   form of a PIDF-LO.  Section 5.2 shows an LbyR URI indicating
   location is to be acquired via an indirection dereference mechanism,
   which is determined by the scheme of URI supplied.

5.1 Location-by-value (Coordinate Format)

   This example shows an INVITE message with a coordinate, or
   coordinate location.  In this example, the SIP request uses a
   sips-URI  [RFC3261], meaning this message is TLS protected on a
   hop-by-hop basis.

   INVITE sips:bob@biloxi.example.com SIP/2.0
   Via: SIPS/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bK74bf9
   Max-Forwards: 70
   To: Bob <sips:bob@biloxi.example.com>
   From: Alice <sips:alice@atlanta.example.com>;tag=9fxced76sl
   Call-ID: 3848276298220188511@atlanta.example.com
   Geolocation: <cid:target123@atlanta.example.com>
     ;inserted-by="alice@atlanta.example.com"
   Supported: geolocation
   Accept: application/sdp, application/pidf+xml
   CSeq: 31862 INVITE
   Contact: <sips:alice@atlanta.example.com>
   Content-Type: multipart/mixed; boundary=boundary1
   Content-Length: ...

   --boundary1

   Content-Type: application/sdp

   ...SDP goes here

   --boundary1

   Content-Type: application/pidf+xml
   Content-ID: <target123@atlanta.example.com>
   <?xml version="1.0" encoding="UTF-8"?>
      <presence xmlns="urn:ietf:params:xml:ns:pidf"
          xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10"
          xmlns:cl="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"
          xmlns:gml="http://www.opengis.net/gml"
          entity="pres:alice@atlanta.example.com">
        <dm:device id="target123">
         <timestamp>2007-12-02T14:00:00Z</timestamp>
         <status>
          <gp:geopriv>
            <gp:location-info>
              <gml:location>
                <gml:Point srsName="urn:ogc:def:crs:EPSG::4326">
                  <gml:pos>33.001111 -96.68142</gml:pos>
                </gml:Point>
               </gml:location>
            </gp:location-info>
            <gp:usage-rules>
              <gp:retransmission-allowed>no</gp:retransmission-allowed>
              <gp:retention-expiry>2007-12-07T18:00:00Z</gp:retention-
                            expiry>
            </gp:usage-rules>
            <gp:method>DHCP</gp:method>
            <gp:provided-by>www.example.com</gp:provided-by>
          </gp:geopriv>
         </status>
        </dm:device>
      </presence>
   --boundary1--

   The Geolocation header field from the above INVITE...

      Geolocation: <cid:target123@atlanta.example.com>

   ...indicates the content-ID location [RFC2392] within the multipart
   message body of where location information is, with SDP being the
   other message body part.  The "cid:" eases parsing of message
   bodies.

   If the Geolocation header field were this instead:

      Geolocation: <sips:server5.atlanta.example.com/target123>

   ...the presence of something other than "cid:" indicates an LbyR is
   included in concerned, has been denied at this message.  It is expected that any node wanting time.
   This only has to
   know where user "target123" is would subscribe do with the location that the location "inserter="
   added to server5 the request, and not about the overall request that was
   sent.  If this were applied to
   dereference the sips-URI (see Figure 4 for SIP request itself, this message flow, and
   Section 5.2 would
   equate to a 6XX Global error.

   Action(s) to be taken by Geolocation-Error receiver for a 5XX:
         This error gives no guidance on what to do next, other than to
         not try again with this decoded example). The returning NOTIFY would
   contain Alice's same location supplied.

   If the Location Recipient determined that merely refreshing, or in
   some other way alter or augment the location supplied would work in
   a PIDF-LO, as new request, then a 3XX location error would have been more
   appropriate.  An example of why this 5XX could have been returned is
   if it location were included in sent as a
   message body  (part) of location URI, and the original INVITE here.

5.2 Location-by-reference

   Below is an INVITE LS denied the
   dereference request with an LbyR URI instead of an LbyV
   PIDF-LO message body part shown in Section 5.1.  It from the potential Location Recipient, this is up to
   the expected location recipient error returned to the "inserter=" entity.  In
   all likelihood, this is a dereference Alice's function error, meaning this
   will not occur when location at is carried by-value in the Atlanta
   LIS server containing request.

   Implementations MUST NOT make any assumptions about the implications
   of this location record.  Dereferencing, if done
   with SIP, is accomplished by the Location Recipient sending error other than recognizing that a
   SUBSCRIBE request to the URI reference for Alice's location.  The
   received NOTIFY is location based
   denial error has occurred.  This does not mean the first SIP request containing Alice's UA
   location, as was
   denied, or even had an error, unless the response was a PIDF-LO message body (see Figure 4 for 424.
   Otherwise, this message
   flow example). only has to do with the location part of the
   request.

   The NOTIFY, in this case, difference between a 1XX and a 5XX location error is the SIP request that simple.  A
   1XX location error is
   conveying location, and appropriate when a Location Recipient either
   does not know or cannot tell the "inserter=" entity what was wrong
   with the INVITE.  There is no retransmission
   of location supplied in this usage.

   INVITE sips:bob@biloxi.example.com SIP/2.0
   Via: SIP/2.0/TLS pc33.atlanta.example.com
     ;branch=z9hG4bK74bf9
   Max-Forwards: 70
   To: Bob <sips:bob@biloxi.example.com>
   From: Alice <sips:alice@atlanta.example.com>;tag=9fxced76sl
   Call-ID: 3848276298220188511@atlanta.example.com
   Geolocation: <sips:3sdefrhy2jj7@lis.atlanta.example.com>
     ;inserted-by="bigbox3.atlanta.example.com"
   Supported: geolocation
   Accept: application/sdp, application/pidf+xml
   CSeq: 31862 INVITE
   Contact: <sips:alice@pc33.atlanta.example.com>

   (...SDP goes here as the only message body) a SIP request.  A 5XX location error
   is appropriate when the Location Recipient would need to dereference the sips-URI in the
   Geolocation header field to retrieve Alice's location.  If was purposely and
   actively prevented from retrieving the
   atlanta.example.com domain chooses to implement location conveyance
   and delivery information.  This
   could occur in this fashion (i.e., LbyR), it is RECOMMENDED that
   entities outside this domain be able a UAS or SIP server.

   If implementations choose to reach inform the dereference
   server, otherwise UAC user of this model error, the
   text string of implementation "Location Information Denial" is only viable within
   the atlanta.example.com domain.

6.  SIP Element Behavior

   Because a device's RECOMMENDED, but not
   mandatory for usage in this error.  Implementations MAY use another
   text string.

   An example of this location error is generally considered to be sensitive
   in nature, here:

   Geolocation-Error: 500; code="Location Information Denial";
                            node="bob.example.com";
                            inserter="alice.example.com";

   This category covers 5XX location information needs to be protected errors.  The same basic reaction
   is expected when
   transmitted.  This can be addressed through securing the a location
   information to prevent either viewing "inserter=" entity receives any 5XX
   location error.

4.3.6 Which Scenario Matches Which Error Code?

   The following scenario/error code mapping MUST be used for
   consistency,

   - Scheme (sip:, or changing the PIDF-LO.

   Section 26 sips:, or pres:, etc.) of [RFC3261] defines the security functionality SIPS by
   transporting SIP messages with either TLS location URI
        isn't supported - (100)
   - Format (geo or IPSec protection
   between SIP entities.

   If a SIP entity wants to prevent all SIP entities civic) isn't supported - (100)
   - Found where location should be, but do not understand what is
        there -(300)
   - Cannot find LS in a request path
   from viewing location URI (no access or just changing the contents of the PIDF-LO, save
   those that possess decryption key, the message body needs no path) - (100) or
     denied access - (500))
   - Dereference failed (timeout) - (200)
   - Insufficient location info supplied - (300)

4.4  The 'geolocation' Option Tag

   This document creates and IANA registers one new option tag:
   "geolocation".  This option tag is to be
   secure by a means such used, as S/MIME.  This would be the case defined in
   [RFC3261], in which a
   UAC wants to make sure only the destination UAS can read the
   PIDF-LO.

6.1 UAC Behavior

   A UAC can send location Require, Supported and Unsupported header fields.

4.5 Using sip/sips/pres as a Dereference Scheme

   If an LbyR URI is included in a SIP request, either because it MUST be a SIP-,
   SIPS- or PRES-URI.  When PRES: is
   expected to facilitate location-based routing of used, if the request, or
   spontaneously (i.e., for a purpose not resulting resolution,
   as defined in [RFC3856], resolves to a SIP: or SIPS: URI, this
   section applies.

   This document but
   known to the UAC).  Alice communicating her location to Bob IANA registers 3 mandatory-to-implement URI schemes
   for LbyR:

      o  SIP:
      o  SIPS:
      o  PRES:

   These 3 are registered with IANA in a SIP
   request Section 9.6.

   These schemes MUST be implemented according to this document.

   absoluteURI is not mandatory-to-implement.

   Dereferencing a simple example of this.  If Alice wanted to include her Target's location using SIP- or SIPS-URI is
   accomplished by treating the URI as a message body in an INVITE that also has an SDP message
   body, the Content-Type: Multipart MUST be supported by both UAC and
   UAS.  Multipart comes in many forms (/mixed, /alternative, etc), PRES-URI and
   this document does not limit which type of multipart is used, though
   future documents MAY specify or limit multipart generating a
   SUBSCRIBE request to a subset of all presence server as defined in [RFC3856]
   using the choices for a given use.

   A UAC conveying location 'presence' event package.  The resulting NOTIFY MUST include
   contain a locationValue in PIDF-LO. See Figure 4 for a
   Geolocation header (see section 4.1) with either an LbyV indication
   (a cid-URL), or an LbyR.  An LbyV basic message body sent without flow for a
   Geolocation header field MUST NOT occur.
   dereference. The UAC supporting NOTIFY contains Alice's PIDF-LO in Figure 4.

   When used in this
   extension manner, SIP is a Using Protocol as defined in
   [RFC3693] and elements receiving location MUST include a Supported header with honor the 'geolocation'
   option tag.

   More than one location format (civic and coordinate) can be included
   'usage-element' rules as defined in the same message body part, but all this specification.

     Alice                 Location Server                      Bob
       |                                                         |
       |               INVITE w/ Location URI                    |
       |-------------------------------------------------------->|
       |                          |                              |
       |                       200 (OK)                          |
       |<--------------------------------------------------------|
       |                          |                              |
       |                          |  SUBSCRIBE to location parts of the same URI   |
       |                          |<-----------------------------|
       |                          |  200 (OK)                    |
       |                          |----------------------------->|
       |                          |                              |
       |                          |  NOTIFY   w/ PIDF-LO MUST point at the same position on the earth, identifying
   the same target.  The same         |
       |                          |----------------------------->|
       |                          |  200 (OK)                    |
       |                          |<-----------------------------|
       |                          |                              |

           Figure 4. Location-by-Reference and Dereferencing

   In Figure 4, Alice sends Bob her location in multiple formats, for
   example, a partial or complete geodetic location URI.  Bob
   receives this location URI in the INVITE and generates a partial or complete
   civic, can allow the recipient new
   transaction (SUBSCRIBE) to use the most convenient or
   preferable format for its use.

   Multiple PIDF-LOs are allowed in retrieve Alice's PIDF-LO.  If accepted,
   the same request, with each allowed
   to point at separate positions - however, each PIDF-LO MUST identify
   a different Target.  Therefore, there will be no confusion by a
   Location Recipient receiving more than one PIDF-LO (in a message
   body or when dereferenced, or a combination).  It is RECOMMENDED
   there is only one locationValue returned in a single SIP the NOTIFY request for from the same
   Target.  More than one will likely lead to confusion by a Location
   Recipient because this extension does not provide guidance on what a
   recipient
   Server to Bob's UA.  This is to do with more than one location, nor does it give any
   preference regarding which the first instance between Alice and
   Bob that Alice's location is better or worse than another
   location in any message, therefore it is sent
   only once, from the same request. Location Server to Bob.

   The 'geolocation' SUBSCRIBE contains a geolocation option tag is inserted in a either the
   Supported or Require header by a
   UAC to provide an indication field (depending on what strength of
   support for this extension. the UAC requires).  The
   presence of NOTIFY MUST match the 'geolocation' option tag in a Supported header
   without subscribing
   UAC's option-tag strength for geolocation.

   A dereference of an LbyR URI using SUBSCRIBE is not violating a Geolocation header field in
   PIDF-LO 'retransmission-allowed' element value set to 'no', as the same
   NOTIFY is the only message informs a in this multi-message set of transactions
   that contains the Target's location, with the location recipient
   being the only SIP element receiving to receive this request that PIDF-LO. This is the UAC understands
   purpose of this
   extension, but it does not know or wish extension to SIP - to convey its location at
   this time.  Certain scenarios exist (location-based retargeting) to a specific
   destination.

5. Geolocation Examples

   This section contains are two examples of messages providing
   location.  One shows LbyV with coordinates, the other shows
   dereferencable location URI. The example for (Coordinate format) is
   taken from [RFC3825]. A Civic-format example of the same position on
   the earth as is in the coordinate format example is in appendix B,
   which is taken from [RFC4776].  The differences between the two
   formats appear within the <gp:location-info> in the examples.  Other
   than this portion of each PIDF-LO, the rest is the same for both
   location formats.

   The key to the provided samples is required in the Geolocation header field,
   which has a different type of URI, based on the different means of
   location conveyance.  Section 5.1 shows a "cid:" URI, indicating
   this SIP request contains an LbyV message body - which is in order the
   form of a PIDF-LO.  Section 5.2 shows an LbyR URI indicating
   location is to retarget be acquired via an indirection dereference mechanism,
   which is determined by the
   message properly. scheme of URI supplied.

5.1 Location-by-value (Coordinate Format)

   This affects how example shows an INVITE message with a UAS or coordinate location.  In
   this example, the SIP server processes
   such request uses a request. sips-URI  [RFC3261], meaning
   this message is protected using TLS on a hop-by-hop basis.

   INVITE sips:bob@biloxi.example.com SIP/2.0
   Via: SIPS/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bK74bf9
   Max-Forwards: 70
   To: Bob <sips:bob@biloxi.example.com>
   From: Alice <sips:alice@atlanta.example.com>;tag=9fxced76sl
   Call-ID: 3848276298220188511@atlanta.example.com
   Geolocation: <cid:target123@atlanta.example.com>
     ;inserted-by="alice@atlanta.example.com"
     ;routing-allowed=no
   Supported: geolocation
   Accept: application/sdp, application/pidf+xml
   CSeq: 31862 INVITE
   Contact: <sips:alice@atlanta.example.com>
   Content-Type: multipart/mixed; boundary=boundary1
   Content-Length: ...

   --boundary1

   Content-Type: application/sdp

   ...SDP goes here
   --boundary1

   Content-Type: application/pidf+xml
   Content-ID: <target123@atlanta.example.com>
   <?xml version="1.0" encoding="UTF-8"?>
      <presence xmlns="urn:ietf:params:xml:ns:pidf"
          xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10"
          xmlns:cl="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr"
          xmlns:gml="http://www.opengis.net/gml"
          entity="pres:alice@atlanta.example.com">
        <tuple id="target123">
         <status>
         <timestamp>2009-07-13T09:00:00Z</timestamp>
          <gp:geopriv>
            <gp:location-info>
              <gml:location>
                <gml:Point srsName="urn:ogc:def:crs:EPSG::4326">
                  <gml:pos>33.001111 -96.68142</gml:pos>
                </gml:Point>
               </gml:location>
            </gp:location-info>
            <gp:usage-rules>
              <gp:retransmission-allowed>no</gp:retransmission-allowed>
              <gp:retention-expiry>2009-07-29T18:00:00Z</gp:retention-
                            expiry>
            </gp:usage-rules>
            <gp:method>802.11</gp:method>
a          </gp:geopriv>
         </status>
        </tuple>
      </presence>
   --boundary1--

   The 'geolocation' option tag SHOULD NOT be used in Geolocation header field from the Proxy-Require
   Header, because above INVITE:

      Geolocation: <cid:target123@atlanta.example.com>

   ... indicates the UAC often will not know content-ID location [RFC2392] within the underlying topology
   to know which proxy will do multipart
   message body of where location information is, with SDP being the retargeting, thus increasing
   other message body part.  The "cid:" eases message body parsing.

   If the Geolocation header field did not contain a "cid:" scheme, for
   example, like this location URI:

      Geolocation: <sips:server5.atlanta.example.com/target123>

   ... the
   likelihood existence of a request failure by the first hop proxy that does not
   understand non-"cid:" scheme indicates this extension, but is required a
   location URI, to by inclusion of be dereferenced to learn the
   option tag in this header.

   A UAC inserting a locationValue MUST include an "inserted-by="
   parameter target's location. Any
   node wanting to indicate its hostport.  This know where user "target123" is copied would subscribe to
   server5 to dereference the
   "inserter=" parameter of the Geolocation-Error header sips-URI (see Figure 4 for this message
   flow, and Section 5.2 for this decoded example). The returning
   NOTIFY would contain Alice's location in a response PIDF-LO, as if a Location Recipient determines there is something wrong with the
   locationValue it were
   included in this request.  Because more than one locationValue
   can be inserted along the path a message body  (part) of the request, this indication original INVITE.

5.2 Location-by-reference

   Below is
   necessary to show which locationValue had the problem an INVITE request with a location URI that is not a "cid:"
   - instead of an LbyV PIDF-LO message body part as shown in Section
   5.1.  The Location Recipient will dereference Alice's location at
   the
   response, and who Atlanta Location Server the locationErrorValue is for.  For example:

   Geolocation: <cid:alice123@atlanta.example.com>;
                 inserted-by="alice@atlanta.example.com"

   If a UAC does not learn and store its location locally (a GPS chip)
   or from URI is pointing towards.
   Dereferencing, if done using SIP, is accomplished by the network (DHCP or LLDP-MED), Location
   Recipient sending a SUBSCRIBE request to the UAC MAY learn its LbyR URI (from DHCP reference for
   Alice's location.  The received NOTIFY is the first SIP request
   containing Alice's UA location, as a PIDF-LO message body (see
   Figure 4 for this message flow example).  If The NOTIFY, in this case,
   and not the latter INVITE, is the case, SIP request that is conveying location.
   There is no retransmission of location in this usage.

   INVITE sips:bob@biloxi.example.com SIP/2.0
   Via: SIP/2.0/TLS pc33.atlanta.example.com
     ;branch=z9hG4bK74bf9
   Max-Forwards: 70
   To: Bob <sips:bob@biloxi.example.com>
   From: Alice <sips:alice@atlanta.example.com>;tag=9fxced76sl
   Call-ID: 3848276298220188511@atlanta.example.com
   Geolocation: <sips:3sdefrhy2jj7@lis.atlanta.example.com>
     ;inserted-by="bigbox3.atlanta.example.com"
     ;routing-allowed=no
   Supported: geolocation
   Accept: application/sdp, application/pidf+xml
   CSeq: 31862 INVITE
   Contact: <sips:alice@pc33.atlanta.example.com>

   (...SDP goes here as the UAC can
   SUBSCRIBE only message body)

   A Location Recipient would need to this LbyR URI, using dereference the 'presence' event package, sips-URI in the
   Geolocation header field to
   get and store its own retrieve Alice's location.

   The act of dereferencing a Target's LbyR will be challenged by  If the
   LIS where this
   atlanta.example.com domain chooses to implement location record conveyance
   and delivery in this fashion, it is - providing a good deal of
   protection, SHOULD still RECOMMENDED that entities
   outside this domain be treated as equivalent able to possession of reach the dereference server, unless
   location information itself and thus TLS SHOULD be used when
   transmitting LbyR hop-by-hop along the path to is intentionally restricted within the Location
   Recipient, for protection reasons.  This atlanta.example.com
   domain.

6.  SIP Element Behavior

   Because a device's location is not generally considered to be confused with
   a possession model, sensitive
   in which possessing the LbyR grants
   authorization to dereference the URI.  Any entity dereferencing the
   LbyR MUST pass whatever authentication and authorization rules are
   on the LIS for this nature, location record.  The Ruleholder from [RFC3693]
   is still very much in control - for any entity possessing the LbyR.

   If information needs to be protected when
   transmitted.  This can be addressed through securing the Location Generator wishes to control whether any location
   included in the SIP request
   information to prevent either viewing or added along changing the signaling path PIDF-LO.

   Section 26 of
   this request can be viewed for routing decisions, [RFC3261] defines the Location
   Generator adds SIPS security functionality by
   transporting SIP messages with either TLS protection between SIP
   entities.

   If a Geolocation header value including SIP entity wants to prevent all SIP entities in a request path
   that do not possess a decryption key from viewing or changing the
   "routing-allowed=no" parameter.  This header parameter provides
   specific policy rules for each locationValue (if there is more than
   one inserted along
   contents of the signaling path) within PIDF-LO, the SIP request. message body needs to be secure by a
   means such as S/MIME.

6.1 UAC Behavior

   A UAC SHOULD include the "routing-allowed" header parameter, with or
   without a locationValue, might choose to each send location in a SIP request supporting this
   specification to ensure the UAC's policy for intermediaries which
   might add a locationValue facilitate
   location-based routing of the Target downstream.  The UAC
   understands that the default behavior request, or for some other purpose.
   Alice communicating her location to Bob in a SIP servers request is a simple
   example of this.  If Alice wanted to consider
   this value to be present, and include her location as a
   message body in an INVITE that it is set to "no".

   The UAC also has an SDP message body, the
   Content-Type: Multipart MUST understand there be supported by both UAC and UAS.
   Multipart comes in many forms (/mixed, /alternative, etc), and this
   document does not limit which type of multipart is no feedback mechanism used, though
   future documents might  specify or limit multipart to inform a subset of
   all the
   Target if choices for a SIP server has included given use.

   A UAC conveying location MUST include a locationValue downstream.

   If in a
   Geolocation header (see section 4.1) with either an LbyV indication
   (a cid-URL), or a dereferencable location URI.  Requests containing
   an LbyV message body sent MUST also contain a Geolocation header
   field.  The UAC has already conveyed supporting this extension MUST include a Supported
   header with the 'geolocation' option tag.

   More than one location format (civic and coordinate) can be included
   in the original request same message body part, but all location parts of the same
   PIDF-LO MUST point at the same position on the earth, identifying
   the same target.  The same location in multiple formats, for
   example, a
   transaction, partial or complete geodetic and wants a partial or complete
   civic, allows the recipient to update select the most preferred format for
   its use.  Additional complementary location information (for
   whatever reason) after the original request is sent, or after a
   dialog is created (regardless of how can be in
   the UAC conveyed location
   previously, second format as an LbyV or LbyR) - this is done by a UAC sending an
   UPDATE request [RFC3311] containing well.

   Multiple PIDF-LOs are allowed in the geolocation option tag and
   Geolocation header same request, with the new locationValue (LbyV or LbyR) each allowed
   to point at separate positions - however, each PIDF-LO MUST identify
   a different Target (i.e., in the
   original destination UAS.

   A PIDF includes identity information.  It is possible for entity= attribute in the
   identity <presence>
   element of the presence document).  Therefore, there will be no
   confusion by a Location Recipient receiving more than one PIDF-LO
   (in a message body or when dereferenced, or a combination).  A SIP
   request SHOULD include only one location per target in the PIDF a single SIP
   request.  More than one will likely lead to be anonymous.  Implementations of confusion by a Location
   Recipient because this extension SHOULD consider the appropriateness of including an
   anonymous identity in the location information where does not provide guidance on what a real identity
   recipient is not required.  When using LbyR, to do with more than one location for the LbyR MUST NOT contain same target
   (which could point to different positions), nor does it give any
   user identifying information. For example, use something
   unidentifiable like

      3fg5t5yqw@example.atlanta.com

   rather than

      aliceishere@example.atlanta.com).

   Use of self-signed certificates
   preference regarding which location is inappropriate for use more or less reliable than
   another location in
   protecting a PIDF, as the sender does not have a secure identity same request.

   The presence of the recipient.

   Mentioned in more detail in later 'geolocation' option tag in section 6.2, SIP MUST NOT
   attempt to overcome rules and behaviors conveyed a Supported header
   field without a Geolocation header field in the same message informs
   a PIDF-LO.
   Therefore, UACs SHOULD take care when setting their
   <retransmission-allowed> flag to "yes", as when Alice tells Bob her
   location with SIP element receiving this flag set to "yes", as long as request that the
   <retention-expiry> time is UAC understands this
   extension, but it does not indicating the location information
   needs know or wish to be deleted - Bob convey its location at
   this time.  Certain scenarios exist (location-based retargeting) in
   which location is free required in a SIP request in order to tell Carol where Alice is.
   This is an implicit byproduct of how retarget the PIDF-LO rule-set is, as of
   this writing. This is
   message properly.  Indicating support with a configuration issue, but something worth
   mentioning here.

6.1.1 UAC Receiving geolocation option tag
   affects how a Location Failure Indication

   Location Recipients can be either, UAS or both, destination UASs and
   intermediate servers SIP server processes such a request. For
   example, it ought to understand that use erroring the location information for
   location-based routing decisions.  If a sent request fails based on
   the because
   there was no location information in the request, a 424 (Bad Location
   Information) response request is sent back likely not going to result
   in the UAC. location appearing in the subsequent request.

   The 424 MUST have a
   Geolocation-Error header containing one or more locationErrorValues 'geolocation' option tag SHOULD NOT be used in the response message.  A locationErrorValue has a Proxy-Require
   header
   parameter indicating which entity inserted field, because often the locationValue
   correlated UAC will not know the underlying
   topology to this error, called know which proxy will do the "inserter=" parameter.  This
   "inserter=" parameter (in retargeting, thus
   increasing the locationErrorValue) likelihood of a request failure at the first hop
   proxy that does not understand this extension, as is copied from required by
   inclusion of the option tag in this header field.

   A UAC inserting a locationValue MUST include an "inserted-by="
   parameter (from to indicate its hostport.  This is copied to the locationValue) by
   "inserter=" parameter of the Geolocation-Error header field in a
   response if a Location Recipient (UAS or proxy) sending determines there is something wrong
   with the error response.  A UAC
   receiving a Geolocation-Error locationValue in any response type MUST review this request.  Because more than one
   locationValue can be inserted along the path of the request, this
   indication is necessary to show which locationValue had the
   "inserter=" parameter problem
   in the locationErrorValue to see if it
   indicates this UAC.  If locationErrorValue does not match, response, and who the locationErrorValue MUST be ignored. If a locationErrorValue is in for.  For
   example:

   Geolocation: <cid:alice123@atlanta.example.com>;
                 inserted-by="alice@atlanta.example.com"

   If a
   424, UAC does not learn and store its location locally (a GPS chip)
   or from the "inserter=" entity is not this UAC, network (DHCP or LLDP-MED), the response SHOULD
   be treated as a 400 response.  If locationErrorValue does indicate
   this UAC, this UAC MUST process MAY learn its
   location URI (from DHCP for example).  If the response, including latter is the case,
   the
   Geolocation-Error code  (defined in section 4.3).  Further, UAC MUST
   ignore a Geolocation-Error header value, even for can SUBSCRIBE to this UAC, even in
   a 424 response if location URI, using the UAC did not include 'presence'
   event package, to get and store its own location.

   The Location Server will likely challenge requests to dereference a Geolocation header value
   (with locationValue) in the request part
   Target's location URI. The location URI SHOULD be treated as
   equivalent to possession of the transaction.

   A UAC MAY reattempt a new request if it believes it can correct the
   stated failure in location information itself and thus
   TLS SHOULD be used when transmitting any location URI hop-by-hop
   along the Geolocation-Error header, unless path to the location
   error Location Recipient, for protection reasons.
   This is a 5XX level error - which clearly states in Section 4.3 not to do this.  A UAC MUST follow all be confused with a 'possession model', in which
   possessing the guidance that pertains to
   UACs from Section 4.3 (Geolocation-Error header), heeding what location URI grants authorization to do
   in case it receives any of dereference the error codes articulated in that
   section.
   URI.  Any UAC that inserted entity dereferencing the location into a request SHOULD be prepared to
   receive URI MUST pass whatever
   authentication and authorization rules are on the Geolocation-Error header in any response, looking LS to
   determine if a locationErrorValue acquire this
   location.  The Ruleholder from [RFC3693] is meant still very much in
   control - for any entity possessing the UAC, and to react
   accordingly. LbyR.

   If a UAC includes location in a request, and either the UAS does not
   determine errored location was critical Location Generator wishes to control whether any location
   included in the transaction and
   accept the request, SIP request or added along the signaling path of
   this request failed can be viewed for reason other than
   location, any response MAY contain routing decisions, the Location
   Generator adds a Geolocation-Error Geolocation header
   containing a locationErrorValue with the details of the location
   error.

6.2 UAS Behavior

   If field value including the Geolocation
   "routing-allowed=no" parameter.  This header field parameter
   provides specific policy rules for each locationValue (if more than
   one locationValue is present in a received SIP
   request, inserted along the type of URI contained in signaling path) within the locationValue will
   indicate if location is an LbyV in a message body (part) or LbyR,
   requiring an additional dereference transaction.  If
   SIP request.  A UAC SHOULD include the LbyR URI is
   sip:, sips: "routing-allowed" header
   field parameter, with or pres:, and the UAS wants without a locationValue, to learn each SIP
   request supporting this specification to ensure the UAC's location, policy for
   intermediaries which might add a locationValue of the UAS MUST initiate Target
   downstream.  The default behavior for SIP servers is to consider
   this value to be present, with a SUBSCRIBE to the URI provided value of "no".

   There is no feedback mechanism to retrieve
   the PIDF-LO being conveyed by inform the UAC as defined in  [RFC3856]. Target if a SIP server
   has included a locationValue downstream. If
   successful, the PIDF-LO will be returned a UAC has already
   conveyed location in the NOTIFY original request from
   the remote host.  The UAS is not REQUIRED of a transaction, and
   wants to dereference update its location information (for whatever reason) after
   the LbyR if
   it does not want to (by configuration original request is sent, or user choice).  It after a dialog is
   RECOMMENDED the UAS render the location sent to it, however it created, this is
   configured to do so.

   A Require
   done by sending an UPDATE request [RFC3311]. The UPDATE will include
   a geolocation option tag and Geolocation header field with the 'geolocation' option tag indicates new
   locationValue to the
   UAC is requiring original destination UAS.

   A presence document includes identity information (in the UAS understand "entity="
   attribute of the <presence> element), although the identity could be
   an unlinkable pseudonym [RFC3693].  Implementations of this
   extension or else send
   an error response.  A 420 (Bad Extension) with a 'geolocation'
   option tag in SHOULD consider the appropriateness of including an Unsupported header would be
   unlinkable pseudonym as the appropriate
   response identity in this case.

   It is possible, but undesirable, for the location information
   where a message real identity is not required.  See the concerns raised in
   section 4.3.2 about unlinkable pseudonyms in relation to arrive with a body
   containing an LbyV, but their
   potential problems with no Geolocation header field value
   pointing requests that need to it (potentially no Geolocation header field at all). In
   this case, route based on the recipient MAY still read and use
   location contained in the message.

   When using LbyR, the message body.
   Unless stated otherwise by future standards-track publication(s), a
   LbyR location URI only has meaning within the Geolocation header field and MUST NOT appear in contain any other SIP header field.

   There are 3 Geolocation header parameters,

      o "inserted-by="
      o "used-for-routing"
      o "routing-allowed"

   The "inserted-by=" parameter informs a Location Recipient which SIP
   element added this locationValue to the SIP request.  This parameter user
   identifying information. For example, use something unidentifiable
   like

      3fg5T5yqWowhGLn54wg4NgHlkDsFn@example.atlanta.com

   rather than

      aliceishere@example.atlanta.com).

   Use of self-signed certificates is mandatory inappropriate for each locationValue use in
   protecting a PIDF, as the request.  The value in sender does not have a secure identity of
   the "inserted-by=" parameter recipient.

   Although this is copied into the "inserter="
   parameter discussed in each locationErrorValue if there is an error more detail in the later in section 6.2,
   SIP entities MUST NOT bypass rules and behaviors conveyed in a
   PIDF-LO.  UACs SHOULD take care when setting their
   <retransmission-allowed> flag to "yes". When Alice tells Bob her
   location with this flag set to be reported back "yes", Bob is free to tell Carol
   where Alice is (as long as the <retention-expiry> time has not
   elapsed, indicating that the location sender.  See section
   6.2.1.

   The "used-for-routing" parameter information should be
   deleted).  This is included in an implicit byproduct of the locationValue if PIDF-LO rule-set, as
   of this writing. This decision is a SIP server used configuration issue, but is
   worth mentioning here.

6.1.1 UAC Receiving a Location Failure Indication

   Location Recipients that use the location in the request to determine how to
   route information for
   location-based routing decisions can be either destination UASs or forward the message towards the ultimate destination.  If
   there are more than one locationValues
   intermediate servers.  If a request fails based on the location
   information in the Geolocation header,
   and it request, a 424 (Bad Location Information)
   response is possible that different locationValues were used sent back to route
   the message at different times of this request's journey.  This is
   allowed, as it is consistent with the rule that anytime a message is
   routed based upon UAC.  The 424 MUST have a locationValue,
   Geolocation-Error header field containing one or more
   locationErrorValues in the response message.  A locationErrorValue
   has a "used-for-routing" header field parameter is
   added indicating which entity inserted the
   locationValue correlated to this error, called the applicable locationValue. "inserter="
   parameter.  This "inserter=" parameter should be
   present in each locationValue used along (in the path. locationErrorValue)
   is copied from the "inserted-by=" parameter (from the locationValue)
   by the Location Recipient (UAS or proxy) sending the error response.
   A
   "used-for-routing" UAC receiving a Geolocation-Error in any response type MUST check
   whether the "inserter=" parameter in the locationErrorValue
   indicates this UAC.

   o  If locationErrorValue does not match, the locationErrorValue
      MUST NOT ever be removed from a
   locationValue in ignored.

   o  If a request.

   The "routing-allowed" parameter locationErrorValue is exclusively for SIP servers, and
   will be discussed in section 6.3.

   Additional locationValues inserted into a request SHOULD be placed
   the order they were generated, 424, and the "inserter=" entity
      is not rearranged.  This informs a
   Location Recipient which was this UAC, the last locationValue in response SHOULD be treated as a 400
      response.

   o  If locationErrorValue does indicate this UAC, this UAC MUST
      process the message
   that was used to route response, including the message.  This is for troubleshooting and
   management reasons.

   Individual header parameters Geolocation-Error code
      (defined in any received locationValue MUST NOT
   be modified or deleted section 4.3), taking the action described in transit to that
      section for the ultimate destination.

   A UAS received error code.

   Additionally, the UAC MUST NOT send location ignore a Geolocation-Error header field
   value, even for this UAC, even in a 424 response message, as there can be
   any number of issues/problems with receiving location, and if the UAC
   or proxy servers cannot error did not
   include a response.  Therefore, Geolocation header field value (with locationValue) in the UAS,
   request part of the transaction.

   A UAC MAY reattempt a new request if it
   wants to send can correct the stated
   failure in the Geolocation-Error header field, unless the location
   error is a 5XX level error - Section 4.3 clearly states not to do
   this.  A UAC its location, SHOULD MUST follow all the guidance that pertains to UACs from
   Section 4.3 (Geolocation-Error Header Field), heeding what to do so
   when it receives any of the error codes articulated in that section.

   Any UAC that inserted location into a new request MUST be prepared to
   receive the Geolocation-Error header field in a
   separate transaction.  This document gives no guidance which SIP
   request any response, looking
   to use, but SIP MESSAGE is determine if a viable choice.

   A UAS MAY include locationErrorValue is meant for the UAC, and to
   react accordingly.

   If a 'geolocation' option tag UAC includes location in the Supported header
   of a response, indicating it request, and either the UAS does understand this extension, even if not
   determine errored location was not in a request critical to the UAS.

   A transaction and
   accept the request, or the request failed for reason other than
   location, any response MAY contain a Geolocation-Error header field
   containing a locationErrorValue with the details of the location
   error.

6.2 UAS wishing to dereference an LbyR URI contained Behavior

   If the Geolocation header field is present in a received
   request will use SIP
   request, the 'presence' event package type of URI contained in a SUBSCRIBE request
   to the URI.  If accepted, the PIDF-LO locationValue will return to the UAS
   indicate if location is in a
   NOTIFY request.  If there are any errors during dereferencing, message body (part) or in requires an
   additional dereference transaction.  If the PIDF-LO itself, location URI is sip:,
   sips: or pres:, and the UAS will error the original request wants to learn the
   UAC with a locationErrorValue indicating what UAC's location, the
   UAS concluded was
   wrong with the location.  This is MUST SUBSCRIBE to include any dereferencing
   problems encountered.

   Section 4.5 of this document called for the IANA registration of 3 provided URI schemes (sip:, sips:, and pres:) that are mandatory to implement
   for dereferencing.

   A UAS MUST be prepared to receive subsequent location updates from retrieve the UAC, either LbyV or LbyR (regardless of how PIDF-LO being
   conveyed by the UAS received
   location previously from this UAC).  The UAC as defined in  [RFC3856].  If successful, the
   Target's PIDF-LO will convey location
   using be returned in the UPDATE [RFC3311] method to NOTIFY request from the UAS, and not a reINVITE.

   If there
   remote host.  The UAS is more than one location (any combination of LbyV and
   LbyR), this document does not give guidance what a Location
   Recipient does with each location.  There are no priority or
   more-trusted indications given by this document. All this is
   considered application specific, and out-of-scope of this document.
   This document makes it clear that if when there are more than one
   location, each in REQUIRED to dereference the location
   URI if location is not needed to process the same PIDF-LO MUST be about request. It is
   RECOMMENDED the same Target
   (identifier) and point at UAS display the same position on location to the earth.  If there
   is more than one PIDF-LO user, or otherwise
   render the location appropriately.

   A Require header field with different Target identifiers, then the 'geolocation' option tag indicates
   the UAC is merely telling requires that the UAS where more than one Target is, and
   there should not be any conflict.

   Within any PIDF-LO, there is understand this extension, sending an
   error response if it does not.  A 420 (Bad Extension) with a <retransmission-allowed> element that
   can
   'geolocation' option tag in an Unsupported header field would be set to "yes" or "no".  These are the only possibilities. If
   Alice conveys her location to Bob (as has been described throughout
   appropriate response in this document) case.

   It is possible, but undesirable, for a message to arrive with a <retransmission-allowed> element set body
   containing an LbyV, but with no Geolocation header field value
   pointing to "no",
   then Bob it (potentially no Geolocation header field at all). In
   this case, the recipient MAY still read and use the message body.
   Unless stated otherwise by future standards-track publication(s), a
   location URI only has meaning within the Geolocation header field
   and MUST NOT inform appear in any other element where Alice is.  If SIP header field.

   There are 3 Geolocation header field parameters,

      o "inserted-by="
      o "used-for-routing"
      o "routing-allowed"

   The "inserted-by=" parameter informs a Location Recipient which SIP
   entity added this locationValue to the SIP request.  This parameter
   is mandatory for each locationValue in the request.  The value in
   the "inserted-by=" parameter is copied into the
   <retransmission-allowed> element "inserter="
   parameter in each locationErrorValue if there is set an error in the
   location to be reported back to "yes", then Bob can
   inform other elements where Alice is, but only until the
   <retention-expiry> element, also location sender.  See section
   6.2.1.

   The "used-for-routing" parameter is included in the PIDF-LO, allows Bob to
   [RFC4119].  As a byproduct of this, that means that locationValue if Alice conveys
   her
   a SIP server used the location in the request to Bob with a <retransmission-allowed> element set determine how to
   "yes", and
   route or forward the <retention-expiry> time message towards the ultimate destination.  If
   there are more than one locationValues in the Geolocation header
   field, it is not requiring Bob possible that different locationValues were used to
   delete Alice's location yet, then Bob
   route the message at different points along the path traversed by
   the request.  This is free to tell anyone else
   where Alice is.  Whenever Bob conveys Alice's location,
   <retention-expiry> timer MUST be maintained allowed, as it is (i.e., not
   changed). The <dm:device id> element identifies consistent with the rule
   that Alice whenever a message is the
   target of this location.  RFC 4119 implicitly allows this behavior,
   thus SIP routed based upon a locationValue, a
   "used-for-routing" parameter is not going added to change this behavior the applicable
   locationValue.  This parameter MUST be present in each locationValue
   used along the path.  A "used-for-routing" parameter MUST NOT be
   removed from occurring.

6.2.1 UAS Generating a Location Failure Indication

   If a UAS receives location locationValue in a request, but determines there request.

   The "routing-allowed" parameter is exclusively for SIP servers, and
   will be discussed in section 6.3.

   Additional locationValues inserted into a request MUST be placed
   the order they were generated, and not rearranged.  This informs a
   problem with
   Location Recipient which was the location last locationValue in the request, it is the responsibility
   of the UAS to inform whomever inserted location into message
   that request
   there was a problem experienced.  The Geolocation used to route the message.  This is for troubleshooting and
   management reasons.

   Individual header field parameters in any received locationValue
   MUST NOT be modified or deleted in transit to the
   request has a locationValue, providing the ultimate
   destination.

   A UAS a URI indicating
   where the Target's MUST NOT send location is. The Location Target identified in
   the PIDF-LO may or may not a response message, as there can be the location inserter, or the
   generator
   any number of issues/problems with receiving location, and the request (the UAC
   or SIP server).  Ultimately,
   location is in proxy server(s) cannot reply to a PIDF-LO.  This is either in response with an error
   response.  If the request as UAS wants to send its location to a
   message body (LbyV), or UAC, it has to be dereferenced from the LbyR in
   the locationValue can do
   so in the request.  LbyR records are typically kept
   on a LIS, which can challenge all dereference requests.  All
   PIDF-LOs have new request within a Location Target identifier. separate transaction.  This document
   gives no recommendation about which SIP request to use, but SIP
   MESSAGE is who the
   location is about.  The "inserted-by=" parameter of the
   locationValue tells the a viable choice.

   A UAS who inserted that locationValue.  This
   "inserted-by=" parameter is copied into MAY include a 'geolocation' option tag in the "inserter=" parameter Supported header
   field of
   the locationErrorValue generated by the Location Recipient (the
   UAS), in a response, when indicating it wants to inform the does understand this extension,
   even if location
   "inserter=" entity there was not included in a problem with request to the UAS.

   A UAS wishing to dereference an location it
   received.

   There can be more than one locationValues URI contained in a request.  The
   "inserter=" parameter received
   request will use the 'presence' event package in a SUBSCRIBE request
   to the locationErrorValue URI.  If accepted, the LS will distinguish it
   from being misunderstood by entities that did not insert return the errored
   location. PIDF-LO to the UAS
   in a NOTIFY request.  If there is one valid locationValue are any errors during dereferencing,
   or in a request, even if all the
   others have errors with them, a 424 (Bad Location Information)
   response MUST NOT be sent.  The Location Recipient (the UAS) is
   RECOMMENDED PIDF-LO itself, the UAS will respond to send the original
   request with a locationErrorValue for each errored
   locationValue, indicating what the UAS concluded
   was wrong with unique "inserter=" parameters to make sure the
   right entities know which locations were in error.

   As hinted at, a location "inserter=" can be a UAC or it can be an
   in-signaling-path SIP server, who is acting as a UAC locator. location.  This
   means the SIP server is including its version of where it thinks the
   UAC is, geographically.  This "inserter=" has to be in the form of
   an LbyR include any dereferencing
   problems encountered.

   Dereferencing for sip:, sips: and pres: URI in a locationValue, because SIP servers schemes are not allowed
   mandatory-to-implement.

   A UAS MUST be prepared to insert message bodies, as of the time of this publication, receive subsequent location updates from
   all
   the way back to RFC3261.

   Each locationErrorValue has an error code, letting UAC, either LbyV or LbyR (regardless of how the UAS received
   location previously from this UAC).  The UAC will convey updated
   location
   "inserter=" entity know what was wrong with using the location supplied.
   See Section 4.3 for UPDATE [RFC3311] method to the 5 actionable responses UAS, and not a UAC can take from
   reINVITE. The UAS MUST NOT reject updated location arriving in a locationErrorValue.
   reINVITE though, as other dialog parameters might be changing also
   (in which a reINVITE is appropriate).

   If the there is more than one location "inserted-by=" entity, meaning either the UAC (any combination of LbyV and
   LbyR), this document does not give guidance about what a Location
   Recipient does with each location.  There are no priority or
   proxy
   more-trusted indications specified by this document. All this is
   considered application-specific, and out-of-scope for this document.
   If more than one location is present in the message path, chose to indicate that PIDF-LO, location was so
   important
   elements in the request same PIDF-LO MUST apply to include a 'geolocation' option tag the same Target
   (identified in a
   Require header, the response SHOULD be a 424 (Bad Location
   Information) back to "entity=" attribute) and point at the "inserter=" entity (knowing same
   position on the response
   will ultimately go to earth.  If there is more than one PIDF-LO with
   different Target identifiers, then the UAC regardless) if is merely telling the UAS
   where more than one Target is, and there needs to should not be any conflict.

   Within any PIDF-LO, there is a
   locationErrorValue sent because <retransmission-allowed> policy
   element that can be set to "yes" or "no".  These are the only
   possibilities. If Alice conveys her location was bad.  Only entities
   identified in a locationErrorValue as the "inserter=" entity will
   pay attention to Bob (as has been
   described throughout this locationErrorValue.  All other entities document) with a <retransmission-allowed>
   element set to "no", then Bob MUST
   ignore NOT inform any locationErrorValue not directed towards them.  See
   section 4.3 for more information on this, including all other element
   where Alice is.  If the location
   specific errors and Geolocation-Error header parameters.

   In <retransmission-allowed> element is set to
   "yes", then Bob can inform other elements where Alice is, but only
   as long as the above scenario ('geolocation' option tag <retention-expiry> policy element, also in a  Require
   header), the only other response can be
   PIDF-LO, allows [RFC4119].  As a 420, but only byproduct of this, that means that
   if Alice conveys her location to Bob with a <retransmission-allowed>
   element set to "yes", and the UAS <retention-expiry> time does not support this Geolocation extension
   require Bob to SIP, delete Alice's location yet, then Bob is free to tell
   anyone else where Alice is.  The entity= attribute in the 424 <presence>
   element identifies who is
   sent.

   If the location "inserted-by=" entity placed target of each location, preventing
   confusion.  Whenever Bob conveys Alice's location,
   <retention-expiry> timer MUST be maintained as is (i.e., not changed
   from when Bob received it).  RFC 4119 implicitly allows this
   behavior, and the 'geolocation'
   option tag in a Supported header, behavior does not change when SIP is the response can be Using
   Protocol.

6.2.1 UAS Generating a 424 if it
   chooses, but also can be any other SIP response, including Location Failure Indication

   If a 200
   OK.  A locationErrorValue UAS receives location in a Geolocation-Error header that request, but determines there is not
   in a 424 (Bad Location Information) response is considered
   informational by the Location Recipient, and not considered
   important enough to reject
   problem with the request based solely on bad location
   information.

   For example, Alice INVITEs Bob in the request, it is the responsibility
   of the UAS to a dialog, and includes geolocation
   in inform the entity that inserted the problematic
   location into that request. Bob can accept  The Geolocation header field in the INVITE with a 200 OK and still
   add
   request has a locationErrorValue in locationValue, providing the 200 OK UAS a location URI
   indicating "yes, I accept
   your request, and btw, something was wrong with where the Target's location you
   provided (in is. The Location Target
   identified in the INVITE)".  What was wrong with PIDF-LO may or may not be the location is
   indicated by inserter,
   or the Geolocation-Error code.  Who this
   locationErrorValue is for is indicated by generator of the "inserter=" parameter.

   Each locationErrorValue request.  Ultimately, location is destined for one "inserter=" entity.
   This gives in a Location Recipient one mechanism to tell each inserter
   what
   PIDF-LO.  This is either in the request as a message body (LbyV), or
   obtained by initiating a dereference transaction on a Location Recipient concluded was wrong with what
   Server identified in the
   "inserter=" included (as far as location is concerned).  Therefore,

   o  there MUST be URI.  Location Servers typically
   challenge all dereference requests.  All PIDF-LOs have a locationErrorValue for each Location
   Target identifier.  The "inserted-by=" parameter of the
   locationValue that
      was considered bad by tells the UAS to ensure each upstream location
      inserter understands which error code(s) SIP entity inserted that
   locationValue.  This "inserted-by=" parameter is intended for them
      (and which to ignore).

   o  there MUST NOT be more than one copied into the
   "inserter=" parameter of the locationErrorValue in generated by the
      response per locationValue
   Location Recipient (the UAS), in a response, when it wants to inform
   the request.

   o location "inserter=" entity there MUST NOT was a problem with the
   location it received.

   There can be more than one locationErrorValue to the same locationValue in a request.  The
   "inserter=" parameter in the request.

   o  there MUST NOT be a locationErrorValue in will prevent
   entities that did not insert the response for a errored location from
   misunderstanding whether the locationErrorValue applies to them.

   If there is one valid locationValue in a request, even if all the request that was not in error, according to
   others have errors with them, the Location Recipient.

   Here is an example of Recipient MUST NOT send a Geolocation-Error header

   Geolocation-Error: 400; code="Permission Necessary";
                           node="server42.example2.com";
                           inserter="alice.example.com";
   424 (Bad Location Information) response.  The above example says that the Location Recipient is
   server42.example.com, and this entity believes it cannot route this
   message without knowing
   (the UAS) MUST send a locationErrorValue for each errored
   locationValue, with unique "inserter=" parameters to make sure the "inserter="'s location.  This
   right entities know which locations were in error.

   As hinted at, a location
   may "inserter=" can be in the request, a UAC or it may need can be an
   in-signaling-path SIP server acting as a UAC locator.  This
   means the SIP server is including its version of where it thinks the
   UAC is, geographically.  This "inserter=" has to be in the request and form of
   an dereferencable location URI in a locationValue, because SIP
   servers are not allowed to insert message bodies.

   Each locationErrorValue has an error code, letting the location
   "inserter=" entity know what was
   not. wrong with the location supplied by
   that entity. See Section 4.3 for the 5 actionable responses a UAC
   can take from a locationErrorValue.

   If the location is encrypted, server42 doesn't know it is "inserted-by=" entity, meaning either the UAC or
   proxy in the message path chose to indicate that location was
   sufficiently important to include a 'geolocation' option tag in the
   request.  server42.example.com sends a
   Require header field, any error response SHOULD be a 424 (Bad
   Location Information) response with a locationErrorValue indicating a 400
   location error, which means it requires permission back to view Alice's
   location the "inserter=" entity (knowing the
   response will ultimately go to proceed with processing her signaling.  Section 4.3
   highlights this example, stating the user, Alice, MUST be made aware
   of this location revelation request.  This document does not give
   any guidance how Alice is UAC regardless) if there needs to
   be informed (i.e., audio, visual,
   etc).  Alice can grant permission or choose not to, knowing this SIP
   request attempt (to this destination, at this time) will fail.  The
   problem could be corrected if a future SIP request were good locationValue sent to travel
   through properly process the request.  Only
   entities identified in a different server than server42 (or it might not). locationErrorValue as the "inserter="
   entity will pay attention to this locationErrorValue.  All other
   entities MUST ignore any locationErrorValue not directed towards
   them.  See Section section 4.3 for further rules about more information on this, including all
   the location-specific errors and Geolocation-Error header
   and field
   parameters.

   In the locationErrorValue.

   This document says nothing about what above scenario ('geolocation' option tag in a Location Recipient Require
   header field), the only other response can be a 420, if the UAS
   does with
   more than one 'good' locationValue not support this Geolocation extension to SIP.

   If the "inserted-by=" location entity placed the 'geolocation'
   option tag in a request (i.e., which to
   choose to use).  This scenario MAY Supported header field, the response can be addressed a 424 if
   it chooses, but also can be any other SIP response, including a 200
   OK.  A locationErrorValue in a future effort.

   Further, more than one error code Geolocation-Error header field that
   is allowed not in a 424 (Bad Location Information) response is considered
   informational by the
   locationErrorValue - each having one "inserter=" parameter.  The
   error codes destined for the same inserter MUST NOT contradict the
   meaning of the problem Location Recipient, and does not cause the
   Location Recipient had with a particular
   locationValue.

6.3 Proxy Behavior

   [RFC3261] states message bodies cannot be added by proxies.
   However, proxies are permitted to add a header reject the request solely because of bad
   location information.

   For example, Alice INVITEs Bob to a dialog, and includes geolocation
   in the request.  This
   implies that a proxy Bob can accept the INVITE with a 200 OK and still
   add a Geolocation locationValue locationErrorValue in the 200 OK indicating "yes, I accept
   your request, and btw, something was wrong with
   LbyR URI, but not LbyV message body.

   It is allowed, but NOT RECOMMENDED, for more than one SIP element to
   insert the location into a request along its path.  As described earlier you
   provided in this document, each insertion of the INVITE".  The specific problem with the location into a SIP request is
   accompanied
   indicated by the Geolocation-Error code. The "inserter=" parameter
   identifies the Location Inserter this locationErrorValue is intended
   for.

   Each locationErrorValue is destined for one "inserter=" entity.
   This gives a new locationValue in Location Recipient a Geolocation header.  Also
   described earlier, each locationValue MUST contain an "inserted-by="
   value indicating mechanism to a tell each inserter
   what the Location Recipient which host inserted
   location into a particular request.

   However, if concluded was wrong with the location is already in a SIP request,
   the "inserter=" entity included.  Therefore,

   o  there MUST be a SIP server
   SHOULD NOT add another LbyR locationErrorValue for each locationValue that identifies
      was considered bad by the same target UAS to ensure each upstream location
      inserter understands which error code is intended for the
      inserter (and which to ignore).

   o  there MUST NOT be more than one locationErrorValue in the
   PIDF-LO (in
      response per locationValue in the <dm:device id> element) to request.

   o  there MUST NOT be more than one locationErrorValue with the same
      "inserter=" entity in the request.  This
   will likely cause confusion at

   o  there MUST NOT be a locationErrorValue in the Location Recipient as to which to
   use.

   A proxy is permitted to read any locationValue, and response for a
      locationValue in the associated
   body, if request that was not S/MIME protected, in transit if present, and can use error, according to
      the contents Location Recipient.

   Here is an example of the a Geolocation-Error header field to make location-based retargeting
   decisions, if retargeting requests based on location is a function
   of

   Geolocation-Error: 201; code="Linkable Target Identity Required";
                           node="server42.example.com";
                           inserter="alice.example.com";

   The above example says that proxy.  Retargeting is defined in [RFC3261].  However, if the Geolocation header parameter "routing-allowed" Location Recipient is present
   server42.example.com, and
   set to "no", or is not present (knowing the default behavior is "no"
   if not present, with or without a Geolocation header), SIP servers
   MUST NOT view the contents of this entity cannot verify the LbyV message body. Further, SIP
   servers MUST NOT attempt to dereference an LbyR. Target's
   identity within this message. This is because typically needed in order to
   make routing decisions for the SIP request, likely request where the entity=
   attribute has an unlinkable pseudonym obscuring a location target's
   identity from the originating UAC, did signaling. This is not give the
   SIP server permission desire because if Alice's
   message is to view be routed based on the location within in the SIP request.
   How a SIP server indicates it requires permission to view a
   request's location in order request,
   server42 has to properly process verify that this request is in
   section 6.3.2.

   If the Geolocation header parameter "routing-allowed" Alice's location.  The
   appropriate action is present in to send a SIP request, the value MUST NOT be changed during processing of
   the request.  If 424 (Bad Location Information)
   response with the Geolocation above (201) Geolocation-Error header parameter "routing-allowed"
   is value.  We do
   not present, SIP servers are to treat the location within the want Alice's request as if routed based on Bob's location.

   See Section 4.3 for further rules about the Geolocation-Error header parameter "routing-allowed" were present
   and set to "no".

   In the spirit of informing implementers of B2BUAs
   field and SBCs, each
   server type really should adhere to the above proxy guidance locationErrorValue.

   This document says nothing about what a Location Recipient does with
   respect
   more than one 'good' locationValue in a request (i.e., which to
   choose to use).  This scenario MAY be addressed in a future effort.

   Further, more than one error code is allowed in the "Routing-allowed" header parameter, understanding
   that there are no IETF police, and the specific behaviors of these
   types of SIP servers
   locationErrorValue - each having one "inserter=" parameter.

6.3 Proxy Behavior

   [RFC3261] states message bodies cannot presently be defined. In other words, if
   the particular type of SIP server mentioned here is added by proxies.
   However, proxies are permitted to add a header field to a request.
   This means that a proxy can add a Geolocation locationValue header
   field with a dereferencable location URI, but not the ultimate
   destination of this a LbyV message
   body.

   It is allowed, but NOT RECOMMENDED, for more than one SIP element to
   insert location into a request and supports along its path.  As described earlier
   in this SIP extension, document, each policy rule within the Geolocation header needs to remain
   intact and unchanged.

   No type insertion of location into a SIP server can delete request is
   accompanied by a "Routing-allowed" new locationValue in a Geolocation header
   parameter, but if one field.
   Also described earlier, each locationValue MUST contain an
   "inserted-by=" value indicating to a Location Recipient the host
   that inserted a specific location into a particular request.

   If, however, location is not yet present, any already in a SIP request, a SIP server MAY
   SHOULD NOT add a
   "Routing-allowed" header parameter with another location URI that identifies the value set same target
   in the PIDF-LO (in the entity= attribute) to "no" only. the same request.  This
   will likely cause confusion at the Location Recipient as to which to
   use.

   More than one Geolocation locationValue in a message is permitted,
   but can cause confusion at the recipient.  If a proxy chooses to add
   a locationValue to a Geolocation header, header field, which would be a
   local policy decision, the new locationValue MUST be added to the
   end of the header field (after previous locationValue(s)).  This is
   done to create an order of insertion of locationValues along the
   path.  Proxies MUST NOT modify the order of locationValues in a
   geolocation
   header. header field.

   A proxy wishing to dereference an LbyR a location URI contained in a
   received request will use the 'presence' event package in a
   SUBSCRIBE request to the URI.  If accepted, the PIDF-LO LS will return the
   PIDF-LO to the proxy in a NOTIFY request.  If there are any errors
   during dereferencing, or in the PIDF-LO itself, the proxy will send
   an error the original request to the UAC with a locationErrorValue indicating what the
   proxy concluded was wrong with the location.  This is to include any
   dereferencing problems encountered.

6.3.1 Proxy Behavior with Geolocation Header Field Parameters

   SIP servers MUST NOT delete any existing Geolocation locationValue
   (URI or header field parameter) from a request.  An existing
   locationValue
   (URI or header parameter) MAY only be modified by adding a "used-for-routing"
   parameter to an existing locationValue, if the request was
   retargeted based on the location within that locationValue.  Further modification of

   According to this specification, the default value of any
   Geolocation header value "routing-allowed" is "no". This parameter
   does not have to be present to deny SIP servers along the signaling
   path the ability to view the target's location. This parameter MAY
   be added in transit by a SIP server, and MUST be with a value of
   "no".  Other modifications of the Geolocation header field MUST NOT
   occur.

   For example, an existing Geolocation locationValue in a request of:

   Geolocation: <cid:alice123@atlanta.example.com>;
                 inserted-by="alice123@atlanta.example.com";

   can be modified by a proxy to add the "used-for-routing" parameter,
   like this:

   Geolocation: <cid:alice123@atlanta.example.com>;
                 inserted-by="alice123@atlanta.example.com";
                 used-for-routing

   if this is the locationValue the proxy used to make a retargeting
   decision based upon, but the proxy can make no other modification.

   A SIP server MAY add a new Geolocation locationValue to a SIP
   request.  The proxy server SHOULD NOT insert a locationValue of a Location Target
   unless it is reasonably certain it knows the actual geographic
   location of the Location Target, for Target (for example, if it thoroughly
   understands the topology of the underlying access network and it can
   identify the device reliably (in location reliably, even in the presence of, for example, of NAT
   or VPN).  Routing errors are likely if the SIP server inserts an
   incorrect locationValue.

   A server adding a locationValue added to an existing Geolocation header field
   would look like:

 Geolocation: <cid:alice123@atlanta.example.com>;
               inserted-by="alice123@atlanta.example.com",
              <sips:3sdefrhy2jj7@lis1.atlanta.example.com>;
               inserted-by="lis1.atlanta.example.com"
              <sips:3sdefrhy2jj7@ls7.atlanta.example.com>;
               inserted-by="ls7.atlanta.example.com"

   Notice the locationValue added by the proxy "ls7" is last among
   locationValues.  This practice  Proxies MUST be done for add locationValue at the end of all added
   locationValues.
   locationValues that are already present in the request.

   If this request was then retargeted by an intermediary using the
   locationValue inserted by the server, server "ls7", the intermediary would add a
   "used-for-routing" parameter like this:

 Geolocation: <cid:alice123@atlanta.example.com>;
               inserted-by="alice123@atlanta.example.com",
              <sips:3sdefrhy2jj7@lis1.atlanta.example.com>;
               inserted-by="lis1.atlanta.example.com";
              <sips:3sdefrhy2jj7@ls7.atlanta.example.com>;
               inserted-by="ls7.atlanta.example.com"; used-for-routing

   It is conceivable that an initial routing decision is made on
   one locationValue, and subsequently another routing decision is
   made on a different locationValue further towards the ultimate
   destination.  This retargeting decision can be made on a newly
   inserted locationValue.  While unusual, newly
   inserted locationValue.  While unusual, it can occur.  In such a
   case, proxies MUST NOT remove any existing "used-for-routing" header
   field parameter.  In this instance, the SIP server retargeting based
   on another locationValue MUST add the "used-for-routing" header
   field parameter to the locationValue used for retargeting by this
   server. This will result in a Geolocation header field indicating
   that the request has been retargeted more than once, which is
   allowed.

   A Proxy that inserts or adds locationValue into a request MAY move a
   'geolocation' option tag that is in a Supported header field into a
   Require header field if this proxy deems geolocation to be
   sufficiently important to Location Recipient(s) of this request.

   A proxy can read any locationValue present, and the associated body,
   if not S/MIME protected, and can use the contents of the header
   field to make location-based retargeting decisions, if retargeting
   requests based on location is a function of that proxy.  Retargeting
   is defined in [RFC3261].  However, if the Geolocation header field
   parameter "routing-allowed" is present and set to "no", or is not
   present (the default behavior is "no" if "routing-allowed" is not
   present, whether or not a Geolocation header field is present), SIP
   servers MUST NOT view the contents of the location message body.
   Further, SIP servers MUST NOT attempt to dereference a location URI.
   This is because the Location Inserter (likely the originating UAC)
   did not give the SIP server permission to view the location within
   the SIP request.  How a SIP server indicates it can occur.  In such requires permission
   to view a
   case, proxies request's location in order to properly process this
   request is described in section 6.3.2.

   If the Geolocation header field parameter "routing-allowed" is
   present in a SIP request, the value MUST NOT remove any existing "used-for-routing" header
   parameter.  In this instance, be changed during
   processing of the request.  If the Geolocation header field
   parameter "routing-allowed" is not present, SIP server retargeting based on
   another locationValue servers MUST add treat
   the location within the request as if the "used-for-routing" header field parameter
   "routing-allowed" were present and set to "no".

   B2BUAs and SBCs should also adhere to the locationValue used for retargeting by this server.
   This will result in a Geolocation above proxy guidance with
   respect to the "Routing-allowed" header looking as field parameter. In other
   words, if it were
   retargeting more than once, which would be true - the particular type of SIP server mentioned here supports
   this SIP extension and is not the desired
   outcome.

   A Proxy that inserts or adds locationValue into a request MAY move a
   'geolocation' option that is in a Supported ultimate destination of this SIP
   request, each policy rule within the Geolocation header into field MUST
   remain intact and unchanged.

   No SIP server can delete a Require "Routing-allowed" header field
   parameter, but if this proxy deems geolocation to be that important one is not yet present, any SIP server MAY add a
   "Routing-allowed" header field parameter with the value set to
   Location Recipient(s) of this request. "no"
   only.

6.3.2 Proxy Error Behavior for Sending or Receiving locationErrorValues

   For proxies that receive a SIP request that contains a location
   error, either in a contained message body or after the proxy does a
   dereference of the LbyR URI, all the rules applicable to a UAS apply
   here (see Section 6.2.1.), since in this case, the proxy is
   considered a Location Recipient. Therefore, there is no reason to
   restate them here, and potentially have the two sections be
   inconsistent. 6.2.1.).
   The one thing point to add is that a proxy does not need to examine
   location contained in a request. Section 6.2.1. only applies to
   proxies that are needing, monitoring need to monitor or policing police location within requests (for
   whatever reason).

   If a proxy inserted a locationValue into a request, it SHOULD MUST be
   ready to examine the response to that request, in case there is one
   or more location errors in the response.  To a great degree, this
   scenario has the proxy behaving as a UAC (see section 6.1.1.) that
   included a locationValue a request, which then receives an error to
   that locationValue.

   This location inserting location-inserting proxy SHOULD be (at least) transaction
   stateful for the response.  If the proxy is configured as a
   stateless proxy, and it inserts location, it MUST process and
   monitor all SIP responses, looking for locationErrorValues that
   indicate it was the "inserter=" to learn that the location it
   supplied was in error.  It SHOULD react
   accordingly according to the error code
   received.  This document gives no guidance what the proxy should do
   to rectify the bad location information, since the proxy is not the
   SIP response destination, but a future document MAY could address this.

   The "routing-allowed" parameter's purpose is to indicate if SIP
   servers along the signaling path should bother looking at the LbyV
   location message body or dereferencing the LbyR. location URI.  There are
   two values specified here for this parameter: "yes" and "no".  If
   the "routing-allowed" parameter is set to "yes", and the SIP server
    determines this SIP request
   needs to should be routed based on the location of the target's
   location, this parameter gives the server permission to look at the location
   (or dereference it).  If
   location (or dereference it).  If this parameter is set to "no",
   then the SIP server MUST NOT view the location message body or
   dereference the location URI within this SIP request.  If the SIP
   server believes it cannot process this message properly because it
   needs to learn the target's location in order to route the message,
   then it MUST return a 424 (Bad Location Information) response,
   indicating it requires permission (error code 400) to view the
   location.

   Here is an example of a Geolocation-Error header field

   Geolocation-Error: 400; code="Permission to Reveal Location
                           Information to a Third Party";
                           node="server42.example.com";
                           inserter="alice.example.com";

   The above example says that the Location Recipient is
   server42.example.com, and this entity believes it cannot route this
   message without knowing permission to view the Target's location.
   Regardless of whether there is a Geolocation header value parameter,
   such as

   routing-allowed=no

   or this parameter is not present in the SIP request (as shown 400
   error example above). The default behavior is to act as if the
   parameter is present and set to "no".  Server42 MUST get permission
   to view the Target's location by reading a routing-allowed header
   parameter saying "yes", otherwise a 400 error is sent back to the
   inserter= entity to get permission.

   Section 4.3 highlights this example, stating the user, Alice, MUST
   be made aware of this parameter location revelation request.  This document
   does not give any guidance how Alice is set to "no", then the SIP
   server MUST NOT view the LbyV be informed (i.e., audio,
   visual, etc).  Alice can grant permission or dereference the LbyR within choose not to, knowing
   this SIP request.  If the SIP server believes it cannot process request attempt (to this
   message properly because it needs to learn the target's location in
   order destination, at this time) will
   fail.  The problem might not recur if a future SIP request were to route the message, then it MUST return
   travel through a 424 (Bad Location)
   response, indicating different server than server42 (or it requires permission (error code 400) to view
   the location. might again).

7.  Geopriv Privacy Considerations

   Location information is considered by most to be highly
   sensitive information, requiring protection from eavesdropping,
   and altering in transit.  [RFC3693] articulates rules to
   be followed by any protocol wishing to be considered a "Using
   Protocol", specifying how a transport protocol meets those rules.
   This section describes how SIP as a Using Protocol meets those
   requirements.

   Quoting requirement #4 of [RFC3693]:

   "The Using Protocol has to obey the privacy and security
    instructions coded in the Location Object and in the
    corresponding Rules regarding the transmission and storage
    of the LO."

   This document requires that SIP entities sending or receiving
   location MUST obey such instructions.

   Quoting requirement #5 of [RFC3693]:

   "The Using Protocol will typically facilitate that the keys
    associated with the credentials are transported to the
    respective parties, that is, key establishment is the
    responsibility of the Using Protocol."

   [RFC3261] and the documents it references define the key
   establishment mechanisms.

   Quoting requirement #6 of [RFC3693]:

   "(Single Message Transfer)  In particular, for tracking of
    small Target devices, the design should allow a single
    message/packet transmission of location as a complete
    transaction."

   When used for tracking, a simple NOTIFY or UPDATE normally is
   relatively small, although the PIDF itself can get be large.  Normal
   RFC 3261 procedures of reverting to TCP when the MTU size is
   exceeded would be invoked.

8.  Security Considerations

   Conveyance of physical location of a UAC raises privacy concerns,
   and depending on use, there probably will be authentication and
   integrity concerns.  This document calls for conveyance to normally
   be accomplished through secure mechanisms, like S/MIME protecting
   message bodies (but (although this is not widely deployed) or TLS
   protecting the overall signaling.  In cases where a session set-up
   is retargeted based on the location of the UAC initiating the call
   or SIP MESSAGE, securing the LbyV location with an end-to-end
   mechanism such as S/MIME is problematic, because one or more proxies
   on the path need the ability to read the location information to
   retarget the message to the appropriate new destination UAS.
   Securing the location hop-by-hop, using TLS, protects the message
   from eavesdropping and modification, but exposes the information to
   all proxies on the path as well as the endpoint.  In most cases, the
   UAC does not know the identity of the proxy or proxies providing
   location-based routing services, so that end-to-middle solutions
   might not be appropriate either.

   These same issues exist for basic SIP signaling, but SIP normally
   does not carry information to physically track a user; making this user. This
   extension is especially sensitive.  That said, there is the ability,
   according to [RFC3693] to have an anonymous identity for the
   target's location.  This is accomplished by use of an unlinkable
   pseudonym in the entity= attribute of the <presence> element
   [RFC4479]. Though, this can be problematic for routing messages
   based on location (covered several times in the document above).

   When location is inserted by a UAC, which is RECOMMENDED, it can
   decide whether to reveal its location using hop-by-hop methods.  UAC
   implementations MUST make such capabilities conditional on explicit
   user permission, and SHOULD alert a user that location is being
   conveyed.  Proxies inserting location for location-based routing are
   unable to meet this requirement, alert users, and such use is NOT RECOMMENDED.  Proxies
   conveying location using this extension MUST have the permission of
   the Target to do so.

   One facet within this

   This SIP extension offers the default ability to require permission
   to view location while the SIP request is such that in transit.  The default
   for this is set to "no", and there is an error explicitly describing
   how an intermediary asks for permission to view the Target's
   location.

   Because target locations can be placed on a remote server, called a
   Location Server accessible with the possession of a URI.  The
   concept of an LbyR location URI,
   this URI has its own security considerations.  It is tempting to
   assume that the dereference of this URI would have authentication,
   authorization and other security mechanisms that limit the access to
   information.  Unfortunately, this might not be true.  The access
   network the UAC is connected to can be the source of location
   reference, and it might not have any credentialing mechanism
   suitable for controlling access to a target's location.  Consider,
   specifically, a nomadic user connected to an access network in a
   hotel.  The UAC has no way to provide a credential acceptable to of the
   hotel Location Server (LS) to any of its intended Location
   Recipients.  The recipient of a reference does not know if a
   reference has appropriate authorization policies or not.  The LS
   should provide location to any requestor.

   Accordingly, possession of the reference should be considered
   equivalent to possession of the value, and the reference should be
   treated with the same degree of care as the value.  Specifically,
   TLS MUST be used to protect the security of the reference.  Notice
   that this specification does not constrain the dereference protocol
   to use TLS. That specification is left entirely to the dereferencing
   protocol documents.

   There is no end-to-end integrity on any locationValue or
   locationErrorValue header field parameter end-to-end (or middle-to-end if the
   value was inserted by a intermediary), so recipients of either
   header field need to implicitly trust the header field contents, and
   take whatever precautions each entity deems appropriate give these facts. given this
   situation.  Any idea of using SIP Identity is lost as soon as it is
   realized that the Geolocation header value can be added to by
   intermediaries in the signaling path.

9.  IANA Considerations

   The following are the IANA considerations made by this SIP
   extension.  Modifications and additions to these registrations
   require a standards track RFC (Standards Action).

   [Editor's Note: RFC-Editor - within the IANA section, please
                   replace "this doc" with the assigned RFC number,
                   if this document reaches publication.]

9.1 IANA Registration for the SIP Geolocation Header Field

   The SIP Geolocation header Header Field is created by this document, with
   its definition and rules in Section 4.1 of this document, to and should
   be added to the sip-parameters, IANA sip-parameters registry, in the portion titled
   "Header Field Parameters and Parameter Values".

                                            Predefined
   Header Field        Parameter Name       Values      Reference
   ----------------    -------------------  ----------  ---------
   Geolocation         inserted-by=         no          [this doc]
   Geolocation         used-for-routing     yes         [this doc]
   Geolocation         routing-allowed      yes         [this doc]

9.2 IANA Registration for New SIP Option Tag

   The SIP option tag "geolocation" is created by this document, with
   the definition and rule in Section 4.4 of this document, to be added
   to the IANA sip-parameters within IANA. registry.

9.3 IANA Registration for Response Code 424

   Reference: RFC-XXXX (i.e., this document)
   Response code: 424 (recommended number to assign)
   Default reason phrase: Bad Location Information

   This SIP Response code is defined in section 4.2 of this document.

9.4 IANA Registration of New Geolocation-Error Header Field

   The SIP Geolocation-error header field is created by this document,
   with its definition and rules in Section 4.3 of this document, to be
   added to the sip-parameters, IANA sip-parameters registry, in the portion titled
   "Header Field Parameters and Parameter Values".

                                            Predefined
   Header Field        Parameter Name       Values      Reference
   -----------------   -------------------  ----------  ---------
   Geolocation-Error   inserter=            no          [this doc]
   Geolocation-Error   node=                no          [this doc]
   Geolocation-Error   code=                no                yes*        [this doc]
   * see section 9.5 for the newly created values.

9.5 IANA Registration for the SIP Geolocation-Error Codes

   New location specific Geolocation-Error codes are created by this
   document, and registered in a new table at in the IANA sip-parameters within
   IANA.
   registry. Details of these error codes are in Section 4.3 of this
   document.

   Geolocation-Error codes
   -----------------------
   Geolocation-Error codes provide reason for the error discovered by
   Location Recipients, categorized by action to be taken by error
   recipient to be placed into SIP responses to inform the location
   inserter of the error.

  Code Description                                          Reference
  ---- ---------------------------------------------------  ---------
  100  "Cannot Process Location"  General location error,   [this doc]
          meaning location in the request cannot be
          processed at this time.  No actionable guidance.
          Can be treated as a 200 or 300 error by error
          recipient.

  200  "Retry Location Later" (with Later with same data)  Location data" The location   [this doc]
          cannot be processed at this time.  Error recipient
          should try again with same data.

  201  "Linkable Target Identity Required"                  [this doc]
          Target's identity cannot be unlinkable within
          the presence element's entity= attribute. This
          is necessary for routing SIP requests based
          on Target's location (and some other entity's).

  300  "Retry Location Later" (with Later with device updated location) location"  [this doc]
          Location cannot be processed at this time.  Error
          recipient should try again with same data.

  400  "Permission Necessary" To Reveal Location Information to a Third Party"
          Permission from calling user [this doc] to reveal location   [this doc]
          in request before request can be processed. This
          is a routing by location error. User MUST be
          informed of permission request.

  500  "Location Information Denial"  Request was actively  [this doc]
          denied because of the location in the request.
          Recipient should not try again.

9.6  IANA Registration of LbyR 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.  Below is an example of how it
   could look reference, as follows:

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

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

10.  Acknowledgements

   To Dave Oran for helping to shape this idea.

   To Jon Peterson and Dean Willis on guidance of the effort.

   To Allison Mankin, Dick Knight, Hannes Tschofenig, Henning
   Schulzrinne, James Winterbottom, Jeroen van Bemmel, Jean-Francois
   Mule, Jonathan Rosenberg, Keith Drage, Marc Linsner, Martin Thomson,
   Mike Hammer, Ted Hardie, Shida Shubert, Umesh Sharma, Richard
   Barnes, Dan Wing, Matt Lepinski and Jacqueline Lee for constructive
   feedback and nits checking.

   A special

   Special thanks to Paul Kyzivat for his help with the ABNF in this
   document, to Dan Wing for help with the S/MIME example,
   document and to Robert Sparks for many helpful comments and the
   proper building construction of the Geolocation-Error header. header field.

   And finally, to Spencer Dawkins for giving this doc a good scrubbing
   to make it more readable.

11. References

11.1 References - Normative

 [RFC3261] J. Rosenberg, H. Schulzrinne, G. Camarillo, A. Johnston, J.
           Peterson, R. Sparks, M. Handley, and E. Schooler, "SIP:
           Session Initiation Protocol", RFC 3261, May 2002.

 [RFC4119] J. Peterson, "A Presence-based GEOPRIV Location Object
           Format", RFC 4119, December 2005

 [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate
 [RFC2392] E. Levinson, " Content-ID and Message-ID Uniform Resource
           Locators", RFC 2392, August 1998

 [RFC3863] H. Sugano, S. Fujimoto, G. Klyne, A. Bateman, W. Carr, J.
           Peterson, "Presence Information Data Format (PIDF)", RFC
           3863, August 2004

 [RFC3856] J. Rosenberg, " A Presence Event Package for the Session
           Initiation Protocol (SIP)", RFC 3856, August 2004

 [RFC3859] J. Peterson, "Common Profile for Presence (CPP)", RFC 3859,
           August 2004

 [RFC3428] B. Campbell, Ed., J. Rosenberg, H. Schulzrinne, C. Huitema,
           D. Gurle, "Session Initiation Protocol (SIP) Extension for
           Instant Messaging" , RFC 3428, December 2002

 [RFC3311] J. Rosenberg, "The Session Initiation Protocol (SIP) UPDATE
           Method", RFC 3311, October 2002

 [RFC3265] Roach, A., A, "Session Initiation Protocol (SIP)-Specific
           Event Notification", RFC 3265, June 2002.

 [RFC3262] Rosenberg, J. and H. Schulzrinne, "Reliability of
           Provisional Responses in Session Initiation Protocol (SIP)",
           RFC 3262, June 2002.

 [RFC3515] R. Sparks, "The Session Initiation Protocol (SIP) Refer
 [RFC3903] Niemi, A., A, "Session Initiation Protocol (SIP) Extension
           for Event State Publication", RFC 3903, October 2004.

 [RFC5234] Crocker, D., Ed., and P. Overell, "Augmented BNF for Syntax
           Specifications: ABNF", STD 68, RFC 5234, January 2008.

 [IANA-civic] http://www.iana.org/assignments/civic-address-types-
                     Registry

 [RFC5491] J. Winterbottom, M. Thomson,

 [RFC5226] T. Narten, H. Tschofenig, "GEOPRIV PIDF-LO
           Usage Clarification, Considerations, and Recommendations ", Alvestrand, "Guidelines for Writing an IANA
 [RFC4479] J. Rosenberg, "A Data Model for Presence", RFC 4479, July
           2006

11.2 References - Informative

 [RFC3693] J. Cuellar, J. Morris, D. Mulligan, J. Peterson. J. Polk,
           "Geopriv Requirements", RFC 3693, February 2004

 [RFC4483] E. Berger, "A Mechanism for Content Indirection in SIP", RFC
 [RFC3825] J. Polk, J. Schnizlein, M. Linsner, "Dynamic Host
           Configuration Protocol Option for Coordinate-based Location
 [RFC4776] H. Schulzrinne, " Dynamic Host Configuration Protocol
           (DHCPv4 and DHCPv6) Option for Civic Addresses Configuration
           Information ", RFC 4776, October 2006

 [ID-PHONE] B. Rosen, J. Polk, "ECRIT Phone BCP",
   Author Information

   James Polk
   Cisco Systems
   3913 Treemont Circle
   Colleyville, Texas  76034

   33.00111N
   96.68142W

   Phone: +1-817-271-3552
   Email: jmpolk@cisco.com

   Brian Rosen
   NeuStar, Inc.
   470 Conrad Dr.
   Mars, PA  16046

   40.70497N
   80.01252W

   Phone: +1 724 382 1051
   Email: br@brianrosen.net

Appendix A.  Requirements for SIP Location Conveyance

   The following subsections address the requirements placed on the
   UAC, the UAS, as well as SIP proxies when conveying location. There
   is If a motivational statement below each requirements that
   requirement is not obvious in intent intent, a motivational statement is
   included below it.

A.1 Requirements for a UAC Conveying Location

   UAC-1  The SIP INVITE Method [RFC3261] must support location
          conveyance.

   UAC-2  The SIP MESSAGE method [RFC3428] must support location
          conveyance.

   UAC-3  SIP Requests within a dialog should support location
          conveyance.

   UAC-4  Other SIP Requests may support location conveyance.

   UAC-5  There must be one, mandatory to implement means of
          transmitting location confidentially.

   Motivation:  interoperability to guarantee interoperability.

   UAC-6  It must be possible for a UAC to update location conveyed
          at any time in a dialog, including during dialog
          establishment.

   Motivation: in case if a UAC has moved prior to the establishment of a
          dialog between UAs, the UAC must be able to send new location
          information.  In the case of  If location having has been conveyed, and the UA
          moves, it needs a means the UAC must be able to update the location previously
          conveyed to
          party of this location change. other parties.

   UAC-7  The privacy and security rules established within [RFC3693]
          that would categorize SIP as a 'Using Protocol' must be met.

   UAC-8  The PIDF-LO [RFC4119] is a mandatory to implement format for
          location conveyance within SIP, whether included LbyV or
          LbyR.

   Motivation:  interoperability with other IETF location protocols and
          mechanisms
          Mechanisms.

   UAC-9  There must be a mechanism for the UAC to request the UAS send
          its location location.

          UAC-9 has been DEPRECATED by the SIP WG, due to the many
          problems this requirement would have caused if implemented.
          The solution is for the above UAS to send a new request to
          the original UAC with the UAS's location.

   UAC-10 There must be a mechanism to differentiate the ability of the
          UAC to convey location from the UACs lack of knowledge of its
          location
   Motivation: Failure to receive location when it is expected can be
          happen because the UAC does not implement this extension, or it can
          be that
          because the UAC implements the extension, but does not know
          where it the Target is.  This may be, for example, due to the
          failure of the access network to provide a location
          acquisition
          mechanisms mechanism the UAC understands. supports.  These cases must be
          differentiated.

   UAC-11  It must be possible to convey location to proxy servers
          along the path.

   Motivation:  Location-based routing.

A.2 Requirements for a UAS Receiving Location

   The following are the requirements for location conveyance by a UAS:

   UAS-1  SIP Responses must support location conveyance.

          Just as with UAC-9, UAS-1 has been DEPRECATED by the SIP WG,
          due to the many problems this requirement would have caused
          if implemented. The solution is for the above UAS to send a
          new request to the original UAC with the UAS's location.

   UAS-2  There must be a unique 4XX response informing the UAC it did
          not provide applicable location information.

   In addition, requirements UAC-5, 6, 7 and 8 also apply to the UAS UAS.

A.3 Requirements for SIP Proxies and Intermediaries

   The following are the requirements for location conveyance by a SIP
   proxies and intermediaries:

   Proxy-1  Proxy servers must be capable of adding a Location header
            field during processing of SIP requests.

   Motivation:  Provide the capability of network assertion of location
            when UACs are unable to do so, or when network assertion is
            more reliable than UAC assertion of location

   Note: Because UACs connected to SIP signaling networks may have
         widely varying access network arrangements, including VPN
         tunnels and roaming mechanisms, it may be difficult for a
         network to reliably know the location of the endpoint.  Proxy
         assertion of location is NOT RECOMMENDED unless the sip SIP
         signaling network has reliable knowledge of the actual
         location of the Targets.

   Proxy-2  There must be a unique 4XX response informing the UAC it
            did not provide applicable location information.