Summary

  • RFC 812 defined NICNAME/WHOIS in 1982 as a human-readable directory for locating network users. RFC 954 widened the searchable population in 1985, but neither specification made a returned name, handle, organisation, host, or contact field proof of legal entitlement or current operational control.
  • Four record families developed along different paths: personal-directory entries, DDN host and network contacts, domain registrations and their public WHOIS displays, and number-resource registry records. Their common query interface did not turn them into one continuous title system.
  • A December 1990 incident provides direct evidence of operational reliance and limited responsibility attribution: a DDN NIC network record guided affected sites and CERT/CC toward an institution, while logs, local administration, and direct investigation remained necessary to identify the machine and operator.
  • A February 1996 dispute over the CLUE.COM registration provides a completed case of administrative standing in Network Solutions’ underlying registration procedure. The recorded registrant received notice, challenged the threatened change, and obtained an injunction preserving the registration. The judicial record does not show that a public WHOIS lookup independently created that standing.
  • The Kremen litigation documents a different October 1995 collision: Network Solutions changed its authoritative registration database after receiving a forged instruction, producing practical use consequences. Public WHOIS could reflect the altered state, but the evidence does not show that a public lookup caused the change or conferred ownership.
  • By 1996, number-resource registration and reassignment data were prescribed inputs to operational contact and additional-allocation decisions. RFC 2050 nevertheless required supporting documentation, protected applicant-designated sensitive material, and provided review through the registry hierarchy. No case examined here shows a public number-resource row alone deciding entitlement.

Reading the schema before reading authority into it

The early specifications are best approached as schema archaeology. Before asking when WHOIS became evidence, it is necessary to ask what its records were designed to contain, who was expected to appear, and what a response purported to do.

RFC 812, written by Ken Harrenstien and Vic White and dated 1 March 1982, described NICNAME/WHOIS as a transaction-based query-and-response server on the SRI-NIC machine. It provided a network-wide directory to ARPANET users on behalf of the Defense Communications Agency. A user sent one command line, received a response, and disconnected. The reply was intended for a human reader rather than for automated interpretation.

The expected population was personal. The Defense Communications Agency requested registration of each individual who had a directory on an ARPANET host and could pass traffic across the network. Registration information included a name, institutional or postal contact details, a telephone contact, and a network mailbox. Those fields show how much personal reachability information the service exposed, but reproducing real entries is unnecessary. Their original function was discovery.

RFC 954, written by K. Harrenstien, M. K. Stahl, and E. J. Feinler and dated October 1985, retained port 43 and the one-query, one-response architecture. It described the service as a directory for Internet users and again said that its output was human-readable. Its searchable population was wider: registered people and mailboxes, network organisations, DDN nodes and associated hosts, and registered MILNET terminal-access users.

The fields already performed different jobs. A name helped a user find a person. A handle distinguished that person from others with similar names and acted as a reusable database reference. An organisation supplied an affiliation. Mailbox and telephone fields provided communication channels. Host and node associations located a person within network operations.

None of those propositions, by itself, said that the person remained employed by the organisation, could bind it, controlled every associated system, or possessed a legal or contractual right in an Internet identifier.

The difference between a directory and an evidentiary system lies partly in what surrounds the displayed fields. An evidentiary system prompts questions about provenance, authority to submit, authentication, effective dates, superseded versions, contested corrections, reasons for change, and review. RFC 812 and RFC 954 specified the public query service. They did not specify a public audit trail answering those questions.

That omission must not be exaggerated. A protocol document is not a complete operations manual. The absence of an authentication rule in the query specification does not prove that NIC personnel accepted every update without correspondence, telephone checks, established site relationships, or human judgment. It establishes something narrower: a recipient of the public reply was not given a standardised account of who supplied each field, how that person’s authority had been tested, which earlier values had been displaced, or whether another party disputed the current record.

Five components must therefore remain separate:

  1. the institution’s underlying registration or identification database;
  2. the public WHOIS response generated from that database;
  3. the procedure by which a registration or contact was added, changed, or deleted;
  4. operational systems associated with the identifier, including host administration, routing, and DNS delegation;
  5. contracts, allocation correspondence, organisational appointments, consent, and legal records outside the database.

Conflating those layers makes the public lookup appear more powerful than the historical evidence permits. A WHOIS response could describe a registration. A registration transaction could change a registrar’s authoritative database. A separate operational change could alter DNS service or network use. A court or registry could later decide whether the transaction was valid. Those were related events, not one event.

The evidentiary ladder examined here is:

directory convenience -> operational reliance -> responsibility attribution -> administrative standing -> entitlement-like inference

Each upward step requires more than a specification showing that a field existed. It requires a dated actor, a particular record, a decision, a competing source of truth, and an observable result. Where the archive supplies only a prescribed procedure, the conclusion must remain a documented expectation rather than a completed act of reliance.

Name and handle: the personal-directory record

The first record family was a directory of people.

What the fields were for

The name field answered the simplest question: which person is being sought? The handle made that answer more stable inside the database. A user could search broadly and then select a particular entry by its handle. Other records could point to the handle without reproducing every contact field.

That was an important technical achievement. Names are not unique, initials vary, and organisational affiliations change. A durable identifier reduced ambiguity within the NIC’s records. It was strong evidence of which database row a user had selected.

It was not an identity credential. RFC 812 and RFC 954 did not describe documentary identity proof, a signature linked to the handle, or an external authority certifying every affiliation. A handle established continuity in the database more clearly than continuity in the person’s employment, responsibilities, or legal capacity.

The organisation field was similarly descriptive. It helped distinguish people and indicated where they could be found. A record could accurately report an institutional association when entered and become stale after a transfer, reorganisation, or departure. The field did not contain an employment agreement or delegation of authority.

Submission, update, and authentication

RFC 812 instructed individuals to send registration information to the NIC. RFC 954 used a registrar channel for comparable submissions. The specifications identify the expected subject and destination of the information, but they do not describe a separate authenticated update protocol.

The surviving specifications support the following limited audit:

  • Submitter and provenance: information came from an individual seeking or required to be registered with the NIC.
  • Update authority: the RFCs do not state a comprehensive rule for deciding who could replace an existing person record.
  • Authentication: no uniform identity-verification method is specified in the public protocol documents.
  • Correction: assistance and registration channels existed, but the RFCs do not describe a contested-correction procedure.
  • Replacement and current time: the public reply represented the database’s current answer; the specifications do not define a per-record effective-time history.
  • Historical retention: no public sequence of prior values is specified.
  • Conflict review: the RFCs do not explain how staff would decide between incompatible claims concerning the same personal entry.
  • Privacy boundary: personal reachability information was deliberately exposed because personal discovery was the service’s original purpose.

Unknown does not mean nonexistent. Internal correspondence or staff practice may have supplied controls that the RFCs did not document. The defensible finding is that those controls were not part of the proof presented to a user of the public reply.

The rung this family supports

The personal-directory record directly establishes directory convenience. In 1982 and 1985, the identified user was an ARPANET or DDN participant searching for a person, mailbox, organisation, or host association. The decision was where to direct a message or enquiry. Competing sources included an employer directory, host account, site roster, telephone contact, or confirmation from the person or institution.

The sources examined here do not document a pre-1997 case in which the presence of a personal NIC handle, by itself, decided legal entitlement, organisational authority, or technical control. The field’s durability could invite those inferences, but its documented function remained discovery.

Host and network: the DDN operational-contact record

The second family connected people to machines, networks, and defined operational roles. Here the record began to carry more than reachability.

From affiliation to a duty to act

A remote operator facing a malfunction or security incident did not merely need the name of someone at an institution. The operator needed someone who could investigate a host, change a configuration, disconnect a system, or direct local personnel to do so.

Contemporaneous sources define that responsibility. The Domain Administrators Guide, RFC 1032, dated November 1987, distinguished the domain administrator from technical and zone contacts. The administrator was expected to coordinate and manage the domain and to possess authority to act or delegate. Technical and zone contacts maintained name-server software and data and worked with technical personnel elsewhere.

RFC 1173, dated August 1990, described the responsibilities of host and network managers. It was explicitly an informational summary of Internet “oral tradition,” not an IAB standard. Even with that limitation, its substantive test is revealing. It required responsible individuals for connected networks to be registered with the appropriate NIC and kept current. A network manager was expected to possess system-management access or authority to disable, disconnect, or stop forwarding traffic from a misbehaving system. A host manager likewise needed the authority, access, and tools required to control the host.

The record and the external reality were therefore linked but not identical. The record named the person. Actual privileges, physical access, employer authority, and local cooperation determined whether that person could perform the role.

The 2011 Guide to the SRI ARC/NIC Records provides a retrospective map of the collection and identifies materials concerning Technical Liaisons, Host Administrators, Node Site Coordinators, and other contact groups. It helps locate relevant records; it is not treated as contemporaneous proof of why every role was created or precisely what authority every holder possessed. Those propositions require period documents such as RFC 1032, RFC 1173, directives, registration materials, and operational reports.

A dated account of how contact files were maintained

A more precise operational record survives in Mary K. Stahl’s Descriptions of NIC Tables and Lists, a final report dated 5 April 1991. SRI International’s Network Information Systems Center prepared the report for the Defense Communications Agency under contract DCA200-90-C-0027, SRI Project ECU 1050, CDRL No. 027. It appears in the Computer History Museum collection titled Defense Communication Agency materials, 9 of 13.

The report identifies several distinct derivatives rather than a single undifferentiated WHOIS file.

Section 3.1, on report page 7, describes MILNET host-administrator files. Their data were extracted from the NIC WHOIS database. Initial information came from Network Change Directives, after which the NIC Hostmaster solicited corrections from Host Administrators each month. The derivative file was generated weekly.

Section 3.7, on report page 10, describes a file organising host administrators by network address. It likewise says that initial data came from Network Change Directives and were kept current through monthly online solicitations for corrections. The file was generated weekly.

The report also states that files and tables carried a version number or date of last update at the file level. That supplied useful temporal information: a user could identify a particular published generation. It did not necessarily provide a public history of every prior value for every contact.

For DDN host and network records, the audit becomes more concrete:

  • Submitter and provenance: initial host information could originate in Network Change Directives; later changes came from recognised Host Administrators, Node Site Coordinators, or network personnel.
  • Update authority: role holders were expected to submit corrections, and the Hostmaster solicited them. The report does not define every test used when a new correspondent claimed to replace an existing role holder.
  • Authentication: an established role and correspondence channel created procedural trust, but the report does not describe a uniform identity-proofing or message-authentication system for all updates.
  • Correction: monthly solicitations and voluntary submissions provided recurring correction routes.
  • Replacement and current time: weekly regenerated files and file-level versions showed publication cycles, not necessarily the effective date of each external organisational change.
  • Historical retention: the report describes current derivatives and their generation. It does not establish a public, complete, per-record sequence of superseded contacts and reasons.
  • Conflict review: the Hostmaster occupied an interpretive position, but the report does not describe a general adjudication procedure for competing claimants to the same role.
  • Privacy boundary: some operational derivatives contained extensive personal and role-contact data. Those details are not reproduced here.

The maintenance system was structured. It was not equivalent to a publicly inspectable chain of authenticated evidence. A current record could still lag behind a personnel change without anyone acting dishonestly.

Operational reliance and responsibility attribution in December 1990

An actual incident supplies the clearest pre-1997 movement beyond prescribed use.

In a paper presented at the 1992 USENIX Security Symposium, Alessandro Berni, Paolo Franchi, and Joy Marino described Internet security incidents in Italy. Their account states that two sites observed intrusion attempts associated with a network in Italy and contacted the CERT Coordination Center. During the response, the DDN NIC WHOIS database associated the network with the University of Milan.

The evidentiary elements can be stated without exposing historical contact details:

  • Date: December 1990, documented in the 1992 paper.
  • Actors: the affected sites and CERT/CC.
  • Record used: the DDN NIC network association and contact information.
  • Decision: which institution should receive the initial incident report and be asked to investigate before operators considered isolating the network.
  • Competing sources of truth: system and packet logs, routing information, actual administration of the implicated machine, local institutional records, and direct confirmation.
  • Result: the lookup identified a relevant institution and initiated contact, but the responsible machine administrator was not immediately established and communication remained difficult.

This case proves operational reliance. The record changed what responders did next: it selected an institution to contact.

It also supports a limited form of responsibility attribution. The network entry associated observed traffic with an organisational network and placed that organisation in the response path. It did not identify the individual who performed the activity, conclusively locate the specific machine, or prove who had the ability to stop it.

Logs established the observed events. WHOIS supplied an institutional association. Local investigation had to connect the traffic to a machine. Organisational authority and technical access determined who could act. The record was a bridge between an identifier and an institution, not a complete attribution system.

The evidence securely reaches operational reliance and responsibility attribution. It does not show that a public network-contact entry conferred standing in a contested administrative change or established entitlement to the network number.

Organisation, domain, contacts, and servers: the domain record

The third family placed several propositions into one visible record: an organisation, a domain name, differentiated contacts, and name servers. Their proximity encouraged later users to read them as a single statement of control. Historically, each had a different evidentiary basis.

The organisation and the domain

RFC 1032 instructed a domain administrator to submit a registration questionnaire and described the administrator as responsible for keeping the domain’s data current. Its verification section said WHOIS could be used to review the organisation associated with a domain, the domain name, administrative, technical, and zone contacts, and the listed name servers.

This was more than personal discovery. It was a prescribed use of WHOIS to compare a registration with the intended domain configuration.

Yet RFC 1032 also supplied contemporaneous counterevidence to any title theory. It said the NIC would not act as referee in local disputes over who had the “right” to register a domain. Such disputes were to be settled among the parties before registration. The NIC could answer technical questions but did not claim to adjudicate the underlying right.

The fields should therefore be read separately:

  • Organisation: the entity represented in the registration application.
  • Administrative contact: the person responsible for policy or organisational coordination.
  • Technical and zone contacts: the people responsible for name-server operation and related data.
  • Name servers: the systems intended to answer authoritatively for the domain.
  • WHOIS display: the registrar’s human-readable representation of recorded facts.
  • DNS delegation: the operational placement of the domain in the hierarchical naming system.

A public WHOIS answer could be compared with an application and active DNS. It could not, without further evidence, prove that the administrative contact still possessed corporate authority or that the organisation held every legal right implicated by the name.

RFC 1032 establishes a normative user and decision: in November 1987, a domain administrator was told to inspect WHOIS when checking whether domain data were correctly represented. The competing sources were the submitted application, superior-domain records, active DNS, and organisational appointments. The RFC does not document a particular administrator making that comparison and obtaining a recorded result. It proves expected operational verification, not a completed reliance event.

Domain correction in the 1991 DDN record

Stahl’s April 1991 report gives the domain-contact file a specific provenance. Section 3.8, on report page 10, says the DOMAIN-CONTACTS derivative drew information from domain-registration applications processed by the NIC Hostmaster and from corrections submitted by Domain Administrators. The raw data were stored in the NIC WHOIS database, and the contact file was generated weekly.

The report also distinguishes administrative, technical, and zone contacts. Those roles were not interchangeable merely because they appeared together.

The report supports a defined correction route but leaves other questions open:

  • a recognised Domain Administrator could submit a correction;
  • the Hostmaster processed the source application or correction;
  • a new weekly derivative could expose the changed current state;
  • the report does not state a universal authentication method for every correction;
  • it does not establish that every public user could retrieve all superseded contacts;
  • it does not describe a uniform procedure for adjudicating incompatible correction requests.

That is evidence of managed mutation. It is not evidence that a displayed administrative contact acquired legal authority merely by being displayed.

InterNIC’s 1993 request workflow

RFC 1400, dated March 1993, documented the transition of non-DDN registration services to InterNIC. From 1 April 1993, InterNIC WHOIS was to contain information on IP addresses, domains, autonomous system numbers, and individual points of contact associated with active nodes. General personal-directory coverage was no longer the central registration service’s main population.

The document also described a structured request process. A requestor submitted a template to an automated registration mailbox. A parser checked information that could be tested mechanically, including domain-name conflicts, and returned a verification or rejection message. The requestor reviewed how the parser had interpreted the submission. Corrections could be returned and rechecked. A satisfactory verification released the request for final processing by registration staff. An unanswered verification expired after seven days. A ticket number exposed the request’s status, and a WHOIS display could carry a last-updated date.

These controls improved form, timing, and traceability, but their modality matters.

The verification form went to the original requestor. RFC 1400 does not say that an existing administrative contact received it because a prior WHOIS listing conferred authority. The requestor’s procedural position arose from having submitted the request. The returned form verified the parser’s interpretation of the submitted data; it was not, by itself, proof that the requestor possessed legal authority to represent the organisation.

RFC 1400 also says that security issues were not discussed in the memo. That absence does not prove that staff used no telephone checks, paper records, prior correspondence, or institutional judgment. It prevents the automated workflow from being cited as evidence of a universal identity-proofing standard.

For the 1993 domain workflow:

  • Provenance: the system linked a request, requestor, parsed form, and ticket.
  • Authentication: the RFC does not specify a universal independent test of organisational authority.
  • Correction: parser errors and rejected submissions had an explicit correction path.
  • Time: ticket-opening information and a last-updated field supplied current temporal markers.
  • History: the public examples do not establish a complete sequence of submitted versions and staff decisions.
  • Review: registration staff performed final processing, but the RFC does not define adjudication of two competing claims.
  • Administrative standing: the document proves the original requestor’s place in that request, not standing acquired from an existing public contact field.

A bounded comparison from RFC 1591

RFC 1591, dated March 1994, concerned DNS structure and delegation. It is useful only as a domain-specific comparison.

The document required administrative and technical contacts for a delegated domain, but responsibility rested on more than a field. A designated manager was expected to serve the relevant community, operate the domain competently, respond to requests, maintain accurate and resilient service, and retain the support of significantly interested parties. A transfer of designated-manager responsibility required communications from both the old and new organisations, with affected parties also relevant.

In disputes over rights to a name, RFC 1591 limited the registration authority’s role to providing contact information and said registration did not create trademark status. It also contemplated review where parties could not reach agreement.

The dated actors were IANA, the higher-level manager, the old and new organisations, and affected parties. A contact record could identify whom to approach. A delegation decision depended on operational performance, agreement, communications, and review.

This is a comparison within DNS. It cannot establish ownership of an IP address block, and it does not prove that every second-level domain change followed the same process.

A completed administrative-standing case: CLUE.COM in 1996

Network Solutions’ July 1995 domain-name dispute policy prescribed notice and procedural options for the recorded registrant when a qualifying trademark claim was presented. Later descriptions of that policy, standing alone, establish procedure rather than completed reliance. A specific case supplies the missing evidence.

The 1998 opinion in Oppedahl & Larson v. Network Solutions describes the record surrounding adoption of the July 1995 policy. It identifies party admissions, the policy exhibit, and the policy’s response to a certified federal trademark registration identical to a registered domain name. The registrar could write to the domain registrant and offer specified options. That judicial account confirms the procedure, while also recording disputes over its application to existing registrants.

A separate, contemporaneous judicial proceeding documents the policy’s application to a particular registration. In Network Solutions, Inc. v. Clue Computing, Inc., the U.S. District Court for the District of Colorado recorded that Clue Computing held the CLUE.COM registration managed by Network Solutions and that Hasbro asserted a competing trademark claim.

On 1 February 1996, Network Solutions informed Clue Computing that its use of the domain might infringe Hasbro’s trademark. The registrar required Clue Computing either to produce a trademark certification or accept assignment of a new domain name. Clue Computing did not remain a passive name in a display. It responded as the recognised registrant, brought a state-court action against Network Solutions, and sought to stop the registrar from placing the registration on hold.

On 25 June 1996, the Boulder County District Court enjoined Network Solutions from changing the registration and use of CLUE.COM. Network Solutions had meanwhile filed a federal interpleader action, presenting itself as a stakeholder prepared to assign registration and use as the court directed. The federal court dismissed that action. It concluded that the existing state injunction prevented Network Solutions from placing the domain under federal control and that the dispute also implicated Network Solutions’ contractual duties to Clue Computing.

The evidentiary elements are unusually complete:

  • Date: notice on 1 February 1996, followed by the state action, June injunction, and federal decision in 1996.
  • Actors: Network Solutions, Clue Computing, Hasbro, the Boulder County District Court, and the federal district court.
  • Specific record: the CLUE.COM registration in Network Solutions’ authoritative registration system, together with the registrar’s dispute file and the competing trademark submission.
  • Decision: whether the recorded registrant had to produce qualifying evidence, accept a replacement name, face a hold, or obtain judicial protection.
  • Competing sources of truth: the registration record, Hasbro’s trademark evidence, the registration relationship, actual use, contractual duties, and court orders.
  • Outcome: the recorded registrant received notice, entered the procedural contest, and obtained an injunction preserving the registration while the dispute continued; the federal interpleader was dismissed.

This case demonstrates administrative standing inside the registrar’s underlying registration procedure. The current registration determined which party Network Solutions treated as the registrant whose use was threatened and whose response mattered.

It does not show that Network Solutions acquired the identity of that party solely by running a public WHOIS query. The opinion speaks to the authoritative registration managed by Network Solutions, the registrar’s policy, its correspondence, and the resulting litigation. Public WHOIS could expose registration and contact information, but the case does not establish that the public display created Clue Computing’s procedural position.

Nor did the registration decide the ultimate trademark question. Hasbro’s trademark record supplied a competing claim. Clue Computing relied on contractual and judicial process. The injunction preserved the status quo; it was not a final declaration that the public contact data proved ownership.

The administrative-standing rung is therefore proved, but only with an important qualification: it is proved for the registrar’s treatment of the party recorded in its authoritative registration system, not as a general constitutive power of public WHOIS fields.

The October 1995 collision: database mutation and practical control

The later federal appellate record in Kremen v. Cohen reconstructs a different October 1995 registration change.

Network Solutions received a letter purporting to authorise deletion of an existing domain registration and registration by another party. Acting on the letter, Network Solutions deleted the earlier registration from its database, registered the domain to a different organisation, and listed a new administrative contact. The letter was later found to be forged. The new registrant used the domain. When restoration was demanded, Network Solutions initially required a court order. Litigation eventually resulted in restoration of the registration.

The opinion was written years after the transaction. It is evidence of the reconstructed sequence and judicial findings, not a contemporaneous operations log.

Five realities must remain separate:

  1. Authoritative registration database: Network Solutions deleted one registration and entered another.
  2. Public WHOIS output: a query could display information derived from the current registration system, but the opinion does not say that a public lookup caused the change.
  3. Change procedure: Network Solutions acted on the submitted letter.
  4. DNS and use: the new registration was followed by practical use of the domain.
  5. Documentary and legal evidence: the apparent authorisation conflicted with genuine consent and was later adjudged forged.

The dated actor was Network Solutions. The specific record was its underlying domain-registration entry, not a public WHOIS response. The decision was to terminate one registration, recognise another, and later refuse administrative restoration without a court order. The competing sources were the original application, actual organisational authority, the disputed letter, testimony, and judicial findings. The result was a change in who could use the registration in practice, followed later by judicial restoration.

This is the strongest pre-1997 example in the material examined here of an entitlement-like consequence produced by mutation of an authoritative registration system. The registrar’s database operation did more than misdirect a message; it altered operative registration state and practical use.

It does not prove that public WHOIS itself transferred the domain, conferred ownership, or caused Network Solutions to act. At most, a public response would have reflected the changed state after the transaction. The constitutive operation occurred in the authoritative registration and DNS administration systems.

Nor does the case prove that every early update procedure was unauthenticated or unreliable. It documents one consequential failure involving a forged instruction. Generalising from it would exceed the evidence.

Network number, ASN, and contact: the number-resource record

The fourth family developed under different pressures: address scarcity, routing scale, delegation to providers and regional registries, and the need to identify networks during operational incidents.

The DDN network-contact precursor

Stahl’s April 1991 report described NETWORK-CONTACTS, a human-readable file for registered Internet network numbers. Section 3.10, on report page 11, says the information came from Internet-number registration applications processed by the NIC Hostmaster and corrections submitted by network coordinators. The raw data were stored in the NIC WHOIS database. The derivative was generated weekly.

The contact file joined a network number and network name to a contact and NIC handle. Its operational purpose was clear: move from a number to a responsible organisation or person. It did not contain the full allocation correspondence, provider agreement, utilisation evidence, or routing state.

This precursor should not be mistaken for a record created by a later regional registry. The institutional lineage continued, but the record’s operator and surrounding process changed.

The InterNIC population after April 1993

RFC 1400 placed IP addresses and autonomous system numbers, with associated points of contact, in the InterNIC service after the transition. That formalised an object-centred population: a person increasingly appeared because the person was linked to a registered infrastructure object.

The transition improved central discoverability, but the existence of an address or ASN object did not itself prove a right. Allocation correspondence, the registry’s administrative decision, provider relationships, actual routing, and continuing compliance remained separate.

RWhois as a design comparison

RFC 1714, dated November 1994, proposed the Referral WHOIS protocol for a distributed registry environment. It distinguished authoritative and cached answers, defined authority areas, and used serial values that changed when data changed. It also allowed registration operations and anticipated authentication information.

Those features show that designers recognised provenance, authority, replication, and mutation as distinct concerns. They do not prove that every production InterNIC or regional-registry update used the proposed mechanisms.

The authentication method remained open. RFC 1714 said further work was needed for unsupervised delegation and that more research was required for client authentication. Its formal security section did not analyse security issues. The document also allowed deleted data to disappear from a primary server rather than requiring permanent retention merely for secondary refresh.

RWhois is therefore a 1994 design comparison, not evidence of a universal deployed audit system. Its serial values tracked the state of an authority area; they were not necessarily a public explanation of who changed each object, under what authority, and why.

RFC 2050 and consequential registration data

By November 1996, RFC 2050 placed registration inside a broader allocation policy. It described a public registry documenting address-space allocations and assignments for uniqueness and troubleshooting. Providers were required to submit reassignment information promptly.

The document gave three reasons for those submissions:

  • operators needed to know who was using a network number and whom to contact about operational or security problems;
  • reassignment information helped demonstrate use of an existing allocation before additional address space was justified;
  • the data supported allocation studies.

RFC 2050 stated that no additional CIDR blocks would be allocated by a regional registry or upstream provider until approximately 80 percent of the reassignment information had been submitted. It also said that providers should retain documented justification for assignments and that unavailable documentation could affect future allocations.

This was a significant change in consequence. Registration was no longer only a directory entry created after an allocation. Maintaining reassignment data formed part of the provider’s continuing administrative obligations.

RFC 2050 nevertheless did not reduce allocation to a WHOIS row. A registry could require engineering plans, examine previous assignments, verify utilisation, request organisational documentation, and audit a request. It distinguished allocations to providers from assignments to end enterprises. It recommended treating provider-based addresses as loans tied to connectivity and warned that allocation did not guarantee routability. Transfers required regional-registry approval under the applicable criteria.

The record’s upper-rung significance is therefore normative rather than case-specific:

  • Dated policy: RFC 2050, November 1996.
  • Actors named by the policy: regional registries, local registries, providers, and requesting organisations.
  • Record: allocation, assignment, and reassignment data.
  • Decision: operational contact and whether demonstrated use justified additional address space.
  • Competing sources of truth: customer assignments, utilisation evidence, engineering plans, routing tables, provider contracts, organisational documents, and registry correspondence.
  • Specified consequence: insufficient reassignment information or justification could affect future allocations.
  • Limit: the source does not document a particular pre-1997 allocation file in which a named registry made and completed that decision.

RFC 2050 proves the policy relationship between registration and allocation. Without a case file, it does not prove how consistently the rule was applied or that a public WHOIS output alone decided a specific request.

Review and confidentiality outside the lookup protocol

RFC 2050 supplies two important limits that a WHOIS-centred account can miss.

First, section 6 gave an organisation a right to appeal a registry decision to the parent registry. The assigning registry was to make relevant documentation available. Further appeals could proceed up the hierarchy and, after other avenues were exhausted, to IANA for a final decision. Each registry was expected to document its appeal procedure.

Second, section 4.6 required an assigning registry to treat information specifically marked sensitive by a requesting organisation as confidential. Where privacy could not be assured, the parent registry could become involved in the assignment.

Neither control was a feature of the port 43 query protocol. The public registry and confidential application file were not identical datasets. The appeal record and public contact record were also different. A user inspecting WHOIS would not necessarily see the sensitive engineering evidence, the registry’s reasoning, or the documents transmitted on appeal.

For number-resource records, the audit is therefore:

  • Provenance: providers, local registries, or requesting organisations supplied assignments and supporting materials.
  • Update authority: RFC 2050 imposed prompt submission duties, but it did not specify a single technical authentication method for every update.
  • Authentication and verification: registries could audit and demand corroborating documentation; the public record did not expose all of that evidence.
  • Correction and replacement: the surrounding registry process could revise records, but RFC 2050 did not define a universal public version history.
  • Time: prompt submission was required; a current public row did not necessarily reveal the complete effective history.
  • Review: appeals proceeded through the registry hierarchy and could ultimately reach IANA.
  • Privacy: registration had a public operational component, while applicant-designated sensitive information was to remain confidential.
  • Entitlement: registration could affect allocation administration, but it did not guarantee routability or serve as a complete title instrument.

Comparing the four record families

The shared WHOIS interface concealed different evidentiary limits.

Record family Primary subject Strongest proved pre-1997 use Update and correction evidence Historical and review limits
Personal-directory WHOIS An individual and contact channels Directory convenience Registration information sent to the NIC; no comprehensive public update-authentication rule in RFC 812 or RFC 954 No specified public per-record version history or contested-identity review
DDN host and network contacts Hosts, networks, and responsible operational roles Operational reliance and limited responsibility attribution Network directives, monthly correction solicitations, voluntary updates, and weekly generated derivatives documented in the April 1991 report File-level versions did not necessarily expose every superseded field or conflict decision
Domain registration and WHOIS Organisation, domain, contacts, and name servers Prescribed verification; completed administrative standing in a registrar’s underlying 1996 registration procedure; practical consequences from a 1995 authoritative database mutation Domain applications and corrections; 1993 parser verification by the original requestor; registrar policy and correspondence No proof that public WHOIS alone authorised changes, created standing, or decided entitlement; disputes depended on agreements, trademark evidence, DNS, correspondence, and courts
Number-resource registration Network numbers, ASNs, allocations, assignments, and contacts Operational contact and policy-based influence on additional allocation Registration applications, coordinator corrections, prompt reassignment duties, audits, and supporting documents No identified pre-1997 case showing a public row deciding an allocation; confidential evidence, reasoning, prior versions, and appeal materials could remain outside the lookup

This comparison prevents two false histories.

The first would begin with the 1982 personal directory and treat every later registration object as an enlarged version of the same white-pages row. That ignores the distinct duties carried by host managers, domain administrators, registrants, providers, and resource contacts.

The second would start with a consequential domain-registration mutation and read its power backward into every earlier WHOIS reply. That ignores the difference between a public display and the authoritative system capable of changing a registration or delegation.

The ladder, with its limits exposed

The evidentiary ladder can now be tested against dated conduct rather than field names alone.

Rung Dated actor and record Decision Competing source of truth Result and limit
Directory convenience ARPANET and DDN users described in RFC 812 (1982) and RFC 954 (1985), querying personal and organisational entries Whom to contact or which record matched a name Employer directories, host accounts, site rosters, direct confirmation The service supplied a human-readable starting point; no entitlement consequence is shown
Operational reliance Affected sites and CERT/CC in the December 1990 Italian incident, using a DDN NIC network record Which institution to contact about observed traffic Logs, routing information, local administration, direct investigation The lookup guided the response toward an institution
Responsibility attribution The same responders, using the network-to-organisation association Which organisation should investigate and act Control of the actual machine and institutional authority Responsibility was attributed at network or institutional level, not conclusively to a machine administrator or user
Administrative standing Network Solutions on 1 February 1996, using the CLUE.COM registration and dispute file to notify Clue Computing Which recorded registrant had to answer the trademark claim and could contest a threatened hold or change Trademark evidence, registration relationship, actual use, contractual duties, court orders The recorded registrant received notice, litigated, and obtained an injunction; public WHOIS alone is not shown to have created that standing
Entitlement-like inference Network Solutions in October 1995, changing its authoritative domain-registration database after a purported authorisation Whether to terminate one registration, create another, and later restore the original state Genuine authority, original correspondence, disputed letter, testimony, judicial findings The database mutation produced practical use consequences; the case does not show that a public WHOIS lookup caused the change

Number-resource administration reached a related but less fully documented upper rung in RFC 2050. Registration and reassignment data were prescribed inputs to future allocation decisions. Without a completed case file, that remains policy evidence of expected administrative consequence rather than proof that a public row decided a particular request.

The result is asymmetrical. Directory convenience, operational reliance, and responsibility attribution are well supported by specifications and a dated incident. Administrative standing is demonstrated in a specific registrar procedure involving an authoritative domain-registration record. Entitlement-like consequence is demonstrated by mutation of that authoritative system. The available evidence does not show public WHOIS becoming a universal source of standing or title before 1997.

Where authority came from

WHOIS did not acquire force through technical protocol alone.

RFC 812 stated that SRI’s NIC maintained the service on behalf of the Defense Communications Agency. Stahl’s April 1991 report identifies a government contract, responsible contractor, deliverable, source database, and derivative files. RFC 1400 documents the transition of non-DDN services to InterNIC.

The Government Accountability Office’s legal history records that the National Science Foundation entered into a cooperative agreement with Network Solutions in 1993 to provide expanded and coordinated information services for the non-military Internet. Those services included second-level domain registration, while Network Solutions also cooperated with USC on root-zone management.

The database’s practical authority came from those institutional assignments, the registration services performed under them, and other actors’ willingness to treat the maintained record as current. Authority lay in an organisation’s recognised function and capacity to act on its database, not in the syntax of a port 43 response.

The GAO history also carries an evidentiary warning. It describes its conclusions as limited by an incomplete record and notes that key contract documents from the 1970s through the 1990s could not be obtained. The surviving agreements and reports locate services within federal sponsorship and contractor performance. They do not support a sweeping claim that a contract converted every contact field into legal title.

SRI-NIC, DDN-NIC, InterNIC, Network Solutions, IANA, and the regional registries were related institutions, but they were not interchangeable. Their constituencies, assigned functions, source materials, and records changed. Continuity of data did not guarantee that every inherited entry had been reauthenticated under a successor’s procedures.

Historically bounded privacy and correction costs

Privacy enters this history because the original fields were chosen for reachability.

The personal-directory service deliberately exposed enough information to find and contact individuals. DDN operational files could expose role holders and extensive contact channels because remote administrators needed to reach someone capable of acting. Domain records connected identifiable contacts to administrative and technical functions. Number-resource records connected network identifiers to operational contacts.

The historical shift was not simply from private to public information. It was from a personal directory serving a relatively bounded community to infrastructure records consulted during incidents, registration changes, disputes, and allocation decisions.

That change increased the consequence of a stale role. A former contact could remain visible after an organisational change. A current technical operator might lack policy authority. An administrative representative might be authorised but unable to repair a machine. Monthly correction solicitation and weekly publication reduced delay in parts of the DDN system, but they did not guarantee that external reality and every derivative changed simultaneously.

The record also shows a narrowing of population. RFC 1400 said InterNIC’s individual records would principally cover points of contact associated with active nodes, while general personal-directory projects could be distributed elsewhere. By 1996, RFC 2050 distinguished public registration information from sensitive application material that registries were required to keep confidential when the applicant marked it as such.

Those were period-specific boundaries. They should not be rewritten as if a later registration-data architecture already governed 1982. The historical question is narrower: whether the amount and form of contact information remained proportionate after the fields began influencing decisions beyond discovery.

Reducing public information could also impose operational costs. The December 1990 incident shows why a central lookup mattered: it gave remote responders an institutional starting point. The record’s weakness was not simply that it exposed a contact. It was that an organisation-level association could be less precise than an incident demanded.

The policy problem was therefore not a simple opposition between openness and privacy. It was how to preserve role-specific reachability without treating the named person as the actor, controller, contractual party, or legal holder in every context.

Counterfactual A: authenticated, versioned, and expressly non-constitutive records

Suppose the same directory entries had been accompanied by stronger procedural authentication, retained prior versions, effective timestamps, recorded reasons for change, and an explicit statement that the fields described contacts rather than created rights.

This is a bounded design comparison. Controlled paper forms, retained correspondence, call-back procedures, dated logs, and institutional countersignatures were conceptually available during the period. A universal cryptographic identity system linking every network contact to an organisation was not an established requirement of RFC 812. Later assumptions about federated identity, automated certificates, or structured registration-data services must not be projected backward as duties the 1982 designers ignored.

Within that boundary, stronger controls would have improved several decisions.

A user could distinguish when a contact became current and whether the entry preceded a merger, resignation, provider change, or delegation dispute. Staff could identify the person who requested a mutation, the authority claimed, and the earlier record displaced. A contested party could challenge the precise transaction rather than merely confronting the latest public answer.

The October 1995 registration collision illustrates the value. If the registrar had required confirmation through an independently established channel, documented the submitter’s asserted authority, retained the superseded registration as a visible historical state, and separated the requested registration change from the resulting DNS action, the defective instruction might have been detected earlier or reversed more efficiently.

The safeguard would not have converted the directory into a title system. Authentication proves that an identified party made a statement. It does not necessarily prove that the party possessed corporate authority, that an agreement remained valid, that a provider relationship continued, or that a court would recognise the claimed entitlement.

Versioning has a similar limit. It can show that a field changed and preserve what preceded it. It cannot decide which state was legally correct. A reason code can explain why staff acted, but the reason may still depend on a forged document or disputed interpretation.

An explicit non-rights statement would have clarified institutional intent. RFC 1032 and RFC 1591 already supplied related substantive limits by refusing to arbitrate local rights or by separating registration from trademark status. Repeating such limits in the public response might have reduced careless inference.

Authority drift would probably still have occurred. Institutions favour records that are available, legible, and maintained by the body responsible for the service. A well-authenticated directory might attract even more reliance. The difference is that later users could better distinguish a contact assertion from an allocation, a registration from a contract, and a current display from the evidence supporting a change.

Counterfactual B: no directory, while underlying relationships survive

Now remove the public directory while leaving contracts, allocation correspondence, registration applications, routing operations, DNS delegations, organisational records, logs, and telephone networks intact.

Many decisions remain possible.

A registry can determine who received an allocation from its correspondence and decision file. A provider can identify its customer from a service agreement. A registrar can inspect an application and subsequent instructions. A domain administrator can examine the active delegation and authoritative name servers. An operator can inspect routing information and escalate through adjacent networks. A court can evaluate consent, organisational authority, agreements, trademark records, and testimony.

The missing function is rapid discovery across institutional boundaries.

In the December 1990 incident, the affected sites would still possess logs, but the path from a network number to a relevant institution would be slower. Responders might have to work through routing relationships, providers, or manual enquiries. The directory did not create the logs or the institution’s responsibility. It reduced the cost of finding the institution that might act.

In domain administration, DNS could show the operating name servers, and registration correspondence could show the original request. Without a common directory, finding the administrative representative would be harder. DNS operation would still not prove organisational consent.

In the CLUE.COM dispute, Network Solutions could identify its registrant from the authoritative registration file and correspondence even if no public WHOIS service existed. The registrar could still send notice, and the registrant could still invoke contractual or judicial remedies. This shows that administrative standing in that case did not depend uniquely on public lookup convenience.

In number-resource administration, a registry could evaluate an additional allocation through the application file and utilisation evidence. Without standardised registration and reassignment records, reconstructing earlier assignments and locating downstream contacts would be slower and less consistent.

This counterfactual identifies WHOIS’s distinctive value: it made heterogeneous relationships searchable from an identifier. It brought the first relevant person or organisation into view.

It also demonstrates why convenience should not be confused with constitutive authority. The underlying relationship could survive the directory’s absence. The directory made that relationship legible and actionable; depending on the system, the authoritative registration transaction, allocation decision, contract, or operational state remained elsewhere.

The 1997 threshold

ARIN’s institutional history states that it was established in December 1997 as an independent nonprofit providing IP registration services in its region. Its 1999 annual report dates the opening of operations to 22 December 1997.

Before that date, several propositions had become well supported:

  • a central query could associate people and organisations with Internet identifiers;
  • role-specific contacts were expected to be reachable and capable of acting;
  • Hostmasters used applications, directives, recognised administrators, and correction submissions to maintain records;
  • some DDN derivatives were regenerated weekly and supported by monthly correction solicitations;
  • operators used network-contact records to decide where to direct incident reports;
  • domain administrators were instructed to compare WHOIS data with intended registration and server information;
  • a recorded domain registrant could receive notice and occupy a consequential procedural position in a completed registrar dispute;
  • mutation of an authoritative domain-registration record could produce practical use consequences;
  • number-resource reassignment data were prescribed inputs to operational contact and subsequent allocation administration;
  • allocation decisions could be audited, appealed, and supported by confidential material outside the public registry.

Several stronger propositions remain unproved by the evidence examined here:

  • that every personal, host, domain, or number-resource update used a uniform identity-proofing method;
  • that every public record exposed a complete history of prior values and reasons for change;
  • that an existing public contact automatically possessed authority to confirm or replace a registration;
  • that RFC 1400’s original requestor was recognised because of a prior public contact listing;
  • that public WHOIS alone created Clue Computing’s administrative standing in the 1996 dispute;
  • that the Kremen registration change was caused by reliance on a public WHOIS query rather than by the registrar’s change procedure and database mutation;
  • that a public number-resource row alone decided a documented pre-1997 allocation request;
  • that a listed contact conclusively established present technical control, legal ownership, or contractual entitlement;
  • that DNS delegation established a right to an IP address block;
  • that a later regional registry maintained or authored records before it began operating.

The transition from convenience to authority therefore had no single date. Its strongest stages occurred in different record families.

Personal-directory WHOIS established convenient discovery. DDN host and network contacts moved into operational reliance and responsibility attribution. A completed 1996 domain dispute shows administrative standing attached to the registrar’s authoritative registration relationship, while the 1995 Kremen sequence shows practical consequences from mutation of that authoritative system. Number-resource policy made registration data relevant to future allocation decisions while retaining supporting documents, confidentiality, and appeal outside the public lookup.

The ladder’s upper rungs are real but narrowly located. Before 1997, the available record does not show public WHOIS becoming a universal title instrument. It shows something more fragile and institutionally revealing: a convenient contact layer becoming the first evidence consulted, the first frame placed around a problem, and the visible reflection of consequential decisions whose authority still came from databases, procedures, contracts, operational systems, and review beyond the lookup.

Sources