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
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.
この文書は、この文書はRFC 3921を廃止RFC 2779.の要求事項に適合して基本的なインスタントメッセージング（IM）とプレゼンス機能を提供する拡張可能なメッセージングおよびプレゼンスプロトコル（XMPP）のコア機能への拡張を定義します。
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ドキュメント（http://trustee.ietf.org/license-info）に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクションで説明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
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
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）は、任意の2つの以上のネットワークエンティティとの間の構造はまだ拡張可能データのほぼリアルタイムの交換を可能にする拡張可能なマークアップ言語[XML]のアプリケーションプロファイルです。 [XMPP-CORE]で定義されたXMPPのコア機能は、特定のXML名前空間で修飾されたアプリケーション固有のデータを送信することにより、コアの上に階層化することができるほぼリアルタイムのアプリケーション、多くの種類のためのビルディングブロックを提供する（参照してください[XML-NAMES]）。この文書では、[IMP-REQS]に記載されているように、インスタントメッセージング（IM）とプレゼンス・アプリケーションに期待される基本的な機能を提供するXMPP拡張を定義します。
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の基本的な構文とセマンティクスは、主に2002年後半には1999年に、Jabberのオープンソースコミュニティ内もともと開発された、XMPPワーキンググループは、IETF IMとして適しているであろうコアのJabberプロトコルの適応の開発にチャーターされ、 [IMP-REQS]に従い、プレゼンス技術。 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.
1対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 1のコンタクトリスト内の項目を管理します
o Exchange messages with one's contacts
1の接点を持つO交換メッセージ
o Exchange presence information with one's contacts
1の接点を持つ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-0045]で指定されている例えば、マルチユーザテキストチャット）XMPP規格財団のXEPシリーズで定義されているが、それらが義務付けされていないので、そのような拡張は、この文書で指定されていません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 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.)
実装上の注意：RFC 2779は、プレゼンスサービスは、IMサービスおよびその逆から分離しなければならないことを規定しています。すなわち、プレゼンスサービス、メッセージングサービス、またはその両方を提供するプロトコルを使用することが可能でなければなりません。この文書のテキストは実装と展開が統一されたIMとプレゼンスのサービスを提供したいということを前提としていますが、それはプレゼンスサービスとメッセージングサービスの両方を提供するXMPPサービスのために必須ではありません、とプロトコルが別々提供することが可能になりますおよびプレゼンスのためとメッセージングのための個別のサービスを提供しています。 （クライアントは<メッセージ/>スタンザを送信しようとする場合、例えば、プレゼンス専用サービスは、<サービス利用不可/>スタンザエラーを返すことができます。）
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クライアントは、ストリーム上のXMLスタンザの潜在的に無制限の数を送受信するために、そのクライアントを制御し、ユーザーを可能にする、XMPPサーバと長寿命XMLストリームを持っています。そのようなストリームは、メッセージ、共有プレゼンス情報を交換し、リアルタイムに近い構造化要求応答相互作用に関与するために使用することができます。次のようにXMLストリームの交渉の後、インスタントメッセージングとプレゼンスセッションのための典型的な流れは以下のとおりです。
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.)
利用不可能プレゼンスを送信し、基礎となるXMLストリームを閉じることによって、所望の場合4.セッションを終了します。 （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].
キーワード "MUST"、 "MUST NOT"、 "REQUIRED"、 "SHALL"、 "SHOULD"、 "ないもの"、 "推奨" "ない（SHOULD NOT）"、 "MAY"、 "推奨NOT"、および「OPTIONAL RFC 2119に記載されているように「この文書の[KEYWORDS]解釈されるべきです。
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.
ASCIIのみの文書にレンダリングすることができない文字を表すために[IRI]で使用される「XML表記」以下、この文書のいくつかの例は、フォームを使用し、「＆＃1 X ...」[UNICODE]を表すために表記装置として文字（例えば、文字列「＆＃x0159のは、」Unicode文字キャロン付きラテン小文字Rの略）。このフォームは間違いないXMPPシステムにおけるワイヤ上で送信されます。
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 US: = user's server
O UC：US O =ユーザーのクライアント：=ユーザーのサーバー
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を参照してください）<IQ />スタンザを使用して管理されます。詳細な構文と意味は以下のセクションで定義されています。
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.
「版」属性は、名簿情報の特定のバージョンを識別する文字列です。値はサーバーによってのみ生成されなければならないと不透明としてクライアントによって処理されなければなりません。サーバは、名簿データのハッシュまたは厳密に増加するシーケンス番号としてバージョンIDを生成するための任意の適切な方法を使用することができます。
Inclusion of the 'ver' attribute is RECOMMENDED.
「版」属性を含めることが推奨されます。
Use of the 'ver' attribute is described more fully under Section 2.6.
「版」属性の使用は、2.6節の下でより完全に記載されています。
Interoperability Note: The 'ver' attribute of the <query/> element was not defined in RFC 3921 and is newly defined in this specification.
相互運用性注：<クエリ/>要素の「版」属性は、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").
名簿セット（2.1.5）内の<クエリ/>要素は、1つの<item />子供、および名簿の結果（2.1.4項）は、通常、複数の<item />子供が含まれていますが含まれています。それぞれの<item />要素は、（時々、「接触」と呼ばれる）のユニークな「名簿項目」を説明しています。
The syntax of the <item/> element is described in the following sections.
<項目/>要素の構文は、以下のセクションに記載されています。
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]).
ブール（デフォルトは[XML-DATATYPES]に従って、「偽」である）3.4の下で説明するように、サブスクリプションの事前承認を通知するために使用された「真」の値を持つ属性を「承認しました」。
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.
相互運用性注：<アイテム/>要素の「承認」属性は、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.
「購読」の値の<item />要素の「尋ねる」属性は、セクション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.
サーバーは、「アウト保留」サブ状態のクライアントに通知するために「頼む」属性を含むべきです。クライアントは、名簿内の属性は、それがサーバーに送信設定し、代わりに「購読」および3.1.2項で説明したようなサブ状態を管理するために「退会」タイプの存在スタンザを使用しなければならない「尋ねる」を含んではいけません。
The 'jid' attribute of the <item/> element specifies the Jabber Identifier (JID) that uniquely identifies the roster 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]).
<項目/>要素の「名前」属性は、ユーザ（ない接触）によって決定されるような「ハンドル」、JIDに関連付けられることを指定します。 「名前」属性の値は、人間のユーザに意味を持っているかもしれないが、それはサーバに不透明です。しかし、「名前」属性は、（一つの可能な比較方法が[XMPP-ADDR]でXMPPのresourcepartsについて記載したものである）は、種々のXMPP拡張のコンテキスト内で目的を一致させるためのサーバによって使用されてもよいです。
It is OPTIONAL for a client to include the 'name' attribute when adding or updating a roster item.
名簿の項目を追加または更新するとき、クライアントは「名前」属性を含めることは任意です。
The state of the presence subscription is captured in the 'subscription' attribute of the <item/> element. The defined subscription-related values are:
プレゼンス購読の状態は、<商品/>要素の「サブスクリプション」属性に捕捉されます。定義されたサブスクリプションに関連する値は次のとおりです。
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
To：ユーザーは、連絡先のプレゼンスへのサブスクリプションを持っていますが、連絡先は、ユーザーのプレゼンスへのサブスクリプションを持っていません
from: the contact has a subscription to the user's presence, but the user does not have a subscription to the contact's presence
From：連絡先は、ユーザーのプレゼンスに加入しているが、ユーザーは、連絡先のプレゼンスへのサブスクリプションを持っていません
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]).
<グループ/>子要素は、名簿の項目がクライアントによってグループ化されるようになるにカテゴリまたは「バケツ」を指定します。 <項目/>要素は、名簿グループは排他的なものではないことを意味し、複数の<グループ/>要素を含むかもしれません。 <グループ/>要素のXML文字データは、人間のユーザに意味を持っているかもしれないが、それはサーバに不透明です。しかし、<グループ/>要素は、様々なXMPP拡張のコンテキスト内で目的を一致させるためのサーバが使用されるかもしれません（一つの可能な比較方法は、[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.
名簿の項目を追加または更新するとき、クライアントは、<グループ/>要素を含めることは任意です。名簿セット（セクション2.1.5）がNO <グループ/>要素が含まれていない場合、その項目はないグループに所属されているものとして解釈されるべきです。
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.
「名簿を得るには、」名簿を返すために、サーバーに対するクライアントの要求です。 <クエリ/>要素は、/任意の<項目を含めることはできません、名前空間、構文的には、クライアントからサーバーに送信され、「：IQ名簿ジャバー」によって修飾<クエリ/>要素を含む「GET」タイプのIQスタンザであります>子要素。
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' タイプ= '取得'> <クエリのxmlns = 'ジャバー：IQ：名簿' /> </ 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.
「名簿結果は」名簿を取得するサーバの応答です。名前空間構文的には、タイプ「結果」サーバからクライアントに送信され、「：IQ名簿ジャバー」によって修飾<クエリ/>要素を含むのIQスタンザです。
The <query/> element in a roster result contains one <item/> element for each contact and therefore can contain more than one <item/> element.
<クエリは/>名簿結果の要素は、複数の<item />要素を含むことができるので、各コンタクトに対して1つの<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 = '結果'> <クエリのxmlns = 'おしゃべり：IQ：名簿' 版= 'ver7'> <項目JID =' 看護師@ example.com '/> <項目jid='romeo@example.net' /> </クエリ> </ 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-結果を返さなければならない<クエリは/>要素は、今度は何の<item />子供が含まれていないこと（すなわち、サーバーは空を返してはなりません<IQ />スタンザタイプの "エラー"）。
S: <iq id='bv1bs71f' to='juliet@example.com/chamber' type='result'> <query xmlns='jabber:iq:roster' ver='ver9'/> </iq>
S：<IQのID = to='juliet@example.com/chamber」TYPE = '結果 'bv1bs71f''> <クエリのxmlns = 'おしゃべり：IQ：名簿' 版= 'ver9' /> </ IQ>
If the roster does not exist, then the server MUST return a stanza error with a condition of <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 = to='juliet@example.com/chamber 'TYPE = 'エラー 'bv1bs71f''> <エラーの種類= 'キャンセル'>の<item-見つからないのxmlns =' URN：IETF：paramsは：XML ：NS：XMPP-スタンザ/> </エラー> </ 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.
「名簿セット」は、サーバーが修正するために、クライアントの要求（すなわち、作成、更新、または削除）名簿項目です。構文的には、クライアントからサーバに送信される「セット」タイプのIQスタンザで、「ジャバー：IQ：名簿」によって修飾<クエリ/>要素含む名前空間を。
The following rules apply to roster sets:
次の規則がセットを名簿に適用されます。
1. The <query/> element MUST contain one and only one <item/> element.
1. <クエリ/>要素は、1つ及び唯一の<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）から送信された、その結果、アドレス「に」は含まれません。さらに、RFC 3921は、名簿の確認特殊なケースを実行するには、サーバーがアドレス「に」を無視するように設定し、必要な。しかし、この仕様は、名簿のセットが送信者以外の「から」アドレスを含める可能性があることを意味する特別なケース、ことを削除しました。したがって、名簿セットを処理するエンティティは、名簿セットの送信者が名簿を更新する権限、および<禁止/>エラーを返さない場合にされていることを確認しなければなりません。
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 = 'セット'> <クエリのxmlns = 'おしゃべり：IQ：名簿'> <項目jid='nurse@example.com'/ > </クエリ> </ 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.
「名簿プッシュは、」サーバからクライアントに送信され、新たに作成、更新、または削除された名簿アイテムです。構文的には、サーバからクライアントに送信される「セット」タイプのIQスタンザで、「ジャバー：IQ：名簿」によって修飾<クエリ/>要素含む名前空間を。
The following rules apply to roster pushes:
次の規則がプッシュを名簿に適用されます。
1. The <query/> element in a roster push MUST contain one and only one <item/> element.
1.名簿プッシュにおける<クエリ/>要素は、1つ及び唯一の<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>.
それは（すなわち、暗黙的にユーザーのアカウントの裸JIDから）属性「から」何を持っていないか、その値がユーザーの裸JID <ユーザーの@ domainpart>の一致する属性「から」を持っていない限り、2 A受信クライアントは、スタンザを無視しなければなりません。
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 = 'セット'> <クエリのxmlns = 'おしゃべり：IQ：名簿'> <項目jid='nurse@example.com'/ > </クエリ> </ 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スタンザのセマンティクスによって義務付けられたように、サーバから名簿プッシュを受信する各リソースがタイプ「結果」または「エラー」（のIQスタンザで応答することになっているが、それは多くの既存のクライアントがプッシュを名簿には返信しないことが知られて）。
C: <iq from='juliet@example.com/balcony' id='a78b4q6ha463' type='result'/>
C：<IQのfrom='juliet@example.com/balcony」ID = 'a78b4q6ha463' TYPE = '結果' />
C: <iq from='juliet@example.com/chamber' id='a78b4q6ha463' type='result'/>
C：<IQのfrom='juliet@example.com/chamber」ID = 'a78b4q6ha463' TYPE = '結果' />
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以外「から」アドレスが含まれる可能性があることを意味し、ユーザーのサーバー以外のエンティティは、名簿情報を維持することができます。そのため、クライアントは、名簿プッシュの送信者が名簿の更新を許可されていることを確認する「から」アドレスをチェックしなければなりません。クライアントが不正なエンティティから名簿プッシュを受信した場合、それがプッシュされたデータを処理してはなりません。加えて、クライアントは、<サービス利用不可/>エラーのスタンザエラーを返すか、全くスタンザエラーを返すことを拒否するか（後者の現象は、予防のために[XMPP-CORE]からMUSTレベルの要件をオーバーライドプレゼンスリーク）。
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.
実装ノート：名簿はプッシュのクライアント処理のためのエラーケースがありません。サーバーは、名簿のプッシュに応じてタイプ「エラー」の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.
クライアントは、サーバとのストリームを介し名簿GETを送信することにより、名簿を要求します。
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' タイプ= '取得'> <クエリのxmlns = 'ジャバー：IQ：名簿' /> </ 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 = '結果'> <クエリのxmlns = 'おしゃべり：IQ：名簿' 版= 'ver11'> <項目JID =' ロミオ@ example.net 'NAME = 'ロミオ' 加入= '両方'> <グループ>友達</グループ> </商品> <商品jid='mercutio@example.com' NAME = 'マーキューシオ' 加入= 'から' /> <項目jid='benvolio@example.net」名前= 'ベンヴォリオ' サブスクリプション= '両方' /> </クエリ> </ 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]（例えば、<サービス利用不可/>名簿名前空間はサポートされているかどうか<サーバ内蔵エラー/>もしサーバーは）処理や名簿を返すトラブルを経験します。
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 = 'セット'> <クエリのxmlns = 'おしゃべり：IQ：名簿'> <項目jid='nurse@example.com' 名前= 'ナース'> <グループ>サーバント</グループ> </商品> </クエリ> </ 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.
サーバーは、名簿のセットを送った接続リソースにタイプ「結果」のIQスタンザを返さなければなりません。
S: <iq id='ph1xaz53' to='juliet@example.com/balcony' type='result'/>
S：<IQのID = 'ph1xaz53' to='juliet@example.com/balcony」TYPE = '結果' />
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' タイプ= '設定'> <クエリのxmlns = 'ジャバー：IQ：名簿' 版= 'ver13'> <項目JID =' 看護師@ example.com」名前= 'ナース' サブスクリプション= 'なし'> <グループ>サーバント</グループ> </ item>の</クエリ> </ 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' タイプ= '設定'> <クエリのxmlns = 'ジャバー：IQ：名簿' 版= 'ver13'> <項目JID =' 看護師@ example.com」名前= 'ナース' サブスクリプション= 'なし'> <グループ>サーバント</グループ> </ item>の</クエリ> </ 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スタンザのセマンティクスによって義務付けられたように、サーバから名簿プッシュを受信する各リソースがタイプ「結果」または「エラー」（のIQスタンザで応答することになっているが、それは多くの既存のクライアントがプッシュを名簿には返信しないことが知られて）。
C: <iq from='juliet@example.com/balcony' id='a78b4q6ha463' type='result'/>
C：<IQのfrom='juliet@example.com/balcony」ID = 'a78b4q6ha463' TYPE = '結果' />
C: <iq from='juliet@example.com/chamber' id='x81g3bdy4n19' type='result'/>
C：<IQのfrom='juliet@example.com/chamber」ID = 'x81g3bdy4n19' TYPE = '結果' />
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.
サーバーが正常に名簿・セットを処理できない場合は、スタンザ・エラーを返さなければなりません。以下のエラーケースが規定されています。サーバのみによって名簿の変更を許可する場合、自然にサーバが名簿を得る処理と内部的な問題が発生した場合、他のスタンザエラーは、<サーバ内蔵エラー/>のように、発生する可能性があり、あるいは<-許可されていません/>そのようなウェブ・インターフェースなどの非XMPP方法。
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).
名簿セットの送信者が（アカウント自体の通常のみ認証されたリソースが許可されている）名簿の更新を許可されていない場合、サーバーは、クライアントに<禁断/>スタンザ誤りを返さなければなりません。
The server MUST return a <bad-request/> stanza error to the client if the roster set contains any of the following violations:
名簿セットは、以下の違反のいずれかが含まれている場合、サーバーは、クライアントに<悪い要求/>スタンザエラーを返す必要があります。
1. The <query/> element contains more than one <item/> child element.
1. <クエリ/>要素は、複数の<item />子要素が含まれています。
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. <項目/>要素は、複数の<グループ/>要素が含まれているが、重複したグループがあり（重複を決定するための一つの可能な比較方法は、[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:
名簿セットは、以下の違反のいずれかが含まれている場合、サーバーは、クライアントに<-許容できない/>スタンザエラーを返す必要があります。
1. The length of the 'name' attribute is greater than a server-configured limit.
1.「名前」属性の長さは、サーバー設定された制限よりも大きいです。
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. <グループ/>要素は、長さゼロであるのXML文字データ（すべてのグループから項目を削除するには、クライアントは、代わりに名簿セットから任意の<group />要素を排除する必要があります）。
3. The XML character data of the <group/> element is larger than a server-configured limit.
3. <グループ/>要素の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 = 'セット'> <クエリのxmlns = 'おしゃべり：IQ：名簿'> <項目JID ='nurse@example.com '/> </クエリ> </ 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 = 'エラー'> <エラーの種類= 'AUTH'> <禁止のxmlns =' URN：IETF：paramsは：XML：NS：XMPP -stanzas' /> </エラー> </ 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 = 'セット'> <クエリのxmlns = 'おしゃべり：IQ：名簿'> <項目jid='nurse@example.com' 名前= '看護師'> <グループ>サーバント</グループ> </ item>の<項目jid='mother@example.comの」name = 'お母さん'> <グループ>家族</グループ> </ item>の</クエリ> </ 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 = 'エラーが'> <エラーの種類は= '変更'> <悪い要求のxmlns =' URN：IETF：paramsは：XML：NS ：XMPP-スタンザ/> </エラー> </ 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 = 'セット'> <クエリのxmlns = 'おしゃべり：IQ：名簿'> <項目jid='nurse@example.com' 名前= '[...いくつか-超長扱う...]'> <グループ>サーバント</グループ> </ item>の</クエリ> </ 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 = 'エラー'> <エラーの種類は= '変更'> <的に許容されないのxmlns =' URN：IETF：paramsは：XML：NS ：XMPP-スタンザ/> </エラー> </ 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 = 'セット'> <クエリのxmlns = 'おしゃべり：IQ：名簿'> <項目jid='nurse@example.com' 名前= 'ナース'> <グループ>サーバント</グループ> <グループ>サーバント</グループ> </商品> </クエリ> </ 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 = 'エラーが'> <エラーの種類は= '変更'> <悪い要求のxmlns =' URN：IETF：paramsは：XML：NS ：XMPP-スタンザ/> </エラー> </ 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 = 'セット'> <クエリのxmlns = 'おしゃべり：IQ：名簿'> <項目jid='nurse@example.com' 名前= 'ナース'> <グループ> </グループ> </商品> </クエリ> </ 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 = 'エラーが'> <エラーの種類= '変更'> <的に許容されないのxmlns =' URN：IETF：paramsは：XML：NS ：XMPP-スタンザ/> </エラー> </ 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 = 'セット'> <クエリのxmlns = 'おしゃべり：IQ：名簿'> <項目jid='nurse@example.com' 名前= '看護師'> <グループ> [...いくつか-非常に長いグループ名...] </グループ> </ item>の</クエリ> </ 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 = 'エラーが'> <エラーの種類は= '変更'> <的に許容されないのxmlns =' URN：IETF：paramsは：XML：NS ：XMPP-スタンザ/> </エラー> </ 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.
相互運用性注：一部のサーバーは、クライアントに<-許可されていません/>スタンザのエラーを返す場合の値<項目が/>要素の「JID」属性は、ユーザーのアカウントの裸JID <ローカル部@ 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:
クライアントが名簿の項目を更新するかもしれないいくつかの理由があります：
Consider a roster item that is defined as follows:
次のように定義された名簿の項目を検討してください。
<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 = 'セット'> <クエリのxmlns = 'おしゃべり：IQ：名簿'> <項目jid='romeo@example.net' 名前= 'ロミオ'> <グループ>友達</グループ> <グループ>恋人</グループ> </商品> </クエリ> </ 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 = 'セット'> <クエリのxmlns = 'おしゃべり：IQ：名簿'> <項目jid='romeo@example.net' 名前= 'ロミオ'> <グループ>恋人</グループ> </商品> </クエリ> </ 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 = 'セット'> <クエリのxmlns = 'おしゃべり：IQ：名簿'> <項目jid='romeo@example.net'/ > </クエリ> </ 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 = 'セット'> <クエリのxmlns = 'おしゃべり：IQ：名簿'> <項目jid='romeo@example.net' 名前= 'MyRomeo' /> </クエリ> </ 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 = 'セット'> <クエリのxmlns = 'おしゃべり：IQ：名簿'> <項目jid='romeo@example.net' 名前= '' /> </クエリ> </ 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」属性を含めるには「名前」属性を含めないと同等です。両方のアクションは、空の文字列に名前を設定します。
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 = 'セット'> <クエリのxmlns = 'おしゃべり：IQ：名簿'> <項目jid='nurse@example.com' 購読=> /> </クエリ> </ 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.ユーザーが連絡先にプレゼンスサブスクリプションを持っている場合は、そのユーザーのサーバーは、（連絡先のプレゼンスの購読を解除するために）連絡先に「退会」タイプの存在スタンザを送らなければなりません。
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.連絡先は、ユーザーへのプレゼンスサブスクリプションを持っている場合は、そのユーザーのサーバーは、（ユーザーの連絡先のサブスクリプションをキャンセルするために）連絡先に「解除」タイプの存在スタンザを送らなければなりません。
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.プレゼンスサブスクリプションは、相互の場合は、ユーザーのサーバーは、「退会」とタイプの存在スタンザの両方に接触する「解除」タイプの存在スタンザを送らなければなりません。
S: <presence from='juliet@example.com' id='lm3ba81g' to='nurse@example.com' type='unsubscribe'/>
S：<存在from='juliet@example.com 'ID = 'lm3ba81g' to='nurse@example.com' TYPE = '解除' />
S: <presence from='juliet@example.com' id='xb2c1v4k' to='nurse@example.com' type='unsubscribed'/>
S：<存在from='juliet@example.com 'ID = 'xb2c1v4k' to='nurse@example.com' TYPE = '解除' />
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」属性の値が名簿にない項目を指定した場合、サーバは、<項目--見つからない/>スタンザ誤りを返さなければなりません。
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 = 'セット'> <クエリのxmlns = 'おしゃべり：IQ：名簿'> <項目JID =' [...非存在-jid ...]」のサブスクリプション= '' /> </クエリ> </ 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 = 'エラー'> <エラーの種類= '変更'>の<item-見つからないのxmlns =' URN：IETF：paramsは：XML ：NS：XMPP-スタンザ/> </エラー> </ IQ>
If a server supports roster versioning, then it MUST advertise the following stream feature during stream negotiation.
サーバーは、名簿のバージョン管理をサポートしている場合、それは、ストリームのネゴシエーション中に、次のストリーム機能をアドバタイズする必要があります。
<ver xmlns='urn:xmpp:features:rosterver'/>
<のxmlns =版 '壷：XMPP：機能：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.
クライアントが名簿のバージョンをサポートしており、前述のセクションで説明したように、それが接続されている先のサーバが名簿のバージョンのサポートをアドバタイズした場合、クライアントは名簿のためにその要求に「版」要素を含むべきです。サーバーは、名簿のバージョン管理をサポートすることを通知しない場合、クライアントは「版」属性を含めることはできません。クライアントはその名簿内の属性を取得する「うた」を含む場合は、名簿の最後のキャッシュに関連するバージョン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：ジャバー名簿を' <クエリのxmlns =を<IQのfrom='romeo@example.net/home 'ID = 'r1h3vzp7' to='romeo@example.net' タイプは、= '取得'> = 'ver14のver 「/> </ 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="").
クライアントがまだ名簿をキャッシュしていないか、キャッシュが紛失または破損しているが、クライアントが名簿のバージョンの使用をブートストラップしたい場合は、空の文字列に「版」属性を設定しなければなりません（すなわち、版=「」）。
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.
クライアントが名簿のバージョン管理をサポートしていないか、名簿のバージョンの使用をブートストラップしたくない場合は当然、それは版 '属性は含まれません。
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で説明するよう（最新版を知らせる「版」属性を含む）完全な名簿を返すか、空のIQを返さなければならないのいずれか-result（従ってプッシュ後述のように任意の名簿修飾は、名簿を介して送信されることを示します）。 （名簿だけでいくつかの項目が含まれている場合、例えば）一般的には、完全な名簿を返すことは（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 = '結果' />
Implementation Note: This empty IQ-result is different from an empty <query/> element, thus disambiguating this usage from an empty roster.
実装上の注意：この空のIQ-結果は、このように空の名簿からこの用法を一義化、空の<クエリ/>要素は異なっています。
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以降に変更された各名簿の項目のためにクライアントに1人の名簿プッシュを送らなければなりません。 （私たちは、名簿のバージョン同期「暫定名簿プッシュ」の目的のために送られる名簿プッシュを呼び出します。）
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 = 'セット'> <クエリのxmlns = 'おしゃべり：IQ：名簿' 版= 'ver34 '> <項目jid='tybalt@example.org' サブスクリプション= '削除' /> </クエリ> </ 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 = 'セット'> <クエリのxmlns = 'おしゃべり：IQ：名簿' 版= 'ver42 '> <項目jid='bill@example.org' サブスクリプション= '両方' /> </クエリ> </ 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 = 'セット'> <クエリのxmlns = 'おしゃべり：IQ：名簿' 版= 'ver72 '> <項目jid='nurse@example.orgの' name = 'ナース' サブスクリプション= 'と'> <グループ>サーバント</グループ> </ item>の</クエリ> </ 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 = 'セット'> <クエリのxmlns = 'おしゃべり：IQ：名簿' = 'ver96版'> <項目jid='juliet@example.orgの' name = 'ジュリエットのサブスクリプション= '両方'> <グループ>のVIP </グループ> </ item>の</クエリ> </ 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.
名簿のバージョン管理が有効になっている場合、サーバは、各名簿プッシュで更新名簿バージョンを含まなければなりません。名簿には、修正の順序で発生しなければならないをプッシュし、名簿プッシュに含まれるバージョンは一意でなければなりません。クライアントは、その名簿に「版」属性を取得またはセットに含まれていない場合でも、すべての名簿をプッシュし、それをクライアントに送信する結果に、サーバは「版」属性を含むべきです。
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 <ローカル部@ domainpart>のと出て行く存在スタンザをスタンプしなければなりません送信側エンティティではなく、完全なJID <ローカル部分@ 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 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>.
ユーザーのクライアントは、「購読」タイプの存在スタンザを送信し、潜在的な連絡先の裸JID <接触する@ domainpart>の「から」のアドレスを指定することにより、サブスクリプション要求を生成します。
UC: <presence id='xk3h1v69' to='juliet@example.com' type='subscribe'/>
UC：<プレゼンスID = 'xk3h1v69' to='juliet@example.com」TYPE = '購読' />
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.
ユーザーは、以降の属性は、裸JID <接触する@ domainpart>ではなく、完全なJID <domainpart / resourcepart @接触>でなければならない「から」の値が、潜在的なインスタントメッセージングとプレゼンス連絡先にプレゼンスサブスクリプション要求を送信するとユーザーが連絡先のすべてのリソースからの存在、「から」属性で指定されていないだけで、特定のリソースを受信するために望ましい結果です。裸た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.要求を処理する前に、ユーザーのサーバーは、（ただし、いくつかの既存の実装は、このチェックを実行しないことが知られている）「から」属性に含まれるJIDの構文をチェックしなければなりません。 JIDは、代わりに<domainpart @接触>の形式<domainpart / resourcepart @接触>である場合、要求は、連絡先の裸JIDに向け、それに応じて「から」アドレスを変更されたかのように、ユーザーのサーバーは、それを扱うべきです。サーバはまた、JIDは[XMPP-ADDR]で定義されたフォーマットに準拠していることを確認し、おそらく<JID-奇形/>スタンザエラーを返すことができます。
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.潜在的な接触は、ローカルサービスポリシーの対象にリモートサーバー上でホストされている場合は、ユーザーのサーバーMUSTその後、ルートコアXMPPスタンザ処理規則に従い、そのリモートドメインへのスタンザ。 （これは</リモートサーバタイムアウト>のような、ユーザに適切なスタンザエラーを返すをもたらすことができます。）
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 <ユーザーの@ domainpart>とアウトバウンドのサブスクリプション要求をスタンプしなければなりません。
US: <presence from='romeo@example.net' id='xk3h1v69' to='juliet@example.com' type='subscribe'/>
米国：<プレゼンスfrom='romeo@example.net 'ID = 'xk3h1v69' to='juliet@example.com' タイプ= '購読' />
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>
米国：<存在from='juliet@example.com「のid = 『xk3h1v69』 to='romeo@example.net」タイプ= 『エラー』> <エラーの種類= 『変更』> <リモート・サーバ・見つからないのxmlns = 'URN：IETF：paramsは：XML：NS：XMPP-スタンザ' /> </エラー> </プレゼンス>
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").
ローカル配信またはリモートプレゼンス購読要求をルーティングした後、ユーザのサーバは、サブスクリプションが保留されている「なし」のサブスクリプション状態に表記の潜在的な接触（ビアを含む、ユーザの興味のすべてのリソースへの名簿プッシュを送らなければなりませんその値）「サブスクライブ」である「頼む」属性。
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>
米国：<IQのid = 'b89c5r7ib574' to='romeo@example.net/foo 'タイプ= '設定'> <クエリのxmlns = 'ジャバー：IQ：名簿'> <項目尋ねる= '加入する' JID =' ジュリエット@ example.com」のサブスクリプション= 'なし' /> </クエリ> </ 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>
米国：<IQのid = 'b89c5r7ib575' to='romeo@example.net/bar 'タイプ= '設定'> <クエリのxmlns = 'ジャバー：IQ：名簿'> <項目尋ねる= '加入する' JID =' ジュリエット@ example.com」のサブスクリプション= 'なし' /> </クエリ> </ 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.
インバウンドプレゼンスサブスクリプション要求を処理する前に、連絡先のサーバは、「から」属性に含まれるJIDの構文をチェックする必要があります。 JIDは、代わりに<domainpart @接触>の形式<domainpart / resourcepart @接触>である場合、要求は、連絡先の裸JIDに向け、それに応じて「から」アドレスを変更されたかのように、連絡先のサーバがそれを扱うべきです。サーバはまた、JIDは[XMPP-ADDR]で定義されたフォーマットに準拠していることを確認し、おそらく<JID-奇形/>スタンザエラーを返すことができます。
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、連絡先のサーバが自動的に連絡先の代わりに、サブスクリプション要求を承認てはならない - セクション3.4で説明したように、接触は、ユーザーからの（a）の事前承認のサブスクリプション要求を持っていない限り、（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から「サブスクライブ」をタイプの存在スタンザを送信することにより、接触が存在し、ユーザが既に連絡先のプレゼンスに加入している、接触の代わりに、その後、連絡先のサーバMUST自動返信した場合JID。代わって、同様に、接触が以前のタイプ「サブスクライブ」の存在スタンザを送られ、連絡先のサーバは、ユーザのプレゼンスサブスクリプションの「事前承認」を示すよう（3.4節を参照）が扱わ場合は、連絡先のサーバーSHOULDはまた、自動返信連絡先の。
CS: <presence from='juliet@example.com' id='xk3h1v69' to='romeo@example.net' type='subscribed'/>
CS：<存在from='juliet@example.com 'ID = 'xk3h1v69' to='romeo@example.net' TYPE = '加入' />
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 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).
3.サブスクリプション要求が連絡先のサーバによって受信された連絡先に関連付けられ、少なくとも1つの利用可能なリソースがある場合はそれ以外の場合は、その後、連絡先のサーバはの方法として第8節に従い、すべての利用可能なリソースにそのサブスクリプション要求を送らなければなりませんプレゼンスサブスクリプション要求の受信を確認、連絡先のサーバは、ユーザの裸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.それ以外の場合は、その後、連絡先のサーバは、その中に含まれる任意の拡張されたコンテンツを含むサブスクリプション要求を含む、完全なプレゼンススタンザの記録を保持しなければならない（8.4節を参照してください接触は、次の利用可能なリソースを持っている要求を配信し、[XMPP-CORE]）の、および。連絡先は、要求を承認または拒否するまで、連絡先のサーバは、連絡先が利用できるリソースを作成するたびにサブスクリプション要求を提供し続けなければなりません。連絡先は、次の利用可能なリソースがある場合（連絡先のサーバーが任意のユーザーからの複数のサブスクリプション要求を実現してはなりません。ユーザーは連絡先がオフラインの間、連絡先に複数のサブスクリプション要求を送信した場合、例えば、連絡先のサーバが一つだけを格納する必要がありますこれは、「サブスクリプション要求スパム」を防ぐのに役立ちます）、連絡先が次の利用可能なリソースを持っている場合、このような最初の要求または最後の要求として、それらの要求、の、と要求の一つだけを提供しなければなりません。
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.
クライアントは、ユーザーのサーバーのための連絡先のサーバと第3.1.6項については、セクション3.1.5で説明したように処理されたタイプの「サブスクライブ」の存在スタンザを送信することにより、サブスクリプション要求を承認します。
CC: <presence id='h4v1c4kj' to='romeo@example.net' type='subscribed'/>
CC：<プレゼンスID = 'h4v1c4kj' to='romeo@example.net」TYPE = '加入' />
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.
クライアントは、連絡先のサーバとユーザのサーバの両方のために、3.2節で説明したように処理されて「解除」タイプの存在スタンザを送信することにより、サブスクリプション要求を拒否します。
CC: <presence id='tb2m1b59' to='romeo@example.net' type='unsubscribed'/>
CC：<プレゼンスID = 'tb2m1b59' to='romeo@example.net」TYPE = '解除' />
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 <domainpart @接触>とアウトバウンドのスタンザをスタンプし、ローカルユーザーにスタンザを提供またはリモートルートなければなりません。
CS: <presence from='juliet@example.com' id='h4v1c4kj' to='romeo@example.net' type='subscribed'/>
CS：<存在from='juliet@example.com 'ID = 'h4v1c4kj' to='romeo@example.net' TYPE = '加入' />
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.)
連絡先のサーバは、その後、「から」の値に設定する「サブスクリプション」属性で、連絡先の興味のすべてのリソースに更新名簿プッシュを送らなければなりません。 （;それが事実であれば、付録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 'タイプ= '設定'> <クエリのxmlns = 'ジャバー：IQ：名簿'> <項目jid='romeo@example.net' サブスクリプション= /> </クエリ> </ 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 'タイプ= '設定'> <クエリのxmlns = 'ジャバー：IQ：名簿'> <項目jid='romeo@example.net' サブスクリプション= /> </クエリ> </ 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.)
接触の観点から、今「サブスクリプション」属性が「から」の値に設定されている理由であるユーザーからのサブスクリプションが存在します。 （;それが事実であれば、付録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：<プレゼンス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：<プレゼンス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'/>
米国：<存在from='juliet@example.com 'ID = 'h4v1c4kj' to='romeo@example.net' タイプ= '加入' />
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>
米国：<IQのid = 'b89c5r7ib576' to='romeo@example.net/foo 'タイプ= '設定'> <クエリのxmlns = 'ジャバー：IQ：名簿'> <項目jid='juliet@example.com' サブスクリプション= 'から' /> </クエリ> </ 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>
米国：<IQのid = 'b89c5r7ib577' to='romeo@example.net/bar 'タイプは、= '設定'> <クエリのxmlns = 'ジャバー：IQ：名簿'> <項目jid='juliet@example.com' サブスクリプション= 'から' /> </クエリ> </ 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'/>
米国：<プレゼンス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'/>
米国：<プレゼンス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'/>
米国：<プレゼンス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'/>
米国：<プレゼンス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").
ユーザーの観点から、今（「サブスクリプション」属性が「へ」の値に設定されている理由である）連絡先のプレゼンスにサブスクリプションが存在します。
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節）をキャンセルするために、それは以前にユーザーに付与されたサブスクリプションをキャンセルする、またはサブスクリプション要求を拒否したい場合、それは「解除」タイプの存在スタンザを送信します。
CC: <presence id='ij5b1v7g' to='romeo@example.net' type='unsubscribed'/>
CC：<プレゼンスID = 'ij5b1v7g' to='romeo@example.net」TYPE = '解除' />
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.
ユーザーの裸JIDは、連絡先の名簿ではまだないか、または「なし」、「なし+アウト保留中」、または「へ」の状態と連絡先の名簿にある場合は1、連絡先のサーバは、ルートべきではないか、存在感を提供タイプのスタンザユーザーに「解除」と後述のように、ユーザーに「利用不可」タイプの存在通知を送ってはいけません。
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.それ以外の場合は、以下の実施例、連絡先のサーバMUST経路に図示またはタイプ、ユーザに「解除」のタイプ「利用できない」と存在スタンザの両方のプレゼンス通知を提供し、連絡先に名簿プッシュを送信しなければならないので。
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.
ユーザーがまだ連絡先のプレゼンスに加入されている間（すなわち、連絡先のサーバールートの前やユーザへの「解除」タイプの存在スタンザを提供）、連絡先のサーバがすべてから「利用できない」タイプの存在スタンザを送らなければなりませんユーザーへの連絡先のオンラインリソース。
CS: <presence from='juliet@example.com/balcony' id='i8bsg3h3' type='unavailable'/>
CS：<存在from='juliet@example.com/balcony」ID = 'i8bsg3h3' TYPE = '利用できません' />
CS: <presence from='juliet@example.com/chamber' id='bvx2c9mk' type='unavailable'/>
CS：<存在from='juliet@example.com/chamber」ID = 'bvx2c9mk' TYPE = '利用できません' />
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.
その後、連絡先のサーバMUSTルートやユーザーへの「解除」タイプの存在スタンザを提供する、接触の裸JID <接触する@ domainpart>とアウトバウンドのサブスクリプションのキャンセルをスタンプすることを確認すること。
CS: <presence from='juliet@example.com' id='ij5b1v7g' to='romeo@example.net' type='unsubscribed'/>
CS：<存在from='juliet@example.com 'ID = 'ij5b1v7g' to='romeo@example.net' TYPE = '解除' />
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 'タイプ= '設定'> <クエリのxmlns = 'ジャバー：IQ：名簿'> <項目jid='romeo@example.net' サブスクリプション= 'なし' /> </クエリ> </ 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 'タイプ= '設定'> <クエリのxmlns = 'ジャバー：IQ：名簿'> <項目jid='romeo@example.net' サブスクリプション= 'なし' /> </クエリ> </ 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:
ユーザーのサーバーがインバウンドサブスクリプションのキャンセルを受信すると、連絡先がサブスクリプションを持つユーザーの名簿にある場合、それは最初=「」の両方（付録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'/>
米国：<存在from='juliet@example.com 'ID = 'ij5b1v7g' to='romeo@example.net' タイプ= '解除' />
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>
米国：<IQのid = 'h37h3u1bv400' to='romeo@example.net/foo 'タイプ= '設定'> <クエリのxmlns = 'ジャバー：IQ：名簿'> <項目jid='juliet@example.com' サブスクリプション= 'なし' /> </クエリ> </ 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>
米国：<IQのid = 'h37h3u1bv401' to='romeo@example.net/bar 'タイプは、= '設定'> <クエリのxmlns = 'ジャバー：IQ：名簿'> <項目jid='juliet@example.com' サブスクリプション= 'なし' /> </クエリ> </ 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".
ユーザーが連絡先のプレゼンスの購読を解除したい場合は、「退会」タイプの存在スタンザを送信します。
UC: <presence id='ul4bs71n' to='juliet@example.com' type='unsubscribe'/>
UC：<プレゼンスID = 'ul4bs71n' to='juliet@example.com」TYPE = '解除' />
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.連絡先がローカルサービスポリシーの対象にリモートサーバー上でホストされている場合は、ユーザーのサーバーMUSTその後、ルートコアXMPPスタンザ処理規則に従い、そのリモートドメインへのスタンザ。 （これは</リモートサーバタイムアウト>のような、ユーザに適切なスタンザエラーを返すをもたらすことができます。）
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 <ユーザーの@ domainpart>とのスタンザをスタンプしなければなりません。
US: <presence from='romeo@example.net' id='ul4bs71n' to='juliet@example.com' type='unsubscribe'/>
米国：<存在from='romeo@example.net 'ID = 'ul4bs71n' to='juliet@example.com' タイプ= '退会' />
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>
米国：<IQのid = 'h37h3u1bv402' to='romeo@example.net/foo 'タイプ= '設定'> <クエリのxmlns = 'ジャバー：IQ：名簿'> <項目jid='juliet@example.com' サブスクリプション= 'なし' /> </クエリ> </ 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>
米国：<IQのto='romeo@example.net/bar 'タイプ= 'セット' のid = 'h37h3u1bv403'> <クエリのxmlns = 'ジャバー：IQ：名簿'> <項目jid='juliet@example.com' サブスクリプション= 'なし' /> </クエリ> </ 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は、サブスクリプションと接触者の名簿にある場合、それは最初=「」の両方（すなわち、+から」、「から」のサブスクリプションの状態が保留中またはサブスクリプション「から」=チェックしなければなりませんアウト」、または 『両方』、付録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：<存在from='romeo@example.net 'ID = 'ul4bs71n' to='juliet@example.com' TYPE = '解除' />
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 'タイプ= '設定'> <クエリのxmlns = 'ジャバー：IQ：名簿'> <項目jid='romeo@example.net' サブスクリプション= 'なし' /> </クエリ> </ 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 'タイプ= '設定'> <クエリのxmlns = 'ジャバー：IQ：名簿'> <項目jid='romeo@example.net' サブスクリプション= 'なし' /> </クエリ> </ 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：<存在from='juliet@example.com/balcony 'ID = 'o5v91w49' to='romeo@example.net' TYPE = '利用できません' />
CS: <presence from='juliet@example.com/chamber' id='n6b1c37k' to='romeo@example.net' type='unavailable'/>
CS：<存在from='juliet@example.com/chamber 'ID = 'n6b1c37k' to='romeo@example.net' TYPE = '利用できません' />
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 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).
そして - それ以外の場合 - ユーザーが連絡先の名簿にない場合、またはユーザーの裸JIDは、上記のチェックに記載されているもの以外のサブスクリプションの状態と連絡先の名簿にある場合、接触は、存在しない場合には、あります連絡先のサーバは静かに、連絡先の興味のリソースへの名簿プッシュを生成する連絡先の名簿を修正し、ないない、連絡先に配信しないことにより、退会スタンザを無視しなければなりません。連絡先を追加したことがない「なし+保留中」のサブスクリプションの状態と機能的に同等（ただし、連絡先のサーバが連絡先に、ユーザからのインバウンドプレゼンスサブスクリプション要求の追跡された場合は、ユーザーは、連絡先の名簿にはまだありません連絡先の名簿へのユーザー）、その後、連絡先のサーバは単にインバウンドプレゼンスサブスクリプション要求（ユーザーが連絡先の名簿に追加されていなかったので、それは、連絡先の名簿からユーザーを削除することはできません）の任意のレコードを削除する必要があります。
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'/>
<サブのxmlns = '壷：XMPP：機能：事前承認' />
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.
クライアントが接続するサーバーは、サブスクリプション事前承認のサポートを宣伝している場合、クライアントが連絡先に「サブスクライブ」タイプの存在スタンザを送信することにより、サブスクリプションの事前承認を生成してもよいです。
UC: <presence id='pg81vx64' to='juliet@example.com' type='subscribed'/>
UC：<プレゼンスID = 'pg81vx64' to='juliet@example.com」TYPE = '加入' />
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.
それはサブスクリプション事前承認をサポートしている場合、次のようにタイプの存在スタンザ「サブスクライブ」を受信すると、ユーザーのサーバーを続行しなければなりません。
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.連絡先は「なし+ +でアウト保留しない」「+保留中へ」の状態、「なし+保留中」、またはで、ユーザーの名簿にある場合は、ユーザーのサーバーは、通常のサブスクリプションの承認などのスタンザを処理しなければなりませんユーザーの興味を持ってすべてのリソースに変更名簿項目を押して、（それぞれ）「アウト保留+から」「両方」、「から」の状態に既存の名簿の項目を更新することによって、（3.1.5項の下を参照）、または、そして、接触するタイプの「サブスクライブ」の存在スタンザをルーティングします。
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.連絡先は、の状態で、ユーザの名簿にある場合は、「へ」、「なし」、または「なし+アウト保留中」、ユーザーのサーバーは、値に「承認済み」フラグを設定することによって、サブスクリプションの事前承認を注意しなければなりません。 「真」の場合、ユーザーの興味を持ってすべてのリソースに変更名簿項目を押してください。しかし、ユーザーのサーバーは接触へのルートタイプの「サブスクライブ」の存在スタンザをしてはなりません。
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.連絡先がユーザの名簿ではまだされていない場合、ユーザーのサーバーは、その後、名簿を押して、「なし」の状態との接触のための名簿アイテムを作成し、「真」の値を「承認済み」フラグを設定しなければなりませんユーザーの興味を持ってすべてのリソースへのアイテム。しかし、ユーザーのサーバーは接触へのルートタイプの「サブスクライブ」の存在スタンザをしてはなりません。
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>
米国：<IQのid = 'h3bs81vs763f' to='romeo@example.net/bar 'タイプ= '設定'> <クエリのxmlns = 'ジャバー：IQ：名簿'> <項目承認= '真' JID =' ジュリエット@ example.com」のサブスクリプション= 'なし' /> </クエリ> </ 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 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からタイプ「購読」の存在スタンザ。
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).
実装上の注意：それは、接触からのプレゼンスサブスクリプション要求を受信した後に、サーバは、サブスクリプションの承認の記録を維持するかどうかを実装、またはローカルサービスポリシーの問題です。サーバは、このような記録を維持しない場合は、サブスクリプション要求を受信すると、それは、連絡先の名簿項目の「承認」属性を（すなわち、その後の名簿にプッシュし、名簿結果）は含まれません。サーバは、このような記録を保持している場合、ユーザは（連絡先にタイプ「解除」の存在スタンザを送信するまでとしない限り、それは常に、連絡先の名簿項目の「承認」属性を（「true」に設定）が含まれますまたは完全に名簿）から連絡先を削除します。
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.)
実装上の注意：クライアントは、セクション3.2の下でより完全に説明するように、「解除」タイプの存在スタンザを送信することにより、事前承認を取り消すことができます。この場合、ユーザーのサーバーを削除「承認済み」属性で、ユーザーの興味を持ってすべてのリソースに名簿プッシュを送信します。 （あるいは、クライアントは単に完全名簿項目を削除することができます。）
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".
存在の概念は、ネットワーク上の通信のためのエンティティの可用性を指します。最も基本的なレベルでは、プレゼンスエンティティが利用可能であるか、または通信のために利用できないかどうかを信号変数（用語「オンライン」と「オフライン」はまた、使用されている）「オン/オフ」ブール値です。そのクライアントは「タイプ」属性があり、<存在/>スタンザを生成するときXMPPでは、そのクライアントはノー「タイプ」属性を持つ<存在/>スタンザを生成するときに、エンティティの可用性が通知され、および可用性のエンティティの欠如が通知されます「利用不可」の値。
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 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.)
XMPPの存在は、通常、エンティティがそのサーバに存在を送り、ここで「パブリッシュ・サブスクライブ」または「オブザーバー」のパターンを、次の、そしてそのサーバはその後、専門用語で（エンティティのプレゼンスに加入している事業体の連絡先のすべてにその情報をブロードキャスト[IMP-MODEL]、プレゼンスが「プレゼンティティ」と「加入者」）が存在することを受信エンティティで生成するエンティティ。クライアントは、プレゼンススタンザはNO「type」属性またはその値が「利用不可」である「タイプ」属性のいずれかを持っていないアドレス、「に」はとそのサーバーに存在スタンザを送信しないことによって、すべての加入エンティティへのブロードキャストのために存在することを生成します。存在のこの種のは、「放送の存在」と呼ばれています。 （クライアントはまた、すなわち、アドレス「から」と存在スタンザを「監督の存在を」送信することができます。これはあまり一般的であるが、時には、ユーザーのプレゼンスに加入されていないエンティティに存在を送信するために使用される;。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.5節）を送信することにより終了される最初のプレゼンス（4.2節）を、送信することにより、そのサーバーでの「プレゼンスセッション」を確立することができます。その存在セッションの間、（[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サーバが正常にルーティングメッセージとIQスタンザのために、ネットワークの可用性に関する情報を必要としない）XMPPのアプリケーションは、メッセージングとプレゼンス機能を統合する必要はない、と彼らは、メッセージングせずにスタンドアロンのプレゼンス機能を提供することができます。
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>.
情報注：以下の例では、ユーザは、彼女は、2つの使用可能なリソース（「バルコニー」と「室」）を有する<juliet@example.com>であり、彼女から」サブスクリプションの状態で彼女の名簿で3つの接点を持っています」または "両方"：<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]で説明した前提条件（必須）完了し、名簿（推奨）を要求した後、クライアントはすなわち、そのサーバーに「初期プレゼンス」を送信することにより、通信のためにその可用性を信号、アドレス「から」なしでのプレゼンススタンザ（ユーザーの利用可能性を示す）なし「タイプ」属性（クライアントの代わりにサーバーによって放送されることになっていることを示します）。
UC: <presence/>
UC：<存在/>
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.
初期プレゼンススタンザは<優先/>要素、<ショー/>要素と<状態/>要素、ならびに拡張されたコンテンツの1つまたは複数のインスタンスを含むかもしれません。詳細は、セクション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 <domainpart / resourcepart @ユーザー>からの初期の存在スタンザを送らなければなりません。そのような接点は、JIDは「から」または「両方」の値に設定する「サブスクリプション」属性を持つ利用者の名簿に存在しているものがあります。
US: <presence from='juliet@example.com/balcony' to='romeo@example.net'/>
米国：<存在from='juliet@example.com/balcony 'to='romeo@example.net' />
US: <presence from='juliet@example.com/balcony' to='mercutio@example.com'/>
米国：<プレゼンスfrom='juliet@example.com/balcony 'to='mercutio@example.com' />
US: <presence from='juliet@example.com/balcony' to='benvolio@example.net'/>
米国：<存在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'/>
米国：<プレゼンスfrom='juliet@example.com/balcony 'to='juliet@example.com' />
[... to the "chamber" resource ...]
[...「室」リソースへ...]
US: <presence from='juliet@example.com/balcony' to='juliet@example.com'/>
米国：<プレゼンス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：<存在from='juliet@example.com/balcony 'to='romeo@example.net' />
[ ... to resource2 ... ]
[...リソース2にします...]
CS: <presence from='juliet@example.com/balcony' to='romeo@example.net'/>
CS：<存在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.ユーザは、連絡先の名簿ではないが、コンタクトとユーザが積極的に（セクション4.6およびセクション5.1を参照）は、通信セッションのためのユーザインタフェースでプレゼンス情報を表示し、メッセージまたはIQスタンザを交換している場合。
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.
「プレゼンスプローブ」は、ユーザーのサーバーがユーザーに代わって送信され、連絡先の現在のプレゼンス情報の要求です。構文的には、その「タイプ」属性「プローブ」の値を有するプレゼンススタンザです。プレゼンスサブスクリプションの文脈では、アドレス「から」の値は、加入者の裸JIDなければならず、アドレス「に」の値が存在するので、ユーザが加入しているため、コンタクトの露出JIDでなければなりませんサブスクリプションが裸JIDに基づいています。
US: <presence from='juliet@example.com' id='ign291v5' to='romeo@example.net' type='probe'/>
米国：<存在from='juliet@example.com 'ID = 'ign291v5' to='romeo@example.net' タイプ= 'プローブ' />
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で説明したように接触が向けプレゼンスを送信した、典型的には、プレゼンス購読のコンテキスト外で存在することを受信したエンティティによって送信することができます。この場合にはアドレス「に」「から」かの値が完全な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.
一般的に、クライアントは、ユーザーの連絡先から収集プレゼンスのタスクは、ユーザーのサーバーで管理されているので、それらを送信する必要はありませんので、プレゼンスプローブは、クライアントによって送信されるべきではありません。しかし、ユーザーのクライアントは、ユーザーのサーバーを発信プレゼンスプローブを生成した場合SHOULDルートプローブ（連絡先は別のサーバにある場合）または（連絡先が同じサーバーにある場合）プローブを処理し、その領収書を使用してはなりませんクライアントへのスタンザまたはストリームエラーを返すための唯一の原因として、接続されたクライアントからのプレゼンスプローブ。
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 <domainpart @連絡先>にユーザーの裸JID <ユーザーの@ 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'/>
米国：<存在from='juliet@example.com 'ID = 'ign291v5' to='romeo@example.net' タイプ= 'プローブ' />
US: <presence from='juliet@example.com' id='xv291f38' to='mercutio@example.com' type='probe'/>
米国：<存在from='juliet@example.com 'ID = 'xv291f38' to='mercutio@example.com' タイプ= 'プローブ' />
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.（付録Aの下で説明したように）、その後、接触アカウントが存在しないか、ユーザーの裸JIDは、「から」以外のサブスクリプションの状態と連絡先の名簿である「アウト保留+から」、または「両方」場合3.2節で説明したようプレゼンスプローブに応じて「解除」タイプの存在スタンザを返すべきで、連絡先のサーバが（これは連絡先へのユーザのサブスクリプションをキャンセルするためのプロトコルフローをトリガしますが、これは、サブスクリプションの取り消しにつながるならない（MUST NOT） 3.4節で説明したよう事前承認）。ここで「から」アドレスは[XMPP-CORE]で説明されるように、プレゼンス漏れを構成するであろうフルJIDを指定するので、コンタクトの露出JIDでなければなりません。
CS: <presence from='mercutio@example.com' id='xv291f38' to='juliet@example.com' type='unsubscribed'/>
CS：<存在from='mercutio@example.com 'ID = 'xv291f38' to='juliet@example.com' TYPE = '解除' />
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.、その後、サーバは（一時的な）</リダイレクト>のスタンザのエラー状態でタイプ「エラー」の存在スタンザを返すか、すべきである<なくなっ/>（永久）それは、連絡先の新しいアドレスを含んでいます。
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：<存在がfrom='mercutio@example.com 'ID = 'xv291f38' to='juliet@example.com' タイプ= 'エラー'> <エラーの種類は= '変更'> <ゴーンのxmlns = "壷：IETF： params：XML：NS：XMPP-スタンザ> XMPP：la-mer@example.com </なくなっ> </エラー> </プレゼンス>
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 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]).
連絡先が使用可能なリソースを持っていない場合はそうでない場合3.、サーバーは「利用できない」ユーザーにタイプの存在スタンザを送信することにより、プレゼンスプローブに返信すべきである（それはに決定論的な答えにつながるので、ここでは利用できない存在を送信することが好ましいがそれが大幅に）連絡先のサーバーによって生成されたプレゼンス通知の数を増やすことができるので、プローブが、それは必須ではありません。連絡先に関連付けられている使用可能なリソースが存在しないため、ここでは「から」アドレスは裸JIDです。適切な場合には、ローカルセキュリティポリシーに従ってこのプレゼンス通知は、プレゼンス通知サーバは（元スタンザの「ID」を含む）の接触から受信したことを最後に利用できない存在スタンザの完全なXMLが含まれていますが、もしない場合がありSHOULD単に連絡先は、もともと提供詳細のいずれかなしで利用できないことを示しています。最後の利用不可能プレゼンススタンザが生成された時間（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：<存在from='mercutio@example.com 'ID = 'xv291f38' to='juliet@example.com' TYPE = '利用できない'> <遅延のxmlns = 'URN：XMPP：遅延' スタンプ= '2002-09 -10T23：41：07Z '/> </プレゼンス>
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.
接触は、少なくとも1つの利用可能なリソースを持っている場合はそうでない4.、サーバは、各から、サーバーが受信した属性「に」は、ユーザにいないとの最後のプレゼンススタンザの完全なXMLを送信することにより、プレゼンスプローブに返信しなければなりません連絡先の利用可能なリソース。ここでアドレス「からは、」使用可能な各リソースの完全なたJIDです。
CS: <presence from='romeo@example.net/foo' id='hzf1v27k' to='juliet@example.com'/>
CS：<プレゼンス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：<プレゼンスfrom='romeo@example.net/bar 'ID = 'ps6t1fu3' to='juliet@example.com'> <ショー>離れて</ショー> </プレゼンス>
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.
実装上の注意：「完全なXML」は、開口部からの完全なスタンザを意味しているすべての要素とコンテンツの名前空間または拡張名前空間で修飾するかどうかの属性を含む、終了</プレゼンス>タグに<存在>タグ。それは、サーバからサーバへの流れを完全にスタンザを送信する場合：「サーバーのjabber」に：ただし、[XMPP-CORE]に従って、連絡先のサーバは、「クライアントジャバー」からコンテンツの名前空間を変換する必要があります。
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に一致するリソースがあると、プロービングエンティティは、連絡先のプレゼンスを確認するために、プレゼンスサブスクリプションを経て許可を持っている場合、サーバーはリソースが利用可能（詳細ではない情報であることだけで事実を伝えるべきである可能なプレゼンス通知を、返さなければなりませんなど<ショー/>、<状態/>、<優先/>、または存在拡張）。
CS: <presence from='romeo@example.net/bar' to='lobby@chat.example.com'/>
CS：<プレゼンス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.
「プローブを送信し、応答を受信」のパターンは、XMPP <IQ />スタンザと同様要求 - 応答プロトコルのように見えるかもしれないがプレゼンスプローブに関して「ID」属性の取り扱いは、RFC 3921.に不特定でした、プローブに対する応答が複数存在スタンザ（コンタクト用の現在アクティブな各利用可能なリソースについて1つ）から成る可能性があるため、実際にはそうではありません。連絡先は、現在利用可能なリソースを持っている場合は、このような理由から、その後、連絡先のサーバは、連絡先の元プレゼンススタンザの「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：！<存在from='juliet@example.com/chamber」ID = 'PRES1'> <ショー> DND </表示し> <状態>忙しい</状態> </プレゼンス>
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：<存在from='juliet@example.com/balcony」ID = 'プレS2'> <ショー>離れて</ショー> <ステータス> </状態> </プレゼンスを>離れステップ
Romeo's server then sends a probe to Juliet.
ロミオのサーバーは、ジュリエットにプローブを送信します。
US: <presence from='romeo@example.net' id='probe1' type='probe'/>
米国：<プレゼンスfrom='romeo@example.net」ID = 'PROBE1' タイプ= 'プローブ' />
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：！<存在from='juliet@example.com/chamber」ID = 'PRES1'> <ショー> DND </表示し> <状態>忙しい</状態> </プレゼンス>
CS: <presence from='juliet@example.com/balcony' id='pres2'> <show>away</show> <status>stepped away</status> </presence>
CS：<存在from='juliet@example.com/balcony」ID = 'プレS2'> <ショー>離れて</ショー> <状態> </ステータス> </プレゼンス>を離れステップ
In the second scenario, Juliet is offline when Romeo's server sends a probe.
2つ目のシナリオでは、ジュリエットはロミオのサーバがプローブを送信するときにオフラインです。
US: <presence from='romeo@example.net' id='probe2' type='probe'/>
米国：<プレゼンスfrom='romeo@example.net」ID = 'PROBE2' タイプ= 'プローブ' />
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.
ジュリエットのサーバーは、彼女のクライアントが送信した利用可能通知から守るために何の「ID」は存在しないため、ローマのプレゼンスプローブの「ID」をミラーリング、使用不能通知で応答します。
CS: <presence from='juliet@example.com' id='probe2' type='unavailable'/>
CS：<存在from='juliet@example.com」ID = 'PROBE2' TYPE = '利用できません' />
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：離れて<存在> <ショー> </ショー> </プレゼンス>
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.
プレゼンス放送は<優先/>要素、<ショー/>要素と<状態/>要素、ならびに拡張されたコンテンツの1つまたは複数のインスタンスを含むかもしれません。詳細は、セクション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>
米国：<存在from='juliet@example.com/balcony 'to='romeo@example.net'> <ショー>離れて</ショー> </プレゼンス>
US: <presence from='juliet@example.com/balcony' to='benvolio@example.net'> <show>away</show> </presence>
米国：<存在from='juliet@example.com/balcony 'to='benvolio@example.net'> <ショー>離れて</ショー> </プレゼンス>
US: <presence from='juliet@example.com/balcony' to='mercutio@example.com'> <show>away</show> </presence>
米国：<プレゼンスfrom='juliet@example.com/balcony 'to='mercutio@example.com'>離れて<ショー> </ショー> </プレゼンス>
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>
米国：<存在from='juliet@example.com/balcony 'to='juliet@example.com/chamber'> <ショー>離れて</ショー> </プレゼンス>
US: <presence from='juliet@example.com/balcony' to='juliet@example.com/balcony'> <show>away</show> </presence>
米国：<存在from='juliet@example.com/balcony 'to='juliet@example.com/balcony'> <ショー>離れて</ショー> </プレゼンス>
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：<存在from='juliet@example.com/balcony 'to='romeo@example.net'> <ショー>離れて</ショー> </プレゼンス>
[ ... to resource2 ... ]
[...リソース2にします...]
CS: <presence from='juliet@example.com/balcony' to='romeo@example.net'> <show>away</show> </presence>
CS：<存在from='juliet@example.com/balcony 'to='romeo@example.net'> <ショー>離れて</ショー> </プレゼンス>
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".
サーバとその存在のセッションを終了する前に、ユーザーのクライアントは優雅に、「使用できない存在」を送信することにより、利用できなくなった、すなわち、属性「に」ノーを有し、それは、値が「利用不可」である「タイプ」属性を所有するプレゼンススタンザ。
UC: <presence type='unavailable'/>
UC：<プレゼンスタイプ= '使用できません' />
Optionally, the unavailable presence stanza MAY contain one or more <status/> elements specifying the reason why the user is no longer available.
必要に応じて、使用できない存在スタンザは、ユーザーがもはや利用できない理由を指定する1つまたは複数の<状態/>要素を含んでいてもよいです。
UC: <presence type='unavailable'> <status>going on vacation</status> </presence>
UC：<プレゼンスタイプ= '利用できない'> <状態> </ステータス> </プレゼンス>休暇に行きます
However, the unavailable presence stanza MUST NOT contain the <priority/> element or the <show/> element, since these elements apply only to available resources.
これらの要素は、利用可能なリソースにのみ適用されますので、使用できない存在スタンザは、<優先/>要素または<ショー/>要素を含めることはできません。
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]).
リソースが不正に使用できなくなる可能性があるため、ユーザのサーバは、使用可能なリソースから利用できない存在を受けるに依存してはなりません（例えば、リソースのXMLストリームがまたはに説明する理由のいずれかのためのストリームエラーなしで閉鎖される可能性がある[XMPP-CORE] ）。
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>
米国：<存在from='juliet@example.com/balcony 'to='romeo@example.net' タイプ= '利用できない'> <状態> </ステータス> </プレゼンス>休暇に行きます
US: <presence from='juliet@example.com/balcony' to='benvolio@example.net' type='unavailable'> <status>going on vacation</status> </presence>
米国：<存在from='juliet@example.com/balcony 'to='benvolio@example.net' タイプ= '利用できない'> <状態> </ステータス> </プレゼンス>休暇に行きます
US: <presence from='juliet@example.com/balcony' to='mercutio@example.com' type='unavailable'> <status>going on vacation</status> </presence>
米国：<プレゼンスfrom='juliet@example.com/balcony 'to='mercutio@example.com' タイプ= '利用できない'> <状態>休暇に入る</ステータス> </プレゼンス>
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>
米国：<プレゼンスfrom='juliet@example.com/balcony 'to='juliet@example.com/chamber' タイプ= '利用できない'>休暇に入る<状態> </ステータス> </プレゼンス>
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).
実装上の注意：クライアントが使用できない存在通知は、すべての加入者（すなわちへのユーザーのサーバーによってルーティングまたは送達されなければならないサーバの放送後に送信するか、生成する属性「に」いいえ「タイプ」属性なしで任意のプレゼンススタンザ、治療しなければなりません）新しいプレゼンスセッションの最初の存在と同等として。
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：<プレゼンスfrom='juliet@example.com/balcony 'to='romeo@example.net' タイプ= '利用できない'>休暇に入る<状態> </ステータス> </プレゼンス>
[ ... to resource2 ... ]
[...リソース2にします...]
CS: <presence from='juliet@example.com/balcony' to='romeo@example.net' type='unavailable'> <status>going on vacation</status> </presence>
CS：<プレゼンスfrom='juliet@example.com/balcony 'to='romeo@example.net' タイプ= '利用できない'>休暇に入る<状態> </ステータス> </プレゼンス>
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 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.
XMPPサーバーには、一般的にどのユーザがなったときに、リストをクリアし、その後、与えられたリソース（フルJID）のために、ユーザーの現在のセッション中に監督の存在を送信したために、エンティティ（裸たJIDまたはフルたJID）のリストを維持することにより、監督の存在を実装しますオフライン（例えば、タイプの放送プレゼンススタンザ「使用不能」を送信することにより）。サーバは、有向プレゼンスリスト（またはその機能的等価物）から、ユーザが利用できない存在に向け送信し、ユーザに利用できないプレゼンスを送信する任意のエンティティを削除する必要がありれる任意のエンティティを削除する必要があります。
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".
述べたように、指向存在は、その値が他のエンティティの裸JIDまたは完全JIDといいえ「タイプ」（可用性を示す）属性又はその「タイプ」属性のいずれかを持つ属性「」へとクライアントが生成したプレゼンススタンザであります値が「利用不可」です。
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.利用者は、最初のプレゼンスを送信した後、ユーザーのプレゼンスの間、すなわち（使用できない存在ブロードキャストを送信する前に、「両方」「から」またはのサブスクリプションタイプを持つユーザーの名簿にある連絡先に向け利用可能または利用できない存在を送信した場合セッション）、ユーザーのサーバーは、ローカルにすなわち、それは）ユーザーによって開始ブロードキャストし、後続の存在下で、連絡先のJIDを含むべきである（提供またはリモートルートその存在スタンザの完全なXMLを、それ以外の存在放送に関する連絡先のステータスを変更してはなりませんしなければなりません。
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.ユーザーは、最初のプレゼンスを送信した後、および（ユーザーのプレゼンスセッションの間、すなわち）使用できない存在ブロードキャストを送信する前に、「両方」「から」またはのサブスクリプションタイプを持つユーザーの名簿にないエンティティに向けプレゼンスを送信した場合、ユーザーのサーバーは、ローカルに（すなわち、それはによって開始可能な存在のいずれかのその後の放送で、エンティティのJIDを含んではいけません提供またはリモートルートその存在スタンザの完全なXMLをエンティティになく、利用できるプレゼンス放送に関する連絡先の状態を変更してはいけませんしなければなりませんユーザー）;しかし、ユーザが向けプレゼンスを送信し、そこから利用可能なリソースが使用できなくなった場合、エンティティに使用できなくプレゼンス（ユーザーがまだ送信されていない場合は、そのエンティティに利用できない存在を指示し）、そのユーザーのサーバーMUST経路。
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.
ユーザーのクライアントが別のエンティティ（例えば、1対1のチャットパートナーまたはマルチユーザーチャットルーム）に向けプレゼンスを送信した場合、いくつかの時間後にエンティティまたはそのサーバーは、クライアントがまだオンラインであるかどうかを知りたいかもしれません。このシナリオでは、ユーザーは、時間の長い期間のための参加者であるかもしれないマルチユーザーチャットルームの場合には、特に一般的です。ユーザーのクライアントが（クライアントまたはクライアントのサーバーで）通知されたチャットルームなしでオフラインになった場合は、部屋の中のユーザの表現が参加しているように見える「幽霊」になるが、実際に中にもはや存在しないことかもしれませんルーム。そのような「幽霊」を検出するために、いくつかのマルチユーザチャットルームの実装は部屋に参加しているユーザーにプレゼンスプローブを送信します。
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).
関連するエンティティが通信のために利用できない「利用不可」信号の値に「type」属性（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サーバに関連付けられている場合、これらのサーバはまた、ピア・サーバ上のエンティティの利用可能性を決定するために、「プローブ」タイプの特殊存在スタンザを使用します。詳細は、セクション4.3の下で提供されています。クライアントは、タイプ「プローブ」の存在スタンザを送るべきではありません。
The values of the 'type' attribute can be summarized as follows:
以下のように「タイプ」属性の値をまとめることができます。
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エラー - エラーは、以前に送信されたプレゼンススタンザの処理について発生しました。プレゼンススタンザタイプ「エラー」である場合、それは<誤り/>子要素を（[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サブスクライブ - 送信者は受信者のプレゼンスに加入することを希望します。
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 - 送信者が受信者の存在から脱退されます。
o unsubscribed -- The subscription request has been denied or a previously granted subscription has been canceled.
O解除 - サブスクリプション要求が拒否されているか、以前に付与されたサブスクリプションがキャンセルされました。
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/>.
「タイプ」属性の値が上記のいずれかの値でない場合は、受信者または中間ルータが<悪い要求/>のスタンザエラーを返すべきです。
Implementation Note: There is no default value for the 'type' attribute of the <presence/> element.
実装上の注意：<存在/>要素の「タイプ」属性のデフォルト値はありません。
Implementation Note: There is no value of "available" for the 'type' attribute of the <presence/> element.
実装上の注意：<存在/>要素の「タイプ」属性に「利用可能」の値がありません。
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.
「：クライアントおしゃべり」または 'おしゃべり：サーバのデフォルトの名前空間宣言に従い、プレゼンススタンザがで修飾されたプレゼンススタンザの特定の子要素を定義し、名前空間、特に<ショー/>、<状態/>、そして、<優先/>要素。これらの子要素は、エンティティの可用性に関する詳細な情報を提供するために使用されています。通常、これらの子要素は、例外は、以下の本文中に記載されていますが、プレゼンススタンザは、NO「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):
オプションの<表示/>要素は、エンティティの特定の可用性サブ状態またはその特定のリソースを指定します。プレゼンススタンザは、複数の<ショー/>要素を含めることはできません。 <ショー/>要素に定義された属性はありません。 （[XML]のセクション3.2.2で定義されるように）<表示/>要素は、混合コンテンツを含んではなりません。 <ショー/>要素の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」）長期間離れています。
If no <show/> element is provided, the entity is assumed to be online and available.
何の<ショー/>要素が提供されない場合は、エンティティがオンラインで使用可能であると仮定されます。
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.
オプションの<状態/>要素は、エンティティの可用性の自然言語記述を指定して、人間が読み取り可能なXML文字データが含まれています。プレゼンススタンザがNO「タイプ」属性を持っていない場合には、通常、（例えば、「会議中」）可用性状態の詳細な説明を提供するために、表示要素に関連して使用されます。
<presence from='romeo@example.net/orchard' xml:lang='en'> <show>dnd</show> <status>Wooing Juliet</status> </presence>
<プレゼンスfrom='romeo@example.net/orchard」XML：LANG = 'EN'> <表示> DND </表示> <状態>ジュリエット求愛</ステータス> </プレゼンス>
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]).
「：LANGのxml」属性は、[XML]から継承されたのを除いて、<状態/>要素に定義された属性は、ありません。 （[XML]のセクション3.2.2で定義されるように）<状態/>要素は、混合コンテンツを含んではなりません。 「：langのXML」「のxml：langの」異なる言語値（明示的に、またはからの継承によって持つ属性要素の値が遠くまで<状態/>要素が含まれてもよいが、各インスタンスが有する場合にのみ、複数のインスタンス[XMPP-CORE]で説明されるようにXMLストリームヘッダを含むことができ、送信者の観点からXML階層、で）。
<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>
<プレゼンスfrom='romeo@example.net/orchard 'ID = 'jx62vs97' XML：LANG = 'EN'> <表示> DND </表示> <状態>求愛ジュリエット</ステータス> <ステータスXML：LANG =' CS'> DVO＆＃をx0159;＆＃x00ED; M SE Julii </ステータス> </プレゼンス>
A presence stanza of type "unavailable" MAY also include a <status/> element to provide detailed information about why the entity is going offline.
タイプの存在スタンザ「利用できない」も実体がオフラインになっている理由についての詳細な情報を提供するために、<状態/>要素を含んでいてもよいです。
<presence from='romeo@example.net/orchard' id='oy6sb241' type='unavailable' xml:lang='en'> <status>Busy IRL</status> </presence>
<プレゼンスfrom='romeo@example.net/orchard」ID = 'oy6sb241' TYPE = '利用できない' XML：LANG = 'EN'> <状態>ビジーIRL </ステータス> </プレゼンス>
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).
<状態/>子はまた、アクションの記述を提供するサブスクリプションに関連するプレゼンススタンザ（すなわち、タイプ「購読」、「購読」、「解除」、または「解除」）で送られてもよいです。対話型のクライアントは、（セクション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>
<プレゼンスfrom='romeo@example.net「ID = 『uc51xs63』 to='nurse@example.com」タイプ= 『購読』> <状態>こんにちは、ジュリエットは私のバディリストにあなたを追加するために私に言った。</ステータス> </プレゼンス>
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]).
オプションの<優先/>要素は、リソースの優先順位を指定する非人間が読めるXMLの文字データが含まれています。値は-128と+127の間の整数でなければなりません。プレゼンススタンザは、複数の<優先/>要素を含めることはできません。 <優先/>要素に定義された属性はありません。 （[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>
<プレゼンスXML：LANG = 'EN'> <表示> DND </表示> <状態>求愛ジュリエット</ステータス> <ステータスXML：LANG = 'CS'> DVO＆＃をx0159;＆＃x00ED; M SE Julii </状態> <優先順位> 1 </優先順位> </プレゼンス>
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を対象としたメッセージを配信するルールを取り扱うメッセージを課すために、例えば）クライアントが提供する優先順位の値を無効にすることができます。サーバがそうする場合は、この修正優先度の値が変更され、優先度の値を伝える、一般的にはゼロのデフォルト値であるので、それは自分自身に戻って、クライアントの存在をエコーし、（ユーザーの連絡先にプレゼンス通知を送信する修正優先度の値を通信する必要があります<優先/>子要素）を含まないことによって行うことができます。
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>
<プレゼンスfrom='romeo@example.net '> <Cのxmlns =' HTTP：//jabber.org/protocol/caps'ハッシュ= 'SHA-1' ノード= 'HTTP：//psi-im.org' 版= 'q07IKJEyjvHSyhy // CH0CxmKi8w =' /> </プレゼンス>
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サーバー、サーバーで認証し、[XMPP-CORE]で説明したようにXMLストリームにリソースを結合しました。交換することができるスタンザの一種である<メッセージ/>（つまり、メッセージング機能は、サーバー上で有効になっている場合など）。メッセージを交換することは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
人間のユーザは、（むしろ全く応答が期待されていないため、単一のメッセージを送信するよりも）接触このようなチャット・セッションに従事しようとするときは、ユーザのクライアントによって生成されたメッセージタイプは、「チャット」であるべきであり、連絡先のクライアントがそれを保存するべきです後続の応答メッセージ・タイプ。ユーザーのクライアントも含むべきです
<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).
連絡先のクライアントもチャットセッションの寿命の間に維持すべきで、その最初のメッセージ、と<スレッド/>要素（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 <domainpart / resourcepart @接触>を推測しようとするの裸JID <domainpart @接触>にチャットセッションの最初のメッセージに対処すべきですステータス/>、または<優先/>任意のプレゼンス通知、それは接触から受信した可能性があります）の値。ユーザーのクライアントは、連絡先からの応答を受信するまでとしない限り、それは、連絡先の裸のJIDに任意の更なるメッセージを送信すべきです。連絡先のクライアントは、最初のメッセージのアドレス「から」で提供されるユーザーの完全なJID <domainpart / resourcepart @ユーザー>への返信に対処すべきです。ユーザーのクライアントは、連絡先の完全なJIDからの応答を受信すると、それはこのように、連絡先の回答のアドレス「からは」その完全なJIDに「のロック」で提供される連絡先の完全なJIDにその後続のメッセージに対処すべきです。クライアントは<メッセージ/>またはピア（またはロックされたリソースからのプレゼンススタンザ）によって制御される他のリソースから<存在/>スタンザを受信した後に「ロック解除」すべきです。結果として、それはピアの裸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.
次のセクションでは、<メッセージ/>スタンザの構文を説明します。
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.
インスタントメッセージングクライアントは、<メッセージ/>スタンザの属性「から」で、目的の受信者の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).
メッセージは、任意の既存のチャットセッションのコンテキストまたは受信されたメッセージの値外に送信されている場合、アドレスではなく、フォームのより形式<ローカル部分@ domainpart>でなければならない「に」<ローカル部分@ 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>
<メッセージfrom='juliet@example.com/balcony 'のid = 'ktx72v49' to='romeo@example.net' TYPE = XMLを 'チャット'：LANG = 'EN'> <BODY>アートなたないロミオ、及びモンタギュー？</ BODY> </メッセージ>
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.
メッセージは、（例えば、一対一のチャットセッションのコンテキスト内で、セクション5.1で説明したように）以前にフォーム<ローカル部分@ domainpart / resourcepart>のアドレスから受信したメッセージに対する応答の値を送信している場合「から」アドレスの形式である必要がありますの<ローカル部分@ domainpart / resourcepart>ではなく、フォームのより<ローカル部@ 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>
<メッセージfrom='romeo@example.net/orchard 'ID = 'sl3nx51f' to='juliet@example.com/balcony' タイプ= [チャット] XML：LANG = 'EN'> <身体>どちらも、公正な聖人、いずれかの場合にはあなたが嫌いだ。</ BODY> </メッセージ>
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: 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.
インスタントメッセージングアプリケーションでメッセージスタンザの一般的な用途は次のとおりです。単一のメッセージを。 1対1のチャットセッションのコンテキストで送信されるメッセージ。マルチユーザーチャットルームのコンテキストで送信されるメッセージ。返事が期待されていないと警告、通知、または他の情報;そして、エラー。これらの用途は、「タイプ」属性で区別されています。 「タイプ」属性を含めることが推奨されます。含まれている場合は、「タイプ」属性は、次の値のいずれかが必要：Oチャット - メッセージは1対1のチャットセッションのコンテキストで送信されます。典型的には、インタラクティブクライアントは、適切な会話履歴を含む二者間で一対一のチャットを可能にするインタフェースで「チャット」タイプのメッセージを提示します。 1対1のチャットセッションに関する詳細な勧告は、セクション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グループチャット - メッセージ（[IRC]と同様）、マルチユーザチャット環境のコンテキスト内で送信されます。典型的には、受信したクライアントは、チャットルームでの当事者の名簿及び適切な会話履歴を含む当事者間の多対多のチャットを可能にするインタフェースの「グループチャット」タイプのメッセージを提示します。 XMPPベースのグループチャットの詳細については、[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の見出しは - メッセージが返事が期待されていないために、警告、通知、またはその他の過渡的な情報を提供する（例えば、ニュースヘッドライン、スポーツのアップデート、ほぼリアルタイムの市場データ、またはシンジケートコンテンツ）。メッセージへの返信が期待されていないため、通常、受信側のクライアントは、適切なスタンドアロンのメッセージからのメッセージを区別インターフェイスタイプ「見出し」のメッセージを提示したメッセージをチャット、グループチャットになるメッセージ（例えば、レシピエントを提供しないことにより、返信する能力）。 「から」アドレスは裸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正常 - メッセージは、1対1の会話又はグループチャットのコンテキスト外で送信されるスタンドアロンのメッセージであり、そして受信者が返信することが期待されました。典型的には、受信したクライアントは、応答する受信者を可能にするインタフェースで「正常」タイプのメッセージを提示するが、会話履歴無しであろう。 「タイプ」属性のデフォルト値は「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アプリケーションは、上記のメッセージタイプのすべてをサポートする必要があります。アプリケーションが受信した場合なし「タイプ」属性やアプリケーションとのメッセージが提供する「タイプ」属性の値を理解していない、それが「通常」のメッセージがタイプであることを考慮しなければならない（すなわち、「通常は」デフォルトです） 。
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').
「タイプ」属性はオプションですが、メッセージへの応答でタイプをミラーリングする礼儀正しいと考えられています。さらに、いくつかの特殊な用途（例えば、マルチユーザチャットサービス）は、その裁量で、特定のメッセージ・タイプ（例えば、タイプ=「グループチャット」）の使用を強制するかもしれません。
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.
<ボディ/>要素は、メッセージのテキストの内容を指定し、人間が読み取り可能な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>
<メッセージfrom='juliet@example.com/balcony 'ID = 'b4vs9km4' to='romeo@example.net' TYPE = XMLを 'チャット'：LANG = 'EN'> <BODY>それゆえアートなた、ロミオ<？ / BODY> </メッセージ>
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]).
「：LANGのxml」属性を除き、<ボディ/>要素に定義された属性は、ありません。異なる言語の値を持つ属性（明示的または<ボディ/>「langのXML」を要素は同じ本体の代替バージョンを提供する目的のためのメッセージスタンザに含まれてもよいが、各インスタンスが有する場合にのみ、複数のインスタンス遠いXML階層のアップ要素の値、[XMPP-CORE]に記載されているように、送信者の観点からXMLストリームヘッダを含むことができる）：「langの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>
<メッセージfrom='juliet@example.com/balcony 'ID = 'z94nb37h' to='romeo@example.net' TYPE = XMLを 'チャット'：LANG = 'EN'> <BODY>それゆえアートなた、ロミオ<？ / BODY> <身体のxml：LANG = 'CS'>プロ＆＃x010D; E＆＃x017D; JSIのTY、ロミオ？ </ BODY> </メッセージ>
The <body/> element MUST NOT contain mixed content (as defined in Section 3.2.2 of [XML]).
（[XML]のセクション3.2.2で定義されるように）<BODY />要素は、混合コンテンツを含んではなりません。
The <subject/> element contains human-readable XML character data that specifies the topic of the message.
<対象/>要素は、メッセージのトピックを指定し、人間が読める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>
<メッセージfrom='juliet@example.com/balcony 'ID = 'c8xg3nf8' to='romeo@example.net' タイプ= XMLを[チャット]：LANG = 'EN'> <対象>私はあなたを懇願</件名を！ > <BODY>それゆえアートなた、ロミオ</ body> </メッセージ>
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]).
「：LANGのxml」属性は、[XML]から継承されたのを除いて、<件名/>要素に定義された属性は、ありません。 「：langのXML」異なる言語の値を持つ属性（明示的に、またはからの継承によって、<主題/>要素は、同一の被写体の代替バージョンを提供する目的のために含まれてもよいが、各インスタンスが有する場合にのみ、複数のインスタンス「XML：langの」遠いXML階層のアップ要素の値、[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>
<メッセージfrom='juliet@example.com/balcony 'ID = 'jk3v47gw' to='romeo@example.net' タイプ= XMLを[チャット]：LANG = 'EN'> <対象>私はあなたを懇願</件名を！ > <対象XML：langは= 'CS'>＆＃x00DA; P＆＃x011B; nliv＆＃x011B。長所＆＃x00ED;メートル！ </件名> <身体>何のためにアート汝、ロミオ</ body>の<身体のxml：LANG = 'CS'>？プロ＆＃x010D; E＆＃x017E; JSIのTY、ロミオ？ </ BODY> </メッセージ>
The <subject/> element MUST NOT contain mixed content (as defined in Section 3.2.2 of [XML]).
（[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の主な用途は、<スレッド/>要素は一意に「チャット」タイプの<メッセージ/>スタンザによってインスタンス2つのエンティティ間の会話のスレッドまたは「チャットセッション」を識別することです。しかしながら、XMPP <スレッド/>要素を一意タイプの<メッセージ/>スタンザによってインスタンス2つのエンティティ間の類似スレッドを識別するためにも使用され得る「見出し」または「正常」、又は多の文脈における複数のエンティティのうちユーザーのチャットルームは、タイプの<メッセージ/>スタンザは、「グループチャット」でインスタンス化。また、このようなゲームセッションやプラグインの間の相互作用として、<メッセージ/>は、人間の会話に関連しないスタンザのために使用されるかもしれません。 <スレッド/>要素は、個々のメッセージのみの会話やメッセージングセッションを識別するために使用されていません。
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.
<スレッド/>要素の包含は任意です。 <スレッド/>要素は、メッセージが属する特定の会話スレッドを識別するため、メッセージスタンザは、複数の<スレッド/>要素を含んでいてはなりません。
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.
<スレッド/>要素は、現在のスレッドが分派や子となっている別のスレッドを特定「親」の属性を有することができます。 「親」属性は、「親」の属性が含まれている上、<スレッド/>要素の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).
実装上の注意：親スレッドと子スレッドの両方を指定する機能は、スレッドを重ねるためのスレッド識別子との競合の可能性を紹介します。例えば、1 <スレッドが/>要素は、「foo」とその値が2番目の<スレッド/>要素は、「バー」のXML文字データが含まれる可能性があります「バー」、および "である「親」属性のXML文字データが含まれる可能性があります親の値が再び 『foo』という親 『属性」、値が『バズ』は、属性、および3番目の<スレッド/>要素は、『バズ』とのXML文字データが含まれる可能性があります』。これは、例えば、それはマルチレベルのユーザインタフェースに「バズ」の親と孫の両方として「foo」を示すことによって「一緒にチェーン」スレッド識別子かどうか（そのような重複スレッド識別子との間の競合を処理する方法を実装次第であります、またはそれは）時点での依存関係の1つのレベルのみ表示されますか。
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]).
<スレッド/>要素は、人間が読めるものではなく、エンティティによって不透明なものとして扱わなければならないの値。何の意味論的な意味は、それに由来していないことができ、かつ唯一の正確な比較がそれに対して行うことができます。 <スレッド/>要素の値が一意に会話パートナーまたはより一般的に（一意性を確保する1つの方法は、汎用一意識別子（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]).
（[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>
<メッセージfrom='juliet@example.com/balcony 'to='romeo@example.net' タイプは、= XMLを[チャット]：LANG = 'EN'> <対象>私はあなたを懇願</サブジェクト> <サブジェクトのxml！ LANG = 'CS'>＆＃x00DA; P＆＃x011B; nliv＆＃x011B;長所＆＃x00ED;メートル！ </件名> <身体>何のためにアート汝、ロミオ</ body>の<身体のxml：LANG = 'CS'>？プロ＆＃x010D; E＆＃x017E; JSIのTY、ロミオ？ </ BODY> <スレッド親= 'e0ffe42b28561960c6b12b944a092794b9683a38'> 0e3141cd80894871a68e6fe6b1ec56fa </スレッド> </メッセージ>
For detailed recommendations regarding use of the <thread/> element, refer to [XEP-0201].
<スレッド/>要素の使用に関する詳細な推奨事項については、[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>
<メッセージfrom='juliet@example.com/balcony 'to='romeo@example.net' タイプ=は、XMLを[チャット]：LANG = 'EN'> <身体>それゆえアート汝、ロミオ</ BODY> <htmlの？ xmlns = 'のhttp：//jabber.org/protocol/xhtml-im'> <体のxmlns = 'のhttp：//www.w3.org/1999/xhtml'> <P>それゆえ<スパンのスタイル= "フォントスタイル：イタリック '>アート</ span>のあなた、<スパンのスタイル=' 色：赤 '>ロミオ</ span>を</ P> </ BODY> </ HTML> </メッセージ>？
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]で定義されていますタイプのIQスタンザの子要素は、「取得」または「設定」。 「おしゃべり：クライアント」と 'おしゃべり：サーバの名前空間は、すべてのスタンザタイプに共通<エラー/>要素以外のIQスタンザの子を定義していません。この文書では、選手（セクション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>、彼はそのresourcepart「果樹園」で使用可能なリソースを持っている、と彼は彼の名簿で以下の個人があります。
o <juliet@example.com> (subscription="both" and she has two available resources, "chamber" and "balcony")
O <juliet@example.com>（サブスクリプション=「両方」と、彼女は2つの利用可能なリソース、「室」と「バルコニー」を持っています）
o <benvolio@example.net> (subscription="to")
O <benvolio@example.net>（サブスクリプション= "へ"）
o <mercutio@example.org> (subscription="from")
O <mercutio@example.org>（サブスクリプション= "から"）
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' タイプ= '取得'> <クエリのxmlns = 'ジャバー：IQ：名簿' /> </ 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>
米国：<IQのid = 'hf61v3n7' to='romeo@example.net/orchard 'タイプ= '結果'> <クエリのxmlns = 'ジャバー：IQ：名簿'> <項目jid='juliet@example.com' 名前= 'ジュリエット' 加入= '両方'> <グループ>友達</グループ> </商品> <商品jid='benvolio@example.org 'NAME = 'ベンヴォリオ' 加入= 'に'/> <項目JID =' mercutio@example.org」名前= ' '/> </クエリ> </ IQからマーキューシオ' サブスクリプション='>
Now the user begins a presence session.
今、ユーザーがプレゼンスセッションを開始します。
Example 3: User sends initial presence
例3：ユーザーが初期の存在を送ります
UC: <presence/>
UC：<存在/>
Example 4: User's server sends presence probes to contacts with subscription="to" and subscription="both" on behalf of the user
例4：ユーザーのサーバーは= =「と」サブスクリプションおよびサブスクリプションとの接点に存在プローブを送信し、「両方」ユーザーのために
US: <presence from='romeo@example.net' to='juliet@example.com' type='probe'/>
米国：<プレゼンスfrom='romeo@example.net 'to='juliet@example.com' タイプ= 'プローブ' />
US: <presence from='romeo@example.net' to='benvolio@example.org' type='probe'/>
米国：<プレゼンスfrom='romeo@example.net 'to='benvolio@example.org' タイプ= 'プローブ' />
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：ユーザーのサーバーは、「両方」ユーザーの利用可能な資源に代わって、だけでなく、ユーザーに= =「から」サブスクリプションおよびサブスクリプションとの接触に最初の存在を送ります
US: <presence from='romeo@example.net/orchard' to='juliet@example.com'/>
米国：<プレゼンスfrom='romeo@example.net/orchard 'to='juliet@example.com' />
US: <presence from='romeo@example.net/orchard' to='mercutio@example.org'/>
米国：<存在from='romeo@example.net/orchard 'to='mercutio@example.org' />
US: <presence from='romeo@example.net/orchard' to='romeo@example.net'/>
米国：<存在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：<xmlの「to='romeo@example.netのプレゼンスfrom='juliet@example.com/balcony：LANG = 'EN'> <ショー>離れて</ショー> <状態>すぐ戻る</ステータス> <優先度> 0 </優先> </プレゼンス>
CS: <presence from='juliet@example.com/chamber' to='romeo@example.net'> <priority>1</priority> </presence>
CS：<存在from='juliet@example.com/chamber 'to='romeo@example.net'> <優先順位> 1 </優先順位> </プレゼンス>
CS: <presence from='benvolio@example.org/pda' to='romeo@example.net' xml:lang='en'> <show>dnd</show> <status>gallivanting</status> </presence>
CS：<xmlの「to='romeo@example.netのプレゼンスfrom='benvolio@example.org/pda：langは= 'EN'> <ショー> DND </表示し> <状態> </ステータス> </ gallivanting存在>
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：<プレゼンスfrom='romeo@example.net/orchard 'to='juliet@example.com' />
CS: <presence from='romeo@example.net/orchard' to='juliet@example.com'/>
CS：<プレゼンスfrom='romeo@example.net/orchard 'to='juliet@example.com' />
CS: <presence from='romeo@example.net/orchard' to='mercutio@example.org'/>
CS：<存在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：<プレゼンスfrom='romeo@example.net/orchard 'to='nurse@example.com' のxml：langは= 'EN'> <ショー> DND <状態> </表示さ>をジュリエット</ステータス> <求愛優先順位> 0 </優先順位> </プレゼンス>
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：<メッセージfrom='juliet@example.com/balcony 'to='romeo@example.net' タイプ= XMLを[チャット]：LANG = 'EN'> <身体>私の耳にはまだ酔っていない百の言葉< / body> <スレッド> e0ffe42b28561960c6b12b944a092794b9683a38 </スレッド> </メッセージ>
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：<メッセージfrom='juliet@example.com/balcony 'to='romeo@example.net' タイプ= XMLを[チャット]：langは 'EN' =>その舌の発話の<身体>、まだ私は音を知っています</ body> <スレッド> e0ffe42b28561960c6b12b944a092794b9683a38 </スレッド> </メッセージ>
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：<メッセージfrom='juliet@example.com/balcony 'to='romeo@example.net' タイプ= XMLを[チャット]：LANG = 'EN'> <身体>アート汝ないロミオとモンタギューを<？ / body> <スレッド> e0ffe42b28561960c6b12b944a092794b9683a38 </スレッド> </メッセージ>
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：<メッセージfrom='romeo@example.net/orchard 'to='juliet@example.com/balcony' タイプ= xmlの[チャット]：langは= 'EN'>のいずれかあなたの場合は、<body>のどちらも、公正聖人嫌い。</ body> <スレッド> e0ffe42b28561960c6b12b944a092794b9683a38 </スレッド> </メッセージ>
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：<メッセージfrom='juliet@example.com/balcony 'to='romeo@example.net/orchard' タイプ= XMLを[チャット]：LANG = 'EN'> <身体>どのようにcam'st魅惑のthou、教えて私、そして何のために？</ body> <スレッド> e0ffe42b28561960c6b12b944a092794b9683a38 </スレッド> </メッセージ>
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：<プレゼンスのxml：langは= 'EN'>！<ショー>離れて</ショー> <ステータス>私が返還しなければならない。</ステータス> <優先順位> 1 </優先順位> </プレゼンス>
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>
米国：<存在from='romeo@example.net/orchard 'to='juliet@example.com' のxml：LANG = 'EN'>！<ショー>離れて</ショー> <状態>私が返還しなければならない</ステータス> <優先順位> 1 </優先> </プレゼンス>
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>
米国：<存在from='romeo@example.net/orchard 'to='mercutio@example.org' のxml：LANG = 'EN'>！<ショー>離れて</ショー> <状態>私が返還しなければならない</ステータス> <優先順位> 1 </優先> </プレゼンス>
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：<存在from='romeo@example.net/orchard 'to='juliet@example.com' のxml：LANG = 'EN'>！<ショー>離れて</ショー> <状態>私が返還しなければならない</ステータス> <優先順位> 1 </優先> </プレゼンス>
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：<存在from='romeo@example.net/orchard 'to='juliet@example.com' のxml：LANG = 'EN'>！<ショー>離れて</ショー> <状態>私が返還しなければならない</ステータス> <優先順位> 1 </優先> </プレゼンス>
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：<存在from='romeo@example.net/orchard 'to='mercutio@example.org' のxml：LANG = 'EN'>！<ショー>離れて</ショー> <状態>私が返還しなければならない</ステータス> <優先順位> 1 </優先> </プレゼンス>
Example 13: One of the contact's resources broadcasts unavailable notification
例13：連絡先の資源の一つが利用できない通知をブロードキャスト
CC: <presence from='juliet@example.com/chamber' type='unavailable'/>
CC：<プレゼンスfrom='juliet@example.com/chamber」タイプ= '使用できません' />
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：<プレゼンスfrom='juliet@example.com/chamber 'to='romeo@example.net' タイプ= '使用できません' />
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：<プレゼンスタイプ= '使用できません' のxml：LANG = 'EN'> <状態>帰宅</ステータス> </プレゼンス>
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>
米国：<プレゼンスfrom='romeo@example.net/orchard 'to='juliet@example.com' タイプ= '使用できません' のxml：LANG = 'EN'> <状態>帰宅</ステータス> </プレゼンス>
US: <presence from='romeo@example.net/orchard' to='mercutio@example.org' type='unavailable' xml:lang='en'> <status>gone home</status> </presence>
米国：<プレゼンスfrom='romeo@example.net/orchard 'to='mercutio@example.org' タイプ= '使用できません' のxml：LANG = 'EN'> <状態>帰宅</ステータス> </プレゼンス>
US: <presence from='romeo@example.net/orchard' to='nurse@example.com' type='unavailable' xml:lang='en'> <status>gone home</status> </presence>
米国：<プレゼンスfrom='romeo@example.net/orchard 'to='nurse@example.com' タイプ= '使用できません' のxml：LANG = 'EN'> <状態>帰宅</ステータス> </プレゼンス>
Finally the user closes his stream and the server responds in kind.
最後に、ユーザは自分のストリームを閉じ、サーバが親切に応答します。
Example 17: User closes stream
実施例17：ユーザーがストリームを閉じ
UC: </stream:stream>
UC：</ストリーム：ストリーム>
Example 18: User's server closes stream
例18：ユーザーズ・サーバーは、ストリームを閉じます
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]。次のセクションでの適合性言語（MUST、SHOULD、など）は、そのようなローカルサービスポリシーを上書きするものではありません。
If the stanza possesses no 'to' attribute, the rules defined in [XMPP-CORE] apply.
スタンザ属性「に」はを持っている場合は、[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.
アウトバウンドスタンザの属性「から」に含まれるアドレスの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は、リモートインスタントメッセージングとプレゼンスサービスがXMPPを介して通信するかどうかを発見するための代替方法として_im._xmppと_pres._xmpp SRVレコード[IMP-SRV]を使用する方法を指定しました。これらの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.
「」の属性に含まれる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.
「から」のアドレスが指定されている場合JIDのdomainpartはサーバ自体によってサービスされて構成されたドメインと一致するところ、次のように裸JID <ローカル部@ domainpart>または完全なJID <ローカル部分@ domainpart / resourcepart>は、サーバが進まなければなりません。
If the user account identified by the 'to' attribute does not exist, how the stanza is processed depends on the stanza type.
で識別されるユーザーアカウントが属性が存在しない「に」の場合、スタンザがどのように処理されるかスタンザの種類によって異なります。
o For an IQ stanza, the server MUST return a <service-unavailable/> stanza error to the sender.
O IQスタンザの場合、サーバーは、送信者に、<サービス利用できません/>スタンザ誤りを返さなければなりません。
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）の送信者に、<サービス利用不可/>スタンザエラーを返します。
o For a presence stanza with no 'type' attribute or a 'type' attribute of "unavailable", the server MUST silently ignore the stanza.
Oノー「タイプ」属性または「利用不可」の「タイプ」属性を持つ存在スタンザの場合、サーバは黙っスタンザを無視しなければなりません。
o For a presence stanza of type "subscribe", "subscribed", "unsubscribe", or "unsubscribed", the server MUST silently ignore the stanza.
Oタイプの存在スタンザについては、「サブスクライブ」「退会」、または「解除」を「購読」、サーバは黙っスタンザを無視しなければなりません。
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型の「プローブ」の存在スタンザの場合、サーバは、（a）はサイレントスタンザを無視しなければならない、または（b）の「解除」型の存在スタンザを返します。
If the JID contained in the 'to' attribute is of the form <localpart@domainpart>, then the server MUST adhere to the following rules.
JIDは「から」属性に含まれている場合は、フォーム<ローカル部@ domainpart>であり、サーバーは、以下の規則に従わなければなりません。
If there is at least one available resource or connected resource, how the stanza is processed depends on the stanza type.
ある場合はスタンザがどのように処理されるか、少なくとも1つの利用可能なリソースまたは接続リソースは、スタンザの種類によって異なります。
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）<サービス利用不可/>であるべき送信者にスタンザエラーを返します。
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":
「チャット」タイプのメッセージスタンザの場合：
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）<サービス利用不可/>であるべき送信者にスタンザエラーを返します。
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/>.
タイプのメッセージスタンザ「グループチャット」の場合、サーバーは利用可能なリソースのいずれかにスタンザを提供してはならないが、代わりに</サービス-利用できない>すべき、送信者にスタンザエラーを返さなければなりません。
For a message stanza of type "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.
タイプ「エラー」のメッセージスタンザの場合、サーバは静かにメッセージを無視しなければなりません。
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>).
すべての場合において、サーバは（すなわち、それは<ローカル部@ domainpart>としてそれを残すのではなく、<ローカル部分@ domainpart / resourcepart>に変更する必要があります）「から」属性を書き換えてはなりません。
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.
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>).
すべての場合において、サーバは（すなわち、それは<ローカル部@ domainpart>としてそれを残すのではなく、<ローカル部分@ domainpart / resourcepart>に変更する必要があります）「から」属性を書き換えてはなりません。
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 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エラーのいずれかを利用者に代わって返信しなければならない、とユーザーの利用可能なリソースのいずれかにIQスタンザを提供してはなりません。予選名前空間のセマンティクスは、サーバーがユーザーに代わって提供することができるとの回答を定義する場合は具体的に、サーバはタイプ「結果」のIQスタンザやIQのいずれかを返すことによって、ユーザーに代わってスタンザに返信しなければなりません元のペイロードに適したタイプ「エラー」のスタンザ。ない場合は、サーバは、<サービス利用できません/>スタンザ誤りで返答しなければなりません。
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）<サービス利用不可/>であるべき送信者にスタンザエラーを返すにメッセージを追加する必要があります。
For a message stanza of type "groupchat", the server MUST return an error to the sender, which SHOULD be <service-unavailable/>.
タイプのメッセージスタンザ「グループチャット」の場合、サーバーは</サービス利用できません>すべき、送信者にエラーを返さなければなりません。
For a message stanza of type "headline" or "error", the server MUST silently ignore the message.
タイプ「見出し」または「エラー」のメッセージスタンザの場合、サーバは静かにメッセージを無視しなければなりません。
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.
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エラーのいずれかでユーザーの代わりに返答しなければなりません。予選名前空間のセマンティクスは、サーバーがユーザーに代わって提供することができるとの回答を定義する場合は具体的に、サーバはタイプ「結果」のIQスタンザやIQのいずれかを返すことによって、ユーザーに代わってスタンザに返信しなければなりません元のペイロードに適したタイプ「エラー」のスタンザ。ない場合は、サーバは、<サービス利用できません/>スタンザ誤りで返答しなければなりません。
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.
JIDのdomainpartは、インバウンドスタンザの属性「から」に含まれている場合は「から」属性の形式は、<ローカル部分@ domainpart / resourcepart>、その後に含まれるサーバー自体とJIDの設定されたドメインのいずれかと一致サーバーは、次の規則に従わなければなりません。
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型の「取得」または意図された受信者は、いずれかの「両方」または「から」タイプのプレゼンスサブスクリプションによって、又は監督の存在によって、要求エンティティと存在感を共有していない場合は、「設定」のIQスタンザのために、その後、サーバーはIQスタンザを届けるべきではなく、代わりに要求しているエンティティに<サービス利用できません/>スタンザエラーを返すべきです。このポリシーは、（セクション11を参照）の存在漏れを防ぐことができます。
o For an IQ stanza of type "result" or "error", the server MUST deliver the stanza to the resource.
O型の「結果」または「エラー」の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ノー「タイプ」属性または「利用不可」の「タイプ」属性を持つ存在スタンザの場合、サーバーは、リソースへのスタンザを提供しなければなりません。
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タイプの存在スタンザ「プローブ」は、サーバーは、セクション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/>.
メッセージタイプのスタンザ「正常」、「グループチャット」、または「見出し」のために、サーバは、（a）はサイレントスタンザを無視しなければならないのいずれか、または（B）/ <サービス利用不可すべき、送信者にエラースタンザを返します>。
For a message stanza of type "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）<サービス利用不可/>であるべき送信者にエラースタンザを返します。
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）の送信者にスタンザエラーを返します。
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.
タイプ「エラー」のメッセージスタンザの場合、サーバは黙っスタンザを無視しなければなりません。
For a presence stanza with no 'type' attribute or a 'type' attribute of "unavailable", the server MUST silently ignore the stanza.
ノー「タイプ」属性または「利用不可」の「タイプ」属性を持つ存在スタンザの場合、サーバは黙っスタンザを無視しなければなりません。
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.
タイプ「サブスクライブ」の存在スタンザの場合は、「退会」、または「解除」、サーバはスタンザを無視しなければなりません。
For a presence stanza of type "probe", the server MUST follow the guidelines provided under Section 4.3.
タイプ「プローブ」の存在スタンザの場合、サーバーは、セクション4.3の下で提供されたガイドラインに従わなければなりません。
For an IQ stanza, the server MUST return a <service-unavailable/> stanza error to the sender.
IQスタンザの場合、サーバーは、送信者に、<サービス利用できません/>スタンザ誤りを返さなければなりません。
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裸）アドレス「」の非負プレゼンス優先度）とを有しています。 （静かにメッセージを無視して、メッセージをオフライン（O）を格納スタンザエラー（E）を用いてメッセージをバウンス：後続の列は、6つの可能な配信オプションと一緒に（、グループチャット、または見出しをチャット、ノーマル）は、4つの主要メッセージタイプを一覧しますS）、とリソースまたはリソースを処理すること、例えば、サーバの実装固有のアルゴリズムに従って「最も利用できる」リソースまたはリソースへのメッセージを配信する、「から」アドレス（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 |
+----------------------------------------------------------+
* 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.
（XMLスタンザのアドレス「に」「から」とで、例えば）XMPPネットワーク上の通信に使用されるXMPPエンティティのアドレスは、ユニフォームリソース識別子[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する（例えば、World Wide Web上のページ）は、URIとして、あるいは国際化リソース識別子[IRI]のいずれかとしてXMPP実体を特定する必要があるかもしれません、とXMPPクライアントが対話する必要がありますそのような外部アプリケーションとの（例えば、XMPPクライアントは、Webページ内のリンクをクリックすることによって呼び出されるかもしれません）。このような相互作用の文脈では、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と虹彩。 「PRES：」[CPIM]で指定されたとようなURI：「IM」XMPPクライアントもとしてエンコードされているアドレスを処理することが推奨されますが：」または「IM」[CPP]で指定されたURIを、彼らは除去することによって、そうすることができます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のためのコアのセキュリティの考慮事項は、チャネルの暗号化、認証、情報漏洩、サービス拒否攻撃、およびドメイン間のフェデレーションの議論を含め、[XMPP-CORE]のセクション13に設けられています。
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.は好ましくはローカルクライアントとリモートサーバとの通信のためのチャネルの暗号化の使用を義務付けます。
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 technology for encryption and signing of XML stanzas if it wishes to ensure end-to-end confidentiality and integrity of its communications.
セクション13.1と13.4で説明したように、サーバは、上記の責任を果たしても、[XMPP-CORE]は、クライアントがある（同じサーバーまたはリモートサーバー上のかどうか）、それは他のクライアントとのやり取り可能性があるスタンザいかなる保証を持っていませんXMPP通信経路に沿って、又はサーバ自体内の全てのホップのために保護されました。その通信のエンドツーエンドの機密性と完全性を確保したい場合に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、サーバーはユーザーのプレゼンスを明らかにしてはなりませんプレゼンス購読（セクション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ユーザーのサーバーは、ユーザーのプレゼンスを知ることを許可されていないエンティティに、ユーザのネットワーク可用性を漏洩してはなりません。 （第3節で説明したように）XMPP自体に、認可は、ユーザにコンタクトからの明示的なサブスクリプションの形をとります。しかし、いくつかの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クライアントは、<状態/>要素を無視してもよいです。これは、「プレゼンスサブスクリプションスパム」を防ぐことができます。
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 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)
機能は、クライアントの役割、サーバーの役割、またはその両方（「N / A」は機能が指定されたロールには適用されないことを意味している）に適用されるかどうかO
o Whether the feature MUST or SHOULD be implemented, where the capitalized terms are to be understood as described in [KEYWORDS]
特徴は、または大文字用語で記載されるように理解されるべきである場合、実装されるべき必要があるかどうかをO [KEYWORDS]
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].
ここで指定された機能セットは、[INTEROP]で撮影して、2005年にIETFのワーキンググループNEWTRK内ラリーMasinterによって提案された概念とフォーマットを遵守しようとします。この機能セットは[REPORTS]によって要求されるよりも詳細であるが、それは[PROCESS]に従って標準ドラフトすることが提案標準からこの仕様を前進をサポートするために提出する実装レポートの生成のための適切な基礎を提供します。
Feature: message-body Description: Support the <body/> child element of the <message/> stanza. Section: Section 5.2.3 Roles: Client MUST, Server N/A.
特集：メッセージ本文の説明：<メッセージ/>スタンザの<ボディ/>子要素をサポートしています。セクション：セクション5.2.3役割：クライアントMUST、サーバーN / A。
Feature: message-subject Description: Support the <subject/> child element of the <message/> stanza. Section: Section 5.2.4 Roles: Client SHOULD, Server N/A.
特集：メッセージ件名説明：<メッセージ/>スタンザの<主題/>子要素をサポートしています。セクション：5.2.4役割：クライアントSHOULD、サーバN / A。
Feature: message-thread Description: Support the <thread/> child element of the <message/> stanza. Section: Section 5.2.5 Roles: Client SHOULD, Server N/A.
特集：メッセージスレッドの説明：<メッセージ/>スタンザの<スレッド/>子要素をサポートしています。セクション：セクション5.2.5役割：クライアントSHOULD、サーバN / A。
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役割：クライアントSHOULD、サーバN / A。
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つの役割：クライアントN / A、サーバー必要があります。
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説明：可用性を示すようがない「タイプ」属性でのプレゼンススタンザを扱います。セクション：セクション4.7.1役割：クライアントMUST、サーバー必要があります。
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.
特集：プレゼンス・プローブの説明：プレゼンス情報の発見のための「プローブ」の「タイプ」属性でのプレゼンススタンザを送受信します。セクション：セクション4.7.1役割：クライアントN / A、サーバー必要があります。
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役割：クライアントMUST、サーバー必要があります。
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.
特集：プレゼンスサブ取り消し説明：別のエンティティから受信したサブスクリプション要求を拒否したり、以前に別のエンティティに付与されたサブスクリプションの承認を取り消す行為として「解除」タイプのアウトバウンド存在スタンザを扱い、タイプのインバウンドプレゼンススタンザを扱います別のエンティティから加入拒否やキャンセルなどの「解除」。セクション：セクション3.2役割：クライアントMUST、サーバー必要があります。
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.
機能：プレゼンスサブ事前承認説明：別のエンティティから受信した加入要求を事前承認の行為として、特定の状況において、「サブスクライブ」タイプのアウトバウンド存在スタンザを扱います。名前空間これは「：IQ名簿ジャバー」内の<item />要素の「承認」属性をサポートしています。セクション：3.4節の役割：クライアント、サーバMAY。
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役割：クライアントMUST、サーバー必要があります。
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節の役割：クライアントMUST、サーバー必要があります。
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.
特集：プレゼンス-使用できません説明：可用性の欠如を示すものとして「利用不可」の「タイプ」属性でのプレゼンススタンザを扱います。セクション：セクション4.7.1役割：クライアントMUST、サーバー必要があります。
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.
特集：名簿-getの説明：サーバ上のアカウントに関連付けられている名簿の情報を取得するための要求として、名前空間タイプのIQスタンザを扱う「名簿：：IQジャバー」によって修飾空の<クエリ/>要素を含む「取得」 。セクション：セクション2.1.3役割：クライアントMUST、サーバー必要があります。
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.
機能：名簿セット説明：<クエリ/>に含まれる項目を追加または更新する要求として、名前空間「名簿：IQジャバー」によって修飾<クエリ/>要素を含むタイプのIQスタンザを扱う「セット」素子。セクション：2.1.5役割：クライアントMUST、サーバー必要があります。
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役割：クライアントMUST、サーバー必要があります。
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.
機能：名簿バージョン説明：送信または受信された名簿情報の特定のバージョンの識別子として、名前空間「名簿：IQジャバー」によって修飾<クエリ/>要素の属性「版」を扱います。セクション：セクション2.1.1役割：クライアントSHOULD、サーバー必要があります。
[DELAY] Saint-Andre, P., "Delayed Delivery", XSF XEP 0203, September 2009.
[DELAY]サンアンドレ、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.
[キーワード]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、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-マックィーン、C.、パオリ、J.、およびT.ブレイ、 "拡張マークアップ言語（XML）1.0（第5版）"、ワールドワイドウェブコンソーシアム推薦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]ブレイ、T.、オランダ、D.、およびA.素人、 "XMLで名前空間"、W3C REC-XML-名、1999年1月、<http://www.w3.org/TR/REC -xml-名>。
[XMPP-CORE] Saint-Andre, P., "Extensible Messaging and Presence Protocol (XMPP): Core", RFC 6120, March 2011.
[XMPP-CORE]サンアンドレ、P.、 "拡張メッセージングおよびプレゼンスプロトコル（XMPP）：コア"、RFC 6120、2011年3月。
[CPIM] Peterson, J., "Common Profile for Instant Messaging (CPIM)", RFC 3860, August 2004.
[CPIM]ピーターソン、J.、 "インスタントメッセージングのための共通プロファイル（CPIM）"、RFC 3860、2004年8月。
[CPP] Peterson, J., "Common Profile for Presence (CPP)", RFC 3859, August 2004.
[CPP]ピーターソン、J.、 "プレゼンスのための共通プロファイル（CPP）"、RFC 3859、2004年8月。
[DOS] Handley, M., Rescorla, E., and IAB, "Internet Denial-of-Service Considerations", RFC 4732, December 2006.
[DOS]ハンドリー、M.、レスコラ、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]日、M.、ローゼンバーグ、J.、およびH.菅野、 "プレゼンスとインスタントメッセージングのためのモデル"、RFC 2778、2000年2月。
[IMP-REQS] Day, M., Aggarwal, S., and J. Vincent, "Instant Messaging / Presence Protocol Requirements", RFC 2779, February 2000.
[IMP-REQS]日、M.、アガルワル、S.、およびJ.ヴィンセント、 "インスタントメッセージング/プレゼンスプロトコル要件"、RFC 2779、2000年2月。
[IMP-SRV] Peterson, J., "Address Resolution for Instant Messaging and Presence", RFC 3861, August 2004.
[IMP-SRV]ピーターソン、J.、 "インスタントメッセージングとプレゼンスのためのアドレス解決"、RFC 3861、2004年8月。
[INTEROP] Masinter, L., "Formalizing IETF Interoperability Reporting", Work in Progress, October 2005.
"IETFの相互運用性のレポート形式化" [INTEROP] Masinter、L.、進歩、2005年10月に作業。
[IRC] Kalt, C., "Internet Relay Chat: Architecture", RFC 2810, April 2000.
[IRC] Kalt、C.は、 "インターネットリレーチャット：アーキテクチャ"、RFC 2810、2000年4月を。
[IRI] Duerst, M. and M. Suignard, "Internationalized Resource Identifiers (IRIs)", RFC 3987, January 2005.
[IRI] Duerst、M.およびM. Suignard、 "国際化リソース識別Fiers（IRI）"、RFC 3987、2005年1月。
[PROCESS] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996.
[プロセス]ブラドナーの、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.
[REPORTS] Dusseault、L.およびR.スパークス、 "標準を起草する推進のための相互運用上の指針と実装レポート"、BCP 9、RFC 5657、2009年9月。
[RFC3920] Saint-Andre, P., Ed., "Extensible Messaging and Presence Protocol (XMPP): Core", RFC 3920, October 2004.
[RFC3920]サンアンドレ、P.、エド、 "拡張メッセージングおよびプレゼンスプロトコル（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]サンアンドレ、P.、エド、 "拡張メッセージングおよびプレゼンスプロトコル（XMPP）：インスタントメッセージングとプレゼンス"。、RFC 3921、2004年10月。
[SASL] Melnikov, A. and K. Zeilenga, "Simple Authentication and Security Layer (SASL)", RFC 4422, June 2006.
[SASL]メルニコフ、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]ローゼンバーグ、J.、RFC 3856 "セッション開始プロトコル（SIP）のためのプレゼンスイベントパッケージ"、2004年8月。
[TLS] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[TLS]ダークス、T.およびE.レスコラ、 "トランスポート層セキュリティ（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]サンアンドレ、P.およびJ.ホッジス、「表現とドメインベースのアプリケーションサービスのアイデンティティの検証、インターネット公開鍵インフラストラクチャ内のトランスポート層セキュリティ（TLS）のコンテキストでX.509（PKIX）証明書を使用しました」、RFC 6125、2011年3月。
[UNICODE] The Unicode Consortium, "The Unicode Standard, Version 6.0", 2010, <http://www.unicode.org/versions/Unicode6.0.0/>.
[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]バーナーズ - リー、T.、フィールディング、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]リーチ、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]ミラード、P.およびP.サンアンドレ、 "個人情報保護リスト"、XSF XEP 0016、2007年2月。
[XEP-0045] Saint-Andre, P., "Multi-User Chat", XSF XEP 0045, July 2008.
[XEP-0045]サンアンドレ、P.、 "マルチユーザーチャット"、XSF XEP 0045、2008年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]ヒルデブラント、J.、サン・アンドレ、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]サンアンドレ、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]サンアンドレ、P.、パターソン、I.、およびK.スミス、 "メッセージスレッドのためのベストプラクティス"、XSF XEP 0201、2010年11月。
[XEP-0237] Saint-Andre, P. and D. Cridland, "Roster Versioning", XSF XEP 0237, March 2010.
[XEP-0237]サンアンドレ、P.およびD. Cridland、 "名簿バージョン管理"、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]ビロン、P.およびA.マルホトラ、 "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]トンプソン、H.、マロニー、M.、メンデルゾーン、N.、およびD.ブナ、 "XMLスキーマパート1：構造第二版"、World Wide Web Consortium（W3C）の勧告REC-XMLSCHEMA-1から20041028、10月2004年、<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]サンアンドレ、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]サンアンドレ、P.、 "国際化資源識別子（IRIを）および拡張メッセージングおよびプレゼンスプロトコル（XMPP）のためのユニフォームリソース識別子（URI）"、RFC 5122、2008年2月。
[VCARD] Dawson, F. and T. Howes, "vCard MIME Directory Profile", RFC 2426, September 1998.
[VCARD]ドーソン、F.とT.ハウズ、 "vCardのMIMEディレクトリプロフィール"、RFC 2426、1998年9月。
Appendix A. Subscription States
付録A.サブスクリプションの状態
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").
このセクションでは（すなわち、型の存在スタンザが「購読」「購読」、「解除」、および「解除」）の加入状態とサブスクリプションに関連するプレゼンススタンザのサーバ処理についての詳細な情報を提供します。
A.1. Defined States
A.1。定義された状態
There are four primary subscription states (these states are described from the perspective of the user, not the contact):
4つの主要なサブスクリプションの状態は、（これらの状態は、ユーザーではなく、接触の観点から説明されている）があります。
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.
To：ユーザー、連絡先のプレゼンスへのサブスクリプションを持っていますが、連絡先は、ユーザーのプレゼンスへのサブスクリプションを持っていません。
From: The contact has a subscription to the user's presence, but the user does not have a subscription to the contact's presence.
From：連絡先は、ユーザーのプレゼンスに加入しているが、ユーザーは、連絡先のプレゼンスへのサブスクリプションを持っていません。
Both: Both the user and the contact have subscriptions to each other's presence (i.e., the union of 'from' and '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:
上記の状態は、このように9つの可能なサブスクリプションの状態を得、インバウンドとアウトバウンドのサブスクリプションを保留に関連する様々なサブ状態によって補完されています。
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.「なし」=連絡先とユーザーがお互いに加入していないされていない、どちらも他のサブスクリプションを要求しました。これは、サブスクリプション=「なし」で利用者の名簿に反映されています。
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.「なし+アウト保留」=連絡先とユーザーがお互いに加入していないされていないため、ユーザーは連絡先に登録要求を送信したが、接触はまだ答えていません。これは、サブスクリプション=「なし」と「購読」=尋ねることで、ユーザの名簿に反映されています。
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 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).
3.「なし+保留中」=連絡先とユーザーがお互いに加入されていない、との接触は、ユーザーに購読要求を送信したが、ユーザーはまだ答えていません。次のようにこの状態は、または、利用者の名簿に反映されない場合があります：ユーザーが連絡先の名簿項目を作成した場合、サーバはその名簿項目を維持しなければなりませんし、またもし一方、インバウンドプレゼンスサブスクリプション要求の有無の点に注意してください。ユーザーが連絡先の名簿アイテムを作成していない、ユーザのサーバは、ユーザが前にサブスクリプション要求を承認するまで（代わりに、サーバは待たなければなりませんインバウンドプレゼンスサブスクリプション要求の有無に注意しなければならないが、連絡先の名簿項目を作成してはいけません）は、ユーザの名簿に連絡先を追加します。
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.「なし+ +でアウト保留」=連絡先とユーザーがお互いに加入していない、接触がサブスクリプション要求が、ユーザーがまだ答えていない、ユーザーがサブスクリプション要求が、連絡先を連絡先を送信したユーザーを送ったが、まだ回答していないされていません。これは、サブスクリプション=「なし」と「購読」=尋ねることで、ユーザの名簿に反映されています。
5. "To" = User is subscribed to contact (one-way); this is reflected in the user's roster by subscription='to'.
=ユーザが（一方向）に接触するようにサブスクライブされている「から」5。これは、「に」=サブスクリプションにより、利用者の名簿に反映されています。
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.連絡を購読している、との接触は、ユーザーに購読要求を送信したが、ユーザーはまだ答えていません。これは、「に」=サブスクリプションにより、利用者の名簿に反映されています。
7. "From" = Contact is subscribed to user (one-way); this is reflected in the user's roster by subscription='from'.
7. =連絡先は、ユーザー（片道）に加入している「から」。これは、「から」=サブスクリプションにより、利用者の名簿に反映されています。
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. =連絡先をユーザに加入されており、ユーザは、サブスクリプション要求が、接触はまだ答えていない連絡先を送信した「アウト保留+から」。これは「から」=サブスクリプションにより、利用者の名簿に反映し、「購読」=お願いしています。
9. "Both" = User and contact are subscribed to each other (two-way); this is reflected in the user's roster by subscription='both'.
9.「両方」=ユーザーとの接触は、相互（双方向）に加入されています。これは、=「」の両方のサブスクリプションにより、ユーザーの名簿に反映されています。
A.2. Server Processing of Outbound Presence Subscription Stanzas
A.2。アウトバウンドプレゼンスサブスクリプションのスタンザのサーバー処理
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.は」NOT MUSTを表します。）
A.2.1. Subscribe
A.2.1。申し込む
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 |
+------------------------------------------------------------------+
[1] A state change to "pending out" includes setting the 'ask' flag to a value of "subscribe" in the user's roster.
[1]「アウト保留」への状態変化は、ユーザの名簿に「購読」の値に「頼む」フラグを設定することを含みます。
A.2.2. Unsubscribe
A.2.2。登録解除
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" |
+-----------------------------------------------------------------+
A.2.3. Subscribed
A.2.3。購読
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 |
+-----------------------------------------------------------------+
[1] Detailed information regarding subscription pre-approval is provided under Section 3.4.
[1]加入事前承認に関する詳細な情報は、セクション3.4の下に設けられています。
A.2.4. Unsubscribed
A.2.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" |
+-----------------------------------------------------------------+
[1] This event can result in cancellation of a subscription pre-approval, as described under Section 3.4.
[1]このイベントは、セクション3.4で説明したように、サブスクリプション事前承認の取り消しをもたらすことができます。
A.3. Server Processing of Inbound Presence Subscription Stanzas
A.3。インバウンドプレゼンスサブスクリプションのスタンザのサーバー処理
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.は」べきではないを表します。）
A.3.1. Subscribe
A.3.1。申し込む
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 |
+------------------------------------------------------------------+
[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で説明したようなタイプの存在「購読」、サーバーMAY自動応答を送信し、なし+保留」ではなく「から」の状態を変更する場合に"。
[2] Server SHOULD auto-reply with "subscribed".
[2]サーバは、「サブスクライブ」で自動返信する必要があります。
A.3.2. Unsubscribe
A.3.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.
ユーザーのサーバーは、タイプの存在スタンザを受信すると、ユーザの視点から、サブスクリプションの状態変化でスタンザの結果は、ユーザーのサーバーが状態を変更しなければならない場合は、連絡先からのユーザのために「退会」接触からプレゼンススタンザを提供しなければなりませんユーザー、およびユーザーに代わって連絡先に「解除」タイプの存在スタンザを送信することにより、SHOULD自動返信します。 （状態変化がないので）それ以外の場合は、ユーザーのサーバーは、スタンザを提供すべきではない状態を変更してはなりません。これらのルールは、以下の表にまとめられています。
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" |
+------------------------------------------------------------------+
[1] Server SHOULD auto-reply with "unsubscribed".
[1]サーバは「解除」で自動返信をする必要があります。
A.3.3. Subscribed
A.3.3。購読
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.
ユーザーのサーバーは、連絡先からのユーザのために、「サブスクライブ」タイプの存在スタンザを受信すると、連絡先のプレゼンス情報へのアクセスのために保留中のアウトバウンド要求がない場合は何の状態が存在しないので、それはサブスクリプションの状態（を変更してはなりません変更）は、ユーザーにスタンザを提供すべきではありません。連絡先のプレゼンス情報とタイプのインバウンドプレゼンススタンザへのアクセスのための保留中のアウトバウンド要求がある場合は、サブスクリプションの状態変化の結果は、ユーザーのサーバーは、サブスクリプションの状態を変更しなければならないし、ユーザにスタンザを提供しなければならない「購読」。ユーザーがすでに連絡先のプレゼンス情報、タイプのインバウンドプレゼンススタンザに加入されている場合は、「加入」のサブスクリプションの状態の変化をもたらしません。 （状態変化がないため）ので、ユーザーのサーバーは、ユーザーにスタンザを提供すべきではないサブスクリプションの状態を変更してはなりません。これらのルールは、以下の表にまとめられています。
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 |
+------------------------------------------------------------------+
A.3.4. Unsubscribed
A.3.4。退会し
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.
ユーザが現在連絡先のプレゼンス情報を購読している連絡先のプレゼンス情報へのアクセスのための場合や、保留中のOutbound要求がある場合に、ユーザのサーバは、ユーザの、連絡先からのユーザのために、「解除」タイプの存在スタンザを受信した場合サーバーは、サブスクリプションの状態を変更しなければならないし、ユーザにスタンザを提供しなければなりません。 （状態変化がないので）それ以外の場合は、ユーザーのサーバーは、スタンザを提供すべきではないサブスクリプションの状態を変更してはなりません。これらのルールは、以下の表にまとめられています。
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" |
+------------------------------------------------------------------+
Appendix B. Blocking Communication
付録B.通信遮断
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]で指定されています。
Appendix C. vCards
付録C. vCardを
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仕様のXML表現[VCARD】このような情報を提供するために、XMPPコミュニティ内で一般的に使用しているが、（このプロトコルのドキュメントを[XEP-0054]に含まれる）は、この仕様の範囲外です。
Appendix D. XML Schema for jabber:iq:roster
IQ：名簿ジャバー付録D. XMLスキーマ
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]に準拠し、この文書で使用された名前空間以下のスキーマは、正式には「：IQ名簿ジャバー」を定義します。 XMLストリームとスタンザの検証がオプションであるので、このスキーマは規範的ではなく、説明の目的でのみ提供されています。コアXMPP名前空間を定義するスキーマは、[XMPP-CORE]を指します。
<?xml version='1.0' encoding='UTF-8'?>
<？xmlのバージョン= '1.0' エンコーディング= 'UTF-8'？>
<xs:schema xmlns:xs='http://www.w3.org/2001/XMLSchema' targetNamespace='jabber:iq:roster' xmlns='jabber:iq:roster' elementFormDefault='qualified'>
<XS：スキーマのxmlns：XSの= 'のhttp：//www.w3.org/2001/XMLSchema' のtargetNamespace = 'ジャバー：IQ：名簿' のxmlns = 'ジャバー：IQ：名簿' のelementFormDefault = '資格'>
<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：要素名= 'クエリ'> <XS：complexTypeの> <XS：配列> <XS：要素REF = 'アイテム' のminOccurs = '0' のmaxOccurs = '無限' /> </ XS：配列> <XS：タイプ= 'のverの' name =属性 'のxs：文字列' 使用= 'オプション' /> </ XS：complexTypeの> </ XS：要素>
<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：要素名= 'アイテム'> <XS：complexTypeの> <XS：配列> <XS：要素REF = 'グループ' のminOccurs = '0' のmaxOccurs = '無限' /> </ XS：配列> <XS：使用= 'オプション' /> <XS：属性名を= '尋ねる' = 'オプション'> <XSを使用します：名前は=タイプ= 'ブール値をXS' を '承認済み' 属性のsimpleType> <XS：制限ベース= 'のxs：NMTOKENを'> <XS：列挙値=' 購読 '/> </ XS：制限> </ XS：単純> </ XS：属性> <XS：属性名=' JID 'タイプ= 'のxs：文字列' 使用='必要な '/> <XS：属性名=' name」をタイプ= 'XS：文字列' 使用= 'オプション' /> <XS：属性名= 'サブスクリプション' 使用= 'オプションの' デフォルト= 'なし'> <XS：単純> <XS：制限基地= 'のxs：NMTOKEN'> <XS：列挙値= '両方' /> <XS：/> <XS 'から' 列挙値=列挙値= 'なし' /> <XS：列挙値= '削除' /> <XS：列挙値= 'と' /> </ XS：制限> </ XS：単純> </ XS：属性> </ XS：complexTypeの> </ XS：要素>
<xs:element name='group' type='xs:string'/>
<XS：要素名= 'グループ' タイプ= 'XS：文字列' />
</xs:schema>
</ XS：スキーマ>
Appendix E. Differences From
から付録E.の違い
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で定義されたコンテンツを除去しました。ただし、下位互換性サーバーの実装のためにセッション確立が「NO-OP」ではないにも関わらず、機能をサポートすることを通知することをお勧めします。
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.
それは裸のJID、ない完全なJIDとなるように、Oプレゼンスプローブのために「から」アドレスを変更しました。
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).
（事前に承認されたサブスクリプション）「true」または「false」に設定することができ、新たな「承認」属性を含むOタイプの存在スタンザを経由して事前承認プレゼンスサブスクリプションのオプションのサーバーのサポートが追加されました「サブスクライブ」、（デフォルト）。
o Added optional 'parent' attribute to <thread/> element.
O <スレッド/>要素に、オプションの「親」属性が追加されました。
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バックそれが元々採取された[XEP-0016に（RFC 3921のセクション10で指定される）ブロッキング通信のためのプロトコルを動かし。
o Recommended returning presence unavailable in response to probes.
Oプローブに応じて利用できない存在感を返す推奨。
o Clarified handling of presence probes sent to full JIDs.
Oフル子供たちに送られたプレゼンスプローブの取り扱いを明確化。
o Explicitly specified that the default value for the presence <priority/> element is zero.
O明示的プレゼンスのためのデフォルト値は<優先/>要素がゼロであることを指定しました。
o Removed recommendation to support the "_im" and "_pres" SRV records.
O「_im」と「_pres」SRVレコードをサポートするための勧告を削除しました。
Appendix F. Acknowledgements
付録F.謝辞
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.この文書は、そこに認め貢献者やコメンテーターの仕事なしには不可能だったでしょう。
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.
文書エディタは、すべてのそのようなフィードバックに対処するために努めてきましたが、何百人もの人々がRFC 3921.の出版以来、実装のフィードバック、バグレポート、明確化のための要求、および改善のための提案を提供している、彼は残りのエラーや曖昧さのために責任を負うものとします。
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.
特別な感謝はケビン・スミス、マシュー・ワイルド、デイブCridland、Waqasフセイン、フィリップHancke、フロリアン・ツァイツ、ジョナス・リンドバーグ、ジェハンページ、トーリー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
ピーターサンアンドレのCisco 1899 Wyknoopストリート、スイート600デンバー、CO 80202 USA
Phone: +1-303-308-3282 EMail: psaintan@cisco.com
電話：+ 1-303-308-3282 Eメール：psaintan@cisco.com