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