One document matched: draft-saintandre-xmpp-i18n-03.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="info" docName="draft-saintandre-xmpp-i18n-03" ipr="trust200902">
<front>
<title abbrev="XMPP I18N">Internationalized Addresses in XMPP</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 day="14" month="March" year="2011"/>
<keyword>internationalization</keyword>
<keyword>Jabber</keyword>
<keyword>PRECIS</keyword>
<keyword>stringprep</keyword>
<keyword>XMPP</keyword>
<abstract>
<t>The Extensible Messaging and Presence Protocol (XMPP) as defined in RFC 3920 used stringprep in the preparation and comparison of non-ASCII characters within XMPP addresses. This document explores a post-stringprep approach to XMPP addresses.</t>
</abstract>
</front>
<middle>
<section title="Introduction" anchor="intro">
<t>The Extensible Messaging and Presence Protocol <xref target='RFC6120'/> is a widely-deployed technology for real-time communication, commonly used for instant messaging (IM) among human users but also for communication among automated systems. XMPP addresses (also called "JabberIDs" or JIDs) are of the form <localpart@domainpart/resourcepart>, where the localpart and resourcepart are formally optional but quite common because they are used to identify clients and other entities on the network. In some sense, XMPP addresses have always been internationalized, because the developers of the original Jabber open-source project intended that all data sent over the wire would consist of UTF-8 encoded Unicode code points. However, at that time (1999) the Jabber developers were quite unsophisticated about internationalization, nor could they simply re-use a reliable internationalization technology that had been developed by the wider Internet community (as they could, for example, by re-using Secure Sockets Layer and Transport Layer Security for channel encryption); this lack of sophistication is evident in the community's first attempt at formally defining the format for JabberIDs in early 2002 <xref target='XEP-0029'/>.</t>
<t>When the first instantiation of the IETF's XMPP WG was formed in late 2002, IDNA2003 <xref target='RFC3490'/> had not yet been published and stringprep <xref target='RFC3454'/> was a new technology. During its work on <xref target='RFC3920'/>, the XMPP WG absorbed as best it could the advice of internationalization experts regarding appropriate methods for preparing and comparing XMPP addresses; however, the participants in the XMPP WG were ignorant of internationalization and therefore did not necessarily make fully-informed decisions. As a result of this early work, in <xref target='RFC3920'/> the XMPP WG decided to re-use IDNA2003 <xref target='RFC3490'/> and Nameprep <xref target='RFC3491'/> for the domainpart of a JID and to define two additional stringprep profiles: Nodeprep for the localpart and Resourceprep for the resourecepart.</t>
<t>Since the publication of <xref target='RFC3920'/> in 2004, the Internet community has gained more experience with internationalization. In particular, IDNA2003, which is based on stringprep, has been superseded by IDNA2008 (<xref target='RFC5890'/>, <xref target='RFC5891'/>, <xref target='RFC5892'/>, <xref target='RFC5893'/>, <xref target='RFC5894'/>), which does not use stringprep. This migration away from stringprep for internationalized domain names has prompted other "customers" of stringprep to consider new approaches to the preparation and comparison of internationalized addresses. As a result, the IETF has formed the PRECIS WG as a common forum for seeking solutions to the problem statement outlined in <xref target='PROBLEM'/>.</t>
<t>This document has two purposes: (1) provide input to the PRECIS WG and (2) help inform the decisions of the XMPP WG regarding internationalization of XMPP addresses, eventually leading to replacement of <xref target='RFC6122'/>. Note well that so far this document present only the author's opinions, and that it does not reflect the consensus of the XMPP WG or the PRECIS WG.</t>
</section>
<section title="Proposed PRECIS String Classes" anchor="precis-classes">
<t>Both <xref target='PROBLEM'/> and <xref target='FRAMEWORK'/> propose that it might be valuable to think of internationalized addresses in terms of broad "string classes". Application technologies like XMPP could either borrow such a string class unchanged or "profile" such a string class with modifications.</t>
<t>This document does not yet make recommendations about borrowing or adapting more general string classes, in part because those classes are not yet clearly defined. However, as input to further discussion, this document explores four string classes that are used in XMPP:</t>
<t>
<list style='symbols'>
<t>Domain names. These are defined in IDNA specification and re-used in XMPP and other applications. However, additional guidelines might be helpful for applications (or at least for XMPP) to fill the gap between what was provided in IDNA2003 (such as normalization and various mapping steps) and what is now provided in IDNA2008. For consistency with the next three string classes we call these "domaineythings".<vspace blankLines='1'/></t>
<t>Username-like things. Such a "nameything" is a word or set of words that is used to identify or address a network entity such as a user, an account, a venue (e.g., a chatroom), an information source (e.g., a feed), or a collection of data (e.g., a file). An XMPP localpart is a kind of nameything, but might profile a base definition of nameythings developed by the PRECIS WG.<vspace blankLines='1'/></t>
<t>Password-like things. Such a "wordything" is a sequence of letters, numbers, and symbols that is used as a secret for access to some resource on a network (e.g., an account or a venue). In XMPP, wordythings are often used by clients to authenticate with servers, as provided in various SASL mechanisms.<vspace blankLines='1'/></t>
<t>Free-form things. Such a "stringything" is a sequence of letters, numbers, symbols, spaces, and other code points that is used for more expressive purposes in an application protocol. An XMPP resourcepart is a kind of stringything, but might profile a base definition of stringythings developed by the PRECIS WG.</t>
</list>
</t>
<t>The following subsections discuss these string classes in more detail, with reference to the properties described in Section 3 of <xref target='PROBLEM'/> (input restrictions, normalization, case mapping, and bidirectionality).</t>
<section title="Domaineythings" anchor="precis-classes-domaineything">
<t>The IDNA2008 protocol is defined in <xref target='RFC5890'/>, <xref target='RFC5891'/>, <xref target='RFC5892'/>, <xref target='RFC5893'/>, and <xref target='RFC5894'/>. However, IDNA2008 covers a smaller range of topics than IDNA2003 <xref target='RFC3490'/>. In particular, normalization and mappings are out of scope for IDNA2008 (although one possible approach is described informationally in <xref target='RFC5895'/>). The XMPP WG, or even the PRECIS WG, might want to choose a normalization form and a set of mappings that would be recommended or required for use on the wire, despite the fact that these matters were not specified in a normative way for IDNA2008. This is especially important in modern application protocols that communicate using UTF-8-encoded Unicode code points instead of 8-bit or 7-bit ASCII (as in older application protocols such as <xref target='RFC5322'/>).</t>
</section>
<section title="Nameythings" anchor="precis-classes-nameything">
<t>Most application technologies need a special class of strings that can be used to include or communicate things like usernames, chatroom names, file names, and data feed names. We group such things into a bucket called "nameythings". Ideally, the PRECIS WG would define a "nameything" class that could be profiled by various application technologies. We suggest that the base class would have the following features:</t>
<t>
<list style='symbols'>
<t>Control characters (e.g., U+0000 through U+001F) would be disallowed.</t>
<t>Space characters (U+0020, along with any code point having a GeneralCategory of Zs) would be disallowed.</t>
<t>All other 7-bit ASCII characters (i.e., U+0021 through U+007E) would be protocol-valid, even if their Unicode GeneralCategory is disallowed by the rules specified below.</t>
<t>As with IDNA2008, any character that has a compatibility equivalent would be disallowed.</t>
<t>Uppercase and titlecase code points would be mapped to their lowercase equivalents.</t>
<t>The normalization form would be NFD (see below).</t>
<t>Profiles of the base class would be able to exclude specific code points that are included in the base.</t>
<t>Profiles of the base class would be able to exclude character classes with other properties (e.g., math symbols) that are included in the base.</t>
</list>
</t>
<t>OPEN ISSUE: Should symbol characters outside the 7-bit ASCII range be disallowed?</t>
<t>OPEN ISSUE: How to handle right-to-left code points? It might be reasonable to simply use the "Bidi Rule" from <xref target='RFC5893'/>, however "." is allowed in nameythings and the Bidi Rule is probably too complex for our purposes because domaineythings have internal structure (based around the "." character) whereas nameythings do not.</t>
</section>
<section title="Wordythings" anchor="precis-classes-wordything">
<t>Many application technologies need a special class of strings that can be used to communicate secrets that are typically used as passwords or passphrases. We group such things into a bucket called "wordythings". Ideally, the PRECIS WG would define a "wordything" class that could be profiled by various application technologies. We suggest that the base class would have the following features:</t>
<t>
<list style='symbols'>
<t>Control characters (e.g., U+0000 through U+001F) would be disallowed.</t>
<t>Space characters (U+0020, along with any code point having a GeneralCategory of Zs) would be disallowed.</t>
<t>All other 7-bit ASCII characters (i.e., U+0021 through U+007E) would be protocol-valid, even if their Unicode GeneralCategory is disallowed by the rules specified below.</t>
<t>Any character that has a compatibility equivalent would be disallowed.</t>
<t>In order to maximize the entropy of passwords and passphrases, uppercase and titlecase code points would be protocol-valid and would not be mapped to their lowercase equivalents.</t>
<t>The normalization form would be NFD (see below).</t>
<t>Profiles of the base class would be able to exclude specific code points that are included in the base.</t>
<t>Profiles of the base class would be able to exclude character classes with other properties (e.g., math symbols) that are included in the base.</t>
</list>
</t>
<t>Although some application protocols use passwords and passphrases directly, others re-use technologies that themselves use passwords in some deployments (e.g., this is true of XMPP, which re-uses Simple Authentication and Security Layer or SASL <xref target='RFC4422'/>).</t>
</section>
<section title="Stringythings" anchor="precis-classes-stringything">
<t>Some application technologies need a special class of strings that can be used in a free-form way. We group such things into a bucket called "stringythings". Ideally, the PRECIS WG would define a "stringything" class that could be profiled by various application technologies. We suggest that the base class would have the following features:</t>
<t>
<list style='symbols'>
<t>Control characters (e.g., U+0000 through U+001F) would be disallowed.</t>
<t>Space characters (U+0020, along with any code point having a GeneralCategory of Zs) would be protocol-valid.</t>
<t>All other 7-bit ASCII characters (i.e., U+0021 through U+007E) would be protocol-valid, even if their Unicode GeneralCategory is disallowed by the rules specified below.</t>
<t>Characters with compatibility equivalents would be protocol-valid.</t>
<t>Uppercase and titlecase code points would protocol-valid and would not be mapped to their lowercase equivalents.</t>
<t>The normalization form would be NFD (see below).</t>
<t>Profiles of the base class would be able to exclude specific code points that are included in the base.</t>
<t>Profiles of the base class would be able to exclude character classes with other properties (e.g., math symbols) that are included in the base.</t>
</list>
</t>
<t>OPEN ISSUE: How to handle right-to-left code points? It might be reasonable to simply use the "Bidi Rule" from <xref target='RFC5893'/>, however "." is allowed in stringythings and the Bidi Rule is probably too complex for our purposes because domaineythings have internal structure (based around the "." character) whereas stringythings do not.</t>
</section>
</section>
<section title="Normalization" anchor="normalization">
<t>Following IDNA2003, existing stringprep profiles all use Unicode Normalization Form KC (NFKC), which performs canonical decomposition and compatibility decomposition, followed by canonical and compatibility recomposition (regarding normalization forms, see <xref target='UAX15'/>). This choice made sense in IDNA2003 because the DNS packet format has fixed-length labels, and NFKC in effect compresses a sequence of characters into the smallest number of bytes possible by performing recomposition. However, experience with some of the application protocols that are currently using NFKC has shown that recomposition is an expensive operation to perform in application servers. In addition, the application protocols that use stringprep all use TCP with security-layer or application-layer compression, so fixing the length of strings is much less important.</t>
<t>What matters most in application protocols is ensuring that network entities (such as clients and servers) all communicate a consistent string representation over the wire. For this purpose, Normalization Form D (NFD), which simply performs canonical decomposition, provides the most efficient approach. As noted above, we can disallow any characters that would require compatibility decomposition, thus removing the need for compatibility decomposition and recomposition. This is what happened in IDNA2008, enabling IDNA technologies to move from NFKC to NFC. If the same basic approach is taken in the PRECIS WG, while at the same time removing the need for recomposition entirely (by making code points with compatibility equivalents), NFKC (the most complex and therefore most computationally intensive normalization form) can be replaced with NFD (the least complex and therefore least computationally intensive normalization form). Another relevant factor is that NFD(x) = NFD(NFD(x)), which means that application servers can be optimized for the case where the normalization has already occurred. In general, using NFD will likely result in significant performance improvements within application servers.</t>
</section>
<section title="Subclassing" anchor="subclassing">
<t>The opportunity for subclassing PRECIS string classes opens the possibility that different applications technologies will subclass a given class in different ways. For example, imagine that the XMPP community defines a detailed subclass of "nameything" that is optimized for the comparison of JabberIDs. However, the email community might do the same for email addresses. At that point, the XMPP comparison methods might diverge significantly from the mail comparison methods, leading to interoperability problems if a given deployment makes use of the same usernames for both JabberIDs and email addresses. The PRECIS WG needs to consider these matters and find a productive balance between compatibility within an application technology and interoperability across application technologies.</t>
</section>
<section title="XMPP Use of PRECIS String Classes" anchor="xmpp-profiles">
<section title="Localpart" anchor="xmpp-profiles-localpart">
<t>The localpart of an XMPP address would be redefined as a profile or subclass of the PRECIS "nameything" class. The following additional restrictions would apply:</t>
<t>
<list style='symbols'>
<t>Space characters (U+0020, along with any code point having a GeneralCategory of Zs) would be disallowed.</t>
<t>The following Unicode code points would be disallowed: U+0022 ("), U+0026 (&), U+0027 ('), U+002F (/), U+003A (:), U+003C (<), U+003E (>), U+0040 (@).</t>
</list>
</t>
<t>OPEN ISSUE: Should symbol characters outside the 7-bit ASCII range be disallowed?</t>
</section>
<section title="Resourcepart" anchor="xmpp-profiles-resourcepart">
<t>The resourcepart of an XMPP address would be redefined as a profile or subclass of the PRECIS "stringything" class, or might even simply use the identity subclass of "stringything".</t>
</section>
</section>
<section title="XMPP Migration Issues" anchor="migration">
<t>Any move away from Nameprep, Nodeprep, and Resourceprep as they are defined today will inevitably introduce the potential for migration issues, such as JIDs that were not ambiguous before the migration but that become ambiguous after the migration. These issues need to be clearly defined and well understood so that the costs and benefits of any change can be properly assessed -- especially if the change might have an impact on authentication (e.g., as described in <xref target='RFC3920'/>), authorization (e.g., presence subscriptions as described in <xref target='RFC6121'/>), access (e.g., joining a chatroom as described in <xref target='XEP-0045'/>), identification (e.g., in XMPP URIs or IRIs as described in <xref target='RFC5122'/>), and other security-related functions.</t>
</section>
<section title="XMPP Protocol Slots" anchor="slots">
<t>IDNA2008 defined the concept of a "domain name slot", i.e., "a protocol element or a function argument or a return value (and so on) explicitly designated for carrying a domain name" (Section 2.3.2.6 of <xref target='RFC5890'/>). Similarly, the XMPP community can define the concepts of a "JID slot", a "localpart slot", and a "resourcepart slot" (and might re-use the concepts of a "nameything slot", "wordything slot", and "stringything slot" from PRECIS specifications). The community has yet to determine the full inventory of such slots. However, the following subsections provide a start at such an inventory.</t>
<section title="JID Slot" anchor="slots-jid">
<t>In XMPP systems, JabberIDs can appear in at least the following slots:</t>
<t>
<list style='symbols'>
<t>Core <xref target='RFC6120'/>: the 'from' and 'to' stream attributes; the 'from' and 'to' stanza attributes.</t>
<t>IM <xref target='RFC6121'/>: the 'jid' attribute of the roster <item/> element.</t>
<t>Privacy Lists <xref target='RFC3921'/>, <xref target='XEP-0016'/>: the 'value' attribute of the <item/> element when the value of the 'type' attribute is "jid".</t>
<t>Data Forms <xref target='XEP-0004'/>: the <value/> element when the 'type' attribute is "jid-single" or "jid-multi".</t>
<t>Flexible Offline Message Retrieval <xref target='XEP-0013'/>: the 'jid' attribute of the <x/> element.</t>
<t>Service Discovery <xref target='XEP-0030'/>: the 'jid' attribute of the <item/> element.</t>
<t>Extended Stanza Addressing <xref target='XEP-0033'/>: the 'jid' attribute of the <address/> element.</t>
<t>Multi-User Chat <xref target='XEP-0045'/>: the 'actor' child of the <item/> element; the 'jid' attribute of the <item/> element; the 'from' and 'to' attributes of the <invite/> and <decline/> elements; the 'jid' attribute of the <destroy/> element.</t>
<t>Bookmarks <xref target='XEP-0048'/>: the 'jid' attribute of the <conference/> element.</t>
<t>vCards <xref target='XEP-0054'/>: the <JABBERID/> of the <vCard/> element.</t>
<t>Jabber Search <xref target='XEP-0055'/>: the 'jid' attribute of the <item/> element.</t>
<t>Publish-Subscribe <xref target='XEP-0060'/>: the 'jid' attribute of the <affiliation/>, <options/>, <subscribe>, <subscription/>, and <unsubscribe/> elements; the 'publisher' attribute of the <item/> element.</t>
<t>SOCKS5 Bytestreams <xref target='XEP-0065'/>: the 'jid' attribute of the <streamhost/> and <streamhost-used/> elements.</t>
<t>Advanced Message Processing <xref target='XEP-0079'/>: the 'from' and 'to' attributes of the <amp/> element.</t>
<t>Jabber Component Protocol <xref target='XEP-0114'/>: the 'from' and 'to' attributes of the <iq/>, <message/>, and <presence/> elements.</t>
<t>Message Archiving <xref target='XEP-0136'/>: the 'with' attribute of the <chat/>, <from/>, and <item/> elements.</t>
<t>Roster Item Exchange <xref target='XEP-0144'/>: the 'jid' attribute of the <item/> element.</t>
<t>Jingle <xref target='XEP-0166'/>: the 'initiator' and 'responder' attributes of the <jingle/> element.</t>
<t>Delayed Delivery <xref target='XEP-0203'/>: the 'from' attribute of the <delay/> element.</t>
<t>Simple Communications Blocking <xref target='XEP-0191'/>: the 'jid' attribute of the <item/> element.</t>
<t>Server Dialback <xref target='RFC3921'/>, <xref target='XEP-0220'/>: the 'from' and 'to' attributes of the <result/> and <verify/> elements.</t>
<t>Direct MUC Invitations <xref target='XEP-0249'/>: the 'jid' attribute of the <x/> element.</t>
</list>
</t>
</section>
<section title="Localpart Slot" anchor="slots-localpart">
<t>In XMPP systems, localparts can appear in at least the following slots:</t>
<t>
<list style='symbols'>
<t>Multi-User Chat <xref target='XEP-0045'/>: the <unique/> element.</t>
<t>In-Band Registration <xref target='XEP-0077'/>: the <username/> element.</t>
</list>
</t>
</section>
<section title="Resourcepart Slot" anchor="slots-resourcepart">
<t>In XMPP systems, resourceparts can appear in at least the following slots:</t>
<t>
<list style='symbols'>
<t>Core <xref target='RFC6120'/>: the <resource/> child of the <bind/> element.</t>
<t>Multi-User Chat <xref target='XEP-0045'/>: the 'nick' attribute of the <item/> element.</t>
<t>Bookmarks <xref target='XEP-0048'/>: the 'nick' attribute of the <conference/> element.</t>
<t>Jabber Search <xref target='XEP-0055'/>: the 'nick' attribute of the <item/> and <query/> elements.</t>
<t>Publish-Subscribe <xref target='XEP-0060'/>: the 'node' attribute of the <address/> element (this might actually be a "stringything slot" but typically it is handled as a resourcepart).</t>
</list>
</t>
</section>
<section title="Wordything Slot" anchor="slots-wordything">
<t>In XMPP systems, generic "wordythings" can appear in at least the following slots:</t>
<t>
<list style='symbols'>
<t>Multi-User Chat <xref target='XEP-0045'/>: the <password/> child of the <destroy/> and <x/> elements.</t>
<t>Bookmarks <xref target='XEP-0048'/>: the 'password' attribute of the <conference/> element.</t>
<t>Direct MUC Invitations <xref target='XEP-0249'/>: the 'password' attribute of the <x/> element.</t>
</list>
</t>
</section>
<section title="Stringything Slot" anchor="slots-stringything">
<t>In XMPP systems, generic "stringythings" can appear in at least the following slots:</t>
<t>
<list style='symbols'>
<t>Flexible Offline Message Retrieval <xref target='XEP-0013'/>: the 'node' attribute of the <x/> element.</t>
<t>Extended Stanza Addressing <xref target='XEP-0033'/>: the 'node' attribute of the <address/> element.</t>
<t>Publish-Subscribe <xref target='XEP-0060'/>: the 'node' attribute of various XML elements.</t>
</list>
</t>
</section>
</section>
<section title="XMPP Error Handling" anchor="errors">
<t>Both the core XMPP specifications and various XMPP extensions might need to define more robust error handling. Although this topic has yet to be explored in detail, it is likely that specifications can more widely use the existing <jid-malformed/> error condition defined in <xref target='RFC6120'/>.</t>
</section>
<section title="XMPP User Interface Issues" anchor="ui">
<t><xref target='RFC5895'/> introduces the helpful concept of "the dividing line between user interface and protocol" and applies that concept to the complexs process of translating the user's (presumed) intentions into bits on the wire. IDNA2003 conflated user interface processing and machine-readable protocols, and in many ways XMPP inherited that same error. It would be desirable for XMPP technologies to define a clear dividing line between user interface and protocol. This might mean that the XMPP community will need to define recommended mappings that are applied to a string before it is considered a JID (or the localpart of resourcepart of a JID).</t>
</section>
<section title="Security Considerations" anchor="security">
<t>The inclusion of non-ASCII characters in XMPP addresses has important security implications, such as the ability to mimic characters or entire addresses through the inclusion of "confusable characters" (see <xref target='RFC4690'/> and <xref target='RFC5890'/>). These issues are explored at some length in <xref target='RFC6122'/>. Other security considerations might apply and will be described in a future version of this specification.</t>
</section>
<section title="IANA Considerations" anchor="iana">
<t>This document defines no actions for the IANA.</t>
</section>
<section title="Acknowledgements" anchor="acks">
<t>Special thanks to Joe Hildebrand for extensive discussions about internationalization and XMPP. Many participants in the XMPP WG Interim Meeting in February 2011 provided valuable feedback. Thanks also to Jack Erwin, Matt Miller, and Tory Patnoe for additional discussions.</t>
</section>
</middle>
<back>
<references title="Informative References">
<reference anchor='FRAMEWORK'>
<front>
<title>Precis Framework: Handling Internationalized Strings in Protocols</title>
<author initials='M' surname='Blanchet' fullname='Marc Blanchet'>
<organization />
</author>
<date month='July' day='5' year='2010' />
<abstract><t>Using Unicode codepoints in protocol strings requires preparation of the string. This document describes the Precis Protocol Framework that prepares various classes of strings used in protocol elements. A protocol specification chooses a class of strings and then implements the corresponding preparation steps described in this document. This document is based on the IDNAbis approach. It obsoletes the Stringprep algorithm.</t></abstract>
</front>
<seriesInfo name='Internet-Draft' value='draft-blanchet-precis-framework-00' />
<format type='TXT'
target='http://www.ietf.org/internet-drafts/draft-blanchet-precis-framework-00.txt' />
</reference>
<reference anchor='PROBLEM'>
<front>
<title>Stringprep Revision Problem Statement</title>
<author initials='M' surname='Blanchet' fullname='Marc Blanchet'>
<organization />
</author>
<author initials='A' surname='Sullivan' fullname='Andrew Sullivan'>
<organization />
</author>
<date month='December' day='9' year='2010' />
<abstract><t>Using Unicode codepoints in protocol strings that expect comparison with other strings requires preparation of the string that contains the Unicode codepoints. Internationalizing Domain Names in Applications (IDNA2003) defined and used Stringprep and Nameprep. Other protocols subsequently defined Stringprep profiles. A new approach different from Stringprep and Nameprep is used for a revision of IDNA2003 (called IDNA2008). Other Stringprep profiles need to be similarly updated or a replacement of Stringprep needs to be designed. This document outlines the issues to be faced by those designing a Stringprep replacement.</t></abstract>
</front>
<seriesInfo name='Internet-Draft' value='draft-ietf-precis-problem-statement-01' />
<format type='TXT'
target='http://www.ietf.org/internet-drafts/draft-ietf-precis-problem-statement-01.txt' />
</reference>
<reference anchor="RFC3454">
<front>
<title>Preparation of Internationalized Strings ("stringprep")</title>
<author initials='P.' surname='Hoffman' fullname='P. Hoffman'>
<organization /></author>
<author initials='M.' surname='Blanchet' fullname='M. Blanchet'>
<organization /></author>
<date month='December' year='2002' /></front>
<seriesInfo name='RFC' value='3454' />
<format type='TXT' octets='138684' target='ftp://ftp.isi.edu/in-notes/rfc3454.txt' />
</reference>
<reference anchor='RFC3490'>
<front>
<title>Internationalizing Domain Names in Applications (IDNA)</title>
<author initials='P.' surname='Faltstrom' fullname='P. Faltstrom'>
<organization /></author>
<author initials='P.' surname='Hoffman' fullname='P. Hoffman'>
<organization /></author>
<author initials='A.' surname='Costello' fullname='A. Costello'>
<organization /></author>
<date month='March' year='2003' /></front>
<seriesInfo name='RFC' value='3490' />
<format type='TXT' octets='51943' target='ftp://ftp.isi.edu/in-notes/rfc3490.txt' />
</reference>
<reference anchor="RFC3491">
<front>
<title>Nameprep: A Stringprep Profile for Internationalized Domain Names (IDN)</title>
<author initials='P.' surname='Hoffman' fullname='P. Hoffman'>
<organization /></author>
<author initials='M.' surname='Blanchet' fullname='M. Blanchet'>
<organization /></author>
<date month='March' year='2003' /></front>
<seriesInfo name='RFC' value='3491' />
<format type='TXT' octets='10316' target='ftp://ftp.isi.edu/in-notes/rfc3491.txt' />
</reference>
<reference anchor='RFC3920'>
<front>
<title abbrev='XMPP Core'>Extensible Messaging and Presence Protocol (XMPP): Core</title>
<author initials='P.' surname='Saint-Andre' fullname='Peter Saint-Andre' role='editor'>
<organization>Jabber Software Foundation</organization>
<address>
<email>stpeter@jabber.org</email></address></author>
<date year='2004' month='October' />
<area>Applications</area>
<workgroup>XMPP Working Group</workgroup>
<keyword>RFC</keyword>
<keyword>Request for Comments</keyword>
<keyword>I-D</keyword>
<keyword>Internet-Draft</keyword>
<keyword>XMPP</keyword>
<keyword>Extensible Messaging and Presence Protocol</keyword>
<keyword>Jabber</keyword>
<keyword>IM</keyword>
<keyword>Instant Messaging</keyword>
<keyword>Presence</keyword>
<keyword>XML</keyword>
<keyword>Extensible Markup Language</keyword>
<abstract>
<t>This memo defines the core features of the Extensible Messaging and Presence Protocol (XMPP), a protocol for streaming Extensible Markup Language (XML) elements in order to exchange structured information in close to real time between any two network endpoints. While XMPP provides a generalized, extensible framework for exchanging XML data, it is used mainly for the purpose of building instant messaging and presence applications that meet the requirements of RFC 2779.</t></abstract></front>
<seriesInfo name='RFC' value='3920' />
<format type='TXT' octets='194313' target='ftp://ftp.isi.edu/in-notes/rfc3920.txt' />
<format type='HTML' octets='237435' target='http://xml.resource.org/public/rfc/html/rfc3920.html' />
<format type='XML' octets='234474' target='http://xml.resource.org/public/rfc/xml/rfc3920.xml' />
</reference>
<reference anchor='RFC3921'>
<front>
<title abbrev='XMPP IM'>Extensible Messaging and Presence Protocol (XMPP): Instant Messaging and Presence</title>
<author initials='P.' surname='Saint-Andre' fullname='Peter Saint-Andre' role='editor'>
<organization>Jabber Software Foundation</organization>
<address>
<email>stpeter@jabber.org</email></address></author>
<date year='2004' month='October' />
<area>Applications</area>
<workgroup>XMPP Working Group</workgroup>
<keyword>RFC</keyword>
<keyword>Request for Comments</keyword>
<keyword>I-D</keyword>
<keyword>Internet-Draft</keyword>
<keyword>XMPP</keyword>
<keyword>Extensible Messaging and Presence Protocol</keyword>
<keyword>Jabber</keyword>
<keyword>IM</keyword>
<keyword>Instant Messaging</keyword>
<keyword>Presence</keyword>
<keyword>XML</keyword>
<keyword>Extensible Markup Language</keyword>
<abstract>
<t>This memo describes extensions to and applications of the core features of the Extensible Messaging and Presence Protocol (XMPP) that provide the basic instant messaging (IM) and presence functionality defined in RFC 2779.</t></abstract></front>
<seriesInfo name='RFC' value='3921' />
<format type='TXT' octets='217527' target='http://www.rfc-editor.org/rfc/rfc3921.txt' />
<format type='HTML' octets='274538' target='http://xml.resource.org/public/rfc/html/rfc3921.html' />
<format type='XML' octets='234468' target='http://xml.resource.org/public/rfc/xml/rfc3921.xml' />
</reference>
<reference anchor='RFC4422'>
<front>
<title>Simple Authentication and Security Layer (SASL)</title>
<author initials='A.' surname='Melnikov' fullname='A. Melnikov'>
<organization /></author>
<author initials='K.' surname='Zeilenga' fullname='K. Zeilenga'>
<organization /></author>
<date year='2006' month='June' />
<abstract>
<t>The Simple Authentication and Security Layer (SASL) is a framework for providing authentication and data security services in connection-oriented protocols via replaceable mechanisms. It provides a structured interface between protocols and mechanisms. The resulting framework allows new protocols to reuse existing mechanisms and allows old protocols to make use of new mechanisms. The framework also provides a protocol for securing subsequent protocol exchanges within a data security layer.</t><t> This document describes how a SASL mechanism is structured, describes how protocols include support for SASL, and defines the protocol for carrying a data security layer over a connection. In addition, this document defines one SASL mechanism, the EXTERNAL mechanism.</t><t> This document obsoletes RFC 2222. [STANDARDS-TRACK]</t></abstract></front>
<seriesInfo name='RFC' value='4422' />
<format type='TXT' octets='73206' target='http://www.rfc-editor.org/rfc/rfc4422.txt' />
</reference>
<reference anchor='RFC4690'>
<front>
<title>Review and Recommendations for Internationalized Domain Names (IDNs)</title>
<author initials='J.' surname='Klensin' fullname='J. Klensin'>
<organization /></author>
<author initials='P.' surname='Faltstrom' fullname='P. Faltstrom'>
<organization /></author>
<author initials='C.' surname='Karp' fullname='C. Karp'>
<organization /></author>
<author>
<organization>IAB</organization></author>
<date year='2006' month='September' />
<abstract>
<t>This note describes issues raised by the deployment and use of Internationalized Domain Names. It describes problems both at the time of registration and for use of those names in the DNS. It recommends that IETF should update the RFCs relating to IDNs and a framework to be followed in doing so, as well as summarizing and identifying some work that is required outside the IETF. In particular, it proposes that some changes be investigated for the Internationalizing Domain Names in Applications (IDNA) standard and its supporting tables, based on experience gained since those standards were completed. This memo provides information for the Internet community.</t></abstract></front>
<seriesInfo name='RFC' value='4690' />
<format type='TXT' octets='100929' target='ftp://ftp.isi.edu/in-notes/rfc4690.txt' />
</reference>
<reference anchor='RFC5122'>
<front>
<title>Internationalized Resource Identifiers (IRIs) and Uniform Resource Identifiers (URIs) for the Extensible Messaging and Presence Protocol (XMPP)</title>
<author initials='P.' surname='Saint-Andre' fullname='P. Saint-Andre'>
<organization /></author>
<date year='2008' month='February' />
<abstract>
<t>This document defines the use of Internationalized Resource Identifiers (IRIs) and Uniform Resource Identifiers (URIs) in identifying or interacting with entities that can communicate via the Extensible Messaging and Presence Protocol (XMPP). [STANDARDS TRACK]</t></abstract></front>
<seriesInfo name='RFC' value='5122' />
<format type='TXT' octets='55566' target='ftp://ftp.isi.edu/in-notes/rfc5122.txt' />
</reference>
<reference anchor='RFC5322'>
<front>
<title>Internet Message Format</title>
<author initials='P.' surname='Resnick' fullname='Peter W.
Resnick' role='editor'>
<organization>Qualcomm Incorporated</organization>
<address>
<postal>
<street>5775 Morehouse Drive</street>
<city>San Diego</city>
<region>CA</region>
<code>92121-1714</code>
<country>US</country></postal>
<phone>+1 858 651 4478</phone>
<email>presnick@qualcomm.com</email>
<uri>http://www.qualcomm.com/~presnick/</uri></address></author>
<date year='2008' month='October' />
<abstract>
<t>This document specifies the Internet
Message Format (IMF), a syntax for text messages
that are sent between computer users, within
the framework of "electronic mail"
messages. This specification is a revision of
Request For Comments (RFC) 2822, which
itself superseded Request For Comments (RFC)
822, "Standard for the Format of ARPA
Internet Text Messages", updating it to
reflect current practice and incorporating
incremental changes that were specified in
other RFCs.</t></abstract></front>
<seriesInfo name='RFC' value='5322' />
<format type='TXT' octets='122322' target='http://www.rfc-editor.org/rfc/rfc5322.txt' />
<format type='HTML' octets='213342' target='http://xml.resource.org/public/rfc/html/rfc5322.html' />
<format type='XML' octets='174183' target='http://xml.resource.org/public/rfc/xml/rfc5322.xml' />
</reference>
<reference anchor='RFC5890'>
<front>
<title>Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework</title>
<author initials='J.' surname='Klensin' fullname='J. Klensin'>
<organization /></author>
<date year='2010' month='August' />
<abstract>
<t>This document is one of a collection that, together, describe the protocol and usage context for a revision of Internationalized Domain Names for Applications (IDNA), superseding the earlier version. It describes the document collection and provides definitions and other material that are common to the set. [STANDARDS TRACK]</t></abstract></front>
<seriesInfo name='RFC' value='5890' />
<format type='TXT' octets='54245' target='http://www.rfc-editor.org/rfc/rfc5890.txt' />
</reference>
<reference anchor='RFC5891'>
<front>
<title>Internationalized Domain Names in Applications (IDNA): Protocol</title>
<author initials='J.' surname='Klensin' fullname='J. Klensin'>
<organization /></author>
<date year='2010' month='August' />
<abstract>
<t>This document is the revised protocol definition for Internationalized Domain Names (IDNs). The rationale for changes, the relationship to the older specification, and important terminology are provided in other documents. This document specifies the protocol mechanism, called Internationalized Domain Names in Applications (IDNA), for registering and looking up IDNs in a way that does not require changes to the DNS itself. IDNA is only meant for processing domain names, not free text. [STANDARDS TRACK]</t></abstract></front>
<seriesInfo name='RFC' value='5891' />
<format type='TXT' octets='38105' target='http://www.rfc-editor.org/rfc/rfc5891.txt' />
</reference>
<reference anchor='RFC5892'>
<front>
<title>The Unicode Code Points and Internationalized Domain Names for Applications (IDNA)</title>
<author initials='P.' surname='Faltstrom' fullname='P. Faltstrom'>
<organization /></author>
<date year='2010' month='August' />
<abstract>
<t>This document specifies rules for deciding whether a code point, considered in isolation or in context, is a candidate for inclusion in an Internationalized Domain Name (IDN).</t><t> It is part of the specification of Internationalizing Domain Names in Applications 2008 (IDNA2008). [STANDARDS TRACK]</t></abstract></front>
<seriesInfo name='RFC' value='5892' />
<format type='TXT' octets='187370' target='http://www.rfc-editor.org/rfc/rfc5892.txt' />
</reference>
<reference anchor='RFC5893'>
<front>
<title>Right-to-Left Scripts for Internationalized Domain Names for Applications (IDNA)</title>
<author initials='H.' surname='Alvestrand' fullname='H. Alvestrand'>
<organization /></author>
<author initials='C.' surname='Karp' fullname='C. Karp'>
<organization /></author>
<date year='2010' month='August' />
<abstract>
<t>The use of right-to-left scripts in Internationalized Domain Names (IDNs) has presented several challenges. This memo provides a new Bidi rule for Internationalized Domain Names for Applications (IDNA) labels, based on the encountered problems with some scripts and some shortcomings in the 2003 IDNA Bidi criterion. [STANDARDS TRACK]</t></abstract></front>
<seriesInfo name='RFC' value='5893' />
<format type='TXT' octets='38870' target='http://www.rfc-editor.org/rfc/rfc5893.txt' />
</reference>
<reference anchor='RFC5894'>
<front>
<title>Internationalized Domain Names for Applications (IDNA): Background, Explanation, and Rationale</title>
<author initials='J.' surname='Klensin' fullname='J. Klensin'>
<organization /></author>
<date year='2010' month='August' />
<abstract>
<t>Several years have passed since the original protocol for Internationalized Domain Names (IDNs) was completed and deployed. During that time, a number of issues have arisen, including the need to update the system to deal with newer versions of Unicode. Some of these issues require tuning of the existing protocols and the tables on which they depend. This document provides an overview of a revised system and provides explanatory material for its components. This document is not an Internet Standards Track specification; it is published for informational purposes.</t></abstract></front>
<seriesInfo name='RFC' value='5894' />
<format type='TXT' octets='115174' target='http://www.rfc-editor.org/rfc/rfc5894.txt' />
</reference>
<reference anchor='RFC5895'>
<front>
<title>Mapping Characters for Internationalized Domain Names in Applications (IDNA) 2008</title>
<author initials='P.' surname='Resnick' fullname='P. Resnick'>
<organization /></author>
<author initials='P.' surname='Hoffman' fullname='P. Hoffman'>
<organization /></author>
<date year='2010' month='September' />
<abstract>
<t>In the original version of the Internationalized Domain Names in Applications (IDNA) protocol, any Unicode code points taken from user input were mapped into a set of Unicode code points that "made sense", and then encoded and passed to the domain name system (DNS). The IDNA2008 protocol (described in RFCs 5890, 5891, 5892, and 5893) presumes that the input to the protocol comes from a set of "permitted" code points, which it then encodes and passes to the DNS, but does not specify what to do with the result of user input. This document describes the actions that can be taken by an implementation between receiving user input and passing permitted code points to the new IDNA protocol. This document is not an Internet Standards Track specification; it is published for informational purposes.</t></abstract></front>
<seriesInfo name='RFC' value='5895' />
<format type='TXT' octets='16556' target='http://www.rfc-editor.org/rfc/rfc5895.txt' />
</reference>
<reference anchor="RFC6120">
<front>
<title>Extensible Messaging and Presence Protocol (XMPP): Core</title>
<author initials='P' surname='Saint-Andre' fullname='Peter Saint-Andre'>
<organization />
</author>
<date month='December' day='20' year='2010' />
<abstract><t>The Extensible Messaging and Presence Protocol (XMPP) is an application profile of the Extensible Markup Language (XML) that enables the near-real-time exchange of structured yet extensible data between any two or more network entities. This document defines XMPP's core protocol methods: setup and teardown of XML streams, channel encryption, authentication, error handling, and communication primitives for messaging, network availability ("presence"), and request-response interactions. This document obsoletes RFC 3920.</t></abstract>
</front>
<seriesInfo name='Internet-Draft' value='draft-ietf-xmpp-3920bis-22' />
<format type='TXT'
target='http://www.ietf.org/internet-drafts/draft-ietf-xmpp-3920bis-22.txt' />
</reference>
<reference anchor="RFC6121">
<front>
<title>Extensible Messaging and Presence Protocol (XMPP): Instant Messaging and Presence</title>
<author initials='P' surname='Saint-Andre' fullname='Peter Saint-Andre'>
<organization />
</author>
<date month='January' day='20' year='2011' />
<abstract><t>This document defines extensions to core features of the Extensible Messaging and Presence Protocol (XMPP) that provide basic instant messaging (IM) and presence functionality in conformance with the requirements in RFC 2779. This document obsoletes RFC 3921.</t></abstract>
</front>
<seriesInfo name='Internet-Draft' value='draft-ietf-xmpp-3921bis-20' />
<format type='TXT'
target='http://www.ietf.org/internet-drafts/draft-ietf-xmpp-3921bis-20.txt' />
</reference>
<reference anchor="RFC6122">
<front>
<title>Extensible Messaging and Presence Protocol (XMPP): Address Format</title>
<author initials='P' surname='Saint-Andre' fullname='Peter Saint-Andre'>
<organization />
</author>
<date month='January' day='6' year='2011' />
<abstract><t>This document defines the format for addresses used in the Extensible Messaging and Presence Protocol (XMPP), including support for non- ASCII characters. This document updates RFC 3920.</t></abstract>
</front>
<seriesInfo name='Internet-Draft' value='draft-ietf-xmpp-address-09' />
<format type='TXT'
target='http://www.ietf.org/internet-drafts/draft-ietf-xmpp-address-09.txt' />
</reference>
<reference anchor="UAX15">
<front>
<title>Unicode Standard Annex #15: Unicode Normalization Forms</title>
<author>
<organization>The Unicode Consortium</organization>
</author>
<date month="September" year="2010" />
</front>
</reference>
<reference anchor="XEP-0004">
<front>
<title>Data Forms</title>
<author initials="R." surname="Eatmon" fullname="Ryan Eatmon">
<organization/>
<address>
<email>reatmon@jabber.org</email>
</address>
</author>
<author initials="J." surname="Hildebrand" fullname="Joe Hildebrand">
<organization/>
<address>
<email>jhildebr@cisco.com</email>
</address>
</author>
<author initials="J." surname="Miller" fullname="Jeremie Miller">
<organization/>
<address>
<email>jer@jabber.org</email>
</address>
</author>
<author initials="T." surname="Muldowney" fullname="Thomas Muldowney">
<organization/>
<address>
<email>temas@jabber.org</email>
</address>
</author>
<author initials="P." surname="Saint-Andre" fullname="Peter Saint-Andre">
<organization/>
<address>
<email>stpeter@jabber.org</email>
</address>
</author>
<date day="13" month="August" year="2007"/>
</front>
<seriesInfo name="XSF XEP" value="0004"/>
<format type="HTML" target="http://xmpp.org/extensions/xep-0004.html"/>
</reference>
<reference anchor="XEP-0013">
<front>
<title>Flexible Offline Message Retrieval</title>
<author initials="P." surname="Saint-Andre" fullname="Peter Saint-Andre">
<organization/>
<address>
<email>stpeter@jabber.org</email>
</address>
</author>
<author initials="C." surname="Kaes" fullname="Craig Kaes">
<organization/>
<address>
<email>ckaes@jabber.com</email>
</address>
</author>
<date day="14" month="July" year="2005"/>
</front>
<seriesInfo name="XSF XEP" value="0013"/>
<format type="HTML" target="http://xmpp.org/extensions/xep-0013.html"/>
</reference>
<reference anchor="XEP-0016">
<front>
<title>Privacy Lists</title>
<author initials="P." surname="Millard" fullname="Peter Millard">
<organization/>
<address>
<email/>
</address>
</author>
<author initials="P." surname="Saint-Andre" fullname="Peter Saint-Andre">
<organization/>
<address>
<email>stpeter@jabber.org</email>
</address>
</author>
<date day="15" month="February" year="2007"/>
</front>
<seriesInfo name="XSF XEP" value="0016"/>
<format type="HTML" target="http://xmpp.org/extensions/xep-0016.html"/>
</reference>
<reference anchor="XEP-0029">
<front>
<title>Definition of Jabber Identifiers (JIDs)</title>
<author initials="C." surname="Kaes" fullname="Craig Kaes">
<organization/>
<address>
<email>craigk@jabber.com</email>
</address>
</author>
<date day="03" month="October" year="2003"/>
</front>
<seriesInfo name="XSF XEP" value="0029"/>
<format type="HTML" target="http://xmpp.org/extensions/xep-0029.html"/>
</reference>
<reference anchor="XEP-0030">
<front>
<title>Service Discovery</title>
<author initials="J." surname="Hildebrand" fullname="Joe Hildebrand">
<organization/>
<address>
<email>jhildebr@cisco.com</email>
</address>
</author>
<author initials="P." surname="Millard" fullname="Peter Millard">
<organization/>
<address>
<email/>
</address>
</author>
<author initials="R." surname="Eatmon" fullname="Ryan Eatmon">
<organization/>
<address>
<email>reatmon@jabber.org</email>
</address>
</author>
<author initials="P." surname="Saint-Andre" fullname="Peter Saint-Andre">
<organization/>
<address>
<email>stpeter@jabber.org</email>
</address>
</author>
<date day="06" month="June" year="2008"/>
</front>
<seriesInfo name="XSF XEP" value="0030"/>
<format type="HTML" target="http://xmpp.org/extensions/xep-0030.html"/>
</reference>
<reference anchor="XEP-0033">
<front>
<title>Extended Stanza Addressing</title>
<author initials="J." surname="Hildebrand" fullname="Joe Hildebrand">
<organization/>
<address>
<email>jhildebr@cisco.com</email>
</address>
</author>
<author initials="P." surname="Saint-Andre" fullname="Peter Saint-Andre">
<organization/>
<address>
<email>stpeter@jabber.org</email>
</address>
</author>
<date day="15" month="September" year="2004"/>
</front>
<seriesInfo name="XSF XEP" value="0033"/>
<format type="HTML" target="http://xmpp.org/extensions/xep-0033.html"/>
</reference>
<reference anchor="XEP-0045">
<front>
<title>Multi-User Chat</title>
<author initials="P." surname="Saint-Andre" fullname="Peter Saint-Andre">
<organization/>
<address>
<email>stpeter@jabber.org</email>
</address>
</author>
<date day="16" month="July" year="2008"/>
</front>
<seriesInfo name="XSF XEP" value="0045"/>
<format type="HTML" target="http://xmpp.org/extensions/xep-0045.html"/>
</reference>
<reference anchor="XEP-0048">
<front>
<title>Bookmarks</title>
<author initials="R." surname="Blackman" fullname="Rachel Blackman">
<organization/>
<address>
<email>rcb@ceruleanstudios.com</email>
</address>
</author>
<author initials="P." surname="Millard" fullname="Peter Millard">
<organization/>
<address>
<email/>
</address>
</author>
<author initials="P." surname="Saint-Andre" fullname="Peter Saint-Andre">
<organization/>
<address>
<email>stpeter@jabber.org</email>
</address>
</author>
<date day="07" month="November" year="2007"/>
</front>
<seriesInfo name="XSF XEP" value="0048"/>
<format type="HTML" target="http://xmpp.org/extensions/xep-0048.html"/>
</reference>
<reference anchor="XEP-0054">
<front>
<title>vcard-temp</title>
<author initials="P." surname="Saint-Andre" fullname="Peter Saint-Andre">
<organization/>
<address>
<email>stpeter@jabber.org</email>
</address>
</author>
<date day="16" month="July" year="2008"/>
</front>
<seriesInfo name="XSF XEP" value="0054"/>
<format type="HTML" target="http://xmpp.org/extensions/xep-0054.html"/>
</reference>
<reference anchor="XEP-0055">
<front>
<title>Jabber Search</title>
<author initials="P." surname="Saint-Andre" fullname="Peter Saint-Andre">
<organization/>
<address>
<email>stpeter@jabber.org</email>
</address>
</author>
<date day="15" month="September" year="2009"/>
</front>
<seriesInfo name="XSF XEP" value="0055"/>
<format type="HTML" target="http://xmpp.org/extensions/xep-0055.html"/>
</reference>
<reference anchor="XEP-0060">
<front>
<title>Publish-Subscribe</title>
<author initials="P." surname="Millard" fullname="Peter Millard">
<organization/>
<address>
<email/>
</address>
</author>
<author initials="P." surname="Saint-Andre" fullname="Peter Saint-Andre">
<organization/>
<address>
<email>stpeter@jabber.org</email>
</address>
</author>
<author initials="R." surname="Meijer" fullname="Ralph Meijer">
<organization/>
<address>
<email>ralphm@ik.nu</email>
</address>
</author>
<date day="12" month="July" year="2010"/>
</front>
<seriesInfo name="XSF XEP" value="0060"/>
<format type="HTML" target="http://xmpp.org/extensions/xep-0060.html"/>
</reference>
<reference anchor="XEP-0065">
<front>
<title>SOCKS5 Bytestreams</title>
<author initials="D." surname="Smith" fullname="Dave Smith">
<organization/>
<address>
<email>dizzyd@jabber.org</email>
</address>
</author>
<author initials="M." surname="Miller" fullname="Matthew Miller">
<organization/>
<address>
<email>linuxwolf@outer-planes.net</email>
</address>
</author>
<author initials="P." surname="Saint-Andre" fullname="Peter Saint-Andre">
<organization/>
<address>
<email>stpeter@jabber.org</email>
</address>
</author>
<author initials="J." surname="Karneges" fullname="Justin Karneges">
<organization/>
<address>
<email>justin@affinix.com</email>
</address>
</author>
<date day="14" month="April" year="in progress, last updated 2010"/>
</front>
<seriesInfo name="XSF XEP" value="0065"/>
<format type="HTML" target="http://xmpp.org/extensions/xep-0065.html"/>
</reference>
<reference anchor="XEP-0077">
<front>
<title>In-Band Registration</title>
<author initials="P." surname="Saint-Andre" fullname="Peter Saint-Andre">
<organization/>
<address>
<email>stpeter@jabber.org</email>
</address>
</author>
<date day="15" month="September" year="2009"/>
</front>
<seriesInfo name="XSF XEP" value="0077"/>
<format type="HTML" target="http://xmpp.org/extensions/xep-0077.html"/>
</reference>
<reference anchor="XEP-0079">
<front>
<title>Advanced Message Processing</title>
<author initials="M." surname="Miller" fullname="Matthew Miller">
<organization/>
<address>
<email>linuxwolf@outer-planes.net</email>
</address>
</author>
<author initials="P." surname="Saint-Andre" fullname="Peter Saint-Andre">
<organization/>
<address>
<email>stpeter@jabber.org</email>
</address>
</author>
<date day="30" month="November" year="2005"/>
</front>
<seriesInfo name="XSF XEP" value="0079"/>
<format type="HTML" target="http://xmpp.org/extensions/xep-0079.html"/>
</reference>
<reference anchor="XEP-0114">
<front>
<title>Jabber Component Protocol</title>
<author initials="P." surname="Saint-Andre" fullname="Peter Saint-Andre">
<organization/>
<address>
<email>stpeter@jabber.org</email>
</address>
</author>
<date day="03" month="March" year="2005"/>
</front>
<seriesInfo name="XSF XEP" value="0114"/>
<format type="HTML" target="http://xmpp.org/extensions/xep-0114.html"/>
</reference>
<reference anchor="XEP-0136">
<front>
<title>Message Archiving</title>
<author initials="I." surname="Paterson" fullname="Ian Paterson">
<organization/>
<address>
<email>ian.paterson@clientside.co.uk</email>
</address>
</author>
<author initials="J." surname="Perlow" fullname="Jon Perlow">
<organization/>
<address>
<email>jonp@google.com</email>
</address>
</author>
<author initials="P." surname="Saint-Andre" fullname="Peter Saint-Andre">
<organization/>
<address>
<email>stpeter@jabber.org</email>
</address>
</author>
<author initials="J." surname="Karneges" fullname="Justin Karneges">
<organization/>
<address>
<email>justin@affinix.com</email>
</address>
</author>
<author initials="A." surname="Tsvyashchenko" fullname="Alexander Tsvyashchenko">
<organization/>
<address>
<email>lists@ndl.kiev.ua</email>
</address>
</author>
<author initials="Y." surname="Leboulanger" fullname="Yann Leboulanger">
<organization/>
<address>
<email>asterix@lagaule.org</email>
</address>
</author>
<date day="21" month="June" year="2010"/>
</front>
<seriesInfo name="XSF XEP" value="0136"/>
<format type="HTML" target="http://xmpp.org/extensions/xep-0136.html"/>
</reference>
<reference anchor="XEP-0144">
<front>
<title>Roster Item Exchange</title>
<author initials="P." surname="Saint-Andre" fullname="Peter Saint-Andre">
<organization/>
<address>
<email>stpeter@jabber.org</email>
</address>
</author>
<date day="26" month="August" year="2005"/>
</front>
<seriesInfo name="XSF XEP" value="0144"/>
<format type="HTML" target="http://xmpp.org/extensions/xep-0144.html"/>
</reference>
<reference anchor="XEP-0166">
<front>
<title>Jingle</title>
<author initials="S." surname="Ludwig" fullname="Scott Ludwig">
<organization/>
<address>
<email>scottlu@google.com</email>
</address>
</author>
<author initials="J." surname="Beda" fullname="Joe Beda">
<organization/>
<address>
<email>jbeda@google.com</email>
</address>
</author>
<author initials="P." surname="Saint-Andre" fullname="Peter Saint-Andre">
<organization/>
<address>
<email>stpeter@jabber.org</email>
</address>
</author>
<author initials="R." surname="McQueen" fullname="Robert McQueen">
<organization/>
<address>
<email>robert.mcqueen@collabora.co.uk</email>
</address>
</author>
<author initials="S." surname="Egan" fullname="Sean Egan">
<organization/>
<address>
<email>seanegan@google.com</email>
</address>
</author>
<author initials="J." surname="Hildebrand" fullname="Joe Hildebrand">
<organization/>
<address>
<email>jhildebr@cisco.com</email>
</address>
</author>
<date day="23" month="December" year="2009"/>
</front>
<seriesInfo name="XSF XEP" value="0166"/>
<format type="HTML" target="http://xmpp.org/extensions/xep-0166.html"/>
</reference>
<reference anchor="XEP-0191">
<front>
<title>Simple Communications Blocking</title>
<author initials="P." surname="Saint-Andre" fullname="Peter Saint-Andre">
<organization/>
<address>
<email>stpeter@jabber.org</email>
</address>
</author>
<date day="15" month="February" year="2007"/>
</front>
<seriesInfo name="XSF XEP" value="0191"/>
<format type="HTML" target="http://xmpp.org/extensions/xep-0191.html"/>
</reference>
<reference anchor="XEP-0203">
<front>
<title>Delayed Delivery</title>
<author initials="P." surname="Saint-Andre" fullname="Peter Saint-Andre">
<organization/>
<address>
<email>stpeter@jabber.org</email>
</address>
</author>
<date day="15" month="September" year="2009"/>
</front>
<seriesInfo name="XSF XEP" value="0203"/>
<format type="HTML" target="http://xmpp.org/extensions/xep-0203.html"/>
</reference>
<reference anchor="XEP-0220">
<front>
<title>Server Dialback</title>
<author initials="J." surname="Miller" fullname="Jeremie Miller">
<organization/>
<address>
<email>jer@jabber.org</email>
</address>
</author>
<author initials="P." surname="Saint-Andre" fullname="Peter Saint-Andre">
<organization/>
<address>
<email>stpeter@jabber.org</email>
</address>
</author>
<author initials="P." surname="Hancke" fullname="Philipp Hancke">
<organization/>
<address>
<email/>
</address>
</author>
<date day="18" month="March" year="2010"/>
</front>
<seriesInfo name="XSF XEP" value="0220"/>
<format type="HTML" target="http://xmpp.org/extensions/xep-0220.html"/>
</reference>
<reference anchor="XEP-0249">
<front>
<title>Direct MUC Invitations</title>
<author initials="P." surname="Saint-Andre" fullname="Peter Saint-Andre">
<organization/>
<address>
<email>stpeter@jabber.org</email>
</address>
</author>
<date day="07" month="December" year="2009"/>
</front>
<seriesInfo name="XSF XEP" value="0249"/>
<format type="HTML" target="http://xmpp.org/extensions/xep-0249.html"/>
</reference>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 01:20:11 |