The IETF WEIRDS working group is defining a follow-on to WHOIS. Since this is the IETF, it’s working on the technical issues about which it can deal with, not policy which is up to ICANN and the country registries.

Somewhat to my surprise, the group is making steady progress. We’ve agreed that the basic model is RESTful, with queries via http, and responses as JSON data structures. The protocol is named RDAP for Registration Data Access Protocol, or maybe RESTful Data Access protocol.

Each request asks one question and requests the response in JSON. (If a server wants to respond with something else like a human-readable web page for requests that don’t ask for a JSON response, that’s fine but it’s also beyond the scope of the spec.) If a different server has the answer, e.g., a registry referring to a registrar, a normal web redirect handles that.

The query and response formats are mostly worked out, both for the numbers registries (IP addresses and related data) and names (registrations in top level domains and the like.) My concern was that the group would get bogged down in nitpicky details, but they seem pretty well under control.

Last week there was a skirmish about search options. ICANN did a WHOIS survey a while ago, and when they asked people what search options they wanted, complex patterns, combinations of fields, pagination to return answers in chunks when there were too many to return all at once, not surprisingly people wanted all of them. Someone claimed these were requirements, which they’re not. Of the existing servers that provide any searching at all, they do a simple prefix match on specific fields, like abc* to match names that start with abc, with a fixed maximum number of results, usually 50. I suggested that’s all we should put in the spec unless we can identify specific registries that plan to implement something fancier, and after a couple of rounds and no registry offering anything fancy, that seems to be the plan. There are still technical details to work out, like how to distinguish searches for ASCII names from Unicode names, but that shouldn’t be too hard.

We’ve also had long discussions about bootstrapping, how to decide which server to ask for each query. For numbers, the assignments of numbers to registries changes very slowly, less than once a year, and the five regional registries (RIRs) know each other and can refer queries to each other, so the bootstrap hardly matters.

If a client program has a built in set of ranges and registries, or just sends all the queries to the local registry, it’ll get redirected if the answer is somewhere else.

For names, the bootstrap is a little harder since there are currently over 300 TLDs, and in the next year or so the number is likely to increase to about 2000. Different TLD registries don’t usually have relationships with each other, so if a query is initially sent to the wrong registry, it has no incentive to redirect to the right one. Given the number of TLDs, a fixed bootstrap would quickly get out of date.

My suggestion was until recently that IANA, the branch of ICANN that among other things handles the names in the root zone, publish the server names in a fixed place in the DNS, e.g., the server for the .foo domain would be at foo.rdap.arpa, so the URL could be something like

http://foo.rdap.arpa/domain/somename.foo

Other proposals were a downloadable web page at IANA, a pool of bootstrap servers (plausible for numbers but completely unworkable for names) or putting the bootstrap info in the TLD itself with a SRV or NAPTR DNS record. I wasn’t thrilled about SRV or NAPTR since they aren’t easily usable from javascript or shell scripts and was pushing for the rdap.arpa approach until at the IETF meeting two weeks ago people from several different TLDs said that dealing with IANA is so tedious that they REALLY don’t want to go that route. So we’ll probably have SRV records in the TLDs. For the benefit of lazy shell and javascript programmers, I’ve reserved rdap-servers.net and hope I can make it work as an informal equivalent of rdap.arpa, extracting the host names from the SRV records.

At this point there are a fair number of technical details left, but nothing that looks terribly hard to work out, so with any luck, we’ll have a new WHOIS design ready to go around the time the new ICANN domains go live early next year.