It makes sense to have the 418 status code then.
> Any attempt to brew coffee with a teapot should result in the error code "418 I'm a teapot".
> TEA-capable pots that are not provisioned to brew coffee may return either a status code of 503, indicating temporary unavailability of coffee, or a code of 418 as defined in the base HTCPCP specification to denote a more permanent indication that the pot is a teapot.
So, all HTTP-only implementations that have 418 are technically incorrect, since it is not part of HTTP.
Which would seem to apply equally here: While the HTCPCP standard only indicates the semantics of the codes with respect to usage in HTCPCP scenarios, they are still code extensions to HTTP and available for use as defined, simply with fewer specified semantics.
Which is to say if you build your HTTP REST API using 418, we can all generally agree that the error from your API at that time is "I'm a teapot". Given that you aren't an HTCPCP endpoint, we just can't assume that we could then try HTCPCP-TEA to then try to brew tea, as we can't be sure that the semantics follow. Perhaps your REST API is simply a catalog of brewing equipment for purchase, and it still makes sense for some of your endpoints to fail with a 418. :)
It's unlikely for the IETF to assign 418 to a different HTTP-based or HTTP-like protocol with an entirely different and non-compatible definition, so even if 418 is laxly defined for HTTP proper, it's still "technically correct" in the sense that you can technically use it all you want and the only repercussions from the technical specs are if you implement it wrong in HTCPCP, there's no wrong way to use 418 in plain HTTP. ;)
I read your link to the RFC before I read the Mozilla article. It was not clear that the RFC was an April fools joke until after I read the Mozilla bit that highlighted it being a gag. After that, the date at the top of the RFC became obvious.
Third sentence probably should have been a warning flag. I think nearly every paragraph has word play
https://tools.ietf.org/html/rfc2324
While we're on the subject though, I'm in early planning for a replacement controller for my Keurig 250 (if I were using a RPi, I'd call it the Pig 250, but it'll likely be a different board) -- I'm excited to actually get HTCPCP in something real; thoughts on practical implementation?