トピック
ソフトウェアライフサイクルとベンダーロックイン
「トピックの観点から見たソフトウェアライフサイクルとベンダーロックイントピックは、特定のテーマ、シグナル、または監視すべき話題を共有する記事を結びつけます。このページは、関連報道、公開情報源、市場関係者、インフラへの影響をたどる豊かな道筋を提供し、企業動向、政策決定、地域的影響、運用リスクにわたってそのトピックがなぜ重要なのかを理解するための十分な文脈を与えます。単なる記事リストにとどまらず、読者は繰り返し現れるシグナル、影響を受ける組織、公開証拠、市場背景、サービス継続性、調達、競争、コンプライアンス、戦略計画といった背景を比較できます。このページでは、トピックの対象範囲、関係するインフラ事業者や政策、報道内容を裏付ける証拠、そして通信事業者、顧客、投資家、政策関係者にとってそのテーマがなぜ重要なのかを説明します。」
インターネット史
送信されなかったバイト――FTP MODE C は TYPE からフィラーをどう復元したか
受信側には個数が届いた。ところが、繰り返す値はその後にない。欠落ではない。FTP の圧縮モードでは、表現形式の交渉がすでに値を決めており、データ列はその決定を参照して完成する仕組みだった。
インターネット史
リレーを一つ通るたび、経路は逆向きへ移った
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`は、どちらでもない答えを持っていた。そこには最初からページが存在しないという構造を運んでいたのである。
インターネット史
最初に届いた断片では決められなかったヘッダー
受信機が最初に見たのは、オフセットがゼロではない IPv4 フラグメントだった。IHL は短く、Record Route も Timestamp もない。しかし、それを元のデータグラムの完全なヘッダーだと判断してはならない。Copy ビットがゼロのオプションは、遅れて届くゼロ・オフセットのフラグメントだけに残るからである。到着順と意味上の「先頭」は同じではなかった。
インターネット史
まだ起きていなかった名前変更：FTP がファイルを RNFR と RNTO の間に置いた理由
FTP サーバーが`350`という肯定応答を返しても、古い名前はまだ残っているかもしれない。`RNFR`が受理したのは変更そのものではなく、変更元を覚えて次の情報を待つ状態だった。名前変更が実際に完了するには、直後の`RNTO`と最終応答が必要だった。
インターネット史
六十四ビットの棚に収められた三十六ビットの一単位
三十二ビット語で動く受信機に、三十六ビットを一単位とするファイルが届く。FTP が示した解は、三十六を三十二に切り詰めることでも、回線上の八ビットごとに別の値とみなすことでもなかった。たとえば六十四ビットの保管単位に一つずつ収め、同じ条件で取り出したとき元の三十六ビット列へ戻せるようにする。保存場所は受信側が決めるが、失ってよい情報まで受信側が決めるわけではない。
インターネット史
ファイルシステム切替を越えて残ったログイン：FTP SMNT が認証主体と名前空間を分けた理由
ログインが続いているなら、見えているファイルの世界も同じだと思いたくなる。FTP の`SMNT`は、その直感を仕様の上で否定した。利用者、課金情報、転送条件を保ったまま、名前を解釈するファイルシステム構造だけを切り替えられたからである。
記事
LACNIC の FORT は ASPA を検証できる。しかしルーター向け経路の初期値はバージョン0だ
LACNIC は ASPA 情報をルーターへ渡せるバリデータを発表した。同じリリースでは、その経路を開く設定値が初期状態で0になっている。能力を実装したこと、能力を有効にしたこと、経路選択を変えたことは、それぞれ別の事実である。
インターネット史
メールボックスより先に届こうとしたメッセージ：SMTP が端末配送を手放した理由
初期の SMTP には、メールボックスへ預けるだけではない選択肢があった。利用中の端末へ直接表示する、端末が使えなければメールボックスへ回す、あるいは両方へ届ける。人が「いま接続中で、割り込みを受け入れている」という刹那的な状態を転送契約に含めた設計は、やがて互換機能の隅へ退いた。その経緯は、保管責任と即時の注意が別物である理由をよく示している。
インターネット史
正しいパスワードの後に残った第三の問い
`PASS`が受け入れられても、FTP のログインが終わるとは限らなかった。サーバーは`230`ではなく`332`を返し、利用者名ともパスワードとも別の`ACCT`を要求できた。その一行は、本人確認と、その作業をどのローカルな勘定・権限文脈に置くかが別の決定だった時代を映している。
インターネット史
同じ接続に二つの上限があった
障害解析の画面に「MSS 1460」と表示されると、接続がその値に合意したように見える。ところが反対向きの SYN には 1200 が入っていることがある。これは交渉の失敗ではない。二つの値は別々の受信者が、自分へ向かうデータについて出した上限であり、同じ問いへの競合する答えではなかった。
インターネット史
名前を変えてはならなかった投稿――NNTP が失われた最終応答を封じ込めた方法
本文も終端のピリオド行もサーバーへ届いた。その直後に回線が切れれば、サーバーが `240` を返していても投稿側には見えない。閲覧画面で検索して見つからなくても、審査待ちかもしれない。NNTP が守ったのは一回実行の幻想ではなく、再試行でも同じ Message-ID を使うという同一性だった。
IETF
サーバーは最初のノックで全額を払わない：TCP の SYN フラッド防衛
TCP の待受サーバーは、見知らぬ相手が扉を叩いた瞬間にメモリーを差し出していた。RFC 4987が扱うのは、相手が応答を受け取った証拠を返すまで、その支出を遅らせる設計である。
インターネット史
片側が話すのをやめたあとに残る仕事
アプリケーションの送信が片方向になっても、接続の仕事まで片方向になるわけではない。DCCP では、データを受け取り続ける側が、その受信状況を送り手に知らせなければならない。そして送り手には、その知らせを受け取ったと、ときどき返す仕事が残った。目的は失われたデータを取り戻すことではなく、相手が古い記録を手放せるようにすることだった。
インターネット史
安全になる前に戻ってきた書き込み
サーバーは成功を返した。それでもクライアントは送信済みのバッファーを捨てられない。データは、次の再起動で消えるメモリーにしか存在しないかもしれなかった。NFS version 3 はこの時間差を隠さず、永続化の段階、サーバーの世代、再送の責任を別々の証拠にした。
IETF
最初のシーケンス番号は時計だけでは足りなかった：TCP ISN の防衛
TCP 接続は、ひとつの番号を公開するところから始まる。その番号が全体で共通する時計を素直に追っていれば、接続を観測できない攻撃者でも、相手になりすますだけの状態を予測できた。
IETF
リセットは証明を求められた：TCP Challenge ACK の防衛線
偽造 RST はかつて、動き続ける受信ウィンドウのどこかに入るだけでよかった。RFC 5961は、長時間接続を消す制御フラグに、相手の現在状態を反映しているという証明を求めた。
インターネット史
何も確保しないかもしれない予約
FTP クライアントは、これから送るファイルの大きさを先に告げることができた。ところがサーバーの肯定応答 `202` は、要求された領域を確保したという意味ではない。「このサイトでは、その命令は余分なので実装していない」と伝えながら、処理を続けさせる応答だった。互換性のための成功と、保存容量の証明は、最初から別のものだった。