idnits 2.17.1 draft-saintandre-xdash-03.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 (July 26, 2011) is 4657 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 5226 (ref. 'BCP26') (Obsoleted by RFC 8126) -- 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 2426 (Obsoleted by RFC 6350) -- 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 2822 (Obsoleted by RFC 5322) -- Obsolete informational reference (is this intentional?): RFC 3406 (Obsoleted by RFC 8141) -- Obsolete informational reference (is this intentional?): RFC 3427 (Obsoleted by RFC 5727) -- Obsolete informational reference (is this intentional?): RFC 4288 (Obsoleted by RFC 6838) -- Obsolete informational reference (is this intentional?): RFC 4566 (Obsoleted by RFC 8866) -- Obsolete informational reference (is this intentional?): RFC 5451 (Obsoleted by RFC 7001) Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 13 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 D. Crocker 5 Expires: January 27, 2012 Brandenburg InternetWorking 6 M. Nottingham 7 July 26, 2011 9 Deprecating Use of the "X-" Prefix in Application Protocols 10 draft-saintandre-xdash-03 12 Abstract 14 Historically, there has often been a perceived distinction between 15 "standard" and "non-standard" parameters (such as media types and 16 header fields), by prefixing the latter with the string "X-" or 17 similar constructions (e.g., "x."). 19 In practice, this convention causes more problems than it solves. 20 Therefore, this document deprecates the "X-" convention for most 21 application protocol parameters. 23 Status of this Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 This Internet-Draft will expire on January 27, 2012. 40 Copyright Notice 42 Copyright (c) 2011 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 3. Recommendations for New Parameters . . . . . . . . . . . . . . 3 60 4. Recommendations for Application Protocols . . . . . . . . . . 4 61 5. Security Considerations . . . . . . . . . . . . . . . . . . . 4 62 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 63 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 5 64 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5 65 8.1. Normative References . . . . . . . . . . . . . . . . . . . 5 66 8.2. Informative References . . . . . . . . . . . . . . . . . . 5 67 Appendix A. Background . . . . . . . . . . . . . . . . . . . . . 7 68 Appendix B. Analysis . . . . . . . . . . . . . . . . . . . . . . 9 69 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 71 1. Introduction 73 Many application protocols use named parameters to identify data 74 (media types, header fields in Internet mail messages and HTTP 75 requests, etc.). Historically, protocol designers and implementers 76 have often distinguished between "standard" and "non-standard" 77 parameters by prefixing the latter with the string "X-" or similar 78 constructions (e.g., "x."), where the "X" is commonly understood to 79 stand for "eXperimental" or "eXtension". 81 Although in theory the "X-" convention was a good way to avoid 82 collisions (and attendant interoperability problems) between standard 83 parameters and non-standard parameters, in practice the costs 84 associated with the advancement of non-standard parameters into the 85 standards space outweigh the benefits. Therefore this document 86 deprecates the "X-" convention for most application protocols by 87 making specific recommendations. 89 See Appendix A for background about the "X-" convention, and 90 Appendix B for the reasoning that led to these recommendations. 92 2. Terminology 94 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 95 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 96 "OPTIONAL" in this document are to be interpreted as described in 97 [RFC2119]. 99 3. Recommendations for New Parameters 101 Creators of new parameters in existing protocols (e.g., HTTP headers, 102 Internet media types) -- regardless of who creates them: 104 1. SHOULD by default assume that all parameters they create have the 105 potential to advance to a standard. 107 2. SHOULD utilise meaningful but currently unused names WITHOUT the 108 "X-" prefix, when there is a potential for it to becomes widely 109 used and/or standardized (e.g., because an extension is public or 110 awaiting wider validation) . 112 3. SHOULD follow conventions specific to the parameter when creating 113 parameters for use in implementation-specific applications or on 114 private networks. Depending on the parameter, this could be a 115 URI (e.g., "http://example.com/foo"), a name that incorporates 116 the relevant organization's name (e.g., "ExampleInc-foo" or 117 "VND.ExampleInc.foo") or primary domain name (e.g., 118 "com.example.foo"). 120 4. SHOULD generate meaningless names for parameters that will not 121 become standardized (e.g., because the extension is completely 122 private or purely speculative). For example, the output of a 123 hash function (e.g., "esuDj6Ssil8kDn4yfvvdwMTRhlU"), a UUID 124 (e.g., "1AB9C36F-1618-4C1F-855D-96B5BAFC7FB3"), or even a 125 nonsense word (e.g., "foobarbazqux") . 127 4. Recommendations for Application Protocols 129 Authors of application protocols that allow extension using 130 parameters: 132 1. SHOULD provide unlimited registries with well-defined 133 registration procedures and SHOULD mandate registration of all 134 non-private parameters, independent of the form of the parameter 135 names. 137 2. MUST NOT assume that any parameter with the "X-" prefix is non- 138 standard and that any parameter without the "X-" prefix is 139 standard. 141 3. SHOULD identify a convention (and reserve delimiters as 142 necessary) to allow local or implementation-specific extensions; 143 e.g. the "vnd." scheme in [RFC4288]. 144 4. SHOULD NOT bar parameters with the "X-" prefix from being 145 registered with IANA, as all existing parameters with the "X-" 146 prefix need to be registered with IANA. 148 5. Security Considerations 150 Interoperability and migration issues with security-critical 151 parameters can result in unnecessary vulnerabilities. 153 6. IANA Considerations 155 [TODO: describe changes to existing procedures to IANA; update RFCs?] 157 7. Acknowledgements 159 Thanks to Claudio Allocchio, Adam Barth, Nathaniel Borenstein, Eric 160 Burger, Al Constanzo, Dave Cridland, Martin Duerst, Frank Ellermann, 161 J.D. Falk, Tony Finch, Tony Hansen, Ted Hardie, Joe Hildebrand, 162 Alfred Hoenes, Paul Hoffman, Eric Johnson, John Klensin, Graham 163 Klyne, Murray Kucherawy, Eliot Lear, John Levine, Bill McQuillan, 164 Alexey Melnikov, Subramanian Moonesamy, Keith Moore, Ben Niven- 165 Jenkins, Dirk Pranke, Randy Presuhn, Julian Reschke, Doug Royer, 166 Andrew Sullivan, Martin Thomson, Nicolas Williams, Tim Williams, and 167 Kurt Zeilenga for their feedback. 169 8. References 171 8.1. Normative References 173 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 174 Requirement Levels", BCP 14, RFC 2119, March 1997. 176 8.2. Informative References 178 [BCP9] Bradner, S., "The Internet Standards Process -- Revision 179 3", BCP 9, RFC 2026, October 1996. 181 [BCP26] Narten, T. and H. Alvestrand, "Guidelines for Writing an 182 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 183 May 2008. 185 [BCP82] Narten, T., "Assigning Experimental and Testing Numbers 186 Considered Useful", BCP 82, RFC 3692, January 2004. 188 [RFC691] Harvey, B., "One more try on the FTP", RFC 691, June 1975. 190 [RFC737] Harrenstien, K., "FTP extension: XSEN", RFC 737, 191 October 1977. 193 [RFC743] Harrenstien, K., "FTP extension: XRSQ/XRCP", RFC 743, 194 December 1977. 196 [RFC775] Mankins, D., Franklin, D., and A. Owen, "Directory 197 oriented FTP commands", RFC 775, December 1980. 199 [RFC822] Crocker, D., "Standard for the format of ARPA Internet 200 text messages", STD 11, RFC 822, August 1982. 202 [RFC1123] Braden, R., "Requirements for Internet Hosts - Application 203 and Support", STD 3, RFC 1123, October 1989. 205 [RFC1154] Robinson, D. and R. Ullmann, "Encoding header field for 206 internet messages", RFC 1154, April 1990. 208 [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 209 Extensions (MIME) Part One: Format of Internet Message 210 Bodies", RFC 2045, November 1996. 212 [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 213 Extensions (MIME) Part Two: Media Types", RFC 2046, 214 November 1996. 216 [RFC2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions) 217 Part Three: Message Header Extensions for Non-ASCII Text", 218 RFC 2047, November 1996. 220 [RFC2068] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., and T. 221 Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", 222 RFC 2068, January 1997. 224 [RFC2426] Dawson, F. and T. Howes, "vCard MIME Directory Profile", 225 RFC 2426, September 1998. 227 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 228 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 229 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 231 [RFC2822] Resnick, P., "Internet Message Format", RFC 2822, 232 April 2001. 234 [RFC2939] Droms, R., "Procedures and IANA Guidelines for Definition 235 of New DHCP Options and Message Types", BCP 43, RFC 2939, 236 September 2000. 238 [RFC3406] Daigle, L., van Gulik, D., Iannella, R., and P. Faltstrom, 239 "Uniform Resource Names (URN) Namespace Definition 240 Mechanisms", BCP 66, RFC 3406, October 2002. 242 [RFC3427] Mankin, A., Bradner, S., Mahy, R., Willis, D., Ott, J., 243 and B. Rosen, "Change Process for the Session Initiation 244 Protocol (SIP)", RFC 3427, December 2002. 246 [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration 247 Procedures for Message Header Fields", BCP 90, RFC 3864, 248 September 2004. 250 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 251 Resource Identifier (URI): Generic Syntax", STD 66, 252 RFC 3986, January 2005. 254 [RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally 255 Unique IDentifier (UUID) URN Namespace", RFC 4122, 256 July 2005. 258 [RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and 259 Registration Procedures", BCP 13, RFC 4288, December 2005. 261 [RFC4512] Zeilenga, K., "Lightweight Directory Access Protocol 262 (LDAP): Directory Information Models", RFC 4512, 263 June 2006. 265 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 266 Description Protocol", RFC 4566, July 2006. 268 [RFC5064] Duerst, M., "The Archived-At Message Header Field", 269 RFC 5064, December 2007. 271 [RFC5451] Kucherawy, M., "Message Header Field for Indicating 272 Message Authentication Status", RFC 5451, April 2009. 274 [RFC5646] Phillips, A. and M. Davis, "Tags for Identifying 275 Languages", BCP 47, RFC 5646, September 2009. 277 [RFC5727] Peterson, J., Jennings, C., and R. Sparks, "Change Process 278 for the Session Initiation Protocol (SIP) and the Real- 279 time Applications and Infrastructure Area", BCP 67, 280 RFC 5727, March 2010. 282 Appendix A. Background 284 The beginnings of the "X-" convention can be found in a suggestion 285 made by Brian Harvey in 1975 with regard to FTP parameters [RFC691]: 287 Thus, FTP servers which care about the distinction between Telnet 288 print and non-print could implement SRVR N and SRVR T. Ideally the 289 SRVR parameters should be registered with Jon Postel to avoid 290 conflicts, although it is not a disaster if two sites use the same 291 parameter for different things. I suggest that parameters be 292 allowed to be more than one letter, and that an initial letter X 293 be used for really local idiosyncracies. 295 This "X" prefix was subsequently used in [RFC737], [RFC743], and 296 [RFC775]. This usage was noted in [RFC1123]: 298 FTP allows "experimental" commands, whose names begin with "X". 299 If these commands are subsequently adopted as standards, there may 300 still be existing implementations using the "X" form.... All FTP 301 implementations SHOULD recognize both forms of these commands, by 302 simply equating them with extra entries in the command lookup 303 table. 305 The "X-" convention has been used for email header fields since at 306 least the publication of [RFC822] in 1982, which distinguished 307 between "Extension-fields" and "user-defined-fields" as follows: 309 The prefatory string "X-" will never be used in the names of 310 Extension-fields. This provides user-defined fields with a 311 protected set of names. 313 That rule was restated by [RFC1154] as follows: 315 Keywords beginning with "X-" are permanently reserved to 316 implementation-specific use. No standard registered encoding 317 keyword will ever begin with "X-". 319 This convention continued with various specifications for media types 320 ([RFC2045], [RFC2046], [RFC2047]), HTTP headers ([RFC2068], 321 [RFC2616]), vCard parameters and properties ([RFC2426]), Uniform 322 Resource Names ([RFC3406]), LDAP field names ([RFC4512]), and other 323 technologies. 325 However, use of the "X-" prefix in email headers was effectively 326 deprecated between the publication of [RFC822] in 1982 and the 327 publication of [RFC2822] in 2001 by removing the distinction between 328 the "extension-field" construct and the "user-defined-field" 329 construct (a similar change happened with regard to Session 330 Initiation Protocol "P-" headers when [RFC3427] was obsoleted by 331 [RFC5727]). 333 Despite the fact that parameters containing the "X-" string have been 334 effectively deprecated in email headers, they continue to be used in 335 a wide variety of application protocols. The two primary situations 336 motivating such use are: 338 1. Experiments that are intended to possibly be standardized in the 339 future, if they are successful. 341 2. Extensions that are intended to never be standardized because 342 they are intended only for use in implementation-specific 343 applications or on private networks. 345 Use of this naming convention is not mandated by the Internet 346 Standards Process [BCP9] or IANA registration rules [BCP26]. Rather 347 it is an individual choice by each specification that references the 348 convention or each administrative process that chooses to use it. In 349 particular, some standards track RFCs have interpreted the convention 350 in a normative way (e.g., [RFC822] and [RFC5451]). 352 Appendix B. Analysis 354 The primary problem with the "X-" convention is that non-standard 355 parameters have a tendency to advance into the protected space of 356 standard parameters (whether de jure or de facto), thus introducing 357 the need for migration from the "X-" name to the standard name. 358 Migration, in turn, introduces interoperability issues because older 359 implementations will support only the "X-" name and newer 360 implementations might support only the standard name. To preserve 361 interoperability, newer implementations simply support the "X-" name 362 forever, which means that the non-standard name has become a de facto 363 standard (thus obviating the need for segregation of the name space 364 into "standard" and "non-standard" in the first place). 366 We have already seen this phenomenon at work with regard to FTP in 367 the quote from [RFC1123] in the previous section. The HTTP community 368 had the same experience with the "x-gzip" and "x-compressed" media 369 types, as noted in [RFC2068]: 371 For compatibility with previous implementations of HTTP, 372 applications should consider "x-gzip" and "x-compress" to be 373 equivalent to "gzip" and "compress" respectively. 375 A similar example can be found in [RFC5064], which defined the 376 "Archived-At" message header field but also found it necessary to 377 define and register the "X-Archived-At" field: 379 For backwards compatibility, this document also describes the 380 X-Archived-At header field, a precursor of the Archived-At header 381 field. The X-Archived-At header field MAY also be parsed, but 382 SHOULD NOT be generated. 384 One of the original reasons for segregation of name spaces into 385 standard and non-standard areas was the perceived difficulty of 386 registering names. However, the solution to that problem has been 387 simpler registration rules, such as those provided by [RFC3864] and 388 [RFC4288], as well as separate registries for permanent and 389 provisional names, as explained in [RFC4288]: 391 [W]ith the simplified registration procedures described above for 392 vendor and personal trees, it should rarely, if ever, be necessary 393 to use unregistered experimental types. Therefore, use of both 394 "x-" and "x." forms is discouraged. 396 Furthermore, often standardization of a non-standard parameter or 397 protocol element leads to subtly different behavior (e.g., the 398 standard version might have different security properties as a result 399 of security review provided during the standardization process). If 400 implementers treat the old, non-standard parameter and the new, 401 standard parameter as equivalent, interoperability and security 402 problems can ensue. 404 For similar considerations with regard to the "P-" convention in the 405 Session Initiation Protocol, see [RFC5727]. 407 In some situations, segregating the name space of parameters used in 408 a given application protocol can be justified: 410 1. When it is extremely unlikely that some parameters will ever be 411 standardized. However, in this case implementation-specific and 412 private-use parameters can be Uniform Resource Identifiers 413 [RFC3986] (e.g., "http://example.com/foo") or can be prepended 414 with a string that is derived from the name or primary domain 415 name of the organization that has defined the parameter (e.g., 416 "ExampleInc-foo", "VND.ExampleInc.foo", or "com.example.foo"). 417 Similarly, truly experimental parameters can be given meaningless 418 names such as nonsense words, the output of a hash function, or 419 UUIDs [RFC4122]. 421 2. When parameter names might have significant meaning. However, 422 this case is rare, since implementers can almost always find a 423 synonym for an existing term (e.g., "urgency" instead of 424 "priority") or simply invent a more creative name (e.g., "get-it- 425 there-fast"). 427 3. When parameter names need to be very short (e.g., as in [RFC5646] 428 for language tags). However, in this case it can be more 429 efficient to assign numbers instead of human-readable names 430 (e.g., as in [RFC2939] for DCHP options) and to leave a certain 431 numeric range for implementation-specific extensions or private 432 use (e.g., as with the codec numbers used with the Session 433 Description Protocol [RFC4566]). 435 There are three primary objections to deprecating the "X-" convention 436 as a best practice for application protocols: 438 1. Implementers are easily confused and can't be expected to know 439 that a parameter is non-standard unless it contains the "X-" 440 prefix. However, implementers already are quite flexible about 441 using both prefixed and non-prefixed names based on what works in 442 the field, so the distinction between de facto names (e.g., 443 "X-foo") and de jure names (e.g., "foo") is effectively 444 meaningless. 446 2. Collisions are undesirable and it would be bad to for both a 447 standard parameter "foo" and a non-standard parameter "foo" to 448 exist simultaneously. However, names are almost always cheap, so 449 an experimental, implementation-specific, or private-use name of 450 "foo" does not prevent a standards development organization from 451 issuing a similarly creative name such as "bar". 452 3. [BCP82] is entitled "Assigning Experimental and Testing Numbers 453 Considered Useful" and therefore implies that the "X-" prefix is 454 also useful for experimental parameters. However, BCP 82 455 addresses the need for protocol numbers when the pool of such 456 numbers is strictly limited (e.g., DHCP options) or when a number 457 is absolutely required even for purely experimental purposes 458 (e.g., the Protocol field of the IP header). In almost all 459 application protocols that make use of protocol parameters 460 (including email headers, media types, HTTP headers, vCard 461 parameters and properties, URNs, and LDAP field names), the name 462 space is not limited or constrained in any way, so there is no 463 need to assign a block of names for private use or experimental 464 purposes (see also [BCP26]). 466 Therefore it appears that segregating the parameter space into a 467 standard area and a non-standard area has few if any benefits, and 468 has at least one significant cost in terms of interoperability. 470 Authors' Addresses 472 Peter Saint-Andre 473 Cisco 474 1899 Wyknoop Street, Suite 600 475 Denver, CO 80202 476 USA 478 Phone: +1-303-308-3282 479 Email: psaintan@cisco.com 480 D. Crocker 481 Brandenburg InternetWorking 482 675 Spruce Dr. 483 Sunnyvale 484 USA 486 Phone: +1.408.246.8253 487 Email: dcrocker@bbiw.net 488 URI: http://bbiw.net 490 Mark Nottingham 492 Email: mnot@mnot.net 493 URI: http://www.mnot.net