SIPPING H. Schulzrinne Internet-Draft Columbia U. Expires: August 19, 2006 February 15, 2006 A Uniform Resource Name (URN) for Services draft-ietf-ecrit-service-urn-00 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 other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months 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 August 19, 2006. Copyright Notice Copyright (C) The Internet Society (2006). Abstract The content of many communication services depend on the context, such as the user's location. We describe a 'service' URN that allows to register such context-dependent services that can be resolved in a distributed manner. Schulzrinne Expires August 19, 2006 [Page 1] Internet-Draft Service URN February 2006 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Registration Template . . . . . . . . . . . . . . . . . . . . 4 3. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 5.1 Normative References . . . . . . . . . . . . . . . . . . . 6 5.2 Informative References . . . . . . . . . . . . . . . . . . 7 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 8 A. Alternative Approaches Considered . . . . . . . . . . . . . . 8 B. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 Intellectual Property and Copyright Statements . . . . . . . . 10 Schulzrinne Expires August 19, 2006 [Page 2] Internet-Draft Service URN February 2006 1. Introduction In existing telecommunications systems, there are many well-known communication and information services that are offered by loosely coordinated entities across a large geographic region, with well- known identifiers. Some of the services are operated by governments or regulated monopolies, others by competing commercial enterprises. Examples include emergency services (reached by 911 in North America, 112 in Europe), community services and volunteer opportunities (211 in some regions of the United States),telephone directory and repair services (411 and 611 in the United States and Canada), government information services (311 in some cities in the United States), lawyer referral services (1-800-LAWYER), car roadside assistance (automobile clubs) and pizza delivery services. Unfortunately, almost all of them are limited in scope to a single country or possibly a group of countries, such as those belonging to the North American Numbering Plan or the European Union. The same identifiers are often used for other purposes outside that region, making accessing such services difficult when users travel or use devices produced outside their home country. These services are characterized by long-term stability of user- visible identifiers, decentralized administration of the underlying service and a well-defined resolution mechanism. (For example, there is no national coordination or call center for 911; rather, various local government organizations cooperate to provide this service, based on jurisdictions.) In this document, we propose a URN namespace that, together with resolution protocols beyond the scope of this document, allows to define such global, well-known services, while distributing the actual implementation across a large number of service-providing entities. While there are many ways to divide provision of such services, we focus on geography as a common way to delineate service regions. In addition, users can choose different directory 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 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 allow to delegate routing decisions to third parties and mark certain requests as having special characteristics while preventing these characteristics to be accidentally invoked on inappropriate requests. Schulzrinne Expires August 19, 2006 [Page 3] Internet-Draft Service URN February 2006 This URN allows to identify services independent of a particular protocol to deliver the services. It may appear in protocols that allow general URIs, such as SIP [5] request URIs, web pages or mapping protocols. Existing technologies address the mapping of service identifiers to a service for a particular DNS domain (DNS SRV [9], DNS NAPTR [11]) or a local area network (SLP [8]). The tel URI [16] allows to express service codes such as 911 by adding a context parameter, but does not address the problem of global validity. LUMP [20] is a prototype resolution system for mapping URNs to URLs based on geographic location. However, it is anticipated that there will be several such systems. 2. Registration Template Below, we include the registration template for the URN scheme according to RFC 3406 [15]. Namespace ID: service Registration Information: Registration version: 1; registration date: 2005-07-10 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 IRIs, that used for domain names [1] except that there is no restriction on the first character being a letter; labels are case-insensitive and SHOULD be specified in all lower- case. Any string of service labels can be used to request services that are either more generic or more specific. In other words, if a service 'x.y.z' exists, the URNs 'x' and 'x.y' are also valid service URNs. "URN:service:" top-level-service *("." service-identifier) top-level-service = ALPHA / DIGIT / "-" / service-identifier = ALPHA / DIGIT / "-" / Relevant ancillary documentation: None Community considerations: The service URN is believe to be relevant to a large cross-section of Internet users, including both technical and non-technical users, on a variety of devices, but particularly for mobile and nomadic users. The service URN will allow Internet users needing services to identify the service by Schulzrinne Expires August 19, 2006 [Page 4] Internet-Draft Service URN February 2006 kind, without having to determine manually who provides the particular service in the user's current context, e.g., at his current location. For example, a traveler will be able to use his mobile device to request emergency services without having to know the local emergency number. 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. The ECRIT working group is currently discussing several approaches, including solutions based on DNS, IRIS and a web-services protocol. Software prototypes for some of these are currently already available and are believed to be readily developed. 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., [13], [14], [18], [19]), types of telecommunications equipment [17], people or organizations [12]. tel URIs [16] 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). 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. Identifier persistence considerations: The 'service' URN for the same service is expected to be persisent, 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: Details of the service assignment depend on the service and national regulations. In general, it is assumed that providers of services can register through a service mapping mechanism for a particular service in a particular geographic area. The provision of some services may be restricted by local or national regulations. (As a hypothetical example, providing emergency services may be restricted to government- authorized entities, which may limit the region where each entity can advertise its services.) The rules for each service are described in a service-specific document. Process for identifier resolution: 'service' identifiers are resolved by the TBD mapping protocol, an instance of a Resolution Discovery System (RDS) as described in RFC 2276 [3]. (In theory, there could be several such mapping protocols in concurrent use, as long as there are reasonable guarantees that all services are available Schulzrinne Expires August 19, 2006 [Page 5] Internet-Draft Service URN February 2006 in all mapping protocols.) Rules for Lexical Equivalence: 'service' identifiers are compared according to domain name comparison rules. The use of homographic identifiers is NOT RECOMMENDED. Conformance with URN Syntax: There are no special considerations. Validation mechanism: The RDS mechanism is also used to validate the existence of a resource. As noted, by its design, the availability of a resource may depend on where service is desired and there may not be service available in all or most locations. (For example, roadside assistance service is unlikely to be available on about 70% of the earth's surface.) Scope: The scope for this URN is public and global. 3. Example For discussion and illustration purposes only, we include an example of a particular service. We choose emergency services as an example, with the top-level service identifier 'sos'. A possible list of identifiers might include: urn:service:sos urn:service:sos.fire urn:service:sos.police urn:service:sos.marine urn:service:sos.mountain urn:service:sos.rescue urn:service:sos.poison urn:service:sos.suicide urn:service:sos.mental-health urn:service:sos.animal-control 4. IANA Considerations New service-identifying tokens and sub-registrations are to be managed by IANA, according to the processes outlined in [4]. The policy for top-level service names is TBD, but could be 'specification required', 'IETF Consensus' or 'Standards Action'. The policy for assigning names to sub-services may differ for each top-level service designation and MUST be defined by the document describing the top-level service. 5. References 5.1 Normative References [1] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987. Schulzrinne Expires August 19, 2006 [Page 6] Internet-Draft Service URN February 2006 [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 Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. [5] 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] Duerst, M. and M. Suignard, "Internationalized Resource Identifiers (IRIs)", RFC 3987, January 2005. 5.2 Informative References [7] Crocker, D., "MAILBOX NAMES FOR COMMON SERVICES, ROLES AND FUNCTIONS", RFC 2142, May 1997. [8] Guttman, E., Perkins, C., Veizades, J., and M. Day, "Service Location Protocol, Version 2", RFC 2608, June 1999. [9] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for specifying the location of services (DNS SRV)", RFC 2782, February 2000. [10] Resnick, P., "Internet Message Format", RFC 2822, April 2001. [11] Mealling, M. and R. Daniel, "The Naming Authority Pointer (NAPTR) DNS Resource Record", RFC 2915, September 2000. [12] Mealling, M., "The Network Solutions Personal Internet Name (PIN): A URN Namespace for People and Organizations", RFC 3043, January 2001. [13] Rozenfeld, S., "Using The ISSN (International Serial Standard Number) as URN (Uniform Resource Names) within an ISSN-URN Namespace", RFC 3044, January 2001. [14] Hakala, J. and H. Walravens, "Using International Standard Book Numbers as Uniform Resource Names", RFC 3187, October 2001. [15] Daigle, L., van Gulik, D., Iannella, R., and P. Faltstrom, "Uniform Resource Names (URN) Namespace Definition Mechanisms", BCP 66, RFC 3406, October 2002. Schulzrinne Expires August 19, 2006 [Page 7] Internet-Draft Service URN February 2006 [16] Schulzrinne, H., "The tel URI for Telephone Numbers", RFC 3966, December 2004. [17] Tesink, K. and R. Fox, "A Uniform Resource Name (URN) Namespace for the Common Language Equipment Identifier (CLEI) Code", RFC 4152, August 2005. [18] Kang, S., "Using Universal Content Identifier (UCI) as Uniform Resource Names (URN)", RFC 4179, October 2005. [19] Kameyama, W., "A Uniform Resource Name (URN) Namespace for the TV-Anytime Forum", RFC 4195, October 2005. [20] Schulzrinne, H., "Location-to-URL Mapping Protocol (LUMP)", draft-schulzrinne-ecrit-lump-01 (work in progress), October 2005. 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 "sos" SIP URI reserved user name proposed here follows the convention of RFC 2142 [7] and the "postmaster" convention documented in RFC 2822 [10]. The approach has the advantage that only the home proxy for a user needs to understand the convention and that the mechanism is likely backwards-compatible with most SIP user agents, with the only requirement that they have to be able to generate alphanumeric URLs. One drawback is that it may conflict with locally assigned addresses of the form "sos@domain". Also, if proxies not affiliated with the domain translate the URL, they violate the current SIP protocol conventions. There are a number of possible alternatives, each with their own set of advantages and problems: Schulzrinne Expires August 19, 2006 [Page 8] Internet-Draft Service URN February 2006 tel:NNN;context=+C This approach uses tel URIs [16]. 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. 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" [16] 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. 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- domain;user=sos". This avoids the name conflict problem, but requires mechanism-aware user agents that are capable of emitting this special URI. Also, the 'user' parameter is meant to describe the format of the user part of the SIP URI, which this usage does not do. Adding other parameters still leaves unclear what, if any, conventions should be used for the user and domain part of the URL. Neither solution is likely to be backward-compatible with existing clients. Special domain: A special domain, such as "sip:fire@sos.int" could be used to identify emergency calls. This has similar properties as the "tel:sos" URI, except that it is indeed a valid URI. To make this usable, the special domain would have to be operational and point to an appropriate emergency services proxy. Having a single, if logical, emergency services proxy for the whole world seems to have undesirable scaling and administrative properties. Appendix B. Acknowledgments This document is based on discussions with Jonathan Rosenberg and benefitted from the comments of Benja Fallenstein and Leslie Daigle. Schulzrinne Expires August 19, 2006 [Page 9] Internet-Draft Service URN February 2006 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Schulzrinne Expires August 19, 2006 [Page 10]