idnits 2.17.00 (12 Aug 2021) /tmp/idnits11580/draft-ietf-appsawg-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 (February 13, 2012) is 3749 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 4395 (Obsoleted by RFC 7595) -- 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 (==), 14 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 APPSAWG P. Saint-Andre 3 Internet-Draft Cisco Systems, Inc. 4 Intended status: BCP D. Crocker 5 Expires: August 16, 2012 Brandenburg InternetWorking 6 M. Nottingham 7 Rackspace 8 February 13, 2012 10 Deprecating Use of the "X-" Prefix in Application Protocols 11 draft-ietf-appsawg-xdash-03 13 Abstract 15 Historically, designers and implementers of application protocols 16 have often distinguished between "standard" and "non-standard" 17 parameters by prefixing the latter with the string "X-" or similar 18 constructions. In practice, this convention causes more problems 19 than it solves. Therefore, this document deprecates the "X-" 20 convention for textual parameters in application protocols. 22 Status of this Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on August 16, 2012. 39 Copyright Notice 41 Copyright (c) 2012 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 2. Recommendations for Implementers of Application Protocols . . 3 58 3. Recommendations for Creators of New Parameters . . . . . . . . 3 59 4. Recommendations for Protocol Designers . . . . . . . . . . . . 4 60 5. Security Considerations . . . . . . . . . . . . . . . . . . . 4 61 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 62 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 5 63 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5 64 8.1. Normative References . . . . . . . . . . . . . . . . . . . 5 65 8.2. Informative References . . . . . . . . . . . . . . . . . . 5 66 Appendix A. Background . . . . . . . . . . . . . . . . . . . . . 7 67 Appendix B. Analysis . . . . . . . . . . . . . . . . . . . . . . 9 68 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 70 1. Introduction 72 Many application protocols use parameters with textual names to 73 identify data (media types, header fields in Internet mail messages 74 and HTTP requests, vCard parameters and properties, etc.). 75 Historically, designers and implementers of application protocols 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 benefits have 84 been outweighed by the costs associated with the leakage of non- 85 standard parameters into the standards space. Therefore this 86 document deprecates the "X-" convention for named parameters in 87 application protocols and makes specific recommendations about how to 88 proceed in a world without the distinction between standard and non- 89 standard parameters. Note that this document covers only parameters 90 with textual names, not parameters that are expressed as numbers. In 91 addition, this document makes no recommendation as to whether 92 existing "X-" parameters ought to remain in use or be migrated to a 93 format without the "X-". 95 See Appendix A for background information about the history of the 96 "X-" convention, and Appendix B for the reasoning that led to the 97 recommendations in this document. 99 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 100 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 101 "OPTIONAL" in this document are to be interpreted as described in 102 [RFC2119]. 104 2. Recommendations for Implementers of Application Protocols 106 Implementers of application protocols MUST NOT treat the general 107 categories of "standard" and "non-standard" parameters in 108 programatically different ways within their applications. 110 3. Recommendations for Creators of New Parameters 112 Creators of new parameters to be used in the context of application 113 protocols: 115 1. SHOULD assume that all parameters they create might become 116 standardized, public, commonly deployed, or used across multiple 117 implementations. 119 2. SHOULD employ meaningful names that they have reason to believe 120 are currently unused (without the "X-" prefix). 122 Note: If the relevant parameter name space has conventions about 123 associating parameter names with those who create them, a parameter 124 name could incorporate the organization's name or primary domain name 125 (see Appendix B for examples). 127 4. Recommendations for Protocol Designers 129 Designers of new application protocols that allow extensions using 130 parameters: 132 1. SHOULD establish registries with potentially unlimited value- 133 spaces, if appropriate including both permanent and provisional 134 registries. 136 2. SHOULD define simple, clear registration procedures. 138 3. SHOULD mandate registration of all non-private parameters, 139 independent of the form of the parameter names. 141 4. SHOULD identify a convention to allow local or implementation- 142 specific extensions, and reserve delimeters for such uses as 143 needed. 145 5. SHOULD NOT prohibit parameters with the "X-" prefix from being 146 registered with the IANA. 148 6. MUST NOT assume that a parameter with an "X-" prefix is non- 149 standard. 151 7. MUST NOT assume that a parameter without an "X-" prefix is 152 standard. 154 5. Security Considerations 156 Interoperability and migration issues with security-critical 157 parameters can result in unnecessary vulnerabilities (see Appendix B 158 for further discussion). 160 6. IANA Considerations 162 This document does not modify registration procedures currently in 163 force for various application protocols. However, such procedures 164 might be updated in the future to incorporate the best practices 165 defined in this document. 167 7. Acknowledgements 169 Thanks to Claudio Allocchio, Adam Barth, Nathaniel Borenstein, Eric 170 Burger, Stuart Cheshire, Al Constanzo, Dave Cridland, Martin Duerst, 171 Frank Ellermann, J.D. Falk, Ned Freed, Tony Finch, Randall Gellens, 172 Tony Hansen, Ted Hardie, Joe Hildebrand, Alfred Hoenes, Paul Hoffman, 173 Eric Johnson, John Klensin, Graham Klyne, Murray Kucherawy, Eliot 174 Lear, John Levine, Bill McQuillan, Alexey Melnikov, Subramanian 175 Moonesamy, Keith Moore, Ben Niven-Jenkins, Zoltan Ordogh, Tim Petch, 176 Dirk Pranke, Randy Presuhn, Julian Reschke, Doug Royer, Andrew 177 Sullivan, Martin Thomson, Matthew Wild, Nicolas Williams, Tim 178 Williams, Mykyta Yevstifeyev, and Kurt Zeilenga for their feedback. 180 8. References 182 8.1. Normative References 184 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 185 Requirement Levels", BCP 14, RFC 2119, March 1997. 187 8.2. Informative References 189 [BCP9] Bradner, S., "The Internet Standards Process -- Revision 190 3", BCP 9, RFC 2026, October 1996. 192 [BCP26] Narten, T. and H. Alvestrand, "Guidelines for Writing an 193 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 194 May 2008. 196 [BCP82] Narten, T., "Assigning Experimental and Testing Numbers 197 Considered Useful", BCP 82, RFC 3692, January 2004. 199 [RFC691] Harvey, B., "One more try on the FTP", RFC 691, June 1975. 201 [RFC737] Harrenstien, K., "FTP extension: XSEN", RFC 737, 202 October 1977. 204 [RFC743] Harrenstien, K., "FTP extension: XRSQ/XRCP", RFC 743, 205 December 1977. 207 [RFC775] Mankins, D., Franklin, D., and A. Owen, "Directory 208 oriented FTP commands", RFC 775, December 1980. 210 [RFC822] Crocker, D., "Standard for the format of ARPA Internet 211 text messages", STD 11, RFC 822, August 1982. 213 [RFC1123] Braden, R., "Requirements for Internet Hosts - Application 214 and Support", STD 3, RFC 1123, October 1989. 216 [RFC1154] Robinson, D. and R. Ullmann, "Encoding header field for 217 internet messages", RFC 1154, April 1990. 219 [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 220 Extensions (MIME) Part One: Format of Internet Message 221 Bodies", RFC 2045, November 1996. 223 [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 224 Extensions (MIME) Part Two: Media Types", RFC 2046, 225 November 1996. 227 [RFC2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions) 228 Part Three: Message Header Extensions for Non-ASCII Text", 229 RFC 2047, November 1996. 231 [RFC2068] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., and T. 232 Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", 233 RFC 2068, January 1997. 235 [RFC2426] Dawson, F. and T. Howes, "vCard MIME Directory Profile", 236 RFC 2426, September 1998. 238 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 239 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 240 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 242 [RFC2822] Resnick, P., "Internet Message Format", RFC 2822, 243 April 2001. 245 [RFC2939] Droms, R., "Procedures and IANA Guidelines for Definition 246 of New DHCP Options and Message Types", BCP 43, RFC 2939, 247 September 2000. 249 [RFC3406] Daigle, L., van Gulik, D., Iannella, R., and P. Faltstrom, 250 "Uniform Resource Names (URN) Namespace Definition 251 Mechanisms", BCP 66, RFC 3406, October 2002. 253 [RFC3427] Mankin, A., Bradner, S., Mahy, R., Willis, D., Ott, J., 254 and B. Rosen, "Change Process for the Session Initiation 255 Protocol (SIP)", RFC 3427, December 2002. 257 [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration 258 Procedures for Message Header Fields", BCP 90, RFC 3864, 259 September 2004. 261 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 262 Resource Identifier (URI): Generic Syntax", STD 66, 263 RFC 3986, January 2005. 265 [RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally 266 Unique IDentifier (UUID) URN Namespace", RFC 4122, 267 July 2005. 269 [RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and 270 Registration Procedures", BCP 13, RFC 4288, December 2005. 272 [RFC4395] Hansen, T., Hardie, T., and L. Masinter, "Guidelines and 273 Registration Procedures for New URI Schemes", BCP 35, 274 RFC 4395, February 2006. 276 [RFC4512] Zeilenga, K., "Lightweight Directory Access Protocol 277 (LDAP): Directory Information Models", RFC 4512, 278 June 2006. 280 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 281 Description Protocol", RFC 4566, July 2006. 283 [RFC5064] Duerst, M., "The Archived-At Message Header Field", 284 RFC 5064, December 2007. 286 [RFC5451] Kucherawy, M., "Message Header Field for Indicating 287 Message Authentication Status", RFC 5451, April 2009. 289 [RFC5646] Phillips, A. and M. Davis, "Tags for Identifying 290 Languages", BCP 47, RFC 5646, September 2009. 292 [RFC5727] Peterson, J., Jennings, C., and R. Sparks, "Change Process 293 for the Session Initiation Protocol (SIP) and the Real- 294 time Applications and Infrastructure Area", BCP 67, 295 RFC 5727, March 2010. 297 Appendix A. Background 299 The beginnings of the "X-" convention can be found in a suggestion 300 made by Brian Harvey in 1975 with regard to FTP parameters [RFC691]: 302 Thus, FTP servers which care about the distinction between Telnet 303 print and non-print could implement SRVR N and SRVR T. Ideally the 304 SRVR parameters should be registered with Jon Postel to avoid 305 conflicts, although it is not a disaster if two sites use the same 306 parameter for different things. I suggest that parameters be 307 allowed to be more than one letter, and that an initial letter X 308 be used for really local idiosyncracies. 310 This "X" prefix was subsequently used in [RFC737], [RFC743], and 311 [RFC775]. This usage was noted in [RFC1123]: 313 FTP allows "experimental" commands, whose names begin with "X". 314 If these commands are subsequently adopted as standards, there may 315 still be existing implementations using the "X" form.... All FTP 316 implementations SHOULD recognize both forms of these commands, by 317 simply equating them with extra entries in the command lookup 318 table. 320 The "X-" convention has been used for email header fields since at 321 least the publication of [RFC822] in 1982, which distinguished 322 between "Extension-fields" and "user-defined-fields" as follows: 324 The prefatory string "X-" will never be used in the names of 325 Extension-fields. This provides user-defined fields with a 326 protected set of names. 328 That rule was restated by [RFC1154] as follows: 330 Keywords beginning with "X-" are permanently reserved to 331 implementation-specific use. No standard registered encoding 332 keyword will ever begin with "X-". 334 This convention continued with various specifications for media types 335 ([RFC2045], [RFC2046], [RFC2047]), HTTP headers ([RFC2068], 336 [RFC2616]), vCard parameters and properties ([RFC2426]), Uniform 337 Resource Names ([RFC3406]), LDAP field names ([RFC4512]), and other 338 application technologies. 340 However, use of the "X-" prefix in email headers was effectively 341 deprecated between the publication of [RFC822] in 1982 and the 342 publication of [RFC2822] in 2001 by removing the distinction between 343 the "extension-field" construct and the "user-defined-field" 344 construct (a similar change happened with regard to Session 345 Initiation Protocol "P-" headers when [RFC3427] was obsoleted by 346 [RFC5727]). 348 Despite the fact that parameters containing the "X-" string have been 349 effectively deprecated in email headers, they continue to be used in 350 a wide variety of application protocols. The two primary situations 351 motivating such use are: 353 1. Experiments that are intended to possibly be standardized in the 354 future, if they are successful. 356 2. Extensions that are intended to never be standardized because 357 they are intended only for implementation-specific use or for 358 local use on private networks. 360 Use of this naming convention is not mandated by the Internet 361 Standards Process [BCP9] or IANA registration rules [BCP26]. Rather 362 it is an individual choice by each specification that references the 363 convention or each administrative process that chooses to use it. In 364 particular, some standards-track RFCs have interpreted the convention 365 in a normative way (e.g., [RFC822] and [RFC5451]). 367 Appendix B. Analysis 369 The primary problem with the "X-" convention is that non-standard 370 parameters have a tendency to leak into the protected space of 371 standard parameters (whether de jure or de facto), thus introducing 372 the need for migration from the "X-" name to the standard name. 373 Migration, in turn, introduces interoperability issues (and sometimes 374 security issues) because older implementations will support only the 375 "X-" name and newer implementations might support only the standard 376 name. To preserve interoperability, newer implementations simply 377 support the "X-" name forever, which means that the non-standard name 378 has become a de facto standard (thus obviating the need for 379 segregation of the name space into "standard" and "non-standard" 380 areas in the first place). 382 We have already seen this phenomenon at work with regard to FTP in 383 the quote from [RFC1123] in the previous section. The HTTP community 384 had the same experience with the "x-gzip" and "x-compressed" media 385 types, as noted in [RFC2068]: 387 For compatibility with previous implementations of HTTP, 388 applications should consider "x-gzip" and "x-compress" to be 389 equivalent to "gzip" and "compress" respectively. 391 A similar example can be found in [RFC5064], which defined the 392 "Archived-At" message header field but also found it necessary to 393 define and register the "X-Archived-At" field: 395 For backwards compatibility, this document also describes the 396 X-Archived-At header field, a precursor of the Archived-At header 397 field. The X-Archived-At header field MAY also be parsed, but 398 SHOULD NOT be generated. 400 One of the original reasons for segregation of name spaces into 401 standard and non-standard areas was the perceived difficulty of 402 registering names. However, the solution to that problem has been 403 simpler registration rules, such as those provided by [RFC3864] and 404 [RFC4288]. As explained in [RFC4288]: 406 [W]ith the simplified registration procedures described above for 407 vendor and personal trees, it should rarely, if ever, be necessary 408 to use unregistered experimental types. Therefore, use of both 409 "x-" and "x." forms is discouraged. 411 For some name spaces, another helpful practice has been the 412 establishment of separate registries for permanent names and 413 provisional names, as in [RFC4395]. 415 Furthermore, often standardization of a non-standard parameter or 416 protocol element leads to subtly different behavior (e.g., the 417 standard version might have different security properties as a result 418 of security review provided during the standardization process). If 419 implementers treat the old, non-standard parameter and the new, 420 standard parameter as equivalent, interoperability and security 421 problems can ensue. 423 For similar considerations with regard to the "P-" convention in the 424 Session Initiation Protocol, see [RFC5727]. 426 In some situations, segregating the parameter name space used in a 427 given application protocol can be justified: 429 1. When it is extremely unlikely that some parameters will ever be 430 standardized. However, in this case implementation-specific and 431 private-use parameters could at least incorporate the 432 organization's name (e.g., "ExampleInc-foo" or, consistent with 433 [RFC4288], "VND.ExampleInc.foo") or primary domain name (e.g., 434 "com.example.foo" or a Uniform Resource Identifier [RFC3986] such 435 as "http://example.com/foo"). In rare cases, truly experimental 436 parameters could be given meaningless names such as nonsense 437 words, the output of a hash function, or UUIDs [RFC4122]. 439 2. When parameter names might have significant meaning. However, 440 this case too is rare, since implementers can almost always find 441 a synonym for an existing term (e.g., "urgency" instead of 442 "priority") or simply invent a more creative name (e.g., "get-it- 443 there-fast"). 445 3. When parameter names need to be very short (e.g., as in [RFC5646] 446 for language tags). However, in this case it can be more 447 efficient to assign numbers instead of human-readable names 448 (e.g., as in [RFC2939] for DCHP options) and to leave a certain 449 numeric range for implementation-specific extensions or private 450 use (e.g., as with the codec numbers used with the Session 451 Description Protocol [RFC4566]). 453 There are three primary objections to deprecating the "X-" convention 454 as a best practice for application protocols: 456 1. Implementers are easily confused and can't be expected to know 457 that a parameter is non-standard unless it contains the "X-" 458 prefix. However, implementers already are quite flexible about 459 using both prefixed and non-prefixed names based on what works in 460 the field, so the distinction between de facto names (e.g., 461 "X-foo") and de jure names (e.g., "foo") is without force. 463 2. Collisions are undesirable and it would be bad for both a 464 standard parameter "foo" and a non-standard parameter "foo" to 465 exist simultaneously. However, names are almost always cheap, so 466 an experimental, implementation-specific, or private-use name of 467 "foo" does not prevent a standards development organization from 468 issuing a similarly creative name such as "bar". 470 3. [BCP82] is entitled "Assigning Experimental and Testing Numbers 471 Considered Useful" and therefore implies that the "X-" prefix is 472 also useful for experimental parameters. However, BCP 82 473 addresses the need for protocol numbers when the pool of such 474 numbers is strictly limited (e.g., DHCP options) or when a number 475 is absolutely required even for purely experimental purposes 476 (e.g., the Protocol field of the IP header). In almost all 477 application protocols that make use of protocol parameters 478 (including email headers, media types, HTTP headers, vCard 479 parameters and properties, URNs, and LDAP field names), the name 480 space is not limited or constrained in any way, so there is no 481 need to assign a block of names for private use or experimental 482 purposes (see also [BCP26]). 484 Therefore it appears that segregating the parameter space into a 485 standard area and a non-standard area has few if any benefits, and 486 has at least one significant cost in terms of interoperability. 488 Authors' Addresses 490 Peter Saint-Andre 491 Cisco Systems, Inc. 492 1899 Wynkoop Street, Suite 600 493 Denver, CO 80202 494 USA 496 Phone: +1-303-308-3282 497 Email: psaintan@cisco.com 499 D. Crocker 500 Brandenburg InternetWorking 501 675 Spruce Dr. 502 Sunnyvale 503 USA 505 Phone: +1.408.246.8253 506 Email: dcrocker@bbiw.net 507 URI: http://bbiw.net 509 Mark Nottingham 510 Rackspace 512 Email: mnot@mnot.net 513 URI: http://www.mnot.net