draft-ietf-regext-rdap-sorting-and-paging-01.txt   draft-ietf-regext-rdap-sorting-and-paging-02.txt 
Registration Protocols Extensions M. Loffredo Registration Protocols Extensions M. Loffredo
Internet-Draft M. Martinelli Internet-Draft M. Martinelli
Intended status: Standards Track IIT-CNR/Registro.it Intended status: Standards Track IIT-CNR/Registro.it
Expires: October 13, 2019 S. Hollenbeck Expires: November 28, 2019 S. Hollenbeck
Verisign Labs Verisign Labs
April 11, 2019 May 27, 2019
Registration Data Access Protocol (RDAP) Query Parameters for Result Registration Data Access Protocol (RDAP) Query Parameters for Result
Sorting and Paging Sorting and Paging
draft-ietf-regext-rdap-sorting-and-paging-01 draft-ietf-regext-rdap-sorting-and-paging-02
Abstract Abstract
The Registration Data Access Protocol (RDAP) does not include core The Registration Data Access Protocol (RDAP) does not include core
functionality for clients to provide sorting and paging parameters functionality for clients to provide sorting and paging parameters
for control of large result sets. This omission can lead to for control of large result sets. This omission can lead to
unpredictable server processing of queries and client processing of unpredictable server processing of queries and client processing of
responses. This unpredictability can be greatly reduced if clients responses. This unpredictability can be greatly reduced if clients
can provide servers with their preferences for managing response can provide servers with their preferences for managing large
values. This document describes RDAP query extensions that allow responses. This document describes RDAP query extensions that allow
clients to specify their preferences for sorting and paging result clients to specify their preferences for sorting and paging result
sets. sets.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on October 13, 2019. This Internet-Draft will expire on November 28, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 20 skipping to change at page 2, line 20
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Conventions Used in This Document . . . . . . . . . . . . 4 1.1. Conventions Used in This Document . . . . . . . . . . . . 4
2. RDAP Query Parameter Specification . . . . . . . . . . . . . 4 2. RDAP Query Parameter Specification . . . . . . . . . . . . . 4
2.1. Sorting and Paging Metadata . . . . . . . . . . . . . . . 4 2.1. Sorting and Paging Metadata . . . . . . . . . . . . . . . 4
2.2. "count" Parameter . . . . . . . . . . . . . . . . . . . . 6 2.2. "count" Parameter . . . . . . . . . . . . . . . . . . . . 6
2.3. "sort" Parameter . . . . . . . . . . . . . . . . . . . . 7 2.3. "sort" Parameter . . . . . . . . . . . . . . . . . . . . 7
2.3.1. Representing Sorting Links . . . . . . . . . . . . . 11 2.3.1. Sorting Properties Declaration . . . . . . . . . . . 7
2.4. "limit" and "offset" Parameters . . . . . . . . . . . . . 12 2.3.2. Representing Sorting Links . . . . . . . . . . . . . 11
2.4.1. Representing Offset Pagination Links . . . . . . . . 13 2.4. "cursor" Parameter . . . . . . . . . . . . . . . . . . . 12
2.5. "cursor" Parameter . . . . . . . . . . . . . . . . . . . 14 2.4.1. Representing Paging Links . . . . . . . . . . . . . . 15
2.5.1. Representing Cursor Pagination Links . . . . . . . . 16 3. Negative Answers . . . . . . . . . . . . . . . . . . . . . . 16
3. Negative Answers . . . . . . . . . . . . . . . . . . . . . . 17 4. RDAP Conformance . . . . . . . . . . . . . . . . . . . . . . 17
4. RDAP Conformance . . . . . . . . . . . . . . . . . . . . . . 18 5. Implementation Considerations . . . . . . . . . . . . . . . . 17
5. Implementation Considerations . . . . . . . . . . . . . . . . 18 6. Implementation Status . . . . . . . . . . . . . . . . . . . . 17
6. Implementation Status . . . . . . . . . . . . . . . . . . . . 19 6.1. IIT-CNR/Registro.it . . . . . . . . . . . . . . . . . . . 18
6.1. IIT-CNR/Registro.it . . . . . . . . . . . . . . . . . . . 20 6.2. Google Registry . . . . . . . . . . . . . . . . . . . . . 18
6.2. Google Registry . . . . . . . . . . . . . . . . . . . . . 20 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
7. Security Considerations . . . . . . . . . . . . . . . . . . . 20 8. Security Considerations . . . . . . . . . . . . . . . . . . . 19
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 21 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 19
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 10.1. Normative References . . . . . . . . . . . . . . . . . . 19
10.1. Normative References . . . . . . . . . . . . . . . . . . 21 10.2. Informative References . . . . . . . . . . . . . . . . . 21
10.2. Informative References . . . . . . . . . . . . . . . . . 22 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 22
Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 25 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25
1. Introduction 1. Introduction
The availability of functionality for result sorting and paging The availability of functionality for result sorting and paging
provides benefits to both clients and servers in the implementation provides benefits to both clients and servers in the implementation
of RESTful services [REST]. These benefits include: of RESTful services [REST]. These benefits include:
o reducing the server response bandwidth requirements; o reducing the server response bandwidth requirements;
o improving server response time; o improving server response time;
o improving query precision and, consequently, obtaining more o improving query precision and, consequently, obtaining more
skipping to change at page 3, line 32 skipping to change at page 3, line 32
identification or the search type is included in the query string. identification or the search type is included in the query string.
The second approach is therefore not compliant with the HTTP standard The second approach is therefore not compliant with the HTTP standard
[RFC7230]. As a result, this document describes a specification [RFC7230]. As a result, this document describes a specification
based on use of query parameters. based on use of query parameters.
Currently the RDAP protocol [RFC7482] defines two query types: Currently the RDAP protocol [RFC7482] defines two query types:
o lookup: the server returns only one object; o lookup: the server returns only one object;
o search: the server returns a collection of objects. o search: the server returns a collection of objects.
While the lookup query does not raise issues in the management of While the lookup query does not raise issues in the response
large result sets, the search query can potentially generate a large management, the search query can potentially generate a large result
result set that could be truncated according to the limits of the set that could be truncated according to the server limits. In
server. In addition, it is not possible to obtain the total number addition, it is not possible to obtain the total number of the
of the objects found that might be returned in a search query objects found that might be returned in a search query response
response [RFC7483]. Lastly, there is no way to specify sort criteria [RFC7483]. Lastly, there is no way to specify sort criteria to
to return the most relevant objects at the beginning of the result return the most relevant objects at the beginning of the result set.
set. Therefore, the client could traverse the whole result set to Therefore, the client might traverse the whole result set to find the
find the relevant objects or, due to truncation, could not find them relevant objects or, due to truncation, could not find them at all.
at all.
The protocol described in this specification extends RDAP query The specification described in this document extends RDAP query
capabilities to enable result sorting and paging, by adding new query capabilities to enable result sorting and paging, by adding new query
parameters that can be applied to RDAP search path segments. The parameters that can be applied to RDAP search path segments. The
service is implemented using the Hypertext Transfer Protocol (HTTP) service is implemented using the Hypertext Transfer Protocol (HTTP)
[RFC7230] and the conventions described in RFC 7480 [RFC7480]. [RFC7230] and the conventions described in RFC 7480 [RFC7480].
The implementation of the new parameters is technically feasible, as The implementation of the new parameters is technically feasible, as
operators for counting, sorting and paging rows are currently operators for counting, sorting and paging rows are currently
supported by the major RDBMSs. supported by the major RDBMSs.
1.1. Conventions Used in This Document 1.1. Conventions Used in This Document
skipping to change at page 4, line 23 skipping to change at page 4, line 23
The new query parameters are OPTIONAL extensions of path segments The new query parameters are OPTIONAL extensions of path segments
defined in RFC 7482 [RFC7482]. They are as follows: defined in RFC 7482 [RFC7482]. They are as follows:
o "count": a boolean value that allows a client to request the total o "count": a boolean value that allows a client to request the total
number of objects found (that due to truncation can be different number of objects found (that due to truncation can be different
from the number of returned objects); from the number of returned objects);
o "sort": a string value that allows a client to request a specific o "sort": a string value that allows a client to request a specific
sort order for the result set; sort order for the result set;
o "limit" and "offset": numeric values that allow a client to
request a specific portion of the entire result set;
o "cursor": a string value representing a pointer to a specific o "cursor": a string value representing a pointer to a specific
fixed size portion of the result set. It is alternate to "limit" fixed size portion of the result set.
and "offset".
Augmented Backus-Naur Form (ABNF) [RFC5234] is used in the following Augmented Backus-Naur Form (ABNF) [RFC5234] is used in the following
sections to describe the formal syntax of these new parameters. sections to describe the formal syntax of these new parameters.
2.1. Sorting and Paging Metadata 2.1. Sorting and Paging Metadata
According to most advanced principles in REST design, collectively According to most advanced principles in REST design, collectively
known as HATEOAS (Hypermedia as the Engine of Application State) known as HATEOAS (Hypermedia as the Engine of Application State)
([HATEOAS]), a client entering a REST application through an initial ([HATEOAS]), a client entering a REST application through an initial
URI should use the server-provided links to dynamically discover URI should use the server-provided links to dynamically discover
skipping to change at page 6, line 20 skipping to change at page 6, line 15
2.2. "count" Parameter 2.2. "count" Parameter
Currently the RDAP protocol does not allow a client to determine the Currently the RDAP protocol does not allow a client to determine the
total number of the results in a query response when the result set total number of the results in a query response when the result set
is truncated. This is rather inefficient because the user cannot is truncated. This is rather inefficient because the user cannot
evaluate the query precision and, at the same time, cannot receive evaluate the query precision and, at the same time, cannot receive
information that could be relevant. information that could be relevant.
The "count" parameter provides additional functionality (Figure 1) The "count" parameter provides additional functionality (Figure 1)
that allows a client to request information from the server that that allows a client to request information from the server that
specifies the total number of elements matching a particular search specifies the total number of elements matching the search pattern.
pattern.
https://example.com/rdap/domains?name=*nr.com&count=true https://example.com/rdap/domains?name=*nr.com&count=true
Figure 1: Example of RDAP query reporting the "count" parameter Figure 1: Example of RDAP query reporting the "count" parameter
The ABNF syntax is the following: The ABNF syntax is the following:
count = "count" EQ ( trueValue / falseValue ) count = "count=" ( trueValue / falseValue )
trueValue = ("true" / "yes" / "1") trueValue = ("true" / "yes" / "1")
falseValue = ("false" / "no" / "0") falseValue = ("false" / "no" / "0")
EQ = "="
A trueValue means that the server MUST provide the total number of A trueValue means that the server MUST provide the total number of
the objects in the "totalCount" field of the "paging_metadata" the objects in the "totalCount" field of the "paging_metadata"
element (Figure 2). A falseValue means that the server MUST NOT element (Figure 2). A falseValue means that the server MUST NOT
provide this number. provide this number.
{ {
"rdapConformance": [ "rdapConformance": [
"rdap_level_0", "rdap_level_0",
"paging_level_0" "paging_level_0"
skipping to change at page 7, line 28 skipping to change at page 7, line 11
Figure 2: Example of RDAP response with "paging_metadata" element Figure 2: Example of RDAP response with "paging_metadata" element
containing the "totalCount" field containing the "totalCount" field
2.3. "sort" Parameter 2.3. "sort" Parameter
The RDAP protocol does not provide any capability to specify results The RDAP protocol does not provide any capability to specify results
sort criteria. A server could implement a default sorting scheme sort criteria. A server could implement a default sorting scheme
according to the object class, but this feature is not mandatory and according to the object class, but this feature is not mandatory and
might not meet user requirements. Sorting can be addressed by the might not meet user requirements. Sorting can be addressed by the
client, but this solution is rather inefficient. Sorting and paging client, but this solution is rather inefficient. Sorting features
features provided by the RDAP server could help avoid truncation of provided by the RDAP server could help avoid truncation of relevant
relevant results and allow for scrolling the result set using results.
subsequent queries.
The "sort" parameter allows the client to ask the server to sort the The "sort" parameter allows the client to ask the server to sort the
results according to the values of one or more properties and results according to the values of one or more properties and
according to the sort direction of each property. The ABNF syntax is according to the sort direction of each property. The ABNF syntax is
the following: the following:
sort = "sort" EQ sortItem *( "," sortItem ) sort = "sort=" sortItem *( "," sortItem )
sortItem = property-ref [":" ( "a" / "d" ) ] sortItem = property-ref [":" ( "a" / "d" ) ]
property-ref = ALPHA *( ALPHA / DIGIT / "_" )
"a" means that the ascending sort MUST be applied, "d" means that the "a" means that the ascending sort MUST be applied, "d" means that the
descending sort MUST be applied. If the sort direction is absent, an descending sort MUST be applied. If the sort direction is absent, an
ascending sort MUST be applied (Figure 3). ascending sort MUST be applied (Figure 3).
https://example.com/rdap/domains?name=*nr.com&sort=ldhName
https://example.com/rdap/domains?name=*nr.com&sort=registrationDate:d
https://example.com/rdap/domains?name=*nr.com&sort=lockedDate,ldhName
Figure 3: Examples of RDAP query reporting the "sort" parameter
If the "sort" parameter reports an allowed sorting property, it MUST
be provided in the "currentSort" field of the "sorting_metadata"
element.
2.3.1. Sorting Properties Declaration
In the "sort" parameter ABNF syntax, property-ref represents a In the "sort" parameter ABNF syntax, property-ref represents a
reference to a property of an RDAP object. Such a reference could be reference to a property of an RDAP object. Such a reference could be
expressed by using a JSON Path. The JSON Path in a JSON document expressed by using a JSON Path. The JSON Path in a JSON document
[RFC8259] is equivalent to the XPath [W3C.CR-xpath-31-20161213] in a [RFC8259] is equivalent to the XPath [W3C.CR-xpath-31-20161213] in a
XML document. For example, the JSON Path to select the value of the XML document. For example, the JSON Path to select the value of the
ASCII name inside an RDAP domain object is "$.ldhName", where $ ASCII name inside an RDAP domain object is "$.ldhName", where $
identifies the root of the document (DOM). Another way to select a identifies the root of the document (DOM). Another way to select a
value inside a JSON document is the JSON Pointer [RFC6901]. While value inside a JSON document is the JSON Pointer [RFC6901]. While
JSON Path or JSON Pointer are both standard ways to select any value JSON Path or JSON Pointer are both standard ways to select any value
inside JSON data, neither is particularly easy to use (e.g. inside JSON data, neither is particularly easy to use (e.g.
skipping to change at page 8, line 43 skipping to change at page 8, line 44
* lastChangedDate * lastChangedDate
* expirationDate * expirationDate
* deletionDate * deletionDate
* reinstantiationDate * reinstantiationDate
* transferDate * transferDate
* lockedDate * lockedDate
* unlockedDate * unlockedDate
o Object specific properties. With regard to the specific o Object specific properties. With regard to the specific
properties, some of them are already defined among the query properties, some of them are already defined among the query
paths. In the following the list of the proposed sorting paths. In the following a list of possible sorting properties,
properties, grouped by objects, is shown: grouped by objects, is shown:
* Domain: ldhName * Domain: ldhName
* Nameserver: ldhName, ipV4, ipV6. * Nameserver: ldhName, ipV4, ipV6.
* Entity: fn, handle, org, email, voice, country, city. * Entity: fn, handle, org, email, voice, country, city.
In the following, the correspondence between the sorting properties The correspondence between the sorting properties and the RDAP fields
and the RDAP fields is shown (Table 1): is shown in Table 1:
+------------+------------+---------------+------------+------------+ +------------+------------+---------------+------------+------------+
| Object | Sorting | RDAP property | Reference | Reference | | Object | Sorting | RDAP property | Reference | Reference |
| class | property | | in RFC | in RFC | | class | property | | in RFC | in RFC |
| | | | 7483 | 6350 | | | | | 7483 | 6350 |
+------------+------------+---------------+------------+------------+ +------------+------------+---------------+------------+------------+
| Searchable | Common | eventAction | 4.5. | | | Searchable | Common | eventAction | 4.5. | |
| objects | properties | values | | | | objects | properties | values | | |
| | | suffixed by | | | | | | suffixed by | | |
| | | "Date" | | | | | | "Date" | | |
skipping to change at page 9, line 40 skipping to change at page 9, line 40
| | city | locality in | 5.1. | 6.3.1 | | | city | locality in | 5.1. | 6.3.1 |
| | | vcard adr | | | | | | vcard adr | | |
+------------+------------+---------------+------------+------------+ +------------+------------+---------------+------------+------------+
Table 1: Sorting properties definition Table 1: Sorting properties definition
With regard to the definitions in Table 1, some further With regard to the definitions in Table 1, some further
considerations must be made to disambiguate cases where the RDAP considerations must be made to disambiguate cases where the RDAP
property is multivalued: property is multivalued:
o Even if a nameserver can have multiple IPv4 and IPv6 addresses, o even if a nameserver can have multiple IPv4 and IPv6 addresses,
the most common configuration includes one address for each IP the most common configuration includes one address for each IP
version. Therefore, the assumption of having a single IPv4 and/or version. Therefore, the assumption of having a single IPv4 and/or
IPv6 value for a nameserver cannot be considered too stringent. IPv6 value for a nameserver cannot be considered too stringent;
o With the exception of handle values, all the sorting properties o with the exception of handle values, all the sorting properties
defined for entity objects can be multivalued according to the defined for entity objects can be multivalued according to the
definition of vCard as given in RFC6350 [RFC6350]. When more than definition of vCard as given in RFC6350 [RFC6350]. When more than
a value is reported, sorting can be applied to the preferred value a value is reported, sorting can be applied to the preferred value
identified by the parameter pref="1". identified by the parameter pref="1".
Each RDAP provider MAY define other sorting properties than those Each RDAP provider MAY define other sorting properties than those
shown in this document. shown in this document.
The "jsonPath" field in the "sorting_metadata" section is used to The "jsonPath" field in the "sorting_metadata" element is used to
clarify the RDAP field the sorting property refers to. In the clarify the RDAP field the sorting property refers to. The mapping
following, the mapping between the sorting properties and the JSON between the sorting properties and the JSON Paths of the RDAP fields
Paths of the RDAP fields is shown (Table 2). The JSON Paths are is shown in Table 2. The JSON Paths are provided according to the
provided according to the Goessner v.0.8.0 specification Goessner v.0.8.0 specification ([GOESSNER-JSON-PATH]):
([GOESSNER-JSON-PATH]):
+-------+-------------+---------------------------------------------+ +-------+-------------+---------------------------------------------+
| Objec | Sorting | JSON Path | | Objec | Sorting | JSON Path |
| t | property | | | t | property | |
| class | | | | class | | |
+-------+-------------+---------------------------------------------+ +-------+-------------+---------------------------------------------+
| Searc | registratio | "$.domainSearchResults[*].events[?(@.eventA | | Searc | registratio | "$.domainSearchResults[*].events[?(@.eventA |
| hable | nDate | ction=="registration")].eventDate | | hable | nDate | ction=="registration")].eventDate |
| objec | | | | objec | | |
| ts | | | | ts | | |
skipping to change at page 11, line 17 skipping to change at page 11, line 16
| | email | $.entitySearchResults[*].vcardArray[1][?(@[ | | | email | $.entitySearchResults[*].vcardArray[1][?(@[ |
| | | 0]=="email")][3] | | | | 0]=="email")][3] |
| | country | $.entitySearchResults[*].vcardArray[1][?(@[ | | | country | $.entitySearchResults[*].vcardArray[1][?(@[ |
| | | 0]=="adr")][3][6] | | | | 0]=="adr")][3][6] |
| | city | $.entitySearchResults[*].vcardArray[1][?(@[ | | | city | $.entitySearchResults[*].vcardArray[1][?(@[ |
| | | 0]=="adr")][3][3] | | | | 0]=="adr")][3][3] |
+-------+-------------+---------------------------------------------+ +-------+-------------+---------------------------------------------+
Table 2: Sorting properties - JSON Path Mapping Table 2: Sorting properties - JSON Path Mapping
If the "sort" parameter reports an allowed sorting property, it MUST 2.3.2. Representing Sorting Links
be provided in the "currentSort" field of the "sorting_metadata"
structure.
https://example.com/rdap/domains?name=*nr.com&sort=ldhName
https://example.com/rdap/domains?name=*nr.com&sort=registrationDate:d
https://example.com/rdap/domains?name=*nr.com&sort=lockedDate,ldhName
Figure 3: Examples of RDAP query reporting the "sort" parameter
2.3.1. Representing Sorting Links
An RDAP server MAY use the "links" array of the "sorting_metadata" An RDAP server MAY use the "links" array of the "sorting_metadata"
section to provide ready-made references [RFC8288] to the available element to provide ready-made references [RFC8288] to the available
sort criteria (Figure 4). Each link represents a reference to an sort criteria (Figure 4). Each link represents a reference to an
alternate view of the results. alternate view of the results.
{ {
"rdapConformance": [ "rdapConformance": [
"rdap_level_0", "rdap_level_0",
"sorting_level_0" "sorting_level_0"
], ],
... ...
"sorting_metadata": { "sorting_metadata": {
"currentSort": "ldhName", "currentSort": "ldhName",
"availableSorts": [ "availableSorts": [
{
"property": "registrationDate",
"jsonPath": "$.domainSearchResults[*].events[?(@.eventAction==\"registration\")].eventDate",
"default": false,
"links": [
{
"value": "https://example.com/rdap/domains?name=*nr.com
&sort=ldhName",
"rel": "alternate",
"href": "https://example.com/rdap/domains?name=*nr.com
&sort=registrationDate",
"title": "Result Ascending Sort Link",
"type": "application/rdap+json"
},
{ {
"value": "https://example.com/rdap/domains?name=*nr.com "property": "registrationDate",
&sort=ldhName", "jsonPath": "$.domainSearchResults[*]
"rel": "alternate", .events[?(@.eventAction==\"registration\")].eventDate",
"href": "https://example.com/rdap/domains?name=*nr.com "default": false,
&sort=registrationDate:d", "links": [
"title": "Result Descending Sort Link", {
"type": "application/rdap+json" "value": "https://example.com/rdap/domains?name=*nr.com
} &sort=ldhName",
"rel": "alternate",
"href": "https://example.com/rdap/domains?name=*nr.com
&sort=registrationDate",
"title": "Result Ascending Sort Link",
"type": "application/rdap+json"
},
{
"value": "https://example.com/rdap/domains?name=*nr.com
&sort=ldhName",
"rel": "alternate",
"href": "https://example.com/rdap/domains?name=*nr.com
&sort=registrationDate:d",
"title": "Result Descending Sort Link",
"type": "application/rdap+json"
}
]
},
"domainSearchResults": [
...
] ]
}, }
"domainSearchResults": [
...
]
}
Figure 4: Example of a "sorting_metadata" instance to implement Figure 4: Example of a "sorting_metadata" instance to implement
result sorting result sorting
2.4. "limit" and "offset" Parameters 2.4. "cursor" Parameter
An RDAP query could return a response with hundreds of objects, An RDAP query could return a response with hundreds, even thousands,
especially when partial matching is used. For that reason, two of objects, especially when partial matching is used. For that
parameters addressing result pagination are defined to make responses reason, the cursor parameter addressing result pagination is defined
easier to handle: to make responses easier to handle.
o "limit": means that the server MUST return the first N objects of Using limit and offset operators represents the most common way to
the result set in the response; implement results pagination. Both of them can be used individually:
o "offset": means that the server MUST skip the first N objects and
MUST return objects starting from position N+1.
The ABNF syntax is the following: o "limit": means that the server must return the first N objects of
the result set;
EQ = "=" o "offset": means that the server must skip the first N objects and
limit = "limit" EQ positive-number must return objects starting from position N+1.
offset = "offset" EQ positive-number
positive-number = non-zero-digit *digit
non-zero-digit = "1" / "2" / "3" / "4" / "5" / "6" / "7" / "8" /
"9"
digit = "0" / non-zero-digit
When limit and offset are used together, they allow implementation of When limit and offset are used together, they allow to identify a
result pagination. The following examples illustrate requests to specific portion of the result set. For example, the pair
return, respectively, the first 5 objects, the set of objects "offset=100,limit=50" returns first 50 objects starting from position
starting from position 6, and first 5 objects starting from position 101 of the result set.
11 of the result set (Figure 5).
https://example.com/rdap/domains?name=*nr.com&limit=5 However, offset pagination raises some well known drawbacks:
https://example.com/rdap/domains?name=*nr.com&offset=5 o when offset has a very high value, scrolling the result set could
take some time;
https://example.com/rdap/domains?name=*nr.com&limit=5&offset=10 o it always requires to fetch all the rows before dropping as many
rows as specified by offset;
Figure 5: Examples of RDAP query reporting the "limit" and "offset" o it may return inconsistent pages when data are frequently updated
parameters (i.e. real-time data) but this doesn't seem the case of
registration data.
2.4.1. Representing Offset Pagination Links An alternative approach to offset pagination is keyset pagination
[SEEK] which consists in adding a query condition that enables the
seletion 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 (e.g.
[CURSOR-API1],[CURSOR-API2]). The cursor is an opaque URL-safe
string representing a logical pointer to the first result of the next
page (Figure 5). Basically, the cursor is the encryption of the key
value identifying the last row of the current page. For example, the
cursor value "a2V5PXRoZWxhc3Rkb21haW5vZnRoZXBhZ2UuY29t=" is the mere
Base64 encoding of "key=thelastdomainofthepage.com".
An RDAP server SHOULD use the "links" array of the "paging_metadata" The ABNF syntax is the following:
element to provide a ready-made reference [RFC8288] to the next page
of the result set (Figure 6). Examples of additional "rel" values a
server MAY implements are "first", "last", "prev".
{ cursor = "cursor=" ( ALPHA / DIGIT / "/" / "=" / "-" / "_" )
"rdapConformance": [
"rdap_level_0",
"paging_level_0"
],
...
"notices": [
{
"title": "Search query limits",
"type": "result set truncated due to excessive load",
"description": [
"search results for domains are limited to 10"
]
}
],
"paging_metadata": {
"totalCount": 73,
"pageCount": 10,
"links": [
{
"value": "https://example.com/rdap/domains?name=*nr.com",
"rel": "next",
"href": "https://example.com/rdap/domains?name=*nr.com&limit=10
&offset=10",
"title": "Result Pagination Link",
"type": "application/rdap+json"
}
]
},
"domainSearchResults": [
...
]
}
Figure 6: Example of a "paging_metadata" instance to implement result https://example.com/rdap/domains?name=*nr.com
pagination based on offset and limit &cursor=wJlCDLIl6KTWypN7T6vc6nWEmEYe99Hjf1XY1xmqV-M=
2.5. "cursor" Parameter Figure 5: An example of RDAP query reporting the "cursor" parameter
The use of limit and offset operators represents the most common way Nevertheless, even cursor pagination can be troublesome:
to implement results pagination. However, when offset has a very
high value, scrolling the result set could take some time. In
addition, offset pagination may return inconsistent pages when data
are frequently updated (i.e. real-time data) but this is not the case
of registration data. An alternative approach to offset pagination
is the keyset pagination, a.k.a. seek-method [SEEK] or cursor
pagination. This method has been taken as the basis for the
implementation of a "cursor" parameter [CURSOR] by some REST API
providers (e.g. [CURSOR-API1],[CURSOR-API2]). The cursor is an
opaque URL-safe string representing a logical pointer to the first
result of the next page (Figure 7).
https://example.com/rdap/domains?name=*nr.com&cursor=wJlCDLIl6KTWypN7T6vc6nWEmEYe99Hjf1XY1xmqV-M= o it needs at least one key field;
Figure 7: An example of RDAP query reporting the "cursor" parameter o it does not allow to sort just by any field because the sorting
criterion must contain a key;
However cursor pagination raises some drawbacks with respect to o it works best with full composite values support by DBMS (i.e.
offset pagination: [x,y]>[a,b]), emulation is possible but ugly and less performant;
o it needs at least one key field; o it does not allow to directly navigate to arbitrary pages because
o it does not allow to sort by any field and paginate the results the result set must be scrolled in sequential order starting from
because sorting has to be made on the key field; the initial page;
o it does not allow to skip pages because they have to be scrolled
in sequential order starting from the initial page; o implementing the bi-directional navigation is tedious because all
o it makes very hard the navigation of the result set in both comparison and sort operations have to be reversed.
directions because all comparison and sort operations have to be
reversed.
Furthermore, in the RDAP context, some additional considerations can Furthermore, in the RDAP context, some additional considerations can
be made: be made:
o an RDAP object is a conceptual aggregation of information o an RDAP object is a conceptual aggregation of information
collected from more than one data structure (e.g. table) and this generally collected from more than one data structure (e.g. table)
makes even harder for the developers the implementation of the and this makes even harder for the developers the implementation
seek-method that is already quite difficult. In fact, for of the keyset pagination that is already quite difficult. For
example, the entity object can gather information from different example, the entity object can gather information from different
data structures (registrars, registrants, contacts, resellers, and data structures (registrars, registrants, contacts, resellers, and
so on), each one with its own key field mapping the RDAP entity so on), each one with its own key field mapping the RDAP entity
handle; handle;
o depending on the number of the page results as well as the number o depending on the number of the page results as well as the number
and the complexity of the properties of each RDAP object in the and the complexity of the properties of each RDAP object in the
response, the time required by offset pagination to skip the response, the time required by offset pagination to skip the
previous pages could be much faster than the processing time previous pages could be much faster than the processing time
needed to build the current page. In fact, RDAP objects are needed to build the current page. In fact, RDAP objects are
usually formed by information belonging to multiple data usually formed by information belonging to multiple data
structures and containing multivalued properties (i.e. arrays) structures and containing multivalued properties (i.e. arrays)
and, therefore, data selection is a time consuming process. This and, therefore, data selection might be a time consuming process.
situation occurs even though the data selection process makes use This situation occurs even though the selection is supported by
of indexes; indexes;
o depending on the access levels defined by each RDAP operator, the o depending on the access levels defined by each RDAP operator, the
increase of complexity and the decrease of flexibility of cursor increase of complexity and the decrease of flexibility of cursor
pagination with respect to the offset pagination could be pagination with respect to the offset pagination could be
considered impractical. considered impractical.
Finally, the cursor pagination seems to be a bit inconsistent with
some capabilities described in this document like sorting and the
implementation of paging links other than the usual "next page" link.
But, while the provisioning of more paging links can be superfluous,
dropping the sorting capability seems quite unreasonable.
Ultimately, both pagination methods have benefits and drawbacks. Ultimately, both pagination methods have benefits and drawbacks.
Therefore, since the "paging_metadata" element keeps the same That said, the cursor parameter can be used not only to encode the
structure and clients merely make use of the paging links as they are key value but also the information about offset pagination. For
provided, this RDAP specification lets operators to implement a example, the cursor value "b2Zmc2V0PTEwMCxsaW1pdD01MAo=" is the mere
method according to their needs, the user access levels, the Base64 encoding of "offset=100,limit=50". This solution lets RDAP
submitted queries. providers to implement a pagination method according to their needs,
the user access levels, the submitted queries. In addition, servers
can change the method over time without announcing anything to the
clients.
2.5.1. Representing Cursor Pagination Links 2.4.1. Representing Paging Links
The same considerations made for offset pagination links are applied An RDAP server SHOULD use the "links" array of the "paging_metadata"
to cursor pagination links (Figure 8). element to provide a ready-made reference [RFC8288] to the next page
of the result set (Figure 6). Examples of additional "rel" values a
server MAY implements are "first", "last", "prev".
{ {
"rdapConformance": [ "rdapConformance": [
"rdap_level_0", "rdap_level_0",
"paging_level_0" "paging_level_0"
], ],
... ...
"notices": [ "notices": [
{ {
"title": "Search query limits", "title": "Search query limits",
skipping to change at page 17, line 39 skipping to change at page 16, line 39
"title": "Result Pagination Link", "title": "Result Pagination Link",
"type": "application/rdap+json" "type": "application/rdap+json"
} }
] ]
}, },
"domainSearchResults": [ "domainSearchResults": [
... ...
] ]
} }
Figure 8: Example of a "paging_metadata" instance to implement cursor Figure 6: Example of a "paging_metadata" instance to implement cursor
pagination pagination
3. Negative Answers 3. Negative Answers
The value constraints for the parameters are defined by their ABNF The value constraints for the parameters are defined by their ABNF
syntax. Therefore, each request providing an invalid value for a syntax. Therefore, each request including an invalid value for a
parameter SHOULD obtain an HTTP 400 (Bad Request) response code. The parameter SHOULD obtain an HTTP 400 (Bad Request) response code. The
same response SHOULD be returned if the client provides an same response SHOULD be returned in the following cases:
unsupported value for the "sort" parameter in both single and multi
sort.
The server can provide a different response when it supports the
"limit" and/or "offset" parameters and the client submits values that
are out of the valid ranges. The possible cases are:
o If the client submits a value for the "limit" parameter that is o if the client provides an unsupported value for the "sort"
greater than the number of objects to be processed, it is parameter in both single and multi sort;
RECOMMENDED that server returns a response including only the
processed objects.
o If the client submits a value for the "offset" parameter that is o if the client submits an invalid value for the "cursor" parameter.
greater than the number of objects to be processed as well as an
invalid value for the "cursor" parameter, it is RECOMMENDED that
server returns an HTTP 404 (Not Found) response code.
Optionally, the response MAY include additional information regarding Optionally, the response MAY include additional information regarding
the negative answer in the HTTP entity body. the negative answer in the HTTP entity body.
4. RDAP Conformance 4. RDAP Conformance
Servers returning the "paging_metadata" element in their responses Servers returning the "paging_metadata" element in their response
MUST include "paging_level_0" in the rdapConformance array as well as MUST include "paging_level_0" in the rdapConformance array as well as
servers returning the "sorting_metadata" element MUST include servers returning the "sorting_metadata" element MUST include
"sorting_level_0". "sorting_level_0".
5. Implementation Considerations 5. Implementation Considerations
The implementation of the new parameters is technically feasible, as The implementation of the new parameters is technically feasible, as
operators for counting, sorting and paging are currently supported by operators for counting, sorting and paging are currently supported by
the major RDBMSs. the major RDBMSs.
In the following, the match between the new defined parameters and Similar operators are completely or partially supported by the most
the SQL operators is shown (Table 3): known NoSQL databases (MongoDB, CouchDB, HBase, Cassandra, Hadoop) so
the implementation of the new parameters seems to be practicable by
+----------------+--------------------------------------------------+ servers working without the use of an RDBMS.
| New query | SQL operator |
| parameter | |
+----------------+--------------------------------------------------+
| count | count(*) query without offset, limit and order |
| | by |
| | [MYSQL-COUNT],[POSTGRES-COUNT],[ORACLE-COUNT] |
| | |
| sort | order by |
| | [MYSQL-SORT],[POSTGRES-SORT],[ORACLE-SORT] |
| | |
| limit | limit n (in MySql [MYSQL-LIMIT] and Postgres |
| | [POSTGRES-LIMIT]) |
| | FETCH FIRST n ROWS ONLY (in Oracle |
| | [ORACLE-LIMIT]) |
| | |
| offset | offset m (in Postgres) |
| | OFFSET m ROWS (in Oracle) |
| | |
| limit + offset | limit n offset m (in MySql and Postgres) |
| | OFFSET m ROWS FETCH NEXT n ROWS ONLY (in Oracle) |
+----------------+--------------------------------------------------+
Table 3: New query parameters vs. SQL operators
With regard to Oracle, Table 3 reports only one of the three methods
that can be used to implement "limit" and "offset" parameters. The
others are described in [ORACLE-ROWNUM] and [ORACLE-ROW-NUMBER].
In addition, similar operators are completely or partially supported Furthermore, both two pagination methods don't require the server to
by the most known NoSQL databases (MongoDB, CouchDB, HBase, handle the result set in a storage area across the requests since a
Cassandra, Hadoop) so the implementation of the new parameters seems new result set is generated each time a request is submitted.
to be practicable by servers working without the use of an RDBMS.
6. Implementation Status 6. Implementation Status
NOTE: Please remove this section and the reference to RFC 7942 prior NOTE: Please remove this section and the reference to RFC 7942 prior
to publication as an RFC. to publication as an RFC.
This section records the status of known implementations of the This section records the status of known implementations of the
protocol defined by this specification at the time of posting of this protocol defined by this specification at the time of posting of this
Internet-Draft, and is based on a proposal described in RFC 7942 Internet-Draft, and is based on a proposal described in RFC 7942
[RFC7942]. The description of implementations in this section is [RFC7942]. The description of implementations in this section is
skipping to change at page 20, line 12 skipping to change at page 18, line 4
Furthermore, no effort has been spent to verify the information Furthermore, no effort has been spent to verify the information
presented here that was supplied by IETF contributors. This is not presented here that was supplied by IETF contributors. This is not
intended as, and must not be construed to be, a catalog of available intended as, and must not be construed to be, a catalog of available
implementations or their features. Readers are advised to note that implementations or their features. Readers are advised to note that
other implementations may exist. other implementations may exist.
According to RFC 7942, "this will allow reviewers and working groups According to RFC 7942, "this will allow reviewers and working groups
to assign due consideration to documents that have the benefit of to assign due consideration to documents that have the benefit of
running code, which may serve as evidence of valuable experimentation running code, which may serve as evidence of valuable experimentation
and feedback that have made the implemented protocols more mature. and feedback that have made the implemented protocols more mature.
It is up to the individual working groups to use this information as It is up to the individual working groups to use this information as
they see fit". they see fit".
6.1. IIT-CNR/Registro.it 6.1. IIT-CNR/Registro.it
Responsible Organization: Institute of Informatics and Telematics Responsible Organization: Institute of Informatics and Telematics
of National Research Council (IIT-CNR)/Registro.it of National Research Council (IIT-CNR)/Registro.it
Location: https://rdap.pubtest.nic.it/ Location: https://rdap.pubtest.nic.it/
Description: This implementation includes support for RDAP queries Description: This implementation includes support for RDAP queries
using data from the public test environment of .it ccTLD. The using data from .it public test environment.
RDAP server implements both offset and cursor pagination (the
latter only when "sort" and "offset" parameters are not present in
the query string).
Level of Maturity: This is a "proof of concept" research Level of Maturity: This is a "proof of concept" research
implementation. implementation.
Coverage: This implementation includes all of the features Coverage: This implementation includes all of the features
described in this specification. described in this specification.
Contact Information: Mario Loffredo, mario.loffredo@iit.cnr.it Contact Information: Mario Loffredo, mario.loffredo@iit.cnr.it
6.2. Google Registry 6.2. Google Registry
Responsible Organization: Google Registry Responsible Organization: Google Registry
Location: https://www.registry.google/rdap/ Location: https://www.registry.google/rdap/
Description: This implementation includes support for RDAP queries Description: This implementation includes support for RDAP queries
for TLDs such as .GOOGLE, .HOW, .SOY, and .xn--q9jyb4c . The RDAP for TLDs such as .google, .how, .soy, and .xn--q9jyb4c . The RDAP
server implements cursor pagination. The link used to request the server implements cursor pagination. The link used to request the
next page is included in the notice section of the response. next page is included in the notice section of the response.
Level of Maturity: Production. Level of Maturity: Production.
Coverage: This implementation includes the "cursor" parameter Coverage: This implementation includes the "cursor" parameter
described in this specification. described in this specification.
Contact Information: Brian Mountford, mountford@google.com Contact Information: Brian Mountford, mountford@google.com
7. Security Considerations 7. IANA Considerations
IANA is requested to register the following values in the RDAP
Extensions Registry:
Extension identifier: paging
Registry operator: Any
Published specification: This document.
Contact: IESG <iesg@ietf.org>
Intended usage: This extension describes a best practice for
result set paging.
Extension identifier: sorting
Registry operator: Any
Published specification: This document.
Contact: IESG <iesg@ietf.org>
Intended usage: This extension describes a best practice for
result set sorting.
8. Security Considerations
Security services for the operations specified in this document are Security services for the operations specified in this document are
described in RFC 7481 [RFC7481]. described in RFC 7481 [RFC7481].
Search query typically requires more server resources (such as Search query typically requires more server resources (such as
memory, CPU cycles, and network bandwidth) when compared to lookup memory, CPU cycles, and network bandwidth) when compared to lookup
query. This increases the risk of server resource exhaustion and query. This increases the risk of server resource exhaustion and
subsequent denial of service due to abuse. This risk can be subsequent denial of service due to abuse. This risk can be
mitigated by either restricting search functionality and limiting the mitigated by either restricting search functionality and limiting the
rate of search requests. Servers can also reduce their load by rate of search requests. Servers can also reduce their load by
truncating the results in the response. However, this last security truncating the results in the response. However, this last security
policy can result in a higher inefficiency if the RDAP server does policy can result in a higher inefficiency if the RDAP server does
not provide any functionality to return the truncated results. not provide any functionality to return the truncated results.
The new parameters presented in this document provide the RDAP The new parameters presented in this document provide the RDAP
operators with a way to implement a secure server without penalizing operators with a way to implement a secure server without penalizing
its efficiency. The "count" parameter gives the user a measure to its efficiency. The "count" parameter gives the user a measure to
evaluate the query precision and, at the same time, return a evaluate the query precision and, at the same time, returns a
significant information. The "sort" parameter allows the user to significant information. The "sort" parameter allows the user to
obtain the most relevant information at the beginning of the result obtain the most relevant information at the beginning of the result
set. In both cases, the user doesn't need to submit further set. In both cases, the user doesn't need to submit further
unnecessary search requests. Finally, the "limit" and "offset" unnecessary search requests. Finally, the "cursor" parameter enables
parameters enable the user to scroll the result set by submitting a the user to scroll the result set by submitting a sequence of
sequence of sustainable queries according to the server limits. sustainable queries according to the server limits.
8. IANA Considerations
This document has no actions for IANA.
9. Acknowledgements 9. Acknowledgements
The authors would like to acknowledge Brian Mountford for his The authors would like to acknowledge Brian Mountford for his
contribution to the development of this document. contribution to the development of this document.
10. References 10. References
10.1. Normative References 10.1. Normative References
skipping to change at page 23, line 23 skipping to change at page 21, line 29
pagination.html>. pagination.html>.
[GOESSNER-JSON-PATH] [GOESSNER-JSON-PATH]
Goessner, S., "JSONPath - XPath for JSON", 2007, Goessner, S., "JSONPath - XPath for JSON", 2007,
<http://goessner.net/articles/JsonPath/>. <http://goessner.net/articles/JsonPath/>.
[HATEOAS] Jedrzejewski, B., "HATEOAS - a simple explanation", 2018, [HATEOAS] Jedrzejewski, B., "HATEOAS - a simple explanation", 2018,
<https://www.e4developer.com/2018/02/16/ <https://www.e4developer.com/2018/02/16/
hateoas-simple-explanation/>. hateoas-simple-explanation/>.
[MYSQL-COUNT]
mysql.com, "MySQL 5.7 Reference Manual, Counting Rows",
October 2015, <https://dev.mysql.com/doc/refman/5.7/en/
counting-rows.html>.
[MYSQL-LIMIT]
mysql.com, "MySQL 5.7 Reference Manual, SELECT Syntax",
October 2015,
<https://dev.mysql.com/doc/refman/5.7/en/select.html>.
[MYSQL-SORT]
mysql.com, "MySQL 5.7 Reference Manual, Sorting Rows",
October 2015, <https://dev.mysql.com/doc/refman/5.7/en/
sorting-rows.html>.
[OData-Part1] [OData-Part1]
Pizzo, M., Handl, R., and M. Zurmuehl, "OData Version 4.0. Pizzo, M., Handl, R., and M. Zurmuehl, "OData Version 4.0.
Part 1: Protocol Plus Errata 03", June 2016, Part 1: Protocol Plus Errata 03", June 2016,
<http://docs.oasis- <http://docs.oasis-
open.org/odata/odata/v4.0/errata03/os/complete/part1- open.org/odata/odata/v4.0/errata03/os/complete/part1-
protocol/ protocol/
odata-v4.0-errata03-os-part1-protocol-complete.pdf>. odata-v4.0-errata03-os-part1-protocol-complete.pdf>.
[ORACLE-COUNT]
Oracle Corporation, "Database SQL Language Reference,
COUNT", March 2016,
<http://docs.oracle.com/database/122/SQLRF/COUNT.htm>.
[ORACLE-LIMIT]
Oracle Corporation, "Database SQL Language Reference,
SELECT, Row limiting clause", March 2016,
<http://docs.oracle.com/database/122/SQLRF/SELECT.htm>.
[ORACLE-ROW-NUMBER]
Oracle Corporation, "Database SQL Language Reference,
SELECT, ROW_NUMBER", March 2016,
<http://docs.oracle.com/database/122/SQLRF/
ROW_NUMBER.htm#SQLRF06100>.
[ORACLE-ROWNUM]
Oracle Corporation, "Database SQL Language Reference,
SELECT, ROWNUM Pseudocolumn", March 2016,
<http://docs.oracle.com/database/122/SQLRF/
ROWNUM-Pseudocolumn.htm#SQLRF00255>.
[ORACLE-SORT]
Oracle Corporation, "Database SQL Language Reference,
SELECT, Order by clause", March 2016,
<http://docs.oracle.com/database/122/SQLRF/SELECT.htm>.
[POSTGRES-COUNT]
postgresql.org, "PostgresSQL, Aggregate Functions",
September 2016,
<https://www.postgresql.org/docs/9.6/static/
functions-aggregate.html>.
[POSTGRES-LIMIT]
postgresql.org, "PostgresSQL, LIMIT and OFFSET", September
2016, <https://www.postgresql.org/docs/9.6/static/
queries-limit.html>.
[POSTGRES-SORT]
postgresql.org, "PostgresSQL, Sorting Rows", September
2016, <https://www.postgresql.org/docs/9.6/static/
queries-order.html>.
[REST] Fredrich, T., "RESTful Service Best Practices, [REST] Fredrich, T., "RESTful Service Best Practices,
Recommendations for Creating Web Services", April 2012, Recommendations for Creating Web Services", April 2012,
<http://www.restapitutorial.com/media/ <http://www.restapitutorial.com/media/
RESTful_Best_Practices-v1_1.pdf>. RESTful_Best_Practices-v1_1.pdf>.
[RFC6901] Bryan, P., Ed., Zyp, K., and M. Nottingham, Ed., [RFC6901] Bryan, P., Ed., Zyp, K., and M. Nottingham, Ed.,
"JavaScript Object Notation (JSON) Pointer", RFC 6901, "JavaScript Object Notation (JSON) Pointer", RFC 6901,
DOI 10.17487/RFC6901, April 2013, DOI 10.17487/RFC6901, April 2013,
<https://www.rfc-editor.org/info/rfc6901>. <https://www.rfc-editor.org/info/rfc6901>.
skipping to change at page 25, line 31 skipping to change at page 22, line 26
Appendix A. Change Log Appendix A. Change Log
00: Initial working group version ported from draft-loffredo-regext- 00: Initial working group version ported from draft-loffredo-regext-
rdap-sorting-and-paging-05 rdap-sorting-and-paging-05
01: Removed both "offset" and "nextOffset" to keep "paging_metadata" 01: Removed both "offset" and "nextOffset" to keep "paging_metadata"
consistent between the pagination methods. Renamed consistent between the pagination methods. Renamed
"Considerations about Paging Implementation" section in ""cursor" "Considerations about Paging Implementation" section in ""cursor"
Parameter". Removed "FOR DISCUSSION" items. Provided a more Parameter". Removed "FOR DISCUSSION" items. Provided a more
detailed description of both "sorting_metadata" and detailed description of both "sorting_metadata" and
"paging_metadata" objects. "paging_metadata" objects.
02: Removed both "offset" and "limit" parameters. Added ABNF syntax
of cursor parameter. Rearranged the layout of some sections.
Removed some items from "Informative References" section. Changed
"IANA Considerations" section.
Authors' Addresses Authors' Addresses
Mario Loffredo Mario Loffredo
IIT-CNR/Registro.it IIT-CNR/Registro.it
Via Moruzzi,1 Via Moruzzi,1
Pisa 56124 Pisa 56124
IT IT
Email: mario.loffredo@iit.cnr.it Email: mario.loffredo@iit.cnr.it
 End of changes. 71 change blocks. 
350 lines changed or deleted 222 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/