draft-ietf-regext-rdap-partial-response-09.txt   draft-ietf-regext-rdap-partial-response-10.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 April 14, 2020 Expires: October 30, 2020 April 28, 2020
Registration Data Access Protocol (RDAP) Partial Response Registration Data Access Protocol (RDAP) Partial Response
draft-ietf-regext-rdap-partial-response-09 draft-ietf-regext-rdap-partial-response-10
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 October 16, 2020. This Internet-Draft will expire on October 30, 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 16 skipping to change at page 2, line 16
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
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. RDAP Conformance . . . . . . . . . . . . . . . . . . 4 2.1.1. RDAP Conformance . . . . . . . . . . . . . . . . . . 4
2.1.2. Representing Subsetting Links . . . . . . . . . . . . 4 2.1.2. Representing Subsetting Links . . . . . . . . . . . . 4
3. Dealing with Relationships . . . . . . . . . . . . . . . . . 5 3. Dealing with Relationships . . . . . . . . . . . . . . . . . 5
4. Basic Field Sets . . . . . . . . . . . . . . . . . . . . . . 5 4. Basic Field Sets . . . . . . . . . . . . . . . . . . . . . . 6
5. Negative Answers . . . . . . . . . . . . . . . . . . . . . . 7 5. Negative Answers . . . . . . . . . . . . . . . . . . . . . . 7
6. Implementation Status . . . . . . . . . . . . . . . . . . . . 8 6. Implementation Status . . . . . . . . . . . . . . . . . . . . 8
6.1. IIT-CNR/Registro.it . . . . . . . . . . . . . . . . . . . 8 6.1. IIT-CNR/Registro.it . . . . . . . . . . . . . . . . . . . 8
6.2. APNIC . . . . . . . . . . . . . . . . . . . . . . . . . . 8 6.2. APNIC . . . . . . . . . . . . . . . . . . . . . . . . . . 8
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
8. Security Considerations . . . . . . . . . . . . . . . . . . . 9 8. Security Considerations . . . . . . . . . . . . . . . . . . . 9
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 10
10.1. Normative References . . . . . . . . . . . . . . . . . . 10 10.1. Normative References . . . . . . . . . . . . . . . . . . 10
10.2. Informative References . . . . . . . . . . . . . . . . . 11 10.2. Informative References . . . . . . . . . . . . . . . . . 11
skipping to change at page 4, line 41 skipping to change at page 4, line 41
2.1.1. RDAP Conformance 2.1.1. RDAP Conformance
Servers returning the "subsetting_metadata" section in their Servers returning the "subsetting_metadata" section in their
responses MUST include "subsetting" in the rdapConformance array. responses MUST include "subsetting" in the rdapConformance array.
2.1.2. Representing Subsetting Links 2.1.2. Representing Subsetting Links
An RDAP server MAY use the "links" array of the "subsetting_metadata" An RDAP server MAY use the "links" array of the "subsetting_metadata"
element to provide ready-made references ([RFC8288]) to the available element to provide ready-made references ([RFC8288]) to the available
field sets (Figure 2). Each link represents a reference to an field sets (Figure 2). The target URI in each link is the reference
alternate view of the results. to an alternate view of the results with respect to the current view
of the results identified by the context URI.
{ {
"rdapConformance": [ "rdapConformance": [
"rdap_level_0", "rdap_level_0",
"subsetting" "subsetting"
], ],
... ...
"subsetting_metadata": { "subsetting_metadata": {
"currentFieldSet": "afieldset", "currentFieldSet": "afieldset",
"availableFieldSets": [ "availableFieldSets": [
{ {
"name": "anotherfieldset", "name": "anotherfieldset",
"description": "Contains some fields", "description": "Contains some fields",
"default": false, "default": false,
"links": [ "links": [
{ {
"value": "https://example.com/rdap/domains?name=*nr.com "value": "https://example.com/rdap/domains?name=*nr.com
&fieldSet=afieldset", &fieldSet=afieldset",
"rel": "alternate", "rel": "alternate",
"href": "https://example.com/rdap/domains?name=*nr.com "href": "https://example.com/rdap/domains?name=*nr.com
&fieldSet=anotherfieldset", &fieldSet=anotherfieldset",
"title": "Result Subset Link", "title": "Result Subset Link",
"type": "application/rdap+json" "type": "application/rdap+json"
}, }
... ]
] },
...
]
}, },
... ...
"domainSearchResults": [ "domainSearchResults": [
... ...
] ]
} }
Figure 2: Example of a "subsetting_metadata" instance Figure 2: Example of a "subsetting_metadata" instance
3. Dealing with Relationships 3. Dealing with Relationships
skipping to change at page 7, line 7 skipping to change at page 7, line 7
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. RDAP providers MAY also add any property link in each field set. RDAP providers MAY also add any property
providing service information. 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",
"subsetting" "subsetting"
], ],
... ...
"domainSearchResults": [ "domainSearchResults": [
{ {
"objectClassName": "domain", "objectClassName": "domain",
"ldhName": "example1.com", "ldhName": "example1.com",
"links": [ "links": [
{ {
"value": "https://example.com/rdap/domain/example1.com", "value": "https://example.com/rdap/domain/example1.com",
"rel": "self", "rel": "self",
"href": "https://example.com/rdap/domain/example1.com", "href": "https://example.com/rdap/domain/example1.com",
"type": "application/rdap+json" "type": "application/rdap+json"
} }
], ]
}, },
{ {
"objectClassName": "domain", "objectClassName": "domain",
"ldhName": "example2.com", "ldhName": "example2.com",
"links": [ "links": [
{ {
"value": "https://example.com/rdap/domain/example2.com", "value": "https://example.com/rdap/domain/example2.com",
"rel": "self", "rel": "self",
"href": "https://example.com/rdap/domain/example2.com", "href": "https://example.com/rdap/domain/example2.com",
"type": "application/rdap+json" "type": "application/rdap+json"
} }
], ]
}, },
... ...
] ]
} }
Figure 3: Example of RDAP response according to the "id" field set Figure 3: Example of RDAP response according to the "id" field set
5. Negative Answers 5. 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 49 skipping to change at page 9, line 49
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.
9. Acknowledgements 9. Acknowledgements
The authors would like to acknowledge Scott Hollenbeck, Tom Harrison, The authors would like to acknowledge Scott Hollenbeck, Tom Harrison,
Karl Heinz Wolf and Jasdip Singh for their contribution to this Karl Heinz Wolf, Jasdip Singh and Patrick Mevzek for their
document. contribution to this document.
10. References 10. References
10.1. Normative References 10.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 13, line 5 skipping to change at page 13, line 5
Language ([CQL]) is a comprehensive expression language that can be Language ([CQL]) is a comprehensive expression language that can be
used to customize the JSON response of a RESTful web service. The used to customize the JSON response of a RESTful web service. The
practical application of CQL to RDAP responses points out that practical application of CQL to RDAP responses points out that
declaring explicitly the output fields would still be acceptable when declaring explicitly the output fields would still be acceptable when
a few fields are requested but it would become very complicated if a few fields are requested but it would become very complicated if
the fields should be more. In the following, two CQL expressions for the fields should be more. In the following, two CQL expressions for
a search domain query are shown (Figure 4): in the first, only a search domain query are shown (Figure 4): in the first, only
objectClassName and ldhName are requested, in the second, the fields objectClassName and ldhName are requested, in the second, the fields
of a possible WHOIS-like response are listed. of a possible WHOIS-like response are listed.
https://example.com/rdap/domains?name=example*.com https://example.com/rdap/domains?name=example*.com
&fields=domainSearchResults(objectClassName,ldhName) &fields=domainSearchResults(objectClassName,ldhName)
https://example.com/rdap/domains?name=example*.com https://example.com/rdap/domains?name=example*.com
&fields=domainSearchResults(objectClassName,ldhName,unicodeName, &fields=domainSearchResults(objectClassName,ldhName,
status, unicodeName,
events(eventAction,eventDate), status,
entities(objectClassName,handle,roles), events(eventAction,eventDate),
nameservers(objectClassName,ldhName)) entities(objectClassName,handle,roles),
nameservers(objectClassName,ldhName))
Figure 4: Examples of CQL expressions for a search domain query Figure 4: Examples of CQL expressions for a search domain query
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.
skipping to change at page 13, line 51 skipping to change at page 14, line 4
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. 06: Clarified the use of self links in "Basic Field Sets" section.
Added APNIC to the implementations of the "Implementation Status" Added APNIC to the implementations of the "Implementation Status"
section. section.
07: Changed "only a subset is returned" to "only a subset of fields 07: Changed "only a subset is returned" to "only a subset of fields
in each result object is returned" in the "Introduction" section. in each result object is returned" in the "Introduction" section.
Moved the "RDAP Conformance" section up in the document. Updated Moved the "RDAP Conformance" section up in the document. Updated
the "Acknowledgements" section. the "Acknowledgements" section.
08: Changed the rdapConformance tag "subsetting_level_0" to 08: Changed the rdapConformance tag "subsetting_level_0" to
"subsetting". Moved [RFC7942] to the "Normative References". "subsetting". Moved [RFC7942] to the "Normative References".
09: Corrected the "rdapConformance" content in Figure 3. 09: Corrected the "rdapConformance" content in Figure 3.
10: Corrected the JSON content in Figure 2. Clarified the meaning
of both context and target URIs in a result subset link defined in
Section 2.1.2. Updated the "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. 16 change blocks. 
31 lines changed or deleted 38 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/