Network Working Group S. Hollenbeck
Request for Comments: 3632 S. Veeramachaneni
Updates: 2832 S. Yalamanchilli
Category: Informational VeriSign, Inc.
November 2003
Network Working Group S. Hollenbeck
Request for Comments: 3632 S. Veeramachaneni
Updates: 2832 S. Yalamanchilli
Category: Informational VeriSign, Inc.
November 2003
VeriSign Registry Registrar Protocol (RRP) Version 2.0.0
VeriSign注册表注册器协议（RRP）2.0.0版
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 (2003). All Rights Reserved.
版权所有（C）互联网协会（2003年）。版权所有。
Abstract
摘要
This document updates version 1.1.0 of the Network Solutions Inc. (NSI) Registry Registrar Protocol (RRP) specified in RFC 2832. The changes described in this document combined with the base specification documented in RFC 2832 specify version 2.0.0 of the VeriSign Registry Registrar Protocol.
本文档更新了RFC 2832中规定的网络解决方案公司（NSI）注册表注册器协议（RRP）的1.1.0版。本文档中描述的更改与RFC 2832中记录的基本规范相结合，指定了VeriSign注册表注册器协议的2.0.0版。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Protocol Updates . . . . . . . . . . . . . . . . . . . . . . . 2
2.1. Response Codes . . . . . . . . . . . . . . . . . . . . . 2
2.2. TRANSFER Command Update . . . . . . . . . . . . . . . . 3
2.3. IPv6 Name Server Addresses . . . . . . . . . . . . . . . 4
3. Internationalization Considerations . . . . . . . . . . . . . 6
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
5. Security Considerations . . . . . . . . . . . . . . . . . . . 6
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6
7. Normative References . . . . . . . . . . . . . . . . . . . . . 6
8. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 7
9. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 8
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Protocol Updates . . . . . . . . . . . . . . . . . . . . . . . 2
2.1. Response Codes . . . . . . . . . . . . . . . . . . . . . 2
2.2. TRANSFER Command Update . . . . . . . . . . . . . . . . 3
2.3. IPv6 Name Server Addresses . . . . . . . . . . . . . . . 4
3. Internationalization Considerations . . . . . . . . . . . . . 6
4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
5. Security Considerations . . . . . . . . . . . . . . . . . . . 6
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6
7. Normative References . . . . . . . . . . . . . . . . . . . . . 6
8. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 7
9. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 8
The Network Solutions, Inc. (NSI) Registry Registrar Protocol (RRP) was developed by NSI in 1998 and 1999 to allow multiple registrars to provide second level Internet domain name registration services in the top level domains (TLDs) administered by the NSI TLD registry. Version 1.1.0 of the NSI RRP was published as Informational RFC 2832 [2] in May 2000. This document describes changes to RFC 2832 that specify version 2.0.0 of the protocol.
网络解决方案公司（NSI）注册注册商协议（RRP）由NSI于1998年和1999年开发，允许多个注册商在NSI TLD注册管理的顶级域（TLD）中提供二级互联网域名注册服务。NSI RRP的1.1.0版于2000年5月作为参考RFC 2832[2]发布。本文档描述了对RFC 2832的更改，这些更改指定了协议的版本2.0.0。
Conventions Used In This Document
本文件中使用的公约
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, RFC 2119 [1].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照BCP 14、RFC 2119[1]中的描述进行解释。
In examples, "C:" represents lines sent by a protocol client and "S:" represents lines returned by a protocol server.
在示例中，“C:”表示协议客户端发送的行，“S:”表示协议服务器返回的行。
This specification describes several modifications to RFC 2832 [2]: two new response codes have been added, domain TRANSFER command processing has been updated to allow a client to cancel a requested domain transfer, and support for IPv6 name server addresses has been added.
本规范描述了对RFC 2832[2]的几项修改：添加了两个新的响应代码，更新了域传输命令处理以允许客户端取消请求的域传输，并添加了对IPv6名称服务器地址的支持。
Section 5.1 of RFC 2832 [2] has been updated to include two additional error response codes.
RFC 2832[2]第5.1节已更新，包括两个额外的错误响应代码。
510 Invalid encoding
510无效编码
The value of a domain name or name server entity contains invalid ASCII compatible encoding used to represent an internationalized domain or host name. The encoding is checked and verified in two situations: when registering an internationalized domain name or name server name, and when changing the name of a name server and the new name of the server is internationalized.
域名或名称服务器实体的值包含用于表示国际化域名或主机名的无效ASCII兼容编码。在两种情况下检查和验证编码：注册国际化域名或名称服务器名称时，以及更改名称服务器名称和服务器新名称国际化时。
Section 5.2 of RFC 2832 [2] has been updated to include response code 510 as a possible error value returned from the ADD command:
RFC 2832[2]第5.2节已更新，将响应代码510作为ADD命令返回的可能错误值包括在内：
Command: ADD Success: 200, 220 Failure: 420, 421, 500, 502, 503, 504, 505, 507, 508, 510, 520, 531, 535, 540, 541, 545, 546, 547, 549, 550, 554
命令：添加成功：200、220失败：420、421、500、502、503、504、505、507、508、510、520、531、535、540、541、545、546、547、549、550、554
557 Name server locked
557名称服务器已锁定
An attempt has been made to modify or delete a name server that is hosting a TLD in the root zone. Modifications to the root zone can only be made with the approval of the U.S. Department of Commerce and IANA, so if the registrar absolutely needs to modify or delete such a name server, the action needs to be coordinated through the registry operator using an out-of-band communications channel.
已尝试修改或删除在根区域中承载TLD的名称服务器。对根区域的修改只能在获得美国商务部和IANA批准的情况下进行，因此，如果注册官绝对需要修改或删除此类名称服务器，则需要通过注册运营商使用带外通信渠道协调操作。
Section 5.2 of RFC 2832 [2] has been updated to include response code 557 as a possible error value returned from the DEL and MOD commands:
RFC 2832[2]第5.2节已更新，将响应代码557作为从DEL和MOD命令返回的可能错误值包括在内：
Command: DEL Success: 200, 220 Failure: 420, 421, 500, 502, 503, 504, 505, 507, 508, 520, 531, 532, 533, 541, 544, 545, 547, 549, 551, 552, 553, 557
命令：DEL成功：200220失败：420421500502 50350450507050852053153254354145454757
Command: MOD Success: 200, 220 Failure: 420, 421, 500, 502, 503, 504, 505, 507, 508, 510, 520, 531, 535, 540, 541, 542, 543, 544, 545, 547, 549, 550, 551, 552, 553, 557
命令：MOD Success:200220 Failure:420421500502503500705085105205315355540541541542547549559553557
Section 4.3.10 of RFC 2832 [2] has been updated to include an additional TRANSFER command processing option.
RFC 2832[2]第4.3.10节已更新，以包括额外的传输命令处理选项。
Old text:
旧文本：
Authorized User: All registrars MAY use the TRANSFER command to request the transfer of registration service authority to the requesting registrar. Only the current sponsoring registrar of a domain name may explicitly approve or reject a requested transfer. The registry MAY implicitly approve or reject requested transfers after a fixed amount of time.
授权用户：所有注册人可使用转移命令向请求注册人请求注册服务权限的转移。只有域名的当前发起注册机构可以明确批准或拒绝请求的转移。登记处可在一段固定时间后默示批准或拒绝所请求的转让。
New text:
新案文：
Authorized User: All registrars MAY use the TRANSFER command to request transfer of registration service authority to the requesting registrar. Only the current sponsoring registrar of a domain name may explicitly approve a requested transfer. The current sponsoring registrar MAY explicitly reject a requested transfer. The registry MAY implicitly approve or reject requested transfers after a fixed amount of time. The requesting registrar MAY cancel a pending request, but the request to cancel the transfer MUST be sent before it has been explicitly approved or rejected by the current sponsoring registrar or it has been implicitly approved or rejected by the registry.
授权用户：所有注册人可使用转移命令向请求注册人请求注册服务权限的转移。只有域名的当前发起注册机构可以明确批准请求的转移。目前的担保登记官可明确拒绝所请求的转让。登记处可在一段固定时间后默示批准或拒绝所请求的转让。提出请求的登记官可以取消一项未决请求，但取消转让的请求必须在当前担保登记官明确批准或拒绝或登记处默示批准或拒绝之前发出。
Example:
例子：
A registrar cancels a previously requested domain transfer:
注册器取消先前请求的域传输：
C:transfer<crlf>
C:-Approve:No<crlf>
C:EntityName:Domain<crlf>
C:DomainName:example.com<crlf>
C:.<crlf>
S:200 Command completed successfully<crlf>
S:.<crlf>
C:transfer<crlf>
C:-Approve:No<crlf>
C:EntityName:Domain<crlf>
C:DomainName:example.com<crlf>
C:.<crlf>
S:200 Command completed successfully<crlf>
S:.<crlf>
Section 7 of RFC 2832 [2] has been updated to include support for name servers using IPv6 addresses. IPv6 addressing architecture is described in RFC 3513 [3]. This ABNF [4] grammar supplements the grammar defined in RFC 2832.
RFC 2832[2]第7节已更新，包括对使用IPv6地址的名称服务器的支持。RFC 3513[3]中描述了IPv6寻址体系结构。本ABNF[4]语法补充了RFC 2832中定义的语法。
; Lexical Tokens
; 词汇标记
hexdigit = digit / %X41-46 / %x61-66 ; 0-9 / A-F / a-f
hexdigit = digit / %X41-46 / %x61-66 ; 0-9 / A-F / a-f
doubleoctet = 1*4hexdigit
doubleoctet = 1*4hexdigit
docolon = doubleoctet colon
docolon = doubleoctet colon
colondo = colon doubleoctet
colondo = colon doubleoctet
ip-address = ip-address-v4 / ip-address-v6
ip-address = ip-address-v4 / ip-address-v6
; ipv4 addresses
ip-address-v4 = 1*3digit dot 1*3digit dot 1*3digit dot 1*3digit
; ipv4 addresses
ip-address-v4 = 1*3digit dot 1*3digit dot 1*3digit dot 1*3digit
ip-address-v6 = ip-address-v6-standard / ip-address-v6-compressed
; Standard form of IPv6 addresses
; 8 hexdigit strings of length 1-4 separated by colons
;
; Eg: 10AA:0:0:00:8:800:200C:417A
ip-address-v6 = ip-address-v6-standard / ip-address-v6-compressed
; Standard form of IPv6 addresses
; 8 hexdigit strings of length 1-4 separated by colons
;
; Eg: 10AA:0:0:00:8:800:200C:417A
ip-address-v6-standard = doubleoctet 7colondo
ip-address-v6-standard = doubleoctet 7colondo
; Compressed form of IPv6 addresses
; Runs of zero-value octets are represented by '::'
;
; Examples:
; :: ==> 0:0:0:0:0:0:0:0
;
; 1:: ==> 1:0:0:0:0:0:0:0
; 2:2:: ==> 2:2:0:0:0:0:0:0
; 7:7:7:7:7:7:7:: ==> 7:7:7:7:7:7:7:0
;
; ::1 ==> 0:0:0:0:0:0:0:1
; ::2:2 ==> 0:0:0:0:0:0:2:2
; ::7:7:7:7:7:7:7 ==> 0:7:7:7:7:7:7:7
;
; E::1 ==> E:0:0:0:0:0:0:1
; E::2:2 ==> E:0:0:0:0:0:2:2
; E::6:6:6:6:6:6 ==> E:0:6:6:6:6:6:6
;
; E:E::1 ==> E:E:0:0:0:0:0:1
; E:E::2:2 ==> E:E:0:0:0:0:2:2
; E:E::5:5:5:5:5 ==> E:E:0:5:5:5:5:5
;
; E:E:E::1 ==> E:E:E:0:0:0:0:1
; E:E:E::2:2 ==> E:E:E:0:0:0:2:2
; E:E:E::4:4:4:4 ==> E:E:E:0:4:4:4:4
;
; E:E:E:E::1 ==> E:E:E:E:0:0:0:1
; E:E:E:E::2:2 ==> E:E:E:E:0:0:2:2
; E:E:E:E::3:3:3 ==> E:E:E:E:0:3:3:3
;
; E:E:E:E:E::1 ==> E:E:E:E:E:0:0:1
; E:E:E:E:E::2:2 ==> E:E:E:E:E:0:2:2
;
; E:E:E:E:E:E::1 ==> E:E:E:E:E:E:0:1
; Compressed form of IPv6 addresses
; Runs of zero-value octets are represented by '::'
;
; Examples:
; :: ==> 0:0:0:0:0:0:0:0
;
; 1:: ==> 1:0:0:0:0:0:0:0
; 2:2:: ==> 2:2:0:0:0:0:0:0
; 7:7:7:7:7:7:7:: ==> 7:7:7:7:7:7:7:0
;
; ::1 ==> 0:0:0:0:0:0:0:1
; ::2:2 ==> 0:0:0:0:0:0:2:2
; ::7:7:7:7:7:7:7 ==> 0:7:7:7:7:7:7:7
;
; E::1 ==> E:0:0:0:0:0:0:1
; E::2:2 ==> E:0:0:0:0:0:2:2
; E::6:6:6:6:6:6 ==> E:0:6:6:6:6:6:6
;
; E:E::1 ==> E:E:0:0:0:0:0:1
; E:E::2:2 ==> E:E:0:0:0:0:2:2
; E:E::5:5:5:5:5 ==> E:E:0:5:5:5:5:5
;
; E:E:E::1 ==> E:E:E:0:0:0:0:1
; E:E:E::2:2 ==> E:E:E:0:0:0:2:2
; E:E:E::4:4:4:4 ==> E:E:E:0:4:4:4:4
;
; E:E:E:E::1 ==> E:E:E:E:0:0:0:1
; E:E:E:E::2:2 ==> E:E:E:E:0:0:2:2
; E:E:E:E::3:3:3 ==> E:E:E:E:0:3:3:3
;
; E:E:E:E:E::1 ==> E:E:E:E:E:0:0:1
; E:E:E:E:E::2:2 ==> E:E:E:E:E:0:2:2
;
; E:E:E:E:E:E::1 ==> E:E:E:E:E:E:0:1
ip-address-v6-compressed = colon colon
ip-address-v6-compressed =/ 1*7docolon colon
ip-address-v6-compressed =/ colon 1*7colondo
ip-address-v6-compressed =/ docolon 1*6colondo
ip-address-v6-compressed =/ 2docolon 1*5colondo
ip-address-v6-compressed = colon colon
ip-address-v6-compressed =/ 1*7docolon colon
ip-address-v6-compressed =/ colon 1*7colondo
ip-address-v6-compressed =/ docolon 1*6colondo
ip-address-v6-compressed =/ 2docolon 1*5colondo
ip-address-v6-compressed =/ 3docolon 1*4colondo
ip-address-v6-compressed =/ 4docolon 1*3colondo
ip-address-v6-compressed =/ 5docolon 1*2colondo
ip-address-v6-compressed =/ 6docolon colondo
ip-address-v6-compressed =/ 3docolon 1*4colondo
ip-address-v6-compressed =/ 4docolon 1*3colondo
ip-address-v6-compressed =/ 5docolon 1*2colondo
ip-address-v6-compressed =/ 6docolon colondo
This document does not introduce any internationalization considerations that are not already documented in RFC 2832 [2].
本文件不介绍RFC 2832[2]中尚未记录的任何国际化注意事项。
This document does not introduce any IANA considerations that are not already documented in RFC 2832 [2].
本文件未介绍RFC 2832[2]中尚未记录的任何IANA注意事项。
This document does not introduce any security considerations that are not already documented in RFC 2832 [2].
本文件未介绍RFC 2832[2]中尚未记录的任何安全注意事项。
The authors graciously acknowledge the contributions of John Brady, Matt Larson, Bill Manning, Erik Nordmark, and Steve Mahlstedt.
作者们非常感谢约翰·布雷迪、马特·拉森、比尔·曼宁、埃里克·诺德马克和史蒂夫·马尔塞特的贡献。
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[1] Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[2] Hollenbeck, S. and M. Srivastava, "NSI Registry Registrar Protocol (RRP) Version 1.1.0", RFC 2832, May 2000.
[2] Hollenbeck，S.和M.Srivastava，“NSI注册登记协议（RRP）1.1.0版”，RFC 28322000年5月。
[3] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6) Addressing Architecture", RFC 3513, April 2003.
[3] Hinden，R.和S.Deering，“互联网协议版本6（IPv6）寻址体系结构”，RFC 3513，2003年4月。
[4] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997.
[4] Crocker，D.，Ed.和P.Overell，“语法规范的扩充BNF:ABNF”，RFC 2234，1997年11月。
Scott Hollenbeck VeriSign, Inc. 21345 Ridgetop Circle Dulles, VA 20166-6503 US
Scott Hollenbeck VeriSign，Inc.美国弗吉尼亚州杜勒斯Ridgetop Circle 21345，邮编20166-6503
EMail: shollenbeck@verisign.com
EMail: shollenbeck@verisign.com
Srikanth Veeramachaneni VeriSign, Inc. 21345 Ridgetop Circle Dulles, VA 20166-6503 US
Srikanth Veeramachaneni VeriSign公司，美国弗吉尼亚州杜勒斯Ridgetop Circle 21345，邮编20166-6503
EMail: sveerama@verisign.com
EMail: sveerama@verisign.com
Suresh Yalamanchilli VeriSign, Inc. 21345 Ridgetop Circle Dulles, VA 20166-6503 US
Suresh Yalamanchilli VeriSign，Inc.美国弗吉尼亚州杜勒斯Ridgetop Circle 21345，邮编20166-6503
EMail: syalamanchilli@verisign.com
EMail: syalamanchilli@verisign.com
Copyright (C) The Internet Society (2003). All Rights Reserved.
版权所有（C）互联网协会（2003年）。版权所有。
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 assignees.
上述授予的有限许可是永久性的，互联网协会或其继承人或受让人不会撤销。
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编辑功能的资金目前由互联网协会提供。