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/