> I have trouble figuring out what's what in IETF standard-making terminology As one might expect, they have a best current practice for that: https://datatrac

> I have trouble figuring out what's what in IETF standard-making terminology As one might expect, they have a best current practice for that: https://datatracker.ietf.org/doc/html/rfc2026 https://datatracker.ietf.org/doc/html/rfc2026 You have internet drafts and RFCs, where RFCs are assigned numbers and are immutable. Internet Drafts are time limited and typically used for work in progress. You have two tracks - informational (for things which are intended to document things but not be standards, including vendors documenting extensions to protocols) and standards track, which has maturity levels like proposed standard. You could say the goal of both tracks is interoperability, while standards track is motivated by having everyone's comments be heard and respected (to the degree possible). Labels like "proposed standard" are basically meant to mark the maturity in the standards process. A future revision might clarify or change the RFC, or the proposed standard might be replaced by something different. A more material example of this progression: HTTP/1.1 was released as: 1. RFC 2068 (proposed standard, January 1997) 2. RFC 2616 (draft standard, June 1999) 3. Reworked through the BIS process into several RFCs (7230-7235, proposed standards, June 2014) 4. Replaced by RFC 9110 and 9112 (and friends) (Internet Standard, STD 97, June 2022) But note these are all revisions of HTTP/1.1 - HTTP/2 and HTTP/3 have developed independently and have their own maturity levels. This is one of the ways that standards differ from software. There have been several documents about HTTP/1.1, all of which aimed to provide maximal backward compatibility with previous deployments, and to clarify and prescribe behavior where there were implementation, interoperability and operational difficulties identified. None of them were HTTP/1.2.