Asklemmy

I love this. Thank you so much.

I always rather enjoyed the double entendre of "420 Enhance Your Calm", which was an unofficial response from Twitter's original API before "429 Too Many Requests" was standardized.

But I can't think of any codes which aren't already in there, that I'd use; there are a bunch that don't see much use, like "410 Gone", so the list could do with trimming down if anything.

I did go to a conference once where they were handing out laptop stickers, and in the pack was a 418 teapot.

Of course, a week after I stuck that to my machine, it died. Telling the laptop it was a teapot didn't agree with it, I guess.

My endorsement is at the bottom of that page, in fact. I wasn't an active campaigner, but a word in favor was the least I could do.

There are joke RFCs almost every year, so it's not unprecedented to add to the standards. This year, one of the additions was a Death Flag to TCP, to indicate when a connection is about to terminate. The RFC Editors are very approachable when it comes to the Apr 1st RFCs: a "real" standard would need to be drafted by someone actually in the field, but the Apr 1st's are open to public submissions as long as you're willing to redraft/edit in accordance with the documentation standards.

It's worth noting that the Clacks header is an unofficial campaign, and hasn't been standardised; the 'Pedia states that some 84,000 sites return X-Clacks-Overhead, and my own is one.

This is actually a good use of 418 in production, and one I've come across before: if you need to perform some custom handling and throwing a HTTP error is the only sensible way to do it, 418 is always available.

Unless your server really is a coffeepot, which is ...unlikely.

The incident you mention is probably the most impactful, but there's also the time the Russian military blocked IPs outside Russia by returning 418 instead of the more logical 403.

I think it's excellent out here. I was stuck on Reddit for the longest time, and this recent debacle has pushed me to explore the networks at the edge; this feels a lot more like the Internet of old. The analogy of email is apt, I think, with the accounts on multiple servers and the interplay between.

For Apr 1st RFCs in particular, the process is that you write your document in conformance to the RFC Editor's Style Guide and email it to the editor directly. If you have a not-a-joke standard that you'd like to be considered, that'll go through as an Internet Draft first, and then there are stages of review.

I haven't been through the latter, but the editors are very approachable over email; I had no issues submitting my RFC for review and revision.

So replicators are kind of a special case: they can make anything already fully prepared, without the need for a brewing command to be sent. It's possible that by the 24th century, there's a compatibility layer between Replicator Intermediate Language and HTCPCP, but I'll leave that to future generations to establish.

That's a tough one: most standards are codified as such because they're already seeing wide use. The major example of one that's been worked the other way around is IPv6: it's been a standard for a very long time, and still doesn't seem to be seeing adoption.

Of course, I wouldn't say I was bullish on IPv6. 32 bits is enough for anyone, right.

What a British thing to ask. Very apt sir, very apt.