idnits 2.17.1 draft-ietf-sipcore-location-conveyance-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == It seems as if not all pages are separated by form feeds - found 0 form feeds but 49 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 591 has weird spacing: '...hat the heade...' == Line 626 has weird spacing: '... ar o ...' == Line 630 has weird spacing: '... ar o ...' == Line 1241 has weird spacing: '...s might speci...' == Line 2091 has weird spacing: '...n-Error inse...' == (2 more instances...) == The document seems to use 'NOT RECOMMENDED' as an RFC 2119 keyword, but does not include the phrase in its RFC 2119 key words list. == Unrecognized Status in 'Intended Status: Standards Track (PS)', assuming Proposed Standard (Expected one of 'Standards Track', 'Full Standard', 'Draft Standard', 'Proposed Standard', 'Best Current Practice', 'Informational', 'Experimental', 'Informational', 'Historic'.) == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 13, 2009) is 5393 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC3863' is defined on line 2196, but no explicit reference was found in the text == Unused Reference: 'IANA-civic' is defined on line 2231, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3265 (Obsoleted by RFC 6665) ** Obsolete normative reference: RFC 2976 (Obsoleted by RFC 6086) -- Possible downref: Non-RFC (?) normative reference: ref. 'IANA-civic' ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) -- Obsolete informational reference (is this intentional?): RFC 3825 (Obsoleted by RFC 6225) Summary: 4 errors (**), 0 flaws (~~), 13 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SIPCORE Working Group James Polk 3 Internet Draft Cisco Systems 4 Expires: January 13, 2009 Brian Rosen 5 Intended Status: Standards Track (PS) NeuStar 6 July 13, 2009 8 Location Conveyance for the Session Initiation Protocol 9 draft-ietf-sipcore-location-conveyance-01.txt 11 Status of this Memo 13 This Internet-Draft is submitted to IETF in full conformance with 14 the provisions of BCP 78 and BCP 79. This document may contain 15 material from IETF Documents or IETF Contributions published or made 16 publicly available before November 10, 2008. The person(s) 17 controlling the copyright in some of this material may not have 18 granted the IETF Trust the right to allow modifications of such 19 material outside the IETF Standards Process. Without obtaining an 20 adequate license from the person(s) controlling the copyright in 21 such materials, this document may not be modified outside the IETF 22 Standards Process, and derivative works of it may not be created 23 outside the IETF Standards Process, except to format it for 24 publication as an RFC or to translate it into languages other than 25 English. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF), its areas, and its working groups. Note that 29 other groups may also distribute working documents as Internet- 30 Drafts. 32 Internet-Drafts are draft documents valid for a maximum of six 33 months and may be updated, replaced, or obsoleted by other documents 34 at any time. It is inappropriate to use Internet-Drafts as 35 reference material or to cite them other than as "work in progress." 37 The list of current Internet-Drafts can be accessed at 38 http://www.ietf.org/ietf/1id-abstracts.txt. 40 The list of Internet-Draft Shadow Directories can be accessed at 41 http://www.ietf.org/shadow.html. 43 This Internet-Draft will expire on January 13, 2009. 45 Copyright Notice 47 Copyright (c) 2009 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents in effect on the date of 52 publication of this document (http://trustee.ietf.org/license-info). 53 Please review these documents carefully, as they describe your 54 rights and restrictions with respect to this document. 56 Legal 58 This documents and the information contained therein are provided on 59 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 60 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE 61 IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL 62 WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY 63 WARRANTY THAT THE USE OF THE INFORMATION THEREIN WILL NOT INFRINGE 64 ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS 65 FOR A PARTICULAR PURPOSE. 67 Abstract 69 This document defines an extension to the Session Initiation 70 Protocol (SIP) to convey geographic location information from one 71 SIP entity to another SIP entity. The extension covers end-to-end 72 conveyance as well as location-based routing, where SIP servers 73 make routing decisions based on the location of the user agent 74 client. 76 Table of Contents 78 1. Conventions and Terminology used in this document . . . . . . 3 79 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 80 3. Overview of SIP Location Conveyance . . . . . . . . . . . . . 4 81 4. SIP Modifications for Geolocation Conveyance . . . . . . . . 7 82 4.1 The Geolocation Header . . . . . . . . . . . . . . . . . 7 83 4.2 424 (Bad Location Information) Response Code . . . . . . 10 84 4.3 The Geolocation-Error Header . . . . . . . . . . . . . . 11 85 4.4 The 'geolocation' Option Tag . . . . . . . . . . . . . . 20 86 4.5 Using sip/sips/pres as a Dereference Scheme . . . . . . . 20 87 5. Geolocation Examples . . . . . . . . . . . . . . . . . . . . 22 88 5.1 Location-by-value (Coordinate Format) . . . . . . . . . . 22 89 5.2 Location-by-reference . . . . . . . . . . . . . . . . . . 24 90 6. SIP Element Behavior . . . . . . . . . . . . . . . . . . . . 24 91 6.1 UAC Behavior . . . . . . . . . . . . . . . . . . . . . . 25 92 6.2 UAS Behavior . . . . . . . . . . . . . . . . . . . . . . 29 93 6.3 Proxy Behavior . . . . . . . . . . . . . . . . . . . . . 34 94 7. Geopriv Privacy Considerations . . . . . . . . . . . . . . . 38 95 8. Security Considerations . . . . . . . . . . . . . . . . . . . 39 96 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . 40 97 9.1 IANA Registration for New SIP Geolocation Header . . . . 41 98 9.2 IANA Registration for New SIP 'geolocation' Option Tag . 41 99 9.3 IANA Registration for New 424 Response Code . . . . . . . 41 100 9.4 IANA Registration for New SIP Geolocation-Error Header . 41 101 9.5 IANA Registration for New SIP Geolocation-Error Codes . . 42 102 9.6 IANA Registration of LbyR Schemes . . . . . . . . . . . 43 103 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 43 104 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 43 105 11.1 Normative References . . . . . . . . . . . . . . . . . 43 106 11.2 Informative References . . . . . . . . . . . . . . . . . 45 107 Author Information . . . . . . . . . . . . . . . . . . . . . 45 108 Appendix A. Requirements for SIP Location Conveyance . . . . 45 110 1. Conventions and Terminology used in this document 112 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 113 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and 114 "OPTIONAL" in this document are to be interpreted as described 115 in [RFC2119]. 117 The following terms and acronyms used throughout this document are 118 defined here: 120 LbyR = Location-by-Reference 122 LbyV = Location-by-Value 124 Location Generator (LG): The entity that initially determines or 125 gathers the location of the Target and creates Location 126 Objects describing the location of the Target [RFC3693]. 128 Location Inserter: a role created in this document describing the 129 entity that included location in a SIP request, either by-value 130 or by-reference (i.e., including a location URI). 132 Location Object (LO): An object conveying location information 133 (and possibly privacy rules) to which Geopriv security 134 mechanisms and privacy rules are to be applied [RFC3693]. 136 Location Recipient (LR): The entity that receives location 137 information. It may have asked for this location explicitly 138 (by sending a query to a location server), or it may receive 139 this location asynchronously [RFC3693]. 141 Location Server (LS): The entity to which a LG publishes location 142 objects, the recipient of queries from location receivers, and 143 the entity that applies rules designed by the rule maker 144 [RFC3693]. 146 A Location Server is also an entity that retains Target Location 147 Objects that are dereferenced by Location Recipients via SIP 148 SUB/NOT transactions. 150 Target: A person or other entity whose location is communicated by 151 a Geopriv Location Object [RFC3693]. 153 Using Protocol: A protocol that carries a Location Object [RFC3693]. 155 2. Introduction 157 This document describes how geolocation can be "conveyed" in a SIP 158 request from one SIP entity unsolicited to another entity using SIP 159 [RFC3261]. Here, "Location" is a description of the physical 160 geographical area where something currently exists. Note that this 161 information is not solicited by the entity that receives it. The 162 mechanism in this document does not allow one SIP user to request 163 the location of another SIP user to be returned in a response. 165 Geographic location in the IETF is discussed in RFC 3693 (Geopriv 166 Requirements) [RFC3693]. It defines a "Target" as the entity whose 167 location is being transmitted over IP. A [RFC3693]-defined "Using 168 Protocol" describes how a "Location Server" transmits a "Location 169 Object" to a "Location Recipient" while maintaining the contained 170 privacy intentions of the Target intact. This document describes a 171 SIP extension to carry a Location Object and how it complies with 172 the Using Protocol requirements in RFC 3693. 174 Common terms are in Section 1. Section 3 provides an overview of SIP 175 location conveyance. Section 4 details the extensions to SIP 176 necessary to accomplish location conveyance. Section 5 gives decode 177 examples of geolocation within SIP requests, both LbyV and LbyR. 178 Section 6 articulates the SIP element type behaviors for location 179 conveyance. Section 7 discusses Geopriv privacy considerations. 180 Section 8 discusses security considerations. Section 9 IANA 181 registers the modifications made to SIP by this document in section 182 4. 184 3. Overview of SIP Location Conveyance 186 The concept of conveying location in SIP is fairly straightforward. 187 Location is conveyed directly or indirectly from a transmitting SIP 188 entity to a receiving SIP entity. When location is conveyed 189 directly, it is conveyed as a value contained within the SIP 190 request, as in Figure 1. 192 Alice Bob LIS 193 | | | 194 | Request w/ Location | | 195 |------------------------>| | 196 | | | 197 | Response | | 198 |<------------------------| | 199 | | | 201 Figure 1. Location Conveyed by Value 203 When location is conveyed indirectly, analogous to Content 204 Indirection [RFC4483], Bob receives (from Alice) a location URI and 205 must make an additional request - here called a dereference - to 206 learn Alice's actual location from a Location Server (LS) 207 identified in the location URI, as in Figure 2. 209 Alice Bob LS 210 | | | 211 | Request w/ Location URI | | 212 |------------------------>| | 213 | | Dereference Request | 214 | |---------------------->| 215 | | | 216 | | Dereference Response | 217 | |<----------------------| 218 | Response | (includes location) | 219 |<------------------------| | 220 | | | 222 Figure 2. Location Conveyed by Reference 224 Many protocols can be used for this dereference transaction, but 225 this is usually determined by the scheme of the location URI in the 226 SIP request. In other words, if the location URI is a SIPS: URI, 227 then SIPS would be used to contact the LS to make the dereference. 229 The location "value" in this SIP extension is in the form of a 230 "Presence Information Data Format - Location Object", or PIDF-LO, as 231 described in [RFC4119]. A PIDF-LO is an XML scheme specifically for 232 carrying the geographic location of a Target. LbyV refers to a UA 233 including a PIDF-LO as a message body part of a SIP request, sending 234 that Location Object to another SIP element. LbyR refers to a UA 235 including a location URI in a SIP request header field which can be 236 dereferenced by a Location Recipient to retrieve Alice's Location 237 Object, in the form of a PIDF-LO. 239 To accomplish location conveyance in SIP, a new SIP header field, 240 Geolocation, is created and described in this document. The 241 Geolocation header field contains a URI that points to where the 242 location is for the location target, either in the body of the SIP 243 request itself (LbyV), or on a Location Server (LbyR). A location 244 URI that points to a message body is always a "cid:" URI (Content 245 Identification), as defined in [RFC2392]. 247 If the URI in the Geolocation header field is a scheme other than 248 "cid:", a dereference transaction (see Figure 2) is necessary. This 249 document describes how a SIP presence subscription [RFC3856] can be 250 used as a dereference protocol. 252 Location can be inserted in a SIP request by a SIP server as well as 253 by a UA. This document offers guidance on this practice. This 254 document also describes how a location recipient can determine which 255 entity included a specific location, as more than one location can 256 be conveyed in a given SIP request. Section 4 gets into guidance and 257 limitations of this behavior. 259 A new error response (424 Bad Location Information) is also defined 260 in this document. Within this response is a new header field 261 indicating location-based errors, called the Geolocation-Error 262 header field. This header field has various codes that provide 263 additional information about the type of location error experienced 264 by a Location Recipient, separated into actionable categories to be 265 taken by the UAC. 267 Because more than one SIP entity can insert location, when 268 considering SIP as an end-to-end protocol, there needs to be a means 269 of identifying which location within a message of multiple locations 270 was considered bad by a location recipient - if that were to occur. 271 The ability to tell which entity (identified by host-id) inserted a 272 specific location is extremely important. Not only does this allow 273 each location error to be targeted at a particular inserter of a 274 specific location object, but it also allows error recipients to 275 understand when the location they inserted was not at fault, and 276 that a received error is not meant for them. This optimization is 277 necessary, otherwise each location error would be a blanket error to 278 every entity upstream in the signaling path. 280 Just as location can be conveyed by more than one entity about the 281 same target, there can be more than one location recipient along a 282 request's path. It is possible to route SIP requests based on the 283 location of the target (i.e., source based routing, instead of 284 normal destination based routing). This means SIP servers can be 285 location recipients. If this is not desired by a Location Inserter, 286 then the Location Inserter can also include a separate indication in 287 the Geolocation header field showing that this usage is not desired. 289 Location Inserters have the ability to provide instructional 290 parameters about location it has inserted. These are hints to 291 downstream entities on how the location information in the message 292 was originated, intended and is to be used. 294 Transport Layer Security is expected when a request contains a 295 target's location. Some implementations will choose to have S/MIME 296 for integrity protection, or to encrypt message bodies from source 297 to destination(s). 299 This document creates a new option tag: geolocation, to indicate 300 support for this extension by UAs. 302 The new header field, the header parameters, the new option tag, the 303 new error response, and Geolocation-Error codes are defined in 304 Section 4, each of which are IANA registered by this document. 306 RFC 3693 demands that a transmitted location be required to maintain 307 privacy considerations. This document maintains all of the privacy 308 considerations defined by RFC 3693, plus adds an intended usage 309 indication within the SIP Geolocation header field. This increases 310 the considerations for recipients not to inspect a target's location 311 when they are not the intended location recipient. 313 4. SIP Modifications for Geolocation Conveyance 315 The following sections detail the standards track modifications 316 to SIP for Location Conveyance. 318 4.1 The Geolocation Header Field 320 This document defines Geolocation as a new SIP header field 321 registered by IANA, with the following ABNF [RFC5234]: 323 Geolocation = "Geolocation" HCOLON (locationValue *(COMMA 324 locationValue)) (COMMA retrans-param) 325 locationValue = LAQUOT locationURI RAQUOT *(SEMI geoloc-param) 326 locationURI = sip-URI / sips-URI / pres-URI 327 / cid-url ; (from RFC 2392) 328 / absoluteURI ; (from RFC 3261) 329 geoloc-param = "inserted-by" EQUAL geoloc-inserter 330 / "used-for-routing" 331 / generic-param ; (from RFC 3261) 332 geoloc-inserter = DQUOTE hostport DQUOTE 333 / gen-value ; (from RFC 3261) 334 retrans-param = "routing-allowed" EQUAL "yes" / "no" 336 sip-URI, sips-URI and absoluteURI are defined according to [RFC3261]. 338 The pres-URI is defined in [RFC3859]. 340 The cid-url is defined in [RFC2392] to locate message body 341 parts. This URI type is present in a SIP request where location 342 is conveyed as a value. 344 Other protocols used in the location URI MUST be reviewed against 345 the RFC 3693 criteria for a Using Protocol. 347 The Geolocation header field MAY have one or more locationValues. 348 SIP servers inserting a locationValue MUST add the new value as the 349 last locationValue in the Geolocation header field (i.e., the last 350 locationValue in the header field is the most recent one added to 351 the message). Placement of the "routing-allowed" parameter, when 352 present, MUST be the last header field value in the Geolocation 353 header field. 355 A locationValue has the following independent header field 356 parameters, 358 o the "inserted-by=" parameter provides the hostport 359 (alice.example.com -- which is the same as the "sent-by" 360 parameter in a Via header field, with or without a port number) 361 of the SIP entity that inserted this locationValue into the 362 request. If a Location Recipient has determined a supplied 363 location is in error, as there can be more than one location in 364 any request, the "inserted-by=" parameter is copied into the 365 locationErrorValue in the response indicating the location error, 366 and to whom the error is for. Hence, this "inserted-by=" 367 parameter MUST be present in each locationValue. If an entity 368 receives an Geolocation-Error with a hostport that does not 369 identify this entity, the Geolocation-Error MUST be ignored. 371 o the "used-for-routing" parameter to inform recipients that the 372 location in this locationValue was used to route the message 373 towards the ultimate destination UAS. "used-for-routing" can 374 occur more than once along the request's path. Because 375 locationValues are inserted as last inserted is last in the 376 header field, the last locationValue is the most recent one added 377 to the message. This also gives the "used-for-routing" header 378 field parameter added meaning - as the receiving SIP entity knows 379 which location URI the message was routed upon. 381 Each locationValue MUST contain exactly one "inserted-by" parameter, 382 indicating which SIP entity added the locationValue to the SIP 383 request. 385 There MUST NOT be more than one "inserted-by=" parameter or one 386 "used-for-routing" parameter in the same locationValue. However, 387 there can be more than one locationValue in the same Geolocation 388 header field. 390 The "routing-allowed" header field parameter is a global parameter 391 over any (and all/each) locationValues in the Geolocation header 392 field. This is the reason why the placement of the header field 393 parameter is outside any locationValue, appears only once, and is 394 always last in the header field value. 396 This header field parameter only has the values "=yes" or "=no". 397 When this parameter is "=yes", any locationValue can be used for 398 routing decisions along the downstream signaling path by 399 intermediaries. When this parameter is "=no", this means no 400 locationValue (inserted by the originating UAC or any (or 401 subsequent) intermediary(ies) along the signaling path) can be used 402 by any SIP intermediary to make routing decisions. This behavior 403 MUST be adhered to. Section 4.3 describes the details on what a 404 routing intermediary does if it believes it needs to use the 405 location in the SIP request in order to process the message further. 407 The practical implication is that when the "routing-allowed" 408 parameter is set to "no", if an LbyV is present in the SIP request, 409 intermediaries MUST NOT view the location (because it is not 410 for intermediaries to view), and if an LbyR is present, MUST NOT 411 dereference it. UASs are allowed to view location in the SIP 412 request even when the "routing-allowed" header field parameter is 413 set to "no". 415 The default behavior when this header field parameter is not present 416 in a message is to treat the SIP request as if the parameter were 417 present and its value is set to "no". 419 This document defines the Geolocation header field as valid in the 420 following SIP requests: 422 INVITE [RFC3261], REGISTER [RFC3261], 423 OPTIONS [RFC3261], BYE [RFC3261], 424 UPDATE [RFC3311], INFO [RFC2976], 425 MESSAGE [RFC3428], REFER [RFC3515], 426 SUBSCRIBE [RFC3265], NOTIFY [RFC3265], 427 PUBLISH [RFC3903] and PRACK [RFC3262] 429 Discussing location using the PUBLISH request is out of scope 430 for this document since it is part of Presence, therefore, for 431 completeness, Table 1 shows PUBLISH is to support Location 432 Conveyance via this extension, but is not discussed further. 434 The following table extends the values in Tables 2 and 3 of RFC 3261 435 [RFC3261]. 437 Header field where proxy INV ACK CAN BYE REG OPT PRA 438 ---------------------------------------------------------------- 439 Geolocation R ar o - - o o o o 441 Header field where proxy SUB NOT UPD MSG REF INF PUB 442 ---------------------------------------------------------------- 443 Geolocation R ar o o o o o o o 445 Table 1: Summary of the Geolocation Header Field 447 The Geolocation header field MAY be included in any one of the above 448 requests by a UAC. A proxy MAY add the Geolocation header field, 449 but MUST NOT modify any pre-existing locationValue, including any 450 associated header field parameters within an existing Geolocation 451 header field value, unless one of the existing locationValues is 452 used to retarget the request towards a new destination UAS. This is 453 discussed in section 6.3. 455 [RFC3261] states message bodies cannot be added by proxies. 456 Therefore, any Geolocation header field added by a proxy MUST be in 457 the form of an location URI, in its own locationValue header field 458 value. 460 A SIP proxy MAY add a Geolocation header field if one is not 461 present, and MAY add the "routing-allowed" parameter if not yet 462 present in the SIP request. When a "routing-allowed" parameter is 463 already present in the SIP request, a SIP server MUST NOT change the 464 value of the parameter (i.e., from 'yes' to 'no', or from 'no' to 465 'yes'). This would override the policy set by an upstream SIP 466 entity (i.e., likely the UAC). 468 Adding a new locationValue to an in-transit request is NOT 469 RECOMMENDED for at least two reasons, 471 #1 SIP Servers are not the best locators geographically of where a 472 UAC is; the location information that a SIP server knows may 473 not be the best location information available. 475 #2 this document gives limited guidance as to what a Location 476 Recipient should do when receiving more than one location (no 477 instructions are given about which locationValue to use when 478 more than one is present), so adding a new locationValue may 479 lead to undesirable results. 481 Location Recipients receiving a location object, whether received 482 directly or as the result of a dereference, MUST honor the usage 483 element rules within that XML document, as defined in [RFC4119]. 484 Such entities MUST NOT alter the rule set. 486 4.2 424 (Bad Location Information) Response Code 488 This SIP extension creates a new location specific response code, 489 defined as follows. 491 424 (Bad Location Information) 493 The 424 (Bad Location Information) response code is a rejection of 494 the request due to its location contents, indicating the location 495 information was malformed or not satisfactory for the recipient's 496 purpose, or could not be dereferenced. 498 Section 4.3 creates the Geolocation-Error header field to provide 499 more detail about what was wrong with the location information in 500 the request. This header field MUST be in the 424 response, 501 containing a locationErrorValue for each invalid locationValue in 502 the request (i.e., and one-for-one matching if all locationValues 503 in the request were bad). 505 If more than one location is present in a request (LbyV or LbyR), 506 and the Location Recipient can process any of the locationValues, a 507 424 MUST NOT be sent. The 424 is only appropriate when the Location 508 Recipient needs a locationValue and there are no locationValues 509 included in a SIP request that are usable by a recipient. 511 A 424 (Bad Location Information) response is a final response within 512 a transaction, and does not terminate an existing dialog. 514 The UAC can use whatever means it knows of to verify/refresh its 515 location information before attempting a new request that includes 516 location. There is no cross-transaction awareness expected by either 517 the UAS or any SIP intermediary as a result of this error message. 518 The new 424 (Bad Location Information) error code is registered with 519 IANA in Section 8 of this document. An initial set of 520 IANA-registered Geolocation-Error codes are in Section 4.3 of this 521 document. 523 4.3 The Geolocation-Error Header Field 525 As discussed in Section 4.2, more granular error notifications, 526 specific to location errors within a received request, are required 527 if the UAC is to know what was wrong within the original request. 528 The Geolocation-Error header field is used for this purpose. 530 The Geolocation-Error header field is used to convey 531 location-specific errors within a response. Additional 532 IANA-registered values must be defined in an RFC (this is the "RFC 533 Required" IANA policy defined in [RFC5226]). The Geolocation-Error 534 header field has the following ABNF [RFC5234]: 536 Geolocation-Error = "Geolocation-Error" HCOLON 537 locationErrorValue 538 *(COMMA locationErrorValue) 539 locationErrorValue = location-error-code *(SEMI 540 location-error-params) 541 location-error-code = 1*3DIGIT 542 location-error-params = location-error-node-id 543 / location-error-host-id 544 / location-error-code-text 545 / generic-param ; from RFC3261 546 location-error-node-id = "node" EQUAL 547 DQOUTE hostport DQOUTE ; from RFC3261 548 location-error-host-id = "inserter" EQUAL 549 DQOUTE hostport DQOUTE ; from RFC3261 550 location-error-code-text = "code" EQUAL quoted-string ; from RFC3261 552 The Geolocation-Error header field MUST contain at least one 553 locationErrorValue to indicate what was wrong with the locationValue 554 in the corresponding request the Location Recipient determined was 555 bad. Each locationErrorValue contains a 3-digit error code 556 indicating what was wrong with the location in the request. Each 557 error type has a corresponding quoted error text string that is 558 human understandable. 560 Each locationErrorValue contains the Location Recipient identifier 561 (the "node=" parameter) which experienced the location error, as 562 well as an identifier of which SIP entity (the "inserter=" 563 parameter) the Location Recipient is told (in the locationValue) 564 added this problematic locationValue to the request. The "node=" 565 and "inserter=" are the domain identifier of a SIP entity, with the 566 ability to have the same host communicate on different ports - and 567 have port specific identification. This is the same information that 568 would be entered in the "sent-by" parameter of the Via header field 569 for that entity [RFC3261]. As stated in section 18 of RFC 3261, 570 the usage of FQDN is RECOMMENDED. Here are examples of both 571 locationErrorValue parameters, 573 node="bob.example.com" 575 inserter="alice.example.com" 577 Both the "node=" and "inserter=" parameters MUST be present in all 578 locationErrorValues in a response, unless the locationValue of the 579 request did not include the "inserted-by=" parameter (which is a 580 violation of this document). The "inserter=" parameter value is 581 copied from the "inserted-by=" parameter within the locationValue of 582 the request. 584 This is required because a Location Recipient that experienced a 585 problem with the location included in a request needs to tell the 586 specific SIP entity which added the locationValue in error into the 587 original request. Since more than one SIP entity can insert 588 location into a request in transit, all other SIP elements may be 589 confused by receiving this error header field, were it to remain 590 generic to all entities in the response path. This requirement 591 means that the header field identifies the Location Inserter who 592 inserted the problematic locationValue, so that all other SIP 593 entities that read the header field know to ignore it. This is of 594 particular use if the original UAC did not include a locationValue 595 in the original SIP request, but a SIP server along the path did 596 insert a locationValue. The locationErrorValue would be interpreted 597 by each SIP entity along the original path upstream and be processed 598 by both the server that included the invalid locationValue and the 599 UAC that did not, resulting in confusion at the UAC. 601 A worse case is when both the original UAC and a SIP server along 602 the path included a locationValue, but there was something 603 wrong with only one of the locationValues. Without an 604 identification of the specific locationValue in error, both entities 605 would react, and one would react incorrectly. 607 When more than one locationErrorValue is present in a 608 Geolocation-Error header field, they are separated by commas. 610 If more than one locationErrorValue is present in a response, and 611 intended for the same "inserter=", each error code MUST be unique to 612 this "inserter=" entity, and the error codes MUST NOT conflict in 613 meaning. 615 Here is an example of a Geolocation-Error header field: 617 Geolocation-Error: 200; code="Retry Location Later"; 618 node="bob.example.com"; 619 inserter="alice.example.com"; 621 The following table extends the values in Table 2&3 of RFC 3261 622 [RFC3261]. 624 Header field where proxy INV ACK CAN BYE REG OPT PRA 625 ---------------------------------------------------------------- 626 Geolocation-Error r ar o - - o o o o 628 Header field where proxy SUB NOT UPD MSG REF INF PUB 629 ---------------------------------------------------------------- 630 Geolocation-Error r ar o o o o o o o 632 Table 2: Summary of the Geolocation-Error Header Field 634 The Geolocation-Error header field MAY be included in any response 635 to one of the above SIP requests, so long as Geolocation was in the 636 request part of the transaction. For example, Alice includes her 637 location in an INVITE to Bob. Bob can accept this INVITE, thus 638 creating a dialog, even though his UA determined the location 639 contained in the INVITE was bad. There is a Geolocation-Error 640 header value in the 200 OK to the INVITE informing Alice the INVITE 641 was accepted but the location provided was bad. The SIP requests 642 included in table 2 above are the ones allowed to optionally contain 643 the Geolocation header field (see section 4.1). That said, a UAC 644 MUST ignore a Geolocation-Error header field value that did not 645 contain its host-id.. 647 Here is an example of a transaction that has a location error. In 648 this case, Bob responds with a 424 (Bad Location Information) 649 response, including a Geolocation-Error header field, is in Figure 3. 651 Alice Bob 652 | | 653 | Request w/ Location | 654 |------------------------------------------------>| 655 | | 656 | | 657 | 424 (Bad Location Information) | 658 | with Geolocation-Error containing | 659 | 200 ("Retry Location Later with same data") | 660 |<------------------------------------------------| 661 | | 663 Figure 3. Basic Transaction with 424 and Geolocation-Error Header 664 Field 666 The following subsections provide an initial list of location 667 based errors for any SIP non-100 response, including the new 424 668 (Bad Location Information) response. These error codes are divided 669 into 5 categories, based on how the response receiver should react 670 to these errors. 672 o 1XX "Cannot Process Location" 674 o 2XX "Retry Location Later with same data" 676 o 3XX "Retry Location Later with updated device location" 678 o 4XX "Permission To Reveal Location Information to a Third Party" 680 o 5XX "Location Information Denial" 682 All 5 of the above error codes MUST be implemented to comply with 683 this specification. Each of these actionable errors is given a 3 684 digit error code category, meaning any future 1XX, 2XX, 3XX, 4XX, 685 and 5XX error codes defined will have the same action expected by 686 X00 categories, although the future error code may provide more 687 granular information. If another action is expected to occur with a 688 newly defined error code, it MUST outside the 100-599 range. 690 4.3.1 Location Error: 100 "Cannot Process Location" 692 The location error 100 "Cannot Process Location" indicates to a 693 Geolocation-Error recipient that the locationValue supplied in a 694 request cannot be processed at this time. This only has to do with 695 the location that the location "inserter=" added to the request, and 696 not about the overall request that was sent. 698 Action(s) to be taken by Geolocation-Error receiver for a 1XX: 699 This error gives no guidance on what to do next. It is a 700 general information indication to a SIP "inserter=" entity 701 that there was an unspecific problem with the location 702 supplied in the SIP request. 704 Implementations MAY choose to react as if the "inserter=" 705 entity received a 2XX or 3XX location error. Implementations MUST 706 NOT react as if the "inserter=" entity received a 4XX location 707 error, as that error category involves human intervention to grant, 708 or not, permission to reveal "inserter=" location when this is 709 likely not desired. 711 The text string of "Cannot Process Location" is RECOMMENDED, but not 712 mandatory for usage in this error. Implementations MAY use another 713 text string. 715 An example 100 location error is: 717 Geolocation-Error: 100; code="Cannot Process Location"; 718 node="bob.example.com"; 719 inserter="alice.example.com"; 721 This category covers all 1XX location errors. The same basic 722 reaction is expected when a location "inserter=" entity receives any 723 1XX location error. 725 4.3.2 Location Error: 200 "Retry Location Later same data" 727 The location error 200 "Retry Location Later same data" indicates 728 to a Geolocation-Error recipient that what they supplied in a 729 request, as far as location is concerned, cannot be processed at 730 this time, but there is no need to update the location at a later 731 time in a new SIP request. For example, this location error is 732 appropriate when the Location Recipient cannot process location at a 733 specific time, or when there is there was a timeout when a location 734 URI is dereferenced. 736 Action(s) to be taken by Geolocation-Error receiver for a 2XX: 737 Reactions to a 2XX location error are to try again after some 738 period of time has elapsed. The "inserter=" has not identified 739 problems with the location provided in the original request, 740 so there is no need to update this location unless the 741 requestor moves. A Retry-After header field MUST be present in 742 the 424 response indicating after how long the LR thinks it 743 can process the location, the error recipient MUST obey this 744 instruction. 746 Implementations SHOULD choose to react by queuing another message 747 with the same location information, unless the "inserter=" entity 748 knows it has changed locations. 750 Implementations MAY inform the user of this error. The text string 751 of "Retry Location Later same data" is RECOMMENDED, but not 752 mandatory for this error. Implementations MAY use another text 753 string to inform the user that location was not received by the UAS 754 (i.e., the called party). 756 An example 200 location error is: 758 Geolocation-Error: 200; code="Retry Location Later same data"; 759 node="bob.example.com"; 760 inserter="alice.example.com"; 762 This category covers all 2XX location errors. The same basic 763 reaction is expected when a location "inserter=" entity receives any 764 2XX location error. 766 If a SIP request has the "routing-allowed" header field parameter 767 set to "no", and the SIP server believes processing location is 768 required in order to service the request properly, a 2XX location 769 error is sent towards the recipient. This error is the proper error 770 even when there is no location in the SIP request, but the SIP 771 request contains a policy statement that location is not to be 772 viewed during transit towards the ultimate destination. 774 4.3.2.1 Location Error: 201 "Linkable Target Identity Required" 776 The error code 201 "Linkable Target Identity Required" is 777 specifically for the event in which a SIP request requires a binding 778 of the Target's identity to the presence document in order to know 779 this is the Target's location to make an appropriate routing 780 decision. Because Alice could include Bob's location in her SIP 781 request, the SIP server - in this specific case - needs to 782 understand this message is routed based on Alice's location, and not 783 Bob's. There is no absolute binding between presence documents and 784 SIP signaling, hence a separate error with specific behaviors are 785 necessary. 787 It is of particular importance is the emergency calling case, 788 described here [ID-PHONE]. The presence document has a 789 element containing an "entity=" attribute identifying who the 790 presence document is about. The PIDF-LO is a presence document. 791 [RFC3693] allows unlinkable pseudonyms to be in the "entity=" 792 attribute. This is problematic for some (all?) source location based 793 call routing situations. 795 The node= routing intermediary makes this locationErrorValue a 201 796 to resolve this problem. In the 424 response, the Retry-After header 797 value of '0' is REQUIRED, indicating the new request be sent 798 immediately, but with a target identification resolved in the 799 PIDF-LO and SIP request. In presence, the entity= attribute is 800 typically the URI of the presentity, meaning something like the 801 Contact address of the UAC here. 803 If there is no Retry-After header value, the default is to resend 804 the SIP request immediately with the corrected entity= attribute 805 (i.e., emulating a Retry-After: 0 header value). 807 Action(s) to be taken by Geolocation-Error receiver for a 201: 809 201 location error indicate the "inserter=" did not properly 810 identify the Target of this presence document. The 811 Retry-After has been received - or is assumed to be 0 - 812 meaning the new SIP request is to be sent immediately. 814 4.3.3 Location Error: 300 "Retry Location Later with device updated 815 location" 817 The location error 300 "Retry Location Later with device updated 818 location" indicates to a Geolocation-Error recipient that what they 819 supplied in a request, as far as location is concerned, cannot be 820 processed. In order to retry this request in a new SIP request, the 821 location information must be updated. 823 Action(s) to be taken by Geolocation-Error receiver for a 3XX: 825 3XX location errors indicate the "inserter=" SIP entity needs 826 to refresh its location, or make the location information 827 supplied more complete, without notifying the user of this 828 error. 3XX errors may be resolved without user intervention. 830 This document gives no guidance how this is accomplished, given the 831 number of ways a UAC can learn its location, or a SIP intermediary 832 can Sight a UAC, as defined in [RFC3693]. 834 This 300 location error currently does not indicate what exactly was 835 wrong with the location supplied, according to the Location 836 Recipient. That is left for a future effort. 838 Implementations MAY choose whether or not to inform the user of this 839 error. The text string of "Retry Location Later with device updated 840 location" is RECOMMENDED, but not mandatory for usage in this 841 error. Implementation MAY use another text string to inform the 842 user that location was not received by the UAS (i.e., the called 843 party). 845 A 3XX location error would be used where the Location Recipient 846 cannot find or cannot parse the location supplied. 3XX location 847 errors should cause a requestor to retry with refreshed location 848 information, which might be sufficient to fix the problem. Also, a 849 3XX location error would be used when a Location Recipient was 850 expecting to find location in a SIP request, but did not find it - 851 perhaps an emergency request was made that did not contain location. 852 The retry in this case would be in the form of an UPDATE Method 853 request, containing location. If the 424 response contains a 854 Retry-After value, there SHOULD NOT be a long delay associated with 855 a new request - under the guise that if the location had been good, 856 there would not have been an error to this request. 858 An example 300 location error is: 860 Geolocation-Error: 300; code="Retry Location Later with device 861 updated location"; 862 node="bob.example.com"; 863 inserter="alice.example.com"; 865 This category covers all 3XX location errors. The same basic 866 reaction is expected when a location "inserter=" entity receives any 867 3XX location error. 869 4.3.4 Location Error: 400 "Permission to Reveal Location Information to 870 a Third Party" 872 The location error 400 "Permission to Reveal Location Information to 873 a Third Party" indicates to a Geolocation-Error recipient that they 874 sent a particular SIP Request including location in that request, 875 without giving permission in the request for an intermediary SIP 876 entity to look at that location information (i.e., the 877 was set to "no" in the PIDF-LO for B2BUAs, 878 or "routing-allowed=no" as a Geolocation header field parameter for 879 proxy servers) to route the request toward the intended recipient 880 (i.e., the UAS, or the called party). 882 Action(s) to be taken by Geolocation-Error receiver for a 4XX: 884 4XX location errors indicate to the UAC (i.e., the calling 885 party) that they need to grant permission to a SIP 886 intermediary server to look at the supplied location to 887 complete the message routing. This indication MUST require 888 human user intervention, acting as the ruleholder of the 889 policy on whether or not location is to be revealed. 891 The user of the location "inserter=" device can choose to grant 892 permission to this SIP intermediary server to allow this request to 893 be routed, or the user can deny permission. It is the user's choice 894 as ruleholder. 896 Implementations MUST provide the user, as ruleholder, a clear 897 indication that permission to consume their location is sought by an 898 entity that is not the entity that the user is calling. The text 899 string of "Permission To Reveal Location Information to a Third 900 Party" is RECOMMENDED, but not mandatory for usage in this error. 901 Implementations MAY use another text string to inform the user that 902 location is being sought by an intermediary (i.e., not the called 903 party). 905 This document gives no guidance how the UAC can seek permission from 906 the user, given the number of ways a UAC can accomplish this (i.e., 907 audio prompt or toggle or keystroke on a UA). 909 This 400 location error indicates exactly which SIP server indicates 910 that it needs the location by the "node=" FQDN address supplied, 911 perhaps telling the user (via audio or video indication) which SIP 912 entity wants this location. Perhaps the user can know in some 913 circumstances whether this is an appropriate "node=" (domain). This 914 latter feature is not described in this document. 916 An example 400 location error is: 918 Geolocation-Error: 400; code="Permission to Reveal Location 919 Information to a Third Party"; 920 node="bob.example.com"; 921 inserter="alice.example.com"; 923 This category covers all 4XX location errors. The same resolution 924 is expected to be afforded to the UAC user, as ruleholder, to any 925 4XX location error. 927 4.3.5 Location Error: 500 "Location Information Denial" 929 The location error 500 "Location Information Denial" indicates to a 930 Geolocation-Error recipient that what they supplied in a request, as 931 far as location is concerned, has been denied at this time. 932 This only has to do with the location that the location "inserter=" 933 added to the request, and not about the overall request that was 934 sent. If this were applied to the SIP request itself, this would 935 equate to a 6XX Global error. 937 Action(s) to be taken by Geolocation-Error receiver for a 5XX: 938 This error gives no guidance on what to do next, other than to 939 not try again with this same location supplied. 941 If the Location Recipient determined that merely refreshing, or in 942 some other way alter or augment the location supplied would work in 943 a new request, then a 3XX location error would have been more 944 appropriate. An example of why this 5XX could have been returned is 945 if location were sent as a location URI, and the LS denied the 946 dereference request from the potential Location Recipient, this is 947 the expected location error returned to the "inserter=" entity. In 948 all likelihood, this is a dereference function error, meaning this 949 will not occur when location is carried by-value in the request. 951 Implementations MUST NOT make any assumptions about the implications 952 of this location error other than recognizing that a location based 953 denial error has occurred. This does not mean the SIP request was 954 denied, or even had an error, unless the response was a 424. 955 Otherwise, this only has to do with the location part of the 956 request. 958 The difference between a 1XX and a 5XX location error is simple. A 959 1XX location error is appropriate when a Location Recipient either 960 does not know or cannot tell the "inserter=" entity what was wrong 961 with the location supplied in a SIP request. A 5XX location error 962 is appropriate when the Location Recipient was purposely and 963 actively prevented from retrieving the location information. This 964 could occur in a UAS or SIP server. 966 If implementations choose to inform the UAC user of this error, the 967 text string of "Location Information Denial" is RECOMMENDED, but not 968 mandatory for usage in this error. Implementations MAY use another 969 text string. 971 An example of this location error is here: 973 Geolocation-Error: 500; code="Location Information Denial"; 974 node="bob.example.com"; 975 inserter="alice.example.com"; 977 This category covers 5XX location errors. The same basic reaction 978 is expected when a location "inserter=" entity receives any 5XX 979 location error. 981 4.3.6 Which Scenario Matches Which Error Code? 983 The following scenario/error code mapping MUST be used for 984 consistency, 986 - Scheme (sip:, or sips:, or pres:, etc.) of the location URI 987 isn't supported - (100) 988 - Format (geo or civic) isn't supported - (100) 989 - Found where location should be, but do not understand what is 990 there -(300) 991 - Cannot find LS in location URI (no access or no path) - (100) or 992 denied access - (500)) 993 - Dereference failed (timeout) - (200) 994 - Insufficient location info supplied - (300) 996 4.4 The 'geolocation' Option Tag 998 This document creates and IANA registers one new option tag: 999 "geolocation". This option tag is to be used, as defined in 1000 [RFC3261], in the Require, Supported and Unsupported header fields. 1002 4.5 Using sip/sips/pres as a Dereference Scheme 1004 If an LbyR URI is included in a SIP request, it MUST be a SIP-, 1005 SIPS- or PRES-URI. When PRES: is used, if the resulting resolution, 1006 as defined in [RFC3856], resolves to a SIP: or SIPS: URI, this 1007 section applies. 1009 This document IANA registers 3 mandatory-to-implement URI schemes 1010 for LbyR: 1012 o SIP: 1013 o SIPS: 1014 o PRES: 1016 These 3 are registered with IANA in Section 9.6. 1018 These schemes MUST be implemented according to this document. 1020 absoluteURI is not mandatory-to-implement. 1022 Dereferencing a Target's location using SIP- or SIPS-URI is 1023 accomplished by treating the URI as a PRES-URI and generating a 1024 SUBSCRIBE request to a presence server as defined in [RFC3856] 1025 using the 'presence' event package. The resulting NOTIFY MUST 1026 contain a PIDF-LO. See Figure 4 for a basic message flow for a 1027 dereference. The NOTIFY contains Alice's PIDF-LO in Figure 4. 1029 When used in this manner, SIP is a Using Protocol as defined in 1030 [RFC3693] and elements receiving location MUST honor the 1031 'usage-element' rules as defined in this specification. 1033 Alice Location Server Bob 1034 | | 1035 | INVITE w/ Location URI | 1036 |-------------------------------------------------------->| 1037 | | | 1038 | 200 (OK) | 1039 |<--------------------------------------------------------| 1040 | | | 1041 | | SUBSCRIBE to location URI | 1042 | |<-----------------------------| 1043 | | 200 (OK) | 1044 | |----------------------------->| 1045 | | | 1046 | | NOTIFY w/ PIDF-LO | 1047 | |----------------------------->| 1048 | | 200 (OK) | 1049 | |<-----------------------------| 1050 | | | 1052 Figure 4. Location-by-Reference and Dereferencing 1054 In Figure 4, Alice sends Bob her location in a location URI. Bob 1055 receives this location URI in the INVITE and generates a new 1056 transaction (SUBSCRIBE) to retrieve Alice's PIDF-LO. If accepted, 1057 the PIDF-LO will be returned in the NOTIFY request from the Location 1058 Server to Bob's UA. This is the first instance between Alice and 1059 Bob that Alice's location is in any message, therefore it is sent 1060 only once, from the Location Server to Bob. 1062 The SUBSCRIBE contains a geolocation option tag in either the 1063 Supported or Require header field (depending on what strength of 1064 support the UAC requires). The NOTIFY MUST match the subscribing 1065 UAC's option-tag strength for geolocation. 1067 A dereference of an LbyR URI using SUBSCRIBE is not violating a 1068 PIDF-LO 'retransmission-allowed' element value set to 'no', as the 1069 NOTIFY is the only message in this multi-message set of transactions 1070 that contains the Target's location, with the location recipient 1071 being the only SIP element to receive this PIDF-LO. This is the 1072 purpose of this extension to SIP - to convey location to a specific 1073 destination. 1075 5. Geolocation Examples 1077 This section contains are two examples of messages providing 1078 location. One shows LbyV with coordinates, the other shows 1079 dereferencable location URI. The example for (Coordinate format) is 1080 taken from [RFC3825]. A Civic-format example of the same position on 1081 the earth as is in the coordinate format example is in appendix B, 1082 which is taken from [RFC4776]. The differences between the two 1083 formats appear within the in the examples. Other 1084 than this portion of each PIDF-LO, the rest is the same for both 1085 location formats. 1087 The key to the provided samples is in the Geolocation header field, 1088 which has a different type of URI, based on the different means of 1089 location conveyance. Section 5.1 shows a "cid:" URI, indicating 1090 this SIP request contains an LbyV message body - which is in the 1091 form of a PIDF-LO. Section 5.2 shows an LbyR URI indicating 1092 location is to be acquired via an indirection dereference mechanism, 1093 which is determined by the scheme of URI supplied. 1095 5.1 Location-by-value (Coordinate Format) 1097 This example shows an INVITE message with a coordinate location. In 1098 this example, the SIP request uses a sips-URI [RFC3261], meaning 1099 this message is protected using TLS on a hop-by-hop basis. 1101 INVITE sips:bob@biloxi.example.com SIP/2.0 1102 Via: SIPS/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bK74bf9 1103 Max-Forwards: 70 1104 To: Bob 1105 From: Alice ;tag=9fxced76sl 1106 Call-ID: 3848276298220188511@atlanta.example.com 1107 Geolocation: 1108 ;inserted-by="alice@atlanta.example.com" 1109 ;routing-allowed=no 1110 Supported: geolocation 1111 Accept: application/sdp, application/pidf+xml 1112 CSeq: 31862 INVITE 1113 Contact: 1114 Content-Type: multipart/mixed; boundary=boundary1 1115 Content-Length: ... 1117 --boundary1 1119 Content-Type: application/sdp 1121 ...SDP goes here 1122 --boundary1 1124 Content-Type: application/pidf+xml 1125 Content-ID: 1126 1127 1132 1133 1134 2009-07-13T09:00:00Z 1135 1136 1137 1138 1139 33.001111 -96.68142 1140 1141 1142 1143 1144 no 1145 2009-07-29T18:00:00Z 1147 1148 802.11 1149 a 1150 1151 1152 1153 --boundary1-- 1155 The Geolocation header field from the above INVITE: 1157 Geolocation: 1159 ... indicates the content-ID location [RFC2392] within the multipart 1160 message body of where location information is, with SDP being the 1161 other message body part. The "cid:" eases message body parsing. 1163 If the Geolocation header field did not contain a "cid:" scheme, for 1164 example, like this location URI: 1166 Geolocation: 1168 ... the existence of a non-"cid:" scheme indicates this is a 1169 location URI, to be dereferenced to learn the target's location. Any 1170 node wanting to know where user "target123" is would subscribe to 1171 server5 to dereference the sips-URI (see Figure 4 for this message 1172 flow, and Section 5.2 for this decoded example). The returning 1173 NOTIFY would contain Alice's location in a PIDF-LO, as if it were 1174 included in a message body (part) of the original INVITE. 1176 5.2 Location-by-reference 1178 Below is an INVITE request with a location URI that is not a "cid:" 1179 - instead of an LbyV PIDF-LO message body part as shown in Section 1180 5.1. The Location Recipient will dereference Alice's location at 1181 the Atlanta Location Server the location URI is pointing towards. 1182 Dereferencing, if done using SIP, is accomplished by the Location 1183 Recipient sending a SUBSCRIBE request to the URI reference for 1184 Alice's location. The received NOTIFY is the first SIP request 1185 containing Alice's UA location, as a PIDF-LO message body (see 1186 Figure 4 for this message flow example). The NOTIFY, in this case, 1187 and not the INVITE, is the SIP request that is conveying location. 1188 There is no retransmission of location in this usage. 1190 INVITE sips:bob@biloxi.example.com SIP/2.0 1191 Via: SIP/2.0/TLS pc33.atlanta.example.com 1192 ;branch=z9hG4bK74bf9 1193 Max-Forwards: 70 1194 To: Bob 1195 From: Alice ;tag=9fxced76sl 1196 Call-ID: 3848276298220188511@atlanta.example.com 1197 Geolocation: 1198 ;inserted-by="bigbox3.atlanta.example.com" 1199 ;routing-allowed=no 1200 Supported: geolocation 1201 Accept: application/sdp, application/pidf+xml 1202 CSeq: 31862 INVITE 1203 Contact: 1205 (...SDP goes here as the only message body) 1207 A Location Recipient would need to dereference the sips-URI in the 1208 Geolocation header field to retrieve Alice's location. If the 1209 atlanta.example.com domain chooses to implement location conveyance 1210 and delivery in this fashion, it is RECOMMENDED that entities 1211 outside this domain be able to reach the dereference server, unless 1212 location is intentionally restricted within the atlanta.example.com 1213 domain. 1215 6. SIP Element Behavior 1217 Because a device's location is generally considered to be sensitive 1218 in nature, location information needs to be protected when 1219 transmitted. This can be addressed through securing the location 1220 information to prevent either viewing or changing the PIDF-LO. 1222 Section 26 of [RFC3261] defines the SIPS security functionality by 1223 transporting SIP messages with either TLS protection between SIP 1224 entities. 1226 If a SIP entity wants to prevent all SIP entities in a request path 1227 that do not possess a decryption key from viewing or changing the 1228 contents of the PIDF-LO, the message body needs to be secure by a 1229 means such as S/MIME. 1231 6.1 UAC Behavior 1233 A UAC might choose to send location in a SIP request to facilitate 1234 location-based routing of the request, or for some other purpose. 1235 Alice communicating her location to Bob in a SIP request is a simple 1236 example of this. If Alice wanted to include her location as a 1237 message body in an INVITE that also has an SDP message body, the 1238 Content-Type: Multipart MUST be supported by both UAC and UAS. 1239 Multipart comes in many forms (/mixed, /alternative, etc), and this 1240 document does not limit which type of multipart is used, though 1241 future documents might specify or limit multipart to a subset of 1242 all the choices for a given use. 1244 A UAC conveying location MUST include a locationValue in a 1245 Geolocation header (see section 4.1) with either an LbyV indication 1246 (a cid-URL), or a dereferencable location URI. Requests containing 1247 an LbyV message body sent MUST also contain a Geolocation header 1248 field. The UAC supporting this extension MUST include a Supported 1249 header with the 'geolocation' option tag. 1251 More than one location format (civic and coordinate) can be included 1252 in the same message body part, but all location parts of the same 1253 PIDF-LO MUST point at the same position on the earth, identifying 1254 the same target. The same location in multiple formats, for 1255 example, a partial or complete geodetic and a partial or complete 1256 civic, allows the recipient to select the most preferred format for 1257 its use. Additional complementary location information can be in 1258 the second format as well. 1260 Multiple PIDF-LOs are allowed in the same request, with each allowed 1261 to point at separate positions - however, each PIDF-LO MUST identify 1262 a different Target (i.e., in the entity= attribute in the 1263 element of the presence document). Therefore, there will be no 1264 confusion by a Location Recipient receiving more than one PIDF-LO 1265 (in a message body or when dereferenced, or a combination). A SIP 1266 request SHOULD include only one location per target in a single SIP 1267 request. More than one will likely lead to confusion by a Location 1268 Recipient because this extension does not provide guidance on what a 1269 recipient is to do with more than one location for the same target 1270 (which could point to different positions), nor does it give any 1271 preference regarding which location is more or less reliable than 1272 another location in the same request. 1274 The presence of the 'geolocation' option tag in a Supported header 1275 field without a Geolocation header field in the same message informs 1276 a SIP element receiving this request that the UAC understands this 1277 extension, but it does not know or wish to convey its location at 1278 this time. Certain scenarios exist (location-based retargeting) in 1279 which location is required in a SIP request in order to retarget the 1280 message properly. Indicating support with a geolocation option tag 1281 affects how a UAS or SIP server processes such a request. For 1282 example, it ought to understand that erroring the request because 1283 there was no location in the request is likely not going to result 1284 in the location appearing in the subsequent request. 1286 The 'geolocation' option tag SHOULD NOT be used in the Proxy-Require 1287 header field, because often the UAC will not know the underlying 1288 topology to know which proxy will do the retargeting, thus 1289 increasing the likelihood of a request failure at the first hop 1290 proxy that does not understand this extension, as is required by 1291 inclusion of the option tag in this header field. 1293 A UAC inserting a locationValue MUST include an "inserted-by=" 1294 parameter to indicate its hostport. This is copied to the 1295 "inserter=" parameter of the Geolocation-Error header field in a 1296 response if a Location Recipient determines there is something wrong 1297 with the locationValue in this request. Because more than one 1298 locationValue can be inserted along the path of the request, this 1299 indication is necessary to show which locationValue had the problem 1300 in the response, and who the locationErrorValue is for. For 1301 example: 1303 Geolocation: ; 1304 inserted-by="alice@atlanta.example.com" 1306 If a UAC does not learn and store its location locally (a GPS chip) 1307 or from the network (DHCP or LLDP-MED), the UAC MAY learn its 1308 location URI (from DHCP for example). If the latter is the case, 1309 the UAC can SUBSCRIBE to this location URI, using the 'presence' 1310 event package, to get and store its own location. 1312 The Location Server will likely challenge requests to dereference a 1313 Target's location URI. The location URI SHOULD be treated as 1314 equivalent to possession of the location information itself and thus 1315 TLS SHOULD be used when transmitting any location URI hop-by-hop 1316 along the path to the Location Recipient, for protection reasons. 1317 This is not to be confused with a 'possession model', in which 1318 possessing the location URI grants authorization to dereference the 1319 URI. Any entity dereferencing the location URI MUST pass whatever 1320 authentication and authorization rules are on the LS to acquire this 1321 location. The Ruleholder from [RFC3693] is still very much in 1322 control - for any entity possessing the LbyR. 1324 If the Location Generator wishes to control whether any location 1325 included in the SIP request or added along the signaling path of 1326 this request can be viewed for routing decisions, the Location 1327 Generator adds a Geolocation header field value including the 1328 "routing-allowed=no" parameter. This header field parameter 1329 provides specific policy rules for each locationValue (if more than 1330 one locationValue is inserted along the signaling path) within the 1331 SIP request. A UAC SHOULD include the "routing-allowed" header 1332 field parameter, with or without a locationValue, to each SIP 1333 request supporting this specification to ensure the UAC's policy for 1334 intermediaries which might add a locationValue of the Target 1335 downstream. The default behavior for SIP servers is to consider 1336 this value to be present, with a value of "no". 1338 There is no feedback mechanism to inform the Target if a SIP server 1339 has included a locationValue downstream. If a UAC has already 1340 conveyed location in the original request of a transaction, and 1341 wants to update its location information (for whatever reason) after 1342 the original request is sent, or after a dialog is created, this is 1343 done by sending an UPDATE request [RFC3311]. The UPDATE will include 1344 a geolocation option tag and Geolocation header field with the new 1345 locationValue to the original destination UAS. 1347 A presence document includes identity information (in the "entity=" 1348 attribute of the element), although the identity could be 1349 an unlinkable pseudonym [RFC3693]. Implementations of this 1350 extension SHOULD consider the appropriateness of including an 1351 unlinkable pseudonym as the identity in the location information 1352 where a real identity is not required. See the concerns raised in 1353 section 4.3.2 about unlinkable pseudonyms in relation to their 1354 potential problems with requests that need to route based on the 1355 location contained in the message. 1357 When using LbyR, the location URI MUST NOT contain any user 1358 identifying information. For example, use something unidentifiable 1359 like 1361 3fg5T5yqWowhGLn54wg4NgHlkDsFn@example.atlanta.com 1363 rather than 1365 aliceishere@example.atlanta.com). 1367 Use of self-signed certificates is inappropriate for use in 1368 protecting a PIDF, as the sender does not have a secure identity of 1369 the recipient. 1371 Although this is discussed in more detail in later in section 6.2, 1372 SIP entities MUST NOT bypass rules and behaviors conveyed in a 1373 PIDF-LO. UACs SHOULD take care when setting their 1374 flag to "yes". When Alice tells Bob her 1375 location with this flag set to "yes", Bob is free to tell Carol 1376 where Alice is (as long as the time has not 1377 elapsed, indicating that the location information should be 1378 deleted). This is an implicit byproduct of the PIDF-LO rule-set, as 1379 of this writing. This decision is a configuration issue, but is 1380 worth mentioning here. 1382 6.1.1 UAC Receiving a Location Failure Indication 1384 Location Recipients that use the location information for 1385 location-based routing decisions can be either destination UASs or 1386 intermediate servers. If a request fails based on the location 1387 information in the request, a 424 (Bad Location Information) 1388 response is sent back to the UAC. The 424 MUST have a 1389 Geolocation-Error header field containing one or more 1390 locationErrorValues in the response message. A locationErrorValue 1391 has a header field parameter indicating which entity inserted the 1392 locationValue correlated to this error, called the "inserter=" 1393 parameter. This "inserter=" parameter (in the locationErrorValue) 1394 is copied from the "inserted-by=" parameter (from the locationValue) 1395 by the Location Recipient (UAS or proxy) sending the error response. 1396 A UAC receiving a Geolocation-Error in any response type MUST check 1397 whether the "inserter=" parameter in the locationErrorValue 1398 indicates this UAC. 1400 o If locationErrorValue does not match, the locationErrorValue 1401 MUST be ignored. 1403 o If a locationErrorValue is in a 424, and the "inserter=" entity 1404 is not this UAC, the response SHOULD be treated as a 400 1405 response. 1407 o If locationErrorValue does indicate this UAC, this UAC MUST 1408 process the response, including the Geolocation-Error code 1409 (defined in section 4.3), taking the action described in that 1410 section for the received error code. 1412 Additionally, the UAC MUST ignore a Geolocation-Error header field 1413 value, even for this UAC, even in a 424 response if the UAC did not 1414 include a Geolocation header field value (with locationValue) in the 1415 request part of the transaction. 1417 A UAC MAY reattempt a new request if it can correct the stated 1418 failure in the Geolocation-Error header field, unless the location 1419 error is a 5XX level error - Section 4.3 clearly states not to do 1420 this. A UAC MUST follow all the guidance that pertains to UACs from 1421 Section 4.3 (Geolocation-Error Header Field), heeding what to do 1422 when it receives any of the error codes articulated in that section. 1424 Any UAC that inserted location into a request MUST be prepared to 1425 receive the Geolocation-Error header field in any response, looking 1426 to determine if a locationErrorValue is meant for the UAC, and to 1427 react accordingly. 1429 If a UAC includes location in a request, and either the UAS does not 1430 determine errored location was critical to the transaction and 1431 accept the request, or the request failed for reason other than 1432 location, any response MAY contain a Geolocation-Error header field 1433 containing a locationErrorValue with the details of the location 1434 error. 1436 6.2 UAS Behavior 1438 If the Geolocation header field is present in a received SIP 1439 request, the type of URI contained in the locationValue will 1440 indicate if location is in a message body (part) or requires an 1441 additional dereference transaction. If the location URI is sip:, 1442 sips: or pres:, and the UAS wants to learn the UAC's location, the 1443 UAS MUST SUBSCRIBE to the provided URI to retrieve the PIDF-LO being 1444 conveyed by the UAC as defined in [RFC3856]. If successful, the 1445 Target's PIDF-LO will be returned in the NOTIFY request from the 1446 remote host. The UAS is not REQUIRED to dereference the location 1447 URI if location is not needed to process the request. It is 1448 RECOMMENDED the UAS display the location to the user, or otherwise 1449 render the location appropriately. 1451 A Require header field with the 'geolocation' option tag indicates 1452 the UAC requires that the UAS understand this extension, sending an 1453 error response if it does not. A 420 (Bad Extension) with a 1454 'geolocation' option tag in an Unsupported header field would be the 1455 appropriate response in this case. 1457 It is possible, but undesirable, for a message to arrive with a body 1458 containing an LbyV, but with no Geolocation header field value 1459 pointing to it (potentially no Geolocation header field at all). In 1460 this case, the recipient MAY still read and use the message body. 1461 Unless stated otherwise by future standards-track publication(s), a 1462 location URI only has meaning within the Geolocation header field 1463 and MUST NOT appear in any other SIP header field. 1465 There are 3 Geolocation header field parameters, 1467 o "inserted-by=" 1468 o "used-for-routing" 1469 o "routing-allowed" 1471 The "inserted-by=" parameter informs a Location Recipient which SIP 1472 entity added this locationValue to the SIP request. This parameter 1473 is mandatory for each locationValue in the request. The value in 1474 the "inserted-by=" parameter is copied into the "inserter=" 1475 parameter in each locationErrorValue if there is an error in the 1476 location to be reported back to the location sender. See section 1477 6.2.1. 1479 The "used-for-routing" parameter is included in the locationValue if 1480 a SIP server used the location in the request to determine how to 1481 route or forward the message towards the ultimate destination. If 1482 there are more than one locationValues in the Geolocation header 1483 field, it is possible that different locationValues were used to 1484 route the message at different points along the path traversed by 1485 the request. This is allowed, as it is consistent with the rule 1486 that whenever a message is routed based upon a locationValue, a 1487 "used-for-routing" parameter is added to the applicable 1488 locationValue. This parameter MUST be present in each locationValue 1489 used along the path. A "used-for-routing" parameter MUST NOT be 1490 removed from a locationValue in a request. 1492 The "routing-allowed" parameter is exclusively for SIP servers, and 1493 will be discussed in section 6.3. 1495 Additional locationValues inserted into a request MUST be placed 1496 the order they were generated, and not rearranged. This informs a 1497 Location Recipient which was the last locationValue in the message 1498 that was used to route the message. This is for troubleshooting and 1499 management reasons. 1501 Individual header field parameters in any received locationValue 1502 MUST NOT be modified or deleted in transit to the ultimate 1503 destination. 1505 A UAS MUST NOT send location in a response message, as there can be 1506 any number of issues/problems with receiving location, and the UAC 1507 or proxy server(s) cannot reply to a response with an error 1508 response. If the UAS wants to send its location to a UAC, it can do 1509 so in a new request within a separate transaction. This document 1510 gives no recommendation about which SIP request to use, but SIP 1511 MESSAGE is a viable choice. 1513 A UAS MAY include a 'geolocation' option tag in the Supported header 1514 field of a response, indicating it does understand this extension, 1515 even if location was not included in a request to the UAS. 1517 A UAS wishing to dereference an location URI contained in a received 1518 request will use the 'presence' event package in a SUBSCRIBE request 1519 to the URI. If accepted, the LS will return the PIDF-LO to the UAS 1520 in a NOTIFY request. If there are any errors during dereferencing, 1521 or in the PIDF-LO itself, the UAS will respond to the original 1522 request with a locationErrorValue indicating what the UAS concluded 1523 was wrong with the location. This is to include any dereferencing 1524 problems encountered. 1526 Dereferencing for sip:, sips: and pres: URI schemes are 1527 mandatory-to-implement. 1529 A UAS MUST be prepared to receive subsequent location updates from 1530 the UAC, either LbyV or LbyR (regardless of how the UAS received 1531 location previously from this UAC). The UAC will convey updated 1532 location using the UPDATE [RFC3311] method to the UAS, and not a 1533 reINVITE. The UAS MUST NOT reject updated location arriving in a 1534 reINVITE though, as other dialog parameters might be changing also 1535 (in which a reINVITE is appropriate). 1537 If there is more than one location (any combination of LbyV and 1538 LbyR), this document does not give guidance about what a Location 1539 Recipient does with each location. There are no priority or 1540 more-trusted indications specified by this document. All this is 1541 considered application-specific, and out-of-scope for this document. 1542 If more than one location is present in the PIDF-LO, location 1543 elements in the same PIDF-LO MUST apply to the same Target 1544 (identified in the "entity=" attribute) and point at the same 1545 position on the earth. If there is more than one PIDF-LO with 1546 different Target identifiers, then the UAC is merely telling the UAS 1547 where more than one Target is, and there should not be any conflict. 1549 Within any PIDF-LO, there is a policy 1550 element that can be set to "yes" or "no". These are the only 1551 possibilities. If Alice conveys her location to Bob (as has been 1552 described throughout this document) with a 1553 element set to "no", then Bob MUST NOT inform any other element 1554 where Alice is. If the element is set to 1555 "yes", then Bob can inform other elements where Alice is, but only 1556 as long as the policy element, also in the 1557 PIDF-LO, allows [RFC4119]. As a byproduct of this, that means that 1558 if Alice conveys her location to Bob with a 1559 element set to "yes", and the time does not 1560 require Bob to delete Alice's location yet, then Bob is free to tell 1561 anyone else where Alice is. The entity= attribute in the 1562 element identifies who is the target of each location, preventing 1563 confusion. Whenever Bob conveys Alice's location, 1564 timer MUST be maintained as is (i.e., not changed 1565 from when Bob received it). RFC 4119 implicitly allows this 1566 behavior, and the behavior does not change when SIP is the Using 1567 Protocol. 1569 6.2.1 UAS Generating a Location Failure Indication 1571 If a UAS receives location in a request, but determines there is a 1572 problem with the location in the request, it is the responsibility 1573 of the UAS to inform the entity that inserted the problematic 1574 location into that request. The Geolocation header field in the 1575 request has a locationValue, providing the UAS a location URI 1576 indicating where the Target's location is. The Location Target 1577 identified in the PIDF-LO may or may not be the location inserter, 1578 or the generator of the request. Ultimately, location is in a 1579 PIDF-LO. This is either in the request as a message body (LbyV), or 1580 obtained by initiating a dereference transaction on a Location 1581 Server identified in the location URI. Location Servers typically 1582 challenge all dereference requests. All PIDF-LOs have a Location 1583 Target identifier. The "inserted-by=" parameter of the 1584 locationValue tells the UAS which SIP entity inserted that 1585 locationValue. This "inserted-by=" parameter is copied into the 1586 "inserter=" parameter of the locationErrorValue generated by the 1587 Location Recipient (the UAS), in a response, when it wants to inform 1588 the location "inserter=" entity there was a problem with the 1589 location it received. 1591 There can be more than one locationValue in a request. The 1592 "inserter=" parameter in the locationErrorValue will prevent 1593 entities that did not insert the errored location from 1594 misunderstanding whether the locationErrorValue applies to them. 1596 If there is one valid locationValue in a request, even if all the 1597 others have errors with them, the Location Recipient MUST NOT send a 1598 424 (Bad Location Information) response. The Location Recipient 1599 (the UAS) MUST send a locationErrorValue for each errored 1600 locationValue, with unique "inserter=" parameters to make sure the 1601 right entities know which locations were in error. 1603 As hinted at, a location "inserter=" can be a UAC or it can be an 1604 in-signaling-path SIP server acting as a UAC locator. This 1605 means the SIP server is including its version of where it thinks the 1606 UAC is, geographically. This "inserter=" has to be in the form of 1607 an dereferencable location URI in a locationValue, because SIP 1608 servers are not allowed to insert message bodies. 1610 Each locationErrorValue has an error code, letting the location 1611 "inserter=" entity know what was wrong with the location supplied by 1612 that entity. See Section 4.3 for the 5 actionable responses a UAC 1613 can take from a locationErrorValue. 1615 If the location "inserted-by=" entity, meaning either the UAC or 1616 proxy in the message path chose to indicate that location was 1617 sufficiently important to include a 'geolocation' option tag in a 1618 Require header field, any error response SHOULD be a 424 (Bad 1619 Location Information) back to the "inserter=" entity (knowing the 1620 response will ultimately go to the UAC regardless) if there needs to 1621 be a good locationValue sent to properly process the request. Only 1622 entities identified in a locationErrorValue as the "inserter=" 1623 entity will pay attention to this locationErrorValue. All other 1624 entities MUST ignore any locationErrorValue not directed towards 1625 them. See section 4.3 for more information on this, including all 1626 the location-specific errors and Geolocation-Error header field 1627 parameters. 1629 In the above scenario ('geolocation' option tag in a Require 1630 header field), the only other response can be a 420, if the UAS 1631 does not support this Geolocation extension to SIP. 1633 If the "inserted-by=" location entity placed the 'geolocation' 1634 option tag in a Supported header field, the response can be a 424 if 1635 it chooses, but also can be any other SIP response, including a 200 1636 OK. A locationErrorValue in a Geolocation-Error header field that 1637 is not in a 424 (Bad Location Information) response is considered 1638 informational by the Location Recipient, and does not cause the 1639 Location Recipient to reject the request solely because of bad 1640 location information. 1642 For example, Alice INVITEs Bob to a dialog, and includes geolocation 1643 in the request. Bob can accept the INVITE with a 200 OK and still 1644 add a locationErrorValue in the 200 OK indicating "yes, I accept 1645 your request, and btw, something was wrong with the location you 1646 provided in the INVITE". The specific problem with the location is 1647 indicated by the Geolocation-Error code. The "inserter=" parameter 1648 identifies the Location Inserter this locationErrorValue is intended 1649 for. 1651 Each locationErrorValue is destined for one "inserter=" entity. 1652 This gives a Location Recipient a mechanism to tell each inserter 1653 what the Location Recipient concluded was wrong with the location 1654 the "inserter=" entity included. Therefore, 1656 o there MUST be a locationErrorValue for each locationValue that 1657 was considered bad by the UAS to ensure each upstream location 1658 inserter understands which error code is intended for the 1659 inserter (and which to ignore). 1661 o there MUST NOT be more than one locationErrorValue in the 1662 response per locationValue in the request. 1664 o there MUST NOT be more than one locationErrorValue with the same 1665 "inserter=" entity in the request. 1667 o there MUST NOT be a locationErrorValue in the response for a 1668 locationValue in the request that was not in error, according to 1669 the Location Recipient. 1671 Here is an example of a Geolocation-Error header field 1673 Geolocation-Error: 201; code="Linkable Target Identity Required"; 1674 node="server42.example.com"; 1675 inserter="alice.example.com"; 1677 The above example says that the Location Recipient is 1678 server42.example.com, and this entity cannot verify the Target's 1679 identity within this message. This is typically needed in order to 1680 make routing decisions for the SIP request where the entity= 1681 attribute has an unlinkable pseudonym obscuring a location target's 1682 identity from the signaling. This is not desire because if Alice's 1683 message is to be routed based on the location in the SIP request, 1684 server42 has to verify that this is Alice's location. The 1685 appropriate action is to send a 424 (Bad Location Information) 1686 response with the above (201) Geolocation-Error header value. We do 1687 not want Alice's request routed based on Bob's location. 1689 See Section 4.3 for further rules about the Geolocation-Error header 1690 field and the locationErrorValue. 1692 This document says nothing about what a Location Recipient does with 1693 more than one 'good' locationValue in a request (i.e., which to 1694 choose to use). This scenario MAY be addressed in a future effort. 1696 Further, more than one error code is allowed in the 1697 locationErrorValue - each having one "inserter=" parameter. 1699 6.3 Proxy Behavior 1701 [RFC3261] states message bodies cannot be added by proxies. 1702 However, proxies are permitted to add a header field to a request. 1703 This means that a proxy can add a Geolocation locationValue header 1704 field with a dereferencable location URI, but not a LbyV message 1705 body. 1707 It is allowed, but NOT RECOMMENDED, for more than one SIP element to 1708 insert location into a request along its path. As described earlier 1709 in this document, each insertion of location into a SIP request is 1710 accompanied by a new locationValue in a Geolocation header field. 1711 Also described earlier, each locationValue MUST contain an 1712 "inserted-by=" value indicating to a Location Recipient the host 1713 that inserted a specific location into a particular request. 1715 If, however, location is already in a SIP request, a SIP server 1716 SHOULD NOT add another location URI that identifies the same target 1717 in the PIDF-LO (in the entity= attribute) to the same request. This 1718 will likely cause confusion at the Location Recipient as to which to 1719 use. 1721 More than one Geolocation locationValue in a message is permitted, 1722 but can cause confusion at the recipient. If a proxy chooses to add 1723 a locationValue to a Geolocation header field, which would be a 1724 local policy decision, the new locationValue MUST be added to the 1725 end of the header field (after previous locationValue(s)). This is 1726 done to create an order of insertion of locationValues along the 1727 path. Proxies MUST NOT modify the order of locationValues in a 1728 geolocation header field. 1730 A proxy wishing to dereference a location URI contained in a 1731 received request will use the 'presence' event package in a 1732 SUBSCRIBE request to the URI. If accepted, the LS will return the 1733 PIDF-LO to the proxy in a NOTIFY request. If there are any errors 1734 during dereferencing, or in the PIDF-LO itself, the proxy will send 1735 an error to the UAC with a locationErrorValue indicating what the 1736 proxy concluded was wrong with the location. This is to include any 1737 dereferencing problems encountered. 1739 6.3.1 Proxy Behavior with Geolocation Header Field Parameters 1741 SIP servers MUST NOT delete any existing Geolocation locationValue 1742 (URI or header field parameter) from a request. An existing 1743 locationValue MAY be modified by adding a "used-for-routing" 1744 parameter to an existing locationValue, if the request was 1745 retargeted based on the location within that locationValue. 1747 According to this specification, the default value of any 1748 Geolocation header value "routing-allowed" is "no". This parameter 1749 does not have to be present to deny SIP servers along the signaling 1750 path the ability to view the target's location. This parameter MAY 1751 be added in transit by a SIP server, and MUST be with a value of 1752 "no". Other modifications of the Geolocation header field MUST NOT 1753 occur. 1755 For example, an existing Geolocation locationValue in a request of: 1757 Geolocation: ; 1758 inserted-by="alice123@atlanta.example.com"; 1760 can be modified by a proxy to add the "used-for-routing" parameter, 1761 like this: 1763 Geolocation: ; 1764 inserted-by="alice123@atlanta.example.com"; 1765 used-for-routing 1767 if this is the locationValue the proxy used to make a retargeting 1768 decision based upon, but the proxy can make no other modification. 1770 A SIP server MAY add a new Geolocation locationValue to a SIP 1771 request. The server SHOULD NOT insert a locationValue of a Target 1772 unless it is reasonably certain it knows the actual geographic 1773 location of the Location Target (for example, if it thoroughly 1774 understands the topology of the underlying access network and it can 1775 identify the device location reliably, even in the presence of NAT 1776 or VPN). Routing errors are likely if the SIP server inserts an 1777 incorrect locationValue. 1779 A locationValue added to an existing Geolocation header field 1780 would look like: 1782 Geolocation: ; 1783 inserted-by="alice123@atlanta.example.com", 1784 ; 1785 inserted-by="ls7.atlanta.example.com" 1787 Notice the locationValue added by proxy "ls7" is last among 1788 locationValues. Proxies MUST add locationValue at the end of all 1789 locationValues that are already present in the request. 1791 If this request was then retargeted by an intermediary using the 1792 locationValue inserted by server "ls7", the intermediary would add a 1793 "used-for-routing" parameter like this: 1795 Geolocation: ; 1796 inserted-by="alice123@atlanta.example.com", 1797 ; 1798 inserted-by="ls7.atlanta.example.com"; used-for-routing 1800 It is conceivable that an initial routing decision is made on 1801 one locationValue, and subsequently another routing decision is 1802 made on a different locationValue further towards the ultimate 1803 destination. This retargeting decision can be made on a newly 1804 inserted locationValue. While unusual, it can occur. In such a 1805 case, proxies MUST NOT remove any existing "used-for-routing" header 1806 field parameter. In this instance, the SIP server retargeting based 1807 on another locationValue MUST add the "used-for-routing" header 1808 field parameter to the locationValue used for retargeting by this 1809 server. This will result in a Geolocation header field indicating 1810 that the request has been retargeted more than once, which is 1811 allowed. 1813 A Proxy that inserts or adds locationValue into a request MAY move a 1814 'geolocation' option tag that is in a Supported header field into a 1815 Require header field if this proxy deems geolocation to be 1816 sufficiently important to Location Recipient(s) of this request. 1818 A proxy can read any locationValue present, and the associated body, 1819 if not S/MIME protected, and can use the contents of the header 1820 field to make location-based retargeting decisions, if retargeting 1821 requests based on location is a function of that proxy. Retargeting 1822 is defined in [RFC3261]. However, if the Geolocation header field 1823 parameter "routing-allowed" is present and set to "no", or is not 1824 present (the default behavior is "no" if "routing-allowed" is not 1825 present, whether or not a Geolocation header field is present), SIP 1826 servers MUST NOT view the contents of the location message body. 1827 Further, SIP servers MUST NOT attempt to dereference a location URI. 1828 This is because the Location Inserter (likely the originating UAC) 1829 did not give the SIP server permission to view the location within 1830 the SIP request. How a SIP server indicates it requires permission 1831 to view a request's location in order to properly process this 1832 request is described in section 6.3.2. 1834 If the Geolocation header field parameter "routing-allowed" is 1835 present in a SIP request, the value MUST NOT be changed during 1836 processing of the request. If the Geolocation header field 1837 parameter "routing-allowed" is not present, SIP servers MUST treat 1838 the location within the request as if the header field parameter 1839 "routing-allowed" were present and set to "no". 1841 B2BUAs and SBCs should also adhere to the above proxy guidance with 1842 respect to the "Routing-allowed" header field parameter. In other 1843 words, if the particular type of SIP server mentioned here supports 1844 this SIP extension and is not the ultimate destination of this SIP 1845 request, each policy rule within the Geolocation header field MUST 1846 remain intact and unchanged. 1848 No SIP server can delete a "Routing-allowed" header field 1849 parameter, but if one is not yet present, any SIP server MAY add a 1850 "Routing-allowed" header field parameter with the value set to "no" 1851 only. 1853 6.3.2 Proxy Error Behavior for Sending or Receiving locationErrorValues 1855 For proxies that receive a SIP request that contains a location 1856 error, all the rules applicable to a UAS apply (see Section 6.2.1.). 1857 The one point to add is that a proxy does not need to examine 1858 location contained in a request. Section 6.2.1. only applies to 1859 proxies that need to monitor or police location within requests (for 1860 whatever reason). 1862 If a proxy inserted a locationValue into a request, it MUST be 1863 ready to examine the response to that request, in case there is one 1864 or more location errors in the response. To a great degree, this 1865 scenario has the proxy behaving as a UAC (see section 6.1.1.) that 1866 included a locationValue a request, which then receives an error to 1867 that locationValue. 1869 This location-inserting proxy SHOULD be (at least) transaction 1870 stateful for the response. If the proxy is configured as a 1871 stateless proxy, and it inserts location, it MUST process and 1872 monitor all SIP responses, looking for locationErrorValues that 1873 indicate it was the "inserter=" to learn that the location it 1874 supplied was in error. It SHOULD react according to the error code 1875 received. This document gives no guidance what the proxy should do 1876 to rectify the bad location information, since the proxy is not the 1877 SIP response destination, but a future document could address this. 1879 The "routing-allowed" parameter's purpose is to indicate if SIP 1880 servers along the signaling path should bother looking at the 1881 location message body or dereferencing the location URI. There are 1882 two values specified here for this parameter: "yes" and "no". If 1883 the "routing-allowed" parameter is set to "yes", and the SIP server 1884 determines this SIP request should be routed based on the target's 1885 location, this parameter gives the server permission to look at the 1886 location (or dereference it). If this parameter is set to "no", 1887 then the SIP server MUST NOT view the location message body or 1888 dereference the location URI within this SIP request. If the SIP 1889 server believes it cannot process this message properly because it 1890 needs to learn the target's location in order to route the message, 1891 then it MUST return a 424 (Bad Location Information) response, 1892 indicating it requires permission (error code 400) to view the 1893 location. 1895 Here is an example of a Geolocation-Error header field 1897 Geolocation-Error: 400; code="Permission to Reveal Location 1898 Information to a Third Party"; 1899 node="server42.example.com"; 1900 inserter="alice.example.com"; 1902 The above example says that the Location Recipient is 1903 server42.example.com, and this entity believes it cannot route this 1904 message without knowing permission to view the Target's location. 1905 Regardless of whether there is a Geolocation header value parameter, 1906 such as 1908 routing-allowed=no 1910 or this parameter is not present in the SIP request (as shown 400 1911 error example above). The default behavior is to act as if the 1912 parameter is present and set to "no". Server42 MUST get permission 1913 to view the Target's location by reading a routing-allowed header 1914 parameter saying "yes", otherwise a 400 error is sent back to the 1915 inserter= entity to get permission. 1917 Section 4.3 highlights this example, stating the user, Alice, MUST 1918 be made aware of this location revelation request. This document 1919 does not give any guidance how Alice is to be informed (i.e., audio, 1920 visual, etc). Alice can grant permission or choose not to, knowing 1921 this SIP request attempt (to this destination, at this time) will 1922 fail. The problem might not recur if a future SIP request were to 1923 travel through a different server than server42 (or it might again). 1925 7. Geopriv Privacy Considerations 1927 Location information is considered by most to be highly 1928 sensitive information, requiring protection from eavesdropping, 1929 and altering in transit. [RFC3693] articulates rules to 1930 be followed by any protocol wishing to be considered a "Using 1931 Protocol", specifying how a transport protocol meets those rules. 1932 This section describes how SIP as a Using Protocol meets those 1933 requirements. 1935 Quoting requirement #4 of [RFC3693]: 1937 "The Using Protocol has to obey the privacy and security 1938 instructions coded in the Location Object and in the 1939 corresponding Rules regarding the transmission and storage 1940 of the LO." 1942 This document requires that SIP entities sending or receiving 1943 location MUST obey such instructions. 1945 Quoting requirement #5 of [RFC3693]: 1947 "The Using Protocol will typically facilitate that the keys 1948 associated with the credentials are transported to the 1949 respective parties, that is, key establishment is the 1950 responsibility of the Using Protocol." 1952 [RFC3261] and the documents it references define the key 1953 establishment mechanisms. 1955 Quoting requirement #6 of [RFC3693]: 1957 "(Single Message Transfer) In particular, for tracking of 1958 small Target devices, the design should allow a single 1959 message/packet transmission of location as a complete 1960 transaction." 1962 When used for tracking, a simple NOTIFY or UPDATE normally is 1963 relatively small, although the PIDF itself can be large. Normal 1964 RFC 3261 procedures of reverting to TCP when the MTU size is 1965 exceeded would be invoked. 1967 8. Security Considerations 1969 Conveyance of physical location of a UAC raises privacy concerns, 1970 and depending on use, there probably will be authentication and 1971 integrity concerns. This document calls for conveyance to 1972 be accomplished through secure mechanisms, like S/MIME protecting 1973 message bodies (although this is not widely deployed) or TLS 1974 protecting the overall signaling. In cases where a session set-up 1975 is retargeted based on the location of the UAC initiating the call 1976 or SIP MESSAGE, securing the LbyV location with an end-to-end 1977 mechanism such as S/MIME is problematic, because one or more proxies 1978 on the path need the ability to read the location information to 1979 retarget the message to the appropriate new destination UAS. 1980 Securing the location hop-by-hop, using TLS, protects the message 1981 from eavesdropping and modification, but exposes the information to 1982 all proxies on the path as well as the endpoint. In most cases, the 1983 UAC does not know the identity of the proxy or proxies providing 1984 location-based routing services, so that end-to-middle solutions 1985 might not be appropriate either. 1987 These same issues exist for basic SIP signaling, but SIP normally 1988 does not carry information to physically track a user. This 1989 extension is especially sensitive. That said, there is the ability, 1990 according to [RFC3693] to have an anonymous identity for the 1991 target's location. This is accomplished by use of an unlinkable 1992 pseudonym in the entity= attribute of the element 1993 [RFC4479]. Though, this can be problematic for routing messages 1994 based on location (covered several times in the document above). 1996 When location is inserted by a UAC, which is RECOMMENDED, it can 1997 decide whether to reveal its location using hop-by-hop methods. UAC 1998 implementations MUST make such capabilities conditional on explicit 1999 user permission, and SHOULD alert a user that location is being 2000 conveyed. Proxies inserting location for location-based routing are 2001 unable to alert users, and such use is NOT RECOMMENDED. Proxies 2002 conveying location using this extension MUST have the permission of 2003 the Target to do so. 2005 This SIP extension offers the default ability to require permission 2006 to view location while the SIP request is in transit. The default 2007 for this is set to "no", and there is an error explicitly describing 2008 how an intermediary asks for permission to view the Target's 2009 location. 2011 Because target locations can be placed on a remote server, called a 2012 Location Server accessible with the possession of a location URI, 2013 this URI has its own security considerations. It is tempting to 2014 assume that the dereference of this URI would have authentication, 2015 authorization and other security mechanisms that limit the access to 2016 information. Unfortunately, this might not be true. The access 2017 network the UAC is connected to can be the source of location 2018 reference, and it might not have any credentialing mechanism 2019 suitable for controlling access to a target's location. Consider, 2020 specifically, a nomadic user connected to an access network in a 2021 hotel. The UAC has no way to provide a credential acceptable of the 2022 hotel Location Server (LS) to any of its intended Location 2023 Recipients. The recipient of a reference does not know if a 2024 reference has appropriate authorization policies or not. 2026 Accordingly, possession of the reference should be considered 2027 equivalent to possession of the value, and the reference should be 2028 treated with the same degree of care as the value. Specifically, 2029 TLS MUST be used to protect the security of the reference. Notice 2030 that this specification does not constrain the dereference protocol 2031 to use TLS. That specification is left entirely to the dereferencing 2032 protocol documents. 2034 There is no end-to-end integrity on any locationValue or 2035 locationErrorValue header field parameter (or middle-to-end if the 2036 value was inserted by a intermediary), so recipients of either 2037 header field need to implicitly trust the header field contents, and 2038 take whatever precautions each entity deems appropriate given this 2039 situation. Any idea of using SIP Identity is lost as soon as it is 2040 realized that the Geolocation header value can be added to by 2041 intermediaries in the signaling path. 2043 9. IANA Considerations 2045 The following are the IANA considerations made by this SIP 2046 extension. Modifications and additions to these registrations 2047 require a standards track RFC (Standards Action). 2049 [Editor's Note: RFC-Editor - within the IANA section, please 2050 replace "this doc" with the assigned RFC number, 2051 if this document reaches publication.] 2053 9.1 IANA Registration for the SIP Geolocation Header Field 2055 The SIP Geolocation Header Field is created by this document, with 2056 its definition and rules in Section 4.1 of this document, and should 2057 be added to the IANA sip-parameters registry, in the portion titled 2058 "Header Field Parameters and Parameter Values". 2060 Predefined 2061 Header Field Parameter Name Values Reference 2062 ---------------- ------------------- ---------- --------- 2063 Geolocation inserted-by= no [this doc] 2064 Geolocation used-for-routing yes [this doc] 2065 Geolocation routing-allowed yes [this doc] 2067 9.2 IANA Registration for New SIP Option Tag 2069 The SIP option tag "geolocation" is created by this document, with 2070 the definition and rule in Section 4.4 of this document, to be added 2071 to the IANA sip-parameters registry. 2073 9.3 IANA Registration for Response Code 424 2075 Reference: RFC-XXXX (i.e., this document) 2076 Response code: 424 (recommended number to assign) 2077 Default reason phrase: Bad Location Information 2079 This SIP Response code is defined in section 4.2 of this document. 2081 9.4 IANA Registration of New Geolocation-Error Header Field 2083 The SIP Geolocation-error header field is created by this document, 2084 with its definition and rules in Section 4.3 of this document, to be 2085 added to the IANA sip-parameters registry, in the portion titled 2086 "Header Field Parameters and Parameter Values". 2088 Predefined 2089 Header Field Parameter Name Values Reference 2090 ----------------- ------------------- ---------- --------- 2091 Geolocation-Error inserter= no [this doc] 2092 Geolocation-Error node= no [this doc] 2093 Geolocation-Error code= yes* [this doc] 2094 * see section 9.5 for the newly created values. 2096 9.5 IANA Registration for the SIP Geolocation-Error Codes 2098 New location specific Geolocation-Error codes are created by this 2099 document, and registered in a new table in the IANA sip-parameters 2100 registry. Details of these error codes are in Section 4.3 of this 2101 document. 2103 Geolocation-Error codes 2104 ----------------------- 2105 Geolocation-Error codes provide reason for the error discovered by 2106 Location Recipients, categorized by action to be taken by error 2107 recipient to be placed into SIP responses to inform the location 2108 inserter of the error. 2110 Code Description Reference 2111 ---- --------------------------------------------------- --------- 2112 100 "Cannot Process Location" General location error, [this doc] 2113 meaning location in the request cannot be 2114 processed at this time. No actionable guidance. 2115 Can be treated as a 200 or 300 error by error 2116 recipient. 2118 200 "Retry Location Later with same data" The location [this doc] 2119 cannot be processed at this time. Error recipient 2120 should try again with same data. 2122 201 "Linkable Target Identity Required" [this doc] 2123 Target's identity cannot be unlinkable within 2124 the presence element's entity= attribute. This 2125 is necessary for routing SIP requests based 2126 on Target's location (and some other entity's). 2128 300 "Retry Location Later with device updated location" [this doc] 2129 Location cannot be processed at this time. Error 2130 recipient should try again with same data. 2132 400 "Permission To Reveal Location Information to a Third Party" 2133 Permission from calling user to reveal location [this doc] 2134 in request before request can be processed. This 2135 is a routing by location error. User MUST be 2136 informed of permission request. 2138 500 "Location Information Denial" Request was actively [this doc] 2139 denied because of the location in the request. 2140 Recipient should not try again. 2142 9.6 IANA Registration of Location URI Schemes 2144 This document directs IANA to create a new set of parameters in a 2145 separate location from SIP and Geopriv, called the "Location 2146 Reference URI" registry, containing the URI scheme, the 2147 Content-Type, and the reference, as follows: 2149 URI Scheme Content-Type Reference 2150 ---------- ------------ --------- 2151 SIP: [this doc] 2152 SIPS: [this doc] 2153 PRES: [this doc] 2155 Additions to this registry must be defined in a permanent and 2156 readily available specification (this is the "Specification 2157 Required" IANA policy defined in [RFC5226]).. 2159 10. Acknowledgements 2161 To Dave Oran for helping to shape this idea. 2163 To Jon Peterson and Dean Willis on guidance of the effort. 2165 To Allison Mankin, Dick Knight, Hannes Tschofenig, Henning 2166 Schulzrinne, James Winterbottom, Jeroen van Bemmel, Jean-Francois 2167 Mule, Jonathan Rosenberg, Keith Drage, Marc Linsner, Martin Thomson, 2168 Mike Hammer, Ted Hardie, Shida Shubert, Umesh Sharma, Richard 2169 Barnes, Dan Wing, Matt Lepinski and Jacqueline Lee for constructive 2170 feedback and nits checking. 2172 Special thanks to Paul Kyzivat for his help with the ABNF in this 2173 document and to Robert Sparks for many helpful comments and the 2174 proper construction of the Geolocation-Error header field. 2176 And finally, to Spencer Dawkins for giving this doc a good scrubbing 2177 to make it more readable. 2179 11. References 2181 11.1 References - Normative 2183 [RFC3261] J. Rosenberg, H. Schulzrinne, G. Camarillo, A. Johnston, J. 2184 Peterson, R. Sparks, M. Handley, and E. Schooler, "SIP: 2185 Session Initiation Protocol", RFC 3261, May 2002. 2187 [RFC4119] J. Peterson, "A Presence-based GEOPRIV Location Object 2188 Format", RFC 4119, December 2005 2190 [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate 2191 Requirement Levels", RFC 2119, March 1997 2193 [RFC2392] E. Levinson, " Content-ID and Message-ID Uniform Resource 2194 Locators", RFC 2392, August 1998 2196 [RFC3863] H. Sugano, S. Fujimoto, G. Klyne, A. Bateman, W. Carr, J. 2197 Peterson, "Presence Information Data Format (PIDF)", RFC 2198 3863, August 2004 2200 [RFC3856] J. Rosenberg, " A Presence Event Package for the Session 2201 Initiation Protocol (SIP)", RFC 3856, August 2004 2203 [RFC3859] J. Peterson, "Common Profile for Presence (CPP)", RFC 3859, 2204 August 2004 2206 [RFC3428] B. Campbell, Ed., J. Rosenberg, H. Schulzrinne, C. Huitema, 2207 D. Gurle, "Session Initiation Protocol (SIP) Extension for 2208 Instant Messaging" , RFC 3428, December 2002 2210 [RFC3311] J. Rosenberg, "The Session Initiation Protocol (SIP) UPDATE 2211 Method", RFC 3311, October 2002 2213 [RFC3265] Roach, A, "Session Initiation Protocol (SIP)-Specific 2214 Event Notification", RFC 3265, June 2002. 2216 [RFC3262] Rosenberg, J. and H. Schulzrinne, "Reliability of 2217 Provisional Responses in Session Initiation Protocol (SIP)", 2218 RFC 3262, June 2002. 2220 [RFC2976] S. Donovan, "The SIP INFO Method", RFC 2976, Oct 2000 2222 [RFC3515] R. Sparks, "The Session Initiation Protocol (SIP) Refer 2223 Method", RFC 3515, April 2003 2225 [RFC3903] Niemi, A, "Session Initiation Protocol (SIP) Extension 2226 for Event State Publication", RFC 3903, October 2004. 2228 [RFC5234] Crocker, D., Ed., and P. Overell, "Augmented BNF for Syntax 2229 Specifications: ABNF", STD 68, RFC 5234, January 2008. 2231 [IANA-civic] http://www.iana.org/assignments/civic-address-types- 2232 Registry 2234 [RFC5226] T. Narten, H. Alvestrand, "Guidelines for Writing an IANA 2235 Considerations Section in RFCs", RFC 5226, May 2008 2237 [RFC4479] J. Rosenberg, "A Data Model for Presence", RFC 4479, July 2238 2006 2240 11.2 References - Informative 2242 [RFC3693] J. Cuellar, J. Morris, D. Mulligan, J. Peterson. J. Polk, 2243 "Geopriv Requirements", RFC 3693, February 2004 2245 [RFC4483] E. Berger, "A Mechanism for Content Indirection in SIP", RFC 2246 4483, May 2006 2248 [RFC3825] J. Polk, J. Schnizlein, M. Linsner, "Dynamic Host 2249 Configuration Protocol Option for Coordinate-based Location 2250 Configuration Information", RFC 3825, July 2004 2252 [RFC4776] H. Schulzrinne, " Dynamic Host Configuration Protocol 2253 (DHCPv4 and DHCPv6) Option for Civic Addresses Configuration 2254 Information ", RFC 4776, October 2006 2256 [ID-PHONE] B. Rosen, J. Polk, "ECRIT Phone BCP", 2257 draft-ietf-ecrit-phonebcp, "work in progress", July 2009 2259 Author Information 2261 James Polk 2262 Cisco Systems 2263 3913 Treemont Circle 2264 Colleyville, Texas 76034 2266 33.00111N 2267 96.68142W 2269 Phone: +1-817-271-3552 2270 Email: jmpolk@cisco.com 2272 Brian Rosen 2273 NeuStar, Inc. 2274 470 Conrad Dr. 2275 Mars, PA 16046 2277 40.70497N 2278 80.01252W 2280 Phone: +1 724 382 1051 2281 Email: br@brianrosen.net 2283 Appendix A. Requirements for SIP Location Conveyance 2285 The following subsections address the requirements placed on the 2286 UAC, the UAS, as well as SIP proxies when conveying location. If a 2287 requirement is not obvious in intent, a motivational statement is 2288 included below it. 2290 A.1 Requirements for a UAC Conveying Location 2292 UAC-1 The SIP INVITE Method [RFC3261] must support location 2293 conveyance. 2295 UAC-2 The SIP MESSAGE method [RFC3428] must support location 2296 conveyance. 2298 UAC-3 SIP Requests within a dialog should support location 2299 conveyance. 2301 UAC-4 Other SIP Requests may support location conveyance. 2303 UAC-5 There must be one, mandatory to implement means of 2304 transmitting location confidentially. 2306 Motivation: to guarantee interoperability. 2308 UAC-6 It must be possible for a UAC to update location conveyed 2309 at any time in a dialog, including during dialog 2310 establishment. 2312 Motivation: if a UAC has moved prior to the establishment of a 2313 dialog between UAs, the UAC must be able to send location 2314 information. If location has been conveyed, and the UA 2315 moves, the UAC must be able to update the location previously 2316 conveyed to other parties. 2318 UAC-7 The privacy and security rules established within [RFC3693] 2319 that would categorize SIP as a 'Using Protocol' must be met. 2321 UAC-8 The PIDF-LO [RFC4119] is a mandatory to implement format for 2322 location conveyance within SIP, whether included LbyV or 2323 LbyR. 2325 Motivation: interoperability with other IETF location protocols and 2326 Mechanisms. 2328 UAC-9 There must be a mechanism for the UAC to request the UAS send 2329 its location. 2331 UAC-9 has been DEPRECATED by the SIP WG, due to the many 2332 problems this requirement would have caused if implemented. 2333 The solution is for the above UAS to send a new request to 2334 the original UAC with the UAS's location. 2336 UAC-10 There must be a mechanism to differentiate the ability of the 2337 UAC to convey location from the UACs lack of knowledge of its 2338 location 2340 Motivation: Failure to receive location when it is expected can 2341 happen because the UAC does not implement this extension, or 2342 because the UAC implements the extension, but does not know 2343 where the Target is. This may be, for example, due to the 2344 failure of the access network to provide a location 2345 acquisition mechanism the UAC supports. These cases must be 2346 differentiated. 2348 UAC-11 It must be possible to convey location to proxy servers 2349 along the path. 2351 Motivation: Location-based routing. 2353 A.2 Requirements for a UAS Receiving Location 2355 The following are the requirements for location conveyance by a UAS: 2357 UAS-1 SIP Responses must support location conveyance. 2359 Just as with UAC-9, UAS-1 has been DEPRECATED by the SIP WG, 2360 due to the many problems this requirement would have caused 2361 if implemented. The solution is for the above UAS to send a 2362 new request to the original UAC with the UAS's location. 2364 UAS-2 There must be a unique 4XX response informing the UAC it did 2365 not provide applicable location information. 2367 In addition, requirements UAC-5, 6, 7 and 8 also apply to the UAS. 2369 A.3 Requirements for SIP Proxies and Intermediaries 2371 The following are the requirements for location conveyance by a SIP 2372 proxies and intermediaries: 2374 Proxy-1 Proxy servers must be capable of adding a Location header 2375 field during processing of SIP requests. 2377 Motivation: Provide network assertion of location 2378 when UACs are unable to do so, or when network assertion is 2379 more reliable than UAC assertion of location 2381 Note: Because UACs connected to SIP signaling networks may have 2382 widely varying access network arrangements, including VPN 2383 tunnels and roaming mechanisms, it may be difficult for a 2384 network to reliably know the location of the endpoint. Proxy 2385 assertion of location is NOT RECOMMENDED unless the SIP 2386 signaling network has reliable knowledge of the actual 2387 location of the Targets. 2389 Proxy-2 There must be a unique 4XX response informing the UAC it 2390 did not provide applicable location information.