IETF

起動要求がサブネットの境界を越えると、中継エージェントはクライアントとサーバーのやり取りに加わる。RFC 1542が定めたのは、目立たないが運用上重要な線引きだった。複数サーバーへの振り分けはできる。ただし、同じクライアントからの要求は、毎回同じ宛先または同じ宛先群へ送る。

IPv6の基礎となった案は、最初の形のまま選ばれたわけではない。審査で問われたのは、IPv4からの移行をどう成立させるか、そして64ビットのアドレスで将来の経路階層を支えられるかだった。SIPPはその指摘を受け、アドレスを8バイトから固定16バイトへ広げ、移行方式も整理した。

1998年、RFC 1490の後継文書は二つの異なる結果を記録した。Frame Relayのマルチプロトコル・カプセル化は広く実装されていた一方、RFC 1490の断片化アルゴリズムには相互運用できる実装がなかった。同じ標準の中でも、機能ごとに実装の行方は分かれうる。

Internet Relay Chat（IRC）の最初の正式な記述は、1993年5月に「Experimental」として公表された。だが、その時点でサービスはすでに数年動いていた。文書が描いたのは、拡大の最中にあり、規模の限界も見え始めたサーバーネットワークである。

RFC 1094は、NFSv2がローカルOSのすべての約束をネットワークへ運ぶわけではないことを示している。あるOSでは、ディレクトリから名前を削除しても、すでに開いているプロセスはファイルを使い続けられる。ステートレスなサーバーがその状態を知らないため、RFCはクライアント側の改名を回避策として挙げた。

署名付きメッセージを一度受け取ったサーバーは、同じものを二度受け入れないとどう確認するのか。RFC 1507のDASSは、応答の往復を増やさないため時刻を選んだ。その代わり、認証の成否は同期時計と、直近のメッセージを覚えておくサーバーの状態に結び付いた。

Identが尋ねたのは、誰がオンラインかという一覧ではない。特定のTCP接続にローカルシステムが結び付けた利用者識別子を、その接続の一端であるホストに答えさせる仕組みだった。要求に含める二つのポートは、問い合わせ先のホストから見た順序で読む。その小さな入れ替わりが、返答の限界も示している。

1993年2月、Marc Andreessenは、画像を文書の途中に表示しながら、その取得先とクリック後の行き先を別々に指定するHTML要素を提案した。`SRC`と`HREF`の区別は小さな構文上の選択に見える。しかし、それによって「画像を表示すること」と「別の場所へ移動すること」は別の操作として記述できた。

IETFは、習得に何年もかかることのある技術プロセスへ新しい参加者を迎えるため、自分のペースで学べる講座を調達している。受講者を評価せず、個人単位で追跡しないという方針は、プライバシーを守る明確な境界になる。では、学習を監視に変えずに、講座が役立っていることをどう示せるのか。そこにガバナンス上の課題が残る。

ディスクを持たないワークステーションがOSを読み込むには、まずROM上の小さなプログラムがネットワークに接続し、コードを要求しなければならない。1984年のRFC 906は、メーカーごとに異なっていた起動方式に対し、IP上のTFTPを共通経路として提案した。とりわけ示唆的なのは、複数のサーバーが応答し得るときの規則である。最初に届いた有効なDATAパケットが、その転送を続けるサーバーを決める。

技術文書は承認された後、公開までの間にも編集されることがある。RFC 4714が捉えたのは、その編集が「文章の手入れ」で済むとは限らない瞬間だ。合意済みの一文を直す以上、変更の記録と承認が要る。

2011年、RFC 6410はIETFの標準成熟度からDraft Standardを取り除いた。ただし移行条項は、すでにその分類にあった文書を自動で移さず、明示的な措置があるまで旧分類を残した。

RFC 2860 の構造は、終了条項から見ると輪郭がはっきりする。IETF と ICANN は合意による変更・終了を認め、どちらか一方からの終了には少なくとも六か月前の通知を求めた。これは永続する統治憲章ではなく、対象を限定した技術業務の取り決めである。その射程は、割当基準、異議申立て、そして明示的に除外された政策問題を読むことで見えてくる。

1984年10月、最初のトップレベルドメイン一覧は、そのまま参入条件の一覧でもあった。ARPAは一時的な名前とされ、ほかの名前は組織の分類に結び付けられ、新しい枝を加えるには認可する機関が必要だった。

Interop ’90 の会場向けに作られた小さな手引きは、急速に変わるネットワークの語彙を読み解く助けになった。一方、短い定義だけで異なるベンダーのシステムが実際に連携できると証明できるかのような姿勢は取らなかった。

受信側に見えるのは、IPパケットに記された送信元アドレスであり、実際の送信者とは限らない。1998年のRFC 2267は、攻撃を受けたホストから、そのトラフィックに最も近いプロバイダー境界へ確認を移した。顧客ネットワークから入るパケットの送信元プレフィックスは、その回線で正当に使えるものか。2000年のBCP 38はこの提案をベストカレントプラクティスに位置づけたが、プレフィックスの一致はネットワーク境界を示すだけで、端末や人を認証するものではない。

2001年、ベルゲンのLinuxユーザーグループは、鳩でIPデータグラムを運ぶ10年前の仕様を試した。記録に残った応答は4つ。ただし紙を外してスキャンし、OCRを人が確認・修正してから、ようやくホストが受け取った。この資料が示すのは一つの経路であり、普及したネットワークではない。

互換性を前提にできるようになる前に、異なる実装どうしが実際に通じることを確かめる必要があった。RFC 1025が記録したのは、初期インターネットのそんな実地試験だ。まず一つの接続を試し、相手を増やし、ゲートウェイを通し、パケットを壊したり並べ替えたりする。一度の握手が成功しただけでは分からないことを、段階を追って見ていく。

IETFでは、Internet（INT）エリアディレクターの選考が二つ同時に進んでいる。Tommy Jensen氏の任期途中の辞任を受けた補充と、Éric Vyncke氏が続投を希望していない通常の2年任期の選考だ。締切も任期の終わりも異なる。

フレームが正常に届いたのに、その確認応答だけが戻らなければ、送信側は同じフレームを再送することがある。1991年のARCNET仕様RFC 1201は、その重複を無視しながら複数フレームを一つのIPデータグラムへ組み直す手順を定めた。

1989年9月、RFC 1118は、まだ外部と接続していない小規模IPネットワークをインターネットへ導くことを目指した。実務上の要点は、運用者や運用センター、文書化されにくい慣行を示したことだ。文書自身の但し書きは、その案内がすぐ古くなり得ることも示していた。

研究ネットワークで人を探す仕組みを、三年で形にする。1989年のRFC 1107はそうした道筋を示した一方、コミュニティが研究活動を約束した文書ではないとも明記した。ここでいう三年は実績ではなく、資金と支援を前提とする計画だった。

1977年、CRLFだけの要求で一台のホストに利用者一覧を求められた。問い方は共有されても、返答の項目と開示可否は各サイトに残った。

名前の登録先を調べることと、その名前の全メンバーへメッセージを配ることは別の仕事だ。1987年3月のNetBIOS over TCP提案は、名前サービスとグループデータグラムの中継を別々の論理機能に割り当てた。その一方で、転送がどこまで完了したかを送信者に伝える仕組みはほとんど用意しなかった。

1987年、全米科学財団（NSF）は、異なるメーカーのゲートウェイを接続する最低条件として、Ethernetとシリアル回線プロトコルを求めた。同じRFCは一方で、メーカーをまたいで単一の自律システムを構成できるオープンなIGPがまだなかったと記録している。接続口は定められても、経路の決め方までは共通化されていなかった。