idnits 2.17.1 draft-ietf-sipcore-location-conveyance-05.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 27 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 1072 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 8, 2011) is 4826 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 907, but not defined == Unused Reference: 'RFC5226' is defined on line 1170, but no explicit reference was found in the text == Unused Reference: 'RFC3264' is defined on line 1176, but no explicit reference was found in the text == Unused Reference: 'ID-GEO-ARCH' is defined on line 1212, 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: September 8, 2011 Brian Rosen 5 Intended Status: Standards Track (PS) Jon Peterson 6 NeuStar 7 Feb 8, 2011 9 Location Conveyance for the Session Initiation Protocol 10 draft-ietf-sipcore-location-conveyance-05.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 September 8, 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 . . . . . . . . . 6 80 4. SIP Modifications for Geolocation Conveyance . . . . . . . . 8 81 4.1 The Geolocation Header . . . . . . . . . . . . . . . . . 8 82 4.2 424 (Bad Location Information) Response Code . . . . . . 10 83 4.3 The Geolocation-Error Header . . . . . . . . . . . . . . 11 84 4.4 The 'geolocation' Option Tag . . . . . . . . . . . . . . 14 85 4.5 Location URIs in Message Bodies . . . . . . . . . . . . . 14 86 4.6 Location URIs Allowed . . . . . . . . . . . . . . . . . . 14 87 5. Geolocation Examples . . . . . . . . . . . . . . . . . . . . 14 88 5.1 Location-by-value (Coordinate Format) . . . . . . . . . . 14 89 5.2 Two Locations Composed in Same Location Object Example . 16 90 6. Geopriv Privacy Considerations . . . . . . . . . . . . . . . 18 91 7. Security Considerations . . . . . . . . . . . . . . . . . . . 18 92 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . 19 93 8.1 IANA Registration for New SIP Geolocation Header . . . . 20 94 8.2 IANA Registration for New SIP 'geolocation' Option Tag . 20 95 8.3 IANA Registration for New 424 Response Code . . . . . . . 20 96 8.4 IANA Registration for New SIP Geolocation-Error Header . 20 97 8.5 IANA Registration for New SIP Geolocation-Error Codes . . 20 98 8.6 IANA Registration of Location URI Schemes . . . . . . . . 21 99 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 21 100 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 22 101 10.1 Normative References . . . . . . . . . . . . . . . . . 22 102 10.2 Informative References . . . . . . . . . . . . . . . . . 23 103 Author Information . . . . . . . . . . . . . . . . . . . . . 24 104 Appendix A. Requirements for SIP Location Conveyance . . . . 24 106 1. Conventions and Terminology used in this document 108 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 109 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and 110 "OPTIONAL" in this document are to be interpreted as described 111 in [RFC2119]. This document furthermore uses numerous terms defined 112 in RFC 3693 [RFC3693], including Location Object, Location 113 Recipient, Location Server, Target, and Using Protocol. 115 2. Introduction 117 Session Initiation Protocol (SIP) [RFC3261] creates, modifies and 118 terminates multimedia sessions. SIP carries certain information 119 related to a session while establishing or maintaining calls. This 120 document defines how SIP conveys geographic location information of 121 a Target (Target) to a Location Recipient (LR). SIP acts as a Using 122 Protocol of location information, as defined in RFC 3693. 124 In order to convey location information, this document specifies a 125 new SIP header, the Geolocation header, which carries a reference to 126 a Location Object. That Location Object may appear in a MIME body 127 attached to the SIP request, or it may be a remote resource in the 128 network. 130 Note that per RFC 3693, a Target is an entity whose location is 131 being conveyed. Thus, a Target could be a SIP user agent (UA), some 132 other IP device (a router or a PC) that does not have a SIP stack, a 133 non-IP device (a person or a black phone) or even a 134 non-communications device (a building or store front). In no way 135 does this document assume that the SIP user agent client which sends 136 a request containing a location object is necessarily the Target. 137 The location of a Target conveyed within SIP typically corresponds 138 to that of a device controlled by the Target, for example, a mobile 139 phone, but such devices can be separated from their owners, and 140 moreover, in some cases the user agent may not know its own 141 location. 143 In the SIP context, a location recipient will most likely be a SIP 144 UA, but due to the mediated nature of SIP architectures, location 145 information conveyed by a single SIP request may have multiple 146 recipients, as any SIP proxy server in the signaling path that 147 inspects the location of the Target must also be considered a 148 Location Recipient. In presence-like architectures, an intermediary 149 that receives publications of location information and distributes 150 them to watchers acts as a Location Server per RFC 3693. This 151 location conveyance mechanism can also be used to deliver URIs 152 pointing to such Location Servers where prospective Location 153 Recipients can request Location Objects. 155 3. Overview of SIP Location Conveyance 157 An operational overview of SIP location conveyance can be shown in 4 158 basic diagrams, with most applications falling under one of the 159 following basic use cases. Each is separated into its own subsection 160 here in section 3. 162 Each diagram has Alice and Bob as UAs. Alice is the Target, and Bob 163 is an LR. A SIP intermediary appears in some of the diagrams. Any 164 SIP entity that receives and inspects location information is an LR, 165 therefore any of the diagrams the SIP intermediary receives the SIP 166 request is potentially an LR - though that does not mean such an 167 intermediary necessarily has to route the SIP request based on the 168 location information. In some use cases, location information 169 passes through the LS on the right of each diagram. 171 3.1 Location Conveyed by Value 173 We start with the simplest diagram of Location Conveyance, Alice to 174 Bob, where no other layer 7 entities are involved. 176 Alice SIP Intermediary Bob LS 177 | | | | 178 | Request w/Location | | 179 |----------------------------------->| | 180 | | | 181 | Response | | 182 |<-----------------------------------| | 183 | | | | 185 Figure 1. Location Conveyed by Value 187 In Figure 1, Alice is both the Target and the LS that is conveying 188 her location directly to Bob, who acts as an LR. This conveyance is 189 point-to-point - it does not pass through any SIP-layer 190 intermediary. A Location Object appears by-value in the initial SIP 191 request as a MIME body, and Bob responds to that SIP request as 192 appropriate. There is a 'Bad Location Information' response code 193 introduced within this document to specifically inform Alice if she 194 conveys bad location to Bob (e.g., Bob "cannot parse the location 195 provided", or "there is not enough location information to determine 196 where Alice is"). 198 3.2 Location Conveyed as a Location URI 200 Here we make Figure 1 a little more complicated by showing a 201 diagram of indirect Location Conveyance from Alice to Bob, where 202 Bob's entity has to retrieve the location object from a 3rd party 203 server. 205 Alice SIP Intermediary Bob LS 206 | | | | 207 | Request w/Location URI | | 208 |----------------------------------->| | 209 | | Dereference | 210 | | Request | 211 | (To: Location URI) | 212 | |---------------->| 213 | | | 214 | | Dereference | 215 | | Response | 216 | (includes location) | 217 | |<----------------| 218 | Response | | 219 |<-----------------------------------| | 220 | | | | 222 Figure 2. Location Conveyed as a Location URI 224 In Figure 2, location is conveyed indirectly, via a Location URI 225 carried in the SIP request (more of those details later). If Alice 226 sends Bob this Location URI, Bob will need to dereference the URI - 227 analogous to Content Indirection [RFC4483] - in order to request the 228 location information. In general, the LS provides the location value 229 to Bob instead of Alice directly for conveyance to Bob. From a user 230 interface perspective, Bob the user won't know that this information 231 was gathered from an LS indirectly rather than culled from the SIP 232 request, and practically this does not impact the operation of 233 location-based applications. 235 The example given in this section is only illustrative, not 236 normative. In particular, applications can choose to dereference a 237 location URI at any time, possibly several times, or potentially not 238 at all. Applications receiving a Location URI in a SIP transaction 239 need to be mindful of timers used by different transactions. In 240 particular, if the means of dereferencing the Location URI might 241 take longer than the SIP transaction timeout (Timer C for INVITE 242 transactions, Timer F for non-INVITE transactions), then it needs to 243 rely on mechanisms other than the transaction's response code to 244 convey location errors, if returning such errors are necessary. 246 3.3 Location Conveyed though a SIP Intermediary 248 In Figure 3, we introduce the idea of a SIP intermediary into the 249 example to illustrate the role of proxying in the location 250 architecture. This intermediary can be a SIP proxy or it can be 251 a back-to-back-user-agent (B2BUA). In this message flow, the SIP 252 intermediary could act as a LR, in addition to Bob. The primary use 253 case for intermediaries consuming location information is 254 location-based routing. In this case, the intermediary chooses a 255 next hop for the SIP request by consulting a specialized location 256 service which selects forwarding destinations based on geographical 257 location. 259 Alice SIP Intermediary Bob LS 260 | | | | 261 | Request | | | 262 | w/Location | | | 263 |--------------->| | | 264 | | Request | | 265 | | w/Location | | 266 | |------------------>| | 267 | | | | 268 | | Response | | 269 | |<------------------| | 270 | Response | | | 271 |<---------------| | | 272 | | | | 274 Figure 3. Location Conveyed though a SIP Intermediary 276 However, the most common case will be one in which the SIP 277 intermediary receives a request with location information (conveyed 278 either by-value or by-reference) and does not know or care about 279 Alice's location, or support this extension, and merely passes it on 280 to Bob. In this case, the intermediary does not act as a Location 281 Recipient. When the intermediary is not an LR, this use case is the 282 same as the one described in Section 3.1. 284 Note that an intermediary does not have to perform location-based 285 routing in order to be location recipient. It could be the case that 286 a SIP intermediary which does not perform location-based routing but 287 does care when Alice includes her location; for example, it could 288 care that the location information is complete or that it correctly 289 identifies where Alice is. The best example of this is 290 intermediaries that verify location information for emergency 291 calling, but it could also be for any location based routing - e.g., 292 contacting Pizza Hut, making sure that organization has Alice's 293 proper location in the initial SIP request. 295 There is another scenario in which the SIP intermediary cares about 296 location and is not an LR, one in which the intermediary inserts 297 another location of the Target, Alice in this case, into the 298 request, and forwards it. This secondary insertion is generally not 299 advisable because downstream SIP entities will not be given any 300 guidance about which location to believe is better, more reliable, 301 less prone to error, more granular, worse than the other location or 302 just plain wrong. 304 The only conceivable way forward, when a second location is placed 305 into the same SIP request by a SIP intermediary is to 306 take a "you break it, you bought it" philosophy with respect to the 307 inserting SIP intermediary. That entity becomes completely 308 responsible for all location within that SIP request (more on this 309 in Section 4). 311 3.4 SIP Intermediary Replacing Bad Location 313 If the SIP intermediary rejects the message due to unsuitable 314 location information (we are not going to discuss any other reasons 315 in this document, and there are many), the SIP response will 316 indicate there was 'Bad Location Information' in the SIP request, 317 and provide a location specific error code indicating what Alice 318 needs to do to send an acceptable request (see Figure 4 for this 319 scenario). 321 Alice SIP Intermediary Bob LS 322 | | | | 323 | Request | | | 324 | w/Location | | | 325 |--------------->| | | 326 | | | | 327 | Rejected | | | 328 | w/New Location | | | 329 |<---------------| | | 330 | | | | 331 | Request | | | 332 | w/New Location | | | 333 |--------------->| | | 334 | | Request | | 335 | | w/New Location | | 336 | |------------------>| | 337 | | | | 339 Figure 4. SIP Intermediary Replacing Bad Location 341 In this last use case, the SIP intermediary wishes to include a 342 Location Object indicating where it understands Alice to be. Thus, 343 it needs to inform her user agent what location it will include in 344 any subsequent SIP request that contains her location. In this 345 case, the intermediary can reject Alice's request and, through the 346 SIP response, convey to her the best way to repair the request in 347 order for the intermediary to accept it. 349 Overriding location information provided by the user requires a 350 deployment where an intermediary necessarily knows better than an 351 end user - after all, it could be that Alice has an on-board GPS, 352 and the SIP intermediary only knows her nearest cell tower. Which is 353 more accurate location information? Currently, there is no way to 354 tell which entity is more accurate, or which is wrong - for that 355 matter. This document will not specify how to indicate which 356 location is more accurate than another. 358 As an aside, it is not envisioned that any SIP-based emergency 359 services request (i.e., IP-911, or 112 type of call attempt) will 360 receive a corrective 'Bad Location Information' response from an 361 intermediary. Most likely, the SIP intermediary would in that 362 scenario act as a B2BUA and insert into the request by-value any 363 appropriate location information for the benefit of Public Safety 364 Answering Point (PSAP) call centers to expedite call reception by 365 the emergency services personnel; thereby, minimizing any delay in 366 call establishment time. The implementation of these specialized 367 deployments is, however, outside the scope of this document. 369 4. SIP Modifications for Geolocation Conveyance 371 The following sections detail the modifications 372 to SIP for location conveyance. 374 4.1 The Geolocation Header 376 This document defines "Geolocation" as a new SIP header field 377 registered by IANA, with the following ABNF [RFC5234]: 379 Geolocation-header = "Geolocation" HCOLON Geolocation-value 380 Geolocation-value = ( locationValue [ COMMA locationValue ] ) 381 / routing-param 382 locationValue = LAQUOT locationURI RAQUOT 383 *(SEMI geoloc-param) 384 locationURI = sip-URI / sips-URI / pres-URI 385 / http-URI / HTTPS-URI 386 / cid-url ; (from RFC 2392) 387 / absoluteURI ; (from RFC 3261) 388 geoloc-param = generic-param; (from RFC 3261) 389 routing-param = "routing-allowed" EQUAL "yes" / "no" 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 Geolocation header field can have zero or more locationValues. A 409 SIP intermediary SHOULD NOT add location to a SIP request that 410 already contains location. This will quite often lead to confusion 411 within LRs. However, if a SIP intermediary were to add location, 412 even if location was not previously present in a SIP request, that 413 SIP intermediary is fully responsible for addressing the concerns of 414 any 424 (Bad Location Information) SIP response it receives about 415 this location addition, and MUST NOT pass on (upstream) the 424 416 response. Additionally, the first SIP intermediary to add a 417 locationValue adds it as the last locationValue in the header value. 418 The next SIP intermediary to add a locationValue adds it as the last 419 locationValue in the header value - and so on. 421 The placement of the "routing-allowed" header field parameter, 422 strongly encouraged by [RFC5606], is outside the locationValue, and 423 MUST always be last in the header field value. The routing-allowed 424 parameter MUST be present, even when no locationValue is present. 425 This scenario sets the routing-allowed policy downstream along the 426 request's signaling path. This header field parameter only has the 427 values "=yes" or "=no". When this parameter is "=yes", the 428 locationValue can be used for routing decisions along the downstream 429 signaling path by intermediaries. If no routing-allowed parameter 430 is present in a SIP request, a SIP intermediary MAY insert this 431 value with a RECOMMENDED value of "no" by default. 433 When this parameter is "=no", this means no locationValue (inserted 434 by the originating UAC or any intermediary along the signaling path) 435 can be used by any SIP intermediary to make routing decisions. 436 Intermediaries that attempt to use the location information for 437 routing purposes in spite of this counter indication may end up 438 routing the request improperly as a result. Sections 4.3 describes 439 the details on what a routing intermediary does if it determines it 440 needs to use the location in the SIP request in order to process the 441 message further. The practical implication is that when the 442 "routing-allowed" parameter is set to "no", if a cid:url is present 443 in the SIP request, intermediaries MUST NOT view the location 444 (because it is not for intermediaries to view), and if a location 445 URI is present, intermediaries MUST NOT dereference it. UAs are 446 allowed to view location in the SIP request even when the 447 "routing-allowed" parameter is set to "no". An LR MUST by default 448 consider the "routing-allowed" header parameter as set to "no", with 449 no exceptions, unless the header field value is set to "yes". 451 This document defines the Geolocation header field as valid in the 452 following SIP requests: 454 INVITE [RFC3261], REGISTER [RFC3261], 455 OPTIONS [RFC3261], BYE [RFC3261], 456 UPDATE [RFC3311], INFO [RFC2976], 457 MESSAGE [RFC3428], REFER [RFC3515], 458 SUBSCRIBE [RFC3265], NOTIFY [RFC3265], 459 PUBLISH [RFC3903], PRACK [RFC3262] 461 The Geolocation header field MAY be included in any one of the 462 above listed requests by a UA, and a 424 response to any one of the 463 requests sent above. Fully appreciating the caveats/warnings 464 mentioned above, a SIP intermediary MAY add the Geolocation header 465 field, but MUST NOT modify any pre-existing locationValue, or any 466 "routing-allowed" header field value in the SIP request or response. 467 SIP intermediaries can also read any locationValue in which the 468 routing-allowed field is set to "=yes". 470 A SIP intermediary MAY add a Geolocation header field if one is not 471 present - for example, when a user agent does not support the 472 Geolocation mechanism but their outbound proxy does and knows their 473 location, or any of a number of other use cases (see Section 3). 474 When adding a Geolocation header value, a SIP intermediary MAY 475 supply a "routing-allowed" parameter only if not yet present in the 476 SIP request. 478 SIP implementations are advised to pay special attention to the 479 policy elements for location retransmission and retention described 480 in RFC 4119. 482 4.2 424 (Bad Location Information) Response Code 484 This SIP extension creates a new location-specific response code, 485 defined as follows, 487 424 (Bad Location Information) 489 The 424 (Bad Location Information) response code is a rejection of 490 the request due to its location contents, indicating location 491 information that was malformed or not satisfactory for the 492 recipient's purpose, or could not be dereferenced. 494 A SIP intermediary can also reject a location it receives from a 495 Target when it understands the Target to be in a different location. 496 The proper handling of this scenario, described in Section 3.4, is 497 for the SIP intermediary to include the proper location in the 424 498 Response. This SHOULD be included in the response as a MIME message 499 body (i.e., a location value), rather than as a URI; however, in 500 cases where the intermediary is willing to share location with 501 recipients but not with a user agent, a reference might be 502 necessary. 504 As mentioned in Section 3.4, it might be the case that the 505 intermediary does not want to chance providing less accurate 506 location information than the user agent; thus it will compose its 507 understanding of where the user agent is in a separate 508 element of the same PIDF-LO message body in the SIP response (which 509 also contains the Target's version of where it is). Therefore, both 510 locations are included - each with different elements. The 511 proper reaction of the user agent is to generate a new SIP request 512 that includes this composed location object, and send it towards the 513 original LR. SIP intermediaries can verify that subsequent requests 514 properly insert the suggested location information before forwarding 515 said requests. 517 SIP intermediaries MUST NOT add, modify or delete the location in a 518 424 response. This specifically applies to intermediaries that are 519 between the 424 response generator and the original UAC. Geolocation 520 and Geolocation-Error header fields and PIDF-LO body parts MUST 521 remain unchanged, never added to or deleted. 523 Section 4.3 describes a Geolocation-Error header field to provide 524 more detail about what was wrong with the location information in 525 the request. This header field MUST be included in the 424 response. 527 It is only appropriate to generate a 424 response when the 528 responding entity needs a locationValue and there are no 529 locationValues included in the SIP request that are usable by that 530 recipient, or as shown in Figure 4 of section 3.4. In the latter 531 scenario, a SIP intermediary is informing the upstream UA which 532 location to include in the next SIP request. 534 A 424 MUST NOT be sent in response to a request that lacks a 535 Geolocation header entirely, as the user agent in that case may not 536 support this extension at all. If a SIP intermediary inserted a 537 locationValue into a SIP request where one was not previously 538 present, it MUST take any and all responsibility for the corrective 539 action if it receives a 424 to a SIP request it sent. 541 A 424 (Bad Location Information) response is a final response within 542 a transaction, and MUST NOT terminate an existing dialog. 544 4.3 The Geolocation-Error Header 546 As discussed in Section 4.2, more granular error notifications 547 specific to location errors within a received request are required 548 if the location inserting entity is to know what was wrong within 549 the original request. The Geolocation-Error header field is used for 550 this purpose. 552 The Geolocation-Error header field is used to convey 553 location-specific errors within a response. The Geolocation-Error 554 header field has the following ABNF [RFC5234]: 556 Geolocation-Error = "Geolocation-Error" HCOLON 557 locationErrorValue 558 locationErrorValue = location-error-code 559 *(SEMI location-error-params) 560 location-error-code = 1*3DIGIT 561 location-error-params = location-error-code-text 562 / generic-param ; from RFC3261 563 location-error-code-text = "code" EQUAL quoted-string ; from RFC3261 565 The Geolocation-Error header field MUST contain only one 566 locationErrorValue to indicate what was wrong with the locationValue 567 the Location Recipient determined was bad. The locationErrorValue 568 contains a 3-digit error code indicating what was wrong with the 569 location in the request. This error code has a corresponding quoted 570 error text string that is human understandable. This text string is 571 OPTIONAL, but RECOMMENDED for human readability. 573 The Geolocation-Error header field MAY be included in any response 574 to one of the SIP Methods mentioned in Section 4.1, so long as a 575 locationValue was in the request part of the same transaction. For 576 example, Alice includes her location in an INVITE to Bob. Bob can 577 accept this INVITE, thus creating a dialog, even though his UA 578 determined the location contained in the INVITE was bad. Bob merely 579 includes a Geolocation-Error header value in the 200 OK to the 580 INVITE informing Alice the INVITE was accepted but the location 581 provided was bad. 583 If, on the other hand, Bob cannot accept Alice's INVITE without a 584 suitable location, a 424 (Bad Location Information) is sent. This 585 message flow is shown in Figures 1, 2 or 3 in Sections 3.1, 3.2 and 586 3.3 respectively. 588 A SIP intermediary that requires Alice's location in order to 589 properly process Alice's INVITE also sends a 424 with a 590 Geolocation-Error code. This message flow is shown in Figure 4 of 591 Section 3.4. 593 If more than one locationValue is present in a SIP request and at 594 least one locationValue is determined to be valid by the LR, the 595 location in that SIP request MUST be considered good as far as 596 location is concerned, and no Geolocation-Error is sent. This is a 597 compromise of complexity vs. accurate information conveyance with 598 respect to informing each location inserter of every bad location. 600 Here is an initial list of location based error code ranges for any 601 SIP non-100 response, including the new 424 (Bad Location 602 Information) response. These error codes are divided into 3 603 categories, based on how the response receiver should react to these 604 errors. There MUST be no more than one Geolocation-Error code in a 605 SIP response, regardless of how many locationValues there are in the 606 correlating SIP request. There is no guidance given in this document 607 as to which locationValue, when more than one was present in the SIP 608 request, is related to the Geolocation-Error code; meaning that, 609 somehow not defined here, the LR just picks one to error. 611 o 1XX errors mean the LR cannot process the location within the 612 request 613 A non-exclusive list of reasons for returning a 1XX is 615 - the location was not present or could not be found, 616 - there was not enough location information to determine 617 where the Target was, 618 - the location information was corrupted or known to be 619 inaccurate, 620 - etc... 622 o 2XX errors mean some specific permission is necessary to process 623 the included location information. 625 o 3XX errors mean there was trouble dereferencing the Location URI 626 sent. 628 It should be noted that for non-INVITE transactions, the SIP 629 response will likely be sent before the dereference response has 630 been received. At this time, this document does not alter that SIP 631 protocol reality. This means the receiver of any non-INVITE response 632 to a request containing location SHOULD NOT consider a 200 OK to 633 mean the act of dereferencing has concluded and the dereferencer 634 (i.e., the LR) has successfully received and parsed the PIDF-LO for 635 errors and found none. This was first brought up in Section 3.2. 637 Additionally, if a SIP entity cannot or chooses not to process 638 location or the SIP request containing location, the existing 639 mechanism of responding with a 503 (Service Unavailable) SHOULD be 640 used with or without a configurable Retry-After header field. There 641 is no special location error code for what already exists within SIP 642 today. 644 Within each of these ranges, there is a top level error as follows: 646 Geolocation-Error: 100 "Cannot Process Location" 648 Geolocation-Error: 200 "Permission To Use Location Information" 650 Geolocation-Error: 300 "Dereference Failure" 652 There are two specific Geolocation-Error codes necessary to include 653 in this document, both have to do with permissions necessary to 654 process the SIP request; they are 656 Geolocation-Error: 201 "Permission To Retransmit Location 657 Information to a Third Party" 659 This location error is specific to having the Presence Information 660 Data Format (PIDF-LO) [RFC4119] element set 661 to "=no". This location error is stating it requires permission 662 (i.e., PIDF-LO element set to "=yes") to 663 process this SIP request further. If the LS sending the location 664 information does not want to give this permission, it will not reset 665 this permission in a new request. If the LS wants this message 666 processed without this permission reset, it MUST choose another 667 logical path (if one exists) for this SIP request. 669 Geolocation-Error: 202 "Permission to Route based on Location 670 Information" 672 This location error is specific to having the locationValue header 673 parameter set to "=no". This location error is 674 stating it requires permission (i.e., a set to 675 "=yes") to process this SIP request further. If the LS sending the 676 location information does not want to give this permission, it will 677 not reset this permission in a new request. If the LS wants this 678 message processed without this permission reset, it MUST choose 679 another logical path (if one exists) for this SIP request. 681 4.4 Location URIs in Message Bodies 683 In the case where an LR sends a 424 response and wishes to 684 communicate suitable location by reference rather than by value, the 685 424 MUST include a content-indirection body per RFC 4483. 687 4.5 Location Profile Negotiation 689 The following is part of the discussion started in Section 3, Figure 690 2, which introduced the concept of sending location indirectly. 692 If a location URI is included in a SIP request, the sending user 693 agent MUST also include a Supported header field indicating which 694 location profiles it supports. Two option tags for location profiles 695 are defined by this document: "geolocation-sip" and 696 "geolocation-http". Future specifications may define further 697 location profiles per the IANA policy described in Section 8.2. 699 The "geolocation-sip" option tag signals support for acquiring 700 location information via the presence event package of SIP 701 ([RFC3856]). A location recipient who supports this option can send 702 a SUBSCRIBE request and parse a resulting NOTIFY containing a 703 PIDF-LO object. The URI schemes supported by this option include 704 "sip", "sips" and "pres". 706 The "geolocation-http" option tag signals support for acquiring 707 location information via an HTTP ([RFC2616]). A location recipient 708 who supports this option can request location with an HTTP GET and 709 parse a resulting 200 response containing a PIDF-LO object. The URI 710 schemes supported by this option include "http" and "https". A 711 failure to parse the 200 response, for whatever reason, will return 712 a "Dereference Failure" indication to the original location sending 713 user agent to inform it that location was not delivered as intended. 715 See [ID-GEO-FILTERS] or [ID-HELD-DEREF] for more details on 716 dereferencing location information. 718 5. Geolocation Examples 720 5.1 Location-by-value (in Coordinate Format) 722 This example shows an INVITE message with a coordinate location. In 723 this example, the SIP request uses a sips-URI [RFC3261], meaning 724 this message is protected using TLS on a hop-by-hop basis. 726 INVITE sips:bob@biloxi.example.com SIP/2.0 727 Via: SIPS/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bK74bf9 728 Max-Forwards: 70 729 To: Bob 730 From: Alice ;tag=9fxced76sl 731 Call-ID: 3848276298220188511@atlanta.example.com 732 Geolocation: 733 ;routing-allowed=no 734 Supported: geolocation 735 Accept: application/sdp, application/pidf+xml 736 CSeq: 31862 INVITE 737 Contact: 738 Content-Type: multipart/mixed; boundary=boundary1 739 Content-Length: ... 741 --boundary1 743 Content-Type: application/sdp 745 ...SDP goes here 747 --boundary1 749 Content-Type: application/pidf+xml 750 Content-ID: 751 752 760 761 762 763 764 765 32.86726 -97.16054 766 767 768 769 770 false 771 772 2010-11-14T20:00:00Z 773 774 775 802.11 776 777 mac:1234567890ab 778 2010-11-04T20:57:29Z 779 780 781 --boundary1-- 783 The Geolocation header field from the above INVITE: 785 Geolocation: 787 ... indicates the content-ID location [RFC2392] within the multipart 788 message body of where location information is. The other message 789 body part is SDP. The "cid:" eases message body parsing and 790 disambiguates multiple parts of the same type. 792 If the Geolocation header field did not contain a "cid:" scheme, for 793 example, it could look like this location URI: 795 Geolocation: 797 ... the existence of a non-"cid:" scheme indicates this is a 798 location URI, to be dereferenced to learn the Target's location. Any 799 node wanting to know where the target is located would subscribe to 800 the SIP presence event package [RFC3856] at 802 sips:target123@server5.atlanta.example.com 804 (see Figure 2 in Section 3.2 for this message flow). 806 5.2 Two Locations Composed in Same Location Object Example 808 This example shows the INVITE message after a SIP intermediary 809 rejected the original INVITE (say, the one in section 5.1). This 810 INVITE contains the composed LO sent by the SIP intermediary which 811 includes where the intermediary understands Alice to be. The rules 812 of RFC 5491 [RFC5491] are followed in this construction. 814 This example is here, but should not be taken as occurring very 815 often. In fact, this is believed to be a corner case of location 816 conveyance applicability. 818 INVITE sips:bob@biloxi.example.com SIP/2.0 819 Via: SIPS/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bK74bf0 820 Max-Forwards: 70 821 To: Bob 822 From: Alice ;tag=9fxced76sl 823 Call-ID: 3848276298220188512@atlanta.example.com 824 Geolocation: 825 ;routing-allowed=no 826 Supported: geolocation 827 Accept: application/sdp, application/pidf+xml 828 CSeq: 31863 INVITE 829 Contact: 830 Content-Type: multipart/mixed; boundary=boundary1 831 Content-Length: ... 833 --boundary1 835 Content-Type: application/sdp 837 ...SDP goes here 839 --boundary1 841 Content-Type: application/pidf+xml 842 Content-ID: 843 844 852 853 854 855 856 857 32.86726 -97.16054 858 859 860 861 862 false 863 864 2010-11-14T20:00:00Z 865 866 867 802.11 869 870 mac:1234567890ab 871 2010-11-04T20:57:29Z 872 873 874 875 876 877 US 878 Texas 879 Colleyville 880 Treemont 881 Circle 882 3913 883 1 884 Haley's Place 885 76034 886 887 888 889 false 890 891 2010-11-14T20:00:00Z 892 893 894 triangulation 895 896 2010-11-04T12:28:04Z 897 898 899 --boundary1-- 901 6. Geopriv Privacy Considerations 903 Location information is considered by most to be highly sensitive 904 information, requiring protection from eavesdropping and altering in 905 transit. [RFC3693] originally articulated rules to be followed by 906 any protocol wishing to be considered a "Using Protocol", specifying 907 how a transport protocol meets those rules. [ID-GEOPRIV-ARCH] 908 updates the guidance in RFC3693 to include subsequently-introduced 909 entities and concepts in the geolocation architecture. 910 Implementations of this SIP location conveyance mechanism MUST 911 adhere to the guidance given in RFC3693 and its updates and/or 912 successors, including (but not limited to) the handling of rules for 913 retention and retransmission. 915 7. Security Considerations 917 Conveyance of physical location of a UA raises privacy concerns, 918 and depending on use, there probably will be authentication and 919 integrity concerns. This document calls for conveyance to 920 be accomplished through secure mechanisms, like S/MIME encrypting 921 message bodies (although this is not widely deployed), TLS 922 protecting the overall signaling or conveyance location by-reference 923 and requiring all entities that dereference location to authenticate 924 themselves. In location-based routing cases, encrypting the 925 location payload with an end-to-end mechanism such as S/MIME is 926 problematic, because one or more proxies on the path need the 927 ability to read the location information to retarget the message to 928 the appropriate new destination UAS. Data can only be encrypted to a 929 particular, anticipated target, and thus if multiple recipients need 930 to inspect a piece of data, and those recipients cannot be predicted 931 by the sender of data, encryption is not a very feasible choice. 932 Securing the location hop-by-hop, using TLS, protects the message 933 from eavesdropping and modification in transit, but exposes the 934 information to all proxies on the path as well as the endpoint. In 935 most cases, the UA has no trust relationship with the proxy or 936 proxies providing location-based routing services, so such 937 end-to-middle solutions might not be appropriate either. 939 When location information is conveyed by reference, however, one can 940 properly authenticate and authorize each entity that wishes to 941 inspect location information. This does not require that the sender 942 of data anticipate who will receive data, and it does permit 943 multiple entities to receive it securely, but it does not however 944 obviate the need for pre-association between the sender of data and 945 any prospective recipients. Obviously, in some contexts this 946 pre-association cannot be presumed; when it is not, effectively 947 unauthenticated access to location information must be permitted. In 948 this case, choosing pseudo-random URIs for location by-reference, 949 coupled with path encryption like SIPS, can help to ensure that only 950 entities on the SIP signaling path learn the URI, and thus restores 951 rough parity with sending location by-value. 953 Location information is especially sensitive when the identity of 954 its Target is obvious. Note that there is the ability, according to 955 [RFC3693] to have an anonymous identity for the Target's location. 956 This is accomplished by use of an unlinkable pseudonym in the 957 "entity=" attribute of the element [RFC4479]. Though, 958 this can be problematic for routing messages based on location 959 (covered in the document above). Moreover, anyone fishing for 960 information would correlate the identity at the SIP layer with that 961 of the location information referenced by SIP signaling. 963 When a UA inserts location, the UA sets the policy on whether to 964 reveal its location along the signaling path - as discussed in 965 Section 4, as well as flags in the PIDF-LO [RFC4119]. UAC 966 implementations MUST make such capabilities conditional on explicit 967 user permission, and MUST alert the user that location is being 968 conveyed. 970 This SIP extension offers the default ability to require permission 971 to view location while the SIP request is in transit. The default 972 for this is set to "no". There is an error explicitly describing 973 how an intermediary asks for permission to view the Target's 974 location, plus a rule stating the user has to be made aware of this 975 permission request. 977 There is no end-to-end integrity on any locationValue or 978 locationErrorValue header field parameter (or middle-to-end if the 979 value was inserted by a intermediary), so recipients of either 980 header field need to implicitly trust the header field contents, and 981 take whatever precautions each entity deems appropriate given this 982 situation. 984 8. IANA Considerations 986 The following are the IANA considerations made by this SIP 987 extension. Modifications and additions to all these registrations 988 require a standards track RFC (Standards Action). 990 [Editor's Note: RFC-Editor - within the IANA section, please 991 replace "this doc" with the assigned RFC number, 992 if this document reaches publication.] 994 8.1 IANA Registration for the SIP Geolocation Header Field 996 The SIP Geolocation Header Field is created by this document, with 997 its definition and rules in Section 4.1 of this document, and should 998 be added to the IANA sip-parameters registry with two actions 1000 1. Update the Header Fields registry with 1002 Registry: 1003 Header Name compact Reference 1004 ----------------- ------- --------- 1005 Geolocation [this doc] 1007 2. In the portion titled "Header Field Parameters and Parameter 1008 Values", add 1010 Predefined 1011 Header Field Parameter Name Values Reference 1012 ---------------- ------------------- ---------- --------- 1013 Geolocation routing-allowed yes [this doc] 1015 8.2 IANA Registration for Location Profiles 1017 This document defines two new SIP option tags: "geolocation-sip" and 1018 "geolocation-http." with the definition and rule in Section 4.5 of 1019 this document, to be added to the IANA sip-parameters Options Tags 1020 registry. 1022 Name Valid Scheme(S) Reference 1023 geolocation-sip See 4.5 [this doc] 1024 geolocation-http See 4.5 [this doc] 1026 The names of profiles are SIP option-tags, and the guidance in this 1027 document does not supersede the option-tag assignment guidance in 1028 [RFC3261] (which requires a Standards Action for the assignment of a 1029 new option tag). This document does however stipulate that 1030 option-tags included to convey the name of a location profile per 1031 this definition MUST begin with the string "geolocation" followed by 1032 a dash. All such option tags should describe protocols used to 1033 acquire location by reference: these tags have no relevance to 1034 location carried in SIP requests by value, which use standard MIME 1035 typing and negotiation. 1037 8.3 IANA Registration for 424 Response Code 1039 In the SIP Response Codes registry, the following is added 1041 Reference: RFC-XXXX (i.e., this document) 1042 Response code: 424 (recommended number to assign) 1043 Default reason phrase: Bad Location Information 1045 Registry: 1046 Response Code Reference 1047 ------------------------------------------ --------- 1048 Request Failure 4xx 1049 424 Bad Location Information [this doc] 1051 This SIP Response code is defined in section 4.2 of this document. 1053 8.4 IANA Registration of New Geolocation-Error Header Field 1055 The SIP Geolocation-error header field is created by this document, 1056 with its definition and rules in Section 4.3 of this document, to be 1057 added to the IANA sip-parameters registry with two actions 1059 1. Update the Header Fields registry with 1061 Registry: 1062 Header Name compact Reference 1063 ----------------- ------- --------- 1064 Geolocation-Error [this doc] 1066 2. In the portion titled "Header Field Parameters and Parameter 1067 Values", add 1069 Predefined 1070 Header Field Parameter Name Values Reference 1071 ----------------- ------------------- ---------- --------- 1072 Geolocation-Error code= yes* [this doc] 1074 * see section 8.5 for the newly created values. 1076 8.5 IANA Registration for the SIP Geolocation-Error Codes 1078 New location specific Geolocation-Error codes are created by this 1079 document, and registered in a new table in the IANA sip-parameters 1080 registry. Details of these error codes are in Section 4.3 of this 1081 document. 1083 Geolocation-Error codes 1084 ----------------------- 1085 Geolocation-Error codes provide reason for the error discovered by 1086 Location Recipients, categorized by action to be taken by error 1087 recipient. 1089 Code Description Reference 1090 ---- --------------------------------------------------- --------- 1091 100 "Cannot Process Location" [this doc] 1093 200 "Permission To Use Location Information" [this doc] 1095 201 "Permission To Retransmit Location Information to a Third Party" 1096 [this doc] 1098 202 "Permission to Route based on Location Information" [this doc] 1100 300 "Dereference Failure" [this doc] 1102 9. Acknowledgements 1104 To Dave Oran for helping to shape this idea. 1106 To Dean Willis for guidance of the effort. 1108 To Allison Mankin, Dick Knight, Hannes Tschofenig, Henning 1109 Schulzrinne, James Winterbottom, Jeroen van Bemmel, Jean-Francois 1110 Mule, Jonathan Rosenberg, Keith Drage, Marc Linsner, Martin Thomson, 1111 Mike Hammer, Ted Hardie, Shida Shubert, Umesh Sharma, Richard 1112 Barnes, Dan Wing, Matt Lepinski, John Elwell and Jacqueline Lee for 1113 constructive feedback and nits checking. 1115 Special thanks to Paul Kyzivat for his help with the ABNF in this 1116 document and to Robert Sparks for many helpful comments and the 1117 proper construction of the Geolocation-Error header field. 1119 And finally, to Spencer Dawkins for giving this doc a good scrubbing 1120 to make it more readable. 1122 10. References 1124 10.1 Normative References 1126 [RFC3261] J. Rosenberg, H. Schulzrinne, G. Camarillo, A. Johnston, J. 1127 Peterson, R. Sparks, M. Handley, and E. Schooler, "SIP: 1128 Session Initiation Protocol", RFC 3261, May 2002. 1130 [RFC4119] J. Peterson, "A Presence-based GEOPRIV Location Object 1131 Format", RFC 4119, December 2005 1133 [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate 1134 Requirement Levels", RFC 2119, March 1997 1136 [RFC2392] E. Levinson, "Content-ID and Message-ID Uniform Resource 1137 Locators", RFC 2392, August 1998 1139 [RFC3856] J. Rosenberg, "A Presence Event Package for the Session 1140 Initiation Protocol (SIP)", RFC 3856, August 2004 1142 [RFC3859] J. Peterson, "Common Profile for Presence (CPP)", RFC 3859, 1143 August 2004 1145 [RFC3428] B. Campbell, Ed., J. Rosenberg, H. Schulzrinne, C. Huitema, 1146 D. Gurle, "Session Initiation Protocol (SIP) Extension for 1147 Instant Messaging" , RFC 3428, December 2002 1149 [RFC3311] J. Rosenberg, "The Session Initiation Protocol (SIP) UPDATE 1150 Method", RFC 3311, October 2002 1152 [RFC3265] Roach, A, "Session Initiation Protocol (SIP)-Specific 1153 Event Notification", RFC 3265, June 2002. 1155 [RFC3262] Rosenberg, J. and H. Schulzrinne, "Reliability of 1156 Provisional Responses in Session Initiation Protocol (SIP)", 1157 RFC 3262, June 2002. 1159 [RFC2976] S. Donovan, "The SIP INFO Method", RFC 2976, Oct 2000 1161 [RFC3515] R. Sparks, "The Session Initiation Protocol (SIP) Refer 1162 Method", RFC 3515, April 2003 1164 [RFC3903] Niemi, A, "Session Initiation Protocol (SIP) Extension 1165 for Event State Publication", RFC 3903, October 2004. 1167 [RFC5234] Crocker, D., Ed., and P. Overell, "Augmented BNF for Syntax 1168 Specifications: ABNF", STD 68, RFC 5234, January 2008. 1170 [RFC5226] T. Narten, H. Alvestrand, "Guidelines for Writing an IANA 1171 Considerations Section in RFCs", RFC 5226, May 2008 1173 [RFC4479] J. Rosenberg, "A Data Model for Presence", RFC 4479, July 1174 2006 1176 [RFC3264] J. Rosenberg, H. Schulzrinne, "The Offer/Answer Model with 1177 Session Description Protocol", RFC 3264, June 2002 1179 [RFC4483] E. Berger, "A Mechanism for Content Indirection in SIP", RFC 1180 4483, May 2006 1182 [RFC5491] J. Winterbottom, M. Thomson, H. Tschofenig, "GEOPRIV PIDF-LO 1183 Usage Clarification, Considerations, and Recommendations ", 1184 RFC 5491, March 2009 1186 [RFC5870] A. Mayrhofer, C. Spanring, "A Uniform Resource Identifier 1187 for Geographic Locations ('geo' URI)", RFC 5870, June 2010 1189 [RFC5606] J. Peterson, T. Hardie, J. Morris, "Implications of 1190 'retransmission-allowed' for SIP Location Conveyance", 1191 RFC5606, Oct 2008 1193 [RFC2616] R. Fielding, J. Gettys, J., Mogul, H. Frystyk, L., 1194 Masinter, P. Leach, T. Berners-Lee, "Hypertext Transfer 1195 Protocol - HTTP/1.1", RFC 2616, June 1999 1197 10.2 Informative References 1199 [RFC3693] J. Cuellar, J. Morris, D. Mulligan, J. Peterson. J. Polk, 1200 "Geopriv Requirements", RFC 3693, February 2004 1202 [RFC2818] E. Rescorla, "HTTP Over TLS", RFC 2818, May 2000 1204 [ID-GEO-FILTERS] R. Mahy, B. Rosen, H. Tschofenig, "Filtering Location 1205 Notifications in SIP", draft-ietf-geopriv-loc-filters, "work 1206 in progress", March 2010 1208 [ID-HELD-DEREF] J. Winterbottom, H. Tschofenig, H. Schulzrinne, M. 1209 Thomson, M. Dawson, "A Location Dereferencing Protocol Using 1210 HELD", "work in progress", December 2010 1212 [ID-GEO-ARCH] R. Barnes, M. Lepinski, A. Cooper, J, Morris, H. 1213 Tschofenig, H. Schulzrinne, "An Architecture for Location 1214 and Location Privacy in Internet Applications", 1215 draft-ietf-geopriv-arch, "work in progress", October 2010 1217 Author Addresses 1219 James Polk 1220 Cisco Systems 1221 3913 Treemont Circle 1222 Colleyville, Texas 76034 1224 33.00111N 1225 96.68142W 1227 Phone: +1-817-271-3552 1228 Email: jmpolk@cisco.com 1230 Brian Rosen 1231 NeuStar, Inc. 1232 470 Conrad Dr. 1233 Mars, PA 16046 1235 40.70497N 1236 80.01252W 1238 Phone: +1 724 382 1051 1239 Email: br@brianrosen.net 1241 Jon Peterson 1242 NeuStar, Inc. 1244 Email: jon.peterson@neustar.biz 1246 Appendix A. Requirements for SIP Location Conveyance 1248 The following subsections address the requirements placed on the 1249 UAC, the UAS, as well as SIP proxies when conveying location. If a 1250 requirement is not obvious in intent, a motivational statement is 1251 included below it. 1253 A.1 Requirements for a UAC Conveying Location 1255 UAC-1 The SIP INVITE Method [RFC3261] must support location 1256 conveyance. 1258 UAC-2 The SIP MESSAGE method [RFC3428] must support location 1259 conveyance. 1261 UAC-3 SIP Requests within a dialog should support location 1262 conveyance. 1264 UAC-4 Other SIP Requests may support location conveyance. 1266 UAC-5 There must be one, mandatory to implement means of 1267 transmitting location confidentially. 1269 Motivation: to guarantee interoperability. 1271 UAC-6 It must be possible for a UAC to update location conveyed 1272 at any time in a dialog, including during dialog 1273 establishment. 1275 Motivation: if a UAC has moved prior to the establishment of a 1276 dialog between UAs, the UAC must be able to send location 1277 information. If location has been conveyed, and the UA 1278 moves, the UAC must be able to update the location previously 1279 conveyed to other parties. 1281 UAC-7 The privacy and security rules established within [RFC3693] 1282 that would categorize SIP as a 'Using Protocol' must be met. 1284 UAC-8 The PIDF-LO [RFC4119] is a mandatory to implement format for 1285 location conveyance within SIP. 1287 Motivation: interoperability with other IETF location protocols and 1288 Mechanisms. 1290 UAC-9 There must be a mechanism for the UAC to request the UAS send 1291 its location. 1293 UAC-9 has been DEPRECATED by the SIP WG, due to the many 1294 problems this requirement would have caused if implemented. 1295 The solution is for the above UAS to send a new request to 1296 the original UAC with the UAS's location. 1298 UAC-10 There must be a mechanism to differentiate the ability of the 1299 UAC to convey location from the UACs lack of knowledge of its 1300 location 1302 Motivation: Failure to receive location when it is expected can 1303 happen because the UAC does not implement this extension, or 1304 because the UAC implements the extension, but does not know 1305 where the Target is. This may be, for example, due to the 1306 failure of the access network to provide a location 1307 acquisition mechanism the UAC supports. These cases must be 1308 differentiated. 1310 UAC-11 It must be possible to convey location to proxy servers 1311 along the path. 1313 Motivation: Location-based routing. 1315 A.2 Requirements for a UAS Receiving Location 1316 The following are the requirements for location conveyance by a UAS: 1318 UAS-1 SIP Responses must support location conveyance. 1320 Just as with UAC-9, UAS-1 has been DEPRECATED by the SIP WG, 1321 due to the many problems this requirement would have caused 1322 if implemented. The solution is for the above UAS to send a 1323 new request to the original UAC with the UAS's location. 1325 UAS-2 There must be a unique 4XX response informing the UAC it did 1326 not provide applicable location information. 1328 In addition, requirements UAC-5, 6, 7 and 8 also apply to the UAS. 1330 A.3 Requirements for SIP Proxies and Intermediaries 1332 The following are the requirements for location conveyance by a SIP 1333 proxies and intermediaries: 1335 Proxy-1 Proxy servers must be capable of adding a Location header 1336 field during processing of SIP requests. 1338 Motivation: Provide network assertion of location 1339 when UACs are unable to do so, or when network assertion is 1340 more reliable than UAC assertion of location 1342 Note: Because UACs connected to SIP signaling networks may have 1343 widely varying access network arrangements, including VPN 1344 tunnels and roaming mechanisms, it may be difficult for a 1345 network to reliably know the location of the endpoint. Proxy 1346 assertion of location is NOT RECOMMENDED unless the SIP 1347 signaling network has reliable knowledge of the actual 1348 location of the Targets. 1350 Proxy-2 There must be a unique 4XX response informing the UAC it 1351 did not provide applicable location information.