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/