One document matched: draft-saintandre-xdash-00.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-00" ipr="trust200902">

  <front>
    <title abbrev="The X- Prefix">Use of the "X-" Prefix in Application Protocols</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="June" day="27" year="2011"/>

    <area>Applications</area>
    <keyword>Internet-Draft</keyword>

    <abstract>
      <t>Many application protocols use named parameters to identity data.  Historically, protocol designers and implementers distinguished between "standard" and "non-standard" parameters by prefixing the latter with the string "X-".  On balance, this "X-" convention has more costs than benefits, although it can be appropriate in certain circumstances.</t>
    </abstract>
  </front>

  <middle>

    <section title="Background" anchor="background">
      <t>Many application protocols use named parameters to identity data (media types, header fields in Internet mail messages and HTTP requests, etc.).  Historically, protocol designers and implementers have often distinguished between "standard" and "non-standard" parameters by prefixing the latter with the string "X-", where the "X" stands for "eXperimental".</t>
      <t>This "X-" convention has been uses for email header fields at least 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 media types (<xref target='RFC2045'/>, <xref target='RFC2046'/>, <xref target='RFC2047'/>), email headers (<xref target='RFC2821'/>, <xref target='RFC5321'/>), HTTP headers (<xref target='RFC2068'/>, <xref target='RFC2616'/>), Uniform Resource Names (<xref target='RFC3406'/>), Session Initiation Protocol "P-" headers (<xref target='RFC3427'/>, obsoleted by <xref target='RFC5727'/>), and other technologies.</t>
      <t>Parameters prefaced with the "X-" string (and similar constructions, such as "x.") are currently used in application protocols for two different purposes:</t>
      <t>
        <list style='symbols'>
          <t>Experiments that might lead to standardization in the future.</t>
          <t>Implementation-specific applications or private networks that are never intended to be standardized.</t>
        </list>
      </t>
      <t>The remainder of this document analyzes the benefits and costs of the "X-" convention and specifies when it is appropriate to apply the convention in application protocols produced by the IETF.</t>
    </section>

    <section title="Analysis" anchor="analysis">
      <t>The primary problem with the "X-" convention is that non-standard parameters have a tendency to leak into the protected space of standardized parameters (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 non-standard name becomes a de facto standard (thus obviating the need for segregation of the name spaces in the first place).  As one example, we can see this phenomenon at work in <xref target='RFC2068'/> (similar examples can be found in <xref target='RFC5064'/>):</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 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 <xref target='RFC3864'/> and <xref target='RFC4288'/>, as well as separate registries for permanent and provisional names.</t>
      <t><xref target='RFC4288'/> calls out one implication of non-standard 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>Furthermore, often standarization of a non-standard parameter or protocol element leads to subtly different behavior (e.g., the standardized 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.</t>
      <t>For similar considerations with regard to the "P-" convention in the Session Initiation Protocol, see <xref target='RFC5727'/>.</t>
      <t>In some situations, segregating the name space of parameters used in a given application protocol can be justified:</t>
      <t>
        <list style='numbers'>
          <t>When it is extremely unlikely that some parameters will ever be standardized.  In this case, private-use parameters can be URIs (e.g., "http://example.com/foo") or can be prepended with a string that is derived from the name or primary domain name of the organization that has defined the parameter (e.g., "Example-Foo" or "com.example.foo").  Similarly, truly experimental parameters can be given meaningless names such as UUIDs <xref target='RFC4122'/>.<vspace blankLines='1'/></t>
          <t>When parameter names might have significant meaning.  This case is rare, since implementers can almost always find a synonym (e.g., "urgency" instead of "priority") or simply invent a new name.<vspace blankLines='1'/></t>
          <t>When parameter names need to be very short (e.g., as in <xref target='RFC5646'/> for language tags).  In this case, it can be more efficient to assign numbers instead of human-readable names (e.g., as in <xref target='RFC2939'/> for DCHP options) and to leave a certain numeric range for private use (e.g., as with the codec numbers used with the Session Description Protocol <xref target='RFC4566'/>).</t>
        </list>
      </t>
      <t>There are two primary objections to deprecating the "X-" convention as a best practice for application protocols:</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 almost always 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>In addition, the existence of <xref target='BCP82'/> ("Assigning Experimental and Testing Numbers Considered Useful") might appear to provide an argument against deprecating the "X-" convention.  However, BCP 82 addresses the need for protocols 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 (e.g., media types, email headers, HTTP headers, URIs), 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 <xref target='BCP26'/>).</t>
      <t>The foregoing considerations lead to the conclusion that segregating non-standard parameters into an "X-" ghetto has few if any benefits, and has at least one significant cost in terms of interoperability.  Therefore, this document recommends against the creation of new names with the special "X-" prefix in application protocols produced within the IETF.</t>
    </section>

    <section title="Security Considerations" anchor="security">
      <t>Interoperability and migration issues with security-critical parameters can result in unnecessary vulnerabilities.</t>
    </section>

    <section title="IANA Considerations" anchor="iana">
      <t>This document requests no action by the IANA.</t>
    </section>

    <section title="Acknowledgements" anchor="acks">
      <t>Thanks to Claudio Allocchio, Adam Barth, Nathaniel Borenstein, Eric Burger, Al Constanzo, Dave Cridland, Dave Crocker, Martin Duerst, J.D. Falk, Tony Finch, Tony Hansen, Ted Hardie, Joe Hildebrand, Alfred Hoenes, Paul Hoffman, Eric Johnson, John Klensin, Graham Klyne, Murray Kucherawy, Eliot Lear, Bill McQuillan, Alexey Melnikov, Subramanian Moonesamy, Keith Moore, Mark Nottingham, Randy Presuhn, Julian Reschke, Doug Royer, Andrew Sullivan, Martin Thomson, Nicolas Williams, and Kurt Zeilenga for feedback.</t>
    </section>

  </middle>

  <back>

    <references title="Informative References">

<reference anchor='BCP26'>
<front>
<title>Guidelines for Writing an IANA Considerations Section in RFCs</title>
<author initials='T.' surname='Narten' fullname='T. Narten'>
<organization /></author>
<author initials='H.' surname='Alvestrand' fullname='H. Alvestrand'>
<organization /></author>
<date year='2008' month='May' />
<abstract>
<t>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.</t></abstract></front>
<seriesInfo name='BCP' value='26' />
<seriesInfo name='RFC' value='5226' />
<format type='TXT' octets='66160' target='http://www.rfc-editor.org/rfc/rfc5226.txt' />
</reference>

<reference anchor='BCP82'>
<front>
<title>Assigning Experimental and Testing Numbers Considered Useful</title>
<author initials='T.' surname='Narten' fullname='T. Narten'>
<organization /></author>
<date year='2004' month='January' />
<abstract>
<t>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.</t></abstract></front>
<seriesInfo name='BCP' value='82' />
<seriesInfo name='RFC' value='3692' />
<format type='TXT' octets='15054' target='http://www.rfc-editor.org/rfc/rfc3692.txt' />
</reference>

<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='RFC2939'>
<front>
<title>Procedures and IANA Guidelines for Definition of New DHCP Options and Message Types</title>
<author initials='R.' surname='Droms' fullname='R. Droms'>
<organization /></author>
<date year='2000' month='September' />
<abstract>
<t>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.</t></abstract></front>
<seriesInfo name='BCP' value='43' />
<seriesInfo name='RFC' value='2939' />
<format type='TXT' octets='13631' target='http://www.rfc-editor.org/rfc/rfc2939.txt' />
</reference>

<reference anchor='RFC3406'>
<front>
<title>Uniform Resource Names (URN) Namespace Definition Mechanisms</title>
<author initials='L.' surname='Daigle' fullname='L. Daigle'>
<organization /></author>
<author initials='D.' surname='van Gulik' fullname='D. van Gulik'>
<organization /></author>
<author initials='R.' surname='Iannella' fullname='R. Iannella'>
<organization /></author>
<author initials='P.' surname='Faltstrom' fullname='P. Faltstrom'>
<organization /></author>
<date year='2002' month='October' />
<abstract>
<t>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.</t></abstract></front>
<seriesInfo name='BCP' value='66' />
<seriesInfo name='RFC' value='3406' />
<format type='TXT' octets='43707' target='http://www.rfc-editor.org/rfc/rfc3406.txt' />
</reference>

<reference anchor='RFC3427'>
<front>
<title>Change Process for the Session Initiation Protocol (SIP)</title>
<author initials='A.' surname='Mankin' fullname='A. Mankin'>
<organization /></author>
<author initials='S.' surname='Bradner' fullname='S. Bradner'>
<organization /></author>
<author initials='R.' surname='Mahy' fullname='R. Mahy'>
<organization /></author>
<author initials='D.' surname='Willis' fullname='D. Willis'>
<organization /></author>
<author initials='J.' surname='Ott' fullname='J. Ott'>
<organization /></author>
<author initials='B.' surname='Rosen' fullname='B. Rosen'>
<organization /></author>
<date year='2002' month='December' />
<abstract>
<t>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.</t></abstract></front>
<seriesInfo name='RFC' value='3427' />
<format type='TXT' octets='26234' target='http://www.rfc-editor.org/rfc/rfc3427.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='RFC4122'>
<front>
<title abbrev='UUID URN'>A Universally Unique IDentifier (UUID) URN Namespace</title>
<author initials='P.' surname='Leach' fullname='Paul J. Leach'>
<organization>Microsoft</organization>
<address>
<postal>
<street>1 Microsoft Way</street>
<city>Redmond</city>
<region>WA</region>
<code>98052</code>
<country>US</country></postal>
<phone>+1 425-882-8080</phone>
<email>paulle@microsoft.com</email></address></author>
<author initials='M.' surname='Mealling' fullname='Michael Mealling'>
<organization>Refactored Networks, LLC</organization>
<address>
<postal>
<street>1635 Old Hwy 41</street>
<street>Suite 112, Box 138</street>
<city>Kennesaw</city>
<region>GA</region>
<code>30152</code>
<country>US</country></postal>
<phone>+1-678-581-9656</phone>
<email>michael@refactored-networks.com</email>
<uri>http://www.refactored-networks.com</uri></address></author>
<author initials='R.' surname='Salz' fullname='Rich Salz'>
<organization>DataPower Technology, Inc.</organization>
<address>
<postal>
<street>1 Alewife Center</street>
<city>Cambridge</city>
<region>MA</region>
<code>02142</code>
<country>US</country></postal>
<phone>+1 617-864-0455</phone>
<email>rsalz@datapower.com</email>
<uri>http://www.datapower.com</uri></address></author>
<date year='2005' month='July' />
<keyword>URN, UUID</keyword>
<abstract>
<t>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.</t>
<t>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.</t></abstract></front>
<seriesInfo name='RFC' value='4122' />
<format type='TXT' octets='59319' target='http://www.rfc-editor.org/rfc/rfc4122.txt' />
<format type='HTML' octets='82717' target='http://xml.resource.org/public/rfc/html/rfc4122.html' />
<format type='XML' octets='62931' target='http://xml.resource.org/public/rfc/xml/rfc4122.xml' />
</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='RFC4566'>
<front>
<title>SDP: Session Description Protocol</title>
<author initials='M.' surname='Handley' fullname='M. Handley'>
<organization /></author>
<author initials='V.' surname='Jacobson' fullname='V. Jacobson'>
<organization /></author>
<author initials='C.' surname='Perkins' fullname='C. Perkins'>
<organization /></author>
<date year='2006' month='July' />
<abstract>
<t>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]</t></abstract></front>
<seriesInfo name='RFC' value='4566' />
<format type='TXT' octets='108820' target='http://www.rfc-editor.org/rfc/rfc4566.txt' />
</reference>

<reference anchor='RFC5064'>
<front>
<title>The Archived-At Message Header Field</title>
<author initials='M.' surname='Duerst' fullname='M. Duerst'>
<organization /></author>
<date year='2007' month='December' />
<abstract>
<t>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]</t></abstract></front>
<seriesInfo name='RFC' value='5064' />
<format type='TXT' octets='20863' target='http://www.rfc-editor.org/rfc/rfc5064.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>

<reference anchor='RFC5727'>
<front>
<title>Change Process for the Session Initiation Protocol (SIP) and the Real-time Applications and Infrastructure Area</title>
<author initials='J.' surname='Peterson' fullname='J. Peterson'>
<organization /></author>
<author initials='C.' surname='Jennings' fullname='C. Jennings'>
<organization /></author>
<author initials='R.' surname='Sparks' fullname='R. Sparks'>
<organization /></author>
<date year='2010' month='March' />
<abstract>
<t>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.</t></abstract></front>
<seriesInfo name='BCP' value='67' />
<seriesInfo name='RFC' value='5727' />
<format type='TXT' octets='35033' target='http://www.rfc-editor.org/rfc/rfc5727.txt' />
</reference>

    </references>

  </back>
</rfc>