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