摘要

  • RFC 1485 为已经确定的 X.500 Distinguished Name 提供面向人的字符串表达，使 ASN.1 结构能够经由名片、邮件等普通媒介传递。
  • “无歧义”约束的是解析方向：合规字符串应还原为一个确定的 DN。分隔符、排版、属性描述符或 OID、引号与备用编码允许同一 DN 拥有多种合法文本。
  • 解析成功只证明结构被还原；条目是否存在和新鲜、DN 是否相等、现实主体是谁、是否完成认证授权以及行动结果，都需要后续凭证。

一段十六进制为什么比漂亮名称更重要

RFC 1485 最容易被记住的是人可读的名称，最值得追问的却是它不美观的部分。当某个属性值没有合适的显示形式时，规范允许把 BER 编码写成十六进制。文本坦率地称这种结果很丑，并预计它主要出现在病态案例中。

恰恰是这条退路支撑了“任何 DN 都能表达”的承诺。只覆盖常见姓名、组织与国家的语法，可以做出演示，却无法保证未来属性、私有属性或接收端尚不认识的值不被丢弃。十六进制形式不保证接收者理解内容；它保证当前界面不会因为不理解而擅自改写内容。

RFC 1485 处理的是一个已经知道的 Distinguished Name。它与 RFC 1484 的边界很清楚：后者从人输入的“声称名称”出发，在名录中寻找候选 DN；前者不负责猜测或查询，而是把已知 DN 从 ASN.1 对象变成人可交换的字符串。

这不是同一件事的两个按钮。搜索回答“你可能指哪个条目”，序列化回答“如何把这个结构写进普通媒介”。

标点承担了树的结构

X.500 的 DN 由名录信息树路径上的一串 Relative Distinguished Name 组成。RFC 1485 采用适合人阅读的“小端”展示顺序：更具体的部分在前，更宽的命名上下文随后。属性类型和值之间用 = 相连；逗号或分号分隔不同 RDN；+ 则把多个类型—值断言放进同一个多值 RDN。

这些符号不是样式。把 + 换成逗号，会把同一命名层级中的两个断言改成前后两个层级。删除属性类型也不是 RFC 1485 DN 表达的简写，尽管它与友好名称工作共享过语法背景。

因此，一行字符保存了至少四类结构事实：每个值的属性类型、值本身、哪些断言属于同一 RDN，以及 RDN 的先后次序。接收方不必根据换行或字体猜测树路径。

同时，逗号与分号、单行与多行都可以服务展示。可恢复的结构是共同约束，页面长相不是。

引号划出了数据与语法的边界

普通值看起来简单，真实数据却可能包含逗号、引号、首尾空格或连续空格。如果不做处理，这些字符会与语法标记冲突。RFC 1485 要求在相应情况下使用引号与转义，把“值中出现的字符”和“控制结构的字符”分开。

属性类型也可能超出接收软件的短名称表。此时可以写点分十进制 OID。一个解析器即使不认识友好描述符，也能保留类型身份。结合十六进制 BER 退路，这套表示法选择了一个重要原则：可读性服务常见路径，完整性不能依赖常见路径。

但保存 OID 并不等于获得模式知识，保存 BER 也不等于知道如何展示或比较。协议在未知处保持事实，而没有伪造理解。

从一个字符串到一个结构，不等于从一个结构到唯一字符串

“可以无歧义解析”很容易被误读成“只有一种正确写法”。RFC 1485 的目标是让合规输入指向确定结构，而不是为每个 DN 颁发唯一的文字外观。

规范允许不同分隔符和排版；序列化器掌握的描述符注册表可能不同；类型既可能显示为短名，也可能退回 OID；值可以采用转义文本或编码形式。多个字符串因而可以回到同一个结构。

后续标准把这条边界说得更明确。RFC 1779 取代 RFC 1485，RFC 2253 引入 LDAPv3 的 UTF-8 表达，RFC 4514 又取代 RFC 2253。RFC 4514 明言不定义 DN 的规范字符串，并允许产生可解析结果的其他转换算法；DN 相等应由 distinguishedNameMatch 判断，而不是直接比较原始文本。

这不是把新规范的措辞倒填进旧文档，而是用谱系澄清旧工作的准确边界：解析结果可以确定，书写表面仍可多样。

屏幕、字节、结构和匹配是四张不同收据

截图记录字形，邮件存档可能记录字节，解析器记录有序 RDN，名录匹配器依据模式选择规则。四者相互关联，却不能互相冒充。

RFC 4512 把属性语法、匹配规则、RDN 与 DN 放在 LDAP 信息模型中；RFC 4517 给出相关语法和匹配规则；RFC 4518 处理国际化字符串匹配所需的映射、规范化、禁用字符与双向文本问题。肉眼相似不自动意味着码点相同、结构相同或模式意义下相等。

因此，把历史 DN 全部转小写、随意裁剪空格、用记忆中的描述符替换 OID，或把显示字符串直接当数据库唯一键，都可能制造假合并或假分裂。可靠迁移应保留原始字节、字符集处理、序列化器与解析器版本、描述符注册表、解析结构、模式和匹配规则。

名称只把请求送到名录门口

RFC 1309 描述了 X.500 的分布式底座：DUA、DSA、命名上下文、链式处理、引用与副本共同决定一次名录操作看到什么。RFC 1485 没有重新规定这些机制。解析出的 DN 可以成为查询输入，却不是查询回执。

解析成功不能证明目标条目在所查时间仍然存在，不能证明副本新鲜，也不能证明访问控制没有隐藏关键属性。即便查到条目，DN 所指向的也是名录模型中的条目；它不会自动认证现实中的人、证明服务控制权、授予角色或批准交易。

RFC 1485 的安全章节明确表示没有讨论安全问题。不能从一套保持名称结构的标点规则中推导出机密性、完整性、防冒用或授权能力。

Historic 是标准状态，不是数据清除命令

RFC Editor 的 RFC 1485 页面 如今将其列为 Historic。RFC 3494 参与了把 LDAPv2 技术规范转为历史状态的行动。后继文档改进了字符编码、转义、描述符与相等判断的表述。

标准谱系的更新不会同步删除邮件、配置、日志与备份里的旧字符串，也不证明各实现曾经完全一致。一个现代解析器面对旧资料，可能拒绝、误读，或缺失当年的描述符注册信息。判断遗留事实必须查看实际运行过的代码和留存输入，不能只凭当前标准标签。

最小共同语法之后，决定仍然分散

Heng Lu 关于运行代码优先、未来决定本地化与现实层次的论述，为这份旧规范提供了合适的阅读框架。共同标准只规定足以交换的边界；序列化器选择本地展示，解析器还原结构，名录运营者对当前条目负责，认证系统与应用分别作出后续决定。

一条可信证据链应依次保存：原始结构化 DN、序列化字节、传输处理、解析结果、基于模式的相等判断、名录快照与条目版本、认证、授权和最终结果。把其中一层缩写成“名称证明了一切”，就是让显示文本获得协议从未授予的权力。

RFC 1485 的成就在于让正式名称穿越人类文本仍可恢复。它留下的更深原则是：每穿越一次边界，就应留下属于该边界的收据。

来源