idnits 2.17.1 draft-ietf-ecrit-service-urn-03.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 620. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 597. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 604. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 610. ** 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 (May 19, 2006) is 6523 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: '7' is defined on line 453, but no explicit reference was found in the text == Unused Reference: '9' is defined on line 459, but no explicit reference was found in the text == Unused Reference: '11' is defined on line 465, 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 (-19) exists of draft-ietf-mmusic-ice-08 == Outdated reference: A later version (-05) exists of draft-ietf-ecrit-security-threats-01 == Outdated reference: A later version (-13) exists of draft-ietf-ecrit-requirements-09 Summary: 5 errors (**), 0 flaws (~~), 9 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: November 20, 2006 May 19, 2006 6 A Uniform Resource Name (URN) for Services 7 draft-ietf-ecrit-service-urn-03 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 November 20, 2006. 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 register such 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. Finding the Mapping Server . . . . . . . . . . . . . . . . . . 7 51 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 52 5.1 New Service-Identifying Labels . . . . . . . . . . . . . . 8 53 5.2 S-NAPTR Application Service Tag . . . . . . . . . . . . . 8 54 5.3 Sub-Services for the 'sos' Service . . . . . . . . . . . . 8 55 5.4 Sub-Services for the 'counseling' Service . . . . . . . . 9 56 6. International Considerations . . . . . . . . . . . . . . . . . 10 57 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 58 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 59 8.1 Normative References . . . . . . . . . . . . . . . . . . . 10 60 8.2 Informative References . . . . . . . . . . . . . . . . . . 11 61 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 12 62 A. Alternative Approaches Considered . . . . . . . . . . . . . . 12 63 B. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 64 Intellectual Property and Copyright Statements . . . . . . . . 15 66 1. Introduction 68 In existing telecommunications systems, there are many well-known 69 communication and information services that are offered by loosely 70 coordinated entities across a large geographic region, with well- 71 known identifiers. Some of the services are operated by governments 72 or regulated monopolies, others by competing commercial enterprises. 73 Examples include emergency services (reached by dialing 911 in North 74 America, 112 in Europe), community services and volunteer 75 opportunities (211 in some regions of the United States), telephone 76 directory and repair services (411 and 611 in the United States and 77 Canada), government information services (311 in some cities in the 78 United States), lawyer referral services (1-800-LAWYER), car roadside 79 assistance (automobile clubs) and pizza delivery services. 80 Unfortunately, almost all of them are limited in scope to a single 81 country or possibly a group of countries, such as those belonging to 82 the North American Numbering Plan or the European Union. The same 83 identifiers are often used for other purposes outside that region, 84 making accessing such services difficult when users travel or use 85 devices produced outside their home country. 87 These services are characterized by long-term stability of user- 88 visible identifiers, decentralized administration of the underlying 89 service and a well-defined resolution mechanism. (For example, there 90 is no national coordination or call center for "9-1-1" in the United 91 States; rather, various local government organizations cooperate to 92 provide this service, based on jurisdictions.) 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 directory providers that in turn manage how geographic 102 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 or buttons that invoke emergency services, as it would not 107 be practical to manually re-configure the device with local emergency 108 contacts for each city or town a user visits with his or her mobile 109 device. Also, such identifiers make it possible to delegate routing 110 decisions to third parties and to mark certain requests as having 111 special characteristics while preventing these characteristics to be 112 accidentally invoked on inappropriate requests. 114 This URN identifies services independent of a particular protocol to 115 deliver the services. It may appear in protocols that allow general 116 URIs, such as the Session Initiation Protocol (SIP) [5] request URIs, 117 web pages or mapping protocols. 119 The service URN is generally not expected to be visible to humans. 120 For example, it is expected that callers will still dial '9-1-1' in 121 the United States to reach emergency services. In some other cases, 122 speed dial buttons might identify the service, as is common practice 123 on hotel phones today. (Speed dial buttons for summoning emergency 124 help are considered inappropriate by most emergency services 125 professionals, at least for mobile devices, as they are too prone to 126 being triggered accidentally.) Rather, protocol elements would carry 127 the service URN described here, allowing universal identification. 128 The translation of dial strings to service URNs is beyond the scope 129 of this document; it is likely to depend on the location of the 130 caller and may be many-to-one. For example, a phone for a traveler 131 could recognize the emergency dial string for both the traveler's 132 home location and the traveler's visited location, translating both 133 to the same universal service URN, urn:service:sos. 135 Since service URNs are not routable, a proxy or user agent has to 136 translate the service URN into a routable URI for a location- 137 appropriate service provider, such as a SIP URL. LoST [21] is one 138 resolution system for mapping service URNs to URLs based on 139 geographic location. It is anticipated that there will be several 140 such systems, possibly with different systems for different services. 142 Services are described by top-level service type, and may contain a 143 hierarchy of sub-services further describing the service, as outlined 144 in Section 3. Mapping protocols SHOULD always provide a mapping just 145 for the top-level service even if sub-services are in use. This 146 mapping for the top-level service MAY also be used if an entity is 147 presented with an invalid sub-service and presenting an error 148 condition to the user is inappropriate, e.g., during an emergency. 150 We discuss alternative approaches for creating service identifiers, 151 and why they are unsatisfactory, in Appendix A. 153 2. Terminology 155 In this document, the key words "MUST", "MUST NOT", "REQUIRED", 156 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 157 and "OPTIONAL" are to be interpreted as described in RFC 2119 [2]. 159 Terminology specific to emergency services is defined in [23]. 161 3. Registration Template 163 Below, we include the registration template for the URN scheme 164 according to RFC 3406 [15]. 165 Namespace ID: service 166 Registration Information: Registration version: 1; registration date: 167 2006-04-02 169 Declared registrant of the namespace: TBD 171 Declaration of syntactic structure: The URN consists of a 172 hierarchical service identifier, with a sequence of labels 173 separated by periods. The left-most label is the most significant 174 one and is called 'top-level service', while names to the right 175 are called 'sub-services'. The set of allowable characters is the 176 same as that for domain names [1] and a subset of the labels 177 allowed in [6]. Labels are case-insensitive and SHOULD be 178 specified in all lower-case. For any given service URN, service- 179 identifiers can be removed right-to-left and the resulting URN is 180 still valid, referring a more generic service. In other words, if 181 a service 'x.y.z' exists, the URNs 'x' and 'x.y' are also valid 182 service URNs. 184 "URN:service:" service 185 service = top-level *("." sub-service) 186 let-dig = ALPHA / DIGIT 187 let-dig-hyp = let-dig / '-' 188 sub-service = let-dig [ *let-dig-hyp let-dig ] 189 top-level = let-dig [ *25let-dig-hyp let-dig ] 191 Relevant ancillary documentation: None 193 Community considerations: The service URN is believed to be relevant 194 to a large cross-section of Internet users, including both 195 technical and non-technical users, on a variety of devices, but 196 particularly for mobile and nomadic users. The service URN will 197 allow Internet users needing services to identify the service by 198 kind, without having to determine manually who provides the 199 particular service in the user's current context, e.g., at the 200 user's current location. For example, travelers will be able to 201 use their mobile devices to request emergency services without 202 having to know the emergency dial string of the visited country. 203 The assignment of identifiers is described in the IANA 204 Considerations (Section 5). The service URN does not prescribe a 205 particular resolution mechanism, but it is assumed that a number 206 of different entities could operate and offer such mechanisms. 208 Namespace considerations: There do not appear to be other URN 209 namespaces that serve the same need of uniquely identifying 210 widely-available communication and information services. Unlike 211 most other currently registered URN namespaces, the service URN 212 does not identify documents and protocol objects (e.g., [13], 213 [14], [18], [19]), types of telecommunications equipment [17], 214 people or organizations [12]. tel URIs [16] identify telephone 215 numbers, but numbers commonly identifying services, such as 911 or 216 112, are specific to a particular region or country. 218 Identifier uniqueness considerations: A service URN identifies a 219 logical service, specified in the service registration (see IANA 220 considerations). Resolution of the URN, if successful, will 221 return a particular instance of the service, and this instance may 222 be different even for two users making the same request in the 223 same place at the same time; the logical service identified by the 224 URN, however, is persistent and unique. Service URNs MUST be 225 unique for each unique service; this is guaranteed through the 226 registration of each service within this namespace, described in 227 Section 5. 229 Identifier persistence considerations: The 'service' URN for the same 230 service is expected to be persistent, although there naturally 231 cannot be a guarantee that a particular service will continue to 232 be available globally or at all times. 234 Process of identifier assignment: The process of identifier 235 assignment is described in the IANA Considerations (Section 5). 237 Process for identifier resolution: 'service' identifiers are resolved 238 by the mapping protocols, an instance of a Resolution Discovery 239 System (RDS) as described in RFC 2276 [3]. Each top-level service 240 can provide its own distinct set of mapping protocols. Within 241 each top-level service, all mapping protocols MUST return the same 242 set of mappings. Section 4 describes how the S-NAPTR mechanism is 243 used to find an instance of a mapping 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 [15]. The S-NAPTR mechanism also 253 allows to determine if a mapping protocol for a particular top- 254 level service exists. The mapping protocol itself would then 255 answer the question whether the service identifier exists. (The 256 issue of whether a particular combination of service and location 257 yields a usable answer is beyond the scope of this specification.) 259 Scope: The scope for this URN is public and global. 261 4. Finding the Mapping Server 263 When a network entity receives a service URN, it uses the S-NAPTR [6] 264 mechanism to determine how to map the service URN, possibly using 265 other information such as geographic location, to a routable URI. 266 Each top-level service may define one or more such mapping protocols 267 and mapping protocol servers may be operated by a range of providers. 268 Thus, the network entity that needs to resolve the service URN 269 queries an appropriate domain, typically its home or service provider 270 domain, for NAPTR records and then selects records that match the 271 service and the mapping protocols it supports. The application 272 service for this URN is registered in IANA Considerations (Section 5) 273 of this document; the application protocols are registered in the 274 appropriate protocol document. 276 try until a working server has been found DNS name provided by DHCP 277 (option X) reverse DNS lookup for all ICE derived addresses [20] 278 application service provider 280 The S-NAPTR entry MAY contain the "s" flag if the resolving client 281 needs to perform an SRV resolution on the replacement string. 283 The first entry in the following example indicates that 'sos' service 284 URNs should be mapped to URIs using the LoST [21] protocol server at 285 lost.example.com, a DNS A record. The second entry is for an 286 imaginary top-level service 'pizza', using the equally imagined 287 'Pizza Location Protocol', offered by the pizzahouse.example.net 288 server, which should be queried for the appropriate DNS SRV record. 289 Note that these NAPTR records are maintained by example.com, i.e., 290 example.com does not actually provide the mapping service itself. 292 example.com. 293 ; order pref flags service regexp 294 IN NAPTR 50 50 "a" "SURN.sos:LoST" "" 295 ; replacement 296 lost.example.org 298 IN NAPTR 10 50 "s" "SURN.pizza:PLP" "" 299 _plp._tcp.pizzahouse.example.net 301 5. IANA Considerations 303 5.1 New Service-Identifying Labels 305 New service-identifying labels and sub-services are to be managed by 306 IANA, according to the processes outlined in [4]. The policy for 307 top-level service names is 'IETF Consensus'. The policy for 308 assigning labels to sub-services may differ for each top-level 309 service designation and MUST be defined by the document describing 310 the top-level service. 312 To allow use within the constraints of S-NAPTR [6], all top-level 313 service names MUST NOT exceed 27 characters. 315 5.2 S-NAPTR Application Service Tag 317 Since each top-level service could use one or more different 318 resolution protocols, we need to indicate the top-level service in 319 the S-NAPTR application service tag. To indicate the URN-to-service 320 mapping service, all such services start with the string "SURN." (for 321 "service URN"), followed by the top-level service identifier. Note 322 that application service tags are case-insensitive and rendered here 323 in mixed case purely for readability. 325 This document effectively creates a sub-registry of labels under 326 SURN, but the contents of that registry are exactly the same as those 327 defined in Section 5.1 and thus no separate IANA action is needed. 329 This document registers the label "SURN.sos" as the S-NAPTR 330 application service tag according to [6] for emergency services and 331 defines the intended usage, interoperability considerations and 332 security considerations (Section 7). 334 5.3 Sub-Services for the 'sos' Service 336 The 'sos' service type describes emergency services requiring an 337 immediate response, typically offered by various branches of the 338 government or other public institutions. Additional sub-services can 339 be added after expert review and should be of general public interest 340 and have a similar emergency nature. The expert review should take 341 into account whether these emergency services are offered widely and 342 in different countries, with approximately the same caller 343 expectation in terms of services rendered. The 'sos' service is not 344 meant to invoke general government, public information or social 345 services. 347 urn:service:sos The generic 'sos' service reaches a public safety 348 answering point (PSAP) which in turn dispatches aid appropriate to 349 the emergency. It encompasses all of the services listed below. 350 urn:service:sos.ambulance This service identifier reaches an 351 ambulance service that provides emergency medical assistance and 352 transportation. 353 urn:service:sos.animal-control Animal control is defined as control 354 of dogs, cats, and domesticated or undomesticated animals. 355 urn:service:sos.fire The 'fire' service identifier summons the fire 356 service, also known as the fire brigade or fire department. 357 urn:service:sos.gas The 'gas' service allows the reporting of natural 358 gas (and other flammable gas) leaks or other natural gas 359 emergencies. 360 urn:service:sos.mountain The 'mountain' service refers to mountain 361 rescue services, i.e., search and rescue activities that occur in 362 a mountainous environment, although the term is sometimes also 363 used to apply to search and rescue in other wilderness 364 environments. 365 urn:service:sos.marine The 'marine' service refers to maritime search 366 and rescue services such as those offered by the coast guard, 367 lifeboat or surf lifesavers. 368 urn:service:sos.physician The 'physician' emergency service connects 369 the caller to a physician referral service. 370 urn:service:sos.poison The 'poison' service refers to special 371 information centers set up to inform citizens about how to respond 372 to potential poisoning. These poison control centers maintain a 373 database of poisons and appropriate emergency treatment. 374 urn:service:sos.police The 'police' service refers to the police 375 department or other law enforcement authorities. 376 urn:service:sos.suicide The 'suicide' service refers to the suicide 377 prevention hotline. 379 5.4 Sub-Services for the 'counseling' Service 381 The 'counseling' service type describes services where callers can 382 receive advice and support, often anonymous, but not requiring an 383 emergency response. (Naturally, such services may transfer callers 384 to an emergency service or summon such services if the situation 385 warrants.) Additional sub-services can be added after expert review 386 and should be of general public interest. The expert review should 387 take into account whether these services are offered widely and in 388 different countries, with approximately the same caller expectation 389 in terms of services rendered. 390 urn:service:counseling The generic 'counseling' service reaches a 391 call center that transfers the caller based on his or her specific 392 needs. 394 urn:service:counseling.mental-health The 'mental-health' service 395 refers to the "diagnostic, treatment, and preventive care that 396 helps improve how persons with mental illness feel both physically 397 and emotionally as well as how they interact with other persons." 398 (U.S. Department of Health and Human Services) 400 urn:service:counseling.children The 'children' service refers to 401 counseling and support services that are specifically tailored to 402 the needs of children. Such services may, for example, provide 403 advice to run-aways or victims of child abuse. 405 6. International Considerations 407 The service labels are protocol elements and not normally seen by 408 users. Thus, the character set for these elements is restricted, as 409 described in Section 3. 411 7. Security Considerations 413 As an identifier, the service URN does not appear to raise any 414 particular security issues. The services described by the URN are 415 meant to be well-known, even if the particular service instance is 416 access-controlled, so privacy considerations do not apply to the URN. 417 There are likely no specific privacy issues when including a service 418 URN on a web page, for example. On the other hand, ferrying the URN 419 in a signaling protocol can give attackers information on the kind of 420 service desired by the caller. For example, this makes it easier for 421 the attacker to automatically find all calls for emergency services 422 or directory assistance. Appropriate, protocol-specific security 423 mechanisms need to be implemented for protocols carrying service 424 URNs. The mapping protocol needs to address a number of threats, as 425 detailed in [22]. 427 8. References 429 8.1 Normative References 431 [1] Braden, R., "Requirements for Internet Hosts - Application and 432 Support", STD 3, RFC 1123, October 1989. 434 [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement 435 Levels", BCP 14, RFC 2119, March 1997. 437 [3] Sollins, K., "Architectural Principles of Uniform Resource Name 438 Resolution", RFC 2276, January 1998. 440 [4] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA 441 Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. 443 [5] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 444 Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: 445 Session Initiation Protocol", RFC 3261, June 2002. 447 [6] Daigle, L. and A. Newton, "Domain-Based Application Service 448 Location Using SRV RRs and the Dynamic Delegation Discovery 449 Service (DDDS)", RFC 3958, January 2005. 451 8.2 Informative References 453 [7] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, 454 March 1997. 456 [8] Crocker, D., "MAILBOX NAMES FOR COMMON SERVICES, ROLES AND 457 FUNCTIONS", RFC 2142, May 1997. 459 [9] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for 460 specifying the location of services (DNS SRV)", RFC 2782, 461 February 2000. 463 [10] Resnick, P., "Internet Message Format", RFC 2822, April 2001. 465 [11] Mealling, M. and R. Daniel, "The Naming Authority Pointer 466 (NAPTR) DNS Resource Record", RFC 2915, September 2000. 468 [12] Mealling, M., "The Network Solutions Personal Internet Name 469 (PIN): A URN Namespace for People and Organizations", RFC 3043, 470 January 2001. 472 [13] Rozenfeld, S., "Using The ISSN (International Serial Standard 473 Number) as URN (Uniform Resource Names) within an ISSN-URN 474 Namespace", RFC 3044, January 2001. 476 [14] Hakala, J. and H. Walravens, "Using International Standard Book 477 Numbers as Uniform Resource Names", RFC 3187, October 2001. 479 [15] Daigle, L., van Gulik, D., Iannella, R., and P. Faltstrom, 480 "Uniform Resource Names (URN) Namespace Definition Mechanisms", 481 BCP 66, RFC 3406, October 2002. 483 [16] Schulzrinne, H., "The tel URI for Telephone Numbers", RFC 3966, 484 December 2004. 486 [17] Tesink, K. and R. Fox, "A Uniform Resource Name (URN) Namespace 487 for the Common Language Equipment Identifier (CLEI) Code", 488 RFC 4152, August 2005. 490 [18] Kang, S., "Using Universal Content Identifier (UCI) as Uniform 491 Resource Names (URN)", RFC 4179, October 2005. 493 [19] Kameyama, W., "A Uniform Resource Name (URN) Namespace for the 494 TV-Anytime Forum", RFC 4195, October 2005. 496 [20] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A 497 Methodology for Network Address Translator (NAT) Traversal for 498 Offer/Answer Protocols", draft-ietf-mmusic-ice-08 (work in 499 progress), March 2006. 501 [21] Hardie, T., "LoST: A Location-to-Service Translation Protocol", 502 draft-hardie-ecrit-lost-00 (work in progress), March 2006. 504 [22] Taylor, T., "Security Threats and Requirements for Emergency 505 Call Marking and Mapping", draft-ietf-ecrit-security-threats-01 506 (work in progress), April 2006. 508 [23] Schulzrinne, H. and R. Marshall, "Requirements for Emergency 509 Context Resolution with Internet Technologies", 510 draft-ietf-ecrit-requirements-09 (work in progress), May 2006. 512 Author's Address 514 Henning Schulzrinne 515 Columbia University 516 Department of Computer Science 517 450 Computer Science Building 518 New York, NY 10027 519 US 521 Phone: +1 212 939 7004 522 Email: hgs+ecrit@cs.columbia.edu 523 URI: http://www.cs.columbia.edu 525 Appendix A. Alternative Approaches Considered 527 The discussions of ways to identify emergency calls has yielded a 528 number of proposals. Since these are occasionally brought up during 529 discussions, we briefly summarize why this document chose not to 530 pursue these solutions. 531 tel:NNN;context=+C This approach uses tel URIs [16]. Here, NNN is 532 the national emergency number, where the country is identified by 533 the context C. This approach is easy for user agents to implement, 534 but hard for proxies and other SIP elements to recognize, as it 535 would have to know about all number-context combinations in the 536 world and track occasional changes. In addition, many of these 537 numbers are being used for other services. For example, the 538 emergency number in Paraguay (00) is also used to call the 539 international operator in the United States. As another example, 540 A number of countries, such as Italy, use 118 as an emergency 541 number, but it also connects to directory assistance in Finland. 543 tel:sos This solution avoids name conflicts, but is not a valid "tel" 544 [16] URI. It also only works if every outbound proxy knows how to 545 route requests to a proxy that can reach emergency services since 546 tel URIs. The SIP URI proposed here only requires a user's home 547 domain to be appropriately configured. 549 sip:sos@domain Earlier work had defined a special user identifier, 550 sos, within the caller's home domain in a SIP URI, for example, 551 sip:sos@example.com. Such a user identifier follows the 552 convention of RFC 2142 [8] and the "postmaster" convention 553 documented in RFC 2822 [10]. This approach had the advantage that 554 dial plans in existing user agents could probably be converted to 555 generate such a URI and that only the home proxy for the domain 556 has to understand the user naming convention. However, it 557 overloads the user part of the URI with specific semantics rather 558 than being opaque, makes routing by the outbound proxy a special 559 case that does not conform to normal SIP request-URI handling 560 rules and is SIP-specific. The mechanism also does not extend 561 readily to other services. 563 SIP URI user parameter: One could create a special URI, such as "aor- 564 domain;user=sos". This avoids the name conflict problem, but 565 requires mechanism-aware user agents that are capable of emitting 566 this special URI. Also, the 'user' parameter is meant to describe 567 the format of the user part of the SIP URI, which this usage does 568 not do. Adding other parameters still leaves unclear what, if 569 any, conventions should be used for the user and domain part of 570 the URL. Neither solution is likely to be backward-compatible 571 with existing clients. 573 Special domain: A special domain, such as "sip:fire@sos.int" could be 574 used to identify emergency calls. This has similar properties as 575 the "tel:sos" URI, except that it is indeed a valid URI. To make 576 this usable, the special domain would have to be operational and 577 point to an appropriate emergency services proxy. Having a 578 single, if logical, emergency services proxy for the whole world 579 seems to have undesirable scaling and administrative properties. 581 Appendix B. Acknowledgments 583 This document is based on discussions with Jonathan Rosenberg and 584 benefited from the comments of Leslie Daigle, Keith Drage, Benja 585 Fallenstein, Paul Kyzivat, Andrew Newton, Brian Rosen, Jonathan 586 Rosenberg, Martin Thomson and Hannes Tschofenig. 588 Intellectual Property Statement 590 The IETF takes no position regarding the validity or scope of any 591 Intellectual Property Rights or other rights that might be claimed to 592 pertain to the implementation or use of the technology described in 593 this document or the extent to which any license under such rights 594 might or might not be available; nor does it represent that it has 595 made any independent effort to identify any such rights. Information 596 on the procedures with respect to rights in RFC documents can be 597 found in BCP 78 and BCP 79. 599 Copies of IPR disclosures made to the IETF Secretariat and any 600 assurances of licenses to be made available, or the result of an 601 attempt made to obtain a general license or permission for the use of 602 such proprietary rights by implementers or users of this 603 specification can be obtained from the IETF on-line IPR repository at 604 http://www.ietf.org/ipr. 606 The IETF invites any interested party to bring to its attention any 607 copyrights, patents or patent applications, or other proprietary 608 rights that may cover technology that may be required to implement 609 this standard. Please address the information to the IETF at 610 ietf-ipr@ietf.org. 612 Disclaimer of Validity 614 This document and the information contained herein are provided on an 615 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 616 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 617 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 618 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 619 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 620 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 622 Copyright Statement 624 Copyright (C) The Internet Society (2006). This document is subject 625 to the rights, licenses and restrictions contained in BCP 78, and 626 except as set forth therein, the authors retain all their rights. 628 Acknowledgment 630 Funding for the RFC Editor function is currently provided by the 631 Internet Society.