idnits 2.17.1 draft-ietf-sip-location-conveyance-03.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 1455. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1439. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1445. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document seems to lack an RFC 3979 Section 5, para. 1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == It seems as if not all pages are separated by form feeds - found 0 form feeds but 29 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 624 has weird spacing: '... Rr ar ...' == Line 628 has weird spacing: '... Rr ar ...' == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'not RECOMMENDED' in this paragraph: While many jurisdictions force a user to reveal their location during an emergency call set-up, there is a small, but real, number of jurisdictions that allow a user to configure their calling device to disable providing location, even during emergency calling. This capability MUST be configurable, but is not RECOMMENDED as the default configuration of any UA. Local policies will dictate this ability. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'M1' is mentioned on line 859, but not defined == Missing Reference: 'M2' is mentioned on line 925, but not defined == Missing Reference: 'RFC216' is mentioned on line 615, but not defined == Missing Reference: 'M3' is mentioned on line 863, but not defined == Unused Reference: 'RFC2616' is defined on line 1169, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 3693 ** Obsolete normative reference: RFC 2393 (ref. 'RFC2392') (Obsoleted by RFC 3173) ** Obsolete normative reference: RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) ** Obsolete normative reference: RFC 2818 (Obsoleted by RFC 9110) -- Obsolete informational reference (is this intentional?): RFC 3825 (Obsoleted by RFC 6225) Summary: 8 errors (**), 0 flaws (~~), 11 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SIP Working Group James Polk 3 Internet Draft Cisco Systems 4 Expiration: Dec 26th, 2006 Brian Rosen 5 NeuStar 7 Session Initiation Protocol Location Conveyance 8 draft-ietf-sip-location-conveyance-03.txt 9 June 26th, 2006 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six 24 months and may be updated, replaced, or obsoleted by other documents 25 at any time. It is inappropriate to use Internet-Drafts as 26 reference material or to cite them other than as "work in 27 progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on December 26th, 2006. 37 Copyright Notice 39 Copyright (C) The Internet Society (2006). 41 Abstract 43 This document defines how the Session Initiation Protocol (SIP) 44 conveys, or pushes, geographic location information from one SIP 45 entity to another SIP entity. SIP Location Conveyance is always end 46 to end, but sometimes the embedded location information can be acted 47 upon by SIP Servers to direct where the message goes, based on where 48 the user agent client is. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 53 1.1 Conventions used in this document . . . . . . . . . . . . 4 54 2. Location In the Body or in a Header . . . . . . . . . . . . . 5 55 3. Requirements for SIP Location Conveyance . . . . . . . . . . 6 56 4. Location Conveyance Using SIP . . . . . . . . . . . . . . . . 9 57 4.1 A New Option Tag and SIP Header . . . . . . . . . . . . . 11 58 4.2 424 (Bad Location Information) Response Code . . . . . . 14 59 4.3 Example PIDF-LO in Geo Format . . . . . . . . . . . . . . 15 60 4.4 Example PIDF-LO in Civic Format . . . . . . . . . . . . . 16 61 5. SIP Element Behavior When Conveying Location . . . . . . . . 17 62 5.1 Location Conveyance Using the INVITE Method . . . . . . . 17 63 5.2 Location Conveyance Using the MESSAGE Method . . . . . . 19 64 5.3 Location Conveyance Using the UPDATE Method . . . . . . . 20 65 5.4 Location Conveyance Using the REGISTER Method . . . . . . 20 66 6. Special Considerations for Emergency Calls . . . . . . . . . 20 67 7. Meeting RFC 3693 Requirements . . . . . . . . . . . . . . . . 21 68 8. Security Considerations . . . . . . . . . . . . . . . . . . . 22 69 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . 22 70 9.1 IANA Registration for the SIP Location Header . . . . . . 22 71 9.2 IANA Registration of the Location Option Tags . . . . . . 23 72 9.3 IANA Registration for Response Code 424 . . . . . . . . . 23 73 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 23 74 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 23 75 11.1 Normative References . . . . . . . . . . . . . . . . . 23 76 11.2 Informative References . . . . . . . . . . . . . . . . . 24 77 Author Information . . . . . . . . . . . . . . . . . . . . . 24 78 Appendix A. Changes from Prior Versions . . . . . . . . . . 24 79 Intellectual Property and Copyright Statements . . . . . . . 28 81 1. Introduction 83 There are several situations in which it is desired or necessary for 84 a Session Initiation Protocol (SIP) [RFC3261] user agent to convey, 85 or push its geographic Location Information (LI) from one SIP entity 86 to another. This document discusses the rules for such conveyance, 87 and includes the requirements to be met when a SIP UAC wants or 88 needs to convey its location to another SIP entity. A concept of 89 inheritance exists in which the conveyance of the location of a user 90 agent means conveying the location of a user of that user agent. 91 This is not an absolute in SIP, but applies for the pushing of 92 location using SIP. The privacy concerns of this topic are also 93 discussed, and need to meet the requirements laid out in RFC 3693 94 [RFC3693]. This document does not discuss the pulling of location 95 information from a remote element to learn that element's location. 96 This is left for a future effort. 98 Why would a SIP user agent (UA) push its location to another SIP UA? 100 There are 3 reasonable scenarios why location can be, or needs to be 101 conveyed to a remote SIP element: 103 1) to include location in a request message seeking the nearest 104 instance of destination, where there could be more than one 105 choice; (hey, here I am, I want to talk to the nearest instance 106 of you? i.e. where's the nearest Pizza Hut relative to where I 107 am now). 109 2) to push the user agent's location to a server such that it can 110 either deal with all the inquiries, leaving the UA to do other 111 tasks (Presence Server), or allow the server to return 112 information to that UAC according to what the UAC is at this 113 time. 115 3) to inform the user of another UA where the sending user is; 116 (dude, he is where I am) or (I need help, here I am) 118 Scenario #1 revolves around the idea of a user wanting to find the 119 nearest instances of something else. For example, where is the 120 nearest pizza parlor. A chain of pizza parlors may be contacted 121 through a single well known URI (sip:pizzaparlor.example.com). This 122 by itself does not solve enough to the sending UA. The server at 123 this well known URI needs to know where the nearest one is to the 124 requester. In SIP, this could be accomplished in the initial 125 message by including the location of the UAC in the Request message. 126 This allows the SIP message to be forwarded to the closest physical 127 site by the pizzaparlor.com proxy server. Additionally, the 128 receiving site's UAS uses the UAC's location to determine the 129 location your delivery. A more immediate example may be: where's 130 the nearest (car) garage repair shop, because the user of the UAC 131 has a flat tire. 133 Scenario #2 revolves around pushing the user's location information 134 to an external server to deal with all location requests in the 135 future. This leaves a buffer layer between the user and the seeker 136 of the user's location. This server would typically handle all 137 security checks and challenges of those seeking the user's location, 138 as well as handling all the processing of the location target's 139 profile rules entered into that server. This external server 140 c/would be a Presence server. This scenario will not be addressed 141 in this document because of the prevailing Presence solutions for 142 conveying location information. 144 Alternatively, a user agent pushing location to a server can allow 145 that server to provide back information pertinent to that UA's 146 location. Perhaps replying with certain information unique to the 147 country or region a mobile UA resides. This would not be possible 148 without the server knowing where the UA is. 150 Scenario #3 actually has a part A and a part B to it. Both involve 151 the UAC including its location in the request to the UAS within a 152 SIP transaction. Part A simply has the user, Alice, informing 153 another user, Bob, where she is. This could be the loan purpose 154 for this SIP message, or it could be part of another transaction - 155 in which location were merely included, such as within a call set- 156 up. 158 Part B of scenario #3 has a user, Alice, calling for help and 159 including location to inform who she's calling where she is. This 160 is where the called party needs to come bring help to. Within this 161 scenario, the UAC will need to know this is a special SIP request 162 message to include the UAC's location in this message. It is 163 envisioned that SIP elements along the path of the SIP request will 164 need to know where Alice's UA is for proper routing purposes. An 165 example of this special SIP request is an emergency call set-up. 167 While scenarios 1, 2 and 3A should use some form of SIP security, 168 typically at the wishes of the user, scenario 3B may or may not 169 involve SIP security measures. This is because including any 170 security measures may cause the SIP request to fail, and that is 171 likely not a good result. It is also conceivable that a first 172 attempt with the user's security measures enabled is tried, and if 173 there are any failures, the subsequent attempt or attempts do not 174 involve security measures. Most believe that completing the 175 emergency call is more important than protecting the information in 176 the SIP message. Obviously this is up to local and jurisdictional 177 policies, but is mentioned here as a hint of a rationale of a later 178 section of this document. 180 This document does not discuss how the UAC discovers or is 181 configured with its location. This document however will specify 182 how it meets the requirements for SIP qualifying as a "using 183 protocol" as defined in [RFC3693], in section 7. 185 Section 3 lists the requirements for SIP location conveyance. 186 Section 4 defines how SIP conveys location. Section 5 illustrates 187 specifics about location conveyance in certain SIP request messages. 188 Section 6 briefly discusses pertinent behaviors with respect to the 189 unique nature of emergency calling. Section 9 provides the security 190 considerations and Section 9 IANA registers one new SIP header, two 191 new option tags and one new 4XX Response codes. 193 The "changes from prior versions" section (the old Section 1.2) has 194 been moved to the lone appendix, as its size is getting too large 195 for efficient reading of this document. 197 1.1 Conventions used in this document 199 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 200 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and 201 "OPTIONAL" in this document are to be interpreted as described 202 in [RFC2119]. 204 2. Location In the Body or in a Header 206 In determining where "location" is placed in a SIP message, 207 consideration is taken as to where the trust model is based on the 208 architecture involved. 210 If the user agent has the location stored within it, and this user 211 agent wants to inform another user agent where it is, it seems 212 reasonable to have this accomplished by placing the location 213 information (coordinate or civic) in a message body (part), sending 214 it as part of a SIP request or response. This is location by-value. 216 No routing of the request based on the location contents is required 217 in this case, therefore no SIP Proxies between these two UAs need to 218 view the location information contained in the SIP message(s). The 219 UAC should know certain types of messages will be routed based on 220 the UA's location when creating a message. 222 RFC 3261 does not permit SIP intermediaries to modify or delete a 223 message body [RFC3261]. There is, however, no restriction on 224 intermediaries viewing message bodies. S/MIME protected message 225 bodies, implemented on bodies for end-to-end communications only 226 (i.e. between user agents), would render the location object opaque 227 to a proxy server from any viewing of the message body. 229 The location format is defined in [RFC4119] as a "Presence 230 Information Data Format - Location Object", or PIDF-LO. The amount 231 of information that is necessary to appropriately transmit location 232 information in a format that is understandable is larger than a SIP 233 header could realistically include. However, there must be a means 234 for both a UAC to include a reference point to where location can be 235 retrieved from a remote server, and in some cases, for a SIP server 236 to add a UAC's location to a SIP message as it is processed 237 by that element. This must be in a SIP header for the above stated 238 reason, and should therefore be in a compact form. A URI satisfies 239 this description. This is location-by-reference. 241 The idea of Location-by-Reference is to allow a UA to store its 242 location on a remote node, to be retrieved by who has this URI. 243 This concept allows the remote node to use its processing power to 244 handle all policy rule operations the user wants performed per 245 request, and all security challenges done as well. 247 Since location in a message body may be opaque to a routing element, 248 message needing to be routed based on the UAC's location should not 249 have said location in the message body where it may not be seen. A 250 UAC's Location in these cases should be in the Location header where 251 it can be dereferenced by a (SIP) routing element. 253 [RFC3693] prefers S/MIME for confidentiality and integrity of 254 Location Information on an end-to-end basis, and indeed S/MIME is 255 preferable in SIP [RFC3261] for protecting a message body. 257 Accordingly, this document specifies location be carried in a body 258 when it is known to/stored in a user agent for end-to-end conveyance 259 of location. The use of SIPS [RFC3261] is orthogonal to this 260 discussion and should always be used. 262 It is conceivable that an initial attempt to communicate with 263 location included may fail due to the security measures used. 264 Subsequent requests ought to use less security. For example, if an 265 initial request used S/MIME and failed. A subsequent request could 266 downgrade the security measures used to that of TLS. A message may 267 be important enough, say an emergency call attempt, where TLS is not 268 used. This should not be a default configuration, but a fallback 269 usage. This is always a matter for local and jurisdictional policy. 271 3. Requirements for SIP Location Conveyance 273 The following subsections address the requirements placed on the 274 user agent client, the user agent server, as well as SIP proxies 275 when conveying location. 277 3.1 Requirements for a UAC Conveying Location 279 The following are the requirements for location conveyance by a user 280 agent client. There is a motivational statement below each 281 requirements that is not obvious in intent. 283 UAC-1 The SIP INVITE Method [RFC3261] MUST support Location 284 Conveyance. 286 UAC-2 The SIP MESSAGE method [RFC3428] MUST support Location 287 Conveyance. 289 UAC-3 SIP Requests within a dialog SHOULD support Location 290 Conveyance. 292 UAC-4 Other SIP Requests MAY support Location Conveyance. 294 UAC-5 There MUST be one, mandatory to implement means of 295 transmitting location confidentially. 297 Motivation: interoperability 299 UAC-6 It MUST be possible for a UAC to update location conveyed 300 at any time in a dialog, including during dialog 301 establishment. 303 Motivation: in case a UAC has moved prior to the establishment of a 304 dialog between UAs, the UAC must be able to send new location 305 information. In the case of location having been conveyed, 306 and the UA moves, it needs a means to update the conveyed to 307 party of this location change. 309 UAC-7 The privacy and security rules established within [RFC3693] 310 that would categorize SIP as a 'using protocol' MUST be met. 311 See Section 7 for analysis. 313 UAC-8 The PIDF-LO [RFC4119] is a mandatory to implement format for 314 location conveyance within SIP, whether included by-value or 315 by-reference. 317 If location is within the message, it is a PIDF-LO by-value in a 318 message body (part). If location is stored on an external node, it 319 is dereferenced as a PIDF-LO. 321 Motivation: interoperability 323 UAC-9 A UAC MUST be capable of transmitting a SIP request without 324 protecting the PIDF-LO message body. It is RECOMMENDED this 325 not be the default configuration of any UA. This requirement 326 is orthogonal to the use of TLS or IPSec hop-by-hop between 327 SIP elements. 329 Motivation: If a SIP request is part of an emergency call, 330 therefore includes the UAC's location, the UAC may understand 331 through local policy or configuration that a proxy server 332 will need to learn the UAC's location to route the message 333 correctly. Using S/MIME on the PIDF-LO defeats this 334 capability in proxies. 336 UAC-10 A UAC MUST allow its user to be able to disable providing 337 location within any SIP request message. It is RECOMMENDED 338 this not is the default configuration of any UA. 340 Motivation: local laws may give this right to all users within a 341 jurisdiction, even when the request is initiating an 342 emergency call. 344 UAC-11 A UAC SHOULD NOT use the Proxy-Require header indicating a 345 SIP intermediary is required to act upon location within a 346 SIP message. 348 Motivation: This is because it is not expected that all SIP 349 elements will understand location, therefore the chances of a 350 message failure is high if proxies are required to support 351 location before forwarding a message. This will lead to 352 unnecessary message failures. 354 3.2 Requirements for a UAS Receiving Location 356 The following are the requirements for location conveyance by a user 357 agent server: 359 UAS-1 SIP Responses MUST support Location Conveyance. 361 UAS-2 There MUST be one, mandatory to implement means of 362 receiving location confidentially. 364 Motivation: interoperability 366 UAS-3 The PIDF-LO [RFC4119] is a mandatory to implement format for 367 location conveyance within SIP, whether included by-value or 368 by-reference. 370 If location is within the message, it is a PIDF-LO by-value in a 371 message body (part). If location is stored on an external node, it 372 is dereferenced as a PIDF-LO. 374 Motivation: interoperability 376 UAS-4 There MUST be a unique 4XX error response code informing 377 the UAC it did not provide applicable location information. 379 UAS-5 UASs MUST be prepared to receive location without privacy 380 mechanisms enabled. It is RECOMMENDED this not be the 381 default configuration of any UA, however, this MUST be 382 possible for local laws that require this function. 384 Motivation: Because a SIP request can fail in transit for security 385 reasons, UACs are allowed to transmit, or retransmit requests 386 including location without any security mechanisms utilized, 387 even when this SIP transaction is an emergency call. UAs 388 must be prepared to receive the messages without confidential 389 location. 391 UAS-6 There MUST be a unique 4XX error response code informing the 392 UAC it did not provide applicable location information. 394 3.3 Requirements for SIP Proxies and Intermediaries 396 The following are the requirements for location conveyance by a SIP 397 proxies and intermediaries: 399 Proxy-1 Proxy servers MUST NOT modify or remove a location 400 message body part, and SHOULD NOT modify or remove a 401 location header or location header value. 403 Motivation: [RFC3261] forbids the removal of a message body part, 404 and the proxy may not have all the relevant information as 405 to why location was included in this message (meaning it 406 might need to be there), and should not remove this 407 critical piece of information. 409 Proxy-2 Proxy servers MUST be capable of adding a Location header 410 during processing of SIP requests. 412 Motivation: If the proxy determines a message needs to have the 413 location of the UAC in the message, and knows the UAC's 414 location by-reference, it must be able to add this header 415 and URI to the message during processing. This SHOULD NOT 416 violate requirement Proxy-3 below. 418 Proxy-3 If a Proxy server detects "location" already exists within 419 a SIP message, it SHOULD NOT add another location header or 420 location body to the message. 422 Motivation: This may lead to confusion downstream. Section 4.1 423 explains this more. 425 Proxy-4 There MUST be a unique 4XX error response code informing 426 the UAC it did not provide applicable location information. 428 4. Location Conveyance Using SIP 430 RFC 4119 defines the PIDF-LO location object to be inside a RFC 3693 431 defined "using protocol" message from one entity to another entity. 432 For SIP location conveyance, using the PIDF-LO body satisfies the 433 entire format and message-handling requirements as stated in the 434 baseline Geopriv Requirements [RFC3693]. 436 Although a PIDF-LO is to be used to indicate location of a UA, the 437 actual PIDF-LO does not need to be contained in the message itself, 438 it can be as a by-reference URI in a SIP header or message body 439 part, pointing to the PIDF-LO of that UA on a remote node. 441 The basic operation of location conveyance is as easy as this in 442 Figure 1., showing a user agent conveying its location to another 443 user agent: 445 UA Alice UA Bob 447 | [M1] Request (w/ Location) | 448 |---------------------------------->| 449 | [M2] Response | 450 |<----------------------------------| 451 | | 453 Figure 1. Basic SIP Location Conveyance 455 Alice wants to inform Bob where she is. She includes location 456 by-value (in a message body) or by-reference (in a new Location 457 header) in her request message towards Bob. Bob MAY choose to 458 include his location in a response back to Alice. 460 Another usage of location conveyance is for a SIP Server route the 461 SIP request message based on included location information, by-value 462 or by-reference, to an appropriate destination. Figure 2 shows this 463 message flow to UAS-B, because that is determined to be the 464 appropriate destination for this message, based on the location of 465 Alice. 467 UA Alice SIP Server UAS-A UAS-B UAS-C 469 | [M1] Request (w/ Location) | | | | 470 |---------------------------->| | | | 471 | | | 472 | |----------------->| 473 | | | 474 | [M2] Response | 475 |<-----------------------------------------------| 476 | | 478 Figure 2. Message Routing based on Location Information 480 How a SIP Server would route a message based on the location in a 481 SIP message is out of scope for this document. But in Figure 2, 482 Alice's message could go to one of three destinations, with the SIP 483 server choosing destination B based on Alice's location. 485 A use-case for Figure 2 could be one in which Alice wants a pizza 486 delivered to her location, wherever she is. She calls her favorite 487 pizza store chain's main address, perhaps this is a single, national 488 URI, with her included location determining which specific store 489 this SIP request is routed to. In such a use-case, Alice can use 490 the same URI wherever she is to contact the same store chain she 491 prefers; never needing to look up the specifics of which store is 492 closest in a unfamiliar city. 494 Another use-case is emergency calling, in which the location of the 495 caller is the key trigger as to which emergency response center 496 receives this SIP request. 498 Because a person's location is generally considered to be sensitive 499 in nature, certain security measures need to be taken into account 500 when transmitting such information. Section 26 of [RFC3261] defines 501 the security functionality SIPS for transporting SIP messages with 502 either TLS or IPSec, and S/MIME for encrypting message bodies from 503 SIP intermediaries that would otherwise have access to reading the 504 clear-text bodies. SIP endpoints SHOULD implement S/MIME to encrypt 505 the PIDF-LO message body (part) end-to-end. The SIPS-URI from 506 [RFC3261] MUST be implemented for message protection (message 507 integrity and confidentiality) and SHOULD be used when S/MIME is not 508 used. 510 The entities sending and receiving location MUST obey the privacy 511 and security rules in the PIDF-LO, regarding retransmission and 512 retention, to be compliant with this specification. 514 Self-signed certificates SHOULD NOT be used for protecting PIDF-LO, 515 as the sender does not have a secure identity of the recipient. 517 More than one location representation or format MAY be included in 518 the same message body part, but all MUST point at the same position 519 on the earth (altitude not withstanding), as this would confuse the 520 recipient by pointing at more than one position within the same 521 message body part. There MAY be a case in which part or parts of 522 one location format and part or parts of another format exist in the 523 same message body part. These complementary pieces of information 524 MUST point at the same position on the earth, yet are incomplete 525 within their own format. For example, there maybe be a latitude and 526 longitude in coordinate format and a civic altitude value to 527 complete a 3-dimensional position of a thing (i.e. which floor of a 528 building the UA is on in a building at a particular lat/long 529 coordinates pair). 531 There MAY be more than one PIDF-LO in the same SIP message, but each 532 in separate message body parts. Each location body part MAY point at 533 different positions on the earth (altitude not withstanding). If 534 the message length exceeds the maximum message length of a single 535 packet (1300 bytes), TCP MUST to be used for proper message 536 fragmentation and reassembly. 538 Several push-based SIP Request Methods are capable (and applicable) 539 of carrying location, including: 541 INVITE, 542 REGISTER, 543 UPDATE, and 544 MESSAGE, 546 While the authors do not yet see a reason to have location conveyed 547 in the ACK, PRACK, BYE, REFER and CANCEL Methods, we do not see a 548 reason to prevent carrying a PIDF-LO within these Method Requests as 549 long as the SIP message meets the requirements stated within this 550 document. Discussing Location in the PUBLISH Request Method will be 551 for another document. 553 SIP Methods such as SUBSCRIBE and NOTIFY are considered a pull-based 554 location retrieval mechanism, and are therefore not part of this 555 document. 557 A 200 OK to a SIP Request MAY carry the UAS's PIDF-LO back to the 558 UAC that provided its location in the original request, but this is 559 not something that can be required due to the timing of the request 560 to 200 OK messages, with potential local/user policy requiring the 561 called user to get involved in determining if the caller is someone 562 they wish to give their location to (and at what precision). 564 4.1 A New Option Tag and SIP Header 566 This document creates and IANA registers one new option tag: 567 "location". This option tag is to be used, per RFC 3261 in the 568 Require, Supported and Unsupported headers. Whenever a UA wants to 569 indicate it understands this SIP extension, the location option tag 570 is included in a Supported header of the SIP message. 572 This option tag SHOULD NOT be used in the Proxy-Require header. 574 This document also creates and IANA registers a new SIP header: 575 Location. The Location header, if present, will have one of two 576 header values defined by this document: 578 o a Location-by-reference URI 580 o a Content-ID indicating where location is within the message body 582 A location-by-reference URI is a pointer to a record on a remote 583 node containing the PIDF-LO of a UA. 585 If the PIDF-LO of a UA is contained in a SIP message, a Location 586 header will be present in the message with a content-ID (cid-url) 587 [RFC2392] indicating which message body part contains location for 588 this UA. This is to aid a node in not having to parse the whole 589 message body or body parts looking for this body type. 591 The purpose of the Location option-tag is to indicate support for 592 this document in the Require, Supported and Unsupported headers. 593 It gives a UAS the proper means to indicate it does not support the 594 concept of location in an Unsupported header in a response message 595 that might otherwise not be clear that the lack of support for 596 location is the problem with the request message. 598 The presence of the Location option tag in a Supported header 599 without a Location header in the same message informs a receiving 600 SIP element the UAC understands the concept of location, but it does 601 not know its location at this time. 603 The new "Location" header has the following BNF syntax: 605 Location = "Location" HCOLON (locationURI *(COMMA 606 locationURI)) 607 locationURI = absoluteURI / cidURI 608 cidURI = "cid:" content-id 610 content-id = addr-spec ; URL encoding of RFC3261 addr-spec 612 The content-ID (cid:) is defined in [RFC2392] to locate message body 613 parts. This MUST be present if location is by-value in a message. 615 It is envisioned that HTTP, through the http_URL in [RFC216], and 616 HTTPS [RFC2818] MAY be used to dereference a location-by-reference 617 PIDF-LO. 619 The following table extends the values in Table 2&3 of RFC3261 620 [RFC3261]. 622 Header field where proxy INV ACK CAN BYE REG OPT PRA 623 ---------------------------------------------------------------- 624 Location Rr ar o - - o o o - 626 Header field where proxy SUB NOT UPD MSG REF INF PUB 627 ---------------------------------------------------------------- 628 Location Rr ar - - o o o o - 630 The Location header MAY be added to, or read if present in, a 631 request message listed above. A proxy MAY add the Location header 632 in transit if one is not present. [RFC3261] states message bodies 633 cannot be added by proxies. A proxy MAY read the location header in 634 transit if present, and MAY use the contents of the location header 635 to make message routing decisions. 637 It is RECOMMENDED that only one Location header be in the same 638 message, but this is not mandatory. That said, there MUST NOT be 639 more than one cid-url pointing to the same location message body 640 (part) in a SIP message, regardless of how many Location headers 641 there are in that message. 643 As of the writing of this document, there is no means in a PIDF-LO 644 to indicate which element generated that PIDF-LO. There is a means 645 of indicating what the subject of the location information is within 646 a PIDF-LO. Meaning, if more than one location, by-value and/or 647 by-reference is included in a message, the recipient, whether 648 intermediary or destination, will not know which location entry was 649 inserted by which element. This can lead to confusion in some 650 cases. Therefore, it is RECOMMENDED that there be a single location 651 representation referring to the same target/subject in a SIP 652 message. This PIDF-LO generation indication may be fixed in the 653 future, resolving this limitation, but that is not part of the scope 654 of this document. 656 Here is an example INVITE request message that includes the proper 657 Location and Supported headers: 659 INVITE sip:bob@biloxi.example.com SIP/2.0 660 Via: SIP/2.0/TCP pc33.atlanta.example.com 661 ;branch=z9hG4bK74bf9 662 Max-Forwards: 70 663 To: Bob 664 From: Alice ;tag=9fxced76sl 665 Call-ID: 3848276298220188511@atlanta.example.com 666 Location: cid:alice123@atlanta.example.com 667 Supported: location 668 Accept: application/sdp, application/pidf+xml 669 CSeq: 31862 INVITE 670 Contact: 671 Content-Type: multipart/mixed; boundary=boundary1 672 Content-Length: ... 674 --boundary1 676 Content-Type: application/sdp 678 ...SDP here 680 --boundary1 682 Content-Type: application/pidf+xml 683 Content-ID: alice123@atlanta.example.com 685 ...PIDF-LO here 687 --boundary1-- 689 The Location header from the above INVITE: 691 Location: cid:alice123@atlanta.example.com 693 indicates the Content-ID location [RFC2392] within the multipart 694 message body of were location information is. 696 If the Location header were this instead: 698 Location: 700 this would indicate location by-reference was included in this 701 message. It is expected that any node wanting to know where user 702 alice123 is would fetch (dereference) the PIDF-LO from the server 703 URI. 705 4.2 424 (Bad Location Information) Response Code 707 In the case that a UAS or SIP intermediary detects an error 708 in a request message specific to the location information supplied 709 by-value or by-reference, a new 4XX level error is created here to 710 indicate this is the problem with the request message. This 711 document creates the new error code: 713 424 (Bad Location Information) 715 The 424 (Bad Location Information) response code is a rejection of 716 the location contents, whether by-value or by-reference of the 717 original SIP Request. The server function of the recipient (UAS or 718 intermediary) has deemed this location by-reference or location by- 719 value to be bad. No further action by the UAC is required. The UAC 720 can use whatever means it knows of to verify/refresh its location 721 information before attempting a new request that includes location. 722 There is no cross-transaction awareness expected by either the UAS 723 or SIP intermediary as a result of this error message. 725 This new error code will be IANA registered in Section 9. 727 4.3 Example PIDF-LO in Geo Format 729 This subsection will show a sample of what just the PIDF-LO can look 730 like, as defined in [RFC4119]. Having this here will first offer a 731 look at a location by-value message body, and secondly, give readers 732 an appreciation for how large a location message body is. This 733 section shows a coordinate position based PIDF-LO. Section 4.4 734 shows this same position in a civic address format. Full example 735 message flows will be left for another document. 737 Whether this PIDF-LO message body is S/MIME encrypted in the SIP 738 message or not, the PIDF-LO stays exactly the same. There is no 739 change to its format, text or characteristics. Whether TLS or IPSec 740 is used to encrypt this overall SIP message or not, the PIDF-LO 741 stays exactly the same. There is no change to its format, text or 742 characteristics. The examples in section 4.3 (Geo format) taken 743 from [RFC3825] and 4.4 (Civic format) taken from [ID-CIVIC] are for 744 the exact same position on the Earth. The differences between the 745 two formats is within the are of the examples. 746 Other than this portion, of each PIDF-LO, the rest the same for both 747 location formats. 749 750 755 756 2006-03-20T14:00:00Z 757 758 759 760 761 762 33.001111N 763 96.68142W 764 765 766 767 768 no 769 2006-03-24T18:00:00Z 771 DHCP 772 www.cisco.com 773 774 775 776 777 779 4.4 Example PIDF-LO in Civic Format 781 This subsection will show a sample of what just the PIDF-LO can look 782 like, as defined in [RFC4119]. Having this here will first offer a 783 look at a location by-value message body, and secondly, give readers 784 an appreciation for how large a location message body. This section 785 shows a civic address based PIDF-LO. Section 4.3 shows this same 786 position in a coordinate format. Full example message flows will be 787 left for another document. 789 Whether this PIDF-LO message body is S/MIME encrypted in the SIP 790 message or not, the PIDF-LO stays exactly the same. There is no 791 change to its format, text or characteristics. Whether TLS or IPSec 792 is used to encrypt this overall SIP message or not, the PIDF-LO 793 stays exactly the same. There is no change to its format, text or 794 characteristics. The examples in section 4.3 (Geo format) taken 795 from [RFC3825] and 4.4 (Civic format) taken from [ID-CIVIC] are for 796 the exact same position on the Earth. The differences between the 797 two formats is within the are of the examples. 798 Other than this portion, of each PIDF-LO, the rest the same for both 799 location formats. 801 802 807 808 2006-03-20T14:00:00Z 809 810 811 812 813 US 814 Texas 815 Colleyville 816 3913 817 Treemont 818 Circle 819 76034 820 Polk Place 821 1 822 823 824 825 no 826 2006-03-24T18:00:00Z 828 DHCP 829 www.cisco.com 830 831 832 833 834 836 5. SIP Element Behavior When Conveying Location 838 This specification includes requirements for the conveyance of 839 location information in the INVITE, REGISTER, UPDATE, and MESSAGE 840 request methods. The mechanisms within this specification could 841 presumably be used in other SIP requests types. However, since there 842 currently are no agreed upon requirement(s) for conveying location 843 in other request types, this specification only describes location 844 conveyance in the four request methods mentioned here. 846 The message flows in this document will be example messages 847 containing only the key headers to convey the point being made that 848 do not include all the requisite SIP headers. All well formed SIP 849 message flows are to be in a separate document for brevity here. 851 5.1 Location Conveyance Using the INVITE Method 853 Below is a common SIP session set-up sequence between two user 854 agents. In this example, Alice will provide Bob with her location 855 in the INVITE message. 857 UA Alice UA Bob 859 | [M1] INVITE | 860 |---------------------------------------->| 861 | [M2] 200 OK | 862 |<----------------------------------------| 863 | [M3] ACK | 864 |---------------------------------------->| 865 | RTP | 866 |<=======================================>| 867 | | 869 Figure 3. Location Conveyance in INVITE Requests 871 User agent Alice invites user agent Bob to a session [M1 of Figure 872 1]. 874 INVITE sips:bob@biloxi.example.com SIP/2.0 875 To: Bob 876 From: Alice ;tag=1928301774 877 Supported: Location 878 Location: cid:alice123@atlanta.example.com 880 If the message were S/MIME encrypted, this would be the Content-type 881 header: 883 Content-Type: application/pkcs7-mime; 884 smime-type=enveloped-data; name=smime.p7m 886 If this INVITE were not S/MIME encrypted, this would be the 887 Content-Type header: 889 Content-Type: multipart/mixed; boundary=boundary1 891 The obvious reason this for a multipart/mixed Content-Type is that 892 this is an INVITE message and there is an SDP message body part 893 included. This is not mandatory, but highly likely. The cid-url in 894 the Location header points a parsing entity that can view the 895 message body to where the PIDF-LO is in the message. 897 Within the non-S/MIME message body is this: 899 --boundary1 901 Content-Type: application/sdp 903 v=0 904 ... 906 --boundary1 908 Content-type: application/pidf+xml 910 PIDF-LO 912 --boundary1-- 914 In the INVITE, Alice's UAC included the Supported header with the 915 location option tag, and the Location header with the cid:url 916 pointing at the by-value PIDF-LO. These two headers MAY be hidden 917 in the S/MIME encrypted message body next to the topmost 918 Content-Type header to hide the fact that this message is carrying 919 location in transit. Bob's UAS, the destination UA of Alice's 920 message, will read these headers when deciphering the overall 921 message body. 923 - If Bob's UA wants to join the call, his UA responses with a 200 OK 925 [M2]. Bob can include his location in the 200 OK response, but 926 this shouldn't be expected to due to user timing. 928 A 424 (Bad Location Information) Response is the proper response if 929 Bob's UA understands this SIP extension (location), but somehow 930 determines the supplied location information is bad. 932 [Alternative M2(1) of Figure 3] 933 SIP/2.0 424 Bad Location Information 934 To: Bob 935 From: Alice ;tag=1928301774 937 The 424 is expected to be more commonly sent by SIP intermediaries 938 along the path between Alice and Bob, than from Bob's UA. 940 - If Bob's UA accepts with a 200 OK message, Alice's UA replies with 941 an ACK and the session is set up. 943 - If Bob's UA does not accept the INVITE for reasons other than 944 location included, a 488 (Not Acceptable Here) may be the 945 response. 947 Figure 3 does not include any Proxies because in it assumed they 948 would not affect the session set-up with respect to whether or not 949 Alice's location is in a message body part, and Proxies do not react 950 to S/MIME encrypted bodies, making their inclusion more or less moot 951 and asking for more complex message flows than necessary here. 953 If Alice included a Require header such as this: 955 Require: Location 957 and Bob did not understand this SIP extension, Bob's appropriate 958 response would be a 420 (Bad Extension) with an Unsupported header 959 containing the Location option tag. This is shown below as an 960 alternative (2) to M2 in Figure 3. 962 [Alternative M2(2) of Figure 3] 963 SIP/2.0 420 Bad Extension 964 To: Bob 965 From: Alice ;tag=1928301774 966 Unsupported: location 968 5.2 Location Conveyance Using the MESSAGE Method 970 There are no additional rules regarding conveying location in a 971 MESSAGE request verses an INVITE request. 973 5.3 Location Conveyance Using the UPDATE Method 975 The UPDATE Method [RFC3311] is to be used any time location 976 information is to be updated between UAs setting up a dialog or 977 after the dialog has been established, no matter how long that 978 dialog has been operational. reINVITE is inappropriate here, and 979 the MESSAGE Method is for non-dialog location conveyance between UAs 980 only. The same security properties used in the INVITE MUST be 981 applied in the UPDATE message. 983 There are 3 conditions UPDATE is used to convey location between 984 UAs: 986 1) During dialog establishment, but before the final 200 OK 988 2) After dialog establishment, but no prior location information has 989 been convey, and 991 3) After dialog establishment, when a UA has determined it has moved 992 (not specified here) 994 There are no additional rules regarding conveying location in a 995 UPDATE request verses an INVITE request. 997 5.4 Location Conveyance Using the REGISTER Method 999 Alice's user agent MAY choose to communicate its location during 1000 registration, the REGISTER Method is used here. This MAY be done to 1001 inform the Registrar server where this UA is to provide it a 1002 customized response based on the particulars of UAs in that 1003 jurisdiction. To indicate to a Registrar Server a UAC supports this 1004 SIP extension, but does not include location in the message, 1005 including a Supported header with a location option tag does this. 1006 Either transaction SHOULD an appropriate confidentiality mechanism. 1008 6. Special Considerations for Emergency Calls 1010 Emergency calling, such as 911, 112 and 999 calling today, 1011 necessitates a UAC to understand the type of call it is about to 1012 initiate with an INVITE message to a PSAP. First of all, the 1013 purpose of calling for emergency help is to get someone to respond 1014 to the UAC's location, therefore, location MUST be included in the 1015 INVITE, if known by the UAC. If the UAC understands this, but does 1016 not know its location at this time, it MUST include the location 1017 option tag in the Supported header, and MUST NOT include the 1018 Location header, as it would not have anything to put as a header 1019 value. 1021 The emergency services community strongly prefers that message 1022 routing occur in the network with the freshest available Public 1023 Safety Answering Point (PSAP) information. Message routing, in this 1024 context, means choosing which SIP(S)-URI to place in the Request-URI 1025 field of the status line. 1027 If a UAC knows it is generating an emergency request towards a PSAP, 1028 there MAY be unique message handling characteristics that diminish 1029 the level of confidentiality of the location information within the 1030 SIP message(s). This is because emergency call routing requires 1031 proxies to know the location of the message originating UAC in order 1032 to make a decision on where to route the message. This is because 1033 emergency calls are directed to the PSAP local to the caller's 1034 location. A proxy performing this function requires that proxy to 1035 learn the location of the UAC during message processing. 1037 How a message is routed based on the location of the UAC, and if and 1038 by how much the level of confidentiality of location information is 1039 diminished when calling for emergency help are both out of scope of 1040 this document. 1042 Hop-by-hop confidentiality mechanisms, as defined in [RFC3261] MUST 1043 be initially attempted by a UAC that includes location. Local 1044 configuration MAY allow a subsequent retry, after a security related 1045 failure, to be without hop-by-hop confidentiality. SIP elements 1046 MUST obey the rules set forth in [RFC3261] regarding maintaining 1047 hop-by-hop confidentiality when a message using a SIPS-URI. If a 1048 UAC retries an emergency request as the result of a 424 (Bad 1049 Location) response, that new request MUST NOT include message body 1050 encryption. Further details of emergency request messages are left 1051 to future work to define. 1053 While many jurisdictions force a user to reveal their location 1054 during an emergency call set-up, there is a small, but real, number 1055 of jurisdictions that allow a user to configure their calling device 1056 to disable providing location, even during emergency calling. This 1057 capability MUST be configurable, but is not RECOMMENDED as the 1058 default configuration of any UA. Local policies will dictate this 1059 ability. 1061 7. Meeting RFC3693 Requirements 1063 Section 7.2 of [RFC3693] details the requirements of a "using 1064 protocol". They are: 1066 Req. 4. The using protocol has to obey the privacy and security 1067 instructions coded in the Location Object and in the 1068 corresponding Rules regarding the transmission and storage of the 1069 LO. 1071 This document requires, in Section 3, that SIP entities sending or 1072 receiving location MUST obey such instructions. 1074 Req. 5. The using protocol will typically facilitate that the keys 1075 associated with the credentials are transported to the respective 1076 parties, that is, key establishment is the responsibility of the 1077 using protocol. 1079 [RFC3261] and the documents it references define the key establish 1080 mechanisms. 1082 Req. 6. (Single Message Transfer) In particular, for tracking of 1083 small target devices, the design should allow a single 1084 message/packet transmission of location as a complete 1085 transaction. 1087 This document specifies that the LO be contained in the body of a 1088 single message, which may be fragmented via TCP, but is still not a 1089 streaming delivery. 1091 8. Security Considerations 1093 Conveyance of physical location of a UAC is problematic for many 1094 reasons. This document calls for that conveyance to normally be 1095 accomplished through secure message body means (like S/MIME or TLS). 1096 In cases where a session set-up is routed based on the location of 1097 the UAC initiating the session or SIP MESSAGE, securing the location 1098 with an end-to-end mechanism such as S/MIME is problematic, due to 1099 the probability of a proxy from requiring the ability to read that 1100 information to route the message appropriately. This means the use 1101 of S/MIME may not be possible. This leaves location information of 1102 the caller available in each proxy through to the PSAP. This may 1103 not be a perfect solution, but may be a pill we need to swallow to 1104 enable this functionality. 1106 A bad implementation of SIP location conveyance would have a UAC 1107 send location in cleartext, without hop-by-hop confidentiality, or 1108 have any SIP element along the path towards the PSAP alter the 1109 transport of any message carrying location to be without hop-by-hop 1110 confidentiality between elements. The latter would be in clear 1111 violation of RFC3261 rules surrounding the use of a SIPS-URI. 1113 9. IANA Considerations 1115 This section defines one new SIP header, one new option tag, and 1116 one new 4XX error response code within the sip-parameters section of 1117 IANA. [NOTE: RFC XXXX denotes this document]. 1119 9.1 IANA Registration for the SIP Location Header 1121 The SIP Location header is created by this document, with its 1122 definition and rules in Section 4 of this document. 1124 9.2 IANA Registration for New SIP Option Tag 1126 The SIP option tag "Location" is created by this document, with the 1127 definition and rule in Section 4 of this document. 1129 9.3 IANA Registration for Response Code 4XX 1131 Reference: RFC-XXXX (i.e. this document) 1132 Response code: 424 1133 Default reason phrase: Bad Location Information 1135 This SIP Response code is defined in section 4.2 of this document. 1137 10. Acknowledgements 1139 To Dave Oran for helping to shape this idea. To Jon Peterson and 1140 Dean Willis on guidance of the effort. To Henning Schulzrinne, 1141 Jonathan Rosenberg, Dick Knight, Mike Hammer, Paul Kyzivat, 1142 Jean-Francois Mule, Hannes Tschofenig, Marc Linsner, Jeroen van 1143 Bemmel and Keith Drage for constructive feedback. 1145 11. References 1147 11.1 References - Normative 1149 [RFC3261] J. Rosenberg, H. Schulzrinne, G. Camarillo, A. Johnston, J. 1150 Peterson, R. Sparks, M. Handley, and E. Schooler, "SIP: 1151 Session Initiation Protocol", RFC 3261, May 2002. 1153 [RFC3693] J. Cuellar, J. Morris, D. Mulligan, J. Peterson. J. Polk, 1154 "Geopriv Requirements", RFC 3693, February 2004 1156 [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate 1157 Requirement Levels", RFC 2119, March 1997 1159 [RFC4119] J. Peterson, "draft-ietf-geopriv-pidf-lo-03", Internet 1160 Draft, Sept 2004, work in progress 1162 [RFC3428] B. Campbell, Ed., J. Rosenberg, H. Schulzrinne, C. Huitema, 1163 D. Gurle, "Session Initiation Protocol (SIP) Extension for 1164 Instant Messaging" , RFC 3428, December 2002 1166 [RFC2392] E. Levinson, " Content-ID and Message-ID Uniform Resource 1167 Locators", RFC 2393, August 1998 1169 [RFC2616] R. Fielding, J. Gettys, J., Mogul, H. Frystyk, L., 1170 Masinter, P. Leach, T. Berners-Lee, "Hypertext Transfer 1171 Protocol - HTTP/1.1", RFC 2616, June 1999 1173 [RFC2818] E. Rescorla, "HTTP Over TLS", RFC 2818, May 2000 1175 [RFC3311] J. Rosenberg, "The Session Initiation Protocol (SIP) UPDATE 1176 Method", RFC 3311, October 2002 1178 11.2 References - Informative 1180 [RFC3825] J. Polk, J. Schnizlein, M. Linsner, "Dynamic Host 1181 Configuration Protocol Option for Coordinate-based Location 1182 Configuration Information", RFC 3825, July 2004 1184 [ID-CIVIC] H. Schulzrinne, " Dynamic Host Configuration Protocol 1185 (DHCPv4 and DHCPv6) Option for Civic Addresses Configuration 1186 Information ", draft-ietf-geopriv-dhcp-civil-09, "work in 1187 progress", January 2006 1189 Author Information 1191 James Polk 1192 Cisco Systems 1193 3913 Treemont Circle 33.00111N 1194 Colleyville, Texas 76034 96.68142W 1196 Phone: +1-817-271-3552 1197 Email: jmpolk@cisco.com 1199 Brian Rosen 1200 470 Conrad Dr. 40.70497N 1201 Mars, PA 16046 80.01252W 1202 US 1204 Phone: +1 724 382 1051 1205 Email: br@brianrosen.net 1207 Appendix A. Changes from Prior Versions 1209 [NOTE TO RFC-EDITOR: If this document is to be published as an RFC, 1210 this Appendix is to be removed prior to that event.] 1212 This is a list of the changes that have been made from the SIP WG 1213 version -02 to this version -03: 1215 - general clean-up of some of the sections 1217 - removed the message examples from the UPDATE, MESSAGE and REGISTER 1218 sections, as these seemed to be making the doc less readable, and 1219 not more readable 1221 - removed the "unknown" option tag, as it was not needed with a 1222 certain combination of the Supported and Location headers 1224 - clarified the location option tag usage in Supported, Require, 1225 Unsupported, and that it shouldn't be used in Proxy-Require, and 1226 why not. 1228 - Added a basic message flow to the basic operation section (Section 1229 4) to aid in understanding of this SIP extension. 1231 - Added a message routing flow, which is based on the location of 1232 the requestor to show how a SIP server can make a routing decision 1233 to a destination based on where the UAC is. 1235 - Articulated how a UAS concludes a UAC understands this extension, 1236 yet does not know its location to provide to the UAS. This is 1237 helpful in those times where an intermediary will act differently 1238 based on whether or not a UAC understands this extension, and 1239 whether or not the UAC includes its location in the request. 1241 - Corrected the erroneous text regarding an Unsupported header being 1242 in a 424 response. It belongs in a 420 response. (Section 5.1) 1244 - Corrected the BNF (I hope) 1246 - Corrected some text in Section 5 that read like this document was 1247 an update to RFC 3261. 1249 This is a list of the changes that have been made from the SIP WG 1250 version -01 to this version -02: 1252 - streamlined the doc by removing text (ultimately removing 42 pages 1253 of text). 1255 - Limited the scope of this document to SIP conveyance, meaning only 1256 how SIP can push location information. 1258 - reduced emergency calling text to just a few paragraphs now that 1259 the ECRIT WG is taking most of that topic on. 1261 - greatly reduced the number of requirements in this version. 1263 - changed the requirements groups from "UA-to-UA", "UA-to-Proxy", 1264 etc to "UAC Reqs", "UAS-Reqs" and "Proxy-Reqs" to focus on what is 1265 being asked of each SIP element. 1267 - Removed the full SIP message examples. 1269 - completed the ABNF for the Location header, including a cid-url to 1270 point at a message body part to help in parsing for location. 1272 - Deleted the call for a new 425 (Retry Location) response code, as 1273 it appears this can easily be used to spoof a UA into providing 1274 where it is inadvertently, even if the intent is legitimate by the 1275 UAC. 1277 This is a list of the changes that have been made from the SIP WG 1278 version -00 to this version -01: 1280 - cleaned up a lot of loose ends in the text 1282 - created a new Location header to convey many means (location is in 1283 the body - even if not viewable, which location format is present, 1284 which format is requested in a query, how to request more than one 1285 location format in a query, whether the UAC understands location 1286 at all, if the UA knows its location, how to push location from 1287 one UA to through a second to a third UA, etc). 1289 - added the ability to convey location by-reference, but only under 1290 certain conditions. 1292 - Added support for the OPTIONS Request to query a server for the 1293 UAC's location, through the use of the new Location header. 1295 - moved both new Response code sections forward in the document for 1296 their meaning to be clearer, earlier for necessary discussion. 1298 - Changed the message flows to only have the pertinent message 1299 headers shown for brevity. 1301 - Added text to the SUB/NOT section showing how and why the location 1302 of a UA can be refreshed or updated with an interval, or by a 1303 trigger. 1305 This is a list of the changes that have been made from the SIPPING 1306 WG version -02 to this SIP WG item document version -00: 1308 - Changed which WG this document is in from SIPPING to SIP due to 1309 the extension of the protocol with new Response codes (424 and 1310 425) for when there is an error involving the LO message body. 1312 - Moved most of the well formed SIP messages out of the main body of 1313 this document and into separate appendixes. This should clean up 1314 the document from a readability point of view, yet still provide 1315 the intended decode examples to readers of this document who wish 1316 that level of detail per flow. The first few flows still have the 1317 decoded SIP messages (unencrypted and encrypted). 1319 - Removed some flow examples which no longer made sense 1321 - Changed all references of "ERC" (Emergency Response Center) to 1322 "PSAP" (Public Safety Answering Point) as a result of discussion 1323 within the new ECRIT WG to define a single term 1325 This is a list of the changes that have been made from the sipping- 1326 01 working group version of this effort to the sipping-02 version: 1328 - added requirements for 2 new 4XX error responses (Bad Location 1329 Information) and (Retry Location Body) 1331 - added "Bad Location Information" as section 8.6 1333 - added "Retry Location Body " as section 9.3 1335 - added support for session mode to cover packet sizes larger than 1336 the single packet limit of 1300 bytes in the message body 1338 - added requirement for a SIP entity to SUBSCRIBE to another for 1339 location information 1341 - added SUBSCRIBE and NOTIFY as section 8.5 1343 - added requirement to have user turn off any tracking created by 1344 subscription 1346 - removed doubt about which method to use for updating location 1347 after a INVITE is sent (update) 1349 - cleaned up which method is to be used if there is no dialog 1350 existing (message) 1352 - removed use of reINVITE to convey location 1354 - clarified that UAs include element of PIDF-LO when 1355 placing an emergency call (to inform PSAP who supplied Location 1356 information) 1358 - updated list of open issues 1360 - added to IANA Considerations section for the two new 4XX level 1361 error responses requested in the last meeting 1363 This is a list of the changes that have been made from the sipping- 1364 00 working group version of this ID to the sipping-01 version: 1366 - Added the offered solution in detail (with message flows, 1367 appropriate SIP Methods for location conveyance, and 1369 - Synchronized the requirements here with those from the Geopriv 1370 Working Group's (attempting to eliminate overlap) 1372 - Took on the task of making this effort the SIP "using protocol" 1373 specification from Geopriv's POV 1375 - Refined the Open Issues section to reflect the progress we've made 1376 here, and to indicate what we have discovered needs addressing, 1377 but has not been to date. 1379 This is a list of the changes that have been made from the -01 1380 individual submission version to the sipping-00 version of this ID: 1382 - Brian Rosen was brought on as a co-author 1384 - Requirements that a location header were negatively received in 1385 the previous version of this document. AD and chair advice was to 1386 move all location information into a message body (and stay away 1387 from headers) 1389 - Added a section of "emergency call" specific requirements 1391 - Added an Open Issues section to mention what hasn't been resolved 1392 yet in this effort 1394 This is a list of the changes that have been made from the 1395 individual submission version -00 to the -01 version 1397 - Added the IPR Statement section 1399 - Adjusted a few requirements based on suggestions from the 1400 Minneapolis meeting 1402 - Added requirements that the UAC is to include from where it 1403 learned its location in any transmission of its LI 1405 - Distinguished the facts (known to date) that certain jurisdictions 1406 relieve persons of their right to privacy when they call a PSAP, 1407 while other jurisdictions maintain a person's right to privacy, 1408 while still others maintain a person's right to privacy - but only 1409 if they ask that their service be set up that way. 1411 - Made the decision that TLS is the security mechanism for location 1412 conveyance in emergency communications (vs. S/MIME, which is still 1413 the mechanism for UA-to-UA non-emergency location conveyance 1414 cases). 1416 - Added the Open Issue of whether a Proxy can insert location 1417 information into an emergency SIP INVITE message, and some of the 1418 open questions surrounding the implications of that action 1420 - added a few names to the acknowledgements section 1422 Intellectual Property Statement 1424 The IETF takes no position regarding the validity or scope of any 1425 Intellectual Property Rights or other rights that might be claimed 1426 to pertain to the implementation or use of the technology described 1427 in this document or the extent to which any license under such 1428 rights might or might not be available; nor does it represent that 1429 it has made any independent effort to identify any such rights. 1431 Information on the procedures with respect to rights in RFC 1432 documents can be found in BCP 78 and BCP 79. 1434 Copies of IPR disclosures made to the IETF Secretariat and any 1435 assurances of licenses to be made available, or the result of an 1436 attempt made to obtain a general license or permission for the use 1437 of such proprietary rights by implementers or users of this 1438 specification can be obtained from the IETF on-line IPR repository 1439 at http://www.ietf.org/ipr. 1441 The IETF invites any interested party to bring to its attention any 1442 copyrights, patents or patent applications, or other proprietary 1443 rights that may cover technology that may be required to implement 1444 this standard. Please address the information to the IETF at 1445 ietf-ipr@ietf.org. 1447 Disclaimer of Validity 1449 This document and the information contained herein are provided on 1450 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 1451 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE 1452 INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR 1453 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1454 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1455 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1457 Copyright Statement 1459 Copyright (C) The Internet Society (2006). This document is subject 1460 to the rights, licenses and restrictions contained in BCP 78, and 1461 except as set forth therein, the authors retain all their rights. 1463 Acknowledgment 1465 Funding for the RFC Editor function is currently provided by the 1466 Internet Society.