プロフィール
Research
Research のプロフィールは、人物、企業、機関、その他のエンティティを横断し、BTW.MEDIA の報道の背後にある対象を比較したい読者に、まとまった情報を提供します。このページでは、公開上の役割、関連イベント、証拠一式、役職・責任の変化、事業展開の範囲、ガバナンス上のリスク、組織間の関係性、市場での重要性を比較できます。企業や人物の記録は通常のニュース時系列とは分けて管理され、見出しの背後にある主体、そのプロフィールを裏付ける証拠、そしてそのプロフィールを重要にするインフラや市場との関係を理解できます。プロフィールが誰・何を表しているか、どの公開情報源がそれを支えているか、企業・市場・ガバナンス機関・イベントとどう結びついているか、そして対象の変化に伴い今後も注目すべき点を確認できます。
インターネット史
何もしない分岐を救済した設計：RFC 3028
フィルターのどの条件にも当てはまらないメールを、どう扱うべきか。Sieve はその空白を放置せず、通常の受信箱へ保存する「暗黙の保存」に変えた。RFC 3028 が示したのは、規則の評価と配送結果を分ける設計である。命令が選ばれても、保存や転送が完了したとは限らない。
インターネット史
会議はメールのヘッダーにはなかった――RFC 2447 の MIME 境界
RFC 2447 は、iTIP の予定情報を電子メールで運ぶための薄い接続層を定めた。MIME の `text/calendar` 部分に機械が読める予定オブジェクトを置き、外側の `method` をオブジェクト内の `METHOD` と一致させる。対応する予定表を持たないメールソフト向けには、人が読める説明も同じメッセージに添えられた。
インターネット史
`+xml` は入口を示したが、意味までは運ばなかった：RFC 3023
末尾の `+xml` を見れば、汎用 XML parser を試せる。しかし、その文書が何を命じ、誰に権限があり、どの結果を残したかは、四文字からは読めない。共通構文を発見することと、固有の意味を承認することは別の判断だった。
インターネット史
RFC 2446が分けた「提案」と「決定」――iTIPに見る予定調整の権限境界
電子カレンダーで「会議を月曜から火曜へ変えたい」と送信することと、実際に共有予定が火曜へ変更されることは同じではない。RFC 2446 が1998年に定義した iCalendar Transport-Independent Interoperability Protocol（iTIP）の歴史的な重要性は、予定データの交換形式だけでなく、誰が何を提案し、誰が master entry を変更し、どのメッセージがその変更を伝えるのかを別々の状態遷移として扱った点にある。COUNTER、REQUEST、REPLY、SEQUENCE…
インターネット史
「ネットワークアドレス」がhostになれる狭い条件：RFC 3021
host 部がすべて0の値は通常、subnet そのものを表した。RFC 3021はその値を無条件に解放したのではない。二つの endpoint しか存在しない link でだけ、隣の router として扱う例外を定めた。
インターネット史
エラーは1件、失われたフレームは複数だった：RFC 3020の「up」を読む
RFC 3020の Multilink Frame Relay MIB では、bundle が up になる条件と、フレームが正しく届いたことは別の問題だった。再順序化エラーの1カウントは複数の欠落を含み得る。まして論理 interface の緑表示は、選ばれた activation policy を通過したことしか証明しない。
インターネット史
「メンバーあり」の行は、管理側が作った行かもしれない：RFC 3019
RFC 3019は IPv6 multicast の listener 状態を SNMP から読める形にした。同時に、cache 行の作成と削除、local membership の設定、MLD の有効化や timer 調整も可能にした。表は agent の現在地を示すが、remote listener や受信結果の独立証明ではなかった。
インターネット史
一度きりのパスワードでも、セッションは守れない――RFC 2444
RFC 2444は、ワンタイムパスワードをネットワーク・プロトコルから呼び出すための SASL 機構として定義した。認証の入口は標準化したが、その後の通信を秘匿したり、サーバーを認証したりする規定ではない。
インターネット史
一括実行はできた。遠隔CALLの後を一括で元には戻せなかった：RFC 3018
RFC 3018の UMSP は、複数 node の memory を128-bit の一つの空間として扱う構想だった。transaction は命令群をまとめて実行へ移せたが、実行後の control transfer まで取り消す仕組みは定義しなかった。
インターネット史
レプリカは一致していた。それでもクライアントは戻らなければならない――RFC 2443
1990年代末、ATM 網では IP マルチキャストを運べたが、クライアントには「どのグループがあり、誰が参加しているのか」を把握する仕組みが要った。RFC 2443は複数の MARS サーバーでその状態を共有した。ただし、障害時の規則は単純な冗長化とは違う。元のサーバーが生存を示さなくなれば、仲間のサーバーはその由来の会員情報を消し、クライアント自身が戻って登録し直す。
インターネット史
電話帳の版は上がった。それでも旅先の設定が新しい証拠にはならなかった：RFC 3017
番号、ダイヤルスクリプト、DNS、proxy、username の加工規則まで一冊に入れば、それは閲覧用名簿ではなく設定入力になる。RFC 3017はその形を共通化したが、版番号だけで配布・適用・接続の成功まで証明しなかった。
インターネット史
どこで切るかが、一度の損失で消える範囲を決めた：RFC 3016
ストリームを RTP へ載せる作業は、単なる梱包ではなかった。RFC 3016では、切れ目の位置が再同期点を守ることも、複数の媒体単位を一度に失わせることもあった。
インターネット史
新しいタグはパケットに収まった。それでもプロトコルを弱め得た――RFC 2440
パケットヘッダーの空き番号は、拡張への招待状に見える。1998年の OpenPGP 仕様は、もっと難しい問いを示した。新しいタグを解析できることは、その機能が暗号システム全体と安全に共存できる証拠ではない。
インターネット史
Contextは接続された。通話はまだ証明されていない：RFC 3015
Megaco は、メディアゲートウェイ内部の関連を命令し監査できる対象にした。RFC 3015が同時に示したのは、その局所状態と、外部ネットワークを越えた受信、再生、会話の成立とは別の証拠だということだった。
IETF
変更可能と書かれたルールは、変更者を名指ししていない
SCHC の新しいアクセス制御案は、圧縮ルールのどこを変更できるかを細かく表現する。しかし、変更可能性の表示は、認証された主体への許可でも、共有 Context の安全な切替手順でもない。
インターネット史
通知は消えた。控えのログもまた消し得た：RFC 3014
受信できなかった通知を後から拾うための帳簿。その帳簿に何を入れ、いつ捨て、誰が保存幅を縮められるのかまで標準化したところに、RFC 3014 の歴史的な鋭さがある。
インターネット史
ページは速くなった。それでも共有リンクの成績は別だった：RFC 2414
1998年、TCP で最初に2セグメントを送る意味は、1つのときの倍のデータを運ぶことだけではなかった。遅延 ACK タイマーが切れる前に、受信側から確認応答を引き出せる可能性があった。短い Web 転送を速める期待は魅力的だったが、パケットが入るのは共有キューだ。ページの高速化だけでは、フロー間の公平性は立証できない。
IETF
プロキシは「稼働中」と答えた。対象インターフェースは応答していない
PROBE は、直接 ping できないインターフェースについて、到達可能なプロキシから状態を得るための道具である。その利点を安全に使うには、返答した主体と、実際に観測された範囲を最後まで消してはならない。
インターネット史
ゲートウェイはチャレンジを出した。それでも信頼はまだ届いていない：RFC 3012
訪問先ネットワークの Foreign Agent が最初に確かめられたのは、端末の全人格ではない。「これは自分がいま出した値への応答か、それとも昔の登録の再送か」という、狭くても実用的な事実だった。
インターネット史
要求は内側から届いた。割り当てるアドレスは外側にあった――RFC 3011
DHCP が見た入口と、利用者が必要としたアドレス空間は同じとは限らない。RFC 3011 はそのずれを例外処理ではなく、監査できるプロトコル上の選択にした。