Summary

  • RFC 1700 called itself an October 1994 snapshot assembled from IANA's maintained files. RFC 3232 later made it Historic because its values had become incomplete and sometimes wrong, leaving the online registry as the current source.
  • A defensible claim about a protocol parameter should pair its live registry row and retrieval time with an immutable capture, registration policy and decision trail. The RFC explains provenance; it does not freeze the present.

Open RFC 1700 and the page still feels official. It has an RFC number, a standards status in its historical header, editors' names and hundreds of assignments laid out in solemn tables. A researcher facing a disputed code point could easily cite the document and believe the citation has settled the current fact.

The document itself warned against that reading. Published in October 1994, it described its contents as a snapshot of an ongoing assignment process. The current values lived in online text files; the RFC was produced by joining those files and adding the formatting needed for publication. The bound-looking artifact was a release, not the database.

Joyce K. Reynolds made that distinction unmissable in RFC 3232. By January 2002, the periodic Assigned Numbers RFC had not been republished for years. The online database at IANA had replaced it in practice. RFC 3232 moved RFC 1700 to Historic because the old values were incomplete and sometimes wrong.

That small administrative RFC established an important rule for internet evidence: permanence and currency are different properties.

The snapshot admitted what it was

RFC 1700, edited by Reynolds and Jon Postel, was not careless about its temporal boundary. Its introduction said it represented a snapshot of the assignments being maintained at the time. It also told readers where requests and corrections belonged: with IANA. Reynolds appeared as the contact for the coordination work.

Earlier volumes show how central that editorial labor was. RFC 900, another Reynolds and Postel edition of Assigned Numbers, did more than list values. It carried transitional states, references and instructions around changing network numbers. The tables were part of an operating process whose state could move between editions.

Print-like publication provided a stable citation. It also imposed a release cadence on data that changed independently of the release. Every new assignment created a gap between the maintained files and the last RFC. Corrections made the gap more dangerous: an old row could be not merely incomplete but affirmatively wrong.

RFC 3232 did not repudiate the archive. It clarified its evidentiary role. RFC 1700 is excellent evidence for what its editors published in October 1994 and for how the assignment system represented itself then. It is poor evidence for what a registry says today. Making it Historic protected both uses by refusing to collapse them.

A registry row carries a procedure

The move online was not simply a change from paper to web pages. Protocol-parameter values sit inside a governance arrangement. RFC 2860, the memorandum between the IETF and ICANN concerning IANA, says that IANA assigns and registers parameters within the IETF's scope according to criteria and procedures specified in RFCs. When those instructions are ambiguous, the IESG provides technical guidance; a dispute can reach the IAB.

The same agreement requires public, online information about current assignments and facilities for submitting requests. The registry is therefore both a publication surface and the visible result of an authorized decision process. A row is not made trustworthy just because it is recent. Its authority also depends on the namespace, the applicable policy and the path by which the assignment or correction was accepted.

RFC 8126 makes those paths legible. A registry definition should identify its name, required fields, initial contents, change control and policy for future registrations. “First Come First Served” asks whether a request is well formed and non-duplicative. “Expert Review” adds evaluation by a designated expert under published guidance. Specification Required, RFC Required, IETF Review and Standards Action impose different evidence and approval burdens.

This means two adjacent rows can look alike while resting on very different decisions. A scrape that saves only value and description erases the registration policy, change controller, reference and status that tell a reviewer how the row came to exist and how it may change.

Current is a time-bounded claim

IANA describes its function as maintaining authoritative public registries so globally used identifiers remain consistent. Its current institutional description says the IANA functions are performed by Public Technical Identifiers, an ICANN affiliate. That is a present-tense fact observed on 10 September 2026, not something RFC 3232 could establish for all time.

The same discipline applies to an individual assignment. “Current” always contains an unstated timestamp. A browser view can change after capture; a registry may add a row, mark a value deprecated, replace a reference or correct a clerical error. The stable URL identifies a moving publication, not an immutable version.

A serious evidence package should therefore preserve the registry's exact name and URI, retrieval time in an explicit time zone, the selected row or range, its displayed status and references, and a byte-level capture or content hash. If the registry offers structured data, keep the raw response beside any normalized table. If it does not, retain the HTML or other source artifact used to make the claim.

The package should also record the applicable registration policy and the decision evidence it points to. A request, expert assessment, IETF consensus document, IANA action and later correction are separate events. Joining them is useful; merging them into one undated “source” field is not.

Reynolds's precise intervention

The Internet Hall of Fame records Reynolds as a 2025 posthumous inductee, a longtime collaborator of Postel at USC's Information Sciences Institute and later a co-leader of the RFC Editor. She died in 2015. Those facts define a historical contribution, not a present office or a claim that she controlled today's registries.

Her authorship of RFC 3232 matters because the document came from someone who had helped turn changing assignment data into durable RFCs. Its lesson is not that archives failed. It is that a successful archive must state where its authority ends.

The RFC series preserves decisions, procedures and snapshots exceptionally well. The live registry preserves the maintained state. One answers “what was published and why?” The other answers “what does the operator report now?” A researcher needs both questions, and a data model capable of refusing to substitute one answer for the other.

A three-layer receipt

For a current-value claim, start with the live state: exact registry, row, status, reference, retrieval time and immutable capture. Next attach decision provenance: request, reviewer or consensus route, assignment action and any change controller. Finally attach the archival layer: the RFCs that created the namespace, set its policy or recorded an earlier state.

Version each layer independently. If a later fetch changes the row, retain both captures and calculate the difference. If a new RFC changes the registration policy without changing existing values, record that as a governance event rather than silently rewriting the old snapshot. If an erratum or correction alters the interpretation of an archival document, preserve that link too.

The result is more than a neat citation. It is a claim that can survive change. Reviewers can reconstruct what was visible, under which rule, at which time—and can see when a venerable RFC has been asked to prove something it never promised.

Sources