RFC4698 日本語訳

4698 IRIS: An Address Registry (areg) Type for the Internet RegistryInformation Service. E. Gunduz, A. Newton, S. Kerr. October 2006. (Format: TXT=89932 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文

Network Working Group                                          E. Gunduz
Request for Comments: 4698                                      RIPE NCC
Category: Standards Track                                      A. Newton
                                                          VeriSign, Inc.
                                                                 S. Kerr
                                                                RIPE NCC
                                                            October 2006

Gunduzがコメントのために要求するワーキンググループE.をネットワークでつないでください: 4698年の熟しているNCCカテゴリ: NCC2006年10月に熟している標準化過程のA.ニュートン・ベリサインのInc.S.カー

                 IRIS: An Address Registry (areg) Type
             for the Internet Registry Information Service

虹彩: インターネット登録情報サービスのためのアドレス登録(areg)タイプ

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

Abstract

要約

   This document describes an IRIS registry schema for IP address and
   Autonomous System Number information.  The schema extends the
   necessary query and result operations of IRIS to provide the
   functional information service needs for syntaxes and results used by
   Internet Protocol address registries.

このドキュメントはIPアドレスとAutonomous System Number情報のためにIRIS登録図式について説明します。図式は、サービスが構文に必要とする機能情報とIPアドレス登録によって使用される結果を提供するためにIRISの必要な質問と結果操作を広げています。

Gunduz, et al.              Standards Track                     [Page 1]

RFC 4698               IRIS Address Registry Type           October 2006

Gunduz、他規格は虹彩アドレス登録タイプ2006年10月にRFC4698を追跡します[1ページ]。

Table of Contents

   1. Introduction ....................................................3
   2. Document Terminology ............................................3
   3. Schema Description ..............................................3
      3.1. Query Derivatives ..........................................4
           3.1.1. <findContacts> Query ................................4
           3.1.2. <findOrganizations> .................................4
           3.1.3. <findAutonomousSystemsByName> and
                  <findNetworksByName> ................................5
           3.1.4. <findNetworksByAddress> .............................5
           3.1.5. <findNetworksByHandle> ..............................6
           3.1.6. <findASByNumber> ....................................6
           3.1.7. <findByContact> .....................................7
           3.1.8. <findNetworksByNameServer> ..........................7
           3.1.9. Contact Search Group ................................8
           3.1.10. Common Search Group ................................8
           3.1.11. Match Parameters ...................................8
      3.2. Result Derivatives .........................................9
           3.2.1. <ipv4Network> and <ipv6Network> Results .............9
           3.2.2. <autonomousSystem> Result ..........................10
           3.2.3. <contact> Result ...................................11
           3.2.4. <organization> Result ..............................12
           3.2.5. Contact References .................................12
           3.2.6. Common Result Child Elements .......................13
      3.3. Support for <iris:lookupEntity> ...........................13
   4. Terminology for Nesting of Networks ............................14
   5. Formal XML Syntax ..............................................18
   6. BEEP Transport Compliance ......................................31
      6.1. Message Pattern ...........................................31
      6.2. Server Authentication .....................................31
   7. URI Resolution .................................................31
      7.1. Application Service Label .................................31
      7.2. Operational Considerations ................................31
      7.3. Top-Down Resolution .......................................31
   8. Internationalization Considerations ............................32
   9. IANA Considerations ............................................32
   10. Security Considerations .......................................32
   11. References ....................................................33
      11.1. Normative References .....................................33
      11.2. Informative References ...................................33
   Appendix A. Privacy Considerations ................................34
   Appendix B. Example Requests and Responses ........................34
      B.1. Example 1 .................................................34
      B.2. Example 2 .................................................36
   Appendix C. Specificity Examples ..................................39
   Appendix D. Contributors ..........................................46
   Appendix E. Acknowledgements ......................................46

1. 序論…3 2. 用語を記録してください…3 3. 図式記述…3 3.1. 派生物について質問してください…4 3.1.1. <findContacts>質問…4 3.1.2. <findOrganizations>…4 3.1.3. <findAutonomousSystemsByName>と<findNetworksByName>…5 3.1.4. <findNetworksByAddress>…5 3.1.5. <findNetworksByHandle>…6 3.1.6. <findASByNumber>…6 3.1.7. <findByContact>…7 3.1.8. <findNetworksByNameServer>…7 3.1.9. 調査班に連絡してください…8 3.1.10. 一般的な調査班…8 3.1.11. パラメタを合わせてください…8 3.2. 結果派生物…9 3.2.1. <ipv4Network>と<ipv6Network>結果…9 3.2.2. <autonomousSystem>結果…10 3.2.3. <接触>結果…11 3.2.4. <組織>は結果として生じます…12 3.2.5. 参照に連絡してください…12 3.2.6. 一般的な結果子供Elements…13 3.3. <には、虹彩: lookupEntityが>であるとサポートしてください…13 4. ネットワークの巣篭もりのための用語…14 5. 正式なXML構文…18 6. 輸送コンプライアンスを鳴らしてください…31 6.1. メッセージパターン…31 6.2. サーバー証明…31 7. URI解決…31 7.1. アプリケーション・サービスラベル…31 7.2. 操作上の問題…31 7.3. トップダウン解決…31 8. 国際化問題…32 9. IANA問題…32 10. セキュリティ問題…32 11. 参照…33 11.1. 標準の参照…33 11.2. 有益な参照…33 付録A.プライバシー問題…34の付録B.例の要求と応答…34 B.1。例1…34 B.2。例2…36 付録C.特異性の例…39 付録D.貢献者…46 付録E.承認…46

Gunduz, et al.              Standards Track                     [Page 2]

RFC 4698               IRIS Address Registry Type           October 2006

Gunduz、他規格は虹彩アドレス登録タイプ2006年10月にRFC4698を追跡します[2ページ]。

1.  Introduction

1. 序論

   An Internet address registry stores information about:

インターネット・アドレス登録は以下に関して情報を保存します。

   o  address ranges

o アドレスは及びます。

   o  autonomous system number ranges

o 自律システム番号は及びます。

   o  associated contacts and organizations

o 関連接触と組織

   o  name servers

o ネームサーバ

   This information is interrelated, and Internet address registries
   store this information and the information's interrelationships in a
   manner befitting the needs of each Internet address registry and its
   constituents.  This document specifies a method for accessing and
   retrieving this information in a common XML format.

この情報は相関的です、そして、インターネット・アドレス登録はそれぞれのインターネット・アドレス登録とその成分の必要性に適する方法でこの情報と情報の相互関係を保存します。このドキュメントは一般的なXML形式でこの情報にアクセスして、検索するためのメソッドを指定します。

   This document describes an IRIS namespace for Internet address
   registries using an XML Schema [8] derived from and using the IRIS
   [2] schema.  This schema and registry type are provided to
   demonstrate the extensibility of the IRIS framework beyond the use of
   domains, a criteria defined in CRISP [4].

このドキュメントは、[8] IRIS[2]図式を引き出されて、使用して、XML Schemaを使用することでIRIS名前空間についてインターネット・アドレス登録に説明します。ドメイン(CRISP[4]で定義された評価基準)の使用を超えてIRISフレームワークの伸展性を示すためにこの図式と登録タイプを提供します。

   The schema given is this document is specified using the Extensible
   Markup Language (XML) 1.0 as described in XML [5], XML Schema
   notation as described in XML_SD [7] and XML_SS [8], and XML
   Namespaces as described in XML_NS [6].

与えられた図式はこのドキュメントがXML[5](XML_サウスダコタ[7]、XML_SS[8]、およびXML_NS[6]で説明されるXML Namespacesで説明されるXML Schema記法)で説明されるようにExtensible Markup Language(XML)1.0を使用することで指定されるということです。

   Examples of client/server XML exchanges with this registry type are
   available in Appendix B.

この登録タイプに従ったクライアント/サーバXML交換の例はAppendix Bで利用可能です。

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 RFC 2119 [1].

キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはRFC2119[1]で説明されるように本書では解釈されることであるべきですか?

3.  Schema Description

3. スキーマ記述

   IRIS requires the derivation of both query and result elements by a
   registry schema.  Descriptions for these follow.

IRISは登録図式で質問と結果要素の両方の派生を必要とします。これらのための記述は続きます。

   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 [1] to describe the specification outside

このセクションの中に含まれた記述はプロトコルの中にデータの交換とのXML要素、属性、および彼らの関係を示します。また、これらの記述は正式なXML構文の範囲の外に仕様を保管しています。したがって、このセクションはRFC2119[1]によって定義された、外で仕様を説明した用語を使用するでしょう。

Gunduz, et al.              Standards Track                     [Page 3]

RFC 4698               IRIS Address Registry Type           October 2006

Gunduz、他規格は虹彩アドレス登録タイプ2006年10月にRFC4698を追跡します[3ページ]。

   the scope of the formal XML syntax.  While reading this section,
   please reference Section 5 for needed details on the formal XML
   syntax.

正式なXML構文の範囲。このセクションを読んでいる間、正式なXML構文に関する必要な詳細のためにセクション5に参照をつけてください。

3.1.  Query Derivatives

3.1. 質問派生物

3.1.1.  <findContacts> Query

3.1.1. <findContacts>質問

   <findContacts> searches for contacts given search constraints.

検索規制を考えて、<findContacts>は接触を捜し求めます。

   The allowable search fields are handled by one of the elements in the
   "contactSearchGroup" (see Section 3.1.9) or the element
   <organizationId>.  The <organizationId> element constrains the query
   based on the organization ID (handle) associated with contacts.  This
   element is an "exactMatchParameter" (see Section 3.1.11).

許容できる検索分野は"contactSearchGroup"(セクション3.1.9を見る)か要素<organizationId>の要素の1つによって扱われます。 <organizationId>要素はID(扱う)が接触に関連づけた組織に基づく質問を抑制します。この要素は"exactMatchParameter"(セクション3.1.11を見る)です。

   This query also provides optional <language> elements containing
   language tags.  Clients MAY use these elements to give a hint about
   the natural language(s) of the affected element.  Servers MAY use
   this information in processing the query, such as tailoring
   normalization routines to aid in more effective searches.

また、この質問は言語タグを含む任意の<言語>要素を提供します。クライアントは、影響を受ける要素の自然言語に関してちょっとほのめかすのにこれらの要素を使用するかもしれません。サーバは、より効果的な検索で支援するために正常化ルーチンを合わせなどなどの質問を処理する際にこの情報を使用するかもしれません。

   The client SHOULD pass the names unchanged to the server, and the
   implementation of the server decides if the search is case sensitive
   or not.

クライアントSHOULDはサーバに変わりのない名前を通過します、そして、サーバの実装は検索が大文字と小文字を区別しているかどうか決めます。

3.1.2.  <findOrganizations>

3.1.2. <findOrganizations>。

   <findOrganizations> searches for organizations given search
   constraints.

検索規制を考えて、<findOrganizations>は組織を捜し求めます。

   The allowable search fields are handled by one of the elements in the
   "commonSearchGroup" (see Section 3.1.10) or the element
   <organizationName>.  This element is an
   "exactOrPartialMatchParameter" (see Section 3.1.11).

許容できる検索分野は"commonSearchGroup"(セクション3.1.10を見る)か要素<organizationName>の要素の1つによって扱われます。この要素は"exactOrPartialMatchParameter"(セクション3.1.11を見る)です。

   This query also provides optional <language> elements containing
   language tags.  Clients MAY use these elements to give a hint about
   the natural language(s) of the affected element.  Servers MAY use
   this information in processing the query, such as tailoring
   normalization routines to aid in more effective searches.

   The client SHOULD pass the names unchanged to the server, and the
   implementation of the server decides if the search is case sensitive
   or not.

クライアントSHOULDはサーバに変わりのない名前を通過します、そして、サーバの実装は検索が大文字と小文字を区別しているかどうか決めます。

Gunduz, et al.              Standards Track                     [Page 4]

RFC 4698               IRIS Address Registry Type           October 2006

Gunduz、他規格は虹彩アドレス登録タイプ2006年10月にRFC4698を追跡します[4ページ]。

3.1.3.  <findAutonomousSystemsByName> and <findNetworksByName>

3.1.3. <findAutonomousSystemsByName>と<findNetworksByName>。

   The <findAutonomousSystemsByName> and <findNetworksByName> elements
   allow searches by name of autonomous systems and networks,
   respectively.  Both have the same format.

<findAutonomousSystemsByName>と<findNetworksByName>要素はそれぞれ自律システムとネットワークの名前の検索を許します。両方には、同じ形式があります。

   The child element <name> is an "exactOrPartialMatchParameter" (see
   Section 3.1.11).

>という子供要素<名は"exactOrPartialMatchParameter"(セクション3.1.11を見る)です。

   This query also provides optional <language> elements containing
   language tags.  Clients MAY use these elements to give a hint about
   the natural language(s) of the affected element.  Servers MAY use
   this information in processing the query, such as tailoring
   normalization routines to aid in more effective searches.

   The client SHOULD pass the names unchanged to the server, and the
   implementation of the server decides if the search is case sensitive
   or not.

クライアントSHOULDはサーバに変わりのない名前を通過します、そして、サーバの実装は検索が大文字と小文字を区別しているかどうか決めます。

3.1.4.  <findNetworksByAddress>

3.1.4. <findNetworksByAddress>。

   The <findNetworksByAddress> element is a query for a network given a
   related IP address or IP address range.  It has the following child
   elements:

関連するIPアドレスかIPアドレスの範囲を考えて、<findNetworksByAddress>要素はネットワークのための質問です。それには、以下の子供要素があります:

   o  <ipv4Address> - has a child <start> element containing the
      starting IPv4 address of the network and an optional child of
      <end> containing the ending IPv4 address of the network.  Clients
      MUST convert any short-form notation to the fully-qualified
      notation.

o <ipv4Address>--IPv4が扱うネットワークの結末を含むネットワークの始めのIPv4アドレスと<終わりの>の任意の子供を含む子供<スタート>要素を持っています。クライアントはどんな縮約形記法も完全に適切な記法に変換しなければなりません。

   o  <ipv6Address> - same as <ipv4Address>, but the child addresses
      contain IPv6 addresses.  Clients MUST convert any short-form
      notation to the fully-qualified notation.

o <ipv6Address>--<ipv4Address>と同じであることで、子供アドレスだけがIPv6アドレスを含んでいます。クライアントはどんな縮約形記法も完全に適切な記法に変換しなければなりません。

   o  <specificity> - determines the network specificity for the search
      (see Section 4).  Valid values are "exact-match", "all-less-
      specific", "one-level-less-specific", "all-more-specific", and
      "one-level-more-specific".  This element may have the optional
      attribute 'allowEquivalences'.  When it is set to "true", the
      result set should include networks with equivalent starting and
      ending addresses.  The default value for 'allowEquivalences' is
      "false".

o <の特異性>--検索(セクション4を見る)のためにネットワークの特異性を決定します。有効値は、「完全な一致」と、「よりオール少ない詳細」と、「あるレベルなしの詳細」と、「よりオール特有」、そして、「もうひとつのレベルの詳細」です。この要素には、任意の属性'allowEquivalences'があるかもしれません。それが「本当に」設定されるとき、結果セットは同等な始めと終了アドレスがあるネットワークを含むべきです。 'allowEquivalences'のためのデフォルト値は「誤っています」。

   The results from this query MUST be either <ipv4Network> or
   <ipv6Network> results.  More than one network result MAY be returned.

この質問からの結果は、<ipv4Network>か<ipv6Network>結果のどちらかであるに違いありません。 1つ以上のネットワーク結果が返されるかもしれません。

Gunduz, et al.              Standards Track                     [Page 5]

RFC 4698               IRIS Address Registry Type           October 2006

Gunduz、他規格は虹彩アドレス登録タイプ2006年10月にRFC4698を追跡します[5ページ]。

3.1.5.  <findNetworksByHandle>

3.1.5. <findNetworksByHandle>。

   The <findNetworksByHandle> element is a query for a network given a
   the handle of a related network.  It has the following child
   elements:

aを考えて、<findNetworksByHandle>要素はネットワークのための質問です。関連するネットワークのハンドル。それには、以下の子供要素があります:

   o  <networkHandle> - specifies the network handle.

o <networkHandle>--ネットワークハンドルを指定します。

   o  <specificity> - determines the network specificity for the search
      (see Section 4).  Valid values are "all-less-specifics", "one-
      level-less-specifics", "all-more-specifics", and "one-level-more-
      specifics".

o <の特異性>--検索(セクション4を見る)のためにネットワークの特異性を決定します。有効値は「よりオール少ない詳細」、「よりオール多くの詳細」の、そして、「1レベル多くの詳細」の「1つのレベルなしの詳細」です。

   The results from this query MUST be either <ipv4Network> or
   <ipv6Network> results.  More than one network result MAY be returned.

この質問からの結果は、<ipv4Network>か<ipv6Network>結果のどちらかであるに違いありません。 1つ以上のネットワーク結果が返されるかもしれません。

   This query could be used to discover the parentage relationships
   between networks that have the same starting and ending addresses.

同じ始めを持っているネットワークと終了アドレスとの生まれ関係を発見するのにこの質問を使用できました。

   The client SHOULD pass handles unchanged to the server, and the
   implementation of the server decides if the search is case sensitive
   or not.

クライアントSHOULDはサーバに変わりのないハンドルを渡します、そして、サーバの実装は検索が大文字と小文字を区別しているかどうか決めます。

3.1.6.  <findASByNumber>

3.1.6. <findASByNumber>。

   The <findASByNumber> element allows a search for autonomous systems
   given an autonomous system number (ASN) range.  It has the following
   child elements:

自律システム番号(ASN)範囲を考えて、<findASByNumber>要素は自律システムの検索を許します。それには、以下の子供要素があります:

   o  <asNumberStart> - specifies the start of the ASN range.

o <asNumberStart>--ASN範囲の始まりを指定します。

   o  <asNumberEnd> - specifies the end of the ASN range.

o <asNumberEnd>--ASN範囲の端を指定します。

   o  <specificity> - determines the range specificity for the search
      (see Section 4).  Valid values are "exact-match", "all-less-
      specific", "one-level-less-specific", "all-more-specific", and
      "one-level-more-specific".  This element may have the optional
      attribute 'allowEquivalences'.  When it is set to "true", the
      result set should include ranges with equivalent starting and
      ending numbers.  The default value for 'allowEquivalences' is
      "false".

o <の特異性>--検索(セクション4を見る)のために範囲の特異性を決定します。有効値は、「完全な一致」と、「よりオール少ない詳細」と、「あるレベルなしの詳細」と、「よりオール特有」、そして、「もうひとつのレベルの詳細」です。この要素には、任意の属性'allowEquivalences'があるかもしれません。それが「本当に」設定されるとき、結果セットは同等な始めの、そして、終わりの数がある範囲を含むべきです。 'allowEquivalences'のためのデフォルト値は「誤っています」。

   The results from this query MUST be <autonomousSystem> results.  More
   than one result MAY be returned.

この質問からの結果は<autonomousSystem>結果であるに違いありません。 1つ以上の結果が返されるかもしれません。

Gunduz, et al.              Standards Track                     [Page 6]

RFC 4698               IRIS Address Registry Type           October 2006

Gunduz、他規格は虹彩アドレス登録タイプ2006年10月にRFC4698を追跡します[6ページ]。

3.1.7.  <findByContact>

3.1.7. <findByContact>。

   The <findByContact> element allows a search for autonomous systems,
   IP networks, and organizations on fields associated with that
   entity's contact.  The optional search element <returnedResultType>
   MUST restrict the results to autonomous systems, IPv4 networks, IPv6
   networks, or organizations using the values 'returnASs',
   'returnIPv4Networks', 'returnIPv6Networks', and
   'returnOrganizations', respectively.

<findByContact>要素はその実体の接触に関連しているフィールドで自律システム、IPネットワーク、および組織の検索を許します。それぞれ値'returnASs'、'returnIPv4Networks'、'returnIPv6Networks'、および'returnOrganizations'を使用して、任意の検索要素<returnedResultType>は結果を自律システム、IPv4ネットワーク、IPv6ネットワーク、または組織に制限しなければなりません。

   The allowable search fields are handled with either the
   <contactHandle> element or one of the elements in the
   "contactSearchGroup" (see Section 3.1.9).  The <contactHandle>
   element allows for the entities to be selected based on the contact
   having the specified contact handle, and it is an
   "exactMatchParameter" type (see Section 3.1.11).  The client SHOULD
   pass these search fields unchanged to the server, and the
   implementation of the server decides if the search is case sensitive
   or not.

許容できる検索分野は<contactHandle>要素か"contactSearchGroup"の要素の1つのどちらかで扱われます(セクション3.1.9を見てください)。 >要素が、実体が接触に基づいて指定された接触ハンドル、およびそれを持ちながら選択されるのを許容する<contactHandleは"exactMatchParameter"タイプ(セクション3.1.11を見る)です。クライアントSHOULDはサーバに変わりのないこれらの検索野原を通り過ぎます、そして、サーバの実装は検索が大文字と小文字を区別しているかどうか決めます。

   The query MAY also be constrained further using the optional <role>
   element.  The contents of this element signify the role the contact
   has with the entity.  The allowable values for this element are
   "adminContact", "nocContact", "techContact", "abuseContact", and
   "otherContact".

また、さらに任意の<役割の>要素を使用して、質問も強制的であるかもしれません。この要素の内容は接触が実体で持っている役割を意味します。この要素のための許容量は、"adminContact"と、"nocContact"と、"techContact"と、"abuseContact"と、"otherContact"です。

   This query also provides optional <language> elements containing
   language tags.  Clients MAY use these elements to give a hint about
   the natural language(s) of the affected element.  Servers MAY use
   this information in processing the query, such as tailoring
   normalization routines to aid in more effective searches.

   The results from this query MUST be <ipv4Network> results,
   <ipv6Network> results, <autonomousSystem> results, or <organization>
   results.  More than one result MAY be returned, and the results MAY
   be of mixed types.

この質問からの結果は、<ipv4Network>結果、<ipv6Network>結果、<autonomousSystem>結果、または<組織>結果であるに違いありません。 1つ以上の結果が返されるかもしれません、そして、複雑なタイプには結果があるかもしれません。

3.1.8.  <findNetworksByNameServer>

3.1.8. <findNetworksByNameServer>。

   The <findNetworksByNameServer> element allows a search for IP
   networks based on their associated name servers.  The <nameServer>
   element contains the fully qualified domain name of the name server.
   The optional search element <returnedResultType> MUST restrict the
   results to IPv4 networks or IPv6 networks using the values
   'returnIPv4Networks' and 'returnIPv6Networks', respectively.

<findNetworksByNameServer>要素はそれらの関連ネームサーバに基づくIPネットワークの検索を許します。 <nameServer>要素はネームサーバに関する完全修飾ドメイン名を含んでいます。それぞれ値'returnIPv4Networks'と'returnIPv6Networks'を使用して、任意の検索要素<returnedResultType>は結果をIPv4ネットワークかIPv6ネットワークに制限しなければなりません。

Gunduz, et al.              Standards Track                     [Page 7]

RFC 4698               IRIS Address Registry Type           October 2006

Gunduz、他規格は虹彩アドレス登録タイプ2006年10月にRFC4698を追跡します[7ページ]。

   The results from this query MUST be <ipv4Network> or <ipv6Network>
   results.  More than one result MAY be returned, and the results MAY
   be of mixed types.

この質問からの結果は、<ipv4Network>か<ipv6Network>結果であるに違いありません。 1つ以上の結果が返されるかもしれません、そして、複雑なタイプには結果があるかもしれません。

3.1.9.  Contact Search Group

3.1.9. 連絡調査班

   Some of the queries above have similar query constraints for
   searching on contacts.  This section describes those common
   parameters.

上の質問のいくつかには、接触で探す同様の質問規制があります。このセクションはそれらの一般的なパラメタについて説明します。

   <commonName> allows the query to be constrained based on the common
   name of the contact.  This constraint is an
   "exactOrPartialMatchParameter" (see Section 3.1.11).

<commonName>は、質問が接触の一般名に基づいて抑制されるのを許容します。この規制は"exactOrPartialMatchParameter"(セクション3.1.11を見る)です。

   This group also contains all the members of the "commonSearchGroup"
   (see Section 3.1.10).

また、このグループは"commonSearchGroup"のすべてのメンバーを含みます(セクション3.1.10を見てください)。

3.1.10.  Common Search Group

3.1.10. 一般的な調査班

   Some of the queries above have similar query constraints for
   searching on contacts.  This section describes those common
   parameters.

上の質問のいくつかには、接触で探す同様の質問規制があります。このセクションはそれらの一般的なパラメタについて説明します。

   <eMail> constrains the query based on the e-mail address of the
   contact.  This constraint is a "domainResource" type (see
   Section 3.1.11).

<eMail>は接触のEメールアドレスに基づく質問を抑制します。この規制は"domainResource"タイプ(セクション3.1.11を見る)です。

   The <city>, <region>, <country>, and <postalCode> elements restrict
   the scope of the query based on the city, region, country, or postal
   code of the contact, respectively.  These constraints are all
   "exactMatchParameter" types (see Section 3.1.11).  The contents of
   <country> MUST be compliant with ISO 3166 [9] two-character country
   codes.

<都市の>、<領域>、<国の>、および<postalCode>要素はそれぞれ接触の都市、領域、国、または郵便番号に基づく質問の範囲を制限します。これらの規制は皆"exactMatchParameter"タイプ(セクション3.1.11を見る)です。 <国の>のコンテンツは[9] ISO3166の2キャラクタの国名略号で対応するに違いありません。

3.1.11.  Match Parameters

3.1.11. パラメタを合わせてください。

   Some of the queries above have constraints that match strings using
   matching parameters.  This section describes those matching
   parameters.

上の質問のいくつかには、合っているパラメタを使用することでストリングに合っている規制があります。このセクションはそれらの合っているパラメタについて説明します。

   Elements of type "exactMatchParameter" will have one child element of
   <exactMatch>.  The contents of this child element are to match
   exactly in the use of the constraint.

タイプ"exactMatchParameter"のElementsには、<exactMatch>の1つの子供要素があるでしょう。この子供要素の内容はちょうど規制の使用で合うことです。

   Elements of type "partialMatchParameter" will have either a
   <beginsWith> child element with an optional <endsWith> child element
   or an <endsWith> child element.  The content of the <beginsWith>

タイプ"partialMatchParameter"のElementsには、任意の<endsWith>子供要素がある<beginsWith>子供要素か<endsWith>子供要素のどちらかがあるでしょう。 <beginsWith>の内容

Gunduz, et al.              Standards Track                     [Page 8]

RFC 4698               IRIS Address Registry Type           October 2006

Gunduz、他規格は虹彩アドレス登録タイプ2006年10月にRFC4698を追跡します[8ページ]。

   element specifies the beginning character sequence for the
   constraint.  The content of the <endsWith> element specifies the
   ending character sequence for the constraint.

要素は始めのキャラクタシーケンスを規制に指定します。 <endsWith>要素の内容は終わりのキャラクタシーケンスを規制に指定します。

   Elements of type "exactOrPartialMatchParameter" can have either the
   child element allowed with the "exactMatchParameter" type or the
   child elements allowed with the "partialMatchParameter" type.

タイプ"exactOrPartialMatchParameter"のElementsは"partialMatchParameter"タイプで"exactMatchParameter"タイプで許容された子供要素か子供要素のどちらかを許容させることができます。

   Elements of type "domainResource" can have either the child element
   allowed with the "exactMatchParameter" type or a child element of
   <inDomain>.  This parameter type is meant to match email, SIP,
   Extensible Messaging and Presence Protocol (XMPP), and other types of
   "user@domain" addresses.  When this parameter is specified with the
   <exactMatch> child element, the constraint is based on the whole
   email address.  When this parameter is specified with the <inDomain>
   child element, the constraint is based on any email address within
   the domain given.  The <inDomain> MUST only contain a valid domain
   name (i.e., no '@' symbol), and the matching SHOULD take place only
   on the domain given (i.e., no partial matches with respect to
   substrings or parent domains).

タイプ"domainResource"のElementsは"exactMatchParameter"タイプで許容された子供要素か<inDomain>の子供要素のどちらかを持つことができます。このパラメータの型はメール(SIP、Extensible Messaging、Presenceプロトコル(XMPP)、および他のタイプの" user@domain "アドレス)に合うことになっています。このパラメタが<exactMatch>子供要素で指定されるとき、規制は全体のEメールアドレスに基づいています。このパラメタが<inDomain>子供要素で指定されるとき、規制は与えられたドメインの中のどんなEメールアドレスにも基づいています。 <inDomain>は有効なドメイン名(すなわち、'@'シンボルがない)を保管するだけでよいです、そして、(すなわち、サブストリングか親ドメインに関する部分的なマッチがありません)と考えて、合っているSHOULDはドメインだけで行われます。

3.2.  Result Derivatives

3.2. 結果派生物

3.2.1.  <ipv4Network> and <ipv6Network> Results

3.2.1. <ipv4Network>と<ipv6Network>結果

   The <ipv4Network> and <ipv6Network> share a common definition of
   'ipNetworkType'.  It has the following child elements:

<ipv4Network>と<ipv6Network>は'ipNetworkType'の一般的な定義を共有します。それには、以下の子供要素があります:

   o  <networkHandle> contains the registry-unique assigned handle for
      this network.

o <networkHandle>はこのネットワークに、登録ユニークな割り当てられたハンドルを含んでいます。

   o  <name> contains a human-friendly name for the network.

o <名前>はネットワークのための人間に優しい名前を含んでいます。

   o  <startAddress> contains the first IP address of the network.

o <startAddress>はネットワークの最初のIPアドレスを含んでいます。

   o  <endAddress> contains the last IP address of the network.

o <endAddress>はネットワークの最後のIPアドレスを含んでいます。

   o  <networkType> contains a string denoting the type of network.

o <networkType>はネットワークのタイプを指示するストリングを含んでいます。

   o  <networkTypeInfo> is an entity reference to a definition of the
      values explained in a plain natural language.  The referent MUST
      be a <simpleEntity> as defined by [2].

o <networkTypeInfo>は明瞭な自然言語で説明された値の定義が実体参照です。指示物は[2]によって定義されるように<simpleEntity>であるに違いありません。

   o  <nameServer> contains the domain name of a nameserver responsible
      for reverse-DNS mapping for this network.

o <nameServer>はこのネットワークにおいて、逆DNSマッピングに原因となるネームサーバのドメイン名を含んでいます。

Gunduz, et al.              Standards Track                     [Page 9]

RFC 4698               IRIS Address Registry Type           October 2006

Gunduz、他規格は虹彩アドレス登録タイプ2006年10月にRFC4698を追跡します[9ページ]。

   o  <organization> contains an entity reference to the organization
      assigned this network.  The referent MUST be an <organization>
      (Section 3.2.4) result.

o <組織>はこのネットワークに配属された組織の実体参照を含んでいます。指示物は<組織>(セクション3.2.4)結果であるに違いありません。

   o  One of the following:

o 以下の1つ:

      *  <parent> contains an entity reference to the parent network of
         this network.  The referent MUST be an <ipv4Network>
         (Section 3.2.1) result if this reference is a child of
         <ipv4Network>.  The referent MUST be an <ipv6Network>
         (Section 3.2.1) result if this reference is a child of
         <ipv6Network>.

* <親>はこのネットワークの親ネットワークの実体参照を含んでいます。この参照が<ipv4Network>の子供であるなら、指示物は<ipv4Network>(セクション3.2.1)結果であるに違いありません。この参照が<ipv6Network>の子供であるなら、指示物は<ipv6Network>(セクション3.2.1)結果であるに違いありません。

      *  <noParent> signifies that this network has no parent network.

* <noParent>は、このネットワークには親ネットワークが全くないのを意味します。

   o  Contact references (see Section 3.2.5).

o 参照に連絡してください(セクション3.2.5を見てください)。

   o  Common child elements (see Section 3.2.6).

o 一般的な子供要素(セクション3.2.6を見ます)。

3.2.2.  <autonomousSystem> Result

3.2.2. <autonomousSystem>結果

   The <autonomousSystem> element represents an assigned or allocated
   autonomous system number range.  It has the following children:

<autonomousSystem>要素は割り当てられたか割り当てられた自律システム数の範囲を表します。それには、以下の子供がいます:

   o  <asHandle> contains a registry-unique assigned handle for this
      autonomous system number range.

o <asHandle>はこの自律システム数の範囲への登録ユニークな割り当てられたハンドルを含んでいます。

   o  <asNumberStart> contains an integer indicating the starting number
      for the autonomous system number range.

o <asNumberStart>は自律システム数の範囲の始めの数を示す整数を含んでいます。

   o  <asNumberEnd> contains an integer indicating the ending number for
      the autonomous system number range.

o <asNumberEnd>は自律システム数の範囲の終わりの数を示す整数を含んでいます。

   o  <name> contains a human-readable name for this autonomous system.

o <名前>はこの自律システムのための人間読み込み可能な名前を含んでいます。

   o  <organization> contains an entity reference to the organization
      assigned or allocated this autonomous system number range.  The
      referent MUST be an <organization> (Section 3.2.4) result.

o <組織>は組織の参照が割り当てた実体を含んだか、またはこの自律システム数の範囲を割り当てました。指示物は<組織>(セクション3.2.4)結果であるに違いありません。

   o  One of the following:

o 以下の1つ:

      *  <parent> contains an entity reference to the parent autonomous
         system of this autonomous system.  The referent MUST be an
         <autonomousSystem> (Section 3.2.2) result.

* <親>はこの自律システムの親自律システムの実体参照を含んでいます。指示物は<autonomousSystem>(セクション3.2.2)結果であるに違いありません。

      *  <noParent> signifies that this autonomous system has no parent
         autonomous system.

* <noParent>は、この自律システムには親自律システムが全くないのを意味します。

Gunduz, et al.              Standards Track                    [Page 10]

RFC 4698               IRIS Address Registry Type           October 2006

Gunduz、他規格は虹彩アドレス登録タイプ2006年10月にRFC4698を追跡します[10ページ]。

   o  Contact references (see Section 3.2.5).

o 参照に連絡してください(セクション3.2.5を見てください)。

   o  Common child elements (see Section 3.2.6).

o 一般的な子供要素(セクション3.2.6を見ます)。

3.2.3.  <contact> Result

3.2.3. <接触>結果

   The <contact> element represents the registration of a point of
   contact.  It has the following child elements:

<連絡>要素は連絡先の登録を表します。それには、以下の子供要素があります:

   o  <contactHandle> contains the registry-unique assigned handle for
      this contact.

o <contactHandle>はこの接触への登録ユニークな割り当てられたハンドルを含んでいます。

   o  <commonName> specifies the name of the contact.

o <commonName>は接触の名前を指定します。

   o  <eMail> contains the email address for this contact.

o <eMail>はこの接触のためのEメールアドレスを含んでいます。

   o  <sip> contains the sip address for this contact.

o <一口>はこの接触への一口アドレスを含んでいます。

   o  <organization> contains an entity reference to the organization
      associated with this contact.  The referent MUST be an
      <organization> (Section 3.2.4) result.

o <組織>はこの接触に関連している組織の実体参照を含んでいます。指示物は<組織>(セクション3.2.4)結果であるに違いありません。

   o  <postalAddress> contains information for reaching the contact via
      postal mail.  It is composed of the following child elements:

o <postalAddress>は郵便で接触に達するための情報を含んでいます。それは以下の子供要素で構成されます:

      *  <address> contains the address for this contact.

* <アドレス>はこの接触へのアドレスを含んでいます。

      *  <city> contains the city where this contact is located.

* <都市の>はこの接触が位置している都市を含んでいます。

      *  <region> contains the national region where this contact is
         located.

* <領域>はこの接触が位置している国家の領域を含んでいます。

      *  <postalCode> contains the postal code where this contact is
         located.

* <postalCode>はこの接触が位置している郵便番号を含んでいます。

      *  <country> contains the country code where this contact is
         located.  This MUST be compliant with ISO 3166 [9]
         two-character country codes.

* この接触が見つけられているところに<国の>は国名略号を含んでいます。これは[9] ISO3166の2キャラクタの国名略号で言いなりになっているに違いありません。

   o  <phone> contains child elements describing the phone number of the
      contact.  The child elements are <number>, <extension>, and
      <type>.

o <電話>は接触の電話番号について説明する子供要素を含んでいます。子供要素は、<番号>と、<拡張子>と、<タイプ>です。

   o  Common child elements (see Section 3.2.6).

o 一般的な子供要素(セクション3.2.6を見ます)。

Gunduz, et al.              Standards Track                    [Page 11]

RFC 4698               IRIS Address Registry Type           October 2006

Gunduz, et al. Standards Track [Page 11] RFC 4698 IRIS Address Registry Type October 2006

3.2.4.  <organization> Result

3.2.4. <organization> Result

   The <organization> element represents an organization.  It has the
   following child elements:

The <organization> element represents an organization. It has the following child elements:

   o  <name> contains the name of the organization.

o <name> contains the name of the organization.

   o  <id> contains a registry-unique identifier for this organization.

o <id> contains a registry-unique identifier for this organization.

   o  <eMail> contains the email address for this organization.

o <eMail> contains the email address for this organization.

   o  <postalAddress> contains a information for reaching the
      organization via postal mail.  It is composed of the following
      child elements:

o <postalAddress> contains a information for reaching the organization via postal mail. It is composed of the following child elements:

      *  <address> contains the address for this organization.

* <address> contains the address for this organization.

      *  <city> contains the city where this organization is located.

* <city> contains the city where this organization is located.

      *  <region> contains the national region where this organization
         is located.

* <region> contains the national region where this organization is located.

      *  <postalCode> contains the postal code where this organization
         is located.

* <postalCode> contains the postal code where this organization is located.

      *  <country> contains the country code where this organization is
         located.  This MUST be compliant with ISO 3166 [9]
         two-character country codes.

* <country> contains the country code where this organization is located. This MUST be compliant with ISO 3166 [9] two-character country codes.

   o  <phone> contains child elements describing the phone number of the
      contact.  The child elements are <number>, <extension>, and
      <type>.

o <phone> contains child elements describing the phone number of the contact. The child elements are <number>, <extension>, and <type>.

   o  Contact references (see Section 3.2.5).

o Contact references (see Section 3.2.5).

   o  Common child elements (see Section 3.2.6).

o Common child elements (see Section 3.2.6).

3.2.5.  Contact References

3.2.5. Contact References

   The registry schema defined in Section 5 normalizes out a group of
   elements used to reference contacts.  This group is used by many of
   the result types for this registry.  The group has the following
   elements, each of which may appear as many times as needed.  The
   referent of each MUST be <contact> (Section 3.2.3) results.

The registry schema defined in Section 5 normalizes out a group of elements used to reference contacts. This group is used by many of the result types for this registry. The group has the following elements, each of which may appear as many times as needed. The referent of each MUST be <contact> (Section 3.2.3) results.

   o  <adminContact>

o <adminContact>

   o  <techContact>

o <techContact>

Gunduz, et al.              Standards Track                    [Page 12]

RFC 4698               IRIS Address Registry Type           October 2006

Gunduz, et al. Standards Track [Page 12] RFC 4698 IRIS Address Registry Type October 2006

   o  <nocContact>

o <nocContact>

   o  <abuseContact>

o <abuseContact>

   o  <otherContact>

o <otherContact>

3.2.6.  Common Result Child Elements

3.2.6. Common Result Child Elements

   The registry schema defined in Section 5 normalizes out a group of
   common elements that are used most among the result types.  The group
   has the following elements:

The registry schema defined in Section 5 normalizes out a group of common elements that are used most among the result types. The group has the following elements:

   o  <numberResourceRegistry> contains an entity reference to the
      number resource registry of record.  The referent MUST be an
      <organization> (Section 3.2.4) result.

o <numberResourceRegistry> contains an entity reference to the number resource registry of record. The referent MUST be an <organization> (Section 3.2.4) result.

   o  <registrationDate> contains the date of first registration.

o <registrationDate> contains the date of first registration.

   o  <lastUpdatedDate> contains the date when the registration was last
      updated.

o <lastUpdatedDate> contains the date when the registration was last updated.

   o  The <iris:seeAlso> element contains an entity reference specifying
      an entity that is indirectly associated with this result object.
      This element can be used for comments and remarks.

o The <iris:seeAlso> element contains an entity reference specifying an entity that is indirectly associated with this result object. This element can be used for comments and remarks.

3.3.  Support for <iris:lookupEntity>

3.3. Support for <iris:lookupEntity>

   The following types of entity classes are recognized by the
   <lookupEntity> query of IRIS for this registry:

The following types of entity classes are recognized by the <lookupEntity> query of IRIS for this registry:

   o  ipv4-handle - a registry-unique identifier specifying an IPv4
      network.  Queries with these names will yield a <ipv4Network>
      result.

o ipv4-handle - a registry-unique identifier specifying an IPv4 network. Queries with these names will yield a <ipv4Network> result.

   o  ipv6-handle - a registry-unique identifier specifying an IPv6
      network.  Queries with these names will yield a <ipv6Network>
      result.

o ipv6-handle - a registry-unique identifier specifying an IPv6 network. Queries with these names will yield a <ipv6Network> result.

   o  as-handle - a registry-unique identifier specifying an autonomous
      system.  It yields a result of <autonomousSystem>.

o as-handle - a registry-unique identifier specifying an autonomous system. It yields a result of <autonomousSystem>.

   o  contact-handle - a registry-unique identifier of a contact.
      Yields a result of <contact>.

o contact-handle - a registry-unique identifier of a contact. Yields a result of <contact>.

   o  organization-id - a registry-unique identifier of an organization.
      Yields a result of <organization>.

o organization-id - a registry-unique identifier of an organization. Yields a result of <organization>.

   o  The entity names of these entity classes are case insensitive.

o The entity names of these entity classes are case insensitive.

Gunduz, et al.              Standards Track                    [Page 13]

RFC 4698               IRIS Address Registry Type           October 2006

Gunduz, et al. Standards Track [Page 13] RFC 4698 IRIS Address Registry Type October 2006

4.  Terminology for Nesting of Networks

4. Terminology for Nesting of Networks

   The following terms are defined for describing the nesting of IP
   networks.

The following terms are defined for describing the nesting of IP networks.

   o  More specific: Given two networks, A and B, A is more specific
      than B if network B includes all space of network A, and if
      network B is larger than network A.

o More specific: Given two networks, A and B, A is more specific than B if network B includes all space of network A, and if network B is larger than network A.

   o  Less specific: Opposite of more specific.  The network B is less
      specific than network A if network A's space is completely
      included in network B and if network A is smaller than network B.

o Less specific: Opposite of more specific. The network B is less specific than network A if network A's space is completely included in network B and if network A is smaller than network B.

   o  Most specific: Given a set of networks, the network or networks
      that are more specific than zero or more specific of the other
      networks in the set, and that are not less specific of any of the
      networks in the set.

o Most specific: Given a set of networks, the network or networks that are more specific than zero or more specific of the other networks in the set, and that are not less specific of any of the networks in the set.

   o  Least specific: Given a set of networks, the network or networks
      that are not more specific to any of the other networks in the
      set.

o Least specific: Given a set of networks, the network or networks that are not more specific to any of the other networks in the set.

   Examples:

Examples:

   +-------------------------------------------------------+
   |                                                       |
   | Given the networks A, B, C, and D as follows:         |
   |                                                       |
   |    A    |---------------------------------|           |
   |    B                    |-----------------|           |
   |    C                       |---------|                |
   |    D      |-------|                                   |
   |                                                       |
   |                                                       |
   | Network A is less specific than B, C, and D.          |
   | Network B is more specific than A.                    |
   | Among these four networks, A is the least specific,   |
   |   and C and D are the most specific.                  |
   |                                                       |
   +-------------------------------------------------------+

+-------------------------------------------------------+ | | | Given the networks A, B, C, and D as follows: | | | | A |---------------------------------| | | B |-----------------| | | C |---------| | | D |-------| | | | | | | Network A is less specific than B, C, and D. | | Network B is more specific than A. | | Among these four networks, A is the least specific, | | and C and D are the most specific. | | | +-------------------------------------------------------+

                        Figure 1: Nesting Example 1

Figure 1: Nesting Example 1

Gunduz, et al.              Standards Track                    [Page 14]

RFC 4698               IRIS Address Registry Type           October 2006

Gunduz, et al. Standards Track [Page 14] RFC 4698 IRIS Address Registry Type October 2006

   +-------------------------------------------------------+
   |                                                       |
   | Given networks E, F, and G:                           |
   |                                                       |
   |    E   |----------|                                   |
   |    F                |--------------|                  |
   |    G     |---|                                        |
   |                                                       |
   | Networks E and F are least specific networks.         |
   | Networks F and G are most specific networks.          |
   |                                                       |
   +-------------------------------------------------------+

+-------------------------------------------------------+ | | | Given networks E, F, and G: | | | | E |----------| | | F |--------------| | | G |---| | | | | Networks E and F are least specific networks. | | Networks F and G are most specific networks. | | | +-------------------------------------------------------+

                        Figure 2: Nesting Example 2

Figure 2: Nesting Example 2

   The following definitions assume that there are no overlapping
   networks in the database.  A network overlaps with another one when
   they encompass each other's space partially.  Examples:

The following definitions assume that there are no overlapping networks in the database. A network overlaps with another one when they encompass each other's space partially. Examples:

     A   |---------------------|
     B       |----------------------------|

A |---------------------| B |----------------------------|

                        Figure 3: Nesting Example 3

Figure 3: Nesting Example 3

   Here, networks A and B are overlapping networks because network A
   encompasses network B's space partially, and network B encompasses
   network A's space partially.

Here, networks A and B are overlapping networks because network A encompasses network B's space partially, and network B encompasses network A's space partially.

     C   |------------------|
     D   |---------|

C |------------------| D |---------|

                        Figure 4: Nesting Example 4

Figure 4: Nesting Example 4

   Here, networks C and D are NOT overlapping networks because even if
   network D encompasses a part of network C's space, network C does not
   encompass network D's space partially (it encompasses network D
   completely).

Here, networks C and D are NOT overlapping networks because even if network D encompasses a part of network C's space, network C does not encompass network D's space partially (it encompasses network D completely).

   The address directory can contain more than one network with the same
   range.  They are said to be exact match networks.

The address directory can contain more than one network with the same range. They are said to be exact match networks.

   The parent/child relationship in the internet address directory is
   unidirectional.  That is, there might also be parent/child
   relationship with exact match networks, but a network cannot be a
   parent and a child of its exact match network at the same time.

The parent/child relationship in the internet address directory is unidirectional. That is, there might also be parent/child relationship with exact match networks, but a network cannot be a parent and a child of its exact match network at the same time.

Gunduz, et al.              Standards Track                    [Page 15]

RFC 4698               IRIS Address Registry Type           October 2006

Gunduz, et al. Standards Track [Page 15] RFC 4698 IRIS Address Registry Type October 2006

   The following are nested matching searches:

The following are nested matching searches:

   (1) all less specifics search: Given a range, find all the networks
       that contain that range (i.e., all less specifics and exact
       matches).  These networks are the networks that fulfill the
       following condition:

(1) all less specifics search: Given a range, find all the networks that contain that range (i.e., all less specifics and exact matches). These networks are the networks that fulfill the following condition:

   (start(network) <= start(search)) AND (end(network) >= end(search))

(start(network) <= start(search)) AND (end(network) >= end(search))

   (2) one-level less specifics search: Given a range, find only the
       most specific network that contains that range (could be multiple
       networks, but usually single).  This is the set of networks from
       (1), with the provision that no network in the return set is
       contained by any other network in the set.  If there are exact
       match networks in the set from (1), they both must appear in the
       result set.  The result set may contain a network that is exact
       match to the query range, if the search allows exact matches.

(2) one-level less specifics search: Given a range, find only the most specific network that contains that range (could be multiple networks, but usually single). This is the set of networks from (1), with the provision that no network in the return set is contained by any other network in the set. If there are exact match networks in the set from (1), they both must appear in the result set. The result set may contain a network that is exact match to the query range, if the search allows exact matches.

       A  |-------------------------------|
       B  |---------------------------|
       C            |-------|
       Query  |- - - - - - - - - -|

A |-------------------------------| B |---------------------------| C |-------| Query |- - - - - - - - - -|

                          Figure 5: Nesting Example 5

Figure 5: Nesting Example 5

       In the above case, the query must return B.

In the above case, the query must return B.

       A  |-------------------------------|
       B  |---------------------------|
       C  |---------------------------|
       D            |-------|
       Query  |- - - - - - - - - -|

A |-------------------------------| B |---------------------------| C |---------------------------| D |-------| Query |- - - - - - - - - -|

                          Figure 6: Nesting Example 6

Figure 6: Nesting Example 6

       Here, the query must return B and C (they are exact matches of
       each other).

Here, the query must return B and C (they are exact matches of each other).

       A  |-------------------------------|
       B  |---------------------------|
       C  |---------------------------|
       D            |-------|
       Query        |- - - -|

A |-------------------------------| B |---------------------------| C |---------------------------| D |-------| Query |- - - -|

                          Figure 7: Nesting Example 7

Figure 7: Nesting Example 7

Gunduz, et al.              Standards Track                    [Page 16]

RFC 4698               IRIS Address Registry Type           October 2006

Gunduz, et al. Standards Track [Page 16] RFC 4698 IRIS Address Registry Type October 2006

       Here, the query must return B and C (they are exact matches of
       each other).  D must not be in the result set, as it is exact
       match to the query if the search specifies that exact matches of
       query range should not appear in the result set.

Here, the query must return B and C (they are exact matches of each other). D must not be in the result set, as it is exact match to the query if the search specifies that exact matches of query range should not appear in the result set.

       In Figure 7, if the search specifies that exact matches to the
       query range are allowed in the result set, then only D must be
       returned.

In Figure 7, if the search specifies that exact matches to the query range are allowed in the result set, then only D must be returned.

   (3) all more specifics search: Given a range, find all the networks
       that are fully within that range.  The search contains a flag
       that specifies if an exact match to the query range should appear
       in the result set or not.  Thus, the result set may or may not
       contain the exact match to the query range, as instructed by the
       search.

(3) all more specifics search: Given a range, find all the networks that are fully within that range. The search contains a flag that specifies if an exact match to the query range should appear in the result set or not. Thus, the result set may or may not contain the exact match to the query range, as instructed by the search.

   (start(network) >= start(search)) AND (end(network) <= end(search))

(start(network) >= start(search)) AND (end(network) <= end(search))

   (4) one-level more specifics search: Given a range, find only the
       least specific networks that are fully within that range.  This
       is the set of networks from (3), with the provision that no
       network in the return set contains any other network in the
       return set.

(4) one-level more specifics search: Given a range, find only the least specific networks that are fully within that range. This is the set of networks from (3), with the provision that no network in the return set contains any other network in the return set.

       Query   |- - - - - - - - - - - - - - - - - - - - - - -|

Query |- - - - - - - - - - - - - - - - - - - - - - -|

       A       |------------------|
       B                           |-------------------------|
       C           |--------|
       D                                      |---------|

A |------------------| B |-------------------------| C |--------| D |---------|

                          Figure 8: Nesting Example 8

Figure 8: Nesting Example 8

   (5) exact match search: Given a range, find the networks that begin
       and end on the same IP addresses as the range.  That is, the
       networks that fulfill the following condition:

(5) exact match search: Given a range, find the networks that begin and end on the same IP addresses as the range. That is, the networks that fulfill the following condition:

   (start(network) = start(search)) AND (end(network) = end(search))

(start(network) = start(search)) AND (end(network) = end(search))

   (6) Given a range, find the exact match network if it exists, and if
       it does not, perform the (2) search.

(6) Given a range, find the exact match network if it exists, and if it does not, perform the (2) search.

   The following are parent-child relationship searches:

The following are parent-child relationship searches:

   (7) Given a network handle, find the network that is the direct (one
       level up) parent of the network with the given handle.

(7) Given a network handle, find the network that is the direct (one level up) parent of the network with the given handle.

Gunduz, et al.              Standards Track                    [Page 17]

RFC 4698               IRIS Address Registry Type           October 2006

Gunduz, et al. Standards Track [Page 17] RFC 4698 IRIS Address Registry Type October 2006

   (8) Given a network handle, find the network or networks that are
       direct (one level down) children of the network with the handle
       given.

(8) Given a network handle, find the network or networks that are direct (one level down) children of the network with the handle given.

5.  Formal XML Syntax

5. Formal XML Syntax

   This IP address registry is specified in the XML Schema notation.
   The formal syntax presented here is a complete schema representation
   suitable for automated validation of an XML instance when combined
   with the formal schema syntax of IRIS.

This IP address registry is specified in the XML Schema notation. The formal syntax presented here is a complete schema representation suitable for automated validation of an XML instance when combined with the formal schema syntax of IRIS.

   <?xml version="1.0"?>
   <schema xmlns="http://www.w3.org/2001/XMLSchema"
     xmlns:areg="urn:ietf:params:xml:ns:areg1"
     xmlns:iris="urn:ietf:params:xml:ns:iris1"
     targetNamespace="urn:ietf:params:xml:ns:areg1"
     elementFormDefault="qualified" >

<?xml version="1.0"?> <schema xmlns="http://www.w3.org/2001/XMLSchema" xmlns:areg="urn:ietf:params:xml:ns:areg1" xmlns:iris="urn:ietf:params:xml:ns:iris1" targetNamespace="urn:ietf:params:xml:ns:areg1" elementFormDefault="qualified" >

     <import namespace="urn:ietf:params:xml:ns:iris1" />

     <annotation>
       <documentation> IP address registry schema derived from IRIS
         schema </documentation>
     </annotation>

<annotation> <documentation> IP address registry schema derived from IRIS schema </documentation> </annotation>

     <!-- ========================================= -->
     <!--                                           -->
     <!-- Query Types                               -->
     <!--                                           -->

     <!-- ========================================= -->
     <!--                                           -->
     <!-- Find Autonomous Systems By Name           -->
     <!-- Find Networks By Name                     -->
     <!--                                           -->

     <complexType name="findByNameType" >
       <complexContent>
         <extension base="iris:queryType">
           <sequence>
             <element name="name"
               type="areg:exactOrPartialMatchParameter" />
             <element name="language" type="language" minOccurs="0"
               maxOccurs="unbounded"/>
           </sequence>
         </extension>
       </complexContent>

Gunduz, et al.              Standards Track                    [Page 18]

RFC 4698               IRIS Address Registry Type           October 2006

Gunduz, et al. Standards Track [Page 18] RFC 4698 IRIS Address Registry Type October 2006

     </complexType>

</complexType>

     <element name="findNetworksByName" type="areg:findByNameType"
       substitutionGroup="iris:query" />
     <element name="findAutonomousSystemsByName"
       type="areg:findByNameType"
       substitutionGroup="iris:query" />

     <!--                                           -->
     <!-- Address/Address Range type for            -->
     <!--   Find Network                            -->
     <!--                                           -->

     <complexType name="addressRangeType">
       <sequence>
         <element name="start" type="token" />
         <element name="end" type="token" minOccurs="0" maxOccurs="1" />
       </sequence>
     </complexType>

     <!--                                           -->
     <!-- Find Networks By Address                  -->
     <!--                                           -->

     <complexType name="findNetworksByAddressType" >
       <complexContent>
         <extension base="iris:queryType">
           <sequence>
             <choice>
               <element name="ipv4Address" type="areg:addressRangeType"
                 />
               <element name="ipv6Address" type="areg:addressRangeType"
                 />
             </choice>
             <element name="specificity">
               <complexType>
                 <simpleContent>
                   <extension base="areg:specificityType" >
                     <attribute name="allowEquivalences" type="boolean"
                       default="false" />
                   </extension>
                 </simpleContent>
               </complexType>
             </element>
           </sequence>
         </extension>
       </complexContent>
     </complexType>

Gunduz, et al.              Standards Track                    [Page 19]

RFC 4698               IRIS Address Registry Type           October 2006

Gunduz, et al. Standards Track [Page 19] RFC 4698 IRIS Address Registry Type October 2006

     <element name="findNetworksByAddress"
       type="areg:findNetworksByAddressType"
       substitutionGroup="iris:query" />

     <!--                                           -->
     <!-- Find AS By Number                         -->
     <!--                                           -->

     <complexType name="findASByNumberType" >
       <complexContent>
         <extension base="iris:queryType">
           <sequence>
             <element name="asNumberStart" type="token" />
             <element name="asNumberEnd" type="token" minOccurs="0"
               maxOccurs="1" />
             <element name="specificity">
               <complexType>
                 <simpleContent>
                   <extension base="areg:specificityType" >
                     <attribute name="allowEquivalences" type="boolean"
                       default="false" />
                   </extension>
                 </simpleContent>
               </complexType>
             </element>
           </sequence>
         </extension>
       </complexContent>
     </complexType>

     <element name="findASByNumber" type="areg:findASByNumberType"
       substitutionGroup="iris:query" />

     <!--                                           -->
     <!-- Specificity Type                          -->
     <!--                                           -->

     <simpleType name="specificityType">
       <restriction base="string">
         <enumeration value="exact-match" />
         <enumeration value="all-less-specific" />
         <enumeration value="one-level-less-specific" />
         <enumeration value="all-more-specific" />
         <enumeration value="one-level-more-specific" />
       </restriction>
     </simpleType>

     <!--                                           -->

Gunduz, et al.              Standards Track                    [Page 20]

RFC 4698               IRIS Address Registry Type           October 2006

Gunduz, et al. Standards Track [Page 20] RFC 4698 IRIS Address Registry Type October 2006

     <!-- Find By Contact                           -->
     <!--                                           -->

     <complexType name="findByContactType">
       <complexContent>
         <extension base="iris:queryType">
           <sequence>
             <choice>
               <group ref="areg:contactSearchGroup" />
               <element name="contactHandle"
                 type="areg:exactMatchParameter" />
             </choice>
             <element name="returnedResultType" minOccurs="0"
               maxOccurs="1" >
               <simpleType>
                 <restriction base="string" >
                   <enumeration value="returnASs" />
                   <enumeration value="returnIPv4Networks" />
                   <enumeration value="returnIPv6Networks" />
                   <enumeration value="returnOrganizations" />
                 </restriction>
               </simpleType>
             </element>
             <element name="role" minOccurs="0" maxOccurs="1" >
               <simpleType>
                 <restriction base="string" >
                   <enumeration value="adminContact" />
                   <enumeration value="techContact" />
                   <enumeration value="nocContact" />
                   <enumeration value="abuseContact" />
                   <enumeration value="otherContact" />
                 </restriction>
               </simpleType>
             </element>
             <element name="language" type="language" minOccurs="0"
               maxOccurs="unbounded"/>
           </sequence>
         </extension>
       </complexContent>
     </complexType>

     <element name="findByContact" type="areg:findByContactType"
       substitutionGroup="iris:query" />

     <!--                                           -->
     <!-- Find Networks By Handle                   -->
     <!--                                           -->

Gunduz, et al.              Standards Track                    [Page 21]

RFC 4698               IRIS Address Registry Type           October 2006

Gunduz, et al. Standards Track [Page 21] RFC 4698 IRIS Address Registry Type October 2006

     <complexType name="findNetworksByHandleType" >
       <complexContent>
         <extension base="iris:queryType">
           <sequence>
             <element name="networkHandle" type="token" />
             <element name="specificity"
               type="areg:specificitySubsetType" />
           </sequence>
         </extension>
       </complexContent>
     </complexType>

     <element name="findNetworksByHandle"
       type="areg:findNetworksByHandleType"
       substitutionGroup="iris:query" />

     <!--                                           -->
     <!-- Specificity Subtype                       -->
     <!--                                           -->

     <simpleType name="specificitySubsetType">
       <restriction base="string">
         <enumeration value="all-less-specific" />
         <enumeration value="one-level-less-specific" />
         <enumeration value="all-more-specific" />
         <enumeration value="one-level-more-specific" />
       </restriction>
     </simpleType>

     <!--                                           -->
     <!-- Find Contacts                             -->
     <!--                                           -->

     <complexType name="findContactsType">
       <complexContent>
         <extension base="iris:queryType">
           <sequence>
             <choice>
               <group ref="areg:contactSearchGroup" />
               <element name="organizationId"
                 type="areg:exactMatchParameter" />
             </choice>
             <element name="language" type="language" minOccurs="0"
               maxOccurs="unbounded"/>
           </sequence>
         </extension>
       </complexContent>
     </complexType>

Gunduz, et al.              Standards Track                    [Page 22]

RFC 4698               IRIS Address Registry Type           October 2006

Gunduz, et al. Standards Track [Page 22] RFC 4698 IRIS Address Registry Type October 2006

     <element name="findContacts" type="areg:findContactsType"
       substitutionGroup="iris:query" />

     <!--                                           -->
     <!-- Find Organizations                        -->
     <!--                                           -->

     <complexType name="findOrganizationsType">
       <complexContent>
         <extension base="iris:queryType">
           <sequence>
             <choice>
               <element name="organizationName"
                 type="areg:exactOrPartialMatchParameter" />
               <group ref="areg:commonSearchGroup" />
             </choice>
             <element name="language" type="language" minOccurs="0"
               maxOccurs="unbounded"/>
           </sequence>
         </extension>
       </complexContent>
     </complexType>

     <element name="findOrganizations" type="areg:findOrganizationsType"
       substitutionGroup="iris:query" />

     <!--                                           -->
     <!-- Find Networks by Name Server              -->
     <!--                                           -->

     <complexType name="findNetworksByNameServerType">
       <complexContent>
         <extension base="iris:queryType">
           <sequence>
             <element name="nameServer" type="normalizedString" />
             <element name="returnedResultType" minOccurs="0"
               maxOccurs="1" >
               <simpleType>
                 <restriction base="string" >
                   <enumeration value="returnIPv4Networks" />
                   <enumeration value="returnIPv6Networks" />
                 </restriction>
               </simpleType>
             </element>
           </sequence>
         </extension>
       </complexContent>
     </complexType>

Gunduz, et al.              Standards Track                    [Page 23]

RFC 4698               IRIS Address Registry Type           October 2006

Gunduz, et al. Standards Track [Page 23] RFC 4698 IRIS Address Registry Type October 2006

     <element name="findNetworksByNameServer"
       type="areg:findNetworksByNameServerType"
       substitutionGroup="iris:query" />

     <!--                                           -->
     <!-- Contact Search Group                      -->
     <!--                                           -->

     <group name="contactSearchGroup">
       <choice>
         <element name="commonName"
           type="areg:exactOrPartialMatchParameter" />
         <group ref="areg:commonSearchGroup" />
       </choice>
     </group>

     <!--                                           -->
     <!-- Common Search Group                       -->
     <!--                                           -->

     <group name="commonSearchGroup">
       <choice>
         <element name="eMail" type="areg:domainResourceParameter" />
         <element name="city" type="areg:exactMatchParameter" />
         <element name="region" type="areg:exactMatchParameter" />
         <element name="country" type="areg:exactMatchParameter" />
         <element name="postalCode" type="areg:exactMatchParameter" />
       </choice>
     </group>

     <!--                                           -->
     <!-- Parameters for Search Groups              -->
     <!--                                           -->

     <complexType name="exactOrPartialMatchParameter">
       <choice>
         <group ref="areg:partialMatchGroup" />
         <group ref="areg:exactMatchGroup" />
       </choice>
     </complexType>

     <complexType name="exactMatchParameter">
       <group ref="areg:exactMatchGroup" />
     </complexType>

     <complexType name="partialMatchParameter">
       <sequence>
         <group ref="areg:partialMatchGroup" />

Gunduz, et al.              Standards Track                    [Page 24]

RFC 4698               IRIS Address Registry Type           October 2006

Gunduz, et al. Standards Track [Page 24] RFC 4698 IRIS Address Registry Type October 2006

       </sequence>
     </complexType>

</sequence> </complexType>

     <complexType name="domainResourceParameter" >
       <choice>
         <group ref="areg:exactMatchGroup" />
         <element name="inDomain" type="token" />
       </choice>
     </complexType>

     <group name="partialMatchGroup">
       <choice>
         <sequence>
           <element name="beginsWith">
             <simpleType>
               <restriction base="token">
                 <minLength value="1"/>
               </restriction>
             </simpleType>
           </element>
           <element minOccurs="0" ref="areg:endsWith"/>
         </sequence>
         <element ref="areg:endsWith" />
       </choice>
     </group>

     <element name="endsWith">
       <simpleType>
         <restriction base="token">
           <minLength value="1"/>
         </restriction>
       </simpleType>
     </element>

     <group name="exactMatchGroup">
       <sequence>
         <element name="exactMatch" type="normalizedString" />
       </sequence>
     </group>

     <!-- ========================================= -->
     <!--                                           -->
     <!-- Result Types                              -->
     <!--                                           -->
     <!-- ========================================= -->

     <!--                                           -->
     <!-- IPv4 and IPv6 Network Results             -->

Gunduz, et al.              Standards Track                    [Page 25]

RFC 4698               IRIS Address Registry Type           October 2006

Gunduz, et al. Standards Track [Page 25] RFC 4698 IRIS Address Registry Type October 2006

     <!--                                           -->

     <complexType name="ipNetworkType">
       <complexContent>
         <extension base="iris:resultType">
           <sequence>
             <element name="networkHandle" type="token"
               minOccurs="0" maxOccurs="1" />
             <element name="name" minOccurs="0" maxOccurs="1"
               type="normalizedString" />
             <element name="startAddress" type="token" />
             <element name="endAddress" type="token" />
             <sequence minOccurs="0" maxOccurs="1">
               <element name="networkType" type="normalizedString"
                 minOccurs="1" maxOccurs="1" />
               <element name="networkTypeInfo" type="iris:entityType"
                 minOccurs="0" maxOccurs="1" />
             </sequence>
             <element name="nameServer" type="normalizedString"
               minOccurs="0" maxOccurs="unbounded" />
             <element name="organization" type="iris:entityType"
               minOccurs="0" maxOccurs="1" />
             <choice minOccurs="0" maxOccurs="1" >
               <element name="parent" type="iris:entityType" />
               <element name="noParent">
               </element>
             </choice>
             <group ref="areg:contactGroup" />
             <group ref="areg:commonGroup" />
           </sequence>
         </extension>
       </complexContent>
     </complexType>

     <element name="ipv4Network" type="areg:ipNetworkType"
       substitutionGroup="iris:result" />

     <element name="ipv6Network" type="areg:ipNetworkType"
       substitutionGroup="iris:result" />

     <!--                                           -->
     <!-- Autonomous System                         -->
     <!--                                           -->

     <complexType name="autonomousSystemType">
       <complexContent>
         <extension base="iris:resultType">
           <sequence>

Gunduz, et al.              Standards Track                    [Page 26]

RFC 4698               IRIS Address Registry Type           October 2006

Gunduz, et al. Standards Track [Page 26] RFC 4698 IRIS Address Registry Type October 2006

             <element name="asHandle" type="token"
               minOccurs="0" maxOccurs="1" />
             <element name="asNumberStart" type="integer" minOccurs="0"
               maxOccurs="1" />
             <element name="asNumberEnd" type="integer" minOccurs="0"
               maxOccurs="1" />
             <element name="name" type="normalizedString" minOccurs="0"
               maxOccurs="1" />
             <element name="organization" type="iris:entityType"
               minOccurs="0" maxOccurs="1" />
             <choice minOccurs="0" maxOccurs="1">
               <element name="parent" type="iris:entityType" />
               <element name="noParent" />
             </choice>
             <group ref="areg:contactGroup" />
             <group ref="areg:commonGroup" />
           </sequence>
         </extension>
       </complexContent>
     </complexType>

     <element name="autonomousSystem" type="areg:autonomousSystemType"
       substitutionGroup="iris:result" />

     <!--                                           -->
     <!-- Contact                                   -->
     <!--                                           -->

     <complexType name="contactType">
       <complexContent>
         <extension base="iris:resultType">
           <sequence>
             <element name="contactHandle" type="token"
               minOccurs="0" maxOccurs="1" />
             <element name="commonName" type="normalizedString"
               minOccurs="0" maxOccurs="1" />
             <element name="eMail" type="normalizedString" minOccurs="0"
               maxOccurs="unbounded" />
             <element name="sip" type="normalizedString" minOccurs="0"
               maxOccurs="unbounded" />
             <element name="organization" type="iris:entityType"
               minOccurs="0" maxOccurs="unbounded" />
             <element name="postalAddress" minOccurs="0"
               maxOccurs="unbounded">
               <complexType>
                 <sequence>
                   <element name="address" type="string" minOccurs="0"
                     maxOccurs="1" />

Gunduz, et al.              Standards Track                    [Page 27]

RFC 4698               IRIS Address Registry Type           October 2006

Gunduz, et al. Standards Track [Page 27] RFC 4698 IRIS Address Registry Type October 2006

                   <element name="city" type="string" minOccurs="0"
                     maxOccurs="1" />
                   <element name="region" type="string" minOccurs="0"
                     maxOccurs="1" />
                   <element name="postalCode" type="normalizedString"
                     minOccurs="0" maxOccurs="1" />
                   <element name="country" type="token" minOccurs="0"
                     maxOccurs="1" />
                 </sequence>
               </complexType>
             </element>
             <element name="phone" minOccurs="0" maxOccurs="unbounded" >
               <complexType>
                 <sequence>
                   <element name="number" type="normalizedString" />
                   <element name="extension" type="normalizedString"
                     minOccurs="0" maxOccurs="unbounded" />
                   <element name="type" type="normalizedString"
                     minOccurs="0" maxOccurs="1" />
                 </sequence>
               </complexType>
             </element>
             <group ref="areg:commonGroup" />
           </sequence>
         </extension>
       </complexContent>
     </complexType>

     <element name="contact" type="areg:contactType"
       substitutionGroup="iris:result" />

     <!--                                           -->
     <!-- Organization                              -->
     <!--                                           -->

     <complexType name="organizationType">
       <complexContent>
         <extension base="iris:resultType">
           <sequence>
             <element name="name" type="normalizedString"
               minOccurs="0" maxOccurs="1" />
             <element name="eMail" type="normalizedString" minOccurs="0"
               maxOccurs="unbounded" />
             <element name="id" type="token" />
             <element name="postalAddress" minOccurs="0"
               maxOccurs="unbounded">
               <complexType>
                 <sequence>

Gunduz, et al.              Standards Track                    [Page 28]

RFC 4698               IRIS Address Registry Type           October 2006

Gunduz, et al. Standards Track [Page 28] RFC 4698 IRIS Address Registry Type October 2006

                   <element name="address" type="string" minOccurs="0"
                     maxOccurs="1" />
                   <element name="city" type="string" minOccurs="0"
                     maxOccurs="1" />
                   <element name="region" type="string" minOccurs="0"
                     maxOccurs="1" />
                   <element name="postalCode" type="normalizedString"
                     minOccurs="0" maxOccurs="1" />
                   <element name="country" type="token" minOccurs="0"
                     maxOccurs="1" />
                 </sequence>
               </complexType>
             </element>
             <element name="phone" minOccurs="0" maxOccurs="unbounded" >
               <complexType>
                 <sequence>
                   <element name="number" type="normalizedString" />
                   <element name="extension" type="normalizedString"
                     minOccurs="0" maxOccurs="unbounded" />
                   <element name="type" type="normalizedString"
                     minOccurs="0" maxOccurs="1" />
                 </sequence>
               </complexType>
             </element>
             <group ref="areg:contactGroup" />
             <group ref="areg:commonGroup" />
           </sequence>
         </extension>
       </complexContent>
     </complexType>

     <element name="organization" type="areg:organizationType"
       substitutionGroup="iris:result" />

     <!--                                           -->
     <!-- Contact Group                             -->
     <!--                                           -->

     <group name="contactGroup">
       <sequence>
         <element name="adminContact" type="iris:entityType"
           minOccurs="0" maxOccurs="unbounded" />
         <element name="techContact" type="iris:entityType"
           minOccurs="0" maxOccurs="unbounded" />
         <element name="nocContact" type="iris:entityType" minOccurs="0"
           maxOccurs="unbounded" />
         <element name="abuseContact" type="iris:entityType"
           minOccurs="0" maxOccurs="unbounded" />

Gunduz, et al.              Standards Track                    [Page 29]

RFC 4698               IRIS Address Registry Type           October 2006

Gunduz, et al. Standards Track [Page 29] RFC 4698 IRIS Address Registry Type October 2006

         <element name="otherContact" type="iris:entityType"
           minOccurs="0" maxOccurs="unbounded" />
       </sequence>
     </group>

     <!--                                           -->
     <!-- Common Group                              -->
     <!--                                           -->

     <group name="commonGroup">
       <sequence>
         <element name="numberResourceRegistry" type="iris:entityType"
           minOccurs="0" maxOccurs="1" />
         <element name="registrationDate" type="dateTime" minOccurs="0"
           maxOccurs="1" />
         <element name="lastUpdatedDate" type="dateTime" minOccurs="0"
           maxOccurs="1" />
         <element ref="iris:seeAlso" minOccurs="0" maxOccurs="unbounded"
           />
       </sequence>
     </group>
   </schema>

                                 Figure 9

Figure 9

Gunduz, et al.              Standards Track                    [Page 30]

RFC 4698               IRIS Address Registry Type           October 2006

Gunduz, et al. Standards Track [Page 30] RFC 4698 IRIS Address Registry Type October 2006

6.  BEEP Transport Compliance

6. BEEP Transport Compliance

   IRIS allows several extensions of the core capabilities.  This
   section outlines those extensions allowable by IRIS-BEEP [3].

IRIS allows several extensions of the core capabilities. This section outlines those extensions allowable by IRIS-BEEP [3].

6.1.  Message Pattern

6.1. Message Pattern

   This registry type uses the default message pattern as described in
   IRIS-BEEP [3].

This registry type uses the default message pattern as described in IRIS-BEEP [3].

6.2.  Server Authentication

6.2. Server Authentication

   This registry type uses the default server authentication method as
   described in IRIS-BEEP [3].

This registry type uses the default server authentication method as described in IRIS-BEEP [3].

7.  URI Resolution

7. URI Resolution

7.1.  Application Service Label

7.1. Application Service Label

   See Section 9 for the application service label registration.

See Section 9 for the application service label registration.

7.2.  Operational Considerations

7.2. Operational Considerations

   Address registries do not have natural links to DNS.  Using reverse
   DNS tree presents problems for IP address delegation (for example,
   delegations do not fall into byte boundaries, unlike reverse DNS),
   and DNS does not currently contain any information regarding
   autonomous system delegation.

Address registries do not have natural links to DNS. Using reverse DNS tree presents problems for IP address delegation (for example, delegations do not fall into byte boundaries, unlike reverse DNS), and DNS does not currently contain any information regarding autonomous system delegation.

   Therefore, in order for the top-down resolution to operate properly,
   it is requested that the IAB instruct IANA to insert and maintain a
   NAPTR DNS resource record for areg.iris.arpa, as described in
   Section 9.

Therefore, in order for the top-down resolution to operate properly, it is requested that the IAB instruct IANA to insert and maintain a NAPTR DNS resource record for areg.iris.arpa, as described in Section 9.

7.3.  Top-Down Resolution

7.3. Top-Down Resolution

   The top-down alternative resolution method MUST be identified as
   'top' in IRIS URIs.

The top-down alternative resolution method MUST be identified as 'top' in IRIS URIs.

   The process for this condition is as follows:

The process for this condition is as follows:

   1.  The IRIS [2] direct-resolution process is tried against
       areg.iris.arpa.

1. The IRIS [2] direct-resolution process is tried against areg.iris.arpa.

   2.  If the direct-resolution process yields no server for which a
       connection can be made, then a negative response is returned, and
       no further action is taken.

2. If the direct-resolution process yields no server for which a connection can be made, then a negative response is returned, and no further action is taken.

Gunduz, et al.              Standards Track                    [Page 31]

RFC 4698               IRIS Address Registry Type           October 2006

Gunduz, et al. Standards Track [Page 31] RFC 4698 IRIS Address Registry Type October 2006

   It is RECOMMENDED that IRIS clients issuing AREG1 requests use the
   'top' resolution method when no resolution method has been explicitly
   given by a user.  IRIS servers accepting AREG1 requests that seek
   information for which they are not authoritative SHOULD refer clients
   using the 'top' resolution method.

It is RECOMMENDED that IRIS clients issuing AREG1 requests use the 'top' resolution method when no resolution method has been explicitly given by a user. IRIS servers accepting AREG1 requests that seek information for which they are not authoritative SHOULD refer clients using the 'top' resolution method.

8.  Internationalization Considerations

8. Internationalization Considerations

   This document lays out no new considerations for internationalization
   beyond those specified in IRIS [2].

This document lays out no new considerations for internationalization beyond those specified in IRIS [2].

9.  IANA Considerations

9. IANA Considerations

   The following URN has been registered with IANA according to the IANA
   considerations defined in IRIS [2]:

The following URN has been registered with IANA according to the IANA considerations defined in IRIS [2]:

      urn:ietf:params:xml:ns:areg1

urn:ietf:params:xml:ns:areg1

   The following S-NAPTR application service label has been registered
   with IANA according to the IANA considerations defined in IRIS [2]:

The following S-NAPTR application service label has been registered with IANA according to the IANA considerations defined in IRIS [2]:

      AREG1

AREG1

   Under instructions from the IAB, the IANA will create a new second
   level domain under .arpa called iris (i.e., iris.arpa.).  The
   contents of this new domain are to be under the control of the IAB.
   Under instructions from the IAB, the IANA will insert and maintain a
   NAPTR DNS resource record in the iris.arpa. domain for the name
   areg.iris.arpa.  The initial contents for that record is:

Under instructions from the IAB, the IANA will create a new second level domain under .arpa called iris (i.e., iris.arpa.). The contents of this new domain are to be under the control of the IAB. Under instructions from the IAB, the IANA will insert and maintain a NAPTR DNS resource record in the iris.arpa. domain for the name areg.iris.arpa. The initial contents for that record is:

   areg.iris.arpa.
   ;;        order pref flags service                   re replacement
   IN NAPTR  100   10   ""    "AREG1:iris.xpc:iris.lwz" "" areg.nro.net

areg.iris.arpa. ;; order pref flags service re replacement IN NAPTR 100 10 "" "AREG1:iris.xpc:iris.lwz" "" areg.nro.net

10.  Security Considerations

10. Security Considerations

   This document lays out no new considerations for security precautions
   beyond those specified in IRIS [2].

This document lays out no new considerations for security precautions beyond those specified in IRIS [2].

Gunduz, et al.              Standards Track                    [Page 32]

RFC 4698               IRIS Address Registry Type           October 2006

Gunduz, et al. Standards Track [Page 32] RFC 4698 IRIS Address Registry Type October 2006

11.  References

11. References

11.1.  Normative References

11.1. Normative References

   [1]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
        Levels", BCP 14, RFC 2119, March 1997.

[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.

   [2]  Newton, A. and M. Sanz, "IRIS: The Internet Registry Information
        Service (IRIS) Core Protocol", RFC 3981, January 2005.

[2] Newton, A. and M. Sanz, "IRIS: The Internet Registry Information Service (IRIS) Core Protocol", RFC 3981, January 2005.

   [3]  Newton, A. and M. Sanz, "Using the Internet Registry Information
        Service (IRIS) over the Blocks Extensible Exchange Protocol
        (BEEP)", RFC 3983, January 2005.

[3] Newton, A. and M. Sanz, "Using the Internet Registry Information Service (IRIS) over the Blocks Extensible Exchange Protocol (BEEP)", RFC 3983, January 2005.

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

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

11.2.  Informative References

11.2. Informative References

   [5]  World Wide Web Consortium, "Extensible Markup Language (XML)
        1.0", W3C XML, February 1998,
        <http://www.w3.org/TR/1998/REC-xml-19980210>.

[5] World Wide Web Consortium, "Extensible Markup Language (XML) 1.0", W3C XML, February 1998, <http://www.w3.org/TR/1998/REC-xml-19980210>.

   [6]  World Wide Web Consortium, "Namespaces in XML", W3C XML
        Namespaces, January 1999,
        <http://www.w3.org/TR/1999/REC-xml-names-19990114>.

[6] World Wide Web Consortium, "Namespaces in XML", W3C XML Namespaces, January 1999, <http://www.w3.org/TR/1999/REC-xml-names-19990114>.

   [7]  World Wide Web Consortium, "XML Schema Part 2: Datatypes",
        W3C XML Schema, October 2000,
        <http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/>.

[7] World Wide Web Consortium, "XML Schema Part 2: Datatypes", W3C XML Schema, October 2000, <http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/>.

   [8]  World Wide Web Consortium, "XML Schema Part 1: Structures",
        W3C XML Schema, October 2000,
        <http://www.w3.org/TR/2001/REC-xmlschema-1-20010502/>.

[8] World Wide Web Consortium, "XML Schema Part 1: Structures", W3C XML Schema, October 2000, <http://www.w3.org/TR/2001/REC-xmlschema-1-20010502/>.

   [9]  International Organization for Standardization, "Codes for the
        representation of names of countries, 3rd edition", ISO Standard
        3166, August 1988.

[9] International Organization for Standardization, "Codes for the representation of names of countries, 3rd edition", ISO Standard 3166, August 1988.

Gunduz, et al.              Standards Track                    [Page 33]

RFC 4698               IRIS Address Registry Type           October 2006

Gunduz, et al. Standards Track [Page 33] RFC 4698 IRIS Address Registry Type October 2006

Appendix A.  Privacy Considerations

Appendix A. Privacy Considerations

   Internet address registries store contact details and other
   information that may be abused.  The XML Schema defined in this
   document purposefully makes the inclusion of any data in a response
   an option that is dependent on the needs and policies of the Internet
   address registry serving the data.

Internet address registries store contact details and other information that may be abused. The XML Schema defined in this document purposefully makes the inclusion of any data in a response an option that is dependent on the needs and policies of the Internet address registry serving the data.

   Combined with the authentication mechanisms of an IRIS transfer
   protocol, Internet address registries may derive authorization
   policies to meet their needs without compromising general privacy
   policies.  As an example, the constituents of an Internet address
   registry may create a policy whereby NOC contact email addresses are
   only to be available to members of the Internet address registry.  To
   institute this policy, the XML elements for NOC contacts will never
   appear in a response to a user that has not been authenticated to be
   a member of the Internet address registry.

IRIS転送プロトコルの認証機構に結合されています、インターネット・アドレス登録は一般的なプライバシーに関する方針で妥協しないで彼らの需要を満たすために認可方針を引き出すかもしれません。例として、インターネット・アドレス登録の成分はインターネット・アドレス登録のメンバーには単に利用可能であるNOC連絡Eメールアドレスがことである方針を作成するかもしれません。 NOCのためにこの方針、XML要素を設けるために、接触はインターネット・アドレス登録のメンバーになるように認証されていないユーザへの応答に決して現れないでしょう。

Appendix B.  Example Requests and Responses

付録B.例の要求と応答

   The examples in this section use the string "C:" to denote data sent
   by a client to a server and the string "S:" to denote data sent by a
   server to a client.

このセクションの例がストリングを使用する、「C:」クライアントによってサーバとストリングに送られたデータを指示する、「S:」サーバによってクライアントに送られたデータを指示するために。

B.1.  Example 1

B.1。例1

   The following is an example of entity lookup for the contact-handle
   of 'JN560-RIR1'.

↓これは'JN560-RIR1'の接触ハンドルのための実体ルックアップに関する例です。

   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:   xsi:schemaLocation="urn:ietf:params:xml:ns:iris1 iris.xsd" >
   C:
   C:   <searchSet>
   C:
   C:     <lookupEntity
   C:       registryType="urn:ietf:params:xml:ns:areg1"
   C:       entityClass="contact-handle"
   C:       entityName="JN560-RIR1" />
   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と等しいです: xsi: schemaLocationは「つぼ:ietf:params:xml:ナノ秒: iris1 iris.xsd」>Cと等しいです: C: <searchSet>C: C: <lookupEntity C: registryTypeが等しい、「つぼ:ietf:params: xml:ナノ秒:areg1"C:、」 entityClassは「接触ハンドル」Cと等しいです: entityNameが等しい、「JN560-RIR1"/>C:」 C: </searchSet>C: C: </要求>。

   S: <?xml version="1.0"?>
   S: <iris:response
   S:   xmlns:iris="urn:ietf:params:xml:ns:iris1"

S: <?xmlバージョン= 「1インチ?」>S: <虹彩: 応答S: xmlns: 虹彩=「つぼ:ietf:params:xml:ナノ秒: iris1"」

Gunduz, et al.              Standards Track                    [Page 34]

RFC 4698               IRIS Address Registry Type           October 2006

Gunduz、他規格は虹彩アドレス登録タイプ2006年10月にRFC4698を追跡します[34ページ]。

   S:   xmlns="urn:ietf:params:xml:ns:areg1"
   S:   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
   S:
   S:   <iris:resultSet>
   S:     <iris:answer>
   S:
   S:       <contact
   S:         authority="rir.example.net"
   S:         registryType="areg1"
   S:         entityClass="contact-handle"
   S:         entityName="JN560-RIR1">
   S:
   S:         <contactHandle>JN560-RIR1</contactHandle>
   S:
   S:         <commonName>Bob Smurd</commonName>
   S:
   S:         <organization
   S:           iris:referentType="organization"
   S:           authority="rir.example.net"
   S:           registryType="areg1"
   S:           entityClass="organization-id"
   S:           entityName="ORGX">
   S:           <iris:displayName
   S:             language="en">
   S:             Organization X, Inc.
   S:           </iris:displayName>
   S:         </organization>
   S:
   S:         <phone>
   S:           <number>+1-703-555-5555</number>
   S:           <type>office</type>
   S:         </phone>
   S:
   S:       </contact>
   S:
   S:     </iris:answer>
   S:   </iris:resultSet>
   S:
   S: </iris:response>

S: xmlnsが等しい、「つぼ:ietf:params:xml:ナノ秒: areg1" S:、」 xmlns: xsiが等しい、「 http://www.w3.org/2001/XMLSchema-instance 、「>S:」 S: <虹彩: resultSet>S: <虹彩: >Sに答えてください: S: <接触S: 権威は"rir.example.net"Sと等しいです: registryTypeが等しい、「areg1" S:」 entityClassは「接触ハンドル」Sと等しいです: entityNameが等しい、「JN560-RIR1">S:」 S: <contactHandle>JN560-RIR1</contactHandle>S: S: <commonName>ボブSmurd</commonName>S: S: <組織S: 虹彩: referentTypeは「組織」Sと等しいです: 権威は"rir.example.net"Sと等しいです: registryTypeが等しい、「areg1" S:」 entityClassは「組織イド」Sと等しいです: entityNameが等しい、「ORGX、「>S:」 <虹彩: displayName S: 言語が等しい、「アン、「>S:」組織X Inc.S: </虹彩: displayName>S: </組織>S: S: <電話>S: <数の>+1-703-555-5555</番号>S: <タイプ>オフィス</タイプ>S: </電話>S: S: </接触>S: S: </虹彩: >Sに答えてください: </虹彩: resultSet>S: S: </虹彩: 応答>。

                           Figure 11: Example 1

図11: 例1

Gunduz, et al.              Standards Track                    [Page 35]

RFC 4698               IRIS Address Registry Type           October 2006

Gunduz、他規格は虹彩アドレス登録タイプ2006年10月にRFC4698を追跡します[35ページ]。

B.2.  Example 2

B.2。例2

   The following example shows a query to find the IP networks
   containing a given address.

以下の例は、与えられたアドレスを含むIPネットワークを見つけるために質問を示しています。

   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:     <findNetworksByAddress
   C:       xmlns="urn:ietf:params:xml:ns:areg1">
   C:
   C:       <ipv4Address>
   C:         <start>192.0.2.134</start>
   C:       </ipv4Address>
   C:
   C:       <specificity
   C:         allowEquivalences="true"
   C:         >one-level-less-specific</specificity>
   C:
   C:     </findNetworksByAddress>
   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: <searchSet>C: <findNetworksByAddress C: xmlnsが等しい、「つぼ:ietf:params: xml:ナノ秒:areg1">C:、」 C: <ipv4Address>C: <スタート>192.0.2.134</スタート>C: </ipv4Address>C: C: <の特異性C: allowEquivalencesは「本当」のCと等しいです: >1レベルなしに特定の</特異性>C: C: </findNetworksByAddress>C: </searchSet>C: C: </要求>。

   S: <?xml version="1.0"?>
   S: <iris:response xmlns:iris="urn:ietf:params:xml:ns:iris1"
   S:   xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
   S:
   S:   <iris:resultSet>
   S:     <iris:answer>
   S:       <areg:ipv4Network
   S:         xmlns="urn:ietf:params:xml:ns:areg1"
   S:         xmlns:areg="urn:ietf:params:xml:ns:areg1"
   S:         xsi:schemaLocation="urn:ietf:params:xml:ns:areg1 areg.xsd"
   S:         authority="rir.example.net" registryType="areg1"
   S:         entityClass="ipv4-handle" entityName="NET-192-0-2-128-1" >
   S:         <networkHandle>
   S:           NET-192-0-2-128-1
   S:         </networkHandle>
   S:         <name>
   S:           UU-192-0-2-D6
   S:         </name>
   S:         <startAddress>
   S:           192.0.2.128
   S:         </startAddress>
   S:         <endAddress>

S: <?xmlバージョン= 「1インチ?」>S: <虹彩: 応答xmlns: 虹彩=、「つぼ:ietf:params: xml:ナノ秒:iris1"S:、」 xmlns: xsiが等しい、「 http://www.w3.org/2001/XMLSchema-instance 、「>S:」 S: <虹彩: resultSet>S: <虹彩: >Sに答えてください: <areg: ipv4Network S: xmlnsが等しい、「つぼ:ietf:params:xml:ナノ秒: areg1" S:、」 xmlns: aregが等しい、「つぼ:ietf:params:xml:ナノ秒: areg1" S:、」 xsi: schemaLocationは「つぼ:ietf:params:xml:ナノ秒: areg1 areg.xsd」Sと等しいです: "rir.example.net"権威=registryTypeが等しい、「areg1" S:」 entityClassが「ipv4-ハンドル」entityNameと等しい、= 「>Sを192-0-2-128 何1インチも網で覆ってください」 <networkHandle>S: 1秒間のネット192-0-2-128: </networkHandle>S: <名前>S: UU-192-0-2-D6 S: </名前>S: <startAddress>S: 192.0.2 .128秒間: </startAddress>S: <endAddress>。

Gunduz, et al.              Standards Track                    [Page 36]

RFC 4698               IRIS Address Registry Type           October 2006

Gunduz、他規格は虹彩アドレス登録タイプ2006年10月にRFC4698を追跡します[36ページ]。

   S:           192.0.2.255
   S:         </endAddress>
   S:         <networkType>reassigned</networkType>
   S:         <organization
   S:           iris:referentType="areg:organization"
   S:           authority="rir.example.net" registryType="areg1"
   S:           entityClass="organization-id" entityName="ORGX">
   S:           <iris:displayName language="en">
   S:             Organization X, Inc.
   S:           </iris:displayName>
   S:         </organization>
   S:         <parent
   S:           iris:referentType="areg:ipv4Network"
   S:           authority="rir.example.net" registryType="areg1"
   S:           entityClass="ipv4-handle" entityName="NET-192-0-2-0-1"/>
   S:         <techContact
   S:           iris:referentType="areg:contact"
   S:           authority="rir.example.net" registryType="areg1"
   S:           entityClass="contact-handle" entityName="JN560-RIR1">
   S:           <iris:displayName language="en">
   S:             Smurd, Bob
   S:           </iris:displayName>
   S:         </techContact>
   S:         <registrationDate>
   S:           2002-11-18T00:00:00-00:00
   S:         </registrationDate>
   S:         <lastUpdatedDate>
   S:           2002-11-18T00:00:00-00:00
   S:         </lastUpdatedDate>
   S:         <iris:seeAlso
   S:           iris:referentType="ANY"
   S:           authority="rir.example.net" registryType="areg1"
   S:           entityClass="local" entityName="portability-notice"/>
   S:       </areg:ipv4Network>
   S:       <areg:ipv4Network
   S:         xmlns="urn:ietf:params:xml:ns:areg1"
   S:         xmlns:areg="urn:ietf:params:xml:ns:areg1"
   S:         xsi:schemaLocation="urn:ietf:params:xml:ns:areg1 areg.xsd"
   S:         authority="rir.example.net" registryType="areg1"
   S:         entityClass="ipv4-handle" entityName="NET-192-0-2-0-2" >
   S:         <networkHandle>
   S:           NET-192-0-2-0-2
   S:         </networkHandle>
   S:         <name>
   S:           UU-192-0-2-0-D5
   S:         </name>
   S:         <startAddress>
   S:           192.0.2.0

S: 192.0.2 .255秒間: </endAddress>S: <networkType>は</networkType>Sを再選任しました: <組織S: 虹彩: referentType=が「: 組織をaregする」というS: "rir.example.net"権威=registryTypeが等しい、「areg1" S:」 entityClassが「組織イド」entityName=と等しい、「ORGX、「>S:」 <虹彩: displayName言語が等しい、「アン、「>S:」組織X Inc.S: </虹彩: displayName>S: </組織>S: <親S: 虹彩: referentTypeは「areg: ipv4Network」Sと等しいです: "rir.example.net"権威=registryTypeが等しい、「areg1" S:」 entityClassが「ipv4-ハンドル」entityNameと等しい、= 「>Sを/に192-0-2-0 何1インチも網で覆ってください」 <techContact S: 虹彩: referentType=が「: 接触をaregする」というS: "rir.example.net"権威=registryTypeが等しい、「areg1" S:」 entityClassが「接触ハンドル」entityName=と等しい、「JN560-RIR1">S:」 <虹彩: displayName言語が等しい、「アン、「>S:」 Smurd、ボブS: </虹彩: displayName>S: </techContact>S: <registrationDate>S: 2002-11-18 T00: 0時0分から0時0分S: </registrationDate>S: <lastUpdatedDate>S: 2002-11-18 T00: 0時0分から0時0分S: </lastUpdatedDate>S: <虹彩: seeAlso S: 虹彩: referentTypeは「ANY」のSと等しいです: "rir.example.net"権威=registryTypeが等しい、「areg1" S:」「地方」のentityClass=entityNameは「携帯性通知」/>Sと等しいです: </areg: ipv4Network>S: <areg: ipv4Network S: xmlnsが等しい、「つぼ:ietf:params:xml:ナノ秒: areg1" S:、」 xmlns: aregが等しい、「つぼ:ietf:params:xml:ナノ秒: areg1" S:、」 xsi: schemaLocationは「つぼ:ietf:params:xml:ナノ秒: areg1 areg.xsd」Sと等しいです: "rir.example.net"権威=registryTypeが等しい、「areg1" S:」 entityClassが「ipv4-ハンドル」entityNameと等しい、= 「>Sを192-0-2-0 何2インチも網で覆ってください」 <networkHandle>S: 2秒間のネット192-0-2-0: </networkHandle>S: <名前>S: UU-192-0-2-0-D5 S: </名前>S: <startAddress>S: 192.0.2.0

Gunduz, et al.              Standards Track                    [Page 37]

RFC 4698               IRIS Address Registry Type           October 2006

Gunduz、他規格は虹彩アドレス登録タイプ2006年10月にRFC4698を追跡します[37ページ]。

   S:         </startAddress>
   S:         <endAddress>
   S:           192.0.2.255
   S:         </endAddress>
   S:         <networkType>direct allocation</networkType>
   S:         <nameServer>auth03.ns.example.org</nameServer>
   S:         <nameServer>auth00.ns.example.org</nameServer>
   S:         <organization
   S:           iris:referentType="areg:organization"
   S:           authority="rir.example.net" registryType="areg1"
   S:           entityClass="organization-id" entityName="ORGY">
   S:           <iris:displayName language="en">
   S:             Organization Y, Inc.
   S:           </iris:displayName>
   S:         </organization>
   S:         <parent
   S:           iris:referentType="areg:ipv4Network"
   S:           authority="rir.example.net" registryType="areg1"
   S:           entityClass="ipv4-handle" entityName="NET-192-0-2-0-1"/>
   S:         <techContact
   S:           iris:referentType="areg:contact"
   S:           authority="rir.example.net" registryType="areg1"
   S:           entityClass="contact-handle" entityName="OA12-RIR1" />
   S:         <registrationDate>
   S:           2000-10-27T00:00:00-00:00
   S:         </registrationDate>
   S:         <lastUpdatedDate>
   S:           2002-02-13T00:00:00-00:00
   S:         </lastUpdatedDate>
   S:         <iris:seeAlso
   S:           iris:referentType="ANY"
   S:           authority="rir.example.net" registryType="areg1"
   S:           entityClass="local" entityName="portability-notice"/>
   S:       </areg:ipv4Network>
   S:     </iris:answer>
   S:     <iris:additional>
   S:       <iris:simpleEntity
   S:         authority="rir.example.net" registryType="areg1"
   S:         entityClass="local" entityName="portability-notice" >
   S:         <iris:property name="portability" language="en">
   S:           Addresses within this block are non-portable.
   S:         </iris:property>

S: </startAddress>S: <endAddress>S: 192.0.2 .255秒間: </endAddress>S: <networkType>直接アロケーション</networkType>S: <ネームサーバ>auth03.ns.example.org</ネームサーバ>S: <ネームサーバ>auth00.ns.example.org</ネームサーバ>S: <組織S: 虹彩: referentType=が「: 組織をaregする」というS: "rir.example.net"権威=registryTypeが等しい、「areg1" S:」 entityClassが「組織イド」entityName=と等しい、「乱交パーティ、「>S:」 <虹彩: displayName言語が等しい、「アン、「>S:」組織Y Inc.S: </虹彩: displayName>S: </組織>S: <親S: 虹彩: referentTypeは「areg: ipv4Network」Sと等しいです: "rir.example.net"権威=registryTypeが等しい、「areg1" S:」 entityClassが「ipv4-ハンドル」entityNameと等しい、= 「>Sを/に192-0-2-0 何1インチも網で覆ってください」 <techContact S: 虹彩: referentType=が「: 接触をaregする」というS: "rir.example.net"権威=registryTypeが等しい、「areg1" S:」 entityClassが「接触ハンドル」entityName=と等しい、「OA12-RIR1"/>S:」 <registrationDate>S: 2000-10-27 T00: 0時0分から0時0分S: </registrationDate>S: <lastUpdatedDate>S: 2002-02-13 T00: 0時0分から0時0分S: </lastUpdatedDate>S: <虹彩: seeAlso S: 虹彩: referentTypeは「ANY」のSと等しいです: "rir.example.net"権威=registryTypeが等しい、「areg1" S:」「地方」のentityClass=entityNameは「携帯性通知」/>Sと等しいです: </areg: ipv4Network>S: </虹彩: >Sに答えてください: <虹彩: 追加>S: <虹彩: simpleEntity S: "rir.example.net"権威=registryTypeが等しい、「areg1" S:」「地方」のentityClass=entityNameは「携帯性通知」>Sと等しいです: <虹彩: 特性名前=「携帯性」言語が等しい、「アン、「>S:」このブロックの中のアドレスは非携帯用です。 S: </虹彩: 特性の>。

Gunduz, et al.              Standards Track                    [Page 38]

RFC 4698               IRIS Address Registry Type           October 2006

Gunduz、他規格は虹彩アドレス登録タイプ2006年10月にRFC4698を追跡します[38ページ]。

   S:       </iris:simpleEntity>
   S:     </iris:additional>
   S:   </iris:resultSet>
   S:
   S: </iris:response>

S: </虹彩: simpleEntity>S: </虹彩: 追加>S: </虹彩: resultSet>S: S: </虹彩: 応答>。

                           Figure 12: Example 2

図12: 例2

Appendix C.  Specificity Examples

付録C.特異性の例

   This section includes examples to clarify specificity options for
   network and ASN searches.

このセクションはネットワークのために特異性オプションをはっきりさせるために例を含んでいます、そして、ASNは探します。

   A    |------------------|                     192.0.2.0  - 192.0.2.15

A|------------------| 192.0.2.0 - 192.0.2.15

   B                        |------------------| 192.0.2.16 - 192.0.2.31

B|------------------| 192.0.2.16 - 192.0.2.31

   C    |--------------|                         192.0.2.0  - 192.0.2.9

C|--------------| 192.0.2.0 - 192.0.2.9

   D                        |---------------|    192.0.2.16 - 192.0.2.30

D|---------------| 192.0.2.16 - 192.0.2.30

   E                        |---------------|    192.0.2.16 - 192.0.2.30

E|---------------| 192.0.2.16 - 192.0.2.30

   F    |--------|                               192.0.2.0  - 192.0.2.5

F|--------| 192.0.2.0 - 192.0.2.5

   G              |----|                         192.0.2.6  - 192.0.2.9

G|----| 192.0.2.6 - 192.0.2.9

                        Contents of the DB

DBのコンテンツ

                     Figure 13: Specificity Example 1

図13: 特異性の例1

Gunduz, et al.              Standards Track                    [Page 39]

RFC 4698               IRIS Address Registry Type           October 2006

Gunduz、他規格は虹彩アドレス登録タイプ2006年10月にRFC4698を追跡します[39ページ]。

   A    |------------------|                     192.0.2.0  - 192.0.2.15

A|------------------| 192.0.2.0 - 192.0.2.15

   B                        |------------------| 192.0.2.16 - 192.0.2.31

B|------------------| 192.0.2.16 - 192.0.2.31

   C    |--------------|                         192.0.2.0  - 192.0.2.9

C|--------------| 192.0.2.0 - 192.0.2.9

   D                        |---------------|    192.0.2.16 - 192.0.2.30

D|---------------| 192.0.2.16 - 192.0.2.30

   E                        |---------------|    192.0.2.16 - 192.0.2.30

E|---------------| 192.0.2.16 - 192.0.2.30

   F    |--------|                               192.0.2.0  - 192.0.2.5

F|--------| 192.0.2.0 - 192.0.2.5

   G              |----|                         192.0.2.6  - 192.0.2.9

G|----| 192.0.2.6 - 192.0.2.9

   Query|- - - - - - - |                         192.0.2.0  - 192.0.2.9

質問|- - - - - - - | 192.0.2.0 - 192.0.2.9

                        Exact match (1)

完全な一致(1)

                        Result: C

結果: C

                     Figure 14: Specificity Example 2

図14: 特異性の例2

   A    |------------------|                     192.0.2.0  - 192.0.2.15

A|------------------| 192.0.2.0 - 192.0.2.15

   B                        |------------------| 192.0.2.16 - 192.0.2.31

B|------------------| 192.0.2.16 - 192.0.2.31

   C    |--------------|                         192.0.2.0  - 192.0.2.9

C|--------------| 192.0.2.0 - 192.0.2.9

   D                        |---------------|    192.0.2.16 - 192.0.2.30

D|---------------| 192.0.2.16 - 192.0.2.30

   E                        |---------------|    192.0.2.16 - 192.0.2.30

E|---------------| 192.0.2.16 - 192.0.2.30

   F    |--------|                               192.0.2.0  - 192.0.2.5

F|--------| 192.0.2.0 - 192.0.2.5

   G              |----|                         192.0.2.6  - 192.0.2.9

G|----| 192.0.2.6 - 192.0.2.9

   Query|- - - - - - - - |                       192.0.2.0  - 192.0.2.12

質問|- - - - - - - - | 192.0.2.0 - 192.0.2.12

                         Exact match (2)

完全な一致(2)

                         Result: None

結果: なし

                     Figure 15: Specificity Example 3

図15: 特異性の例3

Gunduz, et al.              Standards Track                    [Page 40]

RFC 4698               IRIS Address Registry Type           October 2006

Gunduz、他規格は虹彩アドレス登録タイプ2006年10月にRFC4698を追跡します[40ページ]。

   A    |------------------|                     192.0.2.0  - 192.0.2.15

A|------------------| 192.0.2.0 - 192.0.2.15

   B                        |------------------| 192.0.2.16 - 192.0.2.31

B|------------------| 192.0.2.16 - 192.0.2.31

   C    |--------------|                         192.0.2.0  - 192.0.2.9

C|--------------| 192.0.2.0 - 192.0.2.9

   D                        |---------------|    192.0.2.16 - 192.0.2.30

D|---------------| 192.0.2.16 - 192.0.2.30

   E                        |---------------|    192.0.2.16 - 192.0.2.30

E|---------------| 192.0.2.16 - 192.0.2.30

   F    |--------|                               192.0.2.0  - 192.0.2.5

F|--------| 192.0.2.0 - 192.0.2.5

   G              |----|                         192.0.2.6  - 192.0.2.9

G|----| 192.0.2.6 - 192.0.2.9

   Query|- - - - - - - - - |                     192.0.2.0  - 192.0.2.15

質問|- - - - - - - - - | 192.0.2.0 - 192.0.2.15

                All more specifics, allowEquivalences = false

すべての、より多くの詳細、allowEquivalences=偽

                Result: C, F, & G (A is not included; exact match)

結果: C、F、およびG(Aは含まれていません; 完全な一致)

                     Figure 16: Specificity Example 4

図16: 特異性の例4

   A    |------------------|                     192.0.2.0  - 192.0.2.15

A|------------------| 192.0.2.0 - 192.0.2.15

   B                        |------------------| 192.0.2.16 - 192.0.2.31

B|------------------| 192.0.2.16 - 192.0.2.31

   C    |--------------|                         192.0.2.0  - 192.0.2.9

C|--------------| 192.0.2.0 - 192.0.2.9

   D                        |---------------|    192.0.2.16 - 192.0.2.30

D|---------------| 192.0.2.16 - 192.0.2.30

   E                        |---------------|    192.0.2.16 - 192.0.2.30

E|---------------| 192.0.2.16 - 192.0.2.30

   F    |--------|                               192.0.2.0  - 192.0.2.5

F|--------| 192.0.2.0 - 192.0.2.5

   G              |----|                         192.0.2.6  - 192.0.2.9

G|----| 192.0.2.6 - 192.0.2.9

   Query|- - - - - - - - - |                     192.0.2.0  - 192.0.2.15

質問|- - - - - - - - - | 192.0.2.0 - 192.0.2.15

                All more specifics, allowEquivalences = true

すべての、より多くの詳細、allowEquivalences=、本当

                Result: A, C, F, & G (A is included; exact match)

結果: A、C、F、およびG(Aは含まれています; 完全な一致)

                     Figure 17: Specificity Example 5

図17: 特異性の例5

Gunduz, et al.              Standards Track                    [Page 41]

RFC 4698               IRIS Address Registry Type           October 2006

Gunduz、他規格は虹彩アドレス登録タイプ2006年10月にRFC4698を追跡します[41ページ]。

   A    |------------------|                     192.0.2.0  - 192.0.2.15

A|------------------| 192.0.2.0 - 192.0.2.15

   B                        |------------------| 192.0.2.16 - 192.0.2.31

B|------------------| 192.0.2.16 - 192.0.2.31

   C    |--------------|                         192.0.2.0  - 192.0.2.9

C|--------------| 192.0.2.0 - 192.0.2.9

   D                        |---------------|    192.0.2.16 - 192.0.2.30

D|---------------| 192.0.2.16 - 192.0.2.30

   E                        |---------------|    192.0.2.16 - 192.0.2.30

E|---------------| 192.0.2.16 - 192.0.2.30

   F    |--------|                               192.0.2.0  - 192.0.2.5

F|--------| 192.0.2.0 - 192.0.2.5

   G              |----|                         192.0.2.6  - 192.0.2.9

G|----| 192.0.2.6 - 192.0.2.9

   Query|- - - - - - - - - |                     192.0.2.0  - 192.0.2.15

質問|- - - - - - - - - | 192.0.2.0 - 192.0.2.15

                One level more specifics, allowEquivalences = false

1つは、より多くの詳細、allowEquivalencesを= 虚偽で平らにします。

                Result: C

結果: C

                     Figure 18: Specificity Example 6

図18: 特異性の例6

   A    |------------------|                     192.0.2.0  - 192.0.2.15

A|------------------| 192.0.2.0 - 192.0.2.15

   B                        |------------------| 192.0.2.16 - 192.0.2.31

B|------------------| 192.0.2.16 - 192.0.2.31

   C    |--------------|                         192.0.2.0  - 192.0.2.9

C|--------------| 192.0.2.0 - 192.0.2.9

   D                        |---------------|    192.0.2.16 - 192.0.2.30

D|---------------| 192.0.2.16 - 192.0.2.30

   E                        |---------------|    192.0.2.16 - 192.0.2.30

E|---------------| 192.0.2.16 - 192.0.2.30

   F    |--------|                               192.0.2.0  - 192.0.2.5

F|--------| 192.0.2.0 - 192.0.2.5

   G              |----|                         192.0.2.6  - 192.0.2.9

G|----| 192.0.2.6 - 192.0.2.9

   Query|- - - - - - - - - |                     192.0.2.0  - 192.0.2.15

質問|- - - - - - - - - | 192.0.2.0 - 192.0.2.15

                One level more specifics, allowEquivalences = true

1つは= 本当により多くの詳細、allowEquivalencesを平らにします。

                Result: A

結果: A

                     Figure 19: Specificity Example 7

図19: 特異性の例7

Gunduz, et al.              Standards Track                    [Page 42]

RFC 4698               IRIS Address Registry Type           October 2006

Gunduz、他規格は虹彩アドレス登録タイプ2006年10月にRFC4698を追跡します[42ページ]。

   A    |------------------|                     192.0.2.0  - 192.0.2.15

A|------------------| 192.0.2.0 - 192.0.2.15

   B                        |------------------| 192.0.2.16 - 192.0.2.31

B|------------------| 192.0.2.16 - 192.0.2.31

   C    |--------------|                         192.0.2.0  - 192.0.2.9

C|--------------| 192.0.2.0 - 192.0.2.9

   D                        |---------------|    192.0.2.16 - 192.0.2.30

D|---------------| 192.0.2.16 - 192.0.2.30

   E                        |---------------|    192.0.2.16 - 192.0.2.30

E|---------------| 192.0.2.16 - 192.0.2.30

   F    |--------|                               192.0.2.0  - 192.0.2.5

F|--------| 192.0.2.0 - 192.0.2.5

   G              |----|                         192.0.2.6  - 192.0.2.9

G|----| 192.0.2.6 - 192.0.2.9

   Query          |- - |                         192.0.2.6  - 192.0.2.9

質問|- - | 192.0.2.6 - 192.0.2.9

                All less specifics, allowEquivalences = true

すべての、より少ない詳細、allowEquivalences=、本当

                Result: A, C, & G (G is included; exact match)

結果: A、C、およびG(Gは含まれています; 完全な一致)

                     Figure 20: Specificity Example 8

図20: 特異性の例8

   A    |------------------|                     192.0.2.0  - 192.0.2.15

A|------------------| 192.0.2.0 - 192.0.2.15

   B                        |------------------| 192.0.2.16 - 192.0.2.31

B|------------------| 192.0.2.16 - 192.0.2.31

   C    |--------------|                         192.0.2.0  - 192.0.2.9

C|--------------| 192.0.2.0 - 192.0.2.9

   D                        |---------------|    192.0.2.16 - 192.0.2.30

D|---------------| 192.0.2.16 - 192.0.2.30

   E                        |---------------|    192.0.2.16 - 192.0.2.30

E|---------------| 192.0.2.16 - 192.0.2.30

   F    |--------|                               192.0.2.0  - 192.0.2.5

F|--------| 192.0.2.0 - 192.0.2.5

   G              |----|                         192.0.2.6  - 192.0.2.9

G|----| 192.0.2.6 - 192.0.2.9

   Query          |- - |                         192.0.2.6  - 192.0.2.9

質問|- - | 192.0.2.6 - 192.0.2.9

                All less specifics, allowEquivalences = false

すべての、より少ない詳細、allowEquivalences=偽

                Result: A & C (G is not included; exact match)

結果: A&C(Gは含まれていません; 完全な一致)

                     Figure 21: Specificity Example 9

図21: 特異性の例9

Gunduz, et al.              Standards Track                    [Page 43]

RFC 4698               IRIS Address Registry Type           October 2006

Gunduz、他規格は虹彩アドレス登録タイプ2006年10月にRFC4698を追跡します[43ページ]。

   A    |------------------|                     192.0.2.0  - 192.0.2.15

A|------------------| 192.0.2.0 - 192.0.2.15

   B                        |------------------| 192.0.2.16 - 192.0.2.31

B|------------------| 192.0.2.16 - 192.0.2.31

   C    |--------------|                         192.0.2.0  - 192.0.2.9

C|--------------| 192.0.2.0 - 192.0.2.9

   D                        |---------------|    192.0.2.16 - 192.0.2.30

D|---------------| 192.0.2.16 - 192.0.2.30

   E                        |---------------|    192.0.2.16 - 192.0.2.30

E|---------------| 192.0.2.16 - 192.0.2.30

   F    |--------|                               192.0.2.0  - 192.0.2.5

F|--------| 192.0.2.0 - 192.0.2.5

   G              |----|                         192.0.2.6  - 192.0.2.9

G|----| 192.0.2.6 - 192.0.2.9

   Query          |- - |                         192.0.2.6  - 192.0.2.9

質問|- - | 192.0.2.6 - 192.0.2.9

                One level less specifics, allowEquivalences = true

1つは= 本当により少ない詳細、allowEquivalencesを平らにします。

                Result: G (the exact match)

結果: G(完全な一致)

                     Figure 22: Specificity Example 10

図22: 特異性の例10

   A    |------------------|                     192.0.2.0  - 192.0.2.15

A|------------------| 192.0.2.0 - 192.0.2.15

   B                        |------------------| 192.0.2.16 - 192.0.2.31

B|------------------| 192.0.2.16 - 192.0.2.31

   C    |--------------|                         192.0.2.0  - 192.0.2.9

C|--------------| 192.0.2.0 - 192.0.2.9

   D                        |---------------|    192.0.2.16 - 192.0.2.30

D|---------------| 192.0.2.16 - 192.0.2.30

   E                        |---------------|    192.0.2.16 - 192.0.2.30

E|---------------| 192.0.2.16 - 192.0.2.30

   F    |--------|                               192.0.2.0  - 192.0.2.5

F|--------| 192.0.2.0 - 192.0.2.5

   G              |----|                         192.0.2.6  - 192.0.2.9

G|----| 192.0.2.6 - 192.0.2.9

   Query          |- - |                         192.0.2.6  - 192.0.2.9

質問|- - | 192.0.2.6 - 192.0.2.9

                One level less specifics, allowEquivalences = false

1つは、より少ない詳細、allowEquivalencesを= 虚偽で平らにします。

                Result: C

結果: C

                     Figure 23: Specificity Example 11

図23: 特異性の例11

Gunduz, et al.              Standards Track                    [Page 44]

RFC 4698               IRIS Address Registry Type           October 2006

Gunduz、他規格は虹彩アドレス登録タイプ2006年10月にRFC4698を追跡します[44ページ]。

   A    |------------------|                     192.0.2.0  - 192.0.2.15

A|------------------| 192.0.2.0 - 192.0.2.15

   B                        |------------------| 192.0.2.16 - 192.0.2.31

B|------------------| 192.0.2.16 - 192.0.2.31

   C    |--------------|                         192.0.2.0  - 192.0.2.9

C|--------------| 192.0.2.0 - 192.0.2.9

   D                        |---------------|    192.0.2.16 - 192.0.2.30

D|---------------| 192.0.2.16 - 192.0.2.30

   E                        |---------------|    192.0.2.16 - 192.0.2.30

E|---------------| 192.0.2.16 - 192.0.2.30

   F    |--------|                               192.0.2.0  - 192.0.2.5

F|--------| 192.0.2.0 - 192.0.2.5

   G              |----|                         192.0.2.6  - 192.0.2.9

G|----| 192.0.2.6 - 192.0.2.9

   Query|- - - - - - |                           192.0.2.0  - 192.0.2.8

質問|- - - - - - | 192.0.2.0 - 192.0.2.8

             One level less specifics, allowEquivalences = false or true

1つは誤っているか、または本当の状態で、より少ない詳細、allowEquivalences=を平らにします。

             Result: C

結果: C

                     Figure 24: Specificity Example 12

図24: 特異性の例12

   A    |------------------|                     192.0.2.0  - 192.0.2.15

A|------------------| 192.0.2.0 - 192.0.2.15

   B                        |------------------| 192.0.2.16 - 192.0.2.31

B|------------------| 192.0.2.16 - 192.0.2.31

   C    |--------------|                         192.0.2.0  - 192.0.2.9

C|--------------| 192.0.2.0 - 192.0.2.9

   D                        |---------------|    192.0.2.16 - 192.0.2.30

D|---------------| 192.0.2.16 - 192.0.2.30

   E                        |---------------|    192.0.2.16 - 192.0.2.30

E|---------------| 192.0.2.16 - 192.0.2.30

   F    |--------|                               192.0.2.0  - 192.0.2.5

F|--------| 192.0.2.0 - 192.0.2.5

   G              |----|                         192.0.2.6  - 192.0.2.9

G|----| 192.0.2.6 - 192.0.2.9

   Query  =  E

質問=E

                  Find parent (Query argument is a handle)

親を見つけてください。(質問議論はハンドルです)

                  Result: D

結果: D

                     Figure 25: Specificity Example 13

図25: 特異性の例13

Gunduz, et al.              Standards Track                    [Page 45]

RFC 4698               IRIS Address Registry Type           October 2006

Gunduz、他規格は虹彩アドレス登録タイプ2006年10月にRFC4698を追跡します[45ページ]。

   A    |------------------|                     192.0.2.0  - 192.0.2.15

A|------------------| 192.0.2.0 - 192.0.2.15

   B                        |------------------| 192.0.2.16 - 192.0.2.31

B|------------------| 192.0.2.16 - 192.0.2.31

   C    |--------------|                         192.0.2.0  - 192.0.2.9

C|--------------| 192.0.2.0 - 192.0.2.9

   D                        |---------------|    192.0.2.16 - 192.0.2.30

D|---------------| 192.0.2.16 - 192.0.2.30

   E                        |---------------|    192.0.2.16 - 192.0.2.30

E|---------------| 192.0.2.16 - 192.0.2.30

   F    |--------|                               192.0.2.0  - 192.0.2.5

F|--------| 192.0.2.0 - 192.0.2.5

   G              |----|                         192.0.2.6  - 192.0.2.9

G|----| 192.0.2.6 - 192.0.2.9

   Query  =  D

質問=D

                   Find child (Query argument is a handle)

子供を見つけてください。(質問議論はハンドルです)

                   Result: E

結果: E

                     Figure 26: Specificity Example 14

図26: 特異性の例14

Appendix D.  Contributors

付録D.貢献者

   David Blacka and Tim Christensen made substantial contributions to
   this document.

デヴィッドBlackaとティムクリステンセンはこのドキュメントへの多大な貢献をしました。

Appendix E.  Acknowledgements

付録E.承認

   Eric Hall, William Leibzon, April Marine, George Michaelson, Tim
   Christensen Cathy Murphy, Andrei Robachevsky, Marcos Sanz, Frederico
   Neves, Ted Hardie, and many others contributed constructively in the
   mailing list discussions and IETF Meeting sessions.

エリックHall、ウィリアムLeibzon、4月の海兵隊員(ジョージMichaelson)のティム・クリステンセンのキャシー・マーフィー、アンドレイRobachevsky、マルコス・サンス、Fredericoネベス、テッド・ハーディー、および多くの他のものがメーリングリスト議論とIETF Meetingセッションのときに建設的に貢献しました。

Gunduz, et al.              Standards Track                    [Page 46]

RFC 4698               IRIS Address Registry Type           October 2006

Gunduz、他規格は虹彩アドレス登録タイプ2006年10月にRFC4698を追跡します[46ページ]。

Authors' Addresses

作者のアドレス

   Engin Gunduz
   RIPE NCC
   Singel 258
   Amsterdam  1016AB
   The Netherlands

Engin Gunduzの熟しているNCC Singel258アムステルダム1016ABオランダ

   Phone: +31 20 535 4444
   EMail: e.gunduz@computer.org

以下に電話をしてください。 +31 20 535 4444はメールされます: e.gunduz@computer.org

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

アンドリューL.ニュートンベリサインInc.21345屋根の頂円の英貨、ヴァージニア20166米国

   Phone: +1 703 948 3382
   EMail: andy@hxr.us

以下に電話をしてください。 +1 3382年の703 948メール: andy@hxr.us

   Shane W. Kerr
   RIPE NCC
   Singel 258
   Amsterdam  1016AB
   The Netherlands

シェーンW.カー熟しているNCC Singel258アムステルダム1016ABオランダ

   Phone: +31 20 535 4444
   EMail: shane@time-travellers.org

以下に電話をしてください。 +31 20 535 4444はメールされます: shane@time-travellers.org

Gunduz, et al.              Standards Track                    [Page 47]

RFC 4698               IRIS Address Registry Type           October 2006

Gunduz、他規格は虹彩アドレス登録タイプ2006年10月にRFC4698を追跡します[47ページ]。

Full Copyright Statement

完全な著作権宣言文

   Copyright (C) The Internet Society (2006).

   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 procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

IETFはどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。

   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 provided by the IETF
   Administrative Support Activity (IASA).

RFC Editor機能のための基金はIETF Administrative Support Activity(IASA)によって提供されます。

Gunduz, et al.              Standards Track                    [Page 48]

Gunduz、他標準化過程[48ページ]

一覧

RFC 1～100	RFC 1401～1500	RFC 2801～2900	RFC 4201～4300
RFC 101～200	RFC 1501～1600	RFC 2901～3000	RFC 4301～4400
RFC 201～300	RFC 1601～1700	RFC 3001～3100	RFC 4401～4500
RFC 301～400	RFC 1701～1800	RFC 3101～3200	RFC 4501～4600
RFC 401～500	RFC 1801～1900	RFC 3201～3300	RFC 4601～4700
RFC 501～600	RFC 1901～2000	RFC 3301～3400	RFC 4701～4800
RFC 601～700	RFC 2001～2100	RFC 3401～3500	RFC 4801～4900
RFC 701～800	RFC 2101～2200	RFC 3501～3600	RFC 4901～5000
RFC 801～900	RFC 2201～2300	RFC 3601～3700	RFC 5001～5100
RFC 901～1000	RFC 2301～2400	RFC 3701～3800	RFC 5101～5200
RFC 1001～1100	RFC 2401～2500	RFC 3801～3900	RFC 5201～5300
RFC 1101～1200	RFC 2501～2600	RFC 3901～4000	RFC 5301～5400
RFC 1201～1300	RFC 2601～2700	RFC 4001～4100	RFC 5401～5500
RFC 1301～1400	RFC 2701～2800	RFC 4101～4200

RFC4698 日本語訳

一覧

リンク

メニュー

コメント

お問い合わせ

プライバシーポリシー