Network Working Group                                       L. Masinter
Request for Comments: 2324                                 1 April 1998
Category: Informational

ハイパーテキスト・コーヒーポット制御プロトコル

Hyper Text Coffee Pot Control Protocol (HTCPCP/1.0)

このメモの位置付け

このメモは、インターネット共同体への情報提供を目的とする。 インターネットの標準規格を定めようとするものではない。このメモの配付は無制限とする。

著作権表記

Copyright (C) The Internet Society (1998). All Rights Reserved.

概要

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

1.根拠ならびに範囲

コーヒーは世界中にいきわたっている。コンピュータ利用がますますあらゆる場所に浸透するにつれて、コンピュータ利用者たちはコーヒーをいれたがるのである。コーヒーをいれるというのはそれだけで一つのアートだが、Webによって結ばれた世界の分散知能はアートを凌駕する。したがって、コーヒー用に設計された、ちがいのわかるプロトコルに対する需要は強力かつ濃く、芳醇である。コーヒーはコーヒーポットによっていれられる。ネットワーク接続されたコーヒーポットを制御するための制御プロトコルが必要とされているのだ。

家庭用、および消費者向け機器が、インターネットに接続される例がますます増えてきている。初期のネット接続実験としては、自動販売機のインターネット接続によるステータス監視の実証実験などがある[COKE]。インターネット接続された最初期の遠隔「操作」機器としては、1990年にデビューしたインターネット・トースター(SNMPで制御)が挙げられる[RFC2235]。

広くいきわたっている機器を接続しようという需要は、IPv4のアドレス空間を枯渇させるほどに高まっている。消費者たちは、コーヒーポットのような機器を遠隔操作したいと思っている。そうすれば、朝起きたときにいれたてのコーヒーができていたり、あるいは夕食の準備が終わってからコーヒーが用意されるまでの時間を厳密に指定できる。

本文書はハイパーテキスト・コーヒーポット制御プロトコル(Hyper Text Coffee Pot Control Protocol, HTCPCP)を記述する。これは、人気の高いカフェイン入り高温飲料を作成可能なデバイスすべてを制御するのに必要な、あらゆる要求と応答を可能にするものである。

HTTP 1.1 ([RFC2068]) は、webオブジェクトをもとのサーバからクライアントへと転送することを可能にする。webはworld-wideである。HTCPCP は HTTPに基づいているが、これはHTTPがどこにでもあるからである。良質でなければ、これほど普及することはなかったであろう。したがってHTTPは良質である。良質なコーヒーがほしいなら、HTCPCPも良質である必要がある。HTCPCPを良質なものにするためには、HTCPCPをHTTPベースにするのがよろしい。

本プロトコルの将来バージョンでは、エスプレッソ・マシンなどのデバイス用拡張が加えられる可能性もある。

2. HTCPCP Protocol

HTCPCP プロトコルはHTTPの上に構築されており、いくつかの新しいメソッド、ヘッダフィールド、リターンコードを付加している。あらゆるHTCPCPサーバは、"coffee:" URIスキーム(Section 4参照)で参照される。

2.1 HTCPCP Added Methods

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

コーヒーポット制御のためのコマンドは、クライアントからコーヒーサーバにBREWまたはPOSTメソッドで送られ、メッセージのボディのContent-Typeは"application/coffee-pot-command"にセットされる。

コーヒーポットサーバは、絶対に BREW と POST のコマンドを等しく受け付けなくてはならない。ただし、行動をうながすのにPOSTを使うのは推奨されない。

コーヒーポットは電気的なメカニズムを使って水を熱するため、火(ファイア)は生じない。したがって、ファイアウォールは不要であり、ファイアウォール制御方針も問題とはならない。しかしながら、POSTはコーヒーだけの専売特許である可能性があるため、BREWメソッドが追加された。BREWメソッドは他のHTTPベースのプロトコル(たとえばハイパーテキスト・ビール醸造制御プロトコル)などでも使用可能である。

2.1.2 GET メソッド

HTTPで使われるGET メソッドは、「Request-URIで同定された任意の情報を(エンティティとして)とってくる」という意味で使われる。もしRequest-URI がデータ生成プロセスを指していれば、応答の中のエンティティとして返されるのはそこで生成されたデータであって、そのプロセスのソーステキストではない。ただしそのテクストが、該当プロセスの出力である場合は除く。

HTCPCPでは、コーヒーポットと関連づけられるリソースは物理的なものであり、情報リソースではない。ほとんどのコーヒーURIの「データ」にはカフェインは含まれていない。

2.1.3 PROPFIND メソッド

一杯のコーヒーがデータであるなら、それをいれるリソースに関するメタデータは PROPFIND によって記述される[WEBDAV]。

2.1.4 SONOKURAI method

コーヒーが注がれてミルクが提供される場合には、ミルク受容側の保持者は、コーヒーに十分な量のミルクが導入された時に「そのくらい」と言うことが必要である。このため、HTCPCPには SONOKURAI メソッドが追加されている。こんなもんでいい? SONOKURAIって言ってね。

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

HTCPCPは、いくつかのHTTPヘッダフィールドを推奨するとともに、新しいヘッダフィールドを定義している。

2.2.1 推奨ヘッダフィールド

2.2.1.1 "safe"応答ヘッダフィールド

[SAFE] はHTTP応答ヘッダフィールドとして「Safe」を定義している。これは、HTTP要求を繰り返しても安全であることを示すのに使われる。「Safe: Yes」ヘッダフィールドを含めておくことで、クライアントは要求の結果を繰り返し求める場合、直前の要求を繰り返すことが可能になる。

実際にコーヒーをいれるデバイスの安全性はきわめて多様であり、実際にはサーバだけの状態より、クライアント側の状態にも大きく依存する場合がある。したがって本プロトコルでは、「Safe」応答ヘッダに拡張を含める。

          Safe                = "Safe" ":" 安全性状態
          安全性状態          = "yes" | "no" | 条件付きで安全
          条件付きで安全      = "if-" 安全条件
          安全条件            = "user-awake" | ユーザが寝ぼけていないかトークン

この表示によって、ユーザエージェントは一部の安全な要求の再試行を、もっとユーザフレンドリな形で取り扱えるようになる。これは特にPOST要求で重要となる。

2.2.2 新たなヘッダフィールド

2.2.2.1 Accept-Additions(追加物受け入れ)ヘッダフィールド

HTTPでは、"Accept" 要求ヘッダフィールドは、応答で使用可能なメディアタイプを指定するのに使われる。しかしながら HTCPCP においては、応答は自動化されたポット側で追加の行動を必要とすることになるかもしれない。このため HTCPCP には新しいヘッダフィールド「Accept-Additions」が追加されている。
       Accept-Additions = "Accept-Additions" ":"
                          #( addition-range [ accept-params ] )

        追加物タイプ    = ( "*"
                          | ミルクタイプ
                          | シロップタイプ
                          | 甘味料タイプ
                          | 香料タイプ
                          | アルコールタイプ
                          ) *( ";" parameter )
        ミルクタイプ    = ( "Cream" | "Half-and-half" | "Whole-milk"
                          | "Part-Skim" | "Skim" | "Non-Dairy" )
        シロップタイプ  = ( "Vanilla" | "Almond" | "Raspberry"
                          | "Chocolate" )
        甘味料タイプ    = ( "Sugar" | "Honey" | "Saccarin"  | "Condenced milk" | "Sugar-cut" )
        香料タイプ      = ( "Cinnamon" | "Coco" | "Nutmeg" )
        アルコールタイプ= ( "Whisky" | "Rum" | "Kahlua" | "Aquavit" )

2.2.3 含まれていないヘッダフィールド

カフェインぬきのコーヒー用オプションは含まれていない。そんなのコーヒーじゃないもん。

2.3 HTCPCP応答コード

HTCPCPサーバでの問題を示すには、通常の HTTP 応答コードが使われる。本項では、その独特な解釈や新たな応答コードについて述べる。

2.3.1 406 Not Acceptable

 このリターンコードは、通常は「要求によって指定されたリソースは、要求で送られたacceptヘッダによれば受け入れられない内容特性を持った応答エンティティしか生成できない」と解釈される。HTCPCPでは、この応答はコーヒーポットのオペレータがAccept-Addition要求に対応できない場合にも返される可能性がある。要求がHEAD要求でない限り、この応答には、使用可能なコーヒー追加物のリストを含んだエンティティが入っているべきである

現実問題として、現在のほとんどの自動コーヒーポットは追加物を提供できない。

2.3.2 418 おれはやかんだ

やかんでコーヒーをいれようとする試みはすべてエラーコード「418 おれはやかんだ」を返される。結果として生じるエンティティ本文は、なべに黒いと笑われる可能性がある

[ 訳者付記: 原文は英語圏の人間なら必ず幼稚園でならうお遊戯歌 "I'm a little tea pot, short and stout ..." がもとねただと思われる。]

3. "coffee" URI スキーム

コーヒーは国際的なので、国際化コーヒーURIスキームがつくられた。あらゆるコーヒーURLスキームは、URI国際化の慣習[URLI18N] にしたがい29のいかなる言語でも「コーヒー」に相当する単語を構成する文字を、UTF-8エンコーディングでURLエンコーディングして書かれる。

coffee-url  =  コーヒースキーム ":" [ "//" host ]
                ["/" ポット指示コード ] ["?" 追加物リスト ]

コーヒースキーム = ( "koffie"               ; アフリカーンス、オランダ語
               | "q%C3%A6hv%C3%A6"          ; アゼルバイジャン語
               | "%D9%82%D9%87%D9%88%D8%A9" ; アラビア語
               | "akeita"                   ; バスク語
               | "koffee"                   ; ベンガル語
               | "kahva"                    ; ボスニア語
               | "kafe"                     ; ブルガリア語、チェコ語
               | "caf%C3%E8"                ; カタロニア語、フランス語、ガリシア語
               | "%E5%92%96%E5%95%A1"       ; 支那語
               | "kava"                     ; クロアチア語
               | "k%C3%A1va                 ; チェコ語
               | "kaffe"                    ; デンマーク語、ノルウェー語、スウェーデン語
               | "coffee"                   ; 英語
               | "kafo"                     ; エスペラント語
               | "kohv"                     ; エストニア語
               | "kahvi"                    ; フィンランド語
               | "%4Baffee"                 ; ドイツ語
               | "%CE%BA%CE%B1%CF%86%CE%AD" ; ギリシャ語
               | "%E0%A4%95%E0%A5%8C%E0%A4%AB%E0%A5%80" ; ヒンディー語
               | "%E3%82%B3%E3%83%BC%E3%83%92%E3%83%BC" ; 日本語
               | "%EC%BB%A4%ED%94%BC"       ; 朝鮮語
               | "%D0%BA%D0%BE%D1%84%D0%B5" ; ロシア語
               | "%E0%B8%81%E0%B8%B2%E0%B9%81%E0%B8%9F" ; タイ語
               )

   ポット指示コード = "pot-" 整数  ; 複数個のポットをもつマシン用
   追加物リスト = #( 添加物 )

すべての代替コーヒースキーム形式は等価である。しかし、各言語でのコーヒースキームの使用は、そのコーヒーポットによって作られるコーヒーの種類を示すものとして解釈される可能性はある。なお、URLスキーム名は大文字小文字を問わないものの、ドイツ語においては名詞の語頭の大文字化は重要であり、したがって頭文字の「K」をエンコードしなくてはならない。

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

POSTやBREW要求のエンティティ本文は、必ずContent-Type "message/coffeepot" でなくてはならない。コーヒーポット制御情報のほとんどは追加ヘッダで伝えられるため、"message/coffeepot"の中身は以下のcoffee-message-bodyだけである:

   coffee-message-body = "start" | "stop"

5. 運用上の制約条件

本節では、HTCPCPを遍在的に導入するにあたっての運用上の課題について述べる。

5.1 タイミング上の課題

コーヒーポット・ユーザとコーヒーポットサービスの間には、堅牢なサービス品質が要求される。コーヒーポットは必ずネットワーク時間プロトコル(Network Time Protocol) [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ネットワークのアプリケーションとして適切なものだった。コーヒーポットのインストールにおいては、ケンブリッジ大学研究室のトロイ部屋が使用され、共有コーヒーポットの監視用にwebインターフェースが与えられた。これはわれわれ類似研究に従事していた者たちの共有物であり、貧しく赤貧にあえぐ学者であるわれわれは、全員で一台しかコーヒーフィルタマシンが買えず、それはトロイ部屋のすぐ外の廊下に設置されていた。しかしながら非常に熱心かつ精力的な研究者であったわれわれは、大量のコーヒーをも必要としたので、新鮮なコーヒーは煎れたとたんになくなる傾向にあった。

本サービスは、ケンブリッジ・コンピュータ研究室で設計された新しいRPCメカニズム、MSRPC2を用いた最初のアプリケーションとして創られた。これはATMネットワーク用に設計されたネットワーク層プロトコル、 MSNL (Multi-Service Network Layer) 上で動くものである。

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

7. セキュリティ上の検討事項

オレと朝の目覚めのコーヒーの間をじゃましようというヤツは、すべて低セキュリティ状態におかれる。

保護のないコーヒーポットに対し、インターネット利用者から無秩序なアクセスが行われれば、ある種の"denial of coffee service" attacks(「コーヒー提供拒否」攻撃)につながるおそれがある。また不適切なフィルタの使用はトラジャ(の木馬)コーヒー豆を許容してしまうおそれがある。フィルタはウィルス保護手段としては適切ではない。

コーヒー豆のかすをインターネット下水に流すと、配管がつまる可能性があり、結果としてインターネット配管工[PLUMB] のサービスが必要となる。配管工はさらに、インターネット配管ヘルパを必要とする。

アクセス認証については別のメモで論じるものとする。

8. 謝辞

Roy Fielding、 Mark Day、 Keith Moore、 Carl Uno-Manros、 Michael Slavitch、 Martin Duerst といったこの規格への多くのコントリビューター達に多いに感謝する。Prancing Pony、 CMU Coke Machine、Cambridge Coffee Pot, Internet Toaster、その他のコンピュータ制御の遠隔デバイスからのインスピレーションがこの価値ある発明に導いてくれた。

9. References

10. 著者のアドレス

Larry Masinter
Xerox Palo Alto Research Center
3333 Coyote Hill Road
Palo Alto, CA 94304

EMail: masinter@parc.xerox.com


Translator: 山形浩生
東京都千代田区大手町2-2-1
野村総合研究所 社会産業研究部
EMail: hiyori13@mailhost.net


Translator: 山根信二
宮城県仙台市青葉区片平
東北大学大学院 情報科学研究科
EMail: s-yamane@vacia.is.tohoku.ac.jp

(http://jp.gigahit.com/fy3/rfc2324-ja-jp.php3にも別の日本語訳があります。)

11. 著作権表示全文

Copyright (C) The Internet Society (1998).  All Rights Reserved.

 This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works.  However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.

   The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.