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. 理論的根拠と適用範囲 珈琲は世界中どこにでもある。コンピュータの利用が拡がっていく世界に おいて、コンピュータを扱う人はますますコーヒーを淹れたがるようにな る。コーヒーを淹れることはアートであるが、ウェブで接続された世界に 分散している知恵はアートを超越している。したがって、コーヒーを淹れ るためにエスプレッソのように設計されたプロトコルが、濃く(strong, dark)、豊か(rich)に必要となる。珈琲は珈琲ポットを使って淹れる。ネッ トワーク珈琲ポットを制御しようとした場合、これは制御プロトコルが必 要となる。 家庭や消費財は次第にインターネットに接続されてきた。初期のネットワー ク実験で状態監視のためにインターネットに接続された自動販売機が実現 された[COKE]。インターネットに接続されて遠隔操作された初めての機器 のひとつ、インターネットトースター(SNMP により制御される)は 1990 年 にデビューした[RFC2235]。 至るところにある電気製品を接続しようとすることで、IPv4 のアドレス空 間を消費してしまう。消費者は、おめざに淹れたての珈琲を飲んだり夕食 の準備が終わった丁度そのときに珈琲を準備するために、珈琲ポットのよ うな装置を遠隔操作したがる。 Masinter Informational [Page 1] RFC 2324 HTCPCP/1.0 1 April 1998 この文書は、ハイパーテキスト珈琲ポット制御プロトコル(Hyper Text Coffee Pot Control Protocol(HTCPCP))を規定する。このプロトコルは、 それにより、万民に愛されているカフェインたっぷりの暖かい飲み物を作 ることのできるあらゆる装置を制御するのに必要となるすべてのリクエス トと返答を許す。 HTTP 1.1 ([RFC2068]) は、元となるサーバからクライアントに向けてウェ ブオブジェクトを転送するのを許す。ウェブは世界中に広まっている。 HTCPCP は、HTTP をもとにしている。HTTP はどこにでもあるからだ。いい ところがないのにこんなに普及するはずはない。つまり、HTTP はすばらし い。美味しい珈琲が欲しければ、HTCPCP をいいものにしなければならない。 HTCPCP をいいものにするためには、HTTP をもとにするのが都合がよい。 このプロトコルの将来の版は、エスプレッソマシンやそれと同様の装置の ための拡張を含むようになるかもしれない。 2. HTCPCP プロトコル HTCPCP プロトコルは、いくつかの新しいメソッドとヘッダフィールドとリ ターンコードを付け加えて、HTTP の上に構築する。あらゆる HTCPCP サー バーは、URI スキームを "coffee:" により参照する(Section 4)。 2.1 HTCPCP の追加メソッド 2.1.1 BREW メソッド、そして POST の使用法 珈琲ポットを制御するコマンドはクライアントから珈琲サーバーに向けて、 メッセージボディの Content-Type を "application/coffee-pot-command" にセットした BREW メソッドまたは POST メソッドのどちらかを使って送 られる。 珈琲ポットサーバーは、BREW メソッドと POST メソッドの両方をまったく 同等に受け付けなければいけない。ただし、動作を発生させるために POST を使うのは勧めない。 珈琲ポットはお湯を作るのに電子的メカニズムを使うので、火は存在しな い。したがって、防火壁(ファイアウォール)は不要であり、防火壁を制御 するポリシーは無意味だ。しかしながら、POST は珈琲の登録商標かも知れ ないし、BREW メソッドは追加されたものだ。BREW メソッドはほかの HTTP をもとにしたプロトコル(たとえばハイパーテキストビール醸造所制御プロ トコル)に使われるかもしれない。 2.1.2 GET メソッド HTTP では、GET メソッドは「リクエストURIで指定されるどんな情報でも (存在している形式で)検索する」という意味で使われる。もし、リクエス トURI がデータ生成プロセスを参照するなら、レスポンスの実体として戻 されるのは作成されたデータであって、そのテキストがプロセスの出力だ という場合以外は、プロセスのソーステキストではない。 Masinter Informational [Page 2] RFC 2324 HTCPCP/1.0 1 April 1998 HTCPCP では、珈琲ポットと関連するリソースは実体であって情報リソース ではない。ほとんどの coffee URI にとってのデータはカフェインを含ま ない。 2.1.3 PROPFIND メソッド 珈琲1杯がデータとすれば、淹れられたリソースに関するメタデータは PROPFIND メソッドを使って見つけられる[WEBDAV]。 2.1.4 WHEN method 珈琲が注がれ、ミルクが提供されたとき、ミルクの受取る入れ物は十分な ミルクが珈琲に導入された時に「WHEN」という必要がある。この目的で、 WHEN メソッドは HTCPCP に加えられた。十分かな? 「WHEN」と言おう。 2.2 珈琲ポットヘッダーフィールド HTCPCP では、若干の HTTP ヘッダーフィールドを推奨し、新しい物を定義 する。 2.2.1 推奨されるヘッダーフィールド 2.2.1.1 「safe」レスポンスヘッダーフィールド [SAFE] は、HTTP レスポンスヘッダーフィールドの "Safe" を定義する。 これは、HTTP リクエストを繰り返してもだいじょうぶということを示して いた。"Safe: Yes" ヘッダーフィールドを含むものは、リクエストの結果 が繰り返されたとしても、クライアントが前のリクエストを繰り返すこと を許す。 珈琲を淹れる装置の実際の安全性は非常に多様であり、クライアントより はむしろサーバーの状態に依存するかもしれない。というわけで、このプ ロトコルは、次のような "Safe" レスポンスヘッダーを含む。 Safe = "Safe" ":" safe-nature safe-nature = "yes" | "no" | conditionally-safe conditionally-safe = "if-" safe-condition safe-condition = "user-awake" | token これを含めることで、ユーザーエージェントがいくつかの安全なリクエス ト(特に安全な POST リクエスト)のリトライをよりユーザーフレンドリー な方法で取り扱うことができるようになる。 Masinter Informational [Page 3] RFC 2324 HTCPCP/1.0 1 April 1998 2.2.2 新しいヘッダーフィールド 2.2.2.1 Accept-Additions ヘッダーフィールド HTTP では、"Accept" リクエストヘッダーフィールドはレスポンスとして 受け入れられるメディアタイプを指定するのに使われた。一方、HTCPCP で は、レスポンスが自動化されたポットの一部における追加的な動作となる ことがある。このような理由から、HTCPCP では、新しいヘッダーフィール ド "Accept-Additions" を次のように定める。 Accept-Additions = "Accept-Additions" ":" #( addition-range [ accept-params ] ) addition-type = ( "*" | milk-type | syrup-type | sweetener-type | spice-type | alcohol-type ) *( ";" parameter ) milk-type = ( "Cream" | "Half-and-half" | "Whole-milk" | "Part-Skim" | "Skim" | "Non-Dairy" ) syrup-type = ( "Vanilla" | "Almond" | "Raspberry" | "Chocolate" ) alcohol-type = ( "Whisky" | "Rum" | "Kahlua" | "Aquavit" ) 2.2.3 取り除かれるヘッダーフィールド カフェイン抜きの珈琲を与えるオプションなんてない。何か問題でも? 2.3 HTCPCP のリターンコード 普通の HTTP のリターンコードは HTCPCP サーバーの困難さを表すのに使 われる。この節では特別な解釈と新しいリターンコードを規定する。 2.3.1 406 受け入れられない このリターンコードは、通常、「リクエストで指定されたりソースがリク エストの中で送られたアクセプトヘッダー(accept header)にしたがった、 受け入れ可能な性質のコンテンツをレスポンスの実体として生成すること ができないだけ」というように解釈される。HTCPCP では、このレスポンス コードは珈琲ポットのオペレーターが "Accept-Addition" リクエストに応 じられないときに戻されるかもしれない。リクエストが "HEAD" リクエス トでない限り、レスポンスは利用可能な珈琲添加物のリストを含んだ実体 を含めるべきだ。 Masinter Informational [Page 4] RFC 2324 HTCPCP/1.0 1 April 1998 実際のところ、ほとんどの自動化された珈琲ポットは現状では珈琲添加物 を提供することができない。 2.3.2 418 ティーポットだ ティーポットで珈琲を淹れようとすると、"418 I'm a teapot" というエラー コードが必ず戻る。結果として戻される返事は短く断固としたものになる かもしれない。 3. "coffee" URI スキーム 珈琲は国際的なものであるから、国際的な coffee URI スキームが存在す る。あらゆる coffee URL スキームは 29 の言語のうちのどれかで "coffee" という単語を綴った文字の UTF-8 エンコードを URL エンコー ドしたもので記述される。以下に、URI を国際化したものをあげる [URLI18N]。 coffee-url = coffee-scheme ":" [ "//" host ] ["/" pot-designator ] ["?" additions-list ] coffee-scheme = ( "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-designator = "pot-" integer ; たくさんのポットのある機械用 additions-list = #( addition ) Masinter Informational [Page 5] RFC 2324 HTCPCP/1.0 1 April 1998 すべての coffee スキームの派生形は同等である。しかし、様々な言語で coffee スキームを使うのは珈琲ポットで作られる珈琲の種類の指示として 解釈されることもある。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 タイミングについて サービスの強固な品質が珈琲ポットのユーザーと珈琲ポットサービスの間 に必要とされる。珈琲ポットは、ネットワークタイムプロトコル [NTP] を 使ってクロックを世界的に正確な時刻標準に合わせるべきだ。 遠隔ロボット技術は高価な技術だった。しかし、ケンブリッジ珈琲ポット の出現により、遠隔システム監視・管理にウェブ(SNMP ではなく)の利用が 実証された。追加的な珈琲ポットメンテナンスは遠隔ロボット技術により 実現されるだろう。 ウェブのデータは、通常静的である。それゆえ、データ転送と時間の節約 のため、ウェブブラウザプログラムは、個々のユーザが検索したウェブペー ジをユーザのコンピュータに保存する。よって、ユーザがそのページに戻 りたければ、それはローカルに保存されており、サーバーから再取得する 必要はない。ロボット制御や場面転換の監視のために使われる画像は動的 である。新しい物がサーバーからアクセスされる度に検索される必要があ る。 5.2 ファイアウォールまたぎ 多くの組織で、HTTP のトラフィックは、実に用意にファイアウォールを越 えている。近年の珈琲ポットは「火」を使わない。しかし、ファイアウォー ルは「火」のみならずいかなる熱の影響からも任意の資源を保護すること ができる。すべての家庭用コンピューターネットワークはファイアウォー ルにより熱源から保護されるべきだ。しかし、家の外からの珈琲ポットの Masinter Informational [Page 6] RFC 2324 HTCPCP/1.0 1 April 1998 遠隔制御は重要である。したがって、HTCPCP が容易にファイアウォールを 越せることもまた重要である。 HTCPCP が HTTP をベースとしていて 80 番ポートを使っていることにより、 HTTP のもつあらゆるファイアウォール越えの利点を得ている。もちろん、 家庭用ファイアウォールは HTCPCP に特有のメソッドやヘッダ、トレーラー に対応するために、再設定または新しいバージョンが必要となるが、その ような更新をするのは簡単に対応できる。ほとんどの家庭用ネットワーク システムの管理者は珈琲を飲み、HTCPCP をトンネリングすることに対応す るつもりである。 6. システム管理について HTTP プロトコルにより珈琲ポットを監視することは、ウェブの初期のアプ リケーションだった。初期段階では、珈琲ポットの管理は初期の(そして適 当な) ATM ネットワークの利用であった [CAM]。 伝統的な技術 [CAM] により、ビデオカメラにフレームグラブ機能を付属さ せ、ウェブサーバーに画像をフィードする。これは、ATM ネットワークに よくあったアプリケーションである。この珈琲ポットをおくことにより、 ケンブリッジ大学の研究室のトロジャンルームは、共用の珈琲ポットを監 視するためにウェブインターフェースを与えるために使われていた。我々 は、関連する研究に没頭しており、貧しく不毛な大学人なので、珈琲フィ ルターマシンをたった1つしか持っていない。それはトロジャンルームの すぐ外の廊下にある。しかしながら、学問に生涯を捧げ、一生懸命働いて いるので、我々はたくさんの珈琲を平らげ、新しくポットを淹れるとしば しば長持ちしない。 このサービスは、ケンブリッジコンピューター研究室が設計した新しい RPC メカニズム --- MSRPC2 を使った最初のアプリケーションとして作ら れた。これは、ATM ネットワークのために設計されたネットワーク層であ る MSNL (Multi-Service Network Layer) を越えて動く。 インターネット上の珈琲ポットは Coffee Pot MIB を使って管理されるだ ろう [CPMIB]。 7. セキュリティについて わたしとモーニングコーヒーの間に入り込んでくる人はだれでも安全では ない。 インターネットユーザからの保護されていない珈琲ポットへの不適切なア クセスは、ある種の「珈琲供給不能」攻撃となるだろう。不正な濾過装置 の利用は、トロジャングランドを認めることになるかもしれない。濾過は ウィルスプロテクトとして適当でない。 Masinter Informational [Page 7] RFC 2324 HTCPCP/1.0 1 April 1998 珈琲ひきをインターネットの配管に設置することにより配管が詰まるかも しれない。これはインターネット配管工事サービスを必要とするだろう [PLUMB] 。そして今度は、その人はインターネット配管工事サービスヘル パーが必要になるだろう。 アクセス認証については、別のメモで議論されるだろう。 8. 謝辞 この標準のために多くの寄与をしてくれた、Roy Fielding, Mark Day, Keith Moore, Carl Uno-Manros, Michael Slavitch, そして Martin Duerst に深く感謝します。Prancing Pony, the CMU Coke Machine, the Cambridge Coffee Pot, the Internet Toaster, そしてその他のコンピュー タで遠隔制御される装置の発想のおかげでこの価値ある創造に至ることが できた。 9. 参考文献 [RFC2068] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2068, January 1997. [RFC2186] Wessels, D., and K. Claffy, "Internet Cache Protocol (ICP), version 2," RFC 2186, September 1997 [CPMIB] Slavitch, M., "Definitions of Managed Objects for Drip-Type Heated Beverage Hardware Devices using SMIv2", RFC 2325, 1 April 1998. [HTSVMP] Q. Stafford-Fraser, "Hyper Text Sandwich Van Monitoring Protocol, Version 3.2". In preparation. [RFC2295] Holtman, K., and A. Mutz, "Transparent Content Negotiation in HTTP", RFC 2295, March 1998. [SAFE] K. Holtman. "The Safe Response Header Field", September 1997. [CAM] "The Trojan Room Coffee Machine", D. Gordon and M. Johnson, University of Cambridge Computer Lab, [CBIO] "The Trojan Room Coffee Pot, a (non-technical) biography", Q. Stafford-Fraser, University of Cambridge Computer Lab, . [RFC2235] Zakon, R., "Hobbes' Internet Timeline", FYI 32, RFC 2230, November 1997. See also Masinter Informational [Page 8] RFC 2324 HTCPCP/1.0 1 April 1998 [NTP] Mills, D., "Network Time Protocol (Version 3) Specification, Implementation and Analysis", RFC 1305, March 1992. [URLI18N] Masinter, L., "Using UTF8 for non-ASCII Characters in Extended URIs" Work in Progress. [PLUMB] B. Metcalfe, "Internet Plumber of the Year: Jim Gettys", Infoworld, February 2, 1998. [COKE] D. Nichols, "Coke machine history", C. Everhart, "Interesting uses of networking", . 10. 著者の連絡先 Larry Masinter Xerox Palo Alto Research Center 3333 Coyote Hill Road Palo Alto, CA 94304 EMail: masinter@parc.xerox.com Masinter Informational [Page 9] RFC 2324 HTCPCP/1.0 1 April 1998 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. Masinter Informational [Page 10]