摘要

  • RFC 9537 的 redacted 成员可以命名被删隐的字段、说明采用的方法，并指向删隐前或删隐后结构中的位置。它记录服务器怎样描述这次输出，不是被保护原值的副本或独立验真。
  • 原因字段可省略，具体政策不由该 RFC 规定；如果承认某字段存在本身就会泄露信息，服务器还可以不发出删隐标记。因此，查询、权威服务器、访问等级、时间、原始回应、路径解析与政策版本必须分别留证。

一个空位不能替两段历史作答

设想审计程序每天抓取同一域名的 RDAP 记录。昨天有一个注册人联系对象，今天对象消失了。程序若直接写下“隐私规则删除了联系信息”，已经跨过了证据边界。它只观察到两个响应不同；源数据被清空、对象被删隐、访问权限改变、服务器换版或解析器出错，都可能产生相似表象。

RFC 9537 于 2024 年 3 月作为 IETF 标准轨文档发布，解决的正是“没有显示究竟意味着什么”这一小块问题。作者是 James Gould、David Smith、Jody Kolker 与 Roger Carney。2026 年 9 月 7 日留存的 IETF 个人页面列出 Gould 参与的 13 份 RFC；Registration Operations Workshop 委员会简介称，他是 Verisign 技术服务组的 fellow，负责域名注册服务的架构与技术方向。这些材料为其注册协议工作提供了背景，但不构成独自发明或控制他人部署的说法。

标准没有承诺消除所有未知。它只让服务器用共同格式陈述：这份回应中的某个字段经过了删隐。这个陈述值得保存，也必须与更大的证明区分开。

redacted 真正连接了什么

采用扩展的回应会在 rdapConformance 中声明 redacted。包含一个或多个删隐字段的对象，通常会有一个 redacted 数组。数组中的每项必须给出逻辑名称 name，它可以引用登记过的类型，也可以使用未登记的文字说明。

路径把名称与 JSON 结构联系起来。prePath 指向删隐前的位置，所以在客户端收到的文档中解析不到它并不矛盾。postPath 指向仍然存在的空值、部分值或替代值。二者互斥；若另一个字段承担替代功能，还可用 replacementPath 标明。默认路径语言是 RFC 9535 规定的 JSONPath。

这组信息能够支持一个有限结论：服务器把某字段称为删隐，并选择了某种处理方法。它不能还原原始字节，也不能证明内部记录正确、相关自然人身份无误，或访问权限计算合理。路径描述文档的位置，不是对文档背后事实的公证。

IANA 登记 redacted 扩展，以及可复用的删隐名称、原因和表达式语言类别。登记让不同实现使用同一词汇，却不审核每一次响应。看到登记值，最多证明客户端识别到了公共语义，不等于政策获得背书。

四种方法留下四种痕迹

第一种是 removal：字段或对象不再出现在交付的 JSON 中。未显式写出 method 时，它通常是默认方法，但不能用来随意删除依赖数组位置表达语义的元素。

第二种是 emptyValue。对于 jCard 这类位置固定的数组，删除一个槽位会改变后续含义，因此保留位置，只把值设为空字符串或 null。第三种 partialValue 保留格式化值的一部分。第四种 replacementValue 用匿名邮箱、联系表单等新值或新字段承担功能。

这四种状态在网页上可能都显示成“已隐藏”，证据意义却不同。整段对象消失，无法按空槽位的方法检验；部分地址仍泄露区域；联系表单保持可达性，却绝不是原邮箱。RFC 9537 还明确排除用重复字母组成的占位文本冒充删隐，因为占位符可能不符合字段格式，也会让客户端把假值当真值。

因此，截图只适合说明界面体验。审计必须保存实际 JSON 形态、方法与路径，否则会把标准刻意保留的差异再次压平。

“服务器政策”不是政策证明

每条删隐说明可以带 reason。它既可使用登记类型，也可写面向人的描述；但文字描述不得成为客户端处理逻辑的依赖。若自动化流程看到“服务器政策”几个字就批准隐藏，便把说明文案误当成了稳定规则。

标准允许服务器发布删隐政策，却把政策内容留在规范范围之外。RFC 9537 不判断同意是否有效、不解释某地法律、不决定申请人是否有正当权限，也不裁定一次拒绝是否合法。RFC 7481 提供认证和分级访问能力，具体授权仍由本地政策控制。同一对象面向匿名用户和已认证用户出现不同结果，并不自动构成矛盾。

ICANN 2024 年 gTLD RDAP 回应规范展示了“下一层”如何工作：在其适用范围内，它把具体注册数据字段映射到 RFC 9537 的名称和方法，并为邮箱等字段规定处理方式。这是特定体系的运行要求，不能扩展成所有 RDAP 服务的普遍政策，也不能替单次披露请求给出法律结论。

更棘手的是，承认“这里有一项数据，只是不给你看”本身可能泄密。RFC 9537 因而允许服务器在存在性信号造成隐私风险时，不列出相应删隐项。没有 redacted 并不证明完整；它可能意味着没有删隐、未实现扩展，或主动不承认字段存在。

把最小收据组装完整

收据应从请求开始。记录完整 URI、查询是 lookup 还是 search、权威服务器与跳转链、获取时间、传输端身份、认证方式和访问等级。匿名访问与特权访问即便查询同一域名，也不是同一次观察。

随后保存响应原始字节或可验证哈希，提取 rdapConformance、对象身份，以及每项删隐的名称、路径语言、路径、方法和原因。报告要说明 postPath 是否在收到的结构中解析成功，prePath 如何解释，并记录 RDAP 与 JSONPath 客户端版本。否则，解析器升级也可能被误判成服务端政策变化。

若响应链接政策页面，应记录当时的 URL、版本与时间。今天改过的网页不能自动解释去年收到的响应。比较两个视图时，更要把访问等级和时刻绑定在各自结果上，而不是对两个匿名 JSON 做差就称为披露决定。

RFC 9082 区分直接查询与搜索；搜索时，删隐说明属于结果中的具体对象。整组结果被截断，与某个对象里的字段被删隐不是一回事。RFC 9083 的 notices 与 remarks 可以说明全局或对象状态，却不能替代逐字段的结构化标记。

只有这些收据合在一起，才足以写下克制的结论：某服务器在某时间、对某访问等级的某次查询，把某字段描述为以某种方式删隐。隐藏值是什么、政策是否正确、谁能取得它，都还需要新的证据。

来源