YD/T 2936-2015.Extensible messaging and presence protocol (XMPP)-Instant messaging and presence.
1范围
YD/T 2936规定了扩展消息与表示协议(XMPP) 的即时消息与表示的通信规则，用于使任意两个或多个的网络实体间能够进行准实时结构的未扩展数据交换，以便于实体能够获得更详尽的结构信息。
YD/T 2936适用于即时通讯系统。
2规范性引用文件
下列文件对于本文件的应用是必不可少的。凡是注日期的引用文件，仅所注日期的版本适用于本文件。凡是不注日期的引用文件，其最新版本(包括所有的修改单)适用于本文件。
YD/T 2935 扩展消息与表示协议(XMPP) 核心协议
IETF RFC2779 即时消息协议需求(Instant Messaging/ Presence Protocol Requirements)
IETF RFC3861 即时消息与表示的地址解决方法(Address Resolution for Instant Messaging and Presence )
IETF RFC3987 国际化资源标识符(Internationalized Resource ldentifiers (IRIs))
IETF RFC4422 简单认证与安全层协议(Simple Authentication and Security Layer (SASL))

ICS33.100.70
中华人民共和国通信行业标准
YD/T2936-2015
扩展消息与表示协议（XMPP）
即时消息与表示
Extensible messaging and presenceprotocol (XMPP)-Instantmessagingandpresence2015-07-14发布
2015-10-01实施
中华人民共和国工业和信息化部发布前
范围·
规范性引用文件·
缩略语
功能概述·
名册管理…
语法和语义
登录时接收一个人的名册
增加一个名册条目
更新名册条目
删除一个名册条目
名册版本
管理表示订阅·
概述·
请求一个订阅项…
取消一个订阅项
取消订阅：
预批准请求订阅·
交换表示信息
表示基本原理·
初始化表示
表示探测
后续的表示广播…
不可用的表示
定向的表示免费标准bzxz.net
表示语法·
交换消息
概述·
一对一的聊天会话
消息语法
扩展的内容
YD/T2936-2015
YD/T2936-2015
交换IQ节
个示例会话
服务器处理XML节的规则
一般性事项：
没有“to\地址·
远程域·
本地域·
本地用户
URIs的处理.
国际化事项
安全性事项·
16一致性要求
附录A（规范性附录）订阅状态
附录B（资料性附录）通信阻塞
附录C（资料性附录）
vCards*+
附录D（资料性附录）“jabber:iq:roster的XML规划I
本标准是XMPP系列标准之一，本系列标准的名称和结构预计如下：扩展消息与表示协议核心协议；扩展消息与表示协议即时消息与表示；一扩展消息与表示协议地址格式：一扩展消息与表示协议端到端的签名与对象加密。本标准按照GB/T1.1-2009给出的规则起草。YD/T2936-2015
请注意本文件的某些内容可能涉及专利。本文件的发布机构不承担识别这些专利的责任。本标准由中国通信标准化协会提出并归口。本标准起草单位：重庆邮电大学、中国信息通信研究院、国家电网公司信息通信分公司。本标准主要起草人：谢昊飞、王浩、蔡林沁、唐晓铭、李瑞雪、罗志勇、魏曼、王恒、兰飞、锋、刘建明、陈星、
张炎、谢金凤。
1范围
扩展消息与表示协议（XMPP）
即时消息与表示
YD/T2936-2015
本标准规定了扩展消息与表示协议（XMPP）的即时消息与表示的通信规则，用于使任意两个或多个的网络实体间能够进行准实时结构的未扩展数据交换，以便于实体能够获得更详尽的结构信息。本标准适用于即时通讯系统。
2规范性引用文件
下列文件对于本文件的应用是必不可少的。凡是注日期的引用文件，仅所注日期的版本适用于本文件。凡是不注日期的引用文件，其最新版本（包括所有的修改单）适用于本文件。YD/T2935
IETFRFC2779
IETFRFC3861
IETFRFC3987
IETFRFC4422
IETFRFC5122
IETFRFC524
IETFRFC6121
XSFXEP-0016
XSFXEP-0045
XSFXEP-0071
XSFXEP-0115
XSFXEP-0191
XSFXEP-0237
3缩略语
扩展消息与表示协议（XMPP）核心协议即时消息协议需求（InstantMessaging/PresenceProtocolRequirements）即时消息与表示的地址解决方法（AddressResolutionforInstantMessagingandPresence)
国际化资源标识符（InternationalizedResourceIdentifiers（IRIs））简单认证与安全层协议（SimpleAuthenticationandSecurityLayer（SASL））针对XMPP的IRIs和URIs（InternationalizedResourceIdentifiers(IRIs）andUniformResourceIdentifiers (URIs)forthe ExtensibleMessaging and PresenceProtocol (XMPP))
传输层控制协议（TheTransportLayerSecurity（TLS)ProtocolVersion1.2）扩展消息与表示协议（(XMPP）即时消息与表示（ExtensibleMessagingandPresence Protocol (XMPP):Instant Messaging and Presence)隐私名单（PrivacyLists）
多用户聊天协议（Multi-UserChat）XHTML即时消息（\XHTML-IM）
实体能力（EntityCapabilities）简单通信阻塞（SimpleCommunicationsBlocking）登记版本（RosterVersioning）下列缩略语适用于本文件。
Info/Query
InternationalizedResourceIdentifiersJabber Identifier
SimpleAuthenticationAnd SecurityLayerTransport Layer Security
信息/查询
国际化资源标识符
标识符
简单认证和安全层协议
传输层安全协议
YD/T2936-2015
4需求
Uniform Resource IdentifiersExtensible Markup Language
统一资源标识符
可扩展标记语言
ExtensibleMessagingandPresenceProtocol扩展消息与表示协议从习惯上说，即时通信应用结合了以下几个因素。a）聚集的中心是一个联系人或好友的列表（在XMPP中，这个列表被称为“名册”）：b）使用这种应用程序的目的是实现准实时的与特定的联系人交换简短的文本消息，通常大部分这种消息是连续的，并以本标准5.1描述的一对一“聊天会话”的形式进行：c）这种消息的交换是基于“表示”的，例如，关于某个特定联系人的网络可用性的消息（由此知道进行一对一聊天会话的联系人有哪些是在线或可用的）：d）表示消息只提供给那些明确通过认证的联系人，叫做“表示订阅”。因此本标准在较高的级别上假设用户必须能够完成以下使用案例：管理联系人列表中的条目
·与联系人交换信息
与联系人交换表示信息
管理发给联系人的或从联系人收到的表示订阅这些领域的功能详细定义在IETFRFC2779中，感兴趣的用户可以直接阅读原文关于需求方面更深入的内容。虽然基于XMPP的即时消息和表示信息符合RFC2779的要求，但它不是特意为那种协议设计的，因为基础协议是在RFC2779成文之前通过Jabber开放源代码社区的一个开放的开发过程发展出来的。尽管XMPP标准委员会在“XEP”系列协议中定义了许多其他方面的功能（如XSFXEP-0045中描述的多用户文本聊天），但是这些协议不包含在本标准之中，因为它们不是RFC2779所规定的。实现注意事项：IETFRFC2779规定表示服务应与即时通信分离。例如，它应尽可能地用这个协议来提供一个表示消息服务、一个即时消息服务，或同时提供两者。尽管本标准假定实现和部署希望提供统一的即时消息和表示消息服务，但没有要求一个服务应同时提供表示消息服务和即时消息服务，并且协议也提供了把表示消息服务和即时消息服务分离成为独立服务的可能性（如当一个客户端尝试发送一个节时，个只提供表示的服务可以返回一个的节错误）。5功能概述
本章提供给了基于XMPP的即时通信和表示特征的功能总结。YD/T2935《扩展消息与表示协议（XMPP）核心协议》规定了-一个XMPP客户端如何连接到XMPP服务器。特别是，其指定了客户端给其他的XMPP网络实体发送XML节（XMPP中的基本单元）之前应完成的先决条件。这些先决条件由XML流协商组成，并包括XML流头部的交换，可选的通过传输层安全协议（TLS）保障的通道加密，通过SASL保障的强制认证，以及为客户端寻址的流绑定资源。兼容性要求：规定了一个额外的先决条件：正式建立一个即时通信和表示会话。实现和部署经验表明这个先决条件是必不可少的。然而，为了向后兼容，一个实现仍然提供这种功能。这使得旧的软件在能连接上网络的同时也能使新软件节省交互过程。2
YD/T2936-2015
当实现YD/T2935《扩展消息与表示协议（XMPP）核心协议》中规定的先决条件时，一个XMPP客户端和XMPP服务器之间会有一个长久的XML流交互，这使得用户能够通过发送和接收流来控制客户端可能存在的无限数量的XML节。这种流能用来交换消息，分享表示信息以及准实时的方式进行结构化请求-响应交互。在XML流协商以后，即时通信和表示会话的通用流如下所述a）获取花名册；
b）发送初始化表示消息给服务器，服务器广播给所有订阅的联系人，这样就从XMPP通信的角度上线”了：
c）交换消息、管理表示订阅、完成名册更新以及在会话期间的一般过程和用特殊的语法生成其他的XML节：
d）当发送不可用的表示信息时，终止会话并关闭XML流。6名册管理
6.1概述
在XMPP中，用户的联系人列表称为名册，包括任意数量的特定名册条目。每个用户的名册存储在用户的服务器上，从而这个用户可以从任何资源访问该名册信息。当用户在名册中增加条自或者修改已存在的条自时，如果没有错误发生，那么服务器应存储修改的数据，并且当一个通过认证的客户端请求名册时应返回它存储的数据。
安全性注意事项：由于用户的名册可能包含机密资料，服务器应限制对这些数据的访问，因此，只有授权的实体（通常仅限为账户的所有者）才能获取，修改或删除这些数据。假设只有存储用户名册的地方才是用户注册账户的服务器，用户只有通过这个服务器才能通过认证并访问网络。本标准中删除了名册存储、账户注册和网络认证之间必须严格匹配的规则，导致用户可以把它们的名册存储在另一个地点，或者能将多个名册存储在多个地点。然而，由于缺少实施和部署更加灵活的名册存储模型的经验，使用“客户端”和“服务器”（用“联系人名单”取代“某一个联系人名单”），而不是采用新的术语代替“用户存储名册的地点”。未来的规范中可能会为无服务器名册存储或多名册管理提供规范的规则，但这种规则不在本标准的范围之内。6.2语法和语义
6.2.1版本属性
版本属性是一个用于识别特定版本的名册信息的学符串。它应由服务器生成，并被客户端视为不透明。服务器可以采用任何适当的方法生成版本号，比如说名册数据中的哈希表或者是严格递增的序列号。本标准建议包含版本号属性。
对于版本属性的使用在6.6中有详细介绍。兼容性要求：元素中的版本属性在本标准中是最新定义的。6.2.2名册条目
一个名册中的元素可以包含一个或多个子元素。每个子元素描述个唯一的“名册条目”（有时候也称为“联系人”）。条目子元素的语法在下面的章节中描述。6.2.2.1Approved属性
YD/T2936-2015
“Approved”属性是一个布尔对象，“真”值用在7.4节所描述的预先批准的订阅信息中（默认的值是“假”，这与[XML-DATATYPES]保持一致】。服务器在给客户端发布预先批准的订阅应包含“Approved”属性。客户端在发给服务器的名册设置中不能包含“Approved”属性，但是应用类型为“subscribed”和“unsubscribed”的表示节来管理下面（7.4）提到的预先批准的信息作为替代。兼容性要求：元素中的“apprved”属性在本标准中是最新定义的。6.2.2.2Ask属性
元素中包含“订阅”值的“ask”属性用在各种包含“等待”状态的订阅子状态中，见7.1.2。服务器应该包含“ask”属性来告知客户端“等待”子状态。客户端在发送给服务器设置名册信息中不能包含“ask”属性，但是应用类型为“subscribed”和“unsubscribed”的表示节来管理下面（7.2.2）提到的预先批准的信息作为替代。6.2.2.3JID属性
元素中的“jid”属性指唯一标识名册条目的Jabber标识符（JID）。“jid”属性在任何时候客户端或服务器添加、更新、删除和返回名册条目都是必要的。6.2.2.4Name属性
元素中的‘name”属性特指与JID有关的，由用户决定（不是指联系人）。尽管“name”属性可能意味着用户是人，这对服务器是不透明的。然而，在各种扩展的背景下“name”属性可能被服务器用来进行匹配。
当客户端增加或更新名册条目时“name”属性是可选的。6.2.2.5Subscription属性
表示的订阅状态在元素的“subscript”属性中获取。与订阅相关的值是none：用户对联系人的表示没有订阅，而且联系人也没有订阅用户的表示；这是默认的值，因此订阅属性不会被包含，这种状态就认为是“none”：to：用户订阅了联系人的表示，但是联系人没有订阅用户的表示：from：联系人订阅了用户的表示，但是用户没有订阅联系人的表示：both：用户和联系人相互订阅了对方的表示（也称为“相互订阅”）。在名册结果中，客户端应忽略“subscription”属性中除“none”、“to”“from”和“both”以外的任何值。
在名册推送中，客户端应忽略“subscription”属性中除“none”、“to”、“from”和“both”以外的任何值。
在名册设置中，“subscription”属性可能会包含“remove”值，这表示将这个条目从名册中删除；在名册set中，服务器应忽略“remove”以外的任何值。“subscription”这个属性是可选的6.2.2.6组元素
元素表示客户端指定的联系人的分组或类别。一个元素可能包含不止一个元素，这意味着名册组不是独有的。尽管元素的XML特征数据可能意味着用户是人，但它对服务器是不透明的，然而，元素可能被服务器用来对各种XMPP扩展目标进行匹配。4
YD/T2936-2015
当客户端添加或更新名册条目时，元素是可选的。如果名册设置不包括元素，那么条目就认为没有分组。
6.2.3名册获取
“名册获取”是客户端向服务器请求返回名册：从语法上讲，它是一个从客户端发送给服务器的类型为“get”的IQ节，而且包含一个名字空间为“jabber:iqroster”的元素，这个元素不能包含任何子元素。
C:type-'get>

发送一个名册获取期望的结果是服务器返回一个名册结果。6.2.4名册结果
“名册结果”是服务器对“名册获取”的响应；从语法上来说它是一个服务器发给客户端的IQ节，它的类型为“result”名字空间为“jabber:iq：roster”。名册结果中的元素为每个联系人分配元素，因此可以包含多个元素。S:[email protected]/chambertype='result>

如果名册存在但是没有联系人，那么服务器应返回一个包含子元素的IQ-result，这个子元素中不包含子元素（如服务器不能返回一个空的类型为“error”的节）。S:[email protected]/chambertype-'result>

如果名册不存在，那么服务器应返回一个带有条件的节错误。S:[email protected]/chambertype='error>

6.2.5名册设置
“名册设置”是客户端向服务器请求修改（如创建、更新或删除）一个名册条目；从语法上讲它是一个从客户端发送给服务器的IQ节，这个IQ节类型为\set”，名字空间为jabber:iq:roster\，并包含子元素。
以下是名册设置的使用规则。
（1）元素应包含并只能包含一个元素。（2）服务器应忽略任何“subscription”属性中除“remove”以外的任何值。安全性注意事项：通常意义下，名册设置这种IQ节不包含“to”地址，导致从一个名册更新过的账户的通过认证的资源（全JID）会发送所有的名册设置信息。此外，IETFRFC6121要求服务器执行特殊情况来检查名册设置信息从而忽略“to”地址；但是本标准去掉了这种特殊情况，这意味着名册设置除了发送者的地址以外可能还包含了“to”地址。因此，处理名册设置的实体应确保通过发送名册设置来更新名册的实体是经过授权的：如果不是的话，就返回一个错误。C:

6.2.6名册推送
“名册推送”是服务器发送给客户端的关于最近创建、更新或删除名册条目的信息；从语法上讲它是一个从服务器发送给客户端的IQ节，类型为“set”，名字空间为“jabber:iq:roster”，并包含一个元素。
以下是名册推送信息的使用规则：a）名册推送中的元素应包含并只能包含一个元素：b）除非没有包含“from”属性，否则接收的客户端应忽略这个节（如隐含在用户的纯JID账户中）或者它的“from”属性匹配用户的纯JID。S:[email protected]/chamber'type='set'>

YD/T2936-2015
由于YD/T2935《扩展消息与表示协议（XMPP）核心协议》规定了IQ节的语法，每个接收到从服务器发出的名册推送信息的资源都应该返回一个类型为“result”或“error”的IQ节（然而，很多现有的客户端不会对名册推送做出回复）。C:type-'result'/>
C：type-'result'/>
安全性注意事项：通常意义上，名册推送不包括“from”地址，导致从所有账号的纯JID的名册推送信息都会被发送。但是，本标准批准除用户的服务器以外的实体均需维持名册信息，这意味着名册推送信息可能包含除了用户账户纯JID以外的“from”地址。因此，客户端应通过检查名册推送信息发送者的“from”地址来确保是授权的用户。如果客户端从未授权的实体收到一个名册推送信息，它不能处理这个名册推送的数据；另外这个客户端要返回一个的节错误或者完全不返回任何错误。
实现注意事项：客户端在处理名册推送时没有定义错误的情况：如果服务器收到一个“error”类型的IQ作为对名册推送的响应，则应该忽略这个错误。6.3登录时接收一个人的名册
连接到服务器并绑定一个资源之后，客户端应该在发送初始化表示信息之前请求名册（然而，由于可能不是所有的资源都想接收名册，如一个带宽受限的连接，客户端对于名册的请求是可选的）在一个连接的资源上发送一个初始化表示，则称为一个“可用的资源”。如果一个连接的资源或可用的资源请求名册，则称为一个“感兴趣的资源”。服务器应对所有感兴趣的资源发送名册推送信息。实现注意事项：表示请求订阅发给可用的资源，但与订阅状态改变有关的名册推送信息发送给感兴趣的资源。因此，如果希望接收到请求订阅和名册推送信息，它应既要发送初始化表示也要发送名册请求信息。
客户端向服务器请求名册：
C：type-'get>
/iq>
S:[email protected]/balconytype-'result's
7
YD/T2936-2015
subscription-\both>
Friends

subscription=\from/>
subscription=\both/>

如果服务器不能处理名册获取，它应返回一个节错误（例如，如果名册的名字空间不支持就返回，如果服务器在进行故障处理正在返回的名册，则返回）。6.4增加一个名册条目
6.4.1请求
任何时候，客户端可以在名册中增加一个条目。这通过发送一个包含新条目的名册设置来完成。C：type='set>
name-Nurse>
Servants

query>
6.4.2成功示例
如果服务器能够成功的处理新条目的名册设置（例如，如果没有发生错误），它应在用户的名册中创建这个条目并做如下处理。
服务器应向发送名册设置的已连接的资源返回一个类型为“result”的IQ节。S:[email protected]/balconytype-'result/>
服务器也应向用户所有感兴趣的资源发送一个包含新名册条目的名册推送信息，包括生成名册设置的资源。
小提示：此标准内容仅展示完整标准里的部分截取内容，若需要完整标准请到上方自行免费下载完整标准文档。