Network Working Group P. Saint-Andre
Internet-Draft J. Miller
Expires: March 7, 2004 Jabber Software Foundation
September 7, 2003
XMPP Instant Messaging
draft-ietf-xmpp-im-17
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 March 7, 2004.
Copyright Notice
Copyright (C) The Internet Society (2003). All Rights Reserved.
Abstract
This document describes specific extensions to and applications of
the core features of the Extensible Messaging and Presence Protocol
(XMPP Core [1]) that provide the basic instant messaging and presence
functionality defined in RFC 2779 [2].
Saint-Andre & Miller Expires March 7, 2004 [Page 1]
Internet-Draft XMPP Instant Messaging September 2003
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 6
1.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.2 Requirements . . . . . . . . . . . . . . . . . . . . . . . 6
1.3 Terminology . . . . . . . . . . . . . . . . . . . . . . . 7
1.4 Discussion Venue . . . . . . . . . . . . . . . . . . . . . 7
1.5 Intellectual Property Notice . . . . . . . . . . . . . . . 7
2. Syntax of XML Stanzas . . . . . . . . . . . . . . . . . . 8
2.1 Message Stanzas . . . . . . . . . . . . . . . . . . . . . 8
2.1.1 Types of Message . . . . . . . . . . . . . . . . . . . . . 8
2.1.2 Child Elements . . . . . . . . . . . . . . . . . . . . . . 9
2.2 Presence Stanzas . . . . . . . . . . . . . . . . . . . . . 10
2.2.1 Types of Presence . . . . . . . . . . . . . . . . . . . . 10
2.2.2 Child Elements . . . . . . . . . . . . . . . . . . . . . . 11
2.3 IQ Stanzas . . . . . . . . . . . . . . . . . . . . . . . . 13
2.4 Extended Namespaces . . . . . . . . . . . . . . . . . . . 13
3. Establishing a Session . . . . . . . . . . . . . . . . . . 15
4. Exchanging Messages . . . . . . . . . . . . . . . . . . . 18
4.1 Specifying an Intended Recipient . . . . . . . . . . . . . 18
4.2 Specifying a Message Type . . . . . . . . . . . . . . . . 18
4.3 Specifying a Message Body . . . . . . . . . . . . . . . . 18
4.4 Specifying a Message Subject . . . . . . . . . . . . . . . 19
4.5 Specifying a Conversation Thread . . . . . . . . . . . . . 19
5. Exchanging Presence Information . . . . . . . . . . . . . 21
5.1 Client and Server Presence Responsibilities . . . . . . . 21
5.2 Specifying Availability Status . . . . . . . . . . . . . . 24
5.3 Specifying Detailed Status Information . . . . . . . . . . 24
5.4 Specifying Presence Priority . . . . . . . . . . . . . . . 24
5.5 Presence Examples . . . . . . . . . . . . . . . . . . . . 25
6. Managing Subscriptions . . . . . . . . . . . . . . . . . . 29
6.1 Requesting a Subscription . . . . . . . . . . . . . . . . 29
6.2 Handling a Subscription Request . . . . . . . . . . . . . 29
6.3 Cancelling a Subscription from Another Entity . . . . . . 30
6.4 Unsubscribing from Another Entity's Presence . . . . . . . 30
7. Roster Management . . . . . . . . . . . . . . . . . . . . 31
7.1 Syntax and Semantics . . . . . . . . . . . . . . . . . . . 31
7.2 Business Rules . . . . . . . . . . . . . . . . . . . . . . 31
7.3 Retrieving One's Roster on Login . . . . . . . . . . . . . 32
7.4 Adding a Roster Item . . . . . . . . . . . . . . . . . . . 32
7.5 Updating a Roster Item . . . . . . . . . . . . . . . . . . 34
7.6 Deleting a Roster Item . . . . . . . . . . . . . . . . . . 34
8. Integration of Roster Items and Presence Subscriptions . . 36
8.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . 36
8.2 User Subscribes to Contact . . . . . . . . . . . . . . . . 36
8.2.1 Alternate Flow: Contact Declines Subscription Request . . 41
8.3 Creating a Mutual Subscription . . . . . . . . . . . . . . 42
8.3.1 Alternate Flow: User Declines Subscription Request . . . . 45
Saint-Andre & Miller Expires March 7, 2004 [Page 2]
Internet-Draft XMPP Instant Messaging September 2003
8.4 Unsubscribing . . . . . . . . . . . . . . . . . . . . . . 46
8.4.1 Case #1: Unsubscribing When Subscription is Not Mutual . . 46
8.4.2 Case #2: Unsubscribing When Subscription is Mutual . . . . 49
8.5 Cancelling a Subscription . . . . . . . . . . . . . . . . 51
8.5.1 Case #1: Cancelling When Subscription is Not Mutual . . . 51
8.5.2 Case #2: Cancelling When Subscription is Mutual . . . . . 53
8.6 Removing a Roster Item and Cancelling All Subscriptions . 55
9. Subscription States . . . . . . . . . . . . . . . . . . . 59
9.1 Defined States . . . . . . . . . . . . . . . . . . . . . . 59
9.2 Server Handling of Outbound Presence, Categorized by
Subscription State . . . . . . . . . . . . . . . . . . . . 59
9.2.1 Subscription State = None . . . . . . . . . . . . . . . . 60
9.2.2 Subscription State = None + Pending Out . . . . . . . . . 60
9.2.3 Subscription State = None + Pending In . . . . . . . . . . 60
9.2.4 Subscription State = None + Pending Out/In . . . . . . . . 60
9.2.5 Subscription State = To . . . . . . . . . . . . . . . . . 61
9.2.6 Subscription State = To + Pending In . . . . . . . . . . . 61
9.2.7 Subscription State = From . . . . . . . . . . . . . . . . 61
9.2.8 Subscription State = From + Pending Out . . . . . . . . . 61
9.2.9 Subscription State = Both . . . . . . . . . . . . . . . . 62
9.3 Server Handling of Outbound Presence, Categorized by
Presence Type . . . . . . . . . . . . . . . . . . . . . . 62
9.3.1 Subscribe . . . . . . . . . . . . . . . . . . . . . . . . 62
9.3.2 Subscribed . . . . . . . . . . . . . . . . . . . . . . . . 62
9.3.3 Unsubscribe . . . . . . . . . . . . . . . . . . . . . . . 63
9.3.4 Unsubscribed . . . . . . . . . . . . . . . . . . . . . . . 63
9.4 Server Handling of Inbound Presence, Categorized by
Subscription State . . . . . . . . . . . . . . . . . . . . 64
9.4.1 Subscription State = None . . . . . . . . . . . . . . . . 64
9.4.2 Subscription State = None + Pending Out . . . . . . . . . 64
9.4.3 Subscription State = None + Pending In . . . . . . . . . . 64
9.4.4 Subscription State = None + Pending Out/In . . . . . . . . 65
9.4.5 Subscription State = To . . . . . . . . . . . . . . . . . 65
9.4.6 Subscription State = To + Pending In . . . . . . . . . . . 65
9.4.7 Subscription State = From . . . . . . . . . . . . . . . . 65
9.4.8 Subscription State = From + Pending Out . . . . . . . . . 66
9.4.9 Subscription State = Both . . . . . . . . . . . . . . . . 66
9.5 Server Handling of Inbound Presence, Categorized by
Presence Type . . . . . . . . . . . . . . . . . . . . . . 66
9.5.1 Subscribe . . . . . . . . . . . . . . . . . . . . . . . . 66
9.5.2 Subscribed . . . . . . . . . . . . . . . . . . . . . . . . 67
9.5.3 Unsubscribe . . . . . . . . . . . . . . . . . . . . . . . 67
9.5.4 Unsubscribed . . . . . . . . . . . . . . . . . . . . . . . 67
9.6 Server Delivery and Client Acknowledgement of
Subscription State Change Notifications . . . . . . . . . 68
10. Blocking Communication . . . . . . . . . . . . . . . . . . 69
10.1 Syntax and Semantics . . . . . . . . . . . . . . . . . . . 69
10.2 Business Rules . . . . . . . . . . . . . . . . . . . . . . 71
Saint-Andre & Miller Expires March 7, 2004 [Page 3]
Internet-Draft XMPP Instant Messaging September 2003
10.3 Retrieving One's Privacy Lists . . . . . . . . . . . . . . 72
10.4 Managing Active Lists . . . . . . . . . . . . . . . . . . 75
10.5 Managing the Default List . . . . . . . . . . . . . . . . 76
10.6 Editing a Privacy List . . . . . . . . . . . . . . . . . . 77
10.7 Adding a New Privacy List . . . . . . . . . . . . . . . . 78
10.8 Removing a Privacy List . . . . . . . . . . . . . . . . . 78
10.9 Blocking Messages . . . . . . . . . . . . . . . . . . . . 78
10.10 Blocking Inbound Presence Notifications . . . . . . . . . 80
10.11 Blocking Outbound Presence Notifications . . . . . . . . . 82
10.12 Blocking IQs . . . . . . . . . . . . . . . . . . . . . . . 83
10.13 Blocking All Communication . . . . . . . . . . . . . . . . 85
10.14 Blocked Entity Attempts to Communicate with User . . . . . 87
10.15 Higher-Level Heuristics . . . . . . . . . . . . . . . . . 87
11. IANA Considerations . . . . . . . . . . . . . . . . . . . 89
11.1 XML Namespace Name for Session Data . . . . . . . . . . . 89
12. Internationalization Considerations . . . . . . . . . . . 90
13. Security Considerations . . . . . . . . . . . . . . . . . 91
14. Server Rules for Handling XML Stanzas . . . . . . . . . . 92
15. Compliance Requirements . . . . . . . . . . . . . . . . . 94
15.1 Servers . . . . . . . . . . . . . . . . . . . . . . . . . 94
15.2 Clients . . . . . . . . . . . . . . . . . . . . . . . . . 94
Normative References . . . . . . . . . . . . . . . . . . . 95
Informative References . . . . . . . . . . . . . . . . . . 96
Authors' Addresses . . . . . . . . . . . . . . . . . . . . 96
A. vCards . . . . . . . . . . . . . . . . . . . . . . . . . . 97
B. XML Schemas . . . . . . . . . . . . . . . . . . . . . . . 98
B.1 jabber:client namespace . . . . . . . . . . . . . . . . . 98
B.2 jabber:server namespace . . . . . . . . . . . . . . . . . 102
B.3 session . . . . . . . . . . . . . . . . . . . . . . . . . 106
B.4 jabber:iq:privacy . . . . . . . . . . . . . . . . . . . . 106
B.5 jabber:iq:roster . . . . . . . . . . . . . . . . . . . . . 109
C. Differences Between Jabber and XMPP . . . . . . . . . . . 111
C.1 Session Creation . . . . . . . . . . . . . . . . . . . . . 111
C.2 Privacy Rules . . . . . . . . . . . . . . . . . . . . . . 111
D. Revision History . . . . . . . . . . . . . . . . . . . . . 112
D.1 Changes from draft-ietf-xmpp-im-16 . . . . . . . . . . . . 112
D.2 Changes from draft-ietf-xmpp-im-15 . . . . . . . . . . . . 112
D.3 Changes from draft-ietf-xmpp-im-14 . . . . . . . . . . . . 113
D.4 Changes from draft-ietf-xmpp-im-13 . . . . . . . . . . . . 113
D.5 Changes from draft-ietf-xmpp-im-12 . . . . . . . . . . . . 113
D.6 Changes from draft-ietf-xmpp-im-11 . . . . . . . . . . . . 113
D.7 Changes from draft-ietf-xmpp-im-10 . . . . . . . . . . . . 114
D.8 Changes from draft-ietf-xmpp-im-09 . . . . . . . . . . . . 114
D.9 Changes from draft-ietf-xmpp-im-08 . . . . . . . . . . . . 114
D.10 Changes from draft-ietf-xmpp-im-07 . . . . . . . . . . . . 114
D.11 Changes from draft-ietf-xmpp-im-06 . . . . . . . . . . . . 114
D.12 Changes from draft-ietf-xmpp-im-05 . . . . . . . . . . . . 115
D.13 Changes from draft-ietf-xmpp-im-04 . . . . . . . . . . . . 115
Saint-Andre & Miller Expires March 7, 2004 [Page 4]
Internet-Draft XMPP Instant Messaging September 2003
D.14 Changes from draft-ietf-xmpp-im-03 . . . . . . . . . . . . 115
D.15 Changes from draft-ietf-xmpp-im-02 . . . . . . . . . . . . 115
D.16 Changes from draft-ietf-xmpp-im-01 . . . . . . . . . . . . 116
D.17 Changes from draft-ietf-xmpp-im-00 . . . . . . . . . . . . 116
D.18 Changes from draft-miller-xmpp-im-02 . . . . . . . . . . . 116
Intellectual Property and Copyright Statements . . . . . . 117
Saint-Andre & Miller Expires March 7, 2004 [Page 5]
Internet-Draft XMPP Instant Messaging September 2003
1. Introduction
1.1 Overview
The Extensible Messaging and Presence Protocol (XMPP) is a protocol
for streaming XML [3] elements in order to exchange messages and
presence information in close to real time. The core features of XMPP
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 qualified by particular XML namespaces [4]. This document
describes extensions to and applications of XMPP Core that provide
the basic functionality expected of an instant messaging (IM) and
presence application as defined in RFC 2779 [2].
1.2 Requirements
For the purposes of this document, the requirements of a basic
instant messaging and presence application are defined by RFC 2779
[2]. At a high level, RFC 2779 stipulates that a user must be able to
complete the following use cases:
o Exchange messages with other users
o Exchange presence information with other users
o Manage subscriptions to and from other users
o Manage items in a 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, and the interested reader is directed to that document
regarding the requirements addressed herein.
Note: while XMPP-based instant messaging and presence 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 before
RFC 2779 was written. Note also that although protocols addressing
many other functionality areas have been defined in the Jabber
community, such protocols are not included in this document because
they are not required by RFC 2779 [2].
Saint-Andre & Miller Expires March 7, 2004 [Page 6]
Internet-Draft XMPP Instant Messaging September 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 [5].
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 March 7, 2004 [Page 7]
Internet-Draft XMPP Instant Messaging September 2003
2. Syntax of XML Stanzas
The basic semantics and common attributes of XML stanzas qualified by
the 'jabber:client' and 'jabber:server' namespaces are defined in
XMPP Core [1]. However, these namespaces also define various child
elements, as well as values for the common 'type' attribute, that are
specific to instant messaging and presence applications. Thus, before
addressing particular "use cases" for such applications, we here
further describe the syntax of XML stanzas, thereby supplementing the
discussion in XMPP Core [1].
2.1 Message Stanzas
Message stanzas in the 'jabber:client' or 'jabber:server' namespace
are used to "push" information to another entity. Common uses in the
context of instant messaging include single messages, messages sent
in the context of a chat conversation, messages sent in the context
of a multi-user chat room, headlines, and errors.
2.1.1 Types of Message
The 'type' attribute of a message stanza is RECOMMENDED; if included,
it specifies the conversational context of the message thus providing
a hint regarding presentation (e.g., in a GUI). 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 error -- An error has occurred related to a previous message sent
by the sender (for details regarding stanza error syntax, refer to
XMPP Core [1]). A compliant client SHOULD present an appropriate
interface informing the sender of the nature of the error.
o groupchat -- The message is sent in the context of a multi-user
chat environment. A compliant client SHOULD present an interface
enabling many-to-many chat between the parties, including a roster
of parties in the chatroom and an appropriate conversation
history. Full definition of XMPP-based groupchat protocols is out
of scope for this document.
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
Saint-Andre & Miller Expires March 7, 2004 [Page 8]
Internet-Draft XMPP Instant Messaging September 2003
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 normal -- The message is a standalone message to which the
recipient MAY reply if desired.
An IM application SHOULD support all of the foregoing message types;
if an application receives a message with no 'type' attribute or the
application does not understand the value of the 'type' attribute
provided, it MUST consider the message to be of type "normal" (i.e.,
"normal" is the default).
Although the 'type' attribute is NOT REQUIRED, 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').
2.1.2 Child Elements
As described under extended namespaces (Section 2.4), a message
stanza MAY contain any properly-namespaced child element.
In accordance with the default namespace declaration, by default a
message stanza is in the 'jabber:client' or 'jabber:server'
namespace, which defines certain allowable children of message
stanzas. If the message stanza is of type "error", it MUST include an
child; for details, see XMPP Core [1]. Otherwise, the
message stanza MAY contain any of the following child elements
without an explicit namespace declaration:
1.
2.
3.
2.1.2.1 Subject
The element specifies the topic of the message. The
element SHOULD NOT possess any attributes, with the
exception of the 'xml:lang' attribute. Multiple instances of the
element MAY be included for the purpose of providing
alternate versions of the same subject, but only if each instance
possesses an 'xml:lang' attribute with a distinct language value. The
element MUST NOT contain mixed content (as defined in
Saint-Andre & Miller Expires March 7, 2004 [Page 9]
Internet-Draft XMPP Instant Messaging September 2003
Section 3.2.2 of the XML specification [3]).
2.1.2.2 Body
The