RFC 2324：BREW応答はコーヒー完成の証拠ではない

要約

正しい coffee: URIへ、message/coffeepot の start を送る。対象はティーポットではないため418は返らず、追加物の不一致を示す406もない。ネットワーク上では成功に見える。

しかし、その時点で確かめられたのはコントローラーが命令を扱ったことだけだ。ヒーターが作動したか、水や粉があったか、抽出が進んだか、ポットとカップが所定の位置にあったかは別問題である。RFC 2324 は動作を命名したが、その後の物理世界を一つの応答へ畳み込んではいない。

文書は1998年4月1日公開のInformationalで、Internet標準ではない。HTTPを家電へ拡張する風刺だが、メッセージと結果を区別する設計上の論点は本物だ。送信ログは依頼の証拠、アクセスログは受信の証拠である。どちらも通電、温度、液量、提供の証拠ではない。

Accept-Additions はミルク、シロップ、甘味料、香辛料、酒類などの希望を表す。提供できなければ406を返せる。コーヒーをティーポットに要求すれば418を返す。これらは能力不一致を狭く説明する。

406がないからミルクが投入されたとは言えない。418がないから水や豆が存在したとも言えない。定義済みエラーを回避したことと、望んだ成果を観測したことは違う。

Safe も再試行の安全性に関する情報であり、食品安全の証明書ではない。RFC自身、機器の安全性がクライアント側条件にも依存し得ると述べる。衛生、アレルゲン、規制、適温をこのフィールドから推論してはならない。

同日公開の RFC 2325 は、Coffee Pot MIBとして容量、種類、場所、potOperStatus、液量、単位、開始予定時刻、開始後の経過時間、温度を定義した。

容量は現在の状態に関係なく機器が支えられる量であり、満杯を意味しない。brewing は運転状態であって抽出量ではない。液量には単位が必要で、温度は一地点の測定値にすぎない。開始後の時間も、液体がカップへ届いた証拠にはならない。

必要なのは同じ運転を結ぶ証拠鎖だ。要求の識別、対象機器、アクチュエーター、状態遷移、液量と温度、注出、容器、受取人、必要な安全確認を別々に記録する。最後に「誰かが飲んだか」を問うなら、人の行為を示す別の事実が要る。

RFC 9110 は418を未使用として予約した。冗談として十分に実装され、別用途への再割当てが難しくなったからだ。これは文化とソフトウェアにおける持続性の証拠である。

一方、実際のコーヒー製造を示す証拠ではない。番号の予約は共有語彙を守る。ポットの稼働台数、抽出成功率、提供品質は測らない。仕様、実装、運転、物理的提供、人の消費は、それぞれ異なる現実である。