--- 1/draft-ietf-ecrit-service-urn-01.txt 2006-04-05 01:12:19.000000000 +0200 +++ 2/draft-ietf-ecrit-service-urn-02.txt 2006-04-05 01:12:19.000000000 +0200 @@ -1,17 +1,17 @@ -SIPPING H. Schulzrinne +ECRIT H. Schulzrinne Internet-Draft Columbia U. -Expires: September 6, 2006 March 5, 2006 +Expires: October 4, 2006 April 2, 2006 A Uniform Resource Name (URN) for Services - draft-ietf-ecrit-service-urn-01 + draft-ietf-ecrit-service-urn-02 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,57 +22,50 @@ 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 September 6, 2006. + This Internet-Draft will expire on October 4, 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. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Registration Template . . . . . . . . . . . . . . . . . . . . 4 - 3. SIP Media Feature Tag Registration: Service . . . . . . . . . 6 - 4. The Service Application Specification . . . . . . . . . . . . 7 - 4.1 Application Unique String . . . . . . . . . . . . . . . . 7 - 4.2 First Well Known Rule . . . . . . . . . . . . . . . . . . 8 - 4.3 Valid Databases . . . . . . . . . . . . . . . . . . . . . 8 - 4.4 Expected Output . . . . . . . . . . . . . . . . . . . . . 8 - 4.5 Flags . . . . . . . . . . . . . . . . . . . . . . . . . . 8 - 4.6 Services . . . . . . . . . . . . . . . . . . . . . . . . . 8 - 4.7 Example . . . . . . . . . . . . . . . . . . . . . . . . . 8 - 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 - 5.1 sos Service Types . . . . . . . . . . . . . . . . . . . . 9 - 5.2 SIP Media Feature Tag Registration: Service . . . . . . . 10 - 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 - 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 - 7.1 Normative References . . . . . . . . . . . . . . . . . . . 10 - 7.2 Informative References . . . . . . . . . . . . . . . . . . 11 - Author's Address . . . . . . . . . . . . . . . . . . . . . . . 12 - A. Alternative Approaches Considered . . . . . . . . . . . . . . 13 - B. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14 - Intellectual Property and Copyright Statements . . . . . . . . 15 + 3. Finding the Mapping Server . . . . . . . . . . . . . . . . . . 6 + 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 + 4.1 New Service-Identifying Tokens . . . . . . . . . . . . . . 7 + 4.2 S-NAPTR Application Service Label . . . . . . . . . . . . 7 + 4.3 sos Service Types . . . . . . . . . . . . . . . . . . . . 7 + 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 + 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 + 6.1 Normative References . . . . . . . . . . . . . . . . . . . 9 + 6.2 Informative References . . . . . . . . . . . . . . . . . . 9 + Author's Address . . . . . . . . . . . . . . . . . . . . . . . 10 + A. Alternative Approaches Considered . . . . . . . . . . . . . . 11 + B. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 + Intellectual Property and Copyright Statements . . . . . . . . 13 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 dialing 911 in North America, 112 in Europe), community services and volunteer @@ -92,25 +85,25 @@ 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 "9-1-1" in the United States; 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. + 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 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. @@ -129,241 +122,183 @@ professionals, at least for mobile devices, as they are too prone to being triggered accidentally.) Rather, protocol elements would carry the service URN described here, allowing universal identification. The translation of dial strings 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 dial string for both the traveler's home location and the traveler's visited location, translating both to the same universal service URN, urn:service:sos. - Existing technologies address the mapping of service identifiers to a - service for a particular DNS domain (DNS SRV [13], DNS NAPTR [15]) or - a local area network (SLP [12]). - - We discuss alternative approaches in Appendix A. For example, the - tel URI [20] allows to express service codes such as "911" for - emergency services by adding a context parameter, but does not - address the problem of global validity. - Since service URNs are not routable, a proxy or user agent has to - translate the service URN into a routable URL for a location- - appropriate service provider, such as a SIP URL. LoST [24] is one + translate the service URN into a routable URI for a location- + appropriate service provider, such as a SIP URL. LoST [20] is one resolution system for mapping service URNs to URLs based on geographic location. It is anticipated that there will be several - such systems. + such systems, possibly with different systems for different services. - For SIP, the service URN will likely appear in either the request URI - or the To header field, depending on which SIP element recognizes the - request as identifying an emergency call. If the mapping is done by - a proxy, the call may no longer be recognizable as an emergency call. - Section 3 uses the service URN in a new SIP feature tag. + We discuss alternative approaches, and why they are unsatisfactory, + in Appendix A. 2. Registration Template Below, we include the registration template for the URN scheme - according to RFC 3406 [19]. - + according to RFC 3406 [15]. Namespace ID: service Registration Information: Registration version: 1; registration date: - 2005-07-10 + 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] 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. + 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. 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:" service - service = top-level-service *("." sub-service) - top-level-service = service-identifier - sub-service = service-identifier - service-identifier = 1*(ALPHA / DIGIT / "-") + service = top-level *("." service-identifier) + let-dig = ALPHA / DIGIT + let-dig-hyp = let-dig / '-' + service-identifier = let-dig [ *let-dig-hyp let-dig ] + top-level = let-dig [ *25let-dig-hyp let-dig ] 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 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 5). The service URN + 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. + 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., [17], - [18], [22], [23]), types of telecommunications equipment [21], - people or organizations [16]. tel URIs [20] identify telephone + 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. + 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 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 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 the mapping protocols, an instance of a Resolution Discovery - System (RDS) as described in RFC 2276 [3]. There could be several - such mapping protocols in concurrent use, as long as there are - reasonable guarantees that all services are available in all - mapping protocols. Section 4 describes the DDDS service that uses - DNS NAPTR records to find an instance of a mapping service. + System (RDS) as described in RFC 2276 [3]. 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. Section 3 describes how DNS NAPTR records are + used to find an instance of a mapping service. Rules for Lexical Equivalence: 'service' identifiers are compared - according to domain name comparison rules. The use of homographic - identifiers is NOT RECOMMENDED. + according to case-insensitive string equality. 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. SIP Media Feature Tag Registration: Service - - This section is specific to SIP. - - If a user agent recognizes an emergency call, it inserts the service - URN into the "To" header field of the INVITE request. If a proxy - recognizes a call as an emergency call, but the user agent did not, - the To header field will contain another URL, such as a tel or SIP - URL. As part of the mapping process, the request URI will be - replaced with the URL of the entity providing the service. Thus, the - INVITE request is no longer recognizable as an emergency call, - although this is desirable to prevent misuse of authorization bypass - for emergency calls and for appropriate policy and priority handling - of emergency calls. - - To address this problem, we propose the use of a new media feature - tag [8], sip.service, that describe the desired communication - service. - - For example, a user agent could request to be routed to marine rescue - by including the following SIP header field: - - Accept-Contact: *;sip.service="urn:service:sos.marine" - - The IANA registration can be found in Section 5. - -4. The Service Application Specification - - This template defines the service URN DDDS Application according to - the rules and requirements found in [6]. The DDDS database used by - this Application is found in [7] which is the document that defines - the NAPTR DNS Resource Record type. - - In summary, a client that wants to resolve a service URN obtains a - domain name through a variety of means, looks up the NAPTR record for - the resolution service and used the regular expression in that record - to transform the service URN into a protocol URL that leads to the - mapping service. This approach allows different domains to offer - different instances of the mapping server and to have different - services be handled by different mapping servers. - - [Note: An alternative is to map the URN to a set of labels, ENUM- - style, so that urn:service:sos.fire becomes fire.sos.example.com. - This only works if the service labels are also valid DNS labels.] - -4.1 Application Unique String - - The Application Unique String (AUS) is the service URN. This URN - MUST be canonicalized and hex encoded according to the "absolute-uri" - production found in the Collected ABNF from RFC 2396. - -4.2 First Well Known Rule - - The first well known rule extracts a key from the AUS. For this - application, the first well known rule extracts the service portion - from the URN, i.e., the "service" part described in Declaration of - Syntactic Structure (Section 2). - -4.3 Valid Databases - - The key resulting from the first well known rule is looked up in a - single database, the DNS [7]. The domain is determined by local - configuration, including through DHCP [10]. For SIP services, the - host part of the address-of-record (AOR) SHOULD be a valid NAPTR - record. - -4.4 Expected Output - - The result of the application is a DNS record for the server to - contact. +3. Finding the Mapping Server -4.5 Flags + When a network entity receives a service URN, it uses the S-NAPTR [6] + mechanism to determine how to map the service URN, possibly using + other information such as geographic location, to a routable URI. + Each top-level service may define one or more such mapping protocols + and mapping protocol servers may be operated by a range of providers. + Thus, the network entity that needs to resolve the service URN + queries an appropriate domain, typically its home or service provider + domain, for NAPTR records and then selects records that match the + service and the mapping protocols it supports. The application + service for this URN is registered in IANA Considerations (Section 4) + of this document; the application protocols are registered in the + appropriate protocol document. - Since the NAPTR record provides a URI, the "u" flag is used. + The S-NAPTR entry MAY contain the "s" flag if the resolving client + needs to perform an SRV resolution on the replacement string. -4.6 Services + The first entry in the following example indicates that 'sos' service + URNs should be mapped to URIs using the LoST [20] protocol server at + lost.example.com, a DNS A record. The second entry is for an + imaginary top-level service 'pizza', using the equally imagined + 'Pizza Location Protocol', offered by the pizzahouse.example.net + server, which should be queried for the appropriate DNS SRV record. - The service consists of a token identifying the mapping protocol , - followed by a transport identifier. The string is defined by the - mapping protocol. + Note that these NAPTR records are maintained by example.com, i.e., + example.com does not actually provide the mapping service itself. -4.7 Example + example.com. + ; order pref flags service regexp + IN NAPTR 50 50 "a" "SURN.sos:LoST" "" + ; replacement + lost.example.org - The following example maps service URNs to HTTP URLs of the form - http://example.com/map/[service], using the LoST [24] protocol. + IN NAPTR 10 50 "s" "SURN.pizza:PLP" "" + _plp._tcp.pizzahouse.example.net - example.com. - ; order pref flags service regexp replacement - IN NAPTR 50 50 "u" "LOST+D2T" - "!urn:service:(.*)!http://example.com/map/\1!i" . +4. IANA Considerations -5. IANA Considerations +4.1 New Service-Identifying Tokens 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 'IETF Consensus'. 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. - This section also registers a new SIP media feature tag. + To allow use within the constraints of S-NAPTR [6], all top-level + service names MUST NOT exceed 27 characters. -5.1 sos Service Types +4.2 S-NAPTR Application Service Label + + Since each top-level service could use one or more different + resolution protocols, we need to indicate the top-level service in + the S-NAPTR application service label. To indicate the URN-to- + service mapping service, all such services start with the string + "SURN." (for "service URN"), followed by the top-level service + identifier. Note that application service labels are case- + insensitive and rendered here in mixed case purely for readability. + + This document registers the label "SURN.sos" as the S-NAPTR + application service label according to [6] for emergency services and + defines the intended usage, interoperability considerations and + security considerations (Section 5). + +4.3 sos Service Types The 'sos' service type describes emergency services and services related to public safety and health, typically offered by various branches of the government or other public institutions. Additional sub-services can be added after expert review and should be of general public interest. urn:service:sos The generic 'sos' service reaches a public safety answering point (PSAP), that in turn dispatches aid appropriate to the emergency. It encompasses all of the services listed below. @@ -389,201 +324,163 @@ 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. urn:service:sos.mental-health The 'mental-health' service refers to - the "[d]iagnostic, treatment, and preventive care that helps - improve how persons with mental illness feel both physically and + 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) -5.2 SIP Media Feature Tag Registration: Service - - This specification defines an additional media feature tag, extending - the SIP tree entries described in [8] and following the registration - process in Section 12.1 of that document. This section serves as the - IANA registration for the service feature tags, which are made into - the SIP media feature tag tree. - - Media feature tag name: sip.service - ASN.1 Identifier: New assignment by IANA. - Summary of the media feature indicated by this tag: Each feature tag - indicates the type of service requested. - Values appropriate for use with this feature tag: Service URNs, as - described in this specification, with an equality relationship. - The feature tag is intended primarily for use in the following - applications, protocols, services, or negotiation mechanisms: This - feature tag is most useful in a communications application, for - describing the capabilities of a user agent providing a particular - type of communication service. - Examples of typical use: Routing calls to an appropriate service - provider, such as a provider of emergency services. - Related standards or documents: RFC3840. - Security Considerations: Security considerations for this media - feature tag are discussed in Section 11.1 of RFC3840. - -6. Security Considerations +5. 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 instant is + 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 [25]. Security considerations for the media feature tag - are described in [8]. + detailed in [21]. -7. References +6. References -7.1 Normative References +6.1 Normative References - [1] Mockapetris, P., "Domain names - concepts and facilities", - STD 13, RFC 1034, November 1987. + [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 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] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part - Two: The Algorithm", RFC 3402, October 2002. - - [7] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part - Three: The Domain Name System (DNS) Database", RFC 3403, - October 2002. - - [8] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Indicating User - Agent Capabilities in the Session Initiation Protocol (SIP)", - RFC 3840, August 2004. - - [9] Duerst, M. and M. Suignard, "Internationalized Resource - Identifiers (IRIs)", RFC 3987, January 2005. + [6] 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 +6.2 Informative References - [10] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, + [7] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997. - [11] Crocker, D., "MAILBOX NAMES FOR COMMON SERVICES, ROLES AND + [8] Crocker, D., "MAILBOX NAMES FOR COMMON SERVICES, ROLES AND FUNCTIONS", RFC 2142, May 1997. - [12] Guttman, E., Perkins, C., Veizades, J., and M. Day, "Service - Location Protocol, Version 2", RFC 2608, June 1999. - - [13] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for + [9] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for specifying the location of services (DNS SRV)", RFC 2782, February 2000. - [14] Resnick, P., "Internet Message Format", RFC 2822, April 2001. + [10] Resnick, P., "Internet Message Format", RFC 2822, April 2001. - [15] Mealling, M. and R. Daniel, "The Naming Authority Pointer + [11] Mealling, M. and R. Daniel, "The Naming Authority Pointer (NAPTR) DNS Resource Record", RFC 2915, September 2000. - [16] Mealling, M., "The Network Solutions Personal Internet Name + [12] Mealling, M., "The Network Solutions Personal Internet Name (PIN): A URN Namespace for People and Organizations", RFC 3043, January 2001. - [17] Rozenfeld, S., "Using The ISSN (International Serial Standard + [13] Rozenfeld, S., "Using The ISSN (International Serial Standard Number) as URN (Uniform Resource Names) within an ISSN-URN Namespace", RFC 3044, January 2001. - [18] Hakala, J. and H. Walravens, "Using International Standard Book + [14] Hakala, J. and H. Walravens, "Using International Standard Book Numbers as Uniform Resource Names", RFC 3187, October 2001. - [19] Daigle, L., van Gulik, D., Iannella, R., and P. Faltstrom, + [15] Daigle, L., van Gulik, D., Iannella, R., and P. Faltstrom, "Uniform Resource Names (URN) Namespace Definition Mechanisms", BCP 66, RFC 3406, October 2002. - [20] Schulzrinne, H., "The tel URI for Telephone Numbers", RFC 3966, + [16] Schulzrinne, H., "The tel URI for Telephone Numbers", RFC 3966, December 2004. - [21] Tesink, K. and R. Fox, "A Uniform Resource Name (URN) Namespace + [17] Tesink, K. and R. Fox, "A Uniform Resource Name (URN) Namespace for the Common Language Equipment Identifier (CLEI) Code", RFC 4152, August 2005. - [22] Kang, S., "Using Universal Content Identifier (UCI) as Uniform + [18] Kang, S., "Using Universal Content Identifier (UCI) as Uniform Resource Names (URN)", RFC 4179, October 2005. - [23] Kameyama, W., "A Uniform Resource Name (URN) Namespace for the + [19] Kameyama, W., "A Uniform Resource Name (URN) Namespace for the TV-Anytime Forum", RFC 4195, October 2005. - [24] Hardie, T., "LoST: A Location-to-Service Translation Protocol", + [20] Hardie, T., "LoST: A Location-to-Service Translation Protocol", draft-hardie-ecrit-lost-00 (work in progress), March 2006. - [25] Schulzrinne, H., "Security Threats and Requirements for - Emergency Call Mapping", draft-taylor-ecrit-security-threats-02 - (work in progress), February 2006. + [21] Taylor, T., "Security Threats and Requirements for Emergency + Call Marking and Mapping", draft-ietf-ecrit-security-threats-00 + (work in progress), March 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 "sos" SIP URI reserved user name proposed here follows the - convention of RFC 2142 [11] and the "postmaster" convention - documented in RFC 2822 [14]. 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. + convention of RFC 2142 [8] 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: - tel:NNN;context=+C This approach uses tel URIs [20]. Here, NNN is + 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" - [20] URI. It also only works if every outbound proxy knows how to + [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 @@ -601,22 +498,22 @@ 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 Leslie Daigle, Benja Fallenstein and - Paul Kyzivat. + benefitted from the comments of Leslie Daigle, Benja Fallenstein, + Paul Kyzivat, Andrew Newton, Jonathan Rosenberg and Martin Thomas. 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