Network Working GroupJ. Miller
Internet-DraftThe Project
Expires: December 7, 2000June 8, 2000

Jabber Protocol

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

The list of Internet-Draft Shadow Directories can be accessed at

This Internet-Draft will expire on December 7, 2000.

Copyright Notice

Copyright (C) The Internet Society (2000). All Rights Reserved.


This memo presents an easily extendable XML[1] protocol for Instant Messaging and Presence.


Table of Contents


1. Introduction

This memo describes an XML[1] protocol (referred to as the "Jabber protocol") for structured instant communication between Internet entities using XML Streams[2].

The protocol described in this memo is not theoretical. All aspects of the protocol discussed in this memo have been implemented in the GPL[3]/LGPL[4] licensed Jabber Server.

1.1 Memo Goals

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.

1.2 Protocol Goals

The major goals of the Jabber protocol include:


2. Conformance to RFC 2778 and RFC 2779

The implemented protocol presented in this memo is in near conformance to RFC 2778[5], "A Model for Presence and Instant Messaging" and RFC 2779[6], "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.

2.1 Exceptions to Conformance (needs additional wording)


3. The error Element

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

3.1 Attributes

3.2 Examples

Message error:

<message to="hamlet@denmark" from="horatio@denmark" type="error">
  <body>Angels and Ministers of Grace, defend us!</body>
  <error code="502">Remote Server Error</error>

Presence error:

<presence to="hamlet@denmark" from="horatio@denmark" type="error">
  <error code="302">Redirect</error>

IQ Error:

<iq type="error" from="service.denmark" to="hamlet@denmark" id="1002">
  <query xmlns="jabber:iq:register">
  <error code="502">Remote Server Error</error>


4. The message Element

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.

4.1 Attributes

4.2 Children

4.3 Examples

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>

Complete chat message:

<message to="hamlet@denmark" from="horatio@denmark" type="chat">
  <body>Here, sweet lord, at your service.</body>


5. The presence Element

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.

5.1 Attributes

5.2 Children

May also be extended with the x element. See Extensions Through Namespaces.

5.3 Examples

Initial presence sent to server upon login:


Request to subscribe to a user's presence:

<presence to="horatio@denmark" type="subscribe"/>

Response to a subscribe request:

<presence to="hamlet@denark type="subscribed"/>

Full blown presence:

<presence from="hamlet@denmark">
  <status>Gone to England</status>


6. The iq Element

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.

6.1 Attributes

6.2 Children

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 Extensions Through Namespaces.

6.3 Examples

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)

<iq type="get" id="1001" to="service.denmark">
  <query xmlns="jabber:iq:register"/>

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>

Client request to register for an account.

<iq type="set" to="service.denmark" from="hamlet@denmark" id="1002">
  <query xmlns="jabber:iq:register">


7. Extensions Through Namespaces

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

7.1 Info/Query Namespaces

Numerous Info/Query namespaces have been implemented to faciliate exchange of information between Jabber entities. Namespaces currently implemented within the Jabber server include:

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.

7.1.1 Registration Request - jabber:iq:register

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

Note that while numerous fields are available, only the ones returned by the server are required for registration. Examples

A complete example is provided in the IQ examples.

7.1.2 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. Children Examples

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

Server confirms login:

<iq type="result" id="1001"/>

7.1.3 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. Children Examples

Client request for current roster:

<iq type="get" id="1001">
  <query xmlns="jabber:iq:roster"/>

Server response to client query:

<iq type="result" id="1001">
  <query xmlns="jabber:iq:roster">
    <item jid="claudius@denmark" name="Uncle Claudius" subscription="from">
    <item jid="horatio@denmark" name="Horatio" subscription="both">
    <item jid="fortinbras@norway" name="Prince Fortinbras" subscription="none" ask="subscribe"/>

Client adding new items and modifying an entry:

<iq type="set" id="1002">
  <query xmlns="jabber:iq:roster">  
    <item name="Rosencrantz" jid="rosencrantz@denmark">
    <item name="Guildenstern" jid="guildenstern@denmark">
    <item jid="claudius@denmark" name="King Claudius">

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">
    <item jid="guildenstern@denmark" name="Guildenstern" >
    <item jid="claudius@denmark" name="King Claudius">
<iq type="result" id="1002"/>

7.2 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 namespaces to send URLs, Roster (Contact List) items, Offline Options and other information. The following X namespaces are implemented in the Jabber server:

7.2.1 Examples

Sending an embedded roster item to a user:

<message to="hamlet@denmark" from="horatio@denmark">
  <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>

7.3 Further Extensions

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[9] namespace could easily be implemented within a regular Jabber message:

<message to="hamlet@denmark" type="chat" from="horatio@denmark">
    <x xmlns:xhtml="">
        <xhtml:p style="font-size: 12pt; color: red;">
          Here, sweet lord, at your service.



[1] World Wide Web Consortium, "Extensible Markup Language (XML) 1.0", W3C xml, February 1998.
[2] Miller, J., "XML Streams", May 2000.
[3] Free Software Foundation, "GNU General Public License", June 1991.
[4] Free Software Foundation, "GNU Library General Public License", June 1991.
[5] Day, M., Rosenberg, J. and H. Sugano, "A Model for Presence and Instant Messaging", RFC 2778, February 2000.
[6] Day, M., Aggarwal, S., Mohr, G. and J. Vincent, "A Model for Presence and Instant Messaging", RFC 2779, February 2000.
[7] Berners-Lee, T., Fielding, R.T. and L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1998.
[8] World Wide Web Consortium, "Namespaces in XML", W3C xml-names, January 1999.
[9] World Wide Web Consortium, "XHTML 1.0: The Extensible HyperText Markup Language", W3C xhtml1, January 2000.


Author's Address

  Jeremie Miller
  The Project
  414 DeLong St.
  Cascade, IA 52033
Phone:  319-852-3464


Appendix A. The Jabber Protocol DTD

    Jabber XML DTD
    By Julian "X-ViRGE" Missig

<!--=========== The Main Elements =============-->

<!-- jabber, the root element -->
<!ELEMENT jabber (presence | iq | message)*>

<!-- presence, a subelement of jabber -->

<!ELEMENT presence (status? | priority? | show? | x*)*>
<!ATTLIST presence
  to          CDATA             #IMPLIED
  from	      CDATA		#IMPLIED
  type        (subscribe | subscribed | unsubscribe | unsubscribed | available | 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? | x* | error* | subject? | thread? | priority?)*>
<!ATTLIST message
  to          CDATA             #IMPLIED
  from        CDATA             #IMPLIED
  id          ID
  type	      (normal | error | chat | groupchat | headline) #IMPLIED


<!ELEMENT error (#PCDATA)>

<!-- now using standard numerical error codes -->

<!ATTLIST error
  type        CDATA        #IMPLIED

<!ELEMENT subject (#PCDATA)>

<!ELEMENT thread (#PCDATA)>


<!-- iq, a subelement of jabber -->

  to          CDATA        #IMPLIED
  from        CDATA        #IMPLIED
  id          CDATA	       #IMPLIED
  type	      (get | set | result | error)  #IMPLIED


Appendix B. Acknowledgments

Of special note is Eliot Landrum <> who prepared and edited this specification memo.

The entire 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


Full Copyright Statement