主要領域
基盤
主要領域 の観点では、「基盤」の調査・分析は、記事を主要な領域ごとに整理し、インターネット基盤、運営・政策、接続市場、デジタル資本といった関心分野を追いやすくします。このページでは、関連記事、公開証拠、機関、企業、人物、地域的な影響、運用上の依存関係、市場の文脈をまとめ、別々のカテゴリページに散らばりがちな情報を一覧で確認できます。また、対象領域の説明、関与しうる主体の類型、市場・制度の文脈、シグナルを比較する際に参照すべき資料も示します。運用者、アナリスト、制度・政策の関係者は、同じ領域がイベント、プロフィール、市場の変化、公開証拠、地域依存、長期的なインフラ判断に、時間を追ってどのように現れるかを確認できます。
インターネット史
RFCは37と書いた。稼働中の機器は38を使っていた――RFC 3115
2001年、Mobile IP の同じ拡張に、RFC と IANA レジストリが別々の番号を与えた。二か月後の RFC 3115は、実装がすでに採用していた IANA 側の値に規範を合わせた。
インターネット史
パスワードは一致した。それでも利用者はまだ認証されていなかった――RFC 3112
RFC 3112は、LDAP に保存された password 由来値との比較を可能にした。同時に、その真という答えの権限を限定した。match が成功しても、directory association の認証はまだ終わっていない。
インターネット史
二つの層が「forward」と呼び、逆方向を指した――RFC 3108
RFC 3108が示したのは、値が欠ける事故ではない。call control と ATM bearer signaling が同じ forward という語を使いながら、別々の端点を原点にしたため、正しい値をそのままコピーすることが誤りになった。
インターネット史
ゲートウェイがアドレスを貸し、ローカリティがプロトコルになった――RFC 3102
Realm Specific IP は、アドレス共有を境界装置の見えない書き換えに任せず、private realm の host 自身に public parameter を使わせた。だが、address が host へ移っても、pool、lease、policy、return path の支配は gateway に残った。
インターネット史
DHCP認証は信頼ドメインの内側にとどまった――RFC 3118
RFC 3118は DHCP に認証を加えたが、ネットワーク全体に通用する ID 基盤を作ったわけではない。遅延認証の交換は、同じ管理ドメイン内のクライアントとサーバーが、事前に共有鍵を別経路で受け取れることを前提とし、未認証の応答を受け入れるかどうかはローカルポリシーに委ねた。
インターネット史
同意がチェックボックスになる前――RFC 3098
RFC 3098は広告主に礼儀を求めただけではない。未購読を初期状態にし、データ用途を説明し、出所を伴う確認を送り、退出を可能にし、商用リストの維持費を利益を求める側へ残すという運用設計を示した。
インターネット史
ROHC は戻りチャネルなしで始まった――RFC 3095
確認応答を信頼する前に、ROHC は返事が戻らないリンクでも動かなければならなかった。RFC 3095 は全コンテキストを単方向モードから開始させ、双方向モードへの移行要求を伸長側に持たせた。
インターネット史
TALIは相手がバージョン2だと決めつけられなかった――RFC 3094
TALI 2.0のゲートウェイが新しい管理操作を送るには、接続先が何を理解できるかを先に知る必要があった。RFC 3094はこれをプロトコル上の規則にする一方、IETF による技術審査を受けていないベンダー提案だと、異例なほど明確に記して公開された。
インターネット史
Foo は説明より先に RFC へ入っていた――RFC 3092
1971年の RFC 269は、`FOO`を`BAR`へ改名する例を何の注釈もなく置いた。2001年の RFC 3092が数えるころには、同じ語彙は RFC 全体の約7％に広がっていた。慣行は、説明する文書を待たずに定着していた。
インターネット史
RFC 3091のπマルチキャスト先は、IPv4アドレスではなかった
RFC 3091は、ストリーム、番号指定の UDP 応答、マルチキャストを使ってπを組み立てる構想を描いた。しかし、指定されたマルチキャストグループは有効な IPv4 アドレスとして表せず、文書中の TCP・UDP ポートも、運ぶ側のフィールドに収まらなかった。
インターネット史
ファイアウォールはHTTPを通した。中のパケットを承認したわけではない――RFC 3093
RFC 3093は、完全な IP データグラムを HTTP メッセージに入れ、Web 用の通路を越え、内側のホストで再びプロトコルスタックへ注入する方式を描いた。2001年4月1日公開の喜劇的な設計は、外側の封筒への許可が中身への許可ではないことを鮮明にした。
インターネット史
同じゾーンが、ここでは安全で別の場所では非安全だった――RFC 3090
2001年、「この DNS ゾーンは安全か」という問いには観測者が抜けていた。どのリゾルバーが、どの信頼の起点から、どの経路を検証するのか。RFC 3090は、署名済みゾーンが一部のリゾルバーにだけローカルな安全の島となる現実を分類した。
インターネット史
ルートサービスが返したのは紹介先であり、ディレクトリの答えではない――RFC 3088
分散ディレクトリでは、最初のサーバーが次の接続先を知っていても、探しているレコードを持っているとは限らない。2001年の OpenLDAP 実験は、その違いを具体化した。DNS から LDAP サーバーの候補を見つけて紹介するが、検索結果そのものは紹介先に残る。
インターネット史
URIは留守番電話のメニューを選んだ。それでも発信者を認証してはいない――RFC 3087
2001年、SIP の呼は留守番電話へ届いても、従来の電話網が最初の案内を選ぶために使った確かな手掛かりまで運ぶとは限らなかった。RFC 3087は現在の宛先をサービスへの指示に変えた。経路は文脈を伝えられたが、宛先が身元証明になったわけではない。
インターネット史
ポリシーサーバーは規則を送った。再接続は装置に残った状態を照合しなければならなかった――RFC 3084
RFC 3084 は、ポリシー配布を単なるファイル転送ではなく、応答と巻き戻しを備えた分散トランザクションとして組み立てた。ところが回線が切れると、サーバーと装置はそれぞれ状態を保持する。再接続が戻すのは通信であって、両者の記憶が同じだという証明ではない。
インターネット史
改訂番号はNewsItemを並べられても、読者には届けない――RFC 3085
同じニュース項目が複数の場所に保存されることはある。RFC 3085は NewsML の NewsItem に一つの URN と項目ごとの改訂番号を与えた。一方、ニュース本文の更新と管理メタデータだけの差し替えは別の印で示し、実際に内容を探し出すサービスは提供者に委ねていた。
インターネット史
ケーブルは通信を暗号化した。それでも管理面はプライバシーを止められた――RFC 3083
RFC 3083は DOCSIS Baseline Privacy を SNMP から観測、調整、リセットできる仕組みにした。診断には役立つが、別の安全境界も生まれた。鍵の状態を見るインターフェースが、認可を再開し、時間を変え、マルチキャスト範囲を決められたからだ。
インターネット史
TCPは確実だった。それでも一つのチャネルが他を飢えさせた――RFC 3081
RFC 3081は、一つの BEEP セッションを一つの TCP 接続へ載せたうえで、TCP が解けない問題を正面から扱った。接続全体の信頼性は、その内部にある全アプリケーション・チャネルの進行を保証しない。そこで、チャネル別の信用枠、制御フレームの優先、最低限の巡回サービスが必要になった。
インターネット史
Directory Agentが消えても通知は続く。新サービスは見落とされうる――RFC 3082
RFC 3082は、サービス変化を確かめるための定期的な問い合わせをイベント通知に置き換えようとした。その復旧手順が示すのは、より細かな非対称性だ。すでに購読を知らされたサービスエージェントは通知を続けられるが、新しく参加したエージェントには、誰かが待っていることが伝わらない場合がある。
インターネット史
一つの接続は、一つの会話ではなかった――RFC 3080
BEEP では、接続が生きていてもアプリケーションの会話が成立したとは限らない。RFC 3080のチャネル0は、能力を知らせ、別のチャネルを開閉するための細い管理面だった。選ばれたプロファイルが初めてチャネルに意味を与える。回線、セッション、会話、処理結果は別々の事実だった。