--- 1/draft-ietf-ecrit-service-urn-04.txt 2006-08-29 01:12:08.000000000 +0200 +++ 2/draft-ietf-ecrit-service-urn-05.txt 2006-08-29 01:12:09.000000000 +0200 @@ -1,17 +1,17 @@ ECRIT H. Schulzrinne Internet-Draft Columbia U. -Expires: February 7, 2007 August 6, 2006 +Expires: February 28, 2007 August 27, 2006 A Uniform Resource Name (URN) for Services - draft-ietf-ecrit-service-urn-04 + draft-ietf-ecrit-service-urn-05 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that @@ -22,21 +22,21 @@ and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. - This Internet-Draft will expire on February 7, 2007. + This Internet-Draft will expire on February 28, 2007. Copyright Notice Copyright (C) The Internet Society (2006). Abstract The content of many communication services depends on the context, such as the user's location. We describe a 'service' URN that allows to identify context-dependent services that can be resolved in a @@ -94,101 +94,102 @@ In this document, we propose a URN namespace that, together with resolution protocols beyond the scope of this document, allows us to define such global, well-known services, while distributing the actual implementation across a large number of service-providing entities. There are many ways to divide provision of such services, such as dividing responsibility by geographic region or by the service provider a user chooses. In addition, users can choose different mapping service providers that in turn manage how geographic locations are mapped to service providers. - Availability of such service identifiers simplifies end system - configuration. For example, an IP phone could have a special set of - short cuts, address book entries or buttons that invoke emergency - services, as it would not be practical to manually re-configure the - device with local emergency contacts for each city or town a user - visits with his or her mobile device. Also, such identifiers make it + Availability of such service identifiers allows end systems to convey + information about the desired service to other network entities. For + example, an IP phone could have a special set of short cuts, address + book entries or buttons that invoke emergency services. When such a + service identifier is put into the outgoing SIP message, it allows + SIP proxies to unambiguously take actions, as it would not be + practical to configure them with dial strings and emergency numbers + used throughout the world. Hence, such service identifiers make it possible to delegate routing decisions to third parties and to mark certain requests as having special characteristics while preventing - these characteristics to be accidentally invoked on inappropriate - requests. + these characteristics from being accidentally invoked. This URN identifies services independent of the particular protocol that is used to request or deliver the service. The URN may appear in protocols that allow general URIs, such as the Session Initiation - Protocol (SIP) [5] request URIs, web pages or mapping protocols. + Protocol (SIP) [4] request URIs, web pages or mapping protocols. The service URN is a protocol element and generally not expected to be visible to humans. For example, it is expected that callers will - still dial '9-1-1' in the United States to reach emergency services. - In some other cases, speed dial buttons might identify the service, - as is common practice on hotel phones today. (Speed dial buttons for - summoning emergency help are considered inappropriate by most - emergency services professionals, at least for mobile devices, as - they are too prone to being triggered accidentally.) Rather, - protocols would carry the service URN described here, allowing - universal identification. The translation of dial strings or service - numbers to service URNs is beyond the scope of this document; it is - likely to depend on the location of the caller and may be many-to- - one. For example, a phone for a traveler could recognize the - emergency number for both the traveler's home location and the - traveler's visited location, translating both to the same universal + still dial the emergency number '9-1-1' in the United States to reach + emergency services. In some other cases, speed dial buttons might + identify the service, as is common practice on hotel phones today. + (Speed dial buttons for summoning emergency help are considered + inappropriate by most emergency services professionals, at least for + mobile devices, as they are too prone to being triggered + accidentally.) Rather, protocols would carry the service URN + described here, allowing universal identification. + + The translation of service dial strings or service numbers to service + URNs in the end host is beyond the scope of this document. These + translations likely depend on the location of the caller and may be + many-to-one, i.e., several service numbers may map to one service + URN. For example, a phone for a traveler could recognize the + emergency service number for both the traveler's home location and + the traveler's visited location, mapping both to the same universal service URN, urn:service:sos. Since service URNs are not routable, a SIP proxy or user agent has to translate the service URN into a routable URI for a location- - appropriate service provider, such as a SIP URL. LoST [19] is one - resolution system for mapping service URNs to URLs based on - geographic location. It is anticipated that there will be several - such systems, possibly with different systems for different services. + appropriate service provider, such as a SIP URL. LoST [17] is + expected to be used as a resolution system for mapping service URNs + to URLs based on geographic location. In the future, there may be + several such protocols, possibly different ones for different + services. Services are described by top-level service type, and may contain a hierarchy of sub-services further describing the service, as outlined - in Section 3. Mapping protocols SHOULD always provide a mapping just - for the top-level service even if sub-services are in use. This - mapping for the top-level service MAY also be used if an entity is - presented with an invalid sub-service and presenting an error - condition to the user is inappropriate, e.g., during an emergency. + in Section 3. We discuss alternative approaches for creating service identifiers, and why they are unsatisfactory, in Appendix A. 2. Terminology In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in RFC 2119 [2]. - Terminology specific to emergency services is defined in [21]. + Terminology specific to emergency services is defined in [19]. 3. Registration Template Below, we include the registration template for the URN scheme - according to RFC 3406 [13]. + according to RFC 3406 [12]. Namespace ID: service Registration Information: Registration version: 1; registration date: 2006-04-02 Declared registrant of the namespace: TBD Declaration of syntactic structure: The URN consists of a hierarchical service identifier, with a sequence of labels separated by periods. The left-most label is the most significant one and is called 'top-level service', while names to the right are called 'sub-services'. The set of allowable characters is the same as that for domain names [1] and a subset of the labels - allowed in [6]. Labels are case-insensitive and SHOULD be - specified in all lower-case. For any given service URN, service- - identifiers can be removed right-to-left and the resulting URN is - still valid, referring a more generic service. In other words, if - a service 'x.y.z' exists, the URNs 'x' and 'x.y' are also valid - service URNs. + allowed in [5]. Labels are case-insensitive and MUST be specified + in all lower-case. For any given service URN, service-identifiers + can be removed right-to-left and the resulting URN is still valid, + referring a more generic service. In other words, if a service + 'x.y.z' exists, the URNs 'x' and 'x.y' are also valid service + URNs. "URN:service:" service service = top-level *("." sub-service) let-dig = ALPHA / DIGIT let-dig-hyp = let-dig / '-' sub-service = let-dig [ *let-dig-hyp let-dig ] top-level = let-dig [ *25let-dig-hyp let-dig ] Relevant ancillary documentation: None @@ -204,91 +205,88 @@ having to know the emergency dial string of the visited country. The assignment of identifiers is described in the IANA Considerations (Section 4). The service URN does not prescribe a particular resolution mechanism, but it is assumed that a number of different entities could operate and offer such mechanisms. Namespace considerations: There do not appear to be other URN namespaces that serve the same need of uniquely identifying widely-available communication and information services. Unlike most other currently registered URN namespaces, the service URN - does not identify documents and protocol objects (e.g., [10], - [11], [16], [17]), types of telecommunications equipment [15], - people or organizations [9]. tel URIs [14] identify telephone - numbers, but numbers commonly identifying services, such as 911 or - 112, are specific to a particular region or country. + does not identify documents and protocol objects (e.g., [9], [10], + [15], [16]), types of telecommunications equipment [14], people or + organizations [8]. tel URIs [13] identify telephone numbers, but + numbers commonly identifying services, such as 911 or 112, are + specific to a particular region or country. Identifier uniqueness considerations: A service URN identifies a logical service, specified in the service registration (see IANA Considerations (Section 4)). Resolution of the URN, if successful, will return a particular instance of the service, and this instance may be different even for two users making the same request in the same place at the same time; the logical service identified by the URN, however, is persistent and unique. Service URNs MUST be unique for each unique service; this is guaranteed through the registration of each service within this namespace, described in Section 4. Identifier persistence considerations: The 'service' URN for the same service is expected to be persistent, although there naturally cannot be a guarantee that a particular service will continue to be available globally or at all times. Process of identifier assignment: The process of identifier assignment is described in the IANA Considerations (Section 4). - Process for identifier resolution: 'service' identifiers are resolved - by mapping protocols, based on the service and the location of the - person or entity desiring the use of the service. Each top-level - service can provide its own distinct set of mapping protocols. - Within each top-level service, all mapping protocols MUST return - the same set of mappings. A resolution service is specified in a - separate document. + Process for identifier resolution: There is no single global + resolution service for 'service' URNs. However, each top-level + service can provide a set of mapping protocols to be used with + 'service' URNs of that service. Rules for Lexical Equivalence: 'service' identifiers are compared according to case-insensitive string equality. Conformance with URN Syntax: The BNF in the 'Declaration of syntactic structure' above constrains the syntax for this URN scheme. Validation mechanism: Validation determines whether a given string is - currently a validly-assigned URN [13]. Due to the distributed + currently a validly-assigned URN [12]. Due to the distributed nature of the mapping mechanism and since not all services are available everywhere and not all mapping servers may be configured with all current service registrations, validation in this sense is not possible. Also, the discovery mechanism for the mapping mechanism may not be configured with all current top-level services. Scope: The scope for this URN is public and global. 4. IANA Considerations 4.1 New Service-Identifying Labels Services and sub-services are identified by labels managed by IANA, - according to the processes outlined in [4] in a new registry called + according to the processes outlined in [3] in a new registry called "Service URN Labels". Thus, creating a new service requires IANA action. The policy for adding top-level service labels is 'Standards Action'. (This document defines the top-level service 'sos' and 'counseling'.) The policy for assigning labels to sub-services may differ for each top-level service designation and MUST be defined by the document describing the top-level service. Entries in the registration table have the following format Service Reference Description -------------------------------------------------------------------- foo RFCxyz Brief description of the 'foo' top-level service foo.bar RFCabc Description of the 'foo.bar' service - To allow use within the constraints of S-NAPTR [6], all top-level + To allow use within the constraints of S-NAPTR [5], all top-level service names MUST NOT exceed 27 characters. 4.2 Sub-Services for the 'sos' Service This section defines the first service registration within the IANA registry defined in Section 4.1, using the top-level service label 'sos'. The 'sos' service type describes emergency services requiring an immediate response, typically offered by various branches of the @@ -324,22 +322,20 @@ used to apply to search and rescue in other wilderness environments. urn:service:sos.physician The 'physician' emergency service connects the caller to a physician referral service. urn:service:sos.poison The 'poison' service refers to special information centers set up to inform citizens about how to respond to potential poisoning. These poison control centers maintain a database of poisons and appropriate emergency treatment. urn:service:sos.police The 'police' service refers to the police department or other law enforcement authorities. - urn:service:sos.suicide The 'suicide' service refers to the suicide - prevention hotline. 4.3 Sub-Services for the 'counseling' Service The 'counseling' service type describes services where callers can receive advice and support, often anonymous, but not requiring an emergency response. (Naturally, such services may transfer callers to an emergency service or summon such services if the situation warrants.) Additional sub-services can be added after expert review and should be of general public interest. The expert is chosen in the same manner as describe for the 'sos' service. The expert review @@ -354,184 +350,183 @@ counseling and support services that are specifically tailored to the needs of children. Such services may, for example, provide advice to run-aways or victims of child abuse. urn:service:counseling.mental-health The 'mental-health' service refers to the "diagnostic, treatment, and preventive care that helps improve how persons with mental illness feel both physically and emotionally as well as how they interact with other persons." (U.S. Department of Health and Human Services) + urn:service:counseling.suicide The 'suicide' service refers to the + suicide prevention hotline. + 4.4 Initial IANA Registration The following table contains the initial IANA registration for emergency and counseling services. Service Reference Description -------------------------------------------------------------------- counseling RFC XYZ Counseling services counseling.children RFC XYZ Counseling for children counseling.mental-health RFC XYZ Mental health counseling + counseling.suicide RFC XYZ Suicide prevention hotline sos RFC XYZ Emergency services sos.animal-control RFC XYZ Animal control sos.fire RFC XYZ Fire service sos.gas RFC XYZ Gas leaks and gas emergencies sos.marine RFC XYZ Maritime search and rescue sos.mountain RFC XYZ Mountain rescue sos.physician RFC XYZ Physician referral service sos.poison RFC XYZ Poison control center sos.police RFC XYZ Police, law enforcement - sos.suicide RFC XYZ Suicide prevention hotline + + [[NOTE TO RFC-EDITOR: Please replace above 'RFC XYZ' reference with + the RFC number of this document and remove this note.]] 5. Internationalization Considerations - The service labels are protocol elements [12] and not normally seen + The service labels are protocol elements [11] and not normally seen by users. Thus, the character set for these elements is restricted, as described in Section 3. 6. Security Considerations As an identifier, the service URN does not appear to raise any particular security issues. The services described by the URN are meant to be well-known, even if the particular service instance is access-controlled, so privacy considerations do not apply to the URN. There are likely no specific privacy issues when including a service URN on a web page, for example. On the other hand, ferrying the URN in a signaling protocol can give attackers information on the kind of service desired by the caller. For example, this makes it easier for the attacker to automatically find all calls for emergency services or directory assistance. Appropriate, protocol-specific security mechanisms need to be implemented for protocols carrying service URNs. The mapping protocol needs to address a number of threats, as - detailed in [20]. + detailed in [18]. 7. References 7.1 Normative References [1] Braden, R., "Requirements for Internet Hosts - Application and Support", STD 3, RFC 1123, October 1989. [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. - [3] Sollins, K., "Architectural Principles of Uniform Resource Name - Resolution", RFC 2276, January 1998. - - [4] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA + [3] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. - [5] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., + [4] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002. - [6] Daigle, L. and A. Newton, "Domain-Based Application Service + [5] Daigle, L. and A. Newton, "Domain-Based Application Service Location Using SRV RRs and the Dynamic Delegation Discovery Service (DDDS)", RFC 3958, January 2005. 7.2 Informative References - [7] Crocker, D., "MAILBOX NAMES FOR COMMON SERVICES, ROLES AND + [6] Crocker, D., "MAILBOX NAMES FOR COMMON SERVICES, ROLES AND FUNCTIONS", RFC 2142, May 1997. - [8] Resnick, P., "Internet Message Format", RFC 2822, April 2001. + [7] Resnick, P., "Internet Message Format", RFC 2822, April 2001. - [9] Mealling, M., "The Network Solutions Personal Internet Name + [8] Mealling, M., "The Network Solutions Personal Internet Name (PIN): A URN Namespace for People and Organizations", RFC 3043, January 2001. - [10] Rozenfeld, S., "Using The ISSN (International Serial Standard + [9] Rozenfeld, S., "Using The ISSN (International Serial Standard Number) as URN (Uniform Resource Names) within an ISSN-URN Namespace", RFC 3044, January 2001. - [11] Hakala, J. and H. Walravens, "Using International Standard Book + [10] Hakala, J. and H. Walravens, "Using International Standard Book Numbers as Uniform Resource Names", RFC 3187, October 2001. - [12] Hoffman, P., "Terminology Used in Internationalization in the + [11] Hoffman, P., "Terminology Used in Internationalization in the IETF", RFC 3536, May 2003. - [13] Daigle, L., van Gulik, D., Iannella, R., and P. Faltstrom, + [12] Daigle, L., van Gulik, D., Iannella, R., and P. Faltstrom, "Uniform Resource Names (URN) Namespace Definition Mechanisms", BCP 66, RFC 3406, October 2002. - [14] Schulzrinne, H., "The tel URI for Telephone Numbers", RFC 3966, + [13] Schulzrinne, H., "The tel URI for Telephone Numbers", RFC 3966, December 2004. - [15] Tesink, K. and R. Fox, "A Uniform Resource Name (URN) Namespace + [14] Tesink, K. and R. Fox, "A Uniform Resource Name (URN) Namespace for the Common Language Equipment Identifier (CLEI) Code", RFC 4152, August 2005. - [16] Kang, S., "Using Universal Content Identifier (UCI) as Uniform + [15] Kang, S., "Using Universal Content Identifier (UCI) as Uniform Resource Names (URN)", RFC 4179, October 2005. - [17] Kameyama, W., "A Uniform Resource Name (URN) Namespace for the + [16] Kameyama, W., "A Uniform Resource Name (URN) Namespace for the TV-Anytime Forum", RFC 4195, October 2005. - [18] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A - Methodology for Network Address Translator (NAT) Traversal for - Offer/Answer Protocols", draft-ietf-mmusic-ice-09 (work in - progress), June 2006. - - [19] Hardie, T., "LoST: A Location-to-Service Translation Protocol", - draft-hardie-ecrit-lost-00 (work in progress), March 2006. + [17] Hardie, T., "LoST: A Location-to-Service Translation Protocol", + draft-ietf-ecrit-lost-00 (work in progress), June 2006. - [20] Taylor, T., "Security Threats and Requirements for Emergency + [18] Taylor, T., "Security Threats and Requirements for Emergency Call Marking and Mapping", draft-ietf-ecrit-security-threats-03 (work in progress), July 2006. - [21] Schulzrinne, H. and R. Marshall, "Requirements for Emergency + [19] Schulzrinne, H. and R. Marshall, "Requirements for Emergency Context Resolution with Internet Technologies", - draft-ietf-ecrit-requirements-10 (work in progress), June 2006. + draft-ietf-ecrit-requirements-11 (work in progress), + August 2006. Author's Address Henning Schulzrinne Columbia University Department of Computer Science 450 Computer Science Building New York, NY 10027 US Phone: +1 212 939 7004 Email: hgs+ecrit@cs.columbia.edu URI: http://www.cs.columbia.edu Appendix A. Alternative Approaches Considered The discussions of ways to identify emergency calls has yielded a number of proposals. Since these are occasionally brought up during discussions, we briefly summarize why this document chose not to pursue these solutions. - tel:NNN;context=+C This approach uses tel URIs [14]. Here, NNN is + tel:NNN;context=+C This approach uses tel URIs [13]. Here, NNN is the national emergency number, where the country is identified by the context C. This approach is easy for user agents to implement, but hard for proxies and other SIP elements to recognize, as it would have to know about all number-context combinations in the world and track occasional changes. In addition, many of these numbers are being used for other services. For example, the emergency number in Paraguay (00) is also used to call the international operator in the United States. As another example, A number of countries, such as Italy, use 118 as an emergency number, but it also connects to directory assistance in Finland. tel:sos This solution avoids name conflicts, but is not a valid "tel" - [14] URI. It also only works if every outbound proxy knows how to + [13] URI. It also only works if every outbound proxy knows how to route requests to a proxy that can reach emergency services since tel URIs. The SIP URI proposed here only requires a user's home domain to be appropriately configured. sip:sos@domain Earlier work had defined a special user identifier, sos, within the caller's home domain in a SIP URI, for example, sip:sos@example.com. Such a user identifier follows the - convention of RFC 2142 [7] and the "postmaster" convention - documented in RFC 2822 [8]. This approach had the advantage that + convention of RFC 2142 [6] and the "postmaster" convention + documented in RFC 2822 [7]. This approach had the advantage that dial plans in existing user agents could probably be converted to generate such a URI and that only the home proxy for the domain has to understand the user naming convention. However, it overloads the user part of the URI with specific semantics rather than being opaque, makes routing by the outbound proxy a special case that does not conform to normal SIP request-URI handling rules and is SIP-specific. The mechanism also does not extend readily to other services. SIP URI user parameter: One could create a special URI, such as "aor-