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.

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.

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.

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.)

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.

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 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.

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.

HTTP/1.1 102 Processing
Content-Type: application/wtf

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.

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.

The biggest problem IPv6 has is that IPv4 has been so hugely successful: gargantuan resources have been poured into getting the world connected on IPv4, and the routers/etc deployed in the field (especially in sub-Saharan Africa, south Asia, and other places which got the Internet late) are built around version 4: data paths 32 bits wide, ASICs and firmware developed with 4-byte offsets, and so on.

It's a big effort, and more importantly an expensive effort, to move all that infrastructure over for what the end user perceives as no benefit: their websites load just the same as before.

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.

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.

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.

As the saying goes, "for bandwidth, nothing beats a truck full of tapes 1TB MicroSDs hurtling down the highway".

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.

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.

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

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.

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.

Out.

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

"I do not know with what weapons World War III will be fought, but World War IV will be fought with sticks and stones." - Albert Einstein.

Snopes says this sentiment was actually expressed by Einstein, though perhaps not in this exact phrasing.

It's not up to Mr Masinter or myself to police the usage of anything defined in the standard; if people feel like being assholes regarding the issuance of 418 errors, at least they're being whimsical assholes.

Could be worse; could be 200 with an error message inside, negating the entire point of error codes. I see that all the time.

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.

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.

Internet Relay Chat's been one of those things that's always felt out on the edge. I've been on EFnet since perhaps '03, and it's a lot quieter than it was...

With people moving en masse away from the centralized sites and their Firebase-implemented chats, we may see a pick up in traffic on the IRC networks, which would be good to see.

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.

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.

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.

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.

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.

A tip one contractor passed on to me when caulking: use pieces of toilet paper to smooth it out after applying. You won't get your fingers gunked up, and toilet paper's cheap enough that you can use a bit to smooth off a few inches of caulk and throw the paper away.

Think I got through half a roll when sealing up a window frame a couple years back, looks great.

Did the predilection for tea give me away?

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.

It's just... lightweight reddit basically. I dig it.

One could say you... digg it.

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

As it turns out, I drink black coffee nowadays.