draft-ietf-regext-rdap-sorting-and-paging-10.txt		draft-ietf-regext-rdap-sorting-and-paging-11.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 16, 2020 S. Hollenbeck		Expires: October 18, 2020 S. Hollenbeck
	Verisign Labs		Verisign Labs
	April 14, 2020		April 16, 2020
	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-10		draft-ietf-regext-rdap-sorting-and-paging-11
	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 large		can provide servers with their preferences for managing large
	responses. This document describes RDAP query extensions that allow		responses. This document describes RDAP query extensions that allow
	skipping to change at page 1, line 41 ¶		skipping to change at page 1, line 41 ¶
	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 16, 2020.		This Internet-Draft will expire on October 18, 2020.
	Copyright Notice		Copyright Notice
	Copyright (c) 2020 IETF Trust and the persons identified as the		Copyright (c) 2020 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 36 ¶		skipping to change at page 2, line 36 ¶
	4. Implementation Considerations . . . . . . . . . . . . . . . . 17		4. Implementation Considerations . . . . . . . . . . . . . . . . 17
	5. Implementation Status . . . . . . . . . . . . . . . . . . . . 17		5. Implementation Status . . . . . . . . . . . . . . . . . . . . 17
	5.1. IIT-CNR/Registro.it . . . . . . . . . . . . . . . . . . . 17		5.1. IIT-CNR/Registro.it . . . . . . . . . . . . . . . . . . . 17
	5.2. APNIC . . . . . . . . . . . . . . . . . . . . . . . . . . 18		5.2. APNIC . . . . . . . . . . . . . . . . . . . . . . . . . . 18
	6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18		6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
	7. Security Considerations . . . . . . . . . . . . . . . . . . . 18		7. Security Considerations . . . . . . . . . . . . . . . . . . . 18
	8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19		8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19
	9. References . . . . . . . . . . . . . . . . . . . . . . . . . 19		9. References . . . . . . . . . . . . . . . . . . . . . . . . . 19
	9.1. Normative References . . . . . . . . . . . . . . . . . . 19		9.1. Normative References . . . . . . . . . . . . . . . . . . 19
	9.2. Informative References . . . . . . . . . . . . . . . . . 21		9.2. Informative References . . . . . . . . . . . . . . . . . 21
	Appendix A. Approaches to Result Pagination . . . . . . . . . . 22		Appendix A. JSONPath operators . . . . . . . . . . . . . . . . . 22
	A.1. Specific Issues Raised by RDAP . . . . . . . . . . . . . 23		Appendix B. Approaches to Result Pagination . . . . . . . . . . 23
	Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 24		B.1. Specific Issues Raised by RDAP . . . . . . . . . . . . . 24
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25		Appendix C. Change Log . . . . . . . . . . . . . . . . . . . . . 25
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26
	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 5, line 17 ¶		skipping to change at page 5, line 19 ¶
	by default, if any;		by default, if any;
	o "availableSorts": "AvailableSort[]" (OPTIONAL) an array of objects		o "availableSorts": "AvailableSort[]" (OPTIONAL) an array of objects
	each one describing an alternate available sorting criterion.		each one describing an alternate available sorting criterion.
	Members are:		Members are:
	* "property": "String" (REQUIRED) the name that can be used by		* "property": "String" (REQUIRED) the name that can be used by
	the client to request the sorting criterion;		the client to request the sorting criterion;
	* "default": "Boolean" (REQUIRED) whether the sorting criterion		* "default": "Boolean" (REQUIRED) whether the sorting criterion
	is applied by default;		is applied by default;
	* "jsonPath": "String" (OPTIONAL) the JSON Path of the RDAP field		* "jsonPath": "String" (OPTIONAL) the JSONPath of the RDAP field
	corresponding to the property;		corresponding to the property;
	* "links": "Link[]" (OPTIONAL) an array of links as described in		* "links": "Link[]" (OPTIONAL) an array of links as described in
	RFC 8288 [RFC8288] containing the query string that applies the		RFC 8288 [RFC8288] containing the query string that applies the
	sorting criterion.		sorting criterion.
	At least one between "currentSort" and "availableSorts" MUST be		At least one between "currentSort" and "availableSorts" MUST be
	present.		present.
	The "paging_metadata" element contains the following fields:		The "paging_metadata" element contains the following fields:
	skipping to change at page 8, line 20 ¶		skipping to change at page 8, line 20 ¶
	based on their numeric conversion.		based on their numeric conversion.
	If the "sort" parameter reports an allowed sorting property, it MUST		If the "sort" parameter reports an allowed sorting property, it MUST
	be provided in the "currentSort" field of the "sorting_metadata"		be provided in the "currentSort" field of the "sorting_metadata"
	element.		element.
	2.3.1. Sorting Properties Declaration		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 JSONPath. The JSONPath 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 JSONPath to select the value of the
	ASCII name inside an RDAP domain object is "$.ldhName", whereby $		ASCII name inside an RDAP domain object is "$.ldhName", whereby $
	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		JSONPath 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.
	"$.events[?(@.eventAction='registration')].eventDate" is the JSON		"$.events[?(@.eventAction='registration')].eventDate" is the JSONPath
	Path expression of the registration date in an RDAP domain object).		expression of the registration date in an RDAP domain object).
	Therefore, this specification provides a definition of property-ref		Therefore, this specification provides a definition of property-ref
	in terms of RDAP properties. However, not all the RDAP properties		in terms of RDAP properties. However, not all the RDAP properties
	are suitable to be used in sort criteria, such as:		are suitable to be used in sort criteria, such as:
	o properties providing service information (e.g. links, notices,		o properties providing service information (e.g. links, notices,
	remarks, etc.);		remarks, etc.);
	o multivalued properties (e.g. status, roles, variants, etc.);		o multivalued properties (e.g. status, roles, variants, etc.);
	skipping to change at page 11, line 25 ¶		skipping to change at page 11, line 25 ¶
	than one value is reported, sorting MUST be applied to the		than one value is reported, sorting MUST be applied to the
	preferred value identified by the parameter pref="1". If the pref		preferred value identified by the parameter pref="1". If the pref
	parameter is missing, sorting MUST be applied to the first value.		parameter is missing, sorting MUST be applied to the first value.
	Each RDAP provider MAY define other sorting properties than those		Each RDAP provider MAY define other sorting properties than those
	shown in this document as well as it MAY map those sorting properties		shown in this document as well as it MAY map those sorting properties
	onto different locations.		onto different locations.
	The "jsonPath" field in the "sorting_metadata" element is used to		The "jsonPath" field in the "sorting_metadata" element is used to
	clarify the RDAP field the sorting property refers to. The mapping		clarify the RDAP field the sorting property refers to. The mapping
	between the sorting properties and the JSON Paths of the RDAP fields		between the sorting properties and the JSONPaths of the RDAP fields
	is shown in Table 2. The JSON Paths are provided according to the		is shown in Table 2. The JSONPaths are provided according to the
	Goessner v.0.8.0 specification ([GOESSNER-JSON-PATH]).		Goessner v.0.8.0 specification ([GOESSNER-JSON-PATH]). Further
			documentation about JSONPath operators used in Table 2 is included in
			Appendix A.
	+-------+-------------+---------------------------------------------+		+-------+-------------+---------------------------------------------+
	| Objec | Sorting | JSON Path |		| Objec | Sorting | JSONPath |
	| t | property | |		| t | property | |
	| class | | |		| class | | |
	+-------+-------------+---------------------------------------------+		+-------+-------------+---------------------------------------------+
	| Searc | registratio | $.domainSearchResults[*].events[?(@.eventAc |		| Searc | registratio | $.domainSearchResults[*].events[?(@.eventAc |
	| hable | nDate | tion=="registration")].eventDate |		| hable | nDate | tion=="registration")].eventDate |
	| objec | | |		| objec | | |
	| ts | | |		| ts | | |
	| | reregistrat | $.domainSearchResults[*].events[?(@.eventAc |		| | reregistrat | $.domainSearchResults[*].events[?(@.eventAc |
	| | ionDate | tion=="reregistration")].eventDate |		| | ionDate | tion=="reregistration")].eventDate |
	| | lastChanged | $.domainSearchResults[*].events[?(@.eventAc |		| | lastChanged | $.domainSearchResults[*].events[?(@.eventAc |
	skipping to change at page 12, line 34 ¶		skipping to change at page 12, line 36 ¶
	| | 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] |
	| | cc | $.entitySearchResults[*].vcardArray[1][?(@[ |		| | cc | $.entitySearchResults[*].vcardArray[1][?(@[ |
	| | | 0]=="adr")][1].cc |		| | | 0]=="adr")][1].cc |
	| | 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 - JSONPath Mapping
	Note about the JSON Paths of Table 2 that:		Note about the JSONPaths of Table 2 that:
	o those related to the event dates are defined only for the "domain"		o those related to the event dates are defined only for the "domain"
	object. To obtain the equivalent JSON Paths for "entity" and		object. To obtain the equivalent JSONPaths for "entity" and
	"nameserver", the path segment "domainSearchResults" must be		"nameserver", the path segment "domainSearchResults" must be
	replaced with "entitySearchResults" and "nameserverSearchResults"		replaced with "entitySearchResults" and "nameserverSearchResults"
	respectively;		respectively;
	o those related to vCard elements are specified without taking into		o those related to vCard elements are specified without taking into
	account the "pref" parameter. Servers always applying sorting to		account the "pref" parameter. Servers always applying sorting to
	those values identified by the pref parameter SHOULD update a JSON		those values identified by the pref parameter SHOULD update a
	Path by adding an appropriate filter. For example, if the email		JSONPath by adding an appropriate filter. For example, if the
	values identified by pref="1" are considered for sorting, the JSON		email values identified by pref="1" are considered for sorting,
	Path of the "email" sorting property should be:		the JSONPath of the "email" sorting property should be:
	$.entitySearchResults[*].vcardArray[1][?(@[0]=="email" &&		$.entitySearchResults[*].vcardArray[1][?(@[0]=="email" &&
	@[1].pref=="1")][3]		@[1].pref=="1")][3]
	2.3.2. Representing Sorting Links		2.3.2. 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"
	element 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.
	skipping to change at page 15, line 22 ¶		skipping to change at page 15, line 22 ¶
	"offset=100,limit=50". Likewise, in a simple implementation to		"offset=100,limit=50". Likewise, in a simple implementation to
	represent keyset pagination information, the cursor value		represent keyset pagination information, the cursor value
	"a2V5PXRoZWxhc3Rkb21haW5vZnRoZXBhZ2UuY29t=" represents the mere		"a2V5PXRoZWxhc3Rkb21haW5vZnRoZXBhZ2UuY29t=" represents the mere
	Base64 encoding of "key=thelastdomainofthepage.com" whereby the key		Base64 encoding of "key=thelastdomainofthepage.com" whereby the key
	value identifies the last row of the current page.		value identifies the last row of the current page.
	This solution lets RDAP providers to implement a pagination method		This solution lets RDAP providers to implement a pagination method
	according to their needs, the user access levels, the submitted		according to their needs, the user access levels, the submitted
	queries. In addition, servers can change the method over time		queries. In addition, servers can change the method over time
	without announcing anything to the clients. The considerations that		without announcing anything to the clients. The considerations that
	has led to this solution are reported in more detail in Appendix A.		has led to this solution are reported in more detail in Appendix B.
	The ABNF syntax of the cursor paramter is the following:		The ABNF syntax of the cursor paramter is the following:
	cursor = "cursor=" 1*( ALPHA / DIGIT / "/" / "=" / "-" / "_" )		cursor = "cursor=" 1*( ALPHA / DIGIT / "/" / "=" / "-" / "_" )
	https://example.com/rdap/domains?name=*nr.com		https://example.com/rdap/domains?name=*nr.com
	&cursor=wJlCDLIl6KTWypN7T6vc6nWEmEYe99Hjf1XY1xmqV-M=		&cursor=wJlCDLIl6KTWypN7T6vc6nWEmEYe99Hjf1XY1xmqV-M=
	Figure 5: An example of RDAP query reporting the "cursor" parameter		Figure 5: An example of RDAP query reporting the "cursor" parameter
	skipping to change at page 22, line 5 ¶		skipping to change at page 22, line 5 ¶
	[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>.
	[SEEK] EverSQL.com, "Faster Pagination in Mysql - Why Order By		[SEEK] EverSQL.com, "Faster Pagination in Mysql - Why Order By
	With Limit and Offset is Slow?", July 2017,		With Limit and Offset is Slow?", July 2017,
	<https://www.eversql.com/faster-pagination-in-mysql-why-		<https://www.eversql.com/faster-pagination-in-mysql-why-
	order-by-with-limit-and-offset-is-slow/>.		order-by-with-limit-and-offset-is-slow/>.
	Appendix A. Approaches to Result Pagination		Appendix A. JSONPath operators
			A JSONPath expression represents a path to find an element (or a set
			of elements) in a JSON content.
			The base JSONPath specification requires that implementations support
			a set of "basic operators". These operators are used to access the
			elements of a JSON structure like objects and arrays, and their
			subelements, respectively, object members and array items. No
			operations are defined for retrieving parent or sibling elements of a
			given element. The root element is always referred to as $
			regardless if it is an object or array.
			Additionally, the specification permits implementations to support
			arbitrary script expressions: these can be used to index into an
			object or an array, or to filter elements from an array. While
			script expression behaviour is implementation-defined, most
			implementations support the basic relational and logical operators,
			as well as both object member and array item access, sufficiently
			similarly for the purposes of this document. Commonly-supported
			operators/functions are documented in Table 3.
			+-------------------+-----------------------------------------------+
			| Operator | Descritpion |
			+-------------------+-----------------------------------------------+
			| $ | Root element |
			| .<name> | Object member access |
			| [<number>] | Array item access |
			| * | All elements within the specified scope |
			| [?(<expression>)] | Filter expression |
			| @ | The current element being processed by a |
			| | filter predicate |
			| == | Left is equal to right |
			| != | Left is not equal to right |
			| < | Left is less than right |
			| <= | Left is less than or equal to right |
			| > | Left is greater than right |
			| >= | Left is greater than or equal to right |
			| && | Logical conjunction |
			| || | Logical disjunction |
			+-------------------+-----------------------------------------------+
			Table 3: JSONPath Operators
			Appendix B. Approaches to Result Pagination
	An RDAP query could return a response with hundreds, even thousands,		An RDAP query could return a response with hundreds, even thousands,
	of objects, especially when partial matching is used. For that		of objects, especially when partial matching is used. For that
	reason, the cursor parameter addressing result pagination is defined		reason, the cursor parameter addressing result pagination is defined
	to make responses easier to handle.		to make responses easier to handle.
	Presently, the most popular methods to implement pagination in REST		Presently, the most popular methods to implement pagination in REST
	API are: offset pagination and keyset pagination. Both two		API are: offset pagination and keyset pagination. Both two
	pagination methods don't require the server to handle the result set		pagination methods don't require the server to handle the result set
	in a storage area across the requests since a new result set is		in a storage area across the requests since a new result set is
	skipping to change at page 23, line 24 ¶		skipping to change at page 24, line 24 ¶
	o it works best with full composite values support by DBMS (i.e.		o it works best with full composite values support by DBMS (i.e.
	[x,y]>[a,b]), emulation is possible but ugly and less performant;		[x,y]>[a,b]), emulation is possible but ugly and less performant;
	o it does not allow to directly navigate to arbitrary pages because		o it does not allow to directly navigate to arbitrary pages because
	the result set must be scrolled in sequential order starting from		the result set must be scrolled in sequential order starting from
	the initial page;		the initial page;
	o implementing the bi-directional navigation is tedious because all		o implementing the bi-directional navigation is tedious because all
	comparison and sort operations have to be reversed.		comparison and sort operations have to be reversed.
	A.1. Specific Issues Raised by RDAP		B.1. Specific Issues Raised by RDAP
	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
	generally collected from more than one data structure (e.g. table)		generally collected from more than one data structure (e.g. table)
	and this makes even harder for the developers the implementation		and this makes even harder for the developers the implementation
	of the keyset pagination that is already quite difficult. 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
	skipping to change at page 24, line 9 ¶		skipping to change at page 25, line 9 ¶
	This situation occurs even though the selection is supported by		This situation occurs even though the selection is supported by
	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 keyset		increase of complexity and the decrease of flexibility of keyset
	pagination with respect to the offset pagination could be		pagination with respect to the offset pagination could be
	considered impractical.		considered impractical.
	Ultimately, both pagination methods have benefits and drawbacks.		Ultimately, both pagination methods have benefits and drawbacks.
	Appendix B. Change Log		Appendix C. 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		02: Removed both "offset" and "limit" parameters. Added ABNF syntax
	skipping to change at page 24, line 36 ¶		skipping to change at page 25, line 36 ¶
	04: Replaced "ldhName" with "name" in the "Sorting Properties		04: Replaced "ldhName" with "name" in the "Sorting Properties
	Declaration" section. Clarified the sorting logic with respect to		Declaration" section. Clarified the sorting logic with respect to
	the JSON value types and the sorting policy for multivalued		the JSON value types and the sorting policy for multivalued
	fields.		fields.
	05: Clarified the logic of sorting on IP addresses. Clarified the		05: Clarified the logic of sorting on IP addresses. Clarified the
	mapping between the sorting properties and the RDAP fields.		mapping between the sorting properties and the RDAP fields.
	Updated "Acknowledgements" section.		Updated "Acknowledgements" section.
	06: Renamed "pageCount" to "pageSize" and added "pageNumber" in the		06: Renamed "pageCount" to "pageSize" and added "pageNumber" in the
	"paging_metadata" object.		"paging_metadata" object.
	07: Added "Paging Responses to POST Requests" section.		07: Added "Paging Responses to POST Requests" section.
	08: Added "Approaches to Result Pagination" section to the appendix.		08: Added "Approaches to Result Pagination" section to appendix.
	Added the case of requesting a sort on a property not included in		Added the case of requesting a sort on a property not included in
	the response to the errors listed in the "Negative Answers"		the response to the errors listed in the "Negative Answers"
	section.		section.
	09: Updated the "Implementation Status" section to include APNIC		09: Updated the "Implementation Status" section to include APNIC
	implementation. Moved the "RDAP Conformance" section up in the		implementation. Moved the "RDAP Conformance" section up in the
	document. Removed the "Paging Responses to POST Requests"		document. Removed the "Paging Responses to POST Requests"
	section. Updated the "Acknowledgements" section. Removed unused		section. Updated the "Acknowledgements" section. Removed unused
	references. In the "Sorting Properties Declaration" section:		references. In the "Sorting Properties Declaration" section:
	* clarified the logic of sorting on events;		* clarified the logic of sorting on events;
	* corrected the JSON Path of the "lastChanged" sorting property;		* corrected the JSONPath of the "lastChanged" sorting property;
	* provided a JSON Path example taking into account the vCard		* provided a JSONPath example taking into account the vCard
	"pref" parameter.		"pref" parameter.
	10: Corrected the JSON Paths of both "fn" and "org" sorting		10: Corrected the JSONPaths of both "fn" and "org" sorting
	properties in Table 2. Corrected JSON content in Figure 4. Moved		properties in Table 2. Corrected JSON content in Figure 4. Moved
	[W3C.CR-xpath-31-20161213] and [RFC7942] to the "Normative		[W3C.CR-xpath-31-20161213] and [RFC7942] to the "Normative
	References". Changed the rdapConformance tags "sorting_level_0"		References". Changed the rdapConformance tags "sorting_level_0"
	and "paging_level_0" to "sorting" and "paging" respectively.		and "paging_level_0" to "sorting" and "paging" respectively.
			11: Added the "JSONPath operators" section to appendix.
	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. 24 change blocks.
	33 lines changed or deleted		82 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/