Summary

  • RFC 7168’s Updates field links its tea extension to RFC 2324; its status says Independent Submission, Informational, outside the Internet Standards Track and not an endorsement of deployment.
  • The document link does not establish consensus, an Internet Standard or evidence that a tea appliance implemented the humorous protocol.

One header, separate kinds of authority

The first page of RFC 7168 presents a puzzle. Updates: 2324 points to an earlier document; the title names a tea extension to the Hyper Text Coffee Pot Control Protocol. Just below, the status calls RFC 7168 an Independent Submission and an Informational document, says it is not an Internet Standards Track specification, and says the RFC Editor makes no statement about its value for implementation or deployment.

Those statements do not conflict. Updates identifies a relationship between documents: the 2014 text extends the subject matter of RFC 2324, published in 1998. Independent Submission identifies the publication stream. Informational and its boilerplate describe status. The RFC number records publication in the RFC Series; it does not, by itself, reveal the review path or confer standards-track authority.

This separation matters because the body looks like a protocol specification. RFC 7168 defines BREW requests, a message/teapot media type, tea-specific URIs and response behavior. It uses capitalized requirement words. That formal surface is part of the humor, but it cannot override the status printed on the same page.

What the extension describes

RFC 2324 supplied the HTCPCP vocabulary for coffee pots. RFC 7168 adapts its methods for tea and lets a client learn which varieties are available before choosing one. A tea-capable pot can return an Alternates header listing options such as Darjeeling or Earl Grey. A request to / with message/teapot presents choices without beginning a brew. A request with message/coffeepot can fall back to the base behavior and start coffee instead. The document also describes a stop request for ending the brew at a preferred strength.

This is a coherent design question: how should a client discover its options before triggering an action? The RFC is evidence of what its author specified, not proof that a device performed it. It documents no tea appliance, interoperability test or deployed service. Detailed protocol prose is not an operating record.

RFC 2324 had already said in its 1998 status text that it did not specify an Internet standard of any kind. The Updates field in RFC 7168 does not change the base document’s status or turn the tea extension into a standard. It signals document lineage, not adoption.

The RFC Series has more than one approval path

RFC 5741 explains why headers identify the source and status of RFC documents. The Series contains documents from multiple streams. Its Independent Submission boilerplate says the RFC Editor chose to publish the text at its discretion and makes no statement about implementation or deployment value. RFC 7168 uses that language directly.

Keep three questions separate. The RFC number asks whether a text was published in the Series. Stream and category show how it entered the Series and what standing it claims. Updates shows which earlier document it extends. Here, RFC 2324 to RFC 7168 describes a content relationship, not consensus or use.

Both RFCs are dated 1 April, sixteen years apart, and their technical jokes are apparent in the prose. The date is context, not a substitute for metadata. The status block helps distinguish a playful, formally published contribution from a standard operators are expected to implement.

Heng Lu’s Note 65, Running-Code Primacy, informs the editorial test: specification language is not evidence about what runs. The RFC records what was written and published. Claims about networked tea appliances need independent evidence.

Sources