idnits 2.17.1 draft-ietf-ecrit-service-urn-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 14. -- Found old boilerplate from RFC 3978, Section 5.5 on line 543. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 520. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 527. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 533. ** 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 (April 2, 2006) is 6599 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: '2' is defined on line 362, but no explicit reference was found in the text == Unused Reference: '7' is defined on line 381, but no explicit reference was found in the text == Unused Reference: '9' is defined on line 387, but no explicit reference was found in the text == Unused Reference: '11' is defined on line 393, 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. '10') (Obsoleted by RFC 5322) -- Obsolete informational reference (is this intentional?): RFC 2915 (ref. '11') (Obsoleted by RFC 3401, RFC 3402, RFC 3403, RFC 3404) -- Obsolete informational reference (is this intentional?): RFC 3044 (ref. '13') (Obsoleted by RFC 8254) -- Obsolete informational reference (is this intentional?): RFC 3187 (ref. '14') (Obsoleted by RFC 8254) -- Obsolete informational reference (is this intentional?): RFC 3406 (ref. '15') (Obsoleted by RFC 8141) == Outdated reference: A later version (-05) exists of draft-ietf-ecrit-security-threats-00 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: October 4, 2006 April 2, 2006 6 A Uniform Resource Name (URN) for Services 7 draft-ietf-ecrit-service-urn-02 9 Status of this Memo 11 By submitting this Internet-Draft, each author represents that any 12 applicable patent or other IPR claims of which he or she is aware 13 have been or will be disclosed, and any of which he or she becomes 14 aware will be disclosed, in accordance with Section 6 of BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on October 4, 2006. 34 Copyright Notice 36 Copyright (C) The Internet Society (2006). 38 Abstract 40 The content of many communication services depend on the context, 41 such as the user's location. We describe a 'service' URN that allows 42 to register such context-dependent services that can be resolved in a 43 distributed manner. 45 Table of Contents 47 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 48 2. Registration Template . . . . . . . . . . . . . . . . . . . . 4 49 3. Finding the Mapping Server . . . . . . . . . . . . . . . . . . 6 50 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 51 4.1 New Service-Identifying Tokens . . . . . . . . . . . . . . 7 52 4.2 S-NAPTR Application Service Label . . . . . . . . . . . . 7 53 4.3 sos Service Types . . . . . . . . . . . . . . . . . . . . 7 54 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 55 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 56 6.1 Normative References . . . . . . . . . . . . . . . . . . . 9 57 6.2 Informative References . . . . . . . . . . . . . . . . . . 9 58 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 10 59 A. Alternative Approaches Considered . . . . . . . . . . . . . . 11 60 B. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 61 Intellectual Property and Copyright Statements . . . . . . . . 13 63 1. Introduction 65 In existing telecommunications systems, there are many well-known 66 communication and information services that are offered by loosely 67 coordinated entities across a large geographic region, with well- 68 known identifiers. Some of the services are operated by governments 69 or regulated monopolies, others by competing commercial enterprises. 70 Examples include emergency services (reached by dialing 911 in North 71 America, 112 in Europe), community services and volunteer 72 opportunities (211 in some regions of the United States),telephone 73 directory and repair services (411 and 611 in the United States and 74 Canada), government information services (311 in some cities in the 75 United States), lawyer referral services (1-800-LAWYER), car roadside 76 assistance (automobile clubs) and pizza delivery services. 77 Unfortunately, almost all of them are limited in scope to a single 78 country or possibly a group of countries, such as those belonging to 79 the North American Numbering Plan or the European Union. The same 80 identifiers are often used for other purposes outside that region, 81 making accessing such services difficult when users travel or use 82 devices produced outside their home country. 84 These services are characterized by long-term stability of user- 85 visible identifiers, decentralized administration of the underlying 86 service and a well-defined resolution mechanism. (For example, there 87 is no national coordination or call center for "9-1-1" in the United 88 States; rather, various local government organizations cooperate to 89 provide this service, based on jurisdictions.) 91 In this document, we propose a URN namespace that, together with 92 resolution protocols beyond the scope of this document, allows to 93 define such global, well-known services, while distributing the 94 actual implementation across a large number of service-providing 95 entities. There are many ways to divide provision of such services, 96 such as dividing responsibility by geographic region or by the 97 service provider a user chooses. In addition, users can choose 98 different directory providers that in turn manage how geographic 99 locations are mapped to service providers. 101 Availability of such service identifiers simplifies end system 102 configuration. For example, an IP phone could have a special set of 103 short cuts or buttons that invoke emergency services, as it would not 104 be practical to manually re-configure the device with local emergency 105 contacts for each city or town a user visits with his or her mobile 106 device. Also, such identifiers allow to delegate routing decisions 107 to third parties and mark certain requests as having special 108 characteristics while preventing these characteristics to be 109 accidentally invoked on inappropriate requests. 111 This URN allows to identify services independent of a particular 112 protocol to deliver the services. It may appear in protocols that 113 allow general URIs, such as the Session Initiation Protocol (SIP) [5] 114 request URIs, web pages or mapping protocols. 116 The service URN is generally not expected to be visible to humans. 117 For example, it is expected that callers will still dial '9-1-1' in 118 the United States to reach emergency services. In some other cases, 119 speed dial buttons might identify the service, as is common practice 120 on hotel phones today. (Speed dial buttons for summoning emergency 121 help are considered inappropriate by most emergency services 122 professionals, at least for mobile devices, as they are too prone to 123 being triggered accidentally.) Rather, protocol elements would carry 124 the service URN described here, allowing universal identification. 125 The translation of dial strings to service URNs is beyond the scope 126 of this document; it is likely to depend on the location of the 127 caller and may be many-to-one. For example, a phone for a traveler 128 could recognize the emergency dial string for both the traveler's 129 home location and the traveler's visited location, translating both 130 to the same universal service URN, urn:service:sos. 132 Since service URNs are not routable, a proxy or user agent has to 133 translate the service URN into a routable URI for a location- 134 appropriate service provider, such as a SIP URL. LoST [20] is one 135 resolution system for mapping service URNs to URLs based on 136 geographic location. It is anticipated that there will be several 137 such systems, possibly with different systems for different services. 139 We discuss alternative approaches, and why they are unsatisfactory, 140 in Appendix A. 142 2. Registration Template 144 Below, we include the registration template for the URN scheme 145 according to RFC 3406 [15]. 146 Namespace ID: service 147 Registration Information: Registration version: 1; registration date: 148 2006-04-02 149 Declared registrant of the namespace: TBD 150 Declaration of syntactic structure: The URN consists of a 151 hierarchical service identifier, with a sequence of labels 152 separated by periods. The left-most label is the most significant 153 one and is called 'top-level service', while names to the right 154 are called 'sub-services'. The set of allowable characters is the 155 same as that for domain names [1] and a subset of the labels 156 allowed in [6]; labels are case-insensitive and SHOULD be 157 specified in all lower-case. Any string of service labels can be 158 used to request services that are either more generic or more 159 specific. In other words, if a service 'x.y.z' exists, the URNs 160 'x' and 'x.y' are also valid service URNs. 162 "URN:service:" service 163 service = top-level *("." service-identifier) 164 let-dig = ALPHA / DIGIT 165 let-dig-hyp = let-dig / '-' 166 service-identifier = let-dig [ *let-dig-hyp let-dig ] 167 top-level = let-dig [ *25let-dig-hyp let-dig ] 169 Relevant ancillary documentation: None 170 Community considerations: The service URN is believe to be relevant 171 to a large cross-section of Internet users, including both 172 technical and non-technical users, on a variety of devices, but 173 particularly for mobile and nomadic users. The service URN will 174 allow Internet users needing services to identify the service by 175 kind, without having to determine manually who provides the 176 particular service in the user's current context, e.g., at his 177 current location. For example, a traveler will be able to use his 178 mobile device to request emergency services without having to know 179 the local emergency number. The assignment of identifiers is 180 described in the IANA Considerations (Section 4). The service URN 181 does not prescribe a particular resolution mechanism, but it is 182 assumed that a number of different entities could operate and 183 offer such mechanisms. 184 Namespace considerations: There do not appear to be other URN 185 namespaces that serve the same need of uniquely identifying 186 widely-available communication and information services. Unlike 187 most other currently registered URN namespaces, the service URN 188 does not identify documents and protocol objects (e.g., [13], 189 [14], [18], [19]), types of telecommunications equipment [17], 190 people or organizations [12]. tel URIs [16] identify telephone 191 numbers, but numbers commonly identifying services, such as 911 or 192 112, are specific to a particular region or country. 193 Identifier uniqueness considerations: A service URN identifies a 194 logical service, specified in the service registration (see IANA 195 considerations). Resolution of the URN, if successful, will 196 return a particular instance of the service, and this instance may 197 be different even for two users making the same request in the 198 same place at the same time; the logical service identified by the 199 URN, however, is persistent and unique. Service URNs MUST be 200 unique for each unique service; this is guaranteed through the 201 registration of each service within this namespace, described in 202 Section 4. 204 Identifier persistence considerations: The 'service' URN for the same 205 service is expected to be persisent, although there naturally 206 cannot be a guarantee that a particular service will continue to 207 be available globally or at all times. 208 Process of identifier assignment: The process of identifier 209 assignment is described in the IANA Considerations (Section 4). 210 Process for identifier resolution: 'service' identifiers are resolved 211 by the mapping protocols, an instance of a Resolution Discovery 212 System (RDS) as described in RFC 2276 [3]. Each top-level service 213 can provide its own distinct set of mapping protocols. Within 214 each top-level service, all mapping protocols MUST return the same 215 set of mappings. Section 3 describes how DNS NAPTR records are 216 used to find an instance of a mapping service. 217 Rules for Lexical Equivalence: 'service' identifiers are compared 218 according to case-insensitive string equality. 219 Conformance with URN Syntax: There are no special considerations. 220 Validation mechanism: The RDS mechanism is also used to validate the 221 existence of a resource. As noted, by its design, the 222 availability of a resource may depend on where service is desired 223 and there may not be service available in all or most locations. 224 (For example, roadside assistance service is unlikely to be 225 available on about 70% of the earth's surface.) 226 Scope: The scope for this URN is public and global. 228 3. Finding the Mapping Server 230 When a network entity receives a service URN, it uses the S-NAPTR [6] 231 mechanism to determine how to map the service URN, possibly using 232 other information such as geographic location, to a routable URI. 233 Each top-level service may define one or more such mapping protocols 234 and mapping protocol servers may be operated by a range of providers. 235 Thus, the network entity that needs to resolve the service URN 236 queries an appropriate domain, typically its home or service provider 237 domain, for NAPTR records and then selects records that match the 238 service and the mapping protocols it supports. The application 239 service for this URN is registered in IANA Considerations (Section 4) 240 of this document; the application protocols are registered in the 241 appropriate protocol document. 243 The S-NAPTR entry MAY contain the "s" flag if the resolving client 244 needs to perform an SRV resolution on the replacement string. 246 The first entry in the following example indicates that 'sos' service 247 URNs should be mapped to URIs using the LoST [20] protocol server at 248 lost.example.com, a DNS A record. The second entry is for an 249 imaginary top-level service 'pizza', using the equally imagined 250 'Pizza Location Protocol', offered by the pizzahouse.example.net 251 server, which should be queried for the appropriate DNS SRV record. 253 Note that these NAPTR records are maintained by example.com, i.e., 254 example.com does not actually provide the mapping service itself. 256 example.com. 257 ; order pref flags service regexp 258 IN NAPTR 50 50 "a" "SURN.sos:LoST" "" 259 ; replacement 260 lost.example.org 262 IN NAPTR 10 50 "s" "SURN.pizza:PLP" "" 263 _plp._tcp.pizzahouse.example.net 265 4. IANA Considerations 267 4.1 New Service-Identifying Tokens 269 New service-identifying tokens and sub-registrations are to be 270 managed by IANA, according to the processes outlined in [4]. The 271 policy for top-level service names is 'IETF Consensus'. The policy 272 for assigning names to sub-services may differ for each top-level 273 service designation and MUST be defined by the document describing 274 the top-level service. 276 To allow use within the constraints of S-NAPTR [6], all top-level 277 service names MUST NOT exceed 27 characters. 279 4.2 S-NAPTR Application Service Label 281 Since each top-level service could use one or more different 282 resolution protocols, we need to indicate the top-level service in 283 the S-NAPTR application service label. To indicate the URN-to- 284 service mapping service, all such services start with the string 285 "SURN." (for "service URN"), followed by the top-level service 286 identifier. Note that application service labels are case- 287 insensitive and rendered here in mixed case purely for readability. 289 This document registers the label "SURN.sos" as the S-NAPTR 290 application service label according to [6] for emergency services and 291 defines the intended usage, interoperability considerations and 292 security considerations (Section 5). 294 4.3 sos Service Types 296 The 'sos' service type describes emergency services and services 297 related to public safety and health, typically offered by various 298 branches of the government or other public institutions. Additional 299 sub-services can be added after expert review and should be of 300 general public interest. 302 urn:service:sos The generic 'sos' service reaches a public safety 303 answering point (PSAP), that in turn dispatches aid appropriate to 304 the emergency. It encompasses all of the services listed below. 305 urn:service:sos.ambulance This service identifier reaches an 306 ambulance service that provides emergency medical assistance and 307 transportation. 308 urn:service:sos.animal-control Animal control is defined as control 309 of dogs, cats, and domesticated or undomesticated animals. 310 urn:service:sos.fire The 'fire' service identifier summons the fire 311 service, also known as the fire brigade or fire department. 312 urn:service:sos.gas The 'gas' service allows the reporting of natural 313 gas (and other flammable gas) leaks or other natural gas 314 emergencies. 315 urn:service:sos.mountain The 'mountain' service refers to mountain 316 rescue services, i.e., search and rescue activities that occur in 317 a mountainous environment, although the term is sometimes also 318 used to apply to search and rescue in other wilderness 319 environments. 320 urn:service:sos.marine The 'marine' service refers to maritime search 321 and rescue services such as those offered by the coast guard, 322 lifeboat or surf lifesavers. 323 urn:service:sos.physician The 'physician' emergency service connects 324 the caller to a physician referral service. 325 urn:service:sos.poison The 'poison' service refers to special 326 information centers set up to inform citizens about how to respond 327 to potential poisoning. These poison control centers maintain a 328 database of poisons and appropriate emergency treatment. 329 urn:service:sos.police The 'police' service refers to the police 330 department or other law enforcement authorities. 331 urn:service:sos.suicide The 'suicide' service refers to the suicide 332 prevention hotline. 333 urn:service:sos.mental-health The 'mental-health' service refers to 334 the "Diagnostic, treatment, and preventive care that helps improve 335 how persons with mental illness feel both physically and 336 emotionally as well as how they interact with other persons." 337 (U.S. Department of Health and Human Services) 339 5. Security Considerations 341 As an identifier, the service URN does not appear to raise any 342 particular security issues. The services described by the URN are 343 meant to be well-known, even if the particular service instance is 344 access-controlled, so privacy considerations do not apply to the URN. 345 There are likely no specific privacy issues when including a service 346 URN on a web page, for example. On the other hand, ferrying the URN 347 in a signaling protocol can give attackers information on the kind of 348 service desired by the caller. For example, this makes it easier for 349 the attacker to automatically find all calls for emergency services 350 or directory assistance. Appropriate, protocol-specific security 351 mechanisms need to be implemented for protocols carrying service 352 URNs. The mapping protocol needs to address a number of threats, as 353 detailed in [21]. 355 6. References 357 6.1 Normative References 359 [1] Braden, R., "Requirements for Internet Hosts - Application and 360 Support", STD 3, RFC 1123, October 1989. 362 [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement 363 Levels", BCP 14, RFC 2119, March 1997. 365 [3] Sollins, K., "Architectural Principles of Uniform Resource Name 366 Resolution", RFC 2276, January 1998. 368 [4] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA 369 Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. 371 [5] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 372 Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: 373 Session Initiation Protocol", RFC 3261, June 2002. 375 [6] Daigle, L. and A. Newton, "Domain-Based Application Service 376 Location Using SRV RRs and the Dynamic Delegation Discovery 377 Service (DDDS)", RFC 3958, January 2005. 379 6.2 Informative References 381 [7] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, 382 March 1997. 384 [8] Crocker, D., "MAILBOX NAMES FOR COMMON SERVICES, ROLES AND 385 FUNCTIONS", RFC 2142, May 1997. 387 [9] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for 388 specifying the location of services (DNS SRV)", RFC 2782, 389 February 2000. 391 [10] Resnick, P., "Internet Message Format", RFC 2822, April 2001. 393 [11] Mealling, M. and R. Daniel, "The Naming Authority Pointer 394 (NAPTR) DNS Resource Record", RFC 2915, September 2000. 396 [12] Mealling, M., "The Network Solutions Personal Internet Name 397 (PIN): A URN Namespace for People and Organizations", RFC 3043, 398 January 2001. 400 [13] Rozenfeld, S., "Using The ISSN (International Serial Standard 401 Number) as URN (Uniform Resource Names) within an ISSN-URN 402 Namespace", RFC 3044, January 2001. 404 [14] Hakala, J. and H. Walravens, "Using International Standard Book 405 Numbers as Uniform Resource Names", RFC 3187, October 2001. 407 [15] Daigle, L., van Gulik, D., Iannella, R., and P. Faltstrom, 408 "Uniform Resource Names (URN) Namespace Definition Mechanisms", 409 BCP 66, RFC 3406, October 2002. 411 [16] Schulzrinne, H., "The tel URI for Telephone Numbers", RFC 3966, 412 December 2004. 414 [17] Tesink, K. and R. Fox, "A Uniform Resource Name (URN) Namespace 415 for the Common Language Equipment Identifier (CLEI) Code", 416 RFC 4152, August 2005. 418 [18] Kang, S., "Using Universal Content Identifier (UCI) as Uniform 419 Resource Names (URN)", RFC 4179, October 2005. 421 [19] Kameyama, W., "A Uniform Resource Name (URN) Namespace for the 422 TV-Anytime Forum", RFC 4195, October 2005. 424 [20] Hardie, T., "LoST: A Location-to-Service Translation Protocol", 425 draft-hardie-ecrit-lost-00 (work in progress), March 2006. 427 [21] Taylor, T., "Security Threats and Requirements for Emergency 428 Call Marking and Mapping", draft-ietf-ecrit-security-threats-00 429 (work in progress), March 2006. 431 Author's Address 433 Henning Schulzrinne 434 Columbia University 435 Department of Computer Science 436 450 Computer Science Building 437 New York, NY 10027 438 US 440 Phone: +1 212 939 7004 441 Email: hgs+ecrit@cs.columbia.edu 442 URI: http://www.cs.columbia.edu 444 Appendix A. Alternative Approaches Considered 446 The "sos" SIP URI reserved user name proposed here follows the 447 convention of RFC 2142 [8] and the "postmaster" convention documented 448 in RFC 2822 [10]. The approach has the advantage that only the home 449 proxy for a user needs to understand the convention and that the 450 mechanism is likely backwards-compatible with most SIP user agents, 451 with the only requirement that they have to be able to generate 452 alphanumeric URLs. One drawback is that it may conflict with locally 453 assigned addresses of the form "sos@domain". Also, if proxies not 454 affiliated with the domain translate the URL, they violate the 455 current SIP protocol conventions. 457 There are a number of possible alternatives, each with their own set 458 of advantages and problems: 460 tel:NNN;context=+C This approach uses tel URIs [16]. Here, NNN is 461 the national emergency number, where the country is identified by 462 the context C. This approach is easy for user agents to implement, 463 but hard for proxies and other SIP elements to recognize, as it 464 would have to know about all number-context combinations in the 465 world and track occasional changes. In addition, many of these 466 numbers are being used for other services. For example, the 467 emergency number in Paraguay (00) is also used to call the 468 international operator in the United States. A number of 469 countries, such as Italy, use 118 as an emergency number, but it 470 also connects to directory assistance in Finland. 471 tel:sos This solution avoids name conflicts, but is not a valid "tel" 472 [16] URI. It also only works if every outbound proxy knows how to 473 route requests to a proxy that can reach emergency services since 474 tel URIs. The SIP URI proposed here only requires a user's home 475 domain to be appropriately configured. 477 sip:sos@domain Earlier work had defined a special user identifier, 478 sos, within the caller's home domain in a SIP URI, for example, 479 sip:sos@example.com. This approach had the advantage that dial 480 plans in existing user agents could probably be converted to 481 generate such a URI and that only the home proxy for the domain 482 has to understand the user naming convention. However, it 483 overloads the user part of the URI with specific semantics rather 484 than being opaque, makes routing by the outbound proxy a special 485 case that does not conform to normal SIP request-URI handling 486 rules and is SIP-specific. The mechanism also does not extend 487 readily to other services. 488 SIP URI user parameter: One could create a special URI, such as "aor- 489 domain;user=sos". This avoids the name conflict problem, but 490 requires mechanism-aware user agents that are capable of emitting 491 this special URI. Also, the 'user' parameter is meant to describe 492 the format of the user part of the SIP URI, which this usage does 493 not do. Adding other parameters still leaves unclear what, if 494 any, conventions should be used for the user and domain part of 495 the URL. Neither solution is likely to be backward-compatible 496 with existing clients. 497 Special domain: A special domain, such as "sip:fire@sos.int" could be 498 used to identify emergency calls. This has similar properties as 499 the "tel:sos" URI, except that it is indeed a valid URI. To make 500 this usable, the special domain would have to be operational and 501 point to an appropriate emergency services proxy. Having a 502 single, if logical, emergency services proxy for the whole world 503 seems to have undesirable scaling and administrative properties. 505 Appendix B. Acknowledgments 507 This document is based on discussions with Jonathan Rosenberg and 508 benefitted from the comments of Leslie Daigle, Benja Fallenstein, 509 Paul Kyzivat, Andrew Newton, Jonathan Rosenberg and Martin Thomas. 511 Intellectual Property Statement 513 The IETF takes no position regarding the validity or scope of any 514 Intellectual Property Rights or other rights that might be claimed to 515 pertain to the implementation or use of the technology described in 516 this document or the extent to which any license under such rights 517 might or might not be available; nor does it represent that it has 518 made any independent effort to identify any such rights. Information 519 on the procedures with respect to rights in RFC documents can be 520 found in BCP 78 and BCP 79. 522 Copies of IPR disclosures made to the IETF Secretariat and any 523 assurances of licenses to be made available, or the result of an 524 attempt made to obtain a general license or permission for the use of 525 such proprietary rights by implementers or users of this 526 specification can be obtained from the IETF on-line IPR repository at 527 http://www.ietf.org/ipr. 529 The IETF invites any interested party to bring to its attention any 530 copyrights, patents or patent applications, or other proprietary 531 rights that may cover technology that may be required to implement 532 this standard. Please address the information to the IETF at 533 ietf-ipr@ietf.org. 535 Disclaimer of Validity 537 This document and the information contained herein are provided on an 538 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 539 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 540 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 541 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 542 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 543 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 545 Copyright Statement 547 Copyright (C) The Internet Society (2006). This document is subject 548 to the rights, licenses and restrictions contained in BCP 78, and 549 except as set forth therein, the authors retain all their rights. 551 Acknowledgment 553 Funding for the RFC Editor function is currently provided by the 554 Internet Society.