Summary

  • RFC 1302 defined four essential NIC functions: provide information, support users directly, maintain referral knowledge, and support the wider NIC infrastructure.
  • A NIC was to own an inquiry until resolution, but the document treated an answer, a referral and coordination with a NOC as different ways of resolving its handling obligation.
  • A timestamp, revision number and producing NIC made a resource inspectable; they did not by themselves prove that the resource was accurate, current or effective for the user.

A ticket can remain owned while the work travels

Imagine a user in 1992 sending a question to NIC@domain: a route will not work, a document cannot be found, or an address is unknown. The common mailbox was valuable because the user did not first have to discover the Internet’s institutional map. Someone accepted the question. That was already a form of continuity.

But acceptance did not make the receiving organization omniscient. RFC 1302 instructed each NIC to make a best effort and retain responsibility until an inquiry was resolved “in some way.” It then named three possible ends: answer the question, refer the user to the right information source, or coordinate with a NOC to solve a connectivity problem. Those outcomes belong in separate columns.

An answer records an informational act. A referral records a proposed path to another custodian. Coordination records that operational actors have been engaged. None alone proves that the next organization accepted the handoff, that a router changed state, that the supplied document was right, or that the user’s purpose was achieved. The NIC could own the continuity of the case without owning every event required to finish the world outside it.

The information centre was not the operations centre

RFC 1302 drew an institutional line before describing services. A Network Information Center provided informational, administrative and procedural support. A Network Operations Center oversaw and maintained daily network operations. One organization might perform both functions, and close cooperation was necessary, but the functions were not synonyms.

That distinction prevents an easy historical error. A help desk that knows an outage has been reported is not therefore the system that can repair a link. A NOC action is not automatically a useful explanation to a novice. A user-facing status message is not the underlying state transition. Where the two roles sit in one institution, their records still answer different questions: who received the report, who diagnosed it, who was authorized to act, what changed, and what the user later observed.

The separation also explains why RFC 1302’s security section emphasized procedures and contacts. NIC staff needed to know which groups handled incidents and how to connect users, response centres and NOCs. Awareness of the response path did not transfer incident command to the NIC.

Four functions made a federation, not a single oracle

RFC 1302 identified a minimum service surface. Every Internet NIC should provide information resources, support end users directly, collect and maintain referral information about other NICs, and support the NIC infrastructure itself. The first two were already common. The last two became necessary as the number of networks, users and information centres grew.

The document stated the reason with useful restraint: no single NIC could maintain comprehensive and current information about every Internet service and resource. The proposed nic-profiles database therefore described other NICs and their areas of expertise. It was a routing table for institutional knowledge, not a merger of institutions. A profile could indicate whom to ask. It could not prove that the target still had the answer, would accept the question, or controlled the relevant network.

Local variation remained explicit. Funding, staffing, service level and delivery mechanism were left to each organization and its user community. The shared minimum made cooperation more predictable without claiming uniform capacity. Standardizing the front door was not the same as centralizing everything behind it.

Provenance was designed into the document shelf

RFC 1302 described three ways a NIC could provide a resource. It might copy material from another site into a local repository, point the user to a remote location, or create the material itself. Only for the third case did the document say the creating NIC was solely responsible for content and accuracy.

For everything made available, the RFC recommended a timestamp, a revision number and the name of the producing NIC. It also asked the serving NIC to retain contact information for the source. These fields did important work. They let a reader distinguish a producer from a distributor, compare revisions and ask how old a copy was.

They did not make verification automatic. A new timestamp can accompany a wrong statement. An old but stable specification can remain correct. A local copy can be byte-for-byte faithful while the remote producer has issued a replacement. The metadata creates a route for checking authenticity and currency; it does not replace the check.

This is where RFC 1290 provides an adjacent boundary. Its guide described most entries as pointers to final information. A pointer made a route visible, not the destination present. RFC 1309 supplied another boundary: X.500 could present a unified directory while data remained distributed among custodians, copies, referrals and chains. RFC 1302’s NIC network belonged to the same institutional family, but its subject was human support responsibility rather than a directory protocol.

A common mailbox reduced search cost, not uncertainty to zero

The proposed NIC@domain convention was small and practical. A message should receive a human reply or an up-to-date machine response that performed triage. Consistent naming reduced the chance that a user would abandon a problem before finding any responsible surface.

Yet a machine triage response was only a classification event. It might direct one class of question to an information mailbox and another to an operational contact. A later audit therefore needs both records: what the front door returned and what the destination did. Treating the first automated reply as a substantive answer would turn availability of the support interface into evidence of resolution.

RFC 1302’s delivery table reinforces the point. Information could travel by FTP, email, bulletin board, printed copy, seminar, Telnet, telephone, postal mail, FAX, directory service, library service or person-to-person exchange. Each mechanism supported certain forms of material. None guaranteed receipt, comprehension, relevance or action. Transport and result were different dimensions even when both were called “service.”

Database accuracy required a relationship with the subject

The RFC’s database section was not merely a maintenance checklist. It recommended telling data suppliers why information was collected, how it would be used, what was mandatory or optional, what would be public, who could update it, how updates worked, and what refusal or revocation would mean. People whose personal information appeared publicly should know and should have an opportunity to change or revoke it.

NICs were urged to seek updates at least annually and publish the date of the last update. Annual solicitation was a process commitment, not a promise that every record remained correct on every intervening day. A last-updated date allowed uncertainty to be measured. It did not erase uncertainty.

The historical counterexample sits nearby in RFC 1261. During the 1991 transfer of NIC services from SRI to GSI, familiar contact and information surfaces were designed to continue, but changes to the master WHOIS database and all registration actions paused for five days. A reachable NIC, a working help desk and an active authoritative write path were separately observable conditions. RFC 1302 generalized the service architecture after that transition without dissolving those layers.

Sources

RFC 1302 describes a 1992 service model. It establishes no present NIC deployment, live case, referral success, NOC repair, database accuracy, security response or user outcome.