idnits 2.17.1 draft-ietf-sip-location-conveyance-08.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 1865. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1876. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1883. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1889. 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 38 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 469 has weird spacing: '... ar o ...' == Line 473 has weird spacing: '... ar o ...' == Line 1120 has weird spacing: '... in the locat...' == Line 1255 has weird spacing: '... the conten...' == Line 1429 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: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC2976' is mentioned on line 313, but not defined ** Obsolete undefined reference: RFC 2976 (Obsoleted by RFC 6086) == Missing Reference: 'RFC3515' is mentioned on line 314, but not defined == Missing Reference: 'RFC3903' is mentioned on line 316, but not defined == Missing Reference: 'RFC 4119' is mentioned on line 1712, 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: Jan 9th, 2008 Brian Rosen 5 Intended Status: Standards Track NeuStar 7 Location Conveyance for the Session Initiation Protocol 8 draft-ietf-sip-location-conveyance-08.txt 9 July 9th, 2007 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six 24 months and may be updated, replaced, or obsoleted by other documents 25 at any time. It is inappropriate to use Internet-Drafts as 26 reference material or to cite them other than as "work in 27 progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on January 9th, 2008. 37 Copyright Notice 39 Copyright (C) The IETF Trust (2007). 41 Abstract 43 This document defines an extension to the Session Initiation 44 Protocol (SIP) to convey geographic location information from one 45 SIP entity to another SIP entity. The extension covers end to end 46 conveyance as well as location-based routing, where proxy servers 47 make routing decisions based on the location of the SIP user agents. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 52 2. Conventions used in this document . . . . . . . . . . . . . . 4 53 3. Mechanisms . . . . . . . . . . . . . . . . . . . . . . . . . 4 54 3.1 Overview of SIP Location Conveyance . . . . . . . . . . . 4 55 3.2 The Geolocation Header . . . . . . . . . . . . . . . . . 5 56 3.3 424 (Bad Location Information) Response Code . . . . . . 8 57 3.4 The Geolocation-Error Header . . . . . . . . . . . . . . 8 58 3.5 The Geolocation Option Tag . . . . . . . . . . . . . . . 16 59 3.6 Using sip/sips/pres as a Dereference Scheme . . . . . . . 17 60 4. Geolocation Examples . . . . . . . . . . . . . . . . . . . . 17 61 4.1 Location-by-value (Coordinate Format) . . . . . . . . . . 18 62 4.2 Location-by-reference . . . . . . . . . . . . . . . . . . 19 63 5. SIP Element Behavior . . . . . . . . . . . . . . . . . . . . 20 64 5.1 UAC Behavior . . . . . . . . . . . . . . . . . . . . . . 21 65 5.2 UAS Behavior . . . . . . . . . . . . . . . . . . . . . . 23 66 5.3 Proxy Behavior . . . . . . . . . . . . . . . . . . . . . 25 67 6. Geopriv Privacy Considerations . . . . . . . . . . . . . . . 27 68 7. Security Considerations . . . . . . . . . . . . . . . . . . . 28 69 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . 29 70 8.1 IANA Registration for New SIP Geolocation Header . . . . 30 71 8.2 IANA Registration for New SIP Geolocation Option Tag . . 30 72 8.3 IANA Registration for New 424 Response Code . . . . . . . 30 73 8.4 IANA Registration for New SIP Geolocation-Error Header . 30 74 8.5 IANA Registration for New SIP Geolocation-Error Codes . . 30 75 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 32 76 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 32 77 10.1 Normative References . . . . . . . . . . . . . . . . . 32 78 10.2 Informative References . . . . . . . . . . . . . . . . . 33 79 Author Information . . . . . . . . . . . . . . . . . . . . . 33 80 Appendix A. Requirements for SIP Location Conveyance . . . . 34 81 Appendix B. Example of Civic-based PIDF-LO w/ S/MIME . . . . 36 82 Intellectual Property and Copyright Statements . . . . . . . 37 84 1. Introduction 86 This document describes how Location can be "conveyed" (that is, 87 transmitted over the Internet) from one SIP user agent (UA), or in 88 some circumstances, a proxy server acting in support of a UA, to 89 another entity using SIP [RFC3261]. Here "Location" is a 90 description of the physical geographical area where something 91 currently exists. The phrase "location conveyance" describes 92 scenarios in which a SIP user agent client (UAC) is informing a user 93 agent server (UAS), or intermediate SIP server where the UAC is. A 94 superset of this can also be true as well, in which one UA(1) is 95 telling another UA(2) where another Target is, meaning not 96 necessarily where UA(1) is. The key to this is whether UA(1) has 97 permission to retransmit that other Target's location. If yes, then 98 this is valid. If no, then this is breaking a fundamental rule 99 within this extension. 101 Location Conveyance is different from a UAC seeking the location the 102 UAS. Location conveyance is a 'sending location out in the request' 103 model, where 'asking that someone else's location be in a response' 104 is not discussed here. 106 Geographic location in the IETF is discussed in RFC 3693 (Geopriv 107 Requirements) [RFC3693]. It defines a "Target" as the entity whose 108 location is being sought. In this case, this is the UA's 109 (UA) location. A [RFC3693] "Using Protocol" defines how a "location 110 Server" transmits a "Location Object" to a "Location Recipient" 111 while maintaining the contained privacy intentions of the Target 112 intact. This document describes the extension to SIP for how it 113 complies with the Using Protocol requirements, where the location 114 server is a UA or Proxy Server and the Location Recipient is 115 another UA or Proxy Server. 117 Location can be transmitted by-value or by-reference. The location 118 "value" in this SIP extension is in the form of a Presence 119 Information Data Format - Location Object, or PIDF-LO, as described 120 in [RFC4119]. A PIDF-LO is an XML Scheme specifically for carrying 121 geographic location of a Target. Location-by-value refers to a UA 122 including a PIDF-LO as a body part of a SIP message, sending that 123 Location Object to another SIP element. Location-by-reference 124 refers to a UA or proxy server including a URI in a SIP message 125 header field which can be dereferenced by a Location Recipient for a 126 Location Object, in the form of a PIDF-LO. Dereferencing can be by 127 a SIP UA or a SIP server. 129 As recited in RFC 3693, location often must be kept private. The 130 Location Object (PIDF-LO) contains rules which provides guidance to 131 the Location Recipient and controls onward distribution and 132 retention of the location. This document describes the security and 133 privacy considerations that must be applied to location conveyed 134 with SIP. 136 Another use for location is location-based routing of a 137 SIP request, where the choice of the next hop (and usually, the 138 outgoing Request-URI) is determined by the location of the UAC which 139 is in the message by-value or by-reference. This document describes 140 how location can be conveyed from the UAC, or a proxy acting on its 141 behalf, to a routing proxy. How the location is actually used to 142 determine the next hop or Request-URI is beyond the scope of this 143 document. 145 We refer to the "emergency case". This refers to a specific, 146 important use of SIP location conveyance where the location of the 147 caller is used to determine which Public Safety Answering Point 148 (PSAP) is expected to receive an emergency call request for help 149 (e.g., a call to 1-1-2 or 9-1-1). This is an example of 150 location-based routing. The location conveyed is also used by the 151 PSAP to dispatch first responders to the caller's location. There 152 are special security considerations, which make the emergency case 153 unique, compared to a normal location conveyance within SIP. 155 2. Conventions used in this document 157 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 158 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and 159 "OPTIONAL" in this document are to be interpreted as described 160 in [RFC2119]. 162 3. Mechanisms 164 3.1 Overview of SIP Location Conveyance 166 This document defines a new SIP header: Geolocation. The 167 Geolocation header field contains a URI which can either be a "cid:" 168 URI (Content Identification), per [RFC2392], or a 169 location-by-reference URI to be dereferenced by a Location Recipient 170 to retrieve the location of the Target UA. 172 Where the Geolocation header contains a "cid:", the URI points to a 173 message body that is in the form of a PIDF [RFC3863], which was 174 extended in [RFC4119] to include location, as a PIDF-LO. This is 175 location-by-value, the actual location information in the PIDF-LO is 176 included in the body of the message. 178 If the URI in the Geolocation header field is a scheme other than 179 "cid:", another protocol operation is needed by the SIP message 180 recipient to obtain the location of the Target (UA). This is 181 location-by-reference. This document describes how a SIP presence 182 subscription [RFC3856] can be used as a dereference protocol. 184 The Geolocation header, either with the PIDF-LO in a body or as a 185 location-by-reference URI, can be included by a UA in a 186 SIP message. A SIP proxy server may assert location of the UA by 187 inserting the header field, which must specify a 188 location-by-reference URI. Since body parts cannot be inserted by a 189 SIP proxy server, location-by-value message body cannot be inserted 190 by a proxy. 192 The Geolocation header can have parameters that are associated 193 with a URI in the header field. The "inserted-by" parameter has 194 values of "endpoint" or "server", indicating which entry added 195 location to the message. This header parameter MAY be added every 196 time a new location is added into a message. 198 Retargeting means the Request-URI of the request has changed to 199 point at a new destination UAS. This is different than message 200 routing, that all SIP proxies do. If a SIP request is retargeted 201 based on the location contained or referenced within that message, 202 the "used-for-routing" parameter MUST be added as a header parameter 203 within the appropriate locationValue. 205 There is no mechanism by which the veracity of these parameters can 206 be verified. They are hints to downstream entities on how the 207 location information in the message was originated and used. 209 This document creates a new option tag: geolocation, to indicate 210 support for the this extension by UAs. 212 A new error message (424 Bad Location Information) is also defined 213 in this document. Within this response is a new header indicating 214 location-based errors, call the Geolocation-Error header. This 215 header has various codes that provide additional information about 216 the type of location error experienced by a Location Recipient. 218 Both new headers, the header parameters, the new option-tag, the new 219 error response, and Geolocation-Error codes are IANA registered by 220 this document. 222 3.2 The Geolocation Header 224 This document defines and IANA registers a new SIP header: 225 Geolocation. The Geolocation header field MUST contain at least one 226 of two types of URIs: 228 o a location-by-reference URI, or 230 o a content-ID indicating where location is within the message body 231 of this message 233 A location-by-reference URI is a pointer to a record on a remote 234 node containing location of the location Target, typically the 235 UA in this transaction. 237 A location-by-value content-ID (cid-url) [RFC2392] indicates which 238 message body part contains location for this UA. 240 The Geolocation header has the following BNF syntax: 242 Geolocation = "Geolocation" HCOLON (locationValue *(COMMA 243 locationValue)) 244 locationValue = LAQUOT locationURI RAQUOT *(SEMI geoloc-param) 245 locationURI = sip-URI / sips-URI / pres-URI 246 / cid-url ; (from RFC 2392) 247 / absoluteURI ; (from RFC 3261) 248 geoloc-param = "inserted-by" EQUAL geoloc-inserter 249 / "used-for-routing" 250 / "recipient" EQUAL recipient-type 251 / generic-param ; (from RFC 3261) 252 geoloc-inserter = host-id 253 / gen-value ; (from RFC 3261) 255 recipient-type = "endpoint" / "routing-entity" / "both" 256 / gen-value ; (from RFC 3261) 258 sip-URI, sips-URI and absoluteURI are defined according to RFC 3261. 259 The pres-URI is defined in RFC 3859 [RFC3859]. 261 The cid-url is defined in [RFC2392] to locate message body 262 parts. This URI type MUST be present in a SIP message if location 263 is by-value in that same message. 265 Other protocols used in the Location URI MUST be reviewed against 266 the RFC 3693 criteria for a Using Protocol. 268 The Geolocation header MAY have one or more locationValues. SIP 269 servers inserting a locationValue MUST add the new value to the end 270 of the header value, such that the last locationValue is the most 271 recent one added to the message. 273 A locationValue has the following header parameters. These 274 header parameters include, 276 o the "inserted-by=" provides the host-id (alice.example.com) of 277 the SIP entity that inserted this locationValue into the request. 278 This is used to map to any Geolocation-Error message to determine 279 which location, if there is more than one in a request, the error 280 corresponds to. If an entity receives an Geolocation-Error with 281 a host-id not of this entity, the Geolocation-Error SHOULD be 282 ignored. 284 o "used-for-routing" to inform recipients that the location in this 285 locationValue was used to route the message towards the ultimate 286 destination UAS. This can occur more than once along the 287 request's path. Because locationValues are inserted as last 288 inserted is last in the header, the last locationValue is the 289 most recent one added to the message. This also gives the 290 "used-for-routing" header parameter added integrity - as the 291 receiving SIP entity knows which locationURI the message was 292 routed upon. 294 o the "recipient=" to allow recipients to infer what SIP element 295 type this locationValue was intended to be for. The types are 296 "endpoint", meaning the ultimate destination UAS; 297 "routing-entity", meaning SIP servers; and "both" meaning this 298 locationValue is to be viewed by both types of SIP entities. 300 Each of the three types of header parameters listed here MAY appear 301 in any locationValue once. There MUST NOT be more than one 302 "inserted-by=" parameter or "used-for-routing" parameter or 303 "recipient=" parameter in the same locationValue. However, since 304 there can be more than one locationValue in the same Geolocation 305 header, each can with their own set of these header parameters and 306 not violate this rule. 308 This document defines the Geolocation header as valid in the 309 following SIP requests: 311 INVITE [RFC3261], REGISTER [RFC3261], 312 OPTIONS [RFC3261], BYE [RFC3261], 313 UPDATE [RFC3311], INFO [RFC2976], 314 MESSAGE [RFC3428], REFER [RFC3515], 315 SUBSCRIBE [RFC3265], NOTIFY [RFC3265] and 316 PUBLISH [RFC3903] 318 Discussing location using the PUBLISH Request Method is out of scope 319 for this document, but the Table 1 shows PUBLISH is to support 320 Location Conveyance via this extension. 322 The following table extends the values in Table 2&3 of RFC 3261 323 [RFC3261]. 325 Header field where proxy INV ACK CAN BYE REG OPT PRA 326 ---------------------------------------------------------------- 327 Geolocation R ar o - - o o o o 329 Header field where proxy SUB NOT UPD MSG REF INF PUB 330 ---------------------------------------------------------------- 331 Geolocation R ar o o o o o o o 333 Table 1: Summary of the Geolocation Header 335 The Geolocation header field MAY be included in any one of the above 336 requests by a UAC. A proxy MAY add the Geolocation header, but MUST 337 NOT modify any pre-existing locationValue, including its associated 338 header parameters of within an existing Geolocation header value, 339 unless one of the existing locationValues is used to retarget the 340 request towards a new destination UAS. This is discussed in section 341 5.3. 343 [RFC3261] states message bodies cannot be added by proxies. 344 Therefore, any Geolocation header field added by a proxy MUST be in 345 the form of a location-by-reference URI. 347 Adding a locationValue to an existing Geolocation header SHOULD be 348 done with caution, given this document's limited guidance as to what 349 a Location Recipient should do when receiving more than one 350 location. A Location Recipient can easily be confused by too much 351 location information, producing undesirable results. 353 Location Recipients receiving a location object, received directly 354 or as the result of a dereference, MUST honor the usage element 355 rules within that XML document, per RFC 4119. Such entities MUST 356 NOT alter the rule set. 358 3.3 424 (Bad Location Information) Response Code 360 If a UAS or SIP intermediary detects an error in a request message 361 specific to the location information supplied by-value or 362 by-reference. The new 4XX level error is created here to indicate a 363 problem with the location in the request message. This document 364 creates and IANA registers the new error code: 366 424 (Bad Location Information) 368 The 424 (Bad Location Information) response code is a rejection of 369 the request, due to its location contents, indicating the location 370 information was malformed or not satisfactory for the recipient's 371 purpose or could not be dereferenced. 373 Section 3.4 creates the Geolocation-Error header to provide more 374 detail about what was wrong with the location information in the 375 request. This header MUST be in the 424 response with the most 376 applicable code. 378 If more than one location is present in a request (by-value or 379 by-reference), and any of the locationValues is good for the 380 Location Recipient to process, a 424 MUST NOT be sent. The 424 is 381 only appropriate when there are no locationValues included in a SIP 382 request that are usable by a recipient. 384 A 424 (Bad Location Information) response is a final response within 385 a transaction, and does not terminate a dialog. 387 The UAC can use whatever means it knows of to verify/refresh its 388 location information before attempting a new request that includes 389 location. There is no cross-transaction awareness expected by either 390 the UAS or SIP intermediary as a result of this error message. 392 The new 424 (Bad Location Information) error code is IANA registered 393 in Section 8 of this document. An initial set of location error of 394 IANA registered Geolocation-Error codes are in Section 3.4 of this 395 document. 397 3.4 The Geolocation-Error Header for Error Granularity 399 As discussed in Section 3.3, more granular error notifications, 400 specific to location errors within a received request, are required 401 if the UAC is to know what was wrong within the original request. 402 The Geolocation-Error header is created here for this purpose. 403 Geolocation-Error header is used to convey location specific errors 404 within a response. Additions to this IANA registered header require 405 an RFC be published. 407 Geolocation-Error = "Geolocation-Error" HCOLON (locationErrorValue 408 *(COMMA locationErrorValue)) 409 locationErrorValue = numeric-code SEMI (error-node-id) 410 SEMI (host-id) SEMI (geoloc-error-param) 411 numeric-code = decimal-string 412 error-node-id = node-id 413 host-id = "inserter" EQUAL host name 414 geoloc-error-param = "code" EQUAL error-text-string 415 / generic-param ; (from RFC 3261) 416 error-text-string = string 418 The Geolocation-Error header contains a locationErrorValue, which is 419 a numeric code of the error with its associated descriptive text, 420 the error-text-string. The error-text-string is human understandable 421 text for each error code. The Geolocation-Error can have more than 422 one locationErrorValue, separated by a comma. Included error codes 423 SHOULD NOT conflict in meaning. Each locationErrorValue is targeted 424 at a specific location inserter, which is learned from the 425 "inserted-by=" parameter in the locationValue of the request. 427 The Numeric-code value is the number assigned to a particular error. 428 These error codes start 1, and are not necessarily consecutively 429 incremented. All Numeric-code values are IANA registered. 431 The error-node-id is the node identification of the entity that 432 experienced the location-based error from the request, and MUST NOT 433 be an IP address for many reasons, including the presence of NATs. 434 This can be useful for troubleshooting. Here is an example of an 435 error-node-id 437 alice.example.com 439 The host-id has the same form as the error-node-id, but the host-id 440 is the host name of the entity that inserted the location into the 441 request. This value can be found in the "inserted-by=" parameter of 442 the Geolocation header in the request. If this is not present in 443 the request, the host-id cannot be in the response. This value, 444 when present, gives the response recipients an indication as to 445 which location, therefore which entity, this particular error is 446 intended for. Here is an example of the host-id 448 bob.example.com 450 If an entity receives an Geolocation-Error with a host-id not of 451 this entity, the Geolocation-Error SHOULD be ignored because the 452 error is not intended for this entity. 454 The error-text-string is a natural language ASCII string that is 455 intelligible to a human user reading the error message, which 456 describes the type of error experienced. This string MUST appear in 457 each locationErrorValue of a response. 459 Here is an example of a Geolocation-Error header 461 Geolocation-Error: 1; alice.example.com; code="Location Format not 462 supported" 464 The following table extends the values in Table 2&3 of RFC 3261 465 [RFC3261]. 467 Header field where proxy INV ACK CAN BYE REG OPT PRA 468 ---------------------------------------------------------------- 469 Geolocation-Error r ar o - - o o o o 471 Header field where proxy SUB NOT UPD MSG REF INF PUB 472 ---------------------------------------------------------------- 473 Geolocation-Error r ar o o o o o o o 475 Table 2: Summary of the Geolocation-Error Header 477 The Geolocation-Error header field MAY be included in the response 478 to one of the above SIP requests, so long as Geolocation was in the 479 request part of the transaction. The choice of which SIP requests 480 are in table 2 above come from which Methods can optionally have the 481 Geolocation header (see section 3.2). 483 The Geolocation-Error header allows for multiple locationErrorValues 484 to be returned in the same response. For instance, if a 485 location-by-reference is sent and the supplied scheme is not desired 486 or cannot be processed, but more than one other scheme can be, the 487 424 response can list more than one code from the 20-22 range in the 488 response. The UAC can subsequently retry the transaction with one of 489 the schemes supported or desired by the recipient. 491 To illustrate this, here is an example of Alice including 492 location-by-reference using an HTTP scheme. In this case, Bob 493 cannot dereference using HTTP, but can dereference using SIP, SIPS, 494 and PRES. An example of this transaction, with a 424 (Bad Location 495 Information) response, including a Geolocation-Error header, is in 496 Figure 1. 498 Alice Bob 499 | | 500 | Request w/ Location | 501 | using http scheme | 502 |----------------------------------->| 503 | | 504 | | 505 | 424 (Bad Location Information) | 506 | with Geolocation-Error containing | 507 | 20 (SIP), 21 (SIPS), 22 (PRES) | 508 |<-----------------------------------| 509 | | 511 Figure 1. Basic Transaction with 424 and Geolocation-Error Header 513 The following subsections provide an initial list of location 514 specific granular codes for any SIP responses, including the new 424 515 (Bad Location Information) response. If more than one specific 516 Geolocation-Error code is applicable for a response, each MUST be in 517 the response. Geolocation-Error Code 1 is the generic 'location was 518 supplied, but not understood' error. If a more specific code 519 applies, a code 1 is unnecessary. 521 3.4.1 Geolocation-Error Code 1 Location Not Understood 523 Geolocation-Error code 1 "Location Format not supported" means the 524 location format supplied in the request, by-value or by-reference, 525 was not supported. 527 This code means the recipient understood that location was included 528 in the message, but the format is not supported. Perhaps the format 529 was a freeform text format or data-URL and the recipient only 530 understood location in RFC 4119 PIDF-LO format (civic or 531 x.y(.z) coordinate). This error code applies when a recipient has 532 difficulty parsing the location supplied in the request. 534 If the format is understood, but not desired, an error code 2 or 3 535 MUST be returned in a 424 response, depending on which location 536 format is desired. The Location Recipient returns an error code 2 or 537 3 when it only understands one location format (coordinate or civic) 538 and did not receive that format. 540 If a more specific error code is appropriate in a response, 541 including error code 1 is unnecessary. 543 error-text-string: Location format not supported 545 An example usage in a SIP 424 response: 547 Geolocation-Error: 1 alice.example.com "Location Format not 548 supported" 550 3.4.2 Geolocation-Error Code 2 Coordinate-location Format Desired 552 Geolocation-Error code 2 "Coordinate-location Format Desired" means 553 the location format supplied in the request (probably formatted in 554 civic), by-value or by-reference, was understood and supported, but 555 that the recipient, or an application on the recipient, can or 556 prefers to only process location in the coordinate-location format. 558 A typical reaction to receiving this code is to resend the 559 original message with location formatted in coordinate instead. 561 error-text-string: Coordinate-location Format Desired 563 An example usage in a SIP 424 response: 565 Geolocation-Error: 2 node_alice.example.com "Coordinate-location 566 Format Desired" 568 3.4.3 Geolocation-Error Code 3 Civic-location Format Desired 570 Geolocation-Error code 3 "Civic-location Format Desired" means the 571 location format supplied in the request (probably formatted in 572 coordinate), by-value or by-reference, was understood and supported, 573 but that the recipient, or an application on the recipient, can or 574 prefers to only process location in the civic-location format. 576 A typical reaction to receiving this code is to resend the 577 original message with location formatted in civic instead. 579 error-text-string: Civic-location Format Desired 581 An example usage in a SIP 424 response: 583 Geolocation-Error: 3 alice.example.com "Civic-location Format 584 Desired" 586 3.4.4 Geolocation-Error Code 4 Cannot Parse Location Supplied 588 Geolocation-Error code 4 "Cannot parse location supplied" means the 589 location provided, whether by-value or by-reference, in a request is 590 not well formed. 592 error-text-string: Cannot parse location supplied 594 An example usage in a SIP 424 response: 596 Geolocation-Error: 4 alice.example.com "Cannot parse location 597 supplied" 599 3.4.5 Geolocation-Error Code 5 Cannot Find Location 601 Geolocation-Error code 5 "Cannot find location" means location was 602 expected in the request, but the recipient cannot find it. 604 This can be either because the cid: pointed to a message body part 605 that is not present in the request, there was no location message 606 body part, or what is dereferenced at the supplied locationURI did 607 not return a PIDF-LO, or location is encrypted/opaque to the 608 recipient. 610 A typical reaction to receiving this code is for the location sender 611 to verify that it has indeed included location information in the 612 request in the properly indicated place and then to send the request 613 again. 615 error-text-string: Cannot find location 617 An example usage in a SIP 424 response: 619 Geolocation-Error: 5 alice.example.com "Cannot find location" 621 3.4.6 Geolocation-Error Code 6 Conflicting Locations Supplied 623 Geolocation-Error code 6 "Conflicting Locations Supplied" means a 624 Location Recipient received more than one location describing where 625 the Target is, and is either unsure which whole location is true or 626 which parts of multiple locations make up where the Target is. 628 This is generally a case of either too much information, and the 629 information is pointing towards at least two different positions, 630 confusing the recipient. 632 A possible scenario exists in which at least two locations are in 633 the request, perhaps one or more were added by proxies along the 634 path of the request, each pointing to where the UAC is. If these 635 are pointing at different positions - the UAS does not know which to 636 trust. This error code unfortunately means the UAS cannot solve for 637 which location needs to be ignored to make up a complete location, 638 or how to prioritize one location over all others in the same 639 request. 641 A typical reaction to receiving this code is to reduce the number of 642 different locations supplied in the request, if under control by the 643 Target, and send another message to the Location Recipient. 645 error-text-string: Conflicting Locations Supplied 647 An example usage in a SIP 424 response: 649 Geolocation-Error: 6 alice.example.com "Conflicting Locations 650 Supplied" 652 3.4.7 Geolocation-Error Code 7 Incomplete Location Supplied 654 Geolocation-Error code 7 "Incomplete Location Supplied" means there 655 is not enough location information, by-value or retrieved 656 by-reference, to determine where the location Target is. 658 Perhaps the coordinate precision is not fine enough, or the civic 659 address lacks the fields to inform the UAS or proxy where the Target 660 is. This might be true for request retargeting, or it might be true 661 for first responder dispatch or pizza delivery (for example, because 662 the street address is missing). 664 A typical reaction to receiving this code is for the location sender 665 to convey more (precise) location information, if doing so is 666 allowed by local policy. 668 error-text-string: Incomplete location supplied 670 An example usage in a SIP 424 response: 672 Geolocation-Error: 7 alice.example.com "Incomplete location 673 supplied" 675 3.4.8 Geolocation-Error Code 8 Cannot Dereference 677 Geolocation-Error code 8 "Cannot dereference" means the act of 678 dereferencing failed to return the Target's location. This 679 generally means the supplied URI is bad. 681 error-text-string: Cannot dereference 683 An example usage in a SIP 424 response: 685 Geolocation-Error: 8 alice.example.com "Cannot dereference" 687 3.4.9 Geolocation-Error Code 9 Dereference Denied 689 Geolocation-Error code 9 "Dereference Denied" means there was 690 insufficient authorization to dereference the Target's location. 692 error-text-string: Dereference Denied 694 An example usage in a SIP 424 response: 696 Geolocation-Error: 9 alice.example.com "Dereference Denied" 698 3.4.10 Geolocation-Error Code 10 Dereference Timeout 700 Geolocation-Error code 10 "Dereference Timeout" means the 701 dereferencing node has not received the Target's location within a 702 reasonable timeframe. 704 error-text-string: Dereference Timeout 706 An example usage in a SIP 424 response: 708 Geolocation-Error: 10 alice.example.com "Dereference Timeout" 710 3.4.11 Geolocation-Error Code 11 Cannot Process Dereference 712 Geolocation-Error code 11 "Cannot process Dereference" means the 713 dereference protocol has received an overload condition error, 714 indicating the location cannot be accessed at this time. 716 If a SIP or SIPS scheme were used to dereference the Target's 717 location, and a 503 (Service Unavailable) were the response to the 718 dereference query, this Geolocation-Error code 11 would be placed in 719 the 424 (Bad Location Information) response to the location sender. 721 error-text-string: Cannot process Dereference 723 An example usage in a SIP 424 response: 725 Geolocation-Error: 11 alice.example.com "Cannot process Dereference" 727 3.4.12 Geolocation-Error Code 20 Unsupported Scheme - SIP desired 729 Geolocation-Error code 20 "Unsupported Scheme - SIP desired" means 730 the location dereferencer cannot dereference using the 731 location-by-reference URI scheme supplied because it does not 732 support the necessary protocol to do this. 734 This code means the Location Recipient can dereference the Target's 735 location using a SIP-URI scheme. There can be more than one 736 locationErrorValue in a Geolocation-Error header, indicating in this 737 context the recipient can dereference using each scheme protocol 738 included in the Geolocation-Error header. 740 Note that indicating SIP to be used to dereference location is 741 requesting the transmission to be in cleartext, which is a security 742 risk. Therefore, the SIP scheme SHOULD NOT be used to dereference. 743 An exception can be made for emergency calling, preferably after 744 SIPS has been attempted, and failed. 746 A typical reaction to receiving this code would be for the location 747 sender to send a URI with the sip scheme. 749 error-text-string: unsupported scheme - SIP desired 751 An example usage in a SIP 424 response: 753 Geolocation-Error: 20 alice.example.com "unsupported scheme - SIP 754 desired" 756 3.4.13 Geolocation-Error Code 21 Unsupported Scheme - SIPS desired 758 Geolocation-Error code 21 "Unsupported Scheme - SIPS desired" means 759 the location dereferencer cannot dereference using the 760 location-by-reference URI scheme supplied because it does not 761 support the necessary protocol to do this. 763 This code means the Location Recipient can dereference the Target's 764 location using a SIPS-URI scheme. There can be more than one 765 locationErrorValue in a Geolocation-Error header, indicating in this 766 context the recipient can dereference using each scheme protocol 767 included in the Geolocation-Error header. 769 error-text-string: unsupported scheme - SIPS desired 771 An example usage in a SIP 424 response: 773 Geolocation-Error: 21 alice.example.com "unsupported scheme - SIPS 774 desired" 776 3.4.14 Geolocation-Error Code 22 Unsupported Scheme - pres desired 778 Geolocation-Error code 22 "Unsupported Scheme - pres desired" means 779 the location dereferencer cannot dereference using the 780 location-by-reference URI scheme supplied because it does not 781 support the necessary protocol to do this. 783 This code means the Location Recipient can dereference the Target's 784 location using a PRES-URI scheme. There can be more than one 785 locationErrorValue in a Geolocation-Error header, indicating in this 786 context the recipient can dereference using each scheme protocol 787 included in the Geolocation-Error header. 789 error-text-string: unsupported scheme - pres desired 791 An example usage in a SIP 424 response: 793 Geolocation-Error: 22 alice.example.com "unsupported scheme - pres 794 desired" 796 3.5 The Geolocation Option Tag 798 This document creates and IANA registers one new option tag: 799 "geolocation". This option tag is to be used, per RFC 3261, in the 800 Require, Supported and Unsupported headers. Whenever a UA wants to 801 indicate support for this SIP extension, the geolocation option tag 802 is included in a Supported header of the SIP message. 804 Including the geolocation option-tag within an Unsupported header of 805 a 420 (Bad Extension) response is appropriate when a UAS 806 does not support this Geolocation extension. 808 A UAC adding this option-tag to a Require header field indicates to 809 a UAS the UAS MUST support this extension in order to continue 810 processing the message, or send a 420 response back to the UAC. 811 Some environments MAY use a Require header in this way, but it 812 SHOULD be used with caution to prevent unnecessary communications 813 problems. 815 A UAC SHOULD NOT include this option tag in a Proxy-Require header, 816 since a UAC is not likely to understand the topology of the 817 infrastructure, and therefore would not understand which proxy will 818 do the location-based routing function, if any. A potentially bad 819 scenario would have the first proxy not support this extension, but 820 a subsequent proxy does. This would result in no communications 821 past the first proxy, which MUST send the 420 back under these 822 circumstances. 824 3.6 Using sip/sips/pres as a Dereference Scheme 826 If a location-by-reference URI is included in a SIP request, in MUST 827 be in a locationValue in the Geolocation header and it MUST be a 828 SIP, SIPS or PRES-URI . When PRES: is used, if the resulting 829 resolution, per [RFC3856], resolves to a SIP: or SIPS: URI, this 830 section applies. Use of other protocols for dereferencing of a 831 PRES: URI is not defined, and such use is subject to review against 832 RFC 3693 Using Protocol criteria. 834 Dereferencing a Target's location using SIP or SIPS MUST be 835 accomplished by treating the URI as a presence URI and generating a 836 SUBSCRIBE request to a presence server as per [RFC3856]. The 837 resulting NOTIFY will contain a PIDF, which MUST contain a PIDF-LO. 839 When used in this manner, SIP is a Using Protocol per [RFC3693] and 840 elements receiving location MUST honor the 'usage-element' rules as 841 defined in this extension. 843 A dereference of a location-by-reference URI using SUBSCRIBE is not 844 violating a PIDF-LO 'retransmission-allowed' element value set to 845 'no', as the NOTIFY is the only message in this multi-message set 846 of transactions that contains the Target's location, with the 847 location recipient being the only SIP element to receive location - 848 which is the purpose of this extension: to convey location to a 849 specific destination. 851 4. Geolocation Examples 853 This section contains are two examples of messages providing 854 location. One shows location-by-value with coordinates, the other 855 shows location-by-reference. The example for (Coordinate format) 856 is taken from [RFC3825]. A civic format example of the same position 857 on the earth as is in the coordinate format example is in appendix 858 B, which is taken from [RFC4776]. The differences between the two 859 formats are within the of the examples. Other 860 than this portion of each PIDF-LO, the rest is the same for both 861 location formats. 863 The key to the provided samples is in the Geolocation header, which 864 has a different type of URI, based on the different means of 865 location conveyance. Section 4.1 shows a "cid:" URI, indicating 866 this SIP request contains a location-by-value message body - which 867 is in the form of a PIDF-LO. Section 4.2 shows a 868 location-by-reference URI indicating location is to be acquired via 869 an indirection dereference mechanism, which is determined by the 870 scheme of URI supplied. 872 4.1 Location-by-value (Coordinate Format) 874 This example shows an INVITE message with a coordinate, or 875 coordinate location. In this example, the SIP request uses a 876 sips-URI [RFC3261], meaning this message is TLS protected on a 877 hop-by-hop basis all the way to Bob's domain. 879 INVITE sips:bob@biloxi.example.com SIP/2.0 880 Via: SIP/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bK74bf9 881 Max-Forwards: 70 882 To: Bob 883 From: Alice ;tag=9fxced76sl 884 Call-ID: 3848276298220188511@atlanta.example.com 885 Geolocation: 886 ;inserted-by=alice@atlanta.example.com ;recipient=endpoint 887 Supported: geolocation 888 Accept: application/sdp, application/pidf+xml 889 CSeq: 31862 INVITE 890 Contact: 891 Content-Type: multipart/mixed; boundary=boundary1 892 Content-Length: ... 894 --boundary1 896 Content-Type: application/sdp 898 ...SDP goes here 900 --boundary1 902 Content-Type: application/pidf+xml 903 Content-ID: alice123@atlanta.example.com 905 906 911 912 2007-07-09T14:00:00Z 913 914 915 916 917 918 33.001111 -96.68142 919 920 921 922 923 no 924 2007-07-27T18:00:00Z 926 927 DHCP 928 www.example.com 929 930 931 932 933 --boundary1-- 935 The Geolocation header field from the above INVITE... 937 Geolocation: 939 ...indicates the content-ID location [RFC2392] within the multipart 940 message body of where location information is, with SDP being the 941 other message body part. 943 If the Geolocation header field were this instead: 945 Geolocation: 947 ...this would indicate location by-reference was included in this 948 message. It is expected that any node wanting to know where user 949 target123 is would subscribe to server5 to dereference the sips-URI. 950 The returning NOTIFY would contain Alice's location in a PIDF-LO, as 951 if it were included in a message body (part) of the original INVITE 952 here. 954 4.2 Location-by-reference 956 Below is an INVITE request with a location-by-reference URI instead 957 of a location-by-value PIDF-LO message body part shown in Sections 958 4.1. It is up to the location recipient to dereference Alice's 959 location at the Atlanta server containing the location record. 960 Dereferencing, if done with SIP, is accomplished by the Location 961 Recipient sending a SUBSCRIBE request to the URI reference for 962 Alice's location. The received NOTIFY is the first SIP message 963 containing Alice's UA location, as a PIDF-LO message body. The 964 NOTIFY, in this case, is the SIP request that is conveying location, 965 and not the INVITE. There is no retransmission of location in this 966 usage. 968 INVITE sips:bob@biloxi.example.com SIP/2.0 969 Via: SIP/2.0/TLS pc33.atlanta.example.com 970 ;branch=z9hG4bK74bf9 971 Max-Forwards: 70 972 To: Bob 973 From: Alice ;tag=9fxced76sl 974 Call-ID: 3848276298220188511@atlanta.example.com 975 Geolocation: 976 ;inserted-by=bigbox3.atlanta.example.com ;recipient=server 977 Supported: geolocation 978 Accept: application/sdp, application/pidf+xml 979 CSeq: 31862 INVITE 980 Contact: 982 ...SDP goes here as the only message body 984 A Location Recipient would need to dereference the sips-URI in the 985 Geolocation header field to retrieve Alice's location. If the 986 atlanta.example.com domain chooses to implement location conveyance 987 and delivery in this fashion (i.e., location-by-reference), it is 988 RECOMMENDED that entities outside this domain be able to reach the 989 dereference server, otherwise this model of implementation is 990 only viable within the atlanta.example.com domain. 992 5. SIP Element Behavior 994 Because a device's location is generally considered to be sensitive 995 in nature, privacy of the location information needs to be protected 996 when transmitting such information. Section 26 of [RFC3261] defines 997 the security functionality SIPS for transporting SIP messages with 998 either TLS or IPSec, and S/MIME for encrypting message bodies from 999 SIP intermediaries that would otherwise have access to reading the 1000 clear-text bodies. SIP endpoints SHOULD implement S/MIME to encrypt 1001 the PIDF-LO message body (part) end-to-end when the Location 1002 Recipient is intended to be another UA. The SIPS-URI from [RFC3261] 1003 MUST be implemented for message protection (message integrity and 1004 confidentiality) and SHOULD be used when S/MIME is not used. 1005 Possession of a dereferenceable location URI can be equivalent to 1006 possession of the location information itself and thus TLS SHOULD be 1007 used when transmitting location-by-reference hop-by-hop along the 1008 path to the Location Recipient. 1010 A PIDF includes identity information. It is possible for the 1011 identity in the PIDF to be anonymous. Implementations of this 1012 extension should consider the appropriateness of including an 1013 anonymous identity in the location information where a real identity 1014 is not required. When using location-by-reference, it is 1015 RECOMMENDED that the URI does not contain any identifying 1016 information (for example use 3fg5t5yqw@example.com rather than 1017 alice@example.com). 1019 Location Recipients MUST obey the privacy and security rules in the 1020 PIDF-LO as described in RFC 4119 regarding retransmission and 1021 retention. 1023 Self-signed certificates SHOULD NOT be used for protecting a PIDF, 1024 as the sender does not have a secure identity of the recipient. 1026 More than one location format (civic and coordinate) MAY be included 1027 in the same message body part, but all location parts of the same 1028 PIDF-LO MUST point at the same position on the earth. The same 1029 location in multiple formats can allow the recipient to use the most 1030 convenient or preferable format for its use. Multiple PIDF-LOs are 1031 allowed in the same request, with each allowed to point at separate 1032 positions. 1034 It is RECOMMENDED there is only one "location" in a single SIP 1035 request. This means SIP servers SHOULD NOT add another 1036 locationValue to a SIP request that already contains location. This 1037 will likely lead to confusion at the ultimate location recipient 1038 because this extension does not provide guidance on what a recipient 1039 is to do with more than one location, nor does it give any 1040 preference regarding which location is better or worse than another 1041 location in the same request. 1043 5.1 UAC Behavior 1045 A UAC can send location in a SIP request, because it was requested, 1046 to facilitate location-based routing of the request, or 1047 spontaneously (i.e., a purpose not defined in this document but 1048 known to the UAC). 1050 A UAC conveying location MUST include a locationValue in a 1051 Geolocation header (see section 3.2) with either a location-by-value 1052 indication (a cid-URL), or a location-by-reference indication (a 1053 dereferenceable URI). A location-by-value message body sent without 1054 a Geolocation header field MUST NOT occur. The UAC supporting this 1055 extension MUST include a Supported header with the geolocation 1056 option tag. 1058 The geolocation option-tag is inserted in a Supported header by a 1059 UAC to provide an indication of support for this extension. The 1060 presence of the geolocation option tag in a Supported header without 1061 a Geolocation header field in the same message informs a receiving 1062 SIP element the UAC understands this extension, but it does not know 1063 or wish to convey its location at this time. Certain scenarios 1064 exist (location-based retargeting) in which location is required in 1065 a SIP request in order to retarget the message properly. This 1066 affects how a UAS or SIP server processes to such a request. 1068 The geolocation option tag SHOULD NOT be used in the Proxy-Require 1069 Header, because the UAC often will not know the underlying topology 1070 to know which proxy will do the retargeting, thus increasing the 1071 likelihood of a request failure by the first hop proxy that does not 1072 understand this extension, but is required to by inclusion of the 1073 option-tag in this header. 1075 A UAC inserting a locationValue MUST include an "inserted-by=" 1076 parameter to indicate its host-id. This is copied to the 1077 "inserter=" parameter of the Geolocation-Error header in a response 1078 if there is something wrong with the location in the original 1079 request. Because more than one locationValue can be inserted along 1080 the path of the request, this indication is necessary to show which 1081 locationValue had the problem in the response. For example: 1083 Geolocation: ; 1084 inserted-by=alice@atlanta.example.com 1086 The UAC MAY include an intended target of this location parameter by 1087 adding the "recipient=" parameter to the locationValue like this: 1089 Geolocation: ; 1090 inserted-by=alice@atlanta.example.com; 1091 recipient=endpoint 1093 See section 3.2 for further details about all the header parameters 1094 of a locationValue. 1096 If a sent request failed based on the location in the original 1097 request, a 424 (Bad Location Information) response is sent. The UAC 1098 should receive a Geolocation-Error header in any response message. 1099 The Geolocation-Error has a header parameter indicating which entity 1100 inserted the location pertaining to this error. This is in the form 1101 of a host-id. A UAC receiving this 424 should review this 1102 "inserter=" locationErrorValue parameter to see if it indicates this 1103 UAC. If it does not, the 424 should be ignored. If this value 1104 does, 424 is intended for this UAC, and MUST process the response, 1105 including the Geolocation-Error code (defined in section 3.4). The 1106 UAC SHOULD take correct steps to rectify future errors, based on the 1107 received error code, to increase the possibility of less request 1108 failures going forward. A UAC MAY reattempt a new request if it 1109 believes it can correct the stated failure in the Geolocation-Error 1110 header. 1112 Any UAC that inserted location into a request should be prepared to 1113 receive the Geolocation-Error header in any response, looking to 1114 determine if the header is meant for the UAC, and to react 1115 accordingly. 1117 5.2 UAS Behavior 1119 If the Geolocation header field is present in a received SIP 1120 request, the type of URI contained in the locationValue will 1121 indicate if location has been conveyed by-value in a message body 1122 (part) or by-reference, requiring an additional dereference 1123 transaction. If the by-reference URI is sip:, sips: or pres:, the 1124 UAS MUST initiate a SUBSCRIBE to the URI provided to retrieve the 1125 PIDF-LO being conveyed by the UAC per [RFC3856]. If successful, the 1126 PIDF-LO will be returned in the NOTIFY request from the server. 1128 A Require header with the geolocation option tag indicates the 1129 UAC is requiring the UAS to understand this extension or else send 1130 an error response. A 420 (Bad Extension) with a geolocation option 1131 tag in a Unsupported header would be the appropriate response in 1132 this case. 1134 In the undesired situation in which location is conveyed without a 1135 Geolocation header, that contains the URI of where the location is, 1136 the UAS MUST be able to read a location-by-value message body. A 1137 Location-by-reference URI MUST NOT be placed in any other SIP header 1138 than Geolocation. 1140 If the UAC conveys location in a request, but the UAS has one or 1141 more problems with each location in the request (or while attempting 1142 to dereference the UAC's location), the UAS MUST indicate what 1143 problem was experienced with the location in the request. A 1144 Geolocation-Error header is how the UAS informs the UAC of a 1145 location-based error within the request. Section 3.4 lists these 1146 errors, which are all IANA registered. 1148 The Geolocation-Error header is permitted in any response. For 1149 example, Bob can reply to Alice with a 486 because he's not willing 1150 to accept the call at this time, and inform Alice that the location 1151 contained in the request was bad in some way. In this case, the 486 1152 would contain a Geolocation-Error header indicating the specific 1153 location error experienced 1155 If the request had a Require header with a geolocation option-tag, 1156 then a 424 (Bad Location Information) response would be an 1157 appropriate response. This 424 would include a locationErrorValue 1158 in a Geolocation-Error header. 1160 Because this extension allows more than one locationValue, 1161 potentially from more than SIP entity, there needs to be a means of 1162 identifying which entity inserted a particular locationValue for 1163 error response purposes. Also, there needs to be a means to inform 1164 that entity what the Location Recipient considered in error with 1165 that locationValue. 1167 If a Geolocation locationValue is present in a request, it can 1168 contain as many as three header parameters, "inserted-by=", 1169 "used-for-routing" and "recipient=" parameters. 1171 The "inserted-by" parameter in the locationValue of the request that 1172 had errors in it is copied into the "inserter=" parameter of the 1173 locationErrorValue of the Geolocation-Error header of the response. 1174 This SHOULD happen for each location that was considered bad by the 1175 UAS to ensure each location inserter understands which error code(s) 1176 is intended for them. 1178 Further, more than one error code is allowed in the 1179 locationErrorValue - each having an "inserter=" parameter. The 1180 error codes destined for the same inserter MUST NOT contradict the 1181 meaning of the problem the UAS had with a particular locationValue. 1183 If a locationValue contains the "inserted-by=" parameter, the 1184 recipient will learn the SIP entity who added that locationValue. 1186 If a Geolocation locationValue contains the "used-for-routing" 1187 parameter, the UAS will learn which location was used to retarget 1188 this request towards this UAS. This parameter MAY be present in 1189 each locationValue within the Geolocation header (meaning up to one 1190 per locationValue). locationValues are placed into the Geolocation 1191 header in an order. The location inserted first, remains first in 1192 the header. A subsequence locationValue is placed next in the 1193 header (and so on). The last locationValue in the header was the 1194 most recently added locationValue to the request. From this 1195 order, the more recent "used-for-routing" parameter, if present, was 1196 the locationValue used for retargeting this request at this UAS. In 1197 this case, a "used-for-routing" parameter on a previous 1198 locationValue should be ignored, except perhaps in the case of 1199 after-the-fact analysis of how a request took the whole path it 1200 took. 1202 The "recipient=" header parameter allow recipients to infer the SIP 1203 entity type this locationValue is intended to be for. The types are 1204 "endpoint", meaning the ultimate destination UAS; "routing-entity", 1205 meaning SIP servers; and "both" meaning this locationValue is to be 1206 viewed by both types of SIP entities. 1208 If there are any header parameters in a received locationValue, 1209 they MUST NOT be modified or deleted in transit to the ultimate 1210 destination. 1212 If there is more than one locationValue in a request, and any one of 1213 them is valid (i.e., one contains enough information to not generate 1214 a 424 if that was the only location present in the request), all 1215 other locations MAY be ignored, and a 424 MUST NOT be sent because 1216 of these other locations in the request. Another response MAY be 1217 sent, which includes a locationErrorValue. This document says 1218 nothing about what a Location Recipient does with more than one 1219 'good' location in a request (i.e., which to choose to use). 1221 A Geolocation-Error is permissible in a 200 OK response. This means 1222 everything else in the request was acceptable, but the location was 1223 not for a given error code(s). One exception to this set of rules 1224 is if a geolocation option-tag was in the Require header in the 1225 request. This would necessitate a 424 response. 1227 A UAS MUST NOT send location in a response message, as there can be 1228 any number of issues/problems with receiving location, and the UAC 1229 or proxy servers cannot error a response. Therefore, the UAS, if it 1230 wants to send a UAC its location, SHOULD do so in a new request in a 1231 separate transaction. This document give no guidance which request 1232 to use. 1234 A UAS MAY include a geolocation option-tag in the Supported header 1235 of a response, indicating if does understand this extension. 1237 5.3 Proxy Behavior 1239 [RFC3261] states message bodies cannot be added by proxies. 1240 However, proxies are permitted to add a header to a request. This 1241 implies that a proxy can add a Geolocation locationValue with 1242 location-by-reference URI, but not location-by-value message body. 1243 However, if location is already in a SIP request, a SIP server 1244 SHOULD NOT add another instance of the UAC's location to the same 1245 request. This will likely cause confusion at the Location Recipient 1246 as to which to use. This document gives no guidance how a UAS is to 1247 deal with more than one location in a SIP request, other than the 1248 intended "recipient=" parameter, which has no integrity protection 1249 in transit. If more than one locationValue states 1250 "recipient=endpoint", this document gives no guidance what the UAS 1251 is to do. 1253 A proxy is permitted to read any locationValue, and the associated 1254 body, if not S/MIME protected, in transit if present, and MUST use 1255 the contents of the header field to make location-based retargeting 1256 decisions, if retargeting requests based on location is a function 1257 of that proxy. 1259 More than one Geolocation locationValue in a message is permitted, 1260 but can cause confusion at the recipient. If a proxy chooses to add 1261 a locationValue to a Geolocation header, which would be a local 1262 policy decision, the new locationValue MUST be added to the end of 1263 the header (after previous locationValue(s)). This to create an 1264 order of insertion of locationValues along the path. Proxies MUST 1265 NOT modify the order of locationValues in a geolocation header. 1267 5.3.1 Proxy Behavior with Geolocation Header Parameters 1269 SIP servers MUST NOT delete any existing Geolocation locationValue 1270 (URI or header parameter) from a request. A Geolocation 1271 locationValue (URI or header parameter) MAY only be modified to by 1272 adding a "used-for-routing" parameter to an existing locationValue, 1273 if the request was retargeted based on the location within that 1274 locationValue. Further modification of this Geolocation header 1275 field MUST NOT occur. For example, an existing Geolocation 1276 locationValue in a request of: 1278 Geolocation: ; 1279 inserted-by=alice123@atlanta.example.com; 1281 can be modified by a proxy to add the "used-for-routing" parameter, 1282 like this: 1284 Geolocation: ; 1285 inserted-by=alice@atlanta.example.com; 1286 used-for-routing 1288 if this is the locationValue the proxy used to make a retargeting 1289 decision based upon, but make no other modification. 1291 A SIP server MAY add a new Geolocation locationValue to a SIP 1292 request. The proxy SHOULD NOT insert a locationValue of the UAC 1293 unless it is reasonably certain it knows the actual location of the 1294 endpoint, for example, if it thoroughly understands the topology of 1295 the underlying access network and it can identify the device 1296 reliably (in the presence of, for example, NAT). 1298 B2BUAs MUST set the "inserted-by" header parameter with their 1299 Host-ID. This is for error mapping reasons. 1301 A server adding a locationValue to an existing Geolocation header 1302 would look like: 1304 Geolocation: ; 1305 inserted-by=alice@atlanta.example.com, 1306 ; 1307 inserted-by=lis1.atlanta.example.com; 1309 Notice the locationValue added by the proxy is last among 1310 locationValues. This practice MUST be done for all added 1311 locationValues. 1313 If this request was then retargeted by an intermediary using the 1314 locationValue inserted by the server, the intermediary would add a 1315 "used-for-routing" parameter like this: 1317 Geolocation: ; 1318 inserted-by=alice@atlanta.example.com, 1320 ; 1321 inserted-by=lis1.atlanta.example.com; used-for-routing 1323 It is conceivable that an initial routing decision is made on an 1324 one locationValue, and subsequently another routing decision is 1325 made on a different locationValue. This retargeting decision can be 1326 made on a newly inserted locationValue. While unusual, it can 1327 occur. In such a case, proxies MUST NOT remove any existing 1328 "used-for-routing" header parameter. In this instance, the SIP 1329 server retargeting based on another locationValue MUST add the 1330 "used-for-routing" header parameter to the locationValue used for 1331 retargeting by this server. This will result in a Geolocation 1332 header looking as if it were retargeting more than once, which would 1333 be true - and is the desired outcome. 1335 5.3.2 Proxy Error Behavior with Geolocation-Error Codes 1337 If a proxy determines there is an error within an existing 1338 locationValue, the proxy SHOULD provide a suitable error response. 1339 The 424 (Bad Location Information) is the appropriate location-based 1340 error response here. The 424 MUST contain a Geolocation-Error 1341 header (see section 3.4). If a proxy errors a request for some 1342 other reason than location, and there is a location error also in 1343 the request, the Geolocation-Error (see section 3.4) SHOULD be added 1344 to the response, to inform the UAC of all the errors in the request. 1346 The proxy making the error decision copies the host-id value from 1347 the "inserted-by=" locationValue of the Geolocation header into the 1348 host-id value of the "inserter=" locationErrorValue of the 1349 Geolocation-Error header. This ensures the error is targeted at the 1350 entity that inserted the bad location. More than one error can be 1351 present for each locationValue. These error are in the 1352 locationErrorValue of the response. Each locationErrorValue will 1353 have one "inserter=" value. Thus, the number of locationErrorValues 1354 in a response cannot exceed the number of locationValues in the 1355 request - all within the same transaction. This ensures each error 1356 type is received properly by the offending location inserter. 1358 6. Geopriv Privacy Considerations 1360 Transmitting location information is considered by most to be highly 1361 sensitive information, requiring protection from eavesdropping, 1362 tracking, and altering in transit. [RFC3693] articulates rules to 1363 be followed by any protocol wishing to be considered a Geopriv 1364 "Using Protocol", specifying how a transport protocol meetings 1365 those rules. This section describes how SIP as a Using Protocol 1366 meets those requirements. 1368 Quoting requirement #4 of [RFC3693]: 1370 "The Using Protocol has to obey the privacy and security 1371 instructions coded in the Location Object and in the 1372 corresponding Rules regarding the transmission and storage 1373 of the LO." 1375 This document requires that SIP entities sending or receiving 1376 location MUST obey such instructions. 1378 Quoting requirement #5 of [RFC3693]: 1380 "The Using Protocol will typically facilitate that the keys 1381 associated with the credentials are transported to the 1382 respective parties, that is, key establishment is the 1383 responsibility of the Using Protocol." 1385 [RFC3261] and the documents it references define the key 1386 establishment mechanisms. 1388 Quoting requirement #6 of [RFC3693]: 1390 "(Single Message Transfer) In particular, for tracking of 1391 small Target devices, the design should allow a single 1392 message/packet transmission of location as a complete 1393 transaction." 1395 When used for tracking, a simple NOTIFY or UPDATE normally is 1396 relatively small, although the PIDF itself can get large. Normal 1397 RFC 3261 procedures of reverting to TCP when the MTU size is 1398 exceeded would be invoked. 1400 7. Security Considerations 1402 Conveyance of physical location of a UAC raises privacy concerns, 1403 and depending on use, there probably will be authentication and 1404 integrity concerns. This document calls for conveyance to normally 1405 be accomplished through secure mechanisms, like S/MIME protecting 1406 message bodies (but this is not widely deployed) or TLS protecting 1407 the overall signaling. In cases where a session set-up is 1408 retargeted based on the location of the UAC initiating the call or 1409 SIP MESSAGE, securing the by-value location with an end-to-end 1410 mechanism such as S/MIME is problematic, because one or more proxies 1411 on the path need the ability to read the location information to 1412 retarget the message to the appropriate new destination UAS. 1413 Securing the location hop-by-hop, using TLS, protects the message 1414 from eavesdropping and modification, but exposes the information to 1415 all proxies on the path as well as the endpoint. In most cases, the 1416 UAC does not know the identity of the proxy or proxies providing 1417 location-based routing services, so that end-to-middle solutions 1418 might not be appropriate either. 1420 These same issue exist for basic SIP signaling, but SIP normally 1421 does not carry information to physically track a user; making this 1422 extension especially sensitive, unfortunately. 1424 When location is inserted by a UAC, which is RECOMMENDED, it can 1425 decide whether to reveal its location using hop-by-hop methods. UAC 1426 implementations MUST make such capabilities conditional on explicit 1427 user permission, and SHOULD alert a user that location is being 1428 conveyed. Proxies inserting location for location-based routing are 1429 unable to meet this requirement, and such use is NOT RECOMMENDED. 1430 Proxies conveying location using this extension MUST have the 1431 permission of the Target to do so. 1433 One facet within this extension is such that locations can be placed 1434 on a remote server, accessible with the possession of a URI. The 1435 concept of a location-by-reference URI has its own security 1436 considerations. It is tempting to assume that the dereference would 1437 have authentication, authorization and other security mechanisms 1438 that limit the access to information. Unfortunately, this might not 1439 be true. The access network the UAC is connected to can be the 1440 source of location reference, and it might not have any 1441 credentialing mechanism suitable for controlling access to location. 1442 Consider, specifically, a nomadic user connected to an access 1443 network in a hotel. The UAC has no way to provide a credential 1444 acceptable to the hotel Location Server (LS) to any of its intended 1445 Location Recipients. The recipient of a reference does not know if 1446 a reference has appropriate authorization policies or not. The LS 1447 should provide location to any requestor. 1449 Accordingly, possession of the reference should be considered 1450 equivalent to possession of the value, and the reference should be 1451 treated with the same degree of care as the value. Specifically, 1452 TLS MUST be used to protect the security of the reference. 1454 Because SIP servers can add location in transit, made more easy of 1455 the server is a Session Border Controller or B2BUA, this might cause 1456 there to be conflicting location information (error-code=6), which 1457 could be purposeful to error the request or just cause operation 1458 problems. This problem might be inadvertent, compounded by the fact 1459 that there will likely be some SIP servers that add location on 1460 every call set-up. 1462 There is no integrity on any locationValue or locationErrorValue 1463 header parameter, so recipients of either header need to implicitly 1464 trust the header contents, and take whatever precautions each entity 1465 deems appropriate give these facts. 1467 8. IANA Considerations 1469 The following are the IANA considerations made by this SIP 1470 extension. Modifications and additions to these registrations 1471 require a standards track RFC. 1473 8.1 IANA Registration for the SIP Geolocation Header 1475 The SIP Geolocation header is created by this document, with its 1476 definition and rules in Section 3.2 of this document, to be added to 1477 the sip-parameters. 1479 The Geolocation Header has the following header parameters to be 1480 Registered in a new table: 1482 Geolocation Header parameters 1484 Header Parameters Parameter-values Reference 1485 ---------------- ---------------- -------------- 1486 inserted-by (string) RFC XXXX (this document) 1487 used-for-routing N/A RFC XXXX (this document) 1488 recipient endpoint RFC XXXX (this document) 1489 recipient routing-entity RFC XXXX (this document) 1490 recipient both RFC XXXX (this document) 1492 8.2 IANA Registration for New SIP Option Tag 1494 The SIP option-tag "geolocation" is created by this document, with 1495 the definition and rule in Section 3.5 of this document, to be added 1496 to sip-parameters within IANA. 1498 8.3 IANA Registration for Response Code 424 1500 Reference: RFC-XXXX (i.e., this document) 1501 Response code: 424 (recommended number to assign) 1502 Default reason phrase: Bad Location Information 1504 This SIP Response code is defined in section 3.3 of this document. 1506 8.4 IANA Registration of New Geolocation-Error Header 1508 The SIP Geolocation-error header is created by this document, with 1509 its definition and rules in Section 3.4 of this document, to be 1510 added to the sip-parameters. 1512 8.5 IANA Registration for the SIP Geolocation-Error Codes 1514 New location specific Geolocation-Error codes are created by this 1515 document, and registered in a new table at sip-parameters within 1516 IANA. Details of these error codes are in Section 3.4 of this 1517 document. 1519 Geolocation-Error codes 1520 ----------------------- 1521 Geolocation-Error codes provide reason for the error discovered by 1522 Location Recipients, to place into SIP response messages to inform 1523 the location inserter of the error. 1525 Code Description Reference 1526 ---- --------------------------------------------------- --------- 1527 1 Location Format Not Supported: the location format [this doc] 1528 supplied in the request, by-value or by-reference, 1529 was not supported. 1531 2 Coordinate-location Format Desired: the location [this doc] 1532 format supplied in the request was understood 1533 and supported, but that the recipient, or an 1534 application on the recipient, can or prefers to 1535 only process location in the coordinate-location 1536 format. 1538 3 Civic-location Format Desired: the location [this doc] 1539 format supplied in the request was understood 1540 and supported, but that the recipient, or an 1541 application on the recipient, can or prefers to 1542 only process location in the civic-location 1543 format. 1545 4 Cannot Parse Location Supplied: the location [this doc] 1546 provided, whether by-value or by-reference, in a 1547 request is not well formed. 1549 5 Cannot Find Location: the location was expected in [this doc] 1550 the request, but the recipient cannot find it. 1552 6 Conflicting Locations Supplied: a Location Recipient [this doc] 1553 received more than one location describing where the 1554 Target is, and is either unsure which whole location 1555 is true or which parts of multiple locations make up 1556 where the Target is. 1558 7 Incomplete Location Supplied: there is not enough [this doc] 1559 location information in the request to determine 1560 where the location Target is. 1562 8 Cannot Dereference: the act of dereferencing failed [this doc] 1563 to return the Target's location. This generally 1564 means the supplied URI is bad. 1566 9 Dereference Denied: there was insufficient [this doc] 1567 authorization to dereference the Target's location. 1569 10 Dereference Timeout: the dereferencing node has not [this doc] 1570 received the Target's location within a reasonable. 1572 timeframe 1574 11 Cannot Process Dereference: the dereference protocol [this doc] 1575 has received an overload condition error, indicating 1576 the location cannot be accessed at this time. 1578 20 Unsupported Scheme - sip desired: the location [this doc] 1579 dereferencer cannot dereference using the 1580 location-by-reference URI scheme supplied, and 1581 prefers a sip-uri. 1583 21 Unsupported Scheme - sips desired: the location [this doc] 1584 dereferencer cannot dereference using the 1585 location-by-reference URI scheme supplied, and 1586 prefers a sips-uri. 1588 22 Unsupported Scheme - pres desired: the location [this doc] 1589 dereferencer cannot dereference using the 1590 location-by-reference URI scheme supplied, and 1591 prefers a pres-uri. 1593 9. Acknowledgements 1595 To Dave Oran for helping to shape this idea. To Jon Peterson and 1596 Dean Willis on guidance of the effort. To Allison Mankin, Dick 1597 Knight, Hannes Tschofenig, Henning Schulzrinne, James Winterbottom, 1598 Jeroen van Bemmel, Jean-Francois Mule, Jonathan Rosenberg, Keith 1599 Drage, Marc Linsner, Martin Thomson, Mike Hammer, Paul Kyzivat, 1600 Shida Shubert, Umesh Sharma, Richard Barnes, Ted Hardie, Robert 1601 Sparks and Matt Lepinski for constructive feedback. A special 1602 thanks to Dan Wing for help with the S/MIME example. 1604 10. References 1606 10.1 References - Normative 1608 [RFC3261] J. Rosenberg, H. Schulzrinne, G. Camarillo, A. Johnston, J. 1609 Peterson, R. Sparks, M. Handley, and E. Schooler, "SIP: 1610 Session Initiation Protocol", RFC 3261, May 2002. 1612 [RFC4119] J. Peterson, "A Presence-based GEOPRIV Location Object 1613 Format", RFC 4119, December 2005 1615 [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate 1616 Requirement Levels", RFC 2119, March 1997 1618 [RFC2392] E. Levinson, " Content-ID and Message-ID Uniform Resource 1619 Locators", RFC 2393, August 1998 1621 [RFC3863] H. Sugano, S. Fujimoto, G. Klyne, A. Bateman, W. Carr, J. 1623 Peterson, "Presence Information Data Format (PIDF)", RFC 1624 3863, August 2004 1626 [RFC3856] J. Rosenberg, " A Presence Event Package for the Session 1627 Initiation Protocol (SIP)", RFC 3856, August 2004 1629 [RFC3859] J. Peterson, "Common Profile for Presence (CPP)", RFC 3859, 1630 August 2004 1632 [RFC3428] B. Campbell, Ed., J. Rosenberg, H. Schulzrinne, C. Huitema, 1633 D. Gurle, "Session Initiation Protocol (SIP) Extension for 1634 Instant Messaging" , RFC 3428, December 2002 1636 [RFC3311] J. Rosenberg, "The Session Initiation Protocol (SIP) UPDATE 1637 Method", RFC 3311, October 2002 1639 [RFC3265] Roach, A., "Session Initiation Protocol (SIP)-Specific 1640 Event Notification", RFC 3265, June 2002. 1642 10.2 References - Informative 1644 [RFC3693] J. Cuellar, J. Morris, D. Mulligan, J. Peterson. J. Polk, 1645 "Geopriv Requirements", RFC 3693, February 2004 1647 [RFC3825] J. Polk, J. Schnizlein, M. Linsner, "Dynamic Host 1648 Configuration Protocol Option for Coordinate-based Location 1649 Configuration Information", RFC 3825, July 2004 1651 [RFC4776] H. Schulzrinne, " Dynamic Host Configuration Protocol 1652 (DHCPv4 and DHCPv6) Option for Civic Addresses Configuration 1653 Information ", draft-ietf-geopriv-dhcp-civil-09, "work in 1654 progress", January 2006 1656 Author Information 1658 James Polk 1659 Cisco Systems 1660 3913 Treemont Circle 33.00111N 1661 Colleyville, Texas 76034 96.68142W 1663 Phone: +1-817-271-3552 1664 Email: jmpolk@cisco.com 1666 Brian Rosen 1667 NeuStar, Inc. 1668 470 Conrad Dr. 40.70497N 1669 Mars, PA 16046 80.01252W 1670 US 1671 Phone: +1 724 382 1051 1672 Email: br@brianrosen.net 1674 Appendix A. Requirements for SIP Location Conveyance 1676 The following subsections address the requirements placed on the 1677 UAC, the UAS, as well as SIP proxies when conveying location. There 1678 is a motivational statement below each requirements that is not 1679 obvious in intent 1681 A.1 Requirements for a UAC Conveying Location 1683 UAC-1 The SIP INVITE Method [RFC3261] must support location 1684 conveyance. 1686 UAC-2 The SIP MESSAGE method [RFC3428] must support location 1687 conveyance. 1689 UAC-3 SIP Requests within a dialog should support location 1690 conveyance. 1692 UAC-4 Other SIP Requests may support location conveyance. 1694 UAC-5 There must be one, mandatory to implement means of 1695 transmitting location confidentially. 1697 Motivation: interoperability 1699 UAC-6 It must be possible for a UAC to update location conveyed 1700 at any time in a dialog, including during dialog 1701 establishment. 1703 Motivation: in case a UAC has moved prior to the establishment of a 1704 dialog between UAs, the UAC must be able to send new location 1705 information. In the case of location having been conveyed, 1706 and the UA moves, it needs a means to update the conveyed to 1707 party of this location change. 1709 UAC-7 The privacy and security rules established within [RFC3693] 1710 that would categorize SIP as a 'Using Protocol' must be met. 1712 UAC-8 The PIDF-LO [RFC 4119] is a mandatory to implement format for 1713 location conveyance within SIP, whether included by-value or 1714 by-reference. 1716 Motivation: interoperability with other IETF location protocols and 1717 mechanisms 1719 UAC-9 There must be a mechanism for the UAC to request the UAS send 1720 its location 1722 UAC-10 There must be a mechanism to differentiate the ability of the 1723 UAC to convey location from the UACs lack of knowledge of its 1724 location 1726 Motivation: Failure to receive location when it is expected can be 1727 because the UAC does not implement this extension, or it can 1728 be that the UAC implements the extension, but does not know 1729 where it is. This may be, for example, due to the failure of 1730 the access network to provide a location acquisition 1731 mechanisms the UAC understands. These cases must be 1732 differentiated. 1734 UAC-11 It must be possible to convey location to proxy servers 1735 along the path. 1737 Motivation: Location-based routing. 1739 A.2 Requirements for a UAS Receiving Location 1741 The following are the requirements for location conveyance by a UAS: 1743 UAS-1 SIP Responses must support location conveyance. 1745 UAS-2 There must be a unique 4XX response informing the UAC it did 1746 not provide applicable location information. 1748 In addition, requirements UAC-5, 6, 7 and 8 apply to the UAS 1750 A.3 Requirements for SIP Proxies and Intermediaries 1752 The following are the requirements for location conveyance by a SIP 1753 proxies and intermediaries: 1755 Proxy-1 Proxy servers must be capable of adding a Location header 1756 field during processing of SIP requests. 1758 Motivation: Provide the capability of network assertion of location 1759 when UACs are unable to do so, or when network assertion is 1760 more reliable than UAC assertion of location 1762 Note: Because UACs connected to sip signaling networks may have 1763 widely varying access network arrangements, including VPN 1764 tunnels and roaming mechanisms, it may be difficult for a 1765 network to reliably know the location of the endpoint. Proxy 1766 assertion of location is NOT RECOMMENDED unless the sip 1767 signaling network has reliable knowledge of the actual 1768 location of the Targets. 1770 Proxy-2 There must be a unique 4XX response informing the UAC it 1771 did not provide applicable location information. 1773 Appendix B. Example of INVITE with S/MIME encrypted Civic PIDF-LO 1775 This appendix gives an *EXAMPLE* (meaning this might contain errors 1776 based on future review) of a SIP INVITE request that points to the 1777 same position on the earth as the coordinate based example that's in 1778 section 4.1 in the body of this document: 1780 The INVITE request is TLS hop-by-hop encrypted, and the 1781 location-by-value message body is S/MIME encrypted. This example 1782 shows the location message body in its unencrypted form for clarity. 1783 The message body lines below that have the '$' signs are S/MIME 1784 encrypted. In this example, the SDP is not S/MIME encrypted. 1786 INVITE sips:bob@biloxi.example.com SIP/2.0 1787 Via: SIP/2.0/TLS pc33.atlanta.example.com 1788 ;branch=z9hG4bK74bf9 1789 Max-Forwards: 70 1790 To: Bob 1791 From: Alice ;tag=9fxced76sl 1792 Call-ID: 3848276298220188511@atlanta.example.com 1793 Geolocation: 1794 ;inserted-by=alice@atlanta.example.com ;recipient=endpoint 1795 Supported: geolocation 1796 Accept: application/sdp, application/pidf+xml 1797 CSeq: 31862 INVITE 1798 Contact: 1799 Content-Type: multipart/mixed; boundary=boundary1 1800 Content-Length: ... 1802 --boundary1 1804 Content-Type: application/sdp 1806 ...SDP goes here 1808 --boundary1 1810 Content-Type: application/pkcs7-mime; 1811 smime-type=enveloped-data; name=smime.p7m 1812 Content-ID: alice123@atlanta.example.com 1814 $ Content-Type: application/pidf+xml 1815 $ 1816 $ 1817 $ 1821 $ 1822 $ 2007-07-09T14:00:00Z 1823 $ 1824 $ 1825 $ 1826 $ 1827 $ US 1828 $ Texas 1829 $ Colleyville 1830 $ 3913 1831 $ Treemont 1832 $ Circle 1833 $ 76034 1834 $ Haley's Place 1835 $ 1 1836 $ 1837 $ 1838 $ 1839 $ no 1840 $ 2007-07-27T18:00:00Z 1842 $ 1843 $ DHCP 1844 $ www.example.com 1845 $ 1846 $ 1847 $ 1848 $ 1849 --boundary1-- 1851 Full Copyright Statement 1853 Copyright (C) The IETF Trust (2007). 1855 This document is subject to the rights, licenses and restrictions 1856 contained in BCP 78, and except as set forth therein, the authors 1857 retain all their rights. 1859 This document and the information contained herein are provided on an 1860 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1861 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1862 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1863 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1864 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1865 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1867 Intellectual Property 1869 The IETF takes no position regarding the validity or scope of any 1870 Intellectual Property Rights or other rights that might be claimed to 1871 pertain to the implementation or use of the technology described in 1872 this document or the extent to which any license under such rights 1873 might or might not be available; nor does it represent that it has 1874 made any independent effort to identify any such rights. Information 1875 on the procedures with respect to rights in RFC documents can be 1876 found in BCP 78 and BCP 79. 1878 Copies of IPR disclosures made to the IETF Secretariat and any 1879 assurances of licenses to be made available, or the result of an 1880 attempt made to obtain a general license or permission for the use of 1881 such proprietary rights by implementers or users of this 1882 specification can be obtained from the IETF on-line IPR repository at 1883 http://www.ietf.org/ipr. 1885 The IETF invites any interested party to bring to its attention any 1886 copyrights, patents or patent applications, or other proprietary 1887 rights that may cover technology that may be required to implement 1888 this standard. Please address the information to the IETF at 1889 ietf-ipr@ietf.org. 1891 Acknowledgment 1893 Funding for the RFC Editor function is provided by the IETF 1894 Administrative Support Activity (IASA).