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
        
1. Introduction
1. 介绍

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:”表示协议服务器返回的行。

2. Protocol Updates
2. 协议更新

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名称服务器地址的支持。

2.1. Response Codes
2.1. 响应代码

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

2.2. TRANSFER Command Update
2.2. 传输命令更新

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>
        
2.3. IPv6 Name Server Addresses
2.3. IPv6名称服务器地址

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
        
3. Internationalization Considerations
3. 国际化考虑

This document does not introduce any internationalization considerations that are not already documented in RFC 2832 [2].

本文件不介绍RFC 2832[2]中尚未记录的任何国际化注意事项。

4. IANA Considerations
4. IANA考虑

This document does not introduce any IANA considerations that are not already documented in RFC 2832 [2].

本文件未介绍RFC 2832[2]中尚未记录的任何IANA注意事项。

5. Security Considerations
5. 安全考虑

This document does not introduce any security considerations that are not already documented in RFC 2832 [2].

本文件未介绍RFC 2832[2]中尚未记录的任何安全注意事项。

6. Acknowledgements
6. 致谢

The authors graciously acknowledge the contributions of John Brady, Matt Larson, Bill Manning, Erik Nordmark, and Steve Mahlstedt.

作者们非常感谢约翰·布雷迪、马特·拉森、比尔·曼宁、埃里克·诺德马克和史蒂夫·马尔塞特的贡献。

7. Normative References
7. 规范性引用文件

[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月。

8. Authors' Addresses
8. 作者地址

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
        
9. Full Copyright Statement
9. 完整版权声明

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编辑功能的资金目前由互联网协会提供。