XEP0079.docx
- 文档编号:7323257
- 上传时间:2023-01-22
- 格式:DOCX
- 页数:43
- 大小:40.78KB
XEP0079.docx
《XEP0079.docx》由会员分享,可在线阅读,更多相关《XEP0079.docx(43页珍藏版)》请在冰豆网上搜索。
XEP0079
XEP-0079
出自Jabber/XMPP中文翻译计划
本文的英文原文来自XEP-0079
XEP-0079:
高级消息处理
本文定义了一个XMPP协议扩展来实现实体请求,服务器执行的,高级XMPP
注意:
这里定义的协议是XMPP标准化基金会的一个草案标准.对本协议的执行是被鼓励的,也适于部署到生产系统,但是在它成为最终标准之前可能还会有一些变动.
文档信息
系列:
XEP
编号:
0079
发行者:
XMPP标准基金会
状态:
草案
类型:
标准跟踪
版本:
1.2
最后更新日期:
2005-11-30
批准机构:
XMPP理事会
依赖于:
XMPPCore,XEP-0030,XEP-0082
上文:
XEP-0023
下文:
无
简称:
amp
amp名字空间的XML方案:
//www.xmpp.org/schemas/amp.xsd> amp#errors名字空间的XML方案: //www.xmpp.org/schemas/amp-errors.xsd> feature名字空间的XML方案: //www.xmpp.org/schemas/amp-feature.xsd> 注册项: //www.xmpp.org/registrar/amp.html> Wiki页: //wiki.jabber.org/index.php/AdvancedMessageProcessing(XEP-0079)> 作者信息 MatthewMiller Email: linuxwolf@outer- JabberID: [xmpp: linuxwolf@outer-linuxwolf@outer-] PeterSaint-Andre Email: stpeter@jabber.org JabberID: [xmpp: stpeter@jabber.orgstpeter@jabber.org] 法律通告 XMPP扩展协议的版权(1999-2007)归XMPP标准化基金会(XSF)所有,并完全遵守XSF的知识产权策略 //www.xmpp.org/extensions/ipr-policy.shtml>.本文可以任意分发,仅受限于创作公用协议的第四条.( //creativecommons.org/licenses/by/2.5/>). 讨论地点 首选的讨论的地方是标准讨论邮件列表: //mail.jabber.org/mailman/listinfo/standards>. XMPP相关信息 XMPP是由XSF(XMPP标准化基金会)按互联网标准程序贡献的,和IETF的RFC2026兼容的规范,包括XMPP核心(RFC3920)和XMPPIM(RFC3921).在本文中定义的任何协议,都是在互联网标准程序之外开发的,是扩展XMPP,而不是改变、发展和修改XMPP本身. 一致性术语 本文中以下关键词的含义如RFC2119所述: "MUST","SHALL","REQUIRED";"MUSTNOT","SHALLNOT";"SHOULD","RECOMMENDED";"SHOULDNOT","NOTRECOMMENDED";"MAY","OPTIONAL". 目录 [隐藏] ∙1绪论 o1.1动机 o1.2概念 o1.3前提 ∙2处理流程 o2.1发送者-到-服务器 ▪2.1.1查询 ▪2.1.2指定语义 o2.2服务器处理 ▪2.2.1确认语义 ▪2.2.2决定缺省动作 ▪2.2.3处理规则 ▪2.2.4执行决定的动作 ▪2.2.5返回事件 ∙3条件和动作 o3.1规则条件指南 o3.2规则动作指南 o3.3定义的条件 ▪3.3.1递送 ▪3.3.2期满 ▪3.3.3匹配资源 o3.4定义的动作 ▪3.4.1警告 ▪3.4.2丢弃 ▪3.4.3错误 ▪3.4.4通知 o3.5条件/动作联合描述 ▪3.5.1递送规则 ▪3.5.2期满规则 ▪3.5.3资源匹配规则 ∙4正式描述 o4.1 o4.2 ∙5示例场景 o5.1可靠数据传输 o5.2时间敏感消息 o5.3瞬时消息 ∙6错误处理 o6.1条件 o6.2例子 ▪6.2.1不支持的动作 ▪6.2.2不支持的条件 ▪6.2.3服务不可用 ▪6.2.4未定义的条件 ∙7实施备注 ∙8流特性 ∙9安全性事项 ∙10IANA事项 ∙11XMPP注册事项 o11.1协议名字空间 o11.2流特性 o11.3著名的服务查询节点 o11.4注册项 ▪11.4.1规则条件注册项 ▪11.4.1.1过程 ▪11.4.1.2最低要求 ▪11.4.2规则动作注册项 ▪11.4.2.1过程 ▪11.4.2.2最低要求 ∙12XML规划 o12.1AMP o12.2错误 o12.3流特性 ∙13致谢 ∙14备注 ∙15修订历史 绪论 本文定义了一个协议让终端实体能够为一个XMPP 动机 ∙可靠的数据传输--发送者要求消息递送的通知(肯定的和/或否定的). ∙时间敏感的消息--消息仅在特定的日期和时间之前是合法的. ∙临时消息--消息不应该离线存储用于以后的递送. 概念 本协议主要由服务器或处理 每个规则受限于它所应用的范围,无论是全部路由,还是路由的每一跳.另外,因为本文定义了一套缺省的条件和动作,本协议有足够的可扩展性允许将来更多的定义. 本协议的名字空间是"http: //jabber.org/protocol/amp". 前提 为了本协议能够正常执行,包含的 处理流程 发送者-到-服务器 以下用例描述了发送者和服务器之间的交互.如下所示,这个交互实际上很简单: 1.发送者确定支持(E1) 2.发送者指定适当的规则并发送消息给服务器(E1,E2) 3.发送者等待任何协议定义的应答(UCE) ∙E1: 服务器不支持本协议(UCEunsuccessfully) ∙E2: 服务器不支持一个或多个定义的规则条件/动作(UCEunsuccessfully) 查询 希望使用AMP的发送实体应该(SHOULD)向预定的路径查询对本协议的支持(使用服务查询ServiceDiscovery\[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'> //jabber.org/protocol/amp'> action='drop' value='2004-01-01T00: 00: 00Z'/> 那些语义作为一组 缺省的,规则集仅用于"边缘服务器": 那些发送和接收实体所连接的服务器.(注意: 为了实现高级消息处理,这里"服务器"被定义为在XMPPCore范畴之内并且不包括任何内部组件(可能在服务器实现或安装中提供功能),如连接管理器.) 通过增加"per-hop"属性给 示例6.另一个伴随AMP语义的消息 from='northumberland@shakespeare.lit' id='richard2-4.1.247' to='kingrichard@royalty.england.lit'> //jabber.org/protocol/amp' per-hop='true'> action='drop' value='2004-01-01T00: 00: 00Z'/> 关于失败确认的例子,参考本文的[XMPP文档列表/XMPP扩展/XEP-0079#错误处理]章. 注意: 即使"per-hop"处理被请求,路由中的每一个服务器必须(MUST)忽略它无法应用的规则;可能被应用于每一跳的[XMPP文档列表/XMPP扩展/XEP-0079#已定义情景]概要. 服务器处理 服务器操作大多在此处执行.接收到一个包含AMP扩展的消息之后,服务器执行以下流程: 1.确认语义(E1,E2). 2.决定缺省行为. 3.处理规则直到条件吻合. ∙如果条件吻合,执行那个规则的动作 ∙如果没有条件吻合,执行那个消息的"缺省"行为 4.运行决定的动作(UCE)(E3). ∙E1: 已提供的语义(条件和/或动作)不被支持或不合法(UCE不成功的) ∙E2: 请求的语义不可接受(UCE不成功的) ∙E3: 下一个服务器不支持此协议(UCE不成功的) 确认语义 确认可以采取多种方式,但是最少服务器必须(MUST)确认它理解每一个规则条件和动作,并且条件内容是适当的.服务器也可以(MAY)拒绝接受特定的条件和动作组合,例如如果他们会导致违反安全策略的风险.如果语义不合法,不被支持,或不被接受,服务器必须(MUST)应答一个错误指出那些卷入的规则.服务器应当(SHOULD)在返回错误之前确认所有语义.关于和确认失败相关的错误处理语法和例子,参考本文的[XMPP文档列表/XMPP扩展/XEP-0079#错误处理]章. 决定缺省动作 这一步是原本服务器通常应该做的,除了那些不确定执行的动作.它决定如果没有语义附加到一个消息的时候将会发生什么(例如分发给另一个服务器或离线存储).在这一点,服务器也应该(SHOULD)计算任何定时或日历需求(如果可以应用的话). 处理规则 在这一步,服务器处理附加的语义.服务器必须(MUST)顺序处理规则,并且是按照它们在 执行决定的动作 一旦所有规则被处理或其他合理的理由,服务器在这一点执行决定的动作. 服务器不应该(SHOULDNOT)分发一个包含AMP语义的 返回事件 如果决定的动作包括返回一个事件(警告,错误,或通知)给发送者,服务器必须(MUST)发送一个 条件和动作 本文的前面章节中定义了关于AMP的一般行为.本章概述怎样设置 这里定义的动作和条件集可以在将来补充,只要在XMPPRegistrar中注册增加的动作和条件集.) 规则条件指南 一个 ∙定义一个管理条件集的名字空间 ∙定义条件: ∙ o定义'condition'属性值 ∙ o指定"每一跳"标记(如果应用了的话) ∙ o定义'value'属性值的语法/格式 ∙ o定义"value"如何与条件匹配 规则动作指南 一个 ∙定义一个管理动作集的名字空间 ∙定义动作: ∙ o定义每个'action'属性值 ∙ o定义 定义的条件 条件定义了一个典型的规则如何或何时被触发.条件属性的值决定 以下本文定义的条件应该(SHOULD)被所有实现支持. 在以下章节中,术语"content"和"contents"参考包含在 递送 "deliver"条件用于在以下五种情况下确保递送(或不递送): 1.通过XMPP直接给指定的地址或帐号 2.延迟递送离线储存(用于以后通过XMPP递送) 3.通过XMPP转发给替代的地址或帐号 4.通过一个网关非直接地发给一个替代的非XMPP系统地址或帐号 在条件吻合的时候在接收的这一刻处理器将对这些消息做些什么,如下: 表1: "deliver"值 值 描述 direct 消息将被立刻递送给指定的接收者或路由到下一跳. forward 消息将被转发给另一个XMPP地址或帐号. gateway 消息将通过网关发送给一个非XMPP系统的地址或帐号. none 消息将根本不被递送(例如,因为指定的接收者离线并且消息存储不被允许). stored 消息将被离线存储用于以后递送给指定的接收者. 这个条件可以(MAY)应用于服务器路由中的每一"跳". 期满 "expire-at"条件用于确保在一个绝对的时间点之前递送.很自然的,这不保证\[4\]从发送者的角度来看那个消息在那个时间之后不被发送,因为本文没有假定所有机器(例如,对于递送路由中的所有服务器)的时钟是同步的.无论如何,为了帮助确保这一条件正确地匹配,那些实现了本文的服务器(或那些承载了这类服务的机器)应该(SHOULD)使用网络时间协议(RFC1305\[5\])和已确定的授时保持同步.也要注意期满时间离当前时间越近则期满功能越不可靠(例如,一个消息指定的期满时间为两秒比起设置为两小时或两天,发送者将会更容易得到不可靠的递送). 'value'属性的内容定义了消息发送的准确时间之后的一些点;它的内容必须(MUST)是一个DateTime(定义在XMPPDateandTimeProfiles\[6\]),并且时区必须(MUST)是UTC. 如果消息将在指定的日期时间之后发送,则条件成立.要决定时间的比较,处理器首先要决定是否以及何时一个消息能被分发(例如不是离线存储).然后处理器记录这个时间,并把它和指定的时间比较.如果当前的时间正好在指定时间或在指定时间之后,则条件吻合. 这个条件可以(MAY)被应用于服务器路由中的每一"跳". 匹配资源 "match-resource"条件用于基于接收者的JID中的资源ID来限制递送. 这个条件的定义值如下: 表2: "match-resource"值 值 描述 例子 any 目标资源匹配任何值,高效地忽略任何指定的资源. "home/laptop"匹配"home","home/desktop"或"work/desktop" exact 目标资源精确匹配指定的资源. "home/laptop
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- XEP0079