I'm the author of an April Fool's Internet Standard, AMA

It's great: the Internet should have a bit of that sense of whimsy, and knowing that there's official support in many libraries for "you're asking me for coffee, but I'm a teapot" is one of those things that gets me through the day.

I love this. Thank you so much.

http.cat was absolutely critical when I transitioned from general application development to web backend development. Not a joke, it was just a super readable site listing the codes with a short and memorable url.

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.

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.

You'd have to catch up with Mr Masinter to get his opinion on adding error 418, I'm afraid; that piece of the business wasn't my work.

I'm happy it's there though: it may have sparked flamewars, but at this point what hasn't. It does bring somewhat of that sense of humanity to the whole enterprise of working on the Internet.

Sheesh, some people have no sense of humour.

A little lower down the stack, I always liked the Evil Bit in TCP, a standard which removes all need for firewalls heuristics by requiring malware or packets with evil intent to set the Evil Bit. The receiver can simply drop packets with the Evil Bit set, and thus be entirely safe forever from bad traffic.

At the physical interface layer where data meets real life, I especially enjoy IP over Avian Carrier; that link in particular is to the QoS definition which extends the original spec for carrying packets by carrier pigeon.

The fact that otherwise non-technical people joke about staying in hotel room 404 just shows how pervasive the modern Internet has become. As an aside, it also shows the importance of a good error message; there are some errors (like "Not Found") in HTTP that are simple and clear, and some ("Bad Gateway"?) that are more impenetrable.

No-one jokes about staying in room 504, and the room service never arriving.

(And perhaps one of the larger Lemmies can get a hold of Victoria, get these AMAs going for real.)

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.

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.

That's actually the topic of the talk! Around 1995-96, HTTP was picking up all kinds of use outside the academic community, and people were tacking extensions on left and right; one of the biggest was file upload support, which was done by throwing HTTP and email into a room and having them fight it out. Which is how we ended up with the monstrosity that is "sending emails over HTTP", also known as "posting a form".

The author of HTCPCP decided to codify some of his concerns with these, partly as a joke; I noticed long afterward that his joke was only standardized for coffee, which Personally Offended me as a citizen of a tea-drinking nation.

200 is probably the most common status no? Many successful responses will give 200 in the backend

username checks out

You know sometimes you click on a link and it says "404 not found?" 404 is an HTTP status code. basically when you click on a website your browser makes an "HTTP request" to that website to get the web page, and it'll respond with a code to tell the status. 2xx is ideal, since it means OK. 4xx means it's an error on your end. (404, you requested a nonexistent link.) 5xx means it's a server error.

This person made 418, a status code for "I'm a teapot". It was intended as an april fools joke but it's used sometimes for when the server doesn't want to handle a request from the client.

I need one too and I'm a stupid Gen Y

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.

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.

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.

Out.

Can't stand pineapple at the best of times, on pizza is another level of wrong.

Getting really tired of this meme

Yes, obviously. Where else should it be at if not my pizza?

For "real" RFCs that aren't Apr 1st jokes, there's an independent submissions track for the public to write Internet-Drafts and then submit them into the review process.

With the joke RFCs, they get emailed straight to the editor at least two weeks beforehand. I'm not privy to the selection meeting, but I expect it's fun.

Did the predilection for tea give me away?

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

I never understood the beef people had with that. The Internet is a series of tubes, of various widths and sizes, with inputs at random points in the stream.

Plumbing analogies are apt.

As it turns out, one of the Apr 1st RFCs for this year covers AI Sarcasm Detection, but I can see more serious protocols arising for the transfer of AI model data and/or training procedures in the coming years.

I'd also hope ActivityPub reaches Internet Standard level, though it may fall outside the IETF's scope of operations.

Excellent. I'm on Stage 4 on the Thursday afternoon: "Brewing Tea Over The Internet".

Should be fun times, see you there.

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.

I quite like the idea of HTTP 256 Binary Data Follows, which is just 200 OK but you asked for a non-text content type file.

Wasn't there a new HTTP action recently proposed for "This is a JSON RPC request that we've convinced ourselves is actually REST and we've been using POST and someone finally pointed out that that was stupid"?

Not a new status code but still vaguely amusing.

I enjoy that the original draft for the Referer header spelled it wrong, and now we're all stuck with the typo forever...

I don't think the extra address space of IPv6 is the problem holding back its adoption, so "IPv4 with another octet" would likely run into the same issues.

Not that it's a bad idea, it's just an idea that's unlikely to catch on.

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.

Yes, unless Jen needs to borrow it for a presentation.

I've just done some quick browsing to see if there's a written-down motivation for Referer existing, and there's this on the Wikipedia: "Many blogs publish referrer information in order to link back to people who are linking to them, and hence broaden the conversation."

Which I guess makes sense, in the context of the original use of HTTP as an academic publishing protocol, but it's gained cruft and nefariousness since wider adoption came about.

There are good arguments for stripping Referer from the standard, and yours is one of the most cogent; if Referer is still a thing in another 30 years, I'd be surprised.

This is kinda the problem with widely deployed standards like TCP/IPv4: if you have even one device out there that's on the "old" standard, it won't be able to talk under a hypothetical new standard like IPv6 or TCP-with-huge-packets. And there are a lot more than one device out there that would be cut off.

As I understand it, the big pipes have very large MTUs now, and the edge routers cut up the packets for further transport. That's probably the only way we can realistically go forward.

If anything, we're into the "bust" part of the bubble: layoffs have been coming in waves all year, and are continuing. There were a whole bunch of posts over on Mastodon just a couple of weeks ago, at end of quarter, where people were laid off and looking for work.

As it turns out, I could find no physical implementations of HTCPCP or the tea-brewing extension. The original protocol is somewhat incomplete, which is probably the main issue; also, any modern appliance would probably talk its own protocol encoded in JSON or similar.

While researching for the talk, I did find Hacked-Together Coffeepot Control Protocol which was a UMaryland hackathon project in 2016. They won the prize for "most technologies used in their tech stack", which is ...something.

If you're writing a TEA-compliant client, you'd send the BREW request and expect a 300 Multiple Options back, whereby the server will tell you which teabags are installed. You're correct that there'll be no error, unless all the bag stocks are out server-side.

That'd return 503 Service Unavailable, of course.

As it turns out, I drink black coffee nowadays.

7168 is my only foray into writing an Internet Standard RFC. If you have a good idea for one, you should definitely get in touch with the RFC Editors; I found them very approachable and willing to work with my idea, moulding it into a document that's compliant to their (admittedly old-timey 60's) documentation standards.

RST

Glad to hear it, you should walk around with a HTTP 418 hat so more people know you're not a teapot.

Haha, same here! I was so proud I knew what the title was referring to before reading the post. Lol

The motivation for HTCPCP-TEA was that HTCPCP didn't cover tea brewing. Off the top of my head, I can't think of any infused hot drinks that aren't coffee or a tea of some kind...

Perhaps we need a homebrew beer request standard. The response lag would be tremendous though.

Well, they could. They could also set up listening posts on every transcontinental pipe as they reach land.

What's that, they did?

I read the original HTCPCP around ten years ago, and it Deeply Offended me (as a Brit) that it didn't handle tea brewing at all. That was the entire motivation, I'm afraid.

My following list; of note is Lisa Melton, whose bio says "Follow me and I'll fill your timeline with boosts". She ain't lying.

Looks like some of the talks from last year were released on the conference's YouTube, so: hard to say if the recording will be available. I'll (see if I can) remember to ask on the day.

The RFC Editor's site states that there's an independent submissions track for "real" RFCs, whereby lay members of the public can write Internet-Drafts and then submit them into the review process.

Looks like there's a good resource on how to write Internet-Drafts over at the IETF Authors site which may be worth perusing.