主题
软件生命周期与供应商锁定
在主题维度下，软件生命周期与供应商锁定主题情报把围绕同一具体议题、信号焦点或监测主题的 BTW.MEDIA 文章串联起来。页面为读者提供更完整的阅读路径，涵盖相关报道、证据来源、市场参与者和基础设施影响，并给出足够背景，帮助理解该主题为何在公司动态、治理决策、区域影响和运营风险中值得关注。读者可以比较反复出现的信号、受影响组织、公开证据、市场背景、服务连续性、采购、竞争、合规和战略规划等问题，而不是只看一份单薄的相关文章列表。页面还会说明该主题涵盖什么、涉及哪些基础设施参与方或政策、有哪些证据支撑报道，以及该主题对运营商、客户、投资者和关注政策的读者为何重要。
互联网历史
Rob Pike 与那个什么也没有打开的 9P walk
9P 客户端逐段走完一个名字，服务器也返回了预期的全部 qid。路径确实解析成功了，但文件尚未打开，更没有任何字节移动。Rob Pike 参与塑造的命名思想因此给今天的控制系统留下了一个实用原则：一张回执只有在不替别的步骤作证时，才最可信。
案例档案
RFC 9919 的 SHA-1 计数不是退役回执
当一个 OCSP responder 的 SHA-1 请求曲线归零时，运维团队得到的是一个观察点的安静，而不是整个兼容人口已经消失的证明。RFC 9919 给出了迁移方向，也留下了必须由运营者补齐的证据边界。
案例档案
算法标签变了，密钥没有跟随：RFC 9709 的降级证据边界
攻击者未必需要攻破密码算法；只要能改写“该如何解释密文”的标签，就可能把接收端变成猜测明文的工具。RFC 9709 的回答，是让完整算法身份直接参与派生密钥，并要求运营者把解密、泄露与授权分开记录。
互联网历史
标签写着 JPEG，标识链却指向 GIF：RFC 2158 的格式身份裂缝
RFC 2158 只有几页，却留下了一条无法自洽的记录：小节标题、X.400 正文类型和对象标识符都说这是 GIF，MIME Content-Type 却写成了 `image/jpeg`。这不是一个靠“常识”就能抹平的细节，而是一道清晰的证据边界——出版物可以权威地证明纸面上写了什么，却不能单独证明作者本意、运行代码或网关实际输出。
互联网历史
RFC 2070 的分界线：字节负责抵达，字符编号负责保持不变
把同一个数字字符引用写进两份采用不同外部编码的 HTML 文件，它们在传输中会成为不同的字节序列，却应在解析器面前指向同一个字符。RFC 2070 的关键并非笼统地让 HTML “支持 Unicode”，而是明确了责任边界：`charset` 选择从外部八位组进入文档字符的解码方式，HTML 的抽象文档字符集则保持固定。字符抵达以后，解析、双向排版、字体与显示仍各自需要证据。
互联网历史
单向转换不是等价：RFC 2157 要求把返回路径也交出来
附件穿过网关、字节没有报错、文件名看起来也合理，这些都只是不同层级的回执。RFC 2157 给“等价”设了更严格的门槛：一条规则只是映射；只有两条相反方向的映射组合起来，能够无损返回原来的正文部分，才构成等价。封装则承认另一种事实——内容可以被妥善带回原系统，却未必能被中间系统理解。
互联网历史
密码没有上网，能开门的值却留在服务器：RFC 2069 的验证边界
一张安全审计表最容易勾选的项目，是“密码是否以明文传输”。RFC 2069 让这一格第一次可以诚实地填“否”：客户端不再把密码直接交给网络。然而，下一格不能因此写成“服务器没有可冒用的秘密”。服务器保存的 `H(用户名:realm:密码)` 本身就足以生成该 realm 会接受的响应。线路风险缩小了，保管责任没有消失，只是换了一种不易被名字看见的形态。
互联网历史
软件具备能力，网关实例仍须举证：RFC 2156 的符合性边界
一套邮件网关软件可以包含 MIXER 所要求的全部功能，真正承载邮件的那台实例却可能只按局部场景配置。RFC 2156 把符合性放在部署实例上；分发列表一旦把局部通道扩展成跨管理域路径，产品能力说明便不能替代运行证据。
互联网历史
Ned Freed 与必须先拼回去、再保持不信任的文件名
一串看似普通的附件文件名，可能分散在三个 MIME 参数里，而且到达顺序并不可靠。RFC 2231 解决的是“怎样把同一个值完整还原”，不是“还原后的值能否控制文件系统”。
案例档案
注册表标出了版本，却没有包办含义：RFC 9713
RFC 9713 只给 IANA 表格增加了一列，却让一个常被忽略的边界变得清晰：一个编号可以已经分配、适用于 BPv7，而且不会与公共分配空间冲突，但这些事实仍不能证明接收方理解其内容、接受发送方的私有约定，或有权据此采取行动。
互联网历史
抓到 HTTP/1.1，只能证明这一跳是谁在说话：RFC 2068 的版本边界
一份报文抓包在首行显示 `HTTP/1.1`，最容易诱发的误读，是把这几个字符当成整条路径的履历：客户端、代理、源站仿佛都说过同一种协议，也都执行过 HTTP/1.1 的能力。RFC 2068 给出的含义更窄。版本号属于当前发送者和当前一跳；它声明报文格式与后续通信能力，而不是本次使用过哪些功能，更不是端到端结果收据。
互联网历史
屏幕上的地址很清楚，但它不是线上地址：RFC 2155 的证据边界
RFC 2155 给 APPN 管理站提供了便于人阅读的数据链路地址，却明确要求它只用于显示。真正进入 DLC 报头的字节属于另一套证据。这个看似细小的界线，正好解释了为什么“字段有值”“表里有行”“节点名眼熟”都不能单独证明当前的线上身份。
互联网历史
RFC 2067：标准靠删掉三种合法包形态向前走
1997 年的 IP over HIPPI 没有靠增加能力晋级，反而靠删除自由度变得更可靠。RFC 1374 曾允许首个短 burst、D1 填充和非零 D2 offset；RFC 2067 以“在用实现无人采用”为依据，把三者排除在共同包格式之外。与此同时，它只对单台合规交换机或简单双向点对点链路作出互操作承诺。运行代码决定删什么，拓扑边界决定能承诺到哪里。
互联网历史
签名能指出是谁说的，却不能证明链路真的存在：RFC 2154
RFC 2154 让 OSPF 的每条 LSA 带着来源证明穿过整个泛洪路径。中间路由器不能悄悄改写已覆盖的字节，但起源路由器仍可能把错误度量、已经断开的链路或根本不存在的 stub 网段签得完全正确。
互联网历史
Ward Christensen 与让端点保持自由的 128 字节约定
XMODEM 的历史价值不在于功能齐全，而在于 Ward Christensen 知道什么不该写进公共协议：线路上只保留让两台机器恢复共同状态的最低规则，拨号、文件名、存储、界面与升级则留在端点。
北美区域 ISP 趋势
FirstLight 将 VETRO 定为网络记录系统，现场事实仍须持续对账
FirstLight 表示，向 VETRO 的迁移已经完成，后者现为官方网络记录系统。但迁移完成只是起点：施工变更、业务订单、容量承诺与例外审批能否不断回写，决定了中央地图能否持续反映实际建设和销售中的网络。
互联网历史
RFC 2066：字符集本来就对，接收端仍必须回话
Telnet 原有一条防循环纪律：若对方请求的模式已经生效，就不要继续确认。RFC 2066 却为字符集子协商划出一个重要例外。即使接收端已经使用请求列表中的字符集，也必须发出 `ACCEPTED`；否则，请求方只能在沉默中等待，再用超时猜测结果。双方同时请求时，协议又让服务器拒绝、客户端回答。它用显式回执和角色不对称，把字符集切换变成可终止的状态机。
互联网历史
编号不撞车，不等于机制能互通：RFC 2153
RFC 2153 把专有 PPP 扩展放进统一外壳：Code 或 Type 为 0，再带 OUI、Kind 与厂商自定义值。它解决的是公共编号冲突，不负责把私有含义变成共同知识，更不把“收到”自动升级为“理解、获准、接受和互通”。
互联网历史
文字看得懂，网关却仍有选择：RFC 2152 与 UTF-7 的保存边界
1997 年的 UTF-7 让邮件里的 ASCII 部分继续裸露可读，同时把其他 Unicode 量送进七位安全的移位通道。这个设计解决了运输问题，却没有签发保存证明：标点可以走不同的合法路径，移位序列不能越过换行，解码器还能在丢失原始表示之后交付同一串字符。
互联网历史
服务器不再说，客户端仍要听懂：RFC 2062 的兼容方向
1996 年 12 月，IMAP 把一个常被迁移计划混淆的问题拆开了：停止生成旧语法，不等于立刻丢掉识别旧语法的能力。RFC 2062 让新实现退出过时表达，同时为尚未升级的对端保留有限、可收缩的接收兼容。