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&#x010D;e&#x017D; 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'>&#x00DA;p&#x011B;nliv&#x011B; prosim!</subject>
     <body>Wherefore art thou, Romeo?</body>
     <body xml:lang='cz'>Pro&#x010D;e&#x017D; 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&#x0159;&#x00ED;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&#x0159;&#x00ED;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]

一覧

 RFC 1〜100  RFC 1401〜1500  RFC 2801〜2900  RFC 4201〜4300 
 RFC 101〜200  RFC 1501〜1600  RFC 2901〜3000  RFC 4301〜4400 
 RFC 201〜300  RFC 1601〜1700  RFC 3001〜3100  RFC 4401〜4500 
 RFC 301〜400  RFC 1701〜1800  RFC 3101〜3200  RFC 4501〜4600 
 RFC 401〜500  RFC 1801〜1900  RFC 3201〜3300  RFC 4601〜4700 
 RFC 501〜600  RFC 1901〜2000  RFC 3301〜3400  RFC 4701〜4800 
 RFC 601〜700  RFC 2001〜2100  RFC 3401〜3500  RFC 4801〜4900 
 RFC 701〜800  RFC 2101〜2200  RFC 3501〜3600  RFC 4901〜5000 
 RFC 801〜900  RFC 2201〜2300  RFC 3601〜3700  RFC 5001〜5100 
 RFC 901〜1000  RFC 2301〜2400  RFC 3701〜3800  RFC 5101〜5200 
 RFC 1001〜1100  RFC 2401〜2500  RFC 3801〜3900  RFC 5201〜5300 
 RFC 1101〜1200  RFC 2501〜2600  RFC 3901〜4000  RFC 5301〜5400 
 RFC 1201〜1300  RFC 2601〜2700  RFC 4001〜4100  RFC 5401〜5500 
 RFC 1301〜1400  RFC 2701〜2800  RFC 4101〜4200 

スポンサーリンク

起動時に『UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY.』と出た場合の修復方法

ホームページ製作・web系アプリ系の製作案件募集中です。

上に戻る