RFC 3921 - Extensible Messaging and Presence Protocol (XMPP): Instant Messaging and Presence 日本語訳

URL : https://tools.ietf.org/html/rfc3921
タイトル : RFC 3921 - 拡張可能なメッセージングおよびプレゼンスプロトコル（XMPP）：インスタントメッセージングとプレゼンス
翻訳編集 : 自動生成

Network Working Group                                P. Saint-Andre, Ed.
Request for Comments: 3921                    Jabber Software Foundation
Category: Standards Track                                   October 2004

          Extensible Messaging and Presence Protocol (XMPP):
                     Instant Messaging and Presence

Status of this Memo

このメモの位置付け

This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.

この文書は、インターネットコミュニティのためのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。

著作権表示

著作権（C）インターネット協会（2004）。

Abstract

抽象

This memo describes extensions to and applications of the core features of the Extensible Messaging and Presence Protocol (XMPP) that provide the basic instant messaging (IM) and presence functionality defined in RFC 2779.

このメモはへの拡張およびRFC 2779で定義された基本的なインスタントメッセージング（IM）とプレゼンス機能を提供する拡張可能なメッセージングおよびプレゼンスプロトコル（XMPP）のコア機能のアプリケーションについて説明します。

Table of Contents

   1.   Introduction . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.   Syntax of XML Stanzas  . . . . . . . . . . . . . . . . . . .   4
   3.   Session Establishment  . . . . . . . . . . . . . . . . . . .  10
   4.   Exchanging Messages  . . . . . . . . . . . . . . . . . . . .  13
   5.   Exchanging Presence Information  . . . . . . . . . . . . . .  16
   6.   Managing Subscriptions . . . . . . . . . . . . . . . . . . .  26
   7.   Roster Management  . . . . . . . . . . . . . . . . . . . . .  27
   8.   Integration of Roster Items and Presence Subscriptions . . .  32
   9.   Subscription States  . . . . . . . . . . . . . . . . . . . .  56
   10.  Blocking Communication . . . . . . . . . . . . . . . . . . .  62
   11.  Server Rules for Handling XML Stanzas  . . . . . . . . . . .  85
   12.  IM and Presence Compliance Requirements  . . . . . . . . . .  88
   13.  Internationalization Considerations  . . . . . . . . . . . .  89
   14.  Security Considerations  . . . . . . . . . . . . . . . . . .  89
   15.  IANA Considerations  . . . . . . . . . . . . . . . . . . . .  90
   16.  References . . . . . . . . . . . . . . . . . . . . . . . . .  91
   A.   vCards . . . . . . . . . . . . . . . . . . . . . . . . . . .  93
   B.   XML Schemas. . . . . . . . . . . . . . . . . . . . . . . . .  93
   C.   Differences Between Jabber IM/Presence Protocols and XMPP. . 105
   Contributors . . . . . . . . . . . . . . . . . . . . . . . . . .  106
   Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . .  106
   Author's Address. . . . . . . . . . . . . . . . . . . . . . . . . 106
   Full Copyright Statement. . . . . . . . . . . . . . . . . . . . . 107

1. Introduction

1. はじめに

1.1. Overview

1.1. 概要

The Extensible Messaging and Presence Protocol (XMPP) is a protocol for streaming XML [XML] elements in order to exchange messages and presence information in close to real time. The core features of XMPP are defined in Extensible Messaging and Presence Protocol (XMPP): Core [XMPP-CORE]. These features -- mainly XML streams, use of TLS and SASL, and the <message/>, <presence/>, and <iq/> children of the stream root -- provide the building blocks for many types of near-real-time applications, which may be layered on top of the core by sending application-specific data qualified by particular XML namespaces [XML-NAMES]. This memo describes extensions to and applications of the core features of XMPP that provide the basic functionality expected of an instant messaging (IM) and presence application as defined in RFC 2779 [IMP-REQS].

拡張メッセージングおよびプレゼンスプロトコル（XMPP）は、リアルタイムに近い内のメッセージ及びプレゼンス情報を交換するためにXML [XML]の要素をストリーミングするためのプロトコルです。コア[XMPP-CORE]：XMPPのコア機能は、拡張メッセージングおよびプレゼンスプロトコル（XMPP）で定義されています。これらの機能 - 主にXMLストリーム、TLSおよびSASLの使用、およびストリームのルートの<メッセージ/>、<存在/>、および<IQ />子供 - ニア実、多くの種類のためのビルディングブロックを提供特定のXML名前空間[XML-NAMES]で修飾アプリケーション固有のデータを送信することにより、コアの上に積層してもよい時間アプリケーション。このメモは[IMP-REQS]およびRFC 2779で定義されるように、インスタントメッセージング（IM）とプレゼンス・アプリケーションに期待される基本的な機能を提供するXMPPのコア機能のアプリケーションの拡張を記述しています。

1.2. Requirements

1.2. 必要条件

For the purposes of this memo, the requirements of a basic instant messaging and presence application are defined by [IMP-REQS], which at a high level stipulates that a user must be able to complete the following use cases:

このメモの目的のために、基本的なインスタントメッセージングとプレゼンスアプリケーションの要件は、高いレベルのユーザは、次のユースケースを完了することができなければならないことを規定[IMP-REQS]によって定義されます。

o Exchange messages with other users o Exchange presence information with other users o Manage subscriptions to and from other users o Manage items in a contact list (in XMPP this is called a "roster") o Block communications to or from specific other users

O、他のユーザーとの交流のプレゼンス情報O、他のユーザーとの交流のメッセージは、Oまたは特定の他のユーザからのブロック通信O（XMPPでは、これは「名簿」と呼ばれる）連絡先リスト内の項目を管理O、他のユーザへ及びからのサブスクリプションを管理します

Detailed definitions of these functionality areas are contained in [IMP-REQS], and the interested reader is directed to that document regarding the requirements addressed herein.

これらの機能性領域の詳細な定義は[IMP-REQS]に含まれており、興味のある読者は、本明細書に対処要件に関してその文書を対象とします。

[IMP-REQS] also stipulates that presence services must be separable from instant messaging services; i.e., it must be possible to use the protocol to provide a presence service, an instant messaging service, or both. Although the text of this memo assumes that implementations and deployments will want to offer a unified instant messaging and presence service, there is no requirement that a service must offer both a presence service and an instant messaging service, and the protocol makes it possible to offer separate and distinct services for presence and for instant messaging.

[IMP-REQS]もプレゼンスサービスはインスタントメッセージングサービスから分離しなければならないことを規定しています。すなわち、プレゼンスサービス、インスタントメッセージングサービス、またはその両方を提供するプロトコルを使用することが可能でなければなりません。このメモのテキストは実装と展開が統一されたインスタントメッセージングとプレゼンスサービスを提供したいということを前提としていますが、サービスは、プレゼンスサービスやインスタントメッセージングサービス、およびプロトコルの両方を提供しなければならないという要件を提供することが可能になりませんがありますプレゼンス用およびインスタントメッセージングのための独立した別個のサービスを提供しています。

Note: While XMPP-based instant messaging and presence meets the requirements of [IMP-REQS], it was not designed explicitly with that specification in mind, since the base protocol evolved through an open development process within the Jabber open-source community before RFC 2779 was written. Note also that although protocols addressing many other functionality areas have been defined in the Jabber community, such protocols are not included in this memo because they are not required by [IMP-REQS].

注：XMPPベースのインスタントメッセージングとプレゼンスを[IMP-REQS]の要件を満たしながら、ベースプロトコルはRFC前Jabberのオープンソース・コミュニティ内のオープンな開発プロセスを通じて進化するので、それは、念頭に置いて、その仕様に明示的に設計されていません2779年には書かれていました。他の多くの機能分野に取り組むプロトコルはJabberのコミュニティで定義されているが、それらは[IMP-REQS]によって必要とされていないので、そのようなプロトコルはこのメモに含まれていないことにも注意してください。

1.3. Terminology

1.3. 用語

This memo inherits the terminology defined in [XMPP-CORE].

このメモは[XMPP-CORE]で定義された用語を継承します。

The capitalized key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, RFC 2119 [TERMS].

この文書に記載されている大文字のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "オプション" BCP 14、RFC 2119 [用語]で説明されるように解釈されるべきです。

2. Syntax of XML Stanzas

XMLスタンザの2構文

The basic semantics and common attributes of XML stanzas qualified by the 'jabber:client' and 'jabber:server' namespaces are defined in [XMPP-CORE]. However, these namespaces also define various child elements, as well as values for the common 'type' attribute, that are specific to instant messaging and presence applications. Thus, before addressing particular "use cases" for such applications, we here further describe the syntax of XML stanzas, thereby supplementing the discussion in [XMPP-CORE].

基本的な意味とによって修飾されたXMLスタンザの一般的な属性のおしゃべり：クライアント 'と'おしゃべり：サーバの名前空間は[XMPP-CORE]で定義されています。しかし、これらの名前空間は、様々な子要素だけでなく、インスタントメッセージングとプレゼンスアプリケーションに固有である共通の「タイプ」属性の値を定義します。したがって、このようなアプリケーションのための特定の「ユースケース」を対処する前に、我々はここで、さらにそれによって、[XMPP-CORE]で議論を補完する、XMLスタンザの構文を説明します。

2.1. Message Syntax

2.1. メッセージの構文

Message stanzas qualified by the 'jabber:client' or 'jabber:server' namespace are used to "push" information to another entity. Common uses in instant messaging applications include single messages, messages sent in the context of a chat conversation, messages sent in the context of a multi-user chat room, headlines and other alerts, and errors.

メッセージがで修飾スタンザ「おしゃべり：クライアント」または 'おしゃべり：サーバの名前空間は別のエンティティに情報を「プッシュ」するために使用されています。インスタントメッセージングアプリケーションでの一般的な用途は、単一のメッセージ、チャットの会話のコンテキストで送信されたメッセージ、マルチユーザチャットルームのコンテキストで送信されたメッセージ、見出しや他の警告、およびエラーが含まれます。

2.1.1. Types of Message

2.1.1. メッセージの種類

The 'type' attribute of a message stanza is RECOMMENDED; if included, it specifies the conversational context of the message, thus providing a hint regarding presentation (e.g., in a GUI). If included, the 'type' attribute MUST have one of the following values:

メッセージスタンザの「タイプ」属性が推奨されます。含まれている場合、それは、このように（例えば、GUIで）プレゼンテーションに関するヒントを提供し、メッセージの会話のコンテキストを指定します。含まれている場合は、「タイプ」属性には、次のいずれかの値を持っている必要があります。

o chat -- The message is sent in the context of a one-to-one chat conversation. A compliant client SHOULD present the message in an interface enabling one-to-one chat between the two parties, including an appropriate conversation history.

Oチャット - メッセージが一対一チャットの会話のコンテキストで送信されます。準拠のクライアントは、適切な会話履歴などの二者間の1対1のチャットを可能にするインタフェースでメッセージを提示しなければなりません。

o error -- An error has occurred related to a previous message sent by the sender (for details regarding stanza error syntax, refer to [XMPP-CORE]). A compliant client SHOULD present an appropriate interface informing the sender of the nature of the error.

Oエラー - エラー（[XMPP-CORE]を参照して、スタンザエラー構文に関する詳細については）送信者によって送信された以前のメッセージに関連し発生しました。準拠のクライアントは、エラーの性質を送信者に知らせる適切なインタフェースを提示しなければなりません。

o groupchat -- The message is sent in the context of a multi-user chat environment (similar to that of [IRC]). A compliant client SHOULD present the message in an interface enabling many-to-many chat between the parties, including a roster of parties in the chatroom and an appropriate conversation history. Full definition of XMPP-based groupchat protocols is out of scope for this memo.

Oグループチャット - メッセージ（[IRC]と同様）、マルチユーザチャット環境のコンテキスト内で送信されます。準拠のクライアントは、チャットルームでの政党の名簿と適切な会話履歴を含め、当事者間で多対多のチャットを可能にするインターフェースでメッセージを提示しなければなりません。 XMPPベースのグループチャットプロトコルの完全な定義は、このメモの範囲外です。

o headline -- The message is probably generated by an automated service that delivers or broadcasts content (news, sports, market information, RSS feeds, etc.). No reply to the message is expected, and a compliant client SHOULD present the message in an interface that appropriately differentiates the message from standalone messages, chat sessions, or groupchat sessions (e.g., by not providing the recipient with the ability to reply).

O見出し - メッセージは、おそらく提供または放送コンテンツ（ニュース、スポーツ、市場情報は、RSSフィードなど）自動化されたサービスによって生成されます。メッセージに対する返事が期待されず、準拠クライアントが適切スタンドアロンメッセージ、チャットセッション、又はグループチャットセッション（例えば、返信する能力を受信者を提供しないことによって）からのメッセージを区別インタフェースにメッセージを提示しなければなりません。

o normal -- The message is a single message that is sent outside the context of a one-to-one conversation or groupchat, and to which it is expected that the recipient will reply. A compliant client SHOULD present the message in an interface enabling the recipient to reply, but without a conversation history.

O正常 - メッセージは、1対1の会話又はグループチャットのコンテキスト外で送信される単一のメッセージであり、そして受信者が返信することが期待されました。準拠のクライアントはなく、会話履歴なし、返信する受信者を有効にするインターフェイスにメッセージを提示しなければなりません。

An IM application SHOULD support all of the foregoing message types; if an application receives a message with no 'type' attribute or the application does not understand the value of the 'type' attribute provided, it MUST consider the message to be of type "normal" (i.e., "normal" is the default). The "error" type MUST be generated only in response to an error related to a message received from another entity.

IMアプリケーションは、上記のメッセージタイプの全てを支持します。アプリケーションが受信した場合なし「タイプ」属性やアプリケーションとのメッセージが提供する「タイプ」属性の値を理解していない、それが「通常」のメッセージがタイプであることを考慮しなければならない（すなわち、「通常は」デフォルトです）。「エラー」型は、他のエンティティから受信したメッセージに関連したエラーに応答して生成されなければなりません。

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').

「タイプ」属性はオプションですが、メッセージへの応答でタイプをミラーリングする礼儀正しいと考えられています。さらに、いくつかの特殊な用途（例えば、マルチユーザチャットサービス）は、その裁量で、特定のメッセージ・タイプ（例えば、タイプ=「グループチャット」）の使用を強制するかもしれません。

2.1.2. Child Elements

2.1.2. 子要素

As described under extended namespaces (Section 2.4), a message stanza MAY contain any properly-namespaced child element.

拡張名前空間（2.4節）の下で説明したように、メッセージスタンザは、任意の適切に名前空間の子要素を含むかもしれません。

In accordance with the default namespace declaration, by default a message stanza is qualified by the 'jabber:client' or 'jabber:server' namespace, which defines certain allowable children of message stanzas. If the message stanza is of type "error", it MUST include an <error/> child; for details, see [XMPP-CORE]. Otherwise, the message stanza MAY contain any of the following child elements without an explicit namespace declaration:

「：クライアントおしゃべり」または 'おしゃべり：サーバのメッセージ・スタンザのある許容子どもを定義し、名前空間、デフォルトの名前空間宣言に従い、デフォルトではメッセージスタンザがで修飾されます。メッセージスタンザがタイプ「エラー」である場合、それは<誤り/>子供を含まなければなりません。詳細については、[XMPP-CORE]を参照してください。それ以外の場合は、メッセージスタンザは、明示的な名前空間宣言せずに次の子要素のいずれかが含まれる場合があります。

1. <subject/> 2. <body/> 3. <thread/>

1. <被験者/> 2 <BODY /> 3. <スレッド/>

2.1.2.1. Subject

2.1.2.1。主題

The <subject/> element contains human-readable XML character data that specifies the topic of the message. The <subject/> element MUST NOT possess any attributes, with the exception of the 'xml:lang' attribute. Multiple instances of the <subject/> element MAY be included for the purpose of providing alternate versions of the same subject, but only if each instance possesses an 'xml:lang' attribute with a distinct language value. The <subject/> element MUST NOT contain mixed content (as defined in Section 3.2.2 of [XML]).

<対象/>要素は、メッセージのトピックを指定し、人間が読めるXMLの文字データが含まれています。属性：<件名/>要素は、「LANGのxml」を除いて、すべての属性を持ってはなりません。異なる言語の値を持つ属性：<件名/>要素の複数のインスタンスがなく、各インスタンスは、「LANG XML」を有している場合にのみ、同一の被写体の代替バージョンを提供する目的のために含まれるかもしれません。（[XML]のセクション3.2.2で定義されるように）<被験者/>要素は、混合コンテンツを含んではなりません。

2.1.2.2. Body

2.1.2.2。体

The <body/> element contains human-readable XML character data that specifies the textual contents of the message; this child element is normally included but is OPTIONAL. The <body/> element MUST NOT possess any attributes, with the exception of the 'xml:lang' attribute. Multiple instances of the <body/> element MAY be included but only if each instance possesses an 'xml:lang' attribute with a distinct language value. The <body/> element MUST NOT contain mixed content (as defined in Section 3.2.2 of [XML]).

<ボディ/>要素は、メッセージのテキストの内容を指定し、人間が読み取り可能なXML文字データが含まれています。この子要素は、通常は含まれるがオプションです。属性：<ボディ/>要素は、「LANGのxml」を除いて、すべての属性を持ってはなりません。異なる言語の値を持つ属性：<BODY />要素の複数のインスタンスがなく、各インスタンスは、「LANG XML」を有している場合にのみ含まれるかもしれません。（[XML]のセクション3.2.2で定義されるように）<BODY />要素は、混合コンテンツを含んではなりません。

2.1.2.3. Thread

2.1.2.3。糸

The <thread/> element contains non-human-readable XML character data specifying an identifier that is used for tracking a conversation thread (sometimes referred to as an "instant messaging session") between two entities. The value of the <thread/> element is generated by the sender and SHOULD be copied back in any replies. If used, it MUST be unique to that conversation thread within the stream and MUST be consistent throughout that conversation (a client that receives a message from the same full JID but with a different thread ID MUST assume that the message in question exists outside the context of the existing conversation thread). The use of the <thread/> element is OPTIONAL and is not used to identify individual messages, only conversations. A message stanza MUST NOT contain more than one <thread/> element. The <thread/> element MUST NOT possess any attributes. The value of the <thread/> element MUST be treated as opaque by entities; no semantic meaning may be derived from it, and only exact comparisons may be made against it. The <thread/> element MUST NOT contain mixed content (as defined in Section 3.2.2 of [XML]).

<スレッド/>要素は、会話スレッドを追跡するために使用される識別子を指定する非ヒトが読み取り可能なXML文字データが含まれている2つのエンティティ間の（時には「インスタントメッセージングセッション」と呼びます）。 <スレッド/>要素の値は送信者によって生成され、バック任意の応答にコピーする必要があります。使用している場合、それは、ストリーム内のその会話のスレッドに一意である必要があり、その会話を通して一貫していなければならない（同じフルJIDからではなく、別のスレッドのIDとメッセージを受け取るクライアントは、問題のメッセージがコンテキストの外に存在すると仮定しなければなりません既存の会話スレッドの）。 <スレッド/>要素の使用は任意であり、個々のメッセージのみの会話を識別するために使用されていません。メッセージスタンザは、複数の<スレッド/>要素を含めることはできません。 <スレッド/>要素は、任意の属性を持ってはなりません。 <スレッド/>要素の値は、エンティティによって不透明なものとして扱われなければなりません。何の意味論的な意味は、それに由来しないかもしれない、そして唯一の正確な比較がそれに対して行うことができます。（[XML]のセクション3.2.2で定義されるように）<スレッド/>要素は、混合コンテンツを含んではなりません。

2.2. Presence Syntax

2.2. プレゼンス構文

Presence stanzas are used qualified by the 'jabber:client' or 'jabber:server' namespace to express an entity's current network availability (offline or online, along with various sub-states of the latter and optional user-defined descriptive text), and to notify other entities of that availability. Presence stanzas are also used to negotiate and manage subscriptions to the presence of other entities.

「：クライアントおしゃべり」または 'おしゃべり：サーバのプレゼンススタンザはによって修飾使用されている（の様々なサブ状態とともに、オフラインまたはオンライン後者とオプションのユーザー定義の説明テキスト）エンティティの現在のネットワークの可用性を表現するために、名前空間、およびその可用性の他のエンティティに通知します。プレゼンススタンザは、他のエンティティの存在のためにサブスクリプションを交渉し、管理するために使用されています。

2.2.1. Types of Presence

2.2.1. プレゼンスの種類

The 'type' attribute of a presence stanza is OPTIONAL. A presence stanza that does not possess a 'type' attribute is used to signal to the server that the sender is online and available for communication. If included, the 'type' attribute specifies a lack of availability, a request to manage a subscription to another entity's presence, a request for another entity's current presence, or an error related to a previously-sent presence stanza. If included, the 'type' attribute MUST have one of the following values:

プレゼンススタンザの「タイプ」属性はオプションです。「タイプ」属性を持たない存在スタンザは、送信者が通信のためにオンラインで使用可能なサーバに知らせるために使用されます。含まれている場合は、「タイプ」属性は、可用性の欠如、別のエンティティの存在にサブスクリプションを管理するための要求、別のエンティティの現在のプレゼンスの要求、または以前に送信されたプレゼンススタンザに関連するエラーを指定します。含まれている場合は、「タイプ」属性には、次のいずれかの値を持っている必要があります。

o unavailable -- Signals that the entity is no longer available for communication.

使用不能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 unsubscribe -- The sender is unsubscribing from another entity's presence.

退会O - 送信者が別のエンティティの存在から脱退されます。

o unsubscribed -- The subscription request has been denied or a previously-granted subscription has been cancelled.

O解除 - サブスクリプション要求が拒否されているか、以前に付与されたサブスクリプションがキャンセルされました。

o probe -- A request for an entity's current presence; SHOULD be generated only by a server on behalf of a user.

Oプローブ - エンティティの現在のプレゼンスを要求。唯一のユーザーの代わりにサーバーによって生成されるべきです。

o error -- An error has occurred regarding processing or delivery of a previously-sent presence stanza.

Oエラー - エラーを処理または送信済みプレゼンススタンザの送達について発生しました。

For detailed information regarding presence semantics and the subscription model used in the context of XMPP-based instant messaging and presence applications, refer to Exchanging Presence Information (Section 5) and Managing Subscriptions (Section 6).

プレゼンスのセマンティクスとXMPPベースのインスタントメッセージングとプレゼンスアプリケーションのコンテキストで使用されるサブスクリプションモデルに関する詳細な情報については、プレゼンス情報（第5節）とサブスクリプションの管理（第6節）の交換を参照してください。

2.2.2. Child Elements

2.2.2. 子要素

As described under extended namespaces (Section 2.4), a presence stanza MAY contain any properly-namespaced child element.

拡張名前空間（2.4節）の下で説明したように、プレゼンススタンザは、任意の適切に名前空間の子要素を含むかもしれません。

In accordance with the default namespace declaration, by default a presence stanza is qualified by the 'jabber:client' or 'jabber:server' namespace, which defines certain allowable children of presence stanzas. If the presence stanza is of type "error", it MUST include an <error/> child; for details, see [XMPP-CORE]. If the presence stanza possesses no 'type' attribute, it MAY contain any of the following child elements (note that the <status/> child MAY be sent in a presence stanza of type "unavailable" or, for historical reasons, "subscribe"):

「：クライアントおしゃべり」または 'おしゃべり：サーバのプレゼンススタンザのある許容子どもを定義し、名前空間、デフォルトの名前空間宣言に従い、デフォルトでは存在スタンザがで修飾されます。プレゼンススタンザがタイプ「エラー」である場合、それは<誤り/>子供を含まなければなりません。詳細については、[XMPP-CORE]を参照してください。プレゼンススタンザはNO「type」属性を持っていない場合は、<状態/>子供が「利用できない」や、歴史的な理由のためにタイプの存在スタンザで送信することができる、「購読する」ことに注意してください（次の子要素のいずれかを含むかもしれ）：

1. <show/> 2. <status/> 3. <priority/>

1. <ショー/> 2. <状態/> 3. <優先/>

2.2.2.1. Show

2.2.2.1。公演

The OPTIONAL <show/> element contains non-human-readable XML character data that specifies the particular availability status of an entity or specific resource. A presence stanza MUST NOT contain more than one <show/> element. The <show/> element MUST NOT possess any attributes. If provided, the XML character data value MUST be one of the following (additional availability types could be defined through a properly-namespaced child element of the presence stanza):

オプションの<ショー/>要素は、エンティティの特定の可用性ステータスまたは特定のリソースを指定する非人間が読める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.

何の<ショー/>要素が提供されない場合は、エンティティがオンラインで使用可能であると仮定されます。

2.2.2.2. Status

2.2.2.2。状態

The OPTIONAL <status/> element contains XML character data specifying a natural-language description of availability status. It is normally used in conjunction with the show element to provide a detailed description of an availability state (e.g., "In a meeting"). The <status/> element MUST NOT possess any attributes, with the exception of the 'xml:lang' attribute. Multiple instances of the <status/> element MAY be included but only if each instance possesses an 'xml:lang' attribute with a distinct language value.

オプションの<状態/>要素は、可用性ステータスの自然言語記述を指定するXML文字データが含まれています。通常（例えば、「会議中」）可用性状態の詳細な説明を提供するために、表示要素に関連して使用されます。属性：<状態/>要素は、「LANGのxml」を除いて、すべての属性を持ってはなりません。 <状態/>要素の複数のインスタンスが含まれていてもよいが、各インスタンスは「XML：langの」所有する場合にのみ異なる言語の値を持つ属性を。

2.2.2.3. Priority

2.2.2.3。優先

The OPTIONAL <priority/> element contains non-human-readable XML character data that specifies the priority level of the resource. The value MUST be an integer between -128 and +127. A presence stanza MUST NOT contain more than one <priority/> element. The <priority/> element MUST NOT possess any attributes. If no priority is provided, a server SHOULD consider the priority to be zero. For information regarding the semantics of priority values in stanza routing within instant messaging and presence applications, refer to Server Rules for Handling XML Stanzas (Section 11).

オプションの<優先/>要素は、リソースの優先順位を指定する非人間が読めるXMLの文字データが含まれています。値は-128と+127の間の整数でなければなりません。プレゼンススタンザは、複数の<優先/>要素を含めることはできません。 <優先/>要素は、任意の属性を持ってはなりません。何の優先順位が提供されていない場合、サーバは優先度がゼロであることを考慮すべきです。インスタントメッセージングとプレゼンスアプリケーション内のスタンザルーティングに優先度の値の意味論に関する情報については、XMLスタンザ（セクション11）を取り扱うためにサーバーのルールを参照してください。

2.3. IQ Syntax

2.3. IQ構文

IQ stanzas provide a structured request-response mechanism. The basic semantics of that mechanism (e.g., that the 'id' attribute is REQUIRED) are defined in [XMPP-CORE], whereas the specific semantics required to complete particular use cases are defined in all cases by an extended namespace (Section 2.4) (note that the 'jabber:client' and 'jabber:server' namespaces do not define any children of IQ stanzas other than the common <error/>). This memo defines two such extended namespaces, one for Roster Management (Section 7) and the other for Blocking Communication (Section 10); however, an IQ stanza MAY contain structured information qualified by any extended namespace.

IQスタンザは、構造化された要求応答メカニズムを提供します。その機構固有のセマンティクスが拡張された名前空間によって、全ての場合に定義されている特定のユースケースを完了するために必要なのに対し（例えば、「ID」属性が必要であること）、[XMPP-CORE]で定義される（セクション2.4）の基本的な意味論（ 'おしゃべり：クライアントのことに注意してくださいと'おしゃべり：サーバの名前空間はIQの子を定義していないことは共通<エラー/>以外のスタンザ）。このメモは、二つのそのような拡張された名前空間、選手管理（セクション7）のための1つの通信（セクション10）をブロックするための他の定義します。ただし、IQスタンザは、すべての拡張名前空間で修飾構造化された情報を含むかもしれません。

2.4. Extended Namespaces

2.4. 拡張名前空間

While the three XML stanza kinds defined in the "jabber:client" or "jabber:server" namespace (along with their attributes and child elements) provide a basic level of functionality for messaging and presence, XMPP uses XML namespaces to extend the stanzas for the purpose of providing additional functionality. Thus a message or presence stanza MAY contain one or more optional child elements specifying content that extends the meaning of the message (e.g., an XHTML-formatted version of the message body), and an IQ stanza MAY contain one such child element. This child element MAY have any name and MUST possess an 'xmlns' namespace declaration (other than "jabber:client", "jabber:server", or "http://etherx.jabber.org/streams") that defines all data contained within the child element.

または「ジャバー：サーバー」：「クライアントジャバー」で定義された3つのXMLスタンザの種類ものの（その属性と子要素と一緒に）名前空間は、メッセージングとプレゼンスのための機能の基本的なレベルを提供し、XMPPはのためのスタンザを拡張するためにXML名前空間を使用しています追加機能を提供する目的。したがって、メッセージまたは存在スタンザ（例えば、メッセージ本文のXHTMLフォーマットのバージョン）、およびIQスタンザは、1つのそのような子の元素を含んでいてもよいメッセージの意味を拡張するコンテンツを指定する1つ以上の任意の子要素を含んでいてもよいです。すべてのデータを定義する（または「http://etherx.jabber.org/streams」、：「サーバージャバー」以外の「ジャバークライアント」、）この子要素は、任意の名前を持っているかもしれませんと「のxmlns」名前空間宣言を持っていなければなりません子要素内に含まれます。

Support for any given extended namespace is OPTIONAL on the part of any implementation (aside from the extended namespaces defined herein). If an entity does not understand such a namespace, the entity's expected behavior depends on whether the entity is (1) the recipient or (2) an entity that is routing the stanza to the recipient:

任意の所与の拡張ネームスペースのサポートは、（脇本明細書で定義される拡張された名前空間からの）任意の実装の一部に任意です。エンティティは、そのような名前空間を理解していない場合は、エンティティの期待される動作は、企業は（1）受信者または受信者にスタンザをルーティングしている（2）実体であるかどうかによって異なります。

Recipient: If a recipient receives a stanza that contains a child element it does not understand, it SHOULD ignore that specific XML data, i.e., it SHOULD not process it or present it to a user or associated application (if any). In particular:

受信者：受信者がそれを理解していない子要素が含まれているスタンザを受信した場合、それは特定のXMLデータは、すなわち、それはそれを処理しないことを無視するか、ユーザーまたは関連するアプリケーション（もしあれば）にそれを提示しなければなりません。特に：

* If an entity receives a message or presence stanza that contains XML data qualified by a namespace it does not understand, the portion of the stanza that is in the unknown namespace SHOULD be ignored.

エンティティが、それは理解していない名前空間で修飾されたXMLデータを含むメッセージやプレゼンススタンザを受信した場合*、未知の名前空間にあるスタンザの部分が無視されるべきです。

* If an entity receives a message stanza whose only child element is qualified by a namespace it does not understand, it MUST ignore the entire stanza.

*エンティティは、その唯一の子要素、それは理解していない名前空間で修飾されたメッセージスタンザを受信した場合、それは全体のスタンザを無視しなければなりません。

* If an entity receives an IQ stanza of type "get" or "set" containing a child element qualified by a namespace it does not understand, the entity SHOULD return an IQ stanza of type "error" with an error condition of <service-unavailable/>.

<service-のエラー条件付き*エンティティが「取得」か、それは理解していない名前空間で修飾子要素を含む「設定」タイプのIQスタンザを受信した場合、エンティティはタイプのIQスタンザを返すべき「エラー」使用できません/>。

Router: If a routing entity (usually a server) handles a stanza that contains a child element it does not understand, it SHOULD ignore the associated XML data by passing it on untouched to the recipient.

ルータ：ルーティングエンティティ（通常はサーバー）が、それは理解していない子要素が含まれているスタンザを扱う場合は、受信者にそのままでそれを渡すことによって、関連付けられたXMLデータを無視すべきです。

3. Session Establishment

3.セッションの確立

Most instant messaging and presence applications based on XMPP are implemented via a client-server architecture that requires a client to establish a session on a server in order to engage in the expected instant messaging and presence activities. However, there are several pre-conditions that MUST be met before a client can establish an instant messaging and presence session. These are:

XMPPに基づいて、ほとんどのインスタントメッセージングとプレゼンスのアプリケーションが期待されるインスタントメッセージングとプレゼンス活動に従事するためには、サーバー上のセッションを確立するためにクライアントを必要とするクライアント - サーバアーキテクチャを経由して実装されています。しかし、インスタントメッセージングとプレゼンスセッションを確立することができ、クライアントの前に満たさなければならないいくつかの前提条件があります。これらは：

1. Stream Authentication -- a client MUST complete stream authentication as documented in [XMPP-CORE] before attempting to establish a session or send any XML stanzas. 2. Resource Binding -- after completing stream authentication, a client MUST bind a resource to the stream so that the client's address is of the form <user@domain/resource>, after which the entity is now said to be a "connected resource" in the terminology of [XMPP-CORE].

1.ストリーム認証 - セッションを確立するか、任意のXMLスタンザを送信しようとする前に、[XMPP-CORE]で文書化されているようクライアントがストリームの認証を完了する必要があります。バインディング2.リソース - クライアントのアドレスがエンティティは、現在「接続リソースであると言われた後、フォーム<ユーザー@ドメイン/リソース>、であるように、ストリーム認証を完了した後、クライアントがストリームにリソースをバインドする必要があります「[XMPP-CORE]の用語です。

If a server supports sessions, it MUST include a <session/> element qualified by the 'urn:ietf:params:xml:ns:xmpp-session' namespace in the stream features it advertises to a client after the completion of stream authentication as defined in [XMPP-CORE]:

サーバーがセッションをサポートしている場合、それは「：IETF：のparams：XML：NS：URN、XMPPセッション」によって修飾<セッション/>要素を含まなければならない名前空間ストリーム機能では、それはのように、ストリーム認証が完了した後にクライアントにアドバタイズ[XMPP-CORE]で定義されます：

Server advertises session establishment feature to client:

サーバーは、クライアントにセッション確立の機能をアドバタイズします。

<stream:stream xmlns='jabber:client' xmlns:stream='http://etherx.jabber.org/streams' id='c2s_345' from='example.com' version='1.0'> <stream:features> <bind xmlns='urn:ietf:params:xml:ns:xmpp-bind'/> <session xmlns='urn:ietf:params:xml:ns:xmpp-session'/> </stream:features>

<ストリーム：ストリームのxmlns = 'おしゃべり：クライアントののxmlns：ストリーム= 'のhttp：//etherx.jabber.org/streams'= 'example.com' バージョンからのid = 'c2s_345'= '1.0'> <ストリーム：機能> <バインドのxmlns = '壷：IETF：のparams：XML：NS：XMPP-バインド' /> <セッションのxmlns = '壷：IETF：のparams：XML：NS：XMPPセッション' /> </ストリーム：特長>

Upon being so informed that session establishment is required (and after completing resource binding), the client MUST establish a session if it desires to engage in instant messaging and presence functionality; it completes this step by sending to the server an IQ stanza of type "set" containing an empty <session/> child element qualified by the 'urn:ietf:params:xml:ns:xmpp-session' namespace:

そのセッションの確立が必要であることを知らされ（とリソースの結合を完了した後に）されると、それはインスタントメッセージングとプレゼンス機能に従事することを希望する場合は、クライアントがセッションを確立する必要があります。「：IETF：のparams：XML：NS：XMPPセッション壷」名前空間には、によって修飾空の<セッション/>子要素を含むサーバーに「セット」タイプのIQスタンザを送信することにより、このステップを完了します。

Step 1: Client requests session with server:

ステップ1：クライアントがサーバーとのセッションを要求します。

<= 'example.com' TYPE = 'セット' のid = 'sess_1' にIQ> <セッションのxmlns = 'URN：IETF：paramsは：XML：NS：XMPPセッション' /> </ IQ>

Step 2: Server informs client that session has been created:

ステップ2：サーバーは、セッションが作成されたことをクライアントに通知：

<IQから= 'example.com' TYPE = '結果' のid = 'sess_1' />

Upon establishing a session, a connected resource (in the terminology of [XMPP-CORE]) is said to be an "active resource".

セッションを確立する際に、（[XMPP-CORE]の用語で）接続されたリソースは、「アクティブリソース」であると言われます。

Several error conditions are possible. For example, the server may encounter an internal condition that prevents it from creating the session, the username or authorization identity may lack permissions to create a session, or there may already be an active resource associated with a resource identifier of the same name.

いくつかのエラー条件が可能です。たとえば、サーバーがセッションを作成することを防止する内部状態が発生する可能性があり、ユーザ名または許可IDは、セッションを作成する権限が不足していること、またはすでに同じ名前のリソース識別子に関連付けられたアクティブなリソースがあるかもしれません。

If the server encounters an internal condition that prevents it from creating the session, it MUST return an error.

サーバーがセッションを作成することを防止する内部状態を検出した場合は、エラーを返さなければなりません。

Step 2 (alt): Server responds with error (internal server error):

ステップ2（ALT）：Serverはエラー（内部サーバーエラー）で応答します。

<IQから= 'example.com' TYPE = 'エラー' のid = 'sess_1'> <セッションのxmlns = 'URN：IETF：paramsは：XML：NS：XMPPセッション' /> <エラータイプ= 'ウェイト'> <サーバ内蔵のエラーのxmlns = '壷：IETF：のparams：XML：NS：XMPP-スタンザ' /> </エラー> </ IQ>

If the username or resource is not allowed to create a session, the server MUST return an error (e.g., forbidden).

ユーザ名またはリソースがセッションを作成するために許可されていない場合、サーバは（例えば、禁じられた）エラーを返さなければなりません。

Step 2 (alt): Server responds with error (username or resource not allowed to create session):

ステップ2（ALT）：サーバーはエラーで応答（ユーザ名またはリソースがセッションを作成することはできません）：

<= 'example.com' TYPE = 'エラー' のid = 'sess_1' からIQ> <セッションのxmlns = 'URN：IETF：paramsは：XML：NS：XMPPセッション' /> <エラーの種類= 'AUTH'> <禁断のxmlns = '壷：IETF：のparams：XML：NS：XMPP-スタンザ' /> </エラー> </ IQ>

If there is already an active resource of the same name, the server MUST either (1) terminate the active resource and allow the newly-requested session, or (2) disallow the newly-requested session and maintain the active resource. Which of these the server does is up to the implementation, although it is RECOMMENDED to implement case #1. In case #1, the server SHOULD send a <conflict/> stream error to the active resource, terminate the XML stream and underlying TCP connection for the active resource, and return a IQ stanza of type "result" (indicating success) to the newly-requested session. In case #2, the server SHOULD send a <conflict/> stanza error to the newly-requested session but maintain the XML stream for that connection so that the newly-requested session has an opportunity to negotiate a non-conflicting resource identifier before sending another request for session establishment.

すでに同じ名前のアクティブなリソースがある場合、サーバは、（1）アクティブなリソースを終了し、新たに要求されたセッションを許可する、または（2）新たに要求されたセッションを禁止し、アクティブなリソースを維持しなければなりません。これらのケース＃1を実装するためにお勧めしますが、サーバーは、実装次第ですありません。ケース＃1において、サーバは、アクティブなリソースに<コンフリクト/>ストリームエラーを送信するXMLストリームとアクティブなリソースの基礎となるTCP接続を終了し、に（成功を示す）タイプ「結果」のIQスタンザを返すべき新たに要求されたセッション。ケース＃2では、サーバは、新たに要求されたセッションに<紛争/>スタンザ誤りを送るべきであるが、新たに要求されたセッションは、送信する前に競合しないリソース識別子を交渉する機会を持つように、その接続のためのXMLストリームを維持しますセッション確立のための別の要求。

Step 2 (alt): Server informs existing active resource of resource conflict (case #1):

ステップ2（ALT）：サーバがリソース競合（ケース＃1）の既存のアクティブなリソースを通知します。

<stream:error> <conflict xmlns='urn:ietf:params:xml:ns:xmpp-streams'/> </stream:error> </stream:stream>

<ストリーム：エラー> <競合のxmlns = 'URN：IETF：paramsは：XML：NS：XMPPストリーム' /> </ストリーム：エラー> </ストリーム：ストリーム>

Step 2 (alt): Server informs newly-requested session of resource conflict (case #2):

ステップ2（ALT）：サーバーはリソースの競合の新たに要求されたセッションを通知する（ケース＃2）：

< 'example.com' タイプ= 'エラー' ID = 'sess_1' =からIQ> <セッションのxmlns = 'URN：IETF：paramsは：XML：NS：XMPPセッション' /> <エラータイプ= 'キャンセル'> <紛争のxmlns = '壷：IETF：のparams：XML：NS：XMPP-スタンザ' /> </エラー> </ IQ>

After establishing a session, a client SHOULD send initial presence and request its roster as described below, although these actions are OPTIONAL.

セッションを確立した後、クライアントは初期の存在を送信し、これらのアクションはオプションですが、以下で説明するように、その名簿を要求すべきです。

Note: Before allowing the creation of instant messaging and presence sessions, a server MAY require prior account provisioning. Possible methods for account provisioning include account creation by a server administrator as well as in-band account registration using the 'jabber:iq:register' namespace; the latter method is out of scope for this memo, but is documented in [JEP-0077], published by the Jabber Software Foundation [JSF].

注意：インスタントメッセージングとプレゼンスセッションの作成を許可する前に、サーバーは、前のアカウントのプロビジョニングが必要な場合があります。アカウントプロビジョニングのための可能な方法は、サーバ管理者だけでなく、「：IQ：ジャバー登録」を使用してインバンドアカウント登録してアカウントの作成を含める名前空間を。後者の方法は、このメモの範囲外ですが、Jabberのソフトウェア財団[JSF]が発行し、[JEP-0077]に記載されています。

4. Exchanging Messages

4.メッセージの交換

Exchanging messages is a basic use of XMPP and is brought about when a user generates a message stanza that is addressed to another entity. As defined under Server Rules for Handling XML Stanzas (Section 11), the sender's server is responsible for delivering the message to the intended recipient (if the recipient is on the same server) or for routing the message to the recipient's server (if the recipient is on a different server).

メッセージを交換することはXMPPの基本的な使用であり、ユーザーが別のエンティティ宛てのメッセージスタンザを生成するときにもたらされます。 XMLスタンザ（セクション11）を取り扱うためにサーバーのルールの下で定義されているように、送信者のサーバ（または受信者のサーバーにメッセージをルーティングするための（受信者が同じサーバー上にある場合）、目的の受信者にメッセージを配信する責任がある場合は、受信者）別のサーバー上にあります。

For information regarding the syntax of message stanzas as well as their defined attributes and child elements, refer to Message Syntax (Section 2.1).

メッセージの構文に関する情報はスタンザだけでなく、その定義された属性と子要素については、メッセージ構文（2.1節）を参照してください。

4.1. Specifying an Intended Recipient

4.1. 意図した受信者を指定します

An instant messaging client SHOULD specify an intended recipient for a message by providing the JID of an entity other than the sender in the 'to' attribute of the <message/> stanza. If the message is being sent in reply to a message previously received from an address of the form <user@domain/resource> (e.g., within the context of a chat session), the value of the 'to' address SHOULD be of the form <user@domain/resource> rather than of the form <user@domain> unless the sender has knowledge (via presence) that the intended recipient's resource is no longer available. If the message is being sent outside the context of any existing chat session or received message, the value of the 'to' address SHOULD be of the form <user@domain> rather than of the form <user@domain/resource>.

インスタントメッセージングクライアントは、<メッセージ/>スタンザの属性「から」内の送信者以外のエンティティのJIDを提供することにより、メッセージの意図された受信者を指定する必要があります。メッセージは、以前（チャットセッションのコンテキスト内で、例えば、）フォーム<ユーザ@ドメイン/リソース>のアドレスから受信したメッセージに対する応答で送信されている場合、アドレス「へ」の値はでなければなりません受信者のリソースが使用できなくなったということではなく、送信者が（存在経由）の知識を持っていない限り、フォーム<ユーザー@ドメイン>の形式<ユーザ@ドメイン/リソース>。メッセージは、任意の既存のチャットセッションまたは受信したメッセージのコンテキスト外で送信されている場合、アドレス「へ」の値ではなく、フォーム<ユーザ@ドメイン/リソース>のより形式<ユーザ@ドメイン>でなければなりません。

4.2. Specifying a Message Type

4.2. メッセージの種類を指定します

As noted, it is RECOMMENDED for a message stanza to possess a 'type' attribute whose value captures the conversational context (if any) of the message (see Type (Section 2.1.1)).

述べたように、それは価値のメッセージの会話のコンテキストを（もしあれば）を取り込む「タイプ」属性を所有するメッセージスタンザのために推奨され（タイプ（セクション2.1.1を参照））。

The following example shows a valid value of the 'type' attribute:

次の例では、「タイプ」属性の有効な値を示しています。

Example: A message of a defined type:

例：定義されたタイプのメッセージ：

<message to='romeo@example.net' from='juliet@example.com/balcony' type='chat' xml:lang='en'> <body>Wherefore art thou, Romeo?</body> </message>

<メッセージto='romeo@example.net 'from='juliet@example.com/balcony' タイプ=は、XMLを[チャット]：LANG = 'EN'> <身体>それゆえアート汝、ロミオ</ BODY> </？メッセージ>

4.3. Specifying a Message Body

4.3. メッセージ本文を指定します

A message stanza MAY (and often will) contain a child <body/> element whose XML character data specifies the primary meaning of the message (see Body (Section 2.1.2.2)).

メッセージスタンザMAY（およびしばしばます）XML文字データ（ボディ（セクション2.1.2.2）を参照してください）メッセージの主な意味を指定する子の<body />要素が含まれています。

Example: A message with a body:

例：身体のメッセージ：

<message to='romeo@example.net' from='juliet@example.com/balcony' type='chat' xml:lang='en'> <body>Wherefore art thou, Romeo?</body> <body xml:lang='cz'>PročeŽ jsi ty, Romeo?</body> </message>

<メッセージto='romeo@example.net 'from='juliet@example.com/balcony' タイプ=は、XMLを[チャット]：LANG = 'EN'> <身体>それゆえアート汝、ロミオ</ BODY> <ボディ？ XML：LANG = 'CZ'>プロ＆＃x010D; E＆＃x017D; JSI TY、ロミオ？</ BODY> </メッセージ>

4.4. Specifying a Message Subject

4.4. メッセージの件名を指定します

A message stanza MAY contain one or more child <subject/> elements specifying the topic of the message (see Subject (Section 2.1.2.1)).

メッセージスタンザが1つまたは複数の子メッセージのトピックを指定する<対象/>要素を含んでいてもよい（件名（セクション2.1.2.1を参照））。

Example: A message with a subject:

例：件名のメッセージ：

<message to='romeo@example.net' from='juliet@example.com/balcony' type='chat' xml:lang='en'> <subject>I implore you!</subject> <subject xml:lang='cz'>Úpěnlivě prosim!</subject> <body>Wherefore art thou, Romeo?</body> <body xml:lang='cz'>PročeŽ jsi ty, Romeo?</body> </message>

<メッセージto='romeo@example.net 'from='juliet@example.com/balcony' タイプは、= XMLを[チャット]：LANG = 'EN'> <対象>私はあなたを懇願</サブジェクト> <サブジェクトのxml！ LANG = 'CZ'>＆＃x00DA; P＆＃x011B; nliv＆＃x011B; ！？prosim </件名> <身体>何のためにアート汝、ロミオ</ body>の<身体のxml：LANG = 'CZ'>プロ＆＃x010D; E＆＃x017D; JSI TY、ロミオ？</ BODY> </メッセージ>

4.5. Specifying a Conversation Thread

4.5. 会話スレッドを指定します

A message stanza MAY contain a child <thread/> element specifying the conversation thread in which the message is situated, for the purpose of tracking the conversation (see Thread (Section 2.1.2.3)).

メッセージスタンザは（スレッド（セクション2.1.2.3）を参照）、会話を追跡する目的のために、メッセージが置かれている会話スレッドを指定して子<スレッド/>要素を含むかもしれません。

Example: A threaded conversation:

例：スレッドの会話：

<message to='romeo@example.net/orchard' from='juliet@example.com/balcony' type='chat' xml:lang='en'> <body>Art thou not Romeo, and a Montague?</body> <thread>e0ffe42b28561960c6b12b944a092794b9683a38</thread> </message>

< 'from='juliet@example.com/balcony' タイプ= to='romeo@example.net/orchardメッセージはXMLを[チャット]：LANG = 'EN'>？<身体>アート汝ないロミオ、そしてモンタギュー< / body> <スレッド> e0ffe42b28561960c6b12b944a092794b9683a38 </スレッド> </メッセージ>

<message to='juliet@example.com/balcony' from='romeo@example.net/orchard' type='chat' xml:lang='en'> <body>Neither, fair saint, if either thee dislike.</body> <thread>e0ffe42b28561960c6b12b944a092794b9683a38</thread> </message>

<メッセージto='juliet@example.com/balcony 'from='romeo@example.net/orchard' タイプ= [チャット] XML：LANG = 'EN'> <身体>どちらも、公正聖人、どちらかあなたが嫌いならば。 </ BODY> <スレッド> e0ffe42b28561960c6b12b944a092794b9683a38 </スレッド> </メッセージ>

<message to='romeo@example.net/orchard' from='juliet@example.com/balcony' type='chat' xml:lang='en'> <body>How cam'st thou hither, tell me, and wherefore?</body> <thread>e0ffe42b28561960c6b12b944a092794b9683a38</thread> </message>

<メッセージ 'from='juliet@example.com/balcony' タイプto='romeo@example.net/orchard = XMLを[チャット]：LANG = 'EN'> <身体>どのようにcam'st魅惑あなたは、私に教えて、そして何のために？</ body> <スレッド> e0ffe42b28561960c6b12b944a092794b9683a38 </スレッド> </メッセージ>

5. Exchanging Presence Information

5.プレゼンス情報の交換

Exchanging presence information is made relatively straightforward within XMPP by using presence stanzas. However, we see here a contrast to the handling of messages: although a client MAY send directed presence information to another entity by including a 'to' address, normally presence notifications (i.e., presence stanzas with no 'type' or of type "unavailable" and with no 'to' address) are sent from a client to its server and then broadcasted by the server to any entities that are subscribed to the presence of the sending entity (in the terminology of RFC 2778 [IMP-MODEL], these entities are subscribers). This broadcast model does not apply to subscription-related presence stanzas or presence stanzas of type "error", but to presence notifications only as defined above. (Note: While presence information MAY be provided on a user's behalf by an automated service, normally it is provided by the user's client.)

プレゼンス情報を交換することプレゼンススタンザを使用してXMPP内は比較的簡単行われます。しかし、我々はここでメッセージの処理にコントラストを参照してください。クライアントは通常、アドレス「から」プレゼンス通知などにより別のエンティティに向けプレゼンス情報を送信するかもしれないが（すなわち、存在が利用できない「ノー「タイプ」またはタイプのとスタンザ」とアドレス『に』なし）は、RFC 2778 [IMP-MODEL]の用語で（送信側エンティティのプレゼンスに加入している任意のエンティティにサーバがそのクライアントからサーバに送信され、その後、放送されると、これらエンティティ）が加入しています。この放送モデルは、上記で定義された唯一のようなタイプのサブスクリプションに関連するプレゼンススタンザまたは存在スタンザ「エラー」に、しかし、プレゼンス通知には適用されません。（注：プレゼンス情報が自動化されたサービスがユーザーに代わって提供することができるが、通常はそれがユーザーのクライアントによって提供されます。）

For information regarding the syntax of presence stanzas as well as their defined attributes and child elements, refer to [XMPP-CORE].

プレゼンスの構文に関する情報はスタンザだけでなく、その定義された属性と子要素の場合は、[XMPP-CORE]を参照してください。

5.1. Client and Server Presence Responsibilities

5.1. クライアントとサーバーのプレゼンスの責任

5.1.1. Initial Presence

5.1.1. 初期プレゼンス

After establishing a session, a client SHOULD send initial presence to the server in order to signal its availability for communications. As defined herein, the initial presence stanza (1) MUST possess no 'to' address (signalling that it is meant to be broadcasted by the server on behalf of the client) and (2) MUST possess no 'type' attribute (signalling the user's availability). After sending initial presence, an active resource is said to be an "available resource".

セッションを確立した後、クライアントは、通信のためにその有効性を知らせるために、サーバーへの最初の存在を送るべきです。本明細書で定義されるように、初期プレゼンススタンザ（1）はアドレスなし「に」（クライアントの代わりにサーバで放送されることを意図されていることをシグナリング）及び（2）シグナル伝達（いいえ「タイプ」属性を有していなければならないを持っていなければなりませんユーザーの可用性）。初期の存在を送信した後、アクティブなリソースは、「使用可能なリソース」と言われています。

Upon receiving initial presence from a client, the user's server MUST do the following if there is not already one or more available resources for the user (if there is already one or more available resources for the user, the server obviously does not need to send the presence probes, since it already possesses the requisite information):

クライアントからの最初のプレゼンスを受信すると、ユーザーのサーバーは、ユーザーのために、以下のいない場合、1つまたは複数の利用可能なリソースを行う必要があります（ユーザーのための1つまたは複数の利用可能な資源がすでに存在する場合、サーバーは明らかに送信する必要はありません。プレゼンスプローブ、それはすでに必要な情報を持っているので）：

1. Send presence probes (i.e., presence stanzas whose 'type' attribute is set to a value of "probe") from the full JID (e.g., <user@example.com/resource>) of the user to all contacts to which the user is subscribed in order to determine if they are available; such contacts are those for which a JID is present in the user's roster with the 'subscription' attribute set to a value of "to" or "both". (Note: The user's server MUST NOT send presence probes to contacts from which the user is blocking inbound presence notifications, as described under Blocking Inbound Presence Notifications (Section 10.10).)

1.これまでのすべての連絡先にユーザーの完全なJID（例えば、<user@example.com/resource>）からプレゼンスプローブ（その「タイプ」属性が「プローブ」の値に設定されている、すなわち、プレゼンススタンザ）を送りますユーザーは、それらが利用可能かどうかを決定するために購読されています。そのような接点は、JIDは「へ」または「両方」の値に設定する「サブスクリプション」属性を持つ利用者の名簿に存在しているものがあります。（注意：インバウンドプレゼンス通知（10.10節）をブロックの下に説明するように、ユーザのサーバは、ユーザが、インバウンドプレゼンス通知をブロックされた連絡先にプレゼンスプローブを送ってはいけません。）

2. Broadcast initial presence from the full JID (e.g., <user@example.com/resource>) of the user to all contacts that are subscribed to the user's presence information; such contacts are those for which a JID is present in the user's roster with the 'subscription' attribute set to a value of "from" or "both". (Note: The user's server MUST NOT broadcast initial presence to contacts to which the user is blocking outbound presence notifications, as described under Blocking Outbound Presence Notifications (Section 10.11).)

ユーザのプレゼンス情報にサブスクライブしているすべての連絡先にユーザの完全なJID（例えば、<user@example.com/resource>）から2.ブロードキャスト初期プレゼンス。そのような接点は、JIDは「から」または「両方」の値に設定する「サブスクリプション」属性を持つ利用者の名簿に存在しているものがあります。（注意：送信プレゼンス通知（10.11）をブロックの下に説明するように、ユーザのサーバは、ユーザが、アウトバウンドプレゼンス通知をブロックされている連絡先に、最初の存在を放送してはなりません。）

In addition, the user's server MUST broadcast initial presence from the user's new available resource to any of the user's existing available resources (if any).

（もしあれば）また、ユーザーのサーバーは、ユーザーの既存の利用可能なリソースのいずれかにユーザーの新しい可能なリソースからの初期の存在をブロードキャストしなければなりません。

Upon receiving initial presence from the user, the contact's server MUST deliver the user's presence stanza to the full JIDs (<contact@example.org/resource>) associated with all of the contact's available resources, but only if the user is in the contact's roster with a subscription state of "to" or "both" and the contact has not blocked inbound presence notifications from the user's bare or full JID (as defined under Blocking Inbound Presence Notifications (Section 10.10)).

ユーザーからの最初のプレゼンスを受信すると、連絡先のサーバーは、連絡先の利用可能なリソースのすべてに関連した完全なたJID（<contact@example.org/resource>）へのユーザーのプレゼンススタンザを提供する必要がありますが、ユーザーは、連絡先の中にある場合にのみサブスクリプション状態に名簿「へ」または「両方」との接触は、ユーザーの裸やフルJIDからのインバウンドプレゼンス通知をブロックしていない（インバウンドプレゼンス通知をブロックの下に定義されている（10.10））。

If the user's server receives a presence stanza of type "error" in response to the initial presence that it sent to a contact on behalf of the user, it SHOULD NOT send further presence updates to that contact (until and unless it receives a presence stanza from the contact).

ユーザーのサーバーは、それがユーザーに代わって連絡先に送信することを最初の存在に応じてタイプ「エラー」の存在スタンザを受信した場合、それが存在スタンザを受信するまでとしない限り、それは（その連絡先に、さらにプレゼンスの更新を送るべきではありません接触から）。

5.1.2. Presence Broadcast

5.1.2. プレゼンス放送

After sending initial presence, the user MAY update its presence information for broadcasting at any time during its session by sending a presence stanza with no 'to' address and either no 'type' attribute or a 'type' attribute with a value of "unavailable". (Note: A user's client SHOULD NOT send a presence update to broadcast information that changes independently of the user's presence and availability.)

最初のプレゼンスを送信した後、ユーザーはアドレスと使用できません「の値がないか「タイプ」属性や「type」属性「に」はでのプレゼンススタンザを送信しないことによって、そのセッション中はいつでも放送用のプレゼンス情報を更新することができます。」。（注：ユーザーのクライアントには、独立して、ユーザーのプレゼンスおよび可用性の変更情報をブロードキャストするプレゼンス更新を送るべきではありません。）

If the presence stanza lacks a 'type' attribute (i.e., expresses availability), the user's server MUST broadcast the full XML of that presence stanza to all contacts (1) that are in the user's roster with a subscription type of "from" or "both", (2) to whom the user has not blocked outbound presence notifications, and (3) from whom the server has not received a presence error during the user's session (as well as to any of the user's other available resources).

プレゼンススタンザは、「タイプ」属性（すなわち、可用性を表現する）不足している場合は、ユーザーのサーバーは、「から」のサブスクリプションタイプで、ユーザの名簿にあるすべての連絡先（1）にその存在スタンザの完全なXMLを放送しなければなりませんか、「両方」、（2）ユーザーが発信プレゼンス通知をブロックしていない、および（3）誰からサーバーは、ユーザーのセッション中に存在エラーを受信していない人に（だけでなく、ユーザーの他の利用可能なリソースのいずれかに）。

If the presence stanza has a 'type' attribute set to a value of "unavailable", the user's server MUST broadcast the full XML of that presence stanza to all entities that fit the above description, as well as to any entities to which the user has sent directed available presence during the user's session (if the user has not yet sent directed unavailable presence to that entity).

プレゼンススタンザは「利用不可」の値に設定する「タイプ」属性を持っている場合、ユーザーのサーバーは、任意のエンティティにだけでなく、上記の説明に合わせてすべてのエンティティへのプレゼンススタンザの完全なXMLを放送しなければならないユーザーに（まだ送信していないユーザーは、そのエンティティに利用できない存在を指示されている場合）、ユーザーのセッション中に向ける可能なプレゼンスを送信しました。

5.1.3. Presence Probes

5.1.3. プレゼンスプローブ

Upon receiving a presence probe from the user, the contact's server SHOULD reply as follows:

次のようにユーザからのプレゼンスプローブを受信すると、連絡先のサーバが応答する必要があります。

1. If the user is not in the contact's roster with a subscription state of "From", "From + Pending Out", or "Both" (as defined under Subscription States (Section 9)), the contact's server MUST return a presence stanza of type "error" in response to the presence probe (however, if a server receives a presence probe from a subdomain of the server's hostname or another such trusted service, it MAY provide presence information about the user to that entity). Specifically:

1.利用者は、「差出人」、「アウト保留+から」、または「両方」（サブスクリプションの状態の下で定義されている（第9節））のサブスクリプション状態と接触者の名簿にない場合は、連絡先のサーバが存在感を返さなければなりませんプレゼンスプローブに応答して、タイプ「エラー」のスタンザ（サーバは、サーバのホスト名または別のそのような信頼できるサービスのサブドメインからのプレゼンスプローブを受信した場合しかし、それはそのエンティティへのユーザについてのプレゼンス情報を提供することができます）。具体的に：

       *  if the user is in the contact's roster with a subscription
          state of "None", "None + Pending Out", or "To" (or is not in
          the contact's roster at all), the contact's server MUST return
          a <forbidden/> stanza error in response to the presence probe.

* if the user is in the contact's roster with a subscription state of "None + Pending In", "None + Pending Out/In", or "To + Pending In", the contact's server MUST return a <not-authorized/> stanza error in response to the presence probe.

ユーザーは、「なし+保留アウト/イン」、または「+保留中へ」「なし+保留中」のサブスクリプションの状態で連絡先の名簿にある場合*、連絡先のサーバが返さなければならない<-許可されていません/>プレゼンスプローブに応答して、スタンザエラー。

2. Else, if the contact is blocking presence notifications to the user's bare JID or full JID (using either a default list or active list as defined under Blocking Outbound Presence Notifications (Section 10.11)), the server MUST NOT reply to the presence probe.

そうでなければ2、接触は（アウトバウンドプレゼンス通知（10.11）をブロックの下に定義されているデフォルトのリストまたはアクティブリストのいずれかを使用して）、ユーザーの裸JIDまたは完全なJIDにプレゼンス通知をブロックしている場合、サーバはプレゼンスプローブに返信てはなりません。

3. Else, if the contact has no available resources, the server MUST either (1) reply to the presence probe by sending to the user the full XML of the last presence stanza of type "unavailable" received by the server from the contact, or (2) not reply at all.

コンタクトが利用可能なリソースを持っていない場合はそれ以外3は、サーバは、（1）、接触からサーバによって受信された「利用できない」ユーザにタイプの最後のプレゼンススタンザの完全なXMLを送信することにより、プレゼンスプローブに応答しなければなりませんまたは（2）ですべての返信できません。

4. Else, if the contact has at least one available resource, the server MUST reply to the presence probe by sending to the user the full XML of the last presence stanza with no 'to' attribute received by the server from each of the contact's available resources (again, subject to privacy lists in force for each session).

接触は、少なくとも1つの利用可能なリソースを持っている場合はそうでない4.は、サーバーは、連絡先のそれぞれから、サーバーが受信した属性「に」は、ユーザにいないとの最後のプレゼンススタンザの完全なXMLを送信することにより、プレゼンスプローブに返信しなければなりません利用可能なリソース（再び、プライバシーの対象は、各セッションのために力に一覧表示されます）。

5.1.4. Directed Presence

5.1.4. ダイレクトプレゼンス

A user MAY send directed presence to another entity (i.e., a presence stanza with a 'to' attribute whose value is the JID of the other entity and with either no 'type' attribute or a 'type' attribute whose value is "unavailable"). There are three possible cases:

ユーザは、その値が他のエンティティのJIDといいえ「タイプ」属性またはその値が「利用不可能」である「タイプ」属性のいずれかを持つ属性「」へと別のエンティティ（すなわち、プレゼンススタンザに向けプレゼンスを送信することができます）。三つの可能なケースがあります。

1. If the user sends directed presence to a contact that is in the user's roster with a subscription type of "from" or "both" after having sent initial presence and before sending unavailable presence broadcast, the user's server MUST route or deliver the full XML of that presence stanza (subject to privacy lists) but SHOULD NOT otherwise modify the contact's status regarding presence broadcast (i.e., it SHOULD include the contact's JID in any subsequent presence broadcasts initiated by the user).

1.利用者は、最初のプレゼンスを送信した後と使用できない存在ブロードキャストを送信する前に、ユーザーのサーバーMUSTルートやフルを届ける「両方」「から」またはのサブスクリプションタイプを持つユーザーの名簿にある連絡先に向けプレゼンスを送信した場合そのプレゼンススタンザ（プライバシリストの対象）のXMLが、それ以外の存在放送に関する連絡先の状態を変更するべきではありません（つまり、それがユーザによって開始後続存在放送で連絡先のJIDを含める必要があります）。

2. If the user sends directed presence to an entity that is not in the user's roster with a subscription type of "from" or "both" after having sent initial presence and before sending unavailable presence broadcast, the user's server MUST route or deliver the full XML of that presence stanza to the entity but MUST NOT modify the contact's status regarding available presence broadcast (i.e., it MUST NOT include the entity's JID in any subsequent broadcasts of available presence initiated by the user); however, if the available resource from which the user sent the directed presence become unavailable, the user's server MUST broadcast that unavailable presence to the entity (if the user has not yet sent directed unavailable presence to that entity).

2.ユーザーは、最初のプレゼンスを送信した後と使用できない存在ブロードキャストを送信する前に、ユーザーのサーバーMUSTルートや届ける「両方」「から」またはのサブスクリプションタイプを持つユーザーの名簿にないエンティティに向けプレゼンスを送信した場合エンティティへのプレゼンススタンザの完全なXMLが、利用可能なプレゼンス放送（すなわち、それはユーザによって開始可能な存在のいずれかのその後の放送で、エンティティのJIDを含んではいけません）に関する連絡先の状態を変更してはいけません。ユーザーが指示プレゼンスを送信し、そこから利用できるリソースが利用できなくなった場合（ユーザーがまだその実体に利用できない存在を指示送信していない場合）ただし、ユーザーのサーバーは、エンティティにその利用できない存在をブロードキャストしなければなりません。

3. If the user sends directed presence without first sending initial presence or after having sent unavailable presence broadcast (i.e., the resource is active but not available), the user's server MUST treat the entities to which the user sends directed presence in the same way that it treats the entities listed in case #2 above.

3.ユーザーは（つまり、リソースが利用可能アクティブではありません）最初の初期の存在を送信せず、または利用できない存在放送を送信した後に監督の存在を送信した場合、ユーザーのサーバーは、ユーザーが同じように指示さプレゼンスを送信先のエンティティを扱わなければなりませんそれは、上記のケース＃2に記載されているエンティティを扱うこと。

5.1.5. Unavailable Presence

5.1.5. 使用不可のプレゼンス

Before ending its session with a server, a client SHOULD gracefully become unavailable by sending a final presence stanza that possesses no 'to' attribute and that possesses a 'type' attribute whose value is "unavailable" (optionally, the final presence stanza MAY contain one or more <status/> elements specifying the reason why the user is no longer available). However, the user's server MUST NOT depend on receiving final presence from an available resource, since the resource may become unavailable unexpectedly or may be timed out by the server. If one of the user's resources becomes unavailable for any reason (either gracefully or ungracefully), the user's server MUST broadcast unavailable presence to all contacts (1) that are in the user's roster with a subscription type of "from" or "both", (2) to whom the user has not blocked outbound presence, and (3) from whom the server has not received a presence error during the user's session; the user's server MUST also send that unavailable presence stanza to any of the user's other available resources, as well as to any entities to which the user has sent directed presence during the user's session for that resource (if the user has not yet sent directed unavailable presence to that entity). Any presence stanza with no 'type' attribute and no 'to' attribute that is sent after sending directed unavailable presence or broadcasted unavailable presence MUST be broadcasted by the server to all subscribers.

サーバーとのセッションを終了する前に、クライアントは優雅に属性「に」ノーを持っている、最終的なプレゼンススタンザを送信することにより、使用できなくなるべき、それは、値が「利用不可」である（必要に応じて、最終的プレゼンススタンザが含まれているかもしれない「タイプ」属性を持っていますユーザーはもはや利用できない理由を指定する1つまたは複数の<状態/>要素）。リソースが予期せずに利用できなくなったり、サーバーによってタイムアウトすることができるので、ユーザーのサーバーは、使用可能なリソースから、最終的なプレゼンスを受け取るに依存してはなりません。ユーザーのリソースの1が何らかの理由（いずれか正常または不正に）のために使用できなくなった場合は、ユーザーのサーバーは、「から」または「両方」のサブスクリプションタイプを持つユーザーの名簿にあるすべての連絡先（1）に使用できない存在をブロードキャストしなければなりません、（2）ユーザが発信プレゼンスをブロックしていない人に、及び（3）サーバは、ユーザのセッション中に存在エラーを受信していない人から、ユーザーはまだ利用できない監督送信していない場合、ユーザーのサーバーは、（ユーザーの他の利用可能なリソースのいずれかに、だけでなく、ユーザーがそのリソースに対するユーザーのセッション中に監督の存在を送信してきた任意のエンティティにその利用できない存在スタンザを送らなければなりませんそのエンティティに存在）。指示使用できない存在または放送利用できない存在を送信した後に送信される属性「に」いいえ「タイプ」属性なしで任意のプレゼンススタンザは、すべての加入者に、サーバで放送されなければなりません。

5.1.6. Presence Subscriptions

5.1.6. プレゼンスサブスクリプション

A subscription request is a presence stanza whose 'type' attribute has a value of "subscribe". If the subscription request is being sent to an instant messaging contact, the JID supplied in the 'to' attribute SHOULD be of the form <contact@example.org> rather than <contact@example.org/resource>, since the desired result is normally for the user to receive presence from all of the contact's resources, not merely the particular resource specified in the 'to' attribute.

サブスクリプション要求は、その「タイプ」属性「購読」の値を有するプレゼンススタンザです。サブスクリプション要求がインスタントメッセージング連絡先に送信されている場合、JIDの形式でなければならない「」の属性で供給<contact@example.org>なく<contact@example.org/resource>、所望の結果以来ユーザーは、連絡先のすべてのリソースから「から」属性で指定されていないだけで、特定のリソースをプレゼンスを受信するために、通常です。

A user's server MUST NOT automatically approve subscription requests on the user's behalf. All subscription requests MUST be directed to the user's client, specifically to one or more available resources associated with the user. If there is no available resource associated with the user when the subscription request is received by the user's server, the user's server MUST keep a record of the subscription request and deliver the request when the user next creates an available resource, until the user either approves or denies the request. If there is more than one available resource associated with the user when the subscription request is received by the user's server, the user's server MUST broadcast that subscription request to all available resources in accordance with Server Rules for Handling XML Stanzas (Section 11). (Note: If an active resource

ユーザーのサーバーが自動的にユーザーに代わって、サブスクリプション要求を承認してはなりません。すべてのサブスクリプション要求は、ユーザに関連する1つまたは複数の利用可能なリソースに特異的に、ユーザのクライアントに向けなければなりません。サブスクリプション要求は、ユーザーのサーバーによって受信されたときにユーザーに関連付けられている使用可能なリソースがない場合は、ユーザーのサーバーは、サブスクリプション要求の記録を保持しなければならないし、ユーザーが承認するまで、ユーザーは次回、利用できるリソースを作成する場合、要求を実現しますまたは要求を拒否します。サブスクリプション要求は、ユーザーのサーバーによって受信されたユーザに関連付けられた複数の利用可能なリソースがある場合は、ユーザーのサーバーは、XMLスタンザ（セクション11）を処理するためのサーバーの規則に従い、すべての利用可能なリソースへのサブスクリプション要求をブロードキャストしなければなりません。（注意：アクティブなリソース場合

has not provided initial presence, the server MUST NOT consider it to be available and therefore MUST NOT send subscription requests to it.) However, if the user receives a presence stanza of type "subscribe" from a contact to whom the user has already granted permission to see the user's presence information (e.g., in cases when the contact is seeking to resynchronize subscription states), the user's server SHOULD auto-reply on behalf of the user. In addition, the user's server MAY choose to re-send an unapproved pending subscription request to the contact based on an implementation-specific algorithm (e.g., whenever a new resource becomes available for the user, or after a certain amount of time has elapsed); this helps to recover from transient, silent errors that may have occurred in relation to the original subscription request.

最初のプレゼンスを提供していない、サーバーは、それへのサブスクリプション要求を送ってはいけませんので、それが利用可能であることを考えると、してはならない。）しかし、ユーザーは、ユーザーがすでに付与されている人に接触から「購読する」タイプの存在スタンザを受信した場合（連絡先は、サブスクリプションの状態を再同期しようとしているときのケースでは、例えば）許可は、ユーザーのサーバーがユーザーの代わりに自動返信SHOULD、ユーザーのプレゼンス情報を表示します。また、ユーザーのサーバーが実装固有のアルゴリズムに基づいて連絡先に承認されていない保留中のサブスクリプション要求を再送信することを選択した（例えば、新しいリソースがユーザーのために利用可能になるたび、または一定の時間が経過した後に） ;これは、元のサブスクリプション要求に関連して発生した可能性があり、過渡、サイレントエラーから回復するのに役立ちます。

5.2. Specifying Availability Status

5.2. 可用性ステータスを指定します

A client MAY provide further information about its availability status by using the <show/> element (see Show (Section 2.2.2.1)).

クライアントは、<ショー/>要素（ショー（セクション2.2.2.1）を参照）を使用して、その可用性状況に関するさらなる情報を提供することができます。

Example: Availability status:

例：可用性ステータス：

<存在> <ショー> DND </示して> </プレゼンス>

5.3. Specifying Detailed Status Information

5.3. 詳細なステータス情報を指定します

In conjunction with the <show/> element, a client MAY provide detailed status information by using the <status/> element (see Status (Section 2.2.2.2)).

<ショー/>要素に関連して、クライアントは、<状態/>要素を使って、詳細なステータス情報を提供することができる（ステータス（セクション2.2.2.2を参照））。

Example: Detailed status information:

例：詳細なステータス情報：

<presence xml:lang='en'> <show>dnd</show> <status>Wooing Juliet</status> <status xml:lang='cz'>Ja dvořím Juliet</status> </presence>

<プレゼンスXML：LANG = 'EN'> <表示> DND </表示> <状態>ジュリエットを求愛</ステータス> <ステータスXML：LANG = 'CZ'>ジャDVO＆＃をx0159;＆＃x00ED; Mジュリエット</状態> </プレゼンス>

5.4. Specifying Presence Priority

5.4. プレゼンスの優先順位を指定します

A client MAY provide a priority for its resource by using the <priority/> element (see Priority (Section 2.2.2.3)).

クライアントは<優先/>要素（優先度（2.2.2.3項）を参照）を使用して、そのリソースの優先順位を提供することができます。

Example: Presence priority:

例：プレゼンスの優先順位：

<presence xml:lang='en'> <show>dnd</show> <status>Wooing Juliet</status> <status xml:lang='cz'>Ja dvořím Juliet</status> <priority>1</priority> </presence>

<プレゼンスXML：LANG = 'EN'> <表示> DND </表示> <状態>ジュリエットを求愛</ステータス> <ステータスXML：LANG = 'CZ'>ジャDVO＆＃をx0159;＆＃x00ED; Mジュリエット</状態> <優先順位> 1 </優先順位> </プレゼンス>

5.5. Presence Examples

5.5. プレゼンスの例

The examples in this section illustrate the presence-related protocols described above. The user is romeo@example.net, he has an available resource whose resource identifier is "orchard", and he has the following individuals in his roster:

このセクションの例は、上述したプレゼンス関連のプロトコルを示します。ユーザーはromeo@example.netで、彼は、その資源識別子「果樹園」で使用可能なリソースを持っている、と彼は彼の名簿で以下の個人があります。

o juliet@example.com (subscription="both" and she has two available resources, one whose resource is "chamber" and another whose resource is "balcony")

O juliet@example.com（サブスクリプション=「両方」と、彼女は2つの使用可能なリソース、そのリソース「室」で、その資源「バルコニー」である別のものを持っています）

o benvolio@example.org (subscription="to")

O benvolio@example.org（サブスクリプション= "へ"）

o mercutio@example.org (subscription="from")

O mercutio@example.org（サブスクリプション= "から"）

Example 1: User sends initial presence:

例1：ユーザーが最初のプレゼンスを送信します。

<存在/>

Example 2: User's server sends presence probes to contacts with subscription="to" and subscription="both" on behalf of the user's available resource:

例2：ユーザーのサーバーは、ユーザーの使用可能なリソースの代わりに、「両方」= =「と」サブスクリプションおよびサブスクリプションとの接点に存在プローブを送信します。

<プレゼンス・タイプ= 'プローブ' from='romeo@example.net/orchard 'to='juliet@example.com' />

<プレゼンス・タイプ= 'プローブ' from='romeo@example.net/orchard 'to='benvolio@example.org' />

Example 3: User's server sends initial presence to contacts with subscription="from" and subscription="both" on behalf of the user's available resource:

例3：ユーザーのサーバーは、ユーザーの使用可能なリソースの代わりに、「両方」= =「から」サブスクリプションおよびサブスクリプションとの接触に最初のプレゼンスを送信します。

<プレゼンスfrom='romeo@example.net/orchard 'to='juliet@example.com' />

<存在from='romeo@example.net/orchard 'to='mercutio@example.org' />

Example 4: Contacts' servers reply to presence probe on behalf of all available resources:

例4：連絡先のサーバが使用可能なすべてのリソースに代わって存在プローブに返信：

<presence from='juliet@example.com/balcony' to='romeo@example.net/orchard' xml:lang='en'> <show>away</show> <status>be right back</status> <priority>0</priority> </presence>

<xmlの「to='romeo@example.net/orchardのプレゼンスfrom='juliet@example.com/balcony：LANG = 'EN'> <ショー>離れて</ショー> <状態>すぐ戻る</ステータス> <優先度> 0 </優先> </プレゼンス>

<プレゼンスfrom='juliet@example.com/chamber 'to='romeo@example.net/orchard'> <優先順位> 1 </優先> </プレゼンス>

<presence from='benvolio@example.org/pda' to='romeo@example.net/orchard' xml:lang='en'> <show>dnd</show> <status>gallivanting</status> </presence>

<xmlの「to='romeo@example.net/orchardのプレゼンスfrom='benvolio@example.org/pda：LANG = 'EN'> <ショー> DND </表示し> <状態> </ </ステータス> gallivanting存在>

Example 5: Contacts' servers deliver user's initial presence to all available resources or return error to user:

例5：連絡先のサーバは、ユーザに利用可能なすべてのリソースまたはリターンエラーにユーザーの初期プレゼンスを提供します：

<存在from='romeo@example.net/orchard 'to='juliet@example.com/chamber' />

<存在from='romeo@example.net/orchard 'to='juliet@example.com/balcony' />

<プレゼンスタイプ= 'エラー' from='mercutio@example.org」to='romeo@example.net/orchard '> <エラーの種類=' キャンセル '> <なくなってのxmlns =' 壷：IETF：のparams：XML：NS ：XMPP-スタンザ/> </エラー> </プレゼンス>

Example 6: User sends directed presence to another user not in his roster:

例6：ユーザーがいない彼の名簿で別のユーザーに向けプレゼンスを送信します。

<presence from='romeo@example.net/orchard' to='nurse@example.com' xml:lang='en'> <show>dnd</show> <status>courting Juliet</status> <priority>0</priority> </presence>

<プレゼンスfrom='romeo@example.net/orchard 'to='nurse@example.com' XML：LANG = 'EN'> <表示> DND </表示> <状態>ジュリエットを求愛</ステータス> <優先順位> 0 </優先> </プレゼンス>

Example 7: User sends updated available presence information for broadcasting:

例7：ユーザーは、放送用に更新可能なプレゼンス情報を送信します。

<presence xml:lang='en'> <show>away</show> <status>I shall return!</status> <priority>1</priority> </presence>

<プレゼンスXML：LANG = 'EN'> <ショー>離れて</ショー> <状態>私が返還しなければならない。</ステータス> <優先順位> 1 </優先順位> </プレゼンス>！

Example 8: User's server broadcasts updated presence information only to one contact (not those from whom an error was received or to whom the user sent directed presence):

例8：ユーザーのサーバーは、唯一の接点（ないそれらのエラーを受信した誰からかへのユーザー送ら監督存在）に更新されたプレゼンス情報をブロードキャスト：

<presence 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 </優先> </プレゼンス>

Example 9: Contact's server delivers updated presence information to all of the contact's available resources:

例9：連絡先のサーバーは、連絡先の利用可能なリソースのすべてに更新されたプレゼンス情報を提供します。

[to "balcony" resource...] <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 </優先順位> </プレゼンス>

[to "chamber" resource...] <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 </優先順位> </プレゼンス>

Example 10: One of the contact's resources broadcasts final presence:

例10：連絡先の資源の一つは、最終的なプレゼンスをブロードキャスト：

<プレゼンスfrom='juliet@example.com/balcony」TYPE = '利用できません' />

Example 11: Contact's server sends unavailable presence information to user:

例11：連絡先のサーバは、ユーザに利用できないプレゼンス情報を送信します。

<プレゼンス・タイプ= '利用できない' from='juliet@example.com/balcony 'to='romeo@example.net/orchard' />

Example 12: User sends final presence:

例12：ユーザーは、最終的なプレゼンスを送信します。

<プレゼンスfrom='romeo@example.net/orchard」タイプ= '使用できません' のxml：LANG = 'EN'> <状態>帰宅</ステータス> </プレゼンス>

Example 13: User's server broadcasts unavailable presence information to contact as well as to the person to whom the user sent directed presence:

例13：ユーザーズ・サーバーは、人にだけでなく、連絡して利用できないプレゼンス情報をブロードキャストするユーザーが対象の存在を送った人：

<プレゼンスタイプ= '利用できない' from='romeo@example.net/orchard 'to='juliet@example.com' のxml：LANG = 'EN'> <状態>帰宅</ステータス> </プレゼンス>

<プレゼンスfrom='romeo@example.net/orchard 'to='nurse@example.com' のxml：LANG = 'EN'> <状態>帰宅</ステータス> </プレゼンス>

6. Managing Subscriptions

6.サブスクリプションの管理

In order to protect the privacy of instant messaging users and any other entities, presence and availability information is disclosed only to other entities that the user has approved. When a user has agreed that another entity may view its presence, the entity is said to have a subscription to the user's presence information. A subscription lasts across sessions; indeed, it lasts until the subscriber unsubscribes or the subscribee cancels the previously-granted subscription. Subscriptions are managed within XMPP by sending presence stanzas containing specially-defined attributes.

インスタントメッセージングユーザーやその他のエンティティのプライバシーを保護するために、プレゼンスおよび可用性の情報はユーザーのみが承認した他のエンティティに開示されています。ユーザーが別のエンティティがその存在を見ることができることに同意した場合には、エンティティは、ユーザーのプレゼンス情報へのサブスクリプションを持っていると言われています。サブスクリプションは、セッション間で続きます。確かに、それは、加入者の登録解除まで継続またはサブスクライブは、以前に付与されたサブスクリプションをキャンセルします。サブスクリプションは、特別に定義された属性を含むプレゼンススタンザを送信することによって、XMPP内で管理されています。

Note: There are important interactions between subscriptions and rosters; these are defined under Integration of Roster Items and Presence Subscriptions (Section 8), and the reader must refer to that section for a complete understanding of presence subscriptions.

注意：サブスクリプションと名簿間の重要な相互作用があります。これらは、名簿の項目とプレゼンスサブスクリプションの統合（第8節）の下で定義されており、読者はプレゼンスサブスクリプションを完全に理解するために、そのセクションを参照しなければなりません。

6.1. Requesting a Subscription

6.1. 購読を要求

A request to subscribe to another entity's presence is made by sending a presence stanza of type "subscribe".

別のエンティティのプレゼンスをサブスクライブするための要求は「購読」タイプの存在スタンザを送信することにより行われます。

Example: Sending a subscription request:

例：サブスクリプション要求を送信：

<プレゼンスto='juliet@example.com」タイプ= '' /サブスクライブ>

For client and server responsibilities regarding presence subscription requests, refer to Presence Subscriptions (Section 5.1.6).

プレゼンスサブスクリプション要求について、クライアントとサーバの責任については、プレゼンスサブスクリプション（セクション5.1.6）を参照してください。

6.2. Handling a Subscription Request

6.2. サブスクリプション要求を処理

When a client receives a subscription request from another entity, it MUST either approve the request by sending a presence stanza of type "subscribed" or refuse the request by sending a presence stanza of type "unsubscribed".

クライアントが別のエンティティからのサブスクリプション要求を受信すると、それはタイプ「サブスクライブ」の存在スタンザを送信することにより、要求を承認するか、または「解除」タイプの存在スタンザを送信することにより、要求を拒否しなければならないのいずれか。

Example: Approving a subscription request:

例：サブスクリプション要求を承認：

<プレゼンスto='romeo@example.net」TYPE = '加入/>

Example: Refusing a presence subscription request:

例：プレゼンスサブスクリプション要求を拒否：

<プレゼンスto='romeo@example.net」TYPE = '解除' />

6.3. Cancelling a Subscription from Another Entity

6.3. 別のエンティティからのサブスクリプションをキャンセル

If a user would like to cancel a previously-granted subscription request, it sends a presence stanza of type "unsubscribed".

ユーザーが以前に付与されたサブスクリプション要求をキャンセルしたい場合、それは「解除」タイプの存在スタンザを送信します。

Example: Cancelling a previously granted subscription request:

例：以前に付与されたサブスクリプション要求のキャンセル：

<プレゼンスto='romeo@example.net」TYPE = '解除' />

6.4. Unsubscribing from Another Entity's Presence

6.4. 別のエンティティの存在から退会

If a user would like to unsubscribe from the presence of another entity, it sends a presence stanza of type "unsubscribe".

ユーザーが別のエンティティの存在から退会したい場合は、「退会」タイプの存在スタンザを送信します。

Example: Unsubscribing from an entity's presence:

例：エンティティの存在から退会：

<プレゼンスto='juliet@example.com」TYPE = '解除' />

7. Roster Management

7.名簿管理

In XMPP, one's contact list is called a roster, which consists of any number of specific roster items, each roster item being identified by a unique JID (usually of the form <contact@domain>). A user's roster is stored by the user's server on the user's behalf so that the user may access roster information from any resource.

XMPPでは、一方の連絡先リストは、特定の選手の任意の数の項目から成る名簿、（通常はフォーム<接触@ドメイン>の）一意JIDによって識別される各選手アイテムと呼ばれます。ユーザーが任意のリソースから名簿情報にアクセスできるように、利用者の名簿は、ユーザーに代わって、ユーザーのサーバーに格納されています。

Note: There are important interactions between rosters and subscriptions; these are defined under Integration of Roster Items and Presence Subscriptions (Section 8), and the reader must refer to that section for a complete understanding of roster management.

注意：名簿およびサブスクリプション間の重要な相互作用があります。これらは、名簿項目の統合とプレゼンスサブスクリプション（第8節）の下で定義されており、読者は名簿の管理を完全に理解するために、そのセクションを参照しなければなりません。

7.1. Syntax and Semantics

7.1. 構文とセマンティクス

Rosters are managed using IQ stanzas, specifically by means of a <query/> child element qualified by the 'jabber:iq:roster' namespace. The <query/> element MAY contain one or more <item/> children, each describing a unique roster item or "contact".

名前空間の名簿は、特に「：IQ名簿ジャバー」によって修飾<クエリ/>子要素によって、IQスタンザを使用して管理されています。 <クエリ/>要素は、それぞれが独自の名簿項目または「連絡先」を記述し、一つ以上の<item />子供を含むかもしれません。

The "key" or unique identifier for each roster item is a JID, encapsulated in the 'jid' attribute of the <item/> element (which is REQUIRED). The value of the 'jid' attribute SHOULD be of the form <user@domain> if the item is associated with another (human) instant messaging user.

各名簿項目の「キー」または一意の識別子（必須である）の<item />要素の「JID」属性にカプセル化された、JIDあります。「JID」属性の値は、項目が別の（人間の）インスタント・メッセージング・ユーザーに関連付けられている場合、フォーム<ユーザー@ドメイン>でなければなりません。

The state of the presence subscription in relation to a roster item is captured in the 'subscription' attribute of the <item/> element. Allowable values for this attribute are:

名簿項目に関連するプレゼンス購読の状態の<item />要素の「サブスクリプション」属性に捕捉されます。この属性の許容値は、次のとおりです。

o "none" -- the user does not have a subscription to the contact's presence information, and the contact does not have a subscription to the user's presence information

O「なし」 - ユーザーが連絡先のプレゼンス情報へのサブスクリプションを持っていない、との接触は、ユーザーのプレゼンス情報へのサブスクリプションを持っていません

o "to" -- the user has a subscription to the contact's presence information, but the contact does not have a subscription to the user's presence information

O「に」 - ユーザーは、連絡先のプレゼンス情報へのサブスクリプションを持っていますが、連絡先は、ユーザーのプレゼンス情報へのサブスクリプションを持っていません

o "from" -- the contact has a subscription to the user's presence information, but the user does not have a subscription to the contact's presence information

O「から」 - 連絡先は、ユーザーのプレゼンス情報へのサブスクリプションを持っていますが、ユーザーは、連絡先のプレゼンス情報へのサブスクリプションを持っていません

o "both" -- both the user and the contact have subscriptions to each other's presence information

O「両方」 - ユーザーとの接触の両方がお互いのプレゼンス情報へのサブスクリプションを持っています

Each <item/> element MAY contain a 'name' attribute, which sets the "nickname" to be associated with the JID, as determined by the user (not the contact). The value of the 'name' attribute is opaque.

それぞれの<item />要素は、ユーザ（ない接触）によって決定されるように、JIDに関連付けされる「ニックネーム」を設定する「名前」属性を含んでいてもよいです。「名前」属性の値は不透明です。

Each <item/> element MAY contain one or more <group/> child elements, for use in collecting roster items into various categories. The XML character data of the <group/> element is opaque.

それぞれの<item />要素は、様々なカテゴリに名簿の項目を収集する際に使用するために1つ以上の<グループ/>子要素を含むことができます。 <グループ/>要素のXML文字データは不透明です。

7.2. Business Rules

7.2. ビジネスルール

A server MUST ignore any 'to' address on a roster "set", and MUST treat any roster "set" as applying to the sender. For added safety, a client SHOULD check the "from" address of a "roster push" (incoming IQ of type "set" containing a roster item) to ensure that it is from a trusted source; specifically, the stanza MUST either have no 'from' attribute (i.e., implicitly from the server) or have a 'from' attribute whose value matches the user's bare JID (of the form <user@domain>) or full JID (of the form <user@domain/resource>); otherwise, the client SHOULD ignore the "roster push".

サーバーは、名簿「セット」上のアドレス「から」いずれかを無視しなければならない、と送信者に適用されると任意の名簿「セット」を扱わなければなりません。追加の安全のために、クライアントは、それが信頼できるソースからのものであることを保証するために、「名簿プッシュ」（名簿項目を含む受信IQタイプの「セット」）のアドレス「から」をチェックする必要があります。具体的には、スタンザはMUSTどちらか持っている属性「から」いいえ（すなわち、暗黙的にサーバーから）または属性値が（フォームの<ユーザー@ドメイン>）、ユーザーの裸JIDと一致するか、完全なJID「から」（のを持っていますフォーム<ユーザー@ドメイン/リソース>）;そうでない場合、クライアントは「名簿プッシュ」を無視します。

7.3. Retrieving One's Roster on Login

7.3. ログインにワンの名簿を取得

Upon connecting to the server and becoming an active resource, a client SHOULD request the roster before sending initial presence (however, because receiving the roster may not be desirable for all resources, e.g., a connection with limited bandwidth, the client's request for the roster is OPTIONAL). If an available resource does not request the roster during a session, the server MUST NOT send it presence subscriptions and associated roster updates.

名簿を受信すると、すべてのリソース、例えば、限られた帯域幅に関連して、名簿のためのクライアントの要求のために望ましくないことがあるため、サーバーに接続し、アクティブなリソースになってすると、クライアントは、しかし、（初期の存在を送信する前に名簿を要求する必要があります）はオプションです。使用可能なリソースは、セッション中に名簿を要求していない場合、サーバーはそれをプレゼンスサブスクリプションと関連付けられている名簿の更新を送ってはいけません。

Example: Client requests current roster from server:

例：クライアントがサーバから現在の名簿を要求します。

Example: Client receives roster from server:

例：クライアントがサーバーから名簿を受け取ります。

<iq to='juliet@example.com/balcony' type='result' id='roster_1'> <query xmlns='jabber:iq:roster'> <item jid='romeo@example.net' name='Romeo' subscription='both'> <group>Friends</group> </item> <item jid='mercutio@example.org' name='Mercutio' subscription='from'> <group>Friends</group> </item> <item jid='benvolio@example.org' name='Benvolio' subscription='both'> <group>Friends</group> </item> </query>

<IQのto='juliet@example.com/balcony 'TYPE = '結果' のid = 'roster_1'> <クエリのxmlns = 'おしゃべり：IQ：名簿'> <項目jid='romeo@example.net' NAME =」ロミオ '加入= '両方'> <グループ>友達</グループ> </商品> <商品jid='mercutio@example.org' NAME = 'マーキューシオ' 加入= 'から'> <グループ>友達</グループ> </ item>は<項目jid='benvolio@example.orgの」name = 'ベンヴォリオ' サブスクリプション= '両方'> <グループ>フレンズ</グループ> </ item>の</クエリ>

</iq>

</ IQ>

7.4. Adding a Roster Item

7.4. 名簿項目を追加します

At any time, a user MAY add an item to his or her roster.

いつでも、ユーザーは、彼または彼女の名簿に項目を追加するかもしれません。

Example: Client adds a new item:

例：クライアントは、新しいアイテムを追加します。

<iq from='juliet@example.com/balcony' type='set' id='roster_2'> <query xmlns='jabber:iq:roster'> <item jid='nurse@example.com' name='Nurse'> <group>Servants</group> </item> </query> </iq>

<IQ from='juliet@example.com/balcony 'TYPE = 'セット' のid = 'roster_2'> <クエリのxmlns = 'おしゃべり：IQ：名簿'> <項目jid='nurse@example.com' NAME =」ナース '> <グループ>サーバント</グループ> </ item>の</クエリ> </ IQ>

The server MUST update the roster information in persistent storage, and also push the change out to all of the user's available resources that have requested the roster. This "roster push" consists of an IQ stanza of type "set" from the server to the client and enables all available resources to remain in sync with the server-based roster information.

サーバーは、永続ストレージに名簿情報を更新し、また、名簿を要求した利用者の利用可能なリソースのすべてに変更をプッシュする必要があります。この「名簿プッシュは、」サーバからクライアントへのタイプ「セット」のIQスタンザで構成され、サーバーベースの名簿情報との同期を維持するすべての利用可能なリソースを有効にします。

Example: Server (1) pushes the updated roster information to all available resources that have requested the roster and (2) replies with an IQ result to the sending resource:

例：サーバーは（1）名簿を要求したすべての利用可能なリソースに更新名簿情報をプッシュし、（2）送信リソースにIQ結果を返信：

<iq to='juliet@example.com/balcony' type='set' id='a78b4q6ha463'> <query xmlns='jabber:iq:roster'> <item jid='nurse@example.com' name='Nurse' subscription='none'> <group>Servants</group> </item> </query> </iq>

<IQ to='juliet@example.com/balcony 'TYPE = 'セット' のid = 'a78b4q6ha463'> <クエリのxmlns = 'おしゃべり：IQ：名簿'> <項目jid='nurse@example.com' NAME =」ナース」サブスクリプション= 'なし'> <グループ>サーバント</グループ> </ item>の</クエリ> </ IQ>

<iq to='juliet@example.com/chamber' type='set' id='a78b4q6ha464'> <query xmlns='jabber:iq:roster'> <item jid='nurse@example.com' name='Nurse' subscription='none'> <group>Servants</group>

<IQ to='juliet@example.com/chamber 'TYPE = 'セット' のid = 'a78b4q6ha464'> <クエリのxmlns = 'おしゃべり：IQ：名簿'> <項目jid='nurse@example.com' NAME =」ナース」サブスクリプション= 'なし'> <グループ>サーバント</グループ>

</item> </query> </iq>

</ item>の</クエリ> </ IQ>

As required by the semantics of the IQ stanza kind as defined in [XMPP-CORE], each resource that received the roster push MUST reply with an IQ stanza of type "result" (or "error").

種類として[XMPP-CORE]で定義されたIQスタンザの意味論によって必要とされるよう、名簿プッシュを受信した各リソースは、タイプ「結果」のIQスタンザで応答しなければならない（又は「エラー」）。

Example: Resources reply with an IQ result to the server:

例：リソースがサーバにIQ結果を返信：

<example.comを '= 'へのIQ from='juliet@example.com/balcony' TYPE = '結果' のid = 'a78b4q6ha463 = '例の' /> <たIQ from='juliet@example.com/chamber'。 COM」タイプ= '結果' ID = 'a78b4q6ha464' />

7.5. Updating a Roster Item

7.5. 名簿の項目を更新します

Updating an existing roster item (e.g., changing the group) is done in the same way as adding a new roster item, i.e., by sending the roster item in an IQ set to the server.

既存の名簿項目を更新する（例えば、グループを変更する）サーバにIQセットに名簿項目を送信することによって、すなわち、新しい名簿項目を追加することと同じ方法で行われます。

Example: User updates roster item (added group):

例：ユーザー更新名簿項目（追加グループ）：

<iq from='juliet@example.com/chamber' type='set' id='roster_3'> <query xmlns='jabber:iq:roster'> <item jid='romeo@example.net' name='Romeo' subscription='both'> <group>Friends</group> <group>Lovers</group> </item> </query> </iq>

<IQのfrom='juliet@example.com/chamber 'TYPE = 'セット' のid = 'roster_3'> <クエリのxmlns = 'おしゃべり：IQ：名簿'> <項目jid='romeo@example.net' NAME =」ロミオ」加入= '両方'> <グループ>友達</グループ> <グループ>恋人</グループ> </商品> </クエリ> </ IQ>

As with adding a roster item, when updating a roster item the server MUST update the roster information in persistent storage, and also initiate a roster push to all of the user's available resources that have requested the roster.

名簿の項目を更新する際に名簿項目を追加することと同じように、サーバーは、永続ストレージに名簿情報を更新し、また、名簿を要求した利用者の利用可能なリソースのすべてに名簿のプッシュを開始しなければなりません。

7.6. Deleting a Roster Item

7.6. 名簿の項目を削除します

At any time, a user MAY delete an item from his or her roster by sending an IQ set to the server and making sure that the value of the 'subscription' attribute is "remove" (a compliant server MUST ignore any other values of the 'subscription' attribute when received from a client).

いつでも、ユーザーが（準拠のサーバーは、任意の他の値を無視しなければならないサーバにIQのセットを送信すると「サブスクリプション」属性の値が「削除」であることを確認することで、彼または彼女の名簿から項目を削除してもよいです。クライアントから受信した「サブスクリプション」属性）。

Example: Client removes an item:

例：クライアントがアイテムを削除します。

As with adding a roster item, when deleting a roster item the server MUST update the roster information in persistent storage, initiate a roster push to all of the user's available resources that have requested the roster (with the 'subscription' attribute set to a value of "remove"), and send an IQ result to the initiating resource.

名簿の項目を削除するとき名簿項目を追加することと同じように、サーバーは、永続ストレージに名簿情報を更新する必要があります、値に設定「サブスクリプション」属性を持つ名簿を（要求した利用者の利用可能なリソースのすべてに名簿プッシュを開始「削除」）、および、開始リソースにIQ結果を送信します。

For further information about the implications of this command, see Removing a Roster Item and Cancelling All Subscriptions (Section 8.6).

このコマンドの意味の詳細については、名簿の項目を削除し、すべてのサブスクリプション（8.6節）をキャンセルご覧ください。

8. Integration of Roster Items and Presence Subscriptions

8.名簿項目の統合とプレゼンスサブスクリプション

8.1. Overview

8.1. 概要

Some level of integration between roster items and presence subscriptions is normally expected by an instant messaging user regarding the user's subscriptions to and from other contacts. This section describes the level of integration that MUST be supported within XMPP instant messaging applications.

名簿項目とプレゼンスサブスクリプション間の統合のいくつかのレベルは、通常、他の連絡先にしてから、ユーザのサブスクリプションに関するインスタント・メッセージング・ユーザが期待されます。このセクションでは、XMPPインスタントメッセージングアプリケーション内でサポートしなければならないの統合のレベルを説明しています。

There are four primary subscription states:

4つの主要なサブスクリプションの状態があります。

o None -- the user does not have a subscription to the contact's presence information, and the contact does not have a subscription to the user's presence information

Oなし - ユーザーは、連絡先のプレゼンス情報へのサブスクリプションを持っていないいない、との接触は、ユーザーのプレゼンス情報へのサブスクリプションを持っていません

o To -- the user has a subscription to the contact's presence information, but the contact does not have a subscription to the user's presence information

Oへ - ユーザーが連絡先のプレゼンス情報へのサブスクリプションを持っていますが、連絡先は、ユーザーのプレゼンス情報へのサブスクリプションを持っていません

o From -- the contact has a subscription to the user's presence information, but the user does not have a subscription to the contact's presence information

O - 連絡先は、ユーザーのプレゼンス情報へのサブスクリプションを持っていますが、ユーザーは、連絡先のプレゼンス情報へのサブスクリプションを持っていません

o Both -- both the user and the contact have subscriptions to each other's presence information (i.e., the union of 'from' and 'to')

O両方 - ユーザとの接触の両方がお互いのプレゼンス情報へのサブスクリプションを持っている（すなわち、「に」「から」との組合）

Each of these states is reflected in the roster of both the user and the contact, thus resulting in durable subscription states.

これらの状態の各々は、このように耐久性のあるサブスクリプション状態で、その結果、ユーザとコンタクト両方の名簿に反映されます。

Narrative explanations of how these subscription states interact with roster items in order to complete certain defined use cases are provided in the following sub-sections. Full details regarding server and client handling of all subscription states (including pending states between the primary states listed above) is provided in Subscription States (Section 9).

これらのサブスクリプションの状態は、特定の定義されたユースケースを完了するために名簿の項目と対話する方法の物語説明は以下のサブセクションで提供されています。（上記の主要な状態の間、保留状態を含む）すべてのサブスクリプションの状態のサーバーとクライアントの取り扱いに関する詳細は、サブスクリプションの状態（第9節）で提供されます。

The server MUST NOT send presence subscription requests or roster pushes to unavailable resources, nor to available resources that have not requested the roster.

プレゼンスサブスクリプション要求や名簿を送ってはいけませんサーバーは、名簿を要求していない使用可能なリソースにも、使用できないリソースにプッシュします。

The 'from' and 'to' addresses are OPTIONAL in roster pushes; if included, their values SHOULD be the full JID of the resource for that session. A client MUST acknowledge each roster push with an IQ stanza of type "result" (for the sake of brevity, these stanzas are not shown in the following examples but are required by the IQ semantics defined in [XMPP-CORE]).

「から」とアドレスは名簿プッシュでオプションである「と」;含まれている場合、それらの値は、そのセッションのためのリソースの完全なJIDであるべきです。クライアントは、タイプ「結果」（簡潔にするために、これらのスタンザは、以下の実施例に示されていないが、[XMPP-CORE]で定義されたIQセマンティクスによって必要とされる）のIQスタンザ各名簿プッシュを確認しなければなりません。

8.2. User Subscribes to Contact

8.2. ユーザーは連絡するためにサブスクライブ

The process by which a user subscribes to a contact, including the interaction between roster items and subscription states, is described below.

ユーザが名簿項目と加入状態との間の相互作用を含む、コンタクトをサブスクライブするプロセスは、以下に説明します。

1. In preparation for being able to render the contact in the user's client interface and for the server to keep track of the subscription, the user's client SHOULD perform a "roster set" for the new roster item. This request consists of sending an IQ stanza of type='set' containing a <query/> element qualified by the 'jabber:iq:roster' namespace, which in turn contains an <item/> element that defines the new roster item; the <item/> element MUST possess a 'jid' attribute, MAY possess a 'name' attribute, MUST NOT possess a 'subscription' attribute, and MAY contain one or more <group/> child elements:

1.サブスクリプションを追跡するために、サーバーユーザーのクライアント・インタフェースでとの連絡をレンダリングすることができるというの準備では、ユーザーのクライアントは、新しい名簿項目の「名簿セット」を実行する必要があります。この要求は、=「：IQ：おしゃべり名簿」により修飾<クエリ/>要素を含む「セット」タイプのIQスタンザの送信から成る順に新しい名簿項目を定義する<項目/>要素が含まれている名前空間を、。 <項目/>要素は、「JID」属性を持っていなければならない、「名前」の属性を有することができる、「サブスクリプション」属性を持ってはならない、と1つまたは複数の<group />子要素が含まれる場合があります。

<iq type='set' id='set1'> <query xmlns='jabber:iq:roster'> <item jid='contact@example.org' name='MyContact'> <group>MyBuddies</group> </item> </query> </iq>

<IQタイプ= 'セット' ID = 'SET1'> <クエリのxmlns = 'おしゃべり：IQ：名簿'> <項目jid='contact@example.org」NAME = 'MyContact'> <グループ> MyBuddies </グループ> </ item>の</クエリ> </ IQ>

2. As a result, the user's server (1) MUST initiate a roster push for the new roster item to all available resources associated with this user that have requested the roster, setting the 'subscription' attribute to a value of "none"; and (2) MUST reply to the sending resource with an IQ result indicating the success of the roster set:

2.その結果、ユーザーのサーバーは、（1）「なし」の値に「サブスクリプション」属性を設定し、名簿を要求してきた、このユーザーに関連付けられているすべての利用可能なリソースへの新しい名簿項目の名簿プッシュを開始しなければなりません。（2）名簿セットの成功を示すIQ結果に送信リソースに返信しなければなりません。

<iq type='set'> <query xmlns='jabber:iq:roster'> <item jid='contact@example.org' subscription='none' name='MyContact'> <group>MyBuddies</group> </item> </query> </iq>

<IQタイプ= '設定'> <クエリのxmlns = 'ジャバー：IQ：名簿'> <項目jid='contact@example.org」サブスクリプション= 'なしの' name = 'MyContact'> <グループ> MyBuddies </グループ> </ item>の</クエリ> </ IQ>

<IQタイプ= '結果' ID = 'SET1' />

3. If the user wants to request a subscription to the contact's presence information, the user's client MUST send a presence stanza of type='subscribe' to the contact:

3.ユーザーは、ユーザーのクライアントが連絡先に「購読」=タイプの存在スタンザを送らなければなりません、連絡先のプレゼンス情報へのサブスクリプションを要求したい場合：

<プレゼンスto='contact@example.org」タイプ= '' /サブスクライブ>

4. As a result, the user's server MUST initiate a second roster push to all of the user's available resources that have requested the roster, setting the contact to the pending sub-state of the 'none' subscription state; this pending sub-state is denoted by the inclusion of the ask='subscribe' attribute in the roster item:

4.その結果、ユーザーのサーバーは、「なし」のサブスクリプション状態の保留サブ状態への接触を設定し、名簿を要求した利用者の利用可能なリソースのすべてに二名簿プッシュを開始しなければなりません。この保留中のサブ状態は、名簿の項目に「サブスクライブ」=尋ねる属性を含めることによって示されます。

<iq type='set'> <query xmlns='jabber:iq:roster'> <item jid='contact@example.org' subscription='none' ask='subscribe' name='MyContact'> <group>MyBuddies</group> </item> </query> </iq>

<IQタイプ= '設定'> <クエリのxmlns = 'ジャバー：IQ：名簿'> <項目jid='contact@example.org」サブスクリプション= 'なし 'の名前を= '購読' =尋ねる' MyContact'> <グループ> MyBuddies </グループ> </ item>の</クエリ> </ IQ>

Note: If the user did not create a roster item before sending the subscription request, the server MUST now create one on behalf of the user, then send a roster push to all of the user's available resources that have requested the roster, absent the 'name' attribute and the <group/> child shown above.

注意：ユーザーがサブスクリプション要求を送信する前に名簿項目を作成しなかった場合、サーバは今、その後の名簿を要求しているユーザーの利用可能なリソースのすべてに名簿プッシュを送って、ユーザーの代わりに1を作成する必要があり、存在しません "名前」属性と上図の<グループ/>子。

5. The user's server MUST also stamp the presence stanza of type "subscribe" with the user's bare JID (i.e., <user@example.com>) as the 'from' address (if the user provided a 'from' address set to the user's full JID, the server SHOULD remove the resource identifier). If the contact is served by a different host than the user, the user's server MUST route the presence stanza to the contact's server for delivery to the contact (this case is assumed throughout; however, if the contact is served by the same host, then the server can simply deliver the presence stanza directly):

ユーザーが設定「から」アドレスを提供されている場合5.利用者のサーバーは、（アドレス「から」として、ユーザの裸JID（すなわち、<user@example.com>）で「購読」タイプの存在スタンザをスタンプしなければなりませんユーザーの完全なJID、サーバーは）リソース識別子を削除する必要があります。接触は、ユーザ、ユーザのサーバMUST経路コンタクトへの送達のための連絡先のサーバにプレゼンススタンザは異なるホストによってサービスされている場合（この場合は全体想定されるが、コンタクトが同じホストによってサービスされている場合、次いでサーバーは、単純に）直接プレゼンススタンザを提供することができます：

<プレゼンスfrom='user@example.com 'to='contact@example.org' タイプ= '購読' />

Note: If the user's server receives a presence stanza of type "error" from the contact's server, it MUST deliver the error stanza to the user, whose client MAY determine that the error is in response to the outgoing presence stanza of type "subscribe" it sent previously (e.g., by tracking an 'id' attribute) and then choose to resend the "subscribe" request or revert the roster to its previous state by sending a presence stanza of type "unsubscribe" to the contact.

注意：ユーザーのサーバーは、連絡先のサーバーからタイプ「エラー」の存在スタンザを受信した場合、それはユーザーにエラースタンザを提供しなければならない、そのクライアントにエラーがタイプの出存在スタンザに反応していることを決定することができる「購読」それは以前に送られた（例えば、「ID」属性を追跡することによって）、その後、「サブスクライブ」要求を再送信するか、連絡先にタイプ「退会」の存在スタンザを送信することにより、その前の状態に名簿を元に戻すことを選択します。

6. Upon receiving the presence stanza of type "subscribe" addressed to the contact, the contact's server MUST determine if there is at least one available resource from which the contact has requested the roster. If so, it MUST deliver the subscription request to the contact (if not, the contact's server MUST store the subscription request offline for delivery when this condition is next met; normally this is done by adding a roster item for the contact to the user's roster, with a state of "None + Pending In" as defined under Subscription States (Section 9), however a server SHOULD NOT push or deliver roster items in that state to the contact). No matter when the subscription request is delivered, the contact must decide whether or not to approve it (subject to the contact's configured preferences, the contact's client MAY approve or refuse the subscription request without presenting it to the contact). Here we assume the "happy path" that the contact approves the subscription request (the alternate flow of declining the subscription request is defined in Section 8.2.1). In this case, the contact's client (1) SHOULD perform a roster set specifying the desired nickname and group for the user (if any); and (2) MUST send a presence stanza of type "subscribed" to the user in order to approve the subscription request.

接触が名簿を要求したから少なくとも1つの利用可能なリソースがある場合、「購読」タイプの存在スタンザを受け取る6.接触宛、連絡先のサーバを決定しなければなりません。もしそうなら、それがない場合、この条件は次の満たされたときに、連絡先のサーバが配信のためのサブスクリプション要求をオフラインを保存しなければなりません（連絡先へのサブスクリプション要求を提供しなければなりません。通常、これは、ユーザの名簿への連絡先の名簿項目を追加することによって行われますサブスクリプションの状態（第9条）の下で定義されるように、「なし+保留中」の状態で、しかしサーバが連絡先にその状態で名簿項目を押すか、届けるべきではありません）。サブスクリプション要求が配信さに関係なく、連絡先は（連絡先のクライアントが連絡先にそれを提示することなく、サブスクリプション要求を承認または拒否することができ、連絡先のように構成好みに応じて）それを承認するか否かを決定する必要があります。ここでは、接触は、サブスクリプション要求（サブスクリプション要求を減少する別の流れ8.2.1項で定義されている）を承認する「ハッピーパス」を前提としています。この場合には、連絡先のクライアントは、（1）ユーザ（もしあれば）のための所望のニックネームとグループを指定名簿セットを実行しなければなりません。（2）サブスクリプション要求を承認するために、ユーザにタイプ「サブスクライブ」の存在スタンザを送らなければなりません。

<iq type='set' id='set2'> <query xmlns='jabber:iq:roster'> <item jid='user@example.com' name='SomeUser'> <group>SomeGroup</group> </item> </query> </iq>

<IQタイプ= 'セット' ID = 'SET2'> <クエリのxmlns = 'おしゃべり：IQ：名簿'> <項目jid='user@example.com」NAME = 'SomeUser'> <グループ> SomeGroup </グループ> </ item>の</クエリ> </ IQ>

<プレゼンスto='user@example.com」TYPE = '加入/>

7. As a result, the contact's server (1) MUST initiate a roster push to all available resources associated with the contact that have requested the roster, containing a roster item for the user with the subscription state set to 'from' (the server MUST send this even if the contact did not perform a roster set); (2) MUST return an IQ result to the sending resource indicating the success of the roster set; (3) MUST route the presence stanza of type "subscribed" to the user, first stamping the 'from' address as the bare JID (<contact@example.org>) of the contact; and (4) MUST send available presence from all of the contact's available resources to the user:

7.その結果、連絡先のサーバは、（1）「から」に設定加入状態を持つユーザ（サーバ用の名簿項目を含む、名簿を要求している連絡先に関連付けられたすべての利用可能なリソースに名簿プッシュを開始しなければなりません接触が）名簿セットを実行しなかった場合でも、これを送らなければなりません。（2）名簿セットの成功を示す送信リソースにIQ結果を返さなければなりません。（3）ユーザにMUSTルートタイプの存在スタンザ「購読」を、最初の接触の裸JID（<contact@example.org>）としてアドレス「から」スタンピング。（4）利用者への連絡先の利用可能なリソースのすべてから利用できる存在を送らなければなりません。

<iq type='set' to='contact@example.org/resource'> <query xmlns='jabber:iq:roster'> <item jid='user@example.com' subscription='from' name='SomeUser'> <group>SomeGroup</group> </item> </query> </iq>

<IQタイプ= 'セット' to='contact@example.org/resource '> <クエリのxmlns =' ジャバー：IQ：名簿 '> =」名 'から'<項目jid='user@example.com' サブスクリプション= SomeUser '> <グループ> SomeGroup </グループ> </ item>の</クエリ> </ IQ>

<IQタイプ「ID = 'SET2' to='contact@example.org/resource = '結果' />

<プレゼンスfrom='contact@example.org 'to='user@example.com' TYPE = '加入' />

<プレゼンスfrom='contact@example.org/resource 'to='user@example.com' />

Note: If the contact's server receives a presence stanza of type "error" from the user's server, it MUST deliver the error stanza to the contact, whose client MAY determine that the error is in response to the outgoing presence stanza of type "subscribed" it sent previously (e.g., by tracking an 'id' attribute) and then choose to resend the "subscribed" notification or revert the roster to its previous state by sending a presence stanza of type "unsubscribed" to the user.

注意：連絡先のサーバーは、ユーザーのサーバーからタイプ「エラー」の存在スタンザを受信した場合、それは、そのクライアントにエラーがタイプ「サブスクライブ」の送信プレゼンススタンザに反応していることを決定することができる連絡先に誤りスタンザを提供しなければなりませんそれは、以前に送信された（例えば、「ID」属性を追跡することによって）、次いで「購読」の通知を再送するか、ユーザにタイプ「解除」の存在スタンザを送信することにより、その前の状態に名簿を元に戻すことを選択します。

8. Upon receiving the presence stanza of type "subscribed" addressed to the user, the user's server MUST first verify that the contact is in the user's roster with either of the following states: (a) subscription='none' and ask='subscribe' or (b) subscription='from' and ask='subscribe'. If the contact is not in the user's roster with either of those states, the user's server MUST silently ignore the presence stanza of type "subscribed" (i.e., it MUST NOT route it to the user, modify the user's roster, or generate a roster push to the user's available resources). If the contact is in the user's roster with either of those states, the user's server (1) MUST deliver the presence stanza of type "subscribed" from the contact to the user; (2) MUST initiate a roster push to all of the user's available resources that have requested the roster, containing an updated roster item for the contact with the 'subscription' attribute set to a value of "to"; and (3) MUST deliver the available presence stanza received from each of the contact's available resources to each of the user's available resources:

タイプの存在スタンザを受信する8.ユーザ宛の「購読」、ユーザのサーバは、前記第1コンタクトは、以下の状態のいずれかとのユーザの名簿であることを確認しなければならない：（A）加入=「なし」と「=尋ねます購読」または（b）のサブスクリプション= 『から』と尋ねる= 『』購読します。接触はそれらの状態のいずれかで、ユーザの名簿にない場合は、ユーザーのサーバは黙って（「サブスクライブ」タイプの存在スタンザを無視しなければなりませんつまり、それは利用者の名簿を変更したり、名簿を生成し、ユーザーへのルートにそれをしないMUST ）は、ユーザーの利用可能なリソースにプッシュ。接触は、これらの状態のいずれかとのユーザの名簿にある場合、ユーザのサーバ（1）ユーザの接触から「購読」タイプの存在スタンザを供給しなければなりません。（2）「へ」の値に設定する「サブスクリプション」属性との接触のために更新名簿項目を含む、名簿を要求した利用者の利用可能なリソースのすべてに名簿のプッシュを開始しなければなりません。（3）スタンザユーザの利用可能なリソースのそれぞれに連絡先の利用可能なリソースのそれぞれから受信した利用可能なプレゼンスを提供しなければなりません。

<プレゼンスto='user@example.com 'from='contact@example.org' TYPE = '加入' />

<iq type='set'> <query xmlns='jabber:iq:roster'> <item jid='contact@example.org' subscription='to' name='MyContact'> <group>MyBuddies</group> </item> </query> </iq>

<IQタイプ= '設定'> <クエリのxmlns = 'ジャバー：IQ：名簿'> <項目jid='contact@example.org」サブスクリプション= '' 名= 'MyContact' へ> <グループ> MyBuddies </グループ> </ item>の</クエリ> </ IQ>

<プレゼンスfrom='contact@example.org/resource 'to='user@example.com/resource' />

9. Upon receiving the presence stanza of type "subscribed", the user SHOULD acknowledge receipt of that subscription state notification through either "affirming" it by sending a presence stanza of type "subscribe" to the contact or "denying" it by sending a presence stanza of type "unsubscribe" to the contact; this step does not necessarily affect the subscription state (see Subscription States (Section 9) for details), but instead lets the user's server know that it MUST no longer send notification of the subscription state change to the user (see Section 9.4).

タイプの存在スタンザ「サブスクライブ」を受信すると、ユーザーが連絡先に「購読する」タイプの存在スタンザを送信または送信することによって、それを「否定」で、それを「肯定」のいずれかを介してそのサブスクリプションの状態通知の受領を確認すべきである9。連絡先に「退会」タイプの存在スタンザ。このステップは、必ずしも（詳細については、サブスクリプションの状態（第9節）を参照）、サブスクリプションの状態に影響を与えるが、その代わりに、ユーザーのサーバーは、それがもはや（9.4節を参照）ユーザーにサブスクリプションの状態変化の通知を送ってはならないことを知ることができますしません。

From the perspective of the user, there now exists a subscription to the contact's presence information; from the perspective of the contact, there now exists a subscription from the user.

ユーザの観点からは、今連絡先のプレゼンス情報へのサブスクリプションが存在します。接触の観点から、これで、ユーザーからのサブスクリプションが存在します。

8.2.1. Alternate Flow: Contact Declines Subscription Request

8.2.1. 代替フロー：連絡先が登録要請を辞退

The above activity flow represents the "happy path" regarding the user's subscription request to the contact. The main alternate flow occurs if the contact refuses the user's subscription request, as described below.

上記の活動の流れは、連絡先へのユーザのサブスクリプション要求に関する「ハッピーパス」を表しています。以下に説明するように接触が、ユーザのサブスクリプション要求を拒否した場合、メインの代替フローが生じます。

1. If the contact wants to refuse the request, the contact's client MUST send a presence stanza of type "unsubscribed" to the user (instead of the presence stanza of type "subscribed" sent in Step 6 of Section 8.2):

1.連絡先が要求を拒否したい場合は、連絡先のクライアントは、ユーザーに「解除」（8.2節のステップ6で送信された代わりに、タイプの存在スタンザの「サブスクライブを」）タイプの存在スタンザを送らなければなりません。

<プレゼンスto='user@example.com」TYPE = '解除' />

2. As a result, the contact's server MUST route the presence stanza of type "unsubscribed" to the user, first stamping the 'from' address as the bare JID (<contact@example.org>) of the contact:

結果2、第スタンピングコンタクトのサーバーMUSTルートユーザに「解除」型の存在スタンザ、裸JID（<contact@example.org>）接触のようなアドレス「から」：

<プレゼンスfrom='contact@example.org 'to='user@example.com' TYPE = '解除' />

Note: If the contact's server previously added the user to the contact's roster for tracking purposes, it MUST remove the relevant item at this time.

注意：連絡先のサーバーが以前追跡の目的のために、連絡先の名簿にユーザーを追加した場合、それはこの時点で該当する項目を削除する必要があります。

3. Upon receiving the presence stanza of type "unsubscribed" addressed to the user, the user's server (1) MUST deliver that presence stanza to the user and (2) MUST initiate a roster push to all of the user's available resources that have requested the roster, containing an updated roster item for the contact with the 'subscription' attribute set to a value of "none" and with no 'ask' attribute:

「解除」型の存在スタンザを受け取る3.ユーザ宛の、ユーザのサーバは、（1）ユーザーにそのプレゼンススタンザを供給しなければならない、（2）要求されたそのユーザの利用可能なリソースの全てに名簿プッシュを開始しなければなりません「なし」の値にし、no「を尋ねる」属性を設定する「サブスクリプション」属性との接触のために更新名簿項目を含む名簿、：

<プレゼンスfrom='contact@example.org 'to='user@example.com' TYPE = '解除' />

<iq type='set'> <query xmlns='jabber:iq:roster'> <item jid='contact@example.org' subscription='none' name='MyContact'> <group>MyBuddies</group> </item> </query> </iq>

4. Upon receiving the presence stanza of type "unsubscribed", the user SHOULD acknowledge receipt of that subscription state notification through either "affirming" it by sending a presence stanza of type "unsubscribe" to the contact or "denying" it by sending a presence stanza of type "subscribe" to the contact; this step does not necessarily affect the subscription state (see Subscription States (Section 9) for details), but instead lets the user's server know that it MUST no longer send notification of the subscription state change to the user (see Section 9.4).

「解除」型の存在スタンザを受信すると、ユーザが連絡先に「解除」型の存在スタンザを送信または送信することによって、それを「否定」によってそれを「肯定」のいずれかを介してその加入状態通知の受信を確認すべきである4。連絡先に「購読する」タイプの存在スタンザ。このステップは、必ずしも（詳細については、サブスクリプションの状態（第9節）を参照）、サブスクリプションの状態に影響を与えるが、その代わりに、ユーザーのサーバーは、それがもはや（9.4節を参照）ユーザーにサブスクリプションの状態変化の通知を送ってはならないことを知ることができますしません。

As a result of this activity, the contact is now in the user's roster with a subscription state of "none", whereas the user is not in the contact's roster at all.

ユーザーがまったく接触者の名簿にないのに対し、この活動の結果として、接触は、「なし」のサブスクリプションの状態で、ユーザの名簿になりました。

8.3. Creating a Mutual Subscription

8.3. 相互スクリプションを作成します

The user and contact can build on the "happy path" described above to create a mutual subscription (i.e., a subscription of type "both"). The process is described below.

ユーザとの接触は、相互のサブスクリプション（「両方」タイプの、すなわち、サブスクリプション）を作成するために、上述した「ハッピーパス」上に構築することができます。プロセスは以下の通りです。

1. If the contact wants to create a mutual subscription, the contact MUST send a subscription request to the user (subject to the contact's configured preferences, the contact's client MAY send this automatically):

1.接触は、相互サブスクリプションを作成したい場合は、連絡先は（連絡先のクライアントはこれを自動的に送信し、連絡先のように構成好みに応じて）ユーザーにサブスクリプション要求を送らなければなりません。

<プレゼンスto='user@example.com」タイプ= '' /サブスクライブ>

2. As a result, the contact's server (1) MUST initiate a roster push to all available resources associated with the contact that have requested the roster, with the user still in the 'from' subscription state but with a pending 'to' subscription denoted by the inclusion of the ask='subscribe' attribute in the roster item; and (2) MUST route the presence stanza of type "subscribe" to the user, first stamping the 'from' address as the bare JID (<contact@example.org>) of the contact:

その結果、2、連絡先のサーバー（1）まだサブスクリプション「に」「から」サブスクリプションの状態ではなく、保留中でユーザーと、名簿を要求した連絡先に関連するすべての利用可能なリソースへの名簿のプッシュを開始しなければなりません=尋ねる名簿項目内の属性を「購読」を含めることによって示されます。：（2）MUSTルートタイプの存在スタンザは、前記第1コンタクトの裸JID（<contact@example.org>）としてアドレス「から」スタンピング、ユーザに「購読します」

<iq type='set'> <query xmlns='jabber:iq:roster'> <item jid='user@example.com' subscription='from' ask='subscribe' name='SomeUser'> <group>SomeGroup</group> </item> </query> </iq>

<IQタイプ= '設定'> <クエリのxmlns = 'ジャバー：IQ：名簿'> <項目jid='user@example.com」サブスクリプション= 'から' 頼む= 'サブスクライブの' name = 'SomeUser'> <グループ> SomeGroup </グループ> </ item>の</クエリ> </ IQ>

<プレゼンスfrom='contact@example.org 'to='user@example.com' タイプ= '購読' />

Note: If the contact's server receives a presence stanza of type "error" from the user's server, it MUST deliver the error stanza to the contact, whose client MAY determine that the error is in response to the outgoing presence stanza of type "subscribe" it sent previously (e.g., by tracking an 'id' attribute) and then choose to resend the "subscribe" request or revert the roster to its previous state by sending a presence stanza of type "unsubscribe" to the user.

注意：連絡先のサーバーは、ユーザーのサーバーからタイプ「エラー」の存在スタンザを受信した場合、それはエラーが「購読する」タイプの送信プレゼンススタンザに反応していることを決定することができるそのクライアント接触にエラースタンザを提供しなければなりませんそれは以前に送られた（例えば、「ID」属性を追跡することによって）、その後、「サブスクライブ」要求を再送信したり、ユーザーにタイプ「退会」の存在スタンザを送信することにより、その前の状態に名簿を元に戻すことを選択します。

3. Upon receiving the presence stanza of type "subscribe" addressed to the user, the user's server must determine if there is at least one available resource for which the user has requested the roster. If so, the user's server MUST deliver the subscription request to the user (if not, it MUST store the subscription request offline for delivery when this condition is next met). No matter when the subscription request is delivered, the user must then decide whether or not to approve it (subject to the user's configured preferences, the user's client MAY approve or refuse the subscription request without presenting it to the user). Here we assume the "happy path" that the user approves the subscription request (the alternate flow of declining the subscription request is defined in Section 8.3.1). In this case, the user's client MUST send a presence stanza of type "subscribed" to the contact in order to approve the subscription request.

タイプの存在スタンザを受信する3.「サブスクライブ」ユーザ宛のユーザーが名簿を要求したために、少なくとも1つの利用可能なリソースがある場合は、ユーザーのサーバーを決定する必要があります。そう、ユーザーのサーバーは、ユーザーへのサブスクリプション要求を提供しなければならない場合には（ない場合は、この条件は次の満たされたとき、それは配達のためにオフラインサブスクリプション要求を保存しなければなりません）。サブスクリプション要求が配信さに関係なく、ユーザーは、（ユーザーのクライアントは、ユーザーにそれを提示することなく、サブスクリプション要求を承認または拒否することができ、ユーザーの設定済みの好みに応じて）それを承認するか否かを決定する必要があります。ここでは、ユーザは、サブスクリプション要求（サブスクリプション要求を減少する別の流れ8.3.1項で定義されている）を承認する「ハッピーパス」を前提としています。この場合、ユーザーのクライアントは、サブスクリプション要求を承認するために、連絡先にタイプ「サブスクライブ」の存在スタンザを送らなければなりません。

<プレゼンスto='contact@example.org」TYPE = '加入/>

4. As a result, the user's server (1) MUST initiate a roster push to all of the user's available resources that have requested the roster, containing a roster item for the contact with the 'subscription' attribute set to a value of "both"; (2) MUST route the presence stanza of type "subscribed" to the contact, first stamping the 'from' address as the bare JID (<user@example.com>) of the user; and (3) MUST send to the contact the full XML of the last presence stanza with no 'to' attribute received by the server from each of the user's available resources (subject to privacy lists in force for each session):

4.その結果、ユーザーのサーバーは、（1）の両方「の値に設定する「サブスクリプション」属性との接触のために名簿の項目を含む、名簿を要求した利用者の利用可能なリソースのすべてに名簿のプッシュを開始しなければなりません「; （2）接触にMUSTルートタイプの存在スタンザ「購読」を、第1ユーザの裸JID（<user@example.com>）としてアドレス「から」スタンピング。（3）利用者の利用可能なリソース（各セッションのための力のプライバシーリストの対象）のそれぞれから、サーバーが受信した属性「に」連絡先に無いとの最後のプレゼンススタンザの完全なXMLを送らなければなりません。

<iq type='set'> <query xmlns='jabber:iq:roster'> <item jid='contact@example.org' subscription='both' name='MyContact'> <group>MyBuddies</group> </item> </query> </iq>

<IQタイプ= '設定'> <クエリのxmlns = 'ジャバー：IQ：名簿'> <項目jid='contact@example.org」サブスクリプション= '' の両方の名前= 'MyContact'> <グループ> MyBuddies </グループ> </ item>の</クエリ> </ IQ>

<プレゼンスfrom='user@example.com 'to='contact@example.org' TYPE = '加入' />

<プレゼンスfrom='user@example.com/resource 'to='contact@example.org' />

Note: If the user's server receives a presence stanza of type "error" from the contact's server, it MUST deliver the error stanza to the user, whose client MAY determine that the error is in response to the outgoing presence stanza of type "subscribed" it sent previously (e.g., by tracking an 'id' attribute) and then choose to resend the subscription request or revert the roster to its previous state by sending a presence stanza of type "unsubscribed" to the contact.

注：ユーザーのサーバーは、連絡先のサーバーからタイプ「エラー」の存在スタンザを受信した場合、それは、そのクライアントにエラーがタイプ「サブスクライブ」の送信プレゼンススタンザに反応していることを決定することができるユーザにエラースタンザを提供しなければなりませんそれは以前に送られた（例えば、「ID」属性を追跡することによって）、その後、サブスクリプション要求を再送信するか、連絡先にタイプ「解除」の存在スタンザを送信することにより、その前の状態に名簿を元に戻すことを選択します。

5. Upon receiving the presence stanza of type "subscribed" addressed to the contact, the contact's server MUST first verify that the user is in the contact's roster with either of the following states: (a) subscription='none' and ask='subscribe' or (b) subscription='from' and ask='subscribe'. If the user is not in the contact's roster with either of those states, the contact's server MUST silently ignore the presence stanza of type "subscribed" (i.e., it MUST NOT route it to the contact, modify the contact's roster, or generate a roster push to the contact's available resources). If the user is in the contact's roster with either of those states, the contact's server (1) MUST deliver the presence stanza of type "subscribed" from the user to the contact; (2) MUST initiate a roster push to all available resources associated with the contact that have requested the roster, containing an updated roster item for the user with the 'subscription' attribute set to a value of "both"; and (3) MUST deliver the available presence stanza received from each of the user's available resources to each of the contact's available resources:

「（a）は、サブスクリプション=「なし」と尋ねる=：「サブスクライブ」タイプの存在スタンザを受け取ると5.は、連絡先のサーバは、最初のユーザーが次の状態のいずれかで連絡先の名簿であることを確かめなければなりません連絡先宛購読」または（b）のサブスクリプション= 『から』と尋ねる= 『』購読します。ユーザーは、それらの状態のいずれかと接触者の名簿にない場合は、連絡先のサーバは黙って（「サブスクライブ」タイプの存在スタンザを無視しなければならない、すなわち、それは、連絡先の名簿を変更したり、名簿を生成し、接触へのルートにそれをしないMUST ）連絡先の利用可能なリソースにプッシュ。ユーザが連絡先のサーバ、それらの状態のいずれかと接触者名簿にある場合、（1）利用者から連絡先に「加入」タイプの存在スタンザを供給しなければなりません。（2）「のサブスクリプション」、「両方」の値に設定された属性とユーザの更新名簿項目を含む、名簿を要求している連絡先に関連付けられたすべての利用可能なリソースに名簿プッシュを開始しなければなりません。（3）スタンザ連絡先の利用可能なリソースのそれぞれにユーザの利用可能なリソースのそれぞれから受信した利用可能なプレゼンスを提供しなければなりません。

<プレゼンスfrom='user@example.com 'to='contact@example.org' TYPE = '加入' />

<iq type='set'> <query xmlns='jabber:iq:roster'> <item jid='user@example.com' subscription='both' name='SomeUser'> <group>SomeGroup</group> </item> </query> </iq>

<IQタイプ= '設定'> <クエリのxmlns = 'ジャバー：IQ：名簿'> <項目jid='user@example.com」サブスクリプション= '' の両方の名前= 'SomeUser'> <グループ> SomeGroup </グループ> </ item>の</クエリ> </ IQ>

<プレゼンスfrom='user@example.com/resource 'to='contact@example.org/resource' />

6. Upon receiving the presence stanza of type "subscribed", the contact SHOULD acknowledge receipt of that subscription state notification through either "affirming" it by sending a presence stanza of type "subscribe" to the user or "denying" it by sending a presence stanza of type "unsubscribe" to the user; this step does not necessarily affect the subscription state (see Subscription States (Section 9) for details), but instead lets the contact's server know that it MUST no longer send notification of the subscription state change to the contact (see Section 9.4).

タイプの存在スタンザ「購読」を受信すると、コンタクトがユーザに「購読」タイプの存在スタンザを送信または送信することによって、それを「否定」によってそれを「肯定」のいずれかを介してその加入状態通知の受信を確認すべきである6。ユーザーに「退会」タイプの存在スタンザ。このステップは、必ずしも（詳細については、サブスクリプションの状態（第9節）を参照）、サブスクリプションの状態に影響を与えるが、その代わりに、連絡先のサーバが、それはもはや（9.4節を参照してください）連絡先にサブスクリプションの状態変化の通知を送ってはならないことを知ることができますしません。

The user and the contact now have a mutual subscription to each other's presence -- i.e., the subscription is of type "both".

ユーザーとの接触は今、お互いの存在に相互のサブスクリプションを持っている - すなわち、サブスクリプションがタイプである「両方」。

8.3.1. Alternate Flow: User Declines Subscription Request

8.3.1. 代替フロー：ユーザーが登録要請を辞退

The above activity flow represents the "happy path" regarding the contact's subscription request to the user. The main alternate flow occurs if the user refuses the contact's subscription request, as described below.

上記の活動の流れは、ユーザーへの連絡先のサブスクリプション要求に関する「ハッピーパス」を表しています。以下に説明するように、ユーザは、連絡先のサブスクリプション要求を拒否した場合、メインの代替フローが生じます。

1. If the user wants to refuse the request, the user's client MUST send a presence stanza of type "unsubscribed" to the contact (instead of the presence stanza of type "subscribed" sent in Step 3 of Section 8.3):

1.利用者が要求を拒否したい場合には、ユーザーのクライアントは、連絡先（8.3節の手順3で送信された代わりに、タイプの存在スタンザの「サブスクライブ」）に「解除」タイプの存在スタンザを送らなければなりません。

<プレゼンスto='contact@example.org」TYPE = '解除' />

2. As a result, the user's server MUST route the presence stanza of type "unsubscribed" to the contact, first stamping the 'from' address as the bare JID (<user@example.com>) of the user:

結果2.ユーザのサーバMUSTルートタイプの存在スタンザ接点を「解除」、第1ユーザの裸JID（<user@example.com>）としてアドレス「から」をスタンピング。

<プレゼンスfrom='user@example.com 'to='contact@example.org' TYPE = '解除' />

3. Upon receiving the presence stanza of type "unsubscribed" addressed to the contact, the contact's server (1) MUST deliver that presence stanza to the contact; and (2) MUST initiate a roster push to all available resources associated with the contact that have requested the roster, containing an updated roster item for the user with the 'subscription' attribute set to a value of "from" and with no 'ask' attribute:

「解除」型の存在スタンザを受け取る3.接触宛、コンタクトへのプレゼンススタンザを供給しなければならない連絡先のサーバ（1）。（2）「から」の値にし、no「を尋ねると設定「サブスクリプション」属性を持つユーザのために更新名簿項目を含む、名簿を要求した連絡先に関連するすべての利用可能なリソースへの名簿のプッシュを開始しなければなりません'属性：

<プレゼンスfrom='user@example.com 'to='contact@example.org' TYPE = '解除' />

<iq type='set'> <query xmlns='jabber:iq:roster'> <item jid='user@example.com' subscription='from' name='SomeUser'> <group>SomeGroup</group> </item> </query> </iq>

<IQタイプ= '設定'> <クエリのxmlns = 'ジャバー：IQ：名簿'> <項目jid='user@example.com」サブスクリプション= 'からの' name = 'SomeUser'> <グループ> SomeGroup </グループ> </ item>の</クエリ> </ IQ>

4. Upon receiving the presence stanza of type "unsubscribed", the contact SHOULD acknowledge receipt of that subscription state notification through either "affirming" it by sending a presence stanza of type "unsubscribe" to the user or "denying" it by sending a presence stanza of type "subscribe" to the user; this step does not necessarily affect the subscription state (see Subscription States (Section 9) for details), but instead lets the contact's server know that it MUST no longer send notification of the subscription state change to the contact (see Section 9.4).

「解除」型の存在スタンザを受信すると、連絡先がユーザに「解除」型の存在スタンザを送信または送信することによって、それを「否定」によってそれを「肯定」のいずれかを介してその加入状態通知の受信を確認すべきである4。ユーザーに「購読する」タイプの存在スタンザ。このステップは、必ずしも（詳細については、サブスクリプションの状態（第9節）を参照）、サブスクリプションの状態に影響を与えるが、その代わりに、連絡先のサーバが、それはもはや（9.4節を参照してください）連絡先にサブスクリプションの状態変化の通知を送ってはならないことを知ることができますしません。

As a result of this activity, there has been no change in the subscription state; i.e., the contact is in the user's roster with a subscription state of "to" and the user is in the contact's roster with a subscription state of "from".

この活動の結果として、サブスクリプションの状態に変化がなかったです。即ち、接触「へ」の加入状態とのユーザの名簿であり、ユーザは、「から」の加入状態との接触の名簿です。

8.4. Unsubscribing

8.4. 退会

At any time after subscribing to a contact's presence information, a user MAY unsubscribe. While the XML that the user sends to make this happen is the same in all instances, the subsequent subscription state is different depending on the subscription state obtaining when the unsubscribe "command" is sent. Both possible scenarios are described below.

連絡先のプレゼンス情報をサブスクライブした後、任意の時点で、ユーザーが退会してもよい（MAY）。ユーザーはこれを実現するために送信XMLは、すべてのインスタンスで同じですが、その後のサブスクリプションの状態が配信停止「コマンドが」送信されたときに取得するサブスクリプションの状態に応じて異なっています。どちらの可能なシナリオは、以下に記載されています。

8.4.1. Case #1: Unsubscribing When Subscription is Not Mutual

8.4.1. ケース＃1：契約は相互されていない場合は退会

In the first case, the user has a subscription to the contact's presence information but the contact does not have a subscription to the user's presence information (i.e., the subscription is not yet mutual).

最初のケースでは、ユーザは、連絡先のプレゼンス情報へのサブスクリプションを持っているが、接触（すなわち、サブスクリプションがまだ相互ない）ユーザのプレゼンス情報へのサブスクリプションを持っていません。

1. If the user wants to unsubscribe from the contact's presence information, the user MUST send a presence stanza of type "unsubscribe" to the contact:

1.ユーザーは、ユーザーが連絡先に「退会」タイプの存在スタンザを送らなければなりません、連絡先のプレゼンス情報の購読を解除したい場合：

<プレゼンスto='contact@example.org」TYPE = '解除' />

2. As a result, the user's server (1) MUST send a roster push to all of the user's available resources that have requested the roster, containing an updated roster item for the contact with the 'subscription' attribute set to a value of "none"; and (2) MUST route the presence stanza of type "unsubscribe" to the contact, first stamping the 'from' address as the bare JID (<user@example.com>) of the user:

2.その結果、ユーザーのサーバーは、（1） "の値に設定する「サブスクリプション」属性との接触のために更新名簿項目を含む、名簿を要求した利用者の利用可能なリソースのすべてに名簿プッシュを送らなければなりません無し"; （2）MUSTルートタイプの存在スタンザ接点を「解除」、第1ユーザの裸JID（<user@example.com>）としてアドレス「から」スタンピング。

<iq type='set'> <query xmlns='jabber:iq:roster'> <item jid='contact@example.org' subscription='none' name='MyContact'> <group>MyBuddies</group> </item> </query> </iq>

<プレゼンスfrom='user@example.com 'to='contact@example.org' TYPE = '解除' />

3. Upon receiving the presence stanza of type "unsubscribe" addressed to the contact, the contact's server (1) MUST initiate a roster push to all available resources associated with the contact that have requested the roster, containing an updated roster item for the user with the 'subscription' attribute set to a value of "none" (if the contact is unavailable or has not requested the roster, the contact's server MUST modify the roster item and send that modified item the next time the contact requests the roster); and (2) MUST deliver the "unsubscribe" state change notification to the contact:

「解除」型の存在スタンザを受け取る3.接触宛、連絡先のサーバは、（1）ユーザのために更新された名簿項目を含む、名簿を要求している連絡先に関連付けられたすべての利用可能なリソースに名簿プッシュを開始しなければなりません「サブスクリプション」属性が「なし」の値に設定して（接触が使用できない場合や名簿を要求していない、連絡先のサーバは、名簿の項目を変更し、その変更された項目に連絡先が名簿を要求し、次の時間を送らなければなりません）。（2）コンタクトを「解除」の状態変化通知を提供しなければなりません。

<iq type='set'> <query xmlns='jabber:iq:roster'> <item jid='user@example.com' subscription='none' name='SomeUser'> <group>SomeGroup</group> </item> </query> </iq>

<IQタイプ= '設定'> <クエリのxmlns = 'ジャバー：IQ：名簿'> <項目jid='user@example.com」サブスクリプション= 'なしの' name = 'SomeUser'> <グループ> SomeGroup </グループ> </ item>の</クエリ> </ IQ>

<プレゼンスfrom='user@example.com 'to='contact@example.org' TYPE = '解除' />

4. Upon receiving the presence stanza of type "unsubscribe", the contact SHOULD acknowledge receipt of that subscription state notification through either "affirming" it by sending a presence stanza of type "unsubscribed" to the user or "denying" it by sending a presence stanza of type "subscribed" to the user; this step does not necessarily affect the subscription state (see Subscription States (Section 9) for details), but instead lets the contact's server know that it MUST no longer send notification of the subscription state change to the contact (see Section 9.4).

「解除」型の存在スタンザを受信すると、連絡先がユーザに「解除」型の存在スタンザを送信または送信することによって、それを「否定」によってそれを「肯定」のいずれかを介してその加入状態通知の受信を確認すべきである4。ユーザーに「加入」タイプの存在スタンザ。このステップは、必ずしも（詳細については、サブスクリプションの状態（第9節）を参照）、サブスクリプションの状態に影響を与えるが、その代わりに、連絡先のサーバが、それはもはや（9.4節を参照してください）連絡先にサブスクリプションの状態変化の通知を送ってはならないことを知ることができますしません。

5. The contact's server then (1) MUST send a presence stanza of type "unsubscribed" to the user; and (2) SHOULD send unavailable presence from all of the contact's available resources to the user:

5.連絡先のサーバは、次に、（1）ユーザーに「解除」型の存在スタンザを送らなければなりません。（2）利用者への連絡先の利用可能なリソースのすべてから利用できない存在を送る必要があります。

<プレゼンスfrom='contact@example.org 'to='user@example.com' TYPE = '解除' />

<プレゼンスfrom='contact@example.org/resource 'to='user@example.com' TYPE = '利用できません' />

6. When the user's server receives the presence stanzas of type "unsubscribed" and "unavailable", it MUST deliver them to the user:

ユーザーのサーバーは、タイプの存在スタンザを受け取る6.「解除」と「利用できない」、それがユーザーにそれらを提供しなければなりません：

<プレゼンスfrom='contact@example.org 'to='user@example.com' TYPE = '解除' />

<プレゼンスfrom='contact@example.org/resource 'to='user@example.com' TYPE = '利用できません' />

7. Upon receiving the presence stanza of type "unsubscribed", the user SHOULD acknowledge receipt of that subscription state notification through either "affirming" it by sending a presence stanza of type "unsubscribe" to the contact or "denying" it by sending a presence stanza of type "subscribe" to the contact; this step does not necessarily affect the subscription state (see Subscription States (Section 9) for details), but instead lets the user's server know that it MUST no longer send notification of the subscription state change to the user (see Section 9.4).

「解除」型の存在スタンザを受信すると、ユーザが連絡先に「解除」型の存在スタンザを送信または送信することによって、それを「否定」によってそれを「肯定」のいずれかを介してその加入状態通知の受信を確認すべきである7。連絡先に「購読する」タイプの存在スタンザ。このステップは、必ずしも（詳細については、サブスクリプションの状態（第9節）を参照）、サブスクリプションの状態に影響を与えるが、その代わりに、ユーザーのサーバーは、それがもはや（9.4節を参照）ユーザーにサブスクリプションの状態変化の通知を送ってはならないことを知ることができますしません。

8.4.2. Case #2: Unsubscribing When Subscription is Mutual

8.4.2. ケース＃2：契約は相互のとき退会

In the second case, the user has a subscription to the contact's presence information and the contact also has a subscription to the user's presence information (i.e., the subscription is mutual).

後者の場合、ユーザは、連絡先のプレゼンス情報へのサブスクリプションを持っており、接触は、ユーザのプレゼンス情報へのサブスクリプションを持っている（すなわち、サブスクリプションは、相互です）。

1. If the user wants to unsubscribe from the contact's presence information, the user MUST send a presence stanza of type "unsubscribe" to the contact:

1.ユーザーは、ユーザーが連絡先に「退会」タイプの存在スタンザを送らなければなりません、連絡先のプレゼンス情報の購読を解除したい場合：

<プレゼンスto='contact@example.org」TYPE = '解除' />

2. As a result, the user's server (1) MUST send a roster push to all of the user's available resources that have requested the roster, containing an updated roster item for the contact with the 'subscription' attribute set to a value of "from"; and (2) MUST route the presence stanza of type "unsubscribe" to the contact, first stamping the 'from' address as the bare JID (<user@example.com>) of the user:

2.その結果、ユーザーのサーバーは、（1） "の値に設定する「サブスクリプション」属性との接触のために更新名簿項目を含む、名簿を要求した利用者の利用可能なリソースのすべてに名簿プッシュを送らなければなりませんから"; （2）MUSTルートタイプの存在スタンザ接点を「解除」、第1ユーザの裸JID（<user@example.com>）としてアドレス「から」スタンピング。

<iq type='set'> <query xmlns='jabber:iq:roster'> <item jid='contact@example.org' subscription='from' name='MyContact'> <group>MyBuddies</group> </item> </query> </iq>

<IQタイプ= '設定'> <クエリのxmlns = 'ジャバー：IQ：名簿'> <から項目jid='contact@example.org」サブスクリプション= '' 名= 'MyContact'> <グループ> MyBuddies </グループ> </ item>の</クエリ> </ IQ>

<プレゼンスfrom='user@example.com 'to='contact@example.org' TYPE = '解除' />

3. Upon receiving the presence stanza of type "unsubscribe" addressed to the contact, the contact's server (1) MUST initiate a roster push to all available resources associated with the contact that have requested the roster, containing an updated roster item for the user with the 'subscription' attribute set to a value of "to" (if the contact is unavailable or has not requested the roster, the contact's server MUST modify the roster item and send that modified item the next time the contact requests the roster); and (2) MUST deliver the "unsubscribe" state change notification to the contact:

「解除」型の存在スタンザを受け取る3.接触宛、連絡先のサーバは、（1）ユーザのために更新された名簿項目を含む、名簿を要求している連絡先に関連付けられたすべての利用可能なリソースに名簿プッシュを開始しなければなりません（連絡先が利用できない場合、または名簿を要求していない、連絡先のサーバは名簿の項目を変更し、その変更された項目に連絡先が名簿を要求し、次の時間を送信する必要がある場合）、「サブスクリプション」属性は「へ」の値に設定すると、（2）コンタクトを「解除」の状態変化通知を提供しなければなりません。

<iq type='set'> <query xmlns='jabber:iq:roster'> <item jid='user@example.com' subscription='to' name='SomeUser'> <group>SomeGroup</group> </item> </query> </iq>

<IQタイプ= '設定'> <クエリのxmlns = 'ジャバー：IQ：名簿'> < '名前= 'SomeUserにアイテムjid='user@example.com」サブスクリプション=''> <グループ> SomeGroup </グループ> </ item>の</クエリ> </ IQ>