Summary

  • RFC 2324 defined BREW/POST, additions, retry-safety hints and coffee-specific responses, but those protocol facts stop at the controller boundary.
  • Its companion Coffee Pot MIB could report capacity, operating state, level, time and temperature. None of those fields proved cup delivery, regulatory or food-safety compliance, drinkability or human consumption.

One command, several unfinished facts

Picture the cleanest possible exchange. A client identifies a coffee: resource, sends BREW with a valid message/coffeepot body containing start, and receives an ordinary successful response. The syntax is correct. The intended server answered. No error announced that the target was a teapot or that the requested additions were unavailable.

What has been established? At most, a controller received and handled a command according to the interface it exposed. The message does not show that the heater energized, that water reached temperature, that grounds were present, that liquid crossed the filter, that a carafe was in place or that the right cup received anything. Those are later facts with different witnesses.

That distinction is easy to miss because RFC 2324 is written as a joke with unusually memorable nouns. Published on 1 April 1998, it is Informational and explicitly does not specify an Internet standard. Yet its comic machinery is precise enough to reveal a serious systems problem: naming an action in a protocol does not collapse the distance between requesting it and observing its result.

The request body makes the boundary almost comically small. Section 4 allows only start or stop. The wire can therefore express an instruction without carrying a report of what followed. A client that stores the outbound request as evidence has documented its own intention. A server access log adds evidence of receipt. Neither record is a sensor reading, an actuator trace or a delivery receipt.

Capability was not completion

HTCPCP provides several ways for a pot to say that the request does not fit. Accept-Additions can describe acceptable milk, syrup, sweetener, spice or alcohol. A server may return 406 when the operator cannot comply and should describe available additions. Trying to brew coffee with a teapot should return 418 I'm a teapot.

These answers are useful because they narrow the failure. A 406 can say that the requested composition lies outside the available offer. A 418 identifies a category mismatch in the RFC's invented device model. Neither status measures water, coffee, temperature or volume. Conversely, the absence of 406 or 418 does not prove that every physical precondition was present. It only means those specific protocol refusals were not the response observed.

The Safe response field is similarly bounded. It concerns whether repeating a request is safe, possibly under a condition such as the user being awake. The RFC itself notes that the actual safety of brewing devices can depend on conditions at the client as well as the server. Retry safety is therefore not a food-safety certificate. It does not establish sanitation, allergen handling, electrical safety, a safe serving temperature or permission to serve the result.

Even GET is deliberately awkward. The RFC says the resources associated with a coffee pot are physical, while the data returned for most coffee URIs contain no caffeine. A representation of a pot is not the beverage. A response describing the resource cannot be poured into a cup.

The companion MIB made the ledger larger, not magical

The same April Fools' pair included RFC 2325, a Coffee Pot MIB for drip-type heated beverage hardware. Its objects look much closer to operational evidence: supported capacity, pot type, location, operating status, level, unit, scheduled start time, time since the process began and ambient coffee temperature.

Those fields matter precisely because they are separate. potCapacity describes how many units the device supports regardless of current state. It is not the current quantity. potOperStatus can be off, brewing, holding, other or waiting. A brewing value is a state report, not a measured yield. potLevel needs potMetric to say whether the units are cups, mugs or something else. lastStartTime reports elapsed time from initiation, while potTemperature reports a temperature at an observation point.

No one of them establishes the others. A machine can have capacity while empty. It can report brewing while the cup is absent. It can hold warm liquid that does not match the requested additions. A temperature can be accurate and still say nothing about contamination, local regulation or the intended drinker's tolerance. Even a falling pot level does not identify who received the liquid or whether anybody drank it.

The useful audit is therefore a joined sequence: request identity and time; server receipt; parsed method and body; pot identity and capability; actuator start; later state; temperature and level tied to the same run; transfer into a receptacle; handoff to the intended recipient; any required safety or compliance check; and finally, evidence of consumption if that is truly the business question. Every join needs a time, an object and an actor. Missing joins should remain missing, not be filled by confidence in the protocol name.

What 418 survived

The best-known artefact of HTCPCP is not a brewing system but a number. RFC 9110 calls 418 unused and reserves it in the HTTP status-code registry because the joke was deployed often enough to make the code unsuitable for another assignment. That is genuine historical impact. It proves that the symbol persisted in software and culture.

It proves nothing about coffee. A registered or reserved code has a stable place in a shared vocabulary; it is not an adoption count, an appliance inventory or an operational measurement. The same discipline applies to RFC 2324 itself. Publication provides a citable coordination artefact. Implementation would provide a different fact. A live exchange would provide another. A prepared beverage, a delivered cup and a consumed drink would each require still more evidence.

Sources