コンテンツ種別
Research
コンテンツ種別の観点では、Research は同じ編集形式を持つ BTW.MEDIA の記事を集約し、解説、プロフィール、リスクノート、市場分析、イベント記事を、種類の異なる証拠を混ぜずに比較できるようにします。このページは、この記事タイプがサイト上のインターネット基盤の出来事、企業の動き、ガバナンス上の決定、運用上のシグナル、公開された証拠をどのように位置づけるかを説明します。読者は、どの主体やインフラシステムが頻繁に登場するか、情報源の質が解釈をどう変えるか、対象が継続的なプロフィールなのか、時限性のあるイベントなのか、戦略的な市場シグナルなのか、ガバナンス上の進展なのかを比較できます。同じ形式の記事の背景、時期、証拠を理解したい運用者、投資家、顧客、アナリスト、政策関係者にとって役立つ検索ページです。

インターネット史
重複 ACK が二つ届いても、広げるのは送信であってウィンドウではない――RFC 3042
輻輳ウィンドウが三セグメントの TCP 接続で、一つのセグメントが失われる。後続データが返せる重複 ACK は最大二つで、Fast Retransmit の既存しきい値には一つ足りない。2001 年の RFC 3042 は、この間を埋めるため、最初の二つの ACK に対して新しいデータを送る仕組みを提案した。ただし輻輳ウィンドウは増やさない。

ラテンアメリカ・カリブの国内通信事業者
ミリコムのラテンアメリカ統合完了——買収発表から資本負担へ変わった経済構造
ミリコム・インターナショナル・セルラー(Millicom International Cellular S.A.、ブランド名 Tigo)の中南米買収プログラムは、発表段階から完了段階へ移った。ウルグアイ、エクアドル、コロンビア(テレフォニカ保有67.5%と政府系ラ・ナシオン保有32.5%の両方)、EPM 保有の UNE 株がすべて決済済みであり、チリは NJJ との49%/51%合弁会社 Celtel Chile…

インターネット史
ATMラベルはホップごとに変わる。LDPには両端で共有するVCIDが必要だった
ATM 回線がセルを運び続けていても、次のスイッチで VPI/VCI は別のローカル値に置き換わり得る。RFC 3038はそのホップ単位のラベルと、隣接する LDP ノードが同じ仮想回線を指すための共通 ID を分けた。

インターネット史
コアは TTL を減らせなかった――入口で隠れたホップを先払いした RFC 3034
Frame Relay スイッチは DLCI を高速に置き換えられても、各パケットの TTL を減らす回路を通常は備えていなかった。RFC 3034 はそのホップを無かったことにせず、MPLS の計算を区間境界へ移した。制御面が長さを伝え、入口が差し引く。しかし、その数値だけでは実際の通過経路は証明できない。

欧州・中東の国内通信事業者
stc、ほぼゼロレバレッジからの転換——サウジの通信投資循環が動き出す
2026年上半期、stc(Saudi Telecom Company JSC)は自社の財務状態を意図的に変えた。増資でも買収でもなく、資産負債表のレバレッジを使って設備投資を31.0%増額するという転換である。この記事は、その転換がどのような資金調達と投資先で構成されているか、そしてネットワーク品質の優位が市場シェアに転化しているのかという疑問を検証する。

インターネット史
LDPは全長プレフィックスを残し、Host Address FECを外した
標準の改訂は、表現の一つを削っても、そこで扱っていた能力まで捨てるとは限らない。RFC 3036では全長アドレスのプレフィックスと Host Address FEC が別の意味を持っていた。2007年の改訂は、実装で使われていないという理由で後者を削り、全長プレフィックスを残した。

インターネット史
識別子はセッションを指したが、移したわけではない:RFC 3033
ATM の呼制御メッセージに正しい IPv4 セッション識別子が入っていても、パケットはまだ既定の仮想回線を通っているかもしれない。RFC 3033 は、何を対象にしているかを正確に伝える方法を定めた一方、回線確立、IP 層の移行、QoS の成立を同じ事実にはしなかった。

インターネット史
サーバーは機能を示した。認証後、その答えは変わった:RFC 2449
POP3 クライアントは接続者を知る前に、サーバーに何ができるかを尋ねる。その返答は意図的に慎重でよい。利用者を認証した後なら、同じサーバーも、より具体的な答えを返せる。さらに完全性保護層が加われば、先の一覧がもう有効とは限らない。RFC 2449 は機能発見を機械可読にしたが、一つの一覧をあらゆる状態に通用するサーバーの説明とはしなかった。

インターネット史
署名された判定が「無効」でも矛盾しない:RFC 3029
信頼されたサーバーが証明書を発行し、そこに「無効」と記す。署名は対象を有効にする魔法ではない。誰が、どの要求と時刻と方針に基づいて、その判定を出したかを固定する。RFC 3029 は、サービスの成功と検証結果の成功を意図的に切り分けた。

インターネット史
ネットワークは全パケットを等しく扱った。コーデックはそうではない:RFC 2448
圧縮映像では、数バイトを失ったからといって損害も小さいとは限らない。画像データの一部なら局所的な乱れで済むかもしれないが、その先をどう復号するかを示す短い情報が欠けると、より広く崩れることがある。1998年の RFC 2448は、その違いを送信側の設計に持ち込んだ。コーデック上の役割で情報を分け、失われたときの影響が大きい部分に、より確かな経路を与える。

インターネット史
何もしない分岐を救済した設計: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 サーバーでその状態を共有した。ただし、障害時の規則は単純な冗長化とは違う。元のサーバーが生存を示さなくなれば、仲間のサーバーはその由来の会員情報を消し、クライアント自身が戻って登録し直す。
