主题
软件生命周期与供应商锁定
在主题维度下，软件生命周期与供应商锁定主题情报把围绕同一具体议题、信号焦点或监测主题的 BTW.MEDIA 文章串联起来。页面为读者提供更完整的阅读路径，涵盖相关报道、证据来源、市场参与者和基础设施影响，并给出足够背景，帮助理解该主题为何在公司动态、治理决策、区域影响和运营风险中值得关注。读者可以比较反复出现的信号、受影响组织、公开证据、市场背景、服务连续性、采购、竞争、合规和战略规划等问题，而不是只看一份单薄的相关文章列表。页面还会说明该主题涵盖什么、涉及哪些基础设施参与方或政策、有哪些证据支撑报道，以及该主题对运营商、客户、投资者和关注政策的读者为何重要。
案例档案
签名验过了，命令仍未获授权：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 的经历，揭示了基础设施更难被看见的一面：当机构把资源投向下一代架构时，今天仍在回答查询的系统并不会因此失去安全、发布、测试与支持责任。
北美云服务趋势
Varonis 的 SaaS ARR 中有 1.279 亿美元来自转换层
Varonis 6 月末的 SaaS ARR 为 7.260 亿美元，同比增长 52%。剔除从自托管产品迁入的合同后，余额为 5.981 亿美元，增长 25%。两组数字都成立，但回答的是不同问题。
全球云服务趋势
Cellebrite 的 ARR 增长了 21%，合同储备却在缩小
Cellebrite 以 5.078 亿美元的年度经常性收入结束第二季度，同比增长 21%。但截至六月底，尚未确认为收入的合同金额比去年底少了 3520 万美元，全年目标也被下调。这不是数字互相冲突，而是四本账衡量了四件不同的事。
IETF
Geoff Huston 与主动撤回的 IPv6 默认值
十年间，`/48` 像是一个难题的整洁答案：普通站点究竟该获得多少 IPv6 地址空间？Geoff Huston 参与撰写的文档撤回了这项统一答案，却没有丢掉它原本试图保护的东西。
IETF
Ray Bellis 与那条从连接变成会话的 DNS 通道
一条 TCP 连接可以一直开着，却没有任何一方说明它保存了什么状态。RFC 8490 为 DNS 划出了这条边界：连接属于传输层，会话则是一组双方明确承认的权利、计时器与退出义务。Ray Bellis 与共同作者让“保持在线”不再等同于“可以永久保留状态”。
案例档案
注册源于姓氏，后来的用途另有记录：Nissan Motor v Nissan Computer
法院先后规定过页面上能出现什么、哪些广告必须撤下、哪些批评链接不得禁止，却始终没有把两个域名判给汽车制造商。这不是所有权问题被忽略了，而是证据只支持把注册来源、后来用途和可用救济分开处理。
互联网历史
由接收方决定谁先到
1981 年的邮件事务可以从一句试探开始：`MRSQ ?`。接收方回答 `215 T Text first, please`，意思不是它更喜欢某种排版，而是要求先把整段正文存下来，再逐个给出收件人。发送方可以提议另一种次序，却不能替接收方决定，因为真正要保存的是收件人表还是正文、什么时候能给出失败证据，取决于对端内部怎样递送邮件。SMTP 后来删掉了这场编舞协商，把一条可变状态机固定成今天熟悉的顺序。
互联网历史
发送端没有发送的字节：FTP MODE C 如何从 TYPE 重建填充内容
解码器读到一个有效长度，后面却没有可供重复的样本字节。这不是丢包，也不是文件被截断。FTP 的压缩模式故意把值留在数据流之外：会话此前协商的表示类型，已经决定接收端应当补入空格还是零。
互联网历史
每经一次中继，路径就后退一步
邮件抵达中继 ONE 时，收件命令里的地址不是普通的 `JOE@THREE`，而是 `@ONE,@TWO:JOE@THREE`。ONE 要做一件今天看来反直觉的事：从向前路径最左端删去自己，再把自己写到反向路径的最前端。通往收件人的指令缩短了一段，通往退信责任方的路径却增长了一段。早期 SMTP 把行程写进信封，也让行程在每次交接时改变方向。
互联网历史
必须出现两次的字节：FTP 如何在连续流中写入记录边界
接收程序读到一个全 1 字节，却还不能把它交给文件。它必须等待下一个字节：再来一个全 1，二者还原成一个字面数据；若后面是 1、2 或 3，这一对便分别关闭记录、关闭文件，或同时完成两件事。FTP 没把网络切块误当成文件结构，而是在流里建立了一套可逆语法。
IETF
Ray Bellis 与那台必须转发“未知”的 DNS 代理
一台家庭网关会告诉所有终端：DNS 先交给我。它看起来只是把查询转给上游，却因此站在了新协议功能必经的位置。Ray Bellis 在 RFC 5625 中给这类代理划出的权力边界很窄：可以管理转发、接口和明确的本地策略，但不能把自己不认识的字段，当成 DNS 不允许存在的字段。
互联网历史
缺失的页面不是零页：FTP STRU P 如何在主机之间传递空洞
接收端先看到一个页面，随后又看到索引更靠后的页面，中间位置却没有任何数据穿过网络。FTP 的页结构不要求把它判断为丢包，也不允许随手填成零页：那段沉默可能正是源文件需要保留的结构。
互联网历史
被切开以后仍须随行的指令
一份 IPv4 数据报同时带着两种路径记录：类型 131 的宽松源路由，其类型字节最高位为一；类型 7 的普通记录路由，最高位为零。路由器把数据报切成三片后，零偏移片保留两者，后两片却只带前者。同一数据报由此拥有三份并不等长的首部。这不是损坏，而是一位 Copy 标志指导下的合法派生。
互联网历史
一次尚未发生的重命名：FTP 如何把文件留在 RNFR 与 RNTO 之间
服务器答复了一个肯定的 `350`，监控面板便把重命名标成成功；但此时旧文件名可能一个字节都没有改变。FTP 把一次重命名拆成 `RNFR` 与 `RNTO`，也把“接受来源”与“完成变更”之间那段最容易被日志抹平的状态暴露了出来。
互联网历史
线路没有定义的那个字节
九个八位传输单元沿着 FTP 数据连接抵达，却在文件里只构成两个逻辑单位。因为发送方执行了`TYPE L 36`：每个有意义的单位长 36 位，两个单位合计 72 位，恰好穿过九个线上八位组。线路规定怎样搬运这些位，却没有取得把“字节”永远定义成八位的权力。