摘要

  • 10 月 28 日的 JMAP Object Metadata 草案 05 版新增 Binary：只有 @type 与带填充的有效 base64 两个成员。服务器要按提交时的样子保存并返回；坏格式被拒绝。
  • 这层封装按深度零计算，但补丁路径与查询路径不能穿过它，文本条件也不会匹配其中的字节。04 版还没有这项机制。

能证明盒子在，不能按盒内的指纹找

草案举了一个 32 字节“指纹”的例子，把它放在供应商自己的命名空间里。客户端可以问这个字段是否存在；若要按指纹的字节内容搜索，服务器的文本条件不会帮忙。想用补丁只改 base64 成员也会撞墙：协议把整只 Binary 盒子当成一个值。

设计理由很直白。JSON 字符串装的是 Unicode 文本，应用有时要装任意字节。05 版新章节因此规定了精确的两成员结构、带填充的 base64，以及坏值的 invalidProperties 错误。越过盒壁的补丁会得到 invalidPatch。保存与解读在此分开：服务器负责保管，不负责猜出供应商为这些字节赋予的意思。

谁说了算？命名空间的主人定义字段含义；供应商可用自己控制的小写域名作为命名空间，不必先向 IANA 登记一个名字。服务器决定某类对象是否接受这种供应商空间，另行规定容量。共享元数据遵从对象的读取权限，私人元数据属于相应用户。这些权限安排早在 04 版就有；这次新增的是放进空间里的封闭字节值。

“深度零”听上去像免费通行证，其实只是嵌套层数。草案要求服务器考虑元数据配额，也允许实现自行定尺寸上限，超额返回 overQuota。普通文本过滤器也可能因成本而由服务器拒绝。采购清单若只写“支持元数据搜索”，就漏了三个问题：字段到底是字符串还是 Binary、服务器启用了哪些过滤器、配额按什么口径算。

IETF 状态页仍把文件列为工作组 Internet-Draft。还缺一段实际服务器轨迹，逐项展示写入、原样回读、内部查询失败以及配额扣减。封条的规格很清楚，仓库有没有照办仍要看运行证据。

来源：05 版草案；04 版草案；IETF 状态。