Internet Engineering Task Force (IETF) A. Newton Request for Comments: 7482 ARIN Category: Standards Track S. Hollenbeck ISSN: 2070-1721 Verisign Labs March 2015 Registration Data Access Protocol（RDAP）のクエリ形式 Abstract 本ドキュメントは、"RESTful"Webアクセスパターンを用いてレジストリ （RIR（地域インターネットレジストリ）及びDNR（ドメイン名レジストリ） を含む）の登録情報を検索するために利用するHTTP URLを構築する統一プラッ トフォームを説明している。これらの統一プラットフォームは、RDAP （Registration Data Access Protocol）のクエリ構文を定義している。 Status of This Memo 本ドキュメントは、インターネット標準化過程のドキュメントである。 本ドキュメントは、IETF（Internet Engineering Task Force）の成果物で ある。IETFコミュニティのコンセンサスを代表するものである。また、本ド キュメントは、公開レビューを受けており、IESG（Internet Engineering Steering Group）から公開・発行することを承認されている。インターネッ ト標準に関する詳細は、RFC 5741のSection 2で提供されている。 本ドキュメントに関する最新の状態、正誤、フィードバックの方法などに関 する情報は、下記URLを参照。 http://www.rfc-editor.org/info/rfc7482 Copyright Notice Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Newton & Hollenbeck Standards Track [Page 1] RFC 7482 RDAP Query Format March 2015 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Conventions Used in This Document . . . . . . . . . . . . . . 4 2.1. Acronyms and Abbreviations . . . . . . . . . . . . . . . 4 3. Path Segment Specification . . . . . . . . . . . . . . . . . 4 3.1. Lookup Path Segment Specification . . . . . . . . . . . . 5 3.1.1. IP Network Path Segment Specification . . . . . . . . 6 3.1.2. Autonomous System Path Segment Specification . . . . 7 3.1.3. Domain Path Segment Specification . . . . . . . . . . 7 3.1.4. Nameserver Path Segment Specification . . . . . . . . 8 3.1.5. Entity Path Segment Specification . . . . . . . . . . 9 3.1.6. Help Path Segment Specification . . . . . . . . . . . 9 3.2. Search Path Segment Specification . . . . . . . . . . . . 9 3.2.1. Domain Search . . . . . . . . . . . . . . . . . . . . 10 3.2.2. Nameserver Search . . . . . . . . . . . . . . . . . . 11 3.2.3. Entity Search . . . . . . . . . . . . . . . . . . . . 12 4. Query Processing . . . . . . . . . . . . . . . . . . . . . . 13 4.1. Partial String Searching . . . . . . . . . . . . . . . . 13 4.2. Associated Records . . . . . . . . . . . . . . . . . . . 14 5. Extensibility . . . . . . . . . . . . . . . . . . . . . . . . 14 6. Internationalization Considerations . . . . . . . . . . . . . 15 6.1. Character Encoding Considerations . . . . . . . . . . . . 15 7. Security Considerations . . . . . . . . . . . . . . . . . . . 16 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 8.1. Normative References . . . . . . . . . . . . . . . . . . 17 8.2. Informative References . . . . . . . . . . . . . . . . . 19 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 19 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 1. Introduction 本ドキュメントは、RESTful webサービス及び統一クエリプラットフォーム を用いて登録データをクエリする仕様を説明している。このサービスは、 HTTP（Hypertext Transfer Protocol）[RFC7230] 及び [RFC7480] で説明さ れている規則を用いて実装している。これらの統一プラットフォームは、 RDAP（Registration Data Access Protocol）のクエリ構文を定義している。 この仕様で説明しているプロトコルは、WHOISプロトコル[RFC3912] におけ る不備に対応することを目的としており、長い期間を掛けて下記課題を含め、 確認されてきている。 o 標準化されたコマンド構造の不足 o 標準化されたアウトプット及びエラー構造の不足 o 国際化やローカライゼ―ションのサポート体制の不足 Newton & Hollenbeck Standards Track [Page 2] RFC 7482 RDAP Query Format March 2015 o ユーザーID、認証、アクセス制御のサポートの不足 本ドキュメントで説明されているパターンは、RIR並びにDNRで使用されてい るWHOIS及び他のRESTful Webサービスで用いられるすべての手法を意図的に 網羅していない。ここで説明されているパターンの目的は、下記に挙げるク エリを可能にする。 o IPアドレスによるネットワークのクエリ o 番号による自律システム（AS）番号のクエリ o ドメインによる逆引きDNSメタデータのクエリ o 名前によるネームサーバー情報のクエリ o 名前によるレジストラのクエリ o 識別子によるエンティティー（連絡先情報など）のクエリ サーバー実装は、ローカル要件に依存してこれらの一部の機能のみを自由に サポートできる。サーバーは、サポートしていないクエリタイプであること をクライアントに知らせるために、HTTP 501（Not Implemented）[RFC7231] 応答を返さなければならない（MUST）。 また、各レジストリが、自身及びその顧客のニーズに対応するためにRIR並 びにDNRで使用されているWHOISと他のRESTful Webサービス（両方またはい ずれか一方）を維持し続けることも想定しており、ここで説明されているパ ターンを通して検索された情報も、そのようなサービスを参照する可能性が ある。 同様に、将来的なIETF標準が、追加されるクエリタイプのために追加パター ンを追加する可能性もある。簡易パターンの名前空間スキームは、カスタム 拡張が本ドキュメントで規定されているパターン、または将来的なIETF標準 で規定されるパターンを妨げないためにSection 5で説明されている。 WHOISサービスは、通常、読み取り専用サービスである。よって、本ドキュ メントで規定されているURL [RFC3986] パターンは、HTTP [RFC7231] GET及 びHEADメソッドにのみ適用できる。 本ドキュメントは、説明されたURLをHTTP GETメソッドを発行することで返 された結果、またはエンティティーを説明していない。これらのエンティ ティーに関する仕様は、[RFC7483] で説明されている。 更に、リソース管理、資源登録、更新機能は、本ドキュメントの範囲外とし ている。レジストリは、それら機能を包含するさまざまな多様性ある手法を 有しており、統一的アプローチが相互運用性のために必要とされる可能性は 低い。 Newton & Hollenbeck Standards Track [Page 3] RFC 7482 RDAP Query Format March 2015 HTTPは、サーバーがクライアントを認証し、またクライアントがサーバーを 認証するメカニズムを含む（そこから認可スキームが構築できる）、従って、 そのようなメカニズムは、本ドキュメントでは説明されていない。ポリシー、 資源登録、認証処理、認可などは、本ドキュメントの範囲外であり、それら を展開するためにはローカル基準に基づく選択をしなくてはならない。サポー トされている認証メカニズムは、[RFC7481] で説明されている。 2. Conventions Used in This Document 本ドキュメントにおける次の各キーワード「しなければならない（MUST）」、 「してはならない（MUST NOT）」、「要求されている（REQUIRED）」、「す ることになる（SHALL）」、「することはない（SHALL NOT）」、「すべきで ある（SHOULD）」、「すべきではない（SHOULD NOT）」、「推奨される （RECOMMENDED）」、「してもよい（MAY）」、「任意である（OPTIONAL）」 は、[RFC2119] で説明されているように解釈されるべきものである。 2.1. Acronyms and Abbreviations 本ドキュメントで使用されている頭字語及び略語： IDN：国際化ドメイン名 IDNA：アプリケーションにおけるドメイン名の国際化。IDN（国際化ドメ イン名）を取り扱うプロトコルのこと。 DNR：ドメイン名レジストリ NFC：Unicodeの正規化形式C [Unicode-UAX15] NFKC：Unicodeの正規化形式KC [Unicode-UAX15] RDAP：Registration Data Access Protocol REST：Representational State Transfer この用語は、最初に博士論文 [REST] の中で説明された。 RESTful：HTTPプロトコル及びRESTの原則を用いたサービスを説明する形 容詞。 RIR：地域インターネットレジストリ 3. Path Segment Specification RDAPクエリを構築するために使用されるベースURLは [RFC7484] で説明され ているIANAレジストリで維持されている。クエリは、適切なベースURLをレ ジストリから受信すること及びSections 3.1または3.2で規定されているパ ス部を付加することで形成される。RFC 3986 [RFC3986] のSection 5のよう に、通常、レジストリまたはその他のサービスプロバイダーが、プロトコル、 Newton & Hollenbeck Standards Track [Page 4] RFC 7482 RDAP Query Format March 2015 ホスト、ポートを特定するベースURLを提供する。これは完全なURLの解決に 向けたベースURLとして使用される。 例えば、ベースURLが、"https://example.com/rdap/"の場合、すべてのRDAP クエリのURLは、"https://example.com/rdap/"から始まる。 ブートストラップレジストリは、エンティティーやヘルプを含むグローバル 名前空間の一部ではないクエリオブジェクトのための情報を含んでいない。 関連オブジェクトのベースURLは、完全なクエリを構築するために要求され る。 エンティティーに対して、ベースURLは、既定エンティティーに関連するサー ビス（ドメイン、住所など）のために検索される。クエリURLは、ベースURL をSections 3.1.5または3.2.3のいずれかで規定されるエンティティーパス 部と連結することで構築される。 ヘルプに対しては、ベースURLは、追加情報を要求するすべてのサービス （ドメイン、住所など）のために検索される。クエリURLは、ベースURLを Sections 3.1.6で規定されるヘルプパス部と連結することで構築される。 3.1. Lookup Path Segment Specification RDAPによる符号化の結果を返さずにオブジェクトが存在するか否かを決定す るための簡易な検索は、[RFC7480] のSection 4.1で説明されているように、 HTTP HEADメソッドを用いて実行される。 下記は、完全一致検索のリソースタイプパス部を示す。 o 'ip'：IPv4またはIPv6アドレスを用いて、IPネットワーク及び参照され る関連データを同定するために使用される。 o 'autnum'：ASPLAIN形式のAS番号を用いて、AS番号登録及び参照される関 連データを同定するために使用される。 o 'domain'：完全修飾ドメイン名を用いて、逆引きDNS（RIR）またはドメ イン名（DNR）情報、及び参照される関連データを同定するために使用さ れる。 o 'nameserver'：ホスト名を用いて、ネームサーバー情報クエリを同定す るために使用される。 o 'entity'：文字列識別子を用いて問い合わせ、エンティティー情報クエ リを同定するために使用される。 Newton & Hollenbeck Standards Track [Page 5] RFC 7482 RDAP Query Format March 2015 3.1.1. IP Network Path Segment Specification 構文：ip/ or ip// IPネットワークに関する情報のクエリは、/ip/XXX/...または /ip/XXX/YY/...で形成され、'ip'の後のパス部はIPv4のドット区切り10進数、 IPv6 [RFC5952] のアドレス（すなわちXXX）、またはIPv4・IPv6のCIDR （Classless Inter-domain Routing）[RFC4632] 表記アドレスブロック（す なわちXXX/YY）のいずれかである。語義的には、アドレスを用いたよりシン プルな形式は、IPv4では32、IPv6では128のビットマスク長のCIDRブロック と見なされる。ある特定のアドレスまたはCIDRは、階層化されたネットワー クの中の複数IPネットワークの範囲内に含まれる可能性がある。従って、こ のクエリは、IPネットワークの階層に完全に包含される"most-specific" （最も特定された）または最小規模のIPネットワークをターゲットとしてい る。 このクエリがサポートするIPv4及びIPv6アドレス形式は、IPv4アドレス及び IPv6アドレスのABNF（Augmented Backus-Naur Form）定義としてRFC 3986 [RFC3986] のSection 3.2.2で説明されている。すべての有効なIPv6テキス トアドレス形式 [RFC4291] が使用できる。これは、ゼロの省略やIPv4アド レス埋込IPv6アドレスの有無に関わらず表記されたIPv6アドレスを含む。こ のIPv6アドレスのテキスト表記方法に関するルール[RFC5952] が推奨される （RECOMMENDED）。しかしながら、ゾーンID [RFC4007] は、この表記方法に は適していない。それ故に、RFC 6874 [RFC6874] に対応する構文拡張は、 使用してはならない（MUST NOT）。また、可能であれば、サーバーはそれ らを無視すべきである。 例えば、下記URLは、192.0.2.0を含有する最も特定されたネットワークの情 報を検索するために使用できる。 https://example.com/rdap/ip/192.0.2.0 下記URLは、192.0.2.0/24を含有する最も特定されたネットワークの情報を 検索するために使用される。 https://example.com/rdap/ip/192.0.2.0/24 下記URLは、2001:db8::0を含有する最も特定されたネットワークの情報を検 索するために使用される。 https://example.com/rdap/ip/2001:db8::0 Newton & Hollenbeck Standards Track [Page 6] RFC 7482 RDAP Query Format March 2015 3.1.2. Autonomous System Path Segment Specification 構文：autnum/ AS番号登録に関する情報のためのクエリは、/autnum/XXX/...で形成され、 XXXは、ASPLAIN形式のAS番号である [RFC5396]。いくつかのレジストリでは、 AS番号の登録が個別番号で行われており、その他のレジストリは、AS番号の ブロックを登録していることもある。このクエリの語義は、もしその番号が 登録されたブロックの範囲内に収まるような場合、クエリのターゲットは、 ブロックの登録である。また、個別番号の登録は、1のサイズでの番号のブ ロックと見なされる。 例えば、下記URLは、AS番号12（登録されたブロックの範囲内の番号）を示 した情報を検索するために使用できる。 https://example.com/rdap/autnum/12 下記URLは、4バイトのAS番号65538を示した情報を検索するために使用され る。 https://example.com/rdap/autnum/65538 3.1.3. Domain Path Segment Specification 構文：domain/ ドメイン情報のためのクエリは、/domain/XXXX/...で形成され、XXXXは、 （RIRの）in-addr.arpa ゾーンと ip6.arpa ゾーン、（DNRの）サーバーオ ペレーターが管理するゾーン内の完全修飾ドメイン名のいずれかの（ルート に対する）完全修飾ドメイン名（[RFC0952] 及び [RFC1123] で規定されて いる）である。A-labelまたはU-label形式 [RFC5890] で表記された国際化 ドメイン名（IDN）も、有効なドメイン名である。U-label形式の文字コード 情報に関しては、Section 6.1を参照。 IDNは、A-labelとU-label形式を混合して表記すべきではない（SHOULD NOT）。つまり、IDNで国際化されたラベルは、すべてA-label形式か、すべて U-label形式のどちらかにすべきである（SHOULD）。RDAPクライアントは、 複数の独立したデータソースからクエリ文字列を結成することが可能である。 そのようなクライアントは、A-label及びU-label間の変換を実行することが できないかもしれない。A-label及びU-labelが混合したクエリ文字列を受信 したRDAPサーバーは、すべてのU-labelをA-labelへ変換し、IDNA処理を実行 し、完全一致検索を開始してもよい（MAY）。 Newton & Hollenbeck Standards Track [Page 7] RFC 7482 RDAP Query Format March 2015 その場合、クエリ送信元に返される応答は、クエリ送信元からの入力情報と 一致しないかもしれない。その代わりに、サーバーはクエリの処理を拒否し てもよい（MAY）。 サーバーは、A-labelまたはU-label形式を用いて照合を実施してもよい （MAY）。一つの一貫した形式を各ラベルの照合に用いることは、より確実 となるだろう。 下記URLは、192.0.2/24のネットワークが提供するゾーンを示した情報を検 索するために使用される。 https://example.com/rdap/domain/2.0.192.in-addr.arpa 下記URLは、2001:db8:1::/48のネットワークが提供するゾーンを示した情報 を検索するために使用される。 https://example.com/rdap/domain/1.0.0.0.8.b.d.0.1.0.0.2.ip6.arpa 下記URLは、blah.example.comのドメイン名に関する情報を検索するために 使用される。 https://example.com/rdap/domain/blah.example.com 下記URLは、xn--fo-5ja.exampleのIDNに関する情報を検索するために使用さ れる。 https://example.com/rdap/domain/xn--fo-5ja.example 3.1.4. Nameserver Path Segment Specification 構文：nameserver/ パラメーターは、[RFC0952] 及び[RFC1123] で規定され ている完全修飾ホスト名を表している。A-labelまたはU-label形式 [RFC5890] で表記されたIDN（国際化ドメイン名）も、有効なネームサーバー 名である。ネームサーバー名のIDN処理は、Section 3.1.3で規定されている ドメイン名処理の指示を使用する。U-label形式の文字コード情報に関して は、Section 6.1を参照。 下記URLは、ns1.example.comのネームサーバーに関する情報を検索するため に使用される。 https://example.com/rdap/nameserver/ns1.example.com Newton & Hollenbeck Standards Track [Page 8] RFC 7482 RDAP Query Format March 2015 下記URLは、ns1.xn--fo-5ja.exampleのネームサーバーに関する情報を検索 するために使用される。 https://example.com/rdap/nameserver/ns1.xn--fo-5ja.example 3.1.5. Entity Path Segment Specification 構文：entity/ パラメーターは、エンティティー（コンタクト、登録者またはレ ジストラ）識別子を表しており、その構文は登録プロバイダー固有のもので ある。例えば、あるDNRにとっては、コンタクト識別子は[RFC5730] 及び [RFC5733] で規定されている。 下記URLは、 XXXXに関連するエンティティーに関する情報を検索す るために使用される。 https://example.com/rdap/entity/XXXX 3.1.6. Help Path Segment Specification 構文：help Helpパス部は、RDAPサーバーに対して役立つ情報（コマンド構文、サービス 規約、プライバシーポリシー、レート制限ポリシー、サポートされている認 証方式、サポートされている拡張、テクニカルサポートコンタクト情報、そ の他）をリクエストするために使用できる。"help"に対する応答は、クライ アントがサービスをうまく利用するために必要な基本的情報を提供すべきで ある。下記URLは、"help"に関する情報の応答を受けるために使用される。 https://example.com/rdap/help 3.2. Search Path Segment Specification パターンマッチングの語義は、本ドキュメントSection 4.1.で説明されてい る。検索用のリソースタイプを示すパス部は、以下の通り。 o 'domains'：完全修飾ドメイン名に一致するパターンを用いて、ドメイン 名情報検索を同定するために使用される。 o 'nameservers'：ホスト名に一致するパターンを用いて、ネームサーバー 情報検索を同定するために使用される。 o 'entities'：文字列識別子に一致するパターンを用いて、エンティティー 情報検索を同定するために使用される。 Newton & Hollenbeck Standards Track [Page 9] RFC 7482 RDAP Query Format March 2015 RDAP検索パス部は検索されるオブジェクトの複数形とHTTPクエリ文字列を連 結して構成される。HTTPクエリ文字列は以下の連結によって構成される。 ・疑問符（'?'、US-ASCII値0x003F） ・検索されるオブジェクトに関連するJSONオブジェクト値 ・等号（'='、US-ASCII値0x003D） ・検索パターン検索パターンのクエリ処理は、Section 4で詳細に説明され ている。 本ドキュメントにおける「domain」、「nameserver」、「entity」オブジェ クトの複数形は「domains」、「nameservers」、「entities」となる。 詳細な結果は、HTTP GETメソッドとここで規定されたパス部を用いて取得で きる。 3.2.1. Domain Search ドメイン名情報検索： 構文：domains?name= 構文：domains?nsLdhName= 構文：domains?nsIp= ドメイン情報を「名前」で検索する場合、下記の形式が規定されている。 domains?name=XXXX XXXXはドメイン名を表す検索パターンで、DNR（ドメイン名レジストリ）の サーバーオペレーターが管理するゾーン中と同じLDH（"letters"、"digits"、 "hyphen"：文字・数字・ハイフン）形式 [RFC5890] である。下記URLは、 DNR情報から"example*.com"というパターンにマッチするドメイン名を検索 するために使用される。 https://example.com/rdap/domains?name=example*.com U-label形式のIDN [RFC5890] も検索パターンとして使用できる（Section 4 を参照）。これらの名前の検索は、以下の形式を使用する。 /domains?name=XXXX ここで、XXXXはU-label形式 [RFC5890] のドメイン名を表す検索パターンで ある。U-label形式の文字エンコーディングについてはSection 6.1を参照。 ドメイン情報を「ネームサーバー名」で検索する場合、下記の形式が規定さ れている。 domains?nsLdhName=YYYY Newton & Hollenbeck Standards Track [Page 10] RFC 7482 RDAP Query Format March 2015 YYYYはホスト名を表す検索パターンで、DNRのサーバーオペレーターが管理 するゾーン中と同じLDH形式 [RFC5890] である。 以下のURLは、"ns1.example*.com"というパターンにマッチするネームサー バーに委任されたドメイン名を検索するために使用される。 https://example.com/rdap/domains?nsLdhName=ns1.example*.com ドメイン情報を「ネームサーバーのIPアドレス」で検索する場合、下記の形 式が規定されている。 domains?nsIp=ZZZZ ZZZZはIPv4 [RFC1166] またはIPv6 [RFC5952] アドレスを表す検索パターン である。以下のURLは、アドレスが"192.0.2.0"であるネームサーバーに委任 されたドメイン名を検索するために使用される。 https://example.com/rdap/domains?nsIp=192.0.2.0 3.2.2. Nameserver Search ネームサーバー情報検索： 構文：nameservers?name= 構文：nameservers?ip= ネームサーバー情報をネームサーバー名で検索する場合、下記の形式が規定 されている。 nameservers?name=XXXX XXXXはドメイン名を表す検索パターンで、DNRのサーバーオペレーターが管 理するゾーン中と同じLDH形式 [RFC5890] である。以下のURLは、DNR情報か ら"ns1.example*.com"というパターンにマッチするネームサーバー名を検索 するために使用される。 https://example.com/rdap/nameservers?name=ns1.example*.com U-label形式 [RFC5890] の国際化されたネームサーバー名も検索パターンと して使用できる（Section 4を参照）。これらの名前の検索は、以下の形式 を使用する。ここで、XXXXはU-label形式 [RFC5890] のネームサーバー名を 表す検索パターンである。 /nameservers?name=XXXX U-label形式の文字エンコーディングについてはSection 6.1を参照。 Newton & Hollenbeck Standards Track [Page 11] RFC 7482 RDAP Query Format March 2015 ネームサーバー情報をネームサーバーのIPアドレスで検索する場合、下記の 形式が規定されている。 nameservers?ip=YYYY YYYYはIPv4 [RFC1166] またはIPv6 [RFC5952] アドレスを表す検索パターン である。 以下のURLは、アドレスが"192.0.2.0"であるネームサーバー名を検索するた めに使用される。 https://example.com/rdap/nameservers?ip=192.0.2.0 3.2.3. Entity Search エンティティー情報検索： 構文：entities?fn= 構文：entities?handle= エンティティー情報を名前で検索する場合、下記の形式が規定されている。 entities?fn=XXXX XXXXは、[RFC7483] のSection 5.1で規定されているエンティティー（連絡 先、登録者、レジストラなど）の名前の"FN"プロパティを表す検索パターン である。以下のURLは、"Bobby Joe* "というパターンにマッチするエンティ ティーの名前の情報を検索するために使用される。 https://example.com/rdap/entities?fn=Bobby%20Joe* エンティティー情報をハンドルで検索する場合、下記の形式が規定されてい る。 entities?handle=XXXX XXXXは、登録時業者ごとに形式が異なるエンティティー（連絡先、登録者、 レジストラなど）の識別子を表す検索パターンである。以下のURLは、 "CID-40* "というパターンにマッチするエンティティーハンドルの情報を検 索するために使用される。 https://example.com/rdap/entities?handle=CID-40* URLは、[RFC3986] のルールに従い適切にエンコードされなければならない （MUST）。 上記の例では、"Bobby Joe* "は"Bobby%20Joe* "にエンコードされている。 Newton & Hollenbeck Standards Track [Page 12] RFC 7482 RDAP Query Format March 2015 4. Query Processing サーバーは、クライアントに対し適切なHTTP応答コードを返すことによって、 クエリ処理の成否を示す。本ドキュメントで具体的に特定されていない応答 コードは、[RFC7480] で説明されている。 4.1. Partial String Searching 部分文字列検索は、ゼロ個以上の後続文字に一致させるために、アスタリス ク（'*'、US-ASCII値0x002A）文字を使用する。複数のドメイン名ラベルを 表す文字列は、検索範囲を制限するために検索パターンに連結できる（MAY）。 例えば、"exam* "という検索パターンは、"example.com"及び"example.net" に一致する。"exam*.com"という検索パターンは、"example.com"と一致する。 アスタリスクが検索文字列に含まれる場合、アスタリスク以外の文字の順序 に加え、アスタリスクの位置にゼロ個以上の文字の順序を含むラベルが一致 する。追加パターンの一致処理は、この仕様の範囲外である。 もしサーバーが検索リクエストを受信したが、部分文字列検索における特定 のスタイルをサポートしていないことでリクエストを処理できない場合、 HTTP 422応答（Unprocessable Entity）[RFC4918] を返すべきである （SHOULD）。422エラーを返す際、リクエストされたメディアタイプが [RFC7480] で規定されていれば、サーバーは [RFC7483] のSection 6で規 定されているエラー応答本体も返してよい（MAY）。 部分一致は、Unicode文字の組み合わせ全般に利用可能ではない。その理由 は、Unicode文字が文字同士で組み合わせることが可能だからである。サー バーは、規程に沿った組み合わせが可能な場合は、Unicode文字の組み合わ せの部分一致をすべきではない（SHOULD NOT）。文字はさまざまな方法で 組み合わせることができるため、文字が別の文字と組み合わせることの可否 のケースを検知することが常に可能であるとは限らない。このことは、当然 注意されるべきである。 Unicode文字は規定に沿って別のUnicode文字と組み合わせることが可能であ るため、クライアントは、Unicode文字の部分一致検索を実行することを避 けるべきである。別の文字との組み合わせが必須である文字の場合、不完全 な文字の組み合わせによる部分一致検索は、無効となる。別の文字との組み 合わせが可能である文字による部分一致検索は、組み合わせていない文字で 検索する（つまり、もし文字xが文字yと組み合わせる可能性があるが、文字 yは検索文字列に含まれていない場合、文字xは完全な文字であり、かつ文字 xの組み合わせは検索されない）。 Newton & Hollenbeck Standards Track [Page 13] RFC 7482 RDAP Query Format March 2015 4.2. Associated Records 概念的に、クエリに一致するサーバーのデータベース内のレコードは、サー バーが定義する何らかの方法で関連するレコード、の集合のメンバーである かもしれない（例えば、IDNの異体文字）。集合全体が、応答を構築する際 に含まれるべき候補と見なすことができる。しかしながら、RDAP応答の集合 （セット）を集める際、最終的な応答の構築は、プライバシー及びその他の データ公開ポリシーを心に留めておく必要がある。 検索の性質上、クエリに一致するレコードのリストが存在しうることにも注 意する。前段落で説明されているように、それらの各々のレコードは、集合 のメンバーとして対象となる。最終的に応答に返されるものは、適切なポリ シーによってフィルターされたすべての集合の結合である。 このモデルは、関連する名前（ポリシーにリンクした仕組みやある目的で結 び付けられた名前）に関する取り決めが含まれていることに注意する。完全 一致検索で明示的に選択されていない返却情報（比較的あいまいな検索の結 果返された追加の名前や相互リンクされた名前のリストなど）は、プライバ シー問題を引き起こす可能性があることにも注意する。 すべてのクライアントに公平に適用する、唯一の、静的な返却情報に関する ポリシーは、存在しないかもしれないことにも注意する。クライアントの識 別及び関連する認可は、特定のクエリに対してどれだけ広範な応答集合とな るかを決定する関連要素になる。 5. Extensibility 本ドキュメントは、RIR及びDNRで一般的に登録された限られた数のオブジェ クトのパス部仕様を説明している。ここでは、すべてのレジストリで登録さ れたすべてのオブジェクトにおけるパス部の説明は試みない。カスタムパス 部は、"HTTP Usage in the Registration Data Access Protocol（RDAP）" [RFC7480] のSection 6で説明されている処理を用いて、ここで規定されて いないオブジェクトのために生成される。 カスタムパス部は、一意の識別子とそれに続く下線記号（0x5F）をパス部の 前に付与することで生成される。例えば、カスタムエンティティーパス部は、 "custom_"を"entity"の前に付与することで、"custom_entity"が生成される。 サーバーは、未認識のパス部を含むリクエストに対し、適切な失敗のステー タスコードを返さなければならない（MUST）。 Newton & Hollenbeck Standards Track [Page 14] RFC 7482 RDAP Query Format March 2015 6. Internationalization Considerations RDAPサービスへのクエリ引数としてU-label（IDN labelのUnicode形式）ま たはA-label（IDN labelのUS-ASCII 形式）を実行できる能力をサポートす ることは価値がある。非US-ASCII文字処理に適応できるクライアントは、 A-label文字列よりも視覚的に認識しやすく、見慣れているなどの理由から、 U-labelを選択してもよい。ただし、プログラマチックインターフェースを 用いるクライアントがキーボード設定でU-labelを入力できない場合は、 A-labelを実行・表示する方がより簡単かもしれない。両方のクエリ形式が、 受け入れ可能である。 国際化されたドメイン名及びネームサーバー名は、[RFC4290] で説明されて いるように、異体文字及び異体ラベルを包含することができる。国際化され たドメイン名及びネームサーバー名のクエリをサポートするクライアントは、 "JSON Responses for the Registration Data Access Protocol（RDAP）" [RFC7483] で規定されている異体文字が記されたサービスプロバイダーから の応答を受け入れなければならない（MUST）。 6.1. Character Encoding Considerations サーバーは、HTTPがサポートするさまざまな形式で符号化された文字列を包 含する検索パターンをクライアントから受信することを期待できる。文字比 較を実行する前に、検索パターンに対しフィルター及び正規化ルールを適用 することは、全面的に可能である。ただし、このような処理は、パターン一 致よりも登録された文字列の有効性を決定するために一般的により必要とさ れる。 非US-ASCII文字を包含するクエリ文字列を提示しているRDAPクライアントは、 それら文字列をUTF-8 符号化のUnicodeに変換する。その後、必要な場合に、 ローカルケースマッピングを実行する。 文字列は、正規化形式C（NFC）[Unicode-UAX15] を用いて正規化される。ク ライアントはこれを確実に実行できないかもしれないことに注意する。 UTF-8符号化文字列は、その後適切にクエリURL上でパーセントエンコード [RFC3986] される。 パーセントエンコードの構文解析後に、RDAPサーバーは各クエリをUTF-8符 号化Unicodeとして取り扱う。もし文字列が無効なUTF-8の場合、サーバーは 速やかにクエリ処理を停止し、HTTP 400（Bad Request）応答を返すことが できる。 クエリを処理する際、仮適合U-label及びそれ以外も含め、DNS名の処理方法 に違いが存在する。DNS名は、NR-LDH（Non-Reserved LDH）ラベル（訳注： A-labelではない通常のASCIIラベル）に関するRFC 1035 [RFC1035] の Section 3.1及び、U-labels に関するRFC 5891 [RFC5891] のSection 5.4で 説明されている一致ルールに準じて取り扱われる。DNS名の一致は、 U-labelsとNR-LDH labelsの組み合わせが単一のドメイン名またはホスト名 で確認できるため、一度に一つのラベルを処理する。 Newton & Hollenbeck Standards Track [Page 15] RFC 7482 RDAP Query Format March 2015 そのラベルがU-labelかNR-LDH labelかの決定は、そのラベルがUS-ASCIIの 文字、数字、ハイフン以外の文字を含むかどうかに準じる（いわゆるLDHルー ル）。 それ以外のすべてにおいて、サーバーは全角及び半角文字を、分解等価な文 字にマッピングする。サーバーは、検索された対象データと同じ符号化文字 集合へ文字列を変換し、各文字列は対象データに使用された同じ正規化を用 いて正規化される。一般的には、Unicodeの文字列格納が推奨される（ RECOMMENDED）。比較する目的で、正規化形式KC（NFKC）[Unicode-UAX15] と 文字種の統一化が、予測可能性と一致の件数を最大化するために使用される。 このケースでは、NFCと対照的に、文字種の統一化とNFKCを使用しているこ とに注意する。 7. Security Considerations 本ドキュメントで規定されている運用業務のためのセキュリティサービスは、 "Security Services for the Registration Data Access Protocol（RDAP）" [RFC7481] で説明されている。 検索機能は、簡易な検索機能より多くのサーバーリソース（メモリ、CPUサ イクル、ネットワーク帯域幅など）を一般的に必要とする。これは、サーバー リソースの消耗及び悪用によるサービス妨害のリスクを高める。このリスク は、特定されかつ認可されたクライアントに検索機能を制限するための制御 機能の開発や実装によって緩和することができる。もしそれらのクライアン トが好ましくない挙動を起こした場合、その検索特権は、停止または取り消 すことができる。"HTTP Usage in the Registration Data Access Protocol （RDAP）" [RFC7480] のSection 5.5で説明されているレート制限もまた、 受信する検索リクエストのレートを制御するために使用できる。サーバーオ ペレーターは、検索リクエストの応答で返される情報量を制限することでリ スクを軽減することもできる。 検索機能は、別な方法では明らかにならないオブジェクトの関連性情報を開 示するプライバシーリスクも高める。例えば、クライアントが提供する検索 パターンに明示的に一致しないIDN異体文字 [RFC6927] を返す検索は、別な 方法では入手できない登録ドメイン名に関する情報を開示できてしまう。実 装者は、明示的に要求していない情報を返されることに関するポリシー及び プライバシーの意味合いを考慮する必要がある。 すべてのクライアントに公平に適用する、唯一の、静的な返却情報に関する ポリシーは、存在しないかもしれないことにも注意する。クライアントの識 別及び関連する認可は、特定のクエリに対してどれだけ広範な応答集合とな るかを決定する関連要素となる。 Newton & Hollenbeck Standards Track [Page 16] RFC 7482 RDAP Query Format March 2015 8. References 8.1. Normative References [RFC0952] Harrenstien, K., Stahl, M., and E. Feinler, "DoD Internet host table specification", RFC 952, October 1985, . [RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987, . [RFC1123] Braden, R., Ed., "Requirements for Internet Hosts - Application and Support", STD 3, RFC 1123, October 1989, . [RFC1166] Kirkpatrick, S., Stahl, M., and M. Recker, "Internet numbers", RFC 1166, July 1990, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997, . [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005, . [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, February 2006, . [RFC4632] Fuller, V. and T. Li, "Classless Inter-domain Routing (CIDR): The Internet Address Assignment and Aggregation Plan", BCP 122, RFC 4632, August 2006, . [RFC4918] Dusseault, L., Ed., "HTTP Extensions for Web Distributed Authoring and Versioning (WebDAV)", RFC 4918, June 2007, . [RFC5396] Huston, G. and G. Michaelson, "Textual Representation of Autonomous System (AS) Numbers", RFC 5396, December 2008, . Newton & Hollenbeck Standards Track [Page 17] RFC 7482 RDAP Query Format March 2015 [RFC5730] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)", STD 69, RFC 5730, August 2009, . [RFC5733] Hollenbeck, S., "Extensible Provisioning Protocol (EPP) Contact Mapping", STD 69, RFC 5733, August 2009, . [RFC5890] Klensin, J., "Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework", RFC 5890, August 2010, . [RFC5891] Klensin, J., "Internationalized Domain Names in Applications (IDNA): Protocol", RFC 5891, August 2010, . [RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6 Address Text Representation", RFC 5952, August 2010, . [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing", RFC 7230, June 2014, . [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content", RFC 7231, June 2014, . [RFC7480] Newton, A., Ellacott, B., and N. Kong, "HTTP Usage in the Registration Data Access Protocol (RDAP)", RFC 7480, March 2015, . [RFC7481] Hollenbeck, S. and N. Kong, "Security Services for the Registration Data Access Protocol (RDAP)", RFC 7481, March 2015, . [RFC7483] Newton, A. and S. Hollenbeck, "JSON Responses for the Registration Data Access Protocol (RDAP)", RFC 7483, March 2015, . [RFC7484] Blanchet, M., "Finding the Authoritative Registration Data (RDAP) Service", RFC 7484, March 2015, . Newton & Hollenbeck Standards Track [Page 18] RFC 7482 RDAP Query Format March 2015 [Unicode-UAX15] The Unicode Consortium, "Unicode Standard Annex #15: Unicode Normalization Forms", September 2013, . 8.2. Informative References [REST] Fielding, R., "Architectural Styles and the Design of Network-based Software Architectures", Ph.D. Dissertation, University of California, Irvine, 2000, . [RFC3912] Daigle, L., "WHOIS Protocol Specification", RFC 3912, September 2004, . [RFC4007] Deering, S., Haberman, B., Jinmei, T., Nordmark, E., and B. Zill, "IPv6 Scoped Address Architecture", RFC 4007, March 2005, . [RFC4290] Klensin, J., "Suggested Practices for Registration of Internationalized Domain Names (IDN)", RFC 4290, December 2005, . [RFC6874] Carpenter, B., Cheshire, S., and R. Hinden, "Representing IPv6 Zone Identifiers in Address Literals and Uniform Resource Identifiers", RFC 6874, February 2013, . [RFC6927] Levine, J. and P. Hoffman, "Variants in Second-Level Names Registered in Top-Level Domains", RFC 6927, May 2013, . Acknowledgements This document is derived from original work on RIR query formats developed by Byron J. Ellacott of APNIC, Arturo L. Servin of LACNIC, Kaveh Ranjbar of the RIPE NCC, and Andrew L. Newton of ARIN. Additionally, this document incorporates DNR query formats originally described by Francisco Arias and Steve Sheng of ICANN and Scott Hollenbeck of Verisign Labs. The authors would like to acknowledge the following individuals for their contributions to this document: Francisco Arias, Marc Blanchet, Ernie Dainow, Jean-Philippe Dionne, Byron J. Ellacott, Behnam Esfahbod, John Klensin, John Levine, Edward Lewis, Mark Nottingham, Kaveh Ranjbar, Arturo L. Servin, Steve Sheng, and Andrew Sullivan. Newton & Hollenbeck Standards Track [Page 19] RFC 7482 RDAP Query Format March 2015 Authors' Addresses Andrew Lee Newton American Registry for Internet Numbers 3635 Concorde Parkway Chantilly, VA 20151 United States EMail: andy@arin.net URI: http://www.arin.net Scott Hollenbeck Verisign Labs 12061 Bluemont Way Reston, VA 20190 United States EMail: shollenbeck@verisign.com URI: http://www.verisignlabs.com/ Newton & Hollenbeck Standards Track [Page 20] RFC7482-ja.txt revision 1.0 この翻訳文に関するお問い合わせは dnstech-info@jprs.jp までご連絡下さい。 Japan Registry Services Co., Ltd. https://jprs.jp/tech/