Internet Engineering Task Force (IETF) P. Saint-Andre
Request for Comments: 6648 Cisco Systems, Inc.
BCP: 178 D. Crocker
Category: Best Current Practice Brandenburg InternetWorking
ISSN: 2070-1721 M. Nottingham
Rackspace
June 2012
Internet Engineering Task Force (IETF) P. Saint-Andre
Request for Comments: 6648 Cisco Systems, Inc.
BCP: 178 D. Crocker
Category: Best Current Practice Brandenburg InternetWorking
ISSN: 2070-1721 M. Nottingham
Rackspace
June 2012
Deprecating the "X-" Prefix and Similar Constructs in Application Protocols
不推荐应用程序协议中的“X-”前缀和类似结构
Abstract
摘要
Historically, designers and implementers of application protocols have often distinguished between standardized and unstandardized parameters by prefixing the names of unstandardized parameters with the string "X-" or similar constructs. In practice, that convention causes more problems than it solves. Therefore, this document deprecates the convention for newly defined parameters with textual (as opposed to numerical) names in application protocols.
历史上，应用程序协议的设计者和实现者通常通过在非标准化参数的名称前加上字符串“X-”或类似结构来区分标准化参数和非标准化参数。在实践中，该公约造成的问题多于它解决的问题。因此，本文档反对应用程序协议中新定义的具有文本（而非数字）名称的参数的约定。
Status of This Memo
关于下段备忘
This memo documents an Internet Best Current Practice.
本备忘录记录了互联网最佳实践。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on BCPs is available in Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关BCP的更多信息，请参见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6648.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6648.
Copyright Notice
版权公告
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2012 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction ....................................................2
2. Recommendations for Implementers of Application Protocols .......4
3. Recommendations for Creators of New Parameters ..................4
4. Recommendations for Protocol Designers ..........................4
5. Security Considerations .........................................5
6. IANA Considerations .............................................5
7. Acknowledgements ................................................5
Appendix A. Background ............................................6
Appendix B. Analysis ..............................................7
References ........................................................10
Normative References ...........................................10
Informative References .........................................10
1. Introduction ....................................................2
2. Recommendations for Implementers of Application Protocols .......4
3. Recommendations for Creators of New Parameters ..................4
4. Recommendations for Protocol Designers ..........................4
5. Security Considerations .........................................5
6. IANA Considerations .............................................5
7. Acknowledgements ................................................5
Appendix A. Background ............................................6
Appendix B. Analysis ..............................................7
References ........................................................10
Normative References ...........................................10
Informative References .........................................10
Many application protocols use parameters with textual (as opposed to numerical) names to identify data (media types, header fields in Internet mail messages and HTTP requests, vCard parameters and properties, etc.). Historically, designers and implementers of application protocols have often distinguished between standardized and unstandardized parameters by prefixing the names of unstandardized parameters with the string "X-" or similar constructs (e.g., "x."), where the "X" is commonly understood to stand for "eXperimental" or "eXtension".
许多应用程序协议使用带有文本（而非数字）名称的参数来标识数据（媒体类型、Internet邮件消息和HTTP请求中的头字段、vCard参数和属性等）。历史上，应用程序协议的设计者和实现者通常通过在非标准化参数的名称前加上字符串“X-”或类似结构（例如，“X”）来区分标准化参数和非标准化参数，其中“X”通常被理解为代表“实验”或“扩展”。
Under this convention, the name of a parameter not only identified the data, but also embedded the status of the parameter into the name itself: a parameter defined in a specification produced by a recognized standards development organization (or registered according to processes defined in such a specification) did not start
根据这一约定，参数的名称不仅标识数据，而且还将参数的状态嵌入名称本身：由公认的标准开发组织（或根据此类规范中定义的过程注册）制定的规范中定义的参数没有启动
with "X-" or similar constructs, whereas a parameter defined outside such a specification or process started with "X-" or similar constructs.
使用“X-”或类似构造，而在此类规范或流程之外定义的参数以“X-”或类似构造开始。
As explained more fully under Appendix A, this convention was encouraged for many years in application protocols such as file transfer, email, and the World Wide Web. In particular, it was codified for email by [RFC822] (via the distinction between "Extension-fields" and "user-defined-fields"), but then removed by [RFC2822] based on implementation and deployment experience. A similar progression occurred for SIP technologies with regard to the "P-" header, as explained in [RFC5727]. The reasoning behind those changes is explored under Appendix B.
如附录A所述，多年来，该公约在文件传输、电子邮件和万维网等应用协议中得到鼓励。特别是，[RFC822]（通过“扩展字段”和“用户定义字段”之间的区别）将其编码为电子邮件，但根据实施和部署经验，[RFC2822]将其删除。如[RFC5727]所述，SIP技术在“P-”报头方面也取得了类似的进展。附录B探讨了这些变化背后的原因。
In short, although in theory the "X-" convention was a good way to avoid collisions (and attendant interoperability problems) between standardized parameters and unstandardized parameters, in practice the benefits have been outweighed by the costs associated with the leakage of unstandardized parameters into the standards space.
简言之，尽管理论上“X-”约定是避免标准化参数和非标准化参数之间发生冲突（以及随之而来的互操作性问题）的好方法，但在实践中，非标准化参数泄漏到标准空间的相关成本已经超过了其好处。
This document generalizes from the experience of the email and SIP communities by doing the following:
本文档通过以下方式总结了电子邮件和SIP社区的经验：
1. Deprecates the "X-" convention for newly defined parameters in application protocols, including new parameters for established protocols. This change applies even where the "X-" convention was only implicit, and not explicitly provided, such as was done for email in [RFC822].
1. 反对应用程序协议中新定义参数的“X-”约定，包括已建立协议的新参数。即使“X-”约定只是隐式的，而不是显式的，如[RFC822]中对电子邮件所做的那样，这种更改也适用。
2. Makes specific recommendations about how to proceed in a world without the distinction between standardized and unstandardized parameters (although only for parameters with textual names, not parameters that are expressed as numbers, which are out of the scope of this document).
2. 就如何在不区分标准化参数和非标准化参数的情况下进行操作提出了具体建议（尽管仅适用于具有文本名称的参数，而不适用于以数字表示的参数，这超出了本文档的范围）。
3. Does not recommend against the practice of private, local, preliminary, experimental, or implementation-specific parameters, only against the use of "X-" and similar constructs in the names of such parameters.
3. 不建议使用私有的、本地的、初步的、实验性的或实现特定的参数，只建议使用“X-”和类似的构造作为这些参数的名称。
4. Makes no recommendation as to whether existing "X-" parameters ought to remain in use or be migrated to a format without the "X-"; this is a matter for the creators or maintainers of those parameters.
4. 对于现有的“X-”参数是否应该继续使用或迁移到没有“X-”的格式，没有提出建议；这是这些参数的创建者或维护者的问题。
5. Does not override existing specifications that legislate the use of "X-" for particular application protocols (e.g., the "x-name" token in [RFC5545]); this is a matter for the designers of those protocols.
5. 不覆盖对特定应用协议（例如，[RFC5545]中的“X-name”标记）使用“X-”进行立法的现有规范；这是那些协议设计者的事。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“建议”、“不建议”、“可”和“可选”应按照[RFC2119]中的说明进行解释。
Implementations of application protocols MUST NOT make any assumptions about the status of a parameter, nor take automatic action regarding a parameter, based solely on the presence or absence of "X-" or a similar construct in the parameter's name.
应用程序协议的实现不得仅基于参数名称中是否存在“X-”或类似构造，对参数的状态做出任何假设，也不得对参数采取自动操作。
Creators of new parameters to be used in the context of application protocols:
要在应用程序协议上下文中使用的新参数的创建者：
1. SHOULD assume that all parameters they create might become standardized, public, commonly deployed, or usable across multiple implementations.
1. 应该假设他们创建的所有参数都可能成为标准化的、公共的、通常部署的或跨多个实现可用的。
2. SHOULD employ meaningful parameter names that they have reason to believe are currently unused.
2. 应该使用有理由相信当前未使用的有意义的参数名称。
3. SHOULD NOT prefix their parameter names with "X-" or similar constructs.
3. 不应在其参数名称前加上“X-”或类似的结构。
Note: If the relevant parameter name space has conventions about associating parameter names with those who create them, a parameter name could incorporate the organization's name or primary domain name (see Appendix B for examples).
注意：如果相关参数名称空间具有将参数名称与创建它们的人关联的约定，则参数名称可以包含组织名称或主域名（示例请参见附录B）。
Designers of new application protocols that allow extensions using parameters:
允许使用参数进行扩展的新应用程序协议的设计者：
1. SHOULD establish registries with potentially unlimited value-spaces, defining both permanent and provisional registries if appropriate.
1. 应建立具有潜在无限价值空间的登记处，并在适当情况下定义永久登记处和临时登记处。
2. SHOULD define simple, clear registration procedures.
2. 应定义简单、清晰的注册程序。
3. SHOULD mandate registration of all non-private parameters, independent of the form of the parameter names.
3. 应强制注册所有非私有参数，独立于参数名称的形式。
4. SHOULD NOT prohibit parameters with an "X-" prefix or similar constructs from being registered.
4. 不应禁止注册带有“X-”前缀或类似构造的参数。
5. MUST NOT stipulate that a parameter with an "X-" prefix or similar constructs needs to be understood as unstandardized.
5. 不得规定带有“X-”前缀或类似结构的参数需要理解为非标准化。
6. MUST NOT stipulate that a parameter without an "X-" prefix or similar constructs needs to be understood as standardized.
6. 不得规定不带“X-”前缀或类似结构的参数需要理解为标准化参数。
Interoperability and migration issues with security-critical parameters can result in unnecessary vulnerabilities (see Appendix B for further discussion).
具有安全关键参数的互操作性和迁移问题可能会导致不必要的漏洞（有关进一步讨论，请参阅附录B）。
As a corollary to the recommendation provided under Section 2, implementations MUST NOT assume that standardized parameters are "secure" whereas unstandardized parameters are "insecure", based solely on the names of such parameters.
作为第2节所述建议的必然结果，实施不得仅基于此类参数的名称，假设标准化参数是“安全的”，而非标准化参数是“不安全的”。
This document does not modify registration procedures currently in force for various application protocols. However, such procedures might be updated in the future to incorporate the best practices defined in this document.
本文件不修改目前对各种应用协议有效的注册程序。但是，此类程序可能在将来更新，以纳入本文件中定义的最佳实践。
Thanks to Claudio Allocchio, Adam Barth, Nathaniel Borenstein, Eric Burger, Stuart Cheshire, Al Constanzo, Dave Cridland, Ralph Droms, Martin Duerst, Frank Ellermann, J.D. Falk, Ned Freed, Tony Finch, Randall Gellens, Tony Hansen, Ted Hardie, Joe Hildebrand, Alfred Hoenes, Paul Hoffman, Eric Johnson, Scott Kelly, Scott Kitterman, John Klensin, Graham Klyne, Murray Kucherawy, Eliot Lear, John Levine, Bill McQuillan, Alexey Melnikov, Subramanian Moonesamy, Keith Moore, Ben Niven-Jenkins, Zoltan Ordogh, Tim Petch, Dirk Pranke, Randy Presuhn, Julian Reschke, Dan Romascanu, Doug Royer, Andrew Sullivan, Henry Thompson, Martin Thomson, Matthew Wild, Nicolas Williams, Tim Williams, Mykyta Yevstifeyev, and Kurt Zeilenga for their feedback.
感谢克劳迪奥·阿洛奇、亚当·巴特、纳撒尼尔·博伦斯坦、埃里克·伯格、斯图亚特·切希尔、艾尔·康斯坦佐、戴夫·克里德兰、拉尔夫·德罗姆斯、马丁·杜尔斯、弗兰克·埃勒曼、J.D.福尔克、内德·弗里德、托尼·芬奇、兰德尔·盖伦斯、托尼·汉森、泰德·哈迪、乔·希尔德布兰德、阿尔弗雷德·霍恩斯、保罗·霍夫曼、埃里克·约翰逊、斯科特·凯利、斯科特·基特曼、约翰·克莱辛，格雷厄姆·克莱恩、默里·库奇拉维、艾略特·李尔、约翰·莱文、比尔·麦克奎兰、阿列克西·梅尔尼科夫、亚斋月的穆内萨米、基思·摩尔、本·尼文·詹金斯、佐尔坦·奥多格、蒂姆·佩奇、德克·普拉克、兰迪·普雷森、朱利安·雷什克、丹·罗马斯坎努、道格·罗耶、安德鲁·沙利文、亨利·汤普森、马丁·汤姆森、马修·怀尔德、尼古拉斯·威廉姆斯、蒂姆·威廉姆斯、，Mykyta Yevstifeyev和Kurt Zeilenga感谢他们的反馈。
The beginnings of the "X-" convention can be found in a suggestion made by Brian Harvey in 1975 with regard to FTP parameters [RFC691]:
“X-”约定的开始可以在Brian Harvey于1975年提出的关于FTP参数[RFC691]的建议中找到：
Thus, FTP servers which care about the distinction between Telnet print and non-print could implement SRVR N and SRVR T. Ideally the SRVR parameters should be registered with Jon Postel to avoid conflicts, although it is not a disaster if two sites use the same parameter for different things. I suggest that parameters be allowed to be more than one letter, and that an initial letter X be used for really local idiosyncracies [sic].
因此，关心Telnet打印和非打印之间区别的FTP服务器可以实现SRVR N和SRVR T。理想情况下，SRVR参数应该向Jon Postel注册以避免冲突，尽管如果两个站点对不同的事情使用相同的参数，这并不是灾难。我建议允许参数超过一个字母，并且首字母X用于真正的本地特性[sic]。
This "X" prefix was subsequently used in [RFC737], [RFC743], and [RFC775]. This usage was noted in [RFC1123]:
该“X”前缀随后在[RFC737]、[RFC743]和[RFC775]中使用。[RFC1123]中说明了这种用法：
FTP allows "experimental" commands, whose names begin with "X".
If these commands are subsequently adopted as standards, there may
still be existing implementations using the "X" form.... All FTP
implementations SHOULD recognize both forms of these commands, by
simply equating them with extra entries in the command lookup
table.
FTP allows "experimental" commands, whose names begin with "X".
If these commands are subsequently adopted as standards, there may
still be existing implementations using the "X" form.... All FTP
implementations SHOULD recognize both forms of these commands, by
simply equating them with extra entries in the command lookup
table.
The "X-" convention has been used for email header fields since at least the publication of [RFC822] in 1982, which distinguished between "Extension-fields" and "user-defined-fields" as follows:
至少自1982年[RFC822]发布以来，“X-”约定就一直用于电子邮件标题字段，它将“扩展字段”和“用户定义字段”区分如下：
The prefatory string "X-" will never be used in the names of Extension-fields. This provides user-defined fields with a protected set of names.
前言字符串“X-”永远不会在扩展字段的名称中使用。这为用户定义的字段提供了一组受保护的名称。
That rule was restated by [RFC1154] as follows:
[RFC1154]将该规则重申如下：
Keywords beginning with "X-" are permanently reserved to implementation-specific use. No standard registered encoding keyword will ever begin with "X-".
以“X-”开头的关键字永久保留给特定于实现的使用。任何标准的注册编码关键字都不会以“X-”开头。
This convention continued with various specifications for media types ([RFC2045], [RFC2046], [RFC2047]), HTTP headers ([RFC2068], [RFC2616]), vCard parameters and properties ([RFC2426]), Uniform Resource Names ([RFC3406]), Lightweight Directory Access Protocol (LDAP) field names ([RFC4512]), and other application technologies.
此约定继续使用各种媒体类型（[RFC2045]、[RFC2046]、[RFC2047]）、HTTP头（[RFC2068]、[RFC2616]）、vCard参数和属性（[RFC2426]）、统一资源名（[RFC3406]）、轻型目录访问协议（LDAP）字段名（[RFC4512]）和其他应用程序技术的规范。
However, use of the "X-" prefix in email headers was effectively deprecated between the publication of [RFC822] in 1982 and the publication of [RFC2822] in 2001 by removing the distinction between the "extension-field" construct and the "user-defined-field"
然而，在1982年[RFC822]的发布和2001年[RFC2822]的发布之间，电子邮件标题中使用“X-”前缀的做法实际上遭到了反对，因为删除了“扩展字段”构造和“用户定义字段”之间的区别
construct (a similar change happened with regard to Session Initiation Protocol "P-" headers when [RFC3427] was obsoleted by [RFC5727]).
构造（当[RFC3427]被[RFC5727]淘汰时，会话启动协议“P-”头也发生了类似的变化）。
Despite the fact that parameters containing the "X-" string have been effectively deprecated in email headers, they continue to be used in a wide variety of application protocols. The two primary situations motivating such use are:
尽管包含“X-”字符串的参数在电子邮件头中已被有效地弃用，但它们仍在各种应用程序协议中使用。促使此类使用的两种主要情况是：
1. Experiments that are intended to possibly be standardized in the future, if they are successful.
1. 如果成功的话，将来可能被标准化的实验。
2. Extensions that are intended to never be standardized because they are intended only for implementation-specific use or for local use on private networks.
2. 永远不会被标准化的扩展，因为它们仅用于实现特定用途或专用网络上的本地用途。
Use of this naming convention is not mandated by the Internet Standards Process [BCP9] or IANA registration rules [BCP26]. Rather, it is an individual choice by each specification that references the convention or each administrative process that chooses to use it. In particular, some Standards Track RFCs have interpreted the convention in a normative way (e.g., [RFC822] and [RFC5451]).
互联网标准程序[BCP9]或IANA注册规则[BCP26]不强制使用此命名约定。相反，它是引用公约的每个规范或选择使用公约的每个管理过程的个人选择。特别是，一些标准跟踪RFC以规范的方式解释了公约（例如，[RFC822]和[RFC5451]）。
The primary problem with the "X-" convention is that unstandardized parameters have a tendency to leak into the protected space of standardized parameters, thus introducing the need for migration from the "X-" name to a standardized name. Migration, in turn, introduces interoperability issues (and sometimes security issues) because older implementations will support only the "X-" name and newer implementations might support only the standardized name. To preserve interoperability, newer implementations simply support the "X-" name forever, which means that the unstandardized name has become a de facto standard (thus obviating the need for segregation of the name space into standardized and unstandardized areas in the first place).
“X-”约定的主要问题是，非标准化参数有泄漏到标准化参数的受保护空间的趋势，因此需要从“X-”名称迁移到标准化名称。迁移反过来会带来互操作性问题（有时还会带来安全问题），因为较旧的实现只支持“X-”名称，而较新的实现可能只支持标准化名称。为了保持互操作性，较新的实现只需永远支持“X-”名称，这意味着非标准化名称已成为事实上的标准（从而从一开始就无需将名称空间划分为标准化和非标准化区域）。
We have already seen this phenomenon at work with regard to FTP in the quote from [RFC1123] in Appendix A. The HTTP community had the same experience with the "x-gzip" and "x-compress" media types, as noted in [RFC2068]:
我们已经在附录A中[RFC1123]的引用中看到了FTP方面的这种现象。HTTP社区对“x-gzip”和“x-compress”媒体类型有相同的经验，如[RFC2068]中所述：
For compatibility with previous implementations of HTTP, applications should consider "x-gzip" and "x-compress" to be equivalent to "gzip" and "compress" respectively.
为了与HTTP的先前实现兼容，应用程序应分别考虑“X-GZIP”和“X压缩”等价于“GZIP”和“压缩”。
A similar example can be found in [RFC5064], which defined the "Archived-At" message header field but also found it necessary to define and register the "X-Archived-At" field:
[RFC5064]中有一个类似的示例，它定义了“存档时间”消息头字段，但也发现有必要定义和注册“X存档时间”字段：
For backwards compatibility, this document also describes the X-Archived-At header field, a precursor of the Archived-At header field. The X-Archived-At header field MAY also be parsed, but SHOULD NOT be generated.
为了向后兼容，本文档还介绍了X-Archived-At报头字段，它是归档At报头字段的前身。X-archive-At头字段也可以被解析，但不应生成。
One of the original reasons for segregation of name spaces into standardized and unstandardized areas was the perceived difficulty of registering names. However, the solution to that problem has been simpler registration rules, such as those provided by [RFC3864] and [RFC4288]. As explained in [RFC4288]:
将姓名空间划分为标准化和非标准化区域的最初原因之一是人们认为登记姓名很困难。然而，该问题的解决方案是简化注册规则，如[RFC3864]和[RFC4288]提供的规则。如[RFC4288]所述：
[W]ith the simplified registration procedures described above for vendor and personal trees, it should rarely, if ever, be necessary to use unregistered experimental types. Therefore, use of both "x-" and "x." forms is discouraged.
[W] 通过上述供应商和个人树木的简化注册程序，很少（如果有的话）需要使用未注册的实验类型。因此，不鼓励同时使用“x-”和“x”形式。
For some name spaces, another helpful practice has been the establishment of separate registries for permanent names and provisional names, as in [RFC4395].
对于某些名称空间，另一个有用的做法是为永久名称和临时名称建立单独的登记处，如[RFC4395]。
Furthermore, often standardization of a unstandardized parameter leads to subtly different behavior (e.g., the standardized version might have different security properties as a result of security review provided during the standardization process). If implementers treat the old, unstandardized parameter and the new, standardized parameter as equivalent, interoperability and security problems can ensue. Analysis of unstandardized parameters to detect and correct flaws is, in general, a good thing and is not intended to be discouraged by the lack of distinction in element names. If an originally unstandardized parameter or protocol element is standardized and the new form has differences that affect interoperability or security properties, it would be inappropriate for implementations to treat the old form as identical to the new form.
此外，非标准化参数的标准化通常会导致细微的不同行为（例如，标准化版本可能由于标准化过程中提供的安全审查而具有不同的安全属性）。如果实现者将旧的、非标准化的参数和新的、标准化的参数视为等效参数，那么互操作性和安全性问题就会随之而来。通常，分析非标准参数以检测和纠正缺陷是一件好事，并且不会因为元素名称中缺乏区分而受到阻碍。如果最初未标准化的参数或协议元素被标准化，并且新表单具有影响互操作性或安全属性的差异，那么实现将旧表单视为与新表单相同是不合适的。
For similar considerations with regard to the "P-" convention in the Session Initiation Protocol, see [RFC5727].
有关会话启动协议中“P-”约定的类似考虑，请参见[RFC5727]。
In some situations, segregating the parameter name space used in a given application protocol can be justified:
在某些情况下，隔离给定应用程序协议中使用的参数名称空间是合理的：
1. When it is extremely unlikely that some parameters will ever be standardized. In this case, implementation-specific and private-use parameters could at least incorporate the organization's name (e.g., "ExampleInc-foo" or, consistent with [RFC4288], "VND.ExampleInc.foo") or primary domain name (e.g., "com.example.foo" or a Uniform Resource Identifier [RFC3986] such as "http://example.com/foo"). In rare cases, truly experimental parameters could be given meaningless names such as nonsense words, the output of a hash function, or Universally Unique Identifiers (UUIDs) [RFC4122].
1. 当某些参数极不可能标准化时。在这种情况下，特定于实现的私人使用参数至少可以包含组织的名称（例如，“ExampleInc.foo”或与[RFC4288]“VND.ExampleInc.foo”一致的“VND.ExampleInc.foo”）或主域名（例如，“com.example.foo”或统一资源标识符[RFC3986]，例如http://example.com/foo"). 在极少数情况下，真正的实验参数可能会被赋予无意义的名称，如无意义的单词、哈希函数的输出或通用唯一标识符（UUID）[RFC4122]。
2. When parameter names might have significant meaning. This case too is rare, since implementers can almost always find a synonym for an existing term (e.g., "urgency" instead of "priority") or simply invent a more creative name (e.g., "get-it-there-fast"). The existence of multiple similarly named parameters can be confusing, but this is true regardless if there is an attempt to segregate standardized and unstandardized parameters (e.g., "X-Priority" can be confused with "Urgency").
2. 当参数名称可能具有重要意义时。这种情况也很少见，因为实现者几乎总能找到现有术语的同义词（例如，“紧迫性”而不是“优先级”），或者干脆发明一个更具创造性的名称（例如，“快速到达目的地”）。存在多个类似命名的参数可能会令人困惑，但无论是否有人试图将标准化参数和非标准化参数分开（例如，“X优先级”可能与“紧迫性”混淆），这都是正确的。
3. When parameter names need to be very short (e.g., as in [RFC5646] for language tags). In this case, it can be more efficient to assign numbers instead of human-readable names (e.g., as in [RFC2939] for DHCP options) and to leave a certain numeric range for implementation-specific extensions or private use (e.g., as with the codec numbers used with the Session Description Protocol [RFC4566]).
3. 当参数名称需要非常短时（例如，[RFC5646]中的语言标记）。在这种情况下，可以更有效地分配数字而不是人类可读的名称（例如，如[RFC2939]中的DHCP选项），并为特定于实现的扩展或私人使用留下一定的数字范围（例如，如与会话描述协议[RFC4566]一起使用的编解码器编号）。
There are three primary objections to deprecating the "X-" convention as a best practice for application protocols:
反对将“X-”约定作为应用程序协议的最佳实践的主要原因有三个：
1. Implementers might mistake one parameter for another parameter that has a similar name; a rigid distinction such as an "X-" prefix can make this clear. However, in practice, implementers are forced to blur the distinction (e.g., by treating "X-foo" as a de facto standard), so it inevitably becomes meaningless.
1. 实现者可能会将一个参数误认为另一个具有类似名称的参数；严格的区分，如“X-”前缀可以清楚地表明这一点。然而，在实践中，实现者被迫模糊区分（例如，通过将“X-foo”视为事实标准），因此它不可避免地变得毫无意义。
2. Collisions are undesirable, and it would be bad for both a standardized parameter "foo" and a unstandardized parameter "foo" to exist simultaneously. However, names are almost always cheap, so an experimental, implementation-specific, or private-use name of "foo" does not prevent a standards development organization from issuing a similarly creative name such as "bar".
2. 冲突是不可取的，同时存在标准化参数“foo”和非标准化参数“foo”是不好的。然而，名称几乎总是便宜的，因此实验性的、特定于实现的或私人使用的“foo”名称并不妨碍标准开发组织发布类似的创造性名称，如“bar”。
3. [BCP82] is entitled "Assigning Experimental and Testing Numbers Considered Useful" and therefore implies that the "X-" prefix is also useful for experimental parameters. However, BCP 82 addresses the need for protocol numbers when the pool of such numbers is strictly limited (e.g., DHCP options) or when a number is absolutely required even for purely experimental purposes (e.g., the Protocol field of the IP header). In almost all application protocols that make use of protocol parameters (including email headers, media types, HTTP headers, vCard parameters and properties, URNs, and LDAP field names), the name space is not limited or constrained in any way, so there is no need to assign a block of names for private use or experimental purposes (see also [BCP26]).
3. [BCP82]的标题为“分配被认为有用的实验和测试数字”，因此意味着“X-”前缀也适用于实验参数。然而，当协议号码池受到严格限制（例如，DHCP选项）或即使纯粹出于实验目的（例如，IP报头的协议字段）也绝对需要号码时，BCP 82解决了对协议号码的需要。在几乎所有使用协议参数（包括电子邮件头、媒体类型、HTTP头、vCard参数和属性、URN和LDAP字段名）的应用程序协议中，名称空间没有任何限制或约束，因此无需为私人用途或实验目的分配名称块（另请参见[BCP26]).
Therefore, it appears that segregating the parameter space into a standardized area and a unstandardized area has few, if any, benefits and has at least one significant cost in terms of interoperability.
因此，将参数空间划分为标准化区域和非标准化区域似乎没有什么好处（如果有的话），并且在互操作性方面至少有一个显著的成本。
References
工具书类
Normative References
规范性引用文件
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
Informative References
资料性引用
[BCP9] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996.
[BCP9]Bradner，S.，“互联网标准过程——第3版”，BCP 9，RFC 2026，1996年10月。
[BCP26] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[BCP26]Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 5226，2008年5月。
[BCP82] Narten, T., "Assigning Experimental and Testing Numbers Considered Useful", BCP 82, RFC 3692, January 2004.
[BCP82]Narten，T.，“分配被认为有用的实验和测试数字”，BCP 82，RFC 3692，2004年1月。
[RFC691] Harvey, B., "One more try on the FTP", RFC 691, June 1975.
[RFC691]Harvey，B.，“FTP再尝试一次”，RFC6911975年6月。
[RFC737] Harrenstien, K., "FTP extension: XSEN", RFC 737, October 1977.
[RFC737]Harrenstien，K.，“FTP扩展：XSEN”，RFC737，1977年10月。
[RFC743] Harrenstien, K., "FTP extension: XRSQ/XRCP", RFC 743, December 1977.
[RFC743]Harrenstien，K.，“FTP扩展：XRSQ/XRCP”，RFC7431977年12月。
[RFC775] Mankins, D., Franklin, D., and A. Owen, "Directory oriented FTP commands", RFC 775, December 1980.
[RFC775]Mankins，D.，Franklin，D.，和A.Owen，“面向目录的FTP命令”，RFC 775，1980年12月。
[RFC822] Crocker, D., "Standard for the format of ARPA Internet text messages", STD 11, RFC 822, August 1982.
[RFC822]Crocker，D.，“ARPA互联网文本信息格式标准”，STD 11，RFC 822，1982年8月。
[RFC1123] Braden, R., "Requirements for Internet Hosts - Application and Support", STD 3, RFC 1123, October 1989.
[RFC1123]Braden，R.，“互联网主机的要求-应用和支持”，STD 3，RFC 1123，1989年10月。
[RFC1154] Robinson, D. and R. Ullmann, "Encoding header field for internet messages", RFC 1154, April 1990.
[RFC1154]Robinson，D.和R.Ullmann，“互联网消息的编码头字段”，RFC1154，1990年4月。
[RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996.
[RFC2045]Freed，N.和N.Borenstein，“多用途Internet邮件扩展（MIME）第一部分：Internet邮件正文格式”，RFC 20451996年11月。
[RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, November 1996.
[RFC2046]Freed，N.和N.Borenstein，“多用途Internet邮件扩展（MIME）第二部分：媒体类型”，RFC 20461996年11月。
[RFC2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text", RFC 2047, November 1996.
[RFC2047]Moore，K.，“MIME（多用途互联网邮件扩展）第三部分：非ASCII文本的消息头扩展”，RFC 2047，1996年11月。
[RFC2068] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2068, January 1997.
[RFC2068]菲尔丁，R.，盖蒂，J.，莫格尔，J.，尼尔森，H.，和T.伯纳斯李，“超文本传输协议——HTTP/1.1”，RFC 2068，1997年1月。
[RFC2426] Dawson, F. and T. Howes, "vCard MIME Directory Profile", RFC 2426, September 1998.
[RFC2426]Dawson，F.和T.Howes，“vCard MIME目录配置文件”，RFC 2426，1998年9月。
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC2616]菲尔丁，R.，盖蒂斯，J.，莫卧儿，J.，弗莱斯蒂克，H.，马斯特，L.，利奇，P.，和T.伯纳斯李，“超文本传输协议——HTTP/1.1”，RFC 2616，1999年6月。
[RFC2822] Resnick, P., "Internet Message Format", RFC 2822, April 2001.
[RFC2822]Resnick，P.，“互联网信息格式”，RFC 2822，2001年4月。
[RFC2939] Droms, R., "Procedures and IANA Guidelines for Definition of New DHCP Options and Message Types", BCP 43, RFC 2939, September 2000.
[RFC2939]Droms，R.，“新DHCP选项和消息类型定义的程序和IANA指南”，BCP 43，RFC 2939，2000年9月。
[RFC3406] Daigle, L., van Gulik, D., Iannella, R., and P. Faltstrom, "Uniform Resource Names (URN) Namespace Definition Mechanisms", BCP 66, RFC 3406, October 2002.
[RFC3406]Daigle，L.，van Gulik，D.，Iannella，R.，和P.Faltstrom，“统一资源名称（URN）命名空间定义机制”，BCP 66，RFC 3406，2002年10月。
[RFC3427] Mankin, A., Bradner, S., Mahy, R., Willis, D., Ott, J., and B. Rosen, "Change Process for the Session Initiation Protocol (SIP)", RFC 3427, December 2002.
[RFC3427]Mankin，A.，Bradner，S.，Mahy，R.，Willis，D.，Ott，J.，和B.Rosen，“会话启动协议（SIP）的更改过程”，RFC 3427，2002年12月。
[RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration Procedures for Message Header Fields", BCP 90, RFC 3864, September 2004.
[RFC3864]Klyne，G.，Nottingham，M.和J.Mogul，“消息头字段的注册程序”，BCP 90，RFC 3864，2004年9月。
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005.
[RFC3986]Berners Lee，T.，Fielding，R.，和L.Masinter，“统一资源标识符（URI）：通用语法”，STD 66，RFC 3986，2005年1月。
[RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally Unique IDentifier (UUID) URN Namespace", RFC 4122, July 2005.
[RFC4122]Leach，P.，Mealling，M.和R.Salz，“通用唯一标识符（UUID）URN名称空间”，RFC 4122，2005年7月。
[RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and Registration Procedures", BCP 13, RFC 4288, December 2005.
[RFC4288]Freed，N.和J.Klensin，“介质类型规范和注册程序”，BCP 13，RFC 4288，2005年12月。
[RFC4395] Hansen, T., Hardie, T., and L. Masinter, "Guidelines and Registration Procedures for New URI Schemes", BCP 35, RFC 4395, February 2006.
[RFC4395]Hansen，T.，Hardie，T.，和L.Masinter，“新URI方案的指南和注册程序”，BCP 35，RFC 4395，2006年2月。
[RFC4512] Zeilenga, K., "Lightweight Directory Access Protocol (LDAP): Directory Information Models", RFC 4512, June 2006.
[RFC4512]Zeilenga，K.，“轻量级目录访问协议（LDAP）：目录信息模型”，RFC4512，2006年6月。
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006.
[RFC4566]Handley，M.，Jacobson，V.，和C.Perkins，“SDP：会话描述协议”，RFC4566，2006年7月。
[RFC5064] Duerst, M., "The Archived-At Message Header Field", RFC 5064, December 2007.
[RFC5064]Duerst，M.“在消息头字段存档”，RFC 5064，2007年12月。
[RFC5451] Kucherawy, M., "Message Header Field for Indicating Message Authentication Status", RFC 5451, April 2009.
[RFC5451]Kucherawy，M.，“用于指示消息身份验证状态的消息头字段”，RFC 5451，2009年4月。
[RFC5545] Desruisseaux, B., "Internet Calendaring and Scheduling Core Object Specification (iCalendar)", RFC 5545, September 2009.
[RFC5545]Desruisseaux，B.“互联网日历和调度核心对象规范（iCalendar）”，RFC 55452009年9月。
[RFC5646] Phillips, A. and M. Davis, "Tags for Identifying Languages", BCP 47, RFC 5646, September 2009.
[RFC5646]Phillips，A.和M.Davis，“识别语言的标记”，BCP 47，RFC 5646，2009年9月。
[RFC5727] Peterson, J., Jennings, C., and R. Sparks, "Change Process for the Session Initiation Protocol (SIP) and the Real-time Applications and Infrastructure Area", BCP 67, RFC 5727, March 2010.
[RFC5727]Peterson，J.，Jennings，C.，和R.Sparks，“会话启动协议（SIP）和实时应用程序和基础设施领域的变更过程”，BCP 67，RFC 5727，2010年3月。
Authors' Addresses
作者地址
Peter Saint-Andre Cisco Systems, Inc. 1899 Wynkoop Street, Suite 600 Denver, CO 80202 USA
Peter Saint Andre Cisco Systems，Inc.美国科罗拉多州丹佛市温库普街1899号600室，邮编：80202
Phone: +1-303-308-3282
EMail: psaintan@cisco.com
Phone: +1-303-308-3282
EMail: psaintan@cisco.com
Dave Crocker Brandenburg InternetWorking 675 Spruce Dr. Sunnyvale, CA USA
Dave Crocker Brandenburg互联网675 Spruce Dr.Sunnyvale，加利福尼亚州，美国
Phone: +1.408.246.8253
EMail: dcrocker@bbiw.net
URI: http://bbiw.net
Phone: +1.408.246.8253
EMail: dcrocker@bbiw.net
URI: http://bbiw.net
Mark Nottingham Rackspace
马克诺丁汉货架空间
EMail: mnot@mnot.net
URI: http://www.mnot.net
EMail: mnot@mnot.net
URI: http://www.mnot.net