Summary

  • RFC 3983 called an IRIS BEEP channel ready after its profile was accepted, but that state established a messaging capability, not server identity, user identity or permission to receive registry data.
  • Authentication itself was layered: a registry type could specify a server-authentication method, use a basic TLS authority-name procedure or declare none; encryption and user authentication were separate tuning choices, and referrals created their own credential boundary.

There is a moment in RFC 3983 when a channel becomes ready. A client has offered one or more BEEP profiles. The server has accepted a profile. The channel has been created. IRIS messages may now cross it, and the server must honor queries for the registry types it advertised. The state sounds conclusive because modern dashboards train operators to read “ready” as the end of a negotiation. In this specification, it was only the beginning of several different questions.

The RFC Editor status record, errata record and Datatracker history establish the January 2005 Standards Track document. RFC 3983 mapped the Internet Registry Information Service, IRIS, onto the Blocks Extensible Exchange Protocol, BEEP. These records say what was standardized. They do not say how many deployments existed or whether any service remains reachable.

The transport was chosen for its existing machinery. BEEP already addressed framing, authentication, connection management and negotiation, with toolkits and operational experience available to implementers. An IRIS-only transport would have had to rebuild similar pieces. HTTP brought features but also, in the authors’ view, ambiguity with Web applications and uneven TLS practice. Direct TCP lacked the negotiation characteristics needed when a referral-driven client crossed servers operating with different parameters. This was a stated design judgment, not comparative performance measurement.

The profile identifier carried two axes at once: an IRIS schema version and a registry-type URN. During channel creation, a client could offer multiple profile elements, allowing the parties to negotiate the IRIS version used for each served registry type. Profile acceptance therefore established an agreed message context. It did not establish who the remote authority was, who the user was or what data that user could see.

Even “honor queries” had a bounded meaning. A registry type could define its own BEEP-compatible message pattern, but it had to support the default pattern for the IRIS lookupEntity operation. Under that default, the client sent a valid IRIS XML instance in BEEP MSG; the server returned an IRIS XML instance in RPY, while BEEP ERR carried transport-profile faults. A reply could still contain a registry-layer denial, an unsupported query or another non-result state supplied by the IRIS core whose status page records the layer above this transport. Readiness made an exchange possible; it did not predetermine its answer.

Server identity required its own convention. When the BEEP TLS tuning profile was used, each registry type was encouraged to define how a server represented the authority named in the IRIS URI. If it did not, RFC 3983 supplied a basic method. The client placed the requested authority into BEEP’s serverName. The server returned an X.509 certificate containing that authority. The certificate then had to pass two different checks: cryptographic verification under TLS and a name match against the requested authority, first through subjectAltName dNSName, then through specified subject-name forms.

Those two checks should not be collapsed. A cryptographically valid certificate can be valid for a different name. A matching string without a verified certificate chain is not authenticated identity. The basic procedure bound the authority the client intended to reach to the identity the server presented. It did not merely turn on encryption and infer the rest.

The registry-definition checklist made the separation explicit. Every registry type using this mapping had to state its BEEP message pattern. It also had to define a TLS server-authentication method, choose the basic method, or expressly declare that it used no server authentication. A valid IRIS profile URI and accepted channel therefore could coexist with an architecture that had deliberately selected no server authentication. “Ready” could never serve as shorthand for “server authenticated.”

User identity occupied yet another plane. RFC 3983 listed SASL DIGEST-MD5 and OTP tuning profiles for user authentication without session encryption. It listed TLS cipher uses for encryption alone, and separate client-certificate uses for encryption plus user authentication. Anonymous access could mean that no authentication tuning profile had run, or that the SASL anonymous profile had. The combinations matter: encrypted was not synonymous with user-authenticated; server-authenticated was not synonymous with user-authenticated; an identified user was not automatically authorized for a particular result.

This modularity came from BEEP itself. RFC 3080, with its status, errata and Datatracker record, defined profiles, channels, messages and tuning. RFC 3081 and its status record mapped that framework to TCP. A tuning operation could alter the session’s security state; it did not retroactively turn all the other state variables into one verdict.

The contemporary references sharpen the historical boundary. RFC 2246 and its status specified TLS 1.0. RFC 2222 and its status record supplied the SASL framework then cited. RFC 2817 with its status, and RFC 2818 with its status, represented the two HTTP/TLS approaches that RFC 3983 discussed. These documents explain available mechanisms; they do not prove a particular IRIS connection used them correctly.

Referrals exposed the cost of confusing channel properties. IRIS expected clients to move among servers as a normal course of operation. RFC 3983 warned that a client should not hand credentials to an untrusted referral target. It advised against SASL PLAIN and forbade its use before the TCP session was encrypted. Encryption protected credentials in transit, but it did not establish that the recipient deserved them. The referral target’s identity and trust still had to be evaluated.

A later transport confirms that the messaging layer remained replaceable. RFC 4992 and its status record added the XPC TCP transport and updated the IRIS core. That documentary sequence does not establish why an implementation chose one mapping, nor does it prove BEEP’s adoption or abandonment.

The current IANA URI Schemes registry preserves the iris.beep registration, and the IANA BEEP Parameters registry preserves the profile and tuning namespace. A registration is evidence that a protocol name was allocated. It is not evidence of a ready channel, a matching certificate, an authenticated user or an authorized answer.

RFC 3983’s most useful historical lesson is the modest scope of readiness. A channel could be negotiated, open and capable while identity remained absent, partial or separately configured. Operations that compress all of those states into one green light lose the architecture’s central honesty: connection, confidentiality, identity, authority and result are different receipts.

Sources