Network Working Group S. Hollenbeck
Request for Comments: 3375 Verisign, Inc.
Category: Informational September 2002
Generic Registry-Registrar Protocol Requirements
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 (2002). All Rights Reserved.
著作権（C）インターネット協会（2002）。全著作権所有。
Abstract
抽象
This document describes high-level functional and interface requirements for a client-server protocol for the registration and management of Internet domain names in shared registries. Specific technical requirements detailed for protocol design are not presented here. Instead, this document focuses on the basic functions and interfaces required of a protocol to support multiple registry and registrar operational models.
この文書は共有レジストリでインターネットドメイン名の登録と管理のためのクライアントサーバプロトコルのための高レベルの機能とインタフェースの要件について説明します。プロトコル設計のための詳細な具体的な技術的要件は、ここで提示されていません。代わりに、この文書では、複数のレジストリとレジストラ運用モデルをサポートするためのプロトコルで必要な基本的な機能とインターフェイスに焦点を当てています。
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 [RFC2119].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[RFC2119]に記載されているように解釈されます。
Table of Contents
目次
1. Introduction ....................................... 2
1.1 Definitions, Acronyms, and Abbreviations ........... 2
2. General Description ................................ 4
2.1 System Perspective ................................. 4
2.2 System Functions ................................... 4
2.3 User Characteristics ............................... 5
2.4 Assumptions ........................................ 5
3. Functional Requirements ............................ 5
3.1 Session Management ................................. 6
3.2 Identification and Authentication .................. 6
3.3 Transaction Identification ......................... 7
3.4 Object Management .................................. 7
3.5 Domain Status Indicators ........................... 13
3.6 Transaction Completion Status ...................... 13
4. External Interface Requirements .................... 14
4.1 User, Hardware, and Software Interfaces ............ 14
4.2 Communications Interfaces .......................... 14
5. Performance Requirements ........................... 14
6. Design Constraints ................................. 14
6.1 Standards Compliance ............................... 14
6.2 Hardware Limitations ............................... 15
7. Service Attributes ................................. 15
7.1 Reliability ........................................ 15
7.2 Availability ....................................... 15
7.3 Scalability ........................................ 16
7.4 Maintainability .................................... 16
7.5 Extensibility ...................................... 16
7.6 Security ........................................... 16
8. Other Requirements ................................. 17
8.1 Database Requirements .............................. 17
8.2 Operational Requirements ........................... 17
8.3 Site Adaptation Requirements ....................... 17
8.4 Data Collection Requirements ....................... 17
9. Internationalization Requirements .................. 18
10. IANA Considerations ................................ 18
11. Security Considerations ............................ 18
12. Acknowledgements ................................... 19
13. References ......................................... 19
14. Editor's Address ................................... 20
15. Full Copyright Statement ........................... 21
The advent of shared domain name registration systems illustrates the utility of a common, generic protocol for registry-registrar interaction. A standard generic protocol will allow registrars to communicate with multiple registries through a common interface, reducing operational complexity. This document describes high level functional and interface requirements for a generic provisioning protocol suitable for registry-registrar operations. Detailed technical requirements are not addressed in this document.
共有ドメイン名登録システムの出現は、レジストリ・レジストラの相互作用のための一般的な、一般的なプロトコルの有用性を示しています。標準汎用プロトコルは、演算の複雑さを低減する、レジストラは、共通のインタフェースを介して複数のレジストリと通信することを可能にします。この文書は、レジストリ、レジストラ動作に適した一般的なプロビジョニングプロトコルのための高レベルの機能とインタフェースの要件を記載しています。詳細な技術的要件は、本書で扱われていません。
ccTLD: Country Code Top Level Domain. ".us" is an example of a ccTLD.
ccTLD：国コードトップレベルドメイン。 「.US」はccTLDの一例です。
DNS: Domain Name System
DNS：ドメインネームシステム
gTLD: Generic Top Level Domain. ".com" is an example of a gTLD.
gTLD：ジェネリックトップレベルドメイン。 「.COM」は、gTLDの一例です。
IANA: Internet Assigned Numbers Authority
IANA：インターネット割り当て番号機関
IETF: Internet Engineering Task Force
IETF：インターネットエンジニアリングタスクフォース
IP Address: Either or both IPv4 or IPv6 address.
IPアドレス：どちらか一方または両方のIPv4またはIPv6アドレス。
IPv4: Internet Protocol version 4
IPv4のインターネットプロトコルバージョン4
IPv6: Internet Protocol version 6
IPv6のインターネットプロトコルバージョン6
RRP: Registry-Registrar Protocol
RRP：レジストリ、レジストラプロトコル
TLD: Top Level Domain. A generic term used to describe both gTLDs and ccTLDs that exist under the top-level root of the domain name hierarchy.
TLD：トップレベルドメイン。ドメイン名の階層の最上位レベルのルートの下に存在し、両方のgTLDおよびccTLDのを記述するために使用される一般的な用語。
Exclusive Registration System: A domain name registration system in which registry services are limited to a single registrar. Exclusive Registration Systems are either loosely coupled (in which case the separation between registry and registrar systems is readily evident), or tightly coupled (in which case the separation between registry and registrar systems is obscure).
独占登録制度：レジストリサービスが単一のレジストラに限定されているドメイン名登録システム。排他的な登録システムは、いずれか緩く（レジストリとレジストラシステム間の分離が不明瞭である場合）（レジストリとレジストラシステム間の分離が容易に明らかである場合には）結合、又は緊密に結合されています。
Name Space: The range of values that can be assigned within a particular node of the domain name hierarchy.
名前空間：ドメイン名階層の特定のノード内で割り当て可能な値の範囲。
Object: A generic term used to describe entities that are created, updated, deleted, and otherwise managed by a generic registry-registrar protocol.
オブジェクト：作成、更新、削除、およびそれ以外の一般的なレジストリ・レジストラプロトコルによって管理されているエンティティを記述するために使用される一般的な用語。
Registrant: An entity that registers domain names in a registry through the services provided by a registrar. Registrants include individuals, organizations, and corporations.
登録者：レジストラが提供するサービスを通じてレジストリにドメイン名を登録するエンティティ。登録者は、個人、団体、企業が含まれています。
Registrar: An entity that provides front-end domain name registration services to registrants, providing a public interface to registry services.
レジストラ：サービスをレジストリにパブリックインターフェイスを提供し、登録者へのフロントエンドのドメイン名登録サービスを提供するエンティティ。
Registry: An entity that provides back-end domain name registration services to registrars, managing a central repository of information associated with domain name delegations. A registry is typically responsible for publication and distribution of zone files used by the Domain Name System.
レジストリ：ドメイン名の代表団に関連した情報の中央リポジトリを管理、レジストラにバックエンドのドメイン名登録サービスを提供するエンティティ。レジストリは通常、ドメイン・ネーム・システムで使用されるゾーンファイルの出版と流通を担当しています。
Shared Registration System: A domain name registration system in which registry services are shared among multiple independent registrars. Shared Registration Systems require a loose coupling between registrars and a registry.
共有登録システム：レジストリサービスは、複数の独立した登録機関の間で共有されているドメイン名登録システム。共有登録システムは、レジストラとレジストリの間の疎結合を必要としています。
Thick Registry: A registry in which all of the information associated with registered entities, including both technical information (information needed to produce zone files) and social information (information needed to implement operational, business, or legal practices), is stored within the registry repository.
太いレジストリ：両方の技術情報（ゾーンファイルを生成するために必要な情報）と社会的情報（運用、ビジネス、または法的プラクティスを実装するために必要な情報）を含む登録エンティティに関連付けられた情報のすべては、レジストリ内に格納されているレジストリ倉庫。
Thin Registry: A registry in which all elements of the social information associated with registered entities is distributed between a shared registry and the registrars served by the registry.
シンレジストリ：登録したエンティティに関連付けられている社会的な情報のすべての要素が共有レジストリとレジストリによって提供されるレジストラーの間に分散されているレジストリ。
Zone: The complete set of information for a particular "pruned" subtree of the domain space. The zone concept is described fully in [RFC1035].
ゾーン：ドメイン空間の特定の「剪定」サブツリーのための情報の完全なセット。ゾーンの概念は[RFC1035]で完全に記述されています。
A basic understanding of domain name registration systems provides focus for the enumeration of functional and interface requirements of a protocol to serve those systems. This section provides a high-level description of domain name registration systems to provide context for the requirements identified later in this document.
ドメイン名登録システムの基本的な理解は、それらのシステムにサービスを提供するためのプロトコルの機能とインタフェースの要件の列挙のための焦点を提供します。このセクションでは、この文書の後で特定された要件のためのコンテキストを提供するために、ドメイン名登録システムの高レベルの記述を提供します。
A domain name registration system consists of a protocol and associated software and hardware that permits registrars to provide Internet domain name registration services within the name spaces administered by a registry. A registration system can be shared among multiple competing registrars, or it can be served by a single registrar that is either tightly or loosely coupled with back-end registry services. The system providing registration services for the .com, .net, and .org gTLDs is an example of a shared registration system serving multiple competing registrars. The systems providing registration services for some ccTLDs and the .gov and .mil gTLDs are examples of registration systems served by a single registrar.
ドメイン名の登録システムは、レジストリによって管理名前空間内のインターネットドメイン名登録サービスを提供するために、レジストラを許可プロトコルと関連するソフトウェアとハードウェアで構成されています。登録システムは、複数の競合するレジストラの間で共有することができ、またはそれはしっかりまたは緩くバックエンドのレジストリサービスと結合されているいずれかの単一のレジストラによって提供することができます。システム.NET、.COMの登録サービスを提供し、そしてのgTLDを.orgのは、複数の競合するレジストラをサービング共有登録システムの一例です。いくつかのccTLDと.GOVと.MILのgTLDの登録サービスを提供するシステムは、単一のレジストラが提供する登録システムの例です。
Registrars access a registry through a protocol to register objects and perform object management functions. Required functions include session management; object creation, update, renewal, and deletion; object query; and object transfer.
レジストラは、オブジェクトを登録し、オブジェクト管理機能を実行するためのプロトコルを介してレジストリにアクセスします。必要な機能は、セッション管理を含め、オブジェクトの作成、更新、更新、および削除。オブジェクトクエリ。およびオブジェクト転送。
A registry generates DNS zone files for the name spaces it serves. Zone files are created and distributed to a series of name servers that provide the foundation for the domain name system.
レジストリは、それがサービスを提供するネームスペースのDNSゾーンファイルを生成します。ゾーンファイルが作成され、ドメインネームシステムのための基盤を提供するネームサーバのシリーズに配布されています。
Protocol users fall into two broad categories: entities that use protocol client implementations and entities that use protocol server implementations, though an entity can provide both client and server services if it provides intermediate services. A protocol provides a loose coupling between these communicating entities.
それは中間のサービスを提供する場合、エンティティは、クライアントとサーバーの両方のサービスを提供することができますが、プロトコルのクライアント実装とプロトコル・サーバの実装を使用するエンティティを使用するエンティティ：プロトコルのユーザーは2つの広いカテゴリーに分類されます。プロトコルは、これらの通信エンティティ間の疎結合を提供します。
There is one and only one registry that is authoritative for a given name space and zone.
指定された名前空間とゾーンに対して権限を持っている、唯一のレジストリがあります。
A registry can be authoritative for more than one name space and zone. Some registry operations can be billable. The impact of a billable operation can be mitigated through the specification of non-billable operations that allow a registrar to make informed decisions before executing billable operations.
レジストリは複数の名前空間とゾーンに対する権限を持つことができます。いくつかのレジストリ操作は請求可能なことができます。請求可能な操作の影響は、レジストラが請求可能な操作を実行する前に、情報に基づいた意思決定を行うことを可能非課金対象業務の仕様によって軽減することができます。
A registry can choose to implement a subset of the features provided by a generic registry-registrar protocol. A thin registry, for example, might not provide services to register social information. Specification of minimal implementation compliance requirements is thus an exercise left for a formal protocol definition document that addresses the functional requirements specified here.
レジストリは、一般的なレジストリ・レジストラプロトコルによって提供される機能のサブセットを実装することを選択することができます。薄いレジストリは、例えば、社会的な情報を登録するためのサービスを提供しない場合があります。最小限の実装のコンプライアンス要件の仕様は、このように、ここで指定された機能要件に対処し、正式なプロトコル定義文書に残さ運動です。
A protocol that meets the requirements described here can be called something other than "Generic Registry Registrar Protocol".
ここで説明した要件を満たしているプロトコルは、「一般的なレジストリレジストラプロトコル」以外の何かを呼び出すことができます。
The requirements described in this document are not intended to limit the set of objects that can be managed by a generic registry-registrar protocol.
この文書で説明した要件は、一般的なレジストリ、レジストラプロトコルによって管理することができるオブジェクトのセットを限定するものではありません。
This section describes functional requirements for a registry-registrar protocol. Technical requirements that describe how these requirements are to be met are out of scope for this document.
このセクションでは、レジストリ・レジストラプロトコルのための機能要件について説明します。これらの要件を満たさなければならない方法を記述技術的要件は、この文書の範囲外です。
[1] The protocol MUST provide services to explicitly establish a client session with a registry server.
[1]プロトコルは、明示的にレジストリサーバとクライアントのセッションを確立するためのサービスを提供しなければなりません。
[2] In a connection-oriented environment, a server MUST respond to connection attempts with information that identifies the server and the default server protocol version.
[2]接続指向環境では、サーバは、サーバと、デフォルトのサーバ・プロトコル・バージョンを識別する情報と接続試行に応答しなければなりません。
[3] The protocol MUST provide services that allow a client to request use of a specific protocol version as part of negotiating a session.
[3]プロトコルは、クライアントがセッションを交渉の一部として、特定のプロトコル・バージョンを使用することを要求することを可能にするサービスを提供しなければなりません。
[4] The protocol MUST provide services that allow a server to decline use of a specific protocol version as part of negotiating a session.
[4]プロトコルは、サーバが、セッションを交渉の一部として、特定のプロトコル・バージョンを使用することを拒否することを可能にするサービスを提供しなければなりません。
[5] A session MUST NOT be established if the client and server are unable to reach agreement on the protocol version to be used for the requested session.
クライアントとサーバは、要求されたセッションのために使用するプロトコルのバージョンについて合意に達することができない場合は、[5]セッションが確立されてはなりません。
[6] The protocol MUST provide services to explicitly end an established session.
[6]プロトコルは、明示的に確立されたセッションを終了するサービスを提供しなければなりません。
[7] The protocol MUST provide services that provide transactional atomicity, consistency, isolation, and durability in the advent of session management failures.
[7]プロトコルは、セッション管理障害の出現でトランザクション原子性、一貫性、分離、および耐久性を提供するサービスを提供しなければなりません。
[8] The protocol MUST provide services to confirm that a transaction has been completed if a session is aborted prematurely.
[8]プロトコルは、セッションが途中で中止された場合、トランザクションが完了していることを確認するためのサービスを提供しなければなりません。
[1] The protocol or another layered protocol MUST provide services to identify registrar clients and registry servers before granting access to other protocol services.
[1]プロトコルまたは別の階層型プロトコルは、他のプロトコルサービスへのアクセスを許可する前に、レジストラクライアントとレジストリサーバーを識別するためのサービスを提供しなければなりません。
[2] The protocol or another layered protocol MUST provide services to authenticate registrar clients and registry servers before granting access to other protocol services.
[2]プロトコルまたは別の階層型プロトコルは、他のプロトコルサービスへのアクセスを許可する前に、レジストラクライアントとレジストリ・サーバを認証するためのサービスを提供しなければなりません。
[3] The protocol or another layered protocol MUST provide services to negotiate an authentication mechanism acceptable to both client and server.
[3]プロトコルまたは別の階層型プロトコルは、クライアントとサーバの両方に許容される認証機構をネゴシエートするためのサービスを提供しなければなりません。
[1] Registry operations that create, modify, or delete objects MUST be associated with a registry-unique identifier. The protocol MUST allow each transaction to be identified in a permanent and globally unique manner to facilitate temporal ordering and state management services.
[1]、変更、またはオブジェクトを削除作成レジストリ操作は、レジストリ固有識別子に関連付けられなければなりません。プロトコルは、時間的順序と状態管理サービスを容易にするために、各トランザクションが永続的かつグローバルにユニークな方法で識別できるようにしなければなりません。
This section describes requirements for object management, including identification, registration, association, update, transfer, renewal, deletion, and query.
このセクションでは、識別、登録、関連、更新、移動、更新、削除、およびクエリを含むオブジェクト管理のための要件を記述する。
Some objects, such as name servers and contacts, have utility in multiple registries. However, maintaining disjoint copies of object information in multiple registries can lead to inconsistencies that have adverse consequences for the Internet. For example, changing a name server name in one registry, but not in a second registry that refers to the server for domain name delegation, can produce unexpected DNS query results.
そのようなネームサーバと連絡先、などの一部のオブジェクトは、複数のレジストリにおける有用性を有します。しかし、複数のレジストリ内のオブジェクト情報のばらばらのコピーを維持することは、インターネットのために不利な結果をもたらす矛盾につながることができます。例えば、一つのレジストリ内のネームサーバ名を変更しますが、ドメイン名の代表団のためにサーバーを指し、二レジストリで、予想外のDNSクエリの結果を生成することができません。
[1] The protocol MUST provide services to associate an object identifier with every object.
[1]プロトコルは、すべてのオブジェクトにオブジェクト識別子を関連付けるためにサービスを提供しなければなりません。
[2] Object identifiers MUST be globally unique.
[2]オブジェクト識別子はグローバルにユニークでなければなりません。
[3] An object's identifier MUST NOT change during the lifetime of the object in a particular repository, even if administrative control of the object changes over time.
[3]は、オブジェクトの識別子は、オブジェクトの管理制御が経時変化しても、特定のリポジトリ内のオブジェクトの存続期間中に変更してはいけません。
[4] An object identifier MUST contain information that unambiguously identifies the object.
[4]オブジェクト識別子は明白オブジェクトを識別する情報を含まなければなりません。
[5] Object identifier format specified by the protocol SHOULD be easily parsed and understood by humans.
[5]プロトコルによって指定されたオブジェクト識別子の形式は簡単に解析し、人間が理解されるべきです。
[6] An object's identifier MUST be generated and stored when an object is created.
[6]オブジェクトの識別子が生成され、オブジェクトが作成されるときに保存しなければなりません。
[1] The protocol MUST provide services to register Internet domain names.
[1]プロトコルは、インターネットドメイン名を登録するためのサービスを提供しなければなりません。
[2] The protocol MUST permit a starting and ending time for a domain name registration to be negotiated, thereby allowing a registry to implement policies allowing a range of registration validity periods (the start and end points in time during which one normally assumes that an object will be active), and enabling registrars to select a period for each registration they submit from within the valid range based on out-of-band negotiation between the registrar and the registrant. Registries SHOULD be allowed to accept indefinitely valid registrations if the policy that they are implementing permits, and to specify a default validity period if one is not selected by a registrar. Registries MUST be allowed to specify minimal validity periods consistent with prevailing or preferred practices for fee-for-service recovery. The protocol MUST provide features to ensure that both registry and registrar have a mutual understanding of the validity period at the conclusion of a successful registration event.
ドメイン名の登録は、それによって一つは正常と仮定している間、レジストリは、時間内の登録有効期間（開始点と終了点の範囲を可能にするポリシーを実装することができ、ネゴシエートするための[2]プロトコルは、開始および終了時間を許可する必要がありますオブジェクト）がアクティブであること、そしてそれらがレジストラと登録者との間のアウトオブバンドネゴシエーションに基づいて有効範囲内から送信する各登録期間を選択するレジストラを可能にするであろう。レジストリは、彼らが実装されているポリシーが許せば無期限に有効な登録を受け入れること、そして1がレジストラによって選択されていない場合、デフォルトの有効期間を指定することが許されるべきです。レジストリは有料のためのサービス復旧のための有力なまたは望ましい慣行と一致し、最小限の有効期間を指定することが許されなければなりません。プロトコルは、レジストリとレジストラの両方が成功した登録イベントの終了時に有効期間の相互理解を持っていることを確認するための機能を提供しなければなりません。
[3] The protocol MUST provide services to register name servers. Name server registration MUST NOT be limited to a specific period of time. Name servers MUST be registered with a valid IPv4 or IPv6 address when a "glue record" is required for delegation. A name server MAY be registered with multiple IP addresses. Multiple name servers using distinct server names MAY share an IP address.
[3]プロトコルは、ネームサーバを登録するためのサービスを提供しなければなりません。ネームサーバーの登録は、特定の期間に限定してはなりません。 「グルーレコードが」委任のために必要とされるときのネームサーバは、有効なIPv4またはIPv6アドレスに登録しなければなりません。ネームサーバは、複数のIPアドレスを登録することも可能です。個別のサーバー名を使用して、複数のネームサーバは、IPアドレスを共有する場合があります。
[4] The protocol MUST provide services to manage delegation of zone authority. Names of name servers MUST NOT be required to be tied to the name of the zone(s) for which the server is authoritative.
[4]プロトコルは、ゾーン権限委譲を管理するためのサービスを提供しなければなりません。ネームサーバの名前は、サーバーが権限を持つゾーン（複数可）の名前に拘束されることを必要としてはなりません。
[5] The protocol MUST provide services to register social information describing human and organizational entities. Registration of social information MUST NOT be limited to a specific period of time. Social information MAY include a name (individual name, organization name, or both), address (including street address, city, state or province (if applicable), postal code, and country), voice telephone number, email address, and facsimile telephone number.
[5]プロトコルは、人間や組織エンティティを記述し、社会の情報を登録するためのサービスを提供しなければなりません。社会的情報の登録は、特定の期間に限定してはなりません。社会情報は、音声電話番号、電子メールアドレス、およびファクシミリ電話（番地、市区町村、都道府県（該当する場合）、郵便番号、および国を含む）の名前（個人名、組織名、またはその両方）、アドレスを含んでいてもよいです数。
[6] Protocol services to register an object MUST be available to all authorized registrars.
[6]そのオブジェクトを登録するプロトコル・サービスは、すべての認可レジストラに利用可能でなければなりません。
[1] The protocol MUST provide services to associate name servers with domain names to delegate authority for zones. A domain name MAY have multiple authoritative name servers. Name servers MAY be authoritative for multiple zones.
[1]プロトコルは、ゾーンの権限を委任するために、ドメイン名とネームサーバを関連付けるためにサービスを提供しなければなりません。ドメイン名は、複数の権威ネームサーバを持っているかもしれません。ネームサーバは複数のゾーンに対して権限を持つかもしれ。
[2] The protocol MUST provide services to associate IP addresses with name servers. A name server MAY have multiple IP addresses. An IP address MAY be associated with multiple name server registrations.
[2]プロトコルは、ネームサーバとIPアドレスを関連付けるためにサービスを提供しなければなりません。ネームサーバは、複数のIPアドレスを持っているかもしれません。 IPアドレスは、複数のネームサーバの登録と関連付けられてもよいです。
[3] The protocol MUST provide services to associate social information with other objects. Social information associations MUST be identified by type. "Registrant" is an example social information type that might be associated with an object such as a domain name.
[3]プロトコルは、他のオブジェクトとの社会的情報を関連付けるためにサービスを提供しなければなりません。社会情報の関連付けはタイプによって識別されなければなりません。 「登録者」とは、ドメイン名としてオブジェクトに関連付けられている可能性があり、例えば、ソーシャル情報タイプがあります。
[4] The protocol MUST provide services to associate object management capabilities on a per-registrar basis.
[4]プロトコルごとの登録に基づいて関連付けるオブジェクト管理機能にサービスを提供しなければなりません。
[5] Some managed objects represent shared resources that might be referenced by multiple registrars. The protocol MUST provide services that allow a registrar to associate an existing shared resource object with other registered objects sponsored by a second registrar. For example, authority for the example.tld zone (example.tld domain object managed by registrar X) and authority for the test.tld zone (test.tld domain object managed by registrar Y) might be delegated to server ns1.example.tld (managed by registrar X). Registrar X maintains administrative control over domain object example.tld and server object ns1.example.tld, and registrar Y maintains administrative control over domain object test.tld. Registrar Y does not have administrative control over server object ns1.example.tld.
[5]いくつかの管理対象オブジェクトには、複数のレジストラが参照される可能性がある共有リソースを表します。プロトコルは、レジストラが第レジストラ主催他の登録されたオブジェクトと既存の共有リソース・オブジェクトを関連付けることができ、サービスを提供しなければなりません。例えば、（レジストラYによって管理test.tldドメインオブジェクト）example.tldゾーン（レジストラXが管理しexample.tldドメインオブジェクト）と権限test.tldゾーンのための権限は、サーバns1.example.tldに委任されることがあります（レジストラXによって管理）。レジストラXは、ドメインオブジェクトexample.tldとサーバーオブジェクトns1.example.tldに対する管理制御を維持し、レジストラYは、ドメインオブジェクトtest.tldに対する管理制御を維持します。レジストラYは、サーバーオブジェクトのns1.example.tldに対する管理制御を持っていません。
[1] The protocol MUST provide services to update information associated with registered Internet domain names.
[1]プロトコルは、登録されたインターネットドメイン名に関連付けられた情報を更新するサービスを提供しなければなりません。
[2] The protocol MUST provide services to update information associated with registered name servers.
[2]プロトコルは、登録ネームサーバに関連付けられている情報を更新するサービスを提供しなければなりません。
[3] The protocol MUST provide services to update social information associated with registered human and organizational entities.
[3]プロトコルが登録されているヒトと組織エンティティに関連付けられた社会的情報を更新するサービスを提供しなければなりません。
[4] The protocol MUST provide services to limit requests to update a registered object to the registrar that currently sponsors the registered object.
[4]プロトコルは、現在登録されているオブジェクトを後援レジストラに登録されたオブジェクトを更新するための要求を制限するようにサービスを提供しなければなりません。
[5] The protocol MUST provide services to explicitly reject unauthorized attempts to update a registered object.
[5]プロトコルは、明示的に登録されたオブジェクトを更新するための不正の試行を拒否するようにサービスを提供しなければなりません。
[1] The protocol MUST provide services to transfer domain names among authorized registrars. Name servers registered in a domain being transferred MUST be transferred along with the domain itself. For example, name servers "ns1.example.tld" and "ns2.example.tld" MUST be implicitly transferred when domain "example.tld" is transferred.
[1]プロトコルは、許可レジストラ間のドメイン名を転送するサービスを提供しなければなりません。転送されているドメインに登録されたネームサーバはドメイン自体と一緒に転送する必要があります。ドメイン「example.tld」が転送されている場合たとえば、ネームサーバ「ns1.example.tld」と「ns2.example.tldは、」暗黙的に転送する必要があります。
[2] The protocol MUST provide services to describe all objects, including associated objects, that are transferred as a result of an object transfer.
[2]プロトコルは、オブジェクト移動の結果として転送され、関連するオブジェクトを含むすべてのオブジェクトを記述するためにサービスを提供しなければなりません。
[3] The protocol MUST provide services to transfer social information objects among authorized registrars.
[3]プロトコルは、許可レジストラの間の社会的情報オブジェクトを転送するサービスを提供しなければなりません。
[4] Protocol transfer requests MUST be initiated by the registrar who wishes to become the new administrator of an object.
[4]プロトコル転送要求は、オブジェクトの新しい管理者になることを希望するレジストラによって開始されなければなりません。
[5] The protocol MUST provide services to confirm registrar authorization to transfer an object.
[5]プロトコルオブジェクトを転送するレジストラ許可を確認するためにサービスを提供しなければなりません。
[6] The protocol MUST provide services that allow the requesting registrar to cancel a requested object transfer before the request has been approved or rejected by the original sponsoring registrar. Requests to cancel the transfer of registered objects MUST be limited to the registrar that requested transfer of the registered object. Unauthorized attempts to cancel the transfer of a registered object MUST be explicitly rejected.
[6]プロトコルは、要求元のスポンサーレジストラによって承認または拒否される前に要求レジストラは、要求されたオブジェクトの転送をキャンセルすることを可能にするサービスを提供しなければなりません。登録されたオブジェクトの転送をキャンセルする要求は、登録されたオブジェクトの転送を要求したレジストラに限定されなければなりません。登録されたオブジェクトの転送をキャンセルする不正な試みは、明示的に拒絶しなければなりません。
[7] The protocol MUST provide services that allow the original sponsoring registrar to approve or reject a requested object transfer. Requests to approve or reject the transfer of registered objects MUST be limited to the registrar that currently sponsors the registered object. Unauthorized attempts to approve or reject the transfer of a registered object MUST be explicitly rejected.
[7]プロトコルは、元のスポンサーレジストラは、要求されたオブジェクトの転送を承認または拒否することを可能にするサービスを提供しなければなりません。登録されたオブジェクトの転送を承認または拒否するための要求は、現在、登録されたオブジェクトを後援レジストラに限定されなければなりません。登録されたオブジェクトの転送を承認または拒否する不正な試みは、明示的に拒絶しなければなりません。
[8] The protocol MUST provide services that allow both the original sponsoring registrar and the potential new registrar to monitor the status of both pending and completed transfer requests.
[8]プロトコルは、元のスポンサーレジストラと潜在的な新しいレジストラの両方が、保留中および完成転送要求のステータスを監視することを可能にするサービスを提供しなければなりません。
[9] Transfer of an object MAY extend the object's registration period. If an object's registration period will be extended as the result of a transfer, the new expiration date and time MUST be returned after successful completion of a transfer request.
[9]オブジェクトの移動は、オブジェクトの登録期間を延長することができます。オブジェクトの登録期間は、転送の結果として延長される場合は、新しい有効期限の日付と時刻は、転送要求が正常に完了した後に返されなければなりません。
[10] Requests to initiate the transfer of a registered object MUST be available to all authorized registrars.
登録されたオブジェクトの転送を開始するために[10]要求は、すべての承認レジストラに利用可能でなければなりません。
[11] Registrars might become non-functional and unable to respond to transfer requests. It might be necessary for one registrar to assume management responsibility for the objects associated with another registrar in the event of registrar failure. The protocol MUST NOT restrict the ability to transfer objects in the event of registrar failure.
[11]レジストラは、非機能や要求を転送するために対応ができなくなるかもしれません。 1つのレジストラは、レジストラ障害が発生した場合に、他のレジストラに関連付けられたオブジェクトの管理責任を負うことが必要になることがあります。プロトコルは、レジストラ障害が発生した場合にオブジェクトを転送する能力を制限してはいけません。
[1] The protocol MUST provide services to renew or extend the validity period of registered domain names. If applicable, the new expiration date and time MUST be returned after successful completion of a request to renew or extend the validity period.
[1]プロトコルは、更新または登録されたドメイン名の有効期間を延長するサービスを提供しなければなりません。該当する場合は、新しい有効期限は更新または有効期間を延長するための要求が正常に完了した後に返されなければなりません。
[2] Requests to renew or extend the validity period of a registered object MUST be limited to the registrar that currently sponsors the registered object. Unauthorized attempts to renew or extend the validity period of a registered object MUST be explicitly rejected.
[2]登録されたオブジェクトの有効期間を更新または拡張する要求は、現在登録されているオブジェクトを後援レジストラに制限されなければなりません。登録されたオブジェクトの有効期間を更新または延長する不正な試みは、明示的に拒絶しなければなりません。
[1] The protocol MUST provide services to remove a domain name from the registry.
[1]プロトコルは、レジストリからドメイン名を削除するためにサービスを提供しなければなりません。
[2] The protocol MUST provide services to remove a name server from the registry.
[2]プロトコルは、レジストリからネームサーバを削除するためにサービスを提供しなければなりません。
[3] The protocol MUST provide services to remove a social information object from the registry.
[3]プロトコルは、レジストリからソーシャル情報オブジェクトを削除するためにサービスを提供しなければなりません。
[4] Requests to remove a registered object MUST be limited to the registrar that currently sponsors the registered object. Unauthorized attempts to remove a registered object MUST be explicitly rejected.
[4]登録されたオブジェクトを削除する要求は、現在登録されているオブジェクトを後援レジストラに制限されなければなりません。登録されたオブジェクトを削除する不正な試みは、明示的に拒絶しなければなりません。
This section describes requirements for a lightweight query mechanism whose sole purpose is to determine if an object exists in a registry.
このセクションでは、唯一の目的のオブジェクトがレジストリに存在するかどうかを決定することである軽量なクエリメカニズムのための要件について説明します。
[1] The protocol MUST provide services to determine if a domain name exists in the registry. Domain names MUST be searchable by fully qualified name.
[1]プロトコルは、ドメイン名レジストリ内に存在するかどうかを決定するためにサービスを提供しなければなりません。ドメイン名は完全修飾名で検索でなければなりません。
[2] The protocol MUST provide services to determine if a name server exists in the registry. Name servers MUST be searchable by fully qualified name.
[2]プロトコルは、ネームサーバがレジストリ内に存在するかどうかを決定するためにサービスを提供しなければなりません。ネームサーバは完全修飾名で検索でなければなりません。
[3] The protocol MUST provide services to determine if a social information object exists in the registry. Social information MUST be searchable by a registry-unique identifier.
[3]プロトコルは、ソーシャル情報オブジェクトがレジストリ内に存在するかどうかを決定するためにサービスを提供しなければなりません。社会の情報は、レジストリ、一意の識別子によって検索可能でなければなりません。
[4] A query to determine if an object exists in the registry MUST return only a positive or negative response so that server software that responds to this query can be optimized for speed.
このクエリに応答するサーバーソフトウェアは、速度のために最適化することができるように、[4]オブジェクトがレジストリ内に存在するかどうかを判断するクエリは、正または負の応答を返さなければなりません。
[5] Requests to determine the existence of a registered object MUST be available to all authorized registrars.
[5]登録されたオブジェクトの存在を決定するための要求は、すべての承認レジストラに利用可能でなければなりません。
This section describes requirements for a query mechanism whose purpose is to provide detailed information describing objects that exist in a registry.
このセクションでは、目的のレジストリに存在するオブジェクトを記述した詳細な情報を提供することにあるクエリメカニズムの要件を記載しています。
[1] The protocol MUST provide services to retrieve information describing a domain name from the registry. Returned information MUST include the identifier of the current sponsoring registrar, the identifier of the registrar that originally registered the domain, the creation date and time, the expiration date and time (if any), the date and time of the last successful update (if any), the identifier of the registrar that performed the last update, the date and time of last completed transfer (if any), the current status of the domain, authorization information, identifiers describing social information associated with the domain, and the subordinate name servers registered in the domain. Authorization information MUST only be returned to the current sponsoring registrar.
[1]プロトコルは、レジストリからドメイン名を記述する情報を取得するためにサービスを提供しなければなりません。返される情報には、（もし現在のスポンサーレジストラの識別子、元々のドメインを登録したレジストラの識別子、作成日時、有効期限（もしあれば）、最後に成功した更新の日付と時刻を含まなければなりません任意）、最終更新、最後に完了した転送の日時（もしあれば）、ドメインの現在の状態、許可情報、ドメインに関連する社会的情報を記述する識別子を行うレジストラの識別子、及び下位名前サーバーは、ドメインに登録されました。認証情報は、現在のスポンサーのレジストラに戻す必要があります。
[2] The protocol MUST provide services to retrieve information describing a name server from the registry. Returned information MUST include the identifier of the current sponsoring registrar, the identifier of the registrar that originally registered the name server, the creation date and time, the date and time of the last successful update (if any), the identifier of the registrar that performed the last update, the date and time of last completed transfer (if any), and the IP addresses currently associated with the name server.
[2]プロトコルは、レジストリからネームサーバを記述する情報を取得するためにサービスを提供しなければなりません。返される情報は、現在のスポンサーレジストラの識別子、もともとネームサーバ、作成日時、最後に成功した更新の日時（もしあれば）、レジストラの識別子を登録レジストラの識別子を含まなければならないこと最終更新、最後に完了した転送（もしあれば）の日付と時刻、および現在のネームサーバに関連付けられたIPアドレスを行いました。
[3] The protocol MUST provide services to retrieve social information from the registry. Returned information MUST include identification attributes (which MAY include name, address, telephone numbers, and email address), the identifier of the registrar that originally registered the information, the creation date and time, the date and time of the last successful update (if any), the identifier of the registrar that performed the last update, the date and time of last completed transfer (if any), and authorization information. Authorization information MUST only be returned to the current sponsoring registrar.
[3]プロトコルは、レジストリからの社会的情報を取得するためのサービスを提供しなければなりません。情報があれば、もともとの情報を登録レジストラの識別子、作成日時、最後に成功した更新の日時（（名前、住所、電話番号、電子メールアドレスを含んでいてもよい）識別属性を含まなければならない返さ任意の）、最終更新、最後に完了した転送の日付と時刻（もしあれば）、および認証情報を行っレジストラの識別子。認証情報は、現在のスポンサーのレジストラに戻す必要があります。
[4] The protocol MUST provide services to identify all associated object references, such as name servers associated with domains (including delegations and hierarchical relationships) and contacts associated with domains. This information MUST be visible if the object associations have an impact on the success or failure of protocol operations.
[4]プロトコルは、（委任と階層関係を含む）ドメインとドメインに関連付けられた連絡先に関連付けられたネームサーバなどのすべての関連するオブジェクト参照を識別するためのサービスを提供しなければなりません。オブジェクトの関連付けは、プロトコル操作の成否に影響を与える場合は、この情報が表示されなければなりません。
[5] Requests to retrieve information describing a registered object MAY be granted by the registrar that currently sponsors the registered object. Unauthorized attempts to retrieve information describing a registered object MUST be explicitly rejected.
[5]登録されたオブジェクトを記述する情報を取得するための要求は、現在登録されているオブジェクトを後援レジストラによって付与することができます。登録されたオブジェクトを記述する情報を取得するための不正な試みは、明示的に拒絶しなければなりません。
[1] The protocol MUST provide status indicators that identify the operational state of a domain name. Indicators MAY be provided to identify a newly created state (the domain has been registered but has not yet appeared in a zone), a normal active state (the domain can be modified and is published in a zone), an inactive state (the domain can be modified but is not published in a zone because it has no authoritative name servers), a hold state (the domain can not be modified and is not published in a zone), a lock state (the domain can not be modified and is published in a zone), a pending transfer state, and a pending removal state.
[1]プロトコルは、ドメイン名の動作状態を識別するステータスインジケータを提供しなければなりません。指標は、非アクティブ状態（ドメイン、（ドメインを変更することができ、ゾーンで公開されている）通常のアクティブ状態、（ドメインが登録されているが、まだゾーンに現れていない）新しく作成された状態を識別するために設けられてもよいですロック状態では（ドメインが変更していることができない、（ドメインを変更することはできませんし、ゾーンで公開されていない）保留状態、修正することができますが、それは何の権威ネームサーバを持っていないので）ゾーンで公開されていません）ゾーンに発表され、保留転送状態、および保留中の除去状態。
[2] If provided, protocol indicators for hold and lock status MUST allow independent setting by both registry and registrar.
提供される場合、[2]、保持ロック状態のためのプロトコルインジケータは、レジストリおよびレジストラの両方によって独立設定を可能にしなければなりません。
[3] A domain MAY have multiple statuses at any given time. Some statuses MAY be mutually exclusive.
[3]ドメインは、任意の時点で複数の状態があるかもしれません。いくつかの状況は、相互に排他的である場合があります。
[1] The protocol MUST provide services that unambiguously note the success or failure of every transaction. Individual success and error conditions MUST be noted distinctly.
[1]プロトコルは、明確にすべてのトランザクションの成功または失敗を注意してサービスを提供しなければなりません。個々の成功とエラー条件が明らかに留意しなければなりません。
External interfaces define the interaction points between a system and entities that communicate with the system. Specific areas of interest include user interfaces, hardware interfaces, software interfaces, and communications interfaces.
外部インタフェースは、システムと通信システムとエンティティ間の相互作用点を規定します。関心のある特定の領域は、ユーザインターフェイス、ハードウェアインタフェース、ソフトウェアインタフェース、および通信インタフェースを含みます。
[1] The protocol MUST define a wire format for data exchange, not an application design for user, hardware, or software interfaces so that any application able to create the same bits on the wire, and to maintain the image of the same integrity constraints, is a valid implementation of the protocol.
[1]プロトコルは、データ交換、ユーザ、ハードウェア、またはソフトウェアインターフェイスのないアプリケーション設計用のワイヤフォーマットを定義する必要があるように、ワイヤに同じビットを作成し、同じ整合性制約の画像を維持することができる任意のアプリケーション、プロトコルの有効な実装です。
[1] Registries, registrars, and registrants interact using a wide spectrum of communications interfaces built upon multiple protocols, including transport layer protocols such as TCP and application layer protocols such as SMTP. The protocol MUST only be run over IETF approved protocols that feature congestion control, such as TCP and SCTP.
[1]レジストリ、レジストラ、および登録は、TCPなどのトランスポート層プロトコルおよびSMTPなどのアプリケーション層プロトコルを含む複数のプロトコル上に構築された通信インタフェースの広いスペクトルを用いて相互作用します。 IETFは、TCPやSCTPなどの輻輳制御を備えていますプロトコルを承認した上でプロトコルにのみ実行する必要があります。
[1] Run-time performance is an absolutely critical aspect of protocol usability. While performance is very heavily dependent on the hardware and software architecture that implements a protocol, protocol features can have a direct impact on the ability of the underlying architecture to provide optimal performance. The protocol MUST be usable in both high volume and low volume operating environments.
[1]ファイル名を指定して実行時のパフォーマンスは、プロトコルユーザビリティの絶対的に重要な側面です。パフォーマンスは、プロトコルを実装したハードウェアおよびソフトウェアアーキテクチャに非常に大きく依存しているが、プロトコル機能は、最適なパフォーマンスを提供するために、基本的なアーキテクチャの能力に直接影響を与えることができます。プロトコルは、大量かつ低容量運転環境の両方で使用可能でなければなりません。
Protocol designers need to be aware of issues beyond functional and interface requirements when balancing protocol design decisions. This section describes additional factors that might have an impact on protocol design, including standards compliance and hardware limitations.
プロトコルの設計者は、プロトコル設計上の決定のバランスをとる機能とインタフェースの要件を超えた問題に注意する必要があります。このセクションでは、標準準拠とハードウェアの制限などのプロトコルの設計に影響を与える可能性がある追加の要因を、説明しています。
[1] The protocol MUST conform to current IETF standards. Standards for domain and host name syntax, IP address syntax, security, and transport are particularly relevant. Emerging standards for the Domain Name System MUST be considered as they approach maturity.
[1]プロトコルは、現在IETF標準に準拠しなければなりません。ドメインとホスト名の構文、IPアドレスの構文、セキュリティ、および輸送のための基準は、特に関連します。彼らは成熟に近づくとドメインネームシステムのための新しい標準を考えなければなりません。
[2] The protocol MUST NOT reinvent services offered by lower layer protocol standards. For example, the use of a transport that provides reliability is to be chosen over use of a non-reliable transport with the protocol itself using retransmission to achieve reliability.
[2]プロトコルは、下位層プロトコル標準で提供されるサービスを改革してはなりません。例えば、信頼性を提供するトランスポートを使用することは、信頼性を達成するために、再送信を使用して、プロトコル自体と非信頼性の高いトランスポートを使用するより選択されます。
[1] The protocol MUST NOT define any features that preclude hardware independence.
[1]プロトコルは、ハードウェアの独立性を排除する任意の機能を定義してはいけません。
Elements of service beyond functional and interface requirements are essential factors to consider as part of a protocol design effort. This section describes several important service elements to be addressed by protocol designers, including reliability, availability, scalability, maintainability, extensibility, and security.
機能とインタフェースの要件を超えたサービスの要素は、プロトコル設計努力の一環として検討するために不可欠な要素です。このセクションでは、信頼性、可用性、拡張性、保守性、拡張性、セキュリティなどのプロトコルデザイナーによって対処すべきいくつかの重要なサービスの要素について説明します。
[1] Reliability is a measure of the extent to which a protocol provides a consistent, dependable level of service. Reliability is an important attribute for a domain name management protocol. An unreliable protocol increases the risk of data exchange errors, which at one extreme can have a direct impact on protocol usability and at the other extreme can introduce discontinuity between registry and registrar data stores. The protocol MUST include features that maximize reliability at the application protocol layer. Services provided by underlying transport, session, and presentation protocols SHOULD also be considered when addressing application protocol reliability.
[1]信頼性プロトコルは、サービスの一貫性、信頼性レベルを提供する程度の尺度です。信頼性は、ドメイン名の管理プロトコルのための重要な属性です。信頼性のないプロトコルは、一方の極端でプロトコル・ユーザビリティに直接的な影響を有することができ、他の極端にレジストリとレジストラデータストアとの間の不連続性を導入することができるデータ交換エラーのリスクを増加させます。プロトコルは、アプリケーションプロトコル層での信頼性を最大化するための機能を含まなければなりません。アプリケーションプロトコルの信頼性に取り組む際に基礎となるトランスポート、セッション、およびプレゼンテーション・プロトコルによって提供されるサービスも考慮する必要があります。
[2] The protocol MUST be run over the most reliable transport option available in a given environment. The protocol MUST NOT implement a service that is otherwise available in an applicable standard transport.
[2]プロトコルは、与えられた環境で利用可能な最も信頼性の高いトランスポートオプションの上に実行する必要があります。プロトコルは、適用規格輸送にそうでない場合は利用可能なサービスを実装してはなりません。
[3] Default protocol actions for when a request or event times out MUST be well defined.
[3]要求またはイベントがタイムアウトが明確に定義されなければならない場合のデフォルトのプロトコルアクションを。
[1] Availability is a measure of the extent to which the services provided by a protocol are accessible for an intended use. Availability of an application layer protocol is primarily dependent on the software and hardware systems that implement the protocol.
[1]の状況は、プロトコルによって提供されるサービスは、意図された使用のためにアクセス可能である程度の尺度です。アプリケーション層プロトコルの利用可能性は、プロトコルを実装するソフトウェアおよびハードウェアシステムに主に依存しています。
The protocol MUST NOT include any features that impinge on the underlying availability of the software and hardware systems needed to service the protocol.
プロトコルは、プロトコルにサービスを提供するために必要なソフトウェアとハードウェアのシステムの基本的な可用性に衝突するすべての機能を含んではいけません。
[1] Scalability is a measure of the extent to which a protocol can accommodate use growth while preserving acceptable operational characteristics. The protocol MUST be capable of operating at an acceptable level as the load on registry and registrar systems increases.
[1]スケーラビリティは、許容可能な動作特性を維持しながら、プロトコルが使用成長を収容することができる程度の尺度です。プロトコルは、レジストリおよびレジストラシステム増加の負荷として許容されるレベルで動作可能でなければなりません。
[1] Maintainability is a measure of the extent to which a protocol can be adapted or modified to address unforeseen operational needs or defects. The protocol SHOULD be developed under the nominal working group processes of the IETF to provide a well-known mechanism for ongoing maintenance.
〔1〕保守プロトコルが予期せぬ動作ニーズや欠陥に対処するように適合または改変することができる程度の尺度です。プロトコルは、継続的なメンテナンスのための周知の機構を提供するために、IETFの公称ワーキンググループのプロセスの下で開発されるべきです。
[1] Extensibility is a measure of the extent to which a protocol can be adapted for future uses that were not readily evident when the protocol was originally designed. The protocol SHOULD provide features that at a minimum allow for the management of new object types without requiring revisions to the protocol itself.
[1]拡張プロトコルは、プロトコルが最初に設計された場合には容易に明らかではなかった将来の用途に適合させることができる程度の尺度です。プロトコルは、最低でプロトコル自体への修正を必要とせずに新しいオブジェクトタイプの管理を可能にする機能を提供すべきです。
[2] The requirements described in this document are not intended to limit the set of objects that might be managed by the protocol. The protocol MUST include features that allow extension to object types that are not described in this document.
[2]この文書で説明した要件は、プロトコルによって管理されるかもしれないオブジェクトのセットを限定するものではありません。プロトコルは、この文書に記載されていない種類のオブジェクトへの拡張を可能にする機能を含まなければなりません。
[3] The protocol MUST provide an optional field within all commands whose format and use will be controlled by individual registry policy.
[3]プロトコルは、その形式及び使用個々のレジストリポリシーによって制御されるすべてのコマンド内の任意のフィールドを提供しなければなりません。
[1] Transactional privacy and integrity services MUST be available at some protocol layer.
[1]トランザクションのプライバシーと整合性サービスは、いくつかのプロトコル層で使用可能でなければなりません。
[2] This document describes requirements for basic user identification and authentication services. A generic protocol MAY include additional security services to protect against the attacks described here. A generic protocol MUST depend on other-layered protocols to provide security services that are not provided in the generic protocol itself. A generic protocol that relies on security services from other-layered protocols MUST specify the protocol layers needed to provide security services.
[2]この文書では、基本的なユーザ識別および認証サービスのための要件について説明します。汎用プロトコルは、ここで説明された攻撃から保護するために、追加のセキュリティサービスを含むかもしれません。一般的なプロトコルは、一般的なプロトコル自体で提供されていないセキュリティサービスを提供するために、他の層のプロトコルに依存しなければなりません。他の層のプロトコルからのセキュリティサービスに依存している汎用的なプロトコルは、セキュリティサービスを提供するために必要なプロトコル層を指定しなければなりません。
Certain aspects of anticipated operational environments have to be considered when designing a generic registry-registrar protocol. Areas of concern include database operations, operations, site adaptation, and data collection.
予想される運用環境の特定の態様は、一般的なレジストリ・レジストラプロトコルを設計する際に考慮しなければなりません。気になる部分には、データベース操作、運用、サイトの適応、およびデータ収集が含まれています。
[1] The protocol MUST NOT have any database dependencies. However, efficient use of database operations and resources has to be considered as part of the protocol design effort. The protocol SHOULD provide atomic features that can be efficiently implemented to minimize database load.
[1]プロトコルは、任意のデータベースの依存性を有してはなりません。しかし、データベース操作や資源の有効利用は、プロトコル設計努力の一環として考慮しなければなりません。プロトコルは、効率的に、データベースの負荷を最小限にするために実装することができるアトミックな機能を提供するべきです。
[1] Registry-registrar interactions at the protocol level SHOULD operate without human intervention. However, intermediate services that preserve the integrity of the protocol MAY be provided. For example, an intermediate service that determines if a registrant is authorized to register a name in a name space can be provided.
[1]プロトコルレベルでレジストリレジストラの相互作用は、人間の介入なしに動作しなければなりません。しかし、プロトコルの整合性を保つ中間のサービスが提供されてもよいです。例えば、登録者が名前空間に名前を登録することを許可されているかどうかを決定する中間サービスを提供することができます。
[2] The protocol MUST provide services that allow clients and servers to maintain a consistent understanding of the current date and time to effectively manage objects with temporal properties.
[2]プロトコルは、クライアントとサーバーが効果的に時間的な特性を持つオブジェクトを管理するために、現在の日付と時刻の一貫した理解を維持することを可能にするサービスを提供しなければなりません。
[1] Registries and registrars have varying business and operational requirements. Several factors, including governance standards, local laws, customs, and business practices all play roles in determining how registries and registrars are operated. The protocol MUST be flexible enough to operate in diverse registry-registrar environments.
[1]レジストリとレジストラが、ビジネスや運用要件を変化させてきました。ガバナンス基準、現地の法律、慣習、およびビジネス慣行を含むいくつかの要因が、すべてのレジストリとレジストラを操作する方法を決定する際に役割を果たしています。プロトコルは、多様なレジストリ・レジストラ環境で動作するために十分に柔軟でなければなりません。
[1] Some of the data exchanged between a registrar and registry might be considered personal, private, or otherwise sensitive. Disclosure of such information might be restricted by laws and/or business practices. The protocol MUST provide services to identify data collection policies.
[1]レジストラとレジストリとの間で交換されるデータの一部は、個人のプライベート、またはその他の機密とみなされる可能性があります。そのような情報の開示が法令および/またはビジネス慣行によって制限される可能性があります。プロトコルは、データ収集ポリシーを識別するためのサービスを提供しなければなりません。
[2] Some of the social information exchanged between a registrar and registry might be required to create, manage, or operate Internet or DNS infrastructure facilities, such as zone files. Such information is subject to public disclosure per relevant IETF standards.
[2]レジストラとレジストリの間でやり取り社会的情報の一部は、作成、管理、またはそのようなゾーンファイルとして、インターネットやDNSインフラ施設を、動作させるために必要になることがあります。このような情報は、関連するIETF標準あたり情報公開の対象となります。
[1] [RFC1035] describes Internet host and domain names using characters traditionally found in a subset of the 7-bit US-ASCII character set. More recent standards, such as [RFC2130] and [RFC2277], describe the need to develop protocols for an international Internet. These and other standards MUST be considered during the protocol design process to ensure world-wide usability of a generic registry registrar protocol.
[1] [RFC1035]は、伝統的に7ビットUS-ASCII文字セットのサブセットで見つかった文字を使用してインターネットホスト名およびドメイン名を記述する。そのような[RFC2130]と[RFC2277]などのより最近の基準は、国際的なインターネットのためのプロトコルを開発する必要性を説明します。これらおよび他の基準は、一般的なレジストリレジストラプロトコルの世界的な使いやすさを確保するために、プロトコルの設計プロセスの間に考えなければなりません。
[2] The protocol MUST allow exchange of data in formats consistent with current international agreements for the representation of such objects. In particular, this means that addresses MUST include country, that telephone numbers MUST start with the international prefix "+", and that appropriate thought be given to the usability of information in both local and international contexts. This means that some elements (like names and addresses) might need to be represented multiple times, or formatted for different contexts (for instance English/French in Canada, or Latin/ideographic in Japan).
[2]プロトコルは、このようなオブジェクトの表現のための現在の国際協定と一致するフォーマットでデータの交換を可能にしなければなりません。特に、これはアドレスが国を含まなければならないことを、その電話番号は、ローカルおよび国際的な文脈の両方で情報のユーザビリティに与えられる国際的な接頭辞「+」、およびその適切な考えで始めなければならないことを意味します。これは、（名前や住所などの）いくつかの要素が複数回表され、または（カナダのインスタンス英語/フランス語のため、または日本でのラテン/表意文字）異なるコンテキスト用にフォーマットする必要があることを意味します。
[3] All date and time values specified in a generic registry-registrar protocol MUST be expressed in Universal Coordinated Time. Dates and times MUST include information to represent a four-digit calendar year, a calendar month, a calendar day, hours, minutes, seconds, fractional seconds, and the time zone for Universal Coordinated Time. Calendars apart from the Gregorian calendar MUST NOT be used
[3]一般的なレジストリレジストラプロトコルで指定されたすべての日付と時刻の値は、協定世界時で表されなければなりません。日付と時刻は、4桁の暦年、暦月、カレンダーの日、時間、分、秒、秒の小数、と協定世界時の時間帯を表すための情報を含まなければなりません。離れグレゴリオ暦のカレンダーを使用してはいけません
This document does not require any action on the part of IANA. Protocol specifications that require IANA action MUST follow the guidelines described in [RFC2434].
この文書は、IANAの一部上の任意のアクションを必要としません。 IANAのアクションを必要とするプロトコル仕様は、[RFC2434]で説明したガイドラインに従わなければなりません。
Security services, including confidentiality, authentication, access control, integrity, and non-repudiation SHOULD be applied to protect interactions between registries and registrars as appropriate. Confidentiality services protect sensitive exchanged information from inadvertent disclosure. Authentication services confirm the claimed identity of registries and registrars before engaging in online transactions. Access control services control access to data and services based on identity. Integrity services guarantee that exchanged data has not been altered between the registry and the registrar. Non-repudiation services provide assurance that the sender of a transaction can not deny being the source of the transaction, and that the recipient cannot deny being the receiver of the transaction.
機密性、認証、アクセス制御、完全性、否認防止などのセキュリティサービスは、適切なレジストリとレジストラの間の相互作用を保護するために適用されるべきです。機密性サービスは、不注意による開示から機密交換される情報を保護します。認証サービスは、オンライン取引に従事する前に、レジストリとレジストラ主張身元を確認します。アイデンティティに基づいてデータやサービスへのアクセス制御サービスのアクセスを制御します。データをやり取り整合性サービス保証は、レジストリとレジストラ間で変更されていません。否認防止サービスは、トランザクションの送信者がトランザクションのソースであることを否定することはできませんという保証を提供し、受信者は、トランザクションの受信機であることを否定することはできませんことを。
This document was originally written as an individual submission Internet-Draft. The provreg working group later adopted it as a working group document and provided many invaluable comments and suggested improvements. The author wishes to acknowledge the efforts of WG chairs Edward Lewis and Jaap Akkerhuis for their process and editorial contributions.
この文書は、もともと個々の提出インターネットドラフトとして書かれていました。 provregワーキンググループは、後にワーキンググループ文書としてそれを採用し、多くの貴重なコメントを提供し、改善を提案しました。著者は彼らのプロセスと編集の貢献のためのWGの議長エドワード・ルイスとヤープAkkerhuisの努力を認めることを望みます。
Specific comments that helped guide development of this document were provided by Harald Tveit Alvestrand, Christopher Ambler, Karl Auerbach, Jorg Bauer, George Belotsky, Eric Brunner-Williams, Jordyn Buchanan, Randy Bush, Bruce Campbell, Dan Cohen, Andre Cormier, Kent Crispin, Dave Crocker, Ayesha Damaraju, Lucio De Re, Mats Dufberg, Peter Eisenhauer, Sheer El-Showk, Urs Eppenberger, Patrik Faltstrom, Paul George, Patrick Greenwell, Jarle Greipsland, Olivier Guillard, Alf Hansen, Paul Hoffman, Paul Kane, Shane Kerr, Elmar Knipp, Mike Lampson, Matt Larson, Ping Lu, Klaus Malorny, Bill Manning, Michael Mealling, Patrick Mevzek, Peter Mott, Catherine Murphy, Martin Oldfield, Geva Patz, Elisabeth Porteneuve, Ross Wm. Rader, Budi Rahardjo, Annie Renard, Scott Rose, Takeshi Saigoh, Marcos Sanz, Marcel Schneider, J. William Semich, James Seng, Richard Shockey, Brian Spolarich, William Tan, Stig Venaas, Herbert Vitzthum, and Rick Wesson.
このドキュメントの発展を導く助けた具体的なコメントはハラルド・トバイット・アルベストランド、クリストファー・アンブラー、カール・アウエルバッハ、ヨルグ・バウアー、ジョージBelotsky、エリック・ブルンナー - ウィリアムズ、Jordynブキャナン、ランディブッシュ、ブルース・キャンベル、ダン・コーエン、アンドレ・コーミア、ケントクリスピンによって提供されました、デイブ・クロッカー、AyeshaさんDamaraju、ルシオ・デ・再、マットDufberg、ピーターEisenhauer、シアーエルShowk、ウルスEppenberger、パトリックFaltstrom、ポール・ジョージ、パトリック・グリーンウェル、Jarle Greipsland、オリヴィエ・ギラード、アルフ・ハンセン、ポール・ホフマン、ポール・ケイン、シェーンカー、エルマーKnipp、マイク・Lampson、マット・ラーソン、Pingの呂、クラウスMalorny、ビル・マニング、マイケル・メオーリング、パトリックMevzek、ピーター・モット、キャサリン・マーフィー、マーティン・オールドフィールド、GEVAパッツ、エリザベスPorteneuve、ロス・ウィリアム。レイダー、ブディRahardjo、アニー・ルナール、スコット・ローズ、武Saigoh、マルコス・サンス、マルセル・シュナイダー、J.ウィリアムSemich、ジェームズ・ハンセン、リチャードショッキー、ブライアンSpolarich、ウィリアム・タン、スティグVenaas、ハーバートVitzthum、そしてリックウェッソン。
Normative References:
引用規格：
[RFC2119] Bradner, S., "Key Words for Use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[RFC2434] Narten氏、T.とH. Alvestrand、 "RFCsにIANA問題部に書くためのガイドライン"、BCP 26、RFC 2434、1998年10月。
Informative References:
参考文献：
[RFC1035] Mockapetris, P., "Domain Names - Implementation and Specification", STD 13, RFC 1035, November 1987.
[RFC1035] Mockapetris、P.、 "ドメイン名 - 実装と仕様"、STD 13、RFC 1035、1987年11月。
[RFC2130] Weider, C., Preston, C., Simonsen, K., Alvestrand, H., Atkinson, R., Cripsin, M. and P. Svanberg, "The Report of the IAB Character Set Workshop", RFC 2130, April 1997.
[RFC2130]ウイダー、C.、プレストン、C.、シモンセン、K.、Alvestrand、H.、アトキンソン、R.、Cripsin、M.およびP. Svanberg、 "ワークショップセットIAB文字の報告"、RFC 2130 、1997年4月。
[RFC2277] Alvestrand, H., "IETF Policy on Character Sets and Languages", BCP 18, RFC 2277, January 1998.
[RFC2277] Alvestrand、H.、 "文字セットと言語のIETF方針"、BCP 18、RFC 2277、1998年1月。
Scott Hollenbeck VeriSign Global Registry Services 21345 Ridgetop Circle Dulles, VA 20166-6503 USA
スコットホレンベックベリサイングローバル・レジストリサービス21345のRidgetopサークルダレス、バージニア州20166から6503 USA
EMail: shollenbeck@verisign.com
メールアドレス：shollenbeck@verisign.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 Editor機能のための基金は現在、インターネット協会によって提供されます。