主要領域
基盤
主要領域 の観点では、「基盤」の調査・分析は、記事を主要な領域ごとに整理し、インターネット基盤、運営・政策、接続市場、デジタル資本といった関心分野を追いやすくします。このページでは、関連記事、公開証拠、機関、企業、人物、地域的な影響、運用上の依存関係、市場の文脈をまとめ、別々のカテゴリページに散らばりがちな情報を一覧で確認できます。また、対象領域の説明、関与しうる主体の類型、市場・制度の文脈、シグナルを比較する際に参照すべき資料も示します。運用者、アナリスト、制度・政策の関係者は、同じ領域がイベント、プロフィール、市場の変化、公開証拠、地域依存、長期的なインフラ判断に、時間を追ってどのように現れるかを確認できます。
インターネット史
規則は記述できても、結果は装置側に残った――RFC 3060
RFC 3060は、グループ、ルール、条件、アクションを記述する共通語彙をポリシー管理に与えた。しかし、すべてのルーターに同じ解釈器を与えたわけではない。ルールの適用条件やアクションの順序を必須・推奨として表せても、属性を判断結果に変えるアルゴリズムは各実装に残された。その境界は、規格本文が自ら説明している。
インターネット史
呼制御が IP へ移っても、D チャネルはその場に残った：RFC 3057
RFC 3057は、ISDN 回線そのものをインターネットへ移したわけではない。移したのは境界の向こう側の処理だ。シグナリングゲートウェイは引き続き Q.921 を終端し、IUA が SCTP を使って上位層のシグナリング・プリミティブを呼制御プロセスへ運ぶ。アプリケーションサーバープロセスの障害時にはシグナリングを切り替えられるが、設定途中のすべての呼が維持されるとは約束していない。
インターネット史
カウンターは通話成功を告げた。それでも人が聞いたかは分からない――RFC 3055
2001年、PINT ワーキンググループは、インターネットから起動される電話サービスを数えるための共通面を定めた。RFC 3055は受信、成功、切断をサービス、期間、クライアント、利用者、ゲートウェイ別に見せた。しかし、その精密な表にも届かない場所があった。電話の向こうの人、印字されたファクス、実際に鳴ったスピーカーである。
インターネット史
14 kHzへ広げても、16 kHzの相互運用経路を残したRFC 5577
RFC 5577は G.722.1 の音声プロファイルを広げ、より高いサンプリングクロックを加えた。移行設計で目を引くのは、むしろ控えめな一文だ。旧世代の端末が相手に残るなら、16 kHz の設定も提示し続ける。
インターネット史
電話は部品に名前を付けた。それでもコントローラーは中身を確かめた――RFC 3054
RFC 3054は、インターネット電話の表示、キー、受話器、スピーカー、メディアストリームに共通の語彙を与えた。IPPhone プロファイルにより、遠隔のコントローラーは無秩序なオブジェクト群から用途を推測せず、既知のモデルから始められた。だが、プロファイル宣言、監査結果、制御命令、RTP パケット、実際に聞こえた音は別々の事実だった。
インターネット史
root DSEは製造元を示せても、機能を申告する場所ではない――RFC 3045
LDAP サーバーは、ソフトウェアの開発元と自分が報告するバージョンをクライアントに伝えられる。その情報は運用者の確認や限定的な不具合回避には役立つが、機能一覧ではない。RFC 3045は境界を明示した。製品名は異常の背景を示す手掛かりにはなっても、サーバーが何を実行できるかの証明にはならない。
インターネット史
ISSNは残り、URLは動く――RFC 3044のリゾルバーに置かれた監視役
2001年、ISSN 国際センターは、既存の雑誌番号を URN として扱う方法を示した。難しかったのは番号の表記ではない。その番号から、移り変わる雑誌のウェブ上の住所までをどう保つかだ。RFC 3044は、識別子は残っても URL は残るとは限らないと明記し、定期的に見張る仕組みを置いた。
インターネット史
ブローカーがトンネルを発注しても、運んだのは別の機械だった――RFC 3053
RFC 3053 は、初期 IPv6 の面倒な接続作業をサービスの形にした。登録し、IPv4 終端を伝え、設定を受け取る。しかし、その利便性の裏には明確な境界があった。Tunnel Broker は許可し、割り当て、命令する。Tunnel Server はトンネルを終端する。利用者は自分側を設定し、ネットワークは実際にパケットを運ばなければならない。
インターネット史
世界で通用する名前と単一の権威あるリゾルバー――RFC 3043が約束したこと、その限界
2001年1月、Network Solutions は個人や組織に長く使えるインターネット上の名前を提案した。RFC 3043では、その参照をアプリケーション間で持ち運べる一方、登録テンプレート上の権威ある解釈は同社のリゾルバーに委ねられていた。この違いは今も重要だ。名前が残ることと、それを解決する権限まで移せることは同じではない。
インターネット史
標準は LDP を推奨した。それでも稼働中とは証明しなかった：RFC 3037
RFC 3037 が LDP の実装を推奨した対象は、宛先ルーティングが選ぶ通常経路で MPLS 転送を行う装置だった。推奨は用途の判断であり、実装済み台数でも稼働表示でもない。コード、設定、発見、TCP、合意、ラベル、転送表、パケットはそれぞれ別の証拠である。
インターネット史
重複 ACK が二つ届いても、広げるのは送信であってウィンドウではない――RFC 3042
輻輳ウィンドウが三セグメントの TCP 接続で、一つのセグメントが失われる。後続データが返せる重複 ACK は最大二つで、Fast Retransmit の既存しきい値には一つ足りない。2001 年の RFC 3042 は、この間を埋めるため、最初の二つの ACK に対して新しいデータを送る仕組みを提案した。ただし輻輳ウィンドウは増やさない。
インターネット史
ATMラベルはホップごとに変わる。LDPには両端で共有するVCIDが必要だった
ATM 回線がセルを運び続けていても、次のスイッチで VPI/VCI は別のローカル値に置き換わり得る。RFC 3038はそのホップ単位のラベルと、隣接する LDP ノードが同じ仮想回線を指すための共通 ID を分けた。
インターネット史
コアは TTL を減らせなかった――入口で隠れたホップを先払いした RFC 3034
Frame Relay スイッチは DLCI を高速に置き換えられても、各パケットの TTL を減らす回路を通常は備えていなかった。RFC 3034 はそのホップを無かったことにせず、MPLS の計算を区間境界へ移した。制御面が長さを伝え、入口が差し引く。しかし、その数値だけでは実際の通過経路は証明できない。
インターネット史
LDPは全長プレフィックスを残し、Host Address FECを外した
標準の改訂は、表現の一つを削っても、そこで扱っていた能力まで捨てるとは限らない。RFC 3036では全長アドレスのプレフィックスと Host Address FEC が別の意味を持っていた。2007年の改訂は、実装で使われていないという理由で後者を削り、全長プレフィックスを残した。
インターネット史
識別子はセッションを指したが、移したわけではない：RFC 3033
ATM の呼制御メッセージに正しい IPv4 セッション識別子が入っていても、パケットはまだ既定の仮想回線を通っているかもしれない。RFC 3033 は、何を対象にしているかを正確に伝える方法を定めた一方、回線確立、IP 層の移行、QoS の成立を同じ事実にはしなかった。
インターネット史
サーバーは機能を示した。認証後、その答えは変わった：RFC 2449
POP3 クライアントは接続者を知る前に、サーバーに何ができるかを尋ねる。その返答は意図的に慎重でよい。利用者を認証した後なら、同じサーバーも、より具体的な答えを返せる。さらに完全性保護層が加われば、先の一覧がもう有効とは限らない。RFC 2449 は機能発見を機械可読にしたが、一つの一覧をあらゆる状態に通用するサーバーの説明とはしなかった。
インターネット史
署名された判定が「無効」でも矛盾しない：RFC 3029
信頼されたサーバーが証明書を発行し、そこに「無効」と記す。署名は対象を有効にする魔法ではない。誰が、どの要求と時刻と方針に基づいて、その判定を出したかを固定する。RFC 3029 は、サービスの成功と検証結果の成功を意図的に切り分けた。
インターネット史
ネットワークは全パケットを等しく扱った。コーデックはそうではない：RFC 2448
圧縮映像では、数バイトを失ったからといって損害も小さいとは限らない。画像データの一部なら局所的な乱れで済むかもしれないが、その先をどう復号するかを示す短い情報が欠けると、より広く崩れることがある。1998年の RFC 2448は、その違いを送信側の設計に持ち込んだ。コーデック上の役割で情報を分け、失われたときの影響が大きい部分に、より確かな経路を与える。
インターネット史
何もしない分岐を救済した設計：RFC 3028
フィルターのどの条件にも当てはまらないメールを、どう扱うべきか。Sieve はその空白を放置せず、通常の受信箱へ保存する「暗黙の保存」に変えた。RFC 3028 が示したのは、規則の評価と配送結果を分ける設計である。命令が選ばれても、保存や転送が完了したとは限らない。
インターネット史
会議はメールのヘッダーにはなかった――RFC 2447 の MIME 境界
RFC 2447 は、iTIP の予定情報を電子メールで運ぶための薄い接続層を定めた。MIME の `text/calendar` 部分に機械が読める予定オブジェクトを置き、外側の `method` をオブジェクト内の `METHOD` と一致させる。対応する予定表を持たないメールソフト向けには、人が読める説明も同じメッセージに添えられた。