Network Working Group P. Saint-Andre
Internet-Draft J. Miller
Expires: August 27, 2003 Jabber Software Foundation
February 26, 2003
XMPP Instant Messaging
draft-ietf-xmpp-im-04
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 27, 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 such as that provided by the servers, clients, and other
applications that comprise the XMPP-based Jabber network.
Saint-Andre & Miller Expires August 27, 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 . . . . . . . . . . . . . . . . . . . . 8
3.1 Specifying an Intended Recipient . . . . . . . . . . . . . . 8
3.2 Specifying a Message Type . . . . . . . . . . . . . . . . . 8
3.3 Specifying a Message Subject . . . . . . . . . . . . . . . . 9
3.4 Specifying a Conversation Thread . . . . . . . . . . . . . . 9
3.5 Specifying a Message Body . . . . . . . . . . . . . . . . . 10
3.6 Specifying Additional Information . . . . . . . . . . . . . 10
3.7 Message-Related Errors . . . . . . . . . . . . . . . . . . . 11
4. Exchanging Presence Information . . . . . . . . . . . . . . 12
4.1 Client and Server Responsibilities . . . . . . . . . . . . . 12
4.2 Sending Initial Presence . . . . . . . . . . . . . . . . . . 12
4.3 Specifying Availability Status . . . . . . . . . . . . . . . 13
4.4 Specifying Detailed Status Information . . . . . . . . . . . 13
4.5 Probing for Presence . . . . . . . . . . . . . . . . . . . . 13
4.6 Sending Final Presence . . . . . . . . . . . . . . . . . . . 13
4.7 Determining When a Contact Went Offline . . . . . . . . . . 14
5. Managing Subscriptions . . . . . . . . . . . . . . . . . . . 16
5.1 Requesting a Subscription . . . . . . . . . . . . . . . . . 16
5.2 Handling a Subscription Request . . . . . . . . . . . . . . 16
5.3 Cancelling a Subscription from Another Entity . . . . . . . 17
5.4 Unsubscribing from Another Entity's Presence . . . . . . . . 17
6. Managing One's Roster . . . . . . . . . . . . . . . . . . . 18
6.1 Retrieving One's Roster on Login . . . . . . . . . . . . . . 18
6.2 Adding a Roster Item . . . . . . . . . . . . . . . . . . . . 19
6.3 Deleting a Roster Item . . . . . . . . . . . . . . . . . . . 20
7. Integration of Roster Items and Presence Subscriptions . . . 22
7.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 22
7.2 User Subscribes to Contact . . . . . . . . . . . . . . . . . 22
7.2.1 Alternate Flow . . . . . . . . . . . . . . . . . . . . . . . 25
7.3 Creating a Mutual Subscription . . . . . . . . . . . . . . . 26
7.3.1 Alternate Flow . . . . . . . . . . . . . . . . . . . . . . . 28
7.4 Unsubscribing . . . . . . . . . . . . . . . . . . . . . . . 28
7.4.1 Case #1: Subscription Type 'to' . . . . . . . . . . . . . . 29
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 . . 34
8. Blocking Communication . . . . . . . . . . . . . . . . . . . 36
Saint-Andre & Miller Expires August 27, 2003 [Page 2]
Internet-Draft XMPP Instant Messaging February 2003
8.1 Syntax . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
8.2 Processing Order . . . . . . . . . . . . . . . . . . . . . . 37
8.3 Retrieving One's Privacy Lists . . . . . . . . . . . . . . . 38
8.4 Managing Active Lists . . . . . . . . . . . . . . . . . . . 39
8.5 Managing the Default List . . . . . . . . . . . . . . . . . 40
8.6 Editing a Privacy List . . . . . . . . . . . . . . . . . . . 41
8.7 Removing a Privacy List . . . . . . . . . . . . . . . . . . 41
8.8 Blocking Messages . . . . . . . . . . . . . . . . . . . . . 42
8.9 Blocking Inbound Presence Notifications . . . . . . . . . . 44
8.10 Blocking Outbound Presence Notifications . . . . . . . . . . 45
8.11 Blocking IQs . . . . . . . . . . . . . . . . . . . . . . . . 47
8.12 Blocking All Communication . . . . . . . . . . . . . . . . . 49
8.13 Blocked Entity Attempts to Communicate with User . . . . . . 50
8.14 Higher-Level Heuristics . . . . . . . . . . . . . . . . . . 51
9. Routing and Delivery Rules . . . . . . . . . . . . . . . . . 53
9.1 Client Generation of To Addresses . . . . . . . . . . . . . 53
9.2 Server Handling of XML Stanzas . . . . . . . . . . . . . . . 53
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . 55
11. Security Considerations . . . . . . . . . . . . . . . . . . 56
References . . . . . . . . . . . . . . . . . . . . . . . . . 57
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 57
A. vCards . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
A.1 Retrieving One's vCard . . . . . . . . . . . . . . . . . . . 58
A.2 Updating One's vCard . . . . . . . . . . . . . . . . . . . . 59
A.3 Viewing Another User's vCard . . . . . . . . . . . . . . . . 60
B. Formal Definitions . . . . . . . . . . . . . . . . . . . . . 61
B.1 Schema for jabber:iq:last . . . . . . . . . . . . . . . . . 61
B.2 Schema for jabber:iq:privacy . . . . . . . . . . . . . . . . 61
B.3 Schema for jabber:iq:roster . . . . . . . . . . . . . . . . 63
B.4 DTD for vcard-temp . . . . . . . . . . . . . . . . . . . . . 64
C. Revision History . . . . . . . . . . . . . . . . . . . . . . 71
C.1 Changes from draft-ietf-xmpp-im-03 . . . . . . . . . . . . . 71
C.2 Changes from draft-ietf-xmpp-im-02 . . . . . . . . . . . . . 71
C.3 Changes from draft-ietf-xmpp-im-01 . . . . . . . . . . . . . 71
C.4 Changes from draft-ietf-xmpp-im-00 . . . . . . . . . . . . . 71
C.5 Changes from draft-miller-xmpp-im-02 . . . . . . . . . . . . 72
Full Copyright Statement . . . . . . . . . . . . . . . . . . 73
Saint-Andre & Miller Expires August 27, 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 and authorize 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, mainly in 1999.
Saint-Andre & Miller Expires August 27, 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 27, 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].
Once a client has authenticated with a server using SASL, it MUST
define a resource that the server can associate with the connection
for purposes of authorization and addressing. This is necessary
because stanzas sent to or received from the server within the
context of an active session use a "full JID" (user@domain/resource)
for addressing. Authorizing a resource is accomplished by means of
the 'jabber:iq:auth' namespace as described below.
Step 1: Client queries server regarding information that is still
required to begin a session:
juliet
Step 2: Server responds with the required fields (in this case, only
the username and authorized resource):
juliet
Saint-Andre & Miller Expires August 27, 2003 [Page 6]
Internet-Draft XMPP Instant Messaging February 2003
Step 3: Client sends name of authorized resource:
juliet
balcony
Step 4: Server informs client of successful session initiation:
Step 4 (alt): Server informs client of error encountered during
session initiation:
juliet
Not Acceptable (empty resource)
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 27, 2003 [Page 7]
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 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
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) MUST 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, RSS feeds,
etc.).
o error - A message returned to a sender specifying an error
Saint-Andre & Miller Expires August 27, 2003 [Page 8]
Internet-Draft XMPP Instant Messaging February 2003
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
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. Multiple elements MAY be included, as long as
each contains an 'xml:lang' attribute with a distinct value.
A message with a subject:
Imploring
Wherefore art thou, Romeo?
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. 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 SHOULD be
copied back to the sender in subsequent replies.
Saint-Andre & Miller Expires August 27, 2003 [Page 9]
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