RDAP’s proposed move from jCard to JSContact

On this page

1. Why propose an alternative to jCard?
2. What the contact data would look like
3. How the proposed transition would work
4. Implementation note: October 15 versioning update
5. Would JSContact expose hidden contact information?
6. What happens next?

A lookup tool needs to understand the format of contact information before it can display a name, email address or telephone number. If an RDAP server changes that format and the tool does not support it, the lookup could succeed while contact details disappear from the tool’s display.

That compatibility problem is the practical issue behind the proposed RDAP extension for JSContact. The extension would let servers replace the existing jCard contact representation with JSContact. The draft describes a staged transition for clients and providers.

The extension is an IETF proposal still under development, not a finalized requirement for every RDAP service. JSContact itself is already standardized. Its use in RDAP, including the transition procedure described here, remains work in progress.

Why propose an alternative to jCard?

RDAP’s base response specification uses jCard, the JSON representation of vCard, for contact information inside entity objects. Those entities can represent registrants, registrars, abuse contacts and other parties associated with a registration record.

jCard stores properties in nested arrays. A parser needs to understand each property’s name, parameters, value type and value, rather than treating the data as a flat list of named fields.

According to the draft’s rationale, members of the RDAP Pilot Working Group reported that jCard was unintuitive, complicated to implement for clients and servers, and incompatible with best practices for RESTful APIs.

JSContact uses named JSON objects and prefers maps for collections such as email addresses and telephone numbers. The draft describes this approach as simpler and more efficient to process. Both formats can represent internationalized and unstructured contact information, so the proposal is not introducing those capabilities for the first time.

For the existing format’s structure, see how to read vcardArray.

What the contact data would look like

Consider a fictional contact named Alex Example with the email address alex@example.test. In jCard, the contact member could look like this:

{
  "vcardArray": [
    "vcard",
    [
      ["version", {}, "text", "4.0"],
      ["fn", {}, "text", "Alex Example"],
      ["email", {}, "text", "alex@example.test"]
    ]
  ]
}

The equivalent JSContact member under revision 27 could look like this:

{
  "jscontact_card": {
    "@type": "Card",
    "version": "2.0",
    "name": {
      "full": "Alex Example"
    },
    "emails": {
      "email": {
        "address": "alex@example.test"
      }
    }
  }
}

These are contact-data fragments, not complete RDAP responses. They show the change from vcardArray to jscontact_card, with the same information expressed differently.

A jCard-aware tool finds the fn and email properties and reads their values. A JSContact-aware tool reads name.full and the address values in the emails map. Either parser can feed the same display:

• Name: Alex Example
• Email: alex@example.test

The proposed format rules do not allow both contact members in one entity. They also require a single contact representation across all entities with contact data in a response. Supporting both formats therefore means handling either kind of response, not expecting every response to contain two copies of the contact details.

How the proposed transition would work

The draft describes three stages. They apply to an individual provider’s service, not a synchronized worldwide switch.

1. jCard only

The server returns jCard and cannot provide the alternative. Its rdapConformance array must not contain the jscontact identifier.

2. jCard by default, JSContact on request

The server continues returning jCard unless a client requests JSContact. Revision 27 defines request mechanisms using either the versioning_list or exts_list parameter of the RDAP media type in the HTTP Accept header. Clients must not use both mechanisms in the same request.

Clients and servers implementing the extension must also implement RDAP versioning. The implementation note below distinguishes that dependency’s version from the JSContact extension and data-format versions.

Under the draft’s error-handling rules, requests for unsupported or unknown extensions or extension versions are ignored. If a JSContact request cannot be satisfied during this stage, the server returns jCard by default. Clients therefore need to check the representation returned.

The service’s /help response includes jscontact in rdapConformance to advertise support. An ordinary response containing JSContact includes the same identifier to signal the representation used in that response.

When JSContact is not requested, the server should include a jCard sunset end notice reporting its planned cutoff date and time. The notice can link to instructions for requesting JSContact.

3. JSContact replaces jCard

At this stage, JSContact is the default and the only contact representation returned. The /help response adds noJcard to signal that jCard is no longer available. The server should also include a jCard deprecation notice stating that jCard has been deprecated.

An older tool cannot assume it can request jCard indefinitely. Once a provider reaches this stage, a parser that understands only vcardArray may miss contact data even though the server returned it.

The draft sets no universal migration deadline. It does not fix the length of the sunset period and recommends that providers monitor usage to determine whether their announced timeline needs adjustment. A date in one provider’s notice would describe that service’s transition, not every RDAP server’s schedule.

Implementation note: October 15 versioning update

Revision 08 of the RDAP versioning draft, published October 15, 2026, introduces versioning-0.9. It changes versioning_list syntax to use an unquoted value with + between extension-version identifiers, replacing the previous quoted, space-separated list.

These three versions are independent:

• RDAP versioning extension: versioning-0.9 identifies the versioning mechanism in revision 08, not a contact format.
• RDAP JSContact extension: jscontact-0.5 remains the extension version identifier in JSContact revision 27.
• JSContact contact-data format: The Card’s "version": "2.0" remains required by that RDAP profile. JSContact 2.0 is standardized separately in RFC 9982.

For a server supporting both extension versions, the revision 08 syntax would be:

Accept: application/rdap+json;versioning_list=versioning-0.9+jscontact-0.5

This is a dependency update, not a new JSContact revision or a correction to the contact-data examples above. JSContact revision 27 still references versioning revision 07. Implementers should check their server’s supported revisions and documentation, including versioning_help in its /help response, before adopting the new syntax. The versioning draft identifies versioning-0.9 as incompatible with versioning-0.8; neither identifier replaces jscontact-0.5 or the Card’s "2.0".

Would JSContact expose hidden contact information?

No. Changing the representation does not grant access to data withheld by privacy or disclosure policies.

During the stage when both formats are available, the draft’s security considerations require equivalent access control, redaction and data-release policies for jCard and JSContact. A client must not gain access to a protected email address merely by requesting the alternative format.

There is a structural difference relevant to redaction. As the privacy considerations explain, jCard requires an fn property, while a JSContact Card need not contain a name property. JSContact version 2.0 also makes uid optional, allowing these properties to be removed using RDAP’s redaction removal method.

For users, missing contact details still need context. They might be withheld, unavailable or not displayed correctly by the client. The format alone does not establish which explanation applies. Our guide to missing and redacted RDAP fields covers that distinction.

What happens next?

Verified October 21, 2026: The latest revision of draft-ietf-regext-rdap-jscontact is revision 27, published on October 5, 2026. It remains an active Internet-Draft with IESG state “I-D Exists”. Its intended RFC status is Proposed Standard; that is a target, not an approval already granted.

The developments to watch are formal approval by the Internet Engineering Steering Group (IESG), RFC publication, and verified provider adoption. The draft lists reported implementations, but explicitly says that the supplied implementation information has not been verified. That list should not be treated as proof that every listed service implements revision 27 today.

The live IETF status page tracks the document’s progress. Provider documentation and observed responses are separate evidence of deployment.

For lookup-tool maintainers, the practical preparation is to test contact display across both formats as providers introduce support. Include missing or redacted fields in those tests, read capability signals and transition notices, and confirm the representation returned rather than assuming a request for JSContact guarantees it.