Internet Engineering Task Force (IETF) A. Newton Request for Comments: 7483 ARIN Category: Standards Track S. Hollenbeck ISSN: 2070-1721 Verisign Labs March 2015 Registration Data Access Protocol(RDAP)のためのJSON応答 Abstract 本ドキュメントは、RIR(地域インターネットレジストリ)及びDNR(ドメイ ン名レジストリ)が維持する登録情報を表記するJSONのデータ構造を説明す る。データ構造は、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/rfc7483 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 7483 RDAP JSON Responses March 2015 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Terminology and Definitions . . . . . . . . . . . . . . . 3 1.2. Data Model . . . . . . . . . . . . . . . . . . . . . . . 4 2. Use of JSON . . . . . . . . . . . . . . . . . . . . . . . . . 5 2.1. Naming . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Common Data Types . . . . . . . . . . . . . . . . . . . . . . 7 4. Common Data Structures . . . . . . . . . . . . . . . . . . . 8 4.1. RDAP Conformance . . . . . . . . . . . . . . . . . . . . 8 4.2. Links . . . . . . . . . . . . . . . . . . . . . . . . . . 9 4.3. Notices and Remarks . . . . . . . . . . . . . . . . . . . 10 4.4. Language Identifier . . . . . . . . . . . . . . . . . . . 12 4.5. Events . . . . . . . . . . . . . . . . . . . . . . . . . 12 4.6. Status . . . . . . . . . . . . . . . . . . . . . . . . . 13 4.7. Port 43 WHOIS Server . . . . . . . . . . . . . . . . . . 13 4.8. Public IDs . . . . . . . . . . . . . . . . . . . . . . . 13 4.9. Object Class Name . . . . . . . . . . . . . . . . . . . . 14 4.10. An Example . . . . . . . . . . . . . . . . . . . . . . . 14 5. Object Classes . . . . . . . . . . . . . . . . . . . . . . . 15 5.1. The Entity Object Class . . . . . . . . . . . . . . . . . 16 5.2. The Nameserver Object Class . . . . . . . . . . . . . . . 22 5.3. The Domain Object Class . . . . . . . . . . . . . . . . . 25 5.4. The IP Network Object Class . . . . . . . . . . . . . . . 37 5.5. Autonomous System Number Entity Object Class . . . . . . 41 6. Error Response Body . . . . . . . . . . . . . . . . . . . . . 44 7. Responding to Help Queries . . . . . . . . . . . . . . . . . 45 8. Responding To Searches . . . . . . . . . . . . . . . . . . . 46 9. Indicating Truncated Responses . . . . . . . . . . . . . . . 47 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 49 10.1. RDAP JSON Media Type Registration . . . . . . . . . . . 49 10.2. JSON Values Registry . . . . . . . . . . . . . . . . . . 50 10.2.1. Notice and Remark Types . . . . . . . . . . . . . . 52 10.2.2. Status . . . . . . . . . . . . . . . . . . . . . . . 53 10.2.3. Event Actions . . . . . . . . . . . . . . . . . . . 58 10.2.4. Roles . . . . . . . . . . . . . . . . . . . . . . . 61 10.2.5. Variant Relations . . . . . . . . . . . . . . . . . 64 11. Security Considerations . . . . . . . . . . . . . . . . . . . 65 12. Internationalization Considerations . . . . . . . . . . . . . 65 12.1. Character Encoding . . . . . . . . . . . . . . . . . . . 65 12.2. URIs and IRIs . . . . . . . . . . . . . . . . . . . . . 65 12.3. Language Tags . . . . . . . . . . . . . . . . . . . . . 65 12.4. Internationalized Domain Names . . . . . . . . . . . . . 66 13. Privacy Considerations . . . . . . . . . . . . . . . . . . . 66 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 66 14.1. Normative References . . . . . . . . . . . . . . . . . . 66 14.2. Informative References . . . . . . . . . . . . . . . . . 68 Newton & Hollenbeck Standards Track [Page 2] RFC 7483 RDAP JSON Responses March 2015 Appendix A. Suggested Data Modeling with the Entity Object Class 69 A.1. Registrants and Contacts . . . . . . . . . . . . . . . . 69 A.2. Registrars . . . . . . . . . . . . . . . . . . . . . . . 71 Appendix B. Modeling Events . . . . . . . . . . . . . . . . . . 73 Appendix C. Structured vs. Unstructured Addresses . . . . . . . 75 Appendix D. Secure DNS . . . . . . . . . . . . . . . . . . . . . 77 Appendix E. Motivations for Using JSON . . . . . . . . . . . . . 78 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 79 1. Introduction 本ドキュメントは、Registration Data Access Protocol Query Format [RFC7482] で定義されているJSON [RFC7159] 形式のクエリに対する応答を 説明する。クエリや応答を交換するための通信プロトコルについては、 [RFC7480] で説明されている。 1.1. Terminology and Definitions 本ドキュメントにおける次の各キーワード(すべて大文字で規定されている 場合)「しなければならない(MUST)」、「してはならない(MUST NOT)」、 「要求されている(REQUIRED)」、「することになる(SHALL)」、「する ことはない(SHALL NOT)」、「すべきである(SHOULD)」、「すべきでは ない(SHOULD NOT)」、「推奨される(RECOMMENDED)」、「してもよい (MAY)」、「任意である(OPTIONAL)」は、[RFC2119] で説明されている ように解釈されるべきものである。 下記リストは、本ドキュメントで使用されている専門用語や定義を説明して いる。 DNR:ドメイン名レジストリ LDH:"letters"、"digits"、"hyphen"(文字、数字、ハイフン) member(メンバー):JSON [RFC7159] で定義されているオブジェクト内の データ object(オブジェクト):JSON [RFC7159] で定義されているデータ構造 object class(オブジェクトクラス):本ドキュメントで説明されている JSONオブジェクトに存在するメンバー"members"の定義 object instance(オブジェクトインスタンス):あるオブジェクトクラス のインスタンス化または具体化されたインスタンス RDAP:Registration Data Access Protocol RIR:地域インターネットレジストリ Newton & Hollenbeck Standards Track [Page 3] RFC 7483 RDAP JSON Responses March 2015 1.2. Data Model JSON応答におけるデータモデルは、五つのセクションで規定されている。 1. JSON文字列で搬送される単純データ型 2. より大きなオブジェクトを築き上げる際に繰り返し使用されるJSON配列 またはオブジェクトとして規定されたデータ構造 3. 単一オブジェクトの検索に対応する構造化データを表記するオブジェク トクラス 4. 複数オブジェクトの検索に対応する構造化データを表記するオブジェク トの配列 5. エラーに対する応答 二つの主要なデータ分類項目における応答形式を表記するオブジェクトクラ ス: ・IPアドレス、逆引きDNS名、AS(自律システム)番号に関連付けられた登 録データをRIR(地域インターネットレジストリ)が返す応答、 ・正引きDNS名に関連付けられた登録データをDNR(ドメイン名レジストリ) が返す応答。 下記のオブジェクトクラスは、RIR及びDNRの両方が返す。 1. ドメイン 2. ネームサーバー 3. エンティティー 上記オブジェクトクラスに関するRIR及びDNRの両方が提供する情報は、広範 囲にわたり重複し、その情報は本ドキュメントで両サービスのクラスのため に統一モデルとして記述されている。 上記オブジェクトクラスに加え、RIRは下記のオブジェクトクラスも提供し ている。 1. IPネットワーク 2. AS番号 本ドキュメントで定義されているオブジェクトクラスは、対応クライアント またはサーバーが正確に機能するために理解すべき最小セットを示している。 しかしながら、デプロイの一部は、個別の必要性に応じて追加のオブジェク トクラスを含めたいかもしれない。このような拡張機能の必要性を予期して、 本ドキュメントのSection 2.1では、本ドキュメントで説明されているJSON オブジェクトを拡張するためのメカニズムを定義する。 Newton & Hollenbeck Standards Track [Page 4] RFC 7483 RDAP JSON Responses March 2015 正常応答は、二つの形式を用いる。 ・登録システム内の単一オブジェクトの検索への応答が、検索対象のJSONオ ブジェクトを生成する。 ・複数オブジェクトの検索への応答が、検索対象のJSONオブジェクト配列を 含むJSONオブジェクトを生成する。 各応答型では、最上位のJSONオブジェクトの中に他のデータ構造が存在する。 2. Use of JSON 2.1. Naming JSON応答を受信するクライアントは、応答における認識されていないJSONメ ンバーを無視すべきである(SHOULD)。サーバーは、本ドキュメントで規 定されていないJSON応答の中にメンバーを挿入することができるが、それは 応答においてエラーと見なされない。 JSON応答にそのような未規定のメンバーを挿入するサーバーは、短い識別子、 続いて下線記号、続いて意味を持つ名称を冠するメンバー名を持つべきであ る(SHOULD)。これらの短い識別子は、ソフトウェア実装者がJSONメンバー の仕様を識別することを援助していることが今までに報告されている。短い 識別子の使用を怠ることは、サーバーが本仕様から誤って名前を使用してい ると実装者が思い込むことを引き起こすかもしれない。この許容は、jCard [RFC7095] オブジェクトには適用しない。完全なJSON名称(プレフィックス +下線記号+意味を持つ名称)は、[RFC7480] で説明されているプレフィッ クスのレジストリの文字及び名称の制限を守るべきである(SHOULD)。これ らの制限は、いくつかのクライアントプログラミングモデルを援助すること が報告されており、これらの制限の使用を怠ることは、より遅い採用という 結果をもたらすかもしれない。 本ドキュメントで規定されているすべてのJSONメンバーを用いた下記のJSON 応答を考える: { "handle" : "ABC123", "remarks" : [ { "description" : [ "She sells sea shells down by the sea shore.", "Originally written by Terry Sullivan." ] } ] } Figure 1 Newton & Hollenbeck Standards Track [Page 5] RFC 7483 RDAP JSON Responses March 2015 月(訳注:Moon)のレジストリが、この仕様では見つけられない情報を表し たい場合、"lunarNic"を識別用のプレフィックスとして選択し、そして、例 として最初の月面着陸を意味する"lunarNic_beforeOneSmallStep"と名付け られたメンバー及び他の説明文を含む"lunarNic_harshMistressNotes"と名 付けられたメンバーを挿入するかもしれない。 JSON名称の意味に関する知識を全く持たないクライアントが無視すべきいく つかのJSON名称を用いた下記のJSON応答を考える: { "handle" : "ABC123", "lunarNic_beforeOneSmallStep" : "TRUE THAT!", "remarks" : [ { "description" : [ "She sells sea shells down by the sea shore.", "Originally written by Terry Sullivan." ] } ], "lunarNic_harshMistressNotes" : [ "In space,", "nobody can hear you scream." ] } Figure 2 クライアントが無視する認識されないメンバーの挿入もまた、本仕様の将来 的な改訂に利用できるかもしれない。 JSON応答を処理するクライアントは、応答の中に存在しない、本ドキュメン トで規定されている登録データを表記するメンバーのために準備する必要が ある。言い換えると、サーバーは、自身のポリシーに基づき、登録データを 包含するJSONメンバーを含めないことに束縛されない。 最後に、本ドキュメントで規定されているすべてのJSON名称は、大文字と小 文字を区別する。サーバーとクライアントの両方は、指定された大文字と小 文字を用いてJSON名称を送信、処理しなければならない(MUST)。 Newton & Hollenbeck Standards Track [Page 6] RFC 7483 RDAP JSON Responses March 2015 3. Common Data Types JSON [RFC7159] は、数字、文字列、論理値、配列、オブジェクト、nullの データ型を定義している。本セクションでは、本ドキュメントで使用されて いる共通のJSON文字列に関する語義及び参考構文(両方またはいずれか一方) を説明している。 handle: DNR及びRIRは、レジストリ内の一意識別子があり、それ らはオブジェクトインスタンスを特定して参照すること に使用できる。本ドキュメントで見られるデータ型の語 義は、値を確認できる最近接オブジェクトへのレジスト リ内の一意参照にあたる。"registryId"、"roid"、 "nic-handle"、"registrationNo"などのデータ型名称は、 しばしばこのデータ型と同義の用語である。本ドキュメ ントでは、"handle"という用語が使用されている。クラ イアントがユーザーに公開する用語は、本ドキュメント の範囲を超える表示上の問題である。 IPv4 addresses: 本ドキュメントにおけるIPv4アドレスの表記は、ドット 区切り10進数による表記法を使用している。この表記例 は、"192.0.2.0"である。 IPv6 addresses: 本ドキュメントにおけるIPv6アドレスの表記は、 [RFC5952] で概説されている形式に従っている。この表 記例は、"2001:db8::1:0:0:1"である。 country codes: 地政学的な国家または国の識別が必要な場合、これらの 識別は[ISO.3166.1988] で定義されているように、 alpha-2または2文字の国コードの記号を用いて表記され る。alpha-2表記は、自由に利用可能であるため使用さ れているが、 alpha-3及び numeric-3標準は使用されな い。 LDH names: [RFC5890] で説明されているように、ドメインのラベル が、すべて文字、数字、ハイフンのラベルであるドメイ ン名のテキスト表記。末尾のピリオドは、任意である。 Unicode names: [RFC5890] で説明されているように、一つまたは複数の ラベルがU-labelであるドメイン名のテキスト表記。末 尾のピリオドは、任意である。 dates and times: 日付及び時間を示す値に関する構文は、[RFC3339] で定 義されている。 Newton & Hollenbeck Standards Track [Page 7] RFC 7483 RDAP JSON Responses March 2015 URIs: 統一資源識別子(Uniform Resource Identifiers)を示 す値に関する構文は、[RFC3986] で定義されている。 [RFC7095] で説明されているように、コンタクト情報はjCardsを用いて定義 されている。 4. Common Data Structures このセクションでは、応答やオブジェクトクラスに使用される共通データ構 造を定義している。 4.1. RDAP Conformance "rdapConformance"と名付けられたデータ構造は、文字列の配列であり、各 文字列は応答の構築に使用される仕様に関するヒントを提供している。 このデータ構造は、応答における最上位のJSONオジェクトにしか現れない。 rdapConformanceのデータ構造の例: "rdapConformance" : [ "rdap_level_0" ] Figure 3 文字列リテラル"rdap_level_0"は、本仕様に適合していることを意味する。 カスタムJSON値が応答の中に挿入されている場合、カスタム仕様への適合は、 [RFC7480] で規定されている、IANA RDAP拡張レジストリの適切な識別子を 冠した文字列を使用しなければならない(MUST)。例えば、もし架空の月 のレジストリが、自身が登録した拡張と JSON応答が適合していることを表 したい場合、使用される文字列は、"lunarNIC_level_0"となるかもしれない。 これらのプレフィックスは、ソフトウェア実装者に、仕様の同定を援助し、 プレフィックスの使用を怠ることは、より遅く拡張の採用という結果をもた らすかもしれない。 下記は、カスタム拡張を用いたrdapConformance構造の例である: "rdapConformance" : [ "rdap_level_0", "lunarNic_level_0" ] Figure 4 Newton & Hollenbeck Standards Track [Page 8] RFC 7483 RDAP JSON Responses March 2015 4.2. Links "links"配列は、インターネット上の他のリソースへのリンクを示すデータ 構造で見られる。それらリンクの関係は、[RFC5988] で説明されているIANA レジストリが定義している。 下記は、リンク構造の例である: { "value" : "http://example.com/context_uri", "rel" : "self", "href" : "http://example.com/target_uri", "hreflang" : [ "en", "ch" ], "title" : "title", "media" : "screen", "type" : "application/json" } Figure 5 "rel"、"href"、"hreflang"、"title"、"media"、"type"のJSON名称及び値 は、[RFC5988] のSection 5で見られる値に対応している。JSON値"Value"は、 [RFC5988] で説明されているように、コンテキストURIである。JSON値 "href"は、指定されなければならない(MUST)。他のJSON値はすべて任意 である(OPTIONAL)。 下記は、オブジェクトクラスで見られる"links"配列の例である: "links" : [ { "value" : "http://example.com/ip/2001:db8::123", "rel" : "self", "href" : "http://example.com/ip/2001:db8::123", "type" : "application/rdap+json" }, { "value" : "http://example.com/ip/2001:db8::123", "rel" : "up", "href" : "http://example.com/ip/2001:db8::/48", "type" : "application/rdap+json" } ] Figure 6 Newton & Hollenbeck Standards Track [Page 9] RFC 7483 RDAP JSON Responses March 2015 4.3. Notices and Remarks "notices"及び"remarks"のデータ構造は、同じ形式を用いる。"notices"の 構造は、RDAP情報を提供するサービスに関する情報及び応答全体に関する情 報(両方またはいずれか一方)を示し、"remarks"の構造は、それを含むオ ブジェクトクラス(Section 5のオブジェクトクラスに関する説明を参照) に関する情報を示す。 両方とも、オブジェクト配列である。各オブジェクトは、オブジェクトのタ イトルを表記する任意の"title"文字列、備考または通知の登録タイプを表 す任意の"type"文字列(Section 10.2.1を参照)、説明文を伝える目的で "description"と名付けられた文字列配列、Section4.2で説明されている任 意の"links"配列を含んでいる。 "notices"データ構造の例: "notices" : [ { "title" : "Terms of Use", "description" : [ "Service subject to The Registry of the Moon's TOS.", "Copyright (c) 2020 LunarNIC" ], "links" : [ { "value" : "http://example.net/entity/XXXX", "rel" : "alternate", "type" : "text/html", "href" : "http://www.example.com/terms_of_use.html" } ] } ] Figure 7 "description"配列の文字列に含まれる文章のために、改行、行間、表示の 問題を決定することは、クライアントの仕事である。"description"配列内 の各文字列は、クライアントに語義の境界を示している、人間が解読可能な テキストの単一かつ完全な節を含む。 Newton & Hollenbeck Standards Track [Page 10] RFC 7483 RDAP JSON Responses March 2015 "remarks"データ構造の例: "remarks" : [ { "description" : [ "She sells sea shells down by the sea shore.", "Originally written by Terry Sullivan." ] } ] Figure 8 "remarks"配列のオブジェクトは、"links"配列も持つかもしれないことに注 意する。 "title"及び"description"のフィールドが主に人向けである一方、"type"文 字列は、プログラムによる使用向けに、IANAで登録されているよく知られた 値(Section 10.2.1を参照)を含む。 "remarks"データ構造の例: "remarks" : [ { "type" : "object truncated due to authorization", "description" : [ "Some registration data may not have been given.", "Use proper authorization credentials to see all of it." ] } ] Figure 9 "remarks"配列が、応答における多くのオブジェクトクラスに現れる一方、 "notices"配列は、応答における最上位のオブジェクトのみに現れる。 Newton & Hollenbeck Standards Track [Page 11] RFC 7483 RDAP JSON Responses March 2015 4.4. Language Identifier このデータ構造は、名称と値の組み合わせのみから構成され、名称が"lang"、 そして値が [RFC5646] で説明されている言語識別子を含む文字列である。 "lang" : "mn-Cyrl-MN" Figure 10 "lang"属性は、jCardオブジェクト以外のオブジェクトクラスまたはデータ 構造で、どこにでも現れることができる。 4.5. Events このデータ構造は、オブジェクトクラス(Section 5のオブジェクトクラス に関する説明を参照)のインスタンスで発生する"events"を表す。 下記は、"events"配列の例である: "events" : [ { "eventAction" : "registration", "eventActor" : "SOMEID-LUNARNIC", "eventDate" : "1990-12-31T23:59:59Z" }, { "eventAction" : "last changed", "eventActor" : "OTHERID-LUNARNIC", "eventDate" : "1991-12-31T23:59:59Z" } ] Figure 11 "events"配列は、オブジェクトから構成される。各オブジェクトは下記のメ ンバーを含む。 o "eventAction" -- "event"の理由を示す文字列 o "eventActor" -- "event"の責任を持つアクターを示す任意の識別子 o "eventDate" -- "event"の発生日付及び時間を含む文字列 o "links" -- Section 4.2を参照 Newton & Hollenbeck Standards Track [Page 12] RFC 7483 RDAP JSON Responses March 2015 "event"は、未来の日付でも構わない。イベントの日付が未来である一例は、 レジストリからいつオブジェクトが期限切れとなるかを示すことである。 このデ―タ構造の"links"配列は、イベントアクターを参照するために提供 される。RDAPエンティティーを参照するために、"related"の"rel"及び "application/rdap+json"の"type"が リンク参照に使用される。 "eventAction"文字列のための値のリストは、Section 10.2.3を参照。イベ ントがモデル化されたさまざまな方法に関しては、Appendix B を参照。 4.6. Status "status"と名付けられたデータ構造は、登録オブジェクト(値のリストは、 Section 10.2.2を参照)の状態を示す文字列の配列である。 4.7. Port 43 WHOIS Server "port43"と名付けられたメンバーのデータ構造は、包含しているオブジェク トインスタンスを見つけることができる完全修飾ホスト名またはWHOIS [RFC3912] サーバーのIPアドレスを含む単純な文字列である。WHOIS URIス キームは存在しないので、これはURIではないことに注意する。 4.8. Public IDs このデータ構造は、オブジェクトクラスに公開識別子を対応付ける。それは "publicIds"と名付けられ、オブジェクトの配列である。配列内の各オブジ ェクトは下記のメンバーを含む。 o type -- 公開識別子の型を示す文字列 o identifier -- "type"が示す公開識別子の型 下記は、"publicIds"構造の例である: "publicIds": [ { "type":"IANA Registrar ID", "identifier":"1" } ] Figure 12 Newton & Hollenbeck Standards Track [Page 13] RFC 7483 RDAP JSON Responses March 2015 4.9. Object Class Name "objectClassName"と名付けられたメンバーのデータ構造は、特定のオブジ ェクトのオブジェクトクラス名称を文字列として提示する。これは、オブジ ェクトが処理される型を特定する。objectClassNameはすべてのRDAP応答オ ブジェクトで要求されるので(REQUIRED)、オブジェクトの型を判断するこ とができる。 4.10. An Example これは、"rdapConformance"及び"notices"の両方が埋め込まれている応答の 例である: { "rdapConformance" : [ "rdap_level_0" ], "notices" : [ { "title" : "Content Removed", "description" : [ "Without full authorization, content has been removed.", "Sorry, dude!" ], "links" : [ { "value" : "http://example.net/ip/192.0.2.0/24", "rel" : "alternate", "type" : "text/html", "href" : "http://www.example.com/redaction_policy.html" } ] } ], "lang" : "en", "objectClassName" : "ip network", "startAddress" : "192.0.2.0", "endAddress" : "192.0.2.255", "handle" : "XXXX-RIR", "ipVersion" : "v4", "name": "NET-RTR-1", "parentHandle" : "YYYY-RIR", "remarks" : [ Newton & Hollenbeck Standards Track [Page 14] RFC 7483 RDAP JSON Responses March 2015 { "description" : [ "She sells sea shells down by the sea shore.", "Originally written by Terry Sullivan." ] } ] } Figure 13 5. Object Classes オブジェクトクラスは、[RFC7482] で規定されているクエリの応答に対する 適切な構造を表す。 各オブジェクトクラスは、Section 4.2で規定されているように"links"配列 を含む。応答内のすべてのオブジェクトクラスインスタンスにおいて、オブ ジェクトクラスインスタンスが、クエリに対する応答を直接的に表している か、他のオブジェクトクラスインスタンス内に埋め込まれているか、または 検索結果のセットの項目であるかに関わらず、サーバーは、[RFC5988] で規 定されているIANAレジストリで説明されている"self"(自己)関連を用いて、 オブジェクトクラスインスタンスのURIを表すリンクを提供すべきである (SHOULD)。Section 5.2で説明するように、これはネームサーバーデータ のために常に可能であるとは限らない。クライアントは、自己リンクを持た ないオブジェクトインスタンスを処理できなければならない(MUST)。処理 可能な場合、クライアントは、キャッシュデータのために自己リンクを使用 できる。サーバーは、任意の与えられたオブジェクトインスタンスのために 複数の自己リンクを提供してもよい(MAY)。サーバーが自己リンクの提供 を怠ることは、クライアントがオブジェクトクラスインスタンスをキャッシュ できないという結果をもたらすかもしれない。 キャッシュに対する自己リンクを用いるクライアントは、自己リンクの権威 がデータを返すサーバーの権威と異なるオブジェクトクラスインスタンスを キャッシュすべきではない(SHOULD NOT)。そうしなければ、キャッシュ ポイズニングという結果をもたらすかもしれない。 本ドキュメントで定義されているように、RDAPオブジェクトインスタンスを 参照する際には、自己リンクは"application/ rdap+json"メディアタイプを 含んだ"type"要素を含まなければならない(MUST)。 Newton & Hollenbeck Standards Track [Page 15] RFC 7483 RDAP JSON Responses March 2015 下記は、オブジェクトクラスへの自己リンクを持つ"links"配列の例である : "links" : [ { "value" : "http://example.com/ip/2001:db8::123", "rel" : "self", "href" : "http://example.com/ip/2001:db8::123", "type" : "application/rdap+json" } ] Figure 14 5.1. The Entity Object Class 本ドキュメント全体にわたって現れるエンティティーオブジェクトクラスは、 "Registration Data Access Protocol(RDAP)Query Format" [RFC7482] で 定義されている"/entity/XXXX"クエリの適切な応答である。このオブジェク トクラスは、組織、企業、政府、非営利団体、クラブ、個人、非公式グルー プの情報を表記する。これらすべての表記は非常に類似しているので、実装 者によるコードの再利用を援助するため、エンティティーオブジェクトクラ スをその構造としてJSON [RFC7159] でそれらを表記するのが最良である。 エンティティーオブジェクトクラスは、住所、電子メールアドレス、電話番 号、組織や個人の名前などのコンタクト情報を表記するためにjCard [RFC7095] を使用する。jCardで表記することができる、誕生日、記念日や 性別などの情報タイプの多くは、RDAPでは使用されない。 エンティティーオブジェクトは、RIR及びDNRが提供する。下記は、RIRが提 供するかもしれないエンティティーの例である: { "objectClassName" : "entity", "handle":"XXXX", "vcardArray":[ "vcard", [ ["version", {}, "text", "4.0"], ["fn", {}, "text", "Joe User"], ["n", {}, "text", ["User", "Joe", "", "", ["ing. jr", "M.Sc."]] ], ["kind", {}, "text", "individual"], Newton & Hollenbeck Standards Track [Page 16] RFC 7483 RDAP JSON Responses March 2015 ["lang", { "pref":"1" }, "language-tag", "fr"], ["lang", { "pref":"2" }, "language-tag", "en"], ["org", { "type":"work" }, "text", "Example"], ["title", {}, "text", "Research Scientist"], ["role", {}, "text", "Project Lead"], ["adr", { "type":"work" }, "text", [ "", "Suite 1234", "4321 Rue Somewhere", "Quebec", "QC", "G1V 2M2", "Canada" ] ], ["adr", { "type":"home", "label":"123 Maple Ave\nSuite 90001\nVancouver\nBC\n1239\n" }, "text", [ "", "", "", "", "", "", "" ] ], ["tel", { "type":["work", "voice"], "pref":"1" }, "uri", "tel:+1-555-555-1234;ext=102" ], ["tel", { "type":["work", "cell", "voice", "video", "text"] }, "uri", "tel:+1-555-555-4321" ], ["email", Newton & Hollenbeck Standards Track [Page 17] RFC 7483 RDAP JSON Responses March 2015 { "type":"work" }, "text", "joe.user@example.com" ], ["geo", { "type":"work" }, "uri", "geo:46.772673,-71.282945"], ["key", { "type":"work" }, "uri", "http://www.example.com/joe.user/joe.asc" ], ["tz", {}, "utc-offset", "-05:00"], ["url", { "type":"home" }, "uri", "http://example.org"] ] ], "roles":[ "registrar" ], "publicIds":[ { "type":"IANA Registrar ID", "identifier":"1" } ], "remarks":[ { "description":[ "She sells sea shells down by the sea shore.", "Originally written by Terry Sullivan." ] } ], "links":[ { "value":"http://example.com/entity/XXXX", "rel":"self", "href":"http://example.com/entity/XXXX", "type" : "application/rdap+json" } ], "events":[ { "eventAction":"registration", "eventDate":"1990-12-31T23:59:59Z" } ], "asEventActor":[ Newton & Hollenbeck Standards Track [Page 18] RFC 7483 RDAP JSON Responses March 2015 { "eventAction":"last changed", "eventDate":"1991-12-31T23:59:59Z" } ] } Figure 15 エンティティーオブジェクトクラスは、下記のメンバーを含むことができる。 o objectClassName -- 文字列"entity" o handle -- エンティティーのレジストリ内の一意識別子を表す文字列 o vcardArray -- エンティティーのコンタクト情報を持つjCard o roles -- 文字列の配列。各文字列は、オブジェクトがその最も近い包含 オブジェクト(Section 10.2.4の値のリストを参照)を持つ関連を示す。 o publicIds -- Section 4.8を参照 o entities -- このセクションで定義されるエンティティーオブジェクト の配列 o remarks -- Section 4.3を参照 o links -- Section 4.2を参照 o events -- Section 4.5を参照 o asEventActor -- このデータ構造は、イベントデータ構造(Section 4.5 を参照)と同じ形式をとるが、配列内の各オブジェクトは、 "eventActor"メンバーを持ってはならない(MUST NOT)。これらのオブ ジェクトは、エンティティーが与えられたイベントのためのイベントア クターであることを示す。イベントがモデル化されたさまざまな方法に 関しては、Appendix Bを参照。 o status -- Section 4.6を参照 o port43 -- Section 4.7を参照 o networks -- Section 5.4で定義されるIPネットワークオブジェクトの配 列 o autnums -- Section 5.5で定義されるautnum(AS番号)オブジェクトの 配列 Newton & Hollenbeck Standards Track [Page 19] RFC 7483 RDAP JSON Responses March 2015 エンティティーもまた、配列内に埋め込まれた他のエンティティーを持つか もしれない。これは、特定の個人が指定された責任役割を果たす組織をモデ ル化するために使用される。 下記は、埋め込みエンティティーを持つエンティティーが省略された例であ る: { "objectClassName" : "entity", "handle" : "ANENTITY", "roles" : [ "registrar" ], ... "entities" : [ { "objectClassName" : "entity", "handle": "ANEMBEDDEDENTITY", "roles" : [ "technical" ], ... }, ... ], ... } Figure 16 下記は、DNRが提供するかもしれないエンティティーの例である: { "objectClassName" : "entity", "handle":"XXXX", "vcardArray":[ "vcard", [ ["version", {}, "text", "4.0"], ["fn", {}, "text", "Joe User"], ["kind", {}, "text", "individual"], ["lang", { "pref":"1" }, "language-tag", "fr"], ["lang", { "pref":"2" }, "language-tag", "en"], ["org", { "type":"work" }, "text", "Example"], Newton & Hollenbeck Standards Track [Page 20] RFC 7483 RDAP JSON Responses March 2015 ["title", {}, "text", "Research Scientist"], ["role", {}, "text", "Project Lead"], ["adr", { "type":"work" }, "text", [ "", "Suite 1234", "4321 Rue Somewhere", "Quebec", "QC", "G1V 2M2", "Canada" ] ], ["tel", { "type":["work", "voice"], "pref":"1" }, "uri", "tel:+1-555-555-1234;ext=102" ], ["email", { "type":"work" }, "text", "joe.user@example.com" ] ] ], "status":[ "validated", "locked" ], "remarks":[ { "description":[ "She sells sea shells down by the sea shore.", "Originally written by Terry Sullivan." ] } ], "links":[ { "value":"http://example.com/entity/XXXX", "rel":"self", "href":"http://example.com/entity/XXXX", "type":"application/rdap+json" } ], "port43":"whois.example.net", "events":[ { "eventAction":"registration", "eventDate":"1990-12-31T23:59:59Z" }, Newton & Hollenbeck Standards Track [Page 21] RFC 7483 RDAP JSON Responses March 2015 { "eventAction":"last changed", "eventDate":"1991-12-31T23:59:59Z", "eventActor":"joe@example.com" } ] } Figure 17 RIR及びDNRの両方で見られるさまざまなエンティティータイプをモデル化す るエンティティーオブジェクトクラスの使用については、Appendix Aを参照。 エンティティー内の構造化された住所と、構造化されていない住所に関して は、Appendix Cを参照。 5.2. The Nameserver Object Class ネームサーバーオブジェクトクラスは、正引き及び逆引きの両方のDNSで使 用されるDNSネームサーバーに関する情報を表記する。RIR及びいくつかの DNRは、ドメイン名の属性としてネームサーバー情報を登録または開示する。 一方、他のDNRは、「第一級オブジェクト」としてネームサーバーをモデル 化する。 ネームサーバーオブジェクトクラスは、バリエーションのモデルと程度の両 方に対応する。 下記は、ネームサーバーオブジェクトの例である: { "objectClassName" : "nameserver", "handle" : "XXXX", "ldhName" : "ns1.xn--fo-5ja.example", "unicodeName" : "ns1.foo.example", "status" : [ "active" ], "ipAddresses" : { "v4": [ "192.0.2.1", "192.0.2.2" ], "v6": [ "2001:db8::123" ] }, "remarks" : [ { "description" : [ "She sells sea shells down by the sea shore.", "Originally written by Terry Sullivan." Newton & Hollenbeck Standards Track [Page 22] RFC 7483 RDAP JSON Responses March 2015 ] } ], "links" : [ { "value" : "http://example.net/nameserver/xxxx", "rel" : "self", "href" : "http://example.net/nameserver/xxxx", "type" : "application/rdap+json" } ], "port43" : "whois.example.net", "events" : [ { "eventAction" : "registration", "eventDate" : "1990-12-31T23:59:59Z" }, { "eventAction" : "last changed", "eventDate" : "1991-12-31T23:59:59Z", "eventActor" : "joe@example.com" } ] } Figure 18 Figure 18は、与えられたすべての値を持つネームサーバーオブジェクトの 例である。 第一級のネームサーバーデータモデルを用いるレジストリは、ドメインオブ ジェクト内にこれを埋め込むと同様、"/nameserver"クエリタイプによるそ れへの参照も許可する(すべてレジストリオペレーターポリシーによる)。 他のレジストリは、必要に応じ、情報を切り詰めるかもしれない。Figure 19は、RIR及びいくつかのDNRで見られるネームサーバーオブジェクトの例で ある。一方、Figure 20は、それら以外のDNRで見られるようなネームサーバー オブジェクトの例である。 下記は、最も単純なネームサーバーオブジェクトの例である: { "objectClassName" : "nameserver", "ldhName" : "ns1.example.com" } Newton & Hollenbeck Standards Track [Page 23] RFC 7483 RDAP JSON Responses March 2015 Figure 19 下記は、DNRがよく使用する単純なネームサーバーオブジェクトの例である: { "objectClassName" : "nameserver", "ldhName" : "ns1.example.com", "ipAddresses" : { "v6" : [ "2001:db8::123", "2001:db8::124" ] } } Figure 20 ネームサーバーは、第一級オブジェクトであることをレジストリがモデル化 できるように、ネームサーバーの維持や登録などに責任がある関係者を示す 埋め込まれたエンティティー(Section 5.1)の配列を持つかもしれない。 下記は、埋め込みエンティティーを持つネームサーバーが省略された例であ る: { "objectClassName" : "nameserver", "handle" : "XXXX", "ldhName" : "ns1.xn--fo-5ja.example", ... "entities" : [ ... ], ... } Figure 21 ネームサーバーオブジェクトクラスは、下記のメンバーを含むことができる。 o objectClassName -- 文字列"nameserver" o handle -- ネームサーバーのレジストリ内の一意識別子を表す文字列 o ldhName -- ネームサーバーのLDH名を含む文字列(Section 3を参照) o unicodeName -- ネームサーバーのDNS Unicode名を含む文字列(Section 3を参照) o ipAddresses -- 下記のメンバーを含むオブジェクト: * v6 -- ネームサーバーのIPv6アドレスを含む文字列の配列 * v4 -- ネームサーバーのIPv4アドレスを含む文字列の配列 Newton & Hollenbeck Standards Track [Page 24] RFC 7483 RDAP JSON Responses March 2015 o entities -- Section 5.1で定義されるエンティティーオブジェクトの配 列 o status -- Section 4.6を参照 o remarks -- Section 4.3を参照 o links -- Section 4.2を参照 o port43 -- Section 4.7を参照 o events -- Section 4.5を参照 5.3. The Domain Object Class ドメインオブジェクトクラスは、DNS名及び委任ポイントを表す。RIRでは、 これらの委任ポイントは逆引きDNSツリーに存在するが、DNRでは、委任ポイ ントは正引きDNSツリーに存在する。 いずれの場合も、ドメインオブジェクトクラスの上位構造には、ドメイン登 録、ドメイン名に関連するネームサーバー情報、ドメイン名に関連するエン ティティー(登録者情報、連絡先など)についての情報から構成される。 下記は、上位構造を示すドメインオブジェクトが省略された例である: { "objectClassName" : "domain", "handle" : "XXX", "ldhName" : "blah.example.com", ... "nameservers" : [ ... ], ... "entities" : [ ... ] } Figure 22 ドメインオブジェクトクラスは、下記のメンバーを含むことができる。 o objectClassName -- 文字列"domain" Newton & Hollenbeck Standards Track [Page 25] RFC 7483 RDAP JSON Responses March 2015 o handle -- ドメインオブジェクトインスタンスのレジストリ内の一意識 別子を表す文字列 o ldhName -- Section 3で説明されているLDH形式のドメイン名を含む文字 列 o unicodeName -- Section 3で説明されているU-label形式のドメイン名を 含む文字列 o variants --オブジェクト配列。下記の値を含む: * relation -- 文字列の配列。各文字列は、バリアント間の関係とドメ インオブジェクトを含むことを示す(バリアント関係の提示リストは、 Section 10.2.5を参照)。 * idnTable -- コードポイントの国際化ドメイン名(IDN)テーブルの 名前。IANAのリストなど(IDN tables [IANA_IDNTABLES] を参照)。 * variantNames -- オブジェクトの配列。各オブジェクトは、 "ldhName"メンバー及び"unicodeName"メンバーを含む(Section 3を 参照)。 o nameservers -- Section 5.2で定義されているネームサーバーオブジェ クトの配列 o secureDNS -- 下記のメンバーを含むオブジェクト: * zoneSigned -- true:ゾーンが署名されている場合、false:その他 の場合 * delegationSigned -- 論理値true:親にDSレコードがある場合、 false:その他の場合 * maxSigLife -- 親ゾーンのRRSIG DSレコード [RFC5910] の作成時に 使用される署名の有効期間を秒で表す整数 * dsData -- オブジェクトの配列。各オブジェクトは、下記のメンバー を含む: + keyTag -- [RFC4034] の表記形式で規定されているDNS DSレコー ドの鍵タグフィールドで指定された整数 + algorithm -- [RFC4034] の表記形式で説明されているDNS DSレコー ドのアルゴリズムフィールドで指定された整数 + digest -- [RFC4034] の表記形式で規定されているDNS DSレコー ドのダイジェストフィールドで指定された文字列 Newton & Hollenbeck Standards Track [Page 26] RFC 7483 RDAP JSON Responses March 2015 + digestType -- [RFC4034] の表記形式で規定されているDNS DSレ コードのダイジェストタイプフィールドで指定された整数 + events -- Section 4.5を参照 + links -- Section 4.2を参照 * keyData -- オブジェクトの配列。各オブジェクトは、下記のメンバー を含む: + flags -- [RFC4034] の表記形式で、DNSKEYレコードのフラグフィー ルド値を表記する整数 + protocol -- [RFC4034] の表記形式で、DNSKEYレコードのプロト コルフィールド値を表記する整数 + publicKey -- [RFC4034] の表記形式で、DNSKEYレコード内の公開 鍵を表記する文字列 + algorithm -- [RFC4034] の表記形式で規定されているDNSKEYレコー ドのアルゴリズムフィールドで指定された整数 + events -- Section 4.5を参照 + links -- Section 4.2を参照 これらオブジェクトのバックグラウンド情報はAppendix Dを参照。 o entities -- Section 5.1で定義されるエンティティーオブジェクトの配 列 o status -- Section 4.6を参照 o publicIds -- Section 4.8を参照 o remarks -- Section 4.3を参照 o links -- Section 4.2を参照 o port43 -- Section 4.7を参照 o events -- Section 4.5を参照 o network -- 逆引きDNSドメインが参照するIPネットワークを表記する。 Section 5.4を参照。 Newton & Hollenbeck Standards Track [Page 27] RFC 7483 RDAP JSON Responses March 2015 下記は、RIRによって提供されるかもしれない逆引きDNS委任ポイントを表す JSONドメインオブジェクトの例である: { "objectClassName" : "domain", "handle" : "XXXX", "ldhName" : "0.2.192.in-addr.arpa", "nameservers" : [ { "objectClassName" : "nameserver", "ldhName" : "ns1.rir.example" }, { "objectClassName" : "nameserver", "ldhName" : "ns2.rir.example" } ], "secureDNS": { "delegationSigned": true, "dsData": [ { "keyTag": 12345, "algorithm": 3, "digestType": 1, "digest": "49FD46E6C4B45C55D4AC" } ] }, "remarks" : [ { "description" : [ "She sells sea shells down by the sea shore.", "Originally written by Terry Sullivan." ] } ], "links" : [ { "value": "http://example.net/domain/XXXX", "rel" : "self", "href" : "http://example.net/domain/XXXXX", "type" : "application/rdap+json" Newton & Hollenbeck Standards Track [Page 28] RFC 7483 RDAP JSON Responses March 2015 } ], "events" : [ { "eventAction" : "registration", "eventDate" : "1990-12-31T23:59:59Z" }, { "eventAction" : "last changed", "eventDate" : "1991-12-31T23:59:59Z", "eventActor" : "joe@example.com" } ], "entities" : [ { "objectClassName" : "entity", "handle" : "XXXX", "vcardArray":[ "vcard", [ ["version", {}, "text", "4.0"], ["fn", {}, "text", "Joe User"], ["kind", {}, "text", "individual"], ["lang", { "pref":"1" }, "language-tag", "fr"], ["lang", { "pref":"2" }, "language-tag", "en"], ["org", { "type":"work" }, "text", "Example"], ["title", {}, "text", "Research Scientist"], ["role", {}, "text", "Project Lead"], ["adr", { "type":"work" }, "text", [ "", "Suite 1234", "4321 Rue Somewhere", "Quebec", "QC", "G1V 2M2", "Canada" ] Newton & Hollenbeck Standards Track [Page 29] RFC 7483 RDAP JSON Responses March 2015 ], ["tel", { "type":["work", "voice"], "pref":"1" }, "uri", "tel:+1-555-555-1234;ext=102" ], ["email", { "type":"work" }, "text", "joe.user@example.com" ] ] ], "roles" : [ "registrant" ], "remarks" : [ { "description" : [ "She sells sea shells down by the sea shore.", "Originally written by Terry Sullivan." ] } ], "links" : [ { "value": "http://example.net/entity/xxxx", "rel" : "self", "href" : "http://example.net/entity/xxxx", "type" : "application/rdap+json" } ], "events" : [ { "eventAction" : "registration", "eventDate" : "1990-12-31T23:59:59Z" }, { "eventAction" : "last changed", "eventDate" : "1991-12-31T23:59:59Z", "eventActor" : "joe@example.com" } ] } ], "network" : { "objectClassName" : "ip network", Newton & Hollenbeck Standards Track [Page 30] RFC 7483 RDAP JSON Responses March 2015 "handle" : "XXXX-RIR", "startAddress" : "192.0.2.0", "endAddress" : "192.0.2.255", "ipVersion" : "v6", "name": "NET-RTR-1", "type" : "DIRECT ALLOCATION", "country" : "AU", "parentHandle" : "YYYY-RIR", "status" : [ "active" ] } } Figure 23 下記は、DNRによって提供されるかもしれない正引きDNS委任ポイントを表す JSONドメインオブジェクトの例である: { "objectClassName" : "domain", "handle" : "XXXX", "ldhName" : "xn--fo-5ja.example", "unicodeName" : "foo.example", "variants" : [ { "relation" : [ "registered", "conjoined" ], "variantNames" : [ { "ldhName" : "xn--fo-cka.example", "unicodeName" : "foo.example" }, { "ldhName" : "xn--fo-fka.example", "unicodeName" : "foo.example" } ] }, { "relation" : [ "unregistered", "registration restricted" ], "idnTable": ".EXAMPLE Swedish", "variantNames" : [ { "ldhName": "xn--fo-8ja.example", "unicodeName" : "foo.example" } ] Newton & Hollenbeck Standards Track [Page 31] RFC 7483 RDAP JSON Responses March 2015 } ], "status" : [ "locked", "transfer prohibited" ], "publicIds":[ { "type":"ENS_Auth ID", "identifier":"1234567890" } ], "nameservers" : [ { "objectClassName" : "nameserver", "handle" : "XXXX", "ldhName" : "ns1.example.com", "status" : [ "active" ], "ipAddresses" : { "v6": [ "2001:db8::123", "2001:db8::124" ], "v4": [ "192.0.2.1", "192.0.2.2" ] }, "remarks" : [ { "description" : [ "She sells sea shells down by the sea shore.", "Originally written by Terry Sullivan." ] } ], "links" : [ { "value" : "http://example.net/nameserver/XXXX", "rel" : "self", "href" : "http://example.net/nameserver/XXXX", "type" : "application/rdap+json" } ], "events" : [ { "eventAction" : "registration", "eventDate" : "1990-12-31T23:59:59Z" }, { "eventAction" : "last changed", Newton & Hollenbeck Standards Track [Page 32] RFC 7483 RDAP JSON Responses March 2015 "eventDate" : "1991-12-31T23:59:59Z" } ] }, { "objectClassName" : "nameserver", "handle" : "XXXX", "ldhName" : "ns2.example.com", "status" : [ "active" ], "ipAddresses" : { "v6" : [ "2001:db8::125", "2001:db8::126" ], "v4" : [ "192.0.2.3", "192.0.2.4" ] }, "remarks" : [ { "description" : [ "She sells sea shells down by the sea shore.", "Originally written by Terry Sullivan." ] } ], "links" : [ { "value" : "http://example.net/nameserver/XXXX", "rel" : "self", "href" : "http://example.net/nameserver/XXXX", "type" : "application/rdap+json" } ], "events" : [ { "eventAction" : "registration", "eventDate" : "1990-12-31T23:59:59Z" }, { "eventAction" : "last changed", "eventDate" : "1991-12-31T23:59:59Z" } ] } ], "secureDNS": { Newton & Hollenbeck Standards Track [Page 33] RFC 7483 RDAP JSON Responses March 2015 "zoneSigned": true, "delegationSigned": true, "maxSigLife": 604800, "keyData": [ { "flags": 257, "protocol": 3, "algorithm": 1, "publicKey": "AQPJ////4Q==", "events": [ { "eventAction": "last changed", "eventDate": "2012-07-23T05:15:47Z" } ] } ] }, "remarks" : [ { "description" : [ "She sells sea shells down by the sea shore.", "Originally written by Terry Sullivan." ] } ], "links" : [ { "value": "http://example.net/domain/XXXX", "rel" : "self", "href" : "http://example.net/domain/XXXX", "type" : "application/rdap+json" } ], "port43" : "whois.example.net", "events" : [ { "eventAction" : "registration", "eventDate" : "1990-12-31T23:59:59Z" }, { "eventAction" : "last changed", Newton & Hollenbeck Standards Track [Page 34] RFC 7483 RDAP JSON Responses March 2015 "eventDate" : "1991-12-31T23:59:59Z", "eventActor" : "joe@example.com" }, { "eventAction" : "transfer", "eventDate" : "1991-12-31T23:59:59Z", "eventActor" : "joe@example.com" }, { "eventAction" : "expiration", "eventDate" : "2016-12-31T23:59:59Z", "eventActor" : "joe@example.com" } ], "entities" : [ { "objectClassName" : "entity", "handle" : "XXXX", "vcardArray":[ "vcard", [ ["version", {}, "text", "4.0"], ["fn", {}, "text", "Joe User"], ["kind", {}, "text", "individual"], ["lang", { "pref":"1" }, "language-tag", "fr"], ["lang", { "pref":"2" }, "language-tag", "en"], ["org", { "type":"work" }, "text", "Example"], ["title", {}, "text", "Research Scientist"], ["role", {}, "text", "Project Lead"], ["adr", { "type":"work" }, "text", [ "", "Suite 1234", "4321 Rue Somewhere", "Quebec", "QC", "G1V 2M2", "Canada" ] Newton & Hollenbeck Standards Track [Page 35] RFC 7483 RDAP JSON Responses March 2015 ], ["tel", { "type":["work", "voice"], "pref":"1" }, "uri", "tel:+1-555-555-1234;ext=102" ], ["email", { "type":"work" }, "text", "joe.user@example.com" ] ] ], "status" : [ "validated", "locked" ], "roles" : [ "registrant" ], "remarks" : [ { "description" : [ "She sells sea shells down by the sea shore.", "Originally written by Terry Sullivan." ] } ], "links" : [ { "value" : "http://example.net/entity/xxxx", "rel" : "self", "href" : "http://example.net/entity/xxxx", "type" : "application/rdap+json" } ], "events" : [ { "eventAction" : "registration", "eventDate" : "1990-12-31T23:59:59Z" }, { "eventAction" : "last changed", "eventDate" : "1991-12-31T23:59:59Z" } ] } ] } Figure 24 Newton & Hollenbeck Standards Track [Page 36] RFC 7483 RDAP JSON Responses March 2015 5.4. The IP Network Object Class IPネットワークオブジェクトクラスは、RIRで見られるIPネットワーク登録 をモデル化する。そして、[RFC7482] で定義されているように、それは "/ip"クエリに対する期待された応答である。DNRには同等のオブジェクトク ラスは存在しない。IPネットワークオブジェクトクラスの上位構造は、ネッ トワーク登録及びIPネットワーク(登録者情報、連絡先など)に関するエン ティティーについての情報から構成される。 下記は、上位構造を示すIPネットワークオブジェクトタイプが省略された例 である: { "objectClassName" : "ip network", "handle" : "XXX", ... "entities" : [ ... ] } Figure 25 下記は、ネットワーク登録情報のJSONオブジェクトの例である: { "objectClassName" : "ip network", "handle" : "XXXX-RIR", "startAddress" : "2001:db8::", "endAddress" : "2001:db8:0:ffff:ffff:ffff:ffff:ffff", "ipVersion" : "v6", "name": "NET-RTR-1", "type" : "DIRECT ALLOCATION", "country" : "AU", "parentHandle" : "YYYY-RIR", "status" : [ "active" ], "remarks" : [ { "description" : [ "She sells sea shells down by the sea shore.", "Originally written by Terry Sullivan." ] } ], Newton & Hollenbeck Standards Track [Page 37] RFC 7483 RDAP JSON Responses March 2015 "links" : [ { "value" : "http://example.net/ip/2001:db8::/48", "rel" : "self", "href" : "http://example.net/ip/2001:db8::/48", "type" : "application/rdap+json" }, { "value" : "http://example.net/ip/2001:db8::/48", "rel" : "up", "href" : "http://example.net/ip/2001:C00::/23", "type" : "application/rdap+json" } ], "events" : [ { "eventAction" : "registration", "eventDate" : "1990-12-31T23:59:59Z" }, { "eventAction" : "last changed", "eventDate" : "1991-12-31T23:59:59Z" } ], "entities" : [ { "objectClassName" : "entity", "handle" : "XXXX", "vcardArray":[ "vcard", [ ["version", {}, "text", "4.0"], ["fn", {}, "text", "Joe User"], ["kind", {}, "text", "individual"], ["lang", { "pref":"1" }, "language-tag", "fr"], ["lang", { "pref":"2" }, "language-tag", "en"], ["org", { "type":"work" }, "text", "Example"], ["title", {}, "text", "Research Scientist"], ["role", {}, "text", "Project Lead"], Newton & Hollenbeck Standards Track [Page 38] RFC 7483 RDAP JSON Responses March 2015 ["adr", { "type":"work" }, "text", [ "", "Suite 1234", "4321 Rue Somewhere", "Quebec", "QC", "G1V 2M2", "Canada" ] ], ["tel", { "type":["work", "voice"], "pref":"1" }, "uri", "tel:+1-555-555-1234;ext=102" ], ["email", { "type":"work" }, "text", "joe.user@example.com" ] ] ], "roles" : [ "registrant" ], "remarks" : [ { "description" : [ "She sells sea shells down by the sea shore.", "Originally written by Terry Sullivan." ] } ], "links" : [ { "value" : "http://example.net/entity/xxxx", "rel" : "self", "href" : "http://example.net/entity/xxxx", "type" : "application/rdap+json" } ], "events" : [ { "eventAction" : "registration", "eventDate" : "1990-12-31T23:59:59Z" Newton & Hollenbeck Standards Track [Page 39] RFC 7483 RDAP JSON Responses March 2015 }, { "eventAction" : "last changed", "eventDate" : "1991-12-31T23:59:59Z" } ] } ] } Figure 26 IPネットワークオブジェクトクラスは、下記のメンバーを含むことができる。 o objectClassName -- 文字列"ip network" o handle -- ネットワーク登録のRIR内の一意識別子を表す文字列 o startAddress -- ネットワークの開始IPアドレス。IPv4またはIPv6のい ずれか。 o endAddress -- ネットワークの終了IPアドレス。IPv4またはIPv6のいず れか o ipVersion -- ネットワークのIPプロトコルバージョンを意味する文字列。 「v4」 はIPv4ネットワークを意味し、「v6」 はIPv6ネットワークを意 味する o name -- 登録保有者によってネットワーク登録に割り振られた識別子 o type -- ネットワークのRIR特有の分類を含む文字列 o country -- ネットワークの2文字の国コードを含む文字列 o parentHandle -- このネットワーク登録の親ネットワークのRIRごとの識 別子を含む文字列 o status -- IPネットワークのステータスを指示する文字列の配列 o entities -- Section 5.1で定義されているエンティティーオブジェクト の配列 o remarks -- Section 4.3を参照 o links -- Section 4.2を参照 o port43 -- Section 4.7を参照 Newton & Hollenbeck Standards Track [Page 40] RFC 7483 RDAP JSON Responses March 2015 o events -- Section 4.5を参照 5.5. Autonomous System Number Entity Object Class AS番号(autnum)オブジェクトクラスは、RIRで見られるAS番号登録をモデ ル化する。そして、[RFC7482] で定義されているように、それは"/autnum" クエリに対する期待された応答である。DNRには同等のオブジェクトクラス は存在しない。autnumオブジェクトクラスの上位構造は、ネットワーク登録 及びautnum登録(登録者情報、連絡先など)に関するエンティティーについ ての情報から構成される。それはIPネットワークエンティティーオブジェク トクラスに類似している。 下記は、autnumを表すJSONオブジェクトの例である: { "objectClassName" : "autnum", "handle" : "XXXX-RIR", "startAutnum" : 10, "endAutnum" : 15, "name": "AS-RTR-1", "type" : "DIRECT ALLOCATION", "status" : [ "active" ], "country": "AU", "remarks" : [ { "description" : [ "She sells sea shells down by the sea shore.", "Originally written by Terry Sullivan." ] } ], "links" : [ { "value" : "http://example.net/autnum/xxxx", "rel" : "self", "href" : "http://example.net/autnum/xxxx", "type" : "application/rdap+json" } ], "events" : Newton & Hollenbeck Standards Track [Page 41] RFC 7483 RDAP JSON Responses March 2015 [ { "eventAction" : "registration", "eventDate" : "1990-12-31T23:59:59Z" }, { "eventAction" : "last changed", "eventDate" : "1991-12-31T23:59:59Z" } ], "entities" : [ { "objectClassName" : "entity", "handle" : "XXXX", "vcardArray":[ "vcard", [ ["version", {}, "text", "4.0"], ["fn", {}, "text", "Joe User"], ["kind", {}, "text", "individual"], ["lang", { "pref":"1" }, "language-tag", "fr"], ["lang", { "pref":"2" }, "language-tag", "en"], ["org", { "type":"work" }, "text", "Example"], ["title", {}, "text", "Research Scientist"], ["role", {}, "text", "Project Lead"], ["adr", { "type":"work" }, "text", [ "", "Suite 1234", "4321 Rue Somewhere", "Quebec", "QC", "G1V 2M2", "Canada" ] ], ["tel", { "type":["work", "voice"], "pref":"1" }, "uri", "tel:+1-555-555-1234;ext=102" Newton & Hollenbeck Standards Track [Page 42] RFC 7483 RDAP JSON Responses March 2015 ], ["email", { "type":"work" }, "text", "joe.user@example.com" ] ] ], "roles" : [ "registrant" ], "remarks" : [ { "description" : [ "She sells sea shells down by the sea shore.", "Originally written by Terry Sullivan." ] } ], "links" : [ { "value" : "http://example.net/entity/XXXX", "rel" : "self", "href" : "http://example.net/entity/XXXX", "type" : "application/rdap+json" } ], "events" : [ { "eventAction" : "registration", "eventDate" : "1990-12-31T23:59:59Z" }, { "eventAction" : "last changed", "eventDate" : "1991-12-31T23:59:59Z" } ] } ] } Figure 27 AS番号オブジェクトクラスは、下記のメンバーを含むことができる。 o objectClassName -- 文字列"autnum" Newton & Hollenbeck Standards Track [Page 43] RFC 7483 RDAP JSON Responses March 2015 o handle -- autnum登録のRIR内の一意識別子を表す文字列 o startAutnum -- AS番号のブロック内の開始番号 [RFC5396] を表す番号 o endAutnum -- AS番号のブロック内の終了番号 [RFC5396] を表す番号 o name -- 登録保有者によってautnum登録に割り振られた識別子 o type -- autnumのRIR内の固有分類を含む文字列 o status -- autnumのステータスを示す文字列の配列 o country -- autnumの2文字の国コードを含む文字列 o entities -- Section 5.1で定義されるエンティティーオブジェクトの配 列 o remarks -- Section 4.3を参照 o links -- Section 4.2を参照 o port43 -- Section 4.7を参照 o events -- Section 4.5を参照 6. Error Response Body 無回答の応答は、より具体的な情報を持つエンティティー本体を返すことが ある。 その応答の基本構造は、エラーコード番号(HTTP応答コードに対応する)、 続いて"title"と名付けられた文字列及び"description"と名付けられた文字 列配列から構成されるオブジェクトクラスである。 下記は、共通の応答本体の例である: { "errorCode": 418, "title": "Your Beverage Choice is Not Available", "description": [ "I know coffee has more ummppphhh.", "Sorry, dude!" ] } Figure 28 Newton & Hollenbeck Standards Track [Page 44] RFC 7483 RDAP JSON Responses March 2015 下記は、"rdapConformance"及び"notices"のデータ構造を持つ共通の応答本 体の例である: { "rdapConformance" : [ "rdap_level_0" ], "notices" : [ { "title" : "Beverage Policy", "description" : [ "Beverages with caffeine for keeping horses awake." ], "links" : [ { "value" : "http://example.net/ip/192.0.2.0/24", "rel" : "alternate", "type" : "text/html", "href" : "http://www.example.com/redaction_policy.html" } ] } ], "lang" : "en", "errorCode": 418, "title": "Your beverage choice is not available", "description": [ "I know coffee has more ummppphhh.", "Sorry, dude!" ] } Figure 29 7. Responding to Help Queries [RFC7482] で定義されている"/help"クエリに対する適切な応答は、Section 4.3で定義されているように、"notices"構造を使用することである。 Newton & Hollenbeck Standards Track [Page 45] RFC 7483 RDAP JSON Responses March 2015 下記は、"rdapConformance"データ構造を含む"/help"クエリに対する応答の 例である: { "rdapConformance" : [ "rdap_level_0" ], "notices" : [ { "title" : "Authentication Policy", "description" : [ "Access to sensitive data for users with proper credentials." ], "links" : [ { "value" : "http://example.net/help", "rel" : "alternate", "type" : "text/html", "href" : "http://www.example.com/auth_policy.html" } ] } ] } Figure 30 8. Responding To Searches [RFC7482] では、ドメイン、ネームサーバー、エンティティーの3種類の検 索を規定している。それらの検索に対する応答は、オブジェクトインスタン スの配列の形式をとり、各インスタンスは、検索に対する適切なオブジェク トクラスである(すなわち、/domainsに対する検索はドメインオブジェクト インスタンスの配列を生成する)。それらの配列は、応答オブジェクト内に 含まれる。 配列の名称は、次の通りである。 o "/domains"検索 -- 配列名称"domainSearchResults" o "/nameservers"検索 -- 配列名称"nameserverSearchResults" o "/entities"検索 -- 配列名称"entitySearchResults" Newton & Hollenbeck Standards Track [Page 46] RFC 7483 RDAP JSON Responses March 2015 下記は、"/domains"検索に対する応答が省略された例である: { "rdapConformance" : [ "rdap_level_0" ], ... "domainSearchResults" : [ { "objectClassName" : "domain", "handle" : "1-XXXX", "ldhName" : "1.example.com", ... }, { "objectClassName" : "domain", "handle" : "2-XXXX", "ldhName" : "2.example.com", ... } ] } Figure 31 9. Indicating Truncated Responses 応答データを制限する必要、またはデータの一部を省略する必要がある場合、 応答は「切り詰められた」と見なされる。切り詰められた応答も有効なJSON であるが、検索セットの結果の一部またはオブジェクトのデータの一部が、 サーバーから提供されない。サーバーは、応答オブジェクト内に型付き通知 を含めることで切り詰められたことを示すことができる。 下記は、切り詰められた検索応答が省略された例である: { "rdapConformance" : [ "rdap_level_0" ], "notices" : [ { "title" : "Search Policy", "type" : "result set truncated due to authorization", Newton & Hollenbeck Standards Track [Page 47] RFC 7483 RDAP JSON Responses March 2015 "description" : [ "Search results are limited to 25 per day per querying IP." ], "links" : [ { "value" : "http://example.net/help", "rel" : "alternate", "type" : "text/html", "href" : "http://www.example.com/search_policy.html" } ] } ], "domainSearchResults" : [ ... ] } Figure 32 同様の手法は、単一オブジェクトを返し、かつそのオブジェクト内のデータ を切り詰めた型付き注釈で使用されている。このような例は、自身に関連付 けられたIPネットワークの一部のみを含むエンティティーオブジェクトであ るかもしれない。 下記は、切り詰められたデータのエンティティーが省略された例である: { "objectClassName" : "entity", "handle" : "ANENTITY", "roles" : [ "registrant" ], ... "entities" : [ { "objectClassName" : "entity", "handle": "ANEMBEDDEDENTITY", "roles" : [ "technical" ], ... }, ... ], Newton & Hollenbeck Standards Track [Page 48] RFC 7483 RDAP JSON Responses March 2015 "networks" : [ ... ], ... "remarks" : [ { "title" : "Data Policy", "type" : "object truncated due to unexplainable reason", "description" : [ "Some of the data in this object has been removed." ], "links" : [ { "value" : "http://example.net/help", "rel" : "alternate", "type" : "text/html", "href" : "http://www.example.com/data_policy.html" } ] } ] } Figure 33 10. IANA Considerations 10.1. RDAP JSON Media Type Registration この仕様は、"application/rdap+json"メディアタイプを登録する。 タイプ名:application サブタイプ名:rdap+json 必須パラメーター:n/a エンコーディングの考察:[RFC6839] のSection 3.1参照。 セキュリティの考察:この識別子が表すメディアは、[RFC7159] の Section 6で見られる範囲を超えたセキュリティの考慮事項はない。 相互運用性の考察:このメディア形式に関して、相互運用性の問題はな い。 Newton & Hollenbeck Standards Track [Page 49] RFC 7483 RDAP JSON Responses March 2015 公開仕様:RFC 7483 このメディアタイプを使用するアプリケーション:RDAP(Registration Data Access Protocol) 追加情報:このメディアタイプは、IETF WEIRDSワーキンググループの生 産物である。WEIRDSチャーター、WEIRDSメーリングリスト情報及び WEIRDSワーキンググループが作成した他の資料は、 で見ることができる 更なる情報のための連絡先の個人と電子メールアドレス:IESG 使用目的:一般 仕様上の制限:なし 著者:Andy Newton 変更管理者:IETF 暫定登録:いいえ(このRFCの公表と同時) 10.2. JSON Values Registry IANAは、プロトコルレジストリに"Registration Data Access Protocol (RDAP)"というカテゴリーを作成し、そのカテゴリー内に、IANAは、"RDAP JSON Values"と分類されたURL参照可能で独立型のレジストリを確立した。 この新しいレジストリは、RDAPで規定された"notices"及び"remarks" (Section 4.3)、"status"(Section 4.6)、"role"(Section 5.1)、 "event action"(Section 4.5)、"domain variant relation"(Section 5.3)の各フィールドを使用するためにある。 レジストリ内の各エントリーは、下記のフィールドを含む。 1. Value -- 登録されている文字列値 2. Type -- 登録されている値の型。これは、下記のいずれかでなくてはな らない。 * "notice or remark type" -- 通知または注釈の型を意味する。 * "status" -- Section 4.6で定義されている"status"オブジェクトメ ンバーの値を意味する。 * "role" -- Section 5.1で定義されている"role"配列の値を意味する。 Newton & Hollenbeck Standards Track [Page 50] RFC 7483 RDAP JSON Responses March 2015 * "event action" -- Section 4.5で定義されているイベントアクショ ンの値を意味する。 * "domain variant relation" -- Section 5.3で定義されているドメイ ン及びドメインの異体字との関係性を意味する。 3. Description -- その値が、どのように使用されるか、どのようにクラ イアントで解釈されるべきか、その両方またはいずれか一方の意味に関 する1~2文による説明。 4. Registrant Name -- その値を登録する個人の名称 5. Registrant Contact Information ? 登録者に連絡するために使用され る、電子メールアドレス、郵便の宛先、またはその他の情報。 このレジストリは、[RFC5226] で定義されている"Expert Review"ポリシー の下で運用される。 指名された専門家による本レジストリへの登録レビューは、下記の基準によ って厳格に判断されなくてはならない。 1. 複数の型の中に配置が必要とされる値は、各型に対して別々の登録を割 り当てさせなくてはならない。 2. 値は、文字列でなくてはならない。その値は、単一の空白文字で分離さ れた複数の単語であるべきである。すべての文字は、小文字にすべきで ある。可能であれば、すべての単語は英語で与えられ、かつ、各文字は US-ASCIIとすべきである。 3. 登録は、いかなる既存の登録の意味と重複してはならない。つまり、も し登録の依頼内容が、既存の登録内容と著しく似た性質のものであった 場合、その依頼は却下されるべきである。例えば、"maintainer"及び "registrant"という用語の両方が、ドメイン名またはインターネット番 号資源の保有者を意味するので、それらは著しく似た性質の内容である 場合など。二つの類似した値の機械翻訳が、クライアントソフトウェア の動きを変更する可能性があると合理的に論じられているケースでは、 指定された専門家は、値が著しく類似していると評価すべきではない。 4. 登録は、RDAPの共通使用法に関連しているべきである。指定された専門 家は、これを決定するためにDNRまたはRIRが提供する値を信頼すること ができる。 以降のセクションでは、"JSON Values"レジストリに初期登録する情報を提 供している。 Newton & Hollenbeck Standards Track [Page 51] RFC 7483 RDAP JSON Responses March 2015 10.2.1. Notice and Remark Types 下記の値は、"RDAP JSON Values"レジストリに登録されている。 Value: result set truncated due to authorization (認可が原因で切り詰められた結果のセット) Type: notice and remark type (通知及び注釈の型) Description: The list of results does not contain all results due to lack of authorization. This may indicate to some clients that proper authorization will yield a longer result set. (結果のリストは、認可の不足が原因で、すべての結果を含んではいな い。これは、クライアントに、適切な認可がより長い結果のセットを もたらすことを示す。) Registrant Name: IESG Registrant Contact Information: iesg@ietf.org Value: result set truncated due to excessive load (過負荷が原因で切り詰められた結果のセット) Type: notice and remark type (通知及び注釈の型) Description: The list of results does not contain all results due to an excessively heavy load on the server. This may indicate to some clients that requerying at a later time will yield a longer result set. (結果のリストは、サーバーへの過重負荷が原因で、すべての結果を含 んではいない。これは、あるクライアントに、その後の再問い合わせ がより長い結果のセットをもたらすことを示す。) Registrant Name: IESG Registrant Contact Information: iesg@ietf.org Value: result set truncated due to unexplainable reasons (説明できない理由が原因で切り詰められた結果のセット) Type: notice and remark type (通知及び注釈の型) Description: The list of results does not contain all results for an unexplainable reason. This may indicate to some clients that requerying for any reason will not yield a longer result set. (結果のリストは、説明できない理由が原因で、すべての結果を含んで はいない。これは、クライアントに、その後の再問い合わせがより長 い結果のセットをもたらさないことを示す。) Registrant Name: IESG Registrant Contact Information: iesg@ietf.org Newton & Hollenbeck Standards Track [Page 52] RFC 7483 RDAP JSON Responses March 2015 Value: object truncated due to authorization (認可が原因で切り詰められたオブジェクト) Type: notice and remark type (通知及び注釈の型) Description: The object does not contain all data due to lack of authorization. (オブジェクトは、認可の不足が原因で、すべてのデータを含んではい ない。) Registrant Name: IESG Registrant Contact Information: iesg@ietf.org Value: object truncated due to excessive load (過負荷が原因で切り詰められた結果のセット) Type: notice and remark type (通知及び注釈の型) Description: The object does not contain all data due to an excessively heavy load on the server. This may indicate to some clients that requerying at a later time will yield all data of the object. (オブジェクトは、サーバーへの過重負荷が原因で、すべてのデータを 含んではいない。これは、クライアントに、その後の再問い合わせが オブジェクト全体のデータをもたらすことを示唆する。) Registrant Name: IESG Registrant Contact Information: iesg@ietf.org Value: object truncated due to unexplainable reasons (説明できない理由が原因で切り詰められた結果のセット) Type: notice and remark type (通知及び注釈の型) Description: The object does not contain all data for an unexplainable reason. (説明できない理由で、オブジェクトがすべてのデータを含んでいない。) Registrant Name: IESG Registrant Contact Information: iesg@ietf.org 10.2.2. Status 下記の値は、"RDAP JSON Values"レジストリに登録されている。 Value: validated (有効) Type: status (ステータス) Newton & Hollenbeck Standards Track [Page 53] RFC 7483 RDAP JSON Responses March 2015 Description: Signifies that the data of the object instance has been found to be accurate. This type of status is usually found on entity object instances to note the validity of identifying contact information. (オブジェクトインスタンスのデータが正確であることを示す。このス テータスの型は、識別するコンタクト情報の妥当性に留意するために、 エンティティーオブジェクトインスタンスで通常見られる。) Registrant Name: IESG Registrant Contact Information: iesg@ietf.org Value: renew prohibited (更新の禁止) Type: status (ステータス) Description: Renewal or reregistration of the object instance is forbidden. (オブジェクトインスタンスの更新または再登録は、禁止されている。) Registrant Name: IESG Registrant Contact Information: iesg@ietf.org Value: update prohibited (改訂の禁止) Type: status (ステータス) Description: Updates to the object instance are forbidden. (オブジェクトインスタンスの改訂は、禁止されている。) Registrant Name: IESG Registrant Contact Information: iesg@ietf.org Value: transfer prohibited (移転の禁止) Type: status (ステータス) Description: Transfers of the registration from one registrar to another are forbidden. This type of status normally applies to DNR domain names. (あるレジストラから他のレジストラへの登録の移転は、禁止されてい る。このステータスの型は、通常DNRドメイン名に適用する。) Registrant Name: IESG Registrant Contact Information: iesg@ietf.org Value: delete prohibited (削除の禁止) Newton & Hollenbeck Standards Track [Page 54] RFC 7483 RDAP JSON Responses March 2015 Type: status (ステータス) Description: Deletion of the registration of the object instance is forbidden. This type of status normally applies to DNR domain names. (オブジェクトインスタンスの登録を削除することは、禁止されている。 このステータスの型は、通常DNRドメイン名に適用する。) Registrant Name: IESG Registrant Contact Information: iesg@ietf.org Value: proxy (プロキシー) Type: status (ステータス) Description: The registration of the object instance has been performed by a third party. This is most commonly applied to entities. (オブジェクトインスタンスの登録は、第三者によって行われている。 これは、エンティティーに最も多く適用する。) Registrant Name: IESG Registrant Contact Information: iesg@ietf.org Value: private (非公開) Type: status (ステータス) Description: The information of the object instance is not designated for public consumption. This is most commonly applied to entities. (オブジェクトインスタンスの情報は、公開することを指定されていな い。これは、エンティティーに最も多く適用する。) Registrant Name: IESG Registrant Contact Information: iesg@ietf.org Value: removed (削除されている) Type: status (ステータス) Description: Some of the information of the object instance has not been made available and has been removed. This is most commonly applied to entities. (オブジェクトインスタンスのいくつかの情報は、利用可能ではなく、 また削除されている。これは、エンティティーに最も多く適用する。) Registrant Name: IESG Registrant Contact Information: iesg@ietf.org Newton & Hollenbeck Standards Track [Page 55] RFC 7483 RDAP JSON Responses March 2015 Value: obscured (覆い隠されている) Type: status (ステータス) Description: Some of the information of the object instance has been altered for the purposes of not readily revealing the actual information of the object instance. This is most commonly applied to entities. (オブジェクトインスタンスのいくつかの情報は、オブジェクトインス タンスの実情報を容易に開示しないのために変更されている。これは、 エンティティーに最も多く適用する。) Registrant Name: IESG Registrant Contact Information: iesg@ietf.org Value: associated (関連付けられている) Type: status (ステータス) Description: The object instance is associated with other object instances in the registry. This is most commonly used to signify that a nameserver is associated with a domain or that an entity is associated with a network resource or domain. (オブジェクトインスタンスは、レジストリの他のオブジェクトインス タンスと関連付けられている。これは、ネームサーバーがドメインに 関連付けられている、またはエンティティーがネットワーク資源もし くはドメインに関連付けられていることを示すために通常使用される。) Registrant Name: IESG Registrant Contact Information: iesg@ietf.org Value: active (アクティブ) Type: status (ステータス) Description: The object instance is in use. For domain names, it signifies that the domain name is published in DNS. For network and autnum registrations, it signifies that they are allocated or assigned for use in operational networks. This maps to the "OK" status of the Extensible Provisioning Protocol (EPP) [RFC5730] . (オブジェクトインスタンスは、使用されている。ドメイン名において は、ドメイン名がDNS上で公開されていることを示す。ネットワーク 及びautnum(AS番号)登録においては、運用ネットワーク用に割り振 られているか、割り当てられていることを示す。これは、EPP(the Extensible Provisioning Protocol)[RFC5730] の"OK"ステータスに マッピングされている。) Newton & Hollenbeck Standards Track [Page 56] RFC 7483 RDAP JSON Responses March 2015 Registrant Name: IESG Registrant Contact Information: iesg@ietf.org Value: inactive (非アクティブ) Type: status (ステータス) Description: The object instance is not in use. See "active". (オブジェクトインスタンスは、使用されていない。"active"を参照。) Registrant Name: IESG Registrant Contact Information: iesg@ietf.org Value: locked (ロックされている) Type: status (ステータス) Description: Changes to the object instance cannot be made, including the association of other object instances. (オブジェクトインスタンスに対する変更は、他のオブジェクトインス タンスの関連を含めてできない。) Registrant Name: IESG Registrant Contact Information: iesg@ietf.org Value: pending create (作成待機中) Type: status (ステータス) Description: A request has been received for the creation of the object instance, but this action is not yet complete. (オブジェクトインスタンスの作成要求が受信されたが、いまだその行 為が完了していない。) Registrant Name: IESG Registrant Contact Information: iesg@ietf.org Value: pending renew (更新待機中) Type: status (ステータス) Description: A request has been received for the renewal of the object instance, but this action is not yet complete. (オブジェクトインスタンスの更新要求が受信されたが、いまだその行 為が完了していない。) Newton & Hollenbeck Standards Track [Page 57] RFC 7483 RDAP JSON Responses March 2015 Registrant Name: IESG Registrant Contact Information: iesg@ietf.org Value: pending transfer (移転待機中) Type: status (ステータス) Description: A request has been received for the transfer of the object instance, but this action is not yet complete. (オブジェクトインスタンスの移転要求が受信されたが、いまだその行 為が完了していない。) Registrant Name: IESG Registrant Contact Information: iesg@ietf.org Value: pending update (改訂待機中) Type: status (ステータス) Description: A request has been received for the update or modification of the object instance, but this action is not yet complete. (オブジェクトインスタンスの改訂または修正要求が受信されたが、い まだその行為が完了していない。) Registrant Name: IESG Registrant Contact Information: iesg@ietf.org Value: pending delete (削除待機中) Type: status (ステータス) Description: A request has been received for the deletion or removal of the object instance, but this action is not yet complete. For domains, this might mean that the name is no longer published in DNS but has not yet been purged from the registry database. (オブジェクトインスタンスの削除または除去要求が受信されたが、い まだその行為が完了していない。ドメインにおいては、ドメイン名が もはやDNS上で公開されていないが、いまだレジストリのデータベー スから消却されていないことを示しているかもしれない。) Registrant Name: IESG Registrant Contact Information: iesg@ietf.org 10.2.3. Event Actions 下記の値は、"RDAP JSON Values"レジストリに登録されている。 Newton & Hollenbeck Standards Track [Page 58] RFC 7483 RDAP JSON Responses March 2015 Value: registration (登録) Type: event action (イベントアクション) Description: The object instance was initially registered. (オブジェクトインスタンスは、最初に登録された。) Registrant Name: IESG Registrant Contact Information: iesg@ietf.org Value: reregistration (再登録) Type: event action (イベントアクション) Description: The object instance was registered subsequently to initial registration. (オブジェクトインスタンスは、最初の登録の後に再登録された。) Registrant Name: IESG Registrant Contact Information: iesg@ietf.org Value: last changed (前回の変更) Type: event action (イベントアクション) Description: An action noting when the information in the object instance was last changed. (オブジェクトインスタンスの情報が前回変更されたことの注記。) Registrant Name: IESG Registrant Contact Information: iesg@ietf.org Value: expiration (期限切れ) Type: event action (イベントアクション) Description: The object instance has been removed or will be removed at a predetermined date and time from the registry. (オブジェクトインスタンスは、所定の日時にレジストリから削除され た、または削除される予定である。) Registrant Name: IESG Registrant Contact Information: iesg@ietf.org Value: deletion (削除) Type: event action (イベントアクション) Newton & Hollenbeck Standards Track [Page 59] RFC 7483 RDAP JSON Responses March 2015 Description: The object instance was removed from the registry at a point in time that was not predetermined. (オブジェクトインスタンスは、所定ではない時点で、レジストリから 削除された。) Registrant Name: IESG Registrant Contact Information: iesg@ietf.org Value: reinstantiation (再インスタンス化) Type: event action (イベントアクション) Description: The object instance was reregistered after having been removed from the registry. (オブジェクトインスタンスは、レジストリから削除された後に再登録 された。) Registrant Name: IESG Registrant Contact Information: iesg@ietf.org Value: transfer (移転) Type: event action (イベントアクション) Description: The object instance was transferred from one registrant to another. (オブジェクトインスタンスは、あるレジストラから別のレジストラへ 移転された。) Registrant Name: IESG Registrant Contact Information: iesg@ietf.org Value: locked (ロックされている) Type: event action (イベントアクション) Description: The object instance was locked (see the "locked" status). (オブジェクトインスタンスは、ロックされた(Statusの"locked"を参 照)。) Registrant Name: IESG Registrant Contact Information: iesg@ietf.org Value: unlocked (ロックが解除されている) Type: event action (イベントアクション) Newton & Hollenbeck Standards Track [Page 60] RFC 7483 RDAP JSON Responses March 2015 Description: The object instance was unlocked (see the "locked" status). (オブジェクトインスタンスは、ロックを解除された(Statusの "locked"を参照)。) Registrant Name: IESG Registrant Contact Information: iesg@ietf.org 10.2.4. Roles 下記の値は、"RDAP JSON Values"レジストリに登録されている。 Value: registrant (登録者) Type: role (役割) Description: The entity object instance is the registrant of the registration. In some registries, this is known as a maintainer. (エンティティーオブジェクトインスタンスは、その登録に関する登録 者である。いくつかのレジストリでは、これは維持管理者 (maintainer)として知られている。) Registrant Name: IESG Registrant Contact Information: iesg@ietf.org Value: technical (技術者) Type: role (役割) Description: The entity object instance is a technical contact for the registration. (エンティティーオブジェクトインスタンスは、その登録に関する技術 者の連絡先である。) Registrant Name: IESG Registrant Contact Information: iesg@ietf.org Value: administrative (管理者) Type: role (役割) Description: The entity object instance is an administrative contact for the registration. (エンティティーオブジェクトインスタンスは、その登録に関する管理 者の連絡先である。) Registrant Name: IESG Registrant Contact Information: iesg@ietf.org Newton & Hollenbeck Standards Track [Page 61] RFC 7483 RDAP JSON Responses March 2015 Value: abuse (不正使用) Type: role (役割) Description: The entity object instance handles network abuse issues on behalf of the registrant of the registration. (エンティティーオブジェクトインスタンスは、その登録に関する登録 者を代表してネットワークの不正使用の問題を扱う。) Registrant Name: IESG Registrant Contact Information: iesg@ietf.org Value: billing (請求) Type: role (役割) Description: The entity object instance handles payment and billing issues on behalf of the registrant of the registration. (エンティティーオブジェクトインスタンスは、その登録に関する登録 者を代表して支払及び請求の問題を扱う。) Registrant Name: IESG Registrant Contact Information: iesg@ietf.org Value: registrar (レジストラ) Type: role (役割) Description: The entity object instance represents the authority responsible for the registration in the registry. (エンティティーオブジェクトインスタンスは、レジストリにおいて権 威のある登録責任者を表す。) Registrant Name: IESG Registrant Contact Information: iesg@ietf.org Value: reseller (リセラー) Type: role (役割) Description: The entity object instance represents a third party through which the registration was conducted (i.e., not the registry or registrar). (エンティティーオブジェクトインスタンスは、その登録が第三者を通 して実施されたことを表す(すなわち、レジストリやレジストラでは ない)。) Registrant Name: IESG Registrant Contact Information: iesg@ietf.org Newton & Hollenbeck Standards Track [Page 62] RFC 7483 RDAP JSON Responses March 2015 Value: sponsor (スポンサー) Type: role (役割) Description: The entity object instance represents a domain policy sponsor, such as an ICANN-approved sponsor. (エンティティーオブジェクトインスタンスは、ICANN認定スポンサー などのドメインポリシースポンサーを表す。) Registrant Name: IESG Registrant Contact Information: iesg@ietf.org Value: proxy (プロキシー) Type: role (役割) Description: The entity object instance represents a proxy for another entity object, such as a registrant. (エンティティーオブジェクトインスタンスは、登録者などの別のエン ティティーオブジェクトのためのプロキシーを表す。) Registrant Name: IESG Registrant Contact Information: iesg@ietf.org Value: notifications (通知) Type: role (役割) Description: An entity object instance designated to receive notifications about association object instances. (オブジェクトインスタンスの関連性に関する通知を受信することが指 定されたエンティティーオブジェクトインスタンス。) Registrant Name: IESG Registrant Contact Information: iesg@ietf.org Value: noc (NOC:ネットワークオペレーションセンター) Type: role (役割) Description: The entity object instance handles communications related to a network operations center (NOC). (エンティティーオブジェクトインスタンスは、NOC(ネットワークオ ペレーションセンター)に関する情報交換を扱う。) Registrant Name: IESG Registrant Contact Information: iesg@ietf.or Newton & Hollenbeck Standards Track [Page 63] RFC 7483 RDAP JSON Responses March 2015 10.2.5. Variant Relations 下記の値は、"RDAP JSON Values"レジストリに登録されている。 Value: registered (登録済み) Type: domain variant relation (ドメインの異体字関係) Description: The variant names are registered in the registry. (異体字名が、レジストリに登録されている。) Registrant Name: IESG Registrant Contact Information: iesg@ietf.org Value: unregistered (未登録) Type: domain variant relation (ドメインの異体字関係) Description: The variant names are not found in the registry. (異体字名が、レジストリ上で見つからない。) Registrant Name: IESG Registrant Contact Information: iesg@ietf.org Value: registration restricted (制限された登録) Type: domain variant relation (ドメインの異体字関係) Description: Registration of the variant names is restricted to certain parties or within certain rules. (異体字名の登録が、ある関係者に制限されている、または一定のルー ルの中で制限されている。) Registrant Name: IESG Registrant Contact Information: iesg@ietf.org Value: open registration (公開登録) Type: domain variant relation (ドメインの異体字関係) Description: Registration of the variant names is available to generally qualified registrants. (異体字名の登録は、通常資格のある登録者が利用可能である。) Registrant Name: IESG Registrant Contact Information: iesg@ietf.org Newton & Hollenbeck Standards Track [Page 64] RFC 7483 RDAP JSON Responses March 2015 Value: conjoined (統合) Type: domain variant relation (ドメインの異体字関係) Description: Registration of the variant names occurs automatically with the registration of the containing domain registration. (異体字名の登録は、包含するドメイン登録の登録と共に自動的に起こ る。) Registrant Name: IESG Registrant Contact Information: iesg@ietf.org 11. Security Considerations この仕様は、JSONフォーマットで直列化した情報をモデル化する。JSONは JavaScriptのサブセットであるので、実装は、コードインジェクションを防 止するために [RFC7159] のSection 6で概説されているセキュリティの考察 に従うことを求める。 JSON独自ではないが、RDAPの実装者は、[RFC7480] で規定されるセキュリティ の考察及び [RFC7481] のセキュリティの要件と考察を認識すべきである。 データをキャッシュするクライアント、特に(HTTP層のキャッシュの代わり に)RDAP独自のキャッシュを使用するクライアントは、キャッシュポイズニ ングを防ぐためにセーフガードを持つべきである。キャッシュのために自己 リンクを用いることの助言は、Section 5を参照。 最後に、サービスオペレーターは、Section 13で記述されているプライバシー メカニズムを認識すべきである。 12. Internationalization Considerations 12.1. Character Encoding RDAPのJSON応答におけるデフォルトのテキストエンコーディングは、UTF-8 [RFC3629] であり、すべてのサーバーとクライアントは、UTF-8をサポート しなければならない(MUST)。 12.2. URIs and IRIs [RFC7480] は、RDAPにおけるURI及びIRIの使用を定義している。 12.3. Language Tags Section 4.4は、本ドキュメントで定義されているJSON応答での言語タグの 使用を定義している。 Newton & Hollenbeck Standards Track [Page 65] RFC 7483 RDAP JSON Responses March 2015 12.4. Internationalized Domain Names 国際化ドメイン名(IDN)は、LDH形式とUnicode形式に分けたDNS名 (Section 3を参照)という形でこの仕様の中で表されている。レジストリ による国際化ドメイン名は、Section 5.3の"variants"オブジェクトで説明 されており、また推薦する値は、Section 10.2.5で列挙されている。 13. Privacy Considerations 本仕様は、非公開としてマークされている、削除もしくは覆い隠されている、 その両方またはいずれか一方に該当するコンタクト及び登録者情報を表すた めにステータス値を提案する。完全なステータス値のリストは、Section 10.2.2を参照。いくつかのステータス値は、オブジェクトインスタンスに関 連付けられたプライバシーに対する懸念があることを示す。下記のステータ スコードは、適切な場合、応答のデータ要素を説明するために使用されるべ きである(SHOULD)。 private -- このオブジェクトは、ユーザーが本情報の参照を認可されて いない場合、クエリへの応答内で共有されない。 removed -- オブジェクト内のデータ要素は収集されているが、応答から 除外されている。このオプションは、非公開としてマークする必要なし に、関連付けられたオブジェクトインスタンスへの無認可のアクセスを 防止するために使用される。 obscured -- オブジェクト内のデータ要素は収集されているが、応答値 が変更されているので、値が容易に識別できない。"1212"から"XXXX"へ 変更された値は、覆い隠されたデータの例である。このオプションは、 個人機密情報を漏らす可能性があるため、データ感度が"private"または "removed"のようなより高い保護オプションを要求しない時だけに使用さ れるべきである。 これらの値をコンタクトや登録者に適用した例は、Appendix A.1を参照。 14. References 14.1. Normative References [ISO.3166.1988] International Organization for Standardization, "Codes for the representation of names of countries, 3rd edition", ISO Standard 3166, August 1988. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997, . Newton & Hollenbeck Standards Track [Page 66] RFC 7483 RDAP JSON Responses March 2015 [RFC3339] Klyne, G., Ed. and C. Newman, "Date and Time on the Internet: Timestamps", RFC 3339, July 2002, . [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003, . [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005, . [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "Resource Records for the DNS Security Extensions", RFC 4034, March 2005, . [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008, . [RFC5396] Huston, G. and G. Michaelson, "Textual Representation of Autonomous System (AS) Numbers", RFC 5396, December 2008, . [RFC5646] Phillips, A. and M. Davis, "Tags for Identifying Languages", BCP 47, RFC 5646, September 2009, . [RFC5890] Klensin, J., "Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework", RFC 5890, August 2010, . [RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6 Address Text Representation", RFC 5952, August 2010, . [RFC5988] Nottingham, M., "Web Linking", RFC 5988, October 2010, . [RFC7095] Kewisch, P., "jCard: The JSON Format for vCard", RFC 7095, January 2014, . [RFC7159] Bray, T., "The JavaScript Object Notation (JSON) Data Interchange Format", RFC 7159, March 2014, . Newton & Hollenbeck Standards Track [Page 67] RFC 7483 RDAP JSON Responses March 2015 [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, . [RFC7482] Newton, A. and S. Hollenbeck, "Registration Data Access Protocol (RDAP) Query Format", RFC 7482, March 2015, . 14.2. Informative References [IANA_IDNTABLES] IANA, "Repository of IDN Practices", . [JSON_ascendancy] MacVittie, L., "The Stealthy Ascendancy of JSON", April 2011, . [JSON_performance_study] Nurseitov, N., Paulson, M., Reynolds, R., and C. Izurieta, "Comparison of JSON and XML Data Interchange Formats: A Case Study", 2009, . [RFC3912] Daigle, L., "WHOIS Protocol Specification", RFC 3912, September 2004, . [RFC5730] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)", STD 69, RFC 5730, August 2009, . [RFC5910] Gould, J. and S. Hollenbeck, "Domain Name System (DNS) Security Extensions Mapping for the Extensible Provisioning Protocol (EPP)", RFC 5910, May 2010, . [RFC6350] Perreault, S., "vCard Format Specification", RFC 6350, August 2011, . [RFC6839] Hansen, T. and A. Melnikov, "Additional Media Type Structured Syntax Suffixes", RFC 6839, January 2013, . Newton & Hollenbeck Standards Track [Page 68] RFC 7483 RDAP JSON Responses March 2015 Appendix A. Suggested Data Modeling with the Entity Object Class A.1. Registrants and Contacts This document does not provide specific object classes for registrants and contacts. Instead, the entity object class may be used to represent a registrant or contact. When the entity object is embedded inside a containing object such as a domain name or IP network, the "roles" string array can be used to signify the relationship. It is recommended that the values from Section 10.2.4 be used. The following is an example of an elided containing object with an embedded entity that is both a registrant and administrative contact: { ... "entities" : [ { "objectClassName" : "entity", "handle" : "XXXX", "vcardArray":[ "vcard", [ ["version", {}, "text", "4.0"], ["fn", {}, "text", "Joe User"], ["kind", {}, "text", "individual"], ["lang", { "pref":"1" }, "language-tag", "fr"], ["lang", { "pref":"2" }, "language-tag", "en"], ["org", { "type":"work" }, "text", "Example"], ["title", {}, "text", "Research Scientist"], ["role", {}, "text", "Project Lead"], ["adr", { "type":"work" }, "text", [ "", "Suite 1234", "4321 Rue Somewhere", "Quebec", "QC", Newton & Hollenbeck Standards Track [Page 69] RFC 7483 RDAP JSON Responses March 2015 "G1V 2M2", "Canada" ] ], ["tel", { "type":["work", "voice"], "pref":"1" }, "uri", "tel:+1-555-555-1234;ext=102" ], ["email", { "type":"work" }, "text", "joe.user@example.com" ] ] ], "roles" : [ "registrant", "administrative" ], "remarks" : [ { "description" : [ "She sells sea shells down by the sea shore.", "Originally written by Terry Sullivan." ] } ], "events" : [ { "eventAction" : "registration", "eventDate" : "1990-12-31T23:59:59Z" }, { "eventAction" : "last changed", "eventDate" : "1991-12-31T23:59:59Z" } ] } ] } Figure 34 In many use cases, it is necessary to hide or obscure the information of a registrant or contact due to policy or other operational matters. Registries can denote these situations with "status" values (see Section 10.2.2). Newton & Hollenbeck Standards Track [Page 70] RFC 7483 RDAP JSON Responses March 2015 The following is an elided example of a registrant with information changed to reflect that of a third party. { ... "entities" : [ { "objectClassName" : "entity", "handle" : "XXXX", ... "roles" : [ "registrant", "administrative" ], "status" : [ "proxy", "private", "obscured" ] } ] } Figure 35 A.2. Registrars This document does not provide a specific object class for registrars, but like registrants and contacts (see Appendix A.1), the "roles" string array maybe used. Additionally, many registrars have publicly assigned identifiers. The publicIds structure (Section 4.8) represents that information. The following is an example of an elided containing object with an embedded entity that is a registrar: { ... "entities":[ { "objectClassName" : "entity", "handle":"XXXX", "vcardArray":[ "vcard", [ ["version", {}, "text", "4.0"], ["fn", {}, "text", "Joe's Fish, Chips, and Domains"], ["kind", {}, "text", "org"], ["lang", { "pref":"1" }, "language-tag", "fr"], ["lang", { "pref":"2" }, "language-tag", "en"], Newton & Hollenbeck Standards Track [Page 71] RFC 7483 RDAP JSON Responses March 2015 ["org", { "type":"work" }, "text", "Example"], ["adr", { "type":"work" }, "text", [ "", "Suite 1234", "4321 Rue Somewhere", "Quebec", "QC", "G1V 2M2", "Canada" ] ], ["tel", { "type":["work", "voice"], "pref":"1" }, "uri", "tel:+1-555-555-1234;ext=102" ], ["email", { "type":"work" }, "text", "joes_fish_chips_and_domains@example.com" ] ] ], "roles":[ "registrar" ], "publicIds":[ { "type":"IANA Registrar ID", "identifier":"1" } ], "remarks":[ { "description":[ "She sells sea shells down by the sea shore.", "Originally written by Terry Sullivan." ] } ], "links":[ { "value":"http://example.net/entity/XXXX", "rel":"alternate", Newton & Hollenbeck Standards Track [Page 72] RFC 7483 RDAP JSON Responses March 2015 "type":"text/html", "href":"http://www.example.com" } ] } ] } Figure 36 Appendix B. Modeling Events Events represent actions that have taken place against a registered object at a certain date and time. Events have three properties: the action, the actor, and the date and time of the event (which is sometimes in the future). In some cases, the identity of the actor is not captured. Events can be modeled in three ways: 1. events with no designated actor 2. events where the actor is only designated by an identifier 3. events where the actor can be modeled as an entity For the first use case, the events data structure (Section 4.5) is used without the "eventActor" object member. This is an example of an "events" array without the "eventActor". "events" : [ { "eventAction" : "registration", "eventDate" : "1990-12-31T23:59:59Z" } ] Figure 37 For the second use case, the events data structure (Section 4.5) is used with the "eventActor" object member. Newton & Hollenbeck Standards Track [Page 73] RFC 7483 RDAP JSON Responses March 2015 This is an example of an "events" array with the "eventActor". "events" : [ { "eventAction" : "registration", "eventActor" : "XYZ-NIC", "eventDate" : "1990-12-31T23:59:59Z" } ] Figure 38 For the third use case, the "asEventActor" array is used when an entity (Section 5.1) is embedded into another object class. The "asEventActor" array follows the same structure as the "events" array but does not have "eventActor" attributes. The following is an elided example of a domain object with an entity as an event actor. { "objectClassName" : "domain", "handle" : "XXXX", "ldhName" : "foo.example", "status" : [ "locked", "transfer prohibited" ], ... "entities" : [ { "handle" : "XXXX", ... "asEventActor" : [ { "eventAction" : "last changed", "eventDate" : "1990-12-31T23:59:59Z" } ] } ] } Figure 39 Newton & Hollenbeck Standards Track [Page 74] RFC 7483 RDAP JSON Responses March 2015 Appendix C. Structured vs. Unstructured Addresses The entity (Section 5.1) object class uses jCard [RFC7095] to represent contact information, including postal addresses. jCard has the ability to represent multiple language preferences, multiple email address and phone numbers, and multiple postal addresses in both a structured and unstructured format. This section describes the use of jCard for representing structured and unstructured addresses. The following is an example of a jCard. { "vcardArray":[ "vcard", [ ["version", {}, "text", "4.0"], ["fn", {}, "text", "Joe User"], ["n", {}, "text", ["User", "Joe", "", "", ["ing. jr", "M.Sc."]] ], ["kind", {}, "text", "individual"], ["lang", { "pref":"1" }, "language-tag", "fr"], ["lang", { "pref":"2" }, "language-tag", "en"], ["org", { "type":"work" }, "text", "Example"], ["title", {}, "text", "Research Scientist"], ["role", {}, "text", "Project Lead"], ["adr", { "type":"work" }, "text", [ "", "Suite 1234", "4321 Rue Somewhere", "Quebec", "QC", "G1V 2M2", "Canada" ] ], ["adr", { Newton & Hollenbeck Standards Track [Page 75] RFC 7483 RDAP JSON Responses March 2015 "type":"home", "label":"123 Maple Ave\nSuite 90001\nVancouver\nBC\n1239\n" }, "text", [ "", "", "", "", "", "", "" ] ], ["tel", { "type":["work", "voice"], "pref":"1" }, "uri", "tel:+1-555-555-1234;ext=102" ], ["tel", { "type":["work", "cell", "voice", "video", "text"] }, "uri", "tel:+1-555-555-1234" ], ["email", { "type":"work" }, "text", "joe.user@example.com" ], ["geo", { "type":"work" }, "uri", "geo:46.772673,-71.282945"], ["key", { "type":"work" }, "uri", "http://www.example.com/joe.user/joe.asc" ], ["tz", {}, "utc-offset", "-05:00"], ["url", { "type":"home" }, "uri", "http://example.org"] ] ] } Figure 40 The arrays in Figure 40 with the first member of "adr" represent postal addresses. In the first example, the postal address is given as an array of strings and constitutes a structured address. For components of the structured address that are not applicable, an empty string is given. Each member of that array aligns with the positions of a vCard as given in [RFC6350]. In this example, the following data corresponds to the following positional meanings: Newton & Hollenbeck Standards Track [Page 76] RFC 7483 RDAP JSON Responses March 2015 1. post office box -- not applicable; empty string 2. extended address (e.g., apartment or suite number) -- Suite 1234 3. street address -- 4321 Rue Somewhere 4. locality (e.g., city) -- Quebec 5. region (e.g., state or province) -- QC 6. postal code -- G1V 2M2 7. country name (full name) -- Canada The second example is an unstructured address. It uses the label attribute, which is a string containing a newline (\n) character to separate address components in an unordered, unspecified manner. Note that in this example, the structured address array is still given but that each string is an empty string. Appendix D. Secure DNS Section 5.3 defines the "secureDNS" member to represent secure DNS information about domain names. DNSSEC provides data integrity for DNS through the digital signing of resource records. To enable DNSSEC, the zone is signed by one or more private keys and the signatures are stored as RRSIG records. To complete the chain of trust in the DNS zone hierarchy, a digest of each DNSKEY record (which contains the public key) must be loaded into the parent zone, stored as DS records, and signed by the parent's private key (RRSIG DS record), as indicated in "Resource Records for the DNS Security Extensions" [RFC4034]. Creating the DS records in the parent zone can be done by the registration authority "Domain Name System (DNS) Security Extensions Mapping for the Extensible Provisioning Protocol (EPP)" [RFC5910]. Only DS-related information is provided by RDAP, since other information is not generally stored in the registration database. Other DNSSEC-related information can be retrieved with other DNS tools such as dig. The domain object class (Section 5.3) can represent this information using either the "dsData" or "keyData" object arrays. Client implementers should be aware that some registries do not collect or do not publish all of the secure DNS meta-information. Newton & Hollenbeck Standards Track [Page 77] RFC 7483 RDAP JSON Responses March 2015 Appendix E. Motivations for Using JSON This section addresses a common question regarding the use of JSON over other data formats, most notably XML. It is often pointed out that many DNRs and one RIR support the EPP [RFC5730] standard, which is an XML serialized protocol. The logic is that since EPP is a common protocol in the industry, it follows that XML would be a more natural choice. While EPP does influence this specification quite a bit, EPP serves a different purpose, which is the provisioning of Internet resources between registries and accredited registrars and serving a much narrower audience than that envisioned for RDAP. By contrast, RDAP has a broader audience and is designed for public consumption of data. Experience from RIRs with first generation RESTful web services for WHOIS indicate that a large percentage of clients operate within browsers and other platforms where full-blown XML stacks are not readily available and where JSON is a better fit. Additionally, while EPP is used in much of the DNR community it is not a universal constant in that industry. And finally, EPP's use of XML predates the specification of JSON. If EPP had been defined today, it may very well have used JSON instead of XML. Beyond the specific DNR and RIR communities, the trend in the broader Internet industry is also switching to JSON over XML, especially in the area of RESTful web services (see [JSON_ascendancy]). Studies have also found that JSON is generally less bulky and consequently faster to parse (see [JSON_performance_study]). Acknowledgements This document is derived from original work on RIR responses in JSON by Byron J. Ellacott, Arturo L. Servin, Kaveh Ranjbar, and Andrew L. Newton. Additionally, this document incorporates work on DNR responses in JSON by Ning Kong, Linlin Zhou, Jiagui Xie, and Sean Shen. The components of the DNR object classes are derived from a categorization of WHOIS response formats created by Ning Kong, Linlin Zhou, Guangqing Deng, Steve Sheng, Francisco Arias, Ray Bellis, and Frederico Neves. Tom Harrison, Murray Kucherawy, Ed Lewis, Audric Schiltknecht, Naoki Kambe, and Maarten Bosteels contributed significant review comments and provided clarifying text. James Mitchell provided text regarding the processing of unknown JSON attributes and identified issues Newton & Hollenbeck Standards Track [Page 78] RFC 7483 RDAP JSON Responses March 2015 leading to the remodeling of events. Ernie Dainow and Francisco Obispo provided concrete suggestions that led to a better variant model for domain names. Ernie Dainow provided the background information on the secure DNS attributes and objects for domains, informative text on DNSSEC, and many other attributes that appear throughout the object classes of this document. The switch to and incorporation of jCard was performed by Simon Perreault. Olaf Kolkman and Murray Kucherawy chaired the IETF's WEIRDS working group from which this document has been created. 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 79] RFC7483-ja.txt revision 1.0 この翻訳文に関するお問い合わせは dnstech-info@jprs.jp までご連絡下さい。 Japan Registry Services Co., Ltd. https://jprs.jp/tech/