One document matched: draft-saintandre-xdash-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-01" 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="July" day="5" year="2011"/>

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

    <abstract>
      <t>Many application protocols use named parameters to identify data.  Historically, protocol designers and implementers distinguished between "standard" and "non-standard" parameters by prefixing the latter with the string "X-" or similar constructions.  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 identify 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-" or similar constructions (e.g., "x."), where the "X" is commonly understood to stand for "eXperimental" or "eXtension".</t>
      <t>Although this usage is purely conventional and is not mandated by the Internet Standards Process <xref target='BCP9'/> or IANA registration rules <xref target='BCP26'/>, some implementers, and even some RFCs, have interpreted the convention in a more normative way (e.g., <xref target='RFC5451'/> states that "result codes not beginning with 'x-' MUST be registered with the Internet Assigned Numbers Authority (IANA) and published in an RFC").</t>
      <t>The "X-" convention has been used for email header fields since at least 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 (and subsequently reinforced by <xref target='RFC2821'/> and <xref target='RFC5321'/>):</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'/>), HTTP headers (<xref target='RFC2068'/>, <xref target='RFC2616'/>), vCard parameters and properties (<xref target='RFC2426'/>), Uniform Resource Names (<xref target='RFC3406'/>), LDAP field names (<xref target='RFC4512'/>), Session Initiation Protocol "P-" headers (<xref target='RFC3427'/>, obsoleted by <xref target='RFC5727'/>), and other technologies.</t>
      <t>Parameters prefaced with the "X-" string are currently used in application protocols for two different purposes:</t>
      <t>
        <list style='symbols'>
          <t>Experiments that might be standardized in the future, if they are successful.<vspace blankLines='1'/></t>
          <t>Extensions that will probably not be standardized because they are intended only for use in implementation-specific applications or on private networks.</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.</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 has become a de facto standard (thus obviating the need for segregation of the name space into "standard" and "non-standard" in the first place).  As one example, we can see this phenomenon at work in <xref target='RFC2068'/> (a similar example 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, as explained in xref target='RFC4288'/>:</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.  However, in this case implementation-specific and private-use parameters can be Uniform Resource Identifiers <xref target='RFC3986'/> (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", "com.example.foo", or "VND.example.com.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.  However, this case 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").<vspace blankLines='1'/></t>
          <t>When parameter names need to be very short (e.g., as in <xref target='RFC5646'/> for language tags).  However, 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 implementation-specific extensions or 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 effectively meaningless.<vspace blankLines='1'/></t>
          <t>Collisions are undesirable. 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".</t>
        </list>
      </t>
      <t>Furthermore, 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 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 <xref target='BCP26'/>).</t>
      <t>Therefore it appears 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.</t>
    </section>

    <section title="Recommendations" anchor="recommendations">
      <t>Based on the foregoing considerations, this document makes the following recommendations:</t>
      <t>
        <list style='numbers'>
          <t>Authors of application protocol specifications are discouraged from imputing special meaning to parameters with the "X-" prefix.<vspace blankLines='1'/></t>
          <t>Authors of application protocol specifications are discouraged from mandating that all parameters without the "X-" prefix need to be registered with the IANA.<vspace blankLines='1'/></t>
          <t>Implementers wishing to experiment with parameters that have the potential to be standardized are encouraged to generate names without the "X-" prefix.<vspace blankLines='1'/></t>
          <t>Implementers wishing to experiment with parameters that are unlikely to be standardized are encouraged to generate meaningless names such as UUIDs or the output of a hash function.<vspace blankLines='1'/></t>
          <t>Implementers wishing to create parameters for use in implementation-specific applications or on private networks are encouraged to mint URIs or generate names that incorporate the relevant organization's name or primary domain name.</t>
        </list>
      </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, Frank Ellermann, 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, John Levine, Bill McQuillan, Alexey Melnikov, Subramanian Moonesamy, Keith Moore, Ben Niven-Jenkins, Mark Nottingham, Dirk Pranke, Randy Presuhn, Julian Reschke, Doug Royer, Andrew Sullivan, Martin Thomson, Nicolas Williams, and Kurt Zeilenga for their feedback.</t>
    </section>

  </middle>

  <back>

    <references title="Informative References">

<reference anchor='BCP9'>
<front>
<title abbrev='Internet Standards Process'>The Internet Standards Process -- Revision 3</title>
<author initials='S.' surname='Bradner' fullname='Scott O. Bradner'>
<organization>Harvard University</organization>
<address>
<postal>
<street>1350 Mass. Ave.</street>
<city>Cambridge</city>
<region>MA</region>
<code>02138</code>
<country>US</country></postal>
<phone>+1 617 495 3864</phone>
<email>sob@harvard.edu</email></address></author>
<date year='1996' month='October' />
<abstract>
<t>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.</t></abstract></front>
<seriesInfo name='BCP' value='9' />
<seriesInfo name='RFC' value='2026' />
<format type='TXT' octets='86731' target='http://www.rfc-editor.org/rfc/rfc2026.txt' />
</reference>

<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='RFC2426'>
<front>
<title>vCard MIME Directory Profile</title>
<author initials='F.' surname='Dawson' fullname='Frank Dawson'>
<organization>Lotus Development Corporation</organization>
<address>
<postal>
<street>6544 Battleford Drive</street>
<street>Raleigh</street>
<street>NC 27613</street>
<country>USA</country></postal>
<phone>+1-919-676-9515</phone>
<email>frank_dawson@lotus.com</email></address></author>
<author initials='T.' surname='Howes' fullname='Tim Howes'>
<organization>Netscape Communications Corp.</organization>
<address>
<postal>
<street>501 East Middlefield Rd.</street>
<street>Mountain View</street>
<street>CA 94041</street>
<country>USA</country></postal>
<phone>+1.415.937.3419</phone>
<email>howes@netscape.com</email></address></author>
<date year='1998' month='September' />
<area>Applications</area>
<keyword>MIME</keyword>
<keyword>audio</keyword>
<keyword>content-type</keyword>
<keyword>directory</keyword>
<keyword>multipurpose internet mail extensions</keyword>
<abstract>
<t>
   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.
</t>
<t>
   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 .
</t></abstract></front>
<seriesInfo name='RFC' value='2426' />
<format type='TXT' octets='74646' target='http://www.rfc-editor.org/rfc/rfc2426.txt' />
<format type='HTML' octets='96516' target='http://xml.resource.org/public/rfc/html/rfc2426.html' />
<format type='XML' octets='77964' target='http://xml.resource.org/public/rfc/xml/rfc2426.xml' />
</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='RFC3986'>
<front>
<title abbrev='URI Generic Syntax'>Uniform Resource Identifier (URI): Generic Syntax</title>
<author initials='T.' surname='Berners-Lee' fullname='Tim Berners-Lee'>
<organization abbrev='W3C/MIT'>World Wide Web Consortium</organization>
<address>
<postal>
<street>Massachusetts Institute of Technology</street>
<street>77 Massachusetts Avenue</street>
<city>Cambridge</city>
<region>MA</region>
<code>02139</code>
<country>USA</country></postal>
<phone>+1-617-253-5702</phone>
<facsimile>+1-617-258-5999</facsimile>
<email>timbl@w3.org</email>
<uri>http://www.w3.org/People/Berners-Lee/</uri></address></author>
<author initials='R.' surname='Fielding' fullname='Roy T. Fielding'>
<organization abbrev='Day Software'>Day Software</organization>
<address>
<postal>
<street>5251 California Ave., Suite 110</street>
<city>Irvine</city>
<region>CA</region>
<code>92617</code>
<country>USA</country></postal>
<phone>+1-949-679-2960</phone>
<facsimile>+1-949-679-2972</facsimile>
<email>fielding@gbiv.com</email>
<uri>http://roy.gbiv.com/</uri></address></author>
<author initials='L.' surname='Masinter' fullname='Larry Masinter'>
<organization abbrev='Adobe Systems'>Adobe Systems Incorporated</organization>
<address>
<postal>
<street>345 Park Ave</street>
<city>San Jose</city>
<region>CA</region>
<code>95110</code>
<country>USA</country></postal>
<phone>+1-408-536-3024</phone>
<email>LMM@acm.org</email>
<uri>http://larry.masinter.net/</uri></address></author>
<date year='2005' month='January' />
<area>Applications</area>
<keyword>uniform resource identifier</keyword>
<keyword>URI</keyword>
<keyword>URL</keyword>
<keyword>URN</keyword>
<keyword>WWW</keyword>
<keyword>resource</keyword>
<abstract>
<t>
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.
</t></abstract></front>
<seriesInfo name='STD' value='66' />
<seriesInfo name='RFC' value='3986' />
<format type='TXT' octets='141811' target='http://www.rfc-editor.org/rfc/rfc3986.txt' />
<format type='HTML' octets='213584' target='http://xml.resource.org/public/rfc/html/rfc3986.html' />
<format type='XML' octets='163534' target='http://xml.resource.org/public/rfc/xml/rfc3986.xml' />
</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='RFC4512'>
<front>
<title>Lightweight Directory Access Protocol (LDAP): Directory Information Models</title>
<author initials='K.' surname='Zeilenga' fullname='K. Zeilenga'>
<organization /></author>
<date year='2006' month='June' />
<abstract>
<t>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]</t></abstract></front>
<seriesInfo name='RFC' value='4512' />
<format type='TXT' octets='108377' target='http://www.rfc-editor.org/rfc/rfc4512.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='RFC5451'>
<front>
<title>Message Header Field for Indicating Message Authentication Status</title>
<author initials='M.' surname='Kucherawy' fullname='M. Kucherawy'>
<organization /></author>
<date year='2009' month='April' />
<abstract>
<t>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]</t></abstract></front>
<seriesInfo name='RFC' value='5451' />
<format type='TXT' octets='97404' target='http://www.rfc-editor.org/rfc/rfc5451.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>