Internet Engineering Task Force (IETF) P. Saint-Andre
Request for Comments: 6121 Cisco
Obsoletes: 3921 March 2011
Category: Standards Track
ISSN: 2070-1721
Internet Engineering Task Force (IETF) P. Saint-Andre
Request for Comments: 6121 Cisco
Obsoletes: 3921 March 2011
Category: Standards Track
ISSN: 2070-1721
Extensible Messaging and Presence Protocol (XMPP): Instant Messaging and Presence
可扩展消息和状态协议（XMPP）：即时消息和状态
Abstract
摘要
This document defines extensions to core features of the Extensible Messaging and Presence Protocol (XMPP) that provide basic instant messaging (IM) and presence functionality in conformance with the requirements in RFC 2779. This document obsoletes RFC 3921.
本文档定义了可扩展消息和状态协议（XMPP）核心功能的扩展，该协议根据RFC 2779中的要求提供基本即时消息（IM）和状态功能。本文件废除了RFC 3921。
Status of this Memo
本备忘录的状况
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6121.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6121.
Copyright Notice
版权公告
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2011 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5
1.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 5
1.2. History . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.3. Requirements . . . . . . . . . . . . . . . . . . . . . . 5
1.4. Functional Summary . . . . . . . . . . . . . . . . . . . 7
1.5. Terminology . . . . . . . . . . . . . . . . . . . . . . . 8
2. Managing the Roster . . . . . . . . . . . . . . . . . . . . . 9
2.1. Syntax and Semantics . . . . . . . . . . . . . . . . . . 9
2.1.1. Ver Attribute . . . . . . . . . . . . . . . . . . . . 10
2.1.2. Roster Items . . . . . . . . . . . . . . . . . . . . 10
2.1.2.1. Approved Attribute . . . . . . . . . . . . . . . 10
2.1.2.2. Ask Attribute . . . . . . . . . . . . . . . . . . 10
2.1.2.3. JID Attribute . . . . . . . . . . . . . . . . . . 11
2.1.2.4. Name Attribute . . . . . . . . . . . . . . . . . 11
2.1.2.5. Subscription Attribute . . . . . . . . . . . . . 11
2.1.2.6. Group Element . . . . . . . . . . . . . . . . . . 12
2.1.3. Roster Get . . . . . . . . . . . . . . . . . . . . . 12
2.1.4. Roster Result . . . . . . . . . . . . . . . . . . . . 13
2.1.5. Roster Set . . . . . . . . . . . . . . . . . . . . . 14
2.1.6. Roster Push . . . . . . . . . . . . . . . . . . . . . 14
2.2. Retrieving the Roster on Login . . . . . . . . . . . . . 16
2.3. Adding a Roster Item . . . . . . . . . . . . . . . . . . 17
2.3.1. Request . . . . . . . . . . . . . . . . . . . . . . . 17
2.3.2. Success Case . . . . . . . . . . . . . . . . . . . . 17
2.3.3. Error Cases . . . . . . . . . . . . . . . . . . . . . 18
2.4. Updating a Roster Item . . . . . . . . . . . . . . . . . 22
2.4.1. Request . . . . . . . . . . . . . . . . . . . . . . . 22
2.4.2. Success Case . . . . . . . . . . . . . . . . . . . . 24
2.4.3. Error Cases . . . . . . . . . . . . . . . . . . . . . 24
2.5. Deleting a Roster Item . . . . . . . . . . . . . . . . . 24
2.5.1. Request . . . . . . . . . . . . . . . . . . . . . . . 24
2.5.2. Success Case . . . . . . . . . . . . . . . . . . . . 25
2.5.3. Error Cases . . . . . . . . . . . . . . . . . . . . . 26
2.6. Roster Versioning . . . . . . . . . . . . . . . . . . . . 26
2.6.1. Stream Feature . . . . . . . . . . . . . . . . . . . 26
2.6.2. Request . . . . . . . . . . . . . . . . . . . . . . . 26
2.6.3. Success Case . . . . . . . . . . . . . . . . . . . . 27
3. Managing Presence Subscriptions . . . . . . . . . . . . . . . 30
3.1. Requesting a Subscription . . . . . . . . . . . . . . . . 30
3.1.1. Client Generation of Outbound Subscription Request . 31
3.1.2. Server Processing of Outbound Subscription Request . 32
3.1.3. Server Processing of Inbound Subscription Request . . 34
3.1.4. Client Processing of Inbound Subscription Request . . 35
3.1.5. Server Processing of Outbound Subscription Approval . 36
3.1.6. Server Processing of Inbound Subscription Approval . 38
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5
1.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 5
1.2. History . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.3. Requirements . . . . . . . . . . . . . . . . . . . . . . 5
1.4. Functional Summary . . . . . . . . . . . . . . . . . . . 7
1.5. Terminology . . . . . . . . . . . . . . . . . . . . . . . 8
2. Managing the Roster . . . . . . . . . . . . . . . . . . . . . 9
2.1. Syntax and Semantics . . . . . . . . . . . . . . . . . . 9
2.1.1. Ver Attribute . . . . . . . . . . . . . . . . . . . . 10
2.1.2. Roster Items . . . . . . . . . . . . . . . . . . . . 10
2.1.2.1. Approved Attribute . . . . . . . . . . . . . . . 10
2.1.2.2. Ask Attribute . . . . . . . . . . . . . . . . . . 10
2.1.2.3. JID Attribute . . . . . . . . . . . . . . . . . . 11
2.1.2.4. Name Attribute . . . . . . . . . . . . . . . . . 11
2.1.2.5. Subscription Attribute . . . . . . . . . . . . . 11
2.1.2.6. Group Element . . . . . . . . . . . . . . . . . . 12
2.1.3. Roster Get . . . . . . . . . . . . . . . . . . . . . 12
2.1.4. Roster Result . . . . . . . . . . . . . . . . . . . . 13
2.1.5. Roster Set . . . . . . . . . . . . . . . . . . . . . 14
2.1.6. Roster Push . . . . . . . . . . . . . . . . . . . . . 14
2.2. Retrieving the Roster on Login . . . . . . . . . . . . . 16
2.3. Adding a Roster Item . . . . . . . . . . . . . . . . . . 17
2.3.1. Request . . . . . . . . . . . . . . . . . . . . . . . 17
2.3.2. Success Case . . . . . . . . . . . . . . . . . . . . 17
2.3.3. Error Cases . . . . . . . . . . . . . . . . . . . . . 18
2.4. Updating a Roster Item . . . . . . . . . . . . . . . . . 22
2.4.1. Request . . . . . . . . . . . . . . . . . . . . . . . 22
2.4.2. Success Case . . . . . . . . . . . . . . . . . . . . 24
2.4.3. Error Cases . . . . . . . . . . . . . . . . . . . . . 24
2.5. Deleting a Roster Item . . . . . . . . . . . . . . . . . 24
2.5.1. Request . . . . . . . . . . . . . . . . . . . . . . . 24
2.5.2. Success Case . . . . . . . . . . . . . . . . . . . . 25
2.5.3. Error Cases . . . . . . . . . . . . . . . . . . . . . 26
2.6. Roster Versioning . . . . . . . . . . . . . . . . . . . . 26
2.6.1. Stream Feature . . . . . . . . . . . . . . . . . . . 26
2.6.2. Request . . . . . . . . . . . . . . . . . . . . . . . 26
2.6.3. Success Case . . . . . . . . . . . . . . . . . . . . 27
3. Managing Presence Subscriptions . . . . . . . . . . . . . . . 30
3.1. Requesting a Subscription . . . . . . . . . . . . . . . . 30
3.1.1. Client Generation of Outbound Subscription Request . 31
3.1.2. Server Processing of Outbound Subscription Request . 32
3.1.3. Server Processing of Inbound Subscription Request . . 34
3.1.4. Client Processing of Inbound Subscription Request . . 35
3.1.5. Server Processing of Outbound Subscription Approval . 36
3.1.6. Server Processing of Inbound Subscription Approval . 38
3.2. Canceling a Subscription . . . . . . . . . . . . . . . . 40
3.2.1. Client Generation of Subscription Cancellation . . . 40
3.2.2. Server Processing of Outbound Subscription
Cancellation . . . . . . . . . . . . . . . . . . . . 40
3.2.3. Server Processing of Inbound Subscription
Cancellation . . . . . . . . . . . . . . . . . . . . 41
3.3. Unsubscribing . . . . . . . . . . . . . . . . . . . . . . 43
3.3.1. Client Generation of Unsubscribe . . . . . . . . . . 43
3.3.2. Server Processing of Outbound Unsubscribe . . . . . . 43
3.3.3. Server Processing of Inbound Unsubscribe . . . . . . 44
3.4. Pre-Approving a Subscription Request . . . . . . . . . . 46
3.4.1. Client Generation of Subscription Pre-Approval . . . 46
3.4.2. Server Processing of Subscription Pre-Approval . . . 47
4. Exchanging Presence Information . . . . . . . . . . . . . . . 48
4.1. Presence Fundamentals . . . . . . . . . . . . . . . . . . 48
4.2. Initial Presence . . . . . . . . . . . . . . . . . . . . 49
4.2.1. Client Generation of Initial Presence . . . . . . . . 49
4.2.2. Server Processing of Outbound Initial Presence . . . 50
4.2.3. Server Processing of Inbound Initial Presence . . . . 50
4.2.4. Client Processing of Initial Presence . . . . . . . . 51
4.3. Presence Probes . . . . . . . . . . . . . . . . . . . . . 51
4.3.1. Server Generation of Outbound Presence Probe . . . . 52
4.3.2. Server Processing of Inbound Presence Probe . . . . . 53
4.3.2.1. Handling of the 'id' Attribute . . . . . . . . . 55
4.4. Subsequent Presence Broadcast . . . . . . . . . . . . . . 57
4.4.1. Client Generation of Subsequent Presence Broadcast . 57
4.4.2. Server Processing of Subsequent Outbound Presence . . 57
4.4.3. Server Processing of Subsequent Inbound Presence . . 58
4.4.4. Client Processing of Subsequent Presence . . . . . . 59
4.5. Unavailable Presence . . . . . . . . . . . . . . . . . . 59
4.5.1. Client Generation of Unavailable Presence . . . . . . 59
4.5.2. Server Processing of Outbound Unavailable Presence . 59
4.5.3. Server Processing of Inbound Unavailable Presence . . 61
4.5.4. Client Processing of Unavailable Presence . . . . . . 62
4.6. Directed Presence . . . . . . . . . . . . . . . . . . . . 62
4.6.1. General Considerations . . . . . . . . . . . . . . . 62
4.6.2. Client Generation of Directed Presence . . . . . . . 63
4.6.3. Server Processing of Outbound Directed Presence . . . 63
4.6.4. Server Processing of Inbound Directed Presence . . . 64
4.6.5. Client Processing of Inbound Directed Presence . . . 64
4.6.6. Server Processing of Presence Probes . . . . . . . . 64
4.7. Presence Syntax . . . . . . . . . . . . . . . . . . . . . 65
4.7.1. Type Attribute . . . . . . . . . . . . . . . . . . . 65
4.7.2. Child Elements . . . . . . . . . . . . . . . . . . . 66
4.7.2.1. Show Element . . . . . . . . . . . . . . . . . . 66
4.7.2.2. Status Element . . . . . . . . . . . . . . . . . 67
4.7.2.3. Priority Element . . . . . . . . . . . . . . . . 68
4.7.3. Extended Content . . . . . . . . . . . . . . . . . . 69
3.2. Canceling a Subscription . . . . . . . . . . . . . . . . 40
3.2.1. Client Generation of Subscription Cancellation . . . 40
3.2.2. Server Processing of Outbound Subscription
Cancellation . . . . . . . . . . . . . . . . . . . . 40
3.2.3. Server Processing of Inbound Subscription
Cancellation . . . . . . . . . . . . . . . . . . . . 41
3.3. Unsubscribing . . . . . . . . . . . . . . . . . . . . . . 43
3.3.1. Client Generation of Unsubscribe . . . . . . . . . . 43
3.3.2. Server Processing of Outbound Unsubscribe . . . . . . 43
3.3.3. Server Processing of Inbound Unsubscribe . . . . . . 44
3.4. Pre-Approving a Subscription Request . . . . . . . . . . 46
3.4.1. Client Generation of Subscription Pre-Approval . . . 46
3.4.2. Server Processing of Subscription Pre-Approval . . . 47
4. Exchanging Presence Information . . . . . . . . . . . . . . . 48
4.1. Presence Fundamentals . . . . . . . . . . . . . . . . . . 48
4.2. Initial Presence . . . . . . . . . . . . . . . . . . . . 49
4.2.1. Client Generation of Initial Presence . . . . . . . . 49
4.2.2. Server Processing of Outbound Initial Presence . . . 50
4.2.3. Server Processing of Inbound Initial Presence . . . . 50
4.2.4. Client Processing of Initial Presence . . . . . . . . 51
4.3. Presence Probes . . . . . . . . . . . . . . . . . . . . . 51
4.3.1. Server Generation of Outbound Presence Probe . . . . 52
4.3.2. Server Processing of Inbound Presence Probe . . . . . 53
4.3.2.1. Handling of the 'id' Attribute . . . . . . . . . 55
4.4. Subsequent Presence Broadcast . . . . . . . . . . . . . . 57
4.4.1. Client Generation of Subsequent Presence Broadcast . 57
4.4.2. Server Processing of Subsequent Outbound Presence . . 57
4.4.3. Server Processing of Subsequent Inbound Presence . . 58
4.4.4. Client Processing of Subsequent Presence . . . . . . 59
4.5. Unavailable Presence . . . . . . . . . . . . . . . . . . 59
4.5.1. Client Generation of Unavailable Presence . . . . . . 59
4.5.2. Server Processing of Outbound Unavailable Presence . 59
4.5.3. Server Processing of Inbound Unavailable Presence . . 61
4.5.4. Client Processing of Unavailable Presence . . . . . . 62
4.6. Directed Presence . . . . . . . . . . . . . . . . . . . . 62
4.6.1. General Considerations . . . . . . . . . . . . . . . 62
4.6.2. Client Generation of Directed Presence . . . . . . . 63
4.6.3. Server Processing of Outbound Directed Presence . . . 63
4.6.4. Server Processing of Inbound Directed Presence . . . 64
4.6.5. Client Processing of Inbound Directed Presence . . . 64
4.6.6. Server Processing of Presence Probes . . . . . . . . 64
4.7. Presence Syntax . . . . . . . . . . . . . . . . . . . . . 65
4.7.1. Type Attribute . . . . . . . . . . . . . . . . . . . 65
4.7.2. Child Elements . . . . . . . . . . . . . . . . . . . 66
4.7.2.1. Show Element . . . . . . . . . . . . . . . . . . 66
4.7.2.2. Status Element . . . . . . . . . . . . . . . . . 67
4.7.2.3. Priority Element . . . . . . . . . . . . . . . . 68
4.7.3. Extended Content . . . . . . . . . . . . . . . . . . 69
5. Exchanging Messages . . . . . . . . . . . . . . . . . . . . . 69
5.1. One-to-One Chat Sessions . . . . . . . . . . . . . . . . 69
5.2. Message Syntax . . . . . . . . . . . . . . . . . . . . . 70
5.2.1. To Attribute . . . . . . . . . . . . . . . . . . . . 70
5.2.2. Type Attribute . . . . . . . . . . . . . . . . . . . 71
5.2.3. Body Element . . . . . . . . . . . . . . . . . . . . 73
5.2.4. Subject Element . . . . . . . . . . . . . . . . . . . 74
5.2.5. Thread Element . . . . . . . . . . . . . . . . . . . 75
5.3. Extended Content . . . . . . . . . . . . . . . . . . . . 77
6. Exchanging IQ Stanzas . . . . . . . . . . . . . . . . . . . . 77
7. A Sample Session . . . . . . . . . . . . . . . . . . . . . . 78
8. Server Rules for Processing XML Stanzas . . . . . . . . . . . 84
8.1. General Considerations . . . . . . . . . . . . . . . . . 85
8.2. No 'to' Address . . . . . . . . . . . . . . . . . . . . . 85
8.3. Remote Domain . . . . . . . . . . . . . . . . . . . . . . 85
8.4. Local Domain . . . . . . . . . . . . . . . . . . . . . . 86
8.5. Local User . . . . . . . . . . . . . . . . . . . . . . . 86
8.5.1. No Such User . . . . . . . . . . . . . . . . . . . . 86
8.5.2. localpart@domainpart . . . . . . . . . . . . . . . . 86
8.5.2.1. Available or Connected Resources . . . . . . . . 87
8.5.2.2. No Available or Connected Resources . . . . . . . 89
8.5.3. localpart@domainpart/resourcepart . . . . . . . . . . 90
8.5.3.1. Resource Matches . . . . . . . . . . . . . . . . 90
8.5.3.2. No Resource Matches . . . . . . . . . . . . . . . 90
8.5.4. Summary of Message Delivery Rules . . . . . . . . . . 92
9. Handling of URIs . . . . . . . . . . . . . . . . . . . . . . 93
10. Internationalization Considerations . . . . . . . . . . . . . 94
11. Security Considerations . . . . . . . . . . . . . . . . . . . 94
12. Conformance Requirements . . . . . . . . . . . . . . . . . . 95
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 99
13.1. Normative References . . . . . . . . . . . . . . . . . . 99
13.2. Informative References . . . . . . . . . . . . . . . . . 99
Appendix A. Subscription States . . . . . . . . . . . . . . . . 103
A.1. Defined States . . . . . . . . . . . . . . . . . . . . . 103
A.2. Server Processing of Outbound Presence Subscription
Stanzas . . . . . . . . . . . . . . . . . . . . . . . . . 104
A.2.1. Subscribe . . . . . . . . . . . . . . . . . . . . . . 105
A.2.2. Unsubscribe . . . . . . . . . . . . . . . . . . . . . 105
A.2.3. Subscribed . . . . . . . . . . . . . . . . . . . . . 106
A.2.4. Unsubscribed . . . . . . . . . . . . . . . . . . . . 106
A.3. Server Processing of Inbound Presence Subscription
Stanzas . . . . . . . . . . . . . . . . . . . . . . . . . 106
A.3.1. Subscribe . . . . . . . . . . . . . . . . . . . . . . 107
A.3.2. Unsubscribe . . . . . . . . . . . . . . . . . . . . . 107
A.3.3. Subscribed . . . . . . . . . . . . . . . . . . . . . 108
A.3.4. Unsubscribed . . . . . . . . . . . . . . . . . . . . 109
Appendix B. Blocking Communication . . . . . . . . . . . . . . . 110
Appendix C. vCards . . . . . . . . . . . . . . . . . . . . . . . 110
5. Exchanging Messages . . . . . . . . . . . . . . . . . . . . . 69
5.1. One-to-One Chat Sessions . . . . . . . . . . . . . . . . 69
5.2. Message Syntax . . . . . . . . . . . . . . . . . . . . . 70
5.2.1. To Attribute . . . . . . . . . . . . . . . . . . . . 70
5.2.2. Type Attribute . . . . . . . . . . . . . . . . . . . 71
5.2.3. Body Element . . . . . . . . . . . . . . . . . . . . 73
5.2.4. Subject Element . . . . . . . . . . . . . . . . . . . 74
5.2.5. Thread Element . . . . . . . . . . . . . . . . . . . 75
5.3. Extended Content . . . . . . . . . . . . . . . . . . . . 77
6. Exchanging IQ Stanzas . . . . . . . . . . . . . . . . . . . . 77
7. A Sample Session . . . . . . . . . . . . . . . . . . . . . . 78
8. Server Rules for Processing XML Stanzas . . . . . . . . . . . 84
8.1. General Considerations . . . . . . . . . . . . . . . . . 85
8.2. No 'to' Address . . . . . . . . . . . . . . . . . . . . . 85
8.3. Remote Domain . . . . . . . . . . . . . . . . . . . . . . 85
8.4. Local Domain . . . . . . . . . . . . . . . . . . . . . . 86
8.5. Local User . . . . . . . . . . . . . . . . . . . . . . . 86
8.5.1. No Such User . . . . . . . . . . . . . . . . . . . . 86
8.5.2. localpart@domainpart . . . . . . . . . . . . . . . . 86
8.5.2.1. Available or Connected Resources . . . . . . . . 87
8.5.2.2. No Available or Connected Resources . . . . . . . 89
8.5.3. localpart@domainpart/resourcepart . . . . . . . . . . 90
8.5.3.1. Resource Matches . . . . . . . . . . . . . . . . 90
8.5.3.2. No Resource Matches . . . . . . . . . . . . . . . 90
8.5.4. Summary of Message Delivery Rules . . . . . . . . . . 92
9. Handling of URIs . . . . . . . . . . . . . . . . . . . . . . 93
10. Internationalization Considerations . . . . . . . . . . . . . 94
11. Security Considerations . . . . . . . . . . . . . . . . . . . 94
12. Conformance Requirements . . . . . . . . . . . . . . . . . . 95
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 99
13.1. Normative References . . . . . . . . . . . . . . . . . . 99
13.2. Informative References . . . . . . . . . . . . . . . . . 99
Appendix A. Subscription States . . . . . . . . . . . . . . . . 103
A.1. Defined States . . . . . . . . . . . . . . . . . . . . . 103
A.2. Server Processing of Outbound Presence Subscription
Stanzas . . . . . . . . . . . . . . . . . . . . . . . . . 104
A.2.1. Subscribe . . . . . . . . . . . . . . . . . . . . . . 105
A.2.2. Unsubscribe . . . . . . . . . . . . . . . . . . . . . 105
A.2.3. Subscribed . . . . . . . . . . . . . . . . . . . . . 106
A.2.4. Unsubscribed . . . . . . . . . . . . . . . . . . . . 106
A.3. Server Processing of Inbound Presence Subscription
Stanzas . . . . . . . . . . . . . . . . . . . . . . . . . 106
A.3.1. Subscribe . . . . . . . . . . . . . . . . . . . . . . 107
A.3.2. Unsubscribe . . . . . . . . . . . . . . . . . . . . . 107
A.3.3. Subscribed . . . . . . . . . . . . . . . . . . . . . 108
A.3.4. Unsubscribed . . . . . . . . . . . . . . . . . . . . 109
Appendix B. Blocking Communication . . . . . . . . . . . . . . . 110
Appendix C. vCards . . . . . . . . . . . . . . . . . . . . . . . 110
Appendix D. XML Schema for jabber:iq:roster . . . . . . . . . . 110
Appendix E. Differences From RFC 3921 . . . . . . . . . . . . . 112
Appendix F. Acknowledgements . . . . . . . . . . . . . . . . . . 113
Appendix D. XML Schema for jabber:iq:roster . . . . . . . . . . 110
Appendix E. Differences From RFC 3921 . . . . . . . . . . . . . 112
Appendix F. Acknowledgements . . . . . . . . . . . . . . . . . . 113
The Extensible Messaging and Presence Protocol (XMPP) is an application profile of the Extensible Markup Language [XML] that enables the near-real-time exchange of structured yet extensible data between any two or more network entities. The core features of XMPP defined in [XMPP-CORE] provide the building blocks for many types of near-real-time applications, which can be layered on top of the core by sending application-specific data qualified by particular XML namespaces (refer to [XML-NAMES]). This document defines XMPP extensions that provide the basic functionality expected of an instant messaging (IM) and presence application as described in [IMP-REQS].
可扩展消息和状态协议（XMPP）是可扩展标记语言[XML]的应用程序配置文件，它支持在任意两个或多个网络实体之间近实时地交换结构化但可扩展的数据。[XMPP-core]中定义的XMPP的核心功能为许多类型的近实时应用程序提供了构建块，这些应用程序可以通过发送特定XML名称空间限定的特定于应用程序的数据（参考[XML-NAMES]）在核心之上分层。本文档定义了XMPP扩展，这些扩展提供了[IMP-REQS]中所述的即时消息（IM）和状态应用程序的基本功能。
The basic syntax and semantics of XMPP were developed originally within the Jabber open-source community, mainly in 1999. In late 2002, the XMPP Working Group was chartered with developing an adaptation of the core Jabber protocol that would be suitable as an IETF IM and presence technology in accordance with [IMP-REQS]. In October 2004, [RFC3920] and [RFC3921] were published, representing the most complete definition of XMPP at that time.
XMPP的基本语法和语义最初是在Jabber开源社区内开发的，主要是在1999年。2002年末，XMPP工作组获得特许，根据[IMP-REQS]的规定，开发适用于IETF IM和存在技术的核心Jabber协议的改编。2004年10月，发布了[RFC3920]和[RFC3921]，代表了当时最完整的XMPP定义。
Since 2004 the Internet community has gained extensive implementation and deployment experience with XMPP, including formal interoperability testing carried out under the auspices of the XMPP Standards Foundation (XSF). This document incorporates comprehensive feedback from software developers and service providers, including a number of backward-compatible modifications summarized under Appendix E. As a result, this document reflects the rough consensus of the Internet community regarding the IM and presence features of XMPP 1.0, thus obsoleting RFC 3921.
自2004以来，互联网社区已经获得了广泛的XMPP实现和部署经验，包括在XMPP标准基金会（XSF）主持下进行的正式互操作性测试。本文件综合了软件开发人员和服务提供商的综合反馈，包括附录E中总结的一些向后兼容的修改。因此，本文件反映了互联网社区对XMPP 1.0的IM和状态特性的大致共识，从而淘汰了RFC 3921。
Traditionally, IM applications have combined the following factors:
传统上，IM应用程序结合了以下因素：
1. The central point of focus is a list of one's contacts or "buddies" (in XMPP this list is called a "roster").
1. 焦点的中心点是一个人的联系人或“好友”列表（在XMPP中，这个列表被称为“名册”）。
2. The purpose of using such an application is to exchange relatively brief text messages with particular contacts in close to real time -- often relatively large numbers of such messages in rapid succession, in the form of a one-to-one "chat session" as described under Section 5.1.
2. 使用此类应用程序的目的是与特定联系人近实时地交换相对简短的文本消息——通常以一对一“聊天会话”的形式快速连续地交换相对大量的此类消息，如第5.1节所述。
3. The catalyst for exchanging messages is "presence" -- i.e., information about the network availability of particular contacts (thus knowing who is online and available for a one-to-one chat session).
3. 交换消息的催化剂是“存在”——即关于特定联系人的网络可用性的信息（从而知道谁在线并且可以进行一对一的聊天会话）。
4. Presence information is provided only to contacts that one has authorized by means of an explicit agreement called a "presence subscription".
4. 状态信息仅提供给通过称为“状态订阅”的明确协议授权的联系人。
Thus at a high level this document assumes that a user needs to be able to complete the following use cases:
因此，在较高的层次上，本文档假设用户需要能够完成以下用例：
o Manage items in one's contact list
o 管理联系人列表中的项目
o Exchange messages with one's contacts
o 与联系人交换信息
o Exchange presence information with one's contacts
o 与联系人交换状态信息
o Manage presence subscriptions to and from one's contacts
o 管理联系人的状态订阅和来自联系人的状态订阅
Detailed definitions of these functionality areas are contained in RFC 2779 [IMP-REQS], and the interested reader is referred to that document regarding in-depth requirements. Although the XMPP IM and presence extensions specified herein meet the requirements of RFC 2779, they were 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. Although XMPP protocol extensions addressing many other functionality areas have been defined in the XMPP Standards Foundation's XEP series (e.g., multi-user text chat as specified in [XEP-0045]), such extensions are not specified in this document because they are not mandated by RFC 2779.
RFC 2779[IMP-REQS]中包含了这些功能领域的详细定义，感兴趣的读者可参考该文件中关于深入需求的内容。尽管本文指定的XMPP IM和状态扩展满足RFC 2779的要求，但它们的设计并未明确考虑到该规范，因为在编写RFC 2779之前，基本协议是通过Jabber开源社区内的开放开发过程演变而来的。尽管XMPP标准基金会的XEP系列（如[XEP-0045]中规定的多用户文本聊天）中已定义了解决许多其他功能领域的XMPP协议扩展，但本文档中未规定此类扩展，因为RFC 2779未强制要求它们。
Implementation Note: RFC 2779 stipulates that presence services must be separable from IM services and vice-versa; i.e., it must be possible to use the protocol to provide a presence service, a messaging service, or both. Although the text of this document assumes that implementations and deployments will want to offer a unified IM and presence service, it is not mandatory for an XMPP service to offer both a presence service and a messaging service, and the protocol makes it possible to offer separate and distinct
实施说明：RFC2779规定状态服务必须与IM服务分开，反之亦然；i、 例如，必须能够使用该协议来提供状态服务、消息传递服务或两者。尽管本文档的文本假定实现和部署将希望提供统一的IM和状态服务，但XMPP服务并非必须同时提供状态服务和消息传递服务，并且该协议允许提供单独和不同的服务
services for presence and for messaging. (For example, a presence-only service could return a <service-unavailable/> stanza error if a client attempts to send a <message/> stanza.)
状态和消息服务。（例如，如果客户端尝试发送<message/>节，仅状态信息服务可能会返回<service unavailable/>节错误。）
This non-normative section provides a developer-friendly, functional summary of XMPP-based IM and presence features; consult the sections that follow for a normative definition of these features.
此非规范性部分提供了基于XMPP的IM和状态特性的开发人员友好的功能总结；有关这些特征的规范性定义，请参阅以下章节。
[XMPP-CORE] specifies how an XMPP client connects to an XMPP server. In particular, it specifies the preconditions that need to be fulfilled before a client is allowed to send XML stanzas (the basic unit of meaning in XMPP) to other entities on an XMPP network. These preconditions comprise negotiation of the XML stream and include exchange of XML stream headers, optional channel encryption via Transport Layer Security [TLS], mandatory authentication via Simple Authentication and Security Layer [SASL], and binding of a resource to the stream for client addressing. The reader is referred to [XMPP-CORE] for details regarding these preconditions, and knowledge of [XMPP-CORE] is assumed herein.
[XMPP-CORE]指定XMPP客户端如何连接到XMPP服务器。特别是，它指定了在允许客户端向XMPP网络上的其他实体发送XML节（XMPP中的基本意义单位）之前需要满足的先决条件。这些先决条件包括XML流的协商，包括交换XML流头、通过传输层安全[TLS]的可选通道加密、通过简单身份验证和安全层[SASL]的强制身份验证，以及将资源绑定到流以进行客户端寻址。读者可参考[XMPP-CORE]了解有关这些前提条件的详细信息，本文假设读者了解[XMPP-CORE]。
Interoperability Note: [RFC3921] specified one additional precondition: formal establishment of an instant messaging and presence session. Implementation and deployment experience has shown that this additional step is unnecessary. However, for backward compatibility an implementation MAY still offer that feature. This enables older software to connect while letting newer software save a round trip.
互操作性说明：[RFC3921]指定了另一个先决条件：正式建立即时消息和状态会话。实施和部署经验表明，这一额外步骤是不必要的。然而，为了向后兼容，一个实现仍然可以提供该特性。这使较旧的软件能够连接，同时让较新的软件节省往返时间。
Upon fulfillment of the preconditions specified in [XMPP-CORE], an XMPP client has a long-lived XML stream with an XMPP server, which enables the user controlling that client to send and receive a potentially unlimited number of XML stanzas over the stream. Such a stream can be used to exchange messages, share presence information, and engage in structured request-response interactions in close to real time. After negotiation of the XML stream, the typical flow for an instant messaging and presence session is as follows:
在满足[XMPP-CORE]中指定的前提条件后，XMPP客户机拥有一个具有XMPP服务器的长寿命XML流，这使得控制该客户机的用户能够通过该流发送和接收可能无限数量的XML节。这样的流可以用来交换消息、共享状态信息，并近乎实时地参与结构化的请求-响应交互。协商XML流后，即时消息和状态会话的典型流程如下所示：
1. Retrieve one's roster. (See Section 2.2.)
1. 取回某人的名册。（见第2.2节。）
2. Send initial presence to the server for broadcast to all subscribed contacts, thus "going online" from the perspective of XMPP communication. (See Section 4.2.)
2. 将初始状态发送到服务器，以便向所有订阅的联系人广播，从而从XMPP通信的角度“联机”。（见第4.2节。）
3. Exchange messages, manage presence subscriptions, perform roster updates, and in general process and generate other XML stanzas with particular semantics throughout the life of the session. (See Sections 5, 3, 2, and 6.)
3. 在会话的整个生命周期中，交换消息、管理状态订阅、执行花名册更新，以及在一般过程中生成具有特定语义的其他XML节。（见第5、3、2和6节。）
4. Terminate the session when desired by sending unavailable presence and closing the underlying XML stream. (See Section 4.5.)
4. 通过发送不可用状态并关闭底层XML流，在需要时终止会话。（见第4.5节。）
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [KEYWORDS].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不得”、“应”、“不应”、“建议”、“不建议”、“可”和“可选”应按照RFC 2119[关键词]中的描述进行解释。
This document inherits the terminology defined in [XMPP-CORE].
本文档继承了[XMPP-CORE]中定义的术语。
The terms "automated client" and "interactive client" are to be understood in the sense defined in [TLS-CERTS].
术语“自动客户端”和“交互式客户端”应理解为[TLS-CERTS]中定义的含义。
For convenience, this document employs the term "user" to refer to the owner of an XMPP account; however, account owners need not be humans and can be bots, devices, or other automated applications.
为方便起见，本文档使用术语“用户”来指XMPP帐户的所有者；但是，帐户所有者不必是人类，可以是机器人、设备或其他自动化应用程序。
Several other terms, such as "interested resource", are defined within the body of this document.
本文件正文中定义了其他几个术语，如“感兴趣的资源”。
Following the "XML Notation" used in [IRI] to represent characters
that cannot be rendered in ASCII-only documents, some examples in
this document use the form "&#x...." as a notational device to
represent [UNICODE] characters (e.g., the string "ř" stands
for the Unicode character LATIN SMALL LETTER R WITH CARON); this form
is definitely not to be sent over the wire in XMPP systems.
Following the "XML Notation" used in [IRI] to represent characters
that cannot be rendered in ASCII-only documents, some examples in
this document use the form "&#x...." as a notational device to
represent [UNICODE] characters (e.g., the string "ř" stands
for the Unicode character LATIN SMALL LETTER R WITH CARON); this form
is definitely not to be sent over the wire in XMPP systems.
In examples, lines have been wrapped for improved readability, "[...]" means elision, and the following prepended strings are used (these prepended strings are not to be sent over the wire):
在示例中，为了提高可读性，对行进行了包装，“[…]”表示省略，并使用了以下带前缀的字符串（这些带前缀的字符串不通过导线发送）：
o C: = client
o C:=客户
o CC: = contact's client
o CC:=联系人的客户
o CS: = contact's server
o CS:=联系人的服务器
o S: = server
o S:=服务器
o UC: = user's client
o UC:=用户的客户端
o US: = user's server
o US:=用户的服务器
Readers need to be aware that the examples are not exhaustive and that, in examples for some protocol flows, the alternate steps shown would not necessarily be triggered by the exact data sent in the previous step; in all cases, the protocol definitions specified in this document or in normatively referenced documents rule over any examples provided here. All examples are fictional and the information exchanged (e.g., usernames and passwords) does not represent any existing users or servers.
读者需要意识到，示例并非详尽无遗，并且在一些协议流的示例中，所示的备选步骤不一定由在前一步骤中发送的确切数据触发；在所有情况下，本文件或规范性引用文件中规定的协议定义均优于此处提供的任何示例。所有示例都是虚构的，所交换的信息（例如用户名和密码）并不代表任何现有用户或服务器。
In XMPP, a user's roster contains any number of specific contacts. A user's roster is stored by the user's server on the user's behalf so that the user can access roster information from any device. When the user adds items to the roster or modifies existing items, if an error does not occur then the server SHOULD store that data unmodified if at all possible and MUST return the data it has stored when an authorized client requests the roster.
在XMPP中，用户的花名册包含任意数量的特定联系人。用户的花名册由用户服务器代表用户存储，以便用户可以从任何设备访问花名册信息。当用户向花名册添加项目或修改现有项目时，如果未发生错误，则服务器应尽可能存储未修改的数据，并且必须在授权客户端请求花名册时返回其存储的数据。
Security Warning: Because the user's roster can contain confidential data, the server MUST restrict access to this data so that only authorized entities (typically limited to the account owner) are able to retrieve, modify, or delete it.
安全警告：由于用户的名册可能包含机密数据，服务器必须限制对该数据的访问，以便只有授权实体（通常限于帐户所有者）能够检索、修改或删除该数据。
RFC 3921 assumed that the only place where a user stores their roster is the server where the user's account is registered and at which the user authenticates for access to the XMPP network. This specification removes that strict coupling of roster storage to account registration and network authentication, with the result that a user could store their roster at another location, or could have multiple rosters that are stored in multiple locations. However, in the absence of implementation and deployment experience with a more flexible roster storage model, this specification retains the terminology of RFC 3921 by using the terms "client" and "server" (and "the roster" instead of "a roster"), rather than coining a new term for "a place where a user stores a roster". Future documents might provide normative rules for non-server roster storage or for the management of multiple rosters, but such rules are out of scope for this document.
RFC 3921假设用户存储其名册的唯一位置是注册用户帐户的服务器，并且用户在该服务器上验证访问XMPP网络的权限。本规范消除了名册存储与帐户注册和网络身份验证之间的严格耦合，从而用户可以将名册存储在另一个位置，也可以将多个名册存储在多个位置。然而，在缺乏更灵活的花名册存储模型的实施和部署经验的情况下，本规范保留了RFC 3921的术语，使用术语“客户机”和“服务器”（以及“花名册”而不是“花名册”），而不是为“用户存储花名册的地方”创造新术语。未来的文件可能会为非服务器名册存储或多个名册的管理提供规范性规则，但这些规则不在本文件的范围之内。
Rosters are managed using <iq/> stanzas (see Section 8.2.3 of [XMPP-CORE]), specifically by means of a <query/> child element qualified by the 'jabber:iq:roster' namespace. The detailed syntax and semantics are defined in the following sections.
名册使用<iq/>节（见[XMPP-CORE]第8.2.3节）进行管理，特别是通过由“jabber:iq:名册”命名空间限定的<query/>子元素进行管理。详细的语法和语义将在以下部分中定义。
The 'ver' attribute is a string that identifies a particular version of the roster information. The value MUST be generated only by the server and MUST be treated by the client as opaque. The server can use any appropriate method for generating the version ID, such as a hash of the roster data or a strictly increasing sequence number.
“ver”属性是一个字符串，用于标识名册信息的特定版本。该值必须仅由服务器生成，并且必须由客户端视为不透明。服务器可以使用任何适当的方法来生成版本ID，例如花名册数据的散列或严格递增的序列号。
Inclusion of the 'ver' attribute is RECOMMENDED.
建议包含“ver”属性。
Use of the 'ver' attribute is described more fully under Section 2.6.
“ver”属性的使用在第2.6节中有更全面的描述。
Interoperability Note: The 'ver' attribute of the <query/> element was not defined in RFC 3921 and is newly defined in this specification.
互操作性说明：<query/>元素的“ver”属性未在RFC 3921中定义，而是在本规范中新定义的。
The <query/> element inside a roster set (Section 2.1.5) contains one <item/> child, and a roster result (Section 2.1.4) typically contains multiple <item/> children. Each <item/> element describes a unique "roster item" (sometimes also called a "contact").
花名册集中的<query/>元素（第2.1.5节）包含一个子<item/>，花名册结果（第2.1.4节）通常包含多个子<item/>。每个<item/>元素描述一个独特的“花名册项目”（有时也称为“联系人”）。
The syntax of the <item/> element is described in the following sections.
<item/>元素的语法将在以下部分中描述。
The boolean 'approved' attribute with a value of "true" is used to signal subscription pre-approval as described under Section 3.4 (the default is "false", in accordance with [XML-DATATYPES]).
值为“true”的布尔“approved”属性用于表示订阅预批准，如第3.4节所述（根据[XML-DATATYPES]，默认值为“false”）。
A server SHOULD include the 'approved' attribute to inform the client of subscription pre-approvals. A client MUST NOT include the 'approved' attribute in the roster sets it sends to the server, but instead MUST use presence stanzas of type "subscribed" and "unsubscribed" to manage pre-approvals as described under Section 3.4.
服务器应包含“已批准”属性，以通知客户端订阅预批准。客户机不得将“已批准”属性包含在发送给服务器的花名册集中，而是必须使用“已订阅”和“未订阅”类型的状态节来管理第3.4节所述的预批准。
Interoperability Note: The 'approved' attribute of the <item/> element was not defined in RFC 3921 and is newly defined in this specification.
互操作性说明：<item/>元素的“approved”属性未在RFC 3921中定义，而是在本规范中新定义的。
The 'ask' attribute of the <item/> element with a value of "subscribe" is used to signal various subscription sub-states that include a "Pending Out" aspect as described under Section 3.1.2.
值为“subscribe”的<item/>元素的“ask”属性用于表示各种订阅子状态，包括第3.1.2节所述的“待定”方面。
A server SHOULD include the 'ask' attribute to inform the client of "Pending Out" sub-states. A client MUST NOT include the 'ask' attribute in the roster sets it sends to the server, but instead MUST use presence stanzas of type "subscribe" and "unsubscribe" to manage such sub-states as described under Section 3.1.2.
服务器应包含“ask”属性，以通知客户端“挂起”子状态。客户机不得将“ask”属性包含在发送给服务器的花名册集合中，而是必须使用“订阅”和“取消订阅”类型的状态节来管理第3.1.2节所述的子状态。
The 'jid' attribute of the <item/> element specifies the Jabber Identifier (JID) that uniquely identifies the roster item.
<item/>元素的'jid'属性指定唯一标识花名册项目的Jabber标识符（jid）。
The 'jid' attribute is REQUIRED whenever a client or server adds, updates, deletes, or returns a roster item.
每当客户端或服务器添加、更新、删除或返回花名册项目时，都需要“jid”属性。
The 'name' attribute of the <item/> element specifies the "handle" to be associated with the JID, as determined by the user (not the contact). Although the value of the 'name' attribute MAY have meaning to a human user, it is opaque to the server. However, the 'name' attribute MAY be used by the server for matching purposes within the context of various XMPP extensions (one possible comparison method is that described for XMPP resourceparts in [XMPP-ADDR]).
<item/>元素的“name”属性指定由用户（而不是联系人）确定的与JID关联的“句柄”。虽然“name”属性的值可能对用户有意义，但对服务器来说是不透明的。但是，服务器可以在各种XMPP扩展的上下文中使用“name”属性进行匹配（一种可能的比较方法是[XMPP-ADDR]中针对XMPP resourceparts描述的方法）。
It is OPTIONAL for a client to include the 'name' attribute when adding or updating a roster item.
在添加或更新花名册项目时，客户端可以选择包含“name”属性。
The state of the presence subscription is captured in the 'subscription' attribute of the <item/> element. The defined subscription-related values are:
状态订阅的状态在<item/>元素的“subscription”属性中捕获。定义的订阅相关值包括：
none: the user does not have a subscription to the contact's presence, and the contact does not have a subscription to the user's presence; this is the default value, so if the subscription attribute is not included then the state is to be understood as "none"
无：用户没有订阅联系人的状态，并且联系人没有订阅用户的状态；这是默认值，因此如果未包含订阅属性，则状态应理解为“无”
to: the user has a subscription to the contact's presence, but the contact does not have a subscription to the user's presence
收件人：用户订阅了联系人的状态，但联系人没有订阅用户的状态
from: the contact has a subscription to the user's presence, but the user does not have a subscription to the contact's presence
发件人：联系人订阅了用户的状态，但用户没有订阅联系人的状态
both: the user and the contact have subscriptions to each other's presence (also called a "mutual subscription")
两者：用户和联系人都订阅对方的状态（也称为“相互订阅”）
In a roster result (Section 2.1.4), the client MUST ignore values of the 'subscription' attribute other than "none", "to", "from", or "both".
在名册结果（第2.1.4节）中，客户必须忽略除“无”、“至”、“自”或“两者”之外的“订阅”属性值。
In a roster push (Section 2.1.6), the client MUST ignore values of the 'subscription' attribute other than "none", "to", "from", "both", or "remove".
在花名册推送（第2.1.6节）中，客户必须忽略除“无”、“至”、“自”、“两者”或“删除”以外的“订阅”属性值。
In a roster set (Section 2.1.5), the 'subscription' attribute MAY be included with a value of "remove", which indicates that the item is to be removed from the roster; in a roster set the server MUST ignore all values of the 'subscription' attribute other than "remove".
在花名册集中（第2.1.5节），“订阅”属性可能包含一个“删除”值，表示该项目将从花名册中删除；在花名册集中，服务器必须忽略除“删除”之外的“订阅”属性的所有值。
Inclusion of the 'subscription' attribute is OPTIONAL.
包含“订阅”属性是可选的。
The <group/> child element specifies a category or "bucket" into which the roster item is to be grouped by a client. An <item/> element MAY contain more than one <group/> element, which means that roster groups are not exclusive. Although the XML character data of the <group/> element MAY have meaning to a human user, it is opaque to the server. However, the <group/> element MAY be used by the server for matching purposes within the context of various XMPP extensions (one possible comparison method is that described for XMPP resourceparts in [XMPP-ADDR]).
<group/>子元素指定一个类别或“bucket”，客户机将花名册项目分组到该类别或“bucket”中。一个<item/>元素可能包含多个<group/>元素，这意味着名册组不是排他性的。尽管<group/>元素的XML字符数据可能对人类用户有意义，但对服务器来说是不透明的。但是，服务器可以在各种XMPP扩展的上下文中使用<group/>元素进行匹配（一种可能的比较方法是[XMPP-ADDR]中针对XMPP resourceparts描述的方法）。
It is OPTIONAL for a client to include the <group/> element when adding or updating a roster item. If a roster set (Section 2.1.5) includes no <group/> element, then the item is to be interpreted as being affiliated with no group.
在添加或更新花名册项目时，客户机可以选择包含<group/>元素。如果名册集（第2.1.5节）不包含<group/>元素，则该项目将被解释为不属于任何集团。
A "roster get" is a client's request for the server to return the roster; syntactically it is an IQ stanza of type "get" sent from client to server and containing a <query/> element qualified by the 'jabber:iq:roster' namespace, where the <query/> element MUST NOT contain any <item/> child elements.
“花名册获取”是客户端请求服务器返回花名册；从语法上讲，它是一个类型为“get”的IQ节，从客户端发送到服务器，包含一个由“jabber:IQ:lotster”命名空间限定的<query/>元素，其中<query/>元素不能包含任何<item/>子元素。
C: <iq from='juliet@example.com/balcony'
id='bv1bs71f'
type='get'>
<query xmlns='jabber:iq:roster'/>
</iq>
C: <iq from='juliet@example.com/balcony'
id='bv1bs71f'
type='get'>
<query xmlns='jabber:iq:roster'/>
</iq>
The expected outcome of sending a roster get is for the server to return a roster result.
发送花名册get的预期结果是服务器返回花名册结果。
A "roster result" is the server's response to a roster get; syntactically it is an IQ stanza of type "result" sent from server to client and containing a <query/> element qualified by the 'jabber:iq: roster' namespace.
“花名册结果”是服务器对花名册获取的响应；从语法上讲，它是一个类型为“result”的IQ节，从服务器发送到客户端，并包含一个由“jabber:IQ:花名册”命名空间限定的<query/>元素。
The <query/> element in a roster result contains one <item/> element for each contact and therefore can contain more than one <item/> element.
花名册结果中的<query/>元素为每个联系人包含一个<item/>元素，因此可以包含多个<item/>元素。
S: <iq id='bv1bs71f'
to='juliet@example.com/chamber'
type='result'>
<query xmlns='jabber:iq:roster' ver='ver7'>
<item jid='nurse@example.com'/>
<item jid='romeo@example.net'/>
</query>
</iq>
S: <iq id='bv1bs71f'
to='juliet@example.com/chamber'
type='result'>
<query xmlns='jabber:iq:roster' ver='ver7'>
<item jid='nurse@example.com'/>
<item jid='romeo@example.net'/>
</query>
</iq>
If the roster exists but there are no contacts in the roster, then the server MUST return an IQ-result containing a child <query/> element that in turn contains no <item/> children (i.e., the server MUST NOT return an empty <iq/> stanza of type "error").
如果花名册存在，但花名册中没有联系人，则服务器必须返回一个IQ结果，其中包含一个子<query/>元素，而该子元素又不包含<item/>子元素（即，服务器不得返回类型为“error”的空<IQ/>节）。
S: <iq id='bv1bs71f'
to='juliet@example.com/chamber'
type='result'>
<query xmlns='jabber:iq:roster' ver='ver9'/>
</iq>
S: <iq id='bv1bs71f'
to='juliet@example.com/chamber'
type='result'>
<query xmlns='jabber:iq:roster' ver='ver9'/>
</iq>
If the roster does not exist, then the server MUST return a stanza error with a condition of <item-not-found/>.
如果花名册不存在，则服务器必须返回一个节错误，条件为<item not found/>。
S: <iq id='bv1bs71f'
to='juliet@example.com/chamber'
type='error'>
<error type='cancel'>
<item-not-found
xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
</error>
</iq>
S: <iq id='bv1bs71f'
to='juliet@example.com/chamber'
type='error'>
<error type='cancel'>
<item-not-found
xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
</error>
</iq>
A "roster set" is a client's request for the server to modify (i.e., create, update, or delete) a roster item; syntactically it is an IQ stanza of type "set" sent from client to server and containing a <query/> element qualified by the 'jabber:iq:roster' namespace.
“花名册集”是客户请求服务器修改（即，创建、更新或删除）花名册项目；从语法上讲，它是一个类型为“set”的IQ节，从客户端发送到服务器，包含一个<query/>元素，由“jabber:IQ:花名册”名称空间限定。
The following rules apply to roster sets:
下列规则适用于名册集：
1. The <query/> element MUST contain one and only one <item/> element.
1. <query/>元素必须包含且仅包含一个<item/>元素。
2. The server MUST ignore any value of the 'subscription' attribute other than "remove" (see Section 2.1.2.5).
2. 服务器必须忽略除“删除”之外的“订阅”属性的任何值（参见第2.1.2.5节）。
Security Warning: Traditionally, the IQ stanza of the roster set included no 'to' address, with the result that all roster sets were sent from an authenticated resource (full JID) of the account whose roster was being updated. Furthermore, RFC 3921 required a server to perform special-case checking of roster sets to ignore the 'to' address; however, this specification has removed that special-casing, which means that a roster set might include a 'to' address other than that of the sender. Therefore, the entity that processes a roster set MUST verify that the sender of the roster set is authorized to update the roster, and if not return a <forbidden/> error.
安全警告：传统上，花名册集的IQ节不包含“收件人”地址，因此所有花名册集都是从更新花名册的帐户的已验证资源（完整JID）发送的。此外，RFC3921要求服务器对名册集执行特殊情况检查，以忽略“收件人”地址；然而，本规范删除了这个特殊的外壳，这意味着花名册集可能包括一个“收件人”地址，而不是发件人的地址。因此，处理花名册集的实体必须验证花名册集的发送者是否有权更新花名册，如果没有，则返回<禁止/>错误。
C: <iq from='juliet@example.com/balcony'
id='rs1'
type='set'>
<query xmlns='jabber:iq:roster'>
<item jid='nurse@example.com'/>
</query>
</iq>
C: <iq from='juliet@example.com/balcony'
id='rs1'
type='set'>
<query xmlns='jabber:iq:roster'>
<item jid='nurse@example.com'/>
</query>
</iq>
A "roster push" is a newly created, updated, or deleted roster item that is sent from the server to the client; syntactically it is an IQ stanza of type "set" sent from server to client and containing a <query/> element qualified by the 'jabber:iq:roster' namespace.
“花名册推送”是从服务器发送到客户端的新创建、更新或删除的花名册项目；从语法上讲，它是一个类型为“set”的IQ节，从服务器发送到客户端，包含一个由“jabber:IQ:lotster”命名空间限定的<query/>元素。
The following rules apply to roster pushes:
以下规则适用于排班推送：
1. The <query/> element in a roster push MUST contain one and only one <item/> element.
1. 花名册推送中的<query/>元素必须包含且仅包含一个<item/>元素。
2. A receiving client MUST ignore the stanza unless it has no 'from' attribute (i.e., implicitly from the bare JID of the user's account) or it has a 'from' attribute whose value matches the user's bare JID <user@domainpart>.
2. 接收客户端必须忽略该节，除非它没有“from”属性（即隐式地来自用户帐户的裸JID），或者它有一个值与用户的裸JID匹配的“from”属性<user@domainpart>.
S: <iq id='a78b4q6ha463'
to='juliet@example.com/chamber'
type='set'>
<query xmlns='jabber:iq:roster'>
<item jid='nurse@example.com'/>
</query>
</iq>
S: <iq id='a78b4q6ha463'
to='juliet@example.com/chamber'
type='set'>
<query xmlns='jabber:iq:roster'>
<item jid='nurse@example.com'/>
</query>
</iq>
As mandated by the semantics of the IQ stanza as defined in [XMPP-CORE], each resource that receives a roster push from the server is supposed to reply with an IQ stanza of type "result" or "error" (however, it is known that many existing clients do not reply to roster pushes).
根据[XMPP-CORE]中定义的IQ节语义的规定，从服务器接收花名册推送的每个资源都应该使用类型为“result”或“error”的IQ节进行回复（但是，众所周知，许多现有客户机不会回复花名册推送）。
C: <iq from='juliet@example.com/balcony'
id='a78b4q6ha463'
type='result'/>
C: <iq from='juliet@example.com/balcony'
id='a78b4q6ha463'
type='result'/>
C: <iq from='juliet@example.com/chamber'
id='a78b4q6ha463'
type='result'/>
C: <iq from='juliet@example.com/chamber'
id='a78b4q6ha463'
type='result'/>
Security Warning: Traditionally, a roster push included no 'from' address, with the result that all roster pushes were sent implicitly from the bare JID of the account itself. However, this specification allows entities other than the user's server to maintain roster information, which means that a roster push might include a 'from' address other than the bare JID of the user's account. Therefore, the client MUST check the 'from' address to verify that the sender of the roster push is authorized to update the roster. If the client receives a roster push from an unauthorized entity, it MUST NOT process the pushed data; in addition, the client can either return a stanza error of <service-unavailable/> error or refuse to return a stanza error at all (the latter behavior overrides a MUST-level requirement from [XMPP-CORE] for the purpose of preventing a presence leak).
安全警告：传统上，花名册推送不包括“发件人”地址，因此所有花名册推送都是从帐户本身的裸JID隐式发送的。但是，该规范允许用户服务器以外的实体维护花名册信息，这意味着花名册推送可能包括除用户帐户的裸JID之外的“发件人”地址。因此，客户必须检查“发件人”地址，以验证花名册推送的发件人有权更新花名册。如果客户收到来自未经授权实体的花名册推送，则不得处理推送的数据；此外，客户机可以返回节错误<service unavailable/>error，也可以拒绝返回节错误（为了防止存在泄漏，后一种行为会覆盖[XMPP-CORE]的必须级别要求）。
Implementation Note: There is no error case for client processing of roster pushes; if the server receives an IQ of type "error" in response to a roster push then it SHOULD ignore the error.
实施说明：客户处理花名册推送没有错误案例；如果服务器收到“error”类型的IQ以响应花名册推送，则应忽略该错误。
Upon authenticating with a server and binding a resource (thus becoming a connected resource as defined in [XMPP-CORE]), a client SHOULD request the roster before sending initial presence (however, because receiving the roster is not necessarily desirable for all resources, e.g., a connection with limited bandwidth, the client's request for the roster is not mandatory). After a connected resource sends initial presence (see Section 4.2), it is referred to as an "available resource". If a connected resource or available resource requests the roster, it is referred to as an "interested resource". The server MUST send roster pushes to all interested resources.
在与服务器进行身份验证并绑定资源（从而成为[XMPP-CORE]中定义的连接资源）后，客户机应在发送初始状态之前请求名册（但是，由于接收花名册并不一定是所有资源都需要的，例如，带宽有限的连接，因此客户端对花名册的请求不是强制性的）。在连接的资源发送初始状态（参见第4.2节）后，它被称为“可用资源”。如果连接的资源或可用资源请求花名册，则它被称为“感兴趣的资源”。服务器必须向所有感兴趣的资源发送花名册推送。
Implementation Note: Presence subscription requests are sent to available resources, whereas the roster pushes associated with subscription state changes are sent to interested resources. Therefore, if a resource wishes to receive both subscription requests and roster pushes, it MUST both send initial presence and request the roster.
实现说明：状态订阅请求被发送到可用资源，而与订阅状态更改相关联的花名册推送被发送到感兴趣的资源。因此，如果资源希望同时接收订阅请求和花名册推送，则它必须同时发送初始状态并请求花名册。
A client requests the roster by sending a roster get over its stream with the server.
客户机通过向服务器发送花名册来请求花名册。
C: <iq from='juliet@example.com/balcony'
id='hu2bac18'
type='get'>
<query xmlns='jabber:iq:roster'/>
</iq>
C: <iq from='juliet@example.com/balcony'
id='hu2bac18'
type='get'>
<query xmlns='jabber:iq:roster'/>
</iq>
S: <iq id='hu2bac18'
to='juliet@example.com/balcony'
type='result'>
<query xmlns='jabber:iq:roster' ver='ver11'>
<item jid='romeo@example.net'
name='Romeo'
subscription='both'>
<group>Friends</group>
</item>
<item jid='mercutio@example.com'
name='Mercutio'
subscription='from'/>
<item jid='benvolio@example.net'
name='Benvolio'
subscription='both'/>
</query>
</iq>
S: <iq id='hu2bac18'
to='juliet@example.com/balcony'
type='result'>
<query xmlns='jabber:iq:roster' ver='ver11'>
<item jid='romeo@example.net'
name='Romeo'
subscription='both'>
<group>Friends</group>
</item>
<item jid='mercutio@example.com'
name='Mercutio'
subscription='from'/>
<item jid='benvolio@example.net'
name='Benvolio'
subscription='both'/>
</query>
</iq>
If the server cannot process the roster get, it MUST return an appropriate stanza error as described in [XMPP-CORE] (such as <service-unavailable/> if the roster namespace is not supported or <internal-server-error/> if the server experiences trouble processing or returning the roster).
如果服务器无法处理花名册获取，则必须返回[XMPP-CORE]中所述的相应节错误（例如，如果花名册名称空间不受支持，则返回<service unavailable/>；如果服务器在处理或返回花名册时遇到问题，则返回<internal server error/>）。
At any time, a client can add an item to the roster. This is done by sending a roster set containing a new item.
客户可以随时将项目添加到花名册中。这是通过发送包含新项目的花名册集来完成的。
C: <iq from='juliet@example.com/balcony'
id='ph1xaz53'
type='set'>
<query xmlns='jabber:iq:roster'>
<item jid='nurse@example.com'
name='Nurse'>
<group>Servants</group>
</item>
</query>
</iq>
C: <iq from='juliet@example.com/balcony'
id='ph1xaz53'
type='set'>
<query xmlns='jabber:iq:roster'>
<item jid='nurse@example.com'
name='Nurse'>
<group>Servants</group>
</item>
</query>
</iq>
If the server can successfully process the roster set for the new item (i.e., if no error occurs), it MUST create the item in the user's roster and proceed as follows.
如果服务器能够成功地处理为新项目设置的花名册（即，如果没有发生错误），则必须在用户花名册中创建项目，并按照以下步骤进行操作。
The server MUST return an IQ stanza of type "result" to the connected resource that sent the roster set.
服务器必须向发送花名册集的连接资源返回“result”类型的IQ节。
S: <iq id='ph1xaz53'
to='juliet@example.com/balcony'
type='result'/>
S: <iq id='ph1xaz53'
to='juliet@example.com/balcony'
type='result'/>
The server MUST also send a roster push containing the new roster item to all of the user's interested resources, including the resource that generated the roster set.
服务器还必须向用户感兴趣的所有资源（包括生成花名册集的资源）发送包含新花名册项的花名册推送。
S: <iq to='juliet@example.com/balcony'
id='a78b4q6ha463'
type='set'>
<query xmlns='jabber:iq:roster' ver='ver13'>
<item jid='nurse@example.com'
name='Nurse'
subscription='none'>
<group>Servants</group>
</item>
</query>
</iq>
S: <iq to='juliet@example.com/balcony'
id='a78b4q6ha463'
type='set'>
<query xmlns='jabber:iq:roster' ver='ver13'>
<item jid='nurse@example.com'
name='Nurse'
subscription='none'>
<group>Servants</group>
</item>
</query>
</iq>
S: <iq to='juliet@example.com/chamber'
id='x81g3bdy4n19'
type='set'>
<query xmlns='jabber:iq:roster' ver='ver13'>
<item jid='nurse@example.com'
name='Nurse'
subscription='none'>
<group>Servants</group>
</item>
</query>
</iq>
S: <iq to='juliet@example.com/chamber'
id='x81g3bdy4n19'
type='set'>
<query xmlns='jabber:iq:roster' ver='ver13'>
<item jid='nurse@example.com'
name='Nurse'
subscription='none'>
<group>Servants</group>
</item>
</query>
</iq>
As mandated by the semantics of the IQ stanza as defined in [XMPP-CORE], each resource that receives a roster push from the server is supposed to reply with an IQ stanza of type "result" or "error" (however, it is known that many existing clients do not reply to roster pushes).
根据[XMPP-CORE]中定义的IQ节语义的规定，从服务器接收花名册推送的每个资源都应该使用类型为“result”或“error”的IQ节进行回复（但是，众所周知，许多现有客户机不会回复花名册推送）。
C: <iq from='juliet@example.com/balcony'
id='a78b4q6ha463'
type='result'/>
C: <iq from='juliet@example.com/balcony'
id='a78b4q6ha463'
type='result'/>
C: <iq from='juliet@example.com/chamber'
id='x81g3bdy4n19'
type='result'/>
C: <iq from='juliet@example.com/chamber'
id='x81g3bdy4n19'
type='result'/>
If the server cannot successfully process the roster set, it MUST return a stanza error. The following error cases are defined. Naturally, other stanza errors can occur, such as <internal-server-error/> if the server experiences an internal problem with processing the roster get, or even <not-allowed/> if the server only allows roster modifications by means of a non-XMPP method such as a web interface.
如果服务器无法成功处理花名册集，则必须返回节错误。定义了以下错误情况。当然，也会发生其他节错误，例如，如果服务器在处理花名册获取时遇到内部问题，则会出现<internal server error/>，如果服务器仅允许通过非XMPP方法（如web界面）修改花名册，则会出现<not allowed/>。
The server MUST return a <forbidden/> stanza error to the client if the sender of the roster set is not authorized to update the roster (where typically only an authenticated resource of the account itself is authorized).
如果花名册集的发送者没有被授权更新花名册（通常只有帐户本身的经过身份验证的资源被授权），服务器必须向客户端返回一个<banbidden/>节错误。
The server MUST return a <bad-request/> stanza error to the client if the roster set contains any of the following violations:
如果花名册集包含以下任何违规行为，服务器必须向客户端返回<bad request/>节错误：
1. The <query/> element contains more than one <item/> child element.
1. <query/>元素包含多个子元素。
2. The <item/> element contains more than one <group/> element, but there are duplicate groups (one possible comparison method for determining duplicates is that described for XMPP resourceparts in [XMPP-ADDR]).
2. <item/>元素包含多个<group/>元素，但存在重复的组（确定重复项的一种可能的比较方法是[XMPP-ADDR]中针对XMPP resourceparts所述的方法）。
The server MUST return a <not-acceptable/> stanza error to the client if the roster set contains any of the following violations:
如果花名册集包含以下任何违规行为，服务器必须向客户端返回<not acceptable/>节错误：
1. The length of the 'name' attribute is greater than a server-configured limit.
1. “name”属性的长度大于服务器配置的限制。
2. The XML character data of the <group/> element is of zero length (to remove an item from all groups, the client instead needs to exclude any <group/> element from the roster set).
2. <group/>元素的XML字符数据长度为零（要从所有组中删除项目，客户端需要从花名册集中排除任何<group/>元素）。
3. The XML character data of the <group/> element is larger than a server-configured limit.
3. <group/>元素的XML字符数据大于服务器配置的限制。
Error: Roster set initiated by unauthorized entity
错误：名册集由未经授权的实体启动
C: <iq from='juliet@example.com/balcony'
id='ix7s53v2'
to='romeo@example.net'
type='set'>
<query xmlns='jabber:iq:roster'>
<item jid='nurse@example.com'/>
</query>
</iq>
C: <iq from='juliet@example.com/balcony'
id='ix7s53v2'
to='romeo@example.net'
type='set'>
<query xmlns='jabber:iq:roster'>
<item jid='nurse@example.com'/>
</query>
</iq>
S: <iq id='ix7s53v2'
to='juliet@example.com/balcony'
type='error'>
<error type='auth'>
<forbidden xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
</error>
</iq>
S: <iq id='ix7s53v2'
to='juliet@example.com/balcony'
type='error'>
<error type='auth'>
<forbidden xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
</error>
</iq>
Error: Roster set contains more than one item
错误：花名册集包含多个项目
C: <iq from='juliet@example.com/balcony'
id='nw83vcj4'
type='set'>
<query xmlns='jabber:iq:roster'>
<item jid='nurse@example.com'
name='Nurse'>
<group>Servants</group>
</item>
<item jid='mother@example.com'
name='Mom'>
<group>Family</group>
</item>
</query>
</iq>
C: <iq from='juliet@example.com/balcony'
id='nw83vcj4'
type='set'>
<query xmlns='jabber:iq:roster'>
<item jid='nurse@example.com'
name='Nurse'>
<group>Servants</group>
</item>
<item jid='mother@example.com'
name='Mom'>
<group>Family</group>
</item>
</query>
</iq>
S: <iq id='nw83vcj4'
to='juliet@example.com/balcony'
type='error'>
<error type='modify'>
<bad-request xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
</error>
</iq>
S: <iq id='nw83vcj4'
to='juliet@example.com/balcony'
type='error'>
<error type='modify'>
<bad-request xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
</error>
</iq>
Error: Roster set contains item with oversized handle
错误：花名册集包含句柄过大的项目
C: <iq from='juliet@example.com/balcony'
id='yl491b3d'
type='set'>
<query xmlns='jabber:iq:roster'>
<item jid='nurse@example.com'
name='[ ... some-very-long-handle ... ]'>
<group>Servants</group>
</item>
</query>
</iq>
C: <iq from='juliet@example.com/balcony'
id='yl491b3d'
type='set'>
<query xmlns='jabber:iq:roster'>
<item jid='nurse@example.com'
name='[ ... some-very-long-handle ... ]'>
<group>Servants</group>
</item>
</query>
</iq>
S: <iq id='yl491b3d'
to='juliet@example.com/balcony'
type='error'>
<error type='modify'>
<not-acceptable xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
</error>
</iq>
S: <iq id='yl491b3d'
to='juliet@example.com/balcony'
type='error'>
<error type='modify'>
<not-acceptable xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
</error>
</iq>
Error: Roster set contains duplicate groups
错误：花名册集包含重复的组
C: <iq from='juliet@example.com/balcony'
id='tk3va749'
type='set'>
<query xmlns='jabber:iq:roster'>
<item jid='nurse@example.com'
name='Nurse'>
<group>Servants</group>
<group>Servants</group>
</item>
</query>
</iq>
C: <iq from='juliet@example.com/balcony'
id='tk3va749'
type='set'>
<query xmlns='jabber:iq:roster'>
<item jid='nurse@example.com'
name='Nurse'>
<group>Servants</group>
<group>Servants</group>
</item>
</query>
</iq>
S: <iq id='tk3va749'
to='juliet@example.com/balcony'
type='error'>
<error type='modify'>
<bad-request xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
</error>
</iq>
S: <iq id='tk3va749'
to='juliet@example.com/balcony'
type='error'>
<error type='modify'>
<bad-request xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
</error>
</iq>
Error: Roster set contains empty group
错误：花名册集包含空组
C: <iq from='juliet@example.com/balcony'
id='fl3b486u'
type='set'>
<query xmlns='jabber:iq:roster'>
<item jid='nurse@example.com'
name='Nurse'>
<group></group>
</item>
</query>
</iq>
C: <iq from='juliet@example.com/balcony'
id='fl3b486u'
type='set'>
<query xmlns='jabber:iq:roster'>
<item jid='nurse@example.com'
name='Nurse'>
<group></group>
</item>
</query>
</iq>
S: <iq id='fl3b486u'
to='juliet@example.com/balcony'
type='error'>
<error type='modify'>
<not-acceptable xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
</error>
</iq>
S: <iq id='fl3b486u'
to='juliet@example.com/balcony'
type='error'>
<error type='modify'>
<not-acceptable xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
</error>
</iq>
Error: Roster set contains oversized group name
错误：花名册集包含过大的组名
C: <iq from='juliet@example.com/balcony'
id='qh3b4v19'
type='set'>
<query xmlns='jabber:iq:roster'>
<item jid='nurse@example.com'
name='Nurse'>
<group>[ ... some-very-long-group-name ... ]</group>
</item>
</query>
</iq>
C: <iq from='juliet@example.com/balcony'
id='qh3b4v19'
type='set'>
<query xmlns='jabber:iq:roster'>
<item jid='nurse@example.com'
name='Nurse'>
<group>[ ... some-very-long-group-name ... ]</group>
</item>
</query>
</iq>
S: <iq id='qh3b4v19'
to='juliet@example.com/balcony'
type='error'>
<error type='modify'>
<not-acceptable xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
</error>
</iq>
S: <iq id='qh3b4v19'
to='juliet@example.com/balcony'
type='error'>
<error type='modify'>
<not-acceptable xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
</error>
</iq>
Interoperability Note: Some servers return a <not-allowed/> stanza error to the client if the value of the <item/> element's 'jid' attribute matches the bare JID <localpart@domainpart> of the user's account.
互操作性说明：如果<item/>元素的“jid”属性的值与裸jid匹配，则某些服务器会向客户端返回一个<notallowed/>节错误<localpart@domainpart>用户帐户的名称。
Updating an existing roster item is done in the same way as adding a new roster item, i.e., by sending a roster set to the server. Because a roster item is atomic, the item MUST be updated exactly as provided in the roster set.
更新现有花名册项目的方式与添加新花名册项目的方式相同，即向服务器发送花名册集。因为花名册项目是原子的，所以必须完全按照花名册集中提供的内容更新该项目。
There are several reasons why a client might update a roster item:
客户可能会更新花名册项目的原因有几个：
1. Adding a group
1. 添加组
2. Deleting a group
2. 删除组
3. Changing the handle
3. 换把手
4. Deleting the handle
4. 删除句柄
Consider a roster item that is defined as follows:
考虑一个名册项目，定义如下：
<item jid='romeo@example.net'
name='Romeo'>
<group>Friends</group>
</item>
<item jid='romeo@example.net'
name='Romeo'>
<group>Friends</group>
</item>
The user who has this item in her roster might want to add the item to another group.
名册中有此项目的用户可能希望将该项目添加到其他组。
C: <iq from='juliet@example.com/balcony'
id='di43b2x9'
type='set'>
<query xmlns='jabber:iq:roster'>
<item jid='romeo@example.net'
name='Romeo'>
<group>Friends</group>
<group>Lovers</group>
</item>
</query>
</iq>
C: <iq from='juliet@example.com/balcony'
id='di43b2x9'
type='set'>
<query xmlns='jabber:iq:roster'>
<item jid='romeo@example.net'
name='Romeo'>
<group>Friends</group>
<group>Lovers</group>
</item>
</query>
</iq>
Sometime later, the user might want to remove the item from the original group.
稍后，用户可能希望从原始组中删除该项。
C: <iq from='juliet@example.com/balcony'
id='lf72v157'
type='set'>
<query xmlns='jabber:iq:roster'>
<item jid='romeo@example.net'
name='Romeo'>
<group>Lovers</group>
</item>
</query>
</iq>
C: <iq from='juliet@example.com/balcony'
id='lf72v157'
type='set'>
<query xmlns='jabber:iq:roster'>
<item jid='romeo@example.net'
name='Romeo'>
<group>Lovers</group>
</item>
</query>
</iq>
The user might want to remove the item from all groups.
用户可能希望从所有组中删除该项。
C: <iq from='juliet@example.com/balcony'
id='ju4b62a5'
type='set'>
<query xmlns='jabber:iq:roster'>
<item jid='romeo@example.net'/>
</query>
</iq>
C: <iq from='juliet@example.com/balcony'
id='ju4b62a5'
type='set'>
<query xmlns='jabber:iq:roster'>
<item jid='romeo@example.net'/>
</query>
</iq>
The user might also want to change the handle for the item.
用户可能还希望更改该项的句柄。
C: <iq from='juliet@example.com/balcony'
id='gb3sv487'
type='set'>
<query xmlns='jabber:iq:roster'>
<item jid='romeo@example.net'
name='MyRomeo'/>
</query>
</iq>
C: <iq from='juliet@example.com/balcony'
id='gb3sv487'
type='set'>
<query xmlns='jabber:iq:roster'>
<item jid='romeo@example.net'
name='MyRomeo'/>
</query>
</iq>
The user might then want to remove the handle altogether.
然后，用户可能希望完全移除句柄。
C: <iq from='juliet@example.com/balcony'
id='o3bx66s5'
type='set'>
<query xmlns='jabber:iq:roster'>
<item jid='romeo@example.net'
name=''/>
</query>
</iq>
C: <iq from='juliet@example.com/balcony'
id='o3bx66s5'
type='set'>
<query xmlns='jabber:iq:roster'>
<item jid='romeo@example.net'
name=''/>
</query>
</iq>
Implementation Note: Including an empty 'name' attribute is equivalent to including no 'name' attribute; both actions set the name to the empty string.
实现说明：包含空“name”属性等同于不包含“name”属性；这两个操作都将名称设置为空字符串。
As with adding a roster item, if the roster item can be successfully processed then the server MUST update the item in the user's roster, send a roster push to all of the user's interested resources, and send an IQ result to the initiating resource; details are provided under Section 2.3.
与添加花名册项目一样，如果花名册项目可以成功处理，则服务器必须更新用户花名册中的项目，向用户感兴趣的所有资源发送花名册推送，并向发起资源发送IQ结果；详情见第2.3节。
The error cases described under Section 2.3.3 also apply to updating a roster item.
第2.3.3节中描述的错误案例也适用于更新名册项目。
At any time, a client can delete an item from his or her roster by sending a roster set and specifying a value of "remove" for the 'subscription' attribute.
在任何时候，客户端都可以通过发送花名册集并为“订阅”属性指定“删除”值，从其花名册中删除项目。
C: <iq from='juliet@example.com/balcony'
id='hm4hs97y'
type='set'>
<query xmlns='jabber:iq:roster'>
<item jid='nurse@example.com'
subscription='remove'/>
</query>
</iq>
C: <iq from='juliet@example.com/balcony'
id='hm4hs97y'
type='set'>
<query xmlns='jabber:iq:roster'>
<item jid='nurse@example.com'
subscription='remove'/>
</query>
</iq>
As with adding a roster item, if the server can successfully process the roster set then it MUST update the item in the user's roster, send a roster push to all of the user's interested resources (with the 'subscription' attribute set to a value of "remove"), and send an IQ result to the initiating resource; details are provided under Section 2.3.
与添加花名册项目一样，如果服务器能够成功处理花名册集，则必须更新用户花名册中的项目，向用户感兴趣的所有资源发送花名册推送（将“订阅”属性设置为“删除”）并向发起资源发送IQ结果；详情见第2.3节。
In addition, the user's server might need to generate one or more subscription-related presence stanzas, as follows:
此外，用户的服务器可能需要生成一个或多个与订阅相关的状态节，如下所示：
1. If the user has a presence subscription to the contact, then the user's server MUST send a presence stanza of type "unsubscribe" to the contact (in order to unsubscribe from the contact's presence).
1. 如果用户对联系人有状态订阅，则用户服务器必须向联系人发送类型为“unsubscribe”的状态节（以便从联系人的状态中取消订阅）。
2. If the contact has a presence subscription to the user, then the user's server MUST send a presence stanza of type "unsubscribed" to the contact (in order to cancel the contact's subscription to the user).
2. 如果联系人对用户有状态订阅，则用户服务器必须向联系人发送类型为“unsubscribed”的状态节（以取消联系人对用户的订阅）。
3. If the presence subscription is mutual, then the user's server MUST send both a presence stanza of type "unsubscribe" and a presence stanza of type "unsubscribed" to the contact.
3. 如果状态订阅是相互的，则用户服务器必须向联系人发送类型为“unsubscribe”的状态节和类型为“unsubscribed”的状态节。
S: <presence from='juliet@example.com'
id='lm3ba81g'
to='nurse@example.com'
type='unsubscribe'/>
S: <presence from='juliet@example.com'
id='lm3ba81g'
to='nurse@example.com'
type='unsubscribe'/>
S: <presence from='juliet@example.com'
id='xb2c1v4k'
to='nurse@example.com'
type='unsubscribed'/>
S: <presence from='juliet@example.com'
id='xb2c1v4k'
to='nurse@example.com'
type='unsubscribed'/>
If the value of the 'jid' attribute specifies an item that is not in the roster, then the server MUST return an <item-not-found/> stanza error.
如果“jid”属性的值指定了不在花名册中的项目，则服务器必须返回<item not found/>节错误。
Error: Roster item not found
错误：找不到花名册项目
C: <iq from='juliet@example.com/balcony'
id='uj4b1ca8'
type='set'>
<query xmlns='jabber:iq:roster'>
<item jid='[ ... non-existent-jid ... ]'
subscription='remove'/>
</query>
</iq>
C: <iq from='juliet@example.com/balcony'
id='uj4b1ca8'
type='set'>
<query xmlns='jabber:iq:roster'>
<item jid='[ ... non-existent-jid ... ]'
subscription='remove'/>
</query>
</iq>
S: <iq id='uj4b1ca8'
to='juliet@example.com/balcony'
type='error'>
<error type='modify'>
<item-not-found
xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
</error>
</iq>
S: <iq id='uj4b1ca8'
to='juliet@example.com/balcony'
type='error'>
<error type='modify'>
<item-not-found
xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
</error>
</iq>
If a server supports roster versioning, then it MUST advertise the following stream feature during stream negotiation.
如果服务器支持花名册版本控制，那么它必须在流协商期间公布以下流功能。
<ver xmlns='urn:xmpp:features:rosterver'/>
<ver xmlns='urn:xmpp:features:rosterver'/>
The roster versioning stream feature is merely informative and therefore is never mandatory-to-negotiate.
花名册版本控制流功能只是提供信息，因此从来没有强制协商。
If a client supports roster versioning and the server to which it has connected advertises support for roster versioning as described in the foregoing section, then the client SHOULD include the 'ver' element in its request for the roster. If the server does not advertise support for roster versioning, the client MUST NOT include the 'ver' attribute. If the client includes the 'ver' attribute in its roster get, it sets the attribute's value to the version ID associated with its last cache of the roster.
如果客户机支持花名册版本控制，并且其所连接的服务器如前一节所述公布了对花名册版本控制的支持，则客户机应在其花名册请求中包含“ver”元素。如果服务器未公布对花名册版本控制的支持，则客户端不得包含“ver”属性。如果客户端在其花名册获取中包含“ver”属性，则会将该属性的值设置为与其花名册的最后一个缓存关联的版本ID。
C: <iq from='romeo@example.net/home'
id='r1h3vzp7'
to='romeo@example.net'
type='get'>
<query xmlns='jabber:iq:roster' ver='ver14'/>
</iq>
C: <iq from='romeo@example.net/home'
id='r1h3vzp7'
to='romeo@example.net'
type='get'>
<query xmlns='jabber:iq:roster' ver='ver14'/>
</iq>
If the client has not yet cached the roster or the cache is lost or corrupted, but the client wishes to bootstrap the use of roster versioning, it MUST set the 'ver' attribute to the empty string (i.e., ver="").
如果客户端尚未缓存花名册或缓存丢失或损坏，但客户端希望引导花名册版本控制的使用，则必须将“ver”属性设置为空字符串（即ver=“”）。
Naturally, if the client does not support roster versioning or does not wish to bootstrap the use of roster versioning, it will not include the 'ver' attribute.
当然，如果客户端不支持花名册版本控制或不希望引导花名册版本控制的使用，它将不包括“ver”属性。
Whether or not the roster has been modified since the version ID enumerated by the client, the server MUST either return the complete roster as described under Section 2.1.4 (including a 'ver' attribute that signals the latest version) or return an empty IQ-result (thus indicating that any roster modifications will be sent via roster pushes, as described below). In general, unless returning the complete roster would (1) use less bandwidth than sending individual roster pushes to the client (e.g., if the roster contains only a few items) or (2) the server cannot associate the version ID with any previous version it has on file, the server SHOULD send an empty IQ-result and then send the modifications (if any) via roster pushes.
无论客户机枚举版本ID后是否修改了花名册，服务器都必须返回第2.1.4节所述的完整花名册（包括表示最新版本的“ver”属性），或返回空的IQ结果（因此，表示任何花名册修改都将通过花名册推送发送，如下所述）。通常，除非返回完整的花名册，否则（1）使用的带宽将少于向客户发送单个花名册推送（例如，如果花名册只包含少数项目）或（2）服务器无法将版本ID与其文件中的任何先前版本相关联，服务器应发送一个空的IQ结果，然后通过服务器发送修改（如果有）。
S: <iq from='romeo@example.net'
id='r1h3vzp7'
to='romeo@example.net/home'
type='result'/>
S: <iq from='romeo@example.net'
id='r1h3vzp7'
to='romeo@example.net/home'
type='result'/>
Implementation Note: This empty IQ-result is different from an empty <query/> element, thus disambiguating this usage from an empty roster.
实现说明：这个空的IQ结果不同于一个空的<query/>元素，因此从一个空的花名册中消除了这种用法的歧义。
If roster versioning is enabled and the roster has not been modified since the version ID enumerated by the client, the server will simply not send any roster pushes to the client (until and unless some relevant event triggers a roster push during the lifetime of the client's session).
如果启用了花名册版本控制，并且花名册在客户端枚举版本ID后未被修改，则服务器将不会向客户端发送任何花名册推送（除非在客户端会话的生命周期内，某个相关事件触发花名册推送）。
If the roster has been modified since the version ID enumerated by the client, the server MUST then send one roster push to the client for each roster item that has been modified since the version ID enumerated by the client. (We call a roster push that is sent for purposes of roster version synchronization an "interim roster push".)
如果自客户端枚举的版本ID之后名册已被修改，则服务器必须为自客户端枚举的版本ID之后已修改的每个名册项目向客户端发送一次名册推送。（我们将为花名册版本同步而发送的花名册推送称为“临时花名册推送”。）
Definition: A "roster modification" is any change to the roster data that would result in a roster push to a connected client. Therefore, internal states related to roster processing within the server that would not result in a roster push to a connected client do not necessitate a change to the version.
定义：“花名册修改”是对花名册数据的任何更改，这将导致花名册推送到连接的客户端。因此，与服务器内花名册处理相关的内部状态不会导致花名册推送到连接的客户端，因此不需要更改版本。
S: <iq from='romeo@example.net'
id='ah382g67'
to='romeo@example.net/home'
type='set'>
<query xmlns='jabber:iq:roster' ver='ver34'>
<item jid='tybalt@example.org' subscription='remove'/>
</query>
</iq>
S: <iq from='romeo@example.net'
id='ah382g67'
to='romeo@example.net/home'
type='set'>
<query xmlns='jabber:iq:roster' ver='ver34'>
<item jid='tybalt@example.org' subscription='remove'/>
</query>
</iq>
S: <iq from='romeo@example.net'
id='b2gs90j5'
to='romeo@example.net/home'
type='set'>
<query xmlns='jabber:iq:roster' ver='ver42'>
<item jid='bill@example.org' subscription='both'/>
</query>
</iq>
S: <iq from='romeo@example.net'
id='b2gs90j5'
to='romeo@example.net/home'
type='set'>
<query xmlns='jabber:iq:roster' ver='ver42'>
<item jid='bill@example.org' subscription='both'/>
</query>
</iq>
S: <iq from='romeo@example.net'
id='c73gs419'
to='romeo@example.net/home'
type='set'>
<query xmlns='jabber:iq:roster' ver='ver72'>
<item jid='nurse@example.org'
name='Nurse'
subscription='to'>
<group>Servants</group>
</item>
</query>
</iq>
S: <iq from='romeo@example.net'
id='c73gs419'
to='romeo@example.net/home'
type='set'>
<query xmlns='jabber:iq:roster' ver='ver72'>
<item jid='nurse@example.org'
name='Nurse'
subscription='to'>
<group>Servants</group>
</item>
</query>
</iq>
S: <iq from='romeo@example.net'
id='dh361f35'
to='romeo@example.net/home'
type='set'>
<query xmlns='jabber:iq:roster' ver='ver96'>
<item jid='juliet@example.org'
name='Juliet'
subscription='both'>
<group>VIPs</group>
</item>
</query>
</iq>
S: <iq from='romeo@example.net'
id='dh361f35'
to='romeo@example.net/home'
type='set'>
<query xmlns='jabber:iq:roster' ver='ver96'>
<item jid='juliet@example.org'
name='Juliet'
subscription='both'>
<group>VIPs</group>
</item>
</query>
</iq>
These "interim roster pushes" can be understood as follows:
这些“临时名册推送”可以理解为：
1. Imagine that the client had an active presence session for the entire time between its cached roster version (say, "ver14") and the new roster version (say, "ver96").
1. 假设客户机在其缓存的花名册版本（如“ver14”）和新花名册版本（如“ver96”）之间的整个时间内都有一个活动的状态会话。
2. During that time, the client might have received roster pushes related to various roster versions (which might have been, say, "ver51" and "ver79"). However, some of those roster pushes might have contained intermediate updates to the same roster item (e.g., modifications to the subscription state for bill@example.org from "none" to "to" and from "to" to "both").
2. 在此期间，客户可能收到了与各种花名册版本相关的花名册推送（例如，可能是“ver51”和“ver79”）。但是，其中一些花名册推送可能包含对同一花名册项目的中间更新（例如，对用户订阅状态的修改）bill@example.org从“无”到“到”，从“到”到“两者”）。
3. The interim roster pushes would not include all of the intermediate steps, only the final result of all modifications applied to each item while the client was in fact offline (which might have been, say, "ver34", "ver42", "ver72", and "ver96").
3. 临时花名册推送不包括所有中间步骤，只包括客户实际上处于脱机状态时应用于每个项目的所有修改的最终结果（例如，可能是“ver34”、“ver42”、“ver72”和“ver96”）。
The client MUST handle an "interim roster push" in the same way it handles any roster push (indeed, from the client's perspective it cannot tell the difference between an "interim" roster push and a "live" roster push and therefore it has no way of knowing when it has received all of the interim roster pushes). When requesting the roster after reconnection, the client SHOULD request the version associated with the last roster push it received during its previous session, not the version associated with the roster result it received at the start of its previous session.
客户必须以处理任何花名册推送的相同方式处理“临时花名册推送”（实际上，从客户的角度来看，客户无法区分“临时”花名册推送和“实时”花名册推送，因此无法知道何时收到所有临时花名册推送）。在重新连接后请求排班时，客户端应请求与上次排班推送相关联的版本，而不是与上次会话开始时收到的排班结果相关联的版本。
When roster versioning is enabled, the server MUST include the updated roster version with each roster push. Roster pushes MUST occur in order of modification and the version contained in a roster push MUST be unique. Even if the client has not included the 'ver' attribute in its roster gets or sets, the server SHOULD include the 'ver' attribute on all roster pushes and results that it sends to the client.
启用排班版本控制时，服务器必须在每次排班推送时包含更新的排班版本。排班推送必须按修改顺序进行，排班推送中包含的版本必须唯一。即使客户端没有在其花名册获取或设置中包含“ver”属性，服务器也应该在发送给客户端的所有花名册推送和结果中包含“ver”属性。
Implementation Note: Guidelines and more detailed examples for roster versioning are provided in [XEP-0237].
实施说明：[XEP-0237]中提供了花名册版本控制的指南和更详细的示例。
In order to protect the privacy of XMPP users, presence information is disclosed only to other entities that a user has approved. When a user has agreed that another entity is allowed to view its presence, the entity is said to have a "subscription" to the user's presence. An entity that has a subscription to a user's presence or to which a user has a presence subscription is called a "contact" (in this document the term "contact" is also used in a less strict sense to refer to a potential contact or any item in a user's roster).
为了保护XMPP用户的隐私，状态信息仅披露给用户已批准的其他实体。当用户同意允许另一实体查看其存在时，该实体被称为对该用户的存在有“订阅”。订阅了用户状态或用户订阅了状态的实体称为“联系人”（在本文档中，术语“联系人”在不太严格的意义上也用于指潜在联系人或用户名册中的任何项目）。
In XMPP, a subscription lasts across presence sessions; indeed, it lasts until the contact unsubscribes or the user cancels the previously granted subscription. (This model is different from that used for presence subscriptions in the Session Initiation Protocol (SIP), as defined in [SIP-PRES].)
在XMPP中，订阅持续整个状态会话；实际上，它会一直持续到联系人取消订阅或用户取消先前授予的订阅。（此模型与[SIP-PRES]中定义的会话启动协议（SIP）中用于状态订阅的模型不同。）
Subscriptions are managed within XMPP by sending presence stanzas containing specially defined attributes ("subscribe", "unsubscribe", "subscribed", and "unsubscribed").
在XMPP中，通过发送包含特殊定义属性（“订阅”、“取消订阅”、“订阅”和“取消订阅”）的状态节来管理订阅。
Implementation Note: When a server processes or generates an outbound presence stanza of type "subscribe", "subscribed", "unsubscribe", or "unsubscribed", the server MUST stamp the outgoing presence stanza with the bare JID <localpart@domainpart> of the sending entity, not the full JID <localpart@domainpart/resourcepart>. Enforcement of this rule simplifies the presence subscription model and helps to prevent presence leaks; for information about presence leaks, refer to the security considerations of [XMPP-CORE].
实施说明：当服务器处理或生成类型为“订阅”、“订阅”、“取消订阅”或“取消订阅”的出站状态节时，服务器必须在出站状态节上加盖裸JID戳<localpart@domainpart>发送实体的，而不是完整的JID<localpart@domainpart/resourcepart>。此规则的实施简化了状态订阅模型，并有助于防止状态泄漏；有关存在漏洞的信息，请参阅[XMPP-CORE]的安全注意事项。
Subscription states are reflected in the rosters of both the user and the contact. This section does not cover every possible case related to presence subscriptions, and mainly narrates the protocol flows for bootstrapping a mutual subscription between a user and a contact. Complete details regarding subscription states can be found under Appendix A.
订阅状态反映在用户和联系人的名册中。本节并不涵盖与状态订阅相关的所有可能情况，主要讲述用于引导用户和联系人之间的相互订阅的协议流。有关订阅状态的完整详细信息，请参见附录A。
A "subscription request" is a request from a user for authorization to permanently subscribe to a contact's presence information; syntactically it is a presence stanza whose 'type' attribute has a value of "subscribe". A subscription request is generated by a
“订阅请求”是来自用户的授权请求，以永久订阅联系人的存在信息；从语法上讲，它是一个presence节，其“type”属性的值为“subscribe”。订阅请求由
user's client, processed by the (potential) contact's server, and acted on by the contact via the contact's client. The workflow is described in the following sections.
用户的客户端，由（潜在）联系人的服务器处理，并由联系人通过联系人的客户端执行操作。以下各节介绍了该工作流。
Implementation Note: Presence subscription requests are sent to available resources, whereas the roster pushes associated with subscription state changes are sent to interested resources. Therefore, if a resource wishes to receive both subscription requests and roster pushes, it MUST both send initial presence and request the roster.
实现说明：状态订阅请求被发送到可用资源，而与订阅状态更改相关联的花名册推送被发送到感兴趣的资源。因此，如果资源希望同时接收订阅请求和花名册推送，则它必须同时发送初始状态并请求花名册。
A user's client generates a subscription request by sending a presence stanza of type "subscribe" and specifying a 'to' address of the potential contact's bare JID <contact@domainpart>.
用户的客户端通过发送“subscribe”类型的状态节并指定潜在联系人的裸JID的“to”地址来生成订阅请求<contact@domainpart>.
UC: <presence id='xk3h1v69'
to='juliet@example.com'
type='subscribe'/>
UC: <presence id='xk3h1v69'
to='juliet@example.com'
type='subscribe'/>
When a user sends a presence subscription request to a potential instant messaging and presence contact, the value of the 'to' attribute MUST be a bare JID <contact@domainpart> rather than a full JID <contact@domainpart/resourcepart>, since the desired result is for the user to receive presence from all of the contact's resources, not merely the particular resource specified in the 'to' attribute. Use of bare JIDs also simplifies subscription processing, presence probes, and presence notifications by the user's server and the contact's server.
当用户向潜在的即时消息和状态联系人发送状态订阅请求时，“to”属性的值必须是裸JID<contact@domainpart>而不是一个完整的JID<contact@domainpart/resourcepart>，因为期望的结果是用户从联系人的所有资源接收状态，不仅仅是“to”属性中指定的特定资源。裸JID的使用还简化了用户服务器和联系人服务器的订阅处理、状态探测和状态通知。
For tracking purposes, a client SHOULD include an 'id' attribute in a presence subscription request.
出于跟踪目的，客户端应在状态订阅请求中包含“id”属性。
Implementation Note: Many XMPP clients prompt the user for information about the potential contact (e.g., "handle" and desired roster group) when generating an outbound presence subscription request and therefore send a roster set before sending the outbound presence subscription request. This behavior is OPTIONAL, because a client MAY instead wait until receiving the initial roster push from the server before uploading user-provided information about the contact. A server MUST process a roster set and outbound presence subscription request in either order (i.e., in whatever order generated by the client).
实现说明：许多XMPP客户端在生成出站状态订阅请求时会提示用户提供有关潜在联系人的信息（例如，“句柄”和所需的花名册组），因此在发送出站状态订阅请求之前会发送花名册集。此行为是可选的，因为客户端可能会等到从服务器接收到初始花名册推送后再上载用户提供的联系人信息。服务器必须以任意顺序（即，客户机生成的任何顺序）处理花名册集和出站状态订阅请求。
Upon receiving the outbound presence subscription request, the user's server MUST proceed as follows.
在收到出站状态订阅请求后，用户的服务器必须按照以下步骤进行操作。
1. Before processing the request, the user's server MUST check the syntax of the JID contained in the 'to' attribute (however, it is known that some existing implementations do not perform this check). If the JID is of the form <contact@domainpart/resourcepart> instead of <contact@domainpart>, the user's server SHOULD treat it as if the request had been directed to the contact's bare JID and modify the 'to' address accordingly. The server MAY also verify that the JID adheres to the format defined in [XMPP-ADDR] and possibly return a <jid-malformed/> stanza error.
1. 在处理请求之前，用户的服务器必须检查“to”属性中包含的JID语法（但是，已知一些现有实现不执行此检查）。如果JID的形式是<contact@domainpart/resourcepart>而不是<contact@domainpart>，用户的服务器应将其视为请求已定向到联系人的裸JID，并相应地修改“收件人”地址。服务器还可以验证JID是否符合[XMPP-ADDR]中定义的格式，并可能返回<JID-malformed/>节错误。
2. If the potential contact is hosted on the same server as the user, then the server MUST adhere to the rules specified under Section 3.1.3 when processing the subscription request and delivering it to the (local) contact.
2. 如果潜在联系人与用户托管在同一台服务器上，则在处理订阅请求并将其发送给（本地）联系人时，服务器必须遵守第3.1.3节规定的规则。
3. If the potential contact is hosted on a remote server, subject to local service policies the user's server MUST then route the stanza to that remote domain in accordance with core XMPP stanza processing rules. (This can result in returning an appropriate stanza error to the user, such as <remote-server-timeout/>.)
3. 如果潜在联系人托管在远程服务器上，则根据本地服务策略，用户服务器必须根据核心XMPP节处理规则将节路由到该远程域。（这可能会导致向用户返回适当的节错误，例如<remote server timeout/>。）
As mentioned, before locally delivering or remotely routing the presence subscription request, the user's server MUST stamp the outbound subscription request with the bare JID <user@domainpart> of the user.
如上所述，在本地传递或远程路由状态订阅请求之前，用户的服务器必须使用裸JID标记出站订阅请求<user@domainpart>用户的名称。
US: <presence from='romeo@example.net'
id='xk3h1v69'
to='juliet@example.com'
type='subscribe'/>
US: <presence from='romeo@example.net'
id='xk3h1v69'
to='juliet@example.com'
type='subscribe'/>
If the presence subscription request cannot be locally delivered or remotely routed (e.g., because the request is malformed, the local contact does not exist, the remote server does not exist, an attempt to contact the remote server times out, or any other error is determined or experienced by the user's server), then the user's server MUST return an appropriate error stanza to the user. An example follows.
如果无法本地传递或远程路由状态订阅请求（例如，由于请求格式不正确、本地联系人不存在、远程服务器不存在、尝试联系远程服务器超时或用户服务器确定或遇到任何其他错误），然后，用户的服务器必须向用户返回适当的错误节。下面是一个例子。
US: <presence from='juliet@example.com'
id='xk3h1v69'
to='romeo@example.net'
type='error'>
<error type='modify'>
<remote-server-not-found
xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
</error>
</presence>
US: <presence from='juliet@example.com'
id='xk3h1v69'
to='romeo@example.net'
type='error'>
<error type='modify'>
<remote-server-not-found
xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
</error>
</presence>
After locally delivering or remotely routing the presence subscription request, the user's server MUST then send a roster push to all of the user's interested resources, containing the potential contact with a subscription state of "none" and with notation that the subscription is pending (via an 'ask' attribute whose value is "subscribe").
在本地传递或远程路由状态订阅请求后，用户的服务器必须向用户感兴趣的所有资源发送一个花名册推送，其中包含订阅状态为“无”的潜在联系人，并注明订阅处于挂起状态（通过值为“subscribe”的“ask”属性）。
US: <iq id='b89c5r7ib574'
to='romeo@example.net/foo'
type='set'>
<query xmlns='jabber:iq:roster'>
<item ask='subscribe'
jid='juliet@example.com'
subscription='none'/>
</query>
</iq>
US: <iq id='b89c5r7ib574'
to='romeo@example.net/foo'
type='set'>
<query xmlns='jabber:iq:roster'>
<item ask='subscribe'
jid='juliet@example.com'
subscription='none'/>
</query>
</iq>
US: <iq id='b89c5r7ib575'
to='romeo@example.net/bar'
type='set'>
<query xmlns='jabber:iq:roster'>
<item ask='subscribe'
jid='juliet@example.com'
subscription='none'/>
</query>
</iq>
US: <iq id='b89c5r7ib575'
to='romeo@example.net/bar'
type='set'>
<query xmlns='jabber:iq:roster'>
<item ask='subscribe'
jid='juliet@example.com'
subscription='none'/>
</query>
</iq>
If a remote contact does not approve or deny the subscription request within some configurable amount of time, the user's server SHOULD resend the 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 might have occurred when the original subscription request was routed to the remote domain. When doing so, it is RECOMMENDED for the server to include an 'id' attribute so that it can track responses to the resent subscription request.
如果远程联系人在某个可配置的时间内未批准或拒绝订阅请求，则用户服务器应根据特定于实现的算法（例如，每当新资源可供用户使用时，或在经过一定时间后）将订阅请求重新发送给联系人；这有助于从将原始订阅请求路由到远程域时可能发生的暂时、静默错误中恢复。执行此操作时，建议服务器包含“id”属性，以便跟踪对重新提交订阅请求的响应。
Before processing the inbound presence subscription request, the contact's server SHOULD check the syntax of the JID contained in the 'to' attribute. If the JID is of the form <contact@domainpart/resourcepart> instead of <contact@domainpart>, the contact's server SHOULD treat it as if the request had been directed to the contact's bare JID and modify the 'to' address accordingly. The server MAY also verify that the JID adheres to the format defined in [XMPP-ADDR] and possibly return a <jid-malformed/> stanza error.
在处理入站状态订阅请求之前，联系人的服务器应检查“to”属性中包含的JID语法。如果JID的形式是<contact@domainpart/resourcepart>而不是<contact@domainpart>，联系人的服务器应将其视为请求已定向到联系人的裸JID，并相应地修改“收件人”地址。服务器还可以验证JID是否符合[XMPP-ADDR]中定义的格式，并可能返回<JID-malformed/>节错误。
When processing the inbound presence subscription request, the contact's server MUST adhere to the following rules:
处理入站状态订阅请求时，联系人的服务器必须遵守以下规则：
1. Above all, the contact's server MUST NOT automatically approve subscription requests on the contact's behalf -- unless the contact has (a) pre-approved subscription requests from the user as described under Section 3.4, (b) configured its account to automatically approve subscription requests, or (c) accepted an agreement with its service provider that allows automatic approval (for instance, via an employment agreement within an enterprise deployment). Instead, if a subscription request requires approval then the contact's server MUST deliver that request to the contact's available resource(s) for approval or denial by the contact.
1. 最重要的是，联系人的服务器不得代表联系人自动批准订阅请求，除非联系人（a）按照第3.4节的规定预先批准了用户的订阅请求，（b）将其帐户配置为自动批准订阅请求，或（c）接受与其服务提供商签订的允许自动批准的协议（例如，通过企业部署中的雇佣协议）。相反，如果订阅请求需要批准，则联系人的服务器必须将该请求传递给联系人的可用资源，以供联系人批准或拒绝。
2. If the contact exists and the user already has a subscription to the contact's presence, then the contact's server MUST auto-reply on behalf of the contact by sending a presence stanza of type "subscribed" from the contact's bare JID to the user's bare JID. Likewise, if the contact previously sent a presence stanza of type "subscribed" and the contact's server treated that as indicating "pre-approval" for the user's presence subscription (see Section 3.4), then the contact's server SHOULD also auto-reply on behalf of the contact.
2. 如果联系人存在且用户已经订阅了联系人的状态，则联系人的服务器必须通过从联系人的裸JID向用户的裸JID发送类型为“subscribed”的状态节来代表联系人自动回复。同样，如果联系人之前发送了类型为“subscribed”的状态节，并且联系人的服务器将其视为表示用户状态订阅的“预批准”（参见第3.4节），则联系人的服务器也应代表联系人自动回复。
CS: <presence from='juliet@example.com'
id='xk3h1v69'
to='romeo@example.net'
type='subscribed'/>
CS: <presence from='juliet@example.com'
id='xk3h1v69'
to='romeo@example.net'
type='subscribed'/>
3. Otherwise, if there is at least one available resource associated with the contact when the subscription request is received by the contact's server, then the contact's server MUST send that subscription request to all available resources in accordance with Section 8. As a way of acknowledging receipt of the presence subscription request, the contact's server MAY send a
3. 否则，如果当联系人的服务器收到订阅请求时，至少有一个可用资源与联系人关联，则联系人的服务器必须根据第8节向所有可用资源发送该订阅请求。作为确认收到状态订阅请求的一种方式，联系人的服务器可以发送
presence stanza of type "unavailable" from the bare JID of the contact to the bare JID of the user (the user's client MUST NOT assume that this acknowledgement provides presence information about the contact, since it comes from the contact's bare JID and is received before the subscription request has been approved).
从联系人的裸JID到用户的裸JID，类型为“不可用”的状态节（用户的客户端不得假定此确认提供了有关联系人的状态信息，因为它来自联系人的裸JID，并且在订阅请求批准之前收到）。
4. Otherwise, if the contact has no available resources when the subscription request is received by the contact's server, then the contact's server MUST keep a record of the complete presence stanza comprising the subscription request, including any extended content contained therein (see Section 8.4 of [XMPP-CORE]), and then deliver the request when the contact next has an available resource. The contact's server MUST continue to deliver the subscription request whenever the contact creates an available resource, until the contact either approves or denies the request. (The contact's server MUST NOT deliver more than one subscription request from any given user when the contact next has an available resource; e.g., if the user sends multiple subscription requests to the contact while the contact is offline, the contact's server SHOULD store only one of those requests, such as the first request or last request, and MUST deliver only one of the requests when the contact next has an available resource; this helps to prevent "subscription request spam".)
4. 否则，当联系人的服务器收到订阅请求时，如果联系人没有可用的资源，则联系人的服务器必须保留包含订阅请求的完整状态节的记录，包括其中包含的任何扩展内容（见[XMPP-CORE]第8.4节），然后在下一个联系人有可用资源时发送请求。每当联系人创建可用资源时，该联系人的服务器必须继续传递订阅请求，直到该联系人批准或拒绝该请求为止。（当联系人下一个拥有可用资源时，联系人的服务器不得从任何给定用户发送多个订阅请求；例如，如果用户在联系人脱机时向联系人发送多个订阅请求，则联系人的服务器应仅存储这些请求中的一个，例如第一个请求或最后一个请求当下一个联系人有可用资源时，nd必须只发送一个请求；这有助于防止“订阅请求垃圾邮件”。）
Security Warning: Until and unless the contact approves the subscription request as described under Section 3.1.4, the contact's server MUST NOT add an item for the user to the contact's roster.
安全警告：除非联系人按照第3.1.4节所述批准订阅请求，否则联系人的服务器不得将用户的项目添加到联系人的花名册中。
Security Warning: The mandate for the contact's server to store the complete stanza of the presence subscription request introduces the possibility of an application resource exhaustion attack (see Section 2.1.2 of [DOS]), for example, by a rogue server or a coordinated group of users (e.g., a botnet) against the contact's server or particular contact. Server implementers are advised to consider the possibility of such attacks and provide tools for counteracting it, such as enabling service administrators to set limits on the number or size of inbound presence subscription requests that the server will store in aggregate or for any given contact.
安全警告：要求联系人的服务器存储状态订阅请求的完整部分可能会导致应用程序资源耗尽攻击（参见[DOS]第2.1.2节），例如恶意服务器或协调的用户组（如僵尸网络）针对联系人的服务器或特定联系人。建议服务器执行者考虑此类攻击的可能性并提供用于抵消它的工具，例如使服务管理员能够对服务器将存储在集合或任何给定联系人中的入站存在订阅请求的数量或大小设置限制。
When an interactive client receives a subscription request, it MUST present the request to the natural person controlling the client (i.e., the "contact") for approval, unless the contact has explicitly configured the client to automatically approve or deny some or all
交互客户端收到订阅请求时，必须将该请求提交给控制该客户端的自然人（即“联系人”）批准，除非该联系人已明确配置客户端自动批准或拒绝部分或全部订阅
subscription requests as described above. An automated client that is not controlled by a natural person will have its own application-specific rules for approving or denying subscription requests.
如上所述的订阅请求。不受自然人控制的自动客户端将有自己的特定于应用程序的规则来批准或拒绝订阅请求。
A client approves a subscription request by sending a presence stanza of type "subscribed", which is processed as described under Section 3.1.5 for the contact's server and Section 3.1.6 for the user's server.
客户端通过发送类型为“subscribed”的状态节来批准订阅请求，该状态节按照第3.1.5节针对联系人服务器和第3.1.6节针对用户服务器的描述进行处理。
CC: <presence id='h4v1c4kj'
to='romeo@example.net'
type='subscribed'/>
CC: <presence id='h4v1c4kj'
to='romeo@example.net'
type='subscribed'/>
A client denies a subscription request by sending a presence stanza of type "unsubscribed", which is processed as described under Section 3.2 for both the contact's server and the user's server.
客户端通过发送类型为“unsubscribed”的状态节来拒绝订阅请求，该状态节按照第3.2节对联系人服务器和用户服务器进行处理。
CC: <presence id='tb2m1b59'
to='romeo@example.net'
type='unsubscribed'/>
CC: <presence id='tb2m1b59'
to='romeo@example.net'
type='unsubscribed'/>
For tracking purposes, a client SHOULD include an 'id' attribute in a subscription approval or subscription denial; this 'id' attribute MUST NOT mirror the 'id' attribute of the subscription request.
出于跟踪目的，客户端应在订阅批准或订阅拒绝中包含“id”属性；此“id”属性不能镜像订阅请求的“id”属性。
When the contact's client sends the subscription approval, the contact's server MUST stamp the outbound stanza with the bare JID <contact@domainpart> of the contact and locally deliver or remotely route the stanza to the user.
当联系人的客户端发送订阅批准时，联系人的服务器必须使用裸JID标记出站节<contact@domainpart>并将节本地交付或远程路由给用户。
CS: <presence from='juliet@example.com'
id='h4v1c4kj'
to='romeo@example.net'
type='subscribed'/>
CS: <presence from='juliet@example.com'
id='h4v1c4kj'
to='romeo@example.net'
type='subscribed'/>
The contact's server then MUST send an updated roster push to all of the contact's interested resources, with the 'subscription' attribute set to a value of "from". (Here we assume that the contact does not already have a subscription to the user; if that were the case, the 'subscription' attribute would be set to a value of "both", as explained under Appendix A.)
然后，联系人的服务器必须向联系人感兴趣的所有资源发送更新的花名册推送，并将“订阅”属性设置为值“from”。（此处我们假设联系人尚未订阅用户；如果是这种情况，“订阅”属性将设置为“两者”的值，如附录a所述。）
CS: <iq id='a78b4q6ha463'
to='juliet@example.com/balcony'
type='set'>
<query xmlns='jabber:iq:roster'>
<item jid='romeo@example.net'
subscription='from'/>
</query>
</iq>
CS: <iq id='a78b4q6ha463'
to='juliet@example.com/balcony'
type='set'>
<query xmlns='jabber:iq:roster'>
<item jid='romeo@example.net'
subscription='from'/>
</query>
</iq>
CS: <iq id='x81g3bdy4n19'
to='juliet@example.com/chamber'
type='set'>
<query xmlns='jabber:iq:roster'>
<item jid='romeo@example.net'
subscription='from'/>
</query>
</iq>
CS: <iq id='x81g3bdy4n19'
to='juliet@example.com/chamber'
type='set'>
<query xmlns='jabber:iq:roster'>
<item jid='romeo@example.net'
subscription='from'/>
</query>
</iq>
From the perspective of the contact, there now exists a subscription from the user, which is why the 'subscription' attribute is set to a value of "from". (Here we assume that the contact does not already have a subscription to the user; if that were the case, the 'subscription' attribute would be set to a value of "both", as explained under Appendix A.)
从联系人的角度来看，现在存在来自用户的订阅，这就是为什么将“订阅”属性设置为“From”值的原因。（此处我们假设联系人尚未订阅用户；如果是这种情况，“订阅”属性将设置为“两者”的值，如附录a所述。）
The contact's server MUST then also send current presence to the user from each of the contact's available resources.
然后，联系人的服务器还必须从联系人的每个可用资源向用户发送当前状态。
CS: <presence from='juliet@example.com/balcony'
id='pw72bc5j'
to='romeo@example.net'/>
CS: <presence from='juliet@example.com/balcony'
id='pw72bc5j'
to='romeo@example.net'/>
CS: <presence from='juliet@example.com/chamber'
id='ux31da4q'
to='romeo@example.net'/>
CS: <presence from='juliet@example.com/chamber'
id='ux31da4q'
to='romeo@example.net'/>
In order to subscribe to the user's presence, the contact would then need to send a subscription request to the user. (XMPP clients will often automatically send the subscription request instead of requiring the contact to initiate the subscription request, since it is assumed that the desired end state is a mutual subscription.) Naturally, when the contact sends a subscription request to the user, the subscription states will be different from those shown in the foregoing examples (see Appendix A) and the roles will be reversed.
为了订阅用户的状态，联系人需要向用户发送订阅请求。（XMPP客户端通常会自动发送订阅请求，而不是要求联系人启动订阅请求，因为假定所需的最终状态是相互订阅。）自然，当联系人向用户发送订阅请求时，订阅状态将不同于上述示例（见附录A）中所示的状态，角色将颠倒。
When the user's server receives a subscription approval, it MUST first check if the contact is in the user's roster with subscription='none' or subscription='from' and the 'ask' flag set to "subscribe" (i.e., a subscription state of "None + Pending Out", "None + Pending Out+In", or "From + Pending Out"; see Appendix A). If this check is successful, then the user's server MUST:
当用户服务器收到订阅批准时，它必须首先检查联系人是否在用户名册中，订阅为“无”或订阅为“发件人”，且“询问”标志设置为“订阅”（即订阅状态为“无+待决出”、“无+待决出+入”或“发件人+待决出”；参见附录a）。如果此检查成功，则用户的服务器必须：
1. Deliver the inbound subscription approval to all of the user's interested resources (this helps to give the user's client(s) proper context regarding the subscription approval so that they can differentiate between a roster push originated by another of the user's resources and a subscription approval received from the contact). This MUST occur before sending the roster push described in the next step.
1. 将入站订阅批准传递给用户感兴趣的所有资源（这有助于为用户的客户端提供有关订阅批准的适当上下文，以便他们能够区分由另一个用户资源发起的花名册推送和从联系人收到的订阅批准）。这必须在发送下一步中描述的花名册推送之前发生。
US: <presence from='juliet@example.com'
id='h4v1c4kj'
to='romeo@example.net'
type='subscribed'/>
US: <presence from='juliet@example.com'
id='h4v1c4kj'
to='romeo@example.net'
type='subscribed'/>
2. Initiate a roster push to all of the user's interested resources, containing an updated roster item for the contact with the 'subscription' attribute set to a value of "to" (if the subscription state was "None + Pending Out" or "None + Pending Out+In") or "both" (if the subscription state was "From + Pending Out").
2. 启动对用户感兴趣的所有资源的花名册推送，其中包含联系人的更新花名册项目，该联系人的“订阅”属性设置为“到”（如果订阅状态为“无+挂起输出”或“无+挂起输出+输入”）或“两者”（如果订阅状态为“从+挂起输出”）。
US: <iq id='b89c5r7ib576'
to='romeo@example.net/foo'
type='set'>
<query xmlns='jabber:iq:roster'>
<item jid='juliet@example.com'
subscription='to'/>
</query>
</iq>
US: <iq id='b89c5r7ib576'
to='romeo@example.net/foo'
type='set'>
<query xmlns='jabber:iq:roster'>
<item jid='juliet@example.com'
subscription='to'/>
</query>
</iq>
US: <iq id='b89c5r7ib577'
to='romeo@example.net/bar'
type='set'>
<query xmlns='jabber:iq:roster'>
<item jid='juliet@example.com'
subscription='to'/>
</query>
</iq>
US: <iq id='b89c5r7ib577'
to='romeo@example.net/bar'
type='set'>
<query xmlns='jabber:iq:roster'>
<item jid='juliet@example.com'
subscription='to'/>
</query>
</iq>
3. The user's server MUST also deliver the available presence stanza received from each of the contact's available resources to each of the user's available resources.
3. 用户的服务器还必须将从每个联系人的可用资源收到的可用状态节传递给每个用户的可用资源。
[ ... to resource1 ... ]
[…到资源1…]
US: <presence from='juliet@example.com/balcony'
id='pw72bc5j'
to='romeo@example.net'/>
US: <presence from='juliet@example.com/balcony'
id='pw72bc5j'
to='romeo@example.net'/>
[ ... to resource2 ... ]
[…到资源2…]
US: <presence from='juliet@example.com/balcony'
id='pw72bc5j'
to='romeo@example.net'/>
US: <presence from='juliet@example.com/balcony'
id='pw72bc5j'
to='romeo@example.net'/>
[ ... to resource1 ... ]
[…到资源1…]
US: <presence from='juliet@example.com/chamber'
id='ux31da4q'
to='romeo@example.net'/>
US: <presence from='juliet@example.com/chamber'
id='ux31da4q'
to='romeo@example.net'/>
[ ... to resource2 ... ]
[…到资源2…]
US: <presence from='juliet@example.com/chamber'
id='ux31da4q'
to='romeo@example.net'/>
US: <presence from='juliet@example.com/chamber'
id='ux31da4q'
to='romeo@example.net'/>
Implementation Note: If the user's account has no available resources when the inbound subscription approval notification is received, the user's server MAY keep a record of the notification (ideally the complete presence stanza) and then deliver the notification when the account next has an available resource. This behavior provides more complete signaling to the user regarding the reasons for the roster change that occurred while the user was offline.
实施说明：如果在接收到入站订阅批准通知时用户的帐户没有可用资源，则用户的服务器可能会保留通知的记录（理想情况下是完整的状态节），然后在帐户下次有可用资源时发送通知。此行为向用户提供有关用户脱机时发生的花名册更改原因的更完整的信号。
Otherwise -- that is, if the user does not exist, if the contact is not in the user's roster, or if the contact is in the user's roster with a subscription state other than those described in the foregoing check -- then the user's server MUST silently ignore the subscription approval notification by not delivering it to the user, not modifying the user's roster, and not generating a roster push to the user's interested resources.
否则——也就是说，如果用户不存在，如果联系人不在用户名册中，或者如果联系人在用户名册中的订阅状态与上述检查中所述的订阅状态不同——那么用户服务器必须通过不向用户发送订阅批准通知来默默地忽略订阅批准通知，不修改用户的花名册，也不生成花名册推送到用户感兴趣的资源。
From the perspective of the user, there now exists a subscription to the contact's presence (which is why the 'subscription' attribute is set to a value of "to").
从用户的角度来看，现在存在对联系人状态的订阅（这就是为什么将“订阅”属性设置为值“to”）。
If a contact would like to cancel a subscription that it has previously granted to a user, to cancel a subscription pre-approval (Section 3.4), or to deny a subscription request, it sends a presence stanza of type "unsubscribed".
如果联系人希望取消其先前授予用户的订阅、取消订阅预批准（第3.4节）或拒绝订阅请求，则会发送类型为“unsubscribed”的状态节。
CC: <presence id='ij5b1v7g'
to='romeo@example.net'
type='unsubscribed'/>
CC: <presence id='ij5b1v7g'
to='romeo@example.net'
type='unsubscribed'/>
Upon receiving the outbound subscription cancellation, the contact's server MUST proceed as follows.
收到出站订阅取消后，联系人的服务器必须按以下步骤进行操作。
1. If the user's bare JID is not yet in the contact's roster or is in the contact's roster with a state of "None", "None + Pending Out", or "To", the contact's server SHOULD NOT route or deliver the presence stanza of type "unsubscribed" to the user and MUST NOT send presence notifications of type "unavailable" to the user as described below.
1. 如果用户的裸JID尚未在联系人名册中，或者在联系人名册中的状态为“无”、“无+挂起”或“至”，则联系人服务器不应将类型为“未订阅”的状态节路由或交付给用户，并且不得向用户发送类型为“不可用”的状态通知，如下所述。
2. If the user's bare JID is in the contact's roster with a state of "None", "None + Pending Out", or "To" and the 'approved' flag is set to "true" (thus signaling a subscription pre-approval as described under Section 3.4), the contact's server MUST remove the pre-approval and MUST NOT route or deliver the presence stanza of type "unsubscribed" to the user.
2. 如果用户的裸JID在联系人名册中的状态为“无”、“无+待决”或“至”，且“已批准”标志设置为“真”（从而发出第3.4节所述的订阅预批准信号），则联系人的服务器必须删除预批准，并且不得发送或交付“未订阅”类型的状态节给用户。
3. Otherwise, as shown in the following examples, the contact's server MUST route or deliver both presence notifications of type "unavailable" and presence stanzas of type "unsubscribed" to the user and MUST send a roster push to the contact.
3. 否则，如以下示例所示，联系人的服务器必须将类型为“不可用”的状态通知和类型为“未订阅”的状态节路由或传递给用户，并且必须向联系人发送排班推送。
While the user is still subscribed to the contact's presence (i.e., before the contact's server routes or delivers the presence stanza of type "unsubscribed" to the user), the contact's server MUST send a presence stanza of type "unavailable" from all of the contact's online resources to the user.
当用户仍然订阅联系人的状态时（即，在联系人的服务器将类型为“unsubscribed”的状态节路由或交付给用户之前），联系人的服务器必须从联系人的所有在线资源向用户发送类型为“unavailable”的状态节。
CS: <presence from='juliet@example.com/balcony'
id='i8bsg3h3'
type='unavailable'/>
CS: <presence from='juliet@example.com/balcony'
id='i8bsg3h3'
type='unavailable'/>
CS: <presence from='juliet@example.com/chamber'
id='bvx2c9mk'
type='unavailable'/>
CS: <presence from='juliet@example.com/chamber'
id='bvx2c9mk'
type='unavailable'/>
Then the contact's server MUST route or deliver the presence stanza of type "unsubscribed" to the user, making sure to stamp the outbound subscription cancellation with the bare JID <contact@domainpart> of the contact.
然后，联系人的服务器必须将类型为“unsubscribed”的状态节路由或交付给用户，确保在出站订阅取消上加盖裸JID的印章<contact@domainpart>联系方式。
CS: <presence from='juliet@example.com'
id='ij5b1v7g'
to='romeo@example.net'
type='unsubscribed'/>
CS: <presence from='juliet@example.com'
id='ij5b1v7g'
to='romeo@example.net'
type='unsubscribed'/>
The contact's server then MUST send a roster push with the updated roster item to all of the contact's interested resources, where the subscription state is now either "none" or "to" (see Appendix A).
然后，联系人的服务器必须向联系人的所有感兴趣的资源发送带有更新的花名册项目的花名册推送，其中订阅状态现在为“无”或“至”（见附录a）。
CS: <iq id='pw3f2v175b34'
to='juliet@example.com/balcony'
type='set'>
<query xmlns='jabber:iq:roster'>
<item jid='romeo@example.net'
subscription='none'/>
</query>
</iq>
CS: <iq id='pw3f2v175b34'
to='juliet@example.com/balcony'
type='set'>
<query xmlns='jabber:iq:roster'>
<item jid='romeo@example.net'
subscription='none'/>
</query>
</iq>
CS: <iq id='zu2y3f571v35'
to='juliet@example.com/chamber'
type='set'>
<query xmlns='jabber:iq:roster'>
<item jid='romeo@example.net'
subscription='none'/>
</query>
</iq>
CS: <iq id='zu2y3f571v35'
to='juliet@example.com/chamber'
type='set'>
<query xmlns='jabber:iq:roster'>
<item jid='romeo@example.net'
subscription='none'/>
</query>
</iq>
When the user's server receives the inbound subscription cancellation, it MUST first check if the contact is in the user's roster with subscription='to' or subscription='both' (see Appendix A). If this check is successful, then the user's server MUST:
当用户的服务器收到入站订阅取消时，它必须首先检查联系人是否在用户的名册中，subscription='to'或subscription='both'（参见附录A）。如果此检查成功，则用户的服务器必须：
1. Deliver the inbound subscription cancellation to all of the user's interested resources (this helps to give the user's client(s) proper context regarding the subscription cancellation so that they can differentiate between a roster push originated by another of the user's resources and a subscription cancellation received from the contact). This MUST occur before sending the roster push described in the next step.
1. 将入站订阅取消发送到用户感兴趣的所有资源（这有助于为用户的客户端提供有关订阅取消的适当上下文，以便他们能够区分由另一个用户资源发起的花名册推送和从联系人收到的订阅取消）。这必须在发送下一步中描述的花名册推送之前发生。
US: <presence from='juliet@example.com'
id='ij5b1v7g'
to='romeo@example.net'
type='unsubscribed'/>
US: <presence from='juliet@example.com'
id='ij5b1v7g'
to='romeo@example.net'
type='unsubscribed'/>
2. Initiate a roster push to all of the user's interested resources, containing an updated roster item for the contact with the 'subscription' attribute set to a value of "none" (if the subscription state was "To" or "To + Pending In") or "from" (if the subscription state was "Both").
2. 启动对用户感兴趣的所有资源的花名册推送，其中包含联系人的更新花名册项目，该联系人的“订阅”属性设置为“无”（如果订阅状态为“至”或“至+待决于”）或“自”（如果订阅状态为“两者”）。
US: <iq id='h37h3u1bv400'
to='romeo@example.net/foo'
type='set'>
<query xmlns='jabber:iq:roster'>
<item jid='juliet@example.com'
subscription='none'/>
</query>
</iq>
US: <iq id='h37h3u1bv400'
to='romeo@example.net/foo'
type='set'>
<query xmlns='jabber:iq:roster'>
<item jid='juliet@example.com'
subscription='none'/>
</query>
</iq>
US: <iq id='h37h3u1bv401'
to='romeo@example.net/bar'
type='set'>
<query xmlns='jabber:iq:roster'>
<item jid='juliet@example.com'
subscription='none'/>
</query>
</iq>
US: <iq id='h37h3u1bv401'
to='romeo@example.net/bar'
type='set'>
<query xmlns='jabber:iq:roster'>
<item jid='juliet@example.com'
subscription='none'/>
</query>
</iq>
The user's server MUST also deliver the inbound presence stanzas of type "unavailable".
用户的服务器还必须提供“不可用”类型的入站状态节。
Implementation Note: If the user's account has no available resources when the inbound unsubscribed notification is received, the user's server MAY keep a record of the notification (ideally the complete presence stanza) and then deliver the notification when the account next has an available resource. This behavior provides more complete signaling to the user regarding the reasons for the roster change that occurred while the user was offline.
实施说明：如果在接收到入站取消订阅通知时，用户的帐户没有可用资源，则用户的服务器可能会保留通知记录（理想情况下是完整的状态节），然后在帐户下一个有可用资源时发送通知。此行为向用户提供有关用户脱机时发生的花名册更改原因的更完整的信号。
Otherwise -- that is, if the user does not exist, if the contact is not in the user's roster, or if the contact is in the user's roster with a subscription state other than those described in the foregoing check -- then the user's server MUST silently ignore the unsubscribed notification by not delivering it to the user, not modifying the user's roster, and not generating a roster push to the user's interested resources.
否则——也就是说，如果用户不存在，如果联系人不在用户名册中，或者如果联系人在用户名册中的订阅状态与上述检查中所述的状态不同——那么用户服务器必须通过不向用户发送取消订阅的通知来默默地忽略该通知，不修改用户的花名册，也不生成花名册推送到用户感兴趣的资源。
If a user would like to unsubscribe from a contact's presence, it sends a presence stanza of type "unsubscribe".
如果用户想要取消订阅联系人的状态，它会发送一个类型为“unsubscribe”的状态节。
UC: <presence id='ul4bs71n'
to='juliet@example.com'
type='unsubscribe'/>
UC: <presence id='ul4bs71n'
to='juliet@example.com'
type='unsubscribe'/>
Upon receiving the outbound unsubscribe, the user's server MUST proceed as follows.
收到出站取消订阅后，用户的服务器必须按以下步骤进行。
1. If the contact is hosted on the same server as the user, then the server MUST adhere to the rules specified under Section 3.3.3 when processing the subscription request.
1. 如果联系人与用户位于同一服务器上，则服务器在处理订阅请求时必须遵守第3.3.3节中指定的规则。
2. If the contact is hosted on a remote server, subject to local service policies the user's server MUST then route the stanza to that remote domain in accordance with core XMPP stanza processing rules. (This can result in returning an appropriate stanza error to the user, such as <remote-server-timeout/>.)
2. 如果联系人托管在远程服务器上，则根据本地服务策略，用户服务器必须根据核心XMPP节处理规则将节路由到该远程域。（这可能会导致向用户返回适当的节错误，例如<remote server timeout/>。）
As mentioned, before locally delivering or remotely routing the unsubscribe, the user's server MUST stamp the stanza with the bare JID <user@domainpart> of the user.
如前所述，在本地交付或远程路由取消订阅之前，用户的服务器必须在节上标记裸JID<user@domainpart>用户的名称。
US: <presence from='romeo@example.net'
id='ul4bs71n'
to='juliet@example.com'
type='unsubscribe'/>
US: <presence from='romeo@example.net'
id='ul4bs71n'
to='juliet@example.com'
type='unsubscribe'/>
The user's server then MUST send a roster push with the updated roster item to all of the user's interested resources, where the subscription state is now either "none" or "from" (see Appendix A).
然后，用户的服务器必须向用户感兴趣的所有资源发送带有更新花名册项目的花名册推送，其中订阅状态现在为“无”或“来自”（参见附录a）。
US: <iq id='h37h3u1bv402'
to='romeo@example.net/foo'
type='set'>
<query xmlns='jabber:iq:roster'>
<item jid='juliet@example.com'
subscription='none'/>
</query>
</iq>
US: <iq id='h37h3u1bv402'
to='romeo@example.net/foo'
type='set'>
<query xmlns='jabber:iq:roster'>
<item jid='juliet@example.com'
subscription='none'/>
</query>
</iq>
US: <iq to='romeo@example.net/bar'
type='set'
id='h37h3u1bv403'>
<query xmlns='jabber:iq:roster'>
<item jid='juliet@example.com'
subscription='none'/>
</query>
</iq>
US: <iq to='romeo@example.net/bar'
type='set'
id='h37h3u1bv403'>
<query xmlns='jabber:iq:roster'>
<item jid='juliet@example.com'
subscription='none'/>
</query>
</iq>
When the contact's server receives the unsubscribe notification, it MUST first check if the user's bare JID is in the contact's roster with subscription='from' or subscription='both' (i.e., a subscription state of "From", "From + Pending Out", or "Both"; see Appendix A). If this check is successful, then the contact's server MUST:
当联系人的服务器收到取消订阅通知时，它必须首先检查用户的裸JID是否在联系人的名册中，subscription='from'或subscription='both'（即订阅状态为“from”、“from+Pending Out”或“both”；见附录a）。如果此检查成功，则联系人的服务器必须：
1. Deliver the inbound unsubscribe to all of the contact's interested resources (this helps to give the contact's client(s) proper context regarding the unsubscribe so that they can differentiate between a roster push originated by another of the contact's resources and an unsubscribe received from the user). This MUST occur before sending the roster push described in the next step.
1. 将入站取消订阅传递给联系人的所有感兴趣的资源（这有助于为联系人的客户端提供有关取消订阅的适当上下文，以便他们能够区分由联系人的另一个资源发起的花名册推送和从用户收到的取消订阅）。这必须在发送下一步中描述的花名册推送之前发生。
CS: <presence from='romeo@example.net'
id='ul4bs71n'
to='juliet@example.com'
type='unsubscribe'/>
CS: <presence from='romeo@example.net'
id='ul4bs71n'
to='juliet@example.com'
type='unsubscribe'/>
2. Initiate a roster push to all of the contact's interested resources, containing an updated roster item for the user with the 'subscription' attribute set to a value of "none" (if the subscription state was "From" or "From + Pending Out") or "to" (if the subscription state was "Both").
2. 启动对联系人所有感兴趣资源的花名册推送，其中包含用户的更新花名册项目，其“订阅”属性设置为“无”（如果订阅状态为“从”或“从+挂起”）或“到”（如果订阅状态为“两者”）。
CS: <iq id='tn2b5893g1s4'
to='juliet@example.com/balcony'
type='set'>
<query xmlns='jabber:iq:roster'>
<item jid='romeo@example.net'
subscription='none'/>
</query>
</iq>
CS: <iq id='tn2b5893g1s4'
to='juliet@example.com/balcony'
type='set'>
<query xmlns='jabber:iq:roster'>
<item jid='romeo@example.net'
subscription='none'/>
</query>
</iq>
CS: <iq id='sp3b56n27hrp'
to='juliet@example.com/chamber'
type='set'>
<query xmlns='jabber:iq:roster'>
<item jid='romeo@example.net'
subscription='none'/>
</query>
</iq>
CS: <iq id='sp3b56n27hrp'
to='juliet@example.com/chamber'
type='set'>
<query xmlns='jabber:iq:roster'>
<item jid='romeo@example.net'
subscription='none'/>
</query>
</iq>
3. Generate an outbound presence stanza of type "unavailable" from each of the contact's available resources to the user.
3. 从联系人的每个可用资源向用户生成类型为“不可用”的出站状态节。
CS: <presence from='juliet@example.com/balcony'
id='o5v91w49'
to='romeo@example.net'
type='unavailable'/>
CS: <presence from='juliet@example.com/balcony'
id='o5v91w49'
to='romeo@example.net'
type='unavailable'/>
CS: <presence from='juliet@example.com/chamber'
id='n6b1c37k'
to='romeo@example.net'
type='unavailable'/>
CS: <presence from='juliet@example.com/chamber'
id='n6b1c37k'
to='romeo@example.net'
type='unavailable'/>
Implementation Note: If the contact's account has no available resources when the inbound unsubscribe notification is received, the contact's server MAY keep a record of the notification (ideally the complete presence stanza) and then deliver the notification when the account next has an available resource. This behavior provides more complete signaling to the user regarding the reasons for the roster change that occurred while the user was offline.
实施说明：如果收到入站取消订阅通知时联系人的帐户没有可用资源，则联系人的服务器可能会保留通知记录（理想情况下是完整的状态节），然后在帐户下一个有可用资源时发送通知。此行为向用户提供有关用户脱机时发生的花名册更改原因的更完整的信号。
Otherwise -- that is, if the contact does not exist, if the user is not in the contact's roster, or if the user's bare JID is in the contact's roster with a subscription state other than those described in the foregoing check -- then the contact's server MUST silently ignore the unsubscribe stanza by not delivering it to the contact, not modifying the contact's roster, and not generating a roster push to the contact's interested resources. However, if the contact's server is keeping track of an inbound presence subscription request
否则——也就是说，如果联系人不存在，如果用户不在联系人的花名册中，或者如果用户的裸JID在联系人的花名册中，并且订阅状态与上述检查中所述的状态不同——那么联系人的服务器必须通过不将其发送给联系人而静默地忽略取消订阅节，不修改联系人的花名册，也不生成对联系人感兴趣的资源的花名册推送。但是，如果联系人的服务器正在跟踪入站状态订阅请求
from the user to the contact but the user is not yet in the contact's roster (functionally equivalent to a subscription state of "None + Pending In" where the contact never added the user to the contact's roster), then the contact's server MUST simply remove any record of the inbound presence subscription request (it cannot remove the user from the contact's roster because the user was never added to the contact's roster).
从用户到联系人，但用户还不在联系人的花名册中（功能上相当于订阅状态为“无+待定”，其中联系人从未将用户添加到联系人的花名册中），那么联系人的服务器必须简单地删除入站状态订阅请求的任何记录（它无法从联系人的花名册中删除该用户，因为该用户从未添加到联系人的花名册中）。
Implementation Note: The user's client MUST NOT depend on receiving the unavailable presence notification from the contact, since it MUST consider its presence subscription to the contact, and its presence information about the contact, to be null and void when it sends the presence stanza of type "unsubscribe" or when it receives the roster push triggered by the unsubscribe request.
实现注意事项：用户的客户端不能依赖于从联系人接收不可用的存在通知，因为它必须考虑它的存在对联系人的订阅，以及其关于联系人的存在信息，当发送“取消订阅”的存在节时，它是无效的。或者当它收到由取消订阅请求触发的花名册推送时。
If a user has not received a subscription request from a contact, the user can "pre-approve" such a request so that it will be automatically approved by the user's server.
如果用户尚未收到来自联系人的订阅请求，则用户可以“预批准”此类请求，以便用户的服务器自动批准该请求。
Support for subscription pre-approvals is OPTIONAL on the part of clients and servers. If a server supports subscription pre-approvals, then it MUST advertise the following stream feature during stream negotiation.
客户端和服务器对订阅预批准的支持是可选的。如果服务器支持订阅预批准，则必须在流协商期间公布以下流功能。
<sub xmlns='urn:xmpp:features:pre-approval'/>
<sub xmlns='urn:xmpp:features:pre-approval'/>
The subscription pre-approval stream feature is merely informative and therefore is never mandatory-to-negotiate.
订阅预批准流功能仅提供信息，因此不强制协商。
If the server to which a client connects has advertised support for subscription pre-approvals, the client MAY generate a subscription pre-approval by sending a presence stanza of type "subscribed" to the contact.
如果客户端所连接的服务器已公布对订阅预批准的支持，则客户端可通过向联系人发送类型为“subscribed”的状态节来生成订阅预批准。
UC: <presence id='pg81vx64'
to='juliet@example.com'
type='subscribed'/>
UC: <presence id='pg81vx64'
to='juliet@example.com'
type='subscribed'/>
If the server does not advertise support for subscription pre-approvals, the client MUST NOT attempt to pre-approve subscription requests from potential or actual contacts.
如果服务器未公布对订阅预批准的支持，则客户端不得尝试预批准潜在或实际联系人的订阅请求。
Upon receiving the presence stanza of type "subscribed", the user's server MUST proceed as follows if it supports subscription pre-approvals.
收到类型为“subscribed”的状态节后，如果用户的服务器支持订阅预批准，则必须按照以下步骤进行操作。
1. If the contact is in the user's roster with a state of "Both", "From", or "From + Pending Out", the user's server MUST silently ignore the stanza.
1. 如果联系人在用户的花名册中，状态为“两者”、“发件人”或“发件人+待定”，则用户的服务器必须默默地忽略该节。
2. If the contact is in the user's roster with a state of "To + Pending In", "None + Pending In", or "None + Pending Out+In", the user's server MUST handle the stanza as a normal subscription approval (see under Section 3.1.5) by updating the existing roster item to a state of "Both", "From", or "From + Pending Out" (respectively), pushing the modified roster item to all of the user's interested resources, and routing the presence stanza of type "subscribed" to the contact.
2. 如果联系人在用户名册中的状态为“To+待决in”、“None+待决in”或“None+待决Out+in”，则用户服务器必须通过将现有名册项目更新为“两者”、“From”或“From+待决Out”（分别）的状态，将该节处理为正常订阅批准（见第3.1.5节），将修改后的花名册项目推送到用户感兴趣的所有资源，并将类型为“subscribed”的状态节路由到联系人。
3. If the contact is in the user's roster with a state of "To", "None", or "None + Pending Out", the user's server MUST note the subscription pre-approval by setting the 'approved' flag to a value of "true", then push the modified roster item to all of the user's interested resources. However, the user's server MUST NOT route the presence stanza of type "subscribed" to the contact.
3. 如果联系人在用户名册中的状态为“至”、“无”或“无+待决”，则用户服务器必须通过将“已批准”标志设置为“真”值来记录订阅预批准，然后将修改后的名册项目推送到用户感兴趣的所有资源。但是，用户的服务器不得将类型为“subscribed”的状态节路由到联系人。
4. If the contact is not yet in the user's roster, the user's server MUST create a roster item for the contact with a state of "None" and set the 'approved' flag to a value of "true", then push the roster item to all of the user's interested resources. However, the user's server MUST NOT route the presence stanza of type "subscribed" to the contact.
4. 如果联系人尚未在用户的花名册中，则用户服务器必须为联系人创建一个状态为“无”的花名册项目，并将“已批准”标志设置为值“真”，然后将花名册项目推送到用户感兴趣的所有资源。但是，用户的服务器不得将类型为“subscribed”的状态节路由到联系人。
An example of the roster push follows.
下面是花名册推送的一个例子。
US: <iq id='h3bs81vs763f'
to='romeo@example.net/bar'
type='set'>
<query xmlns='jabber:iq:roster'>
<item approved='true'
jid='juliet@example.com'
subscription='none'/>
</query>
</iq>
US: <iq id='h3bs81vs763f'
to='romeo@example.net/bar'
type='set'>
<query xmlns='jabber:iq:roster'>
<item approved='true'
jid='juliet@example.com'
subscription='none'/>
</query>
</iq>
When the 'approved' flag is set to "true", the user's server MUST NOT deliver a presence stanza of type "subscribe" from the contact to the user, but instead MUST automatically respond to such a stanza on
当“approved”标志设置为“true”时，用户服务器不得将联系人发送给用户的“subscribe”类型的状态节，而是必须在
behalf of the user by returning a presence stanza of type "subscribed" from the bare JID of the user to the bare JID of the contact.
通过从用户的裸JID向联系人的裸JID返回类型为“subscribed”的状态节来代表用户。
Implementation Note: It is a matter of implementation or local service policy whether the server maintains a record of the subscription approval after it has received a presence subscription request from the contact. If the server does not maintain such a record, upon receiving the subscription request it will not include the 'approved' attribute in the roster item for the contact (i.e., in subsequent roster pushes and roster results). If the server maintains such a record, it will always include the 'approved' attribute (set to "true") in the roster item for the contact, until and unless the user sends a presence stanza of type "unsubscribed" to the contact (or removes the contact from the roster entirely).
实施说明：服务器在收到联系人的状态订阅请求后是否保留订阅批准记录是实施或本地服务策略的问题。如果服务器未维护此类记录，则在收到订阅请求后，服务器将不会在联系人的花名册项目中包含“已批准”属性（即，在后续花名册推送和花名册结果中）。如果服务器维护这样的记录，它将始终在联系人的花名册项目中包含“approved”属性（设置为“true”），直到并且除非用户向联系人发送类型为“unsubscribed”的状态节（或者从花名册中完全删除联系人）。
Implementation Note: A client can cancel a pre-approval by sending a presence stanza of type "unsubscribed", as described more fully under Section 3.2. In this case, the user's server would send a roster push to all of the user's interested resources with the 'approved' attribute removed. (Alternatively, the client can simply remove the roster item entirely.)
实施说明：客户可以通过发送类型为“unsubscribed”的状态节取消预批准，如第3.2节所述。在这种情况下，用户的服务器将向用户感兴趣的所有资源发送一个花名册推送，删除“approved”属性。（或者，客户可以简单地完全删除花名册项目。）
The concept of presence refers to an entity's availability for communication over a network. At the most basic level, presence is a boolean "on/off" variable that signals whether an entity is available or unavailable for communication (the terms "online" and "offline" are also used). In XMPP, an entity's availability is signaled when its client generates a <presence/> stanza with no 'type' attribute, and an entity's lack of availability is signaled when its client generates a <presence/> stanza whose 'type' attribute has a value of "unavailable".
存在的概念是指实体通过网络进行通信的可用性。在最基本的层面上，presence是一个布尔“开/关”变量，表示实体是否可用于通信（也使用术语“在线”和“离线”）。在XMPP中，当一个实体的客户机生成一个没有“type”属性的<presence/>节时，该实体的可用性被通知；当一个实体的客户机生成一个“type”属性值为“unavailable”的<presence/>节时，该实体的可用性被通知。
XMPP presence typically follows a "publish-subscribe" or "observer" pattern, wherein an entity sends presence to its server, and its server then broadcasts that information to all of the entity's contacts who have a subscription to the entity's presence (in the terminology of [IMP-MODEL], an entity that generates presence is a "presentity" and the entities that receive presence are "subscribers"). A client generates presence for broadcast to all subscribed entities by sending a presence stanza to its server with no 'to' address, where the presence stanza has either no 'type' attribute or a 'type' attribute whose value is "unavailable". This
XMPP状态通常遵循“发布-订阅”或“观察者”模式，其中实体将状态发送到其服务器，然后其服务器将该信息广播给订阅该实体状态的所有实体联系人（用[IMP-MODEL]术语），生成状态的实体为“状态实体”接收存在的实体是“订阅者”）。客户端通过向其服务器发送不带“收件人”地址的状态节来生成状态，以便广播到所有订阅的实体，其中状态节没有“类型”属性或“类型”属性的值为“不可用”。这
kind of presence is called "broadcast presence". (A client can also send "directed presence", i.e., a presence stanza with a 'to' address; this is less common but is sometimes used to send presence to entities that are not subscribed to the user's presence; see Section 4.6.)
这种存在被称为“广播存在”。（客户端还可以发送“定向状态”，即带有“收件人”地址的状态节；这不太常见，但有时用于向未订阅用户状态的实体发送状态；请参见第4.6节。）
After a client completes the preconditions specified in [XMPP-CORE], it can establish a "presence session" at its server by sending initial presence (Section 4.2), where the presence session is terminated by sending unavailable presence (Section 4.5). For the duration of its presence session, a connected resource (in the terminology of [XMPP-CORE]) is said to be an "available resource".
客户机完成[XMPP-CORE]中规定的前提条件后，可以通过发送初始状态（第4.2节）在其服务器上建立“状态会话”，其中状态会话通过发送不可用状态（第4.5节）终止。在存在会话期间，连接的资源（用[XMPP-CORE]术语）被称为“可用资源”。
In XMPP, applications that combine messaging and presence functionality, the default type of communication for which presence signals availability is messaging; however, it is not necessary for XMPP applications to combine messaging and presence functionality, and they can provide standalone presence features without messaging (in addition, XMPP servers do not require information about network availability in order to successfully route message and IQ stanzas).
在XMPP中，结合了消息传递和状态功能的应用程序，状态信号可用性是消息传递的默认通信类型；但是，XMPP应用程序没有必要将消息传递和状态功能结合起来，它们可以提供独立的状态功能而不需要消息传递（此外，XMPP服务器不需要有关网络可用性的信息来成功路由消息和IQ节）。
Informational Note: In the examples that follow, the user is <juliet@example.com>, she has two available resources ("balcony" and "chamber"), and she has three contacts in her roster with a subscription state of "from" or "both": <romeo@example.net>, <mercutio@example.com>, and <benvolio@example.net>.
信息性说明：在下面的示例中，用户是<juliet@example.com>，她有两个可用资源（“阳台”和“房间”），她的名册中有三个联系人，订阅状态为“从”或“两者”：<romeo@example.net>, <mercutio@example.com>，及<benvolio@example.net>.
After completing the preconditions described in [XMPP-CORE] (REQUIRED) and requesting the roster (RECOMMENDED), a client signals its availability for communication by sending "initial presence" to its server, i.e., a presence stanza with no 'to' address (indicating that it is meant to be broadcast by the server on behalf of the client) and no 'type' attribute (indicating the user's availability).
在完成[XMPP-CORE]（必需）中所述的先决条件并请求名册（推荐）后，客户机通过向其服务器发送“初始状态”来表示其通信可用性，即，没有“到”地址的状态节（表示该状态节将由服务器代表客户机广播）并且没有“type”属性（表示用户的可用性）。
UC: <presence/>
UC: <presence/>
The initial presence stanza MAY contain the <priority/> element, the <show/> element, and one or more instances of the <status/> element, as well as extended content; details are provided under Section 4.7.
初始存在节可以包含<priority/>元素、<show/>元素和<status/>元素的一个或多个实例以及扩展内容；详情见第4.7节。
Upon receiving initial presence from a client, the user's server MUST send the initial presence stanza from the full JID <user@domainpart/resourcepart> of the user to all contacts that are subscribed to the user's presence; 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".
从客户端接收初始状态时，用户的服务器必须从完整JID发送初始状态节<user@domainpart/将用户的resourcepart>添加到订阅用户状态的所有联系人；此类联系人是指用户名册中存在JID且“订阅”属性设置为“自”或“两者”的联系人。
US: <presence from='juliet@example.com/balcony'
to='romeo@example.net'/>
US: <presence from='juliet@example.com/balcony'
to='romeo@example.net'/>
US: <presence from='juliet@example.com/balcony'
to='mercutio@example.com'/>
US: <presence from='juliet@example.com/balcony'
to='mercutio@example.com'/>
US: <presence from='juliet@example.com/balcony'
to='benvolio@example.net'/>
US: <presence from='juliet@example.com/balcony'
to='benvolio@example.net'/>
The user's server MUST also broadcast initial presence from the user's newly available resource to all of the user's available resources, including the resource that generated the presence notification in the first place (i.e., an entity is implicitly subscribed to its own presence).
用户的服务器还必须将初始存在从用户的新可用资源广播到用户的所有可用资源，包括首先生成存在通知的资源（即，实体隐式订阅其自身存在）。
[... to the "balcony" resource ...]
[…到“阳台”资源…]
US: <presence from='juliet@example.com/balcony'
to='juliet@example.com'/>
US: <presence from='juliet@example.com/balcony'
to='juliet@example.com'/>
[... to the "chamber" resource ...]
[…到“商会”资源…]
US: <presence from='juliet@example.com/balcony'
to='juliet@example.com'/>
US: <presence from='juliet@example.com/balcony'
to='juliet@example.com'/>
In the absence of presence information about the user's contacts, the user's server MUST also send presence probes to the user's contacts on behalf of the user as specified under Section 4.3.
如果没有关于用户联系人的状态信息，用户服务器还必须按照第4.3节的规定代表用户向用户联系人发送状态探测。
Upon receiving presence from the user, the contact's server MUST deliver the user's presence stanza to all of the contact's available resources.
收到用户的状态信息后，联系人的服务器必须将用户的状态信息节传递给联系人的所有可用资源。
[ ... to resource1 ... ]
[…到资源1…]
CS: <presence from='juliet@example.com/balcony'
to='romeo@example.net'/>
CS: <presence from='juliet@example.com/balcony'
to='romeo@example.net'/>
[ ... to resource2 ... ]
[…到资源2…]
CS: <presence from='juliet@example.com/balcony'
to='romeo@example.net'/>
CS: <presence from='juliet@example.com/balcony'
to='romeo@example.net'/>
When the contact's client receives presence from the user, the following behavior is suggested for interactive clients:
当联系人的客户端接收到来自用户的状态时，建议交互式客户端执行以下行为：
1. If the user's bare JID is in the contact's roster, display the presence information in an appropriate roster interface.
1. 如果用户的裸JID在联系人的花名册中，则在适当的花名册界面中显示状态信息。
2. If the user is not in the contact's roster but the contact and the user are actively exchanging message or IQ stanzas, display the presence information in the user interface for that communication session (see also Section 4.6 and Section 5.1).
2. 如果用户不在联系人名册中，但联系人和用户正在积极交换信息或IQ节，则在该通信会话的用户界面中显示状态信息（另请参见第4.6节和第5.1节）。
3. Otherwise, ignore the presence information and do not display it to the contact.
3. 否则，请忽略状态信息，不要将其显示给联系人。
A "presence probe" is a request for a contact's current presence information, sent on behalf of a user by the user's server; syntactically it is a presence stanza whose 'type' attribute has a value of "probe". In the context of presence subscriptions, the value of the 'from' address MUST be the bare JID of the subscribed user and the value of the 'to' address MUST be the bare JID of the contact to which the user is subscribed, since presence subscriptions are based on the bare JID.
“状态探测”是由用户的服务器代表用户发送的对联系人当前状态信息的请求；从语法上讲，它是一个presence节，其“type”属性的值为“probe”。在状态订阅的上下文中，“发件人”地址的值必须是订阅用户的裸JID，“收件人”地址的值必须是用户订阅的联系人的裸JID，因为状态订阅基于裸JID。
US: <presence from='juliet@example.com'
id='ign291v5'
to='romeo@example.net'
type='probe'/>
US: <presence from='juliet@example.com'
id='ign291v5'
to='romeo@example.net'
type='probe'/>
Interoperability Note: RFC 3921 specified that probes are sent from the full JID, not the bare JID (a rule that was changed because subscriptions are based on the bare JID). Some existing implementations send from the full JID instead of the bare JID.
互操作性说明：RFC 3921指定从完整JID而不是裸JID发送探测（由于订阅基于裸JID，所以更改了该规则）。一些现有实现从完整JID而不是裸JID发送数据。
Probes can also be sent by an entity that has received presence outside the context of a presence subscription, typically when the contact has sent directed presence as described under Section 4.6; in this case the value of the 'from' or 'to' address can be a full JID instead of a bare JID. See Section 4.6 for a complete discussion.
探测器也可以由在状态订阅上下文之外接收到状态的实体发送，通常是当联系人发送了第4.6节所述的定向状态时；在这种情况下，“from”或“to”地址的值可以是完整JID，而不是裸JID。完整的讨论见第4.6节。
Presence probes SHOULD NOT be sent by a client, because in general a client will not need to send them since the task of gathering presence from a user's contacts is managed by the user's server. However, if a user's client generates an outbound presence probe then the user's server SHOULD route the probe (if the contact is at another server) or process the probe (if the contact is at the same server) and MUST NOT use its receipt of the presence probe from a connected client as the sole cause for returning a stanza or stream error to the client.
状态探测不应由客户端发送，因为通常客户端不需要发送它们，因为从用户联系人收集状态的任务由用户的服务器管理。但是，如果用户的客户端生成出站状态探测，则用户的服务器应路由探测（如果联系人在另一台服务器上）或处理探测（如果联系人在同一台服务器上）并且不得将其从连接的客户端接收到的状态探测作为向客户端返回节或流错误的唯一原因。
When a server needs to discover the availability of a user's contact, it sends a presence probe from the bare JID <user@domainpart> of the user to the bare JID <contact@domainpart> of the contact.
当服务器需要发现用户联系人的可用性时，它会从裸JID发送状态探测<user@domainpart>将用户添加到裸JID<contact@domainpart>联系方式。
Implementation Note: Although presence probes are intended for sending to contacts (i.e., entities to which a user is subscribed), a server MAY send a presence probe to the full JID of an entity from which the user has received presence information during the current session.
实施说明：尽管状态探测旨在发送给联系人（即用户订阅的实体），但服务器可以向用户在当前会话期间从中接收到状态信息的实体的完整JID发送状态探测。
The user's server SHOULD send a presence probe whenever the user starts a new presence session by sending initial presence; however, the server MAY choose not to send the probe at that point if it has what it deems to be reliable and up-to-date presence information about the user's contacts (e.g., because the user has another available resource or because the user briefly logged off and on before the new presence session began). In addition, a server MAY periodically send a presence probe to a contact if it has not received presence information or other traffic from the contact in some configurable amount of time; this can help to prevent "ghost" contacts who appear to be online but in fact are not.
每当用户通过发送初始状态启动新的状态会话时，用户的服务器应发送状态探测；但是，如果服务器具有其认为可靠的、关于用户联系人的最新状态信息（例如，因为用户有另一个可用资源，或者因为用户在新的状态会话开始之前短暂注销和登录），则服务器可以选择在该点不发送探测器。此外，如果服务器在某个可配置的时间量内没有从联系人接收到存在信息或其他通信量，则服务器可以周期性地向联系人发送存在探测；这有助于防止那些看似在线但实际上不在线的“幽灵”联系人。
US: <presence from='juliet@example.com'
id='ign291v5'
to='romeo@example.net'
type='probe'/>
US: <presence from='juliet@example.com'
id='ign291v5'
to='romeo@example.net'
type='probe'/>
US: <presence from='juliet@example.com'
id='xv291f38'
to='mercutio@example.com'
type='probe'/>
US: <presence from='juliet@example.com'
id='xv291f38'
to='mercutio@example.com'
type='probe'/>
Naturally, the user's server does not need to send a presence probe to a contact if the contact's account resides on the same server as the user, since the server possesses the contact's information locally.
当然，如果联系人的帐户与用户位于同一服务器上，则用户的服务器不需要向联系人发送状态探测，因为服务器在本地拥有联系人的信息。
Upon receiving a presence probe to the contact's bare JID from the user's server on behalf of the user, the contact's server MUST reply as follows:
在代表用户从用户服务器接收到对联系人裸JID的状态探测后，联系人服务器必须回复如下：
1. If the contact account does not exist or the user's bare JID is in the contact's roster with a subscription state other than "From", "From + Pending Out", or "Both" (as explained under Appendix A), then the contact's server SHOULD return a presence stanza of type "unsubscribed" in response to the presence probe (this will trigger a protocol flow for canceling the user's subscription to the contact as described under Section 3.2; however, this MUST NOT result in cancellation of a subscription pre-approval as described under Section 3.4). Here the 'from' address MUST be the bare JID of the contact, since specifying a full JID would constitute a presence leak as described in [XMPP-CORE].
1. 如果联系人帐户不存在，或者用户的裸JID在联系人名册中，订阅状态不是“从”、“从+挂起”或“两者”（如附录a所述），则联系人的服务器应返回类型为“未订阅”的状态节，以响应状态探测（如第3.2节所述，这将触发取消用户对联系人订阅的协议流；但是，这不得导致如第3.4节所述取消订阅预批准）。此处的“发件人”地址必须是联系人的裸JID，因为指定完整JID将构成[XMPP-CORE]中所述的存在泄漏。
CS: <presence from='mercutio@example.com'
id='xv291f38'
to='juliet@example.com'
type='unsubscribed'/>
CS: <presence from='mercutio@example.com'
id='xv291f38'
to='juliet@example.com'
type='unsubscribed'/>
However, if a server receives a presence probe from a configured domain of the server itself or another such trusted service, it MAY provide presence information about the user to that entity.
然而，如果服务器从服务器本身的配置域或另一个这样的可信服务接收到存在探测，则它可以向该实体提供关于用户的存在信息。
2. Else, if the contact has moved temporarily or permanently to another address, then the server SHOULD return a presence stanza of type "error" with a stanza error condition of <redirect/> (temporary) or <gone/> (permanent) that includes the new address of the contact.
2. 否则，如果联系人临时或永久移动到另一个地址，则服务器应返回类型为“error”的状态节，其中节错误条件为<redirect/>（临时）或<gone/>（永久），其中包括联系人的新地址。
CS: <presence from='mercutio@example.com'
id='xv291f38'
to='juliet@example.com'
type='error'>
<error type='modify'>
<gone xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'>
xmpp:la-mer@example.com
</gone>
</error>
</presence>
CS: <presence from='mercutio@example.com'
id='xv291f38'
to='juliet@example.com'
type='error'>
<error type='modify'>
<gone xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'>
xmpp:la-mer@example.com
</gone>
</error>
</presence>
3. Else, if the contact has no available resources, then the server SHOULD reply to the presence probe by sending to the user a presence stanza of type "unavailable" (although sending
3. 否则，如果联系人没有可用的资源，则服务器应通过向用户发送类型为“不可用”的状态节（尽管发送
unavailable presence here is preferable because it results in a deterministic answer to the probe, it is not mandatory because it can greatly increase the number of presence notifications generated by the contact's server). Here the 'from' address is the bare JID because there is no available resource associated with the contact. If appropriate in accordance with local security policies this presence notification MAY include the full XML of the last unavailable presence stanza that the server received from the contact (including the 'id' of the original stanza), but if not then the presence notification SHOULD simply indicate that the contact is unavailable without any of the details originally provided. In any case, the presence notification returned to the probing entity SHOULD include information about the time when the last unavailable presence stanza was generated (formatted using the XMPP delayed delivery extension [DELAY]).
此处的不可用状态更可取，因为它会导致对探测的确定性回答，而不是强制性的，因为它会大大增加联系人服务器生成的状态通知的数量）。这里的“发件人”地址是裸JID，因为没有与联系人关联的可用资源。根据本地安全策略，如果合适，此状态通知可能包括服务器从联系人处收到的最后一个不可用状态节的完整XML（包括原始节的“id”），但如果没有，则状态通知应简单地指示联系人在没有最初提供的任何详细信息的情况下不可用。在任何情况下，返回到探测实体的状态通知都应该包括关于生成最后一个不可用状态节的时间的信息（使用XMPP延迟交付扩展[DELAY]格式化）。
CS: <presence from='mercutio@example.com'
id='xv291f38'
to='juliet@example.com'
type='unavailable'>
<delay xmlns='urn:xmpp:delay'
stamp='2002-09-10T23:41:07Z'/>
</presence>
CS: <presence from='mercutio@example.com'
id='xv291f38'
to='juliet@example.com'
type='unavailable'>
<delay xmlns='urn:xmpp:delay'
stamp='2002-09-10T23:41:07Z'/>
</presence>
4. Else, if the contact has at least one available resource, then 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. Here the 'from' addresses are the full JIDs of each available resource.
4. 否则，如果联系人至少有一个可用资源，则服务器必须通过向用户发送最后一个状态节的完整XML（不带“to”属性）来回复状态探测，服务器从联系人的每个可用资源接收到该XML。这里的“from”地址是每个可用资源的完整jid。
CS: <presence from='romeo@example.net/foo'
id='hzf1v27k'
to='juliet@example.com'/>
CS: <presence from='romeo@example.net/foo'
id='hzf1v27k'
to='juliet@example.com'/>
CS: <presence from='romeo@example.net/bar'
id='ps6t1fu3'
to='juliet@example.com'>
<show>away</show>
</presence>
CS: <presence from='romeo@example.net/bar'
id='ps6t1fu3'
to='juliet@example.com'>
<show>away</show>
</presence>
Implementation Note: By "full XML" is meant the complete stanza
from the opening <presence> tag to the closing </presence> tag,
including all elements and attributes whether qualified by the
content namespace or extended namespaces; however, in accordance
Implementation Note: By "full XML" is meant the complete stanza
from the opening <presence> tag to the closing </presence> tag,
including all elements and attributes whether qualified by the
content namespace or extended namespaces; however, in accordance
with [XMPP-CORE], the contact's server will need to transform the content namespace from 'jabber:client' to 'jabber:server' if it sends the complete stanza over a server-to-server stream.
使用[XMPP-CORE]，如果联系人的服务器通过服务器到服务器流发送完整的节，则需要将内容命名空间从“jabber:client”转换为“jabber:server”。
If the contact's server receives a presence probe addressed to a full JID of the contact, the server MUST NOT return presence information about any resource except the resource specified by the 'to' address of the probe. Rules #1 and #2 for a bare JID probe apply equally to the case of a full JID probe. If there is a resource matching the full JID and the probing entity has authorization via a presence subscription to see the contact's presence, then the server MUST return an available presence notification, which SHOULD communicate only the fact that the resource is available (not detailed information such as the <show/>, <status/>, <priority/>, or presence extensions).
如果联系人的服务器接收到地址为联系人完整JID的状态探测，则服务器不得返回任何资源的状态信息，但探测的“收件人”地址指定的资源除外。裸JID探测器的规则#1和#2同样适用于完整JID探测器的情况。如果存在与完整JID匹配的资源，并且探测实体通过状态订阅获得查看联系人状态的授权，则服务器必须返回可用状态通知，该通知应仅传达资源可用的事实（不是详细信息，如<show/>、<status/>、<priority/>或状态扩展）。
CS: <presence from='romeo@example.net/bar'
to='lobby@chat.example.com'/>
CS: <presence from='romeo@example.net/bar'
to='lobby@chat.example.com'/>
Implementation Note: See Section 4.6 regarding rules that supplement the foregoing for handling of directed presence.
实施说明：参见第4.6节，关于补充上述处理直接在场的规则。
The handling of the 'id' attribute in relation to presence probes was unspecified in RFC 3921. Although the pattern of "send a probe and receive a reply" might seem like a request-response protocol similar to the XMPP <iq/> stanza, in fact it is not because the response to a probe might consist of multiple presence stanzas (one for each available resource currently active for the contact). For this reason, if the contact currently has available resources then the contact's server SHOULD preserve the 'id' attribute of the contact's original presence stanza (if any) when sending those presence notifications to the probing entity. By contrast, if the contact currently has no available resources, the probing entity is not authorized (via presence subscription) to see the contact's presence, or an error occurs in relation to the probe, then the contact's server SHOULD mirror the 'id' of the user's presence probe when replying to the probing entity.
RFC 3921中未指定与状态探测相关的“id”属性的处理。尽管“发送探测并接收回复”的模式看起来像是一个请求-响应协议，类似于XMPP<iq/>节，但事实上并非如此，因为对探测的响应可能包含多个状态节（每个可用资源对应一个联系人）。因此，如果联系人当前有可用资源，则在向探测实体发送这些状态通知时，联系人的服务器应保留联系人原始状态节（如果有）的“id”属性。相比之下，如果联系人当前没有可用资源，探测实体未被授权（通过状态订阅）查看联系人的状态，或者探测发生错误，则联系人的服务器应在回复探测实体时镜像用户状态探测的“id”。
The following examples illustrate the difference.
下面的例子说明了这一区别。
In the first scenario, Juliet sends presence from her "chamber" resource.
在第一个场景中，朱丽叶从她的“密室”资源发送存在。
CC: <presence from='juliet@example.com/chamber' id='pres1'>
<show>dnd</show>
<status>busy!</status>
</presence>
CC: <presence from='juliet@example.com/chamber' id='pres1'>
<show>dnd</show>
<status>busy!</status>
</presence>
She also sends presence from her "balcony" resource.
她还从“阳台”资源发送出席信息。
CC: <presence from='juliet@example.com/balcony' id='pres2'>
<show>away</show>
<status>stepped away</status>
</presence>
CC: <presence from='juliet@example.com/balcony' id='pres2'>
<show>away</show>
<status>stepped away</status>
</presence>
Romeo's server then sends a probe to Juliet.
罗密欧的服务器随后向朱丽叶发送了一个探测器。
US: <presence from='romeo@example.net' id='probe1' type='probe'/>
US: <presence from='romeo@example.net' id='probe1' type='probe'/>
Juliet's server then sends both of her presence notifications to Romeo, preserving the 'id' attributes included in the stanzas that her client has sent.
朱丽叶的服务器会将她的两个状态通知发送给罗密欧，并保留客户发送的诗节中包含的“id”属性。
CS: <presence from='juliet@example.com/chamber' id='pres1'>
<show>dnd</show>
<status>busy!</status>
</presence>
CS: <presence from='juliet@example.com/chamber' id='pres1'>
<show>dnd</show>
<status>busy!</status>
</presence>
CS: <presence from='juliet@example.com/balcony' id='pres2'>
<show>away</show>
<status>stepped away</status>
</presence>
CS: <presence from='juliet@example.com/balcony' id='pres2'>
<show>away</show>
<status>stepped away</status>
</presence>
In the second scenario, Juliet is offline when Romeo's server sends a probe.
在第二个场景中，当罗密欧的服务器发送探测器时，朱丽叶离线。
US: <presence from='romeo@example.net'
id='probe2'
type='probe'/>
US: <presence from='romeo@example.net'
id='probe2'
type='probe'/>
Juliet's server replies with an unavailable notification, mirroring the 'id' of Rome's presence probe because there is no 'id' to preserve from an available notification that her client has sent.
Juliet的服务器以不可用的通知进行回复，镜像Rome的状态探测器的“id”，因为在其客户端发送的可用通知中没有要保留的“id”。
CS: <presence from='juliet@example.com'
id='probe2'
type='unavailable'/>
CS: <presence from='juliet@example.com'
id='probe2'
type='unavailable'/>
After sending initial presence, at any time during its session the user's client can update its availability for broadcast by sending a presence stanza with no 'to' address and no 'type' attribute.
发送初始状态后，在会话期间的任何时候，用户的客户端都可以通过发送不带“收件人”地址和“类型”属性的状态节来更新其广播可用性。
UC: <presence>
<show>away</show>
</presence>
UC: <presence>
<show>away</show>
</presence>
The presence broadcast MAY contain the <priority/> element, the <show/> element, and one or more instances of the <status/> element, as well as extended content; details are provided under Section 4.7.
存在广播可以包含<priority/>元素、<show/>元素和<status/>元素的一个或多个实例以及扩展内容；详情见第4.7节。
However, a user SHOULD send a presence update only to broadcast information that is relevant to the user's availability for communication or the communication capabilities of the resource. Information that is not relevant in this way might be of interest to the user's contacts but SHOULD be sent via other means, such as the "publish-subscribe" method described in [XEP-0163].
然而，用户应仅发送状态更新以广播与用户的通信可用性或资源的通信能力相关的信息。以这种方式不相关的信息可能会引起用户联系人的兴趣，但应通过其他方式发送，如[XEP-0163]中所述的“发布-订阅”方法。
Upon receiving a presence stanza expressing updated availability, the user's server MUST broadcast the full XML of that presence stanza to the contacts who are in the user's roster with a subscription type of "from" or "both".
在收到表示更新可用性的状态节后，用户服务器必须向用户名册中的联系人广播该状态节的完整XML，订阅类型为“发件人”或“双方”。
Interoperability Note: RFC 3921 specified that the user's server would check to make sure that it had not received a presence error from the contact before sending subsequent presence notifications. That rule has been removed because this specification uses presence stanzas of type "unsubscribe" (not "error") to solve subscription synchronization problems, in part because such stanzas change the contact's subscription state in the user's roster to either "none" or "to" (see Section 3.3 and Appendix A), thus obviating the need for the error check.
互操作性说明：RFC 3921指定用户的服务器在发送后续状态通知之前将进行检查，以确保未从联系人处收到状态错误。该规则已被删除，因为本规范使用“取消订阅”（而非“错误”）类型的状态节来解决订阅同步问题，部分原因是该节将用户名册中联系人的订阅状态更改为“无”或“至”（见第3.3节和附录A），因此，无需进行错误检查。
Interoperability Note: If the subscription type is "both", some existing server implementations send subsequent presence notifications to a contact only if the contact is online according to the user's server (that is, if the user's server never received a positive indication that the contact is online in response to the presence probe it sent to the contact, the user's server does not send subsequent presence notifications from the user to the
互操作性说明：如果订阅类型为“两者”，则某些现有服务器实现仅在联系人根据用户的服务器处于联机状态时才向联系人发送后续状态通知（也就是说，如果用户的服务器从未收到联系人在线的肯定指示以响应其发送给联系人的状态探测，则用户的服务器不会从用户向联系人发送后续的状态通知。）
contact). This behavior is perceived to save bandwidth, since most presence subscriptions are bidirectional and many contacts will not be online at any given time.
联系方式）。这种行为被认为是为了节省带宽，因为大多数状态订阅是双向的，并且许多联系人在任何给定时间都不会在线。
US: <presence from='juliet@example.com/balcony'
to='romeo@example.net'>
<show>away</show>
</presence>
US: <presence from='juliet@example.com/balcony'
to='romeo@example.net'>
<show>away</show>
</presence>
US: <presence from='juliet@example.com/balcony'
to='benvolio@example.net'>
<show>away</show>
</presence>
US: <presence from='juliet@example.com/balcony'
to='benvolio@example.net'>
<show>away</show>
</presence>
US: <presence from='juliet@example.com/balcony'
to='mercutio@example.com'>
<show>away</show>
</presence>
US: <presence from='juliet@example.com/balcony'
to='mercutio@example.com'>
<show>away</show>
</presence>
Implementation Note: See Section 4.6 regarding rules that supplement the foregoing for handling of directed presence.
实施说明：参见第4.6节，关于补充上述处理直接在场的规则。
The user's server MUST also send the presence stanza to all of the user's available resources (including the resource that generated the presence notification in the first place).
用户的服务器还必须将状态节发送到用户的所有可用资源（包括首先生成状态通知的资源）。
US: <presence from='juliet@example.com/balcony'
to='juliet@example.com/chamber'>
<show>away</show>
</presence>
US: <presence from='juliet@example.com/balcony'
to='juliet@example.com/chamber'>
<show>away</show>
</presence>
US: <presence from='juliet@example.com/balcony'
to='juliet@example.com/balcony'>
<show>away</show>
</presence>
US: <presence from='juliet@example.com/balcony'
to='juliet@example.com/balcony'>
<show>away</show>
</presence>
Upon receiving presence from the user, the contact's server MUST deliver the user's presence stanza to all of the contact's available resources.
收到用户的状态信息后，联系人的服务器必须将用户的状态信息节传递给联系人的所有可用资源。
[ ... to resource1 ... ]
[…到资源1…]
CS: <presence from='juliet@example.com/balcony'
to='romeo@example.net'>
<show>away</show>
</presence>
CS: <presence from='juliet@example.com/balcony'
to='romeo@example.net'>
<show>away</show>
</presence>
[ ... to resource2 ... ]
[…到资源2…]
CS: <presence from='juliet@example.com/balcony'
to='romeo@example.net'>
<show>away</show>
</presence>
CS: <presence from='juliet@example.com/balcony'
to='romeo@example.net'>
<show>away</show>
</presence>
From the perspective of the contact's client, there is no significant difference between initial presence broadcast and subsequent presence, so the contact's client follows the rules for processing of inbound presence defined under Section 4.4.3.
从联系人客户的角度来看，初始状态广播和后续状态之间没有显著差异，因此联系人客户遵循第4.4.3节中定义的入站状态处理规则。
Before ending its presence session with a server, the user's client SHOULD gracefully become unavailable by sending "unavailable presence", i.e., a presence stanza that possesses no 'to' attribute and that possesses a 'type' attribute whose value is "unavailable".
在结束与服务器的状态会话之前，用户的客户端应该通过发送“不可用状态”来正常地变得不可用，即，不具有“to”属性且具有值为“unavailable”的“type”属性的状态节。
UC: <presence type='unavailable'/>
UC: <presence type='unavailable'/>
Optionally, the unavailable presence stanza MAY contain one or more <status/> elements specifying the reason why the user is no longer available.
可选地，不可用状态节可以包含一个或多个<status/>元素，指定用户不再可用的原因。
UC: <presence type='unavailable'>
<status>going on vacation</status>
</presence>
UC: <presence type='unavailable'>
<status>going on vacation</status>
</presence>
However, the unavailable presence stanza MUST NOT contain the <priority/> element or the <show/> element, since these elements apply only to available resources.
但是，不可用状态节不能包含<priority/>元素或<show/>元素，因为这些元素仅适用于可用资源。
The user's server MUST NOT depend on receiving unavailable presence from an available resource, since the resource might become unavailable ungracefully (e.g., the resource's XML stream might be closed with or without a stream error for any of the reasons described in [XMPP-CORE]).
用户服务器不能依赖于从可用资源接收不可用状态，因为该资源可能会变得不可用（例如，由于[XMPP-CORE]中描述的任何原因，该资源的XML流可能关闭时出现流错误或没有流错误）。
If an available resource becomes unavailable for any reason (either gracefully or ungracefully), the user's server MUST broadcast unavailable presence to all contacts that are in the user's roster with a subscription type of "from" or "both".
如果可用资源因任何原因变得不可用（正常或不正常），则用户服务器必须向用户名册中订阅类型为“发件人”或“双方”的所有联系人广播不可用状态。
Interoperability Note: RFC 3921 specified that the user's server would check to make sure that it had not received a presence error from the contact before sending unavailable presence notifications. That rule has been removed because this specification uses presence stanzas of type "unsubscribe" (not "error") to solve subscription synchronization problems, in part because such stanzas change the contact's subscription state in the user's roster to either "none" or "to" (see Section 3.3 and Appendix A), thus obviating the need for the error check.
互操作性说明：RFC 3921指定用户的服务器在发送不可用状态通知之前将进行检查，以确保未从联系人处收到状态错误。该规则已被删除，因为本规范使用“取消订阅”（而非“错误”）类型的状态节来解决订阅同步问题，部分原因是该节将用户名册中联系人的订阅状态更改为“无”或“至”（见第3.3节和附录A），因此，无需进行错误检查。
Implementation Note: Even if the user's server does not broadcast the user's subsequent presence notifications to contacts who are offline (as described under Section 4.4.2), it MUST broadcast the user's unavailable presence notification; if it did not do so, the last presence received by the contact's server would be the user's initial presence for the presence session, with the result that the contact would consider the user to be online.
实施说明：即使用户服务器没有向离线联系人广播用户的后续状态通知（如第4.4.2节所述），也必须广播用户的不可用状态通知；如果没有这样做，则联系人服务器接收到的最后一个存在将是用户对存在会话的初始存在，结果该联系人将考虑用户在线。
Implementation Note: See Section 4.6 regarding rules that supplement the foregoing for handling of directed presence.
实施说明：参见第4.6节，关于补充上述处理直接在场的规则。
If the unavailable notification was gracefully received from the client, then the server MUST broadcast the full XML of the presence stanza.
如果从客户端正常接收到不可用通知，则服务器必须广播状态节的完整XML。
US: <presence from='juliet@example.com/balcony'
to='romeo@example.net'
type='unavailable'>
<status>going on vacation</status>
</presence>
US: <presence from='juliet@example.com/balcony'
to='romeo@example.net'
type='unavailable'>
<status>going on vacation</status>
</presence>
US: <presence from='juliet@example.com/balcony'
to='benvolio@example.net'
type='unavailable'>
<status>going on vacation</status>
</presence>
US: <presence from='juliet@example.com/balcony'
to='benvolio@example.net'
type='unavailable'>
<status>going on vacation</status>
</presence>
US: <presence from='juliet@example.com/balcony'
to='mercutio@example.com'
type='unavailable'>
<status>going on vacation</status>
</presence>
US: <presence from='juliet@example.com/balcony'
to='mercutio@example.com'
type='unavailable'>
<status>going on vacation</status>
</presence>
The user's server MUST also send the unavailable notification to all of the user's available resources (as well as to the resource that generated the unavailable presence in the first place).
用户的服务器还必须向用户的所有可用资源（以及首先生成不可用状态的资源）发送不可用通知。
US: <presence from='juliet@example.com/balcony'
to='juliet@example.com/chamber'
type='unavailable'>
<status>going on vacation</status>
</presence>
US: <presence from='juliet@example.com/balcony'
to='juliet@example.com/chamber'
type='unavailable'>
<status>going on vacation</status>
</presence>
If the server detects that the user has gone offline ungracefully, then the server MUST generate the unavailable presence broadcast on the user's behalf.
如果服务器检测到用户未正常脱机，则服务器必须代表用户生成不可用状态广播。
Implementation Note: Any presence stanza with no 'type' attribute and no 'to' attribute that the client sends after the server broadcasts or generates an unavailable presence notification MUST be routed or delivered by the user's server to all subscribers (i.e., MUST be treated as equivalent to initial presence for a new presence session).
实施说明：客户端在服务器广播或生成不可用状态通知后发送的任何不带“type”属性和“to”属性的状态节必须由用户服务器路由或交付给所有订阅者（即，必须被视为等同于新状态会话的初始状态）。
Upon receiving an unavailable notification from the user, the contact's server MUST deliver the user's presence stanza to all of the contact's available resources.
收到用户的不可用通知后，联系人的服务器必须将用户的状态节传递给联系人的所有可用资源。
[ ... to resource1 ... ]
[…到资源1…]
CS: <presence from='juliet@example.com/balcony'
to='romeo@example.net'
type='unavailable'>
<status>going on vacation</status>
</presence>
CS: <presence from='juliet@example.com/balcony'
to='romeo@example.net'
type='unavailable'>
<status>going on vacation</status>
</presence>
[ ... to resource2 ... ]
[…到资源2…]
CS: <presence from='juliet@example.com/balcony'
to='romeo@example.net'
type='unavailable'>
<status>going on vacation</status>
</presence>
CS: <presence from='juliet@example.com/balcony'
to='romeo@example.net'
type='unavailable'>
<status>going on vacation</status>
</presence>
Implementation Note: If the contact's server does not broadcast subsequent presence notifications to users who are offline (as described under Section 4.4.2), it MUST also update its internal representation of which entities are online by noting that the user is unavailable.
实施说明：如果联系人的服务器没有向离线用户广播后续状态通知（如第4.4.2节所述），则还必须通过注意用户不可用来更新其在线实体的内部表示。
From the perspective of the contact's client, there is no significant difference between available presence broadcast and unavailable presence broadcast, so in general the contact's client follows the rules for processing of inbound presence defined under Section 4.4.3.
从联系人客户的角度来看，可用状态广播和不可用状态广播之间没有显著差异，因此通常情况下，联系人客户遵循第4.4.3节中定义的入站状态处理规则。
However, if the contact receives an unavailable notification from the bare JID of the user (rather than the full JID of a particular available resource), the contact's client SHOULD treat the unavailable notification as applying to all resources.
但是，如果联系人从用户的裸JID（而不是特定可用资源的完整JID）收到不可用通知，则联系人的客户端应将不可用通知视为应用于所有资源。
This section supplements the rules for client and server processing of presence notifications and presence probes, but only for the special case of directed presence.
本节补充了客户端和服务器处理状态通知和状态探测的规则，但仅适用于定向状态的特殊情况。
In general, a client sends directed presence when it wishes to share availability information with an entity that is not subscribed to its presence, typically on a temporary basis. Common uses of directed presence include casual one-to-one chat sessions as described under Section 5.1 and multi-user chat rooms as described in [XEP-0045].
通常，当客户端希望与未订阅其存在的实体共享可用性信息时，通常会临时发送定向存在。定向状态的常见用途包括第5.1节所述的临时一对一聊天会话和[XEP-0045]所述的多用户聊天室。
The temporary relationship established by sharing directed presence with another entity is secondary to the permanent relationship established through a presence subscription. Therefore, the acts of creating, modifying, or canceling a presence subscription MUST take precedence over the rules specified in the following subsections. For example, if a user shares directed presence with a contact but then adds the contact to the user's roster by completing the presence subscription "handshake", the user's server MUST treat the contact just as it would any normal subscriber as described under Section 3, for example, by sending subsequent presence broadcasts to the contact. As another example, if the user then cancels the contact's subscription to the user's presence, the user's server MUST handle the cancellation just as it normally would as described under Section 3.2, which includes sending unavailable presence to the contact even if the user has sent directed presence to the contact.
通过与另一实体共享定向存在而建立的临时关系是通过存在订阅建立的永久关系的次要关系。因此，创建、修改或取消状态订阅的行为必须优先于以下小节中指定的规则。例如，如果用户与联系人共享定向状态，但随后通过完成状态订阅“握手”将联系人添加到用户名册中，则用户服务器必须像对待第3节所述的任何普通订户一样对待该联系人，例如，通过向该联系人发送后续状态广播。作为另一个示例，如果用户随后取消了联系人对用户状态的订阅，则用户服务器必须按照第3.2节所述的正常方式处理取消，包括向联系人发送不可用状态，即使用户已向联系人发送了定向状态。
XMPP servers typically implement directed presence by keeping a list of the entities (bare JIDs or full JIDs) to which a user has sent directed presence during the user's current session for a given resource (full JID), then clearing the list when the user goes offline (e.g., by sending a broadcast presence stanza of type "unavailable"). The server MUST remove from the directed presence
XMPP服务器通常通过保留一个实体列表（裸JID或完整JID）来实现定向存在，用户在当前会话期间为给定资源（完整JID）向该实体发送定向存在，然后在用户脱机时清除该列表（例如，通过发送“不可用”类型的广播存在节）。服务器必须从定向状态中删除
list (or its functional equivalent) any entity to which the user sends directed unavailable presence and SHOULD remove any entity that sends unavailable presence to the user.
列出（或其等效功能）用户向其发送定向不可用状态的任何实体，并应删除向用户发送不可用状态的任何实体。
As noted, directed presence is a client-generated presence stanza with a 'to' attribute whose value is the bare JID or full JID of the other entity and with either no 'type' attribute (indicating availability) or a 'type' attribute whose value is "unavailable".
如前所述，定向呈现是客户端生成的呈现节，具有“to”属性，其值为其他实体的裸JID或完整JID，并且没有“type”属性（表示可用性）或“type”属性，其值为“unavailable”。
When the user's server receives a directed presence stanza, it SHOULD process it according to the following rules.
当用户的服务器接收到定向状态节时，它应该根据以下规则进行处理。
1. If the user sends directed available or unavailable 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 (i.e., during the user's presence session), the user's server MUST locally deliver or remotely route the full XML of that presence stanza 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).
1. 如果用户在发送初始状态之后和发送不可用状态广播之前（即，在用户的状态会话期间），以“来自”或“两者”订阅类型向用户名册中的联系人发送定向可用或不可用状态，用户服务器必须本地交付或远程路由该状态节的完整XML，但不应以其他方式修改联系人关于状态广播的状态（即，在用户发起的任何后续状态广播中应包括联系人的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 (i.e., during the user's presence session), the user's server MUST locally deliver or remotely route 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 becomes unavailable, the user's server MUST route that unavailable presence to the entity (if the user has not yet sent directed unavailable presence to that entity).
2. 如果用户在发送初始状态之后和发送不可用状态广播之前（即，在用户的状态会话期间），以“来自”或“两者”的订阅类型向不在用户名册中的实体发送定向状态，用户服务器必须本地交付或远程路由该状态节的完整XML到实体，但不得修改联系人关于可用状态广播的状态（即，不得在用户发起的任何后续可用状态广播中包含实体的JID）；但是，如果用户发送定向状态的可用资源变得不可用，则用户的服务器必须将该不可用状态路由到该实体（如果用户尚未向该实体发送定向不可用状态）。
3. If the user sends directed presence without first sending initial presence or after having sent unavailable presence broadcast (i.e., the resource is connected but not available), the user's server MUST treat the entity to which the user sends directed presence as in case #2 above.
3. 如果用户未首先发送初始状态或在发送不可用状态广播（即，资源已连接但不可用）后发送定向状态，则用户服务器必须将用户向其发送定向状态的实体视为上述情况#2。
From the perspective of the contact's server, there is no significant difference between presence broadcast and directed presence, so the contact's server follows the rules for processing of inbound presence defined under Sections 4.3.2, 4.4.3, and 4.5.3.
从联系人服务器的角度来看，状态广播和定向状态之间没有显著差异，因此联系人服务器遵循第4.3.2、4.4.3和4.5.3节中定义的入站状态处理规则。
From the perspective of the contact's client, there is no significant difference between presence broadcast and directed presence, so the contact's client follows the rules for processing of inbound presence defined under Section 4.4.3.
从联系人客户的角度来看，状态广播和定向状态之间没有显著差异，因此联系人客户遵循第4.4.3节定义的入站状态处理规则。
If a user's client has sent directed presence to another entity (e.g., a one-to-one chat partner or a multi-user chat room), after some time the entity or its server might want to know if the client is still online. This scenario is especially common in the case of multi-user chat rooms, in which the user might be a participant for a long period of time. If the user's client goes offline without the chat room being informed (either by the client or the client's server), the user's representation in the room might become a "ghost" that appears to be participating but that in fact is no longer present in the room. To detect such "ghosts", some multi-user chat room implementations send presence probes to users that have joined the room.
如果用户的客户端已向另一个实体（例如，一对一聊天伙伴或多用户聊天室）发送定向状态，则一段时间后，该实体或其服务器可能想知道客户端是否仍在线。这种情况在多用户聊天室中尤其常见，在这种情况下，用户可能会在很长一段时间内成为参与者。如果用户的客户端在未通知聊天室的情况下脱机（无论是客户端还是客户端的服务器），则聊天室中的用户表示可能会变成一个“幽灵”，看似参与，但实际上已不在聊天室中。为了检测这种“重影”，一些多用户聊天室实现向加入聊天室的用户发送状态探测。
In the case of directed presence, the probing entity SHOULD send the probe from the JID that received directed presence (whether a full JID or a bare JID). The probe SHOULD be sent to the user's full JID, not the user's bare JID without a resourcepart, because the temporary "authorization" involved with directed presence is based on the full JID from which the user sent directed presence to the probing entity. When the user's server receives a probe, it MUST first apply any logic associated with presence subscriptions as described under Section 4.3.2. If the probing entity does not have a subscription to the user's presence, then the server MUST check if the user has sent directed presence to the entity during its current session; if so, the server SHOULD answer the probe with only mere presence of type "available" or "unavailable" (i.e., not including child elements) and only for that full JID (i.e., not for any other resources that might be currently associated with the user's bare JID).
在定向存在的情况下，探测实体应该从接收定向存在的JID发送探测（无论是完整JID还是裸JID）。探测应该发送到用户的完整JID，而不是没有resourcepart的用户的裸JID，因为定向存在涉及的临时“授权”基于用户向探测实体发送定向存在的完整JID。当用户的服务器接收到探测器时，必须首先应用与状态订阅相关的任何逻辑，如第4.3.2节所述。如果探测实体没有订阅用户的存在，则服务器必须检查用户在其当前会话期间是否向实体发送了定向存在；如果是这样，服务器应仅以“可用”或“不可用”类型（即，不包括子元素）回答探测，并且仅针对该完整JID（即，不针对当前可能与用户的裸JID关联的任何其他资源）。
The absence of a 'type' attribute signals that the relevant entity is available for communication (see Section 4.2 and Section 4.4).
缺少“类型”属性表示相关实体可用于通信（见第4.2节和第4.4节）。
A 'type' attribute with a value of "unavailable" signals that the relevant entity is not available for communication (see Section 4.5).
值为“不可用”的“类型”属性表示相关实体不可用于通信（见第4.5节）。
The XMPP presence stanza is also used to negotiate and manage subscriptions to the presence of other entities. These tasks are completed via presence stanzas of type "subscribe", "unsubscribe", "subscribed", and "unsubscribed" as described under Section 3.
XMPP状态节还用于协商和管理对其他实体状态的订阅。如第3节所述，这些任务通过“订阅”、“取消订阅”、“订阅”和“取消订阅”类型的状态节完成。
If a user and contact are associated with different XMPP servers, those servers also use a special presence stanza of type "probe" in order to determine the availability of the entity on the peer server; details are provided under Section 4.3. Clients SHOULD NOT send presence stanzas of type "probe".
如果用户和联系人与不同的XMPP服务器相关联，这些服务器还使用类型为“probe”的特殊状态节，以确定对等服务器上实体的可用性；详情见第4.3节。客户端不应发送类型为“probe”的状态节。
The values of the 'type' attribute can be summarized as follows:
“type”属性的值可以总结如下：
o error -- An error has occurred regarding processing of a previously sent presence stanza; if the presence stanza is of type "error", it MUST include an <error/> child element (refer to [XMPP-CORE]).
o 错误——处理先前发送的状态节时发生错误；如果presence节的类型为“error”，则它必须包含<error/>子元素（请参阅[XMPP-CORE]）。
o probe -- A request for an entity's current presence; SHOULD be generated only by a server on behalf of a user.
o 探测——对实体当前存在的请求；应仅由服务器代表用户生成。
o subscribe -- The sender wishes to subscribe to the recipient's presence.
o subscribe——发送者希望订阅接收者的状态。
o subscribed -- The sender has allowed the recipient to receive their presence.
o 已订阅--发件人已允许收件人接收他们的状态。
o unavailable -- The sender is no longer available for communication.
o 不可用--发送方不再可用于通信。
o unsubscribe -- The sender is unsubscribing from the receiver's presence.
o unsubscribe——发送方在接收方在场的情况下取消订阅。
o unsubscribed -- The subscription request has been denied or a previously granted subscription has been canceled.
o unsubscribed--订阅请求已被拒绝或先前授予的订阅已被取消。
If the value of the 'type' attribute is not one of the foregoing values, the recipient or an intermediate router SHOULD return a stanza error of <bad-request/>.
如果“type”属性的值不是上述值之一，则接收方或中间路由器应返回节错误<bad request/>。
Implementation Note: There is no default value for the 'type' attribute of the <presence/> element.
实现说明：<presence/>元素的“type”属性没有默认值。
Implementation Note: There is no value of "available" for the 'type' attribute of the <presence/> element.
实现说明：<presence/>元素的“type”属性没有“available”值。
In accordance with the default namespace declaration, a presence stanza is qualified by the 'jabber:client' or 'jabber:server' namespace, which defines certain child elements of presence stanzas, in particular the <show/>, <status/>, and <priority/> elements. These child elements are used to provide more detailed information about an entity's availability. Typically these child elements are included only if the presence stanza possesses no 'type' attribute, although exceptions are noted in the text that follows.
根据默认名称空间声明，状态节由“jabber:client”或“jabber:server”名称空间限定，该名称空间定义状态节的某些子元素，特别是<show/>、<status/>和<priority/>元素。这些子元素用于提供有关实体可用性的更详细信息。通常，仅当presence节不具有“type”属性时，才包含这些子元素，尽管下面的文本中指出了例外情况。
The OPTIONAL <show/> element specifies the particular availability sub-state of an entity or a specific resource thereof. A presence stanza MUST NOT contain more than one <show/> element. There are no attributes defined for the <show/> element. The <show/> element MUST NOT contain mixed content (as defined in Section 3.2.2 of [XML]). The XML character data of the <show/> element is not meant for presentation to a human user. The XML character data MUST be one of the following (additional availability states could be defined through extended content elements):
可选的<show/>元素指定实体或其特定资源的特定可用性子状态。状态节不能包含多个<show/>元素。没有为<show/>元素定义属性。<show/>元素不得包含混合内容（如[XML]第3.2.2节所定义）。<show/>元素的XML字符数据并不表示给人类用户。XML字符数据必须是以下之一（可以通过扩展内容元素定义其他可用性状态）：
o away -- The entity or resource is temporarily away.
o 离开——实体或资源暂时离开。
o chat -- The entity or resource is actively interested in chatting.
o 聊天——实体或资源对聊天非常感兴趣。
o dnd -- The entity or resource is busy (dnd = "Do Not Disturb").
o dnd——实体或资源正忙（dnd=“请勿打扰”）。
o xa -- The entity or resource is away for an extended period (xa = "eXtended Away").
o xa——实体或资源离开一段较长的时间（xa=“extended away”）。
If no <show/> element is provided, the entity is assumed to be online and available.
如果未提供<show/>元素，则假定实体在线且可用。
Any specialized processing of availability states by recipients and intermediate routers is up to the implementation (e.g., incorporation of availability states into stanza routing and delivery logic).
接收方和中间路由器对可用性状态的任何专门处理取决于实现（例如，将可用性状态合并到节路由和交付逻辑中）。
The OPTIONAL <status/> element contains human-readable XML character data specifying a natural-language description of an entity's availability. It is normally used in conjunction with the show element to provide a detailed description of an availability state (e.g., "In a meeting") when the presence stanza has no 'type' attribute.
可选的<status/>元素包含人类可读的XML字符数据，指定实体可用性的自然语言描述。当状态节没有“type”属性时，它通常与show元素结合使用，以提供可用性状态的详细描述（例如，“在会议中”）。
<presence from='romeo@example.net/orchard'
xml:lang='en'>
<show>dnd</show>
<status>Wooing Juliet</status>
</presence>
<presence from='romeo@example.net/orchard'
xml:lang='en'>
<show>dnd</show>
<status>Wooing Juliet</status>
</presence>
There are no attributes defined for the <status/> element, with the exception of the 'xml:lang' attribute inherited from [XML]. The <status/> element MUST NOT contain mixed content (as defined in Section 3.2.2 of [XML]). Multiple instances of the <status/> element MAY be included, but only if each instance possesses an 'xml:lang' attribute with a distinct language value (either explicitly or by inheritance from the 'xml:lang' value of an element farther up in the XML hierarchy, which from the sender's perspective can include the XML stream header as described in [XMPP-CORE]).
除了从[xml]继承的'xml:lang'属性外，没有为<status/>元素定义任何属性。<status/>元素不得包含混合内容（如[XML]第3.2.2节所定义）。可以包括<status/>元素的多个实例，但前提是每个实例都拥有一个具有不同语言值的“xml:lang”属性（显式地或通过继承xml层次结构中更高的元素的“xml:lang”值，从发送方的角度来看，可以包括中所述的xml流头）[XMPP-CORE]）。
<presence from='romeo@example.net/orchard'
id='jx62vs97'
xml:lang='en'>
<show>dnd</show>
<status>Wooing Juliet</status>
<status xml:lang='cs'>Dvořím se Julii</status>
</presence>
<presence from='romeo@example.net/orchard'
id='jx62vs97'
xml:lang='en'>
<show>dnd</show>
<status>Wooing Juliet</status>
<status xml:lang='cs'>Dvořím se Julii</status>
</presence>
A presence stanza of type "unavailable" MAY also include a <status/> element to provide detailed information about why the entity is going offline.
类型为“不可用”的状态节还可以包含<status/>元素，以提供有关实体脱机原因的详细信息。
<presence from='romeo@example.net/orchard'
id='oy6sb241'
type='unavailable'
xml:lang='en'>
<status>Busy IRL</status>
</presence>
<presence from='romeo@example.net/orchard'
id='oy6sb241'
type='unavailable'
xml:lang='en'>
<status>Busy IRL</status>
</presence>
The <status/> child MAY also be sent in a subscription-related presence stanza (i.e., type "subscribe", "subscribed", "unsubscribe", or "unsubscribed") to provide a description of the action. An interactive client MAY present this <status/> information to a human user (see Section 11).
<status/>子项也可以在订阅相关的状态节中发送（即，键入“订阅”、“订阅”、“取消订阅”或“取消订阅”），以提供对操作的描述。交互式客户端可以向人类用户呈现该<status/>信息（见第11节）。
<presence from='romeo@example.net'
id='uc51xs63'
to='nurse@example.com'
type='subscribe'>
<status>Hi, Juliet told me to add you to my buddy list.</status>
</presence>
<presence from='romeo@example.net'
id='uc51xs63'
to='nurse@example.com'
type='subscribe'>
<status>Hi, Juliet told me to add you to my buddy list.</status>
</presence>
The OPTIONAL <priority/> element contains non-human-readable XML character data that specifies the priority level of the resource. The value MUST be an integer between -128 and +127. A presence stanza MUST NOT contain more than one <priority/> element. There are no attributes defined for the <priority/> element. The <priority/> element MUST NOT contain mixed content (as defined in Section 3.2.2 of [XML]).
可选的<priority/>元素包含非人类可读的XML字符数据，用于指定资源的优先级。该值必须是介于-128和+127之间的整数。状态节不能包含多个<priority/>元素。没有为<priority/>元素定义属性。<priority/>元素不得包含混合内容（如[XML]第3.2.2节所定义）。
<presence xml:lang='en'>
<show>dnd</show>
<status>Wooing Juliet</status>
<status xml:lang='cs'>Dvořím se Julii</status>
<priority>1</priority>
</presence>
<presence xml:lang='en'>
<show>dnd</show>
<status>Wooing Juliet</status>
<status xml:lang='cs'>Dvořím se Julii</status>
<priority>1</priority>
</presence>
If no priority is provided, the processing server or client MUST consider the priority to be zero ("0").
如果没有提供优先级，则处理服务器或客户端必须考虑优先级为零（“0”）。
The client's server MAY override the priority value provided by the client (e.g., in order to impose a message handling rule of delivering a message intended for the account's bare JID to all of the account's available resources). If the server does so, it MUST communicate the modified priority value when it echoes the client's presence back to itself and sends the presence notification to the user's contacts (because this modified priority value is typically the default value of zero, communicating the modified priority value can be done by not including the <priority/> child element).
客户机的服务器可以覆盖客户机提供的优先级值（例如，为了强制执行消息处理规则，将用于帐户的裸JID的消息传递到帐户的所有可用资源）。如果服务器这样做，它必须在将客户端的状态反馈回自身并向用户的联系人发送状态通知时传达修改后的优先级值（由于此修改的优先级值通常是默认值零，因此可以通过不包含<priority/>子元素来传递修改的优先级值）。
For information regarding the semantics of priority values in stanza processing within instant messaging and presence applications, refer to Section 8.
有关即时消息和状态应用程序中节处理中优先级值语义的信息，请参阅第8节。
As described in [XMPP-CORE], an XML stanza MAY contain any child element that is qualified by a namespace other than the default namespace; this applies to the presence stanza as well.
如[XMPP-CORE]中所述，XML节可以包含任何子元素，该子元素由默认名称空间以外的名称空间限定；这也适用于在场小节。
(In the following example, the presence stanza includes entity capabilities information as defined in [XEP-0115].)
（在以下示例中，状态节包括[XEP-0115]中定义的实体能力信息。）
<presence from='romeo@example.net'>
<c xmlns='http://jabber.org/protocol/caps'
hash='sha-1'
node='http://psi-im.org'
ver='q07IKJEyjvHSyhy//CH0CxmKi8w='/>
</presence>
<presence from='romeo@example.net'>
<c xmlns='http://jabber.org/protocol/caps'
hash='sha-1'
node='http://psi-im.org'
ver='q07IKJEyjvHSyhy//CH0CxmKi8w='/>
</presence>
Any extended content included in a presence stanza SHOULD represent aspects of an entity's availability for communication or provide information about communication-related capabilities.
状态节中包含的任何扩展内容都应该表示实体通信可用性的各个方面，或者提供有关通信相关能力的信息。
Once a client has authenticated with a server and bound a resource to an XML stream as described in [XMPP-CORE], an XMPP server will route XML stanzas to and from that client. One kind of stanza that can be exchanged is <message/> (if, that is, messaging functionality is enabled on the server). Exchanging messages is a basic use of XMPP and occurs when a user generates a message stanza that is addressed to another entity. As defined under Section 8, the sender's server is responsible for delivering the message to the intended recipient (if the recipient is on the same local server) or for routing the message to the recipient's server (if the recipient is on a remote server). Thus a message stanza is used to "push" information to another entity.
一旦客户机通过服务器身份验证并将资源绑定到XML流（如[XMPP-CORE]中所述），XMPP服务器就会将XML节路由到该客户机，并从该客户机发送XML节。一种可以交换的节是<message/>（如果服务器上启用了消息传递功能）。交换消息是XMPP的一个基本用途，当用户生成一个发往另一个实体的消息节时就会发生。根据第8节的定义，发件人服务器负责将邮件传递给预期收件人（如果收件人在同一本地服务器上），或将邮件路由到收件人服务器（如果收件人在远程服务器上）。因此，消息节用于将信息“推送”到另一个实体。
In practice, instant messaging activity between human users tends to occur in the form of a conversational burst that we call a "chat session": the exchange of multiple messages between two parties in relatively rapid succession within a relatively brief period of time.
实际上，人类用户之间的即时消息传递活动往往以会话突发的形式发生，我们称之为“聊天会话”：双方在相对较短的时间内以相对快速的顺序交换多条消息。
When a human user intends to engage in such a chat session with a contact (rather than sending a single message to which no reply is expected), the message type generated by the user's client SHOULD be "chat" and the contact's client SHOULD preserve that message type in subsequent replies. The user's client also SHOULD include a
当人类用户打算与联系人进行此类聊天会话时（而不是发送一条预期不会有回复的消息），用户客户端生成的消息类型应为“chat”，联系人客户端应在后续回复中保留该消息类型。用户的客户端还应包括
<thread/> element with its initial message, which the contact's client SHOULD also preserve during the life of the chat session (see Section 5.2.5).
<thread/>元素及其初始消息，联系人的客户端也应在聊天会话期间保留该消息（参见第5.2.5节）。
The user's client SHOULD address the initial message in a chat session to the bare JID <contact@domainpart> of the contact (rather than attempting to guess an appropriate full JID <contact@domainpart/resourcepart> based on the <show/>, <status/>, or <priority/> value of any presence notifications it might have received from the contact). Until and unless the user's client receives a reply from the contact, it SHOULD send any further messages to the contact's bare JID. The contact's client SHOULD address its replies to the user's full JID <user@domainpart/resourcepart> as provided in the 'from' address of the initial message. Once the user's client receives a reply from the contact's full JID, it SHOULD address its subsequent messages to the contact's full JID as provided in the 'from' address of the contact's replies, thus "locking in" on that full JID. A client SHOULD "unlock" after having received a <message/> or <presence/> stanza from any other resource controlled by the peer (or a presence stanza from the locked resource); as a result, it SHOULD address its next message(s) in the chat session to the bare JID of the peer (thus "unlocking" the previous "lock") until it receives a message from one of the peer's full JIDs.
用户的客户端应该将聊天会话中的初始消息发送给裸JID<contact@domainpart>联系方式（而不是试图猜测适当的完整JID）<contact@domainpart/resourcepart>基于它可能从联系人处收到的任何状态通知的<show/>、<status/>或<priority/>值）。除非用户的客户端收到联系人的回复，否则它应该向联系人的裸JID发送任何进一步的消息。联系人的客户端应回复用户的完整JID<user@domainpart/resourcepart>在初始消息的“发件人”地址中提供。一旦用户的客户端收到来自联系人完整JID的回复，它应该按照联系人回复的“发件人”地址中的规定将其后续消息发送到联系人的完整JID，从而“锁定”该完整JID。客户端在从对等方控制的任何其他资源（或来自锁定资源的状态节）接收到<message/>或<presence/>节后应“解锁”；因此，它应该将聊天会话中的下一条消息寻址到对等方的裸JID（从而“解锁”上一个“锁”），直到它从对等方的一个完整JID接收到消息为止。
When two parties engage in a chat session but do not share presence with each other based on a presence subscription, they SHOULD send directed presence to each other so that either party can easily discover if the peer goes offline during the course of the chat session. However, a client MUST provide a way for a user to disable such presence sharing globally or to enable it only with particular entities. Furthermore, a party SHOULD send directed unavailable presence to the peer when it has reason to believe that the chat session is over (e.g., if, after some reasonable amount of time, no subsequent messages have been exchanged between the parties).
当双方参与聊天会话但不根据状态订阅相互共享状态时，他们应该相互发送定向状态，以便任何一方都可以轻松发现对方在聊天会话过程中是否离线。但是，客户机必须为用户提供一种方法来全局禁用这种状态共享，或者仅与特定实体启用这种状态共享。此外，当一方有理由相信聊天会话结束时（例如，如果在一段合理的时间之后，双方之间没有交换后续消息），该方应向对等方发送定向不可用状态。
An example of a chat session is provided under Section 7.
第7节提供了聊天会话的示例。
The following sections describe the syntax of the <message/> stanza.
以下各节介绍<message/>节的语法。
An instant messaging client specifies an intended recipient for a message by providing the JID of the intended recipient in the 'to' attribute of the <message/> stanza.
即时消息客户端通过在<message/>节的“to”属性中提供预期收件人的JID来指定消息的预期收件人。
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 <localpart@domainpart> rather than of the form <localpart@domainpart/resourcepart> (see Section 5.1).
如果消息是在任何现有聊天会话或接收到的消息的上下文之外发送的，“收件人”地址的值应为以下格式<localpart@domainpart>而不是形式<localpart@domainpart/resourcepart>（参见第5.1节）。
<message
from='juliet@example.com/balcony'
id='ktx72v49'
to='romeo@example.net'
type='chat'
xml:lang='en'>
<body>Art thou not Romeo, and a Montague?</body>
</message>
<message
from='juliet@example.com/balcony'
id='ktx72v49'
to='romeo@example.net'
type='chat'
xml:lang='en'>
<body>Art thou not Romeo, and a Montague?</body>
</message>
If the message is being sent in reply to a message previously received from an address of the form <localpart@domainpart/resourcepart> (e.g., within the context of a one-to-one chat session as described under Section 5.1), the value of the 'to' address SHOULD be of the form <localpart@domainpart/resourcepart> rather than of the form <localpart@domainpart> unless the sender has knowledge (e.g., via presence) that the intended recipient's resource is no longer available.
如果发送的邮件是对以前从表单地址收到的邮件的回复<localpart@domainpart/resourcepart>（例如，在第5.1节所述的一对一聊天会话的上下文中），“收件人”地址的值应为以下格式<localpart@domainpart/resourcepart>而不是表单的<localpart@domainpart>除非发送者知道（例如，通过存在）预期接收者的资源不再可用。
<message
from='romeo@example.net/orchard'
id='sl3nx51f'
to='juliet@example.com/balcony'
type='chat'
xml:lang='en'>
<body>Neither, fair saint, if either thee dislike.</body>
</message>
<message
from='romeo@example.net/orchard'
id='sl3nx51f'
to='juliet@example.com/balcony'
type='chat'
xml:lang='en'>
<body>Neither, fair saint, if either thee dislike.</body>
</message>
Common uses of the message stanza in instant messaging applications include: single messages; messages sent in the context of a one-to-one chat session; messages sent in the context of a multi-user chat room; alerts, notifications, or other information to which no reply is expected; and errors. These uses are differentiated via the 'type' attribute. Inclusion of the 'type' attribute is RECOMMENDED. If included, the 'type' attribute MUST have one of the following values:
即时消息应用程序中消息节的常见用途包括：单个消息；在一对一聊天会话中发送的消息；在多用户聊天室中发送的消息；警报、通知或其他不需要回复的信息；和错误。通过“类型”属性区分这些用途。建议包含“类型”属性。如果包含，则“type”属性必须具有以下值之一：
o chat -- The message is sent in the context of a one-to-one chat session. Typically an interactive client will present a message of type "chat" in an interface that enables one-to-one chat between the two parties, including an appropriate conversation history. Detailed recommendations regarding one-to-one chat sessions are provided under Section 5.1.
o 聊天——消息在一对一聊天会话的上下文中发送。通常，交互式客户端将在一个界面中显示“chat”类型的消息，该界面支持双方之间的一对一聊天，包括适当的对话历史记录。第5.1节提供了关于一对一聊天会话的详细建议。
o error -- The message is generated by an entity that experiences an error when processing a message received from another entity (for details regarding stanza error syntax, refer to [XMPP-CORE]). A client that receives a message of type "error" SHOULD present an appropriate interface informing the original sender regarding the nature of the error.
o 错误——该消息由处理从另一个实体接收的消息时遇到错误的实体生成（有关节错误语法的详细信息，请参阅[XMPP-CORE]）。接收“错误”类型消息的客户端应提供适当的接口，通知原始发送方错误的性质。
o groupchat -- The message is sent in the context of a multi-user chat environment (similar to that of [IRC]). Typically a receiving client will present a message of type "groupchat" in an interface that enables many-to-many chat between the parties, including a roster of parties in the chatroom and an appropriate conversation history. For detailed information about XMPP-based groupchat, refer to [XEP-0045].
o groupchat——消息是在多用户聊天环境中发送的（类似于[IRC]）。通常，接收客户端将在一个界面中显示“groupchat”类型的消息，该界面允许各方之间进行多对多聊天，包括聊天室中的各方名册和适当的对话历史记录。有关基于XMPP的groupchat的详细信息，请参阅[XEP-0045]。
o headline -- The message provides an alert, a notification, or other transient information to which no reply is expected (e.g., news headlines, sports updates, near-real-time market data, or syndicated content). Because no reply to the message is expected, typically a receiving client will present a message of type "headline" in an interface that appropriately differentiates the message from standalone messages, chat messages, and groupchat messages (e.g., by not providing the recipient with the ability to reply). If the 'to' address is the bare JID, the receiving server SHOULD deliver the message to all of the recipient's available resources with non-negative presence priority and MUST deliver the message to at least one of those resources; if the 'to' address is a full JID and there is a matching resource, the server MUST deliver the message to that resource; otherwise the server MUST either silently ignore the message or return an error (see Section 8).
o 标题——消息提供警报、通知或其他不需要回复的临时信息（例如，新闻标题、体育动态、近实时市场数据或联合内容）。由于预期不会回复消息，通常情况下，接收客户端将在界面中显示“headline”类型的消息，该界面可适当区分消息与独立消息、聊天消息和groupchat消息（例如，不向收件人提供回复能力）。如果“收件人”地址是裸JID，则接收服务器应以非负的存在优先级将消息传递给收件人的所有可用资源，并且必须将消息传递给这些资源中的至少一个；如果“收件人”地址是完整的JID，并且存在匹配的资源，则服务器必须将消息传递给该资源；否则，服务器必须以静默方式忽略消息或返回错误（请参阅第8节）。
o normal -- The message is a standalone 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. Typically a receiving client will present a message of type "normal" in an interface that enables the recipient to reply, but without a conversation history. The default value of the 'type' attribute is "normal".
o 正常——该消息是在一对一对话或groupchat上下文之外发送的独立消息，预期收件人将回复该消息。通常，接收客户端将在一个接口中显示一条“正常”类型的消息，该接口使收件人能够回复，但没有会话历史记录。“type”属性的默认值为“normal”。
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).
IM应用程序应支持上述所有消息类型。如果应用程序接收到没有“type”属性的消息，或者应用程序不理解所提供的“类型”属性的值，则必须将消息视为“正常”类型（即“正常”）为默认值。
Guidelines for server handling of different message types is provided under Section 8.
第8节提供了不同消息类型的服务器处理指南。
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”属性是可选的，但在对消息的任何回复中镜像该类型被认为是礼貌的；此外，一些专用应用程序（例如，多用户聊天服务）可以自行决定强制使用特定的消息类型（例如，type='groupchat'）。
The <body/> element contains human-readable XML character data that specifies the textual contents of the message; this child element is normally included but is OPTIONAL.
<body/>元素包含人类可读的XML字符数据，用于指定消息的文本内容；此子元素通常包括在内，但是可选的。
<message
from='juliet@example.com/balcony'
id='b4vs9km4'
to='romeo@example.net'
type='chat'
xml:lang='en'>
<body>Wherefore art thou, Romeo?</body>
</message>
<message
from='juliet@example.com/balcony'
id='b4vs9km4'
to='romeo@example.net'
type='chat'
xml:lang='en'>
<body>Wherefore art thou, Romeo?</body>
</message>
There are no attributes defined for the <body/> element, with the exception of the 'xml:lang' attribute. Multiple instances of the <body/> element MAY be included in a message stanza for the purpose of providing alternate versions of the same body, but only if each instance possesses an 'xml:lang' attribute with a distinct language value (either explicitly or by inheritance from the 'xml:lang' value of an element farther up in the XML hierarchy, which from the sender's perspective can include the XML stream header as described in [XMPP-CORE]).
除了'xml:lang'属性外，没有为<body/>元素定义任何属性。一个消息节中可以包含<body/>元素的多个实例，以提供同一正文的替代版本，但前提是每个实例都拥有一个具有不同语言值的“xml:lang”属性（显式地或通过继承xml层次结构中更高层元素的'xml:lang'值，从发送方的角度来看，该值可以包括[XMPP-CORE]中描述的xml流头）。
<message
from='juliet@example.com/balcony'
id='z94nb37h'
to='romeo@example.net'
type='chat'
xml:lang='en'>
<body>Wherefore art thou, Romeo?</body>
<body xml:lang='cs'>
PročeŽ jsi ty, Romeo?
</body>
</message>
<message
from='juliet@example.com/balcony'
id='z94nb37h'
to='romeo@example.net'
type='chat'
xml:lang='en'>
<body>Wherefore art thou, Romeo?</body>
<body xml:lang='cs'>
PročeŽ jsi ty, Romeo?
</body>
</message>
The <body/> element MUST NOT contain mixed content (as defined in Section 3.2.2 of [XML]).
<body/>元素不得包含混合内容（如[XML]第3.2.2节所定义）。
The <subject/> element contains human-readable XML character data that specifies the topic of the message.
<subject/>元素包含人类可读的XML字符数据，用于指定消息的主题。
<message
from='juliet@example.com/balcony'
id='c8xg3nf8'
to='romeo@example.net'
type='chat'
xml:lang='en'>
<subject>I implore you!</subject>
<body>Wherefore art thou, Romeo?</body>
</message>
<message
from='juliet@example.com/balcony'
id='c8xg3nf8'
to='romeo@example.net'
type='chat'
xml:lang='en'>
<subject>I implore you!</subject>
<body>Wherefore art thou, Romeo?</body>
</message>
There are no attributes defined for the <subject/> element, with the exception of the 'xml:lang' attribute inherited from [XML]. Multiple instances of the <subject/> element MAY be included for the purpose of providing alternate versions of the same subject, but only if each instance possesses an 'xml:lang' attribute with a distinct language value (either explicitly or by inheritance from the 'xml:lang' value of an element farther up in the XML hierarchy, which from the sender's perspective can include the XML stream header as described in [XMPP-CORE]).
除了从[xml]继承的“xml:lang”属性外，没有为<subject/>元素定义任何属性。为了提供同一主题的替代版本，可以包括<subject/>元素的多个实例，但前提是每个实例都具有具有不同语言值的“xml:lang”属性（显式地或通过继承xml层次结构中更高层元素的'xml:lang'值，从发送方的角度来看，该值可以包括[XMPP-CORE]中描述的xml流头）。
<message
from='juliet@example.com/balcony'
id='jk3v47gw'
to='romeo@example.net'
type='chat'
xml:lang='en'>
<subject>I implore you!</subject>
<subject xml:lang='cs'>
Úpěnlivě prosím!
</subject>
<body>Wherefore art thou, Romeo?</body>
<body xml:lang='cs'>
Pročež jsi ty, Romeo?
</body>
</message>
<message
from='juliet@example.com/balcony'
id='jk3v47gw'
to='romeo@example.net'
type='chat'
xml:lang='en'>
<subject>I implore you!</subject>
<subject xml:lang='cs'>
Úpěnlivě prosím!
</subject>
<body>Wherefore art thou, Romeo?</body>
<body xml:lang='cs'>
Pročež jsi ty, Romeo?
</body>
</message>
The <subject/> element MUST NOT contain mixed content (as defined in Section 3.2.2 of [XML]).
<subject/>元素不得包含混合内容（如[XML]第3.2.2节所定义）。
The primary use of the XMPP <thread/> element is to uniquely identify a conversation thread or "chat session" between two entities instantiated by <message/> stanzas of type 'chat'. However, the XMPP <thread/> element MAY also be used to uniquely identify an analogous thread between two entities instantiated by <message/> stanzas of type 'headline' or 'normal', or among multiple entities in the context of a multi-user chat room instantiated by <message/> stanzas of type 'groupchat'. It MAY also be used for <message/> stanzas not related to a human conversation, such as a game session or an interaction between plugins. The <thread/> element is not used to identify individual messages, only conversations or messaging sessions.
XMPP<thread/>元素的主要用途是唯一地标识由“chat”类型的<message/>节实例化的两个实体之间的对话线程或“chat session”。然而，XMPP<thread/>元素也可用于唯一标识由“headline”或“normal”类型的<message/>节实例化的两个实体之间的类似线程，或在由“groupchat”类型的<message/>节实例化的多用户聊天室上下文中的多个实体之间的类似线程。它也可以用于与人类对话无关的<message/>节，例如游戏会话或插件之间的交互。<thread/>元素不用于标识单个消息，仅用于标识会话或消息会话。
The inclusion of the <thread/> element is OPTIONAL. Because the <thread/> element identifies the particular conversation thread to which a message belongs, a message stanza MUST NOT contain more than one <thread/> element.
包含<thread/>元素是可选的。由于<thread/>元素标识消息所属的特定对话线程，因此消息节不能包含多个<thread/>元素。
The <thread/> element MAY possess a 'parent' attribute that identifies another thread of which the current thread is an offshoot or child. The 'parent' attribute MUST conform to the syntax of the <thread/> element itself and its value MUST be different from the XML character data of the <thread/> element on which the 'parent' attribute is included.
<thread/>元素可能拥有一个“parent”属性，该属性标识当前线程是其分支或子线程的另一个线程。“parent”属性必须符合<thread/>元素本身的语法，并且其值必须不同于包含“parent”属性的<thread/>元素的XML字符数据。
Implementation Note: The ability to specify both a parent thread and a child thread introduces the possibility of conflicts between thread identifiers for overlapping threads. For example, one <thread/> element might contain XML character data of "foo" and a 'parent' attribute whose value is "bar", a second <thread/> element might contain XML character data of "bar" and a 'parent' attribute whose value is "baz", and a third <thread/> element might contain XML character data of "baz" and a 'parent' attribute whose value is once again "foo". It is up to the implementation how it will treat conflicts between such overlapping thread identifiers (e.g., whether it will "chain together" thread identifiers by showing "foo" as both a parent and grandchild of "baz" in a multi-level user interface, or whether it will show only one level of dependency at a time).
实现说明：同时指定父线程和子线程的能力引入了重叠线程的线程标识符之间冲突的可能性。例如，一个<thread/>元素可能包含“foo”的XML字符数据和值为“bar”的“parent”属性，第二个<thread/>元素可能包含“bar”的XML字符数据和值为“baz”的“parent”属性，第三个<thread/>元素可能包含“baz”的XML字符数据以及一个值再次为“foo”的“parent”属性。这取决于实现如何处理此类重叠线程标识符之间的冲突（例如，它是否将通过在多级用户界面中显示“foo”作为“baz”的父级和孙级来“链接在一起”线程标识符，或者它是否一次只显示一个依赖级别）。
The value of the <thread/> element is not human-readable and MUST be treated as opaque by entities; no semantic meaning can be derived from it, and only exact comparisons can be made against it. The value of the <thread/> element MUST uniquely identify the conversation thread either between the conversation partners or more generally (one way to ensure uniqueness is by generating a universally unique identifier (UUID) as described in [UUID]).
<thread/>元素的值不是人类可读的，必须被实体视为不透明的；它没有语义，只能与之进行精确的比较。<thread/>元素的值必须唯一地标识对话伙伴之间的对话线程，或者更一般地标识对话线程（确保唯一性的一种方法是生成一个通用唯一标识符（UUID），如[UUID]中所述）。
Security Warning: An application that generates a ThreadID MUST ensure that it does not reveal identifying information about the entity (e.g., the MAC address of the device on which the XMPP application is running).
安全警告：生成ThreadID的应用程序必须确保不会显示有关实体的标识信息（例如，运行XMPP应用程序的设备的MAC地址）。
The <thread/> element MUST NOT contain mixed content (as defined in Section 3.2.2 of [XML]).
<thread/>元素不得包含混合内容（如[XML]第3.2.2节所定义）。
<message
from='juliet@example.com/balcony'
to='romeo@example.net'
type='chat'
xml:lang='en'>
<subject>I implore you!</subject>
<subject xml:lang='cs'>
Úpěnlivě prosím!
</subject>
<body>Wherefore art thou, Romeo?</body>
<body xml:lang='cs'>
Pročež jsi ty, Romeo?
</body>
<thread parent='e0ffe42b28561960c6b12b944a092794b9683a38'>
0e3141cd80894871a68e6fe6b1ec56fa
</thread>
</message>
<message
from='juliet@example.com/balcony'
to='romeo@example.net'
type='chat'
xml:lang='en'>
<subject>I implore you!</subject>
<subject xml:lang='cs'>
Úpěnlivě prosím!
</subject>
<body>Wherefore art thou, Romeo?</body>
<body xml:lang='cs'>
Pročež jsi ty, Romeo?
</body>
<thread parent='e0ffe42b28561960c6b12b944a092794b9683a38'>
0e3141cd80894871a68e6fe6b1ec56fa
</thread>
</message>
For detailed recommendations regarding use of the <thread/> element, refer to [XEP-0201].
有关<thread/>元件使用的详细建议，请参阅[XEP-0201]。
As described in [XMPP-CORE], an XML stanza MAY contain any child element that is qualified by a namespace other than the default namespace; this applies to the message stanza as well. Guidelines for handling extended content on the part of both routing servers and end recipients are provided in Section 8.4 of [XMPP-CORE].
如[XMPP-CORE]中所述，XML节可以包含任何子元素，该子元素由默认名称空间以外的名称空间限定；这也适用于消息节。[XMPP-CORE]的第8.4节提供了路由服务器和最终收件人处理扩展内容的指南。
(In the following example, the message stanza includes an XHTML-formatted version of the message as defined in [XEP-0071]).)
（在下面的示例中，消息节包括[XEP-0071]中定义的XHTML格式的消息版本。）
<message
from='juliet@example.com/balcony'
to='romeo@example.net'
type='chat'
xml:lang='en'>
<body>Wherefore art thou, Romeo?</body>
<html xmlns='http://jabber.org/protocol/xhtml-im'>
<body xmlns='http://www.w3.org/1999/xhtml'>
<p>Wherefore <span style='font-style: italic'>art</span>
thou, <span style='color:red'>Romeo</span>?</p>
</body>
</html>
</message>
<message
from='juliet@example.com/balcony'
to='romeo@example.net'
type='chat'
xml:lang='en'>
<body>Wherefore art thou, Romeo?</body>
<html xmlns='http://jabber.org/protocol/xhtml-im'>
<body xmlns='http://www.w3.org/1999/xhtml'>
<p>Wherefore <span style='font-style: italic'>art</span>
thou, <span style='color:red'>Romeo</span>?</p>
</body>
</html>
</message>
As described in [XMPP-CORE], IQ stanzas provide a structured request-response mechanism. The basic semantics of that mechanism (e.g., that the 'id' attribute is mandatory) are defined in [XMPP-CORE], whereas the specific semantics needed to complete particular use cases are defined in all instances by the extended namespace that qualifies the direct child element of an IQ stanza of type "get" or "set". The 'jabber:client' and 'jabber:server' namespaces do not define any children of IQ stanzas other than the <error/> element common to all stanza types. This document defines one such extended namespace, for Managing the Roster (Section 2). However, an IQ stanza MAY contain structured information qualified by any extended namespace.
如[XMPP-CORE]所述，IQ节提供了一种结构化的请求-响应机制。该机制的基本语义（例如，“id”属性是强制性的）在[XMPP-CORE]中定义，而完成特定用例所需的特定语义在所有实例中由扩展名称空间定义，扩展名称空间限定了“get”或“set”类型IQ节的直接子元素。“jabber:client”和“jabber:server”名称空间不定义IQ节的任何子级，所有节类型通用的<error/>元素除外。本文件定义了一个这样的扩展名称空间，用于管理名册（第2节）。然而，IQ节可能包含任何扩展名称空间限定的结构化信息。
The examples in this section illustrate a possible instant messaging and presence session. The user is <romeo@example.net>, he has an available resource whose resourcepart is "orchard", and he has the following individuals in his roster:
本节中的示例说明了可能的即时消息和状态会话。用户是<romeo@example.net>，他有一个可用资源，其资源部分为“orchard”，他的名册中有以下人员：
o <juliet@example.com> (subscription="both" and she has two
available resources, "chamber" and "balcony")
o <juliet@example.com> (subscription="both" and she has two
available resources, "chamber" and "balcony")
o <benvolio@example.net> (subscription="to")
o <benvolio@example.net> (subscription="to")
o <mercutio@example.org> (subscription="from")
o <mercutio@example.org> (subscription="from")
First, the user completes the preconditions (stream establishment, TLS and SASL negotiation, and resource binding) described in [XMPP-CORE]; those protocol flows are not reproduced here.
首先，用户完成[XMPP-CORE]中描述的先决条件（流建立、TLS和SASL协商以及资源绑定）；这里不复制这些协议流。
Next, the user requests his roster.
接下来，用户请求他的花名册。
Example 1: User requests current roster from server
示例1：用户从服务器请求当前花名册
UC: <iq from='romeo@example.net/orchard'
id='hf61v3n7'
type='get'>
<query xmlns='jabber:iq:roster'/>
</iq>
UC: <iq from='romeo@example.net/orchard'
id='hf61v3n7'
type='get'>
<query xmlns='jabber:iq:roster'/>
</iq>
Example 2: User receives roster from server
示例2：用户从服务器接收花名册
US: <iq id='hf61v3n7'
to='romeo@example.net/orchard'
type='result'>
<query xmlns='jabber:iq:roster'>
<item jid='juliet@example.com'
name='Juliet'
subscription='both'>
<group>Friends</group>
</item>
<item jid='benvolio@example.org'
name='Benvolio'
subscription='to'/>
<item jid='mercutio@example.org'
name='Mercutio'
subscription='from'/>
</query>
</iq>
US: <iq id='hf61v3n7'
to='romeo@example.net/orchard'
type='result'>
<query xmlns='jabber:iq:roster'>
<item jid='juliet@example.com'
name='Juliet'
subscription='both'>
<group>Friends</group>
</item>
<item jid='benvolio@example.org'
name='Benvolio'
subscription='to'/>
<item jid='mercutio@example.org'
name='Mercutio'
subscription='from'/>
</query>
</iq>
Now the user begins a presence session.
现在，用户开始状态会话。
Example 3: User sends initial presence
示例3：用户发送初始状态
UC: <presence/>
UC: <presence/>
Example 4: User's server sends presence probes to contacts with subscription="to" and subscription="both" on behalf of the user
示例4：用户的服务器代表用户向subscription=“to”和subscription=“both”联系人发送状态探测
US: <presence
from='romeo@example.net'
to='juliet@example.com'
type='probe'/>
US: <presence
from='romeo@example.net'
to='juliet@example.com'
type='probe'/>
US: <presence
from='romeo@example.net'
to='benvolio@example.org'
type='probe'/>
US: <presence
from='romeo@example.net'
to='benvolio@example.org'
type='probe'/>
Example 5: User's server sends initial presence to contacts with subscription="from" and subscription="both" on behalf of the user's available resource, as well as to user
示例5：用户的服务器代表用户的可用资源向subscription=“from”和subscription=“both”联系人以及用户发送初始状态
US: <presence
from='romeo@example.net/orchard'
to='juliet@example.com'/>
US: <presence
from='romeo@example.net/orchard'
to='juliet@example.com'/>
US: <presence
from='romeo@example.net/orchard'
to='mercutio@example.org'/>
US: <presence
from='romeo@example.net/orchard'
to='mercutio@example.org'/>
US: <presence
from='romeo@example.net/orchard'
to='romeo@example.net'/>
US: <presence
from='romeo@example.net/orchard'
to='romeo@example.net'/>
Example 6: Contacts' servers reply to presence probe on behalf of all available resources
示例6：联系人服务器代表所有可用资源回复状态探测
CS: <presence
from='juliet@example.com/balcony'
to='romeo@example.net'
xml:lang='en'>
<show>away</show>
<status>be right back</status>
<priority>0</priority>
</presence>
CS: <presence
from='juliet@example.com/balcony'
to='romeo@example.net'
xml:lang='en'>
<show>away</show>
<status>be right back</status>
<priority>0</priority>
</presence>
CS: <presence
from='juliet@example.com/chamber'
to='romeo@example.net'>
<priority>1</priority>
</presence>
CS: <presence
from='juliet@example.com/chamber'
to='romeo@example.net'>
<priority>1</priority>
</presence>
CS: <presence
from='benvolio@example.org/pda'
to='romeo@example.net'
xml:lang='en'>
<show>dnd</show>
<status>gallivanting</status>
</presence>
CS: <presence
from='benvolio@example.org/pda'
to='romeo@example.net'
xml:lang='en'>
<show>dnd</show>
<status>gallivanting</status>
</presence>
Example 7: Contacts' servers deliver user's initial presence to all available resources
示例7：联系人服务器向所有可用资源提供用户的初始状态
CS: <presence
from='romeo@example.net/orchard'
to='juliet@example.com'/>
CS: <presence
from='romeo@example.net/orchard'
to='juliet@example.com'/>
CS: <presence
from='romeo@example.net/orchard'
to='juliet@example.com'/>
CS: <presence
from='romeo@example.net/orchard'
to='juliet@example.com'/>
CS: <presence
from='romeo@example.net/orchard'
to='mercutio@example.org'/>
CS: <presence
from='romeo@example.net/orchard'
to='mercutio@example.org'/>
Example 8: User sends directed presence to another user not in his roster
示例8：用户向不在其花名册中的另一个用户发送直接出席
UC: <presence
from='romeo@example.net/orchard'
to='nurse@example.com'
xml:lang='en'>
<show>dnd</show>
<status>courting Juliet</status>
<priority>0</priority>
</presence>
UC: <presence
from='romeo@example.net/orchard'
to='nurse@example.com'
xml:lang='en'>
<show>dnd</show>
<status>courting Juliet</status>
<priority>0</priority>
</presence>
Now the user engages in a chat session with one of his contacts.
现在，用户与他的一个联系人进行聊天会话。
Example 9: A threaded conversation
示例9：线程化对话
CC: <message
from='juliet@example.com/balcony'
to='romeo@example.net'
type='chat'
xml:lang='en'>
<body>My ears have not yet drunk a hundred words</body>
<thread>e0ffe42b28561960c6b12b944a092794b9683a38</thread>
</message>
CC: <message
from='juliet@example.com/balcony'
to='romeo@example.net'
type='chat'
xml:lang='en'>
<body>My ears have not yet drunk a hundred words</body>
<thread>e0ffe42b28561960c6b12b944a092794b9683a38</thread>
</message>
CC: <message
from='juliet@example.com/balcony'
to='romeo@example.net'
type='chat'
xml:lang='en'>
<body>Of that tongue's utterance, yet I know the sound:</body>
<thread>e0ffe42b28561960c6b12b944a092794b9683a38</thread>
</message>
CC: <message
from='juliet@example.com/balcony'
to='romeo@example.net'
type='chat'
xml:lang='en'>
<body>Of that tongue's utterance, yet I know the sound:</body>
<thread>e0ffe42b28561960c6b12b944a092794b9683a38</thread>
</message>
CC: <message
from='juliet@example.com/balcony'
to='romeo@example.net'
type='chat'
xml:lang='en'>
<body>Art thou not Romeo, and a Montague?</body>
<thread>e0ffe42b28561960c6b12b944a092794b9683a38</thread>
</message>
CC: <message
from='juliet@example.com/balcony'
to='romeo@example.net'
type='chat'
xml:lang='en'>
<body>Art thou not Romeo, and a Montague?</body>
<thread>e0ffe42b28561960c6b12b944a092794b9683a38</thread>
</message>
UC: <message
from='romeo@example.net/orchard'
to='juliet@example.com/balcony'
type='chat'
xml:lang='en'>
<body>Neither, fair saint, if either thee dislike.</body>
<thread>e0ffe42b28561960c6b12b944a092794b9683a38</thread>
</message>
UC: <message
from='romeo@example.net/orchard'
to='juliet@example.com/balcony'
type='chat'
xml:lang='en'>
<body>Neither, fair saint, if either thee dislike.</body>
<thread>e0ffe42b28561960c6b12b944a092794b9683a38</thread>
</message>
CC: <message
from='juliet@example.com/balcony'
to='romeo@example.net/orchard'
type='chat'
xml:lang='en'>
<body>How cam'st thou hither, tell me, and wherefore?</body>
<thread>e0ffe42b28561960c6b12b944a092794b9683a38</thread>
</message>
CC: <message
from='juliet@example.com/balcony'
to='romeo@example.net/orchard'
type='chat'
xml:lang='en'>
<body>How cam'st thou hither, tell me, and wherefore?</body>
<thread>e0ffe42b28561960c6b12b944a092794b9683a38</thread>
</message>
And so on.
等等
The user can also send subsequent presence broadcast.
用户还可以发送后续状态广播。
Example 10: User sends updated available presence for broadcast
示例10：用户发送更新的可用状态以进行广播
UC: <presence xml:lang='en'>
<show>away</show>
<status>I shall return!</status>
<priority>1</priority>
</presence>
UC: <presence xml:lang='en'>
<show>away</show>
<status>I shall return!</status>
<priority>1</priority>
</presence>
Example 11: User's server broadcasts updated presence to the contacts who have a subscription of type "both" or "from" (but not to the entity to which the user sent directed presence)
示例11：用户的服务器向订阅类型为“两者”或“发件人”的联系人广播更新的状态（但不向用户向其发送定向状态的实体）
US: <presence
from='romeo@example.net/orchard'
to='juliet@example.com'
xml:lang='en'>
<show>away</show>
<status>I shall return!</status>
<priority>1</priority>
</presence>
US: <presence
from='romeo@example.net/orchard'
to='juliet@example.com'
xml:lang='en'>
<show>away</show>
<status>I shall return!</status>
<priority>1</priority>
</presence>
US: <presence
from='romeo@example.net/orchard'
to='mercutio@example.org'
xml:lang='en'>
<show>away</show>
<status>I shall return!</status>
<priority>1</priority>
</presence>
US: <presence
from='romeo@example.net/orchard'
to='mercutio@example.org'
xml:lang='en'>
<show>away</show>
<status>I shall return!</status>
<priority>1</priority>
</presence>
Example 12: Contacts' servers deliver updated presence
示例12：联系人的服务器提供更新的状态
CS: <presence
from='romeo@example.net/orchard'
to='juliet@example.com'
xml:lang='en'>
<show>away</show>
<status>I shall return!</status>
<priority>1</priority>
</presence>
CS: <presence
from='romeo@example.net/orchard'
to='juliet@example.com'
xml:lang='en'>
<show>away</show>
<status>I shall return!</status>
<priority>1</priority>
</presence>
CS: <presence
from='romeo@example.net/orchard'
to='juliet@example.com'
xml:lang='en'>
<show>away</show>
<status>I shall return!</status>
<priority>1</priority>
</presence>
CS: <presence
from='romeo@example.net/orchard'
to='juliet@example.com'
xml:lang='en'>
<show>away</show>
<status>I shall return!</status>
<priority>1</priority>
</presence>
CS: <presence
from='romeo@example.net/orchard'
to='mercutio@example.org'
xml:lang='en'>
<show>away</show>
<status>I shall return!</status>
<priority>1</priority>
</presence>
CS: <presence
from='romeo@example.net/orchard'
to='mercutio@example.org'
xml:lang='en'>
<show>away</show>
<status>I shall return!</status>
<priority>1</priority>
</presence>
Example 13: One of the contact's resources broadcasts unavailable notification
示例13：联系人的一个资源广播不可用通知
CC: <presence from='juliet@example.com/chamber' type='unavailable'/>
CC: <presence from='juliet@example.com/chamber' type='unavailable'/>
Example 14: Contact's server sends unavailable notification to user
示例14：联系人的服务器向用户发送不可用通知
CS: <presence
from='juliet@example.com/chamber'
to='romeo@example.net'
type='unavailable'/>
CS: <presence
from='juliet@example.com/chamber'
to='romeo@example.net'
type='unavailable'/>
Now the user ends his presence session.
现在，用户结束他的状态会话。
Example 15: User sends unavailable notification
示例15：用户发送不可用通知
UC: <presence type='unavailable' xml:lang='en'>
<status>gone home</status>
</presence>
UC: <presence type='unavailable' xml:lang='en'>
<status>gone home</status>
</presence>
Example 16: User's server broadcasts unavailable notification to contacts as well as to the entity to whom the user sent directed presence
示例16：用户的服务器向联系人以及用户向其发送定向状态的实体广播不可用通知
US: <presence
from='romeo@example.net/orchard'
to='juliet@example.com'
type='unavailable'
xml:lang='en'>
<status>gone home</status>
</presence>
US: <presence
from='romeo@example.net/orchard'
to='juliet@example.com'
type='unavailable'
xml:lang='en'>
<status>gone home</status>
</presence>
US: <presence
from='romeo@example.net/orchard'
to='mercutio@example.org'
type='unavailable'
xml:lang='en'>
<status>gone home</status>
</presence>
US: <presence
from='romeo@example.net/orchard'
to='mercutio@example.org'
type='unavailable'
xml:lang='en'>
<status>gone home</status>
</presence>
US: <presence
from='romeo@example.net/orchard'
to='nurse@example.com'
type='unavailable'
xml:lang='en'>
<status>gone home</status>
</presence>
US: <presence
from='romeo@example.net/orchard'
to='nurse@example.com'
type='unavailable'
xml:lang='en'>
<status>gone home</status>
</presence>
Finally the user closes his stream and the server responds in kind.
最后，用户关闭流，服务器以实物形式响应。
Example 17: User closes stream
示例17：用户关闭流
UC: </stream:stream>
UC: </stream:stream>
Example 18: User's server closes stream
示例18：用户的服务器关闭流
US: </stream:stream>
US: </stream:stream>
THE END
结局
Basic server rules for processing XML stanzas are defined in [XMPP-CORE], and the reader is referred to that specification for underlying rules and security implications. This section defines supplementary rules for XMPP instant messaging and presence servers.
处理XML节的基本服务器规则在[XMPP-CORE]中定义，读者可以参考该规范了解底层规则和安全含义。本节定义了XMPP即时消息和状态服务器的补充规则。
Some delivery rules defined in this section specify the use of "offline storage", i.e., the server's act of storing a message stanza on behalf of the user and then delivering it when the user next becomes available. For recommendations regarding offline message storage, refer to [XEP-0160].
本节中定义的一些传递规则规定了“脱机存储”的使用，即服务器代表用户存储消息节，然后在用户下次可用时传递消息节的行为。有关脱机消息存储的建议，请参阅[XEP-0160]。
[XMPP-CORE] discusses general considerations for stanza delivery, in particular the tradeoffs between (i) providing an acceptable level of service regarding stanza delivery and (ii) preventing directory harvesting attacks and presence leaks. However, the concept of a directory harvesting attack does not apply if a contact is known to and trusted by a user (because the contact is in the user's roster as described under Section 2). Similarly, the concept of a presence leak does not apply if a contact is authorized to know a user's presence (by means of a presence subscription as described under Section 3) or if the user has voluntarily sent presence to an entity (by means of directed presence as described under Section 4.6). Therefore, in cases where the following sections guard against directory harvesting attacks and presence leaks by providing an alternative of (a) silently ignoring a stanza or (b) returning an error, a server SHOULD return an error if the originating entity is in the user's roster (when the error would reveal whether the user's account exists) or is authorized to receive presence from the user or has received directed presence from the user (when the error would reveal the presence of a user's resource).
[XMPP-CORE]讨论节交付的一般注意事项，特别是（i）提供节交付的可接受服务级别和（ii）防止目录捕获攻击和存在泄漏之间的权衡。但是，如果用户知道并信任某个联系人（因为该联系人在第2节所述的用户名册中），则目录捕获攻击的概念不适用。类似地，如果联系人被授权知道用户的存在（通过第3节所述的存在订阅），或者如果用户自愿向实体发送存在（通过第4.6节所述的定向存在），则存在泄漏的概念不适用。因此，如果以下部分通过提供（a）静默忽略节或（b）返回错误的替代方案来防止目录捕获攻击和存在泄漏，则如果发起实体在用户名册中，服务器应返回错误（错误将显示用户帐户是否存在）或者被授权接收来自用户的存在，或者已经接收来自用户的定向存在（当错误将显示用户资源的存在时）。
Security Warning: All of the stanza processing rules described below are defined with the understanding that they will be applied subject to enforcement of relevant privacy and security policies, such as those deployed by means of [XEP-0016] or [XEP-0191]. The conformance language (MUST, SHOULD, etc.) in the following sections is not meant to override any such local service policies.
安全警告：以下所述的所有节处理规则的定义均应理解，这些规则将根据相关隐私和安全政策的实施而应用，例如通过[XEP-0016]或[XEP-0191]部署的隐私和安全政策。以下章节中的一致性语言（必须、应该等）并不意味着覆盖任何此类本地服务策略。
If the stanza possesses no 'to' attribute, the rules defined in [XMPP-CORE] apply.
如果节不具有“to”属性，则应用[XMPP-CORE]中定义的规则。
If the domainpart of the address contained in the 'to' attribute of an outbound stanza does not match a configured domain of the server itself, then the rules provided in Section 10.4 of [XMPP-CORE] apply.
如果出站节的“to”属性中包含的地址的domainpart与服务器本身的配置域不匹配，则[XMPP-CORE]第10.4节中提供的规则适用。
Interoperability Note: RFC 3921 specified how to use the _im._xmpp and _pres._xmpp SRV records [IMP-SRV] as a fallback method for discovering whether a remote instant messaging and presence service communicates via XMPP. Because those SRV records have not been widely deployed, this document no longer specifies their use, and new implementations are not encouraged.
互操作性说明：RFC 3921指定了如何使用_im._xmpp和_pres._xmppsrv记录[IMP-SRV]作为回退方法，以发现远程即时消息和状态服务是否通过xmpp进行通信。由于这些SRV记录尚未广泛部署，本文档不再指定它们的用途，也不鼓励新的实现。
If the domainpart of the JID contained in the 'to' attribute matches one of the configured domains of the server, the domain is serviced by the server itself (not by a specialized local service), and the JID is of the form <domainpart> or <domainpart/resourcepart>, the rules defined in [XMPP-CORE] apply.
如果“to”属性中包含的JID的domainpart与服务器的一个配置域相匹配，则该域由服务器本身提供服务（而不是由专门的本地服务），并且JID的形式为<domainpart>或<domainpart/resourcepart>，则[XMPP-CORE]中定义的规则适用。
If the 'to' address specifies a bare JID <localpart@domainpart> or full JID <localpart@domainpart/resourcepart> where the domainpart of the JID matches a configured domain that is serviced by the server itself, the server MUST proceed as follows.
如果“to”地址指定了裸JID<localpart@domainpart>还是完全的JID<localpart@domainpart/resourcepart>如果JID的domainpart与服务器本身提供服务的已配置域相匹配，则服务器必须按照以下步骤进行操作。
If the user account identified by the 'to' attribute does not exist, how the stanza is processed depends on the stanza type.
如果“to”属性标识的用户帐户不存在，则节的处理方式取决于节类型。
o For an IQ stanza, the server MUST return a <service-unavailable/> stanza error to the sender.
o 对于IQ节，服务器必须向发送方返回<service unavailable/>节错误。
o For a message stanza, the server MUST either (a) silently ignore the message or (b) return a <service-unavailable/> stanza error to the sender.
o 对于消息节，服务器必须（a）静默忽略消息，或（b）向发送方返回<service unavailable/>节错误。
o For a presence stanza with no 'type' attribute or a 'type' attribute of "unavailable", the server MUST silently ignore the stanza.
o 对于没有“type”属性或“type”属性为“unavailable”的状态节，服务器必须以静默方式忽略该节。
o For a presence stanza of type "subscribe", "subscribed", "unsubscribe", or "unsubscribed", the server MUST silently ignore the stanza.
o 对于类型为“subscribe”、“subscribed”、“unsubscribe”或“unsubscribed”的状态节，服务器必须静默地忽略该节。
o For a presence stanza of type "probe", the server MUST either (a) silently ignore the stanza or (b) return a presence stanza of type "unsubscribed".
o 对于类型为“probe”的状态节，服务器必须（a）静默忽略该节，或者（b）返回类型为“unsubscribed”的状态节。
If the JID contained in the 'to' attribute is of the form <localpart@domainpart>, then the server MUST adhere to the following rules.
如果“to”属性中包含的JID的形式为<localpart@domainpart>，则服务器必须遵守以下规则。
If there is at least one available resource or connected resource, how the stanza is processed depends on the stanza type.
如果至少有一个可用资源或连接的资源，则节的处理方式取决于节类型。
For a message stanza of type "normal":
对于“正常”类型的消息节：
o If all of the available resources have a negative presence priority then the server SHOULD either (a) store the message offline for later delivery or (b) return a stanza error to the sender, which SHOULD be <service-unavailable/>.
o 如果所有可用资源的状态优先级均为负，则服务器应（a）脱机存储邮件以供以后传递，或（b）向发件人返回节错误，该节错误应为<service unavailable/>。
o If there is one available resource with a non-negative presence priority then the server MUST deliver the message to that resource.
o 如果存在一个具有非负存在优先级的可用资源，则服务器必须将消息传递给该资源。
o If there is more than one resource with a non-negative presence priority then the server MUST either (a) deliver the message to the "most available" resource or resources (according to the server's implementation-specific algorithm, e.g., treating the resource or resources with the highest presence priority as "most available") or (b) deliver the message to all of the non-negative resources.
o 如果存在多个具有非负存在优先级的资源，则服务器必须（a）将消息传递给“最可用”资源（根据服务器的实现特定算法，例如，将具有最高存在优先级的资源视为“最可用”）或（b）将消息传递给所有非负面资源。
For a message stanza of type "chat":
对于“chat”类型的消息节：
o If the only available resource has a negative presence priority then the server SHOULD either (a) store the message offline for later delivery or (b) return a stanza error to the sender, which SHOULD be <service-unavailable/>.
o 如果唯一可用的资源具有负的存在优先级，则服务器应（a）脱机存储邮件以供以后传递，或（b）向发件人返回节错误，该节错误应为<service unavailable/>。
o If the only available resource has a non-negative presence priority then the server MUST deliver the message to that resource.
o 如果唯一可用的资源具有非负的存在优先级，则服务器必须将消息传递给该资源。
o If there is more than one resource with a non-negative presence priority then the server MUST either (a) deliver the message to the "most available" resource or resources (according to the server's implementation-specific algorithm, e.g., treating the resource or resources with the highest presence priority as "most available") or (b) deliver the message to all of the non-negative resources that have opted in to receive chat messages.
o 如果存在多个具有非负存在优先级的资源，则服务器必须（a）将消息传递给“最可用”资源（根据服务器的实现特定算法，例如，将具有最高存在优先级的资源视为“最可用”）或（b）将消息传递给所有选择接收聊天消息的非负面资源。
For a message stanza of type "groupchat", the server MUST NOT deliver the stanza to any of the available resources but instead MUST return a stanza error to the sender, which SHOULD be <service-unavailable/>.
对于类型为“groupchat”的消息节，服务器不得将该节传递给任何可用资源，而是必须向发件人返回节错误，该错误应为<service unavailable/>。
For a message stanza of type "headline":
对于“headline”类型的消息节：
o If the only available resource has a negative presence priority then the server MUST silently ignore the stanza.
o 如果唯一可用的资源具有负的存在优先级，那么服务器必须静默地忽略该节。
o If the only available resource has a non-negative presence priority then the server MUST deliver the message to that resource.
o 如果唯一可用的资源具有非负的存在优先级，则服务器必须将消息传递给该资源。
o If there is more than one resource with a non-negative presence priority then the server MUST deliver the message to all of the non-negative resources.
o 如果有多个资源具有非负存在优先级，则服务器必须将消息传递给所有非负资源。
For a message stanza of type "error", the server MUST silently ignore the message.
对于类型为“error”的消息节，服务器必须以静默方式忽略该消息。
However, for any message type the server MUST NOT deliver the stanza to any available resource with a negative priority; if the only available resource has a negative priority, the server SHOULD handle the message as if there were no available resources or connected resources as described under Section 8.5.2.2.
但是，对于任何消息类型，服务器不得将节传递给任何具有负优先级的可用资源；如果唯一可用的资源具有负优先级，则服务器应按照第8.5.2.2节中所述，将消息当作没有可用资源或连接的资源来处理。
In all cases, the server MUST NOT rewrite the 'to' attribute (i.e., it MUST leave it as <localpart@domainpart> rather than change it to <localpart@domainpart/resourcepart>).
在所有情况下，服务器都不得重写“to”属性（即，必须将其保留为<localpart@domainpart>而不是把它改成<localpart@domainpart/资源部分>）。
For a presence stanza with no type or of type "unavailable", the server MUST deliver it to all available resources.
对于没有类型或类型为“不可用”的状态节，服务器必须将其交付给所有可用资源。
For a presence stanza of type "subscribe", "subscribed", "unsubscribe", or "unsubscribed", the server MUST adhere to the rules defined under Section 3 and summarized under Appendix A.
对于类型为“订阅”、“已订阅”、“取消订阅”或“取消订阅”的状态节，服务器必须遵守第3节中定义并在附录a中总结的规则。
For a presence stanza of type "probe", the server MUST handle it directly as described under Section 4.3.
对于“probe”类型的状态节，服务器必须按照第4.3节所述直接处理。
In all cases, the server MUST NOT rewrite the 'to' attribute (i.e., it MUST leave it as <localpart@domainpart> rather than change it to <localpart@domainpart/resourcepart>).
在所有情况下，服务器都不得重写“to”属性（即，必须将其保留为<localpart@domainpart>而不是把它改成<localpart@domainpart/资源部分>）。
For an IQ stanza, the server itself MUST reply on behalf of the user with either an IQ result or an IQ error, and MUST NOT deliver the IQ stanza to any of the user's available resources. Specifically, if the semantics of the qualifying namespace define a reply that the
对于IQ节，服务器本身必须代表用户回复IQ结果或IQ错误，并且不得将IQ节传递给用户的任何可用资源。具体来说，如果限定命名空间的语义定义了
server can provide on behalf of the user, then the server MUST reply to the stanza on behalf of the user by returning either an IQ stanza of type "result" or an IQ stanza of type "error" that is appropriate to the original payload; if not, then the server MUST reply with a <service-unavailable/> stanza error.
服务器可以代表用户提供，然后服务器必须通过返回适合于原始有效负载的“result”类型的IQ节或“error”类型的IQ节来代表用户回复该节；如果没有，则服务器必须回复<service unavailable/>节错误。
If there are no available resources or connected resources associated with the user, how the stanza is processed depends on the stanza type.
如果没有可用资源或与用户关联的已连接资源，则节的处理方式取决于节类型。
For a message stanza of type "normal" or "chat", the server SHOULD either (a) add the message to offline storage or (b) return a stanza error to the sender, which SHOULD be <service-unavailable/>.
对于类型为“正常”或“聊天”的消息节，服务器应（a）将消息添加到脱机存储或（b）向发件人返回节错误，该节错误应为<service unavailable/>。
For a message stanza of type "groupchat", the server MUST return an error to the sender, which SHOULD be <service-unavailable/>.
对于“groupchat”类型的消息节，服务器必须向发件人返回一个错误，该错误应为<service unavailable/>。
For a message stanza of type "headline" or "error", the server MUST silently ignore the message.
对于类型为“headline”或“error”的消息节，服务器必须以静默方式忽略该消息。
For a presence stanza with no type or of type "unavailable", the server SHOULD silently ignore the stanza by not storing it for later delivery and not replying to it on behalf of the user.
对于没有类型或类型为“不可用”的状态节，服务器应通过不存储该节以供以后传递，也不代表用户回复来忽略该节。
For a presence stanza of type "subscribe", "subscribed", "unsubscribe", or "unsubscribed", the server MUST adhere to the rules defined under Section 3 and summarized under Appendix A.
对于类型为“订阅”、“已订阅”、“取消订阅”或“取消订阅”的状态节，服务器必须遵守第3节中定义并在附录a中总结的规则。
For a presence stanza of type "probe", the server MUST handle it directly as described under Section 4.3.
对于“probe”类型的状态节，服务器必须按照第4.3节所述直接处理。
For an IQ stanza, the server itself MUST reply on behalf of the user with either an IQ result or an IQ error. Specifically, if the semantics of the qualifying namespace define a reply that the server can provide on behalf of the user, then the server MUST reply to the stanza on behalf of the user by returning either an IQ stanza of type "result" or an IQ stanza of type "error" that is appropriate to the original payload; if not, then the server MUST reply with a <service-unavailable/> stanza error.
对于IQ节，服务器本身必须代表用户回复IQ结果或IQ错误。具体地说，如果限定名称空间的语义定义了服务器可以代表用户提供的应答，那么服务器必须通过返回适合于原始有效负载的“result”类型的IQ节或“error”类型的IQ节来代表用户应答该节；如果没有，则服务器必须回复<service unavailable/>节错误。
If the domainpart of the JID contained in the 'to' attribute of an inbound stanza matches one of the configured domains of the server itself and the JID contained in the 'to' attribute is of the form <localpart@domainpart/resourcepart>, then the server MUST adhere to the following rules.
如果入站节的“to”属性中包含的JID的domainpart与服务器本身的一个配置域匹配，并且“to”属性中包含的JID的形式为<localpart@domainpart/resourcepart>，则服务器必须遵守以下规则。
If an available resource or connected resource exactly matches the full JID, how the stanza is processed depends on the stanza type.
如果可用资源或连接的资源与完整JID完全匹配，则节的处理方式取决于节类型。
o For an IQ stanza of type "get" or "set", if the intended recipient does not share presence with the requesting entity either by means of a presence subscription of type "both" or "from" or by means of directed presence, then the server SHOULD NOT deliver the IQ stanza but instead SHOULD return a <service-unavailable/> stanza error to the requesting entity. This policy helps to prevent presence leaks (see Section 11).
o 对于类型为“get”或“set”的IQ节，如果预期接收者未通过类型为“两者”或“发件人”的状态订阅或通过定向状态与请求实体共享状态，然后，服务器不应该传递IQ节，而是应该向请求实体返回<service unavailable/>节错误。该政策有助于防止存在泄漏（见第11节）。
o For an IQ stanza of type "result" or "error", the server MUST deliver the stanza to the resource.
o 对于类型为“result”或“error”的IQ节，服务器必须将该节传递给资源。
o For a message stanza, the server MUST deliver the stanza to the resource.
o 对于消息节，服务器必须将该节传递给资源。
o For a presence stanza with no 'type' attribute or a 'type' attribute of "unavailable", the server MUST deliver the stanza to the resource.
o 对于没有“type”属性或“type”属性为“unavailable”的状态节，服务器必须将该节传递给资源。
o For a presence stanza of type "subscribe", "subscribed", "unsubscribe", or "unsubscribed", the server MUST follow the guidelines provided under Section 3.
o 对于类型为“订阅”、“已订阅”、“取消订阅”或“取消订阅”的状态节，服务器必须遵循第3节提供的指南。
o For a presence stanza of type "probe", the server MUST follow the guidelines provided under Section 4.3.
o 对于“probe”类型的状态节，服务器必须遵循第4.3节提供的指南。
If no available resource or connected resource exactly matches the full JID, how the stanza is processed depends on the stanza type.
如果没有与完整JID完全匹配的可用资源或连接资源，则节的处理方式取决于节类型。
For a message stanza of type "normal", "groupchat", or "headline", the server MUST either (a) silently ignore the stanza or (b) return an error stanza to the sender, which SHOULD be <service-unavailable/>.
对于类型为“正常”、“groupchat”或“headline”的消息节，服务器必须（a）静默忽略该节，或（b）向发件人返回错误节，该节应为<service unavailable/>。
For a message stanza of type "chat":
对于“chat”类型的消息节：
o If there is no available or connected resource, the server MUST either (a) store the message offline for later delivery or (b) return an error stanza to the sender, which SHOULD be <service-unavailable/>.
o 如果没有可用或连接的资源，服务器必须（a）脱机存储邮件以供以后传递，或（b）向发件人返回错误节，该节应为<service unavailable/>。
o If all of the available resources have a negative presence priority then the server SHOULD (a) store the message offline for later delivery or (b) return a stanza error to the sender, which SHOULD be <service-unavailable/>.
o 如果所有可用资源的状态优先级均为负，则服务器应（a）脱机存储邮件以供以后传递，或（b）向发件人返回节错误，该节错误应为<service unavailable/>。
o If there is one available resource with a non-negative presence priority then the server MUST deliver the message to that resource.
o 如果存在一个具有非负存在优先级的可用资源，则服务器必须将消息传递给该资源。
o If there is more than one resource with a non-negative presence priority then the server MUST either (a) deliver the message to the "most available" resource or resources (according to the server's implementation-specific algorithm, e.g., treating the resource or resources with the highest presence priority as "most available") or (b) deliver the message to all of the non-negative resources that have opted in to receive chat messages.
o 如果存在多个具有非负存在优先级的资源，则服务器必须（a）将消息传递给“最可用”资源（根据服务器的实现特定算法，例如，将具有最高存在优先级的资源视为“最可用”）或（b）将消息传递给所有选择接收聊天消息的非负面资源。
For a message stanza of type "error", the server MUST silently ignore the stanza.
对于类型为“error”的消息节，服务器必须以静默方式忽略该节。
For a presence stanza with no 'type' attribute or a 'type' attribute of "unavailable", the server MUST silently ignore the stanza.
对于没有“type”属性或“type”属性为“unavailable”的状态节，服务器必须以静默方式忽略该节。
For a presence stanza of type "subscribe", the server MUST follow the guidelines provided under Section 3.1.3.
对于“订阅”类型的状态节，服务器必须遵循第3.1.3节提供的指南。
For a presence stanza of type "subscribed", "unsubscribe", or "unsubscribed", the server MUST ignore the stanza.
对于类型为“subscribed”、“unsubscribe”或“unsubscribed”的状态节，服务器必须忽略该节。
For a presence stanza of type "probe", the server MUST follow the guidelines provided under Section 4.3.
对于“probe”类型的状态节，服务器必须遵循第4.3节提供的指南。
For an IQ stanza, the server MUST return a <service-unavailable/> stanza error to the sender.
对于IQ节，服务器必须向发送方返回<service unavailable/>节错误。
The following table summarizes the message (not stanza) delivery rules described earlier in this section. The left column shows various combinations of conditions (non-existent account, no active resources, only one resource and it has a negative presence priority, only one resource and it has a non-negative presence priority, or more than one resource and each one has a non-negative presence priority) and 'to' addresses (bare JID, full JID matching an available resource, or full JID matching no available resource). The subsequent columns list the four primary message types (normal, chat, groupchat, or headline) along with six possible delivery options: storing the message offline (O), bouncing the message with a stanza error (E), silently ignoring the message (S), delivering the message to the resource specified in the 'to' address (D), delivering the message to the "most available" resource or resources according to the server's implementation-specific algorithm, e.g., treating the resource or resources with the highest presence priority as "most available" (M), or delivering the message to all resources with non-negative presence priority (A -- where for chat messages "all resources" can mean the set of resources that have explicitly opted in to receiving every chat message). The '/' character stands for "exclusive or". The server SHOULD observe the rules given in section 8.1 when choosing which action to take for a particular message.
下表总结了本节前面介绍的邮件（非节）传递规则。左列显示了各种条件组合（不存在帐户、无活动资源、只有一个资源具有负的存在优先级、只有一个资源具有非负的存在优先级、或多个资源且每个资源具有非负的存在优先级）和“到”地址（裸JID、与可用资源匹配的完整JID或与无可用资源匹配的完整JID）。后面的列列出了四种主要消息类型（普通、聊天、groupchat或标题）以及六种可能的传递选项：脱机存储消息（O）、使用节错误（E）跳转消息、以静默方式忽略消息，将消息传递到“to”地址（D）中指定的资源，根据服务器的实现特定算法将消息传递到“最可用”资源，例如，将具有最高存在优先级的一个或多个资源视为“最可用”（M），或将消息传递给具有非负状态优先级的所有资源（A--其中对于聊天消息，“所有资源”可以表示已明确选择接收每条聊天消息的资源集）。“/”字符表示“异或”。服务器在选择对特定邮件采取何种操作时，应遵守第8.1节中给出的规则。
Table 1: Message Delivery Rules
表1：消息传递规则
+----------------------------------------------------------+
| Condition | Normal | Chat | Groupchat | Headline |
+----------------------------------------------------------+
| ACCOUNT DOES NOT EXIST |
| bare | S/E | S/E | E | S |
| full | S/E | S/E | S/E | S/E |
+----------------------------------------------------------+
| ACCOUNT EXISTS, BUT NO ACTIVE RESOURCES |
| bare | O/E | O/E | E | S |
| full (no match) | S/E | O/E | S/E | S/E |
+----------------------------------------------------------+
| 1+ NEGATIVE RESOURCES BUT ZERO NON-NEGATIVE RESOURCES |
| bare | O/E | O/E | E | S |
| full match | D | D | D | D |
| full no match | S/E | O/E | S/E | S/E |
+----------------------------------------------------------+
| 1 NON-NEGATIVE RESOURCE |
| bare | D | D | E | D |
| full match | D | D | D | D |
| full no match | S/E | D | S/E | S/E |
+----------------------------------------------------------+
| 1+ NON-NEGATIVE RESOURCES |
| bare | M/A | M/A* | E | A |
| full match | D | D/A* | D | D |
| full no match | S/E | M/A* | S/E | S/E |
+----------------------------------------------------------+
+----------------------------------------------------------+
| Condition | Normal | Chat | Groupchat | Headline |
+----------------------------------------------------------+
| ACCOUNT DOES NOT EXIST |
| bare | S/E | S/E | E | S |
| full | S/E | S/E | S/E | S/E |
+----------------------------------------------------------+
| ACCOUNT EXISTS, BUT NO ACTIVE RESOURCES |
| bare | O/E | O/E | E | S |
| full (no match) | S/E | O/E | S/E | S/E |
+----------------------------------------------------------+
| 1+ NEGATIVE RESOURCES BUT ZERO NON-NEGATIVE RESOURCES |
| bare | O/E | O/E | E | S |
| full match | D | D | D | D |
| full no match | S/E | O/E | S/E | S/E |
+----------------------------------------------------------+
| 1 NON-NEGATIVE RESOURCE |
| bare | D | D | E | D |
| full match | D | D | D | D |
| full no match | S/E | D | S/E | S/E |
+----------------------------------------------------------+
| 1+ NON-NEGATIVE RESOURCES |
| bare | M/A | M/A* | E | A |
| full match | D | D/A* | D | D |
| full no match | S/E | M/A* | S/E | S/E |
+----------------------------------------------------------+
* For messages of type "chat", a server SHOULD NOT act in accordance with option (A) unless clients can explicitly opt in to receiving all chat messages; however, methods for opting in are outside the scope of this specification.
* 对于“聊天”类型的消息，服务器不应按照选项（a）行事，除非客户端可以明确选择接收所有聊天消息；但是，选择的方法不在本规范的范围内。
The addresses of XMPP entities as used in communication over an XMPP network (e.g., in the 'from' and 'to' addresses of an XML stanza) MUST NOT be prepended with a Uniform Resource Identifier [URI] scheme.
在通过XMPP网络进行通信时使用的XMPP实体的地址（例如，在XML节的“from”和“to”地址中）不得以统一资源标识符[URI]方案作为前缀。
However, an application that is external to XMPP itself (e.g., a page on the World Wide Web) might need to identify an XMPP entity either as a URI or as an Internationalized Resource Identifier [IRI], and an XMPP client might need to interact with such an external application (for example, an XMPP client might be invoked by clicking a link provided on a web page). In the context of such interactions, XMPP clients are encouraged to handle addresses that are encoded as
但是，XMPP本身外部的应用程序（例如，万维网上的页面）可能需要将XMPP实体标识为URI或国际化资源标识符[IRI]，并且XMPP客户端可能需要与此类外部应用程序交互（例如，可以通过单击网页上提供的链接来调用XMPP客户端）。在这种交互环境中，鼓励XMPP客户端处理编码为
"xmpp:" URIs and IRIs as specified in [XMPP-URI] and further described in [XEP-0147]. Although XMPP clients are also encouraged to handle addresses that are encoded as "im:" URIs as specified in [CPIM] and "pres:" URIs as specified in [CPP], they can do so by removing the "im:" or "pres:" scheme and entrusting address resolution to the server as specified under Section 8.3.
“xmpp:[xmpp-URI]中规定并在[XEP-0147]中进一步描述的URI和IRI。尽管也鼓励XMPP客户端处理[CPIM]中指定的编码为“im:”URI的地址和[CPP]中指定的“pres:”URI的地址，但它们可以通过删除“im:”或“pres:”方案并按照第8.3节的规定将地址解析委托给服务器来实现。
For internationalization considerations, refer to the relevant section of [XMPP-CORE].
有关国际化注意事项，请参阅[XMPP-CORE]的相关章节。
Core security considerations for XMPP are provided in Section 13 of [XMPP-CORE], including discussion of channel encryption, authentication, information leaks, denial-of-service attacks, and interdomain federation.
[XMPP-Core]的第13节提供了XMPP的核心安全注意事项，包括对通道加密、身份验证、信息泄漏、拒绝服务攻击和域间联合的讨论。
Section 13.1 of [XMPP-CORE] outlines the architectural roles of clients and servers in typical deployments of XMPP, and discusses the security properties associated with those roles. These roles have an impact on the security of instant messages, presence subscriptions, and presence notifications as described in this document. In essence, an XMPP user registers (or has provisioned) an account on an XMPP server and therefore places some level of trust in the server to complete various tasks on the user's behalf, enforce security policies, etc. Thus it is the server's responsibility to:
[XMPP-CORE]的第13.1节概述了XMPP典型部署中客户端和服务器的体系结构角色，并讨论了与这些角色相关的安全属性。如本文档所述，这些角色对即时消息、状态订阅和状态通知的安全性有影响。本质上，XMPP用户在XMPP服务器上注册（或已设置）帐户，因此在服务器上建立一定程度的信任，以代表用户完成各种任务，强制执行安全策略等。因此，服务器有责任：
1. Preferably mandate the use of channel encryption for communication with local clients and remote servers.
1. 最好强制使用通道加密与本地客户端和远程服务器通信。
2. Authenticate any client that wishes to access the user's account.
2. 验证任何希望访问用户帐户的客户端。
3. Process XML stanzas to and from clients that have authenticated as the user (specifically with regard to instant messaging and presence functionality, store the user's roster, process inbound and outbound subscription requests and responses, generate and handle presence probes, broadcast outbound presence notifications, route outbound messages, and deliver inbound messages and presence notifications).
3. 处理与作为用户进行身份验证的客户端之间的XML节（特别是关于即时消息和状态功能，存储用户的花名册、处理入站和出站订阅请求和响应、生成和处理状态探测、广播出站状态通知、路由出站消息以及传递入站消息和状态通知）。
As discussed in Sections 13.1 and 13.4 of [XMPP-CORE], even if the server fulfills the foregoing responsibilities, the client does not have any assurance that stanzas it might exchange with other clients (whether on the same server or a remote server) are protected for all hops along the XMPP communication path, or within the server itself. It is the responsibility of the client to use an appropriate
如[XMPP-CORE]第13.1节和第13.4节所述，即使服务器履行了上述职责，客户机也无法保证其可能与其他客户机（无论是在同一台服务器上还是远程服务器上）交换的节在XMPP通信路径上或服务器本身内的所有跃点都受到保护。客户有责任使用适当的
technology for encryption and signing of XML stanzas if it wishes to ensure end-to-end confidentiality and integrity of its communications.
如果希望确保通信的端到端机密性和完整性，则使用XML节加密和签名技术。
Additional considerations that apply only to instant messaging and presence applications of XMPP are defined in several places within this document; specifically:
本文档中的几个地方定义了仅适用于XMPP即时消息和状态应用程序的其他注意事项；明确地：
o When a server processes an inbound presence stanza of type "probe" whose intended recipient is a user associated with one of the server's configured domains, the server MUST NOT reveal the user's presence if the sender is an entity that is not authorized to receive that information as determined by presence subscriptions (see Section 4).
o 当服务器处理类型为“probe”的入站状态节时，其预期收件人是与服务器配置域之一关联的用户，如果发件人是未经授权接收状态订阅确定的信息的实体，则服务器不得透露该用户的状态（见第4节）。
o A user's server MUST NOT leak the user's network availability to entities who are not authorized to know the user's presence. In XMPP itself, authorization takes the form of an explicit subscription from a contact to the user (as described under Section 3). However, some XMPP deployments might consider an entity to be authorized if there is an existing trust relationship between the entity and the user who is generating presence information (as an example, a corporate deployment of XMPP might automatically add the user's presence information to a private directory of employees if the organization mandates the sharing of presence information as part of an employment agreement).
o 用户的服务器不得将用户的网络可用性泄露给无权了解用户存在的实体。在XMPP本身中，授权采用从联系人到用户的显式订阅的形式（如第3节所述）。然而，如果存在实体和正在生成存在信息的用户之间存在现有的信任关系，则某些XMPP部署可能会考虑授权实体。（例如，如果组织强制将共享状态信息作为雇佣协议的一部分，XMPP的公司部署可能会自动将用户的状态信息添加到员工的私有目录中）。
o When a server processes an outbound presence stanza with no type or of type "unavailable", it MUST follow the rules defined under Section 4 in order to ensure that such presence information is not sent to entities that are not authorized to know such information.
o 当服务器处理无类型或类型为“不可用”的出站状态节时，它必须遵循第4节中定义的规则，以确保此类状态信息不会发送给无权了解此类信息的实体。
o A client MAY ignore the <status/> element when contained in a presence stanza of type "subscribe", "unsubscribe", "subscribed", or "unsubscribed"; this can help prevent "presence subscription spam".
o 当包含在类型为“subscribe”、“unsubscribe”、“subscribed”或“unsubscribed”的状态节中时，客户端可以忽略<status/>元素；这有助于防止“状态订阅垃圾邮件”。
This section describes a protocol feature set that summarizes the conformance requirements of this specification. This feature set is appropriate for use in software certification, interoperability testing, and implementation reports. For each feature, this section provides the following information:
本节描述了协议功能集，该功能集总结了本规范的一致性要求。此功能集适用于软件认证、互操作性测试和实施报告。对于每个功能，本节提供以下信息：
o A human-readable name
o 人名
o An informational description
o 信息性描述
o A reference to the particular section of this document that normatively defines the feature
o 对本文件中规范性定义特征的特定章节的参考
o Whether the feature applies to the Client role, the Server role, or both (where "N/A" signifies that the feature is not applicable to the specified role)
o 该功能是否适用于客户端角色、服务器角色或两者（其中“N/A”表示该功能不适用于指定角色）
o Whether the feature MUST or SHOULD be implemented, where the capitalized terms are to be understood as described in [KEYWORDS]
o 是否必须或应该实施该功能，其中大写术语应按照[关键字]中所述理解
The feature set specified here attempts to adhere to the concepts and formats proposed by Larry Masinter within the IETF's NEWTRK Working Group in 2005, as captured in [INTEROP]. Although this feature set is more detailed than called for by [REPORTS], it provides a suitable basis for the generation of implementation reports to be submitted in support of advancing this specification from Proposed Standard to Draft Standard in accordance with [PROCESS].
此处指定的功能集试图遵循Larry Masinter于2005年在IETF的NEWTRK工作组中提出的概念和格式，如[INTEROP]中所述。尽管该功能集比[报告]要求的更详细，但它为生成提交的实施报告提供了合适的基础，以支持根据[过程]将本规范从拟定标准推进到标准草案。
Feature: message-body Description: Support the <body/> child element of the <message/> stanza. Section: Section 5.2.3 Roles: Client MUST, Server N/A.
功能：消息正文描述：支持<message/>节的<body/>子元素。第5.2.3节角色：客户端必须，服务器不适用。
Feature: message-subject Description: Support the <subject/> child element of the <message/> stanza. Section: Section 5.2.4 Roles: Client SHOULD, Server N/A.
功能：消息主题描述：支持<message/>节的<subject/>子元素。第5.2.4节角色：客户端应，服务器不适用。
Feature: message-thread Description: Support the <thread/> child element of the <message/> stanza. Section: Section 5.2.5 Roles: Client SHOULD, Server N/A.
功能：消息线程描述：支持<message/>节的<thread/>子元素。第5.2.5节角色：客户端应，服务器不适用。
Feature: message-type-support Description: Support reception of messages of type "normal", "chat", "groupchat", "headline", and "error". Section: Section 5.2.2 Roles: Client SHOULD, Server N/A.
功能：消息类型支持说明：支持接收“正常”、“聊天”、“群聊”、“标题”和“错误”类型的消息。第5.2.2节角色：客户端应，服务器不适用。
Feature: message-type-deliver Description: Appropriately deliver messages of type "normal", "chat", "groupchat", "headline", and "error". Section: Section 8 Roles: Client N/A, Server SHOULD.
功能：消息类型传递描述：适当地传递“正常”、“聊天”、“群聊”、“标题”和“错误”类型的消息。第8部分角色：客户端不适用，服务器应。
Feature: presence-notype Description: Treat a presence stanza with no 'type' attribute as indicating availability. Section: Section 4.7.1 Roles: Client MUST, Server MUST.
功能：状态notype描述：将没有“type”属性的状态节视为表示可用性。第4.7.1节角色：客户端必须，服务器必须。
Feature: presence-probe Description: Send and receive presence stanzas with a 'type' attribute of "probe" for the discovery of presence information. Section: Section 4.7.1 Roles: Client N/A, Server MUST.
功能：状态探测描述：发送和接收状态节，其“type”属性为“probe”，用于发现状态信息。第4.7.1节角色：客户端不适用，服务器必须。
Feature: presence-sub-approval Description: Treat an outbound presence stanza of type "subscribed" as the act of approving a presence subscription request previously received from another entity, and treat an inbound presence stanza of type "subscribed" as a subscription approval from another entity. Section: Section 3.1 Roles: Client MUST, Server MUST.
特征：状态子批准说明：将“已订阅”类型的出站状态节视为批准先前从另一实体收到的状态订阅请求的行为，并将“已订阅”类型的入站状态节视为来自另一实体的订阅批准。第3.1节角色：客户端必须，服务器必须。
Feature: presence-sub-cancel Description: Treat an outbound presence stanza of type "unsubscribed" as the act of denying a subscription request received from another entity or canceling a subscription approval previously granted to another entity, and treat an inbound presence stanza of type "unsubscribed" as an subscription denial or cancellation from another entity. Section: Section 3.2 Roles: Client MUST, Server MUST.
功能：状态子取消描述：将类型为“unsubscribed”的出站状态节视为拒绝从另一实体收到的订阅请求或取消先前授予另一实体的订阅批准的行为，并将类型为“unsubscribed”的入站状态节视为作为另一实体的订阅拒绝或取消。第3.2节角色：客户端必须，服务器必须。
Feature: presence-sub-preapproval Description: Treat an outbound presence stanza of type "subscribed" in certain circumstances as the act of pre-approving a subscription request received from another entity; this includes support for the 'approved' attribute of the <item/> element within the 'jabber:iq:roster' namespace. Section: Section 3.4 Roles: Client MAY, Server MAY.
特征：状态子预批准描述：在某些情况下，将“已订阅”类型的出站状态节视为预批准从另一实体收到的订阅请求的行为；这包括对“jabber:iq:花名册”命名空间中<item/>元素的“approved”属性的支持。第3.4节角色：客户端可以，服务器可以。
Feature: presence-sub-request Description: Treat an outbound presence stanza of type "subscribe" as the act of requesting a subscription to the presence information of another entity, and treat an inbound presence stanza of type "subscribe" as a presence subscription request from another entity. Section: Section 3.1 Roles: Client MUST, Server MUST.
功能：状态子请求描述：将“订阅”类型的出站状态节视为请求订阅另一实体的状态信息的行为，并将“订阅”类型的入站状态节视为来自另一实体的状态订阅请求。第3.1节角色：客户端必须，服务器必须。
Feature: presence-sub-unsubscribe Description: Treat an outbound presence stanza of type "unsubscribe" as the act of unsubscribing from another entity, and treat an inbound presence stanza of type "unsubscribe" as an unsubscribe notification from another entity. Section: Section 3.3 Roles: Client MUST, Server MUST.
功能：状态子取消订阅说明：将“取消订阅”类型的出站状态节视为从另一实体取消订阅的行为，并将“取消订阅”类型的入站状态节视为从另一实体取消订阅通知。第3.3节角色：客户端必须，服务器必须。
Feature: presence-unavailable Description: Treat a presence stanza with a 'type' attribute of "unavailable" as indicating lack of availability. Section: Section 4.7.1 Roles: Client MUST, Server MUST.
功能：状态不可用描述：将“type”属性为“unavailable”的状态节视为表示缺乏可用性。第4.7.1节角色：客户端必须，服务器必须。
Feature: roster-get Description: Treat an IQ stanza of type "get" containing an empty <query/> element qualified by the 'jabber:iq:roster' namespace as a request to retrieve the roster information associated with an account on a server. Section: Section 2.1.3 Roles: Client MUST, Server MUST.
功能：花名册获取描述：将包含由“jabber:IQ:花名册”命名空间限定的空<query/>元素的类型为“get”的IQ节视为检索与服务器上的帐户关联的花名册信息的请求。第2.1.3节角色：客户端必须，服务器必须。
Feature: roster-set Description: Treat an IQ stanza of type "set" containing a <query/> element qualified by the 'jabber:iq:roster' namespace as a request to add or update the item contained in the <query/> element. Section: Section 2.1.5 Roles: Client MUST, Server MUST.
功能：花名册集描述：将包含由“jabber:IQ:花名册”命名空间限定的<query/>元素的类型为“set”的IQ节视为添加或更新<query/>元素中包含的项的请求。第2.1.5节角色：客户端必须，服务器必须。
Feature: roster-push Description: Send a roster push to each interested resource whenever the server-side representation of the roster information materially changes, or handle such a push when received from the server. Section: Section 2.1.6 Roles: Client MUST, Server MUST.
功能：花名册推送描述：每当花名册信息的服务器端表示发生实质性变化时，向每个感兴趣的资源发送花名册推送，或者在从服务器接收时处理此类推送。第2.1.6节角色：客户端必须，服务器必须。
Feature: roster-version Description: Treat the 'ver' attribute of the <query/> element qualified by the 'jabber:iq:roster' namespace as an identifier of the particular version of roster information being sent or received. Section: Section 2.1.1 Roles: Client SHOULD, Server MUST.
功能：花名册版本描述：将由“jabber:iq:花名册”命名空间限定的<query/>元素的“ver”属性视为正在发送或接收的花名册信息的特定版本的标识符。第2.1.1节角色：客户端应，服务器必须。
[DELAY] Saint-Andre, P., "Delayed Delivery", XSF XEP 0203, September 2009.
[延迟]圣安德烈，P.，“延迟交付”，XSF XEP 0203，2009年9月。
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[关键词]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[XML] Maler, E., Yergeau, F., Sperberg-McQueen, C., Paoli, J., and T. Bray, "Extensible Markup Language (XML) 1.0 (Fifth Edition)", World Wide Web Consortium Recommendation REC-xml-20081126, November 2008, <http://www.w3.org/TR/2008/REC-xml-20081126>.
[XML]Maler，E.，Yergeau，F.，Sperberg McQueen，C.，Paoli，J.，和T.Bray，“可扩展标记语言（XML）1.0（第五版）”，万维网联盟建议REC-XML-20081126，2008年11月<http://www.w3.org/TR/2008/REC-xml-20081126>.
[XML-NAMES] Bray, T., Hollander, D., and A. Layman, "Namespaces in XML", W3C REC-xml-names, January 1999, <http://www.w3.org/TR/REC-xml-names>.
[XML-NAMES]Bray，T.，Hollander，D.，和A.Layman，“XML中的名称空间”，W3C REC XML名称，1999年1月<http://www.w3.org/TR/REC-xml-names>.
[XMPP-CORE] Saint-Andre, P., "Extensible Messaging and Presence Protocol (XMPP): Core", RFC 6120, March 2011.
[XMPP-CORE]Saint Andre，P.，“可扩展消息和状态协议（XMPP）：CORE”，RFC 6120，2011年3月。
[CPIM] Peterson, J., "Common Profile for Instant Messaging (CPIM)", RFC 3860, August 2004.
[CPIM]Peterson，J.，“即时消息的通用配置文件（CPIM）”，RFC3860，2004年8月。
[CPP] Peterson, J., "Common Profile for Presence (CPP)", RFC 3859, August 2004.
[CPP]Peterson，J.，“存在的共同特征（CPP）”，RFC 38592004年8月。
[DOS] Handley, M., Rescorla, E., and IAB, "Internet Denial-of-Service Considerations", RFC 4732, December 2006.
[DOS]Handley，M.，Rescorla，E.，和IAB，“互联网拒绝服务注意事项”，RFC 4732，2006年12月。
[IMP-MODEL] Day, M., Rosenberg, J., and H. Sugano, "A Model for Presence and Instant Messaging", RFC 2778, February 2000.
[IMP-MODEL]Day，M.，Rosenberg，J.，和H.Sugano，“状态和即时信息模型”，RFC 27782000年2月。
[IMP-REQS] Day, M., Aggarwal, S., and J. Vincent, "Instant Messaging / Presence Protocol Requirements", RFC 2779, February 2000.
[IMP-REQS]Day，M.，Aggarwal，S.，和J.Vincent，“即时消息/存在协议要求”，RFC 27792000年2月。
[IMP-SRV] Peterson, J., "Address Resolution for Instant Messaging and Presence", RFC 3861, August 2004.
[IMP-SRV]Peterson，J.，“即时消息和状态的地址解析”，RFC 38612004年8月。
[INTEROP] Masinter, L., "Formalizing IETF Interoperability Reporting", Work in Progress, October 2005.
[INTEROP]Masinter，L.，“IETF互操作性报告的形式化”，正在进行的工作，2005年10月。
[IRC] Kalt, C., "Internet Relay Chat: Architecture", RFC 2810, April 2000.
[IRC]Kalt，C.，“互联网中继聊天：架构”，RFC 28102000年4月。
[IRI] Duerst, M. and M. Suignard, "Internationalized Resource Identifiers (IRIs)", RFC 3987, January 2005.
[IRI]Duerst，M.和M.Suignard，“国际化资源标识符（IRIs）”，RFC 3987，2005年1月。
[PROCESS] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996.
[过程]Bradner，S.，“互联网标准过程——第3版”，BCP 9，RFC 2026，1996年10月。
[REPORTS] Dusseault, L. and R. Sparks, "Guidance on Interoperation and Implementation Reports for Advancement to Draft Standard", BCP 9, RFC 5657, September 2009.
[报告]Dusseault，L.和R.Sparks，“推进标准草案的互操作和实施报告指南”，BCP 9，RFC 5657，2009年9月。
[RFC3920] Saint-Andre, P., Ed., "Extensible Messaging and Presence Protocol (XMPP): Core", RFC 3920, October 2004.
[RFC3920]Saint Andre，P.，Ed.“可扩展消息和状态协议（XMPP）：核心”，RFC 3920，2004年10月。
[RFC3921] Saint-Andre, P., Ed., "Extensible Messaging and Presence Protocol (XMPP): Instant Messaging and Presence", RFC 3921, October 2004.
[RFC3921]Saint Andre，P.，Ed.“可扩展消息传递和状态协议（XMPP）：即时消息传递和状态”，RFC 39212004年10月。
[SASL] Melnikov, A. and K. Zeilenga, "Simple Authentication and Security Layer (SASL)", RFC 4422, June 2006.
[SASL]Melnikov，A.和K.Zeilenga，“简单身份验证和安全层（SASL）”，RFC 4422，2006年6月。
[SIP-PRES] Rosenberg, J., "A Presence Event Package for the Session Initiation Protocol (SIP)", RFC 3856, August 2004.
[SIP-PRES]Rosenberg，J.，“会话启动协议（SIP）的存在事件包”，RFC 3856，2004年8月。
[TLS] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[TLS]Dierks，T.和E.Rescorla，“传输层安全（TLS）协议版本1.2”，RFC 5246，2008年8月。
[TLS-CERTS] Saint-Andre, P. and J. Hodges, "Representation and Verification of Domain-Based Application Service Identity within Internet Public Key Infrastructure Using X.509 (PKIX) Certificates in the Context of Transport Layer Security (TLS)", RFC 6125, March 2011.
[TLS-CERTS]Saint Andre，P.和J.Hodges，“在传输层安全（TLS）环境下使用X.509（PKIX）证书在互联网公钥基础设施中表示和验证基于域的应用程序服务身份”，RFC 61252011年3月。
[UNICODE] The Unicode Consortium, "The Unicode Standard, Version 6.0", 2010, <http://www.unicode.org/versions/Unicode6.0.0/>.
[UNICODE]UNICODE联盟，“UNICODE标准，6.0版”，2010年<http://www.unicode.org/versions/Unicode6.0.0/>.
[URI] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005.
[URI]Berners Lee，T.，Fielding，R.，和L.Masinter，“统一资源标识符（URI）：通用语法”，STD 66，RFC 3986，2005年1月。
[UUID] Leach, P., Mealling, M., and R. Salz, "A Universally Unique IDentifier (UUID) URN Namespace", RFC 4122, July 2005.
[UUID]Leach，P.，Mealling，M.和R.Salz，“通用唯一标识符（UUID）URN名称空间”，RFC 4122，2005年7月。
[XEP-0016] Millard, P. and P. Saint-Andre, "Privacy Lists", XSF XEP 0016, February 2007.
[XEP-0016]Millard，P.和P.Saint Andre，“隐私列表”，XSF XEP 0016，2007年2月。
[XEP-0045] Saint-Andre, P., "Multi-User Chat", XSF XEP 0045, July 2008.
[XEP-0045]圣安德烈，P.，“多用户聊天”，XSF XEP 00452008年7月。
[XEP-0054] Saint-Andre, P., "vcard-temp", XSF XEP 0054, July 2008.
[XEP-0054]圣安德烈，P.，“vcard temp”，XSF XEP 0054，2008年7月。
[XEP-0071] Saint-Andre, P., "XHTML-IM", XSF XEP 0071, September 2008.
[XEP-0071]圣安德烈，P.，“XHTML-IM”，XSF XEP 0071，2008年9月。
[XEP-0115] Hildebrand, J., Saint-Andre, P., and R. Troncon, "Entity Capabilities", XSF XEP 0115, February 2008.
[XEP-0115]Hildebrand，J.，Saint Andre，P.，和R.Troncon，“实体能力”，XSF XEP 0115，2008年2月。
[XEP-0147] Saint-Andre, P., "XMPP URI Scheme Query Components", XSF XEP 0147, September 2006.
[XEP-0147]Saint Andre，P.，“XMPP URI方案查询组件”，XSF XEP 0147，2006年9月。
[XEP-0160] Saint-Andre, P., "Best Practices for Handling Offline Messages", XSF XEP 0160, January 2006.
[XEP-0160]圣安德烈，P.，“处理离线消息的最佳实践”，XSF XEP 0160，2006年1月。
[XEP-0163] Saint-Andre, P. and K. Smith, "Personal Eventing Protocol", XSF XEP 0163, July 2010.
[XEP-0163]圣安德烈，P.和K.史密斯，“个人事件协议”，XSF XEP 0163，2010年7月。
[XEP-0191] Saint-Andre, P., "Simple Communications Blocking", XSF XEP 0191, February 2007.
[XEP-0191]圣安德烈，P.，“简单通信阻塞”，XSF XEP 0191，2007年2月。
[XEP-0201] Saint-Andre, P., Paterson, I., and K. Smith, "Best Practices for Message Threads", XSF XEP 0201, November 2010.
[XEP-0201]Saint Andre，P.，Paterson，I.，和K.Smith，“消息线程的最佳实践”，XSF XEP 02012010年11月。
[XEP-0237] Saint-Andre, P. and D. Cridland, "Roster Versioning", XSF XEP 0237, March 2010.
[XEP-0237]圣安德烈，P.和D.克里德兰，“名册版本控制”，XSF XEP 0237，2010年3月。
[XML-DATATYPES] Biron, P. and A. Malhotra, "XML Schema Part 2: Datatypes Second Edition", W3C REC-xmlschema-2, October 2004, <http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/>.
[XML-DATATYPES]Biron，P.和A.Malhotra，“XML模式第2部分：数据类型第二版”，W3C REC-xmlschema-2，2004年10月<http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/>.
[XML-SCHEMA] Thompson, H., Maloney, M., Mendelsohn, N., and D. Beech, "XML Schema Part 1: Structures Second Edition", World Wide Web Consortium Recommendation REC-xmlschema-1-20041028, October 2004, <http://www.w3.org/TR/2004/REC-xmlschema-1-20041028>.
[XML-SCHEMA]Thompson，H.，Maloney，M.，Mendelsohn，N.，和D.Beech，“XML模式第1部分：结构第二版”，万维网联盟建议REC-xmlschema-1-20041028，2004年10月<http://www.w3.org/TR/2004/REC-xmlschema-1-20041028>.
[XMPP-ADDR] Saint-Andre, P., "Extensible Messaging and Presence Protocol (XMPP): Address Format", RFC 6122, March 2011.
[XMPP-ADDR]Saint Andre，P.，“可扩展消息和状态协议（XMPP）：地址格式”，RFC 6122，2011年3月。
[XMPP-URI] Saint-Andre, P., "Internationalized Resource Identifiers (IRIs) and Uniform Resource Identifiers (URIs) for the Extensible Messaging and Presence Protocol (XMPP)", RFC 5122, February 2008.
[XMPP-URI]Saint Andre，P.，“可扩展消息传递和存在协议（XMPP）的国际化资源标识符（IRI）和统一资源标识符（URI）”，RFC 5122，2008年2月。
[VCARD] Dawson, F. and T. Howes, "vCard MIME Directory Profile", RFC 2426, September 1998.
[VCARD]Dawson，F.和T.Howes，“VCARD MIME目录配置文件”，RFC24261998年9月。
This section provides detailed information about subscription states and server processing of subscription-related presence stanzas (i.e., presence stanzas of type "subscribe", "subscribed", "unsubscribe", and "unsubscribed").
本节提供有关订阅相关状态节（即“订阅”、“订阅”、“取消订阅”和“取消订阅”类型的状态节）的订阅状态和服务器处理的详细信息。
There are four primary subscription states (these states are described from the perspective of the user, not the contact):
有四种主要订阅状态（这些状态是从用户而不是联系人的角度描述的）：
None: The user does not have a subscription to the contact's presence, and the contact does not have a subscription to the user's presence.
无：用户没有订阅联系人的状态，联系人也没有订阅用户的状态。
To: The user has a subscription to the contact's presence, but the contact does not have a subscription to the user's presence.
收件人：用户订阅了联系人的状态，但联系人没有订阅用户的状态。
From: The contact has a subscription to the user's presence, but the user does not have a subscription to the contact's presence.
发件人：联系人订阅了用户的状态，但用户没有订阅联系人的状态。
Both: Both the user and the contact have subscriptions to each other's presence (i.e., the union of 'from' and 'to').
两者：用户和联系人都订阅了对方的状态（即“from”和“to”的联合）。
Implementation Note: For the purpose of processing subscription-related presence stanzas as described in the following sections, a subscription state of "None" includes the case of the contact not being in the user's roster at all, i.e., an unknown entity from the perspective of the user's roster.
实施说明：为了处理以下各节中描述的与订阅相关的存在节，订阅状态“无”包括联系人根本不在用户名册中的情况，即从用户名册的角度来看是未知实体。
The foregoing states are supplemented by various sub-states related to pending inbound and outbound subscriptions, thus yielding nine possible subscription states:
上述状态由与未决入站和出站订阅相关的各种子状态进行补充，从而产生九种可能的订阅状态：
1. "None" = Contact and user are not subscribed to each other, and neither has requested a subscription from the other; this is reflected in the user's roster by subscription='none'.
1. “无”=联系人和用户未相互订阅，且均未向对方请求订阅；这通过subscription='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; this is reflected in the user's roster by subscription='none' and ask='subscribe'.
2. “None+Pending Out”=联系人和用户未相互订阅，且用户已向联系人发送订阅请求，但联系人尚未回复；这通过subscription='none'和ask='subscripte'反映在用户的花名册中。
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. This state might or might not be reflected in the user's roster, as follows: if the user has created a
3. “None+Pending In”=联系人和用户未相互订阅，联系人已向用户发送订阅请求，但用户尚未回复。此状态可能会也可能不会反映在用户的花名册中，如下所示：如果用户创建了
roster item for the contact then the server MUST maintain that roster item and also note the existence of the inbound presence subscription request, whereas if the user has not created a roster item for the contact then the user's server MUST note the existence of the inbound presence subscription request but MUST NOT create a roster item for the contact (instead, the server MUST wait until the user has approved the subscription request before adding the contact to the user's 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; this is reflected in the user's roster by subscription='none' and ask='subscribe'.
4. “None+Pending Out+In”=联系人和用户未相互订阅，联系人已向用户发送订阅请求但用户尚未回复，用户已向联系人发送订阅请求但联系人尚未回复；这通过subscription='none'和ask='subscripte'反映在用户的花名册中。
5. "To" = User is subscribed to contact (one-way); this is reflected in the user's roster by subscription='to'.
5. “To”=用户已订阅联系人（单向）；这通过subscription='to'反映在用户的花名册中。
6. "To + Pending In" = User is subscribed to contact, and contact has sent user a subscription request but user has not replied yet; this is reflected in the user's roster by subscription='to'.
6. “To+Pending In”=用户已订阅联系人，联系人已向用户发送订阅请求，但用户尚未回复；这通过subscription='to'反映在用户的花名册中。
7. "From" = Contact is subscribed to user (one-way); this is reflected in the user's roster by subscription='from'.
7. “From”=联系人已订阅给用户（单向）；这通过subscription='from'反映在用户的花名册中。
8. "From + Pending Out" = Contact is subscribed to user, and user has sent contact a subscription request but contact has not replied yet; this is reflected in the user's roster by subscription='from' and ask='subscribe'.
8. “From+Pending Out”=联系人已向用户订阅，用户已向联系人发送订阅请求，但联系人尚未回复；这通过subscription='from'和ask='subscripte'反映在用户名册中。
9. "Both" = User and contact are subscribed to each other (two-way); this is reflected in the user's roster by subscription='both'.
9. “两者”=用户和联系人相互订阅（双向）；这反映在用户的花名册中，按subscription='tweet'。
Outbound presence subscription stanzas enable the user to manage his or her subscription to the contact's presence (via the "subscribe" and "unsubscribe" types), and to manage the contact's access to the user's presence (via the "subscribed" and "unsubscribed" types).
出站状态订阅节允许用户管理其对联系人状态的订阅（通过“订阅”和“取消订阅”类型），并管理联系人对用户状态的访问（通过“订阅”和“取消订阅”类型）。
The following rules apply to outbound routing of the stanza as well as changes to the user's roster. (These rules are described from the perspective of the user, not the contact. In addition, "S.N." stands for SHOULD NOT and "M.N." stands for MUST NOT.)
以下规则适用于节的出站路由以及对用户名册的更改。（这些规则是从用户而不是联系人的角度来描述的。此外，“S.N.”代表不应，而“M.N.”代表不得。）
Table 2: Processing of outbound "subscribe" stanzas
表2：出站“订阅”节的处理
+------------------------------------------------------------------+
| EXISTING STATE | ROUTE? | NEW STATE |
+------------------------------------------------------------------+
| "None" | MUST [1] | "None + Pending Out" |
| "None + Pending Out" | MUST | no state change |
| "None + Pending In" | MUST [1] | "None + Pending Out+In" |
| "None + Pending Out+In" | MUST | no state change |
| "To" | MUST | no state change |
| "To + Pending In" | MUST | no state change |
| "From" | MUST [1] | "From + Pending Out" |
| "From + Pending Out" | MUST | no state change |
| "Both" | MUST | no state change |
+------------------------------------------------------------------+
+------------------------------------------------------------------+
| EXISTING STATE | ROUTE? | NEW STATE |
+------------------------------------------------------------------+
| "None" | MUST [1] | "None + Pending Out" |
| "None + Pending Out" | MUST | no state change |
| "None + Pending In" | MUST [1] | "None + Pending Out+In" |
| "None + Pending Out+In" | MUST | no state change |
| "To" | MUST | no state change |
| "To + Pending In" | MUST | no state change |
| "From" | MUST [1] | "From + Pending Out" |
| "From + Pending Out" | MUST | no state change |
| "Both" | MUST | no state change |
+------------------------------------------------------------------+
[1] A state change to "pending out" includes setting the 'ask' flag to a value of "subscribe" in the user's roster.
[1] 状态更改为“待定”包括将“询问”标志设置为用户名册中的“订阅”值。
Table 3: Processing of outbound "unsubscribe" stanzas
表3：出站“取消订阅”节的处理
+-----------------------------------------------------------------+
| EXISTING STATE | ROUTE? | NEW STATE |
+-----------------------------------------------------------------+
| "None" | MUST | no state change |
| "None + Pending Out" | MUST | "None" |
| "None + Pending In" | MUST | no state change |
| "None + Pending Out+In" | MUST | "None + Pending In" |
| "To" | MUST | "None" |
| "To + Pending In" | MUST | "None + Pending In" |
| "From" | MUST | no state change |
| "From + Pending Out" | MUST | "From" |
| "Both" | MUST | "From" |
+-----------------------------------------------------------------+
+-----------------------------------------------------------------+
| EXISTING STATE | ROUTE? | NEW STATE |
+-----------------------------------------------------------------+
| "None" | MUST | no state change |
| "None + Pending Out" | MUST | "None" |
| "None + Pending In" | MUST | no state change |
| "None + Pending Out+In" | MUST | "None + Pending In" |
| "To" | MUST | "None" |
| "To + Pending In" | MUST | "None + Pending In" |
| "From" | MUST | no state change |
| "From + Pending Out" | MUST | "From" |
| "Both" | MUST | "From" |
+-----------------------------------------------------------------+
Table 4: Processing of outbound "subscribed" stanzas
表4：出站“订阅”节的处理
+-----------------------------------------------------------------+
| EXISTING STATE | ROUTE? | NEW STATE |
+-----------------------------------------------------------------+
| "None" | M.N. | pre-approval [1] |
| "None + Pending Out" | M.N. | pre-approval [1] |
| "None + Pending In" | MUST | "From" |
| "None + Pending Out+In" | MUST | "From + Pending Out" |
| "To" | M.N. | pre-approval [1] |
| "To + Pending In" | MUST | "Both" |
| "From" | M.N. | no state change |
| "From + Pending Out" | M.N. | no state change |
| "Both" | M.N. | no state change |
+-----------------------------------------------------------------+
+-----------------------------------------------------------------+
| EXISTING STATE | ROUTE? | NEW STATE |
+-----------------------------------------------------------------+
| "None" | M.N. | pre-approval [1] |
| "None + Pending Out" | M.N. | pre-approval [1] |
| "None + Pending In" | MUST | "From" |
| "None + Pending Out+In" | MUST | "From + Pending Out" |
| "To" | M.N. | pre-approval [1] |
| "To + Pending In" | MUST | "Both" |
| "From" | M.N. | no state change |
| "From + Pending Out" | M.N. | no state change |
| "Both" | M.N. | no state change |
+-----------------------------------------------------------------+
[1] Detailed information regarding subscription pre-approval is provided under Section 3.4.
[1] 第3.4节提供了有关认购预批准的详细信息。
Table 5: Processing of outbound "unsubscribed" stanzas
表5：出站“未预订”节的处理
+-----------------------------------------------------------------+
| EXISTING STATE | ROUTE? | NEW STATE |
+-----------------------------------------------------------------+
| "None" | S.N. | no state change [1] |
| "None + Pending Out" | S.N. | no state change [1] |
| "None + Pending In" | MUST | "None" |
| "None + Pending Out+In" | MUST | "None + Pending Out" |
| "To" | S.N. | no state change [1] |
| "To + Pending In" | MUST | "To" |
| "From" | MUST | "None" |
| "From + Pending Out" | MUST | "None + Pending Out" |
| "Both" | MUST | "To" |
+-----------------------------------------------------------------+
+-----------------------------------------------------------------+
| EXISTING STATE | ROUTE? | NEW STATE |
+-----------------------------------------------------------------+
| "None" | S.N. | no state change [1] |
| "None + Pending Out" | S.N. | no state change [1] |
| "None + Pending In" | MUST | "None" |
| "None + Pending Out+In" | MUST | "None + Pending Out" |
| "To" | S.N. | no state change [1] |
| "To + Pending In" | MUST | "To" |
| "From" | MUST | "None" |
| "From + Pending Out" | MUST | "None + Pending Out" |
| "Both" | MUST | "To" |
+-----------------------------------------------------------------+
[1] This event can result in cancellation of a subscription pre-approval, as described under Section 3.4.
[1] 如第3.4节所述，此事件可能导致取消订阅预批准。
Inbound presence subscription stanzas request a subscription-related action from the user (via the "subscribe" type), inform the user of subscription-related actions taken by the contact (via the
入站状态订阅节向用户请求订阅相关操作（通过“订阅”类型），通知用户联系人采取的订阅相关操作（通过
"unsubscribe" type), or enable the user to manage the contact's access to the user's presence information (via the "subscribed" and "unsubscribed" types).
“取消订阅”类型），或允许用户管理联系人对用户状态信息的访问（通过“订阅”和“取消订阅”类型）。
The following rules apply to delivery of the inbound stanza as well as changes to the user's roster. (These rules for server processing of inbound presence subscription stanzas are described from the perspective of the user, not the contact. In addition, "S.N." stands for SHOULD NOT.)
以下规则适用于入站节的交付以及对用户名册的更改。（这些服务器处理入站状态订阅节的规则是从用户而不是联系人的角度描述的。此外，“S.N.”表示不应。）
Table 6: Processing of inbound "subscribe" stanzas
表6：入站“订阅”节的处理
+------------------------------------------------------------------+
| EXISTING STATE | DELIVER? | NEW STATE |
+------------------------------------------------------------------+
| "None" | MUST [1] | "None + Pending In" |
| "None + Pending Out" | MUST | "None + Pending Out+In" |
| "None + Pending In" | S.N. | no state change |
| "None + Pending Out+In" | S.N. | no state change |
| "To" | MUST | "To + Pending In" |
| "To + Pending In" | S.N. | no state change |
| "From" | S.N. [2] | no state change |
| "From + Pending Out" | S.N. [2] | no state change |
| "Both" | S.N. [2] | no state change |
+------------------------------------------------------------------+
+------------------------------------------------------------------+
| EXISTING STATE | DELIVER? | NEW STATE |
+------------------------------------------------------------------+
| "None" | MUST [1] | "None + Pending In" |
| "None + Pending Out" | MUST | "None + Pending Out+In" |
| "None + Pending In" | S.N. | no state change |
| "None + Pending Out+In" | S.N. | no state change |
| "To" | MUST | "To + Pending In" |
| "To + Pending In" | S.N. | no state change |
| "From" | S.N. [2] | no state change |
| "From + Pending Out" | S.N. [2] | no state change |
| "Both" | S.N. [2] | no state change |
+------------------------------------------------------------------+
[1] If the user previously sent presence of type "subscribed" as described under Appendix A.2.3 and Section 3.4, then the server MAY auto-reply with "subscribed" and change the state to "From" rather than "None + Pending In".
[1] 如果用户之前发送了附录A.2.3和第3.4节中所述的“已订阅”类型的状态，则服务器可以自动回复“已订阅”，并将状态更改为“从”，而不是“无+待决”。
[2] Server SHOULD auto-reply with "subscribed".
[2] 服务器应自动回复“已订阅”。
When the user's server receives a presence stanza of type "unsubscribe" for the user from the contact, if the stanza results in a subscription state change from the user's perspective then the user's server MUST change the state, MUST deliver the presence stanza from the contact to the user, and SHOULD auto-reply by sending a presence stanza of type "unsubscribed" to the contact on behalf of the user. Otherwise the user's server MUST NOT change the state and (because there is no state change) SHOULD NOT deliver the stanza. These rules are summarized in the following table.
当用户的服务器从联系人处接收到用户“unsubscribe”类型的状态节时，如果该节导致从用户角度更改订阅状态，则用户的服务器必须更改状态，必须将联系人的状态节传递给用户，并且应该通过代表用户向联系人发送类型为“unsubscribed”的状态节来自动回复。否则，用户的服务器不得更改状态，并且（因为没有状态更改）不应传递节。下表总结了这些规则。
Table 7: Processing of inbound "unsubscribe" stanzas
表7：入站“取消订阅”节的处理
+------------------------------------------------------------------+
| EXISTING STATE | DELIVER? | NEW STATE |
+------------------------------------------------------------------+
| "None" | S.N. | no state change |
| "None + Pending Out" | S.N. | no state change |
| "None + Pending In" | MUST [1] | "None" |
| "None + Pending Out+In" | MUST [1] | "None + Pending Out" |
| "To" | S.N. | no state change |
| "To + Pending In" | MUST [1] | "To" |
| "From" | MUST [1] | "None" |
| "From + Pending Out" | MUST [1] | "None + Pending Out" |
| "Both" | MUST [1] | "To" |
+------------------------------------------------------------------+
+------------------------------------------------------------------+
| EXISTING STATE | DELIVER? | NEW STATE |
+------------------------------------------------------------------+
| "None" | S.N. | no state change |
| "None + Pending Out" | S.N. | no state change |
| "None + Pending In" | MUST [1] | "None" |
| "None + Pending Out+In" | MUST [1] | "None + Pending Out" |
| "To" | S.N. | no state change |
| "To + Pending In" | MUST [1] | "To" |
| "From" | MUST [1] | "None" |
| "From + Pending Out" | MUST [1] | "None + Pending Out" |
| "Both" | MUST [1] | "To" |
+------------------------------------------------------------------+
[1] Server SHOULD auto-reply with "unsubscribed".
[1] 服务器应自动回复“取消订阅”。
When the user's server receives a presence stanza of type "subscribed" for the user from the contact, if there is no pending outbound request for access to the contact's presence information, then it MUST NOT change the subscription state and (because there is no state change) SHOULD NOT deliver the stanza to the user. If there is a pending outbound request for access to the contact's presence information and the inbound presence stanza of type "subscribed" results in a subscription state change, then the user's server MUST change the subscription state and MUST deliver the stanza to the user. If the user already is subscribed to the contact's presence information, the inbound presence stanza of type "subscribed" does not result in a subscription state change; therefore the user's server MUST NOT change the subscription state and (because there is no state change) SHOULD NOT deliver the stanza to the user. These rules are summarized in the following table.
当用户的服务器从联系人处接收到用户类型为“subscribed”的状态节时，如果没有访问联系人状态信息的挂起出站请求，则它不得更改订阅状态，并且（因为没有状态更改）不应将该节传递给用户。如果存在访问联系人状态信息的挂起出站请求，并且“subscribed”类型的入站状态节导致订阅状态更改，则用户的服务器必须更改订阅状态，并且必须将该节传递给用户。如果用户已经订阅了联系人的状态信息，则类型为“subscribed”的入站状态节不会导致订阅状态更改；因此，用户的服务器不得更改订阅状态，并且（因为没有状态更改）不应将节传递给用户。下表总结了这些规则。
Table 8: Processing of inbound "subscribed" stanzas
表8：入站“订阅”节的处理
+------------------------------------------------------------------+
| EXISTING STATE | DELIVER? | NEW STATE |
+------------------------------------------------------------------+
| "None" | S.N. | no state change |
| "None + Pending Out" | MUST | "To" |
| "None + Pending In" | S.N. | no state change |
| "None + Pending Out+In" | MUST | "To + Pending In" |
| "To" | S.N. | no state change |
| "To + Pending In" | S.N. | no state change |
| "From" | S.N. | no state change |
| "From + Pending Out" | MUST | "Both" |
| "Both" | S.N. | no state change |
+------------------------------------------------------------------+
+------------------------------------------------------------------+
| EXISTING STATE | DELIVER? | NEW STATE |
+------------------------------------------------------------------+
| "None" | S.N. | no state change |
| "None + Pending Out" | MUST | "To" |
| "None + Pending In" | S.N. | no state change |
| "None + Pending Out+In" | MUST | "To + Pending In" |
| "To" | S.N. | no state change |
| "To + Pending In" | S.N. | no state change |
| "From" | S.N. | no state change |
| "From + Pending Out" | MUST | "Both" |
| "Both" | S.N. | no state change |
+------------------------------------------------------------------+
When the user's server receives a presence stanza of type "unsubscribed" for the user from the contact, if there is a pending outbound request for access to the contact's presence information or if the user currently is subscribed to the contact's presence information, then the user's server MUST change the subscription state and MUST deliver the stanza to the user. Otherwise, the user's server MUST NOT change the subscription state and (because there is no state change) SHOULD NOT deliver the stanza. These rules are summarized in the following table.
当用户的服务器从联系人处接收到用户“unsubscribed”类型的状态节时，如果存在访问联系人状态信息的未决出站请求，或者如果用户当前已订阅联系人的状态信息，然后，用户的服务器必须更改订阅状态，并且必须将节传递给用户。否则，用户的服务器不得更改订阅状态，并且（因为没有状态更改）不应传递节。下表总结了这些规则。
Table 9: Processing of inbound "unsubscribed" stanzas
表9：入境“未预订”章节的处理
+------------------------------------------------------------------+
| EXISTING STATE | DELIVER? | NEW STATE |
+------------------------------------------------------------------+
| "None" | S.N. | no state change |
| "None + Pending Out" | MUST | "None" |
| "None + Pending In" | S.N. | no state change |
| "None + Pending Out+In" | MUST | "None + Pending In" |
| "To" | MUST | "None" |
| "To + Pending In" | MUST | "None + Pending In" |
| "From" | S.N. | no state change |
| "From + Pending Out" | MUST | "From" |
| "Both" | MUST | "From" |
+------------------------------------------------------------------+
+------------------------------------------------------------------+
| EXISTING STATE | DELIVER? | NEW STATE |
+------------------------------------------------------------------+
| "None" | S.N. | no state change |
| "None + Pending Out" | MUST | "None" |
| "None + Pending In" | S.N. | no state change |
| "None + Pending Out+In" | MUST | "None + Pending In" |
| "To" | MUST | "None" |
| "To + Pending In" | MUST | "None + Pending In" |
| "From" | S.N. | no state change |
| "From + Pending Out" | MUST | "From" |
| "Both" | MUST | "From" |
+------------------------------------------------------------------+
Sections 2.3.5 and 5.4.10 of [IMP-REQS] require that a compliant instant messaging and presence technology needs to enable a user to block communications from selected users. Protocols for doing so are specified in [XEP-0016] and [XEP-0191].
[IMP-REQS]第2.3.5节和第5.4.10节要求，合规即时消息和在场技术需要使用户能够阻止来自选定用户的通信。[XEP-0016]和[XEP-0191]中规定了执行此操作的协议。
Sections 3.1.3 and 4.1.4 of [IMP-REQS] require that it be possible to retrieve out-of-band contact information for other users (e.g., telephone number or email address). An XML representation of the vCard specification defined in RFC 2426 [VCARD] is in common use within the XMPP community to provide such information but is out of scope for this specification (documentation of this protocol is contained in [XEP-0054]).
[IMP-REQS]第3.1.3节和第4.1.4节要求可以检索其他用户的带外联系信息（例如电话号码或电子邮件地址）。RFC 2426[vCard]中定义的vCard规范的XML表示形式在XMPP社区中普遍用于提供此类信息，但不在本规范的范围内（本协议的文档包含在[XEP-0054]中）。
Appendix D. XML Schema for jabber:iq:roster
附录D.jabber的XML模式：iq:花名册
The following schema formally defines the 'jabber:iq:roster' namespace used in this document, in conformance with [XML-SCHEMA]. Because validation of XML streams and stanzas is optional, this schema is not normative and is provided for descriptive purposes only. For schemas defining core XMPP namespaces, refer to [XMPP-CORE].
以下模式根据[XML-schema]正式定义了本文档中使用的“jabber:iq:花名册”名称空间。因为XML流和节的验证是可选的，所以此模式不是规范性的，仅用于描述目的。有关定义核心XMPP命名空间的模式，请参阅[XMPP-core]。
<?xml version='1.0' encoding='UTF-8'?>
<?xml version='1.0' encoding='UTF-8'?>
<xs:schema
xmlns:xs='http://www.w3.org/2001/XMLSchema'
targetNamespace='jabber:iq:roster'
xmlns='jabber:iq:roster'
elementFormDefault='qualified'>
<xs:schema
xmlns:xs='http://www.w3.org/2001/XMLSchema'
targetNamespace='jabber:iq:roster'
xmlns='jabber:iq:roster'
elementFormDefault='qualified'>
<xs:element name='query'>
<xs:complexType>
<xs:sequence>
<xs:element ref='item'
minOccurs='0'
maxOccurs='unbounded'/>
</xs:sequence>
<xs:attribute name='ver'
type='xs:string'
use='optional'/>
</xs:complexType>
</xs:element>
<xs:element name='query'>
<xs:complexType>
<xs:sequence>
<xs:element ref='item'
minOccurs='0'
maxOccurs='unbounded'/>
</xs:sequence>
<xs:attribute name='ver'
type='xs:string'
use='optional'/>
</xs:complexType>
</xs:element>
<xs:element name='item'>
<xs:complexType>
<xs:sequence>
<xs:element ref='group'
minOccurs='0'
maxOccurs='unbounded'/>
</xs:sequence>
<xs:attribute name='approved'
type='xs:boolean'
use='optional'/>
<xs:attribute name='ask'
use='optional'>
<xs:simpleType>
<xs:restriction base='xs:NMTOKEN'>
<xs:enumeration value='subscribe'/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
<xs:attribute name='jid'
type='xs:string'
use='required'/>
<xs:attribute name='name'
type='xs:string'
use='optional'/>
<xs:attribute name='subscription'
use='optional'
default='none'>
<xs:simpleType>
<xs:restriction base='xs:NMTOKEN'>
<xs:enumeration value='both'/>
<xs:enumeration value='from'/>
<xs:enumeration value='none'/>
<xs:enumeration value='remove'/>
<xs:enumeration value='to'/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
</xs:complexType>
</xs:element>
<xs:element name='item'>
<xs:complexType>
<xs:sequence>
<xs:element ref='group'
minOccurs='0'
maxOccurs='unbounded'/>
</xs:sequence>
<xs:attribute name='approved'
type='xs:boolean'
use='optional'/>
<xs:attribute name='ask'
use='optional'>
<xs:simpleType>
<xs:restriction base='xs:NMTOKEN'>
<xs:enumeration value='subscribe'/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
<xs:attribute name='jid'
type='xs:string'
use='required'/>
<xs:attribute name='name'
type='xs:string'
use='optional'/>
<xs:attribute name='subscription'
use='optional'
default='none'>
<xs:simpleType>
<xs:restriction base='xs:NMTOKEN'>
<xs:enumeration value='both'/>
<xs:enumeration value='from'/>
<xs:enumeration value='none'/>
<xs:enumeration value='remove'/>
<xs:enumeration value='to'/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
</xs:complexType>
</xs:element>
<xs:element name='group' type='xs:string'/>
<xs:element name='group' type='xs:string'/>
</xs:schema>
</xs:schema>
Based on consensus derived from implementation and deployment experience as well as formal interoperability testing, the following substantive modifications were made from [RFC3921] (in addition to numerous changes of an editorial nature).
基于从实施和部署经验以及正式互操作性测试中得出的共识，对[RFC3921]进行了以下实质性修改（除了编辑性质的许多更改）。
o The protocol for session establishment was determined to be unnecessary and therefore the content previously defined in Section 3 of RFC 3921 was removed. However, for the sake of backward-compatibility server implementations are encouraged to advertise support for the feature, even though session establishment is a "no-op".
o 会话建立协议被确定为不必要的，因此先前在RFC 3921第3节中定义的内容被删除。但是，为了向后兼容，鼓励服务器实现公布对该功能的支持，即使会话建立是“无操作”。
o In order to more seamlessly repair lack of synchronization in subscription states between rosters located at different servers, clarified and modified error handling related to presence subscription requests, presence probes and presence notifications.
o 为了更无缝地修复位于不同服务器上的名册之间的订阅状态缺乏同步，澄清并修改了与状态订阅请求、状态探测和状态通知相关的错误处理。
o Changed the 'from' address for presence probes so that it is the bare JID, not the full JID.
o 更改状态探测的“发件人”地址，使其成为裸JID，而不是完整JID。
o Adjusted and clarified stanza delivery rules based on implementation and deployment experience.
o 根据实施和部署经验调整和澄清节交付规则。
o Explicitly specified that a server is allowed to deliver a message stanza of type "normal" or "chat" to all resources if it has a method for allowing resources to opt in to such behavior.
o 明确指定允许服务器向所有资源传递类型为“正常”或“聊天”的消息节（如果服务器有允许资源选择此类行为的方法）。
o Allowed a server to use its own algorithm for determining the "most available" resource for the purpose of message delivery, but mentioned the recommended algorithm from RFC 3921 (based on presence priority) as one possible algorithm.
o 允许服务器使用其自己的算法来确定“最可用”的资源以进行消息传递，但提到RFC 3921中推荐的算法（基于存在优先级）是一种可能的算法。
o Added optional versioning of roster information to save bandwidth in cases where the roster has not changed (or has changed very little) between sessions; the relevant protocol interactions were originally described in [XEP-0237].
o 增加了可选的花名册信息版本控制，以在会话之间花名册没有变化（或变化很小）的情况下节省带宽；相关协议交互最初在[XEP-0237]中描述。
o Added optional server support for pre-approved presence subscriptions via presence stanzas of type "subscribed", including a new 'approved' attribute that can be set to "true" (for a pre-approved subscription) or "false" (the default).
o 通过类型为“subscribed”的状态节添加了对预先批准的状态订阅的可选服务器支持，包括一个新的“approved”属性，该属性可以设置为“true”（对于预先批准的订阅）或“false”（默认值）。
o Added optional 'parent' attribute to <thread/> element.
o 在<thread/>元素中添加了可选的“parent”属性。
o Moved the protocol for communications blocking (specified in Section 10 of RFC 3921) back to [XEP-0016], from which it was originally taken.
o 将通信阻塞协议（RFC 3921第10节中规定）移回[XEP-0016]，该协议最初是从[XEP-0016]获取的。
o Recommended returning presence unavailable in response to probes.
o 建议返回不可用的状态以响应探测器。
o Clarified handling of presence probes sent to full JIDs.
o 澄清了发送至完整JID的存在探测的处理。
o Explicitly specified that the default value for the presence <priority/> element is zero.
o 明确指定presence<priority/>元素的默认值为零。
o Removed recommendation to support the "_im" and "_pres" SRV records.
o 删除了支持“\u im”和“\u pres”SRV记录的建议。
This document is an update to, and derived from, RFC 3921. This document would have been impossible without the work of the contributors and commenters acknowledged there.
本文件是对RFC 3921的更新，源于RFC 3921。如果没有撰稿人和评论人的工作，这份文件是不可能的。
Hundreds of people have provided implementation feedback, bug reports, requests for clarification, and suggestions for improvement since publication of RFC 3921. Although the document editor has endeavored to address all such feedback, he is solely responsible for any remaining errors and ambiguities.
自RFC3921发布以来，已有数百人提供了实施反馈、错误报告、澄清请求和改进建议。尽管文档编辑已尽力处理所有此类反馈，但他对任何剩余的错误和含糊之处概不负责。
Some of the text about roster versioning was borrowed from [XEP-0237], and some of the text about message threads was borrowed from [XEP-0201].
关于花名册版本控制的一些文本是从[XEP-0237]借用的，关于消息线程的一些文本是从[XEP-0201]借用的。
Special thanks are due to Kevin Smith, Matthew Wild, Dave Cridland, Waqas Hussain, Philipp Hancke, Florian Zeitz, Jonas Lindberg, Jehan Pages, Tory Patnoe, and others for their comments during Working Group Last Call.
特别感谢Kevin Smith、Matthew Wild、Dave Cridland、Waqas Hussain、Philipp Hancke、Florian Zeitz、Jonas Lindberg、Jehan Pages、Tory Patnoe和其他人在工作组最后一次通话中发表的评论。
Thanks also to Richard Barnes for his review on behalf of the Security Directorate.
还感谢理查德·巴恩斯代表安全理事会进行审查。
The Working Group chairs were Ben Campbell and Joe Hildebrand. The responsible Area Director was Gonzalo Camarillo.
工作组主席是本·坎贝尔和乔·希尔德布兰德。负责区域的主管是冈萨洛·卡马里洛。
Author's Address
作者地址
Peter Saint-Andre Cisco 1899 Wyknoop Street, Suite 600 Denver, CO 80202 USA
美国科罗拉多州丹佛市怀诺普街1899号600室彼得·圣安德烈思科公司80202
Phone: +1-303-308-3282
EMail: psaintan@cisco.com
Phone: +1-303-308-3282
EMail: psaintan@cisco.com