前 6‒18 p ｜ 
もくじ i ｜ 次 6‒20 n 
標準規格を定めるISOや日本のJISでは「ハッカー」という言葉の意味も定義されている。
日本の規格では、JIS X 0001:1994 「情報処理用語 ― 基本用語」の中で、 次のように定義されているという。
01.07 計算機の安全保護
01.07.03 (1)ハッカー 高度の技術をもった計算機のマニア。
01.07.04 (2)ハッカー 高度の技術をもった計算機のマニアであって，知識と手段を駆使して，保護された資源に権限を持たずにアクセスする人。
ISOではどうなっているのか。 対応する規格は ISO/IEC 2382-1:1993 だが、 お金を払ってダウンロードしないと読めないようになっている。 hacker の定義だけでも誰かが抜粋してないかな、と検索してもなかなかヒットしない。 しつこく調べると、エストニアにこの規格書をエストニア語対訳しているページがあるので、 そこから引用する。
ISO/IEC 2382-1:1993 Information technology -- Vocabulary -- Part 1: Fundamental terms
01
Fundamental terms
（基本用語）（中略）
01.07
Computer security
（コンピュータ・セキュリティ）（中略）
01.07.03
hacker (1)
A technically sophisticated computer enthusiast.
（高度の技術を持ちコンピュータに熱中する者）01.07.04
hacker (2)
A technically sophisticated computer enthusiast who uses his or her knowledge and means to gain unauthorized access to protected resources.
（高度の技術を持ちコンピュータに熱中する者のうち、 その知識と手法をプロテクトされたリソースへの無権限アクセスのために用いる者）
見るからにJISの元ネタで、番号まで同じだが、微妙に違いがある:
元ネタでは enthusiast （熱中する人）という価値的に中立な言葉になっている。 そこそこ意味は強いものの（大好き・夢中・没頭）、異常に・例外的に、とまでは行かない。 せいぜいぎりぎり「熱狂的」に届くか、という程度だろう。 必ずしも悪い語感ではなく、むしろ「非常に熱心」という褒め言葉にも使える。 これに対して、JISでは「マニア」というややネガティブな用語になっている。 マニアといったら、文脈によっては褒め言葉にもなるかも知れないが、 一般的には「変人」というイメージだろう。 夢中・熱中を通り越して「極端、病的」「普通の人はやらない」「異常な興味」というニュアンスだ。
さらに、元ネタでは単に uses 「使って」とあっさり流しているところもJISでは「駆使して」とこってりしている。 つまり、規格上、日本の「ハッカー」はISOの「hacker」より意味が強い。 うがった見方をすれば、hacker にとって「普通に熱中」「普通に使用」のことが、 ハッカー文化としては一応やっぱり後進国の日本から見ると「異常な熱狂」「手段を駆使」なのかもしれない。
ISO的に言えば、「高度の技術」と言っても「極端に」とか「例外的に」とか「異常に」高度である必要はなく、
technically sophisticated だから、それなりに洗練された技術を持っていればあてはまる。
さらに computer enthusiast は、マニアまでいく必要なく、趣味でコンピュータに夢中というレベルでも当てはまる語感だ。
ということは…
ISO的にはあなたも hacker ではありませんか（笑）
「いや違う」？ と言っても、国際標準化機構で公式に決めた定義に照らしてあてはまるのだから、 仕方ない。国際規格には逆らえませんぜｗ
いずれにしても、ハッカーの公式な定義は「技術的に優れている者」というのが標準で、 第二義（狭義）として、「そのなかでその技術を不正アクセスに使うもの」ということになる。
つまり「ハッカー」を一般的に「コンピュータ犯罪者」のような意味で使うことは、JISやISOの定義に反している。 特に、ページを書き換えたり、システムを破壊したり…といった行動は、ハッキングの定義と関係ない。 狭義（第二義）においても、 ハッカーのやることはガードを破ってアクセス・利用するところまでで、その先の行動はハックの本質ではない、ということになる。
コンピュータ技術用語なのだから、 やはりそれぞれの標準規格で定められている定義にしたがって、正しく使うべきだ、と、 一応建前としては、そういう結論。ただ、このメモは、言葉は正しく使いましょうみたいな意味ではなく、 単に「ハッカー」が正式に定義されているのはおもしろい、というネタ止まりだ。 あと、国際標準のような権威に弱い日本人をおちょくる…というのも入ってるかな。
ISO 2382 認定ハッカーとか言われると、おっ！？と思うでしょｗ
単にそれなりの技術があってコンピュータが好きなら全員当てはまるんですが…
お花はとってもデリケート。
1. 若いヒマワリのような、向日性の強い植物を、白夜の北極圏で平原に置くとどうなるか。 太陽を追って向きを変えていくと、茎がねじれてしまうのでは？
「太陽たん、太陽たん、くるくるくるくる…。あ゛ーこれ以上、首が回らないっ！！！」
2. 鉢を回転させて、常に植物にとっての見かけの太陽が同じ角度にあるようにする。 同時に、太陽と同等の光を発する光源二つを、別の角度から浴びせる。 向日性植物は三つの光のうち本物の太陽を選択できるか？
「なにこれ～？ 太陽がいっぱいある～～？！？！」
3. 室内で、太陽と同等の光源二つA, Bを植物から見て正反対の位置に設置する。 Aを点灯し、植物がAを向いたとたん、Aを消灯Bを点灯する。 このような意地悪を繰り返すと、最後にはどうなるか。
ふてくされて「もういい。どっちも向かない。しゃがんでひざをかかえて下を向いてやる」
コーヒーサーバ制御プロトコル HTCPCP を記述したRFC 2324の紹介。 RFCであるから厳密にはパブリックドメインではなく、 原著作権は The Internet Society にある。
コーヒーサーバ制御プロトコル HTCPCP 1.0 [RFC2324] には、 明確性・国際化などの点で、若干の技術的問題が認められた。 仕様の意図が不明確であったり、 原語（英語）に依存したジョークが国際化の妨げとなっていた。 本文書では、改訂されたプロトコル HTCPCP 1.1 を導入する。 これはオリジナルの RFC2324 とは、上述の点で、わずかに異なる。
ユビキタス・コンピューティングの世界において、 コンピューティストのコーヒー需要は高まっている。 真においしいコーヒーをいれるのは職人芸であったが、 ウェブ接続された世界の分散的知は、個人の技芸を超越する。 ネットは広大だ。
それゆえに、コーヒーをいれることに特化された挽きたてのプロトコルの必要性は、 濃く、深く、香ばしい。コーヒーをいれるには、コーヒーサーバが用いられる。 ネットワーク・コーヒーサーバを制御する必要がある場合、制御プロトコルが必要である。
インターネットに接続される家庭用装置は増加し続けている。 初期のネットワーク実験は、自動販売機をインターネットに接続し、 稼働状況をモニターできることを実証した [COKE]。 インターネット経由で遠隔操作できる初期のデバイスの例としては、 1990年に公開されたインターネット・トースターがあり、これは制御にSNMPを用いる [RFC2235]。
IPv4アドレスの枯渇を招きつつある器具のユビキタス接続への需要。 消費者はコーヒー沸かしのようなデバイスをリモートから制御して、 朝起きたときにいれたてのコーヒーが準備できていたり、 食事の用意ができた時点から正確に一定時間経過後にコーヒーが出てくるようにしたいと望む。
この文書は、ハイパーテキスト・コーヒーポット制御プロトコル（HTCPCP）を規定する。 HTCPCPは、 この人気の高いカフェイン飲料を生成するすべてのデバイスを制御するのに必要な、 完全なリクエストと応答のセットを与える。
HTTP 1.1 （[RFC2068]）を使えば、 送信元サーバからクライアントへのウェブ・オブジェクトの転送が可能である。 ウェブはワールドワイドであり、HTCPCP も HTTP をベースにする。 これはHTTPが普及しているためである。 良質でなければ普及することはあり得ない。 つまりHTTPは良質である。 良質のコーヒーが欲しければ、HTCPCPは良質である必要がある。 HTCPCPを良質にするには、HTCPCPをHTTPベースにすれば良い。
本プロトコルの将来のバージョンでは、 エスプレッソマシンや同様のデバイスに対応した拡張が含まれる可能性がある。
HTCPCP プロトコルは、HTTPをベースに、 若干の新しいメソッド、ヘッダーフィールド、リターンコードを追加することにより構築される。 すべてのHTCPCPサーバは、コーヒースキームにより参照されるべきである（第4節参照）。
コーヒー沸かしを制御するコマンドは、
クライアントからコーヒーサーバに宛てて BREW または POST メソッドのいずれかを使って送信される。
メッセージ本文は Content-Type ヘッダー application/coffee-pot-command を伴う。
コーヒーサーバは、BREW および POST メソッドを等しく扱わなければならない。
ただし、コーヒーサーバを作動させる目的で POST を使用することは推奨されない。
コーヒー沸かしは電気的メカニズムにより水を熱するから火を使わず、
したがってファイアーウォールは必要なく、
ファイアーウォール制御ポリシーも関係ない。
しかしながら POST, BOSS などはコーヒーの商標である可能性があるため、
BREW メソッドが追加された。
BREW メソッドは、
他のHTTPベースのプロトコル（ハイパーテキスト・ビール醸造プロトコル等）で使用しても良い。
HTTPでは、GETメソッドは「要求URIによって特定される何らかの情報を、
本文として送信せよ」という意味である。
要求URIがデータの動的生成プロセスを参照している場合、
レスポンスの本文として返されるのは生成されたデータである。
生成された出力は、ソースが自分自身を出力するようになっている場合を除き、
生成アルゴリズムのソーステキストとは異なる。
HTCPCPの場合も、コーヒーサーバと関連付けられているリソースは物理的であり、 情報リソースではないが、 ほとんどのコーヒースキームのデータは、コーヒーとは異なる。
コーヒーがデータである場合、
コーヒー生成に関するメタデータは、PROPFINDメソッドによって取得できる [WEBDAV]。
コーヒーが注がれ好みに応じた量のミルクが提供される場合、
ミルクを入れてもらう側は、適量のミルクがコーヒーに注がれた時点でストップをかける必要がある。
この目的のため、HTCPCP には WHENメソッドが追加された。
このくらいでいいかなと思ったら、ユーザはWHENを送信しなければならない。
コーヒーサーバはWHENの受信がないままミルクがカップからあふれはじめた場合は、タイムアウトとして生成オブジェクトを破棄して良い。
HTCPCP ではいくつかの HTTP ヘッダーフィールドの使用が推奨されるとともに、 若干の新しいフィールドが定義される。
2.2.1.1 "safe"応答ヘッダーフィールド
[SAFE] では、HTTP 応答ヘッダーフィールド Safe が定義されており、
HTTPリクエストを反復することが安全であることを示すのに使うことができる。
応答に Safe: Yes が含まれる場合、
クライアントは、任意に前回のリクエストを反復することが許可される。
コーヒー生成の実際の安全性は千差万別で、
実際にはコーヒーサーバ側だけではなく、クライアントの状態にも依存する。
例えば、コーヒー沸かしは安全な耐熱ガラスを使用している場合でも、
朝ちゃんと目が覚めていない状態のクライアントはガラスを割ってしまうかもしれない。
また、けんか中の相手に乱暴な口調でコーヒーをいれさせようとすると、
相手は怒って熱いコーヒーの入ったカップを放り投げてくる可能性があり、
catch の難しい例外が発生する。
こうした安全上の問題に対応するため、
本プロトコルでは、Safe応答ヘッダーを拡張する。
Safe = "Safe" ":" 安全性
安全性 = "yes" | "no" | 条件付きで安全
条件付きで安全 = "if-" 安全条件
安全条件 = "user-awake" | トークン
この情報を使って、ユーザエイジェントは安全なリクエスト、
特に安全な POST リクエストを、ユーザフレンドリーな形で反復することができる。
例えば、クライアントは「可能なら（もう怒っていないなら）コーヒーをいれてください」というリクエストを POST するかもしれない。
これはインターネット上のコミュニケーションを円滑にするであろう。
2.2.2.1 Accept-Additions ヘッダーフィールド
HTTPでは、Acceptリクエスト・ヘッダーフィールドは、
応答として受け入れ可能なメディア型を指定するのに用いられる。
しかしながら、HTCPCPでは、
要求に応えるために自動コーヒーサーバ側の追加的動作が必要となる可能性がある。
そのため、HTCPCPでは、新しいヘッダーフィールド
Accept-Additions を追加する。
以下にその用例を示す（付加物は例示であり、これ以外の付加物を指定することを妨げない）。
Accept-Additions = "Accept-Additions" ":"
#( 付加レンジ [ 付加パラメータ ] )
付加物 = ( "*"
| ミルク型
| シロップ型
| 甘味料型
| スパイス型
| アルコール型
) *( ";" パラメータ )
ミルク型 = ( "クリーム" | "ハーフアンドハーフ" | "全脂乳"
| "ハーフスキム" | "スキム" | "人工乳"
| "スーパーミルク" | "テツコ" | "ハナゲ" )
シロップ型 = ( "バニラ" | "アーモンド" | "ラズベリー"
| "チョコレート" | "スイートミント" | "ストロベルベル" )
アルコール型 = ( "ウイスキー" | "ラム" | "リキュール" | "アクアビット" )
「カフェイン抜き」オプションはサポートされない。 興奮作用を中和したい場合は、麻薬を追加指定しても良いが、 このようなリクエストは多くの国と地域において法的な面で不正である。
コーヒーサーバからミルクを取得するためのいわゆる「コーヒー抜きミルクコーヒー」裏技は、
HTCPCP 1.1 においてはもはやサポートされない。
コーヒーサーバはすべてのコーヒー抜き指定を Bad Request と扱わなければならない。
通常のHTTPリターンコードの使用だけでは、 HTCPCPサーバの実現は困難である。 本節では、既存のコードの特別な解釈と、新しいリターンコードを規定する。
HTTPでのこのコードの通常の解釈は、「指定のリソースは、
要求の条件を満たす形では提供できない」であるが、
HTCPCPでは、この応答コードを「要求の付加物には応じられない」という意味で用いても良い。
例えばクライアントがコーヒーの付加物としてピーナッツやビールやジャズやクラシック音楽や
カチューシャ付きメイドや妹などを要求した場合、
技術的にはそれらはコーヒーの付加物と認められないわけではないが、
通常、サーバは406 Not Acceptable を返すであろう。
要求が HEAD リクエストである場合を除き、
本文として提供可能な付加物リストを送信するべきである。
クライアントは付加物として、みだらな要求をするべきではない。
実際には、現在、ほとんどの自動コーヒーサーバは付加物を提供できない。
ユビキタスな世界ではあらゆるものがネットに接続されているが、 識別子のミスタイプなどから、 往々にして間違ったあて先に対するリクエストが発生する。
きゅうすに対してコーヒーが要求された場合、 きゅうすは、418エラー「わたしはきゅうすです（怒）」を返すべきである。
クライアントがわびを入れてきたときは、
きゅうすは、303 See Otherレスポンスを用いて、
同一LAN内のコーヒーポットの正しいアドレスを通知しても良い。
coffee-url = コーヒースキーム ":" [ "//" コーヒーサーバアドレス ]
["/" ポット識別子 ] ["?" 付加物リスト ]
コーヒーは国際的であるため、コーヒースキームは国際化されている。
「コーヒー」を意味する29か国語の単語のいずれでも、
UTF-8を用いる国際化規約 [URLI18N] に従って用いることができる。
例えば、coffee://foo/pot-0 の代わりに日本語で、
%E3%82%B3%E3%83%BC%E3%83%92%E3%83%BC://foo/pot-0
としても良い。
これら29種類のコーヒースキームは同等である。
ただし、コーヒースキームの言語区分は、コーヒーサーバが生成するコーヒーの種類を示すものと解釈しても良い。
URLは大文字と小文字を区別しないが、
コーヒースキームでは大文字と小文字を区別する。
ドイツ語で注文するときは、名詞の語頭が大文字であることから、
%4Baffee://
とエンコードしなければならない。
POST または BREW リクエストの応答は、
Content-Type: message/coffeepot
でなければならない。
コーヒーサーバを制御するための情報のほとんどは付加ヘッダーによって伝送されるため、
本文は以下のものに限られる。
本文 = "start" | "stop"
このセクションでは、 HTCPCPサーバをユビキタスに運用する上での問題のいくつかを扱う。
コーヒーサーバとコーヒーユーザの間では、 エラーのないサービスが求められる。 コーヒーサーバは Network Time Protocol [NTP] を用いて、 内部時計を協定世界時に正確に同期させるべきである。
ロボット遠隔操作は高価な技術であるが、 Cambridge Coffee Pot [CAM] の出現により、 （SNMPでなく）ウェブを使ってリモートシステムを監視・管理できることが証明された。 付加的なコーヒーサーバ維持作業も、遠隔操作によって実現されるかもしれない。
ウェブデータは通常、静的である。それゆえ、データの転送帯域と時間を節約するために、 ブラウザーはウェブページをユーザのコンピュータにキャッシュする。 ユーザがそのページに戻りたい場合、データはローカルに蓄えられており、 新たにサーバから取得する必要はない。 遠隔ロボット制御で必要なモニター画像は動的である。 アクセスのたびに最新のバージョンを取得する必要がある。
ほとんどの組織で、HTTPトラフィックはファイアーウォールを非常に容易に通過する。 現代のコーヒーサーバは火を使わないが、「防火壁」は火だけでなく、 あらゆる熱源からの保護に有効である。 家庭用コンピューターもすべてファイアーウォールによって熱源から保護されるべきである。 一方、外出時にコーヒーサーバを遠隔操作できることは重要である。 それゆえ、HTCPCPがファイアーウォールを容易に通過できることは重要である。
HTTPはファイアーウォールを通過できるが、 HTCPCPをHTTPベースとしポート80を使うことで、 HTCPCも同じ長所をすべて利用できる。 もちろん、HTCPCPに特有のメソッド、ヘッダー、本文に対応するためには、 ファイアーウォールの設定変更やバージョンアップが必要になるだろう。 だが、そのようなアップグレードは容易に実現可能である。 システム管理者のほとんどはコーヒーを飲むので、HTCPCPをトンネルさせることに進んで協力してくれるであろう。
HTTPプロトコルを使ったコーヒーポットのモニターは、 ウェブの実用的利用の先駆的試みである。 最初期の事例では、コーヒーポットのモニターは、 ATMネットワークの初期における有効利用であった [CAM]。
伝統的な技術 [CAM] は、 ビデオカメラにフレームグラバーを取り付け、デジタル化したイメージをウェブサーバにフィードするものであった。 これは ATMネットワークの有効活用だった。 コーヒーポットの場合、ケンブリッジ大学の研究室が、 共用コーヒーポットをモニターするためのウェブインターフェイスを提供するのに用いられた。 みじめで貧しい研究者であったわれわれには、全員で一台のコーヒーメーカーしかなかった。 それは研究室を出たすぐそこの廊下に置いてあった。 まじめで熱心で研究者であったわれわれは、大量のコーヒーを摂取し、 誰かがコーヒーをいれると、すぐなくなってしまうことが多かった。
そこで、ケンブリッジ大学のコンピューター研究所用に設計されたRPC機構（MSRPC2）の最初の活用例として、 コーヒーポットの状態モニターが始まったのである。 ATMネットワークのために設計されたMSNL (Multi-Service Network Layer) の上で稼働するものである。
インターネット上のコーヒーポットは、 Coffee Pot MIB を用いて運用しても良い [CPMIB]。
朝コーヒーを飲むのをじゃまする者は、 すべてセキュリティー上の問題とみなされる。
保護されていないコーヒーポットへのインターネットからの無制限のアクセスは、 コーヒーサービス拒否攻撃を招く可能性がある。 コーヒーフィルターの不適切な使用は、出がらしの粉などの異物のコーヒー内侵入を許す結果を招く。 コーヒーフィルターではウィルスに対して有効な防御とはならない。
インターネットの配管に異物が入ると、配管が詰まる可能性があり、
broken pipe エラーの原因となる。
モンスターボールに入れて転送する方式では、配管が詰まると修理には危険を伴う。
目がチカチカして気分が悪くなる副作用が報告されている [POLYGON]。
