Registration Data Access Protocol (RDAP) Partial Response
RFC 8982
| Document | Type | RFC - Proposed Standard (February 2021; No errata) | |
|---|---|---|---|
| Authors | Mario Loffredo , Maurizio Martinelli | ||
| Last updated | 2021-02-09 | ||
| Replaces | draft-loffredo-regext-rdap-partial-response | ||
| Stream | Internent Engineering Task Force (IETF) | ||
| Formats | plain text html xml pdf htmlized (tools) htmlized bibtex | ||
| Reviews | |||
| Stream | WG state | Submitted to IESG for Publication | |
| Document shepherd | Jasdip Singh | ||
| Shepherd write-up | Show (last changed 2020-05-08) | ||
| IESG | IESG state | RFC 8982 (Proposed Standard) | |
| Action Holders |
(None)
|
||
| Consensus Boilerplate | Yes | ||
| Telechat date | |||
| Responsible AD | Barry Leiba | ||
| Send notices to | Jasdip Singh <jasdips@arin.net> | ||
| IANA | IANA review state | Version Changed - Review Needed | |
| IANA action state | RFC-Ed-Ack | ||
Internet Engineering Task Force (IETF) M. Loffredo
Request for Comments: 8982 M. Martinelli
Category: Standards Track IIT-CNR/Registro.it
ISSN: 2070-1721 February 2021
Registration Data Access Protocol (RDAP) Partial Response
Abstract
The Registration Data Access Protocol (RDAP) does not include
capabilities to request partial responses. Servers will only return
full responses that include all of the information that a client is
authorized to receive. A partial response capability that limits the
amount of information returned, especially in the case of search
queries, could bring benefits to both clients and servers. This
document describes an RDAP query extension that allows clients to
specify their preference for obtaining a partial response.
Status of This Memo
This is an Internet Standards Track document.
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by the
Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 7841.
Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
https://www.rfc-editor.org/info/rfc8982.
Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction
1.1. Conventions Used in This Document
2. RDAP Path Segment Specification
2.1. Subsetting Metadata
2.1.1. RDAP Conformance
2.1.2. Representing Subsetting Links
3. Dealing with Relationships
4. Basic Field Sets
5. Negative Answers
6. IANA Considerations
7. Security Considerations
8. References
8.1. Normative References
8.2. Informative References
Appendix A. Approaches to Partial Response Implementation
A.1. Specific Issues Raised by RDAP
Acknowledgements
Authors' Addresses
1. Introduction
The use of partial responses in RESTful API [REST] design is very
common. The rationale is quite simple: instead of returning objects
in API responses with all data fields, only a subset of the fields in
each result object is returned. The benefit is obvious: less data
transferred over the network means less bandwidth usage, faster
server responses, less CPU time spent both on the server and the
client, and less memory usage on the client.
Currently, RDAP does not provide a client with any way to request a
partial response. Servers can only provide the client with a full
response [RFC7483]. Servers cannot limit the amount of information
returned in a response based on a client's preferences, and this
creates inefficiencies.
The protocol described in this specification extends RDAP search
capabilities to enable partial responses through the provisioning of
predefined sets of fields that clients can submit to an RDAP service
by adding a new query parameter. The service is implemented using
the Hypertext Transfer Protocol (HTTP) [RFC7230] and the conventions
described in [RFC7480].
1.1. Conventions Used in This Document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
2. RDAP Path Segment Specification
The path segment defined in this section is an OPTIONAL extension of
search path segments defined in [RFC7482]. This document defines an
RDAP query parameter, "fieldSet", whose value is a non-empty string
identifying a server-defined set of fields returned in place of the
full response. The field sets supported by a server are usually
described in out-of-band documents (e.g., RDAP profile) together with
other features. Moreover, this document defines in Section 2.1 an
in-band mechanism by means of which servers can provide clients with
basic information about the supported field sets.
The following is an example of an RDAP query including the "fieldSet"
Show full document text