|
||||||
 |
||||||
|
||||||
その65「RFCのプロセス」 |
||||||
|
||||||
|
||||||
|
||||||
|
||||||
|
||||||
|
■ RFCって何？ 1月初旬、SSHに関するRFCが公開されました。RFC4250からRFC4256までの7つがそれなのですが、個人的には「え？ RFCじゃなかったの？」ということにむしろ驚いたりもしました。そこで思いついたのが、「そういえば、そもそもRFC自体の説明をしていなかったなぁ」ということ。そんなわけで、今回はRFCを取り上げてみたいと思います。RFCは「Request For Comment」の略で、直訳すれば「コメント募集」なわけですが、日本語では「標準勧告文章」と訳されるのが一般的です。文字通り、インターネットに関わるさまざまなプロトコルや技術的手段、情報などを網羅するものであり、事実上インターネットを規律する唯一の根拠と言っても良いでしょう。もっとも、インターネットはRFCを拠り所に運営されているわけで、その意味では規範と言っても良いわけですが、実際のRFCはもう少しくだけた感じに作られていたりします（これは後述）。 ■ RFCのプロセス
IABはその後、「Internet Architecture Board（インターネットアーキテクチャ委員会）」と名前を変えて現在も存在しています。当初はこのIABがRFCの標準化にまつわる作業を手がけていました。その後、IABの上位組織として「ISOC（Internet Society：インターネット学会）」が1992年に設立されるとともに、IABの下位組織として「IETF（Internet Engeneering Task Force：インターネット技術標準化委員会）」が設立されました。 現在、RFCの標準化処理に責任を持つのが、このIETFです。ただし、実際の標準化作業は、IETFの下に「IESG（Internet Engeneering Steering Group：インターネット技術標準化運営グループ）」という組織が設けられ、ここがハンドリングしています。そんなわけで、RFCの標準化作業は、IESGが行なうことになっています。 さて、そのIESGがどんな形でRFCを標準化していくか、という過程を次に説明します（図1）。まず、誰かがドラフト（Internet Draft）を作ります。これは極端な話、誰が作っても構いません。RFCのフォーマットにのっとり（実はこのフォーマットそのものも、RFCに定義されています）、RFCを発行するに足る要件を満たしていれば（これが結構怪しいのですが）、誰でもRFCのドラフトを作成できます。 また、まったく別の組織が作成したプロトコルがここに持ち込まれる場合もあります。冒頭で述べたSSHなどこの良い例であって、その23で説明した通り、当初SSHは商用製品として出発、その後オープンソースなどで利用されていく中でRFC化の必要性が出てきたということです。 さて、ドラフトもしくはすでに存在するプロトコルがIESGに持ち込まれた場合、まずここで最初の審議が行なわれます（現在どんなドラフトが持ち込まれているのか、というのはこちらのページから見ることができます）。必要な要件を満たし、標準化の価値がありと見なされた場合、そこでRFCの番号が割り振られるとともに、ドラフトは標準化提案（Proposal Standard）というステージに格上げされます。 この段階で、複数のグループによりそのプロトコルの実装やテストが行なわれ、必要ならば改訂も行なわれます。この標準化提案の期間は最低6カ月とされており、ここで問題がなかった、あるいは解決されたという場合は、IESGの承認のもとに標準化草案（Draft Standard）のステージとなります。このステージにおいては、最低4カ月以上、広範なテストやさまざまな意見の募集を行なうことになっています。ここでもさらに問題がないとみなされた場合、IESGの承認を経て標準（Standard）のステージになります。 その後、プロトコルの内容が変わらずにずっと使いつづけられる限り、そのRFCはStandardのステージに居続けるわけですが、例えば新規の拡張とか、これを包括する上位あるいは別プロトコルがRFCとして出現し、標準化された場合、旧RFCは自動的に歴史（Historic）の扱いに変わります。廃案化されたRFCはObsoletes（廃物）として扱われてHistoricのカテゴリに入れられるほか、はじめから歴史を記述したもの（例えば、RFC2235がこれにあたります）もここに入れられます。また、標準化の過程で廃案になったものも、やはりHistoricになるわけです。
■ RFCの扱い
このPASというのは、要するにRFCで標準化されたものはそのまま国際標準として転換して良いというもので、ISOそのもので標準化された基準とは区別されますが、現実問題としてはほぼ同様の扱いをされています。ISOで定められた国際標準は、日本ならJISでそのまま標準化されることも少なくないわけで、RFCはつまりこれに準じた標準規格であると認知されているわけです。標準化された規格（というか、RFCですからプロトコル）が尊ばれるのは当然のことです。 また、標準化の過程がオープンで、しかも標準化に対して意見を述べやすいのも特徴の1つです。先の標準化プロセスの中で、標準化提案や標準化草案の段階のRFCに対してコメントを出すことは容易であり（Request for Commentという名前がそもそも、こうした審議の過程でなるべく多くのコメントを出してくれという意味なあたりからも、これが伺えます）、これもまたRFCが尊ばれる理由の1つであります。もちろん、意見が紛糾して議論が収束しないケースもあるので、必ずしもこの仕組みが万能というわけではないのですが、それでも密室で勝手にスペックが決まったりするよりは、はるかにマシであると考える人が多いようです。 RFCの難点があるとすれば、標準化された規格ですから、プロトコルそのものを商売にするのが難しくなることでしょう。例えば、RealNetworks社のReal VideoやMicrosoftのWindows Videoはストリーミング配信をサポートしていますが、これらのストリーミングプロトコルは公開されておりません。というのは、プロトコルそのものがノウハウの塊であり、両社にとってこれをRFCにしてしまうと、自社の製品が売れなくなることを当然恐れているからです。こうしたケースは結構多いわけで、プロトコルそのものを商売の種にするベンダーにとってRFCは非常に使いにくいものになっています。 ■ 余談
・RFC1149 IPデータグラムの転送に鳥類（！）を使った配送方法。パケットの内容を印刷し、鳥の足にくくりつけて飛ばすことを想定しています。要するに伝書鳩のIP版なのですが、これにトライしたグループが出てきたことで、真面目（？）な規格になってしまいました。 ・RFC1313 （架空の）インターネットラジオの番組表。 ・RFC1882 「クリスマス前の12日間のテクノロジー」（なんか読んでいたらJITTERIN’JINNの「プレゼント」を連想してしまいました）。 ・RFC1926 ATM（音響伝達媒体）経由でのIPデータグラムの転送。要するにモールス信号を使ってIPパケットを送る方法を記述しています。 ・RFC2322 洗濯バサミを使ってDHCPの管理を行なう方法。日本でこれの実装例を紹介されている方もおられます（笑）。 ・RFC2549 RFC1149のアップデート版で、QoSの概念が追加されています。しかし、ダチョウクラスって……。 ・RFC3514 IPパケットに“悪意”があるかどうかを判断するbitを追加する、という試み。 ・RFC4042 大昔のマシンの中には、8/16/32bitではなく9/18/36bitをベースにしたものがあります。有名なのはDECのPDP-10、その後継のDEC System20という、今から20年～30年ほど前に現役だったマシンですが、これらのために9bitを基本としたエンコーディング（UTF-9/UTF-18）を定めましょうというもの。次は旧ハニウェルとかNECの大昔のマシン用にUTF-6とかUTF-12が出てくるかも。 これらは俗に「Joke RFC」と言われており、毎年4月1日には必ず新しいRFCが追加されますが、必ずしも4月1日だけではなく、12月とか3月とか、割と無関係に登場するケースもあります。面白いのは、こうしたJoke RFCを“真面目に”審議して通していることで、ISOとかJISでは考えられないおおらかさを感じます。もちろん、真面目なRFCは真面目に議論しているわけですが、こういう遊びを許容するのがRFCの文化、と考えれば良いでしょう。 2006/02/06 10:54
|
 |
|
| Broadband Watch ホームページ |
|
|
|
|
|
|
| Copyright (c) 2006 Impress Watch Corporation, an Impress Group company. All rights reserved. |