要約

  • RFC 1127 は、IETF Host Requirements Working Group が相互運用性をアーキテクチャの純粋さより優先し、決着した論点を明確な要件または推奨へ変えた過程を記録した。
  • 反対方向の MUST と MUST NOT が同じ強さで争われた場合、RFC 1122 と RFC 1123 は MAY または OPTIONAL を残した。別の争点は条件付きの狭い許可になった。
  • MUST が語るのはソフトウェア実装の適合性であり、導入時の設定、稼働値、相手との交換、アプリケーションの成否ではない。

標準ではなく、標準ができるまでの記録

RFC 1127 は自らの権限を最初に限定する。Informational 文書であって、プロトコルを定義せず、いかなる成熟段階の標準でもない。対象は、通信層を扱う RFC 1122 と、アプリケーションおよび支援機能を扱う RFC 1123 が作られた過程である。

だからこそ、規範表には入らない事情を書けた。合意した点、条件付きで妥協した点、判断を見送った点、別の実験に委ねた点が同じ確信度で装われていない。RFC Editor の書誌情報と IETF Datatracker の記録は文書の同一性を保ち、本文は要件に至る判断の履歴を保つ。

約二十人の中核専門家に加え、さらに約二十人が大きく貢献した。二十か月に七回の正式会合、約三メガバイトの電子メール、およそ二十版の草案があった。この量が結論の永続的な正しさを証明するわけではない。ただし、大文字の語が一人の編集者の好みではなく、既存実装と衝突する優先順位を長く調整した結果だとは分かる。

美しい設計より、まず相手と話せること

作業部会は相互運用性、拡張性、機能性、効率、アーキテクチャの純粋さという五つの目標を挙げた。最優先は相互運用性、最後は純粋さだった。設計原則を不要としたのではない。きれいなモデルが、すでにインターネット上にいる多様な機械との通信を壊すとき、どの損失を先に避けるかを決めたのである。

以前の文書にすでに書かれている規則を繰り返す条項も多く、「マニュアルを読め」と皮肉られた。それでも残ったのは、少なくとも一つの実装が別の選択をし、相互運用性、性能または堅牢性の問題を起こしていたからだ。重複した一文は、既知の故障パターンを検査可能な責任に変える。

RFC 1122 と RFC 1123 は短い一覧だけを使う危険も警告する。元のプロトコル仕様、訂正、説明、実装上の文脈まで含めて初めて契約になる。閉じた LAN で動くホストが、多様な経路に出た瞬間に失敗することはある。目標は選ばれた二台のデモではなく、未知のホスト同士の接続だった。

合意の強さが規範語の強さになった

RFC 1122 では MUST または REQUIRED は絶対的要件、SHOULD または RECOMMENDED は影響を理解し慎重に比較したときだけ外せる推奨、MAY または OPTIONAL は実装してもしなくてもよい機能である。

適合にも二段階がある。実装対象プロトコルの MUST を一つでも欠けば非適合。すべての MUST と SHOULD を満たせば無条件適合、MUST はすべて満たすが一部の SHOULD を満たさなければ条件付き適合である。これはコードと文書の関係を述べる分類で、設置済みホストや通信相手の組を保証しない。

RFC 1127 は、その語が論争からどう生まれたかを示す。決着した論点には強い要件や推奨が置かれた。未決の論点では MUST または SHOULD を求める側と、MUST NOT または SHOULD NOT を求める側が同じほど強かった。部会は見解を記し、ない合意を演出せず、MAY または OPTIONAL とした。選択肢が同じ安全性を持つという意味ではなく、共同体が一律に命じられる境界を示している。

別の論点では、限定付き許可が使われた。ホストによる転送、trailer encapsulation、遅延 ACK、TCP keep-alive、UDP checksum の省略、いくつかの Telnet 動作は、全面的に許可または禁止されたのではない。条件、安全な初期値、切り替え手段によって影響を囲い込んだ。

設定できることと、設定されていることは違う

RFC 1127 の重要な範囲宣言は、作業がソフトウェア実装を対象とし、ソフトウェアの設定や利用方法を対象にしなかったという一文である。管理上の判断は、ローカルな権限に属する限り除外された。

RFC 1122 は理由を具体化する。完全に自己設定するプロトコル一式は、当時まだ遠い理想だった。最良値はホスト規模、通信量、周辺トポロジー、管理要件に左右される。最適値が未解決の場合も、自動調整アルゴリズムが存在しない場合もあった。

さらに、正しいシステムが誤った古い相手と通信するため、意図的に「誤設定」されることさえあった。ソースのない旧バイナリとの互換性は現実の負債である。それでも標準準拠の挙動をデフォルトにすべきだと文書は主張する。回避策を初期値にすれば、古い障害を次世代へ保存してしまう。

従って、設定可能という要件が証明するのは能力だけだ。供給者は上書き手段と影響を文書化し、標準はデフォルトを選べる。しかし現場が実際に上書きしたか、14時03分にどの値がメモリにあったか、どの相手が例外を必要としたかは、適合宣言からは読めない。

未解決を曖昧な MUST で覆わなかった

RFC 1127 は、ホスト初期化、dead gateway の検出、gateway と MTU の発見、TTL の選択、再構成タイマー、性能アルゴリズム同士の相互作用などを将来作業として挙げる。十分な手法が文書化されていないもの、過剰なトラフィックを生んだもの、コードが未試験のもの、ネットワーク側の普及を待つものがあった。

権威的に聞こえる一文で穴を隠すこともできた。しかし部会は知識の限界を記し、後続の実験や作業部会に渡した。紙の上では不完全に見えても、運用契約としては誠実になった。

RFC 1123 は、仕様の変化に合わせてプロトコルソフトウェアを保守しなければならないとも警告する。適合結果には版と時点があり、製品名に永久に宿る属性ではない。

文書の後から証拠の階段が始まる

後の RFC 2119 は大文字の用語をインターネット仕様一般へ広げ、RFC Editor の情報ページはその BCP としての履歴を示す。共通語彙になっても、文書が設定を実行するわけではない。

実在するホストを調べるなら、適用仕様とプロトコル集合、コードとビルドを特定する。次に公式デフォルト、出荷時値、導入時上書き、稼働値、変更した権限・時刻・理由を残す。相手の能力、広告、交渉、実際の交換を観察し、最後にアプリケーション結果を確認する。

「RFC 1122 適合」は有用な証拠になり得る。それだけでは意図されたソフトウェア特性の説明にとどまる。Host Requirements はその説明を強くし、RFC 1127 は説明が届かない場所を見えるようにした。

出典