Summary

  • RFC 3982 gave empty registry values two different explanations: private meant the content might never be published, while denied meant policy withheld it at the requester’s current access level.
  • It also qualified disclosed values with specialAccess and doNotRedistribute, separating permission to see data from permission to circulate it; the labels communicated policy but did not enforce it cryptographically or legally.

Picture a domain-registration record with an empty contact field. An abuse responder may read it as “no contact exists.” A privacy officer may read it as “the contact exists but is protected.” An authenticated investigator may read it as “my current account lacks access.” Those are not cosmetic variations. They lead to different escalation paths, different evidence statements and different decisions about whether another request could succeed.

RFC 3982 turned that ambiguity into protocol data. Its status record, errata record and Datatracker history place the January 2005 Standards Track specification in the IRIS family. It defined the domain-registry type: structured queries and results for domains, hosts, contacts, registrars and registration authorities. Its most durable idea was smaller than the whole system. Absence acquired types.

The requirement had already been written down. RFC 3707, with its status, errata and Datatracker record, described what the Cross Registry Internet Service Protocol needed to express. An operator could omit a value without explanation, state that authorization was insufficient, or state that privacy barred disclosure regardless of authorization. When a value was returned, the protocol had to support two labels: do not redistribute and special access granted. Both could apply at once.

That vocabulary answered a real limitation in the baseline. RFC 3912 documented WHOIS as a text request and text response over TCP port 43. Its status page, errata page and Datatracker record do not describe a structured field model. The specification itself says WHOIS lacked strong security, access control, integrity and confidentiality. Operators could put policy language into human-readable responses, but the wire protocol offered no common machine-readable way to preserve the reason for a missing field through parsers, caches and exports.

RFC 3982’s privacy labels applied to typed result values. A relevant element could be present with content or present with nil content. If it appeared without content, it had to carry at least one of two Boolean attributes. private said the content was absent because it might never be published. denied said policy did not allow disclosure at the current level of access.

The temporal difference matters. private described a durable publication boundary. Asking again with a more privileged credential was not promised to change it. denied described the relationship between policy and the present access context. A different authenticated class might be permitted to receive the value. Neither label meant the datum was missing from the registry, and an omitted element still had no standardized explanation.

Returned content had its own pair of labels. specialAccess said the value had been supplied because the recipient held special access rights. doNotRedistribute said the content should not be passed onward. One concerned why the recipient could see the datum; the other concerned what the recipient should do next. The specification allowed them together because privileged access and downstream handling are different decisions.

This is where many modern data pipelines quietly reverse the protocol’s meaning. XML is converted to a relational row, a blank value becomes an empty string, and attributes disappear. Or a privileged value is copied into a spreadsheet while its no-redistribution instruction is left behind. The visible cell survives; the policy state does not. A system can therefore be syntactically faithful and operationally false.

The labels were not magic enforcement. RFC 3982 added no new security precautions beyond IRIS. RFC 3981 and its status record placed query permission in the core and relied on application transports for authentication and privacy. RFC 3983 and its status page supplied a BEEP transport mapping. A Boolean attribute could tell a compliant client that onward redistribution was barred; it could not prevent copying, authenticate an account, encrypt a session, create a legal duty or prove that enforcement would follow.

The domain schema nevertheless made the field-level state useful. RFC 3982 represented domain status, lifecycle dates, contact details, hosts and authority references as structured elements. The policy label travelled with the value it qualified. That placement avoided a page-level privacy flag that would force every field into one visibility category. It also allowed a result to mix ordinary public facts, permanently private fields, currently denied fields and privileged disclosures.

A later standards effort shows why the distinction did not go away. RFC 9083, with its status, errata and Datatracker history, defines the JSON response model for RDAP. RFC 9537, together with its status, errata and Datatracker record, later standardized explicit redaction signals.

RFC 9537 states the ambiguity directly: an RDAP field may be absent because the data does not exist or because the client lacks privilege. Its extension can identify removal, empty-value, partial-value and replacement-value redaction, name the affected field and state a reason. It rejects generic placeholders such as XXXX because they are inconsistent and unreliable signals. It also warns that a redaction marker can reveal that a datum exists, so a server may omit the marker when existence itself is sensitive.

That later work should not be presented as a proven line of descent from IRIS. The official records here do not establish that genealogy. What they show is a recurring systems problem: blankness is not a sufficient evidence model. RFC 3982’s answer was to attach policy meaning to the field. RFC 9537’s answer was to describe the redaction operation and reason. Both resist the same destructive compression.

For an operator, the practical rule is simple and demanding. Preserve the value, the reason for absence, the access context and any onward-use restriction as separate data. A cache should not convert denied into “no record.” An authenticated export should not turn specialAccess into “public.” A screen should not hide doNotRedistribute merely because it can display the value. The protocol’s history is a warning about evidence loss: the blank cell is often the end of a pipeline, not the beginning of an explanation.

Sources