コンテンツ種別
Analysis
コンテンツ種別の観点では、Analysis は同じ編集形式を持つ BTW.MEDIA の記事を集約し、解説、プロフィール、リスクノート、市場分析、イベント記事を、種類の異なる証拠を混ぜずに比較できるようにします。このページは、この記事タイプがサイト上のインターネット基盤の出来事、企業の動き、ガバナンス上の決定、運用上のシグナル、公開された証拠をどのように位置づけるかを説明します。読者は、どの主体やインフラシステムが頻繁に登場するか、情報源の質が解釈をどう変えるか、対象が継続的なプロフィールなのか、時限性のあるイベントなのか、戦略的な市場シグナルなのか、ガバナンス上の進展なのかを比較できます。同じ形式の記事の背景、時期、証拠を理解したい運用者、投資家、顧客、アナリスト、政策関係者にとって役立つ検索ページです。
インターネット史
迂回路は同時に目的地になれない：DNS CNAME が引いた境界
DNS は古い名前から新しい行き先へ案内できる。ただし、その名前自身の通常データを手放すことが条件だった。CNAME はこの制約を、キャッシュ可能な命令へ変えた。迂回を記憶し、対象名から問い合わせをやり直し、別名を支配する者と到着先のデータを支配する者を混同しない。
インターネット史
半分の応答を真実にしなかった1ビット：DNSが運び方を変えたとき
初期の DNS が通常の問い合わせに使う UDP 応答は、512バイトに収まる必要があった。収まらないとき、先頭から入った記録だけを答えにしないための仕掛けが TC だった。「未完了」を明示し、受け手に完全な応答を取り直させる1ビットである。
インターネット史
頼めても命令できない6ビット――DiffServがサービス品質の権限を区切った理由
パケットに優先扱いの印が付いていても、次のネットワークが同じ列を用意したとは限らない。DiffServ は、その不一致を欠陥として隠さず、ヘッダーの要求とキューを所有する側の決定を別々のものとして設計した。
インターネット史
先に来るものを受信側が選んだ
`MRSQ ?`は、メール本文を送ってよいか尋ねる命令ではない。本文と宛先のどちらを先に受け取りたいかを、MTP の受信側に尋ねる命令だった。`215 T Text first, please`と答えたサイトでは、宛先が一人も示される前に本文が保存される。別のサイトは全宛先を先に表へ積み、一つの本文を後から受け取る。SMTP はこの選択を継承しなかった。内部実装の違いを通信路の二種類の手順にせず、外側を一つの順序へ固定した。
インターネット史
送信されなかったバイト――FTP MODE CはTYPEからフィラーをどう復元したか
受信側には個数が届いた。ところが、繰り返す値はその後にない。欠落ではない。FTP の圧縮モードでは、表現形式の交渉がすでに値を決めており、データ列はその決定を参照して完成する仕組みだった。
ICANN
ICANN の優先番号は文字列評価の順番を決めない――キュー外で進む5つの審査とは
優先順位抽選で小さい番号を得れば、申請処理の一部では有利な位置に立てる。しかし、その番号が申請文字列への「合格見込み」を示すわけではない。ICANN の2026年ラウンド資料は、優先番号の適用範囲を明確に区切っている。優先番号は複数の手続の一般的な順序を決める一方、文字列評価（String Evaluation）の進行順には影響しない。
インターネット史
リレーを一つ通るたび、経路は逆向きへ移った
ONE が受け取った宛先は `JOE@THREE` だけではなかった。SMTP の forward-path は `@ONE,@TWO:JOE@THREE` だった。ONE は左端の自分を消し、次の環境で通用する自分の名を reverse-path の先頭に積む。未走行の経路は短くなり、配達不能時に戻る経路は長くなる。一つの住所のように見えた文字列は、実際には中継ごとに向きを変えるエンベロープ状態だった。
インターネット史
二度現れなければならなかったバイト：FTPがストリーム内にレコード境界を置いた方法
受信処理が全ビット1のバイトを読んでも、その場ではファイルへ渡せない。次も同じなら、二つを一つのリテラルデータへ戻す。次が小さな制御値なら、レコード、ファイル、または両方の終わりになる。FTP はネットワークの区切りに頼らず、連続した流の内側へ可逆な構造を埋め込んだ。
IETF
Ray Bellisと、未知をそのまま渡すべきDNSプロキシ
家庭用ゲートウェイは、DHCP で自分を DNS サーバーとして知らせるだけで、すべての端末の前に立てる。問題は、その小さな実装が将来の DNS まで理解できるかではない。Ray Bellis が RFC 5625で問うたのは、理解できないものに出会ったとき、プロキシが意味を壊さず、制限を隠さず、利用者の選択を奪わずにいられるかだった。
インターネット史
欠けたページはゼロのページではなかった：FTP STRU Pがホスト間で穴を運んだ仕組み
受信した二つのページの論理番号が連続していない。途中のページはネットワークで失われたのか。それともゼロで埋めるべきなのか。FTP の`STRU P`は、どちらでもない答えを持っていた。そこには最初からページが存在しないという構造を運んでいたのである。
欧州・中東の地域 ISP トレンド
BSHの単一窓口モデル、SLAに必要なのは依存関係の証拠だ
複数拠点の通信契約を一本化し、障害時の責任窓口を一つにする。BSH の提案は、顧客が何社もの事業者を追いかける負担を減らし得る。ただし、契約が一つになっても、アクセス回線、経路、建物、電源、運用チームまで相互に独立するわけではない。
インターネット史
最初に届いた断片では決められなかったヘッダー
受信機が最初に見たのは、オフセットがゼロではない IPv4 フラグメントだった。IHL は短く、Record Route も Timestamp もない。しかし、それを元のデータグラムの完全なヘッダーだと判断してはならない。Copy ビットがゼロのオプションは、遅れて届くゼロ・オフセットのフラグメントだけに残るからである。到着順と意味上の「先頭」は同じではなかった。
インターネット史
まだ起きていなかった名前変更：FTPがファイルをRNFRとRNTOの間に置いた理由
FTP サーバーが`350`という肯定応答を返しても、古い名前はまだ残っているかもしれない。`RNFR`が受理したのは変更そのものではなく、変更元を覚えて次の情報を待つ状態だった。名前変更が実際に完了するには、直後の`RNTO`と最終応答が必要だった。
記事
LACNIC――不祥事後の正統性をめぐる経済学
確認済みの危機を仮定し、初動、忌避、調査、上訴、業務継続を時間軸で点検する。
インターネット史
六十四ビットの棚に収められた三十六ビットの一単位
三十二ビット語で動く受信機に、三十六ビットを一単位とするファイルが届く。FTP が示した解は、三十六を三十二に切り詰めることでも、回線上の八ビットごとに別の値とみなすことでもなかった。たとえば六十四ビットの保管単位に一つずつ収め、同じ条件で取り出したとき元の三十六ビット列へ戻せるようにする。保存場所は受信側が決めるが、失ってよい情報まで受信側が決めるわけではない。
インターネット史
ファイルシステム切替を越えて残ったログイン：FTP SMNTが認証主体と名前空間を分けた理由
ログインが続いているなら、見えているファイルの世界も同じだと思いたくなる。FTP の`SMNT`は、その直感を仕様の上で否定した。利用者、課金情報、転送条件を保ったまま、名前を解釈するファイルシステム構造だけを切り替えられたからである。
インターネット史
メールボックスより先に届こうとしたメッセージ：SMTPが端末配送を手放した理由
初期の SMTP には、メールボックスへ預けるだけではない選択肢があった。利用中の端末へ直接表示する、端末が使えなければメールボックスへ回す、あるいは両方へ届ける。人が「いま接続中で、割り込みを受け入れている」という刹那的な状態を転送契約に含めた設計は、やがて互換機能の隅へ退いた。その経緯は、保管責任と即時の注意が別物である理由をよく示している。
インターネット史
あなたのためではなかった青信号：NNTPがグループ方針と投稿権限を分けた理由
ニュースグループ一覧の末尾に `y` がある。通常なら「投稿可」を意味する。ところが同じ接続から `POST` を送ると、サーバーは `440 Posting not permitted` と答えられる。NNTP にとって両者は矛盾しない。前者はグループの標準的な扱い、後者はそのクライアントに対する現在の判断だった。
インターネット史
正しいパスワードの後に残った第三の問い
`PASS`が受け入れられても、FTP のログインが終わるとは限らなかった。サーバーは`230`ではなく`332`を返し、利用者名ともパスワードとも別の`ACCT`を要求できた。その一行は、本人確認と、その作業をどのローカルな勘定・権限文脈に置くかが別の決定だった時代を映している。
記事
LACNIC、IANA承認と制度的フランチャイズのリスク
LACNIC の IANA 承認は商業フランチャイズではないが、世界の番号体系と地域社会を結ぶ希少な制度的位置を一組織に与える。