idnits 2.17.1 draft-ietf-sipping-sos-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 14. -- Found old boilerplate from RFC 3978, Section 5.5 on line 447. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 424. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 431. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 437. ** 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: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard 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 == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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.) -- The document date (January 28, 2006) is 6662 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC3361' is defined on line 363, but no explicit reference was found in the text == Unused Reference: 'I-D.taylor-ecrit-security-threats' is defined on line 388, but no explicit reference was found in the text == Outdated reference: A later version (-13) exists of draft-ietf-ecrit-requirements-02 == Outdated reference: A later version (-03) exists of draft-taylor-ecrit-security-threats-01 -- Obsolete informational reference (is this intentional?): RFC 2822 (Obsoleted by RFC 5322) Summary: 3 errors (**), 0 flaws (~~), 7 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group H. Schulzrinne 3 Internet-Draft Columbia U. 4 Expires: August 1, 2006 January 28, 2006 6 Emergency Services URI for the Session Initiation Protocol 7 draft-ietf-sipping-sos-02 9 Status of this Memo 11 By submitting this Internet-Draft, each author represents that any 12 applicable patent or other IPR claims of which he or she is aware 13 have been or will be disclosed, and any of which he or she becomes 14 aware will be disclosed, in accordance with Section 6 of BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on August 1, 2006. 34 Copyright Notice 36 Copyright (C) The Internet Society (2006). 38 Abstract 40 As part of an overall architecture for supporting emergency calling 41 for the Session Initiation Protocol (SIP), this document defines 42 universal emergency SIP URIs, sip:sos@domain and sips:sos@domain, 43 that allows SIP user agents to contact the local emergency call 44 center. It also defines conventions that increase the high 45 probability of reaching the appropriate emergency call center. The 46 document does not define any SIP protocol extensions. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 51 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . 3 52 3. Emergency URIs . . . . . . . . . . . . . . . . . . . . . . . 3 53 4. Request Handling . . . . . . . . . . . . . . . . . . . . . . 4 54 5. Alternative Approaches Considered . . . . . . . . . . . . . 5 55 6. Media Feature Tag Registration: Service . . . . . . . . . . 6 56 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . 7 57 8. Security Considerations . . . . . . . . . . . . . . . . . . 8 58 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8 59 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 8 60 10.1 Normative References . . . . . . . . . . . . . . . . . . 8 61 10.2 Informative References . . . . . . . . . . . . . . . . . 9 62 Author's Address . . . . . . . . . . . . . . . . . . . . . . 10 63 Intellectual Property and Copyright Statements . . . . . . . 11 65 1. Introduction 67 Using the public switched telephone network (PSTN), emergency help 68 can often be summoned at a designated, widely known number, 69 regardless of where the telephone was purchased. However, this 70 number differs between localities, even though it is often the same 71 for a country or continent-size region (such as many countries in the 72 European Union or North America). For end systems based on the 73 Session Initiation Protocol (SIP) [RFC3261], it is desirable to have 74 a universal identifier, independent of location, to simplify the user 75 experience and to allow the device to perform appropriate processing. 76 Here, we define a common user identifier, "sos", as the contact 77 mechanism for emergency assistance. This identifier is meant to be 78 used in addition to any local emergency numbers. 80 This document specifies only a small part of a comprehensive set of 81 recommendations for operating emergency services. Future documents 82 will describe how a device that identifies a call as an emergency 83 call can route it to the appropriate Public Safety Answering Point 84 (PSAP). 86 This document does not introduce any new SIP header fields, request 87 methods, status codes, message bodies, or events. User agents 88 unaware of the recommendations in this draft can place emergency 89 calls, but may not be able to provide the same user interface 90 functionality. The document suggests behavior for proxy servers, in 91 particular outbound proxy servers. 93 The solution described here is not as general as the alternative 94 approach, service URNs [I-D.schulzrinne-sipping-service], but 95 requires no changes to end systems or proxies. 97 2. Terminology 99 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 100 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 101 and "OPTIONAL" are to be interpreted as described in BCP 14, RFC 2119 102 [RFC2119] and indicate requirement levels for compliant 103 implementations. 105 3. Emergency URIs 107 Having a single, global identifier for emergency services is highly 108 desirable, as it allows end system and network devices to be built 109 that recognize such services and can act appropriately. Such actions 110 may include restricting the functionality of the end system, 111 providing special features, overriding user service constraints or 112 routing session setup messages. 114 SIP user agents (UAs) that determine that a dialog or transaction 115 relates to an emergency MUST use an an emergency SIP URI defined 116 below as the Request-URI and "To" header field. 118 It is RECOMMENDED that SIP-based [RFC3261] end systems and proxy 119 servers support a uniform emergency call identifier, namely the SIP 120 and SIPS URIs with the reserved user name "sos" within any domain, 121 e.g., 123 sip:sos@example.com 124 sips:sos@example.com 126 The reserved name is case-insensitive. 128 The host part of the emergency URI SHOULD be the host portion of the 129 address-of-record of the caller. The "sips" form SHOULD be used to 130 ensure integrity and confidentiality; the "sip" form MAY be used if a 131 "sips" call fails with status code 416 (Unsupported URI Scheme). All 132 SIP requests with URIs of this form are assumed to be emergency 133 calls. 135 The domain-of-record was chosen since a SIP user agent may not be 136 able to determine the local domain it is visiting. This also 137 allows each user to test this facility, as the user can ensure 138 that such services are operational in his home domain. An 139 outbound proxy in the visited domain can handle the call if it 140 believes to be in a position to provide appropriate emergency 141 services. 143 In some cases, end users or, more likely, emergency service routing 144 proxies may want to request specific emergency services. We support 145 this feature by leveraging the caller preferences [RFC3841] extension 146 and define a new media feature tag, service, in Section 6. 148 The SIP URI user name "sos" MUST NOT be assigned to any regular user. 150 4. Request Handling 152 Outbound proxy servers SHOULD check whether a tel URIs or a SIP URIs 153 containing a dial string represents an emergency number within its 154 geographic service area, but only if they can be reasonably certain 155 that the call originated from within that area, e.g., if the call 156 contained location information or the network is known to only be 157 reachable from a restricted geographic area. Typically, these 158 service areas encompass whole countries since many countries now have 159 nationwide emergency numbers. Once they recognize an emergency 160 number, they translate the Request-URI to an "sos" URI as described 161 above. 163 The proxy MAY use any additional information contained in the call 164 request to recognize additional numbers as emergency numbers. Such 165 information includes the Mobile Country Code and the Mobile Network 166 Code for 3GPP devices or country information in location information 167 available about the call. 169 5. Alternative Approaches Considered 171 The "sos" SIP URI reserved user name proposed here follows the 172 convention of RFC 2142 [RFC2142] and the "postmaster" convention 173 documented in RFC 2822 [RFC2822]. The approach has the advantage 174 that only the home proxy for a user needs to understand the 175 convention and that the mechanism is likely backwards-compatible with 176 most SIP user agents, with the only requirement that they have to be 177 able to generate alphanumeric URLs. One drawback is that it may 178 conflict with locally assigned addresses of the form "sos@domain". 179 Also, if proxies not affiliated with the domain translate the URL, 180 they violate the current SIP protocol conventions. 182 There are a number of possible alternatives, each with their own set 183 of advantages and problems: 185 tel:NNN;context=+C This approach uses tel URIs [RFC3966]. Here, NNN 186 is the national emergency number, where the country is identified 187 by the context C. This approach is easy for user agents to 188 implement, but hard for proxies and other SIP elements to 189 recognize, as it would have to know about all number-context 190 combinations in the world and track occasional changes. In 191 addition, many of these numbers are being used for other services. 192 For example, the emergency number in Paraguay (00) is also used to 193 call the international operator in the United States. A number of 194 countries, such as Italy, use 118 as an emergency number, but it 195 also connects to directory assistance in Finland. 196 tel:sos This solution avoids name conflicts, but is not a valid "tel" 197 [RFC3966] URI. It also only works if every outbound proxy knows 198 how to route requests to a proxy that can reach emergency services 199 since tel URIs. The SIP URI proposed here only requires a user's 200 home domain to be appropriately configured. 201 urn:service:sos A related document [I-D.schulzrinne-sipping-service] 202 defines a URN for identifying services, such as emergency calling. 203 This solution fits most cleanly into the overall URI architecture, 204 can support a variety of protocols beyond SIP and avoids 205 dependencies on the home domain, but, like the tel URI solution 206 above, also requires that every outbound proxy can resolve this 207 URN and can route calls accordingly. Alternatively, the end 208 system has to be configured with a suitable URN-resolving proxy, 209 e.g., in its home domain. 211 SIP URI user parameter: One could create a special URI, such as "aor- 212 domain;user=sos". This avoids the name conflict problem, but 213 requires mechanism-aware user agents that are capable of emitting 214 this special URI. Also, the 'user' parameter is meant to describe 215 the format of the user part of the SIP URI, which this usage does 216 not do. Adding other parameters still leaves unclear what, if 217 any, conventions should be used for the user and domain part of 218 the URL. Neither solution is likely to be backward-compatible 219 with existing clients. 220 Special domain: A special domain, such as "sip:fire@sos.int" could be 221 used to identify emergency calls. This has similar properties as 222 the "tel:sos" URI, except that it is indeed a valid URI. To make 223 this usable, the special domain would have to be operational and 224 point to an appropriate emergency services proxy. Having a 225 single, if logical, emergency services proxy for the whole world 226 seems to have undesirable scaling and administrative properties. 228 6. Media Feature Tag Registration: Service 230 Instead of defining additional, more specific, emergency services in 231 the SIP URI, we propose the use of a new media feature tag [RFC3840], 232 sip.service, that describe the desired emergency service. 234 For example, a user agent could request to be routed to marine rescue 235 by including the following header: 237 Accept-Contact: *;sip.service="sos.marine" 239 [Note: This mechanism fits with the Caller Preferences model, but 240 reduces the backward-compatibility of the overall approach.] 242 This specification defines an additional media feature tag, extending 243 the SIP tree entries described in [RFC3840] and following the 244 registration process in Section 12.1 of that document. This section 245 serves as the IANA registration for the service feature tags, which 246 are made into the SIP media feature tag tree. 248 This facility is not meant to encourage end users to select emergency 249 services where a single PSAP for all such services exist. Rather, 250 these identifiers reflect current practice in jurisdictions that 251 already have different numbers for the different emergency services. 252 For example, in Germany, ambulance and fire use 112, while police 253 uses 110. 255 We expect that users will rarely invoke specific emergency 256 services directly. Rather, they might be generated by outbound 257 proxy servers translating dial strings or be generated when 258 pressing icon-bearing speed dial buttons. 260 Using feature tags has the advantage that they are not affected by 261 entities that translate URIs, e.g., to route emergency calls to a 262 specific PSAP. 264 The service types for this feature tag are case-insensitive. 265 Additional service types can be registered with IANA (Section 266 Section 7). 268 Media feature tag name: sip.service 269 ASN.1 Identifier: New assignment by IANA. 270 Summary of the media feature indicated by this tag: Each feature tag 271 indicates the type of communication service requested. 272 Values appropriate for use with this feature tag: Token with an 273 equality relationship. Initial values include a number of 274 emergency services: 276 sos: general emergency service 277 sos.fire: fire brigade 278 sos.marine: marine guard 279 sos.mountain: mountain rescue 280 sos.police: police (law enforcement) 281 sos.rescue: ambulance, emergency medical service 282 sos.test: testing, not a real emergency call 283 The feature tag is intended primarily for use in the following 284 applications, protocols, services, or negotiation mechanisms: This 285 feature tag is most useful in a communications application, for 286 describing the capabilities of a user agent providing a particular 287 type of communication service. 288 Examples of typical use: Allowing an emergency service proxy to 289 select the desired emergency service, such as police or ambulance. 290 Related standards or documents: RFC3840. 291 Security Considerations: Security considerations for this media 292 feature tag are discussed in Section 11.1 of RFC3840. 294 7. IANA Considerations 296 Subaddresses of the "sos" address are registered with IANA This 297 specification establishes the "sos" subaddres sub-registry under 298 http://www.iana.org/assignments/sip-parameters. 300 Subaddresses are registered by the IANA when they are published in 301 standards track RFCs. The IANA Considerations section of the RFC 302 must include the following information, which appears in the IANA 303 registry along with the RFC number of the publication. 305 o Name of the subaddress. The name MAY be of any length, but SHOULD 306 be no more than twenty characters long. The name MUST consist of 307 NVT alphanumeric characters only and is case-insensitive. 309 o Descriptive text that describes the emergency service. 311 8. Security Considerations 313 The SIP specification [RFC3261] details security considerations that 314 apply to emergency calls as well. Security for emergency calls has 315 conflicting goals, namely to make it as easy and reliable as possible 316 to reach emergency services, while discouraging and possibly tracing 317 prank calls. It appears unlikely that classical authentication 318 mechanisms can be required by emergency call centers, but SIP proxy 319 servers may be able to add identifying information. 321 Given the sensitive nature of many emergency calls, it is highly 322 desirable to use the "sips" URI to ensure transport-level 323 confidentiality and integrity. However, this may cause the call to 324 fail in some environments. 326 Allowing the user agent to clearly and unambiguously identify 327 emergency calls makes it possible for the user agent to make 328 appropriate policy decisions. For example, a user agent policy may 329 reveal a different amount of information to the callee when making an 330 emergency call. Local laws may affect what information network 331 servers or service providers may be allowed or be required to release 332 to emergency call centers. They may also base their decision on the 333 user-declared destination of the call. 335 Recognizing only "sos" in the user's home domain, i.e., the domain of 336 the user's AOR, prevents spoofing where a link points to a fake 337 emergency calling number and leads the user to, for example, include 338 location information in the request. 340 Additional security considerations related to call routing, 341 destination authentication and other issues are detailed in 342 [I-D.ietf-ecrit-requirements] and [I-D.taylor-ecrit-security- 343 threats]. 345 9. Acknowledgements 347 Andrew Allen, Keith Drage, Cullen Jennings, Mike Pierce, James Polk, 348 Brian Rosen, John Schnizlein and Hannes Tschofenig contributed 349 helpful comments. 351 10. References 353 10.1 Normative References 355 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 356 Requirement Levels", BCP 14, RFC 2119, March 1997. 358 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 359 A., Peterson, J., Sparks, R., Handley, M., and E. 360 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 361 June 2002. 363 [RFC3361] Schulzrinne, H., "Dynamic Host Configuration Protocol 364 (DHCP-for-IPv4) Option for Session Initiation Protocol 365 (SIP) Servers", RFC 3361, August 2002. 367 [RFC3840] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, 368 "Indicating User Agent Capabilities in the Session 369 Initiation Protocol (SIP)", RFC 3840, August 2004. 371 [RFC3841] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Caller 372 Preferences for the Session Initiation Protocol (SIP)", 373 RFC 3841, August 2004. 375 10.2 Informative References 377 [I-D.ietf-ecrit-requirements] 378 Schulzrinne, H. and R. Marshall, "Requirements for 379 Emergency Context Resolution with Internet Technologies", 380 draft-ietf-ecrit-requirements-02 (work in progress), 381 January 2006. 383 [I-D.schulzrinne-sipping-service] 384 Schulzrinne, H., "A Uniform Resource Name (URN) for 385 Services", draft-schulzrinne-sipping-service-01 (work in 386 progress), October 2005. 388 [I-D.taylor-ecrit-security-threats] 389 Schulzrinne, H., "Security Threats and Requirements for 390 Emergency Calling", draft-taylor-ecrit-security-threats-01 391 (work in progress), December 2005. 393 [RFC2142] Crocker, D., "MAILBOX NAMES FOR COMMON SERVICES, ROLES AND 394 FUNCTIONS", RFC 2142, May 1997. 396 [RFC2822] Resnick, P., "Internet Message Format", RFC 2822, 397 April 2001. 399 [RFC3966] Schulzrinne, H., "The tel URI for Telephone Numbers", 400 RFC 3966, December 2004. 402 Author's Address 404 Henning Schulzrinne 405 Columbia University 406 Department of Computer Science 407 450 Computer Science Building 408 New York, NY 10027 409 US 411 Phone: +1 212 939 7004 412 Email: hgs@cs.columbia.edu 413 URI: http://www.cs.columbia.edu 415 Intellectual Property Statement 417 The IETF takes no position regarding the validity or scope of any 418 Intellectual Property Rights or other rights that might be claimed to 419 pertain to the implementation or use of the technology described in 420 this document or the extent to which any license under such rights 421 might or might not be available; nor does it represent that it has 422 made any independent effort to identify any such rights. Information 423 on the procedures with respect to rights in RFC documents can be 424 found in BCP 78 and BCP 79. 426 Copies of IPR disclosures made to the IETF Secretariat and any 427 assurances of licenses to be made available, or the result of an 428 attempt made to obtain a general license or permission for the use of 429 such proprietary rights by implementers or users of this 430 specification can be obtained from the IETF on-line IPR repository at 431 http://www.ietf.org/ipr. 433 The IETF invites any interested party to bring to its attention any 434 copyrights, patents or patent applications, or other proprietary 435 rights that may cover technology that may be required to implement 436 this standard. Please address the information to the IETF at 437 ietf-ipr@ietf.org. 439 Disclaimer of Validity 441 This document and the information contained herein are provided on an 442 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 443 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 444 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 445 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 446 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 447 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 449 Copyright Statement 451 Copyright (C) The Internet Society (2006). This document is subject 452 to the rights, licenses and restrictions contained in BCP 78, and 453 except as set forth therein, the authors retain all their rights. 455 Acknowledgment 457 Funding for the RFC Editor function is currently provided by the 458 Internet Society.