Network Working Group L. Daigle
Request for Comments: 4848 Cisco Systems
Category: Standards Track April 2007
Network Working Group L. Daigle
Request for Comments: 4848 Cisco Systems
Category: Standards Track April 2007
Domain-Based Application Service Location Using URIs and the Dynamic Delegation Discovery Service (DDDS)
使用URI和动态委派发现服务（DDDS）的基于域的应用程序服务位置
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）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The IETF Trust (2007).
版权所有（C）IETF信托基金（2007年）。
Abstract
摘要
The purpose of this document is to define a new, straightforward Dynamic Delegation Discovery Service (DDDS) application to allow mapping of domain names to URIs for particular application services and protocols. Although defined as a new DDDS application, dubbed U-NAPTR, this is effectively an extension of the Straightforward NAPTR (S-NAPTR) DDDS Application.
本文档的目的是定义一个新的、简单的动态委托发现服务（DDDS）应用程序，以允许将域名映射到特定应用程序服务和协议的URI。尽管定义为一个新的DDDS应用程序，称为U-NAPTR，但它实际上是简单的NAPTR（S-NAPTR）DDDS应用程序的扩展。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Straightforward URI-Enabled NAPTR (U-NAPTR) . . . . . . . . . . 3
2.1. Permitted Flags . . . . . . . . . . . . . . . . . . . . . . 3
2.2. Permitted Regular Expressions . . . . . . . . . . . . . . . 4
3. Sample U-NAPTR DNS Records . . . . . . . . . . . . . . . . . . 4
4. Formal Definition of U-NAPTR Application of DDDS . . . . . . . 5
4.1. Application Unique String . . . . . . . . . . . . . . . . . 5
4.2. First Well Known Rule . . . . . . . . . . . . . . . . . . . 5
4.3. Expected Output . . . . . . . . . . . . . . . . . . . . . . 5
4.4. Flags . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
4.5. Service Parameters . . . . . . . . . . . . . . . . . . . . 5
4.5.1. Application Services . . . . . . . . . . . . . . . . . 6
4.5.2. Application Protocols . . . . . . . . . . . . . . . . . 6
4.6. Valid Rules . . . . . . . . . . . . . . . . . . . . . . . . 6
4.7. Valid Databases . . . . . . . . . . . . . . . . . . . . . . 7
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7
6. Security Considerations . . . . . . . . . . . . . . . . . . . . 8
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8
8.1. Normative References . . . . . . . . . . . . . . . . . . . 8
8.2. Informative References . . . . . . . . . . . . . . . . . . 9
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Straightforward URI-Enabled NAPTR (U-NAPTR) . . . . . . . . . . 3
2.1. Permitted Flags . . . . . . . . . . . . . . . . . . . . . . 3
2.2. Permitted Regular Expressions . . . . . . . . . . . . . . . 4
3. Sample U-NAPTR DNS Records . . . . . . . . . . . . . . . . . . 4
4. Formal Definition of U-NAPTR Application of DDDS . . . . . . . 5
4.1. Application Unique String . . . . . . . . . . . . . . . . . 5
4.2. First Well Known Rule . . . . . . . . . . . . . . . . . . . 5
4.3. Expected Output . . . . . . . . . . . . . . . . . . . . . . 5
4.4. Flags . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
4.5. Service Parameters . . . . . . . . . . . . . . . . . . . . 5
4.5.1. Application Services . . . . . . . . . . . . . . . . . 6
4.5.2. Application Protocols . . . . . . . . . . . . . . . . . 6
4.6. Valid Rules . . . . . . . . . . . . . . . . . . . . . . . . 6
4.7. Valid Databases . . . . . . . . . . . . . . . . . . . . . . 7
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7
6. Security Considerations . . . . . . . . . . . . . . . . . . . . 8
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8
8.1. Normative References . . . . . . . . . . . . . . . . . . . 8
8.2. Informative References . . . . . . . . . . . . . . . . . . 9
The purpose of this document is to define a new, straightforward Dynamic Delegation Discovery Service (DDDS) [7] application to allow mapping of domain names to URIs for particular application services and protocols. This allows the "lookup" of particular services available for given domains, for example.
本文档的目的是定义一个新的、直观的动态委托发现服务（DDDS）[7]应用程序，以允许将域名映射到特定应用程序服务和协议的URI。例如，这允许“查找”给定域可用的特定服务。
Although this is defining a new and separate DDDS Application, dubbed U-NAPTR, it is built from the same principles as the Straightforward NAPTR (S-NAPTR) application, specified in [2]. This specification is not an update of S-NAPTR, but the reader is encouraged to review that document for extensive coverage of motivation and implementation considerations.
尽管这定义了一个新的、独立的DDDS应用程序，称为U-NAPTR，但其构建原理与[2]中规定的简单的NAPTR（S-NAPTR）应用程序相同。本规范不是S-NAPTR的更新，但鼓励读者阅读该文件，了解动机和实施注意事项的广泛内容。
S-NAPTR provides for application service location that does not rely on rigid domain naming conventions. It is deemed "straightforward" in part because it rules out the use of regular expressions in NAPTR records (for the S-NAPTR DDDS Application). However, that also rules out the possibility of providing a URI as the target of DDDS resolution. A number of applications, specified (e.g., [9]) and proposed, find the restriction too limiting, making S-NAPTR a near miss to suit their needs.
S-NAPTR提供的应用程序服务位置不依赖于严格的域命名约定。它被认为是“直接的”，部分原因是它排除了在NAPTR记录中使用正则表达式（对于S-NAPTR DDDS应用程序）。然而，这也排除了提供URI作为DDDS解析目标的可能性。许多指定（如[9]）和提议的应用发现限制太过有限，使得S-NAPTR几乎无法满足其需求。
This U-NAPTR is effectively a modest extension to S-NAPTR, to accommodate the use of URIs as targets, without allowing the full range of possible regular expressions in NAPTR records.
此U-NAPTR实际上是S-NAPTR的适度扩展，以适应URI作为目标的使用，而不允许在NAPTR记录中使用所有可能的正则表达式。
This document assumes the reader is familiar with the S-NAPTR specification [2]. The intention of U-NAPTR is to provide everything that S-NAPTR does, except that it allows the use of the "U" flag in the NAPTR record, and a specific form of REGEXP.
本文档假设读者熟悉S-NAPTR规范[2]。U-NAPTR的目的是提供S-NAPTR所做的一切，除了它允许在NAPTR记录中使用“U”标志和特定形式的REGEXP。
U-NAPTR permits the same flags as S-NAPTR ("S", "A", or empty), plus the "U" Flag. For the U-NAPTR DDDS Application, the presence of the "U" Flag in the NAPTR record indicates the REGEXP field must be populated (and, consequently, the REPLACEMENT field is empty). The regular expression in the REGEXP field must be of the limited form described below, and the result of the regular expression evaluation will be a URI that is the result of the DDDS resolution.
U-NAPTR允许与S-NAPTR相同的标志（“S”、“A”或“空”），加上“U”标志。对于U-NAPTR DDDS应用程序，NAPTR记录中的“U”标志表示必须填充REGEXP字段（因此，替换字段为空）。REGEXP字段中的正则表达式必须是下面描述的受限形式，并且正则表达式计算的结果将是一个URI，该URI是DDDS解析的结果。
U-NAPTR permits regular expressions of a form that does a complete replacement of the matched string with a URI, expressed as a constant string. This is essentially a dodge around the fact that the REPLACEMENT field in NAPTR is required to produce only a fully qualified domain name (and, therefore, cannot be used for a URI).
U-NAPTR允许表单的正则表达式使用URI（表示为常量字符串）完全替换匹配的字符串。这本质上是对NAPTR中的替换字段只需要生成完全限定的域名（因此不能用于URI）这一事实的回避。
The specific allowed syntax for U-NAPTR regular expressions is:
U-NAPTR正则表达式允许的特定语法为：
u-naptr-regexp = "!.*!"<URI>"!"
u-naptr-regexp = "!.*!"<URI>"!"
where <URI> is as defined in STD 66 [8], the URI syntax specification.
其中<URI>如STD 66[8]中所定义，URI语法规范。
With this limited form of regular expression, applications using U-NAPTR need not implement full regular expression parsers.
使用这种有限形式的正则表达式，使用U-NAPTR的应用程序不需要实现完整的正则表达式解析器。
In the sample NAPTR RRs for example.com shown below, "WP" is the imagined application service tag for "white pages", and "EM" is the application service tag for an imagined "Extensible Messaging" application service.
在下面显示的示例NAPTR RRs for example.com中，“WP”是“白页”的虚拟应用程序服务标签，“EM”是虚拟“可扩展消息传递”应用程序服务的应用程序服务标签。
example.com.
;; order pref flags
IN NAPTR 100 10 "" "WP:whois++" ( ; service
"" ; regexp
bunyip.example.com. ; replacement
)
IN NAPTR 100 20 "s" "WP:ldap" ( ; service
"" ; regexp
_ldap._tcp.myldap.example.com. ; replacement
)
IN NAPTR 200 10 "u" "EM:protA" ( ; service
"!.*!prota://someisp.example.com!" ; regexp
"" ; replacement
)
IN NAPTR 200 30 "a" "EM:protB" ; service
"" ; regexp
myprotB.example.com.; replacement
)
example.com.
;; order pref flags
IN NAPTR 100 10 "" "WP:whois++" ( ; service
"" ; regexp
bunyip.example.com. ; replacement
)
IN NAPTR 100 20 "s" "WP:ldap" ( ; service
"" ; regexp
_ldap._tcp.myldap.example.com. ; replacement
)
IN NAPTR 200 10 "u" "EM:protA" ( ; service
"!.*!prota://someisp.example.com!" ; regexp
"" ; replacement
)
IN NAPTR 200 30 "a" "EM:protB" ; service
"" ; regexp
myprotB.example.com.; replacement
)
This section formally defines the DDDS Application, as described in [7].
本节正式定义了DDDS应用程序，如[7]所述。
The Application Unique String is a fully qualified domain name (FQDN) for which an authoritative server for a particular service is sought.
应用程序唯一字符串是一个完全限定的域名（FQDN），为其寻找特定服务的权威服务器。
The "First Well Known Rule" is identity -- that is, the output of the rule is the Application Unique String, the FQDN for which the authoritative server for a particular service is sought.
“第一条众所周知的规则”是identity——也就是说，规则的输出是应用程序唯一字符串，即为其寻找特定服务的权威服务器的FQDN。
The expected output of this Application is the information necessary to connect to authoritative server(s) (host, port, protocol, or URI) for an application service within a given domain.
此应用程序的预期输出是连接到给定域内应用程序服务的权威服务器（主机、端口、协议或URI）所需的信息。
This DDDS Application uses only 3 of the Flags defined for the URI/ URN Resolution Application [5]: "S", "A", and "U". No other Flags are valid. If a client obtains a NAPTR RR for a U-NAPTR-using application that contains any other flag, that NAPTR RR should be ignored and processing continues with the next record (if any).
此DDDS应用程序仅使用为URI/URN解析应用程序定义的3个标志[5]：“S”、“A”和“U”。没有其他有效标志。如果客户端为使用U-NAPTR的应用程序获取包含任何其他标志的NAPTR RR，则应忽略该NAPTR RR，并继续处理下一条记录（如果有）。
These flags are for terminal lookups. This means that the Rule is the last one and that the flag determines what the next stage should be. The "S" flag means that the output of this Rule is a FQDN for which one or more SRV [3] records exist. "A" means that the output of the Rule is a domain name and should be used to lookup address records for that domain. "U" means that the output of the Rule is a URI that should be resolved in order to obtain access to the described service.
这些标志用于终端查找。这意味着规则是最后一个，标志决定下一个阶段应该是什么。“S”标志表示此规则的输出是存在一个或多个SRV[3]记录的FQDN。“A”表示规则的输出是域名，应用于查找该域的地址记录。“U”表示规则的输出是一个URI，为了获得对所描述服务的访问权，应该解析该URI。
Consistent with the DDDS algorithm, if the Flag string is empty the next lookup is for another NAPTR record (for the replacement target).
与DDDS算法一致，如果标志字符串为空，则下一次查找是另一条NAPTR记录（用于替换目标）。
Service Parameters for this Application take the form of a string of characters that follow this ABNF [1]:
此应用程序的服务参数采用以下ABNF[1]后面的字符串形式：
service-parms = [ [app-service] *(":" app-protocol)]
app-service = experimental-service / iana-registered-service
app-protocol = experimental-protocol / iana-registered-protocol
experimental-service = "x-" 1*30ALPHANUMSYM
experimental-protocol = "x-" 1*30ALPHANUMSYM
iana-registered-service = ALPHA *31ALPHANUMSYM
iana-registered-protocol = ALPHA *31ALPHANUMSYM
ALPHA = %x41-5A / %x61-7A ; A-Z / a-z
DIGIT = %x30-39 ; 0-9
SYM = %x2B / %x2D / %x2E ; "+" / "-" / "."
ALPHANUMSYM = ALPHA / DIGIT / SYM
; The app-service and app-protocol tags are limited to 32
; characters and must start with an alphabetic character.
; The service-parms are considered case-insensitive.
service-parms = [ [app-service] *(":" app-protocol)]
app-service = experimental-service / iana-registered-service
app-protocol = experimental-protocol / iana-registered-protocol
experimental-service = "x-" 1*30ALPHANUMSYM
experimental-protocol = "x-" 1*30ALPHANUMSYM
iana-registered-service = ALPHA *31ALPHANUMSYM
iana-registered-protocol = ALPHA *31ALPHANUMSYM
ALPHA = %x41-5A / %x61-7A ; A-Z / a-z
DIGIT = %x30-39 ; 0-9
SYM = %x2B / %x2D / %x2E ; "+" / "-" / "."
ALPHANUMSYM = ALPHA / DIGIT / SYM
; The app-service and app-protocol tags are limited to 32
; characters and must start with an alphabetic character.
; The service-parms are considered case-insensitive.
Thus, the Service Parameters may consist of an empty string, just an app-service, or an app-service with one or more app-protocol specifications separated by the ":" symbol.
因此，服务参数可以由空字符串、仅一个应用程序服务或一个或多个应用程序协议规范由“：”符号分隔的应用程序服务组成。
Note that this is similar to, but not the same as the syntax used in the URI DDDS application [5]. The DDDS DNS database requires each DDDS application to define the syntax of allowable service strings. The syntax here is expanded to allow the characters that are valid in any URI scheme name (see [8]). Since "+" (the separator used in the RFC3404 service parameter string) is an allowed character for URI scheme names, ":" is chosen as the separator here.
请注意，这与URI DDDS应用程序[5]中使用的语法相似，但不相同。DDDS DNS数据库要求每个DDDS应用程序定义允许的服务字符串的语法。此处的语法已扩展，允许在任何URI方案名称中使用有效字符（请参见[8]）。由于“+”（RFC3404服务参数字符串中使用的分隔符）是URI方案名称允许使用的字符，因此此处选择“：”作为分隔符。
The "app-service" must be an IANA-registered service; see Section 5 for instructions on registering new application service tags.
“应用程序服务”必须是IANA注册的服务；有关注册新应用程序服务标签的说明，请参见第5节。
The protocol identifiers that are valid for the "app-protocol" production are standard, registered protocols; see Section 5 for instructions on registering new application protocol tags.
对“应用程序协议”生产有效的协议标识符是标准的、注册的协议；有关注册新应用程序协议标记的说明，请参见第5节。
Permitted rules are substitution rules and regular expressions of the following syntax (i.e., a regular expression to replace the domain name with a URI):
允许的规则是以下语法的替换规则和正则表达式（即用URI替换域名的正则表达式）：
u-naptr-regexp = "!.*!"<URI>"!"
u-naptr-regexp = "!.*!"<URI>"!"
where <URI> is as defined in STD 66 [8], the URI syntax specification.
其中<URI>如STD 66[8]中所定义，URI语法规范。
At present, only one DDDS Database is specified for this Application. [4] specifies a DDDS Database that uses the NAPTR DNS resource record to contain the rewrite rules. The Keys for this database are encoded as domain names.
目前，仅为此应用程序指定了一个DDDS数据库。[4] 指定使用NAPTR DNS资源记录包含重写规则的DDDS数据库。此数据库的密钥编码为域名。
The First Well Known Rule produces a domain name, and this is the Key that is used for the first lookup -- the NAPTR records for that domain are requested.
第一条众所周知的规则生成一个域名，这是用于第一次查找的密钥——请求该域的NAPTR记录。
DNS servers MAY interpret Flag values and use that information to include appropriate NAPTR, SRV, or A records in the Additional Information portion of the DNS packet. Clients are encouraged to check for additional information but are not required to do so. See the Additional Information Processing section of [4] for more information on NAPTR records and the Additional Information section of a DNS response packet.
DNS服务器可以解释标志值并使用该信息在DNS分组的附加信息部分中包括适当的NAPTR、SRV或A记录。鼓励客户查看更多信息，但不要求客户查看。有关NAPTR记录和DNS响应数据包的附加信息部分的更多信息，请参阅[4]的附加信息处理部分。
This document does not itself place any requirements on IANA, but provides the basis upon which U-NAPTR-using services can make use of the existing IANA registries for application service tags and application protocol tags (defined in RFC 3958 [2]).
本文件本身并未对IANA提出任何要求，但提供了使用U-NAPTR的服务可以利用现有IANA注册中心进行应用服务标签和应用协议标签（定义见RFC 3958[2]）的基础。
As is the case for S-NAPTR, all application service and protocol tags that start with "x-" are considered experimental, and no provision is made to prevent duplicate use of the same string. Use them at your own risk.
与S-NAPTR的情况一样，所有以“x-”开头的应用程序服务和协议标记都被认为是实验性的，并且没有防止重复使用同一字符串的规定。使用它们的风险自负。
All other application service and protocol tags are registered based on the "specification required" option defined in [6], with the further stipulation that the "specification" is an RFC (of any category).
所有其他应用服务和协议标签均根据[6]中定义的“所需规范”选项进行注册，并进一步规定“规范”为RFC（任何类别）。
There are no further restrictions placed on the tags other than that they must conform with the syntax defined above (Section 4.5).
除了标签必须符合上面定义的语法（第4.5节）之外，对标签没有其他限制。
The defining RFC must clearly identify and describe, for each tag being registered:
定义RFC必须清楚地识别和描述注册的每个标签：
o Application protocol or service tag
o 应用程序协议或服务标签
o Intended usage
o 预期用途
o Interoperability considerations
o 互操作性注意事项
o Security considerations (see Section 6 of this document for further discussion of the types of considerations that are applicable)
o 安全注意事项（有关适用注意事项类型的进一步讨论，请参阅本文件第6节）
o Any relevant related publications
o 任何相关出版物
The defining RFC may also include further application-specific restrictions, such as limitations on the types of URIs that may be returned for the application service.
定义RFC还可以包括进一步的特定于应用程序的限制，例如对可能为应用程序服务返回的uri类型的限制。
U-NAPTR has the same considerations for security as S-NAPTR; see Section 8 of [2]. U-NAPTR has the additional consideration that resolving URIs (from the result of the DDDS resolution) has its own set of security implications, covered in the URI specification (in particular, Section 7 of [8]). In essence, using DNSSEC, client software can be confident that the URI obtained using U-NAPTR is indeed the one specified by the administrator of the domain from which it was retrieved; but the validity of the service reached by resolving that URI is a matter of URI resolution security practices.
U-NAPTR的安全考虑与S-NAPTR相同；见[2]第8节。U-NAPTR还需要考虑的是，解析URI（根据DDDS解析的结果）有其自身的一组安全含义，这些安全含义包含在URI规范（特别是[8]的第7节）中。本质上，使用DNSSEC，客户端软件可以确信使用U-NAPTR获得的URI确实是从中检索到它的域的管理员指定的URI；但是通过解析该URI所达到的服务的有效性是URI解析安全实践的问题。
Thanks to Martin Thomson, John Klensin, Bernard Aboba, Alfred Hoenes, Dan Romascanu, Suresh Krishnan, and Lars Eggert for reviewing earlier versions and catching errors!
感谢Martin Thomson、John Klesins、Bernard Aboba、Alfred Hoenes、Dan Romascanu、Suresh Krishnan和Lars Eggert回顾早期版本并发现错误！
[1] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 4234, October 2005.
[1] Crocker，D.和P.Overell，“语法规范的扩充BNF:ABNF”，RFC 42342005年10月。
[2] Daigle, L. and A. Newton, "Domain-Based Application Service Location Using SRV RRs and the Dynamic Delegation Discovery Service (DDDS)", RFC 3958, January 2005.
[2] Daigle，L.和A.Newton，“使用SRV RRs和动态委托发现服务（DDDS）的基于域的应用程序服务定位”，RFC 3958，2005年1月。
[3] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for specifying the location of services (DNS SRV)", RFC 2782, February 2000.
[3] Gulbrandsen，A.，Vixie，P.和L.Esibov，“用于指定服务位置（DNS SRV）的DNS RR”，RFC 2782，2000年2月。
[4] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part Three: The Domain Name System (DNS) Database", RFC 3403, October 2002.
[4] Mealling，M.“动态委托发现系统（DDDS）第三部分：域名系统（DNS）数据库”，RFC3403，2002年10月。
[5] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part Four: The Uniform Resource Identifiers (URI)", RFC 3404, October 2002.
[5] Mealling，M.“动态委托发现系统（DDDS）第四部分：统一资源标识符（URI）”，RFC34042002年10月。
[6] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[6] Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 2434，1998年10月。
[7] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part One: The Comprehensive DDDS", RFC 3401, October 2002.
[7] Mealling，M，“动态委托发现系统（DDDS）第一部分：综合DDDS”，RFC 3401，2002年10月。
[8] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", RFC 3986, STD 66, January 2005.
[8] Berners Lee，T.，Fielding，R.，和L.Masinter，“统一资源标识符（URI）：通用语法”，RFC 3986，STD 66，2005年1月。
[9] Malamud, C., "Attaching Meaning to Solicitation Class Keywords", RFC 4095, May 2005.
[9] Malamud，C.，“对招标类关键词附加意义”，RFC 4095，2005年5月。
Author's Address
作者地址
Leslie L. Daigle Cisco Systems 13615 Dulles Technology Drive Herndon, VA 20171 US
美国弗吉尼亚州赫恩登市杜勒斯技术大道13615号莱斯利·L·戴格尔思科系统公司，邮编20171
EMail: ledaigle@cisco.com; leslie@thinkingcat.com
EMail: ledaigle@cisco.com; leslie@thinkingcat.com
Full Copyright Statement
完整版权声明
Copyright (C) The IETF Trust (2007).
版权所有（C）IETF信托基金（2007年）。
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.
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。