主要領域
インターネット基盤
主要領域 の観点では、「インターネット基盤」の調査・分析は、記事を主要な領域ごとに整理し、インターネット基盤、運営・政策、接続市場、デジタル資本といった関心分野を追いやすくします。このページでは、関連記事、公開証拠、機関、企業、人物、地域的な影響、運用上の依存関係、市場の文脈をまとめ、別々のカテゴリページに散らばりがちな情報を一覧で確認できます。また、対象領域の説明、関与しうる主体の類型、市場・制度の文脈、シグナルを比較する際に参照すべき資料も示します。運用者、アナリスト、制度・政策の関係者は、同じ領域がイベント、プロフィール、市場の変化、公開証拠、地域依存、長期的なインフラ判断に、時間を追ってどのように現れるかを確認できます。
インターネット史
先行記事を呼び戻せなかった改訂版――Supersedesはいかに置換と消去を分けたか
Usenet で訂正版を届けることと、誤った旧版を消すことは同じ仕事ではなかった。`Supersedes` は新しい記事を通常どおり流通させながら、先行記事の取り下げを各サイトに求める。前者は新規発行、後者は認証とローカル方針に従う処理であり、結果が一致する保証はない。
インターネット史
同じ部屋へ戻らなくてよかった返信：Followup-To が読者と返信先を分けた理由
一つの Usenet 記事を複数のニュースグループで読めても、次の返信は別の場所へ向けられた。`Followup-To` は元記事を移動せず、読者を締め出しもしない。これから作る投稿の初期宛先を示し、最終判断を次の投稿者に残した。
インターネット史
閉じるだけではなかった出口――IMAP が UNSELECT を必要とした理由
メールボックスを手放して認証済み接続だけ残したい。そのために `CLOSE` を送ると、すでに `\Deleted` が付いたメッセージまで恒久的に消える。IMAP は `UNSELECT` によって、退出と削除の決裁を別の操作にした。
インターネット史
ディスクを予約できなかった日付：Expires が Usenet の有用性と保存を分けた理由
記事に正確な日付が付いていても、その日まで読めるという約束にはならない。Usenet の `Expires` は、投稿者が情報の有用性を見積もるための欄だった。ディスク容量、保存例外、実際の削除は各サーバーの管理下に残った。日付は届いても、保存権限までは届かなかった。
インターネット史
選ばれたプロトコルを、プリフェイスがもう一度確かめた
TLS ハンドシェイクが`h2`を選んでも、HTTP/2 はすぐに通常のリクエストを始めなかった。双方は接続プリフェイスを送る。選択と確認を別の証拠にしたこの構造を見ると、ALPN が万能な識別子ではなく、新しい接続に一つの文法を割り当てるための限定された約束だったことが分かる。
インターネット史
ヘッダーに収まらなかった境界線：DistributionはUsenetを絞れても、非公開にはできなかった
Usenet の記事には、ローカル、国内、組織内といった配布範囲の希望を載せられた。しかし境界そのものは運べない。実際の境界は、各サイトが認識する名前、リレー間の設定、運用者が管理するゲートウェイにあった。`Distribution`は意図を見えるようにした。その可視性を機密性の保証と読み違えた瞬間、文字列にインフラの権限を与えることになる。
インターネット史
最初の日付を消さなかった第二の日付――Injection-Dateが執筆とネットワーク投入を分けた理由
月曜日に完成した Netnews 記事が、オフライン端末に残り、金曜日になって初めてネットワークへ入ることがある。作者の日時は文章が完成した時を示す。一方、server は新しい到着か、履歴から消えた古い記事の再来かを判断したい。一つの日時に両方の責任を負わせないことが、解決の核心だった。
インターネット史
TTL から切り離された、もう一つの待ち時間
IPv4 には二つの寿命が重なっていた。一つは経路上で減る TTL、もう一つは宛先が断片を待つ時間である。最初の仕様は後者を前者から借りようとした。しかし TTL が事実上 hop 数として運用されるなら、残りの値は受信メモリを何秒保持すべきか答えない。1989 年の Host Requirements は二つの時計を分離し、そのうえで fragment zero を timeout 通知の条件にした。
インターネット史
「何か」ではなく「どこか」を示す番号――XrefがUsenetの位置をローカルにした理由
同じ Usenet 記事でも、ニュースグループが違えば別の番号を持ち、サーバーが変われば番号体系そのものが変わる。Xref はその矛盾を解消したのではない。記事の同一性と、各サーバーにおける格納位置を意識して分離した。
インターネット史
書かなかった引数が、互換性を決めた
`STOU <CRLF>` には、新しいファイルのパス名を置く欄がない。この省略は「適当な既定名を使う」という曖昧さではなく、名前を選ぶ役割をサーバーへ固定するインターフェースである。小さな文法が、クライアントとサーバーの最小共通契約を守っていた。
インターネット史
アドレスではなかったリスト――List-Id が与えた変わらない名前
投稿先や処理サーバーが移っても、議論の共同体は同じままかもしれない。List-Id はその継続性だけを安定させ、配送、操作、認証を別の権限として残した。
インターネット史
リレーが忘れるべき経路――SMTP は権限を外した後もソースルート構文を残した
古い SMTP の宛先は、最終メールボックスの前に複数のリレー名を並べられる。現在のサーバーにもその形を理解する義務があるが、列挙された順路に従う義務はない。構文が生き残り、命令としての力だけが失われたことに、互換性と権限を分けた設計判断が残っている。
インターネット史
改名ではなかった新アドレス――SMTP が転送と案内を 251 / 551 に分けた理由
古いメールボックスが移転し、二つのサーバーが同じ新アドレスを知っている。一方は `251` で受け入れて転送を引き受け、もう一方は `551` で拒否して次の試行を送信側へ返す。SMTP が伝えたかったのは移転の事実だけでなく、その後を誰が担うかだった。
インターネット史
遅れて届いた音を、あえて鳴らさない
演奏の欠落を知った受信機が、失われた音を必ず鳴らすとは限らない。RTP MIDI の回復ジャーナルが守ろうとしたのは、過去の完全な再演ではなく、通信の誤りが楽器の状態に居座らないことだった。
インターネット史
ファイルを名指せなかったオフセット――FTP 再開が「同じ対象」を前提にした理由
中断した転送には、すでに届いた部分という惜しい資産が残る。FTP はその先から送り直せたが、保存した位置は対象の版を識別しなかった。再開できることと、同じファイルを再開していることの間には、プロトコル外の確認が一つ残った。
IETF
Job Snijdersと、真実ではなくバイト列に署名するチェックリスト
ファイルが一字一句変わっていないことと、その内容が正しいことは別である。IP アドレス資源を扱えることと、会社を法的に代表できることも同じではない。Job Snijders らが設計した RPKI Signed Checklist は、この違いを消すのではなく、機械が証明できる範囲をあえて細く切り出した。
インターネット史
メッセージ自身が鋳造すべき名前――中央台帳なしで Message-ID はどう働いたか
中継サーバーが追跡フィールドを足せばバイト列は変わるが、メッセージは同じままである。作者が一文だけ直しても、新しい版として出すなら別のメッセージになる。`Message-ID` はハッシュでは捉えられないこの境界に名前を与え、中央の発番機関なしに返信と分散ニュースの状態を組み立てた。
インターネット史
接続を拒否しても、返すべき情報は残った
RADIUS の代理サーバーが付けた Proxy-State は、接続を許可する回答だけでなく、拒否する回答にも戻ってくる。認証の結論と、中継者が預かった情報を返す責任。その二つを分けた小さな属性から、共有仕様が私的な実装に踏み込まないための境界が見える。
インターネット史
予約が生きていても、内容が正しいとは限らない
RSVP の要約リフレッシュは、以前に送った状態を識別子で指し示し、同じ説明の繰り返しを減らした。ただし、記録の寿命を延ばす処理と、その記録の中身を確かめ直す処理は同じではない。効率化の歴史には、その差を埋める仕事も残されている。
インターネット史
SMTPが分けられなかった応答：LMTPはローカル配送を受信者単位にした
同じメッセージでも、ローカル配送の結果は一つとは限らない。片方のメールボックスには格納でき、もう片方は一時的に容量不足になる。SMTP の最終応答はトランザクション全体に一つだった。LMTP は、受理済み受信者の順序に沿って結果を返し、再試行の責任を既存キューに残した。