Jabber/XMPP中文翻译计划 - 用户贡献 [zh-cn]

RFC3921

2010-06-04T04:03:38Z

Fantasysoft: /* 会话的建立 */

[[Category:XMPP正式RFC标准]]
[[Category:已翻译]]

本文的英文原文来自[http://www.ietf.org/rfc/rfc3921.txt RFC 3921]

{|
|网络工作组 || Saint-Andre, Ed.
|-
|申请讨论: 3921 || Jabber软件基金会
|-
|类别: 标准跟踪 || 2004年10月
|}

::::'''可扩展的消息和出席信息协议 (XMPP): 即时消息和出席信息'''

'''关于本文的说明'''

:本文为互联网社区定义了一个互联网标准跟踪协议，并且申请讨论协议和提出了改进的建议。请参照“互联网官方协议标准”的最新版本（STD 1）获得这个协议的标准化进程和状态。本文可以不受限制的分发。

'''版权声明'''

:本文版权属于互联网社区 (C) The Internet Society (2004).

'''摘要'''

:本文定义了可扩展消息和出席信息协议（XMPP）的核心功能的扩展和应用，XMPP提供了RFC 2779 定义的基本的即时消息和出席信息功能。

==绪论==

===概览===

:XMPP是一个流化XML[XML]元素的协议，用于准实时的交换消息和出席信息。XMPP的核心功能定义在Extensible Messaging and Presence Protocol (XMPP): Core [XMPP-CORE|XMPP文档列表/XMPP正式RFC标准/RFC3920]. 这些功能 -- 主要是 XML流, 使用 TLS和SASL,以及流的根元素之下的<message/>, <presence/>, 和 <iq/> 子元素 -- 为各种类型的准实时应用提供了一个构造基础, 它可以被放在核心的顶层，使用特定XML名字空间[XML-NAMES]发送特定的应用数据. 本文描述XMPP核心功能的扩展和应用，XMPP核心功能提供了RFC 2779 [IMP-REQS]定义的基本的即时消息和出席信息功能。

===需求===

:为了达到本文的目的, 基本的即时消息和出席信息应用的需求定义在[IMP-REQS],它是一个高阶的规定,一个用户必须完成以下用例:

:*和其他用户交换消息
:*和其他用户交换出席信息
:*管理和其他用户之间的订阅和被订阅
:*管理联系人列表中的条目(在 XMPP 中这被称为 "roster")
:*屏蔽和特定的其他用户之间的通信（出或入）

:这些功能领域的详细定义在[IMP-REQS]中, 感兴趣的用户可以直接阅读原文关于需求方面的内容。

:[IMP-REQS]也规定出席信息服务必须从即时消息服务中分离; 例如, 它必须可能用这个协议来提供一个出席信息服务,一个即时消息服务,或同时提供两者. 尽管本文假定实现和部署希望提供统一的即时消息和出席信息服务, 但没有要求一个服务必须同时提供出席信息服务和即时消息服务, 并且协议也提供了把出席信息服务和即时消息服务分离成为独立服务的可能性.

:注意: 虽然基于XMPP的即时消息和出席信息符合[IMP-REQS]的要求,但它不是特意为那个协议设计的,因为基础协议是在RFC 2779成文之前通过Jabber开放源代码社区的一个开放的开发过程发展出来的. 也请注意尽管在Jabber社区发展的协议中定义了许多其他方面的功能,但是这些协议不包含在本文之中,因为它们不是[IMP-REQS]所要求的.

===术语===

:本文继承了 [XMPP-CORE|XMPP文档列表/XMPP正式RFC标准/RFC3920]定义的术语.

:大写关键字 "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 和 "OPTIONAL" 在本文中的含义定义在 BCP 14, RFC 2119 \[TERMS\].

==XML 节的语法==

:符合'jabber:client'和'jabber:server'名字空间的XML节的基本语义和通用属性已经在[XMPP-CORE|XMPP文档列表/XMPP正式RFC标准/RFC3920]中定义了. 无论如何, 这些名字空间也定义了一些其他的子元素, 比如通用属性'type'的值, 对于即时消息和出席信息应用就是特殊的. 因而, 在选择用于这类应用的特定用例之前, 我们在这里需要先描述一下XML节的语法, 用来补充[XMPP-CORE|XMPP文档列表/XMPP正式RFC标准/RFC3920]中的讨论.

===消息语法===

:符合'jabber:client' or 'jabber:server'名字空间的消息节用于"推" 信息到另一个实体. 在即时消息应用中通常的用法是包含，一个单独的消息,在一个聊天会话中的消息，一个多用户聊天室的上下文中的消息，标题或其他警告和错误的消息,

====消息的类型====

:一个消息节的'type' 属性是建议的(RECOMMENDED); 如果包含了它,它指明这个消息的会话上下文,从而提供一个关于表达的线索(例如, 在一个GUI中). 如果包含了它, 'type' 属性必须(MUST)是以下的值之一 :

:*chat -- 消息是在一对一聊天会话的语境被发送. 一个兼容的客户端应该(SHOULD)在一个允许两个实体进行一对一聊天的界面中显示消息,包括适当的会话历史.

:*error -- 发生了一个和上次发送者发送的消息有关的错误(关于节错误语法的详细信息, 参考 [XMPP-CORE|XMPP文档列表/XMPP正式RFC标准/RFC3920]). 一个兼容客户端应该(SHOULD)在一个适当的界面展示它以通知发送者这个错误的种类.

:*groupchat -- 消息是在一个多用户聊天环境的语境下发送的(类似\[IRC\]). 一个兼容客户端应该(SHOULD)在允许多对多聊天的界面显示这个消息,包括, 包括这个聊天室的名册和适当的会话历史. 基于XMPP的群聊协议的完整定义超出了本文的范围.

:*headline -- 一个消息可能是由一个递送或广播内容的自动化服务生成的(新闻, 体育, 市场信息, RSS feeds, 等等.). 这个消息是不需要回复的, 一个兼容客户端应该(SHOULD) 在一个适当的和单独消息,聊天会话,或群聊会话不同的界面显示这个消息(例如, 不给接收者提供回复能力).

:*normal -- 这个消息是一个在一对一会话或群聊会话之外的单独消息, 并且它希望接收者能够回复.一个兼容客户端应该(SHOULD)在一个允许接收者回复的界面显示这个消息, 但不需要会话历史.

:一个 IM 应用应该(SHOULD)支持所有前述的消息类型;如果一个应用接收了一个没有'type'属性的消息或这个应用不理解'type'属性的值, 它必须(MUST)认为这个消息是一个 "normal" 类型(如,"normal" 是缺省的). "error"类型必须(MUST)仅仅在应答一个和从别的实体接收到的消息有关的错误时生成.

:尽管'type'属性是可选的(OPTIONAL), 处于礼貌原因对于消息的任何回复总是和原来的消息同一类型;此外, 一些特殊的应用(例如, 一个多用户聊天服务) 可以(MAY)根据它们的判断强制特定消息类型的使用(例如, type='groupchat').

====子元素====

:正如扩展名字空间extended namespaces(第二章第四节)所述, 一个消息节可以(MAY)包含任何适当名字空间的子元素.

:和缺省名字空间声明一致, 缺省消息节的名字空间是'jabber:client' 或 'jabber:server', 定义了某几个允许的消息节的子元素. 如果消息节的类型是 "error", 它必须(MUST)包含一个<error/>子元素; 详细情况, 见[XMPP-CORE|XMPP文档列表/XMPP正式RFC标准/RFC3920]. 否则, 消息节可以(MAY)包含以下子元素的任何一种并且无需显式地声明名字空间:

:#<subject/>
:#<body/>
:#<thread/>

=====主题=====

:<subject/> 元素包含了人类可读的 XML 字符数据指明这个消息的主题. <subject/>元素不能(MUST NOT)拥有任何属性, 除了'xml:lang'属性. <subject/> 元素可以(MAY)包含多个实例用于为同一主题提供备用版本, 但是仅在每个实例的拥有的'xml:lang'属性的值互不相同的时候才可以. <subject/> 元素不能(MUST NOT)包含混合的内容(定义在 \[XML\]第三章第二节第二小节).

=====主体=====

:<body/> 元素包含人类可读的XML字符数据表达消息的文本内容; 这个子元素通常会有但是是可选的(OPTIONAL). <body/>元素不能(MUST NOT)拥有任何属性, 除非是'xml:lang'属性. <body/> 元素可以(MAY)包含多个实例用于为同一主体提供备用版本, 但是仅在每个实例的拥有的'xml:lang'属性的值互不相同的时候才可以. <body/>元素不能(MUST NOT)包含混合的内容(定义在 \[XML\]第三章第二节第二小节).

=====线索=====

:<thread/> 元素包含非人类可读的XML字符数据表达一个标识符用于跟踪两个实体之间的一个会话线索(有时相当于一个"即时消息会话"). <thread/>元素的值是由发送者生成的并且应该(SHOULD)在任何回复中拷贝回来. 如果使用了它, 它必须(MUST)在这个流的会话线索中是唯一的并且必须(MUST)和那个会话相一致(一个从同一个全JID但不同线索ID接收到消息的客户端必须(MUST)假定这个有问题的消息存在于已有的会话线索之外. <thread/>元素的使用是可选的(OPTIONAL)并且不是用于标识独立的消息,而是标识会话. 一个消息节不能(MUST NOT)包含超过一个的<thread/>元素. <thread/>元素不能(MUST NOT)拥有任何属性. <thread/>属性的值必须(MUST)被实体处理成不透明的; 不能从它得到任何语义学上的含义,并且只能对它做精确的比较. <thread/>元素不能(MUST NOT)包含混合内容(定义在 [XML]第三章第二节第二小节).

===出席信息语法===

:符合'jabber:client' 或 'jabber:server'名字空间的出席信息节用于表达一个实体当前的网络可用性(离线或在线, 包括之后的各种亚状态和可选的用户名义的描述性文本), 并且通知其他实体它的可用性. 出席信息节也用于协商和管理对于其他实体的出席信息的订阅.

====出席信息的类型====

:出席信息节的'type'属性是可选的(OPTIONAL). 一个不拥有任何'type'属性的出席信息节用来通知服务器发送者已经在线并且可以进行通信了, 'type' 属性表示缺乏可用性, 请求管理对其他实体的出席信息的订阅, 请求其他实体的当前出席信息, 或发生了和上次发出的出席信息节有关的错误. 如果包含了它, 'type'属性必须(MUST)拥有以下值之一:

:*unavailable -- 通知实体将不可通信.

:*subscribe -- 发送者希望订阅接收者的出席信息.

:*subscribed -- 发送者允许接收者接收他们的出席信息.

:*unsubscribe -- 发送者取消订阅另一个实体的出席信息.

:*unsubscribed -- 订阅者的请求被拒绝或以前的订阅被取消.

:*probe -- 对一个实体当前的出席信息的请求; 只应(SHOULD)由服务器代替一个用户生成.

:*error -- 处理或递送之前发送的出席信息节的时候发生了错误.

:关于出席信息语义学的详细信息和基于XMPP的即时消息和出席信息应用程序的订阅模式,参考交换出席信息Exchanging Presence Information(第五章) 和管理订阅Managing Subscriptions(第六章).

====子元素====

:如扩展名字空间extended namespaces(第二章第四节)所述, 一个出席信息节可以(MAY)包含任何适当名字空间的子元素.

:和缺省名字空间声明一致, 缺省出席信息节的名字空间是'jabber:client' 或 'jabber:server', 定义了某几个允许的出席信息节的子元素. 如果出席信息节的类型是 "error", 它必须(MUST)包含一个<error/>子元素; 详细情况, 见[XMPP-CORE|XMPP文档列表/XMPP正式RFC标准/RFC3920]. 如果出席信息节不拥有'type'属性,它可以(MAY)包含以下任何子元素(注意<status/>子元素可以(MAY)在一个类型为"unavailable"或"subscribe"(出于历史原因)的出席信息中被发送):

:#<show/>
:#<status/>
:#<priority/>

=====展示=====

:可选的(OPTIONAL)<show/>元素包含非人类可读的XML字符数据表达一个特定的实体或资源的特定的可用性状态. 一个出席信息节不能(MUST NOT)包含多于一个<show/>元素. <show/>元素不能(MUST NOT)拥有任何属性. 如果提供了, 这个XML字符数据值必须(MUST)是以下之一(额外的可用性类型可以通过出席信息的适当名字空间来定义):

:*away -- 实体或资源临时离开.

:*chat -- 实体或资源在聊天中是激活的.

:*dnd -- 实体或资源是忙(dnd = "不要打扰").

:*xa -- 实体或资源是长时间的离开(xa = "长时间离开").

:如果没有提供<show/>元素, 实体被假定是在线和可用的.

=====状态=====

:可选的(OPTIONAL)<status/>元素包含XML字符数据表达一个可用性状态的自然语言描述. 它通常用于联合show元素以提供可用性状态的详细描述(例如, "会议中"). <status/>元素不能(MUST NOT)拥有任何属性,除了'xml:lang'属性. <status/>元素可以(MAY)包含多个实例但是每个实例的'xml:lang'属性值必须各不相同.

=====优先权=====

:可选的(OPTIONAL)<priority/>元素包含非人类可读的XML字符数据指明资源的优先级别. 这个值必须(MUST)是一个介于-128和+127之间的数字. 一个出席信息小节不能(MUST NOT)包含超过一个的<priority/>元素. <priority/>元素不能(MUST NOT)拥有任何属性. 如果没有优先权被提供,一个服务器应该(SHOULD)认为优先级是零. 关于即时消息和出席信息系统中节路由的优先级的语义, 参考处理XML节的服务器规则Server Rules for Handling XML Stanzas(第十一章).

===IQ语法===

:IQ节提供一个结构化的请求-应答机制. 这个机制的基本语义学(例如, 'id'属性是必需的(REQUIRED))定义在[XMPP-CORE|XMPP文档列表/XMPP正式RFC标准/RFC3920], 然而完成特定用例所需要的特定语义的所有案例定义在扩展名字空间extended namespace(第二章第四节)之中(注意'jabber:client'和'jabber:server'名字空间没有定义除通用的<error/>子元素之外的任何IQ节子元素). 本文定义了两个这样的名字空间,一个用于名册管理Roster Management(第七章)而另一个用于屏蔽通信Blocking Communication(第十章); 无论如何, 一个IQ节可以(MAY)包含符合任何扩展名字空间的结构化信息.

===扩展名字空间===

:因为在"jabber:client"或"jabber:server"名字空间中定义的三个XML节类型(也包括它们的属性和子元素)提供了一个基本功能级用于消息和出席信息, XMPP使用XML名字空间来扩展节用于提供额外的功能, 所以一个消息或出席信息节可以(MAY)包含一个或更多可选的子元素表达扩展消息含义的内容(例如, 一个XHTML格式版本的消息主体), 并且一个IQ节可以(MAY)包含一个这样的子元素. 这个子元素可以(MAY)有任何名字并且可以(MUST)拥有一个'xmlns'名字空间声明(不同于"jabber:client", "jabber:server", 或"http://etherx.jabber.org/streams")定义所有包含在子元素中的数据.

:对于任何特定的扩展名字空间的支持在任何实现中的一部分是可选的(OPTIONAL)(除了在这里定义的扩展名字空间以外). 如果一个实体不理解这样一个名字空间, 实体被期望的行为依赖于这个实体是(1) 接收者或 (2) 一个正在路由到接收者的实体

:接收者: 如果一个接收者接收了一个包含不理解的子元素的节, 它应该(SHOULD)忽略那个特定的XML数据,例如, 它应该(SHOULD)不处理它或不向用户或相关的应用程序(如果有的话)显示它. 具体来说:

::*如果一个实体接收了一个消息或出席信息节包含一个不理解的名字空间, 在节的未知名字空间的这部分应该(SHOULD)被忽略.

::*如果一个实体接收了一个消息节中仅有的一个子元素是不理解的, 它必须(MUST)忽略整个节.

::*如果一个实体接收了一个类型"get"或"set"的IQ节包含一个不理解的子元素, 这个实体应该(SHOULD)返回一个类型为"error"的<service-unavailable/>错误条件的IQ节.

:路由: 如果一个路由实体(通常是一个服务器)处理一个包含它不理解的子元素的节, 它应该(SHOULD)原封不动地把它转给接收者而忽略相关的XML数据.

==会话的建立==

:绝大部分基于XMPP的消息和出席信息应用是由一个客户端-服务器体系结构实现的,为了参加期望的即时消息和出席信息活动,需要客户端在服务器上建立一个会话. 无论如何, 在客户端能够建立一个即时消息和出席信息会话之前有很多前提必须(MUST)满足. 它们是:

:#流验证 -- 客户端在尝试建立一个会话或发送任何XML节之前必须(MUST)完成[XMPP-CORE|XMPP文档列表/XMPP正式RFC标准/RFC3920]中定义的流验证.
:#资源绑定 -- 完成流验证之后, 一个客户端必须(MUST)绑定一个资源到流上,使得客户端的地址符合<user@domain/resource>格式, 然后实体以[XMPP-CORE|XMPP文档列表/XMPP正式RFC标准/RFC3920]规定的术语来说就是一个已连接的资源"connected resource".

:如果一个服务器支持会话, 在完成一个[XMPP-CORE|XMPP文档列表/XMPP正式RFC标准/RFC3920]定义的流验证之后它必须(MUST)在它向客户端声明的流特性中包含一个符合'urn:ietf:params:xml:ns:xmpp-session'名字空间的<session/>元素:

:服务器向客户端声明会话确定特性:

<source lang="xml">
<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>
</source>

:收到需要会话确立的通知之后(并且是在完成资源绑定之后), 客户端如果想使用即时消息和出席信息功能必须(MUST)建立一个会话; 它向服务器发送一个符合'urn:ietf:params:xml:ns:xmpp-session'名字空间的类型为"set"并包含空的<session/>子元素的IQ节以完成这一步骤:

:步骤 1: 客户端向服务器请求会话:

<source lang="xml">
<iq to='example.com'
type='set'
id='sess_1'>
<session xmlns='urn:ietf:params:xml:ns:xmpp-session'/>
</iq>
</source>

:步骤 2: 服务器通知客户端会话已经建立:

<source lang="xml">
<iq from='example.com'
type='result'
id='sess_1'/>
</source>

:建立会话之后, 一个已连接的资源([XMPP-CORE|XMPP文档列表/XMPP正式RFC标准/RFC3920]术语)就被称为一个激活的资源"active resource".

:许多错误条件是可能的. 例如, 服务器可能遭遇一个内部条件阻碍了它建立会话, 用户名或授权身份可能缺乏建立会话的许可, 或同一个名字相关的这个资源ID已经有一个激活的资源.

:如果服务器遭到一个内部条件阻碍了它建立会话, 它必须(MUST)返回一个错误.

:步骤 2 (替代): 服务器应答一个错误(内部服务器错误):

<source lang="xml">
<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>
</source>

:如果用户名或资源不被允许建立一个会话, 服务器必须(MUST)返回一个错误(例如, 被禁止).

:步骤 2 (替代): 服务器应答错误(用户名或资源不被允许建立一个会话):

<source lang="xml">
<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>
</source>

:如果同一名字已经存在一个激活的资源,服务器必须(MUST) (1) 终止这个激活的资源并允许新请求的会话, 或者 (2) 不允许新申请的会话并继续激活的资源. 服务器做哪一步取决于具体的实现, 尽管建议的(RECOMMENDED)实现情景 #1. 在情景 #1, 服务器应该(SHOULD)发送一个<conflict/>流错误给激活的资源, 终止用于这个激活的资源的XML流和相关的TCP连接, 并返回一个类型为"result" 的IQ节(表示成功)给新申请的会话. 在情景 #2, 服务器应该(SHOULD)发送一个<conflict/>节错误给新申请的会话但是继续那个连接的XML流使得新申请的会话在发送另一个会话建立申请之前有机会协商出一个不冲突的资源ID.

:步骤 2 (替代): 服务器通知现有的激活的资源资源冲突(情景 #1):

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

:步骤 2 (替代): 服务器通知新申请的的会话资源冲突(情景 #2):

<source lang="xml">
<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>
</source>

:建立一个会话之后, 客户端应该(SHOULD)按以下描述来发送初始化出席信息并请求它的名册, 尽管这些动作是可选的(OPTIONAL).

:注意: 在允许建立即时消息和出席信息会话之前, 一个服务器可能(MAY)需要先提供帐号. 可能的提供帐号的方法包括由服务器管理员新建帐号以及使用'jabber:iq:register'名字空间进行带内帐号注册; 后一个方法超出了本文的范围, 但是记录在\[JEP-0077\]（译者注：这个协议已改名为 XEP-0077）, 由 Jabber Software Foundation \[JSF\]发行（译者注：这个组织也已改名为XSF）.

==交换消息==

:交换消息是XMPP的一个基本用途并且随之而来的是一个用户生成一个发给另一个实体的消息节. 正如用于处理XML节的服务器规则Server Rules for Handling XML Stanzas(第十一章)中所定义的 , 发送者的服务器负责递送消息给预定的接收者(如果接收者在同一个服务器上)或路由消息给接收者的服务器(如果接收者在不同的服务器上).

:关于消息节的语法和它们已定义的属性和子元素信息, 参考消息语法Message Syntax(第二章第一节).

===指明一个预定的接收者===

:一个即时消息客户端应该(SHOULD)通过提供一个JID或<message/>节中不同于发送者的'to'属性来指定一个消息的预定接收者. 如果这个消息是在回复之前接收到的消息,而接收到的消息是从JID格式为<user@domain/resource>(例如,在一个聊天会话的上下文中)实体发来的, 这个回复消息的'to'地址的值应该(SHOULD)是<user@domain/resource>而不是<user@domain>,除非发送者知道(通过出席信息)预定的接收者的资源将不再可用. 如果消息是在任何现存的聊天会话或接收到的消息之外被发送的,'to'地址的值应该(SHOULD)格式为<user@domain>而不是<user@domain/resource>.

===指定一个消息类型===

:大家知道, 对于一个消息节来说拥有'type'属性(它的值代表了消息的会话上下文(参见 Type(第二章第一节第一小节)))是建议的(RECOMMENDED).

:以下例子展示一个'type'属性的合法值:

:例子: 一个已定义类型的消息:

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

===指定一个消息主体===

:一个消息节可以(MAY)(并且经常会)包含一个<body/>子元素,它的XML字符数据表达消息的主要含义(见 Body(第二章第一节第二小节第二小小节)).

:例子: 一个带主体的消息:

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

===指定一个消息主题===

:一个消息节可以(MAY)包含一个或多个<subject/>子元素指明消息的主题(见 Subject(第二章第一节第二小节第一小小节)).

:例子: 一个带主题的消息:

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

===指定一个会话线索===

:一个消息可以(MAY)包含一个<thread/>子元素指定消息处于哪个会话线索, 用于跟踪会话(见 Thread(第二章第一节第二小节第三小小节)).

:例子: 一个带线索的会话:

<source lang="xml">
<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>
<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>
<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>
</source>

==交换出席信息==

:交换出席信息通过使用出席信息节直接和XMPP相关. 无论如何, 我们看到在这里和消息处理形成一个对比:尽管一个客户端可以(MAY)通过包含一个'to'地址直接给另一个实体发送出席信息, 通常出席信息通知(例如,不包含'type'的或类型为"unavailable"的并且没有'to'地址的出席信息节) 被客户端发送给它的服务器然后由服务器广播给任何订阅了发送实体的出席信息的实体(在 RFC 2778 \[IMP-MODEL\]术语中, 这些实体称为订阅者). 这个广播模式不适用于和订阅相关的节或类型为"error"的出席信息, 而仅适用于以上定义的出席信息通知. (注意: 虽然出席信息可以(MAY)由一个自动化服务代替用户提供, 通常它还是由用户的客户端提供.)

:关于出席信息节的语法以及它们的已定义的属性和子元素的信息, 参考[XMPP-CORE|XMPP文档列表/XMPP正式RFC标准/RFC3920].

===客户端和服务器出席信息职责===

====初始化出席信息====

:建立起一个会话之后, 一个客户端应该(SHOULD)发送初始化出席信息给服务器来通知它的通信可用性.如这里定义的, 初始化出席信息节 (1) 必须(MUST) 不拥有'to'地址(这表示它是由服务器代替客户端发送的广播) 并且 (2) 必须(MUST) 不拥有'type'属性(者表示拥护的可用性). 在发送初始化出席信息之后, 一个激活的资源被称为可用的资源"available resource".

:从一个客户端接收到初始化出席信息之后, 如果这个用户没有一个或更多的已存在的可用资源(如果这个用户已经有一个或更多可用的资源, 服务器明显不需要发送出席信息探测, 因为它已经拥有需要的信息),用户的服务器必须(MUST)做以下的步骤:

:#从用户的全JID(例如,<user@example.com/resource>)发送出席信息探针(例如, 'type'属性值为'probe'的出席信息节)给已被这个用户订阅了的所有联系人以确定它们是否可用; 这些联系人就是那些显示在用户的名册中的JID并且'subscription'属性值为"to"或"both"(注意: 用户的服务器不能(MUST NOT)发送出席信息探针给用户已经屏蔽入站出席信息通知的联系人, 具体的描述在屏蔽入站出席信息通知Blocking Inbound Presence Notifications(第十章第十节).)
:#从用户的全JID (e.g.,<user@example.com/resource>)广播初始化出席信息给所有订阅了该用户的出席信息的联系人; 这些联系人就是那些显示在用户的名册中的JID并且'subscription'属性值为"from"或"both"(注意: 用户的服务器不能(MUST NOT)发送出席信息探针给用户已经屏蔽出站出席信息通知的联系人, 具体的描述在屏蔽出站出席信息通知Blocking Outbound Presence Notifications(第十章第十一节).)

:另外, 用户的服务器必须(MUST)从用户的新的可用的资源向用户任何现存的可用的资源(如果有的话)广播初始化出席信息.

:从用户接收到初始化出席信息之后, 联系人的服务器必须(MUST)递送这个用户的出席信息节给所有联系人的可用资源相应的全JID(<contact@example.org/resource>), 但是仅适用于用户在联系人名册中并且订阅状态为"to"或"both"并且联系人的纯JID或全JID没有被屏蔽入站出席信息通知(定义在屏蔽入站出席信息通知Blocking Inbound Presence Notifications(第十章第十节)).

:如果用户的服务器接收到一个类型为"error"的出席信息节,而这个节是用来回复服务器代替用户向联系人发送的初始化出席信息, 它不应该(SHOULD NOT)发送更多的出席信息更新给那个联系人(直到并且除非它从这个联系人接收到一个出席信息节).

====出席信息广播====

:发送初始化出席信息之后, 用户可以(MAY)在任何时候更新它的出席信息,方法是在会话期间发送一个没有'to'地址也没有'type'属性的出席信息节或'type'属性值为"unavailable"的出席信息节.(注意:一个用户的客户端不应该(SHOULD NOT)发送一个出席信息更新来自行广播用户出席信息和可用性的改变信息.)

:如果出席信息节缺乏'type'属性(例如, 表达可用性), 用户的服务器必须(MUST)广播那个出席信息节的全XML给所有联系人(满足以下三点) (1) 它们在用户的联系人名册中并且订阅类型是"from"或"both", (2) 用户对于这些联系人没有屏蔽出站出席信息通知, 并且 (3) 服务器在用户的会话期间没有从它们那里接收到出席信息错误(同样适用于这个用户的其他可用的资源).

:如果出席信息节的'type'属性值是"unavailable", 用户的服务器必须(MUST)广播那个出席信息节的全XML给所有符合以上描述的实体, 也适用于用户曾经在会话过程中直接发送了可用出席信息的任何实体(如果用户还没来得及直接发送不可用出席信息给那个实体).

====出席信息调查====

:从用户接收到一个出席信息调查之后, 联系人的服务器应该(SHOULD)应答如下:

:#如果用户联系人的名册中的状态不是 "From", "From + Pending Out", 或 "Both" (定义在订阅状态Subscription States(第九章)), 联系人的服务器必须(MUST)返回一个类型为"error"的出席信息节应答这个出席信息调查 (无论如何, 如果一个服务器从这个服务器的主机名的子域或其他信任的服务接收到一个出席信息调查, 它可以(MAY)提供这个用户的出席信息给那个实体). 具体来说:
:##如果用户在联系人的名册中的订阅状态是 "None", "None + Pending Out", 或 "To" (或根本不在联系人的名册中), 联系人的服务器必须(MUST)返回一个<forbidden/>节错误应答这个出席信息调查.
:##如果用户在联系人的名册中的订阅状态是 "None + Pending In", "None + Pending Out/In", 或 "To + Pending In", 联系人的服务器必须(MUST)返回一个<not-authorized/>节错误应答这个出席信息调查.
:#其次, 如果联系人对这个用户的纯JID或全JID屏蔽了出席信息通知(使用缺省列表或激活列表,定义在屏蔽出站出席信息通知Blocking Outbound Presence Notifications (第十章第十一节)), 服务器不能(MUST NOT)应答这个出席信息调查.
:#然后, 如果联系人没有可用的资源, 服务器必须(MUST) 要么 (1) 应答这个出席信息调查, 向这个用户发送服务器从联系人接收到的最后的类型为"unavailable"的出席信息节的全XML, 或 (2) 不应答.
:#最后, 如果联系人至少有一个可用的资源, 服务器必须(MUST)应答这个出席信息调查, 向这个用户发送服务器从联系人的每一个可用的资源收到的最后的没有'to'属性的出席信息节的全XML (再一次的,对于每一个会话都要强制服从隐私列表).

====直接出席信息====

:一个用户可以(MAY)直接发送出席信息给另一个实体 (例如, 一个出席信息节,包含'to'属性并且值为另一个实体的JID并且没有'type'属性或'type'属性值为"unavailable"). 可能出现三种情形:

:#如果用户在已经发送过初始化出席信息广播之后,发送不可用信息广播之前,直接发送出席信息给它的名册中一个订阅状态为"from" 或 "both"的联系人, 这个用户的服务器必须(MUST)路由或递送这个出席信息节的全XML(服从隐私列表)但是不应该(SHOULD NOT) 根据出席信息广播修改联系人的状态(例如, 它应该(SHOULD)在任何接下来的由用户初始化的出席信息广播包含这个联系人的JID).
:#如果用户在已经发送过初始化出席信息广播之后,发送不可用信息广播之前,直接发送出席信息给一个不在用户名册中的实体并且其订阅状态为"from" 或 "both", 这个用户的服务器必须(MUST)路由或递送这个出席信息节的全XML(服从隐私列表)但是不能(MUST NOT) 根据可用性的出席信息广播来修改这个联系人的状态(例如, 它不能(MUST NOT)在任何接下来的由用户初始化的可用性的出席信息广播中包含这个联系人的JID); 无论如何, 如果无法从用户的可用的资源直接发送出席信息, 用户的服务器必须( MUST)广播不可用出席信息给那个实体(如果这个用户还没有直接发送不可用出席信息给那个实体).
:#如果用户不是在已经发送过初始化出席信息广播之后,或在发送不可用信息广播之前,直接发送出席信息(例如, 资源激活了但是还不可用), 用户的服务器必须(MUST)认为用户向其直接发送出席信息的这个实体视为上述第二种情形中的那个实体,采用相同的处理方式.

====不可用出席信息====

:在和一个服务器结束它的会话之前, 客户端应该(SHOULD)雅致地成为不可用的,发送一个最后的没有'to'属性并且'type'属性值为"unavailable"的出席信息节(可选的, 最后的出席信息节可以(MAY)包含一个或多个<status/>元素以指明为什么用户不再可用). 无论如何, 用户的服务器不能(MUST NOT)依赖于从一个可用的资源接收最后的出席信息, 因为资源可能意外的变成不可用或可能被服务器判定超时. 如果用户的资源之一因为任何原因成为不可用的(包括雅致的或粗鲁的), 用户的服务器必须(MUST)广播不可用出席信息给所有如下的联系人 (1) 在用户的名册中并且订阅类型为 "from" 或 "both", (2) 用户没有对它们屏蔽出站出席信息的联系人, 以及 (3) 用户会话期间,服务器没有从它们那里收到出席信息错误的联系人; 用户的服务器也必须(MUST)发送不可用出席信息节给这个用户的任何其他可用的资源, 以及任何用户的资源曾经在会话期间直接向其发送过出席信息的实体(如果用户还没有直接发送不可用出席信息给那个实体). 在直接发送或广播不可用出席信息之后发送的任何没有'type'属性也没有'to'属性的出席信息节必须(MUST)由服务器广播给所有订阅者.

====出席信息订阅====

:一个订阅请求就是一个'type'属性值为"subscribe"的出席信息节. 如果订阅请求被发送给一个即时消息联系人, 在'to'属性中提供的JID的格式应该(SHOULD)是<contact@example.org>而不是<contact@example.org/resource>, 因为用户期望的结果通常是从联系人的所有资源接收到出席信息, 而不仅是'to'属性中的特定资源.

:一个用户的服务器不能(MUST NOT)代替用户自动批准订阅请求. 所有订阅申请必须(MUST)直接发给用户的客户端, 具体来说就是这一用户的一个或多个可用的资源. 如果当订阅申请被用户的服务器接收到的时候没有这个用户的可用资源, 用户的服务器必须(MUST)保持这个订阅申请的记录并且在用户下次建立一个可用的资源时递送这个订阅申请, 直到这个用户批准或拒绝这个请求. 如果如果当订阅申请被用户的服务器接收到的时候这个用户有多于一个的可用资源, 用户的服务器必须(MUST)广播这个订阅申请给所有可用的资源(根据处理XML节的服务器规则Server Rules for Handling XML Stanzas(第十一章)). (注意: 如果一个激活的资源还没有提供初始化出席信息, 服务器不能(MUST NOT)认为它是可用的并且因而不能(MUST NOT)发送订阅申请给它.) 无论如何, 如果用户从一个它已授权可以看到用户的出席信息的联系人那里收到一个类型为"subscribe"的出席信息节(例如, 当一个联系人重新同步订阅状态的时候),用户的服务器应该(SHOULD)代替用户自动应答. 另外, 用户的服务器可以(MAY)基于一个特定实现的法则(例如, 无论何时当用户的一个新的资源可用的时候, 或在一段特定长度的时间过去之后)选择重新发送一个未批准的未决订阅申请给这个联系人; 这有助于恢复可能和原始订阅申请有关的瞬间的,无声的错误.

===指明可用性状态===

:一个客户端可以(MAY)使用<show/>元素提供关于可用性状态的更多信息(参见 Show (第二章第二节第二小节第一小小节)).

:例子: 可用性状态:
<source lang="xml">
<presence>

<show>dnd</show>

</presence>
</source>

===指明详细的可用性状态信息===

:通过联合<show/>元素, 客户端使用<status/>元素可以(MAY)提供详细的可用性状态信息(参见Status (第二章第二节第二小节第二小小节)).

:例子: 详细的状态信息:

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

===指明出席信息优先级===

:客户端可以(MAY)使用<priority/>元素为它的资源提供优先级(参见 Priority (第二章第二节第二小节第三小小节)).

:例子: 出席信息优先级:

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

===出席信息例子===

:本章的例子用于阐明上述和出席信息相关的协议. 用户是 romeo@example.net, 他有一个可用的资源, 资源ID为 "orchard", 并且他的名册中有以下这些人:

:*juliet@example.com (subscription="both" 并且她有两个可用的资源, 一个资源名为"chamber" 而另一个资源名为 "balcony")

:*benvolio@example.org (subscription="to")

:*mercutio@example.org (subscription="from")

:例子 1: 用户发送初始化出席信息:

<source lang="xml">
<presence/>
</source>

:例子 2: 用户的服务器代替用户发送出席信息调查给 subscription="to" 和 subscription="both" 的联系人的可用资源:

<source lang="xml">
<presence
type='probe'
from='romeo@example.net/orchard'
to='juliet@example.com'/>
<presence
type='probe'
from='romeo@example.net/orchard'
to='benvolio@example.org'/>
</source>

:例子 3: 用户的服务器代替用户发送初始化出席信息给 subscription="from" 和 subscription="both"的联系人的可用资源:

<source lang="xml">
<presence
from='romeo@example.net/orchard'
to='juliet@example.com'/>
<presence
from='romeo@example.net/orchard'
to='mercutio@example.org'/>
</source>

:例子 4: 联系人的服务器代替所有可用的资源应答出席信息调查:

<source lang="xml">
<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>
<presence
from='juliet@example.com/chamber'
to='romeo@example.net/orchard'>
<priority>1</priority>
</presence>
<presence
from='benvolio@example.org/pda'
to='romeo@example.net/orchard'
xml:lang='en'>
<show>dnd</show>
<status>gallivanting</status>
</presence>
</source>

:例子 5: 联系人的服务器递送用户的初始化出席信息给所有可用的资源或返回错误给用户:

<source lang="xml">
<presence
from='romeo@example.net/orchard'
to='juliet@example.com/chamber'/>
<presence
from='romeo@example.net/orchard'
to='juliet@example.com/balcony'/>
<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>
</source>

:例子 6: 用户直接发送出席信息给另一个不在他的名册中的用户:

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

:例子 7: 用户发送更新的可用出席信息用于广播:

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

:例子 8: 用户的服务器仅向一个联系人广播更新的出席信息 (不是那些返回错误的联系人,也不是那些用户直接向其发送出席信息的联系人):

<source lang="xml">
<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>
</source>

:例子 9: 联系人的服务器递送更新的出席信息给联系人所有可用的资源:

<source lang="xml">
[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>
[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>
</source>

:例子 10: 联系人的资源之一广播最后出席信息:

<source lang="xml">
<presence from='juliet@example.com/balcony' type='unavailable'/>
</source>

:例子 11: 联系人的服务器发送不可用出席信息给用户:

<source lang="xml">
<presence
type='unavailable'
from='juliet@example.com/balcony'
to='romeo@example.net/orchard'/>
</source>

:例子 12: 用户发送最后出席信息:

<source lang="xml">
<presence from='romeo@example.net/orchard'
type='unavailable'
xml:lang='en'>
<status>gone home</status>
</presence>
</source>

:例子 13: 用户的服务器广播不可用出席信息给联系人,包括用户直接向其发送出席信息的那个人:

<source lang="xml">
<presence
type='unavailable'
from='romeo@example.net/orchard'
to='juliet@example.com'
xml:lang='en'>
<status>gone home</status>
</presence>
<presence
from='romeo@example.net/orchard'
to='nurse@example.com'
xml:lang='en'>
<status>gone home</status>
</presence>
</source>

==管理订阅==

:为了保护即时消息用户和任何其他实体的隐私, 出席信息和可用性信息仅向用户已批准的其他实体披露. 当一个用户同意其他用户可以看到它的出席信息, 这个实体被称为对于用户的出席信息有一个订阅. 订阅超越了会话; 实际上, 它一直存在直到订阅者取消订阅或被订阅者取消曾经授权的订阅为止. 在XMPP中订阅是通过发送包含特定属性的出席信息节来管理的.

:注意: 在订阅和名册之间有重要的交互; 这些定义在名册条目和出席信息订阅的集成Integration of Roster Items and Presence Subscriptions (第八章), 而且读者必须参考那一章才能完整地理解出席信息订阅.

===请求一个订阅===

:对另一个实体的出席信息的订阅请求是由发送一个类型为"subscribe"的出席信息节来开始的.

:例子: 发送一个订阅请求:

<source lang="xml">
<presence to='juliet@example.com' type='subscribe'/>
</source>

:关于客户端和服务器在订阅请求中的职责, 参考出席信息订阅Presence Subscriptions(第五章第一节第六小节).

===处理一个订阅请求===

:当一个客户端从另一个实体接收到一个订阅请求, 它必须(MUST)批准这个请求(发送一个类型为"subscribed"的出席信息节)或拒绝这个请求(发送一个类型为"unsubscribed"的出席信息节).

:例子: 批准一个订阅请求:

<source lang="xml">
<presence to='romeo@example.net' type='subscribed'/>
</source>

:例子: 拒绝一个出席信息订阅的请求:

<source lang="xml">
<presence to='romeo@example.net' type='unsubscribed'/>
</source>

===从另一个实体取消一个订阅===

:如果一个用户想取消一个曾经允许的订阅请求, 它发送一个类型为"unsubscribed"的出席信息节.

:例子: 取消一个曾经允许的订阅请求:

<source lang="xml">
<presence to='romeo@example.net' type='unsubscribed'/>
</source>

===取消对于另一个实体的出席信息的订阅===

:如果用户想取消对于另一个实体的出席信息的订阅, 它发送一个类型为"unsubscribe"的出席信息节.

:例子: 取消对一个实体的出席信息的订阅:

<source lang="xml">
<presence to='juliet@example.com' type='unsubscribe'/>
</source>

==名册管理==

:在XMPP中, 一个人的联系人列表被称为名册(roster), 它包括任意数量的特定名册条目, 每个名册条目被一个唯一的JID(通常格式是<contact@domain>)所标识. 一个用户的名册由用户的服务器代替用户储存从而这个用户可以从任何资源访问名册信息.

:注意: 在名册和订阅之间有重要的交互; 这些定义在名册条目和出席信息订阅的集成Integration of Roster Items and Presence Subscriptions (第八章), 而且读者必须参考那一章才能完整地理解名册管理.

===语法和语义===

:名册使用IQ节来管理, 具体来说就是符合'jabber:iq:roster'名字空间的<query/>子元素的含义.这个<query/>元素可以(MAY)包含一个或更多<item/>子元素, 每个描述一个唯一的名册条目或曰联系人"contact".

:每个名册条目的"key"或者说唯一标识符就是一个JID,封装在<item/>元素的'jid'属性(它是必需的(REQUIRED))之中. 如果这个条目是和另一个(人类)即时消息用户相关的,'jid'属性的值的格式应该(SHOULD)是<user@domain>.

:和一个名册条目相关的出席信息订阅的状态从<item/>元素的'subscription'属性可以得到.这个属性允许的值包括:

:* "none" -- 这个用户没有对这个联系人出席信息的订阅, 这个联系人也没有订阅用户的出席信息

:* "to" -- 这个用户订阅了这个联系人的出席信息, 但是这个联系人没有订阅用户的出席信息

:* "from" -- 这个联系人订阅了用户的出席信息, 但是这个用户没有订阅这个联系人的出席信息

:* "both" -- 用户和联系人互相订阅了对方的出席信息

:每个<item/>条目可以(MAY)包含一个'name'属性, 它设置和这个JID相关的"nickname", 取决于用户(而不是联系人). 'name'属性的值是不透明的.

:每个<item/>条目可以(MAY)包含一个或多个<group/>子元素,用于把名册条目收集到多个类别之中. <group/>子元素的XML字符数据是不透明的.

===商业规则===

:在一个名册"set"中一个服务器必须(MUST)忽略任何'to'地址, 并且必须(MUST)认为任何名册"set"是应用于发送者的. 为了更多的安全性, 一个客户端应该(SHOULD)检查"roster push"(包含一个名册条目的类型为"set"的输入IQ)的"from"地址以保证它来自一个信任的源; 具体的, 这个节必须(MUST)没有 'from'属性(例如, 从服务器隐含的) 或'from'属性的值匹配用户的纯JID(格式为<user@domain>)或全JID(格式为<user@domain/resource>); 否则, 客户端应该(SHOULD)忽略这个"roster push".

===登录时接收一个人的名册===

:在连接到服务器并成为一个激活的资源之后, 一个客户端应该(SHOULD)在发送初始化出席信息之前请求名册(无论如何, 因为可能不是所有的资源都想接收名册, 例如, 一个带宽受限的连接, 客户端对于名册的请求是可选的(OPTIONAL)). 如果一个可用的资源在一个会话期间没有请求名册, 服务器不能(MUST NOT)向它发送出席信息订阅以及相关的名册更新.

:例子: 客户端向服务器请求当前的名册:

<source lang="xml">
<iq from='juliet@example.com/balcony' type='get' id='roster_1'>
<query xmlns='jabber:iq:roster'/>
</iq>
</source>

:例子: 客户端从服务器收到名册:

<source lang="xml">
<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>
</source>

===增加一个名册条目===

:任何时候, 一个用户可以(MAY)增加一个条目到他或她的名册.

:例子: 客户端添加一个新的条目:

<source lang="xml">
<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>
</source>

:服务器必须(MUST)在持久信息存储机构中更新名册信息,并且也要向这个用户的所有已请求名册的可用资源推送这一改变. 这个"名册推送"包括一个类型为"set"的IQ节,从服务器发送给客户端,使用户的所有可用资源保持和基于服务器的名册信息的同步.

:例子: 服务器 (1) 推送更新的名册信息给所有已请求名册的可用资源并且 (2) 以一个IO结果应答发送的资源:

<source lang="xml">
<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>
</item>
</query>
</iq>
<iq to='juliet@example.com/balcony' type='result' id='roster_2'/>
</source>

:正如IQ节类型(定义在[XMPP-CORE|XMPP文档列表/XMPP正式RFC标准/RFC3920])的语义所要求的,每个接收到了名册推送的资源必须(MUST)应答一个类型为"result"(或 "error")的IQ节.

:例子: 资源应答一个IQ结果给服务器:

<source lang="xml">
<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'/>
</source>

===更新名册条目===

:更新一个已有的名册条目(例如, 改变组) 的方法和增加一个新的名册条目是一样的, 换言之, 在IQ set 节中发送名册条目给服务器.

:例子: 用户更新名册条目(增加组):

<source lang="xml">
<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>
</source>

:正如增加一个名册条目, 当更新一个名册条目时服务器必须(MUST)在持久信息存储机构中更新名册信息, 并且也要初始化一个名册推送给这个用户的所有已请求名册的可用资源.

===删除一个名册条目===

:任何时候, 用户可以(MAY)从他或她的名册中删除一个条目,只要发送一个 IQ set 给服务器并确保其'subscription'属性值为"remove" (如果从一个客户端接收到'subscription'属性的任何其他值,一个兼容的服务器必须(MUST)忽略它).

:例子: 客户端移除一个条目:

<source lang="xml">
<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>
</source>

:和增加一个名册条目一样, 删除一个名册条目的时候服务器必须(MUST)在持久信息存储机构中更新名册信息,初始化一个名册推送给这个用户的所有已请求名册的可用资源(伴随着把'subscription'属性值设为"remove"),并且发送一个 IQ result 给初始化资源.

:关于这个命令的含义的更多信息, 见移除一个名册条目并取消所有订阅Removing a Roster Item and Cancelling All Subscriptions (第八章第六节).

==名册条目和出席信息订阅的集成==

===概览===

:关于用户从或向别的联系人订阅出席信息,一个即时消息用户通常希望在名册条目和出席信息订阅之间有某些层次的集成. 本章描述了在XMPP即时消息应用中必须(MUST)支持的那些层次的集成.

:有四种主要的订阅状态:

:* None -- 这个用户没有对这个联系人出席信息的订阅, 这个联系人也没有订阅用户的出席信息

:* To -- 这个用户订阅了这个联系人的出席信息, 但是这个联系人没有订阅用户的出席信息

:* From -- 这个联系人订阅了用户的出席信息, 但是这个用户没有订阅这个联系人的出席信息

:* Both -- 用户和联系人互相订阅了对方的出席信息(例如, 联合'from' 和 'to')

:这些状态的每一个都被反射到用户和联系人双方的名册中, 从而导致持久的订阅状态.

:在以下的子章节中将叙述这些订阅状态如何为了完成特定的已定义的用例而进行交互. 关于服务器和客户端处理所有订阅状态的细节 (包括处于以上所列的状态之外的未决状态)在订阅状态Subscription States(第九章).

:服务器不能(MUST NOT)发送出席信息订阅请求或名册推送给不可用的资源, 也不能给没有已请求的名册的可用资源.

:在名册推送中'from'和'to'地址是可选的(OPTIONAL); 如果包含了, 它们的值应该(SHOULD)是那个会话的资源的全JID. 一个客户端必须(MUST)以一个类型为"result"的IQ节来承认每个名册推送(为了暂时的原因, 这些节不显示在以下的例子中但是按[XMPP-CORE|XMPP文档列表/XMPP正式RFC标准/RFC3920]定义的IQ语义学的规定它们是必需的).

===用户向联系人订阅===

:以下描述一个用户向一个联系人订阅的过程, 包括名册条目和订阅状态之间的互动.

:1. 为了能够在用户的客户端界面处理联系人以及在服务器跟踪订阅, 用户的客户端应该(SHOULD)为新的名册条目执行一个"roster set". 这个请求包括发送一个类型为'set'的IQ节并拥有符合'jabber:iq:roster'名字空间的<query/>子元素, 它(<query/>元素)再包含一个<item/>子元素来定义新的名册条目; 这个<item/>元素必须(MUST)拥有一个'jid'属性, 可以(MAY)拥有一个'name'属性, 不能(MUST NOT)拥有一个'subscription'属性, 并且可以(MAY)包含一个或多个<group/>子元素:

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

:2. 作为结果, 这个用户的服务器 (1) 必须(MUST)为这个新的名册条目初始化一个名册推送给这个用户的所有已经请求名册的可用资源, 其'subscription'属性的值为 "none"; 并且 (2) 必须(MUST)以一个 IQ result 应答发送的资源表明名册设置成功了:

<source lang="xml">
<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'/>
</source>

:3. 如果用户想向这个联系人请求出席信息的订阅, 用户的客户端必须(MUST)发送一个类型为'subscribe'的出席信息节给联系人:

<source lang="xml">
<presence to='contact@example.org' type='subscribe'/>
</source>

:4. 作为结果, 用户的服务器必须(MUST)初始化第二个名册推送给这个用户的所有已经请求名册的可用资源,把这个联系人设置成'none'订阅状态的未决子状态; 这个未决子状态是由名册条目中包含的ask='subscribe'属性所指示的:

<source lang="xml">
<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>
</source>

:注意: 如果用户在发送订阅请求之前没有新建一个名册条目, 服务器必须(MUST)现在代替用户新建一个,然后发送一个名册推送给这个用户的所有已经请求名册的可用资源, 不含以上所示的'name'属性和<group/>子元素.

:5. 用户的服务器也必须(MUST)把这个类型为"subscribe"的出席信息节的'from'地址设置为用户的纯JID(例如, <user@example.com>)(如果用户提供了设置为用户的全JID的'from'地址, 服务器应该(SHOULD)移除资源ID). 如果联系人和用户在不同的主机上, 用户的服务器必须(MUST)路由这个出席信息节到联系人的服务器来递送到这个联系人(这种情形的假定贯穿本文; 无论如何, 如果联系人在同一台主机, 那么服务器可以简单地直接递送出席信息节):

<source lang="xml">
<presence
from='user@example.com'
to='contact@example.org'
type='subscribe'/>
</source>

:注意:如果用户的服务器从联系人的服务器收到了一个类型为"error"的出席信息节, 它必须(MUST)这个错误节给用户, 用户的客户端可以(MAY)确定那个错误是否对于上次用户发出的"subscribe"类型的出席信息节(例如, 通过跟踪'id'属性)的应答,然后选择重新发送"subscribe"请求还是发送一个"unsubscribe"类型的出席信息节给联系人以恢复到它的上一个状态.

:6. 接收到指向联系人的"subscribe"类型的出席信息节之后, 这个联系人的服务器必须(MUST)决定是否至少有一个已请求名册的联系人的可用资源. 如果是, 它必须(MUST)递送这个订阅请求给这个联系人(如果不是, 联系人的服务器必须(MUST)离线存储这个订阅请求用于递送 when this condition is next met; 通常这是通过增加一个关于这个联系人的名册条目到用户名册中来实现的, 伴随着一个 "None + Pending In"的状态(定义在订阅状态Subscription States (第九章)), 无论如何一个服务器不应该(SHOULD NOT)在那种状态下推送或递送名册条目给联系人). 不论何时订阅请求被递送到了, 联系人必须决定是否批准它(根据联系人的配置选项, 联系人的客户端可以(MAY）批准或拒绝订阅请求而无需向联系人显示). 这里我们假定这个 "happy path", 即联系人批准了订阅请求(替代的拒绝订阅请求的流程定义在第八章第二节第一小节). 在这种情形下, 这个联系人的客户端 (1) 应该(SHOULD) 执行一个roster set 为这个用户指明期望的昵称和组(如果有的话); 并且 (2) 必须(MUST)发送一个"subscribed"类型的出席信息节给这个用户以批准这个订阅请求.

<source lang="xml">
<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'/>
</source>

:7. 作为结果, 联系人的服务器 (1) 必须(MUST) 初始化一个名册推送给所有联系人已请求名册的可用资源, 包含一个关于那个用户的名册条目,并且其订阅状态为'from'(甚至联系人不执行roster set,服务器也必须(MUST)发送它); (2) 必须(MUST)返回一个 IQ result 给发送的资源表示名册设置(roster set)成功了; (3) 必须(MUST)路由这个"subscribed"类型的出席信息节给用户, 首先把'from'地址设为联系人的纯JID(<contact@example.org>); 然后 (4) 必须(MUST)从所有联系人的可用资源向用户发送可用的出席信息:

<source lang="xml">
<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'/>
<presence
from='contact@example.org'
to='user@example.com'
type='subscribed'/>
<presence
from='contact@example.org/resource'
to='user@example.com'/>
</source>

:注意: 如果联系人的服务器从用户的服务器收到一个"error"类型的出席信息节, 它必须(MUST)递送这个错误节给联系人, 联系人的客户端可以(MAY)确定那个错误是否对于上次联系人发出的"subscribe"类型的出席信息节(例如, 通过跟踪'id'属性)的应答,然后选择重新发送"subscribe"请求还是发送一个"unsubscribe"类型的出席信息节给用户以恢复到它的上一个状态.

:8. 接收到一个指向用户的"subscribed"类型的出席信息节之后, 用户的服务器必须(MUST)首先检查在用户名册中的这个联系人的状态是: (a) subscription='none' and ask='subscribe' 还是 (b) subscription='from' and ask='subscribe'. 如果联系人不是以上述的状态在用户的名册中,用户的服务器必须(MUST)安静的忽略这个"subscribed"类型的出席信息节(例如, 服务器不能(MUST NOT)路由它到用户, 修改用户的名册, 或生成一个名册推送到用户的可用资源). 如果联系人以上述任何一种状态存在于用户的名册中, 用户的服务器 (1) 必须(MUST)从联系人向用户递送这个"subscribed"类型的出席信息节; (2)必须(MUST)初始化一个名册推送给所有已请求名册的这个用户的可用资源,包含一个关于这个联系人的更新的名册条目,同时其'subscription'属性值设置为"to"; 并且 (3) 必须(MUST)从每一个联系人的可用资源向每一个用户的可用资源递送服务器接收到的可用的出席信息节:

<source lang="xml">
<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>
<presence
from='contact@example.org/resource'
to='user@example.com/resource'/>
</source>

:9. 接收到"subscribed"类型的出席信息节之后, 用户应该(SHOULD)承认接收到了订阅状态通知,
要么发送一个"subscribe"类型的出席信息节给联系人证实它, 要么发送一个"unsubscribe"类型的出席信息节给联系人否认它;这个步骤不一定影响订阅状态(见订阅状态Subscription States(第九章)的细节), 但是会让用户用户的服务器知道它必须(MUST)不再发送订阅状态改变通知给用户(见第九章第四节).

:从用户这方面看, 现在存在一个向联系人的出席信息的订阅; 从联系人的方面看, 现在存在一个从用户的来的订阅.

====替代流程: 联系人拒绝订阅请求====

:以上活动流程展示了关于用户向联系人的订阅请求的 "happy path" . 如果联系人拒绝用户的订阅请求,那么主要的替代流程如下所述.

:1. 如果联系人想拒绝这个请求, 联系人的客户端必须(MUST)发送一个"unsubscribed"类型的出席信息节给用户(取代第八章第二节中步骤6发送的 "subscribed"类型的出席信息节):

<source lang="xml">
<presence to='user@example.com' type='unsubscribed'/>
</source>

:2. 作为结果, 联系人的服务器必须(MUST)路由这个"unsubscribed"类型的出席信息节给用户,首先把'from'地址设为联系人的纯JID(<contact@example.org>):

<source lang="xml">
<presence
from='contact@example.org'
to='user@example.com'
type='unsubscribed'/>
</source>

:注意: 如果联系人的服务器之前把用户添加到了联系人的名册中用来跟踪, 这时它必须(MUST)移除这个相关的条目.

:3. 接收到指向用户的"unsubscribed"类型出席信息节之后, 用户的服务器 (1) 必须(MUST)地送那个出席信息节给用户并且 (2) 必须(MUST) 初始化一个名册推送给这个用户的所有已请求名册的可用资源, 包含一个关于这个联系人的一个更新条目,其'subscription'属性设为"none"并且没有'ask'属性:

<source lang="xml">
<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>
</source>

:4. 接收到类型为"unsubscribed"出席信息节之后, 用户应该(SHOULD)承认收到订阅状态通知, 要么发送一个"unsubscribe"类型的出席信息节给联系人证实它, 要么发送一个"subscribe"类型的出席信息节给联系人否认它; 这一步骤不影响订阅状态(见订阅状态Subscription States(第九章)的细节), 但是让用户的服务器知道它必须(MUST)不再发送订阅状态改变的通知给用户(见第九章第四节).

:作为这一行为的结果, 联系人现在在用户的名册中, 状态为"none",而用户根本不在联系人的名册中.

===建立一个相互的订阅===

:用户和联系人可以在前述"happy path"的基础上建立一个相互的订阅(例如, 一个"both"的订阅类型). 流程如下.

:1. 如果联系人想建立一个相互的订阅, 联系人必须(MUST)发送一个订阅请求给用户(视联系人的配置选项而定, 联系人的客户端可以(MAY)自动发送它):

<source lang="xml">
<presence to='user@example.com' type='subscribe'/>
</source>

:2. 作为结果, 联系人的服务器 (1) 必须(MUST)初始化一个名册推送给联系人的所有已请求名册的可用资源, 伴随着用户仍在'from'订阅状态但同时有一个未决的'to'订阅状态(通过在名册条目中包含一个ask='subscribe'的属性来指示); 并且 (2) 必须(MUST)路由这个"subscribe"类型的出席信息节给用户(先把'from'地址设为联系人的纯JID(<contact@example.org>)):

<source lang="xml">
<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>
<presence
from='contact@example.org'
to='user@example.com'
type='subscribe'/>
</source>

:注意: 如果联系人的服务器从用户的服务器收到一个"error"类型的出席信息节, 它必须(MUST)递送这个错误节给联系人, 它的客户端可以(MAY)确定这个错误是用来应答上次发送的"subscribe"类型的出席信息节(换言之, 通过跟踪'id'属性) 并且选择重发这个"subscribe"请求还是发送一个"unsubscribe"类型的出席信息节给用户以把名册恢复到它的前一个状态.

:3. 接收到指向用户的"subscribe"类型出席信息节之后, 用户的服务器必须确定是否至少有一个已请求名册可用资源. 如果是, 用户的服务器必须(MUST)递送这个订阅请求给用户(如果不是, 它必须(MUST)离线存储这个订阅请求等这种情形再次发生时递送). 无论何时订阅请求被递送了, 用户必须决定是否批准它(视用户的配置选项而定, 用户的客户端可以(MAY)批准或拒绝这个订阅请求而不需要向用户显示). 这里我们假定这是"happy path",用户批准了订阅请求(替代的拒绝订阅请求的流程定义在第八章第三节第一小节). 在这种情形下, 用户的客户端必须(MUST)发送一个"subscribed"类型的出席信息节给联系人表示批准了订阅请求.

<source lang="xml">
<presence to='contact@example.org' type='subscribed'/>
</source>

:4. 作为结果, 用户的服务器 (1) 必须(MUST)初始化一个名册推送给用户的所有已请求名册的可用资源, 包含一个关于联系人的名册条目,其'subscription'属性设为"both"; (2) 必须(MUST)路由这个"subscribed"类型的出席信息节给联系人(先把'from'地址设为用户的纯JID<user@example.com>)); 并且 (3) 必须(MUST)向联系人发送它从用户的每个可用资源收到的最近一次出席信息节的全XML(不带'to'属性)(强制每个会话遵守隐私列表):

<source lang="xml">
<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/resource'
to='contact@example.org'/>
</source>

:注意: 如果用户的服务器从联系人的服务器接收到一个"error"类型的出席信息节, 它必须(MUST)递送这个错误节给用户, 它客户端可以(MAY)确定这个错误是用来应答上次发出去的"subscribed"类型的出席信息节(换言之, 通过跟踪'id'属性) 并且选择重发这个订阅请求还是发送一个"unsubscribed"类型的出席信息节给联系人以把名册恢复到上次的状态.

:5. 接收到指向联系人的"subscribed"类型的出席信息节之后, 联系人的服务器必须(MUST)首先检查用户在联系人的名册中的状态是否以下状态之一: (a) subscription='none' and ask='subscribe' 或 (b) subscription='from' and ask='subscribe'. 如果用户不是以上述两种状态之一存在于联系人的名册中, 联系人的服务器必须(MUST)安静地忽略这个"subscribed"类型的出席信息节(例如, 它不能(MUST NOT)路由它给联系人, 修改联系人的名册, 或生成一个名册推送给联系人的可用资源). 如果用户以上述两种状态之一存在于联系人的名册中, 联系人的服务器 (1) 必须(MUST)从用户向联系人递送这个"subscribed"类型的出席信息节; (2) 必须(MUST)初始化一个名册推送给这个联系人的所有已请求名册的可用资源, 包含一个关于这个用户的更新的名册条目,其'subscription'属性值设为"both"; 并且 (3) 必须(MUST)向这个联系人的每个可用资源递送它从这个用户的每个资源收到的可用出席信息节:

<source lang="xml">
<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>
<presence
from='user@example.com/resource'
to='contact@example.org/resource'/>
</source>

:6. 收到"subscribed"类型的出席信息节之后, 联系人应该(SHOULD)承认收到订阅请求通知,要么发送一个"subscribe"的出席信息节给用户证实它,要么发送一个"unsubscribe"类型的出席信息节给用户否认它; 这一步骤不影响订阅状态(细节见订阅状态Subscription States(第九章)), 但是让联系人的服务器知道它必须(MUST)不再发送订阅状态变更通知给联系人(见第九章第四节).

:用户和联系人现在有了对双方的出席信息的一个相互订阅 \-\- 换言之, 这个订阅类型为 "both".

====替代流程: 用户拒绝订阅请求====

:以上活动流程展示了关于联系人对用户的订阅请求的 "happy path". 如果用户拒绝了联系人的订阅请求,其主要流程如下.

:1. 如果用户想拒绝请求, 用户的客户端必须(MUST)发送一个"unsubscribed"类型的出席信息节给联系人(替代第八章第三节中的第三步中所发送的"subscribed"类型出席信息节):

<source lang="xml">
<presence to='contact@example.org' type='unsubscribed'/>
</source>

:2. 作为结果, 用户的服务器必须(MUST)路由这个"unsubscribed"类型的出席信息节给联系人(首先把'from'地址设为用户的纯JID(<user@example.com>)):

<source lang="xml">
<presence
from='user@example.com'
to='contact@example.org'
type='unsubscribed'/>
</source>

:3. 接收到指向联系人的"unsubscribed"类型的出席信息节之后, 联系人的服务器 (1) 必须(MUST)递送这个出席信息节给联系人; 并且 (2) 必须(MUST)初始化一个名册推送给这个联系人的所有已请求名册的可用资源, 包含关于这个用户的更新的名册条目,其'subscription'属性的值设为"from"并且没有'ask'属性:

<source lang="xml">
<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>
</source>

:4. 接收到"unsubscribed"类型的出席信息节之后, 联系人应该(SHOULD)承认收到那个订阅状态通知,要么向用户发送一个"unsubscribe"类型的出席信息节以证实它,要么向用户发送一个"subscribe"类型的出席信息以否认它; 这个步骤不会影响订阅状态(详见订阅状态Subscription States(第九章)),但是让联系人的服务器知道它必须(MUST)不再发送订阅状态变更通知给联系人(见第九章第四节).

:作为这一活动的结果, 订阅状态没有任何改变; 换言之, 联系人在用户的名册中的订阅状态为"to"并且用户在联系人的名册中的订阅状态为"from".

===取消订阅===

:在订阅了一个联系人的出席信息之后的任何时候, 一个用户可以(MAY)取消订阅. 在所有实例中用户发送来执行这一动作的XML是相同的, 接下来的订阅状态根据发出取消订阅命令时获得的订阅状态的情况而不同. 两种可能的情节描述如下.

====情形 #1: 当订阅不是相互的时候取消订阅====

:在第一种情形, 用户有一个向联系人的出席信息的订阅但是联系人没有对用户的出席信息的订阅（换言之, 订阅不是相互的).

:1. 如果用户想取消对联系人的出席信息的订阅, 用户必须(MUST)发送一个"unsubscribe"类型的出席信息节给联系人:

<source lang="xml">
<presence to='contact@example.org' type='unsubscribe'/>
</source>

:2. 作为一个结果, 用户的服务器 (1) 必须(MUST) 发送一个名册推送给这个用户的所有已请求名册的可用资源,包含一个关于这个联系人的更新名册条目,其'subscription'属性设为"none"; 并且 (2) 必须(MUST)路由这个"unsubscribe"类型的出席信息节给联系人(首先把'from'地址设为用户的纯JID(<user@example.com>)):

<source lang="xml">
<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'/>
</source>

:3. 接收到指向联系人的"unsubscribe"类型出席信息节之后, 联系人的服务器 (1) 必须(MUST)初始化一个名册推送给这个联系人的所有已请求名册的可用资源, 包含一个关于这个用户的名册条目,其'subscription'属性值设为"none" (如果联系人不可用或未曾请求名册, 联系人的服务器必须(MUST)修改名册条目并在下次联系人请求名册时发送那个已修改的条目); 并且 (2) 必须(MUST)递送这个"unsubscribe"状态改变通知给联系人:

<source lang="xml">
<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'/>
</source>

:4. 接收到"unsubscribe"类型的出席信息节之后, 联系人应该(SHOULD)承认收到那个订阅状态通知,要么发送一个"unsubscribed"类型的出席信息节给用户以证实它,要么发送一个"subscribed"类型的出席信息节给用户否认它; 这个步骤不影响订阅状态(详见订阅状态Subscription States (第九章)), 但是让联系人的服务器知道它必须(MUST)不再发送订阅状态变更通知给联系人(见第九章第四节).

:5. 联系人的服务器接着 (1) 必须(MUST)发送一个"unsubscribed"类型的出席信息节给用户;并且 (2) 应该(SHOULD)向用户发送从这个联系人的所有可用资源收到的不可用出席信息:

<source lang="xml">
<presence
from='contact@example.org'
to='user@example.com'
type='unsubscribed'/>
<presence
from='contact@example.org/resource'
to='user@example.com'
type='unavailable'/>
</source>

:6. 当用户的服务器收到类型为"unsubscribed" 和 "unavailable"的出席信息节, 它必须(MUST)递送它们给用户:

<source lang="xml">
<presence
from='contact@example.org'
to='user@example.com'
type='unsubscribed'/>
<presence
from='contact@example.org/resource'
to='user@example.com'
type='unavailable'/>
</source>

:7. 接收到"unsubscribed"类型的出席信息节之后, 用户应该(SHOULD)承认收到那个订阅状态变更通知,要么向联系人发送一个"unsubscribe"类型的出席信息节以证实它,要么向联系人发送一个"subscribe"的出席信息节以否认它;这步骤不影响订阅状态(详见订阅状态Subscription States(第九章)), 但是让用户的服务器知道它必须(MUST)不在发送订阅状态变更通知给用户(见第九章第四节).

====情形 #2: 当订阅是相互的时候取消订阅====

:在第二种情形下, 用户有一个向联系人的出席信息的订阅并且联系人也有一个向用户的出席信息的订阅(换言之, 订阅是相互的).

:1. 如果用户想从联系人的出席信息取消订阅, 用户必须(MUST)发送一个"unsubscribe"类型的出席信息节给联系人:

<source lang="xml">
<presence to='contact@example.org' type='unsubscribe'/>
</source>

:2. 作为一个结果, 用户的服务器 (1) 必须(MUST)发送一个名册推送给这个用户的所有已请求名册的可用资源,包含一个关于这个联系人的更新名册条目,其'subscription'属性值设为"from"; 并且 (2) 必须(MUST)路由这个"unsubscribe"类型的出席信息节给这个联系人( 首先把'from'地址设为这个用户的纯 JID(<user@example.com>):

<source lang="xml">
<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'/>
</source>

:3. 接收到指向联系人的"unsubscribe"类型的出席信息节之后, 联系人的服务器 (1) 必须(MUST)初始化一个名册推送给这个联系人的所有已请求名册的可用资源, 包含一个关于这个用户的名册条目,其'subscription'属性值设为"to" (如果联系人不可用或未曾请求名册, 联系人的服务去必须(MUST)修改这个名册条目并且等下次联系人请求名册的时候再发送这个修改过的名册条目); 并且 (2) 必须(MUST)递送这个"unsubscribe"状态变更通知给联系人:

<source lang="xml">
<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'/>
</source>

:4. 接收到这个"unsubscribe"类型的出席信息节之后, 联系人应该(SHOULD)承认收到了那个订阅状态通知,要么向用户发送一个"unsubscribed"类型的出席信息节以证实它,要么向用户发送一个"subscribed"类型的出席信息节以否认它; 这个步骤不影响订阅状态(详见订阅状态Subscription States(第九章)), 但是让联系人的服务器知道它必须(MUST)不再发送订阅状态变更通知给联系人(见第九章第四节).

:5. 联系人的服务器然后 (1) 必须(MUST)发送一个"unsubscribed"类型的出席信息节给用户; 并且 (2) 应该(SHOULD)向用户发送它从联系人的所有可用资源收到的不可用出席信息:

<source lang="xml">
<presence
from='contact@example.org'
to='user@example.com'
type='unsubscribed'/>
<presence
from='contact@example.org/resource'
to='user@example.com'
type='unavailable'/>
</source>

:6. 当用户的服务器收到"unsubscribed"和"unavailable"类型的出席信息节, 它必须(MUST)递送它们给用户:

<source lang="xml">
<presence
from='contact@example.org'
to='user@example.com'
type='unsubscribed'/>
<presence
from='contact@example.org/resource'
to='user@example.com'
type='unavailable'/>
</source>

:7. 接收到"unsubscribed"类型的出席信息节之后, 用户应该(SHOULD)承认收到了那个订阅状态的通知,要么向联系人发送一个"unsubscribe"类型的出席信息节以证实它,要么向联系人发送一个"subscribe"类型的出席信息节以否认它;这个步骤不影响订阅状态(详见订阅状态Subscription States(第九章)), 但是让用户的服务器知道它必须(MUST)不在发送订阅状态变更通知给用户(见第九章第四节).

:注意: 显然这不会导致名册条目从用户的名册移除, 并且联系人仍然有一个对用户的出席信息的订阅.为了完全取消双向的订阅并完全从用户的名册中移除名册条目, 用户应该(SHOULD)使用subscription='remove'(定义在移除一个名册条目并取消所有订阅项Removing a Roster Item and Cancelling All Subscriptions (第八章第六节))更新名册条目.

===取消一个订阅项===

:在批准来自一个用户的任何订阅请求之后的任何时候, 一个联系人可以(MAY)取消那个订阅项. 联系人在所有实例中执行这个动作中发送的XML是相同的, 接下来的订阅状态根据取消命令发出当时所获得的订阅状态而有所不同. 所有可能的情节描述如下.

====情形 #1: 当订阅不是相互的时候取消订阅项====

:在第一种情形下, 用户有一个对联系人的出席信息的订阅但是联系人没有对于用户的出席信息的订阅(换言之, 订阅还不是相互的).

:1. 如果联系人想取消用户的订阅项, 联系人必须(MUST)发送一个"unsubscribed"类型的出席信息节给用户:

<source lang="xml">
<presence to='user@example.com' type='unsubscribed'/>
</source>

:2. 作为一个结果, 联系人的服务器 (1) 必须(MUST)发送一个名册推送给这个联系人的所有已请求名册的可用资源, 包含一个关于这个用户的更新的名册条目,其'subscription'属性值设为"none"; (2) 必须(MUST)路由这个"unsubscribed"类型的出席信息节给用户(首先把'from'地址设为联系人的纯JID(<contact@example.org>)); 并且 (3) 应该(SHOULD)向用户发送它从联系人的所有可用资源收到的不可用出席信息:

<source lang="xml">
<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='contact@example.org'
to='user@example.com'
type='unsubscribed'/>
<presence
from='contact@example.org/resource'
to='user@example.com'
type='unavailable'/>
</source>

:3. 接收到指向用户的"unsubscribed"类型的出席信息节之后, 用户的服务器 (1) 必须(MUST)初始化一个名册推送给这个用户的所有已请求名册的可用资源, 包含一个关于这个联系人的名册条目更新,其'subscription'属性值设为"none"(如果用户不可用或未曾请求名册, 用户的服务器必须(MUST)修改这个名册条目并且等下次用户请求名册的时候发送修改过的名册条目); (2) 必须(MUST)递送这个"unsubscribed"状态改变通知给这个用户的所有可用资源; 并且 (3) 必须(MUST)向这个用户的所有可用资源递送不可用出席信息:

<source lang="xml">
<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'/>
</source>

:4. 接收到"unsubscribed"类型的出席信息节之后, 用户应该(SHOULD)承认收到了那个订阅状态通知,要么向联系人发送一个"unsubscribe"出席信息节以证实它,要么向联系人发送一个"subscribe"类型的出席信息节以否认它;这个步骤不影响订阅状态(详见订阅状态Subscription States(第九章)), 但是让服务器知道它必须(MUST)不再发送订阅状态变更通知给用户(见第九章第四节).

====情形 #2: 当订阅项是相互的时候取消====

:在这种情形下, 用户有一个对联系人的出席信息的订阅并且联系人也有一个对用户的出席信息的订阅(换言之, 订阅是相互的).

:1. 如果联系人想取消用户的订阅, 联系人必须(MUST)发送一个"unsubscribed"类型的出席信息节给用户:

<source lang="xml">
<presence to='user@example.com' type='unsubscribed'/>
</source>

:2. 作为结果, 联系人的服务器 (1) 必须(MUST)发送一个名册推送给这个联系人的所有已请求名册的可用资源, 包含关于这个用户的一个更新的名册条目,其'subscription'属性值设为"to"; (2) 必须(MUST)路由这个"unsubscribed"类型的出席信息节给用户(首先把'from'地址设为联系人的纯JID(<contact@example.org>)); 并且 (3) 应该(SHOULD)向这个用户的所有可用资源发送它从联系人的所有可用资源收到的不可用出席信息:

<source lang="xml">
<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'/>
</source>

:3. 接收到指向用户的"unsubscribed"类型出席信息节之后, 用户的服务器 (1) 必须(MUST)初始化一个名册推送给这个用户的所有已请求名册的可用资源, 包含关于这个联系人的更新的名册条目,其'subscription'属性值设为"from"(如果这个用户不可用或未曾请求名册, 用户的服务器必须(MUST)修改这个名册条目并且等下次用户请求名册的时候发送修改过的条目给它); 并且(2) 必须(MUST)递送这个"unsubscribed"状态变更通知给用户的所有可用资源; 并且 (3) 必须(MUST)向这个用户的所有可用资源递送这个不可用出席信息:

<source lang="xml">
<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'/>
</source>

:4. 接收到这个"unsubscribed"类型的出席信息节之后, 用户应该(SHOULD)承认收到了那个订阅状态通知,要么向联系人发送一个"unsubscribe"类型的出席信息节以证实它,要么向联系人发送一个"subscribe"类型的出席信息节以否认它; 这一步骤不影响订阅状态(详见订阅状态Subscription States (第九章)), 但是让用户的服务器知道它必须(MUST)不再发送订阅状态变更通知给用户(见第九章第四节).

:注意: 显然这不会使得名册条目从联系人的名册中移除, 并且联系人仍然有一个对用户的出席信息的订阅. 为了完全双向的取消一个相互的订阅并且从联系人的名册中完全移除这个名册条目, 联系人应该以subscription='remove'(定义在移除一个名册条目并取消所有订阅项Removing a Roster Item and Cancelling All Subscriptions (第八章第六节))更新名册条目.

===移除一个名册条目并取消所有订阅项===

:因为在双向完整移除一个名册条目和取消所有订阅的过程中可能有很多步骤, 名册管理协议包含一个"shortcut"方法来做这件事. 无论当前的订阅状态是什么, 这个过程可以通过发送一个roster set(包含一个用于这个联系人的条目,其'subscription'属性值设为"remove")来初始化:

<source lang="xml">
<iq type='set' id='remove1'>
<query xmlns='jabber:iq:roster'>
<item
jid='contact@example.org'
subscription='remove'/>
</query>
</iq>
</source>

:当用户从他或她的名册中移除一个联系人(通过把'subscription'属性值设为"remove"), 用户的服务器 (1) 必须(MUST)自动取消用户和联系人之间的任何现存的出席信息订阅项(包括相应的'to'和'from'); (2) 必须(MUST)从用户的名册移除这个名册条目并且通知这个用户的所有已请求名册的可用资源这个名册条目被移除了; (3) 必须(MUST)通知初始化的资源移除成功了; 并且 (4) 应该(SHOULD)向联系人发送它从这个用户的所有可用资源收到的不可用出席信息:

<source lang="xml">
<presence
from='user@example.com'
to='contact@example.org'
type='unsubscribe'/>
<presence
from='user@example.com'
to='contact@example.org'
type='unsubscribed'/>
<iq type='set'>
<query xmlns='jabber:iq:roster'>
<item
jid='contact@example.org'
subscription='remove'/>
</query>
</iq>
<iq type='result' id='remove1'/>
<presence
from='user@example.com/resource'
to='contact@example.org'
type='unavailable'/>
</source>

:收到"unsubscribe"类型的出席信息后, 联系人的服务器 (1) 必须(MUST)初始化一个名册推送给这个联系人的所有已请求名册的可用资源,包含关于这个用户的一个更新的名册条目,其'subscription'属性值设为"to"(如果这个联系人不可用或未曾请求名册, 联系人的服务器必须(MUST)修改这个名册条目并且等下次联系人请求名册的时候发送这个修改过的条目给它); 并且 (2) 也必须(MUST)递送这个"unsubscribe"状态变更通知给这个联系人的所有可用资源:

<source lang="xml">
<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'/>
</source>

:收到这个"unsubscribed"类型的出席信息节之后, 联系人的服务器 (1) 必须(MUST)初始化一个名册推送给这个联系人的所有已请求名册的可用资源,包含一个关于这个用户的更新的名册条目,其'subscription'属性值设为"none"(如果这个联系人不可用或未曾请求名册, 联系人的服务器必须(MUST)修改名册条目并且等下次联系人请求名册的时候把修改过的条目发送给它); 并且 (2) 也必须(MUST)递送这个"unsubscribe"状态改变通知给这个联系人的所有可用资源:

<source lang="xml">
<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='unsubscribed'/>
</source>

:接收到指向联系人的"unavailable"出席信息节之后, 联系人的服务器必须(MUST)递送这个不可用出席信息给这个用户的所有可用资源:

<source lang="xml">
<presence
from='user@example.com/resource'
to='contact@example.org'
type='unavailable'/>
</source>

:注意: 当用户从用户的名册中移除联系人的时候, 这个联系人的名册最后状态是用户仍然在联系人名册中但是订阅状态为"none"; 为了完全移除关于这个用户的名册条目, 联系人也需要发送一个名册移除请求.

==订阅状态==

:本章提供关于订阅状态以及和订阅相关的出席信息节(换言之,类型为"subscribe", "subscribed", "unsubscribe",和 "unsubscribed"的出席信息节)的服务器处理过程的详细信息.

===已定义的状态===

:有九种可能的订阅状态, 从用户的(不是联系人的)角度描述如下:

:# "None" = 联系人和用户互相没有被对方订阅, 并且也都没有从对方那里请求一个订阅
:# "None + Pending Out" = 联系人和用户互相没有被对方订阅, 用户已经向联系人发送了一个订阅请求但还没有收到回复
:# "None + Pending In" = 联系人和用户互相没有被对方订阅, 联系人已经向用户发送了一个订阅请求但还没有收到回复(注意: 在这种状态下联系人的服务器不应该(SHOULD NOT)推送或递送名册条目, 但是应该(SHOULD)等待,直到联系人的订阅请求已经从用户那里得到批准)
:# "None + Pending Out/In" = 联系人和用户互相没有被对方订阅, 联系人已经向用户发送了一个订阅请求但还没有收到回复, 用户已经向联系人发送了一个订阅请求但还没有收到回复
:# "To" = 用户已订阅联系人(单向)
:# "To + Pending In" = 用户已订阅联系人, 联系人已经向用户发送了一个订阅请求但还没有收到回复
:# "From" = 联系人已订阅用户(单向)
:# "From + Pending Out" = 联系人已订阅用户(单向), 用户已经向联系人发送了一个订阅请求但还没有收到回复
:# "Both" = 用户和联系人互相被对方订阅了(双向)

===出站出席信息订阅节的服务器处理过程===

:出站出席信息订阅节使用户能管理他或她对联系人的出席信息的订阅(通过"subscribe"和"unsubscribe"类型), 并且管理联系人对用户的出席信息的访问(通过"subscribed"和"unsubscribed"类型).

:因为用户的服务器和联系人的服务器有可能失去对于订阅状态的同步, 用户的服务器必须(MUST)毫无例外地路由所有"subscribe"或"unsubscribe"类型的出站出席信息节给联系人,使用户能在需要的时候重新同步他或她的对联系人的出席信息的订阅.

:如果从用户的角度来看,一个"subscribed"或"unsubscribed"类型的出席信息节不会导致一个订阅状态的变更,用户的服务器不应该(SHOULD NOT)路由这个节到联系人那里,并且不能(MUST NOT)做出一个状态变更. 如果这个节导致一个订阅状态的变更, 用户的服务器必须(MUST)路由这个节到联系人,并且必须(MUST)做出相应的状态变更. 这些规则总结如下这些表.

:表 1: 推荐的出站"subscribed"节的处理

{|border="1" cellspacing="0"
!当前状态 !! 路由? !! 新状态
|-
|"None" || 否 || 状态不变
|-
|"None + Pending Out" || 否 || 状态不变
|-
|"None + Pending In" || 是 || "From"
|-
|"None + Pending Out/In" || 是 || "From + Pending Out"
|-
|"To" || 否 || 状态不变
|-
|"To + Pending In" || 是 || "Both"
|-
|"From" || 否 || 状态不变
|-
|"From + Pending Out" || 否 || 状态不变
|-
|"Both" || 否 || 状态不变
|}

:表 2: 推荐的出站"unsubscribed"节处理

{|border="1" cellspacing="0"
!当前状态 !! 路由? !! 新状态
|-
|"None" || 否 || 状态不变
|-
|"None + Pending Out" || 否 || 状态不变
|-
|"None + Pending In" || 是 || "None"
|-
|"None + Pending Out/In" || 是 || "None + Pending Out"
|-
|"To" || 否 || 状态不变
|-
|"To + Pending In" || 是 || "To"
|-
|"From" || 是 || "None"
|-
|"From \+ Pending Out" || 是 || "None \+ Pending Out"
|-
|"Both" || 是 || "To"
|}

===入站出席信息订阅节的服务器处理过程===

:入站出席信息订阅节从用户请求一个订阅相关的动作(通过"subscribe"类型), 通知用户由联系人所做的订阅状态相关的动作(通过"unsubscribe"类型),或使联系人能够管理用户对联系人的出席信息的访问(通过"subscribed"和"unsubscribed"类型).

:当用户的服务器为用户从联系人那里接收到一个订阅请求(换言之, 一个"subscribe"类型的出席信息节), 如果用户未曾允许联系人访问用户的出席信息或者没有未决的入站订阅请求, 它必须(MUST)递送那个请求给用户;无论如何, 如果有一个未决的入站订阅请求, 用户的服务器不应该(SHOULD NOT)递送这个新的请求, 因为上一个订阅请求可能已经被记录下来了. 如果用户已经允许联系人访问用户的出席信息,用户的服务器应该(SHOULD)对一个从联系人发来的"subscribe"类型的入站出席信息节自动回复(通过代替用户向联系人发送一个"subscribed"类型的出席信息节); 这个规则使得联系人可以在需要的时候重新同步订阅状态. 这些规则总结如下面这些表.

:表 3: 推荐的入站"subscribe"节处理

{|border="1" cellspacing="0"
!当前状态 !! 递送? !! 新状态
|-
|"None" || 是 || "None + Pending In"
|-
|"None + Pending Out" || 是 || "None + Pending Out/In"
|-
|"None + Pending In" || 否 || 状态不变
|-
|"None + Pending Out/In" || 否 || 状态不变
|-
|"To" || 是 || "To + Pending In"
|-
|"To + Pending In" || 否 || 状态不变
|-
|"From" || 否 * || 状态不变
|-
|"From + Pending Out" || 否 * || 状态不变
|-
|"Both" || 否 * || 状态不变
|}

:* 服务器应该(SHOULD)以"subscribed"节自动回复

:当用户的服务器为用户从联系人那里收到一个"unsubscribe"类型的出席信息节, 如果从用户的角度看这个节会导致一个订阅状态变更,那么用户的服务器应该(SHOULD)代替用户自动应答(发送一个"unsubscribed"类型的出席信息节给联系人), 必须(MUST)递送这个"unsubscribe"节给用户,并且必须(MUST)改变状态. 如果不会导致订阅状态变更, 用户的服务器不应该(SHOULD NOT)递送这个节并且不能(MUST NOT)改变状态. 这些规则总结如下表.

:表 4: 推荐的入站"unsubscribe"节处理

{|border="1" cellspacing="0"
!当前状态 !! 递送? !! 新状态
|-
|"None" || 否 || 状态不变
|-
|"None + Pending Out" || 否 || 状态不变
|-
|"None + Pending In" || 是 * || "None"
|-
|"None + Pending Out/In" || 是 * || "None \+ Pending Out"
|-
|"To" || 否 || 状态不变
|-
|"To + Pending In" || 是 * || "To"
|-
|"From" || 是 * || "None"
|-
|"From + Pending Out" || 是 * || "None \+ Pending Out
|-
|"Both" || 是 * || "To"
|}

:* 服务器应该(SHOULD)以"unsubscribed"节自动应答

:当用户的服务器为用户从联系人那里收到一个"subscribed"类型的出席信息节, 如果没有一个为访问联系人的出席信息的未决的出站请求,它不能(MUST NOT)递送这个节给用户并且不能(MUST NOT)改变订阅状态. 如果有一个为了访问联系人的出席信息的未决的出站请求并且这个"subscribed"类型的入站出席信息请求会导致一个订阅状态的改变,用户的服务器必须(MUST)递送这个节给用户并且必须(MUST)改变订阅状态. 如果用户已经有授权可以访问联系人的出席信息, 这个"subscribed"类型的入站出席信息节不导致一个订阅状态的变更;从而用户的服务器不应该(SHOULD NOT)递送这个节给用户并且不能(MUST NOT)改变订阅状态. 这些规则总结如下表.

:表 5: 推荐的入站"subscribed"节处理

{|border="1" cellspacing="0"
!当前状态 !! 递送? !! 新状态
|-
|"None" || 否 || 状态不变
|-
|"None + Pending Out" || 是 || "To"
|-
|"None + Pending In" || 否 || 状态不变
|-
|"None + Pending Out/In" || 是 || "To \+ Pending In"
|-
|"To" || 否 || 状态不变
|-
|"To + Pending In" || 否 || 状态不变
|-
|"From" || 否 || 状态不变
|-
|"From + Pending Out" || 是 || "Both"
|-
|"Both" || 否 || 状态不变
|}

:当用户的服务器为用户从联系人那里收到了一个"unsubscribed"类型的出席信息节, 如果有一个为了访问联系人的出席信息的未决的出站请求或者用户当前已经有授权可以访问联系人的出席信息,它必须(MUST)递送这个节给用户并且必须(MUST)改变订阅状态. 否则, 用户的服务器不应该(SHOULD NOT)递送这个节并且不能(MUST NOT)改变订阅状态. 这些规则总结如下表.

:表 6: 推荐的入站"unsubscribed"节处理

{|border="1" cellspacing="0"
!当前状态 !! 递送? !! 新状态
|-
|"None" || 否 || 状态不变
|-
|"None + Pending Out" || 是 || "None"
|-
|"None + Pending In" || 否 || 状态不变
|-
|"None + Pending Out/In" || 是 || "None \+ Pending In"
|-
|"To" || 是 || "None"
|-
|"To + Pending In" || 是 || "None \+ Pending In"
|-
|"From" || 否 || 状态不变
|-
|"From + Pending Out" || 是 || "From"
|-
|"Both" || 是 || "From"
|}

===服务器递送和客户端承认订阅请求以及状态变更通知===

:当一个服务器收到一个"subscribe"类型的入站出席信息节(换言之, 一个订阅请求)或"subscribed"类型,"unsubscribe"类型, 或"unsubscribed"类型(换言之, 一个订阅状态变更通知), 除了发送适当的名册推送(或当下次名册被一个可用资源请求时发送更新的名册), 它必须(MUST)递送这个请求或通知给预定的接收者至少一次. 一个服务器可以(MAY)要求接收者的回执以承认接收到了所有状态变更通知(并且必须(MUST)要求承认订阅请求的情形, 换言之,类型的出席信息节"subscribe"). 为了要求回执, 一个服务器应该(SHOULD)在每次接收者登陆的时候发送这个请求或通知给它, 直到这个接收者承认收到这个通知(通过证实"affirming"或禁止"denying"这个通知),如下表:

:表 7: 订阅状态变更通知的承认

{|border="1" cellspacing="0"
!节类型 !! 接受 !! 禁止
|-
|subscribe || subscribed || unsubscribed
|-
|subscribed || subscribe || unsubscribe
|-
|unsubscribe || unsubscribed || subscribed
|-
|unsubscribed || unsubscribe || subscribe
|}

:显然, 根据前述的订阅状态图表, 一些回执节将被路由到联系人并且导致状态的变更, 而其他的则不会. 无论如何, 任何这样的节必须(MUST)导致服务器不再发送订阅状态变更通知给用户.

:因为在接收到roster set(其'subscription'属性值设为"remove"(见移除一个名册条目并且取消所有订阅项 Removing a Roster Item and Cancelling All Subscriptions (第八章第六节)))之后,用户的服务器必须(MUST)自动生成"unsubscribe"和"unsubscribed"类型的出站出席信息节,服务器必须(MUST)把一个名册移除请求视为发送所有这些出席信息节,以决定是否继续向用户发送"subscribe"或"subscribed"类型的订阅状态变更通知.

==屏蔽通信==

:大多数即时消息系统已发现有必要实现一些方法来为用户屏蔽来自某些特定的其他用户的通信(这在\[IMP-REQS\]的第五章第一节第五小节, 第五章第一节第十五小节,第五章第三节第二小节, 和第五章第四节第十小节中也有要求). 在XMPP中这是由管理某人的隐私列表来实现的(使用'jabber:iq:privacy'名字空间).

:服务器端的隐私列表使得以下用例能够完成:

:* 接收某人的隐私列表.

:* 增加, 移除, 和编辑某人的隐私列表.

:* 设置, 改变, 或取消激活的列表.

:* 设置, 改变, 或取消缺省的列表 (换言之, 缺省激活的那个列表).

:* 基于JID, group, 或 subscription 类型(或全局的) 允许或屏蔽消息.

:* 允许或屏蔽入站出席信息通知,基于 JID, group, 或 subscription 类型 (或全局的).

:* 允许或屏蔽出站出席信息通知,基于 JID, group, 或 subscription 类型 (或全局的).

:* 允许或屏蔽 IQ 节, 基于 JID, group,或 subscription 类型(或全局的).

:* 允许或屏蔽所有通信, 基于 JID, group, 或 subscription 类型(或全局的).

:注意: 出席信息通知不包括出席信息订阅,只包括广播给那些已订阅了用户出席信息的实体的出席信息. 因而这包括没有'type'属性或只包含type='unavailable'的的出席信息节.

===语法和语义===

:一个用户可以(MAY)定义一个或更多的隐私列表, 它们由用户的服务器保存. 每个<list/>元素包含一个或多个格式为<item/>元素的规则, 并且每个<item/>元素使用属性来定义一个隐私规则类型, 一个适用于规则的特定值, 相应的动作, 和处理顺序相应的条目位置.

:语法如下:

<source lang="xml">
<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>
</source>

:如果类型是"jid", 那么'value'属性必须(MUST)包含一个合法的Jabber ID. JIDs 应该(SHOULD)满足以下顺序:

:# <user@domain/resource> (仅为匹配的资源)
:# <user@domain> (任何匹配的资源)
:# <domain/resource> (仅匹配的资源)
:# <domain> (匹配这个域本身, 正如任何 user@domain, domain/resource, 或包含一个子域的地址)

:如果类型为"group", 那么'value'属性应该(SHOULD)包含组在用户的名册中的名字. (如果一个客户端尝试更新, 新建, 或删除一个不在用户名册中的组的列表条目, 服务器应该(SHOULD)返回给客户端一个<item-not-found/>节错误.)

:如果类型是"subscription", 那么'value'属性必须(MUST)是"both", "to", "from", 或"none" (定义在名册语法和语义Roster Syntax and Semantics (第七章第一节))中的一个人, 在这里 "none" 包括对于用户来说完全未知和根本不在用户名册中的实体.

:如果没有包含'type'属性, 这个规则提供失败"fall-through" 情景.

::'action'属性必须(MUST)被包含并且它的值必须(MUST)是允许"allow"或禁止"deny".

::'order'属性必须(MUST)被包含并且它的值必须(MUST)是一个在列表的所有条目中具有唯一性的非负整数. (如果一个客户端尝试以一个非唯一的order值建立或更新一个列表, 服务器必须(MUST)返回给客户端一个<bad-request/>节错误.)

::<item/>元素可以(MAY)包含一个或更多子元素,使得一个实体可以指明更多的细微控制包括屏蔽哪些种类的节(换言之, 不只是简单地屏蔽所有节). 允许的子元素包括:

:* <message/> \-\- 屏蔽引入消息节
:* <iq/> \-\- 屏蔽引入 IQ 节
:* <presence-in/> \-\- 屏蔽引入出席信息通知
:* <presence-out/> \-\- 屏蔽外出出席信息通知

:在"jabber:iq:privacy'名字空间之内, 一个"set"类型的IQ节的<query/>子元素不能(MUST NOT)包含超过一个子元素(换言之, 这个节必须(MUST)只包含一个<active/>元素, 一个<default/>元素, 或一个<list/>元素); 如果一个发送中的实体违反了这个规则, 接收中的实体必须(MUST)返回一个 return a <bad-request/>节错误.

:当一个客户端增加或更新一个隐私列表, <list/>元素应该(SHOULD)包含至少一个<item/>子元素; 当一个客户端移除一个隐私列表的时候, <list/>元素不能(MUST NOT)包含任何<item/>子元素.

:当一个客户端更新一个隐私列表的时候, 它必须包含所有想得到的条目(换言之, 不是一个"delta").

===商业规则===

:# 如果有一个为某会话设置的激活的列表, 它只影响为其激活的那个会话, 并且只在那一个会话的持续期间有效; 服务器必须(MUST)只应用激活列表,并且不能(MUST NOT)应用缺省列表(换言之, 列表没有层次"layering").
:# 缺省列表总体适用于用户, 并且如果没有为一个节指向的目标session/resource设置激活列表,或用户当前没有会话,它会被处理.
:# 如果没有为一个会话设置激活列表(或用户当前没有会话), 并且没有缺省列表,那么所有节应该被(SHOULD BE)接受或由服务器代替用户做适当的处理(遵守用于处理XML节的服务器规则 Server Rules for Handling XML Stanzas (第十一章)).
:# 隐私列表必须(MUST)是第一个由服务器应用的递送规则, 替代 (1) 定义在用于处理XML节的服务器规则Server Rules for Handling XML Stanzas (第十一章)的路由和递送规则, 以及 (2)和订阅相关的出席信息节的处理(和相应的名册推送的生成) 定义在名册条目和出席信息订阅的集成Integration of Roster Items and Presence Subscriptions (第八章).
:# 服务器处理隐私列表条目的顺序是很重要的. 列表条目必须(MUST)按照每个<item/>的'order'属性的整数值的升序来处理.
:# 一旦节和一个隐私列表规则匹配, 服务器必须(MUST)按照这个规则适当地处理这个节,然后终止处理.
:# 如果在一个列表中没有提供一个fall-through的条目, fall-through 动作被假定为允许"allow".
:# 如果一个用户为一个激活列表更新定义, 之后的基于那个激活列表的操作必须(MUST)使用更新的定义(为了那些激活列表正应用的所有资源).
:# 如果在用户的会话期间,在激活的或缺省的列表中定义的名册条目中的订阅状态改变了,或名册组改变了,接下来基于那个列表的处理必须(MUST)考虑计入这个已改变的状态或组(对那个列表当前应用的所有资源).
:# 当一个规则的定义修改了的时候, 服务器必须(MUST)发送一个类型为"set"的IQ节给所有已连接的资源, 包括一个只有一个<list/>子元素的<query/>元素, 其'name'属性设为已修改的隐私列表的名字. 这些隐私列表推送("privacy list pushes")遵守和用于名册管理的名册推送("roster pushes")同样的语义 , 除了被推送给已连接的资源的列表名字本身(不是完整的列表定义或那个"delta"). 是否接受这个修改了的列表定义最终由接收中的资源来决定, 尽管如果这个列表正在应用于一个已连接的资源,它应该(SHOULD)这样做.
:# 当一个已连接的资源尝试移除一个列表或指定一个新的缺省列表,而那个列表应用于一个已连接的资源而不是正在发送的资源, 服务器必须(MUST)返回一个<conflict/>错误给发送中的资源并且不能(MUST NOT)执行这个请求的改变.

===接收某人的隐私列表===

:例子: 客户端向服务器请求隐私列表的名字:

<source lang="xml">
<iq from='romeo@example.net/orchard' type='get' id='getlist1'>
<query xmlns='jabber:iq:privacy'/>
</iq>
</source>

:例子: 服务器发送隐私列表的名字给客户端, 激活列表和缺省列表放在前面:

<source lang="xml">
<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>
</source>

:例子: 客户端向服务器请求一个隐私列表:

<source lang="xml">
<iq from='romeo@example.net/orchard' type='get' id='getlist2'>
<query xmlns='jabber:iq:privacy'>
<list name='public'/>
</query>
</iq>
</source>

:例子: 服务器发送一个隐私列表给客户端:

<source lang="xml">
<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>
</source>

:例子: 客户端向服务器请求另一个隐私列表:

<source lang="xml">
<iq from='romeo@example.net/orchard' type='get' id='getlist3'>
<query xmlns='jabber:iq:privacy'>
<list name='private'/>
</query>
</iq>
</source>

:例子: 服务器发送另一个隐私列表给客户端:

<source lang="xml">
<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>
</source>

:例子: 客户端再向服务器请求另一个隐私列表:

<source lang="xml">
<iq from='romeo@example.net/orchard' type='get' id='getlist4'>
<query xmlns='jabber:iq:privacy'>
<list name='special'/>
</query>
</iq>
</source>

:例子: 服务器再发送另一个隐私列表给客户端:

<source lang="xml">
<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>
</source>

:在这个例子中, 用户有三个列表: (1) 'public', 它允许所有人的通信,除了一个指定的实体(这是缺省列表); (2) 'private', 它只允许和这个用户有双向订阅的联系人的通信(这是激活的列表); 还有 (3) 'special', 它只允许三个指定的实体通信.

:如果用户尝试接收一个列表但是这个列表的名字不存在, 服务器必须(MUST)返回一个<item-not-found/>节错误给用户:

:例子: 客户端尝试接收不存在的列表:

<source lang="xml">
<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>
</source>

:用户在一次只被允许接收一个列表. 如果用户尝试同一个请求中接收超过一个列表, 服务器必须(MUST)返回一个<bad request/>节错误给用户:

:例子: 客户端尝试接收多于一个的列表:

<source lang="xml">
<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>
</source>

===管理激活列表===

:为了设置或改变服务器当前应用的激活列表, 用户必须(MUST)发送一个类型为"set"的IQ节,包含一个符合'jabber:iq:privacy'名字空间的<query/>元素,这个元素<query/>又包含一个空的<active/>子元素,而这个<active/>拥有一个'name'属性,'name'属性值则设为期望的列表名.

:例子: 客户端请求激活列表变更:

<source lang="xml">
<iq from='romeo@example.net/orchard' type='set' id='active1'>
<query xmlns='jabber:iq:privacy'>
<active name='special'/>
</query>
</iq>
</source>

:服务器必须(MUST)在返回结果给客户端之前激活并应用这个已请求的列表.

:例子: 服务器承认激活列表变更成功:

<source lang="xml">
<iq type='result' id='active1' to='romeo@example.net/orchard'/>
</source>

:如果用户尝试设置一个激活列表但是列表名不存在, 服务器必须(MUST)返回一个<item-not-found/>节错误给用户:

:例子: 客户端尝试设置一个不存在的列表作为激活列表:

<source lang="xml">
<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>
</source>

:为了取消使用任何激活列表, 已连接的资源必须(MUST)发送一个空的<active/>元素,并且不带'name'属性.

:例子: 客户端取消使用激活列表:

<source lang="xml">
<iq from='romeo@example.net/orchard' type='set' id='active3'>
<query xmlns='jabber:iq:privacy'>
<active/>
</query>
</iq>
</source>

:例子: 服务器承认取消任何激活列表成功:

<source lang="xml">
<iq type='result' id='active3' to='romeo@example.net/orchard'/>
</source>

===管理缺省列表===

:为了改变它的缺省列表(它对用户来说是全局应用的, 不只是发送中的资源), 用户必须(MUST)发送一个类型为"set"的IQ节, 它包含一个符合'jabber:iq:privacy'名字空间的<query/>元素,这个<query/>元素包含一个空的<default/>子元素,这个<default/>子元素拥有一个'name'属性,这个'name'属性的值设为期望的列表名.

:例子: 用户请求变更缺省列表:

<source lang="xml">
<iq from='romeo@example.net/orchard' type='set' id='default1'>
<query xmlns='jabber:iq:privacy'>
<default name='special'/>
</query>
</iq>
</source>

:例子: 服务器承认缺省列表变更成功:

<source lang="xml">
<iq type='result' id='default1' to='romeo@example.net/orchard'/>
</source>

:如果用户尝试变更一个缺省列表但是这个缺省列表正在由至少一个已连接的但不是当前发送中的这个资源使用着,服务器必须(MUST)返回一个<conflict/>节错误给发送中的资源:

:例子: 客户端尝试改变一个缺省列表但是这个列表正在被另一个资源使用:

<source lang="xml">
<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>
</source>

:如果用户尝试设置一个缺省列表但是这个列表的名字不存在, 服务器必须(MUST)返回一个<item-not-found/>节错误给用户:

:例子: 客户端尝试设置一个不存在的列表作为缺省列表:

<source lang="xml">
<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>
</source>

:为了取消使用缺省列表(换言之, 任何时候都使用域的节路由规则), 用户必须(MUST)发送一个空的不带'name'属性的<default/>元素.

:例子: 客户端取消使用缺省列表:

<source lang="xml">
<iq from='romeo@example.net/orchard' type='set' id='default2'>
<query xmlns='jabber:iq:privacy'>
<default/>
</query>
</iq>
</source>

:例子: 服务器承认成功地取消了任何缺省列表:

<source lang="xml">
<iq type='result' id='default2' to='romeo@example.net/orchard'/>
</source>

:如果一个已连接的资源尝试取消一个用户全局的缺省列表但是这个缺省列表正在应用于另一个已连接的资源,服务器必须(MUST)返回一个<conflict/>错误给发送中的资源:

:例子: 客户端尝试取消一个缺省列表但是这个列表正在被另一个资源使用:

<source lang="xml">
<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>
</source>

===编辑一个隐私列表===

:为了编辑一个隐私列表, 用户必须(MUST)一个类型为"set"的IQ节,包含一个符合'jabber:iq:privacy'名字空间的<query/>元素,这个<query/>元素包含一个拥有一个<list/>子元素,这个<list/>子元素拥有一个'name'属性,这个'name'属性的值设为用户想编辑的列表名. 这个<list/>元素必须(MUST)包含一个或多个<item/>元素, 它们包含了列表中的所有元素以指明用户期望的对列表的变更(不是the "delta").

:例子: 客户端编辑隐私列表:

<source lang="xml">
<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>
</source>

:例子: 服务器承认列表编辑成功:

<source lang="xml">
<iq type='result' id='edit1' to='romeo@example.net/orchard'/>
</source>

:注意: 任何给定的条目的'order'属性值不是固定的. 因而在前述的例子中如果用户想在"tybalt@example.com"条目和"paris@example.org"条目之间增加4个条目, 用户的客户端必须(MUST)在向服务器提交列表之前对相关的条目重新编号.

:服务器必须(MUST)现在发送一个隐私列表推送"privacy list push"给所有已连接的资源:

:例子: 基于列表编辑的隐私列表推送:

<source lang="xml">
<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/home' type='set' id='push2'>
<query xmlns='jabber:iq:privacy'>
<list name='public'/>
</query>
</iq>
</source>

:按照定义在[XMPP-CORE|XMPP文档列表/XMPP正式RFC标准/RFC3920]的IQ节语义, 每个已连接的子元素必须(MUST)返回一个如下的 IQ result 给服务器:

:例子: 承认收到一个隐私列表推送:

<source lang="xml">
<iq from='romeo@example.net/orchard'
type='result'
id='push1'/>
<iq from='romeo@example.net/home'
type='result'
id='push2'/>
</source>

===增加一个新的隐私列表===

:增加一个新的列表和编辑一个现有的列表使用的协议是相同的. 如果列表名和现有的列表名吻合, 这个增加新列表的请求将覆写那个旧的列表. 正如编辑列表一样, 服务器也必须(MUST)发送一个隐私列表推送"privacy list push" 给所有已连接的资源.

===移除一个隐私列表===

:为了移除一个隐私列表, 用户必须(MUST)发送一个类型为"set"的IQ节,包含一个符合'jabber:iq:privacy'名字空间的<query/>元素,这个<query/>元素包含一个空的<list/>子元素,这个<list/>子元素拥有一个'name'属性,这个'name'属性的值设为用户想移除的列表名.

:例子: 客户端移除一个隐私列表:

<source lang="xml">
<iq from='romeo@example.net/orchard' type='set' id='remove1'>
<query xmlns='jabber:iq:privacy'>
<list name='private'/>
</query>
</iq>
</source>

:例子: 服务器承认成功地移除列表:

<source lang="xml">
<iq type='result' id='remove1' to='romeo@example.net/orchard'/>
</source>

:如果一个用户尝试移除一个列表而这个列表正在被应用于至少一个和发送中的资源不同的已连接的资源, 服务器必须(MUST)返回一个<conflict/>节错误给用户; 换言之, 用户在尝试移除它之前必须(MUST)先设置另一个列表成为激活或缺省列表. 如果用户尝试移除一个列表但是列表名字不存在, 服务器必须(MUST)返回一个<item-not-found/>节错误给用户. 如果用户尝试在同一个请求中移除超过一个的列表, 服务器必须(MUST)反回一个<bad request/>节错误给用户.

===屏蔽消息===

:服务器端的隐私列表使得一个用户可以基于实体的JID,名册组,或订阅状态(或全局地)来屏蔽从其他实体引入的消息. 以下例子阐明这个协议. (注意: 为了精简, "result"类型的IQ节没有在以下例子中显示, 隐私列表推送也没有显示.)

:例子: 基于JID的用户屏蔽:

<source lang="xml">
<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>
</source>

:作为建立和应用前述列表的结果, 用户将不会接收到从特定JID发来的消息.

:例子: 基于名册组的用户屏蔽:

<source lang="xml">
<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>
</list>
</query>
</iq>
</source>

:作为建立和应用前述列表的结果, 用户将不会收到从指定名册组中的任何实体发来的消息.

:例子: 基于订阅状态的用户屏蔽:

<source lang="xml">
<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>
</source>

:作为建立和应用前述列表的结果, 用户将不会收到从任何指定订阅状态的实体发来的消息.

:例子: 全局的用户屏蔽:

<source lang="xml">
<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>
</source>

:作为建立和应用前述列表的结果, 用户将不会收到从任何其他用户发来的消息.

===屏蔽入站出席信息通知===

:服务器端的隐私列表使得用户可以基于实体的JID,名册组,或订阅状态(或全局地)屏蔽来自其他实体的入站出席信息通知. 以下例子阐明了这个协议.

:注意: 出席信息通知不包括出席信息订阅,只是把出席信息广播给当前已订阅某个联系人的出席信息的用户. 所以它只包括没有'type'属性的或type='unavailable'的出席信息节.

:例子: 基于JID的用户屏蔽:

<source lang="xml">
<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>
</source>

:作为建立和应用前述列表的结果, 用户将不会收到从指定JID发来的出席信息通知.

:例子: 基于名册组的用户屏蔽:

<source lang="xml">
<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>
</source>

:作为建立和应用前述列表的结果, 用户将不会从指定的名册组中的任何实体收到出席信息通知.

:例子: 基于订阅状态的用户屏蔽:

<source lang="xml">
<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>
</source>

:作为建立和应用前述列表的结果, 用户将不会从指定订阅状态的任何实体收到出席信息通知.

:例子: 全局的用户屏蔽:

<source lang="xml">
<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>
</source>

:作为建立和应用前述列表的结果, 用户将不会从任何其他实体收到出席信息通知.

===屏蔽出站出席信息通知===

:服务器端的隐私列表使用户能够屏蔽发出到其他实体的出席信息通知(基于实体的JID, 名册组, 或订阅状态 (或全局的)). 以下例子阐明了这个协议.

:注意: 出席信息通知不包括出席信息订阅,只把出席信息广播给已订阅了用户的出席信息的联系人.所以只包括没有'type'属性或type='unavailable'的出席信息节.

:例子: 基于JID的用户屏蔽:

<source lang="xml">
<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>
</source>

:作为建立和应用前述列表的结果, 用户将不会给指定JID发送出席信息通知.

:例子: 基于名册组的用户屏蔽:

<source lang="xml">
<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>
</source>

:作为建立和应用前述列表的结果, 用户将不会向指定名册组的任何实体发送出席信息通知.

:例子: 基于订阅状态的用户屏蔽:

<source lang="xml">
<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/>
</item>
</list>
</query>
</iq>
</source>

:作为建立和应用前述列表的结果, 用户将不会向指定订阅状态的任何实体发送出席信息通知.

:例子: 全局的用户屏蔽:

<source lang="xml">
<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>
</source>

:作为建立和应用前述列表的结果, 用户将不会向任何其他用户发送出席信息通知.

===屏蔽IQ节===

:服务器端的隐私列表使用户能够屏蔽从其他实体进来的IQ节(基于实体的JID,名册组, 或订阅状态(或全局地)). 以下例子阐明了这个协议.

:例子: 基于JID的用户屏蔽:

<source lang="xml">
<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>
</source>

:作为建立和应用这个列表的结果, 用户将不会收到从指定JID发来的IQ节.

:例子: 基于名册组的用户屏蔽:

<source lang="xml">
<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>
</source>

:作为建立和应用前述列表的结果, 用户将不会收到从指定名册组的任何实体发来的IQ节.

:例子: 基于订阅状态的用户屏蔽:

<source lang="xml">
<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>
</source>

:作为建立和应用前述列表的结果, 用户将不会收到从指定订阅状态的任何实体发来的IQ节.

:例子: 全局的用户屏蔽:

<source lang="xml">
<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>
</source>

:作为建立和应用前述列表的结果, 用户将不会收到从任何其他用户发来的IQ节.

===屏蔽所有通信===

:服务器端的隐私列表使用户能够基于其他实体的JID,名册组,或订阅状态(或全局的)屏蔽所有进来和出去的节. 注意那部包括订阅相关的出席信息节, 它们被排除在外 (定义在屏蔽入站出席信息通知Blocking Inbound Presence Notifications (第十章第十节)). 以下例子阐明了这个协议.

:例子: 基于JID的用户屏蔽:

<source lang="xml">
<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>
</source>

:作为建立和应用这个列表的结果, 用户将不会收到和发送任何通信给指定JID.

:例子: 基于名册组的用户屏蔽:

<source lang="xml">
<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'
action='deny'
order='13'/>
</list>
</query>
</iq>
</source>

:作为建立和应用前述列表的结果, 用户将不会收到和发送和指定名册组的任何实体的通信.

:例子: 基于订阅状态的用户屏蔽:

<source lang="xml">
<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>
</source>

:作为建立和应用前述列表的结果, 用户将不会收到和发送和指定订阅状态的任何实体的通信.

:例子: 全局的用户屏蔽:

<source lang="xml">
<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>
</source>

:作为建立和应用前述列表的结果, 用户将不会收到和发送和任何其他用户的通信.

===已被屏蔽的实体尝试和用户通信===

:如果一个已被屏蔽的实体尝试发送消息或出席信息给用户, 用户的服务器应该(SHOULD)安静的丢掉这个节并且不能(MUST NOT)返回一个错误给发送的实体.

:如果一个已被屏蔽的实体尝试发送一个类型为"get"或"set"的IQ节给用户, 用户的服务器必须(MUST)给发送的实体一个<service-unavailable/>节错误, 因为这是一个客户端不理解IQ get或set的名字空间的时候所发送的标准错误码. 其他类型的IQ节应该(SHOULD)被服务器安静的丢弃.

:例子: 已被屏蔽的实体尝试发送 IQ get:

<source lang="xml">
<iq type='get'
to='romeo@example.net'
from='tybalt@example.com/pda'
id='probing1'>
<query xmlns='jabber:iq:version'/>
</iq>
</source>

:例子: 服务器返回一个错误给已被屏蔽的实体:

<source lang="xml">
<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>
</source>

===高级启发===

:当建立一个高级隐私启发的表达式的时候, 客户端应该(SHOULD)使用尽可能简单的表达式.

:例如, 启发 "屏蔽不在我名册中的任何用户的通信" 可以使用以下任何一种方式来构造:

:* 允许任何来自我的名册中的JID的通信 (换言之, 列出每个JID成为单独的列表条目), 但是屏蔽和其他任何人的通信

:* 允许任何来自我的名册的某个组中的用户的通信(换言之, 列出每个组作为单独的条目), 但是屏蔽和任何其他人的通信

:* 允许任何我的他(她)之间的订阅状态为'both'或'to'或'from'的用户的通信(换言之, 单独列出每个订阅状态值), 但是屏蔽和任何其他人的通信

:* 屏蔽和任何订阅状态为'none'的用户的通信

:最后一个表达式是最简单的并且应该(SHOULD)被使用; 这种情形下将被发送的XML如下:

<source lang="xml">
<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>
</source>

==服务器处理XML节的规则==

:用于服务器的基本路由和递送规则定义在[XMPP-CORE|XMPP文档列表/XMPP正式RFC标准/RFC3920]中. 本章定义附加的用于XMPP兼容的即时消息和出席信息服务器规则.

===入站节===

:如果一个入站的节的'to'属性的JID中的域标识符部分的主机名和服务器自身的主机名相同并且'to'属性的JID的格式是<user@example.com>或<user@example.com/resource>, 服务器必须(MUST)首先强制应用任何隐私列表(第十章),然后服从以下定义的规则:

:# 如果JID的格式是<user@domain/resource>并且有一个可用的资源和这个全JID吻合, 接受这得服务器必须(MUST)递送这个节给那个资源.
:# 然后如果JID的格式是<user@domain>或格式是<user@domain/resource>,并且和用户相关的帐号不存在, 接收者的服务器 (a) 如果它是一个出席信息节,应该(SHOULD) 安静的忽略这个节(换言之,既不递送它也不返回一个错误), (b) 如果它是一个IQ节,必须(MUST)返回一个<service-unavailable/>节错误给发送者, 并且 (c) 如果它是一个消息节,应该(SHOULD)返回一个<service-unavailable/>节错误给发送者.
:# 然后如果JID的格式是<user@domain/resource>并且没有可用的资源和它的全JID匹配, 接收者的服务器 (a) 如果它是一个出席信息节,应该(SHOULD)安静地忽略这个节(换言之, 既不递送它也不返回一个错误), (b) 如果它是一个IQ节,必须(MUST)返回一个<service-unavailable/>节错误给发送者, 并且 (c) 如果它是一个消息节,应该(SHOULD)把这个节视为发往<user@domain>.
:# 然后如果JID的格式是<user@domain>并且这个用户至少有一个可用的资源, 接收者的服务器必须(MUST)遵守以下规则:
:## 对于消息节, 服务器应该(SHOULD)递送这个节给高优先级的可用资源(如果这个资源没有提供<priority/>元素的值, 服务器应该(SHOULD)认为它提供的值为零). 如果两个或更多的可用资源有相同的优先级, 服务器可以(MAY)使用一些其他的规则(例如, 最近的连接时间, 最近的活动时间, 或由一些<show/>值的层次所定义的最高的可用性) 来从它们中间选择,或可以(MAY)递送这个消息到所有这些资源. 无论如何, 服务器不能(MUST NOT)这个节到一个优先级为负数的可用资源; 如果唯一的一个可用资源的优先级是负数, 服务器应该(SHOULD)当成没有可用资源一样处理这个消息(定义在后面). 另外, 服务器不能(MUST NOT)重写'to'属性(换言之, 它必须(MUST)让它保持<user@domain>而不是改成<user@domain/resource>).
:## 对于类型不是"probe"的出席信息节, 服务器必须(MUST)递送这个节给所有可用的资源;对于出席信息调查, 服务器应该(SHOULD)基于定义在出席信息调查Presence Probes (第五章第一节第三小节)的规则来应答. 另外, 服务器不能(MUST NOT)重写'to'属性(换言之, 它必须(MUST)保持<user@domain>而不是改为<user@domain/resource>).
:## 对于IQ节, 服务器本身必须(MUST)代替用户应答一个IQ result或一个IQ error, 并且不能(MUST NOT)递送这个IQ节给任何可用的资源. 具体来说, 如果合格的名字空间的语义定义了一个服务器可以提供的应答, 服务器必须(MUST)代替用户应答这个节; 如果没有, 服务器必须(MUST)应答一个<service-unavailable/>节错误.
:# 然后如果JID的格式为<user@domain>并且没有这个用户的可用资源, 这个节如何处理依赖于节的类型:
:## 对于类型为"subscribe", "subscribed", "unsubscribe", 和"unsubscribed"的出席信息节, 服务器必须(MUST)维持这个节的一个记并且至少递送这个节一次(也就是, 当这个用户下次建立一个可用的资源的时候); 另外, 服务器必须(MUST)递送类型为"subscribe"的出席信息节直到用户批准或拒绝这个订阅请求为止(参见出席信息订阅Presence Subscriptions (第五章第一节第六小节)).
:## 对于所有其他的出席信息节, 服务器应该(SHOULD)安静的忽略这个节,既不存储它用于以后递送也不代替用户应答它.
:## 对于消息节, 服务器可以(MAY)选择代替用户存储这个节并且当用户下次可用的时候递送给他, 或通过一些其他的手段转发这个消息给用户(例如, 给用户的邮箱). 无论如何, 如果离线消息存储或消息转发没有激活, 服务器必须(MUST)返回发送者一个<service-unavailable/>节错误. (注意:离线信息存储和消息转发没有定义在 XMPP, 因为严格来说它们是实现和服务提供的问题.)
:## 对于IQ节, 服务器本身必须(MUST)代替用户应答一个IQ result或一个IQ error. 具体来说,如果合法的名字空间的语义定义了一个服务器可以提供的应答, 服务器必须(MUST)代替用户应答这个节; 如果没有, 服务器必须(MUST)应答一个<service-unavailable/>节错误.

===出站节===

:如果出站节的'to'属性的地址的域标识符部分的主机名和服务器自身的一个主机名吻合, 服务器必须(MUST) 根据入站节Inbound Stanzas(第十一章第一节)的规则递送这个节给一个本地实体.

:如果出站节的'to'属性的地址的域标识符部分的主机名不和服务器自身的一个主机名吻合, 服务器必须(MUST)尝试路由这个节到外部域. 推荐的动作顺序定义如下:

:# 首先尝试用一个"xmpp-server"服务和"tcp"协议的\[SRV\]服务解析这个外部的主机名,结果得到的资源记录格式如"_xmpp-server._tcp.example.com.", 定义在[XMPP-CORE|XMPP文档列表/XMPP正式RFC标准/RFC3920].
:# 如果"xmpp-server"地址记录解析失败, 尝试解析"_im"或"_pres"\[SRV\]服务(定义在\[IMP-SRV\]), 使用"_im"服务用语<message/>节,使用"_pres"服务用语<presence/>节(如何处理<iq/>节取决于具体实现). 这样得到的结果是一个或多个格式为"_im.<proto>.example.com."或 "_pres.<proto>.example.com."的记录, 这里"<proto>"是一个注册在即时消息SRV协议标签注册表Instant Messaging SRV Protocol Label registry中的一个标签,或者是出席信息SRV协议标签注册表Presence SRV Protocol Label registry中的标签: 要么是"_xmpp",用于XMPP-aware的域,要么是一些 IANA注册的标签IANA-registered label (例如,"_simple") 用于 non-XMPP-aware 的域.
:# 如果这两种SRV地址记录解析都失败了, 尝试执行一个通用的 IPv4/IPv6 地址记录解析来决定IP地址,使用"xmpp-server"端口号5269(已在IANA注册, 定义在[XMPP-CORE|XMPP文档列表/XMPP正式RFC标准/RFC3920]).

:强烈鼓励部署服务器的管理员们保持 _im._xmpp, _pres._xmpp, 和 _xmpp._tcp SRV 记录正确同步, 因为不同的实现可能在"xmpp-server"查找之前执行"_im"和"_pres"查找.

==即时消息和出席信息兼容性需求==

:本章总结了即时消息和出席信息服务器和客户端为了保证兼容的实现而必须(MUST)支持的部分XMPP协议. 所有这些应用必须(MUST)遵守定义在[XMPP-CORE|XMPP文档列表/XMPP正式RFC标准/RFC3920]的要求. 本章的文字定义了附加的用于即时消息和出席信息的兼容性需求; 注意定义在这里的要求补充而不是替代核心需求. 也要注意一个服务器或客户端可以(MAY)仅支持出席信息或即时消息, 如果只想支持出席信息服务或即时消息服务,可以不必同时支持两个.

===服务器===

:除了核心服务器兼容需求之外, 一个即时消息和出席信息服务器必须(MUST)还要支持以下协议:

:* 定义在本文中的所有服务器相关的即时消息和出席信息语法和语义, 包括代替客户端广播出席信息, 出席信息订阅, 名册存储和处理, 隐私列表, 以及 IM-specific 路由和递送规则

===客户端===

:除了核心的客户端兼容性需求之外, 一个即时消息和出席信息客户端还必须(MUST)支持以下协议:

:* 生成和处理由XML规划定义的XML节的IM-specific语义, 包括消息和出席信息节以及它们的子元素的的'type'属性

:* 所有本文定义的客户端相关的即时消息语法和语义, 包括出席信息订阅, 名册管理, 和隐私列表

:* 端到端的对象加密(定义在 XMPP中的端到端对象加密End-to-End Object Encryption in the Extensible Messaging and Presence Protocol (XMPP) \[XMPP-E2E\])

:一个客户端也必须(MUST)处理编码为"im:" URIs的地址(定义在\[CPIM\]), 并且可以(MAY)移除"im:"scheme并把地址解析委托给服务器(定义在出站节Outbound Stanzas(第十一章第二节).

==国际化事项==

:关于国际化的考虑, 参考[XMPP-CORE|XMPP文档列表/XMPP正式RFC标准/RFC3920]相关章节.

==安全性事项==

:XMPP的核心安全性事项定义在[XMPP-CORE|XMPP文档列表/XMPP正式RFC标准/RFC3920]相关章节.

:附加的事项仅适用于分散定义在本文许多地方的XMPP即时消息和出席信息应用; 特别是:

:* 当一个服务器处理一个任何类型的入站节,这个节的预定接收者是和服务器的主机名相关的一个用户,服务器必须(MUST)首先强制应用任何隐私列表(第十章),见处理XML节的服务器规则Server Rules for Handling XML Stanzas(第十一章)).

:* 当一个服务器处理一个类型为"probe"的入站出席信息节,这个节的预定接收者是和服务器的主机名相关的一个用户, 如果这个发送者是一个由出席信息订阅决定的未被授权接收那个信息的实体,服务器不能(MUST NOT)揭露这个用户的出席信息(见客户端和服务器出席信息职责Client and Server Presence Responsibilities (第五章第一节)).

:* 当一个服务器处理一个任何类型的出站出席信息节,这个节没有type属性或type属性值为"unavailable", 为了确保这个出席信息不被广播给那些未被授权知道这个信息的实体, 它必须(MUST)服从客户端和服务器出席信息职责Client and Server Presence Responsibilities (第五章第一节) 定义的规则 .

:* 当一个服务器生成一个错误节作为不存在的用户接收到的一个节的应答的时候, 使用<service-unavailable/>错误条件有助于防止著名的字典攻击, 因为这个错误和条件和其他一些错误条件相同,例如, 一个IQ子元素的名字空间不被理解, 或离线存储或消息转发不被一个域允许.

==IANA事项==

:很多相关的IANA事项, 参考[XMPP-CORE|XMPP文档列表/XMPP正式RFC标准/RFC3920]相关章节.

===会话数据的XML名字空间名===

:以下为XMPP中会话相关的数据定义了一个 URN 子名字空间. (这个名字空间名的格式遵循 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>

===即时消息SRV协议标签注册===

:确定即时消息和出席信息地址[IMP-SRV],为那些能提供遵守"_im"SRV服务标签的服务定义了一个即时消息SRV协议标签注册表. 因为XMPP是其中一个协议, IANA在适当的注册项中注册了"_xmpp"协议标签,如下:

::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>

===出席信息SRV协议标签注册===

:确定即时消息和出席信息地址\[IMP-SRV\],为那些能够提供遵守"_pres"SRV服务标签的服务定义了一个出席信息SRV协议标签注册项. 因为XMPP是其中一个协议, IANA在适当的注册项中注册了"_xmpp"协议标签,如下:

::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>

==参考==

===标准参考===

:[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-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.

:[TERMS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.

:[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>.

:[XMPP-CORE|XMPP文档列表/XMPP正式RFC标准/RFC3920] 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.

===信息参考===

:[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.

:[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-0078] Saint-Andre, P., "Non-SASL Authentication", JSF JEP 0078, July 2004.

:[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.

:[XML-REG] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, January 2004.

==附录 A. vCards==

:[IMP-REQS]的第三章第一节第三小节和第四章第一节第四小节要求可能为其他用户接收带外的联系人信息(例如,电话号码或电子邮件地址). 在Jabber社区中通常使用RFC 2426 [VCARD]中vCard规范的XML来表达这类信息,但这超出了XMPP的范围(这个协议的文档包含在[JEP-0054], 由[JSF]发行).

译者注: [JSF]已改名为[XSF],[JEP-0054]已改名为[XEP-0054]

==附录 B. XML规划==

:接下来的XML规划是描述性的, 不是标准化的. 规划定义在XMPP的核心特性, 参考[XMPP-CORE|XMPP文档列表/XMPP正式RFC标准/RFC3920].

===B.1 jabber:client===

<source lang="xml">
<?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: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: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='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='presence'>
<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>

<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='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: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>
</source>

===B.2 jabber:server===

<source lang="xml">

<?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: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: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='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='presence'>
<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='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='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='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'
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>
</source>

===B.3 session===

<source lang="xml">
<?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:element name='session' type='empty'/>

<xs:simpleType name='empty'>
<xs:restriction base='xs:string'>
<xs:enumeration value=''/>
</xs:restriction>
</xs:simpleType>

</xs:schema>
</source>

===B.4 jabber:iq:privacy===

<source lang="xml">

<?xml version='1.0' encoding='UTF-8'?>

<xs:schema
xmlns:xs='http://www.w3.org/2001/XMLSchema'
targetNamespace='jabber:iq:privacy'
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='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='list'>
<xs:complexType>
<xs:sequence>
<xs:element ref='item'
minOccurs='0'
maxOccurs='unbounded'/>
</xs:sequence>
<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:simpleType name='empty'>
<xs:restriction base='xs:string'>
<xs:enumeration value=''/>
</xs:restriction>
</xs:simpleType>

</xs:schema>
</source>

===B.5 jabber:iq:roster===

<source lang="xml">

<?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: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: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:schema>
</source>

==附录 C. Jabber IM Presence协议和XMPP之间的不同==

:本章是非标准的.

:译者注：附录D对于新接触XMPP的人没有什么意义，就不翻译了，免得浪费时间。因为现在RFC公布已经很久了，以前的Jabber实现很多都进化到XMPP了。

: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|XMPP文档列表/XMPP正式RFC标准/RFC3920] summarizes the differences that relate to all XMPP applications.

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

===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.

==贡献者==

:XMPP的大部分核心方面是由1999年开始的Jabber开源社区开发的. 这个社区是由 Jeremie Miller建立的, 他于1999年1月发布了最初版的jabber server源代码. 主要的基础协议的早期贡献者还包括 Ryan Eatmon, Peter Millard, Thomas Muldowney,和 Dave Smith. XMPP工作组在即时消息和出席信息方面的工作主要集中在IM会话建立和通信屏蔽(隐私列表); 会话建立协议主要是由 Rob Norris 和 Joe Hildebrand 开发的, 隐私列表协议最初是由 Peter Millard.贡献的

==致谢==

:感谢许多在贡献者名单之外的人们. 尽管很难提供一个完整的名单, 以下个人对于定义协议或评论标准提供了很多帮助:
: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. 也感谢 XMPP工作组的成员和 IETF 社区在本文的成文过程中一直提供的评论和反馈。

==作者地址==

:Peter Saint-Andre (编辑)
:Jabber Software Foundation

:EMail: stpeter@jabber.org

==完整的版权声明==

: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 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.

==知识产权==

: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.

: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.

==感谢==

:目前为RFC编辑活动提供资金的Internet Society.

RFC3921

2010-05-31T08:37:00Z

Fantasysoft: /* XML 节的语法 */

[[Category:XMPP正式RFC标准]]
[[Category:已翻译]]

本文的英文原文来自[http://www.ietf.org/rfc/rfc3921.txt RFC 3921]

{|
|网络工作组 || Saint-Andre, Ed.
|-
|申请讨论: 3921 || Jabber软件基金会
|-
|类别: 标准跟踪 || 2004年10月
|}

::::'''可扩展的消息和出席信息协议 (XMPP): 即时消息和出席信息'''

'''关于本文的说明'''

:本文为互联网社区定义了一个互联网标准跟踪协议，并且申请讨论协议和提出了改进的建议。请参照“互联网官方协议标准”的最新版本（STD 1）获得这个协议的标准化进程和状态。本文可以不受限制的分发。

'''版权声明'''

:本文版权属于互联网社区 (C) The Internet Society (2004).

'''摘要'''

:本文定义了可扩展消息和出席信息协议（XMPP）的核心功能的扩展和应用，XMPP提供了RFC 2779 定义的基本的即时消息和出席信息功能。

==绪论==

===概览===

:XMPP是一个流化XML[XML]元素的协议，用于准实时的交换消息和出席信息。XMPP的核心功能定义在Extensible Messaging and Presence Protocol (XMPP): Core [XMPP-CORE|XMPP文档列表/XMPP正式RFC标准/RFC3920]. 这些功能 -- 主要是 XML流, 使用 TLS和SASL,以及流的根元素之下的<message/>, <presence/>, 和 <iq/> 子元素 -- 为各种类型的准实时应用提供了一个构造基础, 它可以被放在核心的顶层，使用特定XML名字空间[XML-NAMES]发送特定的应用数据. 本文描述XMPP核心功能的扩展和应用，XMPP核心功能提供了RFC 2779 [IMP-REQS]定义的基本的即时消息和出席信息功能。

===需求===

:为了达到本文的目的, 基本的即时消息和出席信息应用的需求定义在[IMP-REQS],它是一个高阶的规定,一个用户必须完成以下用例:

:*和其他用户交换消息
:*和其他用户交换出席信息
:*管理和其他用户之间的订阅和被订阅
:*管理联系人列表中的条目(在 XMPP 中这被称为 "roster")
:*屏蔽和特定的其他用户之间的通信（出或入）

:这些功能领域的详细定义在[IMP-REQS]中, 感兴趣的用户可以直接阅读原文关于需求方面的内容。

:[IMP-REQS]也规定出席信息服务必须从即时消息服务中分离; 例如, 它必须可能用这个协议来提供一个出席信息服务,一个即时消息服务,或同时提供两者. 尽管本文假定实现和部署希望提供统一的即时消息和出席信息服务, 但没有要求一个服务必须同时提供出席信息服务和即时消息服务, 并且协议也提供了把出席信息服务和即时消息服务分离成为独立服务的可能性.

:注意: 虽然基于XMPP的即时消息和出席信息符合[IMP-REQS]的要求,但它不是特意为那个协议设计的,因为基础协议是在RFC 2779成文之前通过Jabber开放源代码社区的一个开放的开发过程发展出来的. 也请注意尽管在Jabber社区发展的协议中定义了许多其他方面的功能,但是这些协议不包含在本文之中,因为它们不是[IMP-REQS]所要求的.

===术语===

:本文继承了 [XMPP-CORE|XMPP文档列表/XMPP正式RFC标准/RFC3920]定义的术语.

:大写关键字 "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 和 "OPTIONAL" 在本文中的含义定义在 BCP 14, RFC 2119 \[TERMS\].

==XML 节的语法==

:符合'jabber:client'和'jabber:server'名字空间的XML节的基本语义和通用属性已经在[XMPP-CORE|XMPP文档列表/XMPP正式RFC标准/RFC3920]中定义了. 无论如何, 这些名字空间也定义了一些其他的子元素, 比如通用属性'type'的值, 对于即时消息和出席信息应用就是特殊的. 因而, 在选择用于这类应用的特定用例之前, 我们在这里需要先描述一下XML节的语法, 用来补充[XMPP-CORE|XMPP文档列表/XMPP正式RFC标准/RFC3920]中的讨论.

===消息语法===

:符合'jabber:client' or 'jabber:server'名字空间的消息节用于"推" 信息到另一个实体. 在即时消息应用中通常的用法是包含，一个单独的消息,在一个聊天会话中的消息，一个多用户聊天室的上下文中的消息，标题或其他警告和错误的消息,

====消息的类型====

:一个消息节的'type' 属性是建议的(RECOMMENDED); 如果包含了它,它指明这个消息的会话上下文,从而提供一个关于表达的线索(例如, 在一个GUI中). 如果包含了它, 'type' 属性必须(MUST)是以下的值之一 :

:*chat -- 消息是在一对一聊天会话的语境被发送. 一个兼容的客户端应该(SHOULD)在一个允许两个实体进行一对一聊天的界面中显示消息,包括适当的会话历史.

:*error -- 发生了一个和上次发送者发送的消息有关的错误(关于节错误语法的详细信息, 参考 [XMPP-CORE|XMPP文档列表/XMPP正式RFC标准/RFC3920]). 一个兼容客户端应该(SHOULD)在一个适当的界面展示它以通知发送者这个错误的种类.

:*groupchat -- 消息是在一个多用户聊天环境的语境下发送的(类似\[IRC\]). 一个兼容客户端应该(SHOULD)在允许多对多聊天的界面显示这个消息,包括, 包括这个聊天室的名册和适当的会话历史. 基于XMPP的群聊协议的完整定义超出了本文的范围.

:*headline -- 一个消息可能是由一个递送或广播内容的自动化服务生成的(新闻, 体育, 市场信息, RSS feeds, 等等.). 这个消息是不需要回复的, 一个兼容客户端应该(SHOULD) 在一个适当的和单独消息,聊天会话,或群聊会话不同的界面显示这个消息(例如, 不给接收者提供回复能力).

:*normal -- 这个消息是一个在一对一会话或群聊会话之外的单独消息, 并且它希望接收者能够回复.一个兼容客户端应该(SHOULD)在一个允许接收者回复的界面显示这个消息, 但不需要会话历史.

:一个 IM 应用应该(SHOULD)支持所有前述的消息类型;如果一个应用接收了一个没有'type'属性的消息或这个应用不理解'type'属性的值, 它必须(MUST)认为这个消息是一个 "normal" 类型(如,"normal" 是缺省的). "error"类型必须(MUST)仅仅在应答一个和从别的实体接收到的消息有关的错误时生成.

:尽管'type'属性是可选的(OPTIONAL), 处于礼貌原因对于消息的任何回复总是和原来的消息同一类型;此外, 一些特殊的应用(例如, 一个多用户聊天服务) 可以(MAY)根据它们的判断强制特定消息类型的使用(例如, type='groupchat').

====子元素====

:正如扩展名字空间extended namespaces(第二章第四节)所述, 一个消息节可以(MAY)包含任何适当名字空间的子元素.

:和缺省名字空间声明一致, 缺省消息节的名字空间是'jabber:client' 或 'jabber:server', 定义了某几个允许的消息节的子元素. 如果消息节的类型是 "error", 它必须(MUST)包含一个<error/>子元素; 详细情况, 见[XMPP-CORE|XMPP文档列表/XMPP正式RFC标准/RFC3920]. 否则, 消息节可以(MAY)包含以下子元素的任何一种并且无需显式地声明名字空间:

:#<subject/>
:#<body/>
:#<thread/>

=====主题=====

:<subject/> 元素包含了人类可读的 XML 字符数据指明这个消息的主题. <subject/>元素不能(MUST NOT)拥有任何属性, 除了'xml:lang'属性. <subject/> 元素可以(MAY)包含多个实例用于为同一主题提供备用版本, 但是仅在每个实例的拥有的'xml:lang'属性的值互不相同的时候才可以. <subject/> 元素不能(MUST NOT)包含混合的内容(定义在 \[XML\]第三章第二节第二小节).

=====主体=====

:<body/> 元素包含人类可读的XML字符数据表达消息的文本内容; 这个子元素通常会有但是是可选的(OPTIONAL). <body/>元素不能(MUST NOT)拥有任何属性, 除非是'xml:lang'属性. <body/> 元素可以(MAY)包含多个实例用于为同一主体提供备用版本, 但是仅在每个实例的拥有的'xml:lang'属性的值互不相同的时候才可以. <body/>元素不能(MUST NOT)包含混合的内容(定义在 \[XML\]第三章第二节第二小节).

=====线索=====

:<thread/> 元素包含非人类可读的XML字符数据表达一个标识符用于跟踪两个实体之间的一个会话线索(有时相当于一个"即时消息会话"). <thread/>元素的值是由发送者生成的并且应该(SHOULD)在任何回复中拷贝回来. 如果使用了它, 它必须(MUST)在这个流的会话线索中是唯一的并且必须(MUST)和那个会话相一致(一个从同一个全JID但不同线索ID接收到消息的客户端必须(MUST)假定这个有问题的消息存在于已有的会话线索之外. <thread/>元素的使用是可选的(OPTIONAL)并且不是用于标识独立的消息,而是标识会话. 一个消息节不能(MUST NOT)包含超过一个的<thread/>元素. <thread/>元素不能(MUST NOT)拥有任何属性. <thread/>属性的值必须(MUST)被实体处理成不透明的; 不能从它得到任何语义学上的含义,并且只能对它做精确的比较. <thread/>元素不能(MUST NOT)包含混合内容(定义在 [XML]第三章第二节第二小节).

===出席信息语法===

:符合'jabber:client' 或 'jabber:server'名字空间的出席信息节用于表达一个实体当前的网络可用性(离线或在线, 包括之后的各种亚状态和可选的用户名义的描述性文本), 并且通知其他实体它的可用性. 出席信息节也用于协商和管理对于其他实体的出席信息的订阅.

====出席信息的类型====

:出席信息节的'type'属性是可选的(OPTIONAL). 一个不拥有任何'type'属性的出席信息节用来通知服务器发送者已经在线并且可以进行通信了, 'type' 属性表示缺乏可用性, 请求管理对其他实体的出席信息的订阅, 请求其他实体的当前出席信息, 或发生了和上次发出的出席信息节有关的错误. 如果包含了它, 'type'属性必须(MUST)拥有以下值之一:

:*unavailable -- 通知实体将不可通信.

:*subscribe -- 发送者希望订阅接收者的出席信息.

:*subscribed -- 发送者允许接收者接收他们的出席信息.

:*unsubscribe -- 发送者取消订阅另一个实体的出席信息.

:*unsubscribed -- 订阅者的请求被拒绝或以前的订阅被取消.

:*probe -- 对一个实体当前的出席信息的请求; 只应(SHOULD)由服务器代替一个用户生成.

:*error -- 处理或递送之前发送的出席信息节的时候发生了错误.

:关于出席信息语义学的详细信息和基于XMPP的即时消息和出席信息应用程序的订阅模式,参考交换出席信息Exchanging Presence Information(第五章) 和管理订阅Managing Subscriptions(第六章).

====子元素====

:如扩展名字空间extended namespaces(第二章第四节)所述, 一个出席信息节可以(MAY)包含任何适当名字空间的子元素.

:和缺省名字空间声明一致, 缺省出席信息节的名字空间是'jabber:client' 或 'jabber:server', 定义了某几个允许的出席信息节的子元素. 如果出席信息节的类型是 "error", 它必须(MUST)包含一个<error/>子元素; 详细情况, 见[XMPP-CORE|XMPP文档列表/XMPP正式RFC标准/RFC3920]. 如果出席信息节不拥有'type'属性,它可以(MAY)包含以下任何子元素(注意<status/>子元素可以(MAY)在一个类型为"unavailable"或"subscribe"(出于历史原因)的出席信息中被发送):

:#<show/>
:#<status/>
:#<priority/>

=====展示=====

:可选的(OPTIONAL)<show/>元素包含非人类可读的XML字符数据表达一个特定的实体或资源的特定的可用性状态. 一个出席信息节不能(MUST NOT)包含多于一个<show/>元素. <show/>元素不能(MUST NOT)拥有任何属性. 如果提供了, 这个XML字符数据值必须(MUST)是以下之一(额外的可用性类型可以通过出席信息的适当名字空间来定义):

:*away -- 实体或资源临时离开.

:*chat -- 实体或资源在聊天中是激活的.

:*dnd -- 实体或资源是忙(dnd = "不要打扰").

:*xa -- 实体或资源是长时间的离开(xa = "长时间离开").

:如果没有提供<show/>元素, 实体被假定是在线和可用的.

=====状态=====

:可选的(OPTIONAL)<status/>元素包含XML字符数据表达一个可用性状态的自然语言描述. 它通常用于联合show元素以提供可用性状态的详细描述(例如, "会议中"). <status/>元素不能(MUST NOT)拥有任何属性,除了'xml:lang'属性. <status/>元素可以(MAY)包含多个实例但是每个实例的'xml:lang'属性值必须各不相同.

=====优先权=====

:可选的(OPTIONAL)<priority/>元素包含非人类可读的XML字符数据指明资源的优先级别. 这个值必须(MUST)是一个介于-128和+127之间的数字. 一个出席信息小节不能(MUST NOT)包含超过一个的<priority/>元素. <priority/>元素不能(MUST NOT)拥有任何属性. 如果没有优先权被提供,一个服务器应该(SHOULD)认为优先级是零. 关于即时消息和出席信息系统中节路由的优先级的语义, 参考处理XML节的服务器规则Server Rules for Handling XML Stanzas(第十一章).

===IQ语法===

:IQ节提供一个结构化的请求-应答机制. 这个机制的基本语义学(例如, 'id'属性是必需的(REQUIRED))定义在[XMPP-CORE|XMPP文档列表/XMPP正式RFC标准/RFC3920], 然而完成特定用例所需要的特定语义的所有案例定义在扩展名字空间extended namespace(第二章第四节)之中(注意'jabber:client'和'jabber:server'名字空间没有定义除通用的<error/>子元素之外的任何IQ节子元素). 本文定义了两个这样的名字空间,一个用于名册管理Roster Management(第七章)而另一个用于屏蔽通信Blocking Communication(第十章); 无论如何, 一个IQ节可以(MAY)包含符合任何扩展名字空间的结构化信息.

===扩展名字空间===

:因为在"jabber:client"或"jabber:server"名字空间中定义的三个XML节类型(也包括它们的属性和子元素)提供了一个基本功能级用于消息和出席信息, XMPP使用XML名字空间来扩展节用于提供额外的功能, 所以一个消息或出席信息节可以(MAY)包含一个或更多可选的子元素表达扩展消息含义的内容(例如, 一个XHTML格式版本的消息主体), 并且一个IQ节可以(MAY)包含一个这样的子元素. 这个子元素可以(MAY)有任何名字并且可以(MUST)拥有一个'xmlns'名字空间声明(不同于"jabber:client", "jabber:server", 或"http://etherx.jabber.org/streams")定义所有包含在子元素中的数据.

:对于任何特定的扩展名字空间的支持在任何实现中的一部分是可选的(OPTIONAL)(除了在这里定义的扩展名字空间以外). 如果一个实体不理解这样一个名字空间, 实体被期望的行为依赖于这个实体是(1) 接收者或 (2) 一个正在路由到接收者的实体

:接收者: 如果一个接收者接收了一个包含不理解的子元素的节, 它应该(SHOULD)忽略那个特定的XML数据,例如, 它应该(SHOULD)不处理它或不向用户或相关的应用程序(如果有的话)显示它. 具体来说:

::*如果一个实体接收了一个消息或出席信息节包含一个不理解的名字空间, 在节的未知名字空间的这部分应该(SHOULD)被忽略.

::*如果一个实体接收了一个消息节中仅有的一个子元素是不理解的, 它必须(MUST)忽略整个节.

::*如果一个实体接收了一个类型"get"或"set"的IQ节包含一个不理解的子元素, 这个实体应该(SHOULD)返回一个类型为"error"的<service-unavailable/>错误条件的IQ节.

:路由: 如果一个路由实体(通常是一个服务器)处理一个包含它不理解的子元素的节, 它应该(SHOULD)原封不动地把它转给接收者而忽略相关的XML数据.

==会话的建立==

:绝大部分基于XMPP的消息和出席信息应用是由一个客户端-服务器体系结构实现的,为了参加期望的即时消息和出席信息活动,需要客户端在服务器上建立一个会话. 无论如何, 在客户端能够建立一个即时消息和出席信息会话之前有很多前提必须(MUST)满足. 它们是:

:#流验证 -- 客户端在尝试建立一个会话或发送任何XML节之前必须(MUST)完成[XMPP-CORE|XMPP文档列表/XMPP正式RFC标准/RFC3920]中定义的流验证.
:#资源绑定 -- 完成流验证之后, 一个客户端必须(MUST)绑定一个资源到流上,使得客户端的地址符合<user@domain/resource>格式, 然后实体以[XMPP-CORE|XMPP文档列表/XMPP正式RFC标准/RFC3920]规定的术语来说就是一个已连接的资源"connected resource".

:如果一个服务器支持会话, 在完成一个[XMPP-CORE|XMPP文档列表/XMPP正式RFC标准/RFC3920]定义的流验证之后它必须(MUST)在它向客户端声明的流特性中包含一个符合'urn:ietf:params:xml:ns:xmpp-session'名字空间的<session/>元素:

:服务器向客户端声明会话确定特性:

<source lang="xml">
<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>
</source>

:收到需要会话确立的通知之后(并且是在完成资源绑定之后), 客户端如果想使用即时消息和出席信息功能必须(MUST)建立一个会话; 它向服务器发送一个符合'urn:ietf:params:xml:ns:xmpp-session'名字空间的类型为"set"并包含空的<session/>子元素的IQ节以完成这一步骤:

:步骤 1: 客户端向服务器请求会话:

<source lang="xml">
<iq to='example.com'
type='set'
id='sess_1'>
<session xmlns='urn:ietf:params:xml:ns:xmpp-session'/>
</iq>
</source>

:步骤 2: 服务器通知客户端会话已经建立:

<source lang="xml">
<iq from='example.com'
type='result'
id='sess_1'/>
</source>

:建立会话之后, 一个已连接的资源([XMPP-CORE|XMPP文档列表/XMPP正式RFC标准/RFC3920]术语)就被称为一个激活的资源"active resource".

:许多错误条件是可能的. 例如, 服务器可能遭遇一个内部条件阻碍了它建立会话, 用户名或授权身份可能缺乏建立会话的许可, 或同一个名字相关的这个资源ID已经有一个激活的资源.

:如果服务器遭到一个内部条件阻碍了它建立会话, 它必须(MUST)返回一个错误.

:步骤 2 (替代): 服务器应答一个错误(内部服务器错误):

<source lang="xml">
<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>
</source>

:如果用户名或资源不被允许建立一个会话, 服务器必须(MUST)返回一个错误(例如, 被禁止).

:步骤 2 (替代): 服务器应答错误(用户名或资源不被允许建立一个会话):

<source lang="xml">
<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>
</source>

:如果已经同一名字已经存在一个激活的资源,服务器必须(MUST) (1) 终止这个激活的资源并允许新请求的会话, 或者 (2) 不允许新申请的会话并继续激活的资源. 服务器做哪一步取决于具体的实现, 尽管建议的(RECOMMENDED)实现情景 #1. 在情景 #1, 服务器应该(SHOULD)发送一个<conflict/>流错误给激活的资源, 终止用于这个激活的资源的XML流和相关的TCP连接, 并返回一个类型为"result" 的IQ节(表示成功)给新申请的会话. 在情景 #2, 服务器应该(SHOULD)发送一个<conflict/>节错误给新申请的会话但是继续那个连接的XML流使得新申请的会话在发送另一个会话建立申请之前有机会协商出一个不冲突的资源ID.

:步骤 2 (替代): 服务器通知现有的激活的资源资源冲突(情景 #1):

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

:步骤 2 (替代): 服务器通知新申请的的会话资源冲突(情景 #2):

<source lang="xml">
<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>
</source>

:建立一个会话之后, 客户端应该(SHOULD)按以下描述来发送初始化出席信息并请求它的名册, 尽管这些动作是可选的(OPTIONAL).

:注意: 在允许建立即时消息和出席信息会话之前, 一个服务器可能(MAY)需要先提供帐号. 可能的提供帐号的方法包括由服务器管理员新建帐号以及使用'jabber:iq:register'名字空间进行带内帐号注册; 后一个方法超出了本文的范围, 但是记录在\[JEP-0077\]（译者注：这个协议已改名为 XEP-0077）, 由 Jabber Software Foundation \[JSF\]发行（译者注：这个组织也已改名为XSF）.

==交换消息==

:交换消息是XMPP的一个基本用途并且随之而来的是一个用户生成一个发给另一个实体的消息节. 正如用于处理XML节的服务器规则Server Rules for Handling XML Stanzas(第十一章)中所定义的 , 发送者的服务器负责递送消息给预定的接收者(如果接收者在同一个服务器上)或路由消息给接收者的服务器(如果接收者在不同的服务器上).

:关于消息节的语法和它们已定义的属性和子元素信息, 参考消息语法Message Syntax(第二章第一节).

===指明一个预定的接收者===

:一个即时消息客户端应该(SHOULD)通过提供一个JID或<message/>节中不同于发送者的'to'属性来指定一个消息的预定接收者. 如果这个消息是在回复之前接收到的消息,而接收到的消息是从JID格式为<user@domain/resource>(例如,在一个聊天会话的上下文中)实体发来的, 这个回复消息的'to'地址的值应该(SHOULD)是<user@domain/resource>而不是<user@domain>,除非发送者知道(通过出席信息)预定的接收者的资源将不再可用. 如果消息是在任何现存的聊天会话或接收到的消息之外被发送的,'to'地址的值应该(SHOULD)格式为<user@domain>而不是<user@domain/resource>.

===指定一个消息类型===

:大家知道, 对于一个消息节来说拥有'type'属性(它的值代表了消息的会话上下文(参见 Type(第二章第一节第一小节)))是建议的(RECOMMENDED).

:以下例子展示一个'type'属性的合法值:

:例子: 一个已定义类型的消息:

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

===指定一个消息主体===

:一个消息节可以(MAY)(并且经常会)包含一个<body/>子元素,它的XML字符数据表达消息的主要含义(见 Body(第二章第一节第二小节第二小小节)).

:例子: 一个带主体的消息:

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

===指定一个消息主题===

:一个消息节可以(MAY)包含一个或多个<subject/>子元素指明消息的主题(见 Subject(第二章第一节第二小节第一小小节)).

:例子: 一个带主题的消息:

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

===指定一个会话线索===

:一个消息可以(MAY)包含一个<thread/>子元素指定消息处于哪个会话线索, 用于跟踪会话(见 Thread(第二章第一节第二小节第三小小节)).

:例子: 一个带线索的会话:

<source lang="xml">
<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>
<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>
<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>
</source>

==交换出席信息==

:交换出席信息通过使用出席信息节直接和XMPP相关. 无论如何, 我们看到在这里和消息处理形成一个对比:尽管一个客户端可以(MAY)通过包含一个'to'地址直接给另一个实体发送出席信息, 通常出席信息通知(例如,不包含'type'的或类型为"unavailable"的并且没有'to'地址的出席信息节) 被客户端发送给它的服务器然后由服务器广播给任何订阅了发送实体的出席信息的实体(在 RFC 2778 \[IMP-MODEL\]术语中, 这些实体称为订阅者). 这个广播模式不适用于和订阅相关的节或类型为"error"的出席信息, 而仅适用于以上定义的出席信息通知. (注意: 虽然出席信息可以(MAY)由一个自动化服务代替用户提供, 通常它还是由用户的客户端提供.)

:关于出席信息节的语法以及它们的已定义的属性和子元素的信息, 参考[XMPP-CORE|XMPP文档列表/XMPP正式RFC标准/RFC3920].

===客户端和服务器出席信息职责===

====初始化出席信息====

:建立起一个会话之后, 一个客户端应该(SHOULD)发送初始化出席信息给服务器来通知它的通信可用性.如这里定义的, 初始化出席信息节 (1) 必须(MUST) 不拥有'to'地址(这表示它是由服务器代替客户端发送的广播) 并且 (2) 必须(MUST) 不拥有'type'属性(者表示拥护的可用性). 在发送初始化出席信息之后, 一个激活的资源被称为可用的资源"available resource".

:从一个客户端接收到初始化出席信息之后, 如果这个用户没有一个或更多的已存在的可用资源(如果这个用户已经有一个或更多可用的资源, 服务器明显不需要发送出席信息探测, 因为它已经拥有需要的信息),用户的服务器必须(MUST)做以下的步骤:

:#从用户的全JID(例如,<user@example.com/resource>)发送出席信息探针(例如, 'type'属性值为'probe'的出席信息节)给已被这个用户订阅了的所有联系人以确定它们是否可用; 这些联系人就是那些显示在用户的名册中的JID并且'subscription'属性值为"to"或"both"(注意: 用户的服务器不能(MUST NOT)发送出席信息探针给用户已经屏蔽入站出席信息通知的联系人, 具体的描述在屏蔽入站出席信息通知Blocking Inbound Presence Notifications(第十章第十节).)
:#从用户的全JID (e.g.,<user@example.com/resource>)广播初始化出席信息给所有订阅了该用户的出席信息的联系人; 这些联系人就是那些显示在用户的名册中的JID并且'subscription'属性值为"from"或"both"(注意: 用户的服务器不能(MUST NOT)发送出席信息探针给用户已经屏蔽出站出席信息通知的联系人, 具体的描述在屏蔽出站出席信息通知Blocking Outbound Presence Notifications(第十章第十一节).)

:另外, 用户的服务器必须(MUST)从用户的新的可用的资源向用户任何现存的可用的资源(如果有的话)广播初始化出席信息.

:从用户接收到初始化出席信息之后, 联系人的服务器必须(MUST)递送这个用户的出席信息节给所有联系人的可用资源相应的全JID(<contact@example.org/resource>), 但是仅适用于用户在联系人名册中并且订阅状态为"to"或"both"并且联系人的纯JID或全JID没有被屏蔽入站出席信息通知(定义在屏蔽入站出席信息通知Blocking Inbound Presence Notifications(第十章第十节)).

:如果用户的服务器接收到一个类型为"error"的出席信息节,而这个节是用来回复服务器代替用户向联系人发送的初始化出席信息, 它不应该(SHOULD NOT)发送更多的出席信息更新给那个联系人(直到并且除非它从这个联系人接收到一个出席信息节).

====出席信息广播====

:发送初始化出席信息之后, 用户可以(MAY)在任何时候更新它的出席信息,方法是在会话期间发送一个没有'to'地址也没有'type'属性的出席信息节或'type'属性值为"unavailable"的出席信息节.(注意:一个用户的客户端不应该(SHOULD NOT)发送一个出席信息更新来自行广播用户出席信息和可用性的改变信息.)

:如果出席信息节缺乏'type'属性(例如, 表达可用性), 用户的服务器必须(MUST)广播那个出席信息节的全XML给所有联系人(满足以下三点) (1) 它们在用户的联系人名册中并且订阅类型是"from"或"both", (2) 用户对于这些联系人没有屏蔽出站出席信息通知, 并且 (3) 服务器在用户的会话期间没有从它们那里接收到出席信息错误(同样适用于这个用户的其他可用的资源).

:如果出席信息节的'type'属性值是"unavailable", 用户的服务器必须(MUST)广播那个出席信息节的全XML给所有符合以上描述的实体, 也适用于用户曾经在会话过程中直接发送了可用出席信息的任何实体(如果用户还没来得及直接发送不可用出席信息给那个实体).

====出席信息调查====

:从用户接收到一个出席信息调查之后, 联系人的服务器应该(SHOULD)应答如下:

:#如果用户联系人的名册中的状态不是 "From", "From + Pending Out", 或 "Both" (定义在订阅状态Subscription States(第九章)), 联系人的服务器必须(MUST)返回一个类型为"error"的出席信息节应答这个出席信息调查 (无论如何, 如果一个服务器从这个服务器的主机名的子域或其他信任的服务接收到一个出席信息调查, 它可以(MAY)提供这个用户的出席信息给那个实体). 具体来说:
:##如果用户在联系人的名册中的订阅状态是 "None", "None + Pending Out", 或 "To" (或根本不在联系人的名册中), 联系人的服务器必须(MUST)返回一个<forbidden/>节错误应答这个出席信息调查.
:##如果用户在联系人的名册中的订阅状态是 "None + Pending In", "None + Pending Out/In", 或 "To + Pending In", 联系人的服务器必须(MUST)返回一个<not-authorized/>节错误应答这个出席信息调查.
:#其次, 如果联系人对这个用户的纯JID或全JID屏蔽了出席信息通知(使用缺省列表或激活列表,定义在屏蔽出站出席信息通知Blocking Outbound Presence Notifications (第十章第十一节)), 服务器不能(MUST NOT)应答这个出席信息调查.
:#然后, 如果联系人没有可用的资源, 服务器必须(MUST) 要么 (1) 应答这个出席信息调查, 向这个用户发送服务器从联系人接收到的最后的类型为"unavailable"的出席信息节的全XML, 或 (2) 不应答.
:#最后, 如果联系人至少有一个可用的资源, 服务器必须(MUST)应答这个出席信息调查, 向这个用户发送服务器从联系人的每一个可用的资源收到的最后的没有'to'属性的出席信息节的全XML (再一次的,对于每一个会话都要强制服从隐私列表).

====直接出席信息====

:一个用户可以(MAY)直接发送出席信息给另一个实体 (例如, 一个出席信息节,包含'to'属性并且值为另一个实体的JID并且没有'type'属性或'type'属性值为"unavailable"). 可能出现三种情形:

:#如果用户在已经发送过初始化出席信息广播之后,发送不可用信息广播之前,直接发送出席信息给它的名册中一个订阅状态为"from" 或 "both"的联系人, 这个用户的服务器必须(MUST)路由或递送这个出席信息节的全XML(服从隐私列表)但是不应该(SHOULD NOT) 根据出席信息广播修改联系人的状态(例如, 它应该(SHOULD)在任何接下来的由用户初始化的出席信息广播包含这个联系人的JID).
:#如果用户在已经发送过初始化出席信息广播之后,发送不可用信息广播之前,直接发送出席信息给一个不在用户名册中的实体并且其订阅状态为"from" 或 "both", 这个用户的服务器必须(MUST)路由或递送这个出席信息节的全XML(服从隐私列表)但是不能(MUST NOT) 根据可用性的出席信息广播来修改这个联系人的状态(例如, 它不能(MUST NOT)在任何接下来的由用户初始化的可用性的出席信息广播中包含这个联系人的JID); 无论如何, 如果无法从用户的可用的资源直接发送出席信息, 用户的服务器必须( MUST)广播不可用出席信息给那个实体(如果这个用户还没有直接发送不可用出席信息给那个实体).
:#如果用户不是在已经发送过初始化出席信息广播之后,或在发送不可用信息广播之前,直接发送出席信息(例如, 资源激活了但是还不可用), 用户的服务器必须(MUST)认为用户向其直接发送出席信息的这个实体视为上述第二种情形中的那个实体,采用相同的处理方式.

====不可用出席信息====

:在和一个服务器结束它的会话之前, 客户端应该(SHOULD)雅致地成为不可用的,发送一个最后的没有'to'属性并且'type'属性值为"unavailable"的出席信息节(可选的, 最后的出席信息节可以(MAY)包含一个或多个<status/>元素以指明为什么用户不再可用). 无论如何, 用户的服务器不能(MUST NOT)依赖于从一个可用的资源接收最后的出席信息, 因为资源可能意外的变成不可用或可能被服务器判定超时. 如果用户的资源之一因为任何原因成为不可用的(包括雅致的或粗鲁的), 用户的服务器必须(MUST)广播不可用出席信息给所有如下的联系人 (1) 在用户的名册中并且订阅类型为 "from" 或 "both", (2) 用户没有对它们屏蔽出站出席信息的联系人, 以及 (3) 用户会话期间,服务器没有从它们那里收到出席信息错误的联系人; 用户的服务器也必须(MUST)发送不可用出席信息节给这个用户的任何其他可用的资源, 以及任何用户的资源曾经在会话期间直接向其发送过出席信息的实体(如果用户还没有直接发送不可用出席信息给那个实体). 在直接发送或广播不可用出席信息之后发送的任何没有'type'属性也没有'to'属性的出席信息节必须(MUST)由服务器广播给所有订阅者.

====出席信息订阅====

:一个订阅请求就是一个'type'属性值为"subscribe"的出席信息节. 如果订阅请求被发送给一个即时消息联系人, 在'to'属性中提供的JID的格式应该(SHOULD)是<contact@example.org>而不是<contact@example.org/resource>, 因为用户期望的结果通常是从联系人的所有资源接收到出席信息, 而不仅是'to'属性中的特定资源.

:一个用户的服务器不能(MUST NOT)代替用户自动批准订阅请求. 所有订阅申请必须(MUST)直接发给用户的客户端, 具体来说就是这一用户的一个或多个可用的资源. 如果当订阅申请被用户的服务器接收到的时候没有这个用户的可用资源, 用户的服务器必须(MUST)保持这个订阅申请的记录并且在用户下次建立一个可用的资源时递送这个订阅申请, 直到这个用户批准或拒绝这个请求. 如果如果当订阅申请被用户的服务器接收到的时候这个用户有多于一个的可用资源, 用户的服务器必须(MUST)广播这个订阅申请给所有可用的资源(根据处理XML节的服务器规则Server Rules for Handling XML Stanzas(第十一章)). (注意: 如果一个激活的资源还没有提供初始化出席信息, 服务器不能(MUST NOT)认为它是可用的并且因而不能(MUST NOT)发送订阅申请给它.) 无论如何, 如果用户从一个它已授权可以看到用户的出席信息的联系人那里收到一个类型为"subscribe"的出席信息节(例如, 当一个联系人重新同步订阅状态的时候),用户的服务器应该(SHOULD)代替用户自动应答. 另外, 用户的服务器可以(MAY)基于一个特定实现的法则(例如, 无论何时当用户的一个新的资源可用的时候, 或在一段特定长度的时间过去之后)选择重新发送一个未批准的未决订阅申请给这个联系人; 这有助于恢复可能和原始订阅申请有关的瞬间的,无声的错误.

===指明可用性状态===

:一个客户端可以(MAY)使用<show/>元素提供关于可用性状态的更多信息(参见 Show (第二章第二节第二小节第一小小节)).

:例子: 可用性状态:
<source lang="xml">
<presence>

<show>dnd</show>

</presence>
</source>

===指明详细的可用性状态信息===

:通过联合<show/>元素, 客户端使用<status/>元素可以(MAY)提供详细的可用性状态信息(参见Status (第二章第二节第二小节第二小小节)).

:例子: 详细的状态信息:

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

===指明出席信息优先级===

:客户端可以(MAY)使用<priority/>元素为它的资源提供优先级(参见 Priority (第二章第二节第二小节第三小小节)).

:例子: 出席信息优先级:

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

===出席信息例子===

:本章的例子用于阐明上述和出席信息相关的协议. 用户是 romeo@example.net, 他有一个可用的资源, 资源ID为 "orchard", 并且他的名册中有以下这些人:

:*juliet@example.com (subscription="both" 并且她有两个可用的资源, 一个资源名为"chamber" 而另一个资源名为 "balcony")

:*benvolio@example.org (subscription="to")

:*mercutio@example.org (subscription="from")

:例子 1: 用户发送初始化出席信息:

<source lang="xml">
<presence/>
</source>

:例子 2: 用户的服务器代替用户发送出席信息调查给 subscription="to" 和 subscription="both" 的联系人的可用资源:

<source lang="xml">
<presence
type='probe'
from='romeo@example.net/orchard'
to='juliet@example.com'/>
<presence
type='probe'
from='romeo@example.net/orchard'
to='benvolio@example.org'/>
</source>

:例子 3: 用户的服务器代替用户发送初始化出席信息给 subscription="from" 和 subscription="both"的联系人的可用资源:

<source lang="xml">
<presence
from='romeo@example.net/orchard'
to='juliet@example.com'/>
<presence
from='romeo@example.net/orchard'
to='mercutio@example.org'/>
</source>

:例子 4: 联系人的服务器代替所有可用的资源应答出席信息调查:

<source lang="xml">
<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>
<presence
from='juliet@example.com/chamber'
to='romeo@example.net/orchard'>
<priority>1</priority>
</presence>
<presence
from='benvolio@example.org/pda'
to='romeo@example.net/orchard'
xml:lang='en'>
<show>dnd</show>
<status>gallivanting</status>
</presence>
</source>

:例子 5: 联系人的服务器递送用户的初始化出席信息给所有可用的资源或返回错误给用户:

<source lang="xml">
<presence
from='romeo@example.net/orchard'
to='juliet@example.com/chamber'/>
<presence
from='romeo@example.net/orchard'
to='juliet@example.com/balcony'/>
<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>
</source>

:例子 6: 用户直接发送出席信息给另一个不在他的名册中的用户:

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

:例子 7: 用户发送更新的可用出席信息用于广播:

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

:例子 8: 用户的服务器仅向一个联系人广播更新的出席信息 (不是那些返回错误的联系人,也不是那些用户直接向其发送出席信息的联系人):

<source lang="xml">
<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>
</source>

:例子 9: 联系人的服务器递送更新的出席信息给联系人所有可用的资源:

<source lang="xml">
[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>
[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>
</source>

:例子 10: 联系人的资源之一广播最后出席信息:

<source lang="xml">
<presence from='juliet@example.com/balcony' type='unavailable'/>
</source>

:例子 11: 联系人的服务器发送不可用出席信息给用户:

<source lang="xml">
<presence
type='unavailable'
from='juliet@example.com/balcony'
to='romeo@example.net/orchard'/>
</source>

:例子 12: 用户发送最后出席信息:

<source lang="xml">
<presence from='romeo@example.net/orchard'
type='unavailable'
xml:lang='en'>
<status>gone home</status>
</presence>
</source>

:例子 13: 用户的服务器广播不可用出席信息给联系人,包括用户直接向其发送出席信息的那个人:

<source lang="xml">
<presence
type='unavailable'
from='romeo@example.net/orchard'
to='juliet@example.com'
xml:lang='en'>
<status>gone home</status>
</presence>
<presence
from='romeo@example.net/orchard'
to='nurse@example.com'
xml:lang='en'>
<status>gone home</status>
</presence>
</source>

==管理订阅==

:为了保护即时消息用户和任何其他实体的隐私, 出席信息和可用性信息仅向用户已批准的其他实体披露. 当一个用户同意其他用户可以看到它的出席信息, 这个实体被称为对于用户的出席信息有一个订阅. 订阅超越了会话; 实际上, 它一直存在直到订阅者取消订阅或被订阅者取消曾经授权的订阅为止. 在XMPP中订阅是通过发送包含特定属性的出席信息节来管理的.

:注意: 在订阅和名册之间有重要的交互; 这些定义在名册条目和出席信息订阅的集成Integration of Roster Items and Presence Subscriptions (第八章), 而且读者必须参考那一章才能完整地理解出席信息订阅.

===请求一个订阅===

:对另一个实体的出席信息的订阅请求是由发送一个类型为"subscribe"的出席信息节来开始的.

:例子: 发送一个订阅请求:

<source lang="xml">
<presence to='juliet@example.com' type='subscribe'/>
</source>

:关于客户端和服务器在订阅请求中的职责, 参考出席信息订阅Presence Subscriptions(第五章第一节第六小节).

===处理一个订阅请求===

:当一个客户端从另一个实体接收到一个订阅请求, 它必须(MUST)批准这个请求(发送一个类型为"subscribed"的出席信息节)或拒绝这个请求(发送一个类型为"unsubscribed"的出席信息节).

:例子: 批准一个订阅请求:

<source lang="xml">
<presence to='romeo@example.net' type='subscribed'/>
</source>

:例子: 拒绝一个出席信息订阅的请求:

<source lang="xml">
<presence to='romeo@example.net' type='unsubscribed'/>
</source>

===从另一个实体取消一个订阅===

:如果一个用户想取消一个曾经允许的订阅请求, 它发送一个类型为"unsubscribed"的出席信息节.

:例子: 取消一个曾经允许的订阅请求:

<source lang="xml">
<presence to='romeo@example.net' type='unsubscribed'/>
</source>

===取消对于另一个实体的出席信息的订阅===

:如果用户想取消对于另一个实体的出席信息的订阅, 它发送一个类型为"unsubscribe"的出席信息节.

:例子: 取消对一个实体的出席信息的订阅:

<source lang="xml">
<presence to='juliet@example.com' type='unsubscribe'/>
</source>

==名册管理==

:在XMPP中, 一个人的联系人列表被称为名册(roster), 它包括任意数量的特定名册条目, 每个名册条目被一个唯一的JID(通常格式是<contact@domain>)所标识. 一个用户的名册由用户的服务器代替用户储存从而这个用户可以从任何资源访问名册信息.

:注意: 在名册和订阅之间有重要的交互; 这些定义在名册条目和出席信息订阅的集成Integration of Roster Items and Presence Subscriptions (第八章), 而且读者必须参考那一章才能完整地理解名册管理.

===语法和语义===

:名册使用IQ节来管理, 具体来说就是符合'jabber:iq:roster'名字空间的<query/>子元素的含义.这个<query/>元素可以(MAY)包含一个或更多<item/>子元素, 每个描述一个唯一的名册条目或曰联系人"contact".

:每个名册条目的"key"或者说唯一标识符就是一个JID,封装在<item/>元素的'jid'属性(它是必需的(REQUIRED))之中. 如果这个条目是和另一个(人类)即时消息用户相关的,'jid'属性的值的格式应该(SHOULD)是<user@domain>.

:和一个名册条目相关的出席信息订阅的状态从<item/>元素的'subscription'属性可以得到.这个属性允许的值包括:

:* "none" -- 这个用户没有对这个联系人出席信息的订阅, 这个联系人也没有订阅用户的出席信息

:* "to" -- 这个用户订阅了这个联系人的出席信息, 但是这个联系人没有订阅用户的出席信息

:* "from" -- 这个联系人订阅了用户的出席信息, 但是这个用户没有订阅这个联系人的出席信息

:* "both" -- 用户和联系人互相订阅了对方的出席信息

:每个<item/>条目可以(MAY)包含一个'name'属性, 它设置和这个JID相关的"nickname", 取决于用户(而不是联系人). 'name'属性的值是不透明的.

:每个<item/>条目可以(MAY)包含一个或多个<group/>子元素,用于把名册条目收集到多个类别之中. <group/>子元素的XML字符数据是不透明的.

===商业规则===

:在一个名册"set"中一个服务器必须(MUST)忽略任何'to'地址, 并且必须(MUST)认为任何名册"set"是应用于发送者的. 为了更多的安全性, 一个客户端应该(SHOULD)检查"roster push"(包含一个名册条目的类型为"set"的输入IQ)的"from"地址以保证它来自一个信任的源; 具体的, 这个节必须(MUST)没有 'from'属性(例如, 从服务器隐含的) 或'from'属性的值匹配用户的纯JID(格式为<user@domain>)或全JID(格式为<user@domain/resource>); 否则, 客户端应该(SHOULD)忽略这个"roster push".

===登录时接收一个人的名册===

:在连接到服务器并成为一个激活的资源之后, 一个客户端应该(SHOULD)在发送初始化出席信息之前请求名册(无论如何, 因为可能不是所有的资源都想接收名册, 例如, 一个带宽受限的连接, 客户端对于名册的请求是可选的(OPTIONAL)). 如果一个可用的资源在一个会话期间没有请求名册, 服务器不能(MUST NOT)向它发送出席信息订阅以及相关的名册更新.

:例子: 客户端向服务器请求当前的名册:

<source lang="xml">
<iq from='juliet@example.com/balcony' type='get' id='roster_1'>
<query xmlns='jabber:iq:roster'/>
</iq>
</source>

:例子: 客户端从服务器收到名册:

<source lang="xml">
<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>
</source>

===增加一个名册条目===

:任何时候, 一个用户可以(MAY)增加一个条目到他或她的名册.

:例子: 客户端添加一个新的条目:

<source lang="xml">
<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>
</source>

:服务器必须(MUST)在持久信息存储机构中更新名册信息,并且也要向这个用户的所有已请求名册的可用资源推送这一改变. 这个"名册推送"包括一个类型为"set"的IQ节,从服务器发送给客户端,使用户的所有可用资源保持和基于服务器的名册信息的同步.

:例子: 服务器 (1) 推送更新的名册信息给所有已请求名册的可用资源并且 (2) 以一个IO结果应答发送的资源:

<source lang="xml">
<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>
</item>
</query>
</iq>
<iq to='juliet@example.com/balcony' type='result' id='roster_2'/>
</source>

:正如IQ节类型(定义在[XMPP-CORE|XMPP文档列表/XMPP正式RFC标准/RFC3920])的语义所要求的,每个接收到了名册推送的资源必须(MUST)应答一个类型为"result"(或 "error")的IQ节.

:例子: 资源应答一个IQ结果给服务器:

<source lang="xml">
<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'/>
</source>

===更新名册条目===

:更新一个已有的名册条目(例如, 改变组) 的方法和增加一个新的名册条目是一样的, 换言之, 在IQ set 节中发送名册条目给服务器.

:例子: 用户更新名册条目(增加组):

<source lang="xml">
<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>
</source>

:正如增加一个名册条目, 当更新一个名册条目时服务器必须(MUST)在持久信息存储机构中更新名册信息, 并且也要初始化一个名册推送给这个用户的所有已请求名册的可用资源.

===删除一个名册条目===

:任何时候, 用户可以(MAY)从他或她的名册中删除一个条目,只要发送一个 IQ set 给服务器并确保其'subscription'属性值为"remove" (如果从一个客户端接收到'subscription'属性的任何其他值,一个兼容的服务器必须(MUST)忽略它).

:例子: 客户端移除一个条目:

<source lang="xml">
<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>
</source>

:和增加一个名册条目一样, 删除一个名册条目的时候服务器必须(MUST)在持久信息存储机构中更新名册信息,初始化一个名册推送给这个用户的所有已请求名册的可用资源(伴随着把'subscription'属性值设为"remove"),并且发送一个 IQ result 给初始化资源.

:关于这个命令的含义的更多信息, 见移除一个名册条目并取消所有订阅Removing a Roster Item and Cancelling All Subscriptions (第八章第六节).

==名册条目和出席信息订阅的集成==

===概览===

:关于用户从或向别的联系人订阅出席信息,一个即时消息用户通常希望在名册条目和出席信息订阅之间有某些层次的集成. 本章描述了在XMPP即时消息应用中必须(MUST)支持的那些层次的集成.

:有四种主要的订阅状态:

:* None -- 这个用户没有对这个联系人出席信息的订阅, 这个联系人也没有订阅用户的出席信息

:* To -- 这个用户订阅了这个联系人的出席信息, 但是这个联系人没有订阅用户的出席信息

:* From -- 这个联系人订阅了用户的出席信息, 但是这个用户没有订阅这个联系人的出席信息

:* Both -- 用户和联系人互相订阅了对方的出席信息(例如, 联合'from' 和 'to')

:这些状态的每一个都被反射到用户和联系人双方的名册中, 从而导致持久的订阅状态.

:在以下的子章节中将叙述这些订阅状态如何为了完成特定的已定义的用例而进行交互. 关于服务器和客户端处理所有订阅状态的细节 (包括处于以上所列的状态之外的未决状态)在订阅状态Subscription States(第九章).

:服务器不能(MUST NOT)发送出席信息订阅请求或名册推送给不可用的资源, 也不能给没有已请求的名册的可用资源.

:在名册推送中'from'和'to'地址是可选的(OPTIONAL); 如果包含了, 它们的值应该(SHOULD)是那个会话的资源的全JID. 一个客户端必须(MUST)以一个类型为"result"的IQ节来承认每个名册推送(为了暂时的原因, 这些节不显示在以下的例子中但是按[XMPP-CORE|XMPP文档列表/XMPP正式RFC标准/RFC3920]定义的IQ语义学的规定它们是必需的).

===用户向联系人订阅===

:以下描述一个用户向一个联系人订阅的过程, 包括名册条目和订阅状态之间的互动.

:1. 为了能够在用户的客户端界面处理联系人以及在服务器跟踪订阅, 用户的客户端应该(SHOULD)为新的名册条目执行一个"roster set". 这个请求包括发送一个类型为'set'的IQ节并拥有符合'jabber:iq:roster'名字空间的<query/>子元素, 它(<query/>元素)再包含一个<item/>子元素来定义新的名册条目; 这个<item/>元素必须(MUST)拥有一个'jid'属性, 可以(MAY)拥有一个'name'属性, 不能(MUST NOT)拥有一个'subscription'属性, 并且可以(MAY)包含一个或多个<group/>子元素:

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

:2. 作为结果, 这个用户的服务器 (1) 必须(MUST)为这个新的名册条目初始化一个名册推送给这个用户的所有已经请求名册的可用资源, 其'subscription'属性的值为 "none"; 并且 (2) 必须(MUST)以一个 IQ result 应答发送的资源表明名册设置成功了:

<source lang="xml">
<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'/>
</source>

:3. 如果用户想向这个联系人请求出席信息的订阅, 用户的客户端必须(MUST)发送一个类型为'subscribe'的出席信息节给联系人:

<source lang="xml">
<presence to='contact@example.org' type='subscribe'/>
</source>

:4. 作为结果, 用户的服务器必须(MUST)初始化第二个名册推送给这个用户的所有已经请求名册的可用资源,把这个联系人设置成'none'订阅状态的未决子状态; 这个未决子状态是由名册条目中包含的ask='subscribe'属性所指示的:

<source lang="xml">
<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>
</source>

:注意: 如果用户在发送订阅请求之前没有新建一个名册条目, 服务器必须(MUST)现在代替用户新建一个,然后发送一个名册推送给这个用户的所有已经请求名册的可用资源, 不含以上所示的'name'属性和<group/>子元素.

:5. 用户的服务器也必须(MUST)把这个类型为"subscribe"的出席信息节的'from'地址设置为用户的纯JID(例如, <user@example.com>)(如果用户提供了设置为用户的全JID的'from'地址, 服务器应该(SHOULD)移除资源ID). 如果联系人和用户在不同的主机上, 用户的服务器必须(MUST)路由这个出席信息节到联系人的服务器来递送到这个联系人(这种情形的假定贯穿本文; 无论如何, 如果联系人在同一台主机, 那么服务器可以简单地直接递送出席信息节):

<source lang="xml">
<presence
from='user@example.com'
to='contact@example.org'
type='subscribe'/>
</source>

:注意:如果用户的服务器从联系人的服务器收到了一个类型为"error"的出席信息节, 它必须(MUST)这个错误节给用户, 用户的客户端可以(MAY)确定那个错误是否对于上次用户发出的"subscribe"类型的出席信息节(例如, 通过跟踪'id'属性)的应答,然后选择重新发送"subscribe"请求还是发送一个"unsubscribe"类型的出席信息节给联系人以恢复到它的上一个状态.

:6. 接收到指向联系人的"subscribe"类型的出席信息节之后, 这个联系人的服务器必须(MUST)决定是否至少有一个已请求名册的联系人的可用资源. 如果是, 它必须(MUST)递送这个订阅请求给这个联系人(如果不是, 联系人的服务器必须(MUST)离线存储这个订阅请求用于递送 when this condition is next met; 通常这是通过增加一个关于这个联系人的名册条目到用户名册中来实现的, 伴随着一个 "None + Pending In"的状态(定义在订阅状态Subscription States (第九章)), 无论如何一个服务器不应该(SHOULD NOT)在那种状态下推送或递送名册条目给联系人). 不论何时订阅请求被递送到了, 联系人必须决定是否批准它(根据联系人的配置选项, 联系人的客户端可以(MAY）批准或拒绝订阅请求而无需向联系人显示). 这里我们假定这个 "happy path", 即联系人批准了订阅请求(替代的拒绝订阅请求的流程定义在第八章第二节第一小节). 在这种情形下, 这个联系人的客户端 (1) 应该(SHOULD) 执行一个roster set 为这个用户指明期望的昵称和组(如果有的话); 并且 (2) 必须(MUST)发送一个"subscribed"类型的出席信息节给这个用户以批准这个订阅请求.

<source lang="xml">
<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'/>
</source>

:7. 作为结果, 联系人的服务器 (1) 必须(MUST) 初始化一个名册推送给所有联系人已请求名册的可用资源, 包含一个关于那个用户的名册条目,并且其订阅状态为'from'(甚至联系人不执行roster set,服务器也必须(MUST)发送它); (2) 必须(MUST)返回一个 IQ result 给发送的资源表示名册设置(roster set)成功了; (3) 必须(MUST)路由这个"subscribed"类型的出席信息节给用户, 首先把'from'地址设为联系人的纯JID(<contact@example.org>); 然后 (4) 必须(MUST)从所有联系人的可用资源向用户发送可用的出席信息:

<source lang="xml">
<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'/>
<presence
from='contact@example.org'
to='user@example.com'
type='subscribed'/>
<presence
from='contact@example.org/resource'
to='user@example.com'/>
</source>

:注意: 如果联系人的服务器从用户的服务器收到一个"error"类型的出席信息节, 它必须(MUST)递送这个错误节给联系人, 联系人的客户端可以(MAY)确定那个错误是否对于上次联系人发出的"subscribe"类型的出席信息节(例如, 通过跟踪'id'属性)的应答,然后选择重新发送"subscribe"请求还是发送一个"unsubscribe"类型的出席信息节给用户以恢复到它的上一个状态.

:8. 接收到一个指向用户的"subscribed"类型的出席信息节之后, 用户的服务器必须(MUST)首先检查在用户名册中的这个联系人的状态是: (a) subscription='none' and ask='subscribe' 还是 (b) subscription='from' and ask='subscribe'. 如果联系人不是以上述的状态在用户的名册中,用户的服务器必须(MUST)安静的忽略这个"subscribed"类型的出席信息节(例如, 服务器不能(MUST NOT)路由它到用户, 修改用户的名册, 或生成一个名册推送到用户的可用资源). 如果联系人以上述任何一种状态存在于用户的名册中, 用户的服务器 (1) 必须(MUST)从联系人向用户递送这个"subscribed"类型的出席信息节; (2)必须(MUST)初始化一个名册推送给所有已请求名册的这个用户的可用资源,包含一个关于这个联系人的更新的名册条目,同时其'subscription'属性值设置为"to"; 并且 (3) 必须(MUST)从每一个联系人的可用资源向每一个用户的可用资源递送服务器接收到的可用的出席信息节:

<source lang="xml">
<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>
<presence
from='contact@example.org/resource'
to='user@example.com/resource'/>
</source>

:9. 接收到"subscribed"类型的出席信息节之后, 用户应该(SHOULD)承认接收到了订阅状态通知,
要么发送一个"subscribe"类型的出席信息节给联系人证实它, 要么发送一个"unsubscribe"类型的出席信息节给联系人否认它;这个步骤不一定影响订阅状态(见订阅状态Subscription States(第九章)的细节), 但是会让用户用户的服务器知道它必须(MUST)不再发送订阅状态改变通知给用户(见第九章第四节).

:从用户这方面看, 现在存在一个向联系人的出席信息的订阅; 从联系人的方面看, 现在存在一个从用户的来的订阅.

====替代流程: 联系人拒绝订阅请求====

:以上活动流程展示了关于用户向联系人的订阅请求的 "happy path" . 如果联系人拒绝用户的订阅请求,那么主要的替代流程如下所述.

:1. 如果联系人想拒绝这个请求, 联系人的客户端必须(MUST)发送一个"unsubscribed"类型的出席信息节给用户(取代第八章第二节中步骤6发送的 "subscribed"类型的出席信息节):

<source lang="xml">
<presence to='user@example.com' type='unsubscribed'/>
</source>

:2. 作为结果, 联系人的服务器必须(MUST)路由这个"unsubscribed"类型的出席信息节给用户,首先把'from'地址设为联系人的纯JID(<contact@example.org>):

<source lang="xml">
<presence
from='contact@example.org'
to='user@example.com'
type='unsubscribed'/>
</source>

:注意: 如果联系人的服务器之前把用户添加到了联系人的名册中用来跟踪, 这时它必须(MUST)移除这个相关的条目.

:3. 接收到指向用户的"unsubscribed"类型出席信息节之后, 用户的服务器 (1) 必须(MUST)地送那个出席信息节给用户并且 (2) 必须(MUST) 初始化一个名册推送给这个用户的所有已请求名册的可用资源, 包含一个关于这个联系人的一个更新条目,其'subscription'属性设为"none"并且没有'ask'属性:

<source lang="xml">
<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>
</source>

:4. 接收到类型为"unsubscribed"出席信息节之后, 用户应该(SHOULD)承认收到订阅状态通知, 要么发送一个"unsubscribe"类型的出席信息节给联系人证实它, 要么发送一个"subscribe"类型的出席信息节给联系人否认它; 这一步骤不影响订阅状态(见订阅状态Subscription States(第九章)的细节), 但是让用户的服务器知道它必须(MUST)不再发送订阅状态改变的通知给用户(见第九章第四节).

:作为这一行为的结果, 联系人现在在用户的名册中, 状态为"none",而用户根本不在联系人的名册中.

===建立一个相互的订阅===

:用户和联系人可以在前述"happy path"的基础上建立一个相互的订阅(例如, 一个"both"的订阅类型). 流程如下.

:1. 如果联系人想建立一个相互的订阅, 联系人必须(MUST)发送一个订阅请求给用户(视联系人的配置选项而定, 联系人的客户端可以(MAY)自动发送它):

<source lang="xml">
<presence to='user@example.com' type='subscribe'/>
</source>

:2. 作为结果, 联系人的服务器 (1) 必须(MUST)初始化一个名册推送给联系人的所有已请求名册的可用资源, 伴随着用户仍在'from'订阅状态但同时有一个未决的'to'订阅状态(通过在名册条目中包含一个ask='subscribe'的属性来指示); 并且 (2) 必须(MUST)路由这个"subscribe"类型的出席信息节给用户(先把'from'地址设为联系人的纯JID(<contact@example.org>)):

<source lang="xml">
<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>
<presence
from='contact@example.org'
to='user@example.com'
type='subscribe'/>
</source>

:注意: 如果联系人的服务器从用户的服务器收到一个"error"类型的出席信息节, 它必须(MUST)递送这个错误节给联系人, 它的客户端可以(MAY)确定这个错误是用来应答上次发送的"subscribe"类型的出席信息节(换言之, 通过跟踪'id'属性) 并且选择重发这个"subscribe"请求还是发送一个"unsubscribe"类型的出席信息节给用户以把名册恢复到它的前一个状态.

:3. 接收到指向用户的"subscribe"类型出席信息节之后, 用户的服务器必须确定是否至少有一个已请求名册可用资源. 如果是, 用户的服务器必须(MUST)递送这个订阅请求给用户(如果不是, 它必须(MUST)离线存储这个订阅请求等这种情形再次发生时递送). 无论何时订阅请求被递送了, 用户必须决定是否批准它(视用户的配置选项而定, 用户的客户端可以(MAY)批准或拒绝这个订阅请求而不需要向用户显示). 这里我们假定这是"happy path",用户批准了订阅请求(替代的拒绝订阅请求的流程定义在第八章第三节第一小节). 在这种情形下, 用户的客户端必须(MUST)发送一个"subscribed"类型的出席信息节给联系人表示批准了订阅请求.

<source lang="xml">
<presence to='contact@example.org' type='subscribed'/>
</source>

:4. 作为结果, 用户的服务器 (1) 必须(MUST)初始化一个名册推送给用户的所有已请求名册的可用资源, 包含一个关于联系人的名册条目,其'subscription'属性设为"both"; (2) 必须(MUST)路由这个"subscribed"类型的出席信息节给联系人(先把'from'地址设为用户的纯JID<user@example.com>)); 并且 (3) 必须(MUST)向联系人发送它从用户的每个可用资源收到的最近一次出席信息节的全XML(不带'to'属性)(强制每个会话遵守隐私列表):

<source lang="xml">
<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/resource'
to='contact@example.org'/>
</source>

:注意: 如果用户的服务器从联系人的服务器接收到一个"error"类型的出席信息节, 它必须(MUST)递送这个错误节给用户, 它客户端可以(MAY)确定这个错误是用来应答上次发出去的"subscribed"类型的出席信息节(换言之, 通过跟踪'id'属性) 并且选择重发这个订阅请求还是发送一个"unsubscribed"类型的出席信息节给联系人以把名册恢复到上次的状态.

:5. 接收到指向联系人的"subscribed"类型的出席信息节之后, 联系人的服务器必须(MUST)首先检查用户在联系人的名册中的状态是否以下状态之一: (a) subscription='none' and ask='subscribe' 或 (b) subscription='from' and ask='subscribe'. 如果用户不是以上述两种状态之一存在于联系人的名册中, 联系人的服务器必须(MUST)安静地忽略这个"subscribed"类型的出席信息节(例如, 它不能(MUST NOT)路由它给联系人, 修改联系人的名册, 或生成一个名册推送给联系人的可用资源). 如果用户以上述两种状态之一存在于联系人的名册中, 联系人的服务器 (1) 必须(MUST)从用户向联系人递送这个"subscribed"类型的出席信息节; (2) 必须(MUST)初始化一个名册推送给这个联系人的所有已请求名册的可用资源, 包含一个关于这个用户的更新的名册条目,其'subscription'属性值设为"both"; 并且 (3) 必须(MUST)向这个联系人的每个可用资源递送它从这个用户的每个资源收到的可用出席信息节:

<source lang="xml">
<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>
<presence
from='user@example.com/resource'
to='contact@example.org/resource'/>
</source>

:6. 收到"subscribed"类型的出席信息节之后, 联系人应该(SHOULD)承认收到订阅请求通知,要么发送一个"subscribe"的出席信息节给用户证实它,要么发送一个"unsubscribe"类型的出席信息节给用户否认它; 这一步骤不影响订阅状态(细节见订阅状态Subscription States(第九章)), 但是让联系人的服务器知道它必须(MUST)不再发送订阅状态变更通知给联系人(见第九章第四节).

:用户和联系人现在有了对双方的出席信息的一个相互订阅 \-\- 换言之, 这个订阅类型为 "both".

====替代流程: 用户拒绝订阅请求====

:以上活动流程展示了关于联系人对用户的订阅请求的 "happy path". 如果用户拒绝了联系人的订阅请求,其主要流程如下.

:1. 如果用户想拒绝请求, 用户的客户端必须(MUST)发送一个"unsubscribed"类型的出席信息节给联系人(替代第八章第三节中的第三步中所发送的"subscribed"类型出席信息节):

<source lang="xml">
<presence to='contact@example.org' type='unsubscribed'/>
</source>

:2. 作为结果, 用户的服务器必须(MUST)路由这个"unsubscribed"类型的出席信息节给联系人(首先把'from'地址设为用户的纯JID(<user@example.com>)):

<source lang="xml">
<presence
from='user@example.com'
to='contact@example.org'
type='unsubscribed'/>
</source>

:3. 接收到指向联系人的"unsubscribed"类型的出席信息节之后, 联系人的服务器 (1) 必须(MUST)递送这个出席信息节给联系人; 并且 (2) 必须(MUST)初始化一个名册推送给这个联系人的所有已请求名册的可用资源, 包含关于这个用户的更新的名册条目,其'subscription'属性的值设为"from"并且没有'ask'属性:

<source lang="xml">
<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>
</source>

:4. 接收到"unsubscribed"类型的出席信息节之后, 联系人应该(SHOULD)承认收到那个订阅状态通知,要么向用户发送一个"unsubscribe"类型的出席信息节以证实它,要么向用户发送一个"subscribe"类型的出席信息以否认它; 这个步骤不会影响订阅状态(详见订阅状态Subscription States(第九章)),但是让联系人的服务器知道它必须(MUST)不再发送订阅状态变更通知给联系人(见第九章第四节).

:作为这一活动的结果, 订阅状态没有任何改变; 换言之, 联系人在用户的名册中的订阅状态为"to"并且用户在联系人的名册中的订阅状态为"from".

===取消订阅===

:在订阅了一个联系人的出席信息之后的任何时候, 一个用户可以(MAY)取消订阅. 在所有实例中用户发送来执行这一动作的XML是相同的, 接下来的订阅状态根据发出取消订阅命令时获得的订阅状态的情况而不同. 两种可能的情节描述如下.

====情形 #1: 当订阅不是相互的时候取消订阅====

:在第一种情形, 用户有一个向联系人的出席信息的订阅但是联系人没有对用户的出席信息的订阅（换言之, 订阅不是相互的).

:1. 如果用户想取消对联系人的出席信息的订阅, 用户必须(MUST)发送一个"unsubscribe"类型的出席信息节给联系人:

<source lang="xml">
<presence to='contact@example.org' type='unsubscribe'/>
</source>

:2. 作为一个结果, 用户的服务器 (1) 必须(MUST) 发送一个名册推送给这个用户的所有已请求名册的可用资源,包含一个关于这个联系人的更新名册条目,其'subscription'属性设为"none"; 并且 (2) 必须(MUST)路由这个"unsubscribe"类型的出席信息节给联系人(首先把'from'地址设为用户的纯JID(<user@example.com>)):

<source lang="xml">
<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'/>
</source>

:3. 接收到指向联系人的"unsubscribe"类型出席信息节之后, 联系人的服务器 (1) 必须(MUST)初始化一个名册推送给这个联系人的所有已请求名册的可用资源, 包含一个关于这个用户的名册条目,其'subscription'属性值设为"none" (如果联系人不可用或未曾请求名册, 联系人的服务器必须(MUST)修改名册条目并在下次联系人请求名册时发送那个已修改的条目); 并且 (2) 必须(MUST)递送这个"unsubscribe"状态改变通知给联系人:

<source lang="xml">
<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'/>
</source>

:4. 接收到"unsubscribe"类型的出席信息节之后, 联系人应该(SHOULD)承认收到那个订阅状态通知,要么发送一个"unsubscribed"类型的出席信息节给用户以证实它,要么发送一个"subscribed"类型的出席信息节给用户否认它; 这个步骤不影响订阅状态(详见订阅状态Subscription States (第九章)), 但是让联系人的服务器知道它必须(MUST)不再发送订阅状态变更通知给联系人(见第九章第四节).

:5. 联系人的服务器接着 (1) 必须(MUST)发送一个"unsubscribed"类型的出席信息节给用户;并且 (2) 应该(SHOULD)向用户发送从这个联系人的所有可用资源收到的不可用出席信息:

<source lang="xml">
<presence
from='contact@example.org'
to='user@example.com'
type='unsubscribed'/>
<presence
from='contact@example.org/resource'
to='user@example.com'
type='unavailable'/>
</source>

:6. 当用户的服务器收到类型为"unsubscribed" 和 "unavailable"的出席信息节, 它必须(MUST)递送它们给用户:

<source lang="xml">
<presence
from='contact@example.org'
to='user@example.com'
type='unsubscribed'/>
<presence
from='contact@example.org/resource'
to='user@example.com'
type='unavailable'/>
</source>

:7. 接收到"unsubscribed"类型的出席信息节之后, 用户应该(SHOULD)承认收到那个订阅状态变更通知,要么向联系人发送一个"unsubscribe"类型的出席信息节以证实它,要么向联系人发送一个"subscribe"的出席信息节以否认它;这步骤不影响订阅状态(详见订阅状态Subscription States(第九章)), 但是让用户的服务器知道它必须(MUST)不在发送订阅状态变更通知给用户(见第九章第四节).

====情形 #2: 当订阅是相互的时候取消订阅====

:在第二种情形下, 用户有一个向联系人的出席信息的订阅并且联系人也有一个向用户的出席信息的订阅(换言之, 订阅是相互的).

:1. 如果用户想从联系人的出席信息取消订阅, 用户必须(MUST)发送一个"unsubscribe"类型的出席信息节给联系人:

<source lang="xml">
<presence to='contact@example.org' type='unsubscribe'/>
</source>

:2. 作为一个结果, 用户的服务器 (1) 必须(MUST)发送一个名册推送给这个用户的所有已请求名册的可用资源,包含一个关于这个联系人的更新名册条目,其'subscription'属性值设为"from"; 并且 (2) 必须(MUST)路由这个"unsubscribe"类型的出席信息节给这个联系人( 首先把'from'地址设为这个用户的纯 JID(<user@example.com>):

<source lang="xml">
<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'/>
</source>

:3. 接收到指向联系人的"unsubscribe"类型的出席信息节之后, 联系人的服务器 (1) 必须(MUST)初始化一个名册推送给这个联系人的所有已请求名册的可用资源, 包含一个关于这个用户的名册条目,其'subscription'属性值设为"to" (如果联系人不可用或未曾请求名册, 联系人的服务去必须(MUST)修改这个名册条目并且等下次联系人请求名册的时候再发送这个修改过的名册条目); 并且 (2) 必须(MUST)递送这个"unsubscribe"状态变更通知给联系人:

<source lang="xml">
<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'/>
</source>

:4. 接收到这个"unsubscribe"类型的出席信息节之后, 联系人应该(SHOULD)承认收到了那个订阅状态通知,要么向用户发送一个"unsubscribed"类型的出席信息节以证实它,要么向用户发送一个"subscribed"类型的出席信息节以否认它; 这个步骤不影响订阅状态(详见订阅状态Subscription States(第九章)), 但是让联系人的服务器知道它必须(MUST)不再发送订阅状态变更通知给联系人(见第九章第四节).

:5. 联系人的服务器然后 (1) 必须(MUST)发送一个"unsubscribed"类型的出席信息节给用户; 并且 (2) 应该(SHOULD)向用户发送它从联系人的所有可用资源收到的不可用出席信息:

<source lang="xml">
<presence
from='contact@example.org'
to='user@example.com'
type='unsubscribed'/>
<presence
from='contact@example.org/resource'
to='user@example.com'
type='unavailable'/>
</source>

:6. 当用户的服务器收到"unsubscribed"和"unavailable"类型的出席信息节, 它必须(MUST)递送它们给用户:

<source lang="xml">
<presence
from='contact@example.org'
to='user@example.com'
type='unsubscribed'/>
<presence
from='contact@example.org/resource'
to='user@example.com'
type='unavailable'/>
</source>

:7. 接收到"unsubscribed"类型的出席信息节之后, 用户应该(SHOULD)承认收到了那个订阅状态的通知,要么向联系人发送一个"unsubscribe"类型的出席信息节以证实它,要么向联系人发送一个"subscribe"类型的出席信息节以否认它;这个步骤不影响订阅状态(详见订阅状态Subscription States(第九章)), 但是让用户的服务器知道它必须(MUST)不在发送订阅状态变更通知给用户(见第九章第四节).

:注意: 显然这不会导致名册条目从用户的名册移除, 并且联系人仍然有一个对用户的出席信息的订阅.为了完全取消双向的订阅并完全从用户的名册中移除名册条目, 用户应该(SHOULD)使用subscription='remove'(定义在移除一个名册条目并取消所有订阅项Removing a Roster Item and Cancelling All Subscriptions (第八章第六节))更新名册条目.

===取消一个订阅项===

:在批准来自一个用户的任何订阅请求之后的任何时候, 一个联系人可以(MAY)取消那个订阅项. 联系人在所有实例中执行这个动作中发送的XML是相同的, 接下来的订阅状态根据取消命令发出当时所获得的订阅状态而有所不同. 所有可能的情节描述如下.

====情形 #1: 当订阅不是相互的时候取消订阅项====

:在第一种情形下, 用户有一个对联系人的出席信息的订阅但是联系人没有对于用户的出席信息的订阅(换言之, 订阅还不是相互的).

:1. 如果联系人想取消用户的订阅项, 联系人必须(MUST)发送一个"unsubscribed"类型的出席信息节给用户:

<source lang="xml">
<presence to='user@example.com' type='unsubscribed'/>
</source>

:2. 作为一个结果, 联系人的服务器 (1) 必须(MUST)发送一个名册推送给这个联系人的所有已请求名册的可用资源, 包含一个关于这个用户的更新的名册条目,其'subscription'属性值设为"none"; (2) 必须(MUST)路由这个"unsubscribed"类型的出席信息节给用户(首先把'from'地址设为联系人的纯JID(<contact@example.org>)); 并且 (3) 应该(SHOULD)向用户发送它从联系人的所有可用资源收到的不可用出席信息:

<source lang="xml">
<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='contact@example.org'
to='user@example.com'
type='unsubscribed'/>
<presence
from='contact@example.org/resource'
to='user@example.com'
type='unavailable'/>
</source>

:3. 接收到指向用户的"unsubscribed"类型的出席信息节之后, 用户的服务器 (1) 必须(MUST)初始化一个名册推送给这个用户的所有已请求名册的可用资源, 包含一个关于这个联系人的名册条目更新,其'subscription'属性值设为"none"(如果用户不可用或未曾请求名册, 用户的服务器必须(MUST)修改这个名册条目并且等下次用户请求名册的时候发送修改过的名册条目); (2) 必须(MUST)递送这个"unsubscribed"状态改变通知给这个用户的所有可用资源; 并且 (3) 必须(MUST)向这个用户的所有可用资源递送不可用出席信息:

<source lang="xml">
<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'/>
</source>

:4. 接收到"unsubscribed"类型的出席信息节之后, 用户应该(SHOULD)承认收到了那个订阅状态通知,要么向联系人发送一个"unsubscribe"出席信息节以证实它,要么向联系人发送一个"subscribe"类型的出席信息节以否认它;这个步骤不影响订阅状态(详见订阅状态Subscription States(第九章)), 但是让服务器知道它必须(MUST)不再发送订阅状态变更通知给用户(见第九章第四节).

====情形 #2: 当订阅项是相互的时候取消====

:在这种情形下, 用户有一个对联系人的出席信息的订阅并且联系人也有一个对用户的出席信息的订阅(换言之, 订阅是相互的).

:1. 如果联系人想取消用户的订阅, 联系人必须(MUST)发送一个"unsubscribed"类型的出席信息节给用户:

<source lang="xml">
<presence to='user@example.com' type='unsubscribed'/>
</source>

:2. 作为结果, 联系人的服务器 (1) 必须(MUST)发送一个名册推送给这个联系人的所有已请求名册的可用资源, 包含关于这个用户的一个更新的名册条目,其'subscription'属性值设为"to"; (2) 必须(MUST)路由这个"unsubscribed"类型的出席信息节给用户(首先把'from'地址设为联系人的纯JID(<contact@example.org>)); 并且 (3) 应该(SHOULD)向这个用户的所有可用资源发送它从联系人的所有可用资源收到的不可用出席信息:

<source lang="xml">
<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'/>
</source>

:3. 接收到指向用户的"unsubscribed"类型出席信息节之后, 用户的服务器 (1) 必须(MUST)初始化一个名册推送给这个用户的所有已请求名册的可用资源, 包含关于这个联系人的更新的名册条目,其'subscription'属性值设为"from"(如果这个用户不可用或未曾请求名册, 用户的服务器必须(MUST)修改这个名册条目并且等下次用户请求名册的时候发送修改过的条目给它); 并且(2) 必须(MUST)递送这个"unsubscribed"状态变更通知给用户的所有可用资源; 并且 (3) 必须(MUST)向这个用户的所有可用资源递送这个不可用出席信息:

<source lang="xml">
<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'/>
</source>

:4. 接收到这个"unsubscribed"类型的出席信息节之后, 用户应该(SHOULD)承认收到了那个订阅状态通知,要么向联系人发送一个"unsubscribe"类型的出席信息节以证实它,要么向联系人发送一个"subscribe"类型的出席信息节以否认它; 这一步骤不影响订阅状态(详见订阅状态Subscription States (第九章)), 但是让用户的服务器知道它必须(MUST)不再发送订阅状态变更通知给用户(见第九章第四节).

:注意: 显然这不会使得名册条目从联系人的名册中移除, 并且联系人仍然有一个对用户的出席信息的订阅. 为了完全双向的取消一个相互的订阅并且从联系人的名册中完全移除这个名册条目, 联系人应该以subscription='remove'(定义在移除一个名册条目并取消所有订阅项Removing a Roster Item and Cancelling All Subscriptions (第八章第六节))更新名册条目.

===移除一个名册条目并取消所有订阅项===

:因为在双向完整移除一个名册条目和取消所有订阅的过程中可能有很多步骤, 名册管理协议包含一个"shortcut"方法来做这件事. 无论当前的订阅状态是什么, 这个过程可以通过发送一个roster set(包含一个用于这个联系人的条目,其'subscription'属性值设为"remove")来初始化:

<source lang="xml">
<iq type='set' id='remove1'>
<query xmlns='jabber:iq:roster'>
<item
jid='contact@example.org'
subscription='remove'/>
</query>
</iq>
</source>

:当用户从他或她的名册中移除一个联系人(通过把'subscription'属性值设为"remove"), 用户的服务器 (1) 必须(MUST)自动取消用户和联系人之间的任何现存的出席信息订阅项(包括相应的'to'和'from'); (2) 必须(MUST)从用户的名册移除这个名册条目并且通知这个用户的所有已请求名册的可用资源这个名册条目被移除了; (3) 必须(MUST)通知初始化的资源移除成功了; 并且 (4) 应该(SHOULD)向联系人发送它从这个用户的所有可用资源收到的不可用出席信息:

<source lang="xml">
<presence
from='user@example.com'
to='contact@example.org'
type='unsubscribe'/>
<presence
from='user@example.com'
to='contact@example.org'
type='unsubscribed'/>
<iq type='set'>
<query xmlns='jabber:iq:roster'>
<item
jid='contact@example.org'
subscription='remove'/>
</query>
</iq>
<iq type='result' id='remove1'/>
<presence
from='user@example.com/resource'
to='contact@example.org'
type='unavailable'/>
</source>

:收到"unsubscribe"类型的出席信息后, 联系人的服务器 (1) 必须(MUST)初始化一个名册推送给这个联系人的所有已请求名册的可用资源,包含关于这个用户的一个更新的名册条目,其'subscription'属性值设为"to"(如果这个联系人不可用或未曾请求名册, 联系人的服务器必须(MUST)修改这个名册条目并且等下次联系人请求名册的时候发送这个修改过的条目给它); 并且 (2) 也必须(MUST)递送这个"unsubscribe"状态变更通知给这个联系人的所有可用资源:

<source lang="xml">
<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'/>
</source>

:收到这个"unsubscribed"类型的出席信息节之后, 联系人的服务器 (1) 必须(MUST)初始化一个名册推送给这个联系人的所有已请求名册的可用资源,包含一个关于这个用户的更新的名册条目,其'subscription'属性值设为"none"(如果这个联系人不可用或未曾请求名册, 联系人的服务器必须(MUST)修改名册条目并且等下次联系人请求名册的时候把修改过的条目发送给它); 并且 (2) 也必须(MUST)递送这个"unsubscribe"状态改变通知给这个联系人的所有可用资源:

<source lang="xml">
<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='unsubscribed'/>
</source>

:接收到指向联系人的"unavailable"出席信息节之后, 联系人的服务器必须(MUST)递送这个不可用出席信息给这个用户的所有可用资源:

<source lang="xml">
<presence
from='user@example.com/resource'
to='contact@example.org'
type='unavailable'/>
</source>

:注意: 当用户从用户的名册中移除联系人的时候, 这个联系人的名册最后状态是用户仍然在联系人名册中但是订阅状态为"none"; 为了完全移除关于这个用户的名册条目, 联系人也需要发送一个名册移除请求.

==订阅状态==

:本章提供关于订阅状态以及和订阅相关的出席信息节(换言之,类型为"subscribe", "subscribed", "unsubscribe",和 "unsubscribed"的出席信息节)的服务器处理过程的详细信息.

===已定义的状态===

:有九种可能的订阅状态, 从用户的(不是联系人的)角度描述如下:

:# "None" = 联系人和用户互相没有被对方订阅, 并且也都没有从对方那里请求一个订阅
:# "None + Pending Out" = 联系人和用户互相没有被对方订阅, 用户已经向联系人发送了一个订阅请求但还没有收到回复
:# "None + Pending In" = 联系人和用户互相没有被对方订阅, 联系人已经向用户发送了一个订阅请求但还没有收到回复(注意: 在这种状态下联系人的服务器不应该(SHOULD NOT)推送或递送名册条目, 但是应该(SHOULD)等待,直到联系人的订阅请求已经从用户那里得到批准)
:# "None + Pending Out/In" = 联系人和用户互相没有被对方订阅, 联系人已经向用户发送了一个订阅请求但还没有收到回复, 用户已经向联系人发送了一个订阅请求但还没有收到回复
:# "To" = 用户已订阅联系人(单向)
:# "To + Pending In" = 用户已订阅联系人, 联系人已经向用户发送了一个订阅请求但还没有收到回复
:# "From" = 联系人已订阅用户(单向)
:# "From + Pending Out" = 联系人已订阅用户(单向), 用户已经向联系人发送了一个订阅请求但还没有收到回复
:# "Both" = 用户和联系人互相被对方订阅了(双向)

===出站出席信息订阅节的服务器处理过程===

:出站出席信息订阅节使用户能管理他或她对联系人的出席信息的订阅(通过"subscribe"和"unsubscribe"类型), 并且管理联系人对用户的出席信息的访问(通过"subscribed"和"unsubscribed"类型).

:因为用户的服务器和联系人的服务器有可能失去对于订阅状态的同步, 用户的服务器必须(MUST)毫无例外地路由所有"subscribe"或"unsubscribe"类型的出站出席信息节给联系人,使用户能在需要的时候重新同步他或她的对联系人的出席信息的订阅.

:如果从用户的角度来看,一个"subscribed"或"unsubscribed"类型的出席信息节不会导致一个订阅状态的变更,用户的服务器不应该(SHOULD NOT)路由这个节到联系人那里,并且不能(MUST NOT)做出一个状态变更. 如果这个节导致一个订阅状态的变更, 用户的服务器必须(MUST)路由这个节到联系人,并且必须(MUST)做出相应的状态变更. 这些规则总结如下这些表.

:表 1: 推荐的出站"subscribed"节的处理

{|border="1" cellspacing="0"
!当前状态 !! 路由? !! 新状态
|-
|"None" || 否 || 状态不变
|-
|"None + Pending Out" || 否 || 状态不变
|-
|"None + Pending In" || 是 || "From"
|-
|"None + Pending Out/In" || 是 || "From + Pending Out"
|-
|"To" || 否 || 状态不变
|-
|"To + Pending In" || 是 || "Both"
|-
|"From" || 否 || 状态不变
|-
|"From + Pending Out" || 否 || 状态不变
|-
|"Both" || 否 || 状态不变
|}

:表 2: 推荐的出站"unsubscribed"节处理

{|border="1" cellspacing="0"
!当前状态 !! 路由? !! 新状态
|-
|"None" || 否 || 状态不变
|-
|"None + Pending Out" || 否 || 状态不变
|-
|"None + Pending In" || 是 || "None"
|-
|"None + Pending Out/In" || 是 || "None + Pending Out"
|-
|"To" || 否 || 状态不变
|-
|"To + Pending In" || 是 || "To"
|-
|"From" || 是 || "None"
|-
|"From \+ Pending Out" || 是 || "None \+ Pending Out"
|-
|"Both" || 是 || "To"
|}

===入站出席信息订阅节的服务器处理过程===

:入站出席信息订阅节从用户请求一个订阅相关的动作(通过"subscribe"类型), 通知用户由联系人所做的订阅状态相关的动作(通过"unsubscribe"类型),或使联系人能够管理用户对联系人的出席信息的访问(通过"subscribed"和"unsubscribed"类型).

:当用户的服务器为用户从联系人那里接收到一个订阅请求(换言之, 一个"subscribe"类型的出席信息节), 如果用户未曾允许联系人访问用户的出席信息或者没有未决的入站订阅请求, 它必须(MUST)递送那个请求给用户;无论如何, 如果有一个未决的入站订阅请求, 用户的服务器不应该(SHOULD NOT)递送这个新的请求, 因为上一个订阅请求可能已经被记录下来了. 如果用户已经允许联系人访问用户的出席信息,用户的服务器应该(SHOULD)对一个从联系人发来的"subscribe"类型的入站出席信息节自动回复(通过代替用户向联系人发送一个"subscribed"类型的出席信息节); 这个规则使得联系人可以在需要的时候重新同步订阅状态. 这些规则总结如下面这些表.

:表 3: 推荐的入站"subscribe"节处理

{|border="1" cellspacing="0"
!当前状态 !! 递送? !! 新状态
|-
|"None" || 是 || "None + Pending In"
|-
|"None + Pending Out" || 是 || "None + Pending Out/In"
|-
|"None + Pending In" || 否 || 状态不变
|-
|"None + Pending Out/In" || 否 || 状态不变
|-
|"To" || 是 || "To + Pending In"
|-
|"To + Pending In" || 否 || 状态不变
|-
|"From" || 否 * || 状态不变
|-
|"From + Pending Out" || 否 * || 状态不变
|-
|"Both" || 否 * || 状态不变
|}

:* 服务器应该(SHOULD)以"subscribed"节自动回复

:当用户的服务器为用户从联系人那里收到一个"unsubscribe"类型的出席信息节, 如果从用户的角度看这个节会导致一个订阅状态变更,那么用户的服务器应该(SHOULD)代替用户自动应答(发送一个"unsubscribed"类型的出席信息节给联系人), 必须(MUST)递送这个"unsubscribe"节给用户,并且必须(MUST)改变状态. 如果不会导致订阅状态变更, 用户的服务器不应该(SHOULD NOT)递送这个节并且不能(MUST NOT)改变状态. 这些规则总结如下表.

:表 4: 推荐的入站"unsubscribe"节处理

{|border="1" cellspacing="0"
!当前状态 !! 递送? !! 新状态
|-
|"None" || 否 || 状态不变
|-
|"None + Pending Out" || 否 || 状态不变
|-
|"None + Pending In" || 是 * || "None"
|-
|"None + Pending Out/In" || 是 * || "None \+ Pending Out"
|-
|"To" || 否 || 状态不变
|-
|"To + Pending In" || 是 * || "To"
|-
|"From" || 是 * || "None"
|-
|"From + Pending Out" || 是 * || "None \+ Pending Out
|-
|"Both" || 是 * || "To"
|}

:* 服务器应该(SHOULD)以"unsubscribed"节自动应答

:当用户的服务器为用户从联系人那里收到一个"subscribed"类型的出席信息节, 如果没有一个为访问联系人的出席信息的未决的出站请求,它不能(MUST NOT)递送这个节给用户并且不能(MUST NOT)改变订阅状态. 如果有一个为了访问联系人的出席信息的未决的出站请求并且这个"subscribed"类型的入站出席信息请求会导致一个订阅状态的改变,用户的服务器必须(MUST)递送这个节给用户并且必须(MUST)改变订阅状态. 如果用户已经有授权可以访问联系人的出席信息, 这个"subscribed"类型的入站出席信息节不导致一个订阅状态的变更;从而用户的服务器不应该(SHOULD NOT)递送这个节给用户并且不能(MUST NOT)改变订阅状态. 这些规则总结如下表.

:表 5: 推荐的入站"subscribed"节处理

{|border="1" cellspacing="0"
!当前状态 !! 递送? !! 新状态
|-
|"None" || 否 || 状态不变
|-
|"None + Pending Out" || 是 || "To"
|-
|"None + Pending In" || 否 || 状态不变
|-
|"None + Pending Out/In" || 是 || "To \+ Pending In"
|-
|"To" || 否 || 状态不变
|-
|"To + Pending In" || 否 || 状态不变
|-
|"From" || 否 || 状态不变
|-
|"From + Pending Out" || 是 || "Both"
|-
|"Both" || 否 || 状态不变
|}

:当用户的服务器为用户从联系人那里收到了一个"unsubscribed"类型的出席信息节, 如果有一个为了访问联系人的出席信息的未决的出站请求或者用户当前已经有授权可以访问联系人的出席信息,它必须(MUST)递送这个节给用户并且必须(MUST)改变订阅状态. 否则, 用户的服务器不应该(SHOULD NOT)递送这个节并且不能(MUST NOT)改变订阅状态. 这些规则总结如下表.

:表 6: 推荐的入站"unsubscribed"节处理

{|border="1" cellspacing="0"
!当前状态 !! 递送? !! 新状态
|-
|"None" || 否 || 状态不变
|-
|"None + Pending Out" || 是 || "None"
|-
|"None + Pending In" || 否 || 状态不变
|-
|"None + Pending Out/In" || 是 || "None \+ Pending In"
|-
|"To" || 是 || "None"
|-
|"To + Pending In" || 是 || "None \+ Pending In"
|-
|"From" || 否 || 状态不变
|-
|"From + Pending Out" || 是 || "From"
|-
|"Both" || 是 || "From"
|}

===服务器递送和客户端承认订阅请求以及状态变更通知===

:当一个服务器收到一个"subscribe"类型的入站出席信息节(换言之, 一个订阅请求)或"subscribed"类型,"unsubscribe"类型, 或"unsubscribed"类型(换言之, 一个订阅状态变更通知), 除了发送适当的名册推送(或当下次名册被一个可用资源请求时发送更新的名册), 它必须(MUST)递送这个请求或通知给预定的接收者至少一次. 一个服务器可以(MAY)要求接收者的回执以承认接收到了所有状态变更通知(并且必须(MUST)要求承认订阅请求的情形, 换言之,类型的出席信息节"subscribe"). 为了要求回执, 一个服务器应该(SHOULD)在每次接收者登陆的时候发送这个请求或通知给它, 直到这个接收者承认收到这个通知(通过证实"affirming"或禁止"denying"这个通知),如下表:

:表 7: 订阅状态变更通知的承认

{|border="1" cellspacing="0"
!节类型 !! 接受 !! 禁止
|-
|subscribe || subscribed || unsubscribed
|-
|subscribed || subscribe || unsubscribe
|-
|unsubscribe || unsubscribed || subscribed
|-
|unsubscribed || unsubscribe || subscribe
|}

:显然, 根据前述的订阅状态图表, 一些回执节将被路由到联系人并且导致状态的变更, 而其他的则不会. 无论如何, 任何这样的节必须(MUST)导致服务器不再发送订阅状态变更通知给用户.

:因为在接收到roster set(其'subscription'属性值设为"remove"(见移除一个名册条目并且取消所有订阅项 Removing a Roster Item and Cancelling All Subscriptions (第八章第六节)))之后,用户的服务器必须(MUST)自动生成"unsubscribe"和"unsubscribed"类型的出站出席信息节,服务器必须(MUST)把一个名册移除请求视为发送所有这些出席信息节,以决定是否继续向用户发送"subscribe"或"subscribed"类型的订阅状态变更通知.

==屏蔽通信==

:大多数即时消息系统已发现有必要实现一些方法来为用户屏蔽来自某些特定的其他用户的通信(这在\[IMP-REQS\]的第五章第一节第五小节, 第五章第一节第十五小节,第五章第三节第二小节, 和第五章第四节第十小节中也有要求). 在XMPP中这是由管理某人的隐私列表来实现的(使用'jabber:iq:privacy'名字空间).

:服务器端的隐私列表使得以下用例能够完成:

:* 接收某人的隐私列表.

:* 增加, 移除, 和编辑某人的隐私列表.

:* 设置, 改变, 或取消激活的列表.

:* 设置, 改变, 或取消缺省的列表 (换言之, 缺省激活的那个列表).

:* 基于JID, group, 或 subscription 类型(或全局的) 允许或屏蔽消息.

:* 允许或屏蔽入站出席信息通知,基于 JID, group, 或 subscription 类型 (或全局的).

:* 允许或屏蔽出站出席信息通知,基于 JID, group, 或 subscription 类型 (或全局的).

:* 允许或屏蔽 IQ 节, 基于 JID, group,或 subscription 类型(或全局的).

:* 允许或屏蔽所有通信, 基于 JID, group, 或 subscription 类型(或全局的).

:注意: 出席信息通知不包括出席信息订阅,只包括广播给那些已订阅了用户出席信息的实体的出席信息. 因而这包括没有'type'属性或只包含type='unavailable'的的出席信息节.

===语法和语义===

:一个用户可以(MAY)定义一个或更多的隐私列表, 它们由用户的服务器保存. 每个<list/>元素包含一个或多个格式为<item/>元素的规则, 并且每个<item/>元素使用属性来定义一个隐私规则类型, 一个适用于规则的特定值, 相应的动作, 和处理顺序相应的条目位置.

:语法如下:

<source lang="xml">
<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>
</source>

:如果类型是"jid", 那么'value'属性必须(MUST)包含一个合法的Jabber ID. JIDs 应该(SHOULD)满足以下顺序:

:# <user@domain/resource> (仅为匹配的资源)
:# <user@domain> (任何匹配的资源)
:# <domain/resource> (仅匹配的资源)
:# <domain> (匹配这个域本身, 正如任何 user@domain, domain/resource, 或包含一个子域的地址)

:如果类型为"group", 那么'value'属性应该(SHOULD)包含组在用户的名册中的名字. (如果一个客户端尝试更新, 新建, 或删除一个不在用户名册中的组的列表条目, 服务器应该(SHOULD)返回给客户端一个<item-not-found/>节错误.)

:如果类型是"subscription", 那么'value'属性必须(MUST)是"both", "to", "from", 或"none" (定义在名册语法和语义Roster Syntax and Semantics (第七章第一节))中的一个人, 在这里 "none" 包括对于用户来说完全未知和根本不在用户名册中的实体.

:如果没有包含'type'属性, 这个规则提供失败"fall-through" 情景.

::'action'属性必须(MUST)被包含并且它的值必须(MUST)是允许"allow"或禁止"deny".

::'order'属性必须(MUST)被包含并且它的值必须(MUST)是一个在列表的所有条目中具有唯一性的非负整数. (如果一个客户端尝试以一个非唯一的order值建立或更新一个列表, 服务器必须(MUST)返回给客户端一个<bad-request/>节错误.)

::<item/>元素可以(MAY)包含一个或更多子元素,使得一个实体可以指明更多的细微控制包括屏蔽哪些种类的节(换言之, 不只是简单地屏蔽所有节). 允许的子元素包括:

:* <message/> \-\- 屏蔽引入消息节
:* <iq/> \-\- 屏蔽引入 IQ 节
:* <presence-in/> \-\- 屏蔽引入出席信息通知
:* <presence-out/> \-\- 屏蔽外出出席信息通知

:在"jabber:iq:privacy'名字空间之内, 一个"set"类型的IQ节的<query/>子元素不能(MUST NOT)包含超过一个子元素(换言之, 这个节必须(MUST)只包含一个<active/>元素, 一个<default/>元素, 或一个<list/>元素); 如果一个发送中的实体违反了这个规则, 接收中的实体必须(MUST)返回一个 return a <bad-request/>节错误.

:当一个客户端增加或更新一个隐私列表, <list/>元素应该(SHOULD)包含至少一个<item/>子元素; 当一个客户端移除一个隐私列表的时候, <list/>元素不能(MUST NOT)包含任何<item/>子元素.

:当一个客户端更新一个隐私列表的时候, 它必须包含所有想得到的条目(换言之, 不是一个"delta").

===商业规则===

:# 如果有一个为某会话设置的激活的列表, 它只影响为其激活的那个会话, 并且只在那一个会话的持续期间有效; 服务器必须(MUST)只应用激活列表,并且不能(MUST NOT)应用缺省列表(换言之, 列表没有层次"layering").
:# 缺省列表总体适用于用户, 并且如果没有为一个节指向的目标session/resource设置激活列表,或用户当前没有会话,它会被处理.
:# 如果没有为一个会话设置激活列表(或用户当前没有会话), 并且没有缺省列表,那么所有节应该被(SHOULD BE)接受或由服务器代替用户做适当的处理(遵守用于处理XML节的服务器规则 Server Rules for Handling XML Stanzas (第十一章)).
:# 隐私列表必须(MUST)是第一个由服务器应用的递送规则, 替代 (1) 定义在用于处理XML节的服务器规则Server Rules for Handling XML Stanzas (第十一章)的路由和递送规则, 以及 (2)和订阅相关的出席信息节的处理(和相应的名册推送的生成) 定义在名册条目和出席信息订阅的集成Integration of Roster Items and Presence Subscriptions (第八章).
:# 服务器处理隐私列表条目的顺序是很重要的. 列表条目必须(MUST)按照每个<item/>的'order'属性的整数值的升序来处理.
:# 一旦节和一个隐私列表规则匹配, 服务器必须(MUST)按照这个规则适当地处理这个节,然后终止处理.
:# 如果在一个列表中没有提供一个fall-through的条目, fall-through 动作被假定为允许"allow".
:# 如果一个用户为一个激活列表更新定义, 之后的基于那个激活列表的操作必须(MUST)使用更新的定义(为了那些激活列表正应用的所有资源).
:# 如果在用户的会话期间,在激活的或缺省的列表中定义的名册条目中的订阅状态改变了,或名册组改变了,接下来基于那个列表的处理必须(MUST)考虑计入这个已改变的状态或组(对那个列表当前应用的所有资源).
:# 当一个规则的定义修改了的时候, 服务器必须(MUST)发送一个类型为"set"的IQ节给所有已连接的资源, 包括一个只有一个<list/>子元素的<query/>元素, 其'name'属性设为已修改的隐私列表的名字. 这些隐私列表推送("privacy list pushes")遵守和用于名册管理的名册推送("roster pushes")同样的语义 , 除了被推送给已连接的资源的列表名字本身(不是完整的列表定义或那个"delta"). 是否接受这个修改了的列表定义最终由接收中的资源来决定, 尽管如果这个列表正在应用于一个已连接的资源,它应该(SHOULD)这样做.
:# 当一个已连接的资源尝试移除一个列表或指定一个新的缺省列表,而那个列表应用于一个已连接的资源而不是正在发送的资源, 服务器必须(MUST)返回一个<conflict/>错误给发送中的资源并且不能(MUST NOT)执行这个请求的改变.

===接收某人的隐私列表===

:例子: 客户端向服务器请求隐私列表的名字:

<source lang="xml">
<iq from='romeo@example.net/orchard' type='get' id='getlist1'>
<query xmlns='jabber:iq:privacy'/>
</iq>
</source>

:例子: 服务器发送隐私列表的名字给客户端, 激活列表和缺省列表放在前面:

<source lang="xml">
<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>
</source>

:例子: 客户端向服务器请求一个隐私列表:

<source lang="xml">
<iq from='romeo@example.net/orchard' type='get' id='getlist2'>
<query xmlns='jabber:iq:privacy'>
<list name='public'/>
</query>
</iq>
</source>

:例子: 服务器发送一个隐私列表给客户端:

<source lang="xml">
<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>
</source>

:例子: 客户端向服务器请求另一个隐私列表:

<source lang="xml">
<iq from='romeo@example.net/orchard' type='get' id='getlist3'>
<query xmlns='jabber:iq:privacy'>
<list name='private'/>
</query>
</iq>
</source>

:例子: 服务器发送另一个隐私列表给客户端:

<source lang="xml">
<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>
</source>

:例子: 客户端再向服务器请求另一个隐私列表:

<source lang="xml">
<iq from='romeo@example.net/orchard' type='get' id='getlist4'>
<query xmlns='jabber:iq:privacy'>
<list name='special'/>
</query>
</iq>
</source>

:例子: 服务器再发送另一个隐私列表给客户端:

<source lang="xml">
<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>
</source>

:在这个例子中, 用户有三个列表: (1) 'public', 它允许所有人的通信,除了一个指定的实体(这是缺省列表); (2) 'private', 它只允许和这个用户有双向订阅的联系人的通信(这是激活的列表); 还有 (3) 'special', 它只允许三个指定的实体通信.

:如果用户尝试接收一个列表但是这个列表的名字不存在, 服务器必须(MUST)返回一个<item-not-found/>节错误给用户:

:例子: 客户端尝试接收不存在的列表:

<source lang="xml">
<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>
</source>

:用户在一次只被允许接收一个列表. 如果用户尝试同一个请求中接收超过一个列表, 服务器必须(MUST)返回一个<bad request/>节错误给用户:

:例子: 客户端尝试接收多于一个的列表:

<source lang="xml">
<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>
</source>

===管理激活列表===

:为了设置或改变服务器当前应用的激活列表, 用户必须(MUST)发送一个类型为"set"的IQ节,包含一个符合'jabber:iq:privacy'名字空间的<query/>元素,这个元素<query/>又包含一个空的<active/>子元素,而这个<active/>拥有一个'name'属性,'name'属性值则设为期望的列表名.

:例子: 客户端请求激活列表变更:

<source lang="xml">
<iq from='romeo@example.net/orchard' type='set' id='active1'>
<query xmlns='jabber:iq:privacy'>
<active name='special'/>
</query>
</iq>
</source>

:服务器必须(MUST)在返回结果给客户端之前激活并应用这个已请求的列表.

:例子: 服务器承认激活列表变更成功:

<source lang="xml">
<iq type='result' id='active1' to='romeo@example.net/orchard'/>
</source>

:如果用户尝试设置一个激活列表但是列表名不存在, 服务器必须(MUST)返回一个<item-not-found/>节错误给用户:

:例子: 客户端尝试设置一个不存在的列表作为激活列表:

<source lang="xml">
<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>
</source>

:为了取消使用任何激活列表, 已连接的资源必须(MUST)发送一个空的<active/>元素,并且不带'name'属性.

:例子: 客户端取消使用激活列表:

<source lang="xml">
<iq from='romeo@example.net/orchard' type='set' id='active3'>
<query xmlns='jabber:iq:privacy'>
<active/>
</query>
</iq>
</source>

:例子: 服务器承认取消任何激活列表成功:

<source lang="xml">
<iq type='result' id='active3' to='romeo@example.net/orchard'/>
</source>

===管理缺省列表===

:为了改变它的缺省列表(它对用户来说是全局应用的, 不只是发送中的资源), 用户必须(MUST)发送一个类型为"set"的IQ节, 它包含一个符合'jabber:iq:privacy'名字空间的<query/>元素,这个<query/>元素包含一个空的<default/>子元素,这个<default/>子元素拥有一个'name'属性,这个'name'属性的值设为期望的列表名.

:例子: 用户请求变更缺省列表:

<source lang="xml">
<iq from='romeo@example.net/orchard' type='set' id='default1'>
<query xmlns='jabber:iq:privacy'>
<default name='special'/>
</query>
</iq>
</source>

:例子: 服务器承认缺省列表变更成功:

<source lang="xml">
<iq type='result' id='default1' to='romeo@example.net/orchard'/>
</source>

:如果用户尝试变更一个缺省列表但是这个缺省列表正在由至少一个已连接的但不是当前发送中的这个资源使用着,服务器必须(MUST)返回一个<conflict/>节错误给发送中的资源:

:例子: 客户端尝试改变一个缺省列表但是这个列表正在被另一个资源使用:

<source lang="xml">
<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>
</source>

:如果用户尝试设置一个缺省列表但是这个列表的名字不存在, 服务器必须(MUST)返回一个<item-not-found/>节错误给用户:

:例子: 客户端尝试设置一个不存在的列表作为缺省列表:

<source lang="xml">
<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>
</source>

:为了取消使用缺省列表(换言之, 任何时候都使用域的节路由规则), 用户必须(MUST)发送一个空的不带'name'属性的<default/>元素.

:例子: 客户端取消使用缺省列表:

<source lang="xml">
<iq from='romeo@example.net/orchard' type='set' id='default2'>
<query xmlns='jabber:iq:privacy'>
<default/>
</query>
</iq>
</source>

:例子: 服务器承认成功地取消了任何缺省列表:

<source lang="xml">
<iq type='result' id='default2' to='romeo@example.net/orchard'/>
</source>

:如果一个已连接的资源尝试取消一个用户全局的缺省列表但是这个缺省列表正在应用于另一个已连接的资源,服务器必须(MUST)返回一个<conflict/>错误给发送中的资源:

:例子: 客户端尝试取消一个缺省列表但是这个列表正在被另一个资源使用:

<source lang="xml">
<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>
</source>

===编辑一个隐私列表===

:为了编辑一个隐私列表, 用户必须(MUST)一个类型为"set"的IQ节,包含一个符合'jabber:iq:privacy'名字空间的<query/>元素,这个<query/>元素包含一个拥有一个<list/>子元素,这个<list/>子元素拥有一个'name'属性,这个'name'属性的值设为用户想编辑的列表名. 这个<list/>元素必须(MUST)包含一个或多个<item/>元素, 它们包含了列表中的所有元素以指明用户期望的对列表的变更(不是the "delta").

:例子: 客户端编辑隐私列表:

<source lang="xml">
<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>
</source>

:例子: 服务器承认列表编辑成功:

<source lang="xml">
<iq type='result' id='edit1' to='romeo@example.net/orchard'/>
</source>

:注意: 任何给定的条目的'order'属性值不是固定的. 因而在前述的例子中如果用户想在"tybalt@example.com"条目和"paris@example.org"条目之间增加4个条目, 用户的客户端必须(MUST)在向服务器提交列表之前对相关的条目重新编号.

:服务器必须(MUST)现在发送一个隐私列表推送"privacy list push"给所有已连接的资源:

:例子: 基于列表编辑的隐私列表推送:

<source lang="xml">
<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/home' type='set' id='push2'>
<query xmlns='jabber:iq:privacy'>
<list name='public'/>
</query>
</iq>
</source>

:按照定义在[XMPP-CORE|XMPP文档列表/XMPP正式RFC标准/RFC3920]的IQ节语义, 每个已连接的子元素必须(MUST)返回一个如下的 IQ result 给服务器:

:例子: 承认收到一个隐私列表推送:

<source lang="xml">
<iq from='romeo@example.net/orchard'
type='result'
id='push1'/>
<iq from='romeo@example.net/home'
type='result'
id='push2'/>
</source>

===增加一个新的隐私列表===

:增加一个新的列表和编辑一个现有的列表使用的协议是相同的. 如果列表名和现有的列表名吻合, 这个增加新列表的请求将覆写那个旧的列表. 正如编辑列表一样, 服务器也必须(MUST)发送一个隐私列表推送"privacy list push" 给所有已连接的资源.

===移除一个隐私列表===

:为了移除一个隐私列表, 用户必须(MUST)发送一个类型为"set"的IQ节,包含一个符合'jabber:iq:privacy'名字空间的<query/>元素,这个<query/>元素包含一个空的<list/>子元素,这个<list/>子元素拥有一个'name'属性,这个'name'属性的值设为用户想移除的列表名.

:例子: 客户端移除一个隐私列表:

<source lang="xml">
<iq from='romeo@example.net/orchard' type='set' id='remove1'>
<query xmlns='jabber:iq:privacy'>
<list name='private'/>
</query>
</iq>
</source>

:例子: 服务器承认成功地移除列表:

<source lang="xml">
<iq type='result' id='remove1' to='romeo@example.net/orchard'/>
</source>

:如果一个用户尝试移除一个列表而这个列表正在被应用于至少一个和发送中的资源不同的已连接的资源, 服务器必须(MUST)返回一个<conflict/>节错误给用户; 换言之, 用户在尝试移除它之前必须(MUST)先设置另一个列表成为激活或缺省列表. 如果用户尝试移除一个列表但是列表名字不存在, 服务器必须(MUST)返回一个<item-not-found/>节错误给用户. 如果用户尝试在同一个请求中移除超过一个的列表, 服务器必须(MUST)反回一个<bad request/>节错误给用户.

===屏蔽消息===

:服务器端的隐私列表使得一个用户可以基于实体的JID,名册组,或订阅状态(或全局地)来屏蔽从其他实体引入的消息. 以下例子阐明这个协议. (注意: 为了精简, "result"类型的IQ节没有在以下例子中显示, 隐私列表推送也没有显示.)

:例子: 基于JID的用户屏蔽:

<source lang="xml">
<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>
</source>

:作为建立和应用前述列表的结果, 用户将不会接收到从特定JID发来的消息.

:例子: 基于名册组的用户屏蔽:

<source lang="xml">
<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>
</list>
</query>
</iq>
</source>

:作为建立和应用前述列表的结果, 用户将不会收到从指定名册组中的任何实体发来的消息.

:例子: 基于订阅状态的用户屏蔽:

<source lang="xml">
<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>
</source>

:作为建立和应用前述列表的结果, 用户将不会收到从任何指定订阅状态的实体发来的消息.

:例子: 全局的用户屏蔽:

<source lang="xml">
<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>
</source>

:作为建立和应用前述列表的结果, 用户将不会收到从任何其他用户发来的消息.

===屏蔽入站出席信息通知===

:服务器端的隐私列表使得用户可以基于实体的JID,名册组,或订阅状态(或全局地)屏蔽来自其他实体的入站出席信息通知. 以下例子阐明了这个协议.

:注意: 出席信息通知不包括出席信息订阅,只是把出席信息广播给当前已订阅某个联系人的出席信息的用户. 所以它只包括没有'type'属性的或type='unavailable'的出席信息节.

:例子: 基于JID的用户屏蔽:

<source lang="xml">
<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>
</source>

:作为建立和应用前述列表的结果, 用户将不会收到从指定JID发来的出席信息通知.

:例子: 基于名册组的用户屏蔽:

<source lang="xml">
<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>
</source>

:作为建立和应用前述列表的结果, 用户将不会从指定的名册组中的任何实体收到出席信息通知.

:例子: 基于订阅状态的用户屏蔽:

<source lang="xml">
<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>
</source>

:作为建立和应用前述列表的结果, 用户将不会从指定订阅状态的任何实体收到出席信息通知.

:例子: 全局的用户屏蔽:

<source lang="xml">
<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>
</source>

:作为建立和应用前述列表的结果, 用户将不会从任何其他实体收到出席信息通知.

===评比出站出席信息通知===

:服务器端的隐私列表使用户能够屏蔽发出到其他实体的出席信息通知(基于实体的JID, 名册组, 或订阅状态 (或全局的)). 以下例子阐明了这个协议.

:注意: 出席信息通知不包括出席信息订阅,只把出席信息广播给已订阅了用户的出席信息的联系人.所以只包括没有'type'属性或type='unavailable'的出席信息节.

:例子: 基于JID的用户屏蔽:

<source lang="xml">
<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>
</source>

:作为建立和应用前述列表的结果, 用户将不会给指定JID发送出席信息通知.

:例子: 基于名册组的用户屏蔽:

<source lang="xml">
<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>
</source>

:作为建立和应用前述列表的结果, 用户将不会向指定名册组的任何实体发送出席信息通知.

:例子: 基于订阅状态的用户屏蔽:

<source lang="xml">
<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/>
</item>
</list>
</query>
</iq>
</source>

:作为建立和应用前述列表的结果, 用户将不会向指定订阅状态的任何实体发送出席信息通知.

:例子: 全局的用户屏蔽:

<source lang="xml">
<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>
</source>

:作为建立和应用前述列表的结果, 用户将不会向任何其他用户发送出席信息通知.

===屏蔽IQ节===

:服务器端的隐私列表使用户能够屏蔽从其他实体进来的IQ节(基于实体的JID,名册组, 或订阅状态(或全局地)). 以下例子阐明了这个协议.

:例子: 基于JID的用户屏蔽:

<source lang="xml">
<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>
</source>

:作为建立和应用这个列表的结果, 用户将不会收到从指定JID发来的IQ节.

:例子: 基于名册组的用户屏蔽:

<source lang="xml">
<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>
</source>

:作为建立和应用前述列表的结果, 用户将不会收到从指定名册组的任何实体发来的IQ节.

:例子: 基于订阅状态的用户屏蔽:

<source lang="xml">
<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>
</source>

:作为建立和应用前述列表的结果, 用户将不会收到从指定订阅状态的任何实体发来的IQ节.

:例子: 全局的用户屏蔽:

<source lang="xml">
<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>
</source>

:作为建立和应用前述列表的结果, 用户将不会收到从任何其他用户发来的IQ节.

===屏蔽所有通信===

:服务器端的隐私列表使用户能够基于其他实体的JID,名册组,或订阅状态(或全局的)屏蔽所有进来和出去的节. 注意那部包括订阅相关的出席信息节, 它们被排除在外 (定义在屏蔽入站出席信息通知Blocking Inbound Presence Notifications (第十章第十节)). 以下例子阐明了这个协议.

:例子: 基于JID的用户屏蔽:

<source lang="xml">
<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>
</source>

:作为建立和应用这个列表的结果, 用户将不会收到和发送任何通信给指定JID.

:例子: 基于名册组的用户屏蔽:

<source lang="xml">
<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'
action='deny'
order='13'/>
</list>
</query>
</iq>
</source>

:作为建立和应用前述列表的结果, 用户将不会收到和发送和指定名册组的任何实体的通信.

:例子: 基于订阅状态的用户屏蔽:

<source lang="xml">
<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>
</source>

:作为建立和应用前述列表的结果, 用户将不会收到和发送和指定订阅状态的任何实体的通信.

:例子: 全局的用户屏蔽:

<source lang="xml">
<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>
</source>

:作为建立和应用前述列表的结果, 用户将不会收到和发送和任何其他用户的通信.

===已被屏蔽的实体尝试和用户通信===

:如果一个已被屏蔽的实体尝试发送消息或出席信息给用户, 用户的服务器应该(SHOULD)安静的丢掉这个节并且不能(MUST NOT)返回一个错误给发送的实体.

:如果一个已被屏蔽的实体尝试发送一个类型为"get"或"set"的IQ节给用户, 用户的服务器必须(MUST)给发送的实体一个<service-unavailable/>节错误, 因为这是一个客户端不理解IQ get或set的名字空间的时候所发送的标准错误码. 其他类型的IQ节应该(SHOULD)被服务器安静的丢弃.

:例子: 已被屏蔽的实体尝试发送 IQ get:

<source lang="xml">
<iq type='get'
to='romeo@example.net'
from='tybalt@example.com/pda'
id='probing1'>
<query xmlns='jabber:iq:version'/>
</iq>
</source>

:例子: 服务器返回一个错误给已被屏蔽的实体:

<source lang="xml">
<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>
</source>

===高级启发===

:当建立一个高级隐私启发的表达式的时候, 客户端应该(SHOULD)使用尽可能简单的表达式.

:例如, 启发 "屏蔽不在我名册中的任何用户的通信" 可以使用以下任何一种方式来构造:

:* 允许任何来自我的名册中的JID的通信 (换言之, 列出每个JID成为单独的列表条目), 但是屏蔽和其他任何人的通信

:* 允许任何来自我的名册的某个组中的用户的通信(换言之, 列出每个组作为单独的条目), 但是屏蔽和任何其他人的通信

:* 允许任何我的他(她)之间的订阅状态为'both'或'to'或'from'的用户的通信(换言之, 单独列出每个订阅状态值), 但是屏蔽和任何其他人的通信

:* 屏蔽和任何订阅状态为'none'的用户的通信

:最后一个表达式是最简单的并且应该(SHOULD)被使用; 这种情形下将被发送的XML如下:

<source lang="xml">
<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>
</source>

==服务器处理XML节的规则==

:用于服务器的基本路由和递送规则定义在[XMPP-CORE|XMPP文档列表/XMPP正式RFC标准/RFC3920]中. 本章定义附加的用于XMPP兼容的即时消息和出席信息服务器规则.

===入站节===

:如果一个入站的节的'to'属性的JID中的域标识符部分的主机名和服务器自身的主机名相同并且'to'属性的JID的格式是<user@example.com>或<user@example.com/resource>, 服务器必须(MUST)首先强制应用任何隐私列表(第十章),然后服从以下定义的规则:

:# 如果JID的格式是<user@domain/resource>并且有一个可用的资源和这个全JID吻合, 接受这得服务器必须(MUST)递送这个节给那个资源.
:# 然后如果JID的格式是<user@domain>或格式是<user@domain/resource>,并且和用户相关的帐号不存在, 接收者的服务器 (a) 如果它是一个出席信息节,应该(SHOULD) 安静的忽略这个节(换言之,既不递送它也不返回一个错误), (b) 如果它是一个IQ节,必须(MUST)返回一个<service-unavailable/>节错误给发送者, 并且 (c) 如果它是一个消息节,应该(SHOULD)返回一个<service-unavailable/>节错误给发送者.
:# 然后如果JID的格式是<user@domain/resource>并且没有可用的资源和它的全JID匹配, 接收者的服务器 (a) 如果它是一个出席信息节,应该(SHOULD)安静地忽略这个节(换言之, 既不递送它也不返回一个错误), (b) 如果它是一个IQ节,必须(MUST)返回一个<service-unavailable/>节错误给发送者, 并且 (c) 如果它是一个消息节,应该(SHOULD)把这个节视为发往<user@domain>.
:# 然后如果JID的格式是<user@domain>并且这个用户至少有一个可用的资源, 接收者的服务器必须(MUST)遵守以下规则:
:## 对于消息节, 服务器应该(SHOULD)递送这个节给高优先级的可用资源(如果这个资源没有提供<priority/>元素的值, 服务器应该(SHOULD)认为它提供的值为零). 如果两个或更多的可用资源有相同的优先级, 服务器可以(MAY)使用一些其他的规则(例如, 最近的连接时间, 最近的活动时间, 或由一些<show/>值的层次所定义的最高的可用性) 来从它们中间选择,或可以(MAY)递送这个消息到所有这些资源. 无论如何, 服务器不能(MUST NOT)这个节到一个优先级为负数的可用资源; 如果唯一的一个可用资源的优先级是负数, 服务器应该(SHOULD)当成没有可用资源一样处理这个消息(定义在后面). 另外, 服务器不能(MUST NOT)重写'to'属性(换言之, 它必须(MUST)让它保持<user@domain>而不是改成<user@domain/resource>).
:## 对于类型不是"probe"的出席信息节, 服务器必须(MUST)递送这个节给所有可用的资源;对于出席信息调查, 服务器应该(SHOULD)基于定义在出席信息调查Presence Probes (第五章第一节第三小节)的规则来应答. 另外, 服务器不能(MUST NOT)重写'to'属性(换言之, 它必须(MUST)保持<user@domain>而不是改为<user@domain/resource>).
:## 对于IQ节, 服务器本身必须(MUST)代替用户应答一个IQ result或一个IQ error, 并且不能(MUST NOT)递送这个IQ节给任何可用的资源. 具体来说, 如果合格的名字空间的语义定义了一个服务器可以提供的应答, 服务器必须(MUST)代替用户应答这个节; 如果没有, 服务器必须(MUST)应答一个<service-unavailable/>节错误.
:# 然后如果JID的格式为<user@domain>并且没有这个用户的可用资源, 这个节如何处理依赖于节的类型:
:## 对于类型为"subscribe", "subscribed", "unsubscribe", 和"unsubscribed"的出席信息节, 服务器必须(MUST)维持这个节的一个记并且至少递送这个节一次(也就是, 当这个用户下次建立一个可用的资源的时候); 另外, 服务器必须(MUST)递送类型为"subscribe"的出席信息节直到用户批准或拒绝这个订阅请求为止(参见出席信息订阅Presence Subscriptions (第五章第一节第六小节)).
:## 对于所有其他的出席信息节, 服务器应该(SHOULD)安静的忽略这个节,既不存储它用于以后递送也不代替用户应答它.
:## 对于消息节, 服务器可以(MAY)选择代替用户存储这个节并且当用户下次可用的时候递送给他, 或通过一些其他的手段转发这个消息给用户(例如, 给用户的邮箱). 无论如何, 如果离线消息存储或消息转发没有激活, 服务器必须(MUST)返回发送者一个<service-unavailable/>节错误. (注意:离线信息存储和消息转发没有定义在 XMPP, 因为严格来说它们是实现和服务提供的问题.)
:## 对于IQ节, 服务器本身必须(MUST)代替用户应答一个IQ result或一个IQ error. 具体来说,如果合法的名字空间的语义定义了一个服务器可以提供的应答, 服务器必须(MUST)代替用户应答这个节; 如果没有, 服务器必须(MUST)应答一个<service-unavailable/>节错误.

===出站节===

:如果出站节的'to'属性的地址的域标识符部分的主机名和服务器自身的一个主机名吻合, 服务器必须(MUST) 根据入站节Inbound Stanzas(第十一章第一节)的规则递送这个节给一个本地实体.

:如果出站节的'to'属性的地址的域标识符部分的主机名不和服务器自身的一个主机名吻合, 服务器必须(MUST)尝试路由这个节到外部域. 推荐的动作顺序定义如下:

:# 首先尝试用一个"xmpp-server"服务和"tcp"协议的\[SRV\]服务解析这个外部的主机名,结果得到的资源记录格式如"_xmpp-server._tcp.example.com.", 定义在[XMPP-CORE|XMPP文档列表/XMPP正式RFC标准/RFC3920].
:# 如果"xmpp-server"地址记录解析失败, 尝试解析"_im"或"_pres"\[SRV\]服务(定义在\[IMP-SRV\]), 使用"_im"服务用语<message/>节,使用"_pres"服务用语<presence/>节(如何处理<iq/>节取决于具体实现). 这样得到的结果是一个或多个格式为"_im.<proto>.example.com."或 "_pres.<proto>.example.com."的记录, 这里"<proto>"是一个注册在即时消息SRV协议标签注册表Instant Messaging SRV Protocol Label registry中的一个标签,或者是出席信息SRV协议标签注册表Presence SRV Protocol Label registry中的标签: 要么是"_xmpp",用于XMPP-aware的域,要么是一些 IANA注册的标签IANA-registered label (例如,"_simple") 用于 non-XMPP-aware 的域.
:# 如果这两种SRV地址记录解析都失败了, 尝试执行一个通用的 IPv4/IPv6 地址记录解析来决定IP地址,使用"xmpp-server"端口号5269(已在IANA注册, 定义在[XMPP-CORE|XMPP文档列表/XMPP正式RFC标准/RFC3920]).

:强烈鼓励部署服务器的管理员们保持 _im._xmpp, _pres._xmpp, 和 _xmpp._tcp SRV 记录正确同步, 因为不同的实现可能在"xmpp-server"查找之前执行"_im"和"_pres"查找.

==即时消息和出席信息兼容性需求==

:本章总结了即时消息和出席信息服务器和客户端为了保证兼容的实现而必须(MUST)支持的部分XMPP协议. 所有这些应用必须(MUST)遵守定义在[XMPP-CORE|XMPP文档列表/XMPP正式RFC标准/RFC3920]的要求. 本章的文字定义了附加的用于即时消息和出席信息的兼容性需求; 注意定义在这里的要求补充而不是替代核心需求. 也要注意一个服务器或客户端可以(MAY)仅支持出席信息或即时消息, 如果只想支持出席信息服务或即时消息服务,可以不必同时支持两个.

===服务器===

:除了核心服务器兼容需求之外, 一个即时消息和出席信息服务器必须(MUST)还要支持以下协议:

:* 定义在本文中的所有服务器相关的即时消息和出席信息语法和语义, 包括代替客户端广播出席信息, 出席信息订阅, 名册存储和处理, 隐私列表, 以及 IM-specific 路由和递送规则

===客户端===

:除了核心的客户端兼容性需求之外, 一个即时消息和出席信息客户端还必须(MUST)支持以下协议:

:* 生成和处理由XML规划定义的XML节的IM-specific语义, 包括消息和出席信息节以及它们的子元素的的'type'属性

:* 所有本文定义的客户端相关的即时消息语法和语义, 包括出席信息订阅, 名册管理, 和隐私列表

:* 端到端的对象加密(定义在 XMPP中的端到端对象加密End-to-End Object Encryption in the Extensible Messaging and Presence Protocol (XMPP) \[XMPP-E2E\])

:一个客户端也必须(MUST)处理编码为"im:" URIs的地址(定义在\[CPIM\]), 并且可以(MAY)移除"im:"scheme并把地址解析委托给服务器(定义在出站节Outbound Stanzas(第十一章第二节).

==国际化事项==

:关于国际化的考虑, 参考[XMPP-CORE|XMPP文档列表/XMPP正式RFC标准/RFC3920]相关章节.

==安全性事项==

:XMPP的核心安全性事项定义在[XMPP-CORE|XMPP文档列表/XMPP正式RFC标准/RFC3920]相关章节.

:附加的事项仅适用于分散定义在本文许多地方的XMPP即时消息和出席信息应用; 特别是:

:* 当一个服务器处理一个任何类型的入站节,这个节的预定接收者是和服务器的主机名相关的一个用户,服务器必须(MUST)首先强制应用任何隐私列表(第十章),见处理XML节的服务器规则Server Rules for Handling XML Stanzas(第十一章)).

:* 当一个服务器处理一个类型为"probe"的入站出席信息节,这个节的预定接收者是和服务器的主机名相关的一个用户, 如果这个发送者是一个由出席信息订阅决定的未被授权接收那个信息的实体,服务器不能(MUST NOT)揭露这个用户的出席信息(见客户端和服务器出席信息职责Client and Server Presence Responsibilities (第五章第一节)).

:* 当一个服务器处理一个任何类型的出站出席信息节,这个节没有type属性或type属性值为"unavailable", 为了确保这个出席信息不被广播给那些未被授权知道这个信息的实体, 它必须(MUST)服从客户端和服务器出席信息职责Client and Server Presence Responsibilities (第五章第一节) 定义的规则 .

:* 当一个服务器生成一个错误节作为不存在的用户接收到的一个节的应答的时候, 使用<service-unavailable/>错误条件有助于防止著名的字典攻击, 因为这个错误和条件和其他一些错误条件相同,例如, 一个IQ子元素的名字空间不被理解, 或离线存储或消息转发不被一个域允许.

==IANA事项==

:很多相关的IANA事项, 参考[XMPP-CORE|XMPP文档列表/XMPP正式RFC标准/RFC3920]相关章节.

===会话数据的XML名字空间名===

:以下为XMPP中会话相关的数据定义了一个 URN 子名字空间. (这个名字空间名的格式遵循 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>

===即时消息SRV协议标签注册===

:确定即时消息和出席信息地址[IMP-SRV],为那些能提供遵守"_im"SRV服务标签的服务定义了一个即时消息SRV协议标签注册表. 因为XMPP是其中一个协议, IANA在适当的注册项中注册了"_xmpp"协议标签,如下:

::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>

===出席信息SRV协议标签注册===

:确定即时消息和出席信息地址\[IMP-SRV\],为那些能够提供遵守"_pres"SRV服务标签的服务定义了一个出席信息SRV协议标签注册项. 因为XMPP是其中一个协议, IANA在适当的注册项中注册了"_xmpp"协议标签,如下:

::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>

==参考==

===标准参考===

:[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-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.

:[TERMS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.

:[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>.

:[XMPP-CORE|XMPP文档列表/XMPP正式RFC标准/RFC3920] 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.

===信息参考===

:[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.

:[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-0078] Saint-Andre, P., "Non-SASL Authentication", JSF JEP 0078, July 2004.

:[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.

:[XML-REG] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, January 2004.

==附录 A. vCards==

:[IMP-REQS]的第三章第一节第三小节和第四章第一节第四小节要求可能为其他用户接收带外的联系人信息(例如,电话号码或电子邮件地址). 在Jabber社区中通常使用RFC 2426 [VCARD]中vCard规范的XML来表达这类信息,但这超出了XMPP的范围(这个协议的文档包含在[JEP-0054], 由[JSF]发行).

译者注: [JSF]已改名为[XSF],[JEP-0054]已改名为[XEP-0054]

==附录 B. XML规划==

:接下来的XML规划是描述性的, 不是标准化的. 规划定义在XMPP的核心特性, 参考[XMPP-CORE|XMPP文档列表/XMPP正式RFC标准/RFC3920].

===B.1 jabber:client===

<source lang="xml">
<?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: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: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='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='presence'>
<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>

<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='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: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>
</source>

===B.2 jabber:server===

<source lang="xml">

<?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: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: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='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='presence'>
<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='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='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='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'
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>
</source>

===B.3 session===

<source lang="xml">
<?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:element name='session' type='empty'/>

<xs:simpleType name='empty'>
<xs:restriction base='xs:string'>
<xs:enumeration value=''/>
</xs:restriction>
</xs:simpleType>

</xs:schema>
</source>

===B.4 jabber:iq:privacy===

<source lang="xml">

<?xml version='1.0' encoding='UTF-8'?>

<xs:schema
xmlns:xs='http://www.w3.org/2001/XMLSchema'
targetNamespace='jabber:iq:privacy'
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='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='list'>
<xs:complexType>
<xs:sequence>
<xs:element ref='item'
minOccurs='0'
maxOccurs='unbounded'/>
</xs:sequence>
<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:simpleType name='empty'>
<xs:restriction base='xs:string'>
<xs:enumeration value=''/>
</xs:restriction>
</xs:simpleType>

</xs:schema>
</source>

===B.5 jabber:iq:roster===

<source lang="xml">

<?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: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: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:schema>
</source>

==附录 C. Jabber IM Presence协议和XMPP之间的不同==

:本章是非标准的.

:译者注：附录D对于新接触XMPP的人没有什么意义，就不翻译了，免得浪费时间。因为现在RFC公布已经很久了，以前的Jabber实现很多都进化到XMPP了。

: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|XMPP文档列表/XMPP正式RFC标准/RFC3920] summarizes the differences that relate to all XMPP applications.

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

===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.

==贡献者==

:XMPP的大部分核心方面是由1999年开始的Jabber开源社区开发的. 这个社区是由 Jeremie Miller建立的, 他于1999年1月发布了最初版的jabber server源代码. 主要的基础协议的早期贡献者还包括 Ryan Eatmon, Peter Millard, Thomas Muldowney,和 Dave Smith. XMPP工作组在即时消息和出席信息方面的工作主要集中在IM会话建立和通信屏蔽(隐私列表); 会话建立协议主要是由 Rob Norris 和 Joe Hildebrand 开发的, 隐私列表协议最初是由 Peter Millard.贡献的

==致谢==

:感谢许多在贡献者名单之外的人们. 尽管很难提供一个完整的名单, 以下个人对于定义协议或评论标准提供了很多帮助:
: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. 也感谢 XMPP工作组的成员和 IETF 社区在本文的成文过程中一直提供的评论和反馈。

==作者地址==

:Peter Saint-Andre (编辑)
:Jabber Software Foundation

:EMail: stpeter@jabber.org

==完整的版权声明==

: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 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.

==知识产权==

: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.

: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.

==感谢==

:目前为RFC编辑活动提供资金的Internet Society.

RFC3920

2010-05-27T08:46:58Z

Fantasysoft: /* 协议 */

[[Category:XMPP正式RFC标准]]
[[Category:已翻译]]

"本文的英文原文来自[http://www.ietf.org/rfc/rfc3920.txt RFC 3920]

{|
|网络工作组 || P. Saint-Andre, Ed.
|-
|申请讨论: 3920 || Jabber软件基金会
|-
|类别: 标准跟踪 || 2004年10月
|}

:::'''可扩展的消息和出席信息协议 (XMPP): 核心协议'''

'''关于本文的说明'''

:本文为互联网社区定义了一个互联网标准跟踪协议，并且申请讨论协议和提出了改进的建议。请参照“互联网官方协议标准”的最新版本（STD 1）获得这个协议的标准化进程和状态。本文可以不受限制的分发。

'''版权声明'''

:本文版权属于互联网社区 (C) The Internet Society (2004).

'''摘要'''

:本文定义了可扩展消息和出席信息协议（XMPP）的核心功能，这个协议采用XML流实现在任意两个网络终端接近实时的交换结构化信息。XMPP提供一个通用的可扩展的框架来交换XML数据，它主要用来建立即时消息和出席信息应用以实现 RFC 2779 的需求。

==绪论==

===概览===

:XMPP是一个开放式的XML协议，设计用于准实时消息和出席信息以及请求-响应服务。其基本的语法和语义最初主要是由Jabber开放源代码社区于1999年开发的。2002年，XMPP工作组被授权接手开发和改编Jabber协议以适应IETF的即时消息和出席信息技术。作为XMPP工作组的成果，本文定义了 XMPP 1.0 的核心功能；在 RFC 2779 [IMP-REQS] 中指定的提供即时消息和出席信息功能的扩展，定义在 XMPP-IM 协议 [the Extensible Messaging and Presence Protocol (XMPP): Instant Messaging and Presence] 中。

===术语===

:本文中大写的关键字 "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", 和 "OPTIONAL" 的确切含义符合 BCP 14, RFC 2119 \[TERMS\].

==通用的架构==

===概览===

:尽管XMPP没有指定任何特定的网络结构，但它通常是采用客户-服务器架构进行实现，其中客户端通过TCP方式使用XMPP访问服务器，服务器之间也采用TCP方式进行通信。

:以下是这一架构的抽象的示意图 (这里 "-" 表示使用 XMPP 通讯， "=" 表示可使用任何协议通讯)。

::C1----S1---S2---C3

::::|

::C2----+---G1===FN1===FC1

:符号的含义如下:

::* C1, C2, C3 = XMPP 客户端

::* S1, S2 = XMPP 服务器

::* G1 = 一个XMPP和外部（非XMPP）消息网络之间进行“翻译”的网关

::* FN1 = 一个外部消息网络

::* FC1 = 外部消息网络上的一个客户端

===服务器===

:服务器充当XMPP通信的一个智能抽象层，它主要负责:

:* 对受验证的客户端，服务器以及其他实体之间以XML流形式的连接和会话进行管理。

:* 在这些实体间使用XML流对合理编址的XML节（第九章）进行路由

:大部分 XMPP 兼容的服务器也负责存储客户端使用的数据 (比如基于XMPP协议的及时消息应用中的联系人名单); 在这种情况下， XML 数据直接服务器来处理，而不需要转发到其他实体。

===客户端===

:大部分客户端通过 TCP 连接直接连到服务器，并通过XMPP获得由服务器以及联合服务器所提供的全部功能。多个不同资源（比如不同的设备和地点）的客户端'''可以'''同时登陆并且并发的连接到一个服务器，每个不同资源的客户端通过XMPP地址的资源标识符来区分（比如<node@domain/ home> 和 <node@domain/work>），参见地址空间（第三章）。'''建议'''的客户端和服务器连接的端口是 5222 ，这个端口已经在 IANA（在第十五章第九节查阅端口号码）注册了。

===网关===

:网关是一个特殊用途的服务器端的服务，主要功能是把 XMPP 翻译成外部(非XMPP)消息系统，并把返回的消息翻译成 XMPP 。例如到 email（参见 [SMTP] ），IRC（参见 [IRC] ），SIMPLE（参见 [SIMPLE] ），SMS 的网关；还有和别的消息服务的网关，比如AIM，ICQ，MSN Messenger，Yahoo! Instant Messenger。网关和服务器之间的通信，网关和外部消息系统的通信，不在本文描述范围之内。

===网络===

:因为每个服务器都是由一个网络地址来标识的并且服务器之间的通信是客户-服务器协议的直接扩展，实际上整个系统是由很多互通的服务器构成的。例如，<juliet@example.com> 可以和 <romeo@example.net> 交换消息,出席信息和其他信息。这种模式常见于那些需要使网络地址标准化的协议（比如 SMTP ）。任意两个服务器之间的通信是可选（OPTIONAL）的。如果被激活，那么这种通信应该（SHOULD）通过 XML 流绑定到 TCP 连接上进行。建议的（RECOMMENDED）服务器之间的连接端口为 5269 ，这个端口号已经在 IANA （在第十五章第九节查阅端口号码）注册了。

==地址空间==

===概览===

:一个实体可以是任何一个被认为是一个网络端点的东西(例如网络上的一个 ID )，而且它是通过XMPP进行通信的。所有这些实体都有一个具有唯一性的地址，并符合 RFC 2396 [URI]规范要求的格式。由于历史原因，一个 XMPP 实体的地址被称为 Jabber Identifier 或 JID 。一个合法的 JID 包括一组排列好的元素，包括域名（domain identifier），节点名（node identifier），和资源名（resource identifier）。

:JID的语法定义，使用 [ABNF] 中的 Augmented Backus-Naur 格式。（IPv4 地址和 IPv6地址规则在附录B 中的 [IPv6] 中定义；确定节点规则的合法字符顺序由附录A 的 [STRINGPREP] 的 Nodeprep 部分来定义；确定资源规则的合法字符顺序由附录B 的 [STRINGPREP] 的Resourceprep 部分来定义；子域名规则参考 [IDNA] 中关于国际域名标签的描述。）。

::jid = [ node "@" ] domain [ "/" resource ]

::domain = fqdn / address-literal

::fqdn = (sub-domain 1*("." sub-domain))

::sub-domain = (internationalized domain label)

::address-literal = IPv4address / IPv6address

:所有 JID 都是基于上述的结构。类似 <user@host/resource> 这种结构，最常用来标识一个即时消息用户，这个用户所连接的服务器，以及这个用户用于连接的资源（比如特定类型的客户端软件）。不过,节点类型不是客户端也是有可能的，比如一个用来提供多用户聊天服务的特定的聊天室，地址可以是 <room@service> （这里 “room“ 是聊天室的名字而 ”service“ 是多用户聊天服务的主机名），而加入了这个聊天室的某个特定的用户的地址则是 <room@service/nick> （这里 ”nick“ 是用户在聊天室的昵称）。许多其他的 JID 类型都是可能的（例如 <domain/resource> 可能是一个服务器端的脚本或服务）。

:一个 JID 的每个合法部分（节点名，域名，资源名）的长度不能（MUST NOT）超过 1023 字节。也就是整体长度（包括 '@' 和 '/' ）不能超过 3071 字节。

===域名===

:域名是一个主要的ID并且是 JID 中唯一必需（REQUIRED）的元素（一个纯粹的域名也是一个合法的 JID）。它通常代表网络的网关或者“主”服务器，其他实体通过连接它来实现 XML 转发和数据管理功能。然而，由一个域名标识引用的实体，并非总是一个服务器，它也可能是一个服务器的子域地址，提供额外的功能（比如多用户聊天服务，用户目录，或一个到外部消息系统的网关）。

:每个服务器或者服务的域名，可以（MAY）是一个 IP 地址，但应该（SHOULD）是一个完全合法的域名(参见 [DNS]).一个域名ID必须(MUST)是 [IANA] 里定义的“国际化域名”，并且按 [STRINGPREP]中的 [NAMEPREP] profile进行成功的字符转换。在比较两个域名ID之前，服务器必须(MUST),客户端应该(SHOULD)首先按照Nameprep profile(定义在[IANA]中) 来转换每个域名的字符。

===节点名===

:节点名是一个可选（OPTIONAL）的第二 ID，放在域名之前并用符号"@"分开.它通常表示一个向服务器或网关请求和使用网络服务的实体(比如一个客户端),当然它也能够表示其他的实体(比如在多用户聊天系统中的一个房间). 节点名所代表的实体，它的地址依赖于一个特定的域名;在 XMPP 的即时消息和出席信息应用系统中，这个地址是“纯 JID” <node@domain> 中的一部分。

:一个节点名必须按 \[STRINGPREP\] 中的 Nodeprep profile 进行成功的字符转换。在比较两个节点ID之前，服务器必须（MUST）,客户端应该(SHOULD)首先按 Nodeprep profile 转换每个ID的字符。

===资源名===

:资源名是一个可选的第三 ID,它放在域名的后面并由符号"/"分开。资源名可以跟在 <node@domain>后面也可以跟在 <domain> 后面。它通常表示一个特定的会话，连接（比如设备或者所在位置），或者一个附属于某个节点ID实体相关实体的对象（比如多用户聊天室中的一个参加者）。对于服务器和和其他客户端来说，资源名是不透明的。当它提供必需的信息以完成资源绑定（参见第七章）的时候，通常是由客户端来实现的（尽管可以由客户端向服务器请求完成），然后显示为“已连接的资源”。一个实体可以(MAY)并发维护多个已连接的资源。每个已连接的资源由不同的资源ID来区分。

:一个资源名必须（MUST）按 \[STRINGPREP\] 中的 Resourceprep profile 进行成功的格式化。在比较两个资源ID之前，服务器必须（MUST）,客户端应该(SHOULD)首先按 Resourceprep profile 转换每个ID的字符。

===地址的确认===

:在 SASL （见第六章）握手之后（如果必要的话，也在资源绑定（见第七章）之后），正在接收流信息的实体必须（MUST）确认初始实体的 ID 。

:对于服务器间的通信，在 SASL 握手时，如果没有指明授权的ID，这个初始的实体应该（SHOULD）是经过认证实体（参见简单认证和安全层协议 \[SASL\] 中的定义）授权的ID（见第六章）。

:对于客户端和服务器的通信，在 SASL 握手时，如果没有指明授权的ID，“纯 JID” (<node@domain>)应该（SHOULD）是经过认证实体（参见 [SASL] 中的定义）授权的ID，“全 JID” (<node@domain/resource>)的资源ID部分应该（SHOULD）是由客户端和服务器在资源绑定的时候商定的（参见第七章）。

:接收的实体必须（MUST）确保结果JID（包括节点名，域名，资源名以及分隔符）与本章前面部分描述的规则和格式相一致；为了满足这些约束条件，接收实体可能（MAY）需要把初始实体的发送方 JID 替换成接收实体认可的规范 JID。

==XML流==

===概览===

:两个基本概念，XML流和XML节，使得在出席信息已知的实体之间，异步交换低负载的结构化信息成为可能。这两个术语定义如下：

:XML流的定义：一个XML流是一个容器，包含了两个实体之间通过网络交换的XML元素。一个XML流是由一个XML打开标签 <stream> (包含适当的属性和名字空间声明)开始的,流的结尾则是一个XML关闭L标签 </stream> 。在流的整个生命周期，初始化它的实体可以通过流发送大量的XML元素，用于流的握手(例如 TLS 握手(第五章) 或 SASL 握手(第六章))或XML节（在这里指符合缺省名字空间的元素,包括<message/>,<presence/>, 或 <iq/> 元素）。“初始的流”由初始化实体（通常是一个客户端或服务器）和接收实体（通常是一个服务器）握手，从接收实体来看，它就是那个初始实体的"会话".初始化流允许从初始化实体到接收实体的单向通信;为了使接收实体能够和初始实体交换信息,接收实体必须发起一个反向的握手(应答流).

:XML节的定义: 一个XML节是一个实体通过 XML 流向另一个实体发送的结构化信息中的一个离散的语义单位。一个XML节直接存在于根元素<stream/>的下一级，这样可以说是很好的匹配了[XML](译者注:在标准参考一节)的第43条.任何XML节都是从一个XML流的下一级的某个打开标签（如 <presence>）开始，到相应的关闭标签（如 </presence>）。一个XML节可以（MAY）包含子元素(相关的属性,元素, 和 XML 字符数据等) 以表达完整的信息.在这里定义的XML节仅限于<message/>, <presence/>, 和 <iq/> 元素，具体描述间见 XML Stanzas（第九章）；为TLS握手（第五章）、SASL握手（第六章）、服务器回拨（第八章）的需要而发送的XML元素，不被认为是一个XML节。

:设想一个客户端和服务器会话的例子。为了连接一个服务器，一个客户端必须（MUST）发送一个打开标签<stream>给服务器，初始化一个XML流，也可选择（OPTIONAL）在这之前发送一段文本声明XML版本和支持的字符集（参见文本声明的内容(第十一章第四节); 也可看字符编码(第十一章第五节)）。视本地化策略和提供的服务而定，服务器应该（SHOULD）回复一个XML流给客户端，同样的，也可选择在这之前发送一段文本声明。一旦客户端完成了SASL握手（第六章），客户端可以（MAY）通过流发送不限量的XML节给网络中的任何接收者。当客户端想关闭这个流，它只需要简单的发送一个关闭标签</stream>给服务器（或者作为另一个选择，可能由服务器关闭这个流）。然后，客户端和服务器都应该（SHOULD）彻底地终止这个连接（通常是一个TCP连接）。

:那些习惯认为XML是一个以文本为中心风格的人可能希望看看一个与服务器连接的客户端会话，包含两个打开-关闭 XML文档：一个是从客户端到服务器，一个是从服务器到客户端。下图中，根元素<stream/> 可以被认为是每个“文档”的文档实体，这两个“文档”通过累积那些在XML上传输的XML节来搭建的。无论如何，下图只是方便理解；实际上XMPP并不处理文档而是处理XML流和XML节。

:基本上，一个XML流相当于一个会话期间所有XML节的一个信封。我们可以简单的把它描述成下图：

::|----------------------------

::| <stream>

::|----------------------------

::| <presence>

::| <show/>

::| </presence>

::|----------------------------

::| <message to='foo'>

::| <body/>

::| </message>

::|----------------------------

::| <iq to='bar'>

::| <query/>

::| </iq>

::|----------------------------

::| ...

::|----------------------------

::| </stream>

::|----------------------------

===绑定到TCP===

:虽然有很多非必需的连接使用XML流来绑定\[TCP\]连接（两个实体可以通过别的机制来互联，比如通过\[HTPP\]连接轮询），本规范只定义了 XMPP 到 TCP 的绑定。在客户和服务器通信的过程中，服务器必须（MUST）允许客户端共享一个TCP连接来传输XML节，包括从客户端传到服务器和从服务器传到客户端。在服务器之间的通信过程中，服务器必须（MUST）用一个 TCP连接向对方发送 XML节，另一个 TCP连接（由对方初始化）接收对方的XML节，一共两个 TCP连接。

===流的安全===

:在XMPP 1.0中，当XML流开始握手时，TLS应该（SHOULD）按第五章：TLS的使用中的规定来使用，SASL必须（MUST）按第六章：SASL的使用中的规定来使用。尽管可能（MAY）存在某种共有的机制能够保证双向安全，但是“初始化流”（比如从初始化实体发给接收实体的流）和“应答流”（比如从接收实体发给初始化实体的流）还是必须（MUST）安全的分开。在流被验证之间，实体不应该（SHOULD NOT）尝试通过流发送XML节（第九章）；就算它这样做了，对方的实体也不能（MUST NOT）接受这些XML节，并且应该（SHOULD）返回一个 <not-authorized/> 的流错误信息并且终止当前TCP连接上双方的XML流；注意，这仅仅是针对XML节（包含在缺省命名空间中的 <message/>, <presence/>, 和 <iq/> 元素），而不是指那些用于 TLS握手（第五章）、SASL握手（第六章）握手的流。

===流属性===

:流元素的属性如下:

:* to -- 'to'属性应该（SHOULD）仅用于从初始化实体到接收实体的 XML流的头，并且必须（MUST）设成为接收实体提供服务的主机名。注意，不应该（SHOULD NOT）有 'to'属性出现在接收实体应答初始实体的 XML流的头中；无论如何，如果'to'属性出现在应答流中，初始化实体应该（SHOULD）忽略它。

:* from -- 'from'属性应该（SHOULD）仅用于接收实体应答初始化实体的 XML流的头，并且必须（MUST）设成为接收实体（正在给初始实体授权）提供服务的主机名。注意，不应该（SHOULD NOT）有 'from'属性出现在初始实体发送给接收实体的 XML流的头中；无论如何，如果'from'属性出现在初始化流中，接收实体应该（SHOULD）忽略它。

:* id -- 'id'属性应该（SHOULD）仅用于接收实体发送给初始化实体 XML流的头。这个属性是一个由接收实体创建的具有唯一性的ID,一个初始实体和接收实体之间的会话ID，并且它在接收方的应用程序中（通常是一个服务器）必须（MUST）是唯一的。注意，这个流 ID 必须是足够安全的，所以它必须是不可预知的和不可重复的（参见[RANDOM] 了解如何获得随机性以保证安全性）。不应该（SHOULD NOT）有 'id'属性出现在初始实体发送给接收实体的 XML流的头中；无论如何，如果'id'属性出现在初始化流中，接收实体应该（SHOULD）忽略它。

:* xml:lang -- 'xml:lang'属性（定义在\[XML\]中的第二章第十二节）应该（SHOULD）包含在初始化实体发给接收实体的 XML流的头中，以指定在流中传输的可读XML字符所使用的缺省语言。如果这个属性出现了，接收实体应该（SHOULD）记住它的值，作为初始化流和应答流的缺省属性；如果这个属性没有出现，接收实体应该（SHOULD）用一个可配置的缺省值用于双方的流，这个属性值必须（MUST）在应答流的头中传达。对于所有初始化流中传输的节，如果初始实体没有提供'xml:lang'属性，接收实体应该（SHOULD）应用缺省值；如果初始实体提供了'xml:lang'属性，接收实体不能（MUST NOT）修改或删除它（参见第九章第一节第五小节 xml:lang）。'xml:lang'属性的值必须（MUST）是一个 NMTOKEN (定义在\[XML\]的第二章第三节) 并且必须（MUST）遵守 RFC 3066 \[LANGTAGS\] 规定的格式。

:* version -- version属性（最少需要"1.0"）为本规范中和流相关的协议提供了支持。关于这个属性的生成和处理的详细规则将在下文中定义。

:我们现在可以总结如下:

{|border="1" cellspacing="0"
! !! 初始化方发给接收方 !! 接收方发给初始化方
|-
|to || 接收方的主机名 || 忽略
|-
|from || 忽略 || 接收方的主机名
|-
|id || 忽略 || 会话键值
|-
|xml:lang || 缺省语言 || 缺省语言
|-
|version || 支持XMPP 1.0 || 支持XMPP 1.0
|}

====版本支持====

:在这里XMPP的版本是"1.0"；准确地说，这里囊括了和流相关的所有协议(TLS的使用 (第五章),SASL的使用(第六章), 和流错误(第四章第七节))，以及三个定义好的XML节类型(<message/>,<presence/>,和 <iq/>)。XMPP版本号的编号顺序是“<主版本号>.<副版本号>”。主版本和副版本号必须（MUST）是独立的整数并且每个号码可以（MAY）单独以阿拉伯数字增长。这样，"XMPP 2.4"的版本将比"XMPP 2.13"更低。号码前面的“0”(比如XMPP 6.01)必须(MUST)被接收方忽略并且不能(MUST NOT)被发送出去.

:如果流和节的格式或者必需的处理方式有了显著的改变，以至于老版本的实体如果只是简单的忽略它不理解的节和属性并且继续像老版本一样的处理方式，会使得老版本的实体不能够和新版本的实体交互，只有在这时候主版本号才应该（SHOULD）增加。副版本号显示新的性能，它必须（MUST）被副版本号更低的实体忽略，但被高（副）版本号的实体用于了解信息。例如，一个副版本号显示处理某种新定义的"type"属性的值（用于message,presence或IQ节）的能力；副版本号高的实体将会了解到与之通信的对方不能够理解这个"type"属性的值，所以将不会发送它。

:以下规则是用于'版本'属性在实现流的头信息时如何生成和处理:

:# 初始化实体必须（MUST）在初始化流的头信息中把'版本'的值设置成它所支持的最高版本。（比如，如果最高版本支持就是本规范，那么它必须(MUST)设置成"1.0"）.
:# 接收实体必须（MUST）在应答流的头信息中把'版本'的值设置成初始化实体所提供的版本或它所支持的最高版本,取其中版本号较低的那一个。接收实体必须(MUST)把主版本号和副版本号作为数字来比较,而不是对"主版本号.副版本号"这个字符串进行比较.
:# 如果在应答流的头信息的版本号中至少有一个主版本号低于初始化流的头信息的版本号,并且如前所述,新版本的实体不能够和旧版本实体交互,初始化实体应该(SHUOULD)生成一个<unsupported-version/>的流错误信息并终止XML流和它的TCP连接。
:# 如果一个实体收到一个头信息中没有'version'属性的流，这个实体必须（MUST）把对方实体的'version'当成'0.0'并且在它发送的应答流的头中也不应该(SHOULD NOT)包含'version'属性.

===名字空间声明===

:流的元素必须(MUST)同时满足一个流名字空间声明和一个缺省名字空间声明("名字空间声明"定义在 XML 名字空间定义 \[XML-NAMES\]中).关于流名字空间和缺省名字空间的详细信息,参考名字空间的名字和前缀(第十一章第二节).

===流的特性===

:如果初始化的实体在初始化流的头信息中设置'version'属性的信息为"1.0",接收实体必须(MUST)向初始化实体发送一个 <features/> 子元素以声明任何可供协商的流一级的特性(或者其他需要声明的能力).目前,这仅用于声明本文中定义的 TLS的使用(第五章),SASL的使用（第六章）和资源绑定(第七章),以及 [XMPP-IM|XMPP文档列表/XMPP正式RFC标准/RFC3921] 中定义的会话的建立;无论如何,流特性这一功能将来可以用于声明任何可协商的特性.如果一个实体不理解或支持安全特性,它应该(SHOULD)忽略它.如果要在一个非安全相关的特性(比如资源绑定)被提议之前,完成一个或多个安全特性(比如TLS和SASL)的协商,这个非安全相关的特性不应该(SHOULD NOT)在相应的安全特性协商完毕之前被声明.

===流错误===

:流的根元素可以（MAY）包含一个 <error/> 子元素，由流的名字空间前缀作为它的前缀。这个"错误"子元素必须（MUST）由感知到发生了流级别错误的实体发送（通常是一个服务器而不是一个客户端）。

====规则====

:以下规则适用于流级别的错误:

:* 它假定所有流级别的错误都是不可恢复的；所以，如果一个错误发生在流级别，发现这个错误的实体必须（MUST）发送一个流错误信息给另一个实体，发送一个关闭标签 </stream>，并终止这个流所在的TCP连接。

:* 如果这个错误发生在流刚开始设置的时候，接收实体必须（MUST）仍然发送一个开放标签 <stream> ，并在流元素中包含一个<error/>的子元素，然后发送一个关闭标签 </stream>，最后终止相应的TCP连接。在这种情况下，如果初始化实体在 'to' 属性中提供了一个未知的主机名，服务器应该（SHOULD）在终止之前,先在流的头信息的 'from' 属性中提供一个服务器认证的主机名.

====语法====

:流错误的语法如下:

<source lang="xml">
<stream:error>
<defined-condition xmlns='urn:ietf:params:xml:ns:xmpp-streams'/>
<text xmlns='urn:ietf:params:xml:ns:xmpp-streams' xml:lang='langcode'>
OPTIONAL descriptive text
</text>
[OPTIONAL application-specific condition element]
</stream:error>
<error/>元素:
</source>

:* 必须(MUST)包含一个子元素以描述一个下文定义的节错误条件;这个子元素必须(MUST)符合'urn:ietf:params:xml:ns:xmpp-streams'名字空间.

:* 可以(MAY)包含一个 <text/> 子元素,用XML字符数据描述错误的细节;这个元素必须(MUST)符合'urn:ietf:params:xml:ns:xmpp-streams'名字空间并且应该(SHOULD)拥有一个'xml:lang'属性表明XML字符数据的自然语言。

:* 可以（MAY）包含一个子元素用于描述一个明确的应用程序错误条件；这个元素必须（MUST）符合一个应用程序定义的名字空间，并且它的结构是由那个名字空间定义的。

: <text/> 元素是可选的（OPTIONAL）。如果有这个元素，它应该（SHOULD）仅用于提供描述或调试信息以补充一个已定义的条件或应用程序定义的条件。它不应该（SHOULD NOT）被一个应用程序当成一个可编程的信息。它不应该（SHOULD NOT）被用于向用户表达错误信息，但是可以（MAY）作为和条件元素相关的错误信息之外的附加说明。

====已定义的条件====

:以下流级别的错误条件是已定义的:

:* <bad-format/> -- 实体已经发送XML但是不能被处理;这个错误可以（可以）被更多特定的XML相关的错误替换，比如 <bad-namespace-prefix/>, <invalid-xml/>, <restricted-xml/>, <unsupported-encoding/>, 以及 <xml-not-well-formed/>,尽管更多特定的错误是首选的。

:* <bad-namespace-prefix/> -- 实体发送的名字空间前缀不被支持，或者在一个需要某种前缀的元素中没有发送一个名字空间前缀(参见 XML Namespace Names and Prefixes (第十一章第二节)).

:* <conflict/> -- 服务器正在关闭为这个实体激活的流，因为一个和已经存在的流有冲突的新的流已经被初始化。

:* <connection-timeout/> -- 实体已经很长时间没有通过这个流发生任何通信流量(可由一个本地服务策略来配置).

:* <host-gone/> -- 初始化实体在流的头信息中提供的'to'属性的值所指定的主机已经不再由这台服务器提供

:* <host-unknown/> -- 由初始化实体在流的头信息中提供的 'to' 属性的值和由服务器提供的主机名不一致.

:* <improper-addressing/> -- 一个在两台服务器之间传送的节缺少 'to' 或 'from' 属性(或者这个属性没有值).

:* <internal-server-error/> -- 服务器配置错误或者其他未定义的内部错误,使得服务器无法提供流服务.

:* <invalid-from/> -- 在'from'属性中提供的 JID 或主机名地址，和认证的 JID不匹配或服务器之间无法通过SASL（或回拨）协商出合法的域名，或客户端和服务器之间无法通过它进行认证和资源绑定。

:* <invalid-id/> -- 流 ID 或回拨 ID 是非法的或和以前提供的 ID 不一致.

:* <invalid-namespace/> -- 流名字空间和 "http://etherx.jabber.org/streams" 不相同或回拨名字空间和 "jabber:server:dialback" 不相同.(参考 XML Namespace Names and Prefixes (第十一章第二节)).

:* <invalid-xml/> -- 实体通过流发送了一个非法的XML给执行验证的服务器 (参考 Validation (第十一章第三节)).

:* <not-authorized/> -- 实体试图在流被验证之前发送数据或不被许可执行一个和流协商有关的动作，接收实体在发送错误信息之前不允许（MUST NOT）处理厌恶的节。

:* <policy-violation/> -- 实体违反了某些本地服务策略；服务器可以（MAY）选择在 <text/> 元素或应用程序定义的错误条件（元素）中详细说明策略。

:* <remote-connection-failed/> -- 服务器无法正确连接到用于验证或授权的远程实体。

:* <resource-constraint/> -- 服务器缺乏必要的系统资源为流服务。

:* <restricted-xml/> -- 实体试图发送受限的XML特性，比如一个注释，处理指示，DTD，实体参考，或保留的字符(参考 Restrictions (第十一章第一节)).

:* <see-other-host/> -- 服务器将不提供服务给初始化实体但是把它重定向到另一台主机；服务器应该（SHOULD）在<see-other-host/>元素的XML字符数据中指明替代服务器名或IP地址（它必须（必须）是合法的域名标识）。

:* <system-shutdown/> -- 服务器正在关机并且所有激活的流正在被关闭。

:* <undefined-condition/> -- 错误条件不在本文已定义的错误条件列表之中；这个错误条件应该（SHOULD）仅用于"应用程序定义条件"元素.

:* <unsupported-encoding/> -- 初始化实体以一个服务器不不支持的编码方式编码了一个流(参照Character Encoding (第十一章第五节)).

:* <unsupported-stanza-type/> -- 初始化实体发送了一个流的一级子元素但是服务器不支持.

:* <unsupported-version/> -- 由初始化实体在流的头信息中指定的'version'属性的值所指定的版本不被服务器支持;服务器可以(MAY)在<text/>元素中指定一个它支持的版本号.

:* <xml-not-well-formed/> -- 初始化实体发送了一个不规范的XML(参考[XML]）.

====应用程序定义条件====

:大家知道,应用程序可以(MAY)在error元素中包含一个适当名字空间的子元素来提供一个应用程序定义流错误信息."应用程序定义"元素应该(SHOULD)补充或甚至限定一个已定义的元素.所以 <error/> 元素将包含两个或三个子元素:

<source lang="xml">
<stream:error>
<xml-not-well-formed xmlns='urn:ietf:params:xml:ns:xmpp-streams'/>
<text xml:lang='en' xmlns='urn:ietf:params:xml:ns:xmpp-streams'>
Some special application diagnostic information!
</text>
<escape-your-data xmlns='application-ns'/>
</stream:error>
</stream:stream>
</source>

===简化的流示例===

:这里包含两个简化的例子，描述了基于流的客户端在服务器上的“会话”(这里"C"表示从客户端发给服务器,"S"表示从服务器发给客户端);这些例子只是用于举例说明原理.

:一个基本的 "会话":

<source lang="xml">
C: <?xml version='1.0'?>
<stream:stream to='example.com' xmlns='jabber:client' xmlns:stream='http://etherx.jabber.org/streams' version='1.0'>

S: <?xml version='1.0'?>
<stream:stream from='example.com' id='someid' xmlns='jabber:client' xmlns:stream='http://etherx.jabber.org/streams' version='1.0'>
... encryption, authentication, and resource binding ...

C: <message from='juliet@example.com' to='romeo@example.net' xml:lang='en'>

C: <body>Art thou not Romeo, and a Montague?</body>

C: </message>

S: <message from='romeo@example.net' to='juliet@example.com' xml:lang='en'>

S: <body>Neither, fair saint, if either thee dislike.</body>

S: </message>

C: </stream:stream>

S: </stream:stream>
</source>

:一个不成功的 "会话" :

<source lang="xml">
C: <?xml version='1.0'?>
<stream:stream to='example.com' xmlns='jabber:client' xmlns:stream='http://etherx.jabber.org/streams' version='1.0'>

S: <?xml version='1.0'?>
<stream:stream from='example.com' id='someid' xmlns='jabber:client' xmlns:stream='http://etherx.jabber.org/streams' version='1.0'>
... encryption, authentication, and resource binding ...

C: <message xml:lang='en'>
<body>Bad XML, no closing body tag!
</message>

S: <stream:error>
<xml-not-well-formed xmlns='urn:ietf:params:xml:ns:xmpp-streams'/>
</stream:error>

S: </stream:stream>
</source>

==TLS 的使用==

===概览===

:XMPP包含的一个保证流安全的方法来防止篡改和偷听.这个传输层安全协议[TLS]的频道加密方法, 模拟了类似的其他"STARTTLS"(见RFC 2595 [USINGTLS])的扩展,如 IMAP [IMAP], POP3 [POP3], and ACAP [ACAP]."STARTTLS"的扩展名字空间是'urn:ietf:params:xml:ns:xmpp-tls'.

:一个给定域的管理员可以(MAY)要求客户端和服务器通信以及服务器之间通信时使用TLS，或者两者都要求。客户端应该（SHOULD）在尝试完成 SASL （第六章）握手之前使用 TLS，服务器应该（SHOULD）在两个域之间使用 TLS 以保证服务器间通信的安全。

:以下是使用规则:

::# 一个遵守本协议的初始化实体必须（MUST）在初始化流的头信息中包含一个'version'属性并把值设为“1.0”。
::# 如果TLS握手发生在两个服务器之间，除非服务器声称的DNS主机名已经被解析(见第十四章第四节 Server-to-Server Communications)，通信不能（MUST NOT）继续进行。
::# 当一个遵守本协议的接收实体接收了一个初始化流（它的头信息中包含一个'version'属性并且值设为“1.0”），在发送应答流的的头信息（其中包含版本标记）之后，它必须发送（MUST）<starttls/>元素（名字空间为 'urn:ietf:params:xml:ns:xmpp-tls'）以及其他它支持的流特性。
::# 如果初始化实体选择使用TLS,TLS握手必须在SASL握手之前完成；这个顺序用于帮助保护SASL握手时发送的认证信息的安全，同时可以在必要的时候在TLS握手之前为SASL外部机制提供证书。
::# TLS握手期间,一个实体不能（MUST NOT）在流的根元素中发送任何空格符号作为元素的分隔符（在下面的TLS示例中的任何空格符都仅仅是为了便于阅读）；这个禁令用来帮助确保安全层字节精度。
::# 接收实体必须（MUST）在发送<proceed/> 元素的关闭符号">" 之后立刻开始TLS协商。初始化实体必须（MUST）在从接收实体接收到<proceed/> 元素的关闭符号">" 之后立刻开始TLS协商。
::# 初始化实体必须（MUST）验证接收实体出示的证书；关于证书验证流程参见Certificate Validation ( 第十四章第二节)。
::# 证书必须（MUST）检查初始化实体(比如一个用户)提供的主机名；而不是通过DNS系统解析出来的主机名；例如，如果用户指定一个主机名"example.com"而一个DNS SRV [SRV]查询返回"im.example.com"，证书必须（MUST）检查"example.com".如果任何种类的XMPP实体（例如客户端或服务器）的JID出现在一个证书里，它必须（MUST）表现为一个别名实体里面的UTF8字符串，存在于subjectAltName之中。如何使用 [ASN.1] 对象标识符 "id-on-xmppAddr" 定义在本文的第五章第一节第一小节。
::# 如果 TLS 握手成功了，接收实体必须（MUST）丢弃TLS 生效之前从初始化实体得到的任何不可靠的信息.
::# 如果 TLS 握手成功了，初始化实体必须（MUST）丢弃TLS 生效之前从接收实体得到的任何不可靠的信息.
::# 如果 TLS 握手成功了，接收实体不能(MUST NOT)在流重新开始的时候通过提供其他的流特性来向初始化实体提供 STARTTLS 扩展.
::# 如果 TLS 握手成功了，初始化实体必须(MUST)继续进行SASL握手。
::# 如果 TLS 握手失败了，接收实体必须（MUST）终止XML流和相应的TCP连接。
::# 关于必须（MUST）支持的机制，参照 Mandatory-to-Implement Technologies (第十四章第七节) 。

====用于 XMPP 地址的 ASN.1 对象标识符====

:上文提到的[ASN.1] 对象标识符 "id-on-xmppAddr"定义如下:

::id-pkix OBJECT IDENTIFIER ::= { iso(1) identified-organization(3)

::dod(6) internet(1) security(5) mechanisms(5) pkix(7) }

::id-on OBJECT IDENTIFIER ::= { id-pkix 8 } \-\- other name forms

::id-on-xmppAddr OBJECT IDENTIFIER ::= { id-on 5 }

::XmppAddr ::= UTF8String

:对象标识符也可以(MAY)使用点分隔的格式,如 "1.3.6.1.5.5.7.8.5".

===叙述===

:当一个初始化实体用TLS保护一个和接收实体之间的流，其步骤如下:

::# 初始化实体打开一个TCP连接，发送一个打开的XML流头信息（其'version'属性设置为"1.0"）给接收实体以初始化一个流。
::# 接收实体打开一个TCP连接，发送一个XML流头信息（其'version'属性设置为"1.0"）给初始化实体作为应答。
::# 接收实体向初始化实体提议STARTTLS范围（包括其他支持的流特性），如果TLS对于和接收实体交互是必需的，它应该（SHOULD）在<starttls/>元素中包含子元素<required/>.
::# 初始化实体发出STARTTLS命令(例如, 一个符合'urn:ietf:params:xml:ns:xmpp-tls'名字空间的 <starttls/> 元素) 以通知接收实体它希望开始一个TLS握手来保护流。
::# 接收实体必须（MUST）以'urn:ietf:params:xml:ns:xmpp-tls'名字空间中的<proceed/>元素或<failure/>元素应答。如果失败，接收实体必须（MUST）终止XML流和相应的TCP连接。如果继续进行，接收实体必须（MUST）尝试通过TCP连接完成TLS握手并且在TLS握手完成之前不能（MUST NOT）发送任何其他XML数据。
::# 初始化实体和接收实体尝试完成TLS握手。（要符合\[TLS\]规范）
::# 如果 TLS 握手不成功, 接收实体必须（MUST）终止 TCP 连接. 如果 TLS 握手成功, 初始化实体必须（MUST）发送给接收实体一个打开的XML流头信息来初始化一个新的流（先发送一个关闭标签</stream>是不必要的,因为接收实体和初始化实体必须(MUST)确保原来的流在TLS握手成功之后被关闭）。
::# 在从初始化实体收到新的流头信息之后，接收实体必须（MUST）发送一个新的XML流头信息给初始化实体作为应答，其中应包含可用的特性但不包含STATRTTLS特性。

===客户端-服务器示例===

:以下例子展示一个客户端使用STARTTLS保护数据流 (注意: 以下步骤举例说明协议中的失败案例；在这个例子中它们并不详尽并且也不是必须被数据传输触发的).

:步骤 1: 客户端初始化流给服务器:

<source lang="xml">
<stream:stream xmlns='jabber:client' xmlns:stream='http://etherx.jabber.org/streams' to='example.com' version='1.0'>
</source>

:步骤 2: 服务器发送一个流标签给客户端作为应答:

<source lang="xml">
<stream:stream xmlns='jabber:client' xmlns:stream='http://etherx.jabber.org/streams' id='c2s_123' from='example.com' version='1.0'>
</source>

:步骤 3: 服务器发送 STARTTLS 范围给客户端（包括验证机制和任何其他流特性）:

<source lang="xml">
<stream:features>
<starttls xmlns='urn:ietf:params:xml:ns:xmpp-tls'>
<required/>
</starttls>
<mechanisms xmlns='urn:ietf:params:xml:ns:xmpp-sasl'>
<mechanism>DIGEST-MD5</mechanism>
<mechanism>PLAIN</mechanism>
</mechanisms>
</stream:features>
</source>

:步骤 4: 客户端发送 STARTTLS 命令给服务器:

<source lang="xml">
<starttls xmlns='urn:ietf:params:xml:ns:xmpp-tls'/>
</source>

:步骤 5: 服务器通知客户端可以继续进行:

<source lang="xml">
<proceed xmlns='urn:ietf:params:xml:ns:xmpp-tls'/>
</source>

:步骤 5 (或者): 服务器通知客户端 TLS 握手失败并关闭流和TCP连接:

<source lang="xml">
<failure xmlns='urn:ietf:params:xml:ns:xmpp-tls'/>
</stream:stream>
</source>

:步骤 6: 客户端和服务器尝试通过已有的TCP连接完成 TLS 握手.

:步骤 7: 如果 TLS 握手成功, 客户端初始化一个新的流给服务器:

<source lang="xml">
<stream:stream xmlns='jabber:client' xmlns:stream='http://etherx.jabber.org/streams' to='example.com' version='1.0'>
</source>

:步骤 7 (或者): 如果 TLS 握手不成功, 服务器关闭 TCP 连接.

:步骤 8: 服务器发送一个流头信息应答客户端，其中包括任何可用的流特性:

<source lang="xml">
<stream:stream xmlns='jabber:client' xmlns:stream='http://etherx.jabber.org/streams' from='example.com' id='c2s_234' version='1.0'>
<stream:features>
<mechanisms xmlns='urn:ietf:params:xml:ns:xmpp-sasl'>
<mechanism>DIGEST-MD5</mechanism>
<mechanism>PLAIN</mechanism>
<mechanism>EXTERNAL</mechanism>
</mechanisms>
</stream:features>
</source>

:步骤 9: 客户端继续 SASL 握手 (第六章).

===服务器-服务器示例===

:以下例子展示两个服务器之间使用STARTTLS保护数据流 (注意: 以下步骤举例说明协议中的失败案例；在这个例子中它们并不详尽并且也不是必须被数据传输触发的).

:步骤 1: Server1 初始化流给 Server2:

<source lang="xml">
<stream:stream xmlns='jabber:server' xmlns:stream='http://etherx.jabber.org/streams' to='example.com' version='1.0'>
</source>

:步骤 2: Server2 发送一个流标签给 Server1 作为应答:

<source lang="xml">
<stream:stream xmlns='jabber:server' xmlns:stream='http://etherx.jabber.org/streams' from='example.com' id='s2s_123' version='1.0'>
</source>

:步骤 3: Server2 发送 STARTTLS 范围给 Server1 ，包括验证机制和任何其他流特性:

<source lang="xml">
<stream:features>
<starttls xmlns='urn:ietf:params:xml:ns:xmpp-tls'>
<required/>
</starttls>
<mechanisms xmlns='urn:ietf:params:xml:ns:xmpp-sasl'>
<mechanism>DIGEST-MD5</mechanism>
<mechanism>KERBEROS_V4</mechanism>
</mechanisms>
</stream:features>
</source>

:步骤 4: Server1 发送 STARTTLS 命令给 Server2:

<source lang="xml">
<starttls xmlns='urn:ietf:params:xml:ns:xmpp-tls'/>
</source>

:步骤 5: Server2 通知 Server1 允许继续进行:

<source lang="xml">
<proceed xmlns='urn:ietf:params:xml:ns:xmpp-tls'/>
</source>

:步骤 5 (或者): Server2 通知 Server1 TLS握手失败并关闭流:

<source lang="xml">
<failure xmlns='urn:ietf:params:xml:ns:xmpp-tls'/>
</stream:stream>
</source>

:步骤 6: Server1 和 Server2 尝试通过 TCP 完成 TLS 握手.

:步骤 7: 如果 TLS 握手成功, Server1 初始化一个新的流给 Server2:

<source lang="xml">
<stream:stream xmlns='jabber:server' xmlns:stream='http://etherx.jabber.org/streams' to='example.com' version='1.0'>
</source>

:步骤 7 (或者): 如果 TLS 握手不成功, Server2 关闭 TCP 连接.

:步骤 8: Server2 发送一个包含任何可用流特性的流头信息给 Server1 :

<source lang="xml">
<stream:stream xmlns='jabber:server' xmlns:stream='http://etherx.jabber.org/streams' from='example.com' id='s2s_234' version='1.0'>
<stream:features>
<mechanisms xmlns='urn:ietf:params:xml:ns:xmpp-sasl'>
<mechanism>DIGEST-MD5</mechanism>
<mechanism>KERBEROS_V4</mechanism>
<mechanism>EXTERNAL</mechanism>
</mechanisms>
</stream:features>
</source>

:步骤 9: Server1 继续进行 SASL 握手(第六章).

==SASL 的使用==

===概览===

:XMPP 有一个验证流的方法，即XMPP特定的SASL（简单验证和安全层）\[SASL\]。SASL提供了一个通用的方法为基于连接的协议增加验证支持，而XMPP使用了一个普通的XML名字空间来满足SASL的需要。

:以下规则应用于:

:# 如果SASL协商发生在两台服务器之间，除非服务器宣称的DNS主机名得到解析，不能（MUST NOT）进行通信。(参见服务器间的通信(第十四章第四节)).
:# 如果初始化实体有能力使用 SASL 协商, 它必须（MUST）在初始化流的头信息中包含一个值为"1.0"的属性'version'。
:# 如果接收实体有能力使用 SASL 协商, 它必须（MUST）在应答从初始化实体收到的打开流标签时(如果打开的流标签包含一个值为"1.0"的'version'属性),通过'urn:ietf:params:xml:ns:xmpp-sasl'名字空间中的<mechanisms/>元素声明一个或多个验证机制.
:# 当 SASL 协商时, 一个实体不能（MUST NOT）在流的根元素中发送任何空格符号(匹配 production \[3\] content of \[XML\])作为元素之间的分隔符(在以下的SASL例子中任何空格符号的出现仅仅是为了增加可读性); 这条禁令帮助确保安全层字节的精确度。
:# 当SASL握手时，在XML元素中使用的任何 XML 字符数据必须被编码成 base64, 编码遵循 RFC 3548 第三章的规定。
:# 如果一个简单名字"simple username" 规范被选定的SASL机制所支持，(比如, 这被 DIGEST-MD5 和 CRAM-MD5 机制支持但不被 EXTERNAL 和 GSSAPI 机制支持), 验证的时候初始化实体应该（SHOULD）在服务器间通信时提供简单名字自身的发送域（IP地址或包含在一个域标识符中的域名全称），在客户端与服务器之间通信时提供注册用户名（包含在一个XMPP节点标识符中的用户或节点名）。
:# 如果初始化实体希望以另一个实体的身份出现并且SASL机制支持授权ID的传输，初始化实体在SASL握手时必须（MUST）提供一个授权ID。如果初始化实体不希望以另一个实体的身份出现，初始化实体在SASL握手时不能（MUST NOT）提供一个授权ID。在 \[SASL\] 的定义中,除非授权ID不同于从验证ID（详见\[SASL\]）中得到的缺省的授权ID，初始化实体不能（MUST NOT）提供授权ID。如果提供了，这个授权ID的值必须（MUST）是<domain>的格式(对于服务器来说)或<node@domain>的格式(对于客户端来说).
:# 在成功进行包括安全层的SASL握手之后，接收实体必须（MUST）丢弃任何从初始化实体得到的而不是从SASL协商本身获得的信息。
:# 在成功进行包括安全层的SASL握手之后，初始化实体必须（MUST）丢弃任何从接收实体得到的而不是从SASL协商本身获得的信息。
:# 参看强制执行的技术 (第十四章第七届) ，了解关于必须（MUST）支持的机制.

===叙述===

:一个初始化实体使用SASL和接收实体做验证的步骤如下:

:# 初始化实体请求SASL验证，它发送一个打开的XML流头信息给接收实体，其'version'属性的值为"1.0".
:# 在发送一个XML流头回复之后，接收实体声明一个可用的SASL验证机制清单；每个机制作为一个<mechanism/>元素，作为子元素包含在<mechanisms/>容器元素（其名字空间为'urn:ietf:params:xml:ns:xmpp-sasl'）中，而<mechanisms/>则包含在流名字空间中的<features/>元素中。如果在使用任何验证机制之前需要使用TLS（见第五章），接收实体不能（MUST NOT）在TLS握手之前提供可用的SASL验证机制清单。如果初始化实体在优先的TLS协商过程中呈现了一个合法的证书，接收实体应该（SHOULD）在SASL握手中提出一个SASL外部机制给初始化实体，尽管这个外部机制可以（MAY）在其它环境下提供。
:# 初始化实体发送一个符合'urn:ietf:params:xml:ns:xmpp-sasl'名字空间的<auth/>元素（其中包含了适当的'mechanism'属性值）给接收实体，以选择一个机制。如果这个机制支持或需要，这个元素可以（MAY）包含XML字符数据（在SASL术语中，即“初始化应答”）；如果初始化实体需要发送一个零字节的初始化应答，它必须（MUST）传输一个单独的等号作为应答，这表示应答有效但不包含数据。
:# 如果必要，接收实体向初始化实体发送一个符合'urn:ietf:params:xml:ns:xmpp-sasl'名字空间的<challenge/>元素来发出挑战；这个元素可以（MAY）包含XML字符数据（必须按照初始化实体选择的SASL机制进行一致性运算）。
:# 初始化实体向接收实体发送符合'urn:ietf:params:xml:ns:xmpp-sasl'名字空间的<response/>元素作为应答；这个元素可以（MAY）包含XML字符数据（必须按照初始化实体选择的SASL机制进行一致性运算）。
:# 如果必要，接收实体发送更多的挑战给初始化实体，初始化实体发送更多的回应。

:这一系列的挑战/应答组，持续进行直到发生以下三件事中的一件为止：

:# 初始化实体向接收实体发送符合'urn:ietf:params:xml:ns:xmpp-sasl'名字空间的<abort/>元素以中止握手。在接收到<abort/>元素之后，接收实体应该（SHOULD）允许一个可配置的但是合理的重试次数（至少2次），然后它必须（MUST）终止TCP连接；这使得初始化实体（如一个最终用户客户端）能够容忍可能不正确的credentials（如密码输入错误）而不用强制重新连接。
:# 接收实体向初始化实体发送符合'urn:ietf:params:xml:ns:xmpp-sasl'名字空间的<failure/>元素以报告握手失败（详细的失败原因应该在<failure/>的一个适当的子元素中沟通，在第六章第四节中的SASL Errors中定义）。如果失败的情况发生了，接收实体应该（SHOULD）允许一个可配置的但是合理的重试次数（至少2次），然后它必须（MUST）终止TCP连接；这使得初始化实体（如一个最终用户客户端）能够容忍可能不正确的credentials（如密码输入错误）而不用强制重新连接。
:# 接收实体向初始化实体发送符合'urn:ietf:params:xml:ns:xmpp-sasl'名字空间的<success/>元素以报告握手成功；如果所选择的SASL机制要求，这个元素可以（MAY）包含XML字符数据（见SASL术语,“成功的额外数据”）。接收到<success/> 元素之后，初始化实体必须（MUST）发送一个打开的XML流头信息给接收实体以发起一个新的的流（不需要先发送一个 </stream>标签，因为在发送和接收到<success/>元素之后，接收实体和初始化实体必须确认原来的流被关闭了）。从初始化实体接收到新的流头信息之后，接收实体必须（MUST）发送一个新的流头信息给初始化实体作为回应，附上任何可用的特性（但不包括 STARTTLS 和 SASL 特性）或一个空的 <features/> 元素（这表示没有更多的特性可用）；任何没有在本文定义的附加特性必须（MUST）在XMPP的相关扩展中定义。

===SASL 定义===

:[SASL]的必要条件要求通过协议定义来提供以下信息:

::service name（服务名）: "xmpp"

::initiation sequence（开始序列）: 当初始化实体提供一个打开的XML流头信息并且接收实体善意回应之后，接收实体提供一个可接受的验证方法清单。初始化实体从这个清单中选择一个方法，把它作为 <auth/> 元素的 'mechanism' 属性的值发送给接收实体，也可以选择发送一个初始化应答以避免循环。

::exchange sequence（交换序列）: 挑战和回应的交换，从接收实体发送给初始化实体的 <challenge/> 元素和从初始化实体发送给接收实体的 <response/> 元素信息。接收实体通过发送 <failure/>元素报告失败，发送<success/>元素报告成功；初始化实体通过发送<abort/> 元素中止交换。成功的协商之后，两边都认为原来的XML流已经关闭并且都开始发送新的流头信息。

::security layer negotiation（安全层协商）: 安全层在接收实体发送 <success/> 元素的关闭字符">"之后立刻生效，在初始化实体发送 <success/> 元素的关闭字符">"之后也立刻生效。层的顺序是 \[TCP\]，\[TLS\]，然后是 \[SASL\]，然后是 \[XMPP\]。

::use of the authorization identity（授权ID的使用）: 授权ID可在xmpp中用于表示一个客户端的非缺省的<node@domain>，或一个服务器的<domain> 。

===SASL 错误===

:SASL相关的错误条件定义如下:

::* <aborted/> -- 接收实体认可由初始化实体发送的<abort/>元素；在回应一个<abort/>元素时发送。

::* <incorrect-encoding/> -- 由初始化实体提供的数据无法处理，因为[BASE64]编码不正确（例如，因为编码不符合[BASE64]的第三章）; 在回应一个包含初始化响应数据的<response/> 元素或<auth/>元素时发送.

::* <invalid-authzid/> -- 由初始化实体提供的授权id是非法的，因为它的格式不正确或初始化实体无权给那个ID授权；在回应一个包含初始化响应数据的<response/> 元素或<auth/>元素时发送。

::* <invalid-mechanism/> -- 初始化实体不能提供一个机制活、或请求一个不被接受实体支持的机制；在回应一个<auth/>元素时发送。

::* <mechanism-too-weak/> -- 初始化实体请求的机制比服务器策略对它的要求弱；在回应一个包含初始化响应数据的<response/> 元素或<auth/>元素时发送。

::* <not-authorized/> -- 验证失败，因为初始化实体没有提供合法的credentials（这包括但不限于未知用户名等情形）；在回应一个包含初始化响应数据的<response/> 元素或<auth/>元素时发送。

::* <temporary-auth-failure/> -- 验证失败，因为接收实体出现了临时的错误；在回应一个<response/> 元素或<auth/>元素时发送。

===客户端-服务器示例===

:以下例子展示了一个客户端和一个服务器使用SASL作验证的数据流，通常是在成功的TLS握手之后（注意：以下显示的替代步骤仅用于举例说明协议的失败情形；它们不够详尽也不需要由例子中的数据传送来触发）。

:步骤 1: 客户端初始化流给服务器:

<source lang="xml">
<stream:stream xmlns='jabber:client' xmlns:stream='http://etherx.jabber.org/streams' to='example.com' version='1.0'>
</source>

:步骤 2: 服务器向客户端发送流标签作为应答:

<source lang="xml">
<stream:stream xmlns='jabber:client' xmlns:stream='http://etherx.jabber.org/streams' id='c2s_234' from='example.com' version='1.0'>
</source>

:步骤 3: 服务器通知客户端可用的验证机制:

<source lang="xml">
<stream:features>
<mechanisms xmlns='urn:ietf:params:xml:ns:xmpp-sasl'>
<mechanism>DIGEST-MD5</mechanism>
<mechanism>PLAIN</mechanism>
</mechanisms>
</stream:features>
</source>

:步骤 4: 客户端选择一个验证机制:

<source lang="xml">
<auth xmlns='urn:ietf:params:xml:ns:xmpp-sasl' mechanism='DIGEST-MD5'/>
</source>

:步骤 5: 服务器发送一个 \[BASE64\] 编码的挑战给客户端:

<source lang="xml">
<challenge xmlns='urn:ietf:params:xml:ns:xmpp-sasl'>
cmVhbG09InNvbWVyZWFsbSIsbm9uY2U9Ik9BNk1HOXRFUUdtMmhoIixxb3A9ImF1dGgi
LGNoYXJzZXQ9dXRmLTgsYWxnb3JpdGhtPW1kNS1zZXNzCg==
</challenge>
</source>

:解码后的挑战信息是:

<source lang="xml">
realm="somerealm",nonce="OA6MG9tEQGm2hh",\
qop="auth",charset=utf-8,algorithm=md5-sess
</source>

:步骤 5 (替代): 服务器返回一个错误给客户端:

<source lang="xml">
<failure xmlns='urn:ietf:params:xml:ns:xmpp-sasl'>
<incorrect-encoding/>
</failure>
</stream:stream>
</source>

:步骤 6: 客户端发送一个\[BASE64\]编码的回应这个挑战:

<source lang="xml">
<response xmlns='urn:ietf:params:xml:ns:xmpp-sasl'>
dXNlcm5hbWU9InNvbWVub2RlIixyZWFsbT0ic29tZXJlYWxtIixub25jZT0i
T0E2TUc5dEVRR20yaGgiLGNub25jZT0iT0E2TUhYaDZWcVRyUmsiLG5jPTAw
MDAwMDAxLHFvcD1hdXRoLGRpZ2VzdC11cmk9InhtcHAvZXhhbXBsZS5jb20i
LHJlc3BvbnNlPWQzODhkYWQ5MGQ0YmJkNzYwYTE1MjMyMWYyMTQzYWY3LGNo
YXJzZXQ9dXRmLTgK
</response>
</source>

:解码后的回应信息是:

<source lang="xml">
username="somenode",realm="somerealm",\
nonce="OA6MG9tEQGm2hh",cnonce="OA6MHXh6VqTrRk",\
nc=00000001,qop=auth,digest-uri="xmpp/example.com",\
response=d388dad90d4bbd760a152321f2143af7,charset=utf-8
</source>

:步骤 7: 服务器发送另一个\[BASE64\]编码的挑战给客户端:

<source lang="xml">
<challenge xmlns='urn:ietf:params:xml:ns:xmpp-sasl'>
cnNwYXV0aD1lYTQwZjYwMzM1YzQyN2I1NTI3Yjg0ZGJhYmNkZmZmZAo=
</challenge>
</source>

:解码后的挑战信息是:

<source lang="xml">
rspauth=ea40f60335c427b5527b84dbabcdfffd
</source>

:步骤 7 (或者): 服务器返回一个错误给客户端:

<source lang="xml">
<failure xmlns='urn:ietf:params:xml:ns:xmpp-sasl'>
<temporary-auth-failure/>
</failure>
</stream:stream>
</source>

:步骤 8: 客户端应答这个挑战:

<source lang="xml">
<response xmlns='urn:ietf:params:xml:ns:xmpp-sasl'/>
</source>

:步骤 9: 服务器通知客户端验证成功:

<source lang="xml">
<success xmlns='urn:ietf:params:xml:ns:xmpp-sasl'/>
</source>

:步骤 9 (或者): 服务器通知客户端验证失败:

<source lang="xml">
<failure xmlns='urn:ietf:params:xml:ns:xmpp-sasl'>
<temporary-auth-failure/>
</failure>
</stream:stream>
</source>

:步骤 10: 客户端发起一个新的流给服务器:

<source lang="xml">
<stream:stream xmlns='jabber:client' xmlns:stream='http://etherx.jabber.org/streams' to='example.com' version='1.0'>
</source>

:步骤 11: 服务器发送一个流头信息回应客户端,并附上任何可用的特性(或空的features元素):

<source lang="xml">
<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>
</source>

===服务器-服务器示例===

:以下例子展示了一个服务器和另一个服务器使用SASL作验证的数据流，通常是在成功的TLS握手之后（注意：以下显示的替代步骤仅用于举例说明协议的失败情形；它们不够详尽也不需要由例子中的数据传送来触发）。

:步骤 1: 服务器1 发起一个流给服务器2 :

<source lang="xml">
<stream:stream xmlns='jabber:server' xmlns:stream='http://etherx.jabber.org/streams' to='example.com' version='1.0'>
</source>

:步骤 2: 服务器2 回应一个流标签给服务器1:

<source lang="xml">
<stream:stream xmlns='jabber:server' xmlns:stream='http://etherx.jabber.org/streams' from='example.com' id='s2s_234' version='1.0'>
</source>

:步骤 3: 服务器2 通知服务器1 可用的验证机制:

<source lang="xml">
<stream:features>
<mechanisms xmlns='urn:ietf:params:xml:ns:xmpp-sasl'>
<mechanism>DIGEST-MD5</mechanism>
<mechanism>KERBEROS_V4</mechanism>
</mechanisms>
</stream:features>
</source>

:步骤 4: 服务器1 选择一个验证机制:

<source lang="xml">
<auth xmlns='urn:ietf:params:xml:ns:xmpp-sasl' mechanism='DIGEST-MD5'/>
</source>

:步骤 5: 服务器2 发送一个\[BASE64\]编码的挑战给服务器1:

<source lang="xml">
<challenge xmlns='urn:ietf:params:xml:ns:xmpp-sasl'>
cmVhbG09InNvbWVyZWFsbSIsbm9uY2U9Ik9BNk1HOXRFUUdtMmhoIixxb3A9
ImF1dGgiLGNoYXJzZXQ9dXRmLTgsYWxnb3JpdGhtPW1kNS1zZXNz
</challenge>
</source>

:解码后的挑战信息是:

<source lang="xml">
realm="somerealm",nonce="OA6MG9tEQGm2hh",\
qop="auth",charset=utf-8,algorithm=md5-sess
</source>

:步骤 5 (替代): 服务器2 返回一个错误给服务器1:

<source lang="xml">
<failure xmlns='urn:ietf:params:xml:ns:xmpp-sasl'>
<incorrect-encoding/>
</failure>
</stream:stream>
</source>

:步骤 6: 服务器1 发送一个\[BASE64\]编码的回应这个挑战:

<source lang="xml">
<response xmlns='urn:ietf:params:xml:ns:xmpp-sasl'>
dXNlcm5hbWU9ImV4YW1wbGUub3JnIixyZWFsbT0ic29tZXJlYWxtIixub25j
ZT0iT0E2TUc5dEVRR20yaGgiLGNub25jZT0iT0E2TUhYaDZWcVRyUmsiLG5j
PTAwMDAwMDAxLHFvcD1hdXRoLGRpZ2VzdC11cmk9InhtcHAvZXhhbXBsZS5v
cmciLHJlc3BvbnNlPWQzODhkYWQ5MGQ0YmJkNzYwYTE1MjMyMWYyMTQzYWY3
LGNoYXJzZXQ9dXRmLTgK
</response>
</source>

:解码后的应答信息是:

<source lang="xml">
username="example.org",realm="somerealm",\
nonce="OA6MG9tEQGm2hh",cnonce="OA6MHXh6VqTrRk",\
nc=00000001,qop=auth,digest-uri="xmpp/example.org",\
response=d388dad90d4bbd760a152321f2143af7,charset=utf-8
</source>

:步骤 7: 服务器2 发送另外一个\[BASE64\]编码的挑战给服务器1:

<source lang="xml">
<challenge xmlns='urn:ietf:params:xml:ns:xmpp-sasl'>
cnNwYXV0aD1lYTQwZjYwMzM1YzQyN2I1NTI3Yjg0ZGJhYmNkZmZmZAo=
</challenge>
</source>

:解码后的挑战信息是:

<source lang="xml">
rspauth=ea40f60335c427b5527b84dbabcdfffd
</source>

:步骤 7 (或者): 服务器2 返回一个错误给服务器1:

<source lang="xml">
<failure xmlns='urn:ietf:params:xml:ns:xmpp-sasl'>
<invalid-authzid/>
</failure>
</stream:stream>
</source>

:步骤 8: 服务器1 回应挑战:

<source lang="xml">
<response xmlns='urn:ietf:params:xml:ns:xmpp-sasl'/>
</source>

:步骤 8 (或者): 服务器1 中止协商:

<source lang="xml">
<abort xmlns='urn:ietf:params:xml:ns:xmpp-sasl'/>
</source>

:步骤 9: 服务器2 通知服务器1 验证成功:

<source lang="xml">
<success xmlns='urn:ietf:params:xml:ns:xmpp-sasl'/>
</source>

:步骤 9 (或者): 服务器2 通知服务器1 验证失败:

<source lang="xml">
<failure xmlns='urn:ietf:params:xml:ns:xmpp-sasl'>
<aborted/>
</failure>
</stream:stream>
</source>

:步骤 10: 服务器1 重新发起一个新的流给服务器2:

<source lang="xml">
<stream:stream xmlns='jabber:server' xmlns:stream='http://etherx.jabber.org/streams' to='example.com' version='1.0'>
</source>

:步骤 11: 服务器2 发送一个流头信息应答服务器1 ,并附上任何可用的特性(或一个空的features元素).:

<source lang="xml">
<stream:stream xmlns='jabber:client' xmlns:stream='http://etherx.jabber.org/streams' from='example.com' id='s2s_345' version='1.0'>
<stream:features/>
</source>

==资源绑定==

:在和接收实体完成 SASL 协商(第六章)之后,初始化实体可能(MAY)想要或者需要绑定一个特定的资源到流上.通常这仅适用于客户端: 为了满足本文定义的寻址格式(第三章)和节传输规则(第十章),客户端<node@domain>必须(MUST)拥有一个相关的资源ID（由服务器生成或由客户端程序提供）；以确保在流上使用的地址是一个“全JID”（<node@domain/resource>）。

:接收到一个成功的SASL握手之后，客户端必须（MUST）发送一个新的流头信息给服务器，服务器必须（MUST）返回一个包含可用的流特性列表的头信息。特别是，在成功的SASL握手之后如果服务器需要客户端绑定一个资源，它必须（MUST）在握手成功之后（而不是之前）发送给客户端的应答流特性中包含一个空的符合'urn:ietf:params:xml:ns:xmpp-bind'名字空间的<bind/>元素。:

:服务器向客户端声明资源绑定特性:

<source lang="xml">
<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'/>
</stream:features>
</source>

:收到要求资源绑定的通知后，客户端必须（MUST）通过发送一个符合'urn:ietf:params:xml:ns:xmpp-bind'名字空间的“set”类型的IQ节(参见 IQ 语义 (第九章第二节第三小节))给服务器来绑定一个资源到流中。

:如果客户端端希望允许服务器给自己生成一个资源ID，它可以发送一个包含空的<bind/>元素的“set”类型的IQ节。:

:客户端请求服务器绑定资源:

<source lang="xml">
<iq type='set' id='bind_1'>
<bind xmlns='urn:ietf:params:xml:ns:xmpp-bind'/>
</iq>
</source>

:一个支持资源绑定的服务器必须（MUST）自动生成一个资源ID给客户端。一个由服务器生成的资源ID对于那个<node@domain>必须（MUST）是唯一的。

:如果客户端希望指定资源ID，它发送一个包含期望资源ID的“set”类型的 IQ节，把资源ID作为<bind/>元素下的<resource/>子元素的XML字符数据:

:客户端绑定一个资源:

<source lang="xml">
<iq type='set' id='bind_2'>
<bind xmlns='urn:ietf:params:xml:ns:xmpp-bind'>
<resource>someresource</resource>
</bind>
</iq>
</source>

:一旦服务器为客户端生成了一个资源ID或接受了客户端自己提供的资源ID，它必须（MUST）返回一个“result”类型的 IQ 节给客户端，这个节必须包含一个指明全JID的<jid/>子元素表示服务器决定连接的资源:

:服务器通知客户端资源绑定成功:

<source lang="xml">
<iq type='result' id='bind_2'>
<bind xmlns='urn:ietf:params:xml:ns:xmpp-bind'>
<jid>somenode@example.com/someresource</jid>
</bind>
</iq>
</source>

:一个服务器应该（SHOULD）接受客户端提供的资源ID，但是可以（MAY）用服务器生成的资源ID覆盖它；在这种情况下，服务器不应该（SHOULD NOT）返回一个错误信息一个(如<forbidden/>)给客户端，而应该（SHOULD）在上文所述的 IQ result 中返回生成的资源ID。

:当一个客户端自行提供资源ID时，可能发生以下的节错误(参见 Stanza Errors (第九章第三节)):

::- 提供的资源ID服务器无法处理，因为不符合资源字符规范Resourceprep（附录B）。

::- 客户端不被允许绑定一个资源（如节点或用户已经达到允许连接的资源数限制）。

::- 提供的资源ID已经被使用但是服务器不允许以同一个资源ID绑定多个连接。

:协议对这些错误条件规定如下.

::资源ID不能处理:

<source lang="xml">
<iq type='error' id='bind_2'>
<bind xmlns='urn:ietf:params:xml:ns:xmpp-bind'>
<resource>someresource</resource>
</bind>
<error type='modify'>
<bad-request xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
</error>
</iq>
</source>

::客户端不允许绑定一个资源:

<source lang="xml">
<iq type='error' id='bind_2'>
<bind xmlns='urn:ietf:params:xml:ns:xmpp-bind'>
<resource>someresource</resource>
</bind>
<error type='cancel'>
<not-allowed xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
</error>
</iq>
</source>

::资源ID已经在使用:

<source lang="xml">
<iq type='error' id='bind_2'>
<bind xmlns='urn:ietf:params:xml:ns:xmpp-bind'>
<resource>someresource</resource>
</bind>
<error type='cancel'>
<conflict xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
</error>
</iq>
</source>

:如果,在完成资源绑定步骤之前,客户端试图以符合'urn:ietf:params:xml:ns:xmpp-bind'名字空间的<bind/>子元素发送一个非IQ类型的XML节,服务器不能(MUST NOT)处理这个节,而应该(SHOULD)返回一个<not-authorized/>节错误信息给客户端.

==服务器回拨==

===概览===

:Jabber协议接受的来自XMPP的包括“服务器回拨”方法，用于防治域名欺骗，使得欺骗XML节更为困难。服务器回拨不是一个安全机制，并且它的服务器身份认证结果很弱（参见服务器之间的通信（第十四章第四节）中关于这个方法的安全特性）。需要健壮的安全性的域名应该（SHOULD）使用TLS或SASL；细节参见服务器间的通信（第十四章第四节）。如果SASL用于服务器间通信，回拨就不需要用了（SHOULD NOT）。本文描述回拨的好处在于向后兼容现存的实现和部署。

:服务器回拨方法由现存的DNS系统的存在而成为可能，因为一个服务器（通常）可以查询给定域的授权服务器。由于服务器回拨依赖于DNS，除非服务器宣称的DNS主机得到解析，域之间的通信无法进行（参见服务器间的通信（第十四章第四节））。

:服务器回拨是单向性的，可在单一方向上对一个流进行（微弱的）身份验证．因为服务器回拨不是一个验证机制，通过回拨获得相互的认证是不可能的．因此，为了使得服务器之间的双向通信，服务器回拨必须（MUST）在每个方向上完成。

:在服务器回拨中生成和检验密钥的方法必须（MUST）考虑计算被使用的主机名，由接收服务器生成的流ID，和只有授权服务器网络才知道的秘密。在服务器回拨中流ID是安全性的关键所以必须（MUST）是不可预知的和不可重复的（见\[RANDOM\]中关于使用随机数获得安全性的建议）．

:任何回拨协商过程中发生的错误必须（MUST）被当成一个流错误，并导致流以及相关的TCP连接的终止．可能发生的错误情况协议中描述如下.

:以下术语适用:

:* 发起服务器 -- 尝试在两个域之间建立连接的那个服务器．

:* 接收服务器 -- 尝试验证发起服务期声称的域名的那台服务器．

:* 授权（权威？Authoritative）服务器 -- 回答发起服务器声称的DNS主机名的服务器；基本上这应该是那台发起服务器，但是它也可能是一个在发起服务器网络中独立的服务器。

===事件顺序===

:以下是回拨中的事件顺序的简介:

:# 发起服务器和接收服务器建立一个连接。
:# 发起服务器通过到连接发送一个 'key' 值给接收服务期。
:# 接收服务器建立一个连接到授权服务器。
:# 接收服务器发送一个相同的 'key' 值给授权服务器。
:# 授权服务器回答这个key是否合法。
:# 接收服务器通知发起服务器是否被验证通过。

:我们用用以下图形展示这个事件流程(见附件s2s.png):

{image:img=s2s}

===协议===

:服务器之间互动的细节协议如下:

:1. 发起服务器和接受服务器建立TCP连接.

:2. 发起服务器发送流头信息给接收服务器:

<source lang="xml">
<stream:stream xmlns:stream='http://etherx.jabber.org/streams' xmlns='jabber:server' xmlns:db='jabber:server:dialback'>
</source>

:注意: 'to'和'from'属性在流的根元素是可选的(OPTIONAL). 其中包含的xmlns:db名字空间向接收服务器声明了发起服务器支持回拨. 如果名字空间不正确，接收实体必须（MUST）生成一个<invalid-namespace/>流错误条件并且终止XML流和相应的TCP连接.

:3. 接收服务器应该（SHOULD）回送一个流头信息给发起服务器，为这次交互生成一个唯一性的ID :

<source lang="xml">
<stream:stream xmlns:stream='http://etherx.jabber.org/streams' xmlns='jabber:server' xmlns:db='jabber:server:dialback' id='457F9224A0...'>
</source>

:注意: 'to'和'from'属性在流的根元素是可选的(OPTIONAL). 如果名字空间不正确，发起服务器必须生成一个<invalid-namespace/>流错误条件并且终止XML流和相应的TCP连接.也要注意，在这里接收服务器应该（SHOULD）应答但是可以(MAY)出于安全策略考虑只是悄悄地终止XML流和TCP连接；无论如何，如果接收服务器希望继续，它必须（MUST）回送一个流头信息给发起服务器.

:4. 发起服务器发送一个回拨密钥给接收服务器:

<source lang="xml">
<db:result to='Receiving Server' from='Originating Server'>
98AF014EDC0...
</db:result>
</source>

:注意: 这个密钥不由接收服务器检查，因为接收服务器在会话之间（between sessions）不保存发起服务器的信息. 这个由发起服务器生成的密钥必须（MUST）是基于接收服务器在上一步骤中提供的ID值，以及发起服务器与授权服务器共享的安全机制生成的。如果 'to' 地址的值和接收服务器知道的主机名不匹配，接收服务器必须（MUST）生成一个<host-unknown/>流错误条件并且终止XML流和相应的TCP连接. 如果 'from' 地址和接收服务器已经建立的连接的域名相吻合,接收服务器必须(MUST)维护这个已经存在的连接,直到证明这个新的连接是合法的为止;另外,接收实体可以(MAY)选择生成一个<not-authorized/> 流错误条件给这个新的连接并且终止和新连接申请相关的XML流及相应的TCP连接.

:5. 接收服务器向发起服务器声明的那个域建立一个 TCP 连接,作为结果它连接到授权服务器. (注意: 为了优化性能, 在这里一个实现可以(MAY)重用现有的连接.)

:6. 接收服务器发送一个流头信息给授权服务器:

<source lang="xml">
<stream:stream xmlns:stream='http://etherx.jabber.org/streams' xmlns='jabber:server' xmlns:db='jabber:server:dialback'>
</source>

:注意: 'to'和'from'属性在流的根元素是可选的(OPTIONAL). 如果名字空间不正确，授权服务器必须生成一个<invalid-namespace/>流错误条件并且终止XML流和相应的TCP连接.

:7. 授权服务器发送流头信息给接收服务器:

<source lang="xml">
<stream:stream xmlns:stream='http://etherx.jabber.org/streams' xmlns='jabber:server' xmlns:db='jabber:server:dialback' id='1251A342B...'>
</source>

:注意: 如果名字空间不正确，接收服务器必须生成一个<invalid-namespace/>流错误条件并且终止它和授权服务器之间的XML流和相应的TCP连接. 如果一个流错误发生在接收服务器和 '''授权服务器''' 之间,接收服务器必须(MUST)生成一个 <remote-connection-failed/> 流错误条件并且终止它和 '''发起服务器''' 之间的XML流和相应的TCP连接.

:8. 接收服务器发送一个密钥检查请求给授权服务器:

<source lang="xml">
<db:verify from='Receiving Server' to='Originating Server' id='457F9224A0...'>
98AF014EDC0...
</db:verify>
</source>

:注意: 现在这里已经有了主机名,第三步中接收服务器发送给发起服务器的ID，第四步中发起服务器发送给接收服务器的密钥. 基于这些信息, 加上授权服务器网络共享的安全信息, 这个密钥被证实了.任何可用于验证的办法都可以（MAY）用于生成密钥. 如果 'to' 地址的值和授权服务器知道的主机名不匹配，授权服务器必须（MUST）生成一个<host-unknown/>流错误条件并且终止XML流和相应的TCP连接. 打开这个连接时，如果 'from' 地址和接收服务器声明的主机名（或任何合法的域，如验证过的接收服务器的子域名或寄宿在接收服务器上的其他经过验证的域）不符,授权服务器必须(MUST)生成一个<invalid-from/>流错误条件并且终止XML流和相应的TCP连接.

:9. 授权服务器检查密钥是否合法:

<source lang="xml">
<db:verify from='Originating Server' to='Receiving Server' type='valid' id='457F9224A0...'/>
</source>

::或

<source lang="xml">
<db:verify from='Originating Server' to='Receiving Server' type='invalid' id='457F9224A0...'/>
</source>

:注意: 如果 ID 和第三步中接收服务器提供的不符，接收服务器必须（MUST）生成一个<invalid-id/>流错误条件并且终止XML流和相应的TCP连接. 如果 'to' 地址的值和接收服务器知道的主机名不匹配，接收服务器必须（MUST）生成一个<host-unknown/>流错误条件并且终止XML流和相应的TCP连接. 打开这个连接时，如果 'from' 地址和发起服务器声明的主机名（或任何合法的域，如验证过的发起服务器的子域名或寄宿在发起服务器上的其他经过验证的域）不符,接收服务器必须(MUST)生成一个<invalid-from/>流错误条件并且终止XML流和相应的TCP连接. 在返回验证信息给接收服务器之后，授权服务器应该（SHOULD）终止它们之间的流.

:10. 接收服务器通知发起服务器结果:

<source lang="xml">
<db:result from='Receiving Server'to='Originating Server' type='valid'/>
</source>

:注意: 在这一个点上, 连接已经由 type='valid' 确认验证是通过了，还是没通过. 如果连接是非法的，接收服务器必须（MUST）终止XML流和相应的TCP连接. 如果连接是合法的, 数据可以从发起服务器发送由接收服务器读取；在此之前，所有发送给接收服务器的XML节应该（SHOULD）被丢弃.

:进一步的结果是，接收服务器已经验证了发起服务器的ID，所以通过初始化流("initial stream"，例如从发起服务器到接收服务器的流)发起服务器可以发送，接收服务器可以接受XML节. 为了使用应答流（"response stream"，例如从接收服务器到发起服务器的流）验证实体ID，回拨必须（MUST）在相对的两个方向上都完成.

:在成功的回拨协商之后, 接收服务器应该（SHOULD）接受接下来发起服务器通过当前的合法连接发送的 <db:result/> 包 (例如, 发送给子域或其他寄宿在接收服务器上的主机名的验证请求); 这在单一方向上激活了原始合法连接的 "piggybacking" .

:即使回拨协商成功了, 服务器仍然必须（MUST）检查从其他服务器接收的所有XML节的'from'和'to'属性; 如果一个节不符合这些限定, 收到这些节的服务器必须（MUST）生成一个<improper-addressing/> 流错误条件并终止XML流和相应的TCP连接. 而且, 一个服务器也必须(MUST)检查从其他的有合法域名的服务器的流中收到的节的'from'属性; 如果一个节不符合这一限定, 接收节的服务器必须(MUST)生成一个 <invalid-from/> 流错误条件并终止XML流和相应的TCP连接. 所有这些检查都用来帮助防止特定的节伪造行为.

==XML节==

:在 TLS 协商(第五章) （如果想要）, SASL 协商(第六章), 和资源绑定(第七章)（如果需要）之后, XML节就可以通过流发送了. 在'jabber:client'和'jabber:server'名字空间中定义了三种XML节: <message/>, <presence/>, 和 <iq/>. 另外, 这三种节有五种通用的属性. 这些通用属性, 加上三种节的术语,在这里定义; 更多关于和即时消息及出席信息应用相关的XML节语法详细信息在[XMPP-IM|XMPP文档列表/XMPP正式RFC标准/RFC3921]中提供.

===通用属性===

:以下五种属性通用于 message, presence, 和 IQ 节:

====to====

:'to' 属性表示节的预期接收者的JID.

:在'jabber:client'名字空间中, 一个节应该（SHOULD）处理一个'to'属性, 尽管由服务器处理的从客户端发给服务器的节(如, 发送给服务器用于广播给其他实体的出席信息) 应该不（SHOULD NOT）处理'to'属性.

:在'jabber:server'名字空间中, 一个节必须（MUST）处理一个'to'属性; 如果一个服务器收到一个不符合此限定的节, 它必须（MUST）生成一个<improper-addressing/>流错误条件并终止和这个非法服务器的XML流和相应的TCP连接.

:如果'to'属性的值非法或无法联络, 发现这个事实的实体（通常是发送者或接收者的服务器）必须（MUST）返回一个适当的错误给发送者, 错误节的'from'属性设置成非法节的提供的'to'属性的值.

====from====

:'from' 属性表示发送者的 JID .

:当一个服务器接收了一个符合'jabber:client'名字空间的合法流的XML节, 它必须(MUST)做以下步骤中的一步:

:# 验证客户端提供的'from'属性值就是那个相关实体连接的资源
:# 为生成这个节的已连接的资源增加一个'from'地址（由服务器决定是纯JID或全JID）(参见地址的决定 Determination of Addresses (第三章第五节))
:# 如果一个客户端试图发送一个XML节，而它的'from'属性和这个实体已连接的资源不符, 服务器应该(SHOULD)返回一个<invalid-from/>流错误条件给客户端. 如果一个客户端试图通过一个尚未验证的流发送一个XML节, 服务器应该（SHOULD）返回一个<not-authorized/>流错误条件给客户端. 如果生成了, 所有这些条件必须（MUST）导致流的关闭和相应的TCP连接的终止; 这有助于防止不诚实的客户的拒绝服务攻击.

:当一个服务器从服务器自身生成一个节用于一个已连接的客户端的信息发布(例如, 在服务器为客户端提供数据存储服务的情况下), 这个节必须(MUST) (1) 不包含 'from' 属性或 (2) 包含一个'from'属性，它的值是这个账号的纯 JID (<node@domain>) 或客户端的全 JID (<node@domain/resource>). 如果节不是由服务器自身生成的，那么一个服务器不能（MUST NOT）发送不带'from'属性的节. 当一个客户端接收到一个不包含'from'属性的节, 它必须(MUST)认为这个节是从客户端连接的服务器发来的.

:在'jabber:server'名字空间, 一个节必须(MUST)处理一个'from'属性; 如果一个服务器接收到一个不符合此限定的节, 它必须(MUST)生成一个<improper-addressing/>流错误条件. 而且, 'from'属性的 JID值的域名ID部分必须（MUST）和以SASL协商连接或以回拨协商连接的发送服务器的主机名（或任何合法的域，如发送服务器主机名的合法子域，或其他寄宿在发送服务器上的合法域）吻合; 如果一个服务器接收到的节不符合此限定, 它必须（MUST）生成一个<invalid-from/>流错误条件. 所有这些条件都必须（MUST）导致流的关闭和相应的TCP连接的终止; 这有助于防止不诚实的客户端发起的拒绝服务攻击.

====id====

:可选的'id' 属性可以（MAY）用于为节的内部跟踪发送实体，从IQ节语义来讲，就是通过发送和接收这些节来跟踪“请求-应答”型的交互行为。这个可选的（OPTIONAL）'id'属性值在一个域或一个流中是全局唯一的。IQ节语义学中对此有附加限定；见IQ Semantics (第九章第二节第三小节)。

====type====

:'type' 属性指明消息、出席信息或IQ节的意图或上下文的详细信息。'type'属性所允许的值依据节的类型是消息、出席信息还是IQ而有很大不同；用于消息和出席信息节的值定义在即时消息和出席信息应用中，所以在[XMPP-IM|XMPP文档列表/XMPP正式RFC标准/RFC3921]中定义，反之用于IQ节的值定义了在一个请求\-应答的“会话”中IQ节的角色，所以定义在IQ语义学中（第九章第二节第三小节）。所有三种节的通用'type'值是"error"；见Stanza Errors (第九章第三节)。

====xml:lang====

:如果一个节包含用于显示给人human user看的XML字符数据(在RFC 2277中有所解释\[CHARSET\],"internationalization is for humans")，这个节应该（SHOULD）处理一个'xml:lang'属性(定义在第二章第十二节\[XML\])。 'xml:lang'属性的值指明任何一个人类可读的XML字符数据的缺省语言，它可以（MAY）被特定的子元素的'xml:lang'值重载。如果一个节不处理一个'xml:lang'属性,一个实现必须(MUST)认为缺省的语言就是流属性中定义的语言(第四章第四节). 'xml:lang'属性值必须(MUST)是一个 NMTOKEN 并且必须(MUST)遵守 RFC 3066 \[LANGTAGS\]中定义的格式.

===基本语义学===

====消息语义学====

:<message/>节类型可以被看作是一个"push"机制用于一个实体推送信息给另一个实体,类似发生在email系统中的通信. 所有消息节应该（SHOULD）处理一个表明预定的消息接收者的'to'属性;接收了这样一个节之后,一个服务器应该（SHOULD）路由或递送它给预定的接收者(见 Server Rules for Handling XML Stanzas (第十章)的XML节相关的通用路由和递送规则).

====出席信息语义学====

:<presence/> 元素可以被看作一个基本的广播或“出版-订阅”机制,用于多个实体接收某个已订阅的实体的信息(在这里,是网络可用性信息). 通常,一个发行实体应该（SHOULD）不带'to'属性发送一个出席信息,这时这个实体所连接的服务器应该（SHOULD）广播或多播(multiplex?)那个节给所有订阅的实体.无论如何,一个发行实体也可以(MAY)带'to'属性发送一个出席信息节,这时服务器应该(SHOULD)路由或递送这个节给预定的接收者.见 Server Rules for Handling XML Stanzas (第十章)的XML节相关的通用路由和递送规则,以及[XMPP-IM|XMPP文档列表/XMPP正式RFC标准/RFC3921]中即时消息和出席信息应用中出席信息的特定规则.

====IQ语义学====

:信息/查询(Info/Query),或曰IQ,是一个请求-回应机制,某些情况下类似\[HTTP\].IQ语义学使一个实体能够向另一个实体做出请求并做出应答. 请求和应答所包含的数据定义在IQ元素的一个直接的子元素的名字空间声明中, 并且由请求实体用'id'属性来跟踪这一交互行为. 因而,IQ交互伴随着一个结构化的数据交换的通用模式例如 get/result 或 set/result (尽管有时候会以一个错误信息应答某个请求):

:以下是IQ的流程图，参见附件iq.png

{image:img=iq}

:为了强制执行这些语义学,要应用以下规则:

:1. 对于IQ节来说'id'属性是必需的（REQUIRED）.
:2. 对于IQ节来说'type'属性是必需的（REQUIRED）. 它的值必须（MUST）是以下之一:
::* get -- 这个节是一个对信息或需求的请求.
::* set -- 这个节提供需要的数据, 设置新的值, 或取代现有的值.
::* result -- 这个节是一个对一个成功的 get 或 set 请求的应答.
::* error -- 发生了一个错误，关于处理或递送上次发送的 get 或 set的(参见节错误 Stanza Errors(第九章第三节)).
:3. 一个接收到"get" 或 "set" 类型的IQ请求的实体必须（MUST）回复一个"result"或"error"类型的IQ应答(这个应答必须（MUST）保留相关请求的'id'属性).
:4. 一个接收到"result"或"error"类型的IQ节的实体不能（MUST NOT）再发送更多的"result"或"error"类型的IQ应答; 无论如何, 如上所述, 请求实体可以（MAY）发送另一个请求(如, 一个"set"类型的IQ，通过get/result对提供查询(discovery)所需的信息).
:5. 一个"get" 或 "set" 类型的IQ节必须（MUST）包含并只包含一个子元素指明特定请求或应答的语义.
:6. 一个"result"类型的IQ节必须（MUST）包含零或一个子元素.
:7. 一个"error"类型的IQ节应该（SHOULD）包含和"get"或"set"相关联的那个子元素并且必须（MUST）包含一个<error/>子元素;详细信息,见Stanza Errors (第九章第三节).

===节错误===

:节相关的错误的处理方式类似流错误(第四章第七节). 无论如何, 不像流错误, 节错误是可恢复的;所以错误节包含了暗示原来的发送者可以采取什么行动来补救这个错误.

====规则====

:以下规则适用于节相关的错误:

:* 接收或处理实体察觉到一个节相关的错误条件时应该（MUST）返回给发送实体一个同类型的节(消息,出席信息,或IQ),这个节的'type'属性值则设置为"error"(这里这样的节称之为"error stanza").

:* 生成一个错误节的实体应该（SHOULD）包含原来发送的XML，这样发送者可以检查它，并且如果必要，在尝试重新发送之前纠正它.

:* 一个错误节必须（MUST）包含一个<error/>子元素.

:* 如果'type'属性值不是"error"（或没有"type"属性），节不能(MUST NOT)包含一个<error/>子元素.

:* 接收到一个错误节的实体不能(MUST NOT)应答这个节更多的错误节; 这有助于防止死循环.

====语法====

:节相关错误的语法如下:

<source lang="xml">
<stanza-kind to='sender' type='error'>
[RECOMMENDED to include sender XML here]
<error type='error-type'>
<defined-condition xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
<text xmlns='urn:ietf:params:xml:ns:xmpp-stanzas' xml:lang='langcode'>
OPTIONAL descriptive text
</text>
[OPTIONAL application-specific condition element]
</error>
</stanza-kind>
</source>

:stanza-kind 是 message, presence, 或 iq 中的一个.

:<error/> 元素的'type'属性值必须(MUST)是以下之一:

:* cancel \-\- 不重试(这个错误是不可恢复的)

:* continue \-\- 继续进行(这个条件只是一个警告)

:* modify \-\- 改变数据之后重试

:* auth \-\- 提供证书之后重试

:* wait \-\- 等待之后重试(错误是暂时的)

:<error/>元素:

:* 必须(MUST)包含一个子元素,符合以下定义的节错误条件之一;这个元素(MUST)符合'urn:ietf:params:xml:ns:xmpp-stanzas'名字空间.

:* 可以(MAY)包含一个<text/>子元素容纳XML字符数据用来描述错误的更多细节;这个元素必须(MUST)符合'urn:ietf:params:xml:ns:xmpp-stanzas'名字空间并且应该(SHOULD)处理'xml:lang'属性.

:* 可以(MAY)包含一个应用程序定义的错误条件子元素;这个元素必须(MUST)符合一个应用程序定义的名字空间,并且它的结构由这个名字空间定义.

:<text/>元素是可选的(OPTIONAL).如果包含它,它应该(SHOULD)仅用于提供描述或诊断信息以补充一个已定义的条件或应用程序定义的条件. 它不应(SHOULD NOT)被应用程序认为是一个程序性的. 它不应(SHOULD NOT)被用作向一个使用者展示的错误信息,但是可以(MAY)展示除条件元素(或元素们)相关的错误信息之外的信息.

:最后,为了维护向后兼容性, 这个schema (定义在[XMPP-IM|XMPP文档列表/XMPP正式RFC标准/RFC3921])允许可选的在<error/>元素中包含一个("code")属性.

====已定义的条件====

:以下条件定义用于节错误.

:* <bad-request/> -- 发送者发送的XML是不规范的或不能被处理(例如一个IQ节包含了一个未被承认的'type'属性值); 相关的错误类型应该（SHOULD）是"modify".

:* <conflict/> -- 不同意访问，因为相同的名字或地址已存在一个资源或会话;相关的错误类型应该（ SHOULD）是"cancel".

:* <feature-not-implemented/> -- 请求的特性未被接收者或服务器实现所以不能处理;相关的错误类型应该（SHOULD）是"cancel".

:* <forbidden/> -- 请求实体没有必需的许可来执行这一动作;相关的错误类型应该（SHOULD）是"auth".

:* <gone/> -- 接收者或服务器无法再以这个地址进行联系(错误节可以（MAY）在<gone/>元素的XML字符数据中包含一个新的地址);相关的错误类型应该（SHOULD）是"modify".

:* <internal-server-error/> -- 服务器不能处理节，因为错误的配置或其他未定义的内部服务器错误;相关的错误类型应该（SHOULD）是"wait".

:* <item-not-found/> -- JID地址或申请的条目无法找到;相关的错误类型应该（SHOULD）是"cancel".

:* <jid-malformed/> -- 发送的实体提供的XMPP地址或与之通信的某个XMPP地址(如一个'to'属性值)或这个XMPP地址中的一部分(如一个资源ID)不符合寻址方案的语法(第三章);相关的错误类型应该（SHOULD）是"modify".

:* <not-acceptable/> -- 接收者或服务器理解这个请求但是拒绝处理，因为它不符合某些接收者或服务器定义的标准(例如,一个关于消息中可接收的单词的本地策略);相关错误类型应该（SHOULD）是"modify".

:* <not-allowed/> -- 接收者或服务器不允许任何实体执行这个动作;相关错误类型应该（SHOULD）是"cancel".

:* <not-authorized/> -- 在被允许执行某个动作之前发送者必须提供适当的证书,或已提供了不正确的证书;相关错误类型应该（SHOULD）是"auth".

:* <payment-required/> -- 请求实体未被授权访问请求的服务，因为需要付费;相关错误类型应该（SHOULD）是"auth".

:* <recipient-unavailable/> -- 预定的接收者暂时不可用;相关错误类型应该（SHOULD）是"wait"(注意: 如果这样做会导致泄露预定接收者的网络可用性给一个未被授权了解此信息的实体，应用程序不应该（MUST NOT）返回这个错误).

:* <redirect/> -- 接收者或服务器重定向这个请求信息到另一个实体，通常是暂时的(这个错误节应该（SHOULD）在<redirect/>元素的XML字符数据中包含一个预备的地址,它必须（MUST）是一个合法的JID); 相关的错误类型应该（SHOULD）是"modify".

:* <registration-required/> -- 请求实体未被授权访问请求的服务，因为需要注册;相关错误类型应该（SHOULD）是"auth".

:* <remote-server-not-found/> -- 在预定的接收者的全部或部分JID中的一个远程服务器或服务不存在;相关错误类型应该（SHOULD）是"cancel".

:* <remote-server-timeout/> -- 在预定的接收者（或需要完成的一个申请）的全部或部分JID中的一个远程服务器或服务无法在合理的时间内联系到;相关错误类型应该（SHOULD）是"wait".

:* <resource-constraint/> -- 服务器或接收者缺乏足够的系统资源来服务请求;相关错误类型应该（SHOULD）是"wait".

:* <service-unavailable/> -- 服务器或接收者目前无法提供被请求的服务;相关错误类型应该（SHOULD）是"cancel".

:* <subscription-required/> -- 请求实体未被授权访问能请求的服务，因为需要订阅;相关错误类型应该（SHOULD）是"auth".

:* <undefined-condition/> -- 错误条件不是本列表中定于的其他条件之一;任何错误类型可能和这个条件有关,并且它应该（SHOULD）仅用于关联一个应用程序定义的条件.

:* <unexpected-request/> -- 接收者或服务器理解这个请求但是不希望是在这个时间(比如,请求的顺序颠倒);相关错误类型应该（SHOULD）是"wait".

====应用程序定义条件====

:大家知道,一个应用程序可以（MAY）通过在错误元素里包含一个适当名字空间的字元素来提供应用程序定义的节错误信息. 应用程序定义的元素应该（SHOULD）补充或进一步限定一个已定义的元素. 因而,<error/>元素将包含两个或三个子元素:

<source lang="xml">
<iq type='error' id='some-id'>
<error type='modify'>
<bad-request xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
<too-many-parameters xmlns='application-ns'/>
</error>
</iq>
<message type='error' id='another-id'>
<error type='modify'>
<undefined-condition xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
<text xml:lang='en' xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'>
Some special application diagnostic information...
</text>
<special-application-condition xmlns='application-ns'/>
</error>
</message>
</source>

==服务器处理XML节的规则==

:兼容的服务器实现必须（MUST）确保两个实体之间的XML节按次序处理.

:在按次序处理的需求之外, 每个服务器实现将包含它自己的递送树"delivery tree"以处理它接收到的节.这个树决定一个节是否需要路由到其他域, 在内部处理, 还是递送到和一个已连接的节点相关的资源. 以下规则适用:

===没有'to'地址===

:如果这个节没有'to'属性, 服务器应该(SHOULD)为发送它的实体处理这个节. 因为所有从其他服务器收到的节必须(MUST)拥有'to'属性, 这个规则仅适用于从一个连接到这台服务器的已注册实体(如一个客户端)收到的节.如果这个服务器收到一个没有'to'属性的出席信息节, 服务器应该(SHOULD)向那些订阅了这个发送实体的出席信息的所有实体广播它, 如果可能的话(即时消息和出席信息应用程序中出席信息广播的语义定义在[XMPP-IM|XMPP文档列表/XMPP正式RFC标准/RFC3921]). 如果服务器接收到一个类型为"get" 或 "set" 的没有'to'属性的节并且它理解这个节的名字空间下的内容, 它必须(MUST)为这个发送实体处理节(在这里"process"的含义是由相关的名字空间的语义所决定的)或返回一个错误给发送实体.

===外部域===

:如果'to'属性中的JID的域ID部分的主机名和服务器自身或其子域配置的主机名不匹配, 服务器应该（SHOULD）路由这个节到外部域(取决于本地服务规定或安全策略关于域间通信的规定).有两种可能的情况:

::- 一个服务器之间的流已经存在于两个域之间: 发送者的服务器通过这个已存在的流为这个外部域路由这个节到授权服务器

::- 两个域之间不存在服务器间的流: 发送者服务器 (1) 解析这个外部域的主机名(定义在服务器间的通信Server-to-Server Communications (第十四章第四节)), (2) 在两个域之间进行服务器到服务器的流协商(定义在 Use of TLS (第五章) 和 Use of SASL (第六章)), 然后 (3) 通过这个新建的流为外部域路由这个节到授权服务器

:如果路由到接收者的服务器不成功, 发送者的服务器必须（MUST）返回一个错误给发送者; 如果接收者的服务器联系上了但是从接收者的服务器递送到接收者不成功, 接收者服务器必须（MUST）通过发送者的服务器返回一个错误给发送者.

===子域===

:如果'to'属性中的JID的域ID部分的主机名和服务器自身配置的主机名的一个子域名匹配,服务器必须（MUST）自己处理这个节或路由这个节到专门负责这个子域的特定服务(如果子域被配置了),或者返回一个错误给发送者(如果子域没有配置).

===纯粹的域或特定的资源===

:如果'to'属性中的JID的域ID部分的主机名和服务器自身配置的主机名本身匹配,并且'to'属性中的JID类型是<domain> 或 <domain/resource>, 服务器(或其中定于的资源)必须（MUST）根据节的类型适当的处理这个节或返回一个错误节给发送者.

===同一域中的节点===

:如果'to'属性中的JID的域ID部分的主机名和服务器自身配置的主机名本身匹配,并且'to'属性中的JID类型是<node@domain> 或 <node@domain/resource>, 服务器应该(SHOULD)递送这个节到节的'to'属性中的JID所指明的预定的接收者. 以下规则适用:

:# 如果这个JID包含一个资源ID(例如, 格式是<node@domain/resource>)并且存在一个连接的资源符合这个全JID, 接收者服务器应该（SHOULD）递送这个节给正确符合这个资源ID的流或会话.
:# 如果这个JID包含一个资源ID(例如, 格式是<node@domain/resource>)并且不存在一个连接的资源符合这个全JID, 接收者服务器应该（SHOULD）返回一个<service-unavailable/> 节错误给发送者.
:# 如果这个JID的格式是<node@domain>并且存在至少一个此节点的连接资源, 接收服务器应该（ SHOULD）递送这个节给至少其中一个已连接的资源, 依据应用程序定义的规则(一系列即时消息和出席信息应用程序的递送规则定义在[XMPP-IM|XMPP文档列表/XMPP正式RFC标准/RFC3921]).

==XMPP中的XML用法==

===限制===

:XMPP是一个简单的流式XML元素的专用协议用于接近实时地交换结构化信息. 因为XMPP不需要任意的解析和所有的XML文档, 所以XMPP不需要支持\[XML\]的所有功能. 特殊的, 适用以下限制.

:关于XML生成, 一个XMPP实现不能(MUST NOT)在XML流中注入以下任何东西:

:* 注释 (第二章第五节[XML])

:* 处理指示(第二章第六节同上)

:* 内部或外部的 DTD 子集 (第二章第八节同上)

:* 内部或外部的实体参考 (第四章第二节同上) 除了预定实体以外(第四章第六节同上)

:* 字符数据或属性值包含和预定实体列表中吻合的未逃逸的unescaped字符(第四章第六节同上); 这些字符必须（MUST）逃逸

:关于XML处理, 如果一个XMPP实现接收到这些受限的XML数据,它必须（MUST）忽略这些数据.

===XML 名字空间的名字和前缀===

:XML名字空间\[XML-NAMES\]为所有XMPP兼容的XML建立数据所有权的严格界限. 这个名字空间的基本功能是把结构上混合在一起的XML元素区分出不同的词汇. 确保XMPP兼容的XML有名字空间的感知能力使得任何允许的XML可以被结构化的混合到任何XMPP数据元素中. XML名字空间的名字和前缀的规则在下一小节中.

====流名字空间====

:在所有的XML流头中必须声明一个流名字空间. 流名字空间必须（MUST）是 'http://etherx.jabber.org/streams'. 元素名<stream/>和它的<features/>和<error/>子元素必须（MUST）在所有实例中符合这个流名字空间前缀. 一个实现应该（SHOULD）只为这些元素生成'stream:'前缀, 并且由于历史原因可以（MAY）只接受'stream:'前缀.

====缺省名字空间====

:在所有的XML流中必须声明一个缺省的流名字空间用于定义允许的流根元素的一级子元素. 这个名字空间声明对于初始化流和应答流必须（MUST）是相同的使得双方的流都是合格一致的. 缺省的名字空间声明适用于流和所有在流中发送的节(除非由流名字空间或回拨名字空间的前缀显式的符合另一个名字空间).

:一个服务器实现必须（MUST）支持以下两个缺省名字空间(由于历史原因, 一些实现可能(MAY)只支持这两个缺省名字空间):

:* jabber:client -- 当流用于客户端和服务器的通信时声明这个缺省名字空间

:* jabber:server -- 当流用于两个服务器间的通信时声明这个缺省名字空间

:一个客户端实现必须（MUST）支持'jabber:client'缺省名字空间,并且由于历史原因可以（MAY）只支持这个缺省名字空间.

:如果缺省名字空间是'jabber:client'或'jabber:server'，一个实施不能（MUST NOT）在这个名字空间下为元素生成名字空间前缀. 一个实现不应该（SHOULD NOT）按照元素的内容（可能和流相反）生成不同于'jabber:client'和'jabber:server'名字空间前缀.

:注意: 'jabber:client' 和 'jabber:server' 名字空间接近于相同但是用于不同的上下文(客户端服务器通信用'jabber:client' 而服务器间通信用'jabber:server'). 这两者之间仅有的不同在于在'jabber:client'中被发送的节中'to'和'from'属性是可选的（OPTIONAL）,而在'jabber:server'中被发送的节中它们是必需的（REQUIRED）. 如果兼容的实施接受一个符合'jabber:client'或'jabber:server'名字空间的流, 它必须（MUST）支持通用属性(第九章第一节)和三个核心节类型(message, presence, 和IQ)的基本语义(第九章第二节).

====回拨名字空间====

:所有用于服务器回拨的(第八章)元素都必须声明一个回拨名字空间. 回拨名字空间的名字必须（MUST）是'jabber:server:dialback'. 所有符合此名字空间的元素必须（MUST）有前缀. 一个实现应该（SHOULD）只为这些元素生成'db:'前缀并且只可以（MAY）接受'db:'前缀.

===确认===

:除了注意'jabber:server'名字空间中关于节中'to'和'from'地址的规定,一个服务器不需要为转发到客户端或其他服务器负责检查XML元素;一个实现可以（MAY）选择仅提供有效数据元素但这是可选的（OPTIONAL）(尽管一个实现不能（MUST NOT）接受不规范的XML). 客户端不应该（SHOULD NOT）滥用发送不符合schema的数据的能力, 并且应该（SHOULD）忽略接收到的XML流中任何和schema不一致的元素或属性值. XML流和节的有效性确认是可选的（OPTIONAL）,并且在这里提到的schemas仅用于描述的用途.

===文本声明的包含===

:实现应该（SHOULD）在发送一个流头信息之前发送一个文本声明. 应用程序必须（MUST）遵守\[XML\]中关于环境（那里对文本声明做了规定）的规则.

===字符编码===

:实现必须（MUST）支持通用字符集Universal Character Set (ISO/IEC 10646-1 \[UCS2\])字符到UTF\-8(RFC 3629 \[UTF\-8\])的转换, 必须符合 RFC 2277 \[CHARSET\]. 实现不能（MUST NOT）试图使用任何其他的编码.

==核心的兼容性要求==

:本章总结了可扩展的消息和出席信息协议中的某些方面，为了实施的兼容性，它们必须（MUST）被服务器和客户端支持，当然协议的其他方面也应该（SHOULD）被支持. 为了兼容的目的, 我们在核心协议(它必须(MUST)被任何服务器或客户端支持, 无论是什么特定的应用)和即时消息协议(仅仅是在核心协议之上的即时消息和出席信息应用必须(MUST)支持它)之间划了一个级别. 在本章中定义了所有服务器和客户端的兼容性要求; 即时消息服务器和客户端的兼容性要求在[XMPP-IM|XMPP文档列表/XMPP正式RFC标准/RFC3921]的相关章节中定义.

===服务器===

:除了所有已定义的关于安全, XML使用, 和国际化的要求之外, 一个服务器还必须(MUST)支持以下核心协议以保证兼容性:

:* 在地址中应用\[STRINGPREP\] 的 \[NAMEPREP\], Nodeprep (附录 A),和 Resourceprep (附录 B) profiles (包括确保域ID是\[IDNA\]中定义的国际化域名)

:* XML流(第四章), 包括Use of TLS(第五章), Use of SASL(第六章), 和Resource Binding (第七章)

:* 三个在stanza semantics(第九章第二节)中已定义的节类型(即,<message/>, <presence/>, 和<iq/>)的基本语义

:* 生成错误的语法及相关的流, TLS, SASL, 和 XML节的语义

:另外, 一个服务器可以(MAY)支持以下核心协议:

:* 服务器回拨 (第八章)

===客户端===

:一个客户端必须(MUST)支持以下核心协议以满足兼容性:

:* XML流(第四章), 包括Use of TLS(第五章), Use of SASL(第六章), 和Resource Binding (第七章)

:* 三个在stanza semantics(第九章第二节)中已定义的节类型(即,<message/>, <presence/>, 和<iq/>)的基本语义

:* 处理(并且, 如果可能, 生成) 错误的语法及相关的流, TLS, SASL, 和 XML节的语义

:另外, 一个客户端应该(SHOULD)支持以下核心协议:

:* 地址的生成应用\[STRINGPREP\] 的 \[NAMEPREP\], Nodeprep (附录 A),和 Resourceprep (附录 B) profiles

==国际化事项==

:XML流在Character Encoding(第十一章第五节)中定义为必须(MUST)被编码成UTF\-8. 在Stream Attributes(第四章第四节)中特别定义了, 一个XML流应该(SHOULD)包含一个'xml:lang'属性,它被认为是通过这个用于人类用户解读的流发送的任何XML字符数据的缺省语言. 在 xml:lang (第九章第一节第五小节)特别定义了, 如果一个XML节是用来给人类用户解读，这个节应该（SHOULD）包含一个'xml:lang'属性. 服务器在为连接的实体路由或递送节的时候应该（SHOULD）应用缺省的'xml:lang'属性, 并且不能（MUST NOT）修改或删除它从其他实体收到的节的'xml:lang'属性.

==安全性事项==

===高安全性===

:为了XMPP通信的目的(客户端-服务器和服务器-服务器), "高安全性"条款谈的是相互验证和完整性检查安全性技术的使用; 特别是, 当使用基于证书的验证来提供高安全性, 应该（ SHOULD）建立一个带外的信任链,尽管一个共享签名证书可能允许以前不知道的证书在带内建立信任关系. 参见以下第十四章第二节关于证书确认程序.

:实施必须（MUST）支持高安全性. 服务提供者应该（SHOULD）基于本地安全策略使用高安全性.

===证书确认===

:当一个XMPP点和另一个XMPP点安全的地通信, 它必须（MUST）确认对方终端的证书.有三种可能的情况:

:情形 #1: 点包含一个终端实体证书，以根证书的证书链中一环出现(见\[X509\]中的第六章第一节).

:情形 #2: 点的证书由一个对方不知道的证书授权.

:情形 #3: 点的证书由自己签名.

:在情形#1, 确认方必须(MUST)做以下两条之一:

:# 根据\[X509\]的规则确认对方证书.然后证书应该(SHOULD)被对方接下来在\[HTTP-TLS\]中描述的规则反向确认预期的身份。但如果"xmpp"是subjectAltName扩展类型，则必须（MUST）使用证书中的显示的身份。如果这两项检查之一失败,用户导向的客户端必须（MUST）通知用户（客户端可以（MAY）给用户机会继续连接）或以一个坏证书的错误终止连接。自动客户端应该（SHOULD）终止连接(以一个坏证书错误)并在适当的日志中记录这个错误。自动客户端可以（MAY）提供一个配置设置成禁止检查,但同时必须（MUST）提供一个激活检查的配置。
:# 点应该（SHOULD）出示证书给一个用户用于批准,包括完整的证书链.点必须（MUST）缓存这个证书(或一些其他不会忘记的表达方式比如一个哈希值).在将来的连接中,点必须（MUST）展示相同的证书并且如果改变了证书必须（MUST）通知用户.

:在情形#2 和情形#3, 实现应该（SHOULD）执行上述第二条.

===客户端-服务器通信===

:一个兼容的客户端实现必须（MUST）支持TLS和SASL用于连接到服务器.

:用于加密XML流的TLS协议(在 Use of TLS(第五章)定义)提供可信的机制帮助确保机密性和实体之间数据交换的完整性.

:用于验证XML流的SASL协议(在 Use of SASL(第六章)定义)提供可靠的机制用于确认一个连接到服务器的客户端确实是它自己所声明的那个客户端.

:服务器宣称的DNS主机名被解析之前，客户端-服务器通信不能（MUST NOT）继续进行。应该首先尝试解析\[SRV\]记录，其服务名为"xmpp-client"，协议名为"tcp"，整个资源记录类似"_xmpp-client._tcp.example.com."(使用字符"xmpp-client"表示服务ID是经过IANA注册).如果SRV查找失败,退而求其次，将查找一个正规的IPv4/IPv6地址记录来决定IP地址，使用"xmpp-client"端口5222，这个端口是在IANA注册了的。

:客户端的IP地址和访问方法不能（MUST NOT）被服务器公开, 也不能被被任何原始服务器之外的服务器索取。这帮助保护客户端的服务器避免受到直接攻击（译者注：似乎应该是客户避免受到直接攻击，但原文如此）或被第三方知道它的身份。

===服务器-服务器通信===

:一个兼容的服务器实现必须（MUST）支持TLS和SASL，用于域间的通信.因为历史原因,一个兼容的实施也应该（SHOULD）支持服务器回拨(第八章).

:因为服务提供者是一个策略问题,对于任何给定域和其他域的通信中，它是可选的（OPTIONAL），服务器之间的通信可以（MAY）被任何特定部署的管理员禁止。如果一个特殊的域允许域间的通信，它应该（SHOULD）允许高安全性。

:管理员可能想在服务器间使用SASL来通信，以确保双方的验证和保密性(比如在机构的私有网络).兼容实施应该（SHOULD）为这个目的支持SASL.

:服务器宣称的DNS主机名被解析之前，服务器-服务器通信不能（MUST NOT）继续进行。应该首先尝试解析\[SRV\]记录，其服务名为"xmpp-server"，协议名为"tcp"，整个资源记录类似"_xmpp-server._tcp.example.com."(使用字符"xmpp-server"表示服务ID是经过IANA注册的，注意要用"xmpp-server"取代以前用的"jabber",因为以前的用法不符合[SRV]标准；希望保持向后兼容的实现可以继续查找或应答"jabber"服务ID).如果SRV查找失败,退而求其次，将查找一个正规的IPv4/IPv6地址记录来决定IP地址，使用"xmpp-server"端口5269，这个端口是在IANA注册了的。

:服务器回拨防止域欺骗,从而使得伪造XML节更为困难.它和SASL和TLS不一样，它不是一个用于验证、安全或加密服务器之间的流的机制, 所以只是服务器身份的微弱确认而已。而且除非它使用了DNSSec \[DNSSEC\]否则它容易受到DNS中毒攻击,即使DNS信息是正确的,如果攻击者劫持了远程域,回拨也不能防止它的攻击.需要健壮的安全性的域应该(SHOULD)使用TLS和SASL.如果服务器间的验证使用了SASL,回拨就不应该(SHOULD NOT)使用了,因为它是多余的.

===层的次序===

:协议中的层的次序必须(MUST)如下堆积:

:# TCP
:# TLS
:# SASL
:# XMPP

:这个次序的原理是,[TCP]是基于连接的层,被所有使用,所以处于最上层, [TLS]经常是由操作系统层提供,[SASL]经常由应用程序层提供, XMPP则是应用程序本身.

===缺乏绑定到TLS的SASL通道===

:SASL构架不提供一个机制来绑定SASL验证到一个提供机密性和完整性保护的安全层。这一通道绑定"channel binding"的缺乏阻碍了SASL确认低层安全性所绑定的源和目标终端和SASL所验证的结果是否一致。如果终端不一致, 低层安全性不能被信任用来保护SASL验证的实体之间的数据传输。在这种情况下，一个SASL安全层进行握手的时候应该有效的忽略低层安全性的存在。

===强制实现的技术===

:最低要求, 所有实现必须（MUST）支持以下机制:

::对于验证: SASL [DIGEST-MD5] 机制

::对于机密性: TLS (使用 TLS_RSA_WITH_3DES_EDE_CBC_SHA 密码)

::对于两者: TLS 加 SASL EXTERNAL(使用 TLS_RSA_WITH_3DES_EDE_CBC_SHA 密码支持客户端证书)

===防火墙===

:使用XMPP通信通常是通过\[TCP\]连接到5222端口(客户端-服务器)或5269端口(服务器-服务器), 正如在IANA注册的那样(见 IANA Considerations (第十五章)). 使用这些广为人知的端口允许管理员很容易的通过一般的防火墙来激活或禁止XMPP活动.

===在SASL中使用base64===

:客户端和服务器都必须（MUST）确认在SASL协商中收到的任何\[BASE64\]数据. 一个实现必须(MUST)拒绝(不是忽略)任何非显式允许base64字母的字符串; 这有助于预防建立隐蔽通道泄漏信息的行为。一个实现不能（MUST NOT）在非法输入处中断，如果那个('=')被包含在一些和最后的数据字符(如, "=AAA" or "BBBB=CCC")不同的东西里面，必须(MUST)拒绝接下来的任何包含('=')的base64字符；这有助于防止对这个实现的缓存溢出攻击和其他攻击。Base 64编码从外表看隐藏了容易辨认的信息，例如密码，但是不提供任何算法机密性。Base 64编码必须（MUST）按照RFC 3548\[BASE64\]第三章的定义执行。

===Stringprep Profiles===

:为了处理域ID,XMPP使用了\[STRINGPREP\]中的\[NAMEPREP\] profile; 和Nameprep有关的安全性考虑, 参考\[NAMEPREP\]中的相关章节.

:另外, XMPP 定义了两个\[STRINGPREP\]的 profiles: 用于node identifiers的Nodeprep(附录 A)和用于resource identifiers的Resourceprep(附录 B).

:Unicode 和 ISO/IEC 10646 集有许多字符看起来相似. 在许多时候, 安全协议的使用者可能看起来吻合,比如当比较信任的第三方的名字的时候. 因为没有很多上下文的时候不可能映射看起来相似的字符,比如知道所用的字符集, stringprep不匹配相似字符串,也不因为一些字符串象看起来象别的字符串而禁止它们.

:一个节点ID可能被作为一个实体的XMPP地址的一部分. 一个通常的用途是作为一个即时消息用户的用户名；另一个用途是作为一个多用途聊天室的名字; 很多其他种类的实体可能使用节点ID作为他们的地址的一部分。这些服务的安全性可能会受到国际化节点ID的不同表达的威胁;例如, 一个用户键入一个单独的国际化的节点ID可能访问了另一个用户的帐号信息, 或一个用户可能获得访问一个受限的聊天室或服务的访问权限.

:一个资源ID可能被作为一个实体的XMPP地址的一部分。一个通常的用户是即时消息用户所连接的资源(激活的会话)的名字; 另一个是作为多用户聊天室的某用户的昵称; 许多其他种类的实体可能使用资源ID作为他们地址的一部分.这些服务的安全性可能会受到国际化资源ID的不同表达的威胁;例如, 一个用户可能尝试以同一个名字初始化多个会话,或一个用户可能发送一个消息给多用户聊天室的一个人但实际上发给了另外一个人.

==IANA 事项==

===用于TLS数据的XML名字空间名===

:XMPP中用于TLS相关数据的 URN 子名字空间定义如下. (这个名字空间的名字遵守The IETF XML Registry [XML-REG]定义的格式.)

::URI: urn:ietf:params:xml:ns:xmpp-tls

::Specification: RFC 3920

::Description: This is the XML namespace name for TLS-related data in the Extensible Messaging and Presence Protocol (XMPP) as defined by RFC 3920.

::Registrant Contact: IETF, XMPP Working Group, <xmppwg@jabber.org>

===用于SASL数据的XML名字空间名===

:XMPP中用于SASL相关数据的 URN 子名字空间定义如下. (这个名字空间的名字遵守The IETF XML Registry \[XML-REG\]定义的格式.)

::URI: urn:ietf:params:xml:ns:xmpp-sasl

::Specification: RFC 3920

::Description: This is the XML namespace name for SASL-related data in the Extensible Messaging and Presence Protocol (XMPP) as defined by RFC 3920.

::Registrant Contact: IETF, XMPP Working Group, <xmppwg@jabber.org>

===用于流错误的XML名字空间名===

:XMPP中用于流相关错误的 URN 子名字空间定义如下. (这个名字空间的名字遵守The IETF XML Registry [XML-REG]定义的格式.)

::URI: urn:ietf:params:xml:ns:xmpp-streams

::Specification: RFC 3920

:Description: This is the XML namespace name for stream-related error data in the Extensible Messaging and Presence Protocol (XMPP) as defined by RFC 3920.

::Registrant Contact: IETF, XMPP Working Group, <xmppwg@jabber.org>

===用于资源绑定的XML名字空间名===

:XMPP中用于资源绑定的 URN 子名字空间定义如下. (这个名字空间的名字遵守The IETF XML Registry [XML-REG]定义的格式.)

::URI: urn:ietf:params:xml:ns:xmpp-bind

::Specification: RFC 3920

::Description: This is the XML namespace name for resource binding in the Extensible Messaging and Presence Protocol (XMPP) as defined by RFC 3920.

::Registrant Contact: IETF, XMPP Working Group, <xmppwg@jabber.org>

===用于节错误的XML名字空间名===

:XMPP中用于节相关错误数据的 URN 子名字空间定义如下. (这个名字空间的名字遵守The IETF XML Registry \[XML-REG\]定义的格式.)

::URI: urn:ietf:params:xml:ns:xmpp-stanzas

::Specification: RFC 3920

::Description: This is the XML namespace name for stanza-related error data in the Extensible Messaging and Presence Protocol (XMPP) as defined by RFC 3920.

::Registrant Contact: IETF, XMPP Working Group, <xmppwg@jabber.org>

===Nodeprep Profile of Stringprep===

:The Nodeprep profile of stringprep是在Nodeprep(附录 A)定义的. IANA已经在stringprep profile registry中注册了 Nodeprep.

::Name of this profile:

:::Nodeprep

::RFC in which the profile is defined:

:::RFC 3920

::Indicator whether or not this is the newest version of the profile:

:::This is the first version of Nodeprep

===Resourceprep Profile of Stringprep===

:The Resourceprep profile of stringprep是在Resourceprep(附录 B)定义的. IANA已经在stringprep profile registry中注册了Resourceprep.

::Name of this profile:

:::Resourceprep

::RFC in which the profile is defined:

:::RFC 3920

::Indicator whether or not this is the newest version of the profile:

:::This is the first version of Resourceprep

===GSSAPI 服务名===

:IANA已经注册了 "xmpp" 作为一个 GSSAPI \[GSS-API\] 服务名, 在SASL Definition (第六章第三节)定义了.

===端口号===

:IANA已经注册了"xmpp-client" 和 "xmpp-server" 作为\[TCP\]端口号5222和5269的关键字.

:这些端口应该（SHOULD）用于客户端-服务器和服务器-服务器通信,但它们的使用是可选的（OPTIONAL）.

==参考==

===标准化参考===

:[ABNF] Crocker, D. and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", RFC 2234, November 1997.

:[BASE64] Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 3548, July 2003.

:[CHARSET] Alvestrand, H., "IETF Policy on Character Sets and Languages", BCP 18, RFC 2277, January 1998.

:[DIGEST-MD5] Leach, P. and C. Newman, "Using Digest Authentication as a SASL Mechanism", RFC 2831, May 2000.

:[DNS] Mockapetris, P., "Domain names \- implementation and specification", STD 13, RFC 1035, November 1987.

:[GSS-API] Linn, J., "Generic Security Service Application Program Interface Version 2, Update 1", RFC 2743, January 2000.

:[HTTP-TLS] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.

:[IDNA] Faltstrom, P., Hoffman, P., and A. Costello, "Internationalizing Domain Names in Applications (IDNA)", RFC 3490, March 2003.

:[IPv6] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6) Addressing Architecture", RFC 3513, April 2003.

:[LANGTAGS] Alvestrand, H., "Tags for the Identification of Languages", BCP 47, RFC 3066, January 2001.

:[NAMEPREP] Hoffman, P. and M. Blanchet, "Nameprep: A Stringprep Profile for Internationalized Domain Names (IDN)", RFC 3491, March 2003.

:[RANDOM] Eastlake 3rd, D., Crocker, S., and J. Schiller, "Randomness Recommendations for Security", RFC 1750, December 1994.

:[SASL] Myers, J., "Simple Authentication and Security Layer (SASL)", RFC 2222, October 1997.

:[SRV] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for specifying the location of services (DNS SRV)", RFC 2782, February 2000.

:[STRINGPREP] Hoffman, P. and M. Blanchet, "Preparation of Internationalized Strings ("stringprep")", RFC 3454, December 2002.

:[TCP] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.

:[TERMS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.

:[TLS] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999.

:[UCS2] International Organization for Standardization, "Information Technology \- Universal Multiple-octet coded Character Set (UCS) - Amendment 2: UCS Transformation Format 8 (UTF-8)", ISO Standard 10646-1 Addendum 2, October 1996.

:[UTF-8] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003.

:[X509] Housley, R., Polk, W., Ford, W., and D. Solo, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 3280, April 2002.

:[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>.

===信息参考===

:[ACAP] Newman, C. and J. Myers, "ACAP \-\- Application Configuration Access Protocol", RFC 2244, November 1997.

:[ASN.1] CCITT, "Recommendation X.208: Specification of Abstract Syntax Notation One (ASN.1)", 1988.

:[DNSSEC] Eastlake 3rd, D., "Domain Name System Security Extensions", RFC 2535, March 1999.

:[HTTP] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.

:[IMAP] Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION 4rev1", RFC 3501, March 2003.

:[IMP-REQS] Day, M., Aggarwal, S., Mohr, G., and J. Vincent, "Instant Messaging \/ Presence Protocol Requirements", RFC 2779, February 2000.

:[IRC] Oikarinen, J. and D. Reed, "Internet Relay Chat Protocol", RFC 1459, May 1993.

:[JEP-0029] Kaes, C., "Definition of Jabber Identifiers (JIDs)", JSF JEP 0029, October 2003.

:[JEP-0078] Saint-Andre, P., "Non-SASL Authentication", JSF JEP 0078, July 2004.

[JEP-0086] Norris, R. and P. Saint-Andre, "Error Condition Mappings", JSF JEP 0086, February 2004.

:[JSF] Jabber Software Foundation, "Jabber Software Foundation", <http://www.jabber.org/>.

:[POP3] Myers, J. and M. Rose, "Post Office Protocol - Version 3", STD 53, RFC 1939, May 1996.

:[SIMPLE] SIMPLE Working Group, "SIMPLE WG", <http://www.ietf.org/html.charters/simple-charter.html>.

:[SMTP] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, April 2001.

:[URI] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifiers (URI): Generic Syntax", RFC 2396, August 1998.

:[USINGTLS] Newman, C., "Using TLS with IMAP, POP3 and ACAP", RFC 2595, June 1999.

:[XML-REG] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, January 2004.

:[[RFC3921]] Saint-Andre, P., Ed., "Extensible Messaging and Presence Protocol (XMPP): Instant Messaging and Presence", RFC 3921, October 2004.

==附录 A. Nodeprep==

===A.1. 介绍===

:这个附录定义了 "Nodeprep" profile of [STRINGPREP]. 它定义了处理规则让用户能够在XMPP中输入国际化节点标识符并尽可能正确的获取正确的字符内容. (一个XMPP节点标识符是XMPP地址的可选部分，它在域名标识符和那个'@'分隔符之前；它经常但不是专门用来关联一个即时消息用户名)这些处理规则仅仅适用于XMPP节点标识符但不适用于任意文本或任何XMPP的其他方面.

:这个脚本定义了以下这些, 正如 [STRINGPREP]要求的:

:* 脚本预期的适用性: XMPP的国际化节点标识符

:* 用于stringprep的输入输出字符集: Unicode 3.2, 定义在本附录的第二章

:* 使用的映射: 定义在第三章

:* Unicode正规化使用: 定义在第四章

:* 禁止输出的字符串: 定义在第五章

:* 双字节字符处理: 定义在第六章

===A.2. 字符集===

:本脚本使用Unicode 3.2的未分配编码列表，指向 Table A.1, 也定义在 [STRINGPREP]的附录 A 中.

===A.3. 映射===

:本脚本指定使用[STRINGPREP]的以下表:

::Table B.1

::Table B.2

===A.4. 正规化===

:本脚本指定 Unicode正规化使用 form KC, 定义在 [STRINGPREP]中.

===A.5. 禁止输出===

:本脚本指定使用以下的[STRINGPREP]表禁止输出.

::Table C.1.1

::Table C.1.2

::Table C.2.1

::Table C.2.2

::Table C.3

::Table C.4

::Table C.5

::Table C.6

::Table C.7

::Table C.8

::Table C.9

:另外, 以下Unicode字符也被禁止:

: #x22 (")

: #x26 (&)

: #x27 (')

: #x2F (/)

: #x3A (:)

: #x3C (<)

: #x3E (>)

: #x40 (@)

===A.6. 双字节===

:本脚本指定按照[STRINGPREP]第六章检查双字节.

==附录 B. Resourceprep==

===B.1. 介绍===

:这个附录定义了 "Resourceprep" profile of \[STRINGPREP\]. 它定义了处理规则让用户能够在XMPP中输入国际化资源标识符并尽可能正确的获取正确的字符内容. (一个XMPP资源标识符是XMPP地址的可选部分，它在域名标识符和'/@'分隔符之后；它经常但不是专门用来关联一个即时消息会话名)这些处理规则仅仅适用于XMPP资源标识符但不适用于任意文本或任何XMPP的其他方面.

:这个脚本定义了以下这些, 正如 [STRINGPREP]要求的:

:* 脚本预期的适用性: XMPP的国际化节点标识符

:* 用于stringprep的输入输出字符集: Unicode 3.2, 定义在本附录的第二章

:* 使用的映射: 定义在第三章

:* Unicode正规化使用: 定义在第四章

:* 禁止输出的字符串: 定义在第五章

:* 双字节字符处理: 定义在第六章

===B.2. 字符集===

:本脚本使用Unicode 3.2的未分配编码列表，指向 Table A.1, 也定义在 [STRINGPREP]的附录

===B.3. 映射===

:本脚本指定使用[STRINGPREP]的以下表:

::Table B.1

===B.4. 正规化===

:本脚本指定使用 Unicode normalization form KC, 定义在 [STRINGPREP]中.

===B.5. 禁止输出===

:本脚本指定使用以下的[STRINGPREP]表禁止输出.

::Table C.1.2

::Table C.2.1

::Table C.2.2

::Table C.3

::Table C.4

::Table C.5

::Table C.6

::Table C.7

::Table C.8

::Table C.9

===B.6. 双字节===

:本脚本指定按照[STRINGPREP]第六章检查双字节.

==附录 C. XML 规划==

:以下 XML schemas 是描述性的, 不是标准的. 'jabber:client' 和 'jabber:server' 名字空间的标准定义, 参照 [[RFC3921]].

===C.1. Streams namespace===

<source lang="xml">
<?xml version='1.0' encoding='UTF-8'?>

<xs:schema
xmlns:xs='http://www.w3.org/2001/XMLSchema'
targetNamespace='http://etherx.jabber.org/streams'
xmlns='http://etherx.jabber.org/streams'
elementFormDefault='unqualified'>

<xs:element name='stream'>
<xs:complexType>
<xs:sequence xmlns:client='jabber:client'
xmlns:server='jabber:server'
xmlns:db='jabber:server:dialback'>
<xs:element ref='features' minOccurs='0' maxOccurs='1'/>
<xs:any namespace='urn:ietf:params:xml:ns:xmpp-tls'
minOccurs='0'
maxOccurs='unbounded'/>
<xs:any namespace='urn:ietf:params:xml:ns:xmpp-sasl'
minOccurs='0'
maxOccurs='unbounded'/>
<xs:choice minOccurs='0' maxOccurs='1'>
<xs:choice minOccurs='0' maxOccurs='unbounded'>
<xs:element ref='client:message'/>
<xs:element ref='client:presence'/>
<xs:element ref='client:iq'/>
</xs:choice>
<xs:choice minOccurs='0' maxOccurs='unbounded'>
<xs:element ref='server:message'/>
<xs:element ref='server:presence'/>
<xs:element ref='server:iq'/>
<xs:element ref='db:result'/>
<xs:element ref='db:verify'/>
</xs:choice>
</xs:choice>
<xs:element ref='error' minOccurs='0' maxOccurs='1'/>
</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='version' type='xs:decimal' use='optional'/>
<xs:attribute ref='xml:lang' use='optional'/>
</xs:complexType>
</xs:element>

<xs:element name='features'>
<xs:complexType>
<xs:all xmlns:tls='urn:ietf:params:xml:ns:xmpp-tls'
xmlns:sasl='urn:ietf:params:xml:ns:xmpp-sasl'
xmlns:bind='urn:ietf:params:xml:ns:xmpp-bind'
xmlns:sess='urn:ietf:params:xml:ns:xmpp-session'>
<xs:element ref='tls:starttls' minOccurs='0'/>
<xs:element ref='sasl:mechanisms' minOccurs='0'/>
<xs:element ref='bind:bind' minOccurs='0'/>
<xs:elemnt ref='sess:session' minOccurs='0'/>
</xs:all>
</xs:complexType>
</xs:element>

<xs:element name='error'>
<xs:complexType>
<xs:sequence xmlns:err='urn:ietf:params:xml:ns:xmpp-streams'>
<xs:group ref='err:streamErrorGroup'/>
<xs:element ref='err:text'
minOccurs='0'
maxOccurs='1'/>
</xs:sequence>
</xs:complexType>
</xs:element>

</xs:schema>
</source>

===C.2. Stream error namespace===

<source lang="xml">
<?xml version='1.0' encoding='UTF-8'?>

<xs:schema
xmlns:xs='http://www.w3.org/2001/XMLSchema'
targetNamespace='urn:ietf:params:xml:ns:xmpp-streams'
xmlns='urn:ietf:params:xml:ns:xmpp-streams'
elementFormDefault='qualified'>

<xs:element name='bad-format' type='empty'/>
<xs:element name='bad-namespace-prefix' type='empty'/>
<xs:element name='conflict' type='empty'/>
<xs:element name='connection-timeout' type='empty'/>
<xs:element name='host-gone' type='empty'/>
<xs:element name='host-unknown' type='empty'/>
<xs:element name='improper-addressing' type='empty'/>
<xs:element name='internal-server-error' type='empty'/>
<xs:element name='invalid-from' type='empty'/>
<xs:element name='invalid-id' type='empty'/>
<xs:element name='invalid-namespace' type='empty'/>
<xs:element name='invalid-xml' type='empty'/>
<xs:element name='not-authorized' type='empty'/>
<xs:element name='policy-violation' type='empty'/>
<xs:element name='remote-connection-failed' type='empty'/>
<xs:element name='resource-constraint' type='empty'/>
<xs:element name='restricted-xml' type='empty'/>
<xs:element name='see-other-host' type='xs:string'/>
<xs:element name='system-shutdown' type='empty'/>
<xs:element name='undefined-condition' type='empty'/>
<xs:element name='unsupported-encoding' type='empty'/>
<xs:element name='unsupported-stanza-type' type='empty'/>
<xs:element name='unsupported-version' type='empty'/>
<xs:element name='xml-not-well-formed' type='empty'/>

<xs:group name='streamErrorGroup'>
<xs:choice>
<xs:element ref='bad-format'/>
<xs:element ref='bad-namespace-prefix'/>
<xs:element ref='conflict'/>
<xs:element ref='connection-timeout'/>
<xs:element ref='host-gone'/>
<xs:element ref='host-unknown'/>
<xs:element ref='improper-addressing'/>
<xs:element ref='internal-server-error'/>
<xs:element ref='invalid-from'/>
<xs:element ref='invalid-id'/>
<xs:element ref='invalid-namespace'/>
<xs:element ref='invalid-xml'/>
<xs:element ref='not-authorized'/>
<xs:element ref='policy-violation'/>
<xs:element ref='remote-connection-failed'/>
<xs:element ref='resource-constraint'/>
<xs:element ref='restricted-xml'/>
<xs:element ref='see-other-host'/>
<xs:element ref='system-shutdown'/>
<xs:element ref='undefined-condition'/>
<xs:element ref='unsupported-encoding'/>
<xs:element ref='unsupported-stanza-type'/>
<xs:element ref='unsupported-version'/>
<xs:element ref='xml-not-well-formed'/>
</xs:choice>
</xs:group>

<xs:element name='text'>
<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:simpleType name='empty'>
<xs:restriction base='xs:string'>
<xs:enumeration value=''/>
</xs:restriction>
</xs:simpleType>

</xs:schema>
<／source>

===C.3. TLS namespace==

<source lang="xml">
<?xml version='1.0' encoding='UTF-8'?>

<xs:schema
xmlns:xs='http://www.w3.org/2001/XMLSchema'
targetNamespace='urn:ietf:params:xml:ns:xmpp-tls'
xmlns='urn:ietf:params:xml:ns:xmpp-tls'
elementFormDefault='qualified'>

<xs:element name='starttls'>
<xs:complexType>
<xs:sequence>
<xs:element
name='required'
minOccurs='0'
maxOccurs='1'
type='empty'/>
</xs:sequence>
</xs:complexType>
</xs:element>

<xs:element name='proceed' type='empty'/>
<xs:element name='failure' type='empty'/>

<xs:simpleType name='empty'>
<xs:restriction base='xs:string'>
<xs:enumeration value=''/>
</xs:restriction>
</xs:simpleType>

</xs:schema>
</source>

===C.4. SASL namespace===

<source lang="xml">
<?xml version='1.0' encoding='UTF-8'?>

<xs:schema
xmlns:xs='http://www.w3.org/2001/XMLSchema'
targetNamespace='urn:ietf:params:xml:ns:xmpp-sasl'
xmlns='urn:ietf:params:xml:ns:xmpp-sasl'
elementFormDefault='qualified'>

<xs:element name='mechanisms'>
<xs:complexType>
<xs:sequence>
<xs:element name='mechanism'
maxOccurs='unbounded'
type='xs:string'/>
</xs:sequence>
</xs:complexType>
</xs:element>

<xs:element name='auth'>
<xs:complexType>
<xs:simpleContent>
<xs:extension base='empty'>
<xs:attribute name='mechanism'
type='xs:string'
use='optional'/>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
</xs:element>

<xs:element name='challenge' type='xs:string'/>
<xs:element name='response' type='xs:string'/>
<xs:element name='abort' type='empty'/>
<xs:element name='success' type='empty'/>

<xs:element name='failure'>
<xs:complexType>
<xs:choice minOccurs='0'>
<xs:element name='aborted' type='empty'/>
<xs:element name='incorrect-encoding' type='empty'/>
<xs:element name='invalid-authzid' type='empty'/>
<xs:element name='invalid-mechanism' type='empty'/>
<xs:element name='mechanism-too-weak' type='empty'/>
<xs:element name='not-authorized' type='empty'/>
<xs:element name='temporary-auth-failure' type='empty'/>
</xs:choice>
</xs:complexType>
</xs:element>
<xs:simpleType name='empty'>
<xs:restriction base='xs:string'>
<xs:enumeration value=''/>
</xs:restriction>
</xs:simpleType>

</xs:schema>
</source>

===C.5. Resource binding namespace===

<source lang="xml">
<?xml version='1.0' encoding='UTF-8'?>

<xs:schema
xmlns:xs='http://www.w3.org/2001/XMLSchema'
targetNamespace='urn:ietf:params:xml:ns:xmpp-bind'
xmlns='urn:ietf:params:xml:ns:xmpp-bind'
elementFormDefault='qualified'>

<xs:element name='bind'>
<xs:complexType>
<xs:choice minOccurs='0' maxOccurs='1'>
<xs:element name='resource' type='xs:string'/>
<xs:element name='jid' type='xs:string'/>
</xs:choice>
</xs:complexType>
</xs:element>

</xs:schema>
</source>

===C.6. Dialback namespace===

<source lang="xml">
<?xml version='1.0' encoding='UTF-8'?>

<xs:schema
xmlns:xs='http://www.w3.org/2001/XMLSchema'
targetNamespace='jabber:server:dialback'
xmlns='jabber:server:dialback'
elementFormDefault='qualified'>

<xs:element name='result'>
<xs:complexType>
<xs:simpleContent>
<xs:extension base='xs:token'>
<xs:attribute name='from' type='xs:string' use='required'/>
<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='invalid'/>
<xs:enumeration value='valid'/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
</xs:element>

<xs:element name='verify'>
<xs:complexType>
<xs:simpleContent>
<xs:extension base='xs:token'>
<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='optional'>
<xs:simpleType>
<xs:restriction base='xs:NCName'>
<xs:enumeration value='invalid'/>
<xs:enumeration value='valid'/>
</xs:restriction>
</xs:simpleType>
</xs:attribute>
</xs:extension>
</xs:simpleContent>
</xs:complexType>
</xs:element>

</xs:schema>
</source>

===C.7. Stanza error namespace===

<source lang="xml">
<?xml version='1.0' encoding='UTF-8'?>

<xs:schema
xmlns:xs='http://www.w3.org/2001/XMLSchema'
targetNamespace='urn:ietf:params:xml:ns:xmpp-stanzas'
xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'
elementFormDefault='qualified'>

<xs:element name='bad-request' type='empty'/>
<xs:element name='conflict' type='empty'/>
<xs:element name='feature-not-implemented' type='empty'/>
<xs:element name='forbidden' type='empty'/>
<xs:element name='gone' type='xs:string'/>
<xs:element name='internal-server-error' type='empty'/>
<xs:element name='item-not-found' type='empty'/>
<xs:element name='jid-malformed' type='empty'/>
<xs:element name='not-acceptable' type='empty'/>
<xs:element name='not-allowed' type='empty'/>
<xs:element name='payment-required' type='empty'/>
<xs:element name='recipient-unavailable' type='empty'/>
<xs:element name='redirect' type='xs:string'/>
<xs:element name='registration-required' type='empty'/>
<xs:element name='remote-server-not-found' type='empty'/>
<xs:element name='remote-server-timeout' type='empty'/>
<xs:element name='resource-constraint' type='empty'/>
<xs:element name='service-unavailable' type='empty'/>
<xs:element name='subscription-required' type='empty'/>
<xs:element name='undefined-condition' type='empty'/>
<xs:element name='unexpected-request' type='empty'/>

<xs:group name='stanzaErrorGroup'>
<xs:choice>
<xs:element ref='bad-request'/>
<xs:element ref='conflict'/>
<xs:element ref='feature-not-implemented'/>
<xs:element ref='forbidden'/>
<xs:element ref='gone'/>
<xs:element ref='internal-server-error'/>
<xs:element ref='item-not-found'/>
<xs:element ref='jid-malformed'/>
<xs:element ref='not-acceptable'/>
<xs:element ref='not-allowed'/>
<xs:element ref='payment-required'/>
<xs:element ref='recipient-unavailable'/>
<xs:element ref='redirect'/>
<xs:element ref='registration-required'/>
<xs:element ref='remote-server-not-found'/>
<xs:element ref='remote-server-timeout'/>
<xs:element ref='resource-constraint'/>
<xs:element ref='service-unavailable'/>
<xs:element ref='subscription-required'/>
<xs:element ref='undefined-condition'/>
<xs:element ref='unexpected-request'/>
</xs:choice>
</xs:group>

<xs:element name='text'>
<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:simpleType name='empty'>
<xs:restriction base='xs:string'>
<xs:enumeration value=''/>
</xs:restriction>
</xs:simpleType>

</xs:schema>
</source>

==附录 D. 核心Jabber协议和XMPP的不同==

:本章是非标准的.

::译者注：附录D对于新接触XMPP的人没有什么意义，就不翻译了，免得浪费时间。因为现在RFC公布已经很久了，以前的Jabber实现很多都进化到XMPP了。

: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 core differences, while the corresponding section of [[RFC3921]] summarizes the differences that relate specifically to instant messaging and presence applications.

===D.1. Channel Encryption===

:It was common practice in the Jabber community to use SSL for channel encryption on ports other than 5222 and 5269 (the convention is to use ports 5223 and 5270). XMPP uses TLS over the IANA-registered ports for channel encryption, as defined under Use of TLS (Section 5) herein.

===D.2. Authentication===

:The client-server authentication protocol developed in the Jabber community used a basic IQ interaction qualified by the 'jabber:iq:auth' namespace (documentation of this protocol is contained in \[JEP-0078\], published by the Jabber Software Foundation [JSF]). XMPP uses SASL for authentication, as defined under Use of SASL (Section 6) herein.

:The Jabber community did not develop an authentication protocol for server-to-server communications, only the Server Dialback (Section 8) protocol to prevent server poofing. XMPP supersedes Server Dialback with a true server-to-server authentication protocol, as defined under Use of SASL (Section 6) herein.

===D.3. Resource Binding===

:Resource binding in the Jabber community was handled via the 'jabber:iq:auth' namespace (which was also used for client authentication with a server). XMPP defines a dedicated namespace for resource binding as well as the ability for a server to generate a resource identifier on behalf of a client, as defined under Resource Binding (Section 7).

===D.4. JID Processing===

:JID processing was somewhat loosely defined by the Jabber community (documentation of forbidden characters and case handling is contained in [JEP-0029], published by the Jabber Software Foundation [JSF]). XMPP specifies the use of \[NAMEPREP\] for domain identifiers and supplements Nameprep with two additional [STRINGPREP] profiles for JID processing: Nodeprep (Appendix A) for node identifiers and Resourceprep (Appendix B) for resource identifiers.

===D.5. Error Handling===

:Stream-related errors were handled in the Jabber community via XML character data text in a <stream:error/> element. In XMPP, stream-related errors are handled via an extensible mechanism defined under Stream Errors (Section 4.7) herein. Stanza-related errors were handled in the Jabber community via HTTP-style error codes. In XMPP, stanza-related errors are handled via an extensible mechanism defined under Stanza Errors (Section 9.3) herein. (Documentation of a mapping between Jabber and XMPP error handling mechanisms is contained in \[JEP-0086\], published by the Jabber Software Foundation [JSF].)

===D.6. Internationalization===

:Although use of UTF-8 has always been standard practice within the Jabber community, the community did not define mechanisms for specifying the language of human-readable text provided in XML character data. XMPP specifies the use of the 'xml:lang' attribute in such contexts, as defined under Stream Attributes (Section 4.4) and xml:lang (Section 9.1.5) herein.

===D.7. Stream Version Attribute===

:The Jabber community did not include a 'version' attribute in stream headers. XMPP specifies inclusion of that attribute as a way to signal support for the stream features (authentication, encryption, etc.) defined under Version Support (Section 4.4.1) herein.

==贡献者==

:XMPP的大部分核心方面是由1999年开始的Jabber开源社区开发的. 这个社区是由 Jeremie Miller建立的, 他于1999年1月发布了最初版的jabber server源代码. 主要的基础协议的早期贡献者还包括 Ryan Eatmon, Peter Millard, Thomas Muldowney,和 Dave Smith. XMPP工作组的工作主要集中在安全性和国际化方面; 在这些领域, 使用 TLS 和 SASL 的协议最初是由 Rob Norris贡献的, stringprep profiles 最初是由 Joe Hildebrand贡献的. The error code syntax 是由Lisa Dusseault建议的.

==致谢==

:感谢许多在贡献者名单之外的人们. 尽管很难提供一个完整的名单, 以下个人对于定义协议或评论标准提供了很多帮助:

:Thomas Charron, Richard Dobson, Sam Hartman, Schuyler Heath, Jonathan Hogg, Cullen Jennings, Craig Kaes, Jacek Konieczny, Alexey Melnikov, Keith Minkler, Julian Missig, Pete Resnick, Marshall Rose, Alexey Shchepin, Jean-Louis Seguineau, Iain Shigeoka, Greg Troxel, and David Waite.

:也感谢 XMPP工作组的成员和 IETF 社区在本文的成文过程中一直提供的评论和反馈。

==作者地址==

:Peter Saint-Andre (editor)

:Jabber Software Foundation

:EMail: stpeter@jabber.org

==完整的版权声明==

: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 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==

: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. 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.

==感谢==

:目前为RFC编辑活动提供资金的Internet Society.