Network Working Group H. Schulzrinne
Request for Comments: 5031 Columbia U.
Category: Standards Track January 2008
Network Working Group H. Schulzrinne
Request for Comments: 5031 Columbia U.
Category: Standards Track January 2008
A Uniform Resource Name (URN) for Emergency and Other Well-Known Services
应急和其他知名服务的统一资源名称（URN）
Status of This Memo
关于下段备忘
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Abstract
摘要
The content of many communication services depends on the context, such as the user's location. We describe a 'service' URN that allows well-known context-dependent services that can be resolved in a distributed manner to be identified. Examples include emergency services, directory assistance, and call-before-you-dig hot lines.
许多通信服务的内容取决于上下文，例如用户的位置。我们描述了一个“服务”URN，它允许识别可以以分布式方式解析的众所周知的上下文相关服务。例子包括紧急服务、目录帮助和挖掘热线前的呼叫。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Registration Template . . . . . . . . . . . . . . . . . . . . 4
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
4.1. New Service-Identifying Labels . . . . . . . . . . . . . . 6
4.2. Sub-Services for the 'sos' Service . . . . . . . . . . . . 7
4.3. Sub-Services for the 'counseling' Service . . . . . . . . 8
4.4. Initial IANA Registration . . . . . . . . . . . . . . . . 9
5. Internationalization Considerations . . . . . . . . . . . . . 9
6. Security Considerations . . . . . . . . . . . . . . . . . . . 10
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
7.1. Normative References . . . . . . . . . . . . . . . . . . . 10
7.2. Informative References . . . . . . . . . . . . . . . . . . 11
Appendix A. Alternative Approaches Considered . . . . . . . . . . 13
Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . . . 14
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Registration Template . . . . . . . . . . . . . . . . . . . . 4
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
4.1. New Service-Identifying Labels . . . . . . . . . . . . . . 6
4.2. Sub-Services for the 'sos' Service . . . . . . . . . . . . 7
4.3. Sub-Services for the 'counseling' Service . . . . . . . . 8
4.4. Initial IANA Registration . . . . . . . . . . . . . . . . 9
5. Internationalization Considerations . . . . . . . . . . . . . 9
6. Security Considerations . . . . . . . . . . . . . . . . . . . 10
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
7.1. Normative References . . . . . . . . . . . . . . . . . . . 10
7.2. Informative References . . . . . . . . . . . . . . . . . . 11
Appendix A. Alternative Approaches Considered . . . . . . . . . . 13
Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . . . 14
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 9-1-1 in North America, 1-1-2 in Europe), community services and volunteer opportunities (2-1-1 in some regions of the United States), telephone directory and repair services (4-1-1 and 6-1-1 in the United States and Canada), government information services (3-1-1 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 access to such services difficult when users travel or use devices produced outside their home country.
在现有的电信系统中，有许多众所周知的通信和信息服务，这些服务是由一个地理区域内协调松散的实体提供的，具有众所周知的标识符。其中一些服务由政府或受监管的垄断企业经营，另一些则由竞争性商业企业经营。例如紧急服务（北美拨打9-1-1，欧洲拨打1-1-2），社区服务和志愿者机会（美国某些地区拨打2-1-1），电话簿和维修服务（美国和加拿大拨打4-1-1和6-1-1），政府信息服务（3-1-1在美国的一些城市）、律师推荐服务（1-800-律师）、汽车路边救援（汽车俱乐部）不幸的是，几乎所有这些服务的范围都局限于一个国家或可能是一组国家，如北美编号计划或欧盟的国家。相同的标识符通常用于该地区以外的其他目的，使得使用此类服务时很难获得旅行或使用国外生产的设备。
These services are characterized by long-term stability of user-visible identifiers, decentralized administration of the underlying service, and a well-defined resolution or mapping 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.
这些服务的特点是用户可见标识符的长期稳定性、底层服务的分散管理以及定义良好的解析或映射机制。例如，美国没有针对“9-1-1”的国家协调或呼叫中心；相反，各地方政府组织根据管辖权合作提供这项服务。
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.
在本文档中，我们提出了一个URN名称空间，该名称空间与本文档范围之外的解析协议一起，允许我们定义此类全局的、众所周知的服务，同时将实际实现分布在大量服务提供实体上。有许多方法可以划分此类服务的提供，例如按地理区域或用户选择的服务提供商划分责任。此外，用户可以选择不同的映射服务提供商，这些提供商反过来管理地理位置映射到服务提供商的方式。
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 Session Initiation Protocol (SIP) [RFC3261] 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
这种服务标识符的可用性允许终端系统向其他网络实体传送关于所需服务的信息。例如，IP电话可以有一组特殊的快捷方式、地址簿条目或按钮来调用紧急服务。当这样的服务标识符被放入传出会话发起协议（SIP）[RFC3261]消息中时，它允许SIP代理明确地采取行动，因为用拨号字符串和世界各地使用的紧急号码来配置它们是不切实际的。因此，这样的服务标识符使得将路由决策委托给第三方并将某些请求标记为
having special characteristics while preventing 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 SIP [RFC3261] request URIs, web pages, or mapping protocols.
此URN标识独立于用于请求或交付服务的特定协议的服务。URN可能出现在允许通用URI的协议中，例如SIP[RFC3261]请求URI、网页或映射协议。
The service URN is a protocol element and is generally not expected to be visible to humans. For example, it is expected that callers will 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.)
服务URN是一个协议元素，通常不希望对人类可见。例如，在美国，预计呼叫者仍会拨打紧急电话号码“9-1-1”，以拨打紧急服务。在其他一些情况下，快速拨号按钮可能会识别服务，这是当今酒店电话的常见做法。（大多数紧急服务专业人员认为，用于呼叫紧急帮助的快速拨号按钮不合适，至少对于移动设备来说是这样，因为它们太容易被意外触发。）
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.
将服务拨号字符串或服务号码转换为终端主机中的服务URN超出了本文档的范围。这些转换可能取决于调用者的位置，并且可能是多对一的，即，多个服务号码可能映射到一个服务URN。例如，旅行者的电话可以识别出旅行者的家乡和到访地点的紧急服务号码，将两者映射到同一个通用服务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. A Location-to-Service Translation Protocol (LoST) [LOST] 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.
由于服务URN不可路由，SIP代理或用户代理必须将服务URN转换为位置合适的服务提供者（如SIPURL）的可路由URI。位置到服务转换协议（LoST）[LoST]预计将用作基于地理位置将服务URN映射到URL的解析系统。将来，可能会有几种这样的协议，对于不同的服务可能有不同的协议。
Services are described by top-level service type, and may contain a hierarchy of sub-services that further describe the service, as outlined in Section 3.
服务由顶级服务类型描述，可能包含进一步描述服务的子服务层次结构，如第3节所述。
We discuss alternative approaches for creating service identifiers, and why they are unsatisfactory, in Appendix A.
我们在附录A中讨论了创建服务标识符的替代方法，以及它们不令人满意的原因。
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 [RFC2119].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[RFC2119]中的说明进行解释。
Terminology specific to emergency services is defined in [RFC5012].
[RFC5012]中定义了应急服务专用术语。
Below, we include the registration template for the URN scheme according to RFC 3406 [RFC3406].
下面，我们根据RFC 3406[RFC3406]包括URN方案的注册模板。
Namespace ID: service
命名空间ID:服务
Registration Information:
注册资料：
Registration version: 1
注册版本：1
Registration date: 2006-04-02
注册日期：2006-04-02
Declared registrant of the namespace:
已声明命名空间的注册人：
Registering organization: IETF
注册机构：IETF
Designated contact: Henning Schulzrinne
指定联系人：Henning Schulzrinne
Designated contact email: hgs@cs.columbia.edu
指定联络电邮：hgs@cs.columbia.edu
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 [RFC1123] and a subset of the labels allowed in [RFC3958]. Labels are case-insensitive, but MUST be specified in all lower-case. For any given service URN, service-identifiers can be removed right-to-left; the resulting URN is still valid, referring to 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. The ABNF [RFC4234] is shown below.
语法结构声明：URN由一个分层服务标识符组成，带有一系列由句点分隔的标签。最左边的标签是最重要的，称为“顶级服务”，而右边的名称称为“子服务”。允许的字符集与域名[RFC1123]和[RFC3958]中允许的标签子集相同。标签不区分大小写，但必须以所有小写字母指定。对于任何给定的服务URN，服务标识符可以从右向左移除；生成的URN仍然有效，引用的是更通用的服务。换句话说，如果存在服务“x.y.z”，则URN“x”和“x.y”也是有效的服务URN。ABNF[RFC4234]如下所示。
service-URN = "URN:service:" service
service = top-level *("." sub-service)
top-level = let-dig [ *25let-dig-hyp let-dig ]
sub-service = let-dig [ *let-dig-hyp let-dig ]
let-dig-hyp = let-dig / "-"
let-dig = ALPHA / DIGIT
ALPHA = %x41-5A / %x61-7A ; A-Z / a-z
DIGIT = %x30-39 ; 0-9
service-URN = "URN:service:" service
service = top-level *("." sub-service)
top-level = let-dig [ *25let-dig-hyp let-dig ]
sub-service = let-dig [ *let-dig-hyp let-dig ]
let-dig-hyp = let-dig / "-"
let-dig = ALPHA / DIGIT
ALPHA = %x41-5A / %x61-7A ; A-Z / a-z
DIGIT = %x30-39 ; 0-9
Relevant ancillary documentation: None
相关辅助文件：无
Community considerations: The service URN is believed 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 the user's current location. For example, travelers will be able to use their mobile devices to request emergency services without 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.
社区注意事项：URN服务被认为与各种设备上的大量互联网用户相关，包括技术和非技术用户，但特别是移动和游牧用户。服务URN将允许需要服务的互联网用户按种类识别服务，而无需手动确定在用户的当前上下文中（例如，在用户的当前位置）谁提供特定服务。例如，旅行者可以使用他们的移动设备请求紧急服务，而不必知道被访问国家的紧急拨号字符串。IANA注意事项（第4节）中描述了标识符的分配。服务URN没有规定特定的解决机制，但假定有许多不同的实体可以运行并提供此类机制。
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., [RFC3044], [RFC3187], [RFC4179], and [RFC4195]), types of telecommunications equipment [RFC4152], people, or organizations [RFC3043]. tel URIs [RFC3966] identify telephone numbers, but numbers commonly identifying services (such as 911 or 112) are specific to a particular region or country.
名称空间注意事项：似乎没有其他URN名称空间满足唯一标识广泛可用的通信和信息服务的相同需求。与大多数其他当前注册的URN名称空间不同，服务URN不标识文档和协议对象（例如，[RFC3044]、[RFC3187]、[RFC4179]和[RFC4195]）、电信设备类型[RFC4152]、人员或组织[RFC3043]。电话URI[RFC3966]标识电话号码，但通常标识服务的号码（如911或112）特定于特定地区或国家。
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.
标识符唯一性注意事项：服务URN标识服务注册中指定的逻辑服务（请参阅IANA注意事项（第4节））。URN解析如果成功，将返回服务的特定实例，即使两个用户同时在同一地点发出相同请求，该实例也可能不同；但是，URN标识的逻辑服务是持久的和唯一的。对于每个唯一的服务，服务URN必须是唯一的；这是通过在该名称空间中注册每个服务来保证的，如第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.
标识符持久性注意事项：同一服务的“服务”URN应该是持久的，尽管自然不能保证某个特定服务将在全局或任何时候继续可用。
Process of identifier assignment: The process of identifier assignment is described in the IANA Considerations (Section 4).
标识符分配过程：IANA注意事项（第4节）中描述了标识符分配过程。
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.
标识符解析过程：“服务”URN没有单个全局解析服务。但是，每个顶级服务都可以提供一组映射协议，用于该服务的“服务”URN。
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.
与URN语法的一致性：上述“语法结构声明”中的BNF限制了此URN方案的语法。
Validation mechanism: Validation determines whether a given string is currently a validly-assigned URN [RFC3406]. 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.
验证机制：验证确定给定字符串当前是否为有效分配的URN[RFC3406]。由于映射机制的分布式特性，并且并非所有服务都在任何地方都可用，并且并非所有映射服务器都可以配置所有当前服务注册，因此不可能进行这种意义上的验证。此外，映射机制的发现机制可能未配置所有当前顶级服务。
Scope: The scope for this URN is public and global.
作用域：此URN的作用域是公共的和全局的。
This section registers a new URN scheme with the registration template provided in Section 3.
本节使用第3节中提供的注册模板注册新的URN方案。
Below, Section 4.1 details how to register new service-identifying labels. Descriptions of sub-services for the first two services to be registered, sos and counseling, are given in Section 4.2 and Section 4.3, respectively. Finally, Section 4.4 contains the initial registration table.
下面第4.1节详细介绍了如何注册新的服务标识标签。第4.2节和第4.3节分别给出了前两个待注册服务（sos和咨询）的子服务描述。最后，第4.4节包含初始登记表。
Services and sub-services are identified by labels managed by IANA, according to the processes outlined in [RFC2434] 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
服务和子服务由IANA管理的标签标识，根据[RFC2434]在一个名为“服务URN标签”的新注册中心中概述的流程标识。因此，创建新服务需要IANA操作。添加顶级服务标签的策略是
'Standards Action'. (This document defines the top-level services '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.
“标准行动”。（本文件定义了顶级服务“sos”和“咨询”。）为子服务分配标签的政策可能因每个顶级服务指定而不同，并且必须由描述顶级服务的文件定义。
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
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 [RFC3958], all top-level service names MUST NOT exceed 27 characters.
要允许在S-NAPTR[RFC3958]的约束范围内使用，所有顶级服务名称不得超过27个字符。
This section defines the first service registration within the IANA registry defined in Section 4.1, using the top-level service label 'sos'.
本节使用顶级服务标签“sos”，定义了第4.1节中定义的IANA注册中心内的第一个服务注册。
The 'sos' service type describes emergency services requiring an immediate response, typically offered by various branches of the government or other public institutions. Additional sub-services can be added after expert review and must be of general public interest and have a similar emergency nature. The expert is designated by the ECRIT working group, its successor, or, in their absence, the IESG. The expert review should only approve emergency services that are offered widely and in different countries, with approximately the same caller expectation in terms of services rendered. The 'sos' service is not meant to invoke general government, public information, counseling, or social services.
“sos”服务类型描述了需要立即响应的紧急服务，通常由政府各部门或其他公共机构提供。经专家审查后，可增加额外的子服务，且必须符合一般公众利益，并具有类似的紧急性质。专家由ECRIT工作组、其继任者或IESG（在他们缺席的情况下）指定。专家审查应只批准在不同国家广泛提供的紧急服务，且呼叫者对所提供服务的期望大致相同。“sos”服务并不意味着调用一般政府、公共信息、咨询或社会服务。
urn:service:sos The generic 'sos' service reaches a public safety answering point (PSAP), which in turn dispatches aid appropriate to the emergency. It encompasses all of the services listed below.
urn：服务：sos通用的“sos”服务到达公共安全应答点（PSAP），该应答点依次为紧急情况发送适当的援助。它包括以下列出的所有服务。
urn:service:sos.ambulance This service identifier reaches an ambulance service that provides emergency medical assistance and transportation.
urn:service:sos.救护车此服务标识符到达提供紧急医疗援助和运输的救护车服务。
urn:service:sos.animal-control Animal control typically enforces laws and ordinances pertaining to animal control and management, investigates cases of animal abuse, educates the community in responsible pet ownership and wildlife care, and provides for the housing and care of homeless animals, among other animal-related services.
urn：服务：sos。动物控制动物控制通常执行与动物控制和管理有关的法律和条例，调查虐待动物的案件，教育社区负责任的宠物主人和野生动物护理，提供无家可归动物的住房和护理，以及其他与动物相关的服务。
urn:service:sos.fire The 'fire' service identifier summons the fire service, also known as the fire brigade or fire department.
urn:service:sos.fire“消防”服务标识符召唤消防服务，也称为消防队或消防部门。
urn:service:sos.gas The 'gas' service allows the reporting of natural gas (and other flammable gas) leaks or other natural gas emergencies.
urn:service:sos.gas“gas”服务允许报告天然气（和其他易燃气体）泄漏或其他天然气紧急情况。
urn:service:sos.marine The 'marine' service refers to maritime search and rescue services such as those offered by the coast guard, lifeboat, or surf lifesavers.
urn:service:sos.marine“marine”服务是指海上搜救服务，如海岸警卫队、救生艇或冲浪救生员提供的服务。
urn:service:sos.mountain The 'mountain' service refers to mountain rescue services (i.e., search and rescue activities that occur in a mountainous environment), although the term is sometimes also used to apply to search and rescue in other wilderness environments.
urn:service:sos.mountain“山地”服务是指山地救援服务（即在山地环境中进行的搜索和救援活动），尽管该术语有时也用于其他荒野环境中的搜索和救援。
urn:service:sos.physician The 'physician' emergency service connects the caller to a physician referral service.
urn:service:sos.medical“医师”急救服务将呼叫者连接到医师转诊服务。
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.poison“中毒”服务是指专门设立的信息中心，告知公民如何应对潜在中毒。这些毒物控制中心维护毒物数据库和适当的紧急治疗。
urn:service:sos.police The 'police' service refers to the police department or other law enforcement authorities.
urn:service:sos.police“警察”服务是指警察部门或其他执法机构。
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 described for the 'sos' service. The expert review should take into account whether these services are offered widely and in different countries, with approximately the same caller expectation in terms of services rendered.
“咨询”服务类型描述了呼叫者可以接受建议和支持的服务，通常是匿名的，但不需要紧急响应。（当然，如果情况需要，此类服务可以将呼叫者转移到紧急服务或召集此类服务。）在专家审查后，可以添加额外的子服务，并应符合公众利益。专家的选择方式与“sos”服务相同。专家审评应考虑到这些服务是否在不同的国家广泛提供，在所提供的服务方面，来电者的期望大致相同。
urn:service:counseling The generic 'counseling' service reaches a call center that transfers the caller based on his or her specific needs.
urn：服务：咨询一般的“咨询”服务到达呼叫中心，呼叫中心根据来电者的具体需求转接来电者。
urn:service:counseling.children The 'children' service refers to 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：服务：咨询。儿童“儿童”服务是指专门针对儿童需求而提供的咨询和支持服务。例如，这类服务可以向离家出走者或虐待儿童的受害者提供咨询。
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：服务：咨询。心理健康“心理健康”服务是指“诊断、治疗和预防性护理，帮助改善精神病患者的身体和情感感受以及他们与他人的互动方式”。（美国卫生与公共服务部）
urn:service:counseling.suicide The 'suicide' service refers to the suicide prevention hotline.
服务：咨询。自杀“自杀”服务是指自杀预防热线。
The following table contains the initial IANA registration for emergency and counseling services.
下表包含应急和咨询服务的初始IANA注册。
Service Reference Description
--------------------------------------------------------------------
counseling RFC 5031 Counseling services
counseling.children RFC 5031 Counseling for children
counseling.mental-health RFC 5031 Mental health counseling
counseling.suicide RFC 5031 Suicide prevention hotline
Service Reference Description
--------------------------------------------------------------------
counseling RFC 5031 Counseling services
counseling.children RFC 5031 Counseling for children
counseling.mental-health RFC 5031 Mental health counseling
counseling.suicide RFC 5031 Suicide prevention hotline
sos RFC 5031 Emergency services sos.ambulance RFC 5031 Ambulance service sos.animal-control RFC 5031 Animal control sos.fire RFC 5031 Fire service sos.gas RFC 5031 Gas leaks and gas emergencies sos.marine RFC 5031 Maritime search and rescue sos.mountain RFC 5031 Mountain rescue sos.physician RFC 5031 Physician referral service sos.poison RFC 5031 Poison control center sos.police RFC 5031 Police, law enforcement
sos RFC 5031紧急服务sos.救护车RFC 5031救护车服务sos.animal-control RFC 5031动物控制sos.fire RFC 5031消防服务sos.gas RFC 5031气体泄漏和气体紧急情况sos.marine RFC 5031海上搜救sos.mountain RFC 5031 mountain rescue sos.Medical RFC 5031医师转诊服务sos.Town RFC 5031毒药控制中心sos.police RFC 5031警察、执法部门
The service labels are protocol elements [RFC3536] and are not normally seen by users. Thus, the character set for these elements is restricted, as described in Section 3.
服务标签是协议元素[RFC3536]，用户通常看不到。因此，如第3节所述，这些元素的字符集受到限制。
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.
作为标识符，服务URN似乎不会引起任何特定的安全问题。URN描述的服务是众所周知的，即使特定的服务实例是访问控制的，所以隐私考虑不适用于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 [RFC5069]. That document also discusses the security considerations related to the use of the service URN for emergency services.
例如，在网页上包含服务URN时，可能没有特定的隐私问题。另一方面，在信令协议中传递URN可以向攻击者提供有关调用方所需服务类型的信息。例如，这使攻击者更容易自动查找所有紧急服务或目录帮助呼叫。需要为承载服务URN的协议实现适当的、特定于协议的安全机制。映射协议需要解决许多威胁，详见[RFC5069]。该文件还讨论了与紧急服务使用服务URN相关的安全注意事项。
[RFC1123] Braden, R., "Requirements for Internet Hosts - Application and Support", STD 3, RFC 1123, October 1989.
[RFC1123]Braden，R.，“互联网主机的要求-应用和支持”，STD 3，RFC 1123，1989年10月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[RFC2434]Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 2434，1998年10月。
[RFC3261] 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.
[RFC3261]Rosenberg，J.，Schulzrinne，H.，Camarillo，G.，Johnston，A.，Peterson，J.，Sparks，R.，Handley，M.，和E.Schooler，“SIP：会话启动协议”，RFC 3261，2002年6月。
[RFC3958] Daigle, L. and A. Newton, "Domain-Based Application Service Location Using SRV RRs and the Dynamic Delegation Discovery Service (DDDS)", RFC 3958, January 2005.
[RFC3958]Daigle，L.和A.Newton，“使用SRV RRs和动态委托发现服务（DDDS）的基于域的应用程序服务定位”，RFC 3958，2005年1月。
[RFC4234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 4234, October 2005.
[RFC4234]Crocker，D.，Ed.和P.Overell，“语法规范的扩充BNF:ABNF”，RFC 4234，2005年10月。
[LOST] Hardie, T., "LoST: A Location-to-Service Translation Protocol", Work in Progress, March 2007.
[LOST]Hardie，T.，“LOST:Location to Service Translation Protocol”，正在进行的工作，2007年3月。
[RFC2142] Crocker, D., "MAILBOX NAMES FOR COMMON SERVICES, ROLES AND FUNCTIONS", RFC 2142, May 1997.
[RFC2142]Crocker，D.，“公共服务、角色和功能的邮箱名称”，RFC 2142，1997年5月。
[RFC2822] Resnick, P., "Internet Message Format", RFC 2822, April 2001.
[RFC2822]Resnick，P.，“互联网信息格式”，RFC 2822，2001年4月。
[RFC3043] Mealling, M., "The Network Solutions Personal Internet Name (PIN): A URN Namespace for People and Organizations", RFC 3043, January 2001.
[RFC3043]Mealling，M.，“网络解决方案个人互联网名称（PIN）：个人和组织的URN名称空间”，RFC3043，2001年1月。
[RFC3044] Rozenfeld, S., "Using The ISSN (International Serial Standard Number) as URN (Uniform Resource Names) within an ISSN-URN Namespace", RFC 3044, January 2001.
[RFC3044]Rozenfeld，S.，“在ISSN-URN名称空间中将ISSN（国际序列号）用作URN（统一资源名）”，RFC 3044，2001年1月。
[RFC3187] Hakala, J. and H. Walravens, "Using International Standard Book Numbers as Uniform Resource Names", RFC 3187, October 2001.
[RFC3187]Hakala，J.和H.Walravens，“使用国际标准书号作为统一资源名称”，RFC 3187，2001年10月。
[RFC3406] Daigle, L., van Gulik, D., Iannella, R., and P. Faltstrom, "Uniform Resource Names (URN) Namespace Definition Mechanisms", BCP 66, RFC 3406, October 2002.
[RFC3406]Daigle，L.，van Gulik，D.，Iannella，R.，和P.Faltstrom，“统一资源名称（URN）命名空间定义机制”，BCP 66，RFC 3406，2002年10月。
[RFC3536] Hoffman, P., "Terminology Used in Internationalization in the IETF", RFC 3536, May 2003.
[RFC3536]Hoffman，P.，“IETF国际化中使用的术语”，RFC3536，2003年5月。
[RFC3966] Schulzrinne, H., "The tel URI for Telephone Numbers", RFC 3966, December 2004.
[RFC3966]Schulzrinne，H.，“电话号码的电话URI”，RFC 3966，2004年12月。
[RFC4152] Tesink, K. and R. Fox, "A Uniform Resource Name (URN) Namespace for the Common Language Equipment Identifier (CLEI) Code", RFC 4152, August 2005.
[RFC4152]Tesink，K.和R.Fox，“公共语言设备标识符（CLEI）代码的统一资源名称（URN）命名空间”，RFC 4152，2005年8月。
[RFC4179] Kang, S., "Using Universal Content Identifier (UCI) as Uniform Resource Names (URN)", RFC 4179, October 2005.
[RFC4179]Kang，S.“使用通用内容标识符（UCI）作为统一资源名（URN）”，RFC 4179，2005年10月。
[RFC4195] Kameyama, W., "A Uniform Resource Name (URN) Namespace for the TV-Anytime Forum", RFC 4195, October 2005.
[RFC4195]Kameyama，W.，“TV Anytime论坛的统一资源名（URN）命名空间”，RFC 41952005年10月。
[RFC5012] Schulzrinne, H. and R. Marshall, Ed., "Requirements for Emergency Context Resolution with Internet Technologies", RFC 5012, January 2008.
[RFC5012]Schulzrinne，H.和R.Marshall，Ed.“使用互联网技术解决紧急情况的要求”，RFC 5012，2008年1月。
[RFC5069] Taylor, T., Ed., Tschofenig, H., Schulzrinne, H., and M. Shanmugam, "Security Threats and Requirements for Emergency Call Marking and Mapping", RFC 5069, January 2008.
[RFC5069]Taylor，T.，Ed.，Tschofenig，H.，Schulzrinne，H.，和M.Shanmugam，“紧急呼叫标记和映射的安全威胁和要求”，RFC 5069，2008年1月。
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 [RFC3966]. 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.
电话:NNN ;；context=+C此方法使用tel-uri[RFC3966]。在这里，NNN是国家紧急号码，国家由上下文C确定。这种方法对于用户代理来说很容易实现，但是对于代理和其他SIP元素来说很难识别，因为它必须了解世界上所有的号码上下文组合并跟踪偶尔的变化。此外，这些数字中的许多正在用于其他服务。例如，巴拉圭的紧急电话号码（00）也用于呼叫美国的国际接线员。另一个例子是，一些国家，如意大利，使用118作为紧急号码，但它也连接到芬兰的目录援助。
tel:sos This solution avoids name conflicts, but requires extending the "tel" URI "tel" [RFC3966]. It also only works if every outbound proxy knows how to route requests to a proxy that can reach emergency services since tel URIs do not identify the destination server.
tel:sos此解决方案避免了名称冲突，但需要扩展“tel”URI“tel”[RFC3966]。它也只有在每个出站代理都知道如何将请求路由到可以到达紧急服务的代理时才起作用，因为teluri没有标识目标服务器。
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 [RFC2142] and the "postmaster" convention documented in RFC 2822 [RFC2822]. 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.
抿：sos@domain先前的工作已经在SIP URI中的主叫域中定义了一个特殊的用户标识符sos，例如SIP:sos@example.com. 这种用户标识符遵循RFC 2142[RFC2142]的约定和RFC 2822[RFC2822]中记录的“邮政局长”约定。这种方法的优点是，可以转换现有用户代理中的拨号计划以生成这样的URI，并且只有域的主代理必须理解用户命名约定。但是，它使用特定的语义（而不是不透明）重载URI的用户部分，使出站代理路由成为不符合正常SIP请求URI处理规则且特定于SIP的特例。该机制也不容易扩展到其他服务。
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
SIPURI用户参数：可以创建一个特殊的URI，例如“aor域；用户=sos”。这避免了名称冲突问题，但需要能够发出此特殊URI的机制感知用户代理。另外，“user”参数用于描述SIP URI的用户部分的格式，而这种用法不这样做。添加其他参数仍不清楚，如果
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.
任何约定都应用于URL的用户和域部分。这两种解决方案都不可能与现有客户端向后兼容。
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.
特殊域：特殊域，如“sip:fire@sos.int“可用于识别紧急呼叫。它的属性与“tel:sos”URI类似，只是它确实是一个有效的URI。要使其可用，特殊域必须可操作并指向适当的紧急服务代理。为全世界提供一个单一的（如果合乎逻辑的话）应急服务代理似乎具有不理想的可扩展性和管理特性。
This document is based on discussions with Jonathan Rosenberg and benefited from the comments of Leslie Daigle, Keith Drage, Benja Fallenstein, Paul Kyzivat, Andrew Newton, Brian Rosen, Jonathan Rosenberg, Martin Thomson, and Hannes Tschofenig.
本文件基于与Jonathan Rosenberg的讨论，并受益于Leslie Daigle、Keith Drage、Benja Fallenstein、Paul Kyzivat、Andrew Newton、Brian Rosen、Jonathan Rosenberg、Martin Thomson和Hannes Tschofenig的评论。
Author's Address
作者地址
Henning Schulzrinne Columbia University Department of Computer Science 450 Computer Science Building New York, NY 10027 US
美国纽约州纽约市哥伦比亚大学计算机科学系计算机科学大楼450号
Phone: +1 212 939 7004
EMail: hgs+ecrit@cs.columbia.edu
URI: http://www.cs.columbia.edu
Phone: +1 212 939 7004
EMail: hgs+ecrit@cs.columbia.edu
URI: http://www.cs.columbia.edu
Full Copyright Statement
完整版权声明
Copyright (C) The IETF Trust (2008).
版权所有（C）IETF信托基金（2008年）。
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.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
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, THE IETF TRUST 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.
本文件及其包含的信息以“原样”为基础提供，贡献者、他/她所代表或赞助的组织（如有）、互联网协会、IETF信托基金和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
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.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和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.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为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.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.