By 1995, the RFC series had been running for 26 years and comprised nearly 2,000 documents. Along the way, a persistent misunderstanding had taken root in the industry: people were citing any RFC as if its publication implied endorsement by the IETF as an Internet standard. Vendors would advertise "RFC compliance" for protocols that were experimental, informational, or even satirical. This short, pointed document from three of the Internet's most authoritative voices was written to set the record straight.

The core message is right there in the title. The authors explain that the RFC series is a publication venue, not a standards track. An RFC number confers nothing beyond the fact that a document was formally archived. To understand a document's actual status, you must look at its category label:

• Standards Track (Proposed Standard, Draft Standard, Internet Standard) — has consensus through the IETF process
• Informational — published for the community's convenience; no endorsement implied
• Experimental — part of research; may be widely deployed or may vanish
• Historic — superseded or abandoned
• Best Current Practice (BCP) — operational guidance, not a protocol

The RFC drives home an uncomfortable truth: some very influential technologies (in 1995, things like MIME extensions and various vendor protocols) were Informational, while some Proposed Standards languished with no implementations. Ubiquity and standards status are orthogonal. The document also notes that the RFC Editor accepts submissions from individuals independent of the IETF process — anyone can, in principle, get an RFC published, and this has produced everything from serious protocol proposals to RFC 1149 (IP over Avian Carriers).

The design decision being defended here is that the RFC series should remain an open publication channel rather than being gate-kept to only standards. Jon Postel had run the series since RFC 1 in 1969 with a deliberately light editorial hand, believing that preserving the historical record — including bad ideas, dead ends, and alternative proposals — was more valuable than a curated standards library. RFC 1796 is essentially Postel and colleagues defending this openness while asking readers to be more careful consumers.

Why it still matters in 2026: the confusion has never gone away. Security auditors regularly cite Informational RFCs as if they mandated behavior. Procurement documents demand "RFC 7748 compliance" without realizing what track it's on. LLM-generated code frequently invents behavior by conflating RFC categories. And the DNS, HTTP, and TLS ecosystems all contain widely-implemented Informational RFCs (like RFC 6376 DKIM's original spec quirks, or various draft-* behaviors documented after the fact) that are treated as gospel.

The document also foreshadows the modern Independent Submission Stream, formalized later in RFC 4846 and RFC 5742, which cleanly separates IETF-consensus documents from individual contributions. Today's RFC header prominently displays "Category" and "Stream" precisely because RFC 1796's authors won this argument — but only in the metadata. Human readers still skip past it.

There's a small irony worth noting: RFC 1796 is itself categorized as Informational. It has no standards weight. It simply exists to inform. Which is, of course, exactly its point.