主题
软件生命周期与供应商锁定
在主题维度下，软件生命周期与供应商锁定主题情报把围绕同一具体议题、信号焦点或监测主题的 BTW.MEDIA 文章串联起来。页面为读者提供更完整的阅读路径，涵盖相关报道、证据来源、市场参与者和基础设施影响，并给出足够背景，帮助理解该主题为何在公司动态、治理决策、区域影响和运营风险中值得关注。读者可以比较反复出现的信号、受影响组织、公开证据、市场背景、服务连续性、采购、竞争、合规和战略规划等问题，而不是只看一份单薄的相关文章列表。页面还会说明该主题涵盖什么、涉及哪些基础设施参与方或政策、有哪些证据支撑报道，以及该主题对运营商、客户、投资者和关注政策的读者为何重要。
互联网历史
连接断了，会话没有：RTSP 如何把控制状态留在 TCP 之外
承载 PLAY 的 TCP 连接可以消失，媒体服务器却仍记得已经建立的播放上下文。RTSP 为这份临时记忆分配了独立标识，也明确限制了它的权力：它不是资源名称，不是媒体通路，更不是操作者身份。
案例档案
Header 请求流式转发，Proxy 仍掌握放行：RFC 10036 与 HTTP 消息释放权
源站可以立即写出第一条事件，连接也可以始终处于健康状态，读者却可能一个字节都看不到。中间某一层若坚持等到完整正文再转发，长连接就会把“稍后”变成“永远”。`Incremental: ?1` 让发送者能够明确表达需求，但它不会远程接管沿途每一个 buffer。
互联网历史
不懂就必须拒绝：X.509 关键扩展如何给证书变更划界
新规则写进证书时，旧软件可能连它的名字都没见过。X.509 v3 没有假装所有接收者会同步升级，而是把兼容性选择一并签进证书：有些未知信息可以略过，有些信息若不能理解，验证就不得成功。
案例档案
服务器分配了 Locator，网络还没有接纳路由：RFC 10038 与 SRv6 可达性的权责边界
一条 DHCPv6 Reply 可以把“谁获得哪段 SRv6 Locator、结构怎样、何时到期”写得很清楚。但这条消息并没有穿过路由策略，也没有替远端设备写入 FIB，更不会在终端自动生成预期的 SID 行为。RFC 10038 的治理价值，正在于把分配说清楚，同时不把分配夸大成可达。
互联网历史
一个 XID，两次执行：RPC 为什么还需要编号之外的记忆
远程调用超时之后，客户端重发同一个编号，并不能把已经丢失的历史一起送回服务器。ONC RPC 解决了“这份回复属于哪次调用”，NFS 的演进才说明“这项操作是否已经执行过”需要付出怎样的状态成本。
案例档案
令牌对上了，写入权仍未成立：WebDAV 锁令牌的权限边界
一次成功续锁、一个完全相同的令牌，紧接着却是 423、412 或 403。三种拒绝看似都在说“锁有问题”，实际分别指向缺少锁证据、条件不成立和权限不足。把它们压成一个红灯，系统就会失去解释自己决策的能力。
全球云服务趋势
Veeva 的 Salesforce CRM 设有单客户 150% 席位上限，并将在 2030 年退出
这套旧 CRM 既没有立即停摆，也不再拥有正常扩张的自由。Veeva 与 Salesforce 的协议把它改造成一条逐步收窄的迁移通道：新客户不能进入，存量客户只能在各自上限内扩容，而支持终点和最终销售禁令分别落在 2029 年与 2030 年。
案例档案
缓存说自己命中了：Cache-Status 与解释一份响应的权力
Cache-Status 让 HTTP 路径上的缓存用统一格式说明自己怎样处理了一次请求。它把故障现场从猜测推进到可解析的证词，却没有把运行系统对自身行为的陈述变成独立证明。
案例档案
邮件在释放前已经被接受：IETF 邮件迁移中的留存、改写与转交权
一封邮件收到成功响应，不代表它已经进入邮件列表。IETF 新架构里的首次发件人可能先被要求完成挑战；原邮件被另行保存，确认后才重新注入。随后，发件地址可能因 SPF 与 DMARC 被改写，邮件由 IETF 域名签署，再交给集群外的出站虚拟机。9 月 11 日真正需要检验的，不是“系统是否在线”，而是每一步由谁保管、改变并证明这封邮件。
互联网历史
不属于值的字节：XDR 如何让不同机器读懂同一种表示
XDR 最值得记住的，不是某个复杂类型，而是几个必须写入、却不能算进值里的零字节。它们把不同机器拉到同一条四字节刻度上，也把“数据是什么”和“数据怎样摆放”分开了。
案例档案
网络已经变了，决定却尚未最终成立：NETCONF 确认提交与回滚权
NETCONF 的确认提交可以先把候选配置送入运行态，再让计时器、会话或持久令牌决定它能否留下。它防的是远程变更把操作者关在门外，却不能替组织证明授权、持久化、设备应用与全网结果。
互联网历史
这个号码属于操作，不属于报文：LDAP 如何让多路回应交错而不混淆
LDAP 没有为每一条返回结果另造身份，而是让客户端选择一个整数，并让同一操作产生的全部回应都带着它。搜索由此可以连续吐出条目，其他请求也能插入其间；但编号只能指出“这是谁的状态”，不能证明工作怎样结束。
互联网历史
七个字符改写了匹配规则：SIP branch 为什么以 z9hG4bK 开头
SIP 报文里的 `z9hG4bK` 人人可见，也人人可仿。它的价值不在保密，而在于让接收方知道：眼前这个 Via branch 承诺遵守哪一代事务规则。
案例档案
令牌已经绑定密钥，操作仍未获准：DPoP 与发送方约束的权限边界
DPoP 能让被复制的 OAuth 令牌不再是一张可随处使用的通行证，却不能证明谁正在操纵密钥，也不能替资源服务器决定这个主体此刻是否有权产生所请求的后果。
案例档案
签名验过了，命令仍未获授权：HTTP 消息签名与覆盖范围的权力边界
RFC 9421 能证明一组明确列出的 HTTP 组件没有在语义上被换掉，却不能替业务系统决定签名人有没有权发出这条命令。遗漏的路径、方法、身份与单次使用条件，绝不会因为旁边出现一枚有效签名而自动获得保护。
案例档案
计数器撞上上限，文件名开启新纪元：RPKI 清单与恢复权
一份签名、时间和内容都正确的 RPKI 清单，仍可能因为验证端记住了一个不可能超越的旧序号而永远无法被接受。RFC 9981 给发行方留下了一条狭窄出口：更换清单文件名，开启新的比较纪元，同时保留其余全部新鲜度、位置与完整性证据。
互联网历史
绕路不能同时成为目的地：DNS CNAME 的设计边界
DNS 可以让旧名字通往新目的地，但代价是旧节点必须放弃自己的普通答案。CNAME 把这种限制变成一条可靠规则：缓存这次改道，从目标名重新提问，并把“谁控制别名”与“谁控制终点数据”始终分开。
IETF
Alan DeKok 与把信任交给 TLS 的 RADIUS/1.1
RADIUS/1.1 的关键并不是把旧协议宣布作废，而是把“新规则是否生效”变成每条连接都能回答的问题。Alan DeKok 在 RFC 9765 中回望自己参与过的一次兼容性选择：既然 TLS 已经承担保护职责，RADIUS 数据包为何还要继续携带共享密钥与 MD5 的历史包袱？
互联网历史
拒绝让半份答案冒充事实的那一位：DNS 如何改换运输方式
一个名字可以对应多条记录，可 1987 年普通 DNS 查询的 UDP 信封只有 512 字节。真正保护名字的，并不是把塞得下的部分先交出去，而是一个承认“这次没有装完”的 TC 位：收到它的人必须重新取得完整答案。
互联网历史
Mark Andrews 与那个活得比替代者更久的 DNS 服务器
替代计划可以先被命名，迁移却必须在真实系统里逐项发生。Mark Andrews 在 BIND 10 开发时期继续维护 BIND 9 的经历，揭示了基础设施更难被看见的一面：当机构把资源投向下一代架构时，今天仍在回答查询的系统并不会因此失去安全、发布、测试与支持责任。