idnits 2.17.1 draft-ietf-sip-location-conveyance-00.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 2116. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 2093. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 2100. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 2106. ** 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: ---------------------------------------------------------------------------- == There are 3 instances of lines with non-ascii characters in the document. == 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 43 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 11 instances of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 26 has weird spacing: '...ference mater...' == Line 638 has weird spacing: '...der the subje...' == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: U-U5 - UAC MUST not use S/MIME on the Location Object message body if the message is a dialog related or MESSAGE Request message unless the UAC has a pre-established association with the routing SIP intermediary. -- 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: 'M1' is mentioned on line 1731, but not defined == Missing Reference: 'M2' is mentioned on line 1733, but not defined == Missing Reference: 'M3' is mentioned on line 1735, but not defined == Missing Reference: 'M4' is mentioned on line 1737, but not defined == Missing Reference: 'M5' is mentioned on line 1832, but not defined == Missing Reference: 'M6' is mentioned on line 1741, but not defined == Missing Reference: 'M7' is mentioned on line 1743, but not defined == Missing Reference: 'M8' is mentioned on line 1745, but not defined == Missing Reference: 'M9' is mentioned on line 1747, but not defined == Missing Reference: 'M10' is mentioned on line 1749, but not defined == Missing Reference: 'M11' is mentioned on line 1751, but not defined == Missing Reference: 'M13' is mentioned on line 1755, but not defined == Unused Reference: 'RFC3903' is defined on line 2041, but no explicit reference was found in the text == Unused Reference: 'RFC3265' is defined on line 2053, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'ID-SIP-SOS' ** Obsolete normative reference: RFC 3825 (Obsoleted by RFC 6225) -- Possible downref: Non-RFC (?) normative reference: ref. 'ID-CIVIC' ** Downref: Normative reference to an Informational RFC: RFC 3693 -- Possible downref: Non-RFC (?) normative reference: ref. 'ID-PIDF-LO' ** Obsolete normative reference: RFC 3265 (Obsoleted by RFC 6665) == Outdated reference: A later version (-06) exists of draft-ietf-sipping-e2m-sec-reqs-03 == Outdated reference: A later version (-02) exists of draft-ietf-sipping-session-policy-req-00 Summary: 6 errors (**), 0 flaws (~~), 24 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SIP Working Group James M. Polk 3 Internet Draft Cisco Systems 4 Expiration: Dec 17th, 2005 Brian Rosen 5 File: draft-ietf-sip-location-conveyance-00.txt Emergicom 7 Session Initiation Protocol Location Conveyance 9 June 17th, 2005 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 December 17th, 2005. 37 Copyright Notice 39 Copyright (C) The Internet Society (2005). 41 Abstract 43 This document presents the framework and requirements for usage of 44 the Session Initiation Protocol (SIP) to convey user location 45 information from one Session Initiation Protocol (SIP) entity to 46 another SIP entity. We consider cases where location information is 47 conveyed from end to end, as well as cases where message routing by 48 intermediaries is influenced by the location of the session 49 initiator. We offer a set of solutions to the requirements, each 50 based on the scenario being addressed. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 55 1.1 Conventions . . . . . . . . . . . . . . . . . . . . . . . 3 56 1.2 Changes from Prior Versions . . . . . . . . . . . . . . . 3 57 2. Location In the Body or in a Header . . . . . . . . . . . . . 6 58 3. Scope of Location in a Message Body . . . . . . . . . . . . . 7 59 4. Requirements for UA-to-UA Location Conveyance . . . . . . . . 8 60 5. Requirements for UA-to-Proxy Server Location Conveyance . . . 9 61 6. Additional Requirements for Emergency Calls . . . . . . . . . 10 62 7. Location Conveyance Using SIP . . . . . . . . . . . . . . . . 12 63 8. Location Conveyance UA-to-UA . . . . . . . . . . . . . . . . 13 64 8.1 UA-to-UA Using INVITE . . . . . . . . . . . . . . . . . . 13 65 8.1.1 UA-to-UA Using INVITE with Coordinate Format. . . . . 15 66 8.1.2 UA-to-UA Using INVITE with Civic Format . . . . . . . 17 67 8.2 UA-to-UA Using MESSAGE . . . . . . . . . . . . . . . . . 20 68 8.3 UA-to-UA Using UPDATE . . . . . . . . . . . . . . . . . . 23 69 8.4 UA-to-UA Using PUBLISH . . . . . . . . . . . . . . . . . 27 70 8.5 UA-to-UA Location Conveyance Using SUBSCRIBE and NOTIFY . 28 71 8.6 424 "Bad Location Information" Response Code . . . . . . 28 72 9. Special Considerations for Emergency Calls . . . . . . . . . 28 73 9.1 UA-to-Proxy Using INVITE . . . . . . . . . . . . . . . . 29 74 9.2 UA-to-Proxy Using UPDATE . . . . . . . . . . . . . . . . 34 75 9.3 425 "Retry Location Body" Response Code . . . . . . . . . 38 76 10. Meeting RFC 3693 Requirements . . . . . . . . . . . . . . . . 39 77 11. Open issues . . . . . . . . . . . . . . . . . . . . . . . . . 39 78 12. Security Considerations . . . . . . . . . . . . . . . . . . . 39 79 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . 40 80 13.1 IANA Registration for Response Code 424 . . . . . . . . 40 81 13.2 IANA Registration for Response Code 425 . . . . . . . . 40 82 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 40 83 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 40 84 15.1 Normative References . . . . . . . . . . . . . . . . . 40 85 15.2 Informative References . . . . . . . . . . . . . . . . . 40 86 16. Author Information . . . . . . . . . . . . . . . . . . . . . 41 88 1. Introduction 90 This document presents the framework and requirements for the usage 91 of the Session Initiation Protocol (SIP) [RFC3261] for conveyance of 92 user location information described by [RFC3693] from a SIP entity 93 to another SIP entity. 95 There are several situations in which it is appropriate for SIP to 96 be used to convey Location Information (LI) from one SIP entity to 97 another. This document specifies requirements when a SIP UAC knows 98 its location by some means not specified herein, and needs to inform 99 another SIP entity. One example is one user agent informing another 100 user agent where it is (i.e., you want to tell your friend where you 101 are). 103 Another example is to reach your nearest pizza parlor. A chain of 104 pizza parlors may be contacted through a single well known uri 105 (sip:pizzaparlor.com). This SIP message could be forwarded to the 106 closest franchise by the pizzaparlor.com proxy server. The 107 receiving franchise UAS uses the location information of the UAC to 108 determine the location your delivery. 110 Another important example is emergency calling. A call to 111 sip:sos@example.com is an emergency call as in [ID-SIP-SOS]. The 112 example.com proxy server must route the call to the correct public 113 safety answering point (PSAP) determined by the location of the 114 caller. At the PSAP, the UAS must determine the correct 115 police/fire/ambulance/... service, which is also based on your 116 location. In many jurisdictions, precise location information of 117 the caller in distress is a required component of a call to an 118 emergency center. 120 A fourth example is a direction service, which might give you verbal 121 directions to a venue from your present position. This is a case 122 where only the destination UAS needs to receive the location 123 information. 125 This document does not discuss how the UAC discovers or is 126 configured with its location (either coordinate based such as from 127 [RFC3825] or civic based such as from [ID-CIVIC]). This document 128 will also not discuss the contents of the SIP message body part that 129 is the Location Object (LO) itself. We will specify the 130 requirements for SIP qualifying as a "using protocol" as defined by 131 Geopriv in [RFC3693]. 133 Sections 7, 8 and 9 give specific examples (in well-formed SIP 134 messages) of SIP UA and Proxy behavior for location conveyance, the 135 last of which is a section devoted to the unique circumstances 136 regarding emergency calling. Section 10 addresses how this document 137 adheres to the requirements specified in [RFC3693] (Geopriv 138 Requirements). Section 11 lists the current open issues with 139 location conveyance in SIP, and the new open issues recently 140 discovered as a result of the added effort to this revision. 141 Section 13 IANA registers 2 new Response codes. 143 1.1 Conventions used in this document 145 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 146 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and 147 "OPTIONAL" in this document are to be interpreted as described 148 in [RFC2119]. 150 1.2 Changes from Prior Versions 152 [NOTE TO RFC-EDITOR: If this document is to be published as an RFC, 153 this section is to be removed prior to that event.] 155 This is a list of the changes that have been made from the SIPPING 156 WG version -02 to this SIP WG item document version -00: 158 - Changed which WG this document is in from SIPPING to SIP due to 159 the extension of the protocol with new Response codes (424 and 160 425) for when there is an error involving the LO message body. 162 - Moved most of the well formed SIP messages out of the main body of 163 this document and into separate appendixes. This should clean up 164 the document from a readability point of view, yet still provide 165 the intended decode examples to readers of this document who wish 166 that level of detail per flow. The first few flows still have the 167 decoded SIP messages (unencrypted and encrypted). 169 - Removed some flow examples which no longer made sense 171 - Changed all references of "ERC" (Emergency Response Center) to 172 "PSAP" (Public Safety Answering Point) as a result of discussion 173 within the new ECRIT WG to define a single term 175 This is a list of the changes that have been made from the sipping- 176 01 working group version of this effort to the sipping-02 version: 178 - added requirements for 2 new 4XX error responses (Bad Location 179 Information) and (Retry Location Body) 181 - added "Bad Location Information" as section 8.6 183 - added "Retry Location Body " as section 9.3 185 - added support for session mode to cover packet sizes larger than 186 the single packet limit of 1300 bytes in the message body 188 - added requirement for a SIP entity to SUBSCRIBE to another for 189 location information 191 - added SUBSCRIBE and NOTIFY as section 8.5 193 - added requirement to have user turn off any tracking created by 194 subscription 196 - removed doubt about which method to use for updating location 197 after a INVITE is sent (update) 199 - cleaned up which method is to be used if there is no dialog 200 existing (message) 202 - removed use of reINVITE to convey location 204 - clarified that UAs include element of PIDF-LO when 205 placing an emergency call (to inform PSAP who supplied Location 206 information) 208 - updated list of open issues 210 - added to IANA Considerations section for the two new 4XX level 211 error responses requested in the last meeting 213 This is a list of the changes that have been made from the sipping- 214 00 working group version of this ID to the sipping-01 version: 216 - Added the offered solution in detail (with message flows, 217 appropriate SIP Methods for location conveyance, and 219 - Synchronized the requirements here with those from the Geopriv 220 Working Group's (attempting to eliminate overlap) 222 - Took on the task of making this effort the SIP "using protocol" 223 specification from Geopriv's POV 225 - Refined the Open Issues section to reflect the progress we've made 226 here, and to indicate what we have discovered needs addressing, 227 but has not been to date. 229 This is a list of the changes that have been made from the -01 230 individual submission version to the sipping-00 version of this ID: 232 - Brian Rosen was brought on as a co-author 234 - Requirements that a location header were negatively received in 235 the previous version of this document. AD and chair advice was to 236 move all location information into a message body (and stay away 237 from headers) 239 - Added a section of "emergency call" specific requirements 241 - Added an Open Issues section to mention what hasn't been resolved 242 yet in this effort 244 This is a list of the changes that have been made from the 245 individual submission version -00 to the -01 version 247 - Added the IPR Statement section 249 - Adjusted a few requirements based on suggestions from the 250 Minneapolis meeting 252 - Added requirements that the UAC is to include from where it 253 learned its location in any transmission of its LI 255 - Distinguished the facts (known to date) that certain jurisdictions 256 relieve persons of their right to privacy when they call an PSAP, 257 while other jurisdictions maintain a person's right to privacy, 258 while still others maintain a person's right to privacy - but only 259 if they ask that their service be set up that way. 261 - Made the decision that TLS is the security mechanism for location 262 conveyance in emergency communications (vs. S/MIME, which is still 263 the mechanism for UA-to-UA non-emergency location conveyance 264 cases). 266 - Added the Open Issue of whether a Proxy can insert location 267 information into an emergency SIP INVITE message, and some of the 268 open questions surrounding the implications of that action 270 - added a few names to the acknowledgements section 272 2. Location In the Body or in a Header 274 In determining where "location" is placed in a SIP message, 275 consideration is taken as to where the trust model is based on the 276 architecture involved. 278 If the user agent has the location stored within it, and one user 279 agent wants to inform another user agent where it is, it seems 280 reasonable to have this accomplished by placing the location 281 information (coordinate or civic) in an S/MIME registered and 282 encoded message body, and sending it as part of a SIP request or 283 response. No routing of the request based on the location 284 information is required in this case; therefore no SIP Proxies 285 between these two UAs need to view the location information 286 contained in the SIP messages. This is location by-value. 288 Although SIP [RFC3261] does not permit SIP intermediaries to modify 289 or delete a message body, there is no restriction on viewing message 290 bodies. S/MIME protected message bodies, implemented on bodies for 291 communications between user agents only, would render the location 292 object opaque to a proxy server for any desired modification if it 293 is not correct or precise enough from that proxy's point of view 294 (were it to be able to view it). This problem is similar to that 295 raised in Session Policy [ID-Sess-Pol], where an intermediary may 296 need information in a body, such as IP address of media streams or 297 codec choices to route a call properly. Requirements in [ID-Sess- 298 Pol] are applicable to routing based on location, and are 299 incorporated in these requirements by reference. 301 It is conceivable to create a new header for location information. 302 However, [RFC3693] prefers S/MIME for security of Location 303 Information, and indeed S/MIME is preferable in SIP [RFC3261] for 304 protecting a message body. Accordingly, these requirements specify 305 location be carried in a body when it is known to/stored in a user 306 agent. 308 It is the use of S/MIME however, that limits routing based on 309 location. Therefore, it seems appropriate to require that, where 310 routing is dependent on location, protection of the location 311 information object be accomplished by other mechanisms visible to 312 SIP proxies: here TLS ("sips:" from [RFC3261]). It is envisioned 313 that S/MIME SHOULD be used when location information is not required 314 by proxy servers, and TLS MUST be used when it is. The UAC will 315 need to know the difference in the call's intent as to which 316 security mechanism to engage for LI conveyance. 318 This document does not address the behavior or configuration of SIP 319 Proxy Servers in these cases in order to accomplish location- 320 sensitive routing. That is out of scope, and left for further 321 (complementary) efforts within the ECRIT WG. 323 3. Scope of Location in a Message Body 325 As concluded from the previous section, location information is to 326 be contained within a message body when the user agent has this 327 information locally. If either another body (SDP for example) is 328 also to be sent in the message, or the LI is to be protected with 329 S/MIME, the rules stated in section 7 of [RFC3261] regarding 330 multipart MIME bodies MUST be followed. The format and 331 privacy/security rules of [RFC3693] MUST too be followed. 333 User agents providing location can convey it incorrectly or 334 inappropriately. Therefore, there needs to be a new UAC error 335 response code created to inform the UAC by a UAS or Proxy of this 336 rejected 337 request message because of the location information in the message. 339 There needs to be two new response codes currently not defined in 340 SIP: 342 1) the first indicating the existing location information was not 343 considered good by the viewing SIP element. 345 There will be times in which the UAC does not know its location 346 information, or another SIP entity knows the UAC's location better 347 than the UAC itself. How this is determined is out of scope of this 348 document. In these times, a Proxy servers that know the location 349 of the UAC needs inform the UAC of its location information and have 350 that UAC include that message body in its next SIP message to the 351 same destination UA. This error code needs to be unique with 352 respect to the error code for merely incorrect location information 353 from the UAC. 355 2) a second new response code indicating the existing location 356 information was not considered good by the viewing SIP element, 357 one that includes a new message body with new location 358 information of the UAC to be used in a subsequent SIP Request by 359 the UAC. 361 This second response code would be more applicable for cases in 362 which a SIP intermediary knows more about the location of the UAC 363 than the UAC, and needs to get the more appropriate LO into the SIP 364 message. This cannot occur with existing rules stating message 365 bodies cannot be modified or added by intermediaries. This new 366 response code message containing a new LO of the UAC appears the 367 best course of action. 369 If there can be more than one LO within the same SIP message is not 370 addressed in this document at this time. 372 If there can be more than one LO within the same SIP message and the 373 message is routed by a SIP Proxy based on the contents of an LO, 374 this document currently does not specify how the proxy determines 375 which LO to route the message based on. This is currently an open 376 question as to whether this topic is addressed in the SIP WG or in 377 the ECRIT WG, therefore this is left for future study at this time. 379 4. Requirements for UA-to-UA Location Conveyance 381 The following are the requirements for UA-to-UA Location Conveyance 382 Situations where routing is not based on the LI of either UA, and 383 location is stored/cached in the UAC: 385 U-U1 - Dialog-initiating SIP Requests and their responses MUST 386 support Location Conveyance 388 U-U2 - The SIP MESSAGE method [RFC3428] MUST support Location 389 Conveyance 391 U-U3 - Other SIP Requests SHOULD support Location Conveyance 393 U-U4 - UAC Location information SHOULD remain confidential e2e 394 to the destination UAS except when the session is to an 395 identifiable emergency endsystem. 397 U-U5 - UAC MUST not use S/MIME on the Location Object message body 398 if the message is a dialog related or MESSAGE Request 399 message unless the UAC has a pre-established association 400 with the routing SIP intermediary. 402 U-U6 - UAS Location information SHOULD remain confidential e2e 403 to the destination UAC except when the session is to/from an 404 identifiable emergency endsystem. 406 Emergency callback is one example where this may apply. 408 U-U7 - The privacy and security rules established within the 409 Geopriv Working Group that would categorize SIP as a 'using 410 protocol' MUST be met [RFC3693]. See Section 10 for 411 analysis. 413 U-U8 - Location information MUST be contained in the location 414 Object as defined in [ID-PIDF-LO], which will satisfy all 415 format requirements for interoperability. 417 U-U9 - User Agents and Proxies SHOULD be able to handle SIP 418 messages in which Location Information is fragmented across 419 multiple packets. 421 U-U10 - There MUST be a unique UAC error response code informing 422 the UAC it did not provide applicable location information. 424 U-U11 - There MUST be a means for publishing location state 425 information for a particular presentity to a Presence 426 Compositor Server 428 U-U12 - User Agents and Proxies SHOULD be able to handle SIP 429 messages which contain more than one Location Object. 431 5. Requirements for UA-to-Proxy Server Location Conveyance 433 The following are the requirements for UA-to-Proxy Server Location 434 Conveyance situations: 436 U-PS1 - MUST work with dialog-initiating SIP Requests and 437 responses, as well as the SIP MESSAGE method [RFC3428], and 438 SHOULD work with most SIP messages. 440 U-PS2 - UAC location information SHOULD remain opaque to 441 intermediaries the message was not addressed to, but MUST 442 be useable (i.e. viewable) by intermediary proxy servers 443 requiring location knowledge of the UAC to properly route 444 the message. 446 U-PS3 - The privacy and security rules established within the 447 Geopriv Working Group which would categorize SIP as a 448 'using protocol' MUST be met [RFC3693]. 450 U-PS4 - Proxy servers MUST NOT modify or remove an LO message body 451 part ([RFC3261] currently forbids this). 453 U-PS5 - A SIP message containing a Location Object MUST NOT be 454 rejected by a SIP intermediary because the message body 455 part or LO itself was not understood (except when the 456 intermediary complies with requirement U-PS7 below, or when 457 the SIP message is addressed to that intermediary). 459 With regards to requirement U-PS5, not all SIP Proxies are expected 460 to route messages based on the contained Location Object from the 461 UAC. There will likely be a SIP Proxy able to perform this function 462 downstream, and the original SIP message needs to reach that 463 location enabled Proxy to route correctly. 465 U-PS6 - There MUST be a unique UAC error response code informing 466 the UAC it did not provide applicable location information. 468 U-PS7 - There MUST be a unique UAC error response code informing 469 the UAC it did not provide applicable location information, 470 and to include the location information contained in the 471 message body of the error message for usage in the UAC's 472 next attempt to the same UAS of the original message. 474 6. Additional Requirements for Emergency Calls 476 Emergency calls have requirements that are not generally important 477 to other uses for location in SIP: 479 Emergency calls presently have between 2 and 8-second call setup 480 times. There is ample evidence that the longer call setup end of 481 the range causes an unacceptable number of callers to abandon the 482 call before it is completed. Two-second call completion time is a 483 goal of many existing emergency call centers. Allocating 25% of the 484 call set up for processing privacy concerns seems reasonable; 1 485 second would be 50% of the goal, which seems unacceptable; less than 486 0.5 second seems unachievable, therefore: 488 E-1 - Privacy mechanisms MUST add no more than 0.5 second of call 489 setup time when implemented in present technology UAs and 490 Proxy Servers. 492 It may be acceptable for full privacy mechanisms related to the 493 location of the UAC (and it's user) to be tried on an initial 494 attempt to place a call, as long as the call attempt may be retried 495 without the privacy mechanism present (or enabled) if the first 496 attempt fails. Abandoning privacy in cases of failure of the 497 privacy mechanism might be subject to user preference, although such 498 a feature would be within the domain of a UA implementation and thus 499 not subject to standardization. It should be noted that some 500 jurisdictions have laws that explicitly deny any expectation of 501 location privacy when making an emergency call, while others grant 502 the user the ability to remain anonymous even when calling an PSAP. 503 So far, this has been offered in some jurisdictions, but the user 504 within that jurisdiction must state this preference, as it is not 505 the default configuration. 507 E-2 � Privacy mechanisms MUST NOT be mandatory for successful 508 conveyance of location during an (sos-type) emergency call. 510 E-3 - It MUST be possible to provide a privacy mechanism (that does 511 not violate the other requirements within this document) to a 512 user within a jurisdiction that gives that user the right to 513 choose not to reveal their location even when contacting an 514 PSAP. 516 E-4 � The retention and retransmission policy of the PSAP MUST be 517 able to be made available to the user, and override the 518 user's normal policy when local regulation governs such 519 retention and retransmission (but does not violate 520 requirement E-3). As in E-2 above, requiring the use of the 521 PSAP's retention and/or retransmission policy may be subject 522 to user preference; although in most jurisdictions, local 523 laws specify such policies and may not be overridden by user 524 preference. 526 Location information is considered so important during emergency 527 calls, that it is to be transmitted even when it is not considered 528 reliable, or might even be wrong. For example, some application 529 might know that the DHCP reply with location information was 530 overwritten recently (or exactly) when a VPN connection was 531 activated. This could, and likely will, provide any new location 532 information to the UA from somewhere far away from the UA (perhaps 533 the user's corporate facility). 535 E-5 - A call transfer between response centers MUST NOT be 536 considered a violation of the distribution privacy attribute 537 contained within the location object. 539 This transfer will likely be for legitimate reasons; for example, 540 the session was misrouted to the wrong PSAP, and is referred 541 [RFC3515] to the correct one. 543 E-6 Location information MUST be transmitted if known to the UAC, 544 in all calls to a PSAP, even in the case it is not considered 545 reliable. 547 With that in mind, it is important to distinguish the location 548 information learned locally from LI learned over a VPN; which in 549 itself is useful additional information to that PSAP operator. 551 E-7 THE UA must provide the actual LI of the endpoint, and not 552 location which might have been erroneously given to it by, e.g. 553 a VPN tunnel DHCP server. 555 E-8 A PSAP MAY wish to SUBSCRIBE to the UAC that initiated a 556 session. If this is supported by the UAC, all NOTIFY messages 557 MUST contain the UAC's location information. 559 This is a means for the emergency response centers to maintain a 560 location the callers in distress. 562 E-9 It MUST be possible that any UAC supporting E-8 be informed of 563 this subscription, as this will provide a means of alert to the 564 user who does not wish this capability to remain enabled. 566 7. Location Conveyance using SIP 568 Geopriv is the IETF working group assigned to define a Location 569 Object for carrying within another protocol to convey geographic 570 location of an endpoint to another entity. This Location Object 571 will be supplied within SIP to convey location of a UA (or user of a 572 UA). The Location Object (LO) is defined in [ID-PIDF-LO]. Section 573 26 of [RFC3261] defines the security functionality SIPS for 574 transporting SIP messages with either TLS or IPsec, and S/MIME for 575 encrypting message bodies from SIP intermediaries that would 576 otherwise have access to reading the clear-text bodies. For UA-to- 577 UA location conveyance, using the PIDF-LO body satisfies the entire 578 format and message-handling requirements as stated in the baseline 579 Geopriv Requirements [RFC3693]. SIP entities that will carry an LO 580 MUST implement S/MIME for encrypting on an end-to-end basis the 581 location of a user agent, satisfying [RFC3693]'s security 582 requirements. The SIPS-URI from [RFC3261] SHOULD also be used for 583 further message protection (message integrity, authentication and 584 message confidentiality) and MUST be used when S/MIME is not used 585 (when not violating the requirements for emergency messaging 586 detailed in section 6 of this document). The entities sending and 587 receiving the LO MUST obey the privacy and security instructions in 588 the LO to be compliant with this specification. 590 Self-signed certificates SHOULD NOT be used for protecting LI, as 591 the sender does not have a secure identity of the recipient. 593 Several LOs MAY be included in a body. If the message length 594 exceeds the maximum message length of a single packet, session mode 595 is to be used. 597 Several SIP Methods are capable (and applicable) to carry the LO 598 message body. The Methods are divided into two groups, one for 599 those applicable for UA-to-UA location conveyance, and the other 600 group for UA-to-Proxy Location conveyance for routing the message. 602 The list of applicable Methods for UA-to-UA location conveyance is: 604 INVITE, 605 UPDATE, 606 MESSAGE, 607 SUBSCRIBE/NOTIFY, and 608 PUBLISH. 610 The list of applicable Methods for UA-to-Proxy location conveyance 611 is: 613 INVITE, 614 UPDATE, and 615 MESSAGE 617 While the authors do not yet see a reason to have location conveyed 618 in the OPTIONS, ACK, PRACK, BYE, REFER and CANCEL Methods, we do not 619 see a reason to prevent carrying a LO within these Method Requests 620 as long as the SIP message meets the requirements stated within this 621 document. 623 A 200 OK to an INVITE MAY carry the UAS's LO back to the UAC that 624 provided its location in the INVITE, but this is not something 625 that can be required due to the timing of the INVITE to 200 OK 626 messages, with potential local/user policy requiring the called user 627 to get involved in determining if the caller is someone they wish to 628 give location to (and at what precision). 630 For UA-to-Proxy location conveyance, there are two cases: one in 631 which all proxies on the path from the UA to the proxy that requires 632 location can be trusted with the LI, and one in which intermediate 633 proxies may not be trusted. The former may be implemented with 634 "hop-by-hop" security as specified in [RFC3261] using sips: (i.e. 635 TLS security). In particular, emergency call routing requires 636 routing proxies to know location, and sips: protection is 637 appropriate. The latter case is under study by the SIPPING working 638 group under the subject "End to Middle" security [ID-End-Mid-Sec]. 640 Regardless which scenario (UA-to-UA or UA-to-Proxy) is used to 641 convey location, SIP entities MUST adhere to the rules of [RFC3693], 642 specifically the retention and distribution (privacy) attributes of 643 a UA's location. When Alice is deciding how to transmit her 644 location, she should be keenly aware of the parameters in which she 645 wants her location to be stored and distributed. However, once she 646 sends that location information to Bob, he MUST also now obey 647 Alice's wishes regarding these privacy attributes if he is deciding 648 to inform another party about Alice. This is a fundamental 649 principle of the Geopriv Working Group, i.e. "PRIVACY". 651 8. User Agent-to-User Agent Location Conveyance 653 The offered solution here for the User-to-User location conveyance 654 between UAs is used with the INVITE, UPDATE, MESSAGE, SUB/NOT and 655 PUBLISH Methods in the following subsections. 657 Well formed SIP messages are only in the main body of this document 658 for the first few examples. All well formed SIP message flows are 659 in separate appendixes at the end of this document for brevity here, 660 while there providing a complete set of example flows to review and 661 comment on. 663 8.1 UA-to-UA using INVITE Method 665 Below is a common SIP session set-up sequence between two user 666 agents. In this example, Alice will provide Bob with her geographic 667 location in the INVITE message. 669 UA Alice UA Bob 671 | INVITE [M1] | 672 |---------------------------------------->| 673 | | 674 | 200 OK [M2] | 675 |<----------------------------------------| 676 | | 677 | ACK [M3] | 678 |---------------------------------------->| 679 | | 680 | RTP | 681 |<=======================================>| 682 | | 684 Figure 1. UA-UA with Location in INVITE 686 User agent Alice invites user agent Bob to a session [M1 of Figure 687 1]. 689 - Within this INVITE is a multipart body indication that it is 690 S/MIME encrypted [according to the rules of RFC3261] by Alice for 691 Bob. One body part contains the SDP offered by Alice to Bob. 692 Alice's location (here coordinate based) is the other body part 693 contained in this INVITE. 695 - Bob responses with a 200 OK [M2] (choosing a codec as specified by 696 the Offer/Answer Model [RFC3264]). Bob can include his location 697 in the 200 OK response, but this shouldn't be expected due to user 698 timing. If Bob wants to provide his location to Alice after the 699 200 OK, but before a BYE, the UPDATE Method [RFC3311] should be 700 used. 702 - Alice's UA replies with an ACK and the session is set up. 704 Figure 1. does not include any Proxies because in it assumed they 705 would not affect the session set-up with respect to whether or not 706 Alice's location is in a message body part, and Proxies don't react 707 to S/MIME bodies, making their inclusion more or less moot and more 708 complex than necessary. 710 The most relevant message in Figure 1 having to do with location is 711 (obviously) the message with the location object in it [M1]. So to 712 cut down on length of this document, only the INVITE message in this 713 example will be shown. Section 8.1.1 will give an example of this 714 well formed INVITE message using a Coordinate location format. 715 Section 8.1.2 will give an example of this well formed INVITE 716 message using the civic location format. 718 8.1.1 UA-to-UA INVITE with Coordinate Location Using S/MIME 720 Below is a well-formed SIP INVITE Method message to the example in 721 Figure 1 in section 8.1. 723 [Message 1 in Figure 1] 725 INVITE sips:bob@biloxi.example.com SIP/2.0 726 Via: SIP/2.0/TLS pc33.atlanta.example.com 727 ;branch=z9hG4bK776asdhds 728 Max-Forwards: 70 729 To: Bob 730 From: Alice ;tag=1928301774 731 Call-ID: a84b4c76e66710@pc33.atlanta.example.com 732 CSeq: 314159 INVITE 733 Contact: 734 Content-Type: application/pkcs7-mime; 735 smime-type=enveloped-data; name=smime.p7m 736 Content-Disposition: attachment; 737 filename=smime.p7m handling=required 739 Content-Type: multipart/mixed; boundary=boundary1 741 --boundary1 743 Content-Type: application/sdp 744 v=0 745 o=alice 2890844526 2890844526 IN IP4 atlanta.example.com 746 c=IN IP4 10.1.3.33 747 t=0 0 748 m=audio 49172 RTP/AVP 0 4 18 749 a=rtpmap:0 PCMU/8000 751 --boundary1 753 Content-type: application/cpim-pidf+xml 754 755 760 761 2005-11-11T08:57:29Z 762 763 764 765 766 767 41.87891N 768 87.63649W 770 771 772 dhcp 773 774 775 no 776 2005-11-13T14:57:29Z 778 779 780 781 782 784 --boundary1-- 786 8.1.1.1 UA-to-UA INVITE with Coordinate Location Not Using S/MIME 788 Below is a well-formed SIP INVITE Method message to the example in 789 Figure 1 in section 8.1. This message is here to show that although 790 the requirements are mandatory to implement proper security, it is 791 not mandatory to use. This message below is show for those cases 792 where hop-by-hop security is deployed. 794 [Message 1 in Figure 1] 796 INVITE sip:bob@biloxi.example.com SIP/2.0 797 Via: SIP/2.0/TCP pc33.atlanta.example.com 798 ;branch=z9hG4bK74bf9 799 Max-Forwards: 70 800 From: Alice ;tag=9fxced76sl 801 To: Bob 802 Call-ID: 3848276298220188511@atlanta.example.com 803 CSeq: 31862 INVITE 804 Contact: 805 Content-Type: multipart/mixed; boundary=boundary1 806 Content-Length: ... 808 --boundary1 810 Content-Type: application/sdp 811 v=0 812 o=alice 2890844526 2890844526 IN IP4 atlanta.example.com 813 c=IN IP4 10.1.3.33 814 t=0 0 815 m=audio 49172 RTP/AVP 0 4 18 816 a=rtpmap:0 PCMU/8000 818 --broundary1 820 Content-Type: application/cpim-pidf+xml 821 822 827 828 2005-11-11T08:57:29Z 829 830 831 832 833 834 41.87891N 835 87.63649W 836 837 838 dhcp 839 840 841 no 842 2005-11-13T14:57:29Z 844 845 846 847 848 850 --boundary1-- 852 8.1.2 UA-to-UA INVITE with Civic Location Using S/MIME 854 Below is a well-formed SIP INVITE Method message to the example in 855 Figure 1 in section 8.1 using the civic location format. 857 [Message 1 in Figure 1] 859 INVITE sips:bob@biloxi.example.com SIP/2.0 860 Via: SIP/2.0/TLS pc33.atlanta.example.com 861 ;branch=z9hG4bK776asdhds 862 Max-Forwards: 70 863 To: Bob 864 From: Alice ;tag=1928301774 865 Call-ID: a84b4c76e66710@pc33.atlanta.example.com 866 CSeq: 314159 INVITE 867 Contact: 868 Content-Type: application/pkcs7-mime; 869 smime-type=enveloped-data; name=smime.p7m 870 Content-Disposition: attachment; 871 filename=smime.p7m handling=required 873 Content-Type: multipart/mixed; boundary=boundary1 875 --boundary1 877 Content-Type: application/sdp 878 v=0 879 o=alice 2890844526 2890844526 IN IP4 atlanta.example.com 880 c=IN IP4 10.1.3.33 881 t=0 0 882 m=audio 49172 RTP/AVP 0 4 18 883 a=rtpmap:0 PCMU/8000 885 --boundary1 887 Content-type: application/cpim-pidf+xml 888 889 894 895 2005-11-11T08:57:29Z 896 897 898 899 900 US 901 Illinois 902 Chicago 903 233 904 South 905 Wacker 906 Drive 907 60606 908 Sears Tower 909 1 910 911 dhcp 912 www.cisco.com 913 914 915 no 916 2005-11-13T14:57:29Z 918 919 920 921 922 924 --boundary1-- 926 8.1.2.1 UA-to-UA INVITE with Civic Location Not Using S/MIME 928 Below is a well-formed SIP INVITE Method message to the example in 929 Figure 1 in section 8.1. This message is here to show that although 930 the requirements are mandatory to implement proper security, it is 931 not mandatory to use. This message below is show for those cases 932 where the sending user does not wish to use security mechanisms in 933 transmitting their coordinate location. 935 [Message 1 in Figure 1] 937 INVITE sip:bob@biloxi.example.com SIP/2.0 938 Via: SIP/2.0/TCP pc33.atlanta.example.com 939 ;branch=z9hG4bK74bf9 940 Max-Forwards: 70 941 From: Alice ;tag=9fxced76sl 942 To: Bob 943 Call-ID: 3848276298220188511@atlanta.example.com 944 CSeq: 31862 INVITE 945 Contact: 946 Content-Type: multipart/mixed; boundary=boundary1 947 Content-Length: ... 949 --boundary1 951 Content-Type: application/sdp 952 v=0 953 o=alice 2890844526 2890844526 IN IP4 atlanta.example.com 954 c=IN IP4 10.1.3.33 955 t=0 0 956 m=audio 49172 RTP/AVP 0 4 18 957 a=rtpmap:0 PCMU/8000 959 --broundary1 961 Content-type: application/cpim-pidf+xml 962 963 968 969 2005-11-11T08:57:29Z 970 971 972 973 974 US 975 Illinois 976 Chicago 977 233 978 South 979 Wacker 980 Drive 981 60606 982 Sears Tower 983 1 984 985 dhcp 986 www.cisco.com 987 988 989 no 990 2005-11-13T14:57:29Z 992 993 994 995 996 998 --boundary1-- 1000 8.2 UA-to-UA Using MESSAGE Method 1002 Anytime a user transmits location information outside a dialog, the 1003 MESSAGE Method is to be used. The logic here is as follows: 1005 - UPDATE isn't appropriate because it is for the updating of 1006 session capabilities and parameters of a dialog (after the 1007 INVITE included location information). 1009 - reINVITE isn't appropriate because it is only used (or only 1010 supposed to be used) for changing the parameters of an existing 1011 dialog, and one might not exist in all cases of location 1012 conveyance. 1014 This leaves MESSAGE as the only viable Request Method for location 1015 conveyance outside of a dialog between two users (Alice and Bob in 1016 this case). The following is an example of this communication. 1018 UA Alice UA Bob 1020 | MESSAGE [M1] | 1021 |---------------------------------------->| 1022 | | 1023 | 200 OK [M2] | 1024 |<----------------------------------------| 1025 | | 1027 Figure 2. UA-UA with Location in MESSAGE 1029 Section 8.2.1 will give the well formed MESSAGE Method containing a 1030 well formed Geopriv Location Object using the Coordinate location 1031 format that fully complies with all security requirements - SIPS for 1032 hop-by-hop security, and S/MIME for message body confidentiality 1033 end-to-end, as well as adhering to the retention and distribution 1034 concerns from [RFC3693]. Section 8.2.2 will show the Civic Location 1035 format alternative to the same location, as conveyed from Alice to 1036 Bob. This section does not adhere to confidentiality or integrity 1037 concerns of [RFC3693], but does convey retention and distribution 1038 indicators from Alice. 1040 8.2.1 UA-to-UA MESSAGE with Coordinate Location Using S/MIME 1042 Below is M1 from Figure 2 in section 8.2. that is fully secure and 1043 in compliance with Geopriv requirements in [RFC3693] for security 1044 concerns. 1046 [Message 1 in Figure 2] 1048 MESSAGE sips:bob@biloxi.example.com SIP/2.0 1049 Via: SIP/2.0/TLS pc33.atlanta.example.com 1050 ;branch=z9hG4bK776asegma 1051 Max-Forwards: 70 1052 To: Bob 1053 From: Alice ;tag=1928301774 1054 Call-ID: a84b4c76e66710@pc33.atlanta.example.com 1055 CSeq: 22756 MESSAGE 1056 Content-Type: application/pkcs7-mime; 1057 smime-type=enveloped-data; name=smime.p7m 1058 Content-Disposition: attachment; 1059 filename=smime.p7m handling=required 1061 Content-Type: multipart/mixed; boundary=boundary1 1063 --boundary1 1065 Content-Type: text/plain 1066 Here's my location, Bob? 1068 --broundary1 1070 Content-Type: application/cpim-pidf+xml 1071 Content-Disposition: render 1072 Content-Description: my location 1073 1074 1079 1080 2005-11-11T08:57:29Z 1081 1082 1083 1084 1085 1086 41.87891N 1087 87.63649W 1088 1089 1090 dhcp 1091 1092 1093 no 1094 2005-11-13T14:57:29Z 1096 1097 1098 1099 1100 1102 --boundary1-- 1104 8.2.2 UA-to-UA MESSAGE with Civic Location Not Using S/MIME 1106 Below is a well-formed SIP MESSAGE Method message to the example in 1107 Figure 2 in section 8.2 when hop-by-hop security mechanisms are 1108 deployed. 1110 [Message 1 in Figure 2] 1112 MESSAGE sip:bob@biloxi.example.com SIP/2.0 1113 From: ;tag=34589882 1114 To: 1115 Call-ID: 9242892442211117@atlanta.example.com 1116 CSeq: 6187 MESSAGE 1117 Content-Type: application/cpim-pidf+xml 1118 Content-ID: <766534765937@atlanta.example.com> 1119 Content-Disposition: render 1120 Content-Description: my location 1122 1123 1128 1129 2005-11-11T08:57:29Z 1130 1131 1132 1133 1134 US 1135 Illinois 1136 Chicago 1137 233 1138 South 1139 Wacker 1140 Drive 1141 60606 1142 Sears Tower 1143 1 1144 1145 dhcp 1146 1147 1148 no 1149 2005-11-13T14:57:29Z 1151 1152 1153 1154 1155 1157 8.3 UA-to-UA Location Conveyance Using UPDATE 1159 UPDATE MUST NOT be used to send location information from UA-to-UA 1160 unless location has already been sent in an INVITE or corresponding 1161 200 OK that was the first message exchange in the same dialog set- 1162 up. The same security properties used in the INVITE MUST be used in 1163 the UPDATE message. 1165 The UPDATE Method is to be used any time location information is to 1166 be updated between UAs setting up a dialog or after the dialog has 1167 been established, no matter how long that dialog has been 1168 operational. reINVITE is out of scope here, and the MESSAGE Method 1169 is for non-dialog location conveyance between UAs only. 1171 One reason for this message being generated is if either UA that 1172 sent its location information to the other UA (say in the INVITE and 1173 corresponding 200 OK) is if either UA determines that is has moved 1174 while the dialog has remained operational. How this movement is 1175 determined is outside the scope of this document, but ultimately 1176 should be configurable by local administration or the user of the 1177 UA. By how much Alice has moved to trigger the "sense of movement" 1178 (i.e. the need to send new location) to Bob is also outside the 1179 scope of this specification, but ultimately should be configurable 1180 by local administration or the user of the UA. 1182 In Figure 3., we have an example message flow involving the UPDATE 1183 Method. We are not including all the messages for space reasons. M1 1184 is a well formed SIP message that contains Alice's location. During 1185 the session set-up, Alice's UA knows it has moved while knowing too 1186 the session has not been formally accepted by Bob. Alice's UA 1187 decides to update Bob with her new location with an UPDATE Method 1188 message. Messages M2, M3 and M4 have nothing to do with location 1189 conveyance, therefore will not be shown in detail. Only M1 and M5 1190 will be shown. 1192 NOTE: A similar use for UPDATE is within the UA-to-Proxy Location 1193 Conveyance section of this document. 1195 UA Alice UA Bob 1197 | INVITE [M1] | 1198 |---------------------------------------->| 1199 | | 1200 | 183 (session Progress) [M2] | 1201 |<----------------------------------------| 1202 | | 1203 | PRACK [M3] | 1204 |---------------------------------------->| 1205 | | 1206 | ACK (PRACK) [M4] | 1207 |<----------------------------------------| 1208 | | 1209 | UPDATE [M5] | 1210 |---------------------------------------->| 1211 | | 1212 | ACK (UPDATE) [M6] | 1213 |<----------------------------------------| 1214 | | 1215 | 200 OK (INVITE) [M7] | 1216 |<----------------------------------------| 1217 | | 1218 | RTP | 1219 |<=======================================>| 1220 | | 1222 Figure 3. UA-UA with Location in UPDATE 1224 The following section will include the M1 and M5 messages in detail, 1225 but only in the civic format. 1227 8.3.1 UA-to-UA UPDATE with Civic Location Not Using S/MIME 1229 Here is the initial INVITE from Alice to Bob. 1231 [M1 INVITE to Bob] 1233 INVITE sips:bob@biloxi.example.com SIP/2.0 1234 Via: SIP/2.0/TLS pc33.atlanta.example.com 1235 ;branch=z9hG4bK776asdhds 1236 Max-Forwards: 70 1237 To: Bob 1238 From: Alice ;tag=1928301774 1239 Call-ID: a84b4c76e66710@pc33.atlanta.example.com 1240 CSeq: 314159 INVITE 1241 Contact: 1242 Content-Type: application/pkcs7-mime; 1243 smime-type=enveloped-data; name=smime.p7m 1244 Content-Disposition: attachment; 1245 filename=smime.p7m handling=required 1247 Content-Type: multipart/mixed; boundary=boundary1 1249 --boundary1 1251 Content-Type: application/sdp 1252 v=0 1253 o=alice 2890844526 2890844526 IN IP4 atlanta.example.com 1254 c=IN IP4 10.1.3.33 1255 t=0 0 1256 m=audio 49172 RTP/AVP 0 4 18 1257 a=rtpmap:0 PCMU/8000 1259 --boundary1 1261 Content-type: application/cpim-pidf+xml 1262 1263 1268 1269 2005-11-11T08:57:29Z 1270 1271 1272 1273 1274 US 1275 Illinois 1276 Chicago 1277 233 1278 South 1279 Wacker 1280 Drive 1281 60606 1282 Sears Tower 1283 1 1284 1285 dhcp 1286 802.11 1287 www.cisco.com 1288 1289 1290 no 1291 2005-11-13T14:57:29Z 1293 1294 1295 1296 1297 1299 --boundary1-- 1301 Alice moves locations (with her UA detecting the movement), causing 1302 her UA to generate an UPDATE message ([M5] of Figure 3) prior to 1303 her UA receiving a final response from Bob. Here is that message: 1305 M5 UPDATE to Bob 1307 UPDATE sips:bob@biloxi.example.com/TCP SIP/2.0 1308 Via: SIP/2.0/TLS pc33.atlanta.example.com 1309 ;branch=z9hG4bK776asdhds 1310 Max-Forwards: 70 1311 To: Bob 1312 From: Alice ;tag=1928 1313 Call-ID: a84b4c76e66710@pc33.atlanta.example.com 1314 CSeq: 10197 UPDATE 1315 Contact: 1316 Content-Type: application/pkcs7-mime; 1317 smime-type=enveloped-data; name=smime.p7m 1318 Content-Disposition: attachment; 1319 filename=smime.p7m handling=required 1321 Content-Type: multipart/mixed; boundary=boundary1 1323 --boundary1 1325 Content-Type: application/sdp 1326 v=0 1327 o=alice 2890844526 2890844526 IN IP4 atlanta.example.com 1328 c=IN IP4 10.1.3.33 1329 t=0 0 1330 m=audio 49172 RTP/AVP 0 4 18 1331 a=rtpmap:0 PCMU/8000 1333 --boundary1 1335 Content-type: application/cpim-pidf+xml 1336 1337 1342 1343 2005-11-11T08:57:29Z 1344 1345 1346 1347 1348 US 1349 Illinois 1350 Chicago 1351 250 1352 South Upper 1353 Wacker 1354 Drive 1355 60606 1356 Venice Cafe 1357 1 1358 1359 dhcp 1360 802.11 1361 www.t-mobile.com 1362 1363 1364 no 1365 2005-11-13T14:57:29Z 1367 1368 1369 1370 1371 1373 --boundary1-- 1375 8.4 UA-to-UA Location Conveyance Using PUBLISH 1377 ** This section could not be completed before submission time and 1378 will be completed shortly after IETF61. A thousand and one pardons. 1380 8.5 UA-to-UA Location Conveyance Using SUBSCRIBE and NOTIFY 1382 This section was not completed in time for the ID cut-off, thus all 1383 text was removed until it can be completed. The authors apologize. 1385 8.6 424 "Bad Location Information" Error Response 1387 In the case that a user agent server or SIP Proxy detects an error 1388 in a message containing location information specific to that 1389 message body, a new 4XX level error needs to be sent. This document 1390 creates the new error code: 1392 424 (Bad Location Information) 1394 This will provide the UAC with directed feedback about the status of 1395 location information it sent to that UAS or Proxy. The UAC MAY 1396 attempt to retry sending the message providing its location. 1398 This new error code will be IANA registered. 1400 An example flow of this scenario will be included in the next 1401 version of this internet draft. 1403 9. Special Considerations for Emergency Calls 1405 When a Proxy Server knows to look for a location message body to 1406 route an emergency call as in [ID-EMER-ARCH]. 1408 Emergency calls, which might be detected as detailed in [ID-SIP- 1409 SOS], have special rules for conveyance of location: 1411 1. An emergency call MUST have all LI available to the UA, if any, 1412 sent with the INVITE, and subsequent UPDATE or reINVITE messages 1413 as a PIDF-LO in a body 1415 2. The LO must be protected with sips: unless the attempt to 1416 establish hop-by-hop TLS connection fails and cannot reasonably 1417 be established in a very short (less than a second) time. In 1418 such a case, the LO SHOULD be sent without TLS ONLY for those 1419 hops that failed to support TLS establishment. 1421 3. User Agents MUST NOT use S/MIME 1423 4. User Agents MUST include the element in the PIDF-LO 1424 (if known) to give the PSAP an indication as to who is 1425 responsible for providing the UA with its location information. 1427 Proxies MUST NOT remove a location message body at any time. In the 1428 case where the Proxy knows the location of the UAC and does not 1429 detect the UAC's location information message body in the message 1430 (or determines the LO is bad), the Proxy generates a new 4XX (Retry 1431 Location Body) error message that includes a location information 1432 message body for that UAC to include in the subsequent message. The 1433 user agent MUST include this message body in the subsequent 1434 emergency message. 1436 In the element of the PIDF-LO, the Proxy MUST identify 1437 itself as the source of this location information. The user agent 1438 MUST NOT alter this field's value if received from a Proxy server. 1440 If the UAS of the PSAP receives a SIP request with multiple location 1441 objects, it must determine which to use, since more than one may be 1442 present. This specification does not limit the number of LOs in a 1443 message, even in session mode. 1445 9.1 UA-to-Proxy Routing the Message with INVITE (secure) 1447 When Alice signifies "sos@" [per 3], her UA must understand this 1448 message MUST NOT use S/MIME for the message body, because this is an 1449 emergency call - otherwise the message will not properly route to 1450 the correct destination. Two definite possibilities will exist for 1451 how this message flow will occur [note: the message flows are not 1452 being defined here, they are defined in [ID-EMER-ARCH], but two are 1453 shown here to show the messages themselves]. The first possibility 1454 has Alice sending her INVITE to her first hop Proxy, which 1455 recognizes the message as an emergency message. The Proxy knows to 1456 look into the message bodies for the location body; determine where 1457 Alice is and route the call to the appropriate PSAP. This is shown 1458 in Figure 4A. 1460 UA Alice Proxy PSAP 1462 | INVITE [M1] | | 1463 |------------------>| | 1464 | | INVITE [M2] | 1465 | |-------------------->| 1466 | | 200 OK [M3] | 1467 | |<--------------------| 1468 | 200 OK [M4] | | 1469 |<------------------| | 1470 | ACK [M5] | 1471 |---------------------------------------->| 1472 | RTP | 1473 |<=======================================>| 1474 | | 1476 Figure 4A. UA-PROXY with Location in INVITE 1478 [M1 of Figure 4A] 1480 INVITE sips:sos@atlanta.example.com SIP/2.0 1481 Via: SIP/2.0/TLS pc33.atlanta.example.com 1482 ;branch=z9hG4bK74bf9 1483 Max-Forwards: 70 1484 From: Alice ;tag=9fxced76sl 1485 To: 1486 Call-ID: 3848276298220188511@atlanta.example.com 1487 CSeq: 31862 INVITE 1488 Contact: 1489 Content-Type: multipart/mixed; boundary=boundary1 1490 Content-Length: ... 1492 --boundary1 1494 Content-Type: application/sdp 1495 v=0 1496 o=alice 2890844526 2890844526 IN IP4 atlanta.example.com 1497 c=IN IP4 10.1.3.33 1498 t=0 0 1499 m=audio 49172 RTP/AVP 0 4 18 1500 a=rtpmap:0 PCMU/8000 1502 --boundary1 1504 Once the Proxy receives M1 and recognizes it as an emergency INVITE 1505 Request, this proxy knows to look into the message body for a 1506 location body part to determine the location of the UAC in order to 1507 match the location to an PSAP. Once this look-up occurs, the 1508 message is sent directly to the PSAP (in message [M2]). 1510 [M2 of Figure 4A] - Proxy has determined when to send message 1512 INVITE sips:sos@192.168.10.20 SIP/2.0 1513 Via: SIP/2.0/TLS pc33.atlanta.example.com 1514 ;branch=z9hG4bK74bf9 1515 Max-Forwards: 69 1516 From: Alice ;tag=9fxced76sl 1517 To: 1518 Call-ID: 3848276298220188511@atlanta.example.com 1519 CSeq: 31862 INVITE 1520 Contact: 1521 Content-Type: multipart/mixed; boundary=boundary1 1522 Content-Length: ... 1524 --boundary1 1526 Content-Type: application/sdp 1527 v=0 1528 o=alice 2890844526 2890844526 IN IP4 atlanta.example.com 1529 c=IN IP4 10.1.3.33 1530 t=0 0 1531 m=audio 49172 RTP/AVP 0 4 18 1532 a=rtpmap:0 PCMU/8000 1534 --boundary1 1536 Content-type: application/cpim-pidf+xml 1537 1538 1543 1544 2005-11-11T08:57:29Z 1545 1546 1547 1548 1549 US 1550 Illinois 1551 Chicago 1552 233 1553 South 1554 Wacker 1555 Drive 1556 60606 1557 Sears Tower 1558 1 1559 1560 dhcp 1561 802.11 1562 www.t-mobile.com 1563 1564 1565 no 1566 2005-11-13T14:57:29Z 1568 1569 1570 1571 1572 1574 --boundary1-- 1576 The second probability in message flows is in Figure 4B. in which 1577 the first hop Proxy1 does not either: understand location, or does 1578 not know where the appropriate PSAP is to route the message to. In 1579 either case, that Proxy(1) forwards the message to another Proxy(2) 1580 for proper message routing ([ID-EMER-ARCH] talks to how this 1581 occurs). 1583 UA Alice Proxy1 Proxy2 PSAP 1585 | INVITE [M1] | | | 1586 |------------>| | | 1587 | | INVITE [M2] | | 1588 | |------------>| | 1589 | | | INVITE [M3] | 1590 | | |------------>| 1591 | | | 200 OK [M4] | 1592 | | |<------------| 1593 | | 200 OK [M5] | | 1594 | |<------------| | 1595 | 200 OK [M6] | | | 1596 |<------------| | | 1597 | ACK [M7] | 1598 |---------------------------------------->| 1599 | RTP | 1600 |<=======================================>| 1601 | | 1603 Figure 4B. UA-PROXY with Location in INVITE 1605 In message flows similar to 4A and/or 4B, the Record-Route header 1606 could be added by the proxies, this is OPTIONAL in usage and left to 1607 other documents to refine. 1609 In the case of an identifiable emergency call, something that cannot 1610 happen is for any Proxy to Challenge [per RFC3261] the INVITE 1611 message. In fact, while usage of the SIPS URI is encouraged and 1612 SHOULD be used, it MUST NOT be mandatory for successful message 1613 routing. If the first SIPS INVITE fails for security property 1614 reasons, the second attempt by Alice (in these examples) MUST be 1615 allowed to be in the clear, not challenged, and routed properly. 1616 Security mechanisms MUST NOT fail any call attempt, and if they do 1617 once, they MUST NOT be mandatory for the subsequent attempt for a 1618 successful session set-up to an PSAP. The results of this are that 1619 the Proxy that failed the first attempt for security reasons MUST be 1620 aware of this failed attempt for the subsequent attempt that MUST 1621 process without failure a second time. It must be assumed that the 1622 INVITE in any instance is considered "well formed". 1624 The remaining messages in both 4A and 4B are not included at this 1625 time. If the working groups wants these added, they will be in the 1626 next revision of this document. 1628 9.1.1 UA-to-Proxy Routing the Message with INVITE (unsecure) 1629 Below can be considered the initial unsecure INVITE M1 from Figures 1630 4A and 4A, or the second attempt message to an initial message that 1631 was failed by a Proxy. This version of M1 is not using any security 1632 measures and is using the civic format message body that is the 1633 identical location to the previous example. 1635 [Message M1 from Figure 4A] 1637 INVITE sip:sos@atlanta.example.com SIP/2.0 1638 Via: SIP/2.0/TCP pc33.atlanta.example.com 1639 ;branch=z9hG4bK74bf9 1640 Max-Forwards: 70 1641 From: Alice ;tag=9fxced76sl 1642 To: 1643 Call-ID: 3848276298220188511@atlanta.example.com 1644 CSeq: 31862 INVITE 1645 Contact: 1646 Content-Type: multipart/mixed; boundary=boundary1 1647 Contact-Length: ... 1649 --boundary1 1651 Content-Type: application/sdp 1652 v=0 1653 o=alice 2890844526 2890844526 IN IP4 atlanta.example.com 1654 c=IN IP4 10.1.3.33 1655 t=0 0 1656 m=audio 49172 RTP/AVP 0 4 18 1657 a=rtpmap:0 PCMU/8000 1659 --boundary1 1661 Content-type: application/cpim-pidf+xml 1662 1663 1668 1669 2005-11-11T08:57:29Z 1670 1671 1672 1673 1674 US 1675 Illinois 1676 Chicago 1677 233 1678 South 1679 Wacker 1680 Drive 1681 60606 1682 Sears Tower 1683 1 1684 1685 dhcp 1686 802.11 1687 www.t-mobile.com 1688 1689 1690 no 1691 2005-11-13T14:57:29Z 1693 1694 1695 1696 1697 1699 --boundary1-- 1701 9.2 UA-to-Proxy Routing with UPDATE 1703 If the previous example of the location contained in the INVITE were 1704 to account for the movement of Alice (and her UA) before the PSAP 1705 responded with a 200 OK, the UPDATE method is the appropriate SIP 1706 Request Method to use to update the proxies and PSAP personnel that 1707 Alice has moved locations from where she initially made her set-up 1708 request. 1710 In this scenario (shown in the call flow of Figure 5A), Alice 1711 sending the UPDATE message here may cause the Proxy to CANCEL an 1712 existing pending INVITE Request, and retransmit INVITE to a NEW 1713 PSAP(2), for example, if she walked across a street into a new PSAP 1714 coverage area. The Proxy MUST remain transaction stateful in order 1715 to be aware of the 200 OK Response from PSAP1. Upon receiving the 1716 UPDATE from Alice and analyzing the location provided by the message 1717 looking for a location change, either forwarding that message to 1718 PSAP1 if the change is still within PSAP1's coverage area, or 1719 deciding to forward a message to another PSAP covering where Alice 1720 is now (PSAP2 in this case) with her new location. If the latter 1721 change in destinations is required, the Proxy MUST CANCEL the 1722 pending INVITE to PSAP1 (with a 487 "terminated request" being the 1723 specified response). 1725 SIPS SHOULD be used by Alice initially. Upon any failure of the 1726 initial Request, Alice's UA MUST decide to send the new message 1727 without SIPS. 1729 UA Alice Proxy PSAP1 PSAP2 1731 | INVITE [M1] | | | 1732 |---------------->| | | 1733 | | INVITE [M2] | | 1734 | |------------>| | 1735 | 183 SP [M3] | | | 1736 |<----------------| | | 1737 | PRACK [M4] | | | 1738 |---------------->| | | 1739 | 200 OK (PR)[M5] | | | 1740 |<----------------| | | 1741 | UPDATE [M6] | | | 1742 |---------------->| | | 1743 | 200 OK (UP)[M7] | | | 1744 |<----------------| | | 1745 | | CANCEL [M8] | | 1746 | |------------>| | 1747 | | 487 [M9] | | 1748 | |<------------| | 1749 | | INVITE [M10] | 1750 | |-------------------------->| 1751 | | 200 OK (INV) [M11] | 1752 | |<--------------------------| 1753 |200 OK (INV)[M12]| | 1754 |<----------------| | 1755 | ACK [M13] | 1756 |-------------------------------------------->| 1757 | RTP | 1758 |<===========================================>| 1759 | | 1761 Figure 5A. UA-PROXY with Location in UPDATE 1763 ** see new open issue #9 for the problems with messages 8 through 10 1764 ** of the above flow. 1766 9.2.1 UA-to-Proxy Routing the Message with UPDATE (secure) 1768 INVITE sip:sos@atlanta.example.com SIP/2.0 1769 Via: SIP/2.0/TCP pc33.atlanta.example.com 1770 ;branch=z9hG4bK74bf9 1771 Max-Forwards: 70 1772 From: Alice ;tag=9fxced76sl 1773 To: 1774 Call-ID: 3848276298220188511@atlanta.example.com 1775 CSeq: 31862 INVITE 1776 Contact: 1777 Content-Type: multipart/mixed; boundary=boundary1 1778 Contact-Length: ... 1780 --boundary1 1782 Content-Type: application/sdp 1783 v=0 1784 o=alice 2890844526 2890844526 IN IP4 atlanta.example.com 1785 c=IN IP4 10.1.3.33 1786 t=0 0 1787 m=audio 49172 RTP/AVP 0 4 18 1788 a=rtpmap:0 PCMU/8000 1790 --boundary1 1792 Content-type: application/cpim-pidf+xml 1793 1794 1799 1800 2005-11-11T08:57:29Z 1801 1802 1803 1804 1805 US 1806 Illinois 1807 Chicago 1808 233 1809 South 1810 Wacker 1811 Drive 1812 60606 1813 Sears Tower 1814 1 1815 1816 dhcp 1817 802.11 1818 www.cisco.com 1819 1820 1821 no 1822 2005-11-13T14:57:29Z 1824 1825 1826 1827 1828 1830 --boundary1-- 1831 Alice moves locations (with her UA detecting the movement), causing 1832 her UA to generate an UPDATE message ([M5] of Figure 3) prior to her 1833 UA receiving a final response from the PSAP. In this case, Alice 1834 has walked across the South Wacker Drive to another building. Here 1835 is that message: 1837 [M5 UPDATE to PSAP] 1839 UPDATE sips:bob@biloxi.example.com/TCP SIP/2.0 1840 Via: SIP/2.0/TLS pc33.atlanta.example.com 1841 ;branch=z9hG4bK776asdhds 1842 Max-Forwards: 70 1843 From: Alice ;tag=9fxced76sl 1844 To: 1845 Call-ID: 3848276298220188511@atlanta.example.com 1846 CSeq: 10187 UPDATE 1847 Contact: 1848 Content-Type: multipart/mixed; boundary=boundary1 1849 Contact-Length: ... 1851 --boundary1 1853 Content-Type: application/sdp 1854 v=0 1855 o=alice 2890844526 2890844526 IN IP4 atlanta.example.com 1856 c=IN IP4 10.1.3.33 1857 t=0 0 1858 m=audio 49172 RTP/AVP 0 4 18 1859 a=rtpmap:0 PCMU/8000 1861 --boundary1 1863 Content-type: application/cpim-pidf+xml 1864 1865 1870 1871 2005-11-11T08:57:29Z 1872 1873 1874 1875 1876 US 1877 Illinois 1878 Chicago 1879 250 1880 South Upper 1881 Wacker 1882 Drive 1883 60606 1884 Venice Cafe 1885 1 1886 1887 dhcp 1888 802.11 1889 www.t-mobile.com 1890 1891 1892 no 1893 2005-11-13T14:57:29Z 1895 1896 1897 1898 1899 1901 --boundary1-- 1903 9.2.2 UA-to-Proxy Routing the Message with UPDATE (unsecure) 1905 left blank for now 1907 9.3 425 "Retry Location Body" Error Response 1909 In the case that a SIP Proxy detects an error in a SIP message 1910 containing location information specific to that message body and 1911 has the location of that UAC locally, a new 4XX level error needs to 1912 be sent back to the UAC containing a new Location Object message 1913 body of the UAC as the SIP intermediary understands where the UAC is 1914 with the intent of the UAC including this LO message body in a 1915 subsequent message to the originally addressed UAS. This document 1916 creates the new error code: 1918 425 (Retry Location Body) 1920 The UAC MUST include the SIP intermediary provided LO message body 1921 in the retransmission of the rejected message to the original UAS if 1922 the UAC attempts this communication. User agents may conclude they 1923 have already supplied a proper LO in the rejected request. That LO 1924 can be resent, but the intermediary supplied LO MUST be included as 1925 well. 1927 This new error code will be IANA registered. 1929 An example flow of this scenario will be included in the next 1930 version of this internet draft. 1932 10. Meeting RFC3693 Requirements 1934 Section 7.2 of [RFC3693] details the requirements of a "using 1935 protocol". They are: 1937 Req. 4. The using protocol has to obey the privacy and security 1938 instructions coded in the Location Object and in the 1939 corresponding Rules regarding the transmission and storage of the 1940 LO. 1942 This document requires, in Section 7, that SIP entities sending or 1943 receiving location MUST obey such instructions. 1945 Req. 5. The using protocol will typically facilitate that the keys 1946 associated with the credentials are transported to the respective 1947 parties, that is, key establishment is the responsibility of the 1948 using protocol. 1950 [RFC3261] and the documents it references define the key establish 1951 mechanisms. 1953 Req. 6. (Single Message Transfer) In particular, for tracking of 1954 small target devices, the design should allow a single 1955 message/packet transmission of location as a complete 1956 transaction. 1958 This document specifies that the LO be contained in the body of a 1959 single message. 1961 11. Current Known Open issues 1963 This is a list of open issues that have not yet been addressed to 1964 conclusion: 1966 1) Still have not determined how a SIP entity can request location 1967 to be delivered in a certain format (civil vs. coordinate). 1969 11.1 New Open Issues 1971 These are new open issues to be addressed within this document or 1972 the topics/areas dropped from consideration: 1974 1) May add a section for end-to-middle in a services model 1976 12. Security Considerations 1978 Conveyance of geo-location of a UAC is problematic for many reasons. 1979 This document calls for that conveyance to normally be accomplished 1980 through secure message body means (like S/MIME or TLS). In cases 1981 where a session set-up is routed based on the location of the UAC 1982 initiating the session or SIP MESSAGE, securing the location with an 1983 end-to-end mechanism such as S/MIME is problematic. 1985 13. IANA Considerations 1987 This section defines two new 4XX error response codes within the 1988 sip-parameters section of IANA. [NOTE: RFC XXXX denotes this 1989 document. 1991 13.1 IANA Registration for Response Code 4XX 1993 Reference: RFC-XXXX (this document) 1994 Response code: 424 1995 Default reason phrase: Bad Location Information 1997 13.2 IANA Registration for Response Code 4XX 1999 Reference: RFC-XXXX (this document) 2000 Response code: 425 2001 Default reason phrase: Retry Location Body 2003 14. Acknowledgements 2005 To Dave Oran for helping to shape this idea. To Jon Peterson and 2006 Dean Willis on guidance of the effort. To Henning Schulzrinne, 2007 Jonathan Rosenberg, Dick Knight, Mike Hammer and Keith Drage for 2008 constructive feedback. 2010 15. References 2012 15.1 References - Normative 2014 [RFC3261] J. Rosenberg, H. Schulzrinne, G. Camarillo, A. Johnston, J. 2015 Peterson, R. Sparks, M. Handley, and E. Schooler, "SIP: 2016 Session Initiation Protocol", RFC 3261, May 2002. 2018 [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate 2019 Requirement Levels", RFC 2119, March 1997 2021 [ID-SIP-SOS] H. Schulzrinne, "draft-ietf-sipping-sos-00.txt", Internet 2022 Draft, Feb 2004, Work in progress 2024 [RFC3428] B. Campbell, Ed., J. Rosenberg, H. Schulzrinne, C. Huitema, 2025 D. Gurle, "Session Initiation Protocol (SIP) Extension for 2026 Instant Messaging" , RFC 3428, December 2002 2028 [RFC3825] J. Polk, J. Schnizlein, M. Linsner, "Dynamic Host 2029 Configuration Protocol Option for Coordinate-based Location 2030 Configuration Information", RFC 3825, July 2004 2032 [ID-CIVIC] H. Schulzrinne, "draft-ietf-geopriv-dhcp-civic-06.txt", 2033 Internet Draft, May 05, Work in progress 2035 [RFC3693] J. Cuellar, J. Morris, D. Mulligan, J. Peterson. J. Polk, 2036 "Geopriv Requirements", RFC 3693, February 2004 2038 [RFC3311] J. Rosenberg, "The Session Initiation Protocol (SIP) UPDATE 2039 Method", RFC 3311, October 2002 2041 [RFC3903] Niemi, A., "Session Initiation Protocol (SIP) Extension 2042 for Event State Publication", RFC 3903, October 2004. 2044 [ID-PIDF-LO] J. Peterson, "draft-ietf-geopriv-pidf-lo-03", Internet 2045 Draft, Sept 2004, work in progress 2047 [RFC3264] J. Rosenberg, H. Schulzrinne, "The Offer/Answer Model with 2048 Session Description Protocol", RFC 3264, June 2002 2050 [RFC3515] R. Sparks, "The Session Initiation Protocol (SIP) Refer 2051 Method", RFC 3515, April 2003 2053 [RFC3265] Roach, A., "Session Initiation Protocol (SIP)-Specific 2054 Event Notification", RFC 3265, June 2002. 2056 16.1 References - Informative 2058 [ID-End-Mid-Sec] "Requirements for End to Middle Security in SIP", 2059 draft-ietf-sipping-e2m-sec-reqs-03.txt, Internet Draft, June 2060 2004, work in progress, 2062 [ID-Sess-Pol] J. Rosenberg, "Requirements for Session Policy for the 2063 Session Initiation Protocol�, draft-ietf-sipping-session- 2064 policy-req-00", Internet Draft, June, 2003, "work in 2065 progress" 2067 [ID-EMER-ARCH] H. Schulzrinne, B. Rosen, "draft-schulzrinne-sipping- 2068 emergency-arch", Internet Draft, Feb 2004, work in progress 2070 16. Author Information 2072 James M. Polk 2073 Cisco Systems 2074 2200 East President George Bush Turnpike 33.00111N 2075 Richardson, Texas 75082 USA 96.68142W 2076 jmpolk@cisco.com 2077 Brian Rosen 40.4N 2078 br@brianrosen.net 80.0W 2080 Appendix A. Additional stuff 2082 This section is coming in the next release. 2084 Intellectual Property Statement 2086 The IETF takes no position regarding the validity or scope of any 2087 Intellectual Property Rights or other rights that might be claimed 2088 to pertain to the implementation or use of the technology described 2089 in this document or the extent to which any license under such 2090 rights might or might not be available; nor does it represent that 2091 it has made any independent effort to identify any such rights. 2092 Information on the procedures with respect to rights in RFC 2093 documents can be found in BCP 78 and BCP 79. 2095 Copies of IPR disclosures made to the IETF Secretariat and any 2096 assurances of licenses to be made available, or the result of an 2097 attempt made to obtain a general license or permission for the use 2098 of such proprietary rights by implementers or users of this 2099 specification can be obtained from the IETF on-line IPR repository 2100 at http://www.ietf.org/ipr. 2102 The IETF invites any interested party to bring to its attention any 2103 copyrights, patents or patent applications, or other proprietary 2104 rights that may cover technology that may be required to implement 2105 this standard. Please address the information to the IETF at 2106 ietf-ipr@ietf.org. 2108 Disclaimer of Validity 2110 This document and the information contained herein are provided on 2111 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 2112 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE 2113 INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR 2114 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 2115 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 2116 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 2118 Copyright Statement 2120 Copyright (C) The Internet Society (2005). This document is subject 2121 to the rights, licenses and restrictions contained in BCP 78, and 2122 except as set forth therein, the authors retain all their rights. 2124 Acknowledgment 2126 Funding for the RFC Editor function is currently provided by the 2127 Internet Society. 2129 The Expiration date for this Internet Draft is: 2131 December 17th, 2005