Internet Engineering Task Force (IETF) A. Newton Request for Comments: 7480 ARIN Category: Standards Track B. Ellacott ISSN: 2070-1721 APNIC N. Kong CNNIC March 2015 Registration Data Access Protocol（RDAP）におけるHTTPの利用 Abstract 本ドキュメントは、RDAP（Registration Data Access Protocol）に関する 数多くの説明を取りまとめたものの一つである。RDAPがどのようにHTTP （Hypertext Transfer Protocol）を用いて通信されるかを説明している。 RDAPは、とても古くから使用されているWHOISプロトコルの後継プロトコル である。本ドキュメントの目的は、本アプリケーションの標準的なHTTPメカ ニズムの使用を明確にすることである。 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/rfc7480 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, et al. Standards Track [Page 1] RFC 7480 RDAP over HTTP March 2015 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Design Intents . . . . . . . . . . . . . . . . . . . . . . . 5 4. Queries . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 4.1. HTTP Methods . . . . . . . . . . . . . . . . . . . . . . 5 4.2. Accept Header . . . . . . . . . . . . . . . . . . . . . . 5 4.3. Query Parameters . . . . . . . . . . . . . . . . . . . . 6 5. Types of HTTP Response . . . . . . . . . . . . . . . . . . . 6 5.1. Positive Answers . . . . . . . . . . . . . . . . . . . . 6 5.2. Redirects . . . . . . . . . . . . . . . . . . . . . . . . 6 5.3. Negative Answers . . . . . . . . . . . . . . . . . . . . 7 5.4. Malformed Queries . . . . . . . . . . . . . . . . . . . . 7 5.5. Rate Limits . . . . . . . . . . . . . . . . . . . . . . . 7 5.6. Cross-Origin Resource Sharing (CORS) . . . . . . . . . . 8 6. Extensibility . . . . . . . . . . . . . . . . . . . . . . . . 8 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 8.1. RDAP Extensions Registry . . . . . . . . . . . . . . . . 9 9. Internationalization Considerations . . . . . . . . . . . . . 10 9.1. URIs and IRIs . . . . . . . . . . . . . . . . . . . . . . 10 9.2. Language Identifiers in Queries and Responses . . . . . . 10 9.3. Language Identifiers in HTTP Headers . . . . . . . . . . 10 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 10.1. Normative References . . . . . . . . . . . . . . . . . . 11 10.2. Informative References . . . . . . . . . . . . . . . . . 12 Appendix A. Protocol Example . . . . . . . . . . . . . . . . . . 13 Appendix B. Cache Busting . . . . . . . . . . . . . . . . . . . 13 Appendix C. Bootstrapping and Redirection . . . . . . . . . . . 14 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 15 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 Newton, et al. Standards Track [Page 2] RFC 7480 RDAP over HTTP March 2015 1. Introduction 本ドキュメントは、RDAP（Registration Data Access Protocol）における HTTP（Hypertext Transfer Protocol）[RFC7230] の利用方法について説明 している。本ドキュメントのゴールはREST（Representational State Transfer）[REST] アーキテクチャの様式が示す慣行を用いて、登録データ を提供するディレクトリサービスのさまざまなタイプに適用可能な共通プロ ファイルを、HTTPの使用パターンに結びつけることである。さまざまなディ レクトリサービスに共通の挙動を与えることで、この挙動に結びついたディ レクトリサービス群から、単一のクライアントが容易にデータを取得するこ とができる。 このサービスによって提示が期待される登録データは、ドメイン名とインター ネット番号資源が登録されたインターネット資源登録データである。このデー タは、通常WHOIS [RFC3912] サービスによって提供されているが、WHOISプ ロトコルは、現代の登録データサービスの要求を満たしていない。それを代 替するプロトコルは、WHOISの単純なトランザクションの特質を持続するこ とを期待されており、同時にクエリやレスポンスの仕様、権威のある情報源 へのリダイレクション、国際化ドメイン名（IDN）[RFC5890] のサポート、 住所、組織、個人名といった地域化された登録データのサポートなども提供 する。 共通使用パターンを設計するにあたり、本ドキュメントでは、シンプルに HTTPを利用した考察について紹介している。複雑さもあるかもしれないが、 本ドキュメントのゴールは、サーバー上に設置すること、そしてクライアン トにとって極力シンプルにすることである。クライアントの実装については、 一般的なオペレーティングシステムのスクリプト用ツール（例：bashやwget） を用いることで可能となる。 下記は、当該プロトコルの基本的な使用パターンを説明している。 1. クライアントが、問い合わせる適切なサーバー及びそのクエリに使用す る適切なベースURL（Uniform Resource Locator）を特定する。 [RFC7484] は、サーバーとベースURLを確定する一つの方法を説明して いる。詳細は、Appendix Cを参照。 2. クライアントは、GET [RFC7231] を用いてHTTP（またはHTTPS）クエリ を発信する。例として、192.0.2.0のネットワーク登録についてのクエ リURLは、以下のようになる。 http://example.com/rdap/ip/192.0.2.0 [RFC7482] では、RDAPで使用されるさまざまなクエリの詳細を説明して いる。 Newton, et al. Standards Track [Page 3] RFC 7480 RDAP over HTTP March 2015 3. 受信側サーバーがクエリに対する情報を保有していた場合、クエリの Acceptヘッダーフィールドを調べ、要求された適切なフォーマットでレ スポンスエンティティーと共に200応答を返す。[RFC7483] では、JSON （JavaScript Object Notation）のレスポンスの詳細を説明している。 4. 受信側サーバーがクエリに対する情報を保有しておらず、その情報の所 在に関する知識を保有していた場合、リダイレクト応答（3xx）と Locationヘッダーフィールド（その情報の所在を示すHTTP（S）URL、ま たはその情報の所在に関する知識を持つ他サーバーの所在情報を含む） を返す。クライアントは、そのHTTP URL情報を用いて再問い合わせを行 う。 5. 受信側サーバーがリクエストされている情報を保有しておらず、かつそ の情報の所在に関する知識を保有していない場合、404応答を返す。 6. クエリの受信側サーバーがポリシーを理由としてリクエストに応答した くない場合、無回答であることの理由を示唆するエラー応答（4xx）を 返すだろう。 本ドキュメントでは、HTTPの意義や語義を再定義することは意図していない。 本ドキュメントの目的は、本アプリケーションの標準的なHTTPメカニズムの 使用を明確にすることである。 2. Terminology 本ドキュメントにおける次の各キーワード「しなければならない（MUST）」、 「してはならない（MUST NOT）」、「要求されている（REQUIRED）」、「す ることになる（SHALL）」、「することはない（SHALL NOT）」、「すべきで ある（SHOULD）」、「すべきではない（SHOULD NOT）」、「推奨される （RECOMMENDED）」、「してもよい（MAY）」、「任意である（OPTIONAL）」 は、[RFC2119] で説明されているように解釈されるべきものである。 "Security and Stability Advisory Committee（SSAC）Report on WHOIS Terminology and Structure" [SAC-051] で記述されているように、"WHOIS" という用語・表現は、使われ過ぎており、プロトコル、サービス、データな ど広義な用語を指す目的で頻繁に利用されている。[SAC-051] の規則に従い、 本ドキュメントでは、RDAPの基本的な挙動を説明している。[SAC-051] は、 DNR（ドメイン名レジストリ）向けのRDAPのプロトコルプロファイルである DNRD-AP（ドメイン名登録データアクセスプロトコル）を説明している。 本ドキュメントでは、RDAPクライアントは、RDAPクエリを発信するHTTPユー ザーエージェントであり、またRDAPサーバーは、RDAPレスポンスを提供する HTTPサーバーである。RDAPクエリ及びレスポンスフォーマットについては、 [RFC7482] 及び[RFC7483] で説明されており、一方、本ドキュメントでは、 RDAPクライアント及びサーバーが、どのようにHTTPを使用してクエリやレス ポンスを情報交換するかを説明している。[RFC7481] は、RDAPのセキュリティ に関する考察について説明している。 Newton, et al. Standards Track [Page 4] RFC 7480 RDAP over HTTP March 2015 3. Design Intents 本ドキュメントでは、いくつかの設計基準に対応すべく、作成されている。 1点目：各クエリは、一つの回答を取得するために、たった一つの実行パス を必要とすることを意図されて作られている。レスポンスは、回答、無回答、 リダイレクトを含み、クライアントがクエリを作るために複数の実行パスを 生成することは想定されていない。 2点目：リクエストまたはレスポンスの語義は、将来と標準外（両方または いずれか一方）のレスポンスフォーマットを考慮している。本ドキュメント では、JSON [RFC7159] レスポンスメディアタイプだけが記述されており、 レスポンス内容とは別々に説明されている（[RFC7483] を参照）。本ドキュ メントは、RDAPが当該フォーマットでHTTPを用いてどのように通信されるか のみを説明する。 3点目：このプロトコルは、HTTPと共に利用可能なメカニズムの範囲を活用 できるようにすることを目的としている。HTTPは、本ドキュメントで説明し ていないさまざまなメカニズムも提供している。オペレーターは、キャッシュ 制御、認可、圧縮とリダイレクトを含む彼らのローカルポリシーに従って、 これらのメカニズムを使用することができる。HTTPは更に、REST [REST] 以 降のスタイルを用いたWebサービスにおけるクライアントの挙動を理解する 広範のプログラマーのみならず、拡張性、信頼性、パフォーマンスへの広範 囲にわたる投資から恩恵を受ける。そして、それは登録データディレクトリ サービス（RDDS）及びクライアントを展開するためのコストを削減する。こ のプロトコルは、HTTP 2.0.と上位互換性がある。 4. Queries 4.1. HTTP Methods クライアントは、レスポンス本体を検索するためにGETメソッドを使用し、 またHEADメソッドをサーバー上のデータの存在を確定するために使用する。 クライアントは、HTTP GETまたはHEADメソッドのどちらかを使用すべきであ る（[RFC7231] を参照）（SHOULD）。サーバーは、その他のHTTPメソッドを サポートする義務はない。このため、他のメソッドを用いるクライアントは、 適切に相互運用しないだろう。 クライアント及びサーバーは、セキュリティサービスをサポートするために、 HTTPSをサポートしなくてはならない（MUST）。 4.2. Accept Header RDAP応答が要望されていることをサーバーに示すために、クライアントは RDAP特有のJSONメディアタイプとジェネリックJSONメディアタイプのどちら かまたは両方を組み込んだAcceptヘッダーフィールドを含める。RDAPリクエ ストを受信したサーバーは、RDAP特有のJSONメディアタイプを含む Content-Typeヘッダーと共にエンティティーを返す。 Newton, et al. Standards Track [Page 5] RFC 7480 RDAP over HTTP March 2015 この仕様は、サーバーが、Acceptヘッダーフィールドにおける他のいかなる メディアタイプを含むリクエスト、またはAcceptヘッダーフィールドを含ま ないリクエストに返すレスポンスを定義するものではない。一つの可能性は、 Webブラウザー上の描画に適切なメディアタイプでレスポンスを返すことで ある。 4.3. Query Parameters サーバーは、不明なクエリパラメーターを無視しなくてはならない（MUST）。 キャッシュバスティングの不明なクエリパラメーターの利用は、Appendix B で説明されている。 5. Types of HTTP Response このセクションでは、サーバーがクライアントに対して送信するさまざまな 応答タイプを説明している。非標準のHTTP応答コードは、その使用が禁じら れている一方、このセクションでは、クライアントが理解すべき、サーバー で一般的に使用されている応答コードの最小セットを定義している。いくつ かのクライアントは、これらすべての応答コードを考慮しないシンプルなツー ルで構築されるかもしれない。これらコードを考慮したより堅牢なクライア ントは、より優れたユーザーエクスペリエンスを提供できる。ここで定義さ れていない本アプリケーションの応答コード及びタイプに関する使用方法は、 後続に発行されるドキュメントで説明されることが期待される。 5.1. Positive Answers もしサーバーがクライアントのリクエスト情報を受信し、サーバーのポリシー に従った情報に基づきそのクライアントに応答すると判断した場合、200 （OK）応答の本体内に回答を返す（[RFC7231] を参照）。 5.2. Redirects もしサーバーがクライアントに対し、送信されたクエリに対する回答が他サー バーで検索可能であることを伝えたい場合、恒久的な移動を示すために301 （Moved Permanently）、302（Found）、303（See Other）、一時的リダイ レクトを示すために307（Temporary Redirect）の応答コードを返す。それ は、ロケーションヘッダーフィールド内のHTTP（S）URLを含む（[RFC7231] を参照）。クライアントは、いかなるURL処理を行わずに与えられたURLを用 いて元のクエリを満たす後続リクエストを発行することが期待される。つま り、サーバーは完全なURLを返し、そしてクライアントはそれに従うために URLを変換する必要がない。サーバーは、[RFC7482] に準拠したURLの応答を 返す義務はない。 Newton, et al. Standards Track [Page 6] RFC 7480 RDAP over HTTP March 2015 本アプリケーションのために、そのような恒久的な移動の例は、TLD（Top- Level Domain）オペレーターがクライアントに、検索された情報が他のTLD オペレーターによって検索可能であることを知らせるかもしれない。 （barというドメイン名のクエリがfoo.example上で検索された例： http://foo.example/domain/bar） 例えば、もしクライアントが下記URLを指定した場合、 http://serv1.example.com/weirds/domain/example.com サーバーは、下記URLにリダイレクトし、 https://serv2.example.net/weirds2/ Location:フィールドに下記の値を設定する。 https://serv2.example.net/weirds2/domain/example.com 5.3. Negative Answers もしサーバーが、空の結果のセットである（すなわち、クエリを適切に満足 させるデータがない）ことを応答したい場合、404（Not Found）応答コード を返す。任意で、HTTPエンティティー本体内に不在応答に関する追加情報を 含めてもよい（MAY）。 もしサーバーが、クエリが有効であるとの情報をクライアントに知らせたい が、ポリシーを理由としてクライアントに対してレスポンス内に応答情報を 含めることができない場合、サーバーはHTTPの4xx範囲外の適切な応答コー ドで応答しなくてはならない（MUST）。クライアントは、それが各応答コー ドに対し適切である場合、クエリを再試行することができる（MAY）。 5.4. Malformed Queries もしサーバーが、RDAPクエリとして解釈できないクエリを受信した場合、 400（Bad Request）応答コードを返す。任意で、HTTPエンティティー本体内 に不在応答に関する追加情報を含めてもよい（MAY）。 5.5. Rate Limits サーバーによっては、アドレス収集やその他の不正利用の抑止のためにレー ト制限を適用している。サーバーが、レート制限によってクエリに対する回 答を拒否した場合、[RFC6585] で説明されている429（Too Many Requests） 応答コードを返す。429応答を受信したクライアントは、そのクエリレート を減少させ、かつRetry-Afterヘッダーフィールドがある場合は、それに従 うべきである（SHOULD）。サーバーは、Retry-Afterヘッダーに従わないク ライアントに対しては、より厳しい制限を課すことができる。任意で、サー バーは、HTTPエンティティー本体内にレート制限に関する追加情報を含めて もよい（MAY）。 Newton, et al. Standards Track [Page 7] RFC 7480 RDAP over HTTP March 2015 悪意のあるクライアントは、コードを無視し、高いレートでクエリを送信し 続けることがあるので、これがDoS（denial-of-service）攻撃に対する防御 ではないことに注意する。サーバーは、クライアントに対しレート制限が応 答拒否の理由であることを明らかにしたくない場合は、別の応答コードを使 用することができる。 5.6. Cross-Origin Resource Sharing (CORS) クエリに応答する際、サーバーはAccess-Control-Allow-Originヘッダー フィールド（[W3C.REC-cors-20140116] で規定されている）を使用すること が推奨されている（RECOMMENDED）。 RDAPが公の資源に対して使用される場合、"* "の値が適している。 このヘッダー（CORS（Cross-Origin Resource Sharing）ヘッダーと呼ばれ ることが多い）は、同一生成元"same-origin"の制限を引き上げことで、Web ブラウザー上で動作するアプリケーションをサポートする（例：ブラウザー はWebサーバーからRDAPクライアントコードを読み込むことができるが、そ の他のサーバーにもRDAPデータのクエリを発信できる）。 デフォルトでは、生成元の異なるリクエストが許された環境の場合、ブラウ ザーはcookieを送信しない。Access-Control-Allow-Credentialsヘッダー フィールドを"true"に設定するとcookieを送信する。ただし、 Access-Control-Allow-Credentialsヘッダーフィールドを使用することは推 奨されない（NOT RECOMMENDED）。 6. Extensibility 拡張性を目的とし、本ドキュメントではJSON [RFC7159] データの連続化及 びURIパス部（Section 8を参照）で使用されるプレフィックスのIANAレジス トリを定義している。 プレフィックスや識別子は、US-ASCIIのアルファベット文字コードのA～Z （大文字及び小文字）、数字記号の0～9及び下線記号のみで構成されるべき であり（SHOULD）、またそれらは、下線記号、数字記号または"xml"という 文字で開始すべきではない（SHOULD NOT）。 以下は、ABNF（Augmented Backus-Naur Form）記法のJSON名称を説明してい る [RFC5234]。 name = ALPHA *( ALPHA / DIGIT / "_" ) Figure 1: ABNF記法のJSON名称 この制限は、プログラミング言語Rubyの識別子構文とXML要素名構文を結合 したものであり、二つの目的がある。 目的1：RubyやJavaのような最新のプログラミング言語を用いるクライアン ト実装者は、1次オブジェクトの属性もしくはメンバーにJSON名を自動的に 勧めるライブラリ群を使用することができる。 Newton, et al. Standards Track [Page 8] RFC 7480 RDAP over HTTP March 2015 目的2：これらのルールを用いて、JSONとXML間の完全なマッピングが容易に 達成できる。 7. Security Considerations 本ドキュメントでは、RDAPプロトコルに関して強固なセキュリティ要求を提 起していない。しかしながら、本ドキュメントはHTTPプロトコルが提供する セキュリティメカニズムの使用を制限しない。本ドキュメントは、RDAPクラ イアント及びサーバーがHTTPSをサポートしなくてはならない（MUST）こと を要求する。 本ドキュメントは、DoSに対抗するサーバー実装（Section 5.5を参照）及び HTTPクライアント用の既存セキュリティメカニズムとの相互運用性 （Section 5.6）を推奨している。 RDAPプロトコルに関連する追加のセキュリティの考察については、 [RFC7481] で取り上げられている。 8. IANA Considerations 8.1. RDAP Extensions Registry IANAは、プロトコルレジストリに関する新しいカテゴリーとして "Registration Data Access Protocol（RDAP）"を生成し、そのカテゴリー の中にURL参照可能かつ独立型のレジストリラベル"RDAP Extensions"を確立 させた。このレジストリの目的は、拡張識別子の一意性を確保するためであ る。この拡張識別子は、JSON名称内のプレフィックス及びRDAP URL内のパス セグメントのプレフィックスとして使用されている。 これらの識別子に対する生成ルールは、Section 6で規定されている。 [RFC5226] に従い、新たな値を指定することに関するIANAのポリシーでは、 仕様が要求される。値及びその値の意味は、独立した実装間での相互運用が 可能になるよう、充分に詳しく、RFC、または永続的かつ容易に利用可能な 参照に文書化されなければならない。 以下は、RDAP拡張登録のテンプレートである。 拡張識別子：識別子の拡張を表す レジストリオペレーター：レジストリオペレーターの名称 公開仕様：RFC番号、書誌の参照、または永続的かつ容易に利用可能な仕 様へのURL 更なる情報のための連絡先の個人と電子メールアドレス：当該レジスト リエントリーに関してコンタクトを取るための個人の名前及び電子メー ルアドレス Newton, et al. Standards Track [Page 9] RFC 7480 RDAP over HTTP March 2015 使用目的：レジストリエントリーの簡潔な理由（[RFC5226] で定義され る） 以下は、RDAP拡張レジストリに関する登録情報の例である。 拡張識別子：lunarNic レジストリオペレーター：The Registry of the Moon, LLC 公開仕様：http://www.example/moon_apis/rdap 更なる情報のための連絡先の個人と電子メールアドレス： Professor Bernardo de la Paz 使用目的：一般 9. Internationalization Considerations 9.1. URIs and IRIs クライアントは、RDAPサーバーとの相互作用に関して統一資源識別子（URI） [RFC3986] に変換しなければならない（MUST）ことを前提に、内部使用目的 に該当する場合は、国際化URI（Internationalized Resource Identifiers） [RFC3987] を使用することができる。RDAPサーバーは、すべての応答につい てURIを使用しなくてはならない（MUST）。またクライアントも内部使用目的 に該当する場合は、URIから国際化URIに変換することができる。 9.2. Language Identifiers in Queries and Responses ほとんどのシナリオにおいて、データをリクエストするクライアントは、そ のデータが特定の言語やスクリプトであるということを返されることを伝え ない。その一方で、サーバーがデータを返し、そのデータが特定の言語やス クリプトであるという知識を保有している場合、そのデータは、データ自体 が利用可能な時はいつでも、言語識別子の注釈を付与すべきである （SHOULD）。その結果、クライアントは、それに応じてデータの処理や表示 が可能となる。 [RFC7483] では、そのようなメカニズムを提供している。 9.3. Language Identifiers in HTTP Headers Section 9.2の言語識別子の利用に関する説明に基づき、特に指定がない限 り、サーバーはHTTPエンティティー応答を構成する際、HTTP [RFC7231] Accept-Language ヘッダーフィールドを無視すべきである（SHOULD）。そう することによって、クライアントは、エンティティー本体内の Accept-Language ヘッダーフィールドと'lang'（言語識別子）の値を混在し ないようになる。 Newton, et al. Standards Track [Page 10] RFC 7480 RDAP over HTTP March 2015 しかしながら、HTTP層のメッセージの対象言語に関する情報をクライアント に知らせるために、サーバーはContent- Languageヘッダーフィールド内の 言語識別子を返すことができる（MAY）。 10. References 10.1. Normative References [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, . [RFC3987] Duerst, M. and M. Suignard, "Internationalized Resource Identifiers (IRIs)", RFC 3987, January 2005, . [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008, . [RFC6585] Nottingham, M. and R. Fielding, "Additional HTTP Status Codes", RFC 6585, April 2012, . [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, . [RFC7481] Hollenbeck, S. and N. Kong, "Security Services for the Registration Data Access Protocol (RDAP)", RFC 7481, February 2015, . [RFC7482] Newton, A. and S. Hollenbeck, "Registration Data Access Protocol (RDAP) Query Format", RFC 7482, February 2015, . [RFC7483] Newton, A. and S. Hollenbeck, "JSON Responses for the Registration Data Access Protocol (RDAP)", RFC 7483, February 2015, . Newton, et al. Standards Track [Page 11] RFC 7480 RDAP over HTTP March 2015 [RFC7484] Blanchet, M., "Finding the Authoritative Registration Data (RDAP) Service", RFC 7484, February 2015, . [W3C.REC-cors-20140116] Kesteren, A., "Cross-Origin Resource Sharing", W3C Recommendation, REC-cors-20140116, January 2014, . 10.2. Informative References [REST] Fielding, R. and R. Taylor, "Principled Design of the Modern Web Architecture", ACM Transactions on Internet Technology, Vol. 2, No. 2, May 2002. [RFC3912] Daigle, L., "WHOIS Protocol Specification", RFC 3912, September 2004, . [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, January 2008, . [RFC5890] Klensin, J., "Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework", RFC 5890, August 2010, . [RFC7159] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data Interchange Format", RFC 7159, March 2014, . [SAC-051] Piscitello, D., Ed., "SSAC Report on Domain Name WHOIS Terminology and Structure", A report from the ICANN Security and Stability Advisory Committee (SSAC), September 2011. [lacnic-joint-whois] LACNIC, "Joint Whois", December 2005, . Newton, et al. Standards Track [Page 12] RFC 7480 RDAP over HTTP March 2015 Appendix A. Protocol Example RDAPクライアントとサーバーの典型的な挙動を示すために、下記にリダイレ クトを含む情報交換の例を挙げている。 本ドキュメントでは、データフォーマットが説明されていないので、応答の 中身のデータは簡潔さのため省略する。 ここで使用されるメディアタイプは、[RFC7483] で説明されている。 RDAPクライアントとサーバーの情報交換の例： Client: GET /rdap/ip/203.0.113.0/24 HTTP/1.1 Host: rdap.example.com Accept: application/rdap+json rdap.example.com: HTTP/1.1 301 Moved Permanently Location: http://rdap-ip.example.com/rdap/ip/203.0.113.0/24 Content-Length: 0 Content-Type: application/rdap+json Client: GET /rdap/ip/203.0.113.0/24 HTTP/1.1 Host: rdap-ip.example.com Accept: application/rdap+json rdap-ip.example.com: HTTP/1.1 200 OK Content-Type: application/rdap+json Content-Length: 9001 { ... } Appendix B. Cache Busting 一部のHTTP [RFC7230] キャッシュインフラは、キャッシング標準を適切に 遵守せず、サーバーが意図するよりも長い応答をキャッシュすることができ る。 これらの問題に対処するには、クライアントは、アドホックかつありそうに ないランダムな値を用いたクエリパラメーターを使用する。 Section 4.3はサーバーが未知のパラメーターを無視するよう指示している ので、RDAPの定義と互換性がある。 Newton, et al. Standards Track [Page 13] RFC 7480 RDAP over HTTP March 2015 キャッシュを壊すために未知のクエリパラメーターを用いる例： http://example.com/ip/192.0.2.0?__fuhgetaboutit=xyz123 異常動作しているキャッシュに対処するために未知のパラメーターを使用す ることは、どの仕様上の一部でもなく、情報提供の目的のために提供されて いる。 Appendix C. Bootstrapping and Redirection WHOIS [RFC3912] の伝統的な普及モデルは、権威のある情報源を決定するメ カニズムを提供しない。 過去、いくつかのアプローチが実装されているが、その中でも最も著名なの はJoint WHOIS [lacnic-joint-whois] の取組みである。 しかし、その欠点として、Joint WHOISはプロキシーとサーバーサイドの照 会を用いて実装されている。 これらの問題は、RDAPでは、HTTPリダイレクトとブートストラップを用いて 解決される。 ブートストラップは、[RFC7484] で論じられている。 制約された環境では、[RFC7484] で概説された処理は、実行不可能かもしれ ず、また"redirector"として作動しているサーバーが必要になるかもしれな い。 リダイレクターサーバーは、[RFC7484] で示されたリダイレクションテーブ ルを用いるクライアントにHTTPリダイレクトを発行する。 Figure 2は、ブートストラップのリダイレクターを用いたクライアントを示 す。 REDIRECTOR ARIN RDAP RDAP . . | | Q: 23.1.1.1? -----------------> | | | | <---------- HTTP 301 --------| | ('Try ARIN RDAP') | | | | | Q: 23.1.1.1? -------------------------------> | | <---------- HTTP 200 --------------------- | (JSON response is returned) | | | . Figure 2: 23.1.1.1のRDAPデータのクエリ Newton, et al. Standards Track [Page 14] RFC 7480 RDAP over HTTP March 2015 一部の例では、具体的に"ERX space"として知られるRIR（地域インターネッ トレジストリ）間のネットワークの移転において行われる二次的な委任の場 合などで、複数のHTTPリダイレクトが実行される。 Figure 3は、そのようなシナリオを表す。 REDIRECTOR LACNIC ARIN RDAP RDAP RDAP . . . Q: 23.1.1.1? ----> | | | | | | <-- HTTP 301 --- | | | ('Try LACNIC') | | | | | | | | | Q: 23.1.1.1? -----------------> | | | | <---------- HTTP 301 --------| | ('Try ARIN RDAP') | | | | | Q: 23.1.1.1? -------------------------------> | | <---------- HTTP 200 --------------------- | (JSON response is returned) | | | . Figure 3: 移転されたデータのRDAPデータのクエリ Acknowledgements John Levine provided text to tighten up the Accept header field usage and the text for the section on 429 responses. Marc Blanchet provided some clarifying text regarding the use of URLs with redirects, as well as very useful feedback during Working Group Last Call (WGLC). Normative language reviews were provided by Murray S. Kucherawy, Andrew Sullivan, Tom Harrison, Ed Lewis, and Alexander Mayrhofer. Jean-Phillipe Dionne provided text for the Security Considerations section. The concept of the redirector server informatively discussed in Appendix C was documented by Carlos M. Martinez and Gerardo Rada of Newton, et al. Standards Track [Page 15] RFC 7480 RDAP over HTTP March 2015 LACNIC and Linlin Zhou of CNNIC and subsequently incorporated into this document. This document is the work product of the IETF's WEIRDS working group, of which Olaf Kolkman and Murray Kucherawy were chairs. 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 Byron J. Ellacott Asia Pacific Network Information Centre 6 Cordelia Street South Brisbane QLD 4101 Australia EMail: bje@apnic.net URI: http://www.apnic.net Ning Kong China Internet Network Information Center 4 South 4th Street, Zhongguancun, Haidian District Beijing 100190 China Phone: +86 10 5881 3147 EMail: nkong@cnnic.cn Newton, et al. Standards Track [Page 16] RFC7480-ja.txt revision 1.0 この翻訳文に関するお問い合わせは dnstech-info@jprs.jp までご連絡下さい。 Japan Registry Services Co., Ltd. https://jprs.jp/tech/