摘要

  • RFC 1484 把用户输入称为“声称的名字”（purported name）：它可以省略类型、层级并容忍近似写法，但必须经过名录查询才能得到一个或多个 Distinguished Name。
  • 解析结果取决于有顺序的本地环境、模式、当前条目、别名值、匹配规则和必要时的人工选择；字符不变，候选集合仍可能随地点和时间改变。
  • 最终 DN 在名录树中无歧义地指向一个条目，却不自动证明真人身份、条目控制权、操作授权或外部结果。

昨天唯一，今天出现了同名者

一个人在周一输入简短姓名，系统直接找到唯一候选。周二，另一机构登记了同名条目，还加入了一个恰好相同的替代值。用户再次输入完全相同的字符，界面却要求选择。

这不是查询服务“退化”，而是 RFC 1484 明确承认的性质。它提出 User Friendly Name（UFN），让人可以把会议上听到的描述直接键入，不必填写 Common Name、Organisational Unit、Organisation 和 Country 等表格。代价是：这串文字不是存储的主键，而是等待解析的“声称的名字”。

RFC 1484 甚至建议系统几乎总是保存解析后的 DN，因为新名字出现后，原本无歧义的 UFN 可能变得含混。方便来自动态查找，而动态查找天然带着时间。

省略的结构并没有消失

UFN 可以省略属性类型，可以相对于本地位置缩短高层路径，可以跳过中间组织单位，也可以使用缩写、替代值、近似拼写和日常国名。

一部分空白由默认模式补上。例如最不重要的一端通常按 Common Name 理解，最上层按 Country 理解，中间按组织层级分配类型。另一部分必须由搜索补上：一个未标类型的词究竟是地点、组织还是单位，要看树中实际有哪些条目。

因此，“用户只输入了十几个字符”不是完整的可复现记录。还需要客户端版本、界面语言、默认模式、起始位置、过滤条件、当时的名录快照和用户看到的候选。可读字符串只是输入事实；解析事实存在于系统运行过程中。

本地环境决定先问哪里

RFC 1484 把 environment 定义为一组有顺序的非叶子 DN。顺序会随输入组件数量变化，并且应由用户控制。

在文档的英国大学例子里，单个词先在院系内查，再到大学、国家和根；两个组件会先尝试国家或组织；美国公共 DUA 使用另一套顺序。相同姓名在两个客户端上不必得到相同的第一答案。

顺序是一种权力。先找到“精确”结果的分支可能终止更广的探索。本地组织里熟悉的缩写会优先命中，本地之外却可能只是多个近似项之一。若日志只保存最终 DN，本地环境替用户做出的那次判断就消失了。

这也解释了为何短名不能被当成全球标识符。它的意义由某个客户端在某个时间、从某组起点对某份名录执行出来。

“精确、良好、较差”驱动了控制流

文档把匹配分为 exact、good 和 poor。精确项总是继续；没有精确项时跟随良好项；只有较差的子串或近似项时，让用户确认。若用户全部拒绝，解析器可以换到 environment 的下一个起点。

这些词看似是搜索质量说明，实际上控制了分支。首字母能否对应完整姓名、标点是否忽略、组织缩写是不是替代值、短字符串是否允许前导通配符，都会改变候选和查询成本。人的“是”或“否”也是算法的一步。

后来的 RFC 4511 把 LDAP 搜索的证据边界写得更清楚：base、scope、alias 策略、size/time limit、filter 和属性选择共同构成请求；响应可以先返回条目和 continuation reference，最后才有完成结果。屏幕出现一个名字，并不证明所有路径已经结束。

人类名字、DN 与 DN 字符串是三个对象

RFC 1309 描述 X.500 的底层结构：条目位于 Directory Information Tree，DN 由从根到条目的 RDN 路径组成。已发表的 RFC 1309 文章负责 DUA/DSA、chaining、referral、alias 与副本保管。本篇只处理另一条边界：人在不知道完整路径时如何猜到它。

同月的 RFC 1485 解决的是已知 DN 如何无歧义写成字符串。其后 RFC 1779、RFC 2253 和 RFC 4514 继续演化字符串表示。这条线不是 UFN 搜索算法。

RFC 4514 还强调它没有定义唯一的规范字符串；DN 是否相等，应使用 distinguishedNameMatch。看起来不同的转义或显示形式可能比较相等，看起来相似的文字也可能在模式下不相等。

RFC 4512 说明属性类型决定语法和匹配规则，兄弟节点之间的 RDN 必须唯一，DN 在树中无歧义指向条目。RFC 4518 则规定国际化字符串进入匹配前的准备。字形、编码、归一化值和条目身份不能互相代替。

找到条目不等于认出了真人

名录条目是“关于某个对象的一组有名信息”。它可以代表一个人、角色或应用实体。DN 指向条目，并不证明站在终端前的人控制它，也不证明电话号码、职位或服务地址仍然有效。

访问控制可能隐藏属性；referral 可能尚未跟随；客户端可能命中旧副本；用户可能在同名者中选错。后续应用仍须单独认证、授权并记录结果。向选中的地址发信，还需要投递证据；给选中的账户授予权限，还需要审批与撤销记录。

RFC 1484 改善了发现，不是把发现提升为授权。

原型经验同时证明了价值与缺口

RFC 1484 报告了 PSI Pilot 的 FRED 界面和一个邮件列表管理原型，用户反应良好。这是运行代码的证据，但不是互联网普及率。

经验也暴露了问题：多层组织单位中，如果用户省略的单位不是直接子节点，算法表现不佳；首尾通配符可能在实现中代价很高。歧义、效用、性能和算法变体仍需研究。文档预计格式较稳定，而解析过程应随经验调整。

RFC Editor 记录 保存的是文档事实。RFC 1484 属于 Experimental，而且明确说没有讨论安全。它不能支持隐私、防枚举、认证强度或长期部署结论。

一个小公共格式，许多本地决定

Heng Lu 关于运行代码优先、最小初始规范与本地未来决定以及现实层的论述，为这段历史提供了一把清楚的尺。共同层只需定义可交流的形式和基本过程；客户端仍决定环境，名录仍保存现状，用户仍处理歧义，应用仍决定后果。

负责任的记录不会只写“输入名字，找到了人”。它会保留：原始话语、声称的名字、环境、模式、查询、候选、人工选择、DN、条目版本、认证、授权与实际结果。RFC 1484 的名字之所以友好，正是因为它没有假装自己已经包含这一切。

来源