Deprecating Use of the "X-" Prefix in Application Protocols
Cisco Systems, Inc.
1899 Wynkoop Street, Suite 600
Denver
CO
80202
USA
+1-303-308-3282
psaintan@cisco.com
Brandenburg InternetWorking
675 Spruce Dr.
Sunnyvale
USA
+1.408.246.8253
dcrocker@bbiw.net
http://bbiw.net
Rackspace
mnot@mnot.net
http://www.mnot.net
Applications
APPSAWG
Internet-Draft
Historically, designers and implementers of application protocols have often distinguished between "standard" and "non-standard" parameters by prefixing the latter with the string "X-" or similar constructions. In practice, this convention causes more problems than it solves. Therefore, this document deprecates the "X-" convention for textual parameters in application protocols.
Many application protocols use parameters with textual 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 "standard" and "non-standard" parameters by prefixing the latter with the string "X-" or similar constructions (e.g., "x."), where the "X" is commonly understood to stand for "eXperimental" or "eXtension".
Although in theory the "X-" convention was a good way to avoid collisions (and attendant interoperability problems) between standard parameters and non-standard parameters, in practice the benefits have been outweighed by the costs associated with the leakage of non-standard parameters into the standards space. Therefore this document deprecates the "X-" convention for named parameters in application protocols and makes specific recommendations about how to proceed in a world without the distinction between standard and non-standard parameters. Note that this document covers only parameters with textual names, not parameters that are expressed as numbers. In addition, this document makes no recommendation as to whether existing "X-" parameters ought to remain in use or be migrated to a format without the "X-".
See for background information about the history of the "X-" convention, and for the reasoning that led to the recommendations in this document.
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 .
Implementers of application protocols MUST NOT treat the general categories of "standard" and "non-standard" parameters in programatically different ways within their applications.
Creators of new parameters to be used in the context of application protocols:
SHOULD assume that all parameters they create might become standardized, public, commonly deployed, or used across multiple implementations.
SHOULD employ meaningful names that they have reason to believe are currently unused (without the "X-" prefix).
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 for examples).
Designers of new application protocols that allow extensions using parameters:
SHOULD establish registries with potentially unlimited value-spaces, if appropriate including both permanent and provisional registries.
SHOULD define simple, clear registration procedures.
SHOULD mandate registration of all non-private parameters, independent of the form of the parameter names.
SHOULD identify a convention to allow local or implementation-specific extensions, and reserve delimeters for such uses as needed.
SHOULD NOT prohibit parameters with the "X-" prefix from being registered with the IANA.
MUST NOT assume that a parameter with an "X-" prefix is non-standard.
MUST NOT assume that a parameter without an "X-" prefix is standard.
Interoperability and migration issues with security-critical parameters can result in unnecessary vulnerabilities (see for further discussion).
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, 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, 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, Doug Royer, Andrew Sullivan, Martin Thomson, Matthew Wild, Nicolas Williams, Tim Williams, Mykyta Yevstifeyev, and Kurt Zeilenga for their feedback.
Key words for use in RFCs to Indicate Requirement Levels
Harvard University
1350 Mass. Ave.
Cambridge
MA 02138
- +1 617 495 3864
sob@harvard.edu
General
keyword
In many standards track documents several words are used to signify
the requirements in the specification. These words are often
capitalized. This document defines these words as they should be
interpreted in IETF documents. Authors who follow these guidelines
should incorporate this phrase near the beginning of their document:
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in
RFC 2119.
Note that the force of these words is modified by the requirement
level of the document in which they are used.
The Internet Standards Process -- Revision 3
Harvard University
1350 Mass. Ave.
Cambridge
MA
02138
US
+1 617 495 3864
sob@harvard.edu
This memo documents the process used by the Internet community for the standardization of protocols and procedures. It defines the stages in the standardization process, the requirements for moving a document between stages and the types of documents used during this process. It also addresses the intellectual property rights and copyright issues associated with the standards process.
Guidelines for Writing an IANA Considerations Section in RFCs
Many protocols make use of identifiers consisting of constants and other well-known values. Even after a protocol has been defined and deployment has begun, new values may need to be assigned (e.g., for a new option type in DHCP, or a new encryption or authentication transform for IPsec). To ensure that such quantities have consistent values and interpretations across all implementations, their assignment must be administered by a central authority. For IETF protocols, that role is provided by the Internet Assigned Numbers Authority (IANA).</t><t> In order for IANA to manage a given namespace prudently, it needs guidelines describing the conditions under which new values can be assigned or when modifications to existing values can be made. If IANA is expected to play a role in the management of a namespace, IANA must be given clear and concise instructions describing that role. This document discusses issues that should be considered in formulating a policy for assigning values to a namespace and provides guidelines for authors on the specific text that must be included in documents that place demands on IANA.</t><t> This document obsoletes RFC 2434. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.
Assigning Experimental and Testing Numbers Considered Useful
When experimenting with or extending protocols, it is often necessary to use some sort of protocol number or constant in order to actually test or experiment with the new function, even when testing in a closed environment. For example, to test a new DHCP option, one needs an option number to identify the new function. This document recommends that when writing IANA Considerations sections, authors should consider assigning a small range of numbers for experimentation purposes that implementers can use when testing protocol extensions or other new features. This document reserves some ranges of numbers for experimentation purposes in specific protocols where the need to support experimentation has been identified.
One more try on the FTP
Stanford University (SU), Artifical Intelligence (AI)
This is a slight revision of RFC 686, mainly differing in the discussion of print files. Reading several RFCs that I (sigh) never heard of before writing 686 has convinced me that although I was right all along it was for the wrong reasons. The list of reply codes is also slightly different to reflect the four lists in RFCs 354, 454, 542, and 640 more completely. Let me also suggest that if there are no objections before June 1, everyone take it as official that HELP should return 200, that SRVR should be used as discussed below, and that "permanent" 4xx errors be changed to 5xx. And thanks to Jon Postel who just spent all evening helping me straighten this all out.
Aside from a cry of anguish by the site responsible for the security hassle described below, I've only had one comment on this, which was unfavorable but, alas, unspecific. Let me just say, in the hopes of avoiding more such, that I am not just trying to step on toes for the fun of it, and that I don't think the positive changes to FTP-1 proposed here are necessarily the best possible thing. What they are, I think, is easily doable. The great-FTP-in-the-sky isn't showing any signs of universal acceptability, and it shouldn't stand in the way of solving immediate problems.
Leaving Well Enough Alone
I recently decided it was time for an overhaul of our FTP user and server programs. This was my first venture into the world of network protocols, and I soon discovered that there was a lot we were doing wrong--and a few things that everyone seemed to be doing differently from each other. When I enquired about this, the response from some quarters was "Oh, you're running Version 1!"
FTP extension: XSEN
Stanford Research Institute (SRI) International, KL
This note describes an extension to the File Transfer Protocol which provides for "sending" a message to a logged-in user, as well as variants for mailing it normally whether the user is logged in or not.
FTP extension: XRSQ/XRCP
Stanford Research Institute (SRI), KL
Directory oriented FTP commands
dm@bbn-unix
dan@bbn-unix
ADOwen@bbnd
As a part of the Remote Site Maintenance (RSM) project for ARPA, BBN has installed and maintains the software of several DEC PDP-11s running the Unix operating system. Since Unix has a tree-like directory structure, in which directories are as easy to manipulate as ordinary files, we have found it convenient to expand the FTP servers on these machines to include commands which deal with the creation of directories. Since there are other hosts on the ARPA net which have tree-like directories, including Tops-20 and Multics, we have tried to make these commands as general as possible.
Standard for the format of ARPA Internet text messages
University of Delaware, Dept. of Electrical Engineering
Newark
DE
19711
US
DCrocker@UDel-Relay
Requirements for Internet Hosts - Application and Support
University of Southern California (USC), Information Sciences Institute
4676 Admiralty Way
Marina del Rey
CA
90292-6695
US
+1 213 822 1511
Braden@ISI.EDU
Encoding header field for internet messages
Prime Computer, Inc.
500 Old Connecticut Path
Framingham
MA
01701
US
+1 508 879 2960 x1774
DRB@Relay.Prime.COM
Prime Computer, Inc.
500 Old Connecticut Path
Framingham
MA
01701
US
+1 508 879 2960 x1736
Ariel@Relay.Prime.COM
Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies
Innosoft International, Inc.
1050 East Garvey Avenue South
West Covina
CA
91790
US
+1 818 919 3600
+1 818 919 3614
ned@innosoft.com
First Virtual Holdings
25 Washington Avenue
Morristown
NJ
07960
US
+1 201 540 8967
+1 201 993 3032
nsb@nsb.fv.com
STD 11, RFC 822, defines a message representation protocol specifying considerable detail about US-ASCII message headers, and leaves the message content, or message body, as flat US-ASCII text. This set of documents, collectively called the Multipurpose Internet Mail Extensions, or MIME, redefines the format of messages to allow for
(1) textual message bodies in character sets other than US-ASCII,
(2) an extensible set of different formats for non-textual message bodies,
(3) multi-part message bodies, and
(4) textual header information in character sets other than US-ASCII.
These documents are based on earlier work documented in RFC 934, STD 11, and RFC 1049, but extends and revises them. Because RFC 822 said so little about message bodies, these documents are largely orthogonal to (rather than a revision of) RFC 822.
This initial document specifies the various headers used to describe the structure of MIME messages. The second document, RFC 2046, defines the general structure of the MIME media typing system and defines an initial set of media types. The third document, RFC 2047, describes extensions to RFC 822 to allow non-US-ASCII text data in Internet mail header fields. The fourth document, RFC 2048, specifies various IANA registration procedures for MIME-related facilities. The fifth and final document, RFC 2049, describes MIME conformance
criteria as well as providing some illustrative examples of MIME message formats, acknowledgements, and the bibliography.
These documents are revisions of RFCs 1521, 1522, and 1590, which themselves were revisions of RFCs 1341 and 1342. An appendix in RFC 2049 describes differences and changes from previous versions.
Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types
Innosoft International, Inc.
1050 East Garvey Avenue South
West Covina
CA
91790
US
+1 818 919 3600
+1 818 919 3614
ned@innosoft.com
First Virtual Holdings
25 Washington Avenue
Morristown
NJ
07960
US
+1 201 540 8967
+1 201 993 3032
nsb@nsb.fv.com
STD 11, RFC 822 defines a message representation protocol specifying considerable detail about US-ASCII message headers, but which leaves the message content, or message body, as flat US-ASCII text. This set of documents, collectively called the Multipurpose Internet Mail Extensions, or MIME, redefines the format of messages to allow for
(1) textual message bodies in character sets other than US-ASCII,
(2) an extensible set of different formats for non-textual message bodies,
(3) multi-part message bodies, and
(4) textual header information in character sets other than US-ASCII.
These documents are based on earlier work documented in RFC 934, STD 11 and RFC 1049, but extends and revises them. Because RFC 822 said so little about message bodies, these documents are largely orthogonal to (rather than a revision of) RFC 822.
The initial document in this set, RFC 2045, specifies the various headers used to describe the structure of MIME messages. This second document defines the general structure of the MIME media typing sytem and defines an initial set of media types. The third document, RFC 2047, describes extensions to RFC 822 to allow non-US-ASCII text data in Internet mail header fields. The fourth document, RFC 2048, specifies various IANA registration procedures for MIME-related facilities. The fifth and final document, RFC 2049, describes MIME
conformance criteria as well as providing some illustrative examples of MIME message formats, acknowledgements, and the bibliography.
These documents are revisions of RFCs 1521 and 1522, which themselves were revisions of RFCs 1341 and 1342. An appendix in RFC 2049 describes differences and changes from previous versions.
MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text
University of Tennessee
107 Ayres Hall
Knoxville TN 37996-1301
moore@cs.utk.edu
Applications
Amercian Standard Code for Information Interchange
mail
multipurpose internet mail extensions
STD 11, RFC 822, defines a message representation protocol specifying
considerable detail about US-ASCII message headers, and leaves the
message content, or message body, as flat US-ASCII text. This set of
documents, collectively called the Multipurpose Internet Mail
Extensions, or MIME, redefines the format of messages to allow for
(1) textual message bodies in character sets other than US-ASCII,
(2) an extensible set of different formats for non-textual message
bodies,
(3) multi-part message bodies, and
(4) textual header information in character sets other than US-ASCII.
These documents are based on earlier work documented in RFC 934, STD
11, and RFC 1049, but extends and revises them. Because RFC 822 said
so little about message bodies, these documents are largely
orthogonal to (rather than a revision of) RFC 822.
This particular document is the third document in the series. It
describes extensions to RFC 822 to allow non-US-ASCII text data in
Internet mail header fields.
Other documents in this series include:
+ RFC 2045, which specifies the various headers used to describe
the structure of MIME messages.
+ RFC 2046, which defines the general structure of the MIME media
typing system and defines an initial set of media types,
+ RFC 2048, which specifies various IANA registration procedures
for MIME-related facilities, and
+ RFC 2049, which describes MIME conformance criteria and
provides some illustrative examples of MIME message formats,
acknowledgements, and the bibliography.
These documents are revisions of RFCs 1521, 1522, and 1590, which
themselves were revisions of RFCs 1341 and 1342. An appendix in RFC
2049 describes differences and changes from previous versions.
Hypertext Transfer Protocol -- HTTP/1.1
University of California, Irvine, Department of Information and Computer Science
Irvine
CA
92717-3425
US
+1 714 824 4056
fielding@ics.uci.edu
MIT Laboratory for Computer Science
545 Technology Square
Cambridge
MA
02139
US
+1 617 258 8682
jg@w3.org
Digital Equipment Corporation, Western Research Laboratory
250 University Avenue
Palo Alto
CA
94301
US
mogul@wrl.dec.com
MIT Laboratory for Computer Science
545 Technology Square
Cambridge
MA
02139
US
+1 617 258 8682
frystyk@w3.org
MIT Laboratory for Computer Science
545 Technology Square
Cambridge
MA
02139
US
+1 617 258 8682
timbl@w3.org
The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. It is a generic, stateless, object-oriented protocol which can be used for many tasks, such as name servers and distributed object management systems, through extension of its request methods. A feature of HTTP is the typing and negotiation of data representation, allowing systems to be built independently of the data being transferred.
HTTP has been in use by the World-Wide Web global information initiative since 1990. This specification defines the protocol referred to as "HTTP/1.1".
vCard MIME Directory Profile
Lotus Development Corporation
6544 Battleford Drive
Raleigh
NC 27613
USA
+1-919-676-9515
frank_dawson@lotus.com
Netscape Communications Corp.
501 East Middlefield Rd.
Mountain View
CA 94041
USA
+1.415.937.3419
howes@netscape.com
Applications
MIME
audio
content-type
directory
multipurpose internet mail extensions
This memo defines the profile of the MIME Content-Type for
directory information for a white-pages person object, based on a
vCard electronic business card. The profile definition is independent
of any particular directory service or protocol. The profile is
defined for representing and exchanging a variety of information
about an individual (e.g., formatted and structured name and delivery
addresses, email address, multiple telephone numbers, photograph,
logo, audio clips, etc.). The directory information used by this
profile is based on the attributes for the person object defined in
the X.520 and X.521 directory services recommendations. The profile
also provides the method for including a representation of a
white-pages directory entry within the MIME Content-Type defined by
the document.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY" and "OPTIONAL" in this
document are to be interpreted as described in .
Hypertext Transfer Protocol -- HTTP/1.1
Department of Information and Computer Science
University of California, Irvine
Irvine
CA
92697-3425
+1(949)824-1715
fielding@ics.uci.edu
World Wide Web Consortium
MIT Laboratory for Computer Science, NE43-356
545 Technology Square
Cambridge
MA
02139
+1(617)258-8682
jg@w3.org
Compaq Computer Corporation
Western Research Laboratory
250 University Avenue
Palo Alto
CA
94305
mogul@wrl.dec.com
World Wide Web Consortium
MIT Laboratory for Computer Science, NE43-356
545 Technology Square
Cambridge
MA
02139
+1(617)258-8682
frystyk@w3.org
Xerox Corporation
MIT Laboratory for Computer Science, NE43-356
3333 Coyote Hill Road
Palo Alto
CA
94034
masinter@parc.xerox.com
Microsoft Corporation
1 Microsoft Way
Redmond
WA
98052
paulle@microsoft.com
World Wide Web Consortium
MIT Laboratory for Computer Science, NE43-356
545 Technology Square
Cambridge
MA
02139
+1(617)258-8682
timbl@w3.org
The Hypertext Transfer Protocol (HTTP) is an application-level
protocol for distributed, collaborative, hypermedia information
systems. It is a generic, stateless, protocol which can be used for
many tasks beyond its use for hypertext, such as name servers and
distributed object management systems, through extension of its
request methods, error codes and headers . A feature of HTTP is
the typing and negotiation of data representation, allowing systems
to be built independently of the data being transferred.
HTTP has been in use by the World-Wide Web global information
initiative since 1990. This specification defines the protocol
referred to as "HTTP/1.1", and is an update to RFC 2068 .
Internet Message Format
This document specifies a syntax for text messages that are sent between computer users, within the framework of "electronic mail" messages. [STANDARDS-TRACK]
Procedures and IANA Guidelines for Definition of New DHCP Options and Message Types
This document describes the procedure for defining new DHCP options and message types. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.
Uniform Resource Names (URN) Namespace Definition Mechanisms
This document lays out general definitions of and mechanisms for establishing Uniform Resource Names (URN) "namespaces". The URN WG has defined a syntax for URNs in RFC 2141, as well as some proposed mechanisms for their resolution and use in Internet applications in RFC 3401 and RFC 3405. The whole rests on the concept of individual "namespaces" within the URN structure. Apart from proof-of-concept namespaces, the use of existing identifiers in URNs has been discussed in RFC 2288. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.
Change Process for the Session Initiation Protocol (SIP)
This memo documents a process intended to apply architectural discipline to the future development of the Session Initiation Protocol (SIP). There have been concerns with regards to new SIP proposals. Specifically, that the addition of new SIP features can be damaging towards security and/or greatly increase the complexity of the protocol. The Transport Area directors, along with the SIP and Session Initiation Proposal Investigation (SIPPING) working group chairs, have provided suggestions for SIP modifications and extensions. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.
Registration Procedures for Message Header Fields
This specification defines registration procedures for the message header fields used by Internet mail, HTTP, Netnews and other applications. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.
Uniform Resource Identifier (URI): Generic Syntax
World Wide Web Consortium
Massachusetts Institute of Technology
77 Massachusetts Avenue
Cambridge
MA
02139
USA
+1-617-253-5702
+1-617-258-5999
timbl@w3.org
http://www.w3.org/People/Berners-Lee/
Day Software
5251 California Ave., Suite 110
Irvine
CA
92617
USA
+1-949-679-2960
+1-949-679-2972
fielding@gbiv.com
http://roy.gbiv.com/
Adobe Systems Incorporated
345 Park Ave
San Jose
CA
95110
USA
+1-408-536-3024
LMM@acm.org
http://larry.masinter.net/
Applications
uniform resource identifier
URI
URL
URN
WWW
resource
A Uniform Resource Identifier (URI) is a compact sequence of characters
that identifies an abstract or physical resource. This specification
defines the generic URI syntax and a process for resolving URI references
that might be in relative form, along with guidelines and security
considerations for the use of URIs on the Internet.
The URI syntax defines a grammar that is a superset of all valid URIs,
allowing an implementation to parse the common components of a URI
reference without knowing the scheme-specific requirements of every
possible identifier. This specification does not define a generative
grammar for URIs; that task is performed by the individual
specifications of each URI scheme.
A Universally Unique IDentifier (UUID) URN Namespace
Microsoft
1 Microsoft Way
Redmond
WA
98052
US
+1 425-882-8080
paulle@microsoft.com
Refactored Networks, LLC
1635 Old Hwy 41
Suite 112, Box 138
Kennesaw
GA
30152
US
+1-678-581-9656
michael@refactored-networks.com
http://www.refactored-networks.com
DataPower Technology, Inc.
1 Alewife Center
Cambridge
MA
02142
US
+1 617-864-0455
rsalz@datapower.com
http://www.datapower.com
URN, UUID
This specification defines a Uniform Resource Name namespace for
UUIDs (Universally Unique IDentifier), also known as GUIDs (Globally
Unique IDentifier). A UUID is 128 bits long, and can
guarantee uniqueness across space and time. UUIDs were originally
used in the Apollo Network Computing System and later in the Open
Software Foundation's (OSF) Distributed Computing Environment (DCE),
and then in Microsoft Windows platforms.
This specification is derived from the DCE specification with the
kind permission of the OSF (now known as The Open Group). Information from earlier versions of the DCE specification have been
incorporated into this document.
Media Type Specifications and Registration Procedures
This document defines procedures for the specification and registration of media types for use in MIME and other Internet protocols. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.
Guidelines and Registration Procedures for New URI Schemes
This document provides guidelines and recommendations for the definition of Uniform Resource Identifier (URI) schemes. It also updates the process and IANA registry for URI schemes. It obsoletes both RFC 2717 and RFC 2718. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.
Lightweight Directory Access Protocol (LDAP): Directory Information Models
The Lightweight Directory Access Protocol (LDAP) is an Internet protocol for accessing distributed directory services that act in accordance with X.500 data and service models. This document describes the X.500 Directory Information Models, as used in LDAP. [STANDARDS-TRACK]
SDP: Session Description Protocol
This memo defines the Session Description Protocol (SDP). SDP is intended for describing multimedia sessions for the purposes of session announcement, session invitation, and other forms of multimedia session initiation. [STANDARDS-TRACK]
The Archived-At Message Header Field
This memo defines a new email header field, Archived-At:, to provide a direct link to the archived form of an individual email message. [STANDARDS-TRACK]
Message Header Field for Indicating Message Authentication Status
This memo defines a new header field for use with electronic mail messages to indicate the results of message authentication efforts. Any receiver-side software, such as mail filters or Mail User Agents (MUAs), may use this message header field to relay that information in a convenient way to users or to make sorting and filtering decisions. [STANDARDS-TRACK]
Tags for Identifying Languages
This document describes the structure, content, construction, and semantics of language tags for use in cases where it is desirable to indicate the language used in an information object. It also describes how to register values for use in language tags and the creation of user-defined extensions for private interchange. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.
Change Process for the Session Initiation Protocol (SIP) and the Real-time Applications and Infrastructure Area
This memo documents a process intended to organize the future development of the Session Initiation Protocol (SIP) and related work in the Real-time Applications and Infrastructure (RAI) Area. As the environments in which SIP is deployed grow more numerous and diverse, modifying or extending SIP in certain ways may threaten the interoperability and security of the protocol; however, the IETF process must also cater to the realities of existing deployments and serve the needs of the implementers working with SIP. This document therefore defines the functions of two long-lived working groups in the RAI Area that are, respectively, responsible for the maintenance of the core SIP specifications and the development of new efforts to extend and apply work in this space. This document obsoletes RFC 3427. This memo documents an Internet Best Current Practice.
The beginnings of the "X-" convention can be found in a suggestion made by Brian Harvey in 1975 with regard to FTP parameters :
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.
This "X" prefix was subsequently used in , , and . This usage was noted in :
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 in 1982, which distinguished between "Extension-fields" and "user-defined-fields" as follows:
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.
That rule was restated by as follows:
Keywords beginning with "X-" are permanently reserved to implementation-specific use. No standard registered encoding keyword will ever begin with "X-".
This convention continued with various specifications for media types (, , ), HTTP headers (, ), vCard parameters and properties (), Uniform Resource Names (), LDAP field names (), and other application technologies.
However, use of the "X-" prefix in email headers was effectively deprecated between the publication of in 1982 and the publication of in 2001 by removing the distinction between the "extension-field" construct and the "user-defined-field" construct (a similar change happened with regard to Session Initiation Protocol "P-" headers when was obsoleted by ).
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:
Experiments that are intended to possibly be standardized in the future, if they are successful.
Extensions that are intended to never be standardized because they are intended only for implementation-specific use or for local use on private networks.
Use of this naming convention is not mandated by the Internet Standards Process or IANA registration rules . 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., and ).
The primary problem with the "X-" convention is that non-standard parameters have a tendency to leak into the protected space of standard parameters (whether de jure or de facto), thus introducing the need for migration from the "X-" name to the standard 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 standard name. To preserve interoperability, newer implementations simply support the "X-" name forever, which means that the non-standard name has become a de facto standard (thus obviating the need for segregation of the name space into "standard" and "non-standard" areas in the first place).
We have already seen this phenomenon at work with regard to FTP in the quote from in the previous section. The HTTP community had the same experience with the "x-gzip" and "x-compressed" media types, as noted in :
For compatibility with previous implementations of HTTP, applications should consider "x-gzip" and "x-compress" to be equivalent to "gzip" and "compress" respectively.
A similar example can be found in , which defined the "Archived-At" message header field but also found it necessary to define and register the "X-Archived-At" field:
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.
One of the original reasons for segregation of name spaces into standard and non-standard areas was the perceived difficulty of registering names. However, the solution to that problem has been simpler registration rules, such as those provided by and . As explained in :
[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.
For some name spaces, another helpful practice has been the establishment of separate registries for permanent names and provisional names, as in .
Furthermore, often standardization of a non-standard parameter or protocol element leads to subtly different behavior (e.g., the standard version might have different security properties as a result of security review provided during the standardization process). If implementers treat the old, non-standard parameter and the new, standard parameter as equivalent, interoperability and security problems can ensue.
For similar considerations with regard to the "P-" convention in the Session Initiation Protocol, see .
In some situations, segregating the parameter name space used in a given application protocol can be justified:
When it is extremely unlikely that some parameters will ever be standardized. However, in this case implementation-specific and private-use parameters could at least incorporate the organization's name (e.g., "ExampleInc-foo" or, consistent with , "VND.ExampleInc.foo") or primary domain name (e.g., "com.example.foo" or a Uniform Resource Identifier 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 UUIDs .
When parameter names might have significant meaning. However, 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").
When parameter names need to be very short (e.g., as in for language tags). However, in this case it can be more efficient to assign numbers instead of human-readable names (e.g., as in for DCHP 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 ).
There are three primary objections to deprecating the "X-" convention as a best practice for application protocols:
Implementers are easily confused and can't be expected to know that a parameter is non-standard unless it contains the "X-" prefix. However, implementers already are quite flexible about using both prefixed and non-prefixed names based on what works in the field, so the distinction between de facto names (e.g., "X-foo") and de jure names (e.g., "foo") is without force.
Collisions are undesirable and it would be bad for both a standard parameter "foo" and a non-standard 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".
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 ).
Therefore it appears that segregating the parameter space into a standard area and a non-standard area has few if any benefits, and has at least one significant cost in terms of interoperability.