プロフィール
Research
Research のプロフィールは、人物、企業、機関、その他のエンティティを横断し、BTW.MEDIA の報道の背後にある対象を比較したい読者に、まとまった情報を提供します。このページでは、公開上の役割、関連イベント、証拠一式、役職・責任の変化、事業展開の範囲、ガバナンス上のリスク、組織間の関係性、市場での重要性を比較できます。企業や人物の記録は通常のニュース時系列とは分けて管理され、見出しの背後にある主体、そのプロフィールを裏付ける証拠、そしてそのプロフィールを重要にするインフラや市場との関係を理解できます。プロフィールが誰・何を表しているか、どの公開情報源がそれを支えているか、企業・市場・ガバナンス機関・イベントとどう結びついているか、そして対象の変化に伴い今後も注目すべき点を確認できます。
インターネット史
ルートは合意を減らしたが、世界名簿の権威にはならなかった――RFC 2120
X.500 の名前空間は一本の木として描けても、その根を動かす手続きは一本化されていなかった。第一階層の Directory System Agent（DSA）の管理者は、標準の外で相互に合意を結ぶ必要があった。RFC 2120 が描いたのは、NameFLOW-Paradise が非標準のルート DSA「Giant Tortoise」でその合意網を縮めた経緯と、実用上の利点を失わず ISO プロトコルへ移るための段階設計である。
インターネット史
Adele Goldberg と Smalltalk-80 を旅立たせた契約
「Blue Book」が記述したのは、生きたシステムを持ち運ぶための境界だった。同じイメージを保ち、各マシンでオブジェクトメモリ、バイトコード、実行コンテキスト、プリミティブを実装する。それにより Smalltalk-80 は再実装できたが、速度、フォント、ウィンドウ、デバイス、操作感まで同一になるとは約束されていなかった。
インターネット史
Join に受領証はなかった――更新で生き残る木、RFC 2117
RFC 2117 の疎なマルチキャスト木は、一度の全体取引で成立しなかった。ローカルな会員通知が状態を作り、Join/Prune が各ホップを更新し、新しい送信元は Register で RP に到達し、その後で一部の枝だけが送信元固有経路へ移った。確実性ではなく、期限付きの局所記録が規模を支えた。
IETF
送る前の言葉は誰のものか――RFC 9787の下書き暗号化とコミットメント境界
これは仮想の場面だ。一台の端末で書きかけた文章が自動保存され、数分後、別の端末で同じメールボックスを開くと、その続きが現れる。しかし、その同期が成功したからといって予定受信者が文章を読めるわけではないし、著者が書かれた内容にすでに責任ある意思表示をしたことにもならない。RFC 9787 が下書き暗号化について引く重要な線は、まさにこの途中状態にある。保存と送信は同じメッセージの前後ではあっても、権限、可視性、そしてコミットメントの状態は同じではない。
ケースファイル
Internet Societyは2026–2027年選挙日程を承認した――次に必要なのは公開された稼働記録だ
理事会が時計を承認したことと、参加者がその時計の針を確認できることは同じではない。Internet Society 理事会は9月14日、次期選挙を担う二つの委員会に4人を追加し、「添付のとおり」2026–2027年選挙日程を承認した。決定自体は公開記録で確認できる。残る課題は、添付資料、公開ページ、通知、システム稼働、認証を一つの検証可能な履歴に結び付けることだ。
インターネット史
「1か所」「複数」「観測なし」——RFC 2108が曖昧さを消さなかった理由
管理装置が送信元アドレスを探したとき、答えは常に一つのポートになるわけではなかった。RFC 2108は `single`、`multiple`、`none` を別の状態として残し、測れたことと断定できることの境界を MIB の中に組み込んだ。
インターネット史
Kathleen Boothと、記号が機械命令になる境界
1947年、Kathleen H. V. Britten と Andrew D. Booth は、数学的な手順を20ビットの命令へ落とし込む道筋を記述した。略号はその道筋を読みやすくしたが、計算の意味まで機械に判断させたわけではない。
ケースファイル
W3CのLLMノートは個人責任を示したが、説明責任の手続きは定めていない
W3C Advisory Board は、大規模言語モデルを使ったかどうかにかかわらず、共有した成果には本人が責任を負うと述べた。明快な原則である。しかし同じ文書のステータス欄は、これは Advisory Board が支持する Group Note であり、W3C 全体やそのメンバーが支持したものではないと明記する。妥当な助言を、審査と訂正が可能な規則へ変えるには、誰が採択し、どの証拠を残し、誰が異議を扱うのかを別に定めなければならない。
インターネット史
アドレスは「自宅」、ダイヤル回線は「遠隔」を示した：RFC 2107
RFC 2107 は、遠隔ダイヤルアップ端末にホームネットワーク上の存在感を与えた。その見かけは Foreign Agent、Home Agent、共有秘密、Tunnel ID、そして正しい順序で生成・破棄される状態に支えられていた。
インターネット史
ルーターは端末にアドレスを与えた。身元までは与えなかった――RFC 2106
RFC 2106 は、多数の遠隔 SNA／NetBIOS 端末を一台の DRAP サーバーの背後に収容した。バックボーン側の接続は減ったが、状態と判断権限は境界装置へ集まった。
インターネット史
タグはパケットを進めたが、経路を証明しなかった――RFC 2105
短いタグを付けたパケットがスイッチに入る。装置はその値を正確一致の索引として使い、出口を選び、別のタグに置き換えて次へ送る。1997年の Cisco Tag Switching 構想が美しかったのは、この動作が簡潔だったからだ。しかし、その簡潔さは経路の真実を内包していたからではない。ルーティングとタグ配布が、タグの意味を先に作っていたからである。
IETF
二度目の救済を拒む権利――RFC 9791とNFFRRが作るFast Rerouteの責任境界
期限切れの NFFRR ドラフトに、示唆的な EVPN active-active の事故再構成がある。CE2 が停止すると、PE2 には link1 障害、PE3 には link2 障害に見える。PE2 は PE3 へ退避し、PE3 も局所判断に従って PE2 へ戻す。二つの合理的な修復が結合し、パケットは TTL 切れまで往復する。これは実測された本番障害ではなく文書上の例だ。それでも問いは鋭い。一度 FRR されたパケットに対し、誰が「二度目の救済は危険だから拒め」と命じられるのか。
ケースファイル
RFC 9682の公開だけでは、パーサは届かない
標準の公開は、新しいパーサを配送しない。CDDL の文法が修復されても、その規則が生成バリデータを経て受信側に届いたかは別の問いだ。「対応済み」という一語を解き、標準本文から実行時の電文まで、引き渡しの記録を追う。
インターネット史
2回のハッシュ処理がMACを再利用可能にした。しかし信頼判断までは代行しなかった：RFC 2104
RFC 2104は、既存の反復型ハッシュ関数を内側と外側の2段で包み、再利用できるメッセージ認証コードを定めた。下層のハッシュを交換できる設計は長く残ったが、一致するタグが示す範囲は鍵・アルゴリズム・正確なバイト列に限られる。人物やホストの同一性、権限、鮮度、配送、運用の正しさまで自動的に証明するものではない。
IETF
見えるネットワークは誰を結び付けるのか――RFC 9686と相関能力の統治
アーキテクチャ／プライバシー審査で、自己生成 IPv6 アドレスの登録は二つの顔を持つ。SLAAC や静的設定で選ばれたアドレスを運用者から見えるようにする一方、Client Identifier、アドレス、接続点を横断的に結び付ける能力も強めるからだ。RFC 9686を安全に導入する鍵は、収集できる情報、相関してよい情報、相関結果に基づいて実行できる対応を、同じ権限として扱わないことにある。
インターネット史
リンクは開いた。それでも各名前には受け入れ判定が要った：RFC 2097
PPP は遠隔端末を NetBIOS Frames ネットワークの入口まで運べたが、RFC 2097はリンク確立を到達性と同一視しなかった。NBFCP は、どの16オクテット名を相手側ネットワークへ投影するか、どれが失敗したか、相手の実装種別、マルチキャストの扱い、12オクテット MAC ヘッダーの要否を個別の約束として残した。
インターネット史
カウンターは一受信者の窓を通過したが、送信者の名は示さなかった：RFC 2085
RFC 2085 は HMAC-MD5 Authentication Header に64ビットのリプレイ値を追加した。ただし、そのフィールドを使うかは Security Association ごとに決まった。受信者は自分の並べ替え窓の中で未受信の番号を許可できた。それは一つの SA における新鮮さの証拠であって送信者の身元ではない。複数のマルチキャスト送信者が SA を共有すると、この差が露出した。
インターネット史
四文字目が編集後に残せるものを決めた：RFC 2083
PNG の画素をすべて描き直しても、編集ソフトが理解できない古いメタデータだけが残ることがある。RFC 2083 は、そのメタデータを真実だと認定しなかった。四バイトのチャンク型にある大文字・小文字を使い、未知の機能に対してデコーダーと編集ソフトが取るべき最小限の行動を符号化した。
インターネット史
ディレクトリは二つのリンクを保存したが、意味までは保存しなかった：RFC 2079
一つの項目に「公式記録」と「現行サービス」という二つのリンクが並んでいても、見た目だけでは関係を判定できない。RFC 2079 は URI と人向けラベルを分け、複数値として格納できるようにした。しかし、別資源なのか同じ資源の別地点なのか、古いページなのか権威ある情報源なのかは決めなかった。解析可能性と真実性は別だった。
インターネット史
ヘッダーがあっても権限は付いてこない：RFC 2076 の境界図
パーサーが `Apparently-To` を読めたとしても、一般メールの標準命令、安全な公開情報、受信側が従うべき指示であることまでは証明できない。RFC 2076 は、よく見かける名前をプロトコル、状態、出典、制限と一緒に記録し、その飛躍を防いだ。