摘要

  • RFC 2079 定义了区分大小写、允许多值的 labeledURI 属性，也定义了可附加到既有 X.500 或 LDAP 条目的辅助类 labeledURIObject。
  • 未编码空格把 URI 与可选标签分开；多条值可能指向不同的相关资源，也可能只是同一资源的不同位置，而格式中没有关系类型可供区分。
  • 地址被写入名录，不等于它可达、最新、权威或与另一地址等价；标签也不是可信 HTML，RFC 2079 明确警告不得直接插入网页。

1997 年时，把网址放进名录已经不是新想法。不同团体正在 LDAP 与 X.500 中各自尝试。RFC 2079 的价值，是给这些做法一个共同的属性名和数值形式，让不同客户端看到同一种结构。

每个值先写 URI——当时要求符合 RFC 1738 的 URL——后面可以接一个或多个空格，再接供人阅读的标签。URL 不能包含未编码空格，因此第一个这样的空格自然成为边界。客户端无需理解标签的语言，就能判断地址在哪里结束。

多值保存了一个尚未回答的问题

RFC 2079 说，多条值通常表示与目录对象有关的不同资源，但也可能表示同一资源的不同位置。这两种情况在运营上完全不同。员工主页与头像是一组相关资源；主站与镜像则是两个位置。它们都能用同一属性表示，但其中没有“头像”“镜像”“权威来源”“存档”或“备用”这样的机器可读角色。

标签可以提示资源种类或大小，却没有规定语法。“官方网站”仍只是写入者的陈述。名录能证明该字符串以已知属性附在某个条目上，不能证明目标方承认这种关系，也不能证明两条链接可以互相替代。

后来的 RFC 3986 把 URI 比较描述为逐级增加的处理过程。字符完全一致时可以断定等价；字符不同仍可能在通用或特定协议的规范化之后指向同一资源。因此，精确保留大小写和字符有助于审计，却不是完整的资源身份判断。

扩展条目的能力不是新增权威

labeledURIObject 是从 top 派生的辅助类，本身不强制新增字段，只允许加入 labeledURI。管理员可以把它附到既有对象，而不用改动对象的主要类别；其他类别也可直接接纳该属性。

RFC 2798 让 labeledURI 成为 inetOrgPerson 的可选字段，并用个人主页举例。RFC 3383 又把这个属性和辅助类列入 LDAP 描述符表。这些记录证明定义得到了复用和登记，不证明任一目标页面的状态，也不证明普遍部署。

RFC 3296 后来把相同的数值形式用于 LDAP 下级引用，却另加了明确规则：ref 不使用标签，构造引用时去掉分隔符和标签，使用多值中的每个 URI，而且建议保存或返回 URI 的服务器不要验证引用完整性。一般形式只有在另一份文件给出语义后，才成为具体协议动作。

友好文字一旦显示，就跨过执行边界

标签面向人类。RFC 2079 不鼓励使用非 ASCII 字符，因为当时不同客户端的处理可能不一致，还区分了 X.500 字符表示与 HTML 转义。更关键的是安全警告：如果程序把标签直接塞进 HTML，恶意标签可能携带标记，误导整份页面的读者。

因此，存储原文与渲染原文不是一回事。客户端必须负责转义、展示真实目的地，并决定是否让链接可点击。目标端又引入新的不确定性：重定向、内容更换、域名过期、控制方变更和不同 URI 协议的行为，都发生在名录值之外。

可靠的证据链要逐层保存：名录条目、属性值、URI/标签拆分、多值事实、声称的关系、声称者、目标获取、目标来源与时效、安全显示和后续决策。格式正确只覆盖这条链的一小段。

合并属性名，没有合并现实含义

早期草案曾定义 labeledURL。RFC 2079 将其弃用，因为工作组认为一个 URI 属性优于 URI 与 URL 两套属性。旧定义仍被保留，供客户端在迁移期间兼容。

这次合并减少了共同词汇，却没有删除已部署数据、证明迁移完成，也没有给关系增加分类。URI 这个更宽的名称，也不让不同协议自动等价。

RFC 2079 留下的教训很克制：统一指针如何附在条目上，可以帮助系统交换信息；它不会统一指针为何重要、现在是否有效，或读者应当多信任旁边那句话。

来源