Network Working Group J. Miller Internet-Draft The Jabber.org Project Expires: December 7, 2000 June 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. Miller Expires December 7, 2000 [Page 1] Internet-Draft Jabber Architechture June 2000 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1 Memo Goals . . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.2 Jabber Goals . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Entity Identification . . . . . . . . . . . . . . . . . . . . 4 2.1 Three Tier . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.2 Host (server) . . . . . . . . . . . . . . . . . . . . . . . . 4 2.3 Node (user) . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.4 Resource . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Client-Server . . . . . . . . . . . . . . . . . . . . . . . . 5 3.1 Transport Layer . . . . . . . . . . . . . . . . . . . . . . . 5 3.2 Clients . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.3 Servers . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 4. Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 4.1 Authentication . . . . . . . . . . . . . . . . . . . . . . . . 6 4.2 Messages . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 4.3 Roster . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 4.4 Presence . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 4.5 Presence Subscriptions . . . . . . . . . . . . . . . . . . . . 6 4.6 Server to Server . . . . . . . . . . . . . . . . . . . . . . . 6 5. Security Considerations . . . . . . . . . . . . . . . . . . . 7 5.1 SSL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 5.2 Client-Client . . . . . . . . . . . . . . . . . . . . . . . . 7 5.3 Client Connections . . . . . . . . . . . . . . . . . . . . . . 7 5.4 Presence . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 6. Extended Functionality . . . . . . . . . . . . . . . . . . . . 8 6.1 Services (Agents/Transports) . . . . . . . . . . . . . . . . . 8 6.2 File Transfers (OOB) . . . . . . . . . . . . . . . . . . . . . 8 6.3 XML Medium . . . . . . . . . . . . . . . . . . . . . . . . . . 8 7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 7.1 Minimalistic Client . . . . . . . . . . . . . . . . . . . . . 9 7.2 Basic Client . . . . . . . . . . . . . . . . . . . . . . . . . 9 7.3 Extending . . . . . . . . . . . . . . . . . . . . . . . . . . 9 8. Future . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 8.1 Server Filtering . . . . . . . . . . . . . . . . . . . . . . . 10 8.2 Devices and Presence . . . . . . . . . . . . . . . . . . . . . 10 8.3 Services . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 8.4 HTTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 11 Full Copyright Statement . . . . . . . . . . . . . . . . . . . 12 Miller Expires December 7, 2000 [Page 2] Internet-Draft Jabber Architechture June 2000 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 Miller Expires December 7, 2000 [Page 3] Internet-Draft Jabber Architechture June 2000 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. Miller Expires December 7, 2000 [Page 4] Internet-Draft Jabber Architechture June 2000 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. Miller Expires December 7, 2000 [Page 5] Internet-Draft Jabber Architechture June 2000 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. Miller Expires December 7, 2000 [Page 6] Internet-Draft Jabber Architechture June 2000 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. Miller Expires December 7, 2000 [Page 7] Internet-Draft Jabber Architechture June 2000 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. Miller Expires December 7, 2000 [Page 8] Internet-Draft Jabber Architechture June 2000 7. Examples 7.1 Minimalistic Client 7.2 Basic Client 7.3 Extending Miller Expires December 7, 2000 [Page 9] Internet-Draft Jabber Architechture June 2000 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 Miller Expires December 7, 2000 [Page 10] Internet-Draft Jabber Architechture June 2000 References [1] World Wide Web Consortium, "Extensible Markup Language (XML) 1.0", W3C xml, February 1998, . 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 7, 2000 [Page 11] Internet-Draft Jabber Architechture 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 7, 2000 [Page 12]