主要領域
基盤
主要領域 の観点では、「基盤」の調査・分析は、記事を主要な領域ごとに整理し、インターネット基盤、運営・政策、接続市場、デジタル資本といった関心分野を追いやすくします。このページでは、関連記事、公開証拠、機関、企業、人物、地域的な影響、運用上の依存関係、市場の文脈をまとめ、別々のカテゴリページに散らばりがちな情報を一覧で確認できます。また、対象領域の説明、関与しうる主体の類型、市場・制度の文脈、シグナルを比較する際に参照すべき資料も示します。運用者、アナリスト、制度・政策の関係者は、同じ領域がイベント、プロフィール、市場の変化、公開証拠、地域依存、長期的なインフラ判断に、時間を追ってどのように現れるかを確認できます。

インターネット史
ハイフンを消せば同じ番号になった。それでも同じファイルとは限らない:RFC 3187
`URN:ISBN:0-395-36341-1` からハイフンを除き、末尾の x を大文字へそろえる。それで比較できるのは番号の表記であって、取得したファイルの同一性ではない。RFC 3187 は、lexical equivalence の短い規則の周囲に、版・所在・誤割当という広い現実を残した。

インターネット史
物理リンクは上がっていた。遠端が知ったのは Echo の期限切れだった:RFC 3186
近端の光回線が切れても、遠端のランプは消えない。RFC 3186 の MAPOS/PPP トンネルでは、光パスが網の端で終端されるためだ。遠端が異常を知るのは PPP Echo が戻らなくなった後だった。この時間差に、透明なリンクと実際の経路の違いが表れている。

インターネット史
MSG1 の CEK から MSG2 の権限が生まれた:RFC 3185
MSG2 の鍵を理解するには、MSG2 の受信者欄だけを見ても足りない。一本前の MSG1 に戻り、誰がその CEK を受け取り、保存し、次の KEK を導出できたかをたどる必要がある。RFC 3185 は、暗号化されたオブジェクトの権限が過去の鍵から継承される仕組みを規定した。

インターネット史
その S/MIME 層は、誰の代わりに語ったのか:RFC 3183
署名された層の内側に暗号化された層があり、その内側に別の署名がある。境界装置が一枚を検証し、一枚を外し、新しい署名を加えたとき、最後の受信者に向かって語っているのは誰なのか。RFC 3183 は、S/MIME の入れ子を単なる包装ではなく、権限と保管の履歴として読ませる文書だった。

インターネット史
名前はRSVPに入った。それでも権限は意味を決めなければならなかった:RFC 3182
ポリシー・ロケータ、資格情報、ポリシー判断、実行は、同じ「身元確認」の別名ではない。RFC 3182は、その四つを RSVP の経路上で受け渡す仕組みを示した。ロケータは規則の所在を指し、チケットや証明書は主体の検証材料を与え、PDP が判断し、PEP がローカルに実行する。マルチキャストでは、どのアプリケーションの身元情報が残るかまで選択の対象だった。名前が運ばれたことと、資源を使う権限が成立したことの間には、消してはならない履歴がある。

インターネット史
新しいフローは受入れを勝ち取った。防御優先度は次の到着にも耐えねばならなかった:RFC 3181
資源が全員分ないとき、早く来たことだけでは席を守れない。RFC 3181 は、後から来たフローが既存の予約を退かせる仕組みを定義した。ただし、その勝利を永続的な権利にはしなかった。入るときの優先度と、入った後に次の到着から席を守る優先度は別だった。ポリシー生成、予約の統合、局所的な執行、パケット、アプリケーション結果も、それぞれ別の証拠面に残った。

インターネット史
ランタイムは231と応答した。それでもスクリプトには終了の受領証が必要だった:RFC 3179
「実行中」は、完了の言い換えではない。RFC 3179 はその当たり前をメッセージの順序として残した。231 は制御要求がランタイム状態へ到達したことを示し、中間結果、エラー、終了は別の応答で届いた。さらに結果の解釈と管理対象の変化はプロトコルの外に残る。自動化の証拠は、一つの成功表示ではなく、責任の異なる受領証の列だった。

インターネット史
コアはフローを忘れた。それでもエッジは予約を証明しなければならなかった:RFC 3175
RFC 3175 は、すべての予約をコアの全ルーターに記憶させる設計から一歩退いた。多数の RSVP フローを一つの大きな予約へまとめても、個々の約束まで一つに溶けるわけではない。中央の状態を減らすほど、両端の証拠は鮮明でなければならなかった。

インターネット史
重要なゾーンでも、ルートサーバーの恒久業務ではなかった:RFC 3172
`.arpa` は壊れてよい場所ではなかった。RFC 3172 はルートサーバー級の運用要件を課した一方、ルート用の機械が兼務する状態は変わると記した。守る対象は名前と解決機能であり、2001年のサーバー配置そのものではない。

インターネット史
レジストリはマルチキャストアドレスを割り当てた。それでも使用実態を確かめる必要があった:RFC 3171
台帳の数字が動かないことと、依存関係が生き続けていることは同じではない。RFC 3171 は、世界的に調整される IPv4 マルチキャストアドレスを、理由の保存、定期的な見直し、必要なら回収を伴う例外として扱った。登録は意味を揃えるが、稼働を証明しない。

インターネット史
インデックスはポリシー行を指した。しかし意味までは語らなかった:RFC 3159
設定画面に二つの行がある。条件も動作も参照先も同じで、違うのは番号だけだ。その二行は別のポリシーなのか、同じ内容の複製なのか。RFC 3159の答えは慎重だった。`InstanceId`は一つの行を特定するが、その番号自体にはポリシー上の意味を持たせない。座標と意味を分けることが、実行結果まで追跡するための出発点だった。

インターネット史
トランスレータがパケットを変えたなら、報告も変えなければならない:RFC 3158
RTP トランスレータは、送信元の SSRC を保ったまま符号化やパケット数、シーケンス番号、タイムスタンプ周波数を変えられる。映像が再生できても、RTCP が変換前のバイト数や損失を語り続けてよいわけではない。RFC 3158は、メディアの変換と、そのメディアについての証拠を同じ履歴にそろえる責任を試験項目にした。

インターネット史
サーバーは平文を知らなくても、可用性を支配できた:RFC 3157
鍵を読めない保管者も、その鍵を返さないことはできる。2001年8月の RFC 3157は、暗号資格情報を複数の端末へ移すという課題を、この単純だが見落とされやすい非対称性から捉えた。秘密鍵を暗号化したまま預ければ漏えい面は狭くなる。しかし、一覧、取得、置換、削除を握るサーバーの運用上の権力は消えない。秘密の保護、対象の可用性、同一性の継続、最終的な業務結果は、別々に立証されなければならなかった。

インターネット史
送信側には損失が見えても、その原因は見えなかった:RFC 3155
TCP の輻輳ウィンドウが縮んだという記録は、経路上で何が起きたかを確定する鑑定書ではない。2001年8月の RFC 3155は、まさにその空白を扱った。ACK が進まないとき、混雑したキュー、訂正されなかった伝送誤り、並べ替え、ACK 経路の損失は似た痕跡を残し得る。共有ネットワークを守るには保守的に反応する必要があった。しかし、速く回復することと、原因を知ることは別の仕事だった。

インターネット史
リレーがヘッダーを足し、メッセージの末尾が失われることがある:RFC 3164
旧 BSD syslog 形式では、リレーが時刻とホスト名を補えば、裸のメッセージは読みやすくなる。しかし RFC 3164はパケット全体を1,024バイト以下に制限していた。補ったヘッダーが、イベント本文の末尾に必要な容量を使うことがある。

インターネット史
受信側が多重化を受け入れても、送信側には使わない選択が残った:RFC 3153
制御プロトコルが成功すると、機能まで動いたように見えやすい。RFC 3153は、その近道を許さなかった。受信側が PPP 多重化フレームを読めると申し出たあとも、送信側は実際に束ねるパケットを選べたし、一つも束ねないこともできた。2001年に定義されたのは、最適化の結果ではなく、最適化を安全に試せる互換性の境界だった。

インターネット史
サーバー側にも必要だった三つ目の乱数:RFC 3163
RFC 3163の相互認証モードにある三つ目の乱数は、飾りではない。クライアントが自分の乱数を選ぶ時点で、サーバーが最初に送ったチャレンジをすでに知っている。その順序の非対称性に対処するための値だった。ただし、設計上の対処も、仕様が与える保証も限定的である。

インターネット史
新しい逆引きツリーは、古いツリーが消える前に存在していた:RFC 3152
移行には、正しい名前が決まる瞬間と、最後の古い問い合わせが消える瞬間がある。両者は同時ではない。RFC 3152は IPv6 逆引きの根を`IP6.ARPA`に定め、アドレス配分に沿った委任を求めた。一方、`IP6.INT`は新規実装には不適切とされ、秩序ある段階的廃止に委ねられた。短い文書の中に、標準、委任、ゾーン、キャッシュ、アプリケーションが別々に動くインターネットの現実がある。

インターネット史
IPv6の設定は認証を待つ:RFC 3162
アクセスサーバーは、ホストがどのインターネットプロトコルを使うか分かる前に、セッションを許可しなければならなかった。RFC 3162は一つの RADIUS 交換に両方の可能性を載せ、どの属性を適用するかはネットワークの端に委ねた。

インターネット史
古い名前はURNになった。それでも自分では解決しなかった:RFC 3151
XML は、一台の機械より長く使える一方、URI 専用の欄にはそのまま入らない公開識別子を受け継いだ。RFC 3151はそれを`urn:publicid:`へ決定的に転写した。正規化後の名前は比較できるようになったが、所有者の登録、カタログの選択、対象バイトの検証、パーサーの結果まで URN が保証したわけではない。
