Appendix A. 背景 (Background)
多年来, "X-" 前缀一直用于应用协议中的实验性参数或扩展参数. 示例包括:
文件传输协议 (File Transfer Protocol, FTP)
文件传输协议 (File Transfer Protocol, FTP) [RFC775] 包含 "experimental commands" 的概念, 其中一些命令以 "X" 为前缀 (例如 "XSEN"、"XRSQ"、"XRCP"), 由此形成实验性 FTP 命令应使用 "X" 前缀的约定. 这一约定后来扩展到其他协议.
[RFC691] 的作者认为这一约定存在两个不足:
-
当两个不同实现使用相同 "X-" 名称时, "X" 前缀无法防止名称冲突.
-
带有 "X-" 前缀的参数可能进入永久使用状态, 到那时移除前缀会导致互操作性问题.
尽管存在这些问题, "X-" 前缀约定仍成为常见实践.
电子邮件头部 (Email Headers)
早期电子邮件头部规范 (例如 [RFC822]) 区分了 "extension-fields" (正式标准化) 和 "user-defined-fields" (未标准化). 用户定义字段被要求以 "X-" 开头. 这一约定延续到 [RFC1123], 并在 MIME 的 [RFC2045]、[RFC2046] 和 [RFC2047] 中被编纂.
但是, [RFC2822] 移除了这一区分, 并指出 "X-" 约定 "有一种不幸的倾向, 会让开发者假定 [这些字段] 永远不需要注册或标准化". 当 "X-" 字段被广泛部署时, 这导致了显著的互操作性问题.
其他电子邮件相关协议也发生了类似变化. 例如, [RFC3864] 为所有电子邮件头字段建立了注册机制, 不论它们是否带有 "X-" 前缀.
HTTP Headers
早期 HTTP 规范 ([RFC2068], 后来的 [RFC2616]) 并未强制扩展头使用 "X-" 约定, 但它成为了常见实践. 这导致类似 "X-Forwarded-For" 这样被广泛部署的头部难以标准化, 因为移除 "X-" 前缀会破坏兼容性.
vCard and iCalendar
vCard 规范 [RFC2426] 允许带有 "X-" 前缀的扩展类型和属性. 类似地, iCalendar [RFC5545] 对实验性属性和参数使用 "x-name" 结构. 这些规范继续允许此类名称, 同时也为所有属性和参数提供注册机制.
URN 命名空间 (URN Namespaces)
URN 命名空间定义机制 [RFC3406] 为实验目的保留某些命名空间 (以 "x-" 开头的 NID 值), 但也指出此类名称不应在生产系统中使用.
LDAP 字段名称 (LDAP Field Names)
LDAP [RFC4512] 允许以 "x-" 开头的属性描述用于私有或实验用途, 但如有需要, 这些属性可以被标准化.
结论 (Conclusion)
历史记录表明, 虽然 "X-" 约定的初衷是防止标准化参数和未标准化参数之间发生冲突, 但它往往未能实现这一目标, 并且当实验性参数被广泛部署时, 造成了显著的迁移和互操作性问题.