摘要

  • RFC 3085 为一个逻辑上的 NewsItem 规定由提供方域名和日期限定的 URN，并以正整数修订号排列该条目自身的版本。
  • U 和 A 区分两类更新情形，但命名空间登记或版本标签都不能证明资源存在、可验证或可访问。

一则新闻更正发出后，原始通讯社可能保留旧网址，客户网站存着自己的副本，档案系统又记录了一份。读者说“这篇稿子”时，指的究竟是哪个地址？RFC 3085 试图把内容身份与存放位置分开，而不是替每个副本提供一个永远有效的链接。

这份 2001 年 3 月发布的 RFC 3085 为 NewsML 新闻条目提出 newsml URN 命名空间。文件指出，同一逻辑 NewsItem 可以位于多个物理位置：NewsML 可以列出多个 URL，却只给它一个 URN，以此命名资源。RFC 的类别是 Informational，文本也明确说明它并未制定互联网标准。

标识符由提供方域名、日期、NewsItem 标识、修订号，以及可选的更新字母组成。分配标识符的组织必须在所写日期拥有该域名；同一提供方和日期下，NewsItem 标识必须唯一。修订号必须是正整数，零不允许；对于同一个条目，较大的数字必须代表较新的修订。它不是全体新闻共用的时间戳，也没有规定版本之间间隔多久。

末尾字母描述特定的编辑状态。如果 NewsItem 含有一个或多个 Update 元素，就必须标为 U。如果标识符只对应一组被替换的 NewsManagement 数据，则标为 A。两种情形都不适用时，不加后缀。这样，改动新闻条目本身与只替换管理元数据就有了不同标记。

RFC 对词法等价的定义列出 ProviderId、DateId、NewsItemId 和 RevisionId，并规定不区分大小写；可选更新字母没有列在这组比较字段中。应当谨慎按原文理解：后缀没有被明确写成额外的词法等价键。仅凭这句话，无法断定所有解析器或编辑部如何处理只有后缀不同的两个标识符。

URN 本身不会把稿件送到屏幕上。RFC 3085 将解析和验证服务的责任交给提供方，但限定为“如果有”。当前 IANA 正式 URN 命名空间登记表把 newsml 列为引用 RFC 3085 的命名空间；这证明登记存在，不证明某个解析器正在响应。RFC 还说明，文中示例只是代表性样例，也可能并不指向真实资源。

IPTC 当前对 NewsML-G2 的介绍展示了后续新闻交换格式如何涵盖单条内容与多媒体内容包。但这既不能证明 NewsML 1.0 曾被怎样部署，也不是 RFC 3085 解析服务运行的证据。该 RFC 的贡献要小得多，也更清晰：定义条目身份与版本顺序，同时把内容检索留作另一项服务责任。

分析

这个结构分别回答两个问题：是哪一条新闻，哪个版本排在后面。域名和日期限定分配空间，局部标识指向具体条目，修订号排列其版本。规范写清了这些规则，但没有证据表明各个分发副本都会遵守同一顺序。

U 与 A 的区别也有实际含义：新闻正文含有 Update 元素，与只替换管理数据不是一回事。不过标记只说明设计所区分的情形，不能说明订阅者收到通知、聚合站点抓取了变化，或眼前版本就是最新版本。

监测

核验一个档案或供稿服务时，应分别检查格式、指定日期的域名持有情况、标识唯一性、版本顺序、更新字母与内容的对应关系，以及当前解析或验证响应。RFC 没有规定服务可用率、内容时效或交付目标。

重点留意两种不同故障：新修订已经编号，却没有可访问的副本；或者 URL 仍能打开，却返回旧版。IANA 的登记不回答服务是否在线，NewsML-G2 也只能作为后续背景。

控制与激励

提供方负责自己分配的标识范围，并决定是否运营解析或验证服务。接收方可以另存副本、建索引或保留证据，但这并不会让它自动成为原始修订序列的分配者。

编辑部需要选择只保存 URN，还是同时维护可检索路径，例如解析器、重定向记录或镜像。后者需要持续维护，却是另一项运维承诺，不应被说成 URN 自带的能力。

不可逆的风险是目录仍然完整，指向的新闻副本却已经消失。修订顺序能帮助发现缺项，不能重造丢失内容。身份、版本、网址可用性、验证结果和实际交付应分别记录。

来源