主要领域
基础设施
在 主要领域 分类下，基础设施 按主要领域组织行业情报，帮助读者聚焦互联网基础设施、治理、连接市场或数字资本等方向。页面汇集了相关文章、公开证据、机构、公司、人物、区域关联、运营依赖和市场环境，这些内容可能分散在多个分类页面中。页面解释了该领域、可能的行为主体类型、市场或治理背景，以及读者比较信号时应使用的参考来源。运营商、分析师和治理领域的读者可以观察同一领域如何在事件、档案、市场变化、公开来源证据、区域依赖和更长周期的基础设施决策中随时间显现。
互联网历史
模型能描述规则，却把结果留给设备：RFC 3060
RFC 3060 为策略管理系统提供了共同词汇：组、规则、条件、动作，以及它们之间的关系。它没有为所有路由器规定同一个解释器。规则何时适用可以写进模型，动作先后也可以标为强制或建议；但把这些字段变成决定的算法仍由具体实现承担。这不是读者从空白处推出来的漏洞，RFC 本身就把它划成设计边界。
互联网历史
呼叫控制迁到 IP，D 信道仍留在原处：RFC 3057
RFC 3057 并没有把 ISDN 线路搬进互联网。它只移动了一个边界：信令网关仍负责终结 Q.921，而 IUA 通过 SCTP 把上层信令原语送到远端的呼叫控制进程。应用服务器进程发生故障时，信令可以切换到备用进程；但标准没有保证正在建立中的每一通呼叫都能延续。
互联网历史
计数器说通话成功了，却不知道有没有人听见：RFC 3055
2001 年，PINT 工作组把“互联网发起、电话网执行”的业务变成了一组可查询的运行数据。RFC 3055 能按业务、时间、客户端、用户和网关统计接收、成功与断开；它也留下了一条更重要的边界：服务器能够记下一次“成功”，却未必看见电话另一端的人、传真纸或扬声器。
互联网历史
扩展到 14 kHz，也保留 16 kHz 互通路径：RFC 5577
RFC 5577 扩展了 G.722.1 的音频配置，并加入更快的采样时钟。它更值得注意的迁移安排却很克制：当旧终端仍然重要时，继续提供 16 kHz 配置。
互联网历史
电话给部件起了名字，控制器仍要追问里面有什么：RFC 3054
RFC 3054 为互联网电话的显示屏、按键、听筒、扬声器和媒体流建立了一套共同词汇。IPPhone profile 让远端控制器从已知模型出发，不必面对一组任意对象再猜用途。这条捷径减少了推断，却没有把 profile 声明、审计结果、控制命令、RTP 数据包和人耳听到的声音变成同一件事。
互联网历史
Root DSE 可以报出厂商，却不能把厂牌当作功能协商：RFC 3045
LDAP 服务器可以告诉客户端软件由谁实现、自己报告了哪个版本。这对运维人员排查异常有用，却不是功能清单。RFC 3045 把界线写得很清楚：厂商标签可以提供线索，但不能证明服务器支持什么。
互联网历史
ISSN 长存，URL 会变：RFC 3044 给解析器装上“巡检员”
2001 年，国际 ISSN 中心展示了如何把人们熟悉的连续出版物编号写进 URN。难点并非印出编号，而是如何维护从编号到期刊现行网址之间的路径。RFC 3044 说得很清楚：标识符可以持久，URL 却未必；所以它还需要一套持续巡检机制。
互联网历史
经纪人下达了隧道订单，真正承载它的却是另一台机器：RFC 3053
RFC 3053 把早期 IPv6 接入中一项繁琐工作包装成服务：注册、提交 IPv4 端点、取得配置，然后连接。但这套架构也清楚划出便利性的边界。Tunnel Broker 负责准入、分配和下令；Tunnel Server 负责终结隧道；用户还要在本机应用配置；底层网络还要真的把数据包送过去。
互联网历史
全球名称与单一权威解析器：RFC 3043 的承诺及其边界
2001 年 1 月，Network Solutions 提出一种面向个人与组织的持久互联网名称。RFC 3043 让这一引用可以跨应用携带，却在注册模板中把权威解释交给该公司的解析器。这里的区别至今仍重要：名称可以长期存在，但解析它的权力未必也能随之迁移。
互联网历史
标准推荐了 LDP，却没有证明协议正在运行：RFC 3037
RFC 3037 建议在沿普通目的路由转发 MPLS 的设备上实现 LDP。这个建议回答“协议适合做什么”，并不回答“哪台设备已经打开它”。从代码存在到报文通过，中间还有启用、发现、TCP、协商、绑定和硬件表项，每一步都需要自己的证据。
互联网历史
两个重复 ACK 可以带出新数据，却不能扩大拥塞窗口：RFC 3042
设想发送端的拥塞窗口只有三个报文段，其中一个丢失。接收端最多只能为后续数据返回两个重复确认（ACK），达不到快速重传所需的三个。2001 年，RFC 3042 提出一种克制的补充办法：发送端可在最初两个重复 ACK 到达时发送新数据，但不能因此增大拥塞窗口。
互联网历史
ATM 标签在每跳改变；LDP 需要两端共享的 VCID
一条 ATM 电路可以持续传送信元，而下一个交换机把 VPI/VCI 换成另一组本地值。RFC 3038 因而把逐跳标签与邻接 LDP 节点共同认可的虚连接身份分开，让它们先对上同一条电路，再交换 MPLS 标签映射。
互联网历史
核心交换机不会递减 TTL，于是入口先付掉整段跳数：RFC 3034
Frame Relay 交换机能够高速替换 DLCI，却通常没有逐包递减 TTL 的硬件能力。RFC 3034 没把这些跳点当作不存在，而是把 MPLS 的跳数核算移到非 TTL 段边界：控制面提供长度，入口执行扣减，真实数据路径仍须另行验证。
互联网历史
LDP 留下了完整前缀，却删去了主机地址 FEC
标准可以删掉一种表达方式，而不必删掉它看似专属的能力。RFC 3036 曾把完整地址前缀与 Host Address FEC 视为两种语义不同的东西；到了 2007 年的修订版，后者因“没有任何实现使用”而退出，完整长度的前缀仍然保留。
互联网历史
标识符说出了会话是谁，却没有搬动它：RFC 3033
在 ATM 信令里写入完整的 IPv4 五元组，只能让对端知道“正在谈哪一个会话”。它不等于新虚电路已经建立，也不等于 IP 层已经把流量迁过去。RFC 3033 的历史价值，正在于它把命名能力做得精确，却没有把命名伪装成执行结果。
互联网历史
服务器公布了能力，认证却改变了答案：RFC 2449
POP3 客户端在尚不知道连接者是谁时，先问服务器能做什么。此时的回答可能刻意保守；用户通过认证后，服务器才能给出更贴合该账户的结果。若会话随后建立完整性保护层，先前拿到的能力清单又未必仍然有效。RFC 2449 让能力发现变得机器可读，却没有把一份清单说成适用于所有状态的服务器画像。
互联网历史
服务器签署了结论，对象仍然无效：RFC 3029
一份带有可信签名的证书，结论却是“无效”。这并不矛盾。签名证明谁在何时、依据哪套策略，对哪项请求作出了什么判断；它不会替被检查的文档或证书修复缺陷。2001 年的 RFC 3029 把这条边界写进了验证服务本身。
互联网历史
网络一视同仁，编解码器却不这样看：RFC 2448
压缩视频里丢掉几个字节，不一定只是少了一小块画面。丢掉普通图像数据，可能只留下局部瑕疵；丢掉说明后续数据该如何解读的短小信息，影响却可能扩散得更远。1998 年的 RFC 2448 试图把这种差异交给发送端处理：依据编解码器的语义分类，再为后果更重的信息安排更可靠的传输路径。
互联网历史
规则选中了动作，却没有交付结果：RFC 3028
一封邮件走到过滤脚本末尾，没有命中任何投递动作。这里的“什么都没做”本来可能意味着丢失，Sieve 却把它定义成一种保护：按默认方式保留邮件。这个看似微小的决定揭示了 RFC 3028 的完整边界——规则可以决定下一步，但不能替运行中的邮件系统证明最终结果。
互联网历史
邮件可以承载邀约，却不是日历：RFC 2447 的 MIME 边界
RFC 2447 没有让邮件标题替日历作决定，而是规定：把 iTIP 的日程对象放进 MIME 的 `text/calendar` 部分，再用外层 `method` 标明它携带的操作。没有日历功能的邮件客户端仍可显示一段可读说明，但那不是第二个会议。