[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00

Network Working Group                                          J. Miller
Internet-Draft                                    The Jabber.org Project
Expires: December 14, 2000                                 June 15, 2000


                                 Jabber
                                 jabber

                     draft-miller-impp-jabber-00.txt

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

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

Abstract

   This memo provides a comprehensive description of the Jabber
   architecture, design principles, and protocol.













Miller                 Expires December 14, 2000                [Page 1]


Internet-Draft                   Jabber                        June 2000


Table of Contents

   1.    Introduction . . . . . . . . . . . . . . . . . . . . . . . .  4
   1.1   What is Jabber?  . . . . . . . . . . . . . . . . . . . . . .  4
   1.2   Background and History . . . . . . . . . . . . . . . . . . .  4
   1.3   Evolution  . . . . . . . . . . . . . . . . . . . . . . . . .  4
   1.4   Today  . . . . . . . . . . . . . . . . . . . . . . . . . . .  5
   2.    Architecture Overview  . . . . . . . . . . . . . . . . . . .  6
   2.1   Server . . . . . . . . . . . . . . . . . . . . . . . . . . .  6
   2.2   Client . . . . . . . . . . . . . . . . . . . . . . . . . . .  6
   2.3   Transport  . . . . . . . . . . . . . . . . . . . . . . . . .  7
   3.    Entity Identification  . . . . . . . . . . . . . . . . . . .  8
   3.1   Three Tier . . . . . . . . . . . . . . . . . . . . . . . . .  8
   3.1.1 Host (server)  . . . . . . . . . . . . . . . . . . . . . . .  8
   3.1.2 Node (user)  . . . . . . . . . . . . . . . . . . . . . . . .  8
   3.1.3 Resource . . . . . . . . . . . . . . . . . . . . . . . . . .  8
   3.2   URI  . . . . . . . . . . . . . . . . . . . . . . . . . . . .  8
   4.    XML  . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
   4.1   Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 10
   4.2   Namespaces . . . . . . . . . . . . . . . . . . . . . . . . . 10
   4.3   Validation . . . . . . . . . . . . . . . . . . . . . . . . . 10
   4.4   <message> element  . . . . . . . . . . . . . . . . . . . . . 10
   4.4.1 Attributes . . . . . . . . . . . . . . . . . . . . . . . . . 10
   4.4.2 Children . . . . . . . . . . . . . . . . . . . . . . . . . . 11
   4.4.3 Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 11
   4.5   <presence> element . . . . . . . . . . . . . . . . . . . . . 12
   4.5.1 Attributes . . . . . . . . . . . . . . . . . . . . . . . . . 12
   4.5.2 Children . . . . . . . . . . . . . . . . . . . . . . . . . . 13
   4.5.3 Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 13
   4.6   <iq> element . . . . . . . . . . . . . . . . . . . . . . . . 13
   4.6.1 Attributes . . . . . . . . . . . . . . . . . . . . . . . . . 13
   4.6.2 Children . . . . . . . . . . . . . . . . . . . . . . . . . . 14
   4.6.3 Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 14
   5.    Client Access  . . . . . . . . . . . . . . . . . . . . . . . 16
   5.1   TCP Socket . . . . . . . . . . . . . . . . . . . . . . . . . 16
   5.2   Transport Layer  . . . . . . . . . . . . . . . . . . . . . . 16
   5.3   Authentication . . . . . . . . . . . . . . . . . . . . . . . 16
   5.4   Messages . . . . . . . . . . . . . . . . . . . . . . . . . . 16
   5.5   Presence . . . . . . . . . . . . . . . . . . . . . . . . . . 16
   5.6   Roster . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
   5.7   Presence Subscriptions . . . . . . . . . . . . . . . . . . . 17
   6.    Servers  . . . . . . . . . . . . . . . . . . . . . . . . . . 18
   6.1   Connections  . . . . . . . . . . . . . . . . . . . . . . . . 18
   6.2   DNS  . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
   7.    Security Considerations  . . . . . . . . . . . . . . . . . . 19
   7.1   SSL  . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
   7.2   Secure Identity and Encryption . . . . . . . . . . . . . . . 19
   7.3   Client Connections . . . . . . . . . . . . . . . . . . . . . 19
   7.4   Presence . . . . . . . . . . . . . . . . . . . . . . . . . . 19


Miller                 Expires December 14, 2000                [Page 2]


Internet-Draft                   Jabber                        June 2000


   8.    Scaling Considerations . . . . . . . . . . . . . . . . . . . 20
   8.1   TCP Sockets  . . . . . . . . . . . . . . . . . . . . . . . . 20
   8.2   Server Farms . . . . . . . . . . . . . . . . . . . . . . . . 20
   8.3   Client Optimizations . . . . . . . . . . . . . . . . . . . . 20
   8.4   Server Restrictions  . . . . . . . . . . . . . . . . . . . . 20
   9.    Extended Functionality . . . . . . . . . . . . . . . . . . . 21
   9.1   Services (Agents/Transports) . . . . . . . . . . . . . . . . 21
   9.2   MIME Transfers . . . . . . . . . . . . . . . . . . . . . . . 21
   9.3   XML Medium . . . . . . . . . . . . . . . . . . . . . . . . . 21
   9.4   Session Initialization . . . . . . . . . . . . . . . . . . . 22
   9.5   Client Access  . . . . . . . . . . . . . . . . . . . . . . . 22
   10.   Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 23
   10.1  Minimal Client . . . . . . . . . . . . . . . . . . . . . . . 23
   10.2  Basic Client . . . . . . . . . . . . . . . . . . . . . . . . 23
   10.3  Extending  . . . . . . . . . . . . . . . . . . . . . . . . . 25
   11.   IMPP and Interoperability Notes  . . . . . . . . . . . . . . 28
   11.1  Requirements Conformance . . . . . . . . . . . . . . . . . . 28
   11.2  Interoperability . . . . . . . . . . . . . . . . . . . . . . 28
         References . . . . . . . . . . . . . . . . . . . . . . . . . 29
         Author's Address . . . . . . . . . . . . . . . . . . . . . . 30
   A.    The Jabber Protocol DTD  . . . . . . . . . . . . . . . . . . 31
   B.    XML Streams DTD  . . . . . . . . . . . . . . . . . . . . . . 33
   C.    <error> element  . . . . . . . . . . . . . . . . . . . . . . 34
   C.1   Attributes . . . . . . . . . . . . . . . . . . . . . . . . . 34
   C.2   Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 35
   D.    Info/Query Namespaces  . . . . . . . . . . . . . . . . . . . 36
   D.1   Simple Client Authentication - jabber:iq:auth  . . . . . . . 36
   D.1.1 Children . . . . . . . . . . . . . . . . . . . . . . . . . . 36
   D.1.2 Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 37
   D.2   Roster (Contact List) Management - jabber:iq:roster  . . . . 37
   D.2.1 Children . . . . . . . . . . . . . . . . . . . . . . . . . . 37
   D.2.2 Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 38
   D.3   Registration Request - jabber:iq:register  . . . . . . . . . 39
   D.3.1 Children . . . . . . . . . . . . . . . . . . . . . . . . . . 39
   D.3.2 Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 40
   E.    X Namespaces . . . . . . . . . . . . . . . . . . . . . . . . 41
   E.1   Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 41
   F.    Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . 42
         Full Copyright Statement . . . . . . . . . . . . . . . . . . 43












Miller                 Expires December 14, 2000                [Page 3]


Internet-Draft                   Jabber                        June 2000


1. Introduction

1.1 What is Jabber?

   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.

1.2 Background and History

   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.

1.3 Evolution

   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,


Miller                 Expires December 14, 2000                [Page 4]


Internet-Draft                   Jabber                        June 2000


   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.).

1.4 Today

   After two years of full-time development by a large group of
   individuals around the world:

   o  The abstraction layer and all APIs are fully implemented.

   o  The XML data types are well defined (Appendix A).

   o  Clients for all major platforms and environments are available or
      being developed. See http://jabbercentral.com/clients/ for a
      database of popular clients.

   o  The GPL[4]/LGPL[5] licensed Jabber Server[14] is fully functional.

   o  Numerous working server-side components (transports) exist or are
      in public development for popular services such as ICQ, AOL IM,
      Microsoft Messenger, Yahoo! Messenger, IRC, SMTP, RSS (news
      headlines), and more.

   See http://jabber.org/ for more information.












Miller                 Expires December 14, 2000                [Page 5]


Internet-Draft                   Jabber                        June 2000


2. Architecture Overview

   Connection Map

            T1 = N1 = C3
           /
   C1 -- S1 - S2 = C4
        /  \
   C2 -     T2


   Above is a map of the typical connections within the Jabber
   Architecture.

   o  "-" represents the Jabber XML Protocol.

   o  "=" represents any other protocol.

   o  C1, C2 - Jabber Clients.

   o  C3 - Client on another IM Network.

   o  C4 - Client using an alternate protocol to access the Jabber
      Server.

   o  S1 - a Jabber Server.

   o  T1 - Transport, translating between the Jabber XML Protocol and
      the protocol used on another IM Network.

   o  T2 - Transport providing other real-time data to Jabber, such as
      log notifications or headline news feeds.

   o  N1 - third party IM Network.

2.1 Server

   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.

2.2 Client

   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


Miller                 Expires December 14, 2000                [Page 6]


Internet-Draft                   Jabber                        June 2000


   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.

2.3 Transport

   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.






































Miller                 Expires December 14, 2000                [Page 7]


Internet-Draft                   Jabber                        June 2000


3. Entity Identification

3.1 Three Tier

   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.

3.1.1 Host (server)

   The basic required component of every ID is a Host. The Host is a
   standard DNS hostname and not case sensitive.

3.1.2 Node (user)

   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.

3.1.3 Resource

   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.

3.2 URI

   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


Miller                 Expires December 14, 2000                [Page 8]


Internet-Draft                   Jabber                        June 2000


   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.













































Miller                 Expires December 14, 2000                [Page 9]


Internet-Draft                   Jabber                        June 2000


4. XML

4.1 Overview

   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.

4.2 Namespaces

   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.

4.3 Validation

   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.

4.4 <message> element

   Messages are most similar in function to an email message.

4.4.1 Attributes

   o  to - Specifies to whom the message is intended to be delivered
      to.

   o  from - Specifies the sender of the message. Server set to prevent
      spoofing.



Miller                 Expires December 14, 2000               [Page 10]


Internet-Draft                   Jabber                        June 2000


   o  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, similar to original ICQ
         messages.

      *  chat - Traditional two-way chat similar to AIM or IRC CTCP
         Chat.

      *  groupchat - Group interface similar to an IRC channel with
         multiple participants.

      *  headline - Ticker or active list of items (news, stock market).

      *  error - See the error element (Appendix C).

4.4.2 Children

   o  body - Contains the textual contents of the message for user
      display. No attributes.

   o  subject - Contains the subject of the message. Similar to an
      email subject. No attributes.

   o  thread - A random string generated by the originating client and
      copied back in replies. Used for tracking a conversation thread.

   o  error - See the error element (Appendix C).

4.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>
   </message>











Miller                 Expires December 14, 2000               [Page 11]


Internet-Draft                   Jabber                        June 2000


   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>

4.5 <presence> element

   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.

4.5.1 Attributes

   o  to - Specifies for whom the presence is bound. If none is
      specified, the server receives the presence.

   o  from - Whom the presence is from. Server set to prevent spoofing.

   o  id - A unique identifier for the presence. Sender of the presence
      sets this attribute.

   o  type - Describes the type of presence. No 'type' attribute
      implies "available" presence or current status. Allowable types
      include:

      *  unavailable - Signals that the user is no longer available.

      *  subscribe - An attempt to subscribe to the recipient's
         presence.

      *  subscribed - The sender has enabled the recipient to receive
         their presence.

      *  unsubscribe - An unsubscription request. The server handles
         the actual unsubscription, but clients receive a presence
         element for notification reasons.

      *  unsubscribed - The subscription has been cancelled.

      *  probe - A server-to-server query to request an entity's
         current presence.





Miller                 Expires December 14, 2000               [Page 12]


Internet-Draft                   Jabber                        June 2000


4.5.2 Children

   o  show - Describes a user's exact availability. Must be one of:

      *  away - User is away from the client software 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).

   o  status - Custom availability message. Used in conjunction with
      the show element to give a detailed description of availability.

4.5.3 Examples

   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>

4.6 <iq> element

   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.

4.6.1 Attributes

   o  to - Specifies for whom the IQ is bound.

   o  from - Specifies from whom the IQ is sent. Server set to prevent
      spoofing.

   o  id - A unique identifier for the IQ for tracking the query
      exchange. Sender of the IQ sets this attribute, which is returned
      in the response.

   o  type - The 'type' attribute has several preset values. Each


Miller                 Expires December 14, 2000               [Page 13]


Internet-Draft                   Jabber                        June 2000


      indicates a distinct step within an IQ conversation.

      *  get - Indicates that the current query is a question or search
         for information.

      *  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 successful
         result.

      *  error - The query failed. See the error element (Appendix C).

4.6.2 Children

   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 Appendix D.

4.6.3 Examples

   The following examples are distinct parts of an IQ conversation for
   registration with jabber:iq:register (Appendix D.3) 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>







Miller                 Expires December 14, 2000               [Page 14]


Internet-Draft                   Jabber                        June 2000


   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>































Miller                 Expires December 14, 2000               [Page 15]


Internet-Draft                   Jabber                        June 2000


5. Client Access

5.1 TCP Socket

   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.

5.2 Transport Layer

   An XML Stream (Appendix B) 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.

5.3 Authentication

   The client initially sends an IQ packet over the XML Stream to the
   server with the jabber:iq:auth namespace (Appendix D.1). 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.

5.4 Messages

   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.

5.5 Presence

   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


Miller                 Expires December 14, 2000               [Page 16]


Internet-Draft                   Jabber                        June 2000


   the server.

5.6 Roster

   The client can send an IQ get with the jabber:iq:roster namespace
   (Appendix D.2) 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].

5.7 Presence Subscriptions

   Presence information is made available only to approved entites.
   This approval is managed by a simple subscription system, using the
   presence element (Section 4.5). 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"/>










Miller                 Expires December 14, 2000               [Page 17]


Internet-Draft                   Jabber                        June 2000


6. Servers

   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.

6.1 Connections

   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.

6.2 DNS

   All connections are made directly to the IP address of the hostname
   in the Entity Identifier (Section 3). 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).












Miller                 Expires December 14, 2000               [Page 18]


Internet-Draft                   Jabber                        June 2000


7. Security Considerations

7.1 SSL

   Servers can optionally support normal SSL[8] connections for added
   security on port 5223 for client connections and 5270 for server
   connections.

7.2 Secure Identity and Encryption

   Clients may optionally support signing and encrypting messages and
   presence by using PGP[15]/GnuPG[16].

   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.

7.3 Client Connections

   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.

7.4 Presence

   Presence subscriptions are enforced by the user's server. Only the
   approved entities are able to discover a user's availability.


















Miller                 Expires December 14, 2000               [Page 19]


Internet-Draft                   Jabber                        June 2000


8. Scaling Considerations

8.1 TCP Sockets

   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.

8.2 Server Farms

   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.

8.3 Client Optimizations

   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.

8.4 Server Restrictions

   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.





















Miller                 Expires December 14, 2000               [Page 20]


Internet-Draft                   Jabber                        June 2000


9. Extended Functionality

9.1 Services (Agents/Transports)

   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.

9.2 MIME Transfers

   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.

9.3 XML Medium

   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[17], XML/EDI[18], VoiceXML[19], 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.






Miller                 Expires December 14, 2000               [Page 21]


Internet-Draft                   Jabber                        June 2000


    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>

9.4 Session Initialization

   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.

9.5 Client Access

   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[20] 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.
























Miller                 Expires December 14, 2000               [Page 22]


Internet-Draft                   Jabber                        June 2000


10. Examples

   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.

10.1 Minimal 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>

10.2 Basic Client

   A basic client converation using presence, rosters (iq) and messages:

   SEND: <stream:stream
   SEND:   to="denmark"


Miller                 Expires December 14, 2000               [Page 23]


Internet-Draft                   Jabber                        June 2000


   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>


Miller                 Expires December 14, 2000               [Page 24]


Internet-Draft                   Jabber                        June 2000


   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.

10.3 Extending

   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>



Miller                 Expires December 14, 2000               [Page 25]


Internet-Draft                   Jabber                        June 2000


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


Miller                 Expires December 14, 2000               [Page 26]


Internet-Draft                   Jabber                        June 2000


   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>










































Miller                 Expires December 14, 2000               [Page 27]


Internet-Draft                   Jabber                        June 2000


11. IMPP and Interoperability Notes

11.1 Requirements Conformance

   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.

   o  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.

   o  RFC 2779, section 4.1, paragraph 10 - all MIME data is delivered
      via HTTP.

11.2 Interoperability

   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.


Miller                 Expires December 14, 2000               [Page 28]


Internet-Draft                   Jabber                        June 2000


References

   [1]   World Wide Web Consortium, "Extensible Markup Language (XML)
         1.0", W3C xml, February 1998,
         <http://www.w3.org/TR/1998/REC-xml-19980210>.

   [2]   University of Southern California, "Transmission Control
         Protocol", RFC 793, September 1981,
         <http://www.ietf.org/rfc/rfc0793.txt>.

   [3]   The Jabber.org Project, "vCard XML", March 2000,
         <http://protocol.jabber.org/vcard-temp/>.

   [4]   Free Software Foundation, "GNU General Public License", June
         1991, <http://www.gnu.org/copyleft/gpl.html>.

   [5]   Free Software Foundation, "GNU Library General Public
         License", June 1991, <http://www.gnu.org/copyleft/lgpl.html>.

   [6]   Berners-Lee, T., Fielding, R.T. and L. Masinter, "Uniform
         Resource Identifiers (URI): Generic Syntax", RFC 2396, August
         1998, <http://www.ietf.org/rfc/rfc2396.txt>.

   [7]   World Wide Web Consortium, "Namespaces in XML", W3C xml-names,
         January 1999,
         <http://www.w3.org/TR/1999/REC-xml-names-19990114/>.

   [8]   Freier, A., Karlton, P. and P. Kocher, "The SSL Protocol -
         Version 3.0", November 1996,
         <http://home.netscape.com/eng/ssl3/draft302.txt>.

   [9]   Fielding, R., Gettys, J., Mogul, J., Frystyk, H. and T.
         Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC
         2068, January 1997, <http://www.ietf.org/rfc/rfc2068.txt>.

   [10]  Kegel, D., "The C10K Problem", June 2000,
         <http://www.kegel.com/c10k.html>.

   [11]  Borenstein, N. and N. Freed, "MIME (Multipurpose Internet Mail
         Extensions) Part One: Mechanisms for Specifying and Describing
         the Format of Internet Message Bodies", RFC 1521, September
         1993, <http://www.ietf.org/rfc/rfc1521.txt>.

   [12]  Day, M., Rosenberg, J. and H. Sugano, "A Model for Presence
         and Instant Messaging", RFC 2778, February 2000,
         <http://www.ietf.org/rfc/rfc2778.txt>.

   [13]  Day, M., Aggarwal, S., Mohr, G. and J. Vincent, "A Model for
         Presence and Instant Messaging", RFC 2779, February 2000,


Miller                 Expires December 14, 2000               [Page 29]


Internet-Draft                   Jabber                        June 2000


         <http://www.ietf.org/rfc/rfc2779.txt>.

   [14]  http://jabber.org

   [15]  http://www.pgp.com

   [16]  http://www.gnupg.org

   [17]  http://www.syncml.org

   [18]  http://www.xmledi-group.org/

   [19]  http://www.voicexml.org/

   [20]  http://www.wapforum.org/


Author's Address

   Jeremie Miller
   The Jabber.org Project
   414 DeLong St.
   Cascade, IA  52033
   US

   Phone: 319-852-3464
   EMail: jeremie@jabber.org
























Miller                 Expires December 14, 2000               [Page 30]


Internet-Draft                   Jabber                        June 2000


Appendix A. The Jabber Protocol DTD

   <!--
       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)>


Miller                 Expires December 14, 2000               [Page 31]


Internet-Draft                   Jabber                        June 2000


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





































Miller                 Expires December 14, 2000               [Page 32]


Internet-Draft                   Jabber                        June 2000


Appendix B. XML Streams DTD

   <!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)>








































Miller                 Expires December 14, 2000               [Page 33]


Internet-Draft                   Jabber                        June 2000


Appendix C. <error> element

   A standard error element is used for failed processing of messages
   and iq. This element is a child of the failed element.

C.1 Attributes

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











Miller                 Expires December 14, 2000               [Page 34]


Internet-Draft                   Jabber                        June 2000


C.2 Examples

   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>































Miller                 Expires December 14, 2000               [Page 35]


Internet-Draft                   Jabber                        June 2000


Appendix D. Info/Query Namespaces

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

   o  Simple Client Authentication (jabber:iq:auth)

   o  Agent Properties (jabber:iq:agent)

   o  Registration Requests (jabber:iq:register)

   o  Roster (Contact List) Management (jabber:iq:roster)

   o  Available Agents List (jabber:iq:agents)

   o  Out Of Band Data (jabber:iq:oob)

   o  Client Time (jabber:iq:time)

   o  Client Version (jabber:iq:version)

   o  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.

D.1 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.

D.1.1 Children

   o  username - the unique user name for this user.

   o  password - the secret key or passphrase for the user account.

   o  digest - send a password in a SHA1 hash instead of clear text
      password.

   o  resource - unique value to represent current connection.





Miller                 Expires December 14, 2000               [Page 36]


Internet-Draft                   Jabber                        June 2000


D.1.2 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">
       <username>hamlet</username>
       <password>gertrude</password>
        <resource>Castle</resource>
     </query>
   </iq>

   Server confirms login:

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

D.2 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.

D.2.1 Children

   o  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 entity has a subscription to the user.

         +  to - the user has a subscription to this entity.

         +  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


Miller                 Expires December 14, 2000               [Page 37]


Internet-Draft                   Jabber                        June 2000


         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 instances of the following
      element:

      *  group - contains a user-specified user group name.

D.2.2 Examples

   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>

















Miller                 Expires December 14, 2000               [Page 38]


Internet-Draft                   Jabber                        June 2000


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

D.3 Registration Request - jabber:iq:register

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

D.3.1 Children

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

   o  username

   o  password


Miller                 Expires December 14, 2000               [Page 39]


Internet-Draft                   Jabber                        June 2000


   o  name

   o  email

   o  address

   o  city

   o  state

   o  zip

   o  phone

   o  url

   o  date

   o  misc

   o  text

   o  instructions - contains server provided instructions for
      registration.

   o  key - a unique key provided by the server, required for the
      entire registration process.

D.3.2 Examples

   A complete example is provided in the IQ examples (Section 4.6.3).




















Miller                 Expires December 14, 2000               [Page 40]


Internet-Draft                   Jabber                        June 2000


Appendix E. 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 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:

   o  Delay Logging (jabber:x:delay)

   o  Out Of Band Data (File Transfers) (jabber:x:oob)

   o  Embedded Roster Items (jabber:x:roster)

E.1 Examples

   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>

























Miller                 Expires December 14, 2000               [Page 41]


Internet-Draft                   Jabber                        June 2000


Appendix F. Acknowledgments

   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




































Miller                 Expires December 14, 2000               [Page 42]


Internet-Draft                   Jabber                        June 2000


Full Copyright Statement

   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.

Acknowledgement

   Funding for the RFC editor function is currently provided by the
   Internet Society.



















Miller                 Expires December 14, 2000               [Page 43]


Html markup produced by rfcmarkup 1.124, available from https://tools.ietf.org/tools/rfcmarkup/