跳到主要内容

Appendix B. 分析 (Analysis)

"X-" 约定的问题 (Problems with the "X-" Convention)​

"X-" 约定的主要问题是, 未标准化参数倾向于泄漏到标准化参数的受保护空间中, 从而造成互操作性问题.

以电子邮件头字段为例. 最初, [RFC822] 区分了标准化的 "Extension-fields" 和未标准化的 "user-defined-fields", 后者被要求使用 "X-" 前缀. 但是, 如 [RFC2822] 所述, 这一区分被移除, 原因是:

  1. 许多 "X-" 字段部署得如此广泛, 以至于成为事实标准 (例如 "X-Mailer").

  2. "X-" 前缀阻碍了开发者正确注册其字段.

  3. 当开发者希望标准化某个 "X-" 字段时, 会面临两难: 保留 "X-" 前缀 (这会错误暗示它未标准化), 或移除它 (这会破坏与现有实现的兼容性).

  4. 一些实现者错误地认为任何不带 "X-" 前缀的字段都是正式标准化字段, 从而导致互操作性问题.

其他协议中也出现了类似问题:

  • HTTP: "X-Forwarded-For" 等头部被广泛部署, 但由于前缀存在而难以标准化.

  • SIP: 用于私有头部 (面向封闭网络) 的 "P-" 前缀泄漏到更广泛的互联网中, 如 [RFC5727] 所记录.

  • 媒体类型: 实验性媒体类型的 "x-" 前缀导致了相同问题, 如 [RFC4288] 所记录.

何时隔离可能有合理性 (When Segregation Might Be Justified)​

在某些情况下, 隔离给定应用协议中使用的参数命名空间可能是合理的:

  1. 当某些参数极不可能被标准化时. 在这种情况下, 特定于实现和私有使用的参数至少可以包含组织名称 (例如 "ExampleInc-foo", 或者按 [RFC4288] 的方式使用 "VND.ExampleInc.foo") 或主域名 (例如 "com.example.foo", 或统一资源标识符 [RFC3986], 如 "http://example.com/foo"). 在少数情况下, 真正的实验性参数可以使用无意义名称, 例如无意义词、哈希函数输出, 或通用唯一标识符 (Universally Unique Identifiers, UUID) [RFC4122].

  2. 当参数名称可能具有重要含义时. 这种情况也很少见, 因为实现者几乎总能为现有术语找到同义词 (例如用 "urgency" 代替 "priority"), 或者直接创造一个更有创意的名称 (例如 "get-it-there-fast"). 多个名称相似的参数可能造成混淆, 但无论是否试图隔离标准化和未标准化参数, 这一点都成立 (例如 "X-Priority" 可能与 "Urgency" 混淆).

  3. 当参数名称需要非常短时 (例如 [RFC5646] 中的语言标签). 在这种情况下, 分配数字而不是人类可读名称可能更高效 (例如 [RFC2939] 中的 DHCP 选项), 并可留出一定数字范围用于特定于实现的扩展或私有使用 (例如 Session Description Protocol [RFC4566] 使用的编解码器编号).

反对废弃 "X-" 约定的意见 (Objections to Deprecating the "X-" Convention)​

反对将 "X-" 约定作为应用协议最佳实践废弃的主要意见有三点:

  1. 实现者可能会将一个参数误认为另一个名称相似的参数; "X-" 前缀这种刚性区分可以让这一点更清楚. 但是, 实践中实现者被迫模糊这种区分 (例如将 "X-foo" 视为事实标准), 因而它不可避免地变得毫无意义.

  2. 冲突不可取, 标准化参数 "foo" 和未标准化参数 "foo" 同时存在会很糟糕. 但是, 名称几乎总是廉价的, 因此名为 "foo" 的实验性、特定于实现或私有使用名称, 并不会阻止标准制定组织发布类似有创意的名称, 例如 "bar".

  3. [BCP82] 题为 "Assigning Experimental and Testing Numbers Considered Useful", 因而暗示 "X-" 前缀对实验性参数也有用. 但是, BCP 82 处理的是协议编号池受到严格限制时 (例如 DHCP 选项), 或即使纯实验目的也绝对需要编号时 (例如 IP 头部的 Protocol 字段) 对协议编号的需求. 在几乎所有使用协议参数的应用协议中 (包括电子邮件头部、媒体类型、HTTP 头部、vCard 参数和属性、URN 以及 LDAP 字段名称), 命名空间并不以任何方式受限或受约束, 因此无需为私有使用或实验目的分配一块名称 (另见 [BCP26]).

结论 (Conclusion)​

因此, 将参数空间隔离为标准化区域和未标准化区域似乎几乎没有好处, 即使有也很少, 并且至少在互操作性方面具有一个显著成本.

最后于 更新