Summary

  • AFRINIC’s current WHOIS 2.10.7 changelog, dated 29 November 2022, lists JSContact as a new RDAP feature.
  • Its current public RDAP guide describes queries and a client surface but does not identify a JSContact version, response representation, conformance signal or request method.
  • That is a documentation boundary, not proof about what the endpoint returns or whether any standard has been met.

A feature name is not a client contract

Registries often have good reasons to describe a release in a short line. A changelog needs to tell a member that something moved. A service guide needs to show where an IP, autnum, domain or entity can be queried. Neither document has to become an engineering diary.

But the two documents do different jobs. The AFRINIC changelog currently calls WHOIS 2.10.7 current, dates it to 29 November 2022 and lists improvements to NRO RDAP-profile conformance alongside a new RDAP feature, JSContact. The guide, meanwhile, names the RDAP endpoint, explains IP, autnum, reverse-DNS and entity lookups, points to the NicInfo client and gives an out-of-region HTTP 301 example.

The reader can therefore establish that AFRINIC publicly described a feature-level change and that it operates a documented service surface. The reader cannot, from these two public pages, establish which JSContact representation is relevant, whether a particular version is in view, whether the service returns it by default, whether a client can request it, or which response signal documents that choice. The guide contains none of the terms JSContact, jCard, rdapConformance or version in its RDAP guidance.

That last observation needs discipline. It concerns the guide, not the endpoint. It does not show that an AFRINIC response lacks JSContact. It does not show that a client has failed. It does not show that AFRINIC has failed an NRO profile, a standard or its own release note. A public explanation can be narrower than a deployed capability. The question is not whether readers are entitled to reverse-engineer an implementation. It is what a reader is entitled to know when a public record uses a feature name that has more than one technical life.

Time makes the single word less precise

The timing makes that question concrete. In April 2022, before the AFRINIC release entry, an IETF Internet-Draft about using JSContact in RDAP described an extension for entity contact information. It was work in progress, published as draft-ietf-regext-rdap-jscontact-11, with terminology that included a jscard member and transition-oriented RDAP features. A draft is not an AFRINIC mandate and its existence does not prove that AFRINIC implemented it.

The present version of that work in progress uses later terms. It discusses jscontact_card, representation selection requested by a client, rdapConformance signalling and staged movement between jCard and JSContact. Its stages are useful because they show the kinds of facts a client may need: what a server returns by default, what request changes the representation, what marker tells a client what happened and how a compatibility period is described. They are not a retrospective test for AFRINIC’s 2022 release.

IANA’s current JSContact registry separately lists major versions 1.0 and 2.0. That, too, proves no AFRINIC deployment. It does show why a generic feature label is not automatically an operationally sufficient description. One label can sit beside different data-model generations, response members and migration choices.

The charitable reading of AFRINIC’s record is straightforward. The changelog did not promise a protocol profile. The guide was written to help people make common queries, not to expose a full representation roadmap. Keeping the service documentation concise may also avoid turning a public page into a disclosure of private configuration, contact data or security-sensitive rollout detail.

The remaining gap is still worth naming. A registry can make its public service contract clearer without publishing any of those sensitive things. An extension-availability record could bind a feature claim to the service and documentation revision it concerns; say which contact representation and version are advertised; name a request method only if one is offered; state the response-conformance marker; describe a compatibility or transition state; identify the applicable profile reference; and give a correction and supersession path.

A small test-capture digest could show that the record was checked without publishing a production contact record.

This is a receipt, not an instruction to choose JSContact, jCard or any particular transition. AFRINIC remains responsible for selecting and operating its representation. The point of the record is to prevent a reader from turning one vague release sentence into an unsupported operational conclusion.

The boundary protects both sides

A client needs a way to distinguish “the registry once announced a feature” from “this is the representation to expect in this request.” An operator needs a way to correct the public record without being accused of silently changing a promise that was never made. A member needs to be able to ask a bounded question: which public contract applies to this client-facing feature, and where is its correction history?

Those are registry-record questions. They do not decide policy, allocate resources or expose a contact. They make a public statement returnable to a public service description. That is a modest gain, but infrastructure documentation accumulates its value precisely through such modest joins.

Sources

  1. AFRINIC Online Services Changelog
  2. AFRINIC RDAP service guide
  3. IETF draft-ietf-regext-rdap-jscontact-11
  4. IETF draft-ietf-regext-rdap-jscontact
  5. IANA JSContact registry