プロフィール
Research
Research のプロフィールは、人物、企業、機関、その他のエンティティを横断し、BTW.MEDIA の報道の背後にある対象を比較したい読者に、まとまった情報を提供します。このページでは、公開上の役割、関連イベント、証拠一式、役職・責任の変化、事業展開の範囲、ガバナンス上のリスク、組織間の関係性、市場での重要性を比較できます。企業や人物の記録は通常のニュース時系列とは分けて管理され、見出しの背後にある主体、そのプロフィールを裏付ける証拠、そしてそのプロフィールを重要にするインフラや市場との関係を理解できます。プロフィールが誰・何を表しているか、どの公開情報源がそれを支えているか、企業・市場・ガバナンス機関・イベントとどう結びついているか、そして対象の変化に伴い今後も注目すべき点を確認できます。

インターネット史
CLDAPはなぜ標準化を進められなかったのか:RFC 3352
1995年、CLDAP は接続確立を省き、小さなディレクトリ検索を短い経路で返すことを目指した。8年後の RFC 3352は、その利点だけでは RFC 1798を維持可能な標準へ育てられなかった理由を記録した。ただし、個々の環境で動くコードがすべて消えたとは述べていない。

インターネット史
MPLS は別の経路を選んだ。容量を生み出したわけではない:RFC 3346
最短経路の一本だけが混み、遠回りの回線には余裕が残る。その偏りを直せることが MPLS トラフィックエンジニアリングの魅力だった。RFC 3346 はその効用を認めたうえで、経路変更は既存容量の配置を変えるだけであり、LSP に設定した帯域値そのものは実トラフィックの証明ではないと記録した。

IETF
ゲートウェイは厳しくできる。オリジンの許可にはなれない
中継者は、理解し実際に執行する限り、オリジンが示したレート制限より厳しい制約を伝えられる。しかし、その判断はオリジンの受理結果ではない。経路上の助言と最終的な権限を分けなければならない。

IETF
署名は正しかった。信頼先の選択は別だった
署名検証は成功した。証明書の連鎖も処理できた。しかし、その署名者がこの管理ドメインの帯域を拘束してよい主体かどうかは、暗号計算からは出てこない。正しい署名と正しい権限は、同じ問いへの二つの答えではない。

インターネット史
新しいアドレスは受理された。古いアドレスもまだ有効だった:RFC 3344
新しい登録応答が成功を告げても、以前の転送先が消えたとは限らない。RFC 3344 の `S` ビットは、古いモビリティ・バインディングを残し、一つのデータグラムを有効なすべての気付アドレスへ複製する選択肢を明示していた。

インターネット史
通話を切らずに文字を加える:RFC 3351とSIP
2002年のアクセシビリティ提案が問い直したのは、ごく実務的な設計上の前提だった。伝え方を変えるたびに、通話まで最初からやり直す必要があるのだろうか。

インターネット史
購読は終了した。それでも更新はまだ届き得た:RFC 3343
終了の返答を受け取った後で、古い購読に属するプレゼンス更新が届いた。RFC 3343はこの順序を許していた。サービスは新しい更新を止めたが、先に中継網へ渡した更新までは消せない。終了は送信元の未来を変え、すでに動き出した過去を取り消すものではなかった。

IETF
管理値は変わった。動作状態はまだ追いついていない
SET は新しい値を受理し、直後の GET は古い動作を返した。矛盾していたのは装置ではなく、指示と現在状態を一つのオブジェクトに押し込んだ証拠設計だった。

IETF
104 を受け取った。成功通知を出すにはまだ早い
HTTP の 104 応答は、切断後に戻れる一時リソースを知らせるためのものだ。回復経路が確保されたことと、対象リソースが表現を受理し業務処理を確定したことは、同じ出来事ではない。

インターネット史
遅延報告が発せられても、メッセージは進み続けた:RFC 3342
送り手のもとへ遅延報告が向かい始めた時点でも、元のデータは次の中継へ渡されていた。RFC 3342では、警告の発生と配送の停止は同じ出来事ではない。さらに、最終報告が戻るための期限も別に存在した。三つの時計を一つの成否表示に潰すと、正しい警告が誤った命令へ変わる。

IETF
同じ経路で再送できても、観測の権限までは強くならない
QUIC の新しい提案は、観測したアドレスを元の経路で再送するよう求める。これは配送規律として重要だが、その値が正しい、長く有効である、他の相手から到達できるという証明ではない。

インターネット史
許可エントリを削除しても権限は残った:RFC 3341
個別の許可行を消したのに、対象者はまだデータを送れた。RFC 3341では、それは削除失敗ではない。より広いワイルドカード規則が次の最良一致になった結果である。取消しを維持するには、何も置かないのではなく、`all:none` という具体的な拒否を残す必要があった。

IETF
古い物差しで新しい防御機能を比べた
RFC 3511 で得た数値と RFC 9411 で得た数値が、一つの時系列に並べられた。変わったのは装置だけではない。測定対象そのものだった。

インターネット史
応答は問い合わせたアプリケーションより長く残り得た:RFC 3340
宛先の名札は同じなのに、その裏にいるプログラムはもう別物だった。RFC 3340 が描いたのは、最初のアプリケーションが離脱した後、同じエンドポイントへ接続した二番目のアプリケーションに古い応答が届く場面である。相関が正しくても、所有者まで同じとは限らない。

IETF
パラメーターは届いた。意味は共有されていなかった
セミコロン以降の値は一字も失われず相手へ届いた。しかし送信側は経路指示、受信側は単なる未知属性として扱った。RFC 3508 は拡張欄を用意したが、その一般意味まで定義していない。

インターネット史
同じ瞬間でも由来は同じではなかった:RFC 3339
保存された日時が正しい瞬間を指していても、証拠として十分とは限らない。RFC 3339は2002年、オフセット表現に参照元の違いを持たせた。RFC 9557は2024年、その一部を更新した。瞬間そのものは変わらないのに、文字の読み方は変わり得る。だから正規化値だけでなく、受信した形と解釈規則も残さなければならない。

IETF
セレクターの変換が正しくても、SLA は引き継がれない
ドメイン境界で NRP セレクターを正しく置き換えられても、下流側の帯域配分、トラフィック調整、測定条件まで自動的に継承されるわけではない。境界は識別子の接続点であると同時に、証拠が切れやすい場所だ。

インターネット史
IPv4アドレスはローカルなハンドルにすぎなかった:RFC 3338
古いアプリケーションには IPv4 アドレスが返されたように見えた。しかし、その IPv4 宛先がネットワーク上に存在する必要はなかった。RFC 3338の Bump-in-the-API(BIA)は名前解決とソケット呼び出しを横取りし、ホスト内のプールから一時的な IPv4 形状の値を割り当て、その値を手掛かりに実際の IPv6 相手を取り出した。それは大域的な身元ではなく、表と有効範囲と時点によって意味が決まるローカルハンドルだった。

IETF
サービスは更新された。古い ISTag が判定を生かした
ルールは更新済みだったが、あるノードは旧い `ISTag` を返し、キャッシュは旧判定を再利用した。RFC 3507 が与えるのは比較可能なサービス時代であり、展開完了の証明ではない。

IETF
PPP認証は隣接するチャネルを守らなかった:RFC 3336
「PPP 認証済み」「リンク Up」「CRC 正常」は、同じ安全性を示す三つの言い方ではない。RFC 3336が2002年に記述した AAL2 の構成は、それぞれが別の問いに答えることをよく表している。
