XEP0079高级消息处理.docx
《XEP0079高级消息处理.docx》由会员分享，可在线阅读，更多相关《XEP0079高级消息处理.docx（56页珍藏版）》请在冰豆网上搜索。
XEP0079高级消息处理
XEP-0079
来自Jabber/XMPP中文翻译计划
跳转到：
导航,搜索
本文的英文原文来自XEP-0079
XEP-0079:
高级消息处理
摘要:
本文定义了一个XMPP协议扩展来实现实体请求,服务器执行的,高级XMPPmessage节处理,包括可靠数据传输,时间敏感递送,和临时消息的过期.
作者:
MatthewMiller,PeterSaint-Andre
版权:
©1999-2010XMPP标准化基金会（XSF）.参见法律通告.
状态:
草案
类型:
标准跟踪
版本:
1.2
最后更新日期:
2005-11-30
注意:
这里定义的协议是XMPP标准化基金会的一个草案标准.对本协议的执行是被鼓励的,也适于布署到生产系统,但是在它成为最终标准之前可能还会有一些变动.
目录
∙1绪论
1.1动机
1.2概念
1.3前提
∙2处理流程
2.1发送者-到-服务器
▪2.1.1发现
▪2.1.2指定语义
2.2服务器处理
▪2.2.1确认语义
▪2.2.2决定缺省动作
▪2.2.3处理规则
▪2.2.4执行决定的动作
▪2.2.5返回事件
∙3条件和动作
3.1规则条件指南
3.2规则动作指南
3.3定义的条件
▪3.3.1递送
▪3.3.2期满
▪3.3.3匹配资源
3.4定义的动作
▪3.4.1警告
▪3.4.2丢弃
▪3.4.3错误
▪3.4.4通知
3.5条件/动作联合描述
▪3.5.1递送规则
▪3.5.2期满规则
▪3.5.3资源匹配规则
∙4正式描述
4.1根元素
4.2元素
∙5示例场景
5.1可靠数据传输
5.2时间敏感消息
5.3瞬时消息
∙6错误处理
6.1条件
6.2例子
▪6.2.1不支持的动作
▪6.2.2不支持的条件
▪6.2.3不被接受
▪6.2.4服务不可用
▪6.2.5未定义的条件
∙7实现备注
∙8流特性
∙9安全事项
∙10IANA事项
∙11XMPP注册事项
11.1协议名字空间
11.2流特性
11.3知名服务发现节点
11.4注册项
▪11.4.1规则条件注册项
▪11.4.1.1过程
▪11.4.1.2最低要求
▪11.4.2规则动作注册项
▪11.4.2.1过程
▪11.4.2.2初始提交
∙12XML架构
12.1AMP
12.2错误
12.3流特性
∙13致谢
∙14附录
14.1附录A:
文档信息
14.2附录B:
作者信息
14.3附录C:
法律通告
14.4附录D:
和XMPP的关系
14.5附录E:
讨论地点
14.6附录F:
需求一致性
14.7附录G:
备注
14.8附录H:
修订历史
绪论
本文定义了一个协议让终端实体能够为一个XMPP节指定附加的递送语义.本协议通常用于客户端通知接收服务器如何递送一个特殊的节,例如提供一个失效期或资源匹配策略
动机
节的内置递送语义（定义于XMPPCore1,对即时消息应用来说,也定义于XMPPIM2）,对目前大多数的应用,是足够的.无论如何,更严格的递送语义在很多情况下还是需要的.本文讨论的是最常见的一些情况:
∙可靠的数据传输--发送者要求消息递送的通知（肯定的和/或否定的）.
∙时间敏感的消息--消息仅在特定的日期和时间之前是合法的.
∙临时消息--消息不应该离线存储用于以后的递送.
概念
本协议主要由服务器或处理的服务来处理.协议包括一系列的规则,每个规则有相应的条件和动作.在收到一个适当标记的消息之后,服务器解析它们所收到的规则,寻找吻合的条件.当一个条件吻合时,那个规则的相应动作被执行,同时消息处理停止.
每个规则受限于它所应用的范围,要么是全部路由,或者是路由的每一跳.另外,虽然本文定义了一套缺省的条件和动作,本协议有足够的可扩展性允许将来更多的定义.
本协议的名字空间是"http:
//jabber.org/protocol/amp".
前提
为了本协议能够正常执行,包含的节必须（MUST）拥有一个'id'属性并且'id'属性的值不能（MUSTNOT）是一个空的字符串.服务器必须（MUST）在任何给发送者的应答中包含这个'id'属性值;这使服务器和客户端能把初始的请求正确关联到接下来的任何警报,错误,或通知中.
处理流程
发送者-到-服务器
以下用例描述了发送者和服务器之间的交互.如下所示,这个交互实际上很简单:
1.发送者确定支持（E1）
2.发送者指定适当的规则并发送消息给服务器（E1,E2）
3.发送者等待任何协议定义的应答（UCE）
∙E1:
服务器不支持本协议（UCEunsuccessfully）
∙E2:
服务器不支持一个或多个定义的规则条件/动作（UCEunsuccessfully）
发现
希望使用AMP的发送实体应该（SHOULD）向预定的路径查询对本协议的支持（使用服务发现3）.一般来说,这包括发送disco#info查询给发送者本身所在的服务器以及接收者的服务器.这些查询的结果可以（MAY）被缓存24小时,除非有其他原因过期.
如果一个服务器支持高级消息处理,它必须（MUST）在返回给请求实体的服务查询信息结果中包含一个服务特性"http:
//jabber.org/protocol/amp"来报告.
例子1.初始化服务发现信息请求
to='shakespeare.lit'
type='get'>
//jabber.org/protocol/disco#info'/>
例子2.服务发现信息应答
to='northumberland@shakespeare.lit/westminster'
type='result'>
//jabber.org/protocol/disco#info'>
...
//jabber.org/protocol/amp'/>
...
一个服务器也应该（SHOULD）维护一个名为"http:
//jabber.org/protocol/amp"的服务查询节点,在那里声明它支持的单个的动作和条件.如果一个实体需要决定是否服务器支持单个的动作和条件,它应该（SHOULD）发送一个服务发现信息请求给那个节点;然后服务器必须（MUST）要么返回支持的动作和条件列表要么返回一个错误例如.（注意:
如果这个服务器节点不为此查询节点提供信息,请求实体必须（MUST）认为每一个动作集或条件集的所有动作和条件都被支持.）
每个支持的动作将被报告成一个特性,使用以下格式:
http:
//jabber.org/protocol/amp?
action={action}
每个支持的条件将被报告成一个特性,使用以下格式:
http:
//jabber.org/protocol/amp?
condition={condition}
以下展示的请求-应答流的例子是关于独立的动作和条件的信息（注意'node'属性中包含了什么）.
例子3.对于独立动作和条件的信息的请求
to='shakespeare.lit'
type='get'>
//jabber.org/protocol/disco#info'
node='http:
//jabber.org/protocol/amp'/>
例子4.对于独立动作和条件的应答
to='northumberland@shakespeare.lit/westminster'
type='result'>
//jabber.org/protocol/disco#info'
node='http:
//jabber.org/protocol/amp'>
...
//jabber.org/protocol/amp'/>
//jabber.org/protocol/amp?
action=drop'/>
//jabber.org/protocol/amp?
action=error'/>
//jabber.org/protocol/amp?
action=notify'/>
//jabber.org/protocol/amp?
condition=deliver'/>
//jabber.org/protocol/amp?
condition=expire-at'/>
//jabber.org/protocol/amp?
condition=match-resource'/>
...
指定语义
一旦支持被确定了,发送者就可以附加期望的递送语义给消息:
例子5.一个伴随AMP语义的消息
from='northumberland@shakespeare.lit'
id='richard2-4.1.247'
to='kingrichard@royalty.england.lit'>
Mylord,dispatch;reado'erthesearticles.
//jabber.org/protocol/amp'>
action='drop'
value='2004-01-01T00:
00:
00Z'/>
那些语义作为一组元素定义在根元素中.每个声明一个触发条件和触发后执行的动作.
缺省的,规则集仅用于"边缘服务器":
那些发送和接收实体所连接的服务器.（注意:
为了实现高级消息处理,这里"服务器"被定义为在XMPPCore范畴之内并且不包括任何内部组件（可能在服务器实现或安装中提供功能）,如连接管理器.）
通过增加"per-hop"属性给元素,规则集可以（MAY）应用于从发送实体到接收实体的路由中的服务器-服务器的每一"跳".这个属性的值要么是"true"（应用规则于每一跳）要么是"false"（保持缺省行为,也就是,规则仅应用于边缘服务器）.
例子6.另一个伴随AMP语义的消息
from='northumberland@shakespeare.lit'
id='richard2-4.1.247'
to='kingrichard@royalty.england.lit'>
Mylord,dispatch;reado'erthesearticles.
//jabber.org/protocol/amp'
per-hop='true'>
action='drop'
value='2004-01-01T00:
00:
00Z'/>
关于失败确认的例子,参考本文的错误处理章.
注意:
即使"per-hop"处理被请求,路由中的每一个服务器必须（MUST）忽略它无法应用的规则;定义的条件说明了是否它们能被应用于每一跳.
服务器处理
服务器操作大多在此处执行.接收到一个包含AMP扩展的消息之后,服务器执行以下流程:
1.确认语义（E1,E2）.
2.决定缺省行为.
3.处理规则直到条件吻合.
∙如果条件吻合,执行那个规则的动作
∙如果没有条件吻合,执行那个消息的"缺省"行为
4.运行决定的动作（UCE）（E3）.
∙E1:
已提供的语义（条件和/或动作）不被支持或不合法（UCE不成功的）
∙E2:
请求的语义不可接受（UCE不成功的）
∙E3:
下一个服务器不支持此协议（UCE不成功的）
确认语义
确认可以采取多种方式,但是最少服务器必须（MUST）确认它理解每一个规则条件和动作,并且条件内容是适当的.服务器也可以（MAY）拒绝接受特定的条件和动作组合,例如如果他们会导致违反安全策略的风险.如果语义不合法,不被支持,或不被接受,服务器必须（MUST）应答一个错误指出那些卷入的规则.服务器应当（SHOULD）在返回错误之前确认所有语义.关于和确认失败相关的错误处理语法和例子,参考本文的错误处理章.
决定缺省动作
这一步是原本服务器通常应该做的,除了那些不确定执行的动作.它决定如果没有语义附加到一个消息的时候将会发生什么（例如分发给另一个服务器或离线存储）.在这一点,服务器也应该（SHOULD）计算任何定时或日历需求（如果可以应用的话）.
处理规则
在这一步,服务器处理附加的语义.服务器必须（MUST）顺序处理规则,并且是按照它们在元素中出现的顺序.一旦一个规则的条件吻合,处理结束于那一个动作并超越前面定义的缺省动作（除非这个动作允许继续处理）.
执行决定的动作
一旦所有规则被处理或其他合理的理由,服务器在这一点执行决定的动作.
服务器不应该（SHOULDNOT）分发一个包含AMP语义的节给另一个服务器,除非它知道下一个服务器支持AMP（这应该（SHOULD）通过服务发现协议来查询并可以（MAY）缓存以防止递送延迟）.如果下一个服务器不支持AMP,当前服务器应答给原始发送者一个错误条件.否则流程再次从那个消息已分发到其中的服务器开始.
返回事件
如果决定的动作包括返回一个事件（警告,错误,或通知）给发送者,服务器必须（MUST）发送一个节给发送者,包含那个吻合的规则.这个节必须（MUST）包含初始的'id'属性值并且不应该（SHOULDNOT）包含开始发送者发送的非-AMP的内容（例如,
子元素）.
条件和动作
本文的前面章节中定义了关于AMP的一般行为.本章概述怎样设置动作和条件集.它也提供定义的动作和条件集;这些动作和条件集应该（SHOULD）被任何AMP的实现所支持,但是对任何动作或条件集的支持不是必需的.（注意:
这里定义的动作和条件集可以在将来补充,只要在XMPPRegistrar中注册新增的动作和条件集.）
规则条件指南
一个条件必须（MUST）提供以下信息:
∙定义一个管理条件集的名字空间
∙定义条件:
∙
定义'condition'属性值
∙
指定"per-hop"标记（如果应用了的话）
∙
定义'value'属性值的语法/格式
∙
定义"value"如何与条件匹配
规则动作指南
一个动作的定义必须（MUST）提供以下信息:
∙定义一个管理动作集的名字空间
∙定义动作:
∙
定义每个'action'属性值
∙
定义被触发之后期望的行为
定义的条件
条件定义了一个典型的规则如何或何时被触发.条件属性的值决定内容的含义.
以下本文定义的条件应该（SHOULD）被所有实现支持.
在以下章节中,术语"content"和"contents"参考包含在元素中的XML字符数据.
递送
"deliver"条件用于在以下五种情况下确保递送（或不递送）:
1.通过XMPP直接给指定的地址或帐号
2.延迟递送离线储存（用于以后通过XMPP递送）
3.通过XMPP转发给替代的地址或帐号
4.通过一个网关非直接地发给一个替代的非XMPP系统地址或帐号
在条件吻合的时候在接收的这一刻处理器将对这些消息做些什么,如下:
表1:
"deliver"值
值
描述
direct
消息将被立刻递送给指定的接收者或路由到下一跳.
forward
消息将被转发给另一个XMPP地址或帐号.
gateway
消息将通过网关发送给一个非XMPP系统的地址或帐号.
none
消息将根本不被递送（例如,因为指定的接收者离线并且消息存储不被允许）.
stored
消息将被离线存储用于以后递送给指定的接收者.
这个条件可以（MAY）应用于服务器路由中的每一"跳".
期满
"expire-at"条件用于确保在一个绝对的时间点之前递送.很自然的,这不保证4从发送者的角度来看那个消息在那个时间之后不被发送,因为本文没有假定所有机器（例如,对于递送路由中的所有服务器）的时钟是同步的.无论如何,为了帮助确保这一条件正确地匹配,那些实现了本文的服务器（或那些承载了这类服务的机器）应该（SHOULD）使用网络时间协议（RFC13055）和已确定的授时保持同步.也要注意期满时间离当前时间越近则期满功能越不可靠（例如,一个消息指定的期满时间为两秒比起设置为两小时或两天,发送者将会更容易得到不可靠的递送）.
'value'属性的内容定义了消息发送的准确时间之后的一些点;它的内容必须（MUST）是一个DateTime（定义在XMPPDateandTimeProfiles6）,并且时区必须（MUST）是UTC.
如果消息将在指定的日期时间之后发送,则条件成立.要决定时间的比较,处理器首先要决定是否以及何时一个消息能被分发（例如不是离线存储）.然后处理器记录这个时间,并把它和指定的时间比较.如果当前的时间正好在指定时间或在指定时间之后,则条件吻合.
这个条件可以（MAY）被应用于服务器路由中的每一"跳".
匹配资源
"match-resource"条件用于基于接收者的JID中的资源ID来限制递送.
这个条件的定义值如下:
表2:
"match-resource"值
值
描述
例子
any
目标资源匹配任何值,高效地忽略任何指定的资源.
"home/laptop"匹配"home","home/desktop"或"work/desktop"
exact
目标资源精确匹配指定的资源.
"home/laptop"只匹配"home/laptop"而不是"home/desktop"或"work/desktop"
other
目标资源匹配任何除指定资源之外的值.
"home/laptop"匹配"work/desktop","home"或"home/desktop",但不包括"home/laptop"
按照上述规则,如果实际的目标JID的资源匹配指定的JID,则条件成立.例如,如果一个消息指定给"romeo@伴随"exact"的"match-resource"条件,如果这个消息只能立刻被发送给"romeo@则条件吻合.
为了达到这个条件的目的,一个没有资源的特定JID有以下行为:
∙如果值为"exact",仅当服务器将发送给一个没有资源ID的目标JID时,条件成立（例如,一个多用户聊天7房间或离线存储）.
∙如果值为"other",仅当服务器将不递送给没有资源ID的目标JID时,条件成立.
这个条件不能（MUSTNOT）被应用于服务器路由的每一"跳",只能用于边缘服务器.如果一个元素包含了这个条件并且指明它将被每一跳处理,这个将被忽略.
注意:
从设计上说,这个协议不包含局部资源匹配的支持（它将导致,例如,资源ID"home/laptop"和"homeboy"都匹配"home"）.
定义的动作
动作定义了当一个特定的规则被触发时将发生什么.动作属性的值决定如果一个规则的条件被触发之后的行为.
以下动作由本文定义.
警告
"alert"动作触发一个应答节给发送实体.这个节必须（MUST）包含元素,它本身包含触发这个动作的.在所有其他的关系中Inallotherrespects,这个动作表现为"drop".
例子7.警告应答
to='bernardo@hamlet.lit/elsinore'
id='chatty2'>
//jabber.org/protocol/amp'
status='alert'
from='francisco@hamlet.lit'
to='bernardo@hamlet.lit/elsinore'>
丢弃
"drop"动作安静地从任何更多递送尝试中丢弃消息并确保它不会被离线存储.drop不能（MUSTNOT）导致任何其他应答.
错误
"error"动作触发一个类型为"error"的应答节给发送实体.这个节的子元素必须（MUST）包含一个//jabber.org/protocol/amp#errors'/>错误条件,它本身包含触发这个动作的规则.
例子8.错误应答
升级会员 