idnits 2.17.1 draft-ietf-sip-location-conveyance-01.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 3670. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 3647. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 3654. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 3660. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == There are 3 instances of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard == It seems as if not all pages are separated by form feeds - found 0 form feeds but 73 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 10 instances of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 26 has weird spacing: '...ference mater...' == Line 776 has weird spacing: '...der the subje...' == Line 881 has weird spacing: '... Rr amd...' == Line 885 has weird spacing: '... Rr amd...' -- The exact meaning of the all-uppercase expression 'MAY NOT' is not defined in RFC 2119. If it is intended as a requirements expression, it should be rewritten using one of the combinations defined in RFC 2119; otherwise it should not be all-uppercase. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: U-U5 - UAC MUST not use S/MIME on the Location message body if the message is a dialog related or MESSAGE Request message unless the UAC has a pre-established association with the routing SIP intermediary. == The expression 'MAY NOT', while looking like RFC 2119 requirements text, is not defined in RFC 2119, and should not be used. Consider using 'MUST NOT' instead (if that is what you mean). Found 'MAY NOT' in this paragraph: indicates the Content-ID location [RFC2392] within the multipart message body of were location information is. The geo-loc option-tag indicates the location format within the PIDF-LO message body. If both geo-loc and civic-loc formats were present in the PIDF-LO, the UAC SHOULD include both option-tags if it includes either. The UAC MAY NOT include either option-tag indicating the format of location within the message body. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: If the intermediary does not understand this message and its relationship to location, perhaps because it does not understand the concept of routing based on the UAC's location, it needs to forward the message to another intermediary that will understand how to take location from the message and route it correctly, or communicate with the UAC if there are issues with the message. The intermediary MUST not reject the message because it does not understand the concept of "location". This document does not define how this occurs, as the offered solution here is to include a "Proxy-Require" and a "Require" header in this original Request. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: b) if the intermediary does not understand location, and there is no "Proxy-Require" and/or a "Require" header indicating "location", the intermediary MUST not reject the message, but MUST forward this message to another (upstream) SIP intermediary for proper processing. -- 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 3457, but not defined == Missing Reference: 'M2' is mentioned on line 3459, but not defined == Missing Reference: 'M3' is mentioned on line 3461, but not defined == Missing Reference: 'M4' is mentioned on line 3463, but not defined == Missing Reference: 'M5' is mentioned on line 3556, but not defined == Missing Reference: 'M6' is mentioned on line 3467, but not defined == Missing Reference: 'M7' is mentioned on line 3469, but not defined == Missing Reference: 'M8' is mentioned on line 3035, but not defined == Missing Reference: 'M9' is mentioned on line 3039, but not defined == Missing Reference: 'M10' is mentioned on line 3041, but not defined == Missing Reference: 'M11' is mentioned on line 3043, but not defined == Missing Reference: 'M12' is mentioned on line 3045, but not defined == Missing Reference: 'M13' is mentioned on line 1456, but not defined == Missing Reference: 'M14' is mentioned on line 1458, but not defined ** Obsolete normative reference: RFC 3825 (Obsoleted by RFC 6225) -- Possible downref: Non-RFC (?) normative reference: ref. 'ID-CIVIC' ** Downref: Normative reference to an Informational RFC: RFC 3693 -- Possible downref: Non-RFC (?) normative reference: ref. 'ID-PIDF-LO' ** Obsolete normative reference: RFC 2393 (ref. 'RFC2392') (Obsoleted by RFC 3173) ** Obsolete normative reference: RFC 3265 (Obsoleted by RFC 6665) == Outdated reference: A later version (-06) exists of draft-ietf-sipping-e2m-sec-reqs-03 == Outdated reference: A later version (-02) exists of draft-ietf-sipping-session-policy-req-00 Summary: 7 errors (**), 0 flaws (~~), 29 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SIP Working Group James M. Polk 3 Internet Draft Cisco Systems 4 Expiration: Jan 17th, 2006 Brian Rosen 5 NeuStar 7 Session Initiation Protocol Location Conveyance 8 draft-ietf-sip-location-conveyance-01.txt 9 July 17th, 2005 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six 24 months and may be updated, replaced, or obsoleted by other documents 25 at any time. It is inappropriate to use Internet-Drafts as 26 reference material or to cite them other than as "work in 27 progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on January 17th, 2006. 37 Copyright Notice 39 Copyright (C) The Internet Society (2005). 41 Abstract 43 This document presents the framework and requirements for usage of 44 the Session Initiation Protocol (SIP) to convey user location 45 information from one Session Initiation Protocol (SIP) entity to 46 another SIP entity. We consider cases where location information is 47 conveyed from end to end, as well as cases where message routing by 48 intermediaries is influenced by the location of the session 49 initiator, the user agent client (UAC). We offer a set of solutions 50 to the requirements, each based on the scenario being addressed. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 55 1.1 Conventions . . . . . . . . . . . . . . . . . . . . . . . 4 56 1.2 Changes from Prior Versions . . . . . . . . . . . . . . . 4 57 2. Location In the Body or in a Header . . . . . . . . . . . . . 7 58 3. Scope of Location Conveyance . . . . . . . . . . . . . . . . 8 59 3.1 Scope of Location in a Message Body . . . . . . . . . . . 8 60 3.2 Scope of Location in a Header . . . . . . . . . . . . . . 9 61 4. Requirements for UA-to-UA Location Conveyance . . . . . . . . 10 62 5. Requirements for UA-to-Proxy Server Location Conveyance . . . 11 63 6. Additional Requirements for Emergency Calls . . . . . . . . . 12 64 7. Location Conveyance Using SIP . . . . . . . . . . . . . . . . 14 65 7.1 Indicating Support for Location by the UAC . . . . . . . 16 66 7.2 Location Rejection Responses . . . . . . . . . . . . . . 19 67 7.3 Example PIDF-LO in Geo Format . . . . . . . . . . . . . . 20 68 7.4 Example PIDF-LO in Civic Format . . . . . . . . . . . . . 21 69 8. Location Conveyance UA-to-UA . . . . . . . . . . . . . . . . 23 70 8.1 UA-to-UA Using INVITE . . . . . . . . . . . . . . . . . . 23 71 8.1.1 UA-to-UA Using INVITE w/ Geo Format w-w/o S/MIME . . 25 72 8.1.2 UA-to-UA Using INVITE w/ Civic Format w-w/o S/MIME . 26 73 8.1.3 UA-to-UA Using INVITE Involving 3 Users . . . . . . . 28 74 8.2 OPTIONS Method and Location . . . . . . . . . . . . . . . 31 75 8.2.1 OPTIONS Request to Learn UAC's Location . . . . . . . 31 76 8.2.2 OPTIONS Request to Learn UAS's Location . . . . . . . 33 77 8.3 UA-to-UA Using MESSAGE . . . . . . . . . . . . . . . . . 34 78 8.4 UA-to-UA Using UPDATE . . . . . . . . . . . . . . . . . . 36 79 8.4.1 UPDATE Updates Location During Session 80 Establishment . . . . . . 37 81 8.4.2 UPDATE Updates Location After Session 82 Establishment . . . . . . 39 83 8.4.3 UPDATE Updates Location After a UA Moves 84 in a Dialog . . . . . . 40 85 8.5 Location Conveyance Using PUBLISH . . . . . . . . . . . . 42 86 8.6 UA-to-UA Location Conveyance Using SUBSCRIBE and NOTIFY . 44 87 9. Special Considerations for Emergency Calls . . . . . . . . . 47 88 9.1 Emergency UAC Behavior Rules . . . . . . . . . . . . . . 49 89 9.2 Emergency UAS/Intermediary Behavior Rules . . . . . . . . 50 90 9.3 Basic Emergency Message Flow Examples . . . . . . . . . . 52 91 10. Meeting RFC 3693 Requirements . . . . . . . . . . . . . . . . 55 92 11. Open issues . . . . . . . . . . . . . . . . . . . . . . . . . 55 93 12. Security Considerations . . . . . . . . . . . . . . . . . . . 56 94 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . 56 95 13.1 IANA Registration for Response Code 424 . . . . . . . . 56 96 13.2 IANA Registration for Response Code 425 . . . . . . . . 56 97 13.3 IANA Registration for the SIP Location Header . . . . . 56 98 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 57 99 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 57 100 15.1 Normative References . . . . . . . . . . . . . . . . . 57 101 15.2 Informative References . . . . . . . . . . . . . . . . . 58 102 Author Information . . . . . . . . . . . . . . . . . . . . . 58 103 Intellectual Property and Copyright Statements . . . . . . . 72 105 1. Introduction 107 This document presents the framework and requirements for the usage 108 of the Session Initiation Protocol (SIP) [RFC3261] for conveyance of 109 user location information described by [RFC3693] from a SIP entity 110 to another SIP entity. 112 There are several situations in which it is appropriate for SIP to 113 be used to convey Location Information (LI) from one SIP entity to 114 another. This document specifies requirements when a SIP UAC knows 115 its location by some means not specified herein, and needs to inform 116 another SIP entity. One example is one user agent informing another 117 user agent where it is (i.e. you want to tell your friend where you 118 are). There is a migration issue requiring the capability to convey 119 location seemingly from the source to destination, but in times in 120 which the source, or the originating user agent, has not be upgraded 121 to support this extension to the SIP architecture. There are 122 limitations to this "fix", but it serves a purpose for a critical 123 service discussed in sections 6 and 9 of this document. 125 Another example is to reach your nearest pizza parlor. A chain of 126 pizza parlors may be contacted through a single well known uri 127 (sip:pizzaparlor.com). This SIP message could be forwarded to the 128 closest franchise by the pizzaparlor.com proxy server. The 129 receiving franchise UAS uses the location information of the UAC to 130 determine the location your delivery. 132 Another important example is emergency calling. A call to 133 sip:sos@example.com is an emergency call as in [ID-SIP-SOS]. The 134 example.com proxy server must route the call to the correct public 135 safety answering point (PSAP) determined by the location of the 136 caller. At the PSAP, the UAS must determine the correct 137 police/fire/ambulance/... service, which is also based on your 138 location. In many jurisdictions, precise location information of 139 the caller in distress is a required component of a call to an 140 emergency center. 142 A fourth example is a direction service, which might give you verbal 143 directions to a venue from your present position. This is a case 144 where only the destination UAS needs to receive the location 145 information. 147 This document does not discuss how the UAC discovers or is 148 configured with its location (either coordinate based such as from 149 [RFC3825] or civic based such as from [ID-CIVIC]). This document 150 will also not discuss the contents of the SIP message body part that 151 is the Location Object (LO) itself. We will specify the 152 requirements for SIP qualifying as a "using protocol" as defined by 153 Geopriv in [RFC3693]. 155 Sections 7, 8 and 9 give specific examples (in well-formed SIP 156 messages) of SIP UA and Proxy behavior for location conveyance, the 157 last of which is a section devoted to the unique circumstances 158 regarding emergency calling. Section 10 addresses how this document 159 adheres to the requirements specified in [RFC3693] (Geopriv 160 Requirements). Sections 11 and 12 list the current open issues with 161 location conveyance in SIP, and the new open issues recently 162 discovered as a result of the added effort to this revision. 163 Section 13 IANA registers 2 new Response codes. 165 1.1 Conventions used in this document 167 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 168 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and 169 "OPTIONAL" in this document are to be interpreted as described 170 in [RFC2119]. 172 1.2 Changes from Prior Versions 174 [NOTE TO RFC-EDITOR: If this document is to be published as an RFC, 175 this section is to be removed prior to that event.] 177 This is a list of the changes that have been made from the SIP WG 178 version -00 to this version -01: 180 - cleaned up a lot of loose ends in the text 182 - created a new Location header to convey many means (location is in 183 the body - even if not viewable, which location format is present, 184 which format is requested in a query, how to request more than one 185 location format in a query, whether the UAC understands location 186 at all, if the UA knows its location, how to push location from 187 one UA to through a second to a third UA, etc). 189 - added the ability to convey location by-reference, but only under 190 certain conditions. 192 - Added support for the OPTIONS Request to query a server for the 193 UAC's location, through the use of the new Location header. 195 - moved both new Response code sections forward in the document for 196 their meaning to be clearer, earlier for necessary discussion. 198 - Changed the message flows to only have the pertinent message 199 headers shown for brevity. 201 - Added text to the SUB/NOT section showing how and why the location 202 of a UA can be refreshed or updated with an interval, or by a 203 trigger. 205 This is a list of the changes that have been made from the SIPPING 206 WG version -02 to this SIP WG item document version -00: 208 - Changed which WG this document is in from SIPPING to SIP due to 209 the extension of the protocol with new Response codes (424 and 210 425) for when there is an error involving the LO message body. 212 - Moved most of the well formed SIP messages out of the main body of 213 this document and into separate appendixes. This should clean up 214 the document from a readability point of view, yet still provide 215 the intended decode examples to readers of this document who wish 216 that level of detail per flow. The first few flows still have the 217 decoded SIP messages (unencrypted and encrypted). 219 - Removed some flow examples which no longer made sense 221 - Changed all references of "ERC" (Emergency Response Center) to 222 "PSAP" (Public Safety Answering Point) as a result of discussion 223 within the new ECRIT WG to define a single term 225 This is a list of the changes that have been made from the sipping- 226 01 working group version of this effort to the sipping-02 version: 228 - added requirements for 2 new 4XX error responses (Bad Location 229 Information) and (Retry Location Body) 231 - added "Bad Location Information" as section 8.6 233 - added "Retry Location Body " as section 9.3 235 - added support for session mode to cover packet sizes larger than 236 the single packet limit of 1300 bytes in the message body 238 - added requirement for a SIP entity to SUBSCRIBE to another for 239 location information 241 - added SUBSCRIBE and NOTIFY as section 8.5 243 - added requirement to have user turn off any tracking created by 244 subscription 246 - removed doubt about which method to use for updating location 247 after a INVITE is sent (update) 249 - cleaned up which method is to be used if there is no dialog 250 existing (message) 252 - removed use of reINVITE to convey location 254 - clarified that UAs include element of PIDF-LO when 255 placing an emergency call (to inform PSAP who supplied Location 256 information) 258 - updated list of open issues 259 - added to IANA Considerations section for the two new 4XX level 260 error responses requested in the last meeting 262 This is a list of the changes that have been made from the sipping- 263 00 working group version of this ID to the sipping-01 version: 265 - Added the offered solution in detail (with message flows, 266 appropriate SIP Methods for location conveyance, and 268 - Synchronized the requirements here with those from the Geopriv 269 Working Group's (attempting to eliminate overlap) 271 - Took on the task of making this effort the SIP "using protocol" 272 specification from Geopriv's POV 274 - Refined the Open Issues section to reflect the progress we've made 275 here, and to indicate what we have discovered needs addressing, 276 but has not been to date. 278 This is a list of the changes that have been made from the -01 279 individual submission version to the sipping-00 version of this ID: 281 - Brian Rosen was brought on as a co-author 283 - Requirements that a location header were negatively received in 284 the previous version of this document. AD and chair advice was to 285 move all location information into a message body (and stay away 286 from headers) 288 - Added a section of "emergency call" specific requirements 290 - Added an Open Issues section to mention what hasn't been resolved 291 yet in this effort 293 This is a list of the changes that have been made from the 294 individual submission version -00 to the -01 version 296 - Added the IPR Statement section 298 - Adjusted a few requirements based on suggestions from the 299 Minneapolis meeting 301 - Added requirements that the UAC is to include from where it 302 learned its location in any transmission of its LI 304 - Distinguished the facts (known to date) that certain jurisdictions 305 relieve persons of their right to privacy when they call an PSAP, 306 while other jurisdictions maintain a person's right to privacy, 307 while still others maintain a person's right to privacy - but only 308 if they ask that their service be set up that way. 310 - Made the decision that TLS is the security mechanism for location 311 conveyance in emergency communications (vs. S/MIME, which is still 312 the mechanism for UA-to-UA non-emergency location conveyance 313 cases). 315 - Added the Open Issue of whether a Proxy can insert location 316 information into an emergency SIP INVITE message, and some of the 317 open questions surrounding the implications of that action 319 - added a few names to the acknowledgements section 321 2. Location In the Body or in a Header 323 In determining where "location" is placed in a SIP message, 324 consideration is taken as to where the trust model is based on the 325 architecture involved. 327 If the user agent has the location stored within it, and one user 328 agent wants to inform another user agent where it is, it seems 329 reasonable to have this accomplished by placing the location 330 information (coordinate or civic) in an S/MIME registered and 331 encoded message body, and sending it as part of a SIP request or 332 response. No routing of the request based on the location 333 information is required in this case; therefore no SIP Proxies 334 between these two UAs need to view the location information 335 contained in the SIP messages. This is location by-value. 337 Although SIP [RFC3261] does not permit SIP intermediaries to modify 338 or delete a message body, there is no restriction on viewing message 339 bodies. S/MIME protected message bodies, implemented on bodies for 340 communications between user agents only, would render the location 341 object opaque to a proxy server for any desired modification if it 342 is not correct or precise enough from that proxy's point of view 343 (were it to be able to view it). This problem is similar to that 344 raised in Session Policy [ID-Sess-Pol], where an intermediary may 345 need information in a body, such as IP address of media streams or 346 codec choices to route a call properly. Requirements in [ID-Sess- 347 Pol] are applicable to routing based on location, and are 348 incorporated in these requirements by reference. 350 It is conceivable to create a new header for location information. 351 However, [RFC3693] prefers S/MIME for security of Location 352 Information, and indeed S/MIME is preferable in SIP [RFC3261] for 353 protecting a message body. Accordingly, these requirements specify 354 location be carried in a body when it is known to/stored in a user 355 agent. 357 It is the use of S/MIME however, that limits message routing based 358 on the location of the UAC. Therefore, it seems appropriate to 359 require that, where routing is dependent on location, protection of 360 the location information object be accomplished by other mechanisms 361 visible to SIP proxies: here TLS ("sips:" from [RFC3261]). It is 362 envisioned that S/MIME SHOULD be used when location information is 363 not required by proxy servers, and TLS MUST be used when it is. The 364 UAC will need to know the difference in the call's intent as to 365 which security mechanism to engage for location conveyance. 367 There is another limitation, one that is very real, as a unfortunate 368 result of how certain messages are addressed that limits this 369 restriction to "only in a message body shall location be". Because 370 SIP will be used for emergency calling, and because emergency 371 calling has nothing like an area code - given SIP's purposeful 372 separation from geophysical awareness - a means must be created for 373 any SIP UA to call 911 or 112 (or the like). Because this document 374 is not being generated when all SIP devices are, it is an extension 375 to all UAs existing today. This means for some time, there will 376 need to at least be a stop-gap mechanism for conveying location for 377 the purposes of routing an emergency call which is highly dependent 378 on where it is on the planet; something SIP generally cares nothing 379 about. With this in mind, a Location header will be created to 380 accomplish a location by-reference insertion by a SIP intermediary 381 along the path from UAC towards a Public Safety Answering Point 382 (PSAP). This will not be the sole purpose of this header, but this 383 header can be used for this purpose, as [RFC3261] allows SIP 384 intermediaries to insert headers in transit. 386 This document does not address the behavior or configuration of SIP 387 Proxy Servers in cases in order to accomplish location-sensitive 388 routing. That is out of scope, and left for further study. 390 3. Scope of Location Conveyance 392 As concluded from the previous section, location information is to 393 be contained within a message body when the user agent has this 394 information locally. Location, if not known to the user agent, can 395 be inserted by a SIP intermediary in transit, but there must be 396 rules surround this capability. 398 3.1 Scope of Location in a Message Body 400 If location is to be protected with S/MIME, even when another body 401 (SDP for example) is also to be sent in the message, the rules 402 stated in section 7 of [RFC3261] regarding multipart MIME bodies 403 MUST be followed. The format and privacy/security rules of 404 [RFC3693] MUST too be followed. 406 User agents providing location can convey it incorrectly or 407 inappropriately. Therefore, there needs to be a new UAC error 408 response code created to inform the UAC by a UAS or Proxy of this 409 rejected request message because of the location information in the 410 message. If the SIP intermediary has location knowledge of the UAC, 411 it can include that information in an error message for use in a 412 subsequent request by that UAC, therefore, there needs to be two new 413 response codes currently not defined in SIP: 415 1) the first indicating the existing location information was not 416 considered good by the viewing or receiving SIP element. 418 There will be times in which the UAC does not know its location 419 information, or another SIP entity knows the UAC's location better 420 than the UAC itself. How this is determined is out of scope of this 421 document. In these times, a Proxy servers that know the location 422 of the UAC needs inform the UAC of its location information and have 423 that UAC include that message body in its next SIP message to the 424 same destination UA. This error code needs to be unique with 425 respect to the error code for merely incorrect location information 426 from the UAC. 428 2) a second new response code indicating the existing location 429 information was not considered good by the viewing SIP element, 430 but in this case, the SIP element does have current and correct 431 location information for the UAC to be one that included in a new 432 message body to be used in a subsequent SIP Request by the UAC. 434 This second response code would be more applicable for cases in 435 which a SIP intermediary knows more about the location of the UAC 436 than the UAC, and needs to get the more appropriate location 437 information into the SIP message in order for it to be processed 438 correctly by it, and upstream SIP intermediaries. This cannot occur 439 with existing rules stating message bodies cannot be modified or 440 added by intermediaries. This new response code message containing 441 new location information of the UAC appears the best course of 442 action. 444 Since there can be multiple location observations of the same UAC, 445 each transmitted or otherwise inputted into the UAC, there MUST be a 446 means for including more than one piece of location information in a 447 SIP message. As best as possible, each should be labeled to 448 indicate they are separate observations for the receiving entity to 449 determine which is most correct. 451 3.2 Scope of Location in a Header 453 The first, best location for location relating to the endpoint is in 454 the endpoint. This allows the endpoint to send its location to 455 wherever it wants, using whichever application it wants to use. 456 Keeping the location of an endpoint in a server on a network may be 457 detrimental to the operation at hand. One example is for emergency 458 calling. If the UA does not have its location, and a server does, 459 that means the server has to be 100% stateful of that UA's location 460 100% of the time, wherever that UA goes. [ID-EMER-ARCH] states 461 clearly that time is of the essence in placing an emergency call. 463 The time it takes to do a non-stateful lookup of a UAC's mobile 464 location will impact the time it takes SIP signaling to process that 465 location to determine which PSAP the call should be routed to. 467 Therefore, the use of location by-reference SHOULD be used as a last 468 resort. This becomes obviously the only choice if the UA has no 469 concept of location to include by-value in the first place. For 470 that reason, there needs to be an identifier in SIP messaging 471 indicating a UA is aware of location conveyance. This will greatly 472 speed up the processing at a SIP intermediary and limit its choices 473 when processing a SIP Request that may require location to be 474 present in the SIP message (such as emergency calling). Sections 6 475 and 9 delve deep into this topic. 477 This indication of location awareness MUST be outside a message 478 body, therefore in a header - and as one does not exist today 479 related to location, this document will create one. Section 7 480 details the many purposes of this header, including the ability to 481 convey which location format a UAC is transmitting, or a UAS wants. 483 4. Requirements for UA-to-UA Location Conveyance 485 The following are the requirements for UA-to-UA Location Conveyance 486 Situations where routing is not based on the LI of either UA, and 487 location is stored/cached in the UAC: 489 U-U1 - Dialog-initiating SIP Requests and their responses MUST 490 support Location Conveyance 492 U-U2 - The SIP MESSAGE method [RFC3428] MUST support Location 493 Conveyance 495 U-U3 - Other SIP Requests SHOULD support Location Conveyance 497 U-U4 - UAC Location information SHOULD remain confidential e2e 498 to the destination UAS except when the session is to an 499 identifiable emergency endsystem. 501 U-U5 - UAC MUST not use S/MIME on the Location message body 502 if the message is a dialog related or MESSAGE Request 503 message unless the UAC has a pre-established association 504 with the routing SIP intermediary. 506 U-U6 - UAS Location information SHOULD remain confidential e2e 507 to the destination UAC except when the session is to/from an 508 identifiable emergency endsystem. 510 Emergency callback is one example where this may apply. 512 U-U7 - The privacy and security rules established within the 513 Geopriv Working Group that would categorize SIP as a 'using 514 protocol' [RFC3693] MUST be met. See Section 10 for 515 analysis. 517 U-U8 - Location information SHOULD be contained in the location 518 Object as defined in [ID-PIDF-LO], which will satisfy all 519 format requirements for interoperability. 521 U-U9 - Location information MAY be contained in a by-reference URI 522 contained in a Location Header. All privacy and security 523 rules associated with a Location message body as defined in 524 [ID-PIDF-LO], MUST be maintained. 526 U-U10- User Agents MUST have a means for querying a remote server 527 for the UAC's location; including offering a preferential 528 location format to be returned. 530 U-U11- User Agents and Proxies SHOULD be able to handle SIP 531 messages in which Location Information is fragmented across 532 multiple packets. 534 U-U12- There MUST be a unique UAC error response code informing the 535 UAC it did not provide applicable location information. 537 U-U13- There MUST be a unique UAC error response code informing the 538 UAC of new Location Information known to a SIP Intermediary, 539 and the UAC MUST be prepared to receive that information in 540 the error response itself. 542 U-U14- There MUST be a means for publishing location state 543 information for a particular presentity to a Presence 544 Compositor Server. 546 U-U15- User Agents and Proxies SHOULD be able to process SIP 547 messages which contains more than one piece of Location 548 information. 550 U-U16- User Agents MUST have the ability to query another user 551 agent for location information refresh and movement of the 552 UA. 554 5. Requirements for UA-to-Proxy Server Location Conveyance 556 The following are the requirements for UA-to-Proxy Server Location 557 Conveyance situations: 559 U-PS1 - MUST work with dialog-initiating SIP Requests and 560 responses, as well as the SIP MESSAGE method [RFC3428], and 561 SHOULD work with most SIP messages. 563 U-PS2 - UAC location information SHOULD remain opaque to 564 intermediaries the message was not addressed to, but MUST 565 be useable (i.e. viewable) by intermediary proxy servers 566 requiring location knowledge of the UAC to properly route 567 the message. 569 U-PS3- User Agents MUST have a means for indicating they understand 570 what location conveyance is, but currently do not have their 571 location information to convey. 573 U-PS4 - The privacy and security rules established within the 574 Geopriv Working Group which would categorize SIP as a 575 'using protocol' MUST be met [RFC3693]. 577 U-PS5 - Proxy servers MUST NOT modify or remove an location message 578 body part ([RFC3261] currently forbids this). 580 U-PS6 - A SIP message containing location information MUST NOT be 581 rejected by a SIP intermediary because the message body 582 part or LO itself was not understood (except when the 583 intermediary complies with requirement U-PS8 below, or when 584 the SIP message is addressed to that intermediary). 586 With regards to requirement U-PS6, not all SIP Proxies are expected 587 to route messages based on the contained location information from 588 the UAC. There will likely be a SIP Proxy able to perform this 589 function downstream, and the original SIP message needs to reach 590 that location enabled Proxy to route correctly. 592 U-PS7 - There MUST be a unique UAC error response code informing 593 the UAC it did not provide applicable location information. 595 U-PS8 - There MUST be a unique UAC error response code informing 596 the UAC it did not provide applicable location information, 597 and to include the location information contained in the 598 message body of the error message for usage in the UAC's 599 next attempt to the same UAS of the original message. 601 6. Additional Requirements for Emergency Calls 603 Emergency calls have requirements that are not generally important 604 to other uses for location in SIP: 606 Emergency calls presently have between 2 and 8-second call setup 607 times. There is ample evidence that the longer call setup end of 608 the range causes an unacceptable number of callers to abandon the 609 call before it is completed. Two-second call completion time is a 610 goal of many existing emergency call centers. Allocating 25% of the 611 call set up for processing privacy concerns seems reasonable; 1 612 second would be 50% of the goal, which seems unacceptable; less than 613 0.5 second seems unachievable, therefore: 615 E-1 - Privacy mechanisms MUST add no more than 0.5 second of call 616 setup time when implemented in present technology UAs and 617 Proxy Servers. 619 It may be acceptable for full privacy mechanisms related to the 620 location of the UAC (and it's user) to be tried on an initial 621 attempt to place a call, as long as the call attempt may be retried 622 without the privacy mechanism present (or enabled) if the first 623 attempt fails. Abandoning privacy in cases of failure of the 624 privacy mechanism might be subject to user preference, although such 625 a feature would be within the domain of a UA implementation and thus 626 not subject to standardization. It should be noted that some 627 jurisdictions have laws that explicitly deny any expectation of 628 location privacy when making an emergency call, while others grant 629 the user the ability to remain anonymous even when calling an PSAP. 630 So far, this has been offered in some jurisdictions, but the user 631 within that jurisdiction must state this preference, as it is not 632 the default configuration. 634 E-2 � Privacy mechanisms MUST NOT be mandatory for successful 635 conveyance of location during an (sos-type) emergency call. 637 E-3 - It MUST be possible to provide a privacy mechanism (that does 638 not violate the other requirements within this document) to a 639 user within a jurisdiction that gives that user the right to 640 choose not to reveal their location even when contacting an 641 PSAP. 643 E-4 � The retention and retransmission policy of the PSAP MUST be 644 able to be made available to the user, and override the 645 user's normal policy when local regulation governs such 646 retention and retransmission (but does not violate 647 requirement E-3). As in E-2 above, requiring the use of the 648 PSAP's retention and/or retransmission policy may be subject 649 to user preference; although in most jurisdictions, local 650 laws specify such policies and may not be overridden by user 651 preference. 653 Location information is considered so important during emergency 654 calls, that it is to be transmitted even when it is not considered 655 reliable, or might even be wrong. For example, some application 656 might know that the DHCP reply with location information was 657 overwritten recently (or exactly) when a VPN connection was 658 activated. This could, and likely will, provide any new location 659 information to the UA from somewhere far away from the UA (perhaps 660 the user's corporate facility). 662 E-5 - A call transfer between response centers MUST NOT be 663 considered a violation of the distribution privacy attribute 664 contained within the location object. 666 This transfer will likely be for legitimate reasons; for example, 667 the session was misrouted to the wrong PSAP, and is referred 669 [RFC3515] to the correct one. Of there might have been an overload 670 condition in which more calls were directed to a PSAP than if could 671 handle efficiently, so some of the calls were diverted to another 672 PSAP. 674 E-6 Location information MUST be transmitted, if known to the UAC, 675 in all calls to a PSAP, even in the case the location 676 information known to the UAC is not considered reliable by the 677 UAC. 679 With that in mind, it is important to distinguish the location 680 information learned locally from location information learned over a 681 VPN; which in itself is useful additional information to that PSAP 682 operator. 684 E-7 The UA must provide the actual location of the endpoint, and 685 not location which might have been erroneously given to it by, 686 e.g. a VPN tunnel DHCP server. 688 E-8 A PSAP MAY wish to SUBSCRIBE to the UAC that initiated a 689 session. If this is supported by the UAC, all NOTIFY messages 690 MUST contain the UAC's location information. 692 This is a means for the emergency response centers to maintain a 693 location the callers in distress, even if the UA were to move, even 694 if the caller does not indicate there was a move. This lets the 695 PSAP determine what it considers to be "movement", and leaves that 696 decision out of the user's. 698 E-9 It MUST be possible that any UAC supporting E-8 be informed of 699 this subscription, as this will provide a means of alert to the 700 user who does not wish this capability to remain enabled. 702 7. Location Conveyance using SIP 704 Geopriv is the IETF working group assigned to define a Location 705 Object for carrying within another protocol to convey geographic 706 location of an endpoint to another entity. This Location Object 707 will be supplied within SIP to convey location of a UA (or user of a 708 UA). The Location Object (LO) is defined in [ID-PIDF-LO]. Section 709 26 of [RFC3261] defines the security functionality SIPS for 710 transporting SIP messages with either TLS or IPsec, and S/MIME for 711 encrypting message bodies from SIP intermediaries that would 712 otherwise have access to reading the clear-text bodies. For UA-to- 713 UA location conveyance, using the PIDF-LO body satisfies the entire 714 format and message-handling requirements as stated in the baseline 715 Geopriv Requirements [RFC3693]. SIP entities that will carry an LO 716 MUST implement S/MIME for encrypting on an end-to-end basis the 717 location of a user agent, satisfying [RFC3693]'s security 718 requirements. The SIPS-URI from [RFC3261] SHOULD also be used for 719 further message protection (message integrity, authentication and 720 message confidentiality) and MUST be used when S/MIME is not used 721 (when not violating the requirements for emergency messaging 722 detailed in section 6 of this document). The entities sending and 723 receiving the LO MUST obey the privacy and security instructions in 724 the LO to be compliant with this specification. 726 Self-signed certificates SHOULD NOT be used for protecting LI, as 727 the sender does not have a secure identity of the recipient. 729 Several LOs MAY be included in a body. If the message length 730 exceeds the maximum message length of a single packet, session mode 731 is to be used. 733 Several SIP Methods are capable (and applicable) to carry the LO 734 message body. The Methods are divided into two groups, one for 735 those applicable for UA-to-UA location conveyance, and the other 736 group for UA-to-Proxy Location conveyance for routing the message. 738 The list of applicable Methods for UA-to-UA location conveyance is: 740 INVITE, 741 OPTIONS, 742 UPDATE, 743 MESSAGE, 744 SUBSCRIBE/NOTIFY, and 745 PUBLISH. 747 The list of applicable Methods for UA-to-Proxy location conveyance 748 is: 750 INVITE, 751 UPDATE, and 752 MESSAGE 754 While the authors do not yet see a reason to have location conveyed 755 in the ACK, PRACK, BYE, REFER and CANCEL Methods, we do not see a 756 reason to prevent carrying a LO within these Method Requests as long 757 as the SIP message meets the requirements stated within this 758 document. 760 A 200 OK to an INVITE MAY carry the UAS's LO back to the UAC that 761 provided its location in the INVITE, but this is not something 762 that can be required due to the timing of the INVITE to 200 OK 763 messages, with potential local/user policy requiring the called user 764 to get involved in determining if the caller is someone they wish to 765 give location to (and at what precision). 767 For UA-to-Proxy location conveyance, there are two cases: one in 768 which all proxies in the path from the UA to the proxy that requires 769 location can be trusted with the LI, and one in which intermediate 770 proxies may not be trusted. The former may be implemented with 771 "hop-by-hop" security as specified in [RFC3261] using sips: (i.e. 773 TLS security). In particular, emergency call routing requires 774 routing proxies to know the location of the UAC, and sips: 775 protection is appropriate. The latter case is under study by the 776 SIPPING working group under the subject "End to Middle" security 777 [ID-End-Mid-Sec]. 779 Regardless which scenario (UA-to-UA or UA-to-Proxy) is used to 780 convey location, SIP entities MUST adhere to the rules of [RFC3693], 781 specifically the retention and distribution (privacy) attributes of 782 a UA's location. When Alice is deciding how to transmit her 783 location, she should be keenly aware of the parameters in which she 784 wants her location to be stored and distributed by who she transmits 785 her location to. However, once she sends that location information 786 to Bob, he MUST also now obey Alice's wishes regarding these privacy 787 attributes if he is deciding to inform another party about Alice. 788 This is a fundamental principle of the Geopriv Working Group, i.e. 789 "PRIVACY". 791 7.1 Indicating Support for Location by the UAC 793 User agent clients who supports this specification will indicate 794 that support in two ways, by including two headers in all messages 795 conveying location of any kind specified here: a new "Location" 796 header, and the Supported Header indicating "location" as the value 797 of the header. SIP Requests lacking this combination will indicate 798 to SIP intermediaries that determine there is a problem with a SIP 799 Request that should contain location information whether any of 800 their responses will have a chance at successful understanding. In 801 other words, does the UAC have location clue, or not? If not, 802 because the SIP Request from that UAC didn't include these headers, 803 the intermediary will not rely on the UAC to correct the problem, 804 and will do what it can to fix the problem without the UAC. More on 805 this in section 8 of this document. 807 Location inclusion within a SIP Request will be by-value or by- 808 reference. By-value is the case in which the location information 809 of the UAC is included or contained within the SIP message itself. 810 By-reference is the case in which the location of the UAC is in a 811 database (record or document) somewhere else, but the UAC knows the 812 URI to that record/document and includes only that URI in the SIP 813 Request, in the location header. 815 A UAC that conforms with this specification will include within this 816 INVITE message an indication that it understands what "location" 817 means, that it is necessary to convey location in this INVITE 818 message, and understands any location based rejection responses from 819 the SIP intermediary. There are two new 4XX level Responses defined 820 later in this document. This indication is a new "Location" header 821 with the following syntax: 823 Location = "Location" HCOLON Location-value *(COMMA 824 Location-value) 825 location-value = (addr-spec / option-tag / token) 826 addr-spec = cid-url / absoluteURI 827 option-tag = string 828 token = token / quoted-string 829 cid-url = 830 absoluteURI = 832 IANA Registered Option-tags are: loc-body, civic-loc, geo-loc, 833 convey-uac, convey-uas, unknown 835 - "loc-body" identifies location is present in the message body of 836 this message, but gives no indication which format it is in, or 837 even if it is visible to the SIP element viewing the message. 839 - "civic-loc" identifies the format of location included, or 840 desired. 842 - "geo-loc" identifies the format of location included, or desired. 844 - "convey-uac" identifies in a message for the receiver of this 845 message to forward the sender's location information to another 846 UA. 848 This convey-uac is telling the UAS of this transaction to convey the 849 location of the UAC of this transaction to another UA. This is most 850 clearly applicable in a REFER transaction (see section 8.3). 852 - "convey-uas" identifies to a UAS within a transaction to convey 853 its location to the UAC of that transaction, or to a third party 854 UA (see section 8.3 for this latter example involving REFER). 856 This convey-uas indication is both a request for a UAS to respond to 857 the UAC with the UAS's location (see section 8.1) and a request for 858 a UA to send location information somewhere else (see section 8.3). 860 Civic-loc and geo-loc are defined as being "desired" (not known yet) 861 because each can be placed in a location header within an OPTIONS 862 Request message to learn the UAC's location. See section 8.2 for 863 the details of this. 865 - "unknown" indicates the UAC understands the concept of location, 866 but does not have knowledge of where it is to include in the 867 message. 869 Unknown is a case in which the UAC is asking for help of any 870 intermediary to populate a location header with a by-reference URI, 871 or to return a 425 (Retry Location Body) response that includes a 872 PIDF-LO message body that describes the location for that UAC to be 873 used at a later time. The intermediary that responds to this query 874 could become the UAS target for future OPTIONS requests. 876 The following table extends the values in Table 2/3 of RFC3261 877 [RFC3261]. 879 Header field where proxy INV ACK CAN BYE REG OPT PRA 880 ---------------------------------------------------------------- 881 Location Rr amdr o - - o o o - 883 Header field where proxy SUB NOT UPD MSG REF INF PUB 884 ---------------------------------------------------------------- 885 Location Rr amdr o o o o o o o 887 The Location header MAY be added, modified, read or deleted if 888 present in a Request message listed above. Deleting a location 889 header appears detrimental for communicating a necessary piece of 890 information described throughout this document, unless this is an 891 act of hiding that information. Modifying this header, other than 892 correcting the header of some error, appears to cause more harm than 893 good, and is ill advised. Unless from the SIP Proxy/intermediary 894 generating an error response (see section 7.2), the location header 895 SHOULD NOT be modified or deleted if present in a Response. Only 896 the intermediary that is originating the header value in the 897 response SHOULD add a location header, if one is not yet present. 898 A Proxy/intermediary MAY add the location header in transit if one 899 is not present. A Proxy/intermediary MAY read the location header 900 in transit if present. 902 Here is an example INVITE that includes the proper Location and 903 Supported headers (with a reduced size multipart message body): 905 INVITE sip:bob@biloxi.example.com SIP/2.0 906 Via: SIP/2.0/TCP pc33.atlanta.example.com 907 ;branch=z9hG4bK74bf9 908 Max-Forwards: 70 909 To: Bob 910 From: Alice ;tag=9fxced76sl 911 Call-ID: 3848276298220188511@atlanta.example.com 912 Location: cid: alice123@atlanta.example.com, geo-loc 913 Supported: location 914 Accept: application/sdp, application/cpim-pidf+xml 915 CSeq: 31862 INVITE 916 Contact: 917 Content-Type: multipart/mixed; boundary=boundary1 918 Content-Length: ... 920 --boundary1 922 Content-Type: application/sdp 924 ...SDP here 925 --boundary1 927 Content-Type: application/cpim-pidf+xml 928 Content-ID: alice123@atlanta.example.com 930 ...PIDF-LO with geolocation coordinates here 932 --boundary1-- 934 The location header from the above INVITE: 936 Location: cid:alice123@atlanta.example.com, geo-loc 938 indicates the Content-ID location [RFC2392] within the multipart 939 message body of were location information is. The geo-loc option- 940 tag indicates the location format within the PIDF-LO message body. 941 If both geo-loc and civic-loc formats were present in the PIDF-LO, 942 the UAC SHOULD include both option-tags if it includes either. The 943 UAC MAY NOT include either option-tag indicating the format of 944 location within the message body. 946 If the Location header were this instead: 948 Location: , geo-loc 950 this would indicate location by-reference was included in this 951 message, and in the geo-loc format for whoever fetches it. 953 More than one location by-value message body-part MAY be included in 954 the same SIP message. 956 7.2 Location Rejection Responses 958 Two new 4XX Response messages are created here: 960 - '424 Bad Location Information' - indicates the location in the SIP 961 Request message was bad. 963 - '425 Retry Location Body' - indicates to the UAC that location in 964 the SIP Request message was bad and this response has a new PIDF- 965 LO location-by-value to be stored in the UAC for future use. 967 7.2.1 The 424 "Bad Location Information" Error Code 969 In the case that a UAS or SIP intermediary detects an error 970 in a Request message specific to the location information supplied 971 by-value or by-reference, a new 4XX level error is called for to 972 indicate this is the problem with the message. This document 973 creates the new error code: 975 424 (Bad Location Information) 977 The 424 Bad Location Information Response code is a rejection of the 978 location contents, whether by-value or by-reference of the original 979 SIP Request. The server function of the recipient (UAS or 980 intermediary) had deemed this location by-reference or location by- 981 value to be bad. No further action by the UAC is expected. The UAC 982 can use whatever means it knows to verify/refresh its location 983 information before attempting the Request again. 985 This new error code will be IANA registered. 987 7.2.2 The 425 "Retry Location Body" Error Code 989 In the case that a UAS or SIP intermediary detects an error 990 in a Request message specific to the location information supplied 991 by-value or by-reference within that message, and both has the 992 location by-value of that UAC stored locally and wants to transmit 993 this value to the UAC, a new 4XX level error need is called for to 994 indicate this. This document creates the new error code: 996 425 (Retry Location Body) 998 The 425 Retry Location Body Response code is a rejection of the by- 999 value or by-reference location contained in the original SIP 1000 Request. The 425 Response will contain a application/cpim-pidf+xml 1001 encoded message body to be stored in the UAC for future use. This 1002 will typically be incorporated into the subsequent SIP Request from 1003 the UAC that received the 425 Response to the previous message 1004 attempt. 1006 The UAC SHOULD include this PIDF-LO message body in the subsequent 1007 Request message towards that same intermediary - as it felt strong 1008 enough to reject the last message that had bad location information 1009 to send the UAC new location information. 1011 This new error code will be IANA registered. 1013 An example flow of this scenario will be included in section 9 of 1014 this document. 1016 7.3 Example PIDF-LO in Geo Format 1018 This subsection will show a sample of what just the PIDF-LO can look 1019 like, as defined in [ID-PIDF-LO]. Having this here will first offer 1020 a look at a location by-value message body, and secondly, give the 1021 authors the ability to show how large this is to persuade readers 1022 that this doesn't have to be shown in every example of this 1023 document. Full example message flows will be in the appendixes of 1024 this document. 1026 Whether this PIDF-LO message body is S/MIME encrypted in the SIP 1027 message or not, the PIDF-LO stays exactly the same. There is no 1028 change to its format, text or characteristics. Whether TLS or IPsec 1029 is used to encrypt this overall SIP message or not, the PIDF-LO 1030 stays exactly the same. There is no change to its format, text or 1031 characteristics. The examples in section 7.3 (Geo format) taken 1032 from [RFC3825] and 7.4 (Civic format) taken from [ID-CIVIC] are for 1033 the exact same position on the earth. The civic formatted PIDF-LO 1034 is a little larger (i.e. more lines), but this is not substantial. 1035 The differences between the two formats is within the are of the examples. Other than this portion of each PIDF-LO, 1037 the rest the same for both location formats. 1039 1040 1045 1046 2005-08-01T10:00:00Z 1047 1048 1049 1050 1051 1052 33.001111N 1053 96.68142W 1054 1055 1056 1057 dhcp 1058 www.cisco.com 1059 1060 no 1061 2005-08-05T01:00:00Z 1063 1064 1065 1066 1067 1069 7.4 Example PIDF-LO in Civic Format 1071 This subsection will show a sample of what just the PIDF-LO can look 1072 like, as defined in [ID-PIDF-LO]. Having this here will first offer 1073 a look at a location by-value message body, and secondly, give the 1074 authors the ability to show how large this is to persuade readers 1075 that this doesn't have to be shown in every example of this 1076 document. Full example message flows will be in the appendixes of 1077 this document. 1079 Whether this PIDF-LO message body is S/MIME encrypted in the SIP 1080 message or not, the PIDF-LO stays exactly the same. There is no 1081 change to its format, text or characteristics. Whether TLS or IPsec 1082 is used to encrypt this overall SIP message or not, the PIDF-LO 1083 stays exactly the same. There is no change to its format, text or 1084 characteristics. The examples in section 7.3 (Geo format) taken 1085 from [RFC3825] and 7.4 (Civic format) taken from [ID-CIVIC] are for 1086 the exact same position on the earth. The civic formatted PIDF-LO 1087 is a little larger (i.e. more lines), but this is not substantial. 1088 The differences between the two formats is within the are of the examples. Other than this portion of each PIDF-LO, 1090 the rest the same for both location formats. 1092 1093 1098 1099 2005-08-01T10:00:00Z 1100 1101 1102 1103 1104 US 1105 Texas 1106 Colleyville 1107 3913 1108 Treemont 1109 Circle 1110 76034 1111 Polk Place 1112 1 1113 1114 1115 dhcp 1116 www.cisco.com 1117 1118 no 1119 2005-08-05T01:00:00Z 1121 1122 1123 1124 1125 1127 8. User Agent-to-User Agent Location Conveyance 1129 The offered solution here for the User-to-User location conveyance 1130 between UAs is used with the INVITE, OPTIONS, UPDATE, MESSAGE, 1131 SUB/NOT and PUBLISH Methods in the following subsections. 1133 All complete message flows in this document will be with well-formed 1134 SIP messages. That said, there will be a few individual example 1135 messages containing only the key headers to convey the point being 1136 made that do not include all the requisite SIP headers. As you will 1137 see in the following section (8.1), a well-formed SIP message 1138 containing a PIDF-LO is quite large (at least 59 lines of text), and 1139 will likely be overload to most readers if written for every example 1140 here (given how many examples there are). All well formed SIP 1141 message flows are in separate appendixes at the end of this document 1142 for brevity here. 1144 8.1 UA-to-UA using INVITE Method 1146 Below is a common SIP session set-up sequence between two user 1147 agents. In this example, Alice will provide Bob with her geographic 1148 location in the INVITE message. 1150 UA Alice UA Bob 1152 | INVITE [M1] | 1153 |---------------------------------------->| 1154 | 200 OK [M2] | 1155 |<----------------------------------------| 1156 | ACK [M3] | 1157 |---------------------------------------->| 1158 | RTP | 1159 |<=======================================>| 1160 | | 1162 Figure 1. UA-UA with Location in INVITE 1164 User agent Alice invites user agent Bob to a session [M1 of Figure 1165 1]. 1167 INVITE sips:bob@biloxi.example.com SIP/2.0 1168 To: Bob 1169 From: Alice ;tag=1928301774 1170 Supported: Location 1171 Location: loc-body, geo-loc 1172 Content-Type: application/pkcs7-mime; 1173 smime-type=enveloped-data; name=smime.p7m 1175 - Within this INVITE is a multipart body indication that it is 1176 S/MIME encrypted [according to the rules of RFC3261] by Alice for 1177 Bob. One body part contains the SDP offered by Alice to Bob. 1179 Alice's location (here coordinate based) is the other body part 1180 contained in this INVITE. 1182 Within the message body is this: 1184 Content-Type: multipart/mixed; boundary=boundary1 1186 --boundary1 1188 Content-Type: application/sdp 1189 v=0 1190 ... 1192 --boundary1 1194 Content-type: application/cpim-pidf+xml 1195 PIDF-LO 1197 --boundary1-- 1199 - Bob responses with a 200 OK [M2] (choosing a codec as specified by 1200 the Offer/Answer Model [RFC3264]). Bob can include his location 1201 in the 200 OK response, but this shouldn't be expected to due to 1202 user timing. If Bob wants to provide his location to Alice after 1203 the 200 OK, but before a BYE, the UPDATE Method [RFC3311] should 1204 be used. 1206 Bob also has Alice's location once he decrypts the S/MIME (in 1207 conjunction with decrypting if for the SDP message body). 1209 In this message, Alice decided to include the Supported and 1210 Location headers in the SIP headers even though SIP intermediaries 1211 would not be able to view the information. This SHOULD be 1212 configurable, based on local policy for revealing such information 1213 hints. 1215 If Alice wanted to know Bob's location, she could have included in 1216 the existing Location header an option-tag of "convey-uas". This is 1217 the indication to the UAS within this transaction, in this case Bob, 1218 to return his location in the 200 OK if he chooses too. This 1219 request MAY prompt Bob, the user, of the request, and wait for him 1220 to indicate to his UA whether he would want his location included in 1221 the 200 OK. 1223 - Alice's UA replies with an ACK and the session is set up. 1225 Figure 1. does not include any Proxies because in it assumed they 1226 would not affect the session set-up with respect to whether or not 1227 Alice's location is in a message body part, and Proxies don't react 1228 to S/MIME bodies, making their inclusion more or less moot and more 1229 complex than necessary. 1231 The most relevant message in Figure 1 having to do with location is 1232 (obviously) the message with the location object in it [M1]. So to 1233 cut down on length of this document, only the INVITE message in this 1234 example will be shown. Section 8.1.1 will give an example of this 1235 well formed INVITE message using a Coordinate location format. 1236 Section 8.1.2 will give an example of this well formed INVITE 1237 message using the civic location format. 1239 8.1.1 UA-to-UA INVITE Request with Geo Location Using S/MIME 1241 Below is a well-formed SIP INVITE Method message to the example in 1242 Figure 1 in section 8.1. 1244 [Message 1 in Figure 1] 1246 INVITE sips:bob@biloxi.example.com SIP/2.0 1247 Via: SIP/2.0/TLS pc33.atlanta.example.com 1248 ;branch=z9hG4bK776asdhds 1249 Max-Forwards: 70 1250 To: Bob 1251 From: Alice ;tag=1928301774 1252 Call-ID: a84b4c76e66710@pc33.atlanta.example.com 1253 CSeq: 314159 INVITE 1254 Contact: 1255 Content-Type: application/pkcs7-mime; 1256 smime-type=enveloped-data; name=smime.p7m 1257 Content-Disposition: attachment; 1258 filename=smime.p7m handling=required 1260 Content-Type: multipart/mixed; boundary=boundary1 1262 --boundary1 1264 Content-Type: application/sdp 1265 v=0 1266 o=alice 2890844526 2890844526 IN IP4 atlanta.example.com 1267 c=IN IP4 10.1.3.33 1268 t=0 0 1269 m=audio 49172 RTP/AVP 0 4 18 1270 a=rtpmap:0 PCMU/8000 1272 --boundary1 1274 Content-type: application/cpim-pidf+xml 1275 [Alice's Geo PIDF-LO goes here] 1277 --boundary1-- 1279 8.1.1.1 UA-to-UA INVITE with Coordinate Location Not Using S/MIME 1280 Below is a well-formed SIP INVITE Method message to the example in 1281 Figure 1 in section 8.1. This message is here to show that although 1282 the requirements are mandatory to implement proper security, it is 1283 not mandatory to use. This message below is show for those cases 1284 where hop-by-hop security is deployed. 1286 [Message 1 in Figure 1] 1288 INVITE sip:bob@biloxi.example.com SIP/2.0 1289 Via: SIP/2.0/TCP pc33.atlanta.example.com 1290 ;branch=z9hG4bK74bf9 1291 Max-Forwards: 70 1292 From: Alice ;tag=9fxced76sl 1293 To: Bob 1294 Call-ID: 3848276298220188511@atlanta.example.com 1295 CSeq: 31862 INVITE 1296 Contact: 1297 Content-Type: multipart/mixed; boundary=boundary1 1298 Content-Length: ... 1300 --boundary1 1302 Content-Type: application/sdp 1303 v=0 1304 o=alice 2890844526 2890844526 IN IP4 atlanta.example.com 1305 c=IN IP4 10.1.3.33 1306 t=0 0 1307 m=audio 49172 RTP/AVP 0 4 18 1308 a=rtpmap:0 PCMU/8000 1310 --broundary1 1312 Content-type: application/cpim-pidf+xml 1313 [Alice's Geo PIDF-LO goes here] 1315 --boundary1-- 1317 8.1.2 UA-to-UA INVITE with Civic Location Using S/MIME 1319 Below is a well-formed SIP INVITE Method message to the example in 1320 Figure 1 in section 8.1 using the civic location format. 1322 [Message 1 in Figure 1] 1324 INVITE sips:bob@biloxi.example.com SIP/2.0 1325 Via: SIP/2.0/TLS pc33.atlanta.example.com 1326 ;branch=z9hG4bK776asdhds 1327 Max-Forwards: 70 1328 To: Bob 1329 From: Alice ;tag=1928301774 1330 Call-ID: a84b4c76e66710@pc33.atlanta.example.com 1331 CSeq: 314159 INVITE 1332 Contact: 1333 Content-Type: application/pkcs7-mime; 1334 smime-type=enveloped-data; name=smime.p7m 1335 Content-Disposition: attachment; 1336 filename=smime.p7m handling=required 1338 Content-Type: multipart/mixed; boundary=boundary1 1340 --boundary1 1342 Content-Type: application/sdp 1343 v=0 1344 o=alice 2890844526 2890844526 IN IP4 atlanta.example.com 1345 c=IN IP4 10.1.3.33 1346 t=0 0 1347 m=audio 49172 RTP/AVP 0 4 18 1348 a=rtpmap:0 PCMU/8000 1350 --boundary1 1352 Content-type: application/cpim-pidf+xml 1353 [Alice's Civic PIDF-LO goes here] 1355 --boundary1-- 1357 8.1.2.1 UA-to-UA INVITE with Civic Location Not Using S/MIME 1359 Below is a well-formed SIP INVITE Method message to the example in 1360 Figure 1 in section 8.1. This message is here to show that although 1361 the requirements are mandatory to implement proper security, it is 1362 not mandatory to use. This message below is show for those cases 1363 where the sending user does not wish to use security mechanisms in 1364 transmitting their coordinate location. 1366 [Message 1 in Figure 1] 1368 INVITE sip:bob@biloxi.example.com SIP/2.0 1369 Via: SIP/2.0/TCP pc33.atlanta.example.com 1370 ;branch=z9hG4bK74bf9 1371 Max-Forwards: 70 1372 From: Alice ;tag=9fxced76sl 1373 To: Bob 1374 Call-ID: 3848276298220188511@atlanta.example.com 1375 CSeq: 31862 INVITE 1376 Contact: 1377 Content-Type: multipart/mixed; boundary=boundary1 1378 Content-Length: ... 1380 --boundary1 1382 Content-Type: application/sdp 1383 v=0 1384 o=alice 2890844526 2890844526 IN IP4 atlanta.example.com 1385 c=IN IP4 10.1.3.33 1386 t=0 0 1387 m=audio 49172 RTP/AVP 0 4 18 1388 a=rtpmap:0 PCMU/8000 1390 --broundary1 1392 Content-type: application/cpim-pidf+xml 1393 [Alice's Civic PIDF-LO goes here] 1395 --boundary1-- 1397 8.1.3 UA-to-UA Location Conveyance Involving 3 Users 1399 As stated in [RFC3693], the distribution indication within the PIDF- 1400 LO provides the information regarding if a learned PIDF-LO of 1401 another UA can be given out or not. The distribution element within 1402 the PIDF-LO looks like this: 1404 no 1406 The values within this element are either "yes" or "no". 1408 The element within the PIDF-LO indicating how long this location 1409 information is to be considered good/reliable for is the location 1410 expiration element, which looks like this: 1412 2005-08-05T01:00:00Z 1414 So, if Bob's location, which was transmitted to Alice, has not 1415 reached the expiration time, and Bob set his distribution indication 1416 to "can redistribute", then when Bob refers Alice to call Carol, 1417 Alice can include both hers and Bob's LOs in that new INVITE (from 1418 Alice to Carol). This will tell Carol where both Alice and Bob are. 1419 Bob should be conscious of this capability when setting his 1420 distribution indication with any location conveyance transmission. 1422 Consider the following example message flow [Figure 1a] to show a 1423 3-way communication of location, coupled with how a UA can include 1424 someone else's location. 1426 UA Alice Bob Carol 1428 | INVITE [M1] | | 1429 |---------------------------->| | 1430 | 200 OK [M2] | | 1431 |<----------------------------| | 1432 | ACK [M3] | | 1433 |---------------------------->| | 1434 | RTP | | 1435 |<===========================>| | 1436 | reINVITE (hold) [M4] | | 1437 |<----------------------------| | 1438 | 200 OK [M5] | | 1439 |---------------------------->| | 1440 | REFER (Refer-to:Carol) [M6] | | 1441 |<----------------------------| | 1442 | NOTIFY [M7] | | 1443 |---------------------------->| | 1444 | 200 OK [M8] | | 1445 |<----------------------------| | 1446 | INVITE [M9] | 1447 |------------------------------------------>| 1448 | 200 OK [M10] | 1449 |------------------------------------------>| 1450 | RTP | 1451 |<=========================================>| 1452 | NOTIFY [M11] | | 1453 |---------------------------->| | 1454 | 200 OK [M12] | | 1455 |<----------------------------| | 1456 | BYE [M13] | | 1457 |<----------------------------| | 1458 | 200 OK [M14] | | 1459 |---------------------------->| | 1460 | | 1462 Figure 1a. UA-to-UA with Location in REFER 1464 M1 - Alice presents her location in the INVITE to Bob; 1466 INVITE sips:bob@biloxi.example.com SIP/2.0 1467 To: Bob 1468 From: Alice 1469 Supported: location 1470 Location: geo-loc 1471 Content-Type: multipart/mixed; boundary=boundary1 1473 --boundary1 1475 Content-Type: application/sdp 1476 v=0 1477 ... 1479 --boundary1 1481 Content-type: application/cpim-pidf+xml 1482 [Alice's geo formatted PIDF-LO goes here] 1484 --boundary1-- 1486 M2 - Bob 200 OKs this INVITE and includes his location back to Alice 1487 (with his distribution indication set to "yes"). 1489 If Alice included a location header with a "convey-uas" option-tag: 1491 INVITE sips:bob@biloxi.example.com SIP/2.0 1492 Location: convey-uas 1494 Bob SHOULD feel compelled to reply with his location to Alice. If 1495 Bob doesn't understand this request, Bob returns an Unsupported 1496 header with "location" if his UA doesn't understand location, or 1497 just "convey-uas" if his UA does understand location but doesn't 1498 know his location, or cannot process the request in time for the 200 1499 OK return. 1501 M6 - Bob then directs Alice to contact Carol using a REFER Request 1502 (RFC3515]. 1504 The REFER is used in this message sequence, but it does not carry 1505 anyone's location within the REFER message. UAs SHOULD be prepared 1506 to receive a PIDF-LO message body in a REFER Method Request, 1507 although this doesn't seem likely. Nothing here prevents that from 1508 occurring. If Bob didn't return his location in the 200 OK, but 1509 still wants to convey his location to Alice to send to Carol, he can 1510 include the PIDF-LO in the REFER. Bob can include the following 1511 header in the REFER to tell Alice to tell Carol both of their 1512 locations: 1514 REFER sips:alice@atlanta.example.com SIP/2.0 1515 Location: convey-uac, convey-uas 1517 The [M11] NOTIFY message from Alice to Bob MAY confirm to Bob that 1518 Alice did indeed convey both UA's locations. 1520 If Alice accepted the transaction request of the REFER in a 202 1521 Accepted message, but didn't include her location in the subsequent 1522 INVITE to Carol, her 202 Accepted message would have this header in 1523 it: 1525 [M7] 1526 SIP/2.0 202 Accepted 1527 To: Alice 1528 From: Bob 1529 Unsupported: convey-uac 1531 This indicates to Bob his request was partially fulfilled. Bob 1532 knows his location was conveyed to Carol and that his REFER Request 1533 was accepted, but Alice chose not to send Carol her location 1534 information. 1536 Regardless of Bob's request in the REFER, if he set his retention 1537 indication to "no", Alice MUST NOT forward Bob's location to Carol, 1538 even if he asked her to. This document currently doesn't have a 1539 granular enough indication from Alice to Bob to tell Bob this piece 1540 of information. 1542 8.2 OPTIONS Method and Location 1544 The OPTIONS Method can be used by a UAC to learn its location from a 1545 SIP intermediary that may know this information, or to request the 1546 location of a UAS. A combination of the location header option-tags 1547 in an OPTIONS query can achieve this. 1549 8.2.1 OPTIONS Request to Learn UAC's Location 1551 If Alice knows which server knows her location, perhaps because her 1552 UA was either configured with this server manually or through 1553 registration to the network, she can send an OPTIONS query to it to 1554 learn her location. Take the following message flow as an example: 1556 UA Alice Server1 1558 | OPTIONS [M1] | 1559 |---------------------------------------->| 1560 | 200 OK [M2] | 1561 |<----------------------------------------| 1563 Figure 2a. OPTIONS Request for Location 1565 A non-well-formed message example of how an OPTIONS Method Request 1566 could be used to query a server for the UAC's location might be: 1568 [M1 of Figure 2a] 1569 OPTIONS sips:server1@atlanta.example.com SIP/2.0 1570 To: server1 1571 From: Alice 1572 Proxy-Require: location 1573 Require: location 1574 Location: unknown, geo-loc 1576 Including both the "unknown" and "geo-loc" option-tags in the 1577 Location header indicates the UAC wants to learn its location in the 1578 geo format only. If the Location header were: 1580 OPTIONS sips:server1@atlanta.example.com SIP/2.0 1581 To: server1 1582 From: Alice 1583 Proxy-Require: location 1584 Require: location 1585 Location: unknown, geo-loc, civic 1587 the UAC is asking for both formats to be in the reply. 1589 The key to this request is the "unknown" option-tag. This, in an 1590 OPTIONS Request, if telling the server the UAC doesn't know its 1591 location, and to include the UAC's location in the 200 OK Response. 1592 The presence or lack of presence of other option-tags indicate to 1593 the server how its response will be formed. If no other option-tags 1594 are present in the Location header of this OPTIONS Request, the 1595 server is free to choose whatever format it wishes in the reply. 1597 In the above partial OPTIONS Request, there is a Proxy-Require 1598 header (if the intermediary is a Proxy) and a Require header (if the 1599 intermediary is an instance of a B2BUA). If either apply to the 1600 responding UAS in this transaction, and the location header included 1601 an option-tag the UAS cannot answer, perhaps because it doesn't have 1602 the UAC's civic location format, the 200 OK to this Request will 1603 include what location format(s) is has, and indicates it does not 1604 have the remainder of the request with the Unsupported header 1605 indicating which formats were requested, but not available. An 1606 example of this is the following partial SIP message; 1608 [M2 in Figure 2a] 1609 SIP/2.0 200 OK 1610 To: server1 1611 From: Alice 1612 Unsupported: civic-loc 1613 Content-type: application/cpim-pidf+xml 1615 [Alice's geo formatted PIDF-LO goes here] 1617 If location is to be returned as a by-reference location header 1618 value, a subset of the 200 OK could look like this: 1620 [M2 of Figure 2a] 1621 SIP/2.0 200 OK 1622 To: server1 1623 From: Alice 1624 Location: 1626 The above 200 OK example MAY include an additional option-tag 1627 indicating the format or the location at that by-reference URI. 1629 An OPTIONS Request for the location of the UAC MAY be 401 1630 (Unauthorized) or 407 (Proxy Authentication Required) challenged. 1632 An OPTIONS Request can be redirected to a server that knows the 1633 UAC's location. 1635 A 424 (Bad Location) is the proper indication if the queried server 1636 has no knowledge of the UAC's location. An Unsupported header MUST 1637 be in this 424 Response indicating "location" was not supported. 1639 [alternate M2 in Figure 2b] 1640 SIP/2.0 424 (Bad Location Information) 1641 To: server1 1642 From: Alice 1643 Unsupported: location 1645 8.2.2 OPTIONS Request to Learn UAS's Location 1647 Below is Figure 2b, which shows the OPTIONS Request being used to 1648 query another UA for its location. In this case, it is the UA for 1649 Bob. 1651 UA Alice Bob 1653 | OPTIONS [M1] | 1654 |---------------------------------------->| 1655 | 200 OK [M2] | 1656 |<----------------------------------------| 1658 Figure 2b. OPTIONS Request for Location 1660 Here is a non-well-formed example of the OPTIONS Request from Alice 1661 to Bob: 1663 [M1 of Figure 2b] 1664 OPTIONS sips:bob@biloxi.example.com SIP/2.0 1665 To: Bob 1666 From: Alice 1667 Require: location 1668 Location: geo-loc 1670 In M1 of Figure 2b, Alice queries Bob for his location, and 1671 specifically in his geo format. She has included a Require header 1672 to compel Bob to answer, unless he wishes to reject that inquiry 1673 even if he knows his location. From M1, Bob can do one of the 1674 following: 1676 1) 200 (OK) this with his geo PIDF-LO 1678 2) 488 (Not Acceptable Here), with no further information 1680 3) 488 (Not Acceptable Here), with a Unsupported Header indicating 1681 Bob does not know or understand his geo format, with no further 1682 Information 1684 4) 488 (Not Acceptable Here), with a Unsupported Header indicating 1685 Bob does not know or understand his geo format, but include a 1686 location header indicating he does support the civic-loc format 1688 If Alice did not include a Require header (location), and if Bob 1689 sends option#4 above, Alice can retransmit the OPTIONS Request 1690 indicating the civic format is fine to respond with. Bob SHOULD NOT 1691 send a format not requested unless Alice included a Require header 1692 (with Location) and Bob could not provide location in that format, 1693 but could in another format. 1695 Bob's option#1 200 OK would look like this (non-well-formed) 1696 message: 1698 [M2 in Figure 2b] 1699 SIP/2.0 200 OK 1700 To: Bob 1701 From: Alice 1702 Content-type: application/cpim-pidf+xml 1704 [Bob's geo formatted PIDF-LO goes here] 1706 Bob's option#4 488 (Not Acceptable Here) would look like this (non- 1707 well-formed) message if Bob had his civic location and did not have 1708 his geo location: 1710 [alternate M2 in Figure 2b] 1711 SIP/2.0 488 Not Acceptable Here 1712 To: Bob 1713 From: Alice 1714 Unsupported: geo-loc 1715 Content-type: application/cpim-pidf+xml 1717 [Bob's civic formatted PIDF-LO goes here] 1719 The 424 (Bad Location Information) and 425 (Retry Location Body) 1720 MUST NOT be used in response to an OPTIONS Request. This is because 1721 both of these response codes are for the react to inclusion of 1722 location information in the Request. With OPTIONS, Alice MUST NOT 1723 include her location. Another SIP Method is used for that purpose 1724 (MESSAGE, PUBLISH). 1726 8.3 UA-to-UA Using MESSAGE Method 1728 Anytime a user transmits location information outside a dialog to 1729 another user, the MESSAGE Method is to be used. The logic here is 1730 as follows: 1732 - UPDATE isn't appropriate because it is for the updating of 1733 session capabilities and parameters of a dialog (after the 1734 INVITE included location information). 1736 - reINVITE isn't appropriate because it is only used (or only 1737 supposed to be used) for changing the parameters of an existing 1738 dialog, and one might not exist in all cases of location 1739 conveyance. 1741 This leaves MESSAGE as the only viable Request Method for location 1742 conveyance outside of a dialog between two users (Alice and Bob in 1743 this case). The following is an example of this communication. 1745 To comply with privacy concerns raised in [RFC3693] and [ID-PIDF- 1746 LO], a MESSAGE Method Request including a location message body 1747 SHOULD S/MIME encrypt the message body (part) under the rules 1748 outlined in [RFC3261]. This is not generally possible if the 1749 location is conveyed by-reference in a Location header. 1750 Implementers and end-users should be aware of this shortcoming of 1751 this means for location conveyance. 1753 UA Alice UA Bob 1755 | MESSAGE [M1] | 1756 |---------------------------------------->| 1757 | 200 OK [M2] | 1758 |<----------------------------------------| 1759 | | 1761 Figure 3. UA-UA with Location in MESSAGE 1763 Below is a sample, non-well-formed MESSAGE Method message from Alice 1764 to Bob conveying her geo location: 1766 [M1 of Figure 3] 1767 OPTIONS sips:bob@biloxi.example.com SIP/2.0 1768 To: Bob 1769 From: Alice 1770 Supported: location 1771 Location: geo-loc 1772 Content-Type: multipart/mixed; boundary=boundary1 1774 --boundary1 1776 Content-Type: text/plain 1777 Here's my location, Bob? 1779 --broundary1 1781 Content-Type: application/cpim-pidf+xml 1782 Content-Disposition: render 1784 [Alice's geo format PIDF-LO goes here] 1786 --broundary1-- 1788 The Content-type of M1 here is "multipart/mixed" to have a text 1789 message incorporated into the message. Within the PIDF-LO message 1790 body, there is a Content-Disposition of "render" to display this 1791 location information to Bob when his UA receives it. The cautions 1792 about whether or not Bob actually reads this message are outlined in 1793 [RFC3428]. 1795 The 200 OK to M1 of Figure 3 is a simple OK. 1797 A 424 (Bad Location Information) Response with a Unsupported header 1798 (stating Location) is the proper response if Bob's UA cannot display 1799 this information, but does understand the concept of location. 1801 [Alternative M2 of figure 3] 1802 SIP/2.0 424 Bad Location Information 1803 To: Bob 1804 From: Alice 1805 Unsupported: location 1807 If Bob's UA merely does not support that location format, the 1808 Location header would be: 1810 [Alternative M2 of figure 3] 1811 SIP/2.0 424 Bad Location Information 1812 To: Bob 1813 From: Alice 1814 Unsupported: geo-loc 1816 This alternative indicates to Alice to send another location format 1817 (civic) if she knows her location in that other format. A 1818 subsequent MESSAGE Request could supply this information to Bob. 1820 If Bob is declining the original M1 MESSAGE Request, a 488 (Not 1821 Acceptable Here) is the appropriate response. This 488 MAY include 1822 a location header indicating he does support the civic-loc format. 1824 [Alternative M2 of figure 3] 1825 SIP/2.0 488 Not Acceptable Here 1826 To: Bob 1827 From: Alice 1828 Location: civic-loc 1830 8.4 UA-to-UA Location Conveyance Using UPDATE 1832 The UPDATE Method is to be used any time location information is to 1833 be updated between UAs setting up a dialog or after the dialog has 1834 been established, no matter how long that dialog has been 1835 operational. reINVITE is out of scope here, and the MESSAGE Method 1836 is for non-dialog location conveyance between UAs only. The same 1837 security properties used in the INVITE MUST be used in the UPDATE 1838 message. 1840 There are 3 conditions UPDATE is to be used to convey location 1841 between Uas: 1843 1) During dialog establishment, but before the final 200 OK (see 1844 section 8.4.1) 1846 2) After dialog establishment, but no prior location information has 1847 been convey (see section 8.4.2), and 1849 3) After dialog establishment, when a UA has determined it has moved 1850 (see section 8.4.3) 1852 8.4.1 UPDATE Updates Location During Session Establishment 1854 Use#1 of the UPDATE Method is during dialog establishment, Alice 1855 updates Bob with her location information. This might be different 1856 location information than was in message [M1] of Figure 4a., or it 1857 could be the first time Alice conveys location to Bob. 1859 UA Alice UA Bob 1861 | INVITE [M1] | 1862 |---------------------------------------->| 1863 | UPDATE [M2] | 1864 |---------------------------------------->| 1865 | 200 OK (UPDATE) [M3] | 1866 |<----------------------------------------| 1867 | 200 OK (INVITE) [M4] | 1868 |<----------------------------------------| 1869 | ACK (UPDATE) [M5] | 1870 |---------------------------------------->| 1871 | RTP | 1872 |<=======================================>| 1873 | | 1875 Figure 4a. UA-UA with Location in UPDATE 1877 [M2 of Figure 4a] 1878 UPDATE sips:bob@biloxi.example.com SIP/2.0 1879 To: Bob 1880 From: Alice 1881 Supported: location 1882 Location: geo-loc 1883 Content-Type: multipart/mixed; boundary=boundary1 1885 --boundary1 1886 Content-Type: application/sdp 1887 v= 1888 ... 1890 --broundary1 1892 Content-Type: application/cpim-pidf+xml 1893 [Alice's geo format PIDF-LO goes here] 1895 --broundary1-- 1897 The above example has Alice also changing something within her 1898 original SDP, but this is not necessary for this update of location 1899 information. 1901 A 424 (Bad Location Information) Response with a Unsupported header 1902 (stating Location) is the proper response if Bob's UA cannot support 1903 this information, but does understand the concept of location. 1905 [Alternative M3 of figure 4a] 1906 SIP/2.0 424 Bad Location Information 1907 To: Bob 1908 From: Alice 1909 Unsupported: location 1911 If Bob's UA merely does not support that location format, the 1912 Location header would be: 1914 [Alternative M3 of figure 4a] 1915 SIP/2.0 424 Bad Location Information 1916 To: Bob 1917 From: Alice 1918 Unsupported: geo-loc 1920 This alternative indicates to Alice to send another location format 1921 (civic) if she knows her location in that other format. A 1922 subsequent UPDATE Request could supply this information to Bob. 1924 If Bob is declining the M2 UPDATE Request message, a 488 (Not 1925 Acceptable Here) is the appropriate response. This 488 MAY include 1926 a location header indicating he does support the civic-loc format. 1928 [Alternative M3 of figure 4a] 1929 SIP/2.0 488 Not Acceptable Here 1930 To: Bob 1931 From: Alice 1932 Location: civic-loc 1934 8.4.2 UPDATE Updates Location After Session Establishment 1936 Use #2 of the UPDATE Method is if a dialog *has been* set up between 1937 more than one UA, say between Alice and Bob without location 1938 conveyed in either direction, and location is now going to be sent 1939 from one of those UAs to the other. For example, if Alice invites 1940 Bob to a dialog, but does not include her location in that dialog 1941 establishment. Anytime during that dialog, Alice uses the UPDATE 1942 Method, not the INVITE Method (in a reINVITE), to update the 1943 location parameters of that dialog by sending an UPDATE message, 1944 even if it is from no location parameters to start with. 1946 Once a dialog has been established, a UAC MUST NOT use the INVITE 1947 Method to convey location. The UPDATE Method MUST be used. 1949 Consider the following example message flow in Figure 4b.: 1951 UA Alice UA Bob 1953 | INVITE [M1] | 1954 |---------------------------------------->| 1955 | 200 OK (INVITE) [M2] | 1956 |<----------------------------------------| 1957 | ACK [M3] | 1958 |<----------------------------------------| 1959 | RTP | 1960 |<=======================================>| 1961 | UPDATE [M4] | 1962 |---------------------------------------->| 1963 | 200 OK (UPDATE) [M5] | 1964 |<----------------------------------------| 1965 | | 1967 Figure 4b. UA-UA with Location in UPDATE 1969 [M4 of Figure 4b] 1970 UPDATE sips:bob@biloxi.example.com SIP/2.0 1971 To: Bob 1972 From: Alice 1973 Supported: location 1974 Location: geo-loc 1975 Content-Type: application/cpim-pidf+xml 1977 [Alice's geo format PIDF-LO goes here] 1979 A 424 (Bad Location Information) Response with a Unsupported header 1980 (stating Location) is the proper response if Bob's UA cannot support 1981 this information, but does understand the concept of location. 1983 [Alternative M5 of figure 4b] 1984 SIP/2.0 424 Bad Location Information 1985 To: Bob 1986 From: Alice 1987 Unsupported: location 1989 If Bob's UA merely does not support that location format, the 1990 Location header would be: 1992 [Alternative M5 of figure 4b] 1993 SIP/2.0 424 Bad Location Information 1994 To: Bob 1995 From: Alice 1996 Unsupported: geo-loc 1998 This alternative indicates to Alice to send another location format 1999 (civic) if she knows her location in that other format. A 2000 subsequent UPDATE Request could supply this information to Bob. 2002 If Bob is declining the M4 UPDATE Request message, a 488 (Not 2003 Acceptable Here) is the appropriate response. This 488 MAY include 2004 a location header indicating he does support the civic-loc format. 2006 [Alternative M5 of figure 4b] 2007 SIP/2.0 488 Not Acceptable Here 2008 To: Bob 2009 From: Alice 2010 Location: civic-loc 2012 NOTE: A similar use for UPDATE is within the UA-to-Proxy Location 2013 Conveyance section of this document. 2015 8.4.3 UPDATE Updates Location After a UA Moves in a Dialog 2017 Use#3 of the UPDATE Method is if one UA that already conveyed 2018 location to the other UA, has moved since the dialog was originally 2019 sent up. How a UA determines it has moved is out of scope for this 2020 document. 2022 However that "movement" trigger occurred, M4 of Figure 4c. is the 2023 result: an UPDATE Method Request indicating new location by Alice. 2025 UA Alice UA Bob 2027 | INVITE [M1] | 2028 |---------------------------------------->| 2029 | 200 OK (INVITE) [M2] | 2030 |<----------------------------------------| 2031 | ACK [M3] | 2032 |<----------------------------------------| 2033 | RTP | 2034 |<=======================================>| 2036 **Alice's UA determines it has moved, and needs to update Bob** 2038 | UPDATE [M4] | 2039 |---------------------------------------->| 2040 | 200 OK (UPDATE) [M5] | 2041 |<----------------------------------------| 2042 | | 2044 Figure 4c. UA-UA with Location in UPDATE 2046 Message M4 of Figure 4c. shows the UPDATE of Alice's location 2047 information to Bob. That message may look like this (non-well- 2048 formed SIP message): 2050 [M4 of Figure 4c] 2051 UPDATE sips:bob@biloxi.example.com SIP/2.0 2052 To: Bob 2053 From: Alice 2054 Supported: location 2055 Location: geo-loc 2056 Content-Type: application/cpim-pidf+xml 2058 [Alice's geo format PIDF-LO goes here] 2060 There currently is not an indication Alice can make conveying this 2061 PIDF-LO is new, replacement location information from a previous 2062 message (here in the M1 INVITE message). 2064 A 424 (Bad Location Information) Response with a Unsupported header 2065 (stating Location) is the proper response if Bob's UA cannot support 2066 this information, but does understand the concept of location. 2068 [Alternative M5 of figure 4c] 2069 SIP/2.0 424 Bad Location Information 2070 To: Bob 2071 From: Alice 2072 Unsupported: location 2074 If Bob's UA merely does not support that location format, the 2075 Location header would be: 2077 [Alternative M5 of figure 4c] 2078 SIP/2.0 424 Bad Location Information 2079 To: Bob 2080 From: Alice 2081 Unsupported: geo-loc 2083 This alternative indicates to Alice to send another location format 2084 (civic) if she knows her location in that other format. A 2085 subsequent UPDATE Request could supply this information to Bob. 2087 If Bob is declining the M4 UPDATE Request message, a 488 (Not 2088 Acceptable Here) is the appropriate response. This 488 MAY include 2089 a location header indicating he does support the civic-loc format. 2091 [Alternative M5 of figure 4c] 2092 SIP/2.0 488 Not Acceptable Here 2093 To: Bob 2094 From: Alice 2095 Location: civic-loc 2097 NOTE: A similar use for UPDATE is within the UA-to-Proxy Location 2098 Conveyance section of this document. 2100 8.5 UA-to-UA Location Conveyance Using PUBLISH 2102 The PUBLISH Method Request [RFC3903] is for conveying state 2103 information of a user agent to a compositor server for others to 2104 query for that information. This creates the benefit of the user 2105 agent not always being requested from all angles of the Internet. 2106 That task or chore can be left for a SIP entity build for that task, 2107 as well as one that is built for the efficient task of doing proper 2108 challenges for each user's state information. One piece of state 2109 information interesting to those involved in Presence is geophysical 2110 location. The PUBLISH Method Request message is used by a user 2111 agent to transmit location information to this compositor server for 2112 queries by others. 2114 Consider the following basic message flow in Figure 5: 2116 Compositor 2117 UA Alice Server2 2119 | PUBLISH [M1] | 2120 |---------------------------------------->| 2121 | 200 OK [M2] | 2122 |<----------------------------------------| 2124 Figure 5. OPTIONS Request for Location 2126 A non-well-formed message example of how an PUBLISH Method Request 2127 could be used to push location information to a server representing 2128 the UAC might be: 2130 [M1 of Figure 5] 2131 PUBLISH sips:server2@atlanta.example.com SIP/2.0 2132 To: server2 2133 From: Alice 2134 Accept: application/cpim-pidf+xml 2135 Location: geo-loc 2136 Expires: 21600 2137 Content-type: application/cpim-pidf+xml 2139 [Alice's geo formatted PIDF-LO goes here] 2141 The record location on this compositor server MAY become the 2142 location by-reference URI for future location conveyance by this 2143 UAC. This would have to be returned to the UAC in Location header 2144 of the 200 OK Response if the UAC is expected to use this. 2146 Otherwise, the response to the PUBLISH Request would be something 2147 like this non-well-formed 200 OK message: 2149 [M2 in Figure 5] 2150 SIP/2.0 200 OK 2151 To: server2 2152 From: Alice 2153 Location: geo-loc 2154 SIP-ETag: alice987 2155 Expires: 21600 2157 The Location header copying the option-tag from the Request SHOULD 2158 be considered the indication the compositor server understood the 2159 format and the elements within the PIDF-LO message body of the 2160 PUBLISH message. 2162 PUBLISH performs 4 functions: initial, modify, refresh, or 2163 terminate. Based on this, it can be easily concluded that a PUBLISH 2164 Request conveying the location of a UAC MAY be 401 (Unauthorized) or 2165 407 (Proxy Authentication Required) challenged. UAs MUST be 2166 prepared to be challenged when they communicate location to a 2167 compositor server. 2169 A 424 (Bad Location) is the proper indication if the compositor 2170 server has no knowledge of location capabilities. An Unsupported 2171 header MUST be in this 424 Response indicating "location" was not 2172 supported. 2174 [alternate M2 in Figure 5] 2175 SIP/2.0 424 (Bad Location Information) 2176 To: server2 2177 From: Alice 2178 Unsupported: location 2180 If a compositor server understands location, but does not prefer (or 2181 like) the location format the UAC chose to convey location in, a 488 2182 (Not Acceptable Here) would be the appropriate response. Within 2183 this message, the 488 MUST indicate which format was not preferred 2184 using the Unsupported header and a location option-tag indicating 2185 the existing format. The 488 MUST also have a Location header with 2186 the preferred option-tag format to plainly inform the UAC which 2187 location format to send in a subsequent Request. 2189 This 488 could look like this (non-well-formed) message if the 2190 server received Alice's civic location and prefers her location in 2191 the geo format 2193 [alternate M2 in Figure 5] 2194 SIP/2.0 488 Not Acceptable Here 2195 To: server2 2196 From: Alice 2197 Unsupported: civic 2198 Location: geo-loc 2199 Accept: application/cpim-pidf+xml 2201 ** The corresponding appendix has not be completed at this time.** 2203 8.6 UA-to-UA Location Conveyance Using SUBSCRIBE and NOTIFY 2205 The SUBSCRIBE Method Request [RFC3265] can be used to request the 2206 location, by-reference or by-value of another SIP entity. What is 2207 different in this method of conveying location is the answer is in 2208 the NOTIFY Method Request [RFC3265] from the original UAS, the 2209 subscribed-to entity. This has at least two advantages: 2211 1) This transaction can be used in conjunction with a Geopriv-based 2212 Target and SIMPLE-based Presentity's use of the PUBLISH Method to 2213 a Location server or Compositor. This allows a location target 2214 to publish their location to a server and have that server be the 2215 focus of AAA processes for that target's location, and not burden 2216 the target's device - other than if that target wants to real- 2217 time authorize a location request from one or more requestors. 2219 2) A UAC can subscribe to a UAS (or its server/compositor) for an 2220 ongoing location conveyance; meaning, this can be how a location 2221 requestor (or seeker) establishes a connection to a knowledgeable 2222 source of the UAC's/Presentity's location for more than a one 2223 time request. Consider this to be a tracking capability. 2225 This tracking capability MUST be authorized by the rulemaker of the 2226 UAC/Target/Presentity, but there are some uses in which this is 2227 valuable; consider the 911/112 caller. 2229 When a UAC calls a 911/112-type of local emergency service for help, 2230 regardless of how this occurs within SIP, one of the key functions 2231 of this call is to convey the location of the caller for a PSAP 2232 operator to dispatch first responders. It is very important that 2233 the PSAP operator knows where the caller is to do this. If the 2234 person who called for help is mobile or roaming, depending on how 2235 each is defined, the fact that the caller is not tied to a cable 2236 means they can move to a new location even during the emergency 2237 call. The UPDATE Method is used to update a UAS if the UAC moves, 2238 but this is not necessary reliable, and currently cannot be required 2239 within existing SIP capabilities. This is where the SUB/NOT Request 2240 Methods come in. 2242 Once a caller (UAC) calls a PSAP (UAS) for help (regardless of the 2243 routing issues discussed in section 9 of this document), the PSAP 2244 operator may want to SUBSCRIBE to the caller's UAC to learn where it 2245 is. This can be considered a location refresh. The US Cellular 2246 industry calls this "reachback", and it is part of Wireless Phase II 2247 systems today. This subscription can perform a nearly identical 2248 function, plus a little more. This subscription can request of the 2249 UAC to let the UAS know if there are any location changes to the 2250 UAC. The subscription SHOULD define, or include, what it considers 2251 locally to be "movement". In this way, what one jurisdiction 2252 considers to a large enough change to be "movement" by the UAC does 2253 not mandate this for all jurisdictions. Just as SIP message carry 2254 all the necessary addressing and routing information in each message 2255 - this type of subscription can include what it considers to be a 2256 "movement" by the UAC. This will be what triggers the caller's UA 2257 to NOTIFY the PSAP it has moved, either as a delta from the original 2258 location or a new location the UAC is at. 2260 Here is an example message flow depicting this SUB/NOT for movement 2261 of Alice's UA during an emergency call: 2263 UA Alice Proxy PSAP 2265 | INVITE [M1] | | 2266 |------------------>| | 2267 | | INVITE [M2] | 2268 | |-------------------->| 2269 | | 200 OK [M3] | 2270 | |<--------------------| 2271 | 200 OK [M4] | | 2272 |<------------------| | 2273 | ACK [M5] | 2274 |---------------------------------------->| 2275 | RTP | 2276 |<=======================================>| 2277 | | 2278 | SUBSCRIBE [M6] | 2279 |<----------------------------------------| 2280 | 200 OK (SUB) [M7] | 2281 |---------------------------------------->| 2282 | NOTIFY (init loc verify) [M8] | 2283 |---------------------------------------->| 2284 | 200 OK (NOT) [M9] | 2285 |<----------------------------------------| 2287 **Alice moves locations, causes a trigger** 2289 | NOTIFY (new loc given) [M10] | 2290 |---------------------------------------->| 2291 | 200 OK (NOT) [M11] | 2292 |<----------------------------------------| 2293 Figure 6a. UA-PROXY with Location in INVITE 2295 The call flow shows this: 2297 - Alice called 911/112 (M1 of Figure 6a) and included here location 2298 in a PIDF-LO message body. 2300 - The message was routed correctly (M2 of Figure 6a) (message 2301 routing is not defined here). 2303 - The call was accepted and RTP packets flowed. 2305 - The PSAP operator, either manually or automatically, sent a 2306 SUBSCRIBE Method Request (M6 of Figure 6a) to Alice's UA to 2307 determine or refresh where she is located. 2309 This SUBSCRIBE informs Alice's UA with all it needs to look for 2310 (i.e. what constitutes a change in location, and perhaps which is 2311 the preferred location format for the NOTIFY messages to be sent 2312 back to the PSAP. 2314 - The SUB was accepted with a 200 OK (M7 of Figure 6a). 2316 - Alice's UA immediately, according to [RFC3265], MUST send an 2317 initial status to the subscriber (M8 of Figure 6a). In this 2318 NOTIFY MUST be (perhaps another copy of the same) PIDF-LO from 2319 Alice to the PSAP. 2321 - The PSAP acknowledged receipt of this PIDF-LO in the 200 OK to the 2322 NOTIFY (M9 of Figure 6a). 2324 - If Alice and her UA move enough for the UA to detect what the 2325 SUBSCRIBE considered "movement", Alice's UA, without Alice being 2326 necessarily told, sends a new NOTIFY (M10 of Figure 6a) with this 2327 new location PIDF-LO as a message body. 2329 - This new NOTIFY is acknowledged with another 200 OK (M11 of Figure 2330 6a). 2332 The Subscription SHOULD be for as long as the PSAP operator 2333 considers it needs to know if movement can occur at Alice's UA. In 2334 other words, Alice's UA SHOULD be prepared to receive a SUBSCRIBE 2335 with a very lengthy expires time, and not attempt to reduce the time 2336 requested. When the PSAP considers it time to end the subscription, 2337 it will actively refresh the subscription with a expires of 0, thus 2338 terminating the it. 2340 ** the corresponding appendix has not be completed at this time. 2342 9. Special Considerations for Emergency Calls 2344 Calling for local emergency, such as 911 or 112 today, has special 2345 handling characteristics. First of which is the identification of 2346 the call as an emergency call. When a node detects a call is a 2347 local emergency call, certain processes need to occur that are more 2348 complicated in a SIP architecture than in the circuit switched 2349 world. In the circuit switched world, a caller is tied to a known 2350 Class-5 switch, or a PBX connected to a Class-5 switch. This has 2351 the benefit of providing a location of the end of the wire of that 2352 phone, or more accurately, to the termination point on a wall (of an 2353 office or cube) or on the side of a house or building. Each of 2354 these locations is just that, a physical location. This location 2355 (typically the street address) is entered into a database that 2356 provides a means for looking up where an emergency call came from 2357 during that call's set-up to the PSAP. The look-up is to the 2358 binding of that phone number to that street address. 2360 The challenge in SIP is the disconnect of call processing, either by 2361 the UA itself or by a SIP intermediary, from where the UAC is 2362 located when this emergency call is made. A "call" here in SIP can 2363 be for voice, video, instant messaging or something else - all of 2364 this is considered a call in this document. If the call needs to be 2365 routed to the proper PSAP by some network entity, for example 2366 because the Request-URI didn't have an IP address in it, the routing 2367 entity has to have enough information to route this call to the 2368 proper PSAP. 2370 The routing function towards the proper PSAP is out of scope of this 2371 document, but this document must specify enough SIP capabilities and 2372 information to that SIP intermediary to do the routing correctly 2373 from the contents of that SIP message. 2375 [ID-SIP-SOS] provides one means for identifying a SIP Request as an 2376 emergency session set-up. Once that information is understood by a 2377 routing SIP intermediary, the intermediary (Proxy or an instance of 2378 a B2BUA) must look for the location of the UAC originating the 2379 Request to determine internally or externally where to route the 2380 message to. The mapping of a location to where to route the message 2381 to is also out of scope of this document, and is currently under 2382 investigation. The capability to include location of the UAC in a 2383 SIP message is the task of this document. And this is where it is 2384 separate from the task of defining how to convey location between 2385 user agents that merely want to share location of the UAC. This SIP 2386 intermediary MUST look into the SIP Request, for example an INVITE 2387 Request Method message, for the location of the UAC to be included 2388 in the message. 2390 Location inclusion within a SIP Request will be by-value or by- 2391 reference. By-value is the case in which the location information 2392 is included or contained within the SIP message itself. By- 2393 reference is the case in which the location of the UAC in a 2394 (database) record or document on a server somewhere else, but the 2395 UAC knows the URI to that record/document and includes only that URI 2396 in the SIP Request. 2398 Including this new Location header is not always enough. Therefore, 2399 if the UAC chooses to require there be location recognizable by the 2400 intermediary in order to process this message, the UAC will include 2401 both the "Proxy-Require" and "Require" headers, each with "location" 2402 as their option-tags. The reason for both is that the UAC will not 2403 know the type of SIP element that is doing the routing to the PSAP. 2404 [RFC3261] states the "Proxy-Require" header is for SIP Proxies to 2405 process, and the "Require" header is for SIP UAs to process. Since 2406 the SIP intermediary can be an instance of a B2BUA or a Border 2407 Controller, and neither is guaranteed to adhere to the "Proxy- 2408 Require" header, the Require header MUST be included as well in this 2409 emergency SIP message. 2411 A non-well formed message example would be: 2413 INVITE sip:sos@psap1.tx.us 2414 Proxy-Require: location 2415 Require: location 2416 Location: 2418 If the intermediary understands this message and is able to learn 2419 the UAC's location because it is recognizable as included in the 2420 Request, or to perform a mapping function (locally or remotely) to 2421 determine where to route the call (to the correct PSAP), the message 2422 is forwarded towards that PSAP with the new Request-URI of that 2423 PSAP. 2425 NOTE: The ability and process of this mapping function (taking a 2426 location and determining the correct PSAP for that location) 2427 within the SIP intermediary is defined elsewhere. 2429 If the intermediary does not understand this message and its 2430 relationship to location, perhaps because it does not understand the 2431 concept of routing based on the UAC's location, it needs to forward 2432 the message to another intermediary that will understand how to take 2433 location from the message and route it correctly, or communicate 2434 with the UAC if there are issues with the message. The intermediary 2435 MUST not reject the message because it does not understand the 2436 concept of "location". This document does not define how this 2437 occurs, as the offered solution here is to include a "Proxy-Require" 2438 and a "Require" header in this original Request. 2440 [NOTE: the authors are not sure where that needs to be defined - 2441 here, or in another document. Another way to address this 2442 inconsistency, one that is less forceful, is to mandate the 2443 inclusion of the Supported header instead of the "Proxy- 2444 Require" and a "Require" headers by the UAC in the original 2445 Request. An option is to have the subsequent message from 2446 the UAC remove the Proxy-Require and Require headers and 2447 insert a Supported header, which will not cause a well 2448 behaving intermediary to reject the request. Comments are 2449 desired] 2451 The ability of a PSAP to SUBSCRIBE to the caller's UA to learn if it 2452 moves to a new location, thus changing where the first responders 2453 need to be dispatched, is described in section 8.6 of this document. 2454 That section goes into some detail on how this subscription can be 2455 long lasting to receive repeated updates from the caller's UA if 2456 there is movement. 2458 9.1 Emergency UAC Behavior Rules 2460 The following are the rules of behavior for the UAC transmitting an 2461 emergency SIP Request: 2463 1) The UAC MUST include a location header with a viable location 2464 value indicating where the UAC is to aid the routing 2465 intermediary. 2467 If location is by-value, the location header will have a "loc-body" 2468 option-tag, and the message will include a PIDF-LO message body 2469 indicating the UAC's currently location. 2471 If the location is by-reference, the location header will have the 2472 URI of the location of that UAC as the header value. 2474 Either of the above will indicate to the intermediary that the UAC 2475 is knowledgeable of location, and indicated where the location can 2476 be learned by the intermediary. If this is not present, the 2477 intermediary will act accordingly and supply location other than in 2478 a location message body. This gives the intermediary the ability to 2479 add a location header with a uri of the location record from a 2480 database that the UAS (in the PSAP) will access to learn the UAC's 2481 location when necessary. 2483 2) The UAC MUST include both the "Proxy-Require" and a "Require" 2484 header indicating "location" is required for this message. 2486 3) The UAC MUST understand any 425 (Retry Location Body) Response 2487 message with the PIDF-LO included as a message body part for that 2488 UAC to include in the subsequent retry INVITE to the PSAP as its 2489 location. 2491 NOTE: An open question remains in the case in which the UAC includes 2492 what it thinks is a viable location by-value or by-reference 2493 and receives a 488 (Not Acceptable Here) with an Unsupported 2494 header indicating "Location". 2496 Option#1 to this would be for the UAC to back off including the 2497 "Proxy-Require" and a "Require" headers and merely put in a 2498 Supported Header with "location" in the attempt to get the 2499 message past the SIP intermediary that is rejecting the INVITE 2500 Request message from a lack of understanding of location. 2502 Comments are asked in this case. 2504 4) the UAC SHOULD NOT S/MIME or SIPFRAG protect location 2505 Information without certainty of knowledge the intermediary can 2506 decrypt the message to learn the location of the UAC. This 2507 defeats the purpose of an intermediary assisting in routing the 2508 message correctly - which will be required for 911/112-type 2509 request attempts. 2511 5) the SIP Request from the UAC to the PSAP SHOULD be protected 2512 through a SIPS-URI, TLS or IPsec, but the UAC MUST be prepared to 2513 initially send the message, or a retransmission (based on a 2514 timeout or rejection message) in cleartext to ensure the session 2515 set-up does not fail due to security incompatibilities in 2516 transit, or at the PSAP. 2518 6) the UAC MUST include both a element and a 2519 element in the PIDF-LO message body indicating #1 the 2520 organization that provided the location information to the UAC, 2521 and #2 how the UAC learned its location information, 2522 respectively. 2524 7) The UAC SHOULD be prepared to receive a SUBSCRIBE Request message 2525 from the PSAP seeking verification of its location. This 2526 subscription SHOULD want to last for more than one NOTIFY back to 2527 the subscriber, for the purposes of getting updates of movement 2528 the calling (UAC) detects, based on what is in the original 2529 SUBSCRIBE Request message. As such, this SUBSCRIBE SHOULD have a 2530 lengthy Expires timer. The original (the calling) UAC MUST NOT 2531 reduce the time of this Expires Timer if it accepts the 2532 SUBSCRIBE. See section 8.6 for more on SUB/NOT and location 2533 conveyance. 2535 This SUBSCRIBE SHOULD provide within the message what it considers 2536 to be "movement" by the emergency calling (UAC). 2538 9.2 Emergency UAS/Intermediary Behavior Rules 2540 The following are the rules of behavior for the UAS or intermediary 2541 receiving an emergency SIP Request: 2543 1) identifies that SIP Request as an emergency Request. 2545 2) The intermediary looks for the "location" header to inform it 2546 where location is within this message (by-reference or by-value), 2547 and if the format of the location information is given as a hint. 2549 3) The intermediary looks for a "Proxy-Require" and/or a "Require" 2550 header indicating "location" is required for this message. 2552 4) If the intermediary does not understand location, or does not 2553 observe viable location information within this message MUST do 2554 one of the following action items: 2556 a) reject the message with a 488 (Not Acceptable Here) with a 2557 Unsupported header indicating "location" if the intermediary 2558 does not understand location and there is a "Proxy-Require" 2559 and/or a "Require" header indicating "location" 2561 b) if the intermediary does not understand location, and there is 2562 no "Proxy-Require" and/or a "Require" header indicating 2563 "location", the intermediary MUST not reject the message, but 2564 MUST forward this message to another (upstream) SIP 2565 intermediary for proper processing. 2567 c) reject the message with a 425 (Retry Location Body) if it 2568 understands the concept of location, but does not detect 2569 location in the message, and has a current PIDF-LO for that 2570 UAC. The UAC will know to reattempt the INVITE with this new 2571 PIDF-LO message body. 2573 d) if the intermediary understands the concept of location, but 2574 does not detect location within this message, it MAY insert a 2575 location by-reference, if known 2577 Of particular concern to this option "d" above is the fact this 2578 information never gets back to the UAC, so it MAY remain in the dark 2579 as to its location. If the UAC does not understand location, which 2580 SHOULD be indicated by the lack of presence of the Location header, 2581 insertion is the best possible solution short of upgrading the UAC. 2582 However, if the UAC includes a Location header, an intermediary 2583 SHOULD NOT insert location by-reference and forward the message. 2585 5) the intermediary MUST NOT delete a PIDF-LO message body 2587 6) the intermediary that knows the concept of location SHOULD NOT 2588 insert a location by-reference header value if there is a 2589 location by-value currently in the SIP message from the UAC. 2591 Behavior #5 above MUST NOT be done to satisfy Behavior #6 here, just 2592 to get a by-reference location indication in the message. 2594 7) If the UAC included a location header, but this was not deemed 2595 usable, or determined to be incorrect, the intermediary MAY 2596 reject the Request with one of the following response codes: 2598 a) a 424 (Bad Location Information) response informing the UAC to 2599 include its location in a subsequent attempt, or 2601 b) a 425 (Retry Location Body) if the intermediary can include 2602 what it considers to be current and accurate location 2603 information to the UAC. 2605 9.3 Basic Emergency Message Flow Examples 2607 The following subsections provide a discussion on the basic message 2608 flows for emergency messaging. 2610 9.3.1 Basic INVITE with Location Body 2612 Here is the basic message flow for Alice calling for help. 2614 UA Alice Proxy PSAP 2616 | INVITE (w/ PIDF-LO)[M1] | 2617 |------------------>| | 2618 | INVITE (w/ PIDF-LO) [M2] | 2619 | |-------------------->| 2620 | | 200 OK [M3] | 2621 | |<--------------------| 2622 | 200 OK [M4] | | 2623 |<------------------| | 2624 | ACK [M5] | 2625 |---------------------------------------->| 2626 | RTP | 2627 |<=======================================>| 2628 | | 2630 Figure 7a. UA-PROXY with Location in INVITE 2632 Consider Figure 7a as a very basic message flow establishing an 2633 emergency call from Alice to the correct PSAP suiting her location. 2635 [M1 of Figure 7a] 2637 INVITE sips:sos@atlanta.com SIP/2.0 2638 From: Alice 2639 To: sos@ 2640 Proxy-Require: Location 2641 Require: Location 2642 Location: geo-loc 2643 Content-Type: multipart/mixed; boundary=boundary1 2644 Content-Length: ... 2646 --boundary1 2648 Content-Type: application/sdp 2649 v=0 2650 ... 2652 --boundary1 2654 Content-Type: application/cpim-pidf+xml 2655 (Alice's geo PIDF-LO goes here) 2657 Once the intermediary's mapping function determines the correct PSAP 2658 for Alice's sos@ call to go to, the INVITE will look something like 2659 this (with a changed Request-URI): 2661 [M2 of Figure 7a] 2663 INVITE sips:sos@psap1.atlanta.us SIP/2.0 2664 From: Alice 2665 To: sos@ 2666 Proxy-Require: Location 2667 Require: Location 2668 Location: geo-loc 2669 Content-Type: multipart/mixed; boundary=boundary1 2670 Content-Length: ... 2672 --boundary1 2674 Content-Type: application/sdp 2675 v=0 2676 ... 2678 --boundary1 2680 Content-Type: application/cpim-pidf+xml 2681 (Alice's geo PIDF-LO goes here) 2683 The call gets set up and everything is grand. 2685 See section 8.6 for the message flow that will likely be the follow- 2686 on to this flow in Figure 7a. 2688 9.3.2 Basic INVITE Retry from 425 Response 2690 If the routing SIP intermediary does not detect location in Alice's 2691 INVITE, or determines if it is wrong, and the intermediary knows the 2692 current and correct location of Alice's UAC, it transmits a 425 2693 (Retry Location Body) and includes that location information (by- 2694 value or by-reference) in the rejection response. Figure 7b shows 2695 this basic message flow. 2697 UA Alice Proxy PSAP 2699 | INVITE [M1] | | 2700 |------------------>| | 2701 | 425 Retry Location Body [M2] | 2702 |<------------------| | 2703 | INVITE [M3] | | 2704 |------------------>| | 2705 | | INVITE [M4] | 2706 | |-------------------->| 2707 | | 200 OK [M5] | 2708 | |<--------------------| 2709 | ACK [M6] | 2710 |---------------------------------------->| 2711 | RTP | 2712 |<=======================================>| 2713 | | 2715 Figure 7b. INVITE Retry with Location 2717 The 425 rejection Response could look something like this: 2719 [M2 of Figure 7b] 2721 SIP/2.0 425 Retry Location Body 2722 To: psap1 2723 From: Alice 2724 Location: geo-loc 2725 Content-type: application/cpim-pidf+xml 2727 [Alice's geo formatted PIDF-LO goes here] 2729 [M3 of Figure 7b] 2731 INVITE sips:sos@psap1.atlanta.us SIP/2.0 2732 From: Alice 2733 To: sos@ 2734 Proxy-Require: Location 2735 Require: Location 2736 Location: geo-loc 2737 Content-Type: multipart/mixed; boundary=boundary1 2738 Content-Length: ... 2740 --boundary1 2742 Content-Type: application/sdp 2743 v=0 2744 ... 2746 --boundary1 2747 Content-Type: application/cpim-pidf+xml 2748 (Alice's geo PIDF-LO goes here) 2750 10. Meeting RFC3693 Requirements 2752 Section 7.2 of [RFC3693] details the requirements of a "using 2753 protocol". They are: 2755 Req. 4. The using protocol has to obey the privacy and security 2756 instructions coded in the Location Object and in the 2757 corresponding Rules regarding the transmission and storage of the 2758 LO. 2760 This document requires, in Section 7, that SIP entities sending or 2761 receiving location MUST obey such instructions. 2763 Req. 5. The using protocol will typically facilitate that the keys 2764 associated with the credentials are transported to the respective 2765 parties, that is, key establishment is the responsibility of the 2766 using protocol. 2768 [RFC3261] and the documents it references define the key establish 2769 mechanisms. 2771 Req. 6. (Single Message Transfer) In particular, for tracking of 2772 small target devices, the design should allow a single 2773 message/packet transmission of location as a complete 2774 transaction. 2776 This document specifies that the LO be contained in the body of a 2777 single message. 2779 11. Open issues 2781 This is a list of open issues that have not yet been addressed to 2782 conclusion: 2784 1) Should a Proxy somehow label its location information in the 4XX 2785 (Retry Location Body) message? 2787 11.1 New Open Issues 2789 These are new open issues to be addressed within this document or 2790 the topics/areas dropped from consideration: 2792 1) There is an outstanding request to be able to include more than 2793 one location element, and label at least one the current position 2794 of the UAC, and another the "billing" address of the owner of the 2795 UAC. This comes from the country of Sweden, from our favorite 2796 Patrik Faltstrom. 2798 Options to this are use the Content-Type headers associated with 2799 each message body part, using either: 2801 A) multipart/mixed - because they could be considered different 2803 B) multipart/alternative - for one application to use only one, and 2804 allowing another application to use another 2806 C) multipart/related - because they could be considered similar 2807 enough as they each deal with location 2809 2) May add a section for end-to-middle in a services model 2811 12. Security Considerations 2813 Conveyance of geo-location of a UAC is problematic for many reasons. 2814 This document calls for that conveyance to normally be accomplished 2815 through secure message body means (like S/MIME or TLS). In cases 2816 where a session set-up is routed based on the location of the UAC 2817 initiating the session or SIP MESSAGE, securing the location with an 2818 end-to-end mechanism such as S/MIME is problematic. 2820 13. IANA Considerations 2822 This section defines two new 4XX error response codes within the 2823 sip-parameters section of IANA. [NOTE: RFC XXXX denotes this 2824 document. 2826 13.1 IANA Registration for Response Code 4XX 2828 Reference: RFC-XXXX (this document) 2829 Response code: 424 2830 Default reason phrase: Bad Location Information 2832 13.2 IANA Registration for Response Code 4XX 2834 Reference: RFC-XXXX (this document) 2835 Response code: 425 2836 Default reason phrase: Retry Location Body 2838 13.3 IANA Registration for the SIP Location Header 2840 This subsection will be completed once the authors work out the ABNF 2841 for the header 2843 14. Acknowledgements 2845 To Dave Oran for helping to shape this idea. To Jon Peterson and 2846 Dean Willis on guidance of the effort. To Henning Schulzrinne, 2847 Jonathan Rosenberg, Dick Knight, Mike Hammer and Keith Drage for 2848 constructive feedback. 2850 To Paul Kyzivat for inspiring some of the recent text addressing 2851 lingering issues the authors could not resolve. 2853 15. References 2855 15.1 References - Normative 2857 [RFC3261] J. Rosenberg, H. Schulzrinne, G. Camarillo, A. Johnston, J. 2858 Peterson, R. Sparks, M. Handley, and E. Schooler, "SIP: 2859 Session Initiation Protocol", RFC 3261, May 2002. 2861 [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate 2862 Requirement Levels", RFC 2119, March 1997 2864 [RFC3428] B. Campbell, Ed., J. Rosenberg, H. Schulzrinne, C. Huitema, 2865 D. Gurle, "Session Initiation Protocol (SIP) Extension for 2866 Instant Messaging" , RFC 3428, December 2002 2868 [RFC3825] J. Polk, J. Schnizlein, M. Linsner, "Dynamic Host 2869 Configuration Protocol Option for Coordinate-based Location 2870 Configuration Information", RFC 3825, July 2004 2872 [ID-CIVIC] H. Schulzrinne, "draft-ietf-geopriv-dhcp-civic-06.txt", 2873 Internet Draft, May 05, Work in progress 2875 [RFC3693] J. Cuellar, J. Morris, D. Mulligan, J. Peterson. J. Polk, 2876 "Geopriv Requirements", RFC 3693, February 2004 2878 [RFC3311] J. Rosenberg, "The Session Initiation Protocol (SIP) UPDATE 2879 Method", RFC 3311, October 2002 2881 [RFC3903] Niemi, A., "Session Initiation Protocol (SIP) Extension 2882 for Event State Publication", RFC 3903, October 2004. 2884 [ID-PIDF-LO] J. Peterson, "draft-ietf-geopriv-pidf-lo-03", Internet 2885 Draft, Sept 2004, work in progress 2887 [RFC2392] E. Levinson, " Content-ID and Message-ID Uniform Resource 2888 Locators", RFC 2393, August 1998 2890 [RFC3264] J. Rosenberg, H. Schulzrinne, "The Offer/Answer Model with 2891 Session Description Protocol", RFC 3264, June 2002 2893 [RFC3515] R. Sparks, "The Session Initiation Protocol (SIP) Refer 2894 Method", RFC 3515, April 2003 2896 [RFC3265] Roach, A., "Session Initiation Protocol (SIP)-Specific 2897 Event Notification", RFC 3265, June 2002. 2899 15.2 References - Informative 2901 [ID-End-Mid-Sec] "Requirements for End to Middle Security in SIP", 2902 draft-ietf-sipping-e2m-sec-reqs-03.txt, Internet Draft, June 2903 2004, work in progress, 2905 [ID-Sess-Pol] J. Rosenberg, "Requirements for Session Policy for the 2906 Session Initiation Protocol�, draft-ietf-sipping-session- 2907 policy-req-00", Internet Draft, June, 2003, "work in 2908 progress" 2910 [ID-SIP-SOS] H. Schulzrinne, "draft-ietf-sipping-sos-00.txt", Internet 2911 Draft, Feb 2004, Work in progress 2913 [ID-EMER-ARCH] H. Schulzrinne, B. Rosen, "draft-schulzrinne-sipping- 2914 emergency-arch", Internet Draft, Feb 2004, work in progress 2916 Author Information 2918 James M. Polk 2919 Cisco Systems 2920 2200 East President George Bush Turnpike 33.00111N 2921 Richardson, Texas 75082 USA 96.68142W 2922 jmpolk@cisco.com 2924 Brian Rosen 40.4N 2925 br@brianrosen.net 80.0W 2926 NeuStar 2928 NOTE: these appendixes are not in good order yet, and will be worked 2929 on soon. 2931 Appendix A1. UA-to-UA INVITE with Coordinate Location Not Using S/MIME 2933 Below is a well-formed SIP INVITE Method message to the example in 2934 Figure 1 in section 8.1. This message is here to show that although 2935 the requirements are mandatory to implement proper security, it is 2936 not mandatory to use. This message below is show for those cases 2937 where hop-by-hop security is deployed. 2939 [Message 1 in Figure 1] 2941 INVITE sip:bob@biloxi.example.com SIP/2.0 2942 Via: SIP/2.0/TCP pc33.atlanta.example.com 2943 ;branch=z9hG4bK74bf9 2944 Max-Forwards: 70 2945 From: Alice ;tag=9fxced76sl 2946 To: Bob 2947 Call-ID: 3848276298220188511@atlanta.example.com 2948 CSeq: 31862 INVITE 2949 Contact: 2950 Content-Type: multipart/mixed; boundary=boundary1 2951 Content-Length: ... 2953 --boundary1 2955 Content-Type: application/sdp 2956 v=0 2957 o=alice 2890844526 2890844526 IN IP4 atlanta.example.com 2958 c=IN IP4 10.1.3.33 2959 t=0 0 2960 m=audio 49172 RTP/AVP 0 4 18 2961 a=rtpmap:0 PCMU/8000 2963 --broundary1 2965 Content-Type: application/cpim-pidf+xml 2966 2967 2972 2973 2005-11-11T08:57:29Z 2974 2975 2976 2977 2978 2979 41.87891N 2980 87.63649W 2981 2982 2984 dhcp 2985 2986 2987 no 2988 2005-11-13T14:57:29Z 2990 2991 2992 2993 2994 2996 --boundary1-- 2998 Appendix A2. INVITE and REFER between 3 UAs 3000 In the following example, Alice presents her location in the INVITE 3001 to Bob, which Bob 200 OKs with his location as well. Bob then 3002 directs Alice to contact Carol. The REFER Method [RFC3515] is used 3003 in the message sequence, but it does not carry anyone's location 3004 within the REFER message. This example is here to show a 3-way 3005 communication of location, coupled with how a UA can include someone 3006 else's location. This has security implications due to neither 3007 primary party in the last location transfer being the owner of the 3008 location information. Alice (in this case) MUST adhere to the 3009 retention and distribution privacy requirements within Bob's 3010 location object regarding his location information prior to 3011 considering its inclusion in the INVITE to Carol. 3013 UA Alice Bob Carol 3015 | INVITE [M1] | | 3016 |---------------------------->| | 3017 | 200 OK [M2] | | 3018 |<----------------------------| | 3019 | ACK [M3] | | 3020 |---------------------------->| | 3021 | RTP | | 3022 |<===========================>| | 3023 | reINVITE (hold) [M4] | | 3024 |<----------------------------| | 3025 | 200 OK [M5] | | 3026 |---------------------------->| | 3027 | REFER (Refer-to:Carol) [M6] | | 3028 |<----------------------------| | 3029 | NOTIFY [M9] | | 3030 |---------------------------->| | 3031 | 200 OK [M10] | | 3032 |<----------------------------| | 3033 | INVITE [M7] | 3034 |------------------------------------------>| 3035 | 200 OK [M8] | 3036 |------------------------------------------>| 3037 | RTP | 3038 |<=========================================>| 3039 | NOTIFY [M9] | | 3040 |---------------------------->| | 3041 | 200 OK [M10] | | 3042 |<----------------------------| | 3043 | BYE [M11] | | 3044 |<----------------------------| | 3045 | 200 OK [M12] | | 3046 |---------------------------->| | 3047 | | 3049 Figure A2. UA-to-UA with Location in REFER 3051 Appendix A3. UA-to-UA REFER with Civic Location Using S/MIME 3053 In Figure A2., we have an example message flow involving the REFER 3054 Method. The REFER itself does not carry location objects. 3056 We are not including all the messages for space reasons. M1 is a 3057 well-formed SIP message that contains Alice's location. M2 is Bob's 3058 200 OK in response to Alice's INVITE, and it contains Bob's 3059 Location. 3061 [M1 of Figure A2] - Alice at Sears Tower 3063 INVITE sips:bob@biloxi.example.com SIP/2.0 3064 Via: SIP/2.0/TLS pc33.atlanta.example.com 3065 ;branch=z9hG4bK776asdhds 3066 Max-Forwards: 70 3067 To: Bob 3068 From: Alice ;tag=1928301774 3069 Call-ID: a84b4c76e66710@pc33.atlanta.example.com 3070 CSeq: 314159 INVITE 3071 Contact: 3072 Content-Type: application/pkcs7-mime; 3073 smime-type=enveloped-data; name=smime.p7m 3074 Content-Disposition: attachment; 3075 filename=smime.p7m handling=required 3077 Content-Type: multipart/mixed; boundary=boundary1 3079 --boundary1 3081 Content-Type: application/sdp 3082 v=0 3083 o=alice 2890844526 2890844526 IN IP4 atlanta.example.com 3084 c=IN IP4 10.1.3.33 3085 t=0 0 3086 m=audio 49172 RTP/AVP 0 4 18 3087 a=rtpmap:0 PCMU/8000 3089 --boundary1 3091 Content-type: application/cpim-pidf+xml 3092 3093 3098 3099 2005-11-11T08:57:29Z 3100 3101 3102 3103 3104 US 3105 Illinois 3106 Chicago 3107 233 3108 South 3109 Wacker 3110 Drive 3111 60606 3112 Sears Tower 3113 1 3114 3115 dhcp 3116 www.cisco.com 3117 3118 3119 no 3120 2005-11-13T14:57:29Z 3122 3123 3124 3125 3126 3128 --boundary1-- 3130 Bob replies to Alice's INVITE with a 200 OK and includes his 3131 location. 3133 [M2 of Figure A2] - Bob watching Cubs Game at Wrigley Field 3135 SIP/2.0 200 OK 3136 Via: SIP/2.0/TCP pc33.atlanta.example.com 3137 ;branch=z9hG4bKnashds8 ;received=10.1.3.33 3139 To: Bob ;tag=a6c85cf 3140 From: Alice ;tag=1928301774 3141 Call-ID: a84b4c76e66710 3142 CSeq: 314159 INVITE 3143 Contact: 3144 Content-Type: application/pkcs7-mime; 3145 smime-type=enveloped-data; name=smime.p7m 3146 Content-Disposition: attachment; 3147 filename=smime.p7m handling=required 3149 Content-Type: multipart/mixed; boundary=boundary1 3151 --boundary1 3153 Content-Type: application/sdp 3154 v=0 3155 o=bob 2890844530 2890844530 IN IP4 biloxi.example.com 3156 c=IN IP4 192.168.10.20 3157 t=0 0 3158 m=audio 3456 RTP/AVP 0 3159 a=rtpmap:0 PCMU/8000 3161 --boundary1 3163 Content-type: application/cpim-pidf+xml 3164 3165 3170 3171 2005-11-6T02:30:29Z 3172 3173 3174 3175 3176 US 3177 Illinois 3178 Chicago 3179 Addison 3180 1060 3181 W 3182 street 3183 Wrigley Field 3184 60613 3185 3186 dhcp 3187 www.cisco.com 3188 3189 3190 no 3191 2005-11-6T18:30:29Z 3193 3194 3195 3196 3197 3199 --boundary1-- 3201 Bob refers Alice to Carol, and in M7, Alice includes both locations 3202 in a single SIP message. This is possible because Bob set his 3203 retention value to "yes", thus allowing Alice to pass his location 3204 on to Carol. 3206 [M7 of Figure A2] - Alice tells Carol where she and Bob are 3208 INVITE sips:carol@chicago.example.com SIP/2.0 3209 Via: SIP/2.0/TLS pc33.atlanta.example.com 3210 ;branch=z9hG4bK776asdhdt 3211 Max-Forwards: 70 3212 To: Carol 3213 From: Alice ;tag=1928301775 3214 Call-ID: a84b4c76e66711@pc33.atlanta.example.com 3215 CSeq: 314160 INVITE 3216 Contact: 3217 Content-Type: application/pkcs7-mime; 3218 smime-type=enveloped-data; name=smime.p7m 3219 Content-Disposition: attachment; 3220 filename=smime.p7m handling=required 3222 Content-Type: multipart/mixed; boundary=boundary1 3224 --boundary1 3226 Content-Type: application/sdp 3227 v=0 3228 o=alice 2890844531 2890844531 IN IP4 atlanta.example.com 3229 c=IN IP4 10.1.3.33 3230 t=0 0 3231 m=audio 49173 RTP/AVP 0 4 18 3232 a=rtpmap:0 PCMU/8000 3234 --boundary1 3236 Content-type: application/cpim-pidf+xml 3237 3238 3244 3245 2005-11-5T02:30:29Z 3246 3247 3248 3249 3250 US 3251 Illinois 3252 Chicago 3253 Addison 3254 1060 3255 W 3256 street 3257 Wrigley Field 3258 60613 3259 3260 dhcp 3261 802.11 3262 www.cisco.com 3263 3264 3265 yes 3267 2005-11-6T18:30:29Z 3269 3270 3271 3272 3273 3275 --boundary1 3277 Content-type: application/cpim-pidf+xml 3278 3279 3284 3285 2005-11-6T02:30:29Z 3286 3287 3288 3289 3290 US 3291 Illinois 3292 Chicago 3293 233 3294 South 3295 Wacker 3296 Drive 3297 60606 3298 Sears Tower 3299 1 3300 3301 dhcp 3302 802.11 3303 www.marconi.com 3304 3305 3306 no 3307 2005-11-6T18:30:29Z 3309 3310 3311 3312 3313 3315 --boundary1-- 3317 It is an open question of whether there should be a mechanism to 3318 request or require the transmission of an LO. The LO is contained 3319 in a body, so the available sip mechanisms do not apply. 3321 Appendix A4. UAC to UAS or Proxy Using OPTIONS Method (from 8.2) 3323 Appendix A5. UA-to-UA Using MESSAGE Method (from 8.3) 3325 UA Alice UA Bob 3327 | MESSAGE [M1] | 3328 |---------------------------------------->| 3329 | 200 OK [M2] | 3330 |<----------------------------------------| 3331 | | 3333 Figure A5. UA-UA with Location in MESSAGE 3335 Appendix A6. UA-to-UA MESSAGE with Coordinate Location Using S/MIME 3337 Below is M1 from Figure 2 in section 8.2. that is fully secure and 3338 in compliance with Geopriv requirements in [RFC3693] for security 3339 concerns. 3341 [Message 1 in Figure A5] 3343 MESSAGE sips:bob@biloxi.example.com SIP/2.0 3344 Via: SIP/2.0/TLS pc33.atlanta.example.com 3345 ;branch=z9hG4bK776asegma 3346 Max-Forwards: 70 3347 To: Bob 3348 From: Alice ;tag=1928301774 3349 Call-ID: a84b4c76e66710@pc33.atlanta.example.com 3350 CSeq: 22756 MESSAGE 3351 Content-Type: application/pkcs7-mime; 3352 smime-type=enveloped-data; name=smime.p7m 3353 Content-Disposition: attachment; 3354 filename=smime.p7m handling=required 3356 Content-Type: multipart/mixed; boundary=boundary1 3358 --boundary1 3360 Content-Type: text/plain 3361 Here's my location, Bob? 3363 --broundary1 3365 Content-Type: application/cpim-pidf+xml 3366 Content-Disposition: render 3367 Content-Description: my location 3368 3369 3374 3375 2005-11-11T08:57:29Z 3376 3377 3378 3379 3380 3381 41.87891N 3382 87.63649W 3383 3384 3385 dhcp 3386 3387 3388 no 3389 2005-11-13T14:57:29Z 3391 3392 3394 3395 3396 3398 --boundary1-- 3400 Appendix A7. UA-to-UA MESSAGE with Civic Location Not Using S/MIME 3402 Below is a well-formed SIP MESSAGE Method message to the example in 3403 Figure 2 in section 8.2 when hop-by-hop security mechanisms are 3404 deployed. 3406 [Message 1 in Figure A5] 3408 MESSAGE sip:bob@biloxi.example.com SIP/2.0 3409 From: ;tag=34589882 3410 To: 3411 Call-ID: 9242892442211117@atlanta.example.com 3412 CSeq: 6187 MESSAGE 3413 Content-Type: application/cpim-pidf+xml 3414 Content-ID: <766534765937@atlanta.example.com> 3415 Content-Disposition: render 3416 Content-Description: my location 3418 3419 3424 3425 2005-11-11T08:57:29Z 3426 3427 3428 3429 3430 US 3431 Illinois 3432 Chicago 3433 233 3434 South 3435 Wacker 3436 Drive 3437 60606 3438 Sears Tower 3439 1 3440 3441 dhcp 3442 3443 3444 no 3445 2005-11-13T14:57:29Z 3447 3448 3449 3450 3451 3453 Appendix A8. UA-to-UA Location Conveyance Using UPDATE (from 8.4) 3455 UA Alice UA Bob 3457 | INVITE [M1] | 3458 |---------------------------------------->| 3459 | 183 (session Progress) [M2] | 3460 |<----------------------------------------| 3461 | PRACK [M3] | 3462 |---------------------------------------->| 3463 | ACK (PRACK) [M4] | 3464 |<----------------------------------------| 3465 | UPDATE [M5] | 3466 |---------------------------------------->| 3467 | ACK (UPDATE) [M6] | 3468 |<----------------------------------------| 3469 | 200 OK (INVITE) [M7] | 3470 |<----------------------------------------| 3471 | RTP | 3472 |<=======================================>| 3473 | | 3475 Figure A6. UA-UA with Location in UPDATE 3477 The following section will include the M1 and M5 messages in detail, 3478 but only in the civic format. 3480 Appendix A9. UA-to-UA UPDATE with Civic Location Not Using S/MIME 3482 Here is the initial INVITE from Alice to Bob. 3484 [M1 INVITE to Bob] 3486 INVITE sips:bob@biloxi.example.com SIP/2.0 3487 Via: SIP/2.0/TLS pc33.atlanta.example.com 3488 ;branch=z9hG4bK776asdhds 3489 Max-Forwards: 70 3490 To: Bob 3491 From: Alice ;tag=1928301774 3492 Call-ID: a84b4c76e66710@pc33.atlanta.example.com 3493 CSeq: 314159 INVITE 3494 Contact: 3495 Content-Type: application/pkcs7-mime; 3496 smime-type=enveloped-data; name=smime.p7m 3497 Content-Disposition: attachment; 3498 filename=smime.p7m handling=required 3500 Content-Type: multipart/mixed; boundary=boundary1 3502 --boundary1 3504 Content-Type: application/sdp 3505 v=0 3506 o=alice 2890844526 2890844526 IN IP4 atlanta.example.com 3507 c=IN IP4 10.1.3.33 3508 t=0 0 3509 m=audio 49172 RTP/AVP 0 4 18 3510 a=rtpmap:0 PCMU/8000 3512 --boundary1 3514 Content-type: application/cpim-pidf+xml 3515 3516 3521 3522 2005-11-11T08:57:29Z 3523 3524 3525 3526 3527 US 3528 Illinois 3529 Chicago 3530 233 3531 South 3532 Wacker 3533 Drive 3534 60606 3535 Sears Tower 3536 1 3537 3538 dhcp 3539 802.11 3540 www.cisco.com 3541 3542 3543 no 3544 2005-11-13T14:57:29Z 3547 3548 3549 3550 3551 3553 --boundary1-- 3555 Alice moves locations (with her UA detecting the movement), causing 3556 her UA to generate an UPDATE message ([M5] of Figure 3) prior to 3557 her UA receiving a final response from Bob. Here is that message: 3559 M5 UPDATE to Bob 3561 UPDATE sips:bob@biloxi.example.com/TCP SIP/2.0 3562 Via: SIP/2.0/TLS pc33.atlanta.example.com 3563 ;branch=z9hG4bK776asdhds 3564 Max-Forwards: 70 3565 To: Bob 3566 From: Alice ;tag=1928 3567 Call-ID: a84b4c76e66710@pc33.atlanta.example.com 3568 CSeq: 10197 UPDATE 3569 Contact: 3570 Content-Type: application/pkcs7-mime; 3571 smime-type=enveloped-data; name=smime.p7m 3572 Content-Disposition: attachment; 3573 filename=smime.p7m handling=required 3575 Content-Type: multipart/mixed; boundary=boundary1 3577 --boundary1 3579 Content-Type: application/sdp 3580 v=0 3581 o=alice 2890844526 2890844526 IN IP4 atlanta.example.com 3582 c=IN IP4 10.1.3.33 3583 t=0 0 3584 m=audio 49172 RTP/AVP 0 4 18 3585 a=rtpmap:0 PCMU/8000 3587 --boundary1 3589 Content-type: application/cpim-pidf+xml 3590 3591 3596 3597 2005-11-11T08:57:29Z 3598 3599 3600 3601 3602 US 3603 Illinois 3604 Chicago 3605 250 3606 South Upper 3607 Wacker 3608 Drive 3609 60606 3610 Venice Cafe 3611 1 3612 3613 dhcp 3614 802.11 3615 www.t-mobile.com 3616 3617 3618 no 3619 2005-11-13T14:57:29Z 3621 3622 3623 3624 3625 3627 --boundary1-- 3629 Appendix A10. UA-to-UA Location Conveyance Using PUBLISH (from 8.5) 3631 ** This appendix is not be completed at this time. 3633 Appendix A11. UA-to-UA Location Conveyance Using SUBSCRIBE and NOTIFY 3634 (from 8.6) 3636 ** This appendix is not be completed at this time. 3638 Intellectual Property Statement 3640 The IETF takes no position regarding the validity or scope of any 3641 Intellectual Property Rights or other rights that might be claimed 3642 to pertain to the implementation or use of the technology described 3643 in this document or the extent to which any license under such 3644 rights might or might not be available; nor does it represent that 3645 it has made any independent effort to identify any such rights. 3646 Information on the procedures with respect to rights in RFC 3647 documents can be found in BCP 78 and BCP 79. 3649 Copies of IPR disclosures made to the IETF Secretariat and any 3650 assurances of licenses to be made available, or the result of an 3651 attempt made to obtain a general license or permission for the use 3652 of such proprietary rights by implementers or users of this 3653 specification can be obtained from the IETF on-line IPR repository 3654 at http://www.ietf.org/ipr. 3656 The IETF invites any interested party to bring to its attention any 3657 copyrights, patents or patent applications, or other proprietary 3658 rights that may cover technology that may be required to implement 3659 this standard. Please address the information to the IETF at 3660 ietf-ipr@ietf.org. 3662 Disclaimer of Validity 3664 This document and the information contained herein are provided on 3665 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 3666 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE 3667 INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR 3668 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 3669 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 3670 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 3672 Copyright Statement 3674 Copyright (C) The Internet Society (2005). This document is subject 3675 to the rights, licenses and restrictions contained in BCP 78, and 3676 except as set forth therein, the authors retain all their rights. 3678 Acknowledgment 3680 Funding for the RFC Editor function is currently provided by the 3681 Internet Society. 3683 The Expiration date for this Internet Draft is: 3685 January 17th, 2006