1. 引言

许多应用协议使用带有文本名称 (而非数字名称) 的参数来标识数据, 例如媒体类型, Internet mail 消息和 HTTP 请求中的头字段, vCard 参数和属性等. 历史上, 应用协议的设计者和实现者经常通过在非标准化参数名称前加上字符串 "X-" 或类似结构 (例如 "x.") 来区分标准化参数和非标准化参数, 其中 "X" 通常被理解为表示 "eXperimental" 或 "eXtension".

在这种约定下, 参数名称不仅标识数据, 还将参数的状态嵌入名称本身: 由公认标准开发组织产生的规范定义的参数 (或按照此类规范中定义的流程注册的参数) 不以 "X-" 或类似结构开头, 而在此类规范或流程之外定义的参数则以 "X-" 或类似结构开头.

如附录 A 更完整说明的那样, 多年来这种约定在文件传输, 电子邮件和 World Wide Web 等应用协议中受到鼓励. 特别是, [RFC822] 通过区分 "Extension-fields" 和 "user-defined-fields" 将其编入电子邮件规范, 但随后 [RFC2822] 基于实现和部署经验移除了该约定. 如 [RFC5727] 所述, SIP 技术中关于 "P-" 头字段也出现了类似演进. 附录 B 探讨这些变更背后的理由.

简而言之, 尽管理论上 "X-" 约定是避免标准化参数和非标准化参数之间冲突 (以及随之而来的互操作性问题) 的好方法, 但实践中, 非标准化参数泄漏到标准空间所带来的成本已经超过其收益.

本文档从电子邮件和 SIP 社区的经验出发进行概括, 内容如下:

弃用应用协议中新定义参数的 "X-" 约定, 包括已建立协议的新参数. 即使 "X-" 约定只是隐含存在而非明确规定, 此变更也适用, 例如 [RFC822] 中对电子邮件所做的处理.
对在不区分标准化参数和非标准化参数的环境中如何推进给出具体建议 (但仅适用于具有文本名称的参数, 不适用于以数字表示的参数, 后者不在本文档范围内).
不反对私有, 本地, 初步, 实验性或特定于实现的参数实践, 只反对此类参数名称中使用 "X-" 和类似结构.
不就现有 "X-" 参数应继续使用还是迁移到不带 "X-" 的格式提出建议. 这是这些参数的创建者或维护者需要决定的事项.
不覆盖那些规定在特定应用协议中使用 "X-" 的现有规范 (例如 [RFC5545] 中的 "x-name" token). 这是这些协议的设计者需要处理的事项.

本文档中的关键词 "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", 和 "OPTIONAL" 应按照 [RFC2119] 中的描述解释.