This JEP defines a recommended suite of Jabber/XMPP protocols to be supported by basic instant messaging and presence applications.
NOTICE: This JEP is currently within Last Call or under consideration by the Jabber Council for advancement to the next stage in the JSF standards process. For further details, visit <http://www.jabber.org/council/queue.php>.
Status: Proposed
Type: Standards Track
Number: 0073
Version: 0.9
Last Updated: 2004-12-01
JIG: Standards JIG
Approving Body: Jabber Council
Dependencies: XMPP Core, XMPP IM, JEP-0030, JEP-0077, JEP-0078, JEP-0086
Supersedes: None
Superseded By: None
Short Name: N/A
Email: stpeter@jabber.org
JID: stpeter@jabber.org
This Jabber Enhancement Proposal is copyright 1999 - 2004 by the Jabber Software Foundation (JSF) and is in full conformance with the JSF's Intellectual Property Rights Policy <http://www.jabber.org/jsf/ipr-policy.php>. This material may be distributed only subject to the terms and conditions set forth in the Open Publication License, v1.0 or later (the latest version is presently available at <http://www.opencontent.org/openpub/>).
The preferred venue for discussion of this document is the Standards-JIG discussion list: <http://mail.jabber.org/mailman/listinfo/standards-jig>.
The Extensible Messaging and Presence Protocol (XMPP) is defined in the XMPP Core (RFC 3920) and XMPP IM (RFC 3921) specifications contributed by the Jabber Software Foundation to the Internet Standards Process, which is managed by the Internet Engineering Task Force in accordance with RFC 2026. Any protocols defined in this JEP have been developed outside the Internet Standards Process and are to be understood as extensions to XMPP rather than as an evolution, development, or modification of XMPP itself.
The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.
Given the large number of Jabber/XMPP protocols, [1] it is not always clear to developers exactly which protocols they need to implement in order to interoperate over Jabber/XMPP networks. This JEP attempts to assist developers by defining a protocol suite for basic instant messaging and presence.
Defining a protocol suite provides a high-level "bucket" into which we can place specific functionality areas for development and compliance testing. A baseline is provided by RFCs 3920 and 3921, which define XML streams, JID processing, channel encryption, authentication, the three primary XML stanza types (<message/>, <presence/>, and <iq/>), namespace handling, presence subscriptions, roster management, and privacy lists (whitelisting/blacklisting). However, basic Jabber instant messaging and presence applications should support several additional protocols that were not included in the XMPP specifications for either of the following reasons:
The Basic IM Protocol Suite does not include more advanced IM functionality, such as groupchat or HTML message formatting; see Intermediate IM Protocol Suite [11] for such features.
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 (except as qualified for certain computing platforms in the Security Considerations section of this document). 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 REQUIRED herein in order to ensure compatibility with the large deployed base of older Jabber software: [12]
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.
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 Agent Information [15], but that protocol has been superseded by Service Discovery [16].) Support for Service Discovery is therefore REQUIRED by this protocol suite, as well.
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 In-Band Registration [17] 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).
Thus we define the Basic IM Protocol Suite as follows:
Table 1: Required and Recommended Specifications
| Specification | Requirement Level |
|---|---|
| RFC 3920: XMPP Core | REQUIRED (except as qualified under Security Considerations) |
| RFC 3921: XMPP IM | REQUIRED |
| JEP-0078: Non-SASL Authentication | REQUIRED |
| JEP-0086: Error Condition Mappings | REQUIRED for servers; RECOMMENDED for clients |
| JEP-0030: Service Discovery | REQUIRED |
| JEP-0077: In-Band Registration | REQUIRED for servers; RECOMMENDED for clients |
RFC 3920 requires support for SASL and TLS as must-implement protocols. Unfortunately, support for these advanced security protocols is non-existent or unreliable at the time of writing on computing platforms for some common devices, such as J2ME and Symbian. A client implementation of the Basic IM Protocol Suite is STRONGLY RECOMMENDED to support SASL and TLS; however, a client implementation MAY lack support for SASL and TLS if and only if those protocols are difficult or impossible to implement on a particular computing platform given the existing state of technology. This proviso does not apply to server implementations, which MUST support SASL and TLS.
This JEP requires no interaction with the Internet Assigned Numbers Authority (IANA) [18].
No namespaces or parameters need to be registered with the Jabber Registrar [19] as a result of this JEP.
1. 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 [2] 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 Jabber Software Foundation (JSF) [3] was founded to institute a formal standards process within the growing Jabber community (codified in Jabber Enhancement Proposals [4]). In late 2002, the Internet Engineering Task Force (IETF) [5] formed the XMPP Working Group [6], 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 RFC 2026 [7], resulting in publication of RFC 3920 (XMPP Core [8]) and RFC 3921 (XMPP IM [9]). In the meantime, the JSF 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.
2. The jabberd server is the original server implementation of the Jabber protocols, first developed by Jeremie Miller, inventor of Jabber. For further information, see <http://jabberd.jabberstudio.org/>.
3. The Jabber Software Foundation (JSF) is an independent, non-profit organization that develops open application protocols on top of the IETF's Extensible Messaging and Presence Protocol (XMPP). For further information, see <http://www.jabber.org/jsf/>.
4. JEP-0001: Jabber Enhancement Proposals <http://www.jabber.org/jeps/jep-0001.html>.
5. The Internet Engineering Task Force is the principal body engaged in the development of new Internet standard specifications, best known for its work on standards such as HTTP and SMTP. For further information, see <http://www.ietf.org/>.
6. The XMPP Working Group was created by the Internet Engineering Task Force to define an adaptation of the base Jabber protocols that could be considered an IETF-approved instant messaging and presence technology. For further information, see <http://www.ietf.org/html.charters/xmpp-charter.html>.
7. RFC 2026: The Internet Standards Process <http://www.ietf.org/rfc/rfc2026.txt>.
8. RFC 3920: Extensible Messaging and Presence Protocol (XMPP): Core <http://www.ietf.org/rfc/rfc3920.txt>.
9. RFC 3921: Extensible Messaging and Presence Protocol (XMPP): Instant Messaging and Presence <http://www.ietf.org/rfc/rfc3921.txt>.
10. RFC 2779: A Model for Presence and Instant Messaging <http://www.ietf.org/rfc/rfc2779.txt>.
11. JEP-0117: Intermediate IM Protocol Suite <http://www.jabber.org/jeps/jep-0117.html>.
12. 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 support older software as well as newer software that is unable to implement TLS as explained in the Security Considerations section of this document.
13. JEP-0078: Non-SASL Authentication <http://www.jabber.org/jeps/jep-0078.html>.
14. JEP-0086: Error Condition Mappings <http://www.jabber.org/jeps/jep-0086.html>.
15. JEP-0094: Agent Information <http://www.jabber.org/jeps/jep-0094.html>.
16. JEP-0030: Service Discovery <http://www.jabber.org/jeps/jep-0030.html>.
17. JEP-0077: In-Band Registration <http://www.jabber.org/jeps/jep-0077.html>.
18. The Internet Assigned Numbers Authority (IANA) is the central coordinator for the assignment of unique parameter values for Internet protocols, such as port numbers and URI schemes. For further information, see <http://www.iana.org/>.
19. The Jabber Registrar maintains a list of reserved Jabber protocol namespaces as well as registries of parameters used in the context of protocols approved by the Jabber Software Foundation. For further information, see <http://www.jabber.org/registrar/>.
END