RFC 3981 - IRIS: The Internet Registry Information Service (IRIS) Core Protocol 日本語訳

URL : https://tools.ietf.org/html/rfc3981
タイトル : RFC 3981 - IRIS：インターネットレジストリ情報サービス（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）の最新版を参照してください。このメモの配布は無制限です。

著作権表示

著作権（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.

この文書は、インターネットレジストリの情報サービスのクエリと結果の操作を表現するためのフレームワークのためのアプリケーション層クライアントサーバプロトコルを記述します。拡張マークアップ言語（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

1. Introduction

1. はじめに

The specification outlined in this document is based on the functional requirements described in CRISP [17].

本文書で概説仕様はCRISP [17]に記載の機能要件に基づいています。

1.1. Use of XML

1.1. XMLの使用

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].

この文書は、インターネットレジストリ情報サービス（IRIS）、クエリの種類を説明し、さまざまなレジストリ情報サービスの種類をもたらすように意図されたXMLテキストプロトコルの仕様を説明しています。 [3]に記載のようにIRIS [2]、XMLスキーマ表記で記載されているように記載されているように、拡張マークアップ言語（XML）1.0を使用して指定された[4]、[5]、およびXML名前空間されています。

1.2. General Concepts

1.2. 一般概念

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名前空間を識別する同じURIによって識別されなければならない）XML名前空間とXMLスキーマを使用することにより、エンティティ、クエリなどを命名するための独自の構造を定義するレジストリタイプを可能にします。準拠するために、レジストリの種類の仕様では、この枠組みから拡張する必要があります。

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は、紹介の二つのタイプを定義しています。実体参照は、個々のエンティティについての特定の知識を示し、探索継続は、分散型検索を可能にします。どちらの紹介は、レジストリの種類とインスタンスの違いにまたがることがあります。いかなる仮定や仕様は、エンティティの根、塩基、またはメッシュについて行われていません。

1.3. Framework Layers

1.3. フレームワークのレイヤー

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）（[20]参照）、ブロック拡張交換プロトコルを指し、「虹彩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によって識別されます。共通レジストリは::基本操作と、検索セット、結果セット、および紹介などすべてのレジストリタイプに共通のセマンティクスを定義します。また、特定のレジストリ種類の話のための構文を定義します。アプリケーション・トランスポート::また、アプリケーション輸送機構に固有のURIの構文を定義するなど、認証、メッセージパッシング、接続およびセッションの管理のためのメカニズムを定義します。

1.4. Definitions

1.4. 定義

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エンティティ参照 - 権限、任意分解能法、レジストリ・タイプ、エンティティ・クラス、およびエンティティ名からなるエンティティへのポインタ。エンティティ参照の一つのタイプは、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]で指定されるように他の要素のいずれかのタイプを導出するために同じ意味で使用されています。

1.5. Further Reading

1.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の中核に構造を説明しています。 [18]虹彩ビープ[1]と虹彩DREG：以下の文書は、クリスプに関連するIRIS [17]の他の態様を説明します。

2. Document Terminology

2.ドキュメントの用語

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].

この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はありますBCP 14、RFC 2119に記載されるように解釈される[8]。

3. Protocol Identification

3.プロトコル識別

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インスタンスのルート要素は<要求>でなければなりません。すべての応答XMLインスタンスのルート要素は<応答>でなければなりません。これらの要素は、必要に応じて、スキーマのロケーションを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プロトコルのバージョン管理は、アプリケーション輸送層の責任であるが、XML名前空間に関連付けられている必要があり[3] URIは、虹彩を表します。このURIの変化は、したがって、新しいプロトコルのバージョン（およびその逆）を、基礎となるスキーマの変化を示し、。

4. Exchange Description

4.交換の説明

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構文の範囲外の仕様が含まれています。したがって、このセクションは、[8]正式なXML構文の範囲外の仕様を記述するためにRFC 2119によって定義された用語を使用します。このセクションを読んでいる間、正式なXML構文の詳細については、セクション6を参照してください。

4.1. Request Format

4.1. リクエストのフォーマット

A <request> element contains an optional <control> element and a set of <searchSet> elements.

<要求>要素はオプションの<コントロール>要素と<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を使用して、特定のレジストリタイプを照会するクライアントを可能にします。 <lookupEntity>と<問い合わせ>：これは、その2人の子供の一つで見つけることができます。

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」、および「エンティティネーム」：この要素は3つの属性があります。「registryType」属性は、ルックアップ操作が行われるには、レジストリのタイプのレジストリ識別子が含まれています。「entityClass」属性は、ルックアップ操作が行われるのインデックスを特定するトークンが含まれており、「エンティティネーム」属性は、ルックアップするために、エンティティの名前が含まれています。

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.

<問い合わせ>要素は、抽象的で、合法的に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>も<バッグ>要素が含まれていてもよいです。この要素は、<searchSet>の子として表示されたら、それは「ID」属性を含めることはできません。 <バッグ>要素の詳細については、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.

<コントロール>要素は、任意のXML名前空間の1つのつの子要素が含まれていてもよいです。この子要素は、クライアントが特殊な状態または処理のためにサーバーを通知することができます。そのような<コントロール>子要素の例は、セクション4.3.8に見出すことができます。

4.2. Response Format

4.2. レスポンスフォーマット

The <response> element contains an optional <reaction> element, a set of <resultSet> elements, and an optional <bags> element.

<レスポンス>要素はオプション<反応>要素、<たresultSet>要素のセット、およびオプションの<バッグ>要素を含んでいます。

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>要求への応答です。該当する場合、この要素の内容は、<答え>要素は、オプションの<追加>要素、およびエラーの要素が含まれています。

The children of the <answer> element are of the following types:

<答え>要素の子は次の種類があります。

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 <結果>抽象的要素であり、合法的XMLインスタンス内に配置されなくてもよいです。これは、誘導された結果のタイプを定義するために、レジストリスキーマで使用される基本型を提供します。この導出機構は、セクション4.3に記載されています。

o <entity> is an element specifying an entity reference. See Section 4.3.5.

O <エンティティは>エンティティ参照を指定する要素です。 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>要素は、クエリの紹介を指定します。その一人の子供が<問い合わせ>から派生した要素である（4.3.1項を参照してください）。参照先サーバーにクエリーを指示するには、<searchContinuation>は必須では「権威」属性とオプションの「解像度」属性を持っています。 <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.

実体参照および検索継続を以下の場合は、クライアントは一度だけ、<実体>または<searchContinuation>応答に従ってください。クライアントプロセスをもたらすことができるそうしないと、一般的に紹介ループとして知られている、決して終わることのないクエリーループで立ち往生。

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.

上記のように、<追加>要素は、<結果>要素を含みます。この要素は、サーバーが、具体的に照会されなかったが、それは、このように適切にユーザにこの区別を表示するためにクライアントを有効に、照会結果に関連するクライアントの結果を示すことができます。 <追加>要素の使用は任意です。

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.

セクション4.3で説明したように、<genericCode>の誘導体、O。

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>セクションは、クライアントによって容易に処理し、結果のナビゲーションを可能にするために、<答え>と<追加>セクションに分かれています。サーバーは、<答え>要素内のクエリへの直接の答えを返さなければならないと参照は、<答え>要素で行われたため、<追加>要素で結果を返すことがあります。 <追加>要素の結果は、<答え>要素の直接の子として、または、<答え>要素のより深い子孫としてのいずれかで、<答え>で参照されている必要があります。

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つの目的があります。まず、それは<答え>要素に含まれている参照用のクライアントで再クエリを排除することができます。第二に、それは、クエリの直接の結果であると返されたであろうものは、このように、クライアントが返された結果を処理したり、表示することができますどのようにほのめかし、クライアントは適切な紹介に続いていた結果が区別されます。例えば、木のナビゲーションウィジェットで複雑なディスプレイを構築するクライアントには、<追加>要素の結果から生成されるもののリーフノードである一方で、<答え>要素の結果はすべて、ツリーのルートノードの直下にあるべきこと<知っているだろう>要素に答えます。

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.

<反応>要素（<応答>の子）が<コントロール>要素に対応し、<コントロール>要素の効果のクライアントに助言するサーバのための手段を提供します。

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.

<バッグ>要素（<応答>の子）はオプションです。それは<バッグ>要素が含まれ、各<バッグ>要素の内容は、任意のXML名前空間の一個の要素を構成しています。各<バッグ>要素は、エンティティ参照（<エンティティ>）と、検索継続（<searchContinuation>）の「bagRef」属性によって参照される「ID」属性を有しています。 4.4節を参照してください。

4.3. Extension Framework

4.3. 拡張フレームワーク

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スキーマは一つだけのクエリの種類、および2つのスタンドアロンの結果タイプを定義し、レジストリの構造を定義していないので、それはそれ自体が限られた用途です。 [5]、及び虹彩の上に構築されたスキーマによってそれの拡張を介してXML_SD [4]とXML_SSで定義されるようにIRISの拡張は、ベースIRISスキーマを使用することによって達成されます。

4.3.1. Derived Elements

4.3.1. 派生要素

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スキーマ定義は、任意の要素の導出を禁止していませんが、レジストリのスキーマは、次のタイプの派生を制限する必要があります。

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 <問い合わせ> - 定義されているように、この要素には、コンテンツが含まれていないと、有効な属性はありません。それは抽象的であるため、唯一のその誘導体は、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 <結果> - 定義されているように、この要素は何もコンテンツが含まれておらず、5つの有効な属性があります。「権威」、「解像度」（別売）、「registryType」、「entityClass」、「エンティティネーム」、および「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>のインスタンスです。さらに、エラーの性質を説明するオプションの要素<解説>と<言語>を、含まれています。

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 <エンティティ> - エンティティへの参照を識別する。レジストリスキーマは、<実体>から派生要素を使用すべきではなく、直接<実体>を使用してもよい（MAY）。例えば、エンティティが別のエンティティに関して果たす役割として - <実体>対直接使用から派生することの利点は、要素の名前を定義し、記述的にその名前を使用するチャンスです。 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の> - エンティティを表す親要素との間接的な関連性を有しているエンティティへの参照を示します。この要素は、<エンティティ>要素（セクション4.3.5）に由来します。レジストリスキーマは、この要素に由来し得るか、直接それを使用することができます。

4.3.2. Registry Type Identifier Requirements

4.3.2. レジストリタイプ識別子の要件

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名前空間識別子の識別子は同じでなければなりません。これらの識別子は、[7] XML_URN [9]によって支配IANAレジストリの「NS」クラスに登録URNに制限されなければなりません。これらの識別子は大文字と小文字を区別しません。

This is a restriction on XML_NS [3], which specifies that an XML namespace identifier is any valid URI [6].

これは、XML名前空間識別子が有効なURIであることを指定XML_NS [3]上の制限、である[6]。

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をそのセパレータ以下の部分と略すことがあります。例えば、完全な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]スキーマ識別またはここXML_NS [3] XML名前空間を識別するためのURIの使用を指定するためのURIの使用を指定するXMLインスタンス内で使用してはいけません。

4.3.3. Entity Classes

4.3.3. エンティティークラス

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」とは、「ネームサーバー」と「ネットワーク」クラスで別々のエンティティを参照する場合があります。「ネームサーバ」クラス内のエンティティ「192.0.2.0」は、「エンティティに対し、またアドレス192.0.2.255によりマルチホームおよび「ns.example.com」としてDNSに知られているネームサーバホストを参照することができますネットワーク『クラスの』 192.0.2.0" は、/ 30ネットワーク192.0.2を参照することができます。

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は、再定義してはなりません「ローカル」と「アイリス」の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.

「ローカル」クラスは、サーバオペレータによって局所的に定義されたエンティティのために予約されており、エンティティの特定のタイプを示しません。このエンティティクラスのルックアップは、実体参照や検索継続をもたらすことができます。たとえば、「アイリス：DREG1 // example.com /ローカル/ 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):

「アイリス」クラスは、特定のサービス・インスタンスに固有のエンティティのために予約されています。これは、次のエンティティ名（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.

<制限>（セクション4.3.7.2を参照）の結果が得られるO「制限」、。このエンティティクラスは、他のローカルに定義されたエンティティを含むかもしれません。

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）。

4.3.4. Names of Entities

4.3.4. 実体の名前

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.

エンティティの名前は、レジストリ内の特定のエンティティクラスのインスタンス内で一意である必要があります。 2つのエンティティは、同じ名前を持つべきではないが、単一のエンティティが複数の名前で知られていてもよいです。単一の名前は、2つのエンティティをもたらすことができる状況では、レジストリのスキーマは両方のエンティティに実体参照が含まれている結果の種類を定義することによって、手当をしなければならない（例えば、「example.com」ドメインexample.comとホストの例の両方を参照することができます.COM）。しかし、紛争のこのタイプは、一般的にエンティティクラスの適切な使用によって避けるべきです。

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.

エンティティ名の大文字と小文字の区別は、それらが存在するエンティティクラスに依存しています。レジストリタイプの定義は、エンティティ名の大文字と小文字の区別を指定しなければなりません。レジストリのタイプが異なる場合の感度を持つものとして異なるエンティティクラスのエンティティ名を定義することができます。

4.3.5. References to Entities

4.3.5. エンティティへの参照

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>).

要素<エンティティ>いずれか<たresultSet>の直接の子として、または<結果>に由来するより複雑な構造内に、結果セット内のエンティティへの参照を可能にします。 <実体>要素を「entityType」で定義されています。レジストリスキーマは<エンティティ>参照エンティティに由来する要素を定義する必要がなく、直接<エンティティ>要素を使用することができます。新しい要素を導出することは、レジストリのスキーマが参照エンティティが参照元であり関係を表すために、新しい要素の名前を使用することができます。 <エンティティ>要素が宣言されたときに<エンティティ>の誘導体を代替として使用することはできません（例えば<回答>と<たresultSet>のセクション）。

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.

<実体>要素（およびタイプの要素のentityType '）は、オプションの「言語」属性を持つ<のdisplayName>の子要素を持つことができます。サーバは、実体参照のより多くの人に優しい記述をクライアントに提供できるように、これらが提供されています。これは、多くの場合、紹介構造をナビゲートするユーザーに便利です。

The <entity> element (and its derivations) have the following attributes:

<実体>要素（とその派生）は、以下の属性があります。

o 'authority', 'resolution' (optional), 'registryType', 'entityClass', and 'entityName' -- These attributes specify where the entity may be found.

O「権威」、「解像度」（オプション）、「registryType」、「entityClass」、及び「エンティティネーム」 - エンティティを見つけることができる場合、これらの属性を指定します。

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名が含まれていてもよいです。 <実体>の他の属性とは異なり、この属性は資格とIRIS XML名前空間で宣言されています。したがって、それはまた、IRIS XML名前空間（例えば、「：referentTypeアイリス」）に関連付けられている接頭辞で修飾されます。これは、クライアントが、<実体>から派生要素を使用して実体参照を認識することができます。

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は」 - この属性はオプションです。存在する場合、それが結果セットの<バッグ>セクション内の<バッグ>要素にXML識別子が含まれている必要があります。「bagRef」属性の説明については、4.4節を参照してください。

4.3.6. Temporary Entities

4.3.6. 一時的なエンティティ

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.

インスタンスとは、エンティティ参照が一時的である必要が存在してもよいです。たとえば、結果の特定のタイプは、唯一のユニークなキーを有することができます。その鍵は、すべてのユーザーに公開されないことがセマンティックな意味が含まれている場合は、合成キーを置換する必要があります。

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]ブール型のものであり、「偽」のデフォルト値を持っています。これは、<結果>誘導体およびタイプ「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」、「エンティティネーム」）が表示され、その後の応答と一致していない可能性のある応答内でのみ有効です。サーバは、同じ<たresultSet>の<追加>セクション内の任意の一時的実体参照のリファレントを含まなければなりません

4.3.7. <result> Derived Elements

4.3.7. <結果>派生要素

The base IRIS framework contains three elements directly derived from the <result> element for use by any registry type.

ベースIRISフレームワークは、直接、任意のレジストリ・タイプで使用するために<結果>要素に由来する3つの要素が含まれています。

4.3.7.1. <serviceIdentification>

4.3.7.1。 <serviceIdentification>

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>

<serviceIdentification権限= "example.com" registryType = "DREG1" entityClass = "アイリス" エンティティネーム= "ID"> <当局> <権威> example.com </権限> <権威> example.net </権限> <権限> example.org </権限> </当局> <operatorName>インターネット割り当て番号機関</ operatorName> <電子メール> iana@iana.org </メール> </ 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 <当局は> - この要素は、1つ以上の<権威>要素が含まれています。各<権威>要素は、サーバーが結果を持っているURIの権限コンポーネントが含まれています。サーバーが唯一のオペレータポリシーに応じて、その権限領域の部分的なリストを返すかもしれないが、それは、クライアントが要求したために権限を返さなければなりません。

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 <電子メール> - これらのオプションの要素は、サービスインスタンスのオペレータの電子メールアドレスが含まれています。

o <phone> -- These optional elements contain phone numbers of the operator of the service instance.

O <携帯電話> - これらの任意の要素は、サービスインスタンスのオペレータの電話番号を含みます。

o <seeAlso> -- See Section 4.3.1 for its definition.

O <seeAlsoの> - その定義については、セクション4.3.1を参照してください。

4.3.7.2. <limits>

4.3.7.2。 <制限>

An example of a <limits> result:

<限界>結果の例：

<制限権限= "example.com" registryType = "DREG1" entityClass = "絞り" エンティティネーム= "制限"> <totalQueries> <perHour> 2 </ perHour> <perDay> 15 </ perDay> </ totalQueries> <totalResults > <perHour> 25 </ perHour> <perDay> 200 </ perDay> </ totalResults> <totalSessions> <perHour> 2 </ perHour> <perDay> 15 </ perDay> </ totalSessions> </制限>

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:

<制限>要素は、サーバーは、それがサービスの使いすぎから発生する可能性がある限界をクライアントに通知することが可能なメカニズムを提供します。内容は、アクセスの現在のレベルでクライアントへのサービスの制限について説明します。次のように、この要素の内容は以下のとおりです。

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>の子として一度現れなければならないが、複数の子が存在してもよいです。例えば、サーバは、それが15分を照会だけで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> - この要素は、<限界>の他の子要素の構造化された構文の外側に発現することができる他の制限事項が記載されています。この要素は、オプションの<説明>子要素を持っていることが、必須で「言語」属性を持つ各。

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=... />).

これらの子要素のすべてはオプションで、サーバは、それが<限界>要素のないコンテンツを含む（例えば、<限界権限= ... />）を使用して、何の制限を持っていないことを表現してもよいです。

4.3.7.3. <simpleEntity>

4.3.7.3。 <simpleEntity>

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>

<simpleEntity権限= "example.com" registryType = "DREG1" entityClass = "ローカル" エンティティネーム= "予告"> <プロパティ名= "法的" 言語= "EN"> Example.comは、RFC 2606 <に従って予約されています/プロパティ> </ 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.

クライアントは容易に二列の表に、このような情報を表示することができます。バイナリデータや豊富なデータ構造を使用するアプリケーションは、この要素の範囲外です。このような使用シナリオが発生した場合、クライアントはおそらくので、疑問に新しいレジストリタイプの必要性を呼び出し、そのようなデータを処理するために特定の知識が必要になります。

4.3.8. <control> and <reaction> Elements

4.3.8. <コントロール>と<反応>要素

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.

<コントロール>（セクション4.1）と<反応>（セクション4.2）の要素は、クライアントがクエリの処理のためにサーバの特別な状態に要求することを可能にします。これらの要素の意図は、いくつかの法域はIRISの再バージョニングまたは任意のレジストリの種類を必要とせずに、クエリ処理のための政策を採用することができるように拡張性を可能にすることです。

This document defines one control, <onlyCheckPermissions>, and its requisite reaction, <standardReaction>, for compliance with CRISP [17].

この文書では、CRISP [17]に準拠して、<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>要素で、このコントロールに反応しなければなりません。

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 <受け入れ制御> - 制御が必要とする状態の処理を受け付けました。

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 <無効制御> - 活性化することができない制御が必要とする状態の処理（永久故障）。

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>が拒否された場合、サーバは（すなわち、要求に設定すべての検索のために）適切なすべての結果セットを返す必要がありますが、すべての結果セットは、結果の空でなければならないと（反応がの一部ではないエラーが含まれてはなりません結果）が設定され、したがって、エラーを設定結果ではありません。このコントロールは、すべての検索セットまたはそれらのいずれにも適用されます。 <onlyCheckPermissions>要求内のすべての検索・セットのために受け入れることができない場合ので、サーバーは拒否を発行しなければなりません。

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>

C：の<？xml version = "1.0"？> C：<要求のxmlns = "壷：IETF：のparams：XML：NS：iris1" C：のxmlns：XSI = "http://www.w3.org/2001/ XMLスキーマ・インスタンス "> C：C：<コントロール> C <onlyCheckPermissions /> C </制御> C：C：<searchSet> C：C：<lookupEntity C：registryType = "DREG1" C：entityClassは=" ローカル"C：エンティティネーム=" AUP」/> C：C </ searchSet> C：C </リクエスト>

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>

S：の<？xml version = "1.0"？> S：<応答のxmlns = "壷：IETF：のparams：XML：NS：iris1" S：のxmlns：XSI = "http://www.w3.org/2001/ XMLスキーマ・インスタンス」> S：S：<反応> S：<standardReaction> S：<controlAccepted /> S：</ standardReaction> S：</反応> S：S：<たresultSet> S：<答え> S：S ：<simpleEntity S：権限= "example.com" registryType = "DREG1" S：entityClass = "ローカル" エンティティネーム= "AUP"> S：<プロパティ名= "法的" 言語= "EN"> S：それは違法ですこのサービスSからの情報を使用するには：迷惑メールを送信する目的のために。 S：</ property>のS：</ simpleEntity> S：S：</答> S：</たresultSet> S：S：</レスポンス>

4.4. Relay Bags

4.4. リレーバッグ

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によって定義されていない、と別のサーバーからそれをリレーするとき、クライアントは、バッグの中身についての仮定をしてはなりません。

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.

サーバがクライアントに結果セットを返す場合は、<応答>要素は、<バッグ>子要素が含まれていてもよいです。この子要素は、1つ以上の<バッグ>要素が含まれています。これらのそれぞれは、XMLデータ・タイプIDを含む「ID」属性を含まなければなりません。それらが続いているときに使用する袋を指定する必要が実体参照および検索継続は、XMLデータ型IDREFを含む「bagRef」属性を持たなければなりません。 4.2節を参照してください。これは、応答が一度だけバッグを指定することができるが、必要に応じて、個別の袋を持っている（すべての結果セット内の）各エンティティ参照または検索継続を可能にします。

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>要素の子として設定された検索で参照袋を含まなければなりません。 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：の<？xml version = "1.0"？> C：<要求のxmlns = "壷：IETF：のparams：XML：NS：iris1" C：のxmlns：XSI = "http://www.w3.org/2001/ XMLスキーマ・インスタンス」> C：C：<searchSet> C：C：<バッグ> C <simpleBagのxmlns = "http://example.com/"> C：XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX C </ simpleBag> C </バッグ> C：C：<lookupEntity C：registryType = "DREG1" C：entityClass = "ローカル" C：エンティティネーム= "AUP" />

C: C: </searchSet> C: C: </request>

C：C：</ searchSet> C：C：</リクエスト>

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>

S：の<？xml version = "1.0"？> S：<応答のxmlns = "壷：IETF：のparams：XML：NS：iris1" S：のxmlns：アイリス= "壷：IETF：のparams：XML：NS：iris1" S：のxmlns：XSI = "http://www.w3.org/2001/XMLSchema-instance"> S：S：<たresultSet> S：<答え> S：S：<エンティティ権限= "example.com" bagRef = "X1" S：registryType = "DREG1" S：entityClass = "ローカル" エンティティネーム= "AUP" S：アイリス：referentType = "ANY"> S：<のdisplayName言語= "EN"> S：許容使用ポリシーS： </のdisplayName> S：</エンティティ> S：S：S </答える>：</たresultSet> S：S：<バッグ> S：S：<バッグのid = "X1"> S：<simpleBagのxmlns =」 http://example.com/ "> S：AAAAB3NzaC1yc2EAAAABIwAAAIEA0ddD + W3Agl0Lel98G1r77fZ S：</ simpleBag> S：</バッグ> S：S：</袋> S：</レスポンス>

5. Database Serialization

5.データベースのシリアライゼーション

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構文の範囲外の仕様が含まれています。このセクションでは、[8]これらを記述するためにRFC 2119によって定義された用語を使用します。このセクションを読んでいる間、正式な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エンティティのデータベースは、[2]に定義IRIS <シリアライゼーション>要素を使用してXMLのストレージをファイルにシリアライズすることができます。この要素は、<結果>要素誘導体と<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".

<結果>要素の誘導体が実体です。これらのエンティティをロードするサーバは、要素の「registryType」、「entityClass」で指定されたエンティティクラスにエンティティを配置しなければならない、と 'エンティティネームの属性をし、任意のエンティティクラス内のエンティティは、その要素の明示的に定義された子どもたちによると適用される場合があります。レジストリのタイプは2つのエンティティクラス「foo」と「bar」と<結果>を持っている場合たとえば、誘導体は、属性entityClass =「foo」とエンティティネーム=「1」と子要素を持つ<バー> 2 </バー> 、サーバーは、名前「1」として、エンティティクラス「foo」という名前にし、「2」などのエンティティクラス「バー」にその実体を入力することです。

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.

<結果>要素の直列化誘導体のようなサーバーの負荷エンティティは、権限属性を翻訳することができます。サーバーはおそらく、エンティティの権限が変更された場合は、これを行う必要があります。

<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>要素は、明示的な実体参照および検索継続の直列化を可能にします。この要素は、子を持つ<ソース>「権威」、「解像度」（オプション）、「registryType」、「entityClass」、および 'エンティティネームの属性を含む要素。この要素の属性は、この紹介を得るために参照することができる実体を意味するために使用されています。

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.

前述したように、サーバがロードされたエンティティの権限属性を変換する必要がある場合、時間があるかもしれません。また、実装は紹介のために、この必要性に注意しなければなりません。直列化復元時には、サーバは、シリアル化された属性が空の場合、サーバーの有効な権限を含むように（どちらか<実体>または要素<serializedReferral>の<実体>または<ソース>子由来）照会の権限属性を変更する必要があります。シリアライズ時には、サーバーとその関連プロセスは、参照先のサーバーがクエリを答えるいるエンティティである紹介のために空の属性の権限を残しておく必要があります。

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">

<アイリス：シリアライゼーションのxmlns：アイリス= "URN：IETF：paramsは：XML：NS：iris1" のxmlns = "URN：IETF：paramsは：XML：NS：iris1" のxmlns：XSI = "http://www.w3.org / 2001 / XMLスキーマ・インスタンス」>

<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>

<serviceIdentification権限= "iana.org" registryType = "DREG1" entityClass = "アイリス" エンティティネーム= "ID"> <当局> <権威> iana.org </権限> </当局> <operatorName>インターネット割り当て番号機関< / operatorName> <電子メール> dbarton@iana.org </メール> <seeAlsoのアイリス：referentType = "アイリス：simpleEntity" 権威= "iana.org" registryType = "DREG1" entityClass = "ローカル" エンティティネーム= "予告"> < displayName言語= "EN">法律上の注意事項</のdisplayName> </ seeAlsoの> </ serviceIdentification>

<simpleEntity authority="iana.org" registryType="dreg1" entityClass="local" entityName="notice" > <property name="legal" language="en"> Please use the net wisely! </property> </simpleEntity>

<simpleEntity権限= "iana.org" registryType = "DREG1" entityClass = "ローカル" エンティティネーム= "予告"> <プロパティ名= "法的" 言語= "EN">賢くネットを使用してください！ </ property>の</ simpleEntity>

</iris:serialization>

</アイリス：連載>

6. Formal XML Syntax

6.正式なXML構文

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" >

<？xmlのバージョン= "1.0"> <スキーマのxmlns = "http://www.w3.org/2001/XMLSchema" のxmlns：アイリス= "壷：IETF：のparams：XML：NS：iris1" のtargetNamespace = "壷：IETF：のparams：XML：NS：iris1" のelementFormDefault = "資格">

<annotation> <documentation> Internet Registry Information Service (IRIS) Schema v1 </documentation> </annotation>

<注釈> <ドキュメンテーション>インターネットレジストリ情報サービス（IRIS）スキーマV1 </ドキュメンテーション> </注釈>

     <!-- ========================================= -->
     <!--                                           -->
     <!-- The Transactions                          -->
     <!--                                           -->
     <!-- ========================================= -->

<要素名= "要求"> <complexTypeの> <シーケンス> <要素名= "コントロール" タイプ= "アイリス：controlType" のminOccurs = "0" のmaxOccurs = "1" /> <要素名= "searchSet" タイプ=」アイリス：searchSetType」のminOccurs = "1" のmaxOccurs = "無制限" /> </配列> </ complexTypeの> </要素>

<要素名= "応答"> <complexTypeの> <シーケンス> <要素名= "反応" タイプ= "アイリス：reactionType" のminOccurs = "0" のmaxOccurs = "1" /> <要素名= "たresultSet" タイプ=」アイリス：resultSetType」のminOccurs = "1" のmaxOccurs = "無制限" /> <要素名= "バッグ" タイプ= "アイリス：bagsType" のminOccurs = "0" のmaxOccurs = "1" /> </配列> </ complexTypeの> </要素>

     <!-- ========================================= -->
     <!--                                           -->
     <!-- Search Sets and Result Sets               -->
     <!--                                           -->
     <!-- ========================================= -->

<complexTypeの名前= "searchSetType"> <シーケンス> <要素名= "バッグ" タイプ= "アイリス：bagType" のminOccurs = "0" のmaxOccurs = "1" /> <選択> <要素名= "lookupEntity" タイプ=」アイリス：lookupEntityType」/> <要素REF = "アイリス：クエリ" /> </選択> </シーケンス> </ complexTypeの>

<complexTypeの名= "resultSetType"> <シーケンス> <要素名= "答え" のminOccurs = "1" のmaxOccurs = "1"> <complexTypeの> <シーケンス>

<素子REF = "アイリス：結果" のminOccurs = "0" のmaxOccurs = "無制限" /> <要素REF = "アイリス：エンティティ" のminOccurs = "0" のmaxOccurs = "無制限" /> <要素REF = "アイリス：searchContinuation "のminOccurs =" 0" のmaxOccurs = "無制限" /> </配列> </ complexTypeの> </要素> <要素名= "追加" のminOccurs = "0" のmaxOccurs = "1"> <complexTypeの> <シーケンス> <要素REF = "アイリス：結果" のminOccurs = "1" のmaxOccurs = "無制限" /> </シーケンス> </ complexTypeの> </要素> <選択のminOccurs = "0" のmaxOccurs = "1"> <要素名=」 insufficientResources」タイプ= "アイリス：CODETYPE" /> <要素名= "あるInvalidName" タイプ= "アイリス：CODETYPE" /> <要素名= "invalidSearch" タイプ= "アイリス：CODETYPE" /> <要素名= "queryNotSupported"タイプ= "アイリス：CODETYPE" /> <要素名= "limitExceeded" タイプ= "アイリス：CODETYPE" /> <要素名= "nameNotFound" タイプ= "アイリス：CODETYPE" /> <要素名= "permissionDenied" タイプ= "アイリス：CODETYPE" /> <要素名= "bagUnrecognized" タイプ= "アイリス：CODETYPE" /> <要素名= "bagUnacceptable" タイプ= "アイリス：CODETYPE" /> <要素名= "bagRefused"タイプ= "アイリス：CODETYPE" /> <要素REF = "アイリス：genericCode" /> </選択> </シーケンス> </ complexTypeの>

     <!-- ========================================= -->
     <!--                                           -->
     <!-- Controls and Reactions                    -->
     <!--                                           -->
     <!-- ========================================= -->

<complexTypeの名前= "controlType"> <シーケンス> <任意の名前空間= "##あらゆる" のprocessContents = "スキップ" のminOccurs = "1" のmaxOccurs = "1" /> </シーケンス> </ complexTypeの>

<complexTypeの名前= "reactionType"> <シーケンス> <任意の名前空間= "##あらゆる" のprocessContents = "スキップ" のminOccurs = "1" のmaxOccurs = "1" /> </シーケンス> </ complexTypeの>

     <!-- ========================================= -->

     <!--                                           -->
     <!-- Queries and Lookups                       -->
     <!--                                           -->
     <!-- ========================================= -->

<complexTypeの名= "のquerytype" />

<要素名= "クエリ" タイプ= "アイリス：のquerytype" 抽象= "真" />

<complexTypeの名= "lookupEntityType"> = <属性名= "entityClass" タイプ= "トークン" 使用= "必須" /> <属性名<名前= "registryType" タイプ= "anyURIの" 使用= "必須" /属性>は、 "エンティティネーム" タイプ= "トークン" 使用= "必須" /> </ complexTypeの>

     <!-- ========================================= -->
     <!--                                           -->
     <!-- Results                                   -->
     <!--                                           -->
     <!-- ========================================= -->

<complexTypeの名= "resultTypeと"> <名前= "権威" の使用属性= "必要" タイプ= "トークン" /> <属性名= "解決" タイプ= "トークン" /> <名前= "registryType" 使用属性= "必要な" タイプ= "anyURIの" />

<属性名= "entityClass" 使用= "必要な" タイプは、= "トークン" /> <属性名= "エンティティネーム" 使用= "必要な" タイプは、= "トークン" /> <属性名= "temporaryReference" デフォルト= "false" にタイプ= "ブール" /> </ complexTypeの>

<要素名= "結果" タイプ= "アイリス：resultTypeと" 抽象= "真" />

     <!-- ========================================= -->
     <!--                                           -->
     <!-- Errors                                    -->
     <!--                                           -->
     <!-- ========================================= -->

<complexTypeの名= "CODETYPE"> <シーケンスのminOccurs = "0" のmaxOccurs = "無制限"> <要素名= "説明"> <complexTypeの> <simpleContentを> <増設ベースは= "文字列"> <属性使用= "必要"名前= "言語" タイプ= "言語" /> </拡張> </ simpleContentを> </ complexTypeの> </要素> </シーケンス> </ complexTypeの> <要素名= "genericCode" タイプ= "アイリス：CODETYPE"抽象的な= "真" />

     <!-- ========================================= -->
     <!--                                           -->
     <!-- Entity References and                     -->
     <!-- Search Continuations                      -->
     <!--                                           -->
     <!-- ========================================= -->

<complexTypeの名前= "entityType"> <シーケンス> <要素名= "のdisplayName" のminOccurs = "0" のmaxOccurs = "無制限"> <complexTypeの> <simpleContentを> <増設ベース= "文字列"> <属性名は= "言語" = "必須" タイプ= "言語" /> </拡張> </ simpleContentを> </ complexTypeの> </要素を使用する> </シーケンス> <名前= "権威" の使用属性= "必要" タイプ= "トークン" / > <属性名= "解決" タイプ= "トークン" /> <属性名= "registryType" 使用= "必要" タイプ= "anyURIの" /> <属性名= "entityClass" 使用= "必要" タイプ= "トークンreferentTypeType "/> <属性： "/> <名前=属性" エンティティネーム」を使用する= "" タイプ= "トークン"/> <属性名= "referentType" 使用= "必要な" フォーム= "資格" タイプ=" アイリスを必要と名前= "temporaryReference" デフォルト= "false" をタイプ= "ブール" /> <属性名= "bagRef" タイプ= "IDREF" /> </ complexTypeの>

<要素名= "実体" タイプ= "アイリス：entityType" />

<単純名= "referentTypeType"> <組合memberTypesの= "のQNameアイリス：anyLiteralType" /> </単純>

<単純名= "anyLiteralType"> <制限基地= "文字列"> <列挙値= "ANY" /> </制限> </ simpleTypeの>

<complexTypeの名前= "searchContinuationType"> <シーケンス> <要素REF = "アイリス：クエリ" /> </シーケンス> <属性名= "bagRef" タイプ= "IDREF" /> <属性名= "権威" タイプ=」必要なトークン」=使用 "" /> <属性名= "解決" タイプ= "トークン" /> </ complexTypeの>

<要素名= "searchContinuation" タイプ= "アイリス：searchContinuationType" />

     <!-- ========================================= -->
     <!--                                           -->
     <!-- Bags                                      -->
     <!--                                           -->
     <!-- ========================================= -->

<complexTypeの名前= "bagsType"> <シーケンス> <要素名= "バッグ" のminOccurs = "1" のmaxOccurs = "無制限"> <complexTypeの> <complexContentを> <拡張ベース= "アイリス：bagType"> <属性使用=」必要な」名前= "ID" タイプ= "ID" /> </拡張> </ complexContentを> </ complexTypeの> </要素> </配列> </ complexTypeの>

     <complexType
       name="bagType">
       <sequence>
         <any
           namespace="##any"
           processContents="skip"
           minOccurs="1"
           maxOccurs="1" />
       </sequence>
     </complexType>
     <!-- ========================================= -->
     <!--                                           -->
     <!-- Derived Results for use with all          -->

     <!-- registry types.                           -->
     <!--                                           -->
     <!-- ========================================= -->

<！ - - > <！ - 参照 - > <！ - - >

<要素名= "seeAlsoの" タイプ= "アイリス：entityType" />

<！ - - > <！ - サービスの識別 - > <！ - - >

<complexTypeの名前= "serviceIdentificationType"> <complexContentを> <拡張ベース= "アイリス：resultTypeと"> <シーケンス> <要素名= "当局" のminOccurs = "1" のmaxOccurs = "1"> <complexTypeの> <シーケンス> <要素名前= "権威" タイプ= "トークン" のminOccurs = "1" のmaxOccurs = "無制限" /> </シーケンス> </ complexTypeの> </要素> <要素名= "operatorName" タイプ= "文字列" のminOccurs = "0 "のmaxOccurs =" 1" /> <要素名= "電子メール" タイプ= "文字列" のminOccurs = "0" のmaxOccurs = "無制限" /> <要素名= "電話" タイプ= "文字列" のminOccurs = "0" maxOccurs属性= "無限" /> <要素REF = "アイリス：seeAlsoの" minOccurs属性= "0" のmaxOccurs = "無制限" /> </配列> </拡張> </ complexContentを> </ complexTypeの>

<要素名= "serviceIdentification" タイプ= "アイリス：serviceIdentificationType" のsubstitutionGroup = "アイリス：結果" />

<！ - - > <！ - 制限 - > <！ - - >

<complexTypeの名前= "limitsType"> <complexContentを> <拡張ベース= "アイリス：resultTypeと"> <シーケンス> <要素名= "totalQueries" のminOccurs = "0" のmaxOccurs = "1"> <complexTypeの> <グループREF =」アイリス：timeLimitsGroup "のminOccurs = "1" のmaxOccurs = "4"/> </ complexTypeの> </要素> <要素名= "totalResults" のminOccurs = "0" のmaxOccurs = "1"> <complexTypeの> <グループREF ="アイリス：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" />

</要素> <要素名= "totalSessions" のminOccurs = "0" のmaxOccurs = "1"> <complexTypeの> <グループREF = "アイリス：timeLimitsGroup" のminOccurs = "1" のmaxOccurs = "4" /> </ complexTypeの> </要素> <要素名= "otherRestrictions" のminOccurs = "0" のmaxOccurs = "1"> <complexTypeの> <シーケンス> <要素名= "説明" のminOccurs = "0" のmaxOccurs = "無制限"> <complexTypeの> < simpleContentを> <増設ベース= "文字列"> <名前= "言語" タイプ= "言語" を使用する属性= /> </拡張> </ simpleContentを> </ complexTypeの> </要素> </シーケンス> < "必要" /のcomplexType> </要素> <要素REF =：のminOccurs = "0" のmaxOccurs = "無制限" /> </配列> </拡張> </ complexContentを> </ complexTypeの> <要素名=「制限 "を虹彩SEEALSO" "TYPE =" アイリス：limitsType」のsubstitutionGroup = "アイリス：結果" />

<グループ名= "timeLimitsGroup"> <選択> <要素名= "perSecond" タイプ= "NonNegativeIntegerの" /> <要素名= "perMinute" タイプ= "NonNegativeIntegerの" /> <要素名= "perHour" タイプ= "NonNegativeIntegerの"/> <要素名=" perDay」タイプ= "NonNegativeIntegerの" /> </選択> </グループ>

<！ - - > <！ - シンプルなエンティティ - > <！ - - >

<complexTypeの名前= "simpleEntityType"> <complexContentを> <拡張ベース= "アイリス：resultTypeと"> <シーケンス> <要素名= "プロパティ" のminOccurs = "1" のmaxOccurs = "無制限"> <complexTypeの> <simpleContentを> <拡張ベース=「文字列」> <属性名=「名前」タイプ=「文字列」使用=「必須」/> <属性名=「言語」タイプ=「言語」使用=「必須」/> <属性名= "URI "TYPE =" anyURIの」/> </拡張> </ simpleContentを> </ complexTypeの> </要素> </配列> </拡張> </ complexContentを> </ complexTypeの>

<要素名= "simpleEntity" タイプ= "アイリス：simpleEntityType" のsubstitutionGroup = "アイリス：結果" />

     <!-- ========================================= -->
     <!--                                           -->
     <!-- Derived Controls and Reactions            -->
     <!--                                           -->
     <!-- ========================================= -->

<！ - - > <！ - 権限のみをチェックしてください - > <！ - - >

<要素名= "onlyCheckPermissions"> <complexTypeの/> </要素>

<！ - - > <！ - 標準的な反応 - > <！ - - >

<要素名= "standardReaction"> <complexTypeの> <選択> <要素名= "controlAccepted"> <complexTypeの/> </要素> <要素名= "controlDenied"> <complexTypeの/> </要素> <要素名= "controlDisabled">

<complexTypeの/> </要素> <要素名= "controlUnrecognized"> <complexTypeの/> </要素> </選択> </ complexTypeの> </要素>

     <!-- ========================================= -->
     <!--                                           -->
     <!-- Serialization                             -->
     <!--                                           -->
     <!-- ========================================= -->

<complexTypeの名前= "serializedReferralType"> <シーケンス> <要素名= "ソース"> <complexTypeの> <名前= "権威" の使用属性= "必要" タイプ= "トークン" /> <名前= "解決" 属性タイプ= "トークン" /> <属性= "必要" /> <属性名= "entityClass" タイプ= "トークン" の使用名= "registryType" タイプ= "anyURIの" 使用= "必須" /> <属性名= "エンティティネーム"タイプ= "トークン" 使用= "必要" /> </ complexTypeの> </要素> <選択肢> <要素REF = "アイリス：searchContinuation" /> <要素REF = "アイリス：エンティティ" /> </選択>

</sequence> </complexType>

</シーケンス> </ complexTypeの>

<要素名= "連載"> <complexTypeの> <選択肢のminOccurs = "1" のmaxOccurs = "無制限"> <要素REF = "アイリス：結果" /> <要素名= "serializedReferral" タイプ= "アイリス：serializedReferralType" / > </選択> </ complexTypeの> </要素>

</schema>

</スキーマ>

Figure 8

図8

7. The IRIS URI

7.パリON

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).

彼らはさまざまな方法がサーバを見つけて（BEEPがデフォルトである）複数のトランスポートの使用を許可するために使用することができるようにするので、しかし、IRISのURIには柔軟性があります。

7.1. URI Definition

7.1. URIの定義

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

アイリス-URI =スキーム "：" レジストリ-URN "/" [解決法] "/" 権限[ "/" エンティティクラス "/" エンティティ名]スキーム= "アイリス" の権威= // RFC2396で指定されましたレジストリ-URN = // IRIS解決法= *で指定された（非予約|エスケープ）エンティティ・クラス= * |エンティティ名= *（予約されていないエスケープ）|予約されていない（予約されていないが、エスケープ）= //エスケープRFC2396で指定されました= // 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]によって指定されるように解像度方法、エンティティ・クラス、およびエンティティ名は、 "アプリケーション/ x-www-form-urlencodedで" で符号化されたUTF-8 [12]文字セットでなければなりません。

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".

エンティティ・クラスとエンティティ名のコンポーネントが指定されていない場合は、デフォルトで「アイリス」と「ID」が暗示されなければなりません。例えば、 "アイリス：DREG1 // COM" "：DREG1 // COM /アイリス/ IDアイリス" と解釈されます。

When the resolution-method is not specified, the default is the direct resolution method described in Section 7.3.2.

解決法が指定されていない場合は、デフォルトでは、セクション7.3.2で説明した直接解決方法です。

7.2. Transport Specific Schemes

7.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.

「アイリス」スキーム名は、特定のアプリケーションの輸送ではありません。 URI解決プロセスは、アプリケーションの輸送を決定することができます。そのようなプロセスの例は、アプリケーションの輸送を決定するために、セクション7.3.3で説明した手順を使用して直接解像度（7.3.2）です。

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の意味での使用を意味するスキーム名を定義することもできます。

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、それが意味するアプリケーション・トランスポートを使用すべきです。

o If a client has a preferred transport and the resolution process allows for its use, the client MAY use that application transport.

クライアントが優先トランスポートを持ち、解決プロセスは、その使用を許可する場合は、O、クライアントは、そのアプリケーション・トランスポートを使用するかもしれません。

o Otherwise, the default application transport specified by IRIS-BEEP [1] MUST be used.

Oそれ以外の場合は、IRIS-BEEP [1]で指定されたデフォルト・アプリケーション・トランスポートを使用しなければなりません。

7.3. URI Resolution

７。３。うりれそぅちおん

7.3.1. Registry Dependent Resolution

7.3.1. レジストリの依存決議

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.

代替解決方法は、レジストリの種類によって指定することができます。これらのメソッドの識別子は、セクション7.1でABNFに従わなければなりません。

7.3.2. Direct Resolution

7.3.2. 直接の解決

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.

権限コンポーネントは、RFC 2396で指定されたポート番号を伴うドメイン名がある場合は、O、ドメイン名が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）プロセスが使用されます。このプロセスは何も結果を生成しない場合、DNSは、ドメイン名に対応するAまたはAAAAのRRのために照会され、そして使用されるポート番号は、セクション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.

権限コンポーネントは、IPアドレスである場合には、O、その後、DNSが照会されていない、とIPアドレスが直接使用されます。ポート番号が存在する場合、それが直接使用されます。そうでなければ、使用されるポート番号は、セクション7.2に従って使用されるトランスポートのウェルノウンポートです。

The use of an IPv6 address in the authority component MUST conform to RFC 2732 [15].

権限コンポーネントにおけるIPv6アドレスの使用は、RFC 2732 [15]に従わなければなりません。

7.3.3. Transport and Service Location

7.3.3. 交通とサービスの場所

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の省略形を使用します。他の解決方法は、他のアプリケーション・サービス・ラベルを指定するかもしれません。

See Appendix A for sample uses of S-NAPTR.

S-NAPTRのサンプルの使用については、付録Aを参照してください。

7.4. IRIS URI Examples

7.4. IRIS URIの例

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アイリス：DREG1 // example.com /ドメイン/ 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アイリス：DREG1 // example.com *ダイレクト解像度（7.3.2項）の規則に従って「example.com」のためのサーバが権威検索します。 *サーバが「DREG1」レジストリの「アイリス」インデックスの「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アイリス：DREG1 // COM /ドメイン/ 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アイリス：DREG1 // 192.0.2.1：44 /ドメイン/ 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 /ドメイン/ 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 /ドメイン/ 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アイリス：DREG1 /下/ example.com /ドメイン/ example.com *レジストリ型URNによって定義される解決方法「底」の規則に従って「example.com」の認証サーバを検索：IETF：paramsは： XML：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 /下/ example.com /ドメイン/ example.com *レジストリ型URNによって定義される解決方法「底」の規則に従って「example.com」のサーバが権限の検索：IETF： params：XML：NS：DREG1。 * BEEPアプリケーション・トランスポートを使用します。 *サーバが「DREG1」レジストリの、「ドメイン」のインデックス、またはエンティティクラスに「example.com」を求めています。

8. Checklists

8.チェックリスト

8.1. Registry Definition Checklist

8.1. レジストリ定義のチェックリスト

Specifications of registry types MUST include the following explicit definitions:

レジストリタイプの仕様は以下の明示的な定義を含める必要があります。

o Formal XML syntax deriving from the IRIS XML.

IRIS XMLから派生O正式なXML構文。

o An identifying registry URN.

特定のレジストリURN O。

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.

S-NAPTR遵守するためのアプリケーション・サービス・ラベルと略記レジストリURNの登録O [10]。これは、レジストリのタイプ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。

8.2. Transport Mapping Checklist

8.2. 交通マッピングのチェックリスト

Specifications of transport mappings MUST include the following explicit definitions:

トランスポートマッピングの仕様は以下の明示的な定義を含める必要があります。

o A URI scheme name specific to the transport.

交通機関への特定のURIスキーム名O。

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.

S-NAPTRに準拠してアプリケーションプロトコルラベルO [10]。 7.3.3項を参照してください。これはURIのスキーム名IANAレジストリとは異なるIANAレジストリですが、彼らが同じ文字列にすることをお勧めしていることに注意してください。

o The set of allowable character set encodings for the exchange of XML (see Section 9).

XMLの交換のための許容文字セットエンコーディングのセットO（9章を参照してください）。

o The set of security mechanisms.

セキュリティメカニズムのセットO。

9. Internationalization Considerations

9.国際化に関する注意事項

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>宣言で「エンコーディング」属性によって他の文字エンコーディングを特定して使用するためのメカニズムを提供します。この属性又はバイトオーダーマーク（BOM）の不在は、UTF-8 [13]符号化のデフォルト値を示しています。したがって、互換性の理由及びRFC 2277ごとに[16]、UTF-8を使用する[13] IRISで推奨されています。

The complete list of character set encoding identifiers is maintained by IANA at [21].

文字セット符号化識別子の完全なリストは、[21]にIANAによって維持されています。

The application-transport layer MUST define a common set of character set encodings to be understood by both client and server.

アプリケーション・トランスポート層は、クライアントとサーバーの両方が理解する文字セットエンコーディングの共通セットを定義しなければなりません。

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.

国際化された文字列のローカライズは、クライアントからの追加情報が必要な場合があります。エンティティ定義は、ローカリゼーションプロセスでクライアントを支援するための[4] XML_SDによって定義された「言語」タイプを使用する必要があります。例えば、セクション4.3.7.3を参照してください。

10. IANA Considerations

10. IANAの考慮事項

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名前空間とXML_URN [9]で指定されたスキーマレジストリを使用しています。したがって、以下の登録情報は、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：XML O *アンドリュー・ニュートン<andy@hxr.us> *マルコスサンス<sanz@denic.de>：：* URN：IETF：のparams：XML：NS：iris1 O接点節で指定された* XMLスキーマ6

11. Security Considerations

11.セキュリティについての考慮事項

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レジストリの結果は、別のレジストリサービスに対するクライアントのクエリ操作の結果、エンティティの検索および検索継続を含有していてもよいです。クライアントは、後続のエンティティの検索および検索継続を行うためにリプレイ攻撃の対象と認証資格情報とメカニズムを使用しないでください。

12. References

12.参考文献

12.1. Normative References

12.1. 引用規格

[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]ニュートン、A.とM.サンス、RFC 3983 "ブロック拡張可能交換プロトコル（BEEP）を介してインターネットレジストリ情報サービス（IRIS）の使用" を、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]ワールド・ワイド・ウェブ・コンソーシアム、 "拡張マークアップ言語（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]ワールド・ワイド・ウェブ・コンソーシアム、 "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]ワールド・ワイド・ウェブ・コンソーシアム、 "XMLスキーマパート2：データ型"、W3C XML Schemaの、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]ワールド・ワイド・ウェブ・コンソーシアム、 "XMLスキーマパート1：構造"、W3C XML Schemaの、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]バーナーズ - リー、T.、フィールディング、R.、およびL. Masinter、 "ユニフォームリソース識別子（URI）：汎用構文"、RFC 2396、1998年8月。

[7] Moats, R., "URN Syntax", RFC 2141, May 1997.

[7]堀、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]ブラドナーのは、S.は、BCP 14、RFC 2119、1997年3月の "RFCsにおける使用のためのレベルを示すために"。

[9] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, January 2004.

[9] Mealling、M.、 "IETF XMLレジストリ"、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.ニュートン、RFC 3958、2005年1月 "のSRV RRを使用したアプリケーションサービスロケーションおよび動的委任ディスカバリサービス（DDDS）をドメインベース"。

[11] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997.

[11]クロッカー、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規格、バージョン3"、ISBN 0-201-61633-5、2000年、<Unicode標準、バージョン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]コノリー、D.およびL. Masinter、 " 'text / htmlの' メディアの種類"、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] "URLの中にリテラルIPv6アドレスのフォーマット" HindenとR.、大工、B.、およびL. Masinter、RFC 2732、1999年12月。

[16] Alvestrand, H., "IETF Policy on Character Sets and Languages", BCP 18, RFC 2277, January 1998.

[16] Alvestrand、H.、 "文字セットと言語のIETF方針"、BCP 18、RFC 2277、1998年1月。

12.2. Informative References

12.2. 参考文献

[17] Newton, A., "Cross Registry Internet Service Protocol (CRISP) Requirements", RFC 3707, February 2004.

[17]ニュートン、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]ニュートン、A.およびM.サンス、 "IRIS：ドメインレジストリ（DREG）インターネットレジストリ情報サービス（IRIS）のための型"、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]ローズ、M.、 "ブロック拡張可能交換プロトコルコア"、RFC 3080、2001年3月。

URIs

URI

[21] <http://www.iana.org/assignments/character-sets>

「２１」＜ｈっｔｐ：／／ｗっｗ。いあな。おｒｇ／あっしｇんめんｔｓ／ちゃらｃてｒーせｔｓ＞

Appendix A. S-NAPTR and IRIS Uses

付録A. S-NAPTRとIRIS使用方法

A.1. Example of S-NAPTR with IRIS

A.1。 IRISとS-NAPTRの例

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:

このセクションでは、[10] IRISによって使用S-NAPTRの一例を示しています。 REGAとREGB：この例では、2つのレジストリ種類があります。また、2つのIRISアプリケーションは、トランスポートがあります：アイリス-Aおよびアイリス-B。この与えられた、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を実行するサーバーのセットを分割することができる手段。これは、オペレータがREGBのデータを提供するサーバのセットからREGAのためのデータを提供するサーバーのセットを分割することができ、と言うことです。

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. Aは、操作者が虹彩-Bを実行しているサーバーのセットから虹彩-Aを実行しているサーバのセットを識別することができる手段。これは、オペレータがREGAとREGBのデータを提供するプロトコルアイリス-Bを実行しているサーバーのセットからプロトコルアイリスサービングREGAとREGBのデータを実行しているサーバのセットを分割することができ、と言うことです。

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. Aは、オペレータが別のオペレータに委任するように動作するサーバのセットと、その上のサーバのセットを指定することができる手段。

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

example.com。 ;; NAPTR 100 10 "IN "" rega.example.com" "REGB：アイリス：アイリス-B" "" REGB NAPTR 100 10 "" "：：アイリスアイリス-B REGA" IN交換再県旗のサービスを注文します.example.comと

To implement the second feature, the operator then adds the following in their DNS zone:

彼らの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。 ;;アイリス - 「「」_iris-a._udp.example.com regb.example.com：NAPTR 100 10「秒」」REGA IN県旗のサービスの再交換を注文します。 NAPTR 100 10 "秒" "REGA：アイリス-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。 ;; 0 34 big-a.example.com SRV 10に県重量ポート目標。 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。 ;; 0 34 big-b.example.com SRV 10に県重量ポート目標。 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

example.com。 ;; NAPTR 100 10 "IN "" rega.example.com" "REGB：アイリス：アイリス-B" "" somebodyelse NAPTR 100 10 "" "：：アイリスアイリス-B REGA" IN交換再県旗のサービスを注文します.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.

またはオペレータが他の誰かにアイリス-Bプロトコル/トランスポートの下REGBサービスを委任しながら、アイリス・プロトコル/トランスポートの下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

example.com。 ;; NAPTR 100 10に交換再県旗のサービスを注文 "" "REGB：アイリス：アイリス-B" "" NAPTR 100ではregb.example.com 10 "S" "REGB：アイリス - " "" _iris - 。 _udp.example.com NAPTR 100 10 "秒" "REGBの場合：アイリス-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。 ;; 0 34 big-a.example.com SRV 10に県重量ポート目標。 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の間でデータを同期に関わる運用上の問題で、おそらく賢明ではないことに注意してください。これは、何ができるかの一例として、ここで提供されます。

A.2. Using S-NAPTR for Cohabitation

A.2。同棲のためのS-NAPTRを使用して

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によって定義されるように、このサービスフィールドは、その領域のデータを搬送する、虹彩ビーププロトコルとWHOISプロトコルの両方を介して利用可能です。 WHOISアプリケーションプロトコルラベルは、RFC 954 [19]を意味します。

Appendix B. IRIS Design Philosophy

付録B. IRISデザイン哲学

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の開発のための他の抽象的理由があります。このセクションでは、説明をしようとします。

B.1. The Basic Premise

B.1。大前提

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このようなツリーを指定するものとして、レジストリの任意のタイプのデータの組との間の関係を課しません。そこインターネットリソースの多くの種類があり、それらはすべて、そのデータの含まれるセットとの関係の同じスタイルを共有していません。それは自然に適合しない場合は、一般的な関係を課すことは、多くの場合、心配していない利点です。

B.2. The Lure of a Universal Client

B.2。ユニバーサルクライアントのルアー

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の設計前提は、ディレクトリサービスのために、ユニバーサルクライアント（または1つが存在する場合、それは一般的に「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.

一般的なクエリ言語でユニバーサルクライアントを服しようとする試みも非常に有用ではありません。一般的なクエリ言語は、共通のクエリ言語と問題領域の両方の専門知識を持っているユーザーを必要とする特定の問題領域に適用することができます。最後に、結果は通常、問題のドメインに特異的であるが、ユーザーの欲望の翻訳とクエリ言語の最小共通分母の側面を抱えたクライアントの開発です。

B.3. Server Considerations

B.3。サーバーの考慮事項

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は、標準技術の層のセットに基づいて構築されます。これは、サービス事業者は、特定の環境のニーズを満たすためにコンポーネントを切り替えることができます。

B.4. Lookups, Searches, and Entity Classes

B.4。検索、検索、およびエンティティークラス

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には、標準の検索はありません。レジストリの各タイプには、検索の独自のセットを定義します。

B.5. Entities References, Search Continuations, and Scope

B.5。エンティティ参照、検索継続の、とスコープ

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は、実体参照（<実体>）との間に一線を画すため、検索の継続（<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は、実体参照や検索継続の範囲に関して何の要件を行わないことを意味します。スコープは、レジストリのタイプが必要とするものでレジストリタイプは、サービス事業者を可能にするものによって決定されます。

Appendix C. Acknowledgments

付録C.謝辞

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.

名前空間の名前空間と名前空間を記述するために、このドキュメントで使用される用語は現在、レスリーDaigle氏の巧みな議論の戦術により明確に感謝です。以前は、それははるかに混乱しました。また、レスリーは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.

他の多くの技術的な複雑さは、デビッド・Blackaにより、不必要な証明された、削除されました。そして、彼のIRISの実装が粗く、エッジを滑らかに支援してきました。

Authors' Addresses

著者のアドレス

Andrew L. Newton VeriSign, Inc. 21345 Ridgetop Circle Sterling, VA 20166 USA

アンドリュー・L.ニュートンベリサイン社21345 Ridgetopサークルスターリング、VA 20166 USA

Phone: +1 703 948 3382 EMail: anewton@verisignlabs.com; andy@hxr.us URI: http://www.verisignlabs.com/

電話：+1 703 948 3382 Eメール：anewton@verisignlabs.com。 andy@hxr.us URI：http://www.verisignlabs.com/

Marcos Sanz DENIC eG Wiesenhuettenplatz 26 D-60329 Frankfurt Germany

マルコスサンスDENIC Wiesenhuettenplatz 26 D-60329フランクフルトドイツ

EMail: sanz@denic.de URI: http://www.denic.de/

電子メール：sanz@denic.de URI：http://www.denic.de/

Full Copyright Statement

完全な著作権声明

著作権（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.

この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。

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.

IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンライン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-ipr@ietf.orgのIETFに情報を記述してください。

Acknowledgement

謝辞

Funding for the RFC Editor function is currently provided by the Internet Society.

RFC Editor機能のための基金は現在、インターネット協会によって提供されます。

RFC 3981 - IRIS: The Internet Registry Information Service (IRIS) Core Protocol 日本語訳

1. Introduction

1. はじめに

1.1. Use of XML

1.1. XMLの使用

1.2. General Concepts

1.2. 一般概念

1.3. Framework Layers

1.3. フレームワークのレイヤー

1.4. Definitions

1.4. 定義

1.5. Further Reading

1.5. 参考文献

2. Document Terminology

2.ドキュメントの用語

3. Protocol Identification

3.プロトコル識別

4. Exchange Description

4.交換の説明

4.1. Request Format

4.1. リクエストのフォーマット

4.2. Response Format

4.2. レスポンスフォーマット

4.3. Extension Framework

4.3. 拡張フレームワーク

4.3.1. Derived Elements

4.3.1. 派生要素

4.3.2. Registry Type Identifier Requirements

4.3.2. レジストリタイプ識別子の要件

4.3.3. Entity Classes

4.3.3. エンティティークラス

4.3.4. Names of Entities

4.3.4. 実体の名前

4.3.5. References to Entities

4.3.5. エンティティへの参照

4.3.6. Temporary Entities

4.3.6. 一時的なエンティティ

4.3.7. <result> Derived Elements

4.3.7. <結果>派生要素

4.3.7.1. <serviceIdentification>

4.3.7.1。 <serviceIdentification>

4.3.7.2. <limits>

4.3.7.2。 <制限>

4.3.7.3. <simpleEntity>

4.3.7.3。 <simpleEntity>

4.3.8. <control> and <reaction> Elements

4.3.8. <コントロール>と<反応>要素

4.4. Relay Bags

4.4. リレーバッグ

5. Database Serialization

5.データベースのシリアライゼーション

6. Formal XML Syntax

6.正式なXML構文

7. The IRIS URI

7.パリON

7.1. URI Definition

7.1. URIの定義

7.2. Transport Specific Schemes

7.2. 具体的なスキームを輸送

7.3. URI Resolution

７。３。 うり れそぅちおん

7.3.1. Registry Dependent Resolution

7.3.1. レジストリの依存決議

7.3.2. Direct Resolution

7.3.2. 直接の解決

7.3.3. Transport and Service Location

7.3.3. 交通とサービスの場所

7.4. IRIS URI Examples

7.4. IRIS URIの例

8. Checklists

8.チェックリスト

8.1. Registry Definition Checklist

8.1. レジストリ定義のチェックリスト

8.2. Transport Mapping Checklist

8.2. 交通マッピングのチェックリスト

9. Internationalization Considerations

9.国際化に関する注意事項

10. IANA Considerations

10. IANAの考慮事項

11. Security Considerations

７。３。うりれそぅちおん