トピック
ソフトウェアライフサイクルとベンダーロックイン
「トピックの観点から見たソフトウェアライフサイクルとベンダーロックイントピックは、特定のテーマ、シグナル、または監視すべき話題を共有する記事を結びつけます。このページは、関連報道、公開情報源、市場関係者、インフラへの影響をたどる豊かな道筋を提供し、企業動向、政策決定、地域的影響、運用リスクにわたってそのトピックがなぜ重要なのかを理解するための十分な文脈を与えます。単なる記事リストにとどまらず、読者は繰り返し現れるシグナル、影響を受ける組織、公開証拠、市場背景、サービス継続性、調達、競争、コンプライアンス、戦略計画といった背景を比較できます。このページでは、トピックの対象範囲、関係するインフラ事業者や政策、報道内容を裏付ける証拠、そして通信事業者、顧客、投資家、政策関係者にとってそのテーマがなぜ重要なのかを説明します。」
インターネット史
標準は複合オブジェクトを知っていた。段落は profile が選んだ――RFC 1197
「変換なし」という記録ほど、文書交換では誤解を招きやすい。1998年の ODA 用 MIME 規則は、データ本体を変換しないと記した。それでも profile、document class、受信側の実装、製品内の対応表は必要だった。RFC 1197 は、その理由を8年前に一つの単語――paragraph――で示していた。
ケースファイル
グループは新しいエポックに達した。だが意思決定には達していない：RFC 9420における MLS の境界
暗号学的なグループは、きわめて正確に新しい状態へ移れる。Commit が処理され、鍵が更新され、GroupContext が変わり、新しいエポックが存在する。しかし、その技術的事実だけから、関係者が読んだ、理解した、同意した、権限を行使した、あるいは業務上の行為を完了したとは言えない。RFC 9420 の強みは、前者を確かなものにしながら、後者まで主張しない点にある。
ケースファイル
スケジュールは有効だった。変更は実行されていなかった：RFC 9922
定例保守の行に `enabled`、次回時刻、前回の発生時刻、増えたカウンタが並んでいる。その表示は時間規則については有益である。しかし、誰かが変更を許可し、呼び出し、対象で完了させ、結果を確認したという証明にはならない。
インターネット史
中継点は識別子を承認した。宛先はまだストリームを受け入れていなかった――RFC 1190
1990年の ST-II では、経路の途中から肯定的な返事が届いても、まだ送信を始めてはならなかった。隣の agent は制御メッセージを受け取り、転送用の短い識別子を使えると答え、資源を確保していたかもしれない。しかし宛先 application の参加判断は、そのさらに先に残っていた。RFC 1190 は「途中まで進んだ」と「相手が受け入れた」を wire protocol の別イベントにした。
ケースファイル
主張は選択的に開示された。それでも記録は完全ではない：RFC 9901と「ないこと」の証拠
必要な情報だけを見せることは、欠落を隠す不正ではなく、RFC 9901 が意図して支えるプライバシーの機能である。ただし、表示された主張が検証できることと、表示されなかった情報が不要だと分かることは別である。
ケースファイル
時刻印はペイロードに届いた。署名の時刻ではない：RFC 9921
保護された COSE ヘッダーに RFC 3161 のタイムスタンプトークンが入っていても、そのトークンが発行された時点で COSE 署名が存在したことにはならない。RFC 9921 は、ペイロードの存在時刻と署名の存在時刻を混同しないために二つの構成を分けている。
インターネット史
ホスト名は有効だった。それでも悪い名前だった――RFC 1178
仕様に通る文字列と、現場で迷わず使える名前は同じではない。RFC 1123 は1989年、数字で始まるホスト名を受け入れるようソフトウェアに求めた。ところが翌年の RFC 1178 は、管理者にはその命名を避けるよう勧めた。前者は適合実装の入口を広げ、後者は旧いプログラム、ローカルな補完規則、人間の会話が同じ文字列を同じ意味で扱うとは限らない現実を記録した。
ケースファイル
フィールドは解析された。リクエストを決めたわけではない：RFC 9651の意味論上の境界
HTTP フィールドが整った形で読めることと、そのフィールドが行為を決められることは別である。RFC 9651はこの区別を壊さないための共通文法を与える。形をそろえる規格であって、意味や権限を自動的に与える規格ではない。
ケースファイル
クライアントは辞書を持っていた。応答を得たわけではない：RFC 9842
RFC 9842 は、HTTP の圧縮辞書を後続の応答に使えるようにするための限定的な協調方式である。辞書の保持は、サーバーが特定の応答を選んだこと、内容が現在も有効であること、あるいは誰かがその内容に基づいて行動してよいことを示さない。
ケースファイル
連盟はメンバーに署名した。しかしセッションを許可したのではない：RFC 9932 の MATF 境界
鍵のローテーションを「完了」と呼ぶ瞬間には、実際にはいくつもの未確認の段階が残っている。新しい pin を含むメタデータは公開されたかもしれない。だが各メンバーは更新したのか、接続側はそれを事前読込みしたのか、相手は新しい証明書を提示したのか、そしてアプリケーションはその相手にこの操作を許したのか。RFC 9932 は、この連鎖を一つの承認印にしないための材料を与える。
インターネット史
要件は確定した。ホストはまだ設定されていない――RFC 1127
仕様書は大文字の MUST で議論を終えられる。しかし、その単語が機械室に入り、稼働中の値を選ぶことはない。1989年の Host Requirements は、相互運用の経験を義務・推奨・選択肢へと整理した。RFC 1127 が残したのは、その表の背後にある境界である。合意はどこまで強かったのか。何が未決のまま残り、適合する実装と実際の設定・動作・結果との間には何が必要なのか。
ケースファイル
UDP のユーザーデータは保護された。だがオプションはそうではない：RFC 9868
RFC 9868 は UDP にトランスポート・オプションの領域を設ける。それは DTLS が保護する UDP ユーザーデータの一部になるわけではなく、オプションの検査、送信、保護済みペイロードをもって、オプション処理や結果の証拠にはできない。
ケースファイル
クライアントはバイトを送った。しかし新しいプロトコルはまだ受け入れていなかった：RFC 9931 の楽観的遷移の境界
接続上で「次に何を送りたいか」と「相手が次に何を解釈するか」は、同じ時点に決まらない。RFC 9931 が守ろうとしているのはこのずれである。HTTP/1.1 のクライアントは遷移を要求し、応答を待たずに次のプロトコルらしいデータを送りたくなる。しかし応答前のそのデータには、期待した意味はまだ与えられていない。
インターネット史
行は完成した。だが命令はまだ走っていない――RFC 1116と Telnet Linemode
遠い計算機を使っているのに、文字は手元ですぐ現れ、削除も待たずに効く。1989年の Linemode は、この感覚をネットワーク往復から切り離した。入力行をクライアントで整えてから送れば、遅延とパケット数は減る。しかし、手元で完成した行は、遠端で完了した処理の証明にはならない。
ケースファイル
カーソルが続けたのは一覧であって、権限ではない：RFC 9865
RFC 9865 は、すでにカーソルを使う基盤のために SCIM のページ送りを整える。次ページを指す値を、持ち運べるアクセス権や確定済みの判断へ変える仕様ではない。
ケースファイル
アルゴリズムは台帳に載った。それでもシステムは移行していない：RFC 9958 と暗号アジリティ
暗号の所在を列挙することと、現実の通信を移し替えることは別の仕事である。RFC 9958 は前者を急ぐ理由にした。後者が済んだという判定まで、台帳に委ねたわけではない。
インターネット史
NASA の資源では動いた。それでも Internet には安全でなかった――RFC 1106と RFC 1110
実験装置の中では、古いパケットが長く残らないことがある。Internet では、遅延し、順序を入れ替え、複製されたパケットが後から戻り得る。RFC 1106の成功と RFC 1110の反論の間にあったのは、実装の有無ではなく、許される世界の広さだった。
ケースファイル
色は PCEP に届いた。サービスには届いていない：RFC 9863
RFC 9863 は TE パスに色属性を運ぶための PCEP 拡張である。色が通ったことは、サービスが選ばれ、低遅延が実現され、利用者に結果が届いたことを意味しない。
ケースファイル
UUID は並んだ。出来事は証明されていない：RFC 9562、識別子の順序と時刻証拠の境界
障害後の復旧会議で、担当者はイベント一覧を UUIDv7 で昇順に並べた。小さい値には「権限変更を要求」、大きい値には「変更を反映」とある。説明は滑らかだ。しかし、前者は認可判定より前に採番され、後者は送信箱から再送された通知かもしれない。二つの生成元では、時刻補正の履歴も違うかもしれない。並びは調査の入口になる。出来事の証明書にはならない。
ケースファイル
DNS は合図を受け取った。それでも親は判断しなければならない：RFC 9859の委任境界
RFC 9859 は委任保守の確認を早める仕組みである。通知を親側の承認に、応答を DS 公開の証拠に変える仕組みではない。