[要約] RFC 8977は、RDAP(Registration Data Access Protocol)の結果のソートとページングのためのクエリパラメータを定義します。この文書の目的は、RDAP応答の検索結果をより効率的に整理・アクセスする方法を提供することです。主に、大量の登録データを扱う際に役立ちます。
Internet Engineering Task Force (IETF) M. Loffredo
Request for Comments: 8977 M. Martinelli
Category: Standards Track IIT-CNR/Registro.it
ISSN: 2070-1721 S. Hollenbeck
Verisign Labs
January 2021
Registration Data Access Protocol (RDAP) Query Parameters for Result Sorting and Paging
結果ソートとページングの登録データアクセスプロトコル（RDAP）クエリパラメータ
Abstract
概要
The Registration Data Access Protocol (RDAP) does not include core functionality for clients to provide sorting and paging parameters for control of large result sets. This omission can lead to unpredictable server processing of queries and client processing of responses. This unpredictability can be greatly reduced if clients can provide servers with their preferences for managing large responses. This document describes RDAP query extensions that allow clients to specify their preferences for sorting and paging result sets.
登録データアクセスプロトコル（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/rfc8977.
この文書の現在のステータス、任意のエラータ、およびフィードバックを提供する方法は、https://www.rfc-editor.org/info/rfc8977で入手できます。
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 Query Parameter Specification
2.1. Sorting and Paging Metadata
2.1.1. RDAP Conformance
2.2. "count" Parameter
2.3. "sort" Parameter
2.3.1. Sorting Properties Declaration
2.3.2. Representing Sorting Links
2.4. "cursor" Parameter
2.4.1. Representing Paging Links
3. Negative Answers
4. Implementation Considerations
5. IANA Considerations
6. Security Considerations
7. References
7.1. Normative References
7.2. Informative References
Appendix A. JSONPath Operators
Appendix B. Approaches to Result Pagination
B.1. Specific Issues Raised by RDAP
Appendix C. Implementation Notes
C.1. Sorting
C.2. Counting
C.3. Paging
Acknowledgements
Authors' Addresses
The availability of functionality for result sorting and paging provides benefits to both clients and servers in the implementation of RESTful services [REST]. These benefits include:
結果ソートとページングの機能の可用性は、RESTfulサービスの実装でクライアントとサーバーの両方に利点を提供します[REST]。これらの利点は次のとおりです。
* reducing the server response bandwidth requirements
* サーバーレスポンス帯域幅の要件を削減します
* improving server response time
* サーバーの応答時間の向上
* improving query precision and, consequently, obtaining more relevant results
* クエリの精度を向上させると、関連する結果を得ることができます。
* decreasing server query processing load
* サーバークエリ処理の負荷を減らす
* reducing client response processing time
* クライアントの応答処理時間を短縮します
Approaches to implementing features for result sorting and paging can be grouped into two main categories:
結果ソートとページングの機能を実装するためのアプローチは、2つの主要なカテゴリにグループ化できます。
1. Sorting and paging are implemented through the introduction of additional parameters in the query string (e.g., the Open Data Protocol (ODATA) [ODATA-PART1]).
1. ソートとページングは、クエリ文字列（例えば、オープンデータプロトコル（ODATA-PART1]）内の追加のパラメータの導入を通じて実装されます。
2. Information related to the number of results and the specific portion of the result set to be returned, in addition to a set of ready-made links for the result set scrolling, are inserted in the HTTP header of the request/response [RFC7231].
2. 結果セットスクロールの既定のリンクのセットに加えて、結果セットの結果数と結果セットの特定部分に関連する情報は、要求/応答のHTTPヘッダーに挿入されます[RFC7231]。
However, there are some drawbacks associated with the use of the HTTP header. First, the header properties cannot be set directly from a web browser. Moreover, in an HTTP session, the information on the status (i.e., the session identifier) is usually inserted in the header or a cookie, while the information on the resource identification or the search type is included in the query string. Finally, providing custom information through HTTP headers assumes the client has prior knowledge of the server implementation, which is widely considered a Representational State Transfer (REST) design anti-pattern. As a result, this document describes a specification based on the use of query parameters.
ただし、HTTPヘッダーの使用に関連した欠点がいくつかあります。まず、ヘッダーのプロパティをWebブラウザから直接設定することはできません。また、HTTPセッションでは、通常、ステータスに関する情報（すなわちセッション識別子）がヘッダまたはクッキーに挿入され、リソース識別または検索タイプの情報はクエリ文字列に含まれる。最後に、HTTPヘッダーを介してカスタム情報を提供すると、クライアントはサーバー実装に関する事前の知識を持っています。これは、表現状態転送（REST）デザインアンチパターンと広く考えられています。その結果、このドキュメントでは、クエリパラメータの使用に基づく仕様について説明します。
Currently, RDAP [RFC7482] defines two query types:
現在、RDAP [RFC7482]は2つのクエリタイプを定義します。
lookup: the server returns only one object
Lookup：サーバーは1つのオブジェクトだけを返します
search: the server returns a collection of objects
検索：サーバーはオブジェクトのコレクションを返します
While the lookup query does not raise issues regarding response size management, the search query can potentially generate a large result set that is often truncated according to server limits. Besides, it is not possible to obtain the total number of objects found that might be returned in a search query response [RFC7483]. Lastly, there is no way to specify sort criteria to return the most relevant objects at the beginning of the result set. Therefore, the client might traverse the whole result set to find the relevant objects or, due to truncation, might not find them at all.
ルックアップクエリはレスポンスサイズ管理に関して問題を発生しませんが、検索クエリはサーバーの制限に従って切り捨てられることが多い大きな結果セットを生成する可能性があります。その上、検索クエリ応答で返される可能性があるオブジェクトの総数を取得することはできません[RFC7483]。最後に、結果セットの先頭にある最も関連性のあるオブジェクトを返すためのソート基準を指定する方法はありません。したがって、クライアントは結果セット全体を横断して関連オブジェクトを見つけるか、切り捨てのためにそれらを見つけることができないかもしれません。
The specification described in this document extends RDAP query capabilities to enable result sorting and paging by adding new query parameters that can be applied to RDAP search path segments. The service is implemented using the Hypertext Transfer Protocol (HTTP) [RFC7230] and the conventions described in [RFC7480].
この文書に記載されている仕様は、RDAP検索パスセグメントに適用できる新しいクエリパラメータを追加することによって、RDAPクエリ機能を拡張し、結果ソートとページングを有効にします。サービスは、ハイパーテキスト転送プロトコル（HTTP）[RFC7230]と[RFC7480]に記載されている規則を使用して実装されています。
The implementation of the new parameters is technically feasible, as operators for counting, sorting, and paging rows are currently supported by the major relational database management systems.
カウント、ソート、およびページング行の演算子が現在主要なリレーショナルデータベース管理システムによってサポートされているため、新しいパラメータの実装は技術的に実行可能です。
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 new query parameters are OPTIONAL extensions of path segments defined in [RFC7482]. They are as follows:
新しいクエリパラメータは、[RFC7482]で定義されているパスセグメントのオプションの拡張機能です。それらは次のとおりです。
"count": a boolean value that allows a client to request the return of the total number of objects found
"count"：クライアントが見つかったオブジェクトの総数の返却を要求できるブール値
"sort": a string value that allows a client to request a specific sort order for the result set
"sort"：クライアントが結果セットの特定のソート順を要求できるようにする文字列値
"cursor": a string value representing a pointer to a specific fixed-size portion of the result set
"CURSOR"：結果セットの特定の固定サイズ部分へのポインタを表す文字列値
Augmented Backus-Naur Form (ABNF) [RFC5234] is used in the following sections to describe the formal syntax of these new parameters.
次のセクションでは、次のセクションでは、これらの新しいパラメータの正式な構文を説明するために、拡張Backus-Naur Form（ABNF）[RFC5234]が使用されています。
According to most advanced principles in REST design, collectively known as HATEOAS (Hypermedia as the Engine of Application State) [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 neither 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デザインのほとんどの先進的な原則によると、まとめてHateoas（アプリケーション状態のエンジンとしてハイパーメディア）[HATEOAS]では、最初のURIを介してRESTアプリケーションを入力するクライアントがサーバー提供のリンクを使用して利用可能なアクションを動的に検出してアクセスする必要があります。リソースが必要です。このようにして、クライアントは、サービスに関する事前の知識も、その結果、さまざまなリソースのURIをハードコードする必要もありません。これにより、APIがクライアントを破ることなく進化するにつれて、サーバーはURIを変更することができます。間違いなく、RESTサービスはできるだけ自己説明的になるべきです。
Therefore, servers implementing the query parameters described in this specification SHOULD provide additional information in their responses about both the available sorting criteria and possible pagination. Such information is collected in two OPTIONAL response elements named "sorting_metadata" and "paging_metadata".
したがって、この仕様に記載されているクエリパラメータを実装するサーバは、利用可能なソート基準と可能なページ区切りの両方についてのそれらの応答において追加の情報を提供するべきである。そのような情報は、「SORTING_METADATA」と「PAGING_METADATA」という名前の2つのオプションの応答要素に収集されます。
The "sorting_metadata" element contains the following properties:
"sorting_metadata"要素には、次のプロパティが含まれています。
"currentSort": "String" (OPTIONAL)
Either the value of the "sort" parameter as specified in the query
string or the sort applied by default, if any.
"availableSorts": "AvailableSort[]" (OPTIONAL)
An array of objects, with each element describing an available
sort criterion. The AvailableSort object includes the following
members:
"property": "String" (REQUIRED)
The name that can be used by the client to request the sort
criterion.
"default": "Boolean" (REQUIRED)
Indicator of whether the sort criterion is applied by default.
An RDAP server MUST define only one default sorting property
for each object class.
"jsonPath": "String" (OPTIONAL)
The JSONPath expression of the RDAP field corresponding to the
property.
"links": "Link[]" (OPTIONAL)
An array of links as described in [RFC8288] containing the
query string that applies the sort criterion.
At least one of the "currentSort" and "availableSorts" properties MUST be present.
"CurrentSort"と "AvailableAbsorts"のプロパティの少なくとも1つが存在している必要があります。
The "paging_metadata" element contains the following fields:
"paging_metadata"要素には、次のフィールドが含まれています。
"totalCount": "Numeric" (OPTIONAL)
A numeric value representing the total number of objects found.
It MUST be provided if and only if the query string contains the
"count" parameter.
"pageSize": "Numeric" (OPTIONAL)
A numeric value representing the number of objects that should
have been returned in the current page. It MUST be provided if
and only if the total number of objects exceeds the page size.
This property is redundant for RDAP clients because the page size
can be derived from the length of the search results array, but it
can be helpful if the end user interacts with the server through a
web browser.
"pageNumber": "Numeric" (OPTIONAL)
A numeric value representing the number of the current page in the
result set. It MUST be provided if and only if the total number
of objects found exceeds the page size.
"links": "Link[]" (OPTIONAL)
An array of links as described in [RFC8288] containing the
reference to the next page. In this specification, only forward
pagination is described because it is all that is necessary to
traverse the result set.
Servers returning the "paging_metadata" element in their response MUST include the string literal "paging" in the rdapConformance array. Servers returning the "sorting_metadata" element MUST include the string literal "sorting".
応答に "paging_metadata"要素を返すサーバには、RDAPConformAnce配列の文字列リテラル "ページング"を含める必要があります。"SORTING_METADATA"要素を返すサーバーには、文字列リテラル "ソート"を含める必要があります。
Currently, RDAP does not allow a client to determine the total number of results in a query response when the result set is truncated. This is inefficient because the user cannot determine if the result set is complete.
現在、RDAPは、結果セットが切り捨てられたときにクエリ応答の合計数の合計数をクライアントに決定することを許可しません。ユーザーが結果セットが完了したかどうかを判断できないため、これは非効率的です。
The "count" parameter provides additional functionality that allows a client to request information from the server that specifies the total number of objects matching the search pattern.
「count」パラメータは、検索パターンと一致するオブジェクトの総数を指定するサーバーからクライアントが情報を要求できる追加の機能を提供します。
The following is an example of an RDAP query including the "count" parameter:
以下は、 "count"パラメータを含むRDAPクエリの例です。
https://example.com/rdap/domains?name=example*.com&count=true
The ABNF syntax is the following:
ABNF構文は次のとおりです。
count = "count=" ( trueValue / falseValue )
trueValue = ("true" / "yes" / "1")
falseValue = ("false" / "no" / "0")
A trueValue means that the server MUST provide the total number of objects in the "totalCount" field of the "paging_metadata" element (Figure 1). A falseValue means that the server MUST NOT provide this number.
TrueValueは、サーバーが "paging_metadata"要素の "TotalCount"フィールドにあるオブジェクトの総数を提供する必要があることを意味します（図1）。PalseValueは、サーバーがこの番号を指定してはいけないことを意味します。
{
"rdapConformance": [
"rdap_level_0",
"paging"
],
...
"paging_metadata": {
"totalCount": 43
},
"domainSearchResults": [
...
]
}
Figure 1: Example of RDAP Response with "paging_metadata" Element Containing the "totalCount" Field
図1： "totalcount"フィールドを含む "paging_metadata"要素を使用したRDAP応答の例
RDAP does not provide any capability to specify the result set sort criteria. A server could implement a default sorting scheme according to the object class, but this feature is not mandatory and might not meet user requirements. Sorting can be addressed by the client, but this solution is rather inefficient. Sorting features provided by the RDAP server could help avoid truncation of relevant results.
RDAPは、結果セットのソート基準を指定する機能を提供しません。サーバーはオブジェクトクラスに従ってデフォルトのソート方式を実装できますが、この機能は必須ではなく、ユーザーの要件を満たしていない可能性があります。ソートはクライアントによってアドレス指定できますが、このソリューションはかなり効率的です。RDAPサーバーによって提供されたソート機能は、関連する結果の切り捨てを回避するのに役立ちます。
The "sort" parameter allows the client to ask the server to sort the results according to the values of one or more properties and according to the sort direction of each property. The ABNF syntax is the following:
「SORT」パラメータを使用すると、クライアントは1つ以上のプロパティの値と各プロパティのソート方向に応じて結果をソートするようにサーバに要求することができます。ABNF構文は次のとおりです。
sort = "sort=" sortItem *( "," sortItem )
sortItem = property-ref [":" ( "a" / "d" ) ]
property-ref = ALPHA *( ALPHA / DIGIT / "_" )
"a" means that an ascending sort MUST be applied; "d" means that a descending sort MUST be applied. If the sort direction is absent, an ascending sort MUST be applied.
「a」は、昇順の種類を適用する必要があることを意味します。「d」とは、降順のソートを適用する必要があることを意味します。ソート方向が存在しない場合は、昇順を適用する必要があります。
The following are examples of RDAP queries that include the "sort" parameter:
以下は、 "sort"パラメータを含むRDAPクエリの例です。
https://example.com/rdap/domains?name=example*.com&sort=name
https://example.com/rdap/
domains?name=example*.com&sort=registrationDate:d
https://example.com/rdap/
domains?name=example*.com&sort=lockedDate,name
Except for sorting IP addresses and values denoting dates and times, servers MUST implement sorting according to the JSON value type of the RDAP field the sorting property refers to. That is, JSON strings MUST be sorted lexicographically, and JSON numbers MUST be sorted numerically. Values denoting dates and times MUST be sorted in chronological order. If IP addresses are represented as JSON strings, they MUST be sorted based on their numeric conversion.
日付と時間を示すIPアドレスと値のソートを除いて、サーバーはRDAPフィールドのJSON値の種類に従ってソートを実装する必要があります。つまり、JSON文字列は辞書的にソートする必要があり、JSON数は数値的にソートされている必要があります。日付と時間を示す値は、時系列でソートする必要があります。IPアドレスがJSON文字列として表されている場合は、それらの数値変換に基づいてソートする必要があります。
The conversion of an IPv4 address to a number is possible since each dotted format IPv4 address is a representation of a number written in a 256-based manner; for example, 192.168.0.1 means 1*256^0 + 0*256^1 + 168*256^2 + 192*256^3 = 3232235521. Similarly, an IPv6 address can be converted into a number by applying the base 65536. Therefore, the numerical representation of the IPv6 address 2001:0db8:85a3:0:0:8a2e:0370:7334 is 42540766452641154071740215577757643572. Built-in functions and libraries for converting IP addresses into numbers are available in most known programming languages and relational database management systems.
各点付きフォーマットIPv4アドレスは、256ベースの方法で書かれた数字の表現であるため、IPv4アドレスの数値への変換が可能です。例えば、192.168.0.1は1 * 256 ^ 0 0 * 256 ^ 1 168 * 256 ^ 2 192 * 256 ^ 3 = 3232235521を意味します。同様に、IPv6アドレスは、基部65536を適用することによって数値に変換できます。IPv6アドレス2001の数値表現2001：0：0：8A2E：0370：733477764357215557776435721555777643572155577764357215577776435721555777643572155577764357215577776435721555777643572155777764357215757776435772。
If the "sort" parameter presents an allowed sorting property, it MUST be provided in the "currentSort" field of the "sorting_metadata" element.
「SORT」パラメータが許可されたソートプロパティを提示する場合、それは「SORTING_METADATA」要素の「CurrentSort」フィールドに提供されなければなりません。
In the "sort" parameter ABNF syntax, the element named "property-ref" represents a reference to a property of an RDAP object. Such a reference could be expressed by using a JSONPath expression (named "jsonpath" in the following).
「ソート」パラメータABNF構文では、 "property-ref"という名前の要素はRDAPオブジェクトのプロパティへの参照を表します。そのような参照は、JSONPath式（次のように "JSONPATH"という名前）を使用して表現できます。
JSONPath is a syntax, originally based on the XML XPath notation [W3C.CR-xpath-31-20170321], which represents a path to select an element (or a set of elements) in a JSON document [RFC8259]. For example, the jsonpath to select the value of the ASCII name inside an RDAP domain lookup response is "$.ldhName", where $ identifies the root of the document object model (DOM). Another way to select a value inside a JSON document is the JSON Pointer [RFC6901].
JSONPathは、もともとJSON文書[RFC8259]で要素（または要素のセット）を選択するためのパスを表すパスを表すパスを表します。たとえば、RDAPドメインルックアップ応答内のASCII名の値を選択するJSONPATHは "$ .LDHNAME"です。ここで、$はDocument Object Model（DOM）のルートを識別します。JSON文書内の値を選択するもう1つの方法は、JSONポインタ[RFC6901]です。
While JSONPath and JSON Pointer are both commonly adopted notations to select any value inside JSON data, neither is particularly concise and easy to use (e.g., "$.domainSearchResults[*].events[?(@.eventActi on='registration')].eventDate" is the jsonpath of the registration date in an RDAP domain search response).
JSONPathとJSONポインタは両方ともJSONデータ内の任意の値を選択するために一般的に採用されていますが、どちらも特に簡潔で使いやすいです（例： "$ .domainsearchResults [*]。イベント[？（@ eventaction = '登録）] .eventdate "は、RDAPドメイン検索応答の登録日のJSONPATHです）。
Therefore, this specification defines the "property-ref" element in terms of names identifying RDAP properties. However, not all the RDAP properties are suitable to be used in sort criteria. These properties include:
したがって、この仕様は、RDAPプロパティを識別する名前に関して「property-ref」要素を定義します。ただし、すべてのRDAPプロパティがソート基準で使用されるのに適しているわけではありません。これらのプロパティは次のとおりです。
* properties providing service information (e.g., links, notices, and remarks)
* サービス情報提供のプロパティ（例えば、リンク、通知、および発言）
* multivalued properties (e.g., status, roles, and variants)
* 多値的なプロパティ（例えば、ステータス、役割、および変形）
* properties representing relationships to other objects (e.g., entities)
* 他のオブジェクトへの関係を表すプロパティ（例えば、エンティティ）
On the contrary, properties expressed as values of other properties (e.g., registration date) could be used in such a context.
それどころか、他の特性の値（例えば、登録日）として表される特性をそのような文脈で使用することができる。
A list of properties an RDAP server MAY implement is defined. The properties are divided into two groups: object-common properties and object-specific properties.
RDAPサーバーが実装できるプロパティのリストが定義されています。プロパティは、Object-Common Propertiesとオブジェクト固有のプロパティの2つのグループに分けられます。
* Object-common properties. Object-common properties are derived from merging the "eventAction" and the "eventDate" properties. The following values of the "sort" parameter are defined:
* オブジェクト共通プロパティObject-Common Propertiesは、 "EventAction"と "EventDate"プロパティをマージすることから派生します。次の「sort」パラメータの値が定義されています。
- registrationDate
- 登録日
- reregistrationDate
- 登録日
- lastChangedDate
- かんたん
- expirationDate
- 賞味期限
- deletionDate
- 削除された
- reinstantiationDate
- 復活化
- transferDate
- 転送デート
- lockedDate
- ロック型
- unlockedDate
- Unlockeddate.
* Object-specific properties. Note that some of these properties are also defined as query path segments. These properties include:
* オブジェクト固有のプロパティこれらのプロパティのいくつかはクエリパスセグメントとしても定義されていることに注意してください。これらのプロパティは次のとおりです。
- Domain: name
- ドメイン：名前
- Nameserver: name, ipv4, ipv6
- NameServer：Name、IPv4、IPv6
- Entity: fn, handle, org, email, voice, country, cc, city
- エンティティ：FN、ハンドル、組織、電子メール、声、国、CC、都市
The correspondence between these sorting properties and the RDAP object classes is shown in Table 1. Some of the sorting properties defined for the RDAP entity class are related to jCard elements [RFC7095], but because jCard is the JSON format for vCard, the corresponding definitions are included in the vCard specification [RFC6350].
これらのソートプロパティとRDAPオブジェクトクラスの間の対応は表1に示されています.RDAPエンティティクラスに定義されているソートプロパティの一部は、JCARD要素[RFC7095]に関連していますが、JCARDはvCardのJSON形式、対応する定義です。VCARD仕様[RFC6350]に含まれています。
An RDAP server MUST NOT use the defined sorting properties with a meaning other than that described in Table 1.
RDAPサーバーは、表1に記載されているもの以外の意味で定義済みソートプロパティを使用してはいけません。
+============+============+=================+======+=======+======+
| Object | Sorting | RDAP property | RFC | RFC | RFC |
| class | property | | 7483 | 6350 | 8605 |
+============+============+=================+======+=======+======+
| Searchable | Common | eventAction | 4.5 | | |
| objects | properties | values suffixed | | | |
| | | by "Date" | | | |
+------------+------------+-----------------+------+-------+------+
| Domain | name | unicodeName/ | 5.3 | | |
| | | ldhName | | | |
+------------+------------+-----------------+------+-------+------+
| Nameserver | name | unicodeName/ | 5.2 | | |
| | | ldhName | | | |
+------------+------------+-----------------+------+-------+------+
| | ipv4 | v4 ipAddress | 5.2 | | |
+------------+------------+-----------------+------+-------+------+
| | ipv6 | v6 ipAddress | 5.2 | | |
+------------+------------+-----------------+------+-------+------+
| Entity | handle | handle | 5.1 | | |
+------------+------------+-----------------+------+-------+------+
| | fn | jCard fn | 5.1 | 6.2.1 | |
+------------+------------+-----------------+------+-------+------+
| | org | jCard org | 5.1 | 6.6.4 | |
+------------+------------+-----------------+------+-------+------+
| | voice | jCard tel with | 5.1 | 6.4.1 | |
| | | type="voice" | | | |
+------------+------------+-----------------+------+-------+------+
| | email | jCard email | 5.1 | 6.4.2 | |
+------------+------------+-----------------+------+-------+------+
| | country | country name in | 5.1 | 6.3.1 | |
| | | jCard adr | | | |
+------------+------------+-----------------+------+-------+------+
| | cc | country code in | 5.1 | | 3.1 |
| | | jCard adr | | | |
+------------+------------+-----------------+------+-------+------+
| | city | locality in | 5.1 | 6.3.1 | |
| | | jCard adr | | | |
+------------+------------+-----------------+------+-------+------+
Table 1: Definitions of Sorting Properties
表1：ソートプロパティの定義
Regarding the definitions in Table 1, some further considerations are needed to disambiguate some cases:
表1の定義に関しては、いくつかのケースを曖昧させるためにいくつかのさらなる考慮事項が必要である。
* Since the response to a search on either domains or nameservers might include both A-labels and U-labels [RFC5890] in general, a consistent sorting policy MUST treat the unicodeName and ldhName as two representations of the same value. The unicodeName value MUST be used while sorting if it is present; when the unicodeName is unavailable, the value of the ldhName MUST be used instead.
* いずれかのドメインまたはネームサーバでの検索に対する応答には、a-labelsとu-labels [RFC5890]の両方が含まれている可能性があるため、一般に、一貫したソートポリシーは、UnicodenameとLDHNAMEを同じ値の2つの表現として扱う必要があります。存在する場合は、符号化中にUnicodeName値を使用する必要があります。UnicodeNameが利用できない場合は、代わりにLDHNAMEの値を使用する必要があります。
* The jCard "sort-as" parameter MUST be ignored for the sorting capability described in this document.
* このドキュメントに記載されているソート機能については、JCARD "SORT-AS"パラメーターを無視する必要があります。
* Even if a nameserver can have multiple IPv4 and IPv6 addresses, the most common configuration includes one address for each IP version. Therefore, this specification makes the assumption that nameservers have a single IPv4 and/or IPv6 value. When more than one address per IP version is presented, sorting MUST be applied to the first value.
* ネームサーバーに複数のIPv4アドレスとIPv6アドレスを持つことができる場合でも、最も一般的な構成にはIPバージョンごとに1つのアドレスが含まれています。したがって、この仕様は、ネームサーバーが単一のIPv4および/またはIPv6値を持つという仮定を行う。IPバージョンごとに複数のアドレスが表示されている場合は、ソートを最初の値に適用する必要があります。
* Multiple events with a given action on an object might be returned. If this occurs, sorting MUST be applied to the most recent event.
* 特定のアクションを指定した複数のイベントが返される可能性があります。このような場合は、ソートを最新のイベントに適用する必要があります。
* Except for handle values, all the sorting properties defined for entity objects can be multivalued according to the definition of vCard as given in [RFC6350]. When more than one value is presented, sorting MUST be applied to the preferred value identified by the parameter pref="1". If the "pref" parameter is missing, sorting MUST be applied to the first value.
* ハンドル値を除いて、[RFC6350]に与えられたVCardの定義に従って、エンティティオブジェクトに定義されているすべてのソートプロパティを多値にすることができます。複数の値が提示されると、パラメータpref = "1"によって識別される優先値にソートを適用する必要があります。"pref"パラメータが欠落している場合は、ソートを最初の値に適用する必要があります。
The "jsonPath" field in the "sorting_metadata" element is used to clarify the RDAP response field the sorting property refers to. The mapping between the sorting properties and the jsonpaths of the RDAP response fields is shown below. The JSONPath operators used herein are described in Appendix A.
"SORTING_METADATA"要素の "JSONPATH"フィールドは、RDAP応答フィールドを明確にするために使用されます。ソートプロパティの参照。ソートプロパティとRDAP応答フィールドのJSONPathの間のマッピングを以下に示します。本明細書で使用されるJSONPath演算子は付録Aに記載されている。
* Searchable objects
* 検索可能なオブジェクト
registrationDate
$.domainSearchResults[*].events[?(@.eventAction=="registration"
)].eventDate
reregistrationDate
$.domainSearchResults[*].events[?(@.eventAction=="reregistratio
n")].eventDate
lastChangedDate
$.domainSearchResults[*].events[?(@.eventAction=="last
changed")].eventDate
expirationDate
$.domainSearchResults[*].events[?(@.eventAction=="expiration")]
.eventDate
deletionDate
$.domainSearchResults[*].events[?(@.eventAction=="deletion")].e
ventDate
reinstantiationDate
$.domainSearchResults[*].events[?(@.eventAction=="reinstantiati
on")].eventDate
transferDate
$.domainSearchResults[*].events[?(@.eventAction=="transfer")].e
ventDate
lockedDate
$.domainSearchResults[*].events[?(@.eventAction=="locked")].eve
ntDate
unlockedDate
$.domainSearchResults[*].events[?(@.eventAction=="unlocked")].e
ventDate
* Domain
* ドメイン
name $.domainSearchResults[*].[unicodeName,ldhName]
name $ .domainsearchResults [*]。[Unicodename、LDHNAME]
* Nameserver
* ネームサーバー
name $.nameserverSearchResults[*].[unicodeName,ldhName]
name $ .NameserverSearchResults [*] [unicodename、ldhname]
ipv4 $.nameserverSearchResults[*].ipAddresses.v4[0]
IPv4 $ .NameserverSearchResults [*]。ipaddresses.v4 [0]
ipv6 $.nameserverSearchResults[*].ipAddresses.v6[0]
IPv6 $ .NameServer検索結果[*]。IPアドレスv6 [0]
* Entity
* エンティティ
handle $.entitySearchResults[*].handle
$ .entitySearchResults [*]を処理します。ハンドル
fn
$.entitySearchResults[*].vcardArray[1][?(@[0]=="fn")][3]
org
$.entitySearchResults[*].vcardArray[1][?(@[0]=="org")][3]
voice
$.entitySearchResults[*].vcardArray[1][?(@[0]=="tel" &&
@[1].type=="voice")][3]
email
$.entitySearchResults[*].vcardArray[1][?(@[0]=="email")][3]
country
$.entitySearchResults[*].vcardArray[1][?(@[0]=="adr")][3][6]
cc
$.entitySearchResults[*].vcardArray[1][?(@[0]=="adr")][1].cc
city
$.entitySearchResults[*].vcardArray[1][?(@[0]=="adr")][3][3]
Additional notes on the provided jsonpaths:
提供されたJSONPathsに関する追加のメモ：
* Those related to the event dates are defined only for the "domain" object. To obtain the equivalent jsonpaths for "entity" and "nameserver", the path segment "domainSearchResults" must be replaced with "entitySearchResults" and "nameserverSearchResults", respectively.
* イベント日付に関連するものは、 "domain"オブジェクトに対してのみ定義されています。"entity"と "nameserver"の等価なJSONPathを取得するには、パスセグメント「DomainsearchResults」をそれぞれ "EntitySearchResults"と "NemaineServerSearchResults"に置き換える必要があります。
* Those related to jCard elements are specified without taking into account the "pref" parameter. Servers that sort those values identified by the "pref" parameter SHOULD update a jsonpath by adding an appropriate filter. For example, if the email values identified by pref="1" are considered for sorting, the jsonpath of the "email" sorting property should be $.entitySearchResults[*].vcardArray[1][?(@[0]=="email" && @[1].pref=="1")][3].
* JCard要素に関連するものは、「PREF」パラメータを考慮せずに指定されます。"pref"パラメーターによって識別された値を並べ替えるサーバーは、適切なフィルターを追加してJSONPathを更新する必要があります。たとえば、PREF = "1"で識別された電子メール値がソートに対して考慮されている場合、 "電子メール"ソートプロパティのJSONPATHは$ .entitySearchResults [*]です。vcardArray [1] [？（@ [0] =="Eメール" && @ [1] .pref == "1"）] [3]。
An RDAP server MAY use the "links" array of the "sorting_metadata" element to provide ready-made references [RFC8288] to the available sort criteria (Figure 2). Each link represents a reference to an alternate view of the results.
RDAPサーバは、「SORTING_METADATA」要素の「リンク」アレイを使用して、既製の参照[RFC8288]を使用可能なソート基準に提供することができる（図2）。各リンクは、結果の代替ビューへの参照を表します。
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",
"sorting"
],
...
"sorting_metadata": {
"currentSort": "name",
"availableSorts": [
{
"property": "registrationDate",
"jsonPath": "$.domainSearchResults[*]
.events[?(@.eventAction==\"registration\")].eventDate",
"default": false,
"links": [
{
"value": "https://example.com/rdap/domains?name=example*.com
&sort=name",
"rel": "alternate",
"href": "https://example.com/rdap/domains?name=example*.com
&sort=registrationDate",
"title": "Result Ascending Sort Link",
"type": "application/rdap+json"
},
{
"value": "https://example.com/rdap/domains?name=example*.com
&sort=name",
"rel": "alternate",
"href": "https://example.com/rdap/domains?name=example*.com
&sort=registrationDate:d",
"title": "Result Descending Sort Link",
"type": "application/rdap+json"
}
]
},
...
]
},
"domainSearchResults": [
...
]
}
Figure 2: Example of a "sorting_metadata" Instance to Implement Result Sorting
図2：結果ソートを実装する「SORTING_METADATA」インスタンスの例
The "cursor" parameter defined in this specification can be used to encode information about any pagination method. For example, in the case of a simple implementation of the "cursor" parameter to represent offset pagination information, the "cursor" value "b2Zmc2V0PTEwMCxsaW1pdD01MA==" is the base64 encoding of "offset=100,limit=50". Likewise, in a simple implementation to represent keyset pagination information, the "cursor" value "ZXhhbXBsZS1OLmNvbQ==" represents the base64 encoding of "key=example-N.com" whereby the key value identifies the last row of the current page.
この仕様で定義されている「CURSOR」パラメータを使用して、任意のページ区切り方法に関する情報をエンコードできます。たとえば、オフセットページネーション情報を表すために「CURSOR」パラメータを簡単に実装する場合、「カーソル」値「B2ZMC2V0PTEWMCXSAW1PDD01MA ==」は、「オフセット= 100、LIMIT = 50」の基本64エンコードです。同様に、キーセットのページ付け情報を表すための簡単な実装では、「CURSOR」値「ZXHHBXBSZS1OLMNVBQ ==」は「key = example-n.com」の基本64エンコーディングを表し、それによってキー値は現在のページの最後の行を識別する。
Note that this specification uses a base64 encoding for cursor obfuscation just for example. RDAP servers are NOT RECOMMENDED to obfuscate the "cursor" value through a mere base64 encoding.
この仕様は、たとえば、カーソル難読化のための基本64エンコーディングを使用しています。RDAPサーバーは、単なるBase64エンコーディングを介して「カーソル」値を難読化することはお勧めできません。
This solution lets RDAP providers implement a pagination method according to their needs, a user's access level, and the submitted query. Besides, servers can change the method over time without announcing anything to clients. The considerations that have led to this solution are described in more detail in Appendix B.
このソリューションでは、RDAPプロバイダは、ニーズ、ユーザーのアクセスレベル、および送信されたクエリに従ってページネーションメソッドを実装できます。その上、サーバーはクライアントに何も発表せずに、方法を時間の経過とともに変更できます。この解決策につながった考慮事項は、付録Bでより詳細に説明されています。
The ABNF syntax of the "cursor" parameter is the following:
"cursor"パラメータのABNF構文は次のとおりです。
cursor = "cursor=" 1*( ALPHA / DIGIT / "/" / "=" / "-" / "_" )
The following is an example of an RDAP query including the "cursor" parameter:
以下は、 "cursor"パラメータを含むRDAPクエリの例です。
https://example.com/rdap/domains?name=example*.com
&cursor=wJlCDLIl6KTWypN7T6vc6nWEmEYe99Hjf1XY1xmqV-M=
An RDAP server SHOULD use the "links" array of the "paging_metadata" element to provide a ready-made reference [RFC8288] to the next page of the result set (Figure 3). Examples of additional "rel" values a server MAY implement are "first", "last", and "prev".
RDAPサーバーは、「Paging_MetaData」要素の「リンク」アレイを使用して、結果セットの次のページに既製の参照[RFC8288]を提供する必要があります（図3）。サーバが実装することができる追加の「REL」値の例は、「最初」、「最後」、および「前」である。
{
"rdapConformance": [
"rdap_level_0",
"paging"
],
...
"notices": [
{
"title": "Search query limits",
"type": "result set truncated due to excessive load",
"description": [
"search results for domains are limited to 50"
]
}
],
"paging_metadata": {
"totalCount": 73,
"pageSize": 50,
"pageNumber": 1,
"links": [
{
"value": "https://example.com/rdap/domains?name=example*.com",
"rel": "next",
"href": "https://example.com/rdap/domains?name=example*.com
&cursor=wJlCDLIl6KTWypN7T6vc6nWEmEYe99Hjf1XY1xmqV-M=",
"title": "Result Pagination Link",
"type": "application/rdap+json"
}
]
},
"domainSearchResults": [
...
]
}
Figure 3: Example of a "paging_metadata" Instance to Implement Cursor Pagination
図3：カーソルページ付けを実装する「Paging_MetaData」インスタンスの例
The constraints for the values of parameters are defined by their ABNF syntax. Therefore, each request that includes an invalid value for a parameter SHOULD produce an HTTP 400 (Bad Request) response code. The same response SHOULD be returned in the following cases:
パラメータの値に対する制約は、それらのABNF構文によって定義されます。したがって、パラメータに無効な値を含む各要求は、HTTP 400（不良要求）応答コードを生成する必要があります。次の場合に同じ応答を返す必要があります。
* if sorting by either single or multiple properties, the client provides an unsupported value for the "sort" parameter, as well as a value related to an object property not included in the response
* シングルまたは複数のプロパティによるソートの場合、クライアントは「ソート」パラメータにサポートされていない値、および応答に含まれていないオブジェクトプロパティに関する値を提供します。
* if the client submits an invalid value for the "cursor" parameter
* クライアントが "cursor"パラメータに無効な値を送信すると
Optionally, the response MAY include additional information regarding either the supported sorting properties or the correct "cursor" value in the HTTP entity body (Figure 4).
任意選択で、応答は、サポートされているソートプロパティまたはHTTPエンティティ本体内の正しい「カーソル」値に関する追加の情報を含み得る（図4）。
{
"errorCode": 400,
"title": "Domain sorting property 'unknown' is not valid",
"description": [
"Supported domain sorting properties are:"
"'aproperty', 'anotherproperty'"
]
}
}
Figure 4: Example of RDAP Error Response Due to an Invalid Domain Sorting Property Included in the Request
図4：リクエストに含まれている無効なドメインソートプロパティによるRDAPエラー応答の例
Implementation of the new parameters is technically feasible, as operators for counting, sorting, and paging are currently supported by the major relational database management systems. Similar operators are completely or partially supported by the most well-known NoSQL databases (e.g., MongoDB, CouchDB, HBase, Cassandra, Hadoop, etc.). Additional implementation notes are included in Appendix C.
カウント、ソート、およびページングのためのオペレータが現在主なリレーショナルデータベース管理システムによってサポートされているため、新しいパラメータの実装は技術的に実行可能です。同様の演算子は、最も有名なNOSQLデータベース（例えば、MongoDB、CouchDB、HBase、Cassandra、Hadoopなど）によって完全にまたは部分的にサポートされています。追加の実装ノートは付録Cに含まれています。
IANA has registered the following values in the "RDAP Extensions" registry:
IANAは「RDAP Extensions」レジストリに次の値を登録しました。
Extension identifier: paging Registry operator: Any Published specification: RFC 8977 Contact: IETF <iesg@ietf.org> Intended usage: This extension describes a best practice for result set paging.
拡張識別子：ページングレジストリ演算子：任意の公開仕様：RFC 8977連絡先：IETF <iesg@ietf.org>意図された使用法：この拡張子は結果セットページングのためのベストプラクティスを表しています。
Extension identifier: sorting Registry operator: Any Published specification: RFC 8977 Contact: IETF <iesg@ietf.org> Intended usage: This extension describes a best practice for result set sorting.
拡張識別子：ソートレジストリ演算子：任意の公開仕様：RFC 8977連絡先：IETF <iesg@ietf.org>意図された使用法：この拡張子は、結果セットの並べ替えのベストプラクティスを説明しています。
Security services for the operations specified in this document are described in [RFC7481].
この文書で指定された操作のためのセキュリティサービスは[RFC7481]に記載されています。
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 either restricting search functionality or limiting the rate of search requests. Servers can also reduce their load by truncating the results in a response. However, this last security policy can result in a higher inefficiency or risk due to acting on incomplete information if the RDAP server does not provide any functionality to return the truncated results.
検索クエリは通常、ルックアップクエリと比較した場合、より多くのサーバーリソース（メモリ、CPUサイクル、ネットワーク帯域幅など）を必要とします。これにより、サーバーリソースの枯渇とその後のサービス拒否のリスクが高まります。このリスクは、検索機能を制限するか検索要求の割合を制限することによって軽減できます。応答の結果を切り捨てることによって、サーバーはそれらの負荷を減らすことができます。ただし、この最後のセキュリティポリシーは、RDAPサーバーが切り捨てられた結果を返す機能を提供していない場合、不完全な情報に対する行動により、より高い非効率的またはリスクをもたらす可能性があります。
The new parameters presented in this document provide RDAP operators with a way to implement a server that reduces inefficiency risks. The "count" parameter gives the client the ability to evaluate the completeness of a response. The "sort" parameter allows the client to obtain the most relevant information at the beginning of the result set. This can reduce the number of unnecessary search requests. Finally, the "cursor" parameter enables the user to scroll the result set by submitting a sequence of sustainable queries within server-acceptable limits.
この文書に記載されている新しいパラメータは、非効率的なリスクを軽減するサーバーを実装する方法でRDAP演算子を提供します。「Count」パラメータは、クライアントに応答の完全性を評価する能力を与えます。「ソート」パラメータを使用すると、クライアントは結果セットの先頭に最も関連情報を取得できます。これにより、不要な検索要求の数を減らすことができます。最後に、 "cursor"パラメータを使用すると、サーバー許容限度内の一連の持続可能なクエリを送信して、ユーザーは結果セットをスクロールできます。
[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>。
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/RFC5234, January 2008, <https://www.rfc-editor.org/info/rfc5234>.
[RFC5234] Crocker、D.、ED。2008年1月、<https://www.rfc-editor.org/info/rfc-editor.org/info/rfc- editor.org/info/rfc523,2008、<https://www.rfc-editor.org/info/rfc- editor.org/info/rfc- editor.org/info/rfc- editor.org/info/rfc- editor.org/info/rfc- editor.org/info/rfc5234>。
[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>。
[RFC6350] Perreault, S., "vCard Format Specification", RFC 6350, DOI 10.17487/RFC6350, August 2011, <https://www.rfc-editor.org/info/rfc6350>.
[RFC6350] PerreAll、S.、 "VCard Format Specification"、RFC 6350、DOI 10.17487 / RFC6350、2011年8月、<https：//www.rfc-editor.org/info/rfc6350>。
[RFC7095] Kewisch, P., "jCard: The JSON Format for vCard", RFC 7095, DOI 10.17487/RFC7095, January 2014, <https://www.rfc-editor.org/info/rfc7095>.
[RFC7095] Kewisch、P.、 "Jcard：VCARDのJSON形式"、RFC 7095、DOI 10.17487 / RFC7095、2014年1月、<https：//www.rfc-editor.org/info/rfc7095>。
[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>。
[RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer Protocol (HTTP/1.1): Semantics and Content", RFC 7231, DOI 10.17487/RFC7231, June 2014, <https://www.rfc-editor.org/info/rfc7231>.
[RFC7231] Fielding、R.、Ed。J. Reschke、ED。、「Hypertext Transfer Protocol（HTTP / 1.1）：セマンティクスとコンテンツ」、RFC 7231、DOI 10.17487 / RFC7231、2014年6月、<https://www.rfc-editor.org/info/rfc7231>。
[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>。
[RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data Interchange Format", STD 90, RFC 8259, DOI 10.17487/RFC8259, December 2017, <https://www.rfc-editor.org/info/rfc8259>.
[RFC8259] Bray、T.、ED。、「JavaScriptオブジェクト表記（JSON）データ交換フォーマット」、STD 90、RFC 8259、DOI 10.17487 / RFC8259、2017年12月、<https：//www.rfc-editor.org/ info / rfc8259>。
[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>。
[RFC8605] Hollenbeck, S. and R. Carney, "vCard Format Extensions: ICANN Extensions for the Registration Data Access Protocol (RDAP)", RFC 8605, DOI 10.17487/RFC8605, May 2019, <https://www.rfc-editor.org/info/rfc8605>.
[RFC8605] Hollenbeck、S.およびR. Carney、 "登録データアクセスプロトコルのICANN拡張（RDAP）"、RFC 8605、DOI 10.17487 / RFC8605、2019年5月、<https：///www.rfc-editor.org/info/rfc8605>。
[CURSOR] Nimesh, R., "Paginating Real-Time Data with Cursor Based Pagination", July 2014, <https://www.sitepoint.com/ paginating-real-time-data-cursor-based-pagination/>.
[カーソル] Nimesh、R.、「カーソルベースのページ区切りを用いたリアルタイムデータのページ化」、<https://www.sitepoint.com/ページング - リアルタイムデータカーソルベースのページテイン/>。
[CURSOR-API1] Facebook, "Facebook for Developers -- Using the Graph API", <https://developers.facebook.com/docs/graph-api/ using-graph-api>.
[CURSOR-API1] Facebook、「開発者向けのFacebook - Graph APIの使用」、<https：//developers.facebook.com/docs/graph-api/-graph-api>を使用します。
[CURSOR-API2] Twitter, "Twitter Ads API", <https://developer.twitter.com/en/docs/twitter-ads-api>.
[cursor-api2] Twitter、 "Twitter Ads API"、<https://developer.twitter.com/jaN / docs/twitter-ads-api>。
[GOESSNER-JSON-PATH] Goessner, S., "JSONPath - XPath for JSON", February 2007, <https://goessner.net/articles/JsonPath/>.
[auestner-json-path] auestner、S.、2007年2月、<https：//goessner.net/articles/jsonpath/>。
[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 />。
[JSONPATH-COMPARISON] "JSONPath Comparison", <https://cburgmer.github.io/json-path-comparison/>.
[JSONPATH-COMATE] - 「JSONPATH比較」、<https：//cburgmer.github.io/json-path-comparison/>。
[JSONPATH-WG] IETF, "JSON Path (jsonpath)", <https://datatracker.ietf.org/wg/jsonpath/about/>.
[JSONPATH-WG] IETF、「JSONパス（JSONPATH）」、<https://datatracker.ietf.org/wg/jsonpath/about/>。
[ODATA-PART1] Pizzo, M., Handl, R., and M. Zurmuehl, "OData Version 4.0. Part 1: Protocol Plus Errata 03", June 2016, <https://docs.oasis-open.org/odata/odata/v4.0/errata03/os/complete/part1- protocol/odata-v4.0-errata03-os-part1-protocol-complete.pdf>.
[ODATA-PART1]ピザ、M.、Handl、R.、M.Zurmuehl、2016年6月、2016年6月、<https：//docs.oasis-open.org/ODATA / ODATA / v4.0 / errata03 / os / complete / part1-プロトコル/ odata-v4.0-errata03-os-part1-protocol-complete.pdf>。
[REST] Fielding, R., "Architectural Styles and the Design of Network-based Software Architectures", 2000, <https://www.ics.uci.edu/~fielding/pubs/dissertation/ fielding_dissertation.pdf>.
[REST]フィールド化、R。、「ネットワークベースのソフトウェアアーキテクチャの設計」、2000、<https：//www.ics.uci.edu/~fielding/pubs/dissertation/ fielding_dissertation.pdf>。
[RFC6901] Bryan, P., Ed., Zyp, K., and M. Nottingham, Ed., "JavaScript Object Notation (JSON) Pointer", RFC 6901, DOI 10.17487/RFC6901, April 2013, <https://www.rfc-editor.org/info/rfc6901>.
[RFC6901] Bryan、P.、ED。、ZYP、K.、およびM. Nottingham、Ed。、「JavaScriptオブジェクト表記（JSON）ポインタ」、RFC 6901、DOI 10.17487 / RFC6901、2013年4月、<https：//www.rfc-editor.org/info/rfc6901>。
[SEEK] EverSQL, "Faster Pagination in Mysql - Why Order By With Limit and Offset is Slow?", July 2017, <https://www.eversql.com/faster-pagination-in-mysql-why-order-by-with-limit-and-offset-is-slow/>.
[Seek] everSQL、「MySQLでのより速いページ：なぜ順番とオフセットで遅くするのか」、2017年7月、<https：//www.eversql.com/faster-pagination-in-mysql-why-orth-orth-orth-orth-orth-orth-orth-orth-ory-ory-ory - -with-limit-and-offset-is-slow />。
[W3C.CR-xpath-31-20170321] Robie, J., Dyck, M., and J. Spiegel, "XML Path Language (XPath) 3.1", World Wide Web Consortium Recommendation REC-xpath-31-20170321, March 2017, <https://www.w3.org/TR/2017/REC-xpath-31-20170321/>.
[W3C.CR-XPath-31-20170321]ロビー、J.、DYCK、M.、J.Spiegel、「XMLパス言語（XPH）3.1」、ワールドワイドウェブコンソーシアム推薦Rec-XPath-31-20170321、3月31-201703212017、<https://www.w3.org/tr/2017/Rec-xpath-31-20170321/>。
The jsonpaths used in this document are provided according to the Goessner proposal [GOESSNER-JSON-PATH].
この文書で使用されているJSONATHSは、ヤーショナルプロポーザル[goessner-json-path]に従って提供されています。
Such specification requires that implementations support a set of "basic operators". These operators are used to access the elements of a JSON structure like objects and arrays, as well as their subelements (object members and array items, respectively). No operations are defined for retrieving parent or sibling elements of a given element. The root element is always referred to as $ regardless of it being an object or array.
そのような仕様は、実装が「基本演算子」のセットをサポートすることを必要とする。これらの演算子は、オブジェクトや配列のようなJSON構造の要素、およびそれらのサブ要素（それぞれオブジェクトメンバと配列項目）にアクセスするために使用されます。特定の要素の親または兄弟要素を検索するための操作は定義されていません。オブジェクトまたは配列であることに関係なく、ルート要素は常に$と呼ばれます。
Additionally, the specification permits implementations to support arbitrary script expressions. These can be used to index into an object or array, or to filter elements from an array. While script expression behavior is implementation-defined, most implementations support the basic relational and logical operators as well as both object member and array item access, sufficiently similar for the purpose of this document. Commonly supported operators/functions divided into "top-level operators" and "filter operators" are documented in Tables 2 and 3, respectively.
さらに、仕様は、実装が任意のスクリプト式をサポートすることを可能にします。これらは、オブジェクトまたは配列にインデックスを付けるために、またはアレイからの要素をフィルタリングするために使用できます。スクリプト式の動作は実装定義されていますが、ほとんどの実装は、このドキュメントの目的で十分に似ている、基本的なリレーショナルおよび論理演算子とオブジェクトメンバーとアレイアイテムのアクセスの両方をサポートしています。「最上位演算子」と「フィルタ演算子」に分割された一般的にサポートされている演算子/機能は、それぞれ表2および3に記載されています。
For more information on implementation interoperability issues, see [JSONPATH-COMPARISON]. At the time of writing, work is beginning on a standardization effort too (see [JSONPATH-WG]).
実装の相互運用性の問題の詳細については、[JSONPATH-CRATERATION]を参照してください。執筆時点では、標準化の取り組みに進んでいます（[JSONPATH-WG]を参照）。
+===================+=========================================+
| Operator | Description |
+===================+=========================================+
| $ | Root element |
+-------------------+-----------------------------------------+
| .<name> | Object member access (dot-notation) |
+-------------------+-----------------------------------------+
| ['<name>'] | Object member access (bracket-notation) |
+-------------------+-----------------------------------------+
| [<number>] | Array item access |
+-------------------+-----------------------------------------+
| * | All elements within the specified scope |
+-------------------+-----------------------------------------+
| [?(<expression>)] | Filter expression |
+-------------------+-----------------------------------------+
Table 2: JSONPath Top-Level Operators
表2：JSONPATH最上位演算子
+====================+========================================+
| Operator | Description |
+====================+========================================+
| @ | Current element being processed |
+--------------------+----------------------------------------+
| .<name> | Object member access |
+--------------------+----------------------------------------+
| .[<name1>,<name2>] | Union of object members |
+--------------------+----------------------------------------+
| [<number>] | Array item access |
+--------------------+----------------------------------------+
| == | Left is equal to right |
+--------------------+----------------------------------------+
| != | Left is not equal to right |
+--------------------+----------------------------------------+
| < | Left is less than right |
+--------------------+----------------------------------------+
| <= | Left is less than or equal to right |
+--------------------+----------------------------------------+
| > | Left is greater than right |
+--------------------+----------------------------------------+
| >= | Left is greater than or equal to right |
+--------------------+----------------------------------------+
| && | Logical conjunction |
+--------------------+----------------------------------------+
| || | Logical disjunction |
+--------------------+----------------------------------------+
Table 3: JSONPath Filter Operators
表3：JSONPATHフィルタ演算子
An RDAP query could return a response with hundreds, even thousands, of objects, especially when partial matching is used. For this reason, the "cursor" parameter addressing result pagination is defined to make responses easier to handle.
RDAPクエリは、特に部分的なマッチングが使用されているときに、何百ものオブジェクトの何千ものオブジェクトで応答を返す可能性があります。このため、「カーソル」パラメータアドレス指定結果ページ付けは、応答を処理しやすくするために定義されています。
Presently, the most popular methods to implement pagination in a REST API include offset pagination and keyset pagination. Neither pagination method requires the server to handle the result set in a storage area across multiple requests since a new result set is generated each time a request is submitted. Therefore, they are preferred to any other method requiring the management of a REST session.
現在、安定APIにページ区切りを実装するための最も一般的な方法は、オフセットページ付けおよびキーセットページ付けを含む。どちらのページネーション方法でも、リクエストが送信されるたびに新しい結果セットが生成されるため、サーバーが複数の要求にわたって記憶領域内の結果セットを処理する必要があります。したがって、それらは、休止セッションの管理を必要とする他の方法が好ましい。
Using limit and offset operators represents the traditionally used method to implement result pagination. Both of them can be used individually:
制限およびオフセットの使用演算子は、結果のページ付けを実施するために伝統的に使用された方法を表します。どちらも個別に使用できます。
"limit=N": means that the server returns the first N objects of the result set
"limit = n"：サーバーが結果セットの最初のnオブジェクトを返すことを意味します
"offset=N": means that the server skips the first N objects and returns objects starting from position N+1
"offset = n"：サーバーが最初のN個のオブジェクトをスキップして、位置N 1から始めてオブジェクトを返します。
When limit and offset are used together, they provide the ability to identify a specific portion of the result set. For example, the pair "offset=100,limit=50" returns the first 50 objects starting from position 101 of the result set.
制限とオフセットが一緒に使用されるとき、それらは結果セットの特定の部分を識別する機能を提供します。たとえば、ペア "オフセット= 100、limit = 50"は、結果セットの位置101から始まる最初の50オブジェクトを返します。
Though easy to implement, offset pagination also includes drawbacks:
実装が簡単ですが、オフセットページピネーションには欠点も含まれています。
* When offset has a very high value, scrolling the result set could take some time.
* オフセットの値が非常に高い場合は、結果セットをスクロールすると時間がかかる可能性があります。
* It always requires fetching all rows before dropping as many rows as specified by offset.
* オフセットで指定された数の行を削除する前に、常にすべての行をフェッチする必要があります。
* It may return inconsistent pages when data are frequently updated (i.e., real-time data).
* データが頻繁に更新されるとき（すなわち、リアルタイムデータ）のときに矛盾するページを返すことがある。
Keyset pagination [SEEK] adds a query condition that enables the selection of the only data not yet returned. This method has been taken as the basis for the implementation of a "cursor" parameter [CURSOR] by some REST API providers [CURSOR-API1] [CURSOR-API2]. The cursor is a URL-safe string opaque to the client and representing a logical pointer to the first result of the next page.
Keyset Pagination [Sek]まだ返されていないデータの選択を可能にするクエリ条件を追加します。この方法は、一部のREST APIプロバイダ[CURSOR-API1] [CURSOR-API2]によって、「カーソル」パラメータ[カーソル]の実装の基礎として取られています。カーソルはクライアントへのURLセーフな文字列不透明で、次のページの最初の結果への論理ポインタを表します。
Nevertheless, even keyset pagination can be troublesome:
それにもかかわらず、Keyset Paginationさえも面倒な場合があります。
* It needs at least one key field.
* それは少なくとも1つのキーフィールドが必要です。
* It does not allow sorting simply by any field because the sorting criterion must contain a key.
* ソート基準に鍵を含める必要があるため、単純に任意のフィールドでソートを許可しません。
* It works best with full composite values supported by database management systems (i.e., [x,y]>[a,b]); emulation is possible but inelegant and less efficient.
* データベース管理システム（すなわち[x、y]> [a、b]）でサポートされている完全な複合値で最適に機能します。エミュレーションは可能ですが、目立つ、そして効率的ではありません。
* It does not allow direct navigation to arbitrary pages because the result set must be scrolled in sequential order starting from the initial page.
* 結果セットを最初のページから始めて順次順序でスクロールする必要があるため、任意のページへの直接ナビゲーションを許可しません。
* Implementing bidirectional navigation is tedious because all comparison and sort operations have to be reversed.
* すべての比較およびソート操作を逆にする必要があるため、双方向ナビゲーションの実装は面倒です。
Some additional considerations can be made in the RDAP context:
RDAPコンテキストで追加の考慮事項をいくつかします。
* An RDAP object is a conceptual aggregation of information generally collected from more than one data structure (e.g., table), and this makes it even harder to implement keyset pagination, a task that is already quite difficult. For example, the entity object can include information from different data structures (registrars, registrants, contacts, resellers), each one with its key field mapping the RDAP entity handle.
* RDAPオブジェクトは、一般的に複数のデータ構造（例えば、テーブル）から収集された情報の概念的な集約であり、これは鍵のページ付け、すでに非常に困難なタスクを実装することをさらに困難にする。例えば、エンティティオブジェクトは、異なるデータ構造（レジストラ、登録者、連絡先、再販業者）からの情報を含み、それぞれがRDAPエンティティハンドルをマッピングする。
* Depending on the number of page results as well as the number and the complexity of the properties of each RDAP object in the response, the time required by offset pagination to skip the previous pages could be much faster than the processing time needed to build the current page. In fact, RDAP objects are usually formed by information belonging to multiple data structures and containing multivalued properties (i.e., arrays); therefore, data selection might be a time-consuming process. This situation occurs even though the selection is supported by indexes.
* 応答内の各RDAPオブジェクトのプロパティの数および複雑さの数および複雑さに応じて、前のページをスキップするためのオフセットページネーションによって要求される時間は、現在のものを構築するのに必要な処理時間よりはるかに速くなる可能性があります。ページ。実際、RDAPオブジェクトは通常、複数のデータ構造に属し、多値的なプロパティ（すなわちアレイ）を含む情報によって形成される。したがって、データ選択は時間のかかるプロセスである可能性があります。この状況は、選択がインデックスでサポートされていても発生します。
* Depending on the access levels defined by each RDAP operator, the increase in complexity and the decrease in flexibility of keyset pagination in comparison to offset pagination could be considered impractical.
* 各RDAPオペレータによって定義されたアクセスレベルに応じて、オフセット誤植と比較した鍵の複雑さの増加および鍵の柔軟性の低下は非実用的であると見なすことができる。
Ultimately, both pagination methods have benefits and drawbacks.
最終的には、両方のページ区切り方法は利点と欠点を持っています。
This section contains an overview of the main choices made during the implementation of the capabilities defined in this document in the RDAP public test server of Registro.it at the Institute of Informatics and Telematics of the National Research Council (IIT-CNR). The content of this section can represent guidance for implementers who plan to provide RDAP users with those capabilities. The RDAP public test server can be accessed at <https://rdap.pubtest.nic.it/>. Further documentation about the server features is available at <https://rdap.pubtest.nic.it/doc/ README.html>.
このセクションでは、この文書で定義されている機能の実装中にResetrroのRDAP Public Test Serverで定義されている機能の実装の概要について説明します。国立研究評議会（IIT-CNR）の情報学とテレマティックス。このセクションの内容は、RDAPユーザーをそれらの機能を提供することを計画する実装者のためのガイダンスを表すことができます。RDAPパブリックテストサーバーは<https://rdap.pubtest.nic.it/>でアクセスできます。サーバー機能に関するさらなるマニュアルは<https://rdap.pubtest.nic.it/doc/ readme.html>で入手できます。
If no sort criterion is specified in the query string, the results are sorted by a default property: "name" for domains and nameservers, and "handle" for entities. The server supports multiple property sorting but the "sorting_metadata" object includes only the links to alternative result set views sorted by a single property just to show the list of sorting properties allowed for each searchable object. The server supports all the object-specific sorting properties described in the specification except for nameserver sorting based on unicodeName, that is, the "name" sorting property is mapped onto the "ldhName" response field. Regarding the object-common properties, sorting by registrationDate, expirationDate, lastChangedDate, and transferDate is supported.
クエリ文字列にソート基準が指定されていない場合、結果はデフォルトのプロパティ：ドメインとネームサーバーの「名前」、およびエンティティの「ハンドル」によってソートされます。サーバーは複数のプロパティの並べ替えをサポートしていますが、「SORTING_METADATA」オブジェクトには、検索可能なオブジェクトごとに許可されているソートプロパティのリストを表示するためだけに、単一のプロパティによってソートされた代替結果セットビューへのリンクのみが含まれます。サーバーは、UnicodeNameに基づいてネームサーバーの並べ替えを除いて、指定されたすべてのオブジェクト固有のソートプロパティをサポートしています。つまり、「名前」ソートプロパティは "LDHNAME"応答フィールドにマッピングされます。オブジェクト共通のプロパティに関しては、registionDate、ExpirationDate、LastChangeddate、およびTransferDateによるソートがサポートされています。
The counting operation is implemented through a separate query. Some relational database management systems support custom operators to get the total count together with the rows, but the resulting query can be considerably more expensive than that performed without the total count. Therefore, as "totalCount" is an optional response information, always fetching the total number of rows has been considered an inefficient solution. Furthermore, to avoid the processing of unnecessary queries, when the "count" parameter is included in the submitted query, it is not also repeated in the query strings of the "links" array provided in both "paging_metadata" and "sorting_metadata" objects.
カウント動作は別のクエリを通して実装されます。いくつかのリレーショナルデータベース管理システムによっては、カスタムオペレータが行と一緒に合計カウントを取得することができますが、結果として得られるクエリは、合計数のないものよりもかなり高価になる可能性があります。したがって、「TotalCount」はオプションの応答情報であるため、常に合計行数を取り出すことは非効率的な解決策と見なされています。さらに、不要なクエリの処理を回避するために、「COUNT」パラメータが送信されたクエリに含まれている場合、「Paging_MetaData」および「SORTING_METADATA」オブジェクトの両方に提供される「リンク」アレイのクエリ文字列にも繰り返されない。
The server implements the cursor pagination through the keyset pagination when sorting by a unique property is requested or the default sort is applied. Otherwise, it implements the cursor pagination through the offset pagination. As most relational database management systems don't support the comparison of full composite values natively, the implementation of full keyset pagination seem to be troublesome so, at least initially, a selective applicability of keyset pagination is advisable. Moreover, the "cursor" value encodes not only information about pagination but also about the search pattern and the other query parameters in order to check the consistency of the entire query string. If the "cursor" value is inconsistent with the rest of the query string, the server returns an error response.
一意のプロパティによるソートが要求されたとき、またはデフォルトのソートが適用される場合、サーバーはキーセットページネーションを通してカーソルページ化を実装します。さもなければ、それはオフセットのページ付けを通してカーソルページ化を実装する。ほとんどのリレーショナルデータベース管理システムが完全複合値の比較を発表していないので、全てのキーセットのページ付けの実装は厄介であるように思われるので、少なくとも最初はキーサイトのページ付けの選択的適用性が賢明である。さらに、「カーソル」値は、照会文字列全体の一貫性を確認するために、ページ像の情報だけでなく検索パターンおよび他のクエリパラメータについても符号化する。"cursor"値が残りのクエリ文字列と矛盾している場合、サーバーはエラー応答を返します。
Acknowledgements
謝辞
The authors would like to acknowledge Brian Mountford, Tom Harrison, Karl Heinz Wolf, Jasdip Singh, Erik Kline, Éric Vyncke, Benjamin Kaduk, and Roman Danyliw for their contributions to the development of this document.
著者らはBrian Mountford、Tom Harrison、Karl Heinz Wolf、Jasdip Singh、Erik Kline、Erik Vyncke、Benjamin Kaduk、およびRoman Danyyliwがこの文書の開発に貢献したいと思います。
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
Scott Hollenbeck Verisign Labs 12061 Bluemont Way Reston, VA 20190 United States of America
Scott Hollenbeck Verisign Labs 12061 Bluemont Way Reston、VA 20190アメリカ合衆国
Email: shollenbeck@verisign.com
URI: https://www.verisignlabs.com/