Just because it's an Internet Draft doesn't mean anything at all (2014)

I contained my snarfing until:<p>&quot;The ordinals 17, 42 and 6.12 are reserved to reduce confusion.<p>The ordinals 18 and 19 are reserved for the strings &quot;Reserved&quot; and &quot;Unassigned&quot; respectively.<p>Unfortunately the ordinal 20 was used by two earlier, competing proposals, and so can mean either &quot;Color&quot; or Colour&quot;. Implementations are encouraged to disambiguate based upon context.&quot;<p>At which point I audibly snarfed.

&quot;This all worked really well until approximately 1600BCE, at which time the fleeing Atlanteans brought mass quantities of lightly tanned eel leather into Egypt, causing the collapse of straight razor sharpening market.&quot;<p>I really admire people who can write a story like this off the top of their head.

&quot;Unlike most IETF efforts, this document is not embarrassed to clearly state that we are simply shuffling more stuff in while we have the editor open.&quot;<p>Classic.

I thought that was already fairly well known via things like &quot;IP over Avian Carriers&quot;.

To be fair, that&#x27;s also true of RFCs as. (E.g., IP over carrier pigeon). But that doesn&#x27;t really matter.<p>Take HTTP for example. The is no ISO standard, just a smattering of overlapping RFCs over the years with weird spellings (Referer) and ambiguities (GET request entity).<p><i>And the entire web is based on HTTP.</i><p>The quality of the &quot;specification&quot; documents is not high, nor very official, but it&#x27;s the best we have, so people treat it as if it were.

&gt; From -02 to -03<p>&gt; o This Change note was added. Nothing else changed.<p>This comment contains no commentary.

In addition to the point made in the article, even some RFCs do not indicate &quot;what the IETF thinks&quot;. And I&#x27;m not just talking about April 1st RFCs.<p>The IETF has the &quot;Independent Submission Editor&quot; stream of RFCs, which produces RFCs without getting IETF consensus. These RFCs are considered to be work &quot;outside&quot; of the IETF, but can still be published as an RFC.<p>A recent example is <a href="https:&#x2F;&#x2F;tools.ietf.org&#x2F;html&#x2F;rfc8674" rel="nofollow">https:&#x2F;&#x2F;tools.ietf.org&#x2F;html&#x2F;rfc8674</a> from Mark Nottingham:<p><pre><code> The mechanism described in this document does not have IETF consensus and is not a standard. It is a widely deployed approach that has turned out to be useful and is presented here so that server and browser implementations can have a common understanding of how it operates.</code></pre>

RFCs are just a way for big corporations to collaborate on shared standards. It doesn&#x27;t mean that other approaches can&#x27;t become standards as well. It&#x27;s kind of disturbing that RFCs seem to give projects automatic trustworthiness that they didn&#x27;t actually earn.

But it&#x27;s expired...

&gt; Each one of there tokens ...<p>What are &quot;there tokens&quot;? Aw come on. How do you expect me to take any of this seriously with grammatical mistakes like this?

If HN guidelines are considered to allow it, I suggest tweaking the title here to say &quot;Internet Draft&quot; rather than just &quot;ID&quot;, which is unambiguous in the original context (i.e., a thing that actually <i>is</i> an Internet Draft) but not as an HN title.