idnits 2.17.1 draft-ietf-sipcore-location-conveyance-04.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 26 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 580 has weird spacing: '...or code indic...' == Line 590 has weird spacing: '... ar o ...' == Line 594 has weird spacing: '... ar o ...' == Line 1008 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 (Oct 25, 2010) is 4925 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 885, but not defined == Unused Reference: 'RFC3264' is defined on line 1133, but no explicit reference was found in the text == Unused Reference: 'ID-GEO-ARCH' is defined on line 1169, 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 (~~), 13 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: April 25, 2011 Brian Rosen 5 Intended Status: Standards Track (PS) Jon Peterson 6 NeuStar 7 Oct 25, 2010 9 Location Conveyance for the Session Initiation Protocol 10 draft-ietf-sipcore-location-conveyance-04.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 April 25, 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 . . . . . . . . . . . . . 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 Objection, 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 point 152 to such Location Servers where prospective Location Recipients can 153 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 message (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. From a user interface 230 perspective, Bob the user won't know that this information was 231 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 3.3 Location Conveyed though a SIP Intermediary 237 In Figure 3, we introduce the idea of a SIP intermediary into the 238 example to illustrate the role of proxying in the location 239 architecture. This intermediary could be a SIP proxy or it could be 240 a back-to-back-user-agent (B2BUA). In this message flow, the SIP 241 intermediary could act as a LR, in addition to Bob. The primary use 242 case for intermediaries consuming location information is 243 location-based routing. In this case, the intermediary chooses a 244 next hop for the SIP request by consulting a specialized location 245 service which selects forwarding destinations based on geographical 246 location. In this case, the intermediary acts as a Location 247 Recipient. 249 Alice SIP Intermediary Bob LS 250 | | | | 251 | Request | | | 252 | w/Location | | | 253 |--------------->| | | 254 | | Request | | 255 | | w/Location | | 256 | |------------------>| | 257 | | | | 258 | | Response | | 259 | |<------------------| | 260 | Response | | | 261 |<---------------| | | 262 | | | | 264 Figure 3. Location Conveyed though a SIP Intermediary 266 However, the most common case will be one in which the SIP 267 intermediary receives a request with location information (conveyed 268 either by-value or by-reference) and does not know or care about 269 Alice's location, or support this extension, and merely passes it on 270 to Bob. In this case, the intermediary does not act as a Location 271 Recipient. 273 Note that an intermediary does not have to perform location-based 274 routing in order to be location recipient. It could be the case that 275 a SIP intermediary which does not perform location-based routing but 276 does care when Alice includes her location; for example, it could 277 care that the location information is complete or that it correctly 278 identifies where Alice is. The best example of this is 279 intermediaries that verify location information for emergency 280 calling, but it could also be for any location based routing - e.g., 281 contacting Pizza Hut, making sure that organization has Alice's 282 proper location in the initial SIP request. 284 There is another scenario in which the SIP intermediary cares about 285 location and is not an LR, one in which the intermediary inserts 286 another location of the Target, Alice in this case, into the 287 request, and forwards it. This secondary insertion is generally not 288 advisable because downstream SIP entities will not be given any 289 guidance about which location to believe is better, more reliable, 290 less prone to error, more granular, worse than the other location or 291 just plain wrong. 293 The only conceivable way forward, when a second location is placed 294 into the same SIP request by a SIP intermediary is to 295 take a "you break it, you bought it" philosophy with respect to the 296 inserting SIP intermediary. That entity becomes completely 297 responsible for all location within that SIP request (more on this 298 in Section 4). 300 3.4 SIP Intermediary Replacing Bad Location 302 If the SIP intermediary rejects the message due to unsuitable 303 location information (we are not going to discuss any other reasons 304 in this document, and there are many), the SIP response will 305 indicate there was 'Bad Location Information' in the SIP request, 306 and provide a location specific error code indicating what Alice 307 needs to do to send an acceptable request (see Figure 4 for this 308 scenario). 310 Alice SIP Intermediary Bob LS 311 | | | | 312 | Request | | | 313 | w/Location | | | 314 |--------------->| | | 315 | | | | 316 | Rejected | | | 317 | w/New Location | | | 318 |<---------------| | | 319 | | | | 320 | Request | | | 321 | w/New Location | | | 322 |--------------->| | | 323 | | Request | | 324 | | w/New Location | | 325 | |------------------>| | 326 | | | | 328 Figure 4. SIP Intermediary Replacing Bad Location 330 In this last use case, the SIP intermediary wishes to include a 331 Location Object indicating where it understands Alice to be. Thus, 332 it must inform her user agent what location she should include in 333 any subsequent SIP request that contains her location. In these 334 cases, the intermediary can reject Alice's request, through the SIP 335 response, convey to her the best way to repair the request in order 336 for the intermediary to accept it. 338 Overriding location information provided by the user requires a 339 deployment where an intermediary necessarily knows better than an 340 end user - after all, it could be that Alice has an on-board GPS, 341 and the SIP intermediary only knows her nearest cell tower. Which is 342 more accurate location information? Currently, there is no way to 343 tell which entity is more accurate, or which is wrong - for that 344 matter. This document will not specify how to indicate which 345 location is more accurate than another. If desired, intermediaries 346 may furthermore allow both Alice's internally generated location, as 347 well as the SIP intermediary's determination of where Alice, to 348 appear in the same SIP request (the resubmitted one), and permit 349 that to be forwarded to Bob. This case is discussed in more detail 350 in section 4.2 of this document. 352 As an aside, it is not envisioned that any SIP-based emergency 353 services request (i.e., IP-911, or 112 type of call attempt) will 354 receive a corrective 'Bad Location Information' response from an 355 intermediary. Most likely, the SIP intermediary would in that 356 scenario act a B2BUA and insert into the request by-value any 357 appropriate location information for the benefit of Public Safety 358 Answering Point (PSAP) call centers to expedite call reception by 359 the emergency services personnel; thereby, minimizing any delay in 360 call establishment time. The implementation of these specialized 361 deployments is, however, outside the scope of this document. 363 4. SIP Modifications for Geolocation Conveyance 365 The following sections detail the modifications 366 to SIP for location conveyance. 368 4.1 The Geolocation Header 370 This document defines "Geolocation" as a new SIP header field 371 registered by IANA, with the following ABNF [RFC5234]: 373 Geolocation-header = "Geolocation" HCOLON Geolocation-value 374 Geolocation-value = ( locationValue [ COMMA locationValue ] ) 375 / routing-param 376 locationValue = LAQUOT locationURI RAQUOT 377 *(SEMI geoloc-param) 378 locationURI = sip-URI / sips-URI / pres-URI 379 / http-URI / HTTPS-URI 380 / cid-url ; (from RFC 2392) 381 / absoluteURI ; (from RFC 3261) 382 geoloc-param = generic-param; (from RFC 3261) 383 routing-param = "routing-allowed" EQUAL "yes" / "no" 385 sip-URI, sips-URI and absoluteURI are defined according to [RFC3261]. 387 The pres-URI is defined in [RFC3859]. 389 HTTP-URI and HTTPS-URI are defined according to [RFC2616] and 390 [RFC2818], respectively. 392 The cid-url is defined in [RFC2392] to locate message body parts. 393 This URI type is present in a SIP request when location is conveyed 394 as a MIME body in the SIP message. 396 GEO-URIs [RFC5870] are not appropriate for usage the SIP Geolocation 397 header. 399 Other URI schemas used in the location URI MUST be reviewed against 400 the RFC 3693 [RFC3693] criteria for a Using Protocol. 402 The Geolocation header field has zero, one or two locationValues, 403 but MUST NOT contain more than two locationValue. A SIP intermediary 404 SHOULD NOT add location to a SIP request that already contains 405 location. This will quite often lead to confusion within LRs. 406 However, if a SIP intermediary were to add location, even if 407 location was not previously present in a SIP request, that SIP 408 intermediary is fully responsible for addressing the concerns of any 409 424 (Bad Location Information) SIP response it receives about this 410 location addition, and MUST NOT pass on (upstream) the 424 response. 412 The placement of the "routing-allowed" header field parameter, 413 strongly encouraged by [RFC5606], is outside the locationValue, and 414 MUST always be last in the header field value. The routing-allowed 415 parameter MUST be present, even when no locationValue is present. 416 This scenario sets the routing-allowed policy downstream along the 417 request's signaling path. This header field parameter only has the 418 values "=yes" or "=no". When this parameter is "=yes", the 419 locationValue can be used for routing decisions along the downstream 420 signaling path by intermediaries. If no routing-allowed parameter 421 is present in a SIP request, a SIP intermediary MAY insert this 422 value with a RECOMMENDED value of "no" by default. 424 When this parameter is "=no", this means no locationValue (inserted 425 by the originating UAC or any intermediary along the signaling path 426 can be used by any SIP intermediary to make routing decisions. 427 Intermediaries that attempt to use the location information for 428 routing purposes in spite of this counter indication may end up 429 routing the request improperly as a result. Sections 4.3 describes 430 the details on what a routing intermediary does if it determines it 431 needs to use the location in the SIP request in order to process the 432 message further. 434 The practical implication is that when the "routing-allowed" 435 parameter is set to "no", if a cid:url is present in the SIP 436 request, intermediaries MUST NOT view the location (because it is 437 not for intermediaries to view), and if a location URI is present, 438 intermediaries MUST NOT dereference it. UAs are allowed to view 439 location in the SIP request even when the "routing-allowed" 440 parameter is set to "no". An LR MUST by default consider the 441 "routing-allowed" header parameter as set to "no", with no 442 exceptions, unless the header field value is set to "yes". 444 If a routing-allowed parameter is parsed as set to "=yes", an 445 implementation MUST parse the rest of the SIP headers for another 446 instance of the Geolocation header value to determine if there is 447 another instance of the routing-allowed parameter set to "=no". If 448 this is the case, the behavior MUST be to process the "=no" 449 indication only, and ignore the "=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 following table extends the values in Tables 2 and 3 of RFC 3261 462 [RFC3261]. 464 Header field where proxy INV ACK CAN BYE REG OPT PRA 465 ---------------------------------------------------------------- 466 Geolocation R ar o - - o o o o 467 Geolocation 424 r o - - o o o o 469 Header field where proxy SUB NOT UPD MSG REF INF PUB 470 ---------------------------------------------------------------- 471 Geolocation R ar o o o o o o o 472 Geolocation 424 r o o o o o o o 474 Table 1: Summary of the Geolocation Header Field 476 The Geolocation header field MAY be included in any one of the 477 optional requests by a UA. A proxy MAY add the Geolocation header 478 field, but MUST NOT modify any pre-existing locationValue, including 479 the "routing-allowed" header field value. 481 A SIP intermediary MAY add a Geolocation header field if one is not 482 present - for example, when a user agent does not support the 483 Geolocation mechanism but their outbound proxy does and knows their 484 location, or any of a number of other use cases (see Section 3). 485 When adding a Geolocation header, a SIP intermediary MAY supply the 486 "routing-allowed" parameter if not yet present in the SIP request, 487 but MUST NOT add a "routing-allowed" parameter if one is already 488 present in this SIP request. 490 SIP implementations are advised to pay special attention to the 491 policy elements for location retransmission and retention described 492 in RFC 4119. 494 4.2 424 (Bad Location Information) Response Code 496 This SIP extension creates a new location-specific response code, 497 defined as follows, 499 424 (Bad Location Information) 501 The 424 (Bad Location Information) response code is a rejection of 502 the request due to its location contents, indicating location 503 information that was malformed or not satisfactory for the 504 recipient's purpose, or could not be dereferenced. 506 A SIP intermediary can also reject a location it receives from a 507 Target when it understands the Target to be in a different location. 508 The proper handling of this scenario, described in Section 3.4, is 509 for the SIP intermediary to include the proper location in the 424 510 Response. This SHOULD be included in the response as a MIME message 511 body (i.e., a location value), rather than as a URI; however, in 512 cases where the intermediary is willing to share location with 513 recipients but not with a user agent, a reference might be 514 necessary. 516 As mentioned in Section 3.4, it might be the case that the 517 intermediary does not want to chance providing less accurate 518 location information than the user agent; thus it will compose its 519 understanding of where the user agent is in a separate 520 element of the same PIDF-LO message body in the SIP response (which 521 also contains the Target's version of where it is). Therefore, both 522 locations are included - each with different elements. The 523 proper reaction of the user agent is to generate a new SIP request 524 that includes this composed location object, and send it towards the 525 original LR. SIP intermediaries can verify that subsequent requests 526 properly insert the suggested location information before forwarding 527 said requests. 529 SIP intermediaries MUST NOT add, modify or delete the location in a 530 424 response. This specifically applies to intermediaries that are 531 between the 424 response generator and the original UAC. All 532 respects of the Geolocation and Geolocation-Error headers and 533 PIDF-LO(s) MUST remain unchanged, never added to or deleted. 535 Section 4.3 describes a Geolocation-Error header field to provide 536 more detail about what was wrong with the location information in 537 the request. This header field MUST be included in the 424 response. 539 It is only appropriate to generate a 424 response when the 540 responding entity needs a locationValue and there are no 541 locationValues included in the SIP request that are usable by that 542 recipient, or as shown in Figure 4 of section 3.4. In this scenario, 543 a SIP intermediary is informing the upstream UA which location to 544 include in the next SIP request. 546 A 424 MUST NOT be sent in response to a request that lacks a 547 Geolocation header entirely, as the user agent in that case may not 548 support this extension at all. If a SIP intermediary inserted a 549 locationValue into a SIP request where one was not previously 550 present, it MUST take any and all responsibility for the corrective 551 action if it receives a 424 to a SIP request it sent. 553 A 424 (Bad Location Information) response is a final response within 554 a transaction, and MUST NOT terminate an existing dialog. 556 4.3 The Geolocation-Error Header 558 As discussed in Section 4.2, more granular error notifications 559 specific to location errors within a received request are required 560 if the UA is to know what was wrong within the original request. 561 The Geolocation-Error header field is used for this purpose. 563 The Geolocation-Error header field is used to convey 564 location-specific errors within a response. The Geolocation-Error 565 header field has the following ABNF [RFC5234]: 567 Geolocation-Error = "Geolocation-Error" HCOLON 568 locationErrorValue 569 locationErrorValue = location-error-arg 570 location-error-arg = location-error-code 571 *(SEMI location-error-params) 572 location-error-code = 1*3DIGIT 573 location-error-params = location-error-code-text 574 / generic-param ; from RFC3261 575 location-error-code-text = "code" EQUAL quoted-string ; from RFC3261 577 The Geolocation-Error header field MUST contain only one 578 locationErrorValue to indicate what was wrong with the locationValue 579 the Location Recipient determined was bad. The locationErrorValue 580 contains a 3-digit error code indicating what was wrong with the 581 location in the request. Each error code has a corresponding quoted 582 error text string that is human understandable. This text string is 583 OPTIONAL, but RECOMMENDED for human readability. 585 The following table extends the values in Table 2&3 of RFC 3261 586 [RFC3261]. 588 Header field where proxy INV ACK CAN BYE REG OPT PRA 589 ---------------------------------------------------------------- 590 Geolocation-Error r ar o - - o o o o 592 Header field where proxy SUB NOT UPD MSG REF INF PUB 593 ---------------------------------------------------------------- 594 Geolocation-Error r ar o o o o o o o 596 Table 2: Summary of the Geolocation-Error Header Field 598 The Geolocation-Error header field MAY be included in any response 599 to one of the above SIP requests, so long as a Geolocation 600 locationValue was in the request part of the transaction. For 601 example, Alice includes her location in an INVITE to Bob. Bob can 602 accept this INVITE, thus creating a dialog, even though his UA 603 determined the location contained in the INVITE was bad. Bob merely 604 includes a Geolocation-Error header value in the 200 OK to the 605 INVITE informing Alice the INVITE was accepted but the location 606 provided was bad. The SIP requests included in table 2 above are the 607 ones allowed to optionally contain the Geolocation header field (see 608 section 4.1). 610 If, on the other hand, Bob cannot accept Alice's INVITE without a 611 suitable location, a 424 (Bad Location Information) is sent. This 612 message flow is shown in Figures 1, 2 or 3 in Section 3. 614 The following subsections provide an initial list of location 615 based errors for any SIP non-100 response, including the new 424 616 (Bad Location Information) response. These error codes are divided 617 into 4 categories, based on how the response receiver should react 618 to these errors. 620 o 1XX errors mean the LR cannot process the location within the 621 request. 623 o 2XX errors mean the LR wants the LS to send new or updated 624 location information, perhaps with a delay associated with when 625 to send the request. 627 o 3XX errors mean some specific permission is necessary to process 628 the included location information. 630 o 4XX errors mean there was trouble dereferencing the Location URI 631 sent. 633 Within these 4 number ranges, there is a top level error as follows: 635 Geolocation-Error: 100 "Cannot Process Location" 637 Geolocation-Error: 200 "Retry Location Later with device updated 638 location" 640 Geolocation-Error: 300 "Permission To Use Location Information" 642 Geolocation-Error: 400 "Dereference Failure" 644 There are two specific Geolocation-Error codes necessary to include 645 in this document, both have to do with permissions necessary to 646 process the SIP request; they are 648 Geolocation-Error: 301 "Permission To Retransmit Location 649 Information to a Third Party" 651 This location error is specific to having the Presence Information 652 Data Format (PIDF-LO) [RFC4119] element set 653 to "=no". This location error is stating it requires permission 654 (i.e., PIDF-LO element set to "=yes") to 655 process this SIP request further. If the LS sending the location 656 information does not want to give this permission, it will not reset 657 this permission in a new request. If the LS wants this message 658 processed without this permission reset, it MUST choose another 659 logical path (if one exists). 661 Geolocation-Error: 302 "Permission to Route based on Location 662 Information" 664 This location error is specific to having the locationValue header 665 parameter set to "=no". This location error is 666 stating it requires permission (i.e., a set to 667 "=yes") to process this SIP request further. If the LS sending the 668 location information does not want to give this permission, it will 669 not reset this permission in a new request. If the LS wants this 670 message processed without this permission reset, it MUST choose 671 another logical path (if one exists). 673 4.4 The 'geolocation' Option Tag 675 This document creates and registers with the IANA one new option 676 tag: "geolocation". This option tag is to be used, as defined in 677 [RFC3261], in the Require, Supported and Unsupported header fields. 679 4.5 Location URIs in Message Bodies 681 In the case where a location recipient sends a 424 response and 682 wishes to communicate suitable location by reference rather than by 683 value, the 424 MUST include a content-indirection body per RFC 4483. 685 4.6 Location URIs Allowed 687 The following is part of the discussion started in Section 3, Figure 688 2, which introduced the concept of sending location indirectly. 690 If a location URI is included in a SIP request, it SHOULD be a SIP-, 691 SIPS- or PRES-URI. When PRES: is used, as defined in [RFC3856], if 692 the resulting resolution resolves to a SIP: or SIPS: URI, this 693 section applies. These schemes MUST be implemented according to 694 this document. 696 See [ID-GEO-FILTERS] for more details on dereferencing location. 698 An HTTP: [RFC2616] or HTTPS: URI [RFC2818] are also allowed, and 699 SHOULD be dereferenced according to [ID-HELD-DEREF]. 701 5. Geolocation Examples 703 5.1 Location-by-value (in Coordinate Format) 705 This example shows an INVITE message with a coordinate location. In 706 this example, the SIP request uses a sips-URI [RFC3261], meaning 707 this message is protected using TLS on a hop-by-hop basis. 709 INVITE sips:bob@biloxi.example.com SIP/2.0 710 Via: SIPS/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bK74bf9 711 Max-Forwards: 70 712 To: Bob 713 From: Alice ;tag=9fxced76sl 714 Call-ID: 3848276298220188511@atlanta.example.com 715 Geolocation: 716 ;routing-allowed=no 717 Supported: geolocation 718 Accept: application/sdp, application/pidf+xml 719 CSeq: 31862 INVITE 720 Contact: 721 Content-Type: multipart/mixed; boundary=boundary1 722 Content-Length: ... 724 --boundary1 726 Content-Type: application/sdp 728 ...SDP goes here 730 --boundary1 732 Content-Type: application/pidf+xml 733 Content-ID: 734 735 743 744 745 746 747 748 32.86726 -97.16054 749 750 751 752 753 false 754 755 2010-11-14T20:00:00Z 756 757 758 802.11 759 760 mac:1234567890ab 761 2010-11-04T20:57:29Z 762 763 764 --boundary1-- 765 The Geolocation header field from the above INVITE: 767 Geolocation: 769 ... indicates the content-ID location [RFC2392] within the multipart 770 message body of where location information is. An assumption can be 771 made that SDP is the other message body part. The "cid:" eases 772 message body parsing by disambiguating the MIME body that contains 773 the location information associated with this request. 775 If the Geolocation header field did not contain a "cid:" scheme, for 776 example, it could look like this location URI: 778 Geolocation: 780 ... the existence of a non-"cid:" scheme indicates this is a 781 location URI, to be dereferenced to learn the Target's location. Any 782 node wanting to know where user "target123" is would subscribe to 783 that user at server5 to dereference the sips-URI (see Figure 3 in 784 section 3 for this message flow). 786 5.2 Two Locations Composed in Same Location Object Example 788 This example shows the INVITE message after a SIP intermediary 789 rejected the original INVITE (say, the one in section 5.1). This 790 INVITE contains the composed LO sent by the SIP intermediary which 791 includes where the intermediary understands Alice to be. The rules 792 of RFC 5491 [RFC5491] are followed in this construction. 794 This example is here, but should not be taken as occurring very 795 often. In fact, this is believed to be a corner case of location 796 conveyance applicability. 798 INVITE sips:bob@biloxi.example.com SIP/2.0 799 Via: SIPS/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bK74bf0 800 Max-Forwards: 70 801 To: Bob 802 From: Alice ;tag=9fxced76sl 803 Call-ID: 3848276298220188512@atlanta.example.com 804 Geolocation: 805 ;routing-allowed=no 806 Supported: geolocation 807 Accept: application/sdp, application/pidf+xml 808 CSeq: 31863 INVITE 809 Contact: 810 Content-Type: multipart/mixed; boundary=boundary1 811 Content-Length: ... 813 --boundary1 815 Content-Type: application/sdp 816 ...SDP goes here 818 --boundary1 820 Content-Type: application/pidf+xml 821 Content-ID: 822 823 831 832 833 834 835 836 32.86726 -97.16054 837 838 839 840 841 false 842 843 2010-11-14T20:00:00Z 844 845 846 802.11 847 848 mac:1234567890ab 849 2010-11-04T20:57:29Z 850 851 852 853 854 855 US 856 Texas 857 Colleyville 858 Treemont 859 Circle 860 3913 861 1 862 Haley's Place 863 76034 864 865 866 867 false 868 869 2010-11-14T20:00:00Z 870 871 872 triangulation 873 874 2010-11-04T12:28:04Z 875 876 877 --boundary1-- 879 6. Geopriv Privacy Considerations 881 Location information is considered by most to be highly sensitive 882 information, requiring protection from eavesdropping and altering in 883 transit. [RFC3693] originally articulated rules to be followed by 884 any protocol wishing to be considered a "Using Protocol", specifying 885 how a transport protocol meets those rules. [ID-GEOPRIV-ARCH] 886 updates the guidance in RFC3693 to include subsequently-introduced 887 entities and concepts in the geolocation architecture. 888 Implementations of this SIP location conveyance mechanism MUST 889 adhere to the guidance given in RFC3693 and its successors, 890 including (but not limited to) the handling of rules for retention 891 and retransmission. 893 7. Security Considerations 895 Conveyance of physical location of a UA raises privacy concerns, 896 and depending on use, there probably will be authentication and 897 integrity concerns. This document calls for conveyance to 898 be accomplished through secure mechanisms, like S/MIME encrypting 899 message bodies (although this is not widely deployed), TLS 900 protecting the overall signaling or conveyance location by-reference 901 and requiring all entities that dereference location to authenticate 902 themselves. In location-based routing cases, encrypting the 903 location payload with an end-to-end mechanism such as S/MIME is 904 problematic, because one or more proxies on the path need the 905 ability to read the location information to retarget the message to 906 the appropriate new destination UAS. Data can only be encrypted to a 907 particular, anticipated target, and thus if multiple recipients need 908 to inspect a piece of data, and those recipients cannot be predicted 909 by the sender of data, encryption is not a very feasible choice. 910 Securing the location hop-by-hop, using TLS, protects the message 911 from eavesdropping and modification in transit, but exposes the 912 information to all proxies on the path as well as the endpoint. In 913 most cases, the UA has no trust relationship with the proxy or 914 proxies providing location-based routing services, so such 915 end-to-middle solutions might not be appropriate either. 917 When location information is conveyed by reference, however, one can 918 properly authenticate and authorize each entity that wishes to 919 inspect location information. This does not require that the sender 920 of data anticipate who will receive data, and it does permit 921 multiple entities to receive it securely, but it does not however 922 obviate the need for pre-association between the sender of data and 923 any prospective recipients. Obviously, in some contexts this 924 pre-association cannot be presumed; when it is not, effectively 925 unauthenticated access to location information must be permitted. In 926 this case, choosing pseudo-random URIs for location by-reference, 927 coupled with path encryption like SIPS, can help to ensure that only 928 entities on the SIP signaling path learn the URI, and thus restores 929 rough parity with sending location by-value. 931 Location information is especially sensitive when the identity of 932 its Target is obvious. Note that there is the ability, according to 933 [RFC3693] to have an anonymous identity for the Target's location. 934 This is accomplished by use of an unlinkable pseudonym in the 935 "entity=" attribute of the element [RFC4479]. Though, 936 this can be problematic for routing messages based on location 937 (covered in the document above). Moreover, anyone fishing for 938 information would correlate the identity at the SIP layer with that 939 of the location information referenced by SIP signaling. 941 When a UA inserts location, the UA sets the policy on whether to 942 reveal its location along the signaling path - as discussed in 943 Section 4, as well as flags in the PIDF-LO [RFC4119]. UAC 944 implementations MUST make such capabilities conditional on explicit 945 user permission, and MUST alert the user that location is being 946 conveyed. 948 This SIP extension offers the default ability to require permission 949 to view location while the SIP request is in transit. The default 950 for this is set to "no". There is an error explicitly describing 951 how an intermediary asks for permission to view the Target's 952 location, plus a rule stating the user has to be made aware of this 953 permission request. 955 There is no end-to-end integrity on any locationValue or 956 locationErrorValue header field parameter (or middle-to-end if the 957 value was inserted by a intermediary), so recipients of either 958 header field need to implicitly trust the header field contents, and 959 take whatever precautions each entity deems appropriate given this 960 situation. 962 8. IANA Considerations 964 The following are the IANA considerations made by this SIP 965 extension. Modifications and additions to these registrations 966 require a standards track RFC (Standards Action). 968 [Editor's Note: RFC-Editor - within the IANA section, please 969 replace "this doc" with the assigned RFC number, 970 if this document reaches publication.] 972 8.1 IANA Registration for the SIP Geolocation Header Field 974 The SIP Geolocation Header Field is created by this document, with 975 its definition and rules in Section 4.1 of this document, and should 976 be added to the IANA sip-parameters registry, in the portion titled 977 "Header Field Parameters and Parameter Values". 979 Predefined 980 Header Field Parameter Name Values Reference 981 ---------------- ------------------- ---------- --------- 982 Geolocation routing-allowed yes [this doc] 984 8.2 IANA Registration for New SIP 'geolocation' Option Tag 986 The SIP option tag "geolocation" is created by this document, with 987 the definition and rule in Section 4.4 of this document, to be added 988 to the IANA sip-parameters registry. 990 8.3 IANA Registration for 424 Response Code 992 Reference: RFC-XXXX (i.e., this document) 993 Response code: 424 (recommended number to assign) 994 Default reason phrase: Bad Location Information 996 This SIP Response code is defined in section 4.2 of this document. 998 8.4 IANA Registration of New Geolocation-Error Header Field 1000 The SIP Geolocation-error header field is created by this document, 1001 with its definition and rules in Section 4.3 of this document, to be 1002 added to the IANA sip-parameters registry, in the portion titled 1003 "Header Field Parameters and Parameter Values". 1005 Predefined 1006 Header Field Parameter Name Values Reference 1007 ----------------- ------------------- ---------- --------- 1008 Geolocation-Error code= yes* [this doc] 1010 * see section 8.5 for the newly created values. 1012 8.5 IANA Registration for the SIP Geolocation-Error Codes 1014 New location specific Geolocation-Error codes are created by this 1015 document, and registered in a new table in the IANA sip-parameters 1016 registry. Details of these error codes are in Section 4.3 of this 1017 document. 1019 Geolocation-Error codes 1020 ----------------------- 1021 Geolocation-Error codes provide reason for the error discovered by 1022 Location Recipients, categorized by action to be taken by error 1023 recipient. 1025 Code Description Reference 1026 ---- --------------------------------------------------- --------- 1027 100 "Cannot Process Location" [this doc] 1029 200 "Retry Location Later with device updated location" [this doc] 1031 300 "Permission To Use Location Information" [this doc] 1033 301 "Permission To Retransmit Location Information to a Third Party" 1034 [this doc] 1036 302 "Permission to Route based on Location Information" [this doc] 1038 400 "Dereference Failure" [this doc] 1040 8.6 IANA Registration of Location URI Schemes 1042 This document directs IANA to create a new set of parameters in a 1043 separate location from SIP and Geopriv, called the "Location 1044 Reference URI" registry, containing the URI scheme, the 1045 Content-Type, and the reference, as follows: 1047 URI Scheme Content-Type Reference 1048 ---------- ------------ --------- 1049 SIP: [this doc] 1050 SIPS: [this doc] 1051 PRES: [this doc] 1052 HTTP: [this doc] 1053 HTTPS: [this doc] 1055 Additions to this registry must be defined in a permanent and 1056 readily available specification (this is the "Specification 1057 Required" IANA policy defined in [RFC5226]). 1059 9. Acknowledgements 1061 To Dave Oran for helping to shape this idea. 1063 To Dean Willis for guidance of the effort. 1065 To Allison Mankin, Dick Knight, Hannes Tschofenig, Henning 1066 Schulzrinne, James Winterbottom, Jeroen van Bemmel, Jean-Francois 1067 Mule, Jonathan Rosenberg, Keith Drage, Marc Linsner, Martin Thomson, 1068 Mike Hammer, Ted Hardie, Shida Shubert, Umesh Sharma, Richard 1069 Barnes, Dan Wing, Matt Lepinski, John Elwell and Jacqueline Lee for 1070 constructive feedback and nits checking. 1072 Special thanks to Paul Kyzivat for his help with the ABNF in this 1073 document and to Robert Sparks for many helpful comments and the 1074 proper construction of the Geolocation-Error header field. 1076 And finally, to Spencer Dawkins for giving this doc a good scrubbing 1077 to make it more readable. 1079 10. References 1081 10.1 Normative References 1083 [RFC3261] J. Rosenberg, H. Schulzrinne, G. Camarillo, A. Johnston, J. 1084 Peterson, R. Sparks, M. Handley, and E. Schooler, "SIP: 1085 Session Initiation Protocol", RFC 3261, May 2002. 1087 [RFC4119] J. Peterson, "A Presence-based GEOPRIV Location Object 1088 Format", RFC 4119, December 2005 1090 [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate 1091 Requirement Levels", RFC 2119, March 1997 1093 [RFC2392] E. Levinson, " Content-ID and Message-ID Uniform Resource 1094 Locators", RFC 2392, August 1998 1096 [RFC3856] J. Rosenberg, " A Presence Event Package for the Session 1097 Initiation Protocol (SIP)", RFC 3856, August 2004 1099 [RFC3859] J. Peterson, "Common Profile for Presence (CPP)", RFC 3859, 1100 August 2004 1102 [RFC3428] B. Campbell, Ed., J. Rosenberg, H. Schulzrinne, C. Huitema, 1103 D. Gurle, "Session Initiation Protocol (SIP) Extension for 1104 Instant Messaging" , RFC 3428, December 2002 1106 [RFC3311] J. Rosenberg, "The Session Initiation Protocol (SIP) UPDATE 1107 Method", RFC 3311, October 2002 1109 [RFC3265] Roach, A, "Session Initiation Protocol (SIP)-Specific 1110 Event Notification", RFC 3265, June 2002. 1112 [RFC3262] Rosenberg, J. and H. Schulzrinne, "Reliability of 1113 Provisional Responses in Session Initiation Protocol (SIP)", 1114 RFC 3262, June 2002. 1116 [RFC2976] S. Donovan, "The SIP INFO Method", RFC 2976, Oct 2000 1118 [RFC3515] R. Sparks, "The Session Initiation Protocol (SIP) Refer 1119 Method", RFC 3515, April 2003 1121 [RFC3903] Niemi, A, "Session Initiation Protocol (SIP) Extension 1122 for Event State Publication", RFC 3903, October 2004. 1124 [RFC5234] Crocker, D., Ed., and P. Overell, "Augmented BNF for Syntax 1125 Specifications: ABNF", STD 68, RFC 5234, January 2008. 1127 [RFC5226] T. Narten, H. Alvestrand, "Guidelines for Writing an IANA 1128 Considerations Section in RFCs", RFC 5226, May 2008 1130 [RFC4479] J. Rosenberg, "A Data Model for Presence", RFC 4479, July 1131 2006 1133 [RFC3264] J. Rosenberg, H. Schulzrinne, "The Offer/Answer Model with 1134 Session Description Protocol", RFC 3264, June 2002 1136 [RFC4483] E. Berger, "A Mechanism for Content Indirection in SIP", RFC 1137 4483, May 2006 1139 [RFC5491] J. Winterbottom, M. Thomson, H. Tschofenig, "GEOPRIV PIDF-LO 1140 Usage Clarification, Considerations, and Recommendations ", 1141 RFC 5491, March 2009 1143 [RFC5870] A. Mayrhofer, C. Spanring, "A Uniform Resource Identifier 1144 for Geographic Locations ('geo' URI)", RFC 5870, June 2010 1146 [RFC5606] J. Peterson, T. Hardie, J. Morris, "Implications of 1147 'retransmission-allowed' for SIP Location Conveyance", 1148 RFC5606, Oct 2008 1150 [RFC2616] R. Fielding, J. Gettys, J., Mogul, H. Frystyk, L., 1151 Masinter, P. Leach, T. Berners-Lee, "Hypertext Transfer 1152 Protocol - HTTP/1.1", RFC 2616, June 1999 1154 10.2 Informative References 1156 [RFC3693] J. Cuellar, J. Morris, D. Mulligan, J. Peterson. J. Polk, 1157 "Geopriv Requirements", RFC 3693, February 2004 1159 [RFC2818] E. Rescorla, "HTTP Over TLS", RFC 2818, May 2000 1161 [ID-GEO-FILTERS] R. Mahy, B. Rosen, H. Tschofenig, "Filtering Location 1162 Notifications in SIP", draft-ietf-geopriv-loc-filters, "work 1163 in progress", March 2010 1165 [ID-HELD-DEREF] J. Winterbottom, H. Tschofenig, H. Schulzrinne, M. 1166 Thomson, M. Dawson, "A Location Dereferencing Protocol Using 1167 HELD", "work in progress", September 2010 1169 [ID-GEO-ARCH] R. Barnes, M. Lepinski, A. Cooper, J, Morris, H. 1170 Tschofenig, H. Schulzrinne, "An Architecture for Location 1171 and Location Privacy in Internet Applications", 1172 draft-ietf-geopriv-arch, "work in progress", October 2010 1174 Author Addresses 1176 James Polk 1177 Cisco Systems 1178 3913 Treemont Circle 1179 Colleyville, Texas 76034 1181 33.00111N 1182 96.68142W 1184 Phone: +1-817-271-3552 1185 Email: jmpolk@cisco.com 1187 Brian Rosen 1188 NeuStar, Inc. 1189 470 Conrad Dr. 1190 Mars, PA 16046 1192 40.70497N 1193 80.01252W 1195 Phone: +1 724 382 1051 1196 Email: br@brianrosen.net 1198 Jon Peterson 1199 NeuStar, Inc. 1201 Email: jon.peterson@neustar.biz 1203 Appendix A. Requirements for SIP Location Conveyance 1205 The following subsections address the requirements placed on the 1206 UAC, the UAS, as well as SIP proxies when conveying location. If a 1207 requirement is not obvious in intent, a motivational statement is 1208 included below it. 1210 A.1 Requirements for a UAC Conveying Location 1212 UAC-1 The SIP INVITE Method [RFC3261] must support location 1213 conveyance. 1215 UAC-2 The SIP MESSAGE method [RFC3428] must support location 1216 conveyance. 1218 UAC-3 SIP Requests within a dialog should support location 1219 conveyance. 1221 UAC-4 Other SIP Requests may support location conveyance. 1223 UAC-5 There must be one, mandatory to implement means of 1224 transmitting location confidentially. 1226 Motivation: to guarantee interoperability. 1228 UAC-6 It must be possible for a UAC to update location conveyed 1229 at any time in a dialog, including during dialog 1230 establishment. 1232 Motivation: if a UAC has moved prior to the establishment of a 1233 dialog between UAs, the UAC must be able to send location 1234 information. If location has been conveyed, and the UA 1235 moves, the UAC must be able to update the location previously 1236 conveyed to other parties. 1238 UAC-7 The privacy and security rules established within [RFC3693] 1239 that would categorize SIP as a 'Using Protocol' must be met. 1241 UAC-8 The PIDF-LO [RFC4119] is a mandatory to implement format for 1242 location conveyance within SIP. 1244 Motivation: interoperability with other IETF location protocols and 1245 Mechanisms. 1247 UAC-9 There must be a mechanism for the UAC to request the UAS send 1248 its location. 1250 UAC-9 has been DEPRECATED by the SIP WG, due to the many 1251 problems this requirement would have caused if implemented. 1252 The solution is for the above UAS to send a new request to 1253 the original UAC with the UAS's location. 1255 UAC-10 There must be a mechanism to differentiate the ability of the 1256 UAC to convey location from the UACs lack of knowledge of its 1257 location 1259 Motivation: Failure to receive location when it is expected can 1260 happen because the UAC does not implement this extension, or 1261 because the UAC implements the extension, but does not know 1262 where the Target is. This may be, for example, due to the 1263 failure of the access network to provide a location 1264 acquisition mechanism the UAC supports. These cases must be 1265 differentiated. 1267 UAC-11 It must be possible to convey location to proxy servers 1268 along the path. 1270 Motivation: Location-based routing. 1272 A.2 Requirements for a UAS Receiving Location 1274 The following are the requirements for location conveyance by a UAS: 1276 UAS-1 SIP Responses must support location conveyance. 1278 Just as with UAC-9, UAS-1 has been DEPRECATED by the SIP WG, 1279 due to the many problems this requirement would have caused 1280 if implemented. The solution is for the above UAS to send a 1281 new request to the original UAC with the UAS's location. 1283 UAS-2 There must be a unique 4XX response informing the UAC it did 1284 not provide applicable location information. 1286 In addition, requirements UAC-5, 6, 7 and 8 also apply to the UAS. 1288 A.3 Requirements for SIP Proxies and Intermediaries 1290 The following are the requirements for location conveyance by a SIP 1291 proxies and intermediaries: 1293 Proxy-1 Proxy servers must be capable of adding a Location header 1294 field during processing of SIP requests. 1296 Motivation: Provide network assertion of location 1297 when UACs are unable to do so, or when network assertion is 1298 more reliable than UAC assertion of location 1300 Note: Because UACs connected to SIP signaling networks may have 1301 widely varying access network arrangements, including VPN 1302 tunnels and roaming mechanisms, it may be difficult for a 1303 network to reliably know the location of the endpoint. Proxy 1304 assertion of location is NOT RECOMMENDED unless the SIP 1305 signaling network has reliable knowledge of the actual 1306 location of the Targets. 1308 Proxy-2 There must be a unique 4XX response informing the UAC it 1309 did not provide applicable location information.