idnits 2.17.1 draft-ietf-sip-location-conveyance-10.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 2161. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 2172. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 2179. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 2185. 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 596 has weird spacing: '... ar o ...' == Line 600 has weird spacing: '... ar o ...' == Line 1539 has weird spacing: '... the conten...' == Line 1731 has weird spacing: '...et this requi...' == Line 1745 has weird spacing: '...dential accep...' == (3 more instances...) == The document seems to use 'NOT RECOMMENDED' as an RFC 2119 keyword, but does not include the phrase in its RFC 2119 key words list. -- 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 (February 24, 2008) is 5906 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 ---------------------------------------------------------------------------- == Missing Reference: 'RFC2976' is mentioned on line 389, but not defined ** Obsolete undefined reference: RFC 2976 (Obsoleted by RFC 6086) == Missing Reference: 'RFC3515' is mentioned on line 390, but not defined == Missing Reference: 'RFC3903' is mentioned on line 392, but not defined == Missing Reference: 'RFC 4119' is mentioned on line 1997, but not defined == Unused Reference: 'IANA-civic' is defined on line 1924, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2393 (ref. 'RFC2392') (Obsoleted by RFC 3173) ** Obsolete normative reference: RFC 3265 (Obsoleted by RFC 6665) -- Obsolete informational reference (is this intentional?): RFC 3825 (Obsoleted by RFC 6225) Summary: 4 errors (**), 0 flaws (~~), 14 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 Expiration: Aug 24, 2008 Brian Rosen 5 Intended Status: Standards Track (PS) NeuStar 6 February 24, 2008 8 Location Conveyance for the Session Initiation Protocol 9 draft-ietf-sip-location-conveyance-10.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 August 24, 2008. 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 proxy servers 46 make routing decisions based on the location of the SIP user agents. 48 Table of Contents 50 1. Conventions and Terminology used in this document . . . . . . 2 51 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 52 3. Overview of SIP Location Conveyance . . . . . . . . . . . . . 5 53 4. SIP Modifications for Geolocation Conveyance . . . . . . . . 7 54 4.1 The Geolocation Header . . . . . . . . . . . . . . . . . 7 55 4.2 424 (Bad Location Information) Response Code . . . . . . 9 56 4.3 The Geolocation-Error Header . . . . . . . . . . . . . . 10 57 4.4 The 'geolocation' Option Tag . . . . . . . . . . . . . . 18 58 4.5 Using sip/sips/pres as a Dereference Scheme . . . . . . . 18 59 5. Geolocation Examples . . . . . . . . . . . . . . . . . . . . 20 60 5.1 Location-by-value (Coordinate Format) . . . . . . . . . . 20 61 5.2 Location-by-reference . . . . . . . . . . . . . . . . . . 22 62 6. SIP Element Behavior . . . . . . . . . . . . . . . . . . . . 22 63 6.1 UAC Behavior . . . . . . . . . . . . . . . . . . . . . . 23 64 6.2 UAS Behavior . . . . . . . . . . . . . . . . . . . . . . 26 65 6.3 Proxy Behavior . . . . . . . . . . . . . . . . . . . . . 30 66 7. Geopriv Privacy Considerations . . . . . . . . . . . . . . . 33 67 8. Security Considerations . . . . . . . . . . . . . . . . . . . 34 68 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . 35 69 9.1 IANA Registration for New SIP Geolocation Header . . . . 35 70 9.2 IANA Registration for New SIP 'geolocation' Option Tag . 36 71 9.3 IANA Registration for New 424 Response Code . . . . . . . 36 72 9.4 IANA Registration for New SIP Geolocation-Error Header . 36 73 9.5 IANA Registration for New SIP Geolocation-Error Codes . . 36 74 9.6 IANA Registration of LbyR Schemes . . . . . . . . . . . 37 75 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 37 76 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 38 77 11.1 Normative References . . . . . . . . . . . . . . . . . 38 78 11.2 Informative References . . . . . . . . . . . . . . . . . 39 79 Author Information . . . . . . . . . . . . . . . . . . . . . 39 80 Appendix A. Requirements for SIP Location Conveyance . . . . 39 81 Appendix B. Example of Civic-based PIDF-LO w/ S/MIME . . . . 41 82 Intellectual Property and Copyright Statements . . . . . . . 43 84 1. Conventions and Terminology used in this document 86 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 87 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and 88 "OPTIONAL" in this document are to be interpreted as described 89 in [RFC2119]. 91 The following terms and acronyms used throughout this document are 92 defined here: 94 "cid=" = content-ID URI. See Section 4.1 for more details. 96 Content-ID - Defined in RFC 2392 as a URL reference to find message 97 body parts within the same message, to ease parsing. 99 LbyR = Location-by-Reference 100 LbyV = Location-by-Value 102 locationErrorValue - contains an actionable error code from a 103 Location Recipient, identifying the location "inserter=", and 104 optionally a test string describing the type of error. There can 105 be one or more locationErrorValues within a Geolocation-Error 106 header in a SIP response. See Section 4.3 for more details. 108 locationValue - contains a URI pointing to a Location Target's 109 location (as a PIDF-LO), and one or more header parameters about 110 that URI. There can be one or more locationValues within a 111 Geolocation header in a SIP request. See Section 4.1 for more 112 details. 114 Location Generator - the first IP enabled device that builds the IP 115 packet that transmits the PIDF-LO containing the Target's 116 location 118 Location Information Server (LIS) - a logical server that stores 119 geolocation records, which correspond to LbyR URIs, which point 120 to those records. 122 Location Object - Defined in RFC 4119 as the PIDF-LO (XML scheme) 123 format which includes the geolocation of Location Target in 124 either civic address or coordinate form. 126 Location Recipient - Defined in RFC3693 as any entity that 127 understands geolocation (LbyR or LbyV) along a message path. 128 Does not include entities that process a message containing 129 geolocation that do not understand geolocation (i.e., layer 3 130 routers). 132 Location Server - a logical IP server that transmits a PIDF-LO. This 133 can be logically combined with the Location Generator, or could 134 be an intermediary element - such as a LIS. 136 Location Target - The entity whose location is being sought, whether 137 or not this entity is aware of this inquiry or is even an IP 138 device. 140 Location-by-Reference (more than one meaning) 142 - a general purpose term meaning a message containing a URI that 143 points to a PIDF-LO (geolocation of a Location Target) not within 144 this same message 146 - a URI that logically locates a geolocation record of a Location 147 Target. The URI does not point to location within the same 148 message as the URI. 150 Location-by-Value - when a message contains the actual location of a 151 Location Target, in the form of a PIDF-LO, within a part of the 152 same message, usually pointed to by a "cid=" URI in a Geolocation 153 header. 155 Using Protocol - as defined in [RFC3693], a protocol that is deemed 156 to be in compliance with the security and privacy aspects of the 157 Geopriv Requirements RFC [RFC3693], with good community 158 verification. 160 Instead of using the terms Location-by-Reference (or just 161 by-reference) and Location-by-Value (or just by-value), this 162 document will herein use the acronyms LbyR and LbyV, respectively. 163 The use of "cid=" implies LbyV, therefore, the use of a "cid=" 164 Reference URL, which is *not* a Location-by-Reference (LbyR). 166 2. Introduction 168 This document describes how Location can be "conveyed" (that is, 169 transmitted over the Internet) from one SIP user agent (UA), or in 170 some circumstances, a proxy server acting in support of a UA, to 171 another entity using SIP [RFC3261]. Here "Location" is a 172 description of the physical geographical area where something 173 currently exists. The phrase "location conveyance" describes 174 scenarios in which a SIP user agent client (UAC) is informing a user 175 agent server (UAS), or intermediate SIP server where the UAC is. A 176 superset of this can also be true as well, in which one UA(1) is 177 telling another UA(2) where another Target is, meaning not 178 necessarily where UA(1) is. The key to this is whether UA(1) has 179 permission to retransmit that other Target's location. If yes, then 180 this is valid. If no, then this is breaking a fundamental rule 181 within this extension. 183 Location Conveyance is different from a UAC seeking the location the 184 UAS. Location conveyance is a 'sending location out in the request' 185 model, where 'asking that someone else's location be in a response' 186 is not discussed here. 188 Geographic location in the IETF is discussed in RFC 3693 (Geopriv 189 Requirements) [RFC3693]. It defines a "Target" as the entity whose 190 location is being sought. In this case, this is the UA's 191 (UA) location. A [RFC3693] "Using Protocol" defines how a "location 192 Server" transmits a "Location Object" to a "Location Recipient" 193 while maintaining the contained privacy intentions of the Target 194 intact. This document describes the extension to SIP for how it 195 complies with the Using Protocol requirements, where the location 196 server is a UA or Proxy Server and the Location Recipient is 197 another UA or Proxy Server. 199 Location can be transmitted by-value or by-reference. The location 200 "value" in this SIP extension is in the form of a Presence 201 Information Data Format - Location Object, or PIDF-LO, as described 202 in [RFC4119]. A PIDF-LO is an XML Scheme specifically for carrying 203 geographic location of a Target. LbyV refers to a UA including a 204 PIDF-LO as a body part of a SIP request, sending that Location 205 Object to another SIP element. LbyR refers to a UA or proxy server 206 including a URI in a SIP request header field which can be 207 dereferenced by a Location Recipient for a Location Object, in the 208 form of a PIDF-LO. Dereferencing can be by a SIP UA or a SIP 209 server. 211 As recited in RFC 3693, location often must be kept private. The 212 Location Object (PIDF-LO) contains rules which provides guidance to 213 the Location Recipient and controls onward distribution and 214 retention of the location. This document describes the security and 215 privacy considerations that must be applied to location conveyed 216 with SIP. 218 Another use for location is location-based routing of a 219 SIP request, where the choice of the next hop (and usually, the 220 outgoing Request-URI) is determined by the location of the UAC which 221 is in the message by-value or by-reference. This document describes 222 how location can be conveyed from the UAC, or a proxy acting on its 223 behalf, to a routing proxy. How the location is actually used to 224 determine the next hop or Request-URI is beyond the scope of this 225 document. 227 We refer to the "emergency case". This refers to a specific, 228 important use of SIP location conveyance where the location of the 229 caller is used to determine which Public Safety Answering Point 230 (PSAP) is expected to receive an emergency call request for help 231 (e.g., a call to 1-1-2 or 9-1-1). This is an example of 232 location-based routing. The location conveyed is also used by the 233 PSAP to dispatch first responders to the caller's location. There 234 are special security considerations, which make the emergency case 235 unique, compared to a normal location conveyance within SIP. 237 Common terms are in Section 1. Section 3 provides an overview of SIP 238 location conveyance. Section 4 details the modifications necessary 239 to accomplish location conveyance. Section 5 gives decode examples 240 of geolocation within SIP requests, both LbyV and LbyR. Section 6 241 articulates the SIP element type behaviors for location conveyance. 242 Section 7 discusses Geopriv privacy considerations. Section 8 243 discusses security considerations. Section 9 IANA registers the 244 modifications made to SIP by this document from section 4. 246 3. Overview of SIP Location Conveyance 248 This document defines a new SIP header: Geolocation. The 249 Geolocation header field contains a URI which can either be a "cid:" 250 URI (Content Identification), as defined in [RFC2392], or an LbyR 251 -- to be dereferenced by a Location Recipient to retrieve the 252 location of the Target UA. 254 Where the Geolocation header contains a "cid:", the URI points to a 255 message body that is in the form of a PIDF [RFC3863], which was 256 extended in [RFC4119] to include location, as a PIDF-LO. This is 257 LbyV, the actual location information in the PIDF-LO is included in 258 the body of the message. 260 If the URI in the Geolocation header field is a scheme other than 261 "cid:", another protocol operation is needed by the SIP message 262 recipient to obtain the location of the Target (UA). This is 263 LbyR. This document describes how a SIP presence subscription 264 [RFC3856] can be used as a dereference protocol. 266 The Geolocation header, either with the PIDF-LO in a body or as a 267 LbyR URI, can be included by a UA in a SIP request. A SIP proxy 268 server can assert location of the UA by inserting the header field, 269 by adding an LbyR URI into the Geolocation header value, even if 270 there is a locationValue already there. Since body parts cannot be 271 inserted by a SIP proxy server, LbyV message body cannot be inserted 272 by a proxy. 274 The Geolocation header can have parameters that are associated 275 with a URI in the header field. The "inserted-by" parameter 276 indicates the host-id of which specific element added this 277 particular location to the request. This header parameter is 278 included in every locationValue, and does not appear more than once 279 per locationValue. The "inserted-by" parameter is especially useful 280 for Location Recipients that receive more than one locationValue 281 within a SIP request. Since implementations of a UA or SIP Server 282 do not know they will be the last entity before a Location 283 Recipient, this optional parameter is necessary within each 284 locationValue. 286 Retargeting means the Request-URI of the request has changed to 287 point at a new destination UAS. This is different than message 288 routing, that all SIP proxies do. If a SIP request is retargeted 289 based on the location contained or referenced within that message, 290 the "used-for-routing" parameter is added as a header parameter 291 within the appropriate locationValue. 293 There is no mechanism by which the veracity of these parameters can 294 be verified. They are hints to downstream entities on how the 295 location information in the message was originated and used. 296 Transport Layer Security is expected when a request contains a 297 user's location. Some implementations will choose to have S/MIME to 298 encrypt message bodies from source to destination. 300 This document creates a new option tag: geolocation, to indicate 301 support for the this extension by UAs. 303 A new error response (424 Bad Location Information) is also defined 304 in this document. Within this response is a new header indicating 305 location-based errors, call the Geolocation-Error header. This 306 header has various codes that provide additional information about 307 the type of location error experienced by a Location Recipient. 309 Both new headers, the header parameters, the new option tag, the new 310 error response, and Geolocation-Error codes, which are defined in 311 Section 4., are IANA registered by this document. 313 4. SIP Modifications for Geolocation Conveyance 315 The following are sections detail the standards track modifications 316 to SIP for Location Conveyance. 318 4.1 The Geolocation Header 320 This document defines and IANA registers a new SIP header: 321 Geolocation, with the following ABNF [RFC5234]: 323 Geolocation = "Geolocation" HCOLON (locationValue *(COMMA 324 locationValue)) 325 locationValue = LAQUOT locationURI RAQUOT *(SEMI geoloc-param) 326 locationURI = sip-URI / sips-URI / pres-URI 327 / cid-url ; (from RFC 2392) 328 / absoluteURI ; (from RFC 3261) 329 geoloc-param = "inserted-by" EQUAL geoloc-inserter 330 / "used-for-routing" 331 / generic-param ; (from RFC 3261) 332 geoloc-inserter = DQUOTE hostport DQUOTE 333 / gen-value ; (from RFC 3261) 335 sip-URI, sips-URI and absoluteURI are defined according to RFC 3261. 336 The pres-URI is defined in RFC 3859 [RFC3859]. 338 The cid-url is defined in [RFC2392] to locate message body 339 parts. This URI type MUST be present in a SIP request if location 340 is transmitted LbyV only. 342 Other protocols used in the Location URI MUST be reviewed against 343 the RFC 3693 criteria for a Using Protocol. 345 The Geolocation header MAY have one or more locationValues. SIP 346 servers inserting a locationValue MUST add the new value to the end 347 of the header value, such that the last locationValue in the header 348 is the most recent one added to the message. 350 A locationValue has the following independent header parameters, 352 o the "inserted-by=" parameter provides the hostport 353 (alice.example.com -- which is the same as the "sent-by" 354 parameter in a Via header, with or without a port number) of the 355 SIP entity that inserted this locationValue into the request. If 356 a Location Recipient has determined a supplied location is in 357 error, as there can be more than one in any request, the 358 "inserted-by=" parameter is copied into the locationErrorValue in 359 the response indicating the location error, and to whom the error 360 is for. Hence, this "inserted-by=" parameter MUST be present in 361 each locationValue. If an entity receives an Geolocation-Error 362 with a hostport not identifying this entity, the 363 Geolocation-Error MUST be ignored. 365 o the "used-for-routing" parameter to inform recipients that the 366 location in this locationValue was used to route the message 367 towards the ultimate destination UAS. "used-for-routing" can 368 occur more than once along the request's path. Because 369 locationValues are inserted as last inserted is last in the 370 header, the last locationValue is the most recent one added to 371 the message. This also gives the "used-for-routing" header 372 parameter added meaning - as the receiving SIP entity knows which 373 locationURI the message was routed upon. 375 Each locationValue MUST contain exactly one "inserted-by" parameter, 376 indicating which SIP entity added the locationValue to the SIP 377 request. 379 There MUST NOT be more than one "inserted-by=" parameter or one 380 "used-for-routing" parameter in the same locationValue. However, 381 there can be more than one locationValue in the same Geolocation 382 header. 384 This document defines the Geolocation header as valid in the 385 following SIP requests: 387 INVITE [RFC3261], REGISTER [RFC3261], 388 OPTIONS [RFC3261], BYE [RFC3261], 389 UPDATE [RFC3311], INFO [RFC2976], 390 MESSAGE [RFC3428], REFER [RFC3515], 391 SUBSCRIBE [RFC3265], NOTIFY [RFC3265], 392 PUBLISH [RFC3903] and PRACK [RFC3262] 394 Discussing location using the PUBLISH request is out of scope 395 for this document since it is part of Presence, therefore, for 396 completeness, Table 1 shows PUBLISH is to support Location 397 Conveyance via this extension, but is not discussed further. 399 The following table extends the values in Table 2&3 of RFC 3261 400 [RFC3261]. 402 Header field where proxy INV ACK CAN BYE REG OPT PRA 403 ---------------------------------------------------------------- 404 Geolocation R ar o - - o o o o 405 Header field where proxy SUB NOT UPD MSG REF INF PUB 406 ---------------------------------------------------------------- 407 Geolocation R ar o o o o o o o 409 Table 1: Summary of the Geolocation Header 411 The Geolocation header field MAY be included in any one of the above 412 requests by a UAC. A proxy MAY add the Geolocation header, but MUST 413 NOT modify any pre-existing locationValue, including its associated 414 header parameters of within an existing Geolocation header value, 415 unless one of the existing locationValues is used to retarget the 416 request towards a new destination UAS. This is discussed in section 417 6.3. 419 [RFC3261] states message bodies cannot be added by proxies. 420 Therefore, any Geolocation header field added by a proxy MUST be in 421 the form of a LbyR URI, in its own locationValue header value. 423 Adding a new locationValue to an an in-transit request SHOULD NOT 424 occur for at least two reasons 426 #1 - SIP Servers are not the best Sighters, as defined by [RFC3693], 427 of geographically where a UAC can be; meaning the location 428 information is not necessarily the greatest. There MAY be 429 exceptions, but this SHOULD be the rule of thumb. 431 #2 - without appropriate caution to the fact that Location 432 Recipients might not understand how to process more than one 433 location, given this document's limited guidance as to what a 434 Location Recipient should do when receiving more than one 435 location (i.e., currently no priority instructions are given 436 for which locationValue to use if there are more than one). A 437 Location Recipient can easily be confused by too much location 438 information, producing undesirable results. The 439 element in the PIDF-LO XML indicates whose location is 440 contained in the PIDF-LO. 442 Location Recipients receiving a location object, received directly 443 or as the result of a dereference, MUST honor the usage element 444 rules within that XML document, as defined in RFC 4119. Such 445 entities MUST NOT alter the rule set. 447 4.2 424 (Bad Location Information) Response Code 449 This SIP extension creates a new Location specific response code, 450 defined as follows. 452 424 (Bad Location Information) 454 The 424 (Bad Location Information) response code is a rejection of 455 the request, due to its location contents, indicating the location 456 information was malformed or not satisfactory for the recipient's 457 purpose, or could not be dereferenced. 459 Section 4.3 creates the Geolocation-Error header to provide more 460 detail about what was wrong with the location information in the 461 request. This header MUST be in the 424 response, containing a 462 locationErrorValue for each invalid locationValue in the request 463 (i.e., and one-for-one matching if all locationValues in the request 464 were bad). 466 If more than one location is present in a request (LbyV or LbyR), 467 and any of the locationValues is good for the Location Recipient to 468 process, a 424 MUST NOT be sent. The 424 is only appropriate when 469 the Location Recipient needs a locationValue and there are no 470 locationValues included in a SIP request that are usable by a 471 recipient. 473 A 424 (Bad Location Information) response is a final response within 474 a transaction, and does not terminate a usage or a dialog. 476 The UAC can use whatever means it knows of to verify/refresh its 477 location information before attempting a new request that includes 478 location. There is no cross-transaction awareness expected by either 479 the UAS or any SIP intermediary as a result of this error message. 481 The new 424 (Bad Location Information) error code is IANA registered 482 in Section 8 of this document. An initial set of location error of 483 IANA registered Geolocation-Error codes are in Section 4.3 of this 484 document. 486 4.3 The Geolocation-Error Header 488 As discussed in Section 4.2, more granular error notifications, 489 specific to location errors within a received request, are required 490 if the UAC is to know what was wrong within the original request. 491 The Geolocation-Error header is created here for this purpose. 492 Geolocation-Error header is used to convey location specific errors 493 within a response. Additions to this IANA registered header require 494 an RFC be published. The Geolocation-Error header has the following 495 ABNF [RFC5234]: 497 Geolocation-Error = "Geolocation-Error" HCOLON 498 locationErrorValue 499 *(COMMA locationErrorValue) 500 locationErrorValue = location-error-code *(SEMI 501 location-error-params) 502 location-error-code = 1*3DIGIT 503 location-error-params = location-error-node-id 504 / location-error-host-id 505 / location-error-code-text 506 / generic-param ; from RFC3261 508 location-error-node-id = "node" EQUAL 509 DQOUTE hostport DQOUTE ; from RFC3261 510 location-error-host-id = "inserter" EQUAL 511 DQOUTE hostport DQOUTE ; from RFC3261 512 location-error-code-text = "code" EQUAL quoted-string ; from RFC3261 514 The Geolocation-Error header MUST contain at least one 515 locationErrorValue to indicate what was wrong with the original 516 locationValue in the corresponding request. If a Location Recipient 517 experienced more than one error a particular locationValue of the 518 corresponding SIP request, there can be one locationErrorValue per 519 problem with the locationValue in the request. Each 520 locationErrorValue contains one 3-digit error code indicating what 521 was wrong with the location in the request. Each error type has a 522 corresponding quoted error text string that is human 523 understandable. If there was something wrong with more than one 524 locationValue in a request, a corresponding locationErrorValue would 525 be sent, one per error, in the response. 527 Each locationErrorValue contains the Location Recipient identifier 528 (the "node=" parameter) which experienced the location error, as 529 well as an identifier of which SIP entity (the "inserter=" 530 parameter) the Location Recipient is told (in the locationValue) 531 added this problematic locationValue to the request. The "node=" 532 and "inserter=" are the domain identifier of a SIP entity, with the 533 ability to have the same host communicate on different ports - and 534 have port specific identification. This is the same as is entered in 535 the "sent-by" parameter of the Via header for that entity 536 [RFC3261]. As stated in section 18 of RFC 3261, the usage of FQDN 537 is RECOMMENDED. Here are examples of both locationErrorValue 538 parameters 540 node="bob.example.com" 542 inserter="alice.example.com" 544 Both the "node=" and "inserter=" parameters MUST be present in all 545 locationErrorValues in a response, unless the "inserted-by=" 546 parameter was not in the locationValue of a request (which is a 547 violation of this document). The "inserter=" parameter value is 548 copied from the "inserted-by=" parameter within the locationValue of 549 the request. No manipulation or calculation is necessary to 550 accomplish this. 552 Here's why this is necessary, a Location Recipient that experienced 553 the location problem with the request needs to tell the specific SIP 554 entity which added the locationValue in error into the original 555 request. Since more than one SIP entity can insert location into a 556 request in transit, all other SIP elements may be confused by 557 receiving this error header, were it to remain generic to all 558 entities in the response path. So, the header has to identify who 559 it is for, so that all other SIP entities that read the header know 560 to ignore it, since it is not for them. This is of particular use 561 if the original UAC did not include a locationValue in the original 562 SIP request, but a SIP server along the path did insert a 563 locationValue. The locationErrorValue would travel to each SIP 564 entity along the original path and tell both the server that 565 included the locationValue what was wrong with the location and the 566 UAC who did not know what the error meant. This will cause 567 confusion if left without this indication. 569 A worse case is when both the original UAC and a SIP server along 570 the path included a locationValue, but there was only something 571 wrong with one of the locationValues. Without this identification 572 of which locationValue was in error, both entities would react and 573 one would do so incorrectly. 575 More than one locationErrorValue in a Geolocation-Error header is 576 separated by a comma. 578 If more than one locationErrorValue is in a response, and intended 579 for the same "inserter=", each error code MUST be unique to this 580 "inserter=" entity, and the error codes SHOULD NOT conflict in 581 meaning. In other words, two error codes (within separate 582 locationErrorValues of the same response) SHOULD NOT give misleading 583 or inconsistent indications to the location "inserter=". 585 Here is an example of a Geolocation-Error header 587 Geolocation-Error: 200; code="Retry Location Later"; 588 node="bob.example.com"; 589 inserter="alice.example.com"; 591 The following table extends the values in Table 2&3 of RFC 3261 592 [RFC3261]. 594 Header field where proxy INV ACK CAN BYE REG OPT PRA 595 ---------------------------------------------------------------- 596 Geolocation-Error r ar o - - o o o o 598 Header field where proxy SUB NOT UPD MSG REF INF PUB 599 ---------------------------------------------------------------- 600 Geolocation-Error r ar o o o o o o o 602 Table 2: Summary of the Geolocation-Error Header 604 The Geolocation-Error header field MAY be included in any response 605 to one of the above SIP requests, so long as Geolocation was in the 606 request part of the transaction. The choice of which SIP requests 607 are in table 2 above come from which Methods can optionally have the 608 Geolocation header (see section 4.1). That said, a UAC MUST ignore 609 a Geolocation-Error header value if it did not include a Geolocation 610 header value in the request part of the transaction. 612 Here is an example of a transaction that has a location error. In 613 this case, Bob responds with a 424 (Bad Location Information) 614 response, including a Geolocation-Error header, is in Figure 1. 616 Alice Bob 617 | | 618 | Request w/ Location | 619 |------------------------------------------------>| 620 | | 621 | | 622 | 424 (Bad Location Information) | 623 | with Geolocation-Error containing | 624 | 200 ("Retry Location Later" (with same data)) | 625 |<------------------------------------------------| 626 | | 628 Figure 1. Basic Transaction with 424 and Geolocation-Error Header 630 The following subsections provide an initial list of location 631 based errors for any SIP non-100 response, including the new 424 632 (Bad Location Information) response. These error codes are divided 633 into 5 categories, each based on receiver (of the response) 634 actionable reactions to these errors. 636 o 100 "Cannot Process Location" 638 o 200 "Retry Location Later" (with same data) 640 o 300 "Retry Location Later" (with device updated location) 642 o 400 "Permission Necessary" 644 o 500 "Location Information Denial" 646 All 5 of the above error codes MUST be implemented to comply with 647 this specification. Each of these actionable errors is given a 3 648 digit error code category, meaning any future 1XX, 2XX, 3XX, 4XX, 649 and 5XX error codes defined will have the same action expected by 650 X00 categories. If another action is expected to occur with a newly 651 defined error code, it MUST outside the 100-599 range. 100 unit 652 ranges are OPTIONAL for future error codes, but they apply here. 654 4.3.1 Location Error: 100 "Cannot Process Location" 656 The location error 100 "Cannot Process Location" indicates to a 657 Geolocation-Error recipient that what they supplied in a request, as 658 far as location is concerned, cannot be processed at this time. 659 This only has to do with the location that the location "inserter=" 660 added to the request, and not about the overall request that was 661 sent. 663 Action(s) to be taken by Geolocation-Error receiver to a 1XX: 664 This error gives no guidance on what to do next. It is a 665 general information indication to a SIP "inserter=" entity 666 that there was an unspecific problem with the location 667 supplied in the SIP request. 669 Implementations MAY choose to react in a way as if this "inserter=" 670 entity received a 2XX or 3XX location error. A 4XX error MUST NOT be 671 misunderstood here, as that error category involves human 672 intervention to grant, or not, permission to reveal "inserter=" 673 location when this is likely not desired. 675 The text string of "Cannot Process Location" is RECOMMENDED, but not 676 mandatory for usage in this error. Implementations MAY use another 677 text string. 679 An example of this location error is here: 681 Geolocation-Error: 100; code="Cannot Process Location"; 682 node="bob.example.com"; 683 inserter="alice.example.com"; 685 This category covers location errors 1XX; meaning there MAY be more 686 specific errors added to this category in future effort(s). The 687 same basic actionable reaction is expected by a location "inserter=" 688 entity to any 1XX location error. 690 4.3.2 Location Error: 200 "Retry Location Later" (same data) 692 The location error 200 "Retry Location Later" (same data) indicates 693 to a Geolocation-Error recipient that what they supplied in a 694 request, as far as location is concerned, cannot be processed at 695 this time, but to retry this request, without changing the location 696 information, at a later time - in a new SIP request. It is possible 697 that the Location Recipient cannot process location at this time, or 698 there was a timeout during dereferencing, if a LbyR were sent. 700 Action(s) to be taken by Geolocation-Error receiver to a 2XX: 701 Reactions to a 2XX location error are to try again, without 702 having to update the location supplied originally. There is 703 no constraints on how long this new try has to wait, unless 704 there is a Retry-After header in a 424 response. 706 Implementations SHOULD choose to react by preparing, however this 707 "inserter=" does or can, to queue another message with the same 708 location information, provided the "inserter=" does not move between 709 the time of the original request and the transmission time of the 710 new request. 712 Implementations MAY choose whether or not to inform the user of this 713 error. The text string of "Retry Location Later" is RECOMMENDED, 714 but not mandatory for usage in this error. Implementations MAY use 715 another text string to inform the user that location was not 716 received by the UAS (i.e., the called party). 718 An example of this location error is here: 720 Geolocation-Error: 200; code="Retry Location Later"; 721 node="bob.example.com"; 722 inserter="alice.example.com"; 724 This category covers location errors 2XX; meaning there MAY be more 725 specific errors added to this category in future effort(s). The 726 same basic actionable reaction is expected by a location "inserter=" 727 entity to any 2XX location error. 729 4.3.3 Location Error: 300 "Retry Location Later" (device updated 730 location) 732 The location error 300 "Retry Location Later" (device updated 733 location) indicates to a Geolocation-Error recipient that what they 734 supplied in a request, as far as location is concerned, cannot be 735 processed at this time, but to retry this request, once the location 736 information has been updated, in a new SIP request. 738 Action(s) to be taken by Geolocation-Error receiver to a 3XX: 739 3XX location errors indicate the "inserter=" SIP entity needs 740 to refresh its location, or make the location information 741 supplied more complete, without notifying the user of this 742 error. 3XX error are to be solved by without user 743 intervention. 745 This document gives no guidance how this is accomplished, given the 746 number of ways a UAC can learn its location, or a SIP intermediary 747 can Sight a UAC, as defined in [RFC3693]. 749 This 300 location error currently does not indicate what exactly was 750 wrong with the location supplied, according to the Location 751 Recipient. That is left for a future effort. 753 Implementations MAY choose whether or not to inform the user of this 754 error. The text string of "Retry Location Later" is RECOMMENDED, 755 but not mandatory for usage in this error. Implementation MAY use 756 another text string to inform the user that location was not 757 received by the UAS (i.e., the called party). 759 A 3XX location error would be used where the Location Recipient 760 cannot find or cannot parse the location supplied, believing that a 761 automated refresh and retry could fix the problem. Also, a 3XX 762 location error would be used when a Location Recipient did not find 763 any location in a SIP request, but was expecting it. Perhaps an 764 emergency request was made that did not contain location. The retry 765 in this case would be in the form of an UPDATE Method request, 766 containing location (LbyV or LbyR). 768 An example of this location error is here: 770 Geolocation-Error: 300; code="Retry Location Later"; 771 node="bob.example.com"; 772 inserter="alice.example.com"; 774 This category covers location errors 3XX; meaning there MAY be more 775 specific errors added to this category in future effort(s). The 776 same basic actionable reaction is expected by a location "inserter=" 777 entity to any 3XX location error. 779 4.3.4 Location Error: 400 "Permission Necessary" 781 The location error 400 "Permission Necessary" indicates to a 782 Geolocation-Error recipient that when they set a particular SIP 783 request, they included location in that request without giving 784 permission in the request for a (or any) SIP server to look at that 785 location information to route the message at the intended recipient 786 (i.e., the UAS, or the called party). 788 Action(s) to be taken by Geolocation-Error receiver to a 4XX: 789 4XX location errors indicate to the UAC (i.e., the calling 790 party), that they need to grant permission to a SIP 791 intermediary server to look at the supplied location to 792 complete the message routing. This indication MUST require 793 human user intervention, as the rulemaker of the policy on 794 whether or not their location is to be revealed. 796 The user of the location "inserter=" device can choose to grant 797 permission to this SIP intermediary server to allow this request to 798 be routed, or the user can deny this location revelation (request by 799 the server). It is the user's choice as rulemaker. 801 Implementations MUST provide the user, as rulemaker, a clear 802 indication that permission to consume their location is sought by an 803 entity other than who that user is calling. The text string of 804 "Permission Necessary" is RECOMMENDED, but not mandatory for usage 805 in this error. Implementation MAY use another text string to inform 806 the user that location is being sought by an intermediary (i.e., not 807 the called party). 809 This document gives no guidance how this intervention is 810 accomplished, given the number of ways a UAC can accomplish this 811 (i.e., audio prompt or toggle or keystroke on their UA). 813 This 400 location error currently does not indicate exactly which 814 SIP server indicates it needs the location revealed. That said, the 815 "node=" FQDN address could be supplied, telling the user (via audio 816 or video indication) which SIP entity wants this location. Perhaps 817 the user can know in some circumstances whether this is an 818 appropriate "node=" (domain). All of this is left for a future 819 effort(s). 821 An example of this location error is here: 823 Geolocation-Error: 400; code="Permission Necessary"; 824 node="bob.example.com"; 825 inserter="alice.example.com"; 827 This category covers location errors 4XX; meaning there MAY be more 828 specific errors added to this category in future effort(s). The 829 same actionable solution is expected to be afforded to the UAC user, 830 as rulemaker, to any 4XX location error. 832 4.3.5 Location Error: 500 "Location Information Denial" 834 The location error 500 "Location Information Denial" indicates to a 835 Geolocation-Error recipient that what they supplied in a request, as 836 far as location is concerned, has been denied at this time. 837 This only has to do with the location that the location "inserter=" 838 added to the request, and not about the overall request that was 839 sent. If this were applied to the SIP request itself, this would 840 equate to a 6XX Global error. 842 Action(s) to be taken by Geolocation-Error receiver to a 1XX: 843 This error gives no guidance on what to do next, other than to 844 not try again with this same location supplied. 846 If the Location Recipient believed that merely refreshing, or in 847 some other way alter or augment the location supplied would work in 848 a new request, then a 3XX location error SHOULD have been returned 849 (to the "inserter="). An example of why this 5XX could have been 850 returned is if location were sent as an LbyR, and the LIS denied the 851 dereference request from the Location (reference) Recipient, this is 852 the expected location error returned to the "inserter=" entity. 854 Implementations MUST NOT interpret anything else into this location 855 error other than it is considered a location based denial error. 856 This does not mean the SIP request was denied, or even had an error, 857 unless the response was a 424. Otherwise, this only has to do with 858 the location part of the request. 860 The difference between a 1XX and a 5XX location error is simple. A 861 1XX location error is a case of a Location Recipient either not 862 knowing or not being able to tell the "inserter=" entity what was 863 wrong with the location supplied in a SIP request. Whereas, a 5XX 864 location error is where the location was purposely, and actively 865 denied (or declined) from being received by the Location Recipient 866 entity, or its user. This could occur in a UAS or SIP server. 868 If implementations choose to inform the UAC user of this error, the 869 text string of "Location Information Denial" is RECOMMENDED, but not 870 mandatory for usage in this error. Implementations MAY use another 871 text string. 873 An example of this location error is here: 875 Geolocation-Error: 500; code="Location Information Denial"; 876 node="bob.example.com"; 877 inserter="alice.example.com"; 879 This category covers location errors 5XX; meaning there MAY be more 880 specific errors added to this category in future effort(s). The 881 same basic actionable reaction is expected by a location "inserter=" 882 entity to any 5XX location error. 884 The following are some additional failure scenarios, with which 885 error code is to be used for each at the time of this document: 887 - Scheme (sip:, or sips:, or pres:, or another one) of the LbyR URI 888 isn't supported (100) 889 - Format (geo or civic) isn't supported (100) 890 - Cannot parse location (100) 891 - Can't find LIS (no access or no path (100) or denied access(500)) 892 - Dereference failed (timeout) (200) 893 - Insufficient location info supplied (300) 894 - Cannot find location in message (300) 896 4.4 The 'geolocation' Option Tag 898 This document creates and IANA registers one new option tag: 899 "geolocation". This option tag is to be used, as defined in RFC 900 3261, in the Require, Supported and Unsupported headers. Whenever a 901 UA wants to indicate support for this SIP extension, the geolocation 902 option tag is included in a Supported header of the SIP request. 904 4.5 Using sip/sips/pres as a Dereference Scheme 906 If a LbyR (LbyR) URI is included in a SIP request, it MUST be a SIP, 907 SIPS or PRES-URI. When PRES: is used, if the resulting resolution, 908 as defined in [RFC3856], resolves to a SIP: or SIPS: URI, this 909 section applies. 911 This document IANA registers 3 mandatory to implement URI schemes 912 for LbyR: 914 o SIP: 915 o SIPS: 916 o PRES: 918 These 3 are IANA registered in Section 9.6. 920 These schemes MUST be implemented according to this document. 921 absoluteURI is not mandatory to implement. 923 Dereferencing a Target's location using SIP or SIPS MUST be 924 accomplished by treating the URI as a presence URI and generating a 925 SUBSCRIBE request to a presence server as defined in [RFC3856] 926 using the 'presence' event package. The resulting NOTIFY will 927 contain a PIDF, which MUST contain a PIDF-LO. See Figure 2. for a 928 basic message flow for a dereference. 930 When used in this manner, SIP is a Using Protocol as defined in 931 [RFC3693] and elements receiving location MUST honor the 932 'usage-element' rules as defined in this extension. 934 Alice Location Server Bob 935 | | 936 | INVITE w/ LbyR URI | 937 |-------------------------------------------------------->| 938 | | | 939 | 200 (OK) | 940 |<--------------------------------------------------------| 941 | | | 942 | | SUBSCRIBE to LbyR URI | 943 | |<-----------------------------| 944 | | 200 (OK) | 945 | |----------------------------->| 946 | | | 947 | | NOTIFY w/ PIDF-LO | 948 | |----------------------------->| 949 | | 200 (OK) | 950 | |<-----------------------------| 951 | | | 953 Figure 2. Location-by-Reference and Dereferencing 955 In Figure 2., Alice sends Bob her location in a LbyR URI. Bob 956 receives this LbyR URI in the INVITE and generates a new transaction 957 (SUBSCRIBE) to retrieve the PIDF-LO of Alice. If accepted, the 958 PIDF-LO will be in the NOTIFY request from the Location Server. 959 This is the first instance between Alice and Bob that Alice's 960 location is in any message, therefore it is sent only once, from the 961 Location Server to Bob. 963 A dereference of a LbyR URI using SUBSCRIBE is not violating a 964 PIDF-LO 'retransmission-allowed' element value set to 'no', as the 965 NOTIFY is the only message in this multi-message set of transactions 966 that contains the Target's location, with the location recipient 967 being the only SIP element to receive location - which is the 968 purpose of this extension: to convey location to a specific 969 destination. 971 5. Geolocation Examples 973 This section contains are two examples of messages providing 974 location. One shows LbyV with coordinates, the other shows LbyR. 975 The example for (Coordinate format) is taken from [RFC3825]. A 976 civic format example of the same position on the earth as is in the 977 coordinate format example is in appendix B, which is taken from 978 [RFC4776]. The differences between the two formats are within the 979 of the examples. Other than this portion of each 980 PIDF-LO, the rest is the same for both location formats. 982 The key to the provided samples is in the Geolocation header, which 983 has a different type of URI, based on the different means of 984 location conveyance. Section 5.1 shows a "cid:" URI, indicating 985 this SIP request contains a LbyV message body - which is in the form 986 of a PIDF-LO. Section 5.2 shows a LbyR URI indicating location is 987 to be acquired via an indirection dereference mechanism, which is 988 determined by the scheme of URI supplied. 990 5.1 Location-by-value (Coordinate Format) 992 This example shows an INVITE message with a coordinate, or 993 coordinate location. In this example, the SIP request uses a 994 sips-URI [RFC3261], meaning this message is TLS protected on a 995 hop-by-hop basis all the way to Bob's domain. 997 INVITE sips:bob@biloxi.example.com SIP/2.0 998 Via: SIPS/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bK74bf9 999 Max-Forwards: 70 1000 To: Bob 1001 From: Alice ;tag=9fxced76sl 1002 Call-ID: 3848276298220188511@atlanta.example.com 1003 Geolocation: 1004 ;inserted-by="alice@atlanta.example.com" 1005 Supported: geolocation 1006 Accept: application/sdp, application/pidf+xml 1007 CSeq: 31862 INVITE 1008 Contact: 1009 Content-Type: multipart/mixed; boundary=boundary1 1010 Content-Length: ... 1012 --boundary1 1014 Content-Type: application/sdp 1015 ...SDP goes here 1017 --boundary1 1019 Content-Type: application/pidf+xml 1020 Content-ID: alice123@atlanta.example.com 1022 1023 1027 1028 2007-12-02T14:00:00Z 1029 1030 1031 1032 1033 1034 33.001111 -96.68142 1035 1036 1037 1038 1039 no 1040 2007-12-07T18:00:00Z 1042 1043 DHCP 1044 www.example.com 1045 1046 1047 1048 1049 --boundary1-- 1051 The Geolocation header field from the above INVITE... 1053 Geolocation: 1055 ...indicates the content-ID location [RFC2392] within the multipart 1056 message body of where location information is, with SDP being the 1057 other message body part. The "cid:" eases parsing of message 1058 bodies. 1060 If the Geolocation header field were this instead: 1062 Geolocation: 1064 ...the presence of something other than "cid:" indicates an LbyR is 1065 included in this message. It is expected that any node wanting to 1066 know where user target123 is would subscribe to server5 to 1067 dereference the sips-URI (see Figure 2. for this message flow, and 1068 Section 5.2 for this decoded example). The returning NOTIFY would 1069 contain Alice's location in a PIDF-LO, as if it were included in a 1070 message body (part) of the original INVITE here. 1072 5.2 Location-by-reference 1074 Below is an INVITE request with a LbyR URI instead of a LbyV PIDF-LO 1075 message body part shown in Section 5.1. It is up to the location 1076 recipient to dereference Alice's location at the Atlanta LIS server 1077 containing the location record. Dereferencing, if done with SIP, is 1078 accomplished by the Location Recipient sending a SUBSCRIBE request 1079 to the URI reference for Alice's location. The received NOTIFY is 1080 the first SIP request containing Alice's UA location, as a PIDF-LO 1081 message body (see Figure 2 for this message flow example). The 1082 NOTIFY, in this case, is the SIP request that is conveying location, 1083 and not the INVITE. There is no retransmission of location in this 1084 usage. 1086 INVITE sips:bob@biloxi.example.com SIP/2.0 1087 Via: SIP/2.0/TLS pc33.atlanta.example.com 1088 ;branch=z9hG4bK74bf9 1089 Max-Forwards: 70 1090 To: Bob 1091 From: Alice ;tag=9fxced76sl 1092 Call-ID: 3848276298220188511@atlanta.example.com 1093 Geolocation: 1094 ;inserted-by="bigbox3.atlanta.example.com" 1095 Supported: geolocation 1096 Accept: application/sdp, application/pidf+xml 1097 CSeq: 31862 INVITE 1098 Contact: 1100 ...SDP goes here as the only message body 1102 A Location Recipient would need to dereference the sips-URI in the 1103 Geolocation header field to retrieve Alice's location. If the 1104 atlanta.example.com domain chooses to implement location conveyance 1105 and delivery in this fashion (i.e., LbyR), it is RECOMMENDED that 1106 entities outside this domain be able to reach the dereference 1107 server, otherwise this model of implementation is only viable within 1108 the atlanta.example.com domain. 1110 6. SIP Element Behavior 1112 Because a device's location is generally considered to be sensitive 1113 in nature, location information needs to be protected when 1114 transmitted. This can be addressed through securing the location 1115 information to prevent either viewing or changing the PIDF-LO. 1117 Section 26 of [RFC3261] defines the security functionality SIPS by 1118 transporting SIP messages with either TLS or IPSec protection 1119 between SIP entities. 1121 If a SIP entity wants to prevent all SIP entities in a request path 1122 from viewing or just changing the contents of the PIDF-LO, save 1123 those that possess decryption key, the message body needs to be 1124 secure by a means such as S/MIME. This would be the case in which a 1125 UAC wants to make sure only the destination UAS can read the 1126 PIDF-LO. S/MIME can be used for just signing, and not encrypting, a 1127 PIDF-LO message body to ensure the integrity of the PIDF-LO is 1128 maintained. 1130 6.1 UAC Behavior 1132 A UAC can send location in a SIP request, either because it is 1133 expected to facilitate location-based routing of the request, or 1134 spontaneously (i.e., a purpose not defined in this document but 1135 known to the UAC). Alice communicating to Bob her location in a SIP 1136 Message request is a simple example of this. If Alice wanted to 1137 include her location as a message body in an INVITE that also has an 1138 SDP message body, the Content-Type: Multipart MUST be supported by 1139 both UAC and UAS. Multipart comes in many forms (/mixed, 1140 /alternative, etc), and this document does not limit which type of 1141 Multipart is used, though future documents MAY specify or limit 1142 Multipart to a subset of all the choices for a given use. 1144 A UAC conveying location MUST include a locationValue in a 1145 Geolocation header (see section 4.1) with either an LbyV indication 1146 (a cid-URL), or an LbyR. An LbyV message body sent without a 1147 Geolocation header field MUST NOT occur. The UAC supporting this 1148 extension MUST include a Supported header with the 'geolocation' 1149 option tag. 1151 More than one location format (civic and coordinate) can be included 1152 in the same message body part, but all location parts of the same 1153 PIDF-LO MUST point at the same position on the earth, identifying 1154 the same target. The same location in multiple formats, for 1155 example, a partial or complete geodetic and a partial or complete 1156 civic, can allow the recipient to use the most convenient or 1157 preferable format for its use. 1159 Multiple PIDF-LOs are allowed in the same request, with each allowed 1160 to point at separate positions - however, each PIDF-LO MUST identify 1161 a different Target. Therefore, there will be no confusion by a 1162 Location Recipient receiving more than one PIDF-LO (in a message 1163 body or when dereferenced, or a combination). It is RECOMMENDED 1164 there is only one locationValue in a single SIP request for the same 1165 Target. More than one will likely lead to confusion by a Location 1166 Recipient because this extension does not provide guidance on what a 1167 recipient is to do with more than one location, nor does it give any 1168 preference regarding which location is better or worse than another 1169 location in the same request. 1171 The 'geolocation' option tag is inserted in a Supported header by a 1172 UAC to provide an indication of support for this extension. The 1173 presence of the 'geolocation' option tag in a Supported header 1174 without a Geolocation header field in the same message informs a SIP 1175 element receiving this request that the UAC understands this 1176 extension, but it does not know or wish to convey its location at 1177 this time. Certain scenarios exist (location-based retargeting) in 1178 which location is required in a SIP request in order to retarget the 1179 message properly. This affects how a UAS or SIP server processes 1180 such a request. 1182 The 'geolocation' option tag SHOULD NOT be used in the Proxy-Require 1183 Header, because the UAC often will not know the underlying topology 1184 to know which proxy will do the retargeting, thus increasing the 1185 likelihood of a request failure by the first hop proxy that does not 1186 understand this extension, but is required to by inclusion of the 1187 option tag in this header. 1189 A UAC inserting a locationValue MUST include an "inserted-by=" 1190 parameter to indicate its hostport. This is copied to the 1191 "inserter=" parameter of the Geolocation-Error header in a response 1192 if a Location Recipient determines there is something wrong with the 1193 locationValue in this request. Because more than one locationValue 1194 can be inserted along the path of the request, this indication is 1195 necessary to show which locationValue had the problem in the 1196 response, and who the locationErrorValue is for. For example: 1198 Geolocation: ; 1199 inserted-by="alice@atlanta.example.com" 1201 If a UAC does not learn and store its location locally (a GPS chip) 1202 or from the network (DHCP or LLDP-MED), the UAC MAY learn its LbyR 1203 URI (from DHCP for example. If the latter is the case, the UAC MAY 1204 SUBSCRIBE to this LbyR URI, using the 'presence' event package, to 1205 get and store its own location. This document does not give a 1206 reason why a UAC would want to do this. 1208 Possession of a Target's LbyR, even though the act of dereferencing 1209 this URI will be challenged by a LIS were this location record is - 1210 providing a good deal of protection, SHOULD still be treated as 1211 equivalent to possession of the location information itself and thus 1212 TLS SHOULD be used when transmitting LbyR hop-by-hop along the path 1213 to the Location Recipient. 1215 A PIDF includes identity information. It is possible for the 1216 identity in the PIDF to be anonymous. Implementations of this 1217 extension SHOULD consider the appropriateness of including an 1218 anonymous identity in the location information where a real identity 1219 is not required. When using LbyR, the LbyR MUST NOT contain any 1220 user identifying information. For example, use something 1221 unidentifiable like 1222 3fg5t5yqw@example.atlanta.com 1224 rather than 1226 aliceishere@example.atlanta.com). 1228 Use of elf-signed certificates is inappropriate for used in 1229 protecting a PIDF, as the sender does not have a secure identity of 1230 the recipient. 1232 6.1.1 UAC Receiving a Location Failure Indication 1234 Location Recipients can be either, or both, destination UASs and 1235 intermediate servers that use the location information for 1236 location-based routing decisions. If a sent request fails based on 1237 the location information in the request, a 424 (Bad Location 1238 Information) response is sent back to the UAC. The 424 MUST have a 1239 Geolocation-Error header containing one or more locationErrorValues 1240 in the response message. A locationErrorValue has a header 1241 parameter indicating which entity inserted the locationValue 1242 correlated to this error, called the "inserter=" parameter. This 1243 "inserter=" parameter (in the locationErrorValue) is copied from the 1244 "inserted-by=" parameter (from the locationValue) by the Location 1245 Recipient (UAS or proxy) sending the error response. A UAC 1246 receiving a Geolocation-Error in any response type MUST review the 1247 "inserter=" parameter in the locationErrorValue to see if it 1248 indicates this UAC. If locationErrorValue does not match, the 1249 locationErrorValue MUST be ignored. If a locationErrorValue is in a 1250 424, and the "inserter=" entity is not this UAC, the response SHOULD 1251 be treated as a 400 response. If locationErrorValue does indicate 1252 this UAC, this UAC MUST process the response, including the 1253 Geolocation-Error code (defined in section 4.3). Further, UAC MUST 1254 ignore a Geolocation-Error header value, even for this UAC, even in 1255 a 424 response if the UAC did not include a Geolocation header value 1256 (with locationValue) in the request part of the transaction. 1258 A UAC MAY reattempt a new request if it believes it can correct the 1259 stated failure in the Geolocation-Error header, unless the location 1260 error is a 5XX level error - which clearly states in Section 4.3 not 1261 to do this. A UAC MUST follow all the guidance that pertains to 1262 UACs from Section 4.3 (Geolocation-Error header), heeding what to do 1263 in case it receives any of the error codes articulated in that 1264 section. 1266 Any UAC that inserted location into a request SHOULD be prepared to 1267 receive the Geolocation-Error header in any response, looking to 1268 determine if a locationErrorValue is meant for the UAC, and to react 1269 accordingly. 1271 If a UAC includes location in a request, and either the UAS does not 1272 determine errored location was critical to the transaction and 1273 accept the request, or the request failed for reason other than 1274 location, any response MAY contain a Geolocation-Error header 1275 containing a locationErrorValue with the details of the location 1276 error. 1278 6.2 UAS Behavior 1280 If the Geolocation header field is present in a received SIP 1281 request, the type of URI contained in the locationValue will 1282 indicate if location is an LbyV in a message body (part) or LbyR, 1283 requiring an additional dereference transaction. If the LbyR URI is 1284 sip:, sips: or pres:, and the UAS wants to leran the UAC's location, 1285 the UAS MUST initiate a SUBSCRIBE to the URI provided to retrieve 1286 the PIDF-LO being conveyed by the UAC as defined in [RFC3856]. If 1287 successful, the PIDF-LO will be returned in the NOTIFY request from 1288 the remote host. The UAS is not REQUIRED to dereference the LbyR if 1289 it does not want to (by configuration or user choice). It is 1290 RECOMMENDED the UAS render the location sent to it, however it is 1291 configured to do so. 1293 A Require header with the 'geolocation' option tag indicates the 1294 UAC is requiring the UAS understand this extension or else send 1295 an error response. A 420 (Bad Extension) with a 'geolocation' 1296 option tag in an Unsupported header would be the appropriate 1297 response in this case. 1299 It is possible, but undesirable, for a message to arrive with a body 1300 containing a LbyV, but with no Geolocation header field value 1301 pointing to it (potentially no Geolocation header field at all). In 1302 this case, the recipient MAY still read and use the message body. 1303 Unless stated otherwise by future standards-track publication(s), a 1304 LbyR URI only has meaning within the Geolocation header field and 1305 MUST NOT appear in any other SIP header field. 1307 There are 2 Geolocation header parameters, 1309 o "inserted-by=" 1310 o "used-for-routing" 1312 The "inserted-by=" parameter informs a Location Recipient which SIP 1313 element added this locationValue to the SIP request. This parameter 1314 is mandatory for each locationValue in the request. The value in 1315 the "inserted-by=" parameter is copied into the "inserter=" 1316 parameter in each locationErrorValue if there is an error in the 1317 location to be reported back to the location sender. See section 1318 6.2.1. 1320 The "used-for-routing" parameter is included in the locationValue if 1321 a SIP server used the location in the request to determine how to 1322 route or forward the message towards the ultimate destination. If 1323 there are more than one locationValues in the Geolocation header, 1324 and it is possible that different locationValues were used to route 1325 the message at different times of this request's journey. This is 1326 allowed, as it is consistent with the rule that anytime a message is 1327 routed based upon a locationValue, a "used-for-routing" parameter is 1328 added to the applicable locationValue. This parameter should be 1329 present in each locationValue used along the path. A 1330 "used-for-routing" parameter MUST NOT ever be removed from a 1331 locationValue in a request. 1333 Additional locationValues inserted into a request SHOULD be placed 1334 the order they were generated, and not rearranged. This informs a 1335 Location Recipient which was the last locationValue in the message 1336 that was used to route the message. This is for troubleshooting and 1337 management reasons. 1339 Individual header parameters in any received locationValue MUST NOT 1340 be modified or deleted in transit to the ultimate destination. 1342 A UAS MUST NOT send location in a response message, as there can be 1343 any number of issues/problems with receiving location, and the UAC 1344 or proxy servers cannot error a response. Therefore, the UAS, if it 1345 wants to send a UAC its location, SHOULD do so in a new request in a 1346 separate transaction. This document gives no guidance which SIP 1347 request to use, but SIP MESSAGE is a viable choice. 1349 A UAS MAY include a 'geolocation' option tag in the Supported header 1350 of a response, indicating it does understand this extension, even if 1351 location was not in a request to the UAS. 1353 A UAS wishing to dereference a LbyR URI contained in a received 1354 request will use the 'presence' event package in a SUBSCRIBE request 1355 to the URI. If accepted, the PIDF-LO will return to the UAS in a 1356 NOTIFY request. If there are any errors during dereferencing, or in 1357 the PIDF-LO itself, the UAS will error the original request to the 1358 UAC with a locationErrorValue indicating what the UAS concluded was 1359 wrong with the location. This is to include any dereferencing 1360 problems encountered. 1362 Section 4.5 of this document called for the IANA registration of 3 1363 URI schemes (sip:, sips:, and pres:) that are mandatory to implement 1364 for dereferencing. 1366 If there is more than one location (any combination of LbyV and 1367 LbyR), this document does not give guidance what a Location 1368 Recipient does with each location. There are no priority or 1369 more-trusted indications given by this document. All this is 1370 considered application specific, and out-of-scope of this document. 1371 This document makes it clear that if when there are more than one 1372 location, each in the same PIDF-LO MUST be about the same Target 1373 (identifier) and point at the same position on the earth. If there 1374 are more than one PIDF-LOs with different Target identifiers, then 1375 the UAC is merely telling the UAS where more than one Target is, and 1376 there should not be any conflict. 1378 6.2.1 UAS Generating a Location Failure Indication 1380 If a UAS receives location in a request, but determines there is a 1381 problem with the location in the request, it is the responsibility 1382 of the UAS to inform whomever inserted location into that request 1383 there was a problem experienced. The Geolocation header in the 1384 request has a locationValue, providing the UAS a URI indicating 1385 where the Target's location is. The Location Target identified in 1386 the PIDF-LO may or may not be the location inserter, or the 1387 generator of the request (the UAC or SIP server). Ultimately, 1388 location is in a PIDF-LO. This is either in the request as a 1389 message body (LbyV), or it has to be dereferenced from the LbyR in 1390 the locationValue in the request. LbyR records are typically kept 1391 on a LIS, which can challenge all dereference requests. All 1392 PIDF-LOs have a Location Target identifier. This is who the 1393 location is about. The "inserted-by=" parameter of the 1394 locationValue tells the UAS who inserted that locationValue. This 1395 "inserted-by=" parameter is copied into the "inserter=" parameter of 1396 the locationErrorValue generated by the Location Recipient (the 1397 UAS), in a response, when it wants to inform the location 1398 "inserter=" entity there was a problem with the location it 1399 received. 1401 There can be more than one locationValues in a request. The 1402 "inserter=" parameter in the locationErrorValue will distinguish it 1403 from being misunderstood by entities that did not insert the errored 1404 location. 1406 If there is one valid locationValue in a request, even if all the 1407 others have errors with them, a 424 (Bad Location Information) 1408 response MUST NOT be sent. The Location Recipient (the UAS) is 1409 RECOMMENDED to send a locationErrorValue for each errored 1410 locationValue, with unique "inserter=" parameters to make sure the 1411 right entities know which locations were in error. 1413 As hinted at, a location "inserter=" can be a UAC or it can be an 1414 in-signaling-path SIP server, who is acting as a UAC Sighter, as 1415 defined in RFC3693. This means the SIP server is including its 1416 version of where it thinks the UAC is, geographically. This 1417 "inserter=" has to be in the form of a LbyR URI in a locationValue, 1418 because SIP servers are not allowed to insert message bodies, as of 1419 the time of this publication, from all the way back to RFC3261. 1421 Each locationErrorValue has a error code, letting the location 1422 "inserter=" entity know what was wrong with the location supplied. 1423 See Section 4.3 for the 5 actionable responses a UAC can take from 1424 a locationErrorValue. 1426 If the location "inserted-by=" entity, meaning either the UAC or 1427 proxy in the message path, chose to indicate that location was so 1428 important in the request to include a 'geolocation' option tag in a 1429 Require header, the response SHOULD be a 424 (Bad Location 1430 Information) back to the "inserter=" entity (knowing the response 1431 will ultimately go to the UAC regardless) if there needs to be a 1432 locationErrorValue sent because the location was bad. Only entities 1433 identified in a locationErrorValue as the "inserter=" entity will 1434 pay attention to this locationErrorValue. All other entities MUST 1435 ignore any locationErrorValue not directed towards them. See 1436 section 4.3 for more information on this, including all the location 1437 specific errors and Geolocation-Error header parameters. 1439 In the above scenario ('geolocation' option tag in a Require 1440 header), the only other response can be a 420, but only if the UAS 1441 does not support this Geolocation extension to SIP, else the 424 is 1442 sent. 1444 If the location "inserted-by=" entity placed the 'geolocation' 1445 option tag in a Supported header, the response can be a 424 if it 1446 chooses, but also can be any other SIP response, including a 200 1447 OK. A locationErrorValue in a Geolocation-Error header that is not 1448 in a 424 (Bad Location Information) response is considered 1449 informational by the Location Recipient, and not considered 1450 important enough to reject the request based solely on bad location 1451 information. 1453 For example, Alice INVITEs Bob to a dialog, and includes geolocation 1454 in the request. Bob can accept the INVITE with a 200 OK and still 1455 add a locationErrorValue in the 200 OK indicating "yes, I accept 1456 your request, and btw, something was wrong with the location you 1457 provided (in the INVITE)". What was wrong with the location is 1458 indicated by the Geolocation-Error code. Who this 1459 locationErrorValue is for is indicated by the "inserter=" parameter. 1461 Each locationErrorValue is destined for one "inserter=" entity. 1462 This gives a Location Recipient one mechanism to tell each inserter 1463 what the Location Recipient concluded was wrong with what the 1464 "inserter=" included (as far as location is concerned). Therefore, 1466 o there MUST be a locationErrorValue for each locationValue that 1467 was considered bad by the UAS to ensure each upstream location 1468 inserter understands which error code(s) is intended for them 1469 (and which to ignore). 1471 o there MUST NOT be more than one locationErrorValue in the 1472 response per locationValue in the request. 1474 o there MUST NOT be more than one locationErrorValue to the same 1475 "inserter=" in the request. 1477 o there MUST NOT be a locationErrorValue in the response for a 1478 locationValue in the request that was not in error, according to 1479 the Location Recipient. 1481 Here is an example of a Geolocation-Error header 1483 Geolocation-Error: 400; code="Permission Necessary"; 1484 node="server42.example2.com"; 1485 inserter="alice.example.com"; 1487 The above example says that the Location Recipient is 1488 server42.example.com, and this entity believes it cannot route this 1489 message without knowing the "inserter="'s location. This location 1490 may be in the request, or it may need to be in the request and was 1491 not. If location is encrypted, server42 doesn't know it is in the 1492 request. server42.example.com sends a 424 (Bad Location 1493 Information) response with a locationErrorValue indicating a 400 1494 location error, which means it requires permission to view Alice's 1495 location to proceed with processing her signaling. Section 4.3 1496 highlights this example, stating the user, Alice, MUST be made aware 1497 of this location revelation request. This document does not give 1498 any guidance how Alice is to be informed (i.e., audio, visual, 1499 etc). Alice can grant permission or choose not to, knowing this SIP 1500 request attempt (to this destination, at this time) will fail. The 1501 problem could be corrected if a future SIP request were to travel 1502 through a different server than server42 (or it might not). 1504 See Section 4.3 for further rules about the Geolocation-Error header 1505 and the locationErrorValue. 1507 This document says nothing about what a Location Recipient does with 1508 more than one 'good' locationValue in a request (i.e., which to 1509 choose to use). This scenario MAY be addressed in a future effort. 1511 Further, more than one error code is allowed in the 1512 locationErrorValue - each having one "inserter=" parameter. The 1513 error codes destined for the same inserter MUST NOT contradict the 1514 meaning of the problem the Location Recipient had with a particular 1515 locationValue. 1517 6.3 Proxy Behavior 1519 [RFC3261] states message bodies cannot be added by proxies. 1520 However, proxies are permitted to add a header to a request. This 1521 implies that a proxy can add a Geolocation locationValue with 1522 LbyR URI, but not LbyV message body. 1524 It is allowed, but NOT RECOMMENDED, for more than one SIP element to 1525 insert location into a request along its path. As described earlier 1526 in this document, each insertion of location into a SIP request is 1527 accompanied by a new locationValue in a Geolocation header. Also 1528 described earlier, each locationValue MUST contain an "inserted-by=" 1529 value indicating to a Location Recipient which host inserted 1530 location into a particular request. 1532 However, if location is already in a SIP request, a SIP server 1533 SHOULD NOT add another LbyR that identifies the same target in the 1534 PIDF-LO (in the element) to the same request. This will 1535 likely cause confusion at the Location Recipient as to which to use. 1537 A proxy is permitted to read any locationValue, and the associated 1538 body, if not S/MIME protected, in transit if present, and can use 1539 the contents of the header field to make location-based retargeting 1540 decisions, if retargeting requests based on location is a function 1541 of that proxy. Retargeting is defined in [RFC3261]. 1543 More than one Geolocation locationValue in a message is permitted, 1544 but can cause confusion at the recipient. If a proxy chooses to add 1545 a locationValue to a Geolocation header, which would be a local 1546 policy decision, the new locationValue MUST be added to the end of 1547 the header (after previous locationValue(s)). This is done to 1548 create an order of insertion of locationValues along the path. 1549 Proxies MUST NOT modify the order of locationValues in a geolocation 1550 header. 1552 A proxy wishing to dereference a LbyR URI contained in a received 1553 request will use the 'presence' event package in a SUBSCRIBE request 1554 to the URI. If accepted, the PIDF-LO will return to the proxy in a 1555 NOTIFY request. If there are any errors during dereferencing, or in 1556 the PIDF-LO itself, the proxy will error the original request to the 1557 UAC with a locationErrorValue indicating what the proxy concluded 1558 was wrong with the location. This is to include any dereferencing 1559 problems encountered. 1561 6.3.1 Proxy Behavior with Geolocation Header Parameters 1563 SIP servers MUST NOT delete any existing Geolocation locationValue 1564 (URI or header parameter) from a request. An existing locationValue 1565 (URI or header parameter) MAY only be modified by adding a 1566 "used-for-routing" parameter to an existing locationValue, if the 1567 request was retargeted based on the location within that 1568 locationValue. Further modification of this Geolocation header 1569 field MUST NOT occur. For example, an existing Geolocation 1570 locationValue in a request of: 1572 Geolocation: ; 1573 inserted-by="alice123@atlanta.example.com"; 1575 can be modified by a proxy to add the "used-for-routing" parameter, 1576 like this: 1578 Geolocation: ; 1579 inserted-by="alice123@atlanta.example.com"; 1580 used-for-routing 1582 if this is the locationValue the proxy used to make a retargeting 1583 decision based upon, but make no other modification. 1585 A SIP server MAY add a new Geolocation locationValue to a SIP 1586 request. The proxy SHOULD NOT insert a locationValue of a Location 1587 Target unless it is reasonably certain it knows the actual location 1588 of the Location Target, for example, if it thoroughly understands 1589 the topology of the underlying access network and it can identify 1590 the device reliably (in the presence of, for example, NAT or VPN). 1592 A server adding a locationValue to an existing Geolocation header 1593 would look like: 1595 Geolocation: ; 1596 inserted-by="alice123@atlanta.example.com", 1597 ; 1598 inserted-by="lis1.atlanta.example.com" 1600 Notice the locationValue added by the proxy is last among 1601 locationValues. This practice MUST be done for all added 1602 locationValues. 1604 If this request was then retargeted by an intermediary using the 1605 locationValue inserted by the server, the intermediary would add a 1606 "used-for-routing" parameter like this: 1608 Geolocation: ; 1609 inserted-by="alice123@atlanta.example.com", 1610 ; 1611 inserted-by="lis1.atlanta.example.com"; used-for-routing 1613 It is conceivable that an initial routing decision is made on 1614 one locationValue, and subsequently another routing decision is 1615 made on a different locationValue further towards the ultimate 1616 destination. This retargeting decision can be made on a newly 1617 inserted locationValue. While unusual, it can occur. In such a 1618 case, proxies MUST NOT remove any existing "used-for-routing" header 1619 parameter. In this instance, the SIP server retargeting based on 1620 another locationValue MUST add the "used-for-routing" header 1621 parameter to the locationValue used for retargeting by this server. 1622 This will result in a Geolocation header looking as if it were 1623 retargeting more than once, which would be true - and is the desired 1624 outcome. 1626 A Proxy that inserts or adds locationValue into a request MAY move a 1627 'geolocation' option that is in a Supported header into a Require 1628 header if this proxy deems geolocation to be that important to 1629 Location Recipient(s) of this request. 1631 6.3.2 Proxy Error Behavior for Sending or Receiving locationErrorValues 1633 For proxies that receive a SIP request that contains a location 1634 error, either in a contained message body or after the proxy does a 1635 dereference of the LbyR URI, all the rules applicable to a UAS apply 1636 here (see Section 6.2.1.), since in this case, the proxy is 1637 considered a Location Recipient. Therefore, there is no reason to 1638 restate them here, and potentially have the two sections be 1639 inconsistent. The one thing to add is that a proxy does not need to 1640 examine location contained in a request. Section 6.2.1. only applies 1641 to proxies that are needing, monitoring or policing location within 1642 requests (for whatever reason). 1644 If a proxy inserted a locationValue into a request, it SHOULD be 1645 ready to examine the response to that request, in case there is one 1646 or more location errors in the response. To a great degree, this 1647 scenario has the proxy behaving as a UAC (see section 6.1.1.) that 1648 included a locationValue a request, which then receives an error to 1649 that locationValue. 1651 This location inserting proxy SHOULD be transaction stateful for the 1652 response. If the proxy is configured as a stateless proxy, and it 1653 inserts location, it MUST process and monitor all SIP responses, 1654 looking for locationErrorValues that indicate it was the "inserter=" 1655 to learn that location it supplied was in error. It SHOULD react 1656 accordingly to the error code received. This document gives no 1657 guidance what the proxy should do to rectify the bad location 1658 information, but a future document MAY address this. 1660 7. Geopriv Privacy Considerations 1662 Location information is considered by most to be highly 1663 sensitive information, requiring protection from eavesdropping, 1664 and altering in transit. [RFC3693] articulates rules to 1665 be followed by any protocol wishing to be considered a "Using 1666 Protocol", specifying how a transport protocol meets those rules. 1667 This section describes how SIP as a Using Protocol meets those 1668 requirements. 1670 Quoting requirement #4 of [RFC3693]: 1672 "The Using Protocol has to obey the privacy and security 1673 instructions coded in the Location Object and in the 1674 corresponding Rules regarding the transmission and storage 1675 of the LO." 1677 This document requires that SIP entities sending or receiving 1678 location MUST obey such instructions. 1680 Quoting requirement #5 of [RFC3693]: 1682 "The Using Protocol will typically facilitate that the keys 1683 associated with the credentials are transported to the 1684 respective parties, that is, key establishment is the 1685 responsibility of the Using Protocol." 1687 [RFC3261] and the documents it references define the key 1688 establishment mechanisms. 1690 Quoting requirement #6 of [RFC3693]: 1692 "(Single Message Transfer) In particular, for tracking of 1693 small Target devices, the design should allow a single 1694 message/packet transmission of location as a complete 1695 transaction." 1697 When used for tracking, a simple NOTIFY or UPDATE normally is 1698 relatively small, although the PIDF itself can get large. Normal 1699 RFC 3261 procedures of reverting to TCP when the MTU size is 1700 exceeded would be invoked. 1702 8. Security Considerations 1704 Conveyance of physical location of a UAC raises privacy concerns, 1705 and depending on use, there probably will be authentication and 1706 integrity concerns. This document calls for conveyance to normally 1707 be accomplished through secure mechanisms, like S/MIME protecting 1708 message bodies (but this is not widely deployed) or TLS protecting 1709 the overall signaling. In cases where a session set-up is 1710 retargeted based on the location of the UAC initiating the call or 1711 SIP MESSAGE, securing the LbyV location with an end-to-end 1712 mechanism such as S/MIME is problematic, because one or more proxies 1713 on the path need the ability to read the location information to 1714 retarget the message to the appropriate new destination UAS. 1715 Securing the location hop-by-hop, using TLS, protects the message 1716 from eavesdropping and modification, but exposes the information to 1717 all proxies on the path as well as the endpoint. In most cases, the 1718 UAC does not know the identity of the proxy or proxies providing 1719 location-based routing services, so that end-to-middle solutions 1720 might not be appropriate either. 1722 These same issues exist for basic SIP signaling, but SIP normally 1723 does not carry information to physically track a user; making this 1724 extension especially sensitive. 1726 When location is inserted by a UAC, which is RECOMMENDED, it can 1727 decide whether to reveal its location using hop-by-hop methods. UAC 1728 implementations MUST make such capabilities conditional on explicit 1729 user permission, and SHOULD alert a user that location is being 1730 conveyed. Proxies inserting location for location-based routing are 1731 unable to meet this requirement, and such use is NOT RECOMMENDED. 1732 Proxies conveying location using this extension MUST have the 1733 permission of the Target to do so. 1735 One facet within this extension is such that locations can be placed 1736 on a remote server, accessible with the possession of a URI. The 1737 concept of a LbyR URI has its own security considerations. It is 1738 tempting to assume that the dereference would have authentication, 1739 authorization and other security mechanisms that limit the access to 1740 information. Unfortunately, this might not be true. The access 1741 network the UAC is connected to can be the source of location 1742 reference, and it might not have any credentialing mechanism 1743 suitable for controlling access to location. Consider, 1744 specifically, a nomadic user connected to an access network in a 1745 hotel. The UAC has no way to provide a credential acceptable to 1746 the hotel Location Server (LS) to any of its intended Location 1747 Recipients. The recipient of a reference does not know if a 1748 reference has appropriate authorization policies or not. The LS 1749 should provide location to any requestor. 1751 Accordingly, possession of the reference should be considered 1752 equivalent to possession of the value, and the reference should be 1753 treated with the same degree of care as the value. Specifically, 1754 TLS MUST be used to protect the security of the reference. Notice 1755 that this does not constrain the dereference protocol to use TLS. 1756 That specification is left entirely to the dereferencing protocol 1757 documents. 1759 There is no integrity on any locationValue or locationErrorValue 1760 header parameter end-to-end (or middle-to-end if the value was 1761 inserted by a intermediary), so recipients of either header need to 1762 implicitly trust the header contents, and take whatever precautions 1763 each entity deems appropriate give these facts. 1765 9. IANA Considerations 1767 The following are the IANA considerations made by this SIP 1768 extension. Modifications and additions to these registrations 1769 require a standards track RFC (Standards Action). 1771 9.1 IANA Registration for the SIP Geolocation Header 1773 The SIP Geolocation header is created by this document, with its 1774 definition and rules in Section 4.1 of this document, to be added to 1775 the sip-parameters, in the portion titled "Header Field Parameters 1776 and Parameter Values". 1778 Predefined 1779 Header Field Parameter Name Values Reference 1780 ---------------- ------------------- ---------- --------- 1781 Geolocation inserted-by= no [this doc] 1782 Geolocation used-for-routing no [this doc] 1784 9.2 IANA Registration for New SIP Option Tag 1786 The SIP option tag "geolocation" is created by this document, with 1787 the definition and rule in Section 4.4 of this document, to be added 1788 to sip-parameters within IANA. 1790 9.3 IANA Registration for Response Code 424 1792 Reference: RFC-XXXX (i.e., this document) 1793 Response code: 424 (recommended number to assign) 1794 Default reason phrase: Bad Location Information 1796 This SIP Response code is defined in section 4.2 of this document. 1798 9.4 IANA Registration of New Geolocation-Error Header 1800 The SIP Geolocation-error header is created by this document, with 1801 its definition and rules in Section 4.3 of this document, to be 1802 added to the sip-parameters, in the portion titled "Header Field 1803 Parameters and Parameter Values". 1805 Predefined 1806 Header Field Parameter Name Values Reference 1807 ----------------- ------------------- ---------- --------- 1808 Geolocation-Error inserter= no [this doc] 1809 Geolocation-Error node= no [this doc] 1810 Geolocation-Error code= no [this doc] 1812 9.5 IANA Registration for the SIP Geolocation-Error Codes 1814 New location specific Geolocation-Error codes are created by this 1815 document, and registered in a new table at sip-parameters within 1816 IANA. Details of these error codes are in Section 4.3 of this 1817 document. 1819 Geolocation-Error codes 1820 ----------------------- 1821 Geolocation-Error codes provide reason for the error discovered by 1822 Location Recipients, categorized by action to be taken by error 1823 recipient to be placed into SIP responses to inform the location 1824 inserter of the error. 1826 Code Description Reference 1827 ---- --------------------------------------------------- --------- 1828 100 "Cannot Process Location" General location error, [this doc] 1829 meaning location in the request cannot be 1830 processed at this time. No actionable guidance. 1831 Can be treated as a 200 or 300 error by error 1832 recipient. 1834 200 "Retry Location Later" (with same data) Location [this doc] 1835 cannot be processed at this time. Error recipient 1836 should try again with same data. 1838 300 "Retry Location Later" (with device updated location) [this doc] 1839 Location cannot be processed at this time. Error 1840 recipient should try again with same data. 1842 400 "Permission Necessary" Permission from calling user [this doc] 1843 to reveal location in request before request can 1844 be processed. This is a routing by location error. 1845 User MUST be informed of permission request. 1847 500 "Location Information Denial" Request was actively 1848 denied because of the location in the request. 1849 Recipient should not try again. 1851 9.6 IANA Registration of LbyR Schemes 1853 This document directs IANA to create a new set of parameters in a 1854 separate location from SIP and Geopriv, called the "Location 1855 Reference URI" registry, containing the URI scheme, the 1856 Content-Type, and the reference. Below is an example of how it 1857 could look 1859 URI Scheme Content-Type Reference 1860 ---------- ------------ --------- 1861 SIP: [this doc] 1862 SIPS: [this doc] 1863 PRES: [this doc] 1865 Additions to this registry require an industry specification. 1867 10. Acknowledgements 1869 To Dave Oran for helping to shape this idea. To Jon Peterson and 1870 Dean Willis on guidance of the effort. To Allison Mankin, Dick 1871 Knight, Hannes Tschofenig, Henning Schulzrinne, James Winterbottom, 1872 Jeroen van Bemmel, Jean-Francois Mule, Jonathan Rosenberg, Keith 1873 Drage, Marc Linsner, Martin Thomson, Mike Hammer, Paul Kyzivat, 1874 Shida Shubert, Umesh Sharma, Richard Barnes, Ted Hardie and Matt 1875 Lepinski for constructive feedback. A special thanks to Dan Wing 1876 for help with the S/MIME example, and to Robert Sparks for many 1877 helpful comments and the proper building of the Geolocation-Error 1878 header. 1880 11. References 1882 11.1 References - Normative 1884 [RFC3261] J. Rosenberg, H. Schulzrinne, G. Camarillo, A. Johnston, J. 1885 Peterson, R. Sparks, M. Handley, and E. Schooler, "SIP: 1886 Session Initiation Protocol", RFC 3261, May 2002. 1888 [RFC4119] J. Peterson, "A Presence-based GEOPRIV Location Object 1889 Format", RFC 4119, December 2005 1891 [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate 1892 Requirement Levels", RFC 2119, March 1997 1894 [RFC2392] E. Levinson, " Content-ID and Message-ID Uniform Resource 1895 Locators", RFC 2393, August 1998 1897 [RFC3863] H. Sugano, S. Fujimoto, G. Klyne, A. Bateman, W. Carr, J. 1898 Peterson, "Presence Information Data Format (PIDF)", RFC 1899 3863, August 2004 1901 [RFC3856] J. Rosenberg, " A Presence Event Package for the Session 1902 Initiation Protocol (SIP)", RFC 3856, August 2004 1904 [RFC3859] J. Peterson, "Common Profile for Presence (CPP)", RFC 3859, 1905 August 2004 1907 [RFC3428] B. Campbell, Ed., J. Rosenberg, H. Schulzrinne, C. Huitema, 1908 D. Gurle, "Session Initiation Protocol (SIP) Extension for 1909 Instant Messaging" , RFC 3428, December 2002 1911 [RFC3311] J. Rosenberg, "The Session Initiation Protocol (SIP) UPDATE 1912 Method", RFC 3311, October 2002 1914 [RFC3265] Roach, A., "Session Initiation Protocol (SIP)-Specific 1915 Event Notification", RFC 3265, June 2002. 1917 [RFC3262] Rosenberg, J. and H. Schulzrinne, "Reliability of 1918 Provisional Responses in Session Initiation Protocol (SIP)", 1919 RFC 3262, June 2002. 1921 [RFC5234] Crocker, D., Ed., and P. Overell, "Augmented BNF for Syntax 1922 Specifications: ABNF", STD 68, RFC 5234, January 2008. 1924 [IANA-civic] http://www.iana.org/assignments/civic-address-types- 1925 registry 1927 11.2 References - Informative 1929 [RFC3693] J. Cuellar, J. Morris, D. Mulligan, J. Peterson. J. Polk, 1930 "Geopriv Requirements", RFC 3693, February 2004 1932 [RFC3825] J. Polk, J. Schnizlein, M. Linsner, "Dynamic Host 1933 Configuration Protocol Option for Coordinate-based Location 1934 Configuration Information", RFC 3825, July 2004 1936 [RFC4776] H. Schulzrinne, " Dynamic Host Configuration Protocol 1937 (DHCPv4 and DHCPv6) Option for Civic Addresses Configuration 1938 Information ", RFC 4776, October 2006 1940 Author Information 1942 James Polk 1943 Cisco Systems 1944 3913 Treemont Circle 33.00111N 1945 Colleyville, Texas 76034 96.68142W 1947 Phone: +1-817-271-3552 1948 Email: jmpolk@cisco.com 1950 Brian Rosen 1951 NeuStar, Inc. 1952 470 Conrad Dr. 40.70497N 1953 Mars, PA 16046 80.01252W 1954 US 1956 Phone: +1 724 382 1051 1957 Email: br@brianrosen.net 1959 Appendix A. Requirements for SIP Location Conveyance 1961 The following subsections address the requirements placed on the 1962 UAC, the UAS, as well as SIP proxies when conveying location. There 1963 is a motivational statement below each requirements that is not 1964 obvious in intent 1966 A.1 Requirements for a UAC Conveying Location 1968 UAC-1 The SIP INVITE Method [RFC3261] must support location 1969 conveyance. 1971 UAC-2 The SIP MESSAGE method [RFC3428] must support location 1972 conveyance. 1974 UAC-3 SIP Requests within a dialog should support location 1975 conveyance. 1977 UAC-4 Other SIP Requests may support location conveyance. 1979 UAC-5 There must be one, mandatory to implement means of 1980 transmitting location confidentially. 1982 Motivation: interoperability 1984 UAC-6 It must be possible for a UAC to update location conveyed 1985 at any time in a dialog, including during dialog 1986 establishment. 1988 Motivation: in case a UAC has moved prior to the establishment of a 1989 dialog between UAs, the UAC must be able to send new location 1990 information. In the case of location having been conveyed, 1991 and the UA moves, it needs a means to update the conveyed to 1992 party of this location change. 1994 UAC-7 The privacy and security rules established within [RFC3693] 1995 that would categorize SIP as a 'Using Protocol' must be met. 1997 UAC-8 The PIDF-LO [RFC 4119] is a mandatory to implement format for 1998 location conveyance within SIP, whether included LbyV or 1999 LbyR. 2001 Motivation: interoperability with other IETF location protocols and 2002 mechanisms 2004 UAC-9 There must be a mechanism for the UAC to request the UAS send 2005 its location 2007 UAC-9 has been DEPRECATED by the SIP WG, due to the many 2008 problems this requirement would have caused if implemented. 2009 The solution is for the above UAS to send a new request to 2010 the original UAC with the UAS's location. 2012 UAC-10 There must be a mechanism to differentiate the ability of the 2013 UAC to convey location from the UACs lack of knowledge of its 2014 location 2016 Motivation: Failure to receive location when it is expected can be 2017 because the UAC does not implement this extension, or it can 2018 be that the UAC implements the extension, but does not know 2019 where it is. This may be, for example, due to the failure of 2020 the access network to provide a location acquisition 2021 mechanisms the UAC understands. These cases must be 2022 differentiated. 2024 UAC-11 It must be possible to convey location to proxy servers 2025 along the path. 2027 Motivation: Location-based routing. 2029 A.2 Requirements for a UAS Receiving Location 2031 The following are the requirements for location conveyance by a UAS: 2033 UAS-1 SIP Responses must support location conveyance. 2035 Just as with UAC-9, UAS-1 has been DEPRECATED by the SIP WG, 2036 due to the many problems this requirement would have caused 2037 if implemented. The solution is for the above UAS to send a 2038 new request to the original UAC with the UAS's location. 2040 UAS-2 There must be a unique 4XX response informing the UAC it did 2041 not provide applicable location information. 2043 In addition, requirements UAC-5, 6, 7 and 8 apply to the UAS 2045 A.3 Requirements for SIP Proxies and Intermediaries 2047 The following are the requirements for location conveyance by a SIP 2048 proxies and intermediaries: 2050 Proxy-1 Proxy servers must be capable of adding a Location header 2051 field during processing of SIP requests. 2053 Motivation: Provide the capability of network assertion of location 2054 when UACs are unable to do so, or when network assertion is 2055 more reliable than UAC assertion of location 2057 Note: Because UACs connected to sip signaling networks may have 2058 widely varying access network arrangements, including VPN 2059 tunnels and roaming mechanisms, it may be difficult for a 2060 network to reliably know the location of the endpoint. Proxy 2061 assertion of location is NOT RECOMMENDED unless the sip 2062 signaling network has reliable knowledge of the actual 2063 location of the Targets. 2065 Proxy-2 There must be a unique 4XX response informing the UAC it 2066 did not provide applicable location information. 2068 Appendix B. Example of INVITE with S/MIME encrypted Civic PIDF-LO 2070 This appendix gives an *EXAMPLE* (meaning this might contain errors 2071 based on future review) of a SIP INVITE request that points to the 2072 same position on the earth as the coordinate based example that's in 2073 section 5.1 in the body of this document: 2075 The INVITE request is TLS hop-by-hop encrypted, and the 2076 LbyV message body is S/MIME encrypted. This example 2077 shows the location message body in its unencrypted form for clarity. 2078 The message body lines below that have the '$' signs are S/MIME 2079 encrypted. In this example, the SDP is not S/MIME encrypted. 2081 INVITE sips:bob@biloxi.example.com SIP/2.0 2082 Via: SIP/2.0/TLS pc33.atlanta.example.com 2083 ;branch=z9hG4bK74bf9 2084 Max-Forwards: 70 2085 To: Bob 2086 From: Alice ;tag=9fxced76sl 2087 Call-ID: 3848276298220188511@atlanta.example.com 2088 Geolocation: 2089 ;inserted-by="alice@atlanta.example.com" 2090 Supported: geolocation 2091 Accept: application/sdp, application/pidf+xml 2092 CSeq: 31862 INVITE 2093 Contact: 2094 Content-Type: multipart/mixed; boundary=boundary1 2095 Content-Length: ... 2097 --boundary1 2099 Content-Type: application/sdp 2101 ...SDP goes here 2103 --boundary1 2105 Content-Type: application/pkcs7-mime; 2106 smime-type=enveloped-data; name=smime.p7m 2107 Content-ID: alice123@atlanta.example.com 2109 $ Content-Type: application/pidf+xml 2110 $ 2111 $ 2112 $ 2116 $ 2117 $ 2007-07-09T14:00:00Z 2118 $ 2119 $ 2120 $ 2121 $ 2122 $ US 2123 $ Texas 2124 $ Colleyville 2125 $ 3913 2126 $ Treemont 2127 $ Circle 2128 $ 76034 2129 $ Haley's Place 2130 $ 1 2131 $ 2132 $ 2133 $ 2134 $ no 2135 $ 2007-07-27T18:00:00Z 2137 $ 2138 $ DHCP 2139 $ www.example.com 2140 $ 2141 $ 2142 $ 2143 $ 2144 --boundary1-- 2146 Full Copyright Statement 2148 Copyright (C) The IETF Trust (2008). 2150 This document is subject to the rights, licenses and restrictions 2151 contained in BCP 78, and except as set forth therein, the authors 2152 retain all their rights. 2154 This document and the information contained herein are provided on 2155 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 2156 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE 2157 IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL 2158 WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY 2159 WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE 2160 ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS 2161 FOR A PARTICULAR PURPOSE. 2163 Intellectual Property 2165 The IETF takes no position regarding the validity or scope of any 2166 Intellectual Property Rights or other rights that might be claimed 2167 to pertain to the implementation or use of the technology described 2168 in this document or the extent to which any license under such 2169 rights might or might not be available; nor does it represent that 2170 it has made any independent effort to identify any such rights. 2171 Information on the procedures with respect to rights in RFC 2172 documents can be found in BCP 78 and BCP 79. 2174 Copies of IPR disclosures made to the IETF Secretariat and any 2175 assurances of licenses to be made available, or the result of an 2176 attempt made to obtain a general license or permission for the use 2177 of such proprietary rights by implementers or users of this 2178 specification can be obtained from the IETF on-line IPR repository 2179 at http://www.ietf.org/ipr. 2181 The IETF invites any interested party to bring to its attention any 2182 copyrights, patents or patent applications, or other proprietary 2183 rights that may cover technology that may be required to implement 2184 this standard. Please address the information to the IETF at 2185 ietf-ipr@ietf.org. 2187 Acknowledgment 2189 Funding for the RFC Editor function is provided by the IETF 2190 Administrative Support Activity (IASA).