摘要

  • RFC 9982 将 JSContact 2.0 Card 的 uid 改为可选；当 vCard 源数据没有 UID 时，转换器不得为 v2 生成一个。
  • 标识符能让一条记录在特定模型中被引用，却不能单独证明它代表谁、关系是否仍成立、来源是否有资格声明，或接收方是否可合并和更新数据。

JSContact 早期要求每张 Card 都有 uid，这对需要稳定对象句柄的同步协议有用，却与 vCard 的可选 UID 不一致。旧的转换规则会为缺少 UID 的 vCard 生成一个值，但不同实现、甚至同一实现对同一张卡多次转换，并不保证产生相同值。一个为满足结构而产生的字符串，随后可能被写入 members 或 relatedTo，仿佛它已是原始联系人作出的稳定身份声明。

RFC 9982 收窄了这个跳跃。版本 2.0 中，没有 uid 的 Card 仍然有效；默认不能因此被判为无效。但它也不能作为 members 中的成员，不能成为另一张卡 relatedTo 的对象。标准没有说联系人不存在、记录无用或一定不可靠。它只说：这张记录缺少创建此类机器关系所需的可引用锚点。信息可以保留，未经证明的关联不能被自动铸成事实。

转换规则使这一边界可执行。源 vCard 没有 UID 时，转成 JSContact 2.0 或更高版本，uid 必须保持不存在。若转成 1.0，旧规则仍要求生成值，而生成方式由实现决定；即使同一实现尽量重复，也无法消除跨系统歧义。版本升级因此不是“补齐所有字段”，而是承认某些来源没有提供可安全携带的关系键。

领导层尤其需要分开几个常被压缩成“同一个联系人”的判断：两段字节相同；本地键连续；来源可追溯；两条记录指向同一实体；关系目前有效；相关方同意此关系；操作员获准合并；写入后已正确协调。uid 只处在记录结构和引用的一层。它不是身份证明、签名、控制权证明、法律名称、同意书或更新授权。IANA 为 JSCOMPS 补齐登记，改善的是参数登记完整性，不是转换语义的真实性担保。

CardDAV 或 JMAP Contacts 可能需要标识符来同步对象；RDAP 则未必需要。协议需要稳定句柄，并不授权中间层凭空建立主体身份。Heng Lu 所强调的最小共同规格在此十分直接：让交换可行，但不要夺取必须留给来源、关系所有者和本地治理者的判断。