時間軸
複数年
複数年 は、時間軸 の観点から、シグナルが重要であり続けると見込まれる期間という時間軸で BTW Media の記事を整理するページです。直近の運用の変化と、四半期や年単位で進むガバナンス、投資、標準、インフラの長期的な変化を見分けるのに役立ちます。時間軸の前提を、公開された証拠、関係組織、市場環境、顧客への影響、政策圧力、インフラ計画と結び付けることで、動きが緊急なのか、戦略的なのか、裏付けとなる証拠を待つ段階なのかを判断できます。また、時間軸によってシグナルの意味がどう変わるか、影響を受ける可能性のある組織、短期的な対応が必要なインフラ判断と長期的な監視が必要な判断を解説します。
インターネット史
UUID は接続を渡った。権限は残った：RFC 927 が二度目のログインと引き換えにしたもの
パスワード入力を一度省いても、接続先の判断まで省く必要はない。RFC 927 は、認証済みユーザーを示す4オクテットを送る仕組みを定めながら、その認証を信頼するかどうかを接続先に残した。
IETF
Daniel Fett：MFAが確認したのは利用者であり、QRコードの文脈ではない
本物の認可画面で、本物の利用者が、本物の多要素認証を完了する。それでも攻撃者の端末に権限が渡り得る。壊れているのは認証要素ではなく、要求を始めた端末と利用者の判断を結ぶ部分である。
グローバルのデータセンタートレンド
Marvellの供給契約は1四半期で57.621億ドル増えた。顧客注文はなお取消可能
Marvell の最新開示で重要なのは、AI 需要という言葉ではなく、誰の約束が先に固くなったかである。ファウンドリーと組立・検査パートナーへの無条件購入コミットメントは、2026年5月2日の27.568億ドルから8月1日の85.189億ドルへ膨らんだ。一方、顧客販売の相当部分は長期契約ではなく、短期間で取消しや延期が可能な発注書に依存する。供給確保は複数年の契約になったが、公開された需要側の拘束力は同じ規模には達していない。
インターネット史
キー入力は4オクテットになった：RFC 916が反復を状態に置き換えた方法
4オクテットのパケットを単独で見ても、3番目のオクテットは読めない。接続開始なら受信上限、通常時なら長さ、`SO` が立てばデータそのものになるからだ。RFC 916の短さは、バイト列の外にある接続文脈を共有することによって成立していた。
インターネット史
読み値を報告しない名前：RFC 1065 と管理可能なものの形
1988 年のインターネット管理には、観測できるものを記述しながら、その記述を観測値そのものに見せかけない仕組みが必要だった。RFC 1065 はその抑制を与えた。管理対象のオブジェクト型には安定した名前、構文、符号化、アクセス区分を与えられるが、特定のインスタンスの現在値は別途取得すべき事実として残る。
インターネット史
「ここから読み直す」と告げた1バイト：SLIP、RFC 1055、そしてシリアルフレームを取り戻す代価
シリアル回線を流れるのは完成したパケットではなく、時間順のオクテットである。雑音が混じった後には、受信側にどのフレームにも帰属できない断片が残りうる。RFC 1055 が勧めた先頭の `END` は、その断片を直すためのものではない。次のデータグラムの前に境界を一度置き、古い蓄積を次の読み取りの先頭にしないための、意図的に小さな再開始だった。
IETF
Mike McBrideと、一種類の衝突だけを防いだマルチキャスト・レジストリ
二人の採番者が同じ番号棚を使い、「たぶん同じ番号は引かない」と期待していた。RFC 10028が変えたのは確率ではない。棚を六つに分け、共通ルールの側から重複を一つ消した。
インターネット史
切替は一度ではなかった――RFC 897が改名とDNS参照を分けた理由
RFC 921 の旧工程表には、三種類の印が並んだ。予定どおり、遅れて実施、まだ未実施。DNS の誕生を祝う年表なら消してしまいそうな失敗が、ここでは移行状態を知るための一次資料になった。
インターネット史
ホストに見せないはずのLAN：RFC 925とトポロジーを隠す代償
初期のインターネット・サイトは、ケーブルごとに外部へ姿を見せることも、複数の LAN を一つのローカルネットワークだとホストに信じさせることもできた。RFC 925は後者の錯覚を選んだ。ホストの ARP は変えず、ホストが知る必要のない経路の発見、記憶、時には代理を中間装置へ移したのである。
インターネット史
運ぶ網が接続そのものではなかった――RFC 892が輸送状態と経路を分けた理由
下の接続が切れたとき、上の接続も必ず死ぬのか。RFC 892 の答えは class によって違った。class 0 では寿命が結び付く。回復機能を持つ class では、別の Network Connection へ割り当て直して同期し直せる。この差が、二つの「接続」を同じものとして扱えない理由だった。
IETF
Gavin Brownと、ドメイン登録にはまだ至っていなかった「成功したcreate」
受付票は、窓口が申請を受け取った証拠である。採択通知ではない。RFC 8334の`applicationID`は、この二つを混同しないための番号だ。EPP コマンドが成功しても、ドメインの割当はまだ保留になり得る。
IETF
Russ Housleyと、証明書には記せても一意にはできないMACアドレス
証明書は6個または8個のオクテットを正確に固定できる。だが、その値を現在使っているインターフェースや、通信を許可した現場の判断まで固定できるわけではない。
インターネット史
最短経路は時刻を運んだが、親時計を選ばなかった――RFC 891のHELLO
RFC 891では、経路表の一行に往復遅延と時計オフセットが同居した。しかし、速い経路が時刻の権威になったわけではない。経路は測定で選び、親時計は設定で指定し、補正の可否は各ホストが判断した。
インターネット史
フレームはデータグラムより長かった――RFC 894がEthernetパディングをIPの外に置いた理由
受信バッファには46オクテットあるのに、IPv4 の Total Length は20を示している。どちらかが誤りとは限らない。Ethernet は最小フレームを満たすための長さを報告し、IP は自分のデータグラムの終端を宣言する。RFC 894は、同じ受信イベントに二つの正しい長さが存在できることを標準にした。
IETF
Benoît Claiseと、ベースモジュール自身には見えないaugment
依存関係を読むとき、出発点のファイルがすべてを語るとは限らない。YANG では、別のモジュールが外からノードを差し込める。RFC 10035は、その逆向きの関係をサーバーの現在形として記録する。
インターネット史
「誰かいるか」と「あなたが提供しているか」は別の質問だった――RFC 887のサービス発見
ブロードキャストへの沈黙は、明示的な否定応答ではない。RFC 887はこの違いを、質問そのものを二種類に分けて表した。さらに第三者の案内を、提供者本人の確認より弱い情報として扱った。
IETF
Kazuho Okuと、拒否を見える化してもストリーミングを約束しないHTTPフィールド
接続が切れず、サーバーも応答を作っているのに、最初のデータだけが届かない。RFC 10036は、その原因の一部を「対応する仲介者の明示的な拒否」に変える。一方で、フィールドを知らないホップまで従わせるものではない。
インターネット史
「公式リスト」は実装証明ではなかった――RFC 880が状態と動作中コードを分けた方法
Telnet の欄には、仕様書があるかだけでなく、古い手引きに残っているか、改訂版に収録されたか、一般に使われているかという別々の列があった。RFC 880は、ひとつの「対応済み」という言葉ではオプションの現実を表せないことを表の形で示していた。
IETF
Aaron Pareckiと、トークン窃取を止めてもクライアント乗っ取りは止めないBFF
OAuth トークンをブラウザの JavaScript から隔離すれば、持ち出して別の場所で使う攻撃は大きく減る。しかし、正規オリジン内で動く悪意あるコードは、利用中のセッションを通じて BFF に処理を依頼できる。RFC 10017は、この「守れたもの」と「まだ呼び出せるもの」を同じ成功表示にまとめない。
インターネット史
バックドアは経路ではなかった――RFC 831が分断されたSATNETへ届くまで
宛先だけを書き換えても、返事は戻らない。送信元だけを書き換えても、要求は届かない。RFC 831が想定した SATNET の分断では、往路と復路が別々の理由で失われていた。そこで UCL のマルチホーム・ホストは、限られた保守通信の両端を二度書き換える。ただし自らを経路として広告してはならなかった。