idnits 2.17.1 draft-ietf-sip-location-conveyance-09.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 2126. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 2137. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 2144. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 2150. 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 43 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 556 has weird spacing: '... ar o ...' == Line 560 has weird spacing: '... ar o ...' == Line 1250 has weird spacing: '...orValue shoul...' == Line 1483 has weird spacing: '... the conten...' == Line 1671 has weird spacing: '...et this requi...' == 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: None ---------------------------------------------------------------------------- == Missing Reference: 'RFC2976' is mentioned on line 328, but not defined ** Obsolete undefined reference: RFC 2976 (Obsoleted by RFC 6086) == Missing Reference: 'RFC3515' is mentioned on line 329, but not defined == Missing Reference: 'RFC3903' is mentioned on line 331, but not defined == Missing Reference: 'RFC 4119' is mentioned on line 1962, but not defined ** 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: 4 errors (**), 0 flaws (~~), 12 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: May 16th, 2008 Brian Rosen 5 Intended Status: Standards Track (PS) NeuStar 7 Location Conveyance for the Session Initiation Protocol 8 draft-ietf-sip-location-conveyance-09.txt 9 Nov 16th, 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 progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on May 16th, 2008. 36 Copyright Notice 38 Copyright (C) The IETF Trust (2007). 40 Abstract 42 This document defines an extension to the Session Initiation 43 Protocol (SIP) to convey geographic location information from one 44 SIP entity to another SIP entity. The extension covers end to end 45 conveyance as well as location-based routing, where proxy servers 46 make routing decisions based on the location of the SIP user agents. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 51 2. Conventions used in this document . . . . . . . . . . . . . . 4 52 3. Mechanisms . . . . . . . . . . . . . . . . . . . . . . . . . 4 53 3.1 Overview of SIP Location Conveyance . . . . . . . . . . . 4 54 3.2 The Geolocation Header . . . . . . . . . . . . . . . . . 5 55 3.3 424 (Bad Location Information) Response Code . . . . . . 8 56 3.4 The Geolocation-Error Header . . . . . . . . . . . . . . 9 57 3.5 The Geolocation Option Tag . . . . . . . . . . . . . . . 18 58 3.6 Using sip/sips/pres as a Dereference Scheme . . . . . . . 19 59 4. Geolocation Examples . . . . . . . . . . . . . . . . . . . . 20 60 4.1 Location-by-value (Coordinate Format) . . . . . . . . . . 20 61 4.2 Location-by-reference . . . . . . . . . . . . . . . . . . 22 62 5. SIP Element Behavior . . . . . . . . . . . . . . . . . . . . 23 63 5.1 UAC Behavior . . . . . . . . . . . . . . . . . . . . . . 24 64 5.2 UAS Behavior . . . . . . . . . . . . . . . . . . . . . . 26 65 5.3 Proxy Behavior . . . . . . . . . . . . . . . . . . . . . 29 66 6. Geopriv Privacy Considerations . . . . . . . . . . . . . . . 32 67 7. Security Considerations . . . . . . . . . . . . . . . . . . . 33 68 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . 34 69 8.1 IANA Registration for New SIP Geolocation Header . . . . 34 70 8.2 IANA Registration for New SIP Geolocation Option Tag . . 35 71 8.3 IANA Registration for New 424 Response Code . . . . . . . 35 72 8.4 IANA Registration for New SIP Geolocation-Error Header . 35 73 8.5 IANA Registration for New SIP Geolocation-Error Codes . . 35 74 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 37 75 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 37 76 10.1 Normative References . . . . . . . . . . . . . . . . . 37 77 10.2 Informative References . . . . . . . . . . . . . . . . . 38 78 Author Information . . . . . . . . . . . . . . . . . . . . . 38 79 Appendix A. Requirements for SIP Location Conveyance . . . . 39 80 Appendix B. Example of Civic-based PIDF-LO w/ S/MIME . . . . 41 81 Intellectual Property and Copyright Statements . . . . . . . 42 83 1. Introduction 85 This document describes how Location can be "conveyed" (that is, 86 transmitted over the Internet) from one SIP user agent (UA), or in 87 some circumstances, a proxy server acting in support of a UA, to 88 another entity using SIP [RFC3261]. Here "Location" is a 89 description of the physical geographical area where something 90 currently exists. The phrase "location conveyance" describes 91 scenarios in which a SIP user agent client (UAC) is informing a user 92 agent server (UAS), or intermediate SIP server where the UAC is. A 93 superset of this can also be true as well, in which one UA(1) is 94 telling another UA(2) where another Target is, meaning not 95 necessarily where UA(1) is. The key to this is whether UA(1) has 96 permission to retransmit that other Target's location. If yes, then 97 this is valid. If no, then this is breaking a fundamental rule 98 within this extension. 100 Location Conveyance is different from a UAC seeking the location the 101 UAS. Location conveyance is a 'sending location out in the request' 102 model, where 'asking that someone else's location be in a response' 103 is not discussed here. 105 Geographic location in the IETF is discussed in RFC 3693 (Geopriv 106 Requirements) [RFC3693]. It defines a "Target" as the entity whose 107 location is being sought. In this case, this is the UA's 108 (UA) location. A [RFC3693] "Using Protocol" defines how a "location 109 Server" transmits a "Location Object" to a "Location Recipient" 110 while maintaining the contained privacy intentions of the Target 111 intact. This document describes the extension to SIP for how it 112 complies with the Using Protocol requirements, where the location 113 server is a UA or Proxy Server and the Location Recipient is 114 another UA or Proxy Server. 116 Location can be transmitted by-value or by-reference. The location 117 "value" in this SIP extension is in the form of a Presence 118 Information Data Format - Location Object, or PIDF-LO, as described 119 in [RFC4119]. A PIDF-LO is an XML Scheme specifically for carrying 120 geographic location of a Target. Location-by-value refers to a UA 121 including a PIDF-LO as a body part of a SIP message, sending that 122 Location Object to another SIP element. Location-by-reference 123 refers to a UA or proxy server including a URI in a SIP message 124 header field which can be dereferenced by a Location Recipient for a 125 Location Object, in the form of a PIDF-LO. Dereferencing can be by 126 a SIP UA or a SIP server. 128 As recited in RFC 3693, location often must be kept private. The 129 Location Object (PIDF-LO) contains rules which provides guidance to 130 the Location Recipient and controls onward distribution and 131 retention of the location. This document describes the security and 132 privacy considerations that must be applied to location conveyed 133 with SIP. 135 Another use for location is location-based routing of a 136 SIP request, where the choice of the next hop (and usually, the 137 outgoing Request-URI) is determined by the location of the UAC which 138 is in the message by-value or by-reference. This document describes 139 how location can be conveyed from the UAC, or a proxy acting on its 140 behalf, to a routing proxy. How the location is actually used to 141 determine the next hop or Request-URI is beyond the scope of this 142 document. 144 We refer to the "emergency case". This refers to a specific, 145 important use of SIP location conveyance where the location of the 146 caller is used to determine which Public Safety Answering Point 147 (PSAP) is expected to receive an emergency call request for help 148 (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 defines a new SIP header: Geolocation. The 166 Geolocation header field contains a URI which can either be a "cid:" 167 URI (Content Identification), per [RFC2392], or a 168 location-by-reference URI to be dereferenced by a Location Recipient 169 to retrieve the location of the Target UA. 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 field is a scheme other than 178 "cid:", another protocol operation is needed by the SIP message 179 recipient to 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, can be included by a UA in a 185 SIP message. A SIP proxy server may assert location of the UA by 186 inserting the header field, which must specify a 187 location-by-reference URI. Since body parts cannot be inserted by a 188 SIP proxy server, location-by-value message body cannot be inserted 189 by a proxy. 191 The Geolocation header can have parameters that are associated 192 with a URI in the header field. The "inserted-by" parameter has 193 values of "endpoint" or "server", indicating which entry added 194 location to the message. This header parameter MAY be added every 195 time a new location is added into a message. 197 Retargeting means the Request-URI of the request has changed to 198 point at a new destination UAS. This is different than message 199 routing, that all SIP proxies do. If a SIP request is retargeted 200 based on the location contained or referenced within that message, 201 the "used-for-routing" parameter MUST be added as a header parameter 202 within the appropriate locationValue. 204 There is no mechanism by which the veracity of these parameters can 205 be verified. They are hints to downstream entities on how the 206 location information in the message was originated and used. 208 This document creates a new option tag: geolocation, to indicate 209 support for the this extension by UAs. 211 A new error message (424 Bad Location Information) is also defined 212 in this document. Within this response is a new header indicating 213 location-based errors, call the Geolocation-Error header. This 214 header has various codes that provide additional information about 215 the type of location error experienced by a Location Recipient. 217 Both new headers, the header parameters, the new option-tag, the new 218 error response, and Geolocation-Error codes are IANA registered by 219 this document. 221 3.2 The Geolocation Header 223 This document defines and IANA registers a new SIP header: 224 Geolocation. The Geolocation header field MUST contain at least one 225 of two types of URIs: 227 o a location-by-reference URI, or 229 o a content-ID indicating where location is within the message body 230 of this message 232 A location-by-reference URI is a pointer to a record on a remote 233 node containing location of the location Target, typically the 234 UA in this transaction. 236 A location-by-value content-ID (cid-url) [RFC2392] indicates which 237 message body part contains location for this UA. 239 The Geolocation header has the following BNF syntax: 241 Geolocation = "Geolocation" HCOLON (locationValue *(COMMA 242 locationValue)) 243 locationValue = LAQUOT locationURI RAQUOT *(SEMI geoloc-param) 244 locationURI = sip-URI / sips-URI / pres-URI 245 / cid-url ; (from RFC 2392) 246 / absoluteURI ; (from RFC 3261) 247 geoloc-param = "inserted-by" EQUAL geoloc-inserter 248 / "used-for-routing" 249 / "recipient" EQUAL recipient-type 250 / generic-param ; (from RFC 3261) 251 geoloc-inserter = host-id 252 / gen-value ; (from RFC 3261) 254 recipient-type = "endpoint" / "routing-entity" / "both" 255 / gen-value ; (from RFC 3261) 257 sip-URI, sips-URI and absoluteURI are defined according to RFC 3261. 258 The pres-URI is defined in RFC 3859 [RFC3859]. 260 The cid-url is defined in [RFC2392] to locate message body 261 parts. This URI type MUST be present in a SIP message if location 262 is by-value in that same message. 264 Other protocols used in the Location URI MUST be reviewed against 265 the RFC 3693 criteria for a Using Protocol. 267 The Geolocation header MAY have one or more locationValues. SIP 268 servers inserting a locationValue MUST add the new value to the end 269 of the header value, such that the last locationValue in the header 270 is the most recent one added to the message. 272 A locationValue has the following independent header parameters, 274 o the "inserted-by=" parameter provides the host-id 275 (alice.example.com -- which is the same as the "sent-by" 276 parameter in a Via header) of the SIP entity that inserted this 277 locationValue into the request. This is used to map to any 278 Geolocation-Error message to determine which location, if there 279 is more than one in a request, the error corresponds to. If an 280 entity receives an Geolocation-Error with a host-id not of this 281 entity, the Geolocation-Error SHOULD be ignored. 283 o the "used-for-routing" parameter to inform recipients that the 284 location in this locationValue was used to route the message 285 towards the ultimate destination UAS. This can occur more than 286 once along the request's path. Because locationValues are 287 inserted as last inserted is last in the header, the last 288 locationValue is the most recent one added to the message. This 289 also gives the "used-for-routing" header parameter added 290 integrity - as the receiving SIP entity knows which locationURI 291 the message was routed upon. 293 o the "recipient=" parameter to allow recipients to infer what SIP 294 element type this locationValue was intended to be for. The 295 types are 297 o "endpoint" - meaning the ultimate destination UAS; 299 o "routing-entity" - meaning SIP servers that route messages 300 based on the location contents of requests; and 302 o "both" - meaning this locationValue is to be viewed by both 303 types of SIP entities. 305 Not all SIP entities have to read the locationValue within a 306 Geolocation header, therefore a parameter value of "both" does 307 not mean "every" SIP element receiving this request, it means all 308 that care to pay attention to a locationValue. The default 309 behavior of SIP entities reading the locationValue is that if 310 this header parameter is NOT present, the intended recipient is 311 the destination UAS. 313 Each locationValue MUST contain exactly one "inserted-by" parameter, 314 indicating which SIP entity added the locationValue to the SIP 315 request. 317 Each of the three types of header parameters listed here MAY appear 318 in any locationValue once. There MUST NOT be more than one 319 "inserted-by=" parameter or one "used-for-routing" parameter or one 320 "recipient=" parameter in the same locationValue. However, there 321 can be more than one locationValue in the same Geolocation header. 323 This document defines the Geolocation header as valid in the 324 following SIP requests: 326 INVITE [RFC3261], REGISTER [RFC3261], 327 OPTIONS [RFC3261], BYE [RFC3261], 328 UPDATE [RFC3311], INFO [RFC2976], 329 MESSAGE [RFC3428], REFER [RFC3515], 330 SUBSCRIBE [RFC3265], NOTIFY [RFC3265], 331 PUBLISH [RFC3903] and PRACK [RFC3262] 333 Discussing location using the PUBLISH Request Method is out of scope 334 for this document, but the Table 1 shows PUBLISH is to support 335 Location Conveyance via this extension. 337 The following table extends the values in Table 2&3 of RFC 3261 338 [RFC3261]. 340 Header field where proxy INV ACK CAN BYE REG OPT PRA 341 ---------------------------------------------------------------- 342 Geolocation R ar o - - o o o o 344 Header field where proxy SUB NOT UPD MSG REF INF PUB 345 ---------------------------------------------------------------- 346 Geolocation R ar o o o o o o o 348 Table 1: Summary of the Geolocation Header 350 The Geolocation header field MAY be included in any one of the above 351 requests by a UAC. A proxy MAY add the Geolocation header, but MUST 352 NOT modify any pre-existing locationValue, including its associated 353 header parameters of within an existing Geolocation header value, 354 unless one of the existing locationValues is used to retarget the 355 request towards a new destination UAS. This is discussed in section 356 5.3. 358 [RFC3261] states message bodies cannot be added by proxies. 359 Therefore, any Geolocation header field added by a proxy MUST be in 360 the form of a location-by-reference URI, in its own locationValue 361 header value. 363 Adding a new locationValue to an existing Geolocation header SHOULD 364 NOT occur without appropriate caution to the fact that Location 365 Recipients might not understand how to process more than one 366 location, given this document's limited guidance as to what a 367 Location Recipient should do when receiving more than one location 368 (i.e., currently no priority instructions are given for which 369 locationValue to use if there are more than one). A Location 370 Recipient can easily be confused by too much location information, 371 producing undesirable results. The element in the 372 PIDF-LO XML indicates whose location is contained in the PIDF-LO. 374 Location Recipients receiving a location object, received directly 375 or as the result of a dereference, MUST honor the usage element 376 rules within that XML document, per RFC 4119. Such entities MUST 377 NOT alter the rule set. 379 3.3 424 (Bad Location Information) Response Code 381 If a UAS or SIP intermediary detects an error in a request message 382 specific to the location information supplied by-value or 383 by-reference. The new 4XX level error is created here to indicate a 384 problem with the location in the request message. This document 385 creates and IANA registers the new error code: 387 424 (Bad Location Information) 389 The 424 (Bad Location Information) response code is a rejection of 390 the request, due to its location contents, indicating the location 391 information was malformed or not satisfactory for the recipient's 392 purpose, or could not be dereferenced. 394 Section 3.4 creates the Geolocation-Error header to provide more 395 detail about what was wrong with the location information in the 396 request. This header MUST be in the 424 response, containing a 397 locationErrorValue for each invalid locationValue in the request 398 (i.e., and one-for-one matching if all locationValues in the request 399 were bad). 401 If more than one location is present in a request (by-value or 402 by-reference), and any of the locationValues is good for the 403 Location Recipient to process, a 424 MUST NOT be sent. The 424 is 404 only appropriate when the Location Recipient needs a locationValue 405 and there are no locationValues included in a SIP request that are 406 usable by a recipient. 408 A 424 (Bad Location Information) response is a final response within 409 a transaction, and does not terminate a dialog. 411 The UAC can use whatever means it knows of to verify/refresh its 412 location information before attempting a new request that includes 413 location. There is no cross-transaction awareness expected by either 414 the UAS or SIP intermediary as a result of this error message. 416 The new 424 (Bad Location Information) error code is IANA registered 417 in Section 8 of this document. An initial set of location error of 418 IANA registered Geolocation-Error codes are in Section 3.4 of this 419 document. 421 3.4 The Geolocation-Error Header Providing Error Granularity 423 As discussed in Section 3.3, more granular error notifications, 424 specific to location errors within a received request, are required 425 if the UAC is to know what was wrong within the original request. 426 The Geolocation-Error header is created here for this purpose. 427 Geolocation-Error header is used to convey location specific errors 428 within a response. Additions to this IANA registered header require 429 an RFC be published. 431 Geolocation-Error = "Geolocation-Error" HCOLON 432 [locationErrorValue 433 *(COMMA locationErrorValue)] 434 locationErrorValue = location-error-code *(SEMI 435 location-error-params) 436 location-error-code = 1*3DIGIT 437 location-error-params = location-error-node-id 438 / DQOUTE location-error-host-id DQOUTE 439 / CAtype *(SEMI CAtype) 440 / DQOUTE location-error-code-text DQOUTE 441 / generic-param ; from RFC3261 442 location-error-node-id = "node" EQUAL hostname; from RFC3261 443 location-error-host-id = "inserter" EQUAL hostname ; from RFC3261 444 CAtype = "CAtype" EQUAL civic-code *(SEMI "CAtype" 445 EQUAL civic-code) 446 location-error-code-text = "code" EQUAL quoted-string ; from RFC3261 447 civic-code = IANA registered CAtypes; from 448 [IANA-civic] 450 The Geolocation-Error header MUST contain at least one 451 locationErrorValue to indicate what was wrong with the original 452 locationValue in the corresponding request. If a Location Recipient 453 experienced more than one error in the locationValue of the 454 corresponding SIP request, there can be one locationErrorValue per 455 problem with the locationValue in the request (the except to this is 456 involving CAtypes, which will be covered later here). If there was 457 something wrong with more than one locationValue in a request, a 458 corresponding locationErrorValue would be sent, one per error, in 459 the response. Each locationErrorValue contains a 3-digit error code 460 (defined in subsections to this section of this doc) indicating what 461 was wrong with the location(s) in the request. Each error type has 462 a corresponding quoted error text string that is human 463 understandable. 465 Also within the locationErrorValue is the Location Recipient 466 identifier (the "node=") who experienced the location error, as well 467 as an identifier of which SIP entity (the "inserter=") the Location 468 Recipient is told (in the locationValue) added the locationValue to 469 this request. The "node=" and "inserter=" are domain identifier of 470 a SIP entity, the same as is entered in the "sent-by" parameter of 471 the Via header for that entity [RFC3261]. As stated in section 18 472 of RFC 3261, the usage of FQDN is RECOMMENDED. Here are examples of 473 both 475 node=bob.example.com 477 inserter=alice.example.com 479 Both "node=" and "inserter=" parameters MUST be present in all 480 locationErrorValues in a response, unless the "inserted-by=" 481 parameter was not in the request. The "inserter=" parameter is 482 copied from the "inserted-by=" parameter within the locationValue of 483 the request. 485 Here's why, a Location Recipient that experienced the location 486 problem with the request needs to tell who added which location into 487 the original request. Since more than one SIP entity can insert 488 location into a request, all other SIP elements may be confused by 489 receiving this error header. So, the header has to identify who it 490 is for, so that all other SIP entities that read the header know to 491 ignore it, since it is not for them. This is of particular use if 492 the original UAC did not include a locationValue in the original SIP 493 request, but a SIP server along the path did insert a locationValue. 494 The locationErrorValue would travel to each SIP entity along the 495 original path and tell both the server that included the 496 locationValue what was wrong with the location and the UAC who 497 did not know what the error meant. 499 A worse case is when both the original UAC and a SIP server along 500 the path included a locationValue, but there was only something 501 wrong with one of the locationValues. Without this identification 502 of which locationValue was in error, both entities would react and 503 one would do so incorrectly. 505 Finally, there can be a list of one or more CAtype civic-codes that 506 are determined to be in error by the Location Recipient. Perhaps 507 the Location Recipient believes one or more CAtypes are missing, and 508 required in order to fully process the locationValue in the request, 509 or perhaps data entered in one or more CAtypes is wrong, according 510 to the Location Recipient. The list of CAtypes is taken from those 511 that are IANA registered at [IANA-civic]. 513 More than one locationErrorValue in a Geolocation-Error header is 514 separated by a comma. 516 If more than one locationErrorValue is in a response, and intended 517 for the same "inserter=", the error codes SHOULD NOT conflict in 518 meaning. In other words, two error codes (within separate 519 locationErrorValues of the same response) SHOULD NOT give misleading 520 or inconsistent indications to the location "inserter=". 522 Here is an example of a Geolocation-Error header 524 Geolocation-Error: 106; "node=bob.example.com"; 525 "inserter=alice.example.com"; 526 CAtype=A3; CAtype=STS; 527 code="incomplete location supplied" 529 In this example, the Location Recipient (node=Bob) has determined 530 the location supplied by the "inserter=" (inserter=Alice) was not 531 enough to determine where (Alice) was. Specifically, Bob has 532 determined that CAtypes A3 (the city) and STS (the street type 533 (Street, Road, Avenue, etc)) were not present to form a complete 534 location of the Alice. A subsequent request by Alice that included 535 these two additional pieces of location information would tell Bob 536 where Alice was. 538 Notice the CAtypes that were in error are (in the above example 539 Geolocation-Error header), according to the Location Recipient, 540 listed in the locationErrorValue. The associated CAtype values MUST 541 NOT be listed in the locationErrorValue. This is for 542 privacy/security concerns. It is up to the Location Recipient to 543 determine which CAtypes were in error, and only list those CAtypes 544 in the response. The "inserter=" entity MUST determine what to do 545 about correcting each CAtype found in error for subsequent location 546 conveyance. Usually, this would involve either refreshing its 547 location information however it learned its location in the first 548 place, or merely listing what information is lacking/wrong to the 549 location sender (i.e., the user) or its network management. 551 The following table extends the values in Table 2&3 of RFC 3261 552 [RFC3261]. 554 Header field where proxy INV ACK CAN BYE REG OPT PRA 555 ---------------------------------------------------------------- 556 Geolocation-Error r ar o - - o o o o 558 Header field where proxy SUB NOT UPD MSG REF INF PUB 559 ---------------------------------------------------------------- 560 Geolocation-Error r ar o o o o o o o 561 Table 2: Summary of the Geolocation-Error Header 563 The Geolocation-Error header field MAY be included in any response 564 to one of the above SIP requests, so long as Geolocation was in the 565 request part of the transaction. The choice of which SIP requests 566 are in table 2 above come from which Methods can optionally have the 567 Geolocation header (see section 3.2). 569 Here is an example of a transaction that has a location error. In 570 this case, Bob responds with a 424 (Bad Location Information) 571 response, including a Geolocation-Error header, is in Figure 1. 573 Alice Bob 574 | | 575 | Request w/ Location | 576 |--------------------------------------->| 577 | | 578 | | 579 | 424 (Bad Location Information) | 580 | with Geolocation-Error containing | 581 | 106 (Incomplete Location Information) | 582 |<---------------------------------------| 583 | | 585 Figure 1. Basic Transaction with 424 and Geolocation-Error Header 587 The following subsections provide an initial list of location 588 specific granular codes for any SIP responses, including the new 424 589 (Bad Location Information) response. If more than one specific 590 Geolocation-Error code is applicable for a response, each MUST be in 591 the response. Geolocation-Error Code 100 is the generic 'location 592 was supplied, but not understood' error. If a more specific code 593 applies, a code 100 is unnecessary. 595 3.4.1 Geolocation-Error Code 100 Location Not Understood 597 Geolocation-Error code 100 "Location Format not supported" means the 598 location format supplied in the request, by-value or by-reference, 599 was not supported. 601 This code means the recipient understood that location was included 602 in the message, but the format is not supported. Perhaps the format 603 was a freeform text format or data-URL and the recipient only 604 understood location in RFC 4119 PIDF-LO format (civic or 605 x.y(.z) coordinate). This error code applies when a recipient has 606 difficulty parsing the location supplied in the request. 608 If the format is understood, but not desired, an error code 101 or 609 102 MUST be returned in a 424 response, depending on which location 610 format is desired. The Location Recipient returns an error code 101 611 or 102 when it only understands one location format (coordinate or 612 civic) and did not receive that format. 614 If a more specific error code is appropriate in a response, 615 including error code 100 is unnecessary. 617 error-text-string: Location format not supported 619 An example usage in a SIP 424 response: 621 Geolocation-Error: 100; "node=bob.example.com"; 622 "inserter=alice.example.com"; 623 CAtype=A3; CAtype=STS; 624 code="Location Format not supported" 626 3.4.2 Geolocation-Error Code 101 Coordinate-location Format Desired 628 Geolocation-Error code 101 "Coordinate-location Format Desired" 629 means the location format supplied in the request (probably 630 formatted in civic), by-value or by-reference, was understood and 631 supported, but that the recipient, or an application on the 632 recipient, can or prefers to only process location in the 633 coordinate-location format. 635 A typical reaction to receiving this code is to resend the 636 original message with location formatted in coordinate instead. 638 error-text-string: Coordinate-location Format Desired 640 An example usage in a SIP 424 response: 642 Geolocation-Error: 101; "node=bob.example.com"; 643 "inserter=alice.example.com"; 644 code="Coordinate-location Format Desired" 646 3.4.3 Geolocation-Error Code 102 Civic-location Format Desired 648 Geolocation-Error code 102 "Civic-location Format Desired" means the 649 location format supplied in the request (probably formatted in 650 coordinate), by-value or by-reference, was understood and supported, 651 but that the recipient, or an application on the recipient, can or 652 prefers to only process location in the civic-location format. 654 A typical reaction to receiving this code is to resend the 655 original message with location formatted in civic instead. 657 error-text-string: Civic-location Format Desired 659 An example usage in a SIP 424 response: 661 Geolocation-Error: 102; "node=bob.example.com"; 662 "inserter=alice.example.com"; 663 code="Civic-location Format Desired" 665 3.4.4 Geolocation-Error Code 103 Cannot Parse Location Supplied 667 Geolocation-Error code 103 "Cannot parse location supplied" means 668 the location provided, whether by-value or by-reference, in a 669 request is not well formed. 671 error-text-string: Cannot parse location supplied 673 An example usage in a SIP 424 response: 675 Geolocation-Error: 103; "node=bob.example.com"; 676 "inserter=alice.example.com"; 677 code="Cannot parse location supplied" 679 3.4.5 Geolocation-Error Code 104 Cannot Find Location Information 681 Geolocation-Error code 104 "Cannot find location" means location was 682 expected in the request, but the recipient cannot find it. 684 This can be either because the cid: pointed to a message body part 685 that is not present in the request, there was no location message 686 body part, or what is dereferenced at the supplied locationURI did 687 not return a PIDF-LO, or location is encrypted/opaque to the 688 recipient. 690 A typical reaction to receiving this code is for the location sender 691 to verify that it has indeed included location information in the 692 request in the properly indicated place and then to send the request 693 again. 695 error-text-string: Cannot find location 697 An example usage in a SIP 424 response: 699 Geolocation-Error: 104; "node=bob.example.com"; 700 "inserter=alice.example.com"; 701 code="Cannot find location" 703 3.4.6 Geolocation-Error Code 105 Conflicting Locations Supplied 705 Geolocation-Error code 105 "Conflicting Locations Supplied" means a 706 Location Recipient received more than one location describing where 707 the Target is, and is either unsure which whole location is true or 708 which parts of multiple locations make up where the Target is. 710 This is generally a case of either too much information, and the 711 information is pointing towards at least two different positions, 712 confusing the recipient. 714 A possible scenario exists in which at least two locations are in 715 the request, perhaps one or more were added by proxies along the 716 path of the request, each pointing to where the UAC is. If these 717 are pointing at different positions - the UAS does not know which to 718 trust. This error code unfortunately means the UAS cannot solve for 719 which location needs to be ignored to make up a complete location, 720 or how to prioritize one location over all others in the same 721 request. 723 A typical reaction to receiving this code is to reduce the number of 724 different locations supplied in the request, if under control by the 725 Target, and send another message to the Location Recipient. 727 error-text-string: Conflicting Locations Supplied 729 An example usage in a SIP 424 response: 731 Geolocation-Error: 105; "node=bob.example.com"; 732 "inserter=alice.example.com"; 733 code="Conflicting Locations Supplied" 735 3.4.7 Geolocation-Error Code 106 Incomplete Location Supplied 737 Geolocation-Error code 106 "Incomplete Location Supplied" means 738 there is not enough location information, by-value or retrieved 739 by-reference, to determine where the location Target is. 741 Perhaps the coordinate precision is not fine enough, or the civic 742 address lacks the fields to inform the UAS or proxy where the Target 743 is. This might be true for request retargeting, or it might be true 744 for first responder dispatch or pizza delivery (for example, because 745 the street address is missing). 747 A typical reaction to receiving this code is for the location sender 748 to convey more (precise) location information, if doing so is 749 allowed by local policy. 751 error-text-string: Incomplete location supplied 753 An example usage in a SIP 424 response: 755 Geolocation-Error: 106; "node=bob.example.com"; 756 "inserter=alice.example.com"; 757 code="Incomplete location supplied" 759 3.4.8 Geolocation-Error Code 107 Cannot Dereference 761 Geolocation-Error code 107 "Cannot dereference" means the act of 762 dereferencing failed to return the Target's location. This 763 generally means the supplied URI is bad. 765 error-text-string: Cannot dereference 767 An example usage in a SIP 424 response: 769 Geolocation-Error: 107; "node=bob.example.com"; 770 "inserter=alice.example.com"; 771 code="Cannot dereference" 773 3.4.9 Geolocation-Error Code 108 Dereference Denied 775 Geolocation-Error code 108 "Dereference Denied" means there was 776 insufficient authorization to dereference the Target's location. 778 error-text-string: Dereference Denied 780 An example usage in a SIP 424 response: 782 Geolocation-Error: 108; "node=bob.example.com"; 783 "inserter=alice.example.com"; 784 code="Dereference Denied" 786 3.4.10 Geolocation-Error Code 109 Dereference Timeout 788 Geolocation-Error code 109 "Dereference Timeout" means the 789 dereferencing node has not received the Target's location within a 790 reasonable timeframe. 792 error-text-string: Dereference Timeout 794 An example usage in a SIP 424 response: 796 Geolocation-Error: 109; "node=bob.example.com"; 797 "inserter=alice.example.com"; 798 code="Dereference Timeout" 800 3.4.11 Geolocation-Error Code 110 Cannot Process Dereference 802 Geolocation-Error code 110 "Cannot process Dereference" means the 803 dereference protocol has received an overload condition error, 804 indicating the location cannot be accessed at this time. 806 If a SIP or SIPS scheme were used to dereference the Target's 807 location, and a 503 (Service Unavailable) were the response to the 808 dereference query, this Geolocation-Error code 11 would be placed in 809 the 424 (Bad Location Information) response to the location sender. 811 error-text-string: Cannot process Dereference 813 An example usage in a SIP 424 response: 815 Geolocation-Error: 110; "node=bob.example.com"; 816 "inserter=alice.example.com"; 817 code="Cannot process Dereference" 819 3.4.12 Geolocation-Error Code 120 Unsupported Scheme - SIP desired 821 Geolocation-Error code 120 "Unsupported Scheme - SIP desired" means 822 the location dereferencer cannot dereference using the 823 location-by-reference URI scheme supplied because it does not 824 support the necessary protocol to do this. 826 This code means the Location Recipient can dereference the Target's 827 location using a SIP-URI scheme. There can be more than one 828 locationErrorValue in a Geolocation-Error header, indicating in this 829 context the recipient can dereference using each scheme protocol 830 included in the Geolocation-Error header. 832 Note that indicating SIP to be used to dereference location is 833 requesting the transmission to be in cleartext, which is a security 834 risk. Therefore, the SIP scheme SHOULD NOT be used to dereference. 835 An exception can be made for emergency calling, preferably after 836 SIPS has been attempted, and failed. 838 A typical reaction to receiving this code would be for the location 839 sender to send a URI with the sip scheme. 841 error-text-string: unsupported scheme - SIP desired 843 An example usage in a SIP 424 response: 845 Geolocation-Error: 120; "node=bob.example.com"; 846 "inserter=alice.example.com"; 847 code="unsupported scheme - SIP desired" 849 3.4.13 Geolocation-Error Code 121 Unsupported Scheme - SIPS desired 851 Geolocation-Error code 121 "Unsupported Scheme - SIPS desired" means 852 the location dereferencer cannot dereference using the 853 location-by-reference URI scheme supplied because it does not 854 support the necessary protocol to do this. 856 This code means the Location Recipient can dereference the Target's 857 location using a SIPS-URI scheme. There can be more than one 858 locationErrorValue in a Geolocation-Error header, indicating in this 859 context the recipient can dereference using each scheme protocol 860 included in the Geolocation-Error header. 862 error-text-string: unsupported scheme - SIPS desired 864 An example usage in a SIP 424 response: 866 Geolocation-Error: 121; "node=bob.example.com"; 867 "inserter=alice.example.com"; 868 code="unsupported scheme - SIPS desired" 870 3.4.14 Geolocation-Error Code 122 Unsupported Scheme - pres desired 872 Geolocation-Error code 122 "Unsupported Scheme - pres desired" means 873 the location dereferencer cannot dereference using the 874 location-by-reference URI scheme supplied because it does not 875 support the necessary protocol to do this. 877 This code means the Location Recipient can dereference the Target's 878 location using a PRES-URI scheme. There can be more than one 879 locationErrorValue in a Geolocation-Error header, indicating in this 880 context the recipient can dereference using each scheme protocol 881 included in the Geolocation-Error header. 883 error-text-string: unsupported scheme - pres desired 885 An example usage in a SIP 424 response: 887 Geolocation-Error: 122; "node=bob.example.com"; 888 "inserter=alice.example.com"; 889 code="unsupported scheme - pres desired" 891 3.5 The Geolocation Option Tag 893 This document creates and IANA registers one new option tag: 894 "geolocation". This option tag is to be used, per RFC 3261, in the 895 Require, Supported and Unsupported headers. Whenever a UA wants to 896 indicate support for this SIP extension, the geolocation option tag 897 is included in a Supported header of the SIP message. 899 Including the geolocation option-tag within an Unsupported header of 900 a 420 (Bad Extension) response is appropriate when a UAS 901 does not support this Geolocation extension. 903 A UAC adding this option-tag to a Require header field indicates to 904 a UAS the UAS MUST support this extension in order to continue 905 processing the message, or send a 420 response back to the UAC. 906 Some environments might use a Require header in this way, but it 907 should be used with caution to prevent unnecessary communications 908 problems. 910 A UAC SHOULD NOT include this option tag in a Proxy-Require header, 911 since a UAC is not likely to understand the topology of the 912 infrastructure, and therefore would not understand which proxy will 913 do the location-based routing function, if any. A potentially bad 914 scenario would have the first proxy not support this extension, but 915 a subsequent proxy does. This would result in no communications 916 past the first proxy, which MUST send the 420 back under these 917 circumstances. 919 3.6 Using sip/sips/pres as a Dereference Scheme 921 If a location-by-reference (LbyR) URI is included in a SIP request, 922 it MUST be in a locationValue in the Geolocation header and it MUST 923 be a SIP, SIPS or PRES-URI . When PRES: is used, if the resulting 924 resolution, per [RFC3856], resolves to a SIP: or SIPS: URI, this 925 section applies. Use of other protocols for dereferencing of a 926 PRES: URI is not defined, and such use is subject to review against 927 RFC 3693 Using Protocol criteria. 929 Dereferencing a Target's location using SIP or SIPS MUST be 930 accomplished by treating the URI as a presence URI and generating a 931 SUBSCRIBE request to a presence server as per [RFC3856] using the 932 'presence' event package. The resulting NOTIFY will contain a PIDF, 933 which MUST contain a PIDF-LO. See Figure 2. for a basic message flow 934 for a dereference. 936 When used in this manner, SIP is a Using Protocol per [RFC3693] and 937 elements receiving location MUST honor the 'usage-element' rules as 938 defined in this extension. 940 Alice Location Server Bob 941 | | 942 | INVITE w/ Location-by-Reference URI | 943 |-------------------------------------------------------->| 944 | | | 945 | 200 (OK) | 946 |<--------------------------------------------------------| 947 | | | 948 | | SUBSCRIBE to LbyR URI | 949 | |<-----------------------------| 950 | | 200 (OK) | 951 | |----------------------------->| 952 | | | 953 | | NOTIFY w/ PIDF-LO | 954 | |----------------------------->| 955 | | 200 (OK) | 956 | |<-----------------------------| 957 | | | 959 Figure 2. Location-by-Reference and Dereferencing 961 In Figure 2., Alice sends Bob her location in a LbyR URI. Bob 962 receives this LbyR URI in the INVITE and generates a new transaction 963 (SUBSCRIBE) to retrieve the PIDF-LO of Alice. If accepted, the 964 PIDF-LO will be in the NOTIFY request from the Location Server. 965 This is the first instance between Alice and Bob that Alice's 966 location is in any message, therefore it is sent only once, from the 967 Location Server to Bob. 969 A dereference of a location-by-reference URI using SUBSCRIBE is not 970 violating a PIDF-LO 'retransmission-allowed' element value set to 971 'no', as the NOTIFY is the only message in this multi-message set 972 of transactions that contains the Target's location, with the 973 location recipient being the only SIP element to receive location - 974 which is the purpose of this extension: to convey location to a 975 specific destination. 977 4. Geolocation Examples 979 This section contains are two examples of messages providing 980 location. One shows location-by-value with coordinates, the other 981 shows location-by-reference. The example for (Coordinate format) 982 is taken from [RFC3825]. A civic format example of the same position 983 on the earth as is in the coordinate format example is in appendix 984 B, which is taken from [RFC4776]. The differences between the two 985 formats are within the of the examples. Other 986 than this portion of each PIDF-LO, the rest is the same for both 987 location formats. 989 The key to the provided samples is in the Geolocation header, which 990 has a different type of URI, based on the different means of 991 location conveyance. Section 4.1 shows a "cid:" URI, indicating 992 this SIP request contains a location-by-value message body - which 993 is in the form of a PIDF-LO. Section 4.2 shows a 994 location-by-reference URI indicating location is to be acquired via 995 an indirection dereference mechanism, which is determined by the 996 scheme of URI supplied. 998 4.1 Location-by-value (Coordinate Format) 1000 This example shows an INVITE message with a coordinate, or 1001 coordinate location. In this example, the SIP request uses a 1002 sips-URI [RFC3261], meaning this message is TLS protected on a 1003 hop-by-hop basis all the way to Bob's domain. 1005 INVITE sips:bob@biloxi.example.com SIP/2.0 1006 Via: SIP/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bK74bf9 1007 Max-Forwards: 70 1008 To: Bob 1009 From: Alice ;tag=9fxced76sl 1010 Call-ID: 3848276298220188511@atlanta.example.com 1011 Geolocation: 1012 ;inserted-by=alice@atlanta.example.com ;recipient=endpoint 1013 Supported: geolocation 1014 Accept: application/sdp, application/pidf+xml 1015 CSeq: 31862 INVITE 1016 Contact: 1017 Content-Type: multipart/mixed; boundary=boundary1 1018 Content-Length: ... 1020 --boundary1 1022 Content-Type: application/sdp 1024 ...SDP goes here 1026 --boundary1 1028 Content-Type: application/pidf+xml 1029 Content-ID: alice123@atlanta.example.com 1031 1032 1036 1037 2007-12-02T14:00:00Z 1038 1039 1040 1041 1042 1043 33.001111 -96.68142 1044 1045 1046 1047 1048 no 1049 2007-12-07T18:00:00Z 1051 1052 DHCP 1053 www.example.com 1054 1055 1056 1057 1058 --boundary1-- 1060 The Geolocation header field from the above INVITE... 1062 Geolocation: 1064 ...indicates the content-ID location [RFC2392] within the multipart 1065 message body of where location information is, with SDP being the 1066 other message body part. 1068 If the Geolocation header field were this instead: 1070 Geolocation: 1072 ...this would indicate location by-reference was included in this 1073 message. It is expected that any node wanting to know where user 1074 target123 is would subscribe to server5 to dereference the sips-URI. 1075 The returning NOTIFY would contain Alice's location in a PIDF-LO, as 1076 if it were included in a message body (part) of the original INVITE 1077 here. 1079 4.2 Location-by-reference 1081 Below is an INVITE request with a location-by-reference URI instead 1082 of a location-by-value PIDF-LO message body part shown in Sections 1083 4.1. It is up to the location recipient to dereference Alice's 1084 location at the Atlanta server containing the location record. 1085 Dereferencing, if done with SIP, is accomplished by the Location 1086 Recipient sending a SUBSCRIBE request to the URI reference for 1087 Alice's location. The received NOTIFY is the first SIP message 1088 containing Alice's UA location, as a PIDF-LO message body. The 1089 NOTIFY, in this case, is the SIP request that is conveying location, 1090 and not the INVITE. There is no retransmission of location in this 1091 usage. 1093 INVITE sips:bob@biloxi.example.com SIP/2.0 1094 Via: SIP/2.0/TLS pc33.atlanta.example.com 1095 ;branch=z9hG4bK74bf9 1096 Max-Forwards: 70 1097 To: Bob 1098 From: Alice ;tag=9fxced76sl 1099 Call-ID: 3848276298220188511@atlanta.example.com 1100 Geolocation: 1101 ;inserted-by=bigbox3.atlanta.example.com ;recipient=both 1102 Supported: geolocation 1103 Accept: application/sdp, application/pidf+xml 1104 CSeq: 31862 INVITE 1105 Contact: 1107 ...SDP goes here as the only message body 1109 A Location Recipient would need to dereference the sips-URI in the 1110 Geolocation header field to retrieve Alice's location. If the 1111 atlanta.example.com domain chooses to implement location conveyance 1112 and delivery in this fashion (i.e., location-by-reference), it is 1113 RECOMMENDED that entities outside this domain be able to reach the 1114 dereference server, otherwise this model of implementation is 1115 only viable within the atlanta.example.com domain. 1117 5. SIP Element Behavior 1119 Because a device's location is generally considered to be sensitive 1120 in nature, privacy of the location information needs to be protected 1121 when transmitting such information. Section 26 of [RFC3261] defines 1122 the security functionality SIPS for transporting SIP messages with 1123 either TLS or IPSec, and S/MIME for encrypting message bodies from 1124 SIP intermediaries that would otherwise have access to reading the 1125 clear-text bodies. SIP endpoints SHOULD implement S/MIME to encrypt 1126 the PIDF-LO message body (part) end-to-end when the Location 1127 Recipient is intended to be another UA. The SIPS-URI from [RFC3261] 1128 MUST be implemented for message protection (message integrity and 1129 confidentiality) and SHOULD be used when S/MIME is not used. 1130 Possession of a dereferenceable location URI can be equivalent to 1131 possession of the location information itself and thus TLS SHOULD be 1132 used when transmitting location-by-reference hop-by-hop along the 1133 path to the Location Recipient. 1135 A PIDF includes identity information. It is possible for the 1136 identity in the PIDF to be anonymous. Implementations of this 1137 extension should consider the appropriateness of including an 1138 anonymous identity in the location information where a real identity 1139 is not required. When using location-by-reference, it is 1140 RECOMMENDED that the URI does not contain any user identifying 1141 information (for example use 3fg5t5yqw@example.com rather than 1142 alice@example.com). 1144 Location Recipients MUST obey the privacy and security rules in the 1145 PIDF-LO as described in RFC 4119 regarding retransmission and 1146 retention. 1148 Self-signed certificates SHOULD NOT be used for protecting a PIDF, 1149 as the sender does not have a secure identity of the recipient. 1151 More than one location format (civic and coordinate) MAY be included 1152 in the same message body part, but all location parts of the same 1153 PIDF-LO MUST point at the same position on the earth. The same 1154 location in multiple formats can allow the recipient to use the most 1155 convenient or preferable format for its use. Multiple PIDF-LOs are 1156 allowed in the same request, with each allowed to point at separate 1157 positions - because each PIDF-LO has a Target identifier in it. 1158 Therefore, there will be no confusion by a Location Recipient 1159 receiving more than one PIDF-LO (in a message body or when 1160 dereferenced, or a combination). 1162 It is RECOMMENDED there is only one "location" in a single SIP 1163 Request for a given Target. This means SIP servers SHOULD NOT add 1164 another locationValue to a SIP request that already contains 1165 location. This will likely lead to confusion at the ultimate 1166 location recipient because this extension does not provide guidance 1167 on what a recipient is to do with more than one location, nor does 1168 it give any preference regarding which location is better or worse 1169 than another location in the same request. 1171 It is allowed, but NOT RECOMMENDED, for more than one SIP element to 1172 insert location into a request along its path. As described earlier 1173 in this document, each insertion of location into a SIP request is 1174 accompanied by a locationValue in a Geolocation header. Also 1175 described earlier, each locationValue MUST contain an "inserted-by=" 1176 value indicated to a Location Recipient which host inserted location 1177 into a particular request. 1179 5.1 UAC Behavior 1181 A UAC can send location in a SIP request, because it is expected 1182 to facilitate location-based routing of the request, or 1183 spontaneously (i.e., a purpose not defined in this document but 1184 known to the UAC). 1186 A UAC conveying location MUST include a locationValue in a 1187 Geolocation header (see section 3.2) with either a location-by-value 1188 indication (a cid-URL), or a location-by-reference indication (a 1189 dereferenceable URI). A location-by-value message body sent without 1190 a Geolocation header field MUST NOT occur. The UAC supporting this 1191 extension MUST include a Supported header with the geolocation 1192 option tag. 1194 The geolocation option-tag is inserted in a Supported header by a 1195 UAC to provide an indication of support for this extension. The 1196 presence of the geolocation option tag in a Supported header without 1197 a Geolocation header field in the same message informs a receiving 1198 SIP element the UAC understands this extension, but it does not know 1199 or wish to convey its location at this time. Certain scenarios 1200 exist (location-based retargeting) in which location is required in 1201 a SIP request in order to retarget the message properly. This 1202 affects how a UAS or SIP server processes to such a request. 1204 The geolocation option tag SHOULD NOT be used in the Proxy-Require 1205 Header, because the UAC often will not know the underlying topology 1206 to know which proxy will do the retargeting, thus increasing the 1207 likelihood of a request failure by the first hop proxy that does not 1208 understand this extension, but is required to by inclusion of the 1209 option-tag in this header. 1211 A UAC inserting a locationValue MUST include an "inserted-by=" 1212 parameter to indicate its host-id. This is copied to the 1213 "inserter=" parameter of the Geolocation-Error header in a response 1214 if there is something wrong with the location in the original 1215 request. Because more than one locationValue can be inserted along 1216 the path of the request, this indication is necessary to show which 1217 locationValue had the problem in the response. For example: 1219 Geolocation: ; 1220 inserted-by=alice@atlanta.example.com 1222 The UAC MAY include an intended target of this location parameter by 1223 adding the "recipient=" parameter to the locationValue like this: 1225 Geolocation: ; 1226 inserted-by=alice@atlanta.example.com; 1227 recipient=endpoint 1229 See section 3.2 for further details about all the header parameters 1230 of a locationValue. 1232 A UAC MAY SUBSCRIBE to a LbyR URI, using the 'presence' event 1233 package, for its own location. The obvious reason for this is for 1234 the UAC to have its LbyV local to it. This document does not give a 1235 reason why a UAC would want to do this. 1237 5.1.1 UAC Receiving a Location Failure Indication 1239 If a sent request failed based on the location in the original 1240 request, a 424 (Bad Location Information) response is sent back to 1241 the UAC. The 424 MUST have a Geolocation-Error header containing 1242 one or more locationErrorValues in the response message. A 1243 locationErrorValue has a header parameter indicating which entity 1244 inserted the location pertaining to this error, called the 1245 "inserter=" parameter. This "inserter=" parameter is copied from 1246 the "inserted-by=" parameter of the locationValue by the UAS or 1247 proxy sending the error response. A UAC receiving this 424 should 1248 review this "inserter=" parameter in the locationErrorValue to see 1249 if it indicates this UAC. If locationErrorValue does not, the 1250 locationErrorValue should be ignored, and the response SHOULD be 1251 treated as a 4XX response. If locationErrorValue does indicate this 1252 UAC, this UAC MUST process the response, including the 1253 Geolocation-Error code (defined in section 3.4). 1255 In addition to the error code, there MAY be a list of CAtypes in the 1256 locationErrorValue. If there are any, these are what the UAS or 1257 proxy determined was wrong with the location contained in the 1258 original response. The listed CAtypes will not contain the values 1259 sent by the UAC in the request. This is for security/privacy 1260 reasons. 1262 The UAC SHOULD take correct steps to rectify future errors, based on 1263 the received error code and any CAtypes listed, to increase the 1264 probability of successful requests in the future. A UAC MAY 1265 reattempt a new request if it believes it can correct the stated 1266 failure in the Geolocation-Error header. 1268 Any UAC that inserted location into a request should be prepared to 1269 receive the Geolocation-Error header in any response, looking to 1270 determine if the header is meant for the UAC, and to react 1271 accordingly. 1273 If a UAC includes location in a request, and either the UAS does not 1274 determine errored location was critical to the transaction and 1275 accept the request, or the request failed for another reason than 1276 location, any response MAY contain a Geolocation-Error header 1277 containing a locationErrorValue with the details of the location 1278 error. 1280 5.2 UAS Behavior 1282 If the Geolocation header field is present in a received SIP 1283 request, the type of URI contained in the locationValue will 1284 indicate if location has been conveyed by-value in a message body 1285 (part) or by-reference, requiring an additional dereference 1286 transaction. If the by-reference URI is sip:, sips: or pres:, the 1287 UAS MUST initiate a SUBSCRIBE to the URI provided to retrieve the 1288 PIDF-LO being conveyed by the UAC per [RFC3856]. If successful, the 1289 PIDF-LO will be returned in the NOTIFY request from the remote host. 1291 A Require header with the geolocation option tag indicates the 1292 UAC is requiring the UAS understand this extension or else send 1293 an error response. A 420 (Bad Extension) with a geolocation option 1294 tag in an Unsupported header would be the appropriate response in 1295 this case. 1297 It is possible, but undesirable, for a message to arrive with a body 1298 containing a location-by-value, but with no Geolocation header field 1299 value pointing to it (potentially no Geolocation header field at 1300 all). In this case, the recipient MAY still read and use the message 1301 body. Unless stated otherwise by future standards-track 1302 publications, a Location-by-reference URI only has meaning within 1303 the Geolocation header field and MUST NOT appear in any other SIP 1304 header field. 1306 There are 3 Geolocation header parameters, 1308 o "inserted-by=" 1309 o "used-for-routing" 1310 o "recipient=" 1312 The "inserted-by=" parameter informs a Location Recipient which SIP 1313 element added this locationValue to the SIP request. This parameter 1314 is mandatory for each locationValue in the request. The value in 1315 the "inserted-by=" parameter is copied into the "inserter=" 1316 parameter in each locationErrorValue if there is an error in the 1317 location to be reported back to the location sender. See section 1318 5.2.1. 1320 The "used-for-routing" parameter is included in the locationValue if 1321 a SIP server used the location in the request to determine how to 1322 route or forward the message towards the ultimate destination. If 1323 there are more than one locationValue in the Geolocation header, and 1324 it is possible that different locationValues were used to route the 1325 message at different times of this request's journey. This is 1326 allowed, as it is consistent with the rule that anytime a message is 1327 routed based upon a locationValue, a "used-for-routing" parameter is 1328 added to the applicable locationValue. This parameter should be 1329 present in each locationValue used along the path. 1331 More than one locationValue inserted in a request should be placed 1332 the order it was placed, and not rearranged. This informs a 1333 Location Recipient which was the last locationValue in the message 1334 that was used to route the message. This is for troubleshooting and 1335 management reasons. 1337 The "recipient=" header parameter allow recipients to infer the SIP 1338 entity type this locationValue is intended to be for. The types are 1339 "endpoint", meaning the ultimate destination UAS; "routing-entity", 1340 meaning SIP servers; and "both" meaning this locationValue is to be 1341 viewed by both types of SIP entities. 1343 Individual header parameters in any received locationValue MUST NOT 1344 be modified or deleted in transit to the ultimate destination. 1346 A UAS MUST NOT send location in a response message, as there can be 1347 any number of issues/problems with receiving location, and the UAC 1348 or proxy servers cannot error a response. Therefore, the UAS, if it 1349 wants to send a UAC its location, SHOULD do so in a new request in a 1350 separate transaction. This document gives no guidance which SIP 1351 request to use. 1353 A UAS MAY include a geolocation option-tag in the Supported header 1354 of a response, indicating it does understand this extension, even if 1355 location was not in a request to the UAS. 1357 A UAS wishing to dereference a location-by-reference URI contained 1358 in a received request will use the 'presence' event package in a 1359 SUBSCRIBE request to the URI. If accepted, the PIDF-LO will return 1360 to the UAS in a NOTIFY request. If there are any errors during 1361 dereferencing, or in the PIDF-LO itself, the UAS will error the 1362 original request to the UAC with a locationErrorValue indicating 1363 what the UAS concluded was wrong with the location. This is to 1364 include any dereferencing problems encountered. 1366 5.2.1 UAS Generating a Location Failure Indication 1368 If a received request conveys location, but the UAS has one or 1369 more problems with a locationValue in the request (to include while 1370 attempting to dereference the UAC's location), the UAS MUST indicate 1371 each problem experienced with the location in the request in a 1372 424 (Bad Location Information) response back to the inserting 1373 entity if the UAS wants to reject the request because of the 1374 location. A Geolocation-Error header is how the UAS informs the UAC 1375 of a location-based error within the request. Section 3.4 lists 1376 these errors, which are all IANA registered. 1378 Because this extension to SIP allows more than one locationValue in 1379 a Geolocation header, each from separate SIP entities, there 1380 needs to be a means of identifying which entity inserted a 1381 particular locationValue for single error response purposes. This 1382 is further complicated because SIP sends a single rejection 1383 response, that in this case, needs to go to more than one entity, 1384 and be ignored by all other entities not identified in such a way as 1385 to not confuse other SIP entities. 1387 Each locationValue has an "inserted-by=" parameter identifying which 1388 SIP entity added this locationValue to the request. This value is 1389 copied to the locationErrorValue "inserter=" parameter if one needs 1390 to be sent, thus identifying the intended target of this 1391 locationErrorValue. This locationErrorValue is ignored by all other 1392 receivers of this SIP response. 1394 Each locationErrorValue can have more than one error code within it. 1395 Each locationErrorValue is destined for one "inserter=" entity. 1396 This gives a UAS one mechanism to tell each inserter what the 1397 Location Recipient concluded was wrong with what the inserter 1398 included (as far as location is concerned). Therefore, 1400 o there MUST be a locationErrorValue for each locationValue that 1401 was considered bad by the UAS to ensure each upstream location 1402 inserter understands which error code(s)is intended for them (and 1403 which to ignore). 1405 o if the PIDF-LO (received by-value or after dereference) contains 1406 civic CAtypes that the Location Recipient considers malformed or 1407 bad, each CAtype SHOULD be listed in the locationErrorValue to 1408 inform the "inserter=" entity what specifically was wrong with 1409 the locationValue, in addition to the error code. Without these 1410 details, the location inserter might not know what part was 1411 malformed or incomplete about the information supplied in the 1412 request. 1414 o the CAtype values MUST NOT be sent along with the CAtype names 1415 listed in the locationErrorValue. This is for privacy/security 1416 reasons. 1418 o there MUST NOT be more than one locationErrorValue in the 1419 response per locationValue in the request. 1421 o there MUST NOT be more than one locationErrorValue in the 1422 response for the same locationValue in the request. 1424 o there MUST NOT be a locationErrorValue in the response for a 1425 locationValue in the request that was not in error, according to 1426 the Location Recipient. 1428 Here is an example of a Geolocation-Error header 1430 Geolocation-Error: 106; "node=bob.example.com"; 1431 "inserter=alice.example.com"; 1432 CAtype=A3; CAtype=STS; 1433 code="incomplete location supplied" 1435 See Section 3.4 for further rules about the Geolocation-Error header 1436 and the locationErrorValue. 1438 The Geolocation-Error header is permitted in any response. For 1439 example, Bob can reply to Alice with a 486 because he's not willing 1440 to accept the call at this time, and inform Alice that the location 1441 contained in the request was bad in some way. In this case, the 486 1442 would contain a Geolocation-Error header indicating the specific 1443 location error experienced 1445 If there is more than one locationValue in a request, and any one of 1446 them is valid (i.e., one contains enough information to not generate 1447 a 424 if that was the only location present in the request), all 1448 other locations MAY be ignored, and a 424 MUST NOT be sent because 1449 of these other locations in the request. Another response MAY be 1450 sent, which includes a locationErrorValue. This document says 1451 nothing about what a Location Recipient does with more than one 1452 'good' location in a request (i.e., which to choose to use). 1454 Further, more than one error code is allowed in the 1455 locationErrorValue - each having an "inserter=" parameter. The 1456 error codes destined for the same inserter MUST NOT contradict the 1457 meaning of the problem the UAS had with a particular locationValue. 1459 A Geolocation-Error is permissible in a 200 OK response. This means 1460 everything else in the request was acceptable, but the location was 1461 not for a given error code(s). One exception to this set of rules 1462 is if a geolocation option-tag was in the Require header in the 1463 request. This would necessitate a 424 response. 1465 5.3 Proxy Behavior 1467 [RFC3261] states message bodies cannot be added by proxies. 1468 However, proxies are permitted to add a header to a request. This 1469 implies that a proxy can add a Geolocation locationValue with 1470 location-by-reference URI, but not location-by-value message body. 1471 However, if location is already in a SIP request, a SIP server 1472 SHOULD NOT add another instance of the UAC's location to the same 1473 request. This will likely cause confusion at the Location Recipient 1474 as to which to use. This document gives no guidance how a UAS is to 1475 deal with more than one location in a SIP request, other than the 1476 intended "recipient=" parameter, which has no integrity protection 1477 in transit. If more than one locationValue states 1478 "recipient=endpoint", this document gives no guidance what the UAS 1479 is to do. 1481 A proxy is permitted to read any locationValue, and the associated 1482 body, if not S/MIME protected, in transit if present, and MUST use 1483 the contents of the header field to make location-based retargeting 1484 decisions, if retargeting requests based on location is a function 1485 of that proxy. 1487 More than one Geolocation locationValue in a message is permitted, 1488 but can cause confusion at the recipient. If a proxy chooses to add 1489 a locationValue to a Geolocation header, which would be a local 1490 policy decision, the new locationValue MUST be added to the end of 1491 the header (after previous locationValue(s)). This is done to 1492 create an order of insertion of locationValues along the path. 1493 Proxies MUST NOT modify the order of locationValues in a geolocation 1494 header. 1496 A proxy wishing to dereference a location-by-reference URI contained 1497 in a received request will use the 'presence' event package in a 1498 SUBSCRIBE request to the URI. If accepted, the PIDF-LO will return 1499 to the proxy in a NOTIFY request. If there are any errors during 1500 dereferencing, or in the PIDF-LO itself, the proxy will error the 1501 original request to the UAC with a locationErrorValue indicating 1502 what the proxy concluded was wrong with the location. This is to 1503 include any dereferencing problems encountered. 1505 5.3.1 Proxy Behavior with Geolocation Header Parameters 1507 SIP servers MUST NOT delete any existing Geolocation locationValue 1508 (URI or header parameter) from a request. A Geolocation 1509 locationValue (URI or header parameter) MAY only be modified to by 1510 adding a "used-for-routing" parameter to an existing locationValue, 1511 if the request was retargeted based on the location within that 1512 locationValue. Further modification of this Geolocation header 1513 field MUST NOT occur. For example, an existing Geolocation 1514 locationValue in a request of: 1516 Geolocation: ; 1517 inserted-by=alice123@atlanta.example.com; 1519 can be modified by a proxy to add the "used-for-routing" parameter, 1520 like this: 1522 Geolocation: ; 1523 inserted-by=alice123@atlanta.example.com; 1524 used-for-routing 1526 if this is the locationValue the proxy used to make a retargeting 1527 decision based upon, but make no other modification. 1529 A SIP server MAY add a new Geolocation locationValue to a SIP 1530 request. The proxy SHOULD NOT insert a locationValue of the UAC 1531 unless it is reasonably certain it knows the actual location of the 1532 endpoint, for example, if it thoroughly understands the topology of 1533 the underlying access network and it can identify the device 1534 reliably (in the presence of, for example, NAT). 1536 A server adding a locationValue to an existing Geolocation header 1537 would look like: 1539 Geolocation: ; 1540 inserted-by=alice123@atlanta.example.com, 1541 ; 1542 inserted-by=lis1.atlanta.example.com; 1544 Notice the locationValue added by the proxy is last among 1545 locationValues. This practice MUST be done for all added 1546 locationValues. 1548 If this request was then retargeted by an intermediary using the 1549 locationValue inserted by the server, the intermediary would add a 1550 "used-for-routing" parameter like this: 1552 Geolocation: ; 1553 inserted-by=alice123@atlanta.example.com, 1554 ; 1555 inserted-by=lis1.atlanta.example.com; used-for-routing 1557 It is conceivable that an initial routing decision is made on an 1558 one locationValue, and subsequently another routing decision is 1559 made on a different locationValue. This retargeting decision can be 1560 made on a newly inserted locationValue. While unusual, it can 1561 occur. In such a case, proxies MUST NOT remove any existing 1562 "used-for-routing" header parameter. In this instance, the SIP 1563 server retargeting based on another locationValue MUST add the 1564 "used-for-routing" header parameter to the locationValue used for 1565 retargeting by this server. This will result in a Geolocation 1566 header looking as if it were retargeting more than once, which would 1567 be true - and is the desired outcome. 1569 5.3.2 Proxy Error Behavior for Sending or Receiving locationErrorValues 1571 For proxies that receive a SIP request that contains a location 1572 error, either in a contained message body or after the proxy does a 1573 dereference of the LbyR URI, all the rules applicable to a UAS apply 1574 here (see Section 5.2.1.), since in this case, the proxy is 1575 considered a Location Recipient. Therefore, there is no reason to 1576 restate them here, and potentially have the two section be 1577 inconsistent. The one thing to add is that a proxy does not need to 1578 examine location contained in a request. Section 5.2.1. only applies 1579 to proxies that are monitoring or policing location within requests 1580 (for whatever reason). 1582 If a proxy inserted a locationValue into a request, it SHOULD be 1583 ready to examine the response to that request, in case there is one 1584 or more location errors in the response. To a great degree, this 1585 scenario has the proxy behaving as a UAC (see section 5.1.1.) that 1586 included a locationValue a request, which then receives an error to 1587 that locationValue. 1589 If there is one or more locationErrorValues in the response, the 1590 proxy SHOULD examine each "inserter=" parameter in each 1591 locationErrorValue - looking for one that identifies the proxy. If 1592 one matches the proxy's "inserted-by" value, that locationErrorValue 1593 is for only that proxy. This locationErrorValue needs to be reviewed 1594 for each error code and CAtype contained in the value. The proxy 1595 SHOULD attempt to correct for the error reported to it for future 1596 insertion of location into requests. This document gives no 1597 guidance what the proxy should do to rectify the bad location 1598 information, but a future document MAY address this. 1600 6. Geopriv Privacy Considerations 1602 Transmitting location information is considered by most to be highly 1603 sensitive information, requiring protection from eavesdropping, 1604 tracking, and altering in transit. [RFC3693] articulates rules to 1605 be followed by any protocol wishing to be considered a Geopriv 1606 "Using Protocol", specifying how a transport protocol meetings 1607 those rules. This section describes how SIP as a Using Protocol 1608 meets those requirements. 1610 Quoting requirement #4 of [RFC3693]: 1612 "The Using Protocol has to obey the privacy and security 1613 instructions coded in the Location Object and in the 1614 corresponding Rules regarding the transmission and storage 1615 of the LO." 1617 This document requires that SIP entities sending or receiving 1618 location MUST obey such instructions. 1620 Quoting requirement #5 of [RFC3693]: 1622 "The Using Protocol will typically facilitate that the keys 1623 associated with the credentials are transported to the 1624 respective parties, that is, key establishment is the 1625 responsibility of the Using Protocol." 1627 [RFC3261] and the documents it references define the key 1628 establishment mechanisms. 1630 Quoting requirement #6 of [RFC3693]: 1632 "(Single Message Transfer) In particular, for tracking of 1633 small Target devices, the design should allow a single 1634 message/packet transmission of location as a complete 1635 transaction." 1637 When used for tracking, a simple NOTIFY or UPDATE normally is 1638 relatively small, although the PIDF itself can get large. Normal 1639 RFC 3261 procedures of reverting to TCP when the MTU size is 1640 exceeded would be invoked. 1642 7. Security Considerations 1644 Conveyance of physical location of a UAC raises privacy concerns, 1645 and depending on use, there probably will be authentication and 1646 integrity concerns. This document calls for conveyance to normally 1647 be accomplished through secure mechanisms, like S/MIME protecting 1648 message bodies (but this is not widely deployed) or TLS protecting 1649 the overall signaling. In cases where a session set-up is 1650 retargeted based on the location of the UAC initiating the call or 1651 SIP MESSAGE, securing the by-value location with an end-to-end 1652 mechanism such as S/MIME is problematic, because one or more proxies 1653 on the path need the ability to read the location information to 1654 retarget the message to the appropriate new destination UAS. 1655 Securing the location hop-by-hop, using TLS, protects the message 1656 from eavesdropping and modification, but exposes the information to 1657 all proxies on the path as well as the endpoint. In most cases, the 1658 UAC does not know the identity of the proxy or proxies providing 1659 location-based routing services, so that end-to-middle solutions 1660 might not be appropriate either. 1662 These same issues exist for basic SIP signaling, but SIP normally 1663 does not carry information to physically track a user; making this 1664 extension especially sensitive. 1666 When location is inserted by a UAC, which is RECOMMENDED, it can 1667 decide whether to reveal its location using hop-by-hop methods. UAC 1668 implementations MUST make such capabilities conditional on explicit 1669 user permission, and SHOULD alert a user that location is being 1670 conveyed. Proxies inserting location for location-based routing are 1671 unable to meet this requirement, and such use is NOT RECOMMENDED. 1672 Proxies conveying location using this extension MUST have the 1673 permission of the Target to do so. 1675 One facet within this extension is such that locations can be placed 1676 on a remote server, accessible with the possession of a URI. The 1677 concept of a location-by-reference URI has its own security 1678 considerations. It is tempting to assume that the dereference would 1679 have authentication, authorization and other security mechanisms 1680 that limit the access to information. Unfortunately, this might not 1681 be true. The access network the UAC is connected to can be the 1682 source of location reference, and it might not have any 1683 credentialing mechanism suitable for controlling access to location. 1684 Consider, specifically, a nomadic user connected to an access 1685 network in a hotel. The UAC has no way to provide a credential 1686 acceptable to the hotel Location Server (LS) to any of its intended 1687 Location Recipients. The recipient of a reference does not know if 1688 a reference has appropriate authorization policies or not. The LS 1689 should provide location to any requestor. 1691 Accordingly, possession of the reference should be considered 1692 equivalent to possession of the value, and the reference should be 1693 treated with the same degree of care as the value. Specifically, 1694 TLS MUST be used to protect the security of the reference. Notice 1695 that this does not constrain the dereference protocol to use TLS. 1696 That specification is left entirely to the dereferencing protocol 1698 Because SIP servers can add location in transit, made more easy of 1699 the server is a Session Border Controller or B2BUA, this might cause 1700 there to be conflicting location information (error-code=6), which 1701 could be purposeful to error the request or just cause operation 1702 problems. This problem might be inadvertent, compounded by the fact 1703 that there will likely be some SIP servers that add location on 1704 every call set-up. 1706 There is no integrity on any locationValue or locationErrorValue 1707 header parameter, so recipients of either header need to implicitly 1708 trust the header contents, and take whatever precautions each entity 1709 deems appropriate give these facts. 1711 8. IANA Considerations 1713 The following are the IANA considerations made by this SIP 1714 extension. Modifications and additions to these registrations 1715 require a standards track RFC (Standards Action). 1717 8.1 IANA Registration for the SIP Geolocation Header 1719 The SIP Geolocation header is created by this document, with its 1720 definition and rules in Section 3.2 of this document, to be added to 1721 the sip-parameters. 1723 The Geolocation Header has the following header parameters to be 1724 Registered in a new table: 1726 Geolocation Header parameters 1728 Header Parameters Parameter-values Reference 1729 ---------------- ---------------- -------------- 1730 recipient endpoint RFC XXXX (this document) 1731 recipient routing-entity RFC XXXX (this document) 1732 recipient both RFC XXXX (this document) 1734 8.2 IANA Registration for New SIP Option Tag 1736 The SIP option-tag "geolocation" is created by this document, with 1737 the definition and rule in Section 3.5 of this document, to be added 1738 to sip-parameters within IANA. 1740 8.3 IANA Registration for Response Code 424 1742 Reference: RFC-XXXX (i.e., this document) 1743 Response code: 424 (recommended number to assign) 1744 Default reason phrase: Bad Location Information 1746 This SIP Response code is defined in section 3.3 of this document. 1748 8.4 IANA Registration of New Geolocation-Error Header 1750 The SIP Geolocation-error header is created by this document, with 1751 its definition and rules in Section 3.4 of this document, to be 1752 added to the sip-parameters. 1754 8.5 IANA Registration for the SIP Geolocation-Error Codes 1756 New location specific Geolocation-Error codes are created by this 1757 document, and registered in a new table at sip-parameters within 1758 IANA. Details of these error codes are in Section 3.4 of this 1759 document. 1761 Geolocation-Error codes 1762 ----------------------- 1763 Geolocation-Error codes provide reason for the error discovered by 1764 Location Recipients, to place into SIP response messages to inform 1765 the location inserter of the error. 1767 Code Description Reference 1768 ---- --------------------------------------------------- --------- 1769 100 Location Format Not Supported: the location format [this doc] 1770 supplied in the request, by-value or by-reference, 1771 was not supported. 1773 101 Coordinate-location Format Desired: the location [this doc] 1774 format supplied in the request was understood 1775 and supported, but that the recipient, or an 1776 application on the recipient, can or prefers to 1777 only process location in the coordinate-location 1778 format. 1780 102 Civic-location Format Desired: the location [this doc] 1781 format supplied in the request was understood 1782 and supported, but that the recipient, or an 1783 application on the recipient, can or prefers to 1784 only process location in the civic-location 1785 format. 1787 103 Cannot Parse Location Supplied: the location [this doc] 1788 provided, whether by-value or by-reference, in a 1789 request is not well formed. 1791 104 Cannot Find Location: the location was expected in [this doc] 1792 the request, but the recipient cannot find it. 1794 105 Conflicting Locations Supplied: a Location Recipient [this doc] 1795 received more than one location describing where the 1796 Target is, and is either unsure which whole location 1797 is true or which parts of multiple locations make up 1798 where the Target is. 1800 106 Incomplete Location Supplied: there is not enough [this doc] 1801 location information in the request to determine 1802 where the location Target is. 1804 107 Cannot Dereference: the act of dereferencing failed [this doc] 1805 to return the Target's location. This generally 1806 means the supplied URI is bad. 1808 108 Dereference Denied: there was insufficient [this doc] 1809 authorization to dereference the Target's location. 1811 109 Dereference Timeout: the dereferencing node has not [this doc] 1812 received the Target's location within a reasonable. 1813 timeframe 1815 110 Cannot Process Dereference: the dereference protocol [this doc] 1816 has received an overload condition error, indicating 1817 the location cannot be accessed at this time. 1819 120 Unsupported Scheme - sip desired: the location [this doc] 1820 dereferencer cannot dereference using the 1821 location-by-reference URI scheme supplied, and 1822 prefers a sip-uri. 1824 121 Unsupported Scheme - sips desired: the location [this doc] 1825 dereferencer cannot dereference using the 1826 location-by-reference URI scheme supplied, and 1827 prefers a sips-uri. 1829 122 Unsupported Scheme - pres desired: the location [this doc] 1830 dereferencer cannot dereference using the 1831 location-by-reference URI scheme supplied, and 1832 prefers a pres-uri. 1834 9. Acknowledgements 1836 To Dave Oran for helping to shape this idea. To Jon Peterson and 1837 Dean Willis on guidance of the effort. To Allison Mankin, Dick 1838 Knight, Hannes Tschofenig, Henning Schulzrinne, James Winterbottom, 1839 Jeroen van Bemmel, Jean-Francois Mule, Jonathan Rosenberg, Keith 1840 Drage, Marc Linsner, Martin Thomson, Mike Hammer, Paul Kyzivat, 1841 Shida Shubert, Umesh Sharma, Richard Barnes, Ted Hardie and Matt 1842 Lepinski for constructive feedback. A special thanks to Dan Wing 1843 for help with the S/MIME example, and to Robert Sparks for many 1844 helpful comments and the proper building of the Geolocation-Error 1845 header. 1847 10. References 1849 10.1 References - Normative 1851 [RFC3261] J. Rosenberg, H. Schulzrinne, G. Camarillo, A. Johnston, J. 1852 Peterson, R. Sparks, M. Handley, and E. Schooler, "SIP: 1853 Session Initiation Protocol", RFC 3261, May 2002. 1855 [RFC4119] J. Peterson, "A Presence-based GEOPRIV Location Object 1856 Format", RFC 4119, December 2005 1858 [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate 1859 Requirement Levels", RFC 2119, March 1997 1861 [RFC2392] E. Levinson, " Content-ID and Message-ID Uniform Resource 1862 Locators", RFC 2393, August 1998 1864 [RFC3863] H. Sugano, S. Fujimoto, G. Klyne, A. Bateman, W. Carr, J. 1865 Peterson, "Presence Information Data Format (PIDF)", RFC 1866 3863, August 2004 1868 [RFC3856] J. Rosenberg, " A Presence Event Package for the Session 1869 Initiation Protocol (SIP)", RFC 3856, August 2004 1871 [RFC3859] J. Peterson, "Common Profile for Presence (CPP)", RFC 3859, 1872 August 2004 1874 [RFC3428] B. Campbell, Ed., J. Rosenberg, H. Schulzrinne, C. Huitema, 1875 D. Gurle, "Session Initiation Protocol (SIP) Extension for 1876 Instant Messaging" , RFC 3428, December 2002 1878 [RFC3311] J. Rosenberg, "The Session Initiation Protocol (SIP) UPDATE 1879 Method", RFC 3311, October 2002 1881 [RFC3265] Roach, A., "Session Initiation Protocol (SIP)-Specific 1882 Event Notification", RFC 3265, June 2002. 1884 [RFC3262] Rosenberg, J. and H. Schulzrinne, "Reliability of 1885 Provisional Responses in Session Initiation Protocol (SIP)", 1886 RFC 3262, June 2002. 1888 [IANA-civic] http://www.iana.org/assignments/civic-address-types- 1889 registry 1891 10.2 References - Informative 1893 [RFC3693] J. Cuellar, J. Morris, D. Mulligan, J. Peterson. J. Polk, 1894 "Geopriv Requirements", RFC 3693, February 2004 1896 [RFC3825] J. Polk, J. Schnizlein, M. Linsner, "Dynamic Host 1897 Configuration Protocol Option for Coordinate-based Location 1898 Configuration Information", RFC 3825, July 2004 1900 [RFC4776] H. Schulzrinne, " Dynamic Host Configuration Protocol 1901 (DHCPv4 and DHCPv6) Option for Civic Addresses Configuration 1902 Information ", draft-ietf-geopriv-dhcp-civil-09, "work in 1903 progress", January 2006 1905 Author Information 1907 James Polk 1908 Cisco Systems 1909 3913 Treemont Circle 33.00111N 1910 Colleyville, Texas 76034 96.68142W 1912 Phone: +1-817-271-3552 1913 Email: jmpolk@cisco.com 1915 Brian Rosen 1916 NeuStar, Inc. 1917 470 Conrad Dr. 40.70497N 1918 Mars, PA 16046 80.01252W 1919 US 1921 Phone: +1 724 382 1051 1922 Email: br@brianrosen.net 1924 Appendix A. Requirements for SIP Location Conveyance 1926 The following subsections address the requirements placed on the 1927 UAC, the UAS, as well as SIP proxies when conveying location. There 1928 is a motivational statement below each requirements that is not 1929 obvious in intent 1931 A.1 Requirements for a UAC Conveying Location 1933 UAC-1 The SIP INVITE Method [RFC3261] must support location 1934 conveyance. 1936 UAC-2 The SIP MESSAGE method [RFC3428] must support location 1937 conveyance. 1939 UAC-3 SIP Requests within a dialog should support location 1940 conveyance. 1942 UAC-4 Other SIP Requests may support location conveyance. 1944 UAC-5 There must be one, mandatory to implement means of 1945 transmitting location confidentially. 1947 Motivation: interoperability 1949 UAC-6 It must be possible for a UAC to update location conveyed 1950 at any time in a dialog, including during dialog 1951 establishment. 1953 Motivation: in case a UAC has moved prior to the establishment of a 1954 dialog between UAs, the UAC must be able to send new location 1955 information. In the case of location having been conveyed, 1956 and the UA moves, it needs a means to update the conveyed to 1957 party of this location change. 1959 UAC-7 The privacy and security rules established within [RFC3693] 1960 that would categorize SIP as a 'Using Protocol' must be met. 1962 UAC-8 The PIDF-LO [RFC 4119] is a mandatory to implement format for 1963 location conveyance within SIP, whether included by-value or 1964 by-reference. 1966 Motivation: interoperability with other IETF location protocols and 1967 mechanisms 1969 UAC-9 There must be a mechanism for the UAC to request the UAS send 1970 its location 1972 UAC-9 has been DEPRECATED by the SIP WG, due to the many 1973 problems this requirement would have caused if implemented. 1974 The solution is for the above UAS to send a new request to 1975 the original UAC with the UAS's location. 1977 UAC-10 There must be a mechanism to differentiate the ability of the 1978 UAC to convey location from the UACs lack of knowledge of its 1979 location 1981 Motivation: Failure to receive location when it is expected can be 1982 because the UAC does not implement this extension, or it can 1983 be that the UAC implements the extension, but does not know 1984 where it is. This may be, for example, due to the failure of 1985 the access network to provide a location acquisition 1986 mechanisms the UAC understands. These cases must be 1987 differentiated. 1989 UAC-11 It must be possible to convey location to proxy servers 1990 along the path. 1992 Motivation: Location-based routing. 1994 A.2 Requirements for a UAS Receiving Location 1996 The following are the requirements for location conveyance by a UAS: 1998 UAS-1 SIP Responses must support location conveyance. 2000 Just as with UAC-9, UAS-1 has been DEPRECATED by the SIP WG, 2001 due to the many problems this requirement would have caused 2002 if implemented. The solution is for the above UAS to send a 2003 new request to the original UAC with the UAS's location. 2005 UAS-2 There must be a unique 4XX response informing the UAC it did 2006 not provide applicable location information. 2008 In addition, requirements UAC-5, 6, 7 and 8 apply to the UAS 2010 A.3 Requirements for SIP Proxies and Intermediaries 2012 The following are the requirements for location conveyance by a SIP 2013 proxies and intermediaries: 2015 Proxy-1 Proxy servers must be capable of adding a Location header 2016 field during processing of SIP requests. 2018 Motivation: Provide the capability of network assertion of location 2019 when UACs are unable to do so, or when network assertion is 2020 more reliable than UAC assertion of location 2022 Note: Because UACs connected to sip signaling networks may have 2023 widely varying access network arrangements, including VPN 2024 tunnels and roaming mechanisms, it may be difficult for a 2025 network to reliably know the location of the endpoint. Proxy 2026 assertion of location is NOT RECOMMENDED unless the sip 2027 signaling network has reliable knowledge of the actual 2028 location of the Targets. 2030 Proxy-2 There must be a unique 4XX response informing the UAC it 2031 did not provide applicable location information. 2033 Appendix B. Example of INVITE with S/MIME encrypted Civic PIDF-LO 2035 This appendix gives an *EXAMPLE* (meaning this might contain errors 2036 based on future review) of a SIP INVITE request that points to the 2037 same position on the earth as the coordinate based example that's in 2038 section 4.1 in the body of this document: 2040 The INVITE request is TLS hop-by-hop encrypted, and the 2041 location-by-value message body is S/MIME encrypted. This example 2042 shows the location message body in its unencrypted form for clarity. 2043 The message body lines below that have the '$' signs are S/MIME 2044 encrypted. In this example, the SDP is not S/MIME encrypted. 2046 INVITE sips:bob@biloxi.example.com SIP/2.0 2047 Via: SIP/2.0/TLS pc33.atlanta.example.com 2048 ;branch=z9hG4bK74bf9 2049 Max-Forwards: 70 2050 To: Bob 2051 From: Alice ;tag=9fxced76sl 2052 Call-ID: 3848276298220188511@atlanta.example.com 2053 Geolocation: 2054 ;inserted-by=alice@atlanta.example.com ;recipient=endpoint 2055 Supported: geolocation 2056 Accept: application/sdp, application/pidf+xml 2057 CSeq: 31862 INVITE 2058 Contact: 2059 Content-Type: multipart/mixed; boundary=boundary1 2060 Content-Length: ... 2062 --boundary1 2064 Content-Type: application/sdp 2066 ...SDP goes here 2068 --boundary1 2070 Content-Type: application/pkcs7-mime; 2071 smime-type=enveloped-data; name=smime.p7m 2072 Content-ID: alice123@atlanta.example.com 2074 $ Content-Type: application/pidf+xml 2075 $ 2076 $ 2077 $ 2081 $ 2082 $ 2007-07-09T14:00:00Z 2083 $ 2084 $ 2085 $ 2086 $ 2087 $ US 2088 $ Texas 2089 $ Colleyville 2090 $ 3913 2091 $ Treemont 2092 $ Circle 2093 $ 76034 2094 $ Haley's Place 2095 $ 1 2096 $ 2097 $ 2098 $ 2099 $ no 2100 $ 2007-07-27T18:00:00Z 2102 $ 2103 $ DHCP 2104 $ www.example.com 2105 $ 2106 $ 2107 $ 2108 $ 2109 --boundary1-- 2111 Full Copyright Statement 2113 Copyright (C) The IETF Trust (2007). 2115 This document is subject to the rights, licenses and restrictions 2116 contained in BCP 78, and except as set forth therein, the authors 2117 retain all their rights. 2119 This document and the information contained herein are provided on 2120 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 2121 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE 2122 IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL 2123 WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY 2124 WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE 2125 ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS 2126 FOR A PARTICULAR PURPOSE. 2128 Intellectual Property 2130 The IETF takes no position regarding the validity or scope of any 2131 Intellectual Property Rights or other rights that might be claimed 2132 to pertain to the implementation or use of the technology described 2133 in this document or the extent to which any license under such 2134 rights might or might not be available; nor does it represent that 2135 it has made any independent effort to identify any such rights. 2136 Information on the procedures with respect to rights in RFC 2137 documents can be found in BCP 78 and BCP 79. 2139 Copies of IPR disclosures made to the IETF Secretariat and any 2140 assurances of licenses to be made available, or the result of an 2141 attempt made to obtain a general license or permission for the use 2142 of such proprietary rights by implementers or users of this 2143 specification can be obtained from the IETF on-line IPR repository 2144 at http://www.ietf.org/ipr. 2146 The IETF invites any interested party to bring to its attention any 2147 copyrights, patents or patent applications, or other proprietary 2148 rights that may cover technology that may be required to implement 2149 this standard. Please address the information to the IETF at 2150 ietf-ipr@ietf.org. 2152 Acknowledgment 2154 Funding for the RFC Editor function is provided by the IETF 2155 Administrative Support Activity (IASA).