Network Working Group M. Mealling
Request for Comments: 3405 VeriSign
BCP: 65 October 2002
Category: Best Current Practice
Network Working Group M. Mealling
Request for Comments: 3405 VeriSign
BCP: 65 October 2002
Category: Best Current Practice
Dynamic Delegation Discovery System (DDDS) Part Five: URI.ARPA Assignment Procedures
动态委托发现系统（DDDS）第五部分：URI.ARPA分配过程
Status of this Memo
本备忘录的状况
This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Distribution of this memo is unlimited.
本文件规定了互联网社区的最佳现行做法，并要求进行讨论和提出改进建议。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2002). All Rights Reserved.
版权所有（C）互联网协会（2002年）。版权所有。
Abstract
摘要
This document is fifth in a series that is completely specified in "Dynamic Delegation Discovery System (DDDS) Part One: The Comprehensive DDDS" (RFC 3401). It is very important to note that it is impossible to read and understand any document in this series without reading the others.
本文档是“动态委托发现系统（DDDS）第一部分：综合DDDS”（RFC 3401）中完全指定的系列文档中的第五篇。需要注意的是，如果不阅读其他文档，就不可能阅读和理解本系列中的任何文档。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. URI Resolution vs URN Resolution . . . . . . . . . . . . . . 2
3. Registration Policies . . . . . . . . . . . . . . . . . . . 3
3.1 URI.ARPA Registration . . . . . . . . . . . . . . . . . . . 3
3.1.1 Only Schemes in the IETF Tree Allowed . . . . . . . . . . . 3
3.1.2 Scheme Registration Takes Precedence . . . . . . . . . . . . 3
3.1.3 NAPTR Registration May Accompany Scheme Registration . . . . 3
3.1.4 Registration or Changes after Scheme Registration . . . . . 3
3.2 URN.ARPA Registration . . . . . . . . . . . . . . . . . . . 4
3.2.1 NID Registration Takes Precedence . . . . . . . . . . . . . 4
3.2.2 NAPTR Registration May Accompany NID Registration . . . . . 4
3.2.3 Registration or Changes after Scheme Registration . . . . . 4
4. Requirements on hints . . . . . . . . . . . . . . . . . . . 4
5. Submission Procedure . . . . . . . . . . . . . . . . . . . . 5
6. Registration Template . . . . . . . . . . . . . . . . . . . 6
6.1 Key . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
6.2 Authority . . . . . . . . . . . . . . . . . . . . . . . . . 6
6.3 Records . . . . . . . . . . . . . . . . . . . . . . . . . . 6
7. Example Template . . . . . . . . . . . . . . . . . . . . . . 6
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. URI Resolution vs URN Resolution . . . . . . . . . . . . . . 2
3. Registration Policies . . . . . . . . . . . . . . . . . . . 3
3.1 URI.ARPA Registration . . . . . . . . . . . . . . . . . . . 3
3.1.1 Only Schemes in the IETF Tree Allowed . . . . . . . . . . . 3
3.1.2 Scheme Registration Takes Precedence . . . . . . . . . . . . 3
3.1.3 NAPTR Registration May Accompany Scheme Registration . . . . 3
3.1.4 Registration or Changes after Scheme Registration . . . . . 3
3.2 URN.ARPA Registration . . . . . . . . . . . . . . . . . . . 4
3.2.1 NID Registration Takes Precedence . . . . . . . . . . . . . 4
3.2.2 NAPTR Registration May Accompany NID Registration . . . . . 4
3.2.3 Registration or Changes after Scheme Registration . . . . . 4
4. Requirements on hints . . . . . . . . . . . . . . . . . . . 4
5. Submission Procedure . . . . . . . . . . . . . . . . . . . . 5
6. Registration Template . . . . . . . . . . . . . . . . . . . 6
6.1 Key . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
6.2 Authority . . . . . . . . . . . . . . . . . . . . . . . . . 6
6.3 Records . . . . . . . . . . . . . . . . . . . . . . . . . . 6
7. Example Template . . . . . . . . . . . . . . . . . . . . . . 6
8. The URN Registration in the URI.ARPA zone . . . . . . . . . 7
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . 7
10. Security Considerations . . . . . . . . . . . . . . . . . . 7
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
13. Author's Address . . . . . . . . . . . . . . . . . . . . . . 9
14. Full Copyright Statement . . . . . . . . . . . . . . . . . . 10
8. The URN Registration in the URI.ARPA zone . . . . . . . . . 7
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . 7
10. Security Considerations . . . . . . . . . . . . . . . . . . 7
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
13. Author's Address . . . . . . . . . . . . . . . . . . . . . . 9
14. Full Copyright Statement . . . . . . . . . . . . . . . . . . 10
This document defines the policies and procedures for inserting Naming Authority Pointer (NAPTR) records into the 'URI.ARPA' and 'URN.ARPA' zones for the purpose of resolving Uniform Resource Identifiers (URIs) according to "Dynamic Delegation Discovery System (DDDS) Part Four: The URI Resolution Application" (RFC 3402) [2], which is an Application that uses the Domain Name System (DNS) based DDDS Database. All of these concepts are defined in RFC 3401 [1]. It is very important to note that it is impossible to correctly understand this document without reading RFC 3401 and the documents it specifies.
本文件定义了根据“动态委托发现系统（DDDS）第四部分：URI解析应用程序”（RFC 3402）[2]将命名机构指针（NAPTR）记录插入“URI.ARPA”和“URN.ARPA”区域以解析统一资源标识符（URI）的策略和过程，这是一个使用基于域名系统（DNS）的DDDS数据库的应用程序。所有这些概念都在RFC 3401[1]中定义。必须注意的是，如果不阅读RFC 3401及其规定的文件，就不可能正确理解本文件。
RFC 3403 defines a how DNS is used as a DDDS database that contains URI delegation rules (sometimes called resolution hints). That document specifies that the first step in that algorithm is to append 'URI.ARPA' to the URI scheme and retrieve the NAPTR record for that domain-name. I.e., the first step in resolving "http://foo.com/" would be to look up a NAPTR record for the domain "http.URI.ARPA". URN resolution also follows a similar procedure but uses the 'URN.ARPA' zone as its root. This document describes the procedures for inserting a new rule into the 'URI.ARPA' and 'URN.ARPA' zones.
RFC 3403定义了如何将DNS用作包含URI委派规则（有时称为解析提示）的DDDS数据库。该文档指定该算法的第一步是将“URI.ARPA”附加到URI方案并检索该域名的NAPTR记录。即，解决问题的第一步”http://foo.com/将是查找域“http.URI.ARPA”的NAPTR记录。URN解析也遵循类似的过程，但使用“URN.ARPA”区域作为其根。本文档描述了将新规则插入“URI.ARPA”和“URN.ARPA”区域的过程。
RFC 3402 [2] defines how both URI [7] resolution and URN [6] resolution work when DNS is used as the delegation rule (or hint) database. Specifically it says that the initial instructions ('hints') for DNS-based resolution of URIs are stored as resource records in the 'URI.ARPA' DNS zone.
RFC 3402[2]定义了当DNS用作委托规则（或提示）数据库时，URI[7]解析和URN[6]解析的工作方式。具体地说，基于DNS解析URI的初始指令（“提示”）存储为“URI.ARPA”DNS区域中的资源记录。
Since a URN is a URI scheme, a hint for resolution of the URI prefix 'urn:' will also be stored in the 'URI.ARPA' zone. This rule states that the namespace id [6] is extracted, 'URN.ARPA' is appended to the end of the namespace id, and the result is used as the key for retrieval of a subsequent NAPTR record [4].
由于URN是一个URI方案，因此URI前缀“URN:”的解析提示也将存储在“URI.ARPA”区域中。该规则规定提取名称空间id[6]，并将“URN.ARPA”附加到名称空间id的末尾，结果用作检索后续NAPTR记录[4]的键。
The creation of a given URI scheme or URN namespace id (NID) follows the appropriate registration documents for those spaces. URI schemes follow "Registration Procedures for URL Scheme Names" (RFC 2717) [10]. URN namespace ids follow "URN Namespace Definition Mechanisms" (RFC 2611) (or updates thereto) [9].
给定URI方案或URN命名空间id（NID）的创建遵循这些空间的相应注册文档。URI方案遵循“URL方案名称的注册程序”（RFC 2717）[10]。URN命名空间ID遵循“URN命名空间定义机制”（RFC 2611）（或其更新）[9]。
In order to be inserted into the URI.ARPA zone, the subsequent URI scheme MUST be registered under the IETF URI tree. The requirements for this tree are specified in [10].
为了插入URI.ARPA区域，必须在IETF URI树下注册后续URI方案。[10]中规定了该树的要求。
The registration of a NAPTR record for a URI scheme MUST NOT precede proper registration of that scheme and publication of a stable specification in accordance with [10]. The IESG or its designated expert will review the request for
URI方案的NAPTR记录的注册不得先于该方案的正确注册和根据[10]发布稳定规范。IESG或其指定专家将审查申请
1. correctness and technical soundness
1. 正确性和技术可靠性
2. consistency with the published URI specification, and
2. 与已发布的URI规范的一致性，以及
3. to ensure that the NAPTR record for a DNS-based URI does not delegate resolution of the URI to a party other than the holder of the DNS name. This last rule is to insure that a given URI's resolution hint doesn't hijack (inadvertently or otherwise) network traffic for a given domain.
3. 确保基于DNS的URI的NAPTR记录不会将URI的解析委托给DNS名称持有者以外的其他方。最后一条规则是确保给定URI的解析提示不会（无意中或以其他方式）劫持给定域的网络流量。
A request for a URI.ARPA registration MAY accompany a request for a URI scheme (in accordance with [10]), in which case both requests will be reviewed simultaneously by IESG or its designated experts.
URI.ARPA注册请求可能伴随URI方案请求（根据[10]），在这种情况下，IESG或其指定专家将同时审查两个请求。
A request for a NAPTR record (or an request to change an existing NAPTR record) MAY be submitted after the URI prefix has been registered. If the specification for the URI prefix is controlled by some other party than IETF, IESG will require approval from the owner/maintainer of that specification before the registration will be accepted. This is in addition to any technical review of the NAPTR registration done by IESG or its designated experts.
注册URI前缀后，可以提交NAPTR记录请求（或更改现有NAPTR记录的请求）。如果URI前缀的规范由IETF以外的其他方控制，IESG将要求该规范的所有者/维护者在接受注册之前进行批准。这是IESG或其指定专家对NAPTR注册进行的任何技术审查之外的内容。
The registration of a NAPTR record for a URN NID MUST NOT precede proper registration of that NID and publication of a stable specification in accordance with [9]. This is to prevent the registration of a NAPTR record in URN.ARPA from circumventing the NID registration process.
URN NID的NAPTR记录的注册不得先于该NID的正确注册和根据[9]发布稳定规范。这是为了防止在URN.ARPA中注册NAPTR记录绕过NID注册过程。
A request for a URN.ARPA registration MAY accompany a request for a NID (in accordance with [9]), in which case both requests will be reviewed at the same time.
申请URN.ARPA注册可能伴随NID申请（根据[9]），在这种情况下，两个申请将同时审查。
A request for a NAPTR record (or an request to change an existing NAPTR record) MAY be submitted after the NID has been registered. If the specification for the NID is controlled by some other party than IETF, IESG will require approval from the owner/maintainer of that specification before the registration will be accepted. This is in addition to any technical review of the NAPTR registration done by IESG or its designated experts.
NID注册后，可提交NAPTR记录请求（或更改现有NAPTR记录的请求）。如果NID规范由IETF以外的其他方控制，IESG将要求该规范的所有者/维护者在接受注册之前进行批准。这是IESG或其指定专家对NAPTR注册进行的任何技术审查之外的内容。
Note that this applies to all NAPTR records for a particular NID, even though a NAPTR record might affect only part of the URN space assigned to an NID
请注意，这适用于特定NID的所有NAPTR记录，即使NAPTR记录可能只影响分配给NID的URN空间的一部分
Delegation of a namespace can happen in two ways. In the case of most URIs, the key being delegated to is hard-coded into the identifier itself (e.g., a hostname in an HTTP URI). The syntax of where this new key is located is predetermined by the syntax of the scheme. In other cases, the new key can be part of the hint itself. This is the functional equivalent of saying, "if this rule matches then this is always the key."
命名空间的委派可以通过两种方式进行。在大多数URI的情况下，委托给的密钥被硬编码到标识符本身中（例如，HTTP URI中的主机名）。该新密钥所在的语法由方案的语法预先确定。在其他情况下，新键可以是提示本身的一部分。这在功能上相当于说：“如果此规则匹配，则此规则始终是关键。”
In order to minimize the query load on the URI.ARPA and URN.ARPA zones, it is anticipated that the resource records in those zones will have extremely long "times to live" (TTLs), perhaps measured in years.
为了最小化URI.ARPA和URN.ARPA区域上的查询负载，预计这些区域中的资源记录将有非常长的“生存时间”（TTL），可能以年为单位。
Thus, for any URI prefix or URN namespace for which the resolution hints are likely to change, the actual rule should be stored in some other (less stable) DNS zone, and within URI.ARPA or URN.ARPA a stable NAPTR record should be used to delegate queries to that less stable zone.
因此，对于解析提示可能更改的任何URI前缀或URN命名空间，实际规则应存储在其他（不太稳定的）DNS区域中，并且在URI.ARPA或URN.ARPA中，应使用稳定的NAPTR记录将查询委托给不太稳定的区域。
For example, the 'foo' URN namespace has flexible rules for how delegation takes place. Instead of putting those rules in the URN.ARPA zone, the entry instead punts those rules off to a nameserver that has a shorter time to live. The record in URN.ARPA would look like this:
例如，“foo”URN名称空间具有灵活的委托发生方式规则。该条目不是将这些规则放在URN.ARPA区域中，而是将这些规则推送到生存时间较短的名称服务器。URN.ARPA中的记录如下所示：
foo IN NAPTR 100 10 "" "" "" urn-resolver.foo.com.
NAPTR 100 10“”urn-resolver.foo.com中的foo。
Thus, when the client starts out in the resolution process, the first step will be to query foo.URN.ARPA to find the above record, the second step is to begin asking 'urn-resolver.foo.com' for the NAPTR records that contain the resolution rules. The TTL at the root is very long. The TTL at the 'urn-resolver.foo.com' is much shorter.
因此，当客户端开始解析过程时，第一步是查询foo.URN.ARPA以查找上述记录，第二步是开始询问“URN resolver.foo.com”以获取包含解析规则的NAPTR记录。根部的TTL非常长。“urn resolver.foo.com”上的TTL要短得多。
Conversely, the 'http' URI scheme adheres to a particular syntax that specifies that the host to ask is specified in the URI in question. Since this syntax does not change, that rule can be specified in the URI.ARPA zone. The record would look like this:
相反，“http”URI方案遵循特定语法，该语法指定要询问的主机是在所讨论的URI中指定的。由于该语法不变，因此可以在URI.ARPA区域中指定该规则。记录如下所示：
http IN NAPTR 100 100 "" "" "/http:\\/\\/([^\\/:]+)/\\2/i" .
NAPTR 100 100“”中的http“/http:\/\\/（[^\\/:]+）/\\2/i”。
Thus, the second step of resolution is to use the domain-name found in the URI as the next key in the cycle. If, for example, that NAPTR was terminal and contains some hostname in the replacement field, then the client could contact that host in order to ask questions about this particular URI.
因此，解析的第二步是使用URI中找到的域名作为循环中的下一个键。例如，如果NAPTR是终端，并且在替换字段中包含一些主机名，那么客户端可以联系该主机以询问有关此特定URI的问题。
Using the MIME Content-Type registration mechanism [8] as a model for a successful registration mechanism, the 'URI.ARPA' and 'URN.ARPA' procedures consist of a request template submitted to an open mailing list made up of interested parties. If no objections are made within a two week period, a representative of the registration authority considers the submission to be accepted and enters that submission into the nameserver.
使用MIME内容类型注册机制[8]作为成功注册机制的模型，“URI.ARPA”和“URN.ARPA”过程由提交到由相关方组成的开放邮件列表的请求模板组成。如果在两周内未提出异议，则登记机关的代表将认为该提交被接受，并将该提交输入名称服务器。
o Registrations for the 'URI.ARPA' zone are sent to 'register@URI.ARPA'.
o “URI.ARPA”区域的注册被发送到'register@URI.ARPA'.
o Registrations for the 'URN.ARPA' zone are sent to 'register@URN.ARPA'.
o “URN.ARPA”区域的注册已发送到'register@URN.ARPA'.
The registration authority is the Internet Assigned Numbers Authority (IANA).
注册机构是互联网分配号码管理局（IANA）。
Objections are restricted to those that point out impacts on the zone itself or to DNS in general. Objections to the URI scheme or to the URN namespace-id are not allowed, as these should be raised in their respective forums. The logical conclusion of this is that ANY sanctioned URI scheme or URN namespace MUST be allowed to be registered if it meets the requirements specified in this document as regards times to live and general impact to the DNS.
反对意见仅限于指出对区域本身的影响或一般DNS的反对意见。不允许对URI方案或URN命名空间id提出异议，因为这些异议应该在各自的论坛中提出。这样做的逻辑结论是，如果任何经批准的URI方案或URN命名空间满足本文档中规定的有关生存时间和对DNS的一般影响的要求，则必须允许其注册。
The template to be sent to the appropriate list MUST contain the following values:
要发送到相应列表的模板必须包含以下值：
This is the URN NID or URI scheme, which is used as the domain portion of the DNS entry. It must be valid according to the procedures specified in the URN namespace-id assignment document and any future standards for registering new URI schemes.
这是URN NID或URI方案，用作DNS条目的域部分。它必须根据URN名称空间id分配文档中指定的过程以及注册新URI方案的任何未来标准有效。
This is the individual or organization (entity) which has authority for registering the record. It must be an authority recognized as either the IESG or any authority defined in the URN NID [9] or URI scheme registration [10] documents.
这是有权登记记录的个人或组织（实体）。它必须是公认为IESG或URN NID[9]或URI方案注册[10]文件中定义的任何机构。
The actual DNS records representing the rule set for the key. The required values are Preference, Order, Flags, Services, Regex, and Replacement as defined by RFC 3404 [4].
表示密钥规则集的实际DNS记录。所需的值是RFC 3404[4]定义的首选项、顺序、标志、服务、正则表达式和替换。
To: register@URN.ARPA
From: joe@foo.com
To: register@URN.ARPA
From: joe@foo.com
Key: foo Authority: Foo Technology, Inc as specified in RFCFOO Record: foo IN NAPTR 100 100 "" "" "" urn.foo.com.
关键字：foo授权：RFCFOO记录中指定的foo技术公司：NAPTR 100 100“”urn.foo.com中的foo。
Since this document discusses the URI.ARPA and URN.ARPA zones and the URN rule that exists in the URI.ARPA zone, it makes sense for the registration template for the URN URI rule to be specified here:
由于本文档讨论了URI.ARPA和URN.ARPA区域以及URI.ARPA区域中存在的URN规则，因此在此处指定URN URI规则的注册模板是有意义的：
To: register@URI.ARPA From: The IETF URN Working Group
致：register@URI.ARPA发件人：IETF URN工作组
Key: urn Authority: RFC2141 Record: urn IN NAPTR 0 0 "" "" "/^urn:([^:]+)/\\2/i" .
关键字：urn权限：RFC2141记录：NAPTR 0“”中的urn“/^urn:（[^::]+）/\\2/i”。
The IANA has created the zones URN.ARPA and URI.ARPA. The hierarchical name structure, and the only names to be assigned within these zones, are the "keys" as described in Section 6.1 of this document. The administrative and operational management of these zones are to be undertaken by the IANA. The DNS records to be inserted in these zones are subject to the review process described in this document.
IANA已经创建了URN.ARPA和URI.ARPA区域。分层名称结构以及在这些区域内分配的唯一名称是本文件第6.1节所述的“键”。这些区域的行政和运营管理由IANA负责。要插入到这些区域中的DNS记录受本文档中所述审查过程的约束。
The IANA has also created two discussion lists, register@uri.arpa and register@urn.arpa, for the purposes described in this document. The IANA will manage these mailing lists.
IANA还创建了两个讨论列表，register@uri.arpa和register@urn.arpa，用于本文件所述目的。IANA将管理这些邮件列表。
The 'uri.arpa' and 'urn.arpa' zones will be a common point of attack both for Denial of Service and for spoofing entries in order to redirect delegation paths. Any entity running nameservers that contain these zones should take appropriate action for securing an infrastructure level component of the Internet. When it becomes possible for a nameserver to reliably sign the records in its zone it should do so.
“uri.arpa”和“urn.arpa”区域将是拒绝服务和欺骗条目以重定向委派路径的共同攻击点。任何运行包含这些区域的名称服务器的实体都应该采取适当的措施来保护Internet的基础结构级组件。当名称服务器能够可靠地对其区域中的记录进行签名时，它应该这样做。
The author would like to thank Ron Daniel who was originally co-author of these documents. Ron's original insite into the intricate nature of delegation rules made these procedures and the DDDS itself possible.
作者要感谢Ron Daniel，他最初是这些文件的合著者。罗恩对授权规则复杂本质的独到见解使这些程序和DDDS本身成为可能。
[1] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part One: The Comprehensive DDDS", RFC 3401, October 2002.
[1] Mealling，M，“动态委托发现系统（DDDS）第一部分：综合DDDS”，RFC 3401，2002年10月。
[2] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part Two: The Algorithm", RFC 3402, October 2002.
[2] Mealling，M.，“动态委托发现系统（DDDS）第二部分：算法”，RFC3402，2002年10月。
[3] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part Three: The Domain Name System (DNS) Database", RFC 3403, October 2002.
[3] Mealling，M.“动态委托发现系统（DDDS）第三部分：域名系统（DNS）数据库”，RFC3403，2002年10月。
[4] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part Four: The Uniform Resource Identifiers (URI) Resolution Application", RFC 3404, October 2002.
[4] Mealling，M.“动态委托发现系统（DDDS）第四部分：统一资源标识符（URI）解析应用”，RFC3404，2002年10月。
[5] Mealling, M., "Dynamic Delegation Discovery System (DDDS) Part Five: URI.ARPA Assignment Procedures", RFC 3405, October 2002.
[5] Mealling，M.“动态委托发现系统（DDDS）第五部分：URI.ARPA分配程序”，RFC 3405，2002年10月。
[6] Moats, R., "URN Syntax", RFC 2141, November 1998.
[6] 护城河，R.，“瓮语法”，RFC 21411998年11月。
[7] Berners-Lee, T., Fielding, R. and L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1998.
[7] Berners Lee，T.，Fielding，R.和L.Masinter，“统一资源标识符（URI）：通用语法”，RFC 2396，1998年8月。
[8] Freed, N., Klensin, J. and J. Postel, "Multipurpose Internet Mail Extensions (MIME) Part Four: Registration Procedures", BCP 13, RFC 2048, November 1996.
[8] Freed，N.，Klensin，J.和J.Postel，“多用途互联网邮件扩展（MIME）第四部分：注册程序”，BCP 13，RFC 2048，1996年11月。
[9] Faltstrom, P., Iannella, R., Daigle, L. and D. van Gulik, "URN Namespace Definition Mechanisms", BCP 33, RFC 2611, October 1998.
[9] Faltstrom，P.，Iannella，R.，Daigle，L.和D.van Gulik，“URN名称空间定义机制”，BCP 33，RFC 2611，1998年10月。
[10] Petke, R. and I. King, "Registration Procedures for URL Scheme Names", BCP 35, RFC 2717, January 1999.
[10] Petke，R.和I.King，“URL方案名称的注册程序”，BCP 35，RFC 2717，1999年1月。
Michael Mealling VeriSign 21345 Ridgetop Circle Sterling, VA 20166 US
Michael Mealling VeriSign 21345 Ridgetop Circle Sterling，弗吉尼亚州，美国20166
EMail: michael@neonym.net
URI: http://www.verisignlabs.com
EMail: michael@neonym.net
URI: http://www.verisignlabs.com
Copyright (C) The Internet Society (2002). All Rights Reserved.
版权所有（C）互联网协会（2002年）。版权所有。
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
本文件及其译本可复制并提供给他人，对其进行评论或解释或协助其实施的衍生作品可全部或部分编制、复制、出版和分发，不受任何限制，前提是上述版权声明和本段包含在所有此类副本和衍生作品中。但是，不得以任何方式修改本文件本身，例如删除版权通知或对互联网协会或其他互联网组织的引用，除非出于制定互联网标准的需要，在这种情况下，必须遵循互联网标准过程中定义的版权程序，或根据需要将其翻译成英语以外的其他语言。
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
上述授予的有限许可是永久性的，互联网协会或其继承人或受让人不会撤销。
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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.
本文件和其中包含的信息是按“原样”提供的，互联网协会和互联网工程任务组否认所有明示或暗示的保证，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。