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