Jabber ProtocolThe Jabber.org Project414 DeLong St.CascadeIA52033US319-852-3464jeremie@jabber.org
Internet
IMinstant messagingXMLExtensible 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:
MinimalisticEase of implementation, understanding, and manipulation.Independent of transport and mediumFuture 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 - Redirect400 - Bad Request401 - Unauthorized402 - Payment Required403 - Forbidden404 - Not Found405 - Not Allowed406 - Not Acceptable407 - Registration Required408 - Request Timeout500 - Internal Server Error501 - Not Implemented502 - Remote Server Error503 - Service Unavailable504 - Remote Server Timeout
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 dialogchat - Traditional two-way chat similiar to AIM or IRC CTCP Chatgroupchat - Group interface similar to an IRC channel with multiple participantsheadline - Ticker or active list of itemserror - 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.
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 .
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.
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.
usernamepasswordnameemailaddresscitystatezipphoneurldatemisctextinstructions - 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.
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 representssubscription -
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.
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)
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.
Extensible Markup Language (XML) 1.0World Wide Web ConsortiumXML StreamsThe Jabber.org ProjectGNU General Public LicenseFree Software FoundationGNU Library General Public LicenseFree Software FoundationA Model for Presence and Instant MessagingSightPath, Inc.mday@alum.mit.edudynamicsoftjdrosen@dynamicsoft.comFujitsu Laboratories Ltd.suga@flab.fujitsu.co.jpA Model for Presence and Instant MessagingSightPath, Inc.mday@alum.mit.eduMicrosoft Corporationsonuag@microsoft.comgojomo@usa.netInto Networks, Inc.jesse@intonet.comUniform Resource Identifiers (URI): Generic SyntaxWorld Wide Web Consortiumtimbl@w3.orgUniversity of California, Irvinefielding@ics.uci.eduXerox PARCmasinter@parc.xerox.comNamespaces in XMLWorld Wide Web ConsortiumXHTML 1.0: The Extensible HyperText Markup LanguageWorld 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 MuldowneyThomas CharronJulian MissigPeter Millard