| TOC |
|
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 (C) The Internet Society (2000). All Rights Reserved.
This memo provides a comprehensive description of the Jabber architecture, design principles, and protocol.
| TOC |
| TOC |
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.
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.
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, 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.).
After two years of full-time development by a large group of individuals around the world:
| TOC |
Connection Map
T1 = N1 = C3
/
C1 -- S1 - S2 = C4
/ \
C2 - T2
Above is a map of the typical connections within the Jabber Architecture.
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.
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 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.
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.
| TOC |
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.
The basic required component of every ID is a Host. The Host is a standard DNS hostname and not case sensitive.
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.
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.
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 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.
| TOC |
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.
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.
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.
Messages are most similar in function to an email message.
The following examples have been server processed and contain the 'from' attribute.
A simple message:
<message to="horatio@denmark" from="hamlet@denmark"> <body>Angels and Ministers of Grace, defend us!</body> </message>
Complete chat message:
<message to="hamlet@denmark" from="horatio@denmark" type="chat"> <subject>Plotting</subject> <body>Here, sweet lord, at your service.</body> <thread>100052</thread> </message>
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.
Initial presence sent to server upon login to express default availability:
<presence/>
Full-blown presence:
<presence from="hamlet@denmark"> <show>xa</show> <status>Gone to England</status> </presence>
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.
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 Info/Query Namespaces.
The following examples are distinct parts of an IQ conversation for registration with jabber:iq:register namespace.
Client request for registration information to a server service (service.denmark):
<iq type="get" id="1001" to="service.denmark"> <query xmlns="jabber:iq:register"/> </iq>
Server response with registration fields required:
<iq type="result" from="service.denmark" to="hamlet@denmark" id="1001">
<query xmlns="jabber:iq:register">
<instructions>Choose a username and password to register with this server.</instructions>
<name/>
<email/>
<password/>
<key>106c0a7b5510f192a408a1d054150ed1065e255a</key>
</query>
</iq>
Client request to register for an account:
<iq type="set" to="service.denmark" from="hamlet@denmark" id="1002">
<query xmlns="jabber:iq:register">
<name>hamlet</name>
<email>hamlet@denmark</email>
<password>gertrude</password>
<key>106c0a7b5510f192a408a1d054150ed1065e255a</key>
</query>
</iq>
Successful registration:
<iq type="result" from="service.denmark" to="hamlet@denmark" id="1002"/>
Failed registration:
<iq type="error" from="service.denmark" to="hamlet@denmark" id="1002"/> <error code="406">Not Acceptable</error> </iq>
| TOC |
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.
An XML Stream 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.
The client initially sends an IQ packet over the XML Stream to the server with the jabber:iq:auth namespace. 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.
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.
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 the server.
The client can send an IQ get with the jabber:iq:roster namespace 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].
Presence information is made available only to approved entites. This approval is managed by a simple subscription system, using the presence element. 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:
<presence to="horatio@denmark" type="subscribe"/>
Response to a subscribe request:
<presence to="hamlet@denmark" type="subscribed"/>
| TOC |
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.
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.
All connections are made directly to the IP address of the hostname in the Entity Identifier. 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).
| TOC |
Servers can optionally support normal SSL[8] connections for added security on port 5223 for client connections and 5270 for server connections.
Clients may optionally support signing and encrypting messages and presence by using PGP/GnuPG.
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.
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.
Presence subscriptions are enforced by the user's server. Only the approved entities are able to discover a user's availability.
| TOC |
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.
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.
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.
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.
| TOC |
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.
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.
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, XML/EDI, VoiceXML, 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.
A message with some custom XML included
<message to="horatio@denmark" from="hamlet@denmark">
<body>Angels and Ministers of Grace, defend us!</body>
<foo xmlns="http://www.foo.org/">
<bar>ab<fb/>cd</bar>
</foo>
</message>
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.
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 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.
| TOC |
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.
A simple example:
SEND: <stream:stream SEND: to="denmark" SEND: xmlns="jabber:client" SEND: xmlns:stream="http://etherx.jabber.org/streams"> RECV: <stream:stream RECV: from="denmark" RECV: id="1001" RECV: xmlns="jabber:client" RECV: xmlns:stream="http://etherx.jabber.org/streams"> SEND: <iq id="1001" type="set"> SEND: <query xmlns="jabber:iq:auth"> SEND: <username>hamlet</username> SEND: <password>gertrude</password> SEND: <resource>Castle</resource> SEND: </query> SEND: </iq> RECV: <iq id="1001" type="result"/> SEND: <message to="horatio@denmark"> SEND: <body>The air bites shrewdly; it is very cold.</body> SEND: </message> RECV: <message to="hamlet@denmark" from="horatio@denmark> RECV: <body>It is nipping and an eager air.</body> RECV: </message> SEND: </stream:stream> RECV: </stream:stream>
A basic client converation using presence, rosters (iq) and messages:
SEND: <stream:stream SEND: to="denmark" SEND: xmlns="jabber:client" SEND: xmlns:stream="http://etherx.jabber.org/streams"> RECV: <stream:stream RECV: from="denmark" RECV: id="1001" RECV: xmlns="jabber:client" RECV: xmlns:stream="http://etherx.jabber.org/streams"> SEND: <iq id="1001" type="set"> SEND: <query xmlns="jabber:iq:auth"> SEND: <username>hamlet</username> SEND: <password>gertrude</password> SEND: <resource>Castle</resource> SEND: </query> SEND: </iq> RECV: <iq id="1001" type="result"/> SEND: <iq id="1002" type="get"> SEND: <query xmlns="jabber:iq:roster"/> SEND: </iq> RECV: <iq id="1002" type="result"> RECV: <query xmlns="jabber:iq:roster> RECV: <item jid="gertrude@denmark" name="Mother" subscription="both"/> RECV: <item jid="polonius@denmark" subscription="both"/> RECV: <item jid="horatio@denmark" name="Horatio" subscription="both"> RECV: <group>Friends</group> RECV: </item> RECV: </query> RECV: </iq> SEND: <presence/> RECV: <presence from="polonius@denmark/work" to="hamlet@denmark"> RECV: <show>chat</show> RECV: </presence> RECV: <message from="polonius@denmark" to="hamlet@denmark"> RECV: <body>How does my good Lord Hamlet?</body> RECV: </message> SEND: <message to="polonius@denmark"> SEND: <body>Well, God-a-mercy.</body> SEND: </message> RECV: <message from="polonius@denmark" to="hamlet@denmark"> RECV: <body>Do you know me, my lord?</body> RECV: </message> SEND: </stream:stream> RECV: </stream:stream>
Note that only polonius@denmark is online at this time, thus no presence was received from other roster items.
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: <stream:stream SEND: to="denmark" SEND: xmlns="jabber:client" SEND: xmlns:stream="http://etherx.jabber.org/streams"> RECV: <stream:stream RECV: from="denmark" RECV: id="1001" RECV: xmlns="jabber:client" RECV: xmlns:stream="http://etherx.jabber.org/streams"> SEND: <iq id="1001" type="set"> SEND: <query xmlns="jabber:iq:auth"> SEND: <username>hamlet</username> SEND: <password>gertrude</password> SEND: <resource>Courtyard</resource> SEND: </query> SEND: </iq> RECV: <iq id="1001" type="result"/> SEND: <iq id="1002" type="get"> SEND: <query xmlns="jabber:iq:roster"/> SEND: </iq> RECV: <iq id="1002" type="result"> RECV: <query xmlns="jabber:iq:roster> RECV: <item jid="gertrude@denmark" name="Mother" subscription="both"/> RECV: <item jid="polonius@denmark" subscription="both"/> RECV: <item jid="horatio@denmark" name="Horatio" subscription="both"> RECV: <group>Friends</group> RECV: </item> RECV: </query> RECV: </iq> SEND: <presence/> RECV: <presence from="polonius@denmark/work" to="hamlet@denmark"> RECV: <show>chat</show> RECV: </presence> RECV: <presence from="polonius@denmark/work" to="hamlet@denmark"> RECV: <show>away</show> RECV: <status>Busy with project.</status> RECV: </presence> RECV: <presence from="rosencrantz@denmark" to="hamlet@denmark" type="subscribe"/> RECV: <presence from="guildenstern@denmark" to="hamlet@denmark" type="subscribe"/> SEND: <presence to="rosencrantz@denmark" type="subscribed"/> SEND: <presence to="guildenstern@denmark" type="subscribed"/> RECV: <iq type="set"> RECV: <query xmlns="jabber:iq:roster"> RECV: <item jid="rosencrantz@denmark" subscription="from"/> RECV: </query> RECV: </iq> RECV: <iq type="set"> RECV: <query xmlns="jabber:iq:roster"> RECV: <item jid="guildenstern@denmark" subscription="from"/> RECV: </query> RECV: </iq> RECV: <presence from="rosencrantz@denmark/trip" to="hamlet@denmark"/> RECV: <presence from="guildenstern@denmark/palmpilot" to="hamlet@denmark"/> SEND: <message to="polonius@denmark"> SEND: <body>Well, God-a-mercy.</body> SEND: </message> RECV: <message from="guildenstern@denmark" to="hamlet@denmark"> RECV: <body>My honoured lord!</body> RECV: </message> RECV: <message from="rosencrantz@denmark" to="hamlet@denmark"> RECV: <body>My most dear lord!</body> RECV: </message> SEND: <iq id="1003" type="get" to="rosencrantz@denmark/trip"> SEND: <query xmlns="jabber:iq:version"/> SEND: </iq> RECV: <iq type="result" from="rosencrantz@denmark/trip" to="hamlet@denmark" id="1003"> RECV: <query xmlns="jabber:iq:version"> RECV: <name>Gabber</name> RECV: <version>0.6.1</version> RECV: <os>Debian GNU/Linux 2.2.16</os> RECV: </query> RECV: </iq> SEND: </stream:stream> RECV: </stream:stream>
| TOC |
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.
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.
| TOC |
| TOC |
| Jeremie Miller | |
| The Jabber.org Project | |
| 414 DeLong St. | |
| Cascade, IA 52033 | |
| US | |
| Phone: | 319-852-3464 |
| EMail: | jeremie@jabber.org |
| TOC |
<!--
Jabber XML DTD
By Julian "X-ViRGE" Missig
julian@linuxpower.org
-->
<!--=========== The Main Elements =============-->
<!-- jabber, the root element -->
<!-- note: the root element is not normally used due to the use of xmlstreams and namespaces -->
<!ELEMENT jabber ((presence | iq | message)*)>
<!-- presence, a subelement of jabber -->
<!ELEMENT presence ((status? | priority? | show?)*)>
<!ATTLIST presence
to CDATA #IMPLIED
from CDATA #IMPLIED
type (subscribe | subscribed | unsubscribe | unsubscribed | unavailable | probe) #IMPLIED
>
<!ELEMENT status (#PCDATA)>
<!ELEMENT priority (#PCDATA)>
<!ELEMENT show (#PCDATA)> <!-- standard options are: chat, away, xa and dnd -->
<!-- message, a subelement of jabber -->
<!ELEMENT message ((body? | error* | subject? | thread?)*)>
<!ATTLIST message
to CDATA #IMPLIED
from CDATA #IMPLIED
id ID
type (normal | error | chat | groupchat | headline) #IMPLIED
>
<!ELEMENT body (#PCDATA)>
<!ELEMENT error (#PCDATA)>
<!ATTLIST error
code CDATA #IMPLIED
>
<!ELEMENT subject (#PCDATA)>
<!ELEMENT thread (#PCDATA)>
<!ELEMENT x (#PCDATA)>
<!-- iq, a subelement of jabber -->
<!ELEMENT iq (#PCDATA)>
<!ATTLIST iq
to CDATA #IMPLIED
from CDATA #IMPLIED
id ID
type (get | set | result | error) #IMPLIED
>
| TOC |
<!ELEMENT stream (error?)> <!ATTLIST stream to CDATA #REQUIRED from CDATA #IMPLIED id CDATA #IMPLIED xmlns CDATA #REQUIRED xmlns:stream CDATA #REQUIRED 'http://etherx.jabber.org/streams' > <!ELEMENT error (PCDATA)>
| TOC |
A standard error element is used for failed processing of messages and iq. This element is a child of the failed element.
Message error:
<message to="hamlet@denmark" from="horatio@denmark" type="error"> <body>Angels and Ministers of Grace, defend us!</body> <error code="404">Not Found</error> </message>
IQ Error:
<iq type="error" from="service.denmark" to="hamlet@denmark" id="1002">
<query xmlns="jabber:iq:register">
<name>hamlet</name>
<email>hamlet@denmark</email>
<password>gertrude</password>
<key>106c0a7b5510f192a408a1d054150ed1065e255a</key>
</query>
<error code="502">Remote Server Error</error>
</iq>
| TOC |
Numerous Info/Query namespaces have been implemented to faciliate exchange of information between Jabber entities. Namespaces currently implemented within the Jabber server include:
The following subsections describe the three most fundamental extensions.
The jabber:iq:auth namespaces provides a simple mechanism for clients to authenticate and create a resource representing their connection to the server.
The following is a complete example of how a client authenticates with the server.
Client sends user information:
<iq type="set" id="1001">
<query xmlns="jabber:iq:auth">
<username>hamlet</username>
<password>gertrude</password>
<resource>Castle</resource>
</query>
</iq>
Server confirms login:
<iq type="result" id="1001"/>
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.
Client request for current roster:
<iq type="get" id="1001"> <query xmlns="jabber:iq:roster"/> </iq>
Server response to client query:
<iq type="result" id="1001">
<query xmlns="jabber:iq:roster">
<item jid="claudius@denmark" name="Uncle Claudius" subscription="from">
<group>Family</group>
</item>
<item jid="horatio@denmark" name="Horatio" subscription="both">
<group>Friends</group>
</item>
<item jid="fortinbras@norway" name="Prince Fortinbras" subscription="none" ask="subscribe"/>
</query>
</iq>
Client adding new items and modifying an entry:
<iq type="set" id="1002">
<query xmlns="jabber:iq:roster">
<item name="Rosencrantz" jid="rosencrantz@denmark">
<group>Visitors</group>
</item>
<item name="Guildenstern" jid="guildenstern@denmark">
<group>Visitors</group>
</item>
<item jid="claudius@denmark" name="King Claudius">
<group>Family</group>
<group>Royalty</group>
</item>
</group>
</iq>
The server would then respond with the new roster information, plus an IQ result:
<iq type="set">
<query xmlns="jabber:iq:roster">
<item jid="rosencrantz@denmark" name="Rosencrantz">
<group>Visitors</group>
</item>
<item jid="guildenstern@denmark" name="Guildenstern" >
<group>Visitors</group>
</item>
<item jid="claudius@denmark" name="King Claudius">
<group>Family</group>
<group>Royalty</group>
</item>
</group>
</iq>
<iq type="result" id="1002"/>
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.
A complete example is provided in the IQ examples.
| TOC |
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:
Sending an embedded roster item to a user:
<message to="hamlet@denmark" from="horatio@denmark">
<subject>Visitors</subject>
<body>This message contains roster items.</body>
<x xmlns="jabber:x:roster">
<item jid="rosencrantz@denmark" name="Rosencrantz"><group>Visitors</group></item>
<item jid="guildenstern@denmark" name="Guildenstern"><group>Visitors</group></item>
</x>
</message>
| TOC |
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
| TOC |
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.
Funding for the RFC editor function is currently provided by the Internet Society.