idnits 2.17.1 draft-ietf-ecrit-service-urn-07.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, updated by RFC 4748 on line 594. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 605. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 612. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 618. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust 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 (August 15, 2007) is 6091 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) ** Obsolete normative reference: RFC 2434 (ref. '3') (Obsoleted by RFC 5226) ** Obsolete normative reference: RFC 4234 (ref. '6') (Obsoleted by RFC 5234) -- Obsolete informational reference (is this intentional?): RFC 2822 (ref. '8') (Obsoleted by RFC 5322) -- Obsolete informational reference (is this intentional?): RFC 3044 (ref. '10') (Obsoleted by RFC 8254) -- Obsolete informational reference (is this intentional?): RFC 3187 (ref. '11') (Obsoleted by RFC 8254) -- Obsolete informational reference (is this intentional?): RFC 3536 (ref. '12') (Obsoleted by RFC 6365) -- Obsolete informational reference (is this intentional?): RFC 3406 (ref. '13') (Obsoleted by RFC 8141) == Outdated reference: A later version (-10) exists of draft-ietf-ecrit-lost-06 == Outdated reference: A later version (-05) exists of draft-ietf-ecrit-security-threats-04 Summary: 3 errors (**), 0 flaws (~~), 4 warnings (==), 12 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ECRIT H. Schulzrinne 3 Internet-Draft Columbia U. 4 Intended status: Standards Track August 15, 2007 5 Expires: February 16, 2008 7 A Uniform Resource Name (URN) for Emergency and Other Well-Known 8 Services 9 draft-ietf-ecrit-service-urn-07 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 months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on February 16, 2008. 36 Copyright Notice 38 Copyright (C) The IETF Trust (2007). 40 Abstract 42 The content of many communication services depends on the context, 43 such as the user's location. We describe a 'service' URN that allows 44 to identify well-known context-dependent services that can be 45 resolved in a distributed manner. Examples include emergency 46 services, directory assistance and call-before-you-dig hot lines. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 51 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 52 3. Registration Template . . . . . . . . . . . . . . . . . . . . 5 53 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 54 4.1. New Service-Identifying Labels . . . . . . . . . . . . . . 7 55 4.2. Sub-Services for the 'sos' Service . . . . . . . . . . . . 8 56 4.3. Sub-Services for the 'counseling' Service . . . . . . . . 9 57 4.4. Initial IANA Registration . . . . . . . . . . . . . . . . 9 58 5. Internationalization Considerations . . . . . . . . . . . . . 10 59 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 60 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 61 7.1. Normative References . . . . . . . . . . . . . . . . . . . 11 62 7.2. Informative References . . . . . . . . . . . . . . . . . . 11 63 Appendix A. Alternative Approaches Considered . . . . . . . . . . 12 64 Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . . . 13 65 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 14 66 Intellectual Property and Copyright Statements . . . . . . . . . . 15 68 1. Introduction 70 In existing telecommunications systems, there are many well-known 71 communication and information services that are offered by loosely 72 coordinated entities across a large geographic region, with well- 73 known identifiers. Some of the services are operated by governments 74 or regulated monopolies, others by competing commercial enterprises. 75 Examples include emergency services (reached by dialing 9-1-1 in 76 North America, 1-1-2 in Europe), community services and volunteer 77 opportunities (2-1-1 in some regions of the United States), telephone 78 directory and repair services (4-1-1 and 6-1-1 in the United States 79 and Canada), government information services (3-1-1 in some cities in 80 the United States), lawyer referral services (1-800-LAWYER), car 81 roadside assistance (automobile clubs) and pizza delivery services. 82 Unfortunately, almost all of them are limited in scope to a single 83 country or possibly a group of countries, such as those belonging to 84 the North American Numbering Plan or the European Union. The same 85 identifiers are often used for other purposes outside that region, 86 making accessing such services difficult when users travel or use 87 devices produced outside their home country. 89 These services are characterized by long-term stability of user- 90 visible identifiers, decentralized administration of the underlying 91 service and a well-defined resolution or mapping mechanism. For 92 example, there is no national coordination or call center for "9-1-1" 93 in the United States; rather, various local government organizations 94 cooperate to provide this service, based on jurisdictions. We use 95 the terms resolution and mapping interchangeably. 97 In this document, we propose a URN namespace that, together with 98 resolution protocols beyond the scope of this document, allows us to 99 define such global, well-known services, while distributing the 100 actual implementation across a large number of service-providing 101 entities. There are many ways to divide provision of such services, 102 such as dividing responsibility by geographic region or by the 103 service provider a user chooses. In addition, users can choose 104 different mapping service providers that in turn manage how 105 geographic locations are mapped to service providers. 107 Availability of such service identifiers allows end systems to convey 108 information about the desired service to other network entities. For 109 example, an IP phone could have a special set of short cuts, address 110 book entries or buttons that invoke emergency services. When such a 111 service identifier is put into the outgoing Session Initiation 112 Protocol (SIP) [4] message, it allows SIP proxies to unambiguously 113 take actions, as it would not be practical to configure them with 114 dial strings and emergency numbers used throughout the world. Hence, 115 such service identifiers make it possible to delegate routing 116 decisions to third parties and to mark certain requests as having 117 special characteristics while preventing these characteristics from 118 being accidentally invoked. 120 This URN identifies services independent of the particular protocol 121 that is used to request or deliver the service. The URN may appear 122 in protocols that allow general URIs, such as the SIP [4] request 123 URIs, web pages or mapping protocols. 125 The service URN is a protocol element and generally not expected to 126 be visible to humans. For example, it is expected that callers will 127 still dial the emergency number '9-1-1' in the United States to reach 128 emergency services. In some other cases, speed dial buttons might 129 identify the service, as is common practice on hotel phones today. 130 (Speed dial buttons for summoning emergency help are considered 131 inappropriate by most emergency services professionals, at least for 132 mobile devices, as they are too prone to being triggered 133 accidentally.) 135 The translation of service dial strings or service numbers to service 136 URNs in the end host is beyond the scope of this document. These 137 translations likely depend on the location of the caller and may be 138 many-to-one, i.e., several service numbers may map to one service 139 URN. For example, a phone for a traveler could recognize the 140 emergency service number for both the traveler's home location and 141 the traveler's visited location, mapping both to the same universal 142 service URN, urn:service:sos. 144 Since service URNs are not routable, a SIP proxy or user agent has to 145 translate the service URN into a routable URI for a location- 146 appropriate service provider, such as a SIP URL. LoST [18] is 147 expected to be used as a resolution system for mapping service URNs 148 to URLs based on geographic location. In the future, there may be 149 several such protocols, possibly different ones for different 150 services. 152 Services are described by top-level service type, and may contain a 153 hierarchy of sub-services further describing the service, as outlined 154 in Section 3. 156 We discuss alternative approaches for creating service identifiers, 157 and why they are unsatisfactory, in Appendix A. 159 2. Terminology 161 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 162 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 163 and "OPTIONAL" are to be interpreted as described in RFC 2119 [2]. 165 Terminology specific to emergency services is defined in [20]. 167 3. Registration Template 169 Below, we include the registration template for the URN scheme 170 according to RFC 3406 [13]. 171 Namespace ID: service 172 Registration Information: Registration version: 1; registration 173 date: 2006-04-02 175 Declared registrant of the namespace: 176 Registering organization: IETF 177 Designated contact: Henning Schulzrinne 178 Designated contact email: hgs@cs.columbia.edu 180 Declaration of syntactic structure: The URN consists of a 181 hierarchical service identifier, with a sequence of labels 182 separated by periods. The left-most label is the most significant 183 one and is called 'top-level service', while names to the right 184 are called 'sub-services'. The set of allowable characters is the 185 same as that for domain names [1] and a subset of the labels 186 allowed in [5]. Labels are case-insensitive and MUST be specified 187 in all lower-case. For any given service URN, service-identifiers 188 can be removed right-to-left and the resulting URN is still valid, 189 referring a more generic service. In other words, if a service 190 'x.y.z' exists, the URNs 'x' and 'x.y' are also valid service 191 URNs. The ABNF [6] is shown below. 193 service-URN = "URN:service:" service 194 service = top-level *("." sub-service) 195 top-level = let-dig [ *25let-dig-hyp let-dig ] 196 sub-service = let-dig [ *let-dig-hyp let-dig ] 197 let-dig-hyp = let-dig / "-" 198 let-dig = ALPHA / DIGIT 199 ALPHA = %x41-5A / %x61-7A ; A-Z / a-z 200 DIGIT = %x30-39 ; 0-9 202 Relevant ancillary documentation: None 204 Community considerations: The service URN is believed to be relevant 205 to a large cross-section of Internet users, including both 206 technical and non-technical users, on a variety of devices, but 207 particularly for mobile and nomadic users. The service URN will 208 allow Internet users needing services to identify the service by 209 kind, without having to determine manually who provides the 210 particular service in the user's current context, e.g., at the 211 user's current location. For example, travelers will be able to 212 use their mobile devices to request emergency services without 213 having to know the emergency dial string of the visited country. 214 The assignment of identifiers is described in the IANA 215 Considerations (Section 4). The service URN does not prescribe a 216 particular resolution mechanism, but it is assumed that a number 217 of different entities could operate and offer such mechanisms. 219 Namespace considerations: There do not appear to be other URN 220 namespaces that serve the same need of uniquely identifying 221 widely-available communication and information services. Unlike 222 most other currently registered URN namespaces, the service URN 223 does not identify documents and protocol objects (e.g., [10], 224 [11], [16], [17]), types of telecommunications equipment [15], 225 people or organizations [9]. tel URIs [14] identify telephone 226 numbers, but numbers commonly identifying services, such as 911 or 227 112, are specific to a particular region or country. 229 Identifier uniqueness considerations: A service URN identifies a 230 logical service, specified in the service registration (see IANA 231 Considerations (Section 4)). Resolution of the URN, if 232 successful, will return a particular instance of the service, and 233 this instance may be different even for two users making the same 234 request in the same place at the same time; the logical service 235 identified by the URN, however, is persistent and unique. Service 236 URNs MUST be unique for each unique service; this is guaranteed 237 through the registration of each service within this namespace, 238 described in Section 4. 240 Identifier persistence considerations: The 'service' URN for the 241 same service is expected to be persistent, although there 242 naturally cannot be a guarantee that a particular service will 243 continue to be available globally or at all times. 245 Process of identifier assignment: The process of identifier 246 assignment is described in the IANA Considerations (Section 4). 248 Process for identifier resolution: There is no single global 249 resolution service for 'service' URNs. However, each top-level 250 service can provide a set of mapping protocols to be used with 251 'service' URNs of that service. 253 Rules for Lexical Equivalence: 'service' identifiers are compared 254 according to case-insensitive string equality. 256 Conformance with URN Syntax: The BNF in the 'Declaration of 257 syntactic structure' above constrains the syntax for this URN 258 scheme. 260 Validation mechanism: Validation determines whether a given string 261 is currently a validly-assigned URN [13]. Due to the distributed 262 nature of the mapping mechanism and since not all services are 263 available everywhere and not all mapping servers may be configured 264 with all current service registrations, validation in this sense 265 is not possible. Also, the discovery mechanism for the mapping 266 mechanism may not be configured with all current top-level 267 services. 269 Scope: The scope for this URN is public and global. 271 4. IANA Considerations 273 This section registers a new URN scheme with the registration 274 template provided in Section 3. 276 Below, Section 4.1 details how to register new service-identifying 277 labels. Descriptions of sub-services for the first two services to 278 be registered, sos and counseling, are given in Section 4.2 and 279 Section 4.3, respectively. Finally, Section 4.4 contains the initial 280 registration table. 282 4.1. New Service-Identifying Labels 284 Services and sub-services are identified by labels managed by IANA, 285 according to the processes outlined in [3] in a new registry called 286 "Service URN Labels". Thus, creating a new service requires IANA 287 action. The policy for adding top-level service labels is 'Standards 288 Action'. (This document defines the top-level service 'sos' and 289 'counseling'.) The policy for assigning labels to sub-services may 290 differ for each top-level service designation and MUST be defined by 291 the document describing the top-level service. 293 Entries in the registration table have the following format 295 Service Reference Description 296 -------------------------------------------------------------------- 297 foo RFCxyz Brief description of the 'foo' top-level service 298 foo.bar RFCabc Description of the 'foo.bar' service 299 To allow use within the constraints of S-NAPTR [5], all top-level 300 service names MUST NOT exceed 27 characters. 302 4.2. Sub-Services for the 'sos' Service 304 This section defines the first service registration within the IANA 305 registry defined in Section 4.1, using the top-level service label 306 'sos'. 308 The 'sos' service type describes emergency services requiring an 309 immediate response, typically offered by various branches of the 310 government or other public institutions. Additional sub-services can 311 be added after expert review and must be of general public interest 312 and have a similar emergency nature. The expert is designated by the 313 ECRIT working group, its successor, or, in their absence, the IESG. 314 The expert review should only approve emergency services that are 315 offered widely and in different countries, with approximately the 316 same caller expectation in terms of services rendered. The 'sos' 317 service is not meant to invoke general government, public 318 information, counseling or social services. 320 urn:service:sos The generic 'sos' service reaches a public safety 321 answering point (PSAP) which in turn dispatches aid appropriate to 322 the emergency. It encompasses all of the services listed below. 323 urn:service:sos.ambulance This service identifier reaches an 324 ambulance service that provides emergency medical assistance and 325 transportation. 326 urn:service:sos.animal-control Animal control is defined as control 327 of dogs, cats, and domesticated or undomesticated animals. 328 urn:service:sos.fire The 'fire' service identifier summons the fire 329 service, also known as the fire brigade or fire department. 330 urn:service:sos.gas The 'gas' service allows the reporting of 331 natural gas (and other flammable gas) leaks or other natural gas 332 emergencies. 333 urn:service:sos.marine The 'marine' service refers to maritime 334 search and rescue services such as those offered by the coast 335 guard, lifeboat or surf lifesavers. 336 urn:service:sos.mountain The 'mountain' service refers to mountain 337 rescue services, i.e., search and rescue activities that occur in 338 a mountainous environment, although the term is sometimes also 339 used to apply to search and rescue in other wilderness 340 environments. 341 urn:service:sos.physician The 'physician' emergency service connects 342 the caller to a physician referral service. 344 urn:service:sos.poison The 'poison' service refers to special 345 information centers set up to inform citizens about how to respond 346 to potential poisoning. These poison control centers maintain a 347 database of poisons and appropriate emergency treatment. 348 urn:service:sos.police The 'police' service refers to the police 349 department or other law enforcement authorities. 351 4.3. Sub-Services for the 'counseling' Service 353 The 'counseling' service type describes services where callers can 354 receive advice and support, often anonymous, but not requiring an 355 emergency response. (Naturally, such services may transfer callers 356 to an emergency service or summon such services if the situation 357 warrants.) Additional sub-services can be added after expert review 358 and should be of general public interest. The expert is chosen in 359 the same manner as describe for the 'sos' service. The expert review 360 should take into account whether these services are offered widely 361 and in different countries, with approximately the same caller 362 expectation in terms of services rendered. 363 urn:service:counseling The generic 'counseling' service reaches a 364 call center that transfers the caller based on his or her specific 365 needs. 367 urn:service:counseling.children The 'children' service refers to 368 counseling and support services that are specifically tailored to 369 the needs of children. Such services may, for example, provide 370 advice to run-aways or victims of child abuse. 372 urn:service:counseling.mental-health The 'mental-health' service 373 refers to the "diagnostic, treatment, and preventive care that 374 helps improve how persons with mental illness feel both physically 375 and emotionally as well as how they interact with other persons." 376 (U.S. Department of Health and Human Services) 378 urn:service:counseling.suicide The 'suicide' service refers to the 379 suicide prevention hotline. 381 4.4. Initial IANA Registration 383 The following table contains the initial IANA registration for 384 emergency and counseling services. 386 Service Reference Description 387 -------------------------------------------------------------------- 388 counseling RFC XYZ Counseling services 389 counseling.children RFC XYZ Counseling for children 390 counseling.mental-health RFC XYZ Mental health counseling 391 counseling.suicide RFC XYZ Suicide prevention hotline 393 sos RFC XYZ Emergency services 394 sos.animal-control RFC XYZ Animal control 395 sos.fire RFC XYZ Fire service 396 sos.gas RFC XYZ Gas leaks and gas emergencies 397 sos.marine RFC XYZ Maritime search and rescue 398 sos.mountain RFC XYZ Mountain rescue 399 sos.physician RFC XYZ Physician referral service 400 sos.poison RFC XYZ Poison control center 401 sos.police RFC XYZ Police, law enforcement 403 [[NOTE TO RFC-EDITOR: Please replace above 'RFC XYZ' reference with 404 the RFC number of this document and remove this note.]] 406 5. Internationalization Considerations 408 The service labels are protocol elements [12] and not normally seen 409 by users. Thus, the character set for these elements is restricted, 410 as described in Section 3. 412 6. Security Considerations 414 As an identifier, the service URN does not appear to raise any 415 particular security issues. The services described by the URN are 416 meant to be well-known, even if the particular service instance is 417 access-controlled, so privacy considerations do not apply to the URN. 418 There are likely no specific privacy issues when including a service 419 URN on a web page, for example. On the other hand, ferrying the URN 420 in a signaling protocol can give attackers information on the kind of 421 service desired by the caller. For example, this makes it easier for 422 the attacker to automatically find all calls for emergency services 423 or directory assistance. Appropriate, protocol-specific security 424 mechanisms need to be implemented for protocols carrying service 425 URNs. The mapping protocol needs to address a number of threats, as 426 detailed in [19]. That document also discusses the security 427 considerations related to the use of the service URN for emergency 428 services. 430 7. References 431 7.1. Normative References 433 [1] Braden, R., "Requirements for Internet Hosts - Application and 434 Support", STD 3, RFC 1123, October 1989. 436 [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement 437 Levels", BCP 14, RFC 2119, March 1997. 439 [3] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA 440 Considerations Section in RFCs", BCP 26, RFC 2434, 441 October 1998. 443 [4] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 444 Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: 445 Session Initiation Protocol", RFC 3261, June 2002. 447 [5] Daigle, L. and A. Newton, "Domain-Based Application Service 448 Location Using SRV RRs and the Dynamic Delegation Discovery 449 Service (DDDS)", RFC 3958, January 2005. 451 [6] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 452 Specifications: ABNF", RFC 4234, October 2005. 454 7.2. Informative References 456 [7] Crocker, D., "MAILBOX NAMES FOR COMMON SERVICES, ROLES AND 457 FUNCTIONS", RFC 2142, May 1997. 459 [8] Resnick, P., "Internet Message Format", RFC 2822, April 2001. 461 [9] Mealling, M., "The Network Solutions Personal Internet Name 462 (PIN): A URN Namespace for People and Organizations", RFC 3043, 463 January 2001. 465 [10] Rozenfeld, S., "Using The ISSN (International Serial Standard 466 Number) as URN (Uniform Resource Names) within an ISSN-URN 467 Namespace", RFC 3044, January 2001. 469 [11] Hakala, J. and H. Walravens, "Using International Standard Book 470 Numbers as Uniform Resource Names", RFC 3187, October 2001. 472 [12] Hoffman, P., "Terminology Used in Internationalization in the 473 IETF", RFC 3536, May 2003. 475 [13] Daigle, L., van Gulik, D., Iannella, R., and P. Faltstrom, 476 "Uniform Resource Names (URN) Namespace Definition Mechanisms", 477 BCP 66, RFC 3406, October 2002. 479 [14] Schulzrinne, H., "The tel URI for Telephone Numbers", RFC 3966, 480 December 2004. 482 [15] Tesink, K. and R. Fox, "A Uniform Resource Name (URN) Namespace 483 for the Common Language Equipment Identifier (CLEI) Code", 484 RFC 4152, August 2005. 486 [16] Kang, S., "Using Universal Content Identifier (UCI) as Uniform 487 Resource Names (URN)", RFC 4179, October 2005. 489 [17] Kameyama, W., "A Uniform Resource Name (URN) Namespace for the 490 TV-Anytime Forum", RFC 4195, October 2005. 492 [18] Hardie, T., "LoST: A Location-to-Service Translation Protocol", 493 draft-ietf-ecrit-lost-06 (work in progress), August 2007. 495 [19] Taylor, T., "Security Threats and Requirements for Emergency 496 Call Marking and Mapping", draft-ietf-ecrit-security-threats-04 497 (work in progress), April 2007. 499 [20] Schulzrinne, H. and R. Marshall, "Requirements for Emergency 500 Context Resolution with Internet Technologies", 501 draft-ietf-ecrit-requirements-13 (work in progress), 502 March 2007. 504 Appendix A. Alternative Approaches Considered 506 The discussions of ways to identify emergency calls has yielded a 507 number of proposals. Since these are occasionally brought up during 508 discussions, we briefly summarize why this document chose not to 509 pursue these solutions. 510 tel:NNN;context=+C This approach uses tel URIs [14]. Here, NNN is 511 the national emergency number, where the country is identified by 512 the context C. This approach is easy for user agents to implement, 513 but hard for proxies and other SIP elements to recognize, as it 514 would have to know about all number-context combinations in the 515 world and track occasional changes. In addition, many of these 516 numbers are being used for other services. For example, the 517 emergency number in Paraguay (00) is also used to call the 518 international operator in the United States. As another example, 519 A number of countries, such as Italy, use 118 as an emergency 520 number, but it also connects to directory assistance in Finland. 522 tel:sos This solution avoids name conflicts, but is not a valid 523 "tel" [14] URI. It also only works if every outbound proxy knows 524 how to route requests to a proxy that can reach emergency services 525 since tel URIs. The SIP URI proposed here only requires a user's 526 home domain to be appropriately configured. 528 sip:sos@domain Earlier work had defined a special user identifier, 529 sos, within the caller's home domain in a SIP URI, for example, 530 sip:sos@example.com. Such a user identifier follows the 531 convention of RFC 2142 [7] and the "postmaster" convention 532 documented in RFC 2822 [8]. This approach had the advantage that 533 dial plans in existing user agents could probably be converted to 534 generate such a URI and that only the home proxy for the domain 535 has to understand the user naming convention. However, it 536 overloads the user part of the URI with specific semantics rather 537 than being opaque, makes routing by the outbound proxy a special 538 case that does not conform to normal SIP request-URI handling 539 rules and is SIP-specific. The mechanism also does not extend 540 readily to other services. 542 SIP URI user parameter: One could create a special URI, such as 543 "aor-domain;user=sos". This avoids the name conflict problem, but 544 requires mechanism-aware user agents that are capable of emitting 545 this special URI. Also, the 'user' parameter is meant to describe 546 the format of the user part of the SIP URI, which this usage does 547 not do. Adding other parameters still leaves unclear what, if 548 any, conventions should be used for the user and domain part of 549 the URL. Neither solution is likely to be backward-compatible 550 with existing clients. 552 Special domain: A special domain, such as "sip:fire@sos.int" could 553 be used to identify emergency calls. This has similar properties 554 as the "tel:sos" URI, except that it is indeed a valid URI. To 555 make this usable, the special domain would have to be operational 556 and point to an appropriate emergency services proxy. Having a 557 single, if logical, emergency services proxy for the whole world 558 seems to have undesirable scaling and administrative properties. 560 Appendix B. Acknowledgments 562 This document is based on discussions with Jonathan Rosenberg and 563 benefited from the comments of Leslie Daigle, Keith Drage, Benja 564 Fallenstein, Paul Kyzivat, Andrew Newton, Brian Rosen, Jonathan 565 Rosenberg, Martin Thomson and Hannes Tschofenig. 567 Author's Address 569 Henning Schulzrinne 570 Columbia University 571 Department of Computer Science 572 450 Computer Science Building 573 New York, NY 10027 574 US 576 Phone: +1 212 939 7004 577 Email: hgs+ecrit@cs.columbia.edu 578 URI: http://www.cs.columbia.edu 580 Full Copyright Statement 582 Copyright (C) The IETF Trust (2007). 584 This document is subject to the rights, licenses and restrictions 585 contained in BCP 78, and except as set forth therein, the authors 586 retain all their rights. 588 This document and the information contained herein are provided on an 589 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 590 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 591 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 592 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 593 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 594 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 596 Intellectual Property 598 The IETF takes no position regarding the validity or scope of any 599 Intellectual Property Rights or other rights that might be claimed to 600 pertain to the implementation or use of the technology described in 601 this document or the extent to which any license under such rights 602 might or might not be available; nor does it represent that it has 603 made any independent effort to identify any such rights. Information 604 on the procedures with respect to rights in RFC documents can be 605 found in BCP 78 and BCP 79. 607 Copies of IPR disclosures made to the IETF Secretariat and any 608 assurances of licenses to be made available, or the result of an 609 attempt made to obtain a general license or permission for the use of 610 such proprietary rights by implementers or users of this 611 specification can be obtained from the IETF on-line IPR repository at 612 http://www.ietf.org/ipr. 614 The IETF invites any interested party to bring to its attention any 615 copyrights, patents or patent applications, or other proprietary 616 rights that may cover technology that may be required to implement 617 this standard. Please address the information to the IETF at 618 ietf-ipr@ietf.org. 620 Acknowledgment 622 Funding for the RFC Editor function is provided by the IETF 623 Administrative Support Activity (IASA).