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/>
2.2.2.1. Show
The OPTIONAL <show/> element contains non-human-readable XML
character data that specifies the particular availability status of
an entity or specific resource. A presence stanza MUST NOT contain
more than one <show/> element. The <show/> element MUST NOT possess
any attributes. If provided, the XML character data value MUST be
one of the following (additional availability types could be defined
through a properly-namespaced child element of the presence stanza):
OPTIONAL的<show/> element包含非human-readable的XML字符数据。它表示某个entity
或资源的可得性。presence stanza绝对不能(MUST NOT)包含两个或两个以上的<show/>。
<show/> MUST NOT包含任何属性。如果(presence stanza)里有(<show/>)，那么它的XML
字符数据必须(MUST)是下列值中的一个(你还可以通过presence stanza的child element，
在适当的名字空间里定义更多的类型。)
o away -- The entity or resource is temporarily away.
away -- 这个entity或资源暂时不可得。
o chat -- The entity or resource is actively interested in chatting.
chat -- 这个entity或资源正在chatting。
o dnd -- The entity or resource is busy (dnd = "Do Not Disturb").
dnd -- 这个entity或资源正忙(dnd = 'Do Not Disturb')。
o xa -- The entity or resource is away for an extended period (xa =
"eXtended Away").
xa -- 这个entity或资源要离线一段时间 (xa = eXtended Away)
If no <show/> element is provided, the entity is assumed to be online
and available.
如果没有<show/> element，那么这个entity就将被认为是可得的。
2.2.2.2. Status
The OPTIONAL <status/> element contains XML character data specifying
a natural-language description of availability status. It is
normally used in conjunction with the show element to provide a
detailed description of an availability state (e.g., "In a meeting").
The <status/> element MUST NOT possess any attributes, with the
exception of the 'xml:lang' attribute. Multiple instances of the
<status/> element MAY be included but only if each instance possesses
an 'xml:lang' attribute with a distinct language value.
OPTIONAL的<status/> element包含了用人类语言描述的可得性状态的XML字符数据。通常它会
和<show/> element一起使用，以提供可得性状态的详细描述(比方说"在开会")。<status/>
MUST NOT包含除xml:lang之外的任何属性。presence stanza里面可以(MAY)包含多个<status/>，
只是每个<status/>都必须包含一个xml:lang属性并且其language的值不同。
2.2.2.3. Priority
The OPTIONAL <priority/> element contains non-human-readable XML
character data that specifies the priority level of the resource. The
value MUST be an integer between -128 and +127. A presence stanza
MUST NOT contain more than one <priority/> element. The <priority/>
element MUST NOT possess any attributes. If no priority is provided,
a server SHOULD consider the priority to be zero. For information
regarding the semantics of priority values in stanza routing within
instant messaging and presence applications, refer to Server Rules
for Handling XML Stanzas (Section 11).
OPTIONAL的<priority/> element包含非human-readable的，表示资源优先级的XML字符数据。
它的值MUST是一个介于-128到+127之间的整数。presence stanza MUST NOT包含两个或
两个以上的<priority/>元素。<priority/>元素MUST NOT包含任何属性。如果(presence
stanza)没有提供<priority/>，那么服务器SHOULD认为它的优先级为0。至于优先级的值是怎样
影响stanza的路由的，请参阅Server Rules for Handling XML Stanzas (Section 11)。
2.3. IQ Syntax
IQ 的语法
IQ stanzas provide a structured request-response mechanism. The
basic semantics of that mechanism (e.g., that the 'id' attribute is
REQUIRED) are defined in [XMPP-CORE], whereas the specific semantics
required to complete particular use cases are defined in all cases by
an extended namespace (Section 2.4) (note that the 'jabber:client'
and 'jabber:server' namespaces do not define any children of IQ
stanzas other than the common <error/>). This memo defines two such
extended namespaces, one for Roster Management (Section 7) and the
other for Blocking Communication (Section 10); however, an IQ stanza
MAY contain structured information qualified by any extended
namespace.
IQ stanza提供了一个结构化的"请求-回答"(request-response)机制。这一机制的基本语义
(比方说'id'属性是REQUIRED的)由[XMPP-CORE]定义，而用于某项use case的专属语义则
通过"扩展的名字空间(extended namespace)"由这个case定义(注意，'jabber:client'和
'jabber:server'名字空间除了常用的<error/>之外没有再定义别的IQ stanza的child)。
本文档定义了两个这类extended namespace，一个是Roster Management (Section 7)
另一个是Blocking Communication (Section 10)。但是IQ stanza MAY包含任何扩展
名字空间之下的结构化信息。
2.4. Extended Namespaces
While the three XML stanza kinds defined in the "jabber:client" or
"jabber:server" namespace (along with their attributes and child
elements) provide a basic level of functionality for messaging and
presence, XMPP uses XML namespaces to extend the stanzas for the
purpose of providing additional functionality. Thus a message or
presence stanza MAY contain one or more optional child elements
specifying content that extends the meaning of the message (e.g., an
XHTML-formatted version of the message body), and an IQ stanza MAY
contain one such child element. This child element MAY have any name
and MUST possess an 'xmlns' namespace declaration (other than
"jabber:client", "jabber:server", or
"http://etherx.jabber.org/streams") that defines all data contained
within the child element.
虽然'jabber:client'和'jabber:server'名字空间所定义的这三个XML stanza(及其属性和
child element)提供了基本的IM和presence的功能，但为了能提供更多的功能，XMPP还允许你
用XML的名字空间来扩展stanza。这样一来，message和presence stanza MAY包含一个
或多个child elements，并以此来扩展消息的内容(比方说XHTML的消息正文)，而IQ stanza
MAY包含一个这样的child element。这个child element可以'MAY'是任何名字，但是MUST包含
定义了这些child element的数据的'xmlns'名字空间的声明(不能是'jabber:client',
'jabber:server'或'http://etherx.jabber.org/streams')。
Support for any given extended namespace is OPTIONAL on the part of
any implementation (aside from the extended namespaces defined
herein). If an entity does not understand such a namespace, the
entity's expected behavior depends on whether the entity is (1) the
recipient or (2) an entity that is routing the stanza to the
recipient:
implementation可以自行决定(OPTIONAL)是否支持这些扩展名字空间(这里定义的名字空间除外)。
如果entity不知道这个名字空间，那么其行为将由(1)接受方或(2)将stanza路由到接受方的entity
决定。
Recipient: If a recipient receives a stanza that contains a child
element it does not understand, it SHOULD ignore that specific XML
data, i.e., it SHOULD not process it or present it to a user or
associated application (if any). In particular:
接受方：如果接受方收到一个包含它不认识的child element的stanza，那么它SHOULD忽略
这个XML数据。比方说，它SHOULD不处理，或者把它交给用户，或相关的程序(如果有的话)。
特别是：
* If an entity receives a message or presence stanza that
contains XML data qualified by a namespace it does not
understand, the portion of the stanza that is in the unknown
namespace SHOULD be ignored.
如果一个entity收到的message或presence stanza里面包含了它所不认识的namespace
的XML数据的话，那么它SHOULD忽略这部分未知的namespace的stanza。
* If an entity receives a message stanza whose only child element
is qualified by a namespace it does not understand, it MUST
ignore the entire stanza.
如果一个entity收到的message stanza里面只有一个child element，且这个element
属于一个它不认识的namespace，那么它MUST忽略这整个stanza。
* If an entity receives an IQ stanza of type "get" or "set"
containing a child element qualified by a namespace it does not
understand, the entity SHOULD return an IQ stanza of type
"error" with an error condition of <service-unavailable/>.
如果entity收到的'get'或'set'类型的IQ stanza里包含一个它所不认识的namespace
的child element的话，那么这个entity SHOULD回一个error condition为
<service-unavailable/>的'error'类型的IQ stanza。
Router: If a routing entity (usually a server) handles a stanza that
contains a child element it does not understand, it SHOULD ignore
the associated XML data by passing it on untouched to the
recipient.
Router: 如果路由方(通常是服务器)碰到一个含有它不认识的child element的stanza的话，
那么它SHOULD不管这些XML数据，把它们原封不动地传给接受方。
3. Session Establishment
Most instant messaging and presence applications based on XMPP are
implemented via a client-server architecture that requires a client
to establish a session on a server in order to engage in the expected
instant messaging and presence activities. However, there are
several pre-conditions that MUST be met before a client can establish
an instant messaging and presence session. These are:
绝大多数基于XMPP的IM和presence应用程序都是以client-server形式实现的，这种模式要求
客户与服务器建立会话以进行IM和presence活动。但是在客户端建立IM和presence会话之前，还
必须(MUST)满足几个前提条件。它们是：
1. Stream Authentication -- a client MUST complete stream
authentication as documented in [XMPP-CORE] before attempting to
establish a session or send any XML stanzas.
Stream Authentication(流认证) -- 正如[XMPP-CORE]所刊载的，在试图建立会话
并发送XML stanza之前，客户MUST完成流认证。
2. Resource Binding -- after completing stream authentication, a
client MUST bind a resource to the stream so that the client's
address is of the form <user@domain/resource>, after which the
entity is now said to be a "connected resource" in the
terminology of [XMPP-CORE].
资源绑定 -- 流认证完毕之后，客户MUST在这个流上绑定资源，这样客户的地址才会符合
<user@domain/resouce>的格式。只有在做完这些之后，entity才能被视作是[XMPP-CORE]
所称的'在线资源(connected resource)'。
If a server supports sessions, it MUST include a <session/> element
qualified by the 'urn:ietf:params:xml:ns:xmpp-session' namespace in
the stream features it advertises to a client after the completion of
stream authentication as defined in [XMPP-CORE]:
如果服务器支持会话，那么在完成[XMPP-CORE]所定义的stream authentication之后，它MUST
在向client公告的stream feature里面包含一个'urn:ietf:params:xml:ns:xmpp-session'
名字空间下的<session/> element。
Server advertises session establishment feature to client:
服务器向客户公告会话建立的功能:
<stream:stream
xmlns='jabber:client'
xmlns:stream='http://etherx.jabber.org/streams'
id='c2s_345'
from='example.com'
version='1.0'>
<stream:features>
<bind xmlns='urn:ietf:params:xml:ns:xmpp-bind'/>
<session xmlns='urn:ietf:params:xml:ns:xmpp-session'/>
</stream:features>
Upon being so informed that session establishment is required (and
after completing resource binding), the client MUST establish a
session if it desires to engage in instant messaging and presence
functionality; it completes this step by sending to the server an IQ
stanza of type "set" containing an empty <session/> child element
qualified by the 'urn:ietf:params:xml:ns:xmpp-session' namespace:
客户端会如此这般地被告知必须先建立session(并且在绑定资源)，如果它想使用IM和presence
功能，就MUST先建立session。这一步是通过向sever发一个'set'类型的，包含一个空的
<session/> child element的，归在'urn:ietf:params:xml:ns:xmpp-session'名字空间
之下的IQ stanza来完成的。
Step 1: Client requests session with server:
第一步：客户向server请求会话：
<iq to='example.com'
type='set'
id='sess_1'>
<session xmlns='urn:ietf:params:xml:ns:xmpp-session'/>
</iq>
Step 2: Server informs client that session has been created:
第二步：服务器通知客户，会话已经创建完毕：
<iq from='example.com'
type='result'
id='sess_1'/>
Upon establishing a session, a connected resource (in the terminology
of [XMPP-CORE]) is said to be an "active resource".
创建完会话之后，'在线资源'(具体术语的含义，请参阅[XMPP-CORE])就会被认为是active的了。
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 resource
associated with a resource identifier of the same name.
这里有可能会出现几种错误。比方说，服务器端可能会出现妨碍它创建会话的情况，像用户名或提请认证
的身份未获许可，或者这个active resource已经同某个同名的resource identifier(资源标识符)
联系在一起了。
If the server encounters an internal condition that prevents it from
creating the session, it MUST return an error.
如果服务器端碰到了妨碍它创建会话的情况，那它MUST返回一个error。
Step 2 (alt): Server responds with error (internal server error):
第二步(亦有可能出现)：服务器端以error回答(internal server error):
<iq from='example.com' type='error' id='sess_1'>
<session xmlns='urn:ietf:params:xml:ns:xmpp-session'/>
<error type='wait'>
<internal-server-error
xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
</error>
</iq>
If the username or resource is not allowed to create a session, the
server MUST return an error (e.g., forbidden).
如果用户名或资源未被允许创建会话，那么服务器MUST返回一个error(也就是，禁止)
Step 2 (alt): Server responds with error (username or resource not
allowed to create session):
第二步(亦有可能出现)：服务器端以error回答(此用户名或资源不允许创建会话):
<iq from='example.com' type='error' id='sess_1'>
<session xmlns='urn:ietf:params:xml:ns:xmpp-session'/>
<error type='auth'>
<forbidden
xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
</error>
</iq>
If there is already an active resource of the same name, the server
MUST either (1) terminate the active resource and allow the
newly-requested session, or (2) disallow the newly-requested session
and maintain the active resource. Which of these the server does is
up to the implementation, although it is RECOMMENDED to implement
case #1. In case #1, the server SHOULD send a <conflict/> stream
error to the active resource, terminate the XML stream and underlying
TCP connection for the active resource, and return a IQ stanza of
type "result" (indicating success) to the newly-requested session. In
case #2, the server SHOULD send a <conflict/> stanza error to the
newly-requested session but maintain the XML stream for that
connection so that the newly-requested session has an opportunity to
negotiate a non-conflicting resource identifier before sending
another request for session establishment.
如果这个名字已经同某个active resource绑在一起了，服务器必须要么(1)中止active resource
然后让新请求的session进来，要么(2)拒绝新请求的session，同时保持这个active resource.
虽然我们RECOMMEND(推荐)采用＃1，但具体情况还视实现决定。在case #1下，server SHOULD
给active resource发一个<conflict/> stream error，并且中止连接这个active resource
的XML流和TCP连接，然后给新会话发一个'result' type(表示成功)的IQ stanza。在case #2
下，server SHOULD发送一个<conflict/> stanza错误给新的会话请求，但它必须保持这条XML
stream，这样再再次发送建立会话的请求之前，新请求的会话就有机会来协商一个不会引起冲突的
资源表示符了。
Step 2 (alt): Server informs existing active resource of resource
conflict (case #1):
第二步(亦有可能出现)：服务器端告诉已连接的active resource，资源冲突(case #1):
<stream:error>
<conflict xmlns='urn:ietf:params:xml:ns:xmpp-streams'/>
</stream:error>
</stream:stream>
Step 2 (alt): Server informs newly-requested session of resource
conflict (case #2):
第二步(亦有可能出现)：服务器端告诉新申请的会话，出现资源冲突(#case 2)：
<iq from='example.com' type='error' id='sess_1'>
<session xmlns='urn:ietf:params:xml:ns:xmpp-session'/>
<error type='cancel'>
<conflict xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
</error>
</iq>
After establishing a session, a client SHOULD send initial presence
and request its roster as described below, although these actions are
OPTIONAL.
建完会话之后，客户端应当(SHOULD)如下面所说的，发送初始在线信息并请求roster，不过这些
活动都是OPTIONAL的。
Note: Before allowing the creation of instant messaging and presence
sessions, a server MAY require prior account provisioning. Possible
methods for account provisioning include account creation by a server
administrator as well as in-band account registration using the
'jabber:iq:register' namespace; the latter method is out of scope for
this memo, but is documented in [JEP-0077], published by the Jabber
Software Foundation [JSF].
注意：在接纳IM和presence session之前，服务器 MAY 要求客户端事先提供帐号。
提供帐号的方法包括，由服务器的管理员创建帐号，或者用'jabber:iq:register'名字空间
的stanza注册'in-band account';后一种方法超出了本文档的范围，不过它刊载在JSF发布的
[JEP-0077]里面。
4. Exchanging Messages
Exchanging messages is a basic use of XMPP and is brought about when
a user generates a message stanza that is addressed to another
entity. As defined under Server Rules for Handling XML Stanzas
(Section 11), 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).
传递消息是XMPP的基本用途，当用户生成一个message stanza并将它发送给另一个entity的时候
这事就发生了。正如Server Rules for Handling XML Stanzas(Section 11)所定义的，
(如果接受发和发送方使用的是同一个服务器)发送方的服务器要负责将消息发给接受方，(如果发送方和
接收发使用的是不同的服务器)，那发送方的服务器要负责将消息路由至接受方分服务器。
For information regarding the syntax of message stanzas as well as
their defined attributes and child elements, refer to Message Syntax
(Section 2.1).
要想知道message stanza的语法及其定义的属性和child element，请参阅Message Syntax
(Secion 2.1)
4.1. Specifying an Intended Recipient
指定接受方
An instant messaging 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 <message/> 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 of the form
<user@domain/resource> rather than of the form <user@domain> unless
the sender has knowledge (via presence) that the intended recipient's
resource 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 of the form <user@domain/resource>.
IM的客户SHOULD在<message/> stanza的'to'属性里提供一个与sender不同的JID，并以此
指定这条消息的接受方。如果这条消息是回应先前收到的，来自<user@domain/resource>的
消息的(比方说在一个chat session里)，那么'to'地址仍然SHOULD是<user@domain/resource>
而不是<user@domain>，除非发送方知道(通过presence)，接受方的资源已经不可得了。如果
发送的消息不在任何现存的chat session或received message环境下，'to'地址的值SHOULD
是<user@domain>而不是<user@domain/resource>形式的。
4.2. Specifying a Message Type
As noted, it is RECOMMENDED for a message stanza to possess a 'type'
attribute whose value captures the conversational context (if any) of
the message (see Type (Section 2.1.1)).
注意，推荐("RECOMMENDED")一个消息占用"type"属性，让消息的会话读取它
The following example shows a valid value of the 'type' attribute:
下面的例子展示了使用一个有效的"type"属性值
Example: A message of a defined type:
<message
to='[email protected]'
from='[email protected]/balcony'
type='chat'
xml:lang='en'>
<body>Wherefore art thou, Romeo?</body>
</message>
4.3. Specifying a Message Body
A message stanza MAY (and often will) contain a child <body/> element
whose XML character data specifies the primary meaning of the message
(see Body (Section 2.1.2.2)).
一个消息"stanza"可能("MAY")（经常）包含一个<body>子节点，它的XML字符指示消息
的含义（见第2.1.2.2节）。
Example: A message with a body:
<message
to='[email protected]'
from='[email protected]/balcony'
type='chat'
xml:lang='en'>
<body>Wherefore art thou, Romeo?</body>
<body xml:lang='cz'>PročeŽ jsi ty, Romeo?</body>
</message>
4.4. Specifying a Message Subject
A message stanza MAY contain one or more child <subject/> elements
specifying the topic of the message (see Subject (Section 2.1.2.1)).
一个消息"stanza"可能("MAY")包含一个<subject>子节点指示消息
的主题（见第2.1.2.1节）。
Saint-Andre Standards Track [Page 14]
RFC 3921 XMPP IM October 2004
Example: A message with a subject:
<message
to='[email protected]'
from='[email protected]/balcony'
type='chat'
xml:lang='en'>
<subject>I implore you!</subject>
<subject
xml:lang='cz'>Úpěnlivě prosim!</subject>
<body>Wherefore art thou, Romeo?</body>
<body xml:lang='cz'>PročeŽ jsi ty, Romeo?</body>
</message>
4.5. Specifying a Conversation Thread
A message stanza MAY contain a child <thread/> element specifying the
conversation thread in which the message is situated, for the purpose
of tracking the conversation (see Thread (Section 2.1.2.3)).
一个消息"stanza"可能("MAY")包含一个<thread>子节点指示了消息位于哪一个会话线索，
以便跟踪会话。（见第2.1.2.3节）。
Example: A threaded conversation:
<message
to='[email protected]/orchard'
from='[email protected]/balcony'
type='chat'
xml:lang='en'>
<body>Art thou not Romeo, and a Montague?</body>
<thread>e0ffe42b28561960c6b12b944a092794b9683a38</thread>
</message>
<message
to='[email protected]/balcony'
from='[email protected]/orchard'
type='chat'
xml:lang='en'>
<body>Neither, fair saint, if either thee dislike.</body>
<thread>e0ffe42b28561960c6b12b944a092794b9683a38</thread>
</message>
<message
to='[email protected]/orchard'
from='[email protected]/balcony'
type='chat'
xml:lang='en'>
<body>How cam'st thou hither, tell me, and wherefore?</body>
<thread>e0ffe42b28561960c6b12b944a092794b9683a38</thread>
</message>
Saint-Andre Standards Track [Page 15]
RFC 3921 XMPP IM October 2004
5. Exchanging Presence Information
Exchanging presence information is made relatively straightforward
within XMPP by using presence stanzas. However, we see here a
contrast to the handling of messages: although a client MAY send
directed presence information to another entity by including a 'to'
address, normally presence notifications (i.e., presence stanzas with
no 'type' or of type "unavailable" and with no 'to' address) are sent
from a client to its server and then broadcasted by the server to any
entities that are subscribed to the presence of the sending entity
(in the terminology of RFC 2778 [IMP-MODEL], these entities are
subscribers). This broadcast model does not apply to
subscription-related presence stanzas or presence stanzas of type
"error", but to presence notifications only as defined above. (Note:
While presence information MAY be provided on a user's behalf by an
automated service, normally it is provided by the user's client.)
（）。然而，我们将它与消息处理对照：尽管一个客户端可能(MAY)通过指定一个"to"属性地
址值来直接发送"presence"信息到另一个实体，但通常"presence"通知是从客户端发送到它的
服务器，然后被服务器广播到任何订阅了这个发送实体的"presence"信息的实体()。这个广播
机制不能应用于与订阅相关的"presence"和"type"值为"error"的"presence",但对于其它
"presence"如上。(注意：为用户的利益"presence"可能会被一个自动服务所自动发送，但通
常它是用户的客户端提供。)
For information regarding the syntax of presence stanzas as well as
their defined attributes and child elements, refer to [XMPP-CORE].
5.1. Client and Server Presence Responsibilities
5.1.1. Initial Presence
After establishing a session, a client SHOULD send initial presence
to the server in order to signal its availability for communications.
As defined herein, the initial presence stanza (1) MUST possess no
'to' address (signalling that it is meant to be broadcasted by the
server on behalf of the client) and (2) MUST possess no 'type'
attribute (signalling the user's availability). After sending
initial presence, an active resource is said to be an "available
resource".
在建立一个"session"后，一个客户端为了通信可用应该("SHOULD")发送一个初始化"presence"
给服务器。在这里详细说明，初始化"presence"(1)必须("MUST")不能有"to"地址(意味着服务器
将代表客户端将它广播出去)以及(2)必须("MUST")不能有"type"属性(表示用户的可用性)。发送
初始化"presence"后，一个活动的"resource"将说有一个"available resource".
Upon receiving initial presence from a client, the user's server MUST
do the following if there is not already one or more available
resources for the user (if there is already one or more available
resources for the user, the server obviously does not need to send
the presence probes, since it already possesses the requisite
information):
在从一个客户端收到初始化"presence"后，如果该用户不存在的一个或一个以上的可用"resource"，
用户的服务器必须("MUST")做下面的事情(如果该用户已存在的一个或一个以上的可用"resource"，
服务器明显地不需要发送一个"presence"探针,因为它已经持有必要的信息了)：
1. Send presence probes (i.e., presence stanzas whose 'type'
attribute is set to a value of "probe") from the full JID (e.g.,
<[email protected]/resource>) of the user to all contacts to which
the user is subscribed in order to determine if they are
available; such contacts are those for which a JID is present in
the user's roster with the 'subscription' attribute set to a
value of "to" or "both". (Note: The user's server MUST NOT send
presence probes to contacts from which the user is blocking
Saint-Andre Standards Track [Page 16]
RFC 3921 XMPP IM October 2004
inbound presence notifications, as described under Blocking
Inbound Presence Notifications (Section 10.10).)
发送一个"from"为用户的完整JID的"presence"探针（也就是"presence"的"stanza"的
"type"属性值设为"probe"）给它的所有联系人，来订阅他们的"presence"以决定他们是否
可用；这些联系人是在用户的花名薄("roster")中联系人的"subscription"属性值设为
"to"和"both"的（）。
2. Broadcast initial presence from the full JID (e.g.,
<[email protected]/resource>) of the user to all contacts that are
subscribed to the user's presence information; such contacts are
those for which a JID is present in the user's roster with the
'subscription' attribute set to a value of "from" or "both".
(Note: The user's server MUST NOT broadcast initial presence to
contacts to which the user is blocking outbound presence
notifications, as described under Blocking Outbound Presence
Notifications (Section 10.11).)
广播一个"from"为用户的完整JID的初始化"presence"给所有订阅了用户的"presence"信息的
联系人；这些联系人是在用户的花名薄("roster")中联系人的"subscription"属性值设为"from"］
和"both"的，（注意当用户封掉了出"presence"(outbound presence)通知的发送时，用户的服务
器必须不能("MUST NOT")广播初始化"presence"，封闭出"presence"(outbound presence)通知
的发送的描述见第10。11）。
In addition, the user's server MUST broadcast initial presence from
the user's new available resource to any of the user's existing
available resources (if any).
另外，用户的服务器必须("MUST")广播一个来于用户新可用"resource"的初始化"presence"给用户已存
在的可能的"resource"
Upon receiving initial presence from the user, the contact's server
MUST deliver the user's presence stanza to the full JIDs
(<[email protected]/resource>) associated with all of the contact's
available resources, but only if the user is in the contact's roster
with a subscription state of "to" or "both" and the contact has not
blocked inbound presence notifications from the user's bare or full
JID (as defined under Blocking Inbound Presence Notifications
(Section 10.10)).
在从用户那里收到一个初始化"presence",联系人的服务器必须("MUST")传递用户的"presence stanza"
到联系人的所有可用资源关联的完整JID(<[email protected]/resource>),但仅是如果用户在联系人的花
名薄("roster")中且"subscription"状态为"to"或"both"，联系人没有封掉从用户的赤裸的或完整的
jid时接收入"presence"(inbound presence)（封闭入"presence"(inbound presence)通知的接收的描述
见第10。11）。
If the user's server receives a presence stanza of type "error" in
response to the initial presence that it sent to a contact on behalf
of the user, it SHOULD NOT send further presence updates to that
contact (until and unless it receives a presence stanza from the
contact).
如果用户的服务器代表用户发送初始化"presence"时在回复中接收到一个"error"类型的"presence stance"，它
将不(SHOULD NOT )发送后续的"presence"信息组这个联系人(直到或除非它从这个用户收到一个"presence stance")。
5.1.2. Presence Broadcast
After sending initial presence, the user MAY update its presence
information for broadcasting at any time during its session by
sending a presence stanza with no 'to' address and either no 'type'
attribute or a 'type' attribute with a value of "unavailable". (Note:
A user's client SHOULD NOT send a presence update to broadcast
information that changes independently of the user's presence and
availability.)
在发送初始化"presence"后，用户可能("MAY")在它的会话期间通过发送一个没有"to"地址
以及没有"type"或有一个值为"unavailable"的"type"属性的"presence stanza"来广播
更新它的"presence"信息。(注意：)
If the presence stanza lacks a 'type' attribute (i.e., expresses
availability), the user's server MUST broadcast the full XML of that
presence stanza to all contacts (1) that are in the user's roster
with a subscription type of "from" or "both", (2) to whom the user
Saint-Andre Standards Track [Page 17]
RFC 3921 XMPP IM October 2004
has not blocked outbound presence notifications, and (3) from whom
the server has not received a presence error during the user's
session (as well as to any of the user's other available resources).
如果"presence stanza"没有"type"属性(也就是，表示可用)，用户的服务器必须("MUST")广播
它到所有的联系人(1):在用户的花名薄("roster")中"subscription"值为"from"或"both"(2)
用户没用封掉出"presence"("outbound presence"),(3)在用户的会话期间服务器没有收一个
"presence"错误。
If the presence stanza has a 'type' attribute set to a value of
"unavailable", the user's server MUST broadcast the full XML of that
presence stanza to all entities that fit the above description, as well as
to any entities to which the user has sent directed available
presence during the user's session (if the user has not yet sent
directed unavailable presence to that entity).
如果"presence stanza"有一个值为"unavailable"的"type"属性，用户的服务器必须("MUST")广播
它到所有符合上面描述的实体，
5.1.3. Presence Probes
Upon receiving a presence probe from the user, the contact's server
SHOULD reply as follows:
在从用户那里接收到一个"presence"探针("Presence Probes")后，联系人的服务器应该("SHOULD")
象下面那样回答：
1. If the user is not in the contact's roster with a subscription
state of "From", "From + Pending Out", or "Both" (as defined
under Subscription States (Section 9)), the contact's server MUST
return a presence stanza of type "error" in response to the
presence probe (however, if a server receives a presence probe
from a subdomain of the server's hostname or another such trusted
service, it MAY provide presence information about the user to
that entity). Specifically:
如果用户在联系人的花名薄("roster")中"subscription"值不是"From", "From + Pending Out",或
"Both"(见Subscription States (第 9 节))，联系人的服务器必须("MUST")回复"presence"探针
("Presence Probes")(然而，如果一个服务器从一个服务器子域或另一个信任的服务收到一个"presence"
探针("Presence Probes")，它可能("MAY")提供关于这个实体的"presence"信息)返回一个类型为"error"
的"presence stanza"。
* if the user is in the contact's roster with a subscription
state of "None", "None + Pending Out", or "To" (or is not in
the contact's roster at all), the contact's server MUST return
a <forbidden/> stanza error in response to the presence probe.
如果用户在联系人的花名薄("roster")中"subscription"值是"None", "None + Pending Out",或
"To"(或不在联系人的花名薄("roster")中)，联系人的服务器必须("MUST")在回复"presence"探针中返回一
个类型为"forbidden"的"stanza"错误。
* if the user is in the contact's roster with a subscription
state of "None + Pending In", "None + Pending Out/In", or "To
+ Pending In", the contact's server MUST return a
<not-authorized/> stanza error in response to the presence
probe.
如果用户在联系人的花名薄("roster")中"subscription"值是"None", "None + Pending In",或
, "None + Pending Out/In"，或"To+ Pending In"，联系人的服务器必须("MUST")在回复"presence"
探针中返回一个类型为"not-authorized"的"stanza"错误。
2. Else, if the contact is blocking presence notifications to the
user's bare JID or full JID (using either a default list or
active list as defined under Blocking Outbound Presence
Notifications (Section 10.11)), the server MUST NOT reply to the
presence probe.
否则，如果联系人封了用户赤裸的或完整的jid（见10.11）的"presence"通知，服务器必须不
("MUST NOT")回复"presence"探针
3. Else, if the contact has no available resources, the server MUST
either (1) reply to the presence probe by sending to the user the
full XML of the last presence stanza of type "unavailable"
received by the server from the contact, or (2) not reply at all.
否则，如果联系人没有可用资源，服务器必须("MUST")（1）通过服务器发送一个来自于联系人、类
型为"unavailable"的"presence stanza"回复"presence"探针，或者(2)任何时侯都不回复。
Saint-Andre Standards Track [Page 18]
RFC 3921 XMPP IM October 2004
4. Else, if the contact has at least one available resource, the
server MUST reply to the presence probe by sending to the user
the full XML of the last presence stanza with no 'to' attribute
received by the server from each of the contact's available
resources (again, subject to privacy lists in force for each
session).
否则，如果联系人至少有一个可用资源，服务器必须("MUST")通过服务器发送一个来自于联系人每一
个可用资源、没有"to"属性的最后一次"presence stanza"回复"presence"探针( )。
5.1.4. Directed Presence
A user MAY send directed presence to another entity (i.e., a presence
stanza with a 'to' attribute whose value is the JID of the other
entity and with either no 'type' attribute or a 'type' attribute
whose value is "unavailable"). There are three possible cases:
一个用户可能("MAY")发送直接的"presence"("directed presence")到另一个实体(也就是，一个
"to"属性值为其它实体的JID、没有"type"属性或"type"属性值为"unavailable"的"presence").
可能有三件事情发生：
1. If the user sends directed presence to a contact that is in the
user's roster with a subscription type of "from" or "both" after
having sent initial presence and before sending unavailable
presence broadcast, the user's server MUST route or deliver the
full XML of that presence stanza (subject to privacy lists) but
SHOULD NOT otherwise modify the contact's status regarding
presence broadcast (i.e., it SHOULD include the contact's JID in
any subsequent presence broadcasts initiated by the user).
如果用户在发送初始化"presence"("initial presence")后或发一个不可用"presence"
("unavailable presence")广播之前发送一个直接的"presence"("directed presence")给
一个在用户的的花名薄("roster")中"subscription"为 "from" 或 "both"的联系人，用户的服
务器必须("MUST")路由或传递它(服从私有列表)但不应该("SHOULD NOT")另外的修改关于的联系人
的"presence"广播的状态(也就是，它应该("SHOULD")在任何被用户初始化的并发"presence"广
播中包含联系人的JID)
2. If the user sends directed presence to an entity that is not in
the user's roster with a subscription type of "from" or "both"
after having sent initial presence and before sending unavailable
presence broadcast, the user's server MUST route or deliver the
full XML of that presence stanza to the entity but MUST NOT
modify the contact's status regarding available presence
broadcast (i.e., it MUST NOT include the entity's JID in any
subsequent broadcasts of available presence initiated by the
user); however, if the available resource from which the user
sent the directed presence become unavailable, the user's server
MUST broadcast that unavailable presence to the entity (if the
user has not yet sent directed unavailable presence to that
entity).
如果用户在发送初始化"presence"("initial presence")后或发一个不可用"presence"
("unavailable presence")广播之前发送一个直接的"presence"("directed presence")给
任何在用户的花名薄("roster")中"subscription"值不为 "from" 或 "both"的实体，用户的服
务器必须("MUST")路由或传递它(服从私有列表)但必须不("MUST NOT")另外的修改关于可用"presence"
广播的状态(也就是，它必须不("MUST NOT")在任何被用户初始化的并发"presence"广播中包含联
系人的JID)；然而，如果从用户发送直接的"presence"("directed presence")的可用资源变成
不可用时，用户的服务器必须("MUST")广播它到实体(如果用户没有发送不可用"presence"到那个实
体)。
3. If the user sends directed presence without first sending initial
presence or after having sent unavailable presence broadcast
(i.e., the resource is active but not available), the user's
server MUST treat the entities to which the user sends directed
presence in the same way that it treats the entities listed in
case #2 above.
如果在没发送一个初始化"presence"("initial presence")前或发送一个不可用"presence"
("unavailable presence")广播之后(也就是，资源活动但不可用)，用户的服务器必须("MUST")
Saint-Andre Standards Track [Page 19]
RFC 3921 XMPP IM October 2004
5.1.5. Unavailable Presence
Before ending its session with a server, a client SHOULD gracefully
become unavailable by sending a final presence stanza that possesses
no 'to' attribute and that possesses a 'type' attribute whose value
is "unavailable" (optionally, the final presence stanza MAY contain
one or more <status/> elements specifying the reason why the user is
no longer available). However, the user's server MUST NOT depend on
receiving final presence from an available resource, since the
resource may become unavailable unexpectedly or may be timed out by
the server. If one of the user's resources becomes unavailable for
any reason (either gracefully or ungracefully), the user's server
MUST broadcast unavailable presence to all contacts (1) that are in
the user's roster with a subscription type of "from" or "both", (2)
to whom the user has not blocked outbound presence, and (3) from whom
the server has not received a presence error during the user's
session; the user's server MUST also send that unavailable presence
stanza to any of the user's other available resources, as well as to
any entities to which the user has sent directed presence during the
user's session for that resource (if the user has not yet sent
directed unavailable presence to that entity). Any presence stanza
with no 'type' attribute and no 'to' attribute that is sent after
sending directed unavailable presence or broadcasted unavailable
presence MUST be broadcasted by the server to all subscribers.
在结束它与服务器的会话之前，一个客户端应该(SHOULD)优雅的发送最后一个没有"to"属性和"type"值
为"unavailable"(可选的，最后的"presence stanza"可能("MAY")包含一个或多个"status"子节点
指明用户不可用的原因)的"presence stanza"变成不可用。然而，用户的服务器必须不("MUST NOT")依
靠从一个可用的资源收到最后的"presence"，自从资源意外的变成不可用或服务器超时以来。如果用户的
资源中的一个因为某些原因(优雅的或不优雅的)变成不可用，用户的服务器必须("MUST")广播不可用"presence"
到所有的联系人(1)在用户的花名薄("roster")中"subscription"值为 "from" 或 "both"的,(2)用户
没有封掉出"presence"("outbound presence")，(3)用户会话期间没有收到一个"presence"错误；用
户的服务器必须("MUST")也要发送不可用"presence stanza"到用户的其它资源中的一个，也要发送给用
户会话期间曾发过直接"presence stanza"的资源的那些实体(如果还没有发过不可用"presence"给这些实
体)。任何在发送不可用直接"presence"或广播过不可用"presence"后没有"type"属性和没有"to"属性的
"presence"必须("MUST")被服务器广播到所有的订阅者。
5.1.6. Presence Subscriptions
A subscription request is a presence stanza whose 'type' attribute
has a value of "subscribe". If the subscription request is being
sent to an instant messaging contact, the JID supplied in the 'to'
attribute SHOULD be of the form <[email protected]> rather than
<[email protected]/resource>, since the desired result is normally
for the user to receive presence from all of the contact's resources,
not merely the particular resource specified in the 'to' attribute.
一个订阅请求是一个"type"属性值为"subscribe"的"presence stanza"。如果订阅请求
补发送给一个即时消息联系人，在"to"属性中提供的JID应该用 <[email protected]>
格式优先于<[email protected]/resource>格式，
A user's server MUST NOT automatically approve subscription requests
on the user's behalf. All subscription requests MUST be directed to
the user's client, specifically to one or more available resources
associated with the user. If there is no available resource
associated with the user when the subscription request is received by
the user's server, the user's server MUST keep a record of the
subscription request and deliver the request when the user next
creates an available resource, until the user either approves or
denies the request. If there is more than one available resource
associated with the user when the subscription request is received by
the user's server, the user's server MUST broadcast that subscription
request to all available resources in accordance with Server Rules
for Handling XML Stanzas (Section 11). (Note: If an active resource
Saint-Andre Standards Track [Page 20]
RFC 3921 XMPP IM October 2004
has not provided initial presence, the server MUST NOT consider it to
be available and therefore MUST NOT send subscription requests to
it.) However, if the user receives a presence stanza of type
"subscribe" from a contact to whom the user has already granted
permission to see the user's presence information (e.g., in cases
when the contact is seeking to resynchronize subscription states),
the user's server SHOULD auto-reply on behalf of the user. In addition
, the user's server MAY choose to re-send an unapproved
pending subscription request to the contact based on an
implementation-specific algorithm (e.g., whenever a new resource
becomes available for the user, or after a certain amount of time has
elapsed); this helps to recover from transient, silent errors that
may have occurred in relation to the original subscription request.
用户的服务器必须不("MUST NOT")能自动代表用户答应一个订阅请求。所有的订阅请求请必须("MUST")交
给用户处理，特别地用户有一个或多个可用资源，如果当用户的服务器收到订阅请求时没有与用户关联的资
源时，用户的服务器必须("MUST")保留这个订阅请求记录直到下一次用户创建一个资源时时传递给它，决定是
答应或拒绝。如果当用户的服务器收到订阅请求时有多个与用户关联的资源时，用户的服务器必须("MUST")
与处理xml stanza的服务器规则一致广播它到所有的可用资源。(注意：如一个资源没有提供初始化"presence"
，服务器必须不("MUST NOT")能认为它是可用的，因此必须不("MUST NOT")能发送订阅请求给它。)然而，
如果用户从一个联系人那里收到一个类型为"subscribe"的"presence stanza"，但用户已经允许它接收用
户的"presence"信息(也就是，万一联系人在同步它的"subscription"状态)，用户的服务器应该("SHOULD")
代表用户自动的回复。另外，用户的服务器可能("MAY")在一个特殊算法的基础上(例如，只要用户的一个新的资
源变成可用，或确认超时)选择重发一个未经同意的未决的订阅请求给联系人;这有助于接收者
5.2. Specifying Availability Status
A client MAY provide further information about its availability
status by using the <show/> element (see Show (Section 2.2.2.1)).
一个客户端可能("MAY")用<show/>节点提供关于它的可用性状态补充信息。
Example: Availability status:
例如: 可用性状态：
<presence>
<show>dnd</show>
</presence>
5.3. Specifying Detailed Status Information
In conjunction with the <show/> element, a client MAY provide
detailed status information by using the <status/> element (see
Status (Section 2.2.2.2)).
与<show/>节点一起，一个客户端可能("MAY")用<status/>节点提供关于它的详细状态信息。
Example: Detailed status information:
例如: 可用性状态详细状态信息：
<presence xml:lang='en'>
<show>dnd</show>
<status>Wooing Juliet</status>
<status xml:lang='cz'>Ja dvořím Juliet</status>
</presence>
Saint-Andre Standards Track [Page 21]
RFC 3921 XMPP IM October 2004
5.4. Specifying Presence Priority
A client MAY provide a priority for its resource by using the
<priority/> element (see Priority (Section 2.2.2.3)).
一个客户端可能("MAY")用<priority/>节点提供关于它的资源优先级。
Example: Presence priority:
<presence xml:lang='en'>
<show>dnd</show>
<status>Wooing Juliet</status>
<status xml:lang='cz'>Ja dvořím Juliet</status>
<priority>1</priority>
</presence>
5.5. Presence Examples
The examples in this section illustrate the presence-related
protocols described above. The user is [email protected], he has an
available resource whose resource identifier is "orchard", and he has
the following individuals in his roster:
在这节中例子展示了上面描述的关于"presence"协议。用户是" [email protected]",它有
一个资源标识为"orchard"的可用资源，它在它的花名薄("roster")中下列人士
o [email protected] (subscription="both" and she has two available
resources, one whose resource is "chamber" and another whose
resource is "balcony")
(subscription="both"，她有两个可用资源，一个是"chamber"，另一个是"balcony")
o [email protected] (subscription="to")
o [email protected] (subscription="from")
Example 1: User sends initial presence:
例1：用户发送初始化"presence"
<presence/>
Example 2: User's server sends presence probes to contacts with
subscription="to" and subscription="both" on behalf of the user's
available resource:
例2：用户的服务器代表用户的可用资源发送"presence"探针("presence probe")给
subscription="to" 或 subscription="both"的联系人
<presence
type='probe'
from='[email protected]/orchard'
to='[email protected]'/>
<presence
type='probe'
from='[email protected]/orchard'
to='[email protected]'/>
Saint-Andre Standards Track [Page 22]
RFC 3921 XMPP IM October 2004
Example 3: User's server sends initial presence to contacts with
subscription="from" and subscription="both" on behalf of the user's
available resource:
例3：用户的服务器代表用户的可用资源发送初始化"presence"("initial presence")给
subscription="from" 或 subscription="both"的联系人
<presence
from='[email protected]/orchard'
to='[email protected]'/>
<presence
from='[email protected]/orchard'
to='[email protected]'/>
Example 4: Contacts' servers reply to presence probe on behalf of all
available resources:
例4：联系人的服务器代表所有的可用资源回复"presence"探针("presence probe")
<presence
from='[email protected]/balcony'
to='[email protected]/orchard'
xml:lang='en'>
<show>away</show>
<status>be right back</status>
<priority>0</priority>
</presence>
<presence
from='[email protected]/chamber'
to='[email protected]/orchard'>
<priority>1</priority>
</presence>
<presence
from='[email protected]/pda'
to='[email protected]/orchard'
xml:lang='en'>
<show>dnd</show>
<status>gallivanting</status>
</presence>
Example 5: Contacts' servers deliver user's initial presence to all
available resources or return error to user:
例4：联系人的服务器传递用户的初始化"presence"("initial presence")给所有的
可用资源，或返回错误给用户:
<presence
from='[email protected]/orchard'
to='[email protected]/chamber'/>
Saint-Andre Standards Track [Page 23]
RFC 3921 XMPP IM October 2004
<presence
from='[email protected]/orchard'
to='[email protected]/balcony'/>
<presence
type='error'
from='[email protected]'
to='[email protected]/orchard'>
<error type='cancel'>
<gone xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
</error>
</presence>
Example 6: User sends directed presence to another user not in his
roster:
例6：用户发送直接"presence"("directed presence")给另一个不在他的花名薄("roster")
中的用户:
<presence
from='[email protected]/orchard'
to='[email protected]'
xml:lang='en'>
<show>dnd</show>
<status>courting Juliet</status>
<priority>0</priority>
</presence>
Example 7: User sends updated available presence information for
broadcasting:
例7：用户广播发送更新可用"presence"信息:
<presence xml:lang='en'>
<show>away</show>
<status>I shall return!</status>
<priority>1</priority>
</presence>
Example 8: User's server broadcasts updated presence information only
to one contact (not those from whom an error was received or to whom
the user sent directed presence):
例8：用户的服务器仅广播发送更新可用"presence"信息给一个用户(不发给接收到错误的，也不
发给用户发送直接"presence"("directed presence")的):
<presence
from='[email protected]/orchard'
to='[email protected]'
xml:lang='en'>
<show>away</show>
<status>I shall return!</status>
<priority>1</priority>
</presence>
Saint-Andre Standards Track [Page 24]
RFC 3921 XMPP IM October 2004
Example 9: Contact's server delivers updated presence information to
all of the contact's available resources:
例9：联系人的服务器传递更新"presence"信息给联系人的所有可用资源:
[to "balcony" resource...]
<presence
from='[email protected]/orchard'
to='[email protected]'
xml:lang='en'>
<show>away</show>
<status>I shall return!</status>
<priority>1</priority>
</presence>
[to "chamber" resource...]
<presence
from='[email protected]/orchard'
to='[email protected]'
xml:lang='en'>
<show>away</show>
<status>I shall return!</status>
<priority>1</priority>
</presence>
Example 10: One of the contact's resources broadcasts final presence:
例10：联系人的资源中的一个广播最后"presence"("final presence")信息:
<presence from='[email protected]/balcony' type='unavailable'/>
Example 11: Contact's server sends unavailable presence information
to user:
例10：联系人的服务器发送不可用"presence"("unavailable presence")信息给用户:
<presence
type='unavailable'
from='[email protected]/balcony'
to='[email protected]/orchard'/>
Example 12: User sends final presence:
例10：用户发送最后"presence"("final presence"):
<presence from='[email protected]/orchard'
type='unavailable'
xml:lang='en'>
<status>gone home</status>
</presence>
Saint-Andre Standards Track [Page 25]
RFC 3921 XMPP IM October 2004
Example 13: User's server broadcasts unavailable presence information
to contact as well as to the person to whom the user sent directed
presence:
例10：用户的服务器广播不可用"presence"("unavailable presence")信息给联系人，也
包括用户发送直接"presence"("directed presence"):
<presence
type='unavailable'
from='[email protected]/orchard'
to='[email protected]'
xml:lang='en'>
<status>gone home</status>
</presence>
<presence
from='[email protected]/orchard'
to='[email protected]'
xml:lang='en'>
<status>gone home</status>
</presence>
6. Managing Subscriptions
In order to protect the privacy of instant messaging users and any
other entities, presence and availability information is disclosed
only to other entities that the user has approved. When a user has
agreed that another entity may view its presence, the entity is said
to have a subscription to the user's presence information. A
subscription lasts across sessions; indeed, it lasts until the
subscriber unsubscribes or the subscribee cancels the
previously-granted subscription. Subscriptions are managed within
XMPP by sending presence stanzas containing specially-defined
attributes.
为了保护即时消息用户或任何其它实体不受打扰，"presence"和可用信息仅展示给用户允许的
其它实体。当一个用户同意另一个实体可以查看它的"presence"，实体说有一个用户的
"presence"的订阅。一个订阅存在超过会话;当然，它的存在直到订阅者取消订阅或被订阅者取
消先前的订阅允可。
Note: There are important interactions between subscriptions and
rosters; these are defined under Integration of Roster Items and
Presence Subscriptions (Section 8), and the reader must refer to that
section for a complete understanding of presence subscriptions.
注意：在订阅和花名薄("roster")之间有重要的交互；见第8节。
6.1. Requesting a Subscription
A request to subscribe to another entity's presence is made by
sending a presence stanza of type "subscribe".
一个订阅另一个实体的"presence"的请求可以通过发送一个类型为"subscribe"的
"presence stanza"来实现。
Example: Sending a subscription request:
例：发送一个订阅请求
<presence to='[email protected]' type='subscribe'/>
Saint-Andre Standards Track [Page 26]
RFC 3921 XMPP IM October 2004
For client and server responsibilities regarding presence
subscription requests, refer to Presence Subscriptions (Section
5.1.6).
对客户端和服务器关于订阅请求的责任，参考第5.1.6节。
6.2. Handling a Subscription Request
When a client receives a subscription request from another entity, it
MUST either approve the request by sending a presence stanza of type
"subscribed" or refuse the request by sending a presence stanza of
type "unsubscribed".
当一个用户从另一个实体接收到一个订阅请求，它必须("MUST")发送一个类型为"subscribed"的
"presence stanza"来同意这个请求或发送一个类型为"unsubscribed"的"presence stanza"
来拒绝这个请求。
Example: Approving a subscription request:
例：同意一个订阅请求
<presence to='[email protected]' type='subscribed'/>
Example: Refusing a presence subscription request:
例：拒绝一个订阅请求
<presence to='[email protected]' type='unsubscribed'/>
6.3. Cancelling a Subscription from Another Entity
If a user would like to cancel a previously-granted subscription
request, it sends a presence stanza of type "unsubscribed".
如果一个用户想要取消一个先前允许的订阅请求，他发送一个类型值为"unsubscribed"的"presence"。
Example: Cancelling a previously granted subscription request:
例：取消一个先前允许的订阅请求。
<presence to='[email protected]' type='unsubscribed'/>
6.4. Unsubscribing from Another Entity's Presence
If a user would like to unsubscribe from the presence of another
entity, it sends a presence stanza of type "unsubscribe".
如果一个用户想要不再接收另一个实体的"presence"，他发送一个类型值为"unsubscribe"的"presence"。
Example: Unsubscribing from an entity's presence:
<presence to='[email protected]' type='unsubscribe'/>
7. Roster Management
In XMPP, one's contact list is called a roster, which consists of any
number of specific roster items, each roster item being identified by
a unique JID (usually of the form <contact@domain>). A user's roster
is stored by the user's server on the user's behalf so that the user
may access roster information from any resource.
Saint-Andre Standards Track [Page 27]
RFC 3921 XMPP IM October 2004
Note: There are important interactions between rosters and
subscriptions; these are defined under Integration of Roster Items
and Presence Subscriptions (Section 8), and the reader must refer to
that section for a complete understanding of roster management.
在XMPP,一个用户的联系人列表叫花名薄("roster")，它由任意数目的花名薄("roster")条目
组成，每一个花名薄("roster")条目都由一个唯一的JID(通常是<contact@domain>格式)标
识。一个用户的花名薄("roster")是由用户的服务器代表用户来保存的，这样用户可能从任何资
资处访问花名薄("roster")。
注意：
7.1. Syntax and Semantics
Rosters are managed using IQ stanzas, specifically by means of a
<query/> child element qualified by the 'jabber:iq:roster' namespace.
The <query/> element MAY contain one or more <item/> children, each
describing a unique roster item or "contact".
花名薄("roster")是用"IQ stanza"来管理的，它是'jabber:iq:roster'命名空间下的
<query/>的子节点。<query/>节点可能("MAY")包含一个或多个<item/>子节点，每一个
描述了一个唯一的花名薄("roster")条目或联系人"contact".
The "key" or unique identifier for each roster item is a JID,
encapsulated in the 'jid' attribute of the <item/> element (which is
REQUIRED). The value of the 'jid' attribute SHOULD be of the form
<user@domain> if the item is associated with another (human) instant
messaging user.
每一个花名薄("roster")条目的"key"或唯一标识符是一个JID，放置在<item/>节点的"jid"(这
是必需的("REQUIRED")属性中。如果这个项目关联着另一个即时消息用户，"jid"属性值应该("SHOULD")
是<user@domain>格式的。
The state of the presence subscription in relation to a roster item
is captured in the 'subscription' attribute of the <item/> element.
Allowable values for this attribute are:
关于一个花名薄("roster")条目的"presence"订阅状态是保存在<item/>节点的"subscription"属
性中。该属性允许的值如下:
o "none" -- the user does not have a subscription to the contact's
presence information, and the contact does not have a subscription
to the user's presence information
"none" -- 用户没有订阅联系人的"presence"信息，联系人也没有订阅用户的"presence"信息。
o "to" -- the user has a subscription to the contact's presence
information, but the contact does not have a subscription to the
user's presence information
"to" -- 用户订阅了联系人的"presence"信息，但联系人也没有订阅用户的"presence"信息。
o "from" -- the contact has a subscription to the user's presence
information, but the user does not have a subscription to the
contact's presence information
"from" -- 联系人订阅用户的"presence"信息,但用户没有订阅联系人的"presence"信息。
o "both" -- both the user and the contact have subscriptions to each
other's presence information
"both" -- 用户订阅了联系人的"presence"信息，联系人也订阅了用户的"presence"信息。
Each <item/> element MAY contain a 'name' attribute, which sets the
"nickname" to be associated with the JID, as determined by the user
(not the contact). The value of the 'name' attribute is opaque.
每一个<item/>节点可能("MAY")包含一个"name"属性，它设置了这个"JID"的呢称("nickname")，它是
用户决定的(不是联系人)，"name"属性是不透明的
Each <item/> element MAY contain one or more <group/> child elements,
for use in collecting roster items into various categories. The XML
character data of the <group/> element is opaque.
Saint-Andre Standards Track [Page 28]
RFC 3921 XMPP IM October 2004
7.2. Business Rules
A server MUST ignore any 'to' address on a roster "set", and MUST
treat any roster "set" as applying to the sender. For added safety,
a client SHOULD check the "from" address of a "roster push" (incoming
IQ of type "set" containing a roster item) to ensure that it is from
a trusted source; specifically, the stanza MUST either have no 'from'
attribute (i.e., implicitly from the server) or have a 'from'
attribute whose value matches the user's bare JID (of the form
<user@domain>) or full JID (of the form <user@domain/resource>);
otherwise, the client SHOULD ignore the "roster push".
一个服务器必须("MUST")在花名薄("roster")的"set"操作中忽略任何"to"地址，必须("MUST")
象应用于发送者那样信任花名薄("roster")的"set"操作。为了更安全，一个客户端应该("SHOULD")
检查一个"roster push"()的"from"地址来保证它来自一个可信任的源；特别的，"stanza"必须
("MUST")是没有"from"属性(也就是，)或有一个匹配用户"bare JID"(形如<user@domain>)或完
整JID(形如<user@domain/resource>)的"from"属性；否则一个客户端应该("SHOULD")忽略"roster push"。
7.3. Retrieving One's Roster on Login
Upon connecting to the server and becoming an active resource, a
client SHOULD request the roster before sending initial presence
(however, because receiving the roster may not be desirable for all
resources, e.g., a connection with limited bandwidth, the client's
request for the roster is OPTIONAL). If an available resource does
not request the roster during a session, the server MUST NOT send it
presence subscriptions and associated roster updates.
在连接到服务器成为一个活动的资源后，客户端应该("SHOULD")在发送初始化"presence"("initial
presence")(可是，)之前请求获得花名薄("roster")。如果一个可用的资源在一个会话期间不想获得
花名薄("roster")，服务器必须不("MUST NOT")能发送它的"presence"订阅并关联花名薄("roster")
的更新.
Example: Client requests current roster from server:
如：客户端向服务器请求当前的花名薄("roster")
<iq from='[email protected]/balcony' type='get' id='roster_1'>
<query xmlns='jabber:iq:roster'/>
</iq>
Example: Client receives roster from server:
例：客户端从服务器接收到花名薄("roster")
<iq to='[email protected]/balcony' type='result' id='roster_1'>
<query xmlns='jabber:iq:roster'>
<item jid='[email protected]'
name='Romeo'
subscription='both'>
<group>Friends</group>
</item>
<item jid='[email protected]'
name='Mercutio'
subscription='from'>
<group>Friends</group>
</item>
<item jid='[email protected]'
name='Benvolio'
subscription='both'>
<group>Friends</group>
</item>
</query>
Saint-Andre Standards Track [Page 29]
RFC 3921 XMPP IM October 2004
</iq>
7.4. Adding a Roster Item
At any time, a user MAY add an item to his or her roster.
在任何时候，一个用户可能("MAY")增加一个条目到他的花名薄("roster")
Example: Client adds a new item:
<iq from='[email protected]/balcony' type='set' id='roster_2'>
<query xmlns='jabber:iq:roster'>
<item jid='[email protected]'
name='Nurse'>
<group>Servants</group>
</item>
</query>
</iq>
The server MUST update the roster information in persistent storage,
and also push the change out to all of the user's available resources
that have requested the roster. This "roster push" consists of an IQ
stanza of type "set" from the server to the client and enables all
available resources to remain in sync with the server-based roster
information.
服务器必须("MUST")更新花名薄("roster")信息到存储介质上，同时也要发送("push")变动
到用户所有的获得过花名薄("roster")信息可用资源。这个"roster push"由一个从服务器到
客户端的类型为"set"的"IQ stanza"组成，使所有的可用资源与保留在服务器上的花名薄("roster")
信息保持一致。
Example: Server (1) pushes the updated roster information to all
available resources that have requested the roster and (2) replies
with an IQ result to the sending resource:
例：服务器(1)发送("push")变动到用户所有的获得过花名薄("roster")信息可用资源，(2)回复发送请
求资源IQ结果.
<iq to='[email protected]/balcony'
type='set'
id='a78b4q6ha463'>
<query xmlns='jabber:iq:roster'>
<item jid='[email protected]'
name='Nurse'
subscription='none'>
<group>Servants</group>
</item>
</query>
</iq>
<iq to='[email protected]/chamber'
type='set'
id='a78b4q6ha464'>
<query xmlns='jabber:iq:roster'>
<item jid='[email protected]'
name='Nurse'
subscription='none'>
<group>Servants</group>
Saint-Andre Standards Track [Page 30]
RFC 3921 XMPP IM October 2004
</item>
</query>
</iq>
<iq to='[email protected]/balcony' type='result' id='roster_2'/>
As required by the semantics of the IQ stanza kind as defined in
[XMPP-CORE], each resource that received the roster push MUST reply
with an IQ stanza of type "result" (or "error").
Example: Resources reply with an IQ result to the server:
<iq from='[email protected]/balcony'
to='example.com'
type='result'
id='a78b4q6ha463'/>
<iq from='[email protected]/chamber'
to='example.com'
type='result'
id='a78b4q6ha464'/>
7.5. Updating a Roster Item
Updating an existing roster item (e.g., changing the group) is done
in the same way as adding a new roster item, i.e., by sending the
roster item in an IQ set to the server.
象添加一个新的花名薄("roster")条目一样更新一个已存在的花名薄("roster")条目，也就是，发
送一个在类型为"set"的IQ中包含一个花名薄("roster")条目给服务器。
Example: User updates roster item (added group):
例子：用户更新一个花名薄("roster")条目
<iq from='[email protected]/chamber' type='set' id='roster_3'>
<query xmlns='jabber:iq:roster'>
<item jid='[email protected]'
name='Romeo'
subscription='both'>
<group>Friends</group>
<group>Lovers</group>
</item>
</query>
</iq>
As with adding a roster item, when updating a roster item the server
MUST update the roster information in persistent storage, and also
initiate a roster push to all of the user's available resources that
have requested the roster.
和添加一个花名薄("roster")条目一样，当更新一个花名薄("roster")条目时，服务器必须
("MUST")更新花名薄("roster")信息到存储介质上，同时也要发送("push")变动到用户所有
的获得过花名薄("roster")信息可用资源。
Saint-Andre Standards Track [Page 31]
RFC 3921 XMPP IM October 2004
7.6. Deleting a Roster Item
At any time, a user MAY delete an item from his or her roster by
sending an IQ set to the server and making sure that the value of the
'subscription' attribute is "remove" (a compliant server MUST ignore
any other values of the 'subscription' attribute when received from a
client).
在任何时间，用户可能("MUST")通过发送一个类型为"set"的IQ从它的花名薄("roster")中
删除一个条目，确保"subscription"属性是"remove"(一个好的服务器必须("MUST")在从一个
客户端收到时忽略"subscription"任何其它值)。
Example: Client removes an item:
例：客户端删除一个条目：
<iq from='[email protected]/balcony' type='set' id='roster_4'>
<query xmlns='jabber:iq:roster'>
<item jid='[email protected]' subscription='remove'/>
</query>
</iq>
As with adding a roster item, when deleting a roster item the server
MUST update the roster information in persistent storage, initiate a
roster push to all of the user's available resources that have
requested the roster (with the 'subscription' attribute set to a
value of "remove"), and send an IQ result to the initiating resource.
和添加一个花名薄("roster")条目一样，当删除一个花名薄("roster")条目时，服务器必须
("MUST")更新花名薄("roster")信息到存储介质上，同时也要发送("push")变动到用户所有
的获得过花名薄("roster")信息可用资源，并回复一个IQ结果给初始化资源。
For further information about the implications of this command, see
Removing a Roster Item and Cancelling All Subscriptions (Section
8.6).
8. Integration of Roster Items and Presence Subscriptions
8.1. Overview
Some level of integration between roster items and presence
subscriptions is normally expected by an instant messaging user
regarding the user's subscriptions to and from other contacts. This
section describes the level of integration that MUST be supported
within XMPP instant messaging applications.
There are four primary subscription states:
o None -- the user does not have a subscription to the contact's
presence information, and the contact does not have a subscription
to the user's presence information
None -- 用户没有订阅联系人的"presence"信息，联系人也没有订阅用户的"presence"信息。
Saint-Andre Standards Track [Page 32]
RFC 3921 XMPP IM October 2004
o To -- the user has a subscription to the contact's presence
information, but the contact does not have a subscription to the
user's presence information
To -- 用户订阅了联系人的"presence"信息，但联系人也没有订阅用户的"presence"信息。
o From -- the contact has a subscription to the user's presence
information, but the user does not have a subscription to the
contact's presence information
From -- 联系人订阅用户的"presence"信息,但用户没有订阅联系人的"presence"信息。
o Both -- both the user and the contact have subscriptions to each
other's presence information (i.e., the union of 'from' and 'to')
Both -- 用户订阅了联系人的"presence"信息，联系人也订阅了用户的"presence"信息。
Each of these states is reflected in the roster of both the user and
the contact, thus resulting in durable subscription states.
这些状态反映在用户和联系人的花名薄("roster")中，导致订阅状态持续。
Narrative explanations of how these subscription states interact with
roster items in order to complete certain defined use cases are
provided in the following sub-sections. Full details regarding
server and client handling of all subscription states (including
pending states between the primary states listed above) is provided
in Subscription States (Section 9).
The server MUST NOT send presence subscription requests or roster
pushes to unavailable resources, nor to available resources that have
not requested the roster.
服务器必须不能("MUST NOT")发送"presence"订阅请求或" roster push"一个不可用资源，也
不能发给没有请求花名薄("roster")的可用的资源.
The 'from' and 'to' addresses are OPTIONAL in roster pushes; if
included, their values SHOULD be the full JID of the resource for
that session. A client MUST acknowledge each roster push with an IQ
stanza of type "result" (for the sake of brevity, these stanzas are
not shown in the following examples but are required by the IQ
semantics defined in [XMPP-CORE]).
在"roster push"中"from"和"to"地址是可选的("OPTIONAL")；如果有，它们的值应该("SHOULD")
是这个会话资源的完整JID。一个客户端必须("MUST")知道每个"roster push"有一个类型为"result"
的"IQ stanza"( )
8.2. User Subscribes to Contact
The process by which a user subscribes to a contact, including the
interaction between roster items and subscription states, is
described below.
一个用户订阅一个联系人的处理，包括花名薄("roster")条目与订阅状态的交互，在下面描述
1. In preparation for being able to render the contact in the user's
client interface and for the server to keep track of the
subscription, the user's client SHOULD perform a "roster set" for
the new roster item. This request consists of sending an IQ
stanza of type='set' containing a <query/> element qualified by
the 'jabber:iq:roster' namespace, which in turn contains an
<item/> element that defines the new roster item; the <item/>
element MUST possess a 'jid' attribute, MAY possess a 'name'
attribute, MUST NOT possess a 'subscription' attribute, and MAY
contain one or more <group/> child elements:
在准备将联系人呈现在用户的界面和服务器明了这个订阅过程中，用户的客户端应该("SHOULD")为
新的花名薄("roster")条目执行一个"roster set"操作。这个请求由发送一个类型为"set"含有
一个在'jabber:iq:roster'命名空间下的<query/>子节点的IQ stanza"组成，它依次包含了定
义了一个新花名薄("roster")条目的<item/>节点；<item/>节点必须("MUST")有一个"jid"属
性，可能("MAY")包含一个或多相<group/>子节点:
Saint-Andre Standards Track [Page 33]
RFC 3921 XMPP IM October 2004
<iq type='set' id='set1'>
<query xmlns='jabber:iq:roster'>
<item
jid='[email protected]'
name='MyContact'>
<group>MyBuddies</group>
</item>
</query>
</iq>
2. As a result, the user's server (1) MUST initiate a roster push
for the new roster item to all available resources associated
with this user that have requested the roster, setting the
'subscription' attribute to a value of "none"; and (2) MUST reply
to the sending resource with an IQ result indicating the success
of the roster set:
结果，用户的服务器(1)必须("MUST")为新的花名薄("roster")条目初始化一个"roster push"给
这个用户的所有获得过这个花名薄("roster")的可用资源，将"subscription"属性设置成"none"
; (2)必须("MUST")回复一个指示花名薄"set"("roster set")成功的IQ结果给这个资源.
<iq type='set'>
<query xmlns='jabber:iq:roster'>
<item
jid='[email protected]'
subscription='none'
name='MyContact'>
<group>MyBuddies</group>
</item>
</query>
</iq>
<iq type='result' id='set1'/>
3. If the user wants to request a subscription to the contact's
presence information, the user's client MUST send a presence
stanza of type='subscribe' to the contact:
如果用户想要请求一个联系人的"presence"订阅，用户的客户端必须("MUST")发送一个类型为"subscribe"
的"presence stanza"给联系人:
<presence to='[email protected]' type='subscribe'/>
4. As a result, the user's server MUST initiate a second roster push
to all of the user's available resources that have requested the
roster, setting the contact to the pending sub-state of the
'none' subscription state; this pending sub-state is denoted by
the inclusion of the ask='subscribe' attribute in the roster
item:
结果，用户的服务器必须("MUST")开始第二个"roster push"给用户所有的那些请求过花名
薄("roster")的可用资源，设置联系人是未决的"none"状态；这个未决的状态注明了在花名
薄("roster")条目中有一个"ask='subscribe'"属性
Saint-Andre Standards Track [Page 34]
RFC 3921 XMPP IM October 2004
<iq type='set'>
<query xmlns='jabber:iq:roster'>
<item
jid='[email protected]'
subscription='none'
ask='subscribe'
name='MyContact'>
<group>MyBuddies</group>
</item>
</query>
</iq>
Note: If the user did not create a roster item before sending the
subscription request, the server MUST now create one on behalf of the
user, then send a roster push to all of the user's available
resources that have requested the roster, absent the 'name' attribute
and the <group/> child shown above.
注意：如果在没有发送一个订阅请求之前用户没有创建一个花名薄("roster")条目，服务器必须
("MUST")现要代表用户创建一个，然后，发送一个"roster push"给用户所有的那些请求过花名
薄("roster")的可用资源，如上面描述的一样没有"name"属性和<group/>子节点
5. The user's server MUST also stamp the presence stanza of type
"subscribe" with the user's bare JID (i.e., <[email protected]>)
as the 'from' address (if the user provided a 'from' address set
to the user's full JID, the server SHOULD remove the resource
identifier). If the contact is served by a different host than
the user, the user's server MUST route the presence stanza to the
contact's server for delivery to the contact (this case is
assumed throughout; however, if the contact is served by the same
host, then the server can simply deliver the presence stanza
directly):
用户的服务器必须("MUST")象"from"地址(如果用户提供了一个"from"地址来设置用户的完整JID,
服务器应该("SHOULD")删除的标源标识)一样用户的赤裸的JID标记(<[email protected]>)类型为
"subscribe"的"presence stanza"。如果联系人是与用户不同的主机上的，用户的服务器必须("MUST")
路由"presence stanza"到联系人的服务器上传递给联系人(这件事情是自始自尽都是，然而，如果
联系人在同一主机上，那么服务器能简单的直接地传递它)。
<presence
from='[email protected]'
to='[email protected]'
type='subscribe'/>
Note: If the user's server receives a presence stanza of type "error"
from the contact's server, it MUST deliver the error stanza to the
user, whose client MAY determine that the error is in response to the
outgoing presence stanza of type "subscribe" it sent previously
(e.g., by tracking an 'id' attribute) and then choose to resend the
"subscribe" request or revert the roster to its previous state by
sending a presence stanza of type "unsubscribe" to the contact.
注意：如果用户的服务器从联系人的服务器上接收到一个类型为"error"的"presence stanza"，它
必须("MUST")传递这个错误的"stanza"到用户，用户端可能("MAY")会认为这个"error"是它先前
发送的"subscribe"类型的"presence stanza"的响应，然后选择重发一个"subscribe"请求，或
通过发送一个"unsubscribe"类型的"presence stanza"给联系人来恢复花名薄("roster")到先前
的状态。
6. Upon receiving the presence stanza of type "subscribe" addressed
to the contact, the contact's server MUST determine if there is
at least one available resource from which the contact has
requested the roster. If so, it MUST deliver the subscription
request to the contact (if not, the contact's server MUST store
the subscription request offline for delivery when this condition
Saint-Andre Standards Track [Page 35]
RFC 3921 XMPP IM October 2004
is next met; normally this is done by adding a roster item for
the contact to the user's roster, with a state of "None + Pending
In" as defined under Subscription States (Section 9), however a
server SHOULD NOT push or deliver roster items in that state to
the contact). No matter when the subscription request is
delivered, the contact must decide whether or not to approve it
(subject to the contact's configured preferences, the contact's
client MAY approve or refuse the subscription request without
presenting it to the contact). Here we assume the "happy path"
that the contact approves the subscription request (the alternate
flow of declining the subscription request is defined in Section
8.2.1). In this case, the contact's client (1) SHOULD perform a
roster set specifying the desired nickname and group for the user
(if any); and (2) MUST send a presence stanza of type
"subscribed" to the user in order to approve the subscription
request.
在接收到给联系人的"subscribe"类型的"presence stanza"后，服务器必须("MUST")判断联系人请
过联系人的花名薄("roster")的资源至少有一个。如果这样，它必须("MUST")传递它给联系人(如果不
是，联系人的服务器必须离线保存订阅，以便联系人下一次登录时，传递给它;通常它在用户的花名薄("roster")
中添加一个花名薄("roster")条目，用一个在第9节"None + Pending In"状态，可是服务器不应该("SHOULD
NOT"))。当一个订阅请求到达，联系人必须决定答不答应它(根据联系人的配置，服系人的客户端可能("MAY")
答应或拒绝它。)。这而我们假设是"happy path"，就是联系人答应订阅请求。在这件事上，联系人的客户端(1)
应该执行一个"roster set"为用户指定一个昵称和分组；(2)必须发送一个"subscribed"类型的"presence
stanza"给用户来答应订阅请求。
<iq type='set' id='set2'>
<query xmlns='jabber:iq:roster'>
<item
jid='[email protected]'
name='SomeUser'>
<group>SomeGroup</group>
</item>
</query>
</iq>
<presence to='[email protected]' type='subscribed'/>
7. As a result, the contact's server (1) MUST initiate a roster push
to all available resources associated with the contact that have
requested the roster, containing a roster item for the user with
the subscription state set to 'from' (the server MUST send this
even if the contact did not perform a roster set); (2) MUST
return an IQ result to the sending resource indicating the
success of the roster set; (3) MUST route the presence stanza of
type "subscribed" to the user, first stamping the 'from' address
as the bare JID (<[email protected]>) of the contact; and (4)
MUST send available presence from all of the contact's available
resources to the user:
结果，联系人的服务器(1)必须("MUST")初始化一个"roster push"给所有联系人的那些请求过花名
薄("roster")的可用资源，其中包含一个关于用户的状态为"from"的花名薄("roster")条目(服务器必须
("MUST")发送这个事情，如果联系人没有执行一个"roster set"的话);(2)必须("MUST")返回一个IQ
结果给发送资源指明"roster set"成功；(3)必须路由"subscribed"类型的"presence stanza"给用
户，首先要标记"from"地址为联系人赤裸JID(<[email protected]>)；(4)必须("MUST")从联系人
的所有可用资源发送可用"presence"给用户：
Saint-Andre Standards Track [Page 36]
RFC 3921 XMPP IM October 2004
<iq type='set' to='[email protected]/resource'>
<query xmlns='jabber:iq:roster'>
<item
jid='[email protected]'
subscription='from'
name='SomeUser'>
<group>SomeGroup</group>
</item>
</query>
</iq>
<iq type='result' to='[email protected]/resource' id='set2'/>
<presence
from='[email protected]'
to='[email protected]'
type='subscribed'/>
<presence
from='[email protected]/resource'
to='[email protected]'/>
Note: If the contact's server receives a presence stanza of type
"error" from the user's server, it MUST deliver the error stanza to
the contact, whose client MAY determine that the error is in response
to the outgoing presence stanza of type "subscribed" it sent
previously (e.g., by tracking an 'id' attribute) and then choose to
resend the "subscribed" notification or revert the roster to its
previous state by sending a presence stanza of type "unsubscribed" to
the user.
注意：如果联系人的服务器从用户的服务器接收到一个类型为"error"的"presence stanza"，它
必须("MUST")传递"error" stanza给联系人，客户端可能("MAY")判断错误是不是它先前发送的
"subscribed"类型的"presence stanza"的回复，然后选择重发或通过发送一个"unsubscribe"
类型的"presence stanza"给联系人来恢复花名薄("roster")到先前的状态。
8. Upon receiving the presence stanza of type "subscribed" addressed
to the user, the user's server MUST first verify that the contact
is in the user's roster with either of the following states: (a)
subscription='none' and ask='subscribe' or (b)
subscription='from' and ask='subscribe'. If the contact is not
in the user's roster with either of those states, the user's
server MUST silently ignore the presence stanza of type
"subscribed" (i.e., it MUST NOT route it to the user, modify the
user's roster, or generate a roster push to the user's available
resources). If the contact is in the user's roster with either
of those states, the user's server (1) MUST deliver the presence
stanza of type "subscribed" from the contact to the user; (2)
MUST initiate a roster push to all of the user's available
resources that have requested the roster, containing an updated
roster item for the contact with the 'subscription' attribute set
Saint-Andre Standards Track [Page 37]
RFC 3921 XMPP IM October 2004
to a value of "to"; and (3) MUST deliver the available presence
stanza received from each of the contact's available resources to
each of the user's available resources:
在接收到一个给用户的"subscribed"类型的"presence stanza"后，用户的服务器必须("MUST")
首先验证联系人在用户的花名薄("roster")中是不是下列状态:(a)subscription='none' 并
ask='subscribe' ,(b)subscription='from' 并 ask='subscribe'。如果联系人在用户的花名
薄("roster")中不是这些状态，用户的服务器必须("MUST")悄悄地忽略它()。如果联系人在用户的花
名薄("roster")中是这些状态，用户的服务器(1)必须("MUST")从联系人那里传递"subscribed"类型
的"presence stanza"给用户；(2)必须("MUST")初始化一个"roster push"给所有用户的那些请求
过花名薄("roster")的可用资源，其中包含一个用于更新的"subscription"属性值为"to"的关于联系
人的花名薄("roster")条目；(3)必须("MUST")传递每一个从联系人的可用资源接收到的可用"presence stanza"
给用户的每一个可用资源:
<presence
to='[email protected]'
from='[email protected]'
type='subscribed'/>
<iq type='set'>
<query xmlns='jabber:iq:roster'>
<item
jid='[email protected]'
subscription='to'
name='MyContact'>
<group>MyBuddies</group>
</item>
</query>
</iq>
<presence
from='[email protected]/resource'
to='[email protected]/resource'/>
9. Upon receiving the presence stanza of type "subscribed", the user
SHOULD acknowledge receipt of that subscription state
notification through either "affirming" it by sending a presence
stanza of type "subscribe" to the contact or "denying" it by
sending a presence stanza of type "unsubscribe" to the contact;
this step does not necessarily affect the subscription state (see
Subscription States (Section 9) for details), but instead lets
the user's server know that it MUST no longer send notification
of the subscription state change to the user (see Section 9.4).
在接收到"subscribed"类型的"presence stanza"，用户应该("SHOULD")知道订阅状态通知
的回复，发送过一个"subscribe"类型的"presence stanza"就是"affirming"它，发送过一
个"unsubscribe"类型的"presence stanza"就是"denying"它；这一步不是必不可不少的，
但是可代替让用户的服务器知道它必须("MUST")不再发送订阅状态的变更给用户.
From the perspective of the user, there now exists a subscription to
the contact's presence information; from the perspective of the
contact, there now exists a subscription from the user.
8.2.1. Alternate Flow: Contact Declines Subscription Request
The above activity flow represents the "happy path" regarding the
user's subscription request to the contact. The main alternate flow
occurs if the contact refuses the user's subscription request, as
described below.
上面的活动流程描述了关于用户订阅联系人的"happy path"。如果联系人拒绝用户的订阅请求时主要交互流
程如下：
Saint-Andre Standards Track [Page 38]
RFC 3921 XMPP IM October 2004
1. If the contact wants to refuse the request, the contact's client
MUST send a presence stanza of type "unsubscribed" to the user
(instead of the presence stanza of type "subscribed" sent in Step
6 of Section 8.2):
如果联系人想拒绝请求，联系人的客户端必须("MUST")发送一个类型为"unsubscribed"给用户()：
<presence to='[email protected]' type='unsubscribed'/>
2. As a result, the contact's server MUST route the presence stanza
of type "unsubscribed" to the user, first stamping the 'from'
address as the bare JID (<[email protected]>) of the contact:
结果，联系人的服务器必须("MUST")路由"unsubscribed"类型的"presence stanza"给用户，当然首先
要将它用联系人的赤裸的JID(<[email protected]>)标记"from"地址。
<presence
from='[email protected]'
to='[email protected]'
type='unsubscribed'/>
Note: If the contact's server previously added the user to the
contact's roster for tracking purposes, it MUST remove the relevant
item at this time.
注意: 如果联系人的服务器先前为了跟踪添加用户到联系人的花名簿("roster")，它必须在这一次
删除相关项目。
3. Upon receiving the presence stanza of type "unsubscribed"
addressed to the user, the user's server (1) MUST deliver that
presence stanza to the user and (2) MUST initiate a roster push
to all of the user's available resources that have requested the
roster, containing an updated roster item for the contact with
the 'subscription' attribute set to a value of "none" and with no
'ask' attribute:
在接收到给用户的"unsubscribed"类型的"presence stanza"后，用户的服务器(1)必须传递这个
"presence stanza"给用户，(2)必须初始化一个"roster push"到所有用户的那些请求过花名薄
("roster")的可用资源，其中包含一个关于联系人的"subscription"属性值为"none"和没有"ask"属性
的用来更新的条目：
<presence
from='[email protected]'
to='[email protected]'
type='unsubscribed'/>
<iq type='set'>
<query xmlns='jabber:iq:roster'>
<item
jid='[email protected]'
subscription='none'
name='MyContact'>
<group>MyBuddies</group>
</item>
</query>
</iq>
4. Upon receiving the presence stanza of type "unsubscribed", the
user SHOULD acknowledge receipt of that subscription state
notification through either "affirming" it by sending a presence
stanza of type "unsubscribe" to the contact or "denying" it by
Saint-Andre Standards Track [Page 39]
RFC 3921 XMPP IM October 2004
sending a presence stanza of type "subscribe" to the contact;
this step does not necessarily affect the subscription state (see
Subscription States (Section 9) for details), but instead lets
the user's server know that it MUST no longer send notification
of the subscription state change to the user (see Section 9.4).
在接收到一个"unsubscribed"类型的"presence stanza"后，用户应该知道
As a result of this activity, the contact is now in the user's roster
with a subscription state of "none", whereas the user is not in the
contact's roster at all.
作为活动的结果，联系人现在在用户的花名薄("roster")中"subscription"状态为"none"，然而
用户不在联系人的花名薄("roster")中。
8.3. Creating a Mutual Subscription
The user and contact can build on the "happy path" described above to
create a mutual subscription (i.e., a subscription of type "both").
The process is described below.
用户和联系人能够在"happy path"上象上面那样建立一个相互的订阅(也就是，订阅类型为"both")，
过程如下:
1. If the contact wants to create a mutual subscription, the contact
MUST send a subscription request to the user (subject to the
contact's configured preferences, the contact's client MAY send
this automatically):
如果联系人想要创建一个相互的订阅，联系必须("MUST")发送一个订阅请求给用户(根据联系人的配置
，联系人可能("MAY")自动地发送它).
<presence to='[email protected]' type='subscribe'/>
2. As a result, the contact's server (1) MUST initiate a roster push
to all available resources associated with the contact that have
requested the roster, with the user still in the 'from'
subscription state but with a pending 'to' subscription denoted
by the inclusion of the ask='subscribe' attribute in the roster
item; and (2) MUST route the presence stanza of type "subscribe"
to the user, first stamping the 'from' address as the bare JID
(<[email protected]>) of the contact:
结果，联系人的服务器（1）必须初始化一个"roster push"给所有用户的那些请求
过花名薄("roster")的可用资源，用户的"subscription"状态依然是"from"，但有在花名薄
("roster")中包含一个"ask='subscribe'"属性来指明一个未决的"to"订阅；(2)必须("MUST")
路由"subscribe"类型的"presence stanza"给用户，当然首先要将它联系人的赤裸的JID
(<[email protected]>)标记在"from"中：
<iq type='set'>
<query xmlns='jabber:iq:roster'>
<item
jid='[email protected]'
subscription='from'
ask='subscribe'
name='SomeUser'>
<group>SomeGroup</group>
</item>
</query>
</iq>
Saint-Andre Standards Track [Page 40]
RFC 3921 XMPP IM October 2004
<presence
from='[email protected]'
to='[email protected]'
type='subscribe'/>
Note: If the contact's server receives a presence stanza of type
"error" from the user's server, it MUST deliver the error stanza to
the contact, whose client MAY determine that the error is in response
to the outgoing presence stanza of type "subscribe" it sent
previously (e.g., by tracking an 'id' attribute) and then choose to
resend the "subscribe" request or revert the roster to its previous
state by sending a presence stanza of type "unsubscribe" to the user.
注意：如果联系人的服务器从用户的服务器接收到一个"error"类型的"presence stanza",它必
须("MUST")传递这个错误的"stanza"给联系人,客户端可能("MAY")判断它是否是先前发送的类型
为"subscribe"的"presence stanza"的回复，然后选择重发或通过发送一个"unsubscribe"
类型的"presence stanza"给用户来恢复花名薄("roster")到先前的状态。
3. Upon receiving the presence stanza of type "subscribe" addressed
to the user, the user's server must determine if there is at
least one available resource for which the user has requested the
roster. If so, the user's server MUST deliver the subscription
request to the user (if not, it MUST store the subscription
request offline for delivery when this condition is next met). No
matter when the subscription request is delivered, the user must
then decide whether or not to approve it (subject to the user's
configured preferences, the user's client MAY approve or refuse
the subscription request without presenting it to the user).
Here we assume the "happy path" that the user approves the
subscription request (the alternate flow of declining the
subscription request is defined in Section 8.3.1). In this case,
the user's client MUST send a presence stanza of type
"subscribed" to the contact in order to approve the subscription
request.
在接收到给用户的"subscribe"类型的"presence stanza"，用户的服务器必须("MUST")判断用户请
过用户的花名薄("roster")的资源至少有一个。如果这样，它必须("MUST")传递它给用户(如果不是，
联系人的服务器必须离线保存订阅，以便用户下一次登录时，传递给它)。当一个订阅请求到达，用户必须
决定答不答应它(根据用户的配置，用户的客户端可能("MAY")答应或拒绝它。)。这里我们假设是
"happy path"，就是用户答应订阅请求()。在这件事上，用户的客户端必须发送一个"subscribed"类
型的"presence stanza"给用户来答应订阅请求。
<presence to='[email protected]' type='subscribed'/>
4. As a result, the user's server (1) MUST initiate a roster push to
all of the user's available resources that have requested the
roster, containing a roster item for the contact with the
'subscription' attribute set to a value of "both"; (2) MUST route
the presence stanza of type "subscribed" to the contact, first
stamping the 'from' address as the bare JID (<[email protected]>)
of the user; and (3) MUST send to the contact the full XML of the
last presence stanza with no 'to' attribute received by the
server from each of the user's available resources (subject to
privacy lists in force for each session):
结果，用户的服务器(1)必须("MUST")初始化一个"roster push"给所有用户的那些请求过花名薄
("roster")的可用资源，其中包含一个关于联系人的状态为"both"的花名薄;(2)必须路由一个
"subscribed"类型的"presence stanza"给联系人，当然首先要标记"from"地址为用户赤裸JID
(<[email protected]>)；(3)必须("MUST")从用户的每个可用资源发送最后一次的"presence"
给用户()：
Saint-Andre Standards Track [Page 41]
RFC 3921 XMPP IM October 2004
<iq type='set'>
<query xmlns='jabber:iq:roster'>
<item
jid='[email protected]'
subscription='both'
name='MyContact'>
<group>MyBuddies</group>
</item>
</query>
</iq>
<presence
from='[email protected]'
to='[email protected]'
type='subscribed'/>
<presence
from='[email protected]/resource'
to='[email protected]'/>
Note: If the user's server receives a presence stanza of type "error"
from the contact's server, it MUST deliver the error stanza to the
user, whose client MAY determine that the error is in response to the
outgoing presence stanza of type "subscribed" it sent previously
(e.g., by tracking an 'id' attribute) and then choose to resend the
subscription request or revert the roster to its previous state by
sending a presence stanza of type "unsubscribed" to the contact.
注意：如果用户的服务器从联系人的服务器接收到一个类型为"error"的"presence stanza"，它
必须("MUST")传递"error" stanza给联系人，客户端可能("MAY")判断错误是不是它先前发送的
"subscribed"类型的"presence stanza"的回复(也就是，根据"id"属性)，然后选择重发或通过
发送一个"unsubscribe"类型的"presence stanza"给联系人来恢复花名薄("roster")到先前的
状态。
5. Upon receiving the presence stanza of type "subscribed" addressed
to the contact, the contact's server MUST first verify that the
user is in the contact's roster with either of the following
states: (a) subscription='none' and ask='subscribe' or (b)
subscription='from' and ask='subscribe'. If the user is not in
the contact's roster with either of those states, the contact's
server MUST silently ignore the presence stanza of type
"subscribed" (i.e., it MUST NOT route it to the contact, modify
the contact's roster, or generate a roster push to the contact's
available resources). If the user is in the contact's roster
with either of those states, the contact's server (1) MUST
deliver the presence stanza of type "subscribed" from the user to
the contact; (2) MUST initiate a roster push to all available
resources associated with the contact that have requested the
roster, containing an updated roster item for the user with the
'subscription' attribute set to a value of "both"; and (3) MUST
deliver the available presence stanza received from each of the
user's available resources to each of the contact's available
resources:
在接收到一个给联系人的"subscribed"类型的"presence stanza"后，联系人的服务器必须("MUST")
首先验证用户在联系人的花名薄("roster")中是不是下列状态:(a)subscription='none' 并
ask='subscribe' ,(b)subscription='from' 并 ask='subscribe'。如果用户在联系人的花名
薄("roster")中不是这些状态，联系人的服务器必须("MUST")悄悄地忽略它()。如果用户在联系人的花
名薄("roster")中是这些状态，联系人的服务器(1)必须("MUST")从用户那里传递"subscribed"类型
的"presence stanza"给联系人；(2)必须("MUST")初始化一个"roster push"给所有联系人的那些
请求过花名薄("roster")的可用资源，其中包含一个用于更新的"subscription"属性值为"to"的关于
用户的花名薄("roster")条目；(3)必须("MUST")传递每一个从用户的可用资源接收到的可用"presence stanza"
给联系人的每一个可用资源:
Saint-Andre Standards Track [Page 42]
RFC 3921 XMPP IM October 2004
<presence
from='[email protected]'
to='[email protected]'
type='subscribed'/>
<iq type='set'>
<query xmlns='jabber:iq:roster'>
<item
jid='[email protected]'
subscription='both'
name='SomeUser'>
<group>SomeGroup</group>
</item>
</query>
</iq>
<presence
from='[email protected]/resource'
to='[email protected]/resource'/>
6. Upon receiving the presence stanza of type "subscribed", the
contact SHOULD acknowledge receipt of that subscription state
notification through either "affirming" it by sending a presence
stanza of type "subscribe" to the user or "denying" it by sending
a presence stanza of type "unsubscribe" to the user; this step
does not necessarily affect the subscription state (see
Subscription States (Section 9) for details), but instead lets
the contact's server know that it MUST no longer send
notification of the subscription state change to the contact (see
Section 9.4).
在接收到"subscribed"类型的"presence stanza"，联系人应该("SHOULD")知道
The user and the contact now have a mutual subscription to each
other's presence -- i.e., the subscription is of type "both".
用户和联系人现有一个相互订阅，"subscription"状态为"both"
8.3.1. Alternate Flow: User Declines Subscription Request
The above activity flow represents the "happy path" regarding the
contact's subscription request to the user. The main alternate flow
occurs if the user refuses the contact's subscription request, as
described below.
上面的活动流程描述了关于联系人订阅用户的"happy path"。如果用户拒绝联系人的订阅请求时主要交互流
程如下：
1. If the user wants to refuse the request, the user's client MUST
send a presence stanza of type "unsubscribed" to the contact
(instead of the presence stanza of type "subscribed" sent in Step
3 of Section 8.3):
如果用户想拒绝请求，用户的客户端必须("MUST")发送一个类型为"unsubscribed"给联系人()：
<presence to='[email protected]' type='unsubscribed'/>
Saint-Andre Standards Track [Page 43]
RFC 3921 XMPP IM October 2004
2. As a result, the user's server MUST route the presence stanza of
type "unsubscribed" to the contact, first stamping the 'from'
address as the bare JID (<[email protected]>) of the user:
结果，用户的服务器必须("MUST")路由"unsubscribed"类型的"presence stanza"给联系人，当然首先
要将它用用户的赤裸的JID(<[email protected]>)标记"from"地址。
<presence
from='[email protected]'
to='[email protected]'
type='unsubscribed'/>
3. Upon receiving the presence stanza of type "unsubscribed"
addressed to the contact, the contact's server (1) MUST deliver
that presence stanza to the contact; and (2) MUST initiate a
roster push to all available resources associated with the
contact that have requested the roster, containing an updated
roster item for the user with the 'subscription' attribute set to
a value of "from" and with no 'ask' attribute:
在接收到给联系人的"unsubscribed"类型的"presence stanza"后，联系人的服务器(1)必须传递这个
"presence stanza"给联系人，(2)必须初始化一个"roster push"到所有联系人的那些请求过花名薄
("roster")的可用资源，其中包含一个关于用户的"subscription"属性值为"none"和没有"ask"属性
的用来更新的条目：
<presence
from='[email protected]'
to='[email protected]'
type='unsubscribed'/>
<iq type='set'>
<query xmlns='jabber:iq:roster'>
<item
jid='[email protected]'
subscription='from'
name='SomeUser'>
<group>SomeGroup</group>
</item>
</query>
</iq>
4. Upon receiving the presence stanza of type "unsubscribed", the
contact SHOULD acknowledge receipt of that subscription state
notification through either "affirming" it by sending a presence
stanza of type "unsubscribe" to the user or "denying" it by
sending a presence stanza of type "subscribe" to the user; this
step does not necessarily affect the subscription state (see
Subscription States (Section 9) for details), but instead lets
the contact's server know that it MUST no longer send
notification of the subscription state change to the contact (see
Section 9.4).
在接收到一个"unsubscribed"类型的"presence stanza"后，用户应该知道
As a result of this activity, there has been no change in the
subscription state; i.e., the contact is in the user's roster with a
subscription state of "to" and the user is in the contact's roster
with a subscription state of "from".
作为活动的结果，有下面变化：也就是，联系人现在在用户的花名薄("roster")中"subscription"状态为"to"，
用户不在联系人的花名薄("roster")中"subscription"状态为"from"。
Saint-Andre Standards Track [Page 44]
RFC 3921 XMPP IM October 2004
8.4. Unsubscribing
At any time after subscribing to a contact's presence information, a
user MAY unsubscribe. While the XML that the user sends to make
this happen is the same in all instances, the subsequent subscription
state is different depending on the subscription state obtaining when
the unsubscribe "command" is sent. Both possible scenarios are
described below.
在订阅了一个联系人的"presence"信息之后在任何时候，用户可能("MAY")取消订阅，在所有实例中当用户发
送这些XML都是相同的，在发送取消订阅"Command"时后续的订阅状态依赖于订阅状态而不同。可能的设想描述在
下面.
8.4.1. Case #1: Unsubscribing When Subscription is Not Mutual
In the first case, the user has a subscription to the contact's
presence information but the contact does not have a subscription to
the user's presence information (i.e., the subscription is not yet
mutual).
在第一个例子中，用户有一个联系人的订阅，但联系人没有订阅用户的"presence"信息(也就是，不是相互订阅).
1. If the user wants to unsubscribe from the contact's presence
information, the user MUST send a presence stanza of type
"unsubscribe" to the contact:
如果用户想要取消订阅，用户必须("MUST")发送一个"unsubscribe"类型的"presence stanza"给联系人。
<presence to='[email protected]' type='unsubscribe'/>
2. As a result, the user's server (1) MUST send a roster push to all
of the user's available resources that have requested the roster,
containing an updated roster item for the contact with the
'subscription' attribute set to a value of "none"; and (2) MUST
route the presence stanza of type "unsubscribe" to the contact,
first stamping the 'from' address as the bare JID
(<[email protected]>) of the user:
结果,用户的服务器(1)必须("MUST")发送一个"roster push"给所有用户的那些请求过花名薄("roster")的
可用资源,其中包含一个用于更新的"subscription"属性值为"none"的关于联系人的花名薄("roster")条目；
(2)必须("MUST")路由类型为"unsubscribe"的"presence stanza"给联系人，当然要将"from"地址标记为
用户的赤裸的JID(<[email protected]>):
<iq type='set'>
<query xmlns='jabber:iq:roster'>
<item
jid='[email protected]'
subscription='none'
name='MyContact'>
<group>MyBuddies</group>
</item>
</query>
</iq>
<presence
from='[email protected]'
to='[email protected]'
type='unsubscribe'/>
Saint-Andre Standards Track [Page 45]
RFC 3921 XMPP IM October 2004
3. Upon receiving the presence stanza of type "unsubscribe"
addressed to the contact, the contact's server (1) MUST initiate
a roster push to all available resources associated with the
contact that have requested the roster, containing an updated
roster item for the user with the 'subscription' attribute set to
a value of "none" (if the contact is unavailable or has not
requested the roster, the contact's server MUST modify the roster
item and send that modified item the next time the contact
requests the roster); and (2) MUST deliver the "unsubscribe"
state change notification to the contact:
在接收到给联系人的"unsubscribe"类型的"presence stanza"后，联系人的服务器(1)必须("MUST")
初始化一个"roster push"给所有联系人的那些请求过花名薄("roster")的可用资源，其中包含一个用于
更新的"subscription"属性值为"none"的关于用户的花名薄("roster")条目()；(2)必须("MUST")传
递"unsubscribe"状态变更通知给联系人：
<iq type='set'>
<query xmlns='jabber:iq:roster'>
<item
jid='[email protected]'
subscription='none'
name='SomeUser'>
<group>SomeGroup</group>
</item>
</query>
</iq>
<presence
from='[email protected]'
to='[email protected]'
type='unsubscribe'/>
4. Upon receiving the presence stanza of type "unsubscribe", the
contact SHOULD acknowledge receipt of that subscription state
notification through either "affirming" it by sending a presence
stanza of type "unsubscribed" to the user or "denying" it by
sending a presence stanza of type "subscribed" to the user; this
step does not necessarily affect the subscription state (see
Subscription States (Section 9) for details), but instead lets
the contact's server know that it MUST no longer send
notification of the subscription state change to the contact (see
Section 9.4).
在接收到"unsubscribe"类型的"presence stanza"，联系应该("SHOULD")知道订阅状态通知
的回复，发送过一个"unsubscribed"类型的"presence stanza"就是"affirming"它，发送过一
个"subscribed"类型的"presence stanza"就是"denying"它；这一步不是必不可不少的，
但是可代替让联系人的服务器知道它必须("MUST")不再发送订阅状态的变更给联系人.
5. The contact's server then (1) MUST send a presence stanza of type
"unsubscribed" to the user; and (2) SHOULD send unavailable
presence from all of the contact's available resources to the
user:
联系人的服务器然后(1)必须("MUST")发送一个"unsubscribed"类型的"presence stanza"给用户；(2)
应该("SHOULD")从所有的联系人的可用资源发送一个不可用资源给用户：
<presence
from='[email protected]'
to='[email protected]'
type='unsubscribed'/>
Saint-Andre Standards Track [Page 46]
RFC 3921 XMPP IM October 2004
<presence
from='[email protected]/resource'
to='[email protected]'
type='unavailable'/>
6. When the user's server receives the presence stanzas of type
"unsubscribed" and "unavailable", it MUST deliver them to the
user:
当用户的服务器接收到 "unsubscribed" 和 "unavailable"类型的"presence stanzas"，它
必须("MUST")传递它们给用户。
<presence
from='[email protected]'
to='[email protected]'
type='unsubscribed'/>
<presence
from='[email protected]/resource'
to='[email protected]'
type='unavailable'/>
7. Upon receiving the presence stanza of type "unsubscribed", the
user SHOULD acknowledge receipt of that subscription state
notification through either "affirming" it by sending a presence
stanza of type "unsubscribe" to the contact or "denying" it by
sending a presence stanza of type "subscribe" to the contact;
this step does not necessarily affect the subscription state (see
Subscription States (Section 9) for details), but instead lets
the user's server know that it MUST no longer send notification
of the subscription state change to the user (see Section 9.4).
当接收到 "unsubscribed"类型的"presence stanzas"后，用户应该("SHOULD")
8.4.2. Case #2: Unsubscribing When Subscription is Mutual
In the second case, the user has a subscription to the contact's
presence information and the contact also has a subscription to the
user's presence information (i.e., the subscription is mutual).
在第一个例子中，用户有一个联系人的订阅，联系人有订阅用户的"presence"信息(也就是，是相互订阅).
1. If the user wants to unsubscribe from the contact's presence
information, the user MUST send a presence stanza of type
"unsubscribe" to the contact:
如果用户想要取消订阅，用户必须("MUST")发送一个"unsubscribe"类型的"presence stanza"给联系人。
<presence to='[email protected]' type='unsubscribe'/>
2. As a result, the user's server (1) MUST send a roster push to all
of the user's available resources that have requested the roster,
containing an updated roster item for the contact with the
'subscription' attribute set to a value of "from"; and (2) MUST
route the presence stanza of type "unsubscribe" to the contact,
first stamping the 'from' address as the bare JID
(<[email protected]>) of the user:
结果,用户的服务器(1)必须("MUST")发送一个"roster push"给所有用户的那些请求过花名薄("roster")的
可用资源,其中包含一个用于更新的"subscription"属性值为"none"的关于联系人的花名薄("roster")条目；
(2)必须("MUST")路由类型为"unsubscribe"的"presence stanza"给联系人，当然要将"from"地址标记为
用户的赤裸的JID(<[email protected]>):
Saint-Andre Standards Track [Page 47]
RFC 3921 XMPP IM October 2004
<iq type='set'>
<query xmlns='jabber:iq:roster'>
<item
jid='[email protected]'
subscription='from'
name='MyContact'>
<group>MyBuddies</group>
</item>
</query>
</iq>
<presence
from='[email protected]'
to='[email protected]'
type='unsubscribe'/>
3. Upon receiving the presence stanza of type "unsubscribe"
addressed to the contact, the contact's server (1) MUST initiate
a roster push to all available resources associated with the
contact that have requested the roster, containing an updated
roster item for the user with the 'subscription' attribute set to
a value of "to" (if the contact is unavailable or has not
requested the roster, the contact's server MUST modify the roster
item and send that modified item the next time the contact
requests the roster); and (2) MUST deliver the "unsubscribe"
state change notification to the contact:
在接收到给联系人的"unsubscribe"类型的"presence stanza"后，联系人的服务器(1)必须("MUST")
初始化一个"roster push"给所有联系人的那些请求过花名薄("roster")的可用资源，其中包含一个用于
更新的"subscription"属性值为"to"的关于用户的花名薄("roster")条目()；(2)必须("MUST")传
递"unsubscribe"状态变更通知给联系人：
<iq type='set'>
<query xmlns='jabber:iq:roster'>
<item
jid='[email protected]'
subscription='to'
name='SomeUser'>
<group>SomeGroup</group>
</item>
</query>
</iq>
<presence
from='[email protected]'
to='[email protected]'
type='unsubscribe'/>
4. Upon receiving the presence stanza of type "unsubscribe", the
contact SHOULD acknowledge receipt of that subscription state
notification through either "affirming" it by sending a presence
stanza of type "unsubscribed" to the user or "denying" it by
sending a presence stanza of type "subscribed" to the user; this
Saint-Andre Standards Track [Page 48]
RFC 3921 XMPP IM October 2004
step does not necessarily affect the subscription state (see
Subscription States (Section 9) for details), but instead lets
the contact's server know that it MUST no longer send
notification of the subscription state change to the contact (see
Section 9.4).
在接收到"unsubscribe"类型的"presence stanza"，联系人应该("SHOULD")知道订阅状态通知
的回复，发送过一个"unsubscribed"类型的"presence stanza"就是"affirming"它，发送过一
个"subscribed"类型的"presence stanza"就是"denying"它；这一步不是必不可不少的，
但是可代替让联系人的服务器知道它必须("MUST")不再发送订阅状态的变更给联系人.
5. The contact's server then (1) MUST send a presence stanza of type
"unsubscribed" to the user; and (2) SHOULD send unavailable
presence from all of the contact's available resources to the
user:
联系人的服务器然后(1)必须("MUST")发送一个"unsubscribed"类型的"presence stanza"给用户；(2)
应该("SHOULD")从所有的联系人的可用资源发送一个不可用资源给用户：
<presence
from='[email protected]'
to='[email protected]'
type='unsubscribed'/>
<presence
from='[email protected]/resource'
to='[email protected]'
type='unavailable'/>
6. When the user's server receives the presence stanzas of type
"unsubscribed" and "unavailable", it MUST deliver them to the
user:
当用户的服务器接收到 "unsubscribed" 和 "unavailable"类型的"presence stanzas"，它
必须("MUST")传递它们给用户。
<presence
from='[email protected]'
to='[email protected]'
type='unsubscribed'/>
<presence
from='[email protected]/resource'
to='[email protected]'
type='unavailable'/>
7. Upon receiving the presence stanza of type "unsubscribed", the
user SHOULD acknowledge receipt of that subscription state
notification through either "affirming" it by sending a presence
stanza of type "unsubscribe" to the contact or "denying" it by
sending a presence stanza of type "subscribe" to the contact;
this step does not necessarily affect the subscription state (see
Subscription States (Section 9) for details), but instead lets
the user's server know that it MUST no longer send notification
of the subscription state change to the user (see Section 9.4).
Note: Obviously this does not result in removal of the roster item
from the user's roster, and the contact still has a subscription to
the user's presence information. In order to both completely cancel
Saint-Andre Standards Track [Page 49]
RFC 3921 XMPP IM October 2004
a mutual subscription and fully remove the roster item from the
user's roster, the user SHOULD update the roster item with
subscription='remove' as defined under Removing a Roster Item and
Cancelling All Subscriptions (Section 8.6).
注意：明显地导致没有从用户的花名薄("roster")中删除花名薄("roster")条目，联系人仍然有
一个用户"presence"信息的订阅，为了完整的取消一个相互的订阅，并完全地从用户的花名薄("roster")
删除花名薄("roster")条目，用户将用subscription='remove'来更新花名薄("roster")条目，见第8.6节。
8.5. Cancelling a Subscription
At any time after approving a subscription request from a user, a
contact MAY cancel that subscription. While the XML that the contact
sends to make this happen is the same in all instances, the
subsequent subscription state is different depending on the
subscription state obtaining when the cancellation was sent. Both
possible scenarios are described below.
在答应了一个用户的"presence"请求之后在任何时候，联系人可能("MAY")取消订阅请求，在所有实例中当联系人发
送这些XML都是相同的，在取消发送时后续的订阅状态依赖于订阅状态而不同。可能的设想描述在
下面.
8.5.1. Case #1: Cancelling When Subscription is Not Mutual
In the first case, the user has a subscription to the contact's
presence information but the contact does not have a subscription to
the user's presence information (i.e., the subscription is not yet
mutual).
在第一个例子中，用户有一个联系人的订阅，但联系人没有订阅用户的"presence"信息(也就是，不是相互订阅).
1. If the contact wants to cancel the user's subscription, the
contact MUST send a presence stanza of type "unsubscribed" to the
user:
如果联系人想要取消用户订阅，联系人必须("MUST")发送一个"unsubscribed"类型的"presence stanza"给用户。
<presence to='[email protected]' type='unsubscribed'/>
2. As a result, the contact's server (1) MUST send a roster push to
all of the contact's available resources that have requested the
roster, containing an updated roster item for the user with the
'subscription' attribute set to a value of "none"; (2) MUST route
the presence stanza of type "unsubscribed" to the user, first
stamping the 'from' address as the bare JID
(<[email protected]>) of the contact; and (3) SHOULD send
unavailable presence from all of the contact's available
resources to the user:
结果,联系人的服务器(1)必须("MUST")发送一个"roster push"给所有联系人的那些请求过花名薄("roster")的
可用资源,其中包含一个用于更新的"subscription"属性值为"none"的关于联系人的花名薄("roster")条目；
(2)必须("MUST")路由类型为"unsubscribed"的"presence stanza"给联系人，当然要将"from"地址标记为
联系人的赤裸的JID(<[email protected]>)，(3)应该("SHOULD")从所有联系人的可用资源发送不可用"presence":
<iq type='set'>
<query xmlns='jabber:iq:roster'>
<item
jid='[email protected]'
subscription='none'
name='SomeUser'>
<group>SomeGroup</group>
</item>
</query>
</iq>
Saint-Andre Standards Track [Page 50]
RFC 3921 XMPP IM October 2004
<presence
from='[email protected]'
to='[email protected]'
type='unsubscribed'/>
<presence
from='[email protected]/resource'
to='[email protected]'
type='unavailable'/>
3. Upon receiving the presence stanza of type "unsubscribed"
addressed to the user, the user's server (1) MUST initiate a
roster push to all of the user's available resources that have
requested the roster, containing an updated roster item for the
contact with the 'subscription' attribute set to a value of
"none" (if the user is unavailable or has not requested the
roster, the user's server MUST modify the roster item and send
that modified item the next time the user requests the roster);
(2) MUST deliver the "unsubscribed" state change notification to
all of the user's available resources; and (3) MUST deliver the
unavailable presence to all of the user's available resources:
在接收到给用户的"unsubscribed"类型的"presence stanza"后，用户的服务器(1)必须("MUST")
初始化一个"roster push"给所有用户的那些请求过花名薄("roster")的可用资源，其中包含一个用于
更新的"subscription"属性值为"none"的关于联系人的花名薄("roster")条目()；(2)必须("MUST")
传递"unsubscribed"状态变更通知给用户的所有可用资源；(3)：必须("MUST")传递不可用"presence"
给用户的所有可用资源：
<iq type='set'>
<query xmlns='jabber:iq:roster'>
<item
jid='[email protected]'
subscription='none'
name='MyContact'>
<group>MyBuddies</group>
</item>
</query>
</iq>
<presence
from='[email protected]'
to='[email protected]'
type='unsubscribed'/>
<presence
from='[email protected]/resource'
to='[email protected]'
type='unavailable'/>
4. Upon receiving the presence stanza of type "unsubscribed", the
user SHOULD acknowledge receipt of that subscription state
notification through either "affirming" it by sending a presence
stanza of type "unsubscribe" to the contact or "denying" it by
sending a presence stanza of type "subscribe" to the contact;
Saint-Andre Standards Track [Page 51]
RFC 3921 XMPP IM October 2004
this step does not necessarily affect the subscription state (see
Subscription States (Section 9) for details), but instead lets
the user's server know that it MUST no longer send notification
of the subscription state change to the user (see Section 9.4).
8.5.2. Case #2: Cancelling When Subscription is Mutual
In the second case, the user has a subscription to the contact's
presence information and the contact also has a subscription to the
user's presence information (i.e., the subscription is mutual).
在第二个例子中，用户有一个联系人的订阅，联系人也订阅了用户的"presence"信息(也就是，是相互订阅).
1. If the contact wants to cancel the user's subscription, the
contact MUST send a presence stanza of type "unsubscribed" to the
user:
如果联系人想要取消用户订阅，联系人必须("MUST")发送一个"unsubscribed"类型的"presence stanza"给用户。
<presence to='[email protected]' type='unsubscribed'/>
2. As a result, the contact's server (1) MUST send a roster push to
all of the contact's available resources that have requested the
roster, containing an updated roster item for the user with the
'subscription' attribute set to a value of "to"; (2) MUST route
the presence stanza of type "unsubscribed" to the user, first
stamping the 'from' address as the bare JID
(<[email protected]>) of the contact; and (3) SHOULD send
unavailable presence from all of the contact's available
resources to all of the user's available resources:
结果,联系人的服务器(1)必须("MUST")发送一个"roster push"给所有联系人的那些请求过花名薄("roster")的
可用资源,其中包含一个用于更新的"subscription"属性值为"none"的关于联系人的花名薄("roster")条目；
(2)必须("MUST")路由类型为"unsubscribed"的"presence stanza"给联系人，当然要将"from"地址标记为
联系人的赤裸的JID(<[email protected]>)，(3)应该("SHOULD")从所有联系人的可用资源发送不可用"presence":
<iq type='set'>
<query xmlns='jabber:iq:roster'>
<item
jid='[email protected]'
subscription='to'
name='SomeUser'>
<group>SomeGroup</group>
</item>
</query>
</iq>
<presence
from='[email protected]'
to='[email protected]'
type='unsubscribed'/>
<presence
from='[email protected]/resource'
to='[email protected]'
type='unavailable'/>
Saint-Andre Standards Track [Page 52]
RFC 3921 XMPP IM October 2004
3. Upon receiving the presence stanza of type "unsubscribed"
addressed to the user, the user's server (1) MUST initiate a
roster push to all of the user's available resources that have
requested the roster, containing an updated roster item for the
contact with the 'subscription' attribute set to a value of
"from" (if the user is unavailable or has not requested the
roster, the user's server MUST modify the roster item and send
that modified item the next time the user requests the roster);
and (2) MUST deliver the "unsubscribed" state change notification
to all of the user's available resources; and (3) MUST deliver
the unavailable presence to all of the user's available
resources:
在接收到给用户的"unsubscribed"类型的"presence stanza"后，用户的服务器(1)必须("MUST")
初始化一个"roster push"给所有用户的那些请求过花名薄("roster")的可用资源，其中包含一个用于
更新的"subscription"属性值为"none"的关于联系人的花名薄("roster")条目()；(2)必须("MUST")
传递"unsubscribed"状态变更通知给用户的所有可用资源；(3)：必须("MUST")传递不可用"presence"
给用户的所有可用资源：
<iq type='set'>
<query xmlns='jabber:iq:roster'>
<item
jid='[email protected]'
subscription='from'
name='MyContact'>
<group>MyBuddies</group>
</item>
</query>
</iq>
<presence
from='[email protected]'
to='[email protected]'
type='unsubscribed'/>
<presence
from='[email protected]/resource'
to='[email protected]'
type='unavailable'/>
4. Upon receiving the presence stanza of type "unsubscribed", the
user SHOULD acknowledge receipt of that subscription state
notification through either "affirming" it by sending a presence
stanza of type "unsubscribe" to the contact or "denying" it by
sending a presence stanza of type "subscribe" to the contact;
this step does not necessarily affect the subscription state (see
Subscription States (Section 9) for details), but instead lets
the user's server know that it MUST no longer send notification
of the subscription state change to the user (see Section 9.4).
Note: Obviously this does not result in removal of the roster item
from the contact's roster, and the contact still has a subscription
to the user's presence information. In order to both completely
cancel a mutual subscription and fully remove the roster item from
Saint-Andre Standards Track [Page 53]
RFC 3921 XMPP IM October 2004
the contact's roster, the contact should update the roster item with
subscription='remove' as defined under Removing a Roster Item and
Cancelling All Subscriptions (Section 8.6).
注意：明显地导致没有从联系人的花名薄("roster")中删除花名薄("roster")条目，用户仍然有
一个联系人"presence"信息的订阅，为了完整的取消一个相互的订阅，并完全地从联系人的花名薄("roster")
删除花名薄("roster")条目，联系人将用subscription='remove'来更新花名薄("roster")条目，见第8.6节。
8.6. Removing a Roster Item and Cancelling All Subscriptions
Because there may be many steps involved in completely removing a
roster item and cancelling subscriptions in both directions, the
roster management protocol includes a "shortcut" method for doing so.
The process may be initiated no matter what the current subscription
state is by sending a roster set containing an item for the contact
with the 'subscription' attribute set to a value of "remove":
<iq type='set' id='remove1'>
<query xmlns='jabber:iq:roster'>
<item
jid='[email protected]'
subscription='remove'/>
</query>
</iq>
When the user removes a contact from his or her roster by setting the
'subscription' attribute to a value of "remove", the user's server
(1) MUST automatically cancel any existing presence subscription
between the user and the contact (both 'to' and 'from' as
appropriate); (2) MUST remove the roster item from the user's roster
and inform all of the user's available resources that have requested
the roster of the roster item removal; (3) MUST inform the resource
that initiated the removal of success; and (4) SHOULD send
unavailable presence from all of the user's available resources to
the contact:
当用户用一个"subscription"属性值为"remove"来从他的花名薄("roster")中删除一个联系人时，用户的
服务器(1)必须("MUST")自动地取消任何存在的用户与联系人之间的"presence"订阅；(2)必须("MUST")删
除从用户的花名薄("roster")中删除花名薄("roster")条目，通知用户的所有请求过花名薄("roster")的
可用资源花名薄("roster")条目被删除；(3)必须("MUST")通知发送删除请求的资源成功；(4)应该("SHOULD")
从用户所有可用资源发送不可用"presence"给联系人：
<presence
from='[email protected]'
to='[email protected]'
type='unsubscribe'/>
<presence
from='[email protected]'
to='[email protected]'
type='unsubscribed'/>
Saint-Andre Standards Track [Page 54]
RFC 3921 XMPP IM October 2004
<iq type='set'>
<query xmlns='jabber:iq:roster'>
<item
jid='[email protected]'
subscription='remove'/>
</query>
</iq>
<iq type='result' id='remove1'/>
<presence
from='[email protected]/resource'
to='[email protected]'
type='unavailable'/>
Upon receiving the presence stanza of type "unsubscribe", the
contact's server (1) MUST initiate a roster push to all available
resources associated with the contact that have requested the roster,
containing an updated roster item for the user with the
'subscription' attribute set to a value of "to" (if the contact is
unavailable or has not requested the roster, the contact's server
MUST modify the roster item and send that modified item the next time
the contact requests the roster); and (2) MUST also deliver the
"unsubscribe" state change notification to all of the contact's
available resources:
在接收到"unsubscribe"类型的"presence stanza"后，联系人的服务器(1)必须("MUST")初
始化一个"roster push"给所有联系人的那些请求过花名薄("roster")的可用资源，其中包含
一个用于更新的"subscription"属性值为"to"的关于用户的花名薄("roster")条目()；(2)必
须("MUST")传递"unsubscribe"状态变更通知给联系人的所有可用资源：
<iq type='set'>
<query xmlns='jabber:iq:roster'>
<item
jid='[email protected]'
subscription='to'
name='SomeUser'>
<group>SomeGroup</group>
</item>
</query>
</iq>
<presence
from='[email protected]'
to='[email protected]'
type='unsubscribe'/>
Upon receiving the presence stanza of type "unsubscribed", the
contact's server (1) MUST initiate a roster push to all available
resources associated with the contact that have requested the roster,
containing an updated roster item for the user with the
'subscription' attribute set to a value of "none" (if the contact is
unavailable or has not requested the roster, the contact's server
Saint-Andre Standards Track [Page 55]
RFC 3921 XMPP IM October 2004
MUST modify the roster item and send that modified item the next time
the contact requests the roster); and (2) MUST also deliver the
"unsubscribe" state change notification to all of the contact's
available resources:
在接收到"unsubscribed"类型的"presence stanza"后，联系人的服务器(1)必须("MUST")初
始化一个"roster push"给所有联系人的那些请求过花名薄("roster")的可用资源，其中包含
一个用于更新的"subscription"属性值为"none"的关于用户的花名薄("roster")条目()；(2)必
须("MUST")传递"unsubscribe"状态变更通知给联系人的所有可用资源：
<iq type='set'>
<query xmlns='jabber:iq:roster'>
<item
jid='[email protected]'
subscription='none'
name='SomeUser'>
<group>SomeGroup</group>
</item>
</query>
</iq>
<presence
from='[email protected]'
to='[email protected]'
type='unsubscribed'/>
Upon receiving the presence stanza of type "unavailable" addressed to
the contact, the contact's server MUST deliver the unavailable
presence to all of the user's available resources:
在接收到"unavailable"类型的"presence stanza"后，联系人的服务器必须("MUST")传递
不可用"presence"("unavailable presence")给用户的所有可用资源：
<presence
from='[email protected]/resource'
to='[email protected]'
type='unavailable'/>
Note: When the user removes the contact from the user's roster, the
end state of the contact's roster is that the user is still in the
contact's roster with a subscription state of "none"; in order to
completely remove the roster item for the user, the contact needs to
also send a roster removal request.
注意：当用户从用户的花名薄("roster")中删除联系人时，联系人的花名薄("roster")最后的
状态是用户仍然在联系人的花名薄("roster")中，其用户的订阅状态是"none"；为了完整地从
花名薄("roster")中删除关于这个用户的花名薄("roster")条目，联系人也需要发送一个"roster removal"
请求。
9. Subscription States
This section provides detailed information about subscription states
and server handling of subscription-related presence stanzas (i.e.,
presence stanzas of type "subscribe", "subscribed", "unsubscribe",
and "unsubscribed").
这一节详细描述了关于订阅状态和服务器的订阅相关的"presence stanza"的处理(也就是，"subscribe",
"subscribed", "unsubscribe",和 "unsubscribed"类型的"presence stanza" )
9.1. Defined States
There are nine possible subscription states, which are described here
from the user's (not contact's) perspective:
有9个可能的订阅状态，从用户的角度看描述如下
Saint-Andre Standards Track [Page 56]
RFC 3921 XMPP IM October 2004
1. "None" = contact and user are not subscribed to each other, and
neither has requested a subscription from the other
"None" = 联系人和用户没有互相订阅，两者都没有从对方请求一个订阅。
2. "None + Pending Out" = contact and user are not subscribed to
each other, and user has sent contact a subscription request but
contact has not replied yet
"None + Pending Out" = 联系人和用户没有互相订阅对方，用户有发送给联系人一个订阅
请求但联系人没有回复。
3. "None + Pending In" = contact and user are not subscribed to each
other, and contact has sent user a subscription request but user
has not replied yet (note: contact's server SHOULD NOT push or
deliver roster items in this state, but instead SHOULD wait until
contact has approved subscription request from user)
"None + Pending In" = 联系人和用户没有互相订阅对方，联系人有发送给用户一个订阅
请求但用户没有回复(注意，在这个状态联系人的服务器不应该("SHOULD NO") "push"或传
递花名薄("roster")条目，但 )。
4. "None + Pending Out/In" = contact and user are not subscribed to
each other, contact has sent user a subscription request but user
has not replied yet, and user has sent contact a subscription
request but contact has not replied yet
"None + Pending Out/In" = 联系人和用户没有互相订阅对方，联系人有发送给用户一个订阅
请求但用户没有回复,用户也发送给联系人一个订阅请求但联系人没有回复
5. "To" = user is subscribed to contact (one-way)
"To" = 用户有订阅联系人
6. "To + Pending In" = user is subscribed to contact, and contact
has sent user a subscription request but user has not replied yet
"To + Pending In" = 用户有订阅联系人，联系人有发送给用户一个订阅请求但用户没有回复
7. "From" = contact is subscribed to user (one-way)
"From" = 联系人有订阅用户
8. "From + Pending Out" = contact is subscribed to user, and user
has sent contact a subscription request but contact has not
replied yet
"To" = 联系人有订阅用户，用户也发送给联系人一个订阅请求但联系人没有回复
9. "Both" = user and contact are subscribed to each other (two-way)
"To" = 联系人和用户互相订阅对方
9.2. Server Handling of Outbound Presence Subscription Stanzas
Outbound presence subscription stanzas enable the user to manage his
or her subscription to the contact's presence information (via the
"subscribe" and "unsubscribe" types), and to manage the contact's
access to the user's presence information (via the "subscribed" and
"unsubscribed" types).
关于订阅的"Outbound presence stanza"让用户能够理它的联系人的"presence"订阅信息(通过"subscribe"和
"unsubscribe"类型),管理联系人访问用户的"presence"信息(通过 "subscribed" 和 "unsubscribed"类型).
Because it is possible for the user's server and the contact's server
to lose synchronization regarding subscription states, the user's
server MUST without exception route all outbound presence stanzas of
type "subscribe" or "unsubscribe" to the contact so that the user is
able to resynchronize his or her subscription to the contact's
presence information if needed.
因为用户的服务器和联系人的服务器可能丢失关于订阅状态的同步信息。
