[JoshTriplett]

> It's like saying <blink> was "consumed" in HTML because two browsers used to support it.

Which is accurate. Reintroducing a tag named "blink" into HTML to mean something other than "blinking text" would be a really bad idea for compatibility reasons.

[peterwwillis]

So we're trying to avoid breaking the internet by committing to people expecting an error when they're talking to a teapot? So that past implementations of clients connecting to teapots won't break?

Like I say, we could also just add it to the spec... But that would be ridiculous, because why would you support telling someone you were a teapot in an HTTP protocol, when the feature is only useful in a protocol for brewing coffee? That would be like taking a programming language's syntax for assigning data objects and turning it into it's own standard for a text file format.

Maybe a time traveler set this whole thing up 19 years ago just to troll people on standards boards.

[phab]

> That would be like taking a programming language's syntax for assigning data objects and turning it into it's own standard for a text file format.

Looking at you, JSON...

[vacri]

It's a miniscule bit of humour that consumes 1 of 31 used slots in a 100-slot block, in an area of tech that isn't even remotely drowning in 'fun stuff'. What does it really matter? There are plenty of perfectly serious RFCs that are even less implemented than 418.

It's not like this RFC ratifying a 20-year-old joke that 'made it' is going to generate a cavalcade of lookalikes.

[pwdisswordfish]

You never know. Some people used to think 4 billion slots would be more than enough for addressing every host in the world, and so they allocated the addresses haphazardly. Now look at the sorry state of IPv6 adoption 20 years after it's been designed.

Some people used to think 65536 code points would be more than enough to encode every character in every language. Later it turned out not to be the case. Expanding that space necessitated the creation of hacks of various degrees of awfulness like UTF-16, CESU-8, WTF-8; today nearly every Unicode-aware environment has to be prepared to deal with unpaired surrogates somehow.

Expanding a fixed-size namespace is a pain. Who knows if HTTP status codes won't become scarce some day. They better not be wasted on frivolities.

[dhosek]

Having been around for the creation of Unicode, there were plenty of people who argued that 16 bits was insufficient for encoding all the characters and fought for the competing ISO standard which was 32 bits. A final compromise made Unicode a subset of ISO-10646 and now the two character sets are synchronized and act as parallel standards. UTF-8/16/32 were part of things from the beginning not because of the 16-bit assumption behind Unicode 1.0, but for the sake of keeping data reasonably sized. UTF-8 allows for 7-bit ascii files (which were the majority of text files back in the day) to be compliant without change and kept the default size of text files from being doubled or quadrupled in an era in which that was a serious concern for both bandwidth (dial-up connections at 2400baud or lower were quite common) and storage (20MB was considered a HUGE amount of storage).

[quuquuquu]

As frivolous as you think 418 is, people use it.

You honestly can't, in this situation, be the judge of what is "frivolous use" and what is not.

[peterwwillis]

It's literally an error designed to tell a client that an operation occurred on a teapot and not a coffee machine. It is the definition of frivolous.

[quuquuquu]

I appreciate your view point.

Olive oil was used as lantern fuel before it was ingested.

Some swear by it, some want it banned.

Only the user can judge!

[dexterdog]

Except blink is a string that means what it is. 418 is one of a small set of codes to use and has no purpose as it exists other than nonsense.