idnits 2.17.1 draft-ietf-sipcore-location-conveyance-06.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 29 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 == The "Author's Address" (or "Authors' Addresses") section title is misspelled. == Line 1192 has weird spacing: '...n-Error code...' == The document seems to use 'NOT RECOMMENDED' as an RFC 2119 keyword, but does not include the phrase in its RFC 2119 key words list. == 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 (Feb 23, 2011) is 4811 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) == Missing Reference: 'ID-GEOPRIV-ARCH' is mentioned on line 1020, but not defined == Unused Reference: 'RFC5226' is defined on line 1289, but no explicit reference was found in the text == Unused Reference: 'RFC3264' is defined on line 1295, but no explicit reference was found in the text == Unused Reference: 'ID-GEO-ARCH' is defined on line 1331, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3265 (Obsoleted by RFC 6665) ** Obsolete normative reference: RFC 2976 (Obsoleted by RFC 6086) ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) ** 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: 6 errors (**), 0 flaws (~~), 11 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: August 23, 2011 Brian Rosen 5 Intended Status: Standards Track (PS) Jon Peterson 6 NeuStar 7 Feb 23, 2011 9 Location Conveyance for the Session Initiation Protocol 10 draft-ietf-sipcore-location-conveyance-06.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 August 23, 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 . . . . . . . . . . . . . . . . . 8 82 4.2 The Geolocation-Routing Header . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . 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 . . . . 22 95 8.2 IANA Registration for New SIP Geolocation-Routing Header 22 96 8.3 IANA Registration for New SIP Option Tags . . . . . . . . 23 97 8.4 IANA Registration for New 424 Response Code . . . . . . . 23 98 8.5 IANA Registration for New SIP Geolocation-Error Header . 24 99 8.6 IANA Registration for New SIP Geolocation-Error Codes . . 24 100 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 24 101 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 25 102 10.1 Normative References . . . . . . . . . . . . . . . . . 25 103 10.2 Informative References . . . . . . . . . . . . . . . . . 26 104 Author Information . . . . . . . . . . . . . . . . . . . . . 27 105 Appendix A. Requirements for SIP Location Conveyance . . . . 27 107 1. Conventions and Terminology used in this document 109 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 110 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and 111 "OPTIONAL" in this document are to be interpreted as described 112 in [RFC2119]. This document furthermore uses numerous terms defined 113 in RFC 3693 [RFC3693], including Location Object, Location 114 Recipient, Location Server, Target, and Using Protocol. 116 2. Introduction 118 Session Initiation Protocol (SIP) [RFC3261] creates, modifies and 119 terminates multimedia sessions. SIP carries certain information 120 related to a session while establishing or maintaining calls. This 121 document defines how SIP conveys geographic location information of 122 a Target (Target) to a Location Recipient (LR). SIP acts as a Using 123 Protocol of location information, as defined in RFC 3693. 125 In order to convey location information, this document specifies a 126 new SIP header, the Geolocation header, which carries a reference to 127 a Location Object. That Location Object may appear in a MIME body 128 attached to the SIP request, or it may be a remote resource in the 129 network. 131 Note that per RFC 3693, a Target is an entity whose location is 132 being conveyed. Thus, a Target could be a SIP user agent (UA), some 133 other IP device (a router or a PC) that does not have a SIP stack, a 134 non-IP device (a person or a black phone) or even a 135 non-communications device (a building or store front). In no way 136 does this document assume that the SIP user agent client which sends 137 a request containing a location object is necessarily the Target. 138 The location of a Target conveyed within SIP typically corresponds 139 to that of a device controlled by the Target, for example, a mobile 140 phone, but such devices can be separated from their owners, and 141 moreover, in some cases the user agent may not know its own 142 location. 144 In the SIP context, a location recipient will most likely be a SIP 145 UA, but due to the mediated nature of SIP architectures, location 146 information conveyed by a single SIP request may have multiple 147 recipients, as any SIP proxy server in the signaling path that 148 inspects the location of the Target must also be considered a 149 Location Recipient. In presence-like architectures, an intermediary 150 that receives publications of location information and distributes 151 them to watchers acts as a Location Server per RFC 3693. This 152 location conveyance mechanism can also be used to deliver URIs 153 pointing to such Location Servers where prospective Location 154 Recipients can request Location Objects. 156 3. Overview of SIP Location Conveyance 158 An operational overview of SIP location conveyance can be shown in 4 159 basic diagrams, with most applications falling under one of the 160 following basic use cases. Each is separated into its own subsection 161 here in section 3. 163 Each diagram has Alice and Bob as UAs. Alice is the Target, and Bob 164 is an LR. A SIP intermediary appears in some of the diagrams. Any 165 SIP entity that receives and inspects location information is an LR, 166 therefore any of the diagrams the SIP intermediary receives the SIP 167 request is potentially an LR - though that does not mean such an 168 intermediary necessarily has to route the SIP request based on the 169 location information. In some use cases, location information 170 passes through the LS on the right of each diagram. 172 3.1 Location Conveyed by Value 174 We start with the simplest diagram of Location Conveyance, Alice to 175 Bob, where no other layer 7 entities are involved. 177 Alice SIP Intermediary Bob LS 178 | | | | 179 | Request w/Location | | 180 |----------------------------------->| | 181 | | | 182 | Response | | 183 |<-----------------------------------| | 184 | | | | 186 Figure 1. Location Conveyed by Value 188 In Figure 1, Alice is both the Target and the LS that is conveying 189 her location directly to Bob, who acts as an LR. This conveyance is 190 point-to-point - it does not pass through any SIP-layer 191 intermediary. A Location Object appears by-value in the initial SIP 192 request as a MIME body, and Bob responds to that SIP request as 193 appropriate. There is a 'Bad Location Information' response code 194 introduced within this document to specifically inform Alice if she 195 conveys bad location to Bob (e.g., Bob "cannot parse the location 196 provided", or "there is not enough location information to determine 197 where Alice is"). 199 3.2 Location Conveyed as a Location URI 201 Here we make Figure 1 a little more complicated by showing a 202 diagram of indirect Location Conveyance from Alice to Bob, where 203 Bob's entity has to retrieve the location object from a 3rd party 204 server. 206 Alice SIP Intermediary Bob LS 207 | | | | 208 | Request w/Location URI | | 209 |----------------------------------->| | 210 | | Dereference | 211 | | Request | 212 | (To: Location URI) | 213 | |---------------->| 214 | | | 215 | | Dereference | 216 | | Response | 217 | (includes location) | 218 | |<----------------| 219 | Response | | 220 |<-----------------------------------| | 221 | | | | 223 Figure 2. Location Conveyed as a Location URI 225 In Figure 2, location is conveyed indirectly, via a Location URI 226 carried in the SIP request (more of those details later). If Alice 227 sends Bob this Location URI, Bob will need to dereference the URI - 228 analogous to Content Indirection [RFC4483] - in order to request the 229 location information. In general, the LS provides the location value 230 to Bob instead of Alice directly for conveyance to Bob. From a user 231 interface perspective, Bob the user won't know that this information 232 was gathered from an LS indirectly rather than culled from the SIP 233 request, and practically this does not impact the operation of 234 location-based applications. 236 The example given in this section is only illustrative, not 237 normative. In particular, applications can choose to dereference a 238 location URI at any time, possibly several times, or potentially not 239 at all. Applications receiving a Location URI in a SIP transaction 240 need to be mindful of timers used by different transactions. In 241 particular, if the means of dereferencing the Location URI might 242 take longer than the SIP transaction timeout (Timer C for INVITE 243 transactions, Timer F for non-INVITE transactions), then it needs to 244 rely on mechanisms other than the transaction's response code to 245 convey location errors, if returning such errors are necessary. 247 3.3 Location Conveyed though a SIP Intermediary 249 In Figure 3, we introduce the idea of a SIP intermediary into the 250 example to illustrate the role of proxying in the location 251 architecture. This intermediary can be a SIP proxy or it can be 252 a back-to-back-user-agent (B2BUA). In this message flow, the SIP 253 intermediary could act as a LR, in addition to Bob. The primary use 254 case for intermediaries consuming location information is 255 location-based routing. In this case, the intermediary chooses a 256 next hop for the SIP request by consulting a specialized location 257 service which selects forwarding destinations based on geographical 258 location. 260 Alice SIP Intermediary Bob LS 261 | | | | 262 | Request | | | 263 | w/Location | | | 264 |--------------->| | | 265 | | Request | | 266 | | w/Location | | 267 | |------------------>| | 268 | | | | 269 | | Response | | 270 | |<------------------| | 271 | Response | | | 272 |<---------------| | | 273 | | | | 275 Figure 3. Location Conveyed though a SIP Intermediary 277 However, the most common case will be one in which the SIP 278 intermediary receives a request with location information (conveyed 279 either by-value or by-reference) and does not know or care about 280 Alice's location, or support this extension, and merely passes it on 281 to Bob. In this case, the intermediary does not act as a Location 282 Recipient. When the intermediary is not an LR, this use case is the 283 same as the one described in Section 3.1. 285 Note that an intermediary does not have to perform location-based 286 routing in order to be location recipient. It could be the case that 287 a SIP intermediary which does not perform location-based routing but 288 does care when Alice includes her location; for example, it could 289 care that the location information is complete or that it correctly 290 identifies where Alice is. The best example of this is 291 intermediaries that verify location information for emergency 292 calling, but it could also be for any location based routing - e.g., 293 contacting Pizza Hut, making sure that organization has Alice's 294 proper location in the initial SIP request. 296 There is another scenario in which the SIP intermediary cares about 297 location and is not an LR, one in which the intermediary inserts 298 another location of the Target, Alice in this case, into the 299 request, and forwards it. This secondary insertion is generally not 300 advisable because downstream SIP entities will not be given any 301 guidance about which location to believe is better, more reliable, 302 less prone to error, more granular, worse than the other location or 303 just plain wrong. 305 The only conceivable way forward, when a second location is placed 306 into the same SIP request by a SIP intermediary is to 307 take a "you break it, you bought it" philosophy with respect to the 308 inserting SIP intermediary. That entity becomes completely 309 responsible for all location within that SIP request (more on this 310 in Section 4). 312 3.4 SIP Intermediary Replacing Bad Location 314 If the SIP intermediary rejects the message due to unsuitable 315 location information (we are not going to discuss any other reasons 316 in this document, and there are many), the SIP response will 317 indicate there was 'Bad Location Information' in the SIP request, 318 and provide a location specific error code indicating what Alice 319 needs to do to send an acceptable request (see Figure 4 for this 320 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 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 sip-URI, sips-URI and absoluteURI are defined according to [RFC3261]. 393 The pres-URI is defined in [RFC3859]. 395 HTTP-URI and HTTPS-URI are defined according to [RFC2616] and 396 [RFC2818], respectively. 398 The cid-url is defined in [RFC2392] to locate message body parts. 399 This URI type is present in a SIP request when location is conveyed 400 as a MIME body in the SIP message. 402 GEO-URIs [RFC5870] are not appropriate for usage in the SIP 403 Geolocation header. 405 Other URI schemas used in the location URI MUST be reviewed against 406 the RFC 3693 [RFC3693] criteria for a Using Protocol. 408 The generic-param in the definition of locationValue is included as 409 a mechanism for future extensions that might require parameters. 410 This document defines no parameters for use with locationValue. If a 411 Geolocation header field is received that contains generic-params, 412 each SHOULD be ignored, and SHOULD NOT be removed when forwarding 413 the locationValue. If a need arises to define parameters for use 414 with locationValue, a revision/extension to this document is 415 required. 417 The Geolocation header field can have one or more locationValues. A 418 Geolocation header field MUST have at least one header-value. A 419 SIP intermediary SHOULD NOT add location to a SIP request that 420 already contains location. This will quite often lead to confusion 421 within LRs. However, if a SIP intermediary adds location, even if 422 location was not previously present in a SIP request, that SIP 423 intermediary is fully responsible for addressing the concerns of any 424 424 (Bad Location Information) SIP response it receives about this 425 location addition, and MUST NOT pass on (upstream) the 424 response. 426 Additionally, the first SIP intermediary to add a locationValue adds 427 it as the last locationValue in the header value. A SIP intermediary 428 that adds a locationValue MUST position it as the last locationValue 429 of the last Geolocation header field of the message. 431 This document defines the Geolocation header field as valid in the 432 following SIP requests: 434 INVITE [RFC3261], REGISTER [RFC3261], 435 OPTIONS [RFC3261], BYE [RFC3261], 436 UPDATE [RFC3311], INFO [RFC2976], 437 MESSAGE [RFC3428], REFER [RFC3515], 438 SUBSCRIBE [RFC3265], NOTIFY [RFC3265], 439 PUBLISH [RFC3903], PRACK [RFC3262] 441 The Geolocation header field MAY be included in any one of the 442 above listed requests by a UA, and a 424 response to any one of the 443 requests sent above. Fully appreciating the caveats/warnings 444 mentioned above, a SIP intermediary MAY add the Geolocation header 445 field. 447 A SIP intermediary MAY add a Geolocation header field if one is not 448 present - for example, when a user agent does not support the 449 Geolocation mechanism but their outbound proxy does and knows the 450 Target's location, or any of a number of other use cases (see 451 Section 3). 453 The Geolocation header field MAY be present in a SIP request or 454 response without the presence of a Geolocation-Routing header 455 (defined in Section 4.2). As stated in Section 4.2, the default 456 value of Geolocation-Routing header-value is "no", meaning SIP 457 intermediaries are not to view any direct or indirect location 458 within this SIP message. 460 Any locationValue MUST be related to the original Target. This is 461 equally true the location information in a SIP response, i.e., from 462 a SIP intermediary back to the Target explained in Section 3.4. 464 SIP intermediaries are NOT RECOMMENDED to modify existing 465 locationValue(s), and further not to delete any either. 467 4.2 The Geolocation-Routing Header 469 This document defines "Geolocation-Routing" as a new SIP header 470 field registered by IANA, with the following ABNF [RFC5234]: 472 message-header /= Georouting-header ; (message-header from 3261) 473 Georouting-header = "Geolocation-Routing" HCOLON 474 ( "yes" / "no" / generic-value ) 476 The only defined values for the Geolocation-Routing header field are 477 "yes" or "no". When the value is "yes", the locationValue can be 478 used for routing decisions along the downstream signaling path by 479 intermediaries. Values other than "yes" or "no" are permitted as a 480 mechanism for future extensions, and should be treated the same as 481 "no". 483 If no Geolocation-Routing header field is present in a SIP request, 484 a SIP intermediary MAY insert this header field with a RECOMMENDED 485 value of "no" by default. 487 When this Geolocation-Routing header-value is set to "no", this 488 means no locationValue (inserted by the originating UAC or any 489 intermediary along the signaling path) can be used by any SIP 490 intermediary to make routing decisions. Intermediaries that attempt 491 to use the location information for routing purposes in spite of 492 this counter indication could end up routing the request improperly 493 as a result. Section 4.4 describes the details on what a routing 494 intermediary does if it determines it needs to use the location in 495 the SIP request in order to process the message further. The 496 practical implication is that when the Geolocation-Routing 497 header-value is set to "no", if a cid:url is present in the SIP 498 request, intermediaries SHOULD NOT view the location (because it is 499 not for intermediaries to view), and if a location URI is present, 500 intermediaries SHOULD NOT dereference it. UAs are allowed to view 501 location in the SIP request even when the Geolocation-Routing 502 header-value is set to "no". An LR MUST by default consider the 503 Geolocation-Routing header-value as set to "no", with no exceptions, 504 unless the header field value is set to "yes". 506 A Geolocation-Routing header-value is set to "no" has no special 507 security properties, this is at most a request for behavior within 508 SIP intermediaries. That said, if the Geolocation-Routing 509 header-value is set to "no", SIP intermediaries are still to 510 process the SIP request and send it further downstream within the 511 signaling path if there are no errors present in this SIP request. 513 The Geolocation-Routing header field satisfies the recommendations 514 made in section 3.5 of RFC 5606 [RFC5606] regarding indication of 515 permission to use location-based routing in SIP. 517 SIP implementations are advised to pay special attention to the 518 policy elements for location retransmission and retention described 519 in RFC 4119. 521 The Geolocation-Routing header field cannot appear without a 522 header-value in a SIP request or response (i.e., a null value is not 523 allowed). The absence of a Geolocation-Routing header-value in a SIP 524 request is always the same as the following header field: 526 Geolocation-Routing: no 528 The Geolocation-Routing header field MAY be present without a 529 Geolocation header field in the same SIP request. This concept is 530 further explored in Section 4.2.1. 532 4.2.1 Explaining Geolocation-Routing header-value States 534 The Geolocation header field contains a Target's location, and MUST 535 NOT be present if there is no location information in this SIP 536 request. The location information is contained in a one or more 537 locationValues. These locationValues MAY be contained in a single 538 Geolocation header field, or distributed among multiple Geolocation 539 header fields. (See section 7.3.1 of RFC3261.) 541 The Geolocation-Routing header field indicates whether or not SIP 542 intermediaries can view and then route this SIP request based on the 543 included (directly or indirectly) location information. The 544 Geolocation-Routing header field MUST NOT appear more than once in 545 any SIP request, and MUST NOT lack a header-value. The default or 546 implied policy of a SIP request that does not have a 547 Geolocation-Routing header field is the same as if one were present 548 and the header-value were set to "no". 550 There are only 3 possible states regarding the Geolocation-Routing 551 header field 553 - "no" 554 - "yes" 555 - no header-field present in this SIP request 557 The expected results in each state are: 559 If the Geolocation-Routing Only possible interpretations: 560 -------------------------- ----------------------------- 561 "no" Location viewing policy set already 562 such that no intermediaries can view 563 location inserted downstream. 565 SIP intermediaries inserting a 566 locationValue into a Geolocation 567 header field (whether adding to an 568 existing header-value or inserting the 569 Geolocation header field for the first 570 time) MUST NOT modify or delete the 571 received "no" header-value. 573 "yes" Location viewing policy set already 574 such that if location is inserted 575 downstream, intermediaries can 576 maintain an open viewing of location 577 policy or can change policy to "no" 578 for intermediaries further downstream. 580 Geolocation-Routing absent If a Geolocation header field exists 581 (meaning a locationValue is already 582 present), MUST interpret the lack of a 583 Geolocation-Routing header field by 584 default as if there were one present 585 and the header-value is set to "no". 587 If there is no Geolocation header 588 field in this SIP request, the default 589 Geolocation-Routing is open and can be 590 set by a downstream entity or not at 591 all. 593 4.3 424 (Bad Location Information) Response Code 595 This SIP extension creates a new location-specific response code, 596 defined as follows, 598 424 (Bad Location Information) 600 The 424 (Bad Location Information) response code is a rejection of 601 the request due to its location contents, indicating location 602 information that was malformed or not satisfactory for the 603 recipient's purpose, or could not be dereferenced. 605 A SIP intermediary can also reject a location it receives from a 606 Target when it understands the Target to be in a different location. 607 The proper handling of this scenario, described in Section 3.4, is 608 for the SIP intermediary to include the proper location in the 424 609 Response. This SHOULD be included in the response as a MIME message 610 body (i.e., a location value), rather than as a URI; however, in 611 cases where the intermediary is willing to share location with 612 recipients but not with a user agent, a reference might be 613 necessary. 615 As mentioned in Section 3.4, it might be the case that the 616 intermediary does not want to chance providing less accurate 617 location information than the user agent; thus it will compose its 618 understanding of where the user agent is in a separate 619 element of the same PIDF-LO message body in the SIP response (which 620 also contains the Target's version of where it is). Therefore, both 621 locations are included - each with different elements. The 622 proper reaction of the user agent is to generate a new SIP request 623 that includes this composed location object, and send it towards the 624 original LR. SIP intermediaries can verify that subsequent requests 625 properly insert the suggested location information before forwarding 626 said requests. 628 SIP intermediaries MUST NOT add, modify or delete the location in a 629 424 response. This specifically applies to intermediaries that are 630 between the 424 response generator and the original UAC. Geolocation 631 and Geolocation-Error header fields and PIDF-LO body parts MUST 632 remain unchanged, never added to or deleted. 634 Section 4.4 describes a Geolocation-Error header field to provide 635 more detail about what was wrong with the location information in 636 the request. This header field MUST be included in the 424 response. 638 It is only appropriate to generate a 424 response when the 639 responding entity needs a locationValue and there are no 640 locationValues included in the SIP request that are usable by that 641 recipient, or as shown in Figure 4 of section 3.4. In the latter 642 scenario, a SIP intermediary is informing the upstream UA which 643 location to include in the next SIP request. 645 A 424 MUST NOT be sent in response to a request that lacks a 646 Geolocation header entirely, as the user agent in that case may not 647 support this extension at all. If a SIP intermediary inserted a 648 locationValue into a SIP request where one was not previously 649 present, it MUST take any and all responsibility for the corrective 650 action if it receives a 424 to a SIP request it sent. 652 A 424 (Bad Location Information) response is a final response within 653 a transaction, and MUST NOT terminate an existing dialog. 655 4.4 The Geolocation-Error Header 657 As discussed in Section 4.3, more granular error notifications 658 specific to location errors within a received request are required 659 if the location inserting entity is to know what was wrong within 660 the original request. The Geolocation-Error header field is used for 661 this purpose. 663 The Geolocation-Error header field is used to convey 664 location-specific errors within a response. The Geolocation-Error 665 header field has the following ABNF [RFC5234]: 667 message-header /= Geolocation-Error-header ; 668 (message-header from 3261) 669 Geolocation-Error = "Geolocation-Error" HCOLON 670 locationErrorValue 671 locationErrorValue = location-error-code 672 *(SEMI location-error-params) 673 location-error-code = 1*3DIGIT 674 location-error-params = location-error-code-text 675 / generic-param ; from RFC3261 676 location-error-code-text = "code" EQUAL quoted-string ; from RFC3261 678 The Geolocation-Error header field MUST contain only one 679 locationErrorValue to indicate what was wrong with the locationValue 680 the Location Recipient determined was bad. The locationErrorValue 681 contains a 3-digit error code indicating what was wrong with the 682 location in the request. This error code has a corresponding quoted 683 error text string that is human understandable. This text string is 684 OPTIONAL, but RECOMMENDED for human readability. 686 The Geolocation-Error header field MAY be included in any response 687 to one of the SIP Methods mentioned in Section 4.1, so long as a 688 locationValue was in the request part of the same transaction. For 689 example, Alice includes her location in an INVITE to Bob. Bob can 690 accept this INVITE, thus creating a dialog, even though his UA 691 determined the location contained in the INVITE was bad. Bob merely 692 includes a Geolocation-Error header value in the 200 OK to the 693 INVITE informing Alice the INVITE was accepted but the location 694 provided was bad. 696 If, on the other hand, Bob cannot accept Alice's INVITE without a 697 suitable location, a 424 (Bad Location Information) is sent. This 698 message flow is shown in Figures 1, 2 or 3 in Sections 3.1, 3.2 and 699 3.3 respectively. 701 A SIP intermediary that requires Alice's location in order to 702 properly process Alice's INVITE also sends a 424 with a 703 Geolocation-Error code. This message flow is shown in Figure 4 of 704 Section 3.4. 706 If more than one locationValue is present in a SIP request and at 707 least one locationValue is determined to be valid by the LR, the 708 location in that SIP request MUST be considered good as far as 709 location is concerned, and no Geolocation-Error is sent. This is a 710 compromise of complexity vs. accurate information conveyance with 711 respect to informing each location inserter of every bad location. 713 Here is an initial list of location based error code ranges for any 714 SIP non-100 response, including the new 424 (Bad Location 715 Information) response. These error codes are divided into 3 716 categories, based on how the response receiver should react to these 717 errors. There MUST be no more than one Geolocation-Error code in a 718 SIP response, regardless of how many locationValues there are in the 719 correlating SIP request. There is no guidance given in this document 720 as to which locationValue, when more than one was present in the SIP 721 request, is related to the Geolocation-Error code; meaning that, 722 somehow not defined here, the LR just picks one to error. 724 o 1XX errors mean the LR cannot process the location within the 725 request 727 A non-exclusive list of reasons for returning a 1XX is 729 - the location was not present or could not be found, 730 - there was not enough location information to determine 731 where the Target was, 732 - the location information was corrupted or known to be 733 inaccurate, 734 - etc... 736 o 2XX errors mean some specific permission is necessary to process 737 the included location information. 739 o 3XX errors mean there was trouble dereferencing the Location URI 740 sent. 742 It should be noted that for non-INVITE transactions, the SIP 743 response will likely be sent before the dereference response has 744 been received. At this time, this document does not alter that SIP 745 protocol reality. This means the receiver of any non-INVITE response 746 to a request containing location SHOULD NOT consider a 200 OK to 747 mean the act of dereferencing has concluded and the dereferencer 748 (i.e., the LR) has successfully received and parsed the PIDF-LO for 749 errors and found none. This was first brought up in Section 3.2. 751 Additionally, if a SIP entity cannot or chooses not to process 752 location or the SIP request containing location, the existing 753 mechanism of responding with a 503 (Service Unavailable) SHOULD be 754 used with or without a configurable Retry-After header field. There 755 is no special location error code for what already exists within SIP 756 today. 758 Within each of these ranges, there is a top level error as follows: 760 Geolocation-Error: 100 "Cannot Process Location" 762 Geolocation-Error: 200 "Permission To Use Location Information" 764 Geolocation-Error: 300 "Dereference Failure" 765 There are two specific Geolocation-Error codes necessary to include 766 in this document, both have to do with permissions necessary to 767 process the SIP request; they are 769 Geolocation-Error: 201 "Permission To Retransmit Location 770 Information to a Third Party" 772 This location error is specific to having the Presence Information 773 Data Format (PIDF-LO) [RFC4119] element set 774 to "no". This location error is stating it requires permission 775 (i.e., PIDF-LO element set to "yes") to 776 process this SIP request further. If the LS sending the location 777 information does not want to give this permission, it will not reset 778 this permission in a new request. If the LS wants this message 779 processed without this permission reset, it MUST choose another 780 logical path (if one exists) for this SIP request. 782 Geolocation-Error: 202 "Permission to Route based on Location 783 Information" 785 This location error is specific to having the Geolocation-Routing 786 header value set to "no". This location error is stating it requires 787 permission (i.e., the Geolocation-Routing header value set to "yes") 788 to process this SIP request further. If the LS sending the location 789 information does not want to give this permission, it will not reset 790 this permission in a new request. If the LS wants this message 791 processed without this permission reset, it MUST choose another 792 logical path (if one exists) for this SIP request. 794 4.5 Location URIs in Message Bodies 796 In the case where an LR sends a 424 response and wishes to 797 communicate suitable location by reference rather than by value, the 798 424 MUST include a content-indirection body per RFC 4483. 800 4.6 Location Profile Negotiation 802 The following is part of the discussion started in Section 3, Figure 803 2, which introduced the concept of sending location indirectly. 805 If a location URI is included in a SIP request, the sending user 806 agent MUST also include a Supported header field indicating which 807 location profiles it supports. Two option tags for location profiles 808 are defined by this document: "geolocation-sip" and 809 "geolocation-http". Future specifications may define further 810 location profiles per the IANA policy described in Section 8.3. 812 The "geolocation-sip" option tag signals support for acquiring 813 location information via the presence event package of SIP 814 ([RFC3856]). A location recipient who supports this option can send 815 a SUBSCRIBE request and parse a resulting NOTIFY containing a 816 PIDF-LO object. The URI schemes supported by this option include 817 "sip", "sips" and "pres". 819 The "geolocation-http" option tag signals support for acquiring 820 location information via an HTTP ([RFC2616]). A location recipient 821 who supports this option can request location with an HTTP GET and 822 parse a resulting 200 response containing a PIDF-LO object. The URI 823 schemes supported by this option include "http" and "https". A 824 failure to parse the 200 response, for whatever reason, will return 825 a "Dereference Failure" indication to the original location sending 826 user agent to inform it that location was not delivered as intended. 828 See [ID-GEO-FILTERS] or [ID-HELD-DEREF] for more details on 829 dereferencing location information. 831 5. Geolocation Examples 833 5.1 Location-by-value (in Coordinate Format) 835 This example shows an INVITE message with a coordinate location. In 836 this example, the SIP request uses a sips-URI [RFC3261], meaning 837 this message is protected using TLS on a hop-by-hop basis. 839 INVITE sips:bob@biloxi.example.com SIP/2.0 840 Via: SIPS/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bK74bf9 841 Max-Forwards: 70 842 To: Bob 843 From: Alice ;tag=9fxced76sl 844 Call-ID: 3848276298220188511@atlanta.example.com 845 Geolocation: 846 Geolocation-Routing: no 847 Supported: geolocation 848 Accept: application/sdp, application/pidf+xml 849 CSeq: 31862 INVITE 850 Contact: 851 Content-Type: multipart/mixed; boundary=boundary1 852 Content-Length: ... 854 --boundary1 856 Content-Type: application/sdp 858 ...SDP goes here 860 --boundary1 862 Content-Type: application/pidf+xml 863 Content-ID: 864 865 873 874 875 876 877 878 32.86726 -97.16054 879 880 881 882 883 false 884 885 2010-11-14T20:00:00Z 886 887 888 802.11 889 890 mac:1234567890ab 891 2010-11-04T20:57:29Z 892 893 894 --boundary1-- 896 The Geolocation header field from the above INVITE: 898 Geolocation: 900 ... indicates the content-ID location [RFC2392] within the multipart 901 message body of where location information is. The other message 902 body part is SDP. The "cid:" eases message body parsing and 903 disambiguates multiple parts of the same type. 905 If the Geolocation header field did not contain a "cid:" scheme, for 906 example, it could look like this location URI: 908 Geolocation: 910 ... the existence of a non-"cid:" scheme indicates this is a 911 location URI, to be dereferenced to learn the Target's location. Any 912 node wanting to know where the target is located would subscribe to 913 the SIP presence event package [RFC3856] at 915 sips:target123@server5.atlanta.example.com 917 (see Figure 2 in Section 3.2 for this message flow). 919 5.2 Two Locations Composed in Same Location Object Example 921 This example shows the INVITE message after a SIP intermediary 922 rejected the original INVITE (say, the one in section 5.1). This 923 INVITE contains the composed LO sent by the SIP intermediary which 924 includes where the intermediary understands Alice to be. The rules 925 of RFC 5491 [RFC5491] are followed in this construction. 927 This example is here, but ought not be taken as occurring very 928 often. In fact, this example is believed to be a corner case of 929 location conveyance applicability. 931 INVITE sips:bob@biloxi.example.com SIP/2.0 932 Via: SIPS/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bK74bf0 933 Max-Forwards: 70 934 To: Bob 935 From: Alice ;tag=9fxced76sl 936 Call-ID: 3848276298220188512@atlanta.example.com 937 Geolocation: 938 Geolocation-Routing: no 939 Supported: geolocation 940 Accept: application/sdp, application/pidf+xml 941 CSeq: 31863 INVITE 942 Contact: 943 Content-Type: multipart/mixed; boundary=boundary1 944 Content-Length: ... 946 --boundary1 948 Content-Type: application/sdp 950 ...SDP goes here 952 --boundary1 954 Content-Type: application/pidf+xml 955 Content-ID: 956 957 965 966 967 968 969 970 32.86726 -97.16054 972 973 974 975 976 false 977 978 2010-11-14T20:00:00Z 979 980 981 802.11 982 983 mac:1234567890ab 984 2010-11-04T20:57:29Z 985 986 987 988 989 990 US 991 Texas 992 Colleyville 993 Treemont 994 Circle 995 3913 996 1 997 Haley's Place 998 76034 999 1000 1001 1002 false 1003 1004 2010-11-14T20:00:00Z 1005 1006 1007 triangulation 1008 1009 2010-11-04T12:28:04Z 1010 1011 1012 --boundary1-- 1014 6. Geopriv Privacy Considerations 1016 Location information is considered by most to be highly sensitive 1017 information, requiring protection from eavesdropping and altering in 1018 transit. [RFC3693] originally articulated rules to be followed by 1019 any protocol wishing to be considered a "Using Protocol", specifying 1020 how a transport protocol meets those rules. [ID-GEOPRIV-ARCH] 1021 updates the guidance in RFC3693 to include subsequently-introduced 1022 entities and concepts in the geolocation architecture. 1024 Implementations of this SIP location conveyance mechanism MUST 1025 adhere to the guidance given in RFC3693 and its updates and/or 1026 successors, including (but not limited to) the handling of rules for 1027 retention and retransmission. 1029 7. Security Considerations 1031 Conveyance of physical location of a UA raises privacy concerns, 1032 and depending on use, there probably will be authentication and 1033 integrity concerns. This document calls for conveyance to 1034 be accomplished through secure mechanisms, like S/MIME encrypting 1035 message bodies (although this is not widely deployed), TLS 1036 protecting the overall signaling or conveyance location by-reference 1037 and requiring all entities that dereference location to authenticate 1038 themselves. In location-based routing cases, encrypting the 1039 location payload with an end-to-end mechanism such as S/MIME is 1040 problematic, because one or more proxies on the path need the 1041 ability to read the location information to retarget the message to 1042 the appropriate new destination UAS. Data can only be encrypted to a 1043 particular, anticipated target, and thus if multiple recipients need 1044 to inspect a piece of data, and those recipients cannot be predicted 1045 by the sender of data, encryption is not a very feasible choice. 1046 Securing the location hop-by-hop, using TLS, protects the message 1047 from eavesdropping and modification in transit, but exposes the 1048 information to all proxies on the path as well as the endpoint. In 1049 most cases, the UA has no trust relationship with the proxy or 1050 proxies providing location-based routing services, so such 1051 end-to-middle solutions might not be appropriate either. 1053 When location information is conveyed by reference, however, one can 1054 properly authenticate and authorize each entity that wishes to 1055 inspect location information. This does not require that the sender 1056 of data anticipate who will receive data, and it does permit 1057 multiple entities to receive it securely, but it does not however 1058 obviate the need for pre-association between the sender of data and 1059 any prospective recipients. Obviously, in some contexts this 1060 pre-association cannot be presumed; when it is not, effectively 1061 unauthenticated access to location information must be permitted. In 1062 this case, choosing pseudo-random URIs for location by-reference, 1063 coupled with path encryption like SIPS, can help to ensure that only 1064 entities on the SIP signaling path learn the URI, and thus restores 1065 rough parity with sending location by-value. 1067 Location information is especially sensitive when the identity of 1068 its Target is obvious. Note that there is the ability, according to 1069 [RFC3693] to have an anonymous identity for the Target's location. 1070 This is accomplished by use of an unlinkable pseudonym in the 1071 "entity=" attribute of the element [RFC4479]. Though, 1072 this can be problematic for routing messages based on location 1073 (covered in the document above). Moreover, anyone fishing for 1074 information would correlate the identity at the SIP layer with that 1075 of the location information referenced by SIP signaling. 1077 When a UA inserts location, the UA sets the policy on whether to 1078 reveal its location along the signaling path - as discussed in 1079 Section 4, as well as flags in the PIDF-LO [RFC4119]. UAC 1080 implementations MUST make such capabilities conditional on explicit 1081 user permission, and MUST alert the user that location is being 1082 conveyed. 1084 This SIP extension offers the default ability to require permission 1085 to view location while the SIP request is in transit. The default 1086 for this is set to "no". There is an error explicitly describing 1087 how an intermediary asks for permission to view the Target's 1088 location, plus a rule stating the user has to be made aware of this 1089 permission request. 1091 There is no end-to-end integrity on any locationValue or 1092 locationErrorValue header field parameter (or middle-to-end if the 1093 value was inserted by a intermediary), so recipients of either 1094 header field need to implicitly trust the header field contents, and 1095 take whatever precautions each entity deems appropriate given this 1096 situation. 1098 8. IANA Considerations 1100 The following are the IANA considerations made by this SIP 1101 extension. Modifications and additions to all these registrations 1102 require a standards track RFC (Standards Action). 1104 [Editor's Note: RFC-Editor - within the IANA section, please 1105 replace "this doc" with the assigned RFC number, 1106 if this document reaches publication.] 1108 8.1 IANA Registration for the SIP Geolocation Header Field 1110 The SIP Geolocation Header Field is created by this document, with 1111 its definition and rules in Section 4.1 of this document, and should 1112 be added to the IANA sip-parameters registry with two actions 1114 1. Update the Header Fields registry with 1116 Registry: 1117 Header Name compact Reference 1118 ----------------- ------- --------- 1119 Geolocation [this doc] 1121 8.2 IANA Registration for the SIP Geolocation Header Field 1123 The SIP Geolocation-Routing Header Field is created by this document, 1124 with its definition and rules in Section 4.2 of this document, and 1125 should be added to the IANA sip-parameters registry with the 1126 following action 1128 1. Update the Header Fields registry with 1130 Registry: 1131 Header Name compact Reference 1132 ----------------- ------- --------- 1133 Geolocation-Routing [this doc] 1135 8.3 IANA Registration for Location Profiles 1137 This document defines two new SIP option tags: "geolocation-sip" and 1138 "geolocation-http." with the definition and rule in Section 4.6 of 1139 this document, to be added to the IANA sip-parameters Options Tags 1140 registry. 1142 Name Valid Scheme(S) Reference 1143 geolocation-sip See 4.6 [this doc] 1144 geolocation-http See 4.6 [this doc] 1146 The names of profiles are SIP option-tags, and the guidance in this 1147 document does not supersede the option-tag assignment guidance in 1148 [RFC3261] (which requires a Standards Action for the assignment of a 1149 new option tag). This document does however stipulate that 1150 option-tags included to convey the name of a location profile per 1151 this definition MUST begin with the string "geolocation" followed by 1152 a dash. All such option tags should describe protocols used to 1153 acquire location by reference: these tags have no relevance to 1154 location carried in SIP requests by value, which use standard MIME 1155 typing and negotiation. 1157 8.4 IANA Registration for 424 Response Code 1159 In the SIP Response Codes registry, the following is added 1161 Reference: RFC-XXXX (i.e., this document) 1162 Response code: 424 (recommended number to assign) 1163 Default reason phrase: Bad Location Information 1165 Registry: 1166 Response Code Reference 1167 ------------------------------------------ --------- 1168 Request Failure 4xx 1169 424 Bad Location Information [this doc] 1171 This SIP Response code is defined in section 4.3 of this document. 1173 8.5 IANA Registration of New Geolocation-Error Header Field 1175 The SIP Geolocation-error header field is created by this document, 1176 with its definition and rules in Section 4.4 of this document, to be 1177 added to the IANA sip-parameters registry with two actions 1179 1. Update the Header Fields registry with 1181 Registry: 1182 Header Name compact Reference 1183 ----------------- ------- --------- 1184 Geolocation-Error [this doc] 1186 2. In the portion titled "Header Field Parameters and Parameter 1187 Values", add 1189 Predefined 1190 Header Field Parameter Name Values Reference 1191 ----------------- ------------------- ---------- --------- 1192 Geolocation-Error code= yes* [this doc] 1194 * see section 8.6 for the newly created values. 1196 8.6 IANA Registration for the SIP Geolocation-Error Codes 1198 New location specific Geolocation-Error codes are created by this 1199 document, and registered in a new table in the IANA sip-parameters 1200 registry. Details of these error codes are in Section 4.4 of this 1201 document. 1203 Geolocation-Error codes 1204 ----------------------- 1205 Geolocation-Error codes provide reason for the error discovered by 1206 Location Recipients, categorized by action to be taken by error 1207 recipient. 1209 Code Description Reference 1210 ---- --------------------------------------------------- --------- 1211 100 "Cannot Process Location" [this doc] 1213 200 "Permission To Use Location Information" [this doc] 1215 201 "Permission To Retransmit Location Information to a Third Party" 1216 [this doc] 1218 202 "Permission to Route based on Location Information" [this doc] 1220 300 "Dereference Failure" [this doc] 1222 9. Acknowledgements 1223 To Dave Oran for helping to shape this idea. 1225 To Dean Willis for guidance of the effort. 1227 To Allison Mankin, Dick Knight, Hannes Tschofenig, Henning 1228 Schulzrinne, James Winterbottom, Jeroen van Bemmel, Jean-Francois 1229 Mule, Jonathan Rosenberg, Keith Drage, Marc Linsner, Martin Thomson, 1230 Mike Hammer, Ted Hardie, Shida Shubert, Umesh Sharma, Richard 1231 Barnes, Dan Wing, Matt Lepinski, John Elwell and Jacqueline Lee for 1232 constructive feedback and nits checking. 1234 Special thanks to Paul Kyzivat for his help with the ABNF in this 1235 document and to Robert Sparks for many helpful comments and the 1236 proper construction of the Geolocation-Error header field. 1238 And finally, to Spencer Dawkins for giving this doc a good scrubbing 1239 to make it more readable. 1241 10. References 1243 10.1 Normative References 1245 [RFC3261] J. Rosenberg, H. Schulzrinne, G. Camarillo, A. Johnston, J. 1246 Peterson, R. Sparks, M. Handley, and E. Schooler, "SIP: 1247 Session Initiation Protocol", RFC 3261, May 2002. 1249 [RFC4119] J. Peterson, "A Presence-based GEOPRIV Location Object 1250 Format", RFC 4119, December 2005 1252 [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate 1253 Requirement Levels", RFC 2119, March 1997 1255 [RFC2392] E. Levinson, "Content-ID and Message-ID Uniform Resource 1256 Locators", RFC 2392, August 1998 1258 [RFC3856] J. Rosenberg, "A Presence Event Package for the Session 1259 Initiation Protocol (SIP)", RFC 3856, August 2004 1261 [RFC3859] J. Peterson, "Common Profile for Presence (CPP)", RFC 3859, 1262 August 2004 1264 [RFC3428] B. Campbell, Ed., J. Rosenberg, H. Schulzrinne, C. Huitema, 1265 D. Gurle, "Session Initiation Protocol (SIP) Extension for 1266 Instant Messaging" , RFC 3428, December 2002 1268 [RFC3311] J. Rosenberg, "The Session Initiation Protocol (SIP) UPDATE 1269 Method", RFC 3311, October 2002 1271 [RFC3265] Roach, A, "Session Initiation Protocol (SIP)-Specific 1272 Event Notification", RFC 3265, June 2002. 1274 [RFC3262] Rosenberg, J. and H. Schulzrinne, "Reliability of 1275 Provisional Responses in Session Initiation Protocol (SIP)", 1276 RFC 3262, June 2002. 1278 [RFC2976] S. Donovan, "The SIP INFO Method", RFC 2976, Oct 2000 1280 [RFC3515] R. Sparks, "The Session Initiation Protocol (SIP) Refer 1281 Method", RFC 3515, April 2003 1283 [RFC3903] Niemi, A, "Session Initiation Protocol (SIP) Extension 1284 for Event State Publication", RFC 3903, October 2004. 1286 [RFC5234] Crocker, D., Ed., and P. Overell, "Augmented BNF for Syntax 1287 Specifications: ABNF", STD 68, RFC 5234, January 2008. 1289 [RFC5226] T. Narten, H. Alvestrand, "Guidelines for Writing an IANA 1290 Considerations Section in RFCs", RFC 5226, May 2008 1292 [RFC4479] J. Rosenberg, "A Data Model for Presence", RFC 4479, July 1293 2006 1295 [RFC3264] J. Rosenberg, H. Schulzrinne, "The Offer/Answer Model with 1296 Session Description Protocol", RFC 3264, June 2002 1298 [RFC4483] E. Berger, "A Mechanism for Content Indirection in SIP", RFC 1299 4483, May 2006 1301 [RFC5491] J. Winterbottom, M. Thomson, H. Tschofenig, "GEOPRIV PIDF-LO 1302 Usage Clarification, Considerations, and Recommendations ", 1303 RFC 5491, March 2009 1305 [RFC5870] A. Mayrhofer, C. Spanring, "A Uniform Resource Identifier 1306 for Geographic Locations ('geo' URI)", RFC 5870, June 2010 1308 [RFC5606] J. Peterson, T. Hardie, J. Morris, "Implications of 1309 'retransmission-allowed' for SIP Location Conveyance", 1310 RFC5606, Oct 2008 1312 [RFC2616] R. Fielding, J. Gettys, J., Mogul, H. Frystyk, L., 1313 Masinter, P. Leach, T. Berners-Lee, "Hypertext Transfer 1314 Protocol - HTTP/1.1", RFC 2616, June 1999 1316 10.2 Informative References 1318 [RFC3693] J. Cuellar, J. Morris, D. Mulligan, J. Peterson. J. Polk, 1319 "Geopriv Requirements", RFC 3693, February 2004 1321 [RFC2818] E. Rescorla, "HTTP Over TLS", RFC 2818, May 2000 1323 [ID-GEO-FILTERS] R. Mahy, B. Rosen, H. Tschofenig, "Filtering Location 1324 Notifications in SIP", draft-ietf-geopriv-loc-filters, "work 1325 in progress", March 2010 1327 [ID-HELD-DEREF] J. Winterbottom, H. Tschofenig, H. Schulzrinne, M. 1328 Thomson, M. Dawson, "A Location Dereferencing Protocol Using 1329 HELD", "work in progress", December 2010 1331 [ID-GEO-ARCH] R. Barnes, M. Lepinski, A. Cooper, J, Morris, H. 1332 Tschofenig, H. Schulzrinne, "An Architecture for Location 1333 and Location Privacy in Internet Applications", 1334 draft-ietf-geopriv-arch, "work in progress", October 2010 1336 Author Addresses 1338 James Polk 1339 Cisco Systems 1340 3913 Treemont Circle 1341 Colleyville, Texas 76034 1343 33.00111N 1344 96.68142W 1346 Phone: +1-817-271-3552 1347 Email: jmpolk@cisco.com 1349 Brian Rosen 1350 NeuStar, Inc. 1351 470 Conrad Dr. 1352 Mars, PA 16046 1354 40.70497N 1355 80.01252W 1357 Phone: +1 724 382 1051 1358 Email: br@brianrosen.net 1360 Jon Peterson 1361 NeuStar, Inc. 1363 Email: jon.peterson@neustar.biz 1365 Appendix A. Requirements for SIP Location Conveyance 1367 The following subsections address the requirements placed on the 1368 UAC, the UAS, as well as SIP proxies when conveying location. If a 1369 requirement is not obvious in intent, a motivational statement is 1370 included below it. 1372 A.1 Requirements for a UAC Conveying Location 1373 UAC-1 The SIP INVITE Method [RFC3261] must support location 1374 conveyance. 1376 UAC-2 The SIP MESSAGE method [RFC3428] must support location 1377 conveyance. 1379 UAC-3 SIP Requests within a dialog should support location 1380 conveyance. 1382 UAC-4 Other SIP Requests may support location conveyance. 1384 UAC-5 There must be one, mandatory to implement means of 1385 transmitting location confidentially. 1387 Motivation: to guarantee interoperability. 1389 UAC-6 It must be possible for a UAC to update location conveyed 1390 at any time in a dialog, including during dialog 1391 establishment. 1393 Motivation: if a UAC has moved prior to the establishment of a 1394 dialog between UAs, the UAC must be able to send location 1395 information. If location has been conveyed, and the UA 1396 moves, the UAC must be able to update the location previously 1397 conveyed to other parties. 1399 UAC-7 The privacy and security rules established within [RFC3693] 1400 that would categorize SIP as a 'Using Protocol' must be met. 1402 UAC-8 The PIDF-LO [RFC4119] is a mandatory to implement format for 1403 location conveyance within SIP. 1405 Motivation: interoperability with other IETF location protocols and 1406 Mechanisms. 1408 UAC-9 There must be a mechanism for the UAC to request the UAS send 1409 its location. 1411 UAC-9 has been DEPRECATED by the SIP WG, due to the many 1412 problems this requirement would have caused if implemented. 1413 The solution is for the above UAS to send a new request to 1414 the original UAC with the UAS's location. 1416 UAC-10 There must be a mechanism to differentiate the ability of the 1417 UAC to convey location from the UACs lack of knowledge of its 1418 location 1420 Motivation: Failure to receive location when it is expected can 1421 happen because the UAC does not implement this extension, or 1422 because the UAC implements the extension, but does not know 1423 where the Target is. This may be, for example, due to the 1424 failure of the access network to provide a location 1425 acquisition mechanism the UAC supports. These cases must be 1426 differentiated. 1428 UAC-11 It must be possible to convey location to proxy servers 1429 along the path. 1431 Motivation: Location-based routing. 1433 A.2 Requirements for a UAS Receiving Location 1435 The following are the requirements for location conveyance by a UAS: 1437 UAS-1 SIP Responses must support location conveyance. 1439 Just as with UAC-9, UAS-1 has been DEPRECATED by the SIP WG, 1440 due to the many problems this requirement would have caused 1441 if implemented. The solution is for the above UAS to send a 1442 new request to the original UAC with the UAS's location. 1444 UAS-2 There must be a unique 4XX response informing the UAC it did 1445 not provide applicable location information. 1447 In addition, requirements UAC-5, 6, 7 and 8 also apply to the UAS. 1449 A.3 Requirements for SIP Proxies and Intermediaries 1451 The following are the requirements for location conveyance by a SIP 1452 proxies and intermediaries: 1454 Proxy-1 Proxy servers must be capable of adding a Location header 1455 field during processing of SIP requests. 1457 Motivation: Provide network assertion of location 1458 when UACs are unable to do so, or when network assertion is 1459 more reliable than UAC assertion of location 1461 Note: Because UACs connected to SIP signaling networks may have 1462 widely varying access network arrangements, including VPN 1463 tunnels and roaming mechanisms, it may be difficult for a 1464 network to reliably know the location of the endpoint. Proxy 1465 assertion of location is NOT RECOMMENDED unless the SIP 1466 signaling network has reliable knowledge of the actual 1467 location of the Targets. 1469 Proxy-2 There must be a unique 4XX response informing the UAC it 1470 did not provide applicable location information.