idnits 2.17.1 draft-ietf-sipcore-location-conveyance-09.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == It seems as if not all pages are separated by form feeds - found 0 form feeds but 32 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 1294 has weird spacing: '...n-Error code...' == Unrecognized Status in 'Intended Status: Standards Track (PS)', assuming Proposed Standard (Expected one of 'Standards Track', 'Full Standard', 'Draft Standard', 'Proposed Standard', 'Best Current Practice', 'Informational', 'Experimental', 'Informational', 'Historic'.) == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (Sept 4, 2011) is 4892 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 3265 (Obsoleted by RFC 6665) ** Obsolete normative reference: RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) -- Obsolete informational reference (is this intentional?): RFC 2818 (Obsoleted by RFC 9110) Summary: 3 errors (**), 0 flaws (~~), 5 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group James Polk 3 Internet Draft Cisco Systems 4 Expires: Mar 4, 2012 Brian Rosen 5 Intended Status: Standards Track (PS) Jon Peterson 6 NeuStar 7 Sept 4, 2011 9 Location Conveyance for the Session Initiation Protocol 10 draft-ietf-sipcore-location-conveyance-09.txt 12 Abstract 14 This document defines an extension to the Session Initiation 15 Protocol (SIP) to convey geographic location information from one 16 SIP entity to another SIP entity. The SIP extension covers 17 end-to-end conveyance as well as location-based routing, where SIP 18 intermediaries make routing decisions based upon the location of the 19 Location Target. 21 Status of this Memo 23 This Internet-Draft is submitted to IETF in full conformance with 24 the provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF), its areas, and its working groups. Note that 28 other groups may also distribute working documents as Internet- 29 Drafts. 31 Internet-Drafts are draft documents valid for a maximum of six 32 months and may be updated, replaced, or obsoleted by other documents 33 at any time. It is inappropriate to use Internet-Drafts as 34 reference material or to cite them other than as "work in progress." 36 The list of current Internet-Drafts can be accessed at 37 http://www.ietf.org/ietf/1id-abstracts.txt. 39 The list of Internet-Draft Shadow Directories can be accessed at 40 http://www.ietf.org/shadow.html. 42 This Internet-Draft will expire on Mar 4, 2012. 44 Copyright Notice 46 Copyright (c) 2011 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with 54 respect to this document. Code Components extracted from this 55 document must include Simplified BSD License text as described in 56 Section 4.e of the Trust Legal Provisions and are provided without 57 warranty as described in the BSD License. 59 This document may contain material from IETF Documents or IETF 60 Contributions published or made publicly available before November 61 10, 2008. The person(s) controlling the copyright in some of this 62 material may not have granted the IETF Trust the right to allow 63 modifications of such material outside the IETF Standards Process. 64 Without obtaining an adequate license from the person(s) controlling 65 the copyright in such materials, this document may not be modified 66 outside the IETF Standards Process, and derivative works of it may 67 not be created outside the IETF Standards Process, except to format 68 it for publication as an RFC or to translate it into languages other 69 than English. 71 Table of Contents 73 1. Conventions and Terminology used in this document . . . . . . 3 74 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 75 3. Overview of SIP Location Conveyance . . . . . . . . . . . . . 4 76 3.1 Location Conveyed by Value . . . . . . . . . . . . . . . 4 77 3.2 Location Conveyed as a Location URI . . . . . . . . . . . 5 78 3.3 Location Conveyed though a SIP Intermediary . . . . . . . 5 79 3.4 SIP Intermediary Replacing Bad Location . . . . . . . . . 7 80 4. SIP Modifications for Geolocation Conveyance . . . . . . . . 8 81 4.1 The Geolocation Header Field . . . . . . . . . . . . . . 8 82 4.2 The Geolocation-Routing Header Field . . . . . . . . . . 10 83 4.2.1 Explaining Geolocation-Routing header-value States . . 11 84 4.3 424 (Bad Location Information) Response Code . . . . . . 13 85 4.4 The Geolocation-Error Header Field . . . . . . . . . . . 14 86 4.5 Location URIs in Message Bodies . . . . . . . . . . . . . 17 87 4.6 Location Profile Negotiation . . . . . . . . . . . . . . 17 88 5. Geolocation Examples . . . . . . . . . . . . . . . . . . . . 18 89 5.1 Location-by-value (Coordinate Format) . . . . . . . . . . 18 90 5.2 Two Locations Composed in Same Location Object Example . 20 91 6. Geopriv Privacy Considerations . . . . . . . . . . . . . . . 22 92 7. Security Considerations . . . . . . . . . . . . . . . . . . . 22 93 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . 24 94 8.1 IANA Registration for New SIP Geolocation Header Field . 24 95 8.2 IANA Registration for New SIP Geolocation-Routing Header 96 Field . . . . . . . . . . . . . . . . . . . . . . . . . . 24 97 8.3 IANA Registration for New SIP Option Tags . . . . . . . . 25 98 8.4 IANA Registration for New 424 Response Code . . . . . . . 25 99 8.5 IANA Registration for New SIP Geolocation-Error Header 100 Field . . . . . . . . . . . . . . . . . . . . . . . . . . 26 101 8.6 IANA Registration for New SIP Geolocation-Error Codes . . 26 102 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 27 103 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 27 104 10.1 Normative References . . . . . . . . . . . . . . . . . 27 105 10.2 Informative References . . . . . . . . . . . . . . . . . 28 106 Author Information . . . . . . . . . . . . . . . . . . . . . 29 107 Appendix A. Requirements for SIP Location Conveyance . . . . 29 109 1. Conventions and Terminology used in this document 111 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 112 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and 113 "OPTIONAL" in this document are to be interpreted as described 114 in [RFC2119]. This document furthermore uses numerous terms defined 115 in RFC 3693 [RFC3693], including Location Object, Location 116 Recipient, Location Server, Target, Rulemaker and Using Protocol. 118 2. Introduction 120 Session Initiation Protocol (SIP) [RFC3261] creates, modifies and 121 terminates multimedia sessions. SIP carries certain information 122 related to a session while establishing or maintaining calls. This 123 document defines how SIP conveys geographic location information of 124 a Target to a Location Recipient (LR). SIP acts as a Using Protocol 125 of location information, as defined in RFC 3693. 127 In order to convey location information, this document specifies 128 three new SIP header fields, Geolocation, Geolocation-Routing and 129 Geolocation-Error, which carry a reference to a Location Object 130 (LO), grant permission to route a SIP request based on the 131 location-value and provide error notifications specific to location 132 errors respectively. The Location Object (LO) may appear in a MIME 133 body attached to the SIP request, or it may be a remote resource in 134 the network. 136 A Target is an entity whose location is being conveyed, per RFC 137 3693. Thus, a Target could be a SIP user agent (UA), some other IP 138 device (a router or a PC) that does not have a SIP stack, a non-IP 139 device (a person or a black phone) or even a non-communications 140 device (a building or store front). In no way does this document 141 assume that the SIP user agent client which sends a request 142 containing a location object is necessarily the Target. The location 143 of a Target conveyed within SIP typically corresponds to that of a 144 device controlled by the Target, for example, a mobile phone, but 145 such devices can be separated from their owners, and moreover, in 146 some cases the user agent may not know its own location. 148 In the SIP context, a location recipient will most likely be a SIP 149 UA, but due to the mediated nature of SIP architectures, location 150 information conveyed by a single SIP request may have multiple 151 recipients, as any SIP proxy server in the signaling path that 152 inspects the location of the Target must also be considered a 153 Location Recipient. In presence-like architectures, an intermediary 154 that receives publications of location information and distributes 155 them to watchers acts as a Location Server per RFC 3693. This 156 location conveyance mechanism can also be used to deliver URIs 157 pointing to such Location Servers where prospective Location 158 Recipients can request Location Objects. 160 3. Overview of SIP Location Conveyance 162 An operational overview of SIP location conveyance can be shown in 4 163 basic diagrams, with most applications falling under one of the 164 following basic use cases. Each is separated into its own subsection 165 here in section 3. 167 Each diagram has Alice and Bob as UAs. Alice is the Target, and Bob 168 is an LR. A SIP intermediary appears in some of the diagrams. Any 169 SIP entity that receives and inspects location information is an LR, 170 therefore in any of the diagrams the SIP intermediary that receives 171 a SIP request is potentially an LR - though that does not mean such 172 an intermediary necessarily has to route the SIP request based on 173 the location information. In some use cases, location information 174 passes through the LS on the right of each diagram. 176 3.1 Location Conveyed by Value 178 We start with the simplest diagram of Location Conveyance, Alice to 179 Bob, where no other layer 7 entities are involved. 181 Alice SIP Intermediary Bob LS 182 | | | | 183 | Request w/Location | | 184 |----------------------------------->| | 185 | | | 186 | Response | | 187 |<-----------------------------------| | 188 | | | | 190 Figure 1. Location Conveyed by Value 192 In Figure 1, Alice is both the Target and the LS that is conveying 193 her location directly to Bob, who acts as an LR. This conveyance is 194 point-to-point - it does not pass through any SIP-layer 195 intermediary. A Location Object appears by-value in the initial SIP 196 request as a MIME body, and Bob responds to that SIP request as 197 appropriate. There is a 'Bad Location Information' response code 198 introduced within this document to specifically inform Alice if she 199 conveys bad location to Bob (e.g., Bob "cannot parse the location 200 provided", or "there is not enough location information to determine 201 where Alice is"). 203 3.2 Location Conveyed as a Location URI 205 Here we make Figure 1 a little more complicated by showing a 206 diagram of indirect Location Conveyance from Alice to Bob, where 207 Bob's entity has to retrieve the location object from a 3rd party 208 server. 210 Alice SIP Intermediary Bob LS 211 | | | | 212 | Request w/Location URI | | 213 |----------------------------------->| | 214 | | Dereference | 215 | | Request | 216 | (To: Location URI) | 217 | |---------------->| 218 | | | 219 | | Dereference | 220 | | Response | 221 | (includes location) | 222 | |<----------------| 223 | Response | | 224 |<-----------------------------------| | 225 | | | | 227 Figure 2. Location Conveyed as a Location URI 229 In Figure 2, location is conveyed indirectly, via a Location URI 230 carried in the SIP request (more of those details later). If Alice 231 sends Bob this Location URI, Bob will need to dereference the URI - 232 analogous to Content Indirection [RFC4483] - in order to request the 233 location information. In general, the LS provides the location value 234 to Bob instead of Alice directly for conveyance to Bob. From a user 235 interface perspective, Bob the user won't know that this information 236 was gathered from an LS indirectly rather than culled from the SIP 237 request, and practically this does not impact the operation of 238 location-based applications. 240 The example given in this section is only illustrative, not 241 normative. In particular, applications can choose to dereference a 242 location URI at any time, possibly several times, or potentially not 243 at all. Applications receiving a Location URI in a SIP transaction 244 need to be mindful of timers used by different transactions. In 245 particular, if the means of dereferencing the Location URI might 246 take longer than the SIP transaction timeout (Timer C for INVITE 247 transactions, Timer F for non-INVITE transactions), then it needs to 248 rely on mechanisms other than the transaction's response code to 249 convey location errors, if returning such errors are necessary. 251 3.3 Location Conveyed though a SIP Intermediary 252 In Figure 3, we introduce the idea of a SIP intermediary into the 253 example to illustrate the role of proxying in the location 254 architecture. This intermediary can be a SIP proxy or it can be 255 a back-to-back-user-agent (B2BUA). In this message flow, the SIP 256 intermediary could act as a LR, in addition to Bob. The primary use 257 case for intermediaries consuming location information is 258 location-based routing. In this case, the intermediary chooses a 259 next hop for the SIP request by consulting a specialized location 260 service which selects forwarding destinations based on geographical 261 location. 263 Alice SIP Intermediary Bob LS 264 | | | | 265 | Request | | | 266 | w/Location | | | 267 |--------------->| | | 268 | | Request | | 269 | | w/Location | | 270 | |------------------>| | 271 | | | | 272 | | Response | | 273 | |<------------------| | 274 | Response | | | 275 |<---------------| | | 276 | | | | 278 Figure 3. Location Conveyed though a SIP Intermediary 280 However, the most common case will be one in which the SIP 281 intermediary receives a request with location information (conveyed 282 either by-value or by-reference) and does not know or care about 283 Alice's location, or support this extension, and merely passes it on 284 to Bob. In this case, the intermediary does not act as a Location 285 Recipient. When the intermediary is not an LR, this use case is the 286 same as the one described in Section 3.1. 288 Note that an intermediary does not have to perform location-based 289 routing in order to be a Location Recipient. It could be the case 290 that a SIP intermediary which does not perform location-based 291 routing does care when Alice includes her location; for example, 292 it could care that the location information is complete or that it 293 correctly identifies where Alice is. The best example of this is 294 intermediaries that verify location information for emergency 295 calling, but it could also be for any location based routing - e.g., 296 contacting your favorite local pizza delivery service, making sure 297 that organization has Alice's proper location in the initial SIP 298 request. 300 There is another scenario in which the SIP intermediary cares about 301 location and is not an LR, one in which the intermediary inserts 302 another location of the Target, Alice in this case, into the 303 request, and forwards it. This secondary insertion is generally not 304 advisable because downstream SIP entities will not be given any 305 guidance about which location to believe is better, more reliable, 306 less prone to error, more granular, worse than the other location or 307 just plain wrong. 309 This document takes a "you break it, you bought it" approach to 310 dealing with second locations placed into a SIP request by an 311 intermediary entity. That entity becomes completely responsible for 312 all location within that SIP request (more on this in Section 4). 314 3.4 SIP Intermediary Replacing Bad Location 316 If the SIP intermediary rejects the message due to unsuitable 317 location information, the SIP response will indicate there was 'Bad 318 Location Information' in the SIP request, and provide a location 319 specific error code indicating what Alice needs to do to send an 320 acceptable request (see Figure 4 for this scenario). 322 Alice SIP Intermediary Bob LS 323 | | | | 324 | Request | | | 325 | w/Location | | | 326 |--------------->| | | 327 | | | | 328 | Rejected | | | 329 | w/New Location | | | 330 |<---------------| | | 331 | | | | 332 | Request | | | 333 | w/New Location | | | 334 |--------------->| | | 335 | | Request | | 336 | | w/New Location | | 337 | |------------------>| | 338 | | | | 340 Figure 4. SIP Intermediary Replacing Bad Location 342 In this last use case, the SIP intermediary wishes to include a 343 Location Object indicating where it understands Alice to be. Thus, 344 it needs to inform her user agent what location it will include in 345 any subsequent SIP request that contains her location. In this 346 case, the intermediary can reject Alice's request and, through the 347 SIP response, convey to her the best way to repair the request in 348 order for the intermediary to accept it. 350 Overriding location information provided by the user requires a 351 deployment where an intermediary necessarily knows better than an 352 end user - after all, it could be that Alice has an on-board GPS, 353 and the SIP intermediary only knows her nearest cell tower. Which is 354 more accurate location information? Currently, there is no way to 355 tell which entity is more accurate, or which is wrong - for that 356 matter. This document will not specify how to indicate which 357 location is more accurate than another. 359 As an aside, it is not envisioned that any SIP-based emergency 360 services request (i.e., IP-911, or 112 type of call attempt) will 361 receive a corrective 'Bad Location Information' response from an 362 intermediary. Most likely, the SIP intermediary would in that 363 scenario act as a B2BUA and insert into the request by-value any 364 appropriate location information for the benefit of Public Safety 365 Answering Point (PSAP) call centers to expedite call reception by 366 the emergency services personnel; thereby, minimizing any delay in 367 call establishment time. The implementation of these specialized 368 deployments is, however, outside the scope of this document. 370 4. SIP Extensions for Geolocation Conveyance 372 The following sections detail the extensions to SIP for location 373 conveyance. 375 4.1 The Geolocation Header Field 377 This document defines "Geolocation" as a new SIP header field 378 registered by IANA, with the following ABNF [RFC5234]: 380 message-header /= Geolocation-header ; (message-header from 3261) 381 Geolocation-header = "Geolocation" HCOLON locationValue 382 *( COMMA locationValue ) 383 locationValue = LAQUOT locationURI RAQUOT 384 *(SEMI geoloc-param) 385 locationURI = sip-URI / sips-URI / pres-URI 386 / http-URI / https-URI 387 / cid-url ; (from RFC 2392) 388 / absoluteURI ; (from RFC 3261) 389 geoloc-param = generic-param; (from RFC 3261) 391 HCOLON, COMMA, LAQUOT, RAQUOT, and SEMI are defined in RFC3261 392 [RFC3261]. 394 sip-URI, sips-URI and absoluteURI are defined according to [RFC3261]. 396 The pres-URI is defined in [RFC3859]. 398 http-URI and https-URI are defined according to [RFC2616] and 399 [RFC2818], respectively. 401 The cid-url is defined in [RFC2392] to locate message body parts. 402 This URI type is present in a SIP request when location is conveyed 403 as a MIME body in the SIP message. 405 GEO-URIs [RFC5870] are not appropriate for usage in the SIP 406 Geolocation header, because it does not include retention and 407 re-transmission flags as part of the location information. Other URI 408 schemes used in the location URI MUST be reviewed against the RFC 409 3693 [RFC3693] criteria for a Using Protocol. Section 4.6 discusses 410 how URI schemes are communicated using this SIP extension, and what 411 to do if a URI scheme is received that cannot be supported. 413 The generic-param in the definition of locationValue is included as 414 a mechanism for future extensions that might require parameters. 415 This document defines no parameters for use with locationValue. If a 416 Geolocation header field is received that contains generic-params, 417 each parameter SHOULD be ignored, and SHOULD NOT be removed when 418 forwarding the locationValue. If a need arises to define parameters 419 for use with locationValue, a revision/extension to this document is 420 required. 422 The Geolocation header field MUST have at least one locationValue. 423 A SIP intermediary SHOULD NOT add location to a SIP request that 424 already contains location. This will quite often lead to confusion 425 within LRs. However, if a SIP intermediary adds location, even if 426 location was not previously present in a SIP request, that SIP 427 intermediary is fully responsible for addressing the concerns of any 428 424 (Bad Location Information) SIP response it receives about this 429 location addition, and MUST NOT pass on (upstream) the 424 response. 430 A SIP intermediary that adds a locationValue MUST position the new 431 locationValue as the last locationValue within the Geolocation 432 header field of the SIP request. 434 This document defines the Geolocation header field as valid in the 435 following SIP requests: 437 INVITE [RFC3261], REGISTER [RFC3261], 438 OPTIONS [RFC3261], BYE [RFC3261], 439 UPDATE [RFC3311], INFO [RFC6086], 440 MESSAGE [RFC3428], REFER [RFC3515], 441 SUBSCRIBE [RFC3265], NOTIFY [RFC3265], 442 PUBLISH [RFC3903] 444 The Geolocation header field MAY be included in any one of the 445 above listed requests by a UA, and a 424 response to any one of the 446 requests sent above. Fully appreciating the caveats/warnings 447 mentioned above, a SIP intermediary MAY add the Geolocation header 448 field. 450 A SIP intermediary MAY add a Geolocation header field if one is not 451 present - for example, when a user agent does not support the 452 Geolocation mechanism but their outbound proxy does and knows the 453 Target's location, or any of a number of other use cases (see 454 Section 3). 456 The Geolocation header field MAY be present in a SIP request or 457 response without the presence of a Geolocation-Routing header 458 (defined in Section 4.2). As stated in Section 4.2, the default 459 value of Geolocation-Routing header-value is "no", meaning SIP 460 intermediaries MUST NOT view (i.e., process, inspect or actively 461 dereference) any direct or indirect location within this SIP 462 message. This is for at least two fundamental reasons, 464 1) to make the possibility of retention of the Target's location 465 moot (because it was not viewed in the first place); and 467 2) to prevent a different treatment of this SIP request based on 468 the contents of the Location Information in the SIP request. 470 Any locationValue MUST be related to the original Target. This is 471 equally true for the location information in a SIP response, i.e., 472 from a SIP intermediary back to the Target as explained in Section 473 3.4. SIP intermediaries SHOULD NOT modify or delete any existing 474 locationValue(s). A use-case in which this would not apply would be 475 where the SIP intermediary is an anonymizer. The problem with this 476 scenario is that the geolocation included by the Target then becomes 477 useless for the purpose or service they wanted to use (include) it 478 for. For example, 911/emergency calling or finding the nearest 479 (towing company/pizza delivery/dry cleaning) service(s) will not 480 yield intended results if the Location Information were to be 481 modified or deleted from the SIP request. 483 4.2 The Geolocation-Routing Header Field 485 This document defines "Geolocation-Routing" as a new SIP header 486 field registered by IANA, with the following ABNF [RFC5234]: 488 message-header /= Georouting-header ; (message-header from 3261) 489 Georouting-header = "Geolocation-Routing" HCOLON 490 ( "yes" / "no" / generic-value ) 491 generic-value = generic-param; (from RFC 3261) 493 HCOLON is defined in RFC3261 [RFC3261]. 495 The only defined values for the Geolocation-Routing header field are 496 "yes" or "no". When the value is "yes", the locationValue can be 497 used for routing decisions along the downstream signaling path by 498 intermediaries. Values other than "yes" or "no" are permitted for 499 future extensions. Implementations not aware of an extension MUST 500 treat any other received value the same as "no". 502 If no Geolocation-Routing header field is present in a SIP request, 503 a SIP intermediary MAY insert this header. Without knowledge from a 504 Rulemaker, the SIP intermediary inserting this header-value SHOULD 505 NOT set the value to "yes", as this may be more permissive than the 506 originating party intends. An easy way around this is to have the 507 Target always insert this header-value as "no". 509 When this Geolocation-Routing header-value is set to "no", this 510 means no locationValue (inserted by the originating UAC or any 511 intermediary along the signaling path) can be used by any SIP 512 intermediary to make routing decisions. Intermediaries that attempt 513 to use the location information for routing purposes in spite of 514 this counter indication could end up routing the request improperly 515 as a result. Section 4.4 describes the details on what a routing 516 intermediary does if it determines it needs to use the location in 517 the SIP request in order to process the message further. The 518 practical implication is that when the Geolocation-Routing 519 header-value is set to "no", if a cid:url is present in the SIP 520 request, intermediaries MUST NOT view the location (because it is 521 not for intermediaries to consider when processing the request), and 522 if a location URI is present, intermediaries MUST NOT dereference 523 it. UAs are allowed to view location in the SIP request even when 524 the Geolocation-Routing header-value is set to "no". An LR MUST by 525 default consider the Geolocation-Routing header-value as set to 526 "no", with no exceptions, unless the header field value is set to 527 "yes". 529 A Geolocation-Routing header-value that is set to "no" has no 530 special security properties. It is at most a request for behavior 531 within SIP intermediaries. That said, if the Geolocation-Routing 532 header-value is set to "no", SIP intermediaries are still to process 533 the SIP request and send it further downstream within the signaling 534 path if there are no errors present in this SIP request. 536 The Geolocation-Routing header field satisfies the recommendations 537 made in section 3.5 of RFC 5606 [RFC5606] regarding indication of 538 permission to use location-based routing in SIP. 540 SIP implementations are advised to pay special attention to the 541 policy elements for location retransmission and retention described 542 in RFC 4119. 544 The Geolocation-Routing header field cannot appear without a 545 header-value in a SIP request or response (i.e., a null value is not 546 allowed). The absence of a Geolocation-Routing header-value in a SIP 547 request is always the same as the following header field: 549 Geolocation-Routing: no 551 The Geolocation-Routing header field MAY be present without a 552 Geolocation header field in the same SIP request. This concept is 553 further explored in Section 4.2.1. 555 4.2.1 Explaining Geolocation-Routing header-value States 557 The Geolocation header field contains a Target's location, and MUST 558 NOT be present if there is no location information in this SIP 559 request. The location information is contained in one or more 560 locationValues. These locationValues MAY be contained in a single 561 Geolocation header field, or distributed among multiple Geolocation 562 header fields. (See section 7.3.1 of RFC3261.) 564 The Geolocation-Routing header field indicates whether or not SIP 565 intermediaries can view and then route this SIP request based on the 566 included (directly or indirectly) location information. The 567 Geolocation-Routing header field MUST NOT appear more than once in 568 any SIP request, and MUST NOT lack a header-value. The default or 569 implied policy of a SIP request that does not have a 570 Geolocation-Routing header field is the same as if one were present 571 and the header-value were set to "no". 573 There are only 3 possible states regarding the Geolocation-Routing 574 header field 576 - "no" 577 - "yes" 578 - no header-field present in this SIP request 580 The expected results in each state are: 582 If the Geolocation-Routing Only possible interpretations: 583 -------------------------- ----------------------------- 584 "no" SIP intermediaries MUST NOT process 585 included geolocation information 586 within this SIP request. 588 SIP intermediaries inserting a 589 locationValue into a Geolocation 590 header field (whether adding to an 591 existing header-value or inserting the 592 Geolocation header field for the first 593 time) MUST NOT modify or delete the 594 received "no" header-value. 596 "yes" SIP intermediaries can process 597 included geolocation information 598 within this SIP request, and can 599 change the policy to "no" for 600 intermediaries further downstream. 602 Geolocation-Routing absent If a Geolocation header field exists 603 (meaning a locationValue is already 604 present), a SIP intermediary MUST 605 interpret the lack of a 606 Geolocation-Routing header field as if 607 there were one present and the 608 header-value is set to "no". 610 If there is no Geolocation header 611 field in this SIP request, the default 612 Geolocation-Routing is open and can be 613 set by a SIP intermediary or not at 614 all. 616 4.3 424 (Bad Location Information) Response Code 618 This SIP extension creates a new location-specific response code, 619 defined as follows, 621 424 (Bad Location Information) 623 The 424 (Bad Location Information) response code is a rejection of 624 the request due to its location contents, indicating location 625 information that was malformed or not satisfactory for the 626 recipient's purpose, or could not be dereferenced. 628 A SIP intermediary can also reject a location it receives from a 629 Target when it understands the Target to be in a different location. 630 The proper handling of this scenario, described in Section 3.4, is 631 for the SIP intermediary to include the proper location in the 424 632 Response. This SHOULD be included in the response as a MIME message 633 body (i.e., a location value), rather than as a URI; however, in 634 cases where the intermediary is willing to share location with 635 recipients but not with a user agent, a reference might be 636 necessary. 638 As mentioned in Section 3.4, it might be the case that the 639 intermediary does not want to chance providing less accurate 640 location information than the user agent; thus it will compose its 641 understanding of where the user agent is in a separate 642 element of the same PIDF-LO [RFC4119] message body in the SIP 643 response (which also contains the Target's version of where it is). 644 Therefore, both locations are included - each with different 645 elements. The proper reaction of the user agent is to 646 generate a new SIP request that includes this composed location 647 object, and send it towards the original LR. SIP intermediaries can 648 verify that subsequent requests properly insert the suggested 649 location information before forwarding said requests. 651 SIP intermediaries that are forwarding (as opposed to generating) a 652 424 response MUST NOT add, modify, or delete any location appearing 653 in that response. This specifically applies to intermediaries that 654 are between the 424 response generator and the original UAC. 655 Geolocation and Geolocation-Error header fields and PIDF-LO body 656 parts MUST remain unchanged, never added to or deleted. 658 Section 4.4 describes a Geolocation-Error header field to provide 659 more detail about what was wrong with the location information in 660 the request. This header field MUST be included in the 424 response. 662 It is only appropriate to generate a 424 response when the 663 responding entity needs a locationValue and there are no values in 664 the request that are usable by the responder, or when the responder 665 has additional location information to provide. The latter case is 666 shown in Figure 4 of section 3.4. There, a SIP intermediary is 667 informing the upstream UA which location to include in the next SIP 668 request. 670 A 424 MUST NOT be sent in response to a request that lacks a 671 Geolocation header entirely, as the user agent in that case may not 672 support this extension at all. If a SIP intermediary inserted a 673 locationValue into a SIP request where one was not previously 674 present, it MUST take any and all responsibility for the corrective 675 action if it receives a 424 to a SIP request it sent. 677 A 424 (Bad Location Information) response is a final response within 678 a transaction, and MUST NOT terminate an existing dialog. 680 4.4 The Geolocation-Error Header Field 682 As discussed in Section 4.3, more granular error notifications 683 specific to location errors within a received request are required 684 if the location inserting entity is to know what was wrong within 685 the original request. The Geolocation-Error header field is used for 686 this purpose. 688 The Geolocation-Error header field is used to convey 689 location-specific errors within a response. The Geolocation-Error 690 header field has the following ABNF [RFC5234]: 692 message-header /= Geolocation-Error 693 ; (message-header from 3261) 694 Geolocation-Error = "Geolocation-Error" HCOLON 695 locationErrorValue 696 locationErrorValue = location-error-code 697 *(SEMI location-error-params) 698 location-error-code = 1*3DIGIT 699 location-error-params = location-error-code-text 700 / generic-param ; from RFC3261 701 location-error-code-text = "code" EQUAL quoted-string ; from RFC3261 703 HCOLON, SEMI, and EQUAL are defined in RFC3261 [RFC3261]. DIGIT is 704 defined in RFC5234 [RFC5234]. 706 The Geolocation-Error header field MUST contain only one 707 locationErrorValue to indicate what was wrong with the locationValue 708 the Location Recipient determined was bad. The locationErrorValue 709 contains a 3-digit error code indicating what was wrong with the 710 location in the request. This error code has a corresponding quoted 711 error text string that is human understandable. The text string is 712 OPTIONAL, but RECOMMENDED for human readability, similar to the 713 string phrase used for SIP response codes. That said, the strings 714 are complete enough for rendering to the user, if so desired. The 715 strings in this document are recommendations, and are not 716 standardized - meaning an operator can change the strings - but MUST 717 NOT change the meaning of the error code. Similar to how RFC 3261 718 specifies, there MUST NOT be more than one string per error code. 720 The Geolocation-Error header field MAY be included in any response 721 to one of the SIP Methods mentioned in Section 4.1, so long as a 722 locationValue was in the request part of the same transaction. For 723 example, Alice includes her location in an INVITE to Bob. Bob can 724 accept this INVITE, thus creating a dialog, even though his UA 725 determined the location contained in the INVITE was bad. Bob merely 726 includes a Geolocation-Error header value in the 200 OK to the 727 INVITE informing Alice the INVITE was accepted but the location 728 provided was bad. 730 If, on the other hand, Bob cannot accept Alice's INVITE without a 731 suitable location, a 424 (Bad Location Information) is sent. This 732 message flow is shown in Figures 1, 2 or 3 in Sections 3.1, 3.2 and 733 3.3 respectively. 735 If Alice is deliberately leaving location information out of the LO 736 because she does not want Bob to have this additional information, 737 implementations should be aware that Bob could error repeatedly in 738 order to receive more location information about Alice in a 739 subsequent SIP request. Implementations MUST be on guard for this, 740 by not allowing continually more information to be revealed unless 741 it is clear that any LR is permitted by Alice to know all that Alice 742 knows about her location. A limit on the number of such rejections 743 to learn more location information SHOULD be configurable, with a 744 RECOMMENDED maximum of 3 times for each related transaction. 746 A SIP intermediary that requires Alice's location in order to 747 properly process Alice's INVITE also sends a 424 with a 748 Geolocation-Error code. This message flow is shown in Figure 4 of 749 Section 3.4. 751 If more than one locationValue is present in a SIP request and at 752 least one locationValue is determined to be valid by the LR, the 753 location in that SIP request MUST be considered good as far as 754 location is concerned, and no Geolocation-Error is to be sent. 756 Here is an initial list of location based error code ranges for any 757 SIP response, including provisional responses (other than 100 758 Trying) and the new 424 (Bad Location Information) response. These 759 error codes are divided into 3 categories, based on how the response 760 receiver should react to these errors. There MUST be no more than 761 one Geolocation-Error code in a SIP response, regardless of how many 762 locationValues there are in the correlating SIP request. There is no 763 guidance given in this document as to which locationValue, when more 764 than one was present in the SIP request, is related to the 765 Geolocation-Error code; meaning that, somehow not defined here, the 766 LR just picks one to error. 768 o 1XX errors mean the LR cannot process the location within the 769 request 771 A non-exclusive list of reasons for returning a 1XX is 773 - the location was not present or could not be found, 774 - there was not enough location information to determine 775 where the Target was, 776 - the location information was corrupted or known to be 777 inaccurate, 779 o 2XX errors mean some specific permission is necessary to process 780 the included location information. 782 o 3XX errors mean there was trouble dereferencing the Location URI 783 sent. 785 Dereference attempts to the same request SHOULD be limited to 10 786 attempts within a few minutes. This number SHOULD be configurable, 787 but result in a Geolocation-Error: 300 error once reached. 789 It should be noted that for non-INVITE transactions, the SIP 790 response will likely be sent before the dereference response has 791 been received. This document does not alter that SIP protocol 792 reality. This means the receiver of any non-INVITE response to a 793 request containing location SHOULD NOT consider a 200 OK to mean the 794 act of dereferencing has concluded and the dereferencer (i.e., the 795 LR) has successfully received and parsed the PIDF-LO for errors and 796 found none. The end of section 3.2 discusses how transaction timing 797 considerations lead to this requirement. 799 Additionally, if an LR cannot or chooses not to process location 800 from a SIP request, a 500 (Server Internal Error) SHOULD be used 801 with or without a configurable Retry-After header field. There is no 802 special location error code for what already exists within SIP 803 today. 805 Within each of these ranges, there is a top level error as follows: 807 Geolocation-Error: 100 ; code="Cannot Process Location" 809 Geolocation-Error: 200 ; code="Permission To Use Location 810 Information" 812 Geolocation-Error: 300 ; code="Dereference Failure" 813 If an error recipient cannot process a specific error code (such as 814 the 201 or 202 below), perhaps because it does not understand that 815 specific error code, the error recipient SHOULD process the error 816 code as if it originally were a top level error code where the X in 817 X00 matches the specific error code. If the error recipient cannot 818 process a non-100 error code, for whatever reason, then the error 819 code 100 MUST be processed. 821 There are two specific Geolocation-Error codes necessary to include 822 in this document, both have to do with permissions necessary to 823 process the SIP request; they are 825 Geolocation-Error: 201 ; code="Permission To Retransmit Location 826 Information to a Third Party" 828 This location error is specific to having the Presence Information 829 Data Format (PIDF-LO) [RFC4119] element set 830 to "no". This location error is stating it requires permission 831 (i.e., PIDF-LO element set to "yes") to 832 process this SIP request further. If the LS sending the location 833 information does not want to give this permission, it will not 834 change this permission in a new request. If the LS wants this 835 message processed with the element set to 836 "yes" it MUST choose another logical path (if one exists) for this 837 SIP request. 839 Geolocation-Error: 202 ; code="Permission to Route based on Location 840 Information" 842 This location error is specific to having the Geolocation-Routing 843 header value set to "no". This location error is stating it requires 844 permission (i.e., the Geolocation-Routing header value set to "yes") 845 to process this SIP request further. If the LS sending the location 846 information does not want to give this permission, it will not 847 change this permission in a new request. If the LS wants this 848 message processed with the element set to 849 "yes" it MUST choose another logical path (if one exists) for this 850 SIP request. 852 4.5 Location URIs in Message Bodies 854 In the case where an LR sends a 424 response and wishes to 855 communicate suitable location by reference rather than by value, the 856 424 MUST include a content-indirection body per RFC 4483. 858 4.6 Location Profile Negotiation 860 The following is part of the discussion started in Section 3, Figure 861 2, which introduced the concept of sending location indirectly. 863 If a location URI is included in a SIP request, the sending user 864 agent MUST also include a Supported header field indicating which 865 location profiles it supports. Two option tags for location profiles 866 are defined by this document: "geolocation-sip" and 867 "geolocation-http". Future specifications MAY define further 868 location profiles per the IANA policy described in Section 8.3. 870 The "geolocation-sip" option tag signals support for acquiring 871 location information via the presence event package of SIP 872 ([RFC3856]). A location recipient who supports this option can send 873 a SUBSCRIBE request and parse a resulting NOTIFY containing a 874 PIDF-LO object. The URI schemes supported by this option include 875 "sip", "sips" and "pres". 877 The "geolocation-http" option tag signals support for acquiring 878 location information via an HTTP ([RFC2616]). A location recipient 879 who supports this option can request location with an HTTP GET and 880 parse a resulting 200 response containing a PIDF-LO object. The URI 881 schemes supported by this option include "http" and "https". A 882 failure to parse the 200 response, for whatever reason, will return 883 a "Dereference Failure" indication to the original location sending 884 user agent to inform it that location was not delivered as intended. 886 If the location URI receiver does not understand the URI scheme sent 887 to it, it will return an Unsupported header value of the option-tag 888 from the SIP request, and include the option-tag of the preferred 889 URI scheme in the response's Supported header field. 891 See [ID-GEO-FILTERS] or [ID-HELD-DEREF] for more details on 892 dereferencing location information. 894 5. Geolocation Examples 896 5.1 Location-by-value (in Coordinate Format) 898 This example shows an INVITE message with a coordinate location. In 899 this example, the SIP request uses a sips-URI [RFC3261], meaning 900 this message is protected using TLS on a hop-by-hop basis. 902 INVITE sips:bob@biloxi.example.com SIP/2.0 903 Via: SIPS/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bK74bf9 904 Max-Forwards: 70 905 To: Bob 906 From: Alice ;tag=9fxced76sl 907 Call-ID: 3848276298220188511@atlanta.example.com 908 Geolocation: 909 Geolocation-Routing: no 910 Accept: application/sdp, application/pidf+xml 911 CSeq: 31862 INVITE 912 Contact: 913 Content-Type: multipart/mixed; boundary=boundary1 914 Content-Length: ... 916 --boundary1 918 Content-Type: application/sdp 920 ...SDP goes here 922 --boundary1 924 Content-Type: application/pidf+xml 925 Content-ID: 926 927 935 936 937 938 939 940 32.86726 -97.16054 941 942 943 944 945 false 946 947 2010-11-14T20:00:00Z 948 949 950 802.11 951 952 mac:1234567890ab 953 2010-11-04T20:57:29Z 954 955 956 --boundary1-- 958 The Geolocation header field from the above INVITE: 960 Geolocation: 962 ... indicates the content-ID location [RFC2392] within the multipart 963 message body of where location information is. The other message 964 body part is SDP. The "cid:" eases message body parsing and 965 disambiguates multiple parts of the same type. 967 If the Geolocation header field did not contain a "cid:" scheme, for 968 example, it could look like this location URI: 970 Geolocation: 972 ... the existence of a non-"cid:" scheme indicates this is a 973 location URI, to be dereferenced to learn the Target's location. Any 974 node wanting to know where the target is located would subscribe to 975 the SIP presence event package [RFC3856] at 977 sips:target123@server5.atlanta.example.com 979 (see Figure 2 in Section 3.2 for this message flow). 981 5.2 Two Locations Composed in Same Location Object Example 983 This example shows the INVITE message after a SIP intermediary 984 rejected the original INVITE (say, the one in section 5.1). This 985 INVITE contains the composed LO sent by the SIP intermediary which 986 includes where the intermediary understands Alice to be. The rules 987 of RFC 5491 [RFC5491] are followed in this construction. 989 This example is here, but ought not be taken as occurring very 990 often. In fact, this example is believed to be a corner case of 991 location conveyance applicability. 993 INVITE sips:bob@biloxi.example.com SIP/2.0 994 Via: SIPS/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bK74bf0 995 Max-Forwards: 70 996 To: Bob 997 From: Alice ;tag=9fxced76sl 998 Call-ID: 3848276298220188512@atlanta.example.com 999 Geolocation: 1000 Geolocation-Routing: no 1001 Accept: application/sdp, application/pidf+xml 1002 CSeq: 31863 INVITE 1003 Contact: 1004 Content-Type: multipart/mixed; boundary=boundary1 1005 Content-Length: ... 1007 --boundary1 1009 Content-Type: application/sdp 1011 ...SDP goes here 1013 --boundary1 1015 Content-Type: application/pidf+xml 1016 Content-ID: 1017 1018 1026 1027 1028 1029 1030 1031 32.86726 -97.16054 1032 1033 1034 1035 1036 false 1037 1038 2010-11-14T20:00:00Z 1039 1040 1041 802.11 1042 1043 mac:1234567890ab 1044 2010-11-04T20:57:29Z 1045 1046 1047 1048 1049 1050 US 1051 Texas 1052 Colleyville 1053 Treemont 1054 Circle 1055 3913 1056 1 1057 Haley's Place 1058 76034 1059 1060 1061 1062 false 1063 1064 2010-11-14T20:00:00Z 1065 1066 1067 triangulation 1068 1069 2010-11-04T12:28:04Z 1070 1071 1072 --boundary1-- 1074 6. Geopriv Privacy Considerations 1076 Location information is considered by most to be highly sensitive 1077 information, requiring protection from eavesdropping and altering in 1078 transit. [RFC3693] originally articulated rules to be followed by 1079 any protocol wishing to be considered a "Using Protocol", specifying 1080 how a transport protocol meets those rules. [RFC6280] updates 1081 the guidance in RFC3693 to include subsequently introduced 1082 entities and concepts in the geolocation architecture. 1084 RFC5606 explores the difficulties inherent in mapping the GEOPRIV 1085 architecture onto SIP elements. In particular, the difficulties of 1086 defining and identifying recipients of location information are 1087 given in that document, along with guidance in Section 3.3.2 on the 1088 use of location by-reference mechanisms to preserve confidentiality 1089 of location information from unauthorized recipients. 1091 In a SIP deployment, location information may be added by any of 1092 several elements, including the originating user agent or a proxy 1093 server. In all cases, the Rule Maker associated with that location 1094 information decides which entity adds location information and what 1095 access control rules apply. For example, a SIP user agent that does 1096 not support the Geolocation header may rely on a proxy server under 1097 the direction of the Rule Maker adding a Geolocation header with a 1098 reference to location information. The manner in which the Rule 1099 Maker operates on these devices is outside the scope of this 1100 document. 1102 The manner in which SIP implementations honor the Rule Maker's 1103 stipulations for access control rules (including retention and 1104 retransmission) is application-specific and not within the scope of 1105 SIP protocol operations. Entities in SIP networks that fulfill the 1106 architectural roles of the Location Server or Location Recipient 1107 treat the privacy rules associated with location information per 1108 the guidance in [RFC6280] section 4.2.1. In particular, RFC4119 1109 (especially 2.2.2) gives guidance for handling access control rules; 1110 SIP implementations should furthermore consult the emendations in 1111 RFC5606. 1113 7. Security Considerations 1115 Conveyance of physical location of a UA raises privacy concerns, 1116 and depending on use, there probably will be authentication and 1117 integrity concerns. This document calls for conveyance to 1118 be accomplished through secure mechanisms, like S/MIME encrypting 1119 message bodies (although this is not widely deployed), TLS 1120 protecting the overall signaling or conveyance location by-reference 1121 and requiring all entities that dereference location to authenticate 1122 themselves. In location-based routing cases, encrypting the 1123 location payload with an end-to-end mechanism such as S/MIME is 1124 problematic, because one or more proxies on the path need the 1125 ability to read the location information to retarget the message to 1126 the appropriate new destination UAS. Data can only be encrypted to a 1127 particular, anticipated target, and thus if multiple recipients need 1128 to inspect a piece of data, and those recipients cannot be predicted 1129 by the sender of data, encryption is not a very feasible choice. 1130 Securing the location hop-by-hop, using TLS, protects the message 1131 from eavesdropping and modification in transit, but exposes the 1132 information to all proxies on the path as well as the endpoint. In 1133 most cases, the UA has no trust relationship with the proxy or 1134 proxies providing location-based routing services, so such 1135 end-to-middle solutions might not be appropriate either. 1137 When location information is conveyed by reference, however, one can 1138 properly authenticate and authorize each entity that wishes to 1139 inspect location information. This does not require that the sender 1140 of data anticipate who will receive data, and it does permit 1141 multiple entities to receive it securely, but it does not however 1142 obviate the need for pre-association between the sender of data and 1143 any prospective recipients. Obviously, in some contexts this 1144 pre-association cannot be presumed; when it is not, effectively 1145 unauthenticated access to location information must be permitted. In 1146 this case, choosing pseudo-random URIs for location by-reference, 1147 coupled with path encryption like SIPS, can help to ensure that only 1148 entities on the SIP signaling path learn the URI, and thus restores 1149 rough parity with sending location by-value. 1151 Location information is especially sensitive when the identity of 1152 its Target is obvious. Note that there is the ability, according to 1153 [RFC3693] to have an anonymous identity for the Target's location. 1154 This is accomplished by use of an unlinkable pseudonym in the 1155 "entity=" attribute of the element [RFC4479]. Though, 1156 this can be problematic for routing messages based on location 1157 (covered in the document above). Moreover, anyone fishing for 1158 information would correlate the identity at the SIP layer with that 1159 of the location information referenced by SIP signaling. 1161 When a UA inserts location, the UA sets the policy on whether to 1162 reveal its location along the signaling path - as discussed in 1163 Section 4, as well as flags in the PIDF-LO [RFC4119]. UAC 1164 implementations MUST make such capabilities conditional on explicit 1165 user permission, and MUST alert the user that location is being 1166 conveyed. 1168 This SIP extension offers the default ability to require permission 1169 to process location while the SIP request is in transit. The 1170 default for this is set to "no". There is an error explicitly 1171 describing how an intermediary asks for permission to view the 1172 Target's location, plus a rule stating the user has to be made aware 1173 of this permission request. 1175 There is no end-to-end integrity on any locationValue or 1176 locationErrorValue header field parameter (or middle-to-end if the 1177 value was inserted by a intermediary), so recipients of either 1178 header field need to implicitly trust the header field contents, and 1179 take whatever precautions each entity deems appropriate given this 1180 situation. 1182 8. IANA Considerations 1184 The following are the IANA considerations made by this SIP 1185 extension. Modifications and additions to all these registrations 1186 require a standards track RFC (Standards Action). 1188 [Editor's Note: RFC-Editor - within the IANA section, please 1189 replace "this doc" with the assigned RFC number, 1190 if this document reaches publication.] 1192 8.1 IANA Registration for the SIP Geolocation Header Field 1194 The SIP Geolocation Header Field is created by this document, with 1195 its definition and rules in Section 4.1 of this document, and should 1196 be added to the IANA sip-parameters registry with the following 1197 actions 1199 1. Update the Header Fields registry with 1201 Registry: 1202 Header Name compact Reference 1203 ----------------- ------- --------- 1204 Geolocation [this doc] 1206 8.2 IANA Registration for the SIP Geolocation-Routing Header Field 1208 The SIP Geolocation-Routing Header Field is created by this document, 1209 with its definition and rules in Section 4.2 of this document, and 1210 should be added to the IANA sip-parameters registry with the 1211 following action 1213 1. Update the Header Fields registry with 1215 Registry: 1216 Header Name compact Reference 1217 ----------------- ------- --------- 1218 Geolocation-Routing [this doc] 1220 8.3 IANA Registration for Location Profiles 1222 This document defines two new SIP option tags: "geolocation-sip" and 1223 "geolocation-http" to be added to the IANA sip-parameters Options 1224 Tags registry. 1226 Name Description Reference 1227 ----------- ------------------------------------------ --------- 1228 geolocation-sip The "geolocation-sip" option tag signals [this doc] 1229 support for acquiring location information 1230 via the presence event package of SIP 1231 (RFC 3856). A location recipient who 1232 supports this option can send a SUBSCRIBE 1233 request and parse a resulting NOTIFY 1234 containing a PIDF-LO object. The URI 1235 schemes supported by this option include 1236 "sip", "sips" and "pres". 1238 geolocation-http The "geolocation-http" option tag signals [this doc] 1239 support for acquiring location information 1240 via an HTTP ([RFC2616]). A location 1241 recipient who supports this option can 1242 request location with an HTTP GET and 1243 parse a resulting 200 response containing 1244 a PIDF-LO object. The URI schemes 1245 supported by this option include "http" 1246 and "https". 1248 The names of profiles are SIP option-tags, and the guidance in this 1249 document does not supersede the option-tag assignment guidance in 1250 [RFC3261] (which requires a Standards Action for the assignment of a 1251 new option tag). This document does however stipulate that 1252 option-tags included to convey the name of a location profile per 1253 this definition MUST begin with the string "geolocation" followed by 1254 a dash. All such option tags should describe protocols used to 1255 acquire location by reference: these tags have no relevance to 1256 location carried in SIP requests by value, which use standard MIME 1257 typing and negotiation. 1259 8.4 IANA Registration for 424 Response Code 1261 In the SIP Response Codes registry, the following is added 1263 Reference: RFC-XXXX (i.e., this document) 1264 Response code: 424 (recommended number to assign) 1265 Default reason phrase: Bad Location Information 1267 Registry: 1268 Response Code Reference 1269 ------------------------------------------ --------- 1270 Request Failure 4xx 1271 424 Bad Location Information [this doc] 1273 This SIP Response code is defined in section 4.3 of this document. 1275 8.5 IANA Registration of New Geolocation-Error Header Field 1277 The SIP Geolocation-error header field is created by this document, 1278 with its definition and rules in Section 4.4 of this document, to be 1279 added to the IANA sip-parameters registry with two actions 1281 1. Update the Header Fields registry with 1283 Registry: 1284 Header Name compact Reference 1285 ----------------- ------- --------- 1286 Geolocation-Error [this doc] 1288 2. In the portion titled "Header Field Parameters and Parameter 1289 Values", add 1291 Predefined 1292 Header Field Parameter Name Values Reference 1293 ----------------- ------------------- ---------- --------- 1294 Geolocation-Error code yes [this doc] 1296 8.6 IANA Registration for the SIP Geolocation-Error Codes 1298 This document creates a new registry for SIP, called 1299 "Geolocation-Error Codes." Geolocation-Error codes provide reason 1300 for the error discovered by Location Recipients, categorized by 1301 action to be taken by error recipient. The initial values for this 1302 registry are shown below. 1304 Registry Name: Geolocation-Error Codes 1305 Reference: [this doc] 1306 Registration Procedures: Specification Required 1308 Code Default Reason Phrase Reference 1309 ---- --------------------------------------------------- --------- 1310 100 "Cannot Process Location" [this doc] 1312 200 "Permission To Use Location Information" [this doc] 1314 201 "Permission To Retransmit Location Information to a Third Party" 1315 [this doc] 1317 202 "Permission to Route based on Location Information" [this doc] 1319 300 "Dereference Failure" [this doc] 1320 Details of these error codes are in Section 4.4 of this 1321 document. 1323 9. Acknowledgements 1325 To Dave Oran for helping to shape this idea. 1327 To Dean Willis for guidance of the effort. 1329 To Allison Mankin, Dick Knight, Hannes Tschofenig, Henning 1330 Schulzrinne, James Winterbottom, Jeroen van Bemmel, Jean-Francois 1331 Mule, Jonathan Rosenberg, Keith Drage, Marc Linsner, Martin Thomson, 1332 Mike Hammer, Ted Hardie, Shida Shubert, Umesh Sharma, Richard 1333 Barnes, Dan Wing, Matt Lepinski, John Elwell, Thomas Stach, 1334 Jacqueline Lee and Adam Roach for constructive feedback and nits 1335 checking. 1337 Special thanks to Paul Kyzivat for his help with the ABNF in this 1338 document and to Robert Sparks for many helpful comments and the 1339 proper construction of the Geolocation-Error header field. 1341 And finally, to Spencer Dawkins for giving this doc a good scrubbing 1342 to make it more readable. 1344 10. References 1346 10.1 Normative References 1348 [RFC3261] J. Rosenberg, H. Schulzrinne, G. Camarillo, A. Johnston, J. 1349 Peterson, R. Sparks, M. Handley, and E. Schooler, "SIP: 1350 Session Initiation Protocol", RFC 3261, May 2002. 1352 [RFC4119] J. Peterson, "A Presence-based GEOPRIV Location Object 1353 Format", RFC 4119, December 2005 1355 [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate 1356 Requirement Levels", RFC 2119, March 1997 1358 [RFC2392] E. Levinson, "Content-ID and Message-ID Uniform Resource 1359 Locators", RFC 2392, August 1998 1361 [RFC3856] J. Rosenberg, "A Presence Event Package for the Session 1362 Initiation Protocol (SIP)", RFC 3856, August 2004 1364 [RFC3859] J. Peterson, "Common Profile for Presence (CPP)", RFC 3859, 1365 August 2004 1367 [RFC3428] B. Campbell, Ed., J. Rosenberg, H. Schulzrinne, C. Huitema, 1368 D. Gurle, "Session Initiation Protocol (SIP) Extension for 1369 Instant Messaging" , RFC 3428, December 2002 1371 [RFC3311] J. Rosenberg, "The Session Initiation Protocol (SIP) UPDATE 1372 Method", RFC 3311, October 2002 1374 [RFC3265] Roach, A, "Session Initiation Protocol (SIP)-Specific 1375 Event Notification", RFC 3265, June 2002. 1377 [RFC6086] C. Holmberg, E. Burger, H. Kaplan, "Session Initiation 1378 Protocol (SIP) INFO Method and Package Framework", RFC 6086, 1379 January 2011 1381 [RFC3515] R. Sparks, "The Session Initiation Protocol (SIP) Refer 1382 Method", RFC 3515, April 2003 1384 [RFC3903] Niemi, A, "Session Initiation Protocol (SIP) Extension 1385 for Event State Publication", RFC 3903, October 2004. 1387 [RFC5234] Crocker, D., Ed., and P. Overell, "Augmented BNF for Syntax 1388 Specifications: ABNF", STD 68, RFC 5234, January 2008. 1390 [RFC4479] J. Rosenberg, "A Data Model for Presence", RFC 4479, July 1391 2006 1393 [RFC4483] E. Berger, "A Mechanism for Content Indirection in SIP", RFC 1394 4483, May 2006 1396 [RFC5491] J. Winterbottom, M. Thomson, H. Tschofenig, "GEOPRIV PIDF-LO 1397 Usage Clarification, Considerations, and Recommendations ", 1398 RFC 5491, March 2009 1400 [RFC5870] A. Mayrhofer, C. Spanring, "A Uniform Resource Identifier 1401 for Geographic Locations ('geo' URI)", RFC 5870, June 2010 1403 [RFC2616] R. Fielding, J. Gettys, J., Mogul, H. Frystyk, L., 1404 Masinter, P. Leach, T. Berners-Lee, "Hypertext Transfer 1405 Protocol - HTTP/1.1", RFC 2616, June 1999 1407 10.2 Informative References 1409 [RFC3693] J. Cuellar, J. Morris, D. Mulligan, J. Peterson. J. Polk, 1410 "Geopriv Requirements", RFC 3693, February 2004 1412 [RFC2818] E. Rescorla, "HTTP Over TLS", RFC 2818, May 2000 1414 [RFC5606] J. Peterson, T. Hardie, J. Morris, "Implications of 1415 'retransmission-allowed' for SIP Location Conveyance", 1416 RFC5606, Oct 2008 1418 [ID-GEO-FILTERS] R. Mahy, B. Rosen, H. Tschofenig, "Filtering Location 1419 Notifications in SIP", draft-ietf-geopriv-loc-filters, "work 1420 in progress", March 2010 1422 [ID-HELD-DEREF] J. Winterbottom, H. Tschofenig, H. Schulzrinne, M. 1423 Thomson, M. Dawson, "A Location Dereferencing Protocol Using 1424 HELD", "work in progress", June 2011 1426 [RFC6280] R. Barnes, M. Lepinski, A. Cooper, J, Morris, H. 1427 Tschofenig, H. Schulzrinne, "An Architecture for Location 1428 and Location Privacy in Internet Applications", 1429 draft-ietf-geopriv-arch, "work in progress", October 2010 1431 Authors' Addresses 1433 James Polk 1434 Cisco Systems 1435 3913 Treemont Circle 1436 Colleyville, Texas 76034 1438 33.00111N 1439 96.68142W 1441 Phone: +1-817-271-3552 1443 Email: jmpolk@cisco.com 1445 Brian Rosen 1446 NeuStar, Inc. 1447 470 Conrad Dr. 1448 Mars, PA 16046 1450 40.70497N 1451 80.01252W 1453 Phone: +1 724 382 1051 1454 Email: br@brianrosen.net 1456 Jon Peterson 1457 NeuStar, Inc. 1459 Email: jon.peterson@neustar.biz 1461 Appendix A. Requirements for SIP Location Conveyance 1463 The following subsections address the requirements placed on the 1464 UAC, the UAS, as well as SIP proxies when conveying location. This 1465 is from the original requirements draft that has since evolved into 1466 the solution document (that is above). This has been kept for 1467 historical reasons. 1469 If a requirement is not obvious in intent, a motivational statement 1470 is included below it. 1472 A.1 Requirements for a UAC Conveying Location 1474 UAC-1 The SIP INVITE Method [RFC3261] must support location 1475 conveyance. 1477 UAC-2 The SIP MESSAGE method [RFC3428] must support location 1478 conveyance. 1480 UAC-3 SIP Requests within a dialog should support location 1481 conveyance. 1483 UAC-4 Other SIP Requests may support location conveyance. 1485 UAC-5 There must be one, mandatory to implement means of 1486 transmitting location confidentially. 1488 Motivation: to guarantee interoperability. 1490 UAC-6 It must be possible for a UAC to update location conveyed 1491 at any time in a dialog, including during dialog 1492 establishment. 1494 Motivation: if a UAC has moved prior to the establishment of a 1495 dialog between UAs, the UAC must be able to send location 1496 information. If location has been conveyed, and the UA 1497 moves, the UAC must be able to update the location previously 1498 conveyed to other parties. 1500 UAC-7 The privacy and security rules established within [RFC3693] 1501 that would categorize SIP as a 'Using Protocol' MUST be met. 1503 UAC-8 The PIDF-LO [RFC4119] is a mandatory to implement format for 1504 location conveyance within SIP. 1506 Motivation: interoperability with other IETF location protocols and 1507 Mechanisms. 1509 UAC-9 There must be a mechanism for the UAC to request the UAS send 1510 its location. 1512 UAC-9 has been DEPRECATED by the SIP WG, due to the many 1513 problems this requirement would have caused if implemented. 1514 The solution is for the above UAS to send a new request to 1515 the original UAC with the UAS's location. 1517 UAC-10 There must be a mechanism to differentiate the ability of the 1518 UAC to convey location from the UACs lack of knowledge of its 1519 location 1521 Motivation: Failure to receive location when it is expected can 1522 happen because the UAC does not implement this extension, or 1523 because the UAC implements the extension, but does not know 1524 where the Target is. This may be, for example, due to the 1525 failure of the access network to provide a location 1526 acquisition mechanism the UAC supports. These cases must be 1527 differentiated. 1529 UAC-11 It must be possible to convey location to proxy servers 1530 along the path. 1532 Motivation: Location-based routing. 1534 A.2 Requirements for a UAS Receiving Location 1536 The following are the requirements for location conveyance by a UAS: 1538 UAS-1 SIP Responses must support location conveyance. 1540 The SIPCORE WG reached consensus that this be allowed, but 1541 not to communicate the UAS's location; rather for a SIP 1542 intermediary to inform the UAC which location to include in 1543 its next SIP request (as a matter of correcting what was 1544 originally sent by the UAC). 1546 UAS-2 There must be a unique 4XX response informing the UAC it did 1547 not provide applicable location information. 1549 In addition, requirements UAC-5, 6, 7 and 8 also apply to the UAS. 1551 A.3 Requirements for SIP Proxies and Intermediaries 1553 The following are the requirements for location conveyance by a SIP 1554 proxies and intermediaries: 1556 Proxy-1 Proxy servers must be capable of adding a Location header 1557 field during processing of SIP requests. 1559 Motivation: Provide network assertion of location 1560 when UACs are unable to do so, or when network assertion is 1561 more reliable than UAC assertion of location 1563 Note: Because UACs connected to SIP signaling networks can have 1564 widely varying access network arrangements, including VPN 1565 tunnels and roaming mechanisms, it can be difficult for a 1566 network to reliably know the location of the endpoint. 1567 Proxies SHOULD NOT assert location of an endpoint unless the 1568 SIP signaling network has reliable knowledge of the actual 1569 location of the Targets. 1571 Proxy-2 There must be a unique 4XX response informing the UAC it 1572 did not provide applicable location information.