RFC3921 日本語訳
3921 Extensible Messaging and Presence Protocol (XMPP): InstantMessaging and Presence. P. Saint-Andre, Ed.. October 2004. (Format: TXT=217527 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group P. Saint-Andre, Ed. Request for Comments: 3921 Jabber Software Foundation Category: Standards Track October 2004
エド、ワーキンググループP.サンアンドレをネットワークでつないでください。コメントのために以下を要求してください。 3921年のおしゃべりソフトウェア財団カテゴリ: 標準化過程2004年10月
Extensible Messaging and Presence Protocol (XMPP):
Instant Messaging and Presence
広げることができるメッセージングと存在は(XMPP)について議定書の中で述べます: インスタントメッセージングと存在
Status of this Memo
この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.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2004).
Copyright(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.
このメモはRFC2779で定義された基本のインスタントメッセージング(IM)と存在の機能性を提供するExtensible MessagingとPresenceプロトコル(XMPP)のコアの特徴の拡大とアプリケーションについて説明します。
Saint-Andre Standards Track [Page 1] RFC 3921 XMPP IM October 2004
サンアンドレ規格はXMPP不-2004年10月にRFC3921を追跡します[1ページ]。
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. 序論. . . . . . . . . . . . . . . . . . . . . . . . 2 2。 XMLスタンザ. . . . . . . . . . . . . . . . . . . 4 3の構文。 セッション設立. . . . . . . . . . . . . . . . . . . 10 4。 メッセージ. . . . . . . . . . . . . . . . . . . . 13 5を交換します。 存在情報. . . . . . . . . . . . . . 16 6を交換します。 購読. . . . . . . . . . . . . . . . . . . 26 7を管理します。 当直表管理. . . . . . . . . . . . . . . . . . . . . 27 8。 当直表項目と存在購読. . . 32 9の統合。 購読は.56 10を述べます。 コミュニケーション. . . . . . . . . . . . . . . . . . . 62 11を妨げます。 サーバは取り扱いXMLスタンザ. . . . . . . . . . . 85 12のために統治されます。 そして、不-、存在承諾要件. . . . . . . . . . 88 13 国際化問題. . . . . . . . . . . . 89 14。 セキュリティ問題. . . . . . . . . . . . . . . . . . 89 15。 IANA問題. . . . . . . . . . . . . . . . . . . . 90 16。 参照. . . . . . . . . . . . . . . . . . . . . . . . . 91A.vCards. . . . . . . . . . . . . . . . . . . . . . . . . . . 93B.XML Schemas。 . . . . . . . . . . . . . . . . . . . . . . . . 93 おしゃべり不-/存在プロトコルとXMPPのC.差。 . 105人の貢献者. . . . . . . . . . . . . . . . . . . . . . . . . . 106承認. . . . . . . . . . . . . . . . . . . . . . . . 106作者のアドレス。 . . . . . . . . . . . . . . . . . . . . . . . . 106 完全な著作権宣言文。 . . . . . . . . . . . . . . . . . . . . 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].
閉鎖におけるメッセージと存在情報をリアルタイムでと交換して、Extensible MessagingとPresenceプロトコル(XMPP)はストリーミングのXML[XML]要素のためのプロトコルです。 XMPPのコアの特徴はExtensible MessagingとPresenceプロトコル(XMPP)で定義されます: コア[XMPP-コア]。 主にXMLストリーム、ストリームのTLS、SASL、<メッセージ/>、<存在/>、および<iq/>子供の使用が捜すというこれらの特徴は多くのタイプの近くリアルタイムのアプリケーションにブロックを提供します。(アプリケーションは特定のXML名前空間[XML-NAMES]によって資格があった送付のアプリケーション特有のデータによるコアの上で層にされるかもしれません)。 このメモはRFC2779[IMP-REQS]で定義されるようにインスタントメッセージング(IM)と存在アプリケーションに予想された基本機能を提供するXMPPのコアの特徴の拡大とアプリケーションについて説明します。
Saint-Andre Standards Track [Page 2] RFC 3921 XMPP IM October 2004
サンアンドレ規格はXMPP不-2004年10月にRFC3921を追跡します[2ページ]。
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 Manageの品目からの他のユーザo Manage購読がある他のユーザo Exchange存在情報がある交換メッセージはユーザか他の特定のユーザからo Blockコミュニケーションをリストアップします(XMPPでは、これは「当直表」と呼ばれます)。
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]に関する必要条件を満たしている間、それはその仕様で明らかに念頭に設計されませんでした、RFC2779が書かれている前にベースプロトコルがJabberオープンソース共同体の中の開いている開発過程で発展したので。 また、他の多くの機能性領域を扱うプロトコルが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"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはBCP14、RFC2119[用語]で説明されるように本書では解釈されることであるべきですか?
Saint-Andre Standards Track [Page 3] RFC 3921 XMPP IM October 2004
サンアンドレ規格はXMPP不-2004年10月にRFC3921を追跡します[3ページ]。
2. Syntax of XML Stanzas
2. XMLスタンザの構文
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]で定義されます。 しかしながら、また、これらの名前空間はインスタントメッセージングと存在アプリケーションに特定の様々な子供要素、および一般的な'タイプ'属性のための値を定義します。 その結果、そのようなアプリケーションのために「使用はケースに入れる」事項を扱う前に、私たち、ここ、さらにXMLスタンザの構文について説明してください、その結果、[XMPP-CORE]で議論を補います。
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:
メッセージスタンザの'タイプ'属性はRECOMMENDEDです。 含まれているなら、メッセージの会話の関係を指定して、その結果、プレゼンテーション(例えば、GUIの)に関してヒントを提供します。 含まれているなら、'タイプ'属性に、以下の値の1つがなければなりません:
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つのチャットの会話の文脈でメッセージを送ります。 適切な会話歴史を含んでいて、SHOULDが2つの間の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]を参照してください)。 SHOULDが誤りの本質について送付者に知らせる適切なインタフェースを提示する言いなりになっているクライアント。
o groupchat -- The message is sent in the context of a multi-user
chat environment (similar to that of [IRC]). A compliant client
SHOULD present the message in an interface enabling many-to-many
chat between the parties, including a roster of parties in the
chatroom and an appropriate conversation history. Full definition
of XMPP-based groupchat protocols is out of scope for this memo.
o groupchat--マルチユーザチャット環境([IRC]のものと同様の)の文脈でメッセージを送ります。 SHOULDがインタフェースにメッセージを提示するchatroomと適切な会話歴史にパーティーに関する当直表を含むパーティーの間の多くへの多くチャットを可能にする言いなりになっているクライアント。 このメモのための範囲の外にXMPPベースのgroupchatプロトコルの完全な定義があります。
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
o 見出し--メッセージはたぶん内容(ニュース、スポーツ、市場情報、RSS給送など)を提供するか、または放送する自動化されたサービスで生成されます。 メッセージに関するどんな回答も、予想されていてまたはSHOULDがメッセージを提示する言いなりになっているクライアントではありません。
Saint-Andre Standards Track [Page 4] RFC 3921 XMPP IM October 2004
サンアンドレ規格はXMPP不-2004年10月にRFC3921を追跡します[4ページ]。
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).
スタンドアロンメッセージ、チャットセッション、またはgroupchatセッション(例えば、返答する能力を受取人に提供しないのによる)とメッセージを適切に区別するインタフェース。
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会話かgroupchatの文脈の外で送られて、受取人が返答すると予想されるただ一つのメッセージです。 SHOULDがしかし、受取人が会話歴史なしで返答するのを可能にするインタフェースにメッセージを提示する言いなりになっているクライアント。
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.
SHOULDが以上のメッセージタイプのすべてをサポートする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').
'タイプ'属性はOPTIONALですが、それはどんな回答でもメッセージにタイプを反映するために礼儀正しいと考えられます。 その上、いくつかの専門化しているアプリケーション(例えば、マルチユーザチャットサービス)が自己判断で特定のメッセージタイプの使用を実施するかもしれません(例えば、='groupchat'をタイプしてください)。
2.1.2. Child Elements
2.1.2. 子供Elements
As described under extended namespaces (Section 2.4), a message stanza MAY contain any properly-namespaced child element.
拡張名前空間(セクション2.4)の下で説明されるように、メッセージスタンザはどんな適切にnamespacedされた子供要素も含むかもしれません。
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。 <ボディー/>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
<対象/>要素はメッセージの話題を指定する人間読み込み可能なXMLキャラクタデータを含んでいます。 <対象/>要素には、'xml: lang'属性以外のどんな属性もあってはいけません。 <対象/>要素の複数のインスタンスが同じくらいの代替のバージョンを提供する目的のために含まれるかもしれません。
Saint-Andre Standards Track [Page 5] RFC 3921 XMPP IM October 2004
サンアンドレ規格はXMPP不-2004年10月にRFC3921を追跡します[5ページ]。
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'属性がある場合にだけ、かけます。 <対象/>要素は複雑な内容を含んではいけません(.2セクション3.2[XML]で定義されるように)。
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キャラクタデータを含んでいます。 この子供要素は、通常含まれていますが、OPTIONALです。 <ボディー/>要素には、'xml: lang'属性以外のどんな属性もあってはいけません。 しかし、各インスタンスに異なった言語値がある'xml: lang'属性がある場合にだけ、<ボディー/>要素の複数のインスタンスが含まれるかもしれません。 <ボディー/>要素は複雑な内容を含んではいけません(.2セクション3.2[XML]で定義されるように)。
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つの実体の間を縫うように通ります(時々「インスタントメッセージングセッション」に言及されます)。 <スレッド/>要素の価値はいずれかのコピーされた後部が回答であったなら送付者とSHOULDによって生成されます。 使用されるなら、ストリームの中でその会話スレッドにユニークでなければならなく、その会話(同じ完全なJIDからメッセージを受け取りますが、異なったスレッドIDで問題のメッセージが既存の会話スレッドの文脈の外で存在すると仮定しなければならないクライアント)の間中ときの一致しているに違いありません。 <スレッド/>要素の使用は、OPTIONALであり、個々のメッセージ、会話だけを特定するのに使用されません。 メッセージスタンザは1つ以上の<スレッド/>要素を含んではいけません。 <スレッド/>要素には、どんな属性もあってはいけません。 実体で<スレッド/>要素の価値を不透明なものとして扱わなければなりません。 それからどんな意味意味も得ないかもしれません、そして、それに対して正確な比較だけをするかもしれません。 <スレッド/>要素は複雑な内容を含んではいけません(.2セクション3.2[XML]で定義されるように)。
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.
存在スタンザは実体の(後者の、そして、任意のユーザによって定義された説明文の様々なサブ州に伴うオフラインかオンライン)の現在のネットワークの有用性を言い表して、その有用性の他の実体に通知する''または、: サーバについてペチャクチャしゃべってください'という'おしゃべり: クライアントによって資格があるので、中古の名前空間です。 また、存在スタンザも他の実体の存在の購読を交渉して、管理するのにおいて使用されています。
Saint-Andre Standards Track [Page 6] RFC 3921 XMPP IM October 2004
サンアンドレ規格はXMPP不-2004年10月にRFC3921を追跡します[6ページ]。
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:
存在スタンザの'タイプ'属性はOPTIONALです。 'タイプ'属性を持っていない存在スタンザは、送付者がコミュニケーションにオンラインであって手があいているとサーバに合図するのに使用されます。 含まれているなら、'タイプ'属性は有用性の不足、別の実体の存在の購読を管理するという要求、別の実体の現在の存在を求める要求、または以前に送られた存在スタンザに関連する誤りを指定します。 含まれているなら、'タイプ'属性に、以下の値の1つがなければなりません:
o unavailable -- Signals that the entity is no longer available for
communication.
o subscribe -- The sender wishes to subscribe to the recipient's
presence.
o subscribed -- The sender has allowed the recipient to receive
their presence.
o unsubscribe -- The sender is unsubscribing from another entity's
presence.
o unsubscribed -- The subscription request has been denied or a
previously-granted subscription has been cancelled.
o probe -- A request for an entity's current presence; SHOULD be
generated only by a server on behalf of a user.
o error -- An error has occurred regarding processing or delivery of
a previously-sent presence stanza.
For detailed information regarding presence semantics and the subscription model used in the context of XMPP-based instant messaging and presence applications, refer to Exchanging Presence Information (Section 5) and Managing Subscriptions (Section 6).
2.2.2. Child Elements
As described under extended namespaces (Section 2.4), a presence stanza MAY contain any properly-namespaced child element.
In accordance with the default namespace declaration, by default a presence stanza is qualified by the 'jabber:client' or 'jabber:server' namespace, which defines certain allowable children of presence stanzas. If the presence stanza is of type "error", it MUST include an <error/> child; for details, see [XMPP-CORE]. If the presence stanza possesses no 'type' attribute, it MAY contain any of
Saint-Andre Standards Track [Page 7] RFC 3921 XMPP IM October 2004
the following child elements (note that the <status/> child MAY be sent in a presence stanza of type "unavailable" or, for historical reasons, "subscribe"):
1. <show/> 2. <status/> 3. <priority/>
2.2.2.1. Show
The OPTIONAL <show/> element contains non-human-readable XML character data that specifies the particular availability status of an entity or specific resource. A presence stanza MUST NOT contain more than one <show/> element. The <show/> element MUST NOT possess any attributes. If provided, the XML character data value MUST be one of the following (additional availability types could be defined through a properly-namespaced child element of the presence stanza):
o away -- The entity or resource is temporarily away.
o chat -- The entity or resource is actively interested in chatting.
o dnd -- The entity or resource is busy (dnd = "Do Not Disturb").
o xa -- The entity or resource is away for an extended period (xa =
"eXtended Away").
If no <show/> element is provided, the entity is assumed to be online and available.
2.2.2.2. Status
The OPTIONAL <status/> element contains XML character data specifying a natural-language description of availability status. It is normally used in conjunction with the show element to provide a detailed description of an availability state (e.g., "In a meeting"). The <status/> element MUST NOT possess any attributes, with the exception of the 'xml:lang' attribute. Multiple instances of the <status/> element MAY be included but only if each instance possesses an 'xml:lang' attribute with a distinct language value.
2.2.2.3. Priority
The OPTIONAL <priority/> element contains non-human-readable XML character data that specifies the priority level of the resource. The value MUST be an integer between -128 and +127. A presence stanza MUST NOT contain more than one <priority/> element. The <priority/> element MUST NOT possess any attributes. If no priority is provided,
Saint-Andre Standards Track [Page 8] RFC 3921 XMPP IM October 2004
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).
2.3. IQ Syntax
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.
2.4. Extended Namespaces
While the three XML stanza kinds defined in the "jabber:client" or "jabber:server" namespace (along with their attributes and child elements) provide a basic level of functionality for messaging and presence, XMPP uses XML namespaces to extend the stanzas for the purpose of providing additional functionality. Thus a message or presence stanza MAY contain one or more optional child elements specifying content that extends the meaning of the message (e.g., an XHTML-formatted version of the message body), and an IQ stanza MAY contain one such child element. This child element MAY have any name and MUST possess an 'xmlns' namespace declaration (other than "jabber:client", "jabber:server", or "http://etherx.jabber.org/streams") that defines all data contained within the child element.
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:
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:
Saint-Andre Standards Track [Page 9] RFC 3921 XMPP IM October 2004
* 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.
* 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/>.
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.
3. Session Establishment
Most instant messaging and presence applications based on XMPP are implemented via a client-server architecture that requires a client to establish a session on a server in order to engage in the expected instant messaging and presence activities. However, there are several pre-conditions that MUST be met before a client can establish an instant messaging and presence session. These are:
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].
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]:
Saint-Andre Standards Track [Page 10] RFC 3921 XMPP IM October 2004
Server advertises session establishment feature to client:
<stream:stream
xmlns='jabber:client'
xmlns:stream='http://etherx.jabber.org/streams'
id='c2s_345'
from='example.com'
version='1.0'>
<stream:features>
<bind xmlns='urn:ietf:params:xml:ns:xmpp-bind'/>
<session xmlns='urn:ietf:params:xml:ns:xmpp-session'/>
</stream:features>
Upon being so informed that session establishment is required (and after completing resource binding), the client MUST establish a session if it desires to engage in instant messaging and presence functionality; it completes this step by sending to the server an IQ stanza of type "set" containing an empty <session/> child element qualified by the 'urn:ietf:params:xml:ns:xmpp-session' namespace:
Step 1: Client requests session with server:
<iq to='example.com'
type='set'
id='sess_1'>
<session xmlns='urn:ietf:params:xml:ns:xmpp-session'/>
</iq>
Step 2: Server informs client that session has been created:
<iq from='example.com'
type='result'
id='sess_1'/>
Upon establishing a session, a connected resource (in the terminology of [XMPP-CORE]) is said to be an "active resource".
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.
If the server encounters an internal condition that prevents it from creating the session, it MUST return an error.
Saint-Andre Standards Track [Page 11] RFC 3921 XMPP IM October 2004
Step 2 (alt): Server responds with error (internal server error):
<iq from='example.com' type='error' id='sess_1'>
<session xmlns='urn:ietf:params:xml:ns:xmpp-session'/>
<error type='wait'>
<internal-server-error
xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
</error>
</iq>
If the username or resource is not allowed to create a session, the server MUST return an error (e.g., forbidden).
Step 2 (alt): Server responds with error (username or resource not allowed to create session):
<iq from='example.com' type='error' id='sess_1'>
<session xmlns='urn:ietf:params:xml:ns:xmpp-session'/>
<error type='auth'>
<forbidden
xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
</error>
</iq>
If there is already an active resource of the same name, the server MUST either (1) terminate the active resource and allow the newly-requested session, or (2) disallow the newly-requested session and maintain the active resource. Which of these the server does is up to the implementation, although it is RECOMMENDED to implement case #1. In case #1, the server SHOULD send a <conflict/> stream error to the active resource, terminate the XML stream and underlying TCP connection for the active resource, and return a IQ stanza of type "result" (indicating success) to the newly-requested session. In case #2, the server SHOULD send a <conflict/> stanza error to the newly-requested session but maintain the XML stream for that connection so that the newly-requested session has an opportunity to negotiate a non-conflicting resource identifier before sending another request for session establishment.
Step 2 (alt): Server informs existing active resource of resource conflict (case #1):
<stream:error>
<conflict xmlns='urn:ietf:params:xml:ns:xmpp-streams'/>
</stream:error>
</stream:stream>
Saint-Andre Standards Track [Page 12] RFC 3921 XMPP IM October 2004
Step 2 (alt): Server informs newly-requested session of resource conflict (case #2):
<iq from='example.com' type='error' id='sess_1'>
<session xmlns='urn:ietf:params:xml:ns:xmpp-session'/>
<error type='cancel'>
<conflict xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
</error>
</iq>
After establishing a session, a client SHOULD send initial presence and request its roster as described below, although these actions are OPTIONAL.
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].
4. Exchanging Messages
Exchanging messages is a basic use of XMPP and is brought about when a user generates a message stanza that is addressed to another entity. As defined under Server Rules for Handling XML Stanzas (Section 11), the sender's server is responsible for delivering the message to the intended recipient (if the recipient is on the same server) or for routing the message to the recipient's server (if the recipient is on a different server).
For information regarding the syntax of message stanzas as well as their defined attributes and child elements, refer to Message Syntax (Section 2.1).
4.1. Specifying an Intended Recipient
An instant messaging client SHOULD specify an intended recipient for a message by providing the JID of an entity other than the sender in the 'to' attribute of the <message/> stanza. If the message is being sent in reply to a message previously received from an address of the form <user@domain/resource> (e.g., within the context of a chat session), the value of the 'to' address SHOULD be of the form <user@domain/resource> rather than of the form <user@domain> unless the sender has knowledge (via presence) that the intended recipient's resource is no longer available. If the message is being sent
SHOULDが<メッセージ/>スタンザの'to'属性における送付者以外の実体のJIDを提供しながらメッセージのための意図している受取人を指定するインスタントメッセージングクライアント。 以前に form <user@domain/resource のアドレスから受け取られたメッセージに対してメッセージを送る、gt;、(例えば、チャットセッションの文脈の中の)、'to'アドレスSHOULDの値が form <user@domain/resource のそうである、gt;、むしろ、 form <user@domain 、gt;、送付者に意図している受取人のリソースがもう利用可能でないという知識(存在を通した)がない場合。 メッセージを送るなら
Saint-Andre Standards Track [Page 13] RFC 3921 XMPP IM October 2004
サンアンドレ規格はXMPP不-2004年10月にRFC3921を追跡します[13ページ]。
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>.
アドレスSHOULDがどんな既存のチャットセッションの文脈か受信されたメッセージ、'to'の値の外では、 form <user@domain のそうである、gt;、むしろ、 form <user@domain/resource 、gt。
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)).
注意されるように、それはメッセージスタンザが値がメッセージの会話の関係(もしあれば)を得る'タイプ'属性を持つRECOMMENDED(Type(セクション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>
=' juliet@example.com/balcony 'タイプから' romeo@example.net 'と等しい<メッセージは'チャット'xmlと等しいです: langが'アン'><ボディー>Wherefore芸術と等しい、なんじ、ロメオ?</ボディー></メッセージ>、'
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)).
メッセージスタンザがXMLキャラクタデータがメッセージのプライマリ意味を指定する子供<ボディー/>要素を含むかもしれない、(そして、しばしば意志)(Bodyを見てください、(セクション2.1 .2 .2)。
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>
=' juliet@example.com/balcony 'タイプから' romeo@example.net 'と等しい<メッセージ='チャット'xml: langはなんじ、ロメオ--'cz'></ボディー><ボディーxml: lang=Proと#x010D; 'アン'><ボディー>Wherefore芸術のeと#x017Dと等しいです'。 jsi ty、ロメオ--</ボディー></メッセージ>。
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つ以上の子供<対象/>要素を含むかもしれない、(Subjectを見てください、(セクション2.1 .2 .1)。
Saint-Andre Standards Track [Page 14] RFC 3921 XMPP IM October 2004
サンアンドレ規格はXMPP不-2004年10月にRFC3921を追跡します[14ページ]。
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>
=' juliet@example.com/balcony 'タイプ='チャット'xml: lang='アン'>の<の対象の>から、私はあなたを嘆願します!=' romeo@example.net '</対象の><対象のxml: langは'czと等しいこと'の>と#x00DA; pと#x011B;nlivと#x011B'への<メッセージ prosim!</対象><ボディー>Wherefore芸術のなんじと、xml: ロメオ?</ボディー><ボディーlang='cz'>Proと#x010D; eと#x017D;' jsi ty、ロメオ--</ボディー></メッセージ>。
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)).
メッセージスタンザはメッセージが位置している会話スレッドを指定する子供<スレッド/>要素を含むかもしれません、会話を追跡する目的のために(Threadを見てください、(セクション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>
=' romeo@example.net/orchard への'=' juliet@example.com/balcony 'タイプ='チャット'xml: lang='アン'><ボディー>Artからのロメオではなく、なんじ、およびモンターグ?</ボディー><スレッド>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>
=' romeo@example.net/orchard 'タイプ='チャット'xml: lang='アン'><ボディー>Neither、公正な聖者から' juliet@example.com/balcony 'と等しい<メッセージあなたが. </ボディー><スレッド>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>
こちらに、私、およびいわれを言ってくれますか?=' juliet@example.com/balcony 'タイプから' romeo@example.net/orchard 'と等しい<メッセージは'チャット'xmlと等しいです: langが'アン'><ボディー>How cam'stと等しい、なんじ、</ボディー><は>e0ffe42b28561960c6b12b944a092794b9683a38</スレッド></メッセージ>に糸を通します'
Saint-Andre Standards Track [Page 15] RFC 3921 XMPP IM October 2004
サンアンドレ規格はXMPP不-2004年10月にRFC3921を追跡します[15ページ]。
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の中で存在スタンザを使用することによって比較的簡単にします。 しかしながら、私たちは、aがメッセージの取り扱いに対して対照するのをここを見ます: クライアントは'to'アドレスを含んでいることによって、指示された存在情報を別の実体に送るかもしれませんが、通常、存在通知(すなわち、'タイプ'かタイプの「入手できません、な」ノーと'to'アドレスのない存在スタンザ)は、サーバによって送付実体の存在に申し込まれるどんな実体にも、クライアントからサーバに送られて、次に、broadcastedされます(RFC2778[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".
セッション、SHOULDがコミュニケーションのための有用性に合図するためにサーバへの初期の存在を送るクライアントを設立した後に。 初期の存在スタンザ(1)には、ここに定義されるように、'to'アドレスが全くあってはいけません、そして、(それがクライアントを代表したサーバによってbroadcastedされることになっていると合図して)(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
1. 完全なJIDから存在探測装置(すなわち、'タイプ'属性が「徹底的調査」の値に設定される存在スタンザ)を送ってください、(例えば、 <user@example.com/resource 、gt;、)、ユーザが確認するために申し込まれるすべての接触へのユーザでは、それらは利用可能です。 そのような接触は、JIDがユーザの当直表に'購読'属性セットについて“to"の値に存在しているそれらか「両方」です。 (の注意: ユーザサーバはユーザが立ち塞がっている接触に存在探測装置を送ってはいけません。
Saint-Andre Standards Track [Page 16] RFC 3921 XMPP IM October 2004
サンアンドレ規格はXMPP不-2004年10月にRFC3921を追跡します[16ページ]。
inbound presence notifications, as described under Blocking
Inbound Presence Notifications (Section 10.10).)
Blocking Inbound Presence Notifications(セクション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).)
2. 完全なJIDから初期の存在を放送してください、(例えば、 <user@example.com/resource 、gt;、)、ユーザの存在情報に申し込まれるすべての接触へのユーザについて。 そのような接触は、JIDがユーザの当直表に'購読'属性セットについて“from"の値に存在しているそれらか「両方」です。 (注意: ユーザのサーバはユーザが外国行きの存在通知を妨げている接触に初期の存在を放送してはいけません、Blocking Outbound Presence Notifications(セクション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)).
ユーザから初期の存在を受けるとき接触のサーバがユーザの存在スタンザを完全なJIDs (<contact@example.org/resource に提供しなければならない、gt;、)、接触の利用可能資源のすべてにもかかわらず、ユーザが“to"か「両方」の購読状態と共に接触の当直表にいて、接触がユーザのむき出しの、または、完全なJIDからの本国行きの存在通知を妨げているだけではないかどうかと(Blocking Inbound Presence Notifications(セクション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).
ユーザのサーバが初期の存在に対応してタイプ「誤り」の存在スタンザを受け取るならユーザを代表してa接触に発信して、SHOULD NOTであることがさらなる存在アップデートをその接触に送る、(それが接触から存在スタンザを受け取らない、)
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.)
初期の存在を送った後に、ユーザは「入手できません」の値でどんないつでもセッションの間、'to'アドレスなしで存在スタンザを送ることによって放送するための存在情報と'タイプ'属性も'タイプ'属性のどちらかもアップデートしないかもしれません。 (注意: ユーザのクライアントSHOULD NOTはユーザの存在と有用性の如何にかかわらず変化する情報を放送するために存在アップデートを送ります。)
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
存在スタンザが'タイプ'属性(すなわち、有用性を言い表す)を欠いているなら、ユーザのサーバは購読があるユーザの当直表では、ユーザが“from"か「両方」、(2)をだれにタイプしているかということであるすべての接触(1)にその存在スタンザの完全なXMLを放送しなければなりません。
Saint-Andre Standards Track [Page 17] RFC 3921 XMPP IM October 2004
サンアンドレ規格はXMPP不-2004年10月にRFC3921を追跡します[17ページ]。
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).
外国行きの存在通知、およびサーバがユーザのセッション(よくユーザの他の利用可能資源のどれかのように)の間に存在誤りを受けていない(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:
ユーザから存在探測装置を受け止めると、接触のサーバSHOULDは以下の通り返答します:
1. If the user is not in the contact's roster with a subscription
state of "From", "From + Pending Out", or "Both" (as defined
under Subscription States (Section 9)), the contact's server MUST
return a presence stanza of type "error" in response to the
presence probe (however, if a server receives a presence probe
from a subdomain of the server's hostname or another such trusted
service, it MAY provide presence information about the user to
that entity). Specifically:
1. ユーザが「+ 未定のアウト」からの“From"、または「両方」の購読状態と共に接触の当直表にいないなら(Subscription States(セクション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.
* ユーザが「なにも」の購読状態と共に接触の当直表にいるなら「なにも、」 + 未定のアウト“To"(または、全く接触の当直表には、ない)、接触のサーバは/>スタンザ誤りが存在徹底的調査に対応して禁じられた<を返さなければなりません。
* 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.
* ユーザが購読状態と共に接触の当直表にいる、「なにも、中で未定の+、」、「存在に対応した認可されなかったリターンa</>スタンザ誤りが調べる+ 」 「中で未定の+」、接触のサーバの未定の出かけている/がそうしてはいけないなにも。
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. ほかに、接触がユーザのむき出しのJIDか完全なJID(Blocking Outbound Presence Notifications(セクション10.11)の下で定義されるようにデフォルトリストか現役軍人名簿のどちらかを使用する)に存在通知を妨げているなら、サーバは存在徹底的調査に答えてはいけません。
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. ほかに、接触に利用可能資源が全くないなら、サーバはタイプの「入手できません、な」最後の存在スタンザの完全なXMLがサーバで接触、または(2)から受けたユーザに発信するのによる存在徹底的調査に関して全く返答してはいけません(1)が、返答する。
Saint-Andre Standards Track [Page 18] RFC 3921 XMPP IM October 2004
サンアンドレ規格はXMPP不-2004年10月にRFC3921を追跡します[18ページ]。
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).
4. ほかに、接触に少なくとも1つの利用可能なリソースがあるなら、サーバは、最後の存在スタンザの完全なXMLをユーザにサーバでそれぞれに関する接触の利用可能資源から'to'属性を全く受け取っていなく送ることによって、存在徹底的調査に答えなければなりません(一方、プライバシーへの対象は各セッションのために大挙して記載します)。
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である'to'属性と'タイプ'属性がない値が「入手できません」'タイプ'属性のどちらかがある存在スタンザ)に指示された存在を送るかもしれません。 3つの可能なケースがあります:
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. ユーザが初期の存在を送った後と“from"か「両方」の購読タイプでユーザの当直表の送付の入手できない存在が放送した前である接触に指示された存在を送るなら、ユーザのサーバがその存在スタンザ(プライバシーリストを条件とした)の完全なXMLを発送しなければならないか、または提供しなければなりませんが、そうでなければ、SHOULD NOTが存在放送に関する接触の状態を変更する、(すなわち、それ、ユーザによって開始されたどんなその後の存在放送でも接触のSHOULDインクルード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. ユーザが直送するなら、初期の存在を送ったので、送付の入手できない存在が放送する前に、ユーザのサーバがその存在スタンザの完全なXMLを実体に発送しなければならないか、または提供しなければならなかった後にユーザの当直表に“from"か「両方」の購読タイプでありませんが、利用可能な存在に関する接触の状態を変更してはいけない実体への存在は放送しました(すなわち、それはユーザによって開始された利用可能な存在のどんなその後の放送にも実体の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. ユーザが指示された存在を送るなら、初期の存在を送らなければならないか、またはユーザのサーバが入手できない存在放送(すなわち、リソースは、アクティブですが、利用可能でない)を送ったので、同様に、ユーザが指示された存在を送る実体を扱わなければならなかった後にそれが扱う1番目がなければ、実体は上にケース#2に記載しました。
Saint-Andre Standards Track [Page 19] RFC 3921 XMPP IM October 2004
サンアンドレ規格はXMPP不-2004年10月にRFC3921を追跡します[19ページ]。
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.
結末の前に、サーバとのセッション、値が「入手できません」クライアントSHOULDは優雅に'to'属性を全く持っていなくて、'タイプ'属性を持っている最終的な存在スタンザを送ることによって入手できなくなります(任意に、最終的な存在スタンザはユーザがもう手があいていない理由を指定する1つ以上の<状態/>要素を含むかもしれません)。 しかしながら、ユーザのサーバは利用可能なリソースから最終的な存在を受けるのによってはいけません; 以来、リソースは、不意に入手できなくなるか、またはサーバによる外で調節されるかもしれません。ユーザのリソースの1つがどんな理由(優雅か無様である)も入手できなくなるなら、ユーザのサーバはユーザの当直表に“from"か「両方」の購読タイプであるすべての接触(1)に入手できない存在を放送しなければなりません、ユーザが外国行きの存在、およびサーバがユーザのセッションの間に存在誤りを受けていない(3)を妨げていない(2)。 また、ユーザのサーバはその入手できない存在スタンザをユーザの他の利用可能資源のどれかに送らなければなりません、よくユーザがそのリソースのためのユーザのセッションの間に指示された存在を送るどんな実体(ユーザがまだ指示された入手できない存在をその実体に送らないなら)のようにも。 すべての加入者へのサーバで'タイプ'属性を送りますが、送付が入手できない存在を指示したか、または入手できない存在をbroadcastedした後に送られない少しも'to'属性はどんな存在スタンザもbroadcastedしなければなりません。
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.
購読要求は'タイプ'属性に「申し込んでください」の値がある存在スタンザです。 購読要求をインスタントメッセージング接触に送るなら、'to'属性SHOULDで供給されたJIDが form <contact@example.org について送る、gt;、むしろ than <contact@example.org/resource 、gt;、必要な結果は通常接触のリソース(単に'to'属性で指定されなかったいずれの特定のリソースも)のすべてから存在を受けるユーザのためのものです。
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つ以上の利用可能資源に。 ユーザのサーバで購読要求を受け取るとき、ユーザに関連しているどんな利用可能なリソースもなければ、次のユーザが利用可能なリソースを作成するとき、ユーザのサーバは、購読要求に関する記録をつけて、要求を提供しなければなりません、ユーザが要求を承認するか、または否定するまで。 ユーザのサーバで購読要求を受け取るとき、ユーザに関連している1つ以上の利用可能なリソースがあれば、Server Rulesに従って、ユーザのサーバはHandling XML Stanzas(セクション11)のためにその購読要求をすべての利用可能資源に放送しなければなりません。 (アクティブなリソースであるなら以下に注意してください。
Saint-Andre Standards Track [Page 20] RFC 3921 XMPP IM October 2004
サンアンドレ規格はXMPP不-2004年10月にRFC3921を追跡します[20ページ]。
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:
例: 有用性状態:
<presence>
<show>dnd</show>
</presence>
<存在><ショー>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)).
<ショー/>要素に関連してクライアントが<状態/>要素を使用することによって詳細な状態情報を提供するかもしれない、(Statusを見てください、(セクション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は''><が'cz'>Ja dvoと#x0159; #x00ED; mジュリエット</状態></存在>と等しいのを>dnd</ショー><状態>Wooingジュリエット</状態><状態xml: langに示すアン'と等しいです。
Saint-Andre Standards Track [Page 21] RFC 3921 XMPP IM October 2004
サンアンドレ規格はXMPP不-2004年10月にRFC3921を追跡します[21ページ]。
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)).
クライアントが<優先権/>要素を使用することによって優先をリソースに提供するかもしれない、(Priorityを見てください、(セクション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>
<presence xml:lang='en'> <show>dnd</show> <status>Wooing Juliet</status> <status xml:lang='cz'>Ja dvořím Juliet</status> <priority>1</priority> </presence>
5.5. Presence Examples
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 (購読="to")
o mercutio@example.org (subscription="from")
o mercutio@example.org (購読="from")
Example 1: User sends initial presence:
例1: ユーザは初期の存在を送ります:
<presence/>
<存在/>。
Example 2: User's server sends presence probes to contacts with subscription="to" and subscription="both" on behalf of the user's available resource:
例2: ユーザのサーバは購読="to"との接触に存在探測装置を送ります、そして、購読はユーザの利用可能なリソースを代表して「両方」と等しいです:
<presence
type='probe'
from='romeo@example.net/orchard'
to='juliet@example.com'/>
<存在タイプ=が' juliet@example.com '/と等しいように=' romeo@example.net/orchard 'から'調べる'、gt。
<presence
type='probe'
from='romeo@example.net/orchard'
to='benvolio@example.org'/>
<存在タイプ=が' benvolio@example.org '/と等しいように=' romeo@example.net/orchard 'から'調べる'、gt。
Saint-Andre Standards Track [Page 22] RFC 3921 XMPP IM October 2004
サンアンドレ規格はXMPP不-2004年10月にRFC3921を追跡します[22ページ]。
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"との接触に初期の存在を送ります、そして、購読はユーザの利用可能なリソースを代表して「両方」と等しいです:
<presence
from='romeo@example.net/orchard'
to='juliet@example.com'/>
=' romeo@example.net/orchard 'から=' juliet@example.com '/までの<存在、gt。
<presence
from='romeo@example.net/orchard'
to='mercutio@example.org'/>
=' romeo@example.net/orchard 'から=' mercutio@example.org '/までの<存在、gt。
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>
' romeo@example.net/orchard 'xml: langは正しい逆</状態><優先権が>0</優先権></存在>であったなら遠くの'アン'><ショー></ショー><状態>と等しいこと'と等しい=' juliet@example.com/balcony 'からの<存在
<presence
from='juliet@example.com/chamber'
to='romeo@example.net/orchard'>
<priority>1</priority>
</presence>
=' juliet@example.com/chamber 'から=' romeo@example.net/orchard 'までの<存在、gt;、1つの</優先権の<優先権>></存在>。
<presence
from='benvolio@example.org/pda'
to='romeo@example.net/orchard'
xml:lang='en'>
<show>dnd</show>
<status>gallivanting</status>
</presence>
=' benvolio@example.org/pda '等しく'romeo@example.net/果樹園'xmlからの<存在: langは'アン'><ショー>dnd</ショー><状態>遊び歩く</状態></存在>'と等しいです。
Example 5: Contacts' servers deliver user's initial presence to all available resources or return error to user:
例5: 接触のサーバは、ユーザの初期の存在をすべての利用可能資源に提供するか、または誤りをユーザに返します:
<presence
from='romeo@example.net/orchard'
to='juliet@example.com/chamber'/>
=' romeo@example.net/orchard 'から=' juliet@example.com/chamber '/までの<存在、gt。
Saint-Andre Standards Track [Page 23] RFC 3921 XMPP IM October 2004
サンアンドレ規格はXMPP不-2004年10月にRFC3921を追跡します[23ページ]。
<presence
from='romeo@example.net/orchard'
to='juliet@example.com/balcony'/>
=' romeo@example.net/orchard 'から=' juliet@example.com/balcony '/までの<存在、gt。
<presence
type='error'
from='mercutio@example.org'
to='romeo@example.net/orchard'>
<error type='cancel'>
<gone xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
</error>
</presence>
<存在タイプ='誤り'=' mercutio@example.org '等しく'romeo@example果樹園.net/'><誤りタイプ='キャンセル'><過ぎ去る、xmlnsは'つぼ:ietf:params:xml:ナノ秒: 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>
=' romeo@example.net/orchard ジュリエット</状態><優先権を求める'=' nurse@example.com 'xmlに: langは'アンと等しく'><ショー>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は'アン'><は私が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: ユーザのサーバ放送は存在情報を1つの接触だけにアップデートしました(誤りが受けられたか、またはユーザが発信したというわけではないそれらは存在を指示しました):
<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>
=' romeo@example.net/orchard から'私が1つの</優先権の</状態><優先権>></存在>を返すつもりである遠くの'アン'><ショー></ショー><=' juliet@example.com 'xml: lang=状態>'までの<存在
Saint-Andre Standards Track [Page 24] RFC 3921 XMPP IM October 2004
サンアンドレ規格はXMPP不-2004年10月にRFC3921を追跡します[24ページ]。
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>
[「バルコニー」リソースへの] =' romeo@example.net/orchard から'私が1つの</優先権の</状態><優先権>></存在>を返すつもりである遠くの'アン'><ショー></ショー><=' juliet@example.com 'xml: lang=状態>'までの<存在
[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>
[「部屋」リソースへの] =' romeo@example.net/orchard から'私が1つの</優先権の</状態><優先権>></存在>を返すつもりである遠くの'アン'><ショー></ショー><=' juliet@example.com 'xml: lang=状態>'までの<存在
Example 10: One of the contact's resources broadcasts final presence:
例10: 接触のリソースのひとりは最終的な存在を放送します:
<presence from='juliet@example.com/balcony' type='unavailable'/>
=' juliet@example.com/balcony 'タイプからの<存在は'入手できません、な'/>と等しいです。
Example 11: Contact's server sends unavailable presence information to user:
例11: 接触のサーバは入手できない存在情報をユーザに送ります:
<presence
type='unavailable'
from='juliet@example.com/balcony'
to='romeo@example.net/orchard'/>
=' juliet@example.com/balcony 'から=' romeo@example.net/orchard '/まで'入手できません、な'<存在タイプ=、gt。
Example 12: User sends final presence:
例12: ユーザは最終的な存在を送ります:
<presence from='romeo@example.net/orchard'
type='unavailable'
xml:lang='en'>
<status>gone home</status>
</presence>
=' romeo@example.net/orchard 'タイプからの<存在='入手できない'xml: lang='アン'><状態>過ぎ去る、ホーム</状態></存在>、'
Saint-Andre Standards Track [Page 25] RFC 3921 XMPP IM October 2004
サンアンドレ規格はXMPP不-2004年10月にRFC3921を追跡します[25ページ]。
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: ユーザのサーバはまた、ユーザが指示された存在を送った人に関して連絡する入手できない存在情報を放送します:
<presence
type='unavailable'
from='romeo@example.net/orchard'
to='juliet@example.com'
xml:lang='en'>
<status>gone home</status>
</presence>
<存在=への'入手できないタイプ=''= romeo@example.net/orchard '' juliet@example.com 'xml: lang='アン'><状態>過ぎ去る、ホーム</状態></存在>、'
<presence
from='romeo@example.net/orchard'
to='nurse@example.com'
xml:lang='en'>
<status>gone home</status>
</presence>
=' romeo@example.net/orchard 'から=' nurse@example.com までの<存在が': lang=をxmlする'というアン'><状態>過ぎ去る、ホーム</状態></存在>、'
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.
インスタントメッセージングユーザといかなる他の実体のプライバシーも保護するために、存在と有用性情報はユーザが承認した他の実体だけに明らかにされます。 ユーザが、別の実体が存在を見るかもしれないのに同意したとき、実体はユーザの存在情報の購読を持っていると言われます。 購読はセッションの向こう側に続きます。 本当に、加入者が外すまで、持続するか、またはsubscribeeは以前に与えられた購読を中止します。 特に定義された属性を含んでいて、購読は、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.
以下に注意してください。 購読と当直表との重要な相互作用があります。 これらはRoster ItemsとPresence Subscriptions(セクション8)のIntegrationの下で定義されます、そして、読者は存在購読の完全な理解についてそのセクションを参照しなければなりません。
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:
例: 購読を送って、以下を要求してください。
<presence to='juliet@example.com' type='subscribe'/>
' juliet@example.com 'タイプと等しい<存在は'申し込み'/>と等しいです。
Saint-Andre Standards Track [Page 26] RFC 3921 XMPP IM October 2004
サンアンドレ規格はXMPP不-2004年10月にRFC3921を追跡します[26ページ]。
For client and server responsibilities regarding presence subscription requests, refer to Presence Subscriptions (Section 5.1.6).
存在購読要求に関するクライアントとサーバ責任について、Presence Subscriptions(セクション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:
例: 購読を承認して、以下を要求してください。
<presence to='romeo@example.net' type='subscribed'/>
' romeo@example.net 'タイプと等しい<存在は'申し込み'/>と等しいです。
Example: Refusing a presence subscription request:
例: 存在購読を拒否して、以下を要求してください。
<presence to='romeo@example.net' type='unsubscribed'/>
' romeo@example.net 'タイプと等しい<存在は'外す'/>と等しいです。
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:
例: 以前に与えられた購読を中止して、以下を要求してください。
<presence to='romeo@example.net' type='unsubscribed'/>
' romeo@example.net 'タイプと等しい<存在は'外す'/>と等しいです。
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:
例: 実体の存在から以下を外すこと。
<presence to='juliet@example.com' type='unsubscribe'/>
' juliet@example.com 'タイプと等しい<存在は'外す'/>と等しいです。
7. Roster Management
7. Roster Management
In XMPP, one's contact list is called a roster, which consists of any number of specific roster items, each roster item being identified by a unique JID (usually of the form <contact@domain>). A user's roster is stored by the user's server on the user's behalf so that the user may access roster information from any resource.
In XMPP, one's contact list is called a roster, which consists of any number of specific roster items, each roster item being identified by a unique JID (usually of the form <contact@domain>). A user's roster is stored by the user's server on the user's behalf so that the user may access roster information from any resource.
Saint-Andre Standards Track [Page 27] RFC 3921 XMPP IM October 2004
Saint-Andre Standards Track [Page 27] RFC 3921 XMPP IM October 2004
Note: There are important interactions between rosters and subscriptions; these are defined under Integration of Roster Items and Presence Subscriptions (Section 8), and the reader must refer to that section for a complete understanding of roster management.
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.
7.1. Syntax and Semantics
7.1. Syntax and Semantics
Rosters are managed using IQ stanzas, specifically by means of a <query/> child element qualified by the 'jabber:iq:roster' namespace. The <query/> element MAY contain one or more <item/> children, each describing a unique roster item or "contact".
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".
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.
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.
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:
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:
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 "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 "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 "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 "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 "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 "both" -- both the user and the contact have subscriptions to each
other's presence information
o "both" -- both the user and the contact have subscriptions to each other's presence information
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.
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.
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.
Each <item/> element MAY contain one or more <group/> child elements, for use in collecting roster items into various categories. The XML character data of the <group/> element is opaque.
Saint-Andre Standards Track [Page 28] RFC 3921 XMPP IM October 2004
Saint-Andre Standards Track [Page 28] RFC 3921 XMPP IM October 2004
7.2. Business Rules
7.2. Business Rules
A server MUST ignore any 'to' address on a roster "set", and MUST treat any roster "set" as applying to the sender. For added safety, a client SHOULD check the "from" address of a "roster push" (incoming IQ of type "set" containing a roster item) to ensure that it is from a trusted source; specifically, the stanza MUST either have no 'from' attribute (i.e., implicitly from the server) or have a 'from' attribute whose value matches the user's bare JID (of the form <user@domain>) or full JID (of the form <user@domain/resource>); otherwise, the client SHOULD ignore the "roster push".
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".
7.3. Retrieving One's Roster on Login
7.3. Retrieving One's Roster on Login
Upon connecting to the server and becoming an active resource, a client SHOULD request the roster before sending initial presence (however, because receiving the roster may not be desirable for all resources, e.g., a connection with limited bandwidth, the client's request for the roster is OPTIONAL). If an available resource does not request the roster during a session, the server MUST NOT send it presence subscriptions and associated roster updates.
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 requests current roster from server:
<iq from='juliet@example.com/balcony' type='get' id='roster_1'>
<query xmlns='jabber:iq:roster'/>
</iq>
<iq from='juliet@example.com/balcony' type='get' id='roster_1'> <query xmlns='jabber:iq:roster'/> </iq>
Example: Client receives 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='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>
Saint-Andre Standards Track [Page 29] RFC 3921 XMPP IM October 2004
Saint-Andre Standards Track [Page 29] RFC 3921 XMPP IM October 2004
</iq>
</iq>
7.4. Adding a Roster Item
7.4. Adding a Roster Item
At any time, a user MAY add an item to his or her roster.
At any time, a user MAY add an item to his or her roster.
Example: Client adds a new item:
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='set' id='roster_2'> <query xmlns='jabber:iq:roster'> <item jid='nurse@example.com' name='Nurse'> <group>Servants</group> </item> </query> </iq>
The server MUST update the roster information in persistent storage, and also push the change out to all of the user's available resources that have requested the roster. This "roster push" consists of an IQ stanza of type "set" from the server to the client and enables all available resources to remain in sync with the server-based roster information.
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.
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:
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:
<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='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/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='set' id='a78b4q6ha464'> <query xmlns='jabber:iq:roster'> <item jid='nurse@example.com' name='Nurse' subscription='none'> <group>Servants</group>
Saint-Andre Standards Track [Page 30] RFC 3921 XMPP IM October 2004
Saint-Andre Standards Track [Page 30] RFC 3921 XMPP IM October 2004
</item>
</query>
</iq>
</item> </query> </iq>
<iq to='juliet@example.com/balcony' type='result' id='roster_2'/>
<iq to='juliet@example.com/balcony' type='result' id='roster_2'/>
As required by the semantics of the IQ stanza kind as defined in [XMPP-CORE], each resource that received the roster push MUST reply with an IQ stanza of type "result" (or "error").
As required by the semantics of the IQ stanza kind as defined in [XMPP-CORE], each resource that received the roster push MUST reply with an IQ stanza of type "result" (or "error").
Example: Resources reply with an IQ result to the server:
Example: Resources reply with an IQ result to the server:
<iq from='juliet@example.com/balcony'
to='example.com'
type='result'
id='a78b4q6ha463'/>
<iq from='juliet@example.com/chamber'
to='example.com'
type='result'
id='a78b4q6ha464'/>
<iq from='juliet@example.com/balcony' to='example.com' type='result' id='a78b4q6ha463'/> <iq from='juliet@example.com/chamber' to='example.com' type='result' id='a78b4q6ha464'/>
7.5. Updating a Roster Item
7.5. Updating a Roster Item
Updating an existing roster item (e.g., changing the group) is done in the same way as adding a new roster item, i.e., by sending the roster item in an IQ set to the server.
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.
Example: User updates roster item (added group):
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='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>
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.
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.
Saint-Andre Standards Track [Page 31] RFC 3921 XMPP IM October 2004
Saint-Andre Standards Track [Page 31] RFC 3921 XMPP IM October 2004
7.6. Deleting a Roster Item
7.6. Deleting a Roster Item
At any time, a user MAY delete an item from his or her roster by sending an IQ set to the server and making sure that the value of the 'subscription' attribute is "remove" (a compliant server MUST ignore any other values of the 'subscription' attribute when received from a client).
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).
Example: Client removes an item:
Example: Client removes an item:
<iq from='juliet@example.com/balcony' type='set' id='roster_4'>
<query xmlns='jabber:iq:roster'>
<item jid='nurse@example.com' subscription='remove'/>
</query>
</iq>
<iq from='juliet@example.com/balcony' type='set' id='roster_4'> <query xmlns='jabber:iq:roster'> <item jid='nurse@example.com' subscription='remove'/> </query> </iq>
As with adding a roster item, when deleting a roster item the server MUST update the roster information in persistent storage, initiate a roster push to all of the user's available resources that have requested the roster (with the 'subscription' attribute set to a value of "remove"), and send an IQ result to the initiating resource.
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.
For further information about the implications of this command, see Removing a Roster Item and Cancelling All Subscriptions (Section 8.6).
For further information about the implications of this command, see Removing a Roster Item and Cancelling All Subscriptions (Section 8.6).
8. Integration of Roster Items and Presence Subscriptions
8. Integration of Roster Items and Presence Subscriptions
8.1. Overview
8.1. Overview
Some level of integration between roster items and presence subscriptions is normally expected by an instant messaging user regarding the user's subscriptions to and from other contacts. This section describes the level of integration that MUST be supported within XMPP instant messaging applications.
Some level of integration between roster items and presence subscriptions is normally expected by an instant messaging user regarding the user's subscriptions to and from other contacts. This section describes the level of integration that MUST be supported within XMPP instant messaging applications.
There are four primary subscription states:
There are four primary subscription states:
o None -- the user does not have a subscription to the contact's
presence information, and the contact does not have a subscription
to the user's presence information
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
Saint-Andre Standards Track [Page 32] RFC 3921 XMPP IM October 2004
Saint-Andre Standards Track [Page 32] RFC 3921 XMPP IM October 2004
o To -- the user has a subscription to the contact's presence
information, but the contact does not have a subscription to the
user's presence information
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 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 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 Both -- both the user and the contact have subscriptions to each
other's presence information (i.e., the union of 'from' and 'to')
o Both -- both the user and the contact have subscriptions to each other's presence information (i.e., the union of 'from' and 'to')
Each of these states is reflected in the roster of both the user and the contact, thus resulting in durable subscription states.
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).
Narrative explanations of how these subscription states interact with roster items in order to complete certain defined use cases are provided in the following sub-sections. Full details regarding server and client handling of all subscription states (including pending states between the primary states listed above) is provided in Subscription States (Section 9).
The server MUST NOT send presence subscription requests or roster pushes to unavailable resources, nor to available resources that have not requested the roster.
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]).
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]).
8.2. User Subscribes to Contact
8.2. User Subscribes to Contact
The process by which a user subscribes to a contact, including the interaction between roster items and subscription states, is described below.
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. 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:
Saint-Andre Standards Track [Page 33] RFC 3921 XMPP IM October 2004
Saint-Andre Standards Track [Page 33] RFC 3921 XMPP IM October 2004
<iq type='set' id='set1'>
<query xmlns='jabber:iq:roster'>
<item
jid='contact@example.org'
name='MyContact'>
<group>MyBuddies</group>
</item>
</query>
</iq>
<iq type='set' id='set1'> <query xmlns='jabber:iq:roster'> <item jid='contact@example.org' name='MyContact'> <group>MyBuddies</group> </item> </query> </iq>
2. As a result, the user's server (1) MUST initiate a roster push
for the new roster item to all available resources associated
with this user that have requested the roster, setting the
'subscription' attribute to a value of "none"; and (2) MUST reply
to the sending resource with an IQ result indicating the success
of the roster set:
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:
<iq type='set'>
<query xmlns='jabber:iq:roster'>
<item
jid='contact@example.org'
subscription='none'
name='MyContact'>
<group>MyBuddies</group>
</item>
</query>
</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 type='result' id='set1'/>
<iq type='result' id='set1'/>
3. If the user wants to request a subscription to the contact's
presence information, the user's client MUST send a presence
stanza of type='subscribe' to the contact:
3. If the user wants to request a subscription to the contact's presence information, the user's client MUST send a presence stanza of type='subscribe' to the contact:
<presence to='contact@example.org' type='subscribe'/>
<presence to='contact@example.org' type='subscribe'/>
4. As a result, the user's server MUST initiate a second roster push
to all of the user's available resources that have requested the
roster, setting the contact to the pending sub-state of the
'none' subscription state; this pending sub-state is denoted by
the inclusion of the ask='subscribe' attribute in the roster
item:
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:
Saint-Andre Standards Track [Page 34] RFC 3921 XMPP IM October 2004
Saint-Andre Standards Track [Page 34] RFC 3921 XMPP IM October 2004
<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 type='set'> <query xmlns='jabber:iq:roster'> <item jid='contact@example.org' subscription='none' ask='subscribe' name='MyContact'> <group>MyBuddies</group> </item> </query> </iq>
Note: If the user did not create a roster item before sending the subscription request, the server MUST now create one on behalf of the user, then send a roster push to all of the user's available resources that have requested the roster, absent the 'name' attribute and the <group/> child shown above.
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.
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. 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):
<presence
from='user@example.com'
to='contact@example.org'
type='subscribe'/>
<presence from='user@example.com' to='contact@example.org' type='subscribe'/>
Note: If the user's server receives a presence stanza of type "error" from the contact's server, it MUST deliver the error stanza to the user, whose client MAY determine that the error is in response to the outgoing presence stanza of type "subscribe" it sent previously (e.g., by tracking an 'id' attribute) and then choose to resend the "subscribe" request or revert the roster to its previous state by sending a presence stanza of type "unsubscribe" to the contact.
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.
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
6. Upon receiving the presence stanza of type "subscribe" addressed to the contact, the contact's server MUST determine if there is at least one available resource from which the contact has requested the roster. If so, it MUST deliver the subscription request to the contact (if not, the contact's server MUST store the subscription request offline for delivery when this condition
Saint-Andre Standards Track [Page 35] RFC 3921 XMPP IM October 2004
Saint-Andre Standards Track [Page 35] RFC 3921 XMPP IM October 2004
is next met; normally this is done by adding a roster item for
the contact to the user's roster, with a state of "None + Pending
In" as defined under Subscription States (Section 9), however a
server SHOULD NOT push or deliver roster items in that state to
the contact). No matter when the subscription request is
delivered, the contact must decide whether or not to approve it
(subject to the contact's configured preferences, the contact's
client MAY approve or refuse the subscription request without
presenting it to the contact). Here we assume the "happy path"
that the contact approves the subscription request (the alternate
flow of declining the subscription request is defined in Section
8.2.1). In this case, the contact's client (1) SHOULD perform a
roster set specifying the desired nickname and group for the user
(if any); and (2) MUST send a presence stanza of type
"subscribed" to the user in order to approve the subscription
request.
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.
<iq type='set' id='set2'>
<query xmlns='jabber:iq:roster'>
<item
jid='user@example.com'
name='SomeUser'>
<group>SomeGroup</group>
</item>
</query>
</iq>
<iq type='set' id='set2'> <query xmlns='jabber:iq:roster'> <item jid='user@example.com' name='SomeUser'> <group>SomeGroup</group> </item> </query> </iq>
<presence to='user@example.com' type='subscribed'/>
<presence to='user@example.com' type='subscribed'/>
7. As a result, the contact's server (1) MUST initiate a roster push
to all available resources associated with the contact that have
requested the roster, containing a roster item for the user with
the subscription state set to 'from' (the server MUST send this
even if the contact did not perform a roster set); (2) MUST
return an IQ result to the sending resource indicating the
success of the roster set; (3) MUST route the presence stanza of
type "subscribed" to the user, first stamping the 'from' address
as the bare JID (<contact@example.org>) of the contact; and (4)
MUST send available presence from all of the contact's available
resources to the user:
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:
Saint-Andre Standards Track [Page 36] RFC 3921 XMPP IM October 2004
Saint-Andre Standards Track [Page 36] RFC 3921 XMPP IM October 2004
<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 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 type='result' to='contact@example.org/resource' id='set2'/>
<iq type='result' to='contact@example.org/resource' id='set2'/>
<presence
from='contact@example.org'
to='user@example.com'
type='subscribed'/>
<presence from='contact@example.org' to='user@example.com' type='subscribed'/>
<presence
from='contact@example.org/resource'
to='user@example.com'/>
<presence 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.
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.
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
8. Upon receiving the presence stanza of type "subscribed" addressed to the user, the user's server MUST first verify that the contact is in the user's roster with either of the following states: (a) subscription='none' and ask='subscribe' or (b) subscription='from' and ask='subscribe'. If the contact is not in the user's roster with either of those states, the user's server MUST silently ignore the presence stanza of type "subscribed" (i.e., it MUST NOT route it to the user, modify the user's roster, or generate a roster push to the user's available resources). If the contact is in the user's roster with either of those states, the user's server (1) MUST deliver the presence stanza of type "subscribed" from the contact to the user; (2) MUST initiate a roster push to all of the user's available resources that have requested the roster, containing an updated roster item for the contact with the 'subscription' attribute set
Saint-Andre Standards Track [Page 37] RFC 3921 XMPP IM October 2004
Saint-Andre Standards Track [Page 37] RFC 3921 XMPP IM October 2004
to a value of "to"; and (3) MUST deliver the available presence
stanza received from each of the contact's available resources to
each of the user's available resources:
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:
<presence
to='user@example.com'
from='contact@example.org'
type='subscribed'/>
<presence to='user@example.com' from='contact@example.org' type='subscribed'/>
<iq type='set'>
<query xmlns='jabber:iq:roster'>
<item
jid='contact@example.org'
subscription='to'
name='MyContact'>
<group>MyBuddies</group>
</item>
</query>
</iq>
<iq type='set'> <query xmlns='jabber:iq:roster'> <item jid='contact@example.org' subscription='to' name='MyContact'> <group>MyBuddies</group> </item> </query> </iq>
<presence
from='contact@example.org/resource'
to='user@example.com/resource'/>
<presence 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. 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).
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.
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. Alternate Flow: Contact Declines Subscription Request
The above activity flow represents the "happy path" regarding the user's subscription request to the contact. The main alternate flow occurs if the contact refuses the user's subscription request, as described below.
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.
Saint-Andre Standards Track [Page 38] RFC 3921 XMPP IM October 2004
Saint-Andre Standards Track [Page 38] RFC 3921 XMPP IM October 2004
1. If the contact wants to refuse the request, the contact's client
MUST send a presence stanza of type "unsubscribed" to the user
(instead of the presence stanza of type "subscribed" sent in Step
6 of Section 8.2):
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):
<presence to='user@example.com' type='unsubscribed'/>
<presence to='user@example.com' type='unsubscribed'/>
2. As a result, the contact's server MUST route the presence stanza
of type "unsubscribed" to the user, first stamping the 'from'
address as the bare JID (<contact@example.org>) of the contact:
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:
<presence
from='contact@example.org'
to='user@example.com'
type='unsubscribed'/>
<presence from='contact@example.org' to='user@example.com' type='unsubscribed'/>
Note: If the contact's server previously added the user to the contact's roster for tracking purposes, it MUST remove the relevant item at this time.
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. 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:
<presence
from='contact@example.org'
to='user@example.com'
type='unsubscribed'/>
<presence from='contact@example.org' to='user@example.com' type='unsubscribed'/>
<iq type='set'>
<query xmlns='jabber:iq:roster'>
<item
jid='contact@example.org'
subscription='none'
name='MyContact'>
<group>MyBuddies</group>
</item>
</query>
</iq>
<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
4. Upon receiving the presence stanza of type "unsubscribed", the user SHOULD acknowledge receipt of that subscription state notification through either "affirming" it by sending a presence stanza of type "unsubscribe" to the contact or "denying" it by
Saint-Andre Standards Track [Page 39] RFC 3921 XMPP IM October 2004
Saint-Andre Standards Track [Page 39] RFC 3921 XMPP IM October 2004
sending a presence stanza of type "subscribe" to the contact;
this step does not necessarily affect the subscription state (see
Subscription States (Section 9) for details), but instead lets
the user's server know that it MUST no longer send notification
of the subscription state change to the user (see Section 9.4).
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).
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.
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. Creating a Mutual Subscription
The user and contact can build on the "happy path" described above to create a mutual subscription (i.e., a subscription of type "both"). The process is described below.
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. 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):
<presence to='user@example.com' type='subscribe'/>
<presence to='user@example.com' type='subscribe'/>
2. As a result, the contact's server (1) MUST initiate a roster push
to all available resources associated with the contact that have
requested the roster, with the user still in the 'from'
subscription state but with a pending 'to' subscription denoted
by the inclusion of the ask='subscribe' attribute in the roster
item; and (2) MUST route the presence stanza of type "subscribe"
to the user, first stamping the 'from' address as the bare JID
(<contact@example.org>) of the contact:
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:
<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 type='set'> <query xmlns='jabber:iq:roster'> <item jid='user@example.com' subscription='from' ask='subscribe' name='SomeUser'> <group>SomeGroup</group> </item> </query> </iq>
Saint-Andre Standards Track [Page 40] RFC 3921 XMPP IM October 2004
Saint-Andre Standards Track [Page 40] RFC 3921 XMPP IM October 2004
<presence
from='contact@example.org'
to='user@example.com'
type='subscribe'/>
<presence from='contact@example.org' to='user@example.com' type='subscribe'/>
Note: If the contact's server receives a presence stanza of type "error" from the user's server, it MUST deliver the error stanza to the contact, whose client MAY determine that the error is in response to the outgoing presence stanza of type "subscribe" it sent previously (e.g., by tracking an 'id' attribute) and then choose to resend the "subscribe" request or revert the roster to its previous state by sending a presence stanza of type "unsubscribe" to the user.
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.
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. 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.
<presence to='contact@example.org' type='subscribed'/>
<presence to='contact@example.org' type='subscribed'/>
4. As a result, the user's server (1) MUST initiate a roster push to
all of the user's available resources that have requested the
roster, containing a roster item for the contact with the
'subscription' attribute set to a value of "both"; (2) MUST route
the presence stanza of type "subscribed" to the contact, first
stamping the 'from' address as the bare JID (<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. 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):
Saint-Andre Standards Track [Page 41] RFC 3921 XMPP IM October 2004
Saint-Andre Standards Track [Page 41] RFC 3921 XMPP IM October 2004
<iq type='set'>
<query xmlns='jabber:iq:roster'>
<item
jid='contact@example.org'
subscription='both'
name='MyContact'>
<group>MyBuddies</group>
</item>
</query>
</iq>
<iq type='set'> <query xmlns='jabber:iq:roster'> <item jid='contact@example.org' subscription='both' name='MyContact'> <group>MyBuddies</group> </item> </query> </iq>
<presence
from='user@example.com'
to='contact@example.org'
type='subscribed'/>
<presence from='user@example.com' to='contact@example.org' type='subscribed'/>
<presence
from='user@example.com/resource'
to='contact@example.org'/>
<presence 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.
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.
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:
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:
Saint-Andre Standards Track [Page 42] RFC 3921 XMPP IM October 2004
Saint-Andre Standards Track [Page 42] RFC 3921 XMPP IM October 2004
<presence
from='user@example.com'
to='contact@example.org'
type='subscribed'/>
<presence from='user@example.com' to='contact@example.org' type='subscribed'/>
<iq type='set'>
<query xmlns='jabber:iq:roster'>
<item
jid='user@example.com'
subscription='both'
name='SomeUser'>
<group>SomeGroup</group>
</item>
</query>
</iq>
<iq type='set'> <query xmlns='jabber:iq:roster'> <item jid='user@example.com' subscription='both' name='SomeUser'> <group>SomeGroup</group> </item> </query> </iq>
<presence
from='user@example.com/resource'
to='contact@example.org/resource'/>
<presence 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. 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).
The user and the contact now have a mutual subscription to each other's presence -- i.e., the subscription is of type "both".
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. Alternate Flow: User Declines Subscription Request
The above activity flow represents the "happy path" regarding the contact's subscription request to the user. The main alternate flow occurs if the user refuses the contact's subscription request, as described below.
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. 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):
<presence to='contact@example.org' type='unsubscribed'/>
<presence to='contact@example.org' type='unsubscribed'/>
Saint-Andre Standards Track [Page 43] RFC 3921 XMPP IM October 2004
Saint-Andre Standards Track [Page 43] RFC 3921 XMPP IM October 2004
2. As a result, the user's server MUST route the presence stanza of
type "unsubscribed" to the contact, first stamping the 'from'
address as the bare JID (<user@example.com>) of the user:
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:
<presence
from='user@example.com'
to='contact@example.org'
type='unsubscribed'/>
<presence from='user@example.com' to='contact@example.org' type='unsubscribed'/>
3. Upon receiving the presence stanza of type "unsubscribed"
addressed to the contact, the contact's server (1) MUST deliver
that presence stanza to the contact; and (2) MUST initiate a
roster push to all available resources associated with the
contact that have requested the roster, containing an updated
roster item for the user with the 'subscription' attribute set to
a value of "from" and with no 'ask' attribute:
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:
<presence
from='user@example.com'
to='contact@example.org'
type='unsubscribed'/>
<presence from='user@example.com' to='contact@example.org' type='unsubscribed'/>
<iq type='set'>
<query xmlns='jabber:iq:roster'>
<item
jid='user@example.com'
subscription='from'
name='SomeUser'>
<group>SomeGroup</group>
</item>
</query>
</iq>
<iq type='set'> <query xmlns='jabber:iq:roster'> <item jid='user@example.com' subscription='from' name='SomeUser'> <group>SomeGroup</group> </item> </query> </iq>
4. Upon receiving the presence stanza of type "unsubscribed", the
contact SHOULD acknowledge receipt of that subscription state
notification through either "affirming" it by sending a presence
stanza of type "unsubscribe" to the user or "denying" it by
sending a presence stanza of type "subscribe" to the user; this
step does not necessarily affect the subscription state (see
Subscription States (Section 9) for details), but instead lets
the contact's server know that it MUST no longer send
notification of the subscription state change to the contact (see
Section 9.4).
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).
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".
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".
Saint-Andre Standards Track [Page 44] RFC 3921 XMPP IM October 2004
Saint-Andre Standards Track [Page 44] RFC 3921 XMPP IM October 2004
8.4. Unsubscribing
8.4. Unsubscribing
At any time after subscribing to a contact's presence information, a user MAY unsubscribe. While the XML that the user sends to make this happen is the same in all instances, the subsequent subscription state is different depending on the subscription state obtaining when the unsubscribe "command" is sent. Both possible scenarios are described below.
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.
8.4.1. Case #1: Unsubscribing When Subscription is Not Mutual
8.4.1. Case #1: Unsubscribing When Subscription is Not Mutual
In the first case, the user has a subscription to the contact's presence information but the contact does not have a subscription to the user's presence information (i.e., the subscription is not yet mutual).
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. 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:
<presence to='contact@example.org' type='unsubscribe'/>
<presence to='contact@example.org' type='unsubscribe'/>
2. As a result, the user's server (1) MUST send a roster push to all
of the user's available resources that have requested the roster,
containing an updated roster item for the contact with the
'subscription' attribute set to a value of "none"; and (2) MUST
route the presence stanza of type "unsubscribe" to the contact,
first stamping the 'from' address as the bare JID
(<user@example.com>) of the user:
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:
<iq type='set'>
<query xmlns='jabber:iq:roster'>
<item
jid='contact@example.org'
subscription='none'
name='MyContact'>
<group>MyBuddies</group>
</item>
</query>
</iq>
<iq type='set'> <query xmlns='jabber:iq:roster'> <item jid='contact@example.org' subscription='none' name='MyContact'> <group>MyBuddies</group> </item> </query> </iq>
<presence
from='user@example.com'
to='contact@example.org'
type='unsubscribe'/>
<presence from='user@example.com' to='contact@example.org' type='unsubscribe'/>
Saint-Andre Standards Track [Page 45] RFC 3921 XMPP IM October 2004
Saint-Andre Standards Track [Page 45] RFC 3921 XMPP IM October 2004
3. Upon receiving the presence stanza of type "unsubscribe"
addressed to the contact, the contact's server (1) MUST initiate
a roster push to all available resources associated with the
contact that have requested the roster, containing an updated
roster item for the user with the 'subscription' attribute set to
a value of "none" (if the contact is unavailable or has not
requested the roster, the contact's server MUST modify the roster
item and send that modified item the next time the contact
requests the roster); and (2) MUST deliver the "unsubscribe"
state change notification to the contact:
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:
<iq type='set'>
<query xmlns='jabber:iq:roster'>
<item
jid='user@example.com'
subscription='none'
name='SomeUser'>
<group>SomeGroup</group>
</item>
</query>
</iq>
<iq type='set'> <query xmlns='jabber:iq:roster'> <item jid='user@example.com' subscription='none' name='SomeUser'> <group>SomeGroup</group> </item> </query> </iq>
<presence
from='user@example.com'
to='contact@example.org'
type='unsubscribe'/>
<presence from='user@example.com' to='contact@example.org' type='unsubscribe'/>
4. Upon receiving the presence stanza of type "unsubscribe", the
contact SHOULD acknowledge receipt of that subscription state
notification through either "affirming" it by sending a presence
stanza of type "unsubscribed" to the user or "denying" it by
sending a presence stanza of type "subscribed" to the user; this
step does not necessarily affect the subscription state (see
Subscription States (Section 9) for details), but instead lets
the contact's server know that it MUST no longer send
notification of the subscription state change to the contact (see
Section 9.4).
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).
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. 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:
<presence
from='contact@example.org'
to='user@example.com'
type='unsubscribed'/>
<presence from='contact@example.org' to='user@example.com' type='unsubscribed'/>
Saint-Andre Standards Track [Page 46] RFC 3921 XMPP IM October 2004
Saint-Andre Standards Track [Page 46] RFC 3921 XMPP IM October 2004
<presence
from='contact@example.org/resource'
to='user@example.com'
type='unavailable'/>
<presence from='contact@example.org/resource' to='user@example.com' type='unavailable'/>
6. When the user's server receives the presence stanzas of type
"unsubscribed" and "unavailable", it MUST deliver them to the
user:
6. When the user's server receives the presence stanzas of type "unsubscribed" and "unavailable", it MUST deliver them to the user:
<presence
from='contact@example.org'
to='user@example.com'
type='unsubscribed'/>
<presence from='contact@example.org' to='user@example.com' type='unsubscribed'/>
<presence
from='contact@example.org/resource'
to='user@example.com'
type='unavailable'/>
<presence from='contact@example.org/resource' to='user@example.com' type='unavailable'/>
7. Upon receiving the presence stanza of type "unsubscribed", the
user SHOULD acknowledge receipt of that subscription state
notification through either "affirming" it by sending a presence
stanza of type "unsubscribe" to the contact or "denying" it by
sending a presence stanza of type "subscribe" to the contact;
this step does not necessarily affect the subscription state (see
Subscription States (Section 9) for details), but instead lets
the user's server know that it MUST no longer send notification
of the subscription state change to the user (see Section 9.4).
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).
8.4.2. Case #2: Unsubscribing When Subscription is Mutual
8.4.2. Case #2: Unsubscribing When Subscription is Mutual
In the second case, the user has a subscription to the contact's presence information and the contact also has a subscription to the user's presence information (i.e., the subscription is mutual).
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. 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:
<presence to='contact@example.org' type='unsubscribe'/>
<presence to='contact@example.org' type='unsubscribe'/>
2. As a result, the user's server (1) MUST send a roster push to all
of the user's available resources that have requested the roster,
containing an updated roster item for the contact with the
'subscription' attribute set to a value of "from"; and (2) MUST
route the presence stanza of type "unsubscribe" to the contact,
first stamping the 'from' address as the bare JID
(<user@example.com>) of the user:
Saint-Andre Standards Track [Page 47] RFC 3921 XMPP IM October 2004
<iq type='set'>
<query xmlns='jabber:iq:roster'>
<item
jid='contact@example.org'
subscription='from'
name='MyContact'>
<group>MyBuddies</group>
</item>
</query>
</iq>
<presence
from='user@example.com'
to='contact@example.org'
type='unsubscribe'/>
3. Upon receiving the presence stanza of type "unsubscribe"
addressed to the contact, the contact's server (1) MUST initiate
a roster push to all available resources associated with the
contact that have requested the roster, containing an updated
roster item for the user with the 'subscription' attribute set to
a value of "to" (if the contact is unavailable or has not
requested the roster, the contact's server MUST modify the roster
item and send that modified item the next time the contact
requests the roster); and (2) MUST deliver the "unsubscribe"
state change notification to the contact:
<iq type='set'>
<query xmlns='jabber:iq:roster'>
<item
jid='user@example.com'
subscription='to'
name='SomeUser'>
<group>SomeGroup</group>
</item>
</query>
</iq>
<presence
from='user@example.com'
to='contact@example.org'
type='unsubscribe'/>
4. Upon receiving the presence stanza of type "unsubscribe", the
contact SHOULD acknowledge receipt of that subscription state
notification through either "affirming" it by sending a presence
stanza of type "unsubscribed" to the user or "denying" it by
sending a presence stanza of type "subscribed" to the user; this
Saint-Andre Standards Track [Page 48] RFC 3921 XMPP IM October 2004
step does not necessarily affect the subscription state (see
Subscription States (Section 9) for details), but instead lets
the contact's server know that it MUST no longer send
notification of the subscription state change to the contact (see
Section 9.4).
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:
<presence
from='contact@example.org'
to='user@example.com'
type='unsubscribed'/>
<presence
from='contact@example.org/resource'
to='user@example.com'
type='unavailable'/>
6. When the user's server receives the presence stanzas of type
"unsubscribed" and "unavailable", it MUST deliver them to the
user:
<presence
from='contact@example.org'
to='user@example.com'
type='unsubscribed'/>
<presence
from='contact@example.org/resource'
to='user@example.com'
type='unavailable'/>
7. Upon receiving the presence stanza of type "unsubscribed", the
user SHOULD acknowledge receipt of that subscription state
notification through either "affirming" it by sending a presence
stanza of type "unsubscribe" to the contact or "denying" it by
sending a presence stanza of type "subscribe" to the contact;
this step does not necessarily affect the subscription state (see
Subscription States (Section 9) for details), but instead lets
the user's server know that it MUST no longer send notification
of the subscription state change to the user (see Section 9.4).
Note: Obviously this does not result in removal of the roster item from the user's roster, and the contact still has a subscription to the user's presence information. In order to both completely cancel
Saint-Andre Standards Track [Page 49] RFC 3921 XMPP IM October 2004
a mutual subscription and fully remove the roster item from the user's roster, the user SHOULD update the roster item with subscription='remove' as defined under Removing a Roster Item and Cancelling All Subscriptions (Section 8.6).
8.5. Cancelling a Subscription
At any time after approving a subscription request from a user, a contact MAY cancel that subscription. While the XML that the contact sends to make this happen is the same in all instances, the subsequent subscription state is different depending on the subscription state obtaining when the cancellation was sent. Both possible scenarios are described below.
8.5.1. Case #1: Cancelling When Subscription is Not Mutual
In the first case, the user has a subscription to the contact's presence information but the contact does not have a subscription to the user's presence information (i.e., the subscription is not yet mutual).
1. If the contact wants to cancel the user's subscription, the
contact MUST send a presence stanza of type "unsubscribed" to the
user:
<presence to='user@example.com' type='unsubscribed'/>
2. As a result, the contact's server (1) MUST send a roster push to
all of the contact's available resources that have requested the
roster, containing an updated roster item for the user with the
'subscription' attribute set to a value of "none"; (2) MUST route
the presence stanza of type "unsubscribed" to the user, first
stamping the 'from' address as the bare JID
(<contact@example.org>) of the contact; and (3) SHOULD send
unavailable presence from all of the contact's available
resources to the user:
<iq type='set'>
<query xmlns='jabber:iq:roster'>
<item
jid='user@example.com'
subscription='none'
name='SomeUser'>
<group>SomeGroup</group>
</item>
</query>
</iq>
Saint-Andre Standards Track [Page 50] RFC 3921 XMPP IM October 2004
<presence
from='contact@example.org'
to='user@example.com'
type='unsubscribed'/>
<presence
from='contact@example.org/resource'
to='user@example.com'
type='unavailable'/>
3. Upon receiving the presence stanza of type "unsubscribed"
addressed to the user, the user's server (1) MUST initiate a
roster push to all of the user's available resources that have
requested the roster, containing an updated roster item for the
contact with the 'subscription' attribute set to a value of
"none" (if the user is unavailable or has not requested the
roster, the user's server MUST modify the roster item and send
that modified item the next time the user requests the roster);
(2) MUST deliver the "unsubscribed" state change notification to
all of the user's available resources; and (3) MUST deliver the
unavailable presence to all of the user's available resources:
<iq type='set'>
<query xmlns='jabber:iq:roster'>
<item
jid='contact@example.org'
subscription='none'
name='MyContact'>
<group>MyBuddies</group>
</item>
</query>
</iq>
<presence
from='contact@example.org'
to='user@example.com'
type='unsubscribed'/>
<presence
from='contact@example.org/resource'
to='user@example.com'
type='unavailable'/>
4. Upon receiving the presence stanza of type "unsubscribed", the
user SHOULD acknowledge receipt of that subscription state
notification through either "affirming" it by sending a presence
stanza of type "unsubscribe" to the contact or "denying" it by
sending a presence stanza of type "subscribe" to the contact;
Saint-Andre Standards Track [Page 51] RFC 3921 XMPP IM October 2004
this step does not necessarily affect the subscription state (see
Subscription States (Section 9) for details), but instead lets
the user's server know that it MUST no longer send notification
of the subscription state change to the user (see Section 9.4).
8.5.2. Case #2: Cancelling When Subscription is Mutual
In the second case, the user has a subscription to the contact's presence information and the contact also has a subscription to the user's presence information (i.e., the subscription is mutual).
1. If the contact wants to cancel the user's subscription, the
contact MUST send a presence stanza of type "unsubscribed" to the
user:
<presence to='user@example.com' type='unsubscribed'/>
2. As a result, the contact's server (1) MUST send a roster push to
all of the contact's available resources that have requested the
roster, containing an updated roster item for the user with the
'subscription' attribute set to a value of "to"; (2) MUST route
the presence stanza of type "unsubscribed" to the user, first
stamping the 'from' address as the bare JID
(<contact@example.org>) of the contact; and (3) SHOULD send
unavailable presence from all of the contact's available
resources to all of the user's available resources:
<iq type='set'>
<query xmlns='jabber:iq:roster'>
<item
jid='user@example.com'
subscription='to'
name='SomeUser'>
<group>SomeGroup</group>
</item>
</query>
</iq>
<presence
from='contact@example.org'
to='user@example.com'
type='unsubscribed'/>
<presence
from='contact@example.org/resource'
to='user@example.com'
type='unavailable'/>
Saint-Andre Standards Track [Page 52] RFC 3921 XMPP IM October 2004
3. Upon receiving the presence stanza of type "unsubscribed"
addressed to the user, the user's server (1) MUST initiate a
roster push to all of the user's available resources that have
requested the roster, containing an updated roster item for the
contact with the 'subscription' attribute set to a value of
"from" (if the user is unavailable or has not requested the
roster, the user's server MUST modify the roster item and send
that modified item the next time the user requests the roster);
and (2) MUST deliver the "unsubscribed" state change notification
to all of the user's available resources; and (3) MUST deliver
the unavailable presence to all of the user's available
resources:
<iq type='set'>
<query xmlns='jabber:iq:roster'>
<item
jid='contact@example.org'
subscription='from'
name='MyContact'>
<group>MyBuddies</group>
</item>
</query>
</iq>
<presence
from='contact@example.org'
to='user@example.com'
type='unsubscribed'/>
<presence
from='contact@example.org/resource'
to='user@example.com'
type='unavailable'/>
4. Upon receiving the presence stanza of type "unsubscribed", the
user SHOULD acknowledge receipt of that subscription state
notification through either "affirming" it by sending a presence
stanza of type "unsubscribe" to the contact or "denying" it by
sending a presence stanza of type "subscribe" to the contact;
this step does not necessarily affect the subscription state (see
Subscription States (Section 9) for details), but instead lets
the user's server know that it MUST no longer send notification
of the subscription state change to the user (see Section 9.4).
Note: Obviously this does not result in removal of the roster item from the contact's roster, and the contact still has a subscription to the user's presence information. In order to both completely cancel a mutual subscription and fully remove the roster item from
Saint-Andre Standards Track [Page 53] RFC 3921 XMPP IM October 2004
the contact's roster, the contact should update the roster item with subscription='remove' as defined under Removing a Roster Item and Cancelling All Subscriptions (Section 8.6).
8.6. Removing a Roster Item and Cancelling All Subscriptions
Because there may be many steps involved in completely removing a roster item and cancelling subscriptions in both directions, the roster management protocol includes a "shortcut" method for doing so. The process may be initiated no matter what the current subscription state is by sending a roster set containing an item for the contact with the 'subscription' attribute set to a value of "remove":
<iq type='set' id='remove1'>
<query xmlns='jabber:iq:roster'>
<item
jid='contact@example.org'
subscription='remove'/>
</query>
</iq>
When the user removes a contact from his or her roster by setting the 'subscription' attribute to a value of "remove", the user's server (1) MUST automatically cancel any existing presence subscription between the user and the contact (both 'to' and 'from' as appropriate); (2) MUST remove the roster item from the user's roster and inform all of the user's available resources that have requested the roster of the roster item removal; (3) MUST inform the resource that initiated the removal of success; and (4) SHOULD send unavailable presence from all of the user's available resources to the contact:
ユーザがその人の当直表から「取り外してください」の値に'購読'属性を設定することによって接触を取り除くとき、ユーザのサーバ(1)は自動的にユーザと接触('to'と'from'の適切な同じくらい両方)の間のどんな既存の存在購読も中止しなければなりません。 (2) ユーザの当直表から当直表商品を取り外して、当直表項目取り外しに関する当直表を要求したユーザの利用可能資源についてすべてを知らせなければなりません。 (3) 成功の取り外しを開始したリソースを知らせなければなりません。 (4) そして、SHOULDはユーザの利用可能資源のすべてから接触に入手できない存在を送ります:
<presence
from='user@example.com'
to='contact@example.org'
type='unsubscribe'/>
=' user@example.com '等しく' contact@example.org 'タイプ='は外し'/>からの<存在
<presence
from='user@example.com'
to='contact@example.org'
type='unsubscribed'/>
=' user@example.com '等しく' contact@example.org 'タイプ='は外した'/>からの<存在
Saint-Andre Standards Track [Page 54] RFC 3921 XMPP IM October 2004
サンアンドレ規格はXMPP不-2004年10月にRFC3921を追跡します[54ページ]。
<iq type='set'>
<query xmlns='jabber:iq:roster'>
<item
jid='contact@example.org'
subscription='remove'/>
</query>
</iq>
<iqタイプは'セット'><質問xmlnsは'取り外し'/></質問></iq'おしゃべり:iq:当直表'><項目jid=' contact@example.org '購読=>と等しいこと'と等しいです。
<iq type='result' id='remove1'/>
<iqタイプ='結果'イド='remove1'/>。
<presence
from='user@example.com/resource'
to='contact@example.org'
type='unavailable'/>
=' user@example.com/resource 'から=' contact@example.org 'タイプまでの<存在は'入手できません、な'/>と等しいです。
Upon receiving the presence stanza of type "unsubscribe", the contact's server (1) MUST initiate a roster push to all available resources associated with the contact that have requested the roster, containing an updated roster item for the user with the 'subscription' attribute set to a value of "to" (if the contact is unavailable or has not requested the roster, the contact's server MUST modify the roster item and send that modified item the next time the contact requests the roster); and (2) MUST also deliver the "unsubscribe" state change notification to all of the contact's available resources:
「外してください」、接触のサーバ(1)がそうしなければならないタイプの存在スタンザを受け取ったら、当直表を要求した接触に関連しているすべての利用可能資源に当直表プッシュを開始してください、'購読'属性セットでユーザのためのアップデートされた当直表項目を“to"の値に含んでいて(接触が入手できないか、または当直表を要求していないなら、接触のサーバは、接触が当直表を要求する次の時に当直表項目を変更して、その変更された商品を送らなければなりません)。 そして、また、(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:当直表'><項目jid=と等しく' user@example.com '購読は'SomeUser'という><グループ>SomeGroup</グループ>の</品目></質問></iq'to'名=>と等しいこと'と等しいです。
<presence
from='user@example.com'
to='contact@example.org'
type='unsubscribe'/>
=' user@example.com '等しく' contact@example.org 'タイプ='は外し'/>からの<存在
Upon receiving the presence stanza of type "unsubscribed", the contact's server (1) MUST initiate a roster push to all available resources associated with the contact that have requested the roster, containing an updated roster item for the user with the 'subscription' attribute set to a value of "none" (if the contact is unavailable or has not requested the roster, the contact's server
タイプの存在スタンザが「外した」受信のときに、接触のサーバ(1)は当直表を要求した接触に関連しているすべての利用可能資源に当直表プッシュを開始しなければなりません、'購読'属性セットで「なにも」の値にユーザのためのアップデートされた当直表項目を含んでいて(接触は、入手できないか、または当直表、接触のサーバを要求していません。
Saint-Andre Standards Track [Page 55] RFC 3921 XMPP IM October 2004
サンアンドレ規格はXMPP不-2004年10月にRFC3921を追跡します[55ページ]。
MUST modify the roster item and send that modified item the next time the contact requests the roster); and (2) MUST also deliver the "unsubscribe" state change notification to all of the contact's available resources:
接触が当直表を要求する次の時に当直表項目を変更して、その変更された商品を送らなければならない、)、。 そして、(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 '購読は'なにも'名=と等しく'SomeUserと等しく'><グループ>SomeGroup</グループ>の</品目></質問></iq>'と等しいです。
<presence
from='user@example.com'
to='contact@example.org'
type='unsubscribed'/>
=' user@example.com '等しく' contact@example.org 'タイプ='は外した'/>からの<存在
Upon receiving the presence stanza of type "unavailable" addressed to the contact, the contact's server MUST deliver the unavailable presence to all of the user's available resources:
タイプの「入手できません、な」存在スタンザが接触に扱った受信のときに、接触のサーバはユーザの利用可能資源のすべてに入手できない存在を提供しなければなりません:
<presence
from='user@example.com/resource'
to='contact@example.org'
type='unavailable'/>
=' user@example.com/resource 'から=' contact@example.org 'タイプまでの<存在は'入手できません、な'/>と等しいです。
Note: When the user removes the contact from the user's roster, the end state of the contact's roster is that the user is still in the contact's roster with a subscription state of "none"; in order to completely remove the roster item for the user, the contact needs to also send a roster removal request.
以下に注意してください。 ユーザがユーザの当直表から接触を取り除くとき、接触の当直表の端の状態はユーザが「なにも」の購読状態と共にまだ接触の当直表にいるということです。 当直表商品をユーザに完全に取り外すために、接触は、また、当直表取り外し要求を送る必要があります。
9. Subscription States
9. 購読州
This section provides detailed information about subscription states and server handling of subscription-related presence stanzas (i.e., presence stanzas of type "subscribe", "subscribed", "unsubscribe", and "unsubscribed").
このセクションは購読関連の存在スタンザの購読州とサーバ取り扱いの詳細な情報を提供します(すなわち、タイプの存在スタンザは、「申し込ん」で、「申し込ん」で、「外し」て、「外しました」)。
9.1. Defined States
9.1. 定義された州
There are nine possible subscription states, which are described here from the user's (not contact's) perspective:
9つの可能な購読州があります:(州はここでユーザ(接触のものでない)の見解から説明されます)。
Saint-Andre Standards Track [Page 56] RFC 3921 XMPP IM October 2004
サンアンドレ規格はXMPP不-2004年10月にRFC3921を追跡します[56ページ]。
1. "None" = contact and user are not subscribed to each other, and
neither has requested a subscription from the other
1. 接触と「なにも」=ユーザは互いに申し込まれません、そして、どちらももう片方から購読を要求していません。
2. "None + Pending Out" = contact and user are not subscribed to
each other, and user has sent contact a subscription request but
contact has not replied yet
2. 「なにも、+、Outまで、」 =接触とユーザは互いに申し込まれないで、またユーザは購読要求を接触に送りましたが、接触はまだ返答していません。
3. "None + Pending In" = contact and user are not subscribed to each
other, and contact has sent user a subscription request but user
has not replied yet (note: contact's server SHOULD NOT push or
deliver roster items in this state, but instead SHOULD wait until
contact has approved subscription request from user)
3. 「なにも、+、Inまで、」 =接触とユーザは互いに申し込まれないで、また接触は購読要求をユーザに送りましたが、ユーザはまだ返答していません。(注意: 接触のサーバSHOULD NOTはこの状態で当直表商品を押すか、または提供しますが、代わりに、接触がユーザからの購読要求を承認するまで、SHOULDは待っています)
4. "None + Pending Out/In" = contact and user are not subscribed to
each other, contact has sent user a subscription request but user
has not replied yet, and user has sent contact a subscription
request but contact has not replied yet
4. 「なにもに、+は」 =接触とユーザのOut/まで互いに申し込まれませんが、接触は購読要求をユーザに送りましたが、ユーザはまだ返答していなくて、またユーザは購読要求を接触に送りましたが、接触はまだ返答していません。
5. "To" = user is subscribed to contact (one-way)
5. "To"=ユーザは接触に申し込まれます。(一方向)です。
6. "To + Pending In" = user is subscribed to contact, and contact
has sent user a subscription request but user has not replied yet
6. 「+ 未定のIn」=ユーザは接触に申し込まれます、そして、接触は購読要求をユーザに送りましたが、ユーザはまだ返答していません。
7. "From" = contact is subscribed to user (one-way)
7. "From"=接触はユーザに申し込まれます。(一方向)です。
8. "From + Pending Out" = contact is subscribed to user, and user
has sent contact a subscription request but contact has not
replied yet
8. 「+ 未定のOut」=接触はユーザに申し込まれます、そして、ユーザは購読要求を接触に送りましたが、接触はまだ返答していません。
9. "Both" = user and contact are subscribed to each other (two-way)
9. ユーザと「両方」=接触は互いに申し込まれます。(ツーウェイ)
9.2. Server Handling of Outbound Presence Subscription Stanzas
9.2. 外国行きの存在購読スタンザのサーバ取り扱い
Outbound presence subscription stanzas enable the user to manage his or her subscription to the contact's presence information (via the "subscribe" and "unsubscribe" types), and to manage the contact's access to the user's presence information (via the "subscribed" and "unsubscribed" types).
外国行きの存在購読スタンザは、ユーザが接触の存在情報(「申し込んでください」と「外してください」タイプを通した)のその人の購読を管理して、ユーザの存在情報(「申し込まれ」て「外された」タイプを通した)への接触のアクセスを管理するのを可能にします。
Because it is possible for the user's server and the contact's server to lose synchronization regarding subscription states, the user's server MUST without exception route all outbound presence stanzas of type "subscribe" or "unsubscribe" to the contact so that the user is able to resynchronize his or her subscription to the contact's presence information if needed.
ユーザのサーバと接触のサーバが購読州に関して同期を失うのが、可能であるので、ユーザのサーバが例外なしでタイプのスタンザが接触に「申し込む」か、または「外す」すべての外国行きの存在を発送しなければならないので、必要であるなら、ユーザは接触の存在情報のその人の購読を再連動させることができます。
Saint-Andre Standards Track [Page 57] RFC 3921 XMPP IM October 2004
サンアンドレ規格はXMPP不-2004年10月にRFC3921を追跡します[57ページ]。
The user's server SHOULD NOT route a presence stanza of type "subscribed" or "unsubscribed" to the contact if the stanza does not result in a subscription state change from the user's perspective, and MUST NOT make a state change. If the stanza results in a subscription state change, the user's server MUST route the stanza to the contact and MUST make the appropriate state change. These rules are summarized in the following tables.
ユーザのサーバSHOULD NOTはスタンザが州がユーザの見解から変えて、州の変更をしてはいけない購読をもたらさないなら、「申し込まれる」か、または接触に「外された」タイプの存在スタンザを発送します。 購読状態のスタンザ結果が変化するなら、ユーザのサーバは、スタンザを接触に発送しなければならなくて、適切な州の変更を行わなければなりません。 これらの規則は以下のテーブルにまとめられます。
Table 1: Recommended handling of outbound "subscribed" stanzas
テーブル1: 外国行きの「申し込まれた」スタンザのお勧めの取り扱い
+----------------------------------------------------------------+ | EXISTING STATE | ROUTE? | NEW STATE | +----------------------------------------------------------------+ | "None" | no | no state change | | "None + Pending Out" | no | no state change | | "None + Pending In" | yes | "From" | | "None + Pending Out/In" | yes | "From + Pending Out" | | "To" | no | no state change | | "To + Pending In" | yes | "Both" | | "From" | no | no state change | | "From + Pending Out" | no | no state change | | "Both" | no | no state change | +----------------------------------------------------------------+
+----------------------------------------------------------------+ | 現状| ルート? | 新しい状態| +----------------------------------------------------------------+ | 「なにも」| いいえ| 州の変化がありません。| | 「なにも、+ 未定のアウト、」| いいえ| 州の変化がありません。| | 「なにも、中で未定の+、」| はい| "From"| | 「なにも、+ 未定のアウト/コネ、」| はい| 「+ 未定のアウト」| | "To"| いいえ| 州の変化がありません。| | 「中で未定の+」| はい| 「両方」| | "From"| いいえ| 州の変化がありません。| | 「+ 未定のアウト」| いいえ| 州の変化がありません。| | 「両方」| いいえ| 州の変化がありません。| +----------------------------------------------------------------+
Table 2: Recommended handling of outbound "unsubscribed" stanzas
テーブル2: 外国行きの「外された」スタンザのお勧めの取り扱い
+----------------------------------------------------------------+ | EXISTING STATE | ROUTE? | NEW STATE | +----------------------------------------------------------------+ | "None" | no | no state change | | "None + Pending Out" | no | no state change | | "None + Pending In" | yes | "None" | | "None + Pending Out/In" | yes | "None + Pending Out" | | "To" | no | no state change | | "To + Pending In" | yes | "To" | | "From" | yes | "None" | | "From + Pending Out" | yes | "None + Pending Out" | | "Both" | yes | "To" | +----------------------------------------------------------------+
+----------------------------------------------------------------+ | 現状| ルート? | 新しい状態| +----------------------------------------------------------------+ | 「なにも」| いいえ| 州の変化がありません。| | 「なにも、+ 未定のアウト、」| いいえ| 州の変化がありません。| | 「なにも、中で未定の+、」| はい| 「なにも」| | 「なにも、+ 未定のアウト/コネ、」| はい| 「なにも、+ 未定のアウト、」| | "To"| いいえ| 州の変化がありません。| | 「中で未定の+」| はい| "To"| | "From"| はい| 「なにも」| | 「+ 未定のアウト」| はい| 「なにも、+ 未定のアウト、」| | 「両方」| はい| "To"| +----------------------------------------------------------------+
9.3. Server Handling of Inbound Presence Subscription Stanzas
9.3. 本国行きの存在購読スタンザのサーバ取り扱い
Inbound presence subscription stanzas request a subscription-related action from the user (via the "subscribe" type), inform the user of subscription-related actions taken by the contact (via the "unsubscribe" type), or enable the contact to manage the user's access to the contact's presence information (via the "subscribed" and "unsubscribed" types).
本国行きの存在購読スタンザは、ユーザ(「申し込んでください」というタイプを通した)から購読関連の動作を要求するか、接触(「外してください」というタイプを通した)によって取られた購読関連の行動についてユーザに知らせるか、または接触が接触の存在情報(「申し込まれ」て「外された」タイプを通した)へのユーザのアクセスを管理するのを可能にします。
Saint-Andre Standards Track [Page 58] RFC 3921 XMPP IM October 2004
サンアンドレ規格はXMPP不-2004年10月にRFC3921を追跡します[58ページ]。
When the user's server receives a subscription request for the user from the contact (i.e., a presence stanza of type "subscribe"), it MUST deliver that request to the user for approval if the user has not already granted the contact access to the user's presence information and if there is no pending inbound subscription request; however, the user's server SHOULD NOT deliver the new request if there is a pending inbound subscription request, since the previous subscription request will have been recorded. If the user has already granted the contact access to the user's presence information, the user's server SHOULD auto-reply to an inbound presence stanza of type "subscribe" from the contact by sending a presence stanza of type "subscribed" to the contact on behalf of the user; this rule enables the contact to resynchronize the subscription state if needed. These rules are summarized in the following table.
ユーザのサーバが接触からユーザを求める購読要求を受け取るとき(すなわち、タイプの存在スタンザは「申し込まれる」)、ユーザが既にユーザの存在情報への接触アクセスを承諾していなくて、またどんな未定の本国行きの購読要求もなければ、承認のためにその要求をユーザに提供しなければなりません。 しかしながら、未定の本国行きの購読要求があれば、ユーザのサーバSHOULD NOTは新しい要求を提供します、前の購読要求が記録されてしまうだろうので。 ユーザが、タイプの本国行きの存在スタンザへの既にユーザの存在情報への接触アクセス、ユーザのものに与えられたサーバSHOULD自動返答が接触から発信することによって「申し込まれること」を持っているなら、タイプの存在スタンザはユーザを代表して接触に「申し込まれました」。 必要であるなら、この規則は、接触が購読状態を再連動させるのを可能にします。 これらの規則は以下のテーブルにまとめられます。
Table 3: Recommended handling of inbound "subscribe" stanzas
テーブル3: 「申し込んでください」という本国行きのスタンザのお勧めの取り扱い
+------------------------------------------------------------------+ | EXISTING STATE | DELIVER? | NEW STATE | +------------------------------------------------------------------+ | "None" | yes | "None + Pending In" | | "None + Pending Out" | yes | "None + Pending Out/In" | | "None + Pending In" | no | no state change | | "None + Pending Out/In" | no | no state change | | "To" | yes | "To + Pending In" | | "To + Pending In" | no | no state change | | "From" | no * | no state change | | "From + Pending Out" | no * | no state change | | "Both" | no * | no state change | +------------------------------------------------------------------+
+------------------------------------------------------------------+ | 現状| 配送しますか? | 新しい状態| +------------------------------------------------------------------+ | 「なにも」| はい| 「なにも、中で未定の+、」| | 「なにも、+ 未定のアウト、」| はい| 「なにも、+ 未定のアウト/コネ、」| | 「なにも、中で未定の+、」| いいえ| 州の変化がありません。| | 「なにも、+ 未定のアウト/コネ、」| いいえ| 州の変化がありません。| | "To"| はい| 「中で未定の+」| | 「中で未定の+」| いいえ| 州の変化がありません。| | "From"| *がありません。| 州の変化がありません。| | 「+ 未定のアウト」| *がありません。| 州の変化がありません。| | 「両方」| *がありません。| 州の変化がありません。| +------------------------------------------------------------------+
* Server SHOULD auto-reply with "subscribed" stanza
* 「申し込まれた」スタンザがあるサーバSHOULD自動返答
When the user's server receives a presence stanza of type "unsubscribe" for the user from the contact, if the stanza results in a subscription state change from the user's perspective then the user's server SHOULD auto-reply by sending a presence stanza of type "unsubscribed" to the contact on behalf of the user, MUST deliver the "unsubscribe" stanza to the user, and MUST change the state. If no subscription state change results, the user's server SHOULD NOT deliver the stanza and MUST NOT change the state. These rules are summarized in the following table.
ユーザのサーバが発信することによってタイプはユーザのために接触から「外します」、購読状態のスタンザ結果がユーザの見解次に、ユーザのサーバSHOULDから変化するなら自動返答の存在スタンザを受け取るとき、タイプの存在スタンザが、ユーザを代表して接触に「外し」て、「外してください」というスタンザをユーザに提供しなければならなくて、状態を変えなければなりません。 購読州の変化結果、どんなユーザのサーバSHOULD NOTもスタンザを提供して、状態を変えてはいけないなら。 これらの規則は以下のテーブルにまとめられます。
Saint-Andre Standards Track [Page 59] RFC 3921 XMPP IM October 2004
サンアンドレ規格はXMPP不-2004年10月にRFC3921を追跡します[59ページ]。
Table 4: Recommended handling of inbound "unsubscribe" stanzas
テーブル4: 「外してください」という本国行きのスタンザのお勧めの取り扱い
+------------------------------------------------------------------+ | EXISTING STATE | DELIVER? | NEW STATE | +------------------------------------------------------------------+ | "None" | no | no state change | | "None + Pending Out" | no | no state change | | "None + Pending In" | yes * | "None" | | "None + Pending Out/In" | yes * | "None + Pending Out" | | "To" | no | no state change | | "To + Pending In" | yes * | "To" | | "From" | yes * | "None" | | "From + Pending Out" | yes * | "None + Pending Out | | "Both" | yes * | "To" | +------------------------------------------------------------------+
+------------------------------------------------------------------+ | 現状| 配送しますか? | 新しい状態| +------------------------------------------------------------------+ | 「なにも」| いいえ| 州の変化がありません。| | 「なにも、+ 未定のアウト、」| いいえ| 州の変化がありません。| | 「なにも、中で未定の+、」| はい*| 「なにも」| | 「なにも、+ 未定のアウト/コネ、」| はい*| 「なにも、+ 未定のアウト、」| | "To"| いいえ| 州の変化がありません。| | 「中で未定の+」| はい*| "To"| | "From"| はい*| 「なにも」| | 「+ 未定のアウト」| はい*| 「なにも、+ 未定のアウト、」| | 「両方」| はい*| "To"| +------------------------------------------------------------------+
* Server SHOULD auto-reply with "unsubscribed" stanza
* 「外された」スタンザがあるサーバSHOULD自動返答
When the user's server receives a presence stanza of type "subscribed" for the user from the contact, it MUST NOT deliver the stanza to the user and MUST NOT change the subscription state if there is no pending outbound request for access to the contact's presence information. If there is a pending outbound request for access to the contact's presence information and the inbound presence stanza of type "subscribed" results in a subscription state change, the user's server MUST deliver the stanza to the user and MUST change the subscription state. If the user already has access to the contact's presence information, the inbound presence stanza of type "subscribed" does not result in a subscription state change; therefore the user's server SHOULD NOT deliver the stanza to the user and MUST NOT change the subscription state. These rules are summarized in the following table.
ユーザのサーバがユーザのために接触から「申し込まれた」タイプの存在スタンザを受け取るとき、接触の存在情報へのアクセスを求めるどんな未定の外国行きの要求もなければ、それは、スタンザをユーザに提供してはいけなくて、購読状態を変えてはいけません。 接触の存在情報へのアクセスを求める未定の外国行きの要求があって、タイプの本国行きの存在スタンザが購読州の変化で結果を「申し込んだ」なら、ユーザのサーバは、スタンザをユーザに提供しなければならなくて、購読状態を変えなければなりません。 ユーザが既に接触の存在情報に近づく手段を持つなら、「申し込まれた」タイプの本国行きの存在スタンザは購読州の変化をもたらしません。 したがって、ユーザのサーバSHOULD NOTはスタンザをユーザに提供して、購読状態を変えてはいけません。 これらの規則は以下のテーブルにまとめられます。
Table 5: Recommended handling of inbound "subscribed" stanzas
テーブル5: 本国行きの「申し込まれた」スタンザのお勧めの取り扱い
+------------------------------------------------------------------+ | EXISTING STATE | DELIVER? | NEW STATE | +------------------------------------------------------------------+ | "None" | no | no state change | | "None + Pending Out" | yes | "To" | | "None + Pending In" | no | no state change | | "None + Pending Out/In" | yes | "To + Pending In" | | "To" | no | no state change | | "To + Pending In" | no | no state change | | "From" | no | no state change | | "From + Pending Out" | yes | "Both" | | "Both" | no | no state change | +------------------------------------------------------------------+
+------------------------------------------------------------------+ | 現状| 配送しますか? | 新しい状態| +------------------------------------------------------------------+ | 「なにも」| いいえ| 州の変化がありません。| | 「なにも、+ 未定のアウト、」| はい| "To"| | 「なにも、中で未定の+、」| いいえ| 州の変化がありません。| | 「なにも、+ 未定のアウト/コネ、」| はい| 「中で未定の+」| | "To"| いいえ| 州の変化がありません。| | 「中で未定の+」| いいえ| 州の変化がありません。| | "From"| いいえ| 州の変化がありません。| | 「+ 未定のアウト」| はい| 「両方」| | 「両方」| いいえ| 州の変化がありません。| +------------------------------------------------------------------+
Saint-Andre Standards Track [Page 60] RFC 3921 XMPP IM October 2004
サンアンドレ規格はXMPP不-2004年10月にRFC3921を追跡します[60ページ]。
When the user's server receives a presence stanza of type "unsubscribed" for the user from the contact, it MUST deliver the stanza to the user and MUST change the subscription state if there is a pending outbound request for access to the contact's presence information or if the user currently has access to the contact's presence information. Otherwise, the user's server SHOULD NOT deliver the stanza and MUST NOT change the subscription state. These rules are summarized in the following table.
ユーザのサーバがユーザのために接触から「外された」タイプの存在スタンザを受け取るとき、接触の存在情報へのアクセスを求める未定の外国行きの要求があるか、またはユーザが現在接触の存在情報に近づく手段を持っているなら、それは、スタンザをユーザに提供しなければならなくて、購読状態を変えなければなりません。 さもなければ、ユーザのサーバSHOULD NOTはスタンザを提供して、購読状態を変えてはいけません。 これらの規則は以下のテーブルにまとめられます。
Table 6: Recommended handling of inbound "unsubscribed" stanzas
テーブル6: 本国行きの「外された」スタンザのお勧めの取り扱い
+------------------------------------------------------------------+ | EXISTING STATE | DELIVER? | NEW STATE | +------------------------------------------------------------------+ | "None" | no | no state change | | "None + Pending Out" | yes | "None" | | "None + Pending In" | no | no state change | | "None + Pending Out/In" | yes | "None + Pending In" | | "To" | yes | "None" | | "To + Pending In" | yes | "None + Pending In" | | "From" | no | no state change | | "From + Pending Out" | yes | "From" | | "Both" | yes | "From" | +------------------------------------------------------------------+
+------------------------------------------------------------------+ | 現状| 配送しますか? | 新しい状態| +------------------------------------------------------------------+ | 「なにも」| いいえ| 州の変化がありません。| | 「なにも、+ 未定のアウト、」| はい| 「なにも」| | 「なにも、中で未定の+、」| いいえ| 州の変化がありません。| | 「なにも、+ 未定のアウト/コネ、」| はい| 「なにも、中で未定の+、」| | "To"| はい| 「なにも」| | 「中で未定の+」| はい| 「なにも、中で未定の+、」| | "From"| いいえ| 州の変化がありません。| | 「+ 未定のアウト」| はい| "From"| | 「両方」| はい| "From"| +------------------------------------------------------------------+
9.4. Server Delivery and Client Acknowledgement of Subscription
Requests and State Change Notifications
9.4. 購読要求と州の変更届出書のサーバ配送とクライアント承認
When a server receives an inbound presence stanza of type "subscribe" (i.e., a subscription request) or of type "subscribed", "unsubscribe", or "unsubscribed" (i.e., a subscription state change notification), in addition to sending the appropriate roster push (or updated roster when the roster is next requested by an available resource), it MUST deliver the request or notification to the intended recipient at least once. A server MAY require the recipient to acknowledge receipt of all state change notifications (and MUST require acknowledgement in the case of subscription requests, i.e., presence stanzas of type "subscribe"). In order to require acknowledgement, a server SHOULD send the request or notification to the recipient each time the recipient logs in, until the recipient acknowledges receipt of the notification by "affirming" or "denying" the notification, as shown in the following table:
サーバがタイプの本国行きの存在スタンザは、「申し込む」か(すなわち、購読要求)、タイプに「申し込む」、「外す」か、または「外した」(すなわち、購読州の変更届出書)、適切な当直表を送ることに加えてプッシュ(利用可能なリソースによって要求されて、当直表が次であるときに、または、当直表をアップデートする)を受けるとき、それは少なくとも一度要求か通知を意図している受取人に提供しなければなりません。 サーバは、受取人がすべての州の変更届出書(そして、すなわち、購読要求、「申し込タイプ」の存在スタンザの場合で承認を必要としなければならない)の領収書を受け取ったことを知らせるのを必要とするかもしれません。 承認を必要とするように、受取人が受取人までログインするたびにSHOULDが受取人への要求か通知を送るサーバは通知が「確言する」か、または「否定」であることによって、通知の領収書を受け取ったことを知らせます、以下のテーブルに示されるように:
Saint-Andre Standards Track [Page 61] RFC 3921 XMPP IM October 2004
サンアンドレ規格はXMPP不-2004年10月にRFC3921を追跡します[61ページ]。
Table 7: Acknowledgement of subscription state change notifications
テーブル7: 購読州の変更届出書の承認
+--------------------------------------------------+ | STANZA TYPE | ACCEPT | DENY | +--------------------------------------------------+ | subscribe | subscribed | unsubscribed | | subscribed | subscribe | unsubscribe | | unsubscribe | unsubscribed | subscribed | | unsubscribed | unsubscribe | subscribe | +--------------------------------------------------+
+--------------------------------------------------+ | スタンザタイプ| 受け入れてください。| 否定します。| +--------------------------------------------------+ | 申し込んでください。| 申し込まれます。| 外されます。| | 申し込まれます。| 申し込んでください。| 外してください。| | 外してください。| 外されます。| 申し込まれます。| | 外されます。| 外してください。| 申し込んでください。| +--------------------------------------------------+
Obviously, given the foregoing subscription state charts, some of the acknowledgement stanzas will be routed to the contact and result in subscription state changes, while others will not. However, any such stanzas MUST result in the server's no longer sending the subscription state notification to the user.
以上の購読州のチャートを考えて、明らかに、承認スタンザのいくつかが購読州の変化における接触と結果に発送されるでしょう、他のものはそうしないでしょうが。 しかしながら、どんなそのようなスタンザも、サーバがもう購読州の通知をユーザに送らないのをもたらさなければなりません。
Because a user's server MUST automatically generate outbound presence stanzas of type "unsubscribe" and "unsubscribed" upon receiving a roster set with the 'subscription' attribute set to a value of "remove" (see Removing a Roster Item and Cancelling All Subscriptions (Section 8.6)), the server MUST treat a roster remove request as equivalent to sending both of those presence stanzas for purposes of determining whether to continue sending subscription state change notifications of type "subscribe" or "subscribed" to the user.
ユーザのサーバが自動的にタイプの外国行きの存在スタンザを生成しなければならないので、「外してください」と受信「外された」a当直表は'購読'属性セットで「取り外してください」の値にセットしました(Removing a Roster ItemとCancelling All Subscriptions(セクション8.6)を見てください); 「申し込む」というタイプに関する購読州の変更届出書を送り続けているかどうか決定する目的のためにそれらの存在スタンザの両方を送るのに同じくらい同等な要求を取り除くか、またはユーザに「申し込まれ」て、サーバは当直表を扱わなければなりません。
10. Blocking Communication
10. コミュニケーションを妨げます。
Most instant messaging systems have found it necessary to implement some method for users to block communications from particular other users (this is also required by sections 5.1.5, 5.1.15, 5.3.2, and 5.4.10 of [IMP-REQS]). In XMPP this is done by managing one's privacy lists using the 'jabber:iq:privacy' namespace.
ほとんどのインスタントメッセージングシステムが、他の特定のユーザからユーザがコミュニケーションを妨げる何らかのメソッドを実装するのが必要であることがわかりました。そして、(また、これがセクション5.1.5が必要とされる、5.1 .15 5.3 .2、5.4 .10[IMP-REQS。) XMPPでは、'おしゃべり:iq:プライバシー'名前空間を使用することで人のプライバシーリストを管理することによって、これをします。
Server-side privacy lists enable successful completion of the following use cases:
以下のプライバシーリストが可能にするサーバサイド無事終了はケースを使用します:
o Retrieving one's privacy lists.
o 人のプライバシーを検索するのは記載します。
o Adding, removing, and editing one's privacy lists.
o 人のプライバシーを加えて、取り除いて、編集するのは記載します。
o Setting, changing, or declining active lists.
o 現役軍人名簿を設定するか、変えるか、または傾けます。
o Setting, changing, or declining the default list (i.e., the list
that is active by default).
o 設定、変化、またはデフォルトを傾けると、(すなわち、デフォルトでアクティブなリスト)は記載されます。
o Allowing or blocking messages based on JID, group, or subscription
type (or globally).
o JID、グループ、または購読タイプ(グローバルである)に基づくメッセージを、許容するか、または妨げます。
Saint-Andre Standards Track [Page 62] RFC 3921 XMPP IM October 2004
サンアンドレ規格はXMPP不-2004年10月にRFC3921を追跡します[62ページ]。
o Allowing or blocking inbound presence notifications based on JID,
group, or subscription type (or globally).
o JIDに基づく、本国行きの存在通知、グループ、または購読タイプ(グローバルである)を許容するか、または妨げます。
o Allowing or blocking outbound presence notifications based on JID,
group, or subscription type (or globally).
o JIDに基づく、外国行きの存在通知、グループ、または購読タイプ(グローバルである)を許容するか、または妨げます。
o Allowing or blocking IQ stanzas based on JID, group, or
subscription type (or globally).
o JIDに基づくIQスタンザ、グループ、または購読タイプ(グローバルである)を許容するか、または妨げます。
o Allowing or blocking all communications based on JID, group, or
subscription type (or globally).
o JIDに基づくすべてのコミュニケーション、グループ、または購読タイプ(グローバルである)を許容するか、または妨げます。
Note: Presence notifications do not include presence subscriptions, only presence information that is broadcasted to entities that are subscribed to a user's presence information. Thus this includes presence stanzas with no 'type' attribute or of type='unavailable' only.
以下に注意してください。 存在通知は存在購読(ユーザの存在情報に申し込まれる実体にbroadcastedされる存在情報だけ)を含んでいません。 したがって、これは属性かタイプ=の'入手できません''タイプ'のない存在スタンザだけを含んでいます。
10.1. Syntax and Semantics
10.1. 構文と意味論
A user MAY define one or more privacy lists, which are stored by the user's server. Each <list/> element contains one or more rules in the form of <item/> elements, and each <item/> element uses attributes to define a privacy rule type, a specific value to which the rule applies, the relevant action, and the place of the item in the processing order.
ユーザは1つ以上のプライバシーリストを定義するかもしれません。(リストはユーザのサーバによって保存されます)。それぞれの<リスト/>要素は<項目/>要素の形に1つ以上の規則を含んでいます、そして、それぞれの<項目/>要素は処理命令でプライバシー規則タイプ、規則が適用される特定の値、関連動作、および項目の場所を定義するのに属性を使用します。
The syntax is as follows:
構文は以下の通りです:
<iq>
<query xmlns='jabber:iq:privacy'>
<list name='foo'>
<item
type='[jid|group|subscription]'
value='bar'
action='[allow|deny]'
order='unsignedInt'>
[<message/>]
[<presence-in/>]
[<presence-out/>]
[<iq/>]
</item>
</list>
</query>
</iq>
<iq> <query xmlns='jabber:iq:privacy'> <list name='foo'> <item type='[jid|group|subscription]' value='bar' action='[allow|deny]' order='unsignedInt'> [<message/>] [<presence-in/>] [<presence-out/>] [<iq/>] </item> </list> </query> </iq>
Saint-Andre Standards Track [Page 63] RFC 3921 XMPP IM October 2004
サンアンドレ規格はXMPP不-2004年10月にRFC3921を追跡します[63ページ]。
If the type is "jid", then the 'value' attribute MUST contain a valid Jabber ID. JIDs SHOULD be matched in the following order:
タイプが"jid"であるなら、'値'属性は有効なJabber IDを含まなければなりません。 JIDs SHOULD、以下のオーダーで合わせられてください:
1. <user@domain/resource> (only that resource matches)
1. <ユーザ@domain/リソース>。(リソースは合っているだけです)
2. <user@domain> (any resource matches)
2. <ユーザ@domain>。(どんなリソースマッチも)
3. <domain/resource> (only that resource matches)
3. <ドメイン/リソース>。(リソースは合っているだけです)
4. <domain> (the domain itself matches, as does any user@domain,
domain/resource, or address containing a subdomain)
4. <ドメイン>。(ドメイン自体はいずれも user@domain 、ドメイン/リソース、またはサブドメインを含むアドレスのように合っています)
If the type is "group", then the 'value' attribute SHOULD contain the name of a group in the user's roster. (If a client attempts to update, create, or delete a list item with a group that is not in the user's roster, the server SHOULD return to the client an <item-not-found/> stanza error.)
タイプが「グループ」であるなら、'値'属性SHOULDはユーザの当直表のグループの名前を含んでいます。 (クライアントが、ユーザの当直表にないグループと共にリスト項目をアップデートするか、作成するか、または削除するのを試みるなら、サーバSHOULDは見つけられなかった<の品目/>スタンザ誤りをクライアントに返します。)
If the type is "subscription", then the 'value' attribute MUST be one of "both", "to", "from", or "none" as defined under Roster Syntax and Semantics (Section 7.1), where "none" includes entities that are totally unknown to the user and therefore not in the user's roster at all.
タイプが「購読」であるなら、'値'属性は、Roster SyntaxとSemantics(セクション7.1)の下で定義されてしたがって、全くユーザの当直表でないところの「両方」の1つ、“to"、“from"、または「なにも」であるに違いありません。そこでは、「なにも」がユーザにとって、完全に未知であることの実体を含んでいます。
If no 'type' attribute is included, the rule provides the "fall-through" case.
どんな'タイプ'属性も含まれていないなら、規則は「秋の突き抜けている」ケースを供給します。
The 'action' attribute MUST be included and its value MUST be either "allow" or "deny".
値は、'動作'属性を含まなければならなくて、「許容」か「否定」のどちらかでなければなりません。
The 'order' attribute MUST be included and its value MUST be a non-negative integer that is unique among all items in the list. (If a client attempts to create or update a list with non-unique order values, the server MUST return to the client a <bad-request/> stanza error.)
'オーダー'属性を含まなければなりません、そして、値はリストのすべての項目の中でユニークな非負の整数でなければなりません。 (クライアントが、非ユニークなオーダー値でリストを作成するか、またはアップデートするのを試みるなら、サーバは<の悪い要求/>スタンザ誤りをクライアントに返さなければなりません。)
The <item/> element MAY contain one or more child elements that enable an entity to specify more granular control over which kinds of stanzas are to be blocked (i.e., rather than blocking all stanzas). The allowable child elements are:
すなわち、<項目/>要素が実体がどの種類のスタンザが妨げられるかことであるかの、より粒状のコントロールを指定するのを可能にする1つ以上の子供要素を含むかもしれない、(すべてのスタンザを妨げるよりむしろ) 許容できる子供要素は以下の通りです。
o <message/> -- blocks incoming message stanzas o <iq/> -- blocks incoming IQ stanzas o <presence-in/> -- blocks incoming presence notifications o <presence-out/> -- blocks outgoing presence notifications
o ブロック入来メッセージスタンザo<iq/>(ブロック入来中のIQスタンザo<存在/>)が外での入って来る存在通知o<存在/>を妨げるという<メッセージ/>は送信する存在通知を妨げます。
Saint-Andre Standards Track [Page 64] RFC 3921 XMPP IM October 2004
サンアンドレ規格はXMPP不-2004年10月にRFC3921を追跡します[64ページ]。
Within the 'jabber:iq:privacy' namespace, the <query/> child of an IQ stanza of type "set" MUST NOT include more than one child element (i.e., the stanza MUST contain only one <active/> element, one <default/> element, or one <list/> element); if a sending entity violates this rule, the receiving entity MUST return a <bad-request/> stanza error.
'おしゃべり:iq:プライバシー'名前空間の中では、タイプ「セット」のIQスタンザの<質問/>子供は1つ以上の子供要素を入れてはいけません(すなわち、スタンザは1つの<活性/>要素、1つの<デフォルト/>要素、または1つの<リスト/>要素だけを含まなければなりません)。 送付実体がこの規則に違反するなら、受信実体は<の悪い要求/>スタンザ誤りを返さなければなりません。
When a client adds or updates a privacy list, the <list/> element SHOULD contain at least one <item/> child element; when a client removes a privacy list, the <list/> element MUST NOT contain any <item/> child elements.
クライアントがプライバシーリストを加えるか、またはアップデートするとき、<リスト/>要素SHOULDは少なくとも1つの<項目/>子供要素を含んでいます。 クライアントがプライバシーリストを取り除くとき、<リスト/>要素はどんな<項目/>子供要素も含んではいけません。
When a client updates a privacy list, it must include all of the desired items (i.e., not a "delta").
クライアントがプライバシーリストをアップデートするとき、それは必要な項目(すなわち、「デルタ」でない)のすべてを含まなければなりません。
10.2. Business Rules
10.2. ビジネス規則
1. If there is an active list set for a session, it affects only the
session(s) for which it is activated, and only for the duration
of the session(s); the server MUST apply the active list only and
MUST NOT apply the default list (i.e., there is no "layering" of
lists).
1. 現役軍人名簿セットがセッションの間、あれば、それが動かされる、およびセッションの持続時間のためだけのものであるセッションだけに影響します。 サーバは、現役軍人名簿だけを当てはまらなければならなくて、デフォルトリストは当てはまってはいけません(すなわち、リストが「レイヤ」であることがありません)。
2. The default list applies to the user as a whole, and is processed
if there is no active list set for the target session/resource to
which a stanza is addressed, or if there are no current sessions
for the user.
2. デフォルトリストは、全体でユーザに適用して、スタンザが扱われる目標セッション/リソースに設定された現役軍人名簿が全くないか、またはユーザのためのどんな現在のセッションもなければ、処理されます。
3. If there is no active list set for a session (or there are no
current sessions for the user), and there is no default list,
then all stanzas SHOULD BE accepted or appropriately processed by
the server on behalf of the user in accordance with the Server
Rules for Handling XML Stanzas (Section 11).
3. 現役軍人名簿セットが全くセッションの間、なくて(ユーザのためのどんな現在のセッションもありません)、またデフォルトリストが全くなければ、そして、スタンザすべてSHOULD BEです受け入れられたかServer Rulesによると、Handling XML Stanzas(セクション11)のためにサーバによってユーザを代表して適切に処理された。
4. Privacy lists MUST be the first delivery rule applied by a
server, superseding (1) the routing and delivery rules specified
in Server Rules for Handling XML Stanzas (Section 11), and (2)
the handling of subscription-related presence stanzas (and
corresponding generation of roster pushes) specified in
Integration of Roster Items and Presence Subscriptions (Section
8).
4. (2) プライバシーリストは(1) ルーティングに取って代わって、サーバによって適用された初産規則であるに違いありません、そして、配送規則はServer RulesでHandling XML Stanzas(セクション11)に指定しました、そして、購読関連の存在スタンザ(そして、当直表プッシュの対応する世代)の取り扱いはRoster ItemsとPresence Subscriptions(セクション8)のIntegrationで指定しました。
5. The order in which privacy list items are processed by the server
is important. List items MUST be processed in ascending order
determined by the integer values of the 'order' attribute for
each <item/>.
5. プライバシーリスト項目がサーバによって処理されるオーダーは重要です。 それぞれの<項目/>のために'オーダー'属性の整数値で決定している昇順でリスト項目を処理しなければなりません。
Saint-Andre Standards Track [Page 65] RFC 3921 XMPP IM October 2004
サンアンドレ規格はXMPP不-2004年10月にRFC3921を追跡します[65ページ]。
6. As soon as a stanza is matched against a privacy list rule, the
server MUST appropriately handle the stanza in accordance with
the rule and cease processing.
6. スタンザがプライバシーリスト規則に取り組まされるとすぐに、サーバは、規則に従って適切にスタンザを扱って、処理するのをやめなければなりません。
7. If no fall-through item is provided in a list, the fall-through
action is assumed to be "allow".
7. 秋の終えた商品を全くリストに提供しないなら、「許容」であると秋の終えた動作を思います。
8. If a user updates the definition for an active list, subsequent
processing based on that active list MUST use the updated
definition (for all resources to which that active list currently
applies).
8. ユーザが現役軍人名簿のための定義をアップデートするなら、その現役軍人名簿に基づくその後の処理はアップデートされた定義(その現役軍人名簿が現在適用されるすべてのリソースのための)を使用しなければなりません。
9. If a change to the subscription state or roster group of a roster
item defined in an active or default list occurs during a user's
session, subsequent processing based on that list MUST take into
account the changed state or group (for all resources to which
that list currently applies).
9. If a change to the subscription state or roster group of a roster item defined in an active or default list occurs during a user's session, subsequent processing based on that list MUST take into account the changed state or group (for all resources to which that list currently applies).
10. When the definition for a rule is modified, the server MUST send
an IQ stanza of type "set" to all connected resources, containing
a <query/> element with only one <list/> child element, where the
'name' attribute is set to the name of the modified privacy list.
These "privacy list pushes" adhere to the same semantics as the
"roster pushes" used in roster management, except that only the
list name itself (not the full list definition or the "delta") is
pushed to the connected resources. It is up to the receiving
resource to determine whether to retrieve the modified list
definition, although a connected resource SHOULD do so if the
list currently applies to it.
10. When the definition for a rule is modified, the server MUST send an IQ stanza of type "set" to all connected resources, containing a <query/> element with only one <list/> child element, where the 'name' attribute is set to the name of the modified privacy list. These "privacy list pushes" adhere to the same semantics as the "roster pushes" used in roster management, except that only the list name itself (not the full list definition or the "delta") is pushed to the connected resources. It is up to the receiving resource to determine whether to retrieve the modified list definition, although a connected resource SHOULD do so if the list currently applies to it.
11. When a resource attempts to remove a list or specify a new
default list while that list applies to a connected resource
other than the sending resource, the server MUST return a
<conflict/> error to the sending resource and MUST NOT make the
requested change.
11. When a resource attempts to remove a list or specify a new default list while that list applies to a connected resource other than the sending resource, the server MUST return a <conflict/> error to the sending resource and MUST NOT make the requested change.
10.3. Retrieving One's Privacy Lists
10.3. Retrieving One's Privacy Lists
Example: Client requests names of privacy lists from server:
Example: Client requests names of privacy lists from server:
<iq from='romeo@example.net/orchard' type='get' id='getlist1'>
<query xmlns='jabber:iq:privacy'/>
</iq>
<iq from='romeo@example.net/orchard' type='get' id='getlist1'> <query xmlns='jabber:iq:privacy'/> </iq>
Saint-Andre Standards Track [Page 66] RFC 3921 XMPP IM October 2004
Saint-Andre Standards Track [Page 66] RFC 3921 XMPP IM October 2004
Example: Server sends names of privacy lists to client, preceded by active list and default list:
Example: Server sends names of privacy lists to client, preceded by active list and default list:
<iq type='result' id='getlist1' to='romeo@example.net/orchard'>
<query xmlns='jabber:iq:privacy'>
<active name='private'/>
<default name='public'/>
<list name='public'/>
<list name='private'/>
<list name='special'/>
</query>
</iq>
<iq type='result' id='getlist1' to='romeo@example.net/orchard'> <query xmlns='jabber:iq:privacy'> <active name='private'/> <default name='public'/> <list name='public'/> <list name='private'/> <list name='special'/> </query> </iq>
Example: Client requests a privacy list from server:
Example: Client requests a privacy list from server:
<iq from='romeo@example.net/orchard' type='get' id='getlist2'>
<query xmlns='jabber:iq:privacy'>
<list name='public'/>
</query>
</iq>
<iq from='romeo@example.net/orchard' type='get' id='getlist2'> <query xmlns='jabber:iq:privacy'> <list name='public'/> </query> </iq>
Example: Server sends a privacy list to client:
Example: Server sends a privacy list to client:
<iq type='result' id='getlist2' to='romeo@example.net/orchard'>
<query xmlns='jabber:iq:privacy'>
<list name='public'>
<item type='jid'
value='tybalt@example.com'
action='deny'
order='1'/>
<item action='allow' order='2'/>
</list>
</query>
</iq>
<iq type='result' id='getlist2' to='romeo@example.net/orchard'> <query xmlns='jabber:iq:privacy'> <list name='public'> <item type='jid' value='tybalt@example.com' action='deny' order='1'/> <item action='allow' order='2'/> </list> </query> </iq>
Example: Client requests another privacy list from server:
Example: Client requests another privacy list from server:
<iq from='romeo@example.net/orchard' type='get' id='getlist3'>
<query xmlns='jabber:iq:privacy'>
<list name='private'/>
</query>
</iq>
<iq from='romeo@example.net/orchard' type='get' id='getlist3'> <query xmlns='jabber:iq:privacy'> <list name='private'/> </query> </iq>
Saint-Andre Standards Track [Page 67] RFC 3921 XMPP IM October 2004
Saint-Andre Standards Track [Page 67] RFC 3921 XMPP IM October 2004
Example: Server sends another privacy list to client:
Example: Server sends another privacy list to client:
<iq type='result' id='getlist3' to='romeo@example.net/orchard'>
<query xmlns='jabber:iq:privacy'>
<list name='private'>
<item type='subscription'
value='both'
action='allow'
order='10'/>
<item action='deny' order='15'/>
</list>
</query>
</iq>
<iq type='result' id='getlist3' to='romeo@example.net/orchard'> <query xmlns='jabber:iq:privacy'> <list name='private'> <item type='subscription' value='both' action='allow' order='10'/> <item action='deny' order='15'/> </list> </query> </iq>
Example: Client requests yet another privacy list from server:
Example: Client requests yet another privacy list from server:
<iq from='romeo@example.net/orchard' type='get' id='getlist4'>
<query xmlns='jabber:iq:privacy'>
<list name='special'/>
</query>
</iq>
<iq from='romeo@example.net/orchard' type='get' id='getlist4'> <query xmlns='jabber:iq:privacy'> <list name='special'/> </query> </iq>
Example: Server sends yet another privacy list to client:
Example: Server sends yet another privacy list to client:
<iq type='result' id='getlist4' to='romeo@example.net/orchard'>
<query xmlns='jabber:iq:privacy'>
<list name='special'>
<item type='jid'
value='juliet@example.com'
action='allow'
order='6'/>
<item type='jid'
value='benvolio@example.org'
action='allow'
order='7'/>
<item type='jid'
value='mercutio@example.org'
action='allow'
order='42'/>
<item action='deny' order='666'/>
</list>
</query>
</iq>
<iq type='result' id='getlist4' to='romeo@example.net/orchard'> <query xmlns='jabber:iq:privacy'> <list name='special'> <item type='jid' value='juliet@example.com' action='allow' order='6'/> <item type='jid' value='benvolio@example.org' action='allow' order='7'/> <item type='jid' value='mercutio@example.org' action='allow' order='42'/> <item action='deny' order='666'/> </list> </query> </iq>
In this example, the user has three lists: (1) 'public', which allows communications from everyone except one specific entity (this is the default list); (2) 'private', which allows communications only with
In this example, the user has three lists: (1) 'public', which allows communications from everyone except one specific entity (this is the default list); (2) 'private', which allows communications only with
Saint-Andre Standards Track [Page 68] RFC 3921 XMPP IM October 2004
Saint-Andre Standards Track [Page 68] RFC 3921 XMPP IM October 2004
contacts who have a bidirectional subscription with the user (this is the active list); and (3) 'special', which allows communications only with three specific entities.
contacts who have a bidirectional subscription with the user (this is the active list); and (3) 'special', which allows communications only with three specific entities.
If the user attempts to retrieve a list but a list by that name does not exist, the server MUST return an <item-not-found/> stanza error to the user:
If the user attempts to retrieve a list but a list by that name does not exist, the server MUST return an <item-not-found/> stanza error to the user:
Example: Client attempts to retrieve non-existent list:
Example: Client attempts to retrieve non-existent list:
<iq to='romeo@example.net/orchard' type='error' id='getlist5'>
<query xmlns='jabber:iq:privacy'>
<list name='The Empty Set'/>
</query>
<error type='cancel'>
<item-not-found
xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
</error>
</iq>
<iq to='romeo@example.net/orchard' type='error' id='getlist5'> <query xmlns='jabber:iq:privacy'> <list name='The Empty Set'/> </query> <error type='cancel'> <item-not-found xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/> </error> </iq>
The user is allowed to retrieve only one list at a time. If the user attempts to retrieve more than one list in the same request, the server MUST return a <bad request/> stanza error to the user:
The user is allowed to retrieve only one list at a time. If the user attempts to retrieve more than one list in the same request, the server MUST return a <bad request/> stanza error to the user:
Example: Client attempts to retrieve more than one list:
Example: Client attempts to retrieve more than one list:
<iq to='romeo@example.net/orchard' type='error' id='getlist6'>
<query xmlns='jabber:iq:privacy'>
<list name='public'/>
<list name='private'/>
<list name='special'/>
</query>
<error type='modify'>
<bad-request
xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
</error>
</iq>
<iq to='romeo@example.net/orchard' type='error' id='getlist6'> <query xmlns='jabber:iq:privacy'> <list name='public'/> <list name='private'/> <list name='special'/> </query> <error type='modify'> <bad-request xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/> </error> </iq>
10.4. Managing Active Lists
10.4. Managing Active Lists
In order to set or change the active list currently being applied by the server, the user MUST send an IQ stanza of type "set" with a <query/> element qualified by the 'jabber:iq:privacy' namespace that contains an empty <active/> child element possessing a 'name' attribute whose value is set to the desired list name.
In order to set or change the active list currently being applied by the server, the user MUST send an IQ stanza of type "set" with a <query/> element qualified by the 'jabber:iq:privacy' namespace that contains an empty <active/> child element possessing a 'name' attribute whose value is set to the desired list name.
Saint-Andre Standards Track [Page 69] RFC 3921 XMPP IM October 2004
Saint-Andre Standards Track [Page 69] RFC 3921 XMPP IM October 2004
Example: Client requests change of active list:
Example: Client requests change of active list:
<iq from='romeo@example.net/orchard' type='set' id='active1'>
<query xmlns='jabber:iq:privacy'>
<active name='special'/>
</query>
</iq>
<iq from='romeo@example.net/orchard' type='set' id='active1'> <query xmlns='jabber:iq:privacy'> <active name='special'/> </query> </iq>
The server MUST activate and apply the requested list before sending the result back to the client.
The server MUST activate and apply the requested list before sending the result back to the client.
Example: Server acknowledges success of active list change:
Example: Server acknowledges success of active list change:
<iq type='result' id='active1' to='romeo@example.net/orchard'/>
<iq type='result' id='active1' to='romeo@example.net/orchard'/>
If the user attempts to set an active list but a list by that name does not exist, the server MUST return an <item-not-found/> stanza error to the user:
If the user attempts to set an active list but a list by that name does not exist, the server MUST return an <item-not-found/> stanza error to the user:
Example: Client attempts to set a non-existent list as active:
Example: Client attempts to set a non-existent list as active:
<iq to='romeo@example.net/orchard' type='error' id='active2'>
<query xmlns='jabber:iq:privacy'>
<active name='The Empty Set'/>
</query>
<error type='cancel'>
<item-not-found
xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
</error>
</iq>
<iq to='romeo@example.net/orchard' type='error' id='active2'> <query xmlns='jabber:iq:privacy'> <active name='The Empty Set'/> </query> <error type='cancel'> <item-not-found xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/> </error> </iq>
In order to decline the use of any active list, the connected resource MUST send an empty <active/> element with no 'name' attribute.
In order to decline the use of any active list, the connected resource MUST send an empty <active/> element with no 'name' attribute.
Example: Client declines the use of active lists:
Example: Client declines the use of active lists:
<iq from='romeo@example.net/orchard' type='set' id='active3'>
<query xmlns='jabber:iq:privacy'>
<active/>
</query>
</iq>
<iq from='romeo@example.net/orchard' type='set' id='active3'> <query xmlns='jabber:iq:privacy'> <active/> </query> </iq>
Example: Server acknowledges success of declining any active list:
Example: Server acknowledges success of declining any active list:
<iq type='result' id='active3' to='romeo@example.net/orchard'/>
<iq type='result' id='active3' to='romeo@example.net/orchard'/>
Saint-Andre Standards Track [Page 70] RFC 3921 XMPP IM October 2004
Saint-Andre Standards Track [Page 70] RFC 3921 XMPP IM October 2004
10.5. Managing the Default List
10.5. Managing the Default List
In order to change its default list (which applies to the user as a whole, not only the sending resource), the user MUST send an IQ stanza of type "set" with a <query/> element qualified by the 'jabber:iq:privacy' namespace that contains an empty <default/> child element possessing a 'name' attribute whose value is set to the desired list name.
In order to change its default list (which applies to the user as a whole, not only the sending resource), the user MUST send an IQ stanza of type "set" with a <query/> element qualified by the 'jabber:iq:privacy' namespace that contains an empty <default/> child element possessing a 'name' attribute whose value is set to the desired list name.
Example: User requests change of default list:
Example: User requests change of default list:
<iq from='romeo@example.net/orchard' type='set' id='default1'>
<query xmlns='jabber:iq:privacy'>
<default name='special'/>
</query>
</iq>
<iq from='romeo@example.net/orchard' type='set' id='default1'> <query xmlns='jabber:iq:privacy'> <default name='special'/> </query> </iq>
Example: Server acknowledges success of default list change:
Example: Server acknowledges success of default list change:
<iq type='result' id='default1' to='romeo@example.net/orchard'/>
<iq type='result' id='default1' to='romeo@example.net/orchard'/>
If the user attempts to change which list is the default list but the default list is in use by at least one connected resource other than the sending resource, the server MUST return a <conflict/> stanza error to the sending resource:
If the user attempts to change which list is the default list but the default list is in use by at least one connected resource other than the sending resource, the server MUST return a <conflict/> stanza error to the sending resource:
Example: Client attempts to change the default list but that list is in use by another resource:
Example: Client attempts to change the default list but that list is in use by another resource:
<iq to='romeo@example.net/orchard' type='error' id='default1'>
<query xmlns='jabber:iq:privacy'>
<default name='special'/>
</query>
<error type='cancel'>
<conflict
xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
</error>
</iq>
<iq to='romeo@example.net/orchard' type='error' id='default1'> <query xmlns='jabber:iq:privacy'> <default name='special'/> </query> <error type='cancel'> <conflict xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/> </error> </iq>
If the user attempts to set a default list but a list by that name does not exist, the server MUST return an <item-not-found/> stanza error to the user:
If the user attempts to set a default list but a list by that name does not exist, the server MUST return an <item-not-found/> stanza error to the user:
Saint-Andre Standards Track [Page 71] RFC 3921 XMPP IM October 2004
Saint-Andre Standards Track [Page 71] RFC 3921 XMPP IM October 2004
Example: Client attempts to set a non-existent list as default:
Example: Client attempts to set a non-existent list as default:
<iq to='romeo@example.net/orchard' type='error' id='default1'>
<query xmlns='jabber:iq:privacy'>
<default name='The Empty Set'/>
</query>
<error type='cancel'>
<item-not-found
xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
</error>
</iq>
<iq to='romeo@example.net/orchard' type='error' id='default1'> <query xmlns='jabber:iq:privacy'> <default name='The Empty Set'/> </query> <error type='cancel'> <item-not-found xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/> </error> </iq>
In order to decline the use of a default list (i.e., to use the domain's stanza routing rules at all times), the user MUST send an empty <default/> element with no 'name' attribute.
In order to decline the use of a default list (i.e., to use the domain's stanza routing rules at all times), the user MUST send an empty <default/> element with no 'name' attribute.
Example: Client declines the use of the default list:
Example: Client declines the use of the default list:
<iq from='romeo@example.net/orchard' type='set' id='default2'>
<query xmlns='jabber:iq:privacy'>
<default/>
</query>
</iq>
<iq from='romeo@example.net/orchard' type='set' id='default2'> <query xmlns='jabber:iq:privacy'> <default/> </query> </iq>
Example: Server acknowledges success of declining any default list:
Example: Server acknowledges success of declining any default list:
<iq type='result' id='default2' to='romeo@example.net/orchard'/>
<iq type='result' id='default2' to='romeo@example.net/orchard'/>
If one connected resource attempts to decline the use of a default list for the user as a whole but the default list currently applies to at least one other connected resource, the server MUST return a <conflict/> error to the sending resource:
If one connected resource attempts to decline the use of a default list for the user as a whole but the default list currently applies to at least one other connected resource, the server MUST return a <conflict/> error to the sending resource:
Example: Client attempts to decline a default list but that list is in use by another resource:
Example: Client attempts to decline a default list but that list is in use by another resource:
<iq to='romeo@example.net/orchard' type='error' id='default3'>
<query xmlns='jabber:iq:privacy'>
<default/>
</query>
<error type='cancel'>
<conflict
xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
</error>
</iq>
<iq to='romeo@example.net/orchard' type='error' id='default3'> <query xmlns='jabber:iq:privacy'> <default/> </query> <error type='cancel'> <conflict xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/> </error> </iq>
Saint-Andre Standards Track [Page 72] RFC 3921 XMPP IM October 2004
Saint-Andre Standards Track [Page 72] RFC 3921 XMPP IM October 2004
10.6. Editing a Privacy List
10.6. Editing a Privacy List
In order to edit a privacy list, the user MUST send an IQ stanza of type "set" with a <query/> element qualified by the 'jabber:iq:privacy' namespace that contains one <list/> child element possessing a 'name' attribute whose value is set to the list name the user would like to edit. The <list/> element MUST contain one or more <item/> elements, which specify the user's desired changes to the list by including all elements in the list (not the "delta").
In order to edit a privacy list, the user MUST send an IQ stanza of type "set" with a <query/> element qualified by the 'jabber:iq:privacy' namespace that contains one <list/> child element possessing a 'name' attribute whose value is set to the list name the user would like to edit. The <list/> element MUST contain one or more <item/> elements, which specify the user's desired changes to the list by including all elements in the list (not the "delta").
Example: Client edits a privacy list:
Example: Client edits a privacy list:
<iq from='romeo@example.net/orchard' type='set' id='edit1'>
<query xmlns='jabber:iq:privacy'>
<list name='public'>
<item type='jid'
value='tybalt@example.com'
action='deny'
order='3'/>
<item type='jid'
value='paris@example.org'
action='deny'
order='5'/>
<item action='allow' order='68'/>
</list>
</query>
</iq>
<iq from='romeo@example.net/orchard' type='set' id='edit1'> <query xmlns='jabber:iq:privacy'> <list name='public'> <item type='jid' value='tybalt@example.com' action='deny' order='3'/> <item type='jid' value='paris@example.org' action='deny' order='5'/> <item action='allow' order='68'/> </list> </query> </iq>
Example: Server acknowledges success of list edit:
Example: Server acknowledges success of list edit:
<iq type='result' id='edit1' to='romeo@example.net/orchard'/>
<iq type='result' id='edit1' to='romeo@example.net/orchard'/>
Note: The value of the 'order' attribute for any given item is not fixed. Thus in the foregoing example if the user would like to add 4 items between the "tybalt@example.com" item and the "paris@example.org" item, the user's client MUST renumber the relevant items before submitting the list to the server.
Note: The value of the 'order' attribute for any given item is not fixed. Thus in the foregoing example if the user would like to add 4 items between the "tybalt@example.com" item and the "paris@example.org" item, the user's client MUST renumber the relevant items before submitting the list to the server.
The server MUST now send a "privacy list push" to all connected resources:
The server MUST now send a "privacy list push" to all connected resources:
Example: Privacy list push on list edit:
Example: Privacy list push on list edit:
<iq to='romeo@example.net/orchard' type='set' id='push1'>
<query xmlns='jabber:iq:privacy'>
<list name='public'/>
</query>
</iq>
<iq to='romeo@example.net/orchard' type='set' id='push1'> <query xmlns='jabber:iq:privacy'> <list name='public'/> </query> </iq>
Saint-Andre Standards Track [Page 73] RFC 3921 XMPP IM October 2004
Saint-Andre Standards Track [Page 73] RFC 3921 XMPP IM October 2004
<iq to='romeo@example.net/home' type='set' id='push2'>
<query xmlns='jabber:iq:privacy'>
<list name='public'/>
</query>
</iq>
<iq to='romeo@example.net/home' type='set' id='push2'> <query xmlns='jabber:iq:privacy'> <list name='public'/> </query> </iq>
In accordance with the semantics of IQ stanzas defined in [XMPP-CORE], each connected resource MUST return an IQ result to the server as well:
In accordance with the semantics of IQ stanzas defined in [XMPP-CORE], each connected resource MUST return an IQ result to the server as well:
Example: Acknowledging receipt of privacy list pushes:
Example: Acknowledging receipt of privacy list pushes:
<iq from='romeo@example.net/orchard'
type='result'
id='push1'/>
<iq from='romeo@example.net/orchard' type='result' id='push1'/>
<iq from='romeo@example.net/home'
type='result'
id='push2'/>
<iq from='romeo@example.net/home' type='result' id='push2'/>
10.7. Adding a New Privacy List
10.7. Adding a New Privacy List
The same protocol used to edit an existing list is used to create a new list. If the list name matches that of an existing list, the request to add a new list will overwrite the old one. As with list edits, the server MUST also send a "privacy list push" to all connected resources.
The same protocol used to edit an existing list is used to create a new list. If the list name matches that of an existing list, the request to add a new list will overwrite the old one. As with list edits, the server MUST also send a "privacy list push" to all connected resources.
10.8. Removing a Privacy List
10.8. Removing a Privacy List
In order to remove a privacy list, the user MUST send an IQ stanza of type "set" with a <query/> element qualified by the 'jabber:iq:privacy' namespace that contains one empty <list/> child element possessing a 'name' attribute whose value is set to the list name the user would like to remove.
In order to remove a privacy list, the user MUST send an IQ stanza of type "set" with a <query/> element qualified by the 'jabber:iq:privacy' namespace that contains one empty <list/> child element possessing a 'name' attribute whose value is set to the list name the user would like to remove.
Example: Client removes a privacy list:
Example: Client removes a privacy list:
<iq from='romeo@example.net/orchard' type='set' id='remove1'>
<query xmlns='jabber:iq:privacy'>
<list name='private'/>
</query>
</iq>
<iq from='romeo@example.net/orchard' type='set' id='remove1'> <query xmlns='jabber:iq:privacy'> <list name='private'/> </query> </iq>
Example: Server acknowledges success of list removal:
Example: Server acknowledges success of list removal:
<iq type='result' id='remove1' to='romeo@example.net/orchard'/>
<iq type='result' id='remove1' to='romeo@example.net/orchard'/>
Saint-Andre Standards Track [Page 74] RFC 3921 XMPP IM October 2004
Saint-Andre Standards Track [Page 74] RFC 3921 XMPP IM October 2004
If a user attempts to remove a list that is currently being applied to at least one resource other than the sending resource, the server MUST return a <conflict/> stanza error to the user; i.e., the user MUST first set another list to active or default before attempting to remove it. If the user attempts to remove a list but a list by that name does not exist, the server MUST return an <item-not-found/> stanza error to the user. If the user attempts to remove more than one list in the same request, the server MUST return a <bad request/> stanza error to the user.
If a user attempts to remove a list that is currently being applied to at least one resource other than the sending resource, the server MUST return a <conflict/> stanza error to the user; i.e., the user MUST first set another list to active or default before attempting to remove it. If the user attempts to remove a list but a list by that name does not exist, the server MUST return an <item-not-found/> stanza error to the user. If the user attempts to remove more than one list in the same request, the server MUST return a <bad request/> stanza error to the user.
10.9. Blocking Messages
10.9. Blocking Messages
Server-side privacy lists enable a user to block incoming messages from other entities based on the entity's JID, roster group, or subscription status (or globally). The following examples illustrate the protocol. (Note: For the sake of brevity, IQ stanzas of type "result" are not shown in the following examples, nor are "privacy list pushes".)
Server-side privacy lists enable a user to block incoming messages from other entities based on the entity's JID, roster group, or subscription status (or globally). The following examples illustrate the protocol. (Note: For the sake of brevity, IQ stanzas of type "result" are not shown in the following examples, nor are "privacy list pushes".)
Example: User blocks based on JID:
Example: User blocks based on JID:
<iq from='romeo@example.net/orchard' type='set' id='msg1'>
<query xmlns='jabber:iq:privacy'>
<list name='message-jid-example'>
<item type='jid'
value='tybalt@example.com'
action='deny'
order='3'>
<message/>
</item>
</list>
</query>
</iq>
<iq from='romeo@example.net/orchard' type='set' id='msg1'> <query xmlns='jabber:iq:privacy'> <list name='message-jid-example'> <item type='jid' value='tybalt@example.com' action='deny' order='3'> <message/> </item> </list> </query> </iq>
As a result of creating and applying the foregoing list, the user will not receive messages from the entity with the specified JID.
As a result of creating and applying the foregoing list, the user will not receive messages from the entity with the specified JID.
Example: User blocks based on roster group:
Example: User blocks based on roster group:
<iq from='romeo@example.net/orchard' type='set' id='msg2'>
<query xmlns='jabber:iq:privacy'>
<list name='message-group-example'>
<item type='group'
value='Enemies'
action='deny'
order='4'>
<message/>
</item>
<iq from='romeo@example.net/orchard' type='set' id='msg2'> <query xmlns='jabber:iq:privacy'> <list name='message-group-example'> <item type='group' value='Enemies' action='deny' order='4'> <message/> </item>
Saint-Andre Standards Track [Page 75] RFC 3921 XMPP IM October 2004
Saint-Andre Standards Track [Page 75] RFC 3921 XMPP IM October 2004
</list>
</query>
</iq>
</list> </query> </iq>
As a result of creating and applying the foregoing list, the user will not receive messages from any entities in the specified roster group.
As a result of creating and applying the foregoing list, the user will not receive messages from any entities in the specified roster group.
Example: User blocks based on subscription type:
Example: User blocks based on subscription type:
<iq from='romeo@example.net/orchard' type='set' id='msg3'>
<query xmlns='jabber:iq:privacy'>
<list name='message-sub-example'>
<item type='subscription'
value='none'
action='deny'
order='5'>
<message/>
</item>
</list>
</query>
</iq>
<iq from='romeo@example.net/orchard' type='set' id='msg3'> <query xmlns='jabber:iq:privacy'> <list name='message-sub-example'> <item type='subscription' value='none' action='deny' order='5'> <message/> </item> </list> </query> </iq>
As a result of creating and applying the foregoing list, the user will not receive messages from any entities with the specified subscription type.
As a result of creating and applying the foregoing list, the user will not receive messages from any entities with the specified subscription type.
Example: User blocks globally:
Example: User blocks globally:
<iq from='romeo@example.net/orchard' type='set' id='msg4'>
<query xmlns='jabber:iq:privacy'>
<list name='message-global-example'>
<item action='deny' order='6'>
<message/>
</item>
</list>
</query>
</iq>
<iq from='romeo@example.net/orchard' type='set' id='msg4'> <query xmlns='jabber:iq:privacy'> <list name='message-global-example'> <item action='deny' order='6'> <message/> </item> </list> </query> </iq>
As a result of creating and applying the foregoing list, the user will not receive messages from any other users.
As a result of creating and applying the foregoing list, the user will not receive messages from any other users.
10.10. Blocking Inbound Presence Notifications
10.10. Blocking Inbound Presence Notifications
Server-side privacy lists enable a user to block incoming presence notifications from other entities based on the entity's JID, roster group, or subscription status (or globally). The following examples illustrate the protocol.
Server-side privacy lists enable a user to block incoming presence notifications from other entities based on the entity's JID, roster group, or subscription status (or globally). The following examples illustrate the protocol.
Saint-Andre Standards Track [Page 76] RFC 3921 XMPP IM October 2004
Saint-Andre Standards Track [Page 76] RFC 3921 XMPP IM October 2004
Note: Presence notifications do not include presence subscriptions, only presence information that is broadcasted to the user because the user is currently subscribed to a contact's presence information. Thus this includes presence stanzas with no 'type' attribute or of type='unavailable' only.
Note: Presence notifications do not include presence subscriptions, only presence information that is broadcasted to the user because the user is currently subscribed to a contact's presence information. Thus this includes presence stanzas with no 'type' attribute or of type='unavailable' only.
Example: User blocks based on JID:
Example: User blocks based on JID:
<iq from='romeo@example.net/orchard' type='set' id='presin1'>
<query xmlns='jabber:iq:privacy'>
<list name='presin-jid-example'>
<item type='jid'
value='tybalt@example.com'
action='deny'
order='7'>
<presence-in/>
</item>
</list>
</query>
</iq>
<iq from='romeo@example.net/orchard' type='set' id='presin1'> <query xmlns='jabber:iq:privacy'> <list name='presin-jid-example'> <item type='jid' value='tybalt@example.com' action='deny' order='7'> <presence-in/> </item> </list> </query> </iq>
As a result of creating and applying the foregoing list, the user will not receive presence notifications from the entity with the specified JID.
As a result of creating and applying the foregoing list, the user will not receive presence notifications from the entity with the specified JID.
Example: User blocks based on roster group:
Example: User blocks based on roster group:
<iq from='romeo@example.net/orchard' type='set' id='presin2'>
<query xmlns='jabber:iq:privacy'>
<list name='presin-group-example'>
<item type='group'
value='Enemies'
action='deny'
order='8'>
<presence-in/>
</item>
</list>
</query>
</iq>
<iq from='romeo@example.net/orchard' type='set' id='presin2'> <query xmlns='jabber:iq:privacy'> <list name='presin-group-example'> <item type='group' value='Enemies' action='deny' order='8'> <presence-in/> </item> </list> </query> </iq>
As a result of creating and applying the foregoing list, the user will not receive presence notifications from any entities in the specified roster group.
As a result of creating and applying the foregoing list, the user will not receive presence notifications from any entities in the specified roster group.
Saint-Andre Standards Track [Page 77] RFC 3921 XMPP IM October 2004
Saint-Andre Standards Track [Page 77] RFC 3921 XMPP IM October 2004
Example: User blocks based on subscription type:
Example: User blocks based on subscription type:
<iq from='romeo@example.net/orchard' type='set' id='presin3'>
<query xmlns='jabber:iq:privacy'>
<list name='presin-sub-example'>
<item type='subscription'
value='to'
action='deny'
order='9'>
<presence-in/>
</item>
</list>
</query>
</iq>
<iq from='romeo@example.net/orchard' type='set' id='presin3'> <query xmlns='jabber:iq:privacy'> <list name='presin-sub-example'> <item type='subscription' value='to' action='deny' order='9'> <presence-in/> </item> </list> </query> </iq>
As a result of creating and applying the foregoing list, the user will not receive presence notifications from any entities with the specified subscription type.
As a result of creating and applying the foregoing list, the user will not receive presence notifications from any entities with the specified subscription type.
Example: User blocks globally:
Example: User blocks globally:
<iq from='romeo@example.net/orchard' type='set' id='presin4'>
<query xmlns='jabber:iq:privacy'>
<list name='presin-global-example'>
<item action='deny' order='11'>
<presence-in/>
</item>
</list>
</query>
</iq>
<iq from='romeo@example.net/orchard' type='set' id='presin4'> <query xmlns='jabber:iq:privacy'> <list name='presin-global-example'> <item action='deny' order='11'> <presence-in/> </item> </list> </query> </iq>
As a result of creating and applying the foregoing list, the user will not receive presence notifications from any other users.
As a result of creating and applying the foregoing list, the user will not receive presence notifications from any other users.
10.11. Blocking Outbound Presence Notifications
10.11. Blocking Outbound Presence Notifications
Server-side privacy lists enable a user to block outgoing presence notifications to other entities based on the entity's JID, roster group, or subscription status (or globally). The following examples illustrate the protocol.
Server-side privacy lists enable a user to block outgoing presence notifications to other entities based on the entity's JID, roster group, or subscription status (or globally). The following examples illustrate the protocol.
Note: Presence notifications do not include presence subscriptions, only presence information that is broadcasted to contacts because those contacts are currently subscribed to the user's presence information. Thus this includes presence stanzas with no 'type' attribute or of type='unavailable' only.
Note: Presence notifications do not include presence subscriptions, only presence information that is broadcasted to contacts because those contacts are currently subscribed to the user's presence information. Thus this includes presence stanzas with no 'type' attribute or of type='unavailable' only.
Saint-Andre Standards Track [Page 78] RFC 3921 XMPP IM October 2004
Saint-Andre Standards Track [Page 78] RFC 3921 XMPP IM October 2004
Example: User blocks based on JID:
Example: User blocks based on JID:
<iq from='romeo@example.net/orchard' type='set' id='presout1'>
<query xmlns='jabber:iq:privacy'>
<list name='presout-jid-example'>
<item type='jid'
value='tybalt@example.com'
action='deny'
order='13'>
<presence-out/>
</item>
</list>
</query>
</iq>
<iq from='romeo@example.net/orchard' type='set' id='presout1'> <query xmlns='jabber:iq:privacy'> <list name='presout-jid-example'> <item type='jid' value='tybalt@example.com' action='deny' order='13'> <presence-out/> </item> </list> </query> </iq>
As a result of creating and applying the foregoing list, the user will not send presence notifications to the entity with the specified JID.
As a result of creating and applying the foregoing list, the user will not send presence notifications to the entity with the specified JID.
Example: User blocks based on roster group:
Example: User blocks based on roster group:
<iq from='romeo@example.net/orchard' type='set' id='presout2'>
<query xmlns='jabber:iq:privacy'>
<list name='presout-group-example'>
<item type='group'
value='Enemies'
action='deny'
order='15'>
<presence-out/>
</item>
</list>
</query>
</iq>
<iq from='romeo@example.net/orchard' type='set' id='presout2'> <query xmlns='jabber:iq:privacy'> <list name='presout-group-example'> <item type='group' value='Enemies' action='deny' order='15'> <presence-out/> </item> </list> </query> </iq>
As a result of creating and applying the foregoing list, the user will not send presence notifications to any entities in the specified roster group.
As a result of creating and applying the foregoing list, the user will not send presence notifications to any entities in the specified roster group.
Example: User blocks based on subscription type:
Example: User blocks based on subscription type:
<iq from='romeo@example.net/orchard' type='set' id='presout3'>
<query xmlns='jabber:iq:privacy'>
<list name='presout-sub-example'>
<item type='subscription'
value='from'
action='deny'
order='17'>
<presence-out/>
<iq from='romeo@example.net/orchard' type='set' id='presout3'> <query xmlns='jabber:iq:privacy'> <list name='presout-sub-example'> <item type='subscription' value='from' action='deny' order='17'> <presence-out/>
Saint-Andre Standards Track [Page 79] RFC 3921 XMPP IM October 2004
Saint-Andre Standards Track [Page 79] RFC 3921 XMPP IM October 2004
</item>
</list>
</query>
</iq>
</item> </list> </query> </iq>
As a result of creating and applying the foregoing list, the user will not send presence notifications to any entities with the specified subscription type.
As a result of creating and applying the foregoing list, the user will not send presence notifications to any entities with the specified subscription type.
Example: User blocks globally:
Example: User blocks globally:
<iq from='romeo@example.net/orchard' type='set' id='presout4'>
<query xmlns='jabber:iq:privacy'>
<list name='presout-global-example'>
<item action='deny' order='23'>
<presence-out/>
</item>
</list>
</query>
</iq>
<iq from='romeo@example.net/orchard' type='set' id='presout4'> <query xmlns='jabber:iq:privacy'> <list name='presout-global-example'> <item action='deny' order='23'> <presence-out/> </item> </list> </query> </iq>
As a result of creating and applying the foregoing list, the user will not send presence notifications to any other users.
As a result of creating and applying the foregoing list, the user will not send presence notifications to any other users.
10.12. Blocking IQ Stanzas
10.12. Blocking IQ Stanzas
Server-side privacy lists enable a user to block incoming IQ stanzas from other entities based on the entity's JID, roster group, or subscription status (or globally). The following examples illustrate the protocol.
Server-side privacy lists enable a user to block incoming IQ stanzas from other entities based on the entity's JID, roster group, or subscription status (or globally). The following examples illustrate the protocol.
Example: User blocks based on JID:
Example: User blocks based on JID:
<iq from='romeo@example.net/orchard' type='set' id='iq1'>
<query xmlns='jabber:iq:privacy'>
<list name='iq-jid-example'>
<item type='jid'
value='tybalt@example.com'
action='deny'
order='29'>
<iq/>
</item>
</list>
</query>
</iq>
<iq from='romeo@example.net/orchard' type='set' id='iq1'> <query xmlns='jabber:iq:privacy'> <list name='iq-jid-example'> <item type='jid' value='tybalt@example.com' action='deny' order='29'> <iq/> </item> </list> </query> </iq>
As a result of creating and applying the foregoing list, the user will not receive IQ stanzas from the entity with the specified JID.
As a result of creating and applying the foregoing list, the user will not receive IQ stanzas from the entity with the specified JID.
Saint-Andre Standards Track [Page 80] RFC 3921 XMPP IM October 2004
Saint-Andre Standards Track [Page 80] RFC 3921 XMPP IM October 2004
Example: User blocks based on roster group:
Example: User blocks based on roster group:
<iq from='romeo@example.net/orchard' type='set' id='iq2'>
<query xmlns='jabber:iq:privacy'>
<list name='iq-group-example'>
<item type='group'
value='Enemies'
action='deny'
order='31'>
<iq/>
</item>
</list>
</query>
</iq>
<iq from='romeo@example.net/orchard' type='set' id='iq2'> <query xmlns='jabber:iq:privacy'> <list name='iq-group-example'> <item type='group' value='Enemies' action='deny' order='31'> <iq/> </item> </list> </query> </iq>
As a result of creating and applying the foregoing list, the user will not receive IQ stanzas from any entities in the specified roster group.
As a result of creating and applying the foregoing list, the user will not receive IQ stanzas from any entities in the specified roster group.
Example: User blocks based on subscription type:
Example: User blocks based on subscription type:
<iq from='romeo@example.net/orchard' type='set' id='iq3'>
<query xmlns='jabber:iq:privacy'>
<list name='iq-sub-example'>
<item type='subscription'
value='none'
action='deny'
order='17'>
<iq/>
</item>
</list>
</query>
</iq>
<iq from='romeo@example.net/orchard' type='set' id='iq3'> <query xmlns='jabber:iq:privacy'> <list name='iq-sub-example'> <item type='subscription' value='none' action='deny' order='17'> <iq/> </item> </list> </query> </iq>
As a result of creating and applying the foregoing list, the user will not receive IQ stanzas from any entities with the specified subscription type.
As a result of creating and applying the foregoing list, the user will not receive IQ stanzas from any entities with the specified subscription type.
Saint-Andre Standards Track [Page 81] RFC 3921 XMPP IM October 2004
Saint-Andre Standards Track [Page 81] RFC 3921 XMPP IM October 2004
Example: User blocks globally:
Example: User blocks globally:
<iq from='romeo@example.net/orchard' type='set' id='iq4'>
<query xmlns='jabber:iq:privacy'>
<list name='iq-global-example'>
<item action='deny' order='1'>
<iq/>
</item>
</list>
</query>
</iq>
<iq from='romeo@example.net/orchard' type='set' id='iq4'> <query xmlns='jabber:iq:privacy'> <list name='iq-global-example'> <item action='deny' order='1'> <iq/> </item> </list> </query> </iq>
As a result of creating and applying the foregoing list, the user will not receive IQ stanzas from any other users.
As a result of creating and applying the foregoing list, the user will not receive IQ stanzas from any other users.
10.13. Blocking All Communication
10.13. Blocking All Communication
Server-side privacy lists enable a user to block all stanzas from and to other entities based on the entity's JID, roster group, or subscription status (or globally). Note that this includes subscription-related presence stanzas, which are excluded by Blocking Inbound Presence Notifications (Section 10.10). The following examples illustrate the protocol.
Server-side privacy lists enable a user to block all stanzas from and to other entities based on the entity's JID, roster group, or subscription status (or globally). Note that this includes subscription-related presence stanzas, which are excluded by Blocking Inbound Presence Notifications (Section 10.10). The following examples illustrate the protocol.
Example: User blocks based on JID:
Example: User blocks based on JID:
<iq from='romeo@example.net/orchard' type='set' id='all1'>
<query xmlns='jabber:iq:privacy'>
<list name='all-jid-example'>
<item type='jid'
value='tybalt@example.com'
action='deny'
order='23'/>
</list>
</query>
</iq>
<iq from='romeo@example.net/orchard' type='set' id='all1'> <query xmlns='jabber:iq:privacy'> <list name='all-jid-example'> <item type='jid' value='tybalt@example.com' action='deny' order='23'/> </list> </query> </iq>
As a result of creating and applying the foregoing list, the user will not receive any communications from, nor send any stanzas to, the entity with the specified JID.
As a result of creating and applying the foregoing list, the user will not receive any communications from, nor send any stanzas to, the entity with the specified JID.
Example: User blocks based on roster group:
Example: User blocks based on roster group:
<iq from='romeo@example.net/orchard' type='set' id='all2'>
<query xmlns='jabber:iq:privacy'>
<list name='all-group-example'>
<item type='group'
value='Enemies'
<iq from='romeo@example.net/orchard' type='set' id='all2'> <query xmlns='jabber:iq:privacy'> <list name='all-group-example'> <item type='group' value='Enemies'
Saint-Andre Standards Track [Page 82] RFC 3921 XMPP IM October 2004
Saint-Andre Standards Track [Page 82] RFC 3921 XMPP IM October 2004
action='deny'
order='13'/>
</list>
</query>
</iq>
action='deny' order='13'/> </list> </query> </iq>
As a result of creating and applying the foregoing list, the user will not receive any communications from, nor send any stanzas to, any entities in the specified roster group.
As a result of creating and applying the foregoing list, the user will not receive any communications from, nor send any stanzas to, any entities in the specified roster group.
Example: User blocks based on subscription type:
Example: User blocks based on subscription type:
<iq from='romeo@example.net/orchard' type='set' id='all3'>
<query xmlns='jabber:iq:privacy'>
<list name='all-sub-example'>
<item type='subscription'
value='none'
action='deny'
order='11'/>
</list>
</query>
</iq>
<iq from='romeo@example.net/orchard' type='set' id='all3'> <query xmlns='jabber:iq:privacy'> <list name='all-sub-example'> <item type='subscription' value='none' action='deny' order='11'/> </list> </query> </iq>
As a result of creating and applying the foregoing list, the user will not receive any communications from, nor send any stanzas to, any entities with the specified subscription type.
As a result of creating and applying the foregoing list, the user will not receive any communications from, nor send any stanzas to, any entities with the specified subscription type.
Example: User blocks globally:
Example: User blocks globally:
<iq from='romeo@example.net/orchard' type='set' id='all4'>
<query xmlns='jabber:iq:privacy'>
<list name='all-global-example'>
<item action='deny' order='7'/>
</list>
</query>
</iq>
<iq from='romeo@example.net/orchard' type='set' id='all4'> <query xmlns='jabber:iq:privacy'> <list name='all-global-example'> <item action='deny' order='7'/> </list> </query> </iq>
As a result of creating and applying the foregoing list, the user will not receive any communications from, nor send any stanzas to, any other users.
As a result of creating and applying the foregoing list, the user will not receive any communications from, nor send any stanzas to, any other users.
10.14. Blocked Entity Attempts to Communicate with User
10.14. Blocked Entity Attempts to Communicate with User
If a blocked entity attempts to send message or presence stanzas to the user, the user's server SHOULD silently drop the stanza and MUST NOT return an error to the sending entity.
If a blocked entity attempts to send message or presence stanzas to the user, the user's server SHOULD silently drop the stanza and MUST NOT return an error to the sending entity.
Saint-Andre Standards Track [Page 83] RFC 3921 XMPP IM October 2004
Saint-Andre Standards Track [Page 83] RFC 3921 XMPP IM October 2004
If a blocked entity attempts to send an IQ stanza of type "get" or "set" to the user, the user's server MUST return to the sending entity a <service-unavailable/> stanza error, since this is the standard error code sent from a client that does not understand the namespace of an IQ get or set. IQ stanzas of other types SHOULD be silently dropped by the server.
If a blocked entity attempts to send an IQ stanza of type "get" or "set" to the user, the user's server MUST return to the sending entity a <service-unavailable/> stanza error, since this is the standard error code sent from a client that does not understand the namespace of an IQ get or set. IQ stanzas of other types SHOULD be silently dropped by the server.
Example: Blocked entity attempts to send IQ get:
Example: Blocked entity attempts to send IQ get:
<iq type='get'
to='romeo@example.net'
from='tybalt@example.com/pda'
id='probing1'>
<query xmlns='jabber:iq:version'/>
</iq>
<iq type='get' to='romeo@example.net' from='tybalt@example.com/pda' id='probing1'> <query xmlns='jabber:iq:version'/> </iq>
Example: Server returns error to blocked entity:
Example: Server returns error to blocked entity:
<iq type='error'
from='romeo@example.net'
to='tybalt@example.com/pda'
id='probing1'>
<query xmlns='jabber:iq:version'/>
<error type='cancel'>
<service-unavailable
xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
</error>
</iq>
<iq type='error' from='romeo@example.net' to='tybalt@example.com/pda' id='probing1'> <query xmlns='jabber:iq:version'/> <error type='cancel'> <service-unavailable xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/> </error> </iq>
10.15. Higher-Level Heuristics
10.15. Higher-Level Heuristics
When building a representation of a higher-level privacy heuristic, a client SHOULD use the simplest possible representation.
When building a representation of a higher-level privacy heuristic, a client SHOULD use the simplest possible representation.
For example, the heuristic "block all communications with any user not in my roster" could be constructed in any of the following ways:
For example, the heuristic "block all communications with any user not in my roster" could be constructed in any of the following ways:
o allow communications from all JIDs in my roster (i.e., listing
each JID as a separate list item), but block communications with
everyone else
o allow communications from all JIDs in my roster (i.e., listing each JID as a separate list item), but block communications with everyone else
o allow communications from any user who is in one of the groups
that make up my roster (i.e., listing each group as a separate
list item), but block communications from everyone else
o allow communications from any user who is in one of the groups that make up my roster (i.e., listing each group as a separate list item), but block communications from everyone else
o allow communications from any user with whom I have a subscription
of 'both' or 'to' or 'from' (i.e., listing each subscription value
separately), but block communications from everyone else
o allow communications from any user with whom I have a subscription of 'both' or 'to' or 'from' (i.e., listing each subscription value separately), but block communications from everyone else
Saint-Andre Standards Track [Page 84] RFC 3921 XMPP IM October 2004
Saint-Andre Standards Track [Page 84] RFC 3921 XMPP IM October 2004
o block communications from anyone whose subscription state is
'none'
o block communications from anyone whose subscription state is 'none'
The final representation is the simplest and SHOULD be used; here is the XML that would be sent in this case:
The final representation is the simplest and SHOULD be used; here is the XML that would be sent in this case:
<iq type='set' id='heuristic1'>
<query xmlns='jabber:iq:privacy'>
<list name='heuristic-example'>
<item type='subscription'
value='none'
action='deny'
order='437'/>
</list>
</query>
</iq>
<iq type='set' id='heuristic1'> <query xmlns='jabber:iq:privacy'> <list name='heuristic-example'> <item type='subscription' value='none' action='deny' order='437'/> </list> </query> </iq>
11. Server Rules for Handling XML Stanzas
11. Server Rules for Handling XML Stanzas
Basic routing and delivery rules for servers are defined in [XMPP-CORE]. This section defines additional rules for XMPP-compliant instant messaging and presence servers.
Basic routing and delivery rules for servers are defined in [XMPP-CORE]. This section defines additional rules for XMPP-compliant instant messaging and presence servers.
11.1. Inbound Stanzas
11.1. Inbound Stanzas
If the hostname of the domain identifier portion of the JID contained in the 'to' attribute of an inbound stanza matches a hostname of the server itself and the JID contained in the 'to' attribute is of the form <user@example.com> or <user@example.com/resource>, the server MUST first apply any privacy lists (Section 10) that are in force, then follow the rules defined below:
If the hostname of the domain identifier portion of the JID contained in the 'to' attribute of an inbound stanza matches a hostname of the server itself and the JID contained in the 'to' attribute is of the form <user@example.com> or <user@example.com/resource>, the server MUST first apply any privacy lists (Section 10) that are in force, then follow the rules defined below:
1. If the JID is of the form <user@domain/resource> and an available
resource matches the full JID, the recipient's server MUST
deliver the stanza to that resource.
1. If the JID is of the form <user@domain/resource> and an available resource matches the full JID, the recipient's server MUST deliver the stanza to that resource.
2. Else if the JID is of the form <user@domain> or <user@domain/
resource> and the associated user account does not exist, the
recipient's server (a) SHOULD silently ignore the stanza (i.e.,
neither deliver it nor return an error) if it is a presence
stanza, (b) MUST return a <service-unavailable/> stanza error to
the sender if it is an IQ stanza, and (c) SHOULD return a
<service-unavailable/> stanza error to the sender if it is a
message stanza.
2. Else if the JID is of the form <user@domain> or <user@domain/ resource> and the associated user account does not exist, the recipient's server (a) SHOULD silently ignore the stanza (i.e., neither deliver it nor return an error) if it is a presence stanza, (b) MUST return a <service-unavailable/> stanza error to the sender if it is an IQ stanza, and (c) SHOULD return a <service-unavailable/> stanza error to the sender if it is a message stanza.
3. Else if the JID is of the form <user@domain/resource> and no
available resource matches the full JID, the recipient's server
(a) SHOULD silently ignore the stanza (i.e., neither deliver it
3. Else if the JID is of the form <user@domain/resource> and no available resource matches the full JID, the recipient's server (a) SHOULD silently ignore the stanza (i.e., neither deliver it
Saint-Andre Standards Track [Page 85] RFC 3921 XMPP IM October 2004
Saint-Andre Standards Track [Page 85] RFC 3921 XMPP IM October 2004
nor return an error) if it is a presence stanza, (b) MUST return
a <service-unavailable/> stanza error to the sender if it is an
IQ stanza, and (c) SHOULD treat the stanza as if it were
addressed to <user@domain> if it is a message stanza.
nor return an error) if it is a presence stanza, (b) MUST return a <service-unavailable/> stanza error to the sender if it is an IQ stanza, and (c) SHOULD treat the stanza as if it were addressed to <user@domain> if it is a message stanza.
4. Else if the JID is of the form <user@domain> and there is at
least one available resource available for the user, the
recipient's server MUST follow these rules:
4. Else if the JID is of the form <user@domain> and there is at least one available resource available for the user, the recipient's server MUST follow these rules:
1. For message stanzas, the server SHOULD deliver the stanza to
the highest-priority available resource (if the resource did
not provide a value for the <priority/> element, the server
SHOULD consider it to have provided a value of zero). If two
or more available resources have the same priority, the
server MAY use some other rule (e.g., most recent connect
time, most recent activity time, or highest availability as
determined by some hierarchy of <show/> values) to choose
between them or MAY deliver the message to all such
resources. However, the server MUST NOT deliver the stanza
to an available resource with a negative priority; if the
only available resource has a negative priority, the server
SHOULD handle the message as if there were no available
resources (defined below). In addition, the server MUST NOT
rewrite the 'to' attribute (i.e., it MUST leave it as
<user@domain> rather than change it to <user@domain/
resource>).
1. For message stanzas, the server SHOULD deliver the stanza to the highest-priority available resource (if the resource did not provide a value for the <priority/> element, the server SHOULD consider it to have provided a value of zero). If two or more available resources have the same priority, the server MAY use some other rule (e.g., most recent connect time, most recent activity time, or highest availability as determined by some hierarchy of <show/> values) to choose between them or MAY deliver the message to all such resources. However, the server MUST NOT deliver the stanza to an available resource with a negative priority; if the only available resource has a negative priority, the server SHOULD handle the message as if there were no available resources (defined below). In addition, the server MUST NOT rewrite the 'to' attribute (i.e., it MUST leave it as <user@domain> rather than change it to <user@domain/ resource>).
2. For presence stanzas other than those of type "probe", the
server MUST deliver the stanza to all available resources;
for presence probes, the server SHOULD reply based on the
rules defined in Presence Probes (Section 5.1.3). In
addition, the server MUST NOT rewrite the 'to' attribute
(i.e., it MUST leave it as <user@domain> rather than change
it to <user@domain/resource>).
2. For presence stanzas other than those of type "probe", the server MUST deliver the stanza to all available resources; for presence probes, the server SHOULD reply based on the rules defined in Presence Probes (Section 5.1.3). In addition, the server MUST NOT rewrite the 'to' attribute (i.e., it MUST leave it as <user@domain> rather than change it to <user@domain/resource>).
3. For IQ stanzas, the server itself MUST reply on behalf of the
user with either an IQ result or an IQ error, and MUST NOT
deliver the IQ stanza to any of the available resources.
Specifically, if the semantics of the qualifying namespace
define a reply that the server can provide, the server MUST
reply to the stanza on behalf of the user; if not, the server
MUST reply with a <service-unavailable/> stanza error.
3. For IQ stanzas, the server itself MUST reply on behalf of the user with either an IQ result or an IQ error, and MUST NOT deliver the IQ stanza to any of the available resources. Specifically, if the semantics of the qualifying namespace define a reply that the server can provide, the server MUST reply to the stanza on behalf of the user; if not, the server MUST reply with a <service-unavailable/> stanza error.
5. Else if the JID is of the form <user@domain> and there are no
available resources associated with the user, how the stanza is
handled depends on the stanza type:
5. Else if the JID is of the form <user@domain> and there are no available resources associated with the user, how the stanza is handled depends on the stanza type:
Saint-Andre Standards Track [Page 86] RFC 3921 XMPP IM October 2004
Saint-Andre Standards Track [Page 86] RFC 3921 XMPP IM October 2004
1. For presence stanzas of type "subscribe", "subscribed",
"unsubscribe", and "unsubscribed", the server MUST maintain a
record of the stanza and deliver the stanza at least once
(i.e., when the user next creates an available resource); in
addition, the server MUST continue to deliver presence
stanzas of type "subscribe" until the user either approves or
denies the subscription request (see also Presence
Subscriptions (Section 5.1.6)).
1. For presence stanzas of type "subscribe", "subscribed", "unsubscribe", and "unsubscribed", the server MUST maintain a record of the stanza and deliver the stanza at least once (i.e., when the user next creates an available resource); in addition, the server MUST continue to deliver presence stanzas of type "subscribe" until the user either approves or denies the subscription request (see also Presence Subscriptions (Section 5.1.6)).
2. For all other presence stanzas, the server SHOULD silently
ignore the stanza by not storing it for later delivery or
replying to it on behalf of the user.
2. For all other presence stanzas, the server SHOULD silently ignore the stanza by not storing it for later delivery or replying to it on behalf of the user.
3. For message stanzas, the server MAY choose to store the
stanza on behalf of the user and deliver it when the user
next becomes available, or forward the message to the user
via some other means (e.g., to the user's email account).
However, if offline message storage or message forwarding is
not enabled, the server MUST return to the sender a
<service-unavailable/> stanza error. (Note: Offline message
storage and message forwarding are not defined in XMPP, since
they are strictly a matter of implementation and service
provisioning.)
3. For message stanzas, the server MAY choose to store the stanza on behalf of the user and deliver it when the user next becomes available, or forward the message to the user via some other means (e.g., to the user's email account). However, if offline message storage or message forwarding is not enabled, the server MUST return to the sender a <service-unavailable/> stanza error. (Note: Offline message storage and message forwarding are not defined in XMPP, since they are strictly a matter of implementation and service provisioning.)
4. For IQ stanzas, the server itself MUST reply on behalf of the
user with either an IQ result or an IQ error. Specifically,
if the semantics of the qualifying namespace define a reply
that the server can provide, the server MUST reply to the
stanza on behalf of the user; if not, the server MUST reply
with a <service-unavailable/> stanza error.
4. For IQ stanzas, the server itself MUST reply on behalf of the user with either an IQ result or an IQ error. Specifically, if the semantics of the qualifying namespace define a reply that the server can provide, the server MUST reply to the stanza on behalf of the user; if not, the server MUST reply with a <service-unavailable/> stanza error.
11.2. Outbound Stanzas
11.2. Outbound Stanzas
If the hostname of the domain identifier portion of the address contained in the 'to' attribute of an outbound stanza matches a hostname of the server itself, the server MUST deliver the stanza to a local entity according the rules for Inbound Stanzas (Section 11.1).
If the hostname of the domain identifier portion of the address contained in the 'to' attribute of an outbound stanza matches a hostname of the server itself, the server MUST deliver the stanza to a local entity according the rules for Inbound Stanzas (Section 11.1).
If the hostname of the domain identifier portion of the address contained in the 'to' attribute of an outbound stanza does not match a hostname of the server itself, the server MUST attempt to route the stanza to the foreign domain. The recommended order of actions is as follows:
If the hostname of the domain identifier portion of the address contained in the 'to' attribute of an outbound stanza does not match a hostname of the server itself, the server MUST attempt to route the stanza to the foreign domain. The recommended order of actions is as follows:
Saint-Andre Standards Track [Page 87] RFC 3921 XMPP IM October 2004
Saint-Andre Standards Track [Page 87] RFC 3921 XMPP IM October 2004
1. First attempt to resolve the foreign hostname using an [SRV]
Service of "xmpp-server" and Proto of "tcp", resulting in
resource records such as "_xmpp-server._tcp.example.com.", as
specified in [XMPP-CORE].
1. First attempt to resolve the foreign hostname using an [SRV] Service of "xmpp-server" and Proto of "tcp", resulting in resource records such as "_xmpp-server._tcp.example.com.", as specified in [XMPP-CORE].
2. If the "xmpp-server" address record resolution fails, attempt to
resolve the "_im" or "_pres" [SRV] Service as specified in
[IMP-SRV], using the "_im" Service for <message/> stanzas and the
"_pres" Service for <presence/> stanzas (it is up to the
implementation how to handle <iq/> stanzas). This will result in
one or more resolutions of the form "_im.<proto>.example.com." or
"_pres.<proto>.example.com.", where "<proto>" would be a label
registered in the Instant Messaging SRV Protocol Label registry
or the Presence SRV Protocol Label registry: either "_xmpp" for
an XMPP-aware domain or some other IANA-registered label (e.g.,
"_simple") for a non-XMPP-aware domain.
2. If the "xmpp-server" address record resolution fails, attempt to resolve the "_im" or "_pres" [SRV] Service as specified in [IMP-SRV], using the "_im" Service for <message/> stanzas and the "_pres" Service for <presence/> stanzas (it is up to the implementation how to handle <iq/> stanzas). This will result in one or more resolutions of the form "_im.<proto>.example.com." or "_pres.<proto>.example.com.", where "<proto>" would be a label registered in the Instant Messaging SRV Protocol Label registry or the Presence SRV Protocol Label registry: either "_xmpp" for an XMPP-aware domain or some other IANA-registered label (e.g., "_simple") for a non-XMPP-aware domain.
3. If both SRV address record resolutions fail, attempt to perform a
normal IPv4/IPv6 address record resolution to determine the IP
address using the "xmpp-server" port of 5269 registered with the
IANA, as specified in [XMPP-CORE].
3. If both SRV address record resolutions fail, attempt to perform a normal IPv4/IPv6 address record resolution to determine the IP address using the "xmpp-server" port of 5269 registered with the IANA, as specified in [XMPP-CORE].
Administrators of server deployments are strongly encouraged to keep the _im._xmpp, _pres._xmpp, and _xmpp._tcp SRV records properly synchronized, since different implementations might perform the "_im" and "_pres" lookups before the "xmpp-server" lookup.
Administrators of server deployments are strongly encouraged to keep the _im._xmpp, _pres._xmpp, and _xmpp._tcp SRV records properly synchronized, since different implementations might perform the "_im" and "_pres" lookups before the "xmpp-server" lookup.
12. IM and Presence Compliance Requirements
12. IM and Presence Compliance Requirements
This section summarizes the specific aspects of the Extensible Messaging and Presence Protocol that MUST be supported by instant messaging and presence servers and clients in order to be considered compliant implementations. All such applications MUST comply with the requirements specified in [XMPP-CORE]. The text in this section specifies additional compliance requirements for instant messaging and presence servers and clients; note well that the requirements described here supplement but do not supersede the core requirements. Note also that a server or client MAY support only presence or instant messaging, and is not required to support both if only a presence service or an instant messaging service is desired.
This section summarizes the specific aspects of the Extensible Messaging and Presence Protocol that MUST be supported by instant messaging and presence servers and clients in order to be considered compliant implementations. All such applications MUST comply with the requirements specified in [XMPP-CORE]. The text in this section specifies additional compliance requirements for instant messaging and presence servers and clients; note well that the requirements described here supplement but do not supersede the core requirements. Note also that a server or client MAY support only presence or instant messaging, and is not required to support both if only a presence service or an instant messaging service is desired.
12.1. Servers
12.1. Servers
In addition to core server compliance requirements, an instant messaging and presence server MUST additionally support the following protocols:
In addition to core server compliance requirements, an instant messaging and presence server MUST additionally support the following protocols:
Saint-Andre Standards Track [Page 88] RFC 3921 XMPP IM October 2004
Saint-Andre Standards Track [Page 88] RFC 3921 XMPP IM October 2004
o All server-related instant messaging and presence syntax and
semantics defined in this document, including presence broadcast
on behalf of clients, presence subscriptions, roster storage and
manipulation, privacy lists, and IM-specific routing and delivery
rules
o All server-related instant messaging and presence syntax and semantics defined in this document, including presence broadcast on behalf of clients, presence subscriptions, roster storage and manipulation, privacy lists, and IM-specific routing and delivery rules
12.2. Clients
12.2. Clients
In addition to core client compliance requirements, an instant messaging and presence client MUST additionally support the following protocols:
In addition to core client compliance requirements, an instant messaging and presence client MUST additionally support the following protocols:
o Generation and handling of the IM-specific semantics of XML
stanzas as defined by the XML schemas, including the 'type'
attribute of message and presence stanzas as well as their child
elements
o Generation and handling of the IM-specific semantics of XML stanzas as defined by the XML schemas, including the 'type' attribute of message and presence stanzas as well as their child elements
o All client-related instant messaging syntax and semantics defined
in this document, including presence subscriptions, roster
management, and privacy lists
o All client-related instant messaging syntax and semantics defined in this document, including presence subscriptions, roster management, and privacy lists
o End-to-end object encryption as defined in End-to-End Object
Encryption in the Extensible Messaging and Presence Protocol
(XMPP) [XMPP-E2E]
o End-to-end object encryption as defined in End-to-End Object Encryption in the Extensible Messaging and Presence Protocol (XMPP) [XMPP-E2E]
A client MUST also handle addresses that are encoded as "im:" URIs as specified in [CPIM], and MAY do so by removing the "im:" scheme and entrusting address resolution to the server as specified under Outbound Stanzas (Section 11.2).
A client MUST also handle addresses that are encoded as "im:" URIs as specified in [CPIM], and MAY do so by removing the "im:" scheme and entrusting address resolution to the server as specified under Outbound Stanzas (Section 11.2).
13. Internationalization Considerations
13. Internationalization Considerations
For internationalization considerations, refer to the relevant section of [XMPP-CORE].
For internationalization considerations, refer to the relevant section of [XMPP-CORE].
14. Security Considerations
14. Security Considerations
Core security considerations for XMPP are defined in the relevant section of [XMPP-CORE].
Core security considerations for XMPP are defined in the relevant section of [XMPP-CORE].
Additional considerations that apply only to instant messaging and presence applications of XMPP are defined in several places within this memo; specifically:
Additional considerations that apply only to instant messaging and presence applications of XMPP are defined in several places within this memo; specifically:
Saint-Andre Standards Track [Page 89] RFC 3921 XMPP IM October 2004
Saint-Andre Standards Track [Page 89] RFC 3921 XMPP IM October 2004
o When a server processes an inbound stanza of any kind whose
intended recipient is a user associated with one of the server's
hostnames, the server MUST first apply any privacy lists (Section
10) that are in force (see Server Rules for Handling XML Stanzas
(Section 11)).
o When a server processes an inbound stanza of any kind whose intended recipient is a user associated with one of the server's hostnames, the server MUST first apply any privacy lists (Section 10) that are in force (see Server Rules for Handling XML Stanzas (Section 11)).
o When a server processes an inbound presence stanza of type "probe"
whose intended recipient is a user associated with one of the
server's hostnames, the server MUST NOT reveal the user's presence
information if the sender is an entity that is not authorized to
receive that information as determined by presence subscriptions
(see Client and Server Presence Responsibilities (Section 5.1)).
o When a server processes an inbound presence stanza of type "probe" whose intended recipient is a user associated with one of the server's hostnames, the server MUST NOT reveal the user's presence information if the sender is an entity that is not authorized to receive that information as determined by presence subscriptions (see Client and Server Presence Responsibilities (Section 5.1)).
o When a server processes an outbound presence stanza with no type
or of type "unavailable", it MUST follow the rules defined under
Client and Server Presence Responsibilities (Section 5.1) in order
to ensure that such presence information is not broadcasted to
entities that are not authorized to know such information.
o When a server processes an outbound presence stanza with no type or of type "unavailable", it MUST follow the rules defined under Client and Server Presence Responsibilities (Section 5.1) in order to ensure that such presence information is not broadcasted to entities that are not authorized to know such information.
o When a server generates an error stanza in response to receiving a
stanza for a user who does not exist, the use of the
<service-unavailable/> error condition helps protect against
well-known dictionary attacks, since this is the same error
condition that is returned if, for instance, the namespace of an
IQ child element is not understood, or if offline message storage
or message forwarding is not enabled for a domain.
o When a server generates an error stanza in response to receiving a stanza for a user who does not exist, the use of the <service-unavailable/> error condition helps protect against well-known dictionary attacks, since this is the same error condition that is returned if, for instance, the namespace of an IQ child element is not understood, or if offline message storage or message forwarding is not enabled for a domain.
15. IANA Considerations
15. IANA Considerations
For a number of related IANA considerations, refer to the relevant section of [XMPP-CORE].
For a number of related IANA considerations, refer to the relevant section of [XMPP-CORE].
15.1. XML Namespace Name for Session Data
15.1. XML Namespace Name for Session Data
A URN sub-namespace for session-related data in the Extensible Messaging and Presence Protocol (XMPP) is defined as follows. (This namespace name adheres to the format defined in The IETF XML Registry [XML-REG].)
A URN sub-namespace for session-related data in the Extensible Messaging and Presence Protocol (XMPP) is defined as follows. (This namespace name adheres to the format defined in The IETF XML Registry [XML-REG].)
URI: urn:ietf:params:xml:ns:xmpp-session
Specification: RFC 3921
Description: This is the XML namespace name for session-related data
in the Extensible Messaging and Presence Protocol (XMPP) as
defined by RFC 3921.
Registrant Contact: IETF, XMPP Working Group, <xmppwg@jabber.org>
URI: urn:ietf:params:xml:ns:xmpp-session Specification: RFC 3921 Description: This is the XML namespace name for session-related data in the Extensible Messaging and Presence Protocol (XMPP) as defined by RFC 3921. Registrant Contact: IETF, XMPP Working Group, <xmppwg@jabber.org>
Saint-Andre Standards Track [Page 90] RFC 3921 XMPP IM October 2004
Saint-Andre Standards Track [Page 90] RFC 3921 XMPP IM October 2004
15.2. Instant Messaging SRV Protocol Label Registration
15.2. Instant Messaging SRV Protocol Label Registration
Address Resolution for Instant Messaging and Presence [IMP-SRV] defines an Instant Messaging SRV Protocol Label registry for protocols that can provide services that conform to the "_im" SRV Service label. Because XMPP is one such protocol, the IANA registers the "_xmpp" protocol label in the appropriate registry, as follows:
Address Resolution for Instant Messaging and Presence [IMP-SRV] defines an Instant Messaging SRV Protocol Label registry for protocols that can provide services that conform to the "_im" SRV Service label. Because XMPP is one such protocol, the IANA registers the "_xmpp" protocol label in the appropriate registry, as follows:
Protocol label: _xmpp
Specification: RFC 3921
Description: Instant messaging protocol label for the Extensible
Messaging and Presence Protocol (XMPP) as defined by RFC 3921.
Registrant Contact: IETF, XMPP Working Group, <xmppwg@jabber.org>
Protocol label: _xmpp Specification: RFC 3921 Description: Instant messaging protocol label for the Extensible Messaging and Presence Protocol (XMPP) as defined by RFC 3921. Registrant Contact: IETF, XMPP Working Group, <xmppwg@jabber.org>
15.3. Presence SRV Protocol Label Registration
15.3. Presence SRV Protocol Label Registration
Address Resolution for Instant Messaging and Presence [IMP-SRV] defines a Presence SRV Protocol Label registry for protocols that can provide services that conform to the "_pres" SRV Service label. Because XMPP is one such protocol, the IANA registers the "_xmpp" protocol label in the appropriate registry, as follows:
Address Resolution for Instant Messaging and Presence [IMP-SRV] defines a Presence SRV Protocol Label registry for protocols that can provide services that conform to the "_pres" SRV Service label. Because XMPP is one such protocol, the IANA registers the "_xmpp" protocol label in the appropriate registry, as follows:
Protocol label: _xmpp
Specification: RFC 3921
Description: Presence protocol label for the Extensible Messaging and
Presence Protocol (XMPP) as defined by RFC 3921.
Registrant Contact: IETF, XMPP Working Group, <xmppwg@jabber.org>
Protocol label: _xmpp Specification: RFC 3921 Description: Presence protocol label for the Extensible Messaging and Presence Protocol (XMPP) as defined by RFC 3921. Registrant Contact: IETF, XMPP Working Group, <xmppwg@jabber.org>
16. References
16. References
16.1. Normative References
16.1. Normative References
[CPIM] Peterson, J., "Common Profile for Instant Messaging
(CPIM)", RFC 3860, August 2004.
[CPIM] Peterson, J., "Common Profile for Instant Messaging (CPIM)", RFC 3860, August 2004.
[IMP-REQS] Day, M., Aggarwal, S., Mohr, G., and J. Vincent, "Instant
Messaging/Presence Protocol Requirements", RFC 2779,
February 2000.
[IMP-REQS] Day, M., Aggarwal, S., Mohr, G., and J. Vincent, "Instant Messaging/Presence Protocol Requirements", RFC 2779, February 2000.
[IMP-SRV] Peterson, J., "Address Resolution for Instant Messaging
and Presence", RFC 3861, August 2004.
[IMP-SRV] Peterson, J., "Address Resolution for Instant Messaging and Presence", RFC 3861, August 2004.
[SRV] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for
specifying the location of services (DNS SRV)", RFC 2782,
February 2000.
[SRV] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for specifying the location of services (DNS SRV)", RFC 2782, February 2000.
[TERMS] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[TERMS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
Saint-Andre Standards Track [Page 91] RFC 3921 XMPP IM October 2004
Saint-Andre Standards Track [Page 91] RFC 3921 XMPP IM October 2004
[XML] Bray, T., Paoli, J., Sperberg-McQueen, C., and E. Maler,
"Extensible Markup Language (XML) 1.0 (2nd ed)", W3C
REC-xml, October 2000, <http://www.w3.org/TR/REC-xml>.
[XML] Bray, T., Paoli, J., Sperberg-McQueen, C., and E. Maler, "Extensible Markup Language (XML) 1.0 (2nd ed)", W3C REC-xml, October 2000, <http://www.w3.org/TR/REC-xml>.
[XML-NAMES] Bray, T., Hollander, D., and A. Layman, "Namespaces in
XML", W3C REC-xml-names, January 1999,
<http://www.w3.org/TR/REC-xml-names>.
[XML-NAMES] Bray, T., Hollander, D., and A. Layman, "Namespaces in XML", W3C REC-xml-names, January 1999, <http://www.w3.org/TR/REC-xml-names>.
[XMPP-CORE] Saint-Andre, P., "Extensible Messaging and Presence
Protocol (XMPP): Core", RFC 3920, October 2004.
[XMPP-CORE] Saint-Andre, P., "Extensible Messaging and Presence Protocol (XMPP): Core", RFC 3920, October 2004.
[XMPP-E2E] Saint-Andre, P., "End-to-End Object Encryption in the
Extensible Messaging and Presence Protocol (XMPP)", RFC
3923, October 2004.
[XMPP-E2E] Saint-Andre, P., "End-to-End Object Encryption in the Extensible Messaging and Presence Protocol (XMPP)", RFC 3923, October 2004.
16.2. Informative References
16.2. Informative References
[IMP-MODEL] Day, M., Rosenberg, J., and H. Sugano, "A Model for
Presence and Instant Messaging", RFC 2778, February 2000.
[IMP-MODEL] Day, M., Rosenberg, J., and H. Sugano, "A Model for Presence and Instant Messaging", RFC 2778, February 2000.
[IRC] Oikarinen, J. and D. Reed, "Internet Relay Chat
Protocol", RFC 1459, May 1993.
[IRC] Oikarinen, J. and D. Reed, "Internet Relay Chat Protocol", RFC 1459, May 1993.
[JEP-0054] Saint-Andre, P., "vcard-temp", JSF JEP 0054, March 2003.
[JEP-0054] Saint-Andre, P., "vcard-temp", JSF JEP 0054, March 2003.
[JEP-0077] Saint-Andre, P., "In-Band Registration", JSF JEP 0077,
August 2004.
[JEP-0077] Saint-Andre, P., "In-Band Registration", JSF JEP 0077, August 2004.
[JEP-0078] Saint-Andre, P., "Non-SASL Authentication", JSF JEP 0078,
July 2004.
[JEP-0078] Saint-Andre, P., "Non-SASL Authentication", JSF JEP 0078, July 2004.
[JSF] Jabber Software Foundation, "Jabber Software Foundation",
<http://www.jabber.org/>.
[JSF] Jabber Software Foundation, "Jabber Software Foundation", <http://www.jabber.org/>.
[VCARD] Dawson, F. and T. Howes, "vCard MIME Directory Profile",
RFC 2426, September 1998.
[VCARD] Dawson, F. and T. Howes, "vCard MIME Directory Profile", RFC 2426, September 1998.
[XML-REG] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
January 2004.
[XML-REG] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, January 2004.
Saint-Andre Standards Track [Page 92] RFC 3921 XMPP IM October 2004
Saint-Andre Standards Track [Page 92] RFC 3921 XMPP IM October 2004
Appendix A. vCards
Appendix A. vCards
Sections 3.1.3 and 4.1.4 of [IMP-REQS] require that it be possible to retrieve out-of-band contact information for other users (e.g., telephone number or email address). An XML representation of the vCard specification defined in RFC 2426 [VCARD] is in common use within the Jabber community to provide such information but is out of scope for XMPP (documentation of this protocol is contained in [JEP-0054], published by the Jabber Software Foundation [JSF]).
Sections 3.1.3 and 4.1.4 of [IMP-REQS] require that it be possible to retrieve out-of-band contact information for other users (e.g., telephone number or email address). An XML representation of the vCard specification defined in RFC 2426 [VCARD] is in common use within the Jabber community to provide such information but is out of scope for XMPP (documentation of this protocol is contained in [JEP-0054], published by the Jabber Software Foundation [JSF]).
Appendix B. XML Schemas
Appendix B. XML Schemas
The following XML schemas are descriptive, not normative. For schemas defining the core features of XMPP, refer to [XMPP-CORE].
The following XML schemas are descriptive, not normative. For schemas defining the core features of XMPP, refer to [XMPP-CORE].
B.1 jabber:client
B.1 jabber:client
<?xml version='1.0' encoding='UTF-8'?>
<?xml version='1.0' encoding='UTF-8'?>
<xs:schema
xmlns:xs='http://www.w3.org/2001/XMLSchema'
targetNamespace='jabber:client'
xmlns='jabber:client'
elementFormDefault='qualified'>
<xs:schema xmlns:xs='http://www.w3.org/2001/XMLSchema' targetNamespace='jabber:client' xmlns='jabber:client' elementFormDefault='qualified'>
<xs:import namespace='urn:ietf:params:xml:ns:xmpp-stanzas'/>
<xs:import namespace='urn:ietf:params:xml:ns:xmpp-stanzas'/>
<xs:element name='message'>
<xs:complexType>
<xs:sequence>
<xs:choice minOccurs='0' maxOccurs='unbounded'>
<xs:element ref='subject'/>
<xs:element ref='body'/>
<xs:element ref='thread'/>
</xs:choice>
<xs:any namespace='##other'
minOccurs='0'
maxOccurs='unbounded'/>
<xs:element ref='error'
minOccurs='0'/>
<xs:element name='message'> <xs:complexType> <xs:sequence> <xs:choice minOccurs='0' maxOccurs='unbounded'> <xs:element ref='subject'/> <xs:element ref='body'/> <xs:element ref='thread'/> </xs:choice> <xs:any namespace='##other' minOccurs='0' maxOccurs='unbounded'/> <xs:element ref='error' minOccurs='0'/>
Saint-Andre Standards Track [Page 93] RFC 3921 XMPP IM October 2004
Saint-Andre Standards Track [Page 93] RFC 3921 XMPP IM October 2004
</xs:sequence>
<xs:attribute name='from'
type='xs:string'
use='optional'/>
<xs:attribute name='id'
type='xs:NMTOKEN'
use='optional'/>
<xs:attribute name='to'
type='xs:string'
use='optional'/>
<xs:attribute name='type' use='optional' default='normal'>
<xs:simpleType>
<xs:restriction base='xs:NCName'>
<xs:enumeration value='chat'/>
<xs:enumeration value='error'/>
<xs:enumeration value='groupchat'/>
<xs:enumeration value='headline'/>
<xs:enumeration value='normal'/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
<xs:attribute ref='xml:lang' use='optional'/>
</xs:complexType>
</xs:element>
</xs:sequence> <xs:attribute name='from' type='xs:string' use='optional'/> <xs:attribute name='id' type='xs:NMTOKEN' use='optional'/> <xs:attribute name='to' type='xs:string' use='optional'/> <xs:attribute name='type' use='optional' default='normal'> <xs:simpleType> <xs:restriction base='xs:NCName'> <xs:enumeration value='chat'/> <xs:enumeration value='error'/> <xs:enumeration value='groupchat'/> <xs:enumeration value='headline'/> <xs:enumeration value='normal'/> </xs:restriction> </xs:simpleType> </xs:attribute> <xs:attribute ref='xml:lang' use='optional'/> </xs:complexType> </xs:element>
<xs:element name='body'>
<xs:complexType>
<xs:simpleContent>
<xs:extension base='xs:string'>
<xs:attribute ref='xml:lang' use='optional'/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
</xs:element>
<xs:element name='body'> <xs:complexType> <xs:simpleContent> <xs:extension base='xs:string'> <xs:attribute ref='xml:lang' use='optional'/> </xs:extension> </xs:simpleContent> </xs:complexType> </xs:element>
<xs:element name='subject'>
<xs:complexType>
<xs:simpleContent>
<xs:extension base='xs:string'>
<xs:attribute ref='xml:lang' use='optional'/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
</xs:element>
<xs:element name='subject'> <xs:complexType> <xs:simpleContent> <xs:extension base='xs:string'> <xs:attribute ref='xml:lang' use='optional'/> </xs:extension> </xs:simpleContent> </xs:complexType> </xs:element>
<xs:element name='thread' type='xs:NMTOKEN'/>
<xs:element name='thread' type='xs:NMTOKEN'/>
<xs:element name='presence'>
<xs:element name='presence'>
Saint-Andre Standards Track [Page 94] RFC 3921 XMPP IM October 2004
Saint-Andre Standards Track [Page 94] RFC 3921 XMPP IM October 2004
<xs:complexType>
<xs:sequence>
<xs:choice minOccurs='0' maxOccurs='unbounded'>
<xs:element ref='show'/>
<xs:element ref='status'/>
<xs:element ref='priority'/>
</xs:choice>
<xs:any namespace='##other'
minOccurs='0'
maxOccurs='unbounded'/>
<xs:element ref='error'
minOccurs='0'/>
</xs:sequence>
<xs:attribute name='from'
type='xs:string'
use='optional'/>
<xs:attribute name='id'
type='xs:NMTOKEN'
use='optional'/>
<xs:attribute name='to'
type='xs:string'
use='optional'/>
<xs:attribute name='type' use='optional'>
<xs:simpleType>
<xs:restriction base='xs:NCName'>
<xs:enumeration value='error'/>
<xs:enumeration value='probe'/>
<xs:enumeration value='subscribe'/>
<xs:enumeration value='subscribed'/>
<xs:enumeration value='unavailable'/>
<xs:enumeration value='unsubscribe'/>
<xs:enumeration value='unsubscribed'/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
<xs:attribute ref='xml:lang' use='optional'/>
</xs:complexType>
</xs:element>
<xs:complexType> <xs:sequence> <xs:choice minOccurs='0' maxOccurs='unbounded'> <xs:element ref='show'/> <xs:element ref='status'/> <xs:element ref='priority'/> </xs:choice> <xs:any namespace='##other' minOccurs='0' maxOccurs='unbounded'/> <xs:element ref='error' minOccurs='0'/> </xs:sequence> <xs:attribute name='from' type='xs:string' use='optional'/> <xs:attribute name='id' type='xs:NMTOKEN' use='optional'/> <xs:attribute name='to' type='xs:string' use='optional'/> <xs:attribute name='type' use='optional'> <xs:simpleType> <xs:restriction base='xs:NCName'> <xs:enumeration value='error'/> <xs:enumeration value='probe'/> <xs:enumeration value='subscribe'/> <xs:enumeration value='subscribed'/> <xs:enumeration value='unavailable'/> <xs:enumeration value='unsubscribe'/> <xs:enumeration value='unsubscribed'/> </xs:restriction> </xs:simpleType> </xs:attribute> <xs:attribute ref='xml:lang' use='optional'/> </xs:complexType> </xs:element>
<xs:element name='show'>
<xs:simpleType>
<xs:restriction base='xs:NCName'>
<xs:enumeration value='away'/>
<xs:enumeration value='chat'/>
<xs:enumeration value='dnd'/>
<xs:enumeration value='xa'/>
</xs:restriction>
</xs:simpleType>
<xs:element name='show'> <xs:simpleType> <xs:restriction base='xs:NCName'> <xs:enumeration value='away'/> <xs:enumeration value='chat'/> <xs:enumeration value='dnd'/> <xs:enumeration value='xa'/> </xs:restriction> </xs:simpleType>
Saint-Andre Standards Track [Page 95] RFC 3921 XMPP IM October 2004
Saint-Andre Standards Track [Page 95] RFC 3921 XMPP IM October 2004
</xs:element>
</xs:element>
<xs:element name='status'>
<xs:complexType>
<xs:simpleContent>
<xs:extension base='xs:string'>
<xs:attribute ref='xml:lang' use='optional'/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
</xs:element>
<xs:element name='status'> <xs:complexType> <xs:simpleContent> <xs:extension base='xs:string'> <xs:attribute ref='xml:lang' use='optional'/> </xs:extension> </xs:simpleContent> </xs:complexType> </xs:element>
<xs:element name='priority' type='xs:byte'/>
<xs:element name='priority' type='xs:byte'/>
<xs:element name='iq'>
<xs:complexType>
<xs:sequence>
<xs:any namespace='##other'
minOccurs='0'/>
<xs:element ref='error'
minOccurs='0'/>
</xs:sequence>
<xs:attribute name='from'
type='xs:string'
use='optional'/>
<xs:attribute name='id'
type='xs:NMTOKEN'
use='required'/>
<xs:attribute name='to'
type='xs:string'
use='optional'/>
<xs:attribute name='type' use='required'>
<xs:simpleType>
<xs:restriction base='xs:NCName'>
<xs:enumeration value='error'/>
<xs:enumeration value='get'/>
<xs:enumeration value='result'/>
<xs:enumeration value='set'/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
<xs:attribute ref='xml:lang' use='optional'/>
</xs:complexType>
</xs:element>
<xs:element name='iq'> <xs:complexType> <xs:sequence> <xs:any namespace='##other' minOccurs='0'/> <xs:element ref='error' minOccurs='0'/> </xs:sequence> <xs:attribute name='from' type='xs:string' use='optional'/> <xs:attribute name='id' type='xs:NMTOKEN' use='required'/> <xs:attribute name='to' type='xs:string' use='optional'/> <xs:attribute name='type' use='required'> <xs:simpleType> <xs:restriction base='xs:NCName'> <xs:enumeration value='error'/> <xs:enumeration value='get'/> <xs:enumeration value='result'/> <xs:enumeration value='set'/> </xs:restriction> </xs:simpleType> </xs:attribute> <xs:attribute ref='xml:lang' use='optional'/> </xs:complexType> </xs:element>
<xs:element name='error'>
<xs:complexType>
<xs:sequence xmlns:err='urn:ietf:params:xml:ns:xmpp-stanzas'>
<xs:element name='error'> <xs:complexType> <xs:sequence xmlns:err='urn:ietf:params:xml:ns:xmpp-stanzas'>
Saint-Andre Standards Track [Page 96] RFC 3921 XMPP IM October 2004
Saint-Andre Standards Track [Page 96] RFC 3921 XMPP IM October 2004
<xs:group ref='err:stanzaErrorGroup'/>
<xs:element ref='err:text'
minOccurs='0'/>
</xs:sequence>
<xs:attribute name='code' type='xs:byte' use='optional'/>
<xs:attribute name='type' use='required'>
<xs:simpleType>
<xs:restriction base='xs:NCName'>
<xs:enumeration value='auth'/>
<xs:enumeration value='cancel'/>
<xs:enumeration value='continue'/>
<xs:enumeration value='modify'/>
<xs:enumeration value='wait'/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
</xs:complexType>
</xs:element>
<xs:group ref='err:stanzaErrorGroup'/> <xs:element ref='err:text' minOccurs='0'/> </xs:sequence> <xs:attribute name='code' type='xs:byte' use='optional'/> <xs:attribute name='type' use='required'> <xs:simpleType> <xs:restriction base='xs:NCName'> <xs:enumeration value='auth'/> <xs:enumeration value='cancel'/> <xs:enumeration value='continue'/> <xs:enumeration value='modify'/> <xs:enumeration value='wait'/> </xs:restriction> </xs:simpleType> </xs:attribute> </xs:complexType> </xs:element>
</xs:schema>
</xs:schema>
B.2 jabber:server
B.2 jabber:server
<?xml version='1.0' encoding='UTF-8'?>
<?xml version='1.0' encoding='UTF-8'?>
<xs:schema
xmlns:xs='http://www.w3.org/2001/XMLSchema'
targetNamespace='jabber:server'
xmlns='jabber:server'
elementFormDefault='qualified'>
<xs:schema xmlns:xs='http://www.w3.org/2001/XMLSchema' targetNamespace='jabber:server' xmlns='jabber:server' elementFormDefault='qualified'>
<xs:import namespace='urn:ietf:params:xml:ns:xmpp-stanzas'/>
<xs:import namespace='urn:ietf:params:xml:ns:xmpp-stanzas'/>
<xs:element name='message'>
<xs:complexType>
<xs:sequence>
<xs:choice minOccurs='0' maxOccurs='unbounded'>
<xs:element ref='subject'/>
<xs:element ref='body'/>
<xs:element ref='thread'/>
</xs:choice>
<xs:any namespace='##other'
minOccurs='0'
maxOccurs='unbounded'/>
<xs:element ref='error'
minOccurs='0'/>
</xs:sequence>
<xs:element name='message'> <xs:complexType> <xs:sequence> <xs:choice minOccurs='0' maxOccurs='unbounded'> <xs:element ref='subject'/> <xs:element ref='body'/> <xs:element ref='thread'/> </xs:choice> <xs:any namespace='##other' minOccurs='0' maxOccurs='unbounded'/> <xs:element ref='error' minOccurs='0'/> </xs:sequence>
Saint-Andre Standards Track [Page 97] RFC 3921 XMPP IM October 2004
Saint-Andre Standards Track [Page 97] RFC 3921 XMPP IM October 2004
<xs:attribute name='from'
type='xs:string'
use='required'/>
<xs:attribute name='id'
type='xs:NMTOKEN'
use='optional'/>
<xs:attribute name='to'
type='xs:string'
use='required'/>
<xs:attribute name='type' use='optional' default='normal'>
<xs:simpleType>
<xs:restriction base='xs:NCName'>
<xs:enumeration value='chat'/>
<xs:enumeration value='error'/>
<xs:enumeration value='groupchat'/>
<xs:enumeration value='headline'/>
<xs:enumeration value='normal'/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
<xs:attribute ref='xml:lang' use='optional'/>
</xs:complexType>
</xs:element>
<xs:attribute name='from' type='xs:string' use='required'/> <xs:attribute name='id' type='xs:NMTOKEN' use='optional'/> <xs:attribute name='to' type='xs:string' use='required'/> <xs:attribute name='type' use='optional' default='normal'> <xs:simpleType> <xs:restriction base='xs:NCName'> <xs:enumeration value='chat'/> <xs:enumeration value='error'/> <xs:enumeration value='groupchat'/> <xs:enumeration value='headline'/> <xs:enumeration value='normal'/> </xs:restriction> </xs:simpleType> </xs:attribute> <xs:attribute ref='xml:lang' use='optional'/> </xs:complexType> </xs:element>
<xs:element name='body'>
<xs:complexType>
<xs:simpleContent>
<xs:extension base='xs:string'>
<xs:attribute ref='xml:lang' use='optional'/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
</xs:element>
<xs:element name='body'> <xs:complexType> <xs:simpleContent> <xs:extension base='xs:string'> <xs:attribute ref='xml:lang' use='optional'/> </xs:extension> </xs:simpleContent> </xs:complexType> </xs:element>
<xs:element name='subject'>
<xs:complexType>
<xs:simpleContent>
<xs:extension base='xs:string'>
<xs:attribute ref='xml:lang' use='optional'/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
</xs:element>
<xs:element name='subject'> <xs:complexType> <xs:simpleContent> <xs:extension base='xs:string'> <xs:attribute ref='xml:lang' use='optional'/> </xs:extension> </xs:simpleContent> </xs:complexType> </xs:element>
<xs:element name='thread' type='xs:NMTOKEN'/>
<xs:element name='thread' type='xs:NMTOKEN'/>
<xs:element name='presence'>
<xs:complexType>
<xs:element name='presence'> <xs:complexType>
Saint-Andre Standards Track [Page 98] RFC 3921 XMPP IM October 2004
Saint-Andre Standards Track [Page 98] RFC 3921 XMPP IM October 2004
<xs:sequence>
<xs:choice minOccurs='0' maxOccurs='unbounded'>
<xs:element ref='show'/>
<xs:element ref='status'/>
<xs:element ref='priority'/>
</xs:choice>
<xs:any namespace='##other'
minOccurs='0'
maxOccurs='unbounded'/>
<xs:element ref='error'
minOccurs='0'/>
</xs:sequence>
<xs:attribute name='from'
type='xs:string'
use='required'/>
<xs:attribute name='id'
type='xs:NMTOKEN'
use='optional'/>
<xs:attribute name='to'
type='xs:string'
use='required'/>
<xs:attribute name='type' use='optional'>
<xs:simpleType>
<xs:restriction base='xs:NCName'>
<xs:enumeration value='error'/>
<xs:enumeration value='probe'/>
<xs:enumeration value='subscribe'/>
<xs:enumeration value='subscribed'/>
<xs:enumeration value='unavailable'/>
<xs:enumeration value='unsubscribe'/>
<xs:enumeration value='unsubscribed'/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
<xs:attribute ref='xml:lang' use='optional'/>
</xs:complexType>
</xs:element>
<xs:sequence> <xs:choice minOccurs='0' maxOccurs='unbounded'> <xs:element ref='show'/> <xs:element ref='status'/> <xs:element ref='priority'/> </xs:choice> <xs:any namespace='##other' minOccurs='0' maxOccurs='unbounded'/> <xs:element ref='error' minOccurs='0'/> </xs:sequence> <xs:attribute name='from' type='xs:string' use='required'/> <xs:attribute name='id' type='xs:NMTOKEN' use='optional'/> <xs:attribute name='to' type='xs:string' use='required'/> <xs:attribute name='type' use='optional'> <xs:simpleType> <xs:restriction base='xs:NCName'> <xs:enumeration value='error'/> <xs:enumeration value='probe'/> <xs:enumeration value='subscribe'/> <xs:enumeration value='subscribed'/> <xs:enumeration value='unavailable'/> <xs:enumeration value='unsubscribe'/> <xs:enumeration value='unsubscribed'/> </xs:restriction> </xs:simpleType> </xs:attribute> <xs:attribute ref='xml:lang' use='optional'/> </xs:complexType> </xs:element>
<xs:element name='show'>
<xs:simpleType>
<xs:restriction base='xs:NCName'>
<xs:enumeration value='away'/>
<xs:enumeration value='chat'/>
<xs:enumeration value='dnd'/>
<xs:enumeration value='xa'/>
</xs:restriction>
</xs:simpleType>
</xs:element>
<xs:element name='show'> <xs:simpleType> <xs:restriction base='xs:NCName'> <xs:enumeration value='away'/> <xs:enumeration value='chat'/> <xs:enumeration value='dnd'/> <xs:enumeration value='xa'/> </xs:restriction> </xs:simpleType> </xs:element>
Saint-Andre Standards Track [Page 99] RFC 3921 XMPP IM October 2004
Saint-Andre Standards Track [Page 99] RFC 3921 XMPP IM October 2004
<xs:element name='status'>
<xs:complexType>
<xs:simpleContent>
<xs:extension base='xs:string'>
<xs:attribute ref='xml:lang' use='optional'/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
</xs:element>
<xs:element name='status'> <xs:complexType> <xs:simpleContent> <xs:extension base='xs:string'> <xs:attribute ref='xml:lang' use='optional'/> </xs:extension> </xs:simpleContent> </xs:complexType> </xs:element>
<xs:element name='priority' type='xs:byte'/>
<xs:element name='priority' type='xs:byte'/>
<xs:element name='iq'>
<xs:complexType>
<xs:sequence>
<xs:any namespace='##other'
minOccurs='0'/>
<xs:element ref='error'
minOccurs='0'/>
</xs:sequence>
<xs:attribute name='from'
type='xs:string'
use='required'/>
<xs:attribute name='id'
type='xs:NMTOKEN'
use='required'/>
<xs:attribute name='to'
type='xs:string'
use='required'/>
<xs:attribute name='type' use='required'>
<xs:simpleType>
<xs:restriction base='xs:NCName'>
<xs:enumeration value='error'/>
<xs:enumeration value='get'/>
<xs:enumeration value='result'/>
<xs:enumeration value='set'/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
<xs:attribute ref='xml:lang' use='optional'/>
</xs:complexType>
</xs:element>
<xs:element name='iq'> <xs:complexType> <xs:sequence> <xs:any namespace='##other' minOccurs='0'/> <xs:element ref='error' minOccurs='0'/> </xs:sequence> <xs:attribute name='from' type='xs:string' use='required'/> <xs:attribute name='id' type='xs:NMTOKEN' use='required'/> <xs:attribute name='to' type='xs:string' use='required'/> <xs:attribute name='type' use='required'> <xs:simpleType> <xs:restriction base='xs:NCName'> <xs:enumeration value='error'/> <xs:enumeration value='get'/> <xs:enumeration value='result'/> <xs:enumeration value='set'/> </xs:restriction> </xs:simpleType> </xs:attribute> <xs:attribute ref='xml:lang' use='optional'/> </xs:complexType> </xs:element>
<xs:element name='error'>
<xs:complexType>
<xs:sequence xmlns:err='urn:ietf:params:xml:ns:xmpp-stanzas'>
<xs:group ref='err:stanzaErrorGroup'/>
<xs:element ref='err:text'
<xs:element name='error'> <xs:complexType> <xs:sequence xmlns:err='urn:ietf:params:xml:ns:xmpp-stanzas'> <xs:group ref='err:stanzaErrorGroup'/> <xs:element ref='err:text'
Saint-Andre Standards Track [Page 100] RFC 3921 XMPP IM October 2004
Saint-Andre Standards Track [Page 100] RFC 3921 XMPP IM October 2004
minOccurs='0'/>
</xs:sequence>
<xs:attribute name='code' type='xs:byte' use='optional'/>
<xs:attribute name='type' use='required'>
<xs:simpleType>
<xs:restriction base='xs:NCName'>
<xs:enumeration value='auth'/>
<xs:enumeration value='cancel'/>
<xs:enumeration value='continue'/>
<xs:enumeration value='modify'/>
<xs:enumeration value='wait'/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
</xs:complexType>
</xs:element>
minOccurs='0'/> </xs:sequence> <xs:attribute name='code' type='xs:byte' use='optional'/> <xs:attribute name='type' use='required'> <xs:simpleType> <xs:restriction base='xs:NCName'> <xs:enumeration value='auth'/> <xs:enumeration value='cancel'/> <xs:enumeration value='continue'/> <xs:enumeration value='modify'/> <xs:enumeration value='wait'/> </xs:restriction> </xs:simpleType> </xs:attribute> </xs:complexType> </xs:element>
</xs:schema>
</xs:schema>
B.3 session
B.3 session
<?xml version='1.0' encoding='UTF-8'?>
<?xml version='1.0' encoding='UTF-8'?>
<xs:schema
xmlns:xs='http://www.w3.org/2001/XMLSchema'
targetNamespace='urn:ietf:params:xml:ns:xmpp-session'
xmlns='urn:ietf:params:xml:ns:xmpp-session'
elementFormDefault='qualified'>
<xs:schema xmlns:xs='http://www.w3.org/2001/XMLSchema' targetNamespace='urn:ietf:params:xml:ns:xmpp-session' xmlns='urn:ietf:params:xml:ns:xmpp-session' elementFormDefault='qualified'>
<xs:element name='session' type='empty'/>
<xs:element name='session' type='empty'/>
<xs:simpleType name='empty'>
<xs:restriction base='xs:string'>
<xs:enumeration value=''/>
</xs:restriction>
</xs:simpleType>
<xs:simpleType name='empty'> <xs:restriction base='xs:string'> <xs:enumeration value=''/> </xs:restriction> </xs:simpleType>
</xs:schema>
</xs:schema>
B.4 jabber:iq:privacy
B.4 jabber:iq:privacy
<?xml version='1.0' encoding='UTF-8'?>
<?xml version='1.0' encoding='UTF-8'?>
<xs:schema
xmlns:xs='http://www.w3.org/2001/XMLSchema'
targetNamespace='jabber:iq:privacy'
<xs:schema xmlns:xs='http://www.w3.org/2001/XMLSchema' targetNamespace='jabber:iq:privacy'
Saint-Andre Standards Track [Page 101] RFC 3921 XMPP IM October 2004
Saint-Andre Standards Track [Page 101] RFC 3921 XMPP IM October 2004
xmlns='jabber:iq:privacy'
elementFormDefault='qualified'>
xmlns='jabber:iq:privacy' elementFormDefault='qualified'>
<xs:element name='query'>
<xs:complexType>
<xs:sequence>
<xs:element ref='active'
minOccurs='0'/>
<xs:element ref='default'
minOccurs='0'/>
<xs:element ref='list'
minOccurs='0'
maxOccurs='unbounded'/>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name='query'> <xs:complexType> <xs:sequence> <xs:element ref='active' minOccurs='0'/> <xs:element ref='default' minOccurs='0'/> <xs:element ref='list' minOccurs='0' maxOccurs='unbounded'/> </xs:sequence> </xs:complexType> </xs:element>
<xs:element name='active'>
<xs:complexType>
<xs:simpleContent>
<xs:extension base='xs:NMTOKEN'>
<xs:attribute name='name'
type='xs:string'
use='optional'/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
</xs:element>
<xs:element name='active'> <xs:complexType> <xs:simpleContent> <xs:extension base='xs:NMTOKEN'> <xs:attribute name='name' type='xs:string' use='optional'/> </xs:extension> </xs:simpleContent> </xs:complexType> </xs:element>
<xs:element name='default'>
<xs:complexType>
<xs:simpleContent>
<xs:extension base='xs:NMTOKEN'>
<xs:attribute name='name'
type='xs:string'
use='optional'/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
</xs:element>
<xs:element name='default'> <xs:complexType> <xs:simpleContent> <xs:extension base='xs:NMTOKEN'> <xs:attribute name='name' type='xs:string' use='optional'/> </xs:extension> </xs:simpleContent> </xs:complexType> </xs:element>
<xs:element name='list'>
<xs:complexType>
<xs:sequence>
<xs:element ref='item'
minOccurs='0'
maxOccurs='unbounded'/>
</xs:sequence>
<xs:element name='list'> <xs:complexType> <xs:sequence> <xs:element ref='item' minOccurs='0' maxOccurs='unbounded'/> </xs:sequence>
Saint-Andre Standards Track [Page 102] RFC 3921 XMPP IM October 2004
Saint-Andre Standards Track [Page 102] RFC 3921 XMPP IM October 2004
<xs:attribute name='name'
type='xs:string'
use='required'/>
</xs:complexType>
</xs:element>
<xs:attribute name='name' type='xs:string' use='required'/> </xs:complexType> </xs:element>
<xs:element name='item'>
<xs:complexType>
<xs:sequence>
<xs:element name='iq'
minOccurs='0'
type='empty'/>
<xs:element name='message'
minOccurs='0'
type='empty'/>
<xs:element name='presence-in'
minOccurs='0'
type='empty'/>
<xs:element name='presence-out'
minOccurs='0'
type='empty'/>
</xs:sequence>
<xs:attribute name='action' use='required'>
<xs:simpleType>
<xs:restriction base='xs:NCName'>
<xs:enumeration value='allow'/>
<xs:enumeration value='deny'/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
<xs:attribute name='order'
type='xs:unsignedInt'
use='required'/>
<xs:attribute name='type' use='optional'>
<xs:simpleType>
<xs:restriction base='xs:NCName'>
<xs:enumeration value='group'/>
<xs:enumeration value='jid'/>
<xs:enumeration value='subscription'/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
<xs:attribute name='value'
type='xs:string'
use='optional'/>
</xs:complexType>
</xs:element>
<xs:element name='item'> <xs:complexType> <xs:sequence> <xs:element name='iq' minOccurs='0' type='empty'/> <xs:element name='message' minOccurs='0' type='empty'/> <xs:element name='presence-in' minOccurs='0' type='empty'/> <xs:element name='presence-out' minOccurs='0' type='empty'/> </xs:sequence> <xs:attribute name='action' use='required'> <xs:simpleType> <xs:restriction base='xs:NCName'> <xs:enumeration value='allow'/> <xs:enumeration value='deny'/> </xs:restriction> </xs:simpleType> </xs:attribute> <xs:attribute name='order' type='xs:unsignedInt' use='required'/> <xs:attribute name='type' use='optional'> <xs:simpleType> <xs:restriction base='xs:NCName'> <xs:enumeration value='group'/> <xs:enumeration value='jid'/> <xs:enumeration value='subscription'/> </xs:restriction> </xs:simpleType> </xs:attribute> <xs:attribute name='value' type='xs:string' use='optional'/> </xs:complexType> </xs:element>
Saint-Andre Standards Track [Page 103] RFC 3921 XMPP IM October 2004
Saint-Andre Standards Track [Page 103] RFC 3921 XMPP IM October 2004
<xs:simpleType name='empty'>
<xs:restriction base='xs:string'>
<xs:enumeration value=''/>
</xs:restriction>
</xs:simpleType>
<xs:simpleType name='empty'> <xs:restriction base='xs:string'> <xs:enumeration value=''/> </xs:restriction> </xs:simpleType>
</xs:schema>
</xs:schema>
B.5 jabber:iq:roster
B.5 jabber:iq:roster
<?xml version='1.0' encoding='UTF-8'?>
<?xml version='1.0' encoding='UTF-8'?>
<xs:schema
xmlns:xs='http://www.w3.org/2001/XMLSchema'
targetNamespace='jabber:iq:roster'
xmlns='jabber:iq:roster'
elementFormDefault='qualified'>
<xs:schema xmlns:xs='http://www.w3.org/2001/XMLSchema' targetNamespace='jabber:iq:roster' xmlns='jabber:iq:roster' elementFormDefault='qualified'>
<xs:element name='query'>
<xs:complexType>
<xs:sequence>
<xs:element ref='item'
minOccurs='0'
maxOccurs='unbounded'/>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name='query'> <xs:complexType> <xs:sequence> <xs:element ref='item' minOccurs='0' maxOccurs='unbounded'/> </xs:sequence> </xs:complexType> </xs:element>
<xs:element name='item'>
<xs:complexType>
<xs:sequence>
<xs:element ref='group'
minOccurs='0'
maxOccurs='unbounded'/>
</xs:sequence>
<xs:attribute name='ask' use='optional'>
<xs:simpleType>
<xs:restriction base='xs:NCName'>
<xs:enumeration value='subscribe'/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
<xs:attribute name='jid' type='xs:string' use='required'/>
<xs:attribute name='name' type='xs:string' use='optional'/>
<xs:attribute name='subscription' use='optional'>
<xs:simpleType>
<xs:restriction base='xs:NCName'>
<xs:element name='item'> <xs:complexType> <xs:sequence> <xs:element ref='group' minOccurs='0' maxOccurs='unbounded'/> </xs:sequence> <xs:attribute name='ask' use='optional'> <xs:simpleType> <xs:restriction base='xs:NCName'> <xs:enumeration value='subscribe'/> </xs:restriction> </xs:simpleType> </xs:attribute> <xs:attribute name='jid' type='xs:string' use='required'/> <xs:attribute name='name' type='xs:string' use='optional'/> <xs:attribute name='subscription' use='optional'> <xs:simpleType> <xs:restriction base='xs:NCName'>
Saint-Andre Standards Track [Page 104] RFC 3921 XMPP IM October 2004
Saint-Andre Standards Track [Page 104] RFC 3921 XMPP IM October 2004
<xs:enumeration value='both'/>
<xs:enumeration value='from'/>
<xs:enumeration value='none'/>
<xs:enumeration value='remove'/>
<xs:enumeration value='to'/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
</xs:complexType>
</xs:element>
<xs:enumeration value='both'/> <xs:enumeration value='from'/> <xs:enumeration value='none'/> <xs:enumeration value='remove'/> <xs:enumeration value='to'/> </xs:restriction> </xs:simpleType> </xs:attribute> </xs:complexType> </xs:element>
<xs:element name='group' type='xs:string'/>
<xs:element name='group' type='xs:string'/>
</xs:schema>
</xs:schema>
Appendix C. Differences Between Jabber IM/Presence Protocols and XMPP
Appendix C. Differences Between Jabber IM/Presence Protocols and XMPP
This section is non-normative.
This section is non-normative.
XMPP has been adapted from the protocols originally developed in the Jabber open-source community, which can be thought of as "XMPP 0.9". Because there exists a large installed base of Jabber implementations and deployments, it may be helpful to specify the key differences between the relevant Jabber protocols and XMPP in order to expedite and encourage upgrades of those implementations and deployments to XMPP. This section summarizes the differences that relate specifically to instant messaging and presence applications, while the corresponding section of [XMPP-CORE] summarizes the differences that relate to all XMPP applications.
XMPP has been adapted from the protocols originally developed in the Jabber open-source community, which can be thought of as "XMPP 0.9". Because there exists a large installed base of Jabber implementations and deployments, it may be helpful to specify the key differences between the relevant Jabber protocols and XMPP in order to expedite and encourage upgrades of those implementations and deployments to XMPP. This section summarizes the differences that relate specifically to instant messaging and presence applications, while the corresponding section of [XMPP-CORE] summarizes the differences that relate to all XMPP applications.
C.1 Session Establishment
C.1 Session Establishment
The client-to-server authentication protocol developed in the Jabber community assumed that every client is an IM client and therefore initiated an IM session upon successful authentication and resource binding, which are performed simultaneously (documentation of this protocol is contained in [JEP-0078], published by the Jabber Software Foundation [JSF]). XMPP maintains a stricter separation between core functionality and IM functionality; therefore, an IM session is not created until the client specifically requests one using the protocol defined under Session Establishment (Section 3).
The client-to-server authentication protocol developed in the Jabber community assumed that every client is an IM client and therefore initiated an IM session upon successful authentication and resource binding, which are performed simultaneously (documentation of this protocol is contained in [JEP-0078], published by the Jabber Software Foundation [JSF]). XMPP maintains a stricter separation between core functionality and IM functionality; therefore, an IM session is not created until the client specifically requests one using the protocol defined under Session Establishment (Section 3).
Saint-Andre Standards Track [Page 105] RFC 3921 XMPP IM October 2004
Saint-Andre Standards Track [Page 105] RFC 3921 XMPP IM October 2004
C.2 Privacy Lists
C.2 Privacy Lists
The Jabber community began to define a protocol for communications blocking (privacy lists) in late 2001, but that effort was deprecated once the XMPP Working Group was formed. Therefore the protocol defined under Blocking Communication (Section 10) is the only such protocol defined for use in the Jabber community.
The Jabber community began to define a protocol for communications blocking (privacy lists) in late 2001, but that effort was deprecated once the XMPP Working Group was formed. Therefore the protocol defined under Blocking Communication (Section 10) is the only such protocol defined for use in the Jabber community.
Contributors
Contributors
Most of the core aspects of the Extensible Messaging and Presence Protocol were developed originally within the Jabber open-source community in 1999. This community was founded by Jeremie Miller, who released source code for the initial version of the jabberd server in January 1999. Major early contributors to the base protocol also included Ryan Eatmon, Peter Millard, Thomas Muldowney, and Dave Smith. Work specific to instant messaging and presence by the XMPP Working Group has concentrated especially on IM session establishment and communication blocking (privacy lists); the session establishment protocol was mainly developed by Rob Norris and Joe Hildebrand, and the privacy lists protocol was originally contributed by Peter Millard.
Most of the core aspects of the Extensible Messaging and Presence Protocol were developed originally within the Jabber open-source community in 1999. This community was founded by Jeremie Miller, who released source code for the initial version of the jabberd server in January 1999. Major early contributors to the base protocol also included Ryan Eatmon, Peter Millard, Thomas Muldowney, and Dave Smith. Work specific to instant messaging and presence by the XMPP Working Group has concentrated especially on IM session establishment and communication blocking (privacy lists); the session establishment protocol was mainly developed by Rob Norris and Joe Hildebrand, and the privacy lists protocol was originally contributed by Peter Millard.
Acknowledgements
Acknowledgements
Thanks are due to a number of individuals in addition to the contributors listed. Although it is difficult to provide a complete list, the following individuals were particularly helpful in defining the protocols or in commenting on the specifications in this memo: Thomas Charron, Richard Dobson, Schuyler Heath, Jonathan Hogg, Craig Kaes, Jacek Konieczny, Lisa Dusseault, Alexey Melnikov, Keith Minkler, Julian Missig, Pete Resnick, Marshall Rose, Jean-Louis Seguineau, Alexey Shchepin, Iain Shigeoka, and David Waite. Thanks also to members of the XMPP Working Group and the IETF community for comments and feedback provided throughout the life of this memo.
Thanks are due to a number of individuals in addition to the contributors listed. Although it is difficult to provide a complete list, the following individuals were particularly helpful in defining the protocols or in commenting on the specifications in this memo: Thomas Charron, Richard Dobson, Schuyler Heath, Jonathan Hogg, Craig Kaes, Jacek Konieczny, Lisa Dusseault, Alexey Melnikov, Keith Minkler, Julian Missig, Pete Resnick, Marshall Rose, Jean-Louis Seguineau, Alexey Shchepin, Iain Shigeoka, and David Waite. Thanks also to members of the XMPP Working Group and the IETF community for comments and feedback provided throughout the life of this memo.
Author's Address
Author's Address
Peter Saint-Andre (editor) Jabber Software Foundation
Peter Saint-Andre (editor) Jabber Software Foundation
EMail: stpeter@jabber.org
EMail: stpeter@jabber.org
Saint-Andre Standards Track [Page 106] RFC 3921 XMPP IM October 2004
Saint-Andre Standards Track [Page 106] RFC 3921 XMPP IM October 2004
Full Copyright Statement
Full Copyright Statement
Copyright (C) The Internet Society (2004).
Copyright (C) The Internet Society (2004).
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/S HE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/S HE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
Intellectual Property
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the IETF's procedures with respect to rights in IETF Documents can be found in BCP 78 and BCP 79.
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the IETF's procedures with respect to rights in IETF Documents can be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf- ipr@ietf.org.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf- ipr@ietf.org.
Acknowledgement
Acknowledgement
Funding for the RFC Editor function is currently provided by the Internet Society.
Funding for the RFC Editor function is currently provided by the Internet Society.
Saint-Andre Standards Track [Page 107]
Saint-Andre Standards Track [Page 107]
一覧
スポンサーリンク
