RFC 1796

RFC 1796: Not All RFCs are Standards 🌈

Okay bestie, this one is from April 1995 🌸 It came out of the Network Working Group, and the authors are C. Huitema (INRIA), J. Postel (ISI), and S. Crocker (CyberCash) 👑. The category is Informational 📖, and the title block doesn't list anything it obsoletes or updates ✨

---

Status of this Memo ✨

This memo provides information for the Internet community 💖 It does not specify an Internet standard of any kind 🙅 Distribution of this memo is unlimited, so share away 🦋

Abstract 🌸

This doc is about how the Request for Comments (RFCs) notes relate to Internet Standards 📚

---

Not All RFCs Are Standards 💅

The "Request for Comments" (RFC) series is the official publishing channel for Internet standards docs and other publications from the IESG, IAB, and the Internet community 📮 Every six months or so (for the last few years, anyway), somebody asks why we publish both Internet standards and informational docs as RFCs 🤔 The argument is usually that it causes confusion between "real standards" and "mere publications" 🙄

It's a super common misconception that getting published as an RFC gives you some level of recognition. It doesn't, or at least not any more than getting published in a regular journal 💀 Each RFC actually has a status based on its relationship with the Internet standardization process: Informational, Experimental, or Standards Track (Proposed Standard, Draft Standard, Internet Standard), or Historic 🏷️ That status is printed on the first page of the RFC itself, and it's also documented in the periodic "Internet Official Protocols Standards" RFC (STD 1). The problem is that the status often gets left out of quotes and references, and that can feed the confusion 😭

There are two main sources for the status of Internet standards 🔍 They're summarized periodically in an RFC called "Internet Official Protocol Standards," and they're documented in the "STD" subseries. When a spec gets adopted as an Internet Standard, it gets the extra label "STD xxxx," but it keeps its RFC number and its spot in the RFC series 🎀

Here's the tea: the relationship between STD numbers and RFC numbers is not one to one ☕ STD numbers identify protocols, and RFC numbers identify documents. Sometimes more than one document is used to specify a Standard protocol 🧩

To hype up the standardization status even more, the IAB proposes these actions 📣

• Use the STD number, rather than just the RFC numbers, in the cross references between standard tracks documents,
• Utilize the "web" hypertext technology to publicize the state of the standardization process.

More precisely, they want to add an "html" version of the STD-1 document to the current RFC repository, which is basically the list of Internet standards 🌐 They're also thinking about extending that doc to describe actions in progress, meaning standards track work at the "proposed" or "draft" stage 🚧

---

A Single Archive 📦

The IAB believes the community has really benefitted from having a single archival document series 🙌 Docs are easy to find and easy to retrieve, and file servers are easy to organize. That has been super important over the long term ✨ Experience shows that subseries, or series with limited scope, tend to vanish from the network 👻 And there's no evidence that alternate document schemes would result in less confusion 🤷‍♀️

Plus, the IAB thinks the presence of extra documents doesn't actually hurt the standardization process 💅 Their solution is to better publicize the "standard" status of certain documents, which is pretty easy now that networked hypertext technologies exist 🌈

---

Rather Document Than Ignore 🫶

The RFC series includes some docs that are informational by nature, and others that describe experiences 📝 A problem of perception happens when one of these docs "looks like" an official protocol spec 👀 Misguided vendors might claim conformance to it, and misguided clients might honestly believe they're buying an Internet standard 😬

The IAB's take is that the best help for misguided vendors and clients is to give them guidance 🧭 There's actually very little evidence of vendors purposely trying to pass informational or experimental RFCs off as "Internet standards" 🙅 If those attempts did happen, a proper response would indeed be required ⚖️

The IAB also believes the community is best served by openly developed specifications 🌸 The Internet standardization process guarantees openness and thorough review, and the normal way to develop the spec for an Internet protocol is indeed through the IETF 💜

The community is also well served by having access to specs developed outside the IETF standards process 🦋 That happens because the protocols are experimental, were developed privately, or failed to acquire the degree of consensus needed to get elevated to the standards track 🥹

The IAB's motto is basically that publication beats ignorance 📖 If a particular spec ends up in products deployed over the Internet, we're way better off if it's easy to retrieve as an RFC than if it's hidden away in some private repository 🔐

---

Security Considerations 🔒

🚨 Security issues are not discussed in this memo. 🚨 Literally none. Zero. Nada. So if security is what you're after, this doc isn't the place to look 💀

---

Authors' Addresses 💌

Christian Huitema
INRIA, Sophia-Antipolis
2004 Route des Lucioles
BP 109
F-06561 Valbonne Cedex
France

Phone: +33 93 65 77 15
EMail: Christian.Huitema@MIRSA.INRIA.FR


Jon Postel
USC/Information Sciences Institute
4676 Admiralty Way
Marina del Rey, CA 90292

Phone: 1-310-822-1511
EMail: Postel@ISI.EDU


Steve Crocker
CyberCash, Inc.
2086 Hunters Crest Way
Vienna, VA 22181

Phone: 1- 703-620-1222
EMail: crocker@cybercash.com