Registration Data Access Protocol (RDAP) Partial Response

Explicit field selection raises an RDAP-specific problem: entity information in jCard cannot be easily selected because it is split into items of a jagged array, and RDAP service-information properties (rdapConformance, links, notices) would need to be returned unrequested, complicating server logic.

json, http

Query parameters were chosen as the mechanism for conveying the fieldSet preference because the protocol is implemented over HTTP following RFC 7480 conventions, making query parameters the natural extension point for RDAP search paths defined in RFC 7482.

http, json

The field set approach (client identifies a named server-defined set) was chosen over explicit field selection (client enumerates individual fields) because RDAP's tree-structured JSON objects and jCard arrays make field-level syntax definition complex, and field sets simplify query strings while facilitating interoperability and result limits.

json, http

Servers can define basic field sets that, if known to clients, increase the probability of obtaining a valid response and facilitate RDAP interoperability. Field sets are described in out-of-band documents such as RDAP profiles, supplemented by the in-band "subsetting_metadata" mechanism.

http, json

An RDAP server MAY use the "links" array of the "subsetting_metadata" element to provide ready-made RFC 8288 link references to the available field sets, where each target URI references an alternative view of the current results.

http, json

An RDAP server MUST define only one default field set, indicated by the "default" boolean in the AvailableFieldSet object.

http, json

Each request including an empty or unsupported "fieldSet" value MUST produce an HTTP 400 (Bad Request) response code; the response MAY optionally include additional information about supported field sets in the entity body.

http, json

Fields included in the "brief" and "full" field set responses MUST take into account the user's access and authorization levels.

http, security, json

For the "id" field set, if a returned domain or nameserver is an Internationalized Domain Name (IDN), the "unicodeName" field MUST additionally be included in the response.

http, json

In subsetting links within the "links" array of "subsetting_metadata", the "value", "rel", and "href" JSON values MUST be specified; all other JSON values are OPTIONAL.

http, json

RDAP providers SHOULD include a "links" field indicating the "self" link relationship in basic field set responses; they MAY also add any property providing service information.

http, json

Servers implementing the "fieldSet" query parameter SHOULD provide additional information in their responses about available field sets via the "subsetting_metadata" structure.

http, json

Servers returning the "subsetting_metadata" section in their responses MUST include "subsetting" in the rdapConformance array.

http, json

The AvailableFieldSet object includes required "name" (string) and "default" (boolean) members, and optional "description" (string) and "links" (Link array per RFC 8288) members.

http, json

The "fieldSet" query parameter is an OPTIONAL extension of RDAP search path segments. Its value is a non-empty string identifying a server-defined set of fields to return in place of the full response.

http, json, registry

The "subsetting_metadata" JSON object carries in-band metadata about available field sets. It contains a required "currentFieldSet" string and an optional "availableFieldSets" array of AvailableFieldSet objects.

http, json

Three basic field sets are defined: "id" (key field only: handle for entities, ldhName for domains/nameservers), "brief" (subset of fields for basic knowledge), and "full" (all information the server can provide). The "objectClassName" field is implicitly included in each.

http, json

IANA has registered the extension identifier "subsetting" in the "RDAP Extensions" registry, applicable to any registry operator, with RFC 8982 as the published specification.

registry, http

Search queries require more server resources than lookup queries, increasing the risk of resource exhaustion and denial of service. Partial responses can mitigate this risk when combined with strategies such as restricting search functionality, rate limiting, and result truncation/paging.

security, http

Support for partial responses enables RDAP operators to implement data access control policies based on HTTP authentication (RFC 7481), allowing the list of available field sets and the fields within each set to vary according to the client's access and authorization levels.

security, http