[要約] RFC 8982は、RDAP（Registration Data Access Protocol）の部分的な応答を可能にするための仕様です。この機能により、ユーザーは必要な情報のみをリクエストし、応答から取得できるようになります。これは、データの過剰な転送を避け、効率的なデータアクセスを実現するために利用されます。
Internet Engineering Task Force (IETF) M. Loffredo
Request for Comments: 8982 M. Martinelli
Category: Standards Track IIT-CNR/Registro.it
ISSN: 2070-1721 February 2021
Registration Data Access Protocol (RDAP) Partial Response
登録データアクセスプロトコル（RDAP）部分応答
Abstract
概要
The Registration Data Access Protocol (RDAP) does not include capabilities to request partial responses. Servers will only return full responses that include all of the information that a client is authorized to receive. A partial response capability that limits the amount of information returned, especially in the case of search queries, could bring benefits to both clients and servers. This document describes an RDAP query extension that allows clients to specify their preference for obtaining a partial response.
登録データアクセスプロトコル（RDAP）には、部分応答を要求する機能は含まれていません。サーバーは、クライアントが受信する権限があるというすべての情報を含む完全な回答を返すだけです。特に検索クエリの場合、返された情報の量を制限する部分的な応答機能は、クライアントとサーバーの両方に利益をもたらす可能性があります。このドキュメントでは、クライアントが部分的な応答を取得するための設定を指定できるようにするRDAPクエリ拡張機能について説明します。
Status of This Memo
本文書の位置付け
This is an Internet Standards Track document.
これはインターネット規格のトラック文書です。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.
この文書は、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表します。それは公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による出版の承認を受けました。インターネット規格に関する詳細情報は、RFC 7841のセクション2で利用できます。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc8982.
この文書の現在のステータス、任意のエラータ、およびフィードバックを提供する方法については、https://www.rfc-editor.org/info/rfc8982で取得できます。
Copyright Notice
著作権表示
Copyright (c) 2021 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2021 IETF信頼と文書著者として識別された人。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://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.
このドキュメントは、このドキュメントの発行日に有効なBCP 78およびIETFドキュメントに関連するIETFトラストの法的規定（https://trustee.ietf.org/license-info）の対象となります。 これらのドキュメントは、このドキュメントに関するお客様の権利と制限について説明しているため、注意深く確認してください。 このドキュメントから抽出されたコードコンポーネントには、Trust LegalProvisionsのセクション4.eで説明されているSimplifiedBSD Licenseテキストが含まれている必要があり、Simplified BSDLicenseで説明されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction
1.1. Conventions Used in This Document
2. RDAP Path Segment Specification
2.1. Subsetting Metadata
2.1.1. RDAP Conformance
2.1.2. Representing Subsetting Links
3. Dealing with Relationships
4. Basic Field Sets
5. Negative Answers
6. IANA Considerations
7. Security Considerations
8. References
8.1. Normative References
8.2. Informative References
Appendix A. Approaches to Partial Response Implementation
A.1. Specific Issues Raised by RDAP
Acknowledgements
Authors' Addresses
The use of partial responses in RESTful API [REST] design is very common. The rationale is quite simple: instead of returning objects in API responses with all data fields, only a subset of the fields in each result object is returned. The benefit is obvious: less data transferred over the network means less bandwidth usage, faster server responses, less CPU time spent both on the server and the client, and less memory usage on the client.
RESTful API [REST]デザインの部分応答の使用は非常に一般的です。根拠は非常に簡単です。すべてのデータフィールドを使用してAPI応答でオブジェクトを返す代わりに、各結果オブジェクトのフィールドのサブセットのみが返されます。利点は明らかです。ネットワーク経由で転送されたデータは、帯域幅の使用量、より速いサーバーの応答、より速いサーバーの応答、より少ないCPU時間が少なくなり、クライアント上のメモリ使用量が少なくなります。
Currently, RDAP does not provide a client with any way to request a partial response. Servers can only provide the client with a full response [RFC7483]. Servers cannot limit the amount of information returned in a response based on a client's preferences, and this creates inefficiencies.
現在、RDAPは部分的な応答を要求するための任意の方法でクライアントを提供しません。サーバーはクライアントにフルレスポンスを提供できます[RFC7483]。サーバーは、クライアントの環境設定に基づいて返信された情報の量を制限することはできません。これにより非効率性が発生します。
The protocol described in this specification extends RDAP search capabilities to enable partial responses through the provisioning of predefined sets of fields that clients can submit to an RDAP service by adding a new query parameter. The service is implemented using the Hypertext Transfer Protocol (HTTP) [RFC7230] and the conventions described in [RFC7480].
この仕様に記載されているプロトコルは、新しいクエリパラメータを追加して、クライアントがRDAPサービスに送信できる定義済みフィールドのセットのプロビジョニングを通じて、RDAP検索機能を拡張します。サービスは、ハイパーテキスト転送プロトコル（HTTP）[RFC7230]と[RFC7480]に記載されている規則を使用して実装されています。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
この文書のキーワード "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", および "OPTIONAL" はBCP 14 [RFC2119] [RFC8174]で説明されているように、すべて大文字の場合にのみ解釈されます。
The path segment defined in this section is an OPTIONAL extension of search path segments defined in [RFC7482]. This document defines an RDAP query parameter, "fieldSet", whose value is a non-empty string identifying a server-defined set of fields returned in place of the full response. The field sets supported by a server are usually described in out-of-band documents (e.g., RDAP profile) together with other features. Moreover, this document defines in Section 2.1 an in-band mechanism by means of which servers can provide clients with basic information about the supported field sets.
このセクションで定義されているパスセグメントは、[RFC7482]で定義されている検索パスセグメントのオプションの拡張です。このドキュメントは、RDAPクエリパラメータ「FieldSet」を定義します。その値は、フルレスポンスの代わりに返されるサーバー定義フィールドセットを識別する空でない文字列です。サーバによってサポートされているフィールドセットは、通常、他の機能と共に帯域外文書（例えばRDAPプロファイル）に記載されている。さらに、この文書はセクション2.1で定義されていますが、サーバーがサポートされているフィールドセットに関する基本情報をクライアントに提供できるインバンドメカニズムが定義されています。
The following is an example of an RDAP query including the "fieldSet" parameter:
以下は、 "fieldset"パラメータを含むRDAPクエリの例です。
https://example.com/rdap/domains?name=example*.com&fieldSet=afieldset
This solution can be implemented by RDAP providers with less effort than field selection and is easily requested by clients. The considerations that have led to this solution are described in more detail in Appendix A.
このソリューションは、フィールド選択よりも労力が少ないRDAPプロバイダによって実装でき、クライアントによって簡単に要求されます。この解決策につながった考慮事項は、付録Aでより詳細に説明されています。
According to most advanced principles in REST design, collectively known as "Hypermedia as the Engine of Application State" (HATEOAS) [HATEOAS], a client entering a REST application through an initial URI should use server-provided links to dynamically discover available actions and access the resources it needs. In this way, the client is not required to have prior knowledge of the service nor, consequently, to hard-code the URIs of different resources. This allows the server to make URI changes as the API evolves without breaking clients. Definitively, a REST service should be as self-descriptive as possible.
RESTデザインのほとんどの高度な原則によると、まとめて「HyperMedia」（Application Stateのエンジンとしてのハイパーメディア）[HATEOAS]、初期URIを介してRESTアプリケーションを入力するクライアントは、利用可能なアクションを動的に検出するためのサーバー提供のリンクを使用する必要があります。必要なリソースにアクセスしてください。このようにして、クライアントは、サービスに関する事前の知識も、その結果、さまざまなリソースのURIをハードコーディングする必要はありません。これにより、APIがクライアントを破ることなく進化するにつれて、サーバーはURIを変更することができます。間違いなく、RESTサービスはできるだけ自己説明的になるべきです。
Therefore, servers implementing the query parameter described in this specification SHOULD provide additional information in their responses about the available field sets. Such information is collected in a new JSON data structure named "subsetting_metadata" containing the following properties:
したがって、この仕様に記載されているクエリパラメータを実装するサーバは、利用可能なフィールドセットに関する応答に追加情報を提供する必要があります。そのような情報は、次のプロパティを含む「subsetting_metadata」という名前の新しいJSONデータ構造に収集されます。
"currentFieldSet": "String" (REQUIRED)
either the value of the "fieldSet" parameter as specified in the
query string, or the field set applied by default.
"availableFieldSets": "AvailableFieldSet[]" (OPTIONAL)
an array of objects, with each element describing an available
field set. The AvailableFieldSet object includes the following
members:
"name": "String" (REQUIRED)
the field set name.
"default": "Boolean" (REQUIRED)
indicator of whether the field set is applied by default. An
RDAP server MUST define only one default field set.
"description": "String" (OPTIONAL)
a human-readable description of the field set.
"links": "Link[]" (OPTIONAL)
an array of links as described in [RFC8288] containing the
query string that applies the field set (see Section 2.1.2).
Servers returning the "subsetting_metadata" section in their responses MUST include "subsetting" in the rdapConformance array.
「SUBSETTING_METADATA」を返すサーバーは、RDAPConformAnce配列の「サブセット化」を含める必要があります。
An RDAP server MAY use the "links" array of the "subsetting_metadata" element to provide ready-made references [RFC8288] to the available field sets (Figure 1). The target URI in each link is the reference to an alternative to the current view of results identified by the context URI.
RDAPサーバは、「サブセット_MetaData」要素の「リンク」アレイを使用して、既製の参照[RFC8288]を使用可能なフィールドセットに提供することができる（図1）。各リンク内のターゲットURIは、コンテキストURIによって識別された結果の現在のビューに対する代替案への参照である。
The "value", "rel", and "href" JSON values MUST be specified. All other JSON values are OPTIONAL.
"value"、 "rel"、 "href" json値を指定する必要があります。他のすべてのJSON値はオプションです。
{
"rdapConformance": [
"rdap_level_0",
"subsetting"
],
...
"subsetting_metadata": {
"currentFieldSet": "afieldset",
"availableFieldSets": [
{
"name": "anotherfieldset",
"description": "Contains some fields",
"default": false,
"links": [
{
"value": "https://example.com/rdap/domains?name=example*.com
&fieldSet=afieldset",
"rel": "alternate",
"href": "https://example.com/rdap/domains?name=example*.com
&fieldSet=anotherfieldset",
"title": "Result Subset Link",
"type": "application/rdap+json"
}
]
},
...
]
},
...
"domainSearchResults": [
...
]
}
Figure 1: Example of a "subsetting_metadata" Instance
図1： "subsetting_metadata"インスタンスの例
Representation of second-level objects within a field set produces additional considerations. Since the representation of the topmost returned objects will vary according to the field set in use, the response may contain no relationships (e.g., for an abbreviated field set) or may contain associated objects as in a normal RDAP query response. Each field set can indicate the format of the additional objects to be returned, in the same manner that the format of the topmost objects is controlled by the field set.
フィールドセット内の2レベルオブジェクトの表現は、追加の考慮事項を生成します。最上位の返されたオブジェクトの表現は、使用中に設定されたフィールドに従って変わるので、応答は（例えば、省略されたフィールドセットの場合）、または通常のRDAPクエリ応答のように関連するオブジェクトを含み得る。各フィールドセットは、最上位オブジェクトのフォーマットがフィールドセットによって制御されるのと同じ方法で、返される追加のオブジェクトのフォーマットを示すことができる。
This section defines three basic field sets that servers MAY implement to facilitate their interaction with clients:
このセクションでは、クライアントとの対話を容易にするためにサーバーが実装できる3つの基本フィールドセットを定義します。
"id": The server provides only the key field; "handle" for entities, and "ldhName" for domains and nameservers. If a returned domain or nameserver is an Internationalized Domain Name (IDN) [RFC5890], then the "unicodeName" field MUST additionally be included in the response. This field set could be used when the client wants to obtain a collection of object identifiers (Figure 2).
"ID"：サーバーはキーフィールドのみを提供します。エンティティの「ハンドル」、ドメインやネームサーバーの「LDHNAME」。返されたドメインまたはネームサーバーが国際化されたドメイン名（IDN）[RFC5890]である場合、「UnicodeName」フィールドはレスポンスに追加的に含める必要があります。このフィールドセットは、クライアントがオブジェクト識別子のコレクションを取得したいときに使用できます（図2）。
"brief": The field set contains the fields that can be included in a "short" response. This field set could be used when the client is asking for a subset of the full response that provides only basic knowledge of each object.
「概要」：フィールドセットには、「短い」応答に含めることができるフィールドが含まれています。このフィールドセットは、クライアントが各オブジェクトの基本的な知識のみを提供するフルレスポンスのサブセットを求めているときに使用できます。
"full": The field set contains all of the information the server can provide for a particular object.
"full"：フィールドセットには、サーバーが特定のオブジェクトに指定できるすべての情報が含まれています。
The "objectClassName" field is implicitly included in each of the above field sets. RDAP providers SHOULD include a "links" field indicating the "self" link relationship. RDAP providers MAY also add any property providing service information.
「objectClassName」フィールドは、上記の各フィールドセットに暗黙的に含まれています。RDAPプロバイダには、「自己」リンク関係を示す「リンク」フィールドを含める必要があります。RDAPプロバイダは、サービス情報を提供する任意のプロパティを追加することもできます。
Fields included in the "brief" and "full" field set responses MUST take into account the user's access and authorization levels.
「短い」フィールドセットのレスポンスに含まれるフィールドは、ユーザーのアクセスと許可レベルを考慮に入れなければなりません。
{
"rdapConformance": [
"rdap_level_0",
"subsetting"
],
...
"domainSearchResults": [
{
"objectClassName": "domain",
"ldhName": "example1.com",
"links": [
{
"value": "https://example.com/rdap/domain/example1.com",
"rel": "self",
"href": "https://example.com/rdap/domain/example1.com",
"type": "application/rdap+json"
}
]
},
{
"objectClassName": "domain",
"ldhName": "example2.com",
"links": [
{
"value": "https://example.com/rdap/domain/example2.com",
"rel": "self",
"href": "https://example.com/rdap/domain/example2.com",
"type": "application/rdap+json"
}
]
},
...
]
}
Figure 2: Example of RDAP Response According to the "id" Field Set
図2：「ID」フィールドセットによるRDAP応答の例
Each request including an empty or unsupported "fieldSet" value MUST produce an HTTP 400 (Bad Request) response code. Optionally, the response MAY include additional information regarding the supported field sets in the HTTP entity body (Figure 3).
空のまたはサポートされていない「フィールドセット」値を含む各要求は、HTTP 400（不良要求）応答コードを作成する必要があります。任意選択で、応答は、HTTPエンティティ本体内のサポートされているフィールドセットに関する追加の情報を含み得る（図3）。
{
"errorCode": 400,
"title": "Field set 'unknownfieldset' is not valid",
"description": [
"Supported field sets are: 'afieldset', 'anotherfieldset'."
]
}
}
Figure 3: Example of RDAP Error Response Due to an Invalid Field Set Included in the Request
図3：リクエストに含まれている無効なフィールドセットによるRDAPエラー応答の例
IANA has registered the following value in the "RDAP Extensions" registry:
IANAは "RDAP Extensions"レジストリに次の値を登録しました：
Extension identifier: subsetting Registry operator: Any Published specification: RFC 8982 Contact: IETF <iesg@ietf.org> Intended usage: This extension describes a best practice for partial response provisioning.
拡張識別子：サブセット化レジストリ演算子：任意の公開仕様：RFC 8982連絡先：IETF <iesg@ietf.org>意図された使用法：この拡張子は、部分的な応答プロビジョニングのためのベストプラクティスを説明しています。
A search query typically requires more server resources (such as memory, CPU cycles, and network bandwidth) when compared to a lookup query. This increases the risk of server resource exhaustion and subsequent denial of service. This risk can be mitigated by supporting the return of partial responses combined with other strategies (e.g., restricting search functionality, limiting the rate of search requests, and truncating and paging results).
検索クエリは通常、ルックアップクエリと比較した場合、より多くのサーバーリソース（メモリ、CPUサイクル、ネットワーク帯域幅など）を必要とします。これにより、サーバーリソースの枯渇とその後のサービス拒否のリスクが高まります。このリスクは、他の戦略と組み合わされた部分応答のリターンをサポートすることによって軽減することができます（例えば、検索機能の制限、検索要求の割合、および切り捨ておよびページング結果を制限する）。
Support for partial responses gives RDAP operators the ability to implement data access control policies based on the HTTP authentication mechanisms described in [RFC7481]. RDAP operators can vary the information returned in RDAP responses based on a client's access and authorization levels. For example:
部分的な応答のサポートは、RDAP演算子であり、[RFC7481]に記載されているHTTP認証メカニズムに基づいてデータアクセス制御ポリシーを実装する機能を提供します。RDAP演算子は、クライアントのアクセスと許可レベルに基づいてRDAP応答で返された情報を変更できます。例えば：
* the list of fields for each set can differ based on the client's access and authorization levels;
* 各セットのフィールドのリストは、クライアントのアクセスと許可レベルに基づいて異なります。
* the set of available field sets could be restricted based on the client's access and authorization levels.
* 利用可能なフィールドセットのセットは、クライアントのアクセスと許可レベルに基づいて制限される可能性があります。
Servers can also define different result limits according to the available field sets, so a more flexible truncation strategy can be implemented. The new query parameter presented in this document provides RDAP operators with a way to implement a server that reduces inefficiency risks.
サーバーは、使用可能なフィールドセットに従って異なる結果制限を定義することもできますので、より柔軟な切り捨て方式を実装できます。このドキュメントで提示されている新しいクエリパラメータは、非効率的なリスクを軽減するサーバーを実装する方法を備えたRDAP演算子を提供します。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC2119] BRADNER、S、「RFCSで使用するためのキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<https：//www.rfc-editor.org/info/RFC2119>。
[RFC5890] Klensin, J., "Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework", RFC 5890, DOI 10.17487/RFC5890, August 2010, <https://www.rfc-editor.org/info/rfc5890>.
[RFC5890] Klensin、J.、「アプリケーションの国際化ドメイン名（IDNA）：定義とドキュメントフレームワーク、RFC 5890、DOI 10.17487 / RFC5890、2010年8月、<https：//www.rfc-editor.org/info/RFC5890>。
[RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing", RFC 7230, DOI 10.17487/RFC7230, June 2014, <https://www.rfc-editor.org/info/rfc7230>.
[RFC7230]フィールド、R.、ED。J.Reschke、ED。、「Hypertext Transfer Protocol（HTTP / 1.1）：メッセージ構文とルーティング」、RFC 7230、DOI 10.17487 / RFC7230、2014年6月、<https：//www.rfc-editor.org/info/RFC7230>。
[RFC7480] Newton, A., Ellacott, B., and N. Kong, "HTTP Usage in the Registration Data Access Protocol (RDAP)", RFC 7480, DOI 10.17487/RFC7480, March 2015, <https://www.rfc-editor.org/info/rfc7480>.
[RFC7480] Newton、A.、Ellacott、B.、N.Kong、「登録データアクセスプロトコル（RDAP）」、RFC 7480、DOI 10.17487 / RFC7480、2015年3月、<https：// www。rfc-editor.org/info/rfc7480>。
[RFC7481] Hollenbeck, S. and N. Kong, "Security Services for the Registration Data Access Protocol (RDAP)", RFC 7481, DOI 10.17487/RFC7481, March 2015, <https://www.rfc-editor.org/info/rfc7481>.
[RFC7481] Hollenbeck、S.およびN.Kong、「登録データアクセスプロトコルのためのセキュリティサービス（RDAP）」、RFC 7481、DOI 10.17487 / RFC7481、2015年3月、<https：//www.rfc-editor.org/情報/ RFC7481>。
[RFC7482] Newton, A. and S. Hollenbeck, "Registration Data Access Protocol (RDAP) Query Format", RFC 7482, DOI 10.17487/RFC7482, March 2015, <https://www.rfc-editor.org/info/rfc7482>.
[RFC7482] Newton、A.およびS.Hollenbeck、「登録データアクセスプロトコル（RDAP）クエリフォーマット」、RFC 7482、DOI 10.17487 / RFC7482、2015年3月、<https://www.rfc-editor.org/info/RFC7482>。
[RFC7483] Newton, A. and S. Hollenbeck, "JSON Responses for the Registration Data Access Protocol (RDAP)", RFC 7483, DOI 10.17487/RFC7483, March 2015, <https://www.rfc-editor.org/info/rfc7483>.
[RFC7483] Newton、A.およびS.Hollenbeck、「登録データアクセスプロトコル（RDAP）へのJSON応答」、RFC 7483、DOI 10.17487 / RFC7483、2015年3月、<https：//www.rfc-editor.org/情報/ RFC7483>。
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8174] Leiba、B、「RFC 2119キーワードの大文字の曖昧さ」、BCP 14、RFC 8174、DOI 10.17487 / RFC8174、2017年5月、<https：//www.rfc-editor.org/info/RFC8174>。
[RFC8288] Nottingham, M., "Web Linking", RFC 8288, DOI 10.17487/RFC8288, October 2017, <https://www.rfc-editor.org/info/rfc8288>.
[RFC8288]ノッティンガム、M。、「Webリンク」、RFC 8288、DOI 10.17487 / RFC8288、2017年10月、<https：//www.rfc-editor.org/info/rfc8288>。
[CQL] Whitaker, G., "Catnap Query Language Reference", commit d4f402c, September 2017, <https://github.com/gregwhitaker/catnap/wiki/Catnap-Query-Language-Reference>.
[CQL] Whitaker、G.、「Catnap Query Language Reference」、2017年9月、<https：//github.com/gregwhitaker/catnap/wiki/catnap-query-language-reference>。
[HATEOAS] Jedrzejewski, B., "HATEOAS - a simple explanation", February 2018, <https://www.e4developer.com/2018/02/16/ hateoas-simple-explanation/>.
[HATEOAS] Jedrzejewski、B.、「Hateoas - 簡単な説明」、2018年2月、<https：//www.e4developer.com/2018/02/16/ Hateoas-Simple-Compution />。
[REST] Fielding, R., "Architectural Styles and the Design of Network-based Software Architectures", Ph.D. Dissertation, University of California, Irvine, 2000, <https://www.ics.uci.edu/~fielding/pubs/dissertation/ fielding_dissertation.pdf>.
[REST]フィールド、R.、「アーキテクチャスタイルとネットワークベースのソフトウェアアーキテクチャの設計」、Ph.D。<https://www.ics.uci.edu/~fielding/pubs/dissertation/ fielding_dissertation/ fielding_dissertation/ fielding_dissertation/ fielding_dissertation / fielding_dissertation / fielding_dissertation / fielding_dissertation.pdf>。
Looking at the implementation experiences of partial responses offered by data providers on the web, two approaches are observed:
データプロバイダが提供する部分応答の実装経験を見ると、2つのアプローチが観察されます。
* the client explicitly describes the data fields to be returned;
* クライアントは、返されるデータフィールドを明示的に説明しています。
* the client describes a name identifying a server-defined set of data fields.
* クライアントは、サーバー定義のデータフィールドのセットを識別する名前を説明しています。
The former is more flexible than the latter because clients can specify all the data fields they need. However, it has some drawbacks:
クライアントは必要なすべてのデータフィールドを指定できるため、前者は後者よりも柔軟です。しかし、それはいくつかの欠点を持っています：
* Fields have to be declared according to a given syntax. This is a simple task when the data structure of the object is flat, but it is much more difficult when the object has a tree structure like that of a JSON object. The presence of arrays and deep nested objects complicate both the syntax definition of the query and, consequently, the processing required on the server side.
* 与えられた構文に従ってフィールドを宣言する必要があります。これは、オブジェクトのデータ構造がフラットである場合の単純なタスクですが、オブジェクトがJSONオブジェクトのツリー構造を持つときははるかに困難です。アレイとネストされたオブジェクトの存在は、クエリの構文定義とその結果、サーバー側で必要な処理の両方を複雑にします。
* Clients need to recognize the returned data structure to avoid cases when the requested fields are invalid.
* 要求されたフィールドが無効な場合は、クライアントが返されたデータ構造を認識する必要があります。
* The request of some fields might not match the client's access and authorization levels. Clients might request unauthorized fields, and servers have to define a strategy for responding such as always returning an error response or returning a response that ignores the unauthorized fields.
* 一部のフィールドの要求は、クライアントのアクセスと許可レベルと一致しない可能性があります。クライアントは不正なフィールドを要求し、サーバーは常にエラー応答を返却したり、不正なフィールドを無視した応答を返すなど、応答するための戦略を定義する必要があります。
In addition to those listed above, RDAP responses raise some specific issues:
上記のものに加えて、RDAP応答は特定の問題を引き上げます。
* Relevant entity object information is included in a jCard, but such information cannot be easily selected because it is split into the items of a jagged array.
* 関連エンティティオブジェクト情報はJCARDに含まれていますが、そのような情報はギザギザ配列の項目に分割されているため、簡単に選択できません。
* RDAP responses contain some properties providing service information (e.g., rdapConformance, links, notices, remarks, etc.), which are not normally selected but are just as important. They could be returned anyway but, in this case, the server would provide unrequested data.
* RDAP応答には、サービス情報（例えば、RDAPコンフォート、リンク、通知、備考など）を提供するプロパティがいくつか含まれています。これは、通常は選択されていませんが、重要なだけです。とにかく返される可能性がありますが、この場合、サーバーは不明確なデータを提供します。
It is possible to address these issues. For example, the Catnap Query Language [CQL] is a comprehensive expression language that can be used to customize the JSON response of a RESTful web service. Application of CQL to RDAP responses would explicitly identify the output fields that would be acceptable when a few fields are requested but it would become very complicated when processing a larger number of fields. In the following, two CQL expressions for a domain search query are shown (Figure 4). In the first, only objectClassName and ldhName are requested. In the second, the fields of a possible WHOIS-like response are listed.
これらの問題に対処することは可能です。たとえば、CATNAPクエリ言語[CQL]は、RESTful WebサービスのJSON応答をカスタマイズするために使用できる包括的な表現言語です。CQLへのCQLのアプリケーションへの応用は、いくつかのフィールドが要求されたときに受け入れられる出力フィールドを明示的に識別しますが、より多くのフィールドを処理するときに非常に複雑になるでしょう。以下では、ドメイン検索クエリの2つのCQL式が示されています（図4）。最初に、ObjectClassNameとLDHNameのみが要求されます。第二に、可能なwhoisのような応答のフィールドがリストされています。
https://example.com/rdap/domains?name=example*.com
&fields=domainSearchResults(objectClassName,ldhName)
https://example.com/rdap/domains?name=example*.com
&fields=domainSearchResults(objectClassName,ldhName,
unicodeName,
status,
events(eventAction,eventDate),
entities(objectClassName,handle,roles),
nameservers(objectClassName,ldhName))
Figure 4: Examples of CQL Expressions for a Domain Search Query
図4：ドメイン検索クエリのCQL式の例
The field set approach seems to facilitate RDAP interoperability. Servers can define basic field sets that, if known to clients, can increase the probability of obtaining a valid response. The usage of field sets makes the query string less complex. Moreover, the definition of predefined sets of fields makes it easier to establish result limits.
フィールドセットアプローチは、RDAPの相互運用性を促進するようです。サーバーは、クライアントに既知であれば、有効な応答を得る可能性を高めることができる基本フィールドセットを定義できます。フィールドセットの使用法は、クエリ文字列がより少ない複雑になります。さらに、定義済みフィールドセットの定義は結果制限を確立するのを容易にします。
Finally, considering that there is no real need for RDAP users to have the maximum flexibility in defining all the possible sets of logically connected fields (e.g., users interested in domains usually need to know the status, the creation date, and the expiry date of each domain), the field set approach is preferred.
最後に、RDAPユーザーが一般的に接続されたフィールドのすべての可能なセットを定義する際に最大の柔軟性を持つことが本当の必要性がないことを考えると（たとえば、ドメインに関心のあるユーザーは通常、ステータス、作成日、および有効期限を知る必要があります。各ドメイン）、フィールドセットアプローチが好ましい。
Acknowledgements
謝辞
The authors would like to acknowledge Scott Hollenbeck, Tom Harrison, Karl Heinz Wolf, Jasdip Singh, Patrick Mevzek, Benjamin Kaduk, Roman Danyliw, Murray Kucherawy, Erik Kline, and Robert Wilton for their contribution to this document.
著者らは、Scott Hollenbeck、Tom Harrison、Karl Heinz Wolf、Jasdip Singh、Patrick Mevzek、Roman Danyyliw、Murray Kucherawy、Erik Kline、およびRobert Wiltonがこの文書への貢献のためにRobert Wiltonを承認したいと思います。
Authors' Addresses
著者の住所
Mario Loffredo IIT-CNR/Registro.it Via Moruzzi,1 56124 Pisa Italy
Mario Loffredo Iit-CNR / Registro.IT Moruzzi、1 56124 Pisa Italy
Email: mario.loffredo@iit.cnr.it
URI: https://www.iit.cnr.it
Maurizio Martinelli IIT-CNR/Registro.it Via Moruzzi,1 56124 Pisa Italy
Maurizio Martinelli IIT-CNR / Registro.IT Moruzzi、1 56124 Pisa Italy
Email: maurizio.martinelli@iit.cnr.it
URI: https://www.iit.cnr.it