idnits 2.17.1 draft-ietf-sip-location-conveyance-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1735. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1711. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1718. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1724. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == It seems as if not all pages are separated by form feeds - found 0 form feeds but 35 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 Copyright Line does not match the current year == Line 282 has weird spacing: '... Rr ar ...' == Line 286 has weird spacing: '... Rr ar ...' == Line 990 has weird spacing: '...ontents of th...' == 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. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. 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: 'RFC3851' is mentioned on line 623, but not defined ** Obsolete undefined reference: RFC 3851 (Obsoleted by RFC 5751) ** Downref: Normative reference to an Informational RFC: RFC 3693 ** Obsolete normative reference: RFC 2393 (ref. 'RFC2392') (Obsoleted by RFC 3173) ** Obsolete normative reference: RFC 3265 (Obsoleted by RFC 6665) -- Obsolete informational reference (is this intentional?): RFC 3825 (Obsoleted by RFC 6225) Summary: 5 errors (**), 0 flaws (~~), 8 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SIP Working Group James Polk 3 Internet Draft Cisco Systems 4 Expiration: July 2nd, 2007 Brian Rosen 5 NeuStar 7 Session Initiation Protocol Location Conveyance 8 draft-ietf-sip-location-conveyance-06.txt 9 Jan 2nd, 2007 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six 24 months and may be updated, replaced, or obsoleted by other documents 25 at any time. It is inappropriate to use Internet-Drafts as 26 reference material or to cite them other than as "work in 27 progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on July 2nd, 2007. 37 Copyright Notice 39 Copyright (C) The IETF Trust (2007). 41 Abstract 43 This document defines an extension to the Session Initiation 44 Protocol (SIP) to convey geographic location information from one 45 SIP entity to another SIP entity. The extension covers end to end 46 conveyance as well as location-based routing, where proxy servers 47 make routing decisions based on the location of the UAC. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 52 2. Conventions used in this document . . . . . . . . . . . . . . 4 53 3. Mechanisms . . . . . . . . . . . . . . . . . . . . . . . . . 4 54 3.1 Overview of SIP Location Conveyance . . . . . . . . . . . 4 55 3.2 The Geolocation Header . . . . . . . . . . . . . . . . . 5 56 3.3 424 (Bad Location Information) Response Code . . . . . . 6 57 3.4 New Warning Codes for Location Error Granularity . . . . 7 58 3.5 The Geolocation Option Tag . . . . . . . . . . . . . . . 13 59 3.6 Using sip/sips/pres as a Dereference Protocol . . . . . . 13 60 4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 13 61 4.1 Location-by-value (Coordinate Format) . . . . . . . . . . 14 62 4.2 Location-by-value (Civic Format) . . . . . . . . . . . . 15 63 4.3 Location-by-reference . . . . . . . . . . . . . . . . . . 17 64 5. SIP Element Behavior . . . . . . . . . . . . . . . . . . . . 17 65 5.1 UAC Behavior . . . . . . . . . . . . . . . . . . . . . . 18 66 5.2 UAS Behavior . . . . . . . . . . . . . . . . . . . . . . 19 67 5.3 Proxy Behavior . . . . . . . . . . . . . . . . . . . . . 20 68 6. Special Considerations for Emergency Calls . . . . . . . . . 22 69 7. Geopriv Privacy Considerations . . . . . . . . . . . . . . . 23 70 8. Security Considerations . . . . . . . . . . . . . . . . . . . 23 71 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . 24 72 9.1 IANA Registration for New SIP Geolocation Header . . . . 24 73 9.2 IANA Registration for New SIP Geolocation Option Tag . . 24 74 9.3 IANA Registration for New 4XX Response Code . . . . . . . 24 75 9.4 IANA Registration of New Warning Codes for Location . . . 24 76 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 25 77 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 25 78 11.1 Normative References . . . . . . . . . . . . . . . . . 25 79 11.2 Informative References . . . . . . . . . . . . . . . . . 26 80 Author Information . . . . . . . . . . . . . . . . . . . . . 26 81 Appendix A. Requirements for SIP Location Conveyance . . . . 27 82 Appendix B. Changes from Prior Versions . . . . . . . . . . 29 83 Intellectual Property and Copyright Statements . . . . . . . 34 85 1. Introduction 87 This document describes how Location can be "conveyed" (that is, 88 sent on the Internet) from a SIP user agent, or in some 89 circumstances a proxy server acting on behalf of a user agent, to 90 another entity using the SIP [RFC3261] protocol. Here "Location" is 91 a description of the physical geographical area where a User Agent 92 currently exists. We use the term "conveyance" to distinguish other 93 circumstances when a location is used such as how the entity 94 conveying location using this extension determined where the 95 location was (using, for example, an Assisted GPS mechanism) or a 96 protocol by which the entity acquired the location it is conveying 97 from another entity. 99 Geographic location in the IETF is discussed in RFC 3693 (Geopriv 100 Requirements) [RFC3693]. It defines a "target" as the entity whose 101 location is being transmitted, in this case, it is the user agent's 102 (UA) location. A [RFC3693] "using protocol" defines how a "location 103 server" transmits a "location object" to a "location recipient" 104 while maintaining the contained privacy intentions of the target 105 intact. This document describes the extension to SIP for how it 106 complies with the using protocol requirements, where the location 107 server is a User Agent or Proxy Server and the location recipient is 108 another User Agent or Proxy Server. 110 Location can be transmitted by-value or by-reference. The "value" 111 used in this document is a location object as described in 112 [RFC4119], that is, a PIDF-LO. Location-by-value refers to a user 113 agent including a PIDF-LO as a body part of a SIP message, sending 114 that location object to another SIP element. Location-by-reference 115 refers to a user agent or proxy server including a URI in a SIP 116 message which can be exchanged by a location recipient for a 117 location object, in the form of a PIDF-LO. 119 As recited in RFC3693, location often must be kept private. The 120 location object (PIDF-LO) contains rules which are binding on the 121 location recipient and controls onward distribution and retention of 122 the location. This document describes the security and privacy 123 considerations that must be applied to location conveyed with SIP. 125 Often, location is sent from the User Agent Client to the User Agent 126 Server, or vice versa for purposes that are beyond the scope of this 127 document. Another use for location is location-based routing of a 128 SIP request, where the choice of the next hop (and usually, the 129 outgoing Request URI) is determined by the location of the UAC which 130 is in the message by-value or by-reference. This document describes 131 how location may be conveyed from the UAC, or a proxy acting on its 132 behalf, to a routing proxy. How the location is actually used to 133 determine the next hop or Request-URI is beyond the scope of this 134 document. 136 The Geolocation header is introduced to signify that location is 137 included in a SIP message to provide either a content identifier 138 (cid:) pointer to the body part containing the UAs PIDF-LO, or a 139 location-by-reference URI that may subsequently be "dereferenced" by 140 a using protocol (which may be SIP or another protocol). 142 In this document, we frequently refer to the "emergency case". This 143 refers to a specific, important use of sip location conveyance where 144 the location of the caller is used to determine which Public Safety 145 Answering Point (PSAP) should receive an emergency call request for 146 help (e.g. a call to 1-1-2 or 9-1-1). This is an example of 147 location-based routing. The location conveyed is also used by the 148 PSAP to dispatch first responders to the caller's location. There 149 are special security considerations which make the emergency case 150 unique, compared to a normal location conveyance within SIP. 152 This document is intended to become a standards track RFC. 154 2. Conventions used in this document 156 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 157 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and 158 "OPTIONAL" in this document are to be interpreted as described 159 in [RFC2119]. 161 3. Mechanisms 163 3.1 Overview of SIP Location Conveyance 165 This document creates a new SIP header: Geolocation. The 166 Geolocation header contains either a URI which may be a "cid:" URI 167 (Content Identification, per [RFC2392], or a location-by-reference 168 URI to be dereferenced by a location recipient to retrieve the 169 location of the UAC. 171 Where the Geolocation header contains a "cid:", the URI points to a 172 message body that is in the form of a PIDF [RFC3863], which was 173 extended in [RFC4119] to include location, as a PIDF-LO. This is 174 location-by-value, the actual location information in the PIDF-LO is 175 included in the body of the message. 177 If the URI in the Geolocation header is a scheme other than "cid:", 178 another protocol operation is needed by the message recipient to 179 obtain the location of the target (UA). This is 180 location-by-reference. This document describes how a SIP presence 181 subscription [RFC3856] can be used as a dereference protocol. 183 The Geolocation header, either with the PIDF-LO in a body or as a 184 location-by-reference URI, may be included by a User Agent in a 185 message. A proxy server may assert location of the UA by inserting 186 the header, which must specify a location-by-reference URI. Since 187 body parts may not be inserted by a proxy server, location-by-value 188 cannot be inserted by a proxy. 190 The Geolocation header may have parameters that are associated 191 with a URI in the header. The "inserted-by" parameter has values of 192 "endpoint" or "server", indicative of which entry added location to 193 the message. This header parameter MAY be added every time a new 194 location is added into a message. 196 If a SIP message is routed within the network based on the location 197 contained within that message, the "message-routed-on-this-uri" 198 parameter MUST be added as a header parameter of the URI used to 199 route the message. Once a header parameter is added to a 200 Geolocation header, it SHOULD NOT be deleted in transit to the 201 ultimate destination. 203 There is no mechanism by which the veracity of these parameters can 204 be verified. They are hints to downstream entities on how the 205 location information in the message was originated and used. 207 This document describes an extension to PIDF-LO, the 208 "routing-query-allowed" element, defined in the 'usage-rules' 209 element. When set, this allows an element receiving location to 210 transmit the location to another element to obtain routing 211 information. When used in conjunction with the 212 "retransmission-allowed" element, the rule maker can control 213 distribution of the location information for location-based routing. 215 This document also creates a new option tag: Geolocation, to 216 indicate support for the Geolocation extension. A new error message 217 (424 Bad Location Information) is also defined in this document. 219 3.2 The Geolocation Header 221 This document creates and IANA registers a new SIP header: 222 Geolocation. The Geolocation header MUST contain one of two types 223 of URIs: 225 o a location-by-reference URI, or 227 o a content-ID indicating where location is within the message body 228 of this message 230 A location-by-reference URI is a pointer to a record on a remote 231 node containing location of the location target, typically the 232 UA in this transaction. 234 A location-by-value content-ID (cid-url) [RFC2392] indicates which 235 message body part contains location for this UA. 237 The Geolocation header has the following BNF syntax: 239 Geolocation = "Geolocation" HCOLON (locationValue *(COMMA 240 locationValue)) 241 locationValue = LAQUOT locationURI RAQUOT *(SEMI geoloc-param) 242 locationURI = sip-URI / sips-URI / pres-URI 243 / cid-url ; (from RFC 2392) 244 / absoluteURI ; (from RFC 3261) 245 geoloc-param = "inserted-by" EQUAL geoloc-inserter 246 / "message-routed-on-this-uri" 247 / generic-param ; (from RFC 3261) 248 geoloc-inserter = "endpoint" / "server" 249 / gen-value ; (from RFC 3261) 251 The cid-url is defined in [RFC2392] to locate message body 252 parts. This URI MUST be present if location is by-value in a 253 message. 255 sip-URI, sips-URI and absoluteURI are defined according to RFC3261. 256 The pres-URI is defined in RFC 3859 [RFC3859]. 258 Other protocols used in the Location URI MUST be reviewed against 259 the RFC3693 criteria for a using protocol. 261 This document defines the Geolocation header as valid in the 262 following SIP requests: 264 INVITE [RFC3261], 265 REGISTER [RFC3261], 266 OPTIONS [RFC3261], 267 UPDATE [RFC3311], 268 MESSAGE [RFC3428], 269 SUBSCRIBE [RFC3265], and 270 NOTIFY [RFC3265] 272 Use of the header in BYE, INFO and REFER Methods are allowed, 273 although no purpose is known. Conveying location in a CANCEL, BYE, 274 ACK or PRACK is not defined. Discussing location using the PUBLISH 275 Request Method out of scope for this document. 277 The following table extends the values in Table 2&3 of RFC3261 278 [RFC3261]. 280 Header field where proxy INV ACK CAN BYE REG OPT PRA 281 ---------------------------------------------------------------- 282 Geolocation Rr ar o - - o o o - 284 Header field where proxy SUB NOT UPD MSG REF INF PUB 285 ---------------------------------------------------------------- 286 Geolocation Rr ar o o o o o o - 288 Table 1: Summary of the Geolocation Header 290 The Geolocation header MAY be included in one of the above messages 291 by a User Agent. A proxy MAY add the Geolocation header, but MUST 292 NOT modify the contents of an existing Geolocation header. 293 [RFC3261] states message bodies cannot be added by proxies. 294 Therefore, a Geolocation header added by a proxy MUST specify 295 location-by-reference. 297 Entities receiving location information MUST honor the usage element 298 rules per RFC4119. Such entities MUST NOT alter the rule set. 300 3.3 424 (Bad Location Information) Response Code 302 If a UAS or SIP intermediary detects an error in a request message 303 specific to the location information supplied by-value or 304 by-reference, a new 4XX level error is created here to indicate a 305 problem with the location in the request message. This document 306 creates and IANA registers the new error code: 308 424 (Bad Location Information) 310 The 424 (Bad Location Information) response code is a rejection of 311 the location contents within the original SIP request indicating the 312 location information was malformed or not satisfactory for the 313 recipient's purpose or could not be dereferenced. 315 The UAC can use whatever means it knows of to verify/refresh its 316 location information before attempting a new request that includes 317 location. There is no cross-transaction awareness expected by either 318 the UAS or SIP intermediary as a result of this error message. 320 More resolution of the error for which the 424 was generated MAY be 321 included in a Warning header [RFC3261] with new, IANA registered, 322 location specific warning values (see Section 3.4). 324 The new 424 (Bad Location Information) error code is IANA registered 325 in Section 9 of this document. An initial set of location error 326 codes are in [ID-ERROR]. 328 3.4 New Warning Codes for Location Error Granularity 330 As discussed in Section 3.3, more granular error codes, specific to 331 location errors within a received message, are required if the UAC 332 is to know what was wrong with the original request. The Warning 333 header will be used to convey such error conditions within the 424 334 (Bad Location Information) response. Rather than depleting the 335 remaining available 3XX codes, codes 700 through 740 will be 336 designated for Location warnings. Additions to this 337 IANA registration range for location codes require an RFC. 339 Warning has the advantage of including the node ID in the header, 340 meaning the ID of the entity that sent this response. This can 341 useful for troubleshooting. 343 The Warning header allows for multiple warning codes be returned in 344 the same response. If a location-by-reference is sent and the 345 supplied scheme is not desired or cannot be processed, but more than 346 one other scheme can be, the 424 response can list more than one 347 code from the 720-724 range in the response. The UAC may 348 subsequently retry the operation with one of the schemes supported 349 or desired by the recipient. 351 To illustrate this, here is an example of Alice including 352 location-by-reference using an HTTP schema. Bob cannot dereference 353 using HTTP, but can dereference using SIP, SIPS, and PRES: 355 Alice Bob 356 | | 357 | Request w/ Location | 358 | using http schema | 359 |----------------------------------->| 360 | | 361 | | 362 | 424 (Bad Location Information) | 363 | with Warning header containing | 364 | 720 (SIP), 721 (SIPS), 722 (PRES) | 365 |<-----------------------------------| 366 | | 368 3.4.1 Warning code 701 Location Format Not Supported 370 A Warning header with the code 701 "Location Format not supported" 371 means the location format supplied in the request, by-value or 372 by-reference, was not supported. This cause means the recipient 373 understood that location was included in the message, but the format 374 is not supported. Perhaps the format was a freeform text format or 375 data-URL and the recipient only understood location in RFC4119 376 PIDF-LO format (civic or geo). If a more specific Warning code is 377 available, it MUST be used. For example, if the format is 378 understood, but not desired, a 702 or 703 Warning header SHOULD be 379 returned. The same applies to a location recipient that only 380 understands one format and did not receive that format. For example, 381 if a message containing geo formatted location arrives but the 382 recipient only can process civic formatted location a 703 Warning 383 header should be returned in a 424 response. 385 Recommended warn-text: Location format not supported 387 An example usage in a SIP 424 response: 389 Warning: 701 alice.example.com "Location Format not supported" 391 3.4.2 Warning code 702 Geo-location Format Desired Instead 393 A Warning header with the code 702 "Geo-location Format Desired" 394 means the location format supplied in the request (probably 395 formatted in civic), by-value or by-reference, was understood and 396 supported, but that the recipient, or an application on the 397 recipient prefers, or can only process location in the geo-location 398 format. 400 A typical reaction to receiving this Warning code is to resend the 401 original message with location formatted in geo instead. 403 Recommended warn-text: Geo-location Format Desired 405 An example usage in a SIP 424 response: 407 Warning: 702 node_alice.example.com "Geo-location Format Desired" 409 3.4.3 Warning code 703 Civic-location Format Desired Instead 411 A Warning header with the code 703 "Civic-location Format Desired" 412 means the location format supplied in the request (probably 413 formatted in geo), by-value or by-reference, was understood and 414 supported, but that the recipient, or an application on the 415 recipient prefers, or can only process location in the 416 civic-location format. 418 A typical reaction to receiving this Warning code is to resend the 419 original message with location formatted in civic instead. 421 Recommended warn-text: Civic-location Format Desired 423 An example usage in a SIP 424 response: 425 Warning: 703 alice.example.com "Civic-location Format Desired" 427 3.4.4 Warning code 704 Cannot Parse Location Supplied 429 A Warning header with the code 704 "Cannot parse location supplied" 430 means the location provided, whether by-value or by-reference in a 431 request is not well formed. 433 Recommended warn-text: Cannot parse location supplied 435 An example usage in a SIP 424 response: 437 Warning: 704 alice.example.com "Cannot parse location supplied" 439 3.4.5 Warning code 705 Cannot Find Location 441 A Warning header with the code 705 "Cannot find location" means 442 location should have been in the message received, but the recipient 443 cannot find it, either because it is not in the message, or it is 444 encrypted/opaque to the recipient. 446 A typical reaction to receiving this error would be for the location 447 sender to verify it has indeed included location in the new request 448 and send the message again. 450 Recommended warn-text: Cannot find location 452 An example usage in a SIP 424 response: 454 Warning: 705 alice.example.com "Cannot find location" 456 3.4.6 Warning code 706 Conflicting Locations Supplied 458 A Warning header with the code 706 "Conflicting Locations Supplied" 459 means a location recipient received more than one location 460 describing where the target is, and is either unsure which whole 461 location is true or which parts of multiple locations make up where 462 the target is. This is generally a case of either too much 463 information, and the information is conflicting. 465 A typical reaction to receiving this error is to reduce the number 466 of different locations supplied in the request, and send another 467 message to the location recipient. 469 Recommended warn-text: Conflicting Locations Supplied 471 An example usage in a SIP 424 response: 473 Warning: 706 alice.example.com "conflicting locations supplied" 475 3.4.7 Warning code 707 Incomplete Location Supplied 477 A Warning header with the code 707 "Incomplete Location Supplied" 478 means there is not enough location information, by-value or 479 by-reference, to determine where the location target is. 481 A typical reaction to receiving this message is for the sender to 482 Convey more information if it is willing to do so. 484 Recommended warn-text: Incomplete location supplied 486 An example usage in a SIP 424 response: 488 Warning: 707 alice.example.com "Incomplete location supplied" 490 3.4.8 Warning code 708 Cannot Dereference 492 A Warning header with the code 708 "Cannot dereference" means the 493 act of dereferencing failed to return the target's location. This 494 generally means the supplied URI is bad. 496 Recommended warn-text: Cannot dereference 498 An example usage in a SIP 424 response: 500 Warning: 708 alice.example.com "Cannot dereference" 502 3.4.9 Warning code 709 Dereference Denied 504 A Warning header with the code 709 "Dereference Denied" means there 505 was insufficient authorization to dereference the target's location 506 at, or before the LIS. This is a application layer error, so it is 507 not to be confused with lacking permission through a lower layer 508 firewall. 510 Recommended warn-text: Dereference Denied 512 An example usage in a SIP 424 response: 514 Warning: 709 alice.example.com "Dereference Denied" 516 3.4.10 Warning code 710 Dereference Timeout 518 A Warning header with the code 710 "Dereference Timeout" means that 519 the dereferencing node has not received the target's location within 520 a reasonable timeframe. 522 Recommended warn-text: Dereference Timeout 524 An example usage in a SIP 424 response: 526 Warning: 710 alice.example.com "Dereference Timeout" 528 3.4.11 Warning code 711 Cannot Process Dereference 530 A Warning header with the code 711 "Cannot process Dereference" 531 means the dereference protocol has received an overload condition 532 error, indicating the location cannot be accessed at this time. If 533 a sip or sips schema were used to dereference the target's location, 534 and a 503 (Service Unavailable) were the response to the dereference 535 query, this 711 Warning code would be placed in the 424 (Bad 536 Location Information) response to the location sender. 538 Recommended warn-text: Cannot process Dereference 540 An example usage in a SIP 424 response: 542 Warning: 711 alice.example.com "Cannot process Dereference" 544 3.4.12 Warning code 720 Unsupported Schema - sip desired 546 A Warning header with the code 720 "Unsupported Schema - sip 547 desired" means the location dereferencer cannot dereference using 548 the location-by-reference URI schema supplied because it does not 549 support the necessary protocol to do this. This Warning code means 550 the location recipient can dereference the target's location using a 551 sip-URI schema. There can be more than one Warning code in a 552 Warning header, indicated in this context the recipient can 553 dereference using each schema protocol included in the Warning 554 header. 556 A typical reaction to receiving this error would be for the location 557 sender to send a URI with the sip schema. 559 Recommended warn-text: unsupported schema 561 An example usage in a SIP 424 response: 563 Warning: 720 alice.example.com "unsupported schema - sip desired" 565 3.4.12 Warning code 721 Unsupported Schema - sips desired 567 A Warning header with the code 721 "Unsupported Schema - sips 568 desired" means the location dereferencer cannot dereference using 569 the location-by-reference URI schema supplied because it does not 570 support the necessary protocol to do this. This Warning code means 571 the location recipient can dereference the target's location using a 572 sips-URI schema. There can be more than one Warning code in a 573 Warning header, indicated in this context the recipient can 574 dereference using each schema protocol included in the Warning 575 header. 577 Recommended warn-text: unsupported schema 579 An example usage in a SIP 424 response: 581 Warning: 721 alice.example.com "unsupported schema - sips desired" 583 3.4.13 Warning code 722 Unsupported Schema - pres desired 585 A Warning header with the code 722 "Unsupported Schema - pres 586 desired" means the location dereferencer cannot dereference using 587 the location-by-reference URI schema supplied because it does not 588 support the necessary protocol to do this. This Warning code means 589 the location recipient can dereference the target's location using a 590 pres-URI schema. There can be more than one Warning code in a 591 Warning header, indicated in this context the recipient can 592 dereference using each schema protocol included in the Warning 593 header. 595 Recommended warn-text: unsupported schema 597 An example usage in a SIP 424 response: 599 Warning: 722 alice.example.com "unsupported schema - pres desired" 601 3.5 The Geolocation Option Tag 603 This document creates and IANA registers one new option tag: 604 "geolocation". This option tag is to be used, per RFC 3261, in the 605 Require, Supported and Unsupported headers. Whenever a UA wants to 606 indicate it understands this SIP extension, the geolocation option 607 tag is included in a Supported header of the SIP message. 609 The purpose of the geolocation option-tag is to indicate support for 610 this extension in the Supported and Unsupported headers. Appearance 611 of the option tag in the Require header is a request for location to 612 be conveyed. 614 A UAC SHOULD NOT include this option tag in a Proxy-Require header, 615 since is not likely to understand the topology of the 616 infrastructure, and therefore would not understand which proxy will 617 do the location-based routing function, if any. 619 3.6 Using sip/sips/pres as a Dereference Protocol 621 A sip, sips or pres URI SHOULD be included in a Geolocation header 622 for the location-by-reference URI. When pres: is used, if the 623 resulting resolution, per [RFC3851], resolves to a sip: or sips: 624 URI, this section applies. Use of other protocols for dereferencing 625 of a pres: URI is not defined, and such use is subject to review 626 against RFC3693 using protocol criteria. 628 Dereferencing using sip or sips MUST be accomplished by treating the 629 URI as a presence URI and dereferencing is accomplished by a 630 SUBSCRIBE to a presence service per [RFC3856]. The resulting NOTIFY 631 will contain a PIDF, which MUST contain a PIDF-LO. 633 When used in this manner, SIP is a using protocol per [RFC3693] and 634 elements receiving location MUST honor the 'usage-element' rules as 635 defined in Section 3.4 above. 637 A dereference of a location-by-reference URI using SUBSCRIBE is not 638 violating a PIDF-LO 'retransmission-allowed' element value set to 639 'no', as the NOTIFY is the only message in this multi-message series 640 of transactions that contains the UAC's location, with the location 641 recipient being the only SIP element to receive location - which the 642 purpose of this extension: to convey location to a specific 643 destination. 645 4. Examples 647 Three examples of messages providing location are provided. One 648 shows location-by-value with geo-coordinates, one shows 649 location-by-value with civic location and the third shows 650 location-by-reference. The examples for (Geo format) are taken 651 from [RFC3825] and (Civic format) are taken from [ID-CIVIC] and are 652 for the exact same position on the Earth. The differences between 653 the two formats is within the of the examples. 654 Other than this portion of each PIDF-LO, the rest is the same for 655 both location formats. 657 4.1 Location-by-value (Coordinate Format) 659 This example shows an INVITE message with a coordinate, or geo 660 location. In this example, the SIP request uses a sips-URI 661 [RFC3261], meaning this message is TLS protected on a hop-by-hop 662 basis all the way to Bob's domain. 664 INVITE sips:bob@biloxi.example.com SIP/2.0 665 Via: SIP/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bK74bf9 666 Max-Forwards: 70 667 To: Bob 668 From: Alice ;tag=9fxced76sl 669 Call-ID: 3848276298220188511@atlanta.example.com 670 Geolocation: 671 ;inserted-by=endpoint 672 Supported: geolocation 673 Accept: application/sdp, application/pidf+xml 674 CSeq: 31862 INVITE 675 Contact: 676 Content-Type: multipart/mixed; boundary=boundary1 677 Content-Length: ... 679 --boundary1 681 Content-Type: application/sdp 683 ...SDP here 685 --boundary1 687 Content-Type: application/pidf+xml 688 Content-ID: alice123@atlanta.example.com 690 691 696 697 2007-03-20T14:00:00Z 698 699 700 701 702 703 33.001111N 704 96.68142W 705 706 707 708 709 no 710 2007-03-24T18:00:00Z 712 DHCP 713 www.cisco.com 714 715 716 717 718 719 --boundary1-- 721 The Geolocation header from the above INVITE... 723 Geolocation: 725 ...indicates the content-ID location [RFC2392] within the multipart 726 message body of were location information is, with SDP being the 727 other message body part. 729 If the Geolocation header were this instead: 731 Geolocation: 733 ...this would indicate location by-reference was included in this 734 message. It is expected that any node wanting to know where user 735 alice123 is would subscribe to server5 to dereference the sips-URI. 736 The returning NOTIFY would contain Alice's location in a PIDF-LO, as 737 if it were included in a message body (part) of the original INVITE 738 here. 740 4.2 Location-by-value (Civic Format) 742 This example shows an INVITE message with a civic location. The 743 headers are shown as if the location was S/MIME encrypted, but the 744 unencrypted location information is shown for clarity. The lines 745 below that have the '$' signs are encrypted. 747 INVITE sip:bob@biloxi.example.com SIP/2.0 748 Via: SIP/2.0/TCP pc33.atlanta.example.com 749 ;branch=z9hG4bK74bf9 750 Max-Forwards: 70 751 To: Bob 752 From: Alice ;tag=9fxced76sl 753 Call-ID: 3848276298220188511@atlanta.example.com 754 Geolocation: 755 ;inserted-by=endpoint 756 Supported: geolocation 757 Accept: application/sdp, application/pidf+xml 758 CSeq: 31862 INVITE 759 Contact: 760 Content-Type: multipart/mixed; boundary=boundary1 761 Content-Length: ... 763 --boundary1 765 Content-Type: application/sdp 767 ...SDP here 769 --boundary1 771 Content-Type: application/pkcs7-mime; 772 smime-type=enveloped-data; name=smime.p7m 773 Content-ID: alice123@atlanta.example.com 775 $ Content-Type: application/pidf+xml 776 $ 777 $ 778 $ 783 $ 784 $ 2007-03-20T14:00:00Z 785 $ 786 $ 787 $ 788 $ 789 $ US 790 $ Texas 791 $ Colleyville 792 $ 3913 793 $ Treemont 794 $ Circle 795 $ 76034 796 $ Haley's Place 797 $ 1 798 $ 799 $ 800 $ 801 $ no 802 $ 2007-03-24T18:00:00Z 804 $ DHCP 805 $ www.cisco.com 806 $ 807 $ 808 $ 809 $ 810 $ 811 --boundary1-- 813 4.3 Location-by-reference 815 Here is an example of an INVITE with a location-by-reference URI, 816 sips: in this case, instead of a location-by-value PIDF-LO message 817 body part shown in Sections 4.1 and 4.2. It is up to the location 818 recipient to dereference Alice's location at the Atlanta LIS. 820 INVITE sip:bob@biloxi.example.com SIP/2.0 821 Via: SIP/2.0/TCP pc33.atlanta.example.com 822 ;branch=z9hG4bK74bf9 823 Max-Forwards: 70 824 To: Bob 825 From: Alice ;tag=9fxced76sl 826 Call-ID: 3848276298220188511@atlanta.example.com 827 Geolocation: 828 ;inserted-by=server 829 Supported: geolocation 830 Accept: application/sdp, application/pidf+xml 831 CSeq: 31862 INVITE 832 Contact: 834 ...SDP goes here as the only message body 836 A location recipient would need to dereference the sips-URI in the 837 Geolocation header to retrieve Alice's location. If the 838 atlanta.example.com domain chooses to implement location conveyance 839 and delivery in this way (i.e. location-by-reference), it is 840 RECOMMENDED that entities outside this domain be able to reach the 841 dereferencing LIS server, otherwise this model of implementation is 842 only viable within the atlanta.example.com domain. This will likely 843 not suit some services already being considered in the IETF at the 844 time of this writing, such as emergency calling. 846 5. SIP Element Behavior 848 Because a person's location is generally considered to be sensitive 849 in nature, privacy of the location information must be protected 850 when transmitting such information. Section 26 of [RFC3261] defines 851 the security functionality SIPS for transporting SIP messages with 852 either TLS or IPSec, and S/MIME for encrypting message bodies from 853 SIP intermediaries that would otherwise have access to reading the 854 clear-text bodies. SIP endpoints SHOULD implement S/MIME to encrypt 855 the PIDF-LO message body (part) end-to-end when the intended 856 recipient is the opposite UA. The SIPS-URI from [RFC3261] MUST be 857 implemented for message protection (message integrity and 858 confidentiality) and SHOULD be used when S/MIME is not used. 859 Possession of a dereferenceable location URI may be equivalent to 860 possession of the location information itself and thus TLS SHOULD be 861 used when sending location-by-reference. 863 A PIDF includes identity information. It is possible for the 864 identity in the PIDF to be anonymous. Implementations of this 865 extension should consider the appropriateness of including an 866 anonymous identity in the location information where a real identity 867 is not required. When using location-by-reference, it is 868 RECOMMENDED that the URI not contain any identifying information 869 (for example use 3fg5t5yqw@example.com rather than 870 alice@example.com) 872 The entities receiving location MUST obey the privacy 873 and security rules in the PIDF-LO as described in RFC4119, regarding 874 retransmission and retention. 876 Self-signed certificates SHOULD NOT be used for protecting PIDF, 877 as the sender does not have a secure identity of the recipient. 879 More than one location representation or format, for example: civic 880 and geo, MAY be included in the same message body part, but all MUST 881 point at the same position on the earth. Multiple representations 882 allow the recipient to use the most convenient representation of 883 location. 885 There MAY be more than one PIDF-LO in the same SIP message, but each 886 in separate message body parts. Each location body part MAY point at 887 different positions on the earth. The meaning of such a 888 construction is not defined, and may cause confusion at the 889 recipient 891 5.1 UAC Behavior 893 A UAC may send location because it was requested to, to facilitate 894 location-based routing, or spontaneously (i.e. a purpose not defined 895 in this document but known to the UAC). A UAC MAY receive location 896 from the UAS spontaneously. 898 A UAC conveying location MUST include a Geolocation header with 899 either a location by-value indication (a cid-URL), or a location 900 by-reference indication (a dereferenceable URI). A location body 901 sent without a Geolocation header MUST NOT occur. The UAC 902 supporting this extension MUST include a Supported header with the 903 geolocation option tag. 905 The presence of the geolocation option tag in a Supported header 906 without a Geolocation header in the same message informs a receiving 907 SIP element the UAC understands the concept of location, but it does 908 not know its location at this time. Certain scenarios exist 909 (location-based routing) in which location is required in a message 910 in order to route the message properly. This affects how a UAS or 911 SIP server reacts to such a message. 913 The geolocation option tag SHOULD NOT be used in the Proxy-Require 914 Header. 916 If the UAC inserts a geolocation header, it SHOULD include a 917 "inserted-by=endpoint" parameter. For example: 919 Geolocation: ; 920 inserted-by=endpoint 922 UACs receiving a 424 (Bad Location Information) response MAY find a 923 more granular cause for the location based error in a Warning 924 header. Section 3.4 extends the list of IANA registered Warning 925 codes, specifically for location errors within the request. The 926 UAC SHOULD learn from the Warning code in the response and take 927 appropriate steps based on that error given before attempting to 928 convey location again. See Section 3.4. for the list of new 929 location specific Warning codes. 931 There MAY be future work defining additional error information, say 932 in an XML body, indicating exactly what the error was, if any of the 933 new Warning codes are ambiguous. 935 The behavior of the UAC receiving location is the same as the UAS, 936 as below, except a UAC cannot send a Warning code indicating 937 something was wrong with the location supplied by the UAS. In this 938 case, the location information SHOULD just be ignored in this 939 transaction. A subscription is a better means of getting a UAS's 940 location. 942 5.2 UAS Behavior 944 If the Geolocation header is present, the URI contained in as a 945 header field will indicate if location has been conveyed by-value in 946 a message body (part) or by-reference, requiring an additional 947 dereference transaction. If the by-reference URI is sip:, sips: or 948 pres:, the UAS will initiate a SUBSCRIBE to the URI provided to 949 retrieve the PIDF-LO of the UAC per [RFC3856]. If successful, the 950 PIDF-LO of the UAC will be returned in the NOTIFY request from the 951 server. 953 A Require header with the geolocation option tag indicates the 954 UAC is requiring the UAS understand this extension or error the 955 message. A 420 (Bad Extension) with a geolocation option tag in a 956 Unsupported header would be the appropriate response. 958 If the UAC conveys location in a request, but the UAS has one or 959 more problems with the location in the request (or while attempting 960 to dereference the UAC's location), a 424 (Bad Location Information) 961 response would be an appropriate response. If the UAS can indicate 962 what the problem is with the location in the request, in the form of 963 one of the new Warning codes specifically about location errors, the 964 Warning header SHOULD be included along with the most applicable 965 Warning code(s). Zero or more Warning codes are allowed in a 966 response. 968 For example, if a UAC conveyed location-by-reference and chose a 969 pres schema for the UAS to dereference, and the UAS cannot or will 970 not dereference using pres (for whatever reason), the UAS can 971 include more than one Warning code in the 424 response to indicate 972 what will be acceptable to the UAS in this case. This scenario would 973 like something like this: 975 Warning: 720 UAS-ID Unsupported Schema - sip desired, 976 721 UAS-ID Unsupported Schema - sips desired, 978 The UAS behavior for sending location is the same as the UAC as 979 above. 981 5.3 Proxy Behavior 983 [RFC3261] states message bodies cannot be added by proxies. 984 However, a proxy may add a header to a message. This implies that a 985 proxy MAY add a geolocation header with location-by-reference, but 986 not location-by-value. 988 A proxy MAY read the Geolocation header, and the associated body, if 989 not S/MIME protected, in transit if present, and MAY use the 990 contents of the header to make location-based routing decisions. 992 More than one Geolocation header or header value in a message is 993 permitted. The meaning of such a construction is not defined, and 994 may cause confusion at the recipient. 996 Proxies receiving location where the proxy performs location-based 997 routing may need to consult external databases or systems to 998 determine the route. Transmission of the location information 999 (which SHOULD NOT reveal identity, even if the proxy knows the 1000 identity) is governed by the 'retransmission-allowed' and 1001 'routing-query-allowed': 1003 Retransmission-allowed Routing-query-allowed Transmission for Query 1004 ---------------------- --------------------- ---------------------- 1005 "no" or not present "no" or not present Not Allowed 1006 "no" or not present "yes" Allowed 1007 "yes" not present Allowed 1008 "yes" "no" Not Allowed 1009 "yes" "yes" Allowed 1011 If transmission is not allowed per the above, the proxy SHOULD 1012 provide a suitable error response. The 424 (Bad Location) is the 1013 appropriate response here. 1015 5.3.1 Proxy Behavior with Geolocation Header Parameters 1017 When a message traverses a SIP intermediary, any existing header 1018 value URI and header parameter MUST NOT be modified or deleted, 1019 but MAY be augmented to indicate if the message was routed based on 1020 a specific geolocation URI. For example: 1022 Geolocation: ; 1023 inserted-by=endpoint; message-routed-on-this-uri 1025 A SIP intermediary MAY add a new Geolocation URI value to a message. 1026 The proxy SHOULD NOT insert a location unless it is reasonably 1027 certain it knows the actual location of the endpoint, for example, 1028 if it thoroughly understands the topology of the underlying access 1029 network and it can identify the device reliably (in the presence of, 1030 for example, NAT). 1032 B2BUAs normally set the "inserted-by" parameter to "server". 1034 A server adding a geolocation value to an existing endpoint inserted 1035 location would look like: 1037 Geolocation: ; inserted-by=endpoint, 1038 ; 1039 inserted-by=server; 1041 If this message was then routed by an intermediary using the URI 1042 inserted by the server, the intermediary would note this as: 1044 Geolocation: ; inserted-by=endpoint, 1045 ; 1046 inserted-by=server; message-routed-on-this-uri 1048 It is conceivable that an initial routing decision is made on an 1049 existing header, and subsequently another routing decision is made 1050 on a different header, perhaps even subsequently added by another 1051 proxy on the path. While unusual, it could occur. In such a case, 1052 the later routing proxy MUST remove the incoming 1053 "message-routed-on-this-uri" and replace it with another on the URI 1054 it uses for routing. Downstream entities will not be able to 1055 determine that two routing decisions were made on different location 1056 values. Such a circumstance is considered unlikely to happen, and 1057 the inability to detect it is not considered harmful. 1059 5.3.2 Proxy Error Behavior with Warning Codes 1061 If a SIP intermediary detects a location specific problem with a SIP 1062 request, if SHOULD reply with a 424 (Bad Location Information) 1063 response and include the appropriate Warning code defined in Section 1064 3.4 so the UAC can take whatever corrective action it needs to take 1065 to send a new message with good location information. 1067 6. Special Considerations for Emergency Calls 1069 Emergency calls (1-1-2, 9-1-1, etc.) need location for two reasons: 1071 1. Location is needed to route the call to the correct Public Safety 1072 Answering Point (PSAP), and 1074 2. Location is needed by the PSAP to send responders to the location 1075 of the caller when the caller cannot accurately describe where 1076 s/he is 1078 While all of the privacy concerns for location apply to emergency 1079 calls, it is not acceptable for a security mechanism in place to 1080 support confidentiality of the location to cause an emergency call 1081 to be misrouted, or not supply location when it is needed. 1082 Therefore, some of the behaviors of elements in the path are 1083 different when used with an emergency call. 1085 Recognizing which calls are emergency calls is beyond the scope of 1086 this document. When an emergency call is placed, location is 1087 normally provided by the UAC. Since emergency calls must be routed 1088 based on location (and indeed, in some jurisdictions, there may be 1089 several steps to such routing), the location must be visible to 1090 proxies along the path. Thus S/MIME protection of location MUST NOT 1091 be used. TLS protection of location SHOULD be used, however, if 1092 establishment of the TLS connection fails, the call set-up 1093 operation, including location conveyance, MUST be retried without 1094 TLS. 1096 The entity inserting the geolocation header MUST specify the 1097 "inserted-by" parameter, with values of "endpoint" or "server" as 1098 appropriate. 1100 Both the "retransmission-allowed" and "routing-query-allowed" SHOULD 1101 be set to "yes". Querying for routing may be performed by proxies 1102 providing a routing service for emergency calls even if 1103 retransmission-allowed or routing-query-allowed is set to "no" or is 1104 not present. Proxies routing on the location MUST set the 1105 "message-routed-on-this-uri" parameter. 1107 While many jurisdictions force a user to reveal their location 1108 during an emergency call set-up, there are a small, but real, number 1109 of jurisdictions that allow a user to configure their calling device 1110 to disable providing location, even during emergency calling. This 1111 capability MUST be configurable, but is NOT RECOMMENDED as the 1112 default configuration of any UA. Local policies will dictate this 1113 ability. 1115 7. Geopriv Privacy Considerations 1117 Transmitting location information is considered by most to be highly 1118 sensitive information, requiring protection from eavesdropping, 1119 tracking, and altering in transit. [RFC3693] articulates rules to 1120 be followed by any protocol wishing to be considered a Geopriv 1121 "using protocol", specifying how a transport protocol meetings 1122 those rules. This section describes how SIP as a using protocol 1123 meets those requirements. 1125 Quoting requirement #4 of [RFC3693]: 1127 "The using protocol has to obey the privacy and security 1128 instructions coded in the location object and in the 1129 corresponding Rules regarding the transmission and storage 1130 of the LO." 1132 This document requires that SIP entities sending or receiving 1133 location MUST obey such instructions. 1135 Quoting requirement #5 of [RFC3693]: 1137 "The using protocol will typically facilitate that the keys 1138 associated with the credentials are transported to the 1139 respective parties, that is, key establishment is the 1140 responsibility of the using protocol." 1142 [RFC3261] and the documents it references define the key 1143 establishment mechanisms. 1145 Quoting requirement #6 of [RFC3693]: 1147 "(Single Message Transfer) In particular, for tracking of 1148 small target devices, the design should allow a single 1149 message/packet transmission of location as a complete 1150 transaction." 1152 When used for tracking, a simple NOTIFY or UPDATE normally is 1153 relatively small, although the PIDF itself can get large. Normal 1154 RFC3261 procedures of reverting to TCP when the MTU size is exceeded 1155 would be invoked. 1157 8. Security Considerations 1159 Conveyance of physical location of a UAC raises privacy concerns, 1160 and depending on use, there may be authentication and integrity 1161 concerns. This document calls for conveyance to normally be 1162 accomplished through secure mechanisms (like S/MIME or TLS). In 1163 cases where a session set-up is routed based on the location of the 1164 UAC initiating the session or SIP MESSAGE, securing the by-value 1165 location with an end-to-end mechanism such as S/MIME is problematic, 1166 because one or more proxies on the path need the ability to read the 1167 information to route the message appropriately. Securing the 1168 location hop-by-hop, using TLS, protects the message from 1169 eavesdropping and modification, but exposes the information to all 1170 proxies on the path as well as the endpoint. In most cases, the UAC 1171 does not know the identity of the proxy or proxies providing 1172 location-based routing services, so that end to middle solutions may 1173 not be appropriate either. 1175 When the UAC is the source of the location information, which is 1176 RECOMMENDED, it can decide whether to reveal its location using 1177 hop-by-hop methods. UAC implementations MUST make such capabilities 1178 conditional on explicit user permission, and SHOULD alert a user 1179 that location is being conveyed. Emergency calls have their own 1180 rules in this regard, as detailed in Section 6. Proxies inserting 1181 location for location-based routing are unable to meet this 1182 requirement, and such use is NOT RECOMMENDED. Proxies conveying 1183 location using this extension MUST have the permission of the target 1184 to do so. 1186 9. IANA Considerations 1188 9.1 IANA Registration for the SIP Geolocation Header 1190 The SIP Geolocation header is created by this document, with its 1191 definition and rules in Section 3.2 of this document. 1193 9.2 IANA Registration for New SIP Option Tag 1195 The SIP option tag "Geolocation" is created by this document, with 1196 the definition and rule in Section 3.5 of this document. 1198 9.3 IANA Registration for Response Code 4XX 1200 Reference: RFC-XXXX (i.e. this document) 1201 Response code: 424 1202 Default reason phrase: Bad Location Information 1204 This SIP Response code is defined in section 3.3 of this document. 1206 9.4 IANA Registration of New Warning Codes for Location 1208 New location specific Warning codes are created by this document, 1209 with the definitions in Section 3.4 of this document. 1211 701 Location Format Not Supported 1212 702 Geo-location Format Desired Instead 1213 703 Civic-location Format Desired Instead 1214 704 Cannot Parse Location Supplied 1215 705 Cannot Find Location 1216 706 Conflicting Locations Supplied 1217 707 Incomplete Location Supplied 1218 708 Cannot Dereference 1219 709 Dereference Denied 1220 710 Dereference Timeout 1221 711 Cannot Process Dereference 1222 720 Unsupported Schema - sip desired 1223 721 Unsupported Schema - sips desired 1224 722 Unsupported Schema - pres desired 1226 Adding new location specific Warning codes, or modifying to existing 1227 location specific Warning codes requires an RFC and community 1228 review. 1230 10. Acknowledgements 1232 To Dave Oran for helping to shape this idea. To Jon Peterson and 1233 Dean Willis on guidance of the effort. To Allison Mankin, Dick 1234 Knight, Hannes Tschofenig, Henning Schulzrinne, James Winterbottom, 1235 Jeroen van Bemmel, Jean-Francois Mule, Jonathan Rosenberg, Keith 1236 Drage, Marc Linsner, Martin Thomson, Mike Hammer and Paul Kyzivat 1237 for constructive feedback. Thanks to Dan Wing for help with the 1238 S/MIME example. 1240 11. References 1242 11.1 References - Normative 1244 [RFC3261] J. Rosenberg, H. Schulzrinne, G. Camarillo, A. Johnston, J. 1245 Peterson, R. Sparks, M. Handley, and E. Schooler, "SIP: 1246 Session Initiation Protocol", RFC 3261, May 2002. 1248 [RFC3693] J. Cuellar, J. Morris, D. Mulligan, J. Peterson. J. Polk, 1249 "Geopriv Requirements", RFC 3693, February 2004 1251 [RFC4119] J. Peterson, "A Presence-based GEOPRIV Location Object 1252 Format", RFC 4119, December 2005 1254 [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate 1255 Requirement Levels", RFC 2119, March 1997 1257 [RFC2392] E. Levinson, " Content-ID and Message-ID Uniform Resource 1258 Locators", RFC 2393, August 1998 1260 [RFC3863] H. Sugano, S. Fujimoto, G. Klyne, A. Bateman, W. Carr, J. 1261 Peterson, "Presence Information Data Format (PIDF)", RFC 1262 3863, August 2004 1264 [RFC3856] J. Rosenberg, " A Presence Event Package for the Session 1265 Initiation Protocol (SIP)", RFC 3856, August 2004 1267 [RFC3859] J. Peterson, "Common Profile for Presence (CPP)", RFC 3859, 1268 August 2004 1270 [RFC3428] B. Campbell, Ed., J. Rosenberg, H. Schulzrinne, C. Huitema, 1271 D. Gurle, "Session Initiation Protocol (SIP) Extension for 1272 Instant Messaging" , RFC 3428, December 2002 1274 [RFC3311] J. Rosenberg, "The Session Initiation Protocol (SIP) UPDATE 1275 Method", RFC 3311, October 2002 1277 [RFC3265] Roach, A., "Session Initiation Protocol (SIP)-Specific 1278 Event Notification", RFC 3265, June 2002. 1280 11.2 References - Informative 1282 [ID-ERROR] J. Polk, "A Geopriv Registry for Location-based Error 1283 Response Codes", 1284 draft-polk-geopriv-location-based-error-registry-00, "work 1285 in progress", October 2006 1287 [RFC3825] J. Polk, J. Schnizlein, M. Linsner, "Dynamic Host 1288 Configuration Protocol Option for Coordinate-based Location 1289 Configuration Information", RFC 3825, July 2004 1291 [ID-CIVIC] H. Schulzrinne, " Dynamic Host Configuration Protocol 1292 (DHCPv4 and DHCPv6) Option for Civic Addresses Configuration 1293 Information ", draft-ietf-geopriv-dhcp-civil-09, "work in 1294 progress", January 2006 1296 Author Information 1298 James Polk 1299 Cisco Systems 1300 3913 Treemont Circle 33.00111N 1301 Colleyville, Texas 76034 96.68142W 1303 Phone: +1-817-271-3552 1304 Email: jmpolk@cisco.com 1306 Brian Rosen 1307 NeuStar, Inc. 1309 470 Conrad Dr. 40.70497N 1310 Mars, PA 16046 80.01252W 1311 US 1313 Phone: +1 724 382 1051 1314 Email: br@brianrosen.net 1316 Appendix A. Requirements for SIP Location Conveyance 1318 The following subsections address the requirements placed on the 1319 user agent client, the user agent server, as well as SIP proxies 1320 when conveying location. There is a motivational statement below 1321 each requirements that is not obvious in intent 1323 A.1 Requirements for a UAC Conveying Location 1325 UAC-1 The SIP INVITE Method [RFC3261] must support location 1326 conveyance. 1328 UAC-2 The SIP MESSAGE method [RFC3428] must support location 1329 conveyance. 1331 UAC-3 SIP Requests within a dialog should support location 1332 conveyance. 1334 UAC-4 Other SIP Requests may support location conveyance. 1336 UAC-5 There must be one, mandatory to implement means of 1337 transmitting location confidentially. 1339 Motivation: interoperability 1341 UAC-6 It must be possible for a UAC to update location conveyed 1342 at any time in a dialog, including during dialog 1343 establishment. 1345 Motivation: in case a UAC has moved prior to the establishment of a 1346 dialog between UAs, the UAC must be able to send new location 1347 information. In the case of location having been conveyed, 1348 and the UA moves, it needs a means to update the conveyed to 1349 party of this location change. 1351 UAC-7 The privacy and security rules established within [RFC3693] 1352 that would categorize SIP as a 'using protocol' must be met. 1354 UAC-8 The PIDF-LO [RFC4119] is a mandatory to implement format for 1355 location conveyance within SIP, whether included by-value or 1356 by-reference. 1358 Motivation: interoperability with other IETF location protocols and 1359 mechanisms 1361 UAC-9 There must be a mechanism for the UAC to request the UAS send 1362 its location 1364 UAC-10 There must be a mechanism to differentiate the ability of the 1365 UAC to convey location from the UACs lack of knowledge of its 1366 location 1368 Motivation: Failure to receive location when it is expected can be 1369 because the UAC does not implement this extension, or it can 1370 be that the UAC implements the extension, but does not know 1371 where it is. This may be, for example, due to the failure of 1372 the access network to provide a location acquisition 1373 mechanisms the UAC understands. These cases must be 1374 differentiated. 1376 UAC-11 It must be possible to convey location to proxy servers 1377 along the path. 1379 Motivation: Location-based routing. 1381 A.2 Requirements for a UAS Receiving Location 1383 The following are the requirements for location conveyance by a user 1384 agent server: 1386 UAS-1 SIP Responses must support location conveyance. 1388 UAS-2 There must be a unique 4XX response informing the UAC it did 1389 not provide applicable location information. 1391 In addition, requirements UAC-5, 6, 7 and 8 apply to the UAS 1393 A.3 Requirements for SIP Proxies and Intermediaries 1395 The following are the requirements for location conveyance by a SIP 1396 proxies and intermediaries: 1398 Proxy-1 Proxy servers must be capable of adding a Location header 1399 during processing of SIP requests. 1401 Motivation: Provide the capability of network assertion of location 1402 when UACs are unable to do so, or when network assertion is 1403 more reliable than UAC assertion of location 1405 Note: Because UACs connected to sip signaling networks may have 1406 widely varying access network arrangements, including VPN 1407 tunnels and roaming mechanisms, it may be difficult for a 1408 network to reliably know the location of the endpoint. Proxy 1409 assertion of location is NOT RECOMMENDED unless the sip 1410 signaling network has reliable knowledge of the actual 1411 location of the targets. 1413 Proxy-2 There must be a unique 4XX response informing the UAC it 1414 did not provide applicable location information. 1416 Appendix B. Changes from Prior Versions 1418 [NOTE TO RFC-EDITOR: If this document is to be published as an RFC, 1419 this Appendix B is to be removed prior to that event.] 1421 This is a list of the changes that have been made from the SIP WG 1422 version -05 to this version -06: 1424 - cleaned up some inconsistencies wrt the S/MIME example in Section 1425 4.2 1427 - changed the ABNF to include the ability to indicate which SIP 1428 element inserted a particular location URI, and how a message 1429 routing server indicates which location the message was routed 1430 upon (based on the location in the message) 1432 - changed the granular error code from a Reason header indication to 1433 a Warning code indication (section 3.4), and IANA registered 14 1434 new Warning codes in this document 1436 - As a consequence of the above bullet, changed the specific SIP 1437 element behaviors of each SIP element regarding sending or 1438 receiving a 424 response with a Warning header 1440 - Added rules about indicating which SIP element inserted a 1441 particular location into a message (a new Geolocation header 1442 parameter), as well as when a server adds another new header 1443 parameter indicating the request was routed based on a particular 1444 location included in the message 1446 This is a list of the changes that have been made from the SIP WG 1447 version -04 to this version -05: 1449 - altered the meaning of use of OPTIONS to not be for retrieving the 1450 location of a UAS, but for cases in which location is a required 1451 element of information by a SIP entity. 1453 - added a comment/warning for usage of location-by-reference to a 1454 model in which a domain's LIS be reachable if location is deployed 1455 in this fashion (Section 4.3) 1457 - added a Informative reference to a new ID that is an IANA registry 1458 of location specific error codes to be used in, for example, a 1459 Reason header, to give more granular reasons why a 424 (Bad 1460 Location Information) was sent. 1462 This is a list of the changes that have been made from the SIP WG 1463 version -03 to this version -04: 1465 - removed the inappropriate 2119 language from the Requirements 1466 section. 1468 - removed the old Section 2., which was a Location in a header vs. 1469 in a body artifact from the original versions of the document. 1471 - Added a new Geopriv (or Privacy) Considerations 1473 - Changed the ABNF to reflect discussion on how restrictive the 1474 location-by-reference schemes should be, with an added "Editor's 1475 Note" discussing the issues being faced on this point. 1477 - Changed the "Location" header and option-tag to "Geolocation" 1478 header and option-tag, due to it being pointed out that there is a 1479 conflicting HTTP header called "Location". 1481 - Added new element to PIDF-LO 'routing-query-allowed' 1483 - Stipulated the Reason Header can be used in the 424 Response 1484 Message 1486 - added SUBSCRIBE and NOTIFY as Methods for location conveyance when 1487 used to dereference a sip:, sips: or pres: location-by-reference 1488 URI 1490 - Added OPTIONS Method for a UAC to request the location of a UAS 1491 with a Require header geolocation option-tag. 1493 This is a list of the changes that have been made from the SIP WG 1494 version -02 to this version -03: 1496 - general clean-up of some of the sections 1498 - removed the message examples from the UPDATE, MESSAGE and REGISTER 1499 sections, as these seemed to be making the doc less readable, and 1500 not more readable 1502 - removed the "unknown" option tag, as it was not needed with a 1503 certain combination of the Supported and Location headers 1505 - clarified the location option tag usage in Supported, Require, 1506 Unsupported, and that it shouldn't be used in Proxy-Require, and 1507 why not. 1509 - Added a basic message flow to the basic operation section (Section 1510 4) to aid in understanding of this SIP extension. 1512 - Added a message routing flow, which is based on the location of 1513 the requestor to show how a SIP server can make a routing decision 1514 to a destination based on where the UAC is. 1516 - Articulated how a UAS concludes a UAC understands this extension, 1517 yet does not know its location to provide to the UAS. This is 1518 helpful in those times where an intermediary will act differently 1519 based on whether or not a UAC understands this extension, and 1520 whether or not the UAC includes its location in the request. 1522 - Corrected the erroneous text regarding an Unsupported header being 1523 in a 424 response. It belongs in a 420 response. (Section 5.1) 1525 - Corrected the BNF (I hope) 1527 - Corrected some text in Section 5 that read like this document was 1528 an update to RFC 3261. 1530 This is a list of the changes that have been made from the SIP WG 1531 version -01 to this version -02: 1533 - streamlined the doc by removing text (ultimately removing 42 pages 1534 of text). 1536 - Limited the scope of this document to SIP conveyance, meaning only 1537 how SIP can push location information. 1539 - reduced emergency calling text to just a few paragraphs now that 1540 the ECRIT WG is taking most of that topic on. 1542 - greatly reduced the number of requirements in this version. 1544 - changed the requirements groups from "UA-to-UA", "UA-to-Proxy", 1545 etc to "UAC Reqs", "UAS-Reqs" and "Proxy-Reqs" to focus on what is 1546 being asked of each SIP element. 1548 - Removed the full SIP message examples. 1550 - completed the ABNF for the Location header, including a cid-url to 1551 point at a message body part to help in parsing for location. 1553 - Deleted the call for a new 425 (Retry Location) response code, as 1554 it appears this can easily be used to spoof a UA into providing 1555 where it is inadvertently, even if the intent is legitimate by the 1556 UAC. 1558 This is a list of the changes that have been made from the SIP WG 1559 version -00 to this version -01: 1561 - cleaned up a lot of loose ends in the text 1563 - created a new Location header to convey many means (location is in 1564 the body - even if not viewable, which location format is present, 1565 which format is requested in a query, how to request more than one 1566 location format in a query, whether the UAC understands location 1567 at all, if the UA knows its location, how to push location from 1568 one UA to through a second to a third UA, etc). 1570 - added the ability to convey location by-reference, but only under 1571 certain conditions. 1573 - Added support for the OPTIONS Request to query a server for the 1574 UAC's location, through the use of the new Location header. 1576 - moved both new Response code sections forward in the document for 1577 their meaning to be clearer, earlier for necessary discussion. 1579 - Changed the message flows to only have the pertinent message 1580 headers shown for brevity. 1582 - Added text to the SUB/NOT section showing how and why the location 1583 of a UA can be refreshed or updated with an interval, or by a 1584 trigger. 1586 This is a list of the changes that have been made from the SIPPING 1587 WG version -02 to this SIP WG item document version -00: 1589 - Changed which WG this document is in from SIPPING to SIP due to 1590 the extension of the protocol with new Response codes (424 and 1591 425) for when there is an error involving the LO message body. 1593 - Moved most of the well formed SIP messages out of the main body of 1594 this document and into separate appendixes. This should clean up 1595 the document from a readability point of view, yet still provide 1596 the intended decode examples to readers of this document who wish 1597 that level of detail per flow. The first few flows still have the 1598 decoded SIP messages (unencrypted and encrypted). 1600 - Removed some flow examples which no longer made sense 1602 - Changed all references of "ERC" (Emergency Response Center) to 1603 "PSAP" (Public Safety Answering Point) as a result of discussion 1604 within the new ECRIT WG to define a single term 1606 This is a list of the changes that have been made from the sipping- 1607 01 working group version of this effort to the sipping-02 version: 1609 - added requirements for 2 new 4XX error responses (Bad Location 1610 Information) and (Retry Location Body) 1612 - added "Bad Location Information" as section 8.6 1614 - added "Retry Location Body " as section 9.3 1615 - added support for session mode to cover packet sizes larger than 1616 the single packet limit of 1300 bytes in the message body 1618 - added requirement for a SIP entity to SUBSCRIBE to another for 1619 location information 1621 - added SUBSCRIBE and NOTIFY as section 8.5 1623 - added requirement to have user turn off any tracking created by 1624 subscription 1626 - removed doubt about which method to use for updating location 1627 after a INVITE is sent (update) 1629 - cleaned up which method is to be used if there is no dialog 1630 existing (message) 1632 - removed use of reINVITE to convey location 1634 - clarified that UAs include element of PIDF-LO when 1635 placing an emergency call (to inform PSAP who supplied Location 1636 information) 1638 - updated list of open issues 1640 - added to IANA Considerations section for the two new 4XX level 1641 error responses requested in the last meeting 1643 This is a list of the changes that have been made from the sipping- 1644 00 working group version of this ID to the sipping-01 version: 1646 - Added the offered solution in detail (with message flows, 1647 appropriate SIP Methods for location conveyance, and 1649 - Synchronized the requirements here with those from the Geopriv 1650 Working Group's (attempting to eliminate overlap) 1652 - Took on the task of making this effort the SIP "using protocol" 1653 specification from Geopriv's POV 1655 - Refined the Open Issues section to reflect the progress we've made 1656 here, and to indicate what we have discovered needs addressing, 1657 but has not been to date. 1659 This is a list of the changes that have been made from the -01 1660 individual submission version to the sipping-00 version of this ID: 1662 - Brian Rosen was brought on as a co-author 1664 - Requirements that a location header were negatively received in 1665 the previous version of this document. AD and chair advice was to 1666 move all location information into a message body (and stay away 1667 from headers) 1669 - Added a section of "emergency call" specific requirements 1671 - Added an Open Issues section to mention what hasn't been resolved 1672 yet in this effort 1674 This is a list of the changes that have been made from the 1675 individual submission version -00 to the -01 version 1677 - Added the IPR Statement section 1679 - Adjusted a few requirements based on suggestions from the 1680 Minneapolis meeting 1682 - Added requirements that the UAC is to include from where it 1683 learned its location in any transmission of its LI 1685 - Distinguished the facts (known to date) that certain jurisdictions 1686 relieve persons of their right to privacy when they call a PSAP, 1687 while other jurisdictions maintain a person's right to privacy, 1688 while still others maintain a person's right to privacy - but only 1689 if they ask that their service be set up that way. 1691 - Made the decision that TLS is the security mechanism for location 1692 conveyance in emergency communications (vs. S/MIME, which is still 1693 the mechanism for UA-to-UA non-emergency location conveyance 1694 cases). 1696 - Added the Open Issue of whether a Proxy can insert location 1697 information into an emergency SIP INVITE message, and some of the 1698 open questions surrounding the implications of that action 1700 - added a few names to the acknowledgements section 1702 Intellectual Property Statement 1704 The IETF takes no position regarding the validity or scope of any 1705 Intellectual Property Rights or other rights that might be claimed 1706 to pertain to the implementation or use of the technology described 1707 in this document or the extent to which any license under such 1708 rights might or might not be available; nor does it represent that 1709 it has made any independent effort to identify any such rights. 1710 Information on the procedures with respect to rights in RFC 1711 documents can be found in BCP 78 and BCP 79. 1713 Copies of IPR disclosures made to the IETF Secretariat and any 1714 assurances of licenses to be made available, or the result of an 1715 attempt made to obtain a general license or permission for the use 1716 of such proprietary rights by implementers or users of this 1717 specification can be obtained from the IETF on-line IPR repository 1718 at http://www.ietf.org/ipr. 1720 The IETF invites any interested party to bring to its attention any 1721 copyrights, patents or patent applications, or other proprietary 1722 rights that may cover technology that may be required to implement 1723 this standard. Please address the information to the IETF at 1724 ietf-ipr@ietf.org. 1726 Disclaimer of Validity 1728 This document and the information contained herein are provided on 1729 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 1730 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE 1731 IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL 1732 WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY 1733 WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE 1734 ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS 1735 FOR A PARTICULAR PURPOSE. 1737 Copyright Statement 1739 Copyright (C) The IETF Trust (2007). This document is subject 1740 to the rights, licenses and restrictions contained in BCP 78, and 1741 except as set forth therein, the authors retain all their rights. 1743 Acknowledgment 1745 Funding for the RFC Editor function is currently provided by the 1746 Internet Society.