Network Working Group J. Miller Internet-Draft The Jabber.org Project Expires: December 14, 2000 June 15, 2000 Jabber jabber Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on December 14, 2000. Copyright Notice Copyright (C) The Internet Society (2000). All Rights Reserved. Abstract This memo provides a comprehensive description of the Jabber architecture, design principles, and protocol. Miller Expires December 14, 2000 [Page 1] Internet-Draft Jabber June 2000 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1 What is Jabber? . . . . . . . . . . . . . . . . . . . . . . 4 1.2 Background and History . . . . . . . . . . . . . . . . . . . 4 1.3 Evolution . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.4 Today . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Architecture Overview . . . . . . . . . . . . . . . . . . . 6 2.1 Server . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 2.2 Client . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 2.3 Transport . . . . . . . . . . . . . . . . . . . . . . . . . 7 3. Entity Identification . . . . . . . . . . . . . . . . . . . 8 3.1 Three Tier . . . . . . . . . . . . . . . . . . . . . . . . . 8 3.1.1 Host (server) . . . . . . . . . . . . . . . . . . . . . . . 8 3.1.2 Node (user) . . . . . . . . . . . . . . . . . . . . . . . . 8 3.1.3 Resource . . . . . . . . . . . . . . . . . . . . . . . . . . 8 3.2 URI . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 4. XML . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 4.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 10 4.2 Namespaces . . . . . . . . . . . . . . . . . . . . . . . . . 10 4.3 Validation . . . . . . . . . . . . . . . . . . . . . . . . . 10 4.4 element . . . . . . . . . . . . . . . . . . . . . 10 4.4.1 Attributes . . . . . . . . . . . . . . . . . . . . . . . . . 10 4.4.2 Children . . . . . . . . . . . . . . . . . . . . . . . . . . 11 4.4.3 Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 11 4.5 element . . . . . . . . . . . . . . . . . . . . . 12 4.5.1 Attributes . . . . . . . . . . . . . . . . . . . . . . . . . 12 4.5.2 Children . . . . . . . . . . . . . . . . . . . . . . . . . . 13 4.5.3 Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 13 4.6 element . . . . . . . . . . . . . . . . . . . . . . . . 13 4.6.1 Attributes . . . . . . . . . . . . . . . . . . . . . . . . . 13 4.6.2 Children . . . . . . . . . . . . . . . . . . . . . . . . . . 14 4.6.3 Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 14 5. Client Access . . . . . . . . . . . . . . . . . . . . . . . 16 5.1 TCP Socket . . . . . . . . . . . . . . . . . . . . . . . . . 16 5.2 Transport Layer . . . . . . . . . . . . . . . . . . . . . . 16 5.3 Authentication . . . . . . . . . . . . . . . . . . . . . . . 16 5.4 Messages . . . . . . . . . . . . . . . . . . . . . . . . . . 16 5.5 Presence . . . . . . . . . . . . . . . . . . . . . . . . . . 16 5.6 Roster . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 5.7 Presence Subscriptions . . . . . . . . . . . . . . . . . . . 17 6. Servers . . . . . . . . . . . . . . . . . . . . . . . . . . 18 6.1 Connections . . . . . . . . . . . . . . . . . . . . . . . . 18 6.2 DNS . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 7. Security Considerations . . . . . . . . . . . . . . . . . . 19 7.1 SSL . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 7.2 Secure Identity and Encryption . . . . . . . . . . . . . . . 19 7.3 Client Connections . . . . . . . . . . . . . . . . . . . . . 19 7.4 Presence . . . . . . . . . . . . . . . . . . . . . . . . . . 19 Miller Expires December 14, 2000 [Page 2] Internet-Draft Jabber June 2000 8. Scaling Considerations . . . . . . . . . . . . . . . . . . . 20 8.1 TCP Sockets . . . . . . . . . . . . . . . . . . . . . . . . 20 8.2 Server Farms . . . . . . . . . . . . . . . . . . . . . . . . 20 8.3 Client Optimizations . . . . . . . . . . . . . . . . . . . . 20 8.4 Server Restrictions . . . . . . . . . . . . . . . . . . . . 20 9. Extended Functionality . . . . . . . . . . . . . . . . . . . 21 9.1 Services (Agents/Transports) . . . . . . . . . . . . . . . . 21 9.2 MIME Transfers . . . . . . . . . . . . . . . . . . . . . . . 21 9.3 XML Medium . . . . . . . . . . . . . . . . . . . . . . . . . 21 9.4 Session Initialization . . . . . . . . . . . . . . . . . . . 22 9.5 Client Access . . . . . . . . . . . . . . . . . . . . . . . 22 10. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 23 10.1 Minimal Client . . . . . . . . . . . . . . . . . . . . . . . 23 10.2 Basic Client . . . . . . . . . . . . . . . . . . . . . . . . 23 10.3 Extending . . . . . . . . . . . . . . . . . . . . . . . . . 25 11. IMPP and Interoperability Notes . . . . . . . . . . . . . . 28 11.1 Requirements Conformance . . . . . . . . . . . . . . . . . . 28 11.2 Interoperability . . . . . . . . . . . . . . . . . . . . . . 28 References . . . . . . . . . . . . . . . . . . . . . . . . . 29 Author's Address . . . . . . . . . . . . . . . . . . . . . . 30 A. The Jabber Protocol DTD . . . . . . . . . . . . . . . . . . 31 B. XML Streams DTD . . . . . . . . . . . . . . . . . . . . . . 33 C. element . . . . . . . . . . . . . . . . . . . . . . 34 C.1 Attributes . . . . . . . . . . . . . . . . . . . . . . . . . 34 C.2 Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 35 D. Info/Query Namespaces . . . . . . . . . . . . . . . . . . . 36 D.1 Simple Client Authentication - jabber:iq:auth . . . . . . . 36 D.1.1 Children . . . . . . . . . . . . . . . . . . . . . . . . . . 36 D.1.2 Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 37 D.2 Roster (Contact List) Management - jabber:iq:roster . . . . 37 D.2.1 Children . . . . . . . . . . . . . . . . . . . . . . . . . . 37 D.2.2 Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 38 D.3 Registration Request - jabber:iq:register . . . . . . . . . 39 D.3.1 Children . . . . . . . . . . . . . . . . . . . . . . . . . . 39 D.3.2 Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 40 E. X Namespaces . . . . . . . . . . . . . . . . . . . . . . . . 41 E.1 Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 41 F. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 42 Full Copyright Statement . . . . . . . . . . . . . . . . . . 43 Miller Expires December 14, 2000 [Page 3] Internet-Draft Jabber June 2000 1. Introduction 1.1 What is Jabber? At the core, Jabber is an API to provide instant messaging and presence functionality independent of data exchanged between entities. The primary use of Jabber is to give existing applications instant connectivity through messaging and presence features, contact list capabilities, and back-end services that transparently enrich the available functionality. Essentially, Jabber defines an abstraction layer utilizing XML[1] to encode the common essential data types. This abstraction layer is managed by an intelligent server which routes data between the client APIs and the backend services that translate data from remote networks or protocols. By using this compatible abstraction layer, Jabber can provide many aspects of an Instant Messaging (IM) and/or Presence service in a simplified and uniform way. 1.2 Background and History Jabber began in early 1998 as an open source project to both enable and ease the construction of compatible IM clients. The intention was that a client would only have to understand simple standard XML data types for messages and presence, and be able to focus on being an IM client, not on the complexity of dealing with the various IM networks. To avoid requiring the overhead of a typical "loadable module" API, the XML abstraction layer was made available to the client via a standard TCP[2] socket. The chosen model is essentially that of a typical client-server, where the clients utilizing the API access it as a server via TCP. Certain server components have a very high frequency of upgrades, based on the adapting protocols with which they translate. The server was also then shared on a single host to a group of users to reduce the maintenance requirements for the client API. This also significantly reduces the deployment overhead for clients, since they simply need a single TCP socket to the server. 1.3 Evolution As Jabber was developed and the architecture evolved, it became clear that a simple and flexible means of assigning identity to the various components was required. This started with clients, which are required to have a unique identity and be authorized to access the server API. The server was also assigned a unique identity, as were the individual components on the server side. Due to the role that the server plays with respect to the clients, Miller Expires December 14, 2000 [Page 4] Internet-Draft Jabber June 2000 and and due to the need to have a clear and established means of identitfying individual entities, the natural evolution of the server was to simply become an intelligent router. Not only does the server manage and route the XML data between the client API and the abstraction layer, but it also routes data directly between clients acting as an independent IM server for all clients. By assigning server identity as a hostname, servers are also able to route data directly to each other and their connected clients, thereby creating a new, inherently open IM network out of all the individual installed servers and clients. Additionally, to simplify clients as well as to add functionality to the server, the server began to act as an XML repository by storing XML for the client. This enables the server to store the contact list (roster), offline messages, profile information such as a XML vCard[3], or custom client preferences and data (bookmarks, settings, etc.). 1.4 Today After two years of full-time development by a large group of individuals around the world: o The abstraction layer and all APIs are fully implemented. o The XML data types are well defined (Appendix A). o Clients for all major platforms and environments are available or being developed. See http://jabbercentral.com/clients/ for a database of popular clients. o The GPL[4]/LGPL[5] licensed Jabber Server[14] is fully functional. o Numerous working server-side components (transports) exist or are in public development for popular services such as ICQ, AOL IM, Microsoft Messenger, Yahoo! Messenger, IRC, SMTP, RSS (news headlines), and more. See http://jabber.org/ for more information. Miller Expires December 14, 2000 [Page 5] Internet-Draft Jabber June 2000 2. Architecture Overview Connection Map T1 = N1 = C3 / C1 -- S1 - S2 = C4 / \ C2 - T2 Above is a map of the typical connections within the Jabber Architecture. o "-" represents the Jabber XML Protocol. o "=" represents any other protocol. o C1, C2 - Jabber Clients. o C3 - Client on another IM Network. o C4 - Client using an alternate protocol to access the Jabber Server. o S1 - a Jabber Server. o T1 - Transport, translating between the Jabber XML Protocol and the protocol used on another IM Network. o T2 - Transport providing other real-time data to Jabber, such as log notifications or headline news feeds. o N1 - third party IM Network. 2.1 Server The Server acts as an intelligent abstraction layer, managing the authorized client connections and connections to other Servers and Transports. All of the XML data is routed to the appropriate entities, or handled directly via internal modules on behalf of an entity. Servers can also utilize their own protocol to provide access to their clients. 2.2 Client Clients may directly connect to the Server and use the XML Protocol to take full advantage of the functionality available. A client may also be customized to only operate with one server, or use an Miller Expires December 14, 2000 [Page 6] Internet-Draft Jabber June 2000 alternate protocol to access a custom server. Clients of alternate IM Networks are also part of the Architecture, made accessable via a Transport to that IM Network. 2.3 Transport A Tranport is a special-purpose Server. The primary function of a Transport is to translate the Jabber XML protocol to the protocol of a third party IM Network as well as translate the return data back to XML. Transports may also function to provide access to additional back-end functionality such as a real-time alert system, device presence, pager delivery, language translation or other custom needs. Miller Expires December 14, 2000 [Page 7] Internet-Draft Jabber June 2000 3. Entity Identification 3.1 Three Tier The basic concept behind all identity within Jabber is a three-tier structure: the host, node, and resource. This allows a host to manage its nodes, and allows each node to have independent addressable resources. The most common use of this structure is as a server, user, and connection identifier. 3.1.1 Host (server) The basic required component of every ID is a Host. The Host is a standard DNS hostname and not case sensitive. 3.1.2 Node (user) Each Host can be addressed with individual Nodes, or users. Each user is specific to the Host it is associated with, similar to email. Usernames are restricted to 255 characters, and the following ASCII characters are invalid: any character with a decimal value less than 33 or in the following set [:@<>'"&]. Case is preserved, but not used when comparing/matching. A Node address looks similar to email: node@host. Node addresses are intended to be human readable/usable in the same manner that email addresses are used today. 3.1.3 Resource Resources are specific to a Node. All characters are allowed and there are no restrictions. Resource addresses are similar to the path part of a URL. Resources are used to address specific connections (since a Jabber server allows a user to be connected from multiple resources simultaneously), devices, or inboxes. An example Resource address: node@host/resource. Resource addresses are intended to be hidden from a user and only used at the software/protocol level. 3.2 URI A Jabber identifier conforms to RFC 2396[6], "Uniform Resource Identifiers (URI): Generic Syntax" by prepending a "jabber://" to any address. When compared to other URIs, it acts like a hybrid mailto: and http:// URI, offering both a user identity and an optional path/resource specification. Originally the abstraction layer used a Jabber URI within the protocol, but this was dropped until that use could undergo further review. Some of the reasoning was that the protocol was not capable Miller Expires December 14, 2000 [Page 8] Internet-Draft Jabber June 2000 of handling any other URI, in the sense that SMTP does not directly handle mailto: URIs within the protocol. Also, there was a tendency to want to create proprietary custom URIs (such as 'icq:' or 'talk:') within the protocol. Enabling the abstraction layer to use full URIs directly was deferred until such a use could be standardized and agreed upon. Miller Expires December 14, 2000 [Page 9] Internet-Draft Jabber June 2000 4. XML 4.1 Overview XML[1] is used to define the common basic data types: message and presence. Essentially, XML is the core enabling technology within the abstraction layer, providing a common language with which everything can communicate. XML allows for painless growth and expansion of the basic data types and almost infinite customization and extensibility anywhere within the data. Many solutions already exist for handling and parsing XML, and the XML Industry has invested significant time in understanding the technology and ensuring full internationalization. 4.2 Namespaces XML Namespaces[7] are used within all Jabber XML to create strict boundaries of data ownership. The basic function of namespaces is to separate different vocabularies of XML elements that are structurally mixed together. By ensuring that Jabber's XML is namespace-aware, it allows any XML defined by anyone to be structurally mixed with any data element within the protocol. This feature is relied upon frequently within the protocol to separate the XML that is processed by different components. 4.3 Validation Provided with this specification is a reference DTD for Jabber. It is an important note that the Jabber server is not responsible for validating the XML elements forwarded to a new user - an implementation may choose to provide only validated data elements but is not required to. Clients should not rely on the ability to send data which does not conform to the DTD, and should handle any non-conformant elements or attributes on the incoming stream by ignoring them. 4.4 element Messages are most similar in function to an email message. 4.4.1 Attributes o to - Specifies to whom the message is intended to be delivered to. o from - Specifies the sender of the message. Server set to prevent spoofing. Miller Expires December 14, 2000 [Page 10] Internet-Draft Jabber June 2000 o type - Used to express the context as to what format the message should be displayed in. If no type is set, clients default to a type="normal". Values include: * normal - Single message dialog, similar to original ICQ messages. * chat - Traditional two-way chat similar to AIM or IRC CTCP Chat. * groupchat - Group interface similar to an IRC channel with multiple participants. * headline - Ticker or active list of items (news, stock market). * error - See the error element (Appendix C). 4.4.2 Children o body - Contains the textual contents of the message for user display. No attributes. o subject - Contains the subject of the message. Similar to an email subject. No attributes. o thread - A random string generated by the originating client and copied back in replies. Used for tracking a conversation thread. o error - See the error element (Appendix C). 4.4.3 Examples The following examples have been server processed and contain the 'from' attribute. A simple message: Angels and Ministers of Grace, defend us! Miller Expires December 14, 2000 [Page 11] Internet-Draft Jabber June 2000 Complete chat message: Plotting Here, sweet lord, at your service. 100052 4.5 element Presence is used to express the current status from one entity to a group of entities. The characteristics of presence are most similar to that of a network game where the data travels from one host to the server, and then broadcast to the other hosts participating in that game. 4.5.1 Attributes o to - Specifies for whom the presence is bound. If none is specified, the server receives the presence. o from - Whom the presence is from. Server set to prevent spoofing. o id - A unique identifier for the presence. Sender of the presence sets this attribute. o type - Describes the type of presence. No 'type' attribute implies "available" presence or current status. Allowable types include: * unavailable - Signals that the user is no longer available. * subscribe - An attempt to subscribe to the recipient's presence. * subscribed - The sender has enabled the recipient to receive their presence. * unsubscribe - An unsubscription request. The server handles the actual unsubscription, but clients receive a presence element for notification reasons. * unsubscribed - The subscription has been cancelled. * probe - A server-to-server query to request an entity's current presence. Miller Expires December 14, 2000 [Page 12] Internet-Draft Jabber June 2000 4.5.2 Children o show - Describes a user's exact availability. Must be one of: * away - User is away from the client software temporarily. * chat - User is free to chat. * xa - User is away for an extended period (eXtended Away). * dnd - User does not wish to be disturbed (Do Not Disturb). o status - Custom availability message. Used in conjunction with the show element to give a detailed description of availability. 4.5.3 Examples Initial presence sent to server upon login to express default availability: Full-blown presence: xa Gone to England 4.6 element Info/Query, or IQ, is a simple structured conversation wrapper. Just as HTTP is a request-response medium, IQ enables an entity to make a request and receive a response from another entity. The actual content of the request and response is defined by another namespace within the IQ. 4.6.1 Attributes o to - Specifies for whom the IQ is bound. o from - Specifies from whom the IQ is sent. Server set to prevent spoofing. o id - A unique identifier for the IQ for tracking the query exchange. Sender of the IQ sets this attribute, which is returned in the response. o type - The 'type' attribute has several preset values. Each Miller Expires December 14, 2000 [Page 13] Internet-Draft Jabber June 2000 indicates a distinct step within an IQ conversation. * get - Indicates that the current query is a question or search for information. * set - This query contains data intended to set values or replace existing values. * result - This is a successful response to a get/set query. The IQ usually contains no further information on a successful result. * error - The query failed. See the error element (Appendix C). 4.6.2 Children In the strictest terms, the iq element contains no children since it is a vessel for XML in another namespace. In operation, a query element is usually contained within the iq element as defined by its own separate namespace. See Appendix D. 4.6.3 Examples The following examples are distinct parts of an IQ conversation for registration with jabber:iq:register (Appendix D.3) namespace. Client request for registration information to a server service (service.denmark): Server response with registration fields required: Choose a username and password to register with this server. 106c0a7b5510f192a408a1d054150ed1065e255a Miller Expires December 14, 2000 [Page 14] Internet-Draft Jabber June 2000 Client request to register for an account: hamlet hamlet@denmark gertrude 106c0a7b5510f192a408a1d054150ed1065e255a Successful registration: Failed registration: Not Acceptable Miller Expires December 14, 2000 [Page 15] Internet-Draft Jabber June 2000 5. Client Access 5.1 TCP Socket Clients connect to the server on TCP port 5222. The connection from the client to the server is persistent and maintains the presence state of the client after authentication. The server delivers all data to the client via this socket. If it is broken because of a network error, a client should reasonably attempt to reestablish the link with the server. Clients are never required to accept an incoming network connection, or establish a connection to any host other than the server. 5.2 Transport Layer An XML Stream (Appendix B) is simply the direct association of an XML document with a single TCP socket, and is used as the default transport layer to move data between clients and servers. When the socket is opened, the first data sent is the opening root element of the XML document representing that stream. All XML data within the document is continually parsed as available via the socket. When a top-level element is closed, it can then be further processed by the application. This simple streaming transport layer reduces the complexity of implementing applications that use Jabber, and satisfies all the demands of the communication with the server. 5.3 Authentication The client initially sends an IQ packet over the XML Stream to the server with the jabber:iq:auth namespace (Appendix D.1). This provides the credentials to access the server, which are either returned with an error or accepted. After accepting the credentials, the connection is then authorized to send and receive data. 5.4 Messages The client sends a message with a valid 'to' attribute. The server processes the 'to' address and adds a 'from' address, then attempts to deliver to the recipient. Messages that fail for any reason are returned as an error. Messages may be delivered to the client from the server at any time, with an appropriate 'from' attribute set. 5.5 Presence The current presence for the client is updated by sending presence to the server without a 'to' attribute. The server delivers this to the authorized recipients based on the subscription status as stored in the roster. The client will not receive presence from other entities until it has provided some form of available presence to Miller Expires December 14, 2000 [Page 16] Internet-Draft Jabber June 2000 the server. 5.6 Roster The client can send an IQ get with the jabber:iq:roster namespace (Appendix D.2) at any time, and will receive a result containing all the items that the server has stored for that user. Changes to any one item can be made by submitting that changed item via an IQ set in the same namespace. Since Jabber allows multiple connections for a single user, the roster may change by one connection and that change needs to be updated to the other connections. At any time, the server may do a "Roster Push" by sending an IQ set to the client containing the new/updated item[s]. 5.7 Presence Subscriptions Presence information is made available only to approved entites. This approval is managed by a simple subscription system, using the presence element (Section 4.5). There are four distinct types of subscription requests: subscribe - A request to be approved for receiving all future presence changes unsubscribe - A request to no longer receive any presence changes subscribed - A notice that a subscription has been created and all future presence changes will be sent unsubscribed - A notice that a subscription has been removed, and no further presence changes will be sent Request to subscribe to a user's presence: Response to a subscribe request: Miller Expires December 14, 2000 [Page 17] Internet-Draft Jabber June 2000 6. Servers The abstraction layer that Jabber provides includes the ability to individually address servers, and in fact relies on this ability for all external sources of data and functionality. This model then significantly expands the definition of a server to include intelligent agents, transports, device gateways, or any interactive data source. The additional expansion creates a need for flexibility in how server-side entities communicate. The server to server communication happens independent of the client, and can use any protocol or communication means available. The server may choose to implement a loadable module interface to allow components (which might be addressed as a server) to interact with clients, or two servers may choose to tunnel their data via an alternate transport layer. In fact, the Jabber Server uses an alternate communication library, libetherx, which manages connections between the server and trusted transports in a more efficient model. Although any protocol can be used between servers, at least one common basic one must exist so that there can be some guarantee of interoperability. 6.1 Connections Servers interconnect on TCP port 5269. There is no required state held between servers, so the connection is stateless and may be dropped at any time, but it is recommended that the connection persist based on the freqency of the interaction. Data is sent only over a locally originated connection to another server. All data from other servers is delivered via connections from those servers. 6.2 DNS All connections are made directly to the IP address of the hostname in the Entity Identifier (Section 3). If the connection to this host fails, servers attempt an MX record lookup. A connection attempt is made to each found MX record. In order to not conflict with SMTP and be able to operate a Jabber server on a separate host, a list of MX records is processed in reverse priority (highest number first). Miller Expires December 14, 2000 [Page 18] Internet-Draft Jabber June 2000 7. Security Considerations 7.1 SSL Servers can optionally support normal SSL[8] connections for added security on port 5223 for client connections and 5270 for server connections. 7.2 Secure Identity and Encryption Clients may optionally support signing and encrypting messages and presence by using PGP[15]/GnuPG[16]. The Jabber model specifically does NOT require trust in the remote servers or server-server trust. Although there may be benefits to a trusted server model (this issue is hotly debated), the direct client-client trust is already in use in email and allows those who desire a higher level of security to use it without requiring the significant increase in complexity throughout the architecture. 7.3 Client Connections The IP address and method of access of clients is never made available, nor are any connections other than the original server connection required. This protects the client hosts from direct attack or identification by third parties, and allows the service provider to utilize an alternate protocol or provide another method of access to its clients. 7.4 Presence Presence subscriptions are enforced by the user's server. Only the approved entities are able to discover a user's availability. Miller Expires December 14, 2000 [Page 19] Internet-Draft Jabber June 2000 8. Scaling Considerations 8.1 TCP Sockets A single, modern UNIX machine with proper tuning can handle 100,000 connections simultaneously. In c10k[10], Dan Kegel details how UNIX machines can be properly configured to handle large numbers of TCP connections. 8.2 Server Farms By sending the 302 redirect error as response to an authorization attempt, clients can be intelligently re-routed to a group of servers. A large-scale Jabber Server deployment will function in a manner very similar to that of a web server farm, with each server handling a moderate load and adding server hardware as demand grows. 8.3 Client Optimizations Custom clients can also make additional optimizations to reduce server load, such as idle auto-disconnect or local caching of server data that changes infrequently. These changes would be specific to the service requiring them and the clients supporting that service. 8.4 Server Restrictions The server can apply limits to various aspects of the client functionality: roster size, offline message sizes, simultaneous session restrictions, rate limits, etc. These limits require no changes to clients and can be enforced on any server. Miller Expires December 14, 2000 [Page 20] Internet-Draft Jabber June 2000 9. Extended Functionality 9.1 Services (Agents/Transports) The Jabber Architecture is designed to transparently provide access to independent data sources, so it is inherently geared to be extended in this way. Any server-side entity can easily participate in the real-time generation and delivery of XML. These entities can expose simple data sources such as instant calendaring events or log notifications, or enable access to an existing group of individuals by translating to an alternate protocol. All the new functionality is immediately available to any application utilizing Jabber or any entity available via the abstraction layer. 9.2 MIME Transfers All MIME objects, such as files, are transferred externally to the Jabber XML. MIME[11] is the dominant and successful method for transferring such data, and accessible in almost every environment. The Jabber XML Protocol is used to exchange http:// URLs between entities needing to exchange a MIME object. The jabber:x:oob can be inserted into messages and presence to express a MIME attachment. The jabber:iq:oob can be sent directly to another entity to express a single immediate MIME transfer. Recipient entities are then able to make the judgment whether they are able to handle the MIME objects, before incurring the cost of retreiving them. 9.3 XML Medium As mentioned, the use of XML Namespaces allows any entity to insert any custom XML in an alternate namespace anywhere within the protocol. This flexibiliy is used frequently within clients and servers, and enables custom applications to utilize the access Jabber provides to instantly exchange structured data with each other. Because Jabber is an XML medium, many of the new XML data formats can be immediately deployed on top of Jabber. This includes vCard XML[3], SyncML[17], XML/EDI[18], VoiceXML[19], and many more. The server can also act as an XML repository. The Jabber Server supports this via the jabber:iq:private namespace, which can contain any other XML that is stored on the server for the client. This can be used to store client preferences, bookmarks, game states, address books, notes, and any other structured data. Miller Expires December 14, 2000 [Page 21] Internet-Draft Jabber June 2000 A message with some custom XML included Angels and Ministers of Grace, defend us! abcd 9.4 Session Initialization Users often use the existing presence and contact list to manually initiate other interactive software (e.g., "Hamlet, ready to start the game? I'm on and ready!"). By including custom XML or sending a URI, this could be automated within the client or application. Common uses are voice and video conferencing, games, collaborative tools, calendaring, and more. 9.5 Client Access By utilizing the XML abstraction layer available as a client, additional gateways can be built to provide access to Jabber functionality for existing devices and software. Already, HTTP and IRC client gateways exist, with telnet and WAP[20] gateways under construction. In the future, devices with limited functionality or restricted access could use a custom gateway to access the messaging and presence features available on the server. Miller Expires December 14, 2000 [Page 22] Internet-Draft Jabber June 2000 10. Examples All data is sent over the TCP socket to denmark:5222. SEND: indicates that the stream is going to the server while RECV: indicates that the stream is coming from the server to the client. 10.1 Minimal Client A simple example: SEND: RECV: SEND: SEND: SEND: hamlet SEND: gertrude SEND: Castle SEND: SEND: RECV: SEND: SEND: The air bites shrewdly; it is very cold. SEND: RECV: RECV: SEND: SEND: SEND: hamlet SEND: gertrude SEND: Castle SEND: SEND: RECV: SEND: SEND: SEND: RECV: RECV: RECV: RECV: RECV: Friends RECV: RECV: RECV: SEND: RECV: RECV: chat RECV: RECV: RECV: How does my good Lord Hamlet? RECV: SEND: SEND: Well, God-a-mercy. SEND: RECV: RECV: Do you know me, my lord? Miller Expires December 14, 2000 [Page 24] Internet-Draft Jabber June 2000 RECV: SEND: RECV: Note that only polonius@denmark is online at this time, thus no presence was received from other roster items. 10.3 Extending A more advanced example that includes adding users to the roster, two new users coming online, a user changing status, and a client version request. SEND: RECV: SEND: SEND: SEND: hamlet SEND: gertrude SEND: Courtyard SEND: SEND: RECV: SEND: SEND: SEND: RECV: RECV: RECV: RECV: RECV: Friends RECV: RECV: RECV: Miller Expires December 14, 2000 [Page 25] Internet-Draft Jabber June 2000 SEND: RECV: RECV: chat RECV: RECV: RECV: away RECV: Busy with project. RECV: RECV: RECV: SEND: SEND: RECV: RECV: RECV: RECV: RECV: RECV: RECV: RECV: RECV: RECV: RECV: RECV: SEND: SEND: Well, God-a-mercy. SEND: RECV: RECV: My honoured lord! RECV: RECV: RECV: My most dear lord! RECV: SEND: SEND: SEND: RECV: Miller Expires December 14, 2000 [Page 26] Internet-Draft Jabber June 2000 RECV: RECV: Gabber RECV: 0.6.1 RECV: Debian GNU/Linux 2.2.16 RECV: RECV: SEND: RECV: Miller Expires December 14, 2000 [Page 27] Internet-Draft Jabber June 2000 11. IMPP and Interoperability Notes 11.1 Requirements Conformance The implemented protocol presented in this memo is in near conformance to RFC 2778[12], "A Model for Presence and Instant Messaging" and RFC 2779[13], "Instant Messaging / Presence Protocol Requirements." Notable differences are outlined in the following section. It should be noted that the Jabber protocol has been in evolution for approximately two years as of the date of this memo, thus this protocol has not been designed in response to RFCs 2778 and 2779. o RFC 2779, section 2.5 - Complete conformance with these requirements can be obtained by using a standard public key infrastructure such as GnuPG or PGP. o RFC 2779, section 4.1, paragraph 10 - all MIME data is delivered via HTTP. 11.2 Interoperability Jabber already provides complete interoperability, but at the cost of reverse engineering a 3rd party IM network protocol and operating a local translator to that protocol. The form of interoperability that Jabber offers is also restricted to the clients and requires the user to have a valid account on each IM network. It is the goal and desire of the Jabber development effort to increase the reach of the XML abstraction layer to overcome these limitations and reduce the reliance on local transports. The Jabber Development Team is ready and eager to interoperate directly at the server level with any other IM network and also willing to do much of the work to assist with this effort, as it reduces the complexity of the transport and adds significant new functionality to both sides. Using MSN Messenger as a example, full interoperability can be achieved with a relatively simple addition to their IM network. The MSN Messenger service would directly translate the Jabber XML to and from the native format at the server level, as well as ensuring that the MSN Messenger client software would be able to address non-native users (it already utilizes a user@host based format, which may enable interoperability without any changes to client software). The actual details of the translation depend on the native data format and accessibility within the network of servers, but the XML is well defined and functionality across both networks is similiar enough for an almost direct mapping. This level of interoperability enables all Jabber and MSN Messenger users to communicate instantly and transparently without modifying parts of either network. Miller Expires December 14, 2000 [Page 28] Internet-Draft Jabber June 2000 References [1] World Wide Web Consortium, "Extensible Markup Language (XML) 1.0", W3C xml, February 1998, . [2] University of Southern California, "Transmission Control Protocol", RFC 793, September 1981, . [3] The Jabber.org Project, "vCard XML", March 2000, . [4] Free Software Foundation, "GNU General Public License", June 1991, . [5] Free Software Foundation, "GNU Library General Public License", June 1991, . [6] Berners-Lee, T., Fielding, R.T. and L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1998, . [7] World Wide Web Consortium, "Namespaces in XML", W3C xml-names, January 1999, . [8] Freier, A., Karlton, P. and P. Kocher, "The SSL Protocol - Version 3.0", November 1996, . [9] Fielding, R., Gettys, J., Mogul, J., Frystyk, H. and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2068, January 1997, . [10] Kegel, D., "The C10K Problem", June 2000, . [11] Borenstein, N. and N. Freed, "MIME (Multipurpose Internet Mail Extensions) Part One: Mechanisms for Specifying and Describing the Format of Internet Message Bodies", RFC 1521, September 1993, . [12] Day, M., Rosenberg, J. and H. Sugano, "A Model for Presence and Instant Messaging", RFC 2778, February 2000, . [13] Day, M., Aggarwal, S., Mohr, G. and J. Vincent, "A Model for Presence and Instant Messaging", RFC 2779, February 2000, Miller Expires December 14, 2000 [Page 29] Internet-Draft Jabber June 2000 . [14] http://jabber.org [15] http://www.pgp.com [16] http://www.gnupg.org [17] http://www.syncml.org [18] http://www.xmledi-group.org/ [19] http://www.voicexml.org/ [20] http://www.wapforum.org/ Author's Address Jeremie Miller The Jabber.org Project 414 DeLong St. Cascade, IA 52033 US Phone: 319-852-3464 EMail: jeremie@jabber.org Miller Expires December 14, 2000 [Page 30] Internet-Draft Jabber June 2000 Appendix A. The Jabber Protocol DTD Miller Expires December 14, 2000 [Page 31] Internet-Draft Jabber June 2000 Miller Expires December 14, 2000 [Page 32] Internet-Draft Jabber June 2000 Appendix B. XML Streams DTD Miller Expires December 14, 2000 [Page 33] Internet-Draft Jabber June 2000 Appendix C. element A standard error element is used for failed processing of messages and iq. This element is a child of the failed element. C.1 Attributes o code - a numerical error code corresponding to a specific error description. The numerical codes used are nearly synchronous with HTTP error codes: * 302 - Redirect * 400 - Bad Request * 401 - Unauthorized * 402 - Payment Required * 403 - Forbidden * 404 - Not Found * 405 - Not Allowed * 406 - Not Acceptable * 407 - Registration Required * 408 - Request Timeout * 500 - Internal Server Error * 501 - Not Implemented * 502 - Remote Server Error * 503 - Service Unavailable * 504 - Remote Server Timeout Miller Expires December 14, 2000 [Page 34] Internet-Draft Jabber June 2000 C.2 Examples Message error: Angels and Ministers of Grace, defend us! Not Found IQ Error: hamlet hamlet@denmark gertrude 106c0a7b5510f192a408a1d054150ed1065e255a Remote Server Error Miller Expires December 14, 2000 [Page 35] Internet-Draft Jabber June 2000 Appendix D. Info/Query Namespaces Numerous Info/Query (Section 4.6) namespaces have been implemented to faciliate exchange of information between Jabber entities. Namespaces currently implemented within the Jabber server include: o Simple Client Authentication (jabber:iq:auth) o Agent Properties (jabber:iq:agent) o Registration Requests (jabber:iq:register) o Roster (Contact List) Management (jabber:iq:roster) o Available Agents List (jabber:iq:agents) o Out Of Band Data (jabber:iq:oob) o Client Time (jabber:iq:time) o Client Version (jabber:iq:version) o Temporary vCard (vcard-temp) Note that the Temporary vCard namespace is being used until the vCard XML standard has been finalized. The following subsections describe the three most fundamental extensions. D.1 Simple Client Authentication - jabber:iq:auth The jabber:iq:auth namespaces provides a simple mechanism for clients to authenticate and create a resource representing their connection to the server. D.1.1 Children o username - the unique user name for this user. o password - the secret key or passphrase for the user account. o digest - send a password in a SHA1 hash instead of clear text password. o resource - unique value to represent current connection. Miller Expires December 14, 2000 [Page 36] Internet-Draft Jabber June 2000 D.1.2 Examples The following is a complete example of how a client authenticates with the server. Client sends user information: hamlet gertrude Castle Server confirms login: D.2 Roster (Contact List) Management - jabber:iq:roster Provides a simple method for server-side contact list management. Upon connecting to the server, clients should request for the roster using jabber:iq:roster. Since the roster may not be desirable for all clients (e.g., cellular phone client), the client request of the roster is optional. D.2.1 Children o item - a specific roster item (contact) has the following attributes: * jid - the complete JID (Jabber ID) of the user that this item represents * subscription - the current status of the subscription related to this item. May have a value of: + none - no subscription. + from - this entity has a subscription to the user. + to - the user has a subscription to this entity. + both - subscription is both to and from. + remove - item is to be removed. * ask - the current status of a request to this item. May be one Miller Expires December 14, 2000 [Page 37] Internet-Draft Jabber June 2000 of: + subscription - the user is asking this item for a subscription. + unsubscription - the user is asking this item for an unsubscription. This element may contain one or more instances of the following element: * group - contains a user-specified user group name. D.2.2 Examples Client request for current roster: Server response to client query: Family Friends Miller Expires December 14, 2000 [Page 38] Internet-Draft Jabber June 2000 Client adding new items and modifying an entry: Visitors Visitors Family Royalty The server would then respond with the new roster information, plus an IQ result: Visitors Visitors Family Royalty D.3 Registration Request - jabber:iq:register Through jabber:iq:register, clients can register with the Jabber server itself or with new services. D.3.1 Children Note that while numerous fields are available, only the ones returned by the server are required for registration. o username o password Miller Expires December 14, 2000 [Page 39] Internet-Draft Jabber June 2000 o name o email o address o city o state o zip o phone o url o date o misc o text o instructions - contains server provided instructions for registration. o key - a unique key provided by the server, required for the entire registration process. D.3.2 Examples A complete example is provided in the IQ examples (Section 4.6.3). Miller Expires December 14, 2000 [Page 40] Internet-Draft Jabber June 2000 Appendix E. X Namespaces For sending information that does not require the IQ structure, the X namespace series has been implemented. Clients can use this type of namespace to send URLs, Roster (Contact List) items, Offline Options and other information. The following X namespaces have been implemented so far in the Jabber server: o Delay Logging (jabber:x:delay) o Out Of Band Data (File Transfers) (jabber:x:oob) o Embedded Roster Items (jabber:x:roster) E.1 Examples Sending an embedded roster item to a user: Visitors This message contains roster items. Visitors Visitors Miller Expires December 14, 2000 [Page 41] Internet-Draft Jabber June 2000 Appendix F. Acknowledgments While the entire Jabber.org team has been actively involved in the development of this protocol, the following individuals have significantly contributed: Eliot Landrum Thomas Muldowney Thomas Charron Julian Missig Peter Millard Miller Expires December 14, 2000 [Page 42] Internet-Draft Jabber June 2000 Full Copyright Statement Copyright (C) The Internet Society (2000). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Acknowledgement Funding for the RFC editor function is currently provided by the Internet Society. Miller Expires December 14, 2000 [Page 43]