| 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 7, 2000.
Copyright (C) The Internet Society (2000). All Rights Reserved.
This memo presents an easily extendable XML[1] protocol for Instant Messaging and Presence.
| TOC |
| TOC |
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.
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:
| TOC |
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.
| TOC |
All of the main elements (message, iq, and presence) return error messages using a standard error method.
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> </message>
Presence error:
<presence to="hamlet@denmark" from="horatio@denmark" type="error"> <error code="302">Redirect</error> </presence>
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 |
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.
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>
| TOC |
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.
May also be extended with the x element. See Extensions Through Namespaces.
Initial presence sent to server upon login:
<presence/>
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"> <show>xa</show> <status>Gone to England</status> </presence>
| TOC |
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.
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.
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"/> </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>
| TOC |
To extend the base protocol for new capabilities, the protocol makes extensive use of XML Namespaces[8].
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.
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.
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"/>
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:
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>
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">
<subject>Plotting</subject>
<body>
<x xmlns:xhtml="http://www.w3.org/1999/xhtml">
<xhtml:body>
<xhtml:p style="font-size: 12pt; color: red;">
Here, sweet lord, at your service.
</xhtml:p>
</xhtml:body>
</x>
</body>
<thread>100052</thread>
</message>
| TOC |
| [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. |
| 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 -->
<!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 body (#PCDATA)>
<!ELEMENT error (#PCDATA)>
<!-- now using standard numerical error codes
http://docs.jabber.org/general/errorcodes/ -->
<!ATTLIST error
type 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 CDATA #IMPLIED
type (get | set | result | error) #IMPLIED
>
| TOC |
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
| 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.