摘要

  • RFC 5328 注册的是 dvb 名称空间；具体名称由 DVB 标准流程及其指定机构分配，并以 DVB 目录中的存在作为有效性依据。名称持续存在，不代表某一解析权威、地址或服务持续在线。
  • 不同接收机可能经广播轮播、DVBSTP multicast、HTTP 或 DNS SRV 引导解析。名称或资源的认证信息必须与 URN 分开携带，解析成功也不等于资源已认证、渲染或使用。

稳定字符串掩盖了权威迁移

一次故障复盘里，团队拿出同一个 urn:dvb：故障前后字符完全一致，因此他们认为“控制面没有变化”。真正改变的是目录版本、解析权威和返回位置。

持久名称的价值，本来就在于资源迁移时不必改名。于是“名字没变”恰好不能证明名字背后的控制面没变。它只能作为连接不同阶段收据的稳定键。

若只保存 URN 和最后一次 URL，迁移前的判断依据会消失。系统需要保存目录身份与版本、分配权威、解析入口、选择的解析权威、策略 epoch、返回位置和观测时间，才能说明变化发生在哪一层。

IANA 行只登记名称空间

RFC 5328 声明结构为 urn:dvb:<NSS>。IANA 的 URN Namespaces registry 证明 dvb 是注册 NID，并指出治理文档。它不列出每一个已分配名称。

具体名称通过 DVB 的标准制定流程分配；DVB 还可把部分名称空间交给受其制度约束的指定机构。因而一段能通过通用 URN parser 的字符串，仍可能从未被 DVB 体系分配。

RFC 8141 后来明确指出：以 urn: 开头且语法正确仍不足以成为有效 URN。NID 必须注册，assigned-name 也必须遵守该名称空间的规则。

证据链至少要区分 parser 结果、NID 注册表版本、DVB 规则版本、分配机构、委派记录与具体名称的目录成员资格。

目录只回答“是否被分配”

RFC 5328 没有给出名称内部自带的验证机制。它说 DVB 会维护 URN catalogues，名称出现在目录中就表示有效。

这是一条清楚但有限的判据。它回答指定目录是否承认该名称，不回答接收机能否发现解析器、解析器是否使用同一版本目录、返回位置是否可达，或资源是否真实。

同一名称可以同时出现以下状态：新目录已发布；某解析器仍缓存旧目录；广播接收机尚未收到新记录；IP 终端已拿到新位置。把这些状态压成 valid=true 会丢掉故障的时间结构。

目录收据应保存发布者、版本、发布时间、签名或权威依据、查询时点与成员结果。解析收据另行保存。

永不重分配不是永不断线

DVB 承诺已分配字符串不会被重新分配，并承诺维护正式命名资源的可访问性与持久性。这些承诺建立名称制度的连续性。

它们不是对任意时刻网络可达性的测量。某个 DNS 记录、multicast 路径、HTTP endpoint 或广播流可以暂时不可用，而名称本身仍有效。旧位置也可被替换而不改变名称。

若监控把一个历史 endpoint 当成名称寿命，迁移会被误报为名称失效；若监控因为名称有效就忽略 endpoint 故障，又会把治理承诺当成实时 SLA。

正确做法是分别记录名称状态、目录状态、解析路径状态和资源访问状态。

接收机类型决定可见的路径

RFC 5328 面对的设备并不共享一种网络能力，因此没有指定唯一的解析或委派机制。

仅能单向接收广播的机顶盒，需要从广播流里的 service discovery 信息取得解析数据。家庭网络终端可以经网关使用 IP。后者成功访问 HTTP，不能证明前者收到了轮播记录。

文档列出多种输送方式：在数字电视流中周期重复 RAR 与 RR；通过 DVBSTP 周期 multicast RR；以及对 GET /dvb/sdns 返回 unicast RR。

这些不是同一个“解析成功”的替代 UI。每条路径有不同的传播、缓存、丢失和观测边界。必须从实际接收机类别所在的网络观察，而不是用中心机房的一条 IP 探针代替全部终端。

引导入口还不是解析结果

客户端首先要找到 Service Discovery and Selection 入口。RFC 描述了 dvbservdsc 服务、TCP/UDP 端口 3937、注册 multicast 地址，以及在 services.dvb.org 下利用 DNS SRV 发现非默认入口。

IANA 注册服务名和端口，只证明公共坐标的含义。它不证明存在 listener。注册 multicast 地址不证明路由、加入组或收包。SRV 响应给出目标，也不证明目标在线、获授权或持有当前 RR。

因此要顺序保存：注册表坐标、DNS 或 multicast 观测、发现的入口、连通结果、解析权威、RR、返回位置。前一步不能替后一步签字。

RFC 8553 后来把 RFC 5328 等文档中的下划线 DNS 节点纳入统一 IANA 模型。那项维护证明 _dvbservdsc 这类节点命名获得协调，不证明某个 SRV RR 或服务实例存在。

大小写等价只是一条比较规则

RFC 5328 规定 NSS 不区分大小写。不同书写形式可以在词法比较上代表同一名称。

这并不使两个解析响应、两个目录投影或两个资源内容相等。调查时必须同时保存输入原文与规范化形式，然后比较目录 epoch、解析权威、locator 集合和内容 hash。

若两台设备把等价名称解析成不同内容，真正的问题位于目录、缓存、策略或权威，而不是名称比较。用“名称相同”结束调查，只会掩盖控制面分叉。

认证证据在 URN 外部

RFC 5328 明确说，名称被解析为位置并访问时，资源可能需要认证；认证名称或资源的信息应与 URN 分开传递，而不是放进 URN 本身。

所以 dvb 前缀、目录成员、DNS SRV、正确端口、HTTP 成功或可渲染内容，都不会自动组成信任链。认证收据应说明验证了什么对象、采用什么机制、信任锚是谁、适用什么策略、结果发生在何时。

文档也把 DVB 对 NSS 字符赋予特殊意义所产生的安全问题留给其他 DVB 规范。通用解析器不能从看似有层级的字符串里推导授权。

一个资源可以认证成功却不受当前应用授权；也可以未认证却被设备顺利显示。真实性、兼容性与使用结果都需独立记录。

联系人更新不等于解析权威更新

RFC 7354 更新了注册信息与 declared registrant 联系方式，采用角色邮箱，并明确其他字段仍按 RFC 5328。

它证明名称空间的行政联系人得到维护。它没有观测目录、DNS、multicast、HTTP、广播流或终端，也没有宣告解析权威迁移。

若系统看到联系人日期较新就把服务健康标绿，等于把治理记录扩张成运行测量。相反，旧联系人也不能自动证明服务失效。两种状态需要不同的修复流程。

示例不能进入资产清单

RFC 给出两个教学示例，并明确它们不保证真实。它们说明语法长什么样，不证明分配、目录成员或资源存在。

自动抽取器若把示例加入扫描列表，就从文档凭空创建了对象。名称进入资产清单前，必须有分配与目录证据；进入运行监控前，还需解析授权、访问范围和明确的管理责任。

同理，看到真实的 dvb NID 也不能枚举或猜测其下的对象。

取回数据仍不是完成使用

解析可能返回 locator、metadata 或 representation。之后还有取回、认证、鲜度、解析、转换、渲染、应用授权与最终结果。

RFC 描述的终端差异使这些阶段不可省略。适合门户网页的表示可能要转换后才能供另一设备使用；metadata 可正确而所指内容不可访问；画面可显示而互动操作未完成。

收据应保存返回对象 hash、认证结果、格式处理、渲染与应用 outcome。200 OK 只能关闭一次 HTTP 请求，不能关闭这条业务链。

决策收据

对每次 urn:dvb 使用保存：原始与规范化名称、NID 注册版本、DVB 规则、分配权威与委派、目录身份与 epoch、成员结果、接收机类型、可用信道、引导方法、RAR/RR/DVBSTP/HTTP/DNS 观测、所选解析权威、locator、外部认证、内容 hash 与鲜度、parser、renderer、应用授权和实际结果。

名称是关联这些凭据的稳定键。它不能替任何一项给出结论。

来源