要約

  • ホスト要件作業班は、現実の実装とプロトコル規則をすり合わせ、設計の純粋さより相互運用性を優先した。
  • RFC 1122とRFC 1123が実用上の基準を示し、RFC 1127は合意と未解決の論点を記録した。

1989年、問題はインターネットにプロトコルがあるかどうかだけではなかった。異なるホストのソフトウェアが、十分に共通した規則に従って通信できるかが問われていた。公開されたプロトコルを実装しても、古い文書が積み重なった結果、仕様の隙間や矛盾、未決定の選択に直面することがあった。その差は、ある機器が別の機器へ接続しようとしたとき、利用者の目に現れる。

IETFのホスト要件作業班は、この実装上の境界を明確にするため約20か月を費やした。作業と同時期に公表された回顧で、編集者のRobert Bradenは、正式会合7回、約3メガバイトの電子メール、中心となる専門家約20人と、重要な貢献をした別の約20人を挙げている。文書はおよそ20種類の草案を経た。いずれもBradenによる概数で、出席者数やメール量を監査した記録ではない。RFC 1127

目標の優先順位は、やり取りの量よりも作業の性格をよく示している。作業班は相互運用性、拡張性、機能性、効率性、アーキテクチャの純粋さを掲げた。Bradenによれば相互運用性が明らかに最優先で、純粋さは最後だった。中間の三項目の順序は論点ごとに異なる。完全に整ったモデルをすべての実務に当てはめるより、異なる実装が一緒に動くことを重視した。

成果は1989年10月、二つの標準として公表された。RFC 1122はリンク層、IP層、トランスポート層を扱い、RFC 1123はアプリケーションとサポートのプロトコルを扱う。両文書はホストソフトウェアの要件を示し、RFC 1122は当時のインターネットアーキテクチャを実現する規則だと説明している。ゲートウェイには別にRFC 1009があり、ホストとパケットを転送する装置の役割は関係しながらも異なっていた。

これは新しいプロトコル一式ではない。過去の標準を実装者が使える形にまとめ、誤りを直し、更新を反映し、仕様の空白を埋め、必要なら実装の選択肢を絞り、プロトコルの意図や既知の解決策を記録した。Bradenは、以前の要求を言い換えただけの条項も多いと記す。それでも、少なくとも一つの実装がその要求を守らなかったため、再掲する意味があった。規則を公開することと、複数の製品で使えるようにすることは別の仕事だった。

作業班は共通の基準をどこで止めるかも決めた。合意した例の一つは、ホストにDNS実装を求めることだった。一方、複数のネットワークインターフェースを持つホストの振る舞い、つまりマルチホームは未解決項目に残った。ある機能を必須にするか禁止するかで合意できないとき、RFC 1127によると、仕様は対立する見解を記したうえで任意扱いとする場合があった。合意は一部を共通化し、別の部分では選択を残した。

この境界が重要だ。ホスト要件は全機器を同じ設計にしたのでも、すべてのベンダーの準拠を保証したのでも、アーキテクチャの議論を終わらせたのでもない。ホストに何が期待されるかを探しやすくし、解決していない問題を決着済みの原則に見せずに残した。ソフトウェアとネットワークが接する地点で、相互運用のための実用的な説明を作ったことが、その歴史的な意味だった。