idnits 2.17.1 draft-saintandre-xdash-considered-harmful-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 19, 2010) is 4937 days in the past. Is this intentional? Checking references for intended status: Best Current Practice ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Obsolete informational reference (is this intentional?): RFC 822 (Obsoleted by RFC 2822) -- Obsolete informational reference (is this intentional?): RFC 1154 (Obsoleted by RFC 1505) -- Obsolete informational reference (is this intentional?): RFC 2068 (Obsoleted by RFC 2616) -- Obsolete informational reference (is this intentional?): RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) -- Obsolete informational reference (is this intentional?): RFC 2821 (Obsoleted by RFC 5321) -- Obsolete informational reference (is this intentional?): RFC 4288 (Obsoleted by RFC 6838) Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group P. Saint-Andre 3 Internet-Draft Cisco 4 Intended status: BCP October 19, 2010 5 Expires: April 22, 2011 7 "X-" Considered Harmful 8 draft-saintandre-xdash-considered-harmful-01 10 Abstract 12 Many application protocols use named parameters to represent data 13 (for example, header fields in Internet mail messages and HTTP 14 requests). Historically, protocol designers and implementers have 15 often differentiated between "standard" and "experimental" parameters 16 by prefixing experimental parameters with the string "X-". This 17 document argues that, on balance, the "X-" convention has more costs 18 than benefits. 20 Status of this Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on April 22, 2011. 37 Copyright Notice 39 Copyright (c) 2010 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents 44 (http://trustee.ietf.org/license-info) in effect on the date of 45 publication of this document. Please review these documents 46 carefully, as they describe your rights and restrictions with respect 47 to this document. Code Components extracted from this document must 48 include Simplified BSD License text as described in Section 4.e of 49 the Trust Legal Provisions and are provided without warranty as 50 described in the Simplified BSD License. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 2. Argument . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 3. Security Considerations . . . . . . . . . . . . . . . . . . . . 4 57 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 4 58 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 5 59 6. Informative References . . . . . . . . . . . . . . . . . . . . 5 60 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 6 62 1. Introduction 64 Many application protocols use named parameters to represent data 65 (for example, header fields in Internet mail messages and HTTP 66 requests). Historically, protocol designers and implementers have 67 often differentiated between "standard" and "experimental" parameters 68 by prefixing experimental parameters with the string "X-", where the 69 "X" stands for "eXperimental". This document argues that on balance 70 the "X-" convention has more costs than benefits. 72 2. Argument 74 The "X-" convention has been in use for email header fields since the 75 publication of [RFC822] in 1982, which distinguished between 76 Extension-fields and user-defined-fields as follows: 78 The prefatory string "X-" will never be used in the names of 79 Extension-fields. This provides user-defined fields with a 80 protected set of names. 82 That rule was restated by [RFC1154] as follows: 84 Keywords beginning with "X-" are permanently reserved to 85 implementation-specific use. No standard registered encoding 86 keyword will ever begin with "X-". 88 This convention continued with various specifications for MIME 89 [RFC2045] [RFC2046] [RFC2047], email [RFC2821] [RFC5321], HTTP 90 [RFC2068] [RFC2616], and other technologies. 92 The primary problem with the "X-" convention is that experimental or 93 implementation-specific parameters have a tendency to become 94 standardized (whether de jure or de facto), thus introducing the need 95 for migration from the "X-" name to the standardized name. 96 Migration, in turn, introduces interoperability issues because older 97 implementations will support only the "X-" name and newer 98 implementations might support only the standardized name. To 99 preserve interoperability, newer implementations simply support the 100 "X-" name forever, which means that the experimental name becomes a 101 de facto standard (thus obviating the need for segregation of the 102 name spaces in the first place). We can see this phenomenon at work 103 in [RFC2068]: 105 For compatibility with previous implementations of HTTP, 106 applications should consider "x-gzip" and "x-compress" to be 107 equivalent to "gzip" and "compress" respectively. 109 One of the original reasons for segregation of name spaces into 110 standard and experimental areas was the perceived difficulty of 111 registering names. However, the solution to that problem has been 112 simpler registration rules, such as those provided by [RFC3864] and 113 [RFC4288], as well as separate registries for permanent and 114 provisional names. Indeed, [RFC4288] explicitly calls out the 115 implications for experimental names: 117 [W]ith the simplified registration procedures described above for 118 vendor and personal trees, it should rarely, if ever, be necessary 119 to use unregistered experimental types. Therefore, use of both 120 "x-" and "x." forms is discouraged. 122 In some limited situations, segregating a name space can be 123 justified; for example, when the names need to be very small (as in 124 [RFC5646]) or when the names have significant meaning. However, in 125 general, segregating experimental or implementation-specific 126 parameters into an "X-" ghetto has few if any benefits, and has at 127 least one significant interoperability cost. The practice is at best 128 useless and at worst harmful. 130 The primary objections to discarding the "X-" convention are: 132 o Implementers are easily confused. However, implementers already 133 are quite flexible about using both prefixed and non-prefixed 134 names based on what works in the field, so the distinction between 135 de facto names (e.g., "X-foo") and de jure names (e.g., "foo") is 136 meaningless to them. 138 o Collisions are undesirable. However, names are usually cheap, so 139 an experimental or implementation-specific name of "foo" does not 140 prevent a standards development organization from issuing a 141 similarly creative name such as "bar". 143 Therefore, this document recommends against the creation of new names 144 with the special "X-" prefix in IETF protocols. 146 3. Security Considerations 148 Interoperability and migration issues with security-critical 149 paramaters can result in unnecessary vulnerabilities. 151 4. IANA Considerations 153 This document has no actions for the IANA. 155 5. Acknowledgements 157 Thanks to Adam Barth, Dave Crocker, Martin Duerst, Paul Hoffman, 158 Graham Klyne, Alexey Melnikov, Mark Nottingham, and Randy Presuhn for 159 feedback. 161 6. Informative References 163 [RFC822] Crocker, D., "Standard for the format of ARPA Internet 164 text messages", STD 11, RFC 822, August 1982. 166 [RFC1154] Robinson, D. and R. Ullmann, "Encoding header field for 167 internet messages", RFC 1154, April 1990. 169 [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 170 Extensions (MIME) Part One: Format of Internet Message 171 Bodies", RFC 2045, November 1996. 173 [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 174 Extensions (MIME) Part Two: Media Types", RFC 2046, 175 November 1996. 177 [RFC2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions) 178 Part Three: Message Header Extensions for Non-ASCII Text", 179 RFC 2047, November 1996. 181 [RFC2068] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., and T. 182 Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", 183 RFC 2068, January 1997. 185 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 186 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 187 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 189 [RFC2821] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, 190 April 2001. 192 [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration 193 Procedures for Message Header Fields", BCP 90, RFC 3864, 194 September 2004. 196 [RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and 197 Registration Procedures", BCP 13, RFC 4288, December 2005. 199 [RFC5321] Klensin, J., "Simple Mail Transfer Protocol", RFC 5321, 200 October 2008. 202 [RFC5646] Phillips, A. and M. Davis, "Tags for Identifying 203 Languages", BCP 47, RFC 5646, September 2009. 205 Author's Address 207 Peter Saint-Andre 208 Cisco 209 1899 Wyknoop Street, Suite 600 210 Denver, CO 80202 211 USA 213 Phone: +1-303-308-3282 214 Email: psaintan@cisco.com