Network Working Group P. Saint-Andre, Ed.
Request for Comments: 3921 Jabber Software Foundation
Category: Standards Track October 2004
Extensible Messaging and Presence Protocol (XMPP):
Instant Messaging and Presence
Status of this Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2004).
Abstract
This memo describes extensions to and applications of the core
features of the Extensible Messaging and Presence Protocol (XMPP)
that provide the basic instant messaging (IM) and presence
functionality defined in RFC 2779.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Syntax of XML Stanzas . . . . . . . . . . . . . . . . . . . 4
3. Session Establishment . . . . . . . . . . . . . . . . . . . 10
4. Exchanging Messages . . . . . . . . . . . . . . . . . . . . 13
5. Exchanging Presence Information . . . . . . . . . . . . . . 16
6. Managing Subscriptions . . . . . . . . . . . . . . . . . . . 26
7. Roster Management . . . . . . . . . . . . . . . . . . . . . 27
8. Integration of Roster Items and Presence Subscriptions . . . 32
9. Subscription States . . . . . . . . . . . . . . . . . . . . 56
10. Blocking Communication . . . . . . . . . . . . . . . . . . . 62
11. Server Rules for Handling XML Stanzas . . . . . . . . . . . 85
12. IM and Presence Compliance Requirements . . . . . . . . . . 88
13. Internationalization Considerations . . . . . . . . . . . . 89
14. Security Considerations . . . . . . . . . . . . . . . . . . 89
15. IANA Considerations . . . . . . . . . . . . . . . . . . . . 90
16. References . . . . . . . . . . . . . . . . . . . . . . . . . 91
A. vCards . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
B. XML Schemas. . . . . . . . . . . . . . . . . . . . . . . . . 93
C. Differences Between Jabber IM/Presence Protocols and XMPP. . 105
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 106
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 106
Author's Address. . . . . . . . . . . . . . . . . . . . . . . . . 106
Full Copyright Statement. . . . . . . . . . . . . . . . . . . . . 107
1. Introduction
1.1. Overview
The Extensible Messaging and Presence Protocol (XMPP) is a protocol
for streaming XML [XML] elements in order to exchange messages and
presence information in close to real time. The core features of
XMPP are defined in Extensible Messaging and Presence Protocol
(XMPP): Core [XMPP-CORE]. These features -- mainly XML streams, use
of TLS and SASL, and the <message/>, <presence/>, and <iq/> 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 [XML-NAMES]. This memo describes extensions to and
applications of the core features of XMPP that provide the basic
functionality expected of an instant messaging (IM) and presence
application as defined in RFC 2779 [IMP-REQS].
XMPP是一种通过将XML elements流化以达到近乎实时地传递消息(message)和在线信息
(presence information)的协议。XMPP的核心功能在(XMPP): Core [XMPP-CORE]中定义。
这些功能——主要包括XML的流化，TLS和SASL的使用，以及像<message/>,<presence/>以及
<iq/>这样的流的子元素——提供给我们一些素材，使我们能创建很多"半实时(near-real-time)"
的应用程序，而这些半实时的应用程序或许会位于应用程序的核心层之上，专门负责发送由程序专用的
XML数据。这份memo讲述的是怎样扩展和使用XMPP的核心功能，而XMPP的核心协议仅涵盖了由RFC
2779[IMP-REQS]定义的，基本的IM和presence application 所应该提供的功能。
1.2. Requirements
For the purposes of this memo, the requirements of a basic instant
messaging and presence application are defined by [IMP-REQS], which
at a high level stipulates that a user must be able to complete the
following use cases:
作为本文档的基础，基本的IM和"在线应用程序presence application"的要求
刊载在[IMP-REQS]里面。这份文档在大体上规定了用户必须能完成如下的功能。
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")
管理通讯录里的资料(XMPP称之为roster)
o Block communications to or from specific other users
切断与他人的通讯
Detailed definitions of these functionality areas are contained in
[IMP-REQS], and the interested reader is directed to that document
regarding the requirements addressed herein.
这些功能的详细定义刊载在[IMP-REQS]里，感兴趣的读者可以自己去看。
[IMP-REQS] also stipulates that presence services must be separable
from instant messaging services; i.e., it must be possible to use the
protocol to provide a presence service, an instant messaging service,
or both. Although the text of this memo assumes that implementations
and deployments will want to offer a unified instant messaging and
presence service, there is no requirement that a service must offer
both a presence service and an instant messaging service, and the
protocol makes it possible to offer separate and distinct services
for presence and for instant messaging.
[IMP-REQS]同时还规定，在线信息的服务必须与及时信息的服务相分离。比方说，
协议必须允许你只使用在线信息，或及时信息服务，当然也可以两个都用。虽然
我们认为真正实现的时候，在线信息和及时信息服务肯定是合二为一的，但是它
也没有强求你一定必须同时提供在线信息合及时信息服务。这个协议完全允许你
提供单独的在线信息或及时信息服务。
Note: While XMPP-based instant messaging and presence meets the
requirements of [IMP-REQS], it was not designed explicitly with that
specification 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 memo
because they are not required by [IMP-REQS].
注意：虽然基于XMPP的及时信息和在线服务符合[IMP-REQS]的要求，但它并
不是刻意去实现的，因为Jabber开源社区早在RFC 2779发布之前就已经促成了
基本的协议。同时还要指出的是，虽然Jabber社区还为协议设计了很多别的方面
的功能，但由于[IMP-REQS]并没有要求，因此我们这里也就不涉及了。
1.3. Terminology
This memo inherits the terminology defined in [XMPP-CORE].
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 BCP
14, RFC 2119 [TERMS].
2. Syntax of XML Stanzas
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]. 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].
XML stanzas都归在'jabber:client'和'jabber:server'名字空间之下，其基本语义
和常用属性由[XMPP-CORE]定义。除了常用的'type'属性的值之外，这两个名字空间
还定义了很多专供及时信息或在线信息服务的child elements。因此在描述此类应用
程序的“use case”之前，我们先探讨一下XML stanzas的语法，也借此补充一下
[XMPP-CORE]。
2.1. Message Syntax
Message stanzas qualified by the 'jabber:client' or 'jabber:server'
namespace are used to "push" information to another entity. Common
uses in instant messaging applications 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 other alerts,
and errors.
归在'jabber:client'或'jabber:server'名字空间之下的Message stanzas是用来
向另一个entity"推"信息用的。在IM应用程序里，这种stanzas常用被用于发送“单条
消息(single message)”，在chat环境下发送消息，在多用户的chat room的环境下
发送消息，以及发送headline，警告和错误消息。
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
included, the 'type' attribute MUST have one of the following values:
message stanza的'type'属性是RECOMMENDED的；如果有，它表示这个消息是在怎样
的交谈环境下发出的，因此它也暗示了该怎样显示这条消息(比方说在GUI环境下)。
'type'属性如果有必须(MUST)是下面值里的一个。
o chat -- The message is sent in the context of a one-to-one chat
conversation. A compliant client SHOULD present the message in an
interface enabling one-to-one chat between the two parties,
including an appropriate conversation history.
chat -- 消息是在一对一的chat谈话中发出的。客户端应当(SHOULD)在一个
能让用户进行一对一谈话的界面里提示这条消息，包括交谈的记录。
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]). A compliant client SHOULD present an appropriate
interface informing the sender of the nature of the error.
error -- 表示先前发送的消息发生了错误(关于stanza的错误的语法，
请参阅[XMPP-CORE])。客户端应当(SHOULD)能告诉发送发错误的性质。
o groupchat -- The message is sent in the context of a multi-user
chat environment (similar to that of [IRC]). A compliant client
SHOULD present the message in 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 memo.
groupchat -- 这条消息是在多用户交谈环境下发出的(类似[IRC])。客户端
应当(SHOULD)在能允许用户进行多对多谈话的界面里显示这条消息，这其中
应该包括chat room的参与者的roster(名单)，以及适当的谈话记录。基于XMPP
的群组交谈协议超出了本文档的范围。
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 the message in 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).
headline -- 这条消息或许是由某个后台服务生成并发送或广播的(新闻，体育，
市场信息，RSS服务等到)。它不需要用户的回应。客户端应当(SHOULD)在
一个合适的界面下提示这条消息以将其与"standalone message"，"chat session"
和"groupchat session"相区分(比方说用户只能看不能reply)。
o normal -- The message is a single message that is sent outside the
context of a one-to-one conversation or groupchat, and to which it
is expected that the recipient will reply. A compliant client
SHOULD present the message in an interface enabling the recipient
to reply, but without a conversation history.
normal -- 这是一个single message，既不是一对一的交谈，也不是群组交谈，
而且允许接受方回应。客户端应当(SHOULD)在一个能让用户reply的界面里显示
这条消息，但是不要有谈话记录。
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). The "error" type MUST be generated only in
response to an error related to a message received from another
entity.
IM application应当支持所有上述message type，如果它收到了一个没有'type'属性的message
或者它看不懂这个'type'属性，那它必须(MUST)将其认做是"normal"的message(也就是说，
"normal"是默认的属性)。"error"只限于(MUST)用来回应与对方发出的message相关的错误。
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').
虽然'type'属性是OPTIONAL的，但是最好在回应信息里面附上相同的'type'信息；此外有些专用程序
(比方说多用户的chat service)可以(MAY)根据他们自己的需要，强制使用特定的message type
(比方说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.
正如我们将在"扩展名字空间"(Section2.4)所讲的，message stanza可以(MAY)包含任意的
"属于适当的名字空间"的child element。
In accordance with the default namespace declaration, by default a
message stanza is qualified by 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 <error/> child; for details, see [XMPP-CORE]. Otherwise, the
message stanza MAY contain any of the following child elements
without an explicit namespace declaration:
为了与默认的名字空间的声明相一致，默认情况下，message stanza被归到'jabber:client'或
'jabber:server'名字空间下。这两个名字空间定义了一些被认可的message stanza的child。
'error'类型的message stanza必须(MUST)包含<error/> child；具体细节请看[XMPP-CORE]。
除此之外，message stanza可以(MAY)不经声明就使用下列的child elements。
1. <subject/>
2. <body/>
3. <thread/>
2.1.2.1. Subject
The <subject/> element contains human-readable XML character data
that specifies the topic of the message. The <subject/> element MUST
NOT possess any attributes, with the exception of the 'xml:lang'
attribute. Multiple instances of the <subject/> 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 <subject/> element MUST NOT
contain mixed content (as defined in Section 3.2.2 of [XML]).
<subject/> element包含human-readable的，表示message的标题的XML字符数据。
<subject/>绝对不能(MUST NOT)包含除'xml:lang'之外的任何属性。为了能提供同一个
subject的多个版本，一个message里面可以(MAY)包含多个<body/> element。但这仅限于
每个<body/>都包含'xml:lang'属性，并且其language值都不相同的情形。<subject/>
绝对不能(MUST NOT)包含mixed content(见Section 3.2.2)
2.1.2.2. Body
The <body/> element contains human-readable XML character data that
specifies the textual contents of the message; this child element is
normally included but is OPTIONAL. The <body/> element MUST NOT
possess any attributes, with the exception of the 'xml:lang'
attribute. Multiple instances of the <body/> element MAY be included
but only if each instance possesses an 'xml:lang' attribute with a
distinct language value. The <body/> element MUST NOT contain mixed
content (as defined in Section 3.2.2 of [XML]).
<body/> element包含human-readable的，用来表示消息的正文内容的XML字符数据；通常
message都会包含这个child，但它是可选的(OPTIONAL)。<body/> element绝对不能(MUST NOT)
包含除'xml:lang'之外的任何属性。一个message里面可以(MAY)包含多个<subject/> element。
但这仅限于每个<subject/>都包含'xml:lang'属性，并且其language值都不相同的情形。
<body/>绝对不能(MUST NOT)包含mixed content(见Section 3.2.2)
2.1.2.3. Thread
The <thread/> element contains non-human-readable XML character data
specifying an identifier that is used for tracking a conversation
thread (sometimes referred to as an "instant messaging session")
between two entities. The value of the <thread/> element is
generated by the sender and SHOULD be copied back in any replies. If
used, it MUST be unique to that conversation thread within the stream
and MUST be consistent throughout that conversation (a client that
receives a message from the same full JID but with a different thread
ID MUST assume that the message in question exists outside the
context of the existing conversation thread). The use of the
<thread/> element is OPTIONAL and is not used to identify individual
messages, only conversations. A message stanza MUST NOT contain more
than one <thread/> element. The <thread/> element MUST NOT possess
any attributes. The value of the <thread/> element MUST be treated
as opaque by entities; no semantic meaning may be derived from it,
and only exact comparisons may be made against it. The <thread/>
element MUST NOT contain mixed content (as defined in Section 3.2.2
of [XML]).
<thread/> element包含非human-readable的XML字符数据。它是一个用于表示两个entity
之间的conversion thread的(有时也被称作"instance messaging session")标识符。
<thread/> element的值由sender生成，而且每次回复的时候必须(SHOULD)包含在内。如果
用到了它，那么它必须(MUST)与stream里的conversation thread一一对应，而且整个谈话期间
必须保持一致(如果client端收到了同一个JID发出的，但是thread ID不同的message，必须(MUST)
认定这个消息与当前的conversation thread无关。)<thread/> element是OPTIONAL的，
且不用于标识单个message，它是用来标识conversation的。一个message stanza MUST NOT
包含二个或二个以上的<thread/> element。<thread> element MUST NOT包含任何属性。
对entities来说<thread/>的值必须(MUST)是不透明的；不能用它来获取任何语义信息，而且只能
对它进行精确地比较。<thread/> MUST NOT包含mixed content(Section 3.2.2)
2.2. Presence Syntax
Presence stanzas are used qualified by the 'jabber:client' or
'jabber:server' namespace to express an entity's current network
availability (offline or online, along with various sub-states of the
latter and optional user-defined descriptive text), and to notify
other entities of that availability. Presence stanzas are also used
to negotiate and manage subscriptions to the presence of other
entities.
Presence stanza属于'jabber:client'或'jabber:server'名字空间，它们是用来表示
entity的当前网络可得性(offline还是online，此外后者还有很多sub-state和可选的用户
自定义的叙述性文字)，并且将其通知给其它entities的。Persence stanzas也被用于协商
和管理订阅其它entities的presence信息。
2.2.1. Types of Presence
The 'type' attribute of a presence stanza is OPTIONAL. A presence
stanza that does not possess a 'type' attribute is used to signal to
the server that the sender is online and available for communication.
If included, the 'type' attribute specifies a lack of availability, a
request to manage a subscription to another entity's presence, a
request for another entity's current presence, or an error related to
a previously-sent presence stanza. If included, the 'type' attribute
MUST have one of the following values:
presence stanza的'type'属性是OPTIONAL的。不带'type'属性的presence stanza
是用来通知服务器sender已经上线，并且available for communication。如果有，那么这个
'type'或者用来表示可得性方面的限制，或者用来管理订阅其它用户的presence信息，或者用于
查询其它用户的当前可得性，或者是先前发送的presence stanza出了错。如果有，'type'属性
MUST是下列值中的一个:
o unavailable -- Signals that the entity is no longer available for
communication.
unavailable -- 表示entity不再available for communication了
o subscribe -- The sender wishes to subscribe to the recipient's
presence.
subscribe -- sender希望能订阅recipent的presence信息
o subscribed -- The sender has allowed the recipient to receive
their presence.
subscribed -- 发送方同意让接受方订阅自己的在线信息
o unsubscribe -- The sender is unsubscribing from another entity's
presence.
unsubscribe -- 发送方取消订阅另一方的在线信息
o unsubscribed -- The subscription request has been denied or a
previously-granted subscription has been cancelled.
unsubscribed -- 订阅请求被拒绝或者先前授予的订阅权限被撤销了
o probe -- A request for an entity's current presence; SHOULD be
generated only by a server on behalf of a user.
probe -- 请求entity的当前在线信息；只有(SHOULD)server才能代表用户去生成此类信息。
o error -- An error has occurred regarding processing or delivery of
a previously-sent presence stanza.
error -- 先前发送的presence stanza在处理或投送过程中出现了错误。
For detailed information regarding presence semantics and the
subscription model used in the context of XMPP-based instant
messaging and presence applications, refer to Exchanging Presence
Information (Section 5) and Managing Subscriptions (Section 6).
要想详细了解相关信息，请参阅Section 5 Exchanging Presence Information
和Section 6 Managing Subscriptions。
2.2.2. Child Elements
As described under extended namespaces (Section 2.4), a presence
stanza MAY contain any properly-namespaced child element.
就像Section 2.4的扩展名字空间所说的，presence stanza 可以包含任何
properly-namespaced的child element。
In accordance with the default namespace declaration, by default a
presence stanza is qualified by the 'jabber:client' or
'jabber:server' namespace, which defines certain allowable children
of presence stanzas. If the presence stanza is of type "error", it
MUST include an <error/> child; for details, see [XMPP-CORE]. If the
presence stanza possesses no 'type' attribute, it MAY contain any of
the following child elements (note that the <status/> child MAY be
sent in a presence stanza of type "unavailable" or, for historical
reasons, "subscribe"):
为了与默认的名字空间的声明保持一致，默认的presence stanza被归在'jabber:client'
或'jabber:server'名字空间之下，这两个名字空间还定义了一些被认可的presence stanza
的children。如果presence stanza是'error'类型的，那么它MUST包含<error/>；细节请看
[XMPP-CORE]。如果presence stanza没有'type'属性，那么它MAY包含下列child element
(注意，<status/> child可以随'unavailable' type的presence stanza或，出于历史原因，
'subscribe' type的presence stanza发出。)
1. <show/>
2. <status/>
3. <priority/>
RFC_3921/stuff
Revision 1 as of 2005-07-06 03:29:21
Clear message