主要領域

基盤

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

インターネット史

`+xml` は入口を示したが、意味までは運ばなかった：RFC 3023

末尾の `+xml` を見れば、汎用 XML parser を試せる。しかし、その文書が何を命じ、誰に権限があり、どの結果を残したかは、四文字からは読めない。共通構文を発見することと、固有の意味を承認することは別の判断だった。

2026年9月30日

インターネット史

RFC 2446が分けた「提案」と「決定」――iTIPに見る予定調整の権限境界

電子カレンダーで「会議を月曜から火曜へ変えたい」と送信することと、実際に共有予定が火曜へ変更されることは同じではない。RFC 2446 が1998年に定義した iCalendar Transport-Independent Interoperability Protocol（iTIP）の歴史的な重要性は、予定データの交換形式だけでなく、誰が何を提案し、誰が master entry を変更し、どのメッセージがその変更を伝えるのかを別々の状態遷移として扱った点にある。COUNTER、REQUEST、REPLY、SEQUENCE…

2026年9月30日

インターネット史

「ネットワークアドレス」がhostになれる狭い条件：RFC 3021

host 部がすべて0の値は通常、subnet そのものを表した。RFC 3021はその値を無条件に解放したのではない。二つの endpoint しか存在しない link でだけ、隣の router として扱う例外を定めた。

2026年9月30日

インターネット史

エラーは1件、失われたフレームは複数だった：RFC 3020の「up」を読む

RFC 3020の Multilink Frame Relay MIB では、bundle が up になる条件と、フレームが正しく届いたことは別の問題だった。再順序化エラーの1カウントは複数の欠落を含み得る。まして論理 interface の緑表示は、選ばれた activation policy を通過したことしか証明しない。

2026年9月30日

インターネット史

「メンバーあり」の行は、管理側が作った行かもしれない：RFC 3019

RFC 3019は IPv6 multicast の listener 状態を SNMP から読める形にした。同時に、cache 行の作成と削除、local membership の設定、MLD の有効化や timer 調整も可能にした。表は agent の現在地を示すが、remote listener や受信結果の独立証明ではなかった。

2026年9月30日