idnits 2.17.1 draft-ietf-sip-location-conveyance-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 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1658. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1635. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1642. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1648. ** 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 is 1 instance 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 33 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 26 has weird spacing: '...ference mater...' == Line 118 has weird spacing: '...nearest pizza...' == Line 713 has weird spacing: '... Rr ar ...' == Line 716 has weird spacing: '... Rr ar ...' == 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 'not RECOMMENDED' in this paragraph: While many jurisdictions force a user to reveal their location during an emergency call set-up, there is a small, but real, number of jurisdictions that allow a user to configure their calling device to disable providing location, even during emergency calling. This capability MUST be configurable, but is not RECOMMENDED as the default configuration of any UA. Local policies will dictate this ability. -- 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 1415, but not defined == Missing Reference: 'M2' is mentioned on line 1373, but not defined == Missing Reference: 'M3' is mentioned on line 1300, but not defined == Missing Reference: 'M4' is mentioned on line 1306, but not defined == Missing Reference: 'M5' is mentioned on line 1308, but not defined ** Downref: Normative reference to an Informational RFC: RFC 3693 ** Obsolete normative reference: RFC 2393 (ref. 'RFC2392') (Obsoleted by RFC 3173) -- Obsolete informational reference (is this intentional?): RFC 3825 (Obsoleted by RFC 6225) Summary: 5 errors (**), 0 flaws (~~), 14 warnings (==), 8 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: Sept 6th, 2006 Brian Rosen 5 NeuStar 7 Session Initiation Protocol Location Conveyance 8 draft-ietf-sip-location-conveyance-02.txt 9 Mar 6th, 2006 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six 24 months and may be updated, replaced, or obsoleted by other documents 25 at any time. It is inappropriate to use Internet-Drafts as 26 reference material or to cite them other than as "work in 27 progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on September 6th, 2006. 37 Copyright Notice 39 Copyright (C) The Internet Society (2006). 41 Abstract 43 This document defines how the Session Initiation Protocol (SIP) 44 conveys, or pushes, user location information from one SIP entity 45 to another SIP entity. SIP Location Conveyance is always end to 46 end, but sometimes the embedded location information can be acted 47 upon by SIP Servers to direct where the message goes, based on where 48 the user agent client is. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 53 1.1 Conventions . . . . . . . . . . . . . . . . . . . . . . . 4 54 1.2 Changes from Prior Versions . . . . . . . . . . . . . . . 4 55 2. Location In the Body or in a Header . . . . . . . . . . . . . 8 56 3. Requirements for SIP Location Conveyance . . . . . . . . . . 9 57 4. Location Conveyance Using SIP . . . . . . . . . . . . . . . . 12 58 4.1 New Option Tags and a Location Header Created . . . . . . 13 59 4.2 424 (Bad Location Information) Response Code . . . . . . 16 60 4.3 Example PIDF-LO in Geo Format . . . . . . . . . . . . . . 16 61 4.3 Example PIDF-LO in Civic Format . . . . . . . . . . . . . 17 62 5. SIP Element Behavior When Conveying Location . . . . . . . . 18 63 5.1 Location Conveyance Using the INVITE Method . . . . . . . 19 64 5.2 Location Conveyance Using the MESSAGE Method . . . . . . 21 65 5.3 Location Conveyance Using the UPDATE Method . . . . . . . 22 66 5.4 Location Conveyance Using the REGISTER Method . . . . . . 27 67 6. Special Considerations for Emergency Calls . . . . . . . . . 29 68 7. Meeting RFC 3693 Requirements . . . . . . . . . . . . . . . . 29 69 8. Open issues . . . . . . . . . . . . . . . . . . . . . . . . . 30 70 9. Security Considerations . . . . . . . . . . . . . . . . . . . 30 71 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . 31 72 10.1 IANA Registration for the SIP Location Header . . . . . 31 73 10.2 IANA Registration of the Location Option Tags. . . . . . 31 74 10.3 IANA Registration for Response Code 424 . . . . . . . . 31 75 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 31 76 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 31 77 12.1 Normative References . . . . . . . . . . . . . . . . . 31 78 12.2 Informative References . . . . . . . . . . . . . . . . . 32 79 Author Information . . . . . . . . . . . . . . . . . . . . . 32 80 Intellectual Property and Copyright Statements . . . . . . . 33 82 1. Introduction 84 There are several situations in which it is desired or necessary for 85 a Session Initiation Protocol (SIP) [RFC3261] user agent to convey, 86 or push Location Information (LI) from one SIP entity to another. 87 This document discusses the scenarios for such conveyance, and 88 includes the requirements to be met when a SIP UAC wants or needs to 89 convey its location to another SIP entity. A concept of inheritance 90 exists in which the conveyance of the location of a user agent means 91 conveying the location of a user of that user agent. This is not an 92 absolute in SIP, but applies for the pushing of location using SIP. 93 The privacy concerns of this topic are also discussed, and need to 94 meet the requirements laid out in RFC 3693 [RFC3693]. This document 95 does not discuss the pulling of location information from a user 96 agent. This is left for a future effort. 98 Why would a SIP user agent (UA) push its location to another SIP UA? 100 There are 3 reasonable scenarios why location can be, or needs to be 101 conveyed to a remote SIP element: 103 1) to include location in a request message seeking the nearest 104 instance of destination, where there could be more than one 105 choice; (hey, here I am, I want to talk to the nearest instance 106 of you? i.e. where's the nearest Pizza Hut relative to where I 107 am). 109 2) to push the user's location to a server that can deal with all 110 the inquiries, leaving the UA to do other tasks; (Presence 111 Server) 113 3) to inform the user of another UA where the sending user is; 114 (dude, he is where I am) or (I need help, here I am) 116 Scenario #1 revolves around the idea of a user wanting to find the 117 nearest instances of something else. For example, where is the 118 nearest pizza parlor. A chain of pizza parlors may be contacted 119 through a single well known URI (sip:pizzaparlor.example.com). This 120 by itself does not solve enough to the sending UA. The server at 121 this well known URI needs to know where the nearest one is to the 122 requester. In SIP, this could be accomplished in the initial 123 message by including the location of the UAC in the Request message. 124 This allows the SIP message to be forwarded to the closest physical 125 site by the pizzaparlor.com proxy server. Additionally, the 126 receiving site's UAS uses the UAC's location to determine the 127 location your delivery. A more immediate example may be: where's 128 the nearest (car) garage repair shop, because the user of the UAC 129 has a flat tire. 131 Scenario #2 revolves around pushing the user's location information 132 to an external server to deal with all location requests in the 133 future. This leaves a buffer layer between the user and the seeker 134 of the user's location. This server would typically handle all 135 security checks and challenges of those seeking the user's location, 136 as well as handling all the processing of the location target's 137 profile rules entered into that server. This external server 138 c/would be a Presence server. This scenario will not be addressed 139 in this document because of the prevailing Presence solutions for 140 conveying location information. 142 Scenario #3 actually has a part A and a part B to it. Both involve 143 the UAC including its location in the request to the UAS within a 144 SIP transaction. Part A simply has the user, Alice, informing 145 another user, Bob, where she is. This could be for the loan purpose 146 for this SIP message, or it could be part of another transaction - 147 in which location were merely included, such as within a call set- 148 up. 150 Part B of this scenario has a user, Alice calling for help and 151 including location to inform who she's calling where she is. This 152 is where the called party needs to come bring help to. Within this 153 scenario, the UAC will need to know this is an emergency SIP request 154 message, and to include the UAC's location in this message. 156 While scenarios 1, 2 and 3A should use some form of SIP security, 157 typically at the wishes of the user, scenario 3B may or may not 158 involve SIP security measures. This is because including any 159 security measures may cause the SIP request to fail, and that is 160 likely not a good result. It is also conceivable that a first 161 attempt with the user's security measures enabled is tried, and if 162 there are any failures, the subsequent attempt or attempts do not 163 involve security measures. Most believe that completing the 164 emergency call is more important than protecting the information in 165 the SIP message. Obviously this is up to local and jurisdictional 166 policies, but is mentioned here as a hint of a rationale of a later 167 section of this document. 169 This document does not discuss how the UAC discovers or is 170 configured with its location, however will specify how this spec 171 meets the requirements for SIP qualifying as a "using protocol" as 172 defined in [RFC3693], in section 7. 174 Section 3 lists the requirements for SIP location conveyance. 175 Section 4 defines how SIP conveys location. Section 5 illustrates 176 specifics about location conveyance in certain SIP request messages. 177 Section 6 briefly discusses pertinent behaviors with respect to the 178 unique nature of emergency calling. Section 9 provides the security 179 considerations and Section 10 IANA registers one new SIP header, two 180 new option tags and one new 4XX Response codes. 182 1.1 Conventions used in this document 184 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 185 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and 186 "OPTIONAL" in this document are to be interpreted as described 187 in [RFC2119]. 189 1.2 Changes from Prior Versions 191 [NOTE TO RFC-EDITOR: If this document is to be published as an RFC, 192 this section 1.2 is to be removed prior to that event.] 194 This is a list of the changes that have been made from the SIP WG 195 version -01 to this version -02: 197 - streamlined the doc by removing text (ultimately removing 42 pages 198 of text). 200 - Limited the scope of this document to SIP conveyance, meaning only 201 how SIP can push location information. 203 - reduced emergency calling text to just a few paragraphs now that 204 the ECRIT WG is taking most of that topic on. 206 - greatly reduced the number of requirements in this version. 208 - changed the requirements groups from "UA-to-UA", "UA-to-Proxy", 209 etc to "UAC Reqs", "UAS-Reqs" and "Proxy-Reqs" to focus on what is 210 being asked of each SIP element. 212 - Removed the full SIP message examples. 214 - completed the ABNF for the Location header, including a cid-url to 215 point at a message body part to help in parsing for location. 217 - Deleted the call for a new 425 (Retry Location) response code, as 218 it appears this can easily be used to spoof a UA into providing 219 where it is inadvertently, even if the intent is legitimate by the 220 UAC. 222 This is a list of the changes that have been made from the SIP WG 223 version -00 to this version -01: 225 - cleaned up a lot of loose ends in the text 227 - created a new Location header to convey many means (location is in 228 the body - even if not viewable, which location format is present, 229 which format is requested in a query, how to request more than one 230 location format in a query, whether the UAC understands location 231 at all, if the UA knows its location, how to push location from 232 one UA to through a second to a third UA, etc). 234 - added the ability to convey location by-reference, but only under 235 certain conditions. 237 - Added support for the OPTIONS Request to query a server for the 238 UAC's location, through the use of the new Location header. 240 - moved both new Response code sections forward in the document for 241 their meaning to be clearer, earlier for necessary discussion. 243 - Changed the message flows to only have the pertinent message 244 headers shown for brevity. 246 - Added text to the SUB/NOT section showing how and why the location 247 of a UA can be refreshed or updated with an interval, or by a 248 trigger. 250 This is a list of the changes that have been made from the SIPPING 251 WG version -02 to this SIP WG item document version -00: 253 - Changed which WG this document is in from SIPPING to SIP due to 254 the extension of the protocol with new Response codes (424 and 255 425) for when there is an error involving the LO message body. 257 - Moved most of the well formed SIP messages out of the main body of 258 this document and into separate appendixes. This should clean up 259 the document from a readability point of view, yet still provide 260 the intended decode examples to readers of this document who wish 261 that level of detail per flow. The first few flows still have the 262 decoded SIP messages (unencrypted and encrypted). 264 - Removed some flow examples which no longer made sense 266 - Changed all references of "ERC" (Emergency Response Center) to 267 "PSAP" (Public Safety Answering Point) as a result of discussion 268 within the new ECRIT WG to define a single term 270 This is a list of the changes that have been made from the sipping- 271 01 working group version of this effort to the sipping-02 version: 273 - added requirements for 2 new 4XX error responses (Bad Location 274 Information) and (Retry Location Body) 276 - added "Bad Location Information" as section 8.6 278 - added "Retry Location Body " as section 9.3 280 - added support for session mode to cover packet sizes larger than 281 the single packet limit of 1300 bytes in the message body 283 - added requirement for a SIP entity to SUBSCRIBE to another for 284 location information 286 - added SUBSCRIBE and NOTIFY as section 8.5 288 - added requirement to have user turn off any tracking created by 289 subscription 291 - removed doubt about which method to use for updating location 292 after a INVITE is sent (update) 294 - cleaned up which method is to be used if there is no dialog 295 existing (message) 297 - removed use of reINVITE to convey location 299 - clarified that UAs include element of PIDF-LO when 300 placing an emergency call (to inform PSAP who supplied Location 301 information) 303 - updated list of open issues 305 - added to IANA Considerations section for the two new 4XX level 306 error responses requested in the last meeting 308 This is a list of the changes that have been made from the sipping- 309 00 working group version of this ID to the sipping-01 version: 311 - Added the offered solution in detail (with message flows, 312 appropriate SIP Methods for location conveyance, and 314 - Synchronized the requirements here with those from the Geopriv 315 Working Group's (attempting to eliminate overlap) 317 - Took on the task of making this effort the SIP "using protocol" 318 specification from Geopriv's POV 320 - Refined the Open Issues section to reflect the progress we've made 321 here, and to indicate what we have discovered needs addressing, 322 but has not been to date. 324 This is a list of the changes that have been made from the -01 325 individual submission version to the sipping-00 version of this ID: 327 - Brian Rosen was brought on as a co-author 329 - Requirements that a location header were negatively received in 330 the previous version of this document. AD and chair advice was to 331 move all location information into a message body (and stay away 332 from headers) 334 - Added a section of "emergency call" specific requirements 336 - Added an Open Issues section to mention what hasn't been resolved 337 yet in this effort 339 This is a list of the changes that have been made from the 340 individual submission version -00 to the -01 version 342 - Added the IPR Statement section 344 - Adjusted a few requirements based on suggestions from the 345 Minneapolis meeting 347 - Added requirements that the UAC is to include from where it 348 learned its location in any transmission of its LI 350 - Distinguished the facts (known to date) that certain jurisdictions 351 relieve persons of their right to privacy when they call an PSAP, 352 while other jurisdictions maintain a person's right to privacy, 353 while still others maintain a person's right to privacy - but only 354 if they ask that their service be set up that way. 356 - Made the decision that TLS is the security mechanism for location 357 conveyance in emergency communications (vs. S/MIME, which is still 358 the mechanism for UA-to-UA non-emergency location conveyance 359 cases). 361 - Added the Open Issue of whether a Proxy can insert location 362 information into an emergency SIP INVITE message, and some of the 363 open questions surrounding the implications of that action 365 - added a few names to the acknowledgements section 367 2. Location In the Body or in a Header 369 In determining where "location" is placed in a SIP message, 370 consideration is taken as to where the trust model is based on the 371 architecture involved. 373 If the user agent has the location stored within it, and this user 374 agent wants to inform another user agent where it is, it seems 375 reasonable to have this accomplished by placing the location 376 information (coordinate or civic) in an S/MIME registered and 377 encoded message body, and sending it as part of a SIP request or 378 response. No routing of the request based on the location 379 information is required in this case; therefore no SIP Proxies 380 between these two UAs need to view the location information 381 contained in the SIP messages. The UAC should know messages will be 382 routed based on location when creating a message. This is location 383 by-value. 385 SIP currently does not permit SIP intermediaries to modify 386 or delete a message body [RFC3261]. There is, however, no 387 restriction on intermediaries viewing message bodies. S/MIME 388 protected message bodies, implemented on bodies for end-to-end 389 communications only (i.e. between user agents), would render the 390 location object opaque to a proxy server from any viewing of the 391 message body. This problem is similar to that raised in Session 392 Policy [ID-Sess-Pol], where an intermediary may need information in 393 a body, such as IP address of media streams or codec choices to 394 route a call properly. Requirements in [ID-Sess-Pol] are applicable 395 to routing based on location, and are incorporated in these 396 requirements by reference. 398 The location format is defined in [RFC4119] as a "Presence 399 Information Data Format - Location Object", or PIDF-LO. The amount 400 of information that is necessary to appropriately transmit location 401 information in a format that is understandable is larger than a SIP 402 header could realistically include. However, there must be a means 403 for both a UAC to include a reference point to where location can be 404 retrieved from a remote server, and in some cases, a SIP server 405 wants or needs to add location to a SIP message as it is processed 406 by that server. This must be in a compact form in a SIP header. A 407 URI satisfies this description. This is location-by-reference. 409 Location-by-Reference allows a UA to place its location on a remote 410 node, to be retrieved by who has this URI. This allows the server 411 to use its processing power to handle all policy rule operations the 412 user wants performed per request, and all security challenges done 413 as well. 415 [RFC3693] prefers S/MIME for security of Location Information, and 416 indeed S/MIME is preferable in SIP [RFC3261] for protecting a 417 message body. Accordingly, these requirements specify location be 418 carried in a body when it is known to/stored in a user agent. 420 It is the use of S/MIME however, that limits message routing based 421 on the location of the UAC, scenario 3B from above. Therefore, it 422 seems appropriate to require that, where routing is dependent on 423 location, protection of the location information object be 424 accomplished by other mechanisms visible to SIP proxies: here TLS 425 ("sips:" from [RFC3261]). The UAC will need to know the difference 426 in the call's intent as to which security mechanism to engage for 427 location conveyance. 429 It is conceivable that an initial attempt to communicate with 430 location included may fail due to the security measures used. 431 Subsequent requests ought to use less security. For example, if an 432 initial request used S/MIME and failed. A subsequent request could 433 downgrade the security measures used to that of TLS. This is a 434 matter for local and jurisdictional policy, and is merely a hint at 435 implementation possibilities. 437 3. Requirements for SIP Location Conveyance 439 The following subsections address the requirements placed on the 440 user agent client, the user agent server, as well as SIP proxies 441 when conveying location. 443 3.1 Requirements for a UAC Conveying Location 445 The following are the requirements for location conveyance by a user 446 agent client. There is a motivational statement below each 447 requirements that is not obvious in intent. 449 UAC-1 The SIP INVITE Method [RFC3261] MUST support Location 450 Conveyance. 452 UAC-2 The SIP MESSAGE method [RFC3428] MUST support Location 453 Conveyance. 455 UAC-3 SIP Requests within a dialog SHOULD support Location 456 Conveyance. 458 UAC-4 Other SIP Requests MAY support Location Conveyance. 460 UAC-5 There MUST be one, mandatory to implement means of 461 transmitting location confidentially. 463 Motivation: interoperability 465 UAC-6 It MUST be possible for a UAC to update location conveyed 466 prior to dialog establishment. 468 Motivation: in case a UAC has moved prior to the establishment of a 469 dialog between UAs, the UAC must be able to send new location 470 information. 472 UAC-7 The privacy and security rules established within [RFC3693] 473 that would categorize SIP as a 'using protocol' MUST be met. 474 See Section 7 for analysis. 476 UAC-8 The PIDF-LO [RFC4119] is a mandatory to implement format for 477 location conveyance within SIP, whether included by-value or 478 by-reference. 480 Motivation: interoperability 482 UAC-9 A UAC MUST be capable of transmitting a SIP request without 483 protecting the PIDF-LO message body. It is RECOMMENDED this 484 not be the default configuration of any UA. This requirement 485 is orthogonal to the use of TLS or IPSec hop-by-hop between 486 SIP elements. 488 Motivation: If a SIP request is part of an emergency call, 489 therefore includes the UAC's location, the UAC may understand 490 through local policy or configuration that a proxy server 491 will need to learn the UAC's location to route the message 492 correctly. Using S/MIME on the PIDF-LO defeats this 493 capability in proxies. 495 UAC-10 A UAC MUST allow its user to be able to disable providing 496 location within any SIP request message. It is RECOMMENDED 497 this not be the default configuration of any UA. 499 Motivation: local laws may give this right to all users within a 500 jurisdiction, even when the request is initiating an 501 emergency call. 503 3.2 Requirements for a UAS Receiving Location 505 The following are the requirements for location conveyance by a user 506 agent server: 508 UAS-1 SIP Responses MUST support Location Conveyance. 510 UAS-2 There MUST be one, mandatory to implement means of 511 transmitting location confidentially. 513 Motivation: interoperability 515 UAS-3 The PIDF-LO [RFC4119] is a mandatory to implement format for 516 location conveyance within SIP, whether included by-value or 517 by-reference. 519 Motivation: interoperability 521 UAS-4 There MUST be a unique 4XX error response code informing 522 the UAC it did not provide applicable location information. 524 UAS-5 SIP UAs MUST be prepared to receive location without privacy 525 mechanisms enabled. It is RECOMMENDED this not be the 526 default configuration of any UA, however, this is possible 527 based on local laws. 529 Motivation: Because a SIP request can fail in transit for security 530 reasons, UACs are allowed to transmit, or retransmit requests 531 including location without any security mechanisms utilized, 532 even when this SIP transaction is an emergency call. UAs 533 must be prepared to receive the messages without confidential 534 location. 536 UAS-6 There MUST be a unique 4XX error response code informing the 537 UAC it did not provide applicable location information. 539 3.3 Requirements for SIP Proxies and Intermediaries 541 The following are the requirements for location conveyance by a SIP 542 proxies and intermediaries: 544 Proxy-1 Proxy servers MUST NOT modify or remove a location 545 message body part, and SHOULD NOT modify or remove a 546 location header or location header value. 548 Motivation: [RFC3261] forbids the removal of a message body part, 549 and the proxy may not have all the relevant information as 550 to why location was included in this message (meaning it 551 might need to be there), and should not remove this 552 critical piece of information. 554 Proxy-2 Proxy servers MUST be capable of adding a Location header 555 during processing of SIP requests. 557 Motivation: If the proxy determines a message needs to have the 558 location of the UAC in the message, and knows the UAC's 559 location by-reference, it must be able to add this header 560 and URI to the message during processing. This MUST NOT 561 violate requirement Proxy-3 below. 563 Proxy-3 If a Proxy server detects "location" already exists within 564 a SIP message, it MUST NOT add another location header or 565 location body to the message. 567 Motivation: This may lead to confusion, and should be left for the 568 UAC to do on purpose. 570 Proxy-4 There MUST be a unique 4XX error response code informing 571 the UAC it did not provide applicable location information. 573 4. Location Conveyance Using SIP 575 RFC 4119 defines the PIDF-LO location object to be inside a RFC 3693 576 defined "using protocol" message from one entity to another entity. 577 For SIP location conveyance, using the PIDF-LO body satisfies the 578 entire format and message-handling requirements as stated in the 579 baseline Geopriv Requirements [RFC3693]. 581 Although a PIDF-LO is to be used to indicate location of a UA, the 582 actual PIDF-LO does not need to be contained in the message itself, 583 it can be as a by-reference URI in a SIP header or message body 584 part, pointing to the PIDF-LO of that UA on a remote node. 586 Section 26 of [RFC3261] defines the security functionality SIPS for 587 transporting SIP messages with either TLS or IPSec, and S/MIME for 588 encrypting message bodies from SIP intermediaries that would 589 otherwise have access to reading the clear-text bodies. SIP 590 endpoints MUST implement S/MIME to encrypt the PIDF-LO message body 591 (part) end-to-end. The SIPS-URI from [RFC3261] SHOULD be used for 592 message protection (message integrity and confidentiality) and MUST 593 be used when S/MIME is not used (when not violating the requirements 594 for emergency messaging detailed in section 3 of this document). 595 The entities sending and receiving location MUST obey the privacy 596 and security rules in the PIDF-LO to be compliant with this 597 specification. 599 Self-signed certificates SHOULD NOT be used for protecting PIDF-LO, 600 as the sender does not have a secure identity of the recipient. 602 More than one location representation or format MAY be included in 603 the same message body part, but all MUST point at the same position 604 on the earth (altitude not withstanding), as this would confuse the 605 recipient by pointing at more than one position within the same 606 PIDF-LO. There MAY be a case in which part of one location format 607 and part of another exist in the same message body part. These all 608 still MUST point at the same position on the earth, yet are 609 incomplete within their own format. For example, there maybe be a 610 latitude and longitude in coordinate format and a civic altitude 611 value to complete a 3-dimenttional position of a thing (i.e. which 612 floor of a building the UA is on in a building at a particular 613 lat/long coordinate pair). 615 There MAY be several PIDF-LOs in separate message body parts in the 616 same message, and each MAY point at different positions on the earth 617 (altitude not withstanding). If the message length exceeds the 618 maximum message length of a single packet (1300 bytes), TCP MUST to 619 be used for proper message fragmentation and reassembly. 621 Several push-based SIP Request Methods are capable (and applicable) 622 of carrying location, including: 624 INVITE, 625 REGISTER, 626 UPDATE, and 627 MESSAGE, 629 While the authors do not yet see a reason to have location conveyed 630 in the ACK, PRACK, BYE, REFER and CANCEL Methods, we do not see a 631 reason to prevent carrying a PIDF-LO within these Method Requests as 632 long as the SIP message meets the requirements stated within this 633 document. Discussing Location in the PUBLISH Request Method will be 634 for another document. 636 SIP Methods such as SUBSCRIBE and NOTIFY are considered a pull-based 637 location retrieval mechanism, and are therefore not part of this 638 document. 640 A 200 OK to a SIP Request MAY carry the UAS's PIDF-LO back to the 641 UAC that provided its location in the original request, but this is 642 not something that can be required due to the timing of the request 643 to 200 OK messages, with potential local/user policy requiring the 644 called user to get involved in determining if the caller is someone 645 they wish to give their location to (and at what precision). 647 4.1 New Option Tags and a Location Header Created 649 This document creates and IANA registers two new option tags, 650 "location" or "unknown-location". User agent clients who support 651 this specification will indicate that support by including either of 652 these option-tags in a Supported header. 654 This document also creates and IANA registers a new Location header. 655 The Location header, if present, will have one of three header 656 values defined by this document: 658 o a Location-by-reference URI 660 o a Content ID indicating where location is within the message body 662 o a location based option tag 664 A location-by-reference URI is a pointer to a record on a remote 665 node containing the PIDF-LO of a UA. 667 If the PIDF-LO of a UA is contained in a SIP message, a Location 668 header will be present in the message with a content-ID (cid-url) 669 [RFC2392] indicating where in the message body location is for this 670 UA. This is to aid a node in not having to parse the whole message 671 body or body parts looking for this body type. 673 The Unknown-Location option tag in a Location header indicates a UA 674 understands the concept of location conveyance, but does not have 675 its location to provide. This can save error messages from being 676 generated looking for an answer the UA does not have to give. It 677 can also allow a processing entity the immediate knowledge it needs 678 to act as if the UA will not learn location on its own, and perhaps 679 call on another process to address the location needs for that 680 message. 682 The purpose of the Location option-tag is to indicate support for 683 this document in the Requires, Supported and Unsupported headers. 684 It gives a UAS the proper means to indicate it does not support the 685 concept of location in an Unsupported header in a response message 686 that might otherwise not be clear that the lack of support for 687 location is the problem with the request message. 689 The new "Location" header has the following BNF syntax: 691 Location = "Location" HCOLON Location-value *(COMMA 692 Location-value) 693 location-value = (addr-spec / option-tag / token) 694 addr-spec = cid-url / absoluteURI 695 option-tag = string 696 token = token / quoted-string 697 cid-url = "cid" ":" content-id / 698 absoluteURI = SIP or SIPS-URI 699 content-id = url-addr-spec 700 url-addr-spec = addr-spec ; URL encoding of RFC 822 addr-spec 702 The Content-ID (cid) is defined in [RFC2392] to locate message body 703 parts. 705 The absoluteURI is the SIP or SIPS URI of the location-by-reference, 706 which points at a PIDF-LO of a UA in a record on a remote node. 708 The following table extends the values in Table 2/3 of RFC3261 709 [RFC3261]. 711 Header field where proxy INV ACK CAN BYE REG OPT PRA 712 ---------------------------------------------------------------- 713 Location Rr ar o - - o o o - 714 Header field where proxy SUB NOT UPD MSG REF INF PUB 715 ---------------------------------------------------------------- 716 Location Rr ar - - o o o o - 718 The Location header MAY be added, or read if present in a Request 719 message listed above. A proxy MAY add the location header in 720 transit if one is not present. [RFC3261] states message bodies 721 cannot be added by proxies. A proxy MAY read the location header in 722 transit if present. 724 It is RECOMMENDED that only one Location header be in the same 725 message, but this is not mandatory. That said, there MUST NOT be 726 more than one cid-url pointing to a location message body (part) in 727 a SIP message, regardless of how many Location headers there are in 728 that message. There MUST NOT be more than one location by-reference 729 URI in any SIP message, regardless of how many Location headers 730 there are in a message. 732 Here is an example INVITE that includes the proper Location and 733 Supported headers (without the PIDF-LO message body part): 735 INVITE sip:bob@biloxi.example.com SIP/2.0 736 Via: SIP/2.0/TCP pc33.atlanta.example.com 737 ;branch=z9hG4bK74bf9 738 Max-Forwards: 70 739 To: Bob 740 From: Alice ;tag=9fxced76sl 741 Call-ID: 3848276298220188511@atlanta.example.com 742 Location: cid:alice123@atlanta.example.com 743 Supported: location 744 Accept: application/sdp, application/pidf+xml 745 CSeq: 31862 INVITE 746 Contact: 747 Content-Type: multipart/mixed; boundary=boundary1 748 Content-Length: ... 750 --boundary1 752 Content-Type: application/sdp 754 ...SDP here 756 --boundary1 758 Content-Type: application/pidf+xml 759 Content-ID: alice123@atlanta.example.com 761 ...PIDF-LO with geo-location coordinates here 763 --boundary1-- 764 The location header from the above INVITE: 766 Location: cid:alice123@atlanta.example.com 768 indicates the Content-ID location [RFC2392] within the multipart 769 message body of were location information is. 771 If the Location header were this instead: 773 Location: 775 this would indicate location by-reference was included in this 776 message. It is expected that any node wanting to know where user 777 alice123 is would fetch the PIDF-LO from the server5 URI. 779 4.2 424 (Bad Location Information) Response Code 781 In the case that a UAS or SIP intermediary detects an error 782 in a Request message specific to the location information supplied 783 by-value or by-reference, a new 4XX level error is created here to 784 indicate this is the problem with the request message. This 785 document creates the new error code: 787 424 (Bad Location Information) 789 The 424 (Bad Location Information) Response code is a rejection of 790 the location contents, whether by-value or by-reference of the 791 original SIP Request. The server function of the recipient (UAS or 792 intermediary) has deemed this location by-reference or location by- 793 value to be bad. No further action by the UAC is required. The UAC 794 can use whatever means it knows to verify/refresh its location 795 information before attempting a new request. There is no cross- 796 transaction awareness expected by either the UAS or SIP intermediary 797 as a result of this error message. 799 This new error code will be IANA registered in Section 10. 801 4.3 Example PIDF-LO in Geo Format 803 This subsection will show a sample of what just the PIDF-LO can look 804 like, as defined in [RFC4119]. Having this here will first offer a 805 look at a location by-value message body, and secondly, give readers 806 an appreciation for how large a location message body is so that 807 this document does not have to show a PIDF-LO in every message flow 808 example. This section shows a coordinate position based PIDF-LO. 809 Section 4.4 shows this same position in a civic address format. 810 Full example message flows will be left for another document. 812 Whether this PIDF-LO message body is S/MIME encrypted in the SIP 813 message or not, the PIDF-LO stays exactly the same. There is no 814 change to its format, text or characteristics. Whether TLS or IPSec 815 is used to encrypt this overall SIP message or not, the PIDF-LO 816 stays exactly the same. There is no change to its format, text or 817 characteristics. The examples in section 4.3 (Geo format) taken 818 from [RFC3825] and 4.4 (Civic format) taken from [ID-CIVIC] are for 819 the exact same position on the Earth. The differences between the 820 two formats is within the are of the examples. 821 Other than this portion, of each PIDF-LO, the rest the same for both 822 location formats. 824 825 830 831 2006-03-20T14:00:00Z 832 833 834 835 836 837 33.001111N 838 96.68142W 839 840 841 842 dhcp 843 www.cisco.com 844 845 no 846 2006-03-24T18:00:00Z 848 849 850 851 852 854 4.4 Example PIDF-LO in Civic Format 856 This subsection will show a sample of what just the PIDF-LO can look 857 like, as defined in [RFC4119]. Having this here will first offer a 858 look at a location by-value message body, and secondly, give readers 859 an appreciation for how large a location message body is so that 860 this document does not have to show a PIDF-LO in every message flow 861 example. This section shows a civic address based PIDF-LO. Section 862 4.3 shows this same position in a coordinate format. Full example 863 message flows will be left for another document. 865 Whether this PIDF-LO message body is S/MIME encrypted in the SIP 866 message or not, the PIDF-LO stays exactly the same. There is no 867 change to its format, text or characteristics. Whether TLS or IPSec 868 is used to encrypt this overall SIP message or not, the PIDF-LO 869 stays exactly the same. There is no change to its format, text or 870 characteristics. The examples in section 4.3 (Geo format) taken 871 from [RFC3825] and 4.4 (Civic format) taken from [ID-CIVIC] are for 872 the exact same position on the Earth. The differences between the 873 two formats is within the are of the examples. 874 Other than this portion, of each PIDF-LO, the rest the same for both 875 location formats. 877 878 883 884 2006-03-20T14:00:00Z 885 886 887 888 889 US 890 Texas 891 Colleyville 892 3913 893 Treemont 894 Circle 895 76034 896 Polk Place 897 1 898 899 900 dhcp 901 www.cisco.com 902 903 no 904 2006-03-24T18:00:00Z 906 907 908 909 910 912 5. SIP Element Behavior When Conveying Location 914 The SIP Request Methods that MUST convey location are the INVITE, 915 REGISTER, UPDATE and MESSAGE Methods. It is not forbidden by this 916 document to convey location with any other SIP method. However, no 917 other methods are detailed here. 919 The message flows in this document will be example messages 920 containing only the key headers to convey the point being made that 921 do not include all the requisite SIP headers. All well formed SIP 922 message flows are to be in a separate document for brevity here. 924 5.1 Location Conveyance Using the INVITE Method 926 Below is a common SIP session set-up sequence between two user 927 agents. In this example, Alice will provide Bob with her location 928 in the INVITE message. 930 UA Alice UA Bob 932 | [M1] INVITE | 933 |---------------------------------------->| 934 | [M2] 200 OK | 935 |<----------------------------------------| 936 | [M3] ACK | 937 |---------------------------------------->| 938 | RTP | 939 |<=======================================>| 940 | | 942 Figure 1. Location Conveyance in INVITE Requests 944 User agent Alice invites user agent Bob to a session [M1 of Figure 945 1]. 947 INVITE sips:bob@biloxi.example.com SIP/2.0 948 To: Bob 949 From: Alice ;tag=1928301774 950 Supported: Location 951 Location: cid:alice123@atlanta.example.com 953 If the message were S/MIME encrypted, this would be the Content-type 954 header: 956 Content-Type: application/pkcs7-mime; 957 smime-type=enveloped-data; name=smime.p7m 959 If this INVITE were not S/MIME encrypted, this would be the 960 Content-Type header: 962 Content-Type: multipart/mixed; boundary=boundary1 964 The obvious reason this for a multipart/mixed Content-Type is that 965 this is an INVITE message and there is an SDP message body part 966 included. This is not mandatory, but highly likely. The cid-url in 967 the Location header points a parsing entity that can view the 968 message body to where the PIDF-LO is in the message. 970 Within the non-S/MIME message body is this: 972 --boundary1 974 Content-Type: application/sdp 975 v=0 976 ... 978 --boundary1 980 Content-type: application/pidf+xml 981 PIDF-LO 983 --boundary1-- 985 In the INVITE, Alice's UAC included the Supported header with the 986 location option tag, and the Location header with the cid:url 987 pointing at the by-value PIDF-LO. These two headers MAY be hidden 988 in the S/MIME encrypted message body next to the topmost 989 Content-Type header to hide the fact that this message is carrying 990 location in transit. Bob's UAS, the destination UA of Alice's 991 message, will read these headers when deciphering the overall 992 message body. 994 - If Bob's UA wants to join the call, his UA responses with a 200 OK 995 [M2]. Bob can include his location in the 200 OK response, but 996 this shouldn't be expected to due to user timing. 998 A 424 (Bad Location Information) Response with a Unsupported header 999 (option tag of 'location') is the proper response if Bob's UA cannot 1000 display this information, but does understand the concept of 1001 location. 1003 [Alternative M2 of Figure 2] 1004 SIP/2.0 424 Bad Location Information 1005 To: Bob 1006 From: Alice ;tag=1928301774 1007 Unsupported: location 1009 - If Bob's UA accepts with a 200 OK message, Alice's UA replies with 1010 an ACK and the session is set up. 1012 - If Bob's UA does not accept the INVITE for reasons other than 1013 location included, a 488 (Not Acceptable Here) may be the 1014 response. 1016 Figure 1 does not include any Proxies because in it assumed they 1017 would not affect the session set-up with respect to whether or not 1018 Alice's location is in a message body part, and Proxies do not react 1019 to S/MIME encrypted bodies, making their inclusion more or less moot 1020 and asking for more complex message flows than necessary here. 1022 5.2 Location Conveyance Using the MESSAGE Method 1024 Alice can choose to merely want to communicate her location to Bob 1025 point-to-point, without starting a (voice) conversation, the MESSAGE 1026 Method MAY be used here. 1028 To comply with privacy concerns raised in [RFC3693] and [RFC4119], a 1029 MESSAGE Method Request would be built according to [RFC3428] that 1030 includes a location message body. S/MIME encryption SHOULD be used 1031 on the message body (part), as outlined in [RFC3261]. Figure 2 here 1032 shows a simplistic MESSAGE method message flow. 1034 UA Alice UA Bob 1036 | MESSAGE [M1] | 1037 |---------------------------------------->| 1038 | 200 OK [M2] | 1039 |<----------------------------------------| 1040 | | 1042 Figure 1. Location Conveyance in MESSAGE Requests 1044 Below is a sample, non-well-formed MESSAGE Method message from Alice 1045 to Bob conveying her geo location: 1047 [M1 of Figure 2] 1048 MESSAGE sips:bob@biloxi.example.com SIP/2.0 1049 To: Bob 1050 From: Alice 1051 Supported: location 1052 Location: cid:alice123@atlanta.example.com 1054 If the message were S/MIME encrypted, this would be the Content-type 1055 header: 1057 Content-Type: application/pkcs7-mime; 1058 smime-type=enveloped-data; name=smime.p7m 1060 If this MESSAGE request were not S/MIME encrypted, this would be the 1061 Content-Type header: 1063 Content-Type: multipart/mixed; boundary=boundary1 1065 --boundary1 1067 Content-Type: text/plain 1068 Here's my location, Bob? 1069 --broundary1 1071 Content-Type: application/pidf+xml 1072 Content-Disposition: render 1073 [Alice's PIDF-LO goes here] 1075 --broundary1-- 1077 The Content-type of M1 here is "multipart/mixed" to have a text 1078 message incorporated into the message. Within the PIDF-LO message 1079 body, there is a Content-Disposition of "render" to display this 1080 location information to Bob when his UA receives it. The cautions 1081 about whether or not Bob actually reads this message are outlined in 1082 [RFC3428]. 1084 The 200 OK to M1 of Figure 2 is a simple 200 OK. 1086 A 424 (Bad Location Information) Response with a Unsupported header 1087 (option tag of 'location') is the proper response if Bob's UA cannot 1088 display this information, but does understand the concept of 1089 location. 1091 [Alternative M2 of Figure 2] 1092 SIP/2.0 424 Bad Location Information 1093 To: Bob 1094 From: Alice 1095 Unsupported: location 1097 If Bob is declining the M2 MESSAGE Request message, a 488 (Not 1098 Acceptable Here) is the appropriate response. A Supported header 1099 with a location option tag indicates location was not the reason 1100 this message was declined. 1102 [Alternative M2 of Figure 2] 1103 SIP/2.0 488 Not Acceptable Here 1104 To: Bob 1105 From: Alice 1106 Supported: location 1108 5.3 Location Conveyance Using the UPDATE Method 1110 The UPDATE Method [RFC3311] is to be used any time location 1111 information is to be updated between UAs setting up a dialog or 1112 after the dialog has been established, no matter how long that 1113 dialog has been operational. reINVITE is inappropriate here, and 1114 the MESSAGE Method is for non-dialog location conveyance between UAs 1115 only. The same security properties used in the INVITE MUST be 1116 applied in the UPDATE message. 1118 There are 3 conditions UPDATE is to be used to convey location 1119 between UAs: 1121 1) During dialog establishment, but before the final 200 OK (see 1122 section 5.3.1) 1124 2) After dialog establishment, but no prior location information has 1125 been convey (see section 5.3.2), and 1127 3) After dialog establishment, when a UA has determined it has moved 1128 (see section 5.3.3) 1130 5.3.1 UPDATE Updates Location During Session Establishment 1132 Figure 3a. shows the first example of what the UPDATE Method is 1133 used: during dialog establishment when Alice updates Bob with her 1134 location information [M3]. This might be different location 1135 information than was in message [M1] of Figure 3a. or it could be 1136 the first time Alice conveys location to Bob during the dialog 1137 set-up. 1139 UA Alice UA Bob 1141 | INVITE [M1] | 1142 |---------------------------------------->| 1143 | UPDATE [M2] | 1144 |---------------------------------------->| 1145 | 200 OK (UPDATE) [M3] | 1146 |<----------------------------------------| 1147 | 200 OK (INVITE) [M4] | 1148 |<----------------------------------------| 1149 | ACK (UPDATE) [M5] | 1150 |---------------------------------------->| 1151 | RTP | 1152 |<=======================================>| 1153 | | 1155 Figure 3a. Updating Location During Dialog Establishment 1157 [M2 of Figure 3a] 1158 UPDATE sips:bob@biloxi.example.com SIP/2.0 1159 To: Bob 1160 From: Alice 1161 Supported: location 1162 Location: cid:alice123@atlanta.example.com 1163 Content-Type: multipart/mixed; boundary=boundary1 1165 --boundary1 1167 Content-Type: application/sdp 1168 v= 1169 ... 1171 --broundary1 1173 Content-Type: application/pidf+xml 1174 [Alice's PIDF-LO goes here] 1176 --broundary1-- 1178 The above example has Alice also changing something within her 1179 original SDP, but this is not necessary for this update of location 1180 information. 1182 - If Bob agrees with this INVITE and the UPDATE, there his UA 1183 transits 200 OKs for each [M4] and [M5] in Figure 3a. 1185 - Alice, upon receiving the 200 OKs, sends an ACK to establish the 1186 dialog with her modified location. 1188 Bob's UA should send a 424 (Bad Location Information) Response with 1189 a Unsupported header (stating 'location') if his UA does not 1190 understand the concept of location conveyance; meaning to the INVITE 1191 in [M1]. Therefore, a 424 SHOULD NOT be sent to the UPDATE of 1192 location information if the PIDF-LO is well formed and has valid 1193 (not validated!) location fields. If Bob's UA sends a 424 to this 1194 UPDATE without an Unsupported header containing a location option 1195 tag, Alice's UA MUST interpret that to mean the location in the 1196 PIDF-LO was poorly generated. Perhaps it was missing a field. 1197 Perhaps a field was incomplete. 1199 If Bob is declining the M2 UPDATE Request message, a 488 (Not 1200 Acceptable Here) is the appropriate response. A Supported header 1201 with a location option tag indicates location was not the reason 1202 this message was declined. 1204 [Alternative M3 of Figure 3a] 1205 SIP/2.0 488 Not Acceptable Here 1206 To: Bob 1207 From: Alice 1208 Supported: location 1210 5.3.2 UPDATE Updates Location After Session Establishment 1212 Figure 3b. shows the second example of what the UPDATE Method is 1213 used for: if a dialog exists between Alice and Bob without location 1214 having been conveyed previously in either direction, and one of the 1215 UAs wants to convey location to the other. For example, if Alice 1216 invites Bob to a dialog, but does not include her location in that 1217 dialog establishment. Anytime during that dialog that Alice's UA 1218 decides to convey location, she uses the UPDATE Method, not the 1219 INVITE Method (in a reINVITE), to update the location parameters of 1220 that dialog. 1222 Once a dialog has been established, a UAC MUST NOT use the INVITE 1223 Method as a reINVITE to convey location within a dialog. The UPDATE 1224 Method MUST be used. 1226 Consider the following example message flow in Figure 3b.: 1228 UA Alice UA Bob 1230 | INVITE [M1] | 1231 |---------------------------------------->| 1232 | 200 OK (INVITE) [M2] | 1233 |<----------------------------------------| 1234 | ACK [M3] | 1235 |<----------------------------------------| 1236 | RTP | 1237 |<=======================================>| 1238 | UPDATE [M4] | 1239 |---------------------------------------->| 1240 | 200 OK (UPDATE) [M5] | 1241 |<----------------------------------------| 1242 | | 1244 Figure 3b. Updating Location After Dialog Establishment 1246 For whatever reason, Alice decides to send Bob her location for the 1247 first time. [M4] is an example of the UPDATE message used to 1248 accomplish this. 1250 [M4 of Figure 3b] 1251 UPDATE sips:bob@biloxi.example.com SIP/2.0 1252 To: Bob 1253 From: Alice 1254 Supported: location 1255 Location: cid:alice123@atlanta.example.com 1256 Content-Type: application/pidf+xml 1258 [Alice's PIDF-LO goes here] 1260 A 424 (Bad Location Information) Response with a Unsupported header 1261 (stating Location) is the proper response if Bob's UA does not 1262 understand the concept of location. In this case, the dialog MUST 1263 remain unaffected by this rejection message. Here is a rough idea 1264 of this 424: 1266 [Alternative M5 of Figure 3b] 1267 SIP/2.0 424 Bad Location Information 1268 To: Bob 1269 From: Alice 1270 Unsupported: location 1272 If Bob is declining the M4 UPDATE Request message, a 488 (Not 1273 Acceptable Here) is the appropriate response. A Supported header 1274 with a location option tag indicates location was not the reason 1275 this message was declined. 1277 [Alternative M5 of figure 3b] 1278 SIP/2.0 488 Not Acceptable Here 1279 To: Bob 1280 From: Alice 1281 Supported: location 1283 5.3.3 UPDATE Updates Location After a UA Moves in a Dialog 1285 Figure 3c. shows the first example of what the UPDATE Method is 1286 used: if one UA that already conveyed location to the other UA, and 1287 has moved since the dialog was originally sent up. How a UA 1288 determines it has moved is out of scope for this document. 1290 However that "movement" trigger occurred, M4 of Figure 3c. is the 1291 result: an UPDATE Method Request indicating new location by Alice, 1292 to keep Bob current with Alice's position. 1294 UA Alice UA Bob 1296 | INVITE [M1] | 1297 |---------------------------------------->| 1298 | 200 OK (INVITE) [M2] | 1299 |<----------------------------------------| 1300 | ACK [M3] | 1301 |<----------------------------------------| 1302 | RTP | 1303 |<=======================================>| 1304 **Alice's UA determines it has moved, and needs to update Bob** 1306 | UPDATE [M4] | 1307 |---------------------------------------->| 1308 | 200 OK (UPDATE) [M5] | 1309 |<----------------------------------------| 1310 | | 1312 Figure 3c. Updating Location During Dialog After Movement 1314 This message flow assumes Alice conveyed location in [M1], and that 1315 Bob's UA supports location conveyance by not rejecting the INVITE 1316 request. 1318 Message M4 of Figure 3c. shows the UPDATE of Alice's location 1319 information to Bob. That message may look like this (non-well- 1320 formed SIP message): 1322 [M4 of Figure 3c] 1323 UPDATE sips:bob@biloxi.example.com SIP/2.0 1324 To: Bob 1325 From: Alice 1326 Supported: location 1327 Location: cid:alice123@atlanta.example.com 1328 Content-Type: application/pidf+xml 1330 [Alice's PIDF-LO goes here] 1332 There currently is not an indication within the PIDF-LO for Alice to 1333 tell Bob this PIDF-LO is new, replacement location information from 1334 a previous message (here in the M1 INVITE message). 1336 Because of the 200 OK to the INVITE containing location, Alice knows 1337 Bob's UA understands location conveyance. Therefore, if Bob's UA 1338 sends a 424 to this UPDATE, it MUST NOT contain an Unsupported 1339 header containing a location option tag. 1341 If Alice does receive a 424 (with the Unsupported header with a 1342 location option tag), Alice's UA MUST interpret that to mean the 1343 location in the PIDF-LO was poorly generated. Perhaps it was 1344 missing a field. Perhaps a field was incomplete. 1346 If Bob is declining the M4 UPDATE Request message, a 488 (Not 1347 Acceptable Here) is the appropriate response. A Supported header 1348 with a location option tag indicates location was not the reason 1349 this message was declined. 1351 [Alternative M5 of figure 3c] 1352 SIP/2.0 488 Not Acceptable Here 1353 To: Bob 1354 From: Alice 1355 Supported: location 1357 5.4 Location Conveyance Using the REGISTER Method 1359 Alice can choose to merely want to communicate her location to Bob 1360 point-to-point, without starting a (voice) conversation, the 1361 REGISTER Method MAY be used here. 1363 To comply with privacy concerns raised in [RFC3693] and [RFC4119], a 1364 REGISTER Method Request MUST S/MIME encrypt the PIDF-LO, as outlined 1365 in [RFC3261]. A UAC SHOULD use a SIPS-URI, as outlined in 1366 [RFC3261]. Figure 4 here shows a simplistic REGISTER method 1367 message flow. 1369 UA Alice Registrar 1371 | REGISTER [M1] | 1372 |---------------------------------------->| 1373 | 200 OK [M2] | 1374 |<----------------------------------------| 1375 | | 1377 Figure 4. Location Conveyance in REGISTER Requests 1379 Below is a sample, non-well-formed REGISTER Method message from 1380 Alice to Bob conveying her geo location: 1382 [M1 of Figure 2] 1383 REGISTER sips:registrar1@biloxi.example.com SIP/2.0 1384 To: Alice ; 1385 From: Alice ;tag=1928301774 1386 Supported: location 1387 Location: cid:alice123@atlanta.example.com 1388 Expires: 21600 1390 If the message were S/MIME encrypted, this would be the Content-type 1391 header: 1393 Content-Type: application/pkcs7-mime; 1394 smime-type=enveloped-data; name=smime.p7m 1396 If this REGISTER request were not S/MIME encrypted, this would be 1397 the Content-Type header: 1399 Content-Type: application/pidf+xml 1401 provided there were no other registration event message bodies. 1403 The 200 OK to M1 of Figure 2 is a simple 200 OK. 1405 A 424 (Bad Location Information) Response with a Unsupported header 1406 (option tag of 'location') is the proper response if the Registrar 1407 server does not understand location conveyance. 1409 [Alternative M2 of Figure 2] 1410 SIP/2.0 424 Bad Location Information 1411 To: Alice 1412 From: Alice 1413 Unsupported: location 1415 If the Registrar Server is declining the original [M1] REGISTER 1416 Request, a 488 (Not Acceptable Here) is the appropriate response. A 1417 Supported header with a location option tag indicates location was 1418 not the reason this message was declined. 1420 [Alternative M2 of Figure 2] 1421 SIP/2.0 488 Not Acceptable Here 1422 To: Alice 1423 From: Alice 1424 Supported: location 1426 6. Special Considerations for Emergency Calls 1428 Emergency calling, such as 911, 112 and 999 calling today, 1429 necessitates a UAC to understand the type of call it is about to 1430 generate with an INVITE message to a PSAP. First of all, the 1431 purpose of calling for emergency help is to get someone to respond 1432 to the UAC's location, therefore, location MUST be included in the 1433 INVITE, if known by the UAC. 1435 The emergency services community strongly prefers that message 1436 routing occur in the network with the freshest available Public 1437 Safety Answering Point (PSAP) information. Message routing, in this 1438 context, means choosing which SIP(S)-URI to place in the Request-URI 1439 field of the status line. 1441 If a UAC knows it is generating an emergency request towards a PSAP, 1442 there MAY be unique message handling characteristics that diminish 1443 the level of confidentiality of the location information within the 1444 SIP message(s). This is because emergency call routing requires 1445 proxies to know the location of the message originating UAC in order 1446 to make a decision on where to route the message. This is because 1447 emergency calls are directed to the PSAP local to the caller's 1448 location. A proxy performing this function requires that proxy to 1449 learn the location of the UAC during message processing. 1451 How a message is routed based on the location of the UAC, and if and 1452 by how much the level of confidentiality of location information is 1453 diminished when calling for emergency help are both out of scope of 1454 this document. 1456 Hop-by-hop confidentiality mechanisms, as defined in [RFC3261] MUST 1457 be attempted initially by a UAC that includes location. Local 1458 configuration MAY allow a subsequent retry, after a security related 1459 failure, to be without hop-by-hop confidentiality. SIP elements 1460 MUST obey the rules set forth in [RFC3261] regarding maintaining 1461 hop-by-hop confidentiality when a message using a SIPS-URI. 1463 While many jurisdictions force a user to reveal their location 1464 during an emergency call set-up, there is a small, but real, number 1465 of jurisdictions that allow a user to configure their calling device 1466 to disable providing location, even during emergency calling. This 1467 capability MUST be configurable, but is not RECOMMENDED as the 1468 default configuration of any UA. Local policies will dictate this 1469 ability. 1471 7. Meeting RFC3693 Requirements 1473 Section 7.2 of [RFC3693] details the requirements of a "using 1474 protocol". They are: 1476 Req. 4. The using protocol has to obey the privacy and security 1477 instructions coded in the Location Object and in the 1478 corresponding Rules regarding the transmission and storage of the 1479 LO. 1481 This document requires, in Section 3, that SIP entities sending or 1482 receiving location MUST obey such instructions. 1484 Req. 5. The using protocol will typically facilitate that the keys 1485 associated with the credentials are transported to the respective 1486 parties, that is, key establishment is the responsibility of the 1487 using protocol. 1489 [RFC3261] and the documents it references define the key establish 1490 mechanisms. 1492 Req. 6. (Single Message Transfer) In particular, for tracking of 1493 small target devices, the design should allow a single 1494 message/packet transmission of location as a complete 1495 transaction. 1497 This document specifies that the LO be contained in the body of a 1498 single message, which may be fragmented via TCP, but is still not a 1499 streaming delivery. 1501 8. Open issues 1503 This is a list of open issues that have not yet been addressed to 1504 conclusion: 1506 none 1508 9. Security Considerations 1510 Conveyance of physical location of a UAC is problematic for many 1511 reasons. This document calls for that conveyance to normally be 1512 accomplished through secure message body means (like S/MIME or TLS). 1513 In cases where a session set-up is routed based on the location of 1514 the UAC initiating the session or SIP MESSAGE, securing the location 1515 with an end-to-end mechanism such as S/MIME is problematic, due to 1516 the probability of a proxy from requiring the ability to read that 1517 information to route the message appropriately. This means the use 1518 of S/MIME may not be possible. This leaves location information of 1519 the caller available in each proxy through to the PSAP. This may 1520 not be a perfect solution, but may be a pill we need to swallow to 1521 enable this functionality. 1523 A bad implementation of SIP location conveyance would have a UAC 1524 send location in cleartext, without hop-by-hop confidentiality, or 1525 have any SIP element along the path towards the PSAP alter the 1526 transport of any message carrying location to be without hop-by-hop 1527 confidentiality between elements. The latter would be in clear 1528 violation of RFC3261 rules surrounding the use of a SIPS-URI. 1530 10. IANA Considerations 1532 This section defines one new SIP header, two new option tags, and 1533 one new 4XX error response code within the sip-parameters section of 1534 IANA. [NOTE: RFC XXXX denotes this document]. 1536 10.1 IANA Registration for the SIP Location Header 1538 The Location header is created by this document, with its definition 1539 and rules in Section 4 of this document. 1541 10.2 IANA Registration for Two New SIP Option Tags 1543 Two new SIP option tags are created by this document, "Location" and 1544 "Unknown-location", with the definitions and rules for each in 1545 Section 4 of this document. 1547 10.3 IANA Registration for Response Code 4XX 1549 Reference: RFC-XXXX (i.e. this document) 1550 Response code: 424 1551 Default reason phrase: Bad Location Information 1553 11. Acknowledgements 1555 To Dave Oran for helping to shape this idea. To Jon Peterson and 1556 Dean Willis on guidance of the effort. To Henning Schulzrinne, 1557 Jonathan Rosenberg, Dick Knight, Mike Hammer and Keith Drage for 1558 constructive feedback. 1560 To Paul Kyzivat for inspiring some of the recent text addressing 1561 lingering issues the authors could not resolve. 1563 To Jon Peterson for his guidance in this effort. 1565 12. References 1567 12.1 References - Normative 1569 [RFC3261] J. Rosenberg, H. Schulzrinne, G. Camarillo, A. Johnston, J. 1570 Peterson, R. Sparks, M. Handley, and E. Schooler, "SIP: 1571 Session Initiation Protocol", RFC 3261, May 2002. 1573 [RFC3693] J. Cuellar, J. Morris, D. Mulligan, J. Peterson. J. Polk, 1574 "Geopriv Requirements", RFC 3693, February 2004 1576 [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate 1577 Requirement Levels", RFC 2119, March 1997 1579 [RFC4119] J. Peterson, "draft-ietf-geopriv-pidf-lo-03", Internet 1580 Draft, Sept 2004, work in progress 1582 [RFC3428] B. Campbell, Ed., J. Rosenberg, H. Schulzrinne, C. Huitema, 1583 D. Gurle, "Session Initiation Protocol (SIP) Extension for 1584 Instant Messaging" , RFC 3428, December 2002 1586 [RFC2392] E. Levinson, " Content-ID and Message-ID Uniform Resource 1587 Locators", RFC 2393, August 1998 1589 [RFC3311] J. Rosenberg, "The Session Initiation Protocol (SIP) UPDATE 1590 Method", RFC 3311, October 2002 1592 12.2 References - Informative 1594 [ID-Sess-Pol] J. Rosenberg, "Requirements for Session Policy for the 1595 Session Initiation Protocol�, draft-ietf-sipping-session- 1596 policy-req-02", Internet Draft, July, 2004, "work in 1597 progress" 1599 [RFC3825] J. Polk, J. Schnizlein, M. Linsner, "Dynamic Host 1600 Configuration Protocol Option for Coordinate-based Location 1601 Configuration Information", RFC 3825, July 2004 1603 [ID-CIVIC] H. Schulzrinne, " Dynamic Host Configuration Protocol 1604 (DHCPv4 and DHCPv6) Option for Civic Addresses Configuration 1605 Information ", draft-ietf-geopriv-dhcp-civil-09, "work in 1606 progress", January 2006 1608 Author Information 1610 James M. Polk 1611 Cisco Systems 1612 3913 Treemont Circle 33.00111N 1613 Colleyville, Texas 76034 96.68142W 1615 Phone: +1-817-271-3552 1616 Email: jmpolk@cisco.com 1618 Brian Rosen 1619 470 Conrad Dr. 40.70497N 1620 Mars, PA 16046 80.01252W 1621 US 1623 Phone: +1 724 382 1051 1624 Email: br@brianrosen.net 1626 Intellectual Property Statement 1628 The IETF takes no position regarding the validity or scope of any 1629 Intellectual Property Rights or other rights that might be claimed 1630 to pertain to the implementation or use of the technology described 1631 in this document or the extent to which any license under such 1632 rights might or might not be available; nor does it represent that 1633 it has made any independent effort to identify any such rights. 1634 Information on the procedures with respect to rights in RFC 1635 documents can be found in BCP 78 and BCP 79. 1637 Copies of IPR disclosures made to the IETF Secretariat and any 1638 assurances of licenses to be made available, or the result of an 1639 attempt made to obtain a general license or permission for the use 1640 of such proprietary rights by implementers or users of this 1641 specification can be obtained from the IETF on-line IPR repository 1642 at http://www.ietf.org/ipr. 1644 The IETF invites any interested party to bring to its attention any 1645 copyrights, patents or patent applications, or other proprietary 1646 rights that may cover technology that may be required to implement 1647 this standard. Please address the information to the IETF at 1648 ietf-ipr@ietf.org. 1650 Disclaimer of Validity 1652 This document and the information contained herein are provided on 1653 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 1654 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE 1655 INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR 1656 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1657 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1658 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1660 Copyright Statement 1662 Copyright (C) The Internet Society (2006). This document is subject 1663 to the rights, licenses and restrictions contained in BCP 78, and 1664 except as set forth therein, the authors retain all their rights. 1666 Acknowledgment 1668 Funding for the RFC Editor function is currently provided by the 1669 Internet Society.