Network Working Group J. Peterson
Request for Comments: 3824 H. Liu
Category: Informational J. Yu
NeuStar
B. Campbell
dynamicsoft
June 2004
Network Working Group J. Peterson
Request for Comments: 3824 H. Liu
Category: Informational J. Yu
NeuStar
B. Campbell
dynamicsoft
June 2004
Using E.164 numbers with the Session Initiation Protocol (SIP)
在会话启动协议（SIP）中使用E.164编号
Status of this Memo
本备忘录的状况
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
本备忘录为互联网社区提供信息。它没有规定任何类型的互联网标准。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2004).
版权所有（C）互联网协会（2004年）。
Abstract
摘要
There are a number of contexts in which telephone numbers are employed by Session Initiation Protocol (SIP) applications, many of which can be addressed by ENUM. Although SIP was one of the primary applications for which ENUM was created, there is nevertheless a need to define procedures for integrating ENUM with SIP implementations. This document illustrates how the two protocols might work in concert, and clarifies the authoring and processing of ENUM records for SIP applications. It also provides guidelines for instances in which ENUM, for whatever reason, cannot be used to resolve a telephone number.
在许多上下文中，会话启动协议（SIP）应用程序使用电话号码，其中许多可以通过ENUM进行处理。尽管SIP是创建ENUM的主要应用程序之一，但仍需要定义将ENUM与SIP实现集成的过程。本文档说明了这两个协议如何协同工作，并阐明了SIP应用程序枚举记录的编写和处理。它还为因任何原因无法使用ENUM解析电话号码的实例提供了指导。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Handling Telephone Numbers in SIP . . . . . . . . . . . . . . 3
4. Design Principles . . . . . . . . . . . . . . . . . . . . . . 5
5. Authoring NAPTR Records for SIP . . . . . . . . . . . . . . . 6
5.1. The Service Field . . . . . . . . . . . . . . . . . . . 6
5.2. Creating the Regular Expression: Matching . . . . . . . 6
5.3. Creating the Regular Expression: The URI . . . . . . . . 7
5.4. Setting Order and Preference amongst Records . . . . . . 8
5.5. Example of a Well-Formed ENUM NAPTR Record Set for SIP. 8
6. Processing ENUM Records . . . . . . . . . . . . . . . . . . . 8
6.1. Contending with Multiple SIP records . . . . . . . . . . 8
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Handling Telephone Numbers in SIP . . . . . . . . . . . . . . 3
4. Design Principles . . . . . . . . . . . . . . . . . . . . . . 5
5. Authoring NAPTR Records for SIP . . . . . . . . . . . . . . . 6
5.1. The Service Field . . . . . . . . . . . . . . . . . . . 6
5.2. Creating the Regular Expression: Matching . . . . . . . 6
5.3. Creating the Regular Expression: The URI . . . . . . . . 7
5.4. Setting Order and Preference amongst Records . . . . . . 8
5.5. Example of a Well-Formed ENUM NAPTR Record Set for SIP. 8
6. Processing ENUM Records . . . . . . . . . . . . . . . . . . . 8
6.1. Contending with Multiple SIP records . . . . . . . . . . 8
6.2. Processing the Selected NAPTR Record . . . . . . . . . . 9
7. Compatibility with RFC 3761. . . . . . . . . . . . . . . . . . 10
8. Security Considerations . . . . . . . . . . . . . . . . . . . 11
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
9.1. Normative References . . . . . . . . . . . . . . . . . . 11
9.2. Informative References . . . . . . . . . . . . . . . . . 12
A. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 15
Full Copyright Statement . . . . . . . . . . . . . . . . . . . 16
6.2. Processing the Selected NAPTR Record . . . . . . . . . . 9
7. Compatibility with RFC 3761. . . . . . . . . . . . . . . . . . 10
8. Security Considerations . . . . . . . . . . . . . . . . . . . 11
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
9.1. Normative References . . . . . . . . . . . . . . . . . . 11
9.2. Informative References . . . . . . . . . . . . . . . . . 12
A. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 15
Full Copyright Statement . . . . . . . . . . . . . . . . . . . 16
ENUM (E.164 Number Mapping, RFC 3761 [1]) is a system that uses DNS (Domain Name Service, RFC 1034 [4]) in order to translate certain telephone numbers, like '+12025332600', into URIs (Uniform Resource Identifiers, RFC 2396 [9]), like 'sip:user@sipcarrier.com'. ENUM exists primarily to facilitate the interconnection of systems that rely on telephone numbers with those that use URIs to route transactions. E.164 [10] is the ITU-T standard international numbering plan, under which all globally-reachable telephone numbers are organized.
ENUM（E.164数字映射，RFC 3761[1]）是一个使用DNS（域名服务，RFC 1034[4]）将某些电话号码（如“+12025332600”）转换为URI（统一资源标识符，RFC 2396[9]），如“sip:user@sipcarrier.com'. ENUM的存在主要是为了促进依赖电话号码的系统与使用uri路由事务的系统之间的互连。E.164[10]是ITU-T标准国际编号计划，根据该计划，所有全球可访问的电话号码都被组织起来。
SIP (Session Initiation Protocol, RFC 3261 [2]) is a text-based application protocol that allows two endpoints in the Internet to discover one another in order to exchange context information about a session they would like to share. Common applications for SIP include Internet telephony, instant messaging, video, Internet gaming, and other forms of real-time communications. SIP is a multi-service protocol capable of initiating sessions involving different forms of real-time communications simultaneously.
SIP（Session Initiation Protocol，RFC 3261[2]）是一种基于文本的应用程序协议，它允许Internet中的两个端点相互发现，以便交换有关他们想要共享的会话的上下文信息。SIP的常见应用包括互联网电话、即时消息、视频、互联网游戏和其他形式的实时通信。SIP是一种多业务协议，能够同时启动涉及不同形式实时通信的会话。
The most widespread application for SIP today is Voice-over-IP (VoIP). As such, there are a number of cases in which SIP applications are forced to contend with telephone numbers. Unfortunately, telephone numbers cannot be routing in accordance with the traditional DNS resolution procedures standardized for SIP (see [14]), which rely on SIP URIs. ENUM provides a method for translating E.164 numbers into URIs, including potentially SIP URIs. This document therefore provides an account of how SIP can handle telephone numbers by making use of ENUM. Guidelines are proposed for the authoring of the DNS records used by ENUM, and for client-side processing once these DNS records have been received.
目前SIP最广泛的应用是IP语音（VoIP）。因此，在许多情况下，SIP应用程序被迫与电话号码竞争。不幸的是，电话号码无法按照SIP标准化的传统DNS解析程序（参见[14]）进行路由，该程序依赖于SIP URI。ENUM提供了一种将E.164数字转换为URI的方法，包括潜在的SIPURI。因此，本文档介绍了SIP如何利用ENUM处理电话号码。本指南针对ENUM使用的DNS记录的创作以及收到这些DNS记录后的客户端处理提出了建议。
The guidelines in this document are oriented towards authoring and processing ENUM records specifically for SIP applications. These guidelines assume that the reader is familiar with Naming Authority Pointer (NAPTR) records (RFC 3403 [6]) and ENUM (RFC 3761 [1]). Only those aspects of NAPTR record authoring and processing that have
本文档中的指导方针旨在专门为SIP应用程序编写和处理枚举记录。这些指南假定读者熟悉命名机构指针（NAPTR）记录（RFC 3403[6]）和枚举（RFC 3761[1]）。只有NAPTR记录创作和处理的那些方面
special bearing on SIP, or that require general clarification, are covered in this document; these procedures do not update or override the NAPTR or ENUM core documents.
本文件涵盖了与SIP的特殊关系或需要一般澄清的内容；这些过程不会更新或覆盖NAPTR或ENUM核心文档。
Note that the ENUM specification has undergone a revision shortly before the publication of this document, driven by the update of the NAPTR system described in RFC 2915 [12] to the Dynamic Delegation Discovery System (DDDS) family of specifications (including RFC 3403). This document therefore provides some guidance for handling records designed for the original RFC 2916 [16].
请注意，由于RFC 2915[12]中所述的NAPTR系统更新为动态委托发现系统（DDDS）规范系列（包括RFC 3403），因此在本文件发布前不久，ENUM规范已进行了修订。因此，本文件为处理为原始RFC 2916设计的记录提供了一些指导[16]。
The remainder of this document is organized as follows: Section 3 suggests general behavior for SIP user agents that encounter telephone numbers; Section 4 provides an overview of the intersection of SIP and ENUM; proposed normative guidelines for ENUM record authoring and processing in the context of SIP are described in Section 5, and Section 6 respectively; some considerations relevant to the revision of RFC 2916 are given in Section 7.
本文档的其余部分组织如下：第3节建议遇到电话号码的SIP用户代理的一般行为；第4节概述了SIP和ENUM的交叉点；第5节和第6节分别描述了SIP环境下枚举记录编写和处理的拟议规范性指南；第7节给出了与RFC 2916修订相关的一些注意事项。
In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in RFC 2119 [3] and indicate requirement levels for compliant SIP implementations.
在本文件中，关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“不建议”、“可”和“可选”将按照RFC 2119[3]中的描述进行解释，并表示符合SIP实施的要求级别。
There are a number of reasons why a user might want to initiate a SIP request that targets an E.164 number. One common reason is that the user is calling from the PSTN through a PSTN-SIP gateway; such gateways usually map routing information from the PSTN directly on to SIP signaling. Or a native SIP user might intentionally initiate a session addressed to an E.164 number - perhaps because the target user is canonically known by that number, or the originator's SIP user agent only supports a traditional numeric telephone keypad. A request initially targeting a conventional SIP URI might also be redirected to an E.164 number. In most cases, these are requests for a telephony session (voice communication), though numerous other services are also reached through telephone numbers (including instant messaging services).
用户可能希望发起以E.164号码为目标的SIP请求的原因有很多。一个常见的原因是用户通过PSTN-SIP网关从PSTN呼叫；这种网关通常将路由信息从PSTN直接映射到SIP信令。或者，本机SIP用户可能会有意发起一个以E.164号码为地址的会话，这可能是因为目标用户通常以该号码为准，或者发起人的SIP用户代理仅支持传统的数字电话键盘。最初以传统SIPURI为目标的请求也可能被重定向到E.164号码。在大多数情况下，这些都是对电话会话（语音通信）的请求，尽管许多其他服务也通过电话号码（包括即时消息服务）实现。
Unlike a URI, a telephone number does not contain a host name, or any hints as to where one might deliver a request targeting a telephone number on the Internet. While SIP user agents or proxy servers could be statically provisioned with a mapping of destinations corresponding to particular telephone numbers or telephone number
与URI不同的是，电话号码不包含主机名，也不包含任何关于在Internet上以电话号码为目标发送请求的提示。而SIP用户代理或代理服务器可以静态地配置与特定电话号码或电话号码对应的目的地映射
ranges, considering the size and complexity of a complete mapping, it would be preferable for SIP user agents to be able to query as needed for a destination appropriate for a particular telephone number.
范围，考虑到完整映射的大小和复杂性，SIP用户代理最好能够根据需要查询适合特定电话号码的目的地。
In such cases a user agent might use ENUM to discover a URI associated with the E.164 number - including a SIP URI. URIs discovered through ENUM can then be used normally to route SIP requests to their destination. Note that support for the NAPTR DNS resource record format is specified for ordinary SIP URI processing in [14], and thus support for ENUM is not a significant departure from baseline SIP DNS routing.
在这种情况下，用户代理可以使用ENUM来发现与E.164号码相关联的URI，包括SIPURI。然后，通过枚举发现的URI可以正常用于将SIP请求路由到其目的地。请注意，在[14]中为普通SIP URI处理指定了对NAPTR DNS资源记录格式的支持，因此对ENUM的支持与基线SIP DNS路由没有明显的区别。
Most of the remainder of this document provides procedures for the use of ENUM, but a few guidelines are given in the remainder of this section for cases in which ENUM is not used, for whatever reason.
本文档的大部分剩余部分提供了使用ENUM的过程，但本节的剩余部分为出于任何原因未使用ENUM的情况提供了一些指导原则。
If a user agent is unable to translate an E.164 number with ENUM, it can create a type of SIP Request-URI that contains a telephone number. Since one of the most common applications of SIP is telephony, a great deal of attention has already been devoted to the representation of telephone numbers in SIP. In particular, the tel URL RFC 2806 [8] has been identified as a way of carrying telephone routing information within SIP. A tel URL usually consists of the number in E.164 format preceded by a plus sign, e.g.,: tel:+12025332600. This format is so useful that it has been incorporated into the baseline SIP specification; the user portion of a SIP URI can contain a tel URL (without the scheme string, like sip:+12025332600@carrier.com;user=phone). A SIP proxy server might therefore receive a request from a user agent with a tel URL in the Request-URI; one way in which the proxy server could handle this sort of request is by launching an ENUM query itself, and proxying the SIP request in accordance with the returned ENUM records.
如果用户代理无法使用ENUM转换E.164号码，它可以创建一种包含电话号码的SIP请求URI。由于SIP最常见的应用之一是电话，因此SIP中电话号码的表示已经引起了极大的关注。特别地，已将电话URL RFC 2806[8]识别为在SIP内承载电话路由信息的方式。电话URL通常由E.164格式的数字和加号组成，例如：tel:+12025332600。该格式非常有用，已被纳入基线SIP规范中；SIP URI的用户部分可以包含tel URL（没有方案字符串，如SIP:+12025332600@carrier.com；用户=电话）。因此，SIP代理服务器可以接收来自用户代理的请求，请求URI中包含tel URL；代理服务器处理此类请求的一种方法是启动枚举查询本身，并根据返回的枚举记录代理SIP请求。
In the absence of support for ENUM, or if ENUM requests return no records corresponding to a telephone number, local policy can be used to determine how to forward SIP requests with an E.164 number in the Request-URI. Frequently, such calls are routed to gateways that interconnect SIP networks with the PSTN. These proxy server policies might be provisioned dynamically with routing information for telephone numbers by TRIP [15]. As a matter of precedence, SIP user agents should attempt to translate telephone numbers to URIs with ENUM, if implemented, before creating a tel URL, and deferring the routing of this request to a SIP proxy server.
在不支持ENUM的情况下，或者如果ENUM请求没有返回与电话号码对应的记录，则可以使用本地策略来确定如何转发请求URI中带有E.164号码的SIP请求。通常，此类呼叫被路由到将SIP网络和PSTN互连的网关。这些代理服务器策略可以通过TRIP动态地为电话号码提供路由信息[15]。作为优先事项，SIP用户代理应在创建tel URL并将此请求的路由推迟到SIP代理服务器之前，尝试将电话号码转换为带有ENUM的URI（如果已实现）。
Although the applicability of ENUM to SIP has always been clear, the exact way in which the two should cooperate has been a subject of some controversy. How many SIP URIs should appear in ENUM, what kind of URIs they are, whether or not the "service" field of NAPTR records should contain capability information - numerous questions have arisen around the authoring, and interpretation of ENUM records for SIP consumers. The following, then, is a statement of the particular philosophy that has motivated the recommendations in this document:
尽管ENUM对SIP的适用性一直很明确，但两者合作的确切方式一直存在争议。枚举中应该出现多少SIP URI，它们是什么类型的URI，NAPTR记录的“服务”字段是否应该包含功能信息-围绕SIP使用者的枚举记录的编写和解释，出现了许多问题。因此，以下是激励本文件中建议的特定理念的陈述：
Address-of-record SIP URIs appear in ENUM, not contact address URIs. Roughly speaking, an address-of-record is the canonical identity of a SIP user - it usually appears in the From field of SIP requests sent by that user; a contact address is the URI of a device. The process of registration in SIP (using the REGISTER method), for example, temporarily binds the contact address of a device to the address-of-record of a user. A DNS record has a long time-to-live when compared with the timeframe of SIP registrations. The availability of an address-of-record also transcends the availability of any single device. ENUM is more suitable for representing an long-term identity than the URI of any device with which a user is temporarily associated. If ENUM were purposed to map to specific devices, it would be better to translate telephone numbers to IPv4 addresses than to URIs (which express something richer).
记录SIP URI的地址显示在枚举中，而不是联系人地址URI。粗略地说，记录地址是SIP用户的标准身份——它通常出现在该用户发送的SIP请求的From字段中；联系人地址是设备的URI。例如，在SIP中注册的过程（使用注册方法），将设备的联系地址临时绑定到用户的记录地址。与SIP注册的时间框架相比，DNS记录的生存时间较长。记录地址的可用性也超越了任何单个设备的可用性。ENUM比用户临时关联的任何设备的URI更适合表示长期标识。如果ENUM是为了映射到特定的设备，那么最好将电话号码转换为IPv4地址，而不是URI（URI表示更丰富的内容）。
SIP URIs in ENUM do not convey capability information. SIP has its own methods for negotiating capability information between user agents (see SDP [13], the use of Require/Supported to negotiate extensions in RFC 3261, and callee capabilities [11]); providing more limited capability information within ENUM is at best redundant and at worst potentially misleading to SIP's negotiation system. Also, addresses-of-record do not have capabilities (only devices registered under an address-of-record have actual capabilities), and putting contact addresses in ENUM is not recommended.
枚举中的SIP URI不传递功能信息。SIP有自己的方法来协商用户代理之间的能力信息（参见SDP[13]、在RFC 3261中使用Require/Supported协商扩展以及被叫方能力[11]）；在ENUM中提供更有限的能力信息充其量是冗余的，最坏的情况下可能会误导SIP的协商系统。此外，记录地址不具有功能（只有在记录地址下注册的设备才具有实际功能），不建议将联系人地址放入枚举中。
Only one SIP URI, ideally, appears in an ENUM record set for a telephone number. While it may initially seem attractive to provide multiple SIP URIs that reach the same user within ENUM, if there are multiple addresses at which a user can be contacted, considerably greater flexibility is afforded if multiple URIs are managed by a SIP location service that is identified by a single record in ENUM. Behavior for parallel and sequential forking in SIP, for example, is better managed in SIP than in a set of ENUM records.
理想情况下，电话号码的枚举记录集中只显示一个SIPURI。虽然最初提供多个SIP URI以到达ENUM中的同一用户似乎很有吸引力，但如果有多个地址可以联系用户，那么如果多个URI由由由ENUM中的单个记录标识的SIP位置服务管理，则提供了相当大的灵活性。例如，SIP中并行和顺序分叉的行为在SIP中比在一组枚举记录中管理得更好。
User agents, rather than proxy servers, should process ENUM records. The assumptions underlying the processing of NAPTR records dictate that the ENUM client knows the set of enumservices supported by the entity that is attempting to communicate. A SIP proxy server is unlikely to know the enumservices supported by the originator of a SIP request.
用户代理而不是代理服务器应该处理枚举记录。处理NAPTR记录所依据的假设表明，枚举客户端知道尝试通信的实体所支持的枚举服务集。SIP代理服务器不太可能知道SIP请求的发起人支持的服务。
This document makes no assumptions about who authors NAPTR records (service providers or end users), nor about any mechanisms by which a record, once it is authored, may be uploaded to the appropriate DNS servers. Authorship in the context of this document concerns only the processes by which the NAPTR records themselves are constructed.
本文档未对NAPTR记录的作者（服务提供商或最终用户）做出任何假设，也未假设记录一旦被创作，就可以通过任何机制上传到相应的DNS服务器。本文档中的作者身份仅涉及NAPTR记录本身的构造过程。
There are a few general guidelines which are applicable to the authoring of DNS records that should be considered by the authors of ENUM NAPTR record sets. The most important is that authors SHOULD keep record sets relatively small - DNS is not optimized for the transference of large files. Having five or six NAPTR records is quite reasonable, but policies that encourage records sets of hundreds of NAPTR records are not appropriate. Also, DNS records are relatively permanent; authors SHOULD NOT use ENUM NAPTR records to express relationships between E.164 numbers and URIs that potentially exist for only a short time. DNS is most scalable when it can assume records will be valid for a reasonable length of time (at least several hours).
ENUM NAPTR记录集的作者应考虑一些适用于DNS记录创作的一般准则。最重要的是，作者应该保持记录集相对较小-DNS不适合大文件的传输。拥有五到六条NAPTR记录是相当合理的，但鼓励记录集包含数百条NAPTR记录的政策是不合适的。而且，DNS记录是相对永久的；作者不应使用ENUM NAPTR记录来表示E.164编号和可能只存在很短时间的URI之间的关系。当DNS可以假定记录在合理的时间长度（至少几个小时）内有效时，它的可伸缩性最好。
The Service field of a NAPTR record (per RFC 3403) contains a string token that designates the protocol or service associated with a particular record (and which imparts some inkling of the sort of URI that will result from the use of the record). ENUM [1] requires the IANA registration of service fields known as "enumservices".
NAPTR记录的服务字段（根据RFC 3403）包含一个字符串标记，该标记指定与特定记录相关联的协议或服务（并赋予使用该记录将产生的URI类型的一些线索）。ENUM[1]要求对称为“enumservices”的服务字段进行IANA注册。
An enumservice for SIP has been developed in the ENUM working group (see [7]) which uses the format 'E2U+sip' to designate that a SIP address-of-record appears in the URI field of a NAPTR record. It is strongly RECOMMENDED that authors of NAPTR records use the 'E2U+sip' service field whenever the regexp contains a SIP address-of-record URI.
ENUM工作组（见[7]）开发了一个用于SIP的enumservice，它使用“E2U+SIP”格式指定记录的SIP地址出现在NAPTR记录的URI字段中。强烈建议NAPTR记录的作者在regexp包含记录URI的sip地址时使用“E2U+sip”服务字段。
The authorship of the regular expression (henceforth regexp) in a NAPTR record intended for use by ENUM is vastly simplified by the absence of an antecedent in the substitution (i.e., the section
由于替换中没有先行项（即，节），因此，用于ENUM的NAPTR记录中正则表达式（此后为regexp）的作者身份大大简化
between the first two delimiters). It is RECOMMENDED that implementations use an exclamation point as a delimiter, since this is the only delimiter used throughout the ENUM core specification.
在前两个分隔符之间）。建议实现使用感叹号作为分隔符，因为这是整个枚举核心规范中使用的唯一分隔符。
When a NAPTR record is processed, the expression in the antecedent is matched against the starting string (for ENUM, the telephone number) to assist in locating the proper record in a set; however, in ENUM applications, since the desired record set is located through a reverse resolution in the e164.arpa domain that is based on the starting string, further analysis of the starting string on the client side will usually be unnecessary. In such cases, the antecedent of the regular expression is commonly 'greedy' - it uses the regexp '^.*$', which matches any starting string. Some authors of ENUM record sets may want to use the full power of regexps, and create non-greedy antecedents; the DDDS standard requires that ENUM resolvers support these regexps when they are present. For providing a trivial mapping from a telephone number to a SIP URI, the use of a greedy regexp usually suffices.
处理NAPTR记录时，先行项中的表达式与起始字符串（对于ENUM，电话号码）匹配，以帮助在集合中定位正确的记录；但是，在枚举应用程序中，由于所需的记录集是通过e164.arpa域中基于起始字符串的反向解析来定位的，因此通常不需要在客户端对起始字符串进行进一步分析。在这种情况下，正则表达式的先行项通常是“贪婪的”——它使用与任何起始字符串匹配的regexp“^.*$”。枚举记录集的一些作者可能希望充分利用regexp的功能，并创建非贪婪的先行项；DDDS标准要求枚举解析程序在存在这些正则表达式时支持它们。为了提供从电话号码到SIPURI的简单映射，使用贪婪的regexp通常就足够了。
Example: "!^.*$!sip:user@example.com!"
Example: "!^.*$!sip:user@example.com!"
Note that when the antecedent of the regexp is greedy, this does not mean that the replacement field in NAPTR records provides a viable alternative to authoring with a regexp. Authors of NAPTR records for ENUM MUST NOT use the replacement field in records with an 'E2U+sip' service field.
请注意，当regexp的先行项是贪婪的时，这并不意味着NAPTR记录中的replacement字段提供了使用regexp进行创作的可行替代方案。ENUM的NAPTR记录的作者不得在具有“E2U+sip”服务字段的记录中使用替换字段。
The consequent side of a regexp contains a URI; NAPTR records that are intended to be used for session initiation (including SIP telephony) SHOULD use a SIP URI. While this may not sound especially controversial at first hearing, there are other sorts of URIs that might be considered appropriate for SIP applications: 'tel' URIs, 'im' or 'pres' URIs, or others that describe specific services that might be invoked through SIP are all potentially candidates. While the use of these URIs might seem reasonable under some circumstances, including these in NAPTR records rather than SIP URIs could weaken the proper composition of services and negotiation of capabilities in SIP.
regexp的结果端包含一个URI；用于会话启动（包括SIP电话）的NAPTR记录应使用SIP URI。虽然这在第一次听上去可能并不特别有争议，但还有其他类型的URI可能被认为适用于SIP应用程序：“tel”URI、“im”或“pres”URI，或者描述可能通过SIP调用的特定服务的其他URI都是潜在的候选URI。虽然在某些情况下使用这些URI似乎是合理的，但在NAPTR记录中包括这些URI而不是SIP URI可能会削弱SIP中服务的正确组合和功能协商。
It is RECOMMENDED that authors of ENUM records should always use the SIP or SIPS URI scheme when the service field is 'E2U+sip', and the URIs in question MUST be addresses-of-record, not contact addresses.
当服务字段为“E2U+SIP”时，建议枚举记录的作者始终使用SIP或SIPS URI方案，并且所涉及的URI必须是记录的地址，而不是联系人地址。
Users of SIP can register one or more contact addresses with a SIP registrar that will be consulted by the proxy infrastructure of an administrative domain to contact the end user when requests are
SIP用户可以向SIP注册器注册一个或多个联系地址，管理域的代理基础设施将咨询该注册器，以便在请求发出时联系最终用户
received for their address-of-record. Much of the benefit of using a URI comes from the fact that it represents a logical service associated with a user rather than a device - indeed, if ENUM needs to target specific devices rather than URIs, then a hypothetical 'E2IPv4+sip' enumservice would be more appropriate.
收到他们的记录地址。使用URI的大部分好处来自这样一个事实，即它表示与用户而不是设备相关联的逻辑服务——事实上，如果ENUM需要针对特定的设备而不是URI，那么假设的“E2IPv4+sip”enumservice更合适。
For maximal compatibility authors of ENUM records for SIP SHOULD always use the same order value for all NAPTR records in an ENUM record set. If relative preference among NAPTR records is desirable, it should be expressed solely with the preference field.
为实现最大兼容性，SIP枚举记录的作者应始终对枚举记录集中的所有NAPTR记录使用相同的顺序值。如果需要NAPTR记录之间的相对偏好，则应仅使用偏好字段表示。
$ORIGIN 0.0.6.2.3.3.5.2.0.2.1.e164.arpa. IN NAPTR 100 10 "u" "E2U+sip" "!^.*$!sip:user@example.com!" . IN NAPTR 100 20 "u" "E2U+mailto" "!^.*$!mailto:info@example.com!" .
$ORIGIN 0.0.6.2.3.3.5.2.0.2.1.e164.arpa。在NAPTR 100 10“u”E2U+sip“！^.*$！sip中：user@example.com!" . 在NAPTR 100 20“u”E2U+mailto“！^.*$！mailto中：info@example.com!" .
These guidelines do not by any means exhaustively describe the NAPTR algorithm or the processing of NAPTR records; implementers should familiarize themselves with the DDDS algorithm and ENUM before reviewing this section.
这些指南并未详尽描述NAPTR算法或NAPTR记录的处理；在回顾本节之前，实现者应该熟悉DDDS算法和ENUM。
Although in some cases, ENUM record sets will consist only a single 'E2U+sip' record, this section assumes that integrators of ENUM and SIP must be prepared for more complicated scenarios - however, just because we recommend that clients should be generous in what they receive, and try to make sense of potentially confusing NAPTR records, that does not mean that we recommend any of the potentially troublesome authoring practices that make this generosity necessary.
虽然在某些情况下，枚举记录集将只包含一个“E2U+sip”记录，但本节假设枚举和sip的集成商必须为更复杂的场景做好准备-然而，仅仅因为我们建议客户应慷慨对待他们收到的内容，并试着理解可能混淆的NAPTR记录，这并不意味着我们推荐任何可能带来麻烦的创作实践，使这种慷慨成为必要。
If an ENUM query returns multiple NAPTR records that have a service field of 'E2U+sip', or other service field that may be used by SIP (such as 'E2U+pres', see [17]) the ENUM client must first determine whether or not it should attempt to make use of multiple records or select a single one. The pitfalls of intentionally authoring ENUM record sets with multiple NAPTR records for SIP are detailed above in Section 4.
如果枚举查询返回多个NAPTR记录，这些记录的服务字段为“E2U+sip”，或sip可能使用的其他服务字段（如“E2U+pres”，请参见[17]），则枚举客户端必须首先确定是否应尝试使用多个记录或选择一个记录。上文第4节详细介绍了有意使用多条NAPTR记录为SIP编写枚举记录集的陷阱。
If the ENUM client is a user agent, then at some point a single NAPTR record must be selected to serve as the Request-URI of the desired SIP request. If the given NAPTR records have different preferences, the most preferred record SHOULD be used. If two or more records
如果ENUM客户端是一个用户代理，那么在某个时候，必须选择一条NAPTR记录作为所需SIP请求的请求URI。如果给定的NAPTR记录具有不同的首选项，则应使用最首选的记录。如果有两个或多个记录
share most preferred status, the ENUM client SHOULD randomly determine which record will be used, though it MAY defer to a local policy that employs some other means to select a record.
共享最首选状态时，枚举客户端应随机确定将使用哪个记录，尽管它可能会遵从使用其他方法选择记录的本地策略。
If the ENUM client is a SIP intermediary that can act a redirect server, then it SHOULD return a 3xx response with more than one Contact header field corresponding to the multiple selected NAPTR records in an ENUM record set. If the NAPTR records have different preferences, then 'q' values may be used in the Contact header fields to correspond to these preferences. Alternatively, the redirect server MAY select a single record in accordance with the NAPTR preference fields (or randomly when no preference is specified) and send this resulting URI in a Contact header field in a 3xx response.
如果枚举客户端是可以充当重定向服务器的SIP中介，则它应返回3xx响应，其中包含多个联系人标头字段，对应于枚举记录集中的多个选定NAPTR记录。如果NAPTR记录具有不同的首选项，则可在联系人标题字段中使用“q”值来对应这些首选项。或者，重定向服务器可以根据NAPTR首选项字段选择单个记录（或者在未指定首选项时随机选择），并在3xx响应中在联系人标头字段中发送该结果URI。
Otherwise, if the ENUM client is a SIP intermediary that can act as a proxy server, then it MAY fork the request when it receives multiple appropriate NAPTR records in an ENUM record set. Depending on the relative precedence values of the NAPTR records the proxy may wish to fork sequentially or in parallel. However, the proxy MUST build a route set from these NAPTR records that consists exclusively of SIP or SIPS URIs, not other URI schemes. Alternatively, the proxy server MAY select a single record in accordance with the NAPTR preference fields (or randomly when no preference is specified, or in accordance with local policy) and proxy the request with a Request-URI corresponding to the URI field of this NAPTR record - though again, it MUST select a record that contains a SIP or SIPS URI. Note that there are significant limitations that arise if a proxy server processes ENUM record sets instead of a user agent, and that therefore it is RECOMMENDED that SIP network elements act as redirect servers rather than proxy servers after performing an ENUM query.
否则，如果ENUM客户端是可以充当代理服务器的SIP中介，则当它在ENUM记录集中接收多个适当的NAPTR记录时，可能会分叉请求。根据NAPTR记录的相对优先级值，代理可能希望按顺序或并行分叉。但是，代理必须从这些NAPTR记录构建路由集，该路由集只包含SIP或SIPS URI，而不是其他URI方案。或者，代理服务器可以根据NAPTR首选项字段选择单个记录（或者在未指定首选项时随机选择，或者根据本地策略），并使用与此NAPTR记录的URI字段相对应的请求URI代理请求-尽管如此，它必须选择包含SIP或SIPS URI的记录。请注意，如果代理服务器处理枚举记录集而不是用户代理，则会出现明显的限制，因此建议SIP网元在执行枚举查询后充当重定向服务器而不是代理服务器。
Obviously, when an appropriate NAPTR record has been selected, the URI should be extracted from the regexp field. The URI is between the second and third exclamation points in the string. Once a URI has been extracted from the NAPTR record, it SHOULD be used as the Request-URI of the SIP request for which the ENUM query was launched.
显然，当选择了适当的NAPTR记录时，应该从regexp字段中提取URI。URI位于字符串中第二个和第三个感叹号之间。从NAPTR记录中提取URI后，应将其用作启动枚举查询的SIP请求的请求URI。
SIP clients should perform some sanity checks on the URI, primarily to ensure that they support the scheme of the URI, but also to verify that the URI is well-formed. Clients MUST at least verify that the Request-URI does not target themselves.
SIP客户端应该对URI执行一些健全性检查，主要是为了确保它们支持URI的方案，但也为了验证URI的格式是否正确。客户机必须至少验证请求URI不是以自己为目标的。
Once an address-of-record has been extracted from the selected NAPTR record, clients follow the standard SIP mechanisms (see [14]) for determining how to forward the request. This may involve launching subsequent NAPTR or SRV queries in order to determine how best to
一旦从选定的NAPTR记录中提取了记录地址，客户端将遵循标准SIP机制（参见[14]）来确定如何转发请求。这可能涉及启动后续NAPTR或SRV查询，以确定如何最好地
route to the domain identified by an address-of-record; clients however MUST NOT make the same ENUM query recursively (if the URI returned by ENUM is or contains a tel URL, see [8]).
路由到由记录地址标识的域；但是，客户端不能递归地进行相同的枚举查询（如果枚举返回的URI是或包含tel URL，请参见[8]）。
Note that SIP requests based on the use of NAPTR records may fail for any number of reasons. If there are multiple NAPTR records relevant to SIP present in an ENUM record set, then after a failure has occurred on an initial attempt with one NAPTR record, SIP user agents MAY try their request again with a different NAPTR record from the ENUM record set.
请注意，基于NAPTR记录使用的SIP请求可能会因多种原因而失败。如果枚举记录集中存在多个与SIP相关的NAPTR记录，则在初始尝试使用一个NAPTR记录失败后，SIP用户代理可以使用枚举记录集中不同的NAPTR记录再次尝试其请求。
The ENUM specification is currently undergoing a revision in the ENUM WG. The new specification, RFC 3761 [1], is based on the Dynamic Delegation Discovery System [5] revision to the NAPTR resource record specified in RFC 2915 [12]. For the most part, DDDS is an organizational revision that makes the algorithmic aspects of record processing separable from any underlying database format (such as the NAPTR DNS resource record).
枚举规范目前正在枚举工作组中进行修订。新规范RFC 3761[1]基于RFC 2915[12]中指定的NAPTR资源记录的动态委托发现系统[5]修订版。在很大程度上，DDDS是一种组织修订，它使记录处理的算法方面与任何底层数据库格式（如NAPTR DNS资源记录）分离。
The most important revision in RFC 3761 is the concept of enumservices. The original ENUM specification, RFC 2916, specified a number of "service" values that could be used for ENUM, including the "sip+E2U" service field. RFC 3761 introduces an IANA registration system with new guidelines for the registration of enumservices, which are no longer necessarily divided into discreet "service" and "protocol" fields, and which admit of more complex structures. In order to differentiate enumservices in RFC 3761 from those in RFC 2916, the string "E2U" is the leading element in an enumservice field, whereas by RFC 2916 it was the trailing element.
RFC3761中最重要的修订是enumservices的概念。原始的ENUM规范RFC 2916指定了许多可用于ENUM的“服务”值，包括“sip+E2U”服务字段。RFC 3761引入了IANA注册系统，其中包含注册enumservices的新指南，这些服务不再需要划分为谨慎的“服务”和“协议”字段，并且允许更复杂的结构。为了区分RFC 3761中的enumservices与RFC 2916中的enumservices，字符串“E2U”是enumservice字段中的前导元素，而RFC 2916则是尾随元素。
An enumservice for SIP addresses-of-record is described in [7]. This enumservice uses the enumservice field "E2U+sip". RFC 3761-compliant authors of ENUM records for SIP MUST therefore use the "E2U+sip" enumservice field instead of the "sip+E2U" field. For backwards compatibility with existing legacy records, however, the 'sip+E2U' field SHOULD be supported by an ENUM client that support SIP.
[7]中描述了记录的SIP地址的枚举服务。此enumservice使用enumservice字段“E2U+sip”。因此，符合RFC 3761的SIP枚举记录作者必须使用“E2U+SIP”枚举服务字段，而不是“SIP+E2U”字段。但是，为了与现有遗留记录向后兼容，“sip+E2U”字段应由支持sip的枚举客户端支持。
Also note that the terminology of DDDS differs in a number of respects from the initial NAPTR terminology in RFC 2916. DDDS introduces the concept of an Application, an Application Specific String, a First Well Known Rule, and so on. The terminology used in this document is a little looser (it refers to a 'starting string', for example, where 'Application Specific String' would be used for DDDS). The new terminology is reflected in RFC 3761.
还请注意，DDDS的术语在许多方面与RFC 2916中最初的NAPTR术语不同。DDDS引入了应用程序的概念、特定于应用程序的字符串、第一条众所周知的规则等。本文档中使用的术语有点松散（它指的是“起始字符串”，例如，“特定于应用程序的字符串”将用于DDD）。新术语反映在RFC 3761中。
DNS does not make policy decisions about the records that it shares with an inquirer. All DNS records must be assumed to be available to all inquirers at all times. The information provided within an ENUM record set must therefore be considered to be open to the public - which is a cause for some privacy considerations.
DNS不会对其与查询者共享的记录做出策略决定。必须假设所有DNS记录在任何时候都可供所有查询者使用。因此，必须将枚举记录集中提供的信息视为对公众开放，这是出于某些隐私考虑的原因。
Ordinarily, when you give someone your telephone number, you don't expect that they will be able to trivially determine your full name and place of employment. If, however, you create a NAPTR record for use with ENUM that maps your telephone number to a SIP URI like 'julia.roberts@example.com', expect to get a lot of calls from excited fans.
通常，当你给某人你的电话号码时，你不会期望他们能够琐碎地确定你的全名和工作地点。但是，如果您创建了一个NAPTR记录，用于将电话号码映射到SIPURI（如“julia”）的ENUM。roberts@example.com’，预计会接到很多兴奋的粉丝的电话。
Unlike a traditional telephone number, the target of a SIP URI may require that callers provide cryptographic credentials for authentication and authorization before a user is alerted. In this respect, ENUM in concert with SIP can actually provide far greater protection from unwanted callers than the existing PSTN, despite the public availability of ENUM records.
与传统电话号码不同，SIPURI的目标可能要求呼叫者在向用户发出警报之前提供用于身份验证和授权的加密凭据。在这方面，尽管ENUM记录可以公开使用，但与SIP配合使用的ENUM实际上可以提供比现有PSTN更大的保护，以防止不需要的呼叫者。
Users of ENUM who are nevertheless uncomfortable with revealing their names may, since identities on the Internet are not exactly at a premium, publish a less revealing SIP URI, like 'sip:anonymous00045@example.com' or even 'sip:anonymous00045@anonymous-redirector.example.org', which could in turn point to their internal URI.
尽管如此，由于互联网上的身份并不十分昂贵，对透露姓名感到不舒服的ENUM用户可能会发布一个不太透露姓名的SIP URI，如“SIP:anonymous00045@example.com“甚至”啜饮：anonymous00045@anonymous-org”，它可以反过来指向它们的内部URI。
An analysis of threats specific to the dependence of ENUM on the DNS, and the applicability of DNSSEC [18] to these, is provided in [1].
[1]中提供了对ENUM依赖DNS的特定威胁的分析，以及DNSSEC[18]对这些威胁的适用性。
[1] Faltstrom, P. and M. Mealling, "E.164 to Uniform Resource Identifiers (URI) Dynamic Delegation Discovery System (DDDS) Application (ENUM)", RFC 3761, April 2004.
[1] Faltstrom，P.和M.Mealling，“E.164到统一资源标识符（URI）动态委托发现系统（DDDS）应用程序（ENUM）”，RFC 3761，2004年4月。
[2] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, May 2002.
[2] Rosenberg，J.，Schulzrinne，H.，Camarillo，G.，Johnston，A.，Peterson，J.，Sparks，R.，Handley，M.，和E.Schooler，“SIP：会话启动协议”，RFC 3261，2002年5月。
[3] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[3] Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[4] Mockapetris, P., "Domain Names - Concepts and Facilities", STD13, RFC 1034, November 1987.
[4] Mockapetris，P.，“域名-概念和设施”，STD13，RFC1034，1987年11月。
[5] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part One: The Comprehensive DDDS", RFC 3401, October 2002.
[5] Mealling，M，“动态委托发现系统（DDDS）第一部分：综合DDDS”，RFC 3401，2002年10月。
[6] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part Three: The Domain Name System (DNS) Database", RFC 3403, October 2002.
[6] Mealling，M.“动态委托发现系统（DDDS）第三部分：域名系统（DNS）数据库”，RFC3403，2002年10月。
[7] Peterson, J., "enumservice registration for SIP Addresses-of-Record", RFC 3764, April 2004.
[7] Peterson，J.，“记录的SIP地址的enumservice注册”，RFC 3764，2004年4月。
[8] Vaha-Sipila, A., "URLs for Telephone Calls", RFC 2806, April 2000.
[8] Vaha Sipila，A.，“电话呼叫的URL”，RFC 2806，2000年4月。
[9] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1998.
[9] Berners Lee，T.，Fielding，R.，和L.Masinter，“统一资源标识符（URI）：通用语法”，RFC 2396，1998年8月。
[10] International Telecommunications Union, "Recommendation E.164: The international public telecommunication numbering plan", May 1997, <http://www.itu.int>.
[10] 国际电信联盟，“建议E.164：国际公共电信编号计划”，1997年5月<http://www.itu.int>.
[11] Rosenberg, J., Schulzrinne, H. and P. Kyzviat, "Indicating User Agent Capabilities in the Session Initiation Protocol (SIP)", Work in Progress, June 2003.
[11] Rosenberg，J.，Schulzrinne，H.和P.Kyzviat，“指出会话启动协议（SIP）中的用户代理功能”，正在进行的工作，2003年6月。
[12] Mealling, M. and R. Daniel, "The Naming Authority Pointer (NAPTR) DNS Resource Record", RFC 2915, September 2000.
[12] Mealling，M.和R.Daniel，“命名机构指针（NAPTR）DNS资源记录”，RFC 2915，2000年9月。
[13] Handley, M. and V. Jacobson, "SDP: Session Description Protocol", RFC 2327, April 1998.
[13] Handley，M.和V.Jacobson，“SDP：会话描述协议”，RFC 2327，1998年4月。
[14] Rosenberg, J. and H. Schulzrinne, "Session Initiation Protocol: Locating SIP Servers", RFC 3263, June 2002.
[14] Rosenberg，J.和H.Schulzrinne，“会话启动协议：定位SIP服务器”，RFC3263，2002年6月。
[15] Rosenberg, J., Squire, M., and H. Salama, "Telephony Routing over IP (TRIP)", RFC 3219, August 2001.
[15] Rosenberg，J.，Squire，M.，和H.Salama，“IP电话路由（TRIP）”，RFC 3219，2001年8月。
[16] Faltstrom, P., "E.164 number and DNS", RFC 2916, September 2000.
[16] Faltstrom，P.，“E.164号码和域名系统”，RFC 29162000年9月。
[17] Peterson, J., "Enumservice Registration for Presence Services", Work in Progress, February 2003.
[17] Peterson，J.，“在线服务的Enumservice注册”，正在进行的工作，2003年2月。
[18] Arends, R., et al., "Protocol Modifications for the DNS Security Extensions", Work in Progress, May 2004.
[18] Arends，R.等人，“DNS安全扩展的协议修改”，正在进行的工作，2004年5月。
The authors would like to thank Richard Shockey for his input on privacy issues, and Tom McGarry and Rohan Mahy for overall comments and analysis. Thanks are due as well to Juan Heinanen and Lawrence E. Conroy for advice on updating this document to better reflect RFC 3761. Special thanks are given to Patrik Faltstrom and Michael Mealling for significantly reducing the size of this document by producing a tight and well-specified successor to RFC 2916. Richard Stastny and Patrik Faltstrom also provided valuable notes on the valid usage of non-greedy regexp antecedents.
作者要感谢Richard Shockey在隐私问题上的贡献，感谢Tom McGarry和Rohan Mahy的全面评论和分析。感谢Juan Heinanen和Lawrence E.Conroy就更新本文件提供建议，以更好地反映RFC 3761。特别感谢Patrik Faltstrom和Michael Melling通过制作RFC 2916的紧凑且明确的后续版本，大大缩小了本文件的规模。Richard Stastny和Patrik Faltstrom还就非贪婪regexp先行项的有效使用提供了有价值的说明。
Authors' Addresses
作者地址
Jon Peterson NeuStar, Inc. 1800 Sutter St Suite 570 Concord, CA 94520 USA
美国加利福尼亚州康科德市萨特街1800号570室Jon Peterson NeuStar，Inc.94520
Phone: +1 925/363-8720
EMail: jon.peterson@neustar.biz
URI: http://www.neustar.biz/
Phone: +1 925/363-8720
EMail: jon.peterson@neustar.biz
URI: http://www.neustar.biz/
Hong Liu NeuStar, Inc. 46000 Center Oak Plaza Sterling, VA 20166 USA
Hong Liu NeuStar，Inc.美国弗吉尼亚州斯特林中心橡木广场46000号，邮编20166
EMail: hong.liu@neustar.biz
URI: http://www.neustar.biz/
EMail: hong.liu@neustar.biz
URI: http://www.neustar.biz/
James Yu NeuStar, Inc. 46000 Center Oak Plaza Sterling, VA 20166 USA
James Yu NeuStar，Inc.美国弗吉尼亚州斯特林中心橡木广场46000号，邮编20166
Phone: +1 571/434-5572
EMail: james.yu@neustar.biz
URI: http://www.neustar.biz/
Phone: +1 571/434-5572
EMail: james.yu@neustar.biz
URI: http://www.neustar.biz/
Ben Campbell dynamicsoft 5100 Tennyson Parkway Suite 1200 Plano, TX 75024 USA
美国德克萨斯州普莱诺市坦尼森大道1200号Ben Campbell dynamicsoft 5100套房，邮编75024
EMail: bcampbell@dynamicsoft.com
URI: http://www.dynamicsoft.com/
EMail: bcampbell@dynamicsoft.com
URI: http://www.dynamicsoft.com/
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2004). 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.
版权所有（C）互联网协会（2004年）。本文件受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 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.
本文件及其包含的信息是按“原样”提供的，贡献者、他/她所代表或赞助的组织（如有）、互联网协会和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
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.
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。