One document matched: draft-saintandre-xdash-considered-harmful-01.xml
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc compact="yes"?>
<?rfc iprnotified="no" ?>
<?rfc strict="yes"?>
<?rfc symrefs="yes"?>
<?rfc toc="yes"?>
<?rfc tocdepth="4"?>
<rfc category="bcp" docName="draft-saintandre-xdash-considered-harmful-01" ipr="trust200902">
<front>
<title abbrev="X- Considered Harmful">"X-" Considered Harmful</title>
<author initials="P." surname="Saint-Andre" fullname="Peter Saint-Andre">
<organization>Cisco</organization>
<address>
<postal>
<street>1899 Wyknoop Street, Suite 600</street>
<city>Denver</city>
<region>CO</region>
<code>80202</code>
<country>USA</country>
</postal>
<phone>+1-303-308-3282</phone>
<email>psaintan@cisco.com</email>
</address>
</author>
<date month="October" day="19" year="2010"/>
<area>Applications</area>
<keyword>Internet-Draft</keyword>
<abstract>
<t>Many application protocols use named parameters to represent data (for example, header fields in Internet mail messages and HTTP requests). Historically, protocol designers and implementers have often differentiated between "standard" and "experimental" parameters by prefixing experimental parameters with the string "X-". This document argues that, on balance, the "X-" convention has more costs than benefits.</t>
</abstract>
</front>
<middle>
<section title="Introduction" anchor="introduction">
<t>Many application protocols use named parameters to represent data (for example, header fields in Internet mail messages and HTTP requests). Historically, protocol designers and implementers have often differentiated between "standard" and "experimental" parameters by prefixing experimental parameters with the string "X-", where the "X" stands for "eXperimental". This document argues that on balance the "X-" convention has more costs than benefits.</t>
</section>
<section title="Argument" anchor="argument">
<t>The "X-" convention has been in use for email header fields since the publication of <xref target='RFC822'/> in 1982, which distinguished between Extension-fields and user-defined-fields as follows:</t>
<t><list style='empty'><t>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.</t></list></t>
<t>That rule was restated by <xref target='RFC1154'/> as follows:</t>
<t><list style='empty'><t>Keywords beginning with "X-" are permanently reserved to implementation-specific use. No standard registered encoding keyword will ever begin with "X-".</t></list></t>
<t>This convention continued with various specifications for MIME <xref target='RFC2045'/> <xref target='RFC2046'/> <xref target='RFC2047'/>, email <xref target='RFC2821'/> <xref target='RFC5321'/>, HTTP <xref target='RFC2068'/> <xref target='RFC2616'/>, and other technologies.</t>
<t>The primary problem with the "X-" convention is that experimental or implementation-specific parameters have a tendency to become standardized (whether de jure or de facto), thus introducing the need for migration from the "X-" name to the standardized name. Migration, in turn, introduces interoperability issues because older implementations will support only the "X-" name and newer implementations might support only the standardized name. To preserve interoperability, newer implementations simply support the "X-" name forever, which means that the experimental name becomes a de facto standard (thus obviating the need for segregation of the name spaces in the first place). We can see this phenomenon at work in <xref target='RFC2068'/>:</t>
<t><list style='empty'><t>For compatibility with previous implementations of HTTP, applications should consider "x-gzip" and "x-compress" to be equivalent to "gzip" and "compress" respectively.</t></list></t>
<t>One of the original reasons for segregation of name spaces into standard and experimental areas was the perceived difficulty of registering names. However, the solution to that problem has been simpler registration rules, such as those provided by <xref target='RFC3864'/> and <xref target='RFC4288'/>, as well as separate registries for permanent and provisional names. Indeed, <xref target='RFC4288'/> explicitly calls out the implications for experimental names:</t>
<t><list style='empty'><t>[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.</t></list></t>
<t>In some limited situations, segregating a name space can be justified; for example, when the names need to be very small (as in <xref target='RFC5646'/>) or when the names have significant meaning. However, in general, segregating experimental or implementation-specific parameters into an "X-" ghetto has few if any benefits, and has at least one significant interoperability cost. The practice is at best useless and at worst harmful.</t>
<t>The primary objections to discarding the "X-" convention are:</t>
<t>
<list style='symbols'>
<t>Implementers are easily confused. 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 meaningless to them.<vspace blankLines='1'/></t>
<t>Collisions are undesirable. However, names are usually cheap, so an experimental or implementation-specific name of "foo" does not prevent a standards development organization from issuing a similarly creative name such as "bar".</t>
</list>
</t>
<t>Therefore, this document recommends against the creation of new names with the special "X-" prefix in IETF protocols.</t>
</section>
<section title="Security Considerations" anchor="security">
<t>Interoperability and migration issues with security-critical paramaters can result in unnecessary vulnerabilities.</t>
</section>
<section title="IANA Considerations" anchor="iana">
<t>This document has no actions for the IANA.</t>
</section>
<section title="Acknowledgements" anchor="acks">
<t>Thanks to Adam Barth, Dave Crocker, Martin Duerst, Paul Hoffman, Graham Klyne, Alexey Melnikov, Mark Nottingham, and Randy Presuhn for feedback.</t>
</section>
</middle>
<back>
<references title="Informative References">
<reference anchor='RFC822'>
<front>
<title abbrev='Standard for ARPA Internet Text Messages'>Standard for the format of ARPA Internet text messages</title>
<author initials='D.H.' surname='Crocker' fullname='David H. Crocker'>
<organization>University of Delaware, Dept. of Electrical Engineering</organization>
<address>
<postal>
<street />
<city>Newark</city>
<region>DE</region>
<code>19711</code>
<country>US</country></postal>
<email>DCrocker@UDel-Relay</email></address></author>
<date year='1982' day='13' month='August' /></front>
<seriesInfo name='STD' value='11' />
<seriesInfo name='RFC' value='822' />
<format type='TXT' octets='109200' target='http://www.rfc-editor.org/rfc/rfc822.txt' />
</reference>
<reference anchor='RFC1154'>
<front>
<title>Encoding header field for internet messages</title>
<author initials='D.' surname='Robinson' fullname='David Robinson'>
<organization>Prime Computer, Inc.</organization>
<address>
<postal>
<street>500 Old Connecticut Path</street>
<city>Framingham</city>
<region>MA</region>
<code>01701</code>
<country>US</country></postal>
<phone>+1 508 879 2960 x1774</phone>
<email>DRB@Relay.Prime.COM</email></address></author>
<author initials='R.' surname='Ullmann' fullname='Robert Ullmann'>
<organization>Prime Computer, Inc.</organization>
<address>
<postal>
<street>500 Old Connecticut Path</street>
<city>Framingham</city>
<region>MA</region>
<code>01701</code>
<country>US</country></postal>
<phone>+1 508 879 2960 x1736</phone>
<email>Ariel@Relay.Prime.COM</email></address></author>
<date year='1990' day='1' month='April' /></front>
<seriesInfo name='RFC' value='1154' />
<format type='TXT' octets='12214' target='ftp://ftp.isi.edu/in-notes/rfc1154.txt' />
</reference>
<reference anchor='RFC2045'>
<front>
<title abbrev='Internet Message Bodies'>Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies</title>
<author initials='N.' surname='Freed' fullname='Ned Freed'>
<organization>Innosoft International, Inc.</organization>
<address>
<postal>
<street>1050 East Garvey Avenue South</street>
<city>West Covina</city>
<region>CA</region>
<code>91790</code>
<country>US</country></postal>
<phone>+1 818 919 3600</phone>
<facsimile>+1 818 919 3614</facsimile>
<email>ned@innosoft.com</email></address></author>
<author initials='N.S.' surname='Borenstein' fullname='Nathaniel S. Borenstein'>
<organization>First Virtual Holdings</organization>
<address>
<postal>
<street>25 Washington Avenue</street>
<city>Morristown</city>
<region>NJ</region>
<code>07960</code>
<country>US</country></postal>
<phone>+1 201 540 8967</phone>
<facsimile>+1 201 993 3032</facsimile>
<email>nsb@nsb.fv.com</email></address></author>
<date year='1996' month='November' />
<abstract>
<t>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</t>
<t>(1) textual message bodies in character sets other than US-ASCII,</t>
<t>(2) an extensible set of different formats for non-textual message bodies,</t>
<t>(3) multi-part message bodies, and</t>
<t>(4) textual header information in character sets other than US-ASCII.</t>
<t>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.</t>
<t>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.</t>
<t>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.</t></abstract></front>
<seriesInfo name='RFC' value='2045' />
<format type='TXT' octets='72932' target='ftp://ftp.isi.edu/in-notes/rfc2045.txt' />
</reference>
<reference anchor='RFC2046'>
<front>
<title abbrev='Media Types'>Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types</title>
<author initials='N.' surname='Freed' fullname='Ned Freed'>
<organization>Innosoft International, Inc.</organization>
<address>
<postal>
<street>1050 East Garvey Avenue South</street>
<city>West Covina</city>
<region>CA</region>
<code>91790</code>
<country>US</country></postal>
<phone>+1 818 919 3600</phone>
<facsimile>+1 818 919 3614</facsimile>
<email>ned@innosoft.com</email></address></author>
<author initials='N.' surname='Borenstein' fullname='Nathaniel S. Borenstein'>
<organization>First Virtual Holdings</organization>
<address>
<postal>
<street>25 Washington Avenue</street>
<city>Morristown</city>
<region>NJ</region>
<code>07960</code>
<country>US</country></postal>
<phone>+1 201 540 8967</phone>
<facsimile>+1 201 993 3032</facsimile>
<email>nsb@nsb.fv.com</email></address></author>
<date year='1996' month='November' />
<abstract>
<t>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</t>
<t>(1) textual message bodies in character sets other than US-ASCII,</t>
<t>(2) an extensible set of different formats for non-textual message bodies,</t>
<t>(3) multi-part message bodies, and</t>
<t>(4) textual header information in character sets other than US-ASCII.</t>
<t>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.</t>
<t>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.</t>
<t>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.</t></abstract></front>
<seriesInfo name='RFC' value='2046' />
<format type='TXT' octets='105854' target='ftp://ftp.isi.edu/in-notes/rfc2046.txt' />
</reference>
<reference anchor='RFC2047'>
<front>
<title abbrev='Message Header Extensions'>MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text</title>
<author initials='K.' surname='Moore' fullname='Keith Moore'>
<organization>University of Tennessee</organization>
<address>
<postal>
<street>107 Ayres Hall</street>
<street>Knoxville TN 37996-1301</street></postal>
<email>moore@cs.utk.edu</email></address></author>
<date year='1996' month='November' />
<area>Applications</area>
<keyword>Amercian Standard Code for Information Interchange</keyword>
<keyword>mail</keyword>
<keyword>multipurpose internet mail extensions</keyword>
<abstract>
<t>
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
<list>
<t>
(1) textual message bodies in character sets other than US-ASCII,
</t>
<t>
(2) an extensible set of different formats for non-textual message
bodies,
</t>
<t>
(3) multi-part message bodies, and
</t>
<t>
(4) textual header information in character sets other than US-ASCII.
</t></list></t>
<t>
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.
</t>
<t>
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:
<list>
<t>
+ RFC 2045, which specifies the various headers used to describe
the structure of MIME messages.
</t>
<t>
+ RFC 2046, which defines the general structure of the MIME media
typing system and defines an initial set of media types,
</t>
<t>
+ RFC 2048, which specifies various IANA registration procedures
for MIME-related facilities, and
</t>
<t>
+ RFC 2049, which describes MIME conformance criteria and
provides some illustrative examples of MIME message formats,
acknowledgements, and the bibliography.
</t></list></t>
<t>
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.
</t></abstract></front>
<seriesInfo name='RFC' value='2047' />
<format type='TXT' octets='33262' target='ftp://ftp.isi.edu/in-notes/rfc2047.txt' />
<format type='HTML' octets='52141' target='http://xml.resource.org/public/rfc/html/rfc2047.html' />
<format type='XML' octets='39194' target='http://xml.resource.org/public/rfc/xml/rfc2047.xml' />
</reference>
<reference anchor='RFC2068'>
<front>
<title abbrev='HTTP/1.1'>Hypertext Transfer Protocol -- HTTP/1.1</title>
<author initials='R.' surname='Fielding' fullname='Roy T. Fielding'>
<organization>University of California, Irvine, Department of Information and Computer Science</organization>
<address>
<postal>
<street />
<city>Irvine</city>
<region>CA</region>
<code>92717-3425</code>
<country>US</country></postal>
<facsimile>+1 714 824 4056</facsimile>
<email>fielding@ics.uci.edu</email></address></author>
<author initials='J.' surname='Gettys' fullname='Jim Gettys'>
<organization>MIT Laboratory for Computer Science</organization>
<address>
<postal>
<street>545 Technology Square</street>
<city>Cambridge</city>
<region>MA</region>
<code>02139</code>
<country>US</country></postal>
<facsimile>+1 617 258 8682</facsimile>
<email>jg@w3.org</email></address></author>
<author initials='J.' surname='Mogul' fullname='Jeffrey C. Mogul'>
<organization>Digital Equipment Corporation, Western Research Laboratory</organization>
<address>
<postal>
<street>250 University Avenue</street>
<city>Palo Alto</city>
<region>CA</region>
<code>94301</code>
<country>US</country></postal>
<email>mogul@wrl.dec.com</email></address></author>
<author initials='H.' surname='Nielsen' fullname='Henrik Frystyk Nielsen'>
<organization>MIT Laboratory for Computer Science</organization>
<address>
<postal>
<street>545 Technology Square</street>
<city>Cambridge</city>
<region>MA</region>
<code>02139</code>
<country>US</country></postal>
<facsimile>+1 617 258 8682</facsimile>
<email>frystyk@w3.org</email></address></author>
<author initials='T.' surname='Berners-Lee' fullname='Tim Berners-Lee'>
<organization>MIT Laboratory for Computer Science</organization>
<address>
<postal>
<street>545 Technology Square</street>
<city>Cambridge</city>
<region>MA</region>
<code>02139</code>
<country>US</country></postal>
<facsimile>+1 617 258 8682</facsimile>
<email>timbl@w3.org</email></address></author>
<date year='1997' month='January' />
<abstract>
<t>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.</t>
<t>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".</t></abstract></front>
<seriesInfo name='RFC' value='2068' />
<format type='TXT' octets='378114' target='ftp://ftp.isi.edu/in-notes/rfc2068.txt' />
</reference>
<reference anchor='RFC2616'>
<front>
<title abbrev='HTTP/1.1'>Hypertext Transfer Protocol -- HTTP/1.1</title>
<author initials='R.' surname='Fielding' fullname='Roy T. Fielding'>
<organization abbrev='UC Irvine'>Department of Information and Computer Science</organization>
<address>
<postal>
<street>University of California, Irvine</street>
<city>Irvine</city>
<region>CA</region>
<code>92697-3425</code></postal>
<facsimile>+1(949)824-1715</facsimile>
<email>fielding@ics.uci.edu</email></address></author>
<author initials='J.' surname='Gettys' fullname='James Gettys'>
<organization abbrev='Compaq/W3C'>World Wide Web Consortium</organization>
<address>
<postal>
<street>MIT Laboratory for Computer Science, NE43-356</street>
<street>545 Technology Square</street>
<city>Cambridge</city>
<region>MA</region>
<code>02139</code></postal>
<facsimile>+1(617)258-8682</facsimile>
<email>jg@w3.org</email></address></author>
<author initials='J.' surname='Mogul' fullname='Jeffrey C. Mogul'>
<organization abbrev='Compaq'>Compaq Computer Corporation</organization>
<address>
<postal>
<street>Western Research Laboratory</street>
<street>250 University Avenue</street>
<city>Palo Alto</city>
<region>CA</region>
<code>94305</code></postal>
<email>mogul@wrl.dec.com</email></address></author>
<author initials='H.' surname='Frystyk' fullname='Henrik Frystyk Nielsen'>
<organization abbrev='W3C/MIT'>World Wide Web Consortium</organization>
<address>
<postal>
<street>MIT Laboratory for Computer Science, NE43-356</street>
<street>545 Technology Square</street>
<city>Cambridge</city>
<region>MA</region>
<code>02139</code></postal>
<facsimile>+1(617)258-8682</facsimile>
<email>frystyk@w3.org</email></address></author>
<author initials='L.' surname='Masinter' fullname='Larry Masinter'>
<organization abbrev='Xerox'>Xerox Corporation</organization>
<address>
<postal>
<street>MIT Laboratory for Computer Science, NE43-356</street>
<street>3333 Coyote Hill Road</street>
<city>Palo Alto</city>
<region>CA</region>
<code>94034</code></postal>
<email>masinter@parc.xerox.com</email></address></author>
<author initials='P.' surname='Leach' fullname='Paul J. Leach'>
<organization abbrev='Microsoft'>Microsoft Corporation</organization>
<address>
<postal>
<street>1 Microsoft Way</street>
<city>Redmond</city>
<region>WA</region>
<code>98052</code></postal>
<email>paulle@microsoft.com</email></address></author>
<author initials='T.' surname='Berners-Lee' fullname='Tim Berners-Lee'>
<organization abbrev='W3C/MIT'>World Wide Web Consortium</organization>
<address>
<postal>
<street>MIT Laboratory for Computer Science, NE43-356</street>
<street>545 Technology Square</street>
<city>Cambridge</city>
<region>MA</region>
<code>02139</code></postal>
<facsimile>+1(617)258-8682</facsimile>
<email>timbl@w3.org</email></address></author>
<date year='1999' month='June' />
<abstract>
<t>
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.
</t>
<t>
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 .
</t></abstract></front>
<seriesInfo name='RFC' value='2616' />
<format type='TXT' octets='422317' target='ftp://ftp.isi.edu/in-notes/rfc2616.txt' />
<format type='PS' octets='5529857' target='ftp://ftp.isi.edu/in-notes/rfc2616.ps' />
<format type='PDF' octets='550558' target='ftp://ftp.isi.edu/in-notes/rfc2616.pdf' />
<format type='HTML' octets='636125' target='http://xml.resource.org/public/rfc/html/rfc2616.html' />
<format type='XML' octets='493420' target='http://xml.resource.org/public/rfc/xml/rfc2616.xml' />
</reference>
<reference anchor='RFC2821'>
<front>
<title>Simple Mail Transfer Protocol</title>
<author initials='J.' surname='Klensin' fullname='J. Klensin'>
<organization /></author>
<date year='2001' month='April' />
<abstract>
<t>This document is a self-contained specification of the basic protocol for the Internet electronic mail transport. [STANDARDS TRACK]</t></abstract></front>
<seriesInfo name='RFC' value='2821' />
<format type='TXT' octets='192504' target='ftp://ftp.isi.edu/in-notes/rfc2821.txt' />
</reference>
<reference anchor='RFC3864'>
<front>
<title>Registration Procedures for Message Header Fields</title>
<author initials='G.' surname='Klyne' fullname='G. Klyne'>
<organization /></author>
<author initials='M.' surname='Nottingham' fullname='M. Nottingham'>
<organization /></author>
<author initials='J.' surname='Mogul' fullname='J. Mogul'>
<organization /></author>
<date year='2004' month='September' />
<abstract>
<t>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.</t></abstract></front>
<seriesInfo name='BCP' value='90' />
<seriesInfo name='RFC' value='3864' />
<format type='TXT' octets='36231' target='http://www.rfc-editor.org/rfc/rfc3864.txt' />
</reference>
<reference anchor='RFC4288'>
<front>
<title>Media Type Specifications and Registration Procedures</title>
<author initials='N.' surname='Freed' fullname='N. Freed'>
<organization /></author>
<author initials='J.' surname='Klensin' fullname='J. Klensin'>
<organization /></author>
<date year='2005' month='December' />
<abstract>
<t>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.</t></abstract></front>
<seriesInfo name='BCP' value='13' />
<seriesInfo name='RFC' value='4288' />
<format type='TXT' octets='52667' target='http://www.rfc-editor.org/rfc/rfc4288.txt' />
</reference>
<reference anchor='RFC5321'>
<front>
<title>Simple Mail Transfer Protocol</title>
<author initials='J.' surname='Klensin' fullname='J. Klensin'>
<organization /></author>
<date year='2008' month='October' />
<abstract>
<t>This document is a specification of the basic protocol for Internet electronic mail transport. It consolidates, updates, and clarifies several previous documents, making all or parts of most of them obsolete. It covers the SMTP extension mechanisms and best practices for the contemporary Internet, but does not provide details about particular extensions. Although SMTP was designed as a mail transport and delivery protocol, this specification also contains information that is important to its use as a "mail submission" protocol for "split-UA" (User Agent) mail reading systems and mobile environments. [STANDARDS TRACK]</t></abstract></front>
<seriesInfo name='RFC' value='5321' />
<format type='TXT' octets='225929' target='ftp://ftp.isi.edu/in-notes/rfc5321.txt' />
</reference>
<reference anchor='RFC5646'>
<front>
<title>Tags for Identifying Languages</title>
<author initials='A.' surname='Phillips' fullname='A. Phillips'>
<organization /></author>
<author initials='M.' surname='Davis' fullname='M. Davis'>
<organization /></author>
<date year='2009' month='September' />
<abstract>
<t>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.</t></abstract></front>
<seriesInfo name='BCP' value='47' />
<seriesInfo name='RFC' value='5646' />
<format type='TXT' octets='208592' target='http://www.rfc-editor.org/rfc/rfc5646.txt' />
</reference>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 02:38:37 |