RFC3375 日本語訳
3375 Generic Registry-Registrar Protocol Requirements. S. Hollenbeck. September 2002. (Format: TXT=46022 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group S. Hollenbeck Request for Comments: 3375 Verisign, Inc. Category: Informational September 2002
Hollenbeckがコメントのために要求するワーキンググループS.をネットワークでつないでください: 3375年のVerisign Inc.カテゴリ: 情報の2002年9月
Generic Registry-Registrar Protocol Requirements
ジェネリック登録記録係プロトコル要件
Status of this Memo
この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.
Copyright(C)インターネット協会(2002)。 All rights reserved。
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"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTは[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
1. 序論… 2 1.1の定義、頭文字語、および略語… 2 2. 一般記述… 4 2.1 システム見解… 4 2.2システムは機能します… 4 2.3 ユーザの特性… 5 2.4の仮定… 5 3. 機能条件書… 5 3.1 セッション管理… 6 3.2の識別と認証… 6 3.3 トランザクション識別… 7 3.4 経営者側は反対します… 7 3.5 ドメイン自動運転表示灯… 13
Hollenbeck Informational [Page 1] RFC 3375 Generic RRP Requirements September 2002
[1ページ]RFC3375ジェネリック小売希望価格要件2002年9月の情報のHollenbeck
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
3.6 トランザクション完成状態… 13 4. 外部のインターフェース要件… 14 4.1ユーザ、ハードウェア、およびソフトウェアは連結します… 14 4.2のコミュニケーションインタフェース… 14 5. パフォーマンス要件… 14 6. 規制を設計してください… 14 6.1 規格コンプライアンス… 14 6.2 ハードウェア制限… 15 7. 属性を修理してください… 15 7.1の信頼性… 15 7.2の有用性… 15 7.3スケーラビリティ… 16 7.4の保守性… 16 7.5伸展性… 16 7.6セキュリティ… 16 8. 他の要件… 17 8.1 データベース要件… 17 8.2の操作上の要件… 17 8.3 サイト適合要件… 17 8.4 データ収集要件… 17 9. 国際化要件… 18 10. IANA問題… 18 11. セキュリティ問題… 18 12. 承認… 19 13. 参照… 19 14. エディタのアドレス… 20 15. 完全な著作権宣言文… 21
1. Introduction
1. 序論
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.
共有されたドメイン名登録制の到来は登録記録係相互作用のために一般的なジェネリックプロトコルに関するユーティリティを例証します。 標準のジェネリックプロトコルで、操作上の複雑さを減少させて、記録係は一般的なインタフェースを通って複数の登録で交信できるでしょう。 このドキュメントは登録記録係操作に適したプロトコルに食糧を供給するジェネリックのための機能的、そして、インタフェースの高い平らな要件について説明します。 詳細な技術的要求事項は本書では扱われません。
1.1 Definitions, Acronyms, and Abbreviations
1.1 定義、頭文字語、および略語
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に関する例です。
Hollenbeck Informational [Page 2] RFC 3375 Generic RRP Requirements September 2002
[2ページ]RFC3375ジェネリック小売希望価格要件2002年9月の情報のHollenbeck
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
小売希望価格: 登録記録係プロトコル
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: トップ・レベル・ドメイン。 総称は以前はよくドメイン名階層構造のトップレベル根の下で存在するgTLDsとccTLDsの両方について説明していました。
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).
排他的な登録制: 登録サービスが独身の記録係に制限されるドメイン名登録制。 排他的なRegistration Systemsは緩く結合されるか(その場合、登録と記録係システムの間の分離は容易に明白です)、またはしっかり結合されます(その場合、登録と記録係システムの間の分離は不鮮明です)。
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.
共有された登録制: 登録サービスが複数の独立している記録係の中で共有されるドメイン名登録制。 共有されたRegistration Systemsは記録係と登録の間の疎結合を必要とします。
Hollenbeck Informational [Page 3] RFC 3375 Generic RRP Requirements September 2002
[3ページ]RFC3375ジェネリック小売希望価格要件2002年9月の情報のHollenbeck
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]で完全に説明されます。
2. General Description
2. 概説
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.
ドメイン名登録制の基本的了解事項はプロトコルがそれらのシステムに役立つという機能的、そして、インタフェース要件の列挙に焦点を提供します。このセクションは、後で本書では特定された要件に文脈を提供するためにドメイン名登録制の高値レベル記述を提供します。
2.1 System Perspective
2.1 システム見解
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.
ドメイン名登録制は記録係が登録によって管理された名前空間の中でインターネットドメイン名前登録サービスを提供するのを可能にするプロトコル、関連ソフトウェア、およびハードウェアから成ります。 複数の競争している記録係の中で登録制を共有できますか、またはしっかりか緩くバックエンド登録サービスに結びつけられる独身の記録係はそれに勤めることができます。 .com、.net、および.org gTLDsに登録サービスを供給するシステムは複数の競争している記録係に役立つ共有された登録制に関する例です。 いくつかのccTLDs、.gov、および.mil gTLDsに登録サービスを供給するシステムは独身の記録係によって役立たれた登録制に関する例です。
2.2 System Functions
2.2 システム機能
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がそれが役立つ名前空間のためのゾーンファイルであると生成します。 ゾーンファイルは、ドメイン名システムの基礎を提供する一連のネームサーバに、作成されて、分配されます。
Hollenbeck Informational [Page 4] RFC 3375 Generic RRP Requirements September 2002
[4ページ]RFC3375ジェネリック小売希望価格要件2002年9月の情報のHollenbeck
2.3 User Characteristics
2.3 ユーザの特性
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つの広いカテゴリになります: プロトコルクライアント実装を使用する実体と中間的サービスを提供するなら実体がクライアントとサーバサービスの両方を提供できますが、プロトコルサーバ実装を使用する実体。 プロトコルは、実体を伝えながら、これらの間に疎結合を提供します。
2.4 Assumptions
2.4 仮定
There is one and only one registry that is authoritative for a given name space and zone.
唯一無二の1つの名スペースとゾーンに、正式の登録があります。
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.
1つ以上の名前スペースとゾーンに、登録は正式である場合があります。 いくつかの登録操作が支払い請求可能である場合があります。 記録係が支払い請求可能な操作を実行する前に詳細な情報を得た上での決断をすることができる非支払い請求可能な操作の仕様で支払い請求可能な操作の影響を緩和できます。
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.
本書では説明された要件が登録記録係が議定書の中で述べるジェネリックで対処できるオブジェクトのセットを制限することを意図しません。
3. Functional Requirements
3. 機能条件書
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.
このセクションは登録記録係プロトコルのための機能条件書について説明します。 このドキュメントのための範囲の外に会われるこれらの要件がことである方法を説明する技術的要求事項があります。
Hollenbeck Informational [Page 5] RFC 3375 Generic RRP Requirements September 2002
[5ページ]RFC3375ジェネリック小売希望価格要件2002年9月の情報のHollenbeck
3.1 Session Management
3.1 セッション管理
[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] プロトコルは、セッションが早まって中止されるなら取引が完了されたと確認するためにサービスを提供しなければなりません。
3.2 Identification and Authentication
3.2 識別と認証
[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] プロトコルか別の層にされたプロトコルが、クライアントとサーバの両方に許容できる認証機構を交渉するためにサービスを提供しなければなりません。
Hollenbeck Informational [Page 6] RFC 3375 Generic RRP Requirements September 2002
[6ページ]RFC3375ジェネリック小売希望価格要件2002年9月の情報のHollenbeck
3.3 Transaction Identification
3.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] オブジェクトを作成するか、変更するか、または削除する登録操作は登録ユニークな識別子に関連しているに違いありません。 プロトコルは、各トランザクションが時の注文と州の経営指導を容易にするために永久的でグローバルにユニークな方法で特定されるのを許容しなければなりません。
3.4 Object Management
3.4 オブジェクト管理
This section describes requirements for object management, including identification, registration, association, update, transfer, renewal, deletion, and query.
このセクションは識別、登録、協会、アップデート、転送、更新、削除、および質問を含むオブジェクト管理のための要件について説明します。
3.4.1 Object Identification
3.4.1 オブジェクト識別
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.
ネームサーバや接触などのいくつかのオブジェクトが複数の登録にユーティリティを持っています。 しかしながら、複数の登録でオブジェクト情報のコピーをばらばらにならせるように主張するのがインターネットへの不利な結果を持っている矛盾に通じることができます。 例えば、ドメイン名委譲についてサーバを示す2番目の登録で変えるのではなく、1つの登録でネームサーバ名を変えて、予期していなかった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] オブジェクト識別子形式は容易に分析されて、人間に解釈されたプロトコルSHOULDで指定しました。
[6] An object's identifier MUST be generated and stored when an object is created.
[6] オブジェクトが作成されるとき、オブジェクトの識別子を生成されて、保存しなければなりません。
Hollenbeck Informational [Page 7] RFC 3375 Generic RRP Requirements September 2002
[7ページ]RFC3375ジェネリック小売希望価格要件2002年9月の情報のHollenbeck
3.4.2 Object Registration
3.4.2 オブジェクト登録
[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] プロトコルは交渉されて、その結果、登録が政策を実施するのを許容することへのドメイン名登録のためのさまざまな登録有効期間(時間内にの通常、どれが、オブジェクトが活性になると仮定するか間、始めとエンドポイント)を許容する始めと終了時刻を可能にしなければなりません、そして、記録係が彼らが有効枠から提出する各登録のために期間を選択するのを可能にするのが記録係と記入者の間でバンドの外の交渉を基礎づけました。 登録SHOULD、それらが実施している政策が可能にして、記録係が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] プロトコルは、人間の、そして、組織的な実体について説明する社会情報を登録するためにサービスを提供しなければなりません。 特定の期間まで社会情報の登録を制限してはいけません。 社会情報は名前(個人名、組織名、または両方)、アドレス(住所か都市か州か州(適切であるなら)と、郵便番号と、国を含んでいる)、声の電話番号、Eメールアドレス、およびファクシミリ電話番号を含むかもしれません。
[6] Protocol services to register an object MUST be available to all authorized registrars.
[6] すべての認可された記録係にとって、オブジェクトを登録するプロトコルサービスは利用可能であるに違いありません。
Hollenbeck Informational [Page 8] RFC 3375 Generic RRP Requirements September 2002
[8ページ]RFC3375ジェネリック小売希望価格要件2002年9月の情報のHollenbeck
3.4.3 Object Association
3.4.3 オブジェクト協会
[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] プロトコルは、1記録係あたり1個のベースでオブジェクト管理能力を関連づけるためにサービスを提供しなければなりません。
[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] いくつかの管理オブジェクトが複数の記録係によって参照をつけられるかもしれない共用資源を表します。 プロトコルは記録係が2番目の記録係によって後援される他の登録されたオブジェクトに既存の共用資源オブジェクトを関連づけることができるサービスを提供しなければなりません。 例えば、example.tldゾーンへの権威(記録係Xによって管理されたexample.tldドメインオブジェクト)とtest.tldゾーンへの権威(記録係Yによって管理されたtest.tldドメインオブジェクト)をサーバns1.example.tldへ代表として派遣するかもしれません(記録係Xによって管理されます)。 記録係Xはドメインオブジェクトexample.tldとサーバオブジェクトns1.example.tldの上の運営管理コントロールを維持します、そして、記録係Yはドメインオブジェクトtest.tldの上の運営管理コントロールを維持します。 記録係Yには、サーバオブジェクトns1.example.tldの上の運営管理コントロールがありません。
3.4.4 Object Update
3.4.4 オブジェクトアップデート
[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] プロトコルは、登録されたオブジェクトをアップデートするという要求を現在登録されたオブジェクトを後援する記録係に制限するためにサービスを提供しなければなりません。
Hollenbeck Informational [Page 9] RFC 3375 Generic RRP Requirements September 2002
[9ページ]RFC3375ジェネリック小売希望価格要件2002年9月の情報のHollenbeck
[5] The protocol MUST provide services to explicitly reject unauthorized attempts to update a registered object.
[5] プロトコルは、明らかに登録されたオブジェクトをアップデートする権限のない試みを拒絶するためにサービスを提供しなければなりません。
3.4.5 Object Transfer
3.4.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] オブジェクトの転送はオブジェクトの登録の期間を延ばすかもしれません。 オブジェクトの登録の期間が転送の結果として延ばされるなら、転送要求の無事終了の後に新しい有効期限と時間を返さなければなりません。
Hollenbeck Informational [Page 10] RFC 3375 Generic RRP Requirements September 2002
[10ページ]RFC3375ジェネリック小売希望価格要件2002年9月の情報のHollenbeck
[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人の記録係が、オブジェクトへの経営者の責任が記録係失敗の場合、別の記録係に関連していると仮定するのが必要であるかもしれません。 プロトコルは記録係失敗の場合、オブジェクトを移す能力を制限してはいけません。
3.4.6 Object Renewal/Extension
3.4.6 オブジェクト更新/拡大
[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] 登録されたオブジェクトの有効期間を更新するか、または延ばすという要求を現在登録されたオブジェクトを後援する記録係に制限しなければなりません。 明らかに登録されたオブジェクトの有効期間を更新するか、または延ばす権限のない試みを拒絶しなければなりません。
3.4.7 Object Deletion
3.4.7 目的語削除
[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] 登録されたオブジェクトを取り除くという要求を現在登録されたオブジェクトを後援する記録係に制限しなければなりません。 明らかに登録されたオブジェクトを取り除く権限のない試みを拒絶しなければなりません。
3.4.8 Object Existence Query
3.4.8 オブジェクト存在質問
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] プロトコルは、ドメイン名が登録に存在するかどうか決定するためにサービスを提供しなければなりません。 ドメイン名は完全に修飾された名前で探せるに違いありません。
Hollenbeck Informational [Page 11] RFC 3375 Generic RRP Requirements September 2002
[11ページ]RFC3375ジェネリック小売希望価格要件2002年9月の情報のHollenbeck
[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] 登録されたオブジェクトの存在がすべてに利用可能であるに違いないことを決定するという要求は記録係に権限を与えました。
3.4.9 Object Information Query
3.4.9 オブジェクト情報質問
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
[3] プロトコルは、登録からの社会情報を検索するためにサービスを提供しなければなりません。 返された情報はそんなに元々、識別属性(名前、アドレス、電話番号、およびEメールアドレスを含むかもしれない)、記録係の識別子を含まなければなりません。
Hollenbeck Informational [Page 12] RFC 3375 Generic RRP Requirements September 2002
[12ページ]RFC3375ジェネリック小売希望価格要件2002年9月の情報のHollenbeck
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.
最近のうまくいっているアップデートの情報、作成日付、時、日付、および時(もしあれば)に登録されています、アップデートを実行した記録係の識別子、最終日時は(もしあれば)の転送、および承認情報を終了しました。 記録係を後援する電流に承認情報を返すだけでよいです。
[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] 登録されたオブジェクトについて説明する情報を検索するという要求は現在登録されたオブジェクトを後援する記録係によって承諾されるかもしれません。 明らかに登録されたオブジェクトについて説明する情報を検索する権限のない試みを拒絶しなければなりません。
3.5 Domain Status Indicators
3.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] ドメインには、その時々で、複数の状態がいるかもしれません。 数人の状態が互いに唯一であるかもしれません。
3.6 Transaction Completion Status
3.6 トランザクション完成状態
[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] プロトコルは明白にあらゆるトランザクションの成否に注意するサービスを提供しなければなりません。 明瞭に個々の成功とエラー条件に注意しなければなりません。
Hollenbeck Informational [Page 13] RFC 3375 Generic RRP Requirements September 2002
[13ページ]RFC3375ジェネリック小売希望価格要件2002年9月の情報のHollenbeck
4. External Interface Requirements
4. 外部のインターフェース要件
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.
外部のインタフェースはシステムとコミュニケートするシステムと実体の間の相互作用ポイントを定義します。 興味がある特定の領域はユーザインタフェース、ハードウェア・インタフェース、ソフトウェア・インタフェース、およびコミュニケーションインタフェースを含んでいます。
4.1 User, Hardware, and Software Interfaces
4.1 ユーザ、ハードウェア、およびソフトウェア・インタフェース
[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] プロトコルがアプリケーション設計ではなく、データ交換のためのワイヤ書式をユーザ、ハードウェア、またはソフトウェア・インタフェースと定義しなければならないので、同じビットをワイヤに作成して、同じ保全規制のイメージを維持できるどんなアプリケーションも、プロトコルの有効な実装です。
4.2 Communications Interfaces
4.2 コミュニケーションインタフェース
[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などの輻輳制御を特徴とする承認されたプロトコルを実行することであるにすぎないに違いありません。
5. Performance Requirements
5. パフォーマンス要件
[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] ランタイム性能はプロトコルユーザビリティの絶対に重大な局面です。 性能が非常にずっしりとプロトコルを実装するハードウェアとソフトウェア・アーキテクチャに依存している間、プロトコル機能は基本的なアーキテクチャが最適の性能を提供する能力に直接的な衝撃を持つことができます。 環境を操作して、プロトコルは高いボリュームと低ボリュームの両方で使用可能であるに違いありません。
6. Design Constraints
6. デザイン規制
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.
機能的に向こうの問題を意識しているデザイナーの必要性について議定書の中で述べてください。そうすれば、バランスをとるとき、インターフェース要件はデザイン決定について議定書の中で述べます。 このセクションは規格コンプライアンスとハードウェア制限を含んでいて、プロトコルデザインに影響を与えるかもしれない追加要素について説明します。
6.1 Standards Compliance
6.1 規格コンプライアンス
[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アドレス構文、セキュリティ、および輸送は特に関連しています。 円熟に近づくので考えられて、ドメインネームシステムの規格として現れるのはそうしなければなりません。
Hollenbeck Informational [Page 14] RFC 3375 Generic RRP Requirements September 2002
[14ページ]RFC3375ジェネリック小売希望価格要件2002年9月の情報のHollenbeck
[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] プロトコルは下層プロトコル標準によって提供されたサービスを再発明してはいけません。 例えば、信頼性を提供する輸送の使用はプロトコル自体で非信頼できる輸送の使用に関して信頼性を獲得するのに「再-トランスミッション」を使用することで選ばれることです。
6.2 Hardware Limitations
6.2 ハードウェア制限
[1] The protocol MUST NOT define any features that preclude hardware independence.
[1] プロトコルはハードウェア・インディペンデンスを排除するどんな特徴も定義してはいけません。
7. Service Attributes
7. サービス属性
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.
機能的、そして、インタフェース要件を超えたサービスの要素はプロトコルデザイン取り組みの一部をみなす必須な要素です。 このセクションはプロトコルデザイナーによって扱われる数個の大任要素について説明します、信頼性、有用性、スケーラビリティ、保守性、伸展性、およびセキュリティを含んでいて。
7.1 Reliability
7.1 信頼性
[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] 信頼性はプロトコルが一貫して、信頼できるレベルのサービスを提供する範囲の基準です。 信頼性はドメイン名管理プロトコルのための重要な属性です。 頼り無いプロトコルはデータ交換誤りの危険を増強します。(1つの極端では、誤りは、プロトコルユーザビリティに直接的な衝撃を持つことができて、それとは正反対に登録と記録係データ・ストアの間に不連続を導入できます)。 プロトコルはアプリケーションプロトコル層で信頼性を最大にする特徴を含まなければなりません。 また、アプリケーションを扱うとき考えられて、基本的な輸送、セッション、およびプレゼンテーションプロトコルSHOULDによって提供されたサービスは信頼性について議定書の中で述べます。
[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] 要求かイベント回のアウトをよく定義しなければならない時の間のデフォルトプロトコル動作。
7.2 Availability
7.2 有用性
[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] 有用性は意図している使用に、プロトコルによって提供されたサービスがアクセスしやすい範囲の基準です。 応用層プロトコルの有用性は主としてプロトコルを実装するソフトウェアとハードウェアシステムに依存しています。
Hollenbeck Informational [Page 15] RFC 3375 Generic RRP Requirements September 2002
[15ページ]RFC3375ジェネリック小売希望価格要件2002年9月の情報のHollenbeck
The protocol MUST NOT include any features that impinge on the underlying availability of the software and hardware systems needed to service the protocol.
プロトコルはソフトウェアの基本的な有用性に衝突するどんな特徴も含んではいけません、そして、ハードウェアシステムはプロトコルを修理する必要がありました。
7.3 Scalability
7.3 スケーラビリティ
[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] スケーラビリティはプロトコルが収容できる範囲の基準が許容できる操作上の特性を保存している間、成長を使用するということです。 登録と記録係システムの上の負荷が増加するのに従って、プロトコルは合格水準で作動できなければなりません。
7.4 Maintainability
7.4 保守性
[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であったならSHOULDについて議定書の中で述べてください。
7.5 Extensibility
7.5 伸展性
[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] 伸展性はプロトコルが元々設計されたとき容易に明白でなかった将来の用途のためにプロトコルを適合させることができる範囲の基準です。 プロトコルSHOULDは最小限でプロトコル自体に改正を必要としないで新しいオブジェクト・タイプの管理を考慮する特徴を提供します。
[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] プロトコルは形式と使用が独特の登録方針で制御されるすべてのコマンドの中で任意の野原を供給しなければなりません。
7.6 Security
7.6 セキュリティ
[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
[2] このドキュメントは基本的なユーザ登録名と認証サービスのための要件について説明します。 ジェネリックプロトコルは、ここで説明された攻撃から守るために追加担保サービスを含むかもしれません。 ジェネリックプロトコルは、ジェネリックプロトコル自体に提供されないセキュリティー・サービスを提供するために他に層にされたプロトコルによらなければなりません。 セキュリティを当てにするジェネリックプロトコル
Hollenbeck Informational [Page 16] RFC 3375 Generic RRP Requirements September 2002
[16ページ]RFC3375ジェネリック小売希望価格要件2002年9月の情報のHollenbeck
services from other-layered protocols MUST specify the protocol layers needed to provide security services.
他に層にされたプロトコルからのサービスはセキュリティー・サービスを提供するのが必要であるプロトコル層を指定しなければなりません。
8. Other Requirements
8. 他の要件
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.
ジェネリック登録記録係プロトコルを設計するとき、予期された運用環境のある一定の局面は考えられなければなりません。 関心の領域はデータベース操作、操作、サイト適合、およびデータ収集を含んでいます。
8.1 Database Requirements
8.1 データベース要件
[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] プロトコルには、少しのデータベースの依存もあってはいけません。 しかしながら、データベース操作とリソースの効率的な使用はプロトコルデザイン取り組みの一部であるとみなされなければなりません。 プロトコルSHOULDはデータベース負荷を最小にするために効率的に実装することができる原子特徴を提供します。
8.2 Operational Requirements
8.2 操作上の要件
[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] プロトコルレベルSHOULDでの登録記録係相互作用は人間の介入なしで作動します。 しかしながら、プロトコルの保全を保持する中間的サービスを提供するかもしれません。 例えば、記入者が名前スペースに名前を登録するのが認可されるかどうか決定する中間的サービスは提供できます。
[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] プロトコルは時の特性でクライアントとサーバが事実上、管理するために現在の日時の一貫した理解を維持できるサービスにオブジェクトを提供しなければなりません。
8.3 Site Adaptation Requirements
8.3 サイト適合要件
[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] 登録と記録係には、異なったビジネスと操作上の要件があります。 支配規格を含むいくつかの要素であり、地域法、習慣、および商習慣はすべて、登録と記録係がどのように操作されるかを決定することにおける役割を果たします。 プロトコルはさまざまの登録記録係環境で作動するほどフレキシブルでなければなりません。
8.4 Data Collection Requirements
8.4 データ収集要件
[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] 記録係と登録の間で交換されたいくつかのデータが個人的であるか、個人的であるか、またはそうでなければ、敏感であると考えられるかもしれません。 そのような情報の公開は法、そして/または、商習慣によって制限されるかもしれません。 プロトコルは、データ収集方針を特定するためにサービスを提供しなければなりません。
Hollenbeck Informational [Page 17] RFC 3375 Generic RRP Requirements September 2002
[17ページ]RFC3375ジェネリック小売希望価格要件2002年9月の情報のHollenbeck
[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規格あたりのパブリックディスクロージャを受けることがあります。
9. Internationalization Requirements
9. 国際化要件
[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ビットの米国-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] Universal Coordinated Timeで値がジェネリック登録で記録係プロトコルを指定したすべての日付と時を言い表さなければなりません。 日付と回は、Universal Coordinated Timeのために4ケタの暦年、暦月、カレンダー日、何時間、数分、秒、断片的な秒、および時間帯を表すために情報を含まなければなりません。 グレゴリオ暦は別としてカレンダーを使用してはいけません。
10. IANA Considerations
10. IANA問題
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]で説明されたガイドラインに従わなければなりません。
11. Security Considerations
11. セキュリティ問題
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
適宜登録と記録係との相互作用を保護するために適用されていて、秘密性、認証を含むセキュリティー・サービスがコントロール、保全、および非拒否SHOULDにアクセスします。 秘密性サービスは不注意な公開から機密の交換された情報を保護します。 オンライン・トランザクションに従事する前に、認証サービスは登録と記録係の要求されたアイデンティティを確認します。 そしてアクセス制御サービスがデータへのアクセスを制御する。
Hollenbeck Informational [Page 18] RFC 3375 Generic RRP Requirements September 2002
[18ページ]RFC3375ジェネリック小売希望価格要件2002年9月の情報のHollenbeck
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.
サービスはアイデンティティを基礎づけました。 データを交換したサービスが保証する保全が登録と記録係の間で変更されていません。 非拒否サービスはトランザクションの送付者が、トランザクションの源であることを否定しない場合があって、また受取人が、トランザクションの受信機であることを否定しない場合があるという保証を提供します。
12. Acknowledgements
12. 承認
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いすのエドワード・ルイスとJaap 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.
このドキュメントの開発を誘導するのを助けた特定のコメントがハラルドTveit Alvestrandによって提供されました、クリストファー・アンブラー、カール・アウアーバック、イェルクバウアー、ジョージBelotsky、エリック・ブルンナー-ウィリアムズ、Jordynブキャナン、ランディ・ブッシュ、ブルース・キャンベル、ダン・コーエン、アンドレ・コーミア、ケントクリスピン、デーヴ・クロッカー、Ayesha Damaraju、ルシオDe Re、マッツDufberg、ピーターEisenhauer; 切り立っている高架鉄道-Showk、ウルスEppenberger、パトリクFaltstrom、ポール・ジョージ、パトリック・グリーンウェル、Jarle Greipsland、オリビエGuillard、アルフ・ハンセン、ポール・ホフマン、ポール・ケーン、シェーン・カー、Elmar Knipp(マイクランプソン、マット・ラーソン)はLuを確認します、クラウスMalorny、ビル・マニング、マイケルが食事して、パトリックMevzek、ピーターMott、キャサリン・マーフィー、マーチン・オールドフィールド、Geva Patz、エリザベートPorteneuve、ロスWm。 レーダー、Budi Rahardjo、アニー・レナルド、スコット・ローズ、Takeshi Saigoh、マルコス・サンス、マルセル・シュナイダー、J.ウィリアムSemich、ジェームスSeng、リチャード・ショッキー、ブライアンSpolarich、ウィリアムTan、スティVenaas、ハーバートVitzthum、およびリック・ウェッソン。
13. References
13. 参照
Normative References:
引用規格:
[RFC2119] Bradner, S., "Key Words for Use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] ブラドナー、S.、「使用のための要件レベルを示すRFCsのキーワード」、BCP14、RFC2119、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問題部に書くためのガイドライン」BCP26、RFC2434(1998年10月)。
Informative References:
有益な参照:
[RFC1035] Mockapetris, P., "Domain Names - Implementation and
Specification", STD 13, RFC 1035, November 1987.
[RFC1035]Mockapetris、P.、「ドメイン名--、実装と仕様、」、STD13、RFC1035、11月1987日
Hollenbeck Informational [Page 19] RFC 3375 Generic RRP Requirements September 2002
[19ページ]RFC3375ジェネリック小売希望価格要件2002年9月の情報のHollenbeck
[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.スバンベルク、「IAB文字コードワークショップのレポート」、RFC2130、1997年4月。
[RFC2277] Alvestrand, H., "IETF Policy on Character Sets and
Languages", BCP 18, RFC 2277, January 1998.
[RFC2277] Alvestrand、H.、「文字コードと言語に関するIETF方針」、BCP18、RFC2277、1998年1月。
14. Editor's Address
14. エディタのアドレス
Scott Hollenbeck VeriSign Global Registry Services 21345 Ridgetop Circle Dulles, VA 20166-6503 USA
スコット・Hollenbeckのベリサインのグローバルな登録サービス21345屋根の頂円のヴァージニア20166-6503ダレス(米国)
EMail: shollenbeck@verisign.com
メール: shollenbeck@verisign.com
Hollenbeck Informational [Page 20] RFC 3375 Generic RRP Requirements September 2002
[20ページ]RFC3375ジェネリック小売希望価格要件2002年9月の情報のHollenbeck
15. Full Copyright Statement
15. 完全な著作権宣言文
Copyright (C) The Internet Society (2002). All Rights Reserved.
Copyright(C)インターネット協会(2002)。 All rights reserved。
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.
それに関するこのドキュメントと翻訳は、コピーして、それが批評するか、またはそうでなければわかる他のもの、および派生している作品に提供するか、または準備されているかもしれなくて、コピーされて、発行されて、全体か一部分配された実装を助けるかもしれません、どんな種類の制限なしでも、上の版権情報とこのパラグラフがそのようなすべてのコピーと派生している作品の上に含まれていれば。 しかしながら、このドキュメント自体は何らかの方法で変更されないかもしれません、インターネット協会か他のインターネット組織の版権情報か参照を取り除くのなどように、それを英語以外の言語に翻訳するのが著作権のための手順がインターネットStandardsプロセスで定義したどのケースに従わなければならないか、必要に応じてさもなければ、インターネット標準を開発する目的に必要であるのを除いて。
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機能のための基金は現在、インターネット協会によって提供されます。
Hollenbeck Informational [Page 21]
Hollenbeck情報です。[21ページ]
一覧
スポンサーリンク
