档案
Research
Research档案页面汇集了人物、公司、机构等实体的情报，帮助读者对比BTW.MEDIA报道中的相关主体。通过该页面，读者可以对比公开档案、相关事件、证据材料、角色变动、运营足迹、治理风险、组织联系以及市场关联性，同时将机构与人物记录同普通新闻时间线区分开。读者能理解新闻标题背后的主体、支撑档案的证据，以及使该档案具有重要影响的基础设施或市场关系。也可以看到档案所代表的主体是谁或是什么、依据哪些公开来源、它如何与公司、市场、治理机构或事件连接，以及随着主体演进，哪些变化值得持续关注。
IETF
下游 PCE 不可见，不能把协作链当成自动成立的信任链
源端 PCC 收到了一条完整的跨 AS 计算结果，却可能从未见过参与计算的下游 PCE。RFC 5376 接受这种不对称：运营商可以隐藏内部拓扑、商业安排，甚至隐藏只与直接对等方交互的计算节点。但它没有把“未知参与者返回了一个可用字段”变成信任。相反，隐藏越深，越需要由掌握本地事实的 AS 证明后续信令展开的正是本地 PCE 当初算出的那一段。
IETF
三条会话都举起了结束标记，完整画面仍未被证明
同一幅 JPEG 2000 画面被分进三条 RTP 会话。每条会话都在自己的最后一个包上把 Marker 置为一。三个“结束”都是真的，却没有任何一个单独证明三条层次都到齐、内部没有缺口，更没有证明解码器显示了约定质量的画面。RFC 5371 的关键不在于缺少结束信号，而在于结束信号有严格的管辖范围。
互联网历史
一次绑定移动了整个网络，却不能证明每个节点都可达：RFC 3963
网络移动时，最省事的办法不是让每台机器都知道自己在移动，而是让一台路由器替它们承担变化。RFC 3963 把整段网络的外部位置压缩进一次绑定。这个设计的价值恰恰也规定了证据边界：归属代理能够确认自己已接受绑定、建立转发，却没有因此看见路由器背后的每个节点。
IETF
外层地址与内层地址完全一致，但这不是发送者的身份证明
网关核对了隧道内外的组播目的地址，也核对了被要求保留的源地址；结果全部一致。RFC 5374 要求这种一致性，因为组播路由需要看见正确的组与源。可一致的只是封装结构。把它升级为“这个人发送了这份内容”，证据链中间仍缺了好几层。
IETF
名单里只有一个地址，才改变了同意问题的答案
转码器收到的不是“替我找人”，而是“只向这个已知地址发出一次邀请”。RFC 5370 因此没有要求这类服务使用预先同意名单。这个结论并不属于“转码器”三个字，而属于三个同时成立的事实：一个目标、一次下游邀请、主叫身份可见。产品一旦改变其中任何一项，原来的许可边界就不再自动有效。
互联网历史
零不是“默认值”，而是 4,294,967,296 次迭代：RFC 3962
在 Kerberos 的 AES 参数里，四个全零字节不是空白，也不是“采用默认设置”的快捷写法。RFC 3962 把它解释为完整的 (2^{32}) 次计算；真正缺少参数时才采用 4096。一个字段是否存在，足以把客户端的工作量放大一百多万倍。
IETF
电话先自动接通了。后来那个 re-INVITE 仍无权打开麦克风。
RFC 5373 允许终端在没有用户按键的情况下接受一段入站媒体，却没有把这次授权变成整场会话的永久通行证。只要媒体方向改变，系统就必须重新回答：是谁同意让这个设备向外发送声音？
互联网历史
同一把 Kerberos 密钥，每项用途都需要一个编号：RFC 3961
密码系统最危险的含混，往往不是“不知道用哪把密钥”，而是“知道密钥，却不知道这次成功验证究竟属于哪项协议动作”。RFC 3961 用一个公开的用途编号，把这层语义塞进密钥派生过程，也把验证成功的证明范围压回它本来应有的位置。
IETF
只有视频需要转换，音频却也被送进了中间人
会话的音频已经拥有共同编解码器，只有新增的视频不兼容。系统却把整场通信都绕进转码器。RFC 5369 的 3pcc 模型提供了更细的选择：需要转换的流经过 T，其余流保持直连。一次会话并不天然只有一条信任路径。
IETF
`cid:` 指向了名单，但先要回答：它指的是一个部分，还是整个正文？
一条 Refer-To 头部只写了一个 Content-ID URL。名单确实随请求到达，接收端也能解析它；然而在 RFC 8262 明确规则之前，RFC 5368 的示例曾把“正文部分”和“完整正文”之间的边界留给实现者猜测。一个看似精确的引用，只有在对象边界同样精确时才构成证据。
互联网历史
隧道接收了数据包，解封装却抹去了最近的追踪线索：RFC 3964
6to4 的关键风险并不只是地址可以伪造。更棘手的是，一台设备完全按照设计完成解封装之后，继续向前传递的 IPv6 包还在，最能说明它从哪个 IPv4 隧道入口抵达的外层线索却可能已经消失。
IETF
公共 URI 创建了订阅，后续请求却必须去另一个地址
第一次 SUBSCRIBE 发往公开的名单 URI，并携带收件资源列表。对话建立后，续订请求改为发往服务器提供的 URI；同一份列表正文在这里没有定义好的含义。RFC 5367 用地址变化把两种权力分开：公开入口负责创建，后续目标负责维持已有对话。
IETF
一个 INVITE 装了 SDP 和名单，但它们没有共享同一份成功证明
RFC 5366 允许创建者把会话描述和初始参与者名单放进同一个 multipart INVITE。两个正文一起抵达会议工厂，却启动了两条不同的证据链：SDP 处理创建者与服务器之间的会话，名单只要求服务器尝试邀请其他人。创建者媒体协商成功，不能替任何受邀者证明入会。
互联网历史
电话已经显示振铃，主叫方仍要等媒体包来作证：RFC 3960
SIP 可以报告被叫终端正在响铃，而主叫听到的回铃音却完全由本机生成。RFC 3960 把这段看似连续的等待拆成几种不同事实：信令进展、媒体到达、声音呈现，以及最终接通。
IETF
服务能解开的加密正文，收件人未必能解开
Alice 把一段安全正文加密给名单服务。服务当然可以读取它；Bob 却不是那段密文的密码学受众。若系统把“转发消息”理解成复制全部字节，就会把一个有效的安全对象送到错误的人手中。RFC 5365 的边界更精确：保留有用载荷，不等于保留每一个正文部分。
互联网历史
组播地址写出了汇合点，却没有证明它真的存在：RFC 3956
RFC 3956 把一部分控制面配置写进 IPv6 组播地址，让路由器都能算出同一个 RP 候选。确定性解决了“选谁”，却没有回答“它是否存在、可达、可信并且真的送达数据”。
IETF
同一个 URI 出现两次，RFC 5364 先决定留下哪一种可见性
名单展开后，同一接收者可能由两条路径出现：一条写着 `bcc`，另一条写着 `to`。RFC 5364 不主张发送两次，也不允许实现随手保留第一行；它要求按 `to`、`cc`、`bcc` 的顺序解决优先级。去重因此不只是节省请求，它会决定谁能在接收者历史中看见谁。
互联网历史
数据包没有携带帧数，接收端只能用长度相除：RFC 3952
一段语音能否被正确拆成帧，并不只取决于眼前的数据包。RFC 3952 省去了帧数栏位，把那项信息分散到载荷长度、SDP 协商模式与发送端守约这三处证据里。
IETF
名单里只改了一个 URI，执行对象已经不是原来那一组
请求离开发起者时，收件人名单有十项。服务准备展开时，其中一项已被替换。每一跳都可以使用 TLS，每一条连接也都可以是“安全”的，但这仍然回答不了最重要的问题：最终被授权并执行的，究竟是不是发起者提交的那份名单。
IETF
同意文件绑定发送者、目标与最终接收者，而不是写下一个笼统的“是”
RFC 5360 里的同意不是一项脱离上下文的偏好。relay 要把进入请求的 target URI 翻译成 recipient URI；permission document 因而要说明谁发送、原始目标是谁、最终请求会发给谁，以及接收者用什么能力授予或拒绝。少一个维度，“同意”就可能在后来被套到另一条转发关系上。