JSON Responses for the Registration Data Access Protocol (RDAP)
obsoleted by
- rfc-9083 — JSON Responses for the Registration Data Access Protocol (RDAP)
Extracted elements (30)
jCard (RFC 7095) was chosen to represent entity contact information because the many types of entities in RDAP (organizations, individuals, governments, etc.) share sufficiently similar contact structure that a single unified construct reduces implementer code duplication.
The entity object class unifies what are logically different registry concepts (registrant, registrar, technical contact, etc.) into one JSON structure distinguished by the "roles" array, because these differ mainly in their relationship to containing objects rather than in their data structure.
IRIs (Internationalized Resource Identifiers) SHOULD be converted to URIs before use in RDAP JSON responses, since the JSON format uses URI syntax as defined by RFC 3986.
All JSON names specified in this document are case sensitive. Both servers and clients MUST transmit and process them using the specified character case.
An objectClassName is REQUIRED in all RDAP response objects so that the type of the object can be interpreted.
Clients MUST be able to process object instances without a self link. Servers SHOULD provide a self link for every object class instance in a response.
Clients of these JSON responses SHOULD ignore unrecognized JSON members in responses. Servers can insert members not specified in this document without that constituting an error.
Clients using self links for caching SHOULD NOT cache any object class instances where the authority of the self link is different than the authority of the server returning the data, to avoid cache poisoning.
Objects in the asEventActor array MUST NOT have an "eventActor" member; these objects denote that the containing entity is itself an event actor for the given events.
Self links MUST contain a "type" element containing the "application/rdap+json" media type when referencing RDAP object instances.
Servers that insert unspecified members into JSON responses SHOULD have member names prefixed with a short identifier followed by an underscore followed by a meaningful name. This allowance does not apply to jCard objects.
The "href" JSON value MUST be specified in a link object. All other link JSON values (rel, hreflang, title, media, type) are OPTIONAL.
When signifying conformance to custom extensions in rdapConformance, the string used MUST be prefixed with the appropriate identifier from the IANA RDAP Extensions registry specified in RFC 7480.
RDAP responses can contain personal data such as postal addresses, email addresses, and phone numbers represented in jCard. Servers may withhold data based on policy and signal this via "removed", "obscured", or "private" status values or truncation notices.
Search responses wrap result arrays in named members: "domainSearchResults" for /domains, "nameserverSearchResults" for /nameservers, and "entitySearchResults" for /entities searches.
The Autonomous System Number (autnum) object class models AS number registrations in RIRs, with fields: startAutnum, endAutnum, name, type, status, country, and entities. There is no equivalent DNR object class.
The Domain object class represents a DNS delegation point for both forward (DNR) and reverse (RIR) DNS. It contains ldhName, unicodeName, variants (with relation, idnTable, variantNames), nameservers, secureDNS, entities, publicIds, and a network back-reference for reverse DNS.
The Entity object class represents organizations, individuals, and groups. It uses jCard (RFC 7095) for contact information via "vcardArray", and includes handle, roles, publicIds, entities (embedded), asEventActor, status, port43, networks, and autnums members.
The error response body contains an "errorCode" integer (matching the HTTP status code), a "title" string, and a "description" array of strings. It may also contain rdapConformance and notices.
The "events" array contains objects with "eventAction" (string from IANA registry), optional "eventActor", "eventDate" (RFC 3339 format), and optional "links". Events can be future-dated to denote expiration.
The IP Network object class models RIR IP network registrations, with fields: startAddress, endAddress, ipVersion ("v4" or "v6"), name, type (RIR-specific classification), country (ISO 3166 alpha-2), parentHandle, status, and entities.
The "links" array structure contains objects with fields: value (context URI), rel, href (required), hreflang, title, media, and type; these correspond to RFC 5988 link relation values.
The Nameserver object class contains objectClassName ("nameserver"), handle, ldhName (LDH form), unicodeName (U-label form), ipAddresses (with "v4" and "v6" sub-arrays), entities, status, remarks, links, port43, and events.
The "notices" and "remarks" structures are arrays of objects each containing an optional "title", optional "type" (registered with IANA), a "description" array of strings, and an optional "links" array. Notices describe the service; remarks describe the containing object.
The "rdapConformance" member is an array of strings appearing only in the topmost JSON object of a response, each providing a hint as to the specifications used. The literal "rdap_level_0" signifies conformance with RFC 7483.
The secureDNS object within a domain contains zoneSigned (boolean), delegationSigned (boolean), maxSigLife (integer seconds), dsData (array of DS record fields: keyTag, algorithm, digest, digestType), and keyData (array of DNSKEY record fields: flags, protocol, publicKey, algorithm).
Truncated responses signal omissions via a typed notice (in search results) or a typed remark (in a single object), using IANA-registered type strings such as "result set truncated due to authorization" or "object truncated due to excessive load".
IANA established the "RDAP JSON Values" registry under the "Registration Data Access Protocol (RDAP)" category, covering notice/remark types, status values, event actions, roles, and domain variant relations. The registry operates under Expert Review policy (RFC 5226).
IANA registered the "application/rdap+json" media type for JSON responses to RDAP queries, with no required parameters and security considerations from RFC 7159 Section 6.
The media type application/rdap+json does not have security considerations beyond those found in Section 6 of RFC 7159 (JSON). Security for the RDAP exchange is addressed in RFC 7481.