XMPP协议中文参考指南.docx
- 文档编号:11904498
- 上传时间:2023-04-08
- 格式:DOCX
- 页数:102
- 大小:72.92KB
XMPP协议中文参考指南.docx
《XMPP协议中文参考指南.docx》由会员分享,可在线阅读,更多相关《XMPP协议中文参考指南.docx(102页珍藏版)》请在冰豆网上搜索。
XMPP协议中文参考指南
XMPP协议中文参考指南
绪论
概览
XMPP是一个流化XML[XML]元素的协议,用于准实时的交换消息和出席信息。
XMPP的核心功能定义在ExtensibleMessagingandPresenceProtocol(XMPP):
Core[XMPP-CORE|XMPP文档列表/XMPP正式RFC标准/RFC3920].这些功能--主要是XML流,使用TLS和SASL,以及流的根元素之下的,,和子元素--为各种类型的准实时应用提供了一个构造基础,它可以被放在核心的顶层,使用特定XML名字空间[XML-NAMES]发送特定的应用数据.本文描述XMPP核心功能的扩展和应用,XMPP核心功能提供了RFC2779[IMP-REQS]定义的基本的即时消息和出席信息功能。
需求
为了达到本文的目的,基本的即时消息和出席信息应用的需求定义在[IMP-REQS],它是一个高阶的规定,一个用户必须完成以下用例:
∙和其他用户交换消息
∙和其他用户交换出席信息
∙管理和其他用户之间的订阅和被订阅
∙管理联系人列表中的条目(在XMPP中这被称为"roster")
∙屏蔽和特定的其他用户之间的通信(出或入)
这些功能领域的详细定义在[IMP-REQS]中,感兴趣的用户可以直接阅读原文关于需求方面的内容。
[IMP-REQS]也规定出席信息服务必须从即时消息服务中分离;例如,它必须可能用这个协议来提供一个出席信息服务,一个即时消息服务,或同时提供两者.尽管本文假定实现和部署希望提供统一的即时消息和出席信息服务,但没有要求一个服务必须同时提供出席信息服务和即时消息服务,并且协议也提供了把出席信息服务和即时消息服务分离成为独立服务的可能性.
注意:
虽然基于XMPP的即时消息和出席信息符合[IMP-REQS]的要求,但它不是特意为那个协议设计的,因为基础协议是在RFC2779成文之前通过Jabber开放源代码社区的一个开放的开发过程发展出来的.也请注意尽管在Jabber社区发展的协议中定义了许多其他方面的功能,但是这些协议不包含在本文之中,因为它们不是[IMP-REQS]所要求的.
术语
本文继承了[XMPP-CORE|XMPP文档列表/XMPP正式RFC标准/RFC3920]定义的术语.
大写关键字"MUST","MUSTNOT","REQUIRED","SHALL","SHALLNOT","SHOULD","SHOULDNOT","RECOMMENDED","MAY",和"OPTIONAL"在本文中的含义定义在BCP14,RFC2119\[TERMS\].
XML节的语法
符合'jabber:
client'和'jabber:
server'名字空间的XML节的基本语义和通用属性已经在[XMPP-CORE|XMPP文档列表/XMPP正式RFC标准/RFC3920]中定义了.无论如何,这些名字空间也定义了yixie其他的子元素,比如通用属性'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--一个消息可能是由一个递送或广播内容的自动化服务生成的(新闻,体育,市场信息,RSSfeeds,等等.).这个消息是不需要回复的,一个兼容客户端应该(SHOULD)在一个适当的和单独消息,聊天会话,或群聊会话不同的界面显示这个消息(例如,不给接收者提供回复能力).
∙normal--这个消息是一个在一对一会话或群聊会话之外的单独消息,并且它希望接收者能够回复.一个兼容客户端应该(SHOULD)在一个允许接收者回复的界面显示这个消息,但不需要会话历史.
一个IM应用应该(SHOULD)支持所有前述的消息类型;如果一个应用接收了一个没有'type'属性的消息或这个应用不理解'type'属性的值,它必须(MUST)认为这个消息是一个"normal"类型(如,"normal"是缺省的)."error"类型必须(MUST)仅仅在应答一个和从别的实体接收到的消息有关的错误时生成.
尽管'type'属性是可选的(OPTIONAL),处于礼貌原因对于消息的任何回复总是和原来的消息同一类型;此外,一些特殊的应用(例如,一个多用户聊天服务)可以(MAY)根据它们的判断强制特定消息类型的使用(例如,type='groupchat').
子元素
正如扩展名字空间extendednamespaces(第二章第四节)所述,一个消息节可以(MAY)包含任何适当名字空间的子元素.
和缺省名字空间声明一致,缺省消息节的名字空间是'jabber:
client'或'jabber:
server',定义了某几个允许的消息节的子元素.如果消息节的类型是"error",它必须(MUST)包含一个子元素;详细情况,见[XMPP-CORE|XMPP文档列表/XMPP正式RFC标准/RFC3920].否则,消息节可以(MAY)包含以下子元素的任何一种并且无需显式地声明名字空间:
1.
2.
3.
主题
元素包含了人类可读的XML字符数据指明这个消息的主题.元素不能(MUSTNOT)拥有任何属性,除了'xml:
lang'属性.元素可以(MAY)包含多个实例用于为同一主题提供备用版本,但是仅在每个实例的拥有的'xml:
lang'属性的值互不相同的时候才可以.元素不能(MUSTNOT)包含混合的内容(定义在\[XML\]第三章第二节第二小节).
主体
元素包含人类可读的XML字符数据表达消息的文本内容;这个子元素通常会有但是是可选的(OPTIONAL).
元素不能(MUSTNOT)拥有任何属性,除非是'xml:
lang'属性.
元素可以(MAY)包含多个实例用于为同一主体提供备用版本,但是仅在每个实例的拥有的'xml:
lang'属性的值互不相同的时候才可以.
元素不能(MUSTNOT)包含混合的内容(定义在\[XML\]第三章第二节第二小节).
线索
元素包含非人类可读的XML字符数据表达一个标识符用于跟踪两个实体之间的一个会话线索(有时相当于一个"即时消息会话").元素的值是由发送者生成的并且应该(SHOULD)在任何回复中拷贝回来.如果使用了它,它必须(MUST)在这个流的会话线索中是唯一的并且必须(MUST)和那个会话相一致(一个从同一个全JID但不同线索ID接收到消息的客户端必须(MUST)假定这个有问题的消息存在于已有的会话线索之外.元素的使用是可选的(OPTIONAL)并且不是用于标识独立的消息,而是标识会话.一个消息节不能(MUSTNOT)包含超过一个的元素.元素不能(MUSTNOT)拥有任何属性.属性的值必须(MUST)被实体处理成不透明的;不能从它得到任何语义学上的含义,并且只能对它做精确的比较.元素不能(MUSTNOT)包含混合内容(定义在[XML]第三章第二节第二小节).
出席信息语法
符合'jabber:
client'或'jabber:
server'名字空间的出席信息节用于表达一个实体当前的网络可用性(离线或在线,包括之后的各种亚状态和可选的用户名义的描述性文本),并且通知其他实体它的可用性.出席信息节也用于协商和管理对于其他实体的出席信息的订阅.
出席信息的类型
出席信息节的'type'属性是可选的(OPTIONAL).一个不拥有任何'type'属性的出席信息节用来通知服务器发送者已经在线并且可以进行通信了,'type'属性表示缺乏可用性,请求管理对其他实体的出席信息的订阅,请求其他实体的当前出席信息,或发生了和上次发出的出席信息节有关的错误.如果包含了它,'type'属性必须(MUST)拥有以下值之一:
∙unavailable--通知实体将不可通信.
∙subscribe--发送者希望订阅接收者的出席信息.
∙subscribed--发送者允许接收者接收他们的出席信息.
∙unsubscribe--发送者取消订阅另一个实体的出席信息.
∙unsubscribed--订阅者的请求被拒绝或以前的订阅被取消.
∙probe--对一个实体当前的出席信息的请求;只应(SHOULD)由服务器代替一个用户生成.
∙error--处理或递送之前发送的出席信息节的时候发生了错误.
关于出席信息语义学的详细信息和基于XMPP的即时消息和出席信息应用程序的订阅模式,参考交换出席信息ExchangingPresenceInformation(第五章)和管理订阅ManagingSubscriptions(第六章).
子元素
如扩展名字空间extendednamespaces(第二章第四节)所述,一个出席信息节可以(MAY)包含任何适当名字空间的子元素.
和缺省名字空间声明一致,缺省出席信息节的名字空间是'jabber:
client'或'jabber:
server',定义了某几个允许的出席信息节的子元素.如果出席信息节的类型是"error",它必须(MUST)包含一个子元素;详细情况,见[XMPP-CORE|XMPP文档列表/XMPP正式RFC标准/RFC3920].如果出席信息节不拥有'type'属性,它可以(MAY)包含以下任何子元素(注意子元素可以(MAY)在一个类型为"unavailable"或"subscribe"(出于历史原因)的出席信息中被发送):
1.
2.
3.
展示
可选的(OPTIONAL)元素包含非人类可读的XML字符数据表达一个特定的实体或资源的特定的可用性状态.一个出席信息节不能(MUSTNOT)包含多于一个元素.元素不能(MUSTNOT)拥有任何属性.如果提供了,这个XML字符数据值必须(MUST)是以下之一(额外的可用性类型可以通过出席信息的适当名字空间来定义):
∙away--实体或资源临时离开.
∙chat--实体或资源在聊天中是激活的.
∙dnd--实体或资源是忙(dnd="不要打扰").
∙xa--实体或资源是长时间的离开(xa="长时间离开").
如果没有提供元素,实体被假定是在线和可用的.
状态
可选的(OPTIONAL)元素包含XML字符数据表达一个可用性状态的自然语言描述.它通常用于联合show元素以提供可用性状态的详细描述(例如,"会议中").元素不能(MUSTNOT)拥有任何属性,除了'xml:
lang'属性.元素可以(MAY)包含多个实例但是每个实例的'xml:
lang'属性值必须各不相同.
优先权
可选的(OPTIONAL)元素包含非人类可读的XML字符数据指明资源的优先级别.这个值必须(MUST)是一个介于-128和+127之间的数字.一个出席信息小节不能(MUSTNOT)包含超过一个的元素.元素不能(MUSTNOT)拥有任何属性.如果没有优先权被提供,一个服务器应该(SHOULD)认为优先级是零.关于即时消息和出席信息系统中节路由的优先级的语义,参考处理XML节的服务器规则ServerRulesforHandlingXMLStanzas(第十一章).
IQ语法
IQ节提供一个结构化的请求-应答机制.这个机制的基本语义学(例如,'id'属性是必需的(REQUIRED))定义在[XMPP-CORE|XMPP文档列表/XMPP正式RFC标准/RFC3920],然而完成特定用例所需要的特定语义的所有案例定义在扩展名字空间extendednamespace(第二章第四节)之中(注意'jabber:
client'和'jabber:
server'名字空间没有定义除通用的子元素之外的任何IQ节子元素).本文定义了两个这样的名字空间,一个用于名册管理RosterManagement(第七章)而另一个用于屏蔽通信BlockingCommunication(第十章);无论如何,一个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"的错误条件的IQ节.
路由:
如果一个路由实体(通常是一个服务器)处理一个包含它不理解的子元素的节,它应该(SHOULD)原封不动地把它转给接收者而忽略相关的XML数据.
会话的建立
绝大部分基于XMPP的消息和出席信息应用是由一个客户端-服务器体系结构实现的,为了参加期望的即时消息和出席信息活动,需要客户端在服务器上建立一个会话.无论如何,在客户端能够建立一个即时消息和出席信息会话之前有很多前提必须(MUST)满足.它们是:
1.流验证--客户端在尝试建立一个会话或发送任何XML节之前必须(MUST)完成[XMPP-CORE|XMPP文档列表/XMPP正式RFC标准/RFC3920]中定义的流验证.
2.资源绑定--完成流验证之后,一个客户端必须(MUST)绑定一个资源到流上,使得客户端的地址符合格式,然后实体以[XMPP-CORE|XMPP文档列表/XMPP正式RFC标准/RFC3920]规定的术语来说就是一个已连接的资源"connectedresource".
如果一个服务器支持会话,在完成一个[XMPP-CORE|XMPP文档列表/XMPP正式RFC标准/RFC3920]定义的流验证之后它必须(MUST)在它向客户端声明的流特性中包含一个符合'urn:
ietf:
params:
xml:
ns:
xmpp-session'名字空间的元素:
服务器向客户端声明会话确定特性:
stream
xmlns='jabber:
client'
xmlns:
stream='http:
//etherx.jabber.org/streams'
id='c2s_345'
from=''
version='1.0'>
features>
ietf:
params:
xml:
ns:
xmpp-bind'/>
ietf:
params:
xml:
ns:
xmpp-session'/>
features>
收到需要会话确立的通知之后(并且是在完成资源绑定之后),客户端如果想使用即时消息和出席信息功能必须(MUST)建立一个会话;它向服务器发送一个符合'urn:
ietf:
params:
xml:
ns:
xmpp-session'名字空间的类型为"set"并包含空的子元素的IQ节以完成这一步骤:
步骤1:
客户端向服务器请求会话:
type='set'
id='sess_1'>
ietf:
params:
xml:
ns:
xmpp-session'/>
步骤2:
服务器通知客户端会话已经建立:
type='result'
id='sess_1'/>
建立会话之后,一个已连接的资源([XMPP-CORE|XMPP文档列表/XMPP正式RFC标准/RFC3920]术语)就被称为一个激活的资源"activeresource".
许多错误条件是可能的.例如,服务器可能遭遇一个内部条件阻碍了它建立会话,用户名或授权身份可能缺乏建立会话的许可,或同一个名字相关的这个资源ID已经有一个激活的资源.
如果服务器遭到一个内部条件阻碍了它建立会话,它必须(MUST)返回一个错误.
步骤2(替代):
服务器应答一个错误(内部服务器错误):
ietf:
params:
xml:
ns:
xmpp-session'/>
xmlns='urn:
ietf:
params:
xml:
ns:
xmpp-stanzas'/>
如果用户名或资源不被允许建立一个会话,服务器必须(MUST)返回一个错误(例如,被禁止).
步骤2(替代):
服务器应答错误(用户名或资源不被允许建立一个会话):
ietf:
params:
xml:
ns:
xmpp-session'/>
xmlns='urn:
ietf:
params:
xml:
ns:
xmpp-stanzas'/>
如果已经同一名字已经存在一个激活的资源,服务器必须(MUST)
(1)终止这个激活的资源并允许新请求的会话,或者
(2)不允许新申请的会话并继续激活的资源.服务器做哪一步取决于具体的实现,尽管建议的(RECOMMENDED)实现情景#1.在情景#1,服务器应该(SHOULD)发送一个流错误给激活的资源,终止用于这个激活的资源的XML流和相关的TCP连接,并返回一个类型为"result"的IQ节(表示成功)给新申请的会话.在情景#2,服务器应该(SHOULD)发送一个节错误给新申请的会话但是继续那个连接的XML流使得新申请的会话在发送另一个会话建立申请之前有机会协商出一个不冲突的资源ID.
步骤2(替代):
服务器通知现有的激活的资源资源冲突(情景#1):
error>
ietf:
params:
xml:
ns:
xmpp-streams'/>
error>
stream>
步骤2(替代):
服务器通知新申请的的会话资源冲突(情景#2):
ietf:
params:
xml:
ns:
xmpp-session'/>
ietf:
params:
xml:
ns:
xmpp-stanzas'/>
建立一个会话之后,客户端应该(SHOULD)按以下描述来发送初始化出席信息并请求它的名册,尽管这些动作是可选的(OPTIONAL).
注意:
在允许建立即时消息和出席信息会