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/