ハイパーテキストコーヒーポット制御プロトコル (HTCPCP/1.0)

Studying HTTP > RFC-Translations related HTTP

この文書は、 L. Masinter: Hyper Text Coffee Pot Control Protocol (HTCPCP/1.0) (RFC 2324), April 1 1998. を橋本英彦が日本語訳した物です。この文書の取り扱いについては、[Studying HTTP] の RFC 日本語訳を利用するにあたってに従って下さい。

この文書の位置付け

この文書はインターネットコミュニティのための情報を提供する物である。この文書はいかなる種のインターネットの標準も明述する物ではない。この文書の配布に制限は無い。

著作権表示

概要

この文書は、コーヒーポットを制御、監視、診断するためのプロトコルである HTCPCP について記述するものである。

1. 原理とその範囲

コーヒーは世界中にある。コンピュータが世界中至る所に広まっていく中で{ubiquitous} 、その利用者達はコーヒーを作る事を望んでいる。コーヒーを淹れる事は一つのアートであるが、web で接続された分散情報システムというものは既にアートを超越している。そのため、コーヒーを淹れる為に設計された、強く、濃く、リッチな、例えるならエスプレッソコーヒーのようなプロトコルが求められている。コーヒーはコーヒーポットを使って淹れるものである。ネットワークで接続されたコーヒーポットでは、それを制御するために制御プロトコルが必要となる。

昨今、家庭用及び消費者向けの装置がインターネットに接続されるようになってきている。初期のネットワーク実験ではその状態を監視するためにインターネットに接続された自動販売機の実証実験が行われた [COKE]。インターネットにて遠隔「操作」された最初期の機械の一つに、(SNMP 経由で制御される) インターネットトースターがあり、1990 年に公開された [RFC2235]。

このようなあらゆる装置をネットワークに接続させたいとする需要は IPv4アドレス空間の浪費をもたらす事となる。消費者は、例えば、朝、淹れたてのコーヒーで目覚めるための、あるいはディナーの準備が終わったまさにその瞬間にコーヒーを準備するためのコーヒーポットのような装置の遠隔操作を望んでいるのである。

この文書は、ハイパーテキストコーヒーポット制御プロトコル (HTCPCP) について記述するものであり、これは、必要十分なリクエスト及びレスポンスにより、一般的なカフェインの入った暖かい飲み物を作るために利用される全ての装置を制御できるようにする。

HTTP 1.1 ([RFC2068]) はオリジンサーバからクライアントへ web オブジェクトを転送できるようにするものである。この web は world-wide である。 HTCPCP は HTTP に基づいている。これは HTTP が至る所で利用されているからである。良いものでなければそう広まるものではないからだ。即ち、HTTPとは良いものなのである。良いコーヒーを飲みたければ、HTCPCP もより良くする必要がある。 HTCPCP をより良くするためには、そのような HTTP に基づくのが良いのである。

このプロトコルの将来のバージョンはエスプレッソマシン及びそれに類似する装置のための拡張が含まれるかもしれない。

2. HTCPCP プロトコル

HTCPCP プロトコルは HTTP を基に設計され、いくつかの新しいメソッド、ヘッダフィールド、リターンコードを追加している。全ての HTCPCP サーバは "coffee:" URI スキーム (Section 4) によって参照されるべきである。

2.1 HTCPCP 追加メソッド

2.1.1 BREW メソッド、及び POST の使用

コーヒーポットを制御するための命令は、BREW あるいは POST メソッド、そして Content-Type が "application/coffee-pot-command" とセットされたメッセージボディを用いて、クライアントからサーバに送られる。

コーヒーポットサーバは、BREW と POST のどちらのメソッドも同等に扱わなければならない。しかし、動作を実行するために POST を使用する事は推奨されない。

コーヒーポットとは電子的メカニズムを利用して水を熱するもので、即ちそこに火は存在しない。従って、ファイアウォールは必要ないし、またファイアウォール制御ポリシーとも無関係である。しかし、POST はコーヒーの商標かもしれないので、BREW メソッドが追加された。 BREW メソッドは、他の HTTP に基づくプロトコル (例えば、ハイパーテキストビール醸造所制御プロトコル{the Hyper Text Brewery Control Protocol} ) で使用されるかもしれない。

2.1.2 GET メソッド

HTTP では、GET メソッドは "リクエストURI によって識別される（エンティティの形式の中の）何らかの情報を取得する" という意味で使用される。リクエストURI がデータ生成プロセス (訳注: CGI等) を参照する場合、レスポンス中のエンティティとして返されるものは生成されたデータであり、そのソース文書が処理の出力であるというのでなければ、ソース文書が返されるのではない。

HTCPCP では、コーヒーポットに関連付けられたリソースは物理的なものであり、情報資源ではない。多くの coffee URI のための "データ" にはカフェインは含まれない。

2.1.3 PROPFINDメソッド

一杯のコーヒーがデータである場合、淹れられたリソースについての外部データは PROPFIND メソッドを使用する事で検出される [WEBDAV]。

2.1.4 WHEN メソッド

コーヒーが注がれ、ミルクの諾否が提案された時、ミルクの受信者であるコーヒーの保持者は、十分なミルクがコーヒー中に導入されたその時に "when(そのぐらいでいいよ)" と言う必要がある。この目的のために、"WHEN" メソッドが HTCPCP に付け加えられた。もういいかい? ならば WHEN と言ってくれ。

2.2 コーヒーポットヘッダフィールド

HTCPCP ではいくつかの HTTP ヘッダフィールドの使用を推奨し、また新しいものをいくつか定義する。

2.2.1 推奨されるヘッダフィールド

2.2.1.1 "safe" レスポンスヘッダフィールド

[SAFE] では "Safe" という HTTP レスポンスヘッダフィールドを定義しており、これは HTTP リクエストを繰り返す事が安全であるという事を示すために使いうる。もし以前のリクエストの結果を繰り返したければ、"Safe: Yes"というヘッダフィールドを含める事で、クライアントはそのリクエストを繰り返す事ができる。

コーヒーを淹れるための装置の実際の安全性は様々であり、実際、サーバの状態よりもむしろクライアントの状態に依存するかもしれない。そのため、このプロトコルでは "Safe" レスポンスヘッダという拡張を含む:

これにより、ユーザエージェントは安全なリクエスト、特に安全な POST リクエストを、よりユーザフレンドリな方法で再試行できるようになるであろう。

2.2.2 新しいヘッダフィールド

2.2.2.1 Accept-Additions ヘッダフィールド

HTTP では、"Accept" リクエストヘッダフィールドは、レスポンスとして受け入れ可能であるメディアタイプを特定するために使われる。しかし HTCPCPでは、レスポンスは自動化されたポット側での追加的動作によって変化するかもしれない。このような理由によって、 HTCPCP では新しいヘッダフィールド "Accept-Additions" を追加する:

2.2.3 除外されるヘッダフィールド

カフェイン抜きのコーヒーについて与えられるオプションは無い。そんなものに何の意味があろうか?

2.3 HTCPCP リターンコード

通常の HTTP リターンコードは HTCPCP サーバでの問題を表すために使われる。この節では、HTCPCP 特殊の解釈、および新しく定義したリターンコードについて認識する。

2.3.1 406 Not Acceptable

このリターンコードは通常、"そのリクエストによって識別されたリソースは、リクエスト中で送られた Accept ヘッダによって受け入れ可能とはされない性質の内容を持つレスポンスエンティティのみが生成可能である" と解釈される。 HTCPCP では、このレスポンスコードは、コーヒーポットの運転者が Accept-Addtion リクエストに従う事ができない場合に返してもよい。リクエストが HEAD メソッドでなければ、レスポンスには、利用可能なコーヒー添加物のリストをエンティティに含むべきである。

実際は、自動化されたコーヒーポットのほとんどは、現在のところコーヒー添加物を提供する事はできない。

2.3.2 418 I'm a teapot

ティーポットへコーヒーを淹れさせようとするあらゆる試行は、エラーコード "418 I'm a teapot" という結果に終わるべきである。その場合のエンティティボディは酷く簡単なものであってもよい。

3. "coffee" URI スキーム

コーヒーとは国際的なものであるので、国際的な URI スキームもまた存在する。全てのコーヒー URL スキームは、URI の国際化の慣例 [URLI18N] に従い、29 の言語における "コーヒー" を表す語の UTF-8 エンコードされた文字列の URL エンコードをもって記述される。

全ての代替的 coffee スキームは等価である。しかし、各言語中でのコーヒースキームの使用が、そのコーヒーポットによって生成されるコーヒーの種類を示すものとして解釈されるかもしれない。なお、URL スキーム名は本来大文字・小文字を区別しないが、ドイツ語において大文字の使用は重要であり、従って頭文字 "K" は必ず大文字でエンコードされなければならない事に注意。

4. "message/coffeepot" メディアタイプ

POST および BREW リクエストのエンティティボディの Content-Type は "message/coffeepot" でなければならない。コーヒーポットを制御するためのほとんどの情報は追加的ヘッダによって転送されるので、"message/coffeepot" の内容は coffee-message-body のみを含む:

5. 運用上の制限

この節では HTCPCP を至る所に広げ効果的に活用するための運用上の問題についていくつか記述する。

5.1 タイミングについての考察

コーヒーポットユーザとコーヒーポットサービスとの間には、堅牢なサービス品質が要求される。コーヒーポットは、自身の時計を世界標準時に正確に同期させるためにネットワーク時間プロトコル [NTP] を用いるべきである。

これまで、遠隔ロボット工学は高価な技術であった。しかし、ケンブリッジコーヒーポット [CAM] の出現により、監視・管理のための遠隔システムとして (SNMP ではなく) web を利用できるという事が実証された。更なるコーヒーポット管理のための作業は、遠隔ロボット工学によって達成されるであろう。

web データは通常は静的である。それ故、データの転送やそのための時間を節約するために、web ブラウザプログラムはコンピュータ上でユーザが取得したそれぞれの web ページを保存する。従って、ユーザが以前取得したページに戻ろうとした時でも、それは既にローカルに保存されており、再びサーバから転送してくる必要はない。ロボットの制御や、変化する場面の監視のために使用される画像は動的である。アクセス毎に、サーバから新鮮なものを取得する必要がある。

5.2 ファイアウォールを乗り越える場合

多くの組織において、HTTP トラフィックは全く容易ファイアウォールを乗り越えている。最近のコーヒーポットは火を使わない。しかし、"ファイアウォール" は、火に限らず、熱に関するあらゆる問題からその源を保護するために有用である。全ての家庭用コンピューターネットワークは熱源からファイアウォールによって保護されるべきである。しかし、家の外からのコーヒーポットの遠隔制御は重要である。従って、HTCPCP が容易にファイアウォールを乗り越えるという事もまた重要なのである。

HTCPCP が HTTP を基にしている事、またポート 80 を使う事によって、ファイアウォールを越えるための HTTP の良い所は全て得る事ができる。もちろん、家庭用ファイアウォールは HTCPCP 特有のメソッド、ヘッダ、トレーラに適合するために再設定あるいは新バージョンが必要となるであろうが、そのような更新にも容易に対応するであろう。多くの家庭用ネットワークシステムの管理者はコーヒーを飲むから、HTCPCP をトンネリングする必要性に対応させる事をいとわないはずである。

6. システム管理についての考察

HTTP プロトコルを利用したコーヒーポットの監視は、初期の web アプリケーションの一つであった。最初期の例では、コーヒーポットの監視は ATM ネットワークの初期の (また適切な) 利用方法であった [CAM]。

その伝統的な技術 [CAM] とは、フレームグラバをビデオカメラに接続し、コーヒーポットの画像を web サーバに送り込むというものであった。これはATM ネットワークのアプリケーションとしては適切であった。このコーヒーポットへの実装では、ケンブリッジ大学の Trojan Room 研究室が共有コーヒーポットを監視するための web インタフェースを提供するために使用された。関連する研究に参加していた学者達は貧乏だったので、みんなでコーヒーフィルタマシンをたった一つ持っていただけで、それは Trojan Room のすぐ外の廊下に置かれていた。しかし、非常に精力的に打ち込む勤勉な学者達だったので、多量のコーヒーを飲み干してしまい、新鮮なコーヒーが淹れられても、それが長く持たない事もしばしばであった。

このサービスは、ケンブリッジ・ンピュータ研究室にて設計された新しい RPC 機構、すなわち MSRPC2 を使用する初めてのアプリケーションとして作成された。これは、MSNL (Multi-Service Network Layer)、すなわち ATM ネットワークのために設計されたネットワーク層プロトコル上で動作する。

インターネット上のコーヒーポットは、コーヒーポットMIB [CPMIB] を使って管理する事ができる。

7. セキュリティについての考察

私と私のモーニングコーヒーの間に入り込むあらゆる人間は、おそらく安全ではない。

インターネットユーザからの保護されていないコーヒーポットへの不正なアクセスは、ある種の "コーヒーサービス拒否{denial of coffee service}" 攻撃を引き起こすかもしれない。フィルタリング(濾過)装置の不適切な使用は、コーヒーを Trojan Room の床へ侵入させてしまう事になるかもしれない。フィルタリングは、ウィルスからの保護手段としては適していない。

コーヒーの出がらしをインターネット配管に流すと、配管を詰まらせる事になるかもしれず、その結果インターネット配管工 [PLUMB] のサービスが必要となるだろうし、そうなれば今度は配管工の助手をも必要とする事になるだろう。

8. 謝辞

Roy Fielding, Mark Day, Keith Moore, Carl Uno-Manros, MichaelSlavitch, Martin Duerst 各氏を含む、この標準に寄与された多くの方々に感謝する。 the Prancing Pony, the CMU Coke Machine, the CambridgeCoffee Pot, the Internet Toaster, 及びその他のコンピュータによって遠隔制御される装置という発想がこの価値ある創造へと導いてくれた。

9. 参照文献

10. 筆者のアドレス

11. 著作権表示全文

この文章とその翻訳は、複製し他人に配布する事ができ、またその実装についてのコメント、その他の方法を用いた説明、その補助となるような派生的作業はそれらの中に上の著作権表示とこの段落を含む事によって、その全て又は一部を、いかなる制約も受けずに、作成、複製、発表、及び配布する事ができる。しかしながら、インターネット標準化プロセスにて定義されている著作権のための手続きに従わなければならないような場合の中でインターネット標準を開発するという目的に必要である、あるいは英語以外の言語に翻訳する必要があるという場合を除いて、この文章自体を、その著作権表示や、インターネット学会あるいは他のインターネット団体への参照を削除するような、いかなる変更もできない。

上で認めた制限された許諾は永続的なものであり、インターネット学会及びその継承者や譲渡者によって取り消される事は無い。

この文書とここに含まれた情報は、"そのまま {AS IS}" である事を基に提供され、インターネット学会、及び IETF は、この中の情報の使用が、商用利用及び特定用途においていかなる権利もいかなる暗黙的保障も侵害していないという保障への制限を含め、明示的に又は暗黙的に、全ての保障を放棄する。