Internet Standards Like Whois Get REST, JSON Support

The people who built the Internet were Unix people, and they designed Internet standards to work like Unix. Usually that involves systems opening raw sockets and sending through them strings of text that the receiving system must then Parse to extract the data and commands. The code to do this often ends up ugly, clumsy, error-prone and a minefield of security vulnerabilities.

But of late, the engineers building new standards have started using REST APIs and JSON for their implementations. The advantages are obvious. Code to use the standards would conform to the conventions increasingly used by Internet programmers. It would look like just another API call, as opposed to the cornucopia of kludges one finds in Internet standards. Finally, structuring data in JSON facilitates bounds checking and other security best practices.

Such standards are created and managed by the Internet Engineering Task Force. Anyone can propose a standard through the IETF, and people often do. The vehicle is a document called a request for comment. After a period of discussion and consensus building, some RFCs move on to the "standards track."

There is a full standards-track RFC called RFC 7159: The JavaScript Object Notation (JSON) Data Interchange Format, edited by Tim Bray of Google and dated March 2014. The document makes clear that it is largely the same text as an IETF informational document on JSON by Douglas Crockford of dated July 2006.

JSON is used in many more standards than REST; a search on IETF for "JSON" returns "about 60,500 results," but only 67 of them are standards-track RFCs. A search for "Representational State Transfer" yields 440 results, only five of which are real standards-track RFCs. Only three use both REST and JSON, and two of those are part of the same broader standard.

There are many interesting JSON standards, including RFC 7265: jCal: The JSON Format for iCalendar, RFC 7515: JSON Web Signature (JWS), RFC 7516: JSON Web Encryption (JWE) and RFC 7033: WebFinger.

The oldest REST standard appears to be RFC 6690: Constrained RESTful Environments (CoRE) Link Format, dated August 2012. It defines the response format from the server for Resource enumeration but, somewhat oddly, does not use JSON for that format. RFC 7252: The Constrained Application Protocol (CoAP) from June 2014 is related to RFC 6690. Both are aimed at embedded applications once referred to as mobile to mobile, but now known far and wide as the Internet of Things.

The first real REST/JSON Internet standard effort appears to be RFC 7285: Application-Layer Traffic Optimization (ALTO) Protocol from September 2014. It defines services that "provide network information (e.g., basic network location structure and preferences of network paths) [from the point of view of ISP] with the goal of modifying network resource consumption patterns while maintaining or improving application performance." In other words, it allows application developers to tune clients and servers to local client network conditions. The standard's authors come from Alcatel-Lucent, Cisco, Comcast, Google, Open Garden, the University of Stuttgart and Yale.

A series of five standards-track RFCs define a new standard called Registration Data Access Protocol (RDAP), the anointed successor to Whois. If you're looking for a good example of a badly designed standard, look no further than Whois. It is the Internet service that lists who owns an Internet domain and certain other details, such as the authoritative name servers. Click here, for example, to see the Whois information for

Submitting a Whois request isn't that hard. Open a socket to port 43 on the domain's Whois server (which you can get by doing a similar Whois query to for the top-level domain of the domain you're looking up) and send the domain name to the socket, followed by \r\n (carriage return and line Feed). What you get back is a long and basically unstructured string. You need to find and extract any details you need. You may easily run into servers with unusual responses.

The following RFCs make up RDAP:

There is also a related informational document called RFC 7485: Inventory and Analysis of WHOIS Registration Objects.

In fact, RDAP enables lookups not just of domain name information, but also:

  • Networks by IP address
  • Autonomous system numbers by number
  • Reverse DNS metadata by domain
  • Nameservers by name
  • Registrars by name
  • Entities (such as contacts) by identifier

Servers are not required to support all of these functions.

Queries return JSON, such as this example:

"events" : [
    "eventAction" : "registration",
    "eventActor" : "SOMEID-LUNARNIC",
    "eventDate" : "1990-12-31T23:59:59Z"
    "eventAction" : "last changed",
    "eventActor" : "OTHERID-LUNARNIC",
    "eventDate" : "1991-12-31T23:59:59Z"
} ]

Don't be surprised to see REST/JSON versions of other important Internet standards proposed. SMTP, the email protocol of the Internet, would be an interesting possibility. In many cases, extant third-party implementations could be used as a basis.

Old-timer resistance to the March of Progress is an old story. No doubt many will miss being able to send and receive individual bytes through a socket, but that's not what most developers need. We need higher-level abstractions that work well with modern languages. REST and JSON fit the bill.

Be sure to read the next Domains article: Daily API RoundUp: Heartland, Cirrus Identity, Simpliroute, RunKeeper, Node.js Frameworks