Jabber Architechture

Insert Jabber introduction and background here... Define new medium that can carry any IM/P data converted from any protocol real-time to simple clients

(reword) This memo is intended to provide a structured document describing the Jabber architecture as implemented by the open-source Jabber.org Project.

The goals of Jabber Architecture include: Instant Messaging Presence Minimal implementation reqirements Utilize XML as the payload format Flexibility Extensibility

All entities are one of three types, a host, node, or resource.

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

Each Host can be addressed with individual Nodes, or users. Each user is specific to the Host it is associated with, similiar to email. Usernames are restricted to 255 characters, and the following ASCII characters are invalid: any less than 33 or in the following set [:@<>'"&]. Case is preserved, but not used when comparing/matching. A Node address looks similiar to email: node@host. Node addresses are intended to be human readable/usable.

Resources are specific to a Node. All characters are allowed and there are no restrictions. Resource addresses are similiar to the path part of a URL. (Resources are used to address specific connections, 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.

XML Streams are used for all connections within Jabber.

Clients connect with an XML Stream on port 5222 of the server. The default namespace for this stream is "jabber:client". 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 XML Stream.

Servers connect to each other with an XML Stream on port 5269. The default namespace for this stream is "jabber:server". The server connections are one-way stateless streams, only used to deliver data from one server to another. If the connection to the host fails, servers attempt a DNS MX record lookup, and utilize the MX records in reverse priority (highest number first), attempting to connect to each MX record.

The client initially sends an IQ packet over the XML Stream to the server with the jabber:iq:auth namespace. This provides the credentials to access the server, which are either returned with an error or accepted. After accepting the credentials, the XML Stream is then authorized to send data via those credentials and will receive data from the server over the XML Stream.

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.

The client can send an IQ get with the jabber:iq:roster namespace at any time, and will receive a result containing all the items that the server has stored for that user. Changes to any one item can be made by submitting that changed item via an IQ set in the same namespace. At any time, the server may do a "Roster Push" by sending an IQ set to the client containing the new/updated item[s].

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.

Fill in here, describing the subscribe/unsubscribe/subscribed/unsubscribed exchange.

Servers exchange all protocol data to another server with a qualified to and from attribute. There is no specific server state or exchange held, all data is simply routed to another server.

Servers can optionally support normal SSL connections on port 5223 for added security for client connections.

Clients may optionally support signing and encrypting messages and presence by using PGP/GPG.

The IP address of clients is never made available, nor are any connections other than the original client->server XML Stream required. This protects the client hosts from direct attack or identification by third parties, and allows the service provider to utilize an alternate protocol or provide another method of access to its clients.

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

... real-time generating/converting XML to/from alternate protocols or data formats. IQ for obtaining list of services from entities, IQ for registration/search with services.

... oob URI for all non-xml data. HTTP URL's for all file transfers. iq for live file xfer, message attachments...

Any XML can be inserted for any additional functionality at any point anywhere in the protocol. ... x:delay for showing delays in delivery, vCard, iq:private for a server, any custom application.

... real-time data services formatted in xml pushed to clients, calendars, alerts, news, collab tools, etc.

... HTTP methods for Jabber protocol, 3rd party http file xfers