idnits 2.17.1 draft-ietf-sip-location-conveyance-11.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 2207. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 2218. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 2225. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 2231. 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 44 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 Copyright Line does not match the current year == Line 597 has weird spacing: '... ar o ...' == Line 601 has weird spacing: '... ar o ...' == Line 1836 has weird spacing: '...n-Error inse...' == Line 1837 has weird spacing: '...n-Error node...' == Line 1838 has weird spacing: '...n-Error code...' == 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. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 30, 2008) is 5628 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: None ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 3265 (Obsoleted by RFC 6665) ** Obsolete normative reference: RFC 2976 (Obsoleted by RFC 6086) -- Obsolete informational reference (is this intentional?): RFC 3825 (Obsoleted by RFC 6225) Summary: 3 errors (**), 0 flaws (~~), 8 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SIP Working Group James Polk 3 Internet Draft Cisco Systems 4 Expires: April 30, 2009 Brian Rosen 5 Intended Status: Standards Track (PS) NeuStar 6 October 30, 2008 8 Location Conveyance for the Session Initiation Protocol 9 draft-ietf-sip-location-conveyance-11.txt 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six 24 months and may be updated, replaced, or obsoleted by other documents 25 at any time. It is inappropriate to use Internet-Drafts as 26 reference material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on April 30, 2009. 36 Copyright Notice 38 Copyright (C) The IETF Trust (2008). 40 Abstract 42 This document defines an extension to the Session Initiation 43 Protocol (SIP) to convey geographic location information from one 44 SIP entity to another SIP entity. The extension covers end to end 45 conveyance as well as location-based routing, where SIP servers 46 make routing decisions based on the location of the user agent 47 clients. 49 Table of Contents 51 1. Conventions and Terminology used in this document . . . . . . 2 52 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 53 3. Overview of SIP Location Conveyance . . . . . . . . . . . . . 5 54 4. SIP Modifications for Geolocation Conveyance . . . . . . . . 7 55 4.1 The Geolocation Header . . . . . . . . . . . . . . . . . 7 56 4.2 424 (Bad Location Information) Response Code . . . . . . 9 57 4.3 The Geolocation-Error Header . . . . . . . . . . . . . . 10 58 4.4 The 'geolocation' Option Tag . . . . . . . . . . . . . . 18 59 4.5 Using sip/sips/pres as a Dereference Scheme . . . . . . . 18 60 5. Geolocation Examples . . . . . . . . . . . . . . . . . . . . 20 61 5.1 Location-by-value (Coordinate Format) . . . . . . . . . . 20 62 5.2 Location-by-reference . . . . . . . . . . . . . . . . . . 22 63 6. SIP Element Behavior . . . . . . . . . . . . . . . . . . . . 23 64 6.1 UAC Behavior . . . . . . . . . . . . . . . . . . . . . . 23 65 6.2 UAS Behavior . . . . . . . . . . . . . . . . . . . . . . 26 66 6.3 Proxy Behavior . . . . . . . . . . . . . . . . . . . . . 31 67 7. Geopriv Privacy Considerations . . . . . . . . . . . . . . . 34 68 8. Security Considerations . . . . . . . . . . . . . . . . . . . 34 69 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . 36 70 9.1 IANA Registration for New SIP Geolocation Header . . . . 36 71 9.2 IANA Registration for New SIP 'geolocation' Option Tag . 36 72 9.3 IANA Registration for New 424 Response Code . . . . . . . 36 73 9.4 IANA Registration for New SIP Geolocation-Error Header . 36 74 9.5 IANA Registration for New SIP Geolocation-Error Codes . . 37 75 9.6 IANA Registration of LbyR Schemes . . . . . . . . . . . 37 76 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 38 77 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 38 78 11.1 Normative References . . . . . . . . . . . . . . . . . 38 79 11.2 Informative References . . . . . . . . . . . . . . . . . 39 80 Author Information . . . . . . . . . . . . . . . . . . . . . 40 81 Appendix A. Requirements for SIP Location Conveyance . . . . 40 82 Appendix B. Example of Civic-based PIDF-LO w/ S/MIME . . . . 42 83 Intellectual Property and Copyright Statements . . . . . . . 44 85 1. Conventions and Terminology used in this document 87 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 88 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and 89 "OPTIONAL" in this document are to be interpreted as described 90 in [RFC2119]. 92 The following terms and acronyms used throughout this document are 93 defined here: 95 "cid=" = content-ID URI. See Section 4.1 for more details. 97 Content-ID - Defined in RFC 2392 as a URL reference to find message 98 body parts within the same message, to ease parsing. 100 LbyR = Location-by-Reference 101 LbyV = Location-by-Value 103 locationErrorValue - contains an actionable error code from a 104 Location Recipient, identifying the location "inserter=", and 105 optionally a test string describing the type of error. There can 106 be one or more locationErrorValues within a Geolocation-Error 107 header in a SIP response. See Section 4.3 for more details. 109 locationValue - contains a URI pointing to a Location Target's 110 location (as a PIDF-LO), and one or more header parameters about 111 that URI. There can be one or more locationValues within a 112 Geolocation header in a SIP request. See Section 4.1 for more 113 details. 115 Location Generator - the first IP enabled device that builds the IP 116 packet that transmits the PIDF-LO containing the Target's 117 location 119 Location Information Server (LIS) - a logical server that stores 120 geolocation records, which correspond to LbyR URIs, which point 121 to those records. 123 Location Object - Defined in RFC 4119 as the PIDF-LO (XML scheme) 124 format which includes the geolocation of Location Target in 125 either civic address or coordinate form. 127 Location Recipient - Defined in RFC3693 as any entity that 128 understands geolocation (LbyR or LbyV) along a message path. 129 Does not include entities that process a message containing 130 geolocation that do not understand geolocation (i.e., layer 3 131 routers). 133 Location Server - a logical IP server that transmits a PIDF-LO. This 134 can be logically combined with the Location Generator, or could 135 be an intermediary element - such as a LIS. 137 Location Target - The entity whose location is being sought, whether 138 or not this entity is aware of this inquiry or is even an IP 139 device. 141 Location-by-Reference (more than one meaning) 143 - a general purpose term meaning a message containing a URI that 144 points to a PIDF-LO (geolocation of a Location Target) not within 145 this same message 147 - a URI that logically locates a geolocation record of a Location 148 Target. The URI does not point to location within the same 149 message as the URI. 151 Location-by-Value - when a message contains the actual location of a 152 Location Target, in the form of a PIDF-LO, within a part of the 153 same message, usually pointed to by a "cid=" URI in a Geolocation 154 header. 156 Using Protocol - as defined in [RFC3693], a protocol that is deemed 157 to be in compliance with the security and privacy aspects of the 158 Geopriv Requirements RFC [RFC3693], with good community 159 verification. 161 Instead of using the terms Location-by-Reference (or just 162 by-reference) and Location-by-Value (or just by-value), this 163 document will herein use the acronyms LbyR and LbyV, respectively. 164 The use of "cid=" implies LbyV, therefore, the use of a "cid=" 165 Reference URL, which is *not* a Location-by-Reference (LbyR). 167 2. Introduction 169 This document describes how Location can be "conveyed" (that is, 170 transmitted over the Internet) from one SIP user agent (UA), or in 171 some circumstances, a proxy server acting in support of a UA, to 172 another entity using SIP [RFC3261]. Here "Location" is a 173 description of the physical geographical area where something 174 currently exists. The phrase "location conveyance" describes 175 scenarios in which a SIP user agent client (UAC) is informing a user 176 agent server (UAS), or intermediate SIP server where the UAC is. A 177 superset of this can also be true as well, in which one UA(1) is 178 telling another UA(2) where another Target is, meaning not 179 necessarily where UA(1) is. The key to this is whether UA(1) has 180 permission to retransmit that other Target's location. If yes, then 181 this is valid. If no, then this is breaking a fundamental rule 182 within this extension. 184 Location Conveyance is different from a UAC seeking the location the 185 UAS. Location conveyance is a 'sending location out in the request' 186 model, where 'asking that someone else's location be in a response' 187 is not discussed here. 189 Geographic location in the IETF is discussed in RFC 3693 (Geopriv 190 Requirements) [RFC3693]. It defines a "Target" as the entity whose 191 location is being sought. In this case, this is the UA's 192 (UA) location. A [RFC3693] "Using Protocol" defines how a "Location 193 Server" transmits a "Location Object" to a "Location Recipient" 194 while maintaining the contained privacy intentions of the Target 195 intact. This document describes the extension to SIP for how it 196 complies with the Using Protocol requirements, where the location 197 server is a UA or Proxy Server and the Location Recipient is 198 another UA or Proxy Server. 200 Location can be transmitted by-value or by-reference. The location 201 "value" in this SIP extension is in the form of a Presence 202 Information Data Format - Location Object, or PIDF-LO, as described 203 in [RFC4119]. A PIDF-LO is an XML Scheme specifically for carrying 204 geographic location of a Target. LbyV refers to a UA including a 205 PIDF-LO as a body part of a SIP request, sending that Location 206 Object to another SIP element. LbyR refers to a UA or proxy server 207 including a URI in a SIP request header field which can be 208 dereferenced by a Location Recipient for a Location Object, in the 209 form of a PIDF-LO. Dereferencing can be by a SIP UA or a SIP 210 server. 212 As recited in RFC 3693, location often must be kept private. The 213 Location Object (PIDF-LO) contains rules which provides guidance to 214 the Location Recipient and controls onward distribution and 215 retention of the location. This document describes the security and 216 privacy considerations that must be applied to location conveyed 217 with SIP. 219 Another use for location is location-based routing of a 220 SIP request, where the choice of the next hop (and usually, the 221 outgoing Request-URI) is determined by the location of the UAC which 222 is in the message by-value or by-reference. This document describes 223 how location can be conveyed from the UAC, or a proxy acting on its 224 behalf, to a routing proxy. How the location is actually used to 225 determine the next hop or Request-URI is beyond the scope of this 226 document. 228 We refer to the "emergency case". This refers to a specific, 229 important use of SIP location conveyance where the location of the 230 caller is used to determine which Public Safety Answering Point 231 (PSAP) is expected to receive an emergency call request for help 232 (e.g., a call to 1-1-2 or 9-1-1). This is an example of 233 location-based routing. The location conveyed is also used by the 234 PSAP to dispatch first responders to the caller's location. There 235 are special security considerations, which make the emergency case 236 unique, compared to a normal location conveyance within SIP. 238 Common terms are in Section 1. Section 3 provides an overview of SIP 239 location conveyance. Section 4 details the modifications necessary 240 to accomplish location conveyance. Section 5 gives decode examples 241 of geolocation within SIP requests, both LbyV and LbyR. Section 6 242 articulates the SIP element type behaviors for location conveyance. 243 Section 7 discusses Geopriv privacy considerations. Section 8 244 discusses security considerations. Section 9 IANA registers the 245 modifications made to SIP by this document from section 4. 247 3. Overview of SIP Location Conveyance 249 This document defines a new SIP header: Geolocation. The 250 Geolocation header field contains a URI which can either be a "cid:" 251 URI (Content Identification), as defined in [RFC2392], or an LbyR 252 -- to be dereferenced by a Location Recipient to retrieve the 253 location of the Target UA. 255 Where the Geolocation header contains a "cid:", the URI points to a 256 message body that is in the form of a PIDF [RFC3863], which was 257 extended in [RFC4119] to include location, as a PIDF-LO. This is 258 LbyV, the actual location information in the PIDF-LO is included in 259 the body of the message. 261 If the URI in the Geolocation header field is a scheme other than 262 "cid:", another protocol operation is needed by the SIP message 263 recipient to obtain the location of the Target (UA). This is 264 LbyR. This document describes how a SIP presence subscription 265 [RFC3856] can be used as a dereference protocol. 267 The Geolocation header, either with the PIDF-LO in a body or as a 268 LbyR URI, can be included by a UA in a SIP request. A SIP proxy 269 server can assert location of the UA by inserting the header field, 270 by adding an LbyR URI into the Geolocation header value, even if 271 there is a locationValue already there. Since body parts cannot be 272 inserted by a SIP proxy server, LbyV message body cannot be inserted 273 by a proxy. 275 The Geolocation header can have parameters that are associated 276 with a URI in the header field. The "inserted-by" parameter 277 indicates the host-id of which specific element added this 278 particular location to the request. This header parameter is 279 included in every locationValue, and does not appear more than once 280 per locationValue. The "inserted-by" parameter is especially useful 281 for Location Recipients that receive more than one locationValue 282 within a SIP request. Since implementations of a UA or SIP Server 283 do not know they will be the last entity before a Location 284 Recipient, this optional parameter is necessary within each 285 locationValue. 287 Retargeting means the Request-URI of the request has changed to 288 point at a new destination UAS. This is different than message 289 routing, that all SIP proxies do. If a SIP request is retargeted 290 based on the location contained or referenced within that message, 291 the "used-for-routing" parameter is added as a header parameter 292 within the appropriate locationValue. 294 There is no mechanism by which the veracity of these parameters can 295 be verified. They are hints to downstream entities on how the 296 location information in the message was originated and used. 297 Transport Layer Security is expected when a request contains a 298 user's location. Some implementations will choose to have S/MIME to 299 encrypt message bodies from source to destination. 301 This document creates a new option tag: geolocation, to indicate 302 support for this extension by UAs. 304 A new error response (424 Bad Location Information) is also defined 305 in this document. Within this response is a new header indicating 306 location-based errors, call the Geolocation-Error header. This 307 header has various codes that provide additional information about 308 the type of location error experienced by a Location Recipient. 310 Both new headers, the header parameters, the new option tag, the new 311 error response, and Geolocation-Error codes, which are defined in 312 Section 4., are IANA registered by this document. 314 4. SIP Modifications for Geolocation Conveyance 316 The following are sections detail the standards track modifications 317 to SIP for Location Conveyance. 319 4.1 The Geolocation Header 321 This document defines and IANA registers a new SIP header: 322 Geolocation, with the following ABNF [RFC5234]: 324 Geolocation = "Geolocation" HCOLON (locationValue *(COMMA 325 locationValue)) 326 locationValue = LAQUOT locationURI RAQUOT *(SEMI geoloc-param) 327 locationURI = sip-URI / sips-URI / pres-URI 328 / cid-url ; (from RFC 2392) 329 / absoluteURI ; (from RFC 3261) 330 geoloc-param = "inserted-by" EQUAL geoloc-inserter 331 / "used-for-routing" 332 / generic-param ; (from RFC 3261) 333 geoloc-inserter = DQUOTE hostport DQUOTE 334 / gen-value ; (from RFC 3261) 336 sip-URI, sips-URI and absoluteURI are defined according to RFC 3261. 337 The pres-URI is defined in RFC 3859 [RFC3859]. 339 The cid-url is defined in [RFC2392] to locate message body 340 parts. This URI type MUST be present in a SIP request if location 341 is transmitted LbyV only. 343 Other protocols used in the Location URI MUST be reviewed against 344 the RFC 3693 criteria for a Using Protocol. 346 The Geolocation header MAY have one or more locationValues. SIP 347 servers inserting a locationValue MUST add the new value to the end 348 of the header value, such that the last locationValue in the header 349 is the most recent one added to the message. 351 A locationValue has the following independent header parameters, 353 o the "inserted-by=" parameter provides the hostport 354 (alice.example.com -- which is the same as the "sent-by" 355 parameter in a Via header, with or without a port number) of the 356 SIP entity that inserted this locationValue into the request. If 357 a Location Recipient has determined a supplied location is in 358 error, as there can be more than one in any request, the 359 "inserted-by=" parameter is copied into the locationErrorValue in 360 the response indicating the location error, and to whom the error 361 is for. Hence, this "inserted-by=" parameter MUST be present in 362 each locationValue. If an entity receives an Geolocation-Error 363 with a hostport not identifying this entity, the 364 Geolocation-Error MUST be ignored. 366 o the "used-for-routing" parameter to inform recipients that the 367 location in this locationValue was used to route the message 368 towards the ultimate destination UAS. "used-for-routing" can 369 occur more than once along the request's path. Because 370 locationValues are inserted as last inserted is last in the 371 header, the last locationValue is the most recent one added to 372 the message. This also gives the "used-for-routing" header 373 parameter added meaning - as the receiving SIP entity knows which 374 locationURI the message was routed upon. 376 Each locationValue MUST contain exactly one "inserted-by" parameter, 377 indicating which SIP entity added the locationValue to the SIP 378 request. 380 There MUST NOT be more than one "inserted-by=" parameter or one 381 "used-for-routing" parameter in the same locationValue. However, 382 there can be more than one locationValue in the same Geolocation 383 header. 385 This document defines the Geolocation header as valid in the 386 following SIP requests: 388 INVITE [RFC3261], REGISTER [RFC3261], 389 OPTIONS [RFC3261], BYE [RFC3261], 390 UPDATE [RFC3311], INFO [RFC2976], 391 MESSAGE [RFC3428], REFER [RFC3515], 392 SUBSCRIBE [RFC3265], NOTIFY [RFC3265], 393 PUBLISH [RFC3903] and PRACK [RFC3262] 395 Discussing location using the PUBLISH request is out of scope 396 for this document since it is part of Presence, therefore, for 397 completeness, Table 1 shows PUBLISH is to support Location 398 Conveyance via this extension, but is not discussed further. 400 The following table extends the values in Table 2&3 of RFC 3261 401 [RFC3261]. 403 Header field where proxy INV ACK CAN BYE REG OPT PRA 404 ---------------------------------------------------------------- 405 Geolocation R ar o - - o o o o 406 Header field where proxy SUB NOT UPD MSG REF INF PUB 407 ---------------------------------------------------------------- 408 Geolocation R ar o o o o o o o 410 Table 1: Summary of the Geolocation Header 412 The Geolocation header field MAY be included in any one of the above 413 requests by a UAC. A proxy MAY add the Geolocation header, but MUST 414 NOT modify any pre-existing locationValue, including any associated 415 header parameters within an existing Geolocation header value, 416 unless one of the existing locationValues is used to retarget the 417 request towards a new destination UAS. This is discussed in section 418 6.3. 420 [RFC3261] states message bodies cannot be added by proxies. 421 Therefore, any Geolocation header field added by a proxy MUST be in 422 the form of an LbyR URI, in its own locationValue header value. 424 Adding a new locationValue to an in-transit request SHOULD NOT 425 occur for at least two reasons 427 #1 - SIP Servers are not the best Sighters, as defined by [RFC3693], 428 of geographically where a UAC can be; meaning the location 429 information is not necessarily the greatest. There MAY be 430 exceptions, but this SHOULD be the rule of thumb. 432 #2 - without appropriate caution to the fact that Location 433 Recipients might not understand how to process more than one 434 location, given this document's limited guidance as to what a 435 Location Recipient should do when receiving more than one 436 location (i.e., currently no priority instructions are given 437 for which locationValue to use if there are more than one). A 438 Location Recipient can easily be confused by too much location 439 information, producing undesirable results. The 440 element in the PIDF-LO XML indicates whose location is 441 contained in the PIDF-LO. 443 Location Recipients receiving a location object, received directly 444 or as the result of a dereference, MUST honor the usage element 445 rules within that XML document, as defined in [RFC4119]. Such 446 entities MUST NOT alter the rule set. 448 4.2 424 (Bad Location Information) Response Code 450 This SIP extension creates a new Location specific response code, 451 defined as follows. 453 424 (Bad Location Information) 455 The 424 (Bad Location Information) response code is a rejection of 456 the request, due to its location contents, indicating the location 457 information was malformed or not satisfactory for the recipient's 458 purpose, or could not be dereferenced. 460 Section 4.3 creates the Geolocation-Error header to provide more 461 detail about what was wrong with the location information in the 462 request. This header MUST be in the 424 response, containing a 463 locationErrorValue for each invalid locationValue in the request 464 (i.e., and one-for-one matching if all locationValues in the request 465 were bad). 467 If more than one location is present in a request (LbyV or LbyR), 468 and any of the locationValues is good for the Location Recipient to 469 process, a 424 MUST NOT be sent. The 424 is only appropriate when 470 the Location Recipient needs a locationValue and there are no 471 locationValues included in a SIP request that are usable by a 472 recipient. 474 A 424 (Bad Location Information) response is a final response within 475 a transaction, and does not terminate a usage or a dialog. 477 The UAC can use whatever means it knows of to verify/refresh its 478 location information before attempting a new request that includes 479 location. There is no cross-transaction awareness expected by either 480 the UAS or any SIP intermediary as a result of this error message. 482 The new 424 (Bad Location Information) error code is IANA registered 483 in Section 8 of this document. An initial set of location error of 484 IANA registered Geolocation-Error codes are in Section 4.3 of this 485 document. 487 4.3 The Geolocation-Error Header 489 As discussed in Section 4.2, more granular error notifications, 490 specific to location errors within a received request, are required 491 if the UAC is to know what was wrong within the original request. 492 The Geolocation-Error header is created here for this purpose. 493 Geolocation-Error header is used to convey location specific errors 494 within a response. Additions to this IANA registered header require 495 an RFC be published. The Geolocation-Error header has the following 496 ABNF [RFC5234]: 498 Geolocation-Error = "Geolocation-Error" HCOLON 499 locationErrorValue 500 *(COMMA locationErrorValue) 501 locationErrorValue = location-error-code *(SEMI 502 location-error-params) 503 location-error-code = 1*3DIGIT 504 location-error-params = location-error-node-id 505 / location-error-host-id 506 / location-error-code-text 507 / generic-param ; from RFC3261 509 location-error-node-id = "node" EQUAL 510 DQOUTE hostport DQOUTE ; from RFC3261 511 location-error-host-id = "inserter" EQUAL 512 DQOUTE hostport DQOUTE ; from RFC3261 513 location-error-code-text = "code" EQUAL quoted-string ; from RFC3261 515 The Geolocation-Error header MUST contain at least one 516 locationErrorValue to indicate what was wrong with the original 517 locationValue in the corresponding request. If a Location Recipient 518 experienced more than one error a particular locationValue of the 519 corresponding SIP request, there can be one locationErrorValue per 520 problem with the locationValue in the request. Each 521 locationErrorValue contains one 3-digit error code indicating what 522 was wrong with the location in the request. Each error type has a 523 corresponding quoted error text string that is human 524 understandable. If there was something wrong with more than one 525 locationValue in a request, a corresponding locationErrorValue would 526 be sent, one per error, in the response. 528 Each locationErrorValue contains the Location Recipient identifier 529 (the "node=" parameter) which experienced the location error, as 530 well as an identifier of which SIP entity (the "inserter=" 531 parameter) the Location Recipient is told (in the locationValue) 532 added this problematic locationValue to the request. The "node=" 533 and "inserter=" are the domain identifier of a SIP entity, with the 534 ability to have the same host communicate on different ports - and 535 have port specific identification. This is the same as is entered in 536 the "sent-by" parameter of the Via header for that entity 537 [RFC3261]. As stated in section 18 of RFC 3261, the usage of FQDN 538 is RECOMMENDED. Here are examples of both locationErrorValue 539 parameters 541 node="bob.example.com" 543 inserter="alice.example.com" 545 Both the "node=" and "inserter=" parameters MUST be present in all 546 locationErrorValues in a response, unless the "inserted-by=" 547 parameter was not in the locationValue of a request (which is a 548 violation of this document). The "inserter=" parameter value is 549 copied from the "inserted-by=" parameter within the locationValue of 550 the request. No manipulation or calculation is necessary to 551 accomplish this. 553 Here's why this is necessary, a Location Recipient that experienced 554 the location problem with the request needs to tell the specific SIP 555 entity which added the locationValue in error into the original 556 request. Since more than one SIP entity can insert location into a 557 request in transit, all other SIP elements may be confused by 558 receiving this error header, were it to remain generic to all 559 entities in the response path. So, the header has to identify who 560 it is for, so that all other SIP entities that read the header know 561 to ignore it, since it is not for them. This is of particular use 562 if the original UAC did not include a locationValue in the original 563 SIP request, but a SIP server along the path did insert a 564 locationValue. The locationErrorValue would travel to each SIP 565 entity along the original path and tell both the server that 566 included the locationValue what was wrong with the location and the 567 UAC who did not know what the error meant. This will cause 568 confusion if left without this indication. 570 A worse case is when both the original UAC and a SIP server along 571 the path included a locationValue, but there was only something 572 wrong with one of the locationValues. Without this identification 573 of which locationValue was in error, both entities would react and 574 one would do so incorrectly. 576 More than one locationErrorValue in a Geolocation-Error header is 577 separated by a comma. 579 If more than one locationErrorValue is in a response, and intended 580 for the same "inserter=", each error code MUST be unique to this 581 "inserter=" entity, and the error codes SHOULD NOT conflict in 582 meaning. In other words, two error codes (within separate 583 locationErrorValues of the same response) SHOULD NOT give misleading 584 or inconsistent indications to the location "inserter=". 586 Here is an example of a Geolocation-Error header 588 Geolocation-Error: 200; code="Retry Location Later"; 589 node="bob.example.com"; 590 inserter="alice.example.com"; 592 The following table extends the values in Table 2&3 of RFC 3261 593 [RFC3261]. 595 Header field where proxy INV ACK CAN BYE REG OPT PRA 596 ---------------------------------------------------------------- 597 Geolocation-Error r ar o - - o o o o 599 Header field where proxy SUB NOT UPD MSG REF INF PUB 600 ---------------------------------------------------------------- 601 Geolocation-Error r ar o o o o o o o 603 Table 2: Summary of the Geolocation-Error Header 605 The Geolocation-Error header field MAY be included in any response 606 to one of the above SIP requests, so long as Geolocation was in the 607 request part of the transaction. The choice of which SIP requests 608 are in table 2 above come from which Methods can optionally have the 609 Geolocation header (see section 4.1). That said, a UAC MUST ignore 610 a Geolocation-Error header value if it did not include a Geolocation 611 header value in the request part of the transaction. 613 Here is an example of a transaction that has a location error. In 614 this case, Bob responds with a 424 (Bad Location Information) 615 response, including a Geolocation-Error header, is in Figure 1. 617 Alice Bob 618 | | 619 | Request w/ Location | 620 |------------------------------------------------>| 621 | | 622 | | 623 | 424 (Bad Location Information) | 624 | with Geolocation-Error containing | 625 | 200 ("Retry Location Later" (with same data)) | 626 |<------------------------------------------------| 627 | | 629 Figure 1. Basic Transaction with 424 and Geolocation-Error Header 631 The following subsections provide an initial list of location 632 based errors for any SIP non-100 response, including the new 424 633 (Bad Location Information) response. These error codes are divided 634 into 5 categories, each based on receiver (of the response) 635 actionable reactions to these errors. 637 o 100 "Cannot Process Location" 639 o 200 "Retry Location Later" (with same data) 641 o 300 "Retry Location Later" (with device updated location) 643 o 400 "Permission Necessary" 645 o 500 "Location Information Denial" 647 All 5 of the above error codes MUST be implemented to comply with 648 this specification. Each of these actionable errors is given a 3 649 digit error code category, meaning any future 1XX, 2XX, 3XX, 4XX, 650 and 5XX error codes defined will have the same action expected by 651 X00 categories. If another action is expected to occur with a newly 652 defined error code, it MUST outside the 100-599 range. 100 unit 653 ranges are OPTIONAL for future error codes, but they apply here. 655 4.3.1 Location Error: 100 "Cannot Process Location" 657 The location error 100 "Cannot Process Location" indicates to a 658 Geolocation-Error recipient that what they supplied in a request, as 659 far as location is concerned, cannot be processed at this time. 660 This only has to do with the location that the location "inserter=" 661 added to the request, and not about the overall request that was 662 sent. 664 Action(s) to be taken by Geolocation-Error receiver to a 1XX: 665 This error gives no guidance on what to do next. It is a 666 general information indication to a SIP "inserter=" entity 667 that there was an unspecific problem with the location 668 supplied in the SIP request. 670 Implementations MAY choose to react in a way as if this "inserter=" 671 entity received a 2XX or 3XX location error. A 4XX error MUST NOT be 672 misunderstood here, as that error category involves human 673 intervention to grant, or not, permission to reveal "inserter=" 674 location when this is likely not desired. 676 The text string of "Cannot Process Location" is RECOMMENDED, but not 677 mandatory for usage in this error. Implementations MAY use another 678 text string. 680 An example of this location error is here: 682 Geolocation-Error: 100; code="Cannot Process Location"; 683 node="bob.example.com"; 684 inserter="alice.example.com"; 686 This category covers location errors 1XX; meaning there MAY be more 687 specific errors added to this category in future effort(s). The 688 same basic actionable reaction is expected by a location "inserter=" 689 entity to any 1XX location error. 691 4.3.2 Location Error: 200 "Retry Location Later" (same data) 693 The location error 200 "Retry Location Later" (same data) indicates 694 to a Geolocation-Error recipient that what they supplied in a 695 request, as far as location is concerned, cannot be processed at 696 this time, but to retry this request, without changing the location 697 information, at a later time - in a new SIP request. It is possible 698 that the Location Recipient cannot process location at this time, or 699 there was a timeout during dereferencing, if an LbyR were sent. 701 Action(s) to be taken by Geolocation-Error receiver to a 2XX: 702 Reactions to a 2XX location error are to try again, without 703 having to update the location supplied originally. There is 704 no constraints on how long this new try has to wait, unless 705 there is a Retry-After header in a 424 response. 707 Implementations SHOULD choose to react by preparing, however this 708 "inserter=" does or can, to queue another message with the same 709 location information, provided the "inserter=" does not move between 710 the time of the original request and the transmission time of the 711 new request. 713 Implementations MAY choose whether or not to inform the user of this 714 error. The text string of "Retry Location Later" is RECOMMENDED, 715 but not mandatory for usage in this error. Implementations MAY use 716 another text string to inform the user that location was not 717 received by the UAS (i.e., the called party). 719 An example of this location error is here: 721 Geolocation-Error: 200; code="Retry Location Later"; 722 node="bob.example.com"; 723 inserter="alice.example.com"; 725 This category covers location errors 2XX; meaning there MAY be more 726 specific errors added to this category in future effort(s). The 727 same basic actionable reaction is expected by a location "inserter=" 728 entity to any 2XX location error. 730 4.3.3 Location Error: 300 "Retry Location Later" (device updated 731 location) 733 The location error 300 "Retry Location Later" (device updated 734 location) indicates to a Geolocation-Error recipient that what they 735 supplied in a request, as far as location is concerned, cannot be 736 processed at this time, but to retry this request, once the location 737 information has been updated, in a new SIP request. 739 Action(s) to be taken by Geolocation-Error receiver to a 3XX: 740 3XX location errors indicate the "inserter=" SIP entity needs 741 to refresh its location, or make the location information 742 supplied more complete, without notifying the user of this 743 error. 3XX error are to be solved by without user 744 intervention. 746 This document gives no guidance how this is accomplished, given the 747 number of ways a UAC can learn its location, or a SIP intermediary 748 can Sight a UAC, as defined in [RFC3693]. 750 This 300 location error currently does not indicate what exactly was 751 wrong with the location supplied, according to the Location 752 Recipient. That is left for a future effort. 754 Implementations MAY choose whether or not to inform the user of this 755 error. The text string of "Retry Location Later" is RECOMMENDED, 756 but not mandatory for usage in this error. Implementation MAY use 757 another text string to inform the user that location was not 758 received by the UAS (i.e., the called party). 760 A 3XX location error would be used where the Location Recipient 761 cannot find or cannot parse the location supplied, believing that a 762 automated refresh and retry could fix the problem. Also, a 3XX 763 location error would be used when a Location Recipient did not find 764 any location in a SIP request, but was expecting it. Perhaps an 765 emergency request was made that did not contain location. The retry 766 in this case would be in the form of an UPDATE Method request, 767 containing location (LbyV or LbyR). 769 An example of this location error is here: 771 Geolocation-Error: 300; code="Retry Location Later"; 772 node="bob.example.com"; 773 inserter="alice.example.com"; 775 This category covers location errors 3XX; meaning there MAY be more 776 specific errors added to this category in future effort(s). The 777 same basic actionable reaction is expected by a location "inserter=" 778 entity to any 3XX location error. 780 4.3.4 Location Error: 400 "Permission Necessary" 782 The location error 400 "Permission Necessary" indicates to a 783 Geolocation-Error recipient that when they set a particular SIP 784 request, they included location in that request without giving 785 permission in the request for a (or any) SIP server to look at that 786 location information to route the message at the intended recipient 787 (i.e., the UAS, or the called party). 789 Action(s) to be taken by Geolocation-Error receiver to a 4XX: 790 4XX location errors indicate to the UAC (i.e., the calling 791 party) that they need to grant permission to a SIP 792 intermediary server to look at the supplied location to 793 complete the message routing. This indication MUST require 794 human user intervention, as the rulemaker of the policy on 795 whether or not their location is to be revealed. 797 The user of the location "inserter=" device can choose to grant 798 permission to this SIP intermediary server to allow this request to 799 be routed, or the user can deny this location revelation (request by 800 the server). It is the user's choice as rulemaker. 802 Implementations MUST provide the user, as rulemaker, a clear 803 indication that permission to consume their location is sought by an 804 entity other than who that user is calling. The text string of 805 "Permission Necessary" is RECOMMENDED, but not mandatory for usage 806 in this error. Implementation MAY use another text string to inform 807 the user that location is being sought by an intermediary (i.e., not 808 the called party). 810 This document gives no guidance how this intervention is 811 accomplished, given the number of ways a UAC can accomplish this 812 (i.e., audio prompt or toggle or keystroke on their UA). 814 This 400 location error currently does not indicate exactly which 815 SIP server indicates it needs the location revealed. That said, the 816 "node=" FQDN address could be supplied, telling the user (via audio 817 or video indication) which SIP entity wants this location. Perhaps 818 the user can know in some circumstances whether this is an 819 appropriate "node=" (domain). All of this is left for a future 820 effort(s). 822 An example of this location error is here: 824 Geolocation-Error: 400; code="Permission Necessary"; 825 node="bob.example.com"; 826 inserter="alice.example.com"; 828 This category covers location errors 4XX; meaning there MAY be more 829 specific errors added to this category in future effort(s). The 830 same actionable solution is expected to be afforded to the UAC user, 831 as rulemaker, to any 4XX location error. 833 4.3.5 Location Error: 500 "Location Information Denial" 835 The location error 500 "Location Information Denial" indicates to a 836 Geolocation-Error recipient that what they supplied in a request, as 837 far as location is concerned, has been denied at this time. 838 This only has to do with the location that the location "inserter=" 839 added to the request, and not about the overall request that was 840 sent. If this were applied to the SIP request itself, this would 841 equate to a 6XX Global error. 843 Action(s) to be taken by Geolocation-Error receiver to a 1XX: 844 This error gives no guidance on what to do next, other than to 845 not try again with this same location supplied. 847 If the Location Recipient believed that merely refreshing, or in 848 some other way alter or augment the location supplied would work in 849 a new request, then a 3XX location error SHOULD have been returned 850 (to the "inserter="). An example of why this 5XX could have been 851 returned is if location were sent as an LbyR, and the LIS denied the 852 dereference request from the Location (reference) Recipient, this is 853 the expected location error returned to the "inserter=" entity. 855 Implementations MUST NOT interpret anything else into this location 856 error other than it is considered a location based denial error. 857 This does not mean the SIP request was denied, or even had an error, 858 unless the response was a 424. Otherwise, this only has to do with 859 the location part of the request. 861 The difference between a 1XX and a 5XX location error is simple. A 862 1XX location error is a case of a Location Recipient either not 863 knowing or not being able to tell the "inserter=" entity what was 864 wrong with the location supplied in a SIP request. Whereas, a 5XX 865 location error is where the location was purposely, and actively 866 denied (or declined) from being received by the Location Recipient 867 entity, or its user. This could occur in a UAS or SIP server. 869 If implementations choose to inform the UAC user of this error, the 870 text string of "Location Information Denial" is RECOMMENDED, but not 871 mandatory for usage in this error. Implementations MAY use another 872 text string. 874 An example of this location error is here: 876 Geolocation-Error: 500; code="Location Information Denial"; 877 node="bob.example.com"; 878 inserter="alice.example.com"; 880 This category covers location errors 5XX; meaning there MAY be more 881 specific errors added to this category in future effort(s). The 882 same basic actionable reaction is expected by a location "inserter=" 883 entity to any 5XX location error. 885 4.3.6 Which Scenario Matches Which Error Code? 887 The following are some additional failure scenarios, with which 888 error code SHOULD be used for consistency, 890 - Scheme (sip:, or sips:, or pres:, or another one) of the LbyR URI 891 isn't supported (100) 892 - Format (geo or civic) isn't supported (100) 893 - Cannot parse location (100) 894 - Can't find LIS (no access or no path (100) or denied access(500)) 895 - Dereference failed (timeout) (200) 896 - Insufficient location info supplied (300) 897 - Cannot find location in message (300) 899 4.4 The 'geolocation' Option Tag 901 This document creates and IANA registers one new option tag: 902 "geolocation". This option tag is to be used, as defined in RFC 903 3261, in the Require, Supported and Unsupported headers. Whenever a 904 UA wants to indicate support for this SIP extension, the geolocation 905 option tag is included in a Supported header of the SIP request. 907 4.5 Using sip/sips/pres as a Dereference Scheme 909 If an LbyR URI is included in a SIP request, it MUST be a SIP, SIPS 910 or PRES-URI. When PRES: is used, if the resulting resolution, as 911 defined in [RFC3856], resolves to a SIP: or SIPS: URI, this 912 section applies. 914 This document IANA registers 3 mandatory to implement URI schemes 915 for LbyR: 917 o SIP: 918 o SIPS: 919 o PRES: 921 These 3 are IANA registered in Section 9.6. 923 These schemes MUST be implemented according to this document. 924 absoluteURI is not mandatory to implement. 926 Dereferencing a Target's location using SIP or SIPS MUST be 927 accomplished by treating the URI as a presence URI and generating a 928 SUBSCRIBE request to a presence server as defined in [RFC3856] 929 using the 'presence' event package. The resulting NOTIFY will 930 contain a PIDF, which MUST contain a PIDF-LO. See Figure 2. for a 931 basic message flow for a dereference. 933 When used in this manner, SIP is a Using Protocol as defined in 934 [RFC3693] and elements receiving location MUST honor the 935 'usage-element' rules as defined in this extension. 937 Alice Location Server Bob 938 | | 939 | INVITE w/ LbyR URI | 940 |-------------------------------------------------------->| 941 | | | 942 | 200 (OK) | 943 |<--------------------------------------------------------| 944 | | | 945 | | SUBSCRIBE to LbyR URI | 946 | |<-----------------------------| 947 | | 200 (OK) | 948 | |----------------------------->| 949 | | | 950 | | NOTIFY w/ PIDF-LO | 951 | |----------------------------->| 952 | | 200 (OK) | 953 | |<-----------------------------| 954 | | | 956 Figure 2. Location-by-Reference and Dereferencing 958 In Figure 2., Alice sends Bob her location in an LbyR URI. Bob 959 receives this LbyR URI in the INVITE and generates a new transaction 960 (SUBSCRIBE) to retrieve the PIDF-LO of Alice. If accepted, the 961 PIDF-LO will be in the NOTIFY request from the Location Server back 962 to Bob's UA. This is the first instance between Alice and Bob that 963 Alice's location is in any message, therefore it is sent only once, 964 from the Location Server to Bob. 966 The SUBSCRIBE contains a geolocation option tag in either the 967 Supported or Require header (depending on what strength of support 968 the UAC wants to apply). The NOTIFY MUST match the subscribing 969 UAC's option-tag strength for geolocation. 971 A dereference of an LbyR URI using SUBSCRIBE is not violating a 972 PIDF-LO 'retransmission-allowed' element value set to 'no', as the 973 NOTIFY is the only message in this multi-message set of transactions 974 that contains the Target's location, with the location recipient 975 being the only SIP element to receive this PIDF-LO. This is the 976 purpose of this extension to SIP - to convey location to a specific 977 destination. 979 5. Geolocation Examples 981 This section contains are two examples of messages providing 982 location. One shows LbyV with coordinates, the other shows LbyR. 983 The example for (Coordinate format) is taken from [RFC3825]. A 984 civic format example of the same position on the earth as is in the 985 coordinate format example is in appendix B, which is taken from 986 [RFC4776]. The differences between the two formats are within the 987 of the examples. Other than this portion of each 988 PIDF-LO, the rest is the same for both location formats. 990 The key to the provided samples is in the Geolocation header, which 991 has a different type of URI, based on the different means of 992 location conveyance. Section 5.1 shows a "cid:" URI, indicating 993 this SIP request contains an LbyV message body - which is in the 994 form of a PIDF-LO. Section 5.2 shows an LbyR URI indicating 995 location is to be acquired via an indirection dereference mechanism, 996 which is determined by the scheme of URI supplied. 998 5.1 Location-by-value (Coordinate Format) 1000 This example shows an INVITE message with a coordinate, or 1001 coordinate location. In this example, the SIP request uses a 1002 sips-URI [RFC3261], meaning this message is TLS protected on a 1003 hop-by-hop basis all the way to Bob's domain. 1005 INVITE sips:bob@biloxi.example.com SIP/2.0 1006 Via: SIPS/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bK74bf9 1007 Max-Forwards: 70 1008 To: Bob 1009 From: Alice ;tag=9fxced76sl 1010 Call-ID: 3848276298220188511@atlanta.example.com 1011 Geolocation: 1012 ;inserted-by="alice@atlanta.example.com" 1013 Supported: geolocation 1014 Accept: application/sdp, application/pidf+xml 1015 CSeq: 31862 INVITE 1016 Contact: 1017 Content-Type: multipart/mixed; boundary=boundary1 1018 Content-Length: ... 1020 --boundary1 1022 Content-Type: application/sdp 1024 ...SDP goes here 1026 --boundary1 1028 Content-Type: application/pidf+xml 1029 Content-ID: target123@atlanta.example.com 1031 1032 1037 1038 2007-12-02T14:00:00Z 1039 1040 1041 1042 1043 1044 33.001111 -96.68142 1045 1046 1047 1048 1049 no 1050 2007-12-07T18:00:00Z 1052 1053 DHCP 1054 www.example.com 1055 1056 1057 1058 1059 --boundary1-- 1061 The Geolocation header field from the above INVITE... 1063 Geolocation: 1065 ...indicates the content-ID location [RFC2392] within the multipart 1066 message body of where location information is, with SDP being the 1067 other message body part. The "cid:" eases parsing of message 1068 bodies. 1070 If the Geolocation header field were this instead: 1072 Geolocation: 1074 ...the presence of something other than "cid:" indicates an LbyR is 1075 included in this message. It is expected that any node wanting to 1076 know where user target123 is would subscribe to server5 to 1077 dereference the sips-URI (see Figure 2. for this message flow, and 1078 Section 5.2 for this decoded example). The returning NOTIFY would 1079 contain Alice's location in a PIDF-LO, as if it were included in a 1080 message body (part) of the original INVITE here. 1082 5.2 Location-by-reference 1084 Below is an INVITE request with an LbyR URI instead of an LbyV 1085 PIDF-LO message body part shown in Section 5.1. It is up to the 1086 location recipient to dereference Alice's location at the Atlanta 1087 LIS server containing the location record. Dereferencing, if done 1088 with SIP, is accomplished by the Location Recipient sending a 1089 SUBSCRIBE request to the URI reference for Alice's location. The 1090 received NOTIFY is the first SIP request containing Alice's UA 1091 location, as a PIDF-LO message body (see Figure 2 for this message 1092 flow example). The NOTIFY, in this case, is the SIP request that is 1093 conveying location, and not the INVITE. There is no retransmission 1094 of location in this usage. 1096 INVITE sips:bob@biloxi.example.com SIP/2.0 1097 Via: SIP/2.0/TLS pc33.atlanta.example.com 1098 ;branch=z9hG4bK74bf9 1099 Max-Forwards: 70 1100 To: Bob 1101 From: Alice ;tag=9fxced76sl 1102 Call-ID: 3848276298220188511@atlanta.example.com 1103 Geolocation: 1104 ;inserted-by="bigbox3.atlanta.example.com" 1105 Supported: geolocation 1106 Accept: application/sdp, application/pidf+xml 1107 CSeq: 31862 INVITE 1108 Contact: 1110 (...SDP goes here as the only message body) 1112 A Location Recipient would need to dereference the sips-URI in the 1113 Geolocation header field to retrieve Alice's location. If the 1114 atlanta.example.com domain chooses to implement location conveyance 1115 and delivery in this fashion (i.e., LbyR), it is RECOMMENDED that 1116 entities outside this domain be able to reach the dereference 1117 server, otherwise this model of implementation is only viable within 1118 the atlanta.example.com domain. 1120 6. SIP Element Behavior 1122 Because a device's location is generally considered to be sensitive 1123 in nature, location information needs to be protected when 1124 transmitted. This can be addressed through securing the location 1125 information to prevent either viewing or changing the PIDF-LO. 1127 Section 26 of [RFC3261] defines the security functionality SIPS by 1128 transporting SIP messages with either TLS or IPSec protection 1129 between SIP entities. 1131 If a SIP entity wants to prevent all SIP entities in a request path 1132 from viewing or just changing the contents of the PIDF-LO, save 1133 those that possess decryption key, the message body needs to be 1134 secure by a means such as S/MIME. This would be the case in which a 1135 UAC wants to make sure only the destination UAS can read the 1136 PIDF-LO. S/MIME can be used for just signing, and not encrypting, a 1137 PIDF-LO message body to ensure the integrity of the PIDF-LO is 1138 maintained. 1140 6.1 UAC Behavior 1142 A UAC can send location in a SIP request, either because it is 1143 expected to facilitate location-based routing of the request, or 1144 spontaneously (i.e., a purpose not defined in this document but 1145 known to the UAC). Alice communicating to Bob her location in a SIP 1146 Message request is a simple example of this. If Alice wanted to 1147 include her location as a message body in an INVITE that also has an 1148 SDP message body, the Content-Type: Multipart MUST be supported by 1149 both UAC and UAS. Multipart comes in many forms (/mixed, 1150 /alternative, etc), and this document does not limit which type of 1151 Multipart is used, though future documents MAY specify or limit 1152 Multipart to a subset of all the choices for a given use. 1154 A UAC conveying location MUST include a locationValue in a 1155 Geolocation header (see section 4.1) with either an LbyV indication 1156 (a cid-URL), or an LbyR. An LbyV message body sent without a 1157 Geolocation header field MUST NOT occur. The UAC supporting this 1158 extension MUST include a Supported header with the 'geolocation' 1159 option tag. 1161 More than one location format (civic and coordinate) can be included 1162 in the same message body part, but all location parts of the same 1163 PIDF-LO MUST point at the same position on the earth, identifying 1164 the same target. The same location in multiple formats, for 1165 example, a partial or complete geodetic and a partial or complete 1166 civic, can allow the recipient to use the most convenient or 1167 preferable format for its use. 1169 Multiple PIDF-LOs are allowed in the same request, with each allowed 1170 to point at separate positions - however, each PIDF-LO MUST identify 1171 a different Target. Therefore, there will be no confusion by a 1172 Location Recipient receiving more than one PIDF-LO (in a message 1173 body or when dereferenced, or a combination). It is RECOMMENDED 1174 there is only one locationValue in a single SIP request for the same 1175 Target. More than one will likely lead to confusion by a Location 1176 Recipient because this extension does not provide guidance on what a 1177 recipient is to do with more than one location, nor does it give any 1178 preference regarding which location is better or worse than another 1179 location in the same request. 1181 The 'geolocation' option tag is inserted in a Supported header by a 1182 UAC to provide an indication of support for this extension. The 1183 presence of the 'geolocation' option tag in a Supported header 1184 without a Geolocation header field in the same message informs a SIP 1185 element receiving this request that the UAC understands this 1186 extension, but it does not know or wish to convey its location at 1187 this time. Certain scenarios exist (location-based retargeting) in 1188 which location is required in a SIP request in order to retarget the 1189 message properly. This affects how a UAS or SIP server processes 1190 such a request. 1192 The 'geolocation' option tag SHOULD NOT be used in the Proxy-Require 1193 Header, because the UAC often will not know the underlying topology 1194 to know which proxy will do the retargeting, thus increasing the 1195 likelihood of a request failure by the first hop proxy that does not 1196 understand this extension, but is required to by inclusion of the 1197 option tag in this header. 1199 A UAC inserting a locationValue MUST include an "inserted-by=" 1200 parameter to indicate its hostport. This is copied to the 1201 "inserter=" parameter of the Geolocation-Error header in a response 1202 if a Location Recipient determines there is something wrong with the 1203 locationValue in this request. Because more than one locationValue 1204 can be inserted along the path of the request, this indication is 1205 necessary to show which locationValue had the problem in the 1206 response, and who the locationErrorValue is for. For example: 1208 Geolocation: ; 1209 inserted-by="alice@atlanta.example.com" 1211 If a UAC does not learn and store its location locally (a GPS chip) 1212 or from the network (DHCP or LLDP-MED), the UAC MAY learn its LbyR 1213 URI (from DHCP for example). If the latter is the case, the UAC MAY 1214 SUBSCRIBE to this LbyR URI, using the 'presence' event package, to 1215 get and store its own location. 1217 The act of dereferencing a Target's LbyR will be challenged by the 1218 LIS were this location record is - providing a good deal of 1219 protection, SHOULD still be treated as equivalent to possession of 1220 the location information itself and thus TLS SHOULD be used when 1221 transmitting LbyR hop-by-hop along the path to the Location 1222 Recipient, for protection reasons. This is not to be confused with 1223 a possession model, in which possessing the LbyR grants 1224 authorization to dereference the URI. Any entity dereferencing the 1225 LbyR MUST pass whatever authentication and authorization rules are 1226 on the LIS for this location record. The Rulemaker from [RFC3693] 1227 is still very much in control - for any entity possessing the LbyR. 1229 If a UAC has already conveyed location in the original request of a 1230 transaction, and wants to update its location information (for 1231 whatever reason) after the original request is sent, or after a 1232 dialog is created (regardless of how the UAC conveyed location 1233 previously, as an LbyV or LbyR) - this is done by a UAC sending an 1234 UPDATE request [RFC3311] containing the geolocation option tag and 1235 Geolocation header with the new locationValue (LbyV or LbyR) to the 1236 original destination UAS. 1238 A PIDF includes identity information. It is possible for the 1239 identity in the PIDF to be anonymous. Implementations of this 1240 extension SHOULD consider the appropriateness of including an 1241 anonymous identity in the location information where a real identity 1242 is not required. When using LbyR, the LbyR MUST NOT contain any 1243 user identifying information. For example, use something 1244 unidentifiable like 1246 3fg5t5yqw@example.atlanta.com 1248 rather than 1250 aliceishere@example.atlanta.com). 1252 Use of self-signed certificates is inappropriate for use in 1253 protecting a PIDF, as the sender does not have a secure identity of 1254 the recipient. 1256 6.1.1 UAC Receiving a Location Failure Indication 1258 Location Recipients can be either, or both, destination UASs and 1259 intermediate servers that use the location information for 1260 location-based routing decisions. If a sent request fails based on 1261 the location information in the request, a 424 (Bad Location 1262 Information) response is sent back to the UAC. The 424 MUST have a 1263 Geolocation-Error header containing one or more locationErrorValues 1264 in the response message. A locationErrorValue has a header 1265 parameter indicating which entity inserted the locationValue 1266 correlated to this error, called the "inserter=" parameter. This 1267 "inserter=" parameter (in the locationErrorValue) is copied from the 1268 "inserted-by=" parameter (from the locationValue) by the Location 1269 Recipient (UAS or proxy) sending the error response. A UAC 1270 receiving a Geolocation-Error in any response type MUST review the 1271 "inserter=" parameter in the locationErrorValue to see if it 1272 indicates this UAC. If locationErrorValue does not match, the 1273 locationErrorValue MUST be ignored. If a locationErrorValue is in a 1274 424, and the "inserter=" entity is not this UAC, the response SHOULD 1275 be treated as a 400 response. If locationErrorValue does indicate 1276 this UAC, this UAC MUST process the response, including the 1277 Geolocation-Error code (defined in section 4.3). Further, UAC MUST 1278 ignore a Geolocation-Error header value, even for this UAC, even in 1279 a 424 response if the UAC did not include a Geolocation header value 1280 (with locationValue) in the request part of the transaction. 1282 A UAC MAY reattempt a new request if it believes it can correct the 1283 stated failure in the Geolocation-Error header, unless the location 1284 error is a 5XX level error - which clearly states in Section 4.3 not 1285 to do this. A UAC MUST follow all the guidance that pertains to 1286 UACs from Section 4.3 (Geolocation-Error header), heeding what to do 1287 in case it receives any of the error codes articulated in that 1288 section. 1290 Any UAC that inserted location into a request SHOULD be prepared to 1291 receive the Geolocation-Error header in any response, looking to 1292 determine if a locationErrorValue is meant for the UAC, and to react 1293 accordingly. 1295 If a UAC includes location in a request, and either the UAS does not 1296 determine errored location was critical to the transaction and 1297 accept the request, or the request failed for reason other than 1298 location, any response MAY contain a Geolocation-Error header 1299 containing a locationErrorValue with the details of the location 1300 error. 1302 6.2 UAS Behavior 1304 If the Geolocation header field is present in a received SIP 1305 request, the type of URI contained in the locationValue will 1306 indicate if location is an LbyV in a message body (part) or LbyR, 1307 requiring an additional dereference transaction. If the LbyR URI is 1308 sip:, sips: or pres:, and the UAS wants to learn the UAC's location, 1309 the UAS MUST initiate a SUBSCRIBE to the URI provided to retrieve 1310 the PIDF-LO being conveyed by the UAC as defined in [RFC3856]. If 1311 successful, the PIDF-LO will be returned in the NOTIFY request from 1312 the remote host. The UAS is not REQUIRED to dereference the LbyR if 1313 it does not want to (by configuration or user choice). It is 1314 RECOMMENDED the UAS render the location sent to it, however it is 1315 configured to do so. 1317 A Require header with the 'geolocation' option tag indicates the 1318 UAC is requiring the UAS understand this extension or else send 1319 an error response. A 420 (Bad Extension) with a 'geolocation' 1320 option tag in an Unsupported header would be the appropriate 1321 response in this case. 1323 It is possible, but undesirable, for a message to arrive with a body 1324 containing an LbyV, but with no Geolocation header field value 1325 pointing to it (potentially no Geolocation header field at all). In 1326 this case, the recipient MAY still read and use the message body. 1327 Unless stated otherwise by future standards-track publication(s), a 1328 LbyR URI only has meaning within the Geolocation header field and 1329 MUST NOT appear in any other SIP header field. 1331 There are 2 Geolocation header parameters, 1333 o "inserted-by=" 1334 o "used-for-routing" 1336 The "inserted-by=" parameter informs a Location Recipient which SIP 1337 element added this locationValue to the SIP request. This parameter 1338 is mandatory for each locationValue in the request. The value in 1339 the "inserted-by=" parameter is copied into the "inserter=" 1340 parameter in each locationErrorValue if there is an error in the 1341 location to be reported back to the location sender. See section 1342 6.2.1. 1344 The "used-for-routing" parameter is included in the locationValue if 1345 a SIP server used the location in the request to determine how to 1346 route or forward the message towards the ultimate destination. If 1347 there are more than one locationValues in the Geolocation header, 1348 and it is possible that different locationValues were used to route 1349 the message at different times of this request's journey. This is 1350 allowed, as it is consistent with the rule that anytime a message is 1351 routed based upon a locationValue, a "used-for-routing" parameter is 1352 added to the applicable locationValue. This parameter should be 1353 present in each locationValue used along the path. A 1354 "used-for-routing" parameter MUST NOT ever be removed from a 1355 locationValue in a request. 1357 Additional locationValues inserted into a request SHOULD be placed 1358 the order they were generated, and not rearranged. This informs a 1359 Location Recipient which was the last locationValue in the message 1360 that was used to route the message. This is for troubleshooting and 1361 management reasons. 1363 Individual header parameters in any received locationValue MUST NOT 1364 be modified or deleted in transit to the ultimate destination. 1366 A UAS MUST NOT send location in a response message, as there can be 1367 any number of issues/problems with receiving location, and the UAC 1368 or proxy servers cannot error a response. Therefore, the UAS, if it 1369 wants to send a UAC its location, SHOULD do so in a new request in a 1370 separate transaction. This document gives no guidance which SIP 1371 request to use, but SIP MESSAGE is a viable choice. 1373 A UAS MAY include a 'geolocation' option tag in the Supported header 1374 of a response, indicating it does understand this extension, even if 1375 location was not in a request to the UAS. 1377 A UAS wishing to dereference an LbyR URI contained in a received 1378 request will use the 'presence' event package in a SUBSCRIBE request 1379 to the URI. If accepted, the PIDF-LO will return to the UAS in a 1380 NOTIFY request. If there are any errors during dereferencing, or in 1381 the PIDF-LO itself, the UAS will error the original request to the 1382 UAC with a locationErrorValue indicating what the UAS concluded was 1383 wrong with the location. This is to include any dereferencing 1384 problems encountered. 1386 Section 4.5 of this document called for the IANA registration of 3 1387 URI schemes (sip:, sips:, and pres:) that are mandatory to implement 1388 for dereferencing. 1390 A UAS MUST be prepared to receive subsequent location updates from 1391 the UAC, either LbyV or LbyR (regardless of how the UAS received 1392 location previously from this UAC). The UAC will convey location 1393 using the UPDATE [RFC3311] method to the UAS. 1395 If there is more than one location (any combination of LbyV and 1396 LbyR), this document does not give guidance what a Location 1397 Recipient does with each location. There are no priority or 1398 more-trusted indications given by this document. All this is 1399 considered application specific, and out-of-scope of this document. 1400 This document makes it clear that if when there are more than one 1401 location, each in the same PIDF-LO MUST be about the same Target 1402 (identifier) and point at the same position on the earth. If there 1403 is more than one PIDF-LO with different Target identifiers, then 1404 the UAC is merely telling the UAS where more than one Target is, and 1405 there should not be any conflict. 1407 6.2.1 UAS Generating a Location Failure Indication 1409 If a UAS receives location in a request, but determines there is a 1410 problem with the location in the request, it is the responsibility 1411 of the UAS to inform whomever inserted location into that request 1412 there was a problem experienced. The Geolocation header in the 1413 request has a locationValue, providing the UAS a URI indicating 1414 where the Target's location is. The Location Target identified in 1415 the PIDF-LO may or may not be the location inserter, or the 1416 generator of the request (the UAC or SIP server). Ultimately, 1417 location is in a PIDF-LO. This is either in the request as a 1418 message body (LbyV), or it has to be dereferenced from the LbyR in 1419 the locationValue in the request. LbyR records are typically kept 1420 on a LIS, which can challenge all dereference requests. All 1421 PIDF-LOs have a Location Target identifier. This is who the 1422 location is about. The "inserted-by=" parameter of the 1423 locationValue tells the UAS who inserted that locationValue. This 1424 "inserted-by=" parameter is copied into the "inserter=" parameter of 1425 the locationErrorValue generated by the Location Recipient (the 1426 UAS), in a response, when it wants to inform the location 1427 "inserter=" entity there was a problem with the location it 1428 received. 1430 There can be more than one locationValues in a request. The 1431 "inserter=" parameter in the locationErrorValue will distinguish it 1432 from being misunderstood by entities that did not insert the errored 1433 location. 1435 If there is one valid locationValue in a request, even if all the 1436 others have errors with them, a 424 (Bad Location Information) 1437 response MUST NOT be sent. The Location Recipient (the UAS) is 1438 RECOMMENDED to send a locationErrorValue for each errored 1439 locationValue, with unique "inserter=" parameters to make sure the 1440 right entities know which locations were in error. 1442 As hinted at, a location "inserter=" can be a UAC or it can be an 1443 in-signaling-path SIP server, who is acting as a UAC Sighter, as 1444 defined in RFC3693. This means the SIP server is including its 1445 version of where it thinks the UAC is, geographically. This 1446 "inserter=" has to be in the form of an LbyR URI in a locationValue, 1447 because SIP servers are not allowed to insert message bodies, as of 1448 the time of this publication, from all the way back to RFC3261. 1450 Each locationErrorValue has a error code, letting the location 1451 "inserter=" entity know what was wrong with the location supplied. 1452 See Section 4.3 for the 5 actionable responses a UAC can take from 1453 a locationErrorValue. 1454 If the location "inserted-by=" entity, meaning either the UAC or 1455 proxy in the message path, chose to indicate that location was so 1456 important in the request to include a 'geolocation' option tag in a 1457 Require header, the response SHOULD be a 424 (Bad Location 1458 Information) back to the "inserter=" entity (knowing the response 1459 will ultimately go to the UAC regardless) if there needs to be a 1460 locationErrorValue sent because the location was bad. Only entities 1461 identified in a locationErrorValue as the "inserter=" entity will 1462 pay attention to this locationErrorValue. All other entities MUST 1463 ignore any locationErrorValue not directed towards them. See 1464 section 4.3 for more information on this, including all the location 1465 specific errors and Geolocation-Error header parameters. 1467 In the above scenario ('geolocation' option tag in a Require 1468 header), the only other response can be a 420, but only if the UAS 1469 does not support this Geolocation extension to SIP, else the 424 is 1470 sent. 1472 If the location "inserted-by=" entity placed the 'geolocation' 1473 option tag in a Supported header, the response can be a 424 if it 1474 chooses, but also can be any other SIP response, including a 200 1475 OK. A locationErrorValue in a Geolocation-Error header that is not 1476 in a 424 (Bad Location Information) response is considered 1477 informational by the Location Recipient, and not considered 1478 important enough to reject the request based solely on bad location 1479 information. 1481 For example, Alice INVITEs Bob to a dialog, and includes geolocation 1482 in the request. Bob can accept the INVITE with a 200 OK and still 1483 add a locationErrorValue in the 200 OK indicating "yes, I accept 1484 your request, and btw, something was wrong with the location you 1485 provided (in the INVITE)". What was wrong with the location is 1486 indicated by the Geolocation-Error code. Who this 1487 locationErrorValue is for is indicated by the "inserter=" parameter. 1489 Each locationErrorValue is destined for one "inserter=" entity. 1490 This gives a Location Recipient one mechanism to tell each inserter 1491 what the Location Recipient concluded was wrong with what the 1492 "inserter=" included (as far as location is concerned). Therefore, 1494 o there MUST be a locationErrorValue for each locationValue that 1495 was considered bad by the UAS to ensure each upstream location 1496 inserter understands which error code(s) is intended for them 1497 (and which to ignore). 1499 o there MUST NOT be more than one locationErrorValue in the 1500 response per locationValue in the request. 1502 o there MUST NOT be more than one locationErrorValue to the same 1503 "inserter=" in the request. 1505 o there MUST NOT be a locationErrorValue in the response for a 1506 locationValue in the request that was not in error, according to 1507 the Location Recipient. 1509 Here is an example of a Geolocation-Error header 1511 Geolocation-Error: 400; code="Permission Necessary"; 1512 node="server42.example2.com"; 1513 inserter="alice.example.com"; 1515 The above example says that the Location Recipient is 1516 server42.example.com, and this entity believes it cannot route this 1517 message without knowing the "inserter="'s location. This location 1518 may be in the request, or it may need to be in the request and was 1519 not. If location is encrypted, server42 doesn't know it is in the 1520 request. server42.example.com sends a 424 (Bad Location 1521 Information) response with a locationErrorValue indicating a 400 1522 location error, which means it requires permission to view Alice's 1523 location to proceed with processing her signaling. Section 4.3 1524 highlights this example, stating the user, Alice, MUST be made aware 1525 of this location revelation request. This document does not give 1526 any guidance how Alice is to be informed (i.e., audio, visual, 1527 etc). Alice can grant permission or choose not to, knowing this SIP 1528 request attempt (to this destination, at this time) will fail. The 1529 problem could be corrected if a future SIP request were to travel 1530 through a different server than server42 (or it might not). 1532 See Section 4.3 for further rules about the Geolocation-Error header 1533 and the locationErrorValue. 1535 This document says nothing about what a Location Recipient does with 1536 more than one 'good' locationValue in a request (i.e., which to 1537 choose to use). This scenario MAY be addressed in a future effort. 1539 Further, more than one error code is allowed in the 1540 locationErrorValue - each having one "inserter=" parameter. The 1541 error codes destined for the same inserter MUST NOT contradict the 1542 meaning of the problem the Location Recipient had with a particular 1543 locationValue. 1545 6.3 Proxy Behavior 1547 [RFC3261] states message bodies cannot be added by proxies. 1548 However, proxies are permitted to add a header to a request. This 1549 implies that a proxy can add a Geolocation locationValue with 1550 LbyR URI, but not LbyV message body. 1552 It is allowed, but NOT RECOMMENDED, for more than one SIP element to 1553 insert location into a request along its path. As described earlier 1554 in this document, each insertion of location into a SIP request is 1555 accompanied by a new locationValue in a Geolocation header. Also 1556 described earlier, each locationValue MUST contain an "inserted-by=" 1557 value indicating to a Location Recipient which host inserted 1558 location into a particular request. 1560 However, if location is already in a SIP request, a SIP server 1561 SHOULD NOT add another LbyR that identifies the same target in the 1562 PIDF-LO (in the element) to the same request. This will 1563 likely cause confusion at the Location Recipient as to which to use. 1565 A proxy is permitted to read any locationValue, and the associated 1566 body, if not S/MIME protected, in transit if present, and can use 1567 the contents of the header field to make location-based retargeting 1568 decisions, if retargeting requests based on location is a function 1569 of that proxy. Retargeting is defined in [RFC3261]. 1571 More than one Geolocation locationValue in a message is permitted, 1572 but can cause confusion at the recipient. If a proxy chooses to add 1573 a locationValue to a Geolocation header, which would be a local 1574 policy decision, the new locationValue MUST be added to the end of 1575 the header (after previous locationValue(s)). This is done to 1576 create an order of insertion of locationValues along the path. 1577 Proxies MUST NOT modify the order of locationValues in a geolocation 1578 header. 1580 A proxy wishing to dereference an LbyR URI contained in a received 1581 request will use the 'presence' event package in a SUBSCRIBE request 1582 to the URI. If accepted, the PIDF-LO will return to the proxy in a 1583 NOTIFY request. If there are any errors during dereferencing, or in 1584 the PIDF-LO itself, the proxy will error the original request to the 1585 UAC with a locationErrorValue indicating what the proxy concluded 1586 was wrong with the location. This is to include any dereferencing 1587 problems encountered. 1589 6.3.1 Proxy Behavior with Geolocation Header Parameters 1591 SIP servers MUST NOT delete any existing Geolocation locationValue 1592 (URI or header parameter) from a request. An existing locationValue 1593 (URI or header parameter) MAY only be modified by adding a 1594 "used-for-routing" parameter to an existing locationValue, if the 1595 request was retargeted based on the location within that 1596 locationValue. Further modification of this Geolocation header 1597 field MUST NOT occur. For example, an existing Geolocation 1598 locationValue in a request of: 1600 Geolocation: ; 1601 inserted-by="alice123@atlanta.example.com"; 1603 can be modified by a proxy to add the "used-for-routing" parameter, 1604 like this: 1606 Geolocation: ; 1607 inserted-by="alice123@atlanta.example.com"; 1608 used-for-routing 1610 if this is the locationValue the proxy used to make a retargeting 1611 decision based upon, but make no other modification. 1613 A SIP server MAY add a new Geolocation locationValue to a SIP 1614 request. The proxy SHOULD NOT insert a locationValue of a Location 1615 Target unless it is reasonably certain it knows the actual location 1616 of the Location Target, for example, if it thoroughly understands 1617 the topology of the underlying access network and it can identify 1618 the device reliably (in the presence of, for example, NAT or VPN). 1620 A server adding a locationValue to an existing Geolocation header 1621 would look like: 1623 Geolocation: ; 1624 inserted-by="alice123@atlanta.example.com", 1625 ; 1626 inserted-by="lis1.atlanta.example.com" 1628 Notice the locationValue added by the proxy is last among 1629 locationValues. This practice MUST be done for all added 1630 locationValues. 1632 If this request was then retargeted by an intermediary using the 1633 locationValue inserted by the server, the intermediary would add a 1634 "used-for-routing" parameter like this: 1636 Geolocation: ; 1637 inserted-by="alice123@atlanta.example.com", 1638 ; 1639 inserted-by="lis1.atlanta.example.com"; used-for-routing 1641 It is conceivable that an initial routing decision is made on 1642 one locationValue, and subsequently another routing decision is 1643 made on a different locationValue further towards the ultimate 1644 destination. This retargeting decision can be made on a newly 1645 inserted locationValue. While unusual, it can occur. In such a 1646 case, proxies MUST NOT remove any existing "used-for-routing" header 1647 parameter. In this instance, the SIP server retargeting based on 1648 another locationValue MUST add the "used-for-routing" header 1649 parameter to the locationValue used for retargeting by this server. 1650 This will result in a Geolocation header looking as if it were 1651 retargeting more than once, which would be true - and is the desired 1652 outcome. 1654 A Proxy that inserts or adds locationValue into a request MAY move a 1655 'geolocation' option that is in a Supported header into a Require 1656 header if this proxy deems geolocation to be that important to 1657 Location Recipient(s) of this request. 1659 6.3.2 Proxy Error Behavior for Sending or Receiving locationErrorValues 1661 For proxies that receive a SIP request that contains a location 1662 error, either in a contained message body or after the proxy does a 1663 dereference of the LbyR URI, all the rules applicable to a UAS apply 1664 here (see Section 6.2.1.), since in this case, the proxy is 1665 considered a Location Recipient. Therefore, there is no reason to 1666 restate them here, and potentially have the two sections be 1667 inconsistent. The one thing to add is that a proxy does not need to 1668 examine location contained in a request. Section 6.2.1. only applies 1669 to proxies that are needing, monitoring or policing location within 1670 requests (for whatever reason). 1672 If a proxy inserted a locationValue into a request, it SHOULD be 1673 ready to examine the response to that request, in case there is one 1674 or more location errors in the response. To a great degree, this 1675 scenario has the proxy behaving as a UAC (see section 6.1.1.) that 1676 included a locationValue a request, which then receives an error to 1677 that locationValue. 1679 This location inserting proxy SHOULD be transaction stateful for the 1680 response. If the proxy is configured as a stateless proxy, and it 1681 inserts location, it MUST process and monitor all SIP responses, 1682 looking for locationErrorValues that indicate it was the "inserter=" 1683 to learn that location it supplied was in error. It SHOULD react 1684 accordingly to the error code received. This document gives no 1685 guidance what the proxy should do to rectify the bad location 1686 information, but a future document MAY address this. 1688 7. Geopriv Privacy Considerations 1690 Location information is considered by most to be highly 1691 sensitive information, requiring protection from eavesdropping, 1692 and altering in transit. [RFC3693] articulates rules to 1693 be followed by any protocol wishing to be considered a "Using 1694 Protocol", specifying how a transport protocol meets those rules. 1695 This section describes how SIP as a Using Protocol meets those 1696 requirements. 1698 Quoting requirement #4 of [RFC3693]: 1700 "The Using Protocol has to obey the privacy and security 1701 instructions coded in the Location Object and in the 1702 corresponding Rules regarding the transmission and storage 1703 of the LO." 1705 This document requires that SIP entities sending or receiving 1706 location MUST obey such instructions. 1708 Quoting requirement #5 of [RFC3693]: 1710 "The Using Protocol will typically facilitate that the keys 1711 associated with the credentials are transported to the 1712 respective parties, that is, key establishment is the 1713 responsibility of the Using Protocol." 1715 [RFC3261] and the documents it references define the key 1716 establishment mechanisms. 1718 Quoting requirement #6 of [RFC3693]: 1720 "(Single Message Transfer) In particular, for tracking of 1721 small Target devices, the design should allow a single 1722 message/packet transmission of location as a complete 1723 transaction." 1725 When used for tracking, a simple NOTIFY or UPDATE normally is 1726 relatively small, although the PIDF itself can get large. Normal 1727 RFC 3261 procedures of reverting to TCP when the MTU size is 1728 exceeded would be invoked. 1730 8. Security Considerations 1732 Conveyance of physical location of a UAC raises privacy concerns, 1733 and depending on use, there probably will be authentication and 1734 integrity concerns. This document calls for conveyance to normally 1735 be accomplished through secure mechanisms, like S/MIME protecting 1736 message bodies (but this is not widely deployed) or TLS protecting 1737 the overall signaling. In cases where a session set-up is 1738 retargeted based on the location of the UAC initiating the call or 1739 SIP MESSAGE, securing the LbyV location with an end-to-end 1740 mechanism such as S/MIME is problematic, because one or more proxies 1741 on the path need the ability to read the location information to 1742 retarget the message to the appropriate new destination UAS. 1743 Securing the location hop-by-hop, using TLS, protects the message 1744 from eavesdropping and modification, but exposes the information to 1745 all proxies on the path as well as the endpoint. In most cases, the 1746 UAC does not know the identity of the proxy or proxies providing 1747 location-based routing services, so that end-to-middle solutions 1748 might not be appropriate either. 1750 These same issues exist for basic SIP signaling, but SIP normally 1751 does not carry information to physically track a user; making this 1752 extension especially sensitive. 1754 When location is inserted by a UAC, which is RECOMMENDED, it can 1755 decide whether to reveal its location using hop-by-hop methods. UAC 1756 implementations MUST make such capabilities conditional on explicit 1757 user permission, and SHOULD alert a user that location is being 1758 conveyed. Proxies inserting location for location-based routing are 1759 unable to meet this requirement, and such use is NOT RECOMMENDED. 1760 Proxies conveying location using this extension MUST have the 1761 permission of the Target to do so. 1763 One facet within this extension is such that locations can be placed 1764 on a remote server, accessible with the possession of a URI. The 1765 concept of an LbyR URI has its own security considerations. It is 1766 tempting to assume that the dereference would have authentication, 1767 authorization and other security mechanisms that limit the access to 1768 information. Unfortunately, this might not be true. The access 1769 network the UAC is connected to can be the source of location 1770 reference, and it might not have any credentialing mechanism 1771 suitable for controlling access to location. Consider, 1772 specifically, a nomadic user connected to an access network in a 1773 hotel. The UAC has no way to provide a credential acceptable to 1774 the hotel Location Server (LS) to any of its intended Location 1775 Recipients. The recipient of a reference does not know if a 1776 reference has appropriate authorization policies or not. The LS 1777 should provide location to any requestor. 1779 Accordingly, possession of the reference should be considered 1780 equivalent to possession of the value, and the reference should be 1781 treated with the same degree of care as the value. Specifically, 1782 TLS MUST be used to protect the security of the reference. Notice 1783 that this does not constrain the dereference protocol to use TLS. 1784 That specification is left entirely to the dereferencing protocol 1785 documents. 1787 There is no integrity on any locationValue or locationErrorValue 1788 header parameter end-to-end (or middle-to-end if the value was 1789 inserted by a intermediary), so recipients of either header need to 1790 implicitly trust the header contents, and take whatever precautions 1791 each entity deems appropriate give these facts. 1793 9. IANA Considerations 1795 The following are the IANA considerations made by this SIP 1796 extension. Modifications and additions to these registrations 1797 require a standards track RFC (Standards Action). 1799 9.1 IANA Registration for the SIP Geolocation Header 1801 The SIP Geolocation header is created by this document, with its 1802 definition and rules in Section 4.1 of this document, to be added to 1803 the sip-parameters, in the portion titled "Header Field Parameters 1804 and Parameter Values". 1806 Predefined 1807 Header Field Parameter Name Values Reference 1808 ---------------- ------------------- ---------- --------- 1809 Geolocation inserted-by= no [this doc] 1810 Geolocation used-for-routing no [this doc] 1812 9.2 IANA Registration for New SIP Option Tag 1814 The SIP option tag "geolocation" is created by this document, with 1815 the definition and rule in Section 4.4 of this document, to be added 1816 to sip-parameters within IANA. 1818 9.3 IANA Registration for Response Code 424 1820 Reference: RFC-XXXX (i.e., this document) 1821 Response code: 424 (recommended number to assign) 1822 Default reason phrase: Bad Location Information 1824 This SIP Response code is defined in section 4.2 of this document. 1826 9.4 IANA Registration of New Geolocation-Error Header 1828 The SIP Geolocation-error header is created by this document, with 1829 its definition and rules in Section 4.3 of this document, to be 1830 added to the sip-parameters, in the portion titled "Header Field 1831 Parameters and Parameter Values". 1833 Predefined 1834 Header Field Parameter Name Values Reference 1835 ----------------- ------------------- ---------- --------- 1836 Geolocation-Error inserter= no [this doc] 1837 Geolocation-Error node= no [this doc] 1838 Geolocation-Error code= no [this doc] 1840 9.5 IANA Registration for the SIP Geolocation-Error Codes 1842 New location specific Geolocation-Error codes are created by this 1843 document, and registered in a new table at sip-parameters within 1844 IANA. Details of these error codes are in Section 4.3 of this 1845 document. 1847 Geolocation-Error codes 1848 ----------------------- 1849 Geolocation-Error codes provide reason for the error discovered by 1850 Location Recipients, categorized by action to be taken by error 1851 recipient to be placed into SIP responses to inform the location 1852 inserter of the error. 1854 Code Description Reference 1855 ---- --------------------------------------------------- --------- 1856 100 "Cannot Process Location" General location error, [this doc] 1857 meaning location in the request cannot be 1858 processed at this time. No actionable guidance. 1859 Can be treated as a 200 or 300 error by error 1860 recipient. 1862 200 "Retry Location Later" (with same data) Location [this doc] 1863 cannot be processed at this time. Error recipient 1864 should try again with same data. 1866 300 "Retry Location Later" (with device updated location) [this doc] 1867 Location cannot be processed at this time. Error 1868 recipient should try again with same data. 1870 400 "Permission Necessary" Permission from calling user [this doc] 1871 to reveal location in request before request can 1872 be processed. This is a routing by location error. 1873 User MUST be informed of permission request. 1875 500 "Location Information Denial" Request was actively 1876 denied because of the location in the request. 1877 Recipient should not try again. 1879 9.6 IANA Registration of LbyR Schemes 1881 This document directs IANA to create a new set of parameters in a 1882 separate location from SIP and Geopriv, called the "Location 1883 Reference URI" registry, containing the URI scheme, the 1884 Content-Type, and the reference. Below is an example of how it 1885 could look 1887 URI Scheme Content-Type Reference 1888 ---------- ------------ --------- 1889 SIP: [this doc] 1890 SIPS: [this doc] 1891 PRES: [this doc] 1893 Additions to this registry require an industry specification. 1895 10. Acknowledgements 1897 To Dave Oran for helping to shape this idea. To Jon Peterson and 1898 Dean Willis on guidance of the effort. To Allison Mankin, Dick 1899 Knight, Hannes Tschofenig, Henning Schulzrinne, James Winterbottom, 1900 Jeroen van Bemmel, Jean-Francois Mule, Jonathan Rosenberg, Keith 1901 Drage, Marc Linsner, Martin Thomson, Mike Hammer, Paul Kyzivat, 1902 Shida Shubert, Umesh Sharma, Richard Barnes, Ted Hardie, Matt 1903 Lepinski and Jacqueline Lee for constructive feedback and nits 1904 checking. 1906 A special thanks to Paul Kyzivat for his help with the ABNF in this 1907 document, to Dan Wing for help with the S/MIME example, and to 1908 Robert Sparks for many helpful comments and the proper building of 1909 the Geolocation-Error header. 1911 11. References 1913 11.1 References - Normative 1915 [RFC3261] J. Rosenberg, H. Schulzrinne, G. Camarillo, A. Johnston, J. 1916 Peterson, R. Sparks, M. Handley, and E. Schooler, "SIP: 1917 Session Initiation Protocol", RFC 3261, May 2002. 1919 [RFC4119] J. Peterson, "A Presence-based GEOPRIV Location Object 1920 Format", RFC 4119, December 2005 1922 [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate 1923 Requirement Levels", RFC 2119, March 1997 1925 [RFC2392] E. Levinson, " Content-ID and Message-ID Uniform Resource 1926 Locators", RFC 2392, August 1998 1928 [RFC3863] H. Sugano, S. Fujimoto, G. Klyne, A. Bateman, W. Carr, J. 1929 Peterson, "Presence Information Data Format (PIDF)", RFC 1930 3863, August 2004 1932 [RFC3856] J. Rosenberg, " A Presence Event Package for the Session 1933 Initiation Protocol (SIP)", RFC 3856, August 2004 1935 [RFC3859] J. Peterson, "Common Profile for Presence (CPP)", RFC 3859, 1936 August 2004 1938 [RFC3428] B. Campbell, Ed., J. Rosenberg, H. Schulzrinne, C. Huitema, 1939 D. Gurle, "Session Initiation Protocol (SIP) Extension for 1940 Instant Messaging" , RFC 3428, December 2002 1942 [RFC3311] J. Rosenberg, "The Session Initiation Protocol (SIP) UPDATE 1943 Method", RFC 3311, October 2002 1945 [RFC3265] Roach, A., "Session Initiation Protocol (SIP)-Specific 1946 Event Notification", RFC 3265, June 2002. 1948 [RFC3262] Rosenberg, J. and H. Schulzrinne, "Reliability of 1949 Provisional Responses in Session Initiation Protocol (SIP)", 1950 RFC 3262, June 2002. 1952 [RFC2976] S. Donovan, "The SIP INFO Method", RFC 2976, Oct 2000 1954 [RFC3515] R. Sparks, "The Session Initiation Protocol (SIP) Refer 1955 Method", RFC 3515, April 2003 1957 [RFC3903] Niemi, A., "Session Initiation Protocol (SIP) Extension 1958 for Event State Publication", RFC 3903, October 2004. 1960 [RFC5234] Crocker, D., Ed., and P. Overell, "Augmented BNF for Syntax 1961 Specifications: ABNF", STD 68, RFC 5234, January 2008. 1963 [IANA-civic] http://www.iana.org/assignments/civic-address-types- 1964 registry 1966 11.2 References - Informative 1968 [RFC3693] J. Cuellar, J. Morris, D. Mulligan, J. Peterson. J. Polk, 1969 "Geopriv Requirements", RFC 3693, February 2004 1971 [RFC3825] J. Polk, J. Schnizlein, M. Linsner, "Dynamic Host 1972 Configuration Protocol Option for Coordinate-based Location 1973 Configuration Information", RFC 3825, July 2004 1975 [RFC4776] H. Schulzrinne, " Dynamic Host Configuration Protocol 1976 (DHCPv4 and DHCPv6) Option for Civic Addresses Configuration 1977 Information ", RFC 4776, October 2006 1979 Author Information 1981 James Polk 1982 Cisco Systems 1983 3913 Treemont Circle 1984 Colleyville, Texas 76034 1986 33.00111N 1987 96.68142W 1989 Phone: +1-817-271-3552 1990 Email: jmpolk@cisco.com 1992 Brian Rosen 1993 NeuStar, Inc. 1994 470 Conrad Dr. 1995 Mars, PA 16046 1997 40.70497N 1998 80.01252W 2000 Phone: +1 724 382 1051 2001 Email: br@brianrosen.net 2003 Appendix A. Requirements for SIP Location Conveyance 2005 The following subsections address the requirements placed on the 2006 UAC, the UAS, as well as SIP proxies when conveying location. There 2007 is a motivational statement below each requirements that is not 2008 obvious in intent 2010 A.1 Requirements for a UAC Conveying Location 2012 UAC-1 The SIP INVITE Method [RFC3261] must support location 2013 conveyance. 2015 UAC-2 The SIP MESSAGE method [RFC3428] must support location 2016 conveyance. 2018 UAC-3 SIP Requests within a dialog should support location 2019 conveyance. 2021 UAC-4 Other SIP Requests may support location conveyance. 2023 UAC-5 There must be one, mandatory to implement means of 2024 transmitting location confidentially. 2026 Motivation: interoperability 2028 UAC-6 It must be possible for a UAC to update location conveyed 2029 at any time in a dialog, including during dialog 2030 establishment. 2032 Motivation: in case a UAC has moved prior to the establishment of a 2033 dialog between UAs, the UAC must be able to send new location 2034 information. In the case of location having been conveyed, 2035 and the UA moves, it needs a means to update the conveyed to 2036 party of this location change. 2038 UAC-7 The privacy and security rules established within [RFC3693] 2039 that would categorize SIP as a 'Using Protocol' must be met. 2041 UAC-8 The PIDF-LO [RFC4119] is a mandatory to implement format for 2042 location conveyance within SIP, whether included LbyV or 2043 LbyR. 2045 Motivation: interoperability with other IETF location protocols and 2046 mechanisms 2048 UAC-9 There must be a mechanism for the UAC to request the UAS send 2049 its location 2051 UAC-9 has been DEPRECATED by the SIP WG, due to the many 2052 problems this requirement would have caused if implemented. 2053 The solution is for the above UAS to send a new request to 2054 the original UAC with the UAS's location. 2056 UAC-10 There must be a mechanism to differentiate the ability of the 2057 UAC to convey location from the UACs lack of knowledge of its 2058 location 2060 Motivation: Failure to receive location when it is expected can be 2061 because the UAC does not implement this extension, or it can 2062 be that the UAC implements the extension, but does not know 2063 where it is. This may be, for example, due to the failure of 2064 the access network to provide a location acquisition 2065 mechanisms the UAC understands. These cases must be 2066 differentiated. 2068 UAC-11 It must be possible to convey location to proxy servers 2069 along the path. 2071 Motivation: Location-based routing. 2073 A.2 Requirements for a UAS Receiving Location 2075 The following are the requirements for location conveyance by a UAS: 2077 UAS-1 SIP Responses must support location conveyance. 2079 Just as with UAC-9, UAS-1 has been DEPRECATED by the SIP WG, 2080 due to the many problems this requirement would have caused 2081 if implemented. The solution is for the above UAS to send a 2082 new request to the original UAC with the UAS's location. 2084 UAS-2 There must be a unique 4XX response informing the UAC it did 2085 not provide applicable location information. 2087 In addition, requirements UAC-5, 6, 7 and 8 apply to the UAS 2089 A.3 Requirements for SIP Proxies and Intermediaries 2091 The following are the requirements for location conveyance by a SIP 2092 proxies and intermediaries: 2094 Proxy-1 Proxy servers must be capable of adding a Location header 2095 field during processing of SIP requests. 2097 Motivation: Provide the capability of network assertion of location 2098 when UACs are unable to do so, or when network assertion is 2099 more reliable than UAC assertion of location 2101 Note: Because UACs connected to sip signaling networks may have 2102 widely varying access network arrangements, including VPN 2103 tunnels and roaming mechanisms, it may be difficult for a 2104 network to reliably know the location of the endpoint. Proxy 2105 assertion of location is NOT RECOMMENDED unless the sip 2106 signaling network has reliable knowledge of the actual 2107 location of the Targets. 2109 Proxy-2 There must be a unique 4XX response informing the UAC it 2110 did not provide applicable location information. 2112 Appendix B. Example of INVITE with S/MIME encrypted Civic PIDF-LO 2114 This appendix gives an *EXAMPLE* (meaning this might contain errors 2115 based on future review) of a SIP INVITE request that points to the 2116 same position on the earth as the coordinate based example that is 2117 in section 5.1 in the body of this document: 2119 The INVITE request is TLS hop-by-hop encrypted, and the 2120 LbyV message body is S/MIME encrypted. This example 2121 shows the location message body in its unencrypted form for clarity. 2122 The message body lines below that have the '$' signs are S/MIME 2123 encrypted. In this example, the SDP is not S/MIME encrypted. A 2124 complete list of IANA registered CAtypes can be found at 2125 [IANA-civic]. 2127 INVITE sips:bob@biloxi.example.com SIP/2.0 2128 Via: SIP/2.0/TLS pc33.atlanta.example.com 2129 ;branch=z9hG4bK74bf9 2130 Max-Forwards: 70 2131 To: Bob 2132 From: Alice ;tag=9fxced76sl 2133 Call-ID: 3848276298220188511@atlanta.example.com 2134 Geolocation: 2135 ;inserted-by="alice@atlanta.example.com" 2136 Supported: geolocation 2137 Accept: application/sdp, application/pidf+xml 2138 CSeq: 31862 INVITE 2139 Contact: 2140 Content-Type: multipart/mixed; boundary=boundary1 2141 Content-Length: ... 2143 --boundary1 2145 Content-Type: application/sdp 2147 ...SDP goes here 2149 --boundary1 2151 Content-Type: application/pkcs7-mime; 2152 smime-type=enveloped-data; name=smime.p7m 2153 Content-ID: target123@atlanta.example.com 2155 $ Content-Type: application/pidf+xml 2156 $ 2157 $ 2158 $ 2162 $ 2163 $ 2007-07-09T14:00:00Z 2164 $ 2165 $ 2166 $ 2167 $ 2168 $ US 2169 $ Texas 2170 $ Colleyville 2171 $ 3913 2172 $ Treemont 2173 $ Circle 2174 $ 76034 2175 $ Haley's Place 2176 $ 1 2177 $ 2178 $ 2179 $ 2180 $ no 2181 $ 2007-07-27T18:00:00Z 2183 $ 2184 $ DHCP 2185 $ www.example.com 2186 $ 2187 $ 2188 $ 2189 $ 2190 --boundary1-- 2192 Full Copyright Statement 2194 Copyright (C) The IETF Trust (2008). 2196 This document is subject to the rights, licenses and restrictions 2197 contained in BCP 78, and except as set forth therein, the authors 2198 retain all their rights. 2200 This document and the information contained herein are provided on 2201 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 2202 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE 2203 IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL 2204 WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY 2205 WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE 2206 ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS 2207 FOR A PARTICULAR PURPOSE. 2209 Intellectual Property 2211 The IETF takes no position regarding the validity or scope of any 2212 Intellectual Property Rights or other rights that might be claimed 2213 to pertain to the implementation or use of the technology described 2214 in this document or the extent to which any license under such 2215 rights might or might not be available; nor does it represent that 2216 it has made any independent effort to identify any such rights. 2217 Information on the procedures with respect to rights in RFC 2218 documents can be found in BCP 78 and BCP 79. 2220 Copies of IPR disclosures made to the IETF Secretariat and any 2221 assurances of licenses to be made available, or the result of an 2222 attempt made to obtain a general license or permission for the use 2223 of such proprietary rights by implementers or users of this 2224 specification can be obtained from the IETF on-line IPR repository 2225 at http://www.ietf.org/ipr. 2227 The IETF invites any interested party to bring to its attention any 2228 copyrights, patents or patent applications, or other proprietary 2229 rights that may cover technology that may be required to implement 2230 this standard. Please address the information to the IETF at 2231 ietf-ipr@ietf.org. 2233 Acknowledgment 2235 Funding for the RFC Editor function is provided by the IETF 2236 Administrative Support Activity (IASA).