moparisthebest
/
xeps
mirror of https://github.com/moparisthebest/xeps
1
0
Fork 0
Code Issues Releases Wiki Activity

1.1pre2 

git-svn-id: file:///home/ksmith/gitmigration/svn/xmpp/trunk@468 4b5297f7-1745-476d-ba37-a9c6900126ab
This commit is contained in:
Peter Saint-Andre 2007-01-31 23:23:05 +00:00
parent d087744dd8
commit 59434e4a5a
1 changed files with 23 additions and 28 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

51
xep-0073.xml
View File

@ -26,81 +26,81 @@
<shortname>N/A</shortname>
&stpeter;
<revision>
<version>1.1pre1</version>
<date>in progress, last updated 2007-01-30</date>
<version>1.1pre2</version>
<date>in progress, last updated 2007-01-31</date>
<initials>psa</initials>
<remark>Changed support for XEP-0078 and XEP-0086 from REQUIRED to RECOMMENDED.</remark>
<remark><p>Changed support for XEP-0077 from required for servers and recommended for clients to recommended for both servers and clients; changed support for XEP-0078 from required for both servers and clients to recommended for servers and not recommended for clients; changed support for XEP-0086 from required for servers and recommended for clients to recommended for both servers and clients.</p></remark>
</revision>
<revision>
<version>1.0</version>
<date>2004-12-09</date>
<initials>psa</initials>
<remark>Per a vote of the Jabber Council, advanced status to Active.</remark>
<remark><p>Per a vote of the Jabber Council, advanced status to Active.</p></remark>
</revision>
<revision>
<version>0.10</version>
<date>2004-12-06</date>
<initials>psa</initials>
<remark>Per feedback from the Jabber Council, made all of RFC 3920 mandatory (no loophole allowing certain client platforms to not support TLS and SASL).</remark>
<remark><p>Per feedback from the Jabber Council, made all of RFC 3920 mandatory (no loophole allowing certain client platforms to not support TLS and SASL).</p></remark>
</revision>
<revision>
<version>0.9</version>
<date>2004-12-01</date>
<initials>psa</initials>
<remark>Removed reference to deployments and moved historical paragraph to a footnote.</remark>
<remark><p>Removed reference to deployments and moved historical paragraph to a footnote.</p></remark>
</revision>
<revision>
<version>0.8</version>
<date>2004-11-18</date>
<initials>psa</initials>
<remark>Updated references to reflect publication of RFCs 3920 and 3921.</remark>
<remark><p>Updated references to reflect publication of RFCs 3920 and 3921.</p></remark>
</revision>
<revision>
<version>0.7</version>
<date>2004-08-18</date>
<initials>psa</initials>
<remark>Changed In-Band Registration to recommended for clients; added note about SSL communications over port 5223; clarified wording throughout.</remark>
<remark><p>Changed In-Band Registration to recommended for clients; added note about SSL communications over port 5223; clarified wording throughout.</p></remark>
</revision>
<revision>
<version>0.6</version>
<date>2004-03-24</date>
<initials>psa</initials>
<remark>Updated to reflect approval of XMPP Core and XMPP IM.</remark>
<remark><p>Updated to reflect approval of XMPP Core and XMPP IM.</p></remark>
</revision>
<revision>
<version>0.5</version>
<date>2003-11-24</date>
<initials>psa</initials>
<remark>Updated to reflect work by the XMPP WG; changed status to Deferred.</remark>
<remark><p>Updated to reflect work by the XMPP WG; changed status to Deferred.</p></remark>
</revision>
<revision>
<version>0.4</version>
<date>2003-08-13</date>
<initials>psa</initials>
<remark>Renamed.</remark>
<remark><p>Renamed.</p></remark>
</revision>
<revision>
<version>0.3</version>
<date>2003-05-20</date>
<initials>psa</initials>
<remark>Slight editorial revisions.</remark>
<remark><p>Slight editorial revisions.</p></remark>
</revision>
<revision>
<version>0.2</version>
<date>2003-04-06</date>
<initials>psa</initials>
<remark>Limited scope to definition of "Jabber IM Basic".</remark>
<remark><p>Limited scope to definition of "Jabber IM Basic".</p></remark>
</revision>
<revision>
<version>0.1</version>
<date>2003-03-04</date>
<initials>psa</initials>
<remark>Initial version.</remark>
<remark><p>Initial version.</p></remark>
</revision>
</header>
<section1 topic='Introduction' anchor='intro'>
<p>Given the large number of Jabber/XMPP protocols,
<note>The protocols developed by the Jabber community have matured considerably since 1999. The core protocols were originally created by a small group of developers who worked on early Jabber-related open-source software projects such as the &jabberd; server, the Winjab, Gabber, and Jarl clients, the Net::Jabber and Jabberbeans libraries, and gateways to consumer IM services. In the summer of 2001, the &XSF; was founded to institute a formal standards process within the growing Jabber community (codified in &xep0001;). In late 2002, the &IETF; formed the &XMPPWG;, which formalized the core Jabber protocols under the name Extensible Messaging and Presence Protocol (XMPP). In early 2004, the IETF approved the main XMPP specifications as Proposed Standards within the Internet Standards Process defined by &rfc2026;, resulting in publication of <cite>RFC 3920</cite> (&xmppcore;) and <cite>RFC 3921</cite> (&xmppim;). In the meantime, the XSF has continued to develop additional protocols on top of XMPP in order to address functionality areas (such as file transfer) that were too application-specific for consideration within the IETF.</note>
<note>The protocols developed by the Jabber community have matured considerably since 1999. The core protocols were originally created by a small group of developers who worked on early Jabber-related open-source software projects such as the &jabberd; server, the Winjab, Gabber, and Jarl clients, the Net::Jabber and Jabberbeans libraries, and gateways to consumer IM services. In the summer of 2001, the &XSF; was founded to institute a formal standards process within the growing Jabber community (codified in &xep0001;). In late 2002, the &IETF; formed the &XMPPWG;, which formalized the core Jabber protocols under the name Extensible Messaging and Presence Protocol (XMPP). In early 2004, the IETF approved the main XMPP specifications as Proposed Standards within the Internet Standards Process defined by &rfc2026;, resulting in publication of <cite>RFC 3920</cite> (&xmppcore;) and <cite>RFC 3921</cite> (&xmppim;). In the meantime, the XSF has continued to develop additional protocols on top of XMPP in order to address functionality areas that are too application-specific for consideration within the IETF.</note>
it is not always clear to developers exactly which protocols they need to implement in order to interoperate over Jabber/XMPP networks. This document attempts to assist developers by defining a protocol suite for basic instant messaging and presence.</p>
</section1>
<section1 topic='Requirements and Approach' anchor='reqs'>
@ -112,16 +112,11 @@
<p>The Basic IM Protocol Suite does not include more advanced IM functionality, such as groupchat or HTML message formatting; see &xep0117; for such features.</p>
</section1>
<section1 topic='Definition' anchor='def'>
<p>The software developed in the Jabber community is built on the foundation of XML streams, a consistent addressing scheme (JIDs), channel encryption, authentication of an entity (client or server) with a server, three core data elements (&MESSAGE;, &PRESENCE;, and &IQ;), and proper handling of XML namespaces. These foundational building blocks have been formalized within RFC 3920, support for which is REQUIRED by this protocol suite. However, XMPP Core is not fully congruent with the core of what has traditionally been known as "Jabber", and this divergence needs to be captured in the Basic IM Protocol Suite. In particular, the following are RECOMMENDED herein in order to ensure compatibility with the large deployed base of older Jabber software:
<note>Older software also used port 5223 for SSL-enabled communications between a client and a server, rather than upgrading port 5222 as is done during TLS negotiation (the equivalent for server-to-server communications was never implemented); while support for this behavior is OPTIONAL, it may be quite desirable in order to interoperate with older software and deployments.</note>
</p>
<ul>
<li>Support for &xep0078; as a fallback method for authentication.</li>
<li>Support for the error 'code' attribute specified in &xep0086;.</li>
</ul>
<p>RFC 3920 does not define everything that is normally expected of even a minimal instant messaging and presence application (in effect, it defines the transport layer rather than the IM and presence application layer). Much of this IM and presence functionality is defined in RFC 3921 in order to meet the requirements of RFC 2779. In particular, RFC 3921 defines roster management, presence subscriptions, privacy lists (whitelisting/blacklisting), and routing and delivery guidelines for clients and servers.</p>
<p>However, Jabber instant messaging and presence applications have traditionally also included the ability to discover information about other entities on the network, and to reply to queries for information. This behavior is extremely helpful because it ensures that entities on the network can determine each other's capabilities and thus understand how to communicate together. (The original such protocol was &xep0094;, but that protocol has been superseded by &xep0030;.) Support for Service Discovery is therefore REQUIRED by this protocol suite, as well.</p>
<p>Traditionally, Jabber servers (and some services) have also offered the ability for clients to register accounts "in-band" (i.e., over Jabber/XMPP) in order to bootstrap participation on the network; this protocol is defined in &xep0077; and support for it is REQUIRED for servers but RECOMMENDED for clients (however, any given server deployment MAY disable in-band registration as a matter of service provisioning).</p>
<p>The software developed in the Jabber community is built on the foundation of XML streams, a consistent addressing scheme (JIDs), channel encryption, authentication of an entity (client or server) with a server, three core data elements (&MESSAGE;, &PRESENCE;, and &IQ;), and proper handling of XML namespaces. These foundational building blocks have been formalized within RFC 3920, support for which is REQUIRED by this protocol suite.</p>
<p>However, XMPP Core is not fully congruent with the core of what has traditionally been known as "Jabber", and this divergence needs to be captured in the Basic IM Protocol Suite. For the sake of backward compatibility, support for &xep0078; is RECOMMENDED for servers (but not clients) as a fallback method of authentication by older deployed clients. <note>Older software also used port 5223 for SSL-enabled communications between a client and a server, rather than upgrading port 5222 as is done during TLS negotiation (the equivalent for server-to-server communications was never implemented). Support for this behavior is OPTIONAL on the part of servers for backwards-compatibility with older deployed clients.</note> In addition, support for the error 'code' attribute specified in &xep0086; is RECOMMENDED for both clients and servers.</p>
<p>RFC 3920 does not define everything that is normally expected of even a minimal instant messaging and presence application (in effect, it defines the transport layer rather than the IM and presence application layer). Much of this IM and presence functionality is defined in RFC 3921 in order to meet the requirements of RFC 2779. In particular, RFC 3921 defines roster management, presence subscriptions, and routing and delivery guidelines for clients and servers. Therefore, support for <cite>RFC 3921</cite> is REQUIRED.</p>
<p>Furthermore, Jabber instant messaging and presence applications typically include the ability to discover information about other entities on the network, and to reply to queries for information. This behavior is extremely helpful because it ensures that entities on the network can determine each other's capabilities and thus understand how to communicate together. Therefore, support for &xep0030; is REQUIRED by this protocol suite.</p>
<p>Traditionally, Jabber servers (and some services) have also offered the ability for clients to register accounts "in-band" (see &xep0077;) in order to bootstrap participation on the network; support for that protocol is RECOMMENDED but any given server deployment MAY disable in-band registration as a matter of service provisioning.</p>
<p>Thus we define the Basic IM Protocol Suite as follows:</p>
<table caption='Required and Recommended Specifications'>
<tr>
@ -142,11 +137,11 @@
</tr>
<tr>
<td><strong>XEP-0077: In-Band Registration</strong></td>
<td>REQUIRED for servers; RECOMMENDED for clients</td>
<td>RECOMMENDED</td>
</tr>
<tr>
<td><strong>XEP-0078: Non-SASL Authentication</strong></td>
<td>RECOMMENDED</td>
<td>RECOMMENDED for servers; NOT RECOMMENDED for clients</td>
</tr>
<tr>
<td><strong>XEP-0086: Error Condition Mappings</strong></td>
@ -155,7 +150,7 @@
</table>
</section1>
<section1 topic='Security Considerations' anchor='security'>
<p>RFC 3920 requires support for SASL and TLS as must-implement protocols, and that support is not modified herein. Refer to <cite>XEP-0078: Non-SASL Authentication</cite> for an explanation of the older authentication method still in use by various existing client and server implementations and deployments, as well as the proper order of precedence between SASL authentication (RFC 3920) and non-SASL authentication (XEP-0078).</p>
<p>RFC 3920 requires support for SASL and TLS as must-implement protocols, and that support is not modified herein. The older authentication method specified in <cite>XEP-0078: Non-SASL Authentication</cite> is now deprecated; however, support for it is still recommended in server implementations for the sake of backward compatibility (see <cite>XEP-0078</cite> regarding the proper order of precedence between SASL authentication and non-SASL authentication).</p>
</section1>
<section1 topic='IANA Considerations' anchor='iana'>
<p>This document requires no interaction with &IANA;.</p>