The Jabber.org Project

414 DeLong St. Cascade IA 52033 US 319-852-3464 jeremie@jabber.org

Internet IM instant messaging XML Extensible Markup Language This memo presents an easily extendable XML protocol for Instant Messaging and Presence.

This memo describes an XML protocol (referred to as the "Jabber protocol") for structured instant communication between Internet entities using XML Streams. The protocol described in this memo is not theoretical. All aspects of the protocol discussed in this memo have been implemented in the GPL/LGPL licensed Jabber Server.

The goals of this memo are to accuratly describe the implemented Jabber protocol and to provide short real-world examples. Furthermore, this memo aims to point out areas in which the protocol may be extended by future developement or third parties.

The major goals of the Jabber protocol include: Minimalistic Ease of implementation, understanding, and manipulation. Independent of transport and medium Future extensibility with little or no modification by client applications. Platform independence. The protocol should not be dependent in any way upon a certain operating system platform.

The implemented protocol presented in this memo is in near conformance to RFC 2778, "A Model for Presence and Instant Messaging" and RFC 2779, "Instant Messaging / Presence Protocol Requirements." Notable exceptions to non-conformance are outlined in the following subsection. It should be noted that the Jabber protocol has been in evolution for approxiamtly two years as of the date of this memo, thus this protocol has not been designed in response to RFCs 2778 and 2779.

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. RFC 2779, section 4.1, paragraph 10 regarding message formats based on MIME. RFC 2779, section 4.2 - Reliability. This type of guarantee of reliability can be obtained by creating a message structure based on the Info/Query structure.

All of the main elements (message, iq, and presence) return error messages using a standard error method.

code - a numerical error code coorisponding 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

Message error: Angels and Ministers of Grace, defend us! Remote Server Error ]]>

Presence error: Redirect ]]>

IQ Error: hamlet hamlet@denmark gertrude 106c0a7b5510f192a408a1d054150ed1065e255a Remote Server Error ]]>

The message structure is for sending regular instant messages between entities. Several message types are defined within the attributes. In use, this element is analogous to an email message.

to - Specifies to whom the messages is intended to be delivered to. from - Specifies the sender of the message. 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 chat - Traditional two-way chat similiar to AIM or IRC CTCP Chat groupchat - Group interface similar to an IRC channel with multiple participants headline - Ticker or active list of items error - See the error element.

body - Contains the textual contents of the message for user display. No attributes. subject - Contains the subject of the message. Similar to an email subject. No attributes. thread - A random string generated by the originating client and copied back in replies. Used for tracking a conversation thread. error - See the error element.

The following examples have been server processed and contain the from attribute.

A simple message: Angels and Ministers of Grace, defend us! ]]>

Complete chat message: Plotting Here, sweet lord, at your service. 100052 ]]>

The presence element allows for entities to express exact presence information (online, offline, away, etc.) to "subscribed" (authorized) users. The server keeps track of who is authorized to view an entity's status and to whom presence updates need to be sent to.

to - Specifies to whome the presence is bound for. If none is specified, the server receives the presence. from - Who the presence is from. id - A unique identifier for the presence. Sender of the presence sets this attribute. type - Describes the type of presence. Allowable types include: available - Default. Signals that the user is online. unavailable - Signals that the user is no longer available. Allows for offline options to be set (usually with x element extensions, see ). subscribe - An attempt to subscribe to a user's presence. subscribed - The subscribe attempt was successful. unsubscribe - An unsubscription request. The server handles the actual unsubscription, but clients receive for notification reasons. unsubscribed - A presence unsubscribe completed succesfully. probe - A query to a user's presence. This is used server-side only. error - See the error element.

show - Describes a user's exact availability. Must be one of: away - User is away from the client 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). status - Availability message. Used in conjunction with the show element to give a custom description of availability. May also be extended with the x element. See .

Initial presence sent to server upon login: ]]>

Request to subscribe to a user's presence: ]]>

Response to a subscribe request: ]]>

Full blown presence: xa Gone to England ]]>

Info/Query is a simple "client/server" framework within the protocol. It structures a rudimentary conversation between any two entities and allows them to pass XML formatted queries and responses back and forth.

to - Specifies to whom the IQ is bound for. from - Specifies from whom the IQ is from. id - A unique identifier for the IQ for tracking the query exchange. Sender of the IQ sets this attribute. type - The type attribute has several preset values. Each indicate a distinct step within an IQ converstation. get - Indicates that the current query is a question or search for information. Default, assumed if no value to the type attribute is given. error - The query failed. See the error element. 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 sucessful result.

In the strictest terms, the iq element contains no children. In operation, a query element is usually contained within the iq element. The query element is defined by its namespace. See .

The following examples are distinct parts of an IQ conversation for registration with jabber:iq:auth.

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 ]]>

Client request to register for an account. hamlet hamlet@denmark gertrude 106c0a7b5510f192a408a1d054150ed1065e255a ]]>

To extend the base protocol for new capabilities, the protocol makes extensive use of XML Namespaces.

Numerous Info/Query namespaces have been implemented to faciliate exchange of information between Jabber entities. Namespaces currently implemented within the Jabber server include: Simple Client Authentication (jabber:iq:auth) Agent Properties (jabber:iq:agent) Registration Requests (jabber:iq:register) Roster (Contact List) management (jabber:iq:roster) Available Agents List (jabber:iq:agents) Out Of Band Data (jabber:iq:oob) Client Time (jabber:iq:time) Client Version (jabber:iq:version) 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.

Through jabber:iq:register, clients can register with the Jabber server itself or with new services.

Note that while numerous fields are available, only the ones returned by the server are required for registration. username password name email address city state zip phone url date misc text instructions - contains server provided instructions for registration. key - a unique key provided by the server, required for the entire registration process.

A complete example is provided in the IQ examples.

The jabber:iq:auth namespaces provides a simple mechanism for clients to authenticate and create a resource representing their connection to the server.

username - the unique user name for this user. password - the secret key or passphrase for the user account. digest - send a password in a SHA1 hash instead of clear text password. resource - unique value to represent current connection.

The following is a complete example of how a client authenticates with the server.

Client sends user information: hamlet gertrude Castle ]]>

Server confirms login: ]]>

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.

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 item has a subscription to the user. to - the user has a subscription to this item. 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 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 of the following element: group - contains a user-specified user group name.

Client request for current roster: ]]>

Server response to client query: Family Friends ]]>

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 ]]>

For sending information that does not require the IQ structure, the X namespace series has been implemented. Clients can use this type of namespaces to send URLs, Roster (Contact List) items, Offline Options and other information. The following X namespaces are implemented in the Jabber server: Offline Options (jabber:x:offline) Delay Logging (jabber:x:delay) Extended Identity/Routing Persistence (jabber:x:ident) Out Of Band Data (File Transfers) (jabber:x:oob) Embedded Roster Items (jabber:x:roster)

Sending an embedded roster item to a user: Visitors This message contains roster items. Visitors Visitors ]]>

Anyone can implement their own namespace extensions without breaking the protocol. If the extended data is properly presented (i.e. within an x element), the server will simply pass the extended information on to the client. Clients will ignore the extended data if they are not capable of understanding it.

For instance, the W3C's XHTML namespace could easily be implemented within a regular Jabber message: Plotting Here, sweet lord, at your service. 100052 ]]>

World Wide Web Consortium The Jabber.org Project Free Software Foundation Free Software Foundation SightPath, Inc.

mday@alum.mit.edu

dynamicsoft

jdrosen@dynamicsoft.com

Fujitsu Laboratories Ltd.

suga@flab.fujitsu.co.jp

SightPath, Inc.

mday@alum.mit.edu

Microsoft Corporation

sonuag@microsoft.com

gojomo@usa.net

Into Networks, Inc.

jesse@intonet.com

World Wide Web Consortium

timbl@w3.org

University of California, Irvine

fielding@ics.uci.edu

Xerox PARC

masinter@parc.xerox.com

World Wide Web Consortium World Wide Web Consortium

]]>

Of special note is Eliot Landrum <eliot@landrum.cx> who prepared and edited this specification memo. The entire Jabber.org team has been actively involved in the development of this protocol, yet the following individuals have directly contributed greatly to the evolution of the protocol. Thomas Muldowney Thomas Charron Julian Missig Peter Millard