idnits 2.17.1 draft-ietf-sipcore-location-conveyance-07.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 30 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 1224 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 (May 4, 2011) is 4734 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) ** Downref: Normative reference to an Informational RFC: RFC 5606 ** 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: 4 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: Nov 4, 2011 Brian Rosen 5 Intended Status: Standards Track (PS) Jon Peterson 6 NeuStar 7 May 4, 2011 9 Location Conveyance for the Session Initiation Protocol 10 draft-ietf-sipcore-location-conveyance-07.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 Nov 4, 2011. 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 . . . . . . . . . . . 4 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 . . . . . . 12 85 4.4 The Geolocation-Error Header Field . . . . . . . . . . . 13 86 4.5 Location URIs in Message Bodies . . . . . . . . . . . . . 16 87 4.6 Location Profile Negotiation . . . . . . . . . . . . . . 16 88 5. Geolocation Examples . . . . . . . . . . . . . . . . . . . . 17 89 5.1 Location-by-value (Coordinate Format) . . . . . . . . . . 17 90 5.2 Two Locations Composed in Same Location Object Example . 19 91 6. Geopriv Privacy Considerations . . . . . . . . . . . . . . . 20 92 7. Security Considerations . . . . . . . . . . . . . . . . . . . 21 93 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . 22 94 8.1 IANA Registration for New SIP Geolocation Header Field . 22 95 8.2 IANA Registration for New SIP Geolocation-Routing Header 96 Field . . . . . . . . . . . . . . . . . . . . . . . . . . 22 97 8.3 IANA Registration for New SIP Option Tags . . . . . . . . 23 98 8.4 IANA Registration for New 424 Response Code . . . . . . . 23 99 8.5 IANA Registration for New SIP Geolocation-Error Header 100 Field . . . . . . . . . . . . . . . . . . . . . . . . . . 24 101 8.6 IANA Registration for New SIP Geolocation-Error Codes . . 24 102 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 24 103 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 25 104 10.1 Normative References . . . . . . . . . . . . . . . . . 25 105 10.2 Informative References . . . . . . . . . . . . . . . . . 26 106 Author Information . . . . . . . . . . . . . . . . . . . . . 27 107 Appendix A. Requirements for SIP Location Conveyance . . . . 27 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, 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 any of the diagrams the SIP intermediary receives the SIP 171 request is potentially an LR - though that does not mean such an 172 intermediary necessarily has to route the SIP request based on the 173 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 location recipient. It could be the case that 290 a SIP intermediary which does not perform location-based routing but 291 does care when Alice includes her location; for example, it could 292 care that the location information is complete or that it correctly 293 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 Modifications for Geolocation Conveyance 372 The following sections detail the modifications 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. 408 Other URI schemas used in the location URI MUST be reviewed against 409 the RFC 3693 [RFC3693] criteria for a Using Protocol. 411 The generic-param in the definition of locationValue is included as 412 a mechanism for future extensions that might require parameters. 413 This document defines no parameters for use with locationValue. If a 414 Geolocation header field is received that contains generic-params, 415 each parameter SHOULD be ignored, and SHOULD NOT be removed when 416 forwarding the locationValue. If a need arises to define parameters 417 for use with locationValue, a revision/extension to this document is 418 required. 420 The Geolocation header field can have one or more locationValues. A 421 Geolocation header field MUST have at least one locationValue. A 422 SIP intermediary SHOULD NOT add location to a SIP request that 423 already contains location. This will quite often lead to confusion 424 within LRs. However, if a SIP intermediary adds location, even if 425 location was not previously present in a SIP request, that SIP 426 intermediary is fully responsible for addressing the concerns of any 427 424 (Bad Location Information) SIP response it receives about this 428 location addition, and MUST NOT pass on (upstream) the 424 response. 429 A SIP intermediary that adds a locationValue MUST position the new 430 locationValue as the last locationValue within the Geolocation 431 header field of the SIP request. 433 This document defines the Geolocation header field as valid in the 434 following SIP requests: 436 INVITE [RFC3261], REGISTER [RFC3261], 437 OPTIONS [RFC3261], BYE [RFC3261], 438 UPDATE [RFC3311], INFO [RFC6086], 439 MESSAGE [RFC3428], REFER [RFC3515], 440 SUBSCRIBE [RFC3265], NOTIFY [RFC3265], 441 PUBLISH [RFC3903] 443 The Geolocation header field MAY be included in any one of the 444 above listed requests by a UA, and a 424 response to any one of the 445 requests sent above. Fully appreciating the caveats/warnings 446 mentioned above, a SIP intermediary MAY add the Geolocation header 447 field. 449 A SIP intermediary MAY add a Geolocation header field if one is not 450 present - for example, when a user agent does not support the 451 Geolocation mechanism but their outbound proxy does and knows the 452 Target's location, or any of a number of other use cases (see 453 Section 3). 455 The Geolocation header field MAY be present in a SIP request or 456 response without the presence of a Geolocation-Routing header 457 (defined in Section 4.2). As stated in Section 4.2, the default 458 value of Geolocation-Routing header-value is "no", meaning SIP 459 intermediaries are not to view any direct or indirect location 460 within this SIP message. 462 Any locationValue MUST be related to the original Target. This is 463 equally true the location information in a SIP response, i.e., from 464 a SIP intermediary back to the Target as explained in Section 3.4. 466 SIP intermediaries SHOULD NOT modify or delete any existing 467 locationValue(s). 469 4.2 The Geolocation-Routing Header Field 471 This document defines "Geolocation-Routing" as a new SIP header 472 field registered by IANA, with the following ABNF [RFC5234]: 474 message-header /= Georouting-header ; (message-header from 3261) 475 Georouting-header = "Geolocation-Routing" HCOLON 476 ( "yes" / "no" / generic-value ) 477 generic-value = generic-param; (from RFC 3261) 479 HCOLON is defined in RFC3261 [RFC3261]. 481 The only defined values for the Geolocation-Routing header field are 482 "yes" or "no". When the value is "yes", the locationValue can be 483 used for routing decisions along the downstream signaling path by 484 intermediaries. Values other than "yes" or "no" are permitted for 485 future extensions. Implementations not aware of an extension MUST 486 treat any other received value the same as "no". 488 If no Geolocation-Routing header field is present in a SIP request, 489 a SIP intermediary MAY insert this header. Without knowledge from a 490 Rulemaker, the SIP intermediary inserting this header-value SHOULD 491 NOT set the value to "yes", as this could allow the Target's 492 location to be forwarded to third parties without the Target's 493 explicit permission. An easy way around this is to have the Target 494 always insert this header-value as "no". 496 When this Geolocation-Routing header-value is set to "no", this 497 means no locationValue (inserted by the originating UAC or any 498 intermediary along the signaling path) can be used by any SIP 499 intermediary to make routing decisions. Intermediaries that attempt 500 to use the location information for routing purposes in spite of 501 this counter indication could end up routing the request improperly 502 as a result. Section 4.4 describes the details on what a routing 503 intermediary does if it determines it needs to use the location in 504 the SIP request in order to process the message further. The 505 practical implication is that when the Geolocation-Routing 506 header-value is set to "no", if a cid:url is present in the SIP 507 request, intermediaries SHOULD NOT view the location (because it is 508 not for intermediaries to view), and if a location URI is present, 509 intermediaries SHOULD NOT dereference it. UAs are allowed to view 510 location in the SIP request even when the Geolocation-Routing 511 header-value is set to "no". An LR MUST by default consider the 512 Geolocation-Routing header-value as set to "no", with no exceptions, 513 unless the header field value is set to "yes". 515 A Geolocation-Routing header-value that is set to "no" has no 516 special security properties. It is at most a request for behavior 517 within SIP intermediaries. That said, if the Geolocation-Routing 518 header-value is set to "no", SIP intermediaries are still to process 519 the SIP request and send it further downstream within the signaling 520 path if there are no errors present in this SIP request. 522 The Geolocation-Routing header field satisfies the recommendations 523 made in section 3.5 of RFC 5606 [RFC5606] regarding indication of 524 permission to use location-based routing in SIP. 526 SIP implementations are advised to pay special attention to the 527 policy elements for location retransmission and retention described 528 in RFC 4119. 530 The Geolocation-Routing header field cannot appear without a 531 header-value in a SIP request or response (i.e., a null value is not 532 allowed). The absence of a Geolocation-Routing header-value in a SIP 533 request is always the same as the following header field: 535 Geolocation-Routing: no 537 The Geolocation-Routing header field MAY be present without a 538 Geolocation header field in the same SIP request. This concept is 539 further explored in Section 4.2.1. 541 4.2.1 Explaining Geolocation-Routing header-value States 543 The Geolocation header field contains a Target's location, and MUST 544 NOT be present if there is no location information in this SIP 545 request. The location information is contained in one or more 546 locationValues. These locationValues MAY be contained in a single 547 Geolocation header field, or distributed among multiple Geolocation 548 header fields. (See section 7.3.1 of RFC3261.) 550 The Geolocation-Routing header field indicates whether or not SIP 551 intermediaries can view and then route this SIP request based on the 552 included (directly or indirectly) location information. The 553 Geolocation-Routing header field MUST NOT appear more than once in 554 any SIP request, and MUST NOT lack a header-value. The default or 555 implied policy of a SIP request that does not have a 556 Geolocation-Routing header field is the same as if one were present 557 and the header-value were set to "no". 559 There are only 3 possible states regarding the Geolocation-Routing 560 header field 562 - "no" 563 - "yes" 564 - no header-field present in this SIP request 566 The expected results in each state are: 568 If the Geolocation-Routing Only possible interpretations: 569 -------------------------- ----------------------------- 570 "no" Location viewing policy set already 571 such that no intermediaries can view 572 location inserted downstream. 574 SIP intermediaries inserting a 575 locationValue into a Geolocation 576 header field (whether adding to an 577 existing header-value or inserting the 578 Geolocation header field for the first 579 time) MUST NOT modify or delete the 580 received "no" header-value. 582 "yes" Location viewing policy set already 583 such that if location is inserted 584 downstream, intermediaries can 585 maintain an open viewing of location 586 policy or can change policy to "no" 587 for intermediaries further downstream. 589 Geolocation-Routing absent If a Geolocation header field exists 590 (meaning a locationValue is already 591 present), a SIP intermediary MUST 592 interpret the lack of a 593 Geolocation-Routing header field as if 594 there were one present and the 595 header-value is set to "no". 597 If there is no Geolocation header 598 field in this SIP request, the default 599 Geolocation-Routing is open and can be 600 set by a downstream entity or not at 601 all. 603 4.3 424 (Bad Location Information) Response Code 605 This SIP extension creates a new location-specific response code, 606 defined as follows, 608 424 (Bad Location Information) 610 The 424 (Bad Location Information) response code is a rejection of 611 the request due to its location contents, indicating location 612 information that was malformed or not satisfactory for the 613 recipient's purpose, or could not be dereferenced. 615 A SIP intermediary can also reject a location it receives from a 616 Target when it understands the Target to be in a different location. 617 The proper handling of this scenario, described in Section 3.4, is 618 for the SIP intermediary to include the proper location in the 424 619 Response. This SHOULD be included in the response as a MIME message 620 body (i.e., a location value), rather than as a URI; however, in 621 cases where the intermediary is willing to share location with 622 recipients but not with a user agent, a reference might be 623 necessary. 625 As mentioned in Section 3.4, it might be the case that the 626 intermediary does not want to chance providing less accurate 627 location information than the user agent; thus it will compose its 628 understanding of where the user agent is in a separate 629 element of the same PIDF-LO message body in the SIP response (which 630 also contains the Target's version of where it is). Therefore, both 631 locations are included - each with different elements. The 632 proper reaction of the user agent is to generate a new SIP request 633 that includes this composed location object, and send it towards the 634 original LR. SIP intermediaries can verify that subsequent requests 635 properly insert the suggested location information before forwarding 636 said requests. 638 SIP intermediaries that are forwarding (as opposed to generating) a 639 424 response MUST NOT add, modify, or delete any location appearing 640 in that response. This specifically applies to intermediaries that 641 are between the 424 response generator and the original UAC. 642 Geolocation and Geolocation-Error header fields and PIDF-LO body 643 parts MUST remain unchanged, never added to or deleted. 645 Section 4.4 describes a Geolocation-Error header field to provide 646 more detail about what was wrong with the location information in 647 the request. This header field MUST be included in the 424 response. 649 It is only appropriate to generate a 424 response when the 650 responding entity needs a locationValue and there are no values in 651 the request that are usable by the responder, or when the responder 652 has additional location information to provide. The latter case is 653 shown in Figure 4 of section 3.4. There, a SIP intermediary is 654 informing the upstream UA which location to include in the next SIP 655 request. 657 A 424 MUST NOT be sent in response to a request that lacks a 658 Geolocation header entirely, as the user agent in that case may not 659 support this extension at all. If a SIP intermediary inserted a 660 locationValue into a SIP request where one was not previously 661 present, it MUST take any and all responsibility for the corrective 662 action if it receives a 424 to a SIP request it sent. 664 A 424 (Bad Location Information) response is a final response within 665 a transaction, and MUST NOT terminate an existing dialog. 667 4.4 The Geolocation-Error Header Field 669 As discussed in Section 4.3, more granular error notifications 670 specific to location errors within a received request are required 671 if the location inserting entity is to know what was wrong within 672 the original request. The Geolocation-Error header field is used for 673 this purpose. 675 The Geolocation-Error header field is used to convey 676 location-specific errors within a response. The Geolocation-Error 677 header field has the following ABNF [RFC5234]: 679 message-header /= Geolocation-Error ; 680 (message-header from 3261) 681 Geolocation-Error = "Geolocation-Error" HCOLON 682 locationErrorValue 683 locationErrorValue = location-error-code 684 *(SEMI location-error-params) 685 location-error-code = 1*3DIGIT 686 location-error-params = location-error-code-text 687 / generic-param ; from RFC3261 688 location-error-code-text = "code" EQUAL quoted-string ; from RFC3261 690 HCOLON, SEMI, and EQUAL are defined in RFC3261 [RFC3261]. DIGIT is 691 defined in RFC5234 [RFC5234]. 693 The Geolocation-Error header field MUST contain only one 694 locationErrorValue to indicate what was wrong with the locationValue 695 the Location Recipient determined was bad. The locationErrorValue 696 contains a 3-digit error code indicating what was wrong with the 697 location in the request. This error code has a corresponding quoted 698 error text string that is human understandable. The text string are 699 OPTIONAL, but RECOMMENDED for human readability, similar to the 700 string phrase used for SIP response codes. That said, the strings 701 are complete enough for rendering to the user, if so desired. The 702 strings in this document are recommendations, and are not 703 standardized - meaning an operator can change the strings - but MUST 704 NOT change the meaning of the error code. Similar to how RFC 3261 705 specifies, there MUST NOT be more than one string per error code. 707 The Geolocation-Error header field MAY be included in any response 708 to one of the SIP Methods mentioned in Section 4.1, so long as a 709 locationValue was in the request part of the same transaction. For 710 example, Alice includes her location in an INVITE to Bob. Bob can 711 accept this INVITE, thus creating a dialog, even though his UA 712 determined the location contained in the INVITE was bad. Bob merely 713 includes a Geolocation-Error header value in the 200 OK to the 714 INVITE informing Alice the INVITE was accepted but the location 715 provided was bad. 717 If, on the other hand, Bob cannot accept Alice's INVITE without a 718 suitable location, a 424 (Bad Location Information) is sent. This 719 message flow is shown in Figures 1, 2 or 3 in Sections 3.1, 3.2 and 720 3.3 respectively. 722 A SIP intermediary that requires Alice's location in order to 723 properly process Alice's INVITE also sends a 424 with a 724 Geolocation-Error code. This message flow is shown in Figure 4 of 725 Section 3.4. 727 If more than one locationValue is present in a SIP request and at 728 least one locationValue is determined to be valid by the LR, the 729 location in that SIP request MUST be considered good as far as 730 location is concerned, and no Geolocation-Error is to be sent. 732 Here is an initial list of location based error code ranges for any 733 SIP response, including provisional responses (other than 100 734 Trying) and the new 424 (Bad Location Information) response. These 735 error codes are divided into 3 categories, based on how the response 736 receiver should react to these errors. There MUST be no more than 737 one Geolocation-Error code in a SIP response, regardless of how many 738 locationValues there are in the correlating SIP request. There is no 739 guidance given in this document as to which locationValue, when more 740 than one was present in the SIP request, is related to the 741 Geolocation-Error code; meaning that, somehow not defined here, the 742 LR just picks one to error. 744 o 1XX errors mean the LR cannot process the location within the 745 request 747 A non-exclusive list of reasons for returning a 1XX is 749 - the location was not present or could not be found, 750 - there was not enough location information to determine 751 where the Target was, 752 - the location information was corrupted or known to be 753 inaccurate, 755 o 2XX errors mean some specific permission is necessary to process 756 the included location information. 758 o 3XX errors mean there was trouble dereferencing the Location URI 759 sent. 761 It should be noted that for non-INVITE transactions, the SIP 762 response will likely be sent before the dereference response has 763 been received. This document does not alter that SIP protocol 764 reality. This means the receiver of any non-INVITE response to a 765 request containing location SHOULD NOT consider a 200 OK to mean the 766 act of dereferencing has concluded and the dereferencer (i.e., the 767 LR) has successfully received and parsed the PIDF-LO for errors and 768 found none. The end of section 3.2 discusses how transaction timing 769 considerations lead to this requirement. 771 Additionally, if an LR cannot or chooses not to process location 772 from a SIP request, a 500 (Server Internal Error) SHOULD be used 773 with or without a configurable Retry-After header field. There is no 774 special location error code for what already exists within SIP 775 today. 777 Within each of these ranges, there is a top level error as follows: 779 Geolocation-Error: 100 ; code="Cannot Process Location" 781 Geolocation-Error: 200 ; code="Permission To Use Location 782 Information" 784 Geolocation-Error: 300 ; code="Dereference Failure" 786 If an error recipient cannot process an specific error code (such as 787 the 201 or 202 below), perhaps because it does not understand that 788 specific error code, the error recipient SHOULD process the error 789 code as if it originally were a top level error code where the X in 790 X00 matches the specific error code. If the error recipient cannot 791 process a non-100 error code, for whatever reason, then the error 792 code 100 MUST be processed. 794 There are two specific Geolocation-Error codes necessary to include 795 in this document, both have to do with permissions necessary to 796 process the SIP request; they are 798 Geolocation-Error: 201 ; code="Permission To Retransmit Location 799 Information to a Third Party" 801 This location error is specific to having the Presence Information 802 Data Format (PIDF-LO) [RFC4119] element set 803 to "no". This location error is stating it requires permission 804 (i.e., PIDF-LO element set to "yes") to 805 process this SIP request further. If the LS sending the location 806 information does not want to give this permission, it will not reset 807 this permission in a new request. If the LS wants this message 808 processed without this permission reset, it MUST choose another 809 logical path (if one exists) for this SIP request. 811 Geolocation-Error: 202 ; code="Permission to Route based on Location 812 Information" 814 This location error is specific to having the Geolocation-Routing 815 header value set to "no". This location error is stating it requires 816 permission (i.e., the Geolocation-Routing header value set to "yes") 817 to process this SIP request further. If the LS sending the location 818 information does not want to give this permission, it will not reset 819 this permission in a new request. If the LS wants this message 820 processed without this permission reset, it MUST choose another 821 logical path (if one exists) for this SIP request. 823 4.5 Location URIs in Message Bodies 825 In the case where an LR sends a 424 response and wishes to 826 communicate suitable location by reference rather than by value, the 827 424 MUST include a content-indirection body per RFC 4483. 829 4.6 Location Profile Negotiation 831 The following is part of the discussion started in Section 3, Figure 832 2, which introduced the concept of sending location indirectly. 834 If a location URI is included in a SIP request, the sending user 835 agent MUST also include a Supported header field indicating which 836 location profiles it supports. Two option tags for location profiles 837 are defined by this document: "geolocation-sip" and 838 "geolocation-http". Future specifications MAY define further 839 location profiles per the IANA policy described in Section 8.3. 841 The "geolocation-sip" option tag signals support for acquiring 842 location information via the presence event package of SIP 843 ([RFC3856]). A location recipient who supports this option can send 844 a SUBSCRIBE request and parse a resulting NOTIFY containing a 845 PIDF-LO object. The URI schemes supported by this option include 846 "sip", "sips" and "pres". 848 The "geolocation-http" option tag signals support for acquiring 849 location information via an HTTP ([RFC2616]). A location recipient 850 who supports this option can request location with an HTTP GET and 851 parse a resulting 200 response containing a PIDF-LO object. The URI 852 schemes supported by this option include "http" and "https". A 853 failure to parse the 200 response, for whatever reason, will return 854 a "Dereference Failure" indication to the original location sending 855 user agent to inform it that location was not delivered as intended. 857 If the location URI receiver does not understand the URI scheme sent 858 to it, it will return an Unsupported header value of the option-tag 859 from the SIP request, and include the option-tag of the preferred 860 URI scheme in the response's Supported header field. 862 See [ID-GEO-FILTERS] or [ID-HELD-DEREF] for more details on 863 dereferencing location information. 865 5. Geolocation Examples 867 5.1 Location-by-value (in Coordinate Format) 869 This example shows an INVITE message with a coordinate location. In 870 this example, the SIP request uses a sips-URI [RFC3261], meaning 871 this message is protected using TLS on a hop-by-hop basis. 873 INVITE sips:bob@biloxi.example.com SIP/2.0 874 Via: SIPS/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bK74bf9 875 Max-Forwards: 70 876 To: Bob 877 From: Alice ;tag=9fxced76sl 878 Call-ID: 3848276298220188511@atlanta.example.com 879 Geolocation: 880 Geolocation-Routing: no 881 Accept: application/sdp, application/pidf+xml 882 CSeq: 31862 INVITE 883 Contact: 884 Content-Type: multipart/mixed; boundary=boundary1 885 Content-Length: ... 887 --boundary1 889 Content-Type: application/sdp 891 ...SDP goes here 893 --boundary1 895 Content-Type: application/pidf+xml 896 Content-ID: 897 898 906 907 908 909 910 911 32.86726 -97.16054 912 913 914 915 916 false 917 918 2010-11-14T20:00:00Z 919 920 921 802.11 922 923 mac:1234567890ab 924 2010-11-04T20:57:29Z 925 926 927 --boundary1-- 929 The Geolocation header field from the above INVITE: 931 Geolocation: 933 ... indicates the content-ID location [RFC2392] within the multipart 934 message body of where location information is. The other message 935 body part is SDP. The "cid:" eases message body parsing and 936 disambiguates multiple parts of the same type. 938 If the Geolocation header field did not contain a "cid:" scheme, for 939 example, it could look like this location URI: 941 Geolocation: 943 ... the existence of a non-"cid:" scheme indicates this is a 944 location URI, to be dereferenced to learn the Target's location. Any 945 node wanting to know where the target is located would subscribe to 946 the SIP presence event package [RFC3856] at 948 sips:target123@server5.atlanta.example.com 950 (see Figure 2 in Section 3.2 for this message flow). 952 5.2 Two Locations Composed in Same Location Object Example 954 This example shows the INVITE message after a SIP intermediary 955 rejected the original INVITE (say, the one in section 5.1). This 956 INVITE contains the composed LO sent by the SIP intermediary which 957 includes where the intermediary understands Alice to be. The rules 958 of RFC 5491 [RFC5491] are followed in this construction. 960 This example is here, but ought not be taken as occurring very 961 often. In fact, this example is believed to be a corner case of 962 location conveyance applicability. 964 INVITE sips:bob@biloxi.example.com SIP/2.0 965 Via: SIPS/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bK74bf0 966 Max-Forwards: 70 967 To: Bob 968 From: Alice ;tag=9fxced76sl 969 Call-ID: 3848276298220188512@atlanta.example.com 970 Geolocation: 971 Geolocation-Routing: no 972 Accept: application/sdp, application/pidf+xml 973 CSeq: 31863 INVITE 974 Contact: 975 Content-Type: multipart/mixed; boundary=boundary1 976 Content-Length: ... 978 --boundary1 980 Content-Type: application/sdp 982 ...SDP goes here 984 --boundary1 986 Content-Type: application/pidf+xml 987 Content-ID: 988 989 997 998 999 1000 1001 1002 32.86726 -97.16054 1003 1004 1005 1006 1007 false 1008 1009 2010-11-14T20:00:00Z 1010 1011 1012 802.11 1013 1014 mac:1234567890ab 1015 2010-11-04T20:57:29Z 1016 1017 1018 1019 1020 1021 US 1022 Texas 1023 Colleyville 1024 Treemont 1025 Circle 1026 3913 1027 1 1028 Haley's Place 1029 76034 1030 1031 1032 1033 false 1034 1035 2010-11-14T20:00:00Z 1036 1037 1038 triangulation 1039 1040 2010-11-04T12:28:04Z 1041 1042 1043 --boundary1-- 1045 6. Geopriv Privacy Considerations 1047 Location information is considered by most to be highly sensitive 1048 information, requiring protection from eavesdropping and altering in 1049 transit. [RFC3693] originally articulated rules to be followed by 1050 any protocol wishing to be considered a "Using Protocol", specifying 1051 how a transport protocol meets those rules. [ID-GEO-ARCH] updates 1052 the guidance in RFC3693 to include subsequently-introduced 1053 entities and concepts in the geolocation architecture. 1055 Implementations of this SIP location conveyance mechanism MUST 1056 adhere to the guidance given in RFC3693 and its updates and/or 1057 successors, including (but not limited to) the handling of rules for 1058 retention and retransmission. 1060 7. Security Considerations 1062 Conveyance of physical location of a UA raises privacy concerns, 1063 and depending on use, there probably will be authentication and 1064 integrity concerns. This document calls for conveyance to 1065 be accomplished through secure mechanisms, like S/MIME encrypting 1066 message bodies (although this is not widely deployed), TLS 1067 protecting the overall signaling or conveyance location by-reference 1068 and requiring all entities that dereference location to authenticate 1069 themselves. In location-based routing cases, encrypting the 1070 location payload with an end-to-end mechanism such as S/MIME is 1071 problematic, because one or more proxies on the path need the 1072 ability to read the location information to retarget the message to 1073 the appropriate new destination UAS. Data can only be encrypted to a 1074 particular, anticipated target, and thus if multiple recipients need 1075 to inspect a piece of data, and those recipients cannot be predicted 1076 by the sender of data, encryption is not a very feasible choice. 1077 Securing the location hop-by-hop, using TLS, protects the message 1078 from eavesdropping and modification in transit, but exposes the 1079 information to all proxies on the path as well as the endpoint. In 1080 most cases, the UA has no trust relationship with the proxy or 1081 proxies providing location-based routing services, so such 1082 end-to-middle solutions might not be appropriate either. 1084 When location information is conveyed by reference, however, one can 1085 properly authenticate and authorize each entity that wishes to 1086 inspect location information. This does not require that the sender 1087 of data anticipate who will receive data, and it does permit 1088 multiple entities to receive it securely, but it does not however 1089 obviate the need for pre-association between the sender of data and 1090 any prospective recipients. Obviously, in some contexts this 1091 pre-association cannot be presumed; when it is not, effectively 1092 unauthenticated access to location information must be permitted. In 1093 this case, choosing pseudo-random URIs for location by-reference, 1094 coupled with path encryption like SIPS, can help to ensure that only 1095 entities on the SIP signaling path learn the URI, and thus restores 1096 rough parity with sending location by-value. 1098 Location information is especially sensitive when the identity of 1099 its Target is obvious. Note that there is the ability, according to 1100 [RFC3693] to have an anonymous identity for the Target's location. 1101 This is accomplished by use of an unlinkable pseudonym in the 1102 "entity=" attribute of the element [RFC4479]. Though, 1103 this can be problematic for routing messages based on location 1104 (covered in the document above). Moreover, anyone fishing for 1105 information would correlate the identity at the SIP layer with that 1106 of the location information referenced by SIP signaling. 1108 When a UA inserts location, the UA sets the policy on whether to 1109 reveal its location along the signaling path - as discussed in 1110 Section 4, as well as flags in the PIDF-LO [RFC4119]. UAC 1111 implementations MUST make such capabilities conditional on explicit 1112 user permission, and MUST alert the user that location is being 1113 conveyed. 1115 This SIP extension offers the default ability to require permission 1116 to view location while the SIP request is in transit. The default 1117 for this is set to "no". There is an error explicitly describing 1118 how an intermediary asks for permission to view the Target's 1119 location, plus a rule stating the user has to be made aware of this 1120 permission request. 1122 There is no end-to-end integrity on any locationValue or 1123 locationErrorValue header field parameter (or middle-to-end if the 1124 value was inserted by a intermediary), so recipients of either 1125 header field need to implicitly trust the header field contents, and 1126 take whatever precautions each entity deems appropriate given this 1127 situation. 1129 8. IANA Considerations 1131 The following are the IANA considerations made by this SIP 1132 extension. Modifications and additions to all these registrations 1133 require a standards track RFC (Standards Action). 1135 [Editor's Note: RFC-Editor - within the IANA section, please 1136 replace "this doc" with the assigned RFC number, 1137 if this document reaches publication.] 1139 8.1 IANA Registration for the SIP Geolocation Header Field 1141 The SIP Geolocation Header Field is created by this document, with 1142 its definition and rules in Section 4.1 of this document, and should 1143 be added to the IANA sip-parameters registry with the following 1144 actions 1146 1. Update the Header Fields registry with 1148 Registry: 1149 Header Name compact Reference 1150 ----------------- ------- --------- 1151 Geolocation [this doc] 1153 8.2 IANA Registration for the SIP Geolocation-Routing Header Field 1155 The SIP Geolocation-Routing Header Field is created by this document, 1156 with its definition and rules in Section 4.2 of this document, and 1157 should be added to the IANA sip-parameters registry with the 1158 following action 1160 1. Update the Header Fields registry with 1162 Registry: 1163 Header Name compact Reference 1164 ----------------- ------- --------- 1165 Geolocation-Routing [this doc] 1167 8.3 IANA Registration for Location Profiles 1169 This document defines two new SIP option tags: "geolocation-sip" and 1170 "geolocation-http." with the definition and rule in Section 4.6 of 1171 this document, to be added to the IANA sip-parameters Options Tags 1172 registry. 1174 Name Valid Scheme(S) Reference 1175 geolocation-sip See 4.6 [this doc] 1176 geolocation-http See 4.6 [this doc] 1178 The names of profiles are SIP option-tags, and the guidance in this 1179 document does not supersede the option-tag assignment guidance in 1180 [RFC3261] (which requires a Standards Action for the assignment of a 1181 new option tag). This document does however stipulate that 1182 option-tags included to convey the name of a location profile per 1183 this definition MUST begin with the string "geolocation" followed by 1184 a dash. All such option tags should describe protocols used to 1185 acquire location by reference: these tags have no relevance to 1186 location carried in SIP requests by value, which use standard MIME 1187 typing and negotiation. 1189 8.4 IANA Registration for 424 Response Code 1191 In the SIP Response Codes registry, the following is added 1193 Reference: RFC-XXXX (i.e., this document) 1194 Response code: 424 (recommended number to assign) 1195 Default reason phrase: Bad Location Information 1197 Registry: 1198 Response Code Reference 1199 ------------------------------------------ --------- 1200 Request Failure 4xx 1201 424 Bad Location Information [this doc] 1203 This SIP Response code is defined in section 4.3 of this document. 1205 8.5 IANA Registration of New Geolocation-Error Header Field 1207 The SIP Geolocation-error header field is created by this document, 1208 with its definition and rules in Section 4.4 of this document, to be 1209 added to the IANA sip-parameters registry with two actions 1211 1. Update the Header Fields registry with 1213 Registry: 1214 Header Name compact Reference 1215 ----------------- ------- --------- 1216 Geolocation-Error [this doc] 1218 2. In the portion titled "Header Field Parameters and Parameter 1219 Values", add 1221 Predefined 1222 Header Field Parameter Name Values Reference 1223 ----------------- ------------------- ---------- --------- 1224 Geolocation-Error code= yes [this doc] 1226 8.6 IANA Registration for the SIP Geolocation-Error Codes 1228 New location specific Geolocation-Error codes are created by this 1229 document, and registered in a new table in the IANA sip-parameters 1230 registry. Details of these error codes are in Section 4.4 of this 1231 document. 1233 Geolocation-Error codes 1234 ----------------------- 1235 Geolocation-Error codes provide reason for the error discovered by 1236 Location Recipients, categorized by action to be taken by error 1237 recipient. 1239 Code Default Reason Phrase Reference 1240 ---- --------------------------------------------------- --------- 1241 100 "Cannot Process Location" [this doc] 1243 200 "Permission To Use Location Information" [this doc] 1245 201 "Permission To Retransmit Location Information to a Third Party" 1246 [this doc] 1248 202 "Permission to Route based on Location Information" [this doc] 1250 300 "Dereference Failure" [this doc] 1252 9. Acknowledgements 1254 To Dave Oran for helping to shape this idea. 1256 To Dean Willis for guidance of the effort. 1258 To Allison Mankin, Dick Knight, Hannes Tschofenig, Henning 1259 Schulzrinne, James Winterbottom, Jeroen van Bemmel, Jean-Francois 1260 Mule, Jonathan Rosenberg, Keith Drage, Marc Linsner, Martin Thomson, 1261 Mike Hammer, Ted Hardie, Shida Shubert, Umesh Sharma, Richard 1262 Barnes, Dan Wing, Matt Lepinski, John Elwell, Thomas Stach and 1263 Jacqueline Lee for constructive feedback and nits checking. 1265 Special thanks to Paul Kyzivat for his help with the ABNF in this 1266 document and to Robert Sparks for many helpful comments and the 1267 proper construction of the Geolocation-Error header field. 1269 And finally, to Spencer Dawkins for giving this doc a good scrubbing 1270 to make it more readable. 1272 10. References 1274 10.1 Normative References 1276 [RFC3261] J. Rosenberg, H. Schulzrinne, G. Camarillo, A. Johnston, J. 1277 Peterson, R. Sparks, M. Handley, and E. Schooler, "SIP: 1278 Session Initiation Protocol", RFC 3261, May 2002. 1280 [RFC4119] J. Peterson, "A Presence-based GEOPRIV Location Object 1281 Format", RFC 4119, December 2005 1283 [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate 1284 Requirement Levels", RFC 2119, March 1997 1286 [RFC2392] E. Levinson, "Content-ID and Message-ID Uniform Resource 1287 Locators", RFC 2392, August 1998 1289 [RFC3856] J. Rosenberg, "A Presence Event Package for the Session 1290 Initiation Protocol (SIP)", RFC 3856, August 2004 1292 [RFC3859] J. Peterson, "Common Profile for Presence (CPP)", RFC 3859, 1293 August 2004 1295 [RFC3428] B. Campbell, Ed., J. Rosenberg, H. Schulzrinne, C. Huitema, 1296 D. Gurle, "Session Initiation Protocol (SIP) Extension for 1297 Instant Messaging" , RFC 3428, December 2002 1299 [RFC3311] J. Rosenberg, "The Session Initiation Protocol (SIP) UPDATE 1300 Method", RFC 3311, October 2002 1302 [RFC3265] Roach, A, "Session Initiation Protocol (SIP)-Specific 1303 Event Notification", RFC 3265, June 2002. 1305 [RFC6086] C. Holmberg, E. Burger, H. Kaplan, "Session Initiation 1306 Protocol (SIP) INFO Method and Package Framework", RFC 6086, 1307 January 2011 1309 [RFC3515] R. Sparks, "The Session Initiation Protocol (SIP) Refer 1310 Method", RFC 3515, April 2003 1312 [RFC3903] Niemi, A, "Session Initiation Protocol (SIP) Extension 1313 for Event State Publication", RFC 3903, October 2004. 1315 [RFC5234] Crocker, D., Ed., and P. Overell, "Augmented BNF for Syntax 1316 Specifications: ABNF", STD 68, RFC 5234, January 2008. 1318 [RFC4479] J. Rosenberg, "A Data Model for Presence", RFC 4479, July 1319 2006 1321 [RFC4483] E. Berger, "A Mechanism for Content Indirection in SIP", RFC 1322 4483, May 2006 1324 [RFC5491] J. Winterbottom, M. Thomson, H. Tschofenig, "GEOPRIV PIDF-LO 1325 Usage Clarification, Considerations, and Recommendations ", 1326 RFC 5491, March 2009 1328 [RFC5870] A. Mayrhofer, C. Spanring, "A Uniform Resource Identifier 1329 for Geographic Locations ('geo' URI)", RFC 5870, June 2010 1331 [RFC5606] J. Peterson, T. Hardie, J. Morris, "Implications of 1332 'retransmission-allowed' for SIP Location Conveyance", 1333 RFC5606, Oct 2008 1335 [RFC2616] R. Fielding, J. Gettys, J., Mogul, H. Frystyk, L., 1336 Masinter, P. Leach, T. Berners-Lee, "Hypertext Transfer 1337 Protocol - HTTP/1.1", RFC 2616, June 1999 1339 10.2 Informative References 1341 [RFC3693] J. Cuellar, J. Morris, D. Mulligan, J. Peterson. J. Polk, 1342 "Geopriv Requirements", RFC 3693, February 2004 1344 [RFC2818] E. Rescorla, "HTTP Over TLS", RFC 2818, May 2000 1346 [ID-GEO-FILTERS] R. Mahy, B. Rosen, H. Tschofenig, "Filtering Location 1347 Notifications in SIP", draft-ietf-geopriv-loc-filters, "work 1348 in progress", March 2010 1350 [ID-HELD-DEREF] J. Winterbottom, H. Tschofenig, H. Schulzrinne, M. 1351 Thomson, M. Dawson, "A Location Dereferencing Protocol Using 1352 HELD", "work in progress", December 2010 1354 [ID-GEO-ARCH] R. Barnes, M. Lepinski, A. Cooper, J, Morris, H. 1355 Tschofenig, H. Schulzrinne, "An Architecture for Location 1356 and Location Privacy in Internet Applications", 1357 draft-ietf-geopriv-arch, "work in progress", October 2010 1359 Authors' Addresses 1361 James Polk 1362 Cisco Systems 1363 3913 Treemont Circle 1364 Colleyville, Texas 76034 1366 33.00111N 1367 96.68142W 1369 Phone: +1-817-271-3552 1370 Email: jmpolk@cisco.com 1372 Brian Rosen 1373 NeuStar, Inc. 1374 470 Conrad Dr. 1375 Mars, PA 16046 1377 40.70497N 1378 80.01252W 1380 Phone: +1 724 382 1051 1381 Email: br@brianrosen.net 1383 Jon Peterson 1384 NeuStar, Inc. 1386 Email: jon.peterson@neustar.biz 1388 Appendix A. Requirements for SIP Location Conveyance 1390 The following subsections address the requirements placed on the 1391 UAC, the UAS, as well as SIP proxies when conveying location. If a 1392 requirement is not obvious in intent, a motivational statement is 1393 included below it. 1395 A.1 Requirements for a UAC Conveying Location 1397 UAC-1 The SIP INVITE Method [RFC3261] must support location 1398 conveyance. 1400 UAC-2 The SIP MESSAGE method [RFC3428] must support location 1401 conveyance. 1403 UAC-3 SIP Requests within a dialog should support location 1404 conveyance. 1406 UAC-4 Other SIP Requests may support location conveyance. 1408 UAC-5 There must be one, mandatory to implement means of 1409 transmitting location confidentially. 1411 Motivation: to guarantee interoperability. 1413 UAC-6 It must be possible for a UAC to update location conveyed 1414 at any time in a dialog, including during dialog 1415 establishment. 1417 Motivation: if a UAC has moved prior to the establishment of a 1418 dialog between UAs, the UAC must be able to send location 1419 information. If location has been conveyed, and the UA 1420 moves, the UAC must be able to update the location previously 1421 conveyed to other parties. 1423 UAC-7 The privacy and security rules established within [RFC3693] 1424 that would categorize SIP as a 'Using Protocol' must be met. 1426 UAC-8 The PIDF-LO [RFC4119] is a mandatory to implement format for 1427 location conveyance within SIP. 1429 Motivation: interoperability with other IETF location protocols and 1430 Mechanisms. 1432 UAC-9 There must be a mechanism for the UAC to request the UAS send 1433 its location. 1435 UAC-9 has been DEPRECATED by the SIP WG, due to the many 1436 problems this requirement would have caused if implemented. 1437 The solution is for the above UAS to send a new request to 1438 the original UAC with the UAS's location. 1440 UAC-10 There must be a mechanism to differentiate the ability of the 1441 UAC to convey location from the UACs lack of knowledge of its 1442 location 1444 Motivation: Failure to receive location when it is expected can 1445 happen because the UAC does not implement this extension, or 1446 because the UAC implements the extension, but does not know 1447 where the Target is. This may be, for example, due to the 1448 failure of the access network to provide a location 1449 acquisition mechanism the UAC supports. These cases must be 1450 differentiated. 1452 UAC-11 It must be possible to convey location to proxy servers 1453 along the path. 1455 Motivation: Location-based routing. 1457 A.2 Requirements for a UAS Receiving Location 1459 The following are the requirements for location conveyance by a UAS: 1461 UAS-1 SIP Responses must support location conveyance. 1463 The SIPCORE WG reached consensus that this be allowed, but 1464 not to communicate the UAS's location; rather for a SIP 1465 intermediary to inform the UAC which location to include in 1466 its next SIP request (as a matter of correcting what was 1467 originally sent by the UAC). 1469 UAS-2 There must be a unique 4XX response informing the UAC it did 1470 not provide applicable location information. 1472 In addition, requirements UAC-5, 6, 7 and 8 also apply to the UAS. 1474 A.3 Requirements for SIP Proxies and Intermediaries 1476 The following are the requirements for location conveyance by a SIP 1477 proxies and intermediaries: 1479 Proxy-1 Proxy servers must be capable of adding a Location header 1480 field during processing of SIP requests. 1482 Motivation: Provide network assertion of location 1483 when UACs are unable to do so, or when network assertion is 1484 more reliable than UAC assertion of location 1486 Note: Because UACs connected to SIP signaling networks can have 1487 widely varying access network arrangements, including VPN 1488 tunnels and roaming mechanisms, it can be difficult for a 1489 network to reliably know the location of the endpoint. 1490 Proxies SHOULD NOT assert location of an endpoint unless the 1491 SIP signaling network has reliable knowledge of the actual 1492 location of the Targets. 1494 Proxy-2 There must be a unique 4XX response informing the UAC it 1495 did not provide applicable location information.