SIPCORE
Network Working Group                                        James Polk
Internet Draft                                            Cisco Systems
Expires: August January 12, 2010 2011                                   Brian Rosen
Intended Status: Standards Track (PS)                      Jon Peterson
                                                                NeuStar
                                                           Feb
                                                          July 12, 2010

         Location Conveyance for the Session Initiation Protocol
              draft-ietf-sipcore-location-conveyance-02.txt
              draft-ietf-sipcore-location-conveyance-03.txt

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
   conveyance as well as location-based routing, where SIP servers
   intermediaries make routing decisions based upon the location of the
   user agent client.

Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with
   the provisions of BCP 78 and BCP 79.

   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 Aug Jan 12, 2010. 2011.

Copyright Notice

   Copyright (c) 2010 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
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with
   respect to this document.  Code Components extracted from this
   document must include Simplified BSD License text as described in
   Section 4.e of the Trust Legal Provisions and are provided without
   warranty as described in the BSD License.

   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.

Table of Contents

   1.  Conventions and Terminology used in this document . . . . . .  3
   2.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .  3
       2.1 Scoping and Describing a Target verses a Device . . . . .  4
   3.  Overview of SIP Location Conveyance . . . . . . . . . . . . .  5  3
   4.  SIP Modifications for Geolocation Conveyance  . . . . . . . .  8  7
       4.1 The Geolocation Header  . . . . . . . . . . . . . . . . .  8  7
       4.2 424 (Bad Location Information) Response Code  . . . . . . 12  9
       4.3 The Geolocation-Error Header  . . . . . . . . . . . . . . 12 10
       4.4 The 'geolocation' Option Tag  . . . . . . . . . . . . . . 24 12
       4.5 Using sip/sips/pres as a Dereference Scheme . . . . . . . 24
   5.  Geolocation Examples  . . . . . . . . . . . . . . . . . . . . 25
       5.1 Location-by-value (Coordinate Format) . . . . . . . . . . 26
       5.2 Location-by-reference . . . . . . . . . . . . . . . . . . 27
   6.  SIP Element Behavior  . . . . . . . . . . . . . . . . . . . . 28
       6.1 UAC Behavior  . . . Location URIs in Message Bodies . . . . . . . . . . . . . 12
       4.6 Location URIs Allowed . . . . . . 28
       6.2 UAS Behavior . . . . . . . . . . . . 12
   5.  Geolocation Examples  . . . . . . . . . . 33
       6.3 Proxy Behavior . . . . . . . . . . 13
       5.1 Location-by-value (Coordinate Format) . . . . . . . . . . 13
       5.2 Two Locations Composed in Same Location Object Example  . 38
   7. 14
   6.  Geopriv Privacy Considerations  . . . . . . . . . . . . . . . 42
   8. 16
   7.  Security Considerations . . . . . . . . . . . . . . . . . . . 43
   9. 17
   8.  IANA Considerations   . . . . . . . . . . . . . . . . . . . . 45
       9.1 18
       8.1 IANA Registration for New SIP Geolocation Header  . . . . 45
       9.2 19
       8.2 IANA Registration for New SIP 'geolocation' Option Tag  . 45
       9.3 19
       8.3 IANA Registration for New 424 Response Code . . . . . . . 45
       9.4 19
       8.4 IANA Registration for New SIP Geolocation-Error Header  . 45
       9.5 19
       8.5 IANA Registration for New SIP Geolocation-Error Codes . . 46
       9.6 19
       8.6 IANA Registration of Location URI Schemes . . . . . . . . 47
   10. 20
   9.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . 47
   11. 20
   10. References  . . . . . . . . . . . . . . . . . . . . . . . . . 48
       11.1 21
       10.1 Normative References   . . . . . . . . . . . . . . . . . 48
       11.2 21
       10.2 Informative References . . . . . . . . . . . . . . . . . 49 22
       Author Information  . . . . . . . . . . . . . . . . . . . . . 49 22
       Appendix A. Requirements for SIP Location Conveyance  . . . . 50 23

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 This document are furthermore uses numerous terms defined here:

   LbyV:  Location-by-Value
   in RFC 3693 [RFC3693], including Location Generator (LG): The entity that initially determines or
      gathers the location of the Target and creates Objection, Location
      Objects describing the
   Recipient, Location Server, Target, and Using Protocol.

2.  Introduction

   Session Initiation Protocol (SIP) [RFC3261] creates, modifies and
   terminates multimedia sessions.  SIP carries certain information
   related to a session while establishing or maintaining calls.  This
   document defines how SIP conveys geographic location information of the
   a Target [RFC3693]. (Target) to a Location Inserter: Recipient (LR). SIP acts as a role created Using
   Protocol of location information, as defined in RFC 3693.

   In order to convey location information, this document describing the
      entity that included location in specifies a
   new SIP request, either by-value
      or by-reference (i.e., including header, the Geolocation header, which carries a location URI).

   Location Object (LO): An object conveying location information
      (and possibly privacy rules) to which Geopriv security
      mechanisms and privacy rules are reference to be applied [RFC3693].
   a Location Recipient (LR): The entity that receives location
      information.  It Object. That Location Object may have asked for this location explicitly
      (by sending appear in a query MIME body
   attached to a location server), the SIP request, or it may receive
      this location asynchronously [RFC3693].

   Location Server (LS): The entity to which be a LG publishes location
      objects, the recipient of queries from location receivers, and remote resource in the entity
   network.

   Note that applies rules designed by the rule maker
      [RFC3693].

      A Location Server per RFC 3693, a Target 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
   being conveyed. Thus, a Location Object [RFC3693].

2.  Introduction

   This document describes how geolocation can Target could 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.  This
   "something" is user agent (UA), some
   other IP device (a router or a Location Target.  Note PC) that this information is does not
   solicited (i.e., asked for have a SIP stack, a
   non-IP device (a person or requested) by the entity that receives
   it.  The mechanism in a black phone) or even a
   non-communications device (a building or store front). In no way
   does this document does not define how one SIP
   entity requests assume that the location of another SIP entity to be returned in user agent client which sends
   a response.

   Geographic location in the IETF is discussed in RFC 3693 (Geopriv
   Requirements) [RFC3693].  It defines request containing a "Target" as the entity whose location object is being transmitted over IP.  A [RFC3693]-defined "Using
   Protocol" describes how a "Location Server" transmits a "Location
   Object" to a "Location Recipient" while maintaining necessarily the contained
   privacy intentions Target.
   The location of the Target intact. This document describes a Target conveyed within SIP extension typically corresponds
   to carry that of a Location Object and how it complies with device controlled by the Using Protocol requirements in RFC 3693.

   Common terms are Target, for example, a mobile
   phone, but such devices can be separated from their owners, and
   moreover, in Section 1. Section 3 provides an overview of some cases the user agent may not know its own
   location.

   In the SIP context, a location conveyance.  Section 4 details the extensions to recipient will most likely be a SIP
   necessary
   UA, but due to accomplish location conveyance.  Section 5 gives decode
   examples the mediated nature of geolocation within SIP requests, both with a value and
   with architectures, location
   information conveyed by a reference.  Section 6 articulates the single 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 request may have multiple
   recipients, as any SIP by this document proxy server in section 4.

2.1 Scoping and Describing a the signaling path that
   inspects the location of the Target verses must also be considered a Device

   Geographic
   Location Recipient. In presence-like architectures, an intermediary
   that receives publications of location is related to a device, not information and distributes
   them to a user as far watchers acts as
   this document is concerned.  When a user is logged onto a device,
   the two entities are bound and Location Server per RFC 3693. This
   location conveyance mechanism can also be said used to be the same deliver URIs point
   to such Location
   Target - as far as this document is concerned.  This document
   specifies how one UA uses a SIP Servers where prospective Location Recipients can
   request to convey its whereabouts to
   another UA.

   Devices have a <device ID> element Location Objects.

3.  Overview of SIP Location Conveyance
   An operational overview of SIP location conveyance can be shown in a presence document for
   identification, which 4
   basic diagrams, with most applications falling under one of these
   basic use cases.

   Each diagram has Alice and Bob as UAs. Alice is usually its MAC (or equivalent) address.
   This element the Target, and Bob
   is not always present in the presence document.  As
   will be mentioned in Section 6.1, there are different ways to
   identify a Target, including an LR.  A SIP intermediary appears in the form some of a SIP Contact address
   (as defined by RFC 3261) or a pseudonym.

   In SIP, we often interchangeably use the terms 'Alice' and '(the)
   UA' to mean the same thing.  Sometimes we refer to 'Alice the user',
   which means the human, and not the diagrams. Any
   SIP instance of entity that receives and inspects location information is an endpoint.
   When we talk about 'Alice' without clarifying we are talking about LR,
   therefore any of the human user, we implicitly bind Alice and diagrams the UA as SIP intermediary receives the same
   entity, even if she is identified with a pseudonym in SIP signaling.
   This
   request is common practice throughout most SIP documents.  The Geopriv
   architecture potentially an LR - though that does not make this user-to-device binding very often in
   its documentation.

   The Geopriv architecture describes Location Targets (Target) and
   Location Recipients (LR), which can easily fit into mean such an
   intermediary necessarily has to route the SIP model by
   having request based on the
   location information.  In some use cases, location information
   passes through the LS on the right of each diagram.

      Alice send          SIP Intermediary       Bob her location.               LS
        |                |                   |                 |
        |       Request w/Location           |                 |
        |----------------------------------->|                 |
        |                                    |                 |
        |             Response               |                 |
        |<-----------------------------------|                 |
        |                |                   |                 |

        Figure 1. Location Conveyed by Value

   In this example, Figure 1, Alice is both the Target and Bob is the Location Recipient.  Here, we are not
   concerned with how a UA learns its location, either by being told
   where it LS that is or from conveying
   her location directly to Bob, who acts as an onboard GPS. LR. This conveyance is exclusively within
   point-to-point - it does not pass through any SIP-layer
   intermediary.  A Location Object appears by-value in the
   Geopriv architecture.

   In this document, we allow initial SIP servers
   request as a MIME body, and Bob responds to insert the Target's
   location while processing the that SIP request towards the destination.
   In this scenario, the originating UA (Alice) is always the Target.
   The location inserting SIP server as
   appropriate.  There is not the Target.

   We also allow SIP servers to be consumers of location, i.e., an LR,
   for the purposes of making routing decisions based on the location
   in a SIP request.

   This 'Bad Location Information' response code
   introduced within this document maintains the practice of other SIP documents by:

   o  a Target associated with a user has the inherited identity of
      that user (i.e., Alice or Bob). The SIP-URI will generally be
      similar to (or be) a Contact address, which could be a pseudonym
      for the user; (see Section 6.1 for more on this)

   o specifically inform Alice is a UA, as is Bob. Understanding SIP signaling will
      determine which is the UAC and which is the UAS.  We specify
      later that location can only be in a SIP request, even if that
      request contains the she
   conveys bad location of more than one Target.

   o  a Target without an identifiable user associated with it is not
      necessarily user-less, the binding is just not obvious or could
      purposely be a pseudonym (for security reasons) . The SIP-URI
      will be more like a fully qualified Call-ID (unique through space
      and time, as defined by RFC 3261);

   o  a Target which is user-less will likely have a SIP-URI, where the
      user-part of the address is the MAC (or equivalent) address of to Bob (i.e., Bob "cannot parse the device, location
   provided", or a pseudo-string id, but still a URI for this
      document's purpose;

   The above "there is informative in nature.

3.  Overview of SIP Location Conveyance

   The concept of conveying not enough location in SIP is fairly straightforward.
   Location is conveyed directly or indirectly from a transmitting SIP
   entity information to a receiving SIP entity.  When location is conveyed
   directly, it is conveyed as a value contained within the SIP
   request, as in Figure 1. determine
   where Alice is").

      Alice          SIP Intermediary       Bob               LS
        |                |                   |                 |
        |      Request w/ Location w/Location URI        |                 |
        |------------------------>|
        |----------------------------------->|                 |
        |                                    |    Dereference  |
        |       Response                                    |        Request  |
        |                                   (To: Location URI) |
        |                                    |---------------->|
        |                                    |                 |
        |                                    |    Dereference  |
        |                                    |       Response  |
        |                                  (includes location) |
        |                                    |<----------------|
        |             Response               |                 |
        |<-----------------------------------|                 |
        |<------------------------|
        |                |                   |                 |

        Figure 1. 2. Location Conveyed by Value

   When as a Location URI

   In Figure 2, location is conveyed indirectly, via a Location URI
   carried in the SIP message (more of those details later).  If Alice
   sends Bob this Location URI, Bob will need to dereference the URI -
   analogous to Content Indirection [RFC4483], Bob receives (from Alice) a location URI and
   must make an additional request - here called a dereference [RFC4483] - in order to
   learn Alice's actual request the
   location from a Location Server (LS)
   identified in information. In general, the LS provides the location URI, as in Figure 2. value
   to Bob instead of Alice directly.  From a user interface
   perspective, Bob the user won't know that this information was
   gathered from an LS indirectly rather than culled from the SIP
   request, and practically this does not impact the operation of
   location-based applications.

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

        Figure 2. 3. Location Conveyed by Reference

   Many protocols can be used for this dereference transaction, but
   this is usually determined by though a SIP Intermediary

   In Figure 3, we introduce the scheme idea of a SIP intermediary into the location URI in
   example to illustrate the
   SIP request. In other words, if role of proxying in the location URI is
   architecture. This intermediary could be a SIPS: URI,
   then SIPS would SIP proxy or it could be used to contact
   a back-to-back-user-agent (B2BUA).  In this message flow, the LS SIP
   intermediary may act as a LR, in addition to make the dereference. Bob. The primary use
   case for intermediaries consuming location "value" in this SIP extension information is in
   location-based routing. In this case, the form of intermediary chooses a
   "Presence Information Data Format - Location Object", or PIDF-LO, as
   described in [RFC4119].  A PIDF-LO is an XML scheme specifically
   next hop 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.  A UA can included request by consulting a specialized location URI in a SIP request header field, pointing at
   service which selects forwarding destinations based on geographical
   location. In this case, the intermediary acts as a Location
   Server, which
   Recipient.

   However, it can be dereferenced by the case that the SIP intermediary receives a Location Recipient of this
   request with location URI to retrieve information (conveyed either by-value or
   by-reference) and does not know or care about Alice's Location Object, always location, or
   support this extension, and merely passes it on to Bob - in this
   case, the form
   of intermediary does not act as a PIDF-LO.

   To accomplish location conveyance Location Recipient.

   Note that an intermediary does not have to perform location-based
   routing in SIP, order to be location recipient. It could be the case that
   a new SIP header field,
   Geolocation, is created and described in this document.  The
   Geolocation header field contains a URI intermediary which does not perform location-based routing but
   does care when Alice includes her location; for example, it could
   care that points to where the location information is complete or that it correctly
   identifies where Alice is. The best example of this is
   intermediaries that verify location information for the emergency
   calling, but it could also be for any location based routing - e.g.,
   contacting Pizza Hut, making sure that organization has Alice's
   proper location Target, either in the body of the initial SIP
   request itself, or on a Location Server.  A URI to help entities
   parse for request.

   If the location in a SIP request will (always) get this in
   the form of a "cid:" URI (Content Identification), as defined in
   [RFC2392].

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

   Location can be inserted in a SIP request by a SIP server as well as
   by a UA. This document offers guidance on this practice. This
   document also describes how a location recipient can determine which
   entity included a specific location, as more than one location 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, called the Geolocation-Error
   header field.  This header field has various codes that provide
   additional information about the type of location error experienced
   by a Location 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 which entity (identified by host-id) inserted a
   specific location is extremely important. Not only does this allow
   each location error to be Targeted at a particular inserter of a
   specific location object, but it also allows error recipients to
   understand when the location they inserted was not at fault, and
   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 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
   request's path.  It is possible to route SIP requests based on the
   location of the 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,
   then the Location Inserter can also include a separate indication in
   the Geolocation header field showing that this usage is not desired.

   Location Inserters have the ability to provide instructional
   parameters 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(s).

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

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

   RFC 3693 demands that a transmitted location 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 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 sections detail the standards track modifications
   to SIP for Location Conveyance.

4.1 The Geolocation Header Field

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

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

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

   The pres-URI is defined in [RFC3859].

   The cid-url is defined in [RFC2392] to locate message body
   parts.  This URI type is present in a SIP request when location
   is conveyed as a value.

   Other protocols used in the location URI MUST be reviewed against
   the RFC 3693 [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 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 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
      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 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 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 field.

   The "routing-allowed" header field parameter is a global parameter
   over any (and all/each) locationValues in the Geolocation header
   field.  The placement of the parameter is outside any locationValue,
   appears only once, and is always last in the header field value. The
   routing-allowed parameter MAY be present when no locationValue is
   present. This scenario sets the routing-allowed policy downstream
   along the request's signaling path.

   This header field parameter only has the values "=yes" or "=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.  Sections
   4.3 and 6.3 describe 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 a cid:url is present in the SIP
   request, intermediaries MUST NOT view the location (because it is
   not for intermediaries to view), and if a location URI is present,
   intermediaries MUST NOT dereference it.  UAs are allowed to view
   location in the SIP request even when the "routing-allowed"
   parameter is set to "no".

   There MUST not be more than one routing-allowed parameter in any SIP
   request, regardless of when there are cases of more than one
   Geolocation header field row (i.e., more than one Geolocation
   header in the SIP request, as defined in section 7.3.1 of RFC 3261).
   There does not have to be any routing-allowed parameter present in a
   Geolocation header value of a SIP request.  However, the default
   treatment of the absence of the routing-allowed parameter is as if
   it were present, and set to "=no" without exception.

   If a routing-allowed parameter is parsed as set to "=yes", an
   implementation MUST parse the rest of the SIP header for another
   instance of the Geolocation header value to determine if there is
   another instance of the routing-allowed parameter set to "=no". If
   this is the case, the behavior MUST be to process the "=no"
   indication only, and ignore the "=yes".

   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 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 UA.  A proxy MAY add the Geolocation 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 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., the UAC).

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

   #1  SIP Servers are not the best geographic locators of where a
       UA is; the location information that a SIP server knows might
       not be the best location information available.

   #2  this document gives limited guidance as to what a Location
       Recipient should do when receiving more than one location (no
       instructions are given about which locationValue to use when
       more than one is present), so adding a new locationValue may
       lead to undesirable results.

   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.

   Other modifications of the Geolocation header field MUST NOT occur
   without an update to this specification.

4.2 424 (Bad Location Information) Response Code

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

      424 (Bad Location Information)

   The 424 (Bad Location Information) response code is a rejection of
   the 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 (value or location
   URI), and the Location Recipient 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 an existing dialog.

   The UA 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 UA or any SIP intermediary as a result of this error message.
   The new 424 (Bad Location Information) error code is registered with
   IANA in Section 8 of this document.  An initial set of
   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 UA is to know what was wrong within the original request.
   The Geolocation-Error header field is used for this purpose.

   The Geolocation-Error header field is used to convey
   location-specific errors within a response.  Additional
   IANA-registered values must be defined in an RFC (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-arg SEMI
                               node-param SEMI inserter-param
   location-error-arg       = location-error-code
                               *(SEMI location-error-params)
   location-error-code      = 1*3DIGIT
   location-error-params    = location-error-code-text
                              / generic-param ; from RFC3261
   location-error-code-text = "code" EQUAL quoted-string ; from RFC3261
   node-param               = location-error-node-id
   location-error-node-id   = "node" EQUAL
                                 DQOUTE hostport DQOUTE ; from RFC3261
   inserter-param           = location-error-host-id
   location-error-host-id   = "inserter" EQUAL
                                 DQOUTE hostport DQOUTE ; from RFC3261

   The Geolocation-Error header field MUST contain at least one
   locationErrorValue to indicate what was wrong with the locationValue
   in the corresponding request the Location Recipient determined was
   bad. Each locationErrorValue contains 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.  This text string is OPTIONAL, but RECOMMENDED
   for easy understanding.

   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 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,

      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 locationValue of 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.  This is required because a Location Recipient that
   experienced 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 field, were it to
   remain generic to all entities in the response path.  This
   requirement means that the  header field identifies the Location
   Inserter who inserted the problematic locationValue, so that all
   other SIP entities that read the header field know to ignore 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
   be interpreted by each SIP entity along the original path upstream
   and be processed by both the server that included the invalid
   locationValue and the UAC that did not, resulting in confusion 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 something
   wrong with only one of the locationValues.  Without an
   identification of the specific locationValue in error, both entities
   would react, and one would react incorrectly.

   When more than one locationErrorValue is present in a
   Geolocation-Error header field, they are separated by 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 MUST NOT conflict in
   meaning.

   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 SIP requests
   included in table 2 above are the ones allowed to optionally contain
   the Geolocation header field (see section 4.1).  That said, a UAC
   MUST ignore a Geolocation-Error header field value that did not
   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 field, is in Figure 3.

      Alice                                              Bob
        |                                                 |
        |       Request w/ Location                       |
        |------------------------------------------------>|
        |                                                 |
        |                                                 |
        |  424 (Bad Location Information)                 |
        |  with Geolocation-Error containing              |
        |  200 ("Retry Location Later with same 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, based on how the response receiver should react
   to these errors.

   We start with a general purpose location error, meaning we are not
   being specific about what is wrong with the location provided, but
   it has been determined to be bad.

      o  1XX "Cannot Process Location"

   We next have an error that indicates there is probably nothing wrong
   with the location information provided, but the receiver cannot
   process it at this time.  A Retry-After header value will indicate
   how long to wait until sending location again to this Location
   Recipient and expect it to be processed.

      o  2XX "Retry Location Later with same data"

   We next have an indication that something was wrong with the
   location information supplied in the SIP request, and something on
   the sender's side needs to be done to correct the bad information.
   A Retry-After header value will indicate when to resend the location
   information.

      o  3XX "Retry Location Later with updated device location"

   We next have a permission flag contained with this SIP request
   indicating an LR need permission to reveal this information to a 3rd
   party (retransmission-allowed flag) or permission to view the
   contained location to properly process the SIP request
   (routing-allowed flag). We will define two individual errors here to
   facilitate informing the "inserter=" which flag needs to be adjusted
   if they want this SIP request processed further by this SIP entity.

      o  4XX "Permission To Use Location Information"

   Finally, we create a general location denial error, for times when a
   dereference was denied or timed-out.

      o  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, although the future error code may provide more
   granular information.  If another action is expected to occur with a
   newly defined error code, it MUST outside the 100-599 range.

4.3.1 Location Error: 100 "Cannot Process Location"

   The location error 100 "Cannot Process Location" indicates to a
   Geolocation-Error recipient that the locationValue supplied in a
   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 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 as if the "inserter="
   entity received a 2XX or 3XX location error. Implementations MUST
   NOT 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 100 location error is:

   Geolocation-Error: 100; code="Cannot Process Location";
                            node="bob.example.com";
                            inserter="alice.example.com";

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

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

   The location error 200 "Retry Location 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 update the location at a later
   time in a new SIP request.  For example, this location error is
   appropriate when the Location Recipient cannot process location at a
   specific time, or when there is there was a timeout when a location
   URI is dereferenced.

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

   Implementations SHOULD choose to react by queuing another message
   with the same location information, unless the "inserter=" entity
   knows it has changed locations.

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

   An example 200 location error is:

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

   This category covers all 2XX location errors.  The same basic
   reaction is expected when a location "inserter=" entity 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 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.2.1 Location Error: 201 "Linkable Target Identity Required"

   The error code 201 "Linkable Target Identity Required" is
   specifically for the event in which a SIP request requires a binding
   of the Target's identity to the presence document in order to know
   this is the Target's location to make an appropriate routing
   decision.  Because Alice could include Bob's location in her SIP
   request, the SIP server - in this specific case - needs to
   understand this message is routed based on Alice's location, and not
   Bob's.  There is no absolute binding between presence documents and
   SIP signaling, hence a separate error with specific behaviors are
   necessary.

   It is of particular importance is the 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 "entity="
   attribute. This is problematic for some (all?) source location based
   call routing situations.

   The "node=" routing intermediary makes this locationErrorValue a 201
   to resolve this problem. In the 424 response, the Retry-After header
   value of '0' is REQUIRED, indicating the new request be sent
   immediately, but with a Target identification resolved in the
   PIDF-LO and SIP request. In presence, the "entity=" attribute is
   typically the URI of the presentity, meaning something like the
   Contact address of the 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 Retry-After: 0 header value).

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

         201 location error indicate the "inserter=" did not properly
         identify the Target of this presence document.  The
         Retry-After has been received - or is assumed to be 0 -
         meaning the new SIP request is to be sent immediately.

4.3.3 Location Error: 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 what they
   supplied in a request, as far as location is concerned, cannot be
   processed. In order to retry this request in a new SIP request, the
   location information must be updated.

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

         3XX location errors indicate the "inserter=" SIP entity needs
         to refresh its location, or make the location information
         supplied more complete, without notifying the user of this
         error.  3XX errors may be resolved without user intervention.

   This document gives no guidance how this is accomplished, given the
   number of ways a UAC can learn its location, or a SIP intermediary
   can determine this UAC's location (with or without the help of a
   Location Server.

   This 300 location error currently does not indicate what exactly was
   wrong with the location supplied, according to the Location
   Recipient.  That is left for a future effort.

   Implementations MAY choose whether or not to inform the user of this
   error.  The text string of "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 was not received by the UA (i.e., the called
   party).

   A 3XX location error would be used where the Location Recipient
   cannot find or cannot parse the location supplied. 3XX location
   errors should cause a requestor to retry with refreshed location
   information, which might be sufficient to fix the problem.  Also, a
   3XX location error would be used when a Location Recipient was
   expecting to find location in a SIP request, but did not find it -
   perhaps an emergency request was made that did not contain location.
   The retry in this case would be in the form of an UPDATE Method
   request, containing location.  If the 424 response contains a
   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 300 location error is:

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

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

4.3.4 Location Error: 400 "Permission To Use Location Information"

   The location error 400 "Permission To Use Location Information"
   indicates to a Geolocation-Error recipient that they sent a
   particular SIP Request including location in that request, without
   giving permission in the request for an intermediary SIP entity to
   look at that 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 field parameter for
   proxy servers) to route the request toward the intended recipient
   (i.e., the called party).

   All 4XX level location errors are asking for permission from the
   "inserter=" to set a flag differently in order to accomplish
   something with the location.

   An example 400 location error is:

   Geolocation-Error: 400; code="Permission To Use Location
                            Information";
                            node="bob.example.com";
                            inserter="alice.example.com";

   Because there are two completely separate flags known at this time,
   one in the PIDF-LO (retransmission-allowed) and one as a Geolocation
   header parameter (routing-allowed), two separate Locations Errors
   are created to give the "inserter=" entity the specific choice to
   reset the right flag.

4.3.4.1 Location Error: 401 "Permission To Retransmit Location
                             Information to a Third Party"

   This location error is specific to having the PIDF-LO
   <retransmission-allowed> element set to "=no". This location error
   is asking for permission of the "inserter=" entity to resend the SIP
   request with a PIDF-LO <retransmission-allowed> element set to
   "=yes".

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

         The 401 location error indicates to the location "inserter="
         that the LR (i.e., a UA or SIP intermediary server) needs to
         have permission to transmit the supplied location information
         to a third party.  This indication MUST require human user
         intervention, acting as the Ruleholder of the policy on
         whether or not location is to be revealed.

   The user of the location "inserter=" device can choose to grant
   permission to the LR to allow this request to be sent on to another
   entity, or the user can deny permission.  It is the user's choice as
   Ruleholder.

   Implementations MUST provide the user, as Ruleholder, a clear
   indication that permission to consume their location is sought by an
   entity that is not the entity that the user is calling.  The text
   string of " Permission To Retransmit Location Information to a Third
   Party " is RECOMMENDED, but not mandatory for this error.
   Implementations MAY use another text string to inform the user that
   location is being sought by an LR.

   This document gives no guidance how the UA can seek permission from
   the user, given the number of ways a UA can accomplish this (i.e.,
   audio prompt or toggle or keystroke on the UA).

   An example 401 location error is:

   Geolocation-Error: 401; code="Permission To Retransmit Location
                            Information to a Third Party";
                            node="bob.example.com";
                            inserter="alice.example.com";

4.3.4.2 Location Error: 402 "Permission to Route based on Location
                             Information"

   This location error is specific to having the locationValue header
   parameter <routing-allowed> set to "=no". This location error is
   asking for permission of the "inserter=" entity to resend the SIP
   request with a locationValue header parameter <routing-allowed> set
   to "=yes".

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

         The 402 location error indicates to the location "inserter="
         that the LR (i.e., SIP intermediary server) needs to have
         permission in to look at and use the supplied location to
         complete the message routing.  This indication MUST require
         human user intervention, acting as the Ruleholder of the
         policy on whether or not location is to be revealed.

   The user of the location "inserter=" can choose to grant permission
   to this SIP intermediary server to allow this request to be routed,
   or the user can deny permission.  It is the user's choice as
   Ruleholder.

   Implementations MUST provide the user, as Ruleholder, a clear
   indication that permission to consume their location is sought by an
   entity that is not the entity that the user is calling.  The text
   string of "Permission to Route based on Location Information" is
   RECOMMENDED, but not mandatory for usage in this error.
   Implementations MAY use another text string to inform the user that
   location is being sought by an intermediary (i.e., not the called
   party).

   This document gives no guidance how the UA can seek permission from
   the user, given the number of ways a UA can accomplish this (i.e.,
   audio prompt or toggle or keystroke on the UA).

   This 402 location error indicates which specific SIP server needs
   the location by the "node=" FQDN address supplied, perhaps telling
   the user (via audio or video indication) which SIP entity wants its
   location learned for routing purposes.  Perhaps the user can know in
   some circumstances whether this is an appropriate "node=" (domain).
   This latter feature is not described in this document (just
   mentioned here as a possibility).

   An example 402 location error is:

   Geolocation-Error: 402; code="Permission to Route based on
                            Location Information";
                            node="bob.example.com";
                            inserter="alice.example.com";

4.3.5 Location Error: 500 "Location Information Denial"

   The location error 500 "Location Information Denial" indicates to a
   Geolocation-Error recipient that what they supplied in a request, as
   far as location is concerned, has been denied 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.  If this were applied to the SIP request itself, this 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 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 new request, then a 3XX location error would have been more
   appropriate.  An example of why this 5XX could have been returned is
   if location were sent as a location URI, and the LS denied the
   dereference request from the potential Location Recipient, this is
   the expected location error returned to the "inserter=" entity.  In
   all likelihood, this is a dereference function error, meaning this
   will not occur when location is carried by-value in the request.

   Implementations MUST NOT make any assumptions about the implications
   of this location error other than recognizing that a location based
   denial error has occurred.  This does not mean the SIP request was
   denied, or even had an error, unless the response was a 424.
   Otherwise, this only has to do with the location part of the
   request.

   The difference between a 1XX and a 5XX location error is simple.  A
   1XX location error is appropriate when a Location Recipient either
   does not know or cannot tell the "inserter=" entity what was wrong
   with the location supplied in a SIP request.  A 5XX location error
   is appropriate when the Location Recipient was purposely and
   actively prevented from retrieving the location information.  This
   could occur in a UA or SIP server.

   If implementations choose to inform the UA user of this error, the
   text string of "Location Information Denial" 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 5XX location errors.  The same basic reaction
   is expected when a location "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 sips:, or pres:, etc.) of the location URI
        is not supported - (100)
   - Format (geo or civic) is not supported - (100)
   - Found where location information should be in the request, but do
        not understand what is at that part of the request -(300)
   - Cannot find LS in location URI (no access or 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 used, as defined in
   [RFC3261], in the Require, Supported and Unsupported header fields.

4.5 Using sip/sips/pres as a Dereference Scheme

   If a location URI is included in a SIP request, it MUST be a SIP-,
   SIPS- or PRES-URI.  When PRES: is used, as defined in [RFC3856], if
   the resulting resolution resolves to a SIP: or SIPS: URI, this
   section applies.

   This document IANA registers 3 mandatory-to-implement URI schemes
   for a location URI:

      o  SIP:
      o  SIPS:
      o  PRES:

   These 3 are registered with IANA in Section 9.6.

   These schemes MUST be implemented according to this document.

   absoluteURI is not mandatory-to-implement, but allowed.

   Dereferencing a Target's 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 MUST
   contain a PIDF-LO. See Figure 4 for a basic message flow for a
   dereference. 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 specification.

     Alice                 Location Server                      Bob
       |                                                         |
       |               INVITE w/ Location URI                    |
       |-------------------------------------------------------->|
       |                          |                              |
       |                          |  SUBSCRIBE to location URI   |
       |                          |<-----------------------------|
       |                          |  200 (OK)                    |
       |                          |----------------------------->|
       |                          |                              |
       |                          |  NOTIFY   w/ PIDF-LO         |
       |                          |----------------------------->|
       |                          |  200 (OK)                    |
       |                          |<-----------------------------|
       |                          |                              |
       |                       200 (OK)                          |
       |<--------------------------------------------------------|
       |                          |                              |

           Figure 4. Location-by-Reference and Dereferencing

   In Figure 4, Alice sends Bob her location as a location URI.  Bob
   receives this location URI in the INVITE and generates a new
   transaction (SUBSCRIBE) to retrieve Alice's PIDF-LO.  If accepted,
   the PIDF-LO will be returned in the NOTIFY request from the Location
   Server to Bob's UA.  This is the first instance between Alice and
   Bob that Alice's location is in any message.

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

   A dereference of a location 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.

   Certain nuances about this subscription exist that will not be
   covered in this document. Instead these additional functions will be
   described in the following document: [ID-GEO-FILTERS].  Here we
   introduce the general concept; the "Filters" document has the
   details.  These two are consistent with each other.

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 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 the
   form of a PIDF-LO.  Section 5.2 shows an location 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 location.  In
   this example, the SIP request uses a 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>
          <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>2010-02-12T06:00:00Z</gp:retention-
                            expiry>
            </gp:usage-rules>
            <gp:method>802.11</gp:method>
           </gp:geopriv>
         </status>
         <timestamp>2010-02-12T04:00:00Z</timestamp>
        </tuple>
      </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 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 existence of a non-"cid:" scheme indicates this is a
   location URI, to be dereferenced to learn the Target's location. Any
   node wanting to know where user "target123" is would subscribe to
   server5 to dereference the 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 PIDF-LO, as if it were
   included in a message body  (part) of the original INVITE.

5.2 Location-by-reference

   Below is 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 Atlanta Location Server the location URI is pointing towards.
   Dereferencing, if done using SIP, is accomplished by the Location
   Recipient sending a SUBSCRIBE request to the URI 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). The NOTIFY, in this case,
   and not the INVITE, is the 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 only message body)

   A Location Recipient would need to dereference the sips-URI in the
   Geolocation header field to retrieve Alice's location.  If the
   atlanta.example.com domain chooses to implement location conveyance
   and delivery in this fashion, it is RECOMMENDED that entities
   outside this domain be able to reach the dereference server, unless
   location is intentionally restricted within the atlanta.example.com
   domain.

6.  SIP Element Behavior

   Because a device's location is generally considered to be sensitive
   in nature, location information needs to be protected when
   transmitted.  This can be addressed through securing the location
   information to prevent either viewing or changing the PIDF-LO.

   Section 26 of [RFC3261] defines the SIPS security functionality by
   transporting SIP messages with either TLS protection between SIP
   entities.

   If a SIP entity wants to prevent all SIP entities in a request path
   that do not possess a decryption key from viewing or changing the
   contents of the PIDF-LO, the message body needs to be secure by a
   means such as S/MIME.

6.1 UAC Behavior

   A UAC might choose to send location in a SIP request to facilitate
   location-based routing of the request, or for some other purpose.
   Alice communicating her location to Bob in a SIP request is a simple
   example of this.  If Alice wanted to include her location 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), and this
   document does not limit which type of multipart is used, though
   future documents might  specify or limit multipart to a subset of
   all the choices for a given use.

   A UAC conveying location MUST include a locationValue 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 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 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 partial or complete geodetic and a partial or complete
   civic, allows the recipient to select the most preferred format for
   its use.  Additional complementary location information can be in
   the second format as well.

   Multiple PIDF-LOs are allowed in the same request, with each allowed
   to point at separate positions - however, each PIDF-LO MUST identify
   a different Target (i.e., in the "entity=" attribute in the
   <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 a
   single SIP request.  More than one will likely lead to confusion by
   a Location Recipient because this extension does not provide
   guidance on what a recipient is to do with more than one location
   for the same Target (which could point to different positions), nor
   does it give any preference regarding which location is more or less
   reliable than another location in the same request.

   The presence of the 'geolocation' option tag in a Supported header
   field without a Geolocation header field in the same message informs
   a SIP element receiving this request that the UAC understands this
   extension, but it does not know or wish to convey its location at
   this time.  Certain scenarios exist (location-based retargeting) in
   which location is required in a SIP request in order to retarget the
   message properly.  Indicating support with a geolocation option tag
   affects how a UAS or SIP server processes such a request. For
   example, it ought to understand that erroring the request because
   there was no location in the request is likely not going to result
   in the location appearing in the subsequent request.

   The 'geolocation' option tag SHOULD NOT be used in the Proxy-Require
   header field, because often the UAC will not know the underlying
   topology to know which proxy will do the retargeting, thus
   increasing the likelihood of a request failure at the first hop
   proxy that does not understand this extension, as is required by
   inclusion of the option tag in this header field.

   A UAC inserting a locationValue MUST include an "inserted-by="
   parameter to indicate its hostport.  This is copied to the
   "inserter=" parameter of the Geolocation-Error header field in a
   response if a Location Recipient determines there is something wrong
   with the locationValue in 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 problem
   in the response, and who 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 the network (DHCP or LLDP-MED), the UAC MAY learn its
   location URI (from DHCP for example).  If the latter is the case,
   the UAC can SUBSCRIBE to this location URI, using the 'presence'
   event package, to get and store its own location.

   The Location Server will likely challenge requests to dereference a
   Target's location URI. The location URI SHOULD be treated as
   equivalent to possession of the location information itself and thus
   TLS SHOULD be used when transmitting any location URI hop-by-hop
   along the path to the Location Recipient, for protection reasons.
   This is not to be confused with a 'possession model', in which
   possessing the location URI grants authorization to dereference the
   URI.  Any entity dereferencing the location URI MUST pass whatever
   authentication and authorization rules are on the LS to acquire this
   location.  The Ruleholder from [RFC3693] is still very much in
   control - for any entity possessing the location URI.

   If the Location Generator wishes to control whether any location
   included in the SIP request or added along the signaling path of
   this request can be viewed for routing decisions, the Location
   Generator adds a Geolocation header field value including the
   "routing-allowed=no" parameter.  This header field parameter
   provides specific policy rules for each locationValue (if more than
   one locationValue is inserted along the signaling path) within the
   SIP request.  A UAC SHOULD include the "routing-allowed" header
   field parameter, with or without a locationValue, to each SIP
   request supporting this specification to ensure the UAC's policy for
   intermediaries which might add a locationValue of the Target
   downstream.  The default behavior for SIP servers is to consider
   this value to be present, with a value of "=no".  A "=no" value in
   this parameter indicates there can be no routing decisions derived
   from the UAC's location.  UACs MUST be prepared to receive an error
   indicating a SIP intermediary needs to have this parameter set
   to"=yes" in order to properly routing this message.  The UAC can
   make a local policy choice as to whether it wishes to set the
   parameter to "=yes", thus allowing each SIP entity along the message
   path to use the UAC's location when making routing decisions.  There
   is no way to indicate that only a subset of SIP intermediaries have
   permission, while other intermediaries do not.

   There is no feedback mechanism to inform the Target if a SIP server
   has included a locationValue downstream. If a UAC has already
   conveyed location in the original request of a transaction, and
   wants to update its location information (for whatever reason) after
   the original request is sent, or after a dialog is created, this is
   done by sending an UPDATE request [RFC3311]. The UPDATE will include
   a geolocation option tag and Geolocation header field with the new
   locationValue to the original destination UAS.

   A presence document includes identity information (in the "entity="
   attribute of the <presence> element), although the identity could be
   an unlinkable pseudonym [RFC3693].  Implementations of this
   extension SHOULD consider the appropriateness of including an
   unlinkable pseudonym as the identity in the location information
   where a real identity is not required.  See the concerns raised in
   section 4.3.2 about unlinkable pseudonyms in relation to their
   potential problems with requests that need to route based on the
   location contained in the message.

   A location URI MUST NOT contain any user identifying information.
   For example, it is much more secure to use something unidentifiable
   like

      3fg5T5yqWowhGLn54wg4NgHlkDsFn@example.atlanta.com

   rather than something identifiable like

      aliceishere@example.atlanta.com.

   Use of self-signed certificates is inappropriate for use in
   protecting a PIDF, as the sender does not have a secure identity of
   the recipient.

   Although this is discussed in more detail in 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 "yes", Bob is free to tell Carol
   where Alice is (as long as the <retention-expiry> time has not
   elapsed, indicating that the location information should have
   already been deleted, according to RFC 4119).  This is an implicit
   byproduct of the PIDF-LO rule-set, as of this writing. This decision
   is a configuration issue, but is worth mentioning here.

6.1.1 UAC Receiving a Location Failure Indication

   Location Recipients that use the location information for
   location-based routing decisions can be either destination UAs or
   intermediate servers.  If a request fails based on the location
   information in the request, a 424 (Bad Location Information)
   response is sent back to the UAC.  The 424 MUST have a
   Geolocation-Error header field containing one or more
   locationErrorValues in the response message.  A locationErrorValue
   has a header field parameter indicating which entity inserted the
   locationValue correlated to this error, called the "inserter="
   parameter.  This "inserter=" parameter (in the locationErrorValue)
   is copied from the "inserted-by=" parameter (from the locationValue)
   by the Location Recipient (UA or proxy) sending the error response.
   A 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 be ignored.

   o  If a locationErrorValue is in a 424, and the "inserter=" entity
      is not this UAC, the response SHOULD be treated as a 400
      response.

   o  If locationErrorValue does indicate this UAC, this UAC MUST
      process the response, including the Geolocation-Error code
      (defined in section 4.3), taking the action described in that
      section for the received error code.

   Additionally, the UAC MUST ignore a Geolocation-Error header field
   value, even for this UAC, even in a 424 response if the UAC did not
   include a Geolocation header field value (with locationValue) in the
   request part of the transaction.

   A UAC MAY reattempt a new request if it 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 MUST follow all the guidance that pertains to UACs from
   Section 4.3 (Geolocation-Error Header Field), heeding what to do
   when it receives any of the error codes articulated in that section.

   Any UAC that inserted location into a request MUST be prepared to
   receive the Geolocation-Error header field in any response, looking
   to determine if a locationErrorValue is meant for the UAC, and to
   react accordingly.

   If a UAC includes location in a request, and either the UAS does not
   determine errored location was critical to the 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 Behavior

   If the Geolocation header field is present in a received SIP
   request, the type of URI contained in the locationValue will
   indicate if location is in a message body (part) or requires an
   additional dereference transaction.  If the location URI is sip:,
   sips: or pres:, and the UAS wants to learn the UAC's location, the
   UAS MUST SUBSCRIBE to the provided URI to retrieve the PIDF-LO being
   conveyed by the UAC as defined in  [RFC3856].  If successful, the
   Target's PIDF-LO will be returned in the NOTIFY request from the
   remote host.  The UAS is not REQUIRED to dereference the location
   URI if location is not needed to process the request. It is
   RECOMMENDED the UAS display the location to the user, or otherwise
   render the location appropriately.

   A Require header field with the 'geolocation' option tag indicates
   the UAC requires that the UAS understand this extension, sending an
   error response if it does not.  A 420 (Bad Extension) with a
   'geolocation' option tag in an Unsupported header field would be the
   appropriate response in this case.

   It is possible, but undesirable, for a message to arrive with a body
   containing an LbyV, but with no Geolocation header field value
   pointing to 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 appear in any other SIP header field.

   There are 3 Geolocation header field parameters,

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

   The "inserted-by=" and "used-for-routing" parameters are contained
   within a locationValue, whereas the "routing-allowed" parameter is
   outside any locationValue, and is to appear at most once in the SIP
   request.

   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 "inserter="
   parameter in each locationErrorValue if there is an error in the
   location to be reported back to the location sender.  See section
   6.2.1.

   The "used-for-routing" parameter is included in the locationValue if
   a SIP server used the location in the request to determine how to
   route or forward the message towards the ultimate destination.  If
   there are more than one locationValues in the Geolocation header
   field, it is possible that different locationValues were used to
   route the message at different points along the path traversed by
   the request.  This is allowed, as it is consistent with the rule
   that whenever a message is routed based upon a locationValue, a
   "used-for-routing" parameter is added to 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 a locationValue in a 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
   Location Recipient which was the last locationValue in the message
   that was 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 ultimate
   destination.

   A UAS MUST NOT send location in a response message, as there can be
   any number of issues/problems with receiving location, and the UAC
   or proxy server(s) cannot reply to a response with an error
   response.  If the UAS wants to send its location to a UAC, it can do
   so in a new request within a separate transaction.  This document
   gives no recommendation about which SIP request to use, but SIP
   MESSAGE is a viable choice.

   A UAS MAY include a 'geolocation' option tag in the Supported header
   field of a response, indicating it does understand this extension,
   even if location was not included in a request to the UAS.

   A UAS wishing to dereference a location URI contained in a received
   request will use the 'presence' event package in a SUBSCRIBE request
   to the URI.  If accepted, the LS will return the PIDF-LO to the UAS
   in one or more NOTIFY requests -  depending on the duration of the
   subscription.  If there are any errors during dereferencing,
   or in the PIDF-LO itself, the UAS will respond to the original
   request with a locationErrorValue indicating what the UAS concluded
   was wrong with the location.  This is to include any dereferencing
   problems encountered.

   Dereferencing for sip:, sips: and pres: URI schemes are
   mandatory-to-implement.

   A UAS MUST be prepared to receive subsequent location updates from
   upstream entities (regardless of how the UAS received location
   previously from this UAC).  The UAC will convey updated location
   using the UPDATE [RFC3311] method to the UAS, and not a reINVITE.
   The UAS MUST NOT reject updated location arriving in a reINVITE
   though, as other dialog parameters might be changing also (in which
   a reINVITE is appropriate).

   If there is more than one location (any combination of PIDF-LOs or
   location URIs), this document does not give guidance as to what a
   Location Recipient does with each location.  There are no priority
   or '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 PIDF-LO,
   location elements in the same PIDF-LO MUST apply to the same Target
   (identified in the "entity=" attribute) and MUST point at the same
   position on the earth.  If there is more than one PIDF-LO with
   different Target identifiers, then the UAC is merely telling the UAS
   where more than one Target is, and there SHOULD NOT be any conflict.

   Within any PIDF-LO, there is a <retransmission-allowed> policy
   element that can be set to "yes" or "no".  These are the only
   possibilities. If Alice conveys her location to Bob (as has been
   described throughout this document) with a <retransmission-allowed>
   element set to "no", then Bob MUST NOT inform any other element
   where Alice is.  If the <retransmission-allowed> element is set to
   "yes", then Bob can inform other elements where Alice is, but only
   as long as the <retention-expiry> policy element, also in the
   PIDF-LO, allows [RFC4119].  As a byproduct of this, that means that
   if Alice conveys her location to Bob with a <retransmission-allowed>
   element set to "yes", and the <retention-expiry> time does not
   require Bob to delete Alice's location yet, then Bob is free to tell
   anyone else where Alice is.  The "entity=" attribute in the
   <presence> element identifies who is the 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 behavior does not change when SIP is the Using
   Protocol.

6.2.1 UAS Generating a Location Failure Indication

   If a UAS receives location in a request, but determines there is a
   problem with the location in the request, it is the responsibility
   of the UAS to inform the entity that inserted the problematic
   location into that request.  The Geolocation header field in the
   request has a locationValue, providing the UAS a location URI
   indicating where the Target's location is. The Location Target
   identified in the PIDF-LO may or may not be the location inserter,
   or the generator of the request.  Ultimately, location is in a
   PIDF-LO.  This is either in the request as a message body (LbyV), or
   obtained by initiating a dereference transaction on a Location
   Server identified in the location URI.  Location Servers typically
   challenge all dereference requests.  All PIDF-LOs have a Location
   Target identifier.  The "inserted-by=" parameter of the
   locationValue tells the UAS which SIP entity inserted that
   locationValue.  This "inserted-by=" parameter is copied into the
   "inserter=" parameter of the locationErrorValue generated by the
   Location Recipient (the UAS), in a response, when it wants to inform
   the location "inserter=" entity there was a problem with the
   location it received.

   There can be more than one locationValue in a request.  The
   "inserter=" parameter in the locationErrorValue will prevent
   entities that did not insert the errored location from
   misunderstanding whether the locationErrorValue applies to them.

   If there is one valid locationValue in a request, even if all the
   others have errors associated with them, the Location Recipient MUST
   NOT send a 424 (Bad Location Information) response.  The Location
   Recipient  (the UAS) MUST send a locationErrorValue for each errored
   locationValue, 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 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 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 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 "inserted-by=" entity, meaning either the UAC or
   proxy in intermediary rejects the message path chose due to indicate that unsuitable
   location was
   sufficiently important information (we are not going to include a 'geolocation' option tag in a
   Require header field, discuss any error response SHOULD be a 424 (Bad
   Location Information) back to the "inserter=" entity (knowing other reasons
   in this document, and there are many), the SIP response will ultimately go to the UAC regardless) if
   indicate there needs to
   be a good locationValue sent to properly process the request.  Only
   entities identified was 'Bad Location Information' in a locationErrorValue as the "inserter="
   entity will pay attention to this locationErrorValue.  All other
   entities MUST ignore any locationErrorValue not directed towards
   them.  See section 4.3 for more information on this, including all the location-specific errors SIP request,
   and Geolocation-Error header field
   parameters.

   In the above scenario ('geolocation' option tag in a Require
   header field), the only other response can be provide a 420, if the UAS
   does not support this Geolocation extension to SIP.

   If the "inserted-by=" location entity placed the 'geolocation'
   option tag in a Supported header field, the response can be a 424 if
   it chooses, but also can be any other specific error code indicating what Alice
   needs to do to send an acceptable request.

      Alice          SIP response, including a 200
   OK.  A locationErrorValue in a Geolocation-Error header field that
   is not in a 424 (Bad Intermediary       Bob               LS
        |                |                   |                 |
        |   Request      |                   |                 |
        |    w/Location  |                   |                 |
        |--------------->|                   |                 |
        |                |                   |                 |
        |   Rejected     |                   |                 |
        | w/New Location Information) response is considered
   informational by the |                   |                 |
        |<---------------|                   |                 |
        |                |                   |                 |
        |   Request      |                   |                 |
        | w/New Location |                   |                 |
        |--------------->|                   |                 |
        |                |    Request        |                 |
        |                |  w/New Location   |                 |
        |                |------------------>|                 |
        |                |                   |                 |

        Figure 4. SIP Intermediary Replacing Bad Location Recipient, and does not cause

   In this last use case, the
   Location Recipient SIP intermediary wishes to reject the request solely because of bad
   location information.

   For example, include a
   Location Object indicating where it understands Alice INVITEs Bob to a dialog, and includes geolocation be. Thus,
   it must inform her user agent what location she should include in
   any subsequent SIP request that contains her location. In these
   cases, the request. Bob intermediary can accept reject Alice's request, through the INVITE with a 200 OK and still
   add a locationErrorValue in SIP
   response, convey to her the 200 OK indicating "yes, I accept
   your request, and btw, something was wrong with best way to repair the location you
   provided request in order
   for the INVITE".  The specific problem with the intermediary to accept it.

   Overriding location is
   indicated information provided by the Geolocation-Error code. The "inserter=" parameter
   identifies user requires a
   deployment where an intermediary necessarily knows better than an
   end user - after all, it could be that Alice has an on-board GPS,
   and the Location Inserter this locationErrorValue SIP intermediary only knows her nearest cell tower. Which is intended
   for.

   Each locationErrorValue
   more accurate location information? Currently, there is destined for one "inserter=" entity.
   This gives a Location Recipient a mechanism no way to
   tell each inserter
   what the Location Recipient concluded was wrong with the location
   the "inserter=" which entity included.  Therefore,

   o  there MUST be a locationErrorValue is more accurate, or which is wrong - for each locationValue that
      was considered bad by the UAS
   matter.  This document will not specify how to ensure each upstream location
      inserter understands indicate which error code
   location is intended for the
      inserter (and which to ignore).

   o  there MUST NOT be more than one locationErrorValue in the
      response per locationValue in the request.

   o  there MUST NOT be more accurate than one locationErrorValue with the same
      "inserter=" entity in the request.

   o  there MUST NOT be a locationErrorValue in another. If desired, intermediaries
   may furthermore allow both Alice's internally generated location, as
   well as the response for a
      locationValue SIP intermediary's determination of where Alice, to
   appear in the same SIP request (the resubmitted one), and permit
   that was not in error, according to
      the Location Recipient.

   Here be forwarded to Bob. This case is discussed in more detail
   in section 4.2 of this document.

   As an example aside, it is not envisioned that any SIP-based emergency
   services request (i.e., IP-911, or 112 type of call attempt) will
   receive a Geolocation-Error header field

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

   The above example says that the corrective 'Bad Location Recipient is
   server42.example.com, and this entity cannot verify Information' response from an
   intermediary.  Most likely, the Target's
   identity within this message. This is typically needed SIP intermediary would in order to
   make routing decisions that
   scenario act a B2BUA and insert into the request by-value any
   appropriate location information for the benefit of Public Safety
   Answering Point (PSAP) call centers to expedite call reception by
   the emergency services personnel; thereby, minimizing any delay in
   call establishment time. The implementation of these specialized
   deployments is, however, outside the scope of this document.

4.  SIP request where Modifications for Geolocation Conveyance

   The following sections detail the "entity="
   attribute has an unlinkable pseudonym obscuring a modifications
   to SIP for location Target's
   identity from the signaling. conveyance.

4.1 The Geolocation Header

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

   Geolocation        =  "Geolocation" HCOLON locationArg
                          (*COMMA locationArg)
   locationArg        =  locationValue / routing-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       =  generic-param;  (from RFC 3261)
   routing-param      =  "routing-allowed" EQUAL "yes" / "no"

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

   The pres-URI is not desire because if Alice's defined in [RFC3859].

   The cid-url is defined in [RFC2392] to locate message body parts.
   This URI type is to be routed based on the location present in the a SIP request,
   server42 has to verify that this is Alice's location.  The
   appropriate action request when location is to send conveyed
   as a 424 (Bad Location Information)
   response with MIME body in the above (201) Geolocation-Error header value.  We do
   not want Alice's request routed based on Bob's location.

   See Section 4.3 for further rules about SIP message.

   Other URI schemas used in the Geolocation-Error header
   field and location URI MUST be reviewed against
   the locationErrorValue.

   This document says nothing about what RFC 3693 [RFC3693] criteria for a Location Recipient does with
   more than Using Protocol.

   The Geolocation header field has zero or one 'good' locationValue in a request (i.e., which to
   choose to use).  This scenario MAY be addressed in a future effort.

   Further, locationValue, but
   MUST NOT contain more than one error code locationValue.

   The placement of the "routing-allowed" header field parameter is allowed in
   outside the
   locationErrorValue - each having one "inserter=" parameter.

6.3 Proxy Behavior

   [RFC3261] states message bodies cannot locationValue, and MUST always be added by proxies.
   However, proxies are permitted to add a last in the header
   field to a request.
   This means that a proxy can add a Geolocation value. The routing-allowed parameter MAY be present when no
   locationValue is present. This scenario sets the routing-allowed
   policy downstream along the request's signaling path.  This header
   field with a dereferencable location URI, but not an LbyV message
   body.

   It parameter only has the values "=yes" or "=no".  When this
   parameter is allowed, but NOT RECOMMENDED, "=yes", the locationValue can be used for more than one 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 intermediary along the signaling path
   can be used by any SIP element intermediary to
   insert make routing decisions.
   Intermediaries that attempt to use the location into a request along its path.  As described earlier information for
   routing purposes in this document, each insertion spite of location into a SIP this counter indication may end up
   routing the request is
   accompanied by improperly as a new locationValue in result.  Sections 4.3 describes
   the details on what a Geolocation header field.
   Also described earlier, each locationValue MUST contain an
   "inserted-by=" value indicating routing intermediary does if it determines it
   needs to a Location Recipient use the host
   that inserted a specific location into a particular request.

   If, however, location is already in a SIP request, a SIP server
   SHOULD NOT add another location URI that identifies the same Target SIP request in the PIDF-LO (in the "entity=" attribute) order to process 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 further.

   The practical implication is permitted,
   but can cause confusion at that when the recipient.  If a proxy chooses "routing-allowed"
   parameter is set to add "no", if a locationValue cid:url is present in the SIP
   request, intermediaries MUST NOT view the location (because it is
   not for intermediaries to view), and if a Geolocation header field, which would be a
   local policy decision, the new locationValue location URI is present,
   intermediaries MUST be added NOT dereference it.  UAs are allowed to view
   location in the
   end of SIP request even when the header field (after previous locationValue(s)).  This "routing-allowed"
   parameter is
   done set to create an order of insertion of locationValues along the
   path.  Proxies "no".  An LR MUST NOT modify by default consider the order of locationValues in a
   geolocation
   "routing-allowed" header field.  Section 4 covers more details parameter as set to "no", with
   respect no
   exceptions, unless the header field value is set to "yes".

   If a routing-allowed parameter is parsed as set to "=yes", an
   implementation MUST parse the rules rest of usage the SIP headers for another
   instance of the Geolocation header value(s).
   Each rule MUST be obeyed as written there.

   A proxy wishing to dereference a location URI contained in a
   received request will use the 'presence' event package in a
   SUBSCRIBE request value to the URI, but only determine if there is
   another instance of the "routing-allowed"
   header routing-allowed parameter is set to "=yes".  This transaction is described in
   Section 4.5. "=no". If accepted,
   this is the LS will return case, the PIDF-LO behavior MUST be to process the
   proxy in a NOTIFY request.  If there are any errors during
   dereferencing, or in "=no"
   indication only, and ignore the PIDF-LO itself, "=yes".

   This document defines the proxy will send an
   error to Geolocation header field as valid in the UAC with a locationErrorValue indicating what
   following SIP requests:

      INVITE [RFC3261],             REGISTER [RFC3261],
      OPTIONS [RFC3261],            BYE [RFC3261],
      UPDATE [RFC3311],             INFO [RFC2976],
      MESSAGE [RFC3428],            REFER [RFC3515],
      SUBSCRIBE [RFC3265],          NOTIFY [RFC3265],
      PUBLISH [RFC3903],            PRACK [RFC3262]

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

      Header field             where proxy
   concluded was wrong with the location.  This is to include any
   dereferencing problems encountered.

6.3.1 Proxy Behavior with INV ACK CAN BYE REG OPT PRA
      ----------------------------------------------------------------
      Geolocation              R     ar     o   -   -   o   o   o   o

      Header Field Parameters

   SIP servers MUST field             where proxy SUB NOT delete any existing UPD MSG REF INF PUB
      ----------------------------------------------------------------
      Geolocation locationValue
   (URI or header field parameter) from a request.  An existing
   locationValue MAY 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.

   According to this specification, the default value              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
   optional requests by a UA.  A proxy MAY add the Geolocation header value
   field, but MUST NOT modify any pre-existing locationValue, including
   the "routing-allowed" is "no". If header field value.

   A SIP intermediary MAY add a Geolocation header value field if one is received by a SIP server with not
   present - for example, when a "routing-allowed"
   parameter set to "=no", user agent does not support the SIP server MUST NOT view
   Geolocation mechanism but their outbound proxy does and knows their
   location, or dereference
   the location any of a number of other use cases (see Figure 4 in the
   section 3).  When adding a Geolocation header, a SIP request. If there is no intermediary
   MAY supply the "routing-allowed" parameter if not yet present in the
   SIP request (i.e., all instances of Geolocation
   header field rows (as defined request.

   SIP implementations are advised to pay special attention to the
   policy elements for location retransmission and retention described
   in section 7.3.1 of RFC 3261), the
   previously stated default 4119.

4.2 424 (Bad Location Information) Response Code

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

      424 (Bad Location Information)

   The 424 (Bad Location Information) response code is a rejection of
   the request due to treat its location contents, indicating location
   information that was malformed or not satisfactory for the Geolocation header value
   as if it contained a "routing-allowed=no" parameter, without
   exception.  Therefore, this parameter does
   recipient's purpose, or could not have to be present to
   deny dereferenced.

   A SIP servers along intermediary can also reject a location it receives from a
   Target when it understands the signaling path Target to be in a different location.
   The proper handling of this scenario is for the ability SIP intermediary to view
   include the
   Target's location. proper location in the 424 Response.  This parameter MAY SHOULD be added
   included in transit by a SIP
   server, and MUST be with the response as a value of "no".

   For example, an existing Geolocation locationValue in MIME message body (i.e., a request of:

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

   can be modified by location
   value), rather than as a proxy to add URI; however, in cases where the "used-for-routing" parameter,
   like this:

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

   if this
   intermediary is the locationValue the proxy used willing to make a retargeting
   decision based upon, share location with recipients but the proxy can make no other modification.

   A SIP server MAY add a new Geolocation locationValue to a SIP
   request.  The server SHOULD NOT insert not
   with a locationValue of user agent, a Target
   unless it is reasonably certain reference might be necessary.

   As mentioned in section 3 (below Figure 4), it knows might be the actual geographic case
   that the intermediary does not want to chance providing less
   accurate location of information than the Location Target (for example, if user agent; thus it thoroughly
   understands the topology will
   compose its understanding of where the underlying access network and it can
   identify the device location reliably, even user agent is in a separate
   <geopriv> element of the presence same PIDF-LO message body of NAT
   or VPN).  Routing errors are likely if the SIP server inserts an
   incorrect locationValue.

   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@ls7.atlanta.example.com>;
               inserted-by="ls7.atlanta.example.com"

   Notice the locationValue added by proxy "ls7" is last among
   locationValues.  Proxies MUST add locationValue at
   response (which also contains the end Target's version of all
   locationValues that where it is).
   Therefore, both locations are already present in the request.

   If this request was then retargeted by an intermediary using the
   locationValue inserted by 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@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 included - each potentially with
   different locationValue further towards <method> elements.  The proper reaction of the ultimate
   destination.  This retargeting decision can be made on a newly
   inserted locationValue.  While unusual, it can occur.  In such user agent
   is to generate a
   case, proxies MUST NOT remove any existing "used-for-routing" header
   field parameter.  In new SIP request that includes this instance, composed
   location object, and send it towards the original LR.  SIP server retargeting based
   on another locationValue MUST add
   intermediaries can verify that subsequent requests properly insert
   the "used-for-routing" suggested location information before forwarding said requests.

   Section 4.3 describes a Geolocation-Error header field parameter to provide
   more detail about what was wrong with the locationValue used for retargeting by this
   server. This will result location information in a Geolocation
   the request.  This header field indicating
   that MUST be included in the request has been retargeted more than once, which 424 response.

   The 424 is
   allowed.

   A Proxy that inserts or adds only appropriate when the Location Recipient needs a
   locationValue into and there are no locationValues included in a SIP
   request MAY move a
   'geolocation' option tag that is in are usable by a Supported header field into recipient, or as shown in Figure 4 of
   section 3, a
   Require header field if this proxy deems geolocation SIP intermediary is informing the UA which location to
   include in the next SIP request. A 424 MUST NOT be
   sufficiently important sent in response
   to Location Recipient(s) of a request that lacks a Geolocation header entirely, as the user
   agent in that case may not support this request. extension at all.

   A proxy can read any locationValue present, 424 (Bad Location Information) response is a final response within
   a transaction, and the associated body,
   if does not S/MIME protected, and can use the contents of the header
   field terminate an existing dialog.

4.3 The Geolocation-Error Header

   As discussed in Section 4.2, more granular error notifications
   specific to make location-based retargeting decisions, if retargeting
   requests based on location is errors within a function of that proxy.  Retargeting
   is defined in [RFC3261].  However, received request are required
   if the Geolocation header field
   parameter "routing-allowed" UA is present and set to "no", or is not
   present (the default behavior know what was wrong within the original request.
   The Geolocation-Error header field is "no" if "routing-allowed" used for this purpose.

   The Geolocation-Error header field is not
   present, whether or not used to convey
   location-specific errors within a Geolocation response.  The Geolocation-Error
   header field is present), SIP
   servers MUST NOT view the contents of has the location message body.
   Further, SIP servers following ABNF [RFC5234]:

   Geolocation-Error        = "Geolocation-Error" HCOLON
                                locationErrorValue
   locationErrorValue       = location-error-arg
   location-error-arg       = location-error-code
                               *(SEMI location-error-params)
   location-error-code      = 1*3DIGIT
   location-error-params    = location-error-code-text
                              / generic-param ; from RFC3261
   location-error-code-text = "code" EQUAL quoted-string ; from RFC3261

   The Geolocation-Error header field MUST NOT attempt contain only one
   locationErrorValue to dereference a location URI.
   This is because the Location Inserter (likely indicate what was wrong with the originating UAC)
   did not give locationValue
   the SIP server permission to view Location Recipient determined was bad. The locationErrorValue
   contains a 3-digit error code  indicating what was wrong with the
   location within in the SIP request.  How a SIP server indicates it requires permission
   to view  Each error code has a request's location in order to properly process this
   request corresponding quoted
   error text string that is described human understandable.  This text string is
   OPTIONAL, but RECOMMENDED for human readability.

   The following table extends the values in section 6.3.2.

   If 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 Geolocation-Error Header Field

   The Geolocation-Error header field parameter "routing-allowed" is
   present in a SIP request, the value MUST NOT MAY be changed during
   processing included in any response
   to one of the request.  If the Geolocation header field
   parameter "routing-allowed" is not present, above SIP servers MUST treat requests, so long as a Geolocation
   locationValue was in the request part of the transaction.  For
   example, Alice includes her location within in an INVITE to Bob. Bob can
   accept this INVITE, thus creating a dialog, even though his UA
   determined the request as if location contained in the INVITE was bad.  Bob merely
   includes a Geolocation-Error header field parameter
   "routing-allowed" were present and set to "no".

   B2BUAs and SBCs should also adhere to value in the above proxy guidance with
   respect 200 OK to the "Routing-allowed" header field parameter. In other
   words, if
   INVITE informing Alice the particular type of SIP server mentioned here supports
   this SIP extension and is not INVITE was accepted but the ultimate destination of this location
   provided was bad. The SIP
   request, each policy rule within requests included in table 2 above are the
   ones allowed to optionally contain the Geolocation header field MUST
   remain intact and unchanged.

   SIP server MUST NOT delete (see
   section 4.1).

   If, on the other hand, Bob cannot accept Alice's INVITE without a "routing-allowed" header field
   parameter, but if one
   suitable location, a 424 (Bad Location Information) is not yet present, sent. This
   message flow is shown in Figures 1, 2 or 3 in Section 3.

   The following subsections provide an initial list of location
   based errors for any SIP server MAY add a
   "Routing-allowed" header field parameter with non-100 response, including the new 424
   (Bad Location Information) response.  These error codes are divided
   into 4 categories, based on how the value set response receiver should react
   to "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, all these errors.

   o  1XX errors mean the LR cannot process the rules applicable to a UAS apply (see Section 6.2.1.).
   The one point to add is that a proxy does not need to examine location contained in a within the
      request. Section 6.2.1. only applies to
   proxies that need

   o  2XX errors mean the LR wants the LS to monitor send new or police updated
      location within requests (for
   whatever reason).

   If a proxy inserted a locationValue into information, perhaps with a request, it MUST be
   ready delay associated with when
      to examine send the response to that request, in case there request.

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

   o  4XX errors in mean there was trouble dereferencing the response.  To Location URI
      sent.

   All 4 of these error groups have a great degree, this
   scenario has top level error code with the proxy behaving
   meaning as stated above (i.e., a UAC (see section 6.1.1.) that
   included a locationValue Location Error: 100 is "Cannot
   Process Location", etc).  There are two exceptions necessary to
   include in this document, both have to do with permissions necessary
   to process the SIP request; they are

   Location Error: 301 "Permission To Retransmit Location
                        Information to a request, which then receives an Third Party"

   This location error is specific to
   that locationValue.

   This location-inserting proxy SHOULD be (at least) transaction
   stateful for the response.  If having the proxy Presence Information
   Data Format (PIDF-LO) [RFC4119] <retransmission-allowed> element set
   to "=no". This location error is configured as a
   stateless proxy, and it inserts location, stating it MUST process and
   monitor all requires permission
   (i.e., PIDF-LO <retransmission-allowed> element set to "=yes") to
   process this SIP responses, looking for locationErrorValues that
   indicate it was request further.  If the "inserter=" to learn that LS sending the location
   information does not want to give this permission, it
   supplied was will not reset
   this permission in error.  It SHOULD react according to a new request. If the error code
   received. LS wants this message
   processed without this permission reset, it MUST choose another
   logical path (if one exists).

   Location Error: 302 "Permission to Route based on Location
                        Information"

   This document gives no guidance what the proxy should do location error is specific to rectify having the bad locationValue header
   parameter <routing-allowed> set to "=no". This location information, since the proxy error is not the
   SIP response destination, but
   stating it requires permission (i.e., a future document could address this.

   The "routing-allowed" parameter's purpose is <routing-allowed> set to indicate if
   "=yes") to process this SIP
   servers along request further.  If the signaling path should bother looking at LS sending the
   location message body or dereferencing information does not want to give this permission, it will
   not reset this permission in a new request. If the location URI.  There are
   two values specified here for LS wants this parameter: "yes"
   message processed without this permission reset, it MUST choose
   another logical path (if one exists).

4.4 The 'geolocation' Option Tag

   This document creates and "no".  If registers with the "routing-allowed" parameter IANA one new option
   tag: "geolocation".  This option tag is set to "yes", and the SIP server
   determines this SIP request should be routed based on the Target's
   location, this parameter gives used, as defined in
   [RFC3261], in the server permission to look at Require, Supported and Unsupported header fields.

4.5 Location URIs in Message Bodies

   In the case where a location (or dereference it).  If this parameter is set recipient sends a 424 response and
   wishes to "no",
   then communicate suitable location by reference rather than by
   value, the SIP server 424 MUST NOT view the location message include a content-indirection body or
   dereference per RFC 4483.

4.6 Location URIs Allowed

   The following is part of the discussion started in Section 3, Figure
   2, which initiated the concept of sending location URI within this SIP request. indirectly.

   If the SIP
   server believes it cannot process this message properly because it
   needs to learn the Target's a location URI is included in order to route the message,
   then a SIP request, it MUST return be a 424 (Bad Location Information) response,
   indicating it requires permission (error code 402) to view SIP-,
   SIPS- or PRES-URI.  When PRES: is used, as defined in [RFC3856], if
   the
   location.

   Here resulting resolution resolves to a SIP: or SIPS: URI, this
   section applies.  These schemes MUST be implemented according to
   this document.

   absoluteURI is an not mandatory-to-implement, but allowed.

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

5.  Geolocation Example

5.1 Location-by-value (in Coordinate Format)

   This example of shows an INVITE message with a Geolocation-Error coordinate location.  In
   this example, the SIP request uses a 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>
     ;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">
         <dm:device id="target123-1">
          <gp:geopriv>
            <gp:location-info>
              <gml:location>
                <gml:Point srsName="urn:ogc:def:crs:EPSG::4326">
                  <gml:pos>32.86726 -97.16054</gml:pos>
                </gml:Point>
               </gml:location>
            </gp:location-info>
            <gp:usage-rules>
              <gp:retransmission-allowed>no</gp:retransmission-allowed>
              <gp:retention-expiry>2010-07-30T20:00:00Z</gp:retention-
                            expiry>
            </gp:usage-rules>
            <gp:method>802.11</gp:method>
           </gp:geopriv>
          <dm:deviceID>mac:1234567890ab</dm:deviceID>
          <dm:timestamp>2010-07-28T20:57:29Z</dm:timestamp>
         </dm:device>
        </tuple>
      </presence>
   --boundary1--

   The Geolocation header field

   Geolocation-Error: 402; code="Permission to Route based on
                            Location Information";
                            node="bob.example.com";
                            inserter="alice.example.com"; 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. An assumption can be
   made that SDP is the other message body part.  The above example says "cid:" eases
   message body parsing by disambiguating the MIME body that contains
   the Location Recipient is
   server42.example.com, and location information associated with this entity believes request.

   If the Geolocation header field did not contain a "cid:" scheme, for
   example, it cannot route could look like this
   message without knowing permission to view location URI:

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

   ... the Target's location.
   Regardless existence of whether there is a Geolocation header value parameter,
   such as

      routing-allowed=no

   or non-"cid:" scheme indicates this parameter is not present in the SIP request (as shown 402
   error example above). The default behavior is a
   location URI, to act as if be dereferenced to learn the
   parameter Target's location. Any
   node wanting to know where user "target123" is present and set would subscribe to "=no".  Server42 MUST get permission
   that user at server5 to view dereference the Target's location by reading a routing-allowed header
   parameter saying "=yes", otherwise sips-URI (see Figure 3 in
   section 3 for this message flow).

5.2 Two Locations Composed in Same Location Object Example

   This example shows the INVITE message after a 402 error is SIP intermediary
   rejected the original INVITE (say, the one in section 5.1). This
   INVITE contains the composed LO sent back to by the
   "inserter=" entity to get permission.

   Section 4.3 highlights this example, stating SIP intermediary which
   includes where the user, Alice, MUST
   be made aware intermediary understands Alice to be. The rules
   of RFC 5491 [RFC5491] are followed in this location revelation request. construction.

   This document
   does not give any guidance how Alice example is to be informed (i.e., audio,
   visual, etc).  Alice can grant permission or choose here, but should not to, knowing
   this SIP request attempt (to this destination, at be taken as occurring very
   often. In fact, this time) will
   fail.  The problem might not recur if a future SIP request were is believed to
   travel through be a different server than server42 (or it might again).

7. corner case of location
   conveyance applicability.

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

   --boundary1

   Content-Type: application/sdp

   ...SDP goes here

   --boundary1

 <?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:dm="urn:ietf:params:xml:ns:pidf:data-model"
        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">
       <dm:device id="target123-1">
         <gp:geopriv>
            <gp:location-info>
              <gml:location>
                <gml:Point srsName="urn:ogc:def:crs:EPSG::4326">
                  <gml:pos>32.86726 -97.16054</gml:pos>
                </gml:Point>
               </gml:location>
            </gp:location-info>
            <gp:usage-rules>
             <gp:retransmission-allowed>no</gp:retransmission-allowed>
             <gp:retention-expiry>2010-07-30T20:00:00Z</gp:retention-
                           expiry>
           </gp:usage-rules>
           <gp:method>802.11</gp:method>
          </gp:geopriv>
        <dm:deviceID>mac:1234567890ab</dm:deviceID>
        <dm:timestamp>2010-07-28T20:57:29Z</dm:timestamp>
       </dm:device>
       <dm:person id="target123">
         <gp:geopriv>
           <gp:location-info>
             <cl:civilAddress>
               <cl:country>US</cl:country>
               <cl:A1>Texas</cl:A1>
               <cl:A3>Colleyville</cl:A3>
               <cl:HNO>3913</cl:HNO>
               <cl:A6>Treemont</cl:A6>
               <cl:STS>Circle</cl:STS>
               <cl:PC>76034</cl:PC>
               <cl:NAM>Haley's Place</cl:NAM>
               <cl:FLR>1</cl:FLR>
             <cl:civilAddress>
           </gp:location-info>
           <gp:usage-rules>
             <gp:retransmission-allowed>no</gp:retransmission-allowed>
             <gp:retention-expiry>2010-07-30T20:00:00Z</gp:retention-
                           expiry>
              <gp:method>triangulation</gp:method>
           </gp:usage-rules>
          </geopriv>
       <dm:timestamp>2010-07-28T12:28:04Z</dm:timestamp>
       </dm:person>
      </tuple>
     </presence>

   --boundary1--

6.  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 be large.  Normal
   RFC 3261 procedures of reverting to TCP when the MTU size is
   exceeded would be invoked.

8.

7.  Security Considerations

   Conveyance of physical location of a UA raises privacy concerns,
   and depending on use, there probably will be authentication and
   integrity concerns.  This document calls for conveyance to
   be accomplished through secure mechanisms, like S/MIME protecting encrypting
   message bodies (although this is not widely deployed) or deployed), TLS
   protecting the overall signaling.  In cases where a session set-up
   is retargeted based on the location of the UA initiating the call signaling or SIP MESSAGE, securing conveyance location by-reference
   and requiring all entities that dereference location to authenticate
   themselves.  In location-based routing cases, encrypting the LbyV
   location payload 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. Data can only be encrypted to a
   particular, anticipated target, and thus if multiple recipients need
   to inspect a piece of data, and those recipients cannot be predicted
   by the sender of data, encryption is not a very feasible choice.
   Securing the location hop-by-hop, using TLS, protects the message
   from eavesdropping and modification, modification in transit, but exposes the
   information to all proxies on the path as well as the endpoint.  In
   most cases, the UA does not know the identity of has no trust relationship with the proxy or
   proxies providing location-based routing services, so that such
   end-to-middle solutions might not be appropriate either.

   These same issues exist for basic SIP signaling,

   When location information is conveyed by reference, however, one can
   properly authenticate and authorize each entity that wishes to
   inspect location information. This does not require that the sender
   of data anticipate who will receive data, and it does permit
   multiple entities to receive it securely, but SIP normally it does not carry however
   obviate the need for pre-association between the sender of data and
   any prospective recipients. Obviously, in some contexts this
   pre-association cannot be presumed; when it is not, effectively
   unauthenticated access to location information must be permitted. In
   this case, choosing pseudo-random URIs for location by-reference,
   coupled with path encryption like SIPS, can help to ensure that only
   entities on the SIP signaling path learn the URI, and thus restores
   rough parity with sending location by-value.

   Location information to physically track a user. This
   extension is especially sensitive.  That said, sensitive when the identity of
   its Target is obvious. Note that 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 a UA inserts location, the UA sets the policy on whether to
   reveal its location along the signaling path - as discussed in
   Section 4, as well as flags in the PIDF-LO [RFC4119].  UAC
   implementations MUST make such capabilities conditional on explicit
   user permission, and SHOULD alert the user that location is being
   conveyed.  Proxies inserting location for location-based routing are
   unable to alert users, and such use is NOT RECOMMENDED. Proxies
   conveying location using this extension MUST have the permission of
   the Target to do so.

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

   Because Target locations can be placed on a Location Server
   accessible with the possession of a location URI, this URI has its
   own security considerations.  It is tempting to assume that the
   dereference of this URI
   information would have authentication, authorization and
   other security mechanisms that limit the access to information.
   Unfortunately, this might not be true.  The access network the UA 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 UA has no way to
   provide a credential acceptable of correlate 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.

   Accordingly, possession of identity at the reference should be considered
   equivalent to possession SIP layer with that
   of the value, and location information referenced by SIP signaling.

   When a UA inserts location, the reference should be
   treated with UA sets the same degree of care policy on whether to
   reveal its location along the signaling path - as discussed in
   Section 4, as well as flags in the value.  Specifically,
   TLS PIDF-LO [RFC4119].  UAC
   implementations MUST be used to protect the security of make such capabilities conditional on explicit
   user permission, and MUST alert the reference.  Notice user that this specification does not constrain location is being
   conveyed.

   This SIP extension offers the dereference protocol default ability to use TLS. That specification require permission
   to view location while the SIP request is in transit.  The default
   for this is set to "no". There is left entirely an error explicitly describing
   how an intermediary asks for permission to view the dereferencing
   protocol documents. Target's
   location, plus a rule stating the user has to be made aware of this
   permission request.

   There is no end-to-end integrity on any locationValue or
   locationErrorValue header field parameter (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 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.

8.  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

8.1 IANA Registration for the SIP Geolocation Header Field

   The SIP Geolocation Header Field is created by this document, with
   its definition and rules in Section 4.1 of this document, and should
   be added to the 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

8.2 IANA Registration for New SIP 'geolocation' 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 registry.

9.3

8.3 IANA Registration for 424 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

8.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 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=                yes*        [this doc]

   * see section 9.5 for the newly created values.

9.5

8.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 in the IANA sip-parameters
   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.
   recipient.

  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 same data" The location   [this doc]
          cannot be processed at this time.  Error recipient
          should try again with same data.

  201  "Linkable Target Identity Required"  ---------
  100  "Cannot Process Location"                            [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

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

  400

  300  "Permission To Use Location Information " Information"             [this doc]
          Permission is being requested from the calling
          user to reveal and or use location in request
          before request can be processed. This error
          informs the "inserter=" entity that permission
          is required to process this SIP request. Ruleholder
          MUST be informed of permission request.

  401

  301  "Permission To Retransmit Location Information to a Third Party"
          Permission from the calling user to send location
                                                            [this doc]
          information to a third party entity - not in the
          signaling path. This flag is in the PIDF-LO. The
          user MUST be informed of permission request.

  402

  302  "Permission to Route based on Location Information"  [this doc]
          Permission from calling user to reveal location
          in request before request can be processed. This
          is a routing by location error. The user MUST be
          informed of permission request.

  500

  400  "Location Information Denial"  Request has been                        [this doc]
          Explicitly denied because of the location in
          the request.  Sender should not try again.

9.6

8.6  IANA Registration of Location URI Schemes

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

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

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

10. [RFC5226]).

9.  Acknowledgements

   To Dave Oran for helping to shape this idea.

   To Jon Peterson and Dean Willis on for 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, John Elwell and Jacqueline Lee for
   constructive feedback and nits checking.

   Special thanks to Paul Kyzivat for his help with the ABNF in this
   document and to Robert Sparks for many helpful comments and the
   proper construction of the Geolocation-Error header field.

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

11. References

11.1

10. References -

10.1 Normative References

 [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
           Requirement Levels", RFC 2119, March 1997

 [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, "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.

 [RFC2976] S. Donovan, "The SIP INFO Method", RFC 2976, Oct 2000

 [RFC3515] R. Sparks, "The Session Initiation Protocol (SIP) Refer
           Method", RFC 3515, April 2003

 [RFC3903] Niemi, 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

 [RFC5226] T. Narten, H. Alvestrand, "Guidelines for Writing an IANA
           Considerations Section in RFCs", RFC 5226, May 2008

 [RFC4479] J. Rosenberg, "A Data Model for Presence", RFC 4479, July
           2006

11.2 References - Informative

 [RFC3693] J. Cuellar, J. Morris, D. Mulligan,

 [RFC3264] J. Peterson. J. Polk,
           "Geopriv Requirements", Rosenberg, H. Schulzrinne, "The Offer/Answer Model with
           Session Description Protocol", RFC 3693, February 2004 3264, June 2002

 [RFC4483] E. Berger, "A Mechanism for Content Indirection in SIP", RFC
           4483, May 2006

 [RFC3825] J. Polk,

 [RFC5491] J. Schnizlein, Winterbottom, M. Linsner, "Dynamic Host
           Configuration Protocol Option for Coordinate-based Location
           Configuration Information", RFC 3825, July 2004

 [RFC4776] Thomson, H. Schulzrinne, " Dynamic Host Configuration Protocol
           (DHCPv4 Tschofenig, "GEOPRIV PIDF-LO
           Usage Clarification, Considerations, and DHCPv6) Option for Civic Addresses Configuration
           Information Recommendations ",
           RFC 4776, October 2006

 [ID-PHONE] B. Rosen, 5491, March 2009

10.2 Informative References

 [RFC3693] J. Cuellar, J. Morris, D. Mulligan, J. Peterson. J. Polk, "ECRIT Phone BCP",
           draft-ietf-ecrit-phonebcp, "work in progress", Jan 2010
           "Geopriv Requirements", RFC 3693, February 2004

 [ID-GEO-FILTERS] R. Mahy, B. Rosen, H. Tschofenig, "Filtering Location
           Notifications in SIP", draft-ietf-geopriv-loc-filters, "work
           in progress", December 2009

   Author Information March 2010

Authors' Addresses

   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
   Jon Peterson
   NeuStar, Inc.

   Email: jon.peterson@neustar.biz

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. If a
   requirement is not obvious in 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: 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: if a UAC has moved prior to the establishment of a
          dialog between UAs, the UAC must be able to send location
          information.  If location has been conveyed, and the UA
          moves, the UAC must be able to update the location previously
          conveyed to 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.

   Motivation:  interoperability with other IETF location protocols and
          Mechanisms.

   UAC-9  There must be a mechanism for the UAC to request the UAS send
          its 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
          happen because the UAC does not implement this extension, or
          because the UAC implements the extension, but does not know
          where the Target is.  This may be, for example, due to the
          failure of the access network to provide a location
          acquisition mechanism the UAC 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.

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 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
         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.