draft-ietf-regext-rdap-partial-response-05.txt   draft-ietf-regext-rdap-partial-response-06.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: August 14, 2020 February 11, 2020 Expires: September 4, 2020 March 3, 2020
Registration Data Access Protocol (RDAP) Partial Response Registration Data Access Protocol (RDAP) Partial Response
draft-ietf-regext-rdap-partial-response-05 draft-ietf-regext-rdap-partial-response-06
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. A user authorization, the server can only return full responses. A
partial response 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.
skipping to change at page 1, line 36 skipping to change at page 1, line 36
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 August 14, 2020. This Internet-Draft will expire on September 4, 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 20 skipping to change at page 2, line 20
1.1. Conventions Used in This Document . . . . . . . . . . . . 3 1.1. Conventions Used in This Document . . . . . . . . . . . . 3
2. RDAP Path Segment Specification . . . . . . . . . . . . . . . 3 2. RDAP Path Segment Specification . . . . . . . . . . . . . . . 3
2.1. Subsetting Metadata . . . . . . . . . . . . . . . . . . . 3 2.1. Subsetting Metadata . . . . . . . . . . . . . . . . . . . 3
2.1.1. Representing Subsetting Links . . . . . . . . . . . . 4 2.1.1. Representing Subsetting Links . . . . . . . . . . . . 4
3. Dealing with Relationships . . . . . . . . . . . . . . . . . 5 3. Dealing with Relationships . . . . . . . . . . . . . . . . . 5
4. Basic Field Sets . . . . . . . . . . . . . . . . . . . . . . 5 4. Basic Field Sets . . . . . . . . . . . . . . . . . . . . . . 5
5. Negative Answers . . . . . . . . . . . . . . . . . . . . . . 7 5. Negative Answers . . . . . . . . . . . . . . . . . . . . . . 7
6. RDAP Conformance . . . . . . . . . . . . . . . . . . . . . . 8 6. RDAP Conformance . . . . . . . . . . . . . . . . . . . . . . 8
7. Implementation Status . . . . . . . . . . . . . . . . . . . . 8 7. Implementation Status . . . . . . . . . . . . . . . . . . . . 8
7.1. IIT-CNR/Registro.it . . . . . . . . . . . . . . . . . . . 8 7.1. IIT-CNR/Registro.it . . . . . . . . . . . . . . . . . . . 8
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 7.2. APNIC . . . . . . . . . . . . . . . . . . . . . . . . . . 8
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
9. Security Considerations . . . . . . . . . . . . . . . . . . . 9 9. Security Considerations . . . . . . . . . . . . . . . . . . . 9
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
11.1. Normative References . . . . . . . . . . . . . . . . . . 9 11.1. Normative References . . . . . . . . . . . . . . . . . . 10
11.2. Informative References . . . . . . . . . . . . . . . . . 10 11.2. Informative References . . . . . . . . . . . . . . . . . 11
Appendix A. Approaches to Partial Response Implementation . . . 11 Appendix A. Approaches to Partial Response Implementation . . . 12
A.1. Specific Issues Raised by RDAP . . . . . . . . . . . . . 12 A.1. Specific Issues Raised by RDAP . . . . . . . . . . . . . 12
Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 13 Appendix B. Change Log . . . . . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14
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
skipping to change at page 6, line 24 skipping to change at page 6, line 24
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 are RECOMMENDED to include a "self" above field sets. RDAP providers are RECOMMENDED to include a "self"
link in each field set other than "full" in order to allow clients to link in each field set. RDAP providers MAY also add any property
easily request for the full objects. RDAP providers MAY also add any providing service information.
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 the user access levels. according to the user access levels.
{ {
"rdapConformance": [ "rdapConformance": [
"rdap_level_0", "rdap_level_0",
], ],
... ...
"domainSearchResults": [ "domainSearchResults": [
skipping to change at page 8, line 48 skipping to change at page 8, line 48
Responsible Organization: Institute of Informatics and Telematics Responsible Organization: Institute of Informatics and Telematics
of National Research Council (IIT-CNR)/Registro.it of National Research Council (IIT-CNR)/Registro.it
Location: https://rdap.pubtest.nic.it/ Location: https://rdap.pubtest.nic.it/
Description: This implementation includes support for RDAP queries Description: This implementation includes support for RDAP queries
using data from .it public test environment. using data from .it public test environment.
Level of Maturity: This is an "alpha" test implementation. Level of Maturity: This is an "alpha" test implementation.
Coverage: This implementation includes all of the features Coverage: This implementation includes all of the features
described in this specification. described in this specification.
Contact Information: Mario Loffredo, mario.loffredo@iit.cnr.it Contact Information: Mario Loffredo, mario.loffredo@iit.cnr.it
7.2. APNIC
Responsible Organization: Asia-Pacific Network Information Centre
Location: https://github.com/APNIC-net/rdap-rmp-demo/tree/partial-
response
Description: A proof-of-concept for RDAP mirroring.
Level of Maturity: This is a proof-of-concept implementation.
Coverage: This implementation includes all of the features
described in this specification.
Contact Information: Tom Harrison, tomh@apnic.net
8. IANA Considerations 8. IANA Considerations
IANA is requested to register the following value in the RDAP IANA is requested to register the following value in the RDAP
Extensions Registry: Extensions Registry:
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
skipping to change at page 13, line 41 skipping to change at page 14, line 4
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 04: Recommended the RDAP providers to include a "self" link in any
field set other than "full". Updated "Acknowledgements" section. field set other than "full". Updated "Acknowledgements" section.
05: Moved "Approaches to Partial Response Implementation" section to 05: Moved "Approaches to Partial Response Implementation" section to
the appendix. the appendix.
06: Clarified the use of self links in "Basic Field Sets" section.
Added APNIC to the implementations of the "Implementation Status"
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. 9 change blocks. 
12 lines changed or deleted 27 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/