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

Jabber Architechture
architechture

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 7, 2000.

Copyright Notice

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

Abstract

Fill in abstract here... This describes an Instant Messaging and Presence architecture as implemented by the Jabber.org Project.



 TOC 

Table of Contents




 TOC 

1. Introduction

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

1.1 Memo Goals

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

1.2 Jabber Goals

The goals of Jabber Architecture include:

Instant Messaging

Presence

Minimal implementation reqirements

Utilize XML as the payload format

Flexibility

Extensibility



 TOC 

2. Entity Identification

2.1 Three Tier

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

2.2 Host (server)

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

2.3 Node (user)

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.

2.4 Resource

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.



 TOC 

3. Client-Server

3.1 Transport Layer

XML Streams are used for all connections within Jabber.

3.2 Clients

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.

3.3 Servers

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.



 TOC 

4. Protocol

4.1 Authentication

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.

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

4.3 Roster

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

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

4.5 Presence Subscriptions

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

4.6 Server to Server

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.



 TOC 

5. Security Considerations

5.1 SSL

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

5.2 Client-Client

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

5.3 Client Connections

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.

5.4 Presence

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



 TOC 

6. Extended Functionality

6.1 Services (Agents/Transports)

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

6.2 File Transfers (OOB)

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

6.3 XML Medium

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.



 TOC 

7. Examples

7.1 Minimalistic Client

7.2 Basic Client

7.3 Extending



 TOC 

8. Future

8.1 Server Filtering

8.2 Devices and Presence

8.3 Services

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

8.4 HTTP

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



 TOC 

References

[1] World Wide Web Consortium, "Extensible Markup Language (XML) 1.0", W3C xml, February 1998.


 TOC 

Author's Address

  Jeremie Miller
  The Jabber.org Project
  414 DeLong St.
  Cascade, IA 52033
  US
Phone:  319-852-3464
EMail:  jeremie@jabber.org


 TOC 

Full Copyright Statement

Acknowledgement