Network Working Group P. Saint-Andre
Internet-Draft J. Miller
Expires: October 26, 2003 Jabber Software Foundation
April 27, 2003
XMPP Instant Messaging
draft-ietf-xmpp-im-10
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 October 26, 2003.
Copyright Notice
Copyright (C) The Internet Society (2003). All Rights Reserved.
Abstract
This document describes the specific extensions to and applications
of the Extensible Messaging and Presence Protocol (XMPP) that are
required to create a basic instant messaging and presence
application, such as the servers and clients that comprise the Jabber
network.
Saint-Andre & Miller Expires October 26, 2003 [Page 1]
Internet-Draft XMPP Instant Messaging April 2003
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2 Requirements . . . . . . . . . . . . . . . . . . . . . . . . 4
1.3 Terminology . . . . . . . . . . . . . . . . . . . . . . . . 5
1.4 Discussion Venue . . . . . . . . . . . . . . . . . . . . . . 5
1.5 Intellectual Property Notice . . . . . . . . . . . . . . . . 5
2. Establishing a Session . . . . . . . . . . . . . . . . . . . 6
3. Exchanging Messages . . . . . . . . . . . . . . . . . . . . 8
3.1 Specifying an Intended Recipient . . . . . . . . . . . . . . 8
3.2 Specifying a Message Type . . . . . . . . . . . . . . . . . 8
3.3 Specifying a Message Body . . . . . . . . . . . . . . . . . 9
3.4 Specifying a Message Subject . . . . . . . . . . . . . . . . 9
3.5 Specifying a Conversation Thread . . . . . . . . . . . . . . 10
4. Exchanging Presence Information . . . . . . . . . . . . . . 11
4.1 Client and Server Responsibilities . . . . . . . . . . . . . 11
4.2 Sending Initial Presence . . . . . . . . . . . . . . . . . . 12
4.3 Specifying Availability Status . . . . . . . . . . . . . . . 12
4.4 Specifying Detailed Status Information . . . . . . . . . . . 12
4.5 Probing for Presence . . . . . . . . . . . . . . . . . . . . 13
4.6 Sending Final Presence . . . . . . . . . . . . . . . . . . . 13
4.7 Determining When a Contact Went Offline . . . . . . . . . . 13
5. Managing Subscriptions . . . . . . . . . . . . . . . . . . . 15
5.1 Requesting a Subscription . . . . . . . . . . . . . . . . . 15
5.2 Handling a Subscription Request . . . . . . . . . . . . . . 15
5.3 Cancelling a Subscription from Another Entity . . . . . . . 16
5.4 Unsubscribing from Another Entity's Presence . . . . . . . . 16
6. Managing One's Roster . . . . . . . . . . . . . . . . . . . 17
6.1 Retrieving One's Roster on Login . . . . . . . . . . . . . . 17
6.2 Adding a Roster Item . . . . . . . . . . . . . . . . . . . . 18
6.3 Deleting a Roster Item . . . . . . . . . . . . . . . . . . . 20
7. Integration of Roster Items and Presence Subscriptions . . . 21
7.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 21
7.2 User Subscribes to Contact . . . . . . . . . . . . . . . . . 21
7.2.1 Alternate Flow: Contact Declines Subscription Request . . . 24
7.3 Creating a Mutual Subscription . . . . . . . . . . . . . . . 25
7.3.1 Alternate Flow: User Declines Subscription Request . . . . . 27
7.4 Unsubscribing . . . . . . . . . . . . . . . . . . . . . . . 28
7.4.1 Case #1: Subscription Type 'to' . . . . . . . . . . . . . . 28
7.4.2 Case #2: Subscription Type 'both' . . . . . . . . . . . . . 30
7.5 Cancelling a Subscription . . . . . . . . . . . . . . . . . 32
7.5.1 Case #1: Subscription Type 'from' . . . . . . . . . . . . . 32
7.5.2 Case #2: Subscription Type 'both' . . . . . . . . . . . . . 33
7.6 Removing a Roster Item and Cancelling All Subscriptions . . 35
8. Blocking Communication . . . . . . . . . . . . . . . . . . . 36
8.1 Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
8.2 Business Rules . . . . . . . . . . . . . . . . . . . . . . . 38
Saint-Andre & Miller Expires October 26, 2003 [Page 2]
Internet-Draft XMPP Instant Messaging April 2003
8.3 Retrieving One's Privacy Lists . . . . . . . . . . . . . . . 39
8.4 Managing Active Lists . . . . . . . . . . . . . . . . . . . 42
8.5 Managing the Default List . . . . . . . . . . . . . . . . . 43
8.6 Editing a Privacy List . . . . . . . . . . . . . . . . . . . 44
8.7 Adding a New Privacy List . . . . . . . . . . . . . . . . . 45
8.8 Removing a Privacy List . . . . . . . . . . . . . . . . . . 45
8.9 Blocking Messages . . . . . . . . . . . . . . . . . . . . . 46
8.10 Blocking Inbound Presence Notifications . . . . . . . . . . 48
8.11 Blocking Outbound Presence Notifications . . . . . . . . . . 49
8.12 Blocking IQs . . . . . . . . . . . . . . . . . . . . . . . . 51
8.13 Blocking All Communication . . . . . . . . . . . . . . . . . 53
8.14 Blocked Entity Attempts to Communicate with User . . . . . . 54
8.15 Higher-Level Heuristics . . . . . . . . . . . . . . . . . . 55
9. Routing and Delivery Rules . . . . . . . . . . . . . . . . . 57
9.1 Client Generation of To Addresses . . . . . . . . . . . . . 57
9.2 Server Handling of XML Stanzas Addressed to IM Accounts . . 57
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . 59
10.1 XML Namespace Name for Session Data . . . . . . . . . . . . 59
11. Security Considerations . . . . . . . . . . . . . . . . . . 60
Normative References . . . . . . . . . . . . . . . . . . . . 61
Informative References . . . . . . . . . . . . . . . . . . . 62
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 62
A. vCards . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
B. XML Schemas . . . . . . . . . . . . . . . . . . . . . . . . 64
B.1 session . . . . . . . . . . . . . . . . . . . . . . . . . . 64
B.2 jabber:iq:last . . . . . . . . . . . . . . . . . . . . . . . 64
B.3 jabber:iq:privacy . . . . . . . . . . . . . . . . . . . . . 64
B.4 jabber:iq:privacy:error . . . . . . . . . . . . . . . . . . 66
B.5 jabber:iq:roster . . . . . . . . . . . . . . . . . . . . . . 66
C. Revision History . . . . . . . . . . . . . . . . . . . . . . 68
C.1 Changes from draft-ietf-xmpp-im-09 . . . . . . . . . . . . . 68
C.2 Changes from draft-ietf-xmpp-im-08 . . . . . . . . . . . . . 68
C.3 Changes from draft-ietf-xmpp-im-07 . . . . . . . . . . . . . 68
C.4 Changes from draft-ietf-xmpp-im-06 . . . . . . . . . . . . . 68
C.5 Changes from draft-ietf-xmpp-im-05 . . . . . . . . . . . . . 68
C.6 Changes from draft-ietf-xmpp-im-04 . . . . . . . . . . . . . 69
C.7 Changes from draft-ietf-xmpp-im-03 . . . . . . . . . . . . . 69
C.8 Changes from draft-ietf-xmpp-im-02 . . . . . . . . . . . . . 69
C.9 Changes from draft-ietf-xmpp-im-01 . . . . . . . . . . . . . 70
C.10 Changes from draft-ietf-xmpp-im-00 . . . . . . . . . . . . . 70
C.11 Changes from draft-miller-xmpp-im-02 . . . . . . . . . . . . 70
Intellectual Property and Copyright Statements . . . . . . . 71
Saint-Andre & Miller Expires October 26, 2003 [Page 3]
Internet-Draft XMPP Instant Messaging April 2003
1. Introduction
1.1 Overview
The core features of the Extensible Messaging and Presence Protocol
are defined in XMPP Core [1]. These features -- specifically XML
streams, stream authentication and encryption, and the ,
, and children of the stream root -- provide the
building blocks for many types of near-real-time applications, which
may be layered on top of the core by sending application-specific
data scoped by particular XML namespaces. This document describes the
extensions to and applications of XMPP Core that are required to
create the basic functionality expected of an instant messaging and
presence application as defined in RFC 2779 [2].
1.2 Requirements
For the purposes of this document, we stipulate that a basic instant
messaging and presence application needs to enable a user to perform
the following high-level use cases:
o Establish a session with a server
o Exchange messages with other users
o Exchange presence information with other users
o Manage subscriptions to and from other users
o Manage the items in the user's contact list (in XMPP this is
called a "roster")
o Block communications to or from specific other users
Detailed definitions of these functionality areas are contained in
RFC 2779 [2], and the interested reader is directed to that document
regarding the requirements addressed herein.
Note: although XMPP IM meets the requirements of RFC 2779, it was not
designed explicitly with RFC 2779 in mind, since the base protocol
evolved through an open development process within the Jabber
open-source community, mainly in 1999. In addition, protocols
addressing many other functionality areas have been defined and
continue to be defined by the Jabber Software Foundation [4]. These
include service discovery, multi-user chat, data gathering and forms
submission, feature negotiation, message composing events, message
expiration, delayed delivery, file transfer, XHTML message
formatting, publish-subscribe, and transports for XML-RPC and SOAP.
Saint-Andre & Miller Expires October 26, 2003 [Page 4]
Internet-Draft XMPP Instant Messaging April 2003
However, such protocols are not described herein because they are not
required by RFC 2779 [2].
1.3 Terminology
This document inherits the terminology defined in XMPP Core [1].
The capitalized key words "MUST", "MUST NOT", "REQUIRED", "SHALL",
"SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in RFC
2119 [3].
1.4 Discussion Venue
The authors welcome discussion and comments related to the topics
presented in this document. The preferred forum is the
mailing list, for which archives and subscription
information are available at .
1.5 Intellectual Property Notice
This document is in full compliance with all provisions of Section 10
of RFC 2026. Parts of this specification use the term "jabber" for
identifying namespaces and other protocol syntax. Jabber[tm] is a
registered trademark of Jabber, Inc. Jabber, Inc. grants permission
to the IETF for use of the Jabber trademark in association with this
specification and its successors, if any.
Saint-Andre & Miller Expires October 26, 2003 [Page 5]
Internet-Draft XMPP Instant Messaging April 2003
2. Establishing a Session
Most instant messaging applications based on XMPP are implemented via
a client-server architecture that requires a user to establish a
session on the server in order to engage in standard instant
messaging and presence activities. However, there are several
pre-conditions that must be met before a user may establish such a
session. These include:
1. Account Provisioning -- while this is outside the scope of XMPP,
methods for doing so include account creation by a server
administrator as well as in-band account registration using the
'jabber:iq:register' namespace; the latter method is documented
by the Jabber Software Foundation [4] at .
2. Authentication and Resource Authorization -- methods for
completing these pre-conditions are documented in XMPP Core [1];
note that client authentication with a server MUST include an
authorization identity that specifies the full JID (user@domain/
resource) associated with the connection for addressing purposes.
Once a client has authenticated with a server and authorized a full
JID (including resource), it SHOULD request that the server activate
an IM session for the client. This is accomplished by means of the
'urn:ietf:params:xml:ns:xmpp-session' namespace:
Step 1: Client requests session with server:
Step 2: Server informs client that session has been created:
Several error conditions are possible. For example, the server may
encounter an internal condition that prevents it from creating the
session, the username or authorization identity may lack permissions
to create a session, or there may already be an active session
associated with an authzid of the same name.
If the server encounters an internal condition that prevents it from
creating the session, it MUST return an error.
Saint-Andre & Miller Expires October 26, 2003 [Page 6]
Internet-Draft XMPP Instant Messaging April 2003
Step 2 (alt): Server responds with error (internal server error):
If the username or authorization identity is not allowed to create a
session, the server MUST return an error.
Step 2 (alt): Server responds with error (username or authzid not
allowed to create session):
If there is already an active session associated with an authzid of
the same name, the server MUST either (1) terminate the active
session and allow the newly-requested session, or (2) disallow the
newly-requested session and maintain the existing session. Which of
these the server does is up to the implementation, although it is
RECOMMENDED to implement (1).
Step 2 (alt): Server informs client of resource conflict (the desired
resource name is already in use by another active connection):
Saint-Andre & Miller Expires October 26, 2003 [Page 7]
Internet-Draft XMPP Instant Messaging April 2003
3. Exchanging Messages
Exchanging messages is a basic use of XMPP and is effected when a
user sends a message stanza to another user (or, more generally,
another entity). As defined under Routing and Delivery Rules (Section
9), the sender's server is responsible for delivering the message to
the intended recipient (if the recipient is on the same server) or
for routing the message to the recipient's server (if the recipient
is on a different server).
Detailed information regarding the syntax of message stanzas and
their defined attributes and child elements may be found in XMPP Core
[1].
3.1 Specifying an Intended Recipient
An IM client SHOULD specify an intended recipient for a message by
providing the JID of an entity other than the sender in the 'to'
attribute of the stanza. If the message is being sent in
reply to a message previously received from an address of the form
"user@domain/resource" (e.g., within the context of a chat session),
the value of the 'to' address SHOULD be the complete address rather
than merely "user@domain" unless the sender has knowledge (via
presence) that the intended recipient is no longer available. If the
message is being sent outside the context of any existing chat
session or received message, the value of the 'to' address SHOULD be
of the form "user@domain" rather than "user@domain/resource".
3.2 Specifying a Message Type
As mentioned in XMPP Core [1], there are several defined types of
messages (specified by means of a 'type' attribute within the
element). In the context of an instant messaging
application, a client MAY include a message type in order to capture
the conversational context of the message, thus providing a hint
regarding presentation (e.g., in a GUI). If no 'type' attribute is
provided, the message SHOULD be assumed to be a standalone message to
which the recipient MAY reply if desired. If the 'type' attribute is
included, it SHOULD have one of the following values (any other value
MAY be ignored):
o chat -- The message is sent in the context of a one-to-one chat
conversation. A compliant client SHOULD present an interface
enabling one-to-one chat between the two parties, including an
appropriate conversation history.
o groupchat -- The message is sent in the context of a multi-user
chat environment. A compliant client SHOULD present an interface
Saint-Andre & Miller Expires October 26, 2003 [Page 8]
Internet-Draft XMPP Instant Messaging April 2003
enabling many-to-many chat between the parties, including a roster
of parties in the chatroom and an appropriate conversation
history.
o headline -- The message is probably generated by an automated
service that delivers or broadcasts content (news, sports, market
information, RSS feeds, etc.). No reply to the message is
expected, and a compliant client SHOULD present an interface that
appropriately differentiates the message from standalone messages,
chat sessions, or groupchat sessions (e.g., by not providing the
recipient with the ability to reply).
o error -- An error has occurred related to a previous message sent
by the sender (for details regarding stanza error syntax, see XMPP
Core [1]). A compliant client SHOULD present an appropriate
interface informing the sender of the nature of the error.
Although the 'type' attribute is OPTIONAL, it is considered polite to
mirror the type in any replies to a message; furthermore, some
specialized applications (e.g., a multi-user chat service) MAY at
their discretion enforce the use of a particular message type (e.g.,
type='groupchat').
3.3 Specifying a Message Body
A message stanza MAY (and often will) contain a child element
specifying the main content of the message. The contents of the body
MUST be XML character data and MUST NOT contain mixed content. If it
is necessary to provide the main message content in an alternate form
(e.g., encrypted using the public key infrastructure or formatted
using XHTML), the alternate form MUST be contained in some other
child of the message stanza. Multiple