Just because it's an Internet Draft doesn't mean anything at all (2014)(tools.ietf.org)
tools.ietf.org
Just because it's an Internet Draft doesn't mean anything at all (2014)
https://tools.ietf.org/html/draft-wkumari-not-a-draft-06
38 comments
Its very easy after watching the ancient aliens season 1 pilot episode, believe me!
[deleted]
To be fair, that's also true of RFCs as. (E.g., IP over carrier pigeon). But that doesn't really matter.
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).
And the entire web is based on HTTP.
The quality of the "specification" documents is not high, nor very official, but it's the best we have, so people treat it as if it were.
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).
And the entire web is based on HTTP.
The quality of the "specification" documents is not high, nor very official, but it's the best we have, so people treat it as if it were.
I'd like to also share the legendary RFC 2795 for those not yet in the know: https://tools.ietf.org/html/rfc2795
> From -02 to -03
> o This Change note was added. Nothing else changed.
This comment contains no commentary.
> o This Change note was added. Nothing else changed.
This comment contains no commentary.
In addition to the point made in the article, even some RFCs do not indicate "what the IETF thinks". And I'm not just talking about April 1st RFCs.
The IETF has the "Independent Submission Editor" stream of RFCs, which produces RFCs without getting IETF consensus. These RFCs are considered to be work "outside" of the IETF, but can still be published as an RFC.
A recent example is https://tools.ietf.org/html/rfc8674 from Mark Nottingham:
The IETF has the "Independent Submission Editor" stream of RFCs, which produces RFCs without getting IETF consensus. These RFCs are considered to be work "outside" of the IETF, but can still be published as an RFC.
A recent example is https://tools.ietf.org/html/rfc8674 from Mark Nottingham:
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.> Each one of there tokens ...
What are "there tokens"? Aw come on. How do you expect me to take any of this seriously with grammatical mistakes like this?
What are "there tokens"? Aw come on. How do you expect me to take any of this seriously with grammatical mistakes like this?
Thank you for your review and comment. This oversight has been fixed, and new version posted: https://www.ietf.org/id/draft-wkumari-not-a-draft-08.txt
I'm planning on putting this on GitHub soon, so that issues can be filed, and, more importantly, pull requests submitted. Important work....
I'm planning on putting this on GitHub soon, so that issues can be filed, and, more importantly, pull requests submitted. Important work....
Yes, as i read it, my thought was “at least it's a draft; i wonder if an updated version with proper spelling and grammar was ever released.
(considering the document is a snarky comment about form, i think the usual proscription against snarky comments about form can be relaxed)
(considering the document is a snarky comment about form, i think the usual proscription against snarky comments about form can be relaxed)
But it's expired...
That's the sole reason you shouldn't use it as reference.
On the contrary; it permits it. Since its purpose was to prevant misattribution of internet-drafts to the ietf, we can surely now claim with certainty that the ietf teaches fake news about the demise of ancient egypt.
I contained my snarfing until:
"The ordinals 17, 42 and 6.12 are reserved to reduce confusion.
The ordinals 18 and 19 are reserved for the strings "Reserved" and "Unassigned" respectively.
Unfortunately the ordinal 20 was used by two earlier, competing proposals, and so can mean either "Color" or Colour". Implementations are encouraged to disambiguate based upon context."
At which point I audibly snarfed.
"The ordinals 17, 42 and 6.12 are reserved to reduce confusion.
The ordinals 18 and 19 are reserved for the strings "Reserved" and "Unassigned" respectively.
Unfortunately the ordinal 20 was used by two earlier, competing proposals, and so can mean either "Color" or Colour". Implementations are encouraged to disambiguate based upon context."
At which point I audibly snarfed.
Your snarfing was the impetus for my snarf. Ergo, not all snarfing originates from user Angostura, but all of user Angostura's snarfing has historically beget my snarfs.
I thought that was already fairly well known via things like "IP over Avian Carriers".
But that's an RFC, so it carries (very slightly) more weight than an Internet Draft. In the real world, what matters is whether it's implemented: https://www.blug.linux.no/rfc1149/writeup/
> In the real world, what matters is whether it's implemented
Yes, RFC 2324[1] is also serious business because it’s implemented in the real world. Or at least I have implemented HTTP 418 I’m a teapot. (I’ve also seen gross violations where some APIs use HTTP 418 as their custom error code instead of complying with the RFC.)
[1] https://tools.ietf.org/html/rfc2324#section-2.3.2
Yes, RFC 2324[1] is also serious business because it’s implemented in the real world. Or at least I have implemented HTTP 418 I’m a teapot. (I’ve also seen gross violations where some APIs use HTTP 418 as their custom error code instead of complying with the RFC.)
[1] https://tools.ietf.org/html/rfc2324#section-2.3.2
> I've also seen gross violations where some APIs use HTTP 418 as their custom error code instead of complying with the RFC.
I know a lot of people disagree with the IETF's policy of imprisoning those who fail to comply with the RFC, but personally I don't think they go far enough.
I know a lot of people disagree with the IETF's policy of imprisoning those who fail to comply with the RFC, but personally I don't think they go far enough.
RFC v draft is really not truely accurate IMO. There are plenty of examples of drafts in production that haven’t made it to RFC status yet. :)
It has been implemented, there is a fair bit of evidence on /r/birdsarentreal. The Birds Work for the Bourgeoisie.
Is there some video of this being implemented? I would love to see it.
RFCs are just a way for big corporations to collaborate on shared standards. It doesn't mean that other approaches can't become standards as well. It's kind of disturbing that RFCs seem to give projects automatic trustworthiness that they didn't actually earn.
At least more than one interested party thought about it, and documented the result. It might not be good, but it's worth evaluating to see if it's good enough.
Tldr: if you must send datagrams via pigeons, consider the rfc, then use an exfat microsd card.
Tldr: if you must send datagrams via pigeons, consider the rfc, then use an exfat microsd card.
[deleted]
"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."
Classic.
Classic.
If HN guidelines are considered to allow it, I suggest tweaking the title here to say "Internet Draft" rather than just "ID", which is unambiguous in the original context (i.e., a thing that actually is an Internet Draft) but not as an HN title.
I really admire people who can write a story like this off the top of their head.