draft-ietf-regext-rdap-partial-response-03.txt   draft-ietf-regext-rdap-partial-response-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: January 31, 2020 July 30, 2019 Expires: March 5, 2020 September 2, 2019
Registration Data Access Protocol (RDAP) Partial Response Registration Data Access Protocol (RDAP) Partial Response
draft-ietf-regext-rdap-partial-response-03 draft-ietf-regext-rdap-partial-response-04
Abstract Abstract
The Registration Data Access Protocol (RDAP) does not include The Registration Data Access Protocol (RDAP) does not include
capabilities to request partial responses. In fact, according to the capabilities to request partial responses. In fact, according to the
user authorization, the server can only return full responses. user authorization, the server can only return full responses. A
Partial responses capability, especially in the case of search partial response capability, especially in the case of search
queries, could bring benefits to both clients and servers. This queries, could bring benefits to both clients and servers. This
document describes an RDAP query extension that allows clients to document describes an RDAP query extension that allows clients to
specify their preference for obtaining a partial response. specify their preference for obtaining a partial response.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 31, 2020. This Internet-Draft will expire on March 5, 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 2, line 18 skipping to change at page 2, line 18
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Conventions Used in This Document . . . . . . . . . . . . 3 1.1. Conventions Used in This Document . . . . . . . . . . . . 3
2. Approaches to Partial Response Implementation . . . . . . . . 3 2. Approaches to Partial Response Implementation . . . . . . . . 3
3. RDAP Path Segment Specification . . . . . . . . . . . . . . . 5 3. RDAP Path Segment Specification . . . . . . . . . . . . . . . 5
3.1. Subsetting Metadata . . . . . . . . . . . . . . . . . . . 5 3.1. Subsetting Metadata . . . . . . . . . . . . . . . . . . . 5
3.1.1. Representing Subsetting Links . . . . . . . . . . . . 6 3.1.1. Representing Subsetting Links . . . . . . . . . . . . 6
4. Dealing with Relationships . . . . . . . . . . . . . . . . . 7 4. Dealing with Relationships . . . . . . . . . . . . . . . . . 7
5. Basic Field Sets . . . . . . . . . . . . . . . . . . . . . . 7 5. Basic Field Sets . . . . . . . . . . . . . . . . . . . . . . 7
6. Negative Answers . . . . . . . . . . . . . . . . . . . . . . 8 6. Negative Answers . . . . . . . . . . . . . . . . . . . . . . 8
7. RDAP Conformance . . . . . . . . . . . . . . . . . . . . . . 8 7. RDAP Conformance . . . . . . . . . . . . . . . . . . . . . . 9
8. Implementation Status . . . . . . . . . . . . . . . . . . . . 8 8. Implementation Status . . . . . . . . . . . . . . . . . . . . 9
8.1. IIT-CNR/Registro.it . . . . . . . . . . . . . . . . . . . 9 8.1. IIT-CNR/Registro.it . . . . . . . . . . . . . . . . . . . 9
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
10. Security Considerations . . . . . . . . . . . . . . . . . . . 9 10. Security Considerations . . . . . . . . . . . . . . . . . . . 10
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
12.1. Normative References . . . . . . . . . . . . . . . . . . 10 12.1. Normative References . . . . . . . . . . . . . . . . . . 11
12.2. Informative References . . . . . . . . . . . . . . . . . 11 12.2. Informative References . . . . . . . . . . . . . . . . . 11
Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 12 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13
1. Introduction 1. Introduction
The use of partial response in RESTful API ([REST]) design is very The use of partial response in RESTful API ([REST]) design is very
common. The rationale is quite simple: instead of returning objects common. The rationale is quite simple: instead of returning objects
in API responses with all data fields, only a subset is returned. in API responses with all data fields, only a subset is returned.
The benefit is obvious: less data transferred over the network means The benefit is obvious: less data transferred over the network means
less bandwidth usage, faster server response, less CPU time spent less bandwidth usage, faster server response, less CPU time spent
both on the server and the client, as well as less memory usage on both on the server and the client, as well as less memory usage on
the client. the client.
skipping to change at page 3, line 32 skipping to change at page 3, line 32
2. Approaches to Partial Response Implementation 2. Approaches to Partial Response Implementation
Looking at the implementation experiences described above, two Looking at the implementation experiences described above, two
approaches to the implementation of partial response can be detected: approaches to the implementation of partial response can be detected:
o the client declares explicitly the data fields to get back; o the client declares explicitly the data fields to get back;
o the client declares a name identifying a server pre-defined set of o the client declares a name identifying a server pre-defined set of
data fields. data fields.
The former is more flexible than the latter, because clients can The former is more flexible than the latter because clients can
specify all the data fields they need. However, it has some specify all the data fields they need. However, it has some
drawbacks: drawbacks:
o fields have to be declared according to a given syntax. This is a o fields have to be declared according to a given syntax. This is a
simple task when the data structure of the object is flat, but it simple task when the data structure of the object is flat, but it
is much more difficult when the object has a tree structure like is much more difficult when the object has a tree structure like
the one of a JSON object. The presence of arrays and deep nested the one of a JSON object. The presence of arrays and deep nested
objects contributes to complicate both the syntax definition of objects contributes to complicate both the syntax definition of
the query and, consequently, the processing phase on the server the query and, consequently, the processing phase on the server
side; side;
skipping to change at page 5, line 4 skipping to change at page 5, line 4
The latter approach seems to facilitate RDAP interoperability. In The latter approach seems to facilitate RDAP interoperability. In
fact, servers can define some basic field sets which, if known to the fact, servers can define some basic field sets which, if known to the
clients, can increase the probability to get a valid response. The clients, can increase the probability to get a valid response. The
usage of field sets lets the query string be less complex. In usage of field sets lets the query string be less complex. In
addition, the definition of pre-defined sets of fields makes easier addition, the definition of pre-defined sets of fields makes easier
to establish the results limits. to establish the results limits.
Finally, considering that there is not a real need for RDAP users to Finally, considering that there is not a real need for RDAP users to
have the maximum flexibility in defining all the possible sets of have the maximum flexibility in defining all the possible sets of
logically connected fields (e.g. users interested in domains usually logically connected fields (e.g. users interested in domains usually
need to know the status, the creation date, the expire date of each need to know the status, the creation date, the expiry date of each
domain), the latter approach is preferred. domain), the latter approach is preferred.
3. RDAP Path Segment Specification 3. RDAP Path Segment Specification
The path segment defined in this section is an OPTIONAL extension of The path segment defined in this section is an OPTIONAL extension of
search path segments defined in RFC 7482 ([RFC7482]). This document search path segments defined in RFC 7482 ([RFC7482]). This document
defines an RDAP query parameter, "fieldSet", whose value is a string defines an RDAP query parameter, "fieldSet", whose value is a string
identifying a server pre-defined set of fields (Figure 2). identifying a server pre-defined set of fields (Figure 2).
https://example.com/rdap/domains?name=example*.com&fieldSet=afieldset https://example.com/rdap/domains?name=example*.com&fieldSet=afieldset
skipping to change at page 7, line 38 skipping to change at page 7, line 38
o "brief": it contains the fields that can be included in a "short" o "brief": it contains the fields that can be included in a "short"
response. This field set could be used when the client is asking response. This field set could be used when the client is asking
for a subset of the full response which gives a basic knowledge of for a subset of the full response which gives a basic knowledge of
each object; each object;
o "full": it contains all the information the server can provide for o "full": it contains all the information the server can provide for
a particular object. a particular object.
The "objectClassName" field is implicitly included in each of the The "objectClassName" field is implicitly included in each of the
above field sets. RDAP providers MAY add any property providing above field sets. RDAP providers are RECOMMENDED to include a "self"
service information. link in each field set other than "full" in order to allow clients to
easily request for the full objects. RDAP providers MAY also add any
property providing service information.
Fields included in "brief" and "full" field sets could be returned Fields included in "brief" and "full" field sets could be returned
according to users access levels. according to the user access levels.
{ {
"rdapConformance": [ "rdapConformance": [
"rdap_level_0", "rdap_level_0",
], ],
... ...
"domainSearchResults": [ "domainSearchResults": [
{ {
"objectClassName": "domain", "objectClassName": "domain",
"ldhName": "example1.com" "ldhName": "example1.com",
"links": [
{
"value": "https://example.com/rdap/domain/example1.com",
"rel": "self",
"href": "https://example.com/rdap/domain/example1.com",
"type": "application/rdap+json"
}
],
}, },
{ {
"objectClassName": "domain", "objectClassName": "domain",
"ldhName": "example2.com" "ldhName": "example2.com",
"links": [
{
"value": "https://example.com/rdap/domain/example2.com",
"rel": "self",
"href": "https://example.com/rdap/domain/example2.com",
"type": "application/rdap+json"
}
],
}, },
... ...
] ]
} }
Figure 4: Example of RDAP response according to the "id" field set Figure 4: Example of RDAP response according to the "id" field set
6. Negative Answers 6. Negative Answers
Each request including an unsupported field set SHOULD obtain an HTTP Each request including an unsupported field set SHOULD obtain an HTTP
skipping to change at page 9, line 42 skipping to change at page 10, line 19
Extension identifier: subsetting Extension identifier: subsetting
Registry operator: Any Registry operator: Any
Published specification: This document. Published specification: This document.
Contact: IESG <iesg@ietf.org> Contact: IESG <iesg@ietf.org>
Intended usage: This extension describes a best practice for Intended usage: This extension describes a best practice for
partial response provisioning. partial response provisioning.
10. Security Considerations 10. Security Considerations
Search query typically requires more server resources (such as The search query typically requires more server resources (such as
memory, CPU cycles, and network bandwidth) when compared to lookup memory, CPU cycles, and network bandwidth) when compared to the
query. This increases the risk of server resource exhaustion and lookup query. This increases the risk of server resource exhaustion
subsequent denial of service due to abuse. Partial response can and subsequent denial of service due to abuse. Partial response can
contribute together with other strategies (e.g. restricting search contribute together with other strategies (e.g. restricting search
functionality, limiting the rate of search requests, truncating and functionality, limiting the rate of search requests, truncating and
paging results) to mitigate this risk. paging results) to mitigate this risk.
Furthermore, partial response can support RDAP operators to implement Furthermore, partial response can support RDAP operators to implement
a versatile access control policy through the HTTP authentication a versatile access control policy through the HTTP authentication
mechanisms as described in RFC 7481 ([RFC7481]). In fact, RDAP mechanisms as described in RFC 7481 ([RFC7481]). In fact, RDAP
operators can follow different, not alternative, approaches to the operators can follow different, not alternative, approaches to the
building of responses according to the user access levels: building of responses according to the user access levels:
skipping to change at page 10, line 23 skipping to change at page 10, line 48
Servers can also define different results limits according to the Servers can also define different results limits according to the
available field sets, so a more flexible truncation strategy can be available field sets, so a more flexible truncation strategy can be
realized. realized.
Therefore, the new query parameter presented in this document Therefore, the new query parameter presented in this document
provides the RDAP operators with a way to implement a secure server provides the RDAP operators with a way to implement a secure server
without penalizing its efficiency. without penalizing its efficiency.
11. Acknowledgements 11. Acknowledgements
The authors would like to acknowledge Scott Hollenbeck for his The authors would like to acknowledge Scott Hollenbeck and Tom
contribution to this document. Harrison for their contribution to this document.
12. References 12. References
12.1. Normative References 12.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
skipping to change at page 12, line 31 skipping to change at page 13, line 4
Appendix A. Change Log Appendix A. Change Log
00: Initial working group version ported from draft-loffredo-regext- 00: Initial working group version ported from draft-loffredo-regext-
rdap-partial-response-03 rdap-partial-response-03
01: Removed "FOR DISCUSSION" items. Changed the basic field sets 01: Removed "FOR DISCUSSION" items. Changed the basic field sets
from REQUIRED to OPTIONAL. Removed the definition of fields from REQUIRED to OPTIONAL. Removed the definition of fields
included in "brief" field set. Provided a more detailed included in "brief" field set. Provided a more detailed
description of "subsetting_metadata" structure. Removed some description of "subsetting_metadata" structure. Removed some
references. references.
02: Added the "Negative Answers" section. Changed "IANA 02: Added the "Negative Answers" section. Changed "IANA
Considerations" section. Considerations" section.
03: Added the "unicodeName" field in the id fieldSet when a returned 03: Added the "unicodeName" field in the id fieldSet when a returned
domain or nameserver is an IDN. Added RFC5890 to "Normative domain or nameserver is an IDN. Added RFC5890 to "Normative
References" section. References" section.
04: Recommended the RDAP providers to include a "self" link in any
field set other than "full". Updated "Acknowledgements" section.
Authors' Addresses Authors' Addresses
Mario Loffredo Mario Loffredo
IIT-CNR/Registro.it IIT-CNR/Registro.it
Via Moruzzi,1 Via Moruzzi,1
Pisa 56124 Pisa 56124
IT IT
Email: mario.loffredo@iit.cnr.it Email: mario.loffredo@iit.cnr.it
 End of changes. 18 change blocks. 
25 lines changed or deleted 46 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/