idnits 2.17.1 draft-ietf-sipping-location-requirements-02.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 3667, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5 on line 2328. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 2339. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 2346. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 2352. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 2320), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 36. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** 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. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == There are 4 instances of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 47 longer pages, the longest (page 4) being 77 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 47 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 14 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 -- 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) -- Looks like a reference, but probably isn't: 'M1' on line 1945 -- Looks like a reference, but probably isn't: 'M2' on line 1947 -- Looks like a reference, but probably isn't: 'M3' on line 1949 -- Looks like a reference, but probably isn't: 'M4' on line 1951 -- Looks like a reference, but probably isn't: 'M5' on line 2048 -- Looks like a reference, but probably isn't: 'M6' on line 1955 -- Looks like a reference, but probably isn't: 'M7' on line 1957 -- Looks like a reference, but probably isn't: 'M8' on line 1959 -- Looks like a reference, but probably isn't: 'M9' on line 1961 -- Looks like a reference, but probably isn't: 'M10' on line 1963 -- Looks like a reference, but probably isn't: 'M11' on line 1965 -- Looks like a reference, but probably isn't: 'M12' on line 941 -- Looks like a reference, but probably isn't: 'M13' on line 1969 == Unused Reference: '5' is defined on line 2270, but no explicit reference was found in the text == Unused Reference: '6' is defined on line 2273, but no explicit reference was found in the text == Unused Reference: '10' is defined on line 2286, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. '3' ** Obsolete normative reference: RFC 3825 (ref. '5') (Obsoleted by RFC 6225) -- Possible downref: Non-RFC (?) normative reference: ref. '6' ** Downref: Normative reference to an Informational RFC: RFC 3693 (ref. '7') == Outdated reference: A later version (-02) exists of draft-ietf-sipping-session-policy-req-00 -- Possible downref: Normative reference to a draft: ref. '8' -- Possible downref: Non-RFC (?) normative reference: ref. '10' -- Possible downref: Non-RFC (?) normative reference: ref. '11' == Outdated reference: A later version (-06) exists of draft-ietf-sipping-e2m-sec-reqs-03 ** Downref: Normative reference to an Informational draft: draft-ietf-sipping-e2m-sec-reqs (ref. '12') -- Possible downref: Non-RFC (?) normative reference: ref. '13' Summary: 9 errors (**), 0 flaws (~~), 11 warnings (==), 26 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force James M. Polk 2 Internet Draft Cisco Systems 3 Expiration: April 25th, 2005 Brian Rosen 4 File: draft-ietf-sipping-location-requirements-02.txt Emergicom 6 Requirements for 7 Session Initiation Protocol Location Conveyance 9 October 25th, 2004 11 Status of this Memo 13 By submitting this Internet-Draft, I certify that any applicable 14 patent or other IPR claims of which I am aware have been disclosed, 15 and any of which I become aware will be disclosed, in accordance 16 with RFC 3668. 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 21 Internet-Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six 24 months and may be updated, replaced, or obsoleted by other documents 25 at any time. It is inappropriate to use Internet-Drafts as 26 reference material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 Copyright Notice 36 Copyright (C) The Internet Society (2004). All Rights Reserved. 38 Abstract 40 This document presents the framework and requirements for usage of 41 the Session Initiation Protocol (SIP) to convey user location 42 information from one Session Initiation Protocol (SIP) entity to 43 another SIP entity. We consider cases where location information is 44 conveyed from end to end, as well as cases where message routing by 45 intermediaries is influenced by the location of the session 46 initiator. We offer a set of solutions to the requirements, based 47 on the scenario(s) being addressed. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 52 1.1 Conventions . . . . . . . . . . . . . . . . . . . . . . . 3 53 1.2 Changes from Prior Versions . . . . . . . . . . . . . . . 3 54 2. In the Body or in a Header . . . . . . . . . . . . . . . . . 5 55 3. Scope of Location in a Message Body . . . . . . . . . . . . . 6 56 4. Requirements for UA-to-UA Location Conveyance . . . . . . . . 7 57 5. Requirements for UA-to-Proxy Server Location Conveyance . . . 7 58 6. Additional Requirements for Emergency Calls . . . . . . . . . 8 59 7. Location Conveyance Using SIP . . . . . . . . . . . . . . . . 10 60 8. Location Conveyance UA-to-UA . . . . . . . . . . . . . . . . 12 61 8.1 UA-to-UA Using INVITE . . . . . . . . . . . . . . . . . . 12 62 8.1.1 UA-to-UA Using INVITE with Coordinate Format. . . . . 13 63 8.1.2 UA-to-UA Using INVITE with Civic Format . . . . . . . 15 64 8.1.3 UA-to-UA Using INVITE Involving 3 Users . . . . . . . 18 65 8.2 UA-to-UA Using MESSAGE . . . . . . . . . . . . . . . . . 24 66 8.3 UA-to-UA Using UPDATE . . . . . . . . . . . . . . . . . . 27 67 8.4 UA-to-UA Using PUBLISH . . . . . . . . . . . . . . . . . 32 68 8.5 UA-to-UA Location Conveyance Using SUBSCRIBE and NOTIFY . 32 69 8.6 424 "Bad Location Information" Error Response . . . . . . 32 70 9. Special Considerations for Emergency Calls . . . . . . . . . 32 71 9.1 UA-to-Proxy Using INVITE . . . . . . . . . . . . . . . . 33 72 9.2 UA-to-Proxy Using UPDATE . . . . . . . . . . . . . . . . 38 73 9.3 425 "Retry Location Body" Error Response . . . . . . . . 42 74 10. Meeting RFC 3693 Requirements . . . . . . . . . . . . . . . . 43 75 11. Current Known Open issues . . . . . . . . . . . . . . . . . . 43 76 12. New Open issues . . . . . . . . . . . . . . . . . . . . . . . 44 77 13. Security Considerations . . . . . . . . . . . . . . . . . . . 44 78 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . 44 79 14.1 IANA Registration for Response Code 424 . . . . . . . . 45 80 14.2 IANA Registration for Response Code 425 . . . . . . . . 45 81 15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 45 82 16. References . . . . . . . . . . . . . . . . . . . . . . . . . 45 83 16.1 Normative References . . . . . . . . . . . . . . . . . 45 84 17. Author Information . . . . . . . . . . . . . . . . . . . . . 46 86 1. Introduction 88 This document presents the framework and requirements for the usage 89 of the Session Initiation Protocol (SIP) [1] for conveyance of user 90 location information described by [7] from a SIP entity to another 91 SIP entity. 93 There are several situations in which it is appropriate for SIP to 94 be used to convey Location Information (LI) from one SIP entity to 95 another. This document specifies requirements when a SIP UAC knows 96 its location by some means not specified herein, and needs to inform 97 another SIP entity. One example is one user agent informing another 98 user agent where it is (you want to tell your friend where you are). 100 Another example is to reach your nearest pizza parlor. A chain of 101 pizza parlors may have a single well known uri 102 (sip:pizzaparlor.com), that is forwarded to the closest franchise by 103 the pizzaparlor.com proxy server. The receiving franchise UAS uses 104 the location information of the UAC to schedule your delivery. 106 Another important example is emergency calling. A call to 107 sip:sos@example.com is an emergency call as in [3]. The example.com 108 proxy server must route the call to the correct emergency response 109 center (ERC) determined by the location of the caller. At the ERC, 110 the UAS must determine the correct police/fire/ambulance/... 111 service, which is also based on your location. In many 112 jurisdictions, precise location information of the caller in 113 distress is a required component of a call to an emergency center. 115 A forth example is a direction service, which might give you verbal 116 directions to a venue from your present position. This is a case 117 where only the destination UAS needs to receive the location 118 information. 120 This document does not discuss how the UAC discovers or is 121 configured with its location (either coordinate or civic based). It 122 also does not discuss the contents of the Location Object (LO). It 123 does specify the requirements for the "using protocol" as defined by 124 Geopriv in [7]. 126 Sections 7, 8 and 9 give specific examples (in well-formed SIP 127 messages) of SIP UA and Proxy behavior for location conveyance, the 128 last of which is a section devoted to the unique circumstances 129 regarding emergency calling. Section 10 addresses how this document 130 adheres to the requirements specified in [7] (Geopriv Requirements). 131 Sections 11 and 12 list the current open issues with location 132 conveyance in SIP, and the new open issues recently discovered as a 133 result of the added effort to this revision. 135 1.1 Conventions used in this document 137 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 138 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and 139 "OPTIONAL" in this document are to be interpreted as described 140 in [2]. 142 1.2 Changes from Prior Versions 144 [NOTE TO RFC-EDITOR: If this document is to be published as an RFC, 145 this section is to be removed prior to that event.] 147 This is a list of the changes that have been made from the -01 148 working group version of this effort to this -02 version: 150 - added requirements for 2 new 4XX error responses (Bad Location 151 Information) and (Retry Location Body) 153 - added "Bad Location Information" as section 8.6 155 - added "Retry Location Body " as section 9.3 157 - added support for session mode to cover packet sizes larger than 158 the single packet limit of 1300 bytes in the message body 160 - added requirement for a SIP entity to SUBSCRIBE to another for 161 location information 163 - added SUBSCRIBE and NOTIFY as section 8.5 165 - added requirement to have user turn off any tracking created by 166 subscription 168 - removed doubt about which method to use for updating location 169 after a INVITE is sent (update) 171 - cleaned up which method is to be used if there is no dialog 172 existing (message) 174 - removed use of reINVITE to convey location 176 - clarified that UAs include element of PIDF-LO when 177 placing an emergency call (to inform ERC who supplied Location 178 information) 180 - updated list of open issues 182 - added to IANA Considerations section for the two new 4XX level 183 error responses requested in the last meeting 185 This is a list of the changes that have been made from the -00 186 working group version of this ID to this version: 188 - Added the offered solution in detail (with message flows, 189 appropriate SIP Methods for location conveyance, and 191 - Synchronized the requirements here with those from the Geopriv 192 Working Group's (attempting to eliminate overlap) 194 - Took on the task of making this effort the SIP "using protocol" 195 specification from Geopriv's POV 197 - Refined the Open Issues section to reflect the progress we've made 198 here, and to indicate what we have discovered needs addressing, 199 but has not been to date. 201 This is a list of the changes that have been made from the -01 202 individual submission version to the WG -00 version of this ID: 204 - Brian Rosen was brought on as a co-author 206 - Requirements that a location header were negatively received in 207 the previous version of this document. AD and chair advice was to 208 move all location information into a message body (and stay away 209 from headers) 211 - Added a section of "emergency call" specific requirements 213 - Added an Open Issues section to mention what hasn't been resolved 214 yet in this effort 216 This is a list of the changes that have been made from the 217 individual submission version -00 to the -01 version 219 - Added the IPR Statement section 221 - Adjusted a few requirements based on suggestions from the 222 Minneapolis meeting 224 - Added requirements that the UAC is to include from where it 225 learned its location in any transmission of its LI 227 - Distinguished the facts (known to date) that certain jurisdictions 228 relieve persons of their right to privacy when they call an ERC, 229 while other jurisdictions maintain a person's right to privacy, 230 while still others maintain a person's right to privacy - but only 231 if they ask that their service be set up that way. 233 - Made the decision that TLS is the security mechanism for location 234 conveyance in emergency communications (vs. S/MIME, which is still 235 the mechanism for UA-to-UA non-emergency location conveyance 236 cases). 238 - Added the Open Issue of whether a Proxy can insert location 239 information into an emergency SIP INVITE message, and some of the 240 open questions surrounding the implications of that action 242 - added a few names to the acknowledgements section 244 2. In the Body or in a Header 246 When one user agent wants to inform another user agent where they 247 are, it seems reasonable to have this accomplished by placing the 248 location information (coordinate or civic) in an S/MIME registered 249 and encoded message body, and sending it as part of a SIP request or 250 response. No routing of the request based on the location 251 information is required in this case; therefore no SIP Proxies 252 between these two UAs need to view the location information 253 contained in the SIP messages. 255 Although SIP [1} does not permit a proxy server to modify or delete 256 a body, there is no restriction on viewing bodies. However, S/MIME 257 protection implemented on bodies is only specified between UAC and 258 UAS, and if engaged, would render the location object opaque to a 259 proxy server for any desired modification if it is not correct or 260 precise enough from that proxy's point of view (were it to be able 261 to view it). This problem is similar to that raised in Session 262 Policy [8], where an intermediary may need information in a body, 263 such as IP address of media streams or codec choices to route a call 264 properly. Requirements in [8] are applicable to routing based on 265 location, and are incorporated in these requirements by reference. 267 It is conceivable to create a new header for location information. 268 However, [7] prefers S/MIME for security of Location Information, 269 and indeed S/MIME is preferable in SIP for protecting one part of a 270 message. Accordingly, these requirements specify location be 271 carried in a body. 273 It is the use of S/MIME however, that limits routing based on 274 location. Therefore, it seems appropriate to require that, where 275 routing is dependent on location, protection of the location 276 information object be accomplished by other mechanisms: here TLS 277 ("sips:" from [1]). It is envisioned that S/MIME SHOULD be used 278 when location information is not required by proxy servers, and TLS 279 MUST be used when it is. The UAC will need to know the difference 280 in the call's intent as to which security mechanism to engage for LI 281 conveyance. 283 This document does not address the behavior or configuration of SIP 284 Proxy Servers in these cases in order to accomplish location- 285 sensitive routing. That is out of scope, and left for further 286 (complementary) efforts. 288 3. Scope of Location in a Message Body 290 As concluded from the previous section, location information is to 291 be contained within a message body. If either another body (SDP for 292 example) is also to be sent in the message, or the LI is to be 293 protected with S/MIME, the rules stated in section 7 of [1] 294 regarding multipart MIME bodies MUST be followed. The format and 295 privacy/security rules of the location information SHOULD be defined 296 within the Geopriv WG. 298 User agents providing location can perform this function 299 incorrectly. Therefore, there needs to be a UAC error response code 300 created to inform the UAC by a UAS or Proxy of this incorrect 301 request message containing location information. 303 There will be times in which the UAC does not know its location 304 information, or another SIP entity knows the UAC's location better 305 than the UAC itself. How this is determined is out of scope of this 306 document. In these times, a Proxy servers that knows the location 307 of the UAC needs inform the UAC of its location information and have 308 that UAC include that message body in its next SIP message to the 309 same destination UA. This error code needs to be unique with 310 respect to the error code for merely incorrect location information 311 from the UAC. 313 4. Requirements for UA-to-UA Location Conveyance 315 The following are the requirements for UA-to-UA Location Conveyance 316 Situations where routing is not based on the LI of either UA: 318 U-U1 - MUST work with dialog-initiating SIP Requests and responses, 319 as well as the SIP MESSAGE method [4], and SHOULD work with 320 most SIP messages. 322 U-U2 - UAC Location information SHOULD remain confidential in route 323 to the destination UA. 325 U-U3 - The privacy and security rules established within the 326 Geopriv Working Group that would categorize SIP as a 'using 327 protocol' MUST be met [7]. 329 U-U4 - Location information MUST be contained in the location 330 Object as defined in [13], which will satisfy all format 331 requirements for interoperability. 333 U-U5 - SHOULD be able to communicate location between user agents 334 with as many packets as is necessary. 336 U-U6 - There MUST be a unique UAC error response code informing the 337 UAC is did not provide valid location information. 339 5. Requirements for UA-to-Proxy Server Location Conveyance 341 The following are the requirements for UA-to-Proxy Server Location 342 Conveyance situations: 344 U-PS1 - MUST work with dialog-initiating SIP Requests and 345 responses, as well as the SIP MESSAGE method[4], and SHOULD 346 work with most SIP messages. 348 U-PS2 - UAC location information SHOULD remain confidential with 349 respect to entities to which the location information is 350 not addressed, but MUST be useable by intermediary proxy 351 servers. 353 U-PS3 - The privacy and security rules established within the 354 Geopriv Working Group which would categorize SIP as a 355 'using protocol' MUST be met [7]. 357 U-PS4 - Modification or removal of the LO by proxy servers MUST NOT 358 be required (as [1] currently forbids this). 360 U-PS5 - any mechanism used to prevent unwanted observation of this 361 Location Information MUST NOT fail the SIP Request if not 362 understood by intermediary SIP entities or the destination 363 UAS. 365 U-PS6 - Proxy Servers that do not or cannot understand the Location 366 Information in the message body for routing purposes MUST 367 NOT fail the SIP Request. 369 U-PS7 � It MUST be possible for a proxy server to assert the 370 validity of the location information provided by the UA. 371 Alternatively, it is acceptable for there to be a mechanism 372 for a proxy server to assert a location object itself. 374 U-PS8 - There MUST be a unique UAC error response code informing 375 the UAC is did not provide valid location information. 377 U-PS9 - There MUST be a unique UAC error response code informing 378 the UAC it did not provide valid location information, and 379 to include the location information contained in the 380 message body of the error message in its next attempt to 381 the same UAS of the original message. 383 6. Additional Requirements for Emergency Calls 385 Emergency calls have requirements that are not generally important 386 to other uses for location in SIP: 388 Emergency calls presently have between 2 and 8-second call setup 389 times. There is ample evidence that the longer call setup end of 390 the range causes an unacceptable number of callers to abandon the 391 call before it is completed. Two-second call completion time is a 392 goal of many existing emergency call centers. Allocating 25% of the 393 call set up for processing privacy concerns seems reasonable; 1 394 second would be 50% of the goal, which seems unacceptable; less than 395 0.5 second seems unachievable, therefore: 397 E-1 - Privacy mechanisms MUST add no more than 0.5 second of call 398 setup time when implemented in present technology UAs and 399 Proxy Servers. 401 It may be acceptable for full privacy mechanisms related to the 402 location of the UAC (and it's user) to be tried on an initial 403 attempt to place a call, as long as the call attempt may be retried 404 without the mechanism if the first attempt fails. Abandoning 405 privacy in cases of failure of the privacy mechanism might be 406 subject to user preference, although such a feature would be within 407 the domain of a UA implementation and thus not subject to 408 standardization. It should be noted that some jurisdictions have 409 laws that explicitly deny any expectation of location privacy when 410 making an emergency call, while others grant the user the ability to 411 remain anonymous even when calling an ERC. So far, this has been 412 offered in some jurisdictions, but the user within that jurisdiction 413 must state this preference, as it is not the default configuration. 415 E-2 � Privacy mechanisms MUST NOT be mandatory for successful 416 conveyance of location during an (sos-type) emergency call. 418 E-3 - It MUST be possible to provide a privacy mechanism (that does 419 not violate the other requirements within this document) to a 420 user within a jurisdiction that gives that user the right to 421 choose not to reveal their location even when contacting an 422 ERC. 424 E-4 � The retention and retransmission policy of the ERC MUST be 425 able to be made available to the user, and override the 426 user's normal policy when local regulation governs such 427 retention and retransmission (but does not violate 428 requirement E-3). As in E-2 above, requiring the use of the 429 ERC's retention and/or retransmission policy may be subject 430 to user preference; although in most jurisdictions, local 431 laws specify such policies and may not be overridden by user 432 preference. 434 Location information is considered so important during emergency 435 calls, that it is to be transmitted even when it is not considered 436 reliable, or might even be wrong. For example, some application 437 might know that the DHCP reply with location information was 438 overwritten recently (or exactly) when a VPN connection was 439 activated. This could, and likely will, provide any new location 440 information to the UA from somewhere far away from the UA (perhaps 441 the user's corporate facility). 443 E-5 Location information MUST be transmitted, if known to the UAC, 444 in all calls to an ERC, even in the case it is not considered 445 reliable. 447 With that in mind, it is important to distinguish the location 448 information learned locally from LI learned over a VPN; which in 449 itself is useful additional information to that ERC operator. 451 E-7 THE UA must provide the actual LI of the endpoint, and not 452 location which might have been erroneously given to it by, e.g. 453 a VPN tunnel DHCP server. 455 E-8 An ERC MAY wish to SUBSCRIBE to the UAC that initiated a 456 session. If this is supported by the UAC, all NOTIFY messages 457 MUST contain the UAC's location information. 459 This is a means for the emergency response centers to maintain a 460 location the callers in distress. 462 E-9 It MUST be possible that any UAC supporting E-8 be informed of 463 this subscription, as this will provide a means of alert to the 464 user who does not wish this capability to remain enabled. 466 7. Location Conveyance using SIP 468 Geopriv is the IETF working group assigned to define a Location 469 Object for carrying within another protocol to convey geographic 470 location of an endpoint to another entity. This Location Object 471 will be supplied within SIP to convey location of a UA (or user of a 472 UA). The Location Object (LO) is defined in [13]. Section 26 of [1] 473 defines the security functionality SIPS for transporting SIP 474 messages with either TLS or IPsec, and S/MIME for encrypting message 475 bodies from SIP intermediaries that would otherwise have access to 476 reading the clear-text bodies. For UA-to-UA location conveyance, 477 using the PIDF-LO body satisfies the entire format and message- 478 handling requirements as stated in the baseline Geopriv requirements 479 [7]. SIP entities that will carry an LO MUST implement S/MIME for 480 encrypting on an end-to-end basis the location of a user agent, 481 satisfying [7]'s security requirements. The SIPS-URI from [1] 482 SHOULD also be used for further message protection (message 483 integrity, authentication and message confidentiality) and MUST be 484 used when S/MIME is not used. The entities sending and receiving 485 the LO MUST obey the privacy and security instructions in the 486 LO to be compliant with this specification. 488 Self-signed certificates SHOULD NOT be used for protecting LI, as 489 the sender does not have a secure identity of the recipient. 491 Several LOs MAY be included in a body. If the message length 492 exceeds the maximum message length of a single packet, session mode 493 is to be used. 495 Several SIP Methods are capable (and applicable) to carry the LO. 496 The Methods are divided into two groups, one for those applicable 497 for UA-to-UA location conveyance, and the other group for UA-to- 498 Proxy Location conveyance for routing the message. 500 The list of applicable Methods for UA-to-UA location conveyance is: 502 INVITE, 503 UPDATE, 504 MESSAGE, and 505 PUBLISH. 507 The list of applicable Methods for UA-to-Proxy location conveyance 508 is: 510 INVITE, 511 UPDATE, 512 MESSAGE, and 513 SUBSCRIBE/NOTIFY 515 While the authors do not yet see a reason to have location conveyed 516 in the OPTIONS, ACK, PRACK, BYE, REFER and CANCEL Methods, we do not 517 see a reason to prevent carrying a LO within these Method Requests 518 as long as the SIP message meets the requirements stated within this 519 document. 521 A 200 OK to an INVITE MAY carry the UAS's LO back to the UAC that 522 provided its location in the INVITE, but this is not something 523 that can be required due to the timing of the INVITE to 200 OK 524 messages, with potential local/user policy requiring the called user 525 to get involved in determining if the caller is someone they wish to 526 give location to (and at what precision). 528 There is an open question as to whether there needs to be a new 529 event package created for a SUBSCRIBE such that one SIP entity 530 (perhaps a service using SIP) can request the ability to have a 531 remote UA's location refreshed at some interval. This idea is not 532 explored further in this version of the document. The capability to 533 have location information refreshed between devices is out of scope 534 within the Geopriv working group at this time, but could easily 535 become part of the "using protocol's" capabilities without violating 536 any of the Geopriv Requirements in [7]. The authors want feedback 537 on incorporating this into this document, or a separate document. 539 For UA-to-Proxy location conveyance, there are two cases: one in 540 which all proxies on the path from the UA to the proxy that requires 541 location can be trusted with the LI, and one in which intermediate 542 proxies may not be trusted. The former may be implemented with 543 "hop-by-hop" security as specified in [1] using sips: (i.e. TLS 544 security). In particular, emergency call routing requires routing 545 proxies to know location, and sips: protection is appropriate. The 546 latter case is under study by the SIPPING working group under the 547 subject "End to Middle" security [12]. 549 Regardless which scenario (UA-to-UA or UA-to-Proxy) is used to 550 convey location, SIP entities MUST adhere to the rules of [7], 551 specifically the retention and distribution (privacy) attributes of 552 a UA's location. When Alice is deciding how to transmit her 553 location, she should be keenly aware of the parameters in which she 554 wants her location to be stored and distributed. However, once she 555 sends that location information to Bob, he MUST also now obey 556 Alice's wishes regarding these privacy attributes if he is deciding 557 to inform another party about Alice. This is a fundamental 558 principle of the Geopriv Working Group, i.e. "PRIVACY". 560 8. User Agent-to-User Agent Location Conveyance 562 The offered solution here for the User-to-User solution for location 563 conveyance between UAs is used with the INVITE, UPDATE, MESSAGE, and 564 PUBLISH Methods in the following subsections. 566 8.1 UA-to-UA using INVITE Method 568 Below is a common SIP session set-up sequence between two user 569 agents. In this example, Alice will provide Bob with her geographic 570 location in the INVITE message. 572 UA Alice UA Bob 574 | INVITE [M1] | 575 |---------------------------------------->| 576 | | 577 | 200 OK [M2] | 578 |<----------------------------------------| 579 | | 580 | ACK [M3] | 581 |---------------------------------------->| 582 | | 583 | RTP | 584 |<=======================================>| 585 | | 587 Figure 1. UA-UA with Location in INVITE 589 User agent Alice invites user agent Bob to a session [M1 of Figure 590 1]. Within this INVITE is a multipart body indication that it is 591 S/MIME encrypted [according to the rules of 1] by Alice for Bob. 592 One body part contains the SDP offered by Alice to Bob. Alice's 593 location (here coordinate based) is the other body part contained in 594 this INVITE. Bob responses with a 200 OK [M2] (choosing a codec as 595 specified by the Offer/Answer Model [14]). Bob can include his 596 location in the 200 OK response, but this shouldn't be expected due 597 to user timing. If Bob wants to provide his location to Alice after 598 the 200 OK, but before a BYE, the UPDATE Method [9] should be used. 599 Alice's UA replies with an ACK and the session is set up. 601 Figure 1. does not include any Proxies because in it assumed they 602 would not affect the session set-up with respect to whether or not 603 Alice's location is in a message body part, and Proxies don't react 604 to S/MIME bodies, making their inclusion more or less moot and more 605 complex than necessary. 607 The most relevant message in Figure 1 having to do with location is 608 (obviously) the message with the location object in it [M1]. So to 609 cut down on length of this document, only the INVITE message in this 610 example will be shown. Section 8.1.1 will give an example of this 611 well formed INVITE message using a Coordinate location format. 612 Section 8.1.2 will give an example of this well formed INVITE 613 message using the civic location format. 615 8.1.1 UA-to-UA INVITE with Coordinate Location Using S/MIME 617 Below is a well-formed SIP INVITE Method message to the example in 618 Figure 1 in section 8.1. 620 [Message 1 in Figure 1] 622 INVITE sips:bob@biloxi.example.com SIP/2.0 623 Via: SIP/2.0/TLS pc33.atlanta.example.com 624 ;branch=z9hG4bK776asdhds 625 Max-Forwards: 70 626 To: Bob 627 From: Alice ;tag=1928301774 628 Call-ID: a84b4c76e66710@pc33.atlanta.example.com 629 CSeq: 314159 INVITE 630 Contact: 631 Content-Type: application/pkcs7-mime; 632 smime-type=enveloped-data; name=smime.p7m 633 Content-Disposition: attachment; 634 filename=smime.p7m handling=required 636 Content-Type: multipart/mixed; boundary=boundary1 638 --boundary1 640 Content-Type: application/sdp 641 v=0 642 o=alice 2890844526 2890844526 IN IP4 atlanta.example.com 643 c=IN IP4 10.1.3.33 644 t=0 0 645 m=audio 49172 RTP/AVP 0 4 8 646 a=rtpmap:0 PCMU/8000 648 --boundary1 650 Content-type: application/cpim-pidf+xml 651 652 657 658 2004-11-11T08:57:29Z 659 660 661 662 663 664 41.87891N 665 87.63649W 666 667 668 dhcp 669 670 671 no 672 2004-11-13T14:57:29Z 674 675 676 677 678 680 --boundary1-- 682 8.1.1.1 UA-to-UA INVITE with Coordinate Location Not Using S/MIME 684 Below is a well-formed SIP INVITE Method message to the example in 685 Figure 1 in section 8.1. This message is here to show that although 686 the requirements are mandatory to implement proper security, it is 687 not mandatory to use. This message below is show for those cases 688 where hop-by-hop security is deployed. 690 [Message 1 in Figure 1] 692 INVITE sip:bob@biloxi.example.com SIP/2.0 693 Via: SIP/2.0/TCP pc33.atlanta.example.com 694 ;branch=z9hG4bK74bf9 695 Max-Forwards: 70 696 From: Alice ;tag=9fxced76sl 697 To: Bob 698 Call-ID: 3848276298220188511@atlanta.example.com 699 CSeq: 31862 INVITE 700 Contact: 701 Content-Type: multipart/mixed; boundary=boundary1 702 Content-Length: ... 704 --boundary1 706 Content-Type: application/sdp 707 v=0 708 o=alice 2890844526 2890844526 IN IP4 atlanta.example.com 709 c=IN IP4 10.1.3.33 710 t=0 0 711 m=audio 49172 RTP/AVP 0 4 8 712 a=rtpmap:0 PCMU/8000 714 --broundary1 716 Content-Type: application/cpim-pidf+xml 717 718 723 724 2004-11-11T08:57:29Z 725 726 727 728 729 730 41.87891N 731 87.63649W 732 733 734 dhcp 735 736 737 no 738 2004-11-13T14:57:29Z 740 741 742 743 744 746 --boundary1-- 748 8.1.2 UA-to-UA INVITE with Civic Location Using S/MIME 750 Below is a well-formed SIP INVITE Method message to the example in 751 Figure 1 in section 8.1 using the civic location format. 753 [Message 1 in Figure 1] 755 INVITE sips:bob@biloxi.example.com SIP/2.0 756 Via: SIP/2.0/TLS pc33.atlanta.example.com 757 ;branch=z9hG4bK776asdhds 758 Max-Forwards: 70 759 To: Bob 760 From: Alice ;tag=1928301774 761 Call-ID: a84b4c76e66710@pc33.atlanta.example.com 762 CSeq: 314159 INVITE 763 Contact: 764 Content-Type: application/pkcs7-mime; 765 smime-type=enveloped-data; name=smime.p7m 766 Content-Disposition: attachment; 767 filename=smime.p7m handling=required 769 Content-Type: multipart/mixed; boundary=boundary1 771 --boundary1 773 Content-Type: application/sdp 774 v=0 775 o=alice 2890844526 2890844526 IN IP4 atlanta.example.com 776 c=IN IP4 10.1.3.33 777 t=0 0 778 m=audio 49172 RTP/AVP 0 4 8 779 a=rtpmap:0 PCMU/8000 781 --boundary1 783 Content-type: application/cpim-pidf+xml 784 785 790 791 2004-11-11T08:57:29Z 792 793 794 795 796 US 797 Illinois 798 Chicago 799 233 800 South 801 Wacker 802 Drive 803 60606 804 Sears Tower 805 1 806 807 dhcp 808 www.cisco.com 809 810 811 no 812 2004-11-13T14:57:29Z 815 816 817 818 819 821 --boundary1-- 823 8.1.2.1 UA-to-UA INVITE with Civic Location Not Using S/MIME 825 Below is a well-formed SIP INVITE Method message to the example in 826 Figure 1 in section 8.1. This message is here to show that although 827 the requirements are mandatory to implement proper security, it is 828 not mandatory to use. This message below is show for those cases 829 where the sending user does not wish to use security mechanisms in 830 transmitting their coordinate location. 832 [Message 1 in Figure 1] 834 INVITE sip:bob@biloxi.example.com SIP/2.0 835 Via: SIP/2.0/TCP pc33.atlanta.example.com 836 ;branch=z9hG4bK74bf9 837 Max-Forwards: 70 838 From: Alice ;tag=9fxced76sl 839 To: Bob 840 Call-ID: 3848276298220188511@atlanta.example.com 841 CSeq: 31862 INVITE 842 Contact: 843 Content-Type: multipart/mixed; boundary=boundary1 844 Content-Length: ... 846 --boundary1 848 Content-Type: application/sdp 849 v=0 850 o=alice 2890844526 2890844526 IN IP4 atlanta.example.com 851 c=IN IP4 10.1.3.33 852 t=0 0 853 m=audio 49172 RTP/AVP 0 4 8 854 a=rtpmap:0 PCMU/8000 856 --broundary1 858 Content-type: application/cpim-pidf+xml 859 860 866 867 2004-11-11T08:57:29Z 868 869 870 871 872 US 873 Illinois 874 Chicago 875 233 876 South 877 Wacker 878 Drive 879 60606 880 Sears Tower 881 1 882 883 dhcp 884 www.cisco.com 885 886 887 no 888 2004-11-13T14:57:29Z 890 891 892 893 894 896 --boundary1-- 898 8.1.3 UA-to-UA Location Conveyance Involving 3 Users 900 In the following example, Alice presents her location in the INVITE 901 to Bob, which Bob 200 OKs with his location as well. Bob then 902 directs Alice to contact Carol. The REFER Method [15] is used in 903 the message sequence, but it does not carry anyone's location within 904 the REFER message. This example is here to show a 3-way 905 communication of location, coupled with how a UA can include someone 906 else's location. This has security implications due to neither 907 primary party in the last location transfer being the owner of the 908 location information. Alice (in this case) MUST adhere to the 909 retention and distribution privacy requirements within Bob's 910 location object regarding his location information prior to 911 considering its inclusion in the INVITE to Carol. 913 UA Alice Bob Carol 915 | INVITE [M1] | | 916 |---------------------------->| | 917 | 200 OK [M2] | | 918 |<----------------------------| | 919 | ACK [M3] | | 920 |---------------------------->| | 921 | RTP | | 922 |<===========================>| | 923 | reINVITE (hold) [M4] | | 924 |<----------------------------| | 925 | 200 OK [M5] | | 926 |---------------------------->| | 927 | REFER (Refer-to:Carol) [M6] | | 928 |<----------------------------| | 929 | INVITE [M7] | 930 |------------------------------------------>| 931 | 200 OK [M8] | 932 |------------------------------------------>| 933 | RTP | 934 |<=========================================>| 935 | NOTIFY [M9] | | 936 |---------------------------->| | 937 | 200 OK [M10] | | 938 |<----------------------------| | 939 | BYE [M11] | | 940 |<----------------------------| | 941 | 200 OK [M12] | | 942 |---------------------------->| | 943 | | 945 Figure 1a. UA-to-UA with Location in REFER 947 8.1.3.1 UA-to-UA REFER with Civic Location Using S/MIME 949 In Figure 1a., we have an example message flow involving the REFER 950 Method. The REFER itself does not carry location objects. 952 We are not including all the messages for space reasons. M1 is a 953 well-formed SIP message that contains Alice's location. M2 is Bob's 954 200 OK in response to Alice's INVITE, and it contains Bob's 955 Location. 957 [M1 of Figure 1a] - Alice at Sears Tower 959 INVITE sips:bob@biloxi.example.com SIP/2.0 960 Via: SIP/2.0/TLS pc33.atlanta.example.com 961 ;branch=z9hG4bK776asdhds 962 Max-Forwards: 70 963 To: Bob 964 From: Alice ;tag=1928301774 965 Call-ID: a84b4c76e66710@pc33.atlanta.example.com 966 CSeq: 314159 INVITE 967 Contact: 968 Content-Type: application/pkcs7-mime; 969 smime-type=enveloped-data; name=smime.p7m 970 Content-Disposition: attachment; 971 filename=smime.p7m handling=required 973 Content-Type: multipart/mixed; boundary=boundary1 975 --boundary1 977 Content-Type: application/sdp 978 v=0 979 o=alice 2890844526 2890844526 IN IP4 atlanta.example.com 980 c=IN IP4 10.1.3.33 981 t=0 0 982 m=audio 49172 RTP/AVP 0 4 8 983 a=rtpmap:0 PCMU/8000 985 --boundary1 987 Content-type: application/cpim-pidf+xml 988 989 994 995 2004-11-11T08:57:29Z 996 997 998 999 1000 US 1001 Illinois 1002 Chicago 1003 233 1004 South 1005 Wacker 1006 Drive 1007 60606 1008 Sears Tower 1009 1 1010 1011 dhcp 1012 www.cisco.com 1013 1014 1015 no 1016 2004-11-13T14:57:29Z 1018 1019 1021 1022 1023 1025 --boundary1-- 1027 Bob replies to Alice's INVITE with a 200 OK and includes his 1028 location. 1030 [M2 of Figure 4] - Bob watching Cubs Game at Wrigley Field 1032 SIP/2.0 200 OK 1033 Via: SIP/2.0/TCP pc33.atlanta.example.com 1034 ;branch=z9hG4bKnashds8 ;received=10.1.3.33 1035 To: Bob ;tag=a6c85cf 1036 From: Alice ;tag=1928301774 1037 Call-ID: a84b4c76e66710 1038 CSeq: 314159 INVITE 1039 Contact: 1040 Content-Type: application/pkcs7-mime; 1041 smime-type=enveloped-data; name=smime.p7m 1042 Content-Disposition: attachment; 1043 filename=smime.p7m handling=required 1045 Content-Type: multipart/mixed; boundary=boundary1 1047 --boundary1 1049 Content-Type: application/sdp 1050 v=0 1051 o=bob 2890844530 2890844530 IN IP4 biloxi.example.com 1052 c=IN IP4 192.168.10.20 1053 t=0 0 1054 m=audio 3456 RTP/AVP 0 1055 a=rtpmap:0 PCMU/8000 1057 --boundary1 1059 Content-type: application/cpim-pidf+xml 1060 1061 1066 1067 2004-11-6T02:30:29Z 1068 1069 1070 1071 1072 US 1073 Illinois 1074 Chicago 1075 Addison 1076 1060 1077 W 1078 street 1079 Wrigley Field 1080 60613 1081 1082 dhcp 1083 www.cisco.com 1084 1085 1086 no 1087 2004-11-6T18:30:29Z 1089 1090 1091 1092 1093 1095 --boundary1-- 1097 Bob REFERs Alice to Carol, and in M7, Alice includes both locations 1098 in a single SIP message. This is possible because Bob set his 1099 retention value to "yes", thus allowing Alice to pass his location 1100 on to Carol. 1102 [M7 of Figure 1a] - Alice tells Carol where she and Bob are 1104 INVITE sips:carol@chicago.example.com SIP/2.0 1105 Via: SIP/2.0/TLS pc33.atlanta.example.com 1106 ;branch=z9hG4bK776asdhdt 1107 Max-Forwards: 70 1108 To: Carol 1109 From: Alice ;tag=1928301775 1110 Call-ID: a84b4c76e66711@pc33.atlanta.example.com 1111 CSeq: 314160 INVITE 1112 Contact: 1113 Content-Type: application/pkcs7-mime; 1114 smime-type=enveloped-data; name=smime.p7m 1115 Content-Disposition: attachment; 1116 filename=smime.p7m handling=required 1118 Content-Type: multipart/mixed; boundary=boundary1 1120 --boundary1 1122 Content-Type: application/sdp 1123 v=0 1124 o=alice 2890844531 2890844531 IN IP4 atlanta.example.com 1125 c=IN IP4 10.1.3.33 1126 t=0 0 1127 m=audio 49173 RTP/AVP 0 4 8 1128 a=rtpmap:0 PCMU/8000 1130 --boundary1 1132 Content-type: application/cpim-pidf+xml 1133 1134 1139 1140 2004-11-5T02:30:29Z 1141 1142 1143 1144 1145 US 1146 Illinois 1147 Chicago 1148 Addison 1149 1060 1150 W 1151 street 1152 Wrigley Field 1153 60613 1154 1155 dhcp 1156 802.11 1157 www.cisco.com 1158 1159 1160 yes 1162 2004-11-6T18:30:29Z 1164 1165 1166 1167 1168 1170 --boundary1 1172 Content-type: application/cpim-pidf+xml 1173 1174 1179 1180 2004-11-6T02:30:29Z 1181 1182 1183 1184 1185 US 1186 Illinois 1187 Chicago 1188 233 1189 South 1190 Wacker 1191 Drive 1192 60606 1193 Sears Tower 1194 1 1195 1196 dhcp 1197 802.11 1198 www.marconi.com 1199 1200 1201 no 1202 2004-11-6T18:30:29Z 1204 1205 1206 1207 1208 1210 --boundary1-- 1212 It is an open question of whether there should be a mechanism to 1213 request or require the transmission of an LO. The LO is contained 1214 in a body, so the available sip mechanisms do not apply. 1216 8.2 UA-to-UA Using MESSAGE Method 1218 Anytime a user transmits location information outside a dialog, the 1219 MESSAGE Method is to be used. The logic here is as follows: 1221 - UPDATE isn't appropriate because it is for the updating of 1222 session capabilities and parameters of a dialog (after the 1223 INVITE included location information). 1225 - reINVITE isn't appropriate because it is only used (or only 1226 supposed to be used) for changing the parameters of an existing 1227 dialog, and one might not exist in all cases of location 1228 conveyance. 1230 This leaves MESSAGE as the only viable Request Method for location 1231 conveyance outside of a dialog between two users (Alice and Bob in 1232 this case). The following is an example of this communication. 1234 UA Alice UA Bob 1236 | MESSAGE [M1] | 1237 |---------------------------------------->| 1238 | | 1239 | 200 OK [M2] | 1240 |<----------------------------------------| 1241 | | 1243 Figure 2. UA-UA with Location in MESSAGE 1245 Section 8.2.1 will give the well formed MESSAGE Method containing a 1246 well formed Geopriv Location Object using the Coordinate location 1247 format that fully complies with all security requirements - SIPS for 1248 hop-by-hop security, and S/MIME for message body confidentiality 1249 end-to-end, as well as adhering to the retention and distribution 1250 concerns from [7]. Section 8.2.2 will show the Civic Location 1251 format alternative to the same location, as conveyed from Alice to 1252 Bob. This section does not adhere to confidentiality or integrity 1253 concerns of [7], but does convey retention and distribution 1254 indicators from Alice. 1256 8.2.1 UA-to-UA MESSAGE with Coordinate Location Using S/MIME 1258 Below is M1 from Figure 2 in section 8.2. that is fully secure and 1259 in compliance with Geopriv requirements in [7] for security 1260 concerns. 1262 [Message 1 in Figure 2] 1264 MESSAGE sips:bob@biloxi.example.com SIP/2.0 1265 Via: SIP/2.0/TLS pc33.atlanta.example.com 1266 ;branch=z9hG4bK776asegma 1267 Max-Forwards: 70 1268 To: Bob 1269 From: Alice ;tag=1928301774 1270 Call-ID: a84b4c76e66710@pc33.atlanta.example.com 1271 CSeq: 22756 MESSAGE 1272 Content-Type: application/pkcs7-mime; 1273 smime-type=enveloped-data; name=smime.p7m 1274 Content-Disposition: attachment; 1275 filename=smime.p7m handling=required 1277 Content-Type: multipart/mixed; boundary=boundary1 1279 --boundary1 1281 Content-Type: text/plain 1282 Here's my location, Bob? 1284 --broundary1 1286 Content-Type: application/cpim-pidf+xml 1287 Content-Disposition: render 1288 Content-Description: my location 1289 1290 1295 1296 2004-11-11T08:57:29Z 1297 1298 1299 1300 1301 1302 41.87891N 1303 87.63649W 1304 1305 1306 dhcp 1307 1308 1309 no 1310 2004-11-13T14:57:29Z 1312 1313 1314 1315 1316 1318 --boundary1-- 1320 8.2.2 UA-to-UA MESSAGE with Civic Location Not Using S/MIME 1322 Below is a well-formed SIP MESSAGE Method message to the example in 1323 Figure 2 in section 8.2 when hop-by-hop security mechanisms are 1324 deployed. 1326 [Message 1 in Figure 2] 1328 MESSAGE sip:bob@biloxi.example.com SIP/2.0 1329 From: ;tag=34589882 1330 To: 1331 Call-ID: 9242892442211117@atlanta.example.com 1332 CSeq: 6187 MESSAGE 1333 Content-Type: application/cpim-pidf+xml 1334 Content-ID: <766534765937@atlanta.example.com> 1335 Content-Disposition: render 1336 Content-Description: my location 1338 1339 1344 1345 2004-11-11T08:57:29Z 1346 1347 1348 1349 1350 US 1351 Illinois 1352 Chicago 1353 233 1354 South 1355 Wacker 1356 Drive 1357 60606 1358 Sears Tower 1359 1 1360 1361 dhcp 1362 1363 1364 no 1365 2004-11-13T14:57:29Z 1367 1368 1369 1370 1371 1373 8.3 UA-to-UA Location Conveyance Using UPDATE 1375 UPDATE MUST NOT be used to send location information from UA-to-UA 1376 unless location has already been sent in an INVITE or corresponding 1377 200 OK that was the first message exchange in the same dialog set- 1378 up. The same security properties used in the INVITE MUST be used in 1379 the UPDATE message. 1381 The UPDATE Method is to be used any time location information is to 1382 be updated between UAs setting up a dialog or after the dialog has 1383 been established, no matter how long that dialog has been 1384 operational. reINVITE is out of scope here, and the MESSAGE Method 1385 is for non-dialog location conveyance between UAs only. 1387 One reason for this message being generated is if either UA that 1388 sent its location information to the other UA (say in the INVITE and 1389 corresponding 200 OK) is if either UA determines that is has moved 1390 while the dialog has remained operational. How this movement is 1391 determined is outside the scope of this document, but ultimately 1392 should be configurable by local administration or the user of the 1393 UA. By how much Alice has moved to trigger the "sense of movement" 1394 (i.e. the need to send new location) to Bob is also outside the 1395 scope of this specification, but ultimately should be configurable 1396 by local administration or the user of the UA. 1398 In Figure 3., we have an example message flow involving the UPDATE 1399 Method. We are not including all the messages for space reasons. M1 1400 is a well formed SIP message that contains Alice's location. During 1401 the session set-up, Alice's UA knows it has moved while knowing too 1402 the session has not been formally accepted by Bob. Alice's UA 1403 decides to update Bob with her new location with an UPDATE Method 1404 message. Messages M2, M3 and M4 have nothing to do with location 1405 conveyance, therefore will not be shown in detail. Only M1 and M5 1406 will be shown. 1408 NOTE: A similar use for UPDATE is within the UA-to-Proxy Location 1409 Conveyance section of this document. 1411 UA Alice UA Bob 1413 | INVITE [M1] | 1414 |---------------------------------------->| 1415 | | 1416 | 183 (session Progress) [M2] | 1417 |<----------------------------------------| 1418 | | 1419 | PRACK [M3] | 1420 |---------------------------------------->| 1421 | | 1422 | ACK (PRACK) [M4] | 1423 |<----------------------------------------| 1424 | | 1425 | UPDATE [M5] | 1426 |---------------------------------------->| 1427 | | 1428 | ACK (UPDATE) [M6] | 1429 |<----------------------------------------| 1430 | | 1431 | 200 OK (INVITE) [M7] | 1432 |<----------------------------------------| 1433 | | 1434 | RTP | 1435 |<=======================================>| 1436 | | 1438 Figure 3. UA-UA with Location in UPDATE 1440 The following section will include the M1 and M5 messages in detail, 1441 but only in the civic format. 1443 8.3.1 UA-to-UA UPDATE with Civic Location Not Using S/MIME 1445 Here is the initial INVITE from Alice to Bob. 1447 [M1 INVITE to Bob] 1449 INVITE sips:bob@biloxi.example.com SIP/2.0 1450 Via: SIP/2.0/TLS pc33.atlanta.example.com 1451 ;branch=z9hG4bK776asdhds 1452 Max-Forwards: 70 1453 To: Bob 1454 From: Alice ;tag=1928301774 1455 Call-ID: a84b4c76e66710@pc33.atlanta.example.com 1456 CSeq: 314159 INVITE 1457 Contact: 1458 Content-Type: application/pkcs7-mime; 1459 smime-type=enveloped-data; name=smime.p7m 1460 Content-Disposition: attachment; 1461 filename=smime.p7m handling=required 1463 Content-Type: multipart/mixed; boundary=boundary1 1465 --boundary1 1467 Content-Type: application/sdp 1468 v=0 1469 o=alice 2890844526 2890844526 IN IP4 atlanta.example.com 1470 c=IN IP4 10.1.3.33 1471 t=0 0 1472 m=audio 49172 RTP/AVP 0 4 8 1473 a=rtpmap:0 PCMU/8000 1475 --boundary1 1476 Content-type: application/cpim-pidf+xml 1477 1478 1483 1484 2004-11-11T08:57:29Z 1485 1486 1487 1488 1489 US 1490 Illinois 1491 Chicago 1492 233 1493 South 1494 Wacker 1495 Drive 1496 60606 1497 Sears Tower 1498 1 1499 1500 dhcp 1501 802.11 1502 www.cisco.com 1503 1504 1505 no 1506 2004-11-13T14:57:29Z 1508 1509 1510 1511 1512 1514 --boundary1-- 1516 Alice moves locations (with her UA detecting the movement), causing 1517 her UA to generate an UPDATE message ([M5] of Figure 3) prior to 1518 her UA receiving a final response from Bob. Here is that message: 1520 M5 UPDATE to Bob 1522 UPDATE sips:bob@biloxi.example.com/TCP SIP/2.0 1523 Via: SIP/2.0/TLS pc33.atlanta.example.com 1524 ;branch=z9hG4bK776asdhds 1525 Max-Forwards: 70 1526 To: Bob 1527 From: Alice ;tag=1928 1528 Call-ID: a84b4c76e66710@pc33.atlanta.example.com 1529 CSeq: 10197 UPDATE 1530 Contact: 1531 Content-Type: application/pkcs7-mime; 1532 smime-type=enveloped-data; name=smime.p7m 1533 Content-Disposition: attachment; 1534 filename=smime.p7m handling=required 1536 Content-Type: multipart/mixed; boundary=boundary1 1538 --boundary1 1540 Content-Type: application/sdp 1541 v=0 1542 o=alice 2890844526 2890844526 IN IP4 atlanta.example.com 1543 c=IN IP4 10.1.3.33 1544 t=0 0 1545 m=audio 49172 RTP/AVP 0 4 8 1546 a=rtpmap:0 PCMU/8000 1548 --boundary1 1550 Content-type: application/cpim-pidf+xml 1551 1552 1557 1558 2004-11-11T08:57:29Z 1559 1560 1561 1562 1563 US 1564 Illinois 1565 Chicago 1566 250 1567 South Upper 1568 Wacker 1569 Drive 1570 60606 1571 Venice Cafe 1572 1 1573 1574 dhcp 1575 802.11 1576 www.t-mobile.com 1577 1578 1579 no 1580 2004-11-13T14:57:29Z 1582 1583 1584 1585 1586 1588 --boundary1-- 1590 8.4 UA-to-UA Location Conveyance Using PUBLISH 1592 ** This section could not be completed before submission time and 1593 will be completed shortly after IETF61. A thousand and one pardons. 1595 8.5 UA-to-UA Location Conveyance Using SUBSCRIBE and NOTIFY 1597 This section was not completed in time for the ID cut-off, thus all 1598 text was removed until it can be completed. The authors apologize. 1600 8.6 424 "Bad Location Information" Error Response 1602 In the case that a user agent server or SIP Proxy detects an error 1603 in a message containing location information specific to that 1604 message body, a new 4XX level error needs to be sent. This document 1605 creates the new error code: 1607 424 (Bad Location Information) 1609 This will provide the UAC with directed feedback about the status of 1610 location information it sent to that UAS or Proxy. The UAC MAY 1611 attempt to retry sending the message providing its location. 1613 This new error code will be IANA registered. 1615 An example flow of this scenario will be included in the next 1616 version of this internet draft. 1618 9. Special Considerations for Emergency Calls 1620 When a Proxy Server knows to look for a location message body to 1621 route an emergency call as in [11]. 1623 Emergency calls, which might be detected as detailed in [3], have 1624 special rules for conveyance of location: 1626 1. An emergency call MUST have all LI available to the UA, if any, 1627 sent with the INVITE, and subsequent UPDATE or reINVITE messages 1628 as a PIDF-LO in a body 1630 2. The LO must be protected with sips: unless the attempt to 1631 establish hop-by-hop TLS connection fails and cannot reasonably 1632 be established in a very short (less than a second) time. In 1633 such a case, the LO SHOULD be sent without TLS ONLY for those 1634 hops that failed to support TLS establishment. 1636 3. User Agents MUST NOT use S/MIME 1638 4. User Agents MUST include the element in the PIDF-LO 1639 (if known) to give the ERC an indication as to who is responsible 1640 for providing the UA with its location information. 1642 Proxies MUST NOT remove a location message body at any time. In the 1643 case where the Proxy knows the location of the UAC and does not 1644 detect the UAC's location information message body in the message 1645 (or determines the LO is bad), the Proxy generates a new 4XX (Retry 1646 Location Body) error message that includes a location information 1647 message body for that UAC to include in the subsequent message. The 1648 user agent MUST include this message body in the subsequent 1649 emergency message. 1651 In the element of the PIDF-LO, the Proxy MUST identify 1652 itself as the source of this location information. The user agent 1653 MUST NOT alter this field's value if received from a Proxy server. 1655 If the UAS of the ERC receives a SIP request with multiple location 1656 objects, it must determine which to use, since more than one may be 1657 present. This specification does not limit the number of LOs in a 1658 message, even in session mode. 1660 9.1 UA-to-Proxy Routing the Message with INVITE (secure) 1662 When Alice signifies "sos@" [per 3], her UA must understand this 1663 message MUST NOT use S/MIME for the message body, because this is an 1664 emergency call - otherwise the message will not properly route to 1665 the correct destination. Two definite possibilities will exist for 1666 how this message flow will occur [note: the message flows are not 1667 being defined here, they are defined in [11], but two are shown here 1668 to show the messages themselves]. The first possibility has Alice 1669 sending her INVITE to her first hop Proxy, which recognizes the 1670 message as an emergency message. The Proxy knows to look into the 1671 message bodies for the location body; determine where Alice is and 1672 route the call to the appropriate ERC. This is shown in Figure 4A. 1674 UA Alice Proxy ERC 1676 | INVITE [M1] | | 1677 |------------------>| | 1678 | | INVITE [M2] | 1679 | |-------------------->| 1680 | | 200 OK [M3] | 1681 | |<--------------------| 1682 | 200 OK [M4] | | 1683 |<------------------| | 1684 | ACK [M5] | 1685 |---------------------------------------->| 1686 | RTP | 1687 |<=======================================>| 1688 | | 1690 Figure 4A. UA-PROXY with Location in INVITE 1692 [M1 of Figure 4A] 1694 INVITE sips:sos@atlanta.example.com SIP/2.0 1695 Via: SIP/2.0/TLS pc33.atlanta.example.com 1696 ;branch=z9hG4bK74bf9 1697 Max-Forwards: 70 1698 From: Alice ;tag=9fxced76sl 1699 To: 1700 Call-ID: 3848276298220188511@atlanta.example.com 1701 CSeq: 31862 INVITE 1702 Contact: 1703 Content-Type: multipart/mixed; boundary=boundary1 1704 Content-Length: ... 1706 --boundary1 1708 Content-Type: application/sdp 1709 v=0 1710 o=alice 2890844526 2890844526 IN IP4 atlanta.example.com 1711 c=IN IP4 10.1.3.33 1712 t=0 0 1713 m=audio 49172 RTP/AVP 0 4 8 1714 a=rtpmap:0 PCMU/8000 1716 --boundary1 1718 Once the Proxy receives M1 and recognizes it as an emergency INVITE 1719 Request, this proxy knows to look into the message body for a 1720 location body part to determine the location of the UAC in order to 1721 match the location to an ERC. Once this look-up occurs, the message 1722 is sent directly to the ERC (in message [M2]). 1724 [M2 of Figure 4A] - Proxy has determined when to send message 1726 INVITE sips:sos@192.168.10.20 SIP/2.0 1727 Via: SIP/2.0/TLS pc33.atlanta.example.com 1728 ;branch=z9hG4bK74bf9 1729 Max-Forwards: 69 1730 From: Alice ;tag=9fxced76sl 1731 To: 1732 Call-ID: 3848276298220188511@atlanta.example.com 1733 CSeq: 31862 INVITE 1734 Contact: 1735 Content-Type: multipart/mixed; boundary=boundary1 1736 Content-Length: ... 1738 --boundary1 1740 Content-Type: application/sdp 1741 v=0 1742 o=alice 2890844526 2890844526 IN IP4 atlanta.example.com 1743 c=IN IP4 10.1.3.33 1744 t=0 0 1745 m=audio 49172 RTP/AVP 0 4 8 1746 a=rtpmap:0 PCMU/8000 1748 --boundary1 1750 Content-type: application/cpim-pidf+xml 1751 1752 1757 1758 2004-11-11T08:57:29Z 1759 1760 1761 1762 1763 US 1764 Illinois 1765 Chicago 1766 233 1767 South 1768 Wacker 1769 Drive 1770 60606 1771 Sears Tower 1772 1 1773 1774 dhcp 1775 802.11 1776 www.t-mobile.com 1777 1778 1779 no 1780 2004-11-13T14:57:29Z 1782 1783 1784 1785 1786 1788 --boundary1-- 1790 The second probability in message flows is in Figure 4B. in which 1791 the first hop Proxy does not either: understand location, or does 1792 not know where the appropriate ERC is to route the message to. In 1793 either case, that Proxy forwards the message to another Proxy for 1794 proper message routing ([11] talks to how this occurs). 1796 UA Alice Proxy Proxy ERC 1798 | INVITE [M1] | | | 1799 |------------>| | | 1800 | | INVITE [M2] | | 1801 | |------------>| | 1802 | | | INVITE [M3] | 1803 | | |------------>| 1804 | | | 200 OK [M4] | 1805 | | |<------------| 1806 | | 200 OK [M5] | | 1807 | |<------------| | 1808 | 200 OK [M6] | | | 1809 |<------------| | | 1810 | ACK [M7] | 1811 |---------------------------------------->| 1812 | RTP | 1813 |<=======================================>| 1814 | | 1816 Figure 4B. UA-PROXY with Location in INVITE 1818 In message flows similar to 4A and/or 4B, the Record-Route header 1819 could be added by the proxies, this is OPTIONAL in usage and left to 1820 other documents to refine. 1822 In the case of an identifiable emergency call, something that cannot 1823 happen is for any Proxy to Challenge [per 1] the INVITE message. In 1824 fact, while usage of the SIPS URI is encouraged and SHOULD be used, 1825 it MUST NOT be mandatory for successful message routing. If the 1826 first SIPS INVITE fails for security property reasons, the second 1827 attempt by Alice (in these examples) MUST be allowed to be in the 1828 clear, not challenged, and routed properly. Security mechanisms 1829 MUST NOT fail any call attempt, and if they do once, they MUST NOT 1830 be mandatory for the subsequent attempt for a successful session 1831 set-up to an ERC. The results of this are that the Proxy that 1832 failed the first attempt for security reasons MUST be aware of this 1833 failed attempt for the subsequent attempt that MUST process without 1834 failure a second time. It must be assumed that the INVITE in any 1835 instance is considered "well formed". 1837 The remaining messages in both 4A and 4B are not included at this 1838 time. If the working groups wants these added, they will be in the 1839 next revision of this document. 1841 9.1.1 UA-to-Proxy Routing the Message with INVITE (unsecure) 1843 Below can be considered the initial unsecure INVITE M1 from Figures 1844 4A and 4A, or the second attempt message to an initial message that 1845 was failed by a Proxy. This version of M1 is not using any security 1846 measures and is using the civic format message body that is the 1847 identical location to the previous example. 1849 [Message M1 from Figure 4A] 1851 INVITE sip:sos@atlanta.example.com SIP/2.0 1852 Via: SIP/2.0/TCP pc33.atlanta.example.com 1853 ;branch=z9hG4bK74bf9 1854 Max-Forwards: 70 1855 From: Alice ;tag=9fxced76sl 1856 To: 1857 Call-ID: 3848276298220188511@atlanta.example.com 1858 CSeq: 31862 INVITE 1859 Contact: 1860 Content-Type: multipart/mixed; boundary=boundary1 1861 Contact-Length: ... 1863 --boundary1 1865 Content-Type: application/sdp 1866 v=0 1867 o=alice 2890844526 2890844526 IN IP4 atlanta.example.com 1868 c=IN IP4 10.1.3.33 1869 t=0 0 1870 m=audio 49172 RTP/AVP 0 4 8 1871 a=rtpmap:0 PCMU/8000 1873 --boundary1 1875 Content-type: application/cpim-pidf+xml 1876 1877 1882 1883 2004-11-11T08:57:29Z 1884 1885 1886 1887 1888 US 1889 Illinois 1890 Chicago 1891 233 1892 South 1893 Wacker 1894 Drive 1895 60606 1896 Sears Tower 1897 1 1898 1899 dhcp 1900 802.11 1901 www.t-mobile.com 1902 1903 1904 no 1905 2004-11-13T14:57:29Z 1907 1908 1909 1910 1911 1913 --boundary1-- 1915 9.2 UA-to-Proxy Routing with UPDATE 1917 If the previous example of the location contained in the INVITE were 1918 to account for the movement of Alice (and her UA) before the ERC 1919 responded with a 200 OK, the UPDATE method is the appropriate SIP 1920 Request Method to use to update the proxies and ERC personnel that 1921 Alice has moved locations from where she initially made her set-up 1922 request. 1924 In this scenario (shown in the call flow of Figure 5A), Alice 1925 sending the UPDATE message here may cause the Proxy to CANCEL an 1926 existing pending INVITE Request, and retransmit INVITE to a NEW 1927 ERC(2), for example, if she walked across a street into a new ERC 1928 coverage area. The Proxy MUST remain transaction stateful in order 1929 to be aware of the 200 OK Response from ERC1. Upon receiving the 1930 UPDATE from Alice and analyzing the location provided by the message 1931 looking for a location change, either forwarding that message to 1932 ERC1 if the change is still within ERC1's coverage area, or deciding 1933 to forward a message to another ERC covering where Alice is now 1934 (ERC2 in this case) with her new location. If the latter change in 1935 destinations is required, the Proxy MUST CANCEL the pending INVITE 1936 to ERC1 (with a 487 "terminated request" being the specified 1937 response). 1939 SIPS SHOULD be used by Alice initially. Upon any failure of the 1940 initial Request, Alice's UA MUST decide to send the new message 1941 without SIPS. 1943 UA Alice Proxy ERC1 ERC2 1945 | INVITE [M1] | | | 1946 |---------------->| | | 1947 | | INVITE [M2] | | 1948 | |------------>| | 1949 | 183 SP [M3] | | | 1950 |<----------------| | | 1951 | PRACK [M4] | | | 1952 |---------------->| | | 1953 | 200 OK (PR)[M5] | | | 1954 |<----------------| | | 1955 | UPDATE [M6] | | | 1956 |---------------->| | | 1957 | 200 OK (UP)[M7] | | | 1958 |<----------------| | | 1959 | | CANCEL [M8] | | 1960 | |------------>| | 1961 | | 487 [M9] | | 1962 | |<------------| | 1963 | | INVITE [M10] | 1964 | |-------------------------->| 1965 | | 200 OK (INV) [M11] | 1966 | |<--------------------------| 1967 |200 OK (INV)[M12]| | 1968 |<----------------| | 1969 | ACK [M13] | 1970 |-------------------------------------------->| 1971 | RTP | 1972 |<===========================================>| 1973 | | 1975 Figure 5A. UA-PROXY with Location in UPDATE 1977 ** see new open issue #9 for the problems with messages 8 through 10 1978 ** of the above flow. 1980 9.2.1 UA-to-Proxy Routing the Message with UPDATE (secure) 1982 INVITE sip:sos@atlanta.example.com SIP/2.0 1983 Via: SIP/2.0/TCP pc33.atlanta.example.com 1984 ;branch=z9hG4bK74bf9 1985 Max-Forwards: 70 1986 From: Alice ;tag=9fxced76sl 1987 To: 1988 Call-ID: 3848276298220188511@atlanta.example.com 1989 CSeq: 31862 INVITE 1990 Contact: 1991 Content-Type: multipart/mixed; boundary=boundary1 1992 Contact-Length: ... 1994 --boundary1 1996 Content-Type: application/sdp 1997 v=0 1998 o=alice 2890844526 2890844526 IN IP4 atlanta.example.com 1999 c=IN IP4 10.1.3.33 2000 t=0 0 2001 m=audio 49172 RTP/AVP 0 4 8 2002 a=rtpmap:0 PCMU/8000 2004 --boundary1 2006 Content-type: application/cpim-pidf+xml 2007 2008 2013 2014 2004-11-11T08:57:29Z 2015 2016 2017 2018 2019 US 2020 Illinois 2021 Chicago 2022 233 2023 South 2024 Wacker 2025 Drive 2026 60606 2027 Sears Tower 2028 1 2029 2030 dhcp 2031 802.11 2033 www.cisco.com 2034 2035 2036 no 2037 2004-11-13T14:57:29Z 2039 2040 2041 2042 2043 2045 --boundary1-- 2047 Alice moves locations (with her UA detecting the movement), causing 2048 her UA to generate an UPDATE message ([M5] of Figure 3) prior to her 2049 UA receiving a final response from the ERC. In this case, Alice has 2050 walked across the South Wacker Drive to another building. Here is 2051 that message: 2053 [M5 UPDATE to ERC] 2055 UPDATE sips:bob@biloxi.example.com/TCP SIP/2.0 2056 Via: SIP/2.0/TLS pc33.atlanta.example.com 2057 ;branch=z9hG4bK776asdhds 2058 Max-Forwards: 70 2059 From: Alice ;tag=9fxced76sl 2060 To: 2061 Call-ID: 3848276298220188511@atlanta.example.com 2062 CSeq: 10187 UPDATE 2063 Contact: 2064 Content-Type: multipart/mixed; boundary=boundary1 2065 Contact-Length: ... 2067 --boundary1 2069 Content-Type: application/sdp 2070 v=0 2071 o=alice 2890844526 2890844526 IN IP4 atlanta.example.com 2072 c=IN IP4 10.1.3.33 2073 t=0 0 2074 m=audio 49172 RTP/AVP 0 4 8 2075 a=rtpmap:0 PCMU/8000 2077 --boundary1 2079 Content-type: application/cpim-pidf+xml 2080 2081 2087 2088 2004-11-11T08:57:29Z 2089 2090 2091 2092 2093 US 2094 Illinois 2095 Chicago 2096 250 2097 South Upper 2098 Wacker 2099 Drive 2100 60606 2101 Venice Cafe 2102 1 2103 2104 dhcp 2105 802.11 2106 www.t-mobile.com 2107 2108 2109 no 2110 2004-11-13T14:57:29Z 2112 2113 2114 2115 2116 2118 --boundary1-- 2120 9.2.2 UA-to-Proxy Routing the Message with UPDATE (unsecure) 2122 left blank for now 2124 9.3 425 "Retry Location Body" Error Response 2126 In the case that a SIP Proxy detects an error in a message 2127 containing location information specific to that message body and 2128 has the location of that UAC locally, a new 400 level error needs to 2129 be sent back to the UAC to instruct the UAC to include the included 2130 location information message body in a subsequent message. This 2131 document creates the new error code: 2133 425 (Retry Location Body) 2135 The UAC MUST ]retransmission of the failed message including this 2136 new location information. User agents may conclude they have 2137 already supplied a proper LO in the failed request. That LO can be 2138 resent, but the Proxy supplied LO MUST be included as well. 2140 This new error code will be IANA registered. 2142 An example flow of this scenario will be included in the next 2143 version of this internet draft. 2145 10. Meeting RFC3693 Requirements 2147 Section 7.2 of [7] details the requirements of a "using protocol". 2148 They are: 2150 Req. 4. The using protocol has to obey the privacy and security 2151 instructions coded in the Location Object and in the 2152 corresponding Rules regarding the transmission and storage of the 2153 LO. 2155 This document requires, in Section 7, that SIP entities sending or 2156 receiving location MUST obey such instructions. 2158 Req. 5. The using protocol will typically facilitate that the keys 2159 associated with the credentials are transported to the respective 2160 parties, that is, key establishment is the responsibility of the 2161 using protocol. 2163 [1] and the documents it references define the key establish 2164 mechanisms. 2166 Req. 6. (Single Message Transfer) In particular, for tracking of 2167 small target devices, the design should allow a single 2168 message/packet transmission of location as a complete 2169 transaction. 2171 This document specifies that the LO be contained in the body of a 2172 single message. 2174 11. Current Known Open issues 2176 This is a list of open issues that have not yet been addressed to 2177 conclusion: 2179 1) Should a Proxy somehow label its location information in the 4XX 2180 (Retry Location Body) message? 2182 2) Still have not determined how a SIP entity can request location 2183 to be delivered in a certain format (civil vs. coordinate). 2185 3) Still have not determined how a UAC can request the UAS return 2186 its location in a 1XX or 2XX response 2188 4) Still have not determined if a Redirect model should be accounted 2189 for (if the 3XX response includes LI, does that get included in 2190 the new Request by the UAC?) 2192 5) This document needs to be renamed within SIPPING to remove the 2193 "requirements" portion 2195 6) From section 9.2 (Emergency call with an updated location), if 2196 Alice does venture into another coverage area, how does her new 2197 UPDATE with new location get sent to a second (and now 2198 appropriate) ERC(2)? 2200 The pending INVITE needs to be cancelled or able to be 2201 sequentially forked (which not all Proxies will be able to do). 2202 Without that occurring, the new UPDATE will not cause a new 2203 INVITE to be originated from the Proxy towards ERC2... and what 2204 happens to the UPDATE message (which cannot be an original 2205 request into ERC2)? 2207 12. New Open Issues 2209 These are new open issues to be addressed within this document or 2210 the topics/areas dropped from consideration: 2212 1) May add a section for end-to-middle in a services model 2214 2) Is there a need to create a new events package for a subscription 2215 to a UA to get it's location either at periodic time intervals or 2216 when the UA has determined it has moved? 2218 13. Security Considerations 2220 Conveyance of geo-location of a UAC is problematic for many reasons. 2221 This document calls for that conveyance to normally be accomplished 2222 through secure message body means (like S/MIME or TLS). In cases 2223 where a session set-up is routed based on the location of the UAC 2224 initiating the session or SIP MESSAGE, securing the location with an 2225 end-to-end mechanism such as S/MIME is problematic. 2227 14. IANA Considerations 2229 This section defines two new 4XX error response codes within the 2230 sip-parameters section of IANA. [NOTE: RFC XXXX denotes this 2231 document. 2233 14.1 IANA Registration for Response Code 4XX 2235 RFC number: XXXX 2236 Response code: 424 2237 Default reason phrase: Bad Location Information 2239 14.2 IANA Registration for Response Code 4XX 2241 RFC number: XXXX 2242 Response code: 425 2243 Default reason phrase: Retry Location Body 2245 15. Acknowledgements 2247 To Dave Oran for helping to shape this idea. To Jon Peterson and 2248 Dean Willis on guidance of the effort. To Henning Schulzrinne, 2249 Jonathan Rosenberg, Dick Knight, and Keith Drage for constructive 2250 feedback. 2252 16. References 2254 16.1 References - Normative 2256 [1] J. Rosenberg, H. Schulzrinne, G. Camarillo, A. Johnston, J. 2257 Peterson, R. Sparks, M. Handley, E. Schooler, "SIP: Session 2258 Initiation Protocol ", RFC 3261, June 2002 2260 [2] S. Bradner, "Key words for use in RFCs to indicate requirement 2261 levels," RFC 2119, Mar. 1997. 2263 [3] H. Schulzrinne, "draft-ietf-sipping-sos-00.txt", Internet 2264 Draft, Feb 2004, Work in progress 2266 [4] B. Campbell, Ed., J. Rosenberg, H. Schulzrinne, C. Huitema, D. 2267 Gurle, "Session Initiation Protocol (SIP) Extension for Instant 2268 Messaging" , RFC 3428, December 2002 2270 [5] J. Polk, J. Schnizlein, M. Linsner, " DHCP Option for Location 2271 Configuration Information", RFC 3825, July 2004 2273 [6] H. Schulzrinne, "draft-ietf-geopriv-dhcp-civic-03.txt", Internet 2274 Draft, July 04, Work in progress 2276 [7] J. Cuellar, J. Morris, D. Mulligan, J. Peterson. J. Polk, "Geopriv 2277 Requirements", RFC 3693, February 2004 2279 [8] J. Rosenberg, "Requirements for Session Policy for the Session 2280 Initiation Protocol�, draft-ietf-sipping-session-policy-req-00", 2281 Internet Draft, June, 2003, "work in progress" 2283 [9] J. Rosenberg, "The Session Initiation Protocol (SIP) UPDATE 2284 Method", RFC 3311, October 2002 2286 [10] A. Niemi, Ed., "draft-ietf-sip-publish-04", Internet Draft, May 2287 2004, work in progress 2289 [11] H. Schulzrinne, B. Rosen, "draft-schulzrinne-sipping-emergency- 2290 arch", Internet Draft, Feb 2004, work in progress 2292 [12] "Requirements for End to Middle Security in SIP", 2293 draft-ietf-sipping-e2m-sec-reqs-03.txt, Internet Draft, June 2294 2004, work in progress, 2296 [13] J. Peterson, "draft-ietf-geopriv-pidf-lo-02", Internet Draft, May 2297 2004, work in progress 2299 [14] J. Rosenberg, H. Schulzrinne, "The Offer/Answer Model with 2300 Session Description Protocol", RFC 3264, June 2002 2302 [15] R. Sparks, "The Session Initiation Protocol (SIP) Refer Method", 2303 RFC 3515, April 2003 2305 17. Author Information 2307 James M. Polk 2308 Cisco Systems 2309 2200 East President George Bush Turnpike 33.00111N 2310 Richardson, Texas 75082 USA 96.68142W 2311 jmpolk@cisco.com 2313 Brian Rosen 40.4N 2314 br@brianrosen.net 80.0W 2316 Full Copyright Statement 2318 Copyright (C) The Internet Society (2004). This document is subject 2319 to the rights, licenses and restrictions contained in BCP 78, and 2320 except as set forth therein, the authors retain all their rights. 2322 This document and the information contained herein are provided on 2323 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 2324 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE 2325 INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR 2326 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 2327 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 2328 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 2330 Intellectual Property 2332 The IETF takes no position regarding the validity or scope of any 2333 Intellectual Property Rights or other rights that might be claimed 2334 to pertain to the implementation or use of the technology described 2335 in this document or the extent to which any license under such 2336 rights might or might not be available; nor does it represent that 2337 it has made any independent effort to identify any such rights. 2338 Information on the procedures with respect to rights in RFC 2339 documents can be found in BCP 78 and BCP 79. 2341 Copies of IPR disclosures made to the IETF Secretariat and any 2342 assurances of licenses to be made available, or the result of an 2343 attempt made to obtain a general license or permission for the use 2344 of such proprietary rights by implementers or users of this 2345 specification can be obtained from the IETF on-line IPR repository 2346 at http://www.ietf.org/ipr. 2348 The IETF invites any interested party to bring to its attention any 2349 copyrights, patents or patent applications, or other proprietary 2350 rights that may cover technology that may be required to implement 2351 this standard. Please address the information to the IETF at ietf- 2352 ipr@ietf.org. 2354 Acknowledgement 2356 Funding for the RFC Editor function is currently provided by the 2357 Internet Society. 2359 The Expiration date for this Internet Draft is: 2361 April 25th, 2005