| 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.
Fill in abstract here... This describes an Instant Messaging and Presence architecture as implemented by the Jabber.org Project.
| TOC |
| TOC |
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
| TOC |
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.
| TOC |
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.
| TOC |
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.
| TOC |
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.
| TOC |
... 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.
| TOC |
| TOC |
... 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
| TOC |
| [1] | World Wide Web Consortium, "Extensible Markup Language (XML) 1.0", W3C xml, February 1998. |
| TOC |
| Jeremie Miller | |
| The Jabber.org Project | |
| 414 DeLong St. | |
| Cascade, IA 52033 | |
| US | |
| Phone: | 319-852-3464 |
| EMail: | jeremie@jabber.org |
| 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.