draft-ietf-regext-rdap-sorting-and-paging-03.txt		draft-ietf-regext-rdap-sorting-and-paging-04.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: December 14, 2019 S. Hollenbeck		Expires: February 2, 2020 S. Hollenbeck
	Verisign Labs		Verisign Labs
	June 12, 2019		August 1, 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-03		draft-ietf-regext-rdap-sorting-and-paging-04
	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 December 14, 2019.		This Internet-Draft will expire on February 2, 2020.
	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 7, line 28 ¶		skipping to change at page 7, line 28 ¶
	the following:		the following:
	sort = "sort=" sortItem *( "," sortItem )		sort = "sort=" sortItem *( "," sortItem )
	sortItem = property-ref [":" ( "a" / "d" ) ]		sortItem = property-ref [":" ( "a" / "d" ) ]
	property-ref = ALPHA *( ALPHA / DIGIT / "_" )		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=name
	https://example.com/rdap/domains?name=*nr.com&sort=registrationDate:d		https://example.com/rdap/domains?name=*nr.com&sort=registrationDate:d
	https://example.com/rdap/domains?name=*nr.com&sort=lockedDate,ldhName		https://example.com/rdap/domains?name=*nr.com&sort=lockedDate,name
	Figure 3: Examples of RDAP query reporting the "sort" parameter		Figure 3: Examples of RDAP query reporting the "sort" parameter
			Servers MUST implement sorting according to the JSON value type of
			the RDAP field the sorting property refers to: the lexicographic
			sorting for strings and the numeric sorting for numbers.
	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 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
	skipping to change at page 8, line 47 ¶		skipping to change at page 8, line 50 ¶
	* 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 a list of possible sorting properties,		paths. In the following a list of possible sorting properties,
	grouped by objects, is shown:		grouped by objects, is shown:
	* Domain: ldhName		* Domain: name
	* Nameserver: ldhName, ipV4, ipV6.		* Nameserver: name, ipV4, ipV6.
	* Entity: fn, handle, org, email, voice, country, cc, city.		* Entity: fn, handle, org, email, voice, country, cc, city.
	The correspondence between the sorting properties and the RDAP fields		The correspondence between the sorting properties and the RDAP fields
	is shown in Table 1:		is shown in Table 1:
	+-----------+-----------+-------------+---------+---------+---------+		+-----------+-----------+---------------------+------+-------+------+
	| Object | Sorting | RDAP | RFC7483 | RFC6350 | RFC8605 |		| Object | Sorting | RDAP property | RFC | RFC | RFC |
	| class | property | property | | | |		| class | property | | 7483 | 6350 | 8605 |
	+-----------+-----------+-------------+---------+---------+---------+		+-----------+-----------+---------------------+------+-------+------+
	| Searchabl | Common pr | eventAction | 4.5. | | |		| Searchabl | Common pr | eventAction values | 4.5. | | |
	| e objects | operties | values | | | |		| e objects | operties | suffixed by "Date" | | | |
	| | | suffixed by | | | |		| | | | | | |
	| | | "Date" | | | |		| Domain | name | unicodeName/ldhName | 5.3. | | |
	| | | | | | |		| | | | | | |
	| Domain | ldhName | ldhName | 5.3. | | |		| Nameserve | name | unicodeName/ldhName | 5.2. | | |
	| | | | | | |		| r | | | | | |
	| Nameserve | ldhName | ldhName | 5.2. | | |		| | ipV4 | v4 ipAddress | 5.2. | | |
	| r | | | | | |		| | ipV6 | v6 ipAddress | 5.2. | | |
	| | ipV4 | v4 | 5.2. | | |		| | | | | | |
	| | | ipAddress | | | |		| Entity | handle | handle | 5.1. | | |
	| | ipV6 | v6 | 5.2. | | |		| | fn | vcard fn | 5.1. | 6.2.1 | |
	| | | ipAddress | | | |		| | org | vcard org | 5.1. | 6.6.4 | |
	| | | | | | |		| | voice | vcard tel with | 5.1. | 6.4.1 | |
	| Entity | handle | handle | 5.1. | | |		| | | type="voice" | | | |
	| | fn | vcard fn | 5.1. | 6.2.1 | |		| | email | vcard email | 5.1. | 6.4.2 | |
	| | org | vcard org | 5.1. | 6.6.4 | |		| | country | country name in | 5.1. | 6.3.1 | |
	| | voice | vcard tel | 5.1. | 6.4.1 | |		| | | vcard adr | | | |
	| | | with type=" | | | |		| | cc | country code in | 5.1. | | 3.1 |
	| | | voice" | | | |		| | | vcard adr | | | |
	| | email | vcard email | 5.1. | 6.4.2 | |		| | city | locality in vcard | 5.1. | 6.3.1 | |
	| | country | country | 5.1. | 6.3.1 | |		| | | adr | | | |
	| | | name in | | | |		+-----------+-----------+---------------------+------+-------+------+
	| | | vcard adr | | | |
	| | cc | country | 5.1. | | 3.1 |
	| | | code in | | | |
	| | | vcard adr | | | |
	| | city | locality in | 5.1. | 6.3.1 | |
	| | | 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 some cases:
	property is multivalued:
			o since the response to a search on either domains or nameservers
			might include both A-labels and U-labels ([RFC5890]) in general, a
			consistent sorting policy shall take unicodeName and ldhName as
			two formats of the same value rather than separately. Therefore,
			the unicodeName value MUST be taken while sorting, when
			unicodeName is missing, the value of ldhName MUST be considered
			instead;
			o the jCard "sort-as" parameter MUST be ignored for the purpose of
			the sorting capability as described in this document;
	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 will be applied to the preferred
	identified by the parameter pref="1".		value identified by the parameter pref="1". If the pref parameter
			is missing, sorting will 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.		shown in this document.
	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 JSON Paths of the RDAP fields
	is shown in Table 2. The JSON Paths are provided according to the		is shown in Table 2. The JSON Paths are provided according to the
	Goessner v.0.8.0 specification ([GOESSNER-JSON-PATH]):		Goessner v.0.8.0 specification ([GOESSNER-JSON-PATH]):
	skipping to change at page 10, line 43 ¶		skipping to change at page 10, line 52 ¶
	| | e | ction=="deletion")].eventDate |		| | e | ction=="deletion")].eventDate |
	| | reinstantia | "$.domainSearchResults[*].events[?(@.eventA |		| | reinstantia | "$.domainSearchResults[*].events[?(@.eventA |
	| | tionDate | ction=="reinstantiation")].eventDate |		| | tionDate | ction=="reinstantiation")].eventDate |
	| | transferDat | "$.domainSearchResults[*].events[?(@.eventA |		| | transferDat | "$.domainSearchResults[*].events[?(@.eventA |
	| | e | ction=="transfer")].eventDate |		| | e | ction=="transfer")].eventDate |
	| | lockedDate | "$.domainSearchResults[*].events[?(@.eventA |		| | lockedDate | "$.domainSearchResults[*].events[?(@.eventA |
	| | | ction=="locked")].eventDate |		| | | ction=="locked")].eventDate |
	| | unlockedDat | "$.domainSearchResults[*].events[?(@.eventA |		| | unlockedDat | "$.domainSearchResults[*].events[?(@.eventA |
	| | e | ction=="unlocked")].eventDate |		| | e | ction=="unlocked")].eventDate |
	| | | |		| | | |
	| Domai | ldhName | $.domainSearchResults[*].ldhName |		| Domai | name | $.domainSearchResults[*].unicodeName |
	| n | | |		| n | | |
	| | | |		| | | |
	| Names | ldhName | $.nameserverSearchResults[*].ldhName |		| Names | name | $.nameserverSearchResults[*].unicodeName |
	| erver | | |		| erver | | |
	| | ipV4 | $.nameserverSearchResults[*].ipAddresses.v4 |		| | ipV4 | $.nameserverSearchResults[*].ipAddresses.v4 |
	| | | [0] |		| | | [0] |
	| | ipV6 | $.nameserverSearchResults[*].ipAddresses.v6 |		| | ipV6 | $.nameserverSearchResults[*].ipAddresses.v6 |
	| | | [0] |		| | | [0] |
	| | | |		| | | |
	| Entit | handle | $.entitySearchResults[*].handle |		| Entit | handle | $.entitySearchResults[*].handle |
	| y | | |		| y | | |
	| | fn | $.entitySearchResults[*].vcardArray[1][?(@[ |		| | fn | $.entitySearchResults[*].vcardArray[1][?(@[ |
	| | | 0]="fn")][3] |		| | | 0]="fn")][3] |
	skipping to change at page 12, line 12 ¶		skipping to change at page 12, line 12 ¶
	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": "name",
	"availableSorts": [		"availableSorts": [
	{		{
	"property": "registrationDate",		"property": "registrationDate",
	"jsonPath": "$.domainSearchResults[*]		"jsonPath": "$.domainSearchResults[*]
	.events[?(@.eventAction==\"registration\")].eventDate",		.events[?(@.eventAction==\"registration\")].eventDate",
	"default": false,		"default": false,
	"links": [		"links": [
	{		{
	"value": "https://example.com/rdap/domains?name=*nr.com		"value": "https://example.com/rdap/domains?name=*nr.com
	&sort=ldhName",		&sort=name",
	"rel": "alternate",		"rel": "alternate",
	"href": "https://example.com/rdap/domains?name=*nr.com		"href": "https://example.com/rdap/domains?name=*nr.com
	&sort=registrationDate",		&sort=registrationDate",
	"title": "Result Ascending Sort Link",		"title": "Result Ascending Sort Link",
	"type": "application/rdap+json"		"type": "application/rdap+json"
	},		},
	{		{
	"value": "https://example.com/rdap/domains?name=*nr.com		"value": "https://example.com/rdap/domains?name=*nr.com
	&sort=ldhName",		&sort=name",
	"rel": "alternate",		"rel": "alternate",
	"href": "https://example.com/rdap/domains?name=*nr.com		"href": "https://example.com/rdap/domains?name=*nr.com
	&sort=registrationDate:d",		&sort=registrationDate:d",
	"title": "Result Descending Sort Link",		"title": "Result Descending Sort Link",
	"type": "application/rdap+json"		"type": "application/rdap+json"
	}		}
	]		]
	},		},
	"domainSearchResults": [		"domainSearchResults": [
	...		...
	skipping to change at page 13, line 7 ¶		skipping to change at page 13, line 7 ¶
	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. "cursor" Parameter		2.4. "cursor" Parameter
	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.
	Using limit and offset operators represents the most common way to		Presently, the most popular methods to implement pagination in REST
	implement results pagination. Both of them can be used individually:		API are: offset pagination and keyset pagination. Both two
			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
			generated each time a request is submitted. Therefore, they are
			preferred in comparison to any other method requiring the management
			of a REST session.
			Using limit and offset operators represents the traditionally used
			method to implement results pagination. Both of them can be used
			individually:
	o "limit": means that the server must return the first N objects of		o "limit": means that the server must return the first N objects of
	the result set;		the result set;
	o "offset": means that the server must skip the first N objects and		o "offset": means that the server must skip the first N objects and
	must return objects starting from position N+1.		must return objects starting from position N+1.
	When limit and offset are used together, they allow to identify a		When limit and offset are used together, they allow to identify a
	specific portion of the result set. For example, the pair		specific portion of the result set. For example, the pair
	"offset=100,limit=50" returns first 50 objects starting from position		"offset=100,limit=50" returns first 50 objects starting from position
	101 of the result set.		101 of the result set.
	However, offset pagination raises some well known drawbacks:		Despite its easiness of implementation, offset pagination raises some
			well known drawbacks:
	o when offset has a very high value, scrolling the result set could		o when offset has a very high value, scrolling the result set could
	take some time;		take some time;
	o it always requires to fetch all the rows before dropping as many		o it always requires to fetch all the rows before dropping as many
	rows as specified by offset;		rows as specified by offset;
	o it may return inconsistent pages when data are frequently updated		o it may return inconsistent pages when data are frequently updated
	(i.e. real-time data) but this doesn't seem the case of		(i.e. real-time data) but this doesn't seem the case of
	registration data.		registration data.
	An alternative approach to offset pagination is keyset pagination		The keyset pagination [SEEK] consists in adding a query condition
	[SEEK] which consists in adding a query condition that enables the		that enables the seletion of the only data not yet returned. This
	seletion of the only data not yet returned. This method has been		method has been taken as the basis for the implementation of a
	taken as the basis for the implementation of a "cursor" parameter		"cursor" parameter [CURSOR] by some REST API providers (e.g.
	[CURSOR] by some REST API providers (e.g.
	[CURSOR-API1],[CURSOR-API2]). The cursor is an opaque URL-safe		[CURSOR-API1],[CURSOR-API2]). The cursor is an opaque URL-safe
	string representing a logical pointer to the first result of the next		string representing a logical pointer to the first result of the next
	page (Figure 5). Basically, the cursor is the encryption of the key		page (Figure 5).
	value identifying the last row of the current page. For example, the
	cursor value "a2V5PXRoZWxhc3Rkb21haW5vZnRoZXBhZ2UuY29t=" is the mere
	Base64 encoding of "key=thelastdomainofthepage.com".
	The ABNF syntax is the following:
	cursor = "cursor=" ( ALPHA / DIGIT / "/" / "=" / "-" / "_" )
	https://example.com/rdap/domains?name=*nr.com
	&cursor=wJlCDLIl6KTWypN7T6vc6nWEmEYe99Hjf1XY1xmqV-M=
	Figure 5: An example of RDAP query reporting the "cursor" parameter
	Nevertheless, even cursor pagination can be troublesome:		Nevertheless, even keyset pagination can be troublesome:
	o it needs at least one key field;		o it needs at least one key field;
	o it does not allow to sort just by any field because the sorting		o it does not allow to sort just by any field because the sorting
	criterion must contain a key;		criterion must contain a key;
	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
	skipping to change at page 14, line 51 ¶		skipping to change at page 14, line 44 ¶
	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 might be a time consuming process.		and, therefore, data selection might be a time consuming process.
	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 cursor		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.
	That said, the cursor parameter can be used to encode not only the
	key value but also the information about offset pagination. For		That said, the cursor parameter defined in this specification can be
	example, the cursor value "b2Zmc2V0PTEwMCxsaW1pdD01MAo=" is the mere		used to encode information about any pagination method. For example,
	Base64 encoding of "offset=100,limit=50". This solution lets RDAP		in the case of a simple implementation of the cursor parameter to
	providers to implement a pagination method according to their needs,		represent offset pagination information, the cursor value
	the user access levels, the submitted queries. In addition, servers		"b2Zmc2V0PTEwMCxsaW1pdD01MAo=" is the mere Base64 encoding of
	can change the method over time without announcing anything to the		"offset=100,limit=50". Likewise, in a simple implementation to
	clients.		represent keyset pagination information, the cursor value
			"a2V5PXRoZWxhc3Rkb21haW5vZnRoZXBhZ2UuY29t=" represents the mere
			Base64 encoding of "key=thelastdomainofthepage.com" where the key
			value identifies the last row of the current page.
			This solution lets RDAP 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.
			The ABNF syntax of the cursor paramter is the following:
			cursor = "cursor=" 1*( ALPHA / DIGIT / "/" / "=" / "-" / "_" )
			https://example.com/rdap/domains?name=*nr.com
			&cursor=wJlCDLIl6KTWypN7T6vc6nWEmEYe99Hjf1XY1xmqV-M=
			Figure 5: An example of RDAP query reporting the "cursor" parameter
	2.4.1. Representing Paging Links		2.4.1. Representing Paging Links
	An RDAP server SHOULD use the "links" array of the "paging_metadata"		An RDAP server SHOULD use the "links" array of the "paging_metadata"
	element to provide a ready-made reference [RFC8288] to the next page		element to provide a ready-made reference [RFC8288] to the next page
	of the result set (Figure 6). Examples of additional "rel" values a		of the result set (Figure 6). Examples of additional "rel" values a
	server MAY implements are "first", "last", "prev".		server MAY implements are "first", "last", "prev".
	{		{
	"rdapConformance": [		"rdapConformance": [
	skipping to change at page 17, line 26 ¶		skipping to change at page 17, line 26 ¶
	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.
	Similar operators are completely or partially supported by the most		Similar operators are completely or partially supported by the most
	known NoSQL databases (MongoDB, CouchDB, HBase, Cassandra, Hadoop) so		known NoSQL databases (MongoDB, CouchDB, HBase, Cassandra, Hadoop) so
	the implementation of the new parameters seems to be practicable by		the implementation of the new parameters seems to be practicable by
	servers working without the use of an RDBMS.		servers working without the use of an RDBMS.
	Furthermore, both two 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 generated each time a request is submitted.
	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
	intended to assist the IETF in its decision processes in progressing		intended to assist the IETF in its decision processes in progressing
	skipping to change at page 20, line 15 ¶		skipping to change at page 20, line 15 ¶
	[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an		[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
	IANA Considerations Section in RFCs", RFC 5226,		IANA Considerations Section in RFCs", RFC 5226,
	DOI 10.17487/RFC5226, May 2008,		DOI 10.17487/RFC5226, May 2008,
	<https://www.rfc-editor.org/info/rfc5226>.		<https://www.rfc-editor.org/info/rfc5226>.
	[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax		[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
	Specifications: ABNF", STD 68, RFC 5234,		Specifications: ABNF", STD 68, RFC 5234,
	DOI 10.17487/RFC5234, January 2008,		DOI 10.17487/RFC5234, January 2008,
	<https://www.rfc-editor.org/info/rfc5234>.		<https://www.rfc-editor.org/info/rfc5234>.
			[RFC5890] Klensin, J., "Internationalized Domain Names for
			Applications (IDNA): Definitions and Document Framework",
			RFC 5890, DOI 10.17487/RFC5890, August 2010,
			<https://www.rfc-editor.org/info/rfc5890>.
	[RFC6350] Perreault, S., "vCard Format Specification", RFC 6350,		[RFC6350] Perreault, S., "vCard Format Specification", RFC 6350,
	DOI 10.17487/RFC6350, August 2011,		DOI 10.17487/RFC6350, August 2011,
	<https://www.rfc-editor.org/info/rfc6350>.		<https://www.rfc-editor.org/info/rfc6350>.
	[RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer		[RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
	Protocol (HTTP/1.1): Message Syntax and Routing",		Protocol (HTTP/1.1): Message Syntax and Routing",
	RFC 7230, DOI 10.17487/RFC7230, June 2014,		RFC 7230, DOI 10.17487/RFC7230, June 2014,
	<https://www.rfc-editor.org/info/rfc7230>.		<https://www.rfc-editor.org/info/rfc7230>.
	[RFC7480] Newton, A., Ellacott, B., and N. Kong, "HTTP Usage in the		[RFC7480] Newton, A., Ellacott, B., and N. Kong, "HTTP Usage in the
	skipping to change at page 22, line 38 ¶		skipping to change at page 22, line 43 ¶
	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
	of cursor parameter. Rearranged the layout of some sections.		of cursor parameter. Rearranged the layout of some sections.
	Removed some items from "Informative References" section. Changed		Removed some items from "Informative References" section. Changed
	"IANA Considerations" section.		"IANA Considerations" section.
	03: Added "cc" to the list of sorting properties in "Sorting		03: Added "cc" to the list of sorting properties in "Sorting
	Properties Declaration" section. Added RFC8605 to the list of		Properties Declaration" section. Added RFC8605 to the list of
	"Informative References".		"Informative References".
			04: Replaced "ldhName" with "name" in the "Sorting Properties
			Declaration" section. Clarified the sorting logic with respect
			the JSON value types and the sorting policy for multivalued
			fields.
	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
	URI: http://www.iit.cnr.it		URI: http://www.iit.cnr.it
	Maurizio Martinelli		Maurizio Martinelli
	IIT-CNR/Registro.it		IIT-CNR/Registro.it
	Via Moruzzi,1		Via Moruzzi,1
	Pisa 56124		Pisa 56124
	IT		IT
	Email: maurizio.martinelli@iit.cnr.it		Email: maurizio.martinelli@iit.cnr.it
	URI: http://www.iit.cnr.it		URI: http://www.iit.cnr.it
	Scott Hollenbeck		Scott Hollenbeck
End of changes. 28 change blocks.
	87 lines changed or deleted		115 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/