SIPSIPCORE Working Group James Polk Internet Draft Cisco Systems Expires:December 18,January 13, 2009 Brian Rosen Intended Status: Standards Track (PS) NeuStarJune 18,July 13, 2009 Location Conveyance for the Session Initiation Protocoldraft-ietf-sipcore-location-conveyance-00.txtdraft-ietf-sipcore-location-conveyance-01.txt Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire onDecember 18,January 13, 2009. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Legal This documents and the information contained therein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION THEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Abstract This document defines an extension to the Session Initiation Protocol (SIP) to convey geographic location information from one SIP entity to another SIP entity. The extension coversend to endend-to-end conveyance as well as location-based routing, where SIP servers make routing decisions based on the location of the user agentclients.client. Table of Contents 1. Conventions and Terminology used in this document . . . . . . 3 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . .34 3. Overview of SIP Location Conveyance . . . . . . . . . . . . . 4 4. SIP Modifications for Geolocation Conveyance . . . . . . . . 7 4.1 The Geolocation Header . . . . . . . . . . . . . . . . . 7 4.2 424 (Bad Location Information) Response Code . . . . . . 10 4.3 The Geolocation-Error Header . . . . . . . . . . . . . . 11 4.4 The 'geolocation' Option Tag . . . . . . . . . . . . . .1920 4.5 Using sip/sips/pres as a Dereference Scheme . . . . . . .1920 5. Geolocation Examples . . . . . . . . . . . . . . . . . . . .2122 5.1 Location-by-value (Coordinate Format) . . . . . . . . . .2122 5.2 Location-by-reference . . . . . . . . . . . . . . . . . .2324 6. SIP Element Behavior . . . . . . . . . . . . . . . . . . . .2324 6.1 UAC Behavior . . . . . . . . . . . . . . . . . . . . . .2425 6.2 UAS Behavior . . . . . . . . . . . . . . . . . . . . . .2729 6.3 Proxy Behavior . . . . . . . . . . . . . . . . . . . . .3234 7. Geopriv Privacy Considerations . . . . . . . . . . . . . . .3638 8. Security Considerations . . . . . . . . . . . . . . . . . . .3739 9. IANA Considerations . . . . . . . . . . . . . . . . . . . .3840 9.1 IANA Registration for New SIP Geolocation Header . . . .3841 9.2 IANA Registration for New SIP 'geolocation' Option Tag .3941 9.3 IANA Registration for New 424 Response Code . . . . . . .3941 9.4 IANA Registration for New SIP Geolocation-Error Header .3941 9.5 IANA Registration for New SIP Geolocation-Error Codes . .3942 9.6 IANA Registration of LbyR Schemes . . . . . . . . . . .4043 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . .4043 11. References . . . . . . . . . . . . . . . . . . . . . . . . .4143 11.1 Normative References . . . . . . . . . . . . . . . . .4143 11.2 Informative References . . . . . . . . . . . . . . . . .4245 Author Information . . . . . . . . . . . . . . . . . . . . .4245 Appendix A. Requirements for SIP Location Conveyance . . . .4345 1. Conventions and Terminology used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. The following terms and acronyms used throughout this document are defined here: LbyR = Location-by-Reference LbyV = Location-by-Value Location Generator (LG): The entity that initially determines or gathers the location of the Target and creates Location Objects describing the location of the Target [RFC3693]. LocationInformation Server (LIS) -Inserter: alogical serverrole created in this document describing the entity thatstores geolocation records of Targets, which correspond to LbyR URIs.included location in a SIP request, either by-value or by-reference (i.e., including a location URI). Location Object (LO): An object conveying location information (and possibly privacy rules) to which Geopriv security mechanisms and privacy rules are to be applied [RFC3693]. Location Recipient (LR): The entity that receives location information. It may have asked for this location explicitly (by sending a query to a location server), or it may receive this location asynchronously [RFC3693]. Location Server (LS): The entity to which a LG publishes location objects, the recipient of queries from location receivers, and the entity that applies rules designed by the rule maker [RFC3693]. A Location Server is also an entity that retains Target Location Objects that are dereferenced by Location Recipients via SIP SUB/NOT transactions. Target: A person or other entity whose location is communicated by a Geopriv Location Object [RFC3693]. Using Protocol: A protocol that carries a Location Object [RFC3693]. 2. Introduction This document describes howLocationgeolocation can be "conveyed" in a SIP request from one SIP entity unsolicited to another entity using SIP [RFC3261]. Here, "Location" is a description of the physical geographical area where something currently exists. Note that this information is not solicited by the entity that receives it. Thephrase "location conveyance" describes scenariosmechanism inwhich athis document does not allow one SIP useragent client (UAC) is informing a user agent server (UAS) or intermediate SIP server without being previously asked where the UAC is. Location Conveyance is different from a UAC, Alice, seekingto request the locationthe UAS, Bob. Location conveyance, using SIP, never asks forof anotherentity's locationSIP user to be returned in a response.Asking for someone else's location is not discussed in this document.Geographic location in the IETF is discussed in RFC 3693 (Geopriv Requirements) [RFC3693]. It defines a "Target" as the entity whose location is being transmitted over IP. A[RFC3693] defined[RFC3693]-defined "Using Protocol" describes how a "Location Server" transmits a "Location Object" to a "Location Recipient" while maintaining the contained privacy intentions of the Target intact. This document describesthea SIP extension toSIP forcarry a Location Object and how it complies with the Using Protocolrequirements, where the location server is a UA or Proxy Server and the Location Recipient is another UA or Proxy Server.requirements in RFC 3693. Common terms are in Section 1. Section 3 provides an overview of SIP location conveyance. Section 4 details themodificationsextensions to SIP necessary to accomplish location conveyance. Section 5 gives decode examples of geolocation within SIP requests, both LbyV and LbyR. Section 6 articulates the SIP element type behaviors for location conveyance. Section 7 discusses Geopriv privacy considerations. Section 8 discusses security considerations. Section 9 IANA registers the modifications made to SIP by this documentfromin section 4. 3. Overview of SIP Location Conveyance The concept of conveying location in SIP is fairly straightforward. Location is conveyed directly or indirectly from a transmitting SIP entity to a receiving SIP entity.IfWhen location is conveyed directly,thenit is conveyed as a value contained within the SIP request,seeas in Figure1.,1. Alice Bob LIS | | | | Request w/ Location | | |------------------------>| | | | | | Response | | |<------------------------| | | | | Figure 1. Location Conveyed by ValueIfWhen location is conveyed indirectly, analogous to Content Indirection [RFC4483],this is a case whereBob receives (from Alice)an LbyRa location URIthat requiresand must make an additionaltransactionrequest - here called a dereference - to learn Alice'slocation by requesting thatactual location from aLIS, seeLocation Server (LS) identified in the location URI, as in Figure2.,2. Alice BobLISLS | | | | Request w/ Location URI | | |------------------------>| | | |FetchDereference Request | | |---------------------->| | | | | |FetchDereference Response | | |<----------------------| | Response | (includes location) | |<------------------------| | | | | Figure 2. Location Conveyed by Reference Many protocols can be used for thisfetchdereference transaction, but this is usuallyboundeddetermined by the scheme of the location URI in the SIP request. In otherworks,words, if the location URI is a SIPS: URI, then SIPS would be used to contact theLISLS to make the dereference. The location "value" in this SIP extension is in the form of aPresence"Presence Information Data Format - LocationObject,Object", or PIDF-LO, as described in [RFC4119]. A PIDF-LO is an XML scheme specifically for carrying the geographic location of a Target. LbyV refers to a UA including a PIDF-LO as a message body part of a SIP request, sending that Location Object to another SIP element. LbyR refers to a UA including a location URI in a SIP request header field which can be dereferenced by a Location Recipient toreceiveretrieve Alice's Location Object, in the form of a PIDF-LO.Dereferencing is done by a Location Recipient.To accomplish location conveyance in SIP, a new SIPheader,header field, Geolocation, is created and described in this document. The Geolocation header field contains a URI that points tothewhere the location is forthatthe location target, either in the body of the SIP request itself (LbyV), or onan external servera Location Server (LbyR). A location URI that points to a message body is always a "cid:" URI (Content Identification), as defined in [RFC2392]. If the URI in the Geolocation header field is a scheme other than "cid:", afetchdereference transaction (see Figure 2) is necessary. This document describes how a SIP presence subscription [RFC3856] can be used as a dereference protocol.Including locationLocation can be inserted in a SIP requestis not limited to insertionby aUA. There are times where aSIP serverwants to insert location of a location target intoas well as by arequest from that target towards the request's destination.UA. This document offers guidance on this practice. This document also describes how a location recipient can determine which entity includedwhata specific location, asit is allowed formore than one locationtocan 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,callcalled the Geolocation-Errorheader.header field. This header field has various codes that provide additional information about the type of location error experienced by a LocationRecipient.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 tellby host-idwhich entity (identified by host-id) insertedwhicha specific location is extremely important. Not only does this allow each location error to be targeted at a particular inserter ofparticular location,a specific location object, but it also allows error recipients to understand whentheir insertedthe location they inserted was not at fault, andwhenthat 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 inthisthe 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 amessage'srequest's path. It ispossible, and it fact, planned in certain circumstancespossible tohaveroute SIP requestsroutedbased on the location of thetarget.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 alocation inserter - the act of including location into this request,Location Inserter, then the Location Inserter can also include a separate indicationis givenin the Geolocation headeritfield showing that this usage isallowed. There is no mechanism by whichnot desired. Location Inserters have theveracity of theseability to provide instructional parameterscan be verified. Theyabout 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 todestination.destination(s). This document creates a new option tag: geolocation, to indicate support for this extension by UAs. The newheaders,header field, the header parameters, the new option tag, the new error response, and Geolocation-Errorcodes, whichcodes are defined in Section4.,4, each of which are IANA registered by this document. RFC 3693 demands that a transmitted locationmustbe 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 Geolocationheader.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 followingaresections detail the standards track modifications to SIP for Location Conveyance. 4.1 The Geolocation Header Field This document definesand IANA registersGeolocation as a new SIPheader: Geolocation,header field registered by IANA, with the following ABNF [RFC5234]: Geolocation = "Geolocation" HCOLON (locationValue *(COMMA locationValue)) (COMMA retrans-param) locationValue = LAQUOT locationURI RAQUOT *(SEMI geoloc-param) locationURI = sip-URI / sips-URI / pres-URI / cid-url ; (from RFC 2392) / absoluteURI ; (from RFC 3261) geoloc-param = "inserted-by" EQUAL geoloc-inserter / "used-for-routing" / generic-param ; (from RFC 3261) geoloc-inserter = DQUOTE hostport DQUOTE / gen-value ; (from RFC 3261) retrans-param = "routing-allowed" EQUAL "yes" / "no" sip-URI, sips-URI and absoluteURI are defined according toRFC 3261.[RFC3261]. The pres-URI is defined inRFC 3859[RFC3859]. The cid-url is defined in [RFC2392] to locate message body parts. This URI typeMUST beis present in a SIP requestifwhere location istransmitted LbyV only.conveyed as a value. Other protocols used in theLocationlocation URI MUST be reviewed against the RFC 3693 criteria for a Using Protocol. The Geolocation header field MAY have one or more locationValues. SIP servers inserting a locationValue MUST add the new value as the last locationValue in the Geolocation header field (i.e., the last locationValue in the header field is the most recent one added to the message). Placement of the "routing-allowed" parameter, when present, MUST be the last header field value in the Geolocationheader.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 Viaheader,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 notidentifyingidentify 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 theheader,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 whichlocationURIlocation 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 Geolocationheader.header field. The "routing-allowed" header field parameter is a global parameter over any (and all/each) locationValues in the Geolocationheader.header field. This is the reason why the placement of the header field parameter is outside any locationValue,andappears only once, and is always last in the header field value. This header field parameter only has the values "=yes" or"=no" only."=no". When this parameter is "=yes", any locationValue can be used for routing decisions along the downstream signaling path by intermediaries. When this parameter is "=no", this means no locationValue (inserted by the originating UAC or any (or subsequent) intermediary(ies) along the signaling path) can be used by any SIP intermediary to make routing decisions. This behavior MUST be adhered to. Section 4.3 describes the details on what a routing intermediary does if it believes it needs to use the location in the SIP request in order to process the message further. The practical implication is that when the "routing-allowed" parameter is set to "no", if an LbyV is present in the SIP request, intermediariesSHOULDMUST NOT view the location (because it is not for intermediaries to view), and if an LbyR is present,SHOULDMUST NOT dereference it. UASs are allowed to view location in the SIP request even when the "routing-allowed" header field parameter is set to "no". The default behavior when this header field parameter is not present in a message is to treat the SIP request as if the parameter were present and its value is set to "no". This document defines the Geolocation header field as valid in the following SIP requests: INVITE [RFC3261], REGISTER [RFC3261], OPTIONS [RFC3261], BYE [RFC3261], UPDATE [RFC3311], INFO [RFC2976], MESSAGE [RFC3428], REFER [RFC3515], SUBSCRIBE [RFC3265], NOTIFY [RFC3265], PUBLISH [RFC3903] and PRACK [RFC3262] Discussing location using the PUBLISH request is out of scope for this document since it is part of Presence, therefore, for completeness, Table 1 shows PUBLISH is to support Location Conveyance via this extension, but is not discussed further. The following table extends the values inTable 2&3Tables 2 and 3 of RFC 3261 [RFC3261]. Header field where proxy INV ACK CAN BYE REG OPT PRA ---------------------------------------------------------------- Geolocation R ar o - - o o o o Header field where proxy SUB NOT UPD MSG REF INF PUB ---------------------------------------------------------------- Geolocation R ar o o o o o o o Table 1: Summary of the Geolocation Header Field The Geolocation header field MAY be included in any one of the above requests by a UAC. A proxy MAY add the Geolocationheader,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 anLbyRlocation URI, in its own locationValue header field value. A SIP proxy MAY add a Geolocation header field if one is not present, and MAY add the "routing-allowed" parameter if not yet present in the SIP request. When a "routing-allowed" parameter is already present in the SIP request, a SIP server MUST NOT change the value of the parameter (i.e., from 'yes' to 'no', or from 'no' to 'yes'). This would override the policy set by an upstream SIP entity (i.e., likely the UAC). Adding a new locationValue to an in-transit request is NOT RECOMMENDEDto occurfor at least two reasons, #1-SIP Servers are not the best locators geographically of where a UAC is;meaningthe location informationisthat a SIP server knows may notnecessarily the greatest. There MAY be exceptions, but this SHOULDbe therule of thumb.best location information available. #2- without appropriate caution to the fact that Location Recipients might not understand how to process more than one location, giventhisdocument'sdocument gives limited guidance as to what a Location Recipient should do when receiving more than one location(i.e., currently no priority(no instructions are givenforabout which locationValue to useif there arewhen more thanone). A Location Recipient can easily be confused by too much location information, producingone is present), so adding a new locationValue may lead to undesirable results.The <dm:device id> element [RFC5491] in the PIDF-LO XML indicates whose location is contained in the PIDF-LO.Location Recipients receiving a location object, whether received directly or as the result of a dereference, MUST honor the usage element rules within that XML document, as defined in [RFC4119]. Such entities MUST NOT alter the rule set. 4.2 424 (Bad Location Information) Response Code This SIP extension creates a newLocationlocation specific response code, defined as follows. 424 (Bad Location Information) The 424 (Bad Location Information) response code is a rejection of therequest,request due to its location contents, indicating the location information was malformed or not satisfactory for the recipient's purpose, or could not be dereferenced. Section 4.3 creates the Geolocation-Error header field to provide more detail about what was wrong with the location information in the request. This header field MUST be in the 424 response, containing a locationErrorValue for each invalid locationValue in the request (i.e., and one-for-one matching if all locationValues in the request were bad). If more than one location is present in a request (LbyV or LbyR), andany of the locationValues is good forthe Location Recipientto process,can process any of the locationValues, a 424 MUST NOT be sent. The 424 is only appropriate when the Location Recipient needs a locationValue and there are no locationValues included in a SIP request that are usable by a recipient. A 424 (Bad Location Information) response is a final response within a transaction, and does not terminatea usage or aan existing dialog. The UAC can use whatever means it knows of to verify/refresh its location information before attempting a new request that includes location. There is no cross-transaction awareness expected by either the UAS or any SIP intermediary as a result of this error message. The new 424 (Bad Location Information) error code isIANAregistered with IANA in Section 8 of this document. An initial set oflocation error of IANA registeredIANA-registered Geolocation-Error codes are in Section 4.3 of this document. 4.3 The Geolocation-Error Header Field As discussed in Section 4.2, more granular error notifications, specific to location errors within a received request, are required if the UAC is to know what was wrong within the original request. The Geolocation-Error header field iscreated hereused for this purpose. The Geolocation-Error header field is used to conveylocation specificlocation-specific errors within a response.Additions to this IANA registered header requireAdditional IANA-registered values must be defined in an RFCbe published.(this is the "RFC Required" IANA policy defined in [RFC5226]). The Geolocation-Error header field has the following ABNF [RFC5234]: Geolocation-Error = "Geolocation-Error" HCOLON locationErrorValue *(COMMA locationErrorValue) locationErrorValue = location-error-code *(SEMI location-error-params) location-error-code = 1*3DIGIT location-error-params = location-error-node-id / location-error-host-id / location-error-code-text / generic-param ; from RFC3261 location-error-node-id = "node" EQUAL DQOUTE hostport DQOUTE ; from RFC3261 location-error-host-id = "inserter" EQUAL DQOUTE hostport DQOUTE ; from RFC3261 location-error-code-text = "code" EQUAL quoted-string ; from RFC3261 The Geolocation-Error header field MUST contain at least one locationErrorValue to indicate what was wrong with theoriginallocationValue in the correspondingrequest. If arequest the Location Recipientexperienced more than one error a particular locationValue of the corresponding SIP request, there can be one locationErrorValue per problem with the locationValue in the request.determined was bad. Each locationErrorValue containsonea 3-digit error code indicating what was wrong with the location in the request. Each error type has a corresponding quoted error text string that is human understandable.If there was something wrong with more than one locationValue in a request, a corresponding locationErrorValue would be sent, one per error, in the response.Each locationErrorValue contains the Location Recipient identifier (the "node=" parameter) which experienced the location error, as well as an identifier of which SIP entity (the "inserter=" parameter) the Location Recipient is told (in the locationValue) added this problematic locationValue to the request. The "node=" and "inserter=" are the domain identifier of a SIP entity, with the ability to have the same host communicate on different ports - and have port specific identification. This is the sameas isinformation 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 locationErrorValueparametersparameters, node="bob.example.com" inserter="alice.example.com" Both the "node=" and "inserter=" parameters MUST be present in all locationErrorValues in a response, unless the"inserted-by=" parameter was not in thelocationValue ofathe request did not include the "inserted-by=" parameter (which is a violation of this document). The "inserter=" parameter value is copied from the "inserted-by=" parameter within the locationValue of the request.No manipulation or calculation is necessary to accomplish this. Here's why thisThis isnecessary,required because a Location Recipient that experiencedthe locationa 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 errorheader,header field, were it to remain generic to all entities in the response path.So,This requirement means that the headerhas to identifyfield identifies the Location Inserter whoit is for,inserted the problematic locationValue, so that all other SIP entities that read the header field know to ignoreit, since it is not for them.it. This is of particular use if the original UAC did not include a locationValue in the original SIP request, but a SIP server along the path did insert a locationValue. The locationErrorValue wouldtravel tobe interpreted by each SIP entity along the original path upstream andtellbe processed by both the server that included the invalid locationValuewhat was wrong with the locationand the UACwhothat didnot know what the error meant. This will causenot, resulting in confusionif left without this indication.at the UAC. A worse case is when both the original UAC and a SIP server along the path included a locationValue, but there wasonlysomething wrong with only one of the locationValues. Withoutthisan identification ofwhichthe specific locationValuewasin error, both entities wouldreactreact, and one woulddo soreact incorrectly.MoreWhen more than one locationErrorValue is present in a Geolocation-Error headerisfield, they are separated bya comma.commas. If more than one locationErrorValue is present in a response, and intended for the same "inserter=", each error code MUST be unique to this "inserter=" entity, and the error codesSHOULDMUST NOT conflict in meaning.In other words, two error codes (within separate locationErrorValues of the same response) SHOULD NOT give misleading or inconsistent indications to the location "inserter=".Here is an example of a Geolocation-Error header field: Geolocation-Error: 200; code="Retry Location Later"; node="bob.example.com"; inserter="alice.example.com"; The following table extends the values in Table 2&3 of RFC 3261 [RFC3261]. Header field where proxy INV ACK CAN BYE REG OPT PRA ---------------------------------------------------------------- Geolocation-Error r ar o - - o o o o Header field where proxy SUB NOT UPD MSG REF INF PUB ---------------------------------------------------------------- Geolocation-Error r ar o o o o o o o Table 2: Summary of the Geolocation-Error Header Field The Geolocation-Error header field MAY be included in any response to one of the above SIP requests, so long as Geolocation was in the request part of the transaction. For example, Alice includes her location in an INVITE to Bob. Bob can accept this INVITE, thus creating a dialog, even though his UA determined the location contained in the INVITE was bad. There is a Geolocation-Error header value in the 200 OK to the INVITE informing Alice the INVITE was accepted but the location provided was bad. Thechoice of whichSIP requestsareincluded in table 2 abovecome from which Methods canare the ones allowed to optionallyhavecontain the Geolocation header field (see section 4.1). That said, a UAC MUST ignore a Geolocation-Error header field valueif itthat did notinclude a Geolocation header value in the request part of the transaction.contain its host-id.. Here is an example of a transaction that has a location error. In this case, Bob responds with a 424 (Bad Location Information) response, including a Geolocation-Errorheader,header field, is in Figure 3. Alice Bob | | | Request w/ Location | |------------------------------------------------>| | | | | | 424 (Bad Location Information) | | with Geolocation-Error containing | | 200 ("Retry LocationLater" (withLater with samedata))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,eachbased onreceiver (ofhow theresponse) actionable reactionsresponse receiver should react to these errors. o1001XX "Cannot Process Location" o2002XX "Retry LocationLater" (withLater with samedata)data" o3003XX "Retry LocationLater" (with deviceLater with updatedlocation)device location" o4004XX "PermissionNecessary"To Reveal Location Information to a Third Party" o5005XX "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 X00categories - just increasecategories, although the future error code may provide more granularmeaning.information. If another action is expected to occur with a newly defined error code, it MUST outside the 100-599 range.100 unit ranges are OPTIONAL for future error codes, but they apply here.4.3.1 Location Error: 100 "Cannot Process Location" The location error 100 "Cannot Process Location" indicates to a Geolocation-Error recipient thatwhat theythe locationValue supplied in arequest, as far as location is concerned,request cannot be processed at this time. This only has to do with the location that the location "inserter=" added to the request, and not about the overall request that was sent. Action(s) to be taken by Geolocation-Error receivertofor 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 reactin a wayas ifthisthe "inserter=" entity received a 2XX or 3XX location error.A 4XX errorImplementations MUST NOTbe misunderstood here,react as if the "inserter=" entity received a 4XX location error, as that error category involves human intervention to grant, or not, permission to reveal "inserter=" location when this is likely not desired. The text string of "Cannot Process Location" is RECOMMENDED, but not mandatory for usage in this error. Implementations MAY use another text string. An exampleof this100 location erroris here:is: Geolocation-Error: 100; code="Cannot Process Location"; node="bob.example.com"; inserter="alice.example.com"; This category covers all 1XX locationerrors 1XX.errors. The same basicactionablereaction is expectedbywhen a location "inserter=" entitytoreceives any 1XX location error. 4.3.2 Location Error: 200 "Retry LocationLater" (same data)Later same data" The location error 200 "Retry LocationLater" (same data)Later same data" indicates to a Geolocation-Error recipient that what they supplied in a request, as far as location is concerned, cannot be processed at this time, but there is no need toretry this request, without changingupdate the locationinformation,at a later time-in a new SIP request.ItFor example, this location error ispossible thatappropriate when the Location Recipient cannot process location atthisa specific time, or when there is there was a timeoutduring dereferencing, if an LbyR were sent.when a location URI is dereferenced. Action(s) to be taken by Geolocation-Error receivertofor a 2XX: Reactions to a 2XX location error are to tryagain, without having to updateagain after some period of time has elapsed. The "inserter=" has not identified problems with the locationsupplied originally. Thereprovided in the original request, so there is noconstraints on how long this new try hasneed towait,update this location unlessthere is athe requestor moves. A Retry-After header field MUST be present inathe 424response.response indicating after how long the LR thinks it can process the location, the error recipient MUST obey this instruction. Implementations SHOULD choose to react bypreparing, however this "inserter=" does or can, to queuequeuing another message with the same location information,providedunless the "inserter="does not move between the time of the original request and the transmission time of the new request.entity knows it has changed locations. Implementations MAYchoose whether or not toinform the user of this error. The text string of "Retry LocationLater"Later same data" is RECOMMENDED, but not mandatory forusage inthis error. Implementations MAY use another text string to inform the user that location was not received by the UAS (i.e., the called party). An exampleof this200 location erroris here:is: Geolocation-Error: 200; code="Retry LocationLater";Later same data"; node="bob.example.com"; inserter="alice.example.com"; This category covers all 2XX locationerrors 2XX.errors. The same basicactionablereaction is expectedbywhen a location "inserter=" entitytoreceives any 2XX location error. If a SIP request has the "routing-allowed" header field parameter set to "no", and the SIP server believes processing locationwithin the requestis 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.34.3.2.1 Location Error:300 "Retry Location Later" (device updated location)201 "Linkable Target Identity Required" Thelocationerror300 "Retry Location Later" (device updated location) indicates to a Geolocation-Error recipient that what they supplied in a request, as far as locationcode 201 "Linkable Target Identity Required" isconcerned, cannot be processed at this time, but to retry this request, oncespecifically for thelocation information has been updated,event in which anewSIPrequest. Action(s)request requires a binding of the Target's identity tobe taken by Geolocation-Error receiverthe presence document in order toa 3XX: 3XX location errors indicateknow this is the"inserter=" SIP entity needsTarget's location torefresh its location, ormakethean appropriate routing decision. Because Alice could include Bob's locationinformation supplied more complete, without notifyingin her SIP request, theuser ofSIP server - in thiserror. 3XX error arespecific case - needs tobe solved by without user intervention. This document gives no guidance howunderstand this message isaccomplished, given the number of ways a UAC can learn itsrouted based on Alice's location,or aand not Bob's. There is no absolute binding between presence documents and SIPintermediary can Sightsignaling, hence aUAC, as defined in [RFC3693]. This 300 locationseparate errorcurrently does not indicate what exactly was wrongwith specific behaviors are necessary. It is of particular importance is thelocation supplied, accordingemergency 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 theLocation Recipient. That"entity=" attribute. This isleftproblematic fora future effort. Implementations MAY choose whether or notsome (all?) source location based call routing situations. The node= routing intermediary makes this locationErrorValue a 201 toinform the user ofresolve thiserror. The text stringproblem. In the 424 response, the Retry-After header value of"Retry Location Later"'0' isRECOMMENDED,REQUIRED, indicating the new request be sent immediately, butnot mandatory for usagewith a target identification resolved inthis error. Implementation MAY use another text string to informtheuser that location was not received byPIDF-LO and SIP request. In presence, theUAS (i.e.,entity= attribute is typically thecalled party). A 3XX location error would be used whereURI of theLocation Recipient cannot find or cannot parsepresentity, meaning something like thelocation supplied, believing that a automated refresh and retry could fixContact address of theproblem. Also,UAC here. If there is no Retry-After header value, the default is to resend the SIP request immediately with the corrected entity= attribute (i.e., emulating a3XX location error wouldRetry-After: 0 header value). Action(s) to beused whentaken by Geolocation-Error receiver for aLocation Recipient did not find any201: 201 locationin a SIP request, but was expecting it. Perhaps an emergency request was made thaterror indicate the "inserter=" did notcontain location. The retry in this case would be inproperly identify theform of an UPDATE Method request, containing location (LbyV or LbyR). An exampleTarget of thislocation error is here: Geolocation-Error: 300; code="Retry Location Later"; node="bob.example.com"; inserter="alice.example.com"; This category covers location errors 3XX.presence document. Thesame basic actionable reactionRetry-After has been received - or isexpected by a location "inserter=" entityassumed toany 3XX location error. 4.3.4be 0 - meaning the new SIP request is to be sent immediately. 4.3.3 Location Error:400 "Permission Necessary" The location error 400 "Permission Necessary"300 "Retry Location Later with device updated location" The location error 300 "Retry Location Later with device updated location" indicates to a Geolocation-Error recipient thatwhenwhat theysentsupplied in aparticular SIPrequest,they includedas far as locationin thatis concerned, cannot be processed. In order to retry this requestwithout giving permissioninthe request fora(or any)new SIPserver to look at thatrequest, the location information(i.e., the <retransmission-allowed> was set to "no" in the PIDF-LO for B2BUAs, or "routing-allowed=no" as a Geolocation header parameter for proxy servers) to route the message at the intended recipient (i.e., the UAS, or the called party).must be updated. Action(s) to be taken by Geolocation-Error receivertofor a4XX: 4XX3XX: 3XX location errors indicateto the UAC (i.e.,thecalling party) that they need to grant permission to a"inserter=" SIPintermediary serverentity needs tolook atrefresh its location, or make thesuppliedlocationto completeinformation supplied more complete, without notifying themessage routing. This indication MUST require humanuserintervention, as the rulemakerofthe policy on whether or not their location is tothis error. 3XX errors may berevealed. Theresolved without userofintervention. This document gives no guidance how this is accomplished, given thelocation "inserter=" devicenumber of ways a UAC canchoose to grant permission to thislearn its location, or a SIP intermediaryserver to allow this request to be routed, or the usercandeny thisSight a UAC, as defined in [RFC3693]. This 300 locationrevelation (request byerror currently does not indicate what exactly was wrong with theserver). It islocation supplied, according to theuser's choice as rulemaker.Location Recipient. That is left for a future effort. ImplementationsMUST provideMAY choose whether or not to inform theuser, as rulemaker, a clear indication that permission to consume their location is sought by an entity other than who thatuseris calling.of this error. The text string of"Permission Necessary""Retry Location Later with device updated location" is RECOMMENDED, but not mandatory for usage in this error. Implementation MAY use another text string to inform the user that locationis being soughtwas not received byan intermediarythe UAS (i.e.,notthe called party).This document gives no guidance how this intervention is accomplished, givenA 3XX location error would be used where thenumber of ways a UAC can accomplish this (i.e., audio prompt or toggleLocation Recipient cannot find orkeystroke on their UA). This 400cannot parse the locationerror currently does not indicate exactlysupplied. 3XX location errors should cause a requestor to retry with refreshed location information, whichSIP server indicates it needsmight be sufficient to fix the problem. Also, a 3XX locationrevealed. That said, the "node=" FQDN address coulderror would besupplied, telling the user (via audio or video indication) whichused when a Location Recipient was expecting to find location in a SIPentity wants thisrequest, but did not find it - perhaps an emergency request was made that did not contain location.Perhaps the user can knowThe retry insome circumstances whetherthisis an appropriate "node=" (domain). Allcase would be in the form ofthis is left foran UPDATE Method request, containing location. If the 424 response contains afuture effort(s).Retry-After value, there SHOULD NOT be a long delay associated with a new request - under the guise that if the location had been good, there would not have been an error to this request. An exampleof this300 location erroris here:is: Geolocation-Error:400; code="Permission Necessary";300; code="Retry Location Later with device updated location"; node="bob.example.com"; inserter="alice.example.com"; This category covers all 3XX locationerrors 4XX.errors. The sameactionable solutionbasic reaction is expectedto be afforded to the UAC user, as rulemaker, towhen a location "inserter=" entity receives any4XX3XX location error.4.3.54.3.4 Location Error:500 "Location400 "Permission to Reveal Location InformationDenial"to a Third Party" The location error500 "Location400 "Permission to Reveal Location InformationDenial"to a Third Party" indicates to a Geolocation-Error recipient thatwhattheysupplied insent arequest, as far as location is concerned, has been denied at this time. This only has to do with theparticular SIP Request including location in thatthe location "inserter=" added to therequest,and not aboutwithout giving permission in theoverallrequest for an intermediary SIP entity to look at that location information (i.e., the <retransmission-allowed> wassent. If this were appliedset to "no" in theSIP request itself, this would equate toPIDF-LO for B2BUAs, or "routing-allowed=no" as a6XX Global error.Geolocation header field parameter for proxy servers) to route the request toward the intended recipient (i.e., the UAS, or the called party). Action(s) to be taken by Geolocation-Error receivertofor a1XX: This error gives no guidance on what to do next, other than to not try again with this same4XX: 4XX locationsupplied. Iferrors indicate to theLocation Recipient believedUAC (i.e., the calling party) thatmerely refreshing, or in some other way alter or augmentthey need to grant permission to a SIP intermediary server to look at thelocationsuppliedwould work in a new request, then a 3XXlocationerror SHOULD have been returned (toto complete the"inserter="). An example of why this 5XX could have been returned is if location were sentmessage routing. This indication MUST require human user intervention, acting asan LbyR, and the LIS deniedthedereference request fromruleholder of theLocation (reference) Recipient, this is the expectedpolicy on whether or not locationerror returnedis to be revealed. The user of the location "inserter="entity. Implementations MUST NOT interpret anything else intodevice can choose to grant permission to thislocation error other than it is considered a location based denial error. This does not mean theSIP intermediary server to allow this requestwas denied,to be routed, oreven had an error, unlesstheresponse was a 424. Otherwise, this only has to do withuser can deny permission. It is thelocation part ofuser's choice as ruleholder. Implementations MUST provide therequest. The difference between a 1XX anduser, as ruleholder, a5XXclear indication that permission to consume their locationerrorissimple. A 1XX location errorsought by an entity that isa case of a Location Recipient either not knowing ornotbeing able to tellthe"inserter="entitywhat was wrong with the location supplied in a SIP request. Whereas, a 5XX location error is where the location was purposely, and actively denied (or declined) from being received by the Location Recipient entity, or its user. This could occur in a UAS or SIP server. If implementations choose to informthat theUACuserof this error, theis calling. The text string of"Location"Permission To Reveal Location InformationDenial"to a Third Party" is RECOMMENDED, but not mandatory for usage in this error. Implementations MAY use another textstring. 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 coversstring to inform the user that locationerrors 5XX. The same basic actionable reactionisexpectedbeing sought by an intermediary (i.e., not the called party). This document gives no guidance how the UAC can seek permission from the user, given the number of ways alocation "inserter=" entity to any 5XX location error. 4.3.6 Which Scenario Matches Which Error Code? The following are some additional failure scenarios, with which error code SHOULD be used for consistency, - Scheme (sip:, or sips:, or pres:, or another one) of the LbyR URI isn't supported (100) - Format (geo or civic) isn't supported (100) - Cannot parse location (100) - Can't find LIS (no accessUAC can accomplish this (i.e., audio prompt orno path (100)toggle ordenied access(500)) - Dereference failed (timeout) (200) - Insufficientkeystroke on a UA). This 400 locationinfo supplied (300) - Cannot finderror indicates exactly which SIP server indicates that it needs the locationin message (300) 4.4 The 'geolocation' Option Tag This document creates and IANA registers one new option tag: "geolocation". This option tag is to be used, as defined in RFC 3261, inby theRequire, Supported and Unsupported headers. Whenever a UA"node=" FQDN address supplied, perhaps telling the user (via audio or video indication) which SIP entity wantsto indicate support forthisSIP extension,location. Perhaps thegeolocation option tag is includeduser can know ina Supported header of the SIP request. 4.5 Using sip/sips/pres as a Dereference Scheme Ifsome circumstances whether this is anLbyR URIappropriate "node=" (domain). This latter feature isincludednot described in this document. An example 400 location error is: Geolocation-Error: 400; code="Permission to Reveal Location Information to aSIP request, it MUST be a SIP-, SIPS- or PRES-URI. When PRES:Third Party"; node="bob.example.com"; inserter="alice.example.com"; This category covers all 4XX location errors. The same resolution isused, ifexpected to be afforded to theresulting resolution,UAC user, asdefined in [RFC3856], resolves to a SIP: or SIPS: URI, this section applies. This document IANA registers 3 mandatory to implement URI schemes for LbyR: o SIP: o SIPS: o PRES: These 3 are IANA registered in Section 9.6. These schemes MUST be implemented according to this document. absoluteURI is not mandatoryruleholder, toimplement. Dereferencing a Target'sany 4XX locationusing SIP- or SIPS-URI is accomplished by treating the URI as a PRES-URI and generating a SUBSCRIBE request to a presence server as defined in [RFC3856] using the 'presence' event package. The resulting NOTIFY will contain the PIDF, rather MUST contain a PIDF-LO. See Figure 4. for a basic message flow for a dereference.error. 4.3.5 Location Error: 500 "Location Information Denial" TheNOTIFY contains Alice's PIDF-LO in Figure 4. When used in this manner, SIP is a Using Protocol as defined in [RFC3693] and elements receivinglocationMUST honor the 'usage-element' rules as defined in this extension. Alice Location Server Bob | | | INVITE w/ LbyR URI | |-------------------------------------------------------->| | | | | 200 (OK) | |<--------------------------------------------------------| | | | | | SUBSCRIBEerror 500 "Location Information Denial" indicates toLbyR URI | | |<-----------------------------| | | 200 (OK) | | |----------------------------->| | | | | | NOTIFY w/ PIDF-LO | | |----------------------------->| | | 200 (OK) | | |<-----------------------------| | | | Figure 4. Location-by-Reference and Dereferencing In Figure 4., Alice sends Bob her location in an LbyR URI. Bob receives this LbyR URIa Geolocation-Error recipient that what they supplied inthe INVITE and generatesanew transaction (SUBSCRIBE) to retrieve the PIDF-LO of Alice. If accepted, the PIDF-LO will be in the NOTIFY request from the Location Server back to Bob's UA. This is the first instance between Alice and Bob that Alice's location is in any message, therefore it is sent only once, from the Location Server to Bob. The SUBSCRIBE contains a geolocation option tag in either the Supported or Require header (depending on what strength of support the UAC wants to apply). The NOTIFY MUST match the subscribing UAC's option-tag strength for geolocation. A dereference of an LbyR URI using SUBSCRIBE is not violating a PIDF-LO 'retransmission-allowed' element value set to 'no', as the NOTIFY is the only message in this multi-message set of transactions that contains the Target's location, with the location recipient being the only SIP element to receive this PIDF-LO. This is the purpose of this extension to SIP - to convey location to a specific destination. 5. Geolocation Examples This section contains are two examples of messages providing location. One shows LbyV with coordinates, the other shows LbyR. The example for (Coordinate format) is taken from [RFC3825]. A civic format example of the same position on the earthrequest, as far as location isin the coordinate format example is in appendix B, which is taken from [RFC4776]. The differences between the two formats are within the <gp:location-info> of the examples. Other than this portion of each PIDF-LO, the rest is the same for both location formats. The key to the provided samples is in the Geolocation header, which has a different type of URI, based on the different means of location conveyance. Section 5.1 shows a "cid:" URI, indicating this SIP request contains an LbyV message body - which is in the form of a PIDF-LO. Section 5.2 shows an LbyR URI indicating location is to be acquired via an indirection dereference mechanism, which is determined by the scheme of URI supplied. 5.1 Location-by-value (Coordinate Format) This example shows an INVITE message with a coordinate, or coordinate location. In this example, the SIP request uses a sips-URI [RFC3261], meaning this message is TLS protected on a hop-by-hop basis. INVITE sips:bob@biloxi.example.com SIP/2.0 Via: SIPS/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bK74bf9 Max-Forwards: 70 To: Bob <sips:bob@biloxi.example.com> From: Alice <sips:alice@atlanta.example.com>;tag=9fxced76sl Call-ID: 3848276298220188511@atlanta.example.com Geolocation: <cid:target123@atlanta.example.com> ;inserted-by="alice@atlanta.example.com" Supported: geolocation Accept: application/sdp, application/pidf+xml CSeq: 31862 INVITE Contact: <sips:alice@atlanta.example.com> Content-Type: multipart/mixed; boundary=boundary1 Content-Length: ... --boundary1 Content-Type: application/sdp ...SDP goes here --boundary1 Content-Type: application/pidf+xml Content-ID: <target123@atlanta.example.com> <?xml version="1.0" encoding="UTF-8"?> <presence xmlns="urn:ietf:params:xml:ns:pidf" xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10" xmlns:cl="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr" xmlns:gml="http://www.opengis.net/gml" entity="pres:alice@atlanta.example.com"> <dm:device id="target123"> <timestamp>2007-12-02T14:00:00Z</timestamp> <status> <gp:geopriv> <gp:location-info> <gml:location> <gml:Point srsName="urn:ogc:def:crs:EPSG::4326"> <gml:pos>33.001111 -96.68142</gml:pos> </gml:Point> </gml:location> </gp:location-info> <gp:usage-rules> <gp:retransmission-allowed>no</gp:retransmission-allowed> <gp:retention-expiry>2007-12-07T18:00:00Z</gp:retention- expiry> </gp:usage-rules> <gp:method>DHCP</gp:method> <gp:provided-by>www.example.com</gp:provided-by> </gp:geopriv> </status> </dm:device> </presence> --boundary1-- The Geolocation header field from the above INVITE... Geolocation: <cid:target123@atlanta.example.com> ...indicates the content-ID location [RFC2392] within the multipart message body of where location information is, with SDP being the other message body part. The "cid:" eases parsing of message bodies. If the Geolocation header field were this instead: Geolocation: <sips:server5.atlanta.example.com/target123> ...the presence of something other than "cid:" indicates an LbyR is included inconcerned, has been denied at thismessage. It is expected that any node wantingtime. This only has toknow where user "target123" is would subscribedo with the location that the location "inserter=" added toserver5the request, and not about the overall request that was sent. If this were applied todereferencethesips-URI (see Figure 4 forSIP request itself, thismessage flow, and Section 5.2would 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 thisdecoded example). The returning NOTIFY would contain Alice'ssame location supplied. If the Location Recipient determined that merely refreshing, or in some other way alter or augment the location supplied would work in aPIDF-LO, asnew request, then a 3XX location error would have been more appropriate. An example of why this 5XX could have been returned is ifitlocation wereincluded insent as amessage body (part) oflocation URI, and theoriginal INVITE here. 5.2 Location-by-reference Below is an INVITELS denied the dereference requestwith an LbyR URI instead of an LbyV PIDF-LO message body part shown in Section 5.1. Itfrom the potential Location Recipient, this isup tothe expected locationrecipienterror returned to the "inserter=" entity. In all likelihood, this is a dereferenceAlice'sfunction error, meaning this will not occur when locationatis carried by-value in theAtlanta LIS server containingrequest. Implementations MUST NOT make any assumptions about the implications of this locationrecord. Dereferencing, if done with SIP, is accomplished by the Location Recipient sendingerror other than recognizing that aSUBSCRIBE request to the URI reference for Alice's location. The received NOTIFY islocation based denial error has occurred. This does not mean thefirstSIP requestcontaining Alice's UA location, aswas denied, or even had an error, unless the response was aPIDF-LO message body (see Figure 4 for424. Otherwise, thismessage flow example).only has to do with the location part of the request. TheNOTIFY, in this case,difference between a 1XX and a 5XX location error isthe SIP request thatsimple. A 1XX location error isconveying location, andappropriate when a Location Recipient either does not know or cannot tell the "inserter=" entity what was wrong with theINVITE. There is no retransmission oflocation supplied inthis usage. INVITE sips:bob@biloxi.example.com SIP/2.0 Via: SIP/2.0/TLS pc33.atlanta.example.com ;branch=z9hG4bK74bf9 Max-Forwards: 70 To: Bob <sips:bob@biloxi.example.com> From: Alice <sips:alice@atlanta.example.com>;tag=9fxced76sl Call-ID: 3848276298220188511@atlanta.example.com Geolocation: <sips:3sdefrhy2jj7@lis.atlanta.example.com> ;inserted-by="bigbox3.atlanta.example.com" Supported: geolocation Accept: application/sdp, application/pidf+xml CSeq: 31862 INVITE Contact: <sips:alice@pc33.atlanta.example.com> (...SDP goes here as the only message body)a SIP request. A 5XX location error is appropriate when the Location Recipientwould need to dereference the sips-URI in the Geolocation header field to retrieve Alice's location. Ifwas purposely and actively prevented from retrieving theatlanta.example.com domain chooses to implementlocationconveyance and deliveryinformation. This could occur inthis fashion (i.e., LbyR), it is RECOMMENDED that entities outside this domain be ablea UAS or SIP server. If implementations choose toreachinform thedereference server, otherwiseUAC user of thismodelerror, the text string ofimplementation"Location Information Denial" isonly viable within the atlanta.example.com domain. 6. SIP Element Behavior Because a device'sRECOMMENDED, but not mandatory for usage in this error. Implementations MAY use another text string. An example of this location error isgenerally considered to be sensitive in nature,here: Geolocation-Error: 500; code="Location Information Denial"; node="bob.example.com"; inserter="alice.example.com"; This category covers 5XX locationinformation needs to be protectederrors. The same basic reaction is expected whentransmitted. This can be addressed through securing thea locationinformation to prevent either viewing"inserter=" entity receives any 5XX location error. 4.3.6 Which Scenario Matches Which Error Code? The following scenario/error code mapping MUST be used for consistency, - Scheme (sip:, orchanging the PIDF-LO. Section 26sips:, or pres:, etc.) of[RFC3261] definesthesecurity functionality SIPS by transporting SIP messages with either TLSlocation URI isn't supported - (100) - Format (geo orIPSec protection between SIP entities. If a SIP entity wants to prevent all SIP entitiescivic) isn't supported - (100) - Found where location should be, but do not understand what is there -(300) - Cannot find LS ina request path from viewinglocation URI (no access orjust changing the contents of the PIDF-LO, save those that possess decryption key, the message body needsno 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 besecure by a means suchused, asS/MIME. This would be the casedefined in [RFC3261], inwhich a UAC wants to make sure only the destination UAS can readthePIDF-LO. 6.1 UAC Behavior A UAC can send locationRequire, Supported and Unsupported header fields. 4.5 Using sip/sips/pres as a Dereference Scheme If an LbyR URI is included in a SIP request,either becauseit MUST be a SIP-, SIPS- or PRES-URI. When PRES: isexpected to facilitate location-based routing ofused, if therequest, or spontaneously (i.e., for a purpose notresulting resolution, as defined in [RFC3856], resolves to a SIP: or SIPS: URI, this section applies. This documentbut known to the UAC). Alice communicating her location to BobIANA registers 3 mandatory-to-implement URI schemes for LbyR: o SIP: o SIPS: o PRES: These 3 are registered with IANA ina SIP requestSection 9.6. These schemes MUST be implemented according to this document. absoluteURI is not mandatory-to-implement. Dereferencing asimple example of this. If Alice wanted to include herTarget's location using SIP- or SIPS-URI is accomplished by treating the URI as amessage body in an INVITE that also has an SDP message body, the Content-Type: Multipart MUST be supported by both UAC and UAS. Multipart comes in many forms (/mixed, /alternative, etc),PRES-URI andthis document does not limit which type of multipart is used, though future documents MAY specify or limit multipartgenerating a SUBSCRIBE request to asubset of allpresence server as defined in [RFC3856] using thechoices for a given use. A UAC conveying location'presence' event package. The resulting NOTIFY MUSTincludecontain alocationValue inPIDF-LO. See Figure 4 for aGeolocation header (see section 4.1) with either an LbyV indication (a cid-URL), or an LbyR. An LbyVbasic messagebody sent withoutflow for aGeolocation header field MUST NOT occur.dereference. TheUAC supportingNOTIFY contains Alice's PIDF-LO in Figure 4. When used in thisextensionmanner, SIP is a Using Protocol as defined in [RFC3693] and elements receiving location MUSTinclude a Supported header withhonor the'geolocation' option tag. More than one location format (civic and coordinate) can be included'usage-element' rules as defined inthe same message body part, but allthis specification. Alice Location Server Bob | | | INVITE w/ Location URI | |-------------------------------------------------------->| | | | | 200 (OK) | |<--------------------------------------------------------| | | | | | SUBSCRIBE to locationparts of the sameURI | | |<-----------------------------| | | 200 (OK) | | |----------------------------->| | | | | | NOTIFY w/ PIDF-LOMUST point at the same position on the earth, identifying the same target. The same| | |----------------------------->| | | 200 (OK) | | |<-----------------------------| | | | Figure 4. Location-by-Reference and Dereferencing In Figure 4, Alice sends Bob her location inmultiple formats, for example,apartial or complete geodeticlocation URI. Bob receives this location URI in the INVITE and generates apartial or complete civic, can allow the recipientnew transaction (SUBSCRIBE) touse the most convenient or preferable format for its use. Multiple PIDF-LOs are allowed inretrieve Alice's PIDF-LO. If accepted, thesame request, with each allowed to point at separate positions - however, eachPIDF-LOMUST identify a different Target. Therefore, therewill beno confusion by a Location Recipient receiving more than one PIDF-LO (in a message body or when dereferenced, or a combination). It is RECOMMENDED there is only one locationValuereturned ina single SIPthe NOTIFY requestforfrom thesame Target. More than one will likely lead to confusion by aLocationRecipient because this extension does not provide guidance on what a recipientServer to Bob's UA. This isto do with more than one location, nor does it give any preference regarding whichthe first instance between Alice and Bob that Alice's location isbetter or worse than another locationin any message, therefore it is sent only once, from thesame request.Location Server to Bob. The'geolocation'SUBSCRIBE contains a geolocation option tagis insertedinaeither the Supported or Require headerby a UAC to provide an indicationfield (depending on what strength of supportfor this extension.the UAC requires). Thepresence ofNOTIFY MUST match the'geolocation' option tag in a Supported header withoutsubscribing UAC's option-tag strength for geolocation. A dereference of an LbyR URI using SUBSCRIBE is not violating aGeolocation header field inPIDF-LO 'retransmission-allowed' element value set to 'no', as thesameNOTIFY is the only messageinforms ain this multi-message set of transactions that contains the Target's location, with the location recipient being the only SIP elementreceivingto receive thisrequest thatPIDF-LO. This is theUAC understandspurpose of thisextension, but it does not know or wishextension to SIP - to conveyitslocationat this time. Certain scenarios exist (location-based retargeting)to a specific destination. 5. Geolocation Examples This section contains are two examples of messages providing location. One shows LbyV with coordinates, the other shows dereferencable location URI. The example for (Coordinate format) is taken from [RFC3825]. A Civic-format example of the same position on the earth as is in the coordinate format example is in appendix B, which is taken from [RFC4776]. The differences between the two formats appear within the <gp:location-info> in the examples. Other than this portion of each PIDF-LO, the rest is the same for both location formats. The key to the provided samples isrequiredin 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 inorderthe form of a PIDF-LO. Section 5.2 shows an LbyR URI indicating location is toretargetbe acquired via an indirection dereference mechanism, which is determined by themessage properly.scheme of URI supplied. 5.1 Location-by-value (Coordinate Format) Thisaffects howexample shows an INVITE message with aUAS orcoordinate location. In this example, the SIPserver processes suchrequest uses arequest.sips-URI [RFC3261], meaning this message is protected using TLS on a hop-by-hop basis. INVITE sips:bob@biloxi.example.com SIP/2.0 Via: SIPS/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bK74bf9 Max-Forwards: 70 To: Bob <sips:bob@biloxi.example.com> From: Alice <sips:alice@atlanta.example.com>;tag=9fxced76sl Call-ID: 3848276298220188511@atlanta.example.com Geolocation: <cid:target123@atlanta.example.com> ;inserted-by="alice@atlanta.example.com" ;routing-allowed=no Supported: geolocation Accept: application/sdp, application/pidf+xml CSeq: 31862 INVITE Contact: <sips:alice@atlanta.example.com> Content-Type: multipart/mixed; boundary=boundary1 Content-Length: ... --boundary1 Content-Type: application/sdp ...SDP goes here --boundary1 Content-Type: application/pidf+xml Content-ID: <target123@atlanta.example.com> <?xml version="1.0" encoding="UTF-8"?> <presence xmlns="urn:ietf:params:xml:ns:pidf" xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10" xmlns:cl="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr" xmlns:gml="http://www.opengis.net/gml" entity="pres:alice@atlanta.example.com"> <tuple id="target123"> <status> <timestamp>2009-07-13T09:00:00Z</timestamp> <gp:geopriv> <gp:location-info> <gml:location> <gml:Point srsName="urn:ogc:def:crs:EPSG::4326"> <gml:pos>33.001111 -96.68142</gml:pos> </gml:Point> </gml:location> </gp:location-info> <gp:usage-rules> <gp:retransmission-allowed>no</gp:retransmission-allowed> <gp:retention-expiry>2009-07-29T18:00:00Z</gp:retention- expiry> </gp:usage-rules> <gp:method>802.11</gp:method> a </gp:geopriv> </status> </tuple> </presence> --boundary1-- The'geolocation' option tag SHOULD NOT be used inGeolocation header field from theProxy-Require Header, becauseabove INVITE: Geolocation: <cid:target123@atlanta.example.com> ... indicates theUAC often will not knowcontent-ID location [RFC2392] within theunderlying topology to know which proxy will domultipart message body of where location information is, with SDP being theretargeting, thus increasingother 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> ... thelikelihoodexistence of arequest failure by the first hop proxy that does not understandnon-"cid:" scheme indicates thisextension, butisrequireda location URI, toby inclusion ofbe dereferenced to learn theoption tag in this header. A UAC inserting a locationValue MUST include an "inserted-by=" parametertarget's location. Any node wanting toindicate its hostport. Thisknow where user "target123" iscopiedwould subscribe to server5 to dereference the"inserter=" parameter of the Geolocation-Error headersips-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 aresponsePIDF-LO, as ifa Location Recipient determines there is something wrong with the locationValueit were included inthis request. Because more than one locationValue can be inserted along the patha message body (part) of therequest, this indicationoriginal INVITE. 5.2 Location-by-reference Below isnecessary to show which locationValue had the probleman 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 theresponse, and whoAtlanta Location Server thelocationErrorValue is for. For example: Geolocation: <cid:alice123@atlanta.example.com>; inserted-by="alice@atlanta.example.com" If a UAC does not learn and store itslocationlocally (a GPS chip) or fromURI is pointing towards. Dereferencing, if done using SIP, is accomplished by thenetwork (DHCP or LLDP-MED),Location Recipient sending a SUBSCRIBE request to theUAC MAY learn its LbyRURI(from DHCPreference 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).IfThe NOTIFY, in this case, and not thelatterINVITE, is thecase,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 theUAC can SUBSCRIBEonly message body) A Location Recipient would need tothis LbyR URI, usingdereference the'presence' event package,sips-URI in the Geolocation header field toget and store its ownretrieve Alice's location.The act of dereferencing a Target's LbyR will be challenged byIf theLIS where thisatlanta.example.com domain chooses to implement locationrecordconveyance and delivery in this fashion, it is- providing a good deal of protection, SHOULD stillRECOMMENDED that entities outside this domain betreated as equivalentable topossession ofreach the dereference server, unless locationinformation itself and thus TLS SHOULD be used when transmitting LbyR hop-by-hop along the path tois intentionally restricted within theLocation Recipient, for protection reasons. Thisatlanta.example.com domain. 6. SIP Element Behavior Because a device's location isnotgenerally considered to beconfused with a possession model,sensitive inwhich possessing the LbyR grants authorization to dereference the URI. Any entity dereferencing the LbyR MUST pass whatever authentication and authorization rules are on the LIS for thisnature, locationrecord. The Ruleholder from [RFC3693] is still very much in control - for any entity possessing the LbyR. Ifinformation needs to be protected when transmitted. This can be addressed through securing theLocation Generator wishes to control whether anylocationincluded in the SIP requestinformation to prevent either viewing oradded alongchanging thesignaling pathPIDF-LO. Section 26 ofthis request can be viewed for routing decisions,[RFC3261] defines theLocation Generator addsSIPS security functionality by transporting SIP messages with either TLS protection between SIP entities. If aGeolocation header value includingSIP entity wants to prevent all SIP entities in a request path that do not possess a decryption key from viewing or changing the"routing-allowed=no" parameter. This header parameter provides specific policy rules for each locationValue (if there is more than one inserted alongcontents of thesignaling path) withinPIDF-LO, theSIP request.message body needs to be secure by a means such as S/MIME. 6.1 UAC Behavior A UACSHOULD include the "routing-allowed" header parameter, with or without a locationValue,might choose toeachsend location in a SIP requestsupporting this specificationtoensure the UAC's policy for intermediaries which might add a locationValuefacilitate location-based routing of theTarget downstream. The UAC understands that the default behaviorrequest, or for some other purpose. Alice communicating her location to Bob in a SIPserversrequest is a simple example of this. If Alice wanted toconsider this value to be present, andinclude her location as a message body in an INVITE thatit is set to "no". The UACalso has an SDP message body, the Content-Type: Multipart MUSTunderstand therebe supported by both UAC and UAS. Multipart comes in many forms (/mixed, /alternative, etc), and this document does not limit which type of multipart isno feedback mechanismused, though future documents might specify or limit multipart toinforma subset of all theTarget ifchoices for aSIP server has includedgiven use. A UAC conveying location MUST include a locationValuedownstream. Ifin 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 UAChas already conveyedsupporting this extension MUST include a Supported header with the 'geolocation' option tag. More than one location format (civic and coordinate) can be included in theoriginal requestsame 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, atransaction,partial or complete geodetic andwantsa partial or complete civic, allows the recipient toupdateselect the most preferred format for its use. Additional complementary location information(for whatever reason) after the original request is sent, or after a dialog is created (regardless of howcan be in theUAC conveyed location previously,second format asan LbyV or LbyR) - this is done by a UAC sending an UPDATE request [RFC3311] containingwell. Multiple PIDF-LOs are allowed in thegeolocation option tag and Geolocation headersame request, withthe new locationValue (LbyV or LbyR)each allowed to point at separate positions - however, each PIDF-LO MUST identify a different Target (i.e., in theoriginal destination UAS. A PIDF includes identity information. It is possible forentity= attribute in theidentity<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 inthe PIDFa single SIP request. More than one will likely lead tobe anonymous. Implementations ofconfusion by a Location Recipient because this extensionSHOULD consider the appropriateness of including an anonymous identity in the location information wheredoes not provide guidance on what areal identityrecipient isnot required. When using LbyR,to do with more than one location for theLbyR MUST NOT containsame target (which could point to different positions), nor does it give anyuser identifying information. For example, use something unidentifiable like 3fg5t5yqw@example.atlanta.com rather than aliceishere@example.atlanta.com). Use of self-signed certificatespreference regarding which location isinappropriate for usemore or less reliable than another location inprotecting a PIDF, asthesender does not have a secure identitysame request. The presence of therecipient. Mentioned in more detail in later'geolocation' option tag insection 6.2, SIP MUST NOT attempt to overcome rules and behaviors conveyeda Supported header field without a Geolocation header field in the same message informs aPIDF-LO. Therefore, UACs SHOULD take care when setting their <retransmission-allowed> flag to "yes", as when Alice tells Bob her location withSIP element receiving thisflag set to "yes", as long asrequest that the<retention-expiry> time isUAC understands this extension, but it does notindicating the location information needsknow or wish tobe deleted - Bobconvey its location at this time. Certain scenarios exist (location-based retargeting) in which location isfreerequired in a SIP request in order totell Carol where Alice is. This is an implicit byproduct of howretarget thePIDF-LO rule-set is, as of this writing. This ismessage properly. Indicating support with aconfiguration issue, but something worth mentioning here. 6.1.1 UAC Receivinggeolocation option tag affects how aLocation Failure Indication Location Recipients can be either,UAS orboth, destination UASs and intermediate serversSIP server processes such a request. For example, it ought to understand thatuseerroring thelocation information for location-based routing decisions. If a sentrequestfails based on thebecause there was no locationinformationin therequest, a 424 (Bad Location Information) responserequest issent backlikely not going to result in theUAC.location appearing in the subsequent request. The424 MUST have a Geolocation-Error header containing one or more locationErrorValues'geolocation' option tag SHOULD NOT be used in theresponse message. A locationErrorValue has aProxy-Require headerparameter indicating which entity insertedfield, because often thelocationValue correlatedUAC will not know the underlying topology tothis error, calledknow which proxy will do the"inserter=" parameter. This "inserter=" parameter (inretargeting, thus increasing thelocationErrorValue)likelihood of a request failure at the first hop proxy that does not understand this extension, as iscopied fromrequired by inclusion of the option tag in this header field. A UAC inserting a locationValue MUST include an "inserted-by=" parameter(fromto indicate its hostport. This is copied to thelocationValue) by"inserter=" parameter of the Geolocation-Error header field in a response if a Location Recipient(UAS or proxy) sendingdetermines there is something wrong with theerror response. A UAC receiving a Geolocation-ErrorlocationValue inany response type MUST reviewthis request. Because more than one locationValue can be inserted along the path of the request, this indication is necessary to show which locationValue had the"inserter=" parameterproblem in thelocationErrorValue to see if it indicates this UAC. If locationErrorValue does not match,response, and who the locationErrorValueMUST be ignored. If a locationErrorValueisinfor. For example: Geolocation: <cid:alice123@atlanta.example.com>; inserted-by="alice@atlanta.example.com" If a424,UAC does not learn and store its location locally (a GPS chip) or from the"inserter=" entity is not this UAC,network (DHCP or LLDP-MED), theresponse SHOULD be treated as a 400 response. If locationErrorValue does indicate this UAC, thisUACMUST processMAY learn its location URI (from DHCP for example). If theresponse, includinglatter is the case, theGeolocation-Error code (defined in section 4.3). Further,UACMUST ignore a Geolocation-Error header value, even forcan SUBSCRIBE to thisUAC, even in a 424 response iflocation URI, using theUAC did not include'presence' event package, to get and store its own location. The Location Server will likely challenge requests to dereference aGeolocation header value (with locationValue) in the request partTarget's location URI. The location URI SHOULD be treated as equivalent to possession of thetransaction. A UAC MAY reattempt a new request if it believes it can correct the stated failure inlocation information itself and thus TLS SHOULD be used when transmitting any location URI hop-by-hop along theGeolocation-Error header, unlesspath to thelocation errorLocation Recipient, for protection reasons. This isa 5XX level error - which clearly states in Section 4.3not todo this. A UAC MUST follow allbe confused with a 'possession model', in which possessing theguidance that pertains to UACs from Section 4.3 (Geolocation-Error header), heeding whatlocation URI grants authorization todo in case it receives any ofdereference theerror codes articulated in that section.URI. AnyUAC that insertedentity dereferencing the locationinto a request SHOULD be prepared to receiveURI MUST pass whatever authentication and authorization rules are on theGeolocation-Error header in any response, lookingLS todetermine if a locationErrorValueacquire this location. The Ruleholder from [RFC3693] ismeantstill very much in control - for any entity possessing theUAC, and to react accordingly.LbyR. Ifa UAC includes location in a request, and eithertheUAS does not determine errored location was criticalLocation Generator wishes to control whether any location included in thetransaction and accept the request,SIP request or added along the signaling path of this requestfailedcan be viewed forreason other than location, any response MAY containrouting decisions, the Location Generator adds aGeolocation-ErrorGeolocation headercontaining a locationErrorValue with the details of the location error. 6.2 UAS Behavior Iffield value including theGeolocation"routing-allowed=no" parameter. This header field parameter provides specific policy rules for each locationValue (if more than one locationValue ispresent in a received SIP request,inserted along thetype of URI contained insignaling path) within thelocationValue will indicate if location is an LbyV in a message body (part) or LbyR, requiring an additional dereference transaction. IfSIP request. A UAC SHOULD include theLbyR URI is sip:, sips:"routing-allowed" header field parameter, with orpres:, and the UAS wantswithout a locationValue, tolearneach SIP request supporting this specification to ensure the UAC'slocation,policy for intermediaries which might add a locationValue of theUAS MUST initiateTarget downstream. The default behavior for SIP servers is to consider this value to be present, with aSUBSCRIBE to the URI providedvalue of "no". There is no feedback mechanism toretrieve the PIDF-LO being conveyed byinform theUAC as defined in [RFC3856].Target if a SIP server has included a locationValue downstream. Ifsuccessful, the PIDF-LO will be returneda UAC has already conveyed location in theNOTIFYoriginal requestfrom the remote host. The UAS is not REQUIREDof a transaction, and wants todereferenceupdate its location information (for whatever reason) after theLbyR if it does not want to (by configurationoriginal request is sent, oruser choice). Itafter a dialog isRECOMMENDED the UAS render the location sent to it, however itcreated, this isconfigured to do so. A Requiredone by sending an UPDATE request [RFC3311]. The UPDATE will include a geolocation option tag and Geolocation header field with the'geolocation' option tag indicatesnew locationValue to theUAC is requiringoriginal destination UAS. A presence document includes identity information (in theUAS understand"entity=" attribute of the <presence> element), although the identity could be an unlinkable pseudonym [RFC3693]. Implementations of this extensionor else send an error response. A 420 (Bad Extension) with a 'geolocation' option tag inSHOULD consider the appropriateness of including anUnsupported header would beunlinkable pseudonym as theappropriate responseidentity inthis case. It is possible, but undesirable, forthe location information where amessagereal identity is not required. See the concerns raised in section 4.3.2 about unlinkable pseudonyms in relation toarrive with a body containing an LbyV, buttheir potential problems withno Geolocation header field value pointingrequests that need toit (potentially no Geolocation header field at all). In this case,route based on therecipient MAY still read and uselocation contained in the message. When using LbyR, themessage body. Unless stated otherwise by future standards-track publication(s), a LbyRlocation URIonly has meaning within the Geolocation header field andMUST NOTappear incontain anyother SIP header field. There are 3 Geolocation header parameters, o "inserted-by=" o "used-for-routing" o "routing-allowed" The "inserted-by=" parameter informs a Location Recipient which SIP element added this locationValue to the SIP request. This parameteruser identifying information. For example, use something unidentifiable like 3fg5T5yqWowhGLn54wg4NgHlkDsFn@example.atlanta.com rather than aliceishere@example.atlanta.com). Use of self-signed certificates ismandatoryinappropriate foreach locationValueuse in protecting a PIDF, as therequest. The value insender does not have a secure identity of the"inserted-by=" parameterrecipient. Although this iscopied into the "inserter=" parameterdiscussed ineach locationErrorValue if there is an errormore detail inthelater 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 tobe reported back"yes", Bob is free to tell Carol where Alice is (as long as the <retention-expiry> time has not elapsed, indicating that the locationsender. See section 6.2.1. The "used-for-routing" parameterinformation should be deleted). This isincluded inan implicit byproduct of thelocationValue ifPIDF-LO rule-set, as of this writing. This decision is aSIP server usedconfiguration issue, but is worth mentioning here. 6.1.1 UAC Receiving a Location Failure Indication Location Recipients that use the locationin the request to determine how to routeinformation for location-based routing decisions can be either destination UASs orforward the message towards the ultimate destination. If there are more than one locationValuesintermediate servers. If a request fails based on the location information in theGeolocation header, and itrequest, a 424 (Bad Location Information) response ispossible that different locationValues were usedsent back toroute the message at different times of this request's journey. This is allowed, as it is consistent withtherule that anytime a message is routed based uponUAC. The 424 MUST have alocationValue,Geolocation-Error header field containing one or more locationErrorValues in the response message. A locationErrorValue has a"used-for-routing"header field parameteris addedindicating which entity inserted the locationValue correlated to this error, called theapplicable locationValue."inserter=" parameter. This "inserter=" parametershould be present in each locationValue used along(in thepath.locationErrorValue) is copied from the "inserted-by=" parameter (from the locationValue) by the Location Recipient (UAS or proxy) sending the error response. A"used-for-routing"UAC receiving a Geolocation-Error in any response type MUST check whether the "inserter=" parameter in the locationErrorValue indicates this UAC. o If locationErrorValue does not match, the locationErrorValue MUSTNOT everberemoved from a locationValue inignored. o If arequest. The "routing-allowed" parameterlocationErrorValue isexclusively for SIP servers, and will be discussedinsection 6.3. Additional locationValues inserted intoarequest SHOULD be placed the order they were generated,424, and the "inserter=" entity is notrearranged. This informs a Location Recipient which wasthis UAC, thelast locationValue inresponse SHOULD be treated as a 400 response. o If locationErrorValue does indicate this UAC, this UAC MUST process themessage that was used to routeresponse, including themessage. This is for troubleshooting and management reasons. Individual header parametersGeolocation-Error code (defined inany received locationValue MUST NOT be modified or deletedsection 4.3), taking the action described intransit tothat section for theultimate destination. A UASreceived error code. Additionally, the UAC MUSTNOT send locationignore a Geolocation-Error header field value, even for this UAC, even in a 424 responsemessage, as there can be any number of issues/problems with receiving location, andif the UACor proxy servers cannot errordid not include aresponse. Therefore,Geolocation header field value (with locationValue) in theUAS,request part of the transaction. A UAC MAY reattempt a new request if itwants to sendcan 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 UACits location, SHOULDMUST follow all the guidance that pertains to UACs from Section 4.3 (Geolocation-Error Header Field), heeding what to dosowhen it receives any of the error codes articulated in that section. Any UAC that inserted location into anewrequest MUST be prepared to receive the Geolocation-Error header field ina separate transaction. This document gives no guidance which SIP requestany response, looking touse, but SIP MESSAGE isdetermine if aviable choice. A UAS MAY includelocationErrorValue is meant for the UAC, and to react accordingly. If a'geolocation' option tagUAC includes location inthe Supported header ofaresponse, indicating itrequest, and either the UAS doesunderstand this extension, even ifnot determine errored location wasnot in a requestcritical to theUAS. Atransaction 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 UASwishing to dereference an LbyR URI containedBehavior If the Geolocation header field is present in a receivedrequest will useSIP request, the'presence' event packagetype of URI contained ina SUBSCRIBE request to the URI. If accepted,thePIDF-LOlocationValue willreturn to the UASindicate if location is in aNOTIFY request. If there are any errors during dereferencing,message body (part) orinrequires an additional dereference transaction. If thePIDF-LO itself,location URI is sip:, sips: or pres:, and the UASwill error the original requestwants to learn theUAC with a locationErrorValue indicating whatUAC's location, the UASconcluded was wrong with the location. This isMUST SUBSCRIBE toinclude any dereferencing problems encountered. Section 4.5 of this document called fortheIANA registration of 3provided URIschemes (sip:, sips:, and pres:) that are mandatory to implement for dereferencing. A UAS MUST be preparedtoreceive subsequent location updates fromretrieve theUAC, either LbyV or LbyR (regardless of howPIDF-LO being conveyed by theUAS received location previously from this UAC). TheUAC as defined in [RFC3856]. If successful, the Target's PIDF-LO willconvey location usingbe returned in theUPDATE [RFC3311] method toNOTIFY request from theUAS, and not a reINVITE. If thereremote host. The UAS ismore than one location (any combination of LbyV and LbyR), this document doesnotgive guidance what a Location Recipient does with each location. There are no priority or more-trusted indications given by this document. All this is considered application specific, and out-of-scope of this document. This document makes it clear that if when there are more than one location, each inREQUIRED to dereference the location URI if location is not needed to process thesame PIDF-LO MUST be aboutrequest. It is RECOMMENDED thesame Target (identifier) and point atUAS display thesame position onlocation to theearth. If there is more than one PIDF-LOuser, or otherwise render the location appropriately. A Require header field withdifferent Target identifiers, thenthe 'geolocation' option tag indicates the UACis merely tellingrequires that the UASwhere more than one Target is, and there should not be any conflict. Within any PIDF-LO, there isunderstand this extension, sending an error response if it does not. A 420 (Bad Extension) with a<retransmission-allowed> element that can'geolocation' option tag in an Unsupported header field would beset to "yes" or "no". These aretheonly possibilities. If Alice conveys her location to Bob (as has been described throughoutappropriate response in thisdocument)case. It is possible, but undesirable, for a message to arrive with a<retransmission-allowed> element setbody containing an LbyV, but with no Geolocation header field value pointing to"no", then Bobit (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 NOTinformappear in any otherelement where Alice is. IfSIP header field. There are 3 Geolocation header field parameters, o "inserted-by=" o "used-for-routing" o "routing-allowed" The "inserted-by=" parameter informs a Location Recipient which SIP entity added this locationValue to the SIP request. This parameter is mandatory for each locationValue in the request. The value in the "inserted-by=" parameter is copied into the<retransmission-allowed> element"inserter=" parameter in each locationErrorValue if there issetan error in the location to be reported back to"yes", then Bob can inform other elements where Alice is, but only untilthe<retention-expiry> element, alsolocation sender. See section 6.2.1. The "used-for-routing" parameter is included in thePIDF-LO, allows Bob to [RFC4119]. As a byproduct of this, that means thatlocationValue ifAlice conveys hera SIP server used the location in the request toBob with a <retransmission-allowed> element setdetermine how to"yes", androute or forward the<retention-expiry> timemessage towards the ultimate destination. If there are more than one locationValues in the Geolocation header field, it isnot requiring Bobpossible that different locationValues were used todelete Alice's location yet, then Bobroute the message at different points along the path traversed by the request. This isfree to tell anyone else where Alice is. Whenever Bob conveys Alice's location, <retention-expiry> timer MUST be maintainedallowed, as it is(i.e., not changed). The <dm:device id> element identifiesconsistent with the rule thatAlicewhenever a message isthe target of this location. RFC 4119 implicitly allows this behavior, thus SIProuted based upon a locationValue, a "used-for-routing" parameter isnot goingadded tochange this behaviorthe applicable locationValue. This parameter MUST be present in each locationValue used along the path. A "used-for-routing" parameter MUST NOT be removed fromoccurring. 6.2.1 UAS Generating a Location Failure Indication IfaUAS receives locationlocationValue in arequest, but determines thererequest. 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 aproblem withLocation Recipient which was thelocationlast locationValue in therequest, it is the responsibility of the UAS to inform whomever inserted location intomessage thatrequest therewasa problem experienced. The Geolocationused 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 therequest has a locationValue, providing theultimate destination. A UASa URI indicating where the Target'sMUST NOT send locationis. The Location Target identifiedinthe PIDF-LO may or may nota response message, as there can bethe location inserter, or the generatorany number of issues/problems with receiving location, and therequest (theUAC orSIP server). Ultimately, location is inproxy server(s) cannot reply to aPIDF-LO. This is either inresponse with an error response. If therequest asUAS wants to send its location to amessage body (LbyV), orUAC, ithas to be dereferenced from the LbyR in the locationValuecan do so inthe request. LbyR records are typically kept onaLIS, which can challenge all dereference requests. All PIDF-LOs havenew request within aLocation Target identifier.separate transaction. This document gives no recommendation about which SIP request to use, but SIP MESSAGE iswho the location is about. The "inserted-by=" parameter of the locationValue tells thea viable choice. A UASwho inserted that locationValue. This "inserted-by=" parameter is copied intoMAY include a 'geolocation' option tag in the"inserter=" parameterSupported header field ofthe locationErrorValue generated by the Location Recipient (the UAS), ina response,whenindicating itwants to inform thedoes understand this extension, even if location"inserter=" entity therewas not included in aproblem withrequest to the UAS. A UAS wishing to dereference an locationit received. There can be more than one locationValuesURI contained in arequest. The "inserter=" parameterreceived request will use the 'presence' event package in a SUBSCRIBE request to thelocationErrorValueURI. If accepted, the LS willdistinguish it from being misunderstood by entities that did not insertreturn theerrored location.PIDF-LO to the UAS in a NOTIFY request. If thereis one valid locationValueare any errors during dereferencing, or ina request, even if alltheothers have errors with them, a 424 (Bad Location Information) response MUST NOT be sent. The Location Recipient (the UAS) is RECOMMENDEDPIDF-LO itself, the UAS will respond tosendthe original request with a locationErrorValuefor each errored locationValue,indicating what the UAS concluded was wrong withunique "inserter=" parameters to make suretheright entities know which locations were in error. As hinted at, a location "inserter=" can be a UAC or it can be an in-signaling-path SIP server, who is acting as a UAC locator.location. Thismeans the SIP serverisincluding its version of where it thinks the UAC is, geographically. This "inserter=" hastobe in the form of an LbyRinclude any dereferencing problems encountered. Dereferencing for sip:, sips: and pres: URIin a locationValue, because SIP serversschemes arenot allowedmandatory-to-implement. A UAS MUST be prepared toinsert message bodies, as of the time of this publication,receive subsequent location updates fromalltheway back to RFC3261. Each locationErrorValue has an error code, lettingUAC, either LbyV or LbyR (regardless of how the UAS received location previously from this UAC). The UAC will convey updated location"inserter=" entity know what was wrong withusing thelocation supplied. See Section 4.3 forUPDATE [RFC3311] method to the5 actionable responsesUAS, and not aUAC can take fromreINVITE. The UAS MUST NOT reject updated location arriving in alocationErrorValue.reINVITE though, as other dialog parameters might be changing also (in which a reINVITE is appropriate). Ifthethere is more than one location"inserted-by=" entity, meaning either the UAC(any combination of LbyV and LbyR), this document does not give guidance about what a Location Recipient does with each location. There are no priority orproxymore-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 themessage path, chose to indicate thatPIDF-LO, locationwas so importantelements in therequestsame PIDF-LO MUST apply toinclude a 'geolocation' option tagthe same Target (identified ina Require header,theresponse SHOULD be a 424 (Bad Location Information) back to"entity=" attribute) and point at the"inserter=" entity (knowingsame position on theresponse will ultimately go toearth. If there is more than one PIDF-LO with different Target identifiers, then the UACregardless) ifis merely telling the UAS where more than one Target is, and thereneeds toshould not be any conflict. Within any PIDF-LO, there is alocationErrorValue sent because<retransmission-allowed> policy element that can be set to "yes" or "no". These are the only possibilities. If Alice conveys her locationwas bad. Only entities identified in a locationErrorValue as the "inserter=" entity will pay attentionto Bob (as has been described throughout thislocationErrorValue. All other entitiesdocument) with a <retransmission-allowed> element set to "no", then Bob MUSTignoreNOT inform anylocationErrorValue not directed towards them. See section 4.3 for more information on this, including allother element where Alice is. If thelocation specific errors and Geolocation-Error header parameters. In<retransmission-allowed> element is set to "yes", then Bob can inform other elements where Alice is, but only as long as theabove scenario ('geolocation' option tag<retention-expiry> policy element, also ina Require header),theonly other response can bePIDF-LO, allows [RFC4119]. As a420, but onlybyproduct of this, that means that if Alice conveys her location to Bob with a <retransmission-allowed> element set to "yes", and theUAS<retention-expiry> time does notsupport this Geolocation extensionrequire Bob toSIP,delete Alice's location yet, then Bob is free to tell anyone else where Alice is. The entity= attribute in the424<presence> element identifies who issent. Ifthelocation "inserted-by=" entity placedtarget of each location, preventing confusion. Whenever Bob conveys Alice's location, <retention-expiry> timer MUST be maintained as is (i.e., not changed from when Bob received it). RFC 4119 implicitly allows this behavior, and the'geolocation' option tag in a Supported header,behavior does not change when SIP is theresponse can beUsing Protocol. 6.2.1 UAS Generating a424 if it chooses, but also can be any other SIP response, includingLocation Failure Indication If a200 OK. A locationErrorValueUAS receives location in aGeolocation-Error header thatrequest, but determines there isnot ina424 (Bad Location Information) response is considered informational by the Location Recipient, and not considered important enough to rejectproblem with therequest based solely on badlocationinformation. For example, Alice INVITEs Bobin the request, it is the responsibility of the UAS toa dialog, and includes geolocation ininform the entity that inserted the problematic location into that request.Bob can acceptThe Geolocation header field in theINVITE with a 200 OK and still addrequest has alocationErrorValue inlocationValue, providing the200 OKUAS a location URI indicating"yes, I accept your request, and btw, something was wrong withwhere the Target's locationyou provided (inis. The Location Target identified in theINVITE)". What was wrong withPIDF-LO may or may not be the locationis indicated byinserter, or theGeolocation-Error code. Who this locationErrorValue is for is indicated bygenerator of the"inserter=" parameter. Each locationErrorValuerequest. Ultimately, location isdestined for one "inserter=" entity. This givesin aLocation Recipient one mechanism to tell each inserter whatPIDF-LO. This is either in the request as a message body (LbyV), or obtained by initiating a dereference transaction on a LocationRecipient concluded was wrong with whatServer identified in the"inserter=" included (as far aslocationis concerned). Therefore, o there MUST beURI. Location Servers typically challenge all dereference requests. All PIDF-LOs have alocationErrorValue for eachLocation Target identifier. The "inserted-by=" parameter of the locationValuethat was considered bad bytells the UASto ensure each upstream location inserter understandswhicherror code(s)SIP entity inserted that locationValue. This "inserted-by=" parameter isintended for them (and which to ignore). o there MUST NOT be more than onecopied into the "inserter=" parameter of the locationErrorValueingenerated by theresponse per locationValueLocation Recipient (the UAS), in a response, when it wants to inform therequest. olocation "inserter=" entity thereMUST NOTwas a problem with the location it received. There can be more than onelocationErrorValue to the samelocationValue in a request. The "inserter=" parameter in therequest. o there MUST NOT be alocationErrorValueinwill prevent entities that did not insert theresponse for aerrored location from misunderstanding whether the locationErrorValue applies to them. If there is one valid locationValue in a request, even if all therequest that was not in error, according toothers have errors with them, the LocationRecipient. Here is an example ofRecipient MUST NOT send aGeolocation-Error header Geolocation-Error: 400; code="Permission Necessary"; node="server42.example2.com"; inserter="alice.example.com";424 (Bad Location Information) response. Theabove example says that theLocation Recipientis server42.example.com, and this entity believes it cannot route this message without knowing(the UAS) MUST send a locationErrorValue for each errored locationValue, with unique "inserter=" parameters to make sure the"inserter="'s location. Thisright entities know which locations were in error. As hinted at, a locationmay"inserter=" can bein the request,a UAC or itmay needcan 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 therequest andform 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 wasnot.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 locationis encrypted, server42 doesn't know it is"inserted-by=" entity, meaning either the UAC or proxy in the message path chose to indicate that location was sufficiently important to include a 'geolocation' option tag inthe request. server42.example.com sendsa Require header field, any error response SHOULD be a 424 (Bad Location Information)response with a locationErrorValue indicating a 400 location error, which means it requires permissionback toview Alice's locationthe "inserter=" entity (knowing the response will ultimately go toproceed with processing her signaling. Section 4.3 highlights this example, statingtheuser, Alice, MUST be made aware of this location revelation request. This document does not give any guidance how Alice isUAC regardless) if there needs to beinformed (i.e., audio, visual, etc). Alice can grant permission or choose not to, knowing this SIP request attempt (to this destination, at this time) will fail. The problem could be corrected ifafuture SIP request weregood locationValue sent totravel throughproperly process the request. Only entities identified in adifferent server than server42 (or it might not).locationErrorValue as the "inserter=" entity will pay attention to this locationErrorValue. All other entities MUST ignore any locationErrorValue not directed towards them. SeeSectionsection 4.3 forfurther rules aboutmore information on this, including all the location-specific errors and Geolocation-Error headerandfield parameters. In thelocationErrorValue. This document says nothing about whatabove scenario ('geolocation' option tag in aLocation RecipientRequire header field), the only other response can be a 420, if the UAS doeswith more than one 'good' locationValuenot support this Geolocation extension to SIP. If the "inserted-by=" location entity placed the 'geolocation' option tag in arequest (i.e., which to choose to use). This scenario MAYSupported header field, the response can beaddresseda 424 if it chooses, but also can be any other SIP response, including a 200 OK. A locationErrorValue in afuture effort. Further, more than one error codeGeolocation-Error header field that isallowednot in a 424 (Bad Location Information) response is considered informational by thelocationErrorValue - each having one "inserter=" parameter. The error codes destined for the same inserter MUST NOT contradict the meaning of the problemLocation Recipient, and does not cause the Location Recipienthad with a particular locationValue. 6.3 Proxy Behavior [RFC3261] states message bodies cannot be added by proxies. However, proxies are permittedtoadd a headerreject the request solely because of bad location information. For example, Alice INVITEs Bob to a dialog, and includes geolocation in the request.This implies that a proxyBob can accept the INVITE with a 200 OK and still add aGeolocation locationValuelocationErrorValue in the 200 OK indicating "yes, I accept your request, and btw, something was wrong withLbyR URI, but not LbyV message body. It is allowed, but NOT RECOMMENDED, for more than one SIP element to insertthe locationinto a request along its path. As described earlieryou provided inthis document, each insertion ofthe INVITE". The specific problem with the locationinto a SIP requestisaccompaniedindicated by the Geolocation-Error code. The "inserter=" parameter identifies the Location Inserter this locationErrorValue is intended for. Each locationErrorValue is destined for one "inserter=" entity. This gives anew locationValue inLocation Recipient aGeolocation header. Also described earlier, each locationValue MUST contain an "inserted-by=" value indicatingmechanism toatell each inserter what the Location Recipientwhich host inserted location into a particular request. However, ifconcluded was wrong with the locationis already in a SIP request,the "inserter=" entity included. Therefore, o there MUST be aSIP server SHOULD NOT add another LbyRlocationErrorValue for each locationValue thatidentifieswas considered bad by thesame targetUAS to ensure each upstream location inserter understands which error code is intended for the inserter (and which to ignore). o there MUST NOT be more than one locationErrorValue in thePIDF-LO (inresponse per locationValue in the<dm:device id> element) torequest. o there MUST NOT be more than one locationErrorValue with the same "inserter=" entity in the request.This will likely cause confusion ato there MUST NOT be a locationErrorValue in theLocation Recipient as to which to use. A proxy is permitted to read any locationValue, andresponse for a locationValue in theassociated body, ifrequest that was notS/MIME protected,intransit if present, and can useerror, according to thecontentsLocation Recipient. Here is an example ofthea Geolocation-Error header fieldto make location-based retargeting decisions, if retargeting requests based on location is a function ofGeolocation-Error: 201; code="Linkable Target Identity Required"; node="server42.example.com"; inserter="alice.example.com"; The above example says thatproxy. Retargeting is defined in [RFC3261]. However, iftheGeolocation header parameter "routing-allowed"Location Recipient ispresentserver42.example.com, andset to "no", or is not present (knowing the default behavior is "no" if not present, with or without a Geolocation header), SIP servers MUST NOT view the contents ofthis entity cannot verify theLbyV message body. Further, SIP servers MUST NOT attempt to dereference an LbyR.Target's identity within this message. This isbecausetypically needed in order to make routing decisions for the SIPrequest, likelyrequest where the entity= attribute has an unlinkable pseudonym obscuring a location target's identity from theoriginating UAC, didsignaling. This is notgive the SIP server permissiondesire because if Alice's message is toviewbe routed based on the locationwithinin the SIPrequest. How a SIP server indicates it requires permission to view a request's location in orderrequest, server42 has toproperly processverify that thisrequestisin section 6.3.2. If the Geolocation header parameter "routing-allowed"Alice's location. The appropriate action ispresent into send aSIP request, the value MUST NOT be changed during processing of the request. If424 (Bad Location Information) response with theGeolocationabove (201) Geolocation-Error headerparameter "routing-allowed" isvalue. We do notpresent, SIP servers are to treat the location within thewant Alice's requestas ifrouted based on Bob's location. See Section 4.3 for further rules about the Geolocation-Error headerparameter "routing-allowed" were present and set to "no". In the spirit of informing implementers of B2BUAsfield andSBCs, each server type really should adhere totheabove proxy guidancelocationErrorValue. This document says nothing about what a Location Recipient does withrespectmore than one 'good' locationValue in a request (i.e., which to choose to use). This scenario MAY be addressed in a future effort. Further, more than one error code is allowed in the"Routing-allowed" header parameter, understanding that there are no IETF police, and the specific behaviors of these types of SIP serverslocationErrorValue - each having one "inserter=" parameter. 6.3 Proxy Behavior [RFC3261] states message bodies cannotpresentlybedefined. In other words, if the particular type of SIP server mentioned here isadded by proxies. However, proxies are permitted to add a header field to a request. This means that a proxy can add a Geolocation locationValue header field with a dereferencable location URI, but notthe ultimate destination of thisa LbyV message body. It is allowed, but NOT RECOMMENDED, for more than one SIP element to insert location into a requestand supportsalong its path. As described earlier in thisSIP extension,document, eachpolicy rule within the Geolocation header needs to remain intact and unchanged. No typeinsertion of location into a SIPserver can deleterequest is accompanied by a"Routing-allowed"new locationValue in a Geolocation headerparameter, but if onefield. Also described earlier, each locationValue MUST contain an "inserted-by=" value indicating to a Location Recipient the host that inserted a specific location into a particular request. If, however, location isnot yet present, anyalready in a SIP request, a SIP serverMAYSHOULD NOT adda "Routing-allowed" header parameter withanother location URI that identifies thevalue setsame target in the PIDF-LO (in the entity= attribute) to"no" only.the same request. This will likely cause confusion at the Location Recipient as to which to use. More than one Geolocation locationValue in a message is permitted, but can cause confusion at the recipient. If a proxy chooses to add a locationValue to a Geolocationheader,header field, which would be a local policy decision, the new locationValue MUST be added to the end of the header field (after previous locationValue(s)). This is done to create an order of insertion of locationValues along the path. Proxies MUST NOT modify the order of locationValues in a geolocationheader.header field. A proxy wishing to dereferencean LbyRa location URI contained in a received request will use the 'presence' event package in a SUBSCRIBE request to the URI. If accepted, thePIDF-LOLS will return the PIDF-LO to the proxy in a NOTIFY request. If there are any errors during dereferencing, or in the PIDF-LO itself, the proxy will send an errorthe original requestto the UAC with a locationErrorValue indicating what the proxy concluded was wrong with the location. This is to include any dereferencing problems encountered. 6.3.1 Proxy Behavior with Geolocation Header Field Parameters SIP servers MUST NOT delete any existing Geolocation locationValue (URI or header field parameter) from a request. An existing locationValue(URI or header parameter)MAYonlybe modified by adding a "used-for-routing" parameter to an existing locationValue, if the request was retargeted based on the location within that locationValue.Further modification ofAccording to this specification, the default value of any Geolocation header value "routing-allowed" is "no". This parameter does not have to be present to deny SIP servers along the signaling path the ability to view the target's location. This parameter MAY be added in transit by a SIP server, and MUST be with a value of "no". Other modifications of the Geolocation header field MUST NOT occur. For example, an existing Geolocation locationValue in a request of: Geolocation: <cid:alice123@atlanta.example.com>; inserted-by="alice123@atlanta.example.com"; can be modified by a proxy to add the "used-for-routing" parameter, like this: Geolocation: <cid:alice123@atlanta.example.com>; inserted-by="alice123@atlanta.example.com"; used-for-routing if this is the locationValue the proxy used to make a retargeting decision based upon, but the proxy can make no other modification. A SIP server MAY add a new Geolocation locationValue to a SIP request. Theproxyserver SHOULD NOT insert a locationValue of aLocationTarget unless it is reasonably certain it knows the actual geographic location of the LocationTarget, forTarget (for example, if it thoroughly understands the topology of the underlying access network and it can identify the devicereliably (inlocation reliably, even in the presenceof, for example,of NAT or VPN). Routing errors are likely if the SIP server inserts an incorrect locationValue. Aserver adding alocationValue added to an existing Geolocation header field would look like: Geolocation: <cid:alice123@atlanta.example.com>; inserted-by="alice123@atlanta.example.com",<sips:3sdefrhy2jj7@lis1.atlanta.example.com>; inserted-by="lis1.atlanta.example.com"<sips:3sdefrhy2jj7@ls7.atlanta.example.com>; inserted-by="ls7.atlanta.example.com" Notice the locationValue added bytheproxy "ls7" is last among locationValues.This practiceProxies MUSTbe done foradd locationValue at the end of alladded locationValues.locationValues that are already present in the request. If this request was then retargeted by an intermediary using the locationValue inserted bythe server,server "ls7", the intermediary would add a "used-for-routing" parameter like this: Geolocation: <cid:alice123@atlanta.example.com>; inserted-by="alice123@atlanta.example.com",<sips:3sdefrhy2jj7@lis1.atlanta.example.com>; inserted-by="lis1.atlanta.example.com";<sips:3sdefrhy2jj7@ls7.atlanta.example.com>; inserted-by="ls7.atlanta.example.com"; used-for-routing It is conceivable that an initial routing decision is made on one locationValue, and subsequently another routing decision is made on a different locationValue further towards the ultimate destination. This retargeting decision can be made on anewly inserted locationValue. While unusual,newly inserted locationValue. While unusual, it can occur. In such a case, proxies MUST NOT remove any existing "used-for-routing" header field parameter. In this instance, the SIP server retargeting based on another locationValue MUST add the "used-for-routing" header field parameter to the locationValue used for retargeting by this server. This will result in a Geolocation header field indicating that the request has been retargeted more than once, which is allowed. A Proxy that inserts or adds locationValue into a request MAY move a 'geolocation' option tag that is in a Supported header field into a Require header field if this proxy deems geolocation to be sufficiently important to Location Recipient(s) of this request. A proxy can read any locationValue present, and the associated body, if not S/MIME protected, and can use the contents of the header field to make location-based retargeting decisions, if retargeting requests based on location is a function of that proxy. Retargeting is defined in [RFC3261]. However, if the Geolocation header field parameter "routing-allowed" is present and set to "no", or is not present (the default behavior is "no" if "routing-allowed" is not present, whether or not a Geolocation header field is present), SIP servers MUST NOT view the contents of the location message body. Further, SIP servers MUST NOT attempt to dereference a location URI. This is because the Location Inserter (likely the originating UAC) did not give the SIP server permission to view the location within the SIP request. How a SIP server indicates itcan occur. In suchrequires permission to view acase, proxiesrequest's location in order to properly process this request is described in section 6.3.2. If the Geolocation header field parameter "routing-allowed" is present in a SIP request, the value MUST NOTremove any existing "used-for-routing" header parameter. In this instance,be changed during processing of the request. If the Geolocation header field parameter "routing-allowed" is not present, SIPserver retargeting based on another locationValueservers MUSTaddtreat the location within the request as if the"used-for-routing"header field parameter "routing-allowed" were present and set to "no". B2BUAs and SBCs should also adhere to thelocationValue used for retargeting by this server. This will result in a Geolocationabove proxy guidance with respect to the "Routing-allowed" headerlooking asfield parameter. In other words, ifit were retargeting more than once, which would be true -the particular type of SIP server mentioned here supports this SIP extension and is not thedesired outcome. A Proxy that inserts or adds locationValue into a request MAY move a 'geolocation' option that is in a Supportedultimate destination of this SIP request, each policy rule within the Geolocation headerintofield MUST remain intact and unchanged. No SIP server can delete aRequire"Routing-allowed" header field parameter, but ifthis proxy deems geolocation to be that importantone is not yet present, any SIP server MAY add a "Routing-allowed" header field parameter with the value set toLocation Recipient(s) of this request."no" only. 6.3.2 Proxy Error Behavior for Sending or Receiving locationErrorValues For proxies that receive a SIP request that contains a location error,either in a contained message body or after the proxy does a dereference of the LbyR URI,all the rules applicable to a UAS applyhere(see Section6.2.1.), since in this case, the proxy is considered a Location Recipient. Therefore, there is no reason to restate them here, and potentially have the two sections be inconsistent.6.2.1.). The onethingpoint to add is that a proxy does not need to examine location contained in a request. Section 6.2.1. only applies to proxies thatare needing, monitoringneed to monitor orpolicingpolice location within requests (for whatever reason). If a proxy inserted a locationValue into a request, itSHOULDMUST be ready to examine the response to that request, in case there is one or more location errors in the response. To a great degree, this scenario has the proxy behaving as a UAC (see section 6.1.1.) that included a locationValue a request, which then receives an error to that locationValue. Thislocation insertinglocation-inserting proxy SHOULD be (at least) transaction stateful for the response. If the proxy is configured as a stateless proxy, and it inserts location, it MUST process and monitor all SIP responses, looking for locationErrorValues that indicate it was the "inserter=" to learn that the location it supplied was in error. It SHOULD reactaccordinglyaccording to the error code received. This document gives no guidance what the proxy should do to rectify the bad location information, since the proxy is not the SIP response destination, but a future documentMAYcould address this. The "routing-allowed" parameter's purpose is to indicate if SIP servers along the signaling path should bother looking at theLbyVlocation message body or dereferencing theLbyR.location URI. There are two values specified here for this parameter: "yes" and "no". If the "routing-allowed" parameter is set to "yes", and the SIP server determines this SIP requestneeds toshould be routed based on thelocation of thetarget's location, this parameter gives the server permission to look at thelocation (or dereference it). Iflocation (or dereference it). If this parameter is set to "no", then the SIP server MUST NOT view the location message body or dereference the location URI within this SIP request. If the SIP server believes it cannot process this message properly because it needs to learn the target's location in order to route the message, then it MUST return a 424 (Bad Location Information) response, indicating it requires permission (error code 400) to view the location. Here is an example of a Geolocation-Error header field Geolocation-Error: 400; code="Permission to Reveal Location Information to a Third Party"; node="server42.example.com"; inserter="alice.example.com"; The above example says that the Location Recipient is server42.example.com, and this entity believes it cannot route this message without knowing permission to view the Target's location. Regardless of whether there is a Geolocation header value parameter, such as routing-allowed=no or this parameter is not present in the SIP request (as shown 400 error example above). The default behavior is to act as if the parameter is present and set to "no". Server42 MUST get permission to view the Target's location by reading a routing-allowed header parameter saying "yes", otherwise a 400 error is sent back to the inserter= entity to get permission. Section 4.3 highlights this example, stating the user, Alice, MUST be made aware of thisparameterlocation revelation request. This document does not give any guidance how Alice issetto"no", then the SIP server MUST NOT view the LbyVbe informed (i.e., audio, visual, etc). Alice can grant permission ordereference the LbyR withinchoose not to, knowing this SIPrequest. If the SIP server believes it cannot processrequest attempt (to thismessage properly because it needs to learn the target's location in orderdestination, at this time) will fail. The problem might not recur if a future SIP request were toroute the message, then it MUST returntravel through a424 (Bad Location) response, indicatingdifferent server than server42 (or itrequires permission (error code 400) to view the location.might again). 7. Geopriv Privacy Considerations Location information is considered by most to be highly sensitive information, requiring protection from eavesdropping, and altering in transit. [RFC3693] articulates rules to be followed by any protocol wishing to be considered a "Using Protocol", specifying how a transport protocol meets those rules. This section describes how SIP as a Using Protocol meets those requirements. Quoting requirement #4 of [RFC3693]: "The Using Protocol has to obey the privacy and security instructions coded in the Location Object and in the corresponding Rules regarding the transmission and storage of the LO." This document requires that SIP entities sending or receiving location MUST obey such instructions. Quoting requirement #5 of [RFC3693]: "The Using Protocol will typically facilitate that the keys associated with the credentials are transported to the respective parties, that is, key establishment is the responsibility of the Using Protocol." [RFC3261] and the documents it references define the key establishment mechanisms. Quoting requirement #6 of [RFC3693]: "(Single Message Transfer) In particular, for tracking of small Target devices, the design should allow a single message/packet transmission of location as a complete transaction." When used for tracking, a simple NOTIFY or UPDATE normally is relatively small, although the PIDF itself cangetbe large. Normal RFC 3261 procedures of reverting to TCP when the MTU size is exceeded would be invoked. 8. Security Considerations Conveyance of physical location of a UAC raises privacy concerns, and depending on use, there probably will be authentication and integrity concerns. This document calls for conveyance tonormallybe accomplished through secure mechanisms, like S/MIME protecting message bodies(but(although this is not widely deployed) or TLS protecting the overall signaling. In cases where a session set-up is retargeted based on the location of the UAC initiating the call or SIP MESSAGE, securing the LbyV location with an end-to-end mechanism such as S/MIME is problematic, because one or more proxies on the path need the ability to read the location information to retarget the message to the appropriate new destination UAS. Securing the location hop-by-hop, using TLS, protects the message from eavesdropping and modification, but exposes the information to all proxies on the path as well as the endpoint. In most cases, the UAC does not know the identity of the proxy or proxies providing location-based routing services, so that end-to-middle solutions might not be appropriate either. These same issues exist for basic SIP signaling, but SIP normally does not carry information to physically track auser; making thisuser. This extension is especially sensitive. That said, there is the ability, according to [RFC3693] to have an anonymous identity for the target's location. This is accomplished by use of an unlinkable pseudonym in the entity= attribute of the <presence> element [RFC4479]. Though, this can be problematic for routing messages based on location (covered several times in the document above). When location is inserted by a UAC, which is RECOMMENDED, it can decide whether to reveal its location using hop-by-hop methods. UAC implementations MUST make such capabilities conditional on explicit user permission, and SHOULD alert a user that location is being conveyed. Proxies inserting location for location-based routing are unable tomeet this requirement,alert users, and such use is NOT RECOMMENDED. Proxies conveying location using this extension MUST have the permission of the Target to do so.One facet within thisThis SIP extension offers the default ability to require permission to view location while the SIP request issuch thatin transit. The default for this is set to "no", and there is an error explicitly describing how an intermediary asks for permission to view the Target's location. Because target locations can be placed on a remote server, called a Location Server accessible with the possession of aURI. The concept of an LbyRlocation URI, this URI has its own security considerations. It is tempting to assume that the dereference of this URI would have authentication, authorization and other security mechanisms that limit the access to information. Unfortunately, this might not be true. The access network the UAC is connected to can be the source of location reference, and it might not have any credentialing mechanism suitable for controlling access to a target's location. Consider, specifically, a nomadic user connected to an access network in a hotel. The UAC has no way to provide a credential acceptabletoof the hotel Location Server (LS) to any of its intended Location Recipients. The recipient of a reference does not know if a reference has appropriate authorization policies or not.The LS should provide location to any requestor.Accordingly, possession of the reference should be considered equivalent to possession of the value, and the reference should be treated with the same degree of care as the value. Specifically, TLS MUST be used to protect the security of the reference. Notice that this specification does not constrain the dereference protocol to use TLS. That specification is left entirely to the dereferencing protocol documents. There is no end-to-end integrity on any locationValue or locationErrorValue header field parameterend-to-end(or middle-to-end if the value was inserted by a intermediary), so recipients of either header field need to implicitly trust the header field contents, and take whatever precautions each entity deems appropriategive these facts.given this situation. Any idea of using SIP Identity is lost as soon as it is realized that the Geolocation header value can be added to by intermediaries in the signaling path. 9. IANA Considerations The following are the IANA considerations made by this SIP extension. Modifications and additions to these registrations require a standards track RFC (Standards Action). [Editor's Note: RFC-Editor - within the IANA section, please replace "this doc" with the assigned RFC number, if this document reaches publication.] 9.1 IANA Registration for the SIP Geolocation Header Field The SIP GeolocationheaderHeader Field is created by this document, with its definition and rules in Section 4.1 of this document,toand should be added to thesip-parameters,IANA sip-parameters registry, in the portion titled "Header Field Parameters and Parameter Values". Predefined Header Field Parameter Name Values Reference ---------------- ------------------- ---------- --------- Geolocation inserted-by= no [this doc] Geolocation used-for-routing yes [this doc] Geolocation routing-allowed yes [this doc] 9.2 IANA Registration for New SIP Option Tag The SIP option tag "geolocation" is created by this document, with the definition and rule in Section 4.4 of this document, to be added to the IANA sip-parameterswithin IANA.registry. 9.3 IANA Registration for Response Code 424 Reference: RFC-XXXX (i.e., this document) Response code: 424 (recommended number to assign) Default reason phrase: Bad Location Information This SIP Response code is defined in section 4.2 of this document. 9.4 IANA Registration of New Geolocation-Error Header Field The SIP Geolocation-error header field is created by this document, with its definition and rules in Section 4.3 of this document, to be added to thesip-parameters,IANA sip-parameters registry, in the portion titled "Header Field Parameters and Parameter Values". Predefined Header Field Parameter Name Values Reference ----------------- ------------------- ---------- --------- Geolocation-Error inserter= no [this doc] Geolocation-Error node= no [this doc] Geolocation-Error code=noyes* [this doc] * see section 9.5 for the newly created values. 9.5 IANA Registration for the SIP Geolocation-Error Codes New location specific Geolocation-Error codes are created by this document, and registered in a new tableatin the IANA sip-parameterswithin IANA.registry. Details of these error codes are in Section 4.3 of this document. Geolocation-Error codes ----------------------- Geolocation-Error codes provide reason for the error discovered by Location Recipients, categorized by action to be taken by error recipient to be placed into SIP responses to inform the location inserter of the error. Code Description Reference ---- --------------------------------------------------- --------- 100 "Cannot Process Location" General location error, [this doc] meaning location in the request cannot be processed at this time. No actionable guidance. Can be treated as a 200 or 300 error by error recipient. 200 "Retry LocationLater" (withLater with samedata) Locationdata" The location [this doc] cannot be processed at this time. Error recipient should try again with same data. 201 "Linkable Target Identity Required" [this doc] Target's identity cannot be unlinkable within the presence element's entity= attribute. This is necessary for routing SIP requests based on Target's location (and some other entity's). 300 "Retry LocationLater" (withLater with device updatedlocation)location" [this doc] Location cannot be processed at this time. Error recipient should try again with same data. 400 "PermissionNecessary"To Reveal Location Information to a Third Party" Permission from calling user[this doc]to reveal location [this doc] in request before request can be processed. This is a routing by location error. User MUST be informed of permission request. 500 "Location Information Denial" Request was actively [this doc] denied because of the location in the request. Recipient should not try again. 9.6 IANA Registration ofLbyRLocation 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 thereference. Below is an example of how it could lookreference, as follows: URI Scheme Content-Type Reference ---------- ------------ --------- SIP: [this doc] SIPS: [this doc] PRES: [this doc] Additions to this registryrequire an industry specification.must be defined in a permanent and readily available specification (this is the "Specification Required" IANA policy defined in [RFC5226]).. 10. Acknowledgements To Dave Oran for helping to shape this idea. To Jon Peterson and Dean Willis on guidance of the effort. To Allison Mankin, Dick Knight, Hannes Tschofenig, Henning Schulzrinne, James Winterbottom, Jeroen van Bemmel, Jean-Francois Mule, Jonathan Rosenberg, Keith Drage, Marc Linsner, Martin Thomson, Mike Hammer, Ted Hardie, Shida Shubert, Umesh Sharma, Richard Barnes, Dan Wing, Matt Lepinski and Jacqueline Lee for constructive feedback and nits checking.A specialSpecial thanks to Paul Kyzivat for his help with the ABNF in thisdocument, to Dan Wing for help with the S/MIME example,document and to Robert Sparks for many helpful comments and the properbuildingconstruction of the Geolocation-Errorheader.header field. And finally, to Spencer Dawkins for giving this doc a good scrubbing to make it more readable. 11. References 11.1 References - Normative [RFC3261] J. Rosenberg, H. Schulzrinne, G. Camarillo, A. Johnston, J. Peterson, R. Sparks, M. Handley, and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, May 2002. [RFC4119] J. Peterson, "A Presence-based GEOPRIV Location Object Format", RFC 4119, December 2005 [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate [RFC2392] E. Levinson, " Content-ID and Message-ID Uniform Resource Locators", RFC 2392, August 1998 [RFC3863] H. Sugano, S. Fujimoto, G. Klyne, A. Bateman, W. Carr, J. Peterson, "Presence Information Data Format (PIDF)", RFC 3863, August 2004 [RFC3856] J. Rosenberg, " A Presence Event Package for the Session Initiation Protocol (SIP)", RFC 3856, August 2004 [RFC3859] J. Peterson, "Common Profile for Presence (CPP)", RFC 3859, August 2004 [RFC3428] B. Campbell, Ed., J. Rosenberg, H. Schulzrinne, C. Huitema, D. Gurle, "Session Initiation Protocol (SIP) Extension for Instant Messaging" , RFC 3428, December 2002 [RFC3311] J. Rosenberg, "The Session Initiation Protocol (SIP) UPDATE Method", RFC 3311, October 2002 [RFC3265] Roach,A.,A, "Session Initiation Protocol (SIP)-Specific Event Notification", RFC 3265, June 2002. [RFC3262] Rosenberg, J. and H. Schulzrinne, "Reliability of Provisional Responses in Session Initiation Protocol (SIP)", RFC 3262, June 2002. [RFC3515] R. Sparks, "The Session Initiation Protocol (SIP) Refer [RFC3903] Niemi,A.,A, "Session Initiation Protocol (SIP) Extension for Event State Publication", RFC 3903, October 2004. [RFC5234] Crocker, D., Ed., and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008. [IANA-civic] http://www.iana.org/assignments/civic-address-types- Registry[RFC5491] J. Winterbottom, M. Thomson,[RFC5226] T. Narten, H.Tschofenig, "GEOPRIV PIDF-LO Usage Clarification, Considerations, and Recommendations ",Alvestrand, "Guidelines for Writing an IANA [RFC4479] J. Rosenberg, "A Data Model for Presence", RFC 4479, July 2006 11.2 References - Informative [RFC3693] J. Cuellar, J. Morris, D. Mulligan, J. Peterson. J. Polk, "Geopriv Requirements", RFC 3693, February 2004 [RFC4483] E. Berger, "A Mechanism for Content Indirection in SIP", RFC [RFC3825] J. Polk, J. Schnizlein, M. Linsner, "Dynamic Host Configuration Protocol Option for Coordinate-based Location [RFC4776] H. Schulzrinne, " Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6) Option for Civic Addresses Configuration Information ", RFC 4776, October 2006 [ID-PHONE] B. Rosen, J. Polk, "ECRIT Phone BCP", Author Information James Polk Cisco Systems 3913 Treemont Circle Colleyville, Texas 76034 33.00111N 96.68142W Phone: +1-817-271-3552 Email: jmpolk@cisco.com Brian Rosen NeuStar, Inc. 470 Conrad Dr. Mars, PA 16046 40.70497N 80.01252W Phone: +1 724 382 1051 Email: br@brianrosen.net Appendix A. Requirements for SIP Location Conveyance The following subsections address the requirements placed on the UAC, the UAS, as well as SIP proxies when conveying location.There isIf amotivational statement below each requirements thatrequirement is not obvious inintentintent, 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:interoperabilityto guarantee interoperability. UAC-6 It must be possible for a UAC to update location conveyed at any time in a dialog, including during dialog establishment. Motivation:in caseif a UAC has moved prior to the establishment of a dialog between UAs, the UAC must be able to sendnewlocation information.In the case ofIf locationhavinghas been conveyed, and the UA moves,it needs a meansthe UAC must be able to update the location previously conveyed toparty of this location change.other parties. UAC-7 The privacy and security rules established within [RFC3693] that would categorize SIP as a 'Using Protocol' must be met. UAC-8 The PIDF-LO [RFC4119] is a mandatory to implement format for location conveyance within SIP, whether included LbyV or LbyR. Motivation: interoperability with other IETF location protocols andmechanismsMechanisms. UAC-9 There must be a mechanism for the UAC to request the UAS send itslocationlocation. 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 canbehappen because the UAC does not implement this extension, orit can be thatbecause the UAC implements the extension, but does not know whereitthe Target is. This may be, for example, due to the failure of the access network to provide a location acquisitionmechanismsmechanism the UACunderstands.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 theUASUAS. 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: Providethe capability ofnetwork 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 thesipSIP 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.