idnits 2.17.1 draft-ietf-appsawg-xdash-05.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 (April 9, 2012) is 4372 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: October 11, 2012 Brandenburg InternetWorking 6 M. Nottingham 7 Rackspace 8 April 9, 2012 10 Deprecating the X- Prefix and Similar Constructs in Application 11 Protocols 12 draft-ietf-appsawg-xdash-05 14 Abstract 16 Historically, designers and implementers of application protocols 17 have often distinguished between standardized and unstandardized 18 parameters by prefixing the names of unstandardized parameters with 19 the string "X-" or similar constructs. In practice, that convention 20 causes more problems than it solves. Therefore, this document 21 deprecates the convention for newly-defined parameters with textual 22 (as opposed to numerical) names in application protocols. 24 Status of this Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on October 11, 2012. 41 Copyright Notice 43 Copyright (c) 2012 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2. Recommendations for Implementers of Application Protocols . . 4 60 3. Recommendations for Creators of New Parameters . . . . . . . . 4 61 4. Recommendations for Protocol Designers . . . . . . . . . . . . 5 62 5. Security Considerations . . . . . . . . . . . . . . . . . . . 5 63 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 64 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6 65 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 66 8.1. Normative References . . . . . . . . . . . . . . . . . . . 6 67 8.2. Informative References . . . . . . . . . . . . . . . . . . 6 68 Appendix A. Background . . . . . . . . . . . . . . . . . . . . . 8 69 Appendix B. Analysis . . . . . . . . . . . . . . . . . . . . . . 10 70 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 72 1. Introduction 74 Many application protocols use parameters with textual (as opposed to 75 numerical) names to identify data (media types, header fields in 76 Internet mail messages and HTTP requests, vCard parameters and 77 properties, etc.). Historically, designers and implementers of 78 application protocols have often distinguished between standardized 79 and unstandardized parameters by prefixing the names of 80 unstandardized parameters with the string "X-" or similar constructs 81 (e.g., "x."), where the "X" is commonly understood to stand for 82 "eXperimental" or "eXtension". 84 Under this convention, the name of a parameter not only identified 85 the data, but also embedded the status of the parameter into the name 86 itself: a parameter defined in a specification produced by a 87 recognized standards development organization (or registered 88 according to processes defined in such a specification) did not start 89 with "X-" or similar constructs, whereas a parameter defined outside 90 such a specification or process started with "X-" or similar 91 constructs. 93 As explained more fully under Appendix A, this convention was 94 encouraged for many years in application protocols such as file 95 transfer, email, and the World Wide Web. In particular, it was 96 codified for email by [RFC822] (via the distinction between 97 "Extension-fields" and "user-defined-fields"), but then removed by 98 [RFC2822] based on implementation and deployment experience. A 99 similar progression occurred for SIP technologies with regard to the 100 "P-" header, as explained in [RFC5727]. The reasoning behind those 101 changes is explored under Appendix B. 103 In short, although in theory the "X-" convention was a good way to 104 avoid collisions (and attendant interoperability problems) between 105 standardized parameters and unstandardized parameters, in practice 106 the benefits have been outweighed by the costs associated with the 107 leakage of unstandardized parameters into the standards space. 109 This document generalizes from the experience of the email and SIP 110 communities by doing the following: 112 1. Deprecates the "X-" convention for newly-defined parameters in 113 application protocols, even where that convention was only 114 implicit instead of being codified in a protocol specification 115 (as was done for email in [RFC822]). 117 2. Makes specific recommendations about how to proceed in a world 118 without the distinction between standardized and unstandardized 119 parameters (although only for parameters with textual names, not 120 parameters that are expressed as numbers, which are out of 121 scope). 123 3. Does not recommend against the practice of private, local, 124 preliminary, experimental, or implementation-specific parameters, 125 only against the use of "X-" and similar constructs in the names 126 of such parameters. 128 4. Makes no recommendation as to whether existing "X-" parameters 129 ought to remain in use or be migrated to a format without the 130 "X-"; this is a matter for the creators or maintainers of those 131 parameters. 133 5. Does not override existing specifications that legislate the use 134 of "X-" for particular application protocols (e.g., the "x-name" 135 token in [RFC5545]); this is a matter for the designers of those 136 protocols. 138 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 139 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 140 "OPTIONAL" in this document are to be interpreted as described in 141 [RFC2119]. 143 2. Recommendations for Implementers of Application Protocols 145 Implementations of application protocols MUST NOT make any 146 assumptions about the status of a parameter, nor take automatic 147 action regarding a parameter, based solely on the presence or absence 148 of "X-" or a similar construct in the parameter's name. 150 3. Recommendations for Creators of New Parameters 152 Creators of new parameters to be used in the context of application 153 protocols: 155 1. SHOULD assume that all parameters they create might become 156 standardized, public, commonly deployed, or used across multiple 157 implementations. 159 2. SHOULD employ meaningful parameter names that they have reason to 160 believe are currently unused. 162 3. SHOULD NOT prefix their parameter names with "X-" or similar 163 constructs. 165 Note: If the relevant parameter name space has conventions about 166 associating parameter names with those who create them, a parameter 167 name could incorporate the organization's name or primary domain name 168 (see Appendix B for examples). 170 4. Recommendations for Protocol Designers 172 Designers of new application protocols that allow extensions using 173 parameters: 175 1. SHOULD establish registries with potentially unlimited value- 176 spaces, if appropriate defining both permanent and provisional 177 registries. 179 2. SHOULD define simple, clear registration procedures. 181 3. SHOULD mandate registration of all non-private parameters, 182 independent of the form of the parameter names. 184 4. SHOULD NOT prohibit parameters with the "X-" prefix or similar 185 constructs from being registered. 187 5. MUST NOT assume that a parameter with an "X-" prefix or similar 188 constructs is unstandardized. 190 6. MUST NOT assume that a parameter without an "X-" prefix or 191 similar constructs is standard. 193 5. Security Considerations 195 Interoperability and migration issues with security-critical 196 parameters can result in unnecessary vulnerabilities (see Appendix B 197 for further discussion). 199 As a corollary to the recommendation provided under Section 2, 200 implementations MUST NOT assume that standardized parameters are 201 "secure" whereas unstandardized parameters are "insecure", based 202 solely on the names of such parameters. 204 6. IANA Considerations 206 This document does not modify registration procedures currently in 207 force for various application protocols. However, such procedures 208 might be updated in the future to incorporate the best practices 209 defined in this document. 211 7. Acknowledgements 213 Thanks to Claudio Allocchio, Adam Barth, Nathaniel Borenstein, Eric 214 Burger, Stuart Cheshire, Al Constanzo, Dave Cridland, Ralph Droms, 215 Martin Duerst, Frank Ellermann, J.D. Falk, Ned Freed, Tony Finch, 216 Randall Gellens, Tony Hansen, Ted Hardie, Joe Hildebrand, Alfred 217 Hoenes, Paul Hoffman, Eric Johnson, Scott Kelly, Scott Kitterman, 218 John Klensin, Graham Klyne, Murray Kucherawy, Eliot Lear, John 219 Levine, Bill McQuillan, Alexey Melnikov, Subramanian Moonesamy, Keith 220 Moore, Ben Niven-Jenkins, Zoltan Ordogh, Tim Petch, Dirk Pranke, 221 Randy Presuhn, Julian Reschke, Dan Romascanu, Doug Royer, Andrew 222 Sullivan, Henry Thompson, Martin Thomson, Matthew Wild, Nicolas 223 Williams, Tim Williams, Mykyta Yevstifeyev, and Kurt Zeilenga for 224 their feedback. 226 8. References 228 8.1. Normative References 230 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 231 Requirement Levels", BCP 14, RFC 2119, March 1997. 233 8.2. Informative References 235 [BCP9] Bradner, S., "The Internet Standards Process -- Revision 236 3", BCP 9, RFC 2026, October 1996. 238 [BCP26] Narten, T. and H. Alvestrand, "Guidelines for Writing an 239 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 240 May 2008. 242 [BCP82] Narten, T., "Assigning Experimental and Testing Numbers 243 Considered Useful", BCP 82, RFC 3692, January 2004. 245 [RFC691] Harvey, B., "One more try on the FTP", RFC 691, June 1975. 247 [RFC737] Harrenstien, K., "FTP extension: XSEN", RFC 737, 248 October 1977. 250 [RFC743] Harrenstien, K., "FTP extension: XRSQ/XRCP", RFC 743, 251 December 1977. 253 [RFC775] Mankins, D., Franklin, D., and A. Owen, "Directory 254 oriented FTP commands", RFC 775, December 1980. 256 [RFC822] Crocker, D., "Standard for the format of ARPA Internet 257 text messages", STD 11, RFC 822, August 1982. 259 [RFC1123] Braden, R., "Requirements for Internet Hosts - Application 260 and Support", STD 3, RFC 1123, October 1989. 262 [RFC1154] Robinson, D. and R. Ullmann, "Encoding header field for 263 internet messages", RFC 1154, April 1990. 265 [RFC2045] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 266 Extensions (MIME) Part One: Format of Internet Message 267 Bodies", RFC 2045, November 1996. 269 [RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail 270 Extensions (MIME) Part Two: Media Types", RFC 2046, 271 November 1996. 273 [RFC2047] Moore, K., "MIME (Multipurpose Internet Mail Extensions) 274 Part Three: Message Header Extensions for Non-ASCII Text", 275 RFC 2047, November 1996. 277 [RFC2068] Fielding, R., Gettys, J., Mogul, J., Nielsen, H., and T. 278 Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", 279 RFC 2068, January 1997. 281 [RFC2426] Dawson, F. and T. Howes, "vCard MIME Directory Profile", 282 RFC 2426, September 1998. 284 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 285 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 286 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 288 [RFC2822] Resnick, P., "Internet Message Format", RFC 2822, 289 April 2001. 291 [RFC2939] Droms, R., "Procedures and IANA Guidelines for Definition 292 of New DHCP Options and Message Types", BCP 43, RFC 2939, 293 September 2000. 295 [RFC3406] Daigle, L., van Gulik, D., Iannella, R., and P. Faltstrom, 296 "Uniform Resource Names (URN) Namespace Definition 297 Mechanisms", BCP 66, RFC 3406, October 2002. 299 [RFC3427] Mankin, A., Bradner, S., Mahy, R., Willis, D., Ott, J., 300 and B. Rosen, "Change Process for the Session Initiation 301 Protocol (SIP)", RFC 3427, December 2002. 303 [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration 304 Procedures for Message Header Fields", BCP 90, RFC 3864, 305 September 2004. 307 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 308 Resource Identifier (URI): Generic Syntax", STD 66, 309 RFC 3986, January 2005. 311 [RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally 312 Unique IDentifier (UUID) URN Namespace", RFC 4122, 313 July 2005. 315 [RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and 316 Registration Procedures", BCP 13, RFC 4288, December 2005. 318 [RFC4395] Hansen, T., Hardie, T., and L. Masinter, "Guidelines and 319 Registration Procedures for New URI Schemes", BCP 35, 320 RFC 4395, February 2006. 322 [RFC4512] Zeilenga, K., "Lightweight Directory Access Protocol 323 (LDAP): Directory Information Models", RFC 4512, 324 June 2006. 326 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 327 Description Protocol", RFC 4566, July 2006. 329 [RFC5064] Duerst, M., "The Archived-At Message Header Field", 330 RFC 5064, December 2007. 332 [RFC5451] Kucherawy, M., "Message Header Field for Indicating 333 Message Authentication Status", RFC 5451, April 2009. 335 [RFC5545] Desruisseaux, B., "Internet Calendaring and Scheduling 336 Core Object Specification (iCalendar)", RFC 5545, 337 September 2009. 339 [RFC5646] Phillips, A. and M. Davis, "Tags for Identifying 340 Languages", BCP 47, RFC 5646, September 2009. 342 [RFC5727] Peterson, J., Jennings, C., and R. Sparks, "Change Process 343 for the Session Initiation Protocol (SIP) and the Real- 344 time Applications and Infrastructure Area", BCP 67, 345 RFC 5727, March 2010. 347 Appendix A. Background 349 The beginnings of the "X-" convention can be found in a suggestion 350 made by Brian Harvey in 1975 with regard to FTP parameters [RFC691]: 352 Thus, FTP servers which care about the distinction between Telnet 353 print and non-print could implement SRVR N and SRVR T. Ideally the 354 SRVR parameters should be registered with Jon Postel to avoid 355 conflicts, although it is not a disaster if two sites use the same 356 parameter for different things. I suggest that parameters be 357 allowed to be more than one letter, and that an initial letter X 358 be used for really local idiosyncracies. 360 This "X" prefix was subsequently used in [RFC737], [RFC743], and 361 [RFC775]. This usage was noted in [RFC1123]: 363 FTP allows "experimental" commands, whose names begin with "X". 364 If these commands are subsequently adopted as standards, there may 365 still be existing implementations using the "X" form.... All FTP 366 implementations SHOULD recognize both forms of these commands, by 367 simply equating them with extra entries in the command lookup 368 table. 370 The "X-" convention has been used for email header fields since at 371 least the publication of [RFC822] in 1982, which distinguished 372 between "Extension-fields" and "user-defined-fields" as follows: 374 The prefatory string "X-" will never be used in the names of 375 Extension-fields. This provides user-defined fields with a 376 protected set of names. 378 That rule was restated by [RFC1154] as follows: 380 Keywords beginning with "X-" are permanently reserved to 381 implementation-specific use. No standard registered encoding 382 keyword will ever begin with "X-". 384 This convention continued with various specifications for media types 385 ([RFC2045], [RFC2046], [RFC2047]), HTTP headers ([RFC2068], 386 [RFC2616]), vCard parameters and properties ([RFC2426]), Uniform 387 Resource Names ([RFC3406]), LDAP field names ([RFC4512]), and other 388 application technologies. 390 However, use of the "X-" prefix in email headers was effectively 391 deprecated between the publication of [RFC822] in 1982 and the 392 publication of [RFC2822] in 2001 by removing the distinction between 393 the "extension-field" construct and the "user-defined-field" 394 construct (a similar change happened with regard to Session 395 Initiation Protocol "P-" headers when [RFC3427] was obsoleted by 396 [RFC5727]). 398 Despite the fact that parameters containing the "X-" string have been 399 effectively deprecated in email headers, they continue to be used in 400 a wide variety of application protocols. The two primary situations 401 motivating such use are: 403 1. Experiments that are intended to possibly be standardized in the 404 future, if they are successful. 406 2. Extensions that are intended to never be standardized because 407 they are intended only for implementation-specific use or for 408 local use on private networks. 410 Use of this naming convention is not mandated by the Internet 411 Standards Process [BCP9] or IANA registration rules [BCP26]. Rather 412 it is an individual choice by each specification that references the 413 convention or each administrative process that chooses to use it. In 414 particular, some standards-track RFCs have interpreted the convention 415 in a normative way (e.g., [RFC822] and [RFC5451]). 417 Appendix B. Analysis 419 The primary problem with the "X-" convention is that unstandardized 420 parameters have a tendency to leak into the protected space of 421 standardized parameters, thus introducing the need for migration from 422 the "X-" name to a standardized name. Migration, in turn, introduces 423 interoperability issues (and sometimes security issues) because older 424 implementations will support only the "X-" name and newer 425 implementations might support only the standardized name. To 426 preserve interoperability, newer implementations simply support the 427 "X-" name forever, which means that the unstandardized name has 428 become a de facto standard (thus obviating the need for segregation 429 of the name space into standardized and unstandardized areas in the 430 first place). 432 We have already seen this phenomenon at work with regard to FTP in 433 the quote from [RFC1123] in the previous section. The HTTP community 434 had the same experience with the "x-gzip" and "x-compress" media 435 types, as noted in [RFC2068]: 437 For compatibility with previous implementations of HTTP, 438 applications should consider "x-gzip" and "x-compress" to be 439 equivalent to "gzip" and "compress" respectively. 441 A similar example can be found in [RFC5064], which defined the 442 "Archived-At" message header field but also found it necessary to 443 define and register the "X-Archived-At" field: 445 For backwards compatibility, this document also describes the 446 X-Archived-At header field, a precursor of the Archived-At header 447 field. The X-Archived-At header field MAY also be parsed, but 448 SHOULD NOT be generated. 450 One of the original reasons for segregation of name spaces into 451 standardized and unstandardized areas was the perceived difficulty of 452 registering names. However, the solution to that problem has been 453 simpler registration rules, such as those provided by [RFC3864] and 454 [RFC4288]. As explained in [RFC4288]: 456 [W]ith the simplified registration procedures described above for 457 vendor and personal trees, it should rarely, if ever, be necessary 458 to use unregistered experimental types. Therefore, use of both 459 "x-" and "x." forms is discouraged. 461 For some name spaces, another helpful practice has been the 462 establishment of separate registries for permanent names and 463 provisional names, as in [RFC4395]. 465 Furthermore, often standardization of a unstandardized parameter 466 leads to subtly different behavior (e.g., the standardized version 467 might have different security properties as a result of security 468 review provided during the standardization process). If implementers 469 treat the old, unstandardized parameter and the new, standardized 470 parameter as equivalent, interoperability and security problems can 471 ensue. Analysis of unstandardized parameters to detect and correct 472 flaws is in general a good thing and is not intended to be 473 discouraged by the lack of distinction in element names. Whenever an 474 originally unstandardized parameter or protocol element is 475 standardized and the new form has differences which affect 476 interoperability or security properties, implementations MUST NOT 477 treat the old form as identical to the new form. 479 For similar considerations with regard to the "P-" convention in the 480 Session Initiation Protocol, see [RFC5727]. 482 In some situations, segregating the parameter name space used in a 483 given application protocol can be justified: 485 1. When it is extremely unlikely that some parameters will ever be 486 standardized. In this case implementation-specific and private- 487 use parameters could at least incorporate the organization's name 488 (e.g., "ExampleInc-foo" or, consistent with [RFC4288], 489 "VND.ExampleInc.foo") or primary domain name (e.g., 490 "com.example.foo" or a Uniform Resource Identifier [RFC3986] such 491 as "http://example.com/foo"). In rare cases, truly experimental 492 parameters could be given meaningless names such as nonsense 493 words, the output of a hash function, or UUIDs [RFC4122]. 495 2. When parameter names might have significant meaning. This case 496 too is rare, since implementers can almost always find a synonym 497 for an existing term (e.g., "urgency" instead of "priority") or 498 simply invent a more creative name (e.g., "get-it-there-fast"). 499 The existence of multiple similarly-named paramaters can be 500 confusing, but this is true regardless if there is an attempt to 501 segregate standardized and unstandardized (e.g., "X-Priority" can 502 be confused with "Urgency"). 504 3. When parameter names need to be very short (e.g., as in [RFC5646] 505 for language tags). In this case it can be more efficient to 506 assign numbers instead of human-readable names (e.g., as in 507 [RFC2939] for DCHP options) and to leave a certain numeric range 508 for implementation-specific extensions or private use (e.g., as 509 with the codec numbers used with the Session Description Protocol 510 [RFC4566]). 512 There are three primary objections to deprecating the "X-" convention 513 as a best practice for application protocols: 515 1. Implementers might mistake one parameter for another parameter 516 that has a similar name; a rigid distinction such as an "X-" 517 prefix can make this clear. However, in practice implementers 518 are forced to blur the distinction (e.g., by treating "X-foo" as 519 a de facto standard) and so it inevitably becomes meaningless. 521 2. Collisions are undesirable and it would be bad for both a 522 standardized parameter "foo" and a unstandardized parameter "foo" 523 to exist simultaneously. However, names are almost always cheap, 524 so an experimental, implementation-specific, or private-use name 525 of "foo" does not prevent a standards development organization 526 from issuing a similarly creative name such as "bar". 528 3. [BCP82] is entitled "Assigning Experimental and Testing Numbers 529 Considered Useful" and therefore implies that the "X-" prefix is 530 also useful for experimental parameters. However, BCP 82 531 addresses the need for protocol numbers when the pool of such 532 numbers is strictly limited (e.g., DHCP options) or when a number 533 is absolutely required even for purely experimental purposes 534 (e.g., the Protocol field of the IP header). In almost all 535 application protocols that make use of protocol parameters 536 (including email headers, media types, HTTP headers, vCard 537 parameters and properties, URNs, and LDAP field names), the name 538 space is not limited or constrained in any way, so there is no 539 need to assign a block of names for private use or experimental 540 purposes (see also [BCP26]). 542 Therefore it appears that segregating the parameter space into a 543 standardized area and a unstandardized area has few if any benefits, 544 and has at least one significant cost in terms of interoperability. 546 Authors' Addresses 548 Peter Saint-Andre 549 Cisco Systems, Inc. 550 1899 Wynkoop Street, Suite 600 551 Denver, CO 80202 552 USA 554 Phone: +1-303-308-3282 555 Email: psaintan@cisco.com 557 D. Crocker 558 Brandenburg InternetWorking 559 675 Spruce Dr. 560 Sunnyvale 561 USA 563 Phone: +1.408.246.8253 564 Email: dcrocker@bbiw.net 565 URI: http://bbiw.net 567 Mark Nottingham 568 Rackspace 570 Email: mnot@mnot.net 571 URI: http://www.mnot.net