idnits 2.17.1 draft-ietf-sipcore-location-conveyance-03.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 25 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 507 has weird spacing: '...or code indic...' == Line 517 has weird spacing: '... ar o ...' == Line 521 has weird spacing: '... ar o ...' == Line 950 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 (July 12, 2010) is 5037 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) == Unused Reference: 'RFC3264' is defined on line 1073, 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) Summary: 4 errors (**), 0 flaws (~~), 10 warnings (==), 1 comment (--). 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: January 12, 2011 Brian Rosen 5 Intended Status: Standards Track (PS) Jon Peterson 6 NeuStar 7 July 12, 2010 9 Location Conveyance for the Session Initiation Protocol 10 draft-ietf-sipcore-location-conveyance-03.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 extension covers end-to-end 17 conveyance as well as location-based routing, where SIP 18 intermediaries make routing decisions based upon the location of the 19 user agent client. 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 Jan 12, 2011. 44 Copyright Notice 46 Copyright (c) 2010 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 . . . . . . . . . . . . . 3 76 4. SIP Modifications for Geolocation Conveyance . . . . . . . . 7 77 4.1 The Geolocation Header . . . . . . . . . . . . . . . . . 7 78 4.2 424 (Bad Location Information) Response Code . . . . . . 9 79 4.3 The Geolocation-Error Header . . . . . . . . . . . . . . 10 80 4.4 The 'geolocation' Option Tag . . . . . . . . . . . . . . 12 81 4.5 Location URIs in Message Bodies . . . . . . . . . . . . . 12 82 4.6 Location URIs Allowed . . . . . . . . . . . . . . . . . . 12 83 5. Geolocation Examples . . . . . . . . . . . . . . . . . . . . 13 84 5.1 Location-by-value (Coordinate Format) . . . . . . . . . . 13 85 5.2 Two Locations Composed in Same Location Object Example . 14 86 6. Geopriv Privacy Considerations . . . . . . . . . . . . . . . 16 87 7. Security Considerations . . . . . . . . . . . . . . . . . . . 17 88 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . 18 89 8.1 IANA Registration for New SIP Geolocation Header . . . . 19 90 8.2 IANA Registration for New SIP 'geolocation' Option Tag . 19 91 8.3 IANA Registration for New 424 Response Code . . . . . . . 19 92 8.4 IANA Registration for New SIP Geolocation-Error Header . 19 93 8.5 IANA Registration for New SIP Geolocation-Error Codes . . 19 94 8.6 IANA Registration of Location URI Schemes . . . . . . . . 20 95 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 20 96 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 97 10.1 Normative References . . . . . . . . . . . . . . . . . 21 98 10.2 Informative References . . . . . . . . . . . . . . . . . 22 99 Author Information . . . . . . . . . . . . . . . . . . . . . 22 100 Appendix A. Requirements for SIP Location Conveyance . . . . 23 102 1. Conventions and Terminology used in this document 104 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 105 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and 106 "OPTIONAL" in this document are to be interpreted as described 107 in [RFC2119]. This document furthermore uses numerous terms defined 108 in RFC 3693 [RFC3693], including Location Objection, Location 109 Recipient, Location Server, Target, and Using Protocol. 111 2. Introduction 113 Session Initiation Protocol (SIP) [RFC3261] creates, modifies and 114 terminates multimedia sessions. SIP carries certain information 115 related to a session while establishing or maintaining calls. This 116 document defines how SIP conveys geographic location information of 117 a Target (Target) to a Location Recipient (LR). SIP acts as a Using 118 Protocol of location information, as defined in RFC 3693. 120 In order to convey location information, this document specifies a 121 new SIP header, the Geolocation header, which carries a reference to 122 a Location Object. That Location Object may appear in a MIME body 123 attached to the SIP request, or it may be a remote resource in the 124 network. 126 Note that per RFC 3693, a Target is an entity whose location is 127 being conveyed. Thus, a Target could be a SIP user agent (UA), some 128 other IP device (a router or a PC) that does not have a SIP stack, a 129 non-IP device (a person or a black phone) or even a 130 non-communications device (a building or store front). In no way 131 does this document assume that the SIP user agent client which sends 132 a request containing a location object is necessarily the Target. 133 The location of a Target conveyed within SIP typically corresponds 134 to that of a device controlled by the Target, for example, a mobile 135 phone, but such devices can be separated from their owners, and 136 moreover, in some cases the user agent may not know its own 137 location. 139 In the SIP context, a location recipient will most likely be a SIP 140 UA, but due to the mediated nature of SIP architectures, location 141 information conveyed by a single SIP request may have multiple 142 recipients, as any SIP proxy server in the signaling path that 143 inspects the location of the Target must also be considered a 144 Location Recipient. In presence-like architectures, an intermediary 145 that receives publications of location information and distributes 146 them to watchers acts as a Location Server per RFC 3693. This 147 location conveyance mechanism can also be used to deliver URIs point 148 to such Location Servers where prospective Location Recipients can 149 request Location Objects. 151 3. Overview of SIP Location Conveyance 152 An operational overview of SIP location conveyance can be shown in 4 153 basic diagrams, with most applications falling under one of these 154 basic use cases. 156 Each diagram has Alice and Bob as UAs. Alice is the Target, and Bob 157 is an LR. A SIP intermediary appears in some of the diagrams. Any 158 SIP entity that receives and inspects location information is an LR, 159 therefore any of the diagrams the SIP intermediary receives the SIP 160 request is potentially an LR - though that does not mean such an 161 intermediary necessarily has to route the SIP request based on the 162 location information. In some use cases, location information 163 passes through the LS on the right of each diagram. 165 Alice SIP Intermediary Bob LS 166 | | | | 167 | Request w/Location | | 168 |----------------------------------->| | 169 | | | 170 | Response | | 171 |<-----------------------------------| | 172 | | | | 174 Figure 1. Location Conveyed by Value 176 In Figure 1, Alice is both the Target and the LS that is conveying 177 her location directly to Bob, who acts as an LR. This conveyance is 178 point-to-point - it does not pass through any SIP-layer 179 intermediary. A Location Object appears by-value in the initial SIP 180 request as a MIME body, and Bob responds to that SIP request as 181 appropriate. There is a 'Bad Location Information' response code 182 introduced within this document to specifically inform Alice if she 183 conveys bad location to Bob (i.e., Bob "cannot parse the location 184 provided", or "there is not enough location information to determine 185 where Alice is"). 187 Alice SIP Intermediary Bob LS 188 | | | | 189 | Request w/Location URI | | 190 |----------------------------------->| | 191 | | Dereference | 192 | | Request | 193 | (To: Location URI) | 194 | |---------------->| 195 | | | 196 | | Dereference | 197 | | Response | 198 | (includes location) | 199 | |<----------------| 200 | Response | | 201 |<-----------------------------------| | 202 | | | | 204 Figure 2. Location Conveyed as a Location URI 206 In Figure 2, location is conveyed indirectly, via a Location URI 207 carried in the SIP message (more of those details later). If Alice 208 sends Bob this Location URI, Bob will need to dereference the URI - 209 analogous to Content Indirection [RFC4483] - in order to request the 210 location information. In general, the LS provides the location value 211 to Bob instead of Alice directly. From a user interface 212 perspective, Bob the user won't know that this information was 213 gathered from an LS indirectly rather than culled from the SIP 214 request, and practically this does not impact the operation of 215 location-based applications. 217 Alice SIP Intermediary Bob LS 218 | | | | 219 | Request | | | 220 | w/Location | | | 221 |--------------->| | | 222 | | Request | | 223 | | w/Location | | 224 | |------------------>| | 225 | | | | 226 | | Response | | 227 | |<------------------| | 228 | Response | | | 229 |<---------------| | | 230 | | | | 232 Figure 3. Location Conveyed though a SIP Intermediary 234 In Figure 3, we introduce the idea of a SIP intermediary into the 235 example to illustrate the role of proxying in the location 236 architecture. This intermediary could be a SIP proxy or it could be 237 a back-to-back-user-agent (B2BUA). In this message flow, the SIP 238 intermediary may act as a LR, in addition to Bob. The primary use 239 case for intermediaries consuming location information is 240 location-based routing. In this case, the intermediary chooses a 241 next hop for the SIP request by consulting a specialized location 242 service which selects forwarding destinations based on geographical 243 location. In this case, the intermediary acts as a Location 244 Recipient. 246 However, it can be the case that the SIP intermediary receives a 247 request with location information (conveyed either by-value or 248 by-reference) and does not know or care about Alice's location, or 249 support this extension, and merely passes it on to Bob - in this 250 case, the intermediary does not act as a Location Recipient. 252 Note that an intermediary does not have to perform location-based 253 routing in order to be location recipient. It could be the case that 254 a SIP intermediary which does not perform location-based routing but 255 does care when Alice includes her location; for example, it could 256 care that the location information is complete or that it correctly 257 identifies where Alice is. The best example of this is 258 intermediaries that verify location information for emergency 259 calling, but it could also be for any location based routing - e.g., 260 contacting Pizza Hut, making sure that organization has Alice's 261 proper location in the initial SIP request. 263 If the SIP intermediary rejects the message due to unsuitable 264 location information (we are not going to discuss any other reasons 265 in this document, and there are many), the SIP response will 266 indicate there was 'Bad Location Information' in the SIP request, 267 and provide a location specific error code indicating what Alice 268 needs to do to send an acceptable request. 270 Alice SIP Intermediary Bob LS 271 | | | | 272 | Request | | | 273 | w/Location | | | 274 |--------------->| | | 275 | | | | 276 | Rejected | | | 277 | w/New Location | | | 278 |<---------------| | | 279 | | | | 280 | Request | | | 281 | w/New Location | | | 282 |--------------->| | | 283 | | Request | | 284 | | w/New Location | | 285 | |------------------>| | 286 | | | | 288 Figure 4. SIP Intermediary Replacing Bad Location 290 In this last use case, the SIP intermediary wishes to include a 291 Location Object indicating where it understands Alice to be. Thus, 292 it must inform her user agent what location she should include in 293 any subsequent SIP request that contains her location. In these 294 cases, the intermediary can reject Alice's request, through the SIP 295 response, convey to her the best way to repair the request in order 296 for the intermediary to accept it. 298 Overriding location information provided by the user requires a 299 deployment where an intermediary necessarily knows better than an 300 end user - after all, it could be that Alice has an on-board GPS, 301 and the SIP intermediary only knows her nearest cell tower. Which is 302 more accurate location information? Currently, there is no way to 303 tell which entity is more accurate, or which is wrong - for that 304 matter. This document will not specify how to indicate which 305 location is more accurate than another. If desired, intermediaries 306 may furthermore allow both Alice's internally generated location, as 307 well as the SIP intermediary's determination of where Alice, to 308 appear in the same SIP request (the resubmitted one), and permit 309 that to be forwarded to Bob. This case is discussed in more detail 310 in section 4.2 of this document. 312 As an aside, it is not envisioned that any SIP-based emergency 313 services request (i.e., IP-911, or 112 type of call attempt) will 314 receive a corrective 'Bad Location Information' response from an 315 intermediary. Most likely, the SIP intermediary would in that 316 scenario act a B2BUA and insert into the request by-value any 317 appropriate location information for the benefit of Public Safety 318 Answering Point (PSAP) call centers to expedite call reception by 319 the emergency services personnel; thereby, minimizing any delay in 320 call establishment time. The implementation of these specialized 321 deployments is, however, outside the scope of this document. 323 4. SIP Modifications for Geolocation Conveyance 325 The following sections detail the modifications 326 to SIP for location conveyance. 328 4.1 The Geolocation Header 330 This document defines "Geolocation" as a new SIP header field 331 registered by IANA, with the following ABNF [RFC5234]: 333 Geolocation = "Geolocation" HCOLON locationArg 334 (*COMMA locationArg) 335 locationArg = locationValue / routing-param 336 locationValue = LAQUOT locationURI RAQUOT 337 *(SEMI geoloc-param) 338 locationURI = sip-URI / sips-URI / pres-URI 339 / cid-url ; (from RFC 2392) 340 / absoluteURI ; (from RFC 3261) 341 geoloc-param = generic-param; (from RFC 3261) 342 routing-param = "routing-allowed" EQUAL "yes" / "no" 344 sip-URI, sips-URI and absoluteURI are defined according to [RFC3261]. 346 The pres-URI is defined in [RFC3859]. 348 The cid-url is defined in [RFC2392] to locate message body parts. 349 This URI type is present in a SIP request when location is conveyed 350 as a MIME body in the SIP message. 352 Other URI schemas used in the location URI MUST be reviewed against 353 the RFC 3693 [RFC3693] criteria for a Using Protocol. 355 The Geolocation header field has zero or one locationValue, but 356 MUST NOT contain more than one locationValue. 358 The placement of the "routing-allowed" header field parameter is 359 outside the locationValue, and MUST always be last in the header 360 field value. The routing-allowed parameter MAY be present when no 361 locationValue is present. This scenario sets the routing-allowed 362 policy downstream along the request's signaling path. This header 363 field parameter only has the values "=yes" or "=no". When this 364 parameter is "=yes", the locationValue can be used for routing 365 decisions along the downstream signaling path by intermediaries. 367 When this parameter is "=no", this means no locationValue (inserted 368 by the originating UAC or any intermediary along the signaling path 369 can be used by any SIP intermediary to make routing decisions. 370 Intermediaries that attempt to use the location information for 371 routing purposes in spite of this counter indication may end up 372 routing the request improperly as a result. Sections 4.3 describes 373 the details on what a routing intermediary does if it determines it 374 needs to use the location in the SIP request in order to process the 375 message further. 377 The practical implication is that when the "routing-allowed" 378 parameter is set to "no", if a cid:url is present in the SIP 379 request, intermediaries MUST NOT view the location (because it is 380 not for intermediaries to view), and if a location URI is present, 381 intermediaries MUST NOT dereference it. UAs are allowed to view 382 location in the SIP request even when the "routing-allowed" 383 parameter is set to "no". An LR MUST by default consider the 384 "routing-allowed" header parameter as set to "no", with no 385 exceptions, unless the header field value is set to "yes". 387 If a routing-allowed parameter is parsed as set to "=yes", an 388 implementation MUST parse the rest of the SIP headers for another 389 instance of the Geolocation header value to determine if there is 390 another instance of the routing-allowed parameter set to "=no". If 391 this is the case, the behavior MUST be to process the "=no" 392 indication only, and ignore the "=yes". 394 This document defines the Geolocation header field as valid in the 395 following SIP requests: 397 INVITE [RFC3261], REGISTER [RFC3261], 398 OPTIONS [RFC3261], BYE [RFC3261], 399 UPDATE [RFC3311], INFO [RFC2976], 400 MESSAGE [RFC3428], REFER [RFC3515], 401 SUBSCRIBE [RFC3265], NOTIFY [RFC3265], 402 PUBLISH [RFC3903], PRACK [RFC3262] 404 The following table extends the values in Tables 2 and 3 of RFC 3261 405 [RFC3261]. 407 Header field where proxy INV ACK CAN BYE REG OPT PRA 408 ---------------------------------------------------------------- 409 Geolocation R ar o - - o o o o 411 Header field where proxy SUB NOT UPD MSG REF INF PUB 412 ---------------------------------------------------------------- 413 Geolocation R ar o o o o o o o 415 Table 1: Summary of the Geolocation Header Field 417 The Geolocation header field MAY be included in any one of the 418 optional requests by a UA. A proxy MAY add the Geolocation header 419 field, but MUST NOT modify any pre-existing locationValue, including 420 the "routing-allowed" header field value. 422 A SIP intermediary MAY add a Geolocation header field if one is not 423 present - for example, when a user agent does not support the 424 Geolocation mechanism but their outbound proxy does and knows their 425 location, or any of a number of other use cases (see Figure 4 in 426 section 3). When adding a Geolocation header, a SIP intermediary 427 MAY supply the "routing-allowed" parameter if not yet present in the 428 SIP request. 430 SIP implementations are advised to pay special attention to the 431 policy elements for location retransmission and retention described 432 in RFC 4119. 434 4.2 424 (Bad Location Information) Response Code 436 This SIP extension creates a new location-specific response code, 437 defined as follows, 439 424 (Bad Location Information) 441 The 424 (Bad Location Information) response code is a rejection of 442 the request due to its location contents, indicating location 443 information that was malformed or not satisfactory for the 444 recipient's purpose, or could not be dereferenced. 446 A SIP intermediary can also reject a location it receives from a 447 Target when it understands the Target to be in a different location. 448 The proper handling of this scenario is for the SIP intermediary to 449 include the proper location in the 424 Response. This SHOULD be 450 included in the response as a MIME message body (i.e., a location 451 value), rather than as a URI; however, in cases where the 452 intermediary is willing to share location with recipients but not 453 with a user agent, a reference might be necessary. 455 As mentioned in section 3 (below Figure 4), it might be the case 456 that the intermediary does not want to chance providing less 457 accurate location information than the user agent; thus it will 458 compose its understanding of where the user agent is in a separate 459 element of the same PIDF-LO message body of the SIP 460 response (which also contains the Target's version of where it is). 461 Therefore, both locations are included - each potentially with 462 different elements. The proper reaction of the user agent 463 is to generate a new SIP request that includes this composed 464 location object, and send it towards the original LR. SIP 465 intermediaries can verify that subsequent requests properly insert 466 the suggested location information before forwarding said requests. 468 Section 4.3 describes a Geolocation-Error header field to provide 469 more detail about what was wrong with the location information in 470 the request. This header field MUST be included in the 424 response. 472 The 424 is only appropriate when the Location Recipient needs a 473 locationValue and there are no locationValues included in a SIP 474 request that are usable by a recipient, or as shown in Figure 4 of 475 section 3, a SIP intermediary is informing the UA which location to 476 include in the next SIP request. A 424 MUST NOT be sent in response 477 to a request that lacks a Geolocation header entirely, as the user 478 agent in that case may not support this extension at all. 480 A 424 (Bad Location Information) response is a final response within 481 a transaction, and does not terminate an existing dialog. 483 4.3 The Geolocation-Error Header 485 As discussed in Section 4.2, more granular error notifications 486 specific to location errors within a received request are required 487 if the UA is to know what was wrong within the original request. 488 The Geolocation-Error header field is used for this purpose. 490 The Geolocation-Error header field is used to convey 491 location-specific errors within a response. The Geolocation-Error 492 header field has the following ABNF [RFC5234]: 494 Geolocation-Error = "Geolocation-Error" HCOLON 495 locationErrorValue 496 locationErrorValue = location-error-arg 497 location-error-arg = location-error-code 498 *(SEMI location-error-params) 499 location-error-code = 1*3DIGIT 500 location-error-params = location-error-code-text 501 / generic-param ; from RFC3261 502 location-error-code-text = "code" EQUAL quoted-string ; from RFC3261 504 The Geolocation-Error header field MUST contain only one 505 locationErrorValue to indicate what was wrong with the locationValue 506 the Location Recipient determined was bad. The locationErrorValue 507 contains a 3-digit error code indicating what was wrong with the 508 location in the request. Each error code has a corresponding quoted 509 error text string that is human understandable. This text string is 510 OPTIONAL, but RECOMMENDED for human readability. 512 The following table extends the values in Table 2&3 of RFC 3261 513 [RFC3261]. 515 Header field where proxy INV ACK CAN BYE REG OPT PRA 516 ---------------------------------------------------------------- 517 Geolocation-Error r ar o - - o o o o 519 Header field where proxy SUB NOT UPD MSG REF INF PUB 520 ---------------------------------------------------------------- 521 Geolocation-Error r ar o o o o o o o 523 Table 2: Summary of the Geolocation-Error Header Field 525 The Geolocation-Error header field MAY be included in any response 526 to one of the above SIP requests, so long as a Geolocation 527 locationValue was in the request part of the transaction. For 528 example, Alice includes her location in an INVITE to Bob. Bob can 529 accept this INVITE, thus creating a dialog, even though his UA 530 determined the location contained in the INVITE was bad. Bob merely 531 includes a Geolocation-Error header value in the 200 OK to the 532 INVITE informing Alice the INVITE was accepted but the location 533 provided was bad. The SIP requests included in table 2 above are the 534 ones allowed to optionally contain the Geolocation header field (see 535 section 4.1). 537 If, on the other hand, Bob cannot accept Alice's INVITE without a 538 suitable location, a 424 (Bad Location Information) is sent. This 539 message flow is shown in Figures 1, 2 or 3 in Section 3. 541 The following subsections provide an initial list of location 542 based errors for any SIP non-100 response, including the new 424 543 (Bad Location Information) response. These error codes are divided 544 into 4 categories, based on how the response receiver should react 545 to these errors. 547 o 1XX errors mean the LR cannot process the location within the 548 request. 550 o 2XX errors mean the LR wants the LS to send new or updated 551 location information, perhaps with a delay associated with when 552 to send the request. 554 o 3XX errors mean some specific permission is necessary to process 555 the included location information. 557 o 4XX errors mean there was trouble dereferencing the Location URI 558 sent. 560 All 4 of these error groups have a top level error code with the 561 meaning as stated above (i.e., a Location Error: 100 is "Cannot 562 Process Location", etc). There are two exceptions necessary to 563 include in this document, both have to do with permissions necessary 564 to process the SIP request; they are 566 Location Error: 301 "Permission To Retransmit Location 567 Information to a Third Party" 569 This location error is specific to having the Presence Information 570 Data Format (PIDF-LO) [RFC4119] element set 571 to "=no". This location error is stating it requires permission 572 (i.e., PIDF-LO element set to "=yes") to 573 process this SIP request further. If the LS sending the location 574 information does not want to give this permission, it will not reset 575 this permission in a new request. If the LS wants this message 576 processed without this permission reset, it MUST choose another 577 logical path (if one exists). 579 Location Error: 302 "Permission to Route based on Location 580 Information" 582 This location error is specific to having the locationValue header 583 parameter set to "=no". This location error is 584 stating it requires permission (i.e., a set to 585 "=yes") to process this SIP request further. If the LS sending the 586 location information does not want to give this permission, it will 587 not reset this permission in a new request. If the LS wants this 588 message processed without this permission reset, it MUST choose 589 another logical path (if one exists). 591 4.4 The 'geolocation' Option Tag 593 This document creates and registers with the IANA one new option 594 tag: "geolocation". This option tag is to be used, as defined in 595 [RFC3261], in the Require, Supported and Unsupported header fields. 597 4.5 Location URIs in Message Bodies 599 In the case where a location recipient sends a 424 response and 600 wishes to communicate suitable location by reference rather than by 601 value, the 424 MUST include a content-indirection body per RFC 4483. 603 4.6 Location URIs Allowed 605 The following is part of the discussion started in Section 3, Figure 606 2, which initiated the concept of sending location indirectly. 608 If a location URI is included in a SIP request, it MUST be a SIP-, 609 SIPS- or PRES-URI. When PRES: is used, as defined in [RFC3856], if 610 the resulting resolution resolves to a SIP: or SIPS: URI, this 611 section applies. These schemes MUST be implemented according to 612 this document. 614 absoluteURI is not mandatory-to-implement, but allowed. 616 See [ID-GEO-FILTERS] for more details on dereferencing location. 618 5. Geolocation Example 620 5.1 Location-by-value (in Coordinate Format) 622 This example shows an INVITE message with a coordinate location. In 623 this example, the SIP request uses a sips-URI [RFC3261], meaning 624 this message is protected using TLS on a hop-by-hop basis. 626 INVITE sips:bob@biloxi.example.com SIP/2.0 627 Via: SIPS/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bK74bf9 628 Max-Forwards: 70 629 To: Bob 630 From: Alice ;tag=9fxced76sl 631 Call-ID: 3848276298220188511@atlanta.example.com 632 Geolocation: 633 ;routing-allowed=no 634 Supported: geolocation 635 Accept: application/sdp, application/pidf+xml 636 CSeq: 31862 INVITE 637 Contact: 638 Content-Type: multipart/mixed; boundary=boundary1 639 Content-Length: ... 641 --boundary1 643 Content-Type: application/sdp 645 ...SDP goes here 647 --boundary1 649 Content-Type: application/pidf+xml 650 Content-ID: 651 652 657 658 659 660 661 662 663 32.86726 -97.16054 664 665 666 667 668 no 669 2010-07-30T20:00:00Z 671 672 802.11 673 674 mac:1234567890ab 675 2010-07-28T20:57:29Z 676 677 678 679 --boundary1-- 681 The Geolocation header field from the above INVITE: 683 Geolocation: 685 ... indicates the content-ID location [RFC2392] within the multipart 686 message body of where location information is. An assumption can be 687 made that SDP is the other message body part. The "cid:" eases 688 message body parsing by disambiguating the MIME body that contains 689 the location information associated with this request. 691 If the Geolocation header field did not contain a "cid:" scheme, for 692 example, it could look like this location URI: 694 Geolocation: 696 ... the existence of a non-"cid:" scheme indicates this is a 697 location URI, to be dereferenced to learn the Target's location. Any 698 node wanting to know where user "target123" is would subscribe to 699 that user at server5 to dereference the sips-URI (see Figure 3 in 700 section 3 for this message flow). 702 5.2 Two Locations Composed in Same Location Object Example 704 This example shows the INVITE message after a SIP intermediary 705 rejected the original INVITE (say, the one in section 5.1). This 706 INVITE contains the composed LO sent by the SIP intermediary which 707 includes where the intermediary understands Alice to be. The rules 708 of RFC 5491 [RFC5491] are followed in this construction. 710 This example is here, but should not be taken as occurring very 711 often. In fact, this is believed to be a corner case of location 712 conveyance applicability. 714 INVITE sips:bob@biloxi.example.com SIP/2.0 715 Via: SIPS/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bK74bf0 716 Max-Forwards: 70 717 To: Bob 718 From: Alice ;tag=9fxced76sl 719 Call-ID: 3848276298220188512@atlanta.example.com 720 Geolocation: 721 ;routing-allowed=no 722 Supported: geolocation 723 Accept: application/sdp, application/pidf+xml 724 CSeq: 31863 INVITE 725 Contact: 726 Content-Type: multipart/mixed; boundary=boundary1 727 Content-Length: ... 729 --boundary1 731 Content-Type: application/sdp 733 ...SDP goes here 735 --boundary1 737 738 744 745 746 747 748 749 750 32.86726 -97.16054 751 752 753 754 755 no 756 2010-07-30T20:00:00Z 758 759 802.11 760 761 mac:1234567890ab 762 2010-07-28T20:57:29Z 763 764 765 766 767 768 US 769 Texas 770 Colleyville 771 3913 772 Treemont 773 Circle 774 76034 775 Haley's Place 776 1 777 778 779 780 no 781 2010-07-30T20:00:00Z 783 triangulation 784 785 786 2010-07-28T12:28:04Z 787 788 789 791 --boundary1-- 793 6. Geopriv Privacy Considerations 795 Location information is considered by most to be highly 796 sensitive information, requiring protection from eavesdropping, 797 and altering in transit. [RFC3693] articulates rules to 798 be followed by any protocol wishing to be considered a "Using 799 Protocol", specifying how a transport protocol meets those rules. 800 This section describes how SIP as a Using Protocol meets those 801 requirements. 803 Quoting requirement #4 of [RFC3693]: 805 "The Using Protocol has to obey the privacy and security 806 instructions coded in the Location Object and in the 807 corresponding Rules regarding the transmission and storage 808 of the LO." 810 This document requires that SIP entities sending or receiving 811 location MUST obey such instructions. 813 Quoting requirement #5 of [RFC3693]: 815 "The Using Protocol will typically facilitate that the keys 816 associated with the credentials are transported to the 817 respective parties, that is, key establishment is the 818 responsibility of the Using Protocol." 820 [RFC3261] and the documents it references define the key 821 establishment mechanisms. 823 Quoting requirement #6 of [RFC3693]: 825 "(Single Message Transfer) In particular, for tracking of 826 small Target devices, the design should allow a single 827 message/packet transmission of location as a complete 828 transaction." 830 When used for tracking, a simple NOTIFY or UPDATE normally is 831 relatively small, although the PIDF itself can be large. Normal 832 RFC 3261 procedures of reverting to TCP when the MTU size is 833 exceeded would be invoked. 835 7. Security Considerations 837 Conveyance of physical location of a UA raises privacy concerns, 838 and depending on use, there probably will be authentication and 839 integrity concerns. This document calls for conveyance to 840 be accomplished through secure mechanisms, like S/MIME encrypting 841 message bodies (although this is not widely deployed), TLS 842 protecting the overall signaling or conveyance location by-reference 843 and requiring all entities that dereference location to authenticate 844 themselves. In location-based routing cases, encrypting the 845 location payload with an end-to-end mechanism such as S/MIME is 846 problematic, because one or more proxies on the path need the 847 ability to read the location information to retarget the message to 848 the appropriate new destination UAS. Data can only be encrypted to a 849 particular, anticipated target, and thus if multiple recipients need 850 to inspect a piece of data, and those recipients cannot be predicted 851 by the sender of data, encryption is not a very feasible choice. 852 Securing the location hop-by-hop, using TLS, protects the message 853 from eavesdropping and modification in transit, but exposes the 854 information to all proxies on the path as well as the endpoint. In 855 most cases, the UA has no trust relationship with the proxy or 856 proxies providing location-based routing services, so such 857 end-to-middle solutions might not be appropriate either. 859 When location information is conveyed by reference, however, one can 860 properly authenticate and authorize each entity that wishes to 861 inspect location information. This does not require that the sender 862 of data anticipate who will receive data, and it does permit 863 multiple entities to receive it securely, but it does not however 864 obviate the need for pre-association between the sender of data and 865 any prospective recipients. Obviously, in some contexts this 866 pre-association cannot be presumed; when it is not, effectively 867 unauthenticated access to location information must be permitted. In 868 this case, choosing pseudo-random URIs for location by-reference, 869 coupled with path encryption like SIPS, can help to ensure that only 870 entities on the SIP signaling path learn the URI, and thus restores 871 rough parity with sending location by-value. 873 Location information is especially sensitive when the identity of 874 its Target is obvious. Note that there is the ability, according to 875 [RFC3693] to have an anonymous identity for the Target's location. 876 This is accomplished by use of an unlinkable pseudonym in the 877 "entity=" attribute of the element [RFC4479]. Though, 878 this can be problematic for routing messages based on location 879 (covered in the document above). Moreover, anyone fishing for 880 information would correlate the identity at the SIP layer with that 881 of the location information referenced by SIP signaling. 883 When a UA inserts location, the UA sets the policy on whether to 884 reveal its location along the signaling path - as discussed in 885 Section 4, as well as flags in the PIDF-LO [RFC4119]. UAC 886 implementations MUST make such capabilities conditional on explicit 887 user permission, and MUST alert the user that location is being 888 conveyed. 890 This SIP extension offers the default ability to require permission 891 to view location while the SIP request is in transit. The default 892 for this is set to "no". There is an error explicitly describing 893 how an intermediary asks for permission to view the Target's 894 location, plus a rule stating the user has to be made aware of this 895 permission request. 897 There is no end-to-end integrity on any locationValue or 898 locationErrorValue header field parameter (or middle-to-end if the 899 value was inserted by a intermediary), so recipients of either 900 header field need to implicitly trust the header field contents, and 901 take whatever precautions each entity deems appropriate given this 902 situation. 904 8. IANA Considerations 906 The following are the IANA considerations made by this SIP 907 extension. Modifications and additions to these registrations 908 require a standards track RFC (Standards Action). 910 [Editor's Note: RFC-Editor - within the IANA section, please 911 replace "this doc" with the assigned RFC number, 912 if this document reaches publication.] 914 8.1 IANA Registration for the SIP Geolocation Header Field 916 The SIP Geolocation Header Field is created by this document, with 917 its definition and rules in Section 4.1 of this document, and should 918 be added to the IANA sip-parameters registry, in the portion titled 919 "Header Field Parameters and Parameter Values". 921 Predefined 922 Header Field Parameter Name Values Reference 923 ---------------- ------------------- ---------- --------- 924 Geolocation routing-allowed yes [this doc] 926 8.2 IANA Registration for New SIP 'geolocation' Option Tag 928 The SIP option tag "geolocation" is created by this document, with 929 the definition and rule in Section 4.4 of this document, to be added 930 to the IANA sip-parameters registry. 932 8.3 IANA Registration for 424 Response Code 934 Reference: RFC-XXXX (i.e., this document) 935 Response code: 424 (recommended number to assign) 936 Default reason phrase: Bad Location Information 938 This SIP Response code is defined in section 4.2 of this document. 940 8.4 IANA Registration of New Geolocation-Error Header Field 942 The SIP Geolocation-error header field is created by this document, 943 with its definition and rules in Section 4.3 of this document, to be 944 added to the IANA sip-parameters registry, in the portion titled 945 "Header Field Parameters and Parameter Values". 947 Predefined 948 Header Field Parameter Name Values Reference 949 ----------------- ------------------- ---------- --------- 950 Geolocation-Error code= yes* [this doc] 952 * see section 9.5 for the newly created values. 954 8.5 IANA Registration for the SIP Geolocation-Error Codes 956 New location specific Geolocation-Error codes are created by this 957 document, and registered in a new table in the IANA sip-parameters 958 registry. Details of these error codes are in Section 4.3 of this 959 document. 961 Geolocation-Error codes 962 ----------------------- 963 Geolocation-Error codes provide reason for the error discovered by 964 Location Recipients, categorized by action to be taken by error 965 recipient. 967 Code Description Reference 968 ---- --------------------------------------------------- --------- 969 100 "Cannot Process Location" [this doc] 971 200 "Retry Location Later with device updated location" [this doc] 973 300 "Permission To Use Location Information" [this doc] 975 301 "Permission To Retransmit Location Information to a Third Party" 976 [this doc] 978 302 "Permission to Route based on Location Information" [this doc] 980 400 "Location Information Denial" [this doc] 982 8.6 IANA Registration of Location URI Schemes 984 This document directs IANA to create a new set of parameters in a 985 separate location from SIP and Geopriv, called the "Location 986 Reference URI" registry, containing the URI scheme, the 987 Content-Type, and the reference, as follows: 989 URI Scheme Content-Type Reference 990 ---------- ------------ --------- 991 SIP: [this doc] 992 SIPS: [this doc] 993 PRES: [this doc] 995 Additions to this registry must be defined in a permanent and 996 readily available specification (this is the "Specification 997 Required" IANA policy defined in [RFC5226]). 999 9. Acknowledgements 1001 To Dave Oran for helping to shape this idea. 1003 To Dean Willis for guidance of the effort. 1005 To Allison Mankin, Dick Knight, Hannes Tschofenig, Henning 1006 Schulzrinne, James Winterbottom, Jeroen van Bemmel, Jean-Francois 1007 Mule, Jonathan Rosenberg, Keith Drage, Marc Linsner, Martin Thomson, 1008 Mike Hammer, Ted Hardie, Shida Shubert, Umesh Sharma, Richard 1009 Barnes, Dan Wing, Matt Lepinski, John Elwell and Jacqueline Lee for 1010 constructive feedback and nits checking. 1012 Special thanks to Paul Kyzivat for his help with the ABNF in this 1013 document and to Robert Sparks for many helpful comments and the 1014 proper construction of the Geolocation-Error header field. 1016 And finally, to Spencer Dawkins for giving this doc a good scrubbing 1017 to make it more readable. 1019 10. References 1021 10.1 Normative References 1023 [RFC3261] J. Rosenberg, H. Schulzrinne, G. Camarillo, A. Johnston, J. 1024 Peterson, R. Sparks, M. Handley, and E. Schooler, "SIP: 1025 Session Initiation Protocol", RFC 3261, May 2002. 1027 [RFC4119] J. Peterson, "A Presence-based GEOPRIV Location Object 1028 Format", RFC 4119, December 2005 1030 [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate 1031 Requirement Levels", RFC 2119, March 1997 1033 [RFC2392] E. Levinson, " Content-ID and Message-ID Uniform Resource 1034 Locators", RFC 2392, August 1998 1036 [RFC3856] J. Rosenberg, " A Presence Event Package for the Session 1037 Initiation Protocol (SIP)", RFC 3856, August 2004 1039 [RFC3859] J. Peterson, "Common Profile for Presence (CPP)", RFC 3859, 1040 August 2004 1042 [RFC3428] B. Campbell, Ed., J. Rosenberg, H. Schulzrinne, C. Huitema, 1043 D. Gurle, "Session Initiation Protocol (SIP) Extension for 1044 Instant Messaging" , RFC 3428, December 2002 1046 [RFC3311] J. Rosenberg, "The Session Initiation Protocol (SIP) UPDATE 1047 Method", RFC 3311, October 2002 1049 [RFC3265] Roach, A, "Session Initiation Protocol (SIP)-Specific 1050 Event Notification", RFC 3265, June 2002. 1052 [RFC3262] Rosenberg, J. and H. Schulzrinne, "Reliability of 1053 Provisional Responses in Session Initiation Protocol (SIP)", 1054 RFC 3262, June 2002. 1056 [RFC2976] S. Donovan, "The SIP INFO Method", RFC 2976, Oct 2000 1058 [RFC3515] R. Sparks, "The Session Initiation Protocol (SIP) Refer 1059 Method", RFC 3515, April 2003 1061 [RFC3903] Niemi, A, "Session Initiation Protocol (SIP) Extension 1062 for Event State Publication", RFC 3903, October 2004. 1064 [RFC5234] Crocker, D., Ed., and P. Overell, "Augmented BNF for Syntax 1065 Specifications: ABNF", STD 68, RFC 5234, January 2008. 1067 [RFC5226] T. Narten, H. Alvestrand, "Guidelines for Writing an IANA 1068 Considerations Section in RFCs", RFC 5226, May 2008 1070 [RFC4479] J. Rosenberg, "A Data Model for Presence", RFC 4479, July 1071 2006 1073 [RFC3264] J. Rosenberg, H. Schulzrinne, "The Offer/Answer Model with 1074 Session Description Protocol", RFC 3264, June 2002 1076 [RFC4483] E. Berger, "A Mechanism for Content Indirection in SIP", RFC 1077 4483, May 2006 1079 [RFC5491] J. Winterbottom, M. Thomson, H. Tschofenig, "GEOPRIV PIDF-LO 1080 Usage Clarification, Considerations, and Recommendations ", 1081 RFC 5491, March 2009 1083 10.2 Informative References 1085 [RFC3693] J. Cuellar, J. Morris, D. Mulligan, J. Peterson. J. Polk, 1086 "Geopriv Requirements", RFC 3693, February 2004 1088 [ID-GEO-FILTERS] R. Mahy, B. Rosen, H. Tschofenig, "Filtering Location 1089 Notifications in SIP", draft-ietf-geopriv-loc-filters, "work 1090 in progress", March 2010 1092 Authors' Addresses 1094 James Polk 1095 Cisco Systems 1096 3913 Treemont Circle 1097 Colleyville, Texas 76034 1099 33.00111N 1100 96.68142W 1102 Phone: +1-817-271-3552 1103 Email: jmpolk@cisco.com 1105 Brian Rosen 1106 NeuStar, Inc. 1107 470 Conrad Dr. 1108 Mars, PA 16046 1110 40.70497N 1111 80.01252W 1113 Phone: +1 724 382 1051 1114 Email: br@brianrosen.net 1115 Jon Peterson 1116 NeuStar, Inc. 1118 Email: jon.peterson@neustar.biz 1120 Appendix A. Requirements for SIP Location Conveyance 1122 The following subsections address the requirements placed on the 1123 UAC, the UAS, as well as SIP proxies when conveying location. If a 1124 requirement is not obvious in intent, a motivational statement is 1125 included below it. 1127 A.1 Requirements for a UAC Conveying Location 1129 UAC-1 The SIP INVITE Method [RFC3261] must support location 1130 conveyance. 1132 UAC-2 The SIP MESSAGE method [RFC3428] must support location 1133 conveyance. 1135 UAC-3 SIP Requests within a dialog should support location 1136 conveyance. 1138 UAC-4 Other SIP Requests may support location conveyance. 1140 UAC-5 There must be one, mandatory to implement means of 1141 transmitting location confidentially. 1143 Motivation: to guarantee interoperability. 1145 UAC-6 It must be possible for a UAC to update location conveyed 1146 at any time in a dialog, including during dialog 1147 establishment. 1149 Motivation: if a UAC has moved prior to the establishment of a 1150 dialog between UAs, the UAC must be able to send location 1151 information. If location has been conveyed, and the UA 1152 moves, the UAC must be able to update the location previously 1153 conveyed to other parties. 1155 UAC-7 The privacy and security rules established within [RFC3693] 1156 that would categorize SIP as a 'Using Protocol' must be met. 1158 UAC-8 The PIDF-LO [RFC4119] is a mandatory to implement format for 1159 location conveyance within SIP. 1161 Motivation: interoperability with other IETF location protocols and 1162 Mechanisms. 1164 UAC-9 There must be a mechanism for the UAC to request the UAS send 1165 its location. 1167 UAC-9 has been DEPRECATED by the SIP WG, due to the many 1168 problems this requirement would have caused if implemented. 1169 The solution is for the above UAS to send a new request to 1170 the original UAC with the UAS's location. 1172 UAC-10 There must be a mechanism to differentiate the ability of the 1173 UAC to convey location from the UACs lack of knowledge of its 1174 location 1176 Motivation: Failure to receive location when it is expected can 1177 happen because the UAC does not implement this extension, or 1178 because the UAC implements the extension, but does not know 1179 where the Target is. This may be, for example, due to the 1180 failure of the access network to provide a location 1181 acquisition mechanism the UAC supports. These cases must be 1182 differentiated. 1184 UAC-11 It must be possible to convey location to proxy servers 1185 along the path. 1187 Motivation: Location-based routing. 1189 A.2 Requirements for a UAS Receiving Location 1191 The following are the requirements for location conveyance by a UAS: 1193 UAS-1 SIP Responses must support location conveyance. 1195 Just as with UAC-9, UAS-1 has been DEPRECATED by the SIP WG, 1196 due to the many problems this requirement would have caused 1197 if implemented. The solution is for the above UAS to send a 1198 new request to the original UAC with the UAS's location. 1200 UAS-2 There must be a unique 4XX response informing the UAC it did 1201 not provide applicable location information. 1203 In addition, requirements UAC-5, 6, 7 and 8 also apply to the UAS. 1205 A.3 Requirements for SIP Proxies and Intermediaries 1207 The following are the requirements for location conveyance by a SIP 1208 proxies and intermediaries: 1210 Proxy-1 Proxy servers must be capable of adding a Location header 1211 field during processing of SIP requests. 1213 Motivation: Provide network assertion of location 1214 when UACs are unable to do so, or when network assertion is 1215 more reliable than UAC assertion of location 1217 Note: Because UACs connected to SIP signaling networks may have 1218 widely varying access network arrangements, including VPN 1219 tunnels and roaming mechanisms, it may be difficult for a 1220 network to reliably know the location of the endpoint. Proxy 1221 assertion of location is NOT RECOMMENDED unless the SIP 1222 signaling network has reliable knowledge of the actual 1223 location of the Targets. 1225 Proxy-2 There must be a unique 4XX response informing the UAC it 1226 did not provide applicable location information.