idnits 2.17.1 draft-ietf-sip-location-conveyance-04.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 on line 1307. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1284. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1291. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1297. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == It seems as if not all pages are separated by form feeds - found 0 form feeds but 27 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 273 has weird spacing: '... Rr ar ...' == Line 277 has weird spacing: '... Rr ar ...' == The document seems to use 'NOT RECOMMENDED' as an RFC 2119 keyword, but does not include the phrase in its RFC 2119 key words list. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC3851' is mentioned on line 375, but not defined ** Obsolete undefined reference: RFC 3851 (Obsoleted by RFC 5751) ** Downref: Normative reference to an Informational RFC: RFC 3693 ** Obsolete normative reference: RFC 2393 (ref. 'RFC2392') (Obsoleted by RFC 3173) ** Obsolete normative reference: RFC 3265 (Obsoleted by RFC 6665) -- Obsolete informational reference (is this intentional?): RFC 3825 (Obsoleted by RFC 6225) Summary: 7 errors (**), 0 flaws (~~), 7 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SIP Working Group James Polk 3 Internet Draft Cisco Systems 4 Expiration: March 1st, 2007 Brian Rosen 5 NeuStar 7 Session Initiation Protocol Location Conveyance 8 draft-ietf-sip-location-conveyance-04.txt 9 Sept 1st, 2006 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 March 1st, 2007. 37 Copyright Notice 39 Copyright (C) The Internet Society (2006). 41 Abstract 43 This document defines an extension to the Session Initiation 44 Protocol (SIP) to convey geographic location information from one 45 SIP entity to another SIP entity. The extension covers end to end 46 conveyance as well as location-based routing, where proxy servers 47 make routing decisions based on the location of the UAC. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 52 2. Conventions used in this document . . . . . . . . . . . . . . 4 53 3. Mechanisms . . . . . . . . . . . . . . . . . . . . . . . . . 4 54 3.1 Overview of SIP Location Conveyance . . . . . . . . . . . 4 55 3.2 The Geolocation Header . . . . . . . . . . . . . . . . . 5 56 3.3 424 (Bad Location Information) Response Code . . . . . . 6 57 3.4 The Geolocation Reason Protocol . . . . . . . . . . . . . 7 58 3.5 The Geolocation Option Tag . . . . . . . . . . . . . . . 7 59 3.6 'routing-query-allowed' Element in PIDF-LO . . . . . . . 8 60 3.7 Using sip/sips/pres as a Dereference Protocol . . . . . . 8 61 4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 8 62 4.1 Location-by-value (Coordinate Format) . . . . . . . . . . 9 63 4.2 Location-by-value (Civic Format) . . . . . . . . . . . . 10 64 4.3 Location-by-reference . . . . . . . . . . . . . . . . . . 12 65 5. SIP Element Behavior . . . . . . . . . . . . . . . . . . . . 12 66 5.1 UAC Behavior . . . . . . . . . . . . . . . . . . . . . . 13 67 5.2 UAS Behavior . . . . . . . . . . . . . . . . . . . . . . 14 68 5.3 Proxy Behavior . . . . . . . . . . . . . . . . . . . . . 14 69 6. Special Considerations for Emergency Calls . . . . . . . . . 15 70 7. Geopriv Privacy Considerations . . . . . . . . . . . . . . . 15 71 8. Security Considerations . . . . . . . . . . . . . . . . . . . 16 72 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . 17 73 9.1 IANA Registration for New SIP Geolocation Header . . . . 17 74 9.2 IANA Registration for New SIP Geolocation Option Tag . . 17 75 9.3 IANA Registration for New 4XX Response Code . . . . . . . 17 76 9.4 IANA Registration of the Geolocation Reason Protocol . . 17 77 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17 78 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 79 11.1 Normative References . . . . . . . . . . . . . . . . . 18 80 11.2 Informative References . . . . . . . . . . . . . . . . . 18 81 Author Information . . . . . . . . . . . . . . . . . . . . . 19 82 Appendix A. Changes from Prior Versions . . . . . . . . . . 19 83 Appendix B. Requirements for SIP Location Conveyance . . . . 21 84 Intellectual Property and Copyright Statements . . . . . . . 26 86 1. Introduction 88 This document describes how Location can be "conveyed" (that is, 89 sent on the Internet) from a SIP user agent, or in some 90 circumstances a proxy server acting on behalf of a user agent, to 91 another entity using the SIP [RFC3261] protocol. Here "Location" is 92 a description of the physical geographical area where a User Agent 93 currently exists. We use the term "conveyance" to distinguish other 94 circumstances when a location is used such as how the entity 95 conveying location using this extension determined where the 96 location was (using, for example, an Assisted GPS mechanism) or a 97 protocol by which the entity acquired the location it is conveying 98 from another entity. 100 Geographic location in the IETF is discussed in RFC 3693 (Geopriv 101 Requirements) [RFC3693]. It defines a "target" as the entity whose 102 location is being transmitted, in this case, it is the user agent's 103 (UA) location. A [RFC3693] "using protocol" defines how a "location 104 server" transmits a "location object" to a "location recipient" 105 while maintaining the contained privacy intentions of the target 106 intact. This document describes the extension to SIP for how it 107 complies with the using protocol requirements, where the location 108 server is a User Agent or Proxy Server and the location recipient is 109 another User Agent or Proxy Server. 111 Location can be transmitted by-value or by-reference. The "value" 112 used in this document is a location object as described in 113 [RFC4119], that is, a PIDF-LO. Location-by-value refers to a user 114 agent including a PIDF-LO as a body part of a SIP message, sending 115 that location object to another SIP element. Location-by-reference 116 refers to a user agent or proxy server including a URI in a SIP 117 message which can be exchanged by a location recipient for a 118 location object, in the form of a PIDF-LO. 120 As recited in RFC3693, location often must be kept private. The 121 location object (PIDF-LO) contains rules which are binding on the 122 location recipient and controls onward distribution and retention of 123 the location. This document describes the security and privacy 124 considerations that must be applied to location conveyed with SIP. 126 Often, location is sent from the User Agent Client to the User Agent 127 Server, or vice versa for purposes that are beyond the scope of this 128 document. Another use for location is location-based routing of a 129 SIP request, where the choice of the next hop (and usually, the 130 outgoing Request URI) is determined by the location of the UAC which 131 is in the message by-value or by-reference. This document describes 132 how location may be conveyed from the UAC, or a proxy acting on its 133 behalf, to a routing proxy. How the location is actually used to 134 determine the next hop or Request-URI is beyond the scope of this 135 document. 137 The Geolocation header is introduced to signify that location is 138 included in a SIP message to provide either a content identifier 139 (cid:) pointer to the body part containing the UAs PIDF-LO, or a 140 location-by-reference URI that may subsequently be "dereferenced" by 141 a using protocol (which may be SIP or another protocol). 143 In this document, we frequently refer to the "emergency case". This 144 refers to a specific, important use of sip location conveyance where 145 the location of the caller is used to determine which Public Safety 146 Answering Point (PSAP) should receive an emergency call request for 147 help (e.g. a call to 1-1-2 or 9-1-1). This is an example of 148 location-based routing. The location conveyed is also used by the 149 PSAP to dispatch first responders to the caller's location. There 150 are special security considerations which make the emergency case 151 unique, compared to a normal location conveyance within SIP. 153 2. Conventions used in this document 155 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 156 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and 157 "OPTIONAL" in this document are to be interpreted as described 158 in [RFC2119]. 160 3. Mechanisms 162 3.1 Overview of SIP Location Conveyance 164 This document creates a new SIP header: Geolocation. The 165 Geolocation header contains either a URI which may be a "cid:" URI 166 (Content Identification, per [RFC2392], or a location-by-reference 167 URI to be dereferenced by a location recipient to retrieve the 168 location of the UAC. 170 Where the Geolocation header contains a "cid:", the URI points to a 171 message body that is in the form of a PIDF [RFC3863], which was 172 extended in [RFC4119] to include location, as a PIDF-LO. This is 173 location-by-value, the actual location information in the PIDF-LO is 174 included in the body of the message. 176 If the URI in the Geolocation header is a scheme other than "cid:", 177 another protocol operation is needed by the message recipient to 178 obtain the location of the target (UA). This is 179 location-by-reference. This document describes how a SIP presence 180 subscription [RFC3856] can be used as a dereference protocol. 182 The Geolocation header, either with the PIDF-LO in a body or as a 183 location-by-reference URI, may be included by a User Agent in a 184 message. A proxy server may assert location of the UA by inserting 185 the header, which must specify a location-by-reference URI. Since 186 body parts may not be inserted by a proxy server, location-by-value 187 cannot be inserted by a proxy. 189 This document describes an extension to PIDF-LO, the 190 "routing-query-allowed" element, defined in the 'usage-rules' 191 element. When set, this allows an element receiving location to 192 transmit the location to another element to obtain routing 193 information. When used in conjunction with the 194 "retransmission-allowed" element, the rule maker can control 195 distribution of the location information for location-based routing. 197 This document also creates a new option tag: Geolocation, to 198 indicate support for the Geolocation extension. A new error message 199 (424 Bad Location Information) is also defined in this document. 201 3.2 The Geolocation Header 203 This document creates and IANA registers a new SIP header: 204 Geolocation. The Geolocation header MUST contain one two types of 205 URIs: 207 o a location-by-reference URI, or 209 o a content-ID indicating where location is within the message body 210 of this message 212 A location-by-reference URI is a pointer to a record on a remote 213 node containing location of the location target, typically the 214 UA in this transaction. 216 A location-by-value content-ID (cid-url) [RFC2392] indicates which 217 message body part contains location for this UA. 219 The Geolocation header has the following BNF syntax: 221 Geolocation = "Geolocation" HCOLON (locationURI *(COMMA 222 locationURI)) 223 locationURI = sip-URI / sips-URI / pres-URI / cidURI 224 / absoluteURI 225 cidURI = "cid:" content-id 227 content-id = addr-spec ; URL encoding of RFC3261 addr-spec 229 The content-ID (cid:) is defined in [RFC2392] to locate message body 230 parts. This URI MUST be present if location is by-value in a 231 message. 233 sip-URI, sips-URI and absoluteURI are defined according to RFC3261. 234 The pres-URI is defined in RFC 3859 [RFC3859]. 236 Other protocols used in the Location URI MUST be reviewed against 237 the RFC3693 criteria for a using protocol. 239 [Editor's Note: The topic of how to control which protocols are 240 allowed in the URI is still contentious. There does seem to be 241 consensus to have the ABNF syntax not restrict the scheme of the 242 dereferencing protocol. This ABNF conforms with how similar 243 extensions are expressed in ABNF in RFC3261: the protocol's use 244 defined by the document is included explicitly, and an "open" (e.g. 245 absoluteURI) is included to allow any future protocol without 246 changing (i.e. updating) the ABNF, for example, in this document. 248 The text currently explicitly requires a Geopriv review of a new 249 proposed dereferencing protocol. This text is still subject to 250 consensus discussions and represents what we believe the direction 251 currently expressed by commenters.] 253 This document defines the Geolocation header as valid in: 255 INVITE [RFC3261], 256 REGISTER [RFC3261], 257 OPTIONS [RFC3261], 258 UPDATE [RFC3311], 259 MESSAGE [RFC3428], 260 SUBSCRIBE [RFC3265], and 261 NOTIFY [RFC3265] 263 Use of the header in BYE, INFO and REFER Methods is allowed, 264 although no purpose is known. Conveying location in a CANCEL, BYE, 265 ACK or PRACK is not defined. Discussing location using the PUBLISH 266 Request Method out of scope for this document. 268 The following table extends the values in Table 2&3 of RFC3261 269 [RFC3261]. 271 Header field where proxy INV ACK CAN BYE REG OPT PRA 272 ---------------------------------------------------------------- 273 Geolocation Rr ar o - - o o o - 275 Header field where proxy SUB NOT UPD MSG REF INF PUB 276 ---------------------------------------------------------------- 277 Geolocation Rr ar o o o o o o - 279 Table 1: Summary of the Geolocation Header 281 The Geolocation header MAY be included in one of the above messages 282 by a User Agent. A proxy MAY add the Geolocation header, but MUST 283 NOT modify the contents of an existing Geolocation header. 284 [RFC3261] states message bodies cannot be added by proxies. 285 Therefore, a Geolocation header added by a proxy MUST specify 286 location-by-reference. 288 It is RECOMMENDED that only one Geolocation header (i.e. header 289 value) be in the same message. There MUST NOT be more than one 290 cid-url pointing to the same location message body (part) in a SIP 291 message. 293 Entities receiving location information MUST honor the usage element 294 rules per RFC4119. Such entities MUST NOT alter the rule set. 296 3.3 424 (Bad Location Information) Response Code 298 If a UAS or SIP intermediary detects an error 299 in a request message specific to the location information supplied 300 by-value or by-reference, a new 4XX level error is created here to 301 indicate a problem with the request message. This 302 document creates and IANA registers the new error code: 304 424 (Bad Location Information) 306 The 424 (Bad Location Information) response code is a rejection of 307 the location contents, within the original SIP Request. If the 308 location was sent by-value, the error indicates the location 309 information was malformed or not satisfactory for the recipient's 310 purpose. If the location was sent by-reference, the error indicates 311 that location could not be obtained using the URI. No further 312 action by the UAC is required. The UAC can use whatever means it 313 knows of to verify/refresh its location information before 314 attempting a new request that includes location. There is no 315 cross-transaction awareness expected by either the UAS or SIP 316 intermediary as a result of this error message. 318 This new error code will be IANA registered in Section 9. 320 More resolution of the error for which the 424 was generated MAY be 321 included in a Reason header [RFC3326]. For these more granular 322 location specific errors, the 'protocol' in the Reason header is 323 'Geolocation', defined in Section 3.4. RFC3326 states that the 324 Reason Header normally is not found in a response. This document 325 extends the use of Reason to include its use within a 424 response. 327 3.4 The Geolocation Reason Protocol 329 For use with the Reason header, this document defines and IANA 330 registers a new Reason Protocol per RFC3326: 332 Protocol Value Protocol Cause Reference 333 Geolocation Status RFCyyyy (i.e. this document) 335 Ed. Note: It has been agreed that Geopriv will create a new IANA 336 registry for the reason code. 338 3.5 The Geolocation Option Tag 340 This document creates and IANA registers one new option tag: 341 "geolocation". This option tag is to be used, per RFC 3261, in the 342 Require, Supported and Unsupported headers. Whenever a UA wants to 343 indicate it understands this SIP extension, the geolocation option 344 tag is included in a Supported header of the SIP message. 346 The purpose of the geolocation option-tag is to indicate support for 347 this extension in the Supported and Unsupported headers. Appearance 348 of the option tag in the Require header is a request for location to 349 be conveyed. 351 A UAC MUST NOT include this option tag in a Proxy-Require header, 352 due to the fact that the UAC is not likely to understand the 353 topology of the infrastructure, and therefore does not understand 354 which proxy will do the location-based routing function. 356 3.6 'routing-query-allowed' element in PIDF-LO 358 This document extends the 'usage-rules' element of RFC4119 to 359 include a new element, 'routing-query-allowed'. When 360 'routing-query-allowed' is set, the receiving element MAY forward 361 the location information to another element to obtain routing 362 information, even if 'retransmission-allowed' value is 'no'. By 363 default, the value MUST be assumed to be 'no' 365 The locPolicyType is extended to define this new element after 366 'note-well': 368 371 3.7 Using sip/sips/pres as a Dereference Protocol 373 A sip, sips or pres URI SHOULD be included in a Geolocation header 374 for the location-by-reference URI. When pres: is used, if the 375 resulting resolution, per [RFC3851], resolves to a sip: or sips: 376 URI, this section applies. Use of other protocols for dereferencing 377 of a pres: URI is not defined, and such use is subject to review 378 against RFC3693 using protocol criteria. 380 Dereferencing using sip or sips MUST be accomplished by treating the 381 URI as a presence URI and dereferencing is accomplished by a 382 SUBSCRIBE to a presence service per [RFC3856]. The resulting NOTIFY 383 will contain a PIDF, which MUST contain a PIDF-LO. 385 When used in this manner, SIP is a using protocol per [RFC3693] and 386 elements receiving location MUST honor the 'usage-element' rules as 387 defined in Section 3.4 above. 389 A dereference of a location-by-reference URI using SUBSCRIBE is not 390 violating a PIDF-LO 'retransmission-allowed' element value set to 391 'no', as the NOTIFY is the only message in this multi-message series 392 of transactions that contains the UAC's location, with the location 393 recipient being the only SIP element to receive location - which the 394 purpose of this extension: to convey location to a specific 395 destination. 397 4. Examples 399 Three examples of messages providing location are provided. One 400 shows location-by-value with geo-coordinates, one shows 401 location-by-value with civic location and the third shows 402 location-by-reference. The examples for (Geo format) are taken 403 from [RFC3825] and (Civic format) are taken from [ID-CIVIC] and are 404 for the exact same position on the Earth. The differences between 405 the two formats is within the of the examples. 406 Other than this portion of each PIDF-LO, the rest is the same for 407 both location formats. 409 4.1 Location-by-value (Coordinate Format) 411 This example shows an INVITE message with a coordinate, or geo 412 location. In this example, the SIP request uses a sips-URI 413 [RFC3261], meaning this message is TLS protected on a hop-by-hop 414 basis all the way to Bob's domain. 416 INVITE sips:bob@biloxi.example.com SIP/2.0 417 Via: SIP/2.0/TLS pc33.atlanta.example.com 418 ;branch=z9hG4bK74bf9 419 Max-Forwards: 70 420 To: Bob 421 From: Alice ;tag=9fxced76sl 422 Call-ID: 3848276298220188511@atlanta.example.com 423 Geolocation: cid:alice123@atlanta.example.com 424 Supported: geolocation 425 Accept: application/sdp, application/pidf+xml 426 CSeq: 31862 INVITE 427 Contact: 428 Content-Type: multipart/mixed; boundary=boundary1 429 Content-Length: ... 431 --boundary1 433 Content-Type: application/sdp 435 ...SDP here 437 --boundary1 439 Content-Type: application/pidf+xml 440 Content-ID: alice123@atlanta.example.com 442 443 448 449 2006-03-20T14:00:00Z 450 451 452 453 454 455 33.001111N 456 96.68142W 458 459 460 461 462 no 463 2006-03-24T18:00:00Z 465 DHCP 466 www.cisco.com 467 468 469 470 471 472 --boundary1-- 474 The Geolocation header from the above INVITE... 476 Geolocation: cid:alice123@atlanta.example.com 478 ...indicates the content-ID location [RFC2392] within the multipart 479 message body of were location information is, with SDP being the 480 other message body part. 482 If the Geolocation header were this instead: 484 Geolocation: 486 ...this would indicate location by-reference was included in this 487 message. It is expected that any node wanting to know where user 488 alice123 is would subscribe to server5 to dereference the sips-URI. 489 The returning NOTIFY would contain Alice's location in a PIDF-LO, as 490 if it were included in a message body (part) of the original INVITE 491 here. 493 4.2 Location-by-value (Civic Format) 495 This example shows an INVITE message with a civic location. The 496 headers are shown as if the location was S/MIME encrypted, but the 497 unencrypted location information is shown for clarity. 499 INVITE sip:bob@biloxi.example.com SIP/2.0 500 Via: SIP/2.0/TCP pc33.atlanta.example.com 501 ;branch=z9hG4bK74bf9 502 Max-Forwards: 70 503 To: Bob 504 From: Alice ;tag=9fxced76sl 505 Call-ID: 3848276298220188511@atlanta.example.com 506 Geolocation: cid:alice123@atlanta.example.com 507 Supported: geolocation 508 Accept: application/sdp, application/pidf+xml 509 CSeq: 31862 INVITE 510 Contact: 511 Content-Type: multipart/mixed; boundary=boundary1 512 Content-Length: ... 514 --boundary1 516 Content-Type: application/sdp 518 ...SDP here 520 --boundary1 522 Content-Type: application/pkcs7-mime; 523 smime-type=enveloped-data; name=smime.p7m 524 ;the following would be encrypted, we show the unencrypted form here 525 526 531 532 2006-03-20T14:00:00Z 533 534 535 536 537 US 538 Texas 539 Colleyville 540 3913 541 Treemont 542 Circle 543 76034 544 Polk Place 545 1 546 547 548 549 no 550 2006-03-24T18:00:00Z 552 DHCP 553 www.cisco.com 554 555 556 557 558 559 --boundary1-- 561 4.3 Location-by-reference 563 Here is an example of an INVITE with a location-by-reference URI, 564 sips: in this case, instead of a location-by-value PIDF-LO message 565 body part shown in Sections 4.1 and 4.2. It is up to the location 566 recipient to dereference Alice's location at the Atlanta LIS. 568 INVITE sip:bob@biloxi.example.com SIP/2.0 569 Via: SIP/2.0/TCP pc33.atlanta.example.com 570 ;branch=z9hG4bK74bf9 571 Max-Forwards: 70 572 To: Bob 573 From: Alice ;tag=9fxced76sl 574 Call-ID: 3848276298220188511@atlanta.example.com 575 Geolocation: sips:3sdefrhy2jj7@lis.atlanta.com 576 Supported: geolocation 577 Accept: application/sdp, application/pidf+xml 578 CSeq: 31862 INVITE 579 Contact: 581 ...SDP goes here as the only message body 583 5. SIP Element Behavior 585 Because a person's location is generally considered to be sensitive 586 in nature, privacy of the location information must be protected 587 when transmitting such information. Section 26 of [RFC3261] defines 588 the security functionality SIPS for transporting SIP messages with 589 either TLS or IPSec, and S/MIME for encrypting message bodies from 590 SIP intermediaries that would otherwise have access to reading the 591 clear-text bodies. SIP endpoints SHOULD implement S/MIME to encrypt 592 the PIDF-LO message body (part) end-to-end when the intended 593 recipient is the opposite UA. The SIPS-URI from [RFC3261] MUST be 594 implemented for message protection (message integrity and 595 confidentiality) and SHOULD be used when S/MIME is not used. 596 Possession of a dereferenceable location URI may be equivalent to 597 possession of the location information itself and thus TLS SHOULD be 598 used when sending location-by-reference. 600 A PIDF includes identity information. It is possible for the 601 identity in the PIDF to be anonymous. Implementations of this 602 extension should consider the appropriateness of including an 603 anonymous identity in the location information where a real identity 604 is not required. When using location-by-reference, it is 605 RECOMMENDED that the URI not contain any identifying information 606 (for example use 3fg5t5yqw@example.com rather than 607 alice@example.com) 609 The entities receiving location MUST obey the privacy 610 and security rules in the PIDF-LO as described in RFC4119, regarding 611 retransmission and retention. 613 Self-signed certificates SHOULD NOT be used for protecting PIDF, 614 as the sender does not have a secure identity of the recipient. 616 More than one location representation or format, for example: civic 617 and geo, MAY be included in the same message body part, but all MUST 618 point at the same position on the earth. Multiple representations 619 allow the recipient to use the most convenient representation of 620 location. 622 There MAY be more than one PIDF-LO in the same SIP message, but each 623 in separate message body parts. Each location body part MAY point at 624 different 2D positions on the earth (altitude not withstanding). 625 The meaning of such a construction is not defined, and may cause 626 confusion at the recipient. 628 5.1 UAC Behavior 630 A UAC may send location because it was requested to, to facilitate 631 location-based routing, or spontaneously (i.e. a purpose not defined 632 in this document but known to the UAC). A UAC MAY receive location 633 from the UAS because it requested it, or because the UAS sent it 634 spontaneously. 636 A UAC conveying location MUST include a Geolocation header with 637 either a location by-value indication (a cid-URL), or a location 638 by-reference indication (a dereferencable URI). A location body 639 sent without a Geolocation header MUST NOT occur. The UAC 640 supporting this extension MUST include a Supported header with the 641 geolocation option tag. 643 The presence of the geolocation option tag in a Supported header 644 without a Geolocation header in the same message informs a receiving 645 SIP element the UAC understands the concept of location, but it does 646 not know its location at this time. Certain scenarios exist 647 (location-based routing) in which location is required in a message 648 in order to route the message properly. This affects how a UAS or 649 SIP server reacts to such a message. 651 This option tag SHOULD NOT be used in the Proxy-Require header. 653 If the UAC requests the location of the UAS, it MAY include the 654 option tag in the Require header of the request. 656 The behavior of the UAC receiving location is the same as the UAS, 657 as below. 659 5.2 UAS Behavior 661 If the geolocation option tag is present in the Supported header of 662 a request, the UAS will look to the Geolocation header to see if 663 location has been conveyed by-value in a message body (part) or 664 by-reference, requiring an additional dereference transaction. If 665 the by-reference URI is sip:, sips: or pres:, the UAS will initiate 666 a SUBSCRIBE to the URI provided to retrieve the PIDF-LO of the UAC 667 per [RFC3856]. If successful, the PIDF-LO of the UAC will be 668 returned in the NOTIFY request from the server. 670 A Require header with the geolocation option tag indicates that the 671 UAC requests the UAS' location. 673 The UAS behavior in sending location is the same as the UAS as 674 above. 676 5.3 Proxy Behavior 678 [RFC3261] states message bodies cannot be added by proxies. A 679 PIDF-LO MAY be read in transit, if visible to the proxy. A proxy 680 MAY add the Geolocation header in transit. A proxy MAY read the 681 Geolocation header in transit if present, and MAY use the contents 682 of the header to make location-based routing decisions. 684 More than one geolocation header in a message is permitted, but its 685 meaning is undefined. A proxy inserting a Geolocation header when 686 there already is one risks confusing the recipient and SHOULD NOT be 687 done. 689 Proxies receiving location where the proxy performs location-based 690 routing may need to consult external databases or systems to 691 determine the route. Transmission of the location information 692 (which SHOULD NOT reveal identity, even if the proxy knows the 693 identity) is governed by the 'retransmission-allowed' and 694 'routing-query-allowed': 696 Retransmission-allowed Routing-query-allowed Transmission for Query 697 ---------------------- --------------------- ---------------------- 698 "no" or not present "no" or not present Not Allowed 699 "no" or not present "yes" Allowed 700 "yes" not present Allowed 701 "yes" "no" Not Allowed 702 "yes" "yes" Allowed 704 If transmission is not allowed per the above, the proxy may provide 705 a suitable error response (424 Bad Location MAY be used). 707 6. Special Considerations for Emergency Calls 709 Emergency calls (1-1-2, 9-1-1, etc.) need location for two reasons: 711 1. Location is needed to route the call to the correct Public Safety 712 Answering Point (PSAP), and 714 2. Location is needed by the PSAP to send responders to the location 715 of the caller when the caller cannot accurately describe where 716 s/he is 718 While all of the privacy concerns for location apply to emergency 719 calls, it is not acceptable for a security mechanism in place to 720 support confidentiality of the location to cause an emergency call 721 to be misrouted, or not supply location when it is needed. 722 Therefore, some of the behaviors of elements in the path are 723 different when used with an emergency call. 725 Recognizing which calls are emergency calls is beyond the scope of 726 this document. When an emergency call is placed, location is 727 normally provided by the UAC. Since emergency calls must be routed 728 based on location (and indeed, in some jurisdictions, there may be 729 several steps to such routing), the location must be visible to 730 proxies along the path. Thus S/MIME protection of location MUST NOT 731 be used. TLS protection of location SHOULD be used, however, if 732 establishment of the TLS connection fails, the call set-up 733 operation, including location conveyance, MUST be retried without 734 TLS. 736 Both the "retransmission-allowed" and "routing-query-allowed" SHOULD 737 be set to "yes". Querying for routing may be performed by proxies 738 providing a routing service for emergency calls even if 739 retransmission-allowed or routing-query-allowed is set to "no" or is 740 not present. 742 While many jurisdictions force a user to reveal their location 743 during an emergency call set-up, there are a small, but real, number 744 of jurisdictions that allow a user to configure their calling device 745 to disable providing location, even during emergency calling. This 746 capability MUST be configurable, but is NOT RECOMMENDED as the 747 default configuration of any UA. Local policies will dictate this 748 ability. 750 7. Geopriv Privacy Considerations 752 Transmitting location information is considered by most to be highly 753 sensitive information, requiring protection from eavesdropping, 754 tracking, and altering in transit. [RFC3693] articulates rules to 755 be followed by any protocol wishing to be considered a Geopriv 756 "using protocol", specifying how a transport protocol meetings 757 those rules. This section describes how SIP as a using protocol 758 meets those requirements. 760 Quoting requirement #4 of [RFC3693]: 762 "The using protocol has to obey the privacy and security 763 instructions coded in the location object and in the 764 corresponding Rules regarding the transmission and storage 765 of the LO." 767 This document requires that SIP entities sending or receiving 768 location MUST obey such instructions. 770 Quoting requirement #5 of [RFC3693]: 772 "The using protocol will typically facilitate that the keys 773 associated with the credentials are transported to the 774 respective parties, that is, key establishment is the 775 responsibility of the using protocol." 777 [RFC3261] and the documents it references define the key 778 establishment mechanisms. 780 Quoting requirement #6 of [RFC3693]: 782 "(Single Message Transfer) In particular, for tracking of 783 small target devices, the design should allow a single 784 message/packet transmission of location as a complete 785 transaction." 787 When used for tracking, a simple NOTIFY or UPDATE normally is 788 relatively small, although the PIDF itself can get large. Normal 789 RFC3261 procedures of reverting to TCP when the MTU size is exceeded 790 would be invoked. 792 8. Security Considerations 794 Conveyance of physical location of a UAC raises privacy concerns, 795 and depending on use, there may be authentication and integrity 796 concerns. This document calls for conveyance to normally be 797 accomplished through secure mechanisms (like S/MIME or TLS). In 798 cases where a session set-up is routed based on the location of the 799 UAC initiating the session or SIP MESSAGE, securing the by-value 800 location with an end-to-end mechanism such as S/MIME is problematic, 801 because one or more proxies on the path need the ability to read the 802 information to route the message appropriately. Securing the 803 location hop-by-hop, using TLS, protects the message from 804 eavesdropping and modification, but exposes the information to all 805 proxies on the path as well as the endpoint. In most cases, the UAC 806 does not know the identity of the proxy or proxies providing 807 location-based routing services, so that end to middle solutions may 808 not be appropriate either. 810 When the UAC is the source of the location information, which is 811 RECOMMENDED, it can decide whether to reveal its location using 812 hop-by-hop methods. UAC implementations MUST make such capabilities 813 conditional on explicit user permission, and SHOULD alert a user 814 that location is being conveyed. Emergency calls have their own 815 rules in this regard, as detailed in Section 6. Proxies inserting 816 location for location-based routing are unable to meet this 817 requirement, and such use is NOT RECOMMENDED. Proxies conveying 818 location using this extension MUST have the permission of the target 819 to do so. 821 9. IANA Considerations 823 9.1 IANA Registration for the SIP Geolocation Header 825 The SIP Geolocation header is created by this document, with its 826 definition and rules in Section 3.2 of this document. 828 9.2 IANA Registration for New SIP Option Tag 830 The SIP option tag "Geolocation" is created by this document, with 831 the definition and rule in Section 3.5 of this document. 833 9.3 IANA Registration for Response Code 4XX 835 Reference: RFC-XXXX (i.e. this document) 836 Response code: 424 837 Default reason phrase: Bad Location Information 839 This SIP Response code is defined in section 3.3 of this document. 841 9.4 IANA Registration of the Geolocation Reason Protocol 843 The Reason Protocol value "Geolocation" is created by this document, 844 with the definition and values in Section 3.4 if this document 846 10. Acknowledgements 848 To Dave Oran for helping to shape this idea. To Jon Peterson and 849 Dean Willis on guidance of the effort. To Allison Mankin, Dick 850 Knight, Hannes Tschofenig, Henning Schulzrinne, James Winterbottom, 851 Jeroen van Bemmel, Jean-Francois Mule, Jonathan Rosenberg, Keith 852 Drage, Marc Linsner Martin Thomson, Mike Hammer and Paul Kyzivat for 853 constructive feedback. 855 11. References 857 11.1 References - Normative 859 [RFC3261] J. Rosenberg, H. Schulzrinne, G. Camarillo, A. Johnston, J. 860 Peterson, R. Sparks, M. Handley, and E. Schooler, "SIP: 861 Session Initiation Protocol", RFC 3261, May 2002. 863 [RFC3693] J. Cuellar, J. Morris, D. Mulligan, J. Peterson. J. Polk, 864 "Geopriv Requirements", RFC 3693, February 2004 866 [RFC4119] J. Peterson, "A Presence-based GEOPRIV Location Object 867 Format", RFC 4119, December 2005 869 [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate 870 Requirement Levels", RFC 2119, March 1997 872 [RFC2392] E. Levinson, " Content-ID and Message-ID Uniform Resource 873 Locators", RFC 2393, August 1998 875 [RFC3863] H. Sugano, S. Fujimoto, G. Klyne, A. Bateman, W. Carr, J. 876 Peterson, "Presence Information Data Format (PIDF)", RFC 877 3863, August 2004 879 [RFC3856] J. Rosenberg, " A Presence Event Package for the Session 880 Initiation Protocol (SIP)", RFC 3856, August 2004 882 [RFC3859] J. Peterson, "Common Profile for Presence (CPP)", RFC 3859, 883 August 2004 885 [RFC3428] B. Campbell, Ed., J. Rosenberg, H. Schulzrinne, C. Huitema, 886 D. Gurle, "Session Initiation Protocol (SIP) Extension for 887 Instant Messaging" , RFC 3428, December 2002 889 [RFC3311] J. Rosenberg, "The Session Initiation Protocol (SIP) UPDATE 890 Method", RFC 3311, October 2002 892 [RFC3265] Roach, A., "Session Initiation Protocol (SIP)-Specific 893 Event Notification", RFC 3265, June 2002. 895 [RFC3326] H. Schulzrinne, D. Oran, G. Camarillo, "The Reason Header 896 Field for the Session Initiation Protocol (SIP)", RFC 3326 897 Reason Header, December 2002 899 11.2 References - Informative 901 [RFC3825] J. Polk, J. Schnizlein, M. Linsner, "Dynamic Host 902 Configuration Protocol Option for Coordinate-based Location 903 Configuration Information", RFC 3825, July 2004 905 [ID-CIVIC] H. Schulzrinne, " Dynamic Host Configuration Protocol 906 (DHCPv4 and DHCPv6) Option for Civic Addresses Configuration 907 Information ", draft-ietf-geopriv-dhcp-civil-09, "work in 908 progress", January 2006 910 Author Information 912 James Polk 913 Cisco Systems 914 3913 Treemont Circle 33.00111N 915 Colleyville, Texas 76034 96.68142W 917 Phone: +1-817-271-3552 918 Email: jmpolk@cisco.com 920 Brian Rosen 921 NeuStar, Inc. 922 470 Conrad Dr. 40.70497N 923 Mars, PA 16046 80.01252W 924 US 926 Phone: +1 724 382 1051 927 Email: br@brianrosen.net 929 Appendix A. Requirements for SIP Location Conveyance 931 The following subsections address the requirements placed on the 932 user agent client, the user agent server, as well as SIP proxies 933 when conveying location. There is a motivational statement below 934 each requirements that is not obvious in intent 936 A.1 Requirements for a UAC Conveying Location 938 UAC-1 The SIP INVITE Method [RFC3261] must support location 939 conveyance. 941 UAC-2 The SIP MESSAGE method [RFC3428] must support location 942 conveyance. 944 UAC-3 SIP Requests within a dialog should support location 945 conveyance. 947 UAC-4 Other SIP Requests may support location conveyance. 949 UAC-5 There must be one, mandatory to implement means of 950 transmitting location confidentially. 952 Motivation: interoperability 954 UAC-6 It must be possible for a UAC to update location conveyed 955 at any time in a dialog, including during dialog 956 establishment. 958 Motivation: in case a UAC has moved prior to the establishment of a 959 dialog between UAs, the UAC must be able to send new location 960 information. In the case of location having been conveyed, 961 and the UA moves, it needs a means to update the conveyed to 962 party of this location change. 964 UAC-7 The privacy and security rules established within [RFC3693] 965 that would categorize SIP as a 'using protocol' must be met. 967 UAC-8 The PIDF-LO [RFC4119] is a mandatory to implement format for 968 location conveyance within SIP, whether included by-value or 969 by-reference. 971 Motivation: interoperability with other IETF location protocols and 972 mechanisms 974 UAC-9 There must be a mechanism for the UAC to request the UAS send 975 its location 977 UAC-10 There must be a mechanism to differentiate the ability of the 978 UAC to convey location from the UACs lack of knowledge of its 979 location 981 Motivation: Failure to receive location when it is expected can be 982 because the UAC does not implement this extension, or it can 983 be that the UAC implements the extension, but does not know 984 where it is. This may be, for example, due to the failure of 985 the access network to provide a location acquisition 986 mechanisms the UAC understands. These cases must be 987 differentiated. 989 UAC-11 It must be possible to convey location to proxy servers 990 along the path. 992 Motivation: Location-based routing. 994 A.2 Requirements for a UAS Receiving Location 996 The following are the requirements for location conveyance by a user 997 agent server: 999 UAS-1 SIP Responses must support location conveyance. 1001 UAS-2 There must be a unique 4XX response informing the UAC it did 1002 not provide applicable location information. 1004 In addition, requirements UAC-5, 6, 7 and 8 apply to the UAS 1006 A.3 Requirements for SIP Proxies and Intermediaries 1008 The following are the requirements for location conveyance by a SIP 1009 proxies and intermediaries: 1011 Proxy-1 Proxy servers must be capable of adding a Location header 1012 during processing of SIP requests. 1014 Motivation: Provide the capability of network assertion of location 1015 when UACs are unable to do so, or when network assertion is 1016 more reliable than UAC assertion of location 1018 Note: Because UACs connected to sip signaling networks may have 1019 widely varying access network arrangements, including VPN 1020 tunnels and roaming mechanisms, it may be difficult for a 1021 network to reliably know the location of the endpoint. Proxy 1022 assertion of location is NOT RECOMMENDED unless the sip 1023 signaling network has reliable knowledge of the actual 1024 location of the targets. 1026 Proxy-2 There must be a unique 4XX response informing the UAC it 1027 did not provide applicable location information. 1029 Appendix B. Changes from Prior Versions 1031 [NOTE TO RFC-EDITOR: If this document is to be published as an RFC, 1032 this Appendix B is to be removed prior to that event.] 1034 This is a list of the changes that have been made from the SIP WG 1035 version -03 to this version -04: 1037 - removed the inappropriate 2119 language from the Requirements 1038 section. 1040 - removed the old Section 2., which was a Location in a header vs. 1041 in a body artifact from the original versions of the document. 1043 - Added a new Geopriv (or Privacy) Considerations 1045 - Changed the ABNF to reflect discussion on how restrictive the 1046 location-by-reference schemes should be, with an added "Editor's 1047 Note" discussing the issues being faced on this point. 1049 - Changed the "Location" header and option-tag to "Geolocation" 1050 header and option-tag, due to it being pointed out that there is a 1051 conflicting HTTP header called "Location". 1053 - Added new element to PIDF-LO 'routing-query-allowed' 1055 - Stipulated the Reason Header can be used in the 424 Response 1056 Message 1058 - added SUBSCRIBE and NOTIFY as Methods for location conveyance when 1059 used to dereference a sip:, sips: or pres: location-by-reference 1060 URI 1062 - Added OPTIONS Method for a UAC to request the location of a UAS 1063 with a Require header geolocation option-tag. 1065 This is a list of the changes that have been made from the SIP WG 1066 version -02 to this version -03: 1068 - general clean-up of some of the sections 1070 - removed the message examples from the UPDATE, MESSAGE and REGISTER 1071 sections, as these seemed to be making the doc less readable, and 1072 not more readable 1074 - removed the "unknown" option tag, as it was not needed with a 1075 certain combination of the Supported and Location headers 1077 - clarified the location option tag usage in Supported, Require, 1078 Unsupported, and that it shouldn't be used in Proxy-Require, and 1079 why not. 1081 - Added a basic message flow to the basic operation section (Section 1082 4) to aid in understanding of this SIP extension. 1084 - Added a message routing flow, which is based on the location of 1085 the requestor to show how a SIP server can make a routing decision 1086 to a destination based on where the UAC is. 1088 - Articulated how a UAS concludes a UAC understands this extension, 1089 yet does not know its location to provide to the UAS. This is 1090 helpful in those times where an intermediary will act differently 1091 based on whether or not a UAC understands this extension, and 1092 whether or not the UAC includes its location in the request. 1094 - Corrected the erroneous text regarding an Unsupported header being 1095 in a 424 response. It belongs in a 420 response. (Section 5.1) 1097 - Corrected the BNF (I hope) 1099 - Corrected some text in Section 5 that read like this document was 1100 an update to RFC 3261. 1102 This is a list of the changes that have been made from the SIP WG 1103 version -01 to this version -02: 1105 - streamlined the doc by removing text (ultimately removing 42 pages 1106 of text). 1108 - Limited the scope of this document to SIP conveyance, meaning only 1109 how SIP can push location information. 1111 - reduced emergency calling text to just a few paragraphs now that 1112 the ECRIT WG is taking most of that topic on. 1114 - greatly reduced the number of requirements in this version. 1116 - changed the requirements groups from "UA-to-UA", "UA-to-Proxy", 1117 etc to "UAC Reqs", "UAS-Reqs" and "Proxy-Reqs" to focus on what is 1118 being asked of each SIP element. 1120 - Removed the full SIP message examples. 1122 - completed the ABNF for the Location header, including a cid-url to 1123 point at a message body part to help in parsing for location. 1125 - Deleted the call for a new 425 (Retry Location) response code, as 1126 it appears this can easily be used to spoof a UA into providing 1127 where it is inadvertently, even if the intent is legitimate by the 1128 UAC. 1130 This is a list of the changes that have been made from the SIP WG 1131 version -00 to this version -01: 1133 - cleaned up a lot of loose ends in the text 1135 - created a new Location header to convey many means (location is in 1136 the body - even if not viewable, which location format is present, 1137 which format is requested in a query, how to request more than one 1138 location format in a query, whether the UAC understands location 1139 at all, if the UA knows its location, how to push location from 1140 one UA to through a second to a third UA, etc). 1142 - added the ability to convey location by-reference, but only under 1143 certain conditions. 1145 - Added support for the OPTIONS Request to query a server for the 1146 UAC's location, through the use of the new Location header. 1148 - moved both new Response code sections forward in the document for 1149 their meaning to be clearer, earlier for necessary discussion. 1151 - Changed the message flows to only have the pertinent message 1152 headers shown for brevity. 1154 - Added text to the SUB/NOT section showing how and why the location 1155 of a UA can be refreshed or updated with an interval, or by a 1156 trigger. 1158 This is a list of the changes that have been made from the SIPPING 1159 WG version -02 to this SIP WG item document version -00: 1161 - Changed which WG this document is in from SIPPING to SIP due to 1162 the extension of the protocol with new Response codes (424 and 1163 425) for when there is an error involving the LO message body. 1165 - Moved most of the well formed SIP messages out of the main body of 1166 this document and into separate appendixes. This should clean up 1167 the document from a readability point of view, yet still provide 1168 the intended decode examples to readers of this document who wish 1169 that level of detail per flow. The first few flows still have the 1170 decoded SIP messages (unencrypted and encrypted). 1172 - Removed some flow examples which no longer made sense 1174 - Changed all references of "ERC" (Emergency Response Center) to 1175 "PSAP" (Public Safety Answering Point) as a result of discussion 1176 within the new ECRIT WG to define a single term 1178 This is a list of the changes that have been made from the sipping- 1179 01 working group version of this effort to the sipping-02 version: 1181 - added requirements for 2 new 4XX error responses (Bad Location 1182 Information) and (Retry Location Body) 1184 - added "Bad Location Information" as section 8.6 1186 - added "Retry Location Body " as section 9.3 1188 - added support for session mode to cover packet sizes larger than 1189 the single packet limit of 1300 bytes in the message body 1191 - added requirement for a SIP entity to SUBSCRIBE to another for 1192 location information 1194 - added SUBSCRIBE and NOTIFY as section 8.5 1196 - added requirement to have user turn off any tracking created by 1197 subscription 1199 - removed doubt about which method to use for updating location 1200 after a INVITE is sent (update) 1202 - cleaned up which method is to be used if there is no dialog 1203 existing (message) 1205 - removed use of reINVITE to convey location 1207 - clarified that UAs include element of PIDF-LO when 1208 placing an emergency call (to inform PSAP who supplied Location 1209 information) 1211 - updated list of open issues 1213 - added to IANA Considerations section for the two new 4XX level 1214 error responses requested in the last meeting 1216 This is a list of the changes that have been made from the sipping- 1217 00 working group version of this ID to the sipping-01 version: 1219 - Added the offered solution in detail (with message flows, 1220 appropriate SIP Methods for location conveyance, and 1222 - Synchronized the requirements here with those from the Geopriv 1223 Working Group's (attempting to eliminate overlap) 1225 - Took on the task of making this effort the SIP "using protocol" 1226 specification from Geopriv's POV 1228 - Refined the Open Issues section to reflect the progress we've made 1229 here, and to indicate what we have discovered needs addressing, 1230 but has not been to date. 1232 This is a list of the changes that have been made from the -01 1233 individual submission version to the sipping-00 version of this ID: 1235 - Brian Rosen was brought on as a co-author 1237 - Requirements that a location header were negatively received in 1238 the previous version of this document. AD and chair advice was to 1239 move all location information into a message body (and stay away 1240 from headers) 1242 - Added a section of "emergency call" specific requirements 1244 - Added an Open Issues section to mention what hasn't been resolved 1245 yet in this effort 1247 This is a list of the changes that have been made from the 1248 individual submission version -00 to the -01 version 1250 - Added the IPR Statement section 1252 - Adjusted a few requirements based on suggestions from the 1253 Minneapolis meeting 1255 - Added requirements that the UAC is to include from where it 1256 learned its location in any transmission of its LI 1258 - Distinguished the facts (known to date) that certain jurisdictions 1259 relieve persons of their right to privacy when they call a PSAP, 1260 while other jurisdictions maintain a person's right to privacy, 1261 while still others maintain a person's right to privacy - but only 1262 if they ask that their service be set up that way. 1264 - Made the decision that TLS is the security mechanism for location 1265 conveyance in emergency communications (vs. S/MIME, which is still 1266 the mechanism for UA-to-UA non-emergency location conveyance 1267 cases). 1269 - Added the Open Issue of whether a Proxy can insert location 1270 information into an emergency SIP INVITE message, and some of the 1271 open questions surrounding the implications of that action 1273 - added a few names to the acknowledgements section 1275 Intellectual Property Statement 1277 The IETF takes no position regarding the validity or scope of any 1278 Intellectual Property Rights or other rights that might be claimed 1279 to pertain to the implementation or use of the technology described 1280 in this document or the extent to which any license under such 1281 rights might or might not be available; nor does it represent that 1282 it has made any independent effort to identify any such rights. 1283 Information on the procedures with respect to rights in RFC 1284 documents can be found in BCP 78 and BCP 79. 1286 Copies of IPR disclosures made to the IETF Secretariat and any 1287 assurances of licenses to be made available, or the result of an 1288 attempt made to obtain a general license or permission for the use 1289 of such proprietary rights by implementers or users of this 1290 specification can be obtained from the IETF on-line IPR repository 1291 at http://www.ietf.org/ipr. 1293 The IETF invites any interested party to bring to its attention any 1294 copyrights, patents or patent applications, or other proprietary 1295 rights that may cover technology that may be required to implement 1296 this standard. Please address the information to the IETF at 1297 ietf-ipr@ietf.org. 1299 Disclaimer of Validity 1301 This document and the information contained herein are provided on 1302 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 1303 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE 1304 INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR 1305 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1306 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1307 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1309 Copyright Statement 1311 Copyright (C) The Internet Society (2006). This document is subject 1312 to the rights, licenses and restrictions contained in BCP 78, and 1313 except as set forth therein, the authors retain all their rights. 1315 Acknowledgment 1317 Funding for the RFC Editor function is currently provided by the 1318 Internet Society.