摘要

  • RFC 1277 编码了在没有 OSI 网络服务时，尝试通过 TCP/IP 或特定 X.25 网络建立 OSI 连接所需的信息。
  • 它的全球唯一地址格式可以标识网络并携带传输参数；分配地址本身并不证明地址可路由，也不证明服务会响应。

OSI 目录可以返回表示地址（Presentation Address），但其模型假设网络地址来自 OSI 网络服务。并非所有试验环境都满足这个假设：OSI 应用也运行在互联网、公用或专用 X.25，以及彼此隔离的网络上。如果每次实验都必须等待一个全球 OSI 网络服务，目录在最需要它的试点环境中反而无法使用。

RFC 1277 只处理连接链条中的一个环节。应用查询表示地址后，客户端还要提取其中的每个网络地址，判断自己能否以及如何使用它们，排列优先顺序，再尝试连接。该备忘录聚焦地址提取：它定义了编码规则，使客户端能从目录返回的值中推导出目录没有单独提供的下层参数。它没有规定完整连接流程、路由发现或应用数据交换是否成功。

这个界线很重要，因为一个地址承担了多种职责。在国际 X.25 场景中，X.121 形式地址可以标识 DTE；在适用条件下，它还可能支持经由公用 X.25 网络路由。但分配标识并不天然具有拓扑含义：终端系统不能假定全球分配地址中的每一部分都描述路径。RFC 1277 明言，IDP 首要用途是分配，原则上不能据此推断路由。把某些 X.121 形式解释为路由的建议，取决于所用服务和格式；私有机制也可能找到更合适的路径。

对使用 RFC 1006 所定义 OSI 传输服务的 TCP/IP 网络，RFC 1277 规定了另一种编码。网络特定部分先放置 12 位 IPv4 地址，之后可选地附加五位端口号和五位传输集合值。后者是 16 位标志字：相应值表示 TCP 或 UDP；如果该字段缺省或为零，则默认使用 TCP。RFC 的例子编码了 10.0.0.6、端口 9 和 UDP。这是客户端尝试连接时的解析规则，并非地址仍有效、网络可达、端口正在监听或调用方获得授权的证明。

新格式还必须与真正用于 OSI 网络服务的地址区分开。RFC 1277 选择 Telex AFI，因为它可留出更大的域特定部分，也较不容易与其他地址用途混淆。短前缀区分子网，其余部分携带网络专用信息。这种设计以较长的十进制表示换取紧凑、自描述的结构；备忘录指出，二进制 ASN.1 编码本可更理想，却受限于可用地址空间。

这项折衷属于过渡时期的工程条件，而非永恒的地址原则。备忘录的历史说明称，该方案已在 THORN 与 ISODE/QUIPU 项目中实现并验证可行。这只能证明那些项目中的方案可用，不能证明它被广泛部署。后来的 RFC 1278 描述了供人查看而非内部存储的表示地址字符串；那与 RFC 1277 的地址分配和下层编码属于不同层次。RFC 1237 的 NSAP 指南讨论的是面向无连接 OSI 网络服务的分配规则，并非 RFC 1277 要解决的非 OSI 下层场景。

RFC 1277 留下的教训远比“地址会告诉你如何连接”狭窄：目录记录可以包含足够的结构，让客户端选择下层解释方式。但仍需要当前有效的路由、兼容的监听端、成功的传输交换和应用响应。把一个编码值当成这四者的共同证明，会把分配、解释、可达性和服务压成同一项声明——备忘录从未作出这样的承诺。

来源：RFC 1277；RFC 1006；RFC 1278；RFC 1237。