摘要

  • RFC 1278 为包含选择器与一个或多个网络地址的 Presentation Address 规定了面向人的字符串形式，同时明确说这种形式不用于内部存储。
  • RFC 1006 地址可以用域名方便输入；一个域名若解析到多个 IP，就应物化为多个网络地址，编码地址重新显示时则应使用 IP 形式。
  • 宏可以递归展开，显示时可以选最长缩写，但文献强调宏不可被依赖。输入、词典、DNS 观测、地址集合、路径选择和连接结果必须各自留痕。

可读界面不是另一份数据库

RFC 1278 于 1991 年 11 月发布，是一份 Informational 文献。它要解决的问题，是怎样把 OSI Presentation Address 写成管理员能够阅读和输入的字符串。

被表示的对象并非一个简单主机名。一个 Presentation Address 在逻辑上由 presentation selector、session selector、transport selector，以及一组网络地址组成。三个选择器位于不同上层会合点，网络地址又可能属于不同地址体系。一个 Application Entity 因而可以携带多个候选网络地址，而不是天然只有一条可走的路。

目录内部保存的是 ASN.1 表示。RFC 1278 的字符串用于给人看，典型读者是系统管理员；它明确指出，这种形式不打算用于内部存储。

这句话把“看起来一样”与“生命周期一样”分开了。显示值可以使用本地词典、方便记忆的名字或当时的排版习惯；持久记录却必须保证以后还能解释。把显示字符串原样塞进数据库，等于把未来解释权交给一套可能变化或消失的外部环境。

文献并没有为了简洁而牺牲复杂情况。语法必须容纳所有合法值、在没有选择器的常见情况下保持干净、支持字符、十进制、16 位数值和十六进制选择器，还要容纳 TCP/IP、X.25(80) 和未来扩展。可读性来自结构清晰，而不是把不方便的事实删掉。

一行字符串可以承载一组地址

语法把可选的三层选择器放在 network-address-list 前。地址列表允许多个元素。字符串把它们写在一起，却没有把它们压成一个“最终地址”。

多个候选本身就是信息。它说明这个 Presentation Address 关联着不止一个网络地址；它不说明这些地址此刻都可达、优先级相同，或者一定指向已经认证的同一端点。

相邻的 RFC 1277 把后续动作分成四步：先从 OSI Directory 查到 Application Entity 的 Presentation Address；再逐个提取网络地址并判断是否、怎样使用；随后决定偏好次序；最后才尝试一个或多个连接。

因此，RFC 1278 的合法字符串只是链条上游的表示记录。它没有替软件判断地址是否适用，没有选中路径，更不是连接成功回执。地址集合、选择结果与连接结果不能因为共用一行日志就合并成一个事实。

域名只负责让输入更容易

RFC 1006 形式允许填写点分 IP，也允许填写 DNS 域名。RFC 1278 对两者并不对称：域名主要是为了输入方便。

如果域名映射到多个 IP，编码过程应生成多个网络地址。把已经编码的地址再转换成字符串时，则始终应该输出 IP 形式。

这里隐含着一条精确的证据链。管理员输入的域名，是输入记录；某时刻的 DNS 回答，是观测记录；由该回答生成的多个网络地址，是物化结果。以后读取存储值时，不应重新查询 DNS，再把今天的回答冒充成当年保存的地址集合。

一名多址也不能被悄悄缩成单址。只存域名，会让旧记录随着 DNS 改动漂移；随手只取一个 IP，又会抹掉当次解析得到的集合。RFC 1278 选择的是把方便的名字展开为显式地址。

这种物化仍不证明连通。DNS 返回值不是连接回执，IP 字面量也不是端点身份。它只让“从什么输入得到了哪些地址”可以被复核。

宏可以压缩文字，不能拥有意义

长地址不利于人眼识别。RFC 1278 允许在网络地址前放一个以 = 分隔的宏，用短名字代替公共前缀。宏还能递归：一个本地短名可以引用更大的宏，逐层展开成完整地址。给人显示时，软件应选择可用的最长替换。

这有利于识别，却引入了另一份状态——宏词典。宏定义一旦改变、在另一台机器上缺失，或者递归链中的某一级不同，同一个可见短名就未必能还原出同一地址。

RFC 1278 在列出若干建议的标准宏之前，先给出明确警告：任何宏都不应被依赖。建议名称是界面便利，不是持久注册保证。

宏出现、宏定义、递归展开和展开后的网络地址，是四条相关记录。只保存第一条，并假设后三条永远存在，就把显示策略变成了隐藏依赖。先展开、再持久化，才能让依赖在记录生成时被看见。

混合网络使这种克制成为必要

RFC 1277 描述的环境并不整齐：国际与私有 X.25、孤立的 OSI 网络、CLNP 试验网、通过 RFC 1006 运行 OSI Transport 的 TCP/IP 局域网，以及 DARPA/NSF Internet 同时存在。要求先有一个无处不在的 OSI Network Service，并不现实。

临时方案把解释下层网络所需的信息编码进 Network Address，让目录仍可提供一个标准地址字段。RFC 1278 再为这套复杂结构提供共同的可读形式。两份文献没有因此宣称底层网络已经合并成一个，也没有把全局唯一的编码写成认证身份。

语法正确只说明表示可以解析。某个调用者能否使用一个候选、应当先试哪一个、连接是否完成，是后来发生的不同状态。后来的成功或失败，也不应回头改写最初输入与物化记录。

来源与边界

本文使用 RFC 1278 支撑其显示用途、选择器与地址列表语法、RFC 1006 域名输入、多地址生成、IP 输出规范化、递归宏及不可依赖警告；使用 RFC 1277 仅说明混合下层网络背景，以及目录查询、地址提取、偏好排序和连接尝试的相邻步骤。

两份文献都写明未讨论安全问题。它们不证明宏可信、DNS 映射稳定、某条路径获得授权、地址对应经过认证的端点，或连接曾经成功；也没有给出部署普及率或今天的运维建议。

RFC 1278 的历史价值，在于它让复杂地址可以被人读懂，却拒绝把可读形式升级为权威记录。缩写可以帮助管理员，存下的地址必须能在缩写消失后继续被解释。