idnits 2.17.00 (12 Aug 2021) /tmp/idnits18767/draft-ietf-sip-location-conveyance-07.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 1755. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1731. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1738. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1744. 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 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 ...' == 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: 'RFC 4119' is mentioned on line 1365, but not defined ** Obsolete normative reference: RFC 2393 (ref. 'RFC2392') (Obsoleted by RFC 3173) ** Obsolete normative reference: RFC 3265 (Obsoleted by RFC 6665) ** Obsolete normative reference: RFC 3851 (Obsoleted by RFC 5751) -- Obsolete informational reference (is this intentional?): RFC 3825 (Obsoleted by RFC 6225) == Outdated reference: draft-ietf-geopriv-dhcp-civil has been published as RFC 4676 Summary: 4 errors (**), 0 flaws (~~), 7 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: Aug 12th, 2007 Brian Rosen 5 Intended Status: Standards Track NeuStar 7 Session Initiation Protocol Location Conveyance 8 draft-ietf-sip-location-conveyance-07.txt 9 Feb 12th, 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 August 12th, 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. This document uses the term "conveyance" to 93 describe scenarios in which a SIP user agent client (UAC) is telling 94 or informing a user agent server (UAS) where the UAC is. This is 95 different from a UAC asking or seeking the location of where the UAS 96 is. Conveyance is a push model, where seeking is a pull model, and 97 therefore not discussed here. 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 in this SIP extension is in the form of a Presence Information Data 112 Format - Location Object, or PIDF-LO, as described in [RFC4119]. A 113 PIDF-LO is an XML Schema specifically for carrying geographic 114 location of a thing. Location-by-value refers to a user agent 115 including a PIDF-LO as a body part of a SIP message, sending that 116 location object to another SIP element. Location-by-reference 117 refers to a user agent or proxy server including a URI in a SIP 118 message which can be exchanged by a location recipient for a 119 location object, in the form of a PIDF-LO. 121 As recited in RFC 3693, location often must be kept private. The 122 location object (PIDF-LO) contains rules which are binding on the 123 location recipient and controls onward distribution and retention of 124 the location. This document describes the security and privacy 125 considerations that must be applied to location conveyed with SIP. 127 Often, location is sent from the User Agent Client to the User Agent 128 Server, or vice versa for purposes that are beyond the scope of this 129 document. Another use for location is location-based routing of a 130 SIP request, where the choice of the next hop (and usually, the 131 outgoing Request URI) is determined by the location of the UAC which 132 is in the message by-value or by-reference. This document describes 133 how location may be conveyed from the UAC, or a proxy acting on its 134 behalf, to a routing proxy. How the location is actually used to 135 determine the next hop or Request-URI is beyond the scope of this 136 document. 138 The Geolocation header is introduced to signify that location is 139 included in a SIP message to provide either a content identifier 140 (cid:) pointer to the body part containing the UA's PIDF-LO, or a 141 location-by-reference URI that may subsequently be "dereferenced" by 142 a using protocol (which may be SIP or another protocol). 144 In this document, we frequently refer to the "emergency case". This 145 refers to a specific, important use of sip location conveyance where 146 the location of the caller is used to determine which Public Safety 147 Answering Point (PSAP) should receive an emergency call request for 148 help (e.g. a call to 1-1-2 or 9-1-1). This is an example of 149 location-based routing. The location conveyed is also used by the 150 PSAP to dispatch first responders to the caller's location. There 151 are special security considerations which make the emergency case 152 unique, compared to a normal location conveyance within SIP. 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 RFC 3261. 256 The pres-URI is defined in RFC 3859 [RFC3859]. 258 Other protocols used in the Location URI MUST be reviewed against 259 the RFC 3693 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 RFC 3261 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 RFC 4119. 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 Warning codes are in Section 3.4 of this document. 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 be 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. An 354 example of this transaction, with a 424 (Bad Location Information) 355 response, including a Warning header, would be in here in Figure 1. 357 Alice Bob 358 | | 359 | Request w/ Location | 360 | using http schema | 361 |----------------------------------->| 362 | | 363 | | 364 | 424 (Bad Location Information) | 365 | with Warning header containing | 366 | 720 (SIP), 721 (SIPS), 722 (PRES) | 367 |<-----------------------------------| 368 | | 370 Figure 1. Basic Transaction with Location Error 372 The following subsections provide an initial list of location 373 specific granular Warning codes for a 424 (Bad Location Information) 374 response. 376 3.4.1 Warning code 701 Location Format Not Supported 378 A Warning header with the code 701 "Location Format not supported" 379 means the location format supplied in the request, by-value or 380 by-reference, was not supported. This cause means the recipient 381 understood that location was included in the message, but the format 382 is not supported. Perhaps the format was a freeform text format or 383 data-URL and the recipient only understood location in RFC 4119 384 PIDF-LO format (civic or coordinate). If a more specific Warning 385 code is available, it MUST be used. For example, if the format is 386 understood, but not desired, a 702 or 703 Warning header should be 387 returned in a 424 response, depending on which location format is 388 desired. The same applies to a location recipient that only 389 understands one format and did not receive that format. For example, 390 if a message containing coordinate formatted location arrives but 391 the recipient only can process civic formatted location, a 703 392 Warning header should be returned in a 424 response. 394 Recommended warn-text: Location format not supported 396 An example usage in a SIP 424 response: 398 Warning: 701 alice.example.com "Location Format not supported" 400 3.4.2 Warning code 702 Coordinate-location Format Desired Instead 402 A Warning header with the code 702 "Coordinate-location Format 403 Desired" means the location format supplied in the request (probably 404 formatted in civic), by-value or by-reference, was understood and 405 supported, but that the recipient, or an application on the 406 recipient prefers, or can only process location in the 407 coordinate-location format. 409 A typical reaction to receiving this Warning code is to resend the 410 original message with location formatted in coordinate instead. 412 Recommended warn-text: Coordinate-location Format Desired 414 An example usage in a SIP 424 response: 416 Warning: 702 node_alice.example.com "Coordinate-location Format 417 Desired" 419 3.4.3 Warning code 703 Civic-location Format Desired Instead 421 A Warning header with the code 703 "Civic-location Format Desired" 422 means the location format supplied in the request (probably 423 formatted in coordinate), by-value or by-reference, was understood 424 and supported, but that the recipient, or an application on the 425 recipient prefers, or can only process location in the 426 civic-location format. 428 A typical reaction to receiving this warning code is to resend the 429 original message with location formatted in civic instead. 431 Recommended warn-text: Civic-location Format Desired 433 An example usage in a SIP 424 response: 435 Warning: 703 alice.example.com "Civic-location Format Desired" 437 3.4.4 Warning code 704 Cannot Parse Location Supplied 439 A Warning header with the code 704 "Cannot parse location supplied" 440 means the location provided, whether by-value or by-reference, in a 441 request is not well formed. 443 Recommended warn-text: Cannot parse location supplied 445 An example usage in a SIP 424 response: 447 Warning: 704 alice.example.com "Cannot parse location supplied" 449 3.4.5 Warning code 705 Cannot Find Location 451 A Warning header with the code 705 "Cannot find location" means 452 location should have been in the message received, but the recipient 453 cannot find it, either because it is not in the message, or it is 454 encrypted/opaque to the recipient. 456 A typical reaction to receiving this warning code is for the 457 location sender to verify that it has indeed included location 458 information in the request and then to send the request again. 460 Recommended warn-text: Cannot find location 462 An example usage in a SIP 424 response: 464 Warning: 705 alice.example.com "Cannot find location" 466 3.4.6 Warning code 706 Conflicting Locations Supplied 468 A Warning header with the code 706 "Conflicting Locations Supplied" 469 means a location recipient received more than one location 470 describing where the target is, and is either unsure which whole 471 location is true or which parts of multiple locations make up where 472 the target is. This is generally a case of either too much 473 information, and the information is conflicting. 475 A typical reaction to receiving this warning code is to reduce the 476 number of different locations supplied in the request, and send 477 another message to the location recipient. 479 Recommended warn-text: Conflicting Locations Supplied 481 An example usage in a SIP 424 response: 483 Warning: 706 alice.example.com "conflicting locations supplied" 485 3.4.7 Warning code 707 Incomplete Location Supplied 487 A Warning header with the code 707 "Incomplete Location Supplied" 488 means there is not enough location information, by-value or 489 by-reference, to determine where the location target is. 491 A typical reaction to receiving this warning code is for the 492 location sender to convey more location information, if doing so is 493 allowed by local policy. 495 Recommended warn-text: Incomplete location supplied 497 An example usage in a SIP 424 response: 499 Warning: 707 alice.example.com "Incomplete location supplied" 501 3.4.8 Warning code 708 Cannot Dereference 503 A Warning header with the code 708 "Cannot dereference" means the 504 act of dereferencing failed to return the target's location. This 505 generally means the supplied URI is bad. 507 Recommended warn-text: Cannot dereference 509 An example usage in a SIP 424 response: 511 Warning: 708 alice.example.com "Cannot dereference" 513 3.4.9 Warning code 709 Dereference Denied 515 A Warning header with the code 709 "Dereference Denied" means there 516 was insufficient authorization to dereference the target's location 517 at, or before the LIS. This is a application layer error, so it is 518 not to be confused with lacking permission through a lower layer 519 firewall. 521 Recommended warn-text: Dereference Denied 523 An example usage in a SIP 424 response: 525 Warning: 709 alice.example.com "Dereference Denied" 527 3.4.10 Warning code 710 Dereference Timeout 529 A Warning header with the code 710 "Dereference Timeout" means that 530 the dereferencing node has not received the target's location within 531 a reasonable timeframe. 533 Recommended warn-text: Dereference Timeout 535 An example usage in a SIP 424 response: 537 Warning: 710 alice.example.com "Dereference Timeout" 539 3.4.11 Warning code 711 Cannot Process Dereference 541 A Warning header with the code 711 "Cannot process Dereference" 542 means the dereference protocol has received an overload condition 543 error, indicating the location cannot be accessed at this time. If 544 a sip or sips schema were used to dereference the target's location, 545 and a 503 (Service Unavailable) were the response to the dereference 546 query, this 711 Warning code would be placed in the 424 (Bad 547 Location Information) response to the location sender. 549 Recommended warn-text: Cannot process Dereference 551 An example usage in a SIP 424 response: 553 Warning: 711 alice.example.com "Cannot process Dereference" 555 3.4.12 Warning code 720 Unsupported Schema - sip desired 557 A Warning header with the code 720 "Unsupported Schema - sip 558 desired" means the location dereferencer cannot dereference using 559 the location-by-reference URI schema supplied because it does not 560 support the necessary protocol to do this. This Warning code means 561 the location recipient can dereference the target's location using a 562 sip-URI schema. There can be more than one Warning code in a 563 Warning header, indicated in this context the recipient can 564 dereference using each schema protocol included in the Warning 565 header. 567 A typical reaction to receiving this warning code would be for the 568 location sender to send a URI with the sip schema. 570 Recommended warn-text: unsupported schema 572 An example usage in a SIP 424 response: 574 Warning: 720 alice.example.com "unsupported schema - sip desired" 576 3.4.12 Warning code 721 Unsupported Schema - sips desired 578 A Warning header with the code 721 "Unsupported Schema - sips 579 desired" means the location dereferencer cannot dereference using 580 the location-by-reference URI schema supplied because it does not 581 support the necessary protocol to do this. This Warning code means 582 the location recipient can dereference the target's location using a 583 sips-URI schema. There can be more than one Warning code in a 584 Warning header, indicated in this context the recipient can 585 dereference using each schema protocol included in the Warning 586 header. 588 Recommended warn-text: unsupported schema 590 An example usage in a SIP 424 response: 592 Warning: 721 alice.example.com "unsupported schema - sips desired" 594 3.4.13 Warning code 722 Unsupported Schema - pres desired 596 A Warning header with the code 722 "Unsupported Schema - pres 597 desired" means the location dereferencer cannot dereference using 598 the location-by-reference URI schema supplied because it does not 599 support the necessary protocol to do this. This Warning code means 600 the location recipient can dereference the target's location using a 601 pres-URI schema. There can be more than one Warning code in a 602 Warning header, indicated in this context the recipient can 603 dereference using each schema protocol included in the Warning 604 header. 606 Recommended warn-text: unsupported schema 608 An example usage in a SIP 424 response: 610 Warning: 722 alice.example.com "unsupported schema - pres desired" 612 3.5 The Geolocation Option Tag 614 This document creates and IANA registers one new option tag: 615 "geolocation". This option tag is to be used, per RFC 3261, in the 616 Require, Supported and Unsupported headers. Whenever a UA wants to 617 indicate it understands this SIP extension, the geolocation option 618 tag is included in a Supported header of the SIP message. 620 The purpose of the geolocation option-tag is to indicate support for 621 this extension in the Supported and Unsupported headers. Appearance 622 of the option tag in the Require header is a request for location to 623 be conveyed. 625 A UAC SHOULD NOT include this option tag in a Proxy-Require header, 626 since is not likely to understand the topology of the 627 infrastructure, and therefore would not understand which proxy will 628 do the location-based routing function, if any. 630 3.6 Using sip/sips/pres as a Dereference Protocol 632 A sip, sips or pres URI SHOULD be included in a Geolocation header 633 for the location-by-reference URI. When pres: is used, if the 634 resulting resolution, per [RFC3851], resolves to a sip: or sips: 635 URI, this section applies. Use of other protocols for dereferencing 636 of a pres: URI is not defined, and such use is subject to review 637 against RFC 3693 using protocol criteria. 639 Dereferencing using sip or sips MUST be accomplished by treating the 640 URI as a presence URI and dereferencing it by sending a SUBSCRIBE 641 request to a presence server as per [RFC3856]. The resulting NOTIFY 642 will contain a PIDF, which MUST contain a PIDF-LO. 644 When used in this manner, SIP is a using protocol per [RFC3693] and 645 elements receiving location MUST honor the 'usage-element' rules as 646 defined in Section 3.4 above. 648 A dereference of a location-by-reference URI using SUBSCRIBE is not 649 violating a PIDF-LO 'retransmission-allowed' element value set to 650 'no', as the NOTIFY is the only message in this multi-message series 651 of transactions that contains the UAC's location, with the location 652 recipient being the only SIP element to receive location - which is 653 the purpose of this extension: to convey location to a specific 654 destination. 656 4. Examples 658 Three examples of messages providing location are provided. One 659 shows location-by-value with coordinates, one shows 660 location-by-value with civic location and the third shows 661 location-by-reference. The examples for (Coordinate format) are 662 taken from [RFC3825] and (Civic format) are taken from [RFC4776] 663 and are for the exact same position on the Earth. The differences 664 between the two formats is within the of the 665 examples. Other than this portion of each PIDF-LO, the rest is the 666 same for both location formats. 668 4.1 Location-by-value (Coordinate Format) 670 This example shows an INVITE message with a coordinate, or 671 coordinate location. In this example, the SIP request uses a 672 sips-URI [RFC3261], meaning this message is TLS protected on a 673 hop-by-hop basis all the way to Bob's domain. 675 INVITE sips:bob@biloxi.example.com SIP/2.0 676 Via: SIP/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bK74bf9 677 Max-Forwards: 70 678 To: Bob 679 From: Alice ;tag=9fxced76sl 680 Call-ID: 3848276298220188511@atlanta.example.com 681 Geolocation: 682 ;inserted-by=endpoint 683 Supported: geolocation 684 Accept: application/sdp, application/pidf+xml 685 CSeq: 31862 INVITE 686 Contact: 687 Content-Type: multipart/mixed; boundary=boundary1 688 Content-Length: ... 690 --boundary1 692 Content-Type: application/sdp 694 ...SDP here 696 --boundary1 698 Content-Type: application/pidf+xml 699 Content-ID: alice123@atlanta.example.com 701 702 707 708 2007-03-20T14:00:00Z 709 710 711 712 713 714 33.001111N 715 96.68142W 716 717 718 719 720 no 721 2007-03-24T18:00:00Z 723 DHCP 724 www.cisco.com 725 726 727 728 729 730 --boundary1-- 732 The Geolocation header from the above INVITE... 734 Geolocation: 736 ...indicates the content-ID location [RFC2392] within the multipart 737 message body of were location information is, with SDP being the 738 other message body part. 740 If the Geolocation header were this instead: 742 Geolocation: 744 ...this would indicate location by-reference was included in this 745 message. It is expected that any node wanting to know where user 746 alice123 is would subscribe to server5 to dereference the sips-URI. 747 The returning NOTIFY would contain Alice's location in a PIDF-LO, as 748 if it were included in a message body (part) of the original INVITE 749 here. 751 4.2 Location-by-value (Civic Format) 753 This example shows an INVITE message with a civic location. The 754 headers are shown as if the location was S/MIME encrypted, but the 755 unencrypted location information is shown for clarity. The lines 756 below that have the '$' signs are encrypted. 758 INVITE sip:bob@biloxi.example.com SIP/2.0 759 Via: SIP/2.0/TCP pc33.atlanta.example.com 760 ;branch=z9hG4bK74bf9 761 Max-Forwards: 70 762 To: Bob 763 From: Alice ;tag=9fxced76sl 764 Call-ID: 3848276298220188511@atlanta.example.com 765 Geolocation: 766 ;inserted-by=endpoint 767 Supported: geolocation 768 Accept: application/sdp, application/pidf+xml 769 CSeq: 31862 INVITE 770 Contact: 771 Content-Type: multipart/mixed; boundary=boundary1 772 Content-Length: ... 774 --boundary1 776 Content-Type: application/sdp 778 ...SDP here 780 --boundary1 782 Content-Type: application/pkcs7-mime; 783 smime-type=enveloped-data; name=smime.p7m 784 Content-ID: alice123@atlanta.example.com 786 $ Content-Type: application/pidf+xml 787 $ 788 $ 789 $ 794 $ 795 $ 2007-03-20T14:00:00Z 796 $ 797 $ 798 $ 799 $ 800 $ US 801 $ Texas 802 $ Colleyville 803 $ 3913 804 $ Treemont 805 $ Circle 806 $ 76034 807 $ Haley's Place 808 $ 1 809 $ 810 $ 811 $ 812 $ no 813 $ 2007-03-24T18:00:00Z 815 $ DHCP 816 $ www.cisco.com 817 $ 818 $ 819 $ 820 $ 821 $ 822 --boundary1-- 824 4.3 Location-by-reference 826 Here is an example of an INVITE with a location-by-reference URI, 827 sips: in this case, instead of a location-by-value PIDF-LO message 828 body part shown in Sections 4.1 and 4.2. It is up to the location 829 recipient to dereference Alice's location at the Atlanta LIS. 831 INVITE sip:bob@biloxi.example.com SIP/2.0 832 Via: SIP/2.0/TCP pc33.atlanta.example.com 833 ;branch=z9hG4bK74bf9 834 Max-Forwards: 70 835 To: Bob 836 From: Alice ;tag=9fxced76sl 837 Call-ID: 3848276298220188511@atlanta.example.com 838 Geolocation: 839 ;inserted-by=server 840 Supported: geolocation 841 Accept: application/sdp, application/pidf+xml 842 CSeq: 31862 INVITE 843 Contact: 845 ...SDP goes here as the only message body 847 A location recipient would need to dereference the sips-URI in the 848 Geolocation header to retrieve Alice's location. If the 849 atlanta.example.com domain chooses to implement location conveyance 850 and delivery in this way (i.e. location-by-reference), it is 851 RECOMMENDED that entities outside this domain be able to reach the 852 dereferencing LIS server, otherwise this model of implementation is 853 only viable within the atlanta.example.com domain. This will likely 854 not suit some services already being considered in the IETF at the 855 time of this writing, such as emergency calling. 857 5. SIP Element Behavior 859 Because a person's location is generally considered to be sensitive 860 in nature, privacy of the location information must be protected 861 when transmitting such information. Section 26 of [RFC3261] defines 862 the security functionality SIPS for transporting SIP messages with 863 either TLS or IPSec, and S/MIME for encrypting message bodies from 864 SIP intermediaries that would otherwise have access to reading the 865 clear-text bodies. SIP endpoints SHOULD implement S/MIME to encrypt 866 the PIDF-LO message body (part) end-to-end when the intended 867 recipient is the opposite UA. The SIPS-URI from [RFC3261] MUST be 868 implemented for message protection (message integrity and 869 confidentiality) and SHOULD be used when S/MIME is not used. 870 Possession of a dereferenceable location URI may be equivalent to 871 possession of the location information itself and thus TLS SHOULD be 872 used when sending location-by-reference. 874 A PIDF includes identity information. It is possible for the 875 identity in the PIDF to be anonymous. Implementations of this 876 extension should consider the appropriateness of including an 877 anonymous identity in the location information where a real identity 878 is not required. When using location-by-reference, it is 879 RECOMMENDED that the URI not contain any identifying information 880 (for example use 3fg5t5yqw@example.com rather than 881 alice@example.com) 883 The entities receiving location MUST obey the privacy 884 and security rules in the PIDF-LO as described in RFC 4119, 885 regarding retransmission and retention. 887 Self-signed certificates SHOULD NOT be used for protecting a PIDF, 888 as the sender does not have a secure identity of the recipient. 890 More than one location representation or format, for example: civic 891 and coordinate, MAY be included in the same message body part, but 892 all MUST point at the same position on the earth. Multiple 893 representations allow the recipient to use the most convenient 894 representation of location. 896 There MAY be more than one PIDF-LO in the same SIP message, so long 897 as each is in a separate message body part. Each location body part 898 MAY point at different positions on the earth. The meaning of such 899 a construction is not defined, and may cause confusion at the 900 recipient. 902 5.1 UAC Behavior 904 A UAC may send location because it was requested to, to facilitate 905 location-based routing, or spontaneously (i.e. a purpose not defined 906 in this document but known to the UAC). A UAC MAY receive location 907 from the UAS spontaneously. 909 A UAC conveying location MUST include a Geolocation header with 910 either a location by-value indication (a cid-URL), or a location 911 by-reference indication (a dereferenceable URI). A location body 912 sent without a Geolocation header MUST NOT occur. The UAC 913 supporting this extension MUST include a Supported header with the 914 geolocation option tag. 916 The presence of the geolocation option tag in a Supported header 917 without a Geolocation header in the same message informs a receiving 918 SIP element the UAC understands the concept of location, but it does 919 not know or wish to convey its location at this time. Certain 920 scenarios exist (location-based routing) in which location is 921 required in a message in order to route the message properly. This 922 affects how a UAS or SIP server reacts to such a message. 924 The geolocation option tag SHOULD NOT be used in the Proxy-Require 925 Header. 927 If the UAC inserts a geolocation header, it SHOULD include a 928 "inserted-by=endpoint" parameter. For example: 930 Geolocation: ; 931 inserted-by=endpoint 933 UACs receiving a 424 (Bad Location Information) response MAY find a 934 more granular cause for the location based error in a Warning 935 header. Upon receiving a 424 error response, the UAC SHOULD take 936 appropriate steps based on the warning code before attempting to 937 convey location again. See Section 3.4. for the list of new 938 location specific Warning codes, all of which are IANA registered in 939 this document. 941 There MAY be future work defining additional error information, say 942 in an XML body, indicating exactly what the error was, if any of the 943 new Warning codes are ambiguous. 945 The behavior of the UAC receiving location is the same as the UAS, 946 as below, except a UAC cannot send a Warning code indicating 947 something was wrong with the location supplied by the UAS. In this 948 case, the location information SHOULD just be ignored in this 949 transaction. A UAC subscribing to a UAS for its location is a 950 better means of acquiring the UAS's location. This is a seeking or 951 pull model scenario, which is not defined here, and left for future 952 study. 954 5.2 UAS Behavior 956 If the Geolocation header is present, the type of URI contained in 957 the header field will indicate if location has been conveyed 958 by-value in a message body (part) or by-reference, requiring an 959 additional dereference transaction. If the by-reference URI is 960 sip:, sips: or pres:, the UAS will initiate a SUBSCRIBE to the URI 961 provided to retrieve the PIDF-LO of the UAC per [RFC3856]. If 962 successful, the PIDF-LO of the UAC will be returned in the NOTIFY 963 request from the server. 965 A Require header with the geolocation option tag indicates the 966 UAC is requiring the UAS understand this extension or else send an 967 error response. A 420 (Bad Extension) with a geolocation option tag 968 in a Unsupported header would be the appropriate response. 970 If the UAC conveys location in a request, but the UAS has one or 971 more problems with the location in the request (or while attempting 972 to dereference the UAC's location), a 424 (Bad Location Information) 973 response would be an appropriate response. If the UAS can indicate 974 what the problem is with the location in the request, in the form of 975 one of the new Warning codes specifically about location errors, the 976 Warning header SHOULD be included along with the most applicable 977 Warning code(s). Zero or more Warning codes are allowed in a 978 response. 980 For example, if a UAC conveyed location-by-reference and chose a 981 pres schema for the UAS to dereference, and the UAS cannot or will 982 not dereference using pres (for whatever reason), the UAS can 983 include more than one Warning code in the 424 response to indicate 984 what will be acceptable to the UAS in this case. This scenario would 985 like something like this: 987 Warning: 720 UAS-ID Unsupported Schema - sip desired, 988 721 UAS-ID Unsupported Schema - sips desired, 990 The UAS behavior for sending location is the same as the UAC as 991 above. 993 5.3 Proxy Behavior 995 [RFC3261] states message bodies cannot be added by proxies. 996 However, a proxy may add a header to a message. This implies that a 997 proxy MAY add a geolocation header with location-by-reference, but 998 not location-by-value. 1000 A proxy MAY read the Geolocation header, and the associated body, if 1001 not S/MIME protected, in transit if present, and MAY use the 1002 contents of the header to make location-based routing decisions. 1004 More than one Geolocation header or header value in a message is 1005 permitted. The meaning of such a construction is not defined, and 1006 may cause confusion at the recipient. 1008 Proxies that perform location-based routing may need to consult 1009 external databases or systems to determine the route. Transmission 1010 of the location information (which SHOULD NOT reveal identity, even 1011 if the proxy knows the identity) is governed by the 1012 'retransmission-allowed' and 'routing-query-allowed': 1014 Retransmission-allowed Routing-query-allowed Transmission for Query 1015 ---------------------- --------------------- ---------------------- 1016 "no" or not present "no" or not present Not Allowed 1017 "no" or not present "yes" Allowed 1018 "yes" not present Allowed 1019 "yes" "no" Not Allowed 1020 "yes" "yes" Allowed 1022 If transmission is not allowed per the above, the proxy SHOULD 1023 provide a suitable error response. The 424 (Bad Location) is the 1024 appropriate response here. 1026 5.3.1 Proxy Behavior with Geolocation Header Parameters 1028 When a message traverses a SIP intermediary, any existing 1029 Geolocation header value (URI or header parameter) MUST NOT be 1030 deleted. A Geolocation header value (URI or header parameter) MAY 1031 only be modified to indicate if the message was routed based on a 1032 specific geolocation URI. Further modification of this Geolocation 1033 header MUST NOT occur. For example: 1035 Geolocation: ; 1036 inserted-by=endpoint; message-routed-on-this-uri 1038 A SIP intermediary MAY add a new Geolocation URI value to a message. 1039 The proxy SHOULD NOT insert a location unless it is reasonably 1040 certain it knows the actual location of the endpoint, for example, 1041 if it thoroughly understands the topology of the underlying access 1042 network and it can identify the device reliably (in the presence of, 1043 for example, NAT). 1045 B2BUAs normally set the "inserted-by" parameter to "server". 1047 A server adding a geolocation value to an existing endpoint inserted 1048 location would look like: 1050 Geolocation: ; inserted-by=endpoint, 1051 ; 1052 inserted-by=server; 1054 If this message was then routed by an intermediary using the URI 1055 inserted by the server, the intermediary would note this as: 1057 Geolocation: ; inserted-by=endpoint, 1058 ; 1059 inserted-by=server; message-routed-on-this-uri 1061 It is conceivable that an initial routing decision is made on an 1062 existing header, and subsequently another routing decision is made 1063 on a different header, perhaps even subsequently added by another 1064 proxy on the path. While unusual, it could occur. In such a case, 1065 the later routing proxy MUST remove the incoming 1066 "message-routed-on-this-uri" and replace it with another on the URI 1067 it uses for routing. Downstream entities will not be able to 1068 determine that two routing decisions were made on different location 1069 values. Such a circumstance is considered unlikely to happen, and 1070 the inability to detect it is not considered harmful. 1072 5.3.2 Proxy Error Behavior with Warning Codes 1074 If a SIP intermediary detects a location specific problem with a SIP 1075 request, if SHOULD reply with a 424 (Bad Location Information) 1076 response and include the appropriate Warning code defined in Section 1077 3.4 so the UAC can take whatever corrective action it needs to take 1078 to send a new message with good location information. 1080 6. Special Considerations for Emergency Calls 1082 Emergency calls (1-1-2, 9-1-1, etc.) need location for two reasons: 1084 1. Location is needed to route the call to the correct Public Safety 1085 Answering Point (PSAP), and 1087 2. Location is needed by the PSAP to send responders to the location 1088 of the caller when the caller cannot accurately describe where 1089 s/he is 1091 While all of the privacy concerns for location apply to emergency 1092 calls, it is not acceptable for a security mechanism in place to 1093 support confidentiality of the location to cause an emergency call 1094 to be misrouted, or not supply location when it is needed. 1095 Therefore, some of the behaviors of elements in the path are 1096 different when used with an emergency call. 1098 Recognizing which calls are emergency calls is beyond the scope of 1099 this document. When an emergency call is placed, location is 1100 normally provided by the UAC. Since emergency calls must be routed 1101 based on location (and indeed, in some jurisdictions, there may be 1102 several steps to such routing), the location must be visible to 1103 proxies along the path. Thus S/MIME protection of location MUST NOT 1104 be used. TLS protection of location SHOULD be used, however, if 1105 establishment of the TLS connection fails, the call set-up 1106 operation, including location conveyance, MUST be retried without 1107 TLS. 1109 The entity inserting the geolocation header MUST specify the 1110 "inserted-by" parameter, with values of "endpoint" or "server" as 1111 appropriate. 1113 Both the "retransmission-allowed" and "routing-query-allowed" SHOULD 1114 be set to "yes". Querying for routing may be performed by proxies 1115 providing a routing service for emergency calls even if 1116 retransmission-allowed or routing-query-allowed is set to "no" or is 1117 not present. Proxies routing on the location MUST set the 1118 "message-routed-on-this-uri" parameter. 1120 While many jurisdictions force a user to reveal their location 1121 during an emergency call set-up, there are a small, but real, number 1122 of jurisdictions that allow a user to configure their calling device 1123 to disable providing location, even during emergency calling. This 1124 capability MUST be configurable, but is NOT RECOMMENDED as the 1125 default configuration of any UA. Local policies will dictate this 1126 ability. 1128 7. Geopriv Privacy Considerations 1130 Transmitting location information is considered by most to be highly 1131 sensitive information, requiring protection from eavesdropping, 1132 tracking, and altering in transit. [RFC3693] articulates rules to 1133 be followed by any protocol wishing to be considered a Geopriv 1134 "using protocol", specifying how a transport protocol meetings 1135 those rules. This section describes how SIP as a using protocol 1136 meets those requirements. 1138 Quoting requirement #4 of [RFC3693]: 1140 "The using protocol has to obey the privacy and security 1141 instructions coded in the location object and in the 1142 corresponding Rules regarding the transmission and storage 1143 of the LO." 1145 This document requires that SIP entities sending or receiving 1146 location MUST obey such instructions. 1148 Quoting requirement #5 of [RFC3693]: 1150 "The using protocol will typically facilitate that the keys 1151 associated with the credentials are transported to the 1152 respective parties, that is, key establishment is the 1153 responsibility of the using protocol." 1155 [RFC3261] and the documents it references define the key 1156 establishment mechanisms. 1158 Quoting requirement #6 of [RFC3693]: 1160 "(Single Message Transfer) In particular, for tracking of 1161 small target devices, the design should allow a single 1162 message/packet transmission of location as a complete 1163 transaction." 1165 When used for tracking, a simple NOTIFY or UPDATE normally is 1166 relatively small, although the PIDF itself can get large. Normal 1167 RFC 3261 procedures of reverting to TCP when the MTU size is 1168 exceeded would be invoked. 1170 8. Security Considerations 1172 Conveyance of physical location of a UAC raises privacy concerns, 1173 and depending on use, there may be authentication and integrity 1174 concerns. This document calls for conveyance to normally be 1175 accomplished through secure mechanisms (like S/MIME or TLS). In 1176 cases where a session set-up is routed based on the location of the 1177 UAC initiating the session or SIP MESSAGE, securing the by-value 1178 location with an end-to-end mechanism such as S/MIME is problematic, 1179 because one or more proxies on the path need the ability to read the 1180 information to route the message appropriately. Securing the 1181 location hop-by-hop, using TLS, protects the message from 1182 eavesdropping and modification, but exposes the information to all 1183 proxies on the path as well as the endpoint. In most cases, the UAC 1184 does not know the identity of the proxy or proxies providing 1185 location-based routing services, so that end to middle solutions may 1186 not be appropriate either. 1188 When the UAC is the source of the location information, which is 1189 RECOMMENDED, it can decide whether to reveal its location using 1190 hop-by-hop methods. UAC implementations MUST make such capabilities 1191 conditional on explicit user permission, and SHOULD alert a user 1192 that location is being conveyed. Emergency calls have their own 1193 rules in this regard, as detailed in Section 6. Proxies inserting 1194 location for location-based routing are unable to meet this 1195 requirement, and such use is NOT RECOMMENDED. Proxies conveying 1196 location using this extension MUST have the permission of the target 1197 to do so. 1199 9. IANA Considerations 1201 9.1 IANA Registration for the SIP Geolocation Header 1203 The SIP Geolocation header is created by this document, with its 1204 definition and rules in Section 3.2 of this document. 1206 9.2 IANA Registration for New SIP Option Tag 1208 The SIP option tag "Geolocation" is created by this document, with 1209 the definition and rule in Section 3.5 of this document. 1211 9.3 IANA Registration for Response Code 4XX 1213 Reference: RFC-XXXX (i.e. this document) 1214 Response code: 424 1215 Default reason phrase: Bad Location Information 1217 This SIP Response code is defined in section 3.3 of this document. 1219 9.4 IANA Registration of New Warning Codes for Location 1221 New location specific Warning codes are created by this document, 1222 with the definitions in Section 3.4 of this document. 1224 701 Location Format Not Supported 1225 702 Coordinate-location Format Desired Instead 1226 703 Civic-location Format Desired Instead 1227 704 Cannot Parse Location Supplied 1228 705 Cannot Find Location 1229 706 Conflicting Locations Supplied 1230 707 Incomplete Location Supplied 1231 708 Cannot Dereference 1232 709 Dereference Denied 1233 710 Dereference Timeout 1234 711 Cannot Process Dereference 1235 720 Unsupported Schema - sip desired 1236 721 Unsupported Schema - sips desired 1237 722 Unsupported Schema - pres desired 1239 Adding new location specific Warning codes, or modifying to existing 1240 location specific Warning codes requires an RFC and community 1241 review. 1243 10. Acknowledgements 1245 To Dave Oran for helping to shape this idea. To Jon Peterson and 1246 Dean Willis on guidance of the effort. To Allison Mankin, Dick 1247 Knight, Hannes Tschofenig, Henning Schulzrinne, James Winterbottom, 1248 Jeroen van Bemmel, Jean-Francois Mule, Jonathan Rosenberg, Keith 1249 Drage, Marc Linsner, Martin Thomson, Mike Hammer, Paul Kyzivat, 1250 Shida Shubert, and Matt Lepinski for constructive feedback. A 1251 special thanks to Dan Wing for help with the S/MIME example. 1253 11. References 1255 11.1 References - Normative 1257 [RFC3261] J. Rosenberg, H. Schulzrinne, G. Camarillo, A. Johnston, J. 1258 Peterson, R. Sparks, M. Handley, and E. Schooler, "SIP: 1259 Session Initiation Protocol", RFC 3261, May 2002. 1261 [RFC4119] J. Peterson, "A Presence-based GEOPRIV Location Object 1262 Format", RFC 4119, December 2005 1264 [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate 1265 Requirement Levels", RFC 2119, March 1997 1267 [RFC2392] E. Levinson, " Content-ID and Message-ID Uniform Resource 1268 Locators", RFC 2393, August 1998 1270 [RFC3863] H. Sugano, S. Fujimoto, G. Klyne, A. Bateman, W. Carr, J. 1271 Peterson, "Presence Information Data Format (PIDF)", RFC 1272 3863, August 2004 1274 [RFC3856] J. Rosenberg, " A Presence Event Package for the Session 1275 Initiation Protocol (SIP)", RFC 3856, August 2004 1277 [RFC3859] J. Peterson, "Common Profile for Presence (CPP)", RFC 3859, 1278 August 2004 1280 [RFC3428] B. Campbell, Ed., J. Rosenberg, H. Schulzrinne, C. Huitema, 1281 D. Gurle, "Session Initiation Protocol (SIP) Extension for 1282 Instant Messaging" , RFC 3428, December 2002 1284 [RFC3311] J. Rosenberg, "The Session Initiation Protocol (SIP) UPDATE 1285 Method", RFC 3311, October 2002 1287 [RFC3265] Roach, A., "Session Initiation Protocol (SIP)-Specific 1288 Event Notification", RFC 3265, June 2002. 1290 [RFC3851] B. Ramsdell, "Secure/Multipurpose Internet Mail Extensions 1291 (S/MIME) Version 3.1 Message Specification", RFC 3851, July 1292 2004 1294 11.2 References - Informative 1296 [RFC3693] J. Cuellar, J. Morris, D. Mulligan, J. Peterson. J. Polk, 1297 "Geopriv Requirements", RFC 3693, February 2004 1299 [RFC3825] J. Polk, J. Schnizlein, M. Linsner, "Dynamic Host 1300 Configuration Protocol Option for Coordinate-based Location 1301 Configuration Information", RFC 3825, July 2004 1303 [RFC4776] H. Schulzrinne, " Dynamic Host Configuration Protocol 1304 (DHCPv4 and DHCPv6) Option for Civic Addresses Configuration 1305 Information ", draft-ietf-geopriv-dhcp-civil-09, "work in 1306 progress", January 2006 1308 Author Information 1310 James Polk 1311 Cisco Systems 1312 3913 Treemont Circle 33.00111N 1313 Colleyville, Texas 76034 96.68142W 1315 Phone: +1-817-271-3552 1316 Email: jmpolk@cisco.com 1318 Brian Rosen 1319 NeuStar, Inc. 1320 470 Conrad Dr. 40.70497N 1321 Mars, PA 16046 80.01252W 1322 US 1324 Phone: +1 724 382 1051 1325 Email: br@brianrosen.net 1327 Appendix A. Requirements for SIP Location Conveyance 1329 The following subsections address the requirements placed on the 1330 user agent client, the user agent server, as well as SIP proxies 1331 when conveying location. There is a motivational statement below 1332 each requirements that is not obvious in intent 1334 A.1 Requirements for a UAC Conveying Location 1336 UAC-1 The SIP INVITE Method [RFC3261] must support location 1337 conveyance. 1339 UAC-2 The SIP MESSAGE method [RFC3428] must support location 1340 conveyance. 1342 UAC-3 SIP Requests within a dialog should support location 1343 conveyance. 1345 UAC-4 Other SIP Requests may support location conveyance. 1347 UAC-5 There must be one, mandatory to implement means of 1348 transmitting location confidentially. 1350 Motivation: interoperability 1352 UAC-6 It must be possible for a UAC to update location conveyed 1353 at any time in a dialog, including during dialog 1354 establishment. 1356 Motivation: in case a UAC has moved prior to the establishment of a 1357 dialog between UAs, the UAC must be able to send new location 1358 information. In the case of location having been conveyed, 1359 and the UA moves, it needs a means to update the conveyed to 1360 party of this location change. 1362 UAC-7 The privacy and security rules established within [RFC3693] 1363 that would categorize SIP as a 'using protocol' must be met. 1365 UAC-8 The PIDF-LO [RFC 4119] is a mandatory to implement format for 1366 location conveyance within SIP, whether included by-value or 1367 by-reference. 1369 Motivation: interoperability with other IETF location protocols and 1370 mechanisms 1372 UAC-9 There must be a mechanism for the UAC to request the UAS send 1373 its location 1375 UAC-10 There must be a mechanism to differentiate the ability of the 1376 UAC to convey location from the UACs lack of knowledge of its 1377 location 1379 Motivation: Failure to receive location when it is expected can be 1380 because the UAC does not implement this extension, or it can 1381 be that the UAC implements the extension, but does not know 1382 where it is. This may be, for example, due to the failure of 1383 the access network to provide a location acquisition 1384 mechanisms the UAC understands. These cases must be 1385 differentiated. 1387 UAC-11 It must be possible to convey location to proxy servers 1388 along the path. 1390 Motivation: Location-based routing. 1392 A.2 Requirements for a UAS Receiving Location 1394 The following are the requirements for location conveyance by a user 1395 agent server: 1397 UAS-1 SIP Responses must support location conveyance. 1399 UAS-2 There must be a unique 4XX response informing the UAC it did 1400 not provide applicable location information. 1402 In addition, requirements UAC-5, 6, 7 and 8 apply to the UAS 1404 A.3 Requirements for SIP Proxies and Intermediaries 1406 The following are the requirements for location conveyance by a SIP 1407 proxies and intermediaries: 1409 Proxy-1 Proxy servers must be capable of adding a Location header 1410 during processing of SIP requests. 1412 Motivation: Provide the capability of network assertion of location 1413 when UACs are unable to do so, or when network assertion is 1414 more reliable than UAC assertion of location 1416 Note: Because UACs connected to sip signaling networks may have 1417 widely varying access network arrangements, including VPN 1418 tunnels and roaming mechanisms, it may be difficult for a 1419 network to reliably know the location of the endpoint. Proxy 1420 assertion of location is NOT RECOMMENDED unless the sip 1421 signaling network has reliable knowledge of the actual 1422 location of the targets. 1424 Proxy-2 There must be a unique 4XX response informing the UAC it 1425 did not provide applicable location information. 1427 Appendix B. Changes from Prior Versions 1429 [NOTE TO RFC-EDITOR: If this document is to be published as an RFC, 1430 this Appendix B is to be removed prior to that event.] 1432 This is a list of the changes that have been made from the SIP WG 1433 version -06 to this version -07: 1435 - Fixed nits from Tools page 1437 - fixed subtle ambiguity in some sentences and misc. errors, based 1438 on feedback from -06. 1440 This is a list of the changes that have been made from the SIP WG 1441 version -05 to this version -06: 1443 - cleaned up some inconsistencies wrt the S/MIME example in Section 1444 4.2 1446 - changed the ABNF to include the ability to indicate which SIP 1447 element inserted a particular location URI, and how a message 1448 routing server indicates which location the message was routed 1449 upon (based on the location in the message) 1451 - changed the granular error code from a Reason header indication to 1452 a Warning code indication (section 3.4), and IANA registered 14 1453 new Warning codes in this document 1455 - As a consequence of the above bullet, changed the specific SIP 1456 element behaviors of each SIP element regarding sending or 1457 receiving a 424 response with a Warning header 1459 - Added rules about indicating which SIP element inserted a 1460 particular location into a message (a new Geolocation header 1461 parameter), as well as when a server adds another new header 1462 parameter indicating the request was routed based on a particular 1463 location included in the message 1465 This is a list of the changes that have been made from the SIP WG 1466 version -04 to this version -05: 1468 - altered the meaning of use of OPTIONS to not be for retrieving the 1469 location of a UAS, but for cases in which location is a required 1470 element of information by a SIP entity. 1472 - added a comment/warning for usage of location-by-reference to a 1473 model in which a domain's LIS be reachable if location is deployed 1474 in this fashion (Section 4.3) 1476 - added a Informative reference to a new ID that is an IANA registry 1477 of location specific error codes to be used in, for example, a 1478 Reason header, to give more granular reasons why a 424 (Bad 1479 Location Information) was sent. 1481 This is a list of the changes that have been made from the SIP WG 1482 version -03 to this version -04: 1484 - removed the inappropriate 2119 language from the Requirements 1485 section. 1487 - removed the old Section 2., which was a Location in a header vs. 1488 in a body artifact from the original versions of the document. 1490 - Added a new Geopriv (or Privacy) Considerations 1492 - Changed the ABNF to reflect discussion on how restrictive the 1493 location-by-reference schemes should be, with an added "Editor's 1494 Note" discussing the issues being faced on this point. 1496 - Changed the "Location" header and option-tag to "Geolocation" 1497 header and option-tag, due to it being pointed out that there is a 1498 conflicting HTTP header called "Location". 1500 - Added new element to PIDF-LO 'routing-query-allowed' 1502 - Stipulated the Reason Header can be used in the 424 Response 1503 Message 1505 - added SUBSCRIBE and NOTIFY as Methods for location conveyance when 1506 used to dereference a sip:, sips: or pres: location-by-reference 1507 URI 1509 - Added OPTIONS Method for a UAC to request the location of a UAS 1510 with a Require header geolocation option-tag. 1512 This is a list of the changes that have been made from the SIP WG 1513 version -02 to this version -03: 1515 - general clean-up of some of the sections 1517 - removed the message examples from the UPDATE, MESSAGE and REGISTER 1518 sections, as these seemed to be making the doc less readable, and 1519 not more readable 1521 - removed the "unknown" option tag, as it was not needed with a 1522 certain combination of the Supported and Location headers 1524 - clarified the location option tag usage in Supported, Require, 1525 Unsupported, and that it shouldn't be used in Proxy-Require, and 1526 why not. 1528 - Added a basic message flow to the basic operation section (Section 1529 4) to aid in understanding of this SIP extension. 1531 - Added a message routing flow, which is based on the location of 1532 the requestor to show how a SIP server can make a routing decision 1533 to a destination based on where the UAC is. 1535 - Articulated how a UAS concludes a UAC understands this extension, 1536 yet does not know its location to provide to the UAS. This is 1537 helpful in those times where an intermediary will act differently 1538 based on whether or not a UAC understands this extension, and 1539 whether or not the UAC includes its location in the request. 1541 - Corrected the erroneous text regarding an Unsupported header being 1542 in a 424 response. It belongs in a 420 response. (Section 5.1) 1544 - Corrected the BNF (I hope) 1546 - Corrected some text in Section 5 that read like this document was 1547 an update to RFC 3261. 1549 This is a list of the changes that have been made from the SIP WG 1550 version -01 to this version -02: 1552 - streamlined the doc by removing text (ultimately removing 42 pages 1553 of text). 1555 - Limited the scope of this document to SIP conveyance, meaning only 1556 how SIP can push location information. 1558 - reduced emergency calling text to just a few paragraphs now that 1559 the ECRIT WG is taking most of that topic on. 1561 - greatly reduced the number of requirements in this version. 1563 - changed the requirements groups from "UA-to-UA", "UA-to-Proxy", 1564 etc to "UAC Reqs", "UAS-Reqs" and "Proxy-Reqs" to focus on what is 1565 being asked of each SIP element. 1567 - Removed the full SIP message examples. 1569 - completed the ABNF for the Location header, including a cid-url to 1570 point at a message body part to help in parsing for location. 1572 - Deleted the call for a new 425 (Retry Location) response code, as 1573 it appears this can easily be used to spoof a UA into providing 1574 where it is inadvertently, even if the intent is legitimate by the 1575 UAC. 1577 This is a list of the changes that have been made from the SIP WG 1578 version -00 to this version -01: 1580 - cleaned up a lot of loose ends in the text 1582 - created a new Location header to convey many means (location is in 1583 the body - even if not viewable, which location format is present, 1584 which format is requested in a query, how to request more than one 1585 location format in a query, whether the UAC understands location 1586 at all, if the UA knows its location, how to push location from 1587 one UA to through a second to a third UA, etc). 1589 - added the ability to convey location by-reference, but only under 1590 certain conditions. 1592 - Added support for the OPTIONS Request to query a server for the 1593 UAC's location, through the use of the new Location header. 1595 - moved both new Response code sections forward in the document for 1596 their meaning to be clearer, earlier for necessary discussion. 1598 - Changed the message flows to only have the pertinent message 1599 headers shown for brevity. 1601 - Added text to the SUB/NOT section showing how and why the location 1602 of a UA can be refreshed or updated with an interval, or by a 1603 trigger. 1605 This is a list of the changes that have been made from the SIPPING 1606 WG version -02 to this SIP WG item document version -00: 1608 - Changed which WG this document is in from SIPPING to SIP due to 1609 the extension of the protocol with new Response codes (424 and 1610 425) for when there is an error involving the LO message body. 1612 - Moved most of the well formed SIP messages out of the main body of 1613 this document and into separate appendixes. This should clean up 1614 the document from a readability point of view, yet still provide 1615 the intended decode examples to readers of this document who wish 1616 that level of detail per flow. The first few flows still have the 1617 decoded SIP messages (unencrypted and encrypted). 1619 - Removed some flow examples which no longer made sense 1621 - Changed all references of "ERC" (Emergency Response Center) to 1622 "PSAP" (Public Safety Answering Point) as a result of discussion 1623 within the new ECRIT WG to define a single term 1625 This is a list of the changes that have been made from the sipping- 1626 01 working group version of this effort to the sipping-02 version: 1628 - added requirements for 2 new 4XX error responses (Bad Location 1629 Information) and (Retry Location Body) 1631 - added "Bad Location Information" as section 8.6 1633 - added "Retry Location Body " as section 9.3 1635 - added support for session mode to cover packet sizes larger than 1636 the single packet limit of 1300 bytes in the message body 1638 - added requirement for a SIP entity to SUBSCRIBE to another for 1639 location information 1641 - added SUBSCRIBE and NOTIFY as section 8.5 1643 - added requirement to have user turn off any tracking created by 1644 subscription 1646 - removed doubt about which method to use for updating location 1647 after a INVITE is sent (update) 1649 - cleaned up which method is to be used if there is no dialog 1650 existing (message) 1652 - removed use of reINVITE to convey location 1654 - clarified that UAs include element of PIDF-LO when 1655 placing an emergency call (to inform PSAP who supplied Location 1656 information) 1658 - updated list of open issues 1660 - added to IANA Considerations section for the two new 4XX level 1661 error responses requested in the last meeting 1663 This is a list of the changes that have been made from the sipping- 1664 00 working group version of this ID to the sipping-01 version: 1666 - Added the offered solution in detail (with message flows, 1667 appropriate SIP Methods for location conveyance, and 1669 - Synchronized the requirements here with those from the Geopriv 1670 Working Group's (attempting to eliminate overlap) 1672 - Took on the task of making this effort the SIP "using protocol" 1673 specification from Geopriv's POV 1675 - Refined the Open Issues section to reflect the progress we've made 1676 here, and to indicate what we have discovered needs addressing, 1677 but has not been to date. 1679 This is a list of the changes that have been made from the -01 1680 individual submission version to the sipping-00 version of this ID: 1682 - Brian Rosen was brought on as a co-author 1684 - Requirements that a location header were negatively received in 1685 the previous version of this document. AD and chair advice was to 1686 move all location information into a message body (and stay away 1687 from headers) 1689 - Added a section of "emergency call" specific requirements 1691 - Added an Open Issues section to mention what hasn't been resolved 1692 yet in this effort 1694 This is a list of the changes that have been made from the 1695 individual submission version -00 to the -01 version 1697 - Added the IPR Statement section 1699 - Adjusted a few requirements based on suggestions from the 1700 Minneapolis meeting 1702 - Added requirements that the UAC is to include from where it 1703 learned its location in any transmission of its LI 1705 - Distinguished the facts (known to date) that certain jurisdictions 1706 relieve persons of their right to privacy when they call a PSAP, 1707 while other jurisdictions maintain a person's right to privacy, 1708 while still others maintain a person's right to privacy - but only 1709 if they ask that their service be set up that way. 1711 - Made the decision that TLS is the security mechanism for location 1712 conveyance in emergency communications (vs. S/MIME, which is still 1713 the mechanism for UA-to-UA non-emergency location conveyance 1714 cases). 1716 - Added the Open Issue of whether a Proxy can insert location 1717 information into an emergency SIP INVITE message, and some of the 1718 open questions surrounding the implications of that action 1720 - added a few names to the acknowledgements section 1722 Intellectual Property Statement 1724 The IETF takes no position regarding the validity or scope of any 1725 Intellectual Property Rights or other rights that might be claimed 1726 to pertain to the implementation or use of the technology described 1727 in this document or the extent to which any license under such 1728 rights might or might not be available; nor does it represent that 1729 it has made any independent effort to identify any such rights. 1730 Information on the procedures with respect to rights in RFC 1731 documents can be found in BCP 78 and BCP 79. 1733 Copies of IPR disclosures made to the IETF Secretariat and any 1734 assurances of licenses to be made available, or the result of an 1735 attempt made to obtain a general license or permission for the use 1736 of such proprietary rights by implementers or users of this 1737 specification can be obtained from the IETF on-line IPR repository 1738 at http://www.ietf.org/ipr. 1740 The IETF invites any interested party to bring to its attention any 1741 copyrights, patents or patent applications, or other proprietary 1742 rights that may cover technology that may be required to implement 1743 this standard. Please address the information to the IETF at 1744 ietf-ipr@ietf.org. 1746 Disclaimer of Validity 1748 This document and the information contained herein are provided on 1749 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 1750 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE 1751 IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL 1752 WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY 1753 WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE 1754 ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS 1755 FOR A PARTICULAR PURPOSE. 1757 Copyright Statement 1759 Copyright (C) The IETF Trust (2007). This document is subject 1760 to the rights, licenses and restrictions contained in BCP 78, and 1761 except as set forth therein, the authors retain all their rights. 1763 Acknowledgment 1765 Funding for the RFC Editor function is currently provided by the 1766 Internet Society.