The Number Resources Organization (NRO) recently registered a Registration Data Access Protocol (RDAP) profile with IANA for the Regional Internet Registry (RIR) community: see https://bitbucket.org/nroecg/nro-rdap-profile/raw/v1/nro-rdap-profile.txt and https://www.iana.org/assignments/rdap-extensions/rdap-extensions.xhtml.

* What does this mean?

As with the ICANN RDAP response profile for gTLDs, this document defines a set of requirements that RIR RDAP services need to fulfil in order to improve consistency across those services. It covers topics like contact data, query processing, and error responses, among others. Over time, as each RIR updates its implementation in order to conform with the profile, the improved consistency will make using RDAP in cross-RIR contexts simpler and more reliable.

* Why do we need a profile?

The profile is necessary, because while the RDAP RFCs (namely RFC 7480, RFC 7481, RFC 7482, RFC 7483 and RFC 7484) are prescriptive on some points, they provide significant flexibility on others.

For example, it’s not possible to mandate in a protocol specification that all registries return contact email addresses for all records, because there may be local policy reasons why that’s not possible in certain cases. Because the RIR RDAP profile’s scope is limited to the number registries, it’s possible for it to be more prescriptive than the more generic protocol document. This, in turn, means that clients need fewer server-specific workarounds, making them simpler to develop and maintain.

* What has to change in APNIC’s RDAP to come into alignment?

APNIC is reviewing its implementation to see how much work is required to reach conformance with the profile. Separately, APNIC is in discussions with the National Internet Registries, who are exploring the possibility of hosting their own RDAP services, to make sure they are aware of the new structural guidelines.

* Other improvements planned for RDAP

The profile’s scope, with a couple of exceptions, is limited to the functionality defined by the original specifications. APNIC’s product development process involves regular evaluation of new RDAP extensions developed by the IETF’s REGEXT working group, to see whether they provide value in the context of APNIC’s RDAP service. Potential improvements include:

- Sorting and paging of search results - https://www.rfc-editor.org/rfc/rfc8977.txt - Reverse search - https://www.ietf.org/archive/id/draft-ietf-regext-rdap-reverse-search-05.txt - Partial responses - https://www.rfc-editor.org/rfc/rfc8982.txt - OIDC authentication - https://www.ietf.org/archive/id/draft-ietf-regext-rdap-openid-06.txt

Community feedback on the usefulness of these extensions (and the profile) is appreciated. You can submit comments and suggestions by replying to this message.

Regards,

Tom Harrison APNIC