idnits 2.17.1 draft-ietf-ecrit-service-urn-05.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 589. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 566. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 573. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 579. ** 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 27, 2006) is 6452 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 informational reference (is this intentional?): RFC 2822 (ref. '7') (Obsoleted by RFC 5322) -- Obsolete informational reference (is this intentional?): RFC 3044 (ref. '9') (Obsoleted by RFC 8254) -- Obsolete informational reference (is this intentional?): RFC 3187 (ref. '10') (Obsoleted by RFC 8254) -- Obsolete informational reference (is this intentional?): RFC 3536 (ref. '11') (Obsoleted by RFC 6365) -- Obsolete informational reference (is this intentional?): RFC 3406 (ref. '12') (Obsoleted by RFC 8141) == Outdated reference: A later version (-10) exists of draft-ietf-ecrit-lost-00 == 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-11 Summary: 4 errors (**), 0 flaws (~~), 6 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 28, 2007 August 27, 2006 6 A Uniform Resource Name (URN) for Services 7 draft-ietf-ecrit-service-urn-05 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 28, 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 allows end systems to convey 105 information about the desired service to other network entities. For 106 example, an IP phone could have a special set of short cuts, address 107 book entries or buttons that invoke emergency services. When such a 108 service identifier is put into the outgoing SIP message, it allows 109 SIP proxies to unambiguously take actions, as it would not be 110 practical to configure them with dial strings and emergency numbers 111 used throughout the world. Hence, such service identifiers make it 112 possible to delegate routing decisions to third parties and to mark 113 certain requests as having special characteristics while preventing 114 these characteristics from being accidentally invoked. 116 This URN identifies services independent of the particular protocol 117 that is used to request or deliver the service. The URN may appear 118 in protocols that allow general URIs, such as the Session Initiation 119 Protocol (SIP) [4] request URIs, web pages or mapping protocols. 121 The service URN is a protocol element and generally not expected to 122 be visible to humans. For example, it is expected that callers will 123 still dial the emergency number '9-1-1' in the United States to reach 124 emergency services. In some other cases, speed dial buttons might 125 identify the service, as is common practice on hotel phones today. 126 (Speed dial buttons for summoning emergency help are considered 127 inappropriate by most emergency services professionals, at least for 128 mobile devices, as they are too prone to being triggered 129 accidentally.) Rather, protocols would carry the service URN 130 described here, allowing universal identification. 132 The translation of service dial strings or service numbers to service 133 URNs in the end host is beyond the scope of this document. These 134 translations likely depend on the location of the caller and may be 135 many-to-one, i.e., several service numbers may map to one service 136 URN. For example, a phone for a traveler could recognize the 137 emergency service number for both the traveler's home location and 138 the traveler's visited location, mapping both to the same universal 139 service URN, urn:service:sos. 141 Since service URNs are not routable, a SIP proxy or user agent has to 142 translate the service URN into a routable URI for a location- 143 appropriate service provider, such as a SIP URL. LoST [17] is 144 expected to be used as a resolution system for mapping service URNs 145 to URLs based on geographic location. In the future, there may be 146 several such protocols, possibly different ones for different 147 services. 149 Services are described by top-level service type, and may contain a 150 hierarchy of sub-services further describing the service, as outlined 151 in Section 3. 153 We discuss alternative approaches for creating service identifiers, 154 and why they are unsatisfactory, in Appendix A. 156 2. Terminology 158 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 159 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 160 and "OPTIONAL" are to be interpreted as described in RFC 2119 [2]. 162 Terminology specific to emergency services is defined in [19]. 164 3. Registration Template 166 Below, we include the registration template for the URN scheme 167 according to RFC 3406 [12]. 168 Namespace ID: service 169 Registration Information: Registration version: 1; registration date: 170 2006-04-02 172 Declared registrant of the namespace: TBD 174 Declaration of syntactic structure: The URN consists of a 175 hierarchical service identifier, with a sequence of labels 176 separated by periods. The left-most label is the most significant 177 one and is called 'top-level service', while names to the right 178 are called 'sub-services'. The set of allowable characters is the 179 same as that for domain names [1] and a subset of the labels 180 allowed in [5]. Labels are case-insensitive and MUST be specified 181 in all lower-case. For any given service URN, service-identifiers 182 can be removed right-to-left and the resulting URN is still valid, 183 referring a more generic service. In other words, if a service 184 'x.y.z' exists, the URNs 'x' and 'x.y' are also valid service 185 URNs. 187 "URN:service:" service 188 service = top-level *("." sub-service) 189 let-dig = ALPHA / DIGIT 190 let-dig-hyp = let-dig / '-' 191 sub-service = let-dig [ *let-dig-hyp let-dig ] 192 top-level = let-dig [ *25let-dig-hyp let-dig ] 194 Relevant ancillary documentation: None 196 Community considerations: The service URN is believed to be relevant 197 to a large cross-section of Internet users, including both 198 technical and non-technical users, on a variety of devices, but 199 particularly for mobile and nomadic users. The service URN will 200 allow Internet users needing services to identify the service by 201 kind, without having to determine manually who provides the 202 particular service in the user's current context, e.g., at the 203 user's current location. For example, travelers will be able to 204 use their mobile devices to request emergency services without 205 having to know the emergency dial string of the visited country. 206 The assignment of identifiers is described in the IANA 207 Considerations (Section 4). The service URN does not prescribe a 208 particular resolution mechanism, but it is assumed that a number 209 of different entities could operate and offer such mechanisms. 211 Namespace considerations: There do not appear to be other URN 212 namespaces that serve the same need of uniquely identifying 213 widely-available communication and information services. Unlike 214 most other currently registered URN namespaces, the service URN 215 does not identify documents and protocol objects (e.g., [9], [10], 216 [15], [16]), types of telecommunications equipment [14], people or 217 organizations [8]. tel URIs [13] identify telephone numbers, but 218 numbers commonly identifying services, such as 911 or 112, are 219 specific to a particular region or country. 221 Identifier uniqueness considerations: A service URN identifies a 222 logical service, specified in the service registration (see IANA 223 Considerations (Section 4)). Resolution of the URN, if 224 successful, will return a particular instance of the service, and 225 this instance may be different even for two users making the same 226 request in the same place at the same time; the logical service 227 identified by the URN, however, is persistent and unique. Service 228 URNs MUST be unique for each unique service; this is guaranteed 229 through the registration of each service within this namespace, 230 described in Section 4. 232 Identifier persistence considerations: The 'service' URN for the same 233 service is expected to be persistent, although there naturally 234 cannot be a guarantee that a particular service will continue to 235 be available globally or at all times. 237 Process of identifier assignment: The process of identifier 238 assignment is described in the IANA Considerations (Section 4). 240 Process for identifier resolution: There is no single global 241 resolution service for 'service' URNs. However, each top-level 242 service can provide a set of mapping protocols to be used with 243 'service' URNs of that service. 245 Rules for Lexical Equivalence: 'service' identifiers are compared 246 according to case-insensitive string equality. 248 Conformance with URN Syntax: The BNF in the 'Declaration of syntactic 249 structure' above constrains the syntax for this URN scheme. 251 Validation mechanism: Validation determines whether a given string is 252 currently a validly-assigned URN [12]. Due to the distributed 253 nature of the mapping mechanism and since not all services are 254 available everywhere and not all mapping servers may be configured 255 with all current service registrations, validation in this sense 256 is not possible. Also, the discovery mechanism for the mapping 257 mechanism may not be configured with all current top-level 258 services. 260 Scope: The scope for this URN is public and global. 262 4. IANA Considerations 264 4.1 New Service-Identifying Labels 266 Services and sub-services are identified by labels managed by IANA, 267 according to the processes outlined in [3] in a new registry called 268 "Service URN Labels". Thus, creating a new service requires IANA 269 action. The policy for adding top-level service labels is 'Standards 270 Action'. (This document defines the top-level service 'sos' and 271 'counseling'.) The policy for assigning labels to sub-services may 272 differ for each top-level service designation and MUST be defined by 273 the document describing the top-level service. 275 Entries in the registration table have the following format 277 Service Reference Description 278 -------------------------------------------------------------------- 279 foo RFCxyz Brief description of the 'foo' top-level service 280 foo.bar RFCabc Description of the 'foo.bar' service 282 To allow use within the constraints of S-NAPTR [5], all top-level 283 service names MUST NOT exceed 27 characters. 285 4.2 Sub-Services for the 'sos' Service 287 This section defines the first service registration within the IANA 288 registry defined in Section 4.1, using the top-level service label 289 'sos'. 291 The 'sos' service type describes emergency services requiring an 292 immediate response, typically offered by various branches of the 293 government or other public institutions. Additional sub-services can 294 be added after expert review and must be of general public interest 295 and have a similar emergency nature. The expert is designated by the 296 ECRIT working group, its successor, or, in their absence, the IESG. 297 The expert review should only approve emergency services that are 298 offered widely and in different countries, with approximately the 299 same caller expectation in terms of services rendered. The 'sos' 300 service is not meant to invoke general government, public 301 information, counseling or social services. 303 urn:service:sos The generic 'sos' service reaches a public safety 304 answering point (PSAP) which in turn dispatches aid appropriate to 305 the emergency. It encompasses all of the services listed below. 306 urn:service:sos.ambulance This service identifier reaches an 307 ambulance service that provides emergency medical assistance and 308 transportation. 309 urn:service:sos.animal-control Animal control is defined as control 310 of dogs, cats, and domesticated or undomesticated animals. 311 urn:service:sos.fire The 'fire' service identifier summons the fire 312 service, also known as the fire brigade or fire department. 313 urn:service:sos.gas The 'gas' service allows the reporting of natural 314 gas (and other flammable gas) leaks or other natural gas 315 emergencies. 316 urn:service:sos.marine The 'marine' service refers to maritime search 317 and rescue services such as those offered by the coast guard, 318 lifeboat or surf lifesavers. 319 urn:service:sos.mountain The 'mountain' service refers to mountain 320 rescue services, i.e., search and rescue activities that occur in 321 a mountainous environment, although the term is sometimes also 322 used to apply to search and rescue in other wilderness 323 environments. 324 urn:service:sos.physician The 'physician' emergency service connects 325 the caller to a physician referral service. 326 urn:service:sos.poison The 'poison' service refers to special 327 information centers set up to inform citizens about how to respond 328 to potential poisoning. These poison control centers maintain a 329 database of poisons and appropriate emergency treatment. 330 urn:service:sos.police The 'police' service refers to the police 331 department or other law enforcement authorities. 333 4.3 Sub-Services for the 'counseling' Service 335 The 'counseling' service type describes services where callers can 336 receive advice and support, often anonymous, but not requiring an 337 emergency response. (Naturally, such services may transfer callers 338 to an emergency service or summon such services if the situation 339 warrants.) Additional sub-services can be added after expert review 340 and should be of general public interest. The expert is chosen in 341 the same manner as describe for the 'sos' service. The expert review 342 should take into account whether these services are offered widely 343 and in different countries, with approximately the same caller 344 expectation in terms of services rendered. 345 urn:service:counseling The generic 'counseling' service reaches a 346 call center that transfers the caller based on his or her specific 347 needs. 349 urn:service:counseling.children The 'children' service refers to 350 counseling and support services that are specifically tailored to 351 the needs of children. Such services may, for example, provide 352 advice to run-aways or victims of child abuse. 354 urn:service:counseling.mental-health The 'mental-health' service 355 refers to the "diagnostic, treatment, and preventive care that 356 helps improve how persons with mental illness feel both physically 357 and emotionally as well as how they interact with other persons." 358 (U.S. Department of Health and Human Services) 360 urn:service:counseling.suicide The 'suicide' service refers to the 361 suicide prevention hotline. 363 4.4 Initial IANA Registration 365 The following table contains the initial IANA registration for 366 emergency and counseling services. 368 Service Reference Description 369 -------------------------------------------------------------------- 370 counseling RFC XYZ Counseling services 371 counseling.children RFC XYZ Counseling for children 372 counseling.mental-health RFC XYZ Mental health counseling 373 counseling.suicide RFC XYZ Suicide prevention hotline 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 385 [[NOTE TO RFC-EDITOR: Please replace above 'RFC XYZ' reference with 386 the RFC number of this document and remove this note.]] 388 5. Internationalization Considerations 390 The service labels are protocol elements [11] and not normally seen 391 by users. Thus, the character set for these elements is restricted, 392 as described in Section 3. 394 6. Security Considerations 396 As an identifier, the service URN does not appear to raise any 397 particular security issues. The services described by the URN are 398 meant to be well-known, even if the particular service instance is 399 access-controlled, so privacy considerations do not apply to the URN. 400 There are likely no specific privacy issues when including a service 401 URN on a web page, for example. On the other hand, ferrying the URN 402 in a signaling protocol can give attackers information on the kind of 403 service desired by the caller. For example, this makes it easier for 404 the attacker to automatically find all calls for emergency services 405 or directory assistance. Appropriate, protocol-specific security 406 mechanisms need to be implemented for protocols carrying service 407 URNs. The mapping protocol needs to address a number of threats, as 408 detailed in [18]. 410 7. References 412 7.1 Normative References 414 [1] Braden, R., "Requirements for Internet Hosts - Application and 415 Support", STD 3, RFC 1123, October 1989. 417 [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement 418 Levels", BCP 14, RFC 2119, March 1997. 420 [3] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA 421 Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. 423 [4] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 424 Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: 425 Session Initiation Protocol", RFC 3261, June 2002. 427 [5] Daigle, L. and A. Newton, "Domain-Based Application Service 428 Location Using SRV RRs and the Dynamic Delegation Discovery 429 Service (DDDS)", RFC 3958, January 2005. 431 7.2 Informative References 433 [6] Crocker, D., "MAILBOX NAMES FOR COMMON SERVICES, ROLES AND 434 FUNCTIONS", RFC 2142, May 1997. 436 [7] Resnick, P., "Internet Message Format", RFC 2822, April 2001. 438 [8] Mealling, M., "The Network Solutions Personal Internet Name 439 (PIN): A URN Namespace for People and Organizations", RFC 3043, 440 January 2001. 442 [9] Rozenfeld, S., "Using The ISSN (International Serial Standard 443 Number) as URN (Uniform Resource Names) within an ISSN-URN 444 Namespace", RFC 3044, January 2001. 446 [10] Hakala, J. and H. Walravens, "Using International Standard Book 447 Numbers as Uniform Resource Names", RFC 3187, October 2001. 449 [11] Hoffman, P., "Terminology Used in Internationalization in the 450 IETF", RFC 3536, May 2003. 452 [12] Daigle, L., van Gulik, D., Iannella, R., and P. Faltstrom, 453 "Uniform Resource Names (URN) Namespace Definition Mechanisms", 454 BCP 66, RFC 3406, October 2002. 456 [13] Schulzrinne, H., "The tel URI for Telephone Numbers", RFC 3966, 457 December 2004. 459 [14] Tesink, K. and R. Fox, "A Uniform Resource Name (URN) Namespace 460 for the Common Language Equipment Identifier (CLEI) Code", 461 RFC 4152, August 2005. 463 [15] Kang, S., "Using Universal Content Identifier (UCI) as Uniform 464 Resource Names (URN)", RFC 4179, October 2005. 466 [16] Kameyama, W., "A Uniform Resource Name (URN) Namespace for the 467 TV-Anytime Forum", RFC 4195, October 2005. 469 [17] Hardie, T., "LoST: A Location-to-Service Translation Protocol", 470 draft-ietf-ecrit-lost-00 (work in progress), June 2006. 472 [18] Taylor, T., "Security Threats and Requirements for Emergency 473 Call Marking and Mapping", draft-ietf-ecrit-security-threats-03 474 (work in progress), July 2006. 476 [19] Schulzrinne, H. and R. Marshall, "Requirements for Emergency 477 Context Resolution with Internet Technologies", 478 draft-ietf-ecrit-requirements-11 (work in progress), 479 August 2006. 481 Author's Address 483 Henning Schulzrinne 484 Columbia University 485 Department of Computer Science 486 450 Computer Science Building 487 New York, NY 10027 488 US 490 Phone: +1 212 939 7004 491 Email: hgs+ecrit@cs.columbia.edu 492 URI: http://www.cs.columbia.edu 494 Appendix A. Alternative Approaches Considered 496 The discussions of ways to identify emergency calls has yielded a 497 number of proposals. Since these are occasionally brought up during 498 discussions, we briefly summarize why this document chose not to 499 pursue these solutions. 500 tel:NNN;context=+C This approach uses tel URIs [13]. Here, NNN is 501 the national emergency number, where the country is identified by 502 the context C. This approach is easy for user agents to implement, 503 but hard for proxies and other SIP elements to recognize, as it 504 would have to know about all number-context combinations in the 505 world and track occasional changes. In addition, many of these 506 numbers are being used for other services. For example, the 507 emergency number in Paraguay (00) is also used to call the 508 international operator in the United States. As another example, 509 A number of countries, such as Italy, use 118 as an emergency 510 number, but it also connects to directory assistance in Finland. 512 tel:sos This solution avoids name conflicts, but is not a valid "tel" 513 [13] URI. It also only works if every outbound proxy knows how to 514 route requests to a proxy that can reach emergency services since 515 tel URIs. The SIP URI proposed here only requires a user's home 516 domain to be appropriately configured. 518 sip:sos@domain Earlier work had defined a special user identifier, 519 sos, within the caller's home domain in a SIP URI, for example, 520 sip:sos@example.com. Such a user identifier follows the 521 convention of RFC 2142 [6] and the "postmaster" convention 522 documented in RFC 2822 [7]. This approach had the advantage that 523 dial plans in existing user agents could probably be converted to 524 generate such a URI and that only the home proxy for the domain 525 has to understand the user naming convention. However, it 526 overloads the user part of the URI with specific semantics rather 527 than being opaque, makes routing by the outbound proxy a special 528 case that does not conform to normal SIP request-URI handling 529 rules and is SIP-specific. The mechanism also does not extend 530 readily to other services. 532 SIP URI user parameter: One could create a special URI, such as "aor- 533 domain;user=sos". This avoids the name conflict problem, but 534 requires mechanism-aware user agents that are capable of emitting 535 this special URI. Also, the 'user' parameter is meant to describe 536 the format of the user part of the SIP URI, which this usage does 537 not do. Adding other parameters still leaves unclear what, if 538 any, conventions should be used for the user and domain part of 539 the URL. Neither solution is likely to be backward-compatible 540 with existing clients. 542 Special domain: A special domain, such as "sip:fire@sos.int" could be 543 used to identify emergency calls. This has similar properties as 544 the "tel:sos" URI, except that it is indeed a valid URI. To make 545 this usable, the special domain would have to be operational and 546 point to an appropriate emergency services proxy. Having a 547 single, if logical, emergency services proxy for the whole world 548 seems to have undesirable scaling and administrative properties. 550 Appendix B. Acknowledgments 552 This document is based on discussions with Jonathan Rosenberg and 553 benefited from the comments of Leslie Daigle, Keith Drage, Benja 554 Fallenstein, Paul Kyzivat, Andrew Newton, Brian Rosen, Jonathan 555 Rosenberg, Martin Thomson and Hannes Tschofenig. 557 Intellectual Property Statement 559 The IETF takes no position regarding the validity or scope of any 560 Intellectual Property Rights or other rights that might be claimed to 561 pertain to the implementation or use of the technology described in 562 this document or the extent to which any license under such rights 563 might or might not be available; nor does it represent that it has 564 made any independent effort to identify any such rights. Information 565 on the procedures with respect to rights in RFC documents can be 566 found in BCP 78 and BCP 79. 568 Copies of IPR disclosures made to the IETF Secretariat and any 569 assurances of licenses to be made available, or the result of an 570 attempt made to obtain a general license or permission for the use of 571 such proprietary rights by implementers or users of this 572 specification can be obtained from the IETF on-line IPR repository at 573 http://www.ietf.org/ipr. 575 The IETF invites any interested party to bring to its attention any 576 copyrights, patents or patent applications, or other proprietary 577 rights that may cover technology that may be required to implement 578 this standard. Please address the information to the IETF at 579 ietf-ipr@ietf.org. 581 Disclaimer of Validity 583 This document and the information contained herein are provided on an 584 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 585 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 586 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 587 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 588 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 589 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 591 Copyright Statement 593 Copyright (C) The Internet Society (2006). This document is subject 594 to the rights, licenses and restrictions contained in BCP 78, and 595 except as set forth therein, the authors retain all their rights. 597 Acknowledgment 599 Funding for the RFC Editor function is currently provided by the 600 Internet Society.