{{{ 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 , , and children of the stream root -- provide the building blocks for many types of near-real-time applications, which may be layered on top of the core by sending application-specific data qualified by particular XML namespaces [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的使用，以及像,以及 这样的流的子元素——提供给我们一些素材，使我们能创建很多"半实时(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 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)包含 child；具体细节请看[XMPP-CORE]。 除此之外，message stanza可以(MAY)不经声明就使用下列的child elements。 1. 2. 3. 2.1.2.1. Subject The element contains human-readable XML character data that specifies the topic of the message. The element MUST NOT possess any attributes, with the exception of the 'xml:lang' attribute. Multiple instances of the element MAY be included for the purpose of providing alternate versions of the same subject, but only if each instance possesses an 'xml:lang' attribute with a distinct language value. The element MUST NOT contain mixed content (as defined in Section 3.2.2 of [XML]). element包含human-readable的，表示message的标题的XML字符数据。 绝对不能(MUST NOT)包含除'xml:lang'之外的任何属性。为了能提供同一个 subject的多个版本，一个message里面可以(MAY)包含多个 element。但这仅限于 每个都包含'xml:lang'属性，并且其language值都不相同的情形。 绝对不能(MUST NOT)包含mixed content(见Section 3.2.2) 2.1.2.2. Body The 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 element MUST NOT possess any attributes, with the exception of the 'xml:lang' attribute. Multiple instances of the element MAY be included but only if each instance possesses an 'xml:lang' attribute with a distinct language value. The element MUST NOT contain mixed content (as defined in Section 3.2.2 of [XML]). element包含human-readable的，用来表示消息的正文内容的XML字符数据；通常 message都会包含这个child，但它是可选的(OPTIONAL)。 element绝对不能(MUST NOT) 包含除'xml:lang'之外的任何属性。一个message里面可以(MAY)包含多个 element。 但这仅限于每个都包含'xml:lang'属性，并且其language值都不相同的情形。 绝对不能(MUST NOT)包含mixed content(见Section 3.2.2) 2.1.2.3. Thread The 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 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 element is OPTIONAL and is not used to identify individual messages, only conversations. A message stanza MUST NOT contain more than one element. The element MUST NOT possess any attributes. The value of the 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 element MUST NOT contain mixed content (as defined in Section 3.2.2 of [XML]). element包含非human-readable的XML字符数据。它是一个用于表示两个entity 之间的conversion thread的(有时也被称作"instance messaging session")标识符。 element的值由sender生成，而且每次回复的时候必须(SHOULD)包含在内。如果 用到了它，那么它必须(MUST)与stream里的conversation thread一一对应，而且整个谈话期间 必须保持一致(如果client端收到了同一个JID发出的，但是thread ID不同的message，必须(MUST) 认定这个消息与当前的conversation thread无关。) element是OPTIONAL的， 且不用于标识单个message，它是用来标识conversation的。一个message stanza MUST NOT 包含二个或二个以上的 element。 element MUST NOT包含任何属性。 对entities来说的值必须(MUST)是不透明的；不能用它来获取任何语义信息，而且只能 对它进行精确地比较。 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 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 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包含；细节请看 [XMPP-CORE]。如果presence stanza没有'type'属性，那么它MAY包含下列child element (注意， child可以随'unavailable' type的presence stanza或，出于历史原因， 'subscribe' type的presence stanza发出。) 1. 2. 3. 2.2.2.1. Show The OPTIONAL 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 element. The 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的 element包含非human-readable的XML字符数据。它表示某个entity 或资源的可得性。presence stanza绝对不能(MUST NOT)包含两个或两个以上的。 MUST NOT包含任何属性。如果(presence stanza)里有()，那么它的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 element is provided, the entity is assumed to be online and available. 如果没有 element，那么这个entity就将被认为是可得的。 2.2.2.2. Status The OPTIONAL 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 element MUST NOT possess any attributes, with the exception of the 'xml:lang' attribute. Multiple instances of the element MAY be included but only if each instance possesses an 'xml:lang' attribute with a distinct language value. OPTIONAL的 element包含了用人类语言描述的可得性状态的XML字符数据。通常它会 和 element一起使用，以提供可得性状态的详细描述(比方说"在开会")。 MUST NOT包含除xml:lang之外的任何属性。presence stanza里面可以(MAY)包含多个， 只是每个都必须包含一个xml:lang属性并且其language的值不同。 2.2.2.3. Priority The OPTIONAL 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 element. The 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的 element包含非human-readable的，表示资源优先级的XML字符数据。 它的值MUST是一个介于-128到+127之间的整数。presence stanza MUST NOT包含两个或 两个以上的元素。元素MUST NOT包含任何属性。如果(presence stanza)没有提供，那么服务器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 ). 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'名字空间除了常用的之外没有再定义别的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 . 如果entity收到的'get'或'set'类型的IQ stanza里包含一个它所不认识的namespace 的child element的话，那么这个entity SHOULD回一个error condition为 的'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 , after which the entity is now said to be a "connected resource" in the terminology of [XMPP-CORE]. 资源绑定 -- 流认证完毕之后，客户MUST在这个流上绑定资源，这样客户的地址才会符合 的格式。只有在做完这些之后，entity才能被视作是[XMPP-CORE] 所称的'在线资源(connected resource)'。 If a server supports sessions, it MUST include a 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' 名字空间下的 element。 Server advertises session establishment feature to client: 服务器向客户公告会话建立的功能: 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 child element qualified by the 'urn:ietf:params:xml:ns:xmpp-session' namespace: 客户端会如此这般地被告知必须先建立session(并且在绑定资源)，如果它想使用IM和presence 功能，就MUST先建立session。这一步是通过向sever发一个'set'类型的，包含一个空的 child element的，归在'urn:ietf:params:xml:ns:xmpp-session'名字空间 之下的IQ stanza来完成的。 Step 1: Client requests session with server: 第一步：客户向server请求会话： Step 2: Server informs client that session has been created: 第二步：服务器通知客户，会话已经创建完毕： 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): 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回答(此用户名或资源不允许创建会话): 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 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 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发一个 stream error，并且中止连接这个active resource 的XML流和TCP连接，然后给新会话发一个'result' type(表示成功)的IQ stanza。在case #2 下，server SHOULD发送一个 stanza错误给新的会话请求，但它必须保持这条XML stream，这样再再次发送建立会话的请求之前，新请求的会话就有机会来协商一个不会引起冲突的 资源表示符了。 Step 2 (alt): Server informs existing active resource of resource conflict (case #1): 第二步(亦有可能出现)：服务器端告诉已连接的active resource，资源冲突(case #1): Step 2 (alt): Server informs newly-requested session of resource conflict (case #2): 第二步(亦有可能出现)：服务器端告诉新申请的会话，出现资源冲突(#case 2)： 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 stanza. If the message is being sent in reply to a message previously received from an address of the form (e.g., within the context of a chat session), the value of the 'to' address SHOULD be of the form rather than of the form 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 rather than of the form . IM的客户SHOULD在 stanza的'to'属性里提供一个与sender不同的JID，并以此 指定这条消息的接受方。如果这条消息是回应先前收到的，来自的 消息的(比方说在一个chat session里)，那么'to'地址仍然SHOULD是 而不是，除非发送方知道(通过presence)，接受方的资源已经不可得了。如果 发送的消息不在任何现存的chat session或received message环境下，'to'地址的值SHOULD 是而不是形式的。 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: Wherefore art thou, Romeo? 4.3. Specifying a Message Body A message stanza MAY (and often will) contain a child element whose XML character data specifies the primary meaning of the message (see Body (Section 2.1.2.2)). 一个消息"stanza"可能("MAY")（经常）包含一个子节点，它的XML字符指示消息 的含义（见第2.1.2.2节）。 Example: A message with a body: Wherefore art thou, Romeo? PročeŽ jsi ty, Romeo? 4.4. Specifying a Message Subject A message stanza MAY contain one or more child elements specifying the topic of the message (see Subject (Section 2.1.2.1)). 一个消息"stanza"可能("MAY")包含一个子节点指示消息 的主题（见第2.1.2.1节）。 Saint-Andre Standards Track [Page 14] RFC 3921 XMPP IM October 2004 Example: A message with a subject: I implore you! Úpěnlivě prosim! Wherefore art thou, Romeo? PročeŽ jsi ty, Romeo? 4.5. Specifying a Conversation Thread A message stanza MAY contain a child element specifying the conversation thread in which the message is situated, for the purpose of tracking the conversation (see Thread (Section 2.1.2.3)). 一个消息"stanza"可能("MAY")包含一个子节点指示了消息位于哪一个会话线索， 以便跟踪会话。（见第2.1.2.3节）。 Example: A threaded conversation: Art thou not Romeo, and a Montague? e0ffe42b28561960c6b12b944a092794b9683a38 Neither, fair saint, if either thee dislike. e0ffe42b28561960c6b12b944a092794b9683a38 How cam'st thou hither, tell me, and wherefore? e0ffe42b28561960c6b12b944a092794b9683a38 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., ) 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., ) 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 () 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(),但仅是如果用户在联系人的花 名薄("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 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 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 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 rather than , 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应该用 格式优先于格式， 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 element (see Show (Section 2.2.2.1)). 一个客户端可能("MAY")用节点提供关于它的可用性状态补充信息。 Example: Availability status: 例如: 可用性状态： dnd 5.3. Specifying Detailed Status Information In conjunction with the element, a client MAY provide detailed status information by using the element (see Status (Section 2.2.2.2)). 与节点一起，一个客户端可能("MAY")用节点提供关于它的详细状态信息。 Example: Detailed status information: 例如: 可用性状态详细状态信息： dnd Wooing Juliet Ja dvořím Juliet 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 element (see Priority (Section 2.2.2.3)). 一个客户端可能("MAY")用节点提供关于它的资源优先级。 Example: Presence priority: dnd Wooing Juliet Ja dvořím Juliet 1 5.5. Presence Examples The examples in this section illustrate the presence-related protocols described above. The user is romeo@example.net, he has an available resource whose resource identifier is "orchard", and he has the following individuals in his roster: 在这节中例子展示了上面描述的关于"presence"协议。用户是" romeo@example.net",它有 一个资源标识为"orchard"的可用资源，它在它的花名薄("roster")中下列人士 o juliet@example.com (subscription="both" and she has two available resources, one whose resource is "chamber" and another whose resource is "balcony") (subscription="both"，她有两个可用资源，一个是"chamber"，另一个是"balcony") o benvolio@example.org (subscription="to") o mercutio@example.org (subscription="from") Example 1: User sends initial presence: 例1：用户发送初始化"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"的联系人 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"的联系人 Example 4: Contacts' servers reply to presence probe on behalf of all available resources: 例4：联系人的服务器代表所有的可用资源回复"presence"探针("presence probe") away be right back 0 1 dnd gallivanting Example 5: Contacts' servers deliver user's initial presence to all available resources or return error to user: 例4：联系人的服务器传递用户的初始化"presence"("initial presence")给所有的 可用资源，或返回错误给用户: Saint-Andre Standards Track [Page 23] RFC 3921 XMPP IM October 2004 Example 6: User sends directed presence to another user not in his roster: 例6：用户发送直接"presence"("directed presence")给另一个不在他的花名薄("roster") 中的用户: dnd courting Juliet 0 Example 7: User sends updated available presence information for broadcasting: 例7：用户广播发送更新可用"presence"信息: away I shall return! 1 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")的): away I shall return! 1 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...] away I shall return! 1 [to "chamber" resource...] away I shall return! 1 Example 10: One of the contact's resources broadcasts final presence: 例10：联系人的资源中的一个广播最后"presence"("final presence")信息: Example 11: Contact's server sends unavailable presence information to user: 例10：联系人的服务器发送不可用"presence"("unavailable presence")信息给用户: Example 12: User sends final presence: 例10：用户发送最后"presence"("final presence"): gone home 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"): gone home gone home 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: 例：发送一个订阅请求 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: 例：同意一个订阅请求 Example: Refusing a presence subscription request: 例：拒绝一个订阅请求 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: 例：取消一个先前允许的订阅请求。 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: 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 ). 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(通常是格式)标 识。一个用户的花名薄("roster")是由用户的服务器代表用户来保存的，这样用户可能从任何资 资处访问花名薄("roster")。 注意： 7.1. Syntax and Semantics Rosters are managed using IQ stanzas, specifically by means of a child element qualified by the 'jabber:iq:roster' namespace. The element MAY contain one or more children, each describing a unique roster item or "contact". 花名薄("roster")是用"IQ stanza"来管理的，它是'jabber:iq:roster'命名空间下的 的子节点。节点可能("MAY")包含一个或多个子节点，每一个 描述了一个唯一的花名薄("roster")条目或联系人"contact". The "key" or unique identifier for each roster item is a JID, encapsulated in the 'jid' attribute of the element (which is REQUIRED). The value of the 'jid' attribute SHOULD be of the form if the item is associated with another (human) instant messaging user. 每一个花名薄("roster")条目的"key"或唯一标识符是一个JID，放置在节点的"jid"(这 是必需的("REQUIRED")属性中。如果这个项目关联着另一个即时消息用户，"jid"属性值应该("SHOULD") 是格式的。 The state of the presence subscription in relation to a roster item is captured in the 'subscription' attribute of the element. Allowable values for this attribute are: 关于一个花名薄("roster")条目的"presence"订阅状态是保存在节点的"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 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. 每一个节点可能("MAY")包含一个"name"属性，它设置了这个"JID"的呢称("nickname")，它是 用户决定的(不是联系人)，"name"属性是不透明的 Each element MAY contain one or more child elements, for use in collecting roster items into various categories. The XML character data of the 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 ) or full JID (of the form ); otherwise, the client SHOULD ignore the "roster push". 一个服务器必须("MUST")在花名薄("roster")的"set"操作中忽略任何"to"地址，必须("MUST") 象应用于发送者那样信任花名薄("roster")的"set"操作。为了更安全，一个客户端应该("SHOULD") 检查一个"roster push"()的"from"地址来保证它来自一个可信任的源；特别的，"stanza"必须 ("MUST")是没有"from"属性(也就是，)或有一个匹配用户"bare JID"(形如)或完 整JID(形如)的"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") Example: Client receives roster from server: 例：客户端从服务器接收到花名薄("roster") Friends Friends Friends Saint-Andre Standards Track [Page 29] RFC 3921 XMPP IM October 2004 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: Servants 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结果. Servants Servants Saint-Andre Standards Track [Page 30] RFC 3921 XMPP IM October 2004 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: 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")条目 Friends Lovers 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: 例：客户端删除一个条目： 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 element qualified by the 'jabber:iq:roster' namespace, which in turn contains an element that defines the new roster item; the element MUST possess a 'jid' attribute, MAY possess a 'name' attribute, MUST NOT possess a 'subscription' attribute, and MAY contain one or more child elements: 在准备将联系人呈现在用户的界面和服务器明了这个订阅过程中，用户的客户端应该("SHOULD")为 新的花名薄("roster")条目执行一个"roster set"操作。这个请求由发送一个类型为"set"含有 一个在'jabber:iq:roster'命名空间下的子节点的IQ stanza"组成，它依次包含了定 义了一个新花名薄("roster")条目的节点；节点必须("MUST")有一个"jid"属 性，可能("MAY")包含一个或多相子节点: Saint-Andre Standards Track [Page 33] RFC 3921 XMPP IM October 2004 MyBuddies 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结果给这个资源. MyBuddies 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"给联系人: 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 MyBuddies 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 child shown above. 注意：如果在没有发送一个订阅请求之前用户没有创建一个花名薄("roster")条目，服务器必须 ("MUST")现要代表用户创建一个，然后，发送一个"roster push"给用户所有的那些请求过花名 薄("roster")的可用资源，如上面描述的一样没有"name"属性和子节点 5. The user's server MUST also stamp the presence stanza of type "subscribe" with the user's bare JID (i.e., ) 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标记()类型为 "subscribe"的"presence stanza"。如果联系人是与用户不同的主机上的，用户的服务器必须("MUST") 路由"presence stanza"到联系人的服务器上传递给联系人(这件事情是自始自尽都是，然而，如果 联系人在同一主机上，那么服务器能简单的直接地传递它)。 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"给用户来答应订阅请求。 SomeGroup 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 () 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()；(4)必须("MUST")从联系人 的所有可用资源发送可用"presence"给用户： Saint-Andre Standards Track [Page 36] RFC 3921 XMPP IM October 2004 SomeGroup 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" 给用户的每一个可用资源: MyBuddies 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"给用户()： 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 () of the contact: 结果，联系人的服务器必须("MUST")路由"unsubscribed"类型的"presence stanza"给用户，当然首先 要将它用联系人的赤裸的JID()标记"from"地址。 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"属性 的用来更新的条目： MyBuddies 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")自动地发送它). 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 () of the contact: 结果，联系人的服务器（1）必须初始化一个"roster push"给所有用户的那些请求 过花名薄("roster")的可用资源，用户的"subscription"状态依然是"from"，但有在花名薄 ("roster")中包含一个"ask='subscribe'"属性来指明一个未决的"to"订阅；(2)必须("MUST") 路由"subscribe"类型的"presence stanza"给用户，当然首先要将它联系人的赤裸的JID ()标记在"from"中： SomeGroup Saint-Andre Standards Track [Page 40] RFC 3921 XMPP IM October 2004 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"给用户来答应订阅请求。 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 () 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 ()；(3)必须("MUST")从用户的每个可用资源发送最后一次的"presence" 给用户()： Saint-Andre Standards Track [Page 41] RFC 3921 XMPP IM October 2004 MyBuddies 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 SomeGroup 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"给联系人()： 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 () of the user: 结果，用户的服务器必须("MUST")路由"unsubscribed"类型的"presence stanza"给联系人，当然首先 要将它用用户的赤裸的JID()标记"from"地址。 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"属性 的用来更新的条目： SomeGroup 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"给联系人。 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 () of the user: 结果,用户的服务器(1)必须("MUST")发送一个"roster push"给所有用户的那些请求过花名薄("roster")的 可用资源,其中包含一个用于更新的"subscription"属性值为"none"的关于联系人的花名薄("roster")条目； (2)必须("MUST")路由类型为"unsubscribe"的"presence stanza"给联系人，当然要将"from"地址标记为 用户的赤裸的JID(): MyBuddies 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"状态变更通知给联系人： SomeGroup 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")从所有的联系人的可用资源发送一个不可用资源给用户： Saint-Andre Standards Track [Page 46] RFC 3921 XMPP IM October 2004 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")传递它们给用户。 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"给联系人。 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 () of the user: 结果,用户的服务器(1)必须("MUST")发送一个"roster push"给所有用户的那些请求过花名薄("roster")的 可用资源,其中包含一个用于更新的"subscription"属性值为"none"的关于联系人的花名薄("roster")条目； (2)必须("MUST")路由类型为"unsubscribe"的"presence stanza"给联系人，当然要将"from"地址标记为 用户的赤裸的JID(): Saint-Andre Standards Track [Page 47] RFC 3921 XMPP IM October 2004 MyBuddies 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"状态变更通知给联系人： SomeGroup 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")从所有的联系人的可用资源发送一个不可用资源给用户： 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")传递它们给用户。 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"给用户。 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 () 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()，(3)应该("SHOULD")从所有联系人的可用资源发送不可用"presence": SomeGroup Saint-Andre Standards Track [Page 50] 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 "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" 给用户的所有可用资源： MyBuddies 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"给用户。 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 () 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()，(3)应该("SHOULD")从所有联系人的可用资源发送不可用"presence": SomeGroup 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" 给用户的所有可用资源： MyBuddies 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": 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"给联系人： Saint-Andre Standards Track [Page 54] RFC 3921 XMPP IM October 2004 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"状态变更通知给联系人的所有可用资源： SomeGroup 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"状态变更通知给联系人的所有可用资源： SomeGroup 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")给用户的所有可用资源： 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. 因为用户的服务器和联系人的服务器可能丢失关于订阅状态的同步信息。 }}}