主要领域
互联网基础设施
在 主要领域 分类下,互联网基础设施 按主要领域组织行业情报,帮助读者聚焦互联网基础设施、治理、连接市场或数字资本等方向。页面汇集了相关文章、公开证据、机构、公司、人物、区域关联、运营依赖和市场环境,这些内容可能分散在多个分类页面中。页面解释了该领域、可能的行为主体类型、市场或治理背景,以及读者比较信号时应使用的参考来源。运营商、分析师和治理领域的读者可以观察同一领域如何在事件、档案、市场变化、公开来源证据、区域依赖和更长周期的基础设施决策中随时间显现。

互联网历史
接口已被判定为下线,虚电路却未必全都失败:RFC 1315
监控最危险的捷径,是把一个容易读出的状态词扩大成整张网络的结论。RFC 1315 在 1992 年为 Frame Relay DTE 定义 MIB 时,把这一界线写进了对象结构:一个物理接口可承载多条虚电路;管理代理可以在指定轮询窗口内统计未获响应的状态查询,并据阈值将接口判为 down。这个判断有价值,但它描述的是接口层的本地管理状态,不是每条虚电路、远端邻居、数据帧或业务结果的总判决。

互联网历史
Trap 已经定义,事件却尚未被观察:RFC 1215
网络管理系统里最像“事实”的东西,有时只是一张空表。企业标识、变量顺序、文字含义和编号都能预先写好,界面也能提前准备好告警颜色,但现实世界可能还没有发生任何事件。RFC 1215 在 1991 年解决了 Trap 如何定义的问题,也恰好暴露了定义、识别、发送、接收与处置之间的证据边界。

互联网历史
地址退信了,主列表里却可能根本没有它:RFC 1211
一封退信点名了某个地址,管理员却在主列表里搜不到它。RFC 1211 记录的并不是一次离奇故障,而是大型邮件列表的常见结构:主列表只保存一个分发别名,真正的成员藏在另一家机构维护的子列表中。退信、路径线索、成员记录、变更请求与实际删除,分别掌握在不同系统和不同人手里。

互联网历史
服务器回了加号,消息却未必被看见:RFC 1312
在消息系统里,最容易被放大的常常是一枚看似明确的确认符号。RFC 1312 的 TCP 服务用 `+` 表示成功,却没有让这枚符号替人作证。1992 年的文档明确说,它可能只表示 Message Send 服务器已经成功调用本地消息投递服务。显示窗口、终端前是否有人、内容是否被读到,仍是另一些没有被该确认覆盖的事实。

互联网历史
路由请求了电路,并不等于电路已就绪:RFC 1306
一条路由有时不仅决定转发方向。RFC 1306 记录的 1992 年实验中,内核完成路由查找后还可以向外部交换控制器发送请求,尝试建立按需的 T3 电路。这个动作很重要,但它绝不是电路本身。报告把查找、请求、建立、可传输和已经传输分开,因而没有让最先出现的一条控制消息冒充最后才可能出现的网络结果。
案例档案
算法已宣告,路径仍待计算:RFC 9502 的 IP Flex-Algorithm 边界
在变更会议上,“某前缀已经挂到算法 129”听起来像结论。它其实最多是一个需要继续拆开的起点。RFC 9502 让 IPv4 与 IPv6 前缀的可达性能够同 IGP Flexible Algorithm 关联,却没有把这种关联变成“流量必经此路”或“服务目标已经实现”的证明。定义是否一致、节点是否参与、路径是否算出、转发表是否安装、业务报文是否真的抵达,仍是五件不同的事。

互联网历史
服务器返回了 250,账号却可能不存在:RFC 1204
如果日志里只剩下一行“250 成功”,RFC 1204 的关键事实就已经丢了。1991 年这份实验性协议要求服务器在用户名格式正确时继续对话,即使它根本不认识这个名字。第一处肯定答复是为了隐藏账号清单;密码核验、正文接收、本地入队和最终投递各有自己的证据。
案例档案
一个 Bundle 已被接收,这并不等于有人承担了保管:RFC 9171 的保证边界
在延迟容忍网络里,“已接收”很容易被写成结论。一个节点有了副本,状态报告可能这样说,仪表板可能亮起绿色。但这并不证明谁已承担持续保管义务,不证明目的应用已经处理载荷,更不证明载荷所代表的工作已经完成。RFC 9171 的可贵之处,正是它不把这些不同的事实压缩成一个词。
案例档案
前缀已登记,路由仍只是本地承诺:RFC 9926
低功耗网络中的 IPv6 前缀被登记到邻居路由器,是一项有价值的路由事实;它不是该前缀的公开权属凭证,也不是全路径、报文送达或后端服务成功的证明。

互联网历史
标准认识“复合逻辑对象”,却没有替应用选定段落:RFC 1197
一份文件可以逐字节完整抵达,也可以通过格式检查,却仍然没有成为收件人手中的同一份文档。RFC 1197 在 1990 年把原因压缩成两页:ODA 给出了足够宽的抽象架构,实际互换还要另选应用配置,并把配置里的实体逐一接到每个编辑系统自己的对象上。
案例档案
群组进入了新 epoch,却并未作出决策:RFC 9420 的 MLS 边界
一个加密群组可以极其精确地进入新状态:某个 Commit 已被处理,密钥已推进,组上下文已更新,新的 epoch 已出现。但这些技术事实本身,并不能说明相关的人已经阅读、理解、同意、授权或执行了某项决定。RFC 9420 的价值恰恰在于它清楚界定了前者,而没有借此宣称后者。

互联网历史
一跳批准了标识符,目标却还没有接受流:RFC 1190
一台 ST-II 中间节点收到 `CONNECT` 后,可以先为本地转发批准一个短标识符、预留能拿到的资源,再把请求送向下一跳。此时控制面已经做了不少工作,目标应用却可能连提案都没看到。RFC 1190 把这段落差写进消息次序:路径上的处理是路径上的事实,不能代替终点掌握的同意权。
案例档案
这项声明被选择性披露,但档案并不完整:RFC 9901 与“缺失”的证据边界
少披露一项信息,可以是正当的隐私设计;它不是对未披露信息作出否定回答。RFC 9901 让持有人能够向验证方展示经发行方支持的特定声明,同时保留其他声明。它验证已经展示的内容,没有把可见部分变成完整档案。
案例档案
时间戳碰到了载荷,却没有给签名定时:RFC 9921
把 RFC 3161 时间戳令牌放进受保护的 COSE 头,并不等于 COSE 签名在该时间戳签发时已经存在。RFC 9921 要求验证方先分清令牌覆盖的是载荷还是签名字节,再谈撤销前的历史有效性。

互联网历史
主机名合法,却仍是个坏名字:RFC 1178
1989 年,RFC 1123 要求主机软件接受以数字开头的名称。不到一年,RFC 1178 却提醒管理员别这样命名。两份文件并不冲突:前者划定合规软件必须识别的语法,后者面对的是人、旧程序和各自不同的本地环境。字符串通过了规则,只说明它能进入系统;它会被当成名称还是地址、补全到哪个域、最终指向谁,仍是另一组问题。
案例档案
字段被解析,并未决定请求:RFC 9651 的语义边界
HTTP 字段变得可机器读取,并不等于它获得了命令系统的资格。RFC 9651 的价值在于把这种界限划得很清楚:它统一数据形状,却把含义与后果留给真正定义该字段、执行该请求的地方。
案例档案
客户端已有字典,但尚未拥有响应:RFC 9842
RFC 9842 让 HTTP 客户端与服务器可以围绕压缩字典协作。它证明的是一项受限的编码条件,而不是服务器已经给出某个响应、缓存已经代表当前业务状态,或某项行动已经获得授权。
案例档案
联盟签了成员,不等于服务已授权会话:RFC 9932 的 MATF 边界
一份由联盟签名的元数据可以帮助系统认出对端。它不能替资源所有者答应一次请求。RFC 9932 的价值不在于把“可信”做成万能标签,而在于把元数据、TLS 对端校验和应用层决定安排在可追溯的先后关系里。

互联网历史
要求已经写定,主机却还没有配置:RFC 1127
规范可以用大写的 MUST 结束一场争论,却不能替机房里的主机拨动开关。1989 年的主机要求工作把互操作经验写成义务、建议和选项;RFC 1127 则留下了规范正文不容易容纳的部分:共识有多牢,分歧为何保留,以及一份合规实现与实际配置、运行状态和最终结果之间还有多远。

互联网历史
已知 DLCI 还不是可用邻居:RFC 1293 的 InARP 边界
Frame Relay 网络可以宣告一条虚电路并给出 DLCI;本地站点仍可能不知道线路另一端的协议地址。RFC 1293 的 InARP 不把 DLCI 当成对端身份,也不从线路存在推出一个地址。它把已知的硬件地址变成一次定向提问:目标协议地址字段为零,询问已经知道的那一端;对端可以答复,也可以沉默;本地随后至多保留一条会老化或失效的映射。
