[要約] RFC 3632は、VeriSign Registry Registrar Protocol（RRP）バージョン2.0.0に関する仕様書です。このRFCの目的は、VeriSignレジストリとレジストラ間の通信プロトコルを定義し、ドメイン名の登録や管理などの操作を効率的に行うことです。
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 Registry Registrar Protocol（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で指定されているネットワークソリューションInc.（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
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.
ネットワークソリューション、Inc。（NSI）レジストリレジストラプロトコル（RRP）は、1998年と1999年にNSIによって開発され、複数のレジストラはNSI TLDレジストリによって管理されている最上位のドメイン（TLDS）で2番目のレベルのインターネットドメイン名登録サービスを提供できるようにしました。。NSI RRPのバージョン1.1.0は、2000年5月に情報RFC 2832 [2]として公開されています。このドキュメントでは、プロトコルのバージョン2.0.0を指定するRFC 2832への変更について説明します。
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].
「必須」、「必須」、「必要ではない」、「しない」、「推奨する」、「推奨する」、「5月」、および「オプション」、「オプション」、「オプション」、「オプション」、「オプション」、「オプション」、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]：2つの新しい応答コードが追加されました、クライアントが要求されたドメイン転送をキャンセルできるようにドメイン転送コマンド処理が更新され、IPv6ネームサーバーアドレスのサポートが追加されました。
Section 5.1 of RFC 2832 [2] has been updated to include two additional error response codes.
RFC 2832 [2]のセクション5.1は、2つの追加のエラー応答コードを含むように更新されました。
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互換エンコーディングが含まれています。エンコードは2つの状況でチェックされ検証されます。国際化されたドメイン名またはネームサーバー名を登録するとき、およびネームサーバーの名前を変更するときとサーバーの新しい名前が国際化されています。
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は、ADDコマンドから返される可能性のあるエラー値として応答コード510を含むように更新されました。
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は、DELおよびMODコマンドから返される可能性のあるエラー値として応答コード557を含むように更新されました。
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 SUCCESS：200,220故障：420,421,500,502,503,504,505,507,508,520,531,532,533,541,544,545,547,549,551,552、553,557
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成功：200,220故障：420,421,500,502,503,504,505,507,508,510,520,531,535,540,541,542,543,544,545,547、547、547、549,550,551,552,553,557
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>
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アドレスを使用したネームサーバのサポートを含むように更新されました。IPv6アドレッシングアーキテクチャはRFC 3513 [3]に記載されています。このABNF [4]文法は、RFC 2832で定義されている文法を補足します。
; Lexical Tokens
;字句トークン
hexdigit = digit / %X41-46 / %x61-66 ; 0-9 / A-F / a-f
doubleoctet = 1*4hexdigit
docolon = doubleoctet colon
colondo = colon doubleoctet
ip-address = ip-address-v4 / ip-address-v6
; 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-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
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
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]にまだ文書化されていないセキュリティ上の考慮事項は導入されません[2]。
The authors graciously acknowledge the contributions of John Brady, Matt Larson, Bill Manning, Erik Nordmark, and Steve Mahlstedt.
著者らは、ジョンBrady、Matt Larson、Bill Manning、Erik Nordmark、および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.Srivastava、 "NSI Registry Registrar Protocol（RRP）バージョン1.1.0"、RFC 2832、2000年5月。
[3] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6) Addressing Architecture", RFC 3513, April 2003.
[3] 「インターネットプロトコルバージョン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、「Syntax仕様のための拡張BNF：ABNF」、RFC 2234、1997年11月。
Scott Hollenbeck VeriSign, Inc. 21345 Ridgetop Circle Dulles, VA 20166-6503 US
Scott Hollenbeck Verisign、Inc。21345 Ridgetop Circle Dulles、VA 20166-6503 US
EMail: shollenbeck@verisign.com
Srikanth Veeramachaneni VeriSign, Inc. 21345 Ridgetop Circle Dulles, VA 20166-6503 US
Srikanth Veeramachaneni Verisign、Inc。21345 Ridgetop Circle Dulles、VA 20166-6503 US
EMail: sveerama@verisign.com
Suresh Yalamanchilli VeriSign, Inc. 21345 Ridgetop Circle Dulles, VA 20166-6503 US
Suresh Yalamanchilli Verisign、Inc。21345 Ridgetop Circle Dulles、VA 20166-6503 US
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エディタ機能のための資金は、現在インターネット社会によって提供されています。