Network Working Group P. Saint-Andre
Internet-Draft J. Miller
Expires: August 24, 2003 Jabber Software Foundation
February 23, 2003
XMPP Instant Messaging
draft-ietf-xmpp-im-03
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 August 24, 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
necessary to create a basic instant messaging and presence
application.
Saint-Andre & Miller Expires August 24, 2003 [Page 1]
Internet-Draft XMPP Instant Messaging February 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. Authentication and Authorization . . . . . . . . . . . . . . 6
3. Exchanging Messages . . . . . . . . . . . . . . . . . . . . 7
3.1 Specifying an Intended Recipient . . . . . . . . . . . . . . 7
3.2 Specifying a Message Type . . . . . . . . . . . . . . . . . 7
3.3 Specifying a Message Subject . . . . . . . . . . . . . . . . 8
3.4 Specifying a Conversation Thread . . . . . . . . . . . . . . 8
3.5 Specifying a Message Body . . . . . . . . . . . . . . . . . 9
3.6 Specifying Additional Information . . . . . . . . . . . . . 9
3.7 Message-Related Errors . . . . . . . . . . . . . . . . . . . 10
4. Exchanging Presence Information . . . . . . . . . . . . . . 11
4.1 Client and Server Responsibilities . . . . . . . . . . . . . 11
4.2 Sending Initial Presence . . . . . . . . . . . . . . . . . . 11
4.3 Specifying Availability Status . . . . . . . . . . . . . . . 12
4.4 Specifying Detailed Status Information . . . . . . . . . . . 12
4.5 Probing for Presence . . . . . . . . . . . . . . . . . . . . 12
4.6 Sending Final Presence . . . . . . . . . . . . . . . . . . . 12
4.7 Determining When a Contact Went Offline . . . . . . . . . . 13
5. Managing Subscriptions . . . . . . . . . . . . . . . . . . . 14
5.1 Requesting a Subscription . . . . . . . . . . . . . . . . . 14
5.2 Handling a Subscription Request . . . . . . . . . . . . . . 14
5.3 Cancelling a Subscription from Another Entity . . . . . . . 14
5.4 Unsubscribing from Another Entity's Presence . . . . . . . . 15
6. Managing One's Roster . . . . . . . . . . . . . . . . . . . 16
6.1 Retrieving One's Roster on Login . . . . . . . . . . . . . . 16
6.2 Adding a Roster Item . . . . . . . . . . . . . . . . . . . . 17
6.3 Deleting a Roster Item . . . . . . . . . . . . . . . . . . . 18
7. Integration of Roster Items and Presence Subscriptions . . . 20
7.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 20
7.2 User Subscribes to Contact . . . . . . . . . . . . . . . . . 20
7.3 Creating a Mutual Subscription . . . . . . . . . . . . . . . 24
7.4 Unsubscribing . . . . . . . . . . . . . . . . . . . . . . . 26
7.4.1 Case #1: Subscription Type 'to' . . . . . . . . . . . . . . 26
7.4.2 Case #2: Subscription Type 'both' . . . . . . . . . . . . . 28
7.5 Cancelling a Subscription . . . . . . . . . . . . . . . . . 29
7.5.1 Case #1: Subscription Type 'from' . . . . . . . . . . . . . 29
7.5.2 Case #2: Subscription Type 'both' . . . . . . . . . . . . . 30
7.6 Removing a Roster Item and Cancelling All Subscriptions . . 31
8. Blocking Communication . . . . . . . . . . . . . . . . . . . 33
8.1 Retrieving One's Privacy Lists . . . . . . . . . . . . . . . 33
8.2 Managing Active Lists . . . . . . . . . . . . . . . . . . . 35
Saint-Andre & Miller Expires August 24, 2003 [Page 2]
Internet-Draft XMPP Instant Messaging February 2003
8.3 Managing the Default List . . . . . . . . . . . . . . . . . 35
8.4 Editing a Privacy List . . . . . . . . . . . . . . . . . . . 36
8.5 Removing a Privacy List . . . . . . . . . . . . . . . . . . 37
8.6 Blocking Messages . . . . . . . . . . . . . . . . . . . . . 37
8.7 Blocking Inbound Presence . . . . . . . . . . . . . . . . . 39
8.8 Blocking Outbound Presence . . . . . . . . . . . . . . . . . 40
8.9 Blocking IQs . . . . . . . . . . . . . . . . . . . . . . . . 42
8.10 Blocking All Communication . . . . . . . . . . . . . . . . . 43
8.11 Blocked Entity Attempts to Send Message to User . . . . . . 45
8.12 Higher-Level Heuristics . . . . . . . . . . . . . . . . . . 45
8.13 Processing Order . . . . . . . . . . . . . . . . . . . . . . 46
9. Security Considerations . . . . . . . . . . . . . . . . . . 48
References . . . . . . . . . . . . . . . . . . . . . . . . . 49
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 49
A. vCards . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
A.1 Retrieving One's vCard . . . . . . . . . . . . . . . . . . . 50
A.2 Updating One's vCard . . . . . . . . . . . . . . . . . . . . 51
A.3 Viewing Another User's vCard . . . . . . . . . . . . . . . . 52
B. Formal Definitions . . . . . . . . . . . . . . . . . . . . . 53
B.1 Schema for jabber:iq:last . . . . . . . . . . . . . . . . . 53
B.2 Schema for jabber:iq:privacy . . . . . . . . . . . . . . . . 53
B.3 Schema for jabber:iq:roster . . . . . . . . . . . . . . . . 54
B.4 DTD for vcard-temp . . . . . . . . . . . . . . . . . . . . . 55
C. Revision History . . . . . . . . . . . . . . . . . . . . . . 63
C.1 Changes from draft-ietf-xmpp-im-02 . . . . . . . . . . . . . 63
C.2 Changes from draft-ietf-xmpp-im-01 . . . . . . . . . . . . . 63
C.3 Changes from draft-ietf-xmpp-im-00 . . . . . . . . . . . . . 63
C.4 Changes from draft-miller-xmpp-im-02 . . . . . . . . . . . . 63
Intellectual Property and Copyright Statements . . . . . . . 65
Saint-Andre & Miller Expires August 24, 2003 [Page 3]
Internet-Draft XMPP Instant Messaging February 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 used to create
the basic functionality expected of an instant messaging and presence
application as defined in RFC 2779 [2]. Extended namespaces for many
other functionality areas have been defined and continue to be
defined by the Jabber Software Foundation [3], including service
discovery, multi-user chat, data gathering and forms submission,
feature negotiation, message composing events, message expiration,
delayed delivery, file transfer, publish-subscribe, and transports
for XML-RPC and SOAP; however, such functionality is not described
herein because it is not required by 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 functionality by using a compliant client:
o Authenticate 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]; although XMPP IM meets those requirements, 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 in 1999.
Saint-Andre & Miller Expires August 24, 2003 [Page 4]
Internet-Draft XMPP Instant Messaging February 2003
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 [4].
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 August 24, 2003 [Page 5]
Internet-Draft XMPP Instant Messaging February 2003
2. Authentication and Authorization
In order to gain access to the network of XMPP-compliant applications
and thus engage in standard IM functionality such as exchanging
messages and presence, a user must first acquire an account on a
server. Although account provisioning 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 defined by the
Jabber Software Foundation [3] and appropriate documentation is
available at the JSF's website.
In order to gain access to the network, a user MUST authenticate with
the server hosting his or her account. If a user's client is capable
of authenticating by means of SASL, it MUST include a 'version'
attribute (set to a value of "1.0") within the opening
element with which it initiated communications with the server. The
protocol describing how a client authenticates with a server using
SASL is defined in XMPP Core [1].
After authenticating, a user MUST also provide a resource name for
the current session, for the purpose of addressing; the protocol for
providing a resource is also defined in XMPP Core [1].
NOTE: Earlier iterations of the Jabber protocol contained a
client-server authentication protocol that was enforced after the
stream was negotiated; this protocol is not suppoted in XMPP but is
documented by the Jabber Software Foundation [3] for historical
purposes.
Saint-Andre & Miller Expires August 24, 2003 [Page 6]
Internet-Draft XMPP Instant Messaging February 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 in the "Routing and Delivery Rules"
section of XMPP Core [1], 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).
3.1 Specifying an Intended Recipient
A client SHOULD specify an intended recipient for the message by
providing an appropriate JID in the 'to' attribute of the
element. Normally, the value of the 'to' attribute specifies an
entity other than the sending user. The intended recipient MAY be any
valid JID (e.g., a user on the same server, a user on a different
server, the server itself, another server, or a service). If the JID
is invalid or cannot be contacted, the entity discovering that fact
(usually the sender's or recipient's server) SHOULD return an error
to the sender.
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 included, the 'type'
attribute 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.
o groupchat -- The message is sent in the context of a multi-user
chat environment.
o headline -- The message is generated by an automated service that
delivers content (news, sports, market information, etc.).
o error - A message returned to a sender specifying an error
associated with a previous message sent by the sender (for a full
list of error messages, see XMPP Core [1])
Although the 'type' attribute is OPTIONAL, it is considered polite to
mirror the type in any replies to a message; furthermore, some
Saint-Andre & Miller Expires August 24, 2003 [Page 7]
Internet-Draft XMPP Instant Messaging February 2003
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 Subject
A message stanza MAY contain a child element specifying
the subject of the message. The subject MUST NOT contain mixed
content.
A message with a subject:
Imploring
Wherefore art thou, Romeo?
Multiple elements MAY be included, as long as each
contains an 'xml:lang' attribute with a distinct value.
3.4 Specifying a Conversation Thread
A message stanza MAY contain a child element specifying the
conversation thread in which the message is situated, for the purpose
of tracking the conversation thread. The content of the
element is a random string that is generated by the sender in
accordance with the algorithm specified in XMPP Core [1]; this string
MAY be copied back to the sender in subsequent replies. If included,
the element MUST have no attributes and MUST NOT contain
mixed content.
Saint-Andre & Miller Expires August 24, 2003 [Page 8]
Internet-Draft XMPP Instant Messaging February 2003
A threaded conversation:
Art thou not Romeo, and a Montague?
e0ffe42b28561960c6b12b944a092794b9683a38
Neither, fair saint, if either thee dislike.
e0ffe42b28561960c6b12b944a092794b9683a38
How cam'st thou hither, tell me, and wherefore?
e0ffe42b28561960c6b12b944a092794b9683a38
3.5 Specifying a Message Body
A message stanza MAY (and often will) contain a child element
specifying the main content of the message as CDATA. The body 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 an appropriately-namespaced child of the
message stanza, as defined for any such extended namespace.
Multiple