RFC3981 日本語訳
3981 IRIS: The Internet Registry Information Service (IRIS) CoreProtocol. A. Newton, M. Sanz. January 2005. (Format: TXT=101359 bytes) (Updated by RFC4992) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group A. Newton
Request for Comments: 3981 VeriSign, Inc.
Category: Standards Track M. Sanz
DENIC eG
January 2005
コメントを求めるワーキンググループA.ニュートンの要求をネットワークでつないでください: 3981年のベリサインInc.カテゴリ: 標準化過程M.サンスDENIC eG2005年1月
IRIS: The Internet Registry Information Service (IRIS) Core Protocol
虹彩: インターネット登録情報サービス(虹彩)コアプロトコル
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.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2005).
Copyright(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
1. 序論. . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1。 XML. . . . . . . . . . . . . . . . . . . . . . . 2 1.2の使用。 一般概念. . . . . . . . . . . . . . . . . . . . 3 1.3。 枠組みの層. . . . . . . . . . . . . . . . . . . . 4 1.4。 定義. . . . . . . . . . . . . . . . . . . . . . 4 1.5。 さらに、.5 2を読みます。 用語. . . . . . . . . . . . . . . . . . . . . 5 3を記録してください。 識別. . . . . . . . . . . . . . . . . . . 5 4について議定書の中で述べてください。 記述. . . . . . . . . . . . . . . . . . . . . 6 4.1を交換してください。 書式. . . . . . . . . . . . . . . . . . . . . 6 4.2を要求してください。 応答形式. . . . . . . . . . . . . . . . . . . . 6 4.3。 拡大枠組み. . . . . . . . . . . . . . . . . . 9 4.3の.1。 要素. . . . . . . . . . . . . . . . 9 4.3.2を引き出しました。 登録タイプ識別子要件. . . . . 10 4.3.3。 実体は.4に.104.3を分類します。 実体. . . . . . . . . . . . . . . 11の名前
Newton & Sanz Standards Track [Page 1] RFC 3981 IRIS-Core January 2005
ニュートンとサンスStandardsは虹彩コア2005年1月にRFC3981を追跡します[1ページ]。
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
4.3.5. 実体. . . . . . . . . . . . . 11 4.3.6の参照。 一時的な実体. . . . . . . . . . . . . . . 12 4.3.7。 <結果>は要素. . . . . . . . . . . 13 4.3.8を引き出しました。 <コントロール>と<反応>要素. . . . . . . 16 4.4。 バッグ. . . . . . . . . . . . . . . . . . . . . . . 18 5をリレーしてください。 データベース連載. . . . . . . . . . . . . . . . . . . . 19 6。 正式なXML構文. . . . . . . . . . . . . . . . . . . . . . 22 7。 虹彩URI. . . . . . . . . . . . . . . . . . . . . . . . . 37 7.1。 URI定義. . . . . . . . . . . . . . . . . . . . . 37 7.2。 特定の計画. . . . . . . . . . . . . . . 38 7.3を輸送してください。 URI解決. . . . . . . . . . . . . . . . . . . . . 38 7.3.1。 登録依存する解決. . . . . . . . . 38 7.3.2。 解決. . . . . . . . . . . . . . . 39 7.3.3を指示してください。 位置. . . . . . . . . 39 7.4を輸送して、修理してください。 虹彩URIの例. . . . . . . . . . . . . . . . . . . 40 8。 チェックリスト. . . . . . . . . . . . . . . . . . . . . . . . . . 41 8.1。 登録定義チェックリスト. . . . . . . . . . . . . 41 8.2。 マッピングチェックリスト. . . . . . . . . . . . . . 42 9を輸送してください。 国際化問題. . . . . . . . . . . . . 42 10。 IANA問題. . . . . . . . . . . . . . . . . . . . . 43 11。 セキュリティ問題. . . . . . . . . . . . . . . . . . . 43 12。 参照. . . . . . . . . . . . . . . . . . . . . . . . . . 43 12.1。 引用規格. . . . . . . . . . . . . . . . . . 43 12.2。 有益な参照. . . . . . . . . . . . . . . . . 45A.S-NAPTRと虹彩は.46A.1を使用します。 虹彩があるS-NAPTRに関する例。 . . . . . . . . . . . . . 46 A.2。 同棲. . . . . . . . . . . . . 47B.虹彩設計理念. . . . . . . . . . . . . . . . . . . . 48B.1にS-NAPTRを使用します。 根本的な前提. . . . . . . . . . . . . . . . . . . 48B.2。 普遍的なクライアント.49B.3からの魅力。 サーバ問題. . . . . . . . . . . . . . . . . 49B.4。 ルックアップ、検索、および実体のクラス. . . . . . . . . 50B.5。 実体参照箇所、検索続刊、および.50の範囲C.承認. . . . . . . . . . . . . . . . . . . . . . . 51作者のアドレス. . . . . . . . . . . . . . . . . . . . . . . . 51の完全な著作権宣言文. . . . . . . . . . . . . . . . . . . . . 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
このドキュメントはインターネットRegistry情報Service(IRIS)(様々な登録情報サービスの質問タイプと結果タイプについて説明することを意図するXMLテキストプロトコル)のための仕様を説明します。 IRISは、拡張マークアップ言語を使用することによって、指定されます。
Newton & Sanz Standards Track [Page 2] RFC 3981 IRIS-Core January 2005
ニュートンとサンスStandardsは虹彩コア2005年1月にRFC3981を追跡します[2ページ]。
(XML) 1.0 as described in [2], XML Schema notation as described in [4] and [5], and XML Namespaces as described in [3].
[3]で説明されるように[2]、[4]と[5]で説明されるXML Schema記法、およびXML Namespacesで説明される(XML。)1.0
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例の中で使用されたUniform Resource Name(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.
これらのURNsの構造はそれらが特定する登録のタイプの上でどんな仮定も制限もしません。 したがって、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図式は特定のサービス例か1セットの例に関するどんな登録、登録識別子、または知識も指定しません。 IRISはこれらの登録が使用されて、定義されて、いくつかの場合、共同利用できる枠組みのための仕様です。 枠組みは単に質問と結果を引き出すのに使用しなければならない登録識別と要素に要素を指定します。
This framework allows a registry type to define its own structure for naming, entities, queries, etc., through the use of XML namespaces and XML schemas (hence, a registry type MUST be identified by the same URI that identifies its XML namespace). To be compliant, a registry type's specification must extend from this framework.
この枠組みで、登録タイプは命名、実体、質問などのためにXML名前空間とXML schemasの使用でそれ自身の構造を定義できます(したがって、XML名前空間を特定するのと同じURIで登録タイプを特定しなければなりません)。 言いなりになるために、登録タイプの仕様はこの枠組みから広がらなければなりません。
The framework defines certain structures that can be common to all registry types, such as references to entities, search continuations, and entity classes. A registry type may declare its own definitions for all of these, or it may mix its derived definitions with the base definitions.
枠組みはすべての登録タイプに、一般的である場合がある、ある構造を定義します、実体の参照や、検索続刊や、実体のクラスなどのように。 登録タイプがこれらのすべてのためのそれ自身の定義を宣言するかもしれませんか、またはそれは派生している定義をベース定義に混ぜるかもしれません。
IRIS defines two types of referrals: an entity reference and a search continuation. An entity reference indicates specific knowledge about an individual entity, and a search continuation allows distributed searches. Both referrals may span differing registry types and instances. No assumptions or specifications are made about the roots, bases, or meshes of entities.
IRISは2つのタイプの紹介を定義します: 実体参照と検索継続。 実体参照は個々の実体に関する特定の知識を示します、そして、検索継続は分配された検索を許します。 両方の紹介は異なった登録タイプと例にかかるかもしれません。 どんな仮定も仕様も実体のルーツ、ベース、またはメッシュの周りでされません。
Newton & Sanz Standards Track [Page 3] RFC 3981 IRIS-Core January 2005
ニュートンとサンスStandardsは虹彩コア2005年1月にRFC3981を追跡します[3ページ]。
1.3. Framework Layers
1.3. 枠組みの層
The IRIS framework can be thought of as having three layers.
3つの層を持っているとIRIS枠組みを考えることができます。
-----------------------------
Registry-Specific |domain | address | etc... |
-----------------------------
Common-Registry | IRIS |
-----------------------------
Application-Transport | beep | iris-lwz | etc... |
-----------------------------
----------------------------- 登録特有です。|ドメイン| アドレス| など。 | ----------------------------- 一般的な登録| 虹彩| ----------------------------- アプリケーション輸送| ビープ音| 虹彩-lwz| など。 | -----------------------------
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.
[20])を見て、この図では、「ビープ音」はBlocks Extensible Exchangeプロトコル(BEEP)を示します。(「虹彩-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 実体のクラス--普通形か一般的なセットの特性がある実体のグループ。
Newton & Sanz Standards Track [Page 4] RFC 3981 IRIS-Core January 2005
ニュートンとサンスStandardsは虹彩コア2005年1月にRFC3981を追跡します[4ページ]。
o entity name -- The identifier used to refer to a single entity
within an entity class.
o 実体名--識別子は以前はよく実体のクラスの中の単一体について言及していました。
o entity reference -- A pointer to an entity composed of an
authority, an optional resolution method, a registry type, an
entity class, and an entity name. One type of entity reference is
the IRIS URI (defined in Section 7).
o 実体参照--実体へのポインタは権威、任意の解決方法、登録タイプ、実体のクラス、および実体名で構成されました。 1つのタイプに関する実体参照はIRIS URI(セクション7では、定義される)です。
The terms "derivative", "derive", and "derivation" are used with the same meaning for deriving one type of element from another as specified in XML_SS [5].
「派生物」という用語、「派生」、および「派生」は、XML_SS[5]の指定されるとしての別のものから1つのタイプの要素を得るのに同じ意味と共に使用されます。
1.5. Further Reading
1.5. 一層の読書
Appendix B contains text answering the question, "Why IRIS?".
付録Bは「なぜ虹彩?」と質問に答えるテキストを含んでいます。
This document describes the structure at the core of IRIS. The following documents describe the other aspects of IRIS relevant to CRISP [17]: iris-beep [1] and iris-dreg [18].
このドキュメントはIRISのコアにおける構造について説明します。 以下のドキュメントはCRISP[17]に関連しているIRISの他の局面について説明します: 虹彩ビープ音[1]と虹彩かすの[18]。
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"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはBCP14(RFC2119[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'の使用がこの仕様に関するOPTIONALであり、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プロトコルのVersioningはアプリケーショントランスポート層の責任ですが、IRISを表すXML名前空間[3]URIに関連しているに違いありません。 このURIにおける変化は、基本的な図式の変化を示して、その結果プロトコル(逆もまた同様である)の新しいバージョンを示します。
Newton & Sanz Standards Track [Page 5] RFC 3981 IRIS-Core January 2005
ニュートンとサンスStandardsは虹彩コア2005年1月にRFC3981を追跡します[5ページ]。
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構文の範囲の外に仕様を保管しています。 したがって、このセクションはRFC2119[8]によって定義された、正式なXML構文の範囲の外で仕様を説明した用語を使用するでしょう。 このセクションを読んでいる間、正式な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を使用することによって特定の登録タイプについて質問するのを可能にします。 2人の子供のひとりでこれを見つけることができます: <lookupEntity>と<は>について質問します。
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>要素は特定の登録で実体のルックアップについて説明します。 この要素には、3つの属性があります: 'registryType'、'entityClass'、および'entityName'。 'registryType'属性はルックアップ操作が行われる登録タイプへの登録識別子を含んでいます。 'entityClass'属性はルックアップ操作が行われるインデックスを特定する象徴を含んでいます、そして、'entityName'属性は見上げる実体の名前を含んでいます。
The <query> element is abstract and may not legally appear in an XML instance. It provides the base type that registry schemas will use to define derived query types. This derivation mechanism is described in Section 4.3.
<質問>要素は、抽象的であり、XML例に法的に現れないかもしれません。 それはschemasが派生している質問タイプを定義するのに使用するその登録をベースタイプに提供します。 この派生メカニズムはセクション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>の子供として現れるとき、それは'イド'属性を含んではいけません。 <バッグ>要素の記述に関しては、セクション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つの子供要素も含むかもしれません。 この子供要素で、クライアントは特別な州か処理のためのサーバに合図できます。 そのような要素の<コントロール>子供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.
<応答>要素は任意の<反応>要素、1セットの<resultSet>要素を含んでいます、そして、任意の<は>要素を膨らませます。
Newton & Sanz Standards Track [Page 6] RFC 3981 IRIS-Core January 2005
ニュートンとサンスStandardsは虹彩コア2005年1月にRFC3981を追跡します[6ページ]。
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インスタンスに法的に置かれないかもしれません。 派生している結果タイプを定義するのに登録schemasによって使用されるように、それはベースタイプを提供します。 この派生メカニズムはセクション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>要素は質問紹介を指定します。 1人の子供が<質問>から得られたあらゆる要素(セクション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.
実体参照と検索続刊に続くとき、クライアントSHOULDは一度<実体>か<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>--対応する質問はこのサーバで後押しされていません。
Newton & Sanz Standards Track [Page 7] RFC 3981 IRIS-Core January 2005
ニュートンとサンスStandardsは虹彩コア2005年1月にRFC3981を追跡します[7ページ]。
o <limitExceeded> -- The corresponding query requires more resources
than allowed.
o <は>をlimitExceededしました--対応する質問は許容されているより多くのリソースを必要とします。
o <nameNotFound> -- The name given in a query does not match a known
entity.
o <nameNotFound>--質問で与えられた名前は知られている実体に合っていません。
o <permissionDenied> -- The authentication given does not allow
access to a specific result entry.
o <は>をpermissionDeniedしました--与えられた認証は特定の結果エントリーへのアクセスを許しません。
o <bagUnrecognized> -- The contents of a bag were unrecognized. See
Section 4.4.
o <は>をbagUnrecognizedしました--バッグの内容は認識されていませんでした。 セクション4.4を見てください。
o <bagUnacceptable> -- The contents of a bag were not and never will
be acceptable. See Section 4.4.
o <bagUnacceptable>--バッグの内容は、なくて、また決して許容できないでしょう。 セクション4.4を見てください。
o <bagRefused> -- The contents of a bag were not acceptable at this
time. See Section 4.4.
o <は>をbagRefusedしました--バッグの内容はこのとき、許容できませんでした。 セクション4.4を見てください。
o A derivative of <genericCode>, as described in Section 4.3.
o セクション4.3で説明されるような<genericCode>の派生物。
The <resultSet> section is divided into the <answer> and <additional> sections to allow easier processing and navigation of the results by a client. Servers MUST return the direct answers to queries in the <answer> element and MAY return results in the <additional> element for which a reference has been made in the <answer> element. Results in the <additional> element MUST have been referenced in the <answer>, either as direct children of the <answer> element or as deeper descendants of the <answer> element.
<resultSet>部は、クライアントで結果の、より簡単な処理とナビゲーションを許容するために<答え>と<の追加>部に分割されます。 サーバは、<答え>要素で質問のダイレクト答えを返さなければならなくて、参照が<答え>要素で行われた<の追加>要素で結果を返すかもしれません。 <の追加>要素の結果は<答え>要素のダイレクト子供として、または、<答え>か、<答え>要素の、より深い子孫として参照をつけられたに違いありません。
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つの目的に役立ちます。 まず最初に、それは<答え>要素に含まれた参照のためにクライアントで再質問を排除するかもしれません。 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
<バッグ>要素(<応答>の子供)は任意です。 それは<バッグ>要素を含んでいます、そして、それぞれの<バッグ>要素の内容はどんなXML名前空間でも1つの要素を構成します。 それぞれの<バッグ>要素には、'イド'属性があります。(それは、実体の'bagRef'属性によって参照をつけられます)。
Newton & Sanz Standards Track [Page 8] RFC 3981 IRIS-Core January 2005
ニュートンとサンスStandardsは虹彩コア2005年1月にRFC3981を追跡します[8ページ]。
references (<entity>) and search continuations (<searchContinuation>). See Section 4.4.
参照(<実体>)と検索続刊(<searchContinuation>)。 セクション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図式が1つの質問タイプだけを定義して、2のスタンドの単独の結果がタイプして、登録構造を定義しないので、それは限られてそれ自体で役に立ちます。 IRISの拡大はベースIRIS図式の使用で実行されます、XML_サウスダコタ[4]とXML_SS[5]と、IRISの上で組み立てられたschemasによるそれの拡大を通して定義されるように。
4.3.1. Derived Elements
4.3.1. 派生しているElements
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 Schema定義は、ベースタイプからIRIS定義で要素型を得るために登録タイプをschemasに要求します。 登録schemasは、タイプされた質問と結果を定義するために要素を引き出さなければなりません。
While the IRIS schema definition does not prohibit the derivation of any elements, registry schemas SHOULD restrict the derivations to the following types:
IRIS図式定義はどんな要素の派生も禁止しませんが、登録schemas SHOULDは派生を以下のタイプに制限します:
o <query> -- As defined, this element contains no content and has no
valid attributes. It is abstract and therefore only its
derivatives appear in XML instances. Registry schemas derive from
this element to define the queries allowed.
o <質問>--定義されるように、この要素は、内容を全く含んでいなくて、またどんな有効な属性も持っていません。 それは抽象的です、そして、したがって、派生物だけがXMLインスタンスに現れます。 登録schemasが、許された質問を定義するためにこの要素に由来しています。
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''entityName'、および'temporaryReference'(任意であることで、セクション4.3.6を見てください)。 それは抽象的です、そして、したがって、派生物だけがXMLインスタンスに現れます。 登録schemasが、質問から返されるかもしれない結果を定義するためにこの要素に由来しています。
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 <実体>--実体の参照を特定します。 直接<実体>を使用するかもしれないのを除いて、要素が<実体>から引き出した登録schemas SHOULD使用。 ダイレクト使用に対して<実体から>を引き出す利点は要素の名前を定義して、その名前描写的を使用する機会です--例えば、役割として、実体は別の実体に関してプレーします。 セクション4.3.5を見てください。
Newton & Sanz Standards Track [Page 9] RFC 3981 IRIS-Core January 2005
ニュートンとサンスStandardsは虹彩コア2005年1月にRFC3981を追跡します[9ページ]。
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)からこの要素を得ます。 登録schemasはこの要素か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 Schemaによって使用された登録タイプとXML名前空間識別子のための識別子は同じであるに違いありません。 これらの識別子をXML_URN[9]によって治められたIANA登録の'ナノ秒'のクラスで登録されたURN[7]に制限しなければなりません。 これらの識別子は大文字と小文字を区別しないです。
This is a restriction on XML_NS [3], which specifies that an XML namespace identifier is any valid URI [6].
これはXML_NS[3]における制限です。NSはXML名前空間識別子があらゆる有効なURI[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、「つぼ:ietf:params: xml:ナノ秒: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 Schema[4]が図式識別にURIの使用を指定するか、またはXML_NS[3]がXML名前空間識別に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に、0インチが言及するかもしれない.2は「ネームサーバ」と「ネットワーク」のクラスで実体を切り離す」と命名します。 実体、「192.0に、「ネームサーバ」における0インチが分類する.2がネームサーバホストにも言及するかもしれない、マルチ、家へ帰り、ところが、"ns.example.com"として.2の.255と知られているコネがDNSであると192.0に扱ってください、実体、「192.0 .2 「ネットワーク」のクラスにおける0インチがネットワーク192.0.2/30を参照するかもしれない、」
IRIS defines two default entity classes of "local" and "iris", which MUST NOT be redefined. These entity classes MUST be valid in all registry types.
IRISは「地方」の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/
「地方」のクラスは、サーバオペレータによって局所的に定義された実体のために予約されて、どんな特定のタイプの実体も指示しません。 この実体のクラスにおけるルックアップは実体参照か検索継続をもたらすかもしれません。 例えば、「虹彩: dreg1//example.com/local/」
Newton & Sanz Standards Track [Page 10] RFC 3981 IRIS-Core January 2005
ニュートンとサンスStandardsは虹彩コア2005年1月にRFC3981を追跡します[10ページ]。
myhosts" may result in a search continuation yielding the nameservers for example.com.
"myhosts"はネームサーバfor 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 セクション4.3を見てください。<serviceIdentification>の結果をもたらす「イド」、(.7 .1)。
o "limits", which yields a result of <limits> (see Section 4.3.7.2).
This entity class MAY contain other locally defined entities as
well.
o セクション4.3を見てください。「限界」(<の結果をもたらす)が>を制限する、(.7 .2)。 この実体のクラスはまた、他の局所的に定義された実体を含むかもしれません。
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_サウスダコタ[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_サウスダコタ[4]によって定義されるようにタイプトークンのものです。
Names of entities SHOULD be unique within an instance of any particular entity class within a registry. Two entities SHOULD NOT have the same name, but a single entity MAY be known by multiple names. In situations where a single name may result in two entities, the registry schema SHOULD make allowances by defining result types that contain entity references to both entities (e.g., "example.com" can refer to both the domain example.com and the host example.com). However, this type of conflict SHOULD generally be avoided by the proper use of entity classes.
名前、実体SHOULDでは、登録の中のどんな特定の実体のクラスのインスタンスの中でもユニークであってください。 しかしSHOULD NOTが同じくらいに単一体と命名させる2つの実体が複数の名前によって知られているかもしれません。 ただ一つの名前が2つの実体をもたらすかもしれない状況で、登録図式SHOULDは、両方の実体の実体参照を含む結果タイプを定義することによって、さじ加減します(例えば、"example.com"はドメインexample.comとホストexample.comの両方を示すことができます)。 しかしながら、これは闘争SHOULDをタイプします。一般に、実体のクラスの適切な使用で、避けられます。
The case sensitivity of entity names is dependent on the entity class in which they reside. The definition of a registry type MUST specify the case sensitivity for entity names. A registry type MAY define the entity names of differing entity classes as having different case sensitivity.
実体名のケース感度はそれらが住んでいる実体のクラスに依存しています。 登録タイプの定義は実体名にケース感度を指定しなければなりません。 登録タイプは異なった実体のクラスの実体名を異なったケース感度を持っていると定義するかもしれません。
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
要素<実体>は<resultSet>のダイレクト子供、または、結果セットにおける実体か、<から結果>を引き出すより複雑な構造の中で参照を許します。 <実体>要素は'entityType'によって定義されます。 登録schemas SHOULDは実体に参照をつけるとき<実体>から得られた要素を定義しますが、直接<実体>要素を使用するかもしれません。 新しい要素を引き出すのに、登録図式は使用できます。
Newton & Sanz Standards Track [Page 11] RFC 3981 IRIS-Core January 2005
ニュートンとサンスStandardsは虹彩コア2005年1月にRFC3981を追跡します[11ページ]。
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>の<答え>部などの)、代用品として<実体>の派生物を使用してはいけません。
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'、および'entityName'--これらの属性は、実体がどこで見つけられるかもしれないかを指定します。
o 'temporaryReference' -- This attribute is optional. See Section
4.3.6.
o 'temporaryReference'--この属性は任意です。 セクション4.3.6を見てください。
o 'referentType' -- This attribute contains the expected type of the
entity being referenced and may contain the word "ANY" or a
qualified XML name. Unlike the other attributes of <entity>, this
attribute is qualified and declared in the IRIS XML namespace.
Therefore it will also be qualified with the prefix associated
with the IRIS XML namespace (e.g., 'iris:referentType'). This
allows clients to recognize entity references using an element
derived from <entity>.
o 'referentType'--この属性は、参照をつけられて、実体の予想されたタイプを含んでいて、「少しも」という単語か適切な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.
実体参照が一時的である必要があるインスタンスは存在するかもしれません。 例えば、特定のタイプの結果に、1個のユニークキーしかないかもしれません。 そのキーがすべてのユーザに暴露されないかもしれない意味意味を含んでいると、合成のキーを代入しなければならないでしょう。
Furthermore, there may be times when data in the data store is not normalized in the same manner as that expressed by the registry schema. In the registry schema, objects of type A may reference objects of type B. But in the data store, objects of type A may contain objects of type B. Again, a synthetic key will have to be temporarily produced.
その上、データ・ストアのデータが登録図式によるそんなに言い表されるのと同じ方法で正常にされない回があるかもしれません。 登録図式、Aがそうするタイプのオブジェクトでは、参照はデータ・ストアでタイプB.Butについて反対して、タイプAのオブジェクトはタイプB.Againのオブジェクトを含むかもしれなくて、合成のキーは一時生産されなければならないでしょう。
Newton & Sanz Standards Track [Page 12] RFC 3981 IRIS-Core January 2005
ニュートンとサンスStandardsは虹彩コア2005年1月にRFC3981を追跡します[12ページ]。
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'、'entityName')は、応答でそれが現れる以内有効であるだけであり、その後の応答と一致していないかもしれません。 サーバは同じ<resultSet>の<の追加>部でのどんな一時的な実体参照の指示物も含まなければなりません。
4.3.7. <result> Derived Elements
4.3.7. <結果>はElementsを引き出しました。
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=」虹彩」entityNameは「イド」><当局><権威>example.com</権威><権威>example.net</権威><権威>の例と等しいです; org</権威></当局><operatorName>インターネットAssigned民数記Authority</operatorName><eMail> iana@iana.org 、lt;、/eMail></serviceIdentification>。
The <serviceIdentification> element is provided to allow IRIS clients to reference IRIS service instances. It contains the following elements:
参照IRISサービスインスタンスにIRISクライアントを許容するために<serviceIdentification>要素を提供します。 それは以下の要素を含んでいます:
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権威コンポーネントを含んでいます。 オペレータ方針によって、サーバは権威領域の部分的なリストを返すだけであるかもしれませんが、要求されていて、それはクライアントがそうした権威を返さなければなりません。
Newton & Sanz Standards Track [Page 13] RFC 3981 IRIS-Core January 2005
ニュートンとサンスStandardsは虹彩コア2005年1月にRFC3981を追跡します[13ページ]。
o <operatorName> -- This element contains the name of the operator
of the server.
o <operatorName>--この要素はサーバのオペレータの名前を含んでいます。
o <eMail> -- These optional elements contain email addresses of the
operator of the service instance.
o <eMail>--これらの随意的な要素はサービスインスタンスのオペレータのEメールアドレスを含んでいます。
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:
<に関する例は>結果を制限します:
<limits
authority="example.com" registryType="dreg1"
entityClass="iris" entityName="limits">
<totalQueries>
<perHour>2</perHour>
<perDay>15</perDay>
</totalQueries>
<totalResults>
<perHour>25</perHour>
<perDay>200</perDay>
</totalResults>
<totalSessions>
<perHour>2</perHour>
<perDay>15</perDay>
</totalSessions>
</limits>
「<は「dreg1" entityClass=」"example.com"権威=registryType=虹彩を制限する」entityNameが等しい、「「><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>の子供として一度現れるだけでよいのですが、1人以上の子供が出席しているかもしれません。 例えば、サーバは、1分あたり15の質問にもかかわらず、1日あたり60の質問だけを受け入れるのを示すかもしれません。
Newton & Sanz Standards Track [Page 14] RFC 3981 IRIS-Core January 2005
ニュートンとサンスStandardsは虹彩コア2005年1月にRFC3981を追跡します[14ページ]。
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>
「"example.com"<simpleEntity権威=registryTypeは「dreg1" entityClass=」と地方であることで等しく」entityName=「通知」><特性名が「法的な」言語=と等しい、「アン、「RFC2606によると、>Example.comは予約されます」。 </特性の></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に関連しているのを許容して。
Newton & Sanz Standards Track [Page 15] RFC 3981 IRIS-Core January 2005
ニュートンとサンスStandardsは虹彩コア2005年1月にRFC3981を追跡します[15ページ]。
Clients may easily display such information in a two-column table. Applications using binary data or richer data structures are out of scope for this element. When such usage scenarios arise, a client will likely need specific knowledge to handle such data, thus calling the need for a new registry type into question.
クライアントは容易に2コラムのテーブルのそのような情報を表示するかもしれません。 この要素のための範囲の外にバイナリ・データを使用するアプリケーションか、より豊かなデータ構造があります。 そのような用法シナリオが起こると、クライアントはそのようなデータを扱うためにおそらく特定の知識を必要とするでしょう、その結果、タイプを新しい登録の必要性に質問に電話をします。
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の再versioningか登録タイプを必要としないで問い合わせ処理のための方針を採ることができるように伸展性を許容することです。
This document defines one control, <onlyCheckPermissions>, and its requisite reaction, <standardReaction>, for compliance with CRISP [17].
このドキュメントはCRISP[17]への承諾ために1つのコントロール、<onlyCheckPermissions>、および必要な反応、<standardReaction>を定義します。
When a client sends an <onlyCheckPermissions> control, it is only asking the server to check to see whether adequate permissions are available to execute the queries in the associated request. A server MUST respond to this control with a <standardReaction> element.
クライアントが<onlyCheckPermissions>コントロールを送るとき、それは、適切な許容が関連要求における質問を実行するために利用可能であるかどうか確認するためにチェックするようにサーバに頼んでいるだけです。 サーバは<standardReaction>要素でこのコントロールに反応しなければなりません。
The <standardReaction> element provides a server with a standard means to respond to controls (it may be used by other controls, but this is left to their definition). It contains four children:
<standardReaction>要素はコントロールに応じる標準の手段をサーバに提供します(それが他のコントロールで使用されるかもしれませんが、これは彼らの定義に残されます)。 それは4人の子供を含みます:
o <controlAccepted> -- the processing or state needed by the control
has been accepted.
o <は>をcontrolAcceptedしました--コントロールで必要である処理か状態を受け入れました。
o <controlDenied> -- the processing or state needed by the control
has been denied (a transient failure).
o <は>をcontrolDeniedしました--(一時障害)はコントロールで必要である処理か状態に対して否定されました。
o <controlDisabled> -- the processing or state needed by the control
cannot be activated (a permanent failure).
o <は>をcontrolDisabledしました--コントロールで必要である処理か状態は起動できません(永久的な失敗)。
o <controlUnrecognized> -- the control is not recognized (a
permanent failure).
o <は>をcontrolUnrecognizedしました--コントロールは認識されません(永久的な失敗)。
If <onlyCheckPermissions> is rejected, then the server MUST return all appropriate result sets (i.e., for every search set in the request), but all result sets MUST be empty of results and MUST contain no errors (a reaction is not part of a result set and is therefore not a result set error). This control applies to all search sets or none of them; therefore a server MUST issue a rejection if <onlyCheckPermissions> cannot be accepted for all search sets in a request.
<onlyCheckPermissions>が拒絶されるならサーバがすべての適切な結果セット(すなわち、要求に設定されたあらゆる検索のための)を返さなければなりませんが、すべての結果セットが、結果がなくなければならなく、誤りを全く含んではいけません(結果の一部がセットしたということでなく、またしたがって、反応は結果セット誤りではありません)。 このコントロールはそれらのすべての検索セットかいずれにも申請されません。 したがって、要求におけるすべての検索セットのために<onlyCheckPermissions>を受け入れることができないなら、サーバは拒絶を発行しなければなりません。
Newton & Sanz Standards Track [Page 16] RFC 3981 IRIS-Core January 2005
ニュートンとサンスStandardsは虹彩コア2005年1月にRFC3981を追跡します[16ページ]。
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バージョン= 「1インチ?」>C: <要求xmlnsが等しい、「つぼ:ietf:params: xml:ナノ秒:iris1"C:、」 xmlns: xsiは" http://www.w3.org/2001/XMLSchema-instance ">Cと等しいです: C: <コントロール>C: <onlyCheckPermissions/>C: </コントロール>C: C: <searchSet>C: C: <lookupEntity C: registryTypeが等しい、「dreg1"C:」 entityClassは「地方」のCと等しいです: entityNameは"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バージョン= 「1インチ?」>S: <応答xmlnsが等しい、「つぼ:ietf:params: xml:ナノ秒:iris1"S:、」 xmlns: " http://www.w3.org/2001/XMLSchema-instance "xsi=>S: S: <反応>S: <standardReaction>S: <は/>SをcontrolAcceptedしました: </standardReaction>S: </反応>S: S: <resultSet>S: <答え>S: S: <simpleEntity S: "example.com"権威=registryTypeが等しい、「dreg1"S:」 「地方」のentityClass=entityNameは"AUP">Sと等しいです: <特性の名が「法的な」言語=と等しい、「アン、「>S:」 このサービスSから情報を使用するのは不法です: 求められていない嵩を送る目的には、メールしてください。 S: </特性の>S: </simpleEntity>S: S: </答え>S: </resultSet>S: S: </応答>。
Newton & Sanz Standards Track [Page 17] RFC 3981 IRIS-Core January 2005
ニュートンとサンスStandardsは虹彩コア2005年1月にRFC3981を追跡します[17ページ]。
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によって定義されません、そして、1つのサーバから別のサーバまでそれをリレーするとき、クライアントはバッグのコンテンツに関する少しの仮定もしてはいけません。
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を含む'イド'属性を含まなければなりません。 それらが続かれているとき、使用されるためにバッグを指定しなければならない実体参照と検索続刊は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からの誤りの1つを返さなければなりません。
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バージョン= 「1インチ?」>C: <要求xmlnsが等しい、「つぼ:ietf:params: xml:ナノ秒:iris1"C:、」 xmlns: xsiは" http://www.w3.org/2001/XMLSchema-instance ">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と等しいです: entityNameは"AUP"/>と等しいです。
Newton & Sanz Standards Track [Page 18] RFC 3981 IRIS-Core January 2005
ニュートンとサンスStandardsは虹彩コア2005年1月にRFC3981を追跡します[18ページ]。
C: C: </searchSet> C: C: </request>
C: C: </searchSet> C: C: </request>
S: <?xml version="1.0"?> S: <response xmlns="urn:ietf:params:xml:ns:iris1" S: xmlns:iris="urn:ietf:params:xml:ns:iris1" S: xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" > S: S: <resultSet> S: <answer> S: S: <entity authority="example.com" bagRef="x1" S: registryType="dreg1" S: entityClass="local" entityName="AUP" S: iris:referentType="ANY" > S: <displayName language="en"> S: Acceptable Usage Policy S: </displayName> S: </entity> S: S: </answer> S: </resultSet> S: S: <bags> S: S: <bag id="x1"> S: <simpleBag xmlns="http://example.com/"> S: AAAAB3NzaC1yc2EAAAABIwAAAIEA0ddD+W3Agl0Lel98G1r77fZ S: </simpleBag> S: </bag> S: S: </bags> S: </response>
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>
5. Database Serialization
5. Database Serialization
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.
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.
Newton & Sanz Standards Track [Page 19] RFC 3981 IRIS-Core January 2005
Newton & Sanz Standards Track [Page 19] RFC 3981 IRIS-Core January 2005
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.
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.
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".
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".
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.
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> 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.
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.
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.
The following is an example of serialized IRIS:
The following is an example of serialized 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">
<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">
Newton & Sanz Standards Track [Page 20] RFC 3981 IRIS-Core January 2005
Newton & Sanz Standards Track [Page 20] RFC 3981 IRIS-Core January 2005
<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 authority="iana.org" registryType="dreg1" entityClass="iris" entityName="id" > <authorities> <authority> iana.org </authority> </authorities> <operatorName> Internet Assigned Numbers Authority </operatorName> <eMail> dbarton@iana.org </eMail> <seeAlso iris:referentType="iris:simpleEntity" authority="iana.org" registryType="dreg1" entityClass="local" entityName="notice"> <displayName language="en"> Legal Notice </displayName> </seeAlso> </serviceIdentification>
<serializedReferral>
<source
authority="example.com" registryType="dreg1"
entityClass="iris"
entityName="id"/>
<entity
iris:referentType="iris:serviceIdentification"
authority="iana.org" registryType="dreg1"
entityClass="iris" entityName="id"/>
</serializedReferral>
<serializedReferral> <source authority="example.com" registryType="dreg1" entityClass="iris" entityName="id"/> <entity iris:referentType="iris:serviceIdentification" authority="iana.org" registryType="dreg1" entityClass="iris" entityName="id"/> </serializedReferral>
<simpleEntity
authority="iana.org" registryType="dreg1"
entityClass="local"
entityName="notice" >
<property name="legal" language="en">
Please use the net wisely!
</property>
</simpleEntity>
<simpleEntity authority="iana.org" registryType="dreg1" entityClass="local" entityName="notice" > <property name="legal" language="en"> Please use the net wisely! </property> </simpleEntity>
</iris:serialization>
</iris:serialization>
Newton & Sanz Standards Track [Page 21] RFC 3981 IRIS-Core January 2005
Newton & Sanz Standards Track [Page 21] RFC 3981 IRIS-Core January 2005
6. Formal XML Syntax
6. Formal XML Syntax
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 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.
<?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 version="1.0"?> <schema xmlns="http://www.w3.org/2001/XMLSchema" xmlns:iris="urn:ietf:params:xml:ns:iris1" targetNamespace="urn:ietf:params:xml:ns:iris1" elementFormDefault="qualified" >
<annotation>
<documentation>
Internet Registry Information Service (IRIS) Schema v1
</documentation>
</annotation>
<annotation> <documentation> Internet Registry Information Service (IRIS) Schema v1 </documentation> </annotation>
<!-- ========================================= -->
<!-- -->
<!-- The Transactions -->
<!-- -->
<!-- ========================================= -->
<!-- ========================================= --> <!-- --> <!-- The Transactions --> <!-- --> <!-- ========================================= -->
<element name="request">
<complexType>
<sequence>
<element
name="control"
type="iris:controlType"
minOccurs="0"
maxOccurs="1" />
<element
name="searchSet"
type="iris:searchSetType"
minOccurs="1"
maxOccurs="unbounded" />
</sequence>
</complexType>
</element>
<element name="request"> <complexType> <sequence> <element name="control" type="iris:controlType" minOccurs="0" maxOccurs="1" /> <element name="searchSet" type="iris:searchSetType" minOccurs="1" maxOccurs="unbounded" /> </sequence> </complexType> </element>
<element name="response">
<complexType>
<sequence>
<element
name="reaction"
type="iris:reactionType"
minOccurs="0"
<element name="response"> <complexType> <sequence> <element name="reaction" type="iris:reactionType" minOccurs="0"
Newton & Sanz Standards Track [Page 22] RFC 3981 IRIS-Core January 2005
Newton & Sanz Standards Track [Page 22] RFC 3981 IRIS-Core January 2005
maxOccurs="1" />
<element
name="resultSet"
type="iris:resultSetType"
minOccurs="1"
maxOccurs="unbounded" />
<element
name="bags"
type="iris:bagsType"
minOccurs="0"
maxOccurs="1" />
</sequence>
</complexType>
</element>
maxOccurs="1" /> <element name="resultSet" type="iris:resultSetType" minOccurs="1" maxOccurs="unbounded" /> <element name="bags" type="iris:bagsType" minOccurs="0" maxOccurs="1" /> </sequence> </complexType> </element>
<!-- ========================================= -->
<!-- -->
<!-- Search Sets and Result Sets -->
<!-- -->
<!-- ========================================= -->
<!-- ========================================= --> <!-- --> <!-- Search Sets and Result Sets --> <!-- --> <!-- ========================================= -->
<complexType
name="searchSetType" >
<sequence>
<element
name="bag"
type="iris:bagType"
minOccurs="0"
maxOccurs="1" />
<choice>
<element
name="lookupEntity"
type="iris:lookupEntityType" />
<element
ref="iris:query" />
</choice>
</sequence>
</complexType>
<complexType name="searchSetType" > <sequence> <element name="bag" type="iris:bagType" minOccurs="0" maxOccurs="1" /> <choice> <element name="lookupEntity" type="iris:lookupEntityType" /> <element ref="iris:query" /> </choice> </sequence> </complexType>
<complexType
name="resultSetType" >
<sequence>
<element
name="answer"
minOccurs="1"
maxOccurs="1">
<complexType>
<sequence>
<complexType name="resultSetType" > <sequence> <element name="answer" minOccurs="1" maxOccurs="1"> <complexType> <sequence>
Newton & Sanz Standards Track [Page 23] RFC 3981 IRIS-Core January 2005
Newton & Sanz Standards Track [Page 23] RFC 3981 IRIS-Core January 2005
<element
ref="iris:result"
minOccurs="0"
maxOccurs="unbounded" />
<element
ref="iris:entity"
minOccurs="0"
maxOccurs="unbounded" />
<element
ref="iris:searchContinuation"
minOccurs="0"
maxOccurs="unbounded" />
</sequence>
</complexType>
</element>
<element
name="additional"
minOccurs="0"
maxOccurs="1">
<complexType>
<sequence>
<element
ref="iris:result"
minOccurs="1"
maxOccurs="unbounded" />
</sequence>
</complexType>
</element>
<choice
minOccurs="0"
maxOccurs="1" >
<element
name="insufficientResources"
type="iris:codeType" />
<element
name="invalidName"
type="iris:codeType" />
<element
name="invalidSearch"
type="iris:codeType" />
<element
name="queryNotSupported"
type="iris:codeType" />
<element
name="limitExceeded"
type="iris:codeType" />
<element
name="nameNotFound"
<element ref="iris:result" minOccurs="0" maxOccurs="unbounded" /> <element ref="iris:entity" minOccurs="0" maxOccurs="unbounded" /> <element ref="iris:searchContinuation" minOccurs="0" maxOccurs="unbounded" /> </sequence> </complexType> </element> <element name="additional" minOccurs="0" maxOccurs="1"> <complexType> <sequence> <element ref="iris:result" minOccurs="1" maxOccurs="unbounded" /> </sequence> </complexType> </element> <choice minOccurs="0" maxOccurs="1" > <element name="insufficientResources" type="iris:codeType" /> <element name="invalidName" type="iris:codeType" /> <element name="invalidSearch" type="iris:codeType" /> <element name="queryNotSupported" type="iris:codeType" /> <element name="limitExceeded" type="iris:codeType" /> <element name="nameNotFound"
Newton & Sanz Standards Track [Page 24] RFC 3981 IRIS-Core January 2005
Newton & Sanz Standards Track [Page 24] RFC 3981 IRIS-Core January 2005
type="iris:codeType" />
<element
name="permissionDenied"
type="iris:codeType" />
<element
name="bagUnrecognized"
type="iris:codeType" />
<element
name="bagUnacceptable"
type="iris:codeType" />
<element
name="bagRefused"
type="iris:codeType" />
<element
ref="iris:genericCode"/>
</choice>
</sequence>
</complexType>
type="iris:codeType" /> <element name="permissionDenied" type="iris:codeType" /> <element name="bagUnrecognized" type="iris:codeType" /> <element name="bagUnacceptable" type="iris:codeType" /> <element name="bagRefused" type="iris:codeType" /> <element ref="iris:genericCode"/> </choice> </sequence> </complexType>
<!-- ========================================= -->
<!-- -->
<!-- Controls and Reactions -->
<!-- -->
<!-- ========================================= -->
<!-- ========================================= --> <!-- --> <!-- Controls and Reactions --> <!-- --> <!-- ========================================= -->
<complexType
name="controlType">
<sequence>
<any
namespace="##any"
processContents="skip"
minOccurs="1"
maxOccurs="1" />
</sequence>
</complexType>
<complexType name="controlType"> <sequence> <any namespace="##any" processContents="skip" minOccurs="1" maxOccurs="1" /> </sequence> </complexType>
<complexType
name="reactionType">
<sequence>
<any
namespace="##any"
processContents="skip"
minOccurs="1"
maxOccurs="1" />
</sequence>
</complexType>
<complexType name="reactionType"> <sequence> <any namespace="##any" processContents="skip" minOccurs="1" maxOccurs="1" /> </sequence> </complexType>
<!-- ========================================= -->
<!-- ========================================= -->
Newton & Sanz Standards Track [Page 25] RFC 3981 IRIS-Core January 2005
Newton & Sanz Standards Track [Page 25] RFC 3981 IRIS-Core January 2005
<!-- -->
<!-- Queries and Lookups -->
<!-- -->
<!-- ========================================= -->
<!-- --> <!-- Queries and Lookups --> <!-- --> <!-- ========================================= -->
<complexType
name="queryType" />
<complexType name="queryType" />
<element
name="query"
type="iris:queryType"
abstract="true" />
<element name="query" type="iris:queryType" abstract="true" />
<complexType
name="lookupEntityType" >
<attribute
name="registryType"
type="anyURI"
use="required" />
<attribute
name="entityClass"
type="token"
use="required" />
<attribute
name="entityName"
type="token"
use="required" />
</complexType>
<complexType name="lookupEntityType" > <attribute name="registryType" type="anyURI" use="required" /> <attribute name="entityClass" type="token" use="required" /> <attribute name="entityName" type="token" use="required" /> </complexType>
<!-- ========================================= -->
<!-- -->
<!-- Results -->
<!-- -->
<!-- ========================================= -->
<!-- ========================================= --> <!-- --> <!-- Results --> <!-- --> <!-- ========================================= -->
<complexType
name="resultType">
<attribute
name="authority"
use="required"
type="token" />
<attribute
name="resolution"
type="token" />
<attribute
name="registryType"
use="required"
type="anyURI" />
<complexType name="resultType"> <attribute name="authority" use="required" type="token" /> <attribute name="resolution" type="token" /> <attribute name="registryType" use="required" type="anyURI" />
Newton & Sanz Standards Track [Page 26] RFC 3981 IRIS-Core January 2005
Newton & Sanz Standards Track [Page 26] RFC 3981 IRIS-Core January 2005
<attribute
name="entityClass"
use="required"
type="token" />
<attribute
name="entityName"
use="required"
type="token" />
<attribute
name="temporaryReference"
default="false"
type="boolean" />
</complexType>
<attribute name="entityClass" use="required" type="token" /> <attribute name="entityName" use="required" type="token" /> <attribute name="temporaryReference" default="false" type="boolean" /> </complexType>
<element
name="result"
type="iris:resultType"
abstract="true" />
<element name="result" type="iris:resultType" abstract="true" />
<!-- ========================================= -->
<!-- -->
<!-- Errors -->
<!-- -->
<!-- ========================================= -->
<!-- ========================================= --> <!-- --> <!-- Errors --> <!-- --> <!-- ========================================= -->
<complexType
name="codeType">
<sequence
minOccurs="0"
maxOccurs="unbounded">
<element
name="explanation">
<complexType>
<simpleContent>
<extension
base="string">
<attribute
use="required"
name="language"
type="language" />
</extension>
</simpleContent>
</complexType>
</element>
</sequence>
</complexType>
<element
name="genericCode"
<complexType name="codeType"> <sequence minOccurs="0" maxOccurs="unbounded"> <element name="explanation"> <complexType> <simpleContent> <extension base="string"> <attribute use="required" name="language" type="language" /> </extension> </simpleContent> </complexType> </element> </sequence> </complexType> <element name="genericCode"
Newton & Sanz Standards Track [Page 27] RFC 3981 IRIS-Core January 2005
Newton & Sanz Standards Track [Page 27] RFC 3981 IRIS-Core January 2005
type="iris:codeType"
abstract="true" />
type="iris:codeType" abstract="true" />
<!-- ========================================= -->
<!-- -->
<!-- Entity References and -->
<!-- Search Continuations -->
<!-- -->
<!-- ========================================= -->
<!-- ========================================= --> <!-- --> <!-- Entity References and --> <!-- Search Continuations --> <!-- --> <!-- ========================================= -->
<complexType
name="entityType">
<sequence>
<element
name="displayName"
minOccurs="0"
maxOccurs="unbounded">
<complexType>
<simpleContent>
<extension
base="string">
<attribute
name="language"
use="required"
type="language" />
</extension>
</simpleContent>
</complexType>
</element>
</sequence>
<attribute
name="authority"
use="required"
type="token" />
<attribute
name="resolution"
type="token" />
<attribute
name="registryType"
use="required"
type="anyURI" />
<attribute
name="entityClass"
use="required"
type="token" />
<attribute
name="entityName"
use="required"
<complexType name="entityType"> <sequence> <element name="displayName" minOccurs="0" maxOccurs="unbounded"> <complexType> <simpleContent> <extension base="string"> <attribute name="language" use="required" type="language" /> </extension> </simpleContent> </complexType> </element> </sequence> <attribute name="authority" use="required" type="token" /> <attribute name="resolution" type="token" /> <attribute name="registryType" use="required" type="anyURI" /> <attribute name="entityClass" use="required" type="token" /> <attribute name="entityName" use="required"
Newton & Sanz Standards Track [Page 28] RFC 3981 IRIS-Core January 2005
Newton & Sanz Standards Track [Page 28] RFC 3981 IRIS-Core January 2005
type="token" />
<attribute
name="referentType"
use="required"
form="qualified"
type="iris:referentTypeType" />
<attribute
name="temporaryReference"
default="false"
type="boolean" />
<attribute
name="bagRef"
type="IDREF" />
</complexType>
type="token" /> <attribute name="referentType" use="required" form="qualified" type="iris:referentTypeType" /> <attribute name="temporaryReference" default="false" type="boolean" /> <attribute name="bagRef" type="IDREF" /> </complexType>
<element
name="entity"
type="iris:entityType" />
<element name="entity" type="iris:entityType" />
<simpleType
name="referentTypeType">
<union
memberTypes="QName iris:anyLiteralType" />
</simpleType>
<simpleType name="referentTypeType"> <union memberTypes="QName iris:anyLiteralType" /> </simpleType>
<simpleType
name="anyLiteralType">
<restriction
base="string">
<enumeration
value="ANY" />
</restriction>
</simpleType>
<simpleType name="anyLiteralType"> <restriction base="string"> <enumeration value="ANY" /> </restriction> </simpleType>
<complexType
name="searchContinuationType">
<sequence>
<element ref="iris:query" />
</sequence>
<attribute
name="bagRef"
type="IDREF" />
<attribute
name="authority"
type="token"
use="required" />
<attribute
name="resolution"
<complexType name="searchContinuationType"> <sequence> <element ref="iris:query" /> </sequence> <attribute name="bagRef" type="IDREF" /> <attribute name="authority" type="token" use="required" /> <attribute name="resolution"
Newton & Sanz Standards Track [Page 29] RFC 3981 IRIS-Core January 2005
Newton & Sanz Standards Track [Page 29] RFC 3981 IRIS-Core January 2005
type="token" />
</complexType>
type="token" /> </complexType>
<element
name="searchContinuation"
type="iris:searchContinuationType" />
<element name="searchContinuation" type="iris:searchContinuationType" />
<!-- ========================================= -->
<!-- -->
<!-- Bags -->
<!-- -->
<!-- ========================================= -->
<!-- ========================================= --> <!-- --> <!-- Bags --> <!-- --> <!-- ========================================= -->
<complexType
name="bagsType">
<sequence>
<element
name="bag"
minOccurs="1"
maxOccurs="unbounded">
<complexType>
<complexContent>
<extension
base="iris:bagType">
<attribute
use="required"
name="id"
type="ID" />
</extension>
</complexContent>
</complexType>
</element>
</sequence>
</complexType>
<complexType name="bagsType"> <sequence> <element name="bag" minOccurs="1" maxOccurs="unbounded"> <complexType> <complexContent> <extension base="iris:bagType"> <attribute use="required" name="id" type="ID" /> </extension> </complexContent> </complexType> </element> </sequence> </complexType>
<complexType
name="bagType">
<sequence>
<any
namespace="##any"
processContents="skip"
minOccurs="1"
maxOccurs="1" />
</sequence>
</complexType>
<!-- ========================================= -->
<!-- -->
<!-- Derived Results for use with all -->
<complexType name="bagType"> <sequence> <any namespace="##any" processContents="skip" minOccurs="1" maxOccurs="1" /> </sequence> </complexType> <!-- ========================================= --> <!-- --> <!-- Derived Results for use with all -->
Newton & Sanz Standards Track [Page 30] RFC 3981 IRIS-Core January 2005
Newton & Sanz Standards Track [Page 30] RFC 3981 IRIS-Core January 2005
<!-- registry types. -->
<!-- -->
<!-- ========================================= -->
<!-- registry types. --> <!-- --> <!-- ========================================= -->
<!-- -->
<!-- See Also -->
<!-- -->
<!-- --> <!-- See Also --> <!-- -->
<element
name="seeAlso"
type="iris:entityType" />
<element name="seeAlso" type="iris:entityType" />
<!-- -->
<!-- Service Identification -->
<!-- -->
<!-- --> <!-- Service Identification --> <!-- -->
<complexType
name="serviceIdentificationType">
<complexContent>
<extension
base="iris:resultType">
<sequence>
<element
name="authorities"
minOccurs="1"
maxOccurs="1">
<complexType>
<sequence>
<element
name="authority"
type="token"
minOccurs="1"
maxOccurs="unbounded" />
</sequence>
</complexType>
</element>
<element
name="operatorName"
type="string"
minOccurs="0"
maxOccurs="1" />
<element
name="eMail"
type="string"
minOccurs="0"
maxOccurs="unbounded" />
<element
name="phone"
<complexType name="serviceIdentificationType"> <complexContent> <extension base="iris:resultType"> <sequence> <element name="authorities" minOccurs="1" maxOccurs="1"> <complexType> <sequence> <element name="authority" type="token" minOccurs="1" maxOccurs="unbounded" /> </sequence> </complexType> </element> <element name="operatorName" type="string" minOccurs="0" maxOccurs="1" /> <element name="eMail" type="string" minOccurs="0" maxOccurs="unbounded" /> <element name="phone"
Newton & Sanz Standards Track [Page 31] RFC 3981 IRIS-Core January 2005
Newton & Sanz Standards Track [Page 31] RFC 3981 IRIS-Core January 2005
type="string"
minOccurs="0"
maxOccurs="unbounded" />
<element
ref="iris:seeAlso"
minOccurs="0"
maxOccurs="unbounded" />
</sequence>
</extension>
</complexContent>
</complexType>
type="string" minOccurs="0" maxOccurs="unbounded" /> <element ref="iris:seeAlso" minOccurs="0" maxOccurs="unbounded" /> </sequence> </extension> </complexContent> </complexType>
<element
name="serviceIdentification"
type="iris:serviceIdentificationType"
substitutionGroup="iris:result" />
<element name="serviceIdentification" type="iris:serviceIdentificationType" substitutionGroup="iris:result" />
<!-- -->
<!-- Limits -->
<!-- -->
<!-- --> <!-- Limits --> <!-- -->
<complexType
name="limitsType">
<complexContent>
<extension
base="iris:resultType">
<sequence>
<element
name="totalQueries"
minOccurs="0"
maxOccurs="1" >
<complexType>
<group
ref="iris:timeLimitsGroup"
minOccurs="1"
maxOccurs="4" />
</complexType>
</element>
<element
name="totalResults"
minOccurs="0"
maxOccurs="1" >
<complexType>
<group
ref="iris:timeLimitsGroup"
minOccurs="1"
maxOccurs="4" />
</complexType>
<complexType name="limitsType"> <complexContent> <extension base="iris:resultType"> <sequence> <element name="totalQueries" minOccurs="0" maxOccurs="1" > <complexType> <group ref="iris:timeLimitsGroup" minOccurs="1" maxOccurs="4" /> </complexType> </element> <element name="totalResults" minOccurs="0" maxOccurs="1" > <complexType> <group ref="iris:timeLimitsGroup" minOccurs="1" maxOccurs="4" /> </complexType>
Newton & Sanz Standards Track [Page 32] RFC 3981 IRIS-Core January 2005
Newton & Sanz Standards Track [Page 32] RFC 3981 IRIS-Core January 2005
</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"
</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"
Newton & Sanz Standards Track [Page 33] RFC 3981 IRIS-Core January 2005
Newton & Sanz Standards Track [Page 33] RFC 3981 IRIS-Core January 2005
substitutionGroup="iris:result" />
substitutionGroup="iris:result" />
<group
name="timeLimitsGroup">
<choice>
<element
name="perSecond"
type="nonNegativeInteger" />
<element
name="perMinute"
type="nonNegativeInteger" />
<element
name="perHour"
type="nonNegativeInteger" />
<element
name="perDay"
type="nonNegativeInteger" />
</choice>
</group>
<group name="timeLimitsGroup"> <choice> <element name="perSecond" type="nonNegativeInteger" /> <element name="perMinute" type="nonNegativeInteger" /> <element name="perHour" type="nonNegativeInteger" /> <element name="perDay" type="nonNegativeInteger" /> </choice> </group>
<!-- -->
<!-- Simple Entity -->
<!-- -->
<!-- --> <!-- Simple Entity --> <!-- -->
<complexType
name="simpleEntityType">
<complexContent>
<extension
base="iris:resultType">
<sequence>
<element
name="property"
minOccurs="1"
maxOccurs="unbounded">
<complexType>
<simpleContent>
<extension
base="string">
<attribute
name="name"
type="string"
use="required" />
<attribute
name="language"
type="language"
use="required" />
<attribute
name="uri"
<complexType name="simpleEntityType"> <complexContent> <extension base="iris:resultType"> <sequence> <element name="property" minOccurs="1" maxOccurs="unbounded"> <complexType> <simpleContent> <extension base="string"> <attribute name="name" type="string" use="required" /> <attribute name="language" type="language" use="required" /> <attribute name="uri"
Newton & Sanz Standards Track [Page 34] RFC 3981 IRIS-Core January 2005
Newton & Sanz Standards Track [Page 34] RFC 3981 IRIS-Core January 2005
type="anyURI" />
</extension>
</simpleContent>
</complexType>
</element>
</sequence>
</extension>
</complexContent>
</complexType>
type="anyURI" /> </extension> </simpleContent> </complexType> </element> </sequence> </extension> </complexContent> </complexType>
<element
name="simpleEntity"
type="iris:simpleEntityType"
substitutionGroup="iris:result" />
<element name="simpleEntity" type="iris:simpleEntityType" substitutionGroup="iris:result" />
<!-- ========================================= -->
<!-- -->
<!-- Derived Controls and Reactions -->
<!-- -->
<!-- ========================================= -->
<!-- ========================================= --> <!-- --> <!-- Derived Controls and Reactions --> <!-- --> <!-- ========================================= -->
<!-- -->
<!-- Only Check Permissions -->
<!-- -->
<!-- --> <!-- Only Check Permissions --> <!-- -->
<element
name="onlyCheckPermissions" >
<complexType />
</element>
<element name="onlyCheckPermissions" > <complexType /> </element>
<!-- -->
<!-- Standard Reaction -->
<!-- -->
<!-- --> <!-- Standard Reaction --> <!-- -->
<element
name="standardReaction" >
<complexType>
<choice>
<element
name="controlAccepted">
<complexType/>
</element>
<element
name="controlDenied">
<complexType/>
</element>
<element
name="controlDisabled">
<element name="standardReaction" > <complexType> <choice> <element name="controlAccepted"> <complexType/> </element> <element name="controlDenied"> <complexType/> </element> <element name="controlDisabled">
Newton & Sanz Standards Track [Page 35] RFC 3981 IRIS-Core January 2005
Newton & Sanz Standards Track [Page 35] RFC 3981 IRIS-Core January 2005
<complexType/>
</element>
<element
name="controlUnrecognized">
<complexType/>
</element>
</choice>
</complexType>
</element>
<complexType/> </element> <element name="controlUnrecognized"> <complexType/> </element> </choice> </complexType> </element>
<!-- ========================================= -->
<!-- -->
<!-- Serialization -->
<!-- -->
<!-- ========================================= -->
<!-- ========================================= --> <!-- --> <!-- Serialization --> <!-- --> <!-- ========================================= -->
<complexType
name="serializedReferralType">
<sequence>
<element name="source">
<complexType>
<attribute
name="authority"
use="required"
type="token" />
<attribute
name="resolution"
type="token" />
<attribute
name="registryType"
type="anyURI"
use="required" />
<attribute
name="entityClass"
type="token"
use="required" />
<attribute
name="entityName"
type="token"
use="required" />
</complexType>
</element>
<choice>
<element
ref="iris:searchContinuation" />
<element
ref="iris:entity" />
</choice>
<complexType name="serializedReferralType"> <sequence> <element name="source"> <complexType> <attribute name="authority" use="required" type="token" /> <attribute name="resolution" type="token" /> <attribute name="registryType" type="anyURI" use="required" /> <attribute name="entityClass" type="token" use="required" /> <attribute name="entityName" type="token" use="required" /> </complexType> </element> <choice> <element ref="iris:searchContinuation" /> <element ref="iris:entity" /> </choice>
Newton & Sanz Standards Track [Page 36] RFC 3981 IRIS-Core January 2005
Newton & Sanz Standards Track [Page 36] RFC 3981 IRIS-Core January 2005
</sequence>
</complexType>
</sequence> </complexType>
<element
name="serialization">
<complexType>
<choice
minOccurs="1"
maxOccurs="unbounded">
<element
ref="iris:result" />
<element
name="serializedReferral"
type="iris:serializedReferralType" />
</choice>
</complexType>
</element>
<element name="serialization"> <complexType> <choice minOccurs="1" maxOccurs="unbounded"> <element ref="iris:result" /> <element name="serializedReferral" type="iris:serializedReferralType" /> </choice> </complexType> </element>
</schema>
</schema>
Figure 8
Figure 8
7. The IRIS URI
7. The IRIS URI
The IRIS URI has a very rigid structure. All IRIS URIs have the same fields and look similar to users.
The IRIS URI has a very rigid structure. All IRIS URIs have the same fields and look similar to users.
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).
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).
7.1. URI Definition
7.1. URI Definition
An IRIS URI [6] has the following general syntax.
An IRIS URI [6] has the following general syntax.
iris:<registry>/<resolution>/<authority>/<class>/<name>
iris:<registry>/<resolution>/<authority>/<class>/<name>
The full ABNF [11] follows, with certain values included from RFC 2396 [6] and RFC 2732 [15].
The full ABNF [11] follows, with certain values included from RFC 2396 [6] and 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)
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)
Newton & Sanz Standards Track [Page 37] RFC 3981 IRIS-Core January 2005
Newton & Sanz Standards Track [Page 37] RFC 3981 IRIS-Core January 2005
entity-name = *(unreserved | escaped)
unreserved = // as specified by RFC2396
escaped = // as specified by RFC2396
entity-name = *(unreserved | escaped) unreserved = // as specified by RFC2396 escaped = // as specified by RFC2396
An IRIS URI MUST NOT be a relative URI. The resolution method, entity class, and entity name MUST be of the UTF-8 [12] character set encoded with "application/x-www-form-urlencoded", as specified by URL_ENC [14].
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].
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".
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".
When the resolution-method is not specified, the default is the direct resolution method described in Section 7.3.2.
When the resolution-method is not specified, the default is the direct resolution method described in Section 7.3.2.
7.2. Transport Specific Schemes
7.2. Transport Specific Schemes
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.
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.
A mapping between an application transport and IRIS MAY define a scheme name signifying its use with the semantics of the IRIS URI.
A mapping between an application transport and IRIS MAY define a scheme name signifying its use with the semantics of the IRIS URI.
The rules for determining which application transport to use are as follows:
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 If an application transport specific scheme name is present, the application transport it signifies SHOULD be used if possible.
o If a client has a preferred transport and the resolution process
allows for its use, the client MAY use that application transport.
o If a client has a preferred transport and the resolution process allows for its use, the client MAY use that application transport.
o Otherwise, the default application transport specified by IRIS-
BEEP [1] MUST be used.
o Otherwise, the default application transport specified by IRIS- BEEP [1] MUST be used.
7.3. URI Resolution
7.3. URI Resolution
7.3.1. Registry Dependent Resolution
7.3.1. Registry Dependent Resolution
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).
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).
Newton & Sanz Standards Track [Page 38] RFC 3981 IRIS-Core January 2005
Newton & Sanz Standards Track [Page 38] RFC 3981 IRIS-Core January 2005
Alternate resolution methods MAY be specified by registry types. The identifiers for these methods MUST conform to the ABNF in Section 7.1.
Alternate resolution methods MAY be specified by registry types. The identifiers for these methods MUST conform to the ABNF in Section 7.1.
7.3.2. Direct Resolution
7.3.2. Direct Resolution
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.
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.
The rules for resolution are as follows:
The rules for resolution are as follows:
o If the authority component is a domain name accompanied by a port
number as specified by RFC 2396, the domain name is converted to
an IP address via an A or AAAA record to the DNS.
o If the authority component is a domain name accompanied by a port number as specified by RFC 2396, the domain name is converted to an IP address via an A or AAAA record to the DNS.
o 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 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 If the authority component is an IP address, then the DNS is not
queried, and the IP address is used directly. If the port number
is present, it is used directly; otherwise, the port number used
is the well-known port of the transport used according to Section
7.2.
o 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.
The use of an IPv6 address in the authority component MUST conform to RFC 2732 [15].
The use of an IPv6 address in the authority component MUST conform to RFC 2732 [15].
7.3.3. Transport and Service Location
7.3.3. Transport and Service Location
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.
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.
Newton & Sanz Standards Track [Page 39] RFC 3981 IRIS-Core January 2005
Newton & Sanz Standards Track [Page 39] RFC 3981 IRIS-Core January 2005
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] 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.
See Appendix A for sample uses of S-NAPTR.
See Appendix A for sample uses of S-NAPTR.
7.4. IRIS URI Examples
7.4. IRIS URI Examples
Here are some examples of IRIS URIs and their meaning:
Here are some examples of IRIS URIs and their meaning:
o iris:dreg1//example.com/domain/example.com
* Finds a server authoritative for "example.com" according to the
rules of direct resolution (Section 7.3.2).
* The server is asked for "example.com" in the "domain" index, or
entity class, of the "dreg1" registry.
o iris:dreg1//example.com/domain/example.com * Finds a server authoritative for "example.com" according to the rules of direct resolution (Section 7.3.2). * The server is asked for "example.com" in the "domain" index, or entity class, of the "dreg1" registry.
o iris:dreg1//example.com
* Finds a server authoritative for "example.com" according to the
rules of direct resolution (Section 7.3.2).
* The server is asked for "id" in the "iris" index, or entity
class, of the "dreg1" registry.
o iris:dreg1//example.com * Finds a server authoritative for "example.com" according to the rules of direct resolution (Section 7.3.2). * The server is asked for "id" in the "iris" index, or entity class, of the "dreg1" registry.
o iris:dreg1//com/domain/example.com
* Finds a server authoritative for "com" according to the rules
of direct-resolution (Section 7.3.2).
* The server is asked for "example.com" in the "domain" index, or
entity class, of the "dreg1" registry.
o iris:dreg1//com/domain/example.com * Finds a server authoritative for "com" according to the rules of direct-resolution (Section 7.3.2). * The server is asked for "example.com" in the "domain" index, or entity class, of the "dreg1" registry.
o iris:dreg1//192.0.2.1:44/domain/example.com
* Following the rules of direct-resolution (Section 7.3.2), the
server at IP address 192.0.2.1 on port 44 is queried by using
BEEP.
* The server is asked for "example.com" in the "domain" index, or
entity class, of the "dreg1" registry.
o iris:dreg1//192.0.2.1:44/domain/example.com * Following the rules of direct-resolution (Section 7.3.2), the server at IP address 192.0.2.1 on port 44 is queried by using BEEP. * The server is asked for "example.com" in the "domain" index, or entity class, of the "dreg1" registry.
o iris.lwz:dreg1//192.0.2.1:44/domain/example.com
* Following the rules of direct-resolution (Section 7.3.2), the
server at IP address 192.0.2.1 on port 44 is queried by using a
lightweight application transport.
* The server is asked for "example.com" in the "domain" index, or
entity class, of the "dreg1" registry.
o iris.lwz:dreg1//192.0.2.1:44/domain/example.com * 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.
Newton & Sanz Standards Track [Page 40] RFC 3981 IRIS-Core January 2005
Newton & Sanz Standards Track [Page 40] RFC 3981 IRIS-Core January 2005
o iris.beep:dreg1//com/domain/example.com
* Finds a server authoritative for "com" according to the rules
of direct-resolution (Section 7.3.2).
* Uses the BEEP application transport.
* The server is asked for "example.com" in the "domain" index, or
entity class, of the "dreg1" registry.
o iris.beep:dreg1//com/domain/example.com * 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:dreg1/bottom/example.com/domain/example.com
* Finds a server authoritative for "example.com" according to the
rules of the resolution method 'bottom' as defined by the
registry type urn:ietf:params:xml:ns:dreg1.
* The application transport used is determined by the 'bottom'
resolution method.
* The server is asked for "example.com" in the "domain" index, or
entity class, of the "dreg1" registry.
o iris:dreg1/bottom/example.com/domain/example.com * Finds a server authoritative for "example.com" according to the rules of the resolution method 'bottom' as defined by the registry type urn:ietf:params:xml:ns:dreg1. * The application transport used is determined by the 'bottom' resolution method. * The server is asked for "example.com" in the "domain" index, or entity class, of the "dreg1" registry.
o iris.beep:dreg1/bottom/example.com/domain/example.com
* Finds a server authoritative for "example.com" according to the
rules of the resolution method 'bottom' as defined by the
registry type urn:ietf:params:xml:ns:dreg1.
* Uses the BEEP application transport.
* The server is asked for "example.com" in the "domain" index, or
entity class, of the "dreg1" registry.
o iris.beep:dreg1/bottom/example.com/domain/example.com * 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.
8. Checklists
8. Checklists
8.1. Registry Definition Checklist
8.1. Registry Definition Checklist
Specifications of registry types MUST include the following explicit definitions:
登録タイプの仕様は以下の明白な定義を含まなければなりません:
o Formal XML syntax deriving from the IRIS XML.
o IRIS XMLからの正式なXML構文派生。
o An identifying registry URN.
o 特定登録URN。
o Any registry specific resolution methods.
o どんな登録の特定の解決メソッド。
o A registration of the abbreviated registry URN as an application
service label for compliance with S-NAPTR [10]. Note that this is
a different IANA registry than the registry type URN IANA
registry.
o S-NAPTR[10]への承諾のためのアプリケーション・サービスラベルとしての簡略化された登録URNの登録。 これが登録タイプURN IANA登録より異なったIANA登録であることに注意してください。
o A list of well-known entity classes.
o よく知られる実体のリストは属します。
o A statement regarding the case sensitivity of the names in each
entity class.
o それぞれの実体のクラスにおける、名前のケース感度に関する声明。
Newton & Sanz Standards Track [Page 41] RFC 3981 IRIS-Core January 2005
ニュートンとサンスStandardsは虹彩コア2005年1月にRFC3981を追跡します[41ページ]。
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.
o 輸送に特定のURI体系名。
o An application protocol label for compliance with S-NAPTR [10].
See Section 7.3.3. Note that although this is a different IANA
registry than the URI scheme name IANA registry, it is RECOMMENDED
that they be the same string of characters.
o S-NAPTR[10]への承諾のためのアプリケーション・プロトコルラベル。 セクション7.3.3を見てください。 これがURI体系名前IANA登録より異なったIANA登録ですが、それらがキャラクタの同じストリングであることがRECOMMENDEDであることに注意してください。
o The set of allowable character set encodings for the exchange of
XML (see Section 9).
o XML(セクション9を見る)の交換のための許容できる文字集合encodingsのセット。
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]encodingsの両方を認識するのが強いられます。 XMLは、属性が<xml>宣言で「コード化」であることによって、他の文字符号化を特定して、使用するためにメカニズムに備えます。 この属性かバイト・オーダー・マーク(BOM)の欠如はUTF-8[13]コード化のデフォルトを示します。 したがって、互換性理由とRFC2277[16]あたりUTF-8[13]の使用はIRISとRECOMMENDEDです。
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.
アプリケーショントランスポート層は、クライアントとサーバの両方に解釈されるために文字集合encodingsの一般的なセットを定義しなければなりません。
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.
国際化しているストリングのローカライズはクライアントからの追加情報を必要とするかもしれません。 実体定義SHOULDはローカライズプロセスでクライアントを支援するためにXML_サウスダコタ[4]によって定義された「言語」タイプを使用します。 セクション4.3を見てください。.7 .3 例のために。
Newton & Sanz Standards Track [Page 42] RFC 3981 IRIS-Core January 2005
ニュートンとサンスStandardsは虹彩コア2005年1月にRFC3981を追跡します[42ページ]。
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_URN[9]で指定された提案されたXML名前空間と図式登録を使用します。 それに従って、以下のレジスト情報をIANAに提供します:
o URN/URI:
* urn:ietf:params:xml:ns:iris1
o Contact:
* Andrew Newton <andy@hxr.us>
* Marcos Sanz <sanz@denic.de>
o XML:
* The XML Schema specified in Section 6
o つぼ/ユリ: * つぼ:ietf:params: xml:ナノ秒:iris1o Contact: * アンドリュー Newton <andy@hxr.us 、gt;、*マルコス Sanz <sanz@denic.de 、gt;、o XML: * セクション6で指定されたXML Schema
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登録結果は別の登録サービスに対してクライアント質問操作をもたらす実体ルックアップと検索続刊を含むかもしれません。 クライアントSHOULD NOTは、その後の実体ルックアップと検索続刊を行うのに反射攻撃を条件として認証資格証明書とメカニズムを使用します。
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.サンス、「インターネット登録情報サービス(虹彩)を広げることができるブロックの上使用して、プロトコルを交換してください(鳴ってください)」、RFC3983、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インチ、W3C XML1998年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 Namespaces)は1999年1月、<http://www.w3.org/TR/1999/REC-xmlに-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 Schema2000年10月、<http://www.w3.org/TR/2001/REC- xmlschema-2-20010502/>。
Newton & Sanz Standards Track [Page 43] RFC 3981 IRIS-Core January 2005
ニュートンとサンスStandardsは虹彩コア2005年1月にRFC3981を追跡します[43ページ]。
[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 Schema2000年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、「Uniform Resource Identifier(URI):」 「ジェネリック構文」、RFC2396、1998年8月。
[7] Moats, R., "URN Syntax", RFC 2141, May 1997.
[7]堀(R.、「つぼの構文」、RFC2141)は1997がそうするかもしれません。
[8] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[8] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[9] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, January
2004.
[9] 食事、M.、「IETF XML登録」、BCP81、RFC3688、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.ニュートン、「SRV RRsを使用するドメインベースのアプリケーション・サービス位置とダイナミックな委譲発見は(DDDS)を修理します」、RFC3958、2005年1月。
[11] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 2234, November 1997.
[11] クロッカー、D.、およびP.Overell、「構文仕様のための増大しているBNF:」 "ABNF"、1997年11月のRFC2234。
[12] The Unicode Consortium, "The Unicode Standard, Version 3", ISBN
0-201-61633-5, 2000, <The Unicode Standard, Version 3>.
[12] ユニコード共同体、「ユニコード規格、バージョン3インチ、ISBN0-201-61633-5、2000、<、ユニコード規格、バージョン3>、」
[13] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD
63, RFC 3629, November 2003.
[13]Yergeau、F.、「UTF-8、ISO10646インチ、STD63、RFC3629、11月2003日の変換形式
[14] Connolly, D. and L. Masinter, "The 'text/html' Media Type", RFC
2854, June 2000.
[14] コノリーとD.とL.Masinter、htmlテキスト/'メディアタイプ」、RFC2854、2000年6月。
[15] Hinden, R., Carpenter, B., and L. Masinter, "Format for Literal
IPv6 Addresses in URL's", RFC 2732, December 1999.
[15]Hinden、R.、大工、B.、およびL.Masinter、「URLの文字通りのIPv6アドレスのための形式」、RFC2732、1999年12月。
[16] Alvestrand, H., "IETF Policy on Character Sets and Languages",
BCP 18, RFC 2277, January 1998.
[16]Alvestrand、H.、「文字コードと言語に関するIETF方針」、BCP18、RFC2277、1998年1月。
Newton & Sanz Standards Track [Page 44] RFC 3981 IRIS-Core January 2005
ニュートンとサンスStandardsは虹彩コア2005年1月にRFC3981を追跡します[44ページ]。
12.2. Informative References
12.2. 有益な参照
[17] Newton, A., "Cross Registry Internet Service Protocol (CRISP)
Requirements", RFC 3707, February 2004.
[17] ニュートン、A.、「交差している登録インターネットのサービスプロトコル(はっきりする)の要件」、RFC3707、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.サンス、「虹彩:」 「インターネット登録情報サービス(虹彩)のためのドメイン登録(かす)タイプ」、RFC3982、2005年1月。
[19] Daigle, L., "WHOIS Protocol Specification", RFC 3912, September
2004.
[19]Daigle、L.、「WHOISプロトコル仕様」、RFC3912、2004年9月。
[20] Rose, M., "The Blocks Extensible Exchange Protocol Core", RFC
3080, March 2001.
[20] ローズ、M.、「ブロックの広げることができる交換プロトコルコア」、RFC3080、2001年3月。
URIs
URI
[21] <http://www.iana.org/assignments/character-sets>
[21] <http://www.iana.org/課題/文字集合>。
Newton & Sanz Standards Track [Page 45] RFC 3981 IRIS-Core January 2005
ニュートンとサンスStandardsは虹彩コア2005年1月にRFC3981を追跡します[45ページ]。
Appendix A. S-NAPTR and IRIS Uses
付録A.S-NAPTRと虹彩用途
A.1. Example of S-NAPTR with IRIS
A.1。 虹彩がある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:
このセクションはIRISによるS-NAPTR[10]使用に関する例を示しています。 この例には、2つの登録タイプがあります: レガとREGB。 また、アプリケーションが輸送する2IRISがあります: 虹彩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を実行しながらサーバのセットからレガを実行するサーバのセットを分割できる手段。 これは言うことになっていて、オペレータはREGBのためのデータを供給しながらサーバのセットからレガのためのデータに役立つサーバのセットと分かれることができます。
2. A means by which an operator can distinguish the set of servers
running iris-a from the set of servers running iris-b. This is to
say, the operator is able to split out the set of servers running
protocol iris-a serving REGA and REGB data from the set of servers
running protocol iris-b serving REGA and REGB data.
2. オペレータが虹彩bを実行しながらサーバのセットからの虹彩aを実行するサーバのセットを区別できる手段。 これは言うことになっていて、オペレータはサーバの実行しているプロトコル虹彩a給仕のレガとREGBのセットからプロトコル虹彩b給仕レガを実行するサーバと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. オペレータが別のオペレータに委任するために操作するセットした上のサーバのサーバのどのセットを指定できる手段。
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。 ;; オーダーpref旗が交換に関してIN NAPTR100 10を修理する、「「「レガ: 虹彩A:虹彩b」、「「NAPTR100 10におけるrega.example.com、「「「REGB: 虹彩a: 虹彩b」、「"regb.example.com"
To implement the second feature, the operator then adds the following in their DNS zone:
次に、2番目の特徴を実装するために、オペレータはそれらのDNSゾーンで以下を加えます:
rega.example.com. ;; order pref flags service re replacement IN NAPTR 100 10 "s" "REGA:iris-a" "" _iris-a._udp.example.com regb.example.com. IN NAPTR 100 10 "s" "REGA:iris-b" "" _iris-b._tcp.example.com
rega.example.com。 ;; オーダーpref旗が交換IN NAPTR100 10「s」に関して「レガ: 虹彩a」を修理する、「「_虹彩a._udp.example.com regb.example.com。」 NAPTR100 10、「s、」 「レガ: 虹彩b」、「「_虹彩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.
_虹彩a._udp.example.com。 ;; pref重さのポート目標IN SRV10 0 34の大きいa.のexample.com。 IN SRV20 0の34の小さいa.example.com。
Newton & Sanz Standards Track [Page 46] RFC 3981 IRIS-Core January 2005
ニュートンとサンスStandardsは虹彩コア2005年1月にRFC3981を追跡します[46ページ]。
_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.
_虹彩b._tcp.example.com。 ;; pref重さのポート目標IN SRV10 0 34の大きいb.のexample.com。 IN SRV20 0の34の小さい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サービスを代表として派遣している間、レガのサービスを操作すると決めるかもしれません。 ここに、それがどう完了しているかがあります:
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。 ;; オーダーpref旗が交換に関してIN NAPTR100 10を修理する、「「「レガ: 虹彩A:虹彩b」、「「NAPTR100 10におけるrega.example.com、「「「REGB: 虹彩a: 虹彩b」、「"somebodyelse.com"
Or the operator may decide to operate REGB services under the iris-a protocol/transport while delegating the REGB services under the iris-b protocol/transport to somebody else.
または、オペレータは、REGBサービスを他の誰かへ虹彩bプロトコル/輸送で代表として派遣している間、虹彩aプロトコル/輸送で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。 ;; オーダーpref旗が交換に関してIN NAPTR100 10を修理する、「「「REGB: 虹彩A:虹彩b」、「「NAPTR100 10におけるregb.example.com、「s、」 「REGB: 虹彩a」、「「_NAPTR100 10における虹彩a._udp.example.com、「s、」 「REGB: 虹彩b」、「「_虹彩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.
_虹彩a._udp.example.com。 ;; pref重さのポート目標IN SRV10 0 34の大きいa.のexample.com。 IN SRV20 0の34の小さい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].
Appendix 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: 虹彩ビープ音」
Newton & Sanz Standards Track [Page 47] RFC 3981 IRIS-Core January 2005
ニュートンとサンスStandardsは虹彩コア2005年1月にRFC3981を追跡します[47ページ]。
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アプリケーション・プロトコルラベルはRFC954[19]について言及します。
Appendix B. IRIS Design Philosophy
付録B.虹彩設計理念
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 それはすべての登録によって使用される、それらのschemasを指定する基本的なスキーマ言語を指定します。
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
o それはどんなタイプの木を指定などなどの登録でもデータのセットの間の少しの関係も課しません。 多くのタイプに関するインターネット資料があります、そして、それらは皆、同じスタイルを共有しません。
Newton & Sanz Standards Track [Page 48] RFC 3981 IRIS-Core January 2005
ニュートンとサンスStandardsは虹彩コア2005年1月にRFC3981を追跡します[48ページ]。
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.
それらの含まれたセットのデータとの関係。 それが自然な発作でないときに、しばしば一般的な関係の負担は利益ではなく、関心です。
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である、それは一般的に「ウェブブラウザ」と呼ばれます)。
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.
サーバ性能のための別の考慮は必要なデータ関係の不足です。 データのセットに異なった関係がしばしばあるので、フリーサイズのアプローチはすべてのタイプの登録をよく与えません。 さらに、公共に面しているサービスは、完全なデータ・ストアをネイティブの形式から人工の関係を実施する形式に変えることによって合理的に満たすことができないサービスレベル必要条件を持っている傾向があります。
Newton & Sanz Standards Track [Page 49] RFC 3981 IRIS-Core January 2005
ニュートンとサンスStandardsは虹彩コア2005年1月にRFC3981を追跡します[49ページ]。
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は1セットの標準の技術的な層に造られます。 これで、サービスオペレータは、彼らの特定の環境の需要を満たすためにコンポーネントを切り換えることができます。
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
最終的に、また、IRISが登録にデータの関係に仮定を全くしないで、また要件を全く置かないので、これはタイプが複数の権威領域の向こう側に広げる同じ登録に関するデータに達します。 IRISが要件を全く作らないこの手段
Newton & Sanz Standards Track [Page 50] RFC 3981 IRIS-Core January 2005
ニュートンとサンスStandardsは虹彩コア2005年1月にRFC3981を追跡します[50ページ]。
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.
実体参照か検索続刊の範囲。 範囲は登録タイプが必要とするものと登録タイプがサービスオペレータに許容するもので決定します。
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、URNs、および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.ニュートンベリサインInc.21345屋根の頂円の英貨、ヴァージニア20166米国
Phone: +1 703 948 3382 EMail: anewton@verisignlabs.com; andy@hxr.us URI: http://www.verisignlabs.com/
以下に電話をしてください。 +1 3382年の703 948メール: anewton@verisignlabs.com; andy@hxr.us ユリ: http://www.verisignlabs.com/
Marcos Sanz DENIC eG Wiesenhuettenplatz 26 D-60329 Frankfurt Germany
マルコスサンスDENIC eG Wiesenhuettenplatz26D-60329フランクフルトドイツ
EMail: sanz@denic.de URI: http://www.denic.de/
メール: sanz@denic.de ユリ: http://www.denic.de/
Newton & Sanz Standards Track [Page 51] RFC 3981 IRIS-Core January 2005
ニュートンとサンスStandardsは虹彩コア2005年1月にRFC3981を追跡します[51ページ]。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2005).
Copyright(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.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
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.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
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はどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でIETF Documentsの権利に関するIETFの手順に関する情報を見つけることができます。
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倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
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機能のための基金は現在、インターネット協会によって提供されます。
Newton & Sanz Standards Track [Page 52]
ニュートンとサンス標準化過程[52ページ]
一覧
スポンサーリンク
