Summary

  • RFC 3981 deliberately made the IRIS core insufficient on its own: registry-specific schemas had to define useful queries, results and entity classes, while a separate transport layer supplied authentication and sessions.
  • Its rejection of a universal client was a boundary, not a failure. A common lookup frame could cross registry types, but meaningful search, safe server policy, authorization and human-friendly display still required domain knowledge.

A protocol normally announces what it enables. RFC 3981 also announced what it would not try to become. Its base XML schema defined only one query type and two standalone result types, and no registry structure. The document called that core “of limited use by itself.” The limitation was not an unfinished corner. It was the mechanism by which one framework could serve registries whose objects, indexes and relationships did not naturally look alike.

The status record, errata record and Datatracker history place the January 2005 document on the Standards Track and show that RFC 4992 later updated it. IRIS — the Internet Registry Information Service — was an XML client-server framework for registry queries and results. It was not a schema for a single global database.

RFC 3981 divided responsibility into three layers. A registry-specific layer defined the queries, results and entity classes of a domain or address registry. The common IRIS layer defined search sets, result sets, references and the syntax for naming registry types. An application-transport layer handled authentication, message transfer, connection and session management, as well as its own URI form. Agreement in one layer was not authority over the other two.

Each registry type received a URN that also identified its XML namespace and schema. A server could host several registry service instances. Yet the core knew no particular registry, registry identifier or service instance, and imposed no universal tree on the data. Concrete specifications supplied that knowledge. RFC 3982 and its status page defined a domain-registry type. RFC 4698 later defined an address-registry type. Their separate schemas were not duplication around the core; they were the intended location of meaning.

The sharpest boundary appeared between lookup and search. In the design appendix, a lookup was a discrete value against one index. The core's lookupEntity operation named a registry type, entity class and entity name. Anything involving partial values, several indexes or several queries against one index became a search. IRIS did not define one standard search language for all registry types. Each registry type defined the searches that fit its own data and operating constraints.

That choice rejected an attractive promise. RFC 3981 titled one section “The Lure of a Universal Client.” A generic client might perform a lookup and render the response crudely. To search well or present results usefully, however, it needed specific knowledge about the data. Adding a common query language did not remove that knowledge requirement. It forced a client to translate user intent through the language's lowest common denominator while the user still had to understand the problem domain.

The server-side objection was more concrete. IRIS addressed public-facing registries, not only controlled enterprise directories. A language flexible enough to combine partial values across indexes would serve a power user and an abusive user. Operators would have to disable expensive query patterns to maintain service. The nominally common language would then expose functions that did not commonly work. A forced universal data relationship created another cost: servers could be asked to transform native stores into an artificial model that did not fit the registry's real relationships or service-level requirements.

This was a tradeoff, not proof that every generic query language is unsafe. RFC 3707 and its status record captured the CRISP requirements that preceded IRIS, including searches, distributed referrals, versioning and abusive users. RFC 3981 applied those concerns to a particular public-registry architecture. The frozen record contains no measurements of abuse frequency, implementation cost or adoption.

Even the generic referral machinery preserved differences in evidence. An entity reference meant that a server had specific knowledge of another entity. A search continuation meant that another authority might hold what the client sought — or might return something else or nothing. Clients were advised to follow either response only once because repeated traversal could create a referral loop. Receiving a continuation therefore did not prove that the referent was reachable, authoritative for the desired record or capable of producing an answer.

The error vocabulary kept further boundaries visible. invalidName concerned syntax; invalidSearch concerned semantic meaning; queryNotSupported described server capability; limitExceeded described allowed resource use; nameNotFound described the selected index; and permissionDenied meant the supplied authentication did not authorize a result entry. A valid XML message could still be the wrong query, an unsupported query, an expensive query, an unauthorized query or a lookup for an absent name.

Transport modularity followed the same discipline. RFC 3983 and its status record mapped IRIS onto BEEP. RFC 4992 later updated RFC 3981 with a TCP transfer protocol that pipelined XML in chunks; its status, errata and Datatracker record establish that update. Neither transport turned the core into a universal registry schema. Authentication and framing could change without acquiring authority over what a domain or address query meant.

The current IANA URI Schemes registry records iris and related transport schemes, while the IETF XML Registry retains the iris1 namespace. Those are durable protocol-registration facts. They are not evidence of a live server, broad deployment, a successful query or a causal story about later registration-data protocols.

RFC 3981's historical contribution was therefore architectural restraint. It standardized how different registry systems could identify types, exchange envelopes and point beyond themselves without claiming that their contents shared one vocabulary or graph. The universal client remained a lure because syntax could be common while understanding stayed local.

Sources