[要約] RFC 3981は、IRIS（Internet Registry Information Service）のコアプロトコルに関するものであり、IRISはインターネットレジストリ情報サービスを提供するためのプロトコルです。このRFCの目的は、IRISの基本的な機能と動作を定義し、インターネット上のリソースの登録情報を効果的に管理するための枠組みを提供することです。
Network Working Group A. Newton
Request for Comments: 3981 VeriSign, Inc.
Category: Standards Track M. Sanz
DENIC eG
January 2005
IRIS: The Internet Registry Information Service (IRIS) Core Protocol
IRIS: インターネット レジストリ情報サービス (IRIS) コア プロトコル
Status of This Memo
本文書の位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
この文書は、インターネット コミュニティ向けのインターネット標準追跡プロトコルを指定し、改善のための議論と提案を求めます。このプロトコルの標準化状況とステータスについては、最新版の「インターネット公式プロトコル標準」(STD 1) を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2005).
著作権 (C) インターネット協会 (2005)。
Abstract
概要
This document describes an application layer client-server protocol for a framework to represent the query and result operations of the information services of Internet registries. Specified in the Extensible Markup Language (XML), the protocol defines generic query and result operations and a mechanism for extending these operations for specific registry service needs.
この文書では、インターネット レジストリの情報サービスのクエリと結果の操作を表すフレームワークのアプリケーション層クライアント/サーバー プロトコルについて説明します。Extensible Markup Language (XML) で指定されるこのプロトコルは、一般的なクエリと結果の操作、および特定のレジストリ サービスのニーズに合わせてこれらの操作を拡張するメカニズムを定義します。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Use of XML . . . . . . . . . . . . . . . . . . . . . . . 2
1.2. General Concepts . . . . . . . . . . . . . . . . . . . . 3
1.3. Framework Layers . . . . . . . . . . . . . . . . . . . . 4
1.4. Definitions . . . . . . . . . . . . . . . . . . . . . . 4
1.5. Further Reading . . . . . . . . . . . . . . . . . . . . 5
2. Document Terminology . . . . . . . . . . . . . . . . . . . . . 5
3. Protocol Identification . . . . . . . . . . . . . . . . . . . 5
4. Exchange Description . . . . . . . . . . . . . . . . . . . . . 6
4.1. Request Format . . . . . . . . . . . . . . . . . . . . . 6
4.2. Response Format . . . . . . . . . . . . . . . . . . . . 6
4.3. Extension Framework . . . . . . . . . . . . . . . . . . 9
4.3.1. Derived Elements . . . . . . . . . . . . . . . . 9
4.3.2. Registry Type Identifier Requirements . . . . . 10
4.3.3. Entity Classes . . . . . . . . . . . . . . . . . 10
4.3.4. Names of Entities . . . . . . . . . . . . . . . 11
4.3.5. References to Entities . . . . . . . . . . . . . 11
4.3.6. Temporary Entities . . . . . . . . . . . . . . . 12
4.3.7. <result> Derived Elements . . . . . . . . . . . 13
4.3.8. <control> and <reaction> Elements . . . . . . . 16
4.4. Relay Bags . . . . . . . . . . . . . . . . . . . . . . . 18
5. Database Serialization . . . . . . . . . . . . . . . . . . . . 19
6. Formal XML Syntax . . . . . . . . . . . . . . . . . . . . . . 22
7. The IRIS URI . . . . . . . . . . . . . . . . . . . . . . . . . 37
7.1. URI Definition . . . . . . . . . . . . . . . . . . . . . 37
7.2. Transport Specific Schemes . . . . . . . . . . . . . . . 38
7.3. URI Resolution . . . . . . . . . . . . . . . . . . . . . 38
7.3.1. Registry Dependent Resolution . . . . . . . . . 38
7.3.2. Direct Resolution . . . . . . . . . . . . . . . 39
7.3.3. Transport and Service Location . . . . . . . . . 39
7.4. IRIS URI Examples . . . . . . . . . . . . . . . . . . . 40
8. Checklists . . . . . . . . . . . . . . . . . . . . . . . . . . 41
8.1. Registry Definition Checklist . . . . . . . . . . . . . 41
8.2. Transport Mapping Checklist . . . . . . . . . . . . . . 42
9. Internationalization Considerations . . . . . . . . . . . . . 42
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 43
11. Security Considerations . . . . . . . . . . . . . . . . . . . 43
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 43
12.1. Normative References . . . . . . . . . . . . . . . . . . 43
12.2. Informative References . . . . . . . . . . . . . . . . . 45
A. S-NAPTR and IRIS Uses . . . . . . . . . . . . . . . . . . . . 46
A.1. Examples of S-NAPTR with IRIS. . . . . . . . . . . . . . 46
A.2. Using S-NAPTR for Cohabitation . . . . . . . . . . . . . 47
B. IRIS Design Philosophy . . . . . . . . . . . . . . . . . . . . 48
B.1. The Basic Premise . . . . . . . . . . . . . . . . . . . 48
B.2. The Lure of a Universal Client . . . . . . . . . . . . . 49
B.3. Server Considerations . . . . . . . . . . . . . . . . . 49
B.4. Lookups, Searches, and Entity Classes . . . . . . . . . 50
B.5. Entities References, Search Continuations, and Scope . . 50
C. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 51
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 51
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 52
The specification outlined in this document is based on the functional requirements described in CRISP [17].
この文書で概説されている仕様は、CRISP [17] で説明されている機能要件に基づいています。
This document describes the specification for the Internet Registry Information Service (IRIS), an XML text protocol intended to describe the query types and result types of various registry information services. IRIS is specified by using the Extensible Markup Language (XML) 1.0 as described in [2], XML Schema notation as described in [4] and [5], and XML Namespaces as described in [3].
この文書では、さまざまなレジストリ情報サービスのクエリ タイプと結果タイプを記述することを目的とした XML テキスト プロトコルであるインターネット レジストリ情報サービス (IRIS) の仕様について説明します。IRIS は、[2] で説明されている Extensible Markup Language (XML) 1.0、[4] および [5] で説明されている XML スキーマ表記、および [3] で説明されている XML 名前空間を使用して指定されます。
Each kind of Internet registry is identified by a registry type. The identifier for a registry type is a Uniform Resource Name (URN) used within the XML instances to identify the XML schema that formally describes the set of queries, results, and entity classes allowed within that type of registry.
インターネット レジストリの各種類は、レジストリ タイプによって識別されます。レジストリ タイプの識別子は、そのタイプのレジストリ内で許可されるクエリ、結果、およびエンティティ クラスのセットを正式に記述する XML スキーマを識別するために XML インスタンス内で使用されるユニフォーム リソース ネーム (URN) です。
The structure of these URNs makes no assumptions or restrictions on the types of registries they identify. Therefore, IRIS may support multiple registry types of a disparate or similar nature; it is only a matter of definition. For instance, a single registry type may be defined for domain name registries, and multiple registry types for the various IP address registries.
これらの URN の構造では、識別されるレジストリの種類について仮定や制限がありません。したがって、IRIS は、異なる性質または類似した性質の複数のレジストリ タイプをサポートする場合があります。それは単なる定義の問題です。たとえば、ドメイン名レジストリには単一のレジストリ タイプを定義し、さまざまな IP アドレス レジストリには複数のレジストリ タイプを定義できます。
A registry information server may handle queries and serve results for multiple registry types. Each registry type that a particular registry operator serves is a registry service instance.
レジストリ情報サーバーはクエリを処理し、複数のレジストリ タイプの結果を提供できます。特定のレジストリ オペレータが提供する各レジストリ タイプは、レジストリ サービス インスタンスです。
IRIS and the XML schema formally describing IRIS do not specify any registry, registry identifier, or knowledge of a particular service instance or set of instances. IRIS is a specification for a framework with which these registries can be defined, used and, in some cases, interoperate. The framework merely specifies the elements for registry identification and the elements that must be used to derive queries and results.
IRIS および IRIS を正式に記述する XML スキーマは、レジストリ、レジストリ識別子、または特定のサービス インスタンスまたはインスタンスのセットに関する知識を指定しません。IRIS は、これらのレジストリを定義、使用し、場合によっては相互運用できるフレームワークの仕様です。このフレームワークは、レジストリを識別するための要素と、クエリと結果を取得するために使用する必要がある要素を指定するだけです。
This framework allows a registry type to define its own structure for naming, entities, queries, etc., through the use of XML namespaces and XML schemas (hence, a registry type MUST be identified by the same URI that identifies its XML namespace). To be compliant, a registry type's specification must extend from this framework.
このフレームワークにより、レジストリ タイプは、XML 名前空間と XML スキーマを使用して、名前付け、エンティティ、クエリなどの独自の構造を定義できます (したがって、レジストリ タイプは、その XML 名前空間を識別するのと同じ URI によって識別されなければなりません)。準拠するには、レジストリ タイプの仕様がこのフレームワークから拡張されている必要があります。
The framework defines certain structures that can be common to all registry types, such as references to entities, search continuations, and entity classes. A registry type may declare its own definitions for all of these, or it may mix its derived definitions with the base definitions.
このフレームワークは、エンティティへの参照、検索継続、エンティティ クラスなど、すべてのレジストリ タイプに共通の特定の構造を定義します。レジストリ タイプは、これらすべてについて独自の定義を宣言することも、その派生定義を基本定義と混合することもできます。
IRIS defines two types of referrals: an entity reference and a search continuation. An entity reference indicates specific knowledge about an individual entity, and a search continuation allows distributed searches. Both referrals may span differing registry types and instances. No assumptions or specifications are made about the roots, bases, or meshes of entities.
IRIS は、エンティティ参照と検索継続の 2 種類の参照を定義します。エンティティ参照は個々のエンティティに関する特定の知識を示し、検索継続により分散検索が可能になります。どちらの紹介も、異なるレジストリ タイプとインスタンスにまたがる場合があります。エンティティのルート、ベース、メッシュについては、いかなる仮定も仕様も行われません。
The IRIS framework can be thought of as having three layers.
IRIS フレームワークは 3 つの層があると考えることができます。
-----------------------------
Registry-Specific |domain | address | etc... |
-----------------------------
Common-Registry | IRIS |
-----------------------------
Application-Transport | beep | iris-lwz | etc... |
-----------------------------
In this figure, "beep" refers to the Blocks Extensible Exchange Protocol (BEEP) (see [20]), and "iris-lwz" refers to a theoretical UDP binding that uses compression.
この図では、「beep」は Blocks Extensible Exchange Protocol (BEEP) ([20] を参照) を指し、「iris-lwz」は圧縮を使用する理論的な UDP バインディングを指します。
The differing layers have the following responsibilities:
異なるレイヤーには次の役割があります。
Registry-Specific :: defines queries, results, and entity classes of a specific type of registry. Each specific type of registry is identified by a URN. Common-Registry :: defines base operations and semantics common to all registry types such as search sets, result sets, and referrals. It also defines the syntaxes for talking about specific registry types. Application-Transport :: defines the mechanisms for authentication, message passing, connection and session management, etc. It also defines the URI syntax specific to the application-transport mechanism.
レジストリ固有:: 特定の種類のレジストリのクエリ、結果、およびエンティティ クラスを定義します。特定の種類のレジストリはそれぞれ URN によって識別されます。Common-Registry :: 検索セット、結果セット、参照など、すべてのレジストリ タイプに共通する基本操作とセマンティクスを定義します。また、特定のレジストリ タイプについて説明するための構文も定義します。Application-Transport :: は、認証、メッセージ パッシング、接続およびセッション管理などのメカニズムを定義します。また、アプリケーション トランスポート メカニズムに固有の URI 構文も定義します。
For clarity, the following definitions are supplied:
明確にするために、次の定義が提供されます。
o registry type -- A registry serving a specific function, such as a domain registry or an address registry. Each type of registry is assigned a URN.
o レジストリ タイプ -- ドメイン レジストリやアドレス レジストリなど、特定の機能を果たすレジストリ。レジストリの種類ごとに URN が割り当てられます。
o registry schema -- The definition for a registry type specifying the queries, results, and entity classes.
o レジストリ スキーマ -- クエリ、結果、エンティティ クラスを指定するレジストリ タイプの定義。
o authority -- A reference to the server or set of servers containing information.
o 権限 -- 情報を含むサーバーまたはサーバーのセットへの参照。
o resolution method -- The technique used to locate an authority.
o 解決方法 -- 権威を見つけるために使用される技術。
o entity class -- A group of entities with a common type or common set of characteristics.
o エンティティ クラス -- 共通のタイプまたは共通の特性セットを持つエンティティのグループ。
o entity name -- The identifier used to refer to a single entity within an entity class.
o エンティティ名 -- エンティティ クラス内の単一エンティティを参照するために使用される識別子。
o entity reference -- A pointer to an entity composed of an authority, an optional resolution method, a registry type, an entity class, and an entity name. One type of entity reference is the IRIS URI (defined in Section 7).
o エンティティ参照 -- 権限、オプションの解決方法、レジストリ タイプ、エンティティ クラス、およびエンティティ名で構成されるエンティティへのポインタ。エンティティ参照の 1 つのタイプは IRIS URI (セクション 7 で定義) です。
The terms "derivative", "derive", and "derivation" are used with the same meaning for deriving one type of element from another as specified in XML_SS [5].
「派生」、「派生」、および「導出」という用語は、XML_SS [5] で指定されているように、あるタイプの要素を別のタイプの要素から導出する場合と同じ意味で使用されます。
Appendix B contains text answering the question, "Why IRIS?".
付録 B には、「なぜ IRIS?」という質問に答えるテキストが含まれています。
This document describes the structure at the core of IRIS. The following documents describe the other aspects of IRIS relevant to CRISP [17]: iris-beep [1] and iris-dreg [18].
この文書では、IRIS の中核となる構造について説明します。次の文書では、CRISP [17] に関連する IRIS の他の側面について説明しています: iris-beep [1] および iris-dreg [18]。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, RFC 2119 [8].
この文書のキーワード「しなければならない」、「してはならない」、「必須」、「しなければならない」、「してはならない」、「すべきである」、「すべきではない」、「推奨」、「してもよい」、「任意」は次のとおりです。BCP 14、RFC 2119 [8] に記載されているように解釈されます。
The root element of all request XML instances MUST be <request>. The root element of all response XML instances MUST be <response>. These elements identify the start of the IRIS elements, the XML namespace used as the identifier for IRIS, and, optionally, the location of the schema. These elements and the associated closing tag MUST be applied to all requests and responses sent by both clients and servers.
すべてのリクエスト XML インスタンスのルート要素は <request> でなければなりません。すべての応答 XML インスタンスのルート要素は <response> でなければなりません。これらの要素は、IRIS 要素の開始、IRIS の識別子として使用される XML 名前空間、およびオプションでスキーマの場所を識別します。これらの要素と関連する終了タグは、クライアントとサーバーの両方から送信されるすべてのリクエストと応答に適用されなければなりません。
The use of the schema location attribute 'xsi:schemaLocation' is OPTIONAL with respect to this specification, and IRIS implementations MAY resolve it to retrieve the schema or MAY use a locally cached version of the schema.
この仕様に関して、スキーマの場所属性「xsi:schemaLocation」の使用はオプションであり、IRIS 実装はそれを解決してスキーマを取得してもよいし、ローカルにキャッシュされたバージョンのスキーマを使用してもよいです。
Versioning of the IRIS protocol is the responsibility of the application-transport layer but MUST be associated with the XML namespace [3] URI representing IRIS. A change in this URI indicates a change of the underlying schema and, therefore, a new version of the protocol (and vice versa).
IRIS プロトコルのバージョン管理はアプリケーション トランスポート層の責任ですが、IRIS を表す XML 名前空間 [3] URI に関連付けられなければなりません (MUST)。この URI の変更は、基礎となるスキーマの変更、つまりプロトコルの新しいバージョンの変更を示します (逆も同様)。
This section describes the request and response exchanges of the protocol. The descriptions contained within this section refer to XML elements and attributes and their relation to the exchange of data within the protocol. These descriptions also contain specifications outside the scope of the formal XML syntax. Therefore, this section will use terms defined by RFC 2119 [8] to describe the specification outside the scope of the formal XML syntax. While reading this section, please reference Section 6 for details on the formal XML syntax.
このセクションでは、プロトコルのリクエストとレスポンスの交換について説明します。このセクションに含まれる説明では、XML 要素と属性、およびプロトコル内のデータ交換との関係について言及します。これらの説明には、正式な XML 構文の範囲外の仕様も含まれています。したがって、このセクションでは、RFC 2119 [8] で定義されている用語を使用して、正式な XML 構文の範囲外の仕様を説明します。このセクションを読みながら、正式な XML 構文の詳細についてはセクション 6 を参照してください。
A <request> element contains an optional <control> element and a set of <searchSet> elements.
<request> 要素には、オプションの <control> 要素と一連の <searchSet> 要素が含まれます。
The <searchSet> elements enable a client to query a particular registry type by using the URN identifying the registry type. This can be found in one of its two children: <lookupEntity> and <query>.
<searchSet> 要素を使用すると、クライアントは、レジストリ タイプを識別する URN を使用して、特定のレジストリ タイプをクエリできます。これは、その 2 つの子の <lookupEntity> と <query> の 1 つにあります。
The <lookupEntity> element describes the lookup of an entity in a specific registry. This element has three attributes: 'registryType', 'entityClass', and 'entityName'. The 'registryType' attribute contains the registry identifier for the registry type in which the lookup operation will take place. The 'entityClass' attribute contains the token identifying the index for which the lookup operation will take place, and the 'entityName' attribute contains the name of the entity to look up.
<lookupEntity> 要素は、特定のレジストリ内のエンティティの検索を記述します。この要素には、「registryType」、「entityClass」、「entityName」の 3 つの属性があります。「registryType」属性には、検索操作が行われるレジストリ タイプのレジストリ識別子が含まれます。「entityClass」属性には、検索操作が行われるインデックスを識別するトークンが含まれ、「entityName」属性には検索するエンティティの名前が含まれます。
The <query> element is abstract and may not legally appear in an XML instance. It provides the base type that registry schemas will use to define derived query types. This derivation mechanism is described in Section 4.3.
<query> 要素は抽象的なものであり、XML インスタンスに法的に出現しない場合があります。これは、レジストリ スキーマが派生クエリ タイプを定義するために使用する基本タイプを提供します。この導出メカニズムについてはセクション 4.3 で説明します。
Each <searchSet> may also contain a <bag> element. When this element appears as a child of <searchSet>, it MUST NOT contain the 'id' attribute. For a description of the <bag> element, see Section 4.4.
各 <searchSet> には <bag> 要素も含まれる場合があります。この要素が <searchSet> の子として表示される場合、「id」属性を含めてはなりません。<bag> 要素の説明については、セクション 4.4 を参照してください。
The <control> element may contain one child element of any XML namespace. This child element allows a client to signal a server for special states or processing. An example of one such <control> child element may be found in Section 4.3.8.
<control> 要素には、任意の XML 名前空間の子要素を 1 つ含めることができます。この子要素により、クライアントはサーバーに特別な状態または処理を通知できます。このような <control> 子要素の例は、セクション 4.3.8 にあります。
The <response> element contains an optional <reaction> element, a set of <resultSet> elements, and an optional <bags> element.
<response> 要素には、オプションの <reaction> 要素、一連の <resultSet> 要素、およびオプションの <bags> 要素が含まれます。
The <resultSet> elements are responses to a <searchSet> request. The contents of this element contain an <answer> element, an optional <additional> element, and error elements, if applicable.
<resultSet> 要素は、<searchSet> リクエストに対する応答です。この要素の内容には、<answer> 要素、オプションの <Additional> 要素、および該当する場合は error 要素が含まれます。
The children of the <answer> element are of the following types:
<answer> 要素の子には次のタイプがあります。
o <result> is an abstract element and may not be legally placed in an XML instance. It provides the base type to be used by registry schemas to define derived result types. This derivation mechanism is described in Section 4.3.
o <result> は抽象要素であり、XML インスタンスに合法的に配置することはできません。これは、派生結果の型を定義するためにレジストリ スキーマで使用される基本型を提供します。この導出メカニズムについてはセクション 4.3 で説明します。
o <entity> is an element specifying an entity reference. See Section 4.3.5.
o <entity>は、実体参照を指定する要素です。セクション 4.3.5 を参照してください。
o The <searchContinuation> element specifies a query referral. Its one child is any element derived from <query> (see Section 4.3.1). To direct the query to a referent server, <searchContinuation> has a mandatory 'authority' attribute and an optional 'resolution' attribute. The <searchContinuation> element may also contain a 'bagRef' attribute. For a description of the 'bagRef' attribute, see Section 4.4.
o <searchContinuation> 要素はクエリ参照を指定します。その 1 つの子は、<query> から派生した任意の要素です (セクション 4.3.1 を参照)。クエリを参照先サーバーに送信するために、<searchContinuation> には必須の「authority」属性とオプションの「resolution」属性があります。<searchContinuation> 要素には、「bagRef」属性も含まれる場合があります。「bagRef」属性の説明については、セクション 4.4 を参照してください。
When following entity references and search continuations, clients SHOULD only follow an <entity> or <searchContinuation> response once. Failure to do so may result in the client process getting stuck in a never-ending query loop, commonly known as a referral loop.
エンティティ参照と検索継続を追跡する場合、クライアントは <entity> または <searchContinuation> 応答を 1 回だけ追跡する必要があります (SHOULD)。これを行わないと、クライアント プロセスが、一般に参照ループとして知られる、終わりのないクエリ ループに陥る可能性があります。
The <additional> element only contains <result> elements, as described above. This element allows a server to indicate to a client results that were not specifically queried but that are related to the queried results, thus enabling the client to display this distinction to a user properly. The <additional> element use is optional.
前述のように、<Additional> 要素には <result> 要素のみが含まれます。この要素を使用すると、サーバーは、特にクエリされたわけではないが、クエリされた結果に関連する結果をクライアントに示すことができるため、クライアントはこの区別をユーザーに適切に表示できるようになります。<Additional> 要素の使用はオプションです。
The following elements, which represent error conditions, may be returned:
エラー状態を表す次の要素が返される場合があります。
o <insufficientResources> -- The corresponding query requires resources unobtainable by the server.
o <insufficientResources> -- 対応するクエリには、サーバーで取得できないリソースが必要です。
o <invalidName> -- A name given in a query is not syntactically correct.
o <invalidName> -- クエリで指定された名前は構文的に正しくありません。
o <invalidSearch> -- Parameters of the corresponding query are not semantically meaningful.
o <invalidSearch> -- 対応するクエリのパラメータは意味的に意味がありません。
o <queryNotSupported> -- The corresponding query is not supported by this server.
o <queryNotSupported> -- 対応するクエリはこのサーバーではサポートされていません。
o <limitExceeded> -- The corresponding query requires more resources than allowed.
o <limitExceeded> -- 対応するクエリには、許可されている以上のリソースが必要です。
o <nameNotFound> -- The name given in a query does not match a known entity.
o <nameNotFound> -- クエリで指定された名前が既知のエンティティと一致しません。
o <permissionDenied> -- The authentication given does not allow access to a specific result entry.
o <permissionDenied> -- 指定された認証では、特定の結果エントリへのアクセスが許可されません。
o <bagUnrecognized> -- The contents of a bag were unrecognized. See Section 4.4.
o <bagUnrecognized> -- バッグの中身が認識されませんでした。セクション 4.4 を参照してください。
o <bagUnacceptable> -- The contents of a bag were not and never will be acceptable. See Section 4.4.
o <bagUnacceptable> -- バッグの中身は許容されませんでしたし、今後も許容されません。セクション 4.4 を参照してください。
o <bagRefused> -- The contents of a bag were not acceptable at this time. See Section 4.4.
o <bagRefused> -- 現時点ではバッグの中身は受け入れられませんでした。セクション 4.4 を参照してください。
o A derivative of <genericCode>, as described in Section 4.3.
o セクション 4.3 で説明されている <genericCode> の派生です。
The <resultSet> section is divided into the <answer> and <additional> sections to allow easier processing and navigation of the results by a client. Servers MUST return the direct answers to queries in the <answer> element and MAY return results in the <additional> element for which a reference has been made in the <answer> element. Results in the <additional> element MUST have been referenced in the <answer>, either as direct children of the <answer> element or as deeper descendants of the <answer> element.
<resultSet> セクションは、クライアントによる結果の処理とナビゲーションを容易にするために、<answer> セクションと <Additional> セクションに分割されています。サーバーは、クエリに対する直接の回答を <answer> 要素で返さなければなりません (MUST)。また、<answer> 要素で参照が行われている結果を <Additional> 要素で返すこともできます (MAY)。<Additional> 要素内の結果は、<answer> 要素の直接の子として、または <answer> 要素のより深い子孫として、<answer> 内で参照されている必要があります。
This serves two purposes. First, it may eliminate a requery by the client for references contained in the <answer> element. Second, it distinguishes between results that are a direct result of a query and those that would have been returned had the client followed the appropriate referrals, thus hinting how clients could process or display the returned results. For instance, clients constructing complex displays with tree navigation widgets will know that results in the <answer> element should all be directly beneath the root node of the tree, while results in the <additional> element are leaf nodes of those produced from the <answer> element.
これには 2 つの目的があります。まず、<answer> 要素に含まれる参照に対するクライアントによる再クエリを排除できます。2 番目に、クエリの直接の結果である結果と、クライアントが適切な参照に従っていた場合に返される結果を区別し、クライアントが返された結果をどのように処理または表示できるかを示します。たとえば、ツリー ナビゲーション ウィジェットを使用して複雑な表示を構築しているクライアントは、<answer> 要素の結果はすべてツリーのルート ノードの直下にある必要があるのに対し、<Additional> 要素の結果は < から生成されたものの葉ノードであることがわかります。答え>要素。
A <reaction> element (child of <response>) is a response to a <control> element, and provides a means for a server to advise a client of the effect of a <control> element.
<reaction> 要素 (<response> の子) は、<control> 要素に対する応答であり、サーバーがクライアントに <control> 要素の効果を通知する手段を提供します。
The <bags> element (child of <response>) is optional. It contains <bag> elements, and the contents of each <bag> element constitute one element in any XML namespace. Each <bag> element has an 'id' attribute, which is referenced by the 'bagRef' attribute of entity references (<entity>) and search continuations (<searchContinuation>). See Section 4.4.
<bags> 要素 (<response> の子) はオプションです。これには <bag> 要素が含まれており、各 <bag> 要素の内容は XML 名前空間の 1 つの要素を構成します。各 <bag> 要素には「id」属性があり、エンティティ参照 (<entity>) および検索継続 (<searchContinuation>) の「bagRef」属性によって参照されます。セクション 4.4 を参照してください。
Because the IRIS schema defines only one query type, and two stand-alone result types, and does not define a registry structure, it is of limited use by itself. Extension of IRIS is accomplished through the use of a base IRIS schema, as defined in XML_SD [4] and XML_SS [5], and through extension of it by schemas constructed on top of IRIS.
IRIS スキーマは 1 つのクエリ タイプと 2 つのスタンドアロン結果タイプのみを定義し、レジストリ構造を定義しないため、それ自体の用途は限られています。IRIS の拡張は、XML_SD [4] および XML_SS [5] で定義されている基本 IRIS スキーマの使用と、IRIS 上に構築されたスキーマによる拡張によって実現されます。
The XML Schema definition of IRIS requires schemas of registry types to derive element types from base types in the IRIS definition. The registry schemas MUST derive elements to define typed queries and results.
IRIS の XML スキーマ定義では、IRIS 定義の基本タイプから要素タイプを導出するために、レジストリ タイプのスキーマが必要です。レジストリ スキーマは、型指定されたクエリと結果を定義する要素を導出する必要があります。
While the IRIS schema definition does not prohibit the derivation of any elements, registry schemas SHOULD restrict the derivations to the following types:
IRIS スキーマ定義では要素の派生を禁止していませんが、レジストリ スキーマは派生を次のタイプに制限する必要があります (SHOULD)。
o <query> -- As defined, this element contains no content and has no valid attributes. It is abstract and therefore only its derivatives appear in XML instances. Registry schemas derive from this element to define the queries allowed.
o <query> -- 定義されているように、この要素にはコンテンツが含まれず、有効な属性もありません。これは抽象的なものであるため、XML インスタンスにはその派生物のみが表示されます。レジストリ スキーマはこの要素から派生して、許可されるクエリを定義します。
o <result> -- As defined, this element contains no content and has five valid attributes: 'authority', 'resolution' (optional), 'registryType', 'entityClass', 'entityName', and 'temporaryReference' (optional, see Section 4.3.6). It is abstract and therefore only its derivatives appear in XML instances. Registry schemas derive from this element to define results that may be returned from a query.
o <result> -- 定義どおり、この要素にはコンテンツは含まれず、次の 5 つの有効な属性があります: 'authority'、'resolution' (オプション)、'registryType'、'entityClass'、'entityName'、および 'temporaryReference' (オプション。「セクション 4.3.6)。これは抽象的なものであるため、XML インスタンスにはその派生物のみが表示されます。レジストリ スキーマはこの要素から派生し、クエリから返される結果を定義します。
o <genericCode> -- As defined, this element is an instance of <codeType>. It contains the optional elements <explanation> and <language>, which further describe the nature of the error.
o <genericCode> -- 定義されているように、この要素は <codeType> のインスタンスです。これにはオプションの要素 <explanation> と < language> が含まれており、エラーの性質をさらに説明します。
o <entity> -- Identifies a reference to an entity. Registry schemas SHOULD use elements derived from <entity> but MAY use <entity> directly. The advantage of deriving from <entity> vs. direct use is the chance to define the name of the element and to use that name descriptively -- for instance, as the role the entity plays with respect to another entity. See Section 4.3.5.
o <entity> -- エンティティへの参照を識別します。レジストリ スキーマは、<entity> から派生した要素を使用すべきであるが、<entity> を直接使用してもよい (MAY)。<entity> から派生することと直接使用することの利点は、要素の名前を定義し、その名前を説明的に使用できることです。たとえば、エンティティが別のエンティティに対して果たす役割として使用できます。セクション 4.3.5 を参照してください。
o <seeAlso> -- Indicates a reference to an entity that has indirect association with a parent element representing an entity. This element is derived from the <entity> element (Section 4.3.5). Registry schemas MAY derive from this element or MAY use it directly.
o <seeAlso> -- エンティティを表す親要素と間接的に関連するエンティティへの参照を示します。この要素は、<entity> 要素 (セクション 4.3.5) から派生します。レジストリ スキーマは、この要素から派生することもできますし、直接使用することもできます。
The identifier for a registry type and the XML namespace identifier used by the XML Schema describing the registry MUST be the same. These identifiers MUST be restricted to a URN [7] registered in the 'ns' class of the IANA registry governed by XML_URN [9]. These identifiers are case insensitive.
レジストリ タイプの識別子と、レジストリを記述する XML スキーマで使用される XML 名前空間識別子は、同じでなければなりません。これらの識別子は、XML_URN [9] によって管理される IANA レジストリの「ns」クラスに登録された URN [7] に制限されなければなりません (MUST)。これらの識別子では大文字と小文字が区別されません。
This is a restriction on XML_NS [3], which specifies that an XML namespace identifier is any valid URI [6].
これは、XML 名前空間識別子が有効な URI [6] であることを指定する XML_NS [3] の制限です。
These identifiers MAY be abbreviated to the part following the class component and its separator of the URN. For example, the full URN "urn:ietf:params:xml:ns:dreg1" may be abbreviated to "dreg1".
これらの識別子は、URN のクラスコンポーネントとその区切り文字に続く部分に短縮されてもよい(MAY)。たとえば、完全な URN「urn:ietf:params:xml:ns:dreg1」は「dreg1」と省略される場合があります。
In use with IRIS, this abbreviation MUST NOT be used inside of XML instances in which the XML Schema [4] specifies the use of a URI for schema identification or where XML_NS [3] specifies the use of a URI for XML namespace identification.
IRIS で使用する場合、この略語は、XML スキーマ [4] がスキーマ識別に URI の使用を指定している XML インスタンス内、または XML_NS [3] が XML 名前空間識別に URI の使用を指定している XML インスタンス内で使用してはなりません (MUST NOT)。
IRIS provides entity classes to help avoid collisions with entity names within any given registry type. Their specification in queries also allows server implementations to narrow search or lookup scopes quickly to a single index.
IRIS は、特定のレジストリ タイプ内のエンティティ名との衝突を回避するのに役立つエンティティ クラスを提供します。クエリ内のそれらの仕様により、サーバー実装は検索または検索範囲を単一のインデックスにすばやく絞り込むこともできます。
For instance, the entity name "192.0.2.0" might refer to separate entities in the "name-server" and "network" classes. The entity "192.0.2.0" in the "name-server" class may refer to the name server host that is also multi-homed by address 192.0.2.255 and known in DNS as "ns.example.com", whereas the entity "192.0.2.0" in the "network" class may refer to the network 192.0.2/30.
たとえば、エンティティ名「192.0.2.0」は、「name-server」クラスと「network」クラスの別個のエンティティを参照する可能性があります。「name-server」クラスのエンティティ「192.0.2.0」は、アドレス 192.0.2.255 によってマルチホーム化され、DNS では「ns.example.com」として知られるネーム サーバ ホストを参照する場合がありますが、エンティティ「」「ネットワーク」クラスの「192.0.2.0」は、ネットワーク 192.0.2/30 を参照している可能性があります。
IRIS defines two default entity classes of "local" and "iris", which MUST NOT be redefined. These entity classes MUST be valid in all registry types.
IRIS は、「local」と「iris」という 2 つのデフォルトのエンティティ クラスを定義します。これらを再定義してはなりません。これらのエンティティ クラスは、すべてのレジストリ タイプで有効でなければなりません。
The "local" class is reserved for entities defined locally by a server operator and does not denote any particular type of entity. A lookup in this entity class MAY result in an entity reference or search continuation. For example, "iris:dreg1//example.com/local/ myhosts" may result in a search continuation yielding the nameservers for example.com.
「ローカル」クラスは、サーバー オペレーターによってローカルに定義されたエンティティ用に予約されており、特定のタイプのエンティティを示すものではありません。このエンティティ クラスの検索により、エンティティ参照または検索継続が発生する場合があります (MAY)。たとえば、「iris:dreg1//example.com/local/myhosts」と入力すると、検索が継続され、example.com などのネームサーバーが得られる場合があります。
The "iris" class is reserved for entities specific to a particular service instance. It MUST contain the following entity names (see Section 4.3.4):
「iris」クラスは、特定のサービス インスタンスに固有のエンティティのために予約されています。次のエンティティ名を含める必要があります (セクション 4.3.4 を参照)。
o "id", which yields a result of <serviceIdentification> (see Section 4.3.7.1).
o 「id」。<serviceIdentification> の結果が得られます (セクション 4.3.7.1 を参照)。
o "limits", which yields a result of <limits> (see Section 4.3.7.2). This entity class MAY contain other locally defined entities as well.
o "limits"。<limits> の結果が得られます (セクション 4.3.7.2 を参照)。このエンティティ クラスには、ローカルに定義された他のエンティティも含めることができます (MAY)。
The names of entity classes in a registry schema are of type token, as defined by XML_SD [4]. Their case sensitivity MUST be defined by the definition of the registry type. In general, they SHOULD be case insensitive.
レジストリ スキーマ内のエンティティ クラスの名前は、XML_SD [4] で定義されているように、トークン型です。大文字と小文字の区別は、レジストリ タイプの定義によって定義する必要があります。一般に、大文字と小文字を区別しない必要があります(SHOULD)。
The names of entities in a registry schema are of type token, as defined by XML_SD [4].
レジストリ スキーマ内のエンティティの名前は、XML_SD [4] で定義されているように、トークン型です。
Names of entities SHOULD be unique within an instance of any particular entity class within a registry. Two entities SHOULD NOT have the same name, but a single entity MAY be known by multiple names. In situations where a single name may result in two entities, the registry schema SHOULD make allowances by defining result types that contain entity references to both entities (e.g., "example.com" can refer to both the domain example.com and the host example.com). However, this type of conflict SHOULD generally be avoided by the proper use of entity classes.
エンティティの名前は、レジストリ内の特定のエンティティ クラスのインスタンス内で一意である必要があります (SHOULD)。2 つのエンティティが同じ名前を持つべきではありませんが、1 つのエンティティが複数の名前で知られていてもよい(MAY)。1 つの名前から 2 つのエンティティが生じる可能性がある状況では、レジストリ スキーマは、両方のエンティティへのエンティティ参照を含む結果タイプを定義することで許容する必要があります (たとえば、「example.com」は、ドメイン example.com とホスト example.com の両方を参照できます).com）。ただし、この種の競合は通常、エンティティ クラスを適切に使用することによって回避すべきです(SHOULD)。
The case sensitivity of entity names is dependent on the entity class in which they reside. The definition of a registry type MUST specify the case sensitivity for entity names. A registry type MAY define the entity names of differing entity classes as having different case sensitivity.
エンティティ名の大文字と小文字の区別は、エンティティ名が存在するエンティティ クラスによって異なります。レジストリ タイプの定義では、エンティティ名の大文字と小文字の区別を指定する必要があります。レジストリ タイプは、異なるエンティティ クラスのエンティティ名を、異なる大文字と小文字の区別を持つものとして定義してもよい(MAY)。
The element <entity> allows references to entities in result sets, either as a direct child of <resultSet> or within a more complex structure deriving from <result>. The <entity> element is defined by 'entityType'. Registry schemas SHOULD define elements derived from <entity> when referencing entities but may use the <entity> element directly. Deriving a new element allows a registry schema to use the name of the new element to signify the relationship the referenced entity has with the referrer. A derivative of <entity> MUST NOT be used as a substitute when the <entity> element is declared (such as in the <answer> section of the <resultSet>).
要素 <entity> を使用すると、<resultSet> の直接の子として、または <result> から派生するより複雑な構造内で、結果セット内のエンティティへの参照が可能になります。<entity> 要素は「entityType」によって定義されます。レジストリ スキーマは、エンティティを参照するときに <entity> から派生した要素を定義する必要がありますが、<entity> 要素を直接使用することもできます。新しい要素を派生すると、レジストリ スキーマは新しい要素の名前を使用して、参照されるエンティティとリファラーとの関係を示すことができます。<entity> 要素が宣言されている場合 (<resultSet> の <answer> セクションなど)、<entity> の派生要素を代わりに使用してはなりません (MUST NOT)。
The <entity> element (and elements of type 'entityType') can have child elements of <displayName> with an optional 'language' attribute. These are provided so that servers may provide clients with a more human-friendly description of the entity reference. This is often useful to users navigating referral structures.
<entity> 要素 (およびタイプ「entityType」の要素) には、オプションの「言語」属性を持つ <displayName> の子要素を含めることができます。これらは、サーバーがクライアントにエンティティ参照のより人間にわかりやすい説明を提供できるようにするために提供されます。これは、ユーザーが紹介構造をナビゲートする場合に便利です。
The <entity> element (and its derivations) have the following attributes:
<entity> 要素 (およびその派生要素) には次の属性があります。
o 'authority', 'resolution' (optional), 'registryType', 'entityClass', and 'entityName' -- These attributes specify where the entity may be found.
o 'authority'、'resolution' (オプション)、'registryType'、'entityClass'、および 'entityName' -- これらの属性は、エンティティが見つかる場所を指定します。
o 'temporaryReference' -- This attribute is optional. See Section 4.3.6.
o 'temporaryReference' -- この属性はオプションです。セクション 4.3.6 を参照してください。
o 'referentType' -- This attribute contains the expected type of the entity being referenced and may contain the word "ANY" or a qualified XML name. Unlike the other attributes of <entity>, this attribute is qualified and declared in the IRIS XML namespace. Therefore it will also be qualified with the prefix associated with the IRIS XML namespace (e.g., 'iris:referentType'). This allows clients to recognize entity references using an element derived from <entity>.
o 'referentType' -- この属性には、参照されるエンティティの予期されるタイプが含まれており、単語「ANY」または修飾された XML 名が含まれる場合があります。<entity> の他の属性とは異なり、この属性は IRIS XML 名前空間で修飾され、宣言されます。したがって、IRIS XML 名前空間に関連付けられたプレフィックス (例: 'iris:referentType') でも修飾されます。これにより、クライアントは <entity> から派生した要素を使用してエンティティ参照を認識できるようになります。
o 'bagRef' -- This attribute is optional. If present, it must contain an XML identifier to a <bag> element in the <bags> section of the result set. For a description of the 'bagRef' attribute, see Section 4.4.
o 'bagRef' -- この属性はオプションです。存在する場合、結果セットの <bags> セクションの <bag> 要素への XML 識別子が含まれている必要があります。「bagRef」属性の説明については、セクション 4.4 を参照してください。
Instances may exist in which an entity reference needs to be temporary. For example, a particular type of result may only have one unique key. If that key contains semantic meaning that may not be exposed to all users, a synthetic key will have to be substituted.
エンティティ参照を一時的にする必要があるインスタンスが存在する場合があります。たとえば、特定の種類の結果には一意のキーが 1 つしかない場合があります。そのキーにすべてのユーザーに公開されない可能性のある意味的な意味が含まれている場合は、合成キーを置き換える必要があります。
Furthermore, there may be times when data in the data store is not normalized in the same manner as that expressed by the registry schema. In the registry schema, objects of type A may reference objects of type B. But in the data store, objects of type A may contain objects of type B. Again, a synthetic key will have to be temporarily produced.
さらに、データ ストア内のデータがレジストリ スキーマで表現されるのと同じ方法で正規化されない場合があります。レジストリ スキーマでは、タイプ A のオブジェクトがタイプ B のオブジェクトを参照する場合があります。しかし、データ ストアでは、タイプ A のオブジェクトにタイプ B のオブジェクトが含まれる場合があります。ここでも、合成キーを一時的に生成する必要があります。
To support such use cases, results and entity references can be declared temporary by using the 'temporaryReference' attribute. This attribute is of type boolean [4] and has a default value of "false". It is optional for <result> derivatives and elements of type 'entityType'.
このようなユースケースをサポートするには、「temporaryReference」属性を使用して結果とエンティティ参照を一時的に宣言できます。この属性はブール型 [4] で、デフォルト値は「false」です。<result> 派生物およびタイプ「entityType」の要素の場合はオプションです。
When this attribute is used, the entity reference data (e.g., 'entityClass', 'entityName') is only valid within the response in which it appears and may not be consistent with subsequent responses. A server MUST include the referent of any temporary entity reference in the <additional> section of the same <resultSet>
この属性が使用される場合、エンティティ参照データ (例: 「entityClass」、「entityName」) は、それが表示される応答内でのみ有効であり、後続の応答と一致しない可能性があります。サーバーは、同じ <resultSet> の <Additional> セクションに一時エンティティ参照の参照先を含めなければなりません (MUST)。
The base IRIS framework contains three elements directly derived from the <result> element for use by any registry type.
基本 IRIS フレームワークには、任意のレジストリ タイプで使用できる <result> 要素から直接派生した 3 つの要素が含まれています。
An example of a <serviceIdentification> result:
<serviceIdentification> の結果の例:
<serviceIdentification
authority="example.com" registryType="dreg1"
entityClass="iris"
entityName="id" >
<authorities>
<authority> example.com </authority>
<authority> example.net </authority>
<authority> example.org </authority>
</authorities>
<operatorName>
Internet Assigned Numbers Authority
</operatorName>
<eMail>
iana@iana.org
</eMail>
</serviceIdentification>
The <serviceIdentification> element is provided to allow IRIS clients to reference IRIS service instances. It contains the following elements:
<serviceIdentification> 要素は、IRIS クライアントが IRIS サービス インスタンスを参照できるようにするために提供されます。これには次の要素が含まれます。
o <authorities> -- This element contains one or more <authority> elements. Each <authority> element contains a URI authority component for which the server has results. Although a server MAY only return a partial list of its authority areas, depending on operator policy, it MUST return the authority for which the client has requested.
o <authority> -- この要素には 1 つ以上の <authority> 要素が含まれます。各 <authority> 要素には、サーバーが結果を持つ URI 権限コンポーネントが含まれています。サーバーは、オペレーターのポリシーに応じて、その権限領域の部分的なリストのみを返すことができますが、クライアントが要求した権限を返さなければなりません(MUST)。
o <operatorName> -- This element contains the name of the operator of the server.
o <operatorName> -- この要素には、サーバーのオペレーターの名前が含まれます。
o <eMail> -- These optional elements contain email addresses of the operator of the service instance.
o <eMail> -- これらのオプションの要素には、サービス インスタンスのオペレーターの電子メール アドレスが含まれます。
o <phone> -- These optional elements contain phone numbers of the operator of the service instance.
o <phone> -- これらのオプションの要素には、サービス インスタンスのオペレーターの電話番号が含まれます。
o <seeAlso> -- See Section 4.3.1 for its definition.
o <seeAlso> -- その定義についてはセクション 4.3.1 を参照してください。
An example of a <limits> result:
<limits> の結果の例:
<limits
authority="example.com" registryType="dreg1"
entityClass="iris" entityName="limits">
<totalQueries>
<perHour>2</perHour>
<perDay>15</perDay>
</totalQueries>
<totalResults>
<perHour>25</perHour>
<perDay>200</perDay>
</totalResults>
<totalSessions>
<perHour>2</perHour>
<perDay>15</perDay>
</totalSessions>
</limits>
The <limits> element provides a mechanism allowing a server to inform a client of the limits it may encounter from overuse of the service. The contents describe the service limitations to a client at the current level of access. The contents of this element are as follows:
<limits> 要素は、サーバーがサービスの過剰使用によって発生する可能性のある制限をクライアントに通知できるメカニズムを提供します。内容は、現在のアクセス レベルでのクライアントに対するサービスの制限を説明します。この要素の内容は次のとおりです。
o <totalQueries> -- This element describes the total number of queries that the server will accept. The children of this element indicate this number per unit of time. The children are <perSecond>, <perMinute>, <perHour>, and <perDay>. Each child MUST only appear once as a child of <totalQueries>, but more than one child MAY be present. For example, a server could indicate that it will accept 15 queries a minute but only 60 queries a day.
o <totalQueries> -- この要素は、サーバーが受け入れるクエリの合計数を記述します。この要素の子は、単位時間あたりのこの数を示します。子は <perSecond>、<perMinute>、<perHour>、および <perDay> です。各子は <totalQueries> の子として 1 回だけ出現しなければなりません (MUST) が、複数の子が存在してもよいです。たとえば、サーバーは 1 分間に 15 クエリを受け入れるが、1 日あたり 60 クエリしか受け付けないことを示すことができます。
o <totalResults> -- This element describes the total number of results that the server will send to a client. The children of this element indicate this number per unit of time in the same manner as <totalQueries>.
o <totalResults> -- この要素は、サーバーがクライアントに送信する結果の合計数を記述します。この要素の子は、<totalQueries> と同じ方法で単位時間当たりの数を示します。
o <totalSessions> -- This element describes the total number of sessions that the server will accept from a client. The children of this element indicate this number per unit of time in the same manner as <totalQueries>. The definition of a session is defined the by application transport layer.
o <totalSessions> -- この要素は、サーバーがクライアントから受け入れるセッションの合計数を記述します。この要素の子は、<totalQueries> と同じ方法で単位時間当たりの数を示します。セッションの定義は、アプリケーションのトランスポート層によって定義されます。
o <otherRestrictions> -- This element describes other restrictions that may only be expressible outside of the structured syntax of the other child elements of <limits>. This element may have optional <description> child elements, each with a mandatory 'language' attribute.
o <otherRestrictions> -- この要素は、<limits> の他の子要素の構造化構文の外でのみ表現可能な他の制限を記述します。この要素にはオプションの <description> 子要素が含まれる場合があり、それぞれに必須の「言語」属性が含まれます。
o <seeAlso> -- These elements are provided to reference other entities, such as a <simpleEntity> (Section 4.3.7.3) describing a published policy. See <seeAlso> (Section 4.3.1).
o <seeAlso> -- これらの要素は、公開されたポリシーを記述する <simpleEntity> (セクション 4.3.7.3) など、他のエンティティを参照するために提供されます。<seeAlso> (セクション 4.3.1) を参照してください。
All of these child elements are optional, and a server may express that it has no limits by using a <limits> element with no content (e.g., <limits authority=... />).
これらの子要素はすべてオプションであり、サーバーは内容のない <limits> 要素を使用して制限がないことを表現できます (例: <limits authoritation=... />)。
An example of a <simpleEntity> result:
<simpleEntity> の結果の例:
<simpleEntity
authority="example.com" registryType="dreg1"
entityClass="local"
entityName="notice" >
<property name="legal" language="en">
Example.com is reserved according to RFC 2606.
</property>
</simpleEntity>
The <simpleEntity> element is provided so that service operators may make simple additions to other entities without deriving entirely new registry types. Its definition allows service operators to reference it from other entities (using, for instance, a <seeAlso> element). The <simpleEntity> is meant to represent name and value pairs of strings, allowing each pair to be associated with a specific language qualifier and an optional URI pointing to more information.
<simpleEntity> 要素は、サービス オペレーターがまったく新しいレジストリ タイプを派生せずに他のエンティティに簡単に追加できるように提供されています。その定義により、サービス オペレーターは他のエンティティからそれを参照できます (たとえば、<seeAlso> 要素を使用)。<simpleEntity> は、文字列の名前と値のペアを表すことを目的としており、各ペアを特定の言語修飾子と詳細情報を指すオプションの URI に関連付けることができます。
Clients may easily display such information in a two-column table. Applications using binary data or richer data structures are out of scope for this element. When such usage scenarios arise, a client will likely need specific knowledge to handle such data, thus calling the need for a new registry type into question.
クライアントは、そのような情報を 2 列の表に簡単に表示できます。バイナリ データまたはより豊富なデータ構造を使用するアプリケーションは、この要素の範囲外です。このような使用シナリオが発生した場合、クライアントはそのようなデータを処理するための特定の知識を必要とする可能性があり、新しいレジストリ タイプの必要性が疑問視されます。
The <control> (Section 4.1) and <reaction> (Section 4.2) elements allow the client to request from the server special states for the processing of queries. The intent of these elements is to allow extensibility so that some jurisdictions may adopt policies for query processing without requiring re-versioning of IRIS or any registry type.
<control> (セクション 4.1) 要素と <reaction> (セクション 4.2) 要素を使用すると、クライアントはクエリの処理のための特別な状態をサーバーに要求できます。これらの要素の目的は、IRIS やレジストリ タイプの再バージョンを必要とせずに、一部の管轄区域でクエリ処理のポリシーを採用できるように拡張性を持たせることです。
This document defines one control, <onlyCheckPermissions>, and its requisite reaction, <standardReaction>, for compliance with CRISP [17].
この文書は、CRISP [17] に準拠するために、1 つのコントロール <onlyCheckPermissions> とその必須の反応 <standardReaction> を定義します。
When a client sends an <onlyCheckPermissions> control, it is only asking the server to check to see whether adequate permissions are available to execute the queries in the associated request. A server MUST respond to this control with a <standardReaction> element.
クライアントが <onlyCheckPermissions> コントロールを送信するときは、関連付けられたリクエスト内のクエリを実行するための適切なアクセス許可が利用可能かどうかを確認することをサーバーに要求するだけです。サーバーは、<standardReaction> 要素でこのコントロールに応答しなければなりません (MUST)。
The <standardReaction> element provides a server with a standard means to respond to controls (it may be used by other controls, but this is left to their definition). It contains four children:
<standardReaction> 要素は、サーバーにコントロールに応答するための標準的な手段を提供します (他のコントロールによって使用される可能性がありますが、これはその定義に任されます)。これには 4 つの子が含まれます。
o <controlAccepted> -- the processing or state needed by the control has been accepted.
o <controlAccepted> -- コントロールに必要な処理または状態が受け入れられました。
o <controlDenied> -- the processing or state needed by the control has been denied (a transient failure).
o <controlDenied> -- コントロールに必要な処理または状態が拒否されました (一時的な障害)。
o <controlDisabled> -- the processing or state needed by the control cannot be activated (a permanent failure).
o <controlDisabled> -- コントロールに必要な処理または状態をアクティブ化できません (永続的な障害)。
o <controlUnrecognized> -- the control is not recognized (a permanent failure).
o <controlUnrecognized> -- コントロールが認識されません (永続的なエラー)。
If <onlyCheckPermissions> is rejected, then the server MUST return all appropriate result sets (i.e., for every search set in the request), but all result sets MUST be empty of results and MUST contain no errors (a reaction is not part of a result set and is therefore not a result set error). This control applies to all search sets or none of them; therefore a server MUST issue a rejection if <onlyCheckPermissions> cannot be accepted for all search sets in a request.
<onlyCheckPermissions> が拒否された場合、サーバーはすべての適切な結果セット (つまり、リクエスト内のすべての検索セット) を返さなければなりません (MUST)。ただし、すべての結果セットには結果が空でなければならず、エラーが含まれていてはなりません (反応は応答の一部ではありません)。結果セットであるため、結果セット エラーではありません)。このコントロールは、すべての検索セットに適用されるか、またはいずれにも適用されません。したがって、リクエスト内のすべての検索セットに対して <onlyCheckPermissions> を受け入れることができない場合、サーバーは拒否を発行しなければなりません (MUST)。
An example of an IRIS XML exchange using these elements follows:
これらの要素を使用した IRIS XML 交換の例は次のとおりです。
C: <?xml version="1.0"?>
C: <request xmlns="urn:ietf:params:xml:ns:iris1"
C: xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" >
C:
C: <control>
C: <onlyCheckPermissions />
C: </control>
C:
C: <searchSet>
C:
C: <lookupEntity
C: registryType="dreg1"
C: entityClass="local"
C: entityName="AUP" />
C:
C: </searchSet>
C:
C: </request>
S: <?xml version="1.0"?>
S: <response xmlns="urn:ietf:params:xml:ns:iris1"
S: xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" >
S:
S: <reaction>
S: <standardReaction>
S: <controlAccepted />
S: </standardReaction>
S: </reaction>
S:
S: <resultSet>
S: <answer>
S:
S: <simpleEntity
S: authority="example.com" registryType="dreg1"
S: entityClass="local" entityName="AUP" >
S: <property name="legal" language="en">
S: It is illegal to use information from this service
S: for the purposes of sending unsolicited bulk email.
S: </property>
S: </simpleEntity>
S:
S: </answer>
S: </resultSet>
S:
S: </response>
IRIS employs bags to allow a server to relay information to a referent server via the client. These bags are generated by the queried server, passed to the client as opaque data, and then passed to the referent server for processing. The contents of the bags are not defined by IRIS, and the client MUST NOT make any assumptions about the contents of a bag when relaying it from one server to another.
IRIS はバッグを使用して、サーバーがクライアント経由で参照先サーバーに情報を中継できるようにします。これらのバッグは、クエリされたサーバーによって生成され、不透明なデータとしてクライアントに渡され、その後、処理のために参照先サーバーに渡されます。バッグの内容は IRIS によって定義されていないため、クライアントはバッグをあるサーバーから別のサーバーに中継するときにバッグの内容についていかなる仮定も行ってはなりません (MUST NOT)。
When a server returns a result set to a client, the <response> element may contain a <bags> child element. This child element contains one or more <bag> elements. Each of these MUST contain an 'id' attribute containing the XML data type ID. Entity references and search continuations that have to specify a bag to be used when they are followed MUST have a 'bagRef' attribute containing the XML data type IDREF. See Section 4.2. This allows the response to specify a bag only once but allows each entity reference or search continuation (in all result sets) to have a distinct bag, as needed.
サーバーが結果セットをクライアントに返すとき、<response> 要素には <bags> 子要素が含まれる場合があります。この子要素には 1 つ以上の <bag> 要素が含まれます。これらのそれぞれには、XML データ型 ID を含む 'id' 属性が含まれなければなりません (MUST)。エンティティ参照と検索継続は、それらをたどるときに使用されるバッグを指定する必要がありますが、XML データ型 IDREF を含む 'bagRef' 属性を持たなければなりません。セクション 4.2 を参照してください。これにより、応答でバッグを指定できるのは 1 回だけですが、必要に応じて、各エンティティ参照または検索継続 (すべての結果セット内) が個別のバッグを持つことができます。
When following an entity reference or search continuation that specifies the use of a bag, the client MUST include the referenced bag in the search set as a child of the <searchSet> element. See Section 4.1.
バッグの使用を指定するエンティティ参照または検索継続を続ける場合、クライアントは参照されるバッグを <searchSet> 要素の子として検索セットに含めなければなりません (MUST)。セクション 4.1 を参照してください。
See Section 4.2 for the list of errors a server may return to a client when a bag is received. A server MUST NOT ignore a bag when it is received. In case a bag cannot be recognized or accepted, one of the errors from Section 4.2 MUST be returned.
バッグの受信時にサーバーがクライアントに返す可能性のあるエラーのリストについては、セクション 4.2 を参照してください。サーバーはバッグを受け取ったときにそれを無視してはなりません。バッグが認識できない、または受け入れられない場合は、セクション 4.2 のエラーのいずれかを返さなければなりません。
An example of an IRIS XML exchange using these elements follows:
これらの要素を使用した IRIS XML 交換の例は次のとおりです。
C: <?xml version="1.0"?>
C: <request xmlns="urn:ietf:params:xml:ns:iris1"
C: xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" >
C:
C: <searchSet>
C:
C: <bag>
C: <simpleBag xmlns="http://example.com/">
C: XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
C: </simpleBag>
C: </bag>
C:
C: <lookupEntity
C: registryType="dreg1"
C: entityClass="local"
C: entityName="AUP" />
C:
C: </searchSet>
C:
C: </request>
S: <?xml version="1.0"?>
S: <response xmlns="urn:ietf:params:xml:ns:iris1"
S: xmlns:iris="urn:ietf:params:xml:ns:iris1"
S: xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" >
S:
S: <resultSet>
S: <answer>
S:
S: <entity authority="example.com" bagRef="x1"
S: registryType="dreg1"
S: entityClass="local" entityName="AUP"
S: iris:referentType="ANY" >
S: <displayName language="en">
S: Acceptable Usage Policy
S: </displayName>
S: </entity>
S:
S: </answer>
S: </resultSet>
S:
S: <bags>
S:
S: <bag id="x1">
S: <simpleBag xmlns="http://example.com/">
S: AAAAB3NzaC1yc2EAAAABIwAAAIEA0ddD+W3Agl0Lel98G1r77fZ
S: </simpleBag>
S: </bag>
S:
S: </bags>
S: </response>
This section describes a method for serializing IRIS registry entities. The descriptions contained within this section refer to XML elements and attributes and their relation to this serialization process. These descriptions also contain specifications outside the scope of the formal XML syntax. This section will use terms defined by RFC 2119 [8] to describe these. While reading this section, please reference Section 6 for needed details on the formal XML syntax.
このセクションでは、IRIS レジストリ エンティティをシリアル化する方法について説明します。このセクション内の説明では、XML 要素と属性、およびこのシリアル化プロセスとの関係について説明します。これらの説明には、正式な XML 構文の範囲外の仕様も含まれています。このセクションでは、RFC 2119 [8] で定義された用語を使用してこれらを説明します。このセクションを読みながら、正式な XML 構文に関する必要な詳細についてはセクション 6 を参照してください。
A database of IRIS entities can be serialized to file storage with XML [2] by using the IRIS defined <serialization> element. This element contains <result> element derivatives and <serializedReferral> elements.
IRIS エンティティのデータベースは、IRIS で定義された <serialization> 要素を使用して、XML [2] でファイル ストレージにシリアル化できます。この要素には、<result> 要素の派生要素と <serializedReferral> 要素が含まれます。
Derivatives of the <result> element are entities. Servers loading these entities MUST place the entity in the entity classes specified by the elements 'registryType', 'entityClass', and 'entityName' attributes and in any entity classes the entities may apply according to explicitly defined children of that element. For instance, if a registry type has two entity classes "foo" and "bar" and a <result> derivative has the attributes entityClass="foo" and entityName="one" and a child element <bar>two</bar>, the server is to enter that entity into the entity class "foo" as the name "one" and into the entity class "bar" as the name "two".
<result> 要素の派生はエンティティです。これらのエンティティをロードするサーバーは、要素 'registryType'、'entityClass'、および 'entityName' 属性によって指定されたエンティティ クラスにエンティティを配置する必要があり、エンティティはどのエンティティ クラスでも、その要素の明示的に定義された子に従って適用できます。たとえば、レジストリ タイプに 2 つのエンティティ クラス "foo" と "bar" があり、<result> 派生クラスに属性entityClass="foo" とentityName="one" および子要素 <bar>two</bar> があるとします。の場合、サーバーはそのエンティティをエンティティ クラス "foo" に名前 "one" として入力し、エンティティ クラス "bar" に名前 "two" として入力します。
Servers loading entities as serialized derivatives of the <result> element MAY translate the authority attribute. Servers will likely have to do this if the authority for the entity has changed.
<result> 要素のシリアル化された派生物としてエンティティをロードするサーバーは、authority 属性を変換してもよい (MAY)。エンティティの権限が変更された場合、サーバーはこれを行う必要がある可能性があります。
<serializedReferral> elements allow the serialization of explicit entity references and search continuations. This element has a child <source> element containing the 'authority', 'resolution' (optional), 'registryType', 'entityClass', and 'entityName' attributes. The attributes of this element are used to signify the entity that can be referenced to yield this referral.
<serializedReferral> 要素を使用すると、明示的なエンティティ参照と検索の継続をシリアル化できます。この要素には、「authority」、「resolution」（オプション）、「registryType」、「entityClass」、および「entityName」属性を含む子 <source> 要素があります。この要素の属性は、この紹介を生成するために参照できるエンティティを示すために使用されます。
As mentioned above, there may be times when a server needs to translate the authority attribute of a loaded entity. Implementations must also beware of this need for referrals. During deserialization, servers MUST change the authority attribute of a referral (either <entity> or elements derived from <entity> or <source> child of <serializedReferral>) to contain a valid authority of the server if the serialized attribute is empty. During serialization, servers and their related processes MUST leave the authority attribute empty for referrals in which the referent is an entity for which the server answers queries.
上で述べたように、サーバーはロードされたエンティティの権限属性を変換する必要がある場合があります。実装では、この紹介の必要性にも注意する必要があります。逆シリアル化中、サーバーは、シリアル化された属性が空の場合、サーバーの有効な権限を含むように、参照の権限属性 (<entity> または <entity> から派生した要素、または <serializedReferral> の子の <source> のいずれか) を変更しなければなりません (MUST)。シリアル化中、サーバーとその関連プロセスは、参照対象がサーバーがクエリに応答するエンティティである参照に対して、authority 属性を空のままにしなければなりません (MUST)。
The following is an example of serialized IRIS:
以下はシリアル化された IRIS の例です。
<iris:serialization
xmlns:iris="urn:ietf:params:xml:ns:iris1"
xmlns="urn:ietf:params:xml:ns:iris1"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<serviceIdentification
authority="iana.org" registryType="dreg1"
entityClass="iris"
entityName="id" >
<authorities>
<authority> iana.org </authority>
</authorities>
<operatorName>
Internet Assigned Numbers Authority
</operatorName>
<eMail>
dbarton@iana.org
</eMail>
<seeAlso
iris:referentType="iris:simpleEntity"
authority="iana.org" registryType="dreg1"
entityClass="local"
entityName="notice">
<displayName language="en">
Legal Notice
</displayName>
</seeAlso>
</serviceIdentification>
<serializedReferral>
<source
authority="example.com" registryType="dreg1"
entityClass="iris"
entityName="id"/>
<entity
iris:referentType="iris:serviceIdentification"
authority="iana.org" registryType="dreg1"
entityClass="iris" entityName="id"/>
</serializedReferral>
<simpleEntity
authority="iana.org" registryType="dreg1"
entityClass="local"
entityName="notice" >
<property name="legal" language="en">
Please use the net wisely!
</property>
</simpleEntity>
</iris:serialization>
IRIS is specified in XML Schema notation. The formal syntax presented here is a complete schema representation of IRIS suitable for automated validation of IRIS XML instances.
IRIS は XML スキーマ表記で指定されます。ここで示す正式な構文は、IRIS XML インスタンスの自動検証に適した IRIS の完全なスキーマ表現です。
<?xml version="1.0"?>
<schema xmlns="http://www.w3.org/2001/XMLSchema"
xmlns:iris="urn:ietf:params:xml:ns:iris1"
targetNamespace="urn:ietf:params:xml:ns:iris1"
elementFormDefault="qualified" >
<annotation>
<documentation>
Internet Registry Information Service (IRIS) Schema v1
</documentation>
</annotation>
<!-- ========================================= -->
<!-- -->
<!-- The Transactions -->
<!-- -->
<!-- ========================================= -->
<element name="request">
<complexType>
<sequence>
<element
name="control"
type="iris:controlType"
minOccurs="0"
maxOccurs="1" />
<element
name="searchSet"
type="iris:searchSetType"
minOccurs="1"
maxOccurs="unbounded" />
</sequence>
</complexType>
</element>
<element name="response">
<complexType>
<sequence>
<element
name="reaction"
type="iris:reactionType"
minOccurs="0"
maxOccurs="1" />
<element
name="resultSet"
type="iris:resultSetType"
minOccurs="1"
maxOccurs="unbounded" />
<element
name="bags"
type="iris:bagsType"
minOccurs="0"
maxOccurs="1" />
</sequence>
</complexType>
</element>
<!-- ========================================= -->
<!-- -->
<!-- Search Sets and Result Sets -->
<!-- -->
<!-- ========================================= -->
<complexType
name="searchSetType" >
<sequence>
<element
name="bag"
type="iris:bagType"
minOccurs="0"
maxOccurs="1" />
<choice>
<element
name="lookupEntity"
type="iris:lookupEntityType" />
<element
ref="iris:query" />
</choice>
</sequence>
</complexType>
<complexType
name="resultSetType" >
<sequence>
<element
name="answer"
minOccurs="1"
maxOccurs="1">
<complexType>
<sequence>
<element
ref="iris:result"
minOccurs="0"
maxOccurs="unbounded" />
<element
ref="iris:entity"
minOccurs="0"
maxOccurs="unbounded" />
<element
ref="iris:searchContinuation"
minOccurs="0"
maxOccurs="unbounded" />
</sequence>
</complexType>
</element>
<element
name="additional"
minOccurs="0"
maxOccurs="1">
<complexType>
<sequence>
<element
ref="iris:result"
minOccurs="1"
maxOccurs="unbounded" />
</sequence>
</complexType>
</element>
<choice
minOccurs="0"
maxOccurs="1" >
<element
name="insufficientResources"
type="iris:codeType" />
<element
name="invalidName"
type="iris:codeType" />
<element
name="invalidSearch"
type="iris:codeType" />
<element
name="queryNotSupported"
type="iris:codeType" />
<element
name="limitExceeded"
type="iris:codeType" />
<element
name="nameNotFound"
type="iris:codeType" />
<element
name="permissionDenied"
type="iris:codeType" />
<element
name="bagUnrecognized"
type="iris:codeType" />
<element
name="bagUnacceptable"
type="iris:codeType" />
<element
name="bagRefused"
type="iris:codeType" />
<element
ref="iris:genericCode"/>
</choice>
</sequence>
</complexType>
<!-- ========================================= -->
<!-- -->
<!-- Controls and Reactions -->
<!-- -->
<!-- ========================================= -->
<complexType
name="controlType">
<sequence>
<any
namespace="##any"
processContents="skip"
minOccurs="1"
maxOccurs="1" />
</sequence>
</complexType>
<complexType
name="reactionType">
<sequence>
<any
namespace="##any"
processContents="skip"
minOccurs="1"
maxOccurs="1" />
</sequence>
</complexType>
<!-- ========================================= -->
<!-- -->
<!-- Queries and Lookups -->
<!-- -->
<!-- ========================================= -->
<complexType
name="queryType" />
<element
name="query"
type="iris:queryType"
abstract="true" />
<complexType
name="lookupEntityType" >
<attribute
name="registryType"
type="anyURI"
use="required" />
<attribute
name="entityClass"
type="token"
use="required" />
<attribute
name="entityName"
type="token"
use="required" />
</complexType>
<!-- ========================================= -->
<!-- -->
<!-- Results -->
<!-- -->
<!-- ========================================= -->
<complexType
name="resultType">
<attribute
name="authority"
use="required"
type="token" />
<attribute
name="resolution"
type="token" />
<attribute
name="registryType"
use="required"
type="anyURI" />
<attribute
name="entityClass"
use="required"
type="token" />
<attribute
name="entityName"
use="required"
type="token" />
<attribute
name="temporaryReference"
default="false"
type="boolean" />
</complexType>
<element
name="result"
type="iris:resultType"
abstract="true" />
<!-- ========================================= -->
<!-- -->
<!-- Errors -->
<!-- -->
<!-- ========================================= -->
<complexType
name="codeType">
<sequence
minOccurs="0"
maxOccurs="unbounded">
<element
name="explanation">
<complexType>
<simpleContent>
<extension
base="string">
<attribute
use="required"
name="language"
type="language" />
</extension>
</simpleContent>
</complexType>
</element>
</sequence>
</complexType>
<element
name="genericCode"
type="iris:codeType"
abstract="true" />
<!-- ========================================= -->
<!-- -->
<!-- Entity References and -->
<!-- Search Continuations -->
<!-- -->
<!-- ========================================= -->
<complexType
name="entityType">
<sequence>
<element
name="displayName"
minOccurs="0"
maxOccurs="unbounded">
<complexType>
<simpleContent>
<extension
base="string">
<attribute
name="language"
use="required"
type="language" />
</extension>
</simpleContent>
</complexType>
</element>
</sequence>
<attribute
name="authority"
use="required"
type="token" />
<attribute
name="resolution"
type="token" />
<attribute
name="registryType"
use="required"
type="anyURI" />
<attribute
name="entityClass"
use="required"
type="token" />
<attribute
name="entityName"
use="required"
type="token" />
<attribute
name="referentType"
use="required"
form="qualified"
type="iris:referentTypeType" />
<attribute
name="temporaryReference"
default="false"
type="boolean" />
<attribute
name="bagRef"
type="IDREF" />
</complexType>
<element
name="entity"
type="iris:entityType" />
<simpleType
name="referentTypeType">
<union
memberTypes="QName iris:anyLiteralType" />
</simpleType>
<simpleType
name="anyLiteralType">
<restriction
base="string">
<enumeration
value="ANY" />
</restriction>
</simpleType>
<complexType
name="searchContinuationType">
<sequence>
<element ref="iris:query" />
</sequence>
<attribute
name="bagRef"
type="IDREF" />
<attribute
name="authority"
type="token"
use="required" />
<attribute
name="resolution"
type="token" />
</complexType>
<element
name="searchContinuation"
type="iris:searchContinuationType" />
<!-- ========================================= -->
<!-- -->
<!-- Bags -->
<!-- -->
<!-- ========================================= -->
<complexType
name="bagsType">
<sequence>
<element
name="bag"
minOccurs="1"
maxOccurs="unbounded">
<complexType>
<complexContent>
<extension
base="iris:bagType">
<attribute
use="required"
name="id"
type="ID" />
</extension>
</complexContent>
</complexType>
</element>
</sequence>
</complexType>
<complexType
name="bagType">
<sequence>
<any
namespace="##any"
processContents="skip"
minOccurs="1"
maxOccurs="1" />
</sequence>
</complexType>
<!-- ========================================= -->
<!-- -->
<!-- Derived Results for use with all -->
<!-- registry types. -->
<!-- -->
<!-- ========================================= -->
<!-- -->
<!-- See Also -->
<!-- -->
<element
name="seeAlso"
type="iris:entityType" />
<!-- -->
<!-- Service Identification -->
<!-- -->
<complexType
name="serviceIdentificationType">
<complexContent>
<extension
base="iris:resultType">
<sequence>
<element
name="authorities"
minOccurs="1"
maxOccurs="1">
<complexType>
<sequence>
<element
name="authority"
type="token"
minOccurs="1"
maxOccurs="unbounded" />
</sequence>
</complexType>
</element>
<element
name="operatorName"
type="string"
minOccurs="0"
maxOccurs="1" />
<element
name="eMail"
type="string"
minOccurs="0"
maxOccurs="unbounded" />
<element
name="phone"
type="string"
minOccurs="0"
maxOccurs="unbounded" />
<element
ref="iris:seeAlso"
minOccurs="0"
maxOccurs="unbounded" />
</sequence>
</extension>
</complexContent>
</complexType>
<element
name="serviceIdentification"
type="iris:serviceIdentificationType"
substitutionGroup="iris:result" />
<!-- -->
<!-- Limits -->
<!-- -->
<complexType
name="limitsType">
<complexContent>
<extension
base="iris:resultType">
<sequence>
<element
name="totalQueries"
minOccurs="0"
maxOccurs="1" >
<complexType>
<group
ref="iris:timeLimitsGroup"
minOccurs="1"
maxOccurs="4" />
</complexType>
</element>
<element
name="totalResults"
minOccurs="0"
maxOccurs="1" >
<complexType>
<group
ref="iris:timeLimitsGroup"
minOccurs="1"
maxOccurs="4" />
</complexType>
</element>
<element
name="totalSessions"
minOccurs="0"
maxOccurs="1" >
<complexType>
<group
ref="iris:timeLimitsGroup"
minOccurs="1"
maxOccurs="4" />
</complexType>
</element>
<element
name="otherRestrictions"
minOccurs="0"
maxOccurs="1">
<complexType>
<sequence>
<element
name="description"
minOccurs="0"
maxOccurs="unbounded">
<complexType>
<simpleContent>
<extension
base="string">
<attribute
name="language"
type="language"
use="required" />
</extension>
</simpleContent>
</complexType>
</element>
</sequence>
</complexType>
</element>
<element
ref="iris:seeAlso"
minOccurs="0"
maxOccurs="unbounded" />
</sequence>
</extension>
</complexContent>
</complexType>
<element
name="limits"
type="iris:limitsType"
substitutionGroup="iris:result" />
<group
name="timeLimitsGroup">
<choice>
<element
name="perSecond"
type="nonNegativeInteger" />
<element
name="perMinute"
type="nonNegativeInteger" />
<element
name="perHour"
type="nonNegativeInteger" />
<element
name="perDay"
type="nonNegativeInteger" />
</choice>
</group>
<!-- -->
<!-- Simple Entity -->
<!-- -->
<complexType
name="simpleEntityType">
<complexContent>
<extension
base="iris:resultType">
<sequence>
<element
name="property"
minOccurs="1"
maxOccurs="unbounded">
<complexType>
<simpleContent>
<extension
base="string">
<attribute
name="name"
type="string"
use="required" />
<attribute
name="language"
type="language"
use="required" />
<attribute
name="uri"
type="anyURI" />
</extension>
</simpleContent>
</complexType>
</element>
</sequence>
</extension>
</complexContent>
</complexType>
<element
name="simpleEntity"
type="iris:simpleEntityType"
substitutionGroup="iris:result" />
<!-- ========================================= -->
<!-- -->
<!-- Derived Controls and Reactions -->
<!-- -->
<!-- ========================================= -->
<!-- -->
<!-- Only Check Permissions -->
<!-- -->
<element
name="onlyCheckPermissions" >
<complexType />
</element>
<!-- -->
<!-- Standard Reaction -->
<!-- -->
<element
name="standardReaction" >
<complexType>
<choice>
<element
name="controlAccepted">
<complexType/>
</element>
<element
name="controlDenied">
<complexType/>
</element>
<element
name="controlDisabled">
<complexType/>
</element>
<element
name="controlUnrecognized">
<complexType/>
</element>
</choice>
</complexType>
</element>
<!-- ========================================= -->
<!-- -->
<!-- Serialization -->
<!-- -->
<!-- ========================================= -->
<complexType
name="serializedReferralType">
<sequence>
<element name="source">
<complexType>
<attribute
name="authority"
use="required"
type="token" />
<attribute
name="resolution"
type="token" />
<attribute
name="registryType"
type="anyURI"
use="required" />
<attribute
name="entityClass"
type="token"
use="required" />
<attribute
name="entityName"
type="token"
use="required" />
</complexType>
</element>
<choice>
<element
ref="iris:searchContinuation" />
<element
ref="iris:entity" />
</choice>
</sequence>
</complexType>
<element
name="serialization">
<complexType>
<choice
minOccurs="1"
maxOccurs="unbounded">
<element
ref="iris:result" />
<element
name="serializedReferral"
type="iris:serializedReferralType" />
</choice>
</complexType>
</element>
</schema>
</スキーマ>
Figure 8
図8
The IRIS URI has a very rigid structure. All IRIS URIs have the same fields and look similar to users.
IRIS URI は非常に厳格な構造を持っています。すべての IRIS URI には同じフィールドがあり、ユーザーの見た目も似ています。
But the IRIS URIs are flexible because they allow different methods to be employed to find servers and allow the use of multiple transports (with BEEP being the default).
ただし、IRIS URI は、さまざまな方法を使用してサーバーを検索したり、複数のトランスポート (デフォルトは BEEP) を使用したりできるため、柔軟性があります。
An IRIS URI [6] has the following general syntax.
IRIS URI [6] には次の一般的な構文があります。
iris:<registry>/<resolution>/<authority>/<class>/<name>
The full ABNF [11] follows, with certain values included from RFC 2396 [6] and RFC 2732 [15].
完全な ABNF [11] は、RFC 2396 [6] および RFC 2732 [15] からの特定の値を含めて続きます。
iris-uri = scheme ":" registry-urn "/"
[ resolution-method ] "/" authority
[ "/" entity-class "/" entity-name ]
scheme = "iris"
authority = // as specified by RFC2396
registry-urn = // as specified by IRIS
resolution-method = *(unreserved | escaped)
entity-class = *(unreserved | escaped)
entity-name = *(unreserved | escaped)
unreserved = // as specified by RFC2396
escaped = // as specified by RFC2396
An IRIS URI MUST NOT be a relative URI. The resolution method, entity class, and entity name MUST be of the UTF-8 [12] character set encoded with "application/x-www-form-urlencoded", as specified by URL_ENC [14].
IRIS URI は相対 URI であってはなりません。解決方法、エンティティクラス、およびエンティティ名は、URL_ENC [14] で指定されているように、「application/x-www-form-urlencoded」でエンコードされた UTF-8 [12] 文字セットでなければなりません (MUST)。
When the entity-class and entity-name components are not specified, the defaults "iris" and "id" MUST be implied. For example, "iris:dreg1//com" is interpreted as "iris:dreg1//com/iris/id".
エンティティクラスコンポーネントとエンティティ名コンポーネントが指定されていない場合、デフォルトの「iris」と「id」が暗黙的に指定されなければなりません（MUST）。たとえば、「iris:dreg1//com」は「iris:dreg1//com/iris/id」として解釈されます。
When the resolution-method is not specified, the default is the direct resolution method described in Section 7.3.2.
解決方法が指定されていない場合、デフォルトはセクション 7.3.2 で説明されている直接解決方法です。
The "iris" scheme name is not application transport specific. The URI resolution process MAY determine the application transport. An example of such a process is direct resolution (Section 7.3.2), which uses the steps outlined in Section 7.3.3 to determine the application transport.
「iris」スキーム名はアプリケーションのトランスポート固有のものではありません。URI 解決プロセスは、アプリケーションのトランスポートを決定してもよい(MAY)。このようなプロセスの例は、直接解決 (セクション 7.3.2) です。これは、セクション 7.3.3 で概要を説明した手順を使用してアプリケーションのトランスポートを決定します。
A mapping between an application transport and IRIS MAY define a scheme name signifying its use with the semantics of the IRIS URI.
アプリケーショントランスポートと IRIS の間のマッピングでは、IRIS URI のセマンティクスでその使用を示すスキーム名を定義してもよい(MAY)。
The rules for determining which application transport to use are as follows:
どのアプリケーション トランスポートを使用するかを決定するためのルールは次のとおりです。
o If an application transport specific scheme name is present, the application transport it signifies SHOULD be used if possible.
o アプリケーショントランスポート固有のスキーム名が存在する場合、可能であれば、それが示すアプリケーショントランスポートを使用する必要があります(SHOULD)。
o If a client has a preferred transport and the resolution process allows for its use, the client MAY use that application transport.
o クライアントに優先トランスポートがあり、解決プロセスでその使用が許可されている場合、クライアントはそのアプリケーション トランスポートを使用してもよい(MAY)。
o Otherwise, the default application transport specified by IRIS-BEEP [1] MUST be used.
o それ以外の場合は、IRIS-BEEP [1] で指定されたデフォルトのアプリケーション トランスポートを使用しなければなりません (MUST)。
Interpretation and resolution of the authority component of an IRIS URI may be altered with the specification of a resolution-method in the URI. If no resolution-method component is specified in the URI, the default is the direct resolution method (see Section 7.3.2).
IRIS URI の権限コンポーネントの解釈と解決は、URI 内の解決メソッドの仕様によって変更される場合があります。URI で解決方法コンポーネントが指定されていない場合、デフォルトは直接解決方法です (セクション 7.3.2 を参照)。
Alternate resolution methods MAY be specified by registry types. The identifiers for these methods MUST conform to the ABNF in Section 7.1.
代替の解決方法は、レジストリ タイプによって指定できます (MAY)。これらのメソッドの識別子は、セクション 7.1 の ABNF に準拠しなければなりません (MUST)。
In the direct resolution process, the authority component of an IRIS URI may only contain a domain name, a domain name accompanied by a port number, an IP address, or an IP address accompanied by a port number. The authority component of the scheme indicates the server or set of servers authoritatively responsible for a domain according to records in DNS (Section 7.3.3) if a domain is specified. If an IP address is specified, it indicates the specific server to be queried.
直接解決プロセスでは、IRIS URI の権限コンポーネントには、ドメイン名、ポート番号を伴うドメイン名、IP アドレス、またはポート番号を伴う IP アドレスのみを含めることができます。スキームの権限コンポーネントは、ドメインが指定されている場合、DNS のレコード (セクション 7.3.3) に従って、ドメインに対して権限を持つサーバーまたはサーバーのセットを示します。IP アドレスが指定されている場合は、クエリの対象となる特定のサーバーを示します。
The rules for resolution are as follows:
解決のルールは次のとおりです。
o If the authority component is a domain name accompanied by a port number as specified by RFC 2396, the domain name is converted to an IP address via an A or AAAA record to the DNS.
o RFC 2396 で指定されているように、権限コンポーネントがポート番号を伴うドメイン名である場合、ドメイン名は、DNS への A または AAAA レコードを介して IP アドレスに変換されます。
o If the authority component is a domain name by itself, the service/transport location (Section 7.3.3) process is used. If this process produces no results, then the DNS is queried for the A or AAAA RRs corresponding to the domain name, and the port number used is the well-known port of the transport used according to Section 7.2.
o 権限コンポーネント自体がドメイン名である場合、サービス/トランスポートの場所 (セクション 7.3.3) プロセスが使用されます。このプロセスで結果が得られない場合、ドメイン名に対応する A または AAAA RR について DNS が照会され、使用されるポート番号は、セクション 7.2 に従って使用されるトランスポートのウェルノウン ポートです。
o If the authority component is an IP address, then the DNS is not queried, and the IP address is used directly. If the port number is present, it is used directly; otherwise, the port number used is the well-known port of the transport used according to Section 7.2.
o 権限コンポーネントが IP アドレスの場合、DNS は照会されず、IP アドレスが直接使用されます。ポート番号が存在する場合は、それが直接使用されます。それ以外の場合、使用されるポート番号は、セクション 7.2 に従って使用されるトランスポートの既知のポートです。
The use of an IPv6 address in the authority component MUST conform to RFC 2732 [15].
権限コンポーネントでの IPv6 アドレスの使用は、RFC 2732 [15] に準拠しなければなりません (MUST)。
The direct resolution method (Section 7.3.2) uses the profiled use of the NAPTR and SRV resource records defined in S-NAPTR [10] to determine both the location of a set of servers for a given service and the set of possible transports that may be used. It is RECOMMENDED that any resolution method not making explicit use of the direct resolution process should use S-NAPTR [10] in whatever process it does define.
直接解決方法 (セクション 7.3.2) は、S-NAPTR [10] で定義されている NAPTR および SRV リソース レコードのプロファイリングされた使用を使用して、特定のサービスの一連のサーバーの場所と、サービスに使用できる可能なトランスポートのセットの両方を決定します。使用される場合があります。直接解決プロセスを明示的に使用しない解決方法は、定義するプロセスにかかわらず S-NAPTR [10] を使用することが推奨されます。
S-NAPTR [10] requires an application service label. The direct resolution method (Section 7.3.2) uses the abbreviated form of the registry URN as the application service label. Other resolution methods MAY specify other application service labels.
S-NAPTR [10] にはアプリケーション サービス ラベルが必要です。直接解決方法 (セクション 7.3.2) では、レジストリ URN の短縮形をアプリケーション サービス ラベルとして使用します。他の解決方法では、他のアプリケーション サービス ラベルを指定してもよい(MAY)。
See Appendix A for sample uses of S-NAPTR.
S-NAPTR の使用例については、付録 A を参照してください。
Here are some examples of IRIS URIs and their meaning:
IRIS URI の例とその意味をいくつか示します。
o iris:dreg1//example.com/domain/example.com * Finds a server authoritative for "example.com" according to the rules of direct resolution (Section 7.3.2). * The server is asked for "example.com" in the "domain" index, or entity class, of the "dreg1" registry.
o iris:dreg1//example.com/domain/example.com * 直接解決のルール (セクション 7.3.2) に従って、「example.com」に対して権限のあるサーバーを検索します。* サーバーは、「dreg1」レジストリの「ドメイン」インデックスまたはエンティティ クラスで「example.com」を要求されます。
o iris:dreg1//example.com * Finds a server authoritative for "example.com" according to the rules of direct resolution (Section 7.3.2). * The server is asked for "id" in the "iris" index, or entity class, of the "dreg1" registry.
o iris:dreg1//example.com * 直接解決のルール (セクション 7.3.2) に従って、「example.com」に対して権限のあるサーバーを検索します。* サーバーは、「dreg1」レジストリの「iris」インデックス、またはエンティティ クラスの「id」を要求されます。
o iris:dreg1//com/domain/example.com * Finds a server authoritative for "com" according to the rules of direct-resolution (Section 7.3.2). * The server is asked for "example.com" in the "domain" index, or entity class, of the "dreg1" registry.
o iris:dreg1//com/domain/example.com * 直接解決のルール (セクション 7.3.2) に従って、「com」に対して権限のあるサーバーを検索します。* サーバーは、「dreg1」レジストリの「ドメイン」インデックスまたはエンティティ クラスで「example.com」を要求されます。
o iris:dreg1//192.0.2.1:44/domain/example.com * Following the rules of direct-resolution (Section 7.3.2), the server at IP address 192.0.2.1 on port 44 is queried by using BEEP. * The server is asked for "example.com" in the "domain" index, or entity class, of the "dreg1" registry.
o iris:dreg1//192.0.2.1:44/domain/example.com * 直接解決のルール (セクション 7.3.2) に従って、ポート 44 上の IP アドレス 192.0.2.1 のサーバーが BEEP を使用してクエリされます。* サーバーは、「dreg1」レジストリの「ドメイン」インデックスまたはエンティティ クラスで「example.com」を要求されます。
o iris.lwz:dreg1//192.0.2.1:44/domain/example.com * Following the rules of direct-resolution (Section 7.3.2), the server at IP address 192.0.2.1 on port 44 is queried by using a lightweight application transport. * The server is asked for "example.com" in the "domain" index, or entity class, of the "dreg1" registry.
o iris.lwz:dreg1//192.0.2.1:44/domain/example.com * 直接解決のルール (セクション 7.3.2) に従って、ポート 44 上の IP アドレス 192.0.2.1 のサーバーは、軽量のメソッドを使用してクエリされます。アプリケーションのトランスポート。* サーバーは、「dreg1」レジストリの「ドメイン」インデックスまたはエンティティ クラスで「example.com」を要求されます。
o iris.beep:dreg1//com/domain/example.com * Finds a server authoritative for "com" according to the rules of direct-resolution (Section 7.3.2). * Uses the BEEP application transport. * The server is asked for "example.com" in the "domain" index, or entity class, of the "dreg1" registry.
o iris.beep:dreg1//com/domain/example.com * 直接解決のルール (セクション 7.3.2) に従って、「com」に対して権限のあるサーバーを検索します。* BEEP アプリケーション トランスポートを使用します。* サーバーは、「dreg1」レジストリの「ドメイン」インデックスまたはエンティティ クラスで「example.com」を要求されます。
o iris:dreg1/bottom/example.com/domain/example.com * Finds a server authoritative for "example.com" according to the rules of the resolution method 'bottom' as defined by the registry type urn:ietf:params:xml:ns:dreg1. * The application transport used is determined by the 'bottom' resolution method. * The server is asked for "example.com" in the "domain" index, or entity class, of the "dreg1" registry.
o iris:dreg1/bottom/example.com/domain/example.com * レジストリ タイプ urn:ietf:params:xml で定義された解決方法「bottom」のルールに従って、「example.com」に対して権限のあるサーバーを検索します:ns:dreg1。* 使用されるアプリケーション トランスポートは、「ボトム」解決方法によって決定されます。* サーバーは、「dreg1」レジストリの「ドメイン」インデックスまたはエンティティ クラスで「example.com」を要求されます。
o iris.beep:dreg1/bottom/example.com/domain/example.com * Finds a server authoritative for "example.com" according to the rules of the resolution method 'bottom' as defined by the registry type urn:ietf:params:xml:ns:dreg1. * Uses the BEEP application transport. * The server is asked for "example.com" in the "domain" index, or entity class, of the "dreg1" registry.
o iris.beep:dreg1/bottom/example.com/domain/example.com * レジストリ タイプ urn:ietf:params で定義された解決方法 'bottom' のルールに従って、「example.com」に対して権限のあるサーバーを検索します:xml:ns:dreg1。* BEEP アプリケーション トランスポートを使用します。* サーバーは、「dreg1」レジストリの「ドメイン」インデックスまたはエンティティ クラスで「example.com」を要求されます。
Specifications of registry types MUST include the following explicit definitions:
レジストリ タイプの仕様には、次の明示的な定義を含める必要があります。
o Formal XML syntax deriving from the IRIS XML.
o IRIS XML から派生した正式な XML 構文。
o An identifying registry URN.
o 識別するレジストリ URN。
o Any registry specific resolution methods.
o レジストリ固有の解決方法。
o A registration of the abbreviated registry URN as an application service label for compliance with S-NAPTR [10]. Note that this is a different IANA registry than the registry type URN IANA registry.
o S-NAPTR [10] に準拠するためのアプリケーション サービス ラベルとしての短縮レジストリ URN の登録。これは、レジストリ タイプ URN IANA レジストリとは異なる IANA レジストリであることに注意してください。
o A list of well-known entity classes.
o 既知のエンティティ クラスのリスト。
o A statement regarding the case sensitivity of the names in each entity class.
o 各エンティティ クラスの名前の大文字と小文字の区別に関するステートメント。
Specifications of transport mappings MUST include the following explicit definitions:
トランスポート マッピングの仕様には、次の明示的な定義を含める必要があります。
o A URI scheme name specific to the transport.
o トランスポートに固有の URI スキーム名。
o An application protocol label for compliance with S-NAPTR [10]. See Section 7.3.3. Note that although this is a different IANA registry than the URI scheme name IANA registry, it is RECOMMENDED that they be the same string of characters.
o S-NAPTR [10] に準拠するためのアプリケーション プロトコル ラベル。セクション 7.3.3 を参照してください。これは URI スキーム名の IANA レジストリとは異なる IANA レジストリですが、同じ文字列であることが推奨されることに注意してください。
o The set of allowable character set encodings for the exchange of XML (see Section 9).
o XML の交換に使用できる文字セット エンコーディングのセット (セクション 9 を参照)。
o The set of security mechanisms.
o 一連のセキュリティ メカニズム。
IRIS is represented in XML. XML processors are obliged to recognize both UTF-8 and UTF-16 [12] encodings. XML provides for mechanisms to identify and use other character encodings by means of the "encoding" attribute in the <xml> declaration. Absence of this attribute or a byte order mark (BOM) indicates a default of UTF-8 [13] encoding. Thus, for compatibility reasons and per RFC 2277 [16], use of UTF-8 [13] is RECOMMENDED with IRIS.
IRIS は XML で表現されます。XML プロセッサは、UTF-8 と UTF-16 [12] エンコーディングの両方を認識する必要があります。XML は、<xml> 宣言の「encoding」属性によって他の文字エンコーディングを識別して使用するメカニズムを提供します。この属性またはバイト オーダー マーク (BOM) がない場合は、デフォルトの UTF-8 [13] エンコーディングを示します。したがって、互換性の理由と RFC 2277 [16] に従って、IRIS では UTF-8 [13] の使用が推奨されます。
The complete list of character set encoding identifiers is maintained by IANA at [21].
文字セットエンコーディング識別子の完全なリストは、IANA によって [21] で管理されています。
The application-transport layer MUST define a common set of character set encodings to be understood by both client and server.
アプリケーショントランスポート層は、クライアントとサーバーの両方が理解できる文字セットエンコーディングの共通セットを定義しなければなりません(MUST)。
Localization of internationalized strings may require additional information from the client. Entity definitions SHOULD use the "language" type defined by XML_SD [4] to aid clients in the localization process. See Section 4.3.7.3 for an example.
国際化された文字列のローカライズには、クライアントからの追加情報が必要になる場合があります。エンティティ定義は、クライアントのローカリゼーション プロセスを支援するために、XML_SD [4] で定義された「言語」タイプを使用すべきです (SHOULD)。例については、セクション 4.3.7.3 を参照してください。
This document uses a proposed XML namespace and schema registry specified in XML_URN [9]. Accordingly, the following registration information is provided for the IANA:
この文書では、XML_URN [9] で指定されている、提案された XML 名前空間とスキーマ レジストリを使用します。したがって、次の登録情報が IANA に提供されます。
o URN/URI: * urn:ietf:params:xml:ns:iris1 o Contact: * Andrew Newton <andy@hxr.us> * Marcos Sanz <sanz@denic.de> o XML: * The XML Schema specified in Section 6
o URN/URI: * urn:ietf:params:xml:ns:iris1 o 連絡先: * Andrew Newton <andy@hxr.us> * Marcos Sanz <sanz@denic.de> o XML: * セクション 6 で指定された XML スキーマ
The IRIS XML layer provides no authentication or privacy facilities of its own. It relies on the application-transport layer for all of these abilities. Application-transports should explicitly define their security mechanisms (see Section 8.2).
IRIS XML レイヤーは、それ自体の認証機能やプライバシー機能を提供しません。これらすべての機能はアプリケーション トランスポート層に依存しています。アプリケーショントランスポートは、そのセキュリティメカニズムを明示的に定義する必要があります (セクション 8.2 を参照)。
Referral IRIS registry results may contain entity lookups and search continuations that result in a client query operation against another registry service. Clients SHOULD NOT use authentication credentials and mechanisms subject to replay attacks to conduct subsequent entity lookups and search continuations.
参照 IRIS レジストリ結果には、別のレジストリ サービスに対するクライアント クエリ操作を引き起こすエンティティ検索と検索の継続が含まれる場合があります。クライアントは、後続のエンティティ検索や検索の継続を行うために、リプレイ攻撃の対象となる認証資格情報やメカニズムを使用すべきではありません (SHOULD NOT)。
[1] Newton, A. and M. Sanz, "Using the Internet Registry Information Service (IRIS) over the Blocks Extensible Exchange Protocol (BEEP)", RFC 3983, January 2005.
[1] Newton, A. および M. Sanz、「ブロック拡張可能交換プロトコル (BEEP) を介したインターネット レジストリ情報サービス (IRIS) の使用」、RFC 3983、2005 年 1 月。
[2] World Wide Web Consortium, "Extensible Markup Language (XML) 1.0", W3C XML, February 1998, <http://www.w3.org/TR/1998/REC-xml-19980210>.
[2] World Wide Web Consortium、「Extensible Markup Language (XML) 1.0」、W3C XML、1998 年 2 月、<http://www.w3.org/TR/1998/REC-xml-19980210>。
[3] World Wide Web Consortium, "Namespaces in XML", W3C XML Namespaces, January 1999, <http://www.w3.org/TR/1999/REC-xml-names-19990114>.
[3] World Wide Web Consortium、「XML の名前空間」、W3C XML 名前空間、1999 年 1 月、<http://www.w3.org/TR/1999/REC-xml-names-19990114>。
[4] World Wide Web Consortium, "XML Schema Part 2: Datatypes", W3C XML Schema, October 2000, <http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/>.
[4] World Wide Web Consortium、「XML スキーマ パート 2: データ型」、W3C XML スキーマ、2000 年 10 月、<http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/>。
[5] World Wide Web Consortium, "XML Schema Part 1: Structures", W3C XML Schema, October 2000, <http://www.w3.org/TR/2001/REC-xmlschema-1-20010502/>.
[5] World Wide Web Consortium、「XML スキーマ パート 1: 構造」、W3C XML スキーマ、2000 年 10 月、<http://www.w3.org/TR/2001/REC-xmlschema-1-20010502/>。
[6] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1998.
[6] Berners-Lee, T.、Fielding, R.、および L. Masinter、「Uniform Resource Identifiers (URI): Generic Syntax」、RFC 2396、1998 年 8 月。
[7] Moats, R., "URN Syntax", RFC 2141, May 1997.
[7] Moats, R.、「URN 構文」、RFC 2141、1997 年 5 月。
[8] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[8] Bradner, S.、「要件レベルを示すために RFC で使用するキーワード」、BCP 14、RFC 2119、1997 年 3 月。
[9] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, January 2004.
[9] Mealing, M.、「IETF XML Registry」、BCP 81、RFC 3688、2004 年 1 月。
[10] Daigle, L. and A. Newton, "Domain-based Application Service Location Using SRV RRs and the Dynamic Delegation Discovery Service (DDDS)", RFC 3958, January 2005.
[10] Daigle, L. および A. Newton、「SRV RR と動的委任検出サービス (DDDS) を使用したドメインベースのアプリケーション サービスの位置」、RFC 3958、2005 年 1 月。
[11] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997.
[11] Crocker, D. および P. Overell、「構文仕様のための拡張 BNF: ABNF」、RFC 2234、1997 年 11 月。
[12] The Unicode Consortium, "The Unicode Standard, Version 3", ISBN 0-201-61633-5, 2000, <The Unicode Standard, Version 3>.
[12] Unicode コンソーシアム、「The Unicode Standard, Version 3」、ISBN 0-201-61633-5、2000、<The Unicode Standard, Version 3>。
[13] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003.
[13] Yergeau, F.、「UTF-8、ISO 10646 の変換形式」、STD 63、RFC 3629、2003 年 11 月。
[14] Connolly, D. and L. Masinter, "The 'text/html' Media Type", RFC 2854, June 2000.
[14] Connolly, D. および L. Masinter、「The 'text/html' Media Type」、RFC 2854、2000 年 6 月。
[15] Hinden, R., Carpenter, B., and L. Masinter, "Format for Literal IPv6 Addresses in URL's", RFC 2732, December 1999.
[15] Hinden, R.、Carpenter, B.、および L. Masinter、「URL 内のリテラル IPv6 アドレスの形式」、RFC 2732、1999 年 12 月。
[16] Alvestrand, H., "IETF Policy on Character Sets and Languages", BCP 18, RFC 2277, January 1998.
[16] Alvestorm, H.、「文字セットと言語に関する IETF ポリシー」、BCP 18、RFC 2277、1998 年 1 月。
[17] Newton, A., "Cross Registry Internet Service Protocol (CRISP) Requirements", RFC 3707, February 2004.
[17] Newton, A.、「クロス レジストリ インターネット サービス プロトコル (CRISP) 要件」、RFC 3707、2004 年 2 月。
[18] Newton, A. and M. Sanz, "IRIS: A Domain Registry (dreg) Type for the Internet Registry Information Service (IRIS)", RFC 3982, January 2005.
[18] Newton, A. および M. Sanz、「IRIS: インターネット レジストリ情報サービス (IRIS) のドメイン レジストリ (dreg) タイプ」、RFC 3982、2005 年 1 月。
[19] Daigle, L., "WHOIS Protocol Specification", RFC 3912, September 2004.
[19] Daigle, L.、「WHOIS プロトコル仕様」、RFC 3912、2004 年 9 月。
[20] Rose, M., "The Blocks Extensible Exchange Protocol Core", RFC 3080, March 2001.
[20] Rose, M.、「The Blocks Extensible Exchange Protocol Core」、RFC 3080、2001 年 3 月。
URIs
URI
[21] <http://www.iana.org/assignments/character-sets>
This section shows an example of S-NAPTR [10] use by IRIS. In this example, there are two registry types: REGA and REGB. There are also two IRIS application transports: iris-a and iris-b. Given this, the use of S-NAPTR offers the following:
このセクションでは、IRIS で使用される S-NAPTR [10] の例を示します。この例には、REGA と REGB の 2 つのレジストリ タイプがあります。iris-a と iris-b という 2 つの IRIS アプリケーション トランスポートもあります。これを考慮すると、S-NAPTR を使用すると次のことが可能になります。
1. A means by which an operator can split the set of servers running REGA from the set of servers running REGB. This is to say, the operator is able to split out the set of servers serving up data for REGA from the set of servers serving up data for REGB.
1. オペレーターが REGB を実行しているサーバーのセットから REGA を実行しているサーバーのセットを分割できる手段。つまり、オペレータは、REGA のデータを提供するサーバーのセットを REGB のデータを提供するサーバーのセットから分離することができます。
2. A means by which an operator can distinguish the set of servers running iris-a from the set of servers running iris-b. This is to say, the operator is able to split out the set of servers running protocol iris-a serving REGA and REGB data from the set of servers running protocol iris-b serving REGA and REGB data.
2. オペレーターが、iris-a を実行しているサーバーのセットと iris-b を実行しているサーバーのセットを区別できる手段。つまり、オペレータは、REGA および REGB データを提供するプロトコル iris-a を実行するサーバーのセットを、REGA および REGB データを提供するプロトコル iris-b を実行するサーバーのセットから分離することができます。
3. A means by which an operator can specify which set of the servers to operate and which set of the above servers to delegate to another operator.
3. オペレーターが、どのサーバーのセットを操作するか、および上記のサーバーのどのセットを別のオペレーターに委任するかを指定できる手段。
To implement the first feature, the operator deploys the following in his or her DNS zone:
最初の機能を実装するには、オペレーターは自分の DNS ゾーンに次のものを展開します。
example.com.
;; order pref flags service re replacement
IN NAPTR 100 10 "" "REGA:iris-a:iris-b" "" rega.example.com
IN NAPTR 100 10 "" "REGB:iris-a:iris-b" "" regb.example.com
To implement the second feature, the operator then adds the following in their DNS zone:
2 番目の機能を実装するには、オペレーターは DNS ゾーンに以下を追加します。
rega.example.com. ;; order pref flags service re replacement IN NAPTR 100 10 "s" "REGA:iris-a" "" _iris-a._udp.example.com regb.example.com. IN NAPTR 100 10 "s" "REGA:iris-b" "" _iris-b._tcp.example.com
rega.example.com。;;優先フラグ サービスの再交換を注文します。 IN NAPTR 100 10 "s" "REGA:iris-a" "" _iris-a._udp.example.com regb.example.com。IN NAPTR 100 10 "s" "REGA:iris-b" "" _iris-b._tcp.example.com
_iris-a._udp.example.com. ;; pref weight port target IN SRV 10 0 34 big-a.example.com. IN SRV 20 0 34 small-a.example.com.
_iris-a._udp.example.com。;;pref ウェイト ポート ターゲット IN SRV 10 0 34 big-a.example.com。IN SRV 20 0 34 small-a.example.com。
_iris-b._tcp.example.com. ;; pref weight port target IN SRV 10 0 34 big-b.example.com. IN SRV 20 0 34 small-b.example.com.
_iris-b._tcp.example.com。;;pref ウェイト ポート ターゲット IN SRV 10 0 34 big-b.example.com。IN SRV 20 0 34 small-b.example.com。
Finally, an operator may decide to operate the REGA services while delegating the REGB services to somebody else. Here is how that is done:
最後に、オペレータは REGB サービスを他の人に委任しながら REGA サービスを運用することを決定する場合があります。その方法は次のとおりです。
example.com.
;; order pref flags service re replacement
IN NAPTR 100 10 "" "REGA:iris-a:iris-b" "" rega.example.com
IN NAPTR 100 10 "" "REGB:iris-a:iris-b" "" somebodyelse.com
Or the operator may decide to operate REGB services under the iris-a protocol/transport while delegating the REGB services under the iris-b protocol/transport to somebody else.
あるいは、オペレータは、iris-a プロトコル/トランスポートの下で REGB サービスを運用し、iris-b プロトコル/トランスポートの下で REGB サービスを他の誰かに委任することを決定する場合もあります。
example.com. ;; order pref flags service re replacement IN NAPTR 100 10 "" "REGB:iris-a:iris-b" "" regb.example.com IN NAPTR 100 10 "s" "REGB:iris-a" "" _iris-a._udp.example.com IN NAPTR 100 10 "s" "REGB:iris-b" "" _iris-b._tcp.somebodyelse.com
例.com。;;優先フラグ サービスの再交換を注文します。 IN NAPTR 100 10 "" "REGB:iris-a:iris-b" "" regb.example.com IN NAPTR 100 10 "s" "REGB:iris-a" "" _iris-a。_udp.example.com IN NAPTR 100 10 "s" "REGB:iris-b" "" _iris-b._tcp.somebodyelse.com
_iris-a._udp.example.com. ;; pref weight port target IN SRV 10 0 34 big-a.example.com. IN SRV 20 0 34 small-a.example.com.
_iris-a._udp.example.com。;;pref ウェイト ポート ターゲット IN SRV 10 0 34 big-a.example.com。IN SRV 20 0 34 small-a.example.com。
Note that while this last example is possible, it is probably not advisable because of the operational issues involved in synchronizing the data between example.com and somebodyelse.com. It is provided here as an example of what is possible.
この最後の例は可能ですが、example.com と somebodyelse.com 間のデータの同期に伴う運用上の問題のため、おそらくお勧めできません。ここでは、可能なことの一例として示します。
Given the examples in Appendix A.1, the use of S-NAPTR could be part of a transition strategy for cohabitation of protocols solving the problems of CRISP [17].
付録 A.1 の例を考慮すると、S-NAPTR の使用は、CRISP の問題を解決するプロトコルの共存のための移行戦略の一部である可能性があります [17]。
For example, the type of data for domain information could be given the application service label of "DREG1". Given this, the service field of an S-NAPTR compliant NAPTR record could read
たとえば、ドメイン情報のデータのタイプには、「DREG1」というアプリケーション サービス ラベルを与えることができます。これを考慮すると、S-NAPTR 準拠の NAPTR レコードのサービス フィールドは次のようになります。
"DREG1:whois:iris-beep"
「DREG1:whois:アイリスビープ音」
This service field conveys that domain data, as defined by CRISP, is available via both the iris-beep protocol and the whois protocol. The whois application protocol label refers to RFC 954 [19].
このサービス フィールドは、CRISP で定義されているドメイン データが、iris-beep プロトコルと Whois プロトコルの両方を介して利用できることを伝えます。Whois アプリケーション プロトコル ラベルは RFC 954 [19] を参照します。
Beyond the concrete arguments that could be placed behind a thoughtful analysis of the bits flying across the ether, there are other abstract reasons for the development of IRIS. This section attempts an explanation.
エーテル上を飛び交うビットの思慮深い分析の背後にある具体的な議論以外にも、IRIS の開発には抽象的な理由があります。このセクションでは説明を試みます。
IRIS has been designed as a directory service for public-facing registries of Internet resources. The basic premise is this:
IRIS は、インターネット リソースの公開レジストリ用のディレクトリ サービスとして設計されています。基本的な前提は次のとおりです。
o A client should be able to look up any single piece of data from any type of registry. This lookup should involve a straight-forward and consistent definition for finding the registry and should entail a hit to a single data index in the registry.
o クライアントは、あらゆる種類のレジストリから単一のデータを検索できる必要があります。この検索には、レジストリを見つけるための簡単で一貫した定義が含まれている必要があり、レジストリ内の単一のデータ インデックスへのヒットが必要です。
o Anything more, such as searches up and down the DNS tree to find the registry or searches across multiple indexes in a registry, requires a client with special knowledge of the data relationships contained within a registry.
o DNS ツリーを上下に検索してレジストリを見つけたり、レジストリ内の複数のインデックスを検索したりするには、レジストリ内に含まれるデータ関係についての特別な知識を持つクライアントが必要です。
Therefore, IRIS does the following:
したがって、IRIS は次のことを行います。
o It specifies the basic schema language used by all registries to specify their schemas.
o すべてのレジストリがスキーマを指定するために使用する基本的なスキーマ言語を指定します。
o It provides the basic framework for a registry to make a reference to an entity in another type of registry.
o これは、レジストリが別の種類のレジストリ内のエンティティを参照するための基本的なフレームワークを提供します。
And, therefore, IRIS does not do the following:
したがって、IRIS は次のことを行いません。
o It does not specify a common query language across all types of registries. A common query language imposed across multiple types of registries usually results in the disabling of certain functions by a server operator in order to meet acceptable levels of performance, leaving a common query language that does not commonly work.
o すべての種類のレジストリに共通のクエリ言語を指定するわけではありません。複数の種類のレジストリに共通のクエリ言語を適用すると、通常、パフォーマンスの許容レベルを満たすためにサーバー オペレータによって特定の機能が無効になり、通常は機能しない共通のクエリ言語が残ります。
o It does not impose any relationship between sets of data in any type of registry, such as specifying a tree. There are many types of Internet resources, and they do not all share the same style of relationship with their contained sets of data. When it is not a natural fit, an imposition of a common relationship is often a concern and not a benefit.
o ツリーの指定など、あらゆる種類のレジストリ内のデータ セット間に関係を課すことはありません。インターネット リソースには多くの種類があり、含まれるデータ セットとの関係のスタイルがすべて同じというわけではありません。それが自然に適合しない場合、共通の関係を押し付けることは多くの場合懸念であり、利点ではありません。
The design premise of IRIS signifies that, for directory services, there is no such thing as a universal client (or that if there is one, it is commonly called the "web browser").
IRIS の設計前提は、ディレクトリ サービスにはユニバーサル クライアントのようなものは存在しない (または、存在する場合は一般に「Web ブラウザ」と呼ばれる) ことを意味します。
For IRIS, the closest thing to a universal client is one that may "look up" data and may be able to display the data in a rudimentary fashion. For a client to be able to "search" data or display it in a truly user-friendly manner, it must have specific knowledge about the type of data it is retrieving.
IRIS の場合、ユニバーサル クライアントに最も近いものは、データを「検索」し、基本的な方法でデータを表示できるクライアントです。クライアントがデータを「検索」したり、真にユーザーフレンドリーな方法で表示したりできるようにするには、取得するデータの種類に関する特定の知識が必要です。
Attempts to outfit a universal client with a common query language are also not very useful. A common query language may be applied to a specific problem domain, which would require a user to have expertise in both the common query language and the problem domain. In the end, the outcome is usually the development of a client specific to the problem domain but saddled with translation of the user's desires and the lowest-common-denominator aspect of the query language.
汎用クライアントに共通のクエリ言語を装備しようとする試みも、あまり役に立ちません。共通のクエリ言語を特定の問題領域に適用する場合、ユーザーは共通のクエリ言語と問題領域の両方の専門知識を必要とします。最終的には通常、問題領域に特化したクライアントの開発になりますが、ユーザーの要望とクエリ言語の最小公倍数の側面の翻訳が伴います。
As mentioned above, IRIS was designed for the directory service needs of public-facing registries. In this light, certain aspects of more generalized directory services are a hindrance in an environment that does not have the same control and safety considerations as a managed network.
前述したように、IRIS は公開レジストリのディレクトリ サービスのニーズに合わせて設計されました。この観点から見ると、より一般化されたディレクトリ サービスの特定の側面は、管理されたネットワークと同様の制御と安全性の考慮事項がない環境では障害となります。
For instance, a common query language can provide great flexibility to both the power user and the abusive user. An abusive user could easily submit a query across multiple indexes with partial values. Such a query would have no utility other than to cause denial of service to other users. To combat this, a service operator must restrict the types of queries that cause harm to overall performance, and this act obsoletes the benefit of a common query language.
たとえば、共通のクエリ言語は、パワー ユーザーと不正ユーザーの両方に大きな柔軟性を提供できます。不正なユーザーは、部分的な値を含む複数のインデックスにまたがるクエリを簡単に送信する可能性があります。このようなクエリには、他のユーザーにサービス拒否を引き起こす以外の用途はありません。これに対処するには、サービス オペレータは全体的なパフォーマンスに悪影響を与えるクエリの種類を制限する必要があり、これにより共通のクエリ言語の利点が失われてしまいます。
Another consideration for server performance is the lack of a required data relationship. Because sets of data often have differing relationships, a one-size-fits-all approach does not fit well with all types of registries. In addition, public-facing services tend to have service level requirements that cannot reasonably be met by transforming complete data stores from a native format into a format enforcing an artificial set of relationships.
サーバーのパフォーマンスに関するもう 1 つの考慮事項は、必要なデータ関係が欠如していることです。データのセットには異なる関係があることが多いため、画一的なアプローチはすべての種類のレジストリにうまく適合しません。さらに、一般向けサービスには、完全なデータ ストアをネイティブ形式から人工的な一連の関係を強制する形式に変換することによっては合理的に満たすことができないサービス レベル要件がある傾向があります。
To combat these issues, operators of public-facing services tend to create their own custom query parsers and back-end data stores. But doing so brings into question the use of a generalized directory service.
これらの問題に対処するために、一般公開サービスの運営者は独自のカスタム クエリ パーサーやバックエンド データ ストアを作成する傾向があります。しかし、そうすることで、一般化されたディレクトリ サービスの使用に疑問が生じます。
Finally, IRIS is built upon a set of standard technological layers. This allows service operators to switch components to meet the needs of their particular environment.
最後に、IRIS は一連の標準技術層の上に構築されています。これにより、サービス オペレーターは、特定の環境のニーズに合わせてコンポーネントを切り替えることができます。
IRIS supports both lookups and searches. Conceptually, the difference between the two is as follows:
IRIS はルックアップと検索の両方をサポートしています。概念的には、この 2 つの違いは次のとおりです。
A "lookup" is a single query with a discrete value on a single index.
「ルックアップ」は、単一のインデックス上の個別の値を持つ単一のクエリです。
Anything more, such as partial value queries, queries across multiple indexes, or multiple queries to a single index is a "search".
部分的な値のクエリ、複数のインデックスにわたるクエリ、または単一のインデックスに対する複数のクエリなど、それ以外のものはすべて「検索」です。
Lookups are accomplished through the defined query <lookupEntity>. This query specifies a discrete name, called the entity name, to be queried in a single index, called the entity class. Therefore, implementations may consider a type of registry to be composed of multiple indexes, one for each defined entity class.
ルックアップは、定義されたクエリ <lookupEntity> を通じて実行されます。このクエリでは、エンティティ クラスと呼ばれる単一のインデックスでクエリされる、エンティティ名と呼ばれる個別の名前を指定します。したがって、実装では、レジストリのタイプが、定義されたエンティティ クラスごとに 1 つずつ、複数のインデックスで構成されると考える場合があります。
There are no standard searches in IRIS. Each type of registry defines its own set of searches.
IRIS には標準の検索はありません。レジストリの種類ごとに、独自の検索セットが定義されます。
Due to its effect on client behavior and the side effects such behavior may have on servers, IRIS makes a clear distinction between entity references (<entity>) and search continuations (<searchContinuation>). It is not an add-on, but a fundamental core of the protocol.
クライアントの動作への影響と、そのような動作がサーバーに与える副作用のため、IRIS ではエンティティ参照 (<entity>) と検索継続 (<searchContinuation>) を明確に区別しています。これはアドオンではなく、プロトコルの基本的なコアです。
The distinction is very important to a client:
この区別はクライアントにとって非常に重要です。
"Go look over there and you will find what you seek." "Go look over there and you may find what you seek, or you may find some other stuff, or you may find nothing."
「あそこを見に行けば、探しているものが見つかるでしょう。」「あそこに行って見てください、そうすれば探しているものが見つかるかもしれませんし、他のものが見つかるかもしれませんし、何も見つからないかもしれません。」
Finally, because IRIS makes no assumptions about and places no requirements on the relationship of data in a registry, this also extends to data of the same registry type spread across multiple authority areas. This means that IRIS makes no requirements as to the scope of entity references or search continuations. The scope is determined by what the registry type needs and by what the registry type allows a service operator.
最後に、IRIS はレジストリ内のデータの関係について何の仮定も要求もしないため、これは複数の権限領域にまたがる同じレジストリ タイプのデータにも適用されます。これは、IRIS がエンティティ参照または検索継続の範囲に関して要件を設けていないことを意味します。スコープは、レジストリ タイプが必要とするものと、レジストリ タイプがサービス オペレータに許可するものによって決まります。
The terminology used in this document to describe namespaces and namespaces of namespaces is now much clearer thanks to the skillful debate tactics of Leslie Daigle. Previously, it was much more confusing. In addition, Leslie has provided great insight into the details of URIs, URNs, and NAPTR/SRV resource records.
このドキュメントで名前空間と名前空間の名前空間を説明するために使用されている用語は、Leslie Daigle の巧みな議論戦術のおかげで、より明確になりました。以前は、もっと混乱していました。さらに、Leslie は、URI、URN、NAPTR/SRV リソース レコードの詳細について優れた洞察を提供してくれました。
Many other technical complexities were proved unnecessary by David Blacka and have been removed. And his IRIS implementation has helped smooth out the rougher edges.
他の多くの技術的な複雑さは David Blacka によって不必要であることが証明され、削除されました。そして、彼の IRIS 実装は、粗い部分を滑らかにするのに役立ちました。
Authors' Addresses
著者の住所
Andrew L. Newton VeriSign, Inc. 21345 Ridgetop Circle Sterling, VA 20166 USA
Andrew L. Newton VeriSign, Inc. 21345 Ridgetop Circle Sterling, VA 20166 USA
Phone: +1 703 948 3382
EMail: anewton@verisignlabs.com; andy@hxr.us
URI: http://www.verisignlabs.com/
Marcos Sanz DENIC eG Wiesenhuettenplatz 26 D-60329 Frankfurt Germany
Marcos Sanz DENIC eG Wiesenhuettenplatz 26 D-60329 フランクフルト ドイツ
EMail: sanz@denic.de
URI: http://www.denic.de/
Full Copyright Statement
完全な著作権に関する声明
Copyright (C) The Internet Society (2005).
著作権 (C) インターネット協会 (2005)。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書は、BCP 78 に含まれる権利、ライセンス、および制限の対象となり、そこに規定されている場合を除き、著者はすべての権利を保持します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
この文書およびここに含まれる情報は「現状のまま」で提供され、寄稿者、寄稿者が代表または後援する組織（存在する場合）、インターネット協会およびインターネット エンジニアリング タスク フォースは、明示的または明示的または明示的に、すべての保証を否認します。ここに記載された情報の使用がいかなる権利も侵害しないことの黙示的な保証、または商品性や特定の目的への適合性の黙示的な保証を含みますが、これに限定されません。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the IETF's procedures with respect to rights in IETF Documents can be found in BCP 78 and BCP 79.
IETF は、本書に記載されているテクノロジの実装または使用に関連すると主張される知的財産権またはその他の権利の有効性や範囲、あるいはそのような権利に基づくライセンスが適用されるかどうかの範囲に関して、いかなる立場も負いません。利用可能であること。また、そのような権利を特定するために独自の努力を行ったことを示すものでもありません。IETF 文書の権利に関する IETF の手順に関する情報は、BCP 78 および BCP 79 に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF 事務局に提出された IPR 開示のコピー、および利用可能になるライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような所有権の使用に対する一般ライセンスまたは許可を取得しようとする試みの結果を入手できます。IETF オンライン IPR リポジトリ http://www.ietf.org/ipr から。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF は、利害関係者に対し、この規格の実装に必要とされる可能性のある技術をカバーする著作権、特許、特許出願、またはその他の所有権について注意を喚起するよう呼びかけています。情報は IETF (ietf-ipr@ietf.org) に送信してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC エディター機能の資金は現在、インターネット協会によって提供されています。