本文的英文原文来自XEP-0079
XEP-0079: 高级消息处理
摘要: 本文定义了一个XMPP协议扩展来实现实体请求,服务器执行的,高级XMPP message 节处理, 包括可靠数据传输, 时间敏感递送, 和临时消息的过期.
作者: Matthew Miller, Peter Saint-Andre
版权: © 1999 - 2010 XMPP标准化基金会(XSF). 参见法律通告.
状态: 草案
类型: 标准跟踪
版本: 1.2
最后更新日期: 2005-11-30
注意: 这里定义的协议是XMPP标准化基金会的一个草案标准.对本协议的执行是被鼓励的,也适于布署到生产系统,但是在它成为最终标准之前可能还会有一些变动.
| 本文的英文原文来自XEP-0084 XEP-0084: 用户头像 摘要: 本文定义了一个XMPP协议扩展，用于交换用户头像,一个小的和自然人用户相关的图像或图标. 该协议定义了头像元数据和图像数据本身的承载格式. 承载格式典型地使用定义于XEP-0163的 XMPP发布-订阅个人事件脚本 协议来传输 作者: Peter Saint-Andre, Peter Millard, Thomas Muldowney, Julian Missig 版权: © 1999 - 2010 XMPP标准化基金会(XSF). 参见法律通告. 状态: 草案 类型: 标准跟踪 版本: 1.1 最后更新日期: 2008-11-05 注意: 这里定义的协议是XMPP标准化基金会的一个草案标准.对本协议的执行是被鼓励的,也适于布署到生产系统,但是在它成为最终标准之前可能还会有一些变动.
绪论很多通讯应用允许那个应用的用户拥有一个相关的小图片或图标. 通常, 这样一个 "avatar" 不一定是一个用户的真正长相的图片, 而可能是一个用户期望的自己的图像 (经常很怪诞) 或该用户暂时的状态 (例如心情或活动). 本文定义一个方法来把头像合并到目前的 Jabber/XMPP 系统，即把该功能架在 XMPP发布-订阅 1 扩展 ("pubsub")之上, 特别是 个人事件协议 2 子集 ("PEP"), 它被定义用于符合 RFC 3921 3的 XMPP 即时消息和出席信息系统的场景. 本协议在这里定义使用两种 pubsub 节点(nodes): 一个 node 用于元数据 "metadata"，关于头像状态的 (称为 元数据节点 "metadata node") ；另一个是用于头像数据本身 (称为 数据节点 "data node"). 这个从数据中分离出来的元数据 metadata 节省了带宽，并且使发布者和订阅者能够缓存头像数据. (例如, 一个用户可能在两个或三个头像之间切换, 这种情况下用户的联系人们可以显示这些图片的一个本地缓存版本而不用每次检索或接收完整的图片.) 这个协议也允许头像数据存储在一个可通过HTTP (见 RFC 2616 4) 访问的 URL 上. 5 如果一个 pubsub-aware 数据仓库不可用，作为一个回退机制这是有帮助的. 它也使头像图片能被托管在公共的网站上 (例如, 一个面向终端用户的社区网站) 并从那个网站检索到而不是直接由发布的客户端以任何方式来处理. 最后, 本协议也使 XMPP 应用能选择性地和托管了用户头像的第三方服务(例如, 在线游戏系统和虚拟世界)集成. 一旦 XMPP 发布-订阅 的 PEP子集被足够广泛地实现和布署，本协议准备将来取代 基于IQ的头像 6 和 基于vCard的头像 7. 需求本文涉及以下的头像发布的用例:
本文涉及以下头像订阅的用例:
基本处理流程发布和更新用户头像的流程如下:
这个处理流程在随后的章节描述得更加完整. 注意: 在发布头像数据和元数据之前, 用户必须 MUST 根据定义于 XEP-0163 的流程确定是否他或她的服务器支持pubsub的PEP子集，因为这个支持简化了头像发布. 以下例子假定PEP服务可用. 用户发布数据在更新头像元数据节点之前, 发布者必须 MUST m确保头像数据在数据节点或URL是可用的. 当发布头像数据到数据节点时, 发布者必须 MUST 确保 pubsub ItemID 是该"image/png" 格式数据的 SHA-1 哈希值 (这被订阅者用于决定是否可以使用本地缓存副本来显示). 以下例子展示发布头像数据到数据节点时发送的 XML 结构. 例子 1. 发布头像数据到数据节点 例子 2. Pubsub服务应答成功 如果头像将通过 HTTP 而不是 pubsub 数据节点可用, 发布者必须 MUST 要么检查这个 HTTP URL 是否存在头像数据，要么通过标准的 HTTP 方法发布它 (这些方法超出了本协议的范围; 反考 RFC 2616). 用户发布元数据通知任何时候发布者希望修改当前头像, 它必须 MUST 更新元数据节点. 以下例子显示的指定可用头像数据的元数据，仅针对一个格式 ("image/png") 并且只可在数据节点访问. 例子 3. 发布头像元数据 以下例子显示的指定可用头像数据的元数据，对一个 HTTP URL 可用. 例子 4. 发布头像元数据 订阅者接收元数据通知接着用户的虚拟 virtual pubsub 服务将发送元数据通知给那些订阅了该用户的元数据节点的实体或那些声明拥有接收头像元数据能力的联系人(通过在 实体能力 8 中包含一个"urn:xmpp:avatar:metadata+notify"特性). 例子 5. 订阅者接收头像元数据通知 如上所示, 取决于节点配置, 这个条目可以包含关于该发布资源的 扩展的节地址 9 信息(详见 XEP-0060 ). 订阅者获取数据在接收到该通知后, 每个订阅者应该决定是否有一个该头像的本地缓存副本(它可以通过ItemID搜索一个图像标识符). 如果该订阅者已经有一个该头像的本地缓存副本, 它不能(MUST NOT)获取该图像数据. 如果该订阅者没有该头像图片的本地缓存副本, 它应该获取该数据. 它可以发送一个pubsub的 获取条目 请求给该数据节点, 指定适当的ItemID. 例子 6. 订阅者通过ItemID请求最后的条目 运行在该用户的服务器上的PEP服务接着应该返回头像数据. 例子 7. PEP服务返回头像数据 如果被发送给元数据节点的<info/>元素拥有一个'url'属性, 该头像数据位于一个URL. 所以, 为了获取那一内容类型的头像图片数据, 该请求实体必须发送一个HTTP请求给指定的URL. 干这事的方法超出了本协议的范围(见 RFC 2616 ). 发布者禁止头像发布为了临时禁止头像发布, 该用户发布一个空的<metadata/>元素给该元数据节点. 例子 8. 临时禁止头像发布 照旧, 该元数据的订阅者将接着收到该通知. 例子 9. 订阅者获取头像元数据通知 注意: 在本协议的一个早期版本中, 用户通过发送包含一个<stop/>子元素的<metadata/>元素来表明它想禁止发布. 为了保持和其他PEP载荷格式的一致性, 对<stop/>元素的支持被废弃了. 协议语法pubsub的PEP子集要求在命名空间和节点之间将存在一对一的关系. 因为在这里定义的协议规定了两种节点的使用(一个用于头像数据一个用于头像元数据), 我们定义了两个命名空间, 每个都有一个相应的根元素:
更多定义如下. Data元素<data/>元素被用于通讯头像数据本身, 并只用于"image/png"内容类型(支持这个是必需的). XML字符数据必须展示内容类型为"image/png"的头像的图片, 遵循RFC 464810的第4章做Base64编码. (注意: Line feeds不应该(SHOULD NOT)被添加但是应该被接受.) <data/>元素不能(MUST NOT)拥有任何属性. 对<data/>元素的支持是必需的. Metadata元素<metadata/>元素被用于通讯关于该头像的信息. <metadata/>元素有两个允许的子元素:
更多定义如下. 另外, <metadata/>元素可以是空的(即, 不包含子元素); 这个格式被用于禁止头像发布. Info元素 <info/>子元素被用于通讯头像元数据. 对<info/>元素的支持是必需的. <info/>子元素必须是空的. <info/>元素的已定义属性见下表. 表1: Info Attributes
<metadata/>根元素可以包含多个<info/>元素. 每个<info/>元素必须为相同的头像图片指定元数据但是要以替代的内容类型(例如, "image/png", "image/gif", 和 "image/jpeg"), 并且格式之一必须是"image/png"以确保互操作性. 'type'属性的值必须是一个在IANA注册了的内容类型"image"或"video". 12 对"image/png"内容类型的支持是必需的. 对"image/gif"和"image/jpeg"内容类型的支持是推荐的. 岁任何其他内容类型的支持是可选的. Pointer元素 <pointer/>子元素被用于指向一个未通过pubsub或HTTP发布的头像, 但是相反由类似在线游戏系统或虚拟世界的第三方服务提供. 如果发布的应用有相关的信息,<pointer/>元素可以拥有以下属性:
<pointer/>元素的内容必须是一个正确使用命名空间的子元素以指定如何从第三方服务获取该头像的信息. 任何子元素的结构超出了本文的范围. 即使包含了<pointer>元素, 至少必须有一个<info/>元素的实例发生在它之前，这样不支持<pointer/>元素的实现能显示该头像的"后备"格式(最低限度, "image/png"). 对<pointer/>元素的支持是可选的. 另外的例子带多内容类型的Metadata以下例子展示指定头像数据的元数据可用的多种格式("image/png", "image/gif", 和 "image/mng"), 这里"image/png"内容类型只可用在数据节点而其他内容类型可用于 HTTP URLs. 例子 10. 发布头像元数据(多格式) 在前述的例子中, 以"image/png"内容类型封装的图片同时可用于一个pubsub数据节点和一个HTTP URL; 所以它被包含了两次(第二次带了一个'url'属性). 带Pointer的Metadata以下例子展示元数据指定在数据节点可用的"image/png"头像数据，同时也带有一个指针指向外部服务. 例子 11. 发布头像元数据(带指针) 服务查询查询头像可用性pubsub "auto-subscribe" 和 "filtered-notifications" 特性允许一个联系人自动订阅一个用户的头像. 无论如何, 一个联系人也能显式地决定是否另一个用户使用本协议发布头像，通过发送一个服务查询 13 条目 ("disco#items") 请求给该用户的春JID <localpart@domain.tld>. 例子 12. 查询条目请求 如果该用户发布头像数据到一个PEP节点, 结果必须包含适当的条目. 例子 13. 查询条目结果 该联系人接着可以根据XEP-0060中定义的协议订阅该元数据节点. 无论如何, 该联系人不应该(SHOULD NOT)订阅该数据节点(反之, 它应该简单地在需要的时候从那个节点获取条目, 如上所述). 实现备注多资源如果一个用户同一时间有多个资源, 每个资源可以发布一个不同的头像. PEP服务应该包含上述的正在发布的资源的"replyto"地址，这样易于区分这个头像和前一个资源的头像. 头像同步当一个用户以一个新的资源登陆并且之前发布了一个头像, 它的客户端应该获取它最近发布的头像, 要么通过自动发送带有合适的实体可用性信息的出席信息(见 XEP-0115)要么使用XEP-0060所述的"retrieve-items"方法. 图片处理决定获取哪个头像格式(例如, "image/gif"而不是"image/png")和决定获取的适当方法(例如, HTTP而不是pubsub)是接收的应用的责任. 接收的应用显示一个图片的时候不应该(SHOULD NOT)拉伸它. 如果一个头像对一个联系人不可用, 接收应用可以显示该联系人的相片, 例如, 在联系人的vCard中提供的(见vcard-temp 14) 或其他个人信息. 安全事项关于和基础的传输协议相关的安全事项见XEP-0060和XEP-0163. 有可能SHA-1哈希机制的输出会导致冲突; 无论如何, 使用SHA-1生成头像数据的哈希不是安全的关键. IANA事项本文使用了IANA注册的内容类型, 但是不要求和互联网编号分配授权机构(IANA) 15交互. XMPP注册处事项协议命名空间XMPP注册处 16 已经把"urn:xmpp:avatar:data"和"urn:xmpp:avatar:metadata"包含在它的协议命名空间的注册项中(见 <http://xmpp.org/registrar/namespaces.html>). XML SchemaData命名空间Metadata命名空间作者备注Peter Millard, 本协议从版本0.1到版本0.7的作者, 去世于 April 26, 2006. 剩下的作者们感谢他在用户头像方面的工作. 附录附录A:文档信息系列：XEP 序号：0084 发布者：XMPP标准基金会 状态：草案 类型：标准跟踪 版本：1.1 最后更新：2008-11-05 批准机构：XMPP理事会 依赖标准：XMPP Core, XEP-0030, XEP-0060, XEP-0163 替代标准：XEP-0008, XEP-0153 被替代标准：无 缩略名：avatar data命名空间的XML Schema: <http://www.xmpp.org/schemas/avatar-data.xsd> metadata命名空间的XML Schema: <http://www.xmpp.org/schemas/avatar-metadata.xsd> 原文控制： HTML 附录B:作者信息Peter Saint-Andre Email: stpeter@jabber.org JabberID: stpeter@jabber.org URI: https://stpeter.im/ Peter Millard 见 作者备注 Thomas Muldowney Email: temas@jabber.org JabberID: temas@jabber.org Julian Missig Email: julian@jabber.org JabberID: julian@jabber.org 附录C:法律通告版权 XMPP扩展协议的版权(1999-2008)归XMPP标准化基金会(XSF)所有. 权限 特此授权,费用全免,对任何获得本协议副本的人,对使用本协议没有限制,包括不限制在软件程序中实现本协议,不限制在网络服务中布署本协议,不限制拷贝,修改,合并,发行,翻译,分发,转授,或销售本协议的副本,被允许使用本协议做了以上工作的人士,应接受前述的版权声明和本许可通知并且必须包含在所有的副本或实质性部分的规格中.除非单独的许可，被重新分发的修改工作，不得含有关于作者，标题，编号，或出版者的规格的误导性资料，并不得宣称修改工作是由本文的作者，作者所属的任何组织或项目，或XMPP标准基金会签注。 免责声明' ## 特别注意：本协议是提供的“原样”的基础，没有担保或任何形式的条件，明示或暗示，包括，但不限于任何担保或关于名称，非侵权性，适销性或适合作某一特定目的的条件. ## 责任限制 在任何情况下以及没有任何法律规定时，不论是侵权行为（包括疏忽），合同或其它方面，除非根据适用法律的要求（如蓄意和有严重疏忽行为）或以书面形式同意，XMPP标准基金会或任何作者不对本协议所造成的损失承担责任，包括任何直接，间接，特殊，偶发，或任何从本协议出，入，连接的字符产生的或实现，布署或其他对本协议的使用导致的相应的损害赔偿（包括但不限于善意的损失，停止作业，电脑失灵或故障，或任何和所有其他商业损害或损失） ，即使XMPP标准基金会或作者已被告知此类损害的可能性。 知识产权的一致性 XMPP扩展协议完全遵守XSF的知识产权策略(可在<http://www.xmpp.org/extensions/ipr-policy.shtml>找到副本或写信给XMPP标准基金会, 1899 Wynkoop Street, Suite 600, Denver, CO 80202 USA). 附录D:和XMPP的关系可扩展的消息和出席信息协议 (XMPP) 定义于 XMPP Core (RFC 3920) 和 XMPP IM (RFC 3921) 规范里，由 XMPP标准基金会贡献到由依据RFC 2026成立的互联网工程人物组管理的互联网标准流程 Internet Standards Process. 本文定义的任何协议已在互联网标准流程之外开发，并且被理解为 XMPP 的扩展而不是一个XMPP本身的演化, 开发, 或修改. 附录E:讨论地点主要的XMPP扩展协议讨论地点是 <standards@xmpp.org> 讨论列表. 在 xmpp.org 的其它讨论列表中的讨论可能也有合适的; 所有的列表见 <http://xmpp.org/about/discuss.shtml> . 勘误表可以发送邮件到 <editor@xmpp.org>. 附录F:需求一致性以下用于本文的需求关键字的解释见于 RFC 2119: "MUST", "SHALL", "REQUIRED"; "MUST NOT", "SHALL NOT"; "SHOULD", "RECOMMENDED"; "SHOULD NOT", "NOT RECOMMENDED"; "MAY", "OPTIONAL".
附录G:备注1. XEP-0060: 发布-订阅 <http://xmpp.org/extensions/xep-0060.html>. 2. XEP-0163: 个人事件协议 <http://xmpp.org/extensions/xep-0163.html>. 3. RFC 3921: Extensible Messaging and Presence Protocol (XMPP): Instant Messaging and Presence <http://tools.ietf.org/html/rfc3921>. 4. RFC 2616: 超文本传输协议 -- HTTP/1.1 <http://tools.ietf.org/html/rfc2616>. 5. "可通过HTTP访问"意味着该数据在一个 http: 或 https: 的URI上是可用的. 6. XEP-0008: 基于IQ的头像 <http://xmpp.org/extensions/xep-0008.html>. 7. XEP-0153: 基于vCard的头像 <http://xmpp.org/extensions/xep-0153.html>. 8. XEP-0115: 实体能力 <http://xmpp.org/extensions/xep-0115.html>. 9. XEP-0033: 可扩展的节地址 <http://xmpp.org/extensions/xep-0033.html>. 10. RFC 4648: Base16, Base32, 和 Base64 数据编码 <http://tools.ietf.org/html/rfc4648>. 11. RFC 3174: US Secure Hash Algorithm 1 (SHA1) <http://tools.ietf.org/html/rfc3174>. 12. IANA注册处的内容类型位于 <http://www.iana.org/assignments/media-types/>. 13. XEP-0030: 服务查询 <http://xmpp.org/extensions/xep-0030.html>. 14. XEP-0054: vcard-temp <http://xmpp.org/extensions/xep-0054.html>. 15. 互联网号码分配机构(IANA)是为互联网协议分配唯一性的参数值的中间协调者, 类似端口号码和 URI schemes. 更多信息参见 <http://www.iana.org/>. 16. XMPP注册处维护一个保留的协议命名空间的列表和在XMPP标准基金会批准的XMPP扩展协议的上下文中使用的参数的注册项的列表. 更多信息见 <http://xmpp.org/registrar/>. 附录H:修订历史注意: 本协议的旧版本可能在 http://xmpp.org/extensions/attic/ 还可用 Version 1.1 (2008-11-05) For consistency with other PEP payload formats, changed stop semantics to use an empty <metadata/> element rather than a <stop/> child element. (psa) Version 1.0 (2007-11-07) Per a vote of the XMPP Council, advanced status to Draft; concurrently, the XMPP Registrar issued the urn:xmpp:avatar:data and urn:xmpp:avatar:metadata namespaces. (psa) Version 0.12 (2007-08-31) Clarified HTTP publishing; completed copy edit. (psa) Version 0.11 (2007-07-25) Removed image size requirements. (psa) Version 0.10 (2007-06-18) Changed height and width attributes from required to recommended; updated security considerations to reflect problems with SHA-1; further specified datatypes. (psa) Version 0.9 (2007-02-01) Updated to reflect pubsub and PEP changes; added implementation notes about multiple resources and avatar synchronization; modified experimental namespaces to conform to XEP-0053. (psa) Version 0.8 (2006-06-19) Updated to reflect pubsub and PEP changes; added implementation notes about multiple resources and avatar synchronization. (psa) Version 0.7 (2006-01-17) Updated to use PEP. (psa) Version 0.6 (2005-04-13) Major modification per list discussion: specified that metadata may include the same avatar in multiple alternate formats; allowed pointers to third-party avatars not available via pubsub or HTTP; changed pixel size restrictions; specified that bytes, content-type, height, id, and width are required metadata; changed type attribute to content-type; made explicit that URLs can be http: or https: URIs; more fully specified protocol, updated the examples, updated the schemas. (psa) Version 0.5 (2005-03-28) Friendly fork per Council discussion: allowed data to be stored in a pubsub data repository or at a URL accessible via HTTP; also split text into publisher and subscriber use cases, specified requirements, added more examples, etc. (psa/pgm) Version 0.4 (2003-05-20) Lessen the image requirements. Include the content type in info. (tjm) Version 0.3 (2003-05-08) Drastic change to use two nodes on pubsub, allowing for hash updates independently of the data. This makes client caching much easier. Allow only PNG and MNG currently. (tjm) Version 0.2 (2003-05-07) Clarified the use of "current" as the item id. Fixed some example errors. Made the interaction with disco more clear. The reason to use pubsub is made more clear as well. (tjm) Version 0.1 (2003-05-07) Initial version. (tjm) |
绪论
本文定义了一个协议让终端实体能够为一个XMPP <message/>节指定附加的递送语义. 本协议通常用于客户端通知接收服务器如何递送一个特殊的节, 例如提供一个失效期或资源匹配策略
动机
<message/>节的内置递送语义(定义于XMPP Core 1, 对即时消息应用来说,也定义于XMPP IM 2),对目前大多数的应用,是足够的. 无论如何, 更严格的递送语义在很多情况下还是需要的. 本文讨论的是最常见的一些情况:
- 可靠的数据传输 -- 发送者要求消息递送的通知(肯定的和/或否定的).
- 时间敏感的消息 -- 消息仅在特定的日期和时间之前是合法的.
- 临时消息 -- 消息不应该离线存储用于以后的递送.
概念
本协议主要由服务器或处理<message/>的服务来处理. 协议包括一系列的规则, 每个规则有相应的条件和动作. 在收到一个适当标记的消息之后, 服务器解析它们所收到的规则, 寻找吻合的条件. 当一个条件吻合时, 那个规则的相应动作被执行, 同时消息处理停止.
每个规则受限于它所应用的范围, 要么是全部路由, 或者是路由的每一跳. 另外, 虽然本文定义了一套缺省的条件和动作, 本协议有足够的可扩展性允许将来更多的定义.
本协议的名字空间是"http://jabber.org/protocol/amp".
前提
为了本协议能够正常执行, 包含的<message/>节必须(MUST)拥有一个'id'属性并且'id'属性的值不能(MUST NOT)是一个空的字符串. 服务器必须(MUST)在任何给发送者的应答中包含这个'id'属性值; 这使服务器和客户端能把初始的请求正确关联到接下来的任何警报,错误,或通知中.
处理流程
发送者-到-服务器
以下用例描述了发送者和服务器之间的交互. 如下所示, 这个交互实际上很简单:
- 发送者确定支持(E1)
- 发送者指定适当的规则并发送消息给服务器(E1,E2)
- 发送者等待任何协议定义的应答(UCE)
- E1: 服务器不支持本协议(UCE unsuccessfully)
- E2: 服务器不支持一个或多个定义的规则条件/动作(UCE unsuccessfully)
发现
希望使用AMP的发送实体应该(SHOULD)向预定的路径查询对本协议的支持(使用服务发现 3). 一般来说, 这包括发送 disco#info 查询 给发送者本身所在的服务器以及接收者的服务器. 这些查询的结果可以(MAY)被缓存24小时, 除非有其他原因过期.
如果一个服务器支持高级消息处理, 它必须(MUST)在返回给请求实体的服务查询信息结果中包含一个服务特性"http://jabber.org/protocol/amp"来报告.
例子 1. 初始化服务发现信息请求
<iq from='northumberland@shakespeare.lit/westminster'
to='shakespeare.lit'
type='get'>
<query xmlns='http://jabber.org/protocol/disco#info'/>
</iq>例子 2. 服务发现信息应答
<iq from='shakespeare.lit'
to='northumberland@shakespeare.lit/westminster'
type='result'>
<query xmlns='http://jabber.org/protocol/disco#info'>
<identity name='Shakespeare IM' category='im' type='server'/>
...
<feature var='http://jabber.org/protocol/amp'/>
...
</query>
</iq>一个服务器也应该(SHOULD)维护一个名为"http://jabber.org/protocol/amp"的服务查询节点, 在那里声明它支持的单个的动作和条件. 如果一个实体需要决定是否服务器支持单个的动作和条件, 它应该(SHOULD)发送一个服务发现信息请求给那个节点; 然后服务器必须(MUST)要么返回支持的动作和条件列表要么返回一个错误例如<feature-not-implemented/>. (注意: 如果这个服务器节点不为此查询节点提供信息, 请求实体必须(MUST)认为每一个动作集或条件集的所有动作和条件都被支持.)
每个支持的动作将被报告成一个特性,使用以下格式:
http://jabber.org/protocol/amp?action={action}
每个支持的条件将被报告成一个特性, 使用以下格式:
http://jabber.org/protocol/amp?condition={condition}
以下展示的 请求-应答 流的例子是关于独立的动作和条件的信息(注意'node'属性中包含了什么).
例子 3. 对于独立动作和条件的信息的请求
<iq from='northumberland@shakespeare.lit/westminster'
to='shakespeare.lit'
type='get'>
<query xmlns='http://jabber.org/protocol/disco#info'
node='http://jabber.org/protocol/amp'/>
</iq>例子 4. 对于独立动作和条件的应答
<iq from='shakespeare.lit'
to='northumberland@shakespeare.lit/westminster'
type='result'>
<query xmlns='http://jabber.org/protocol/disco#info'
node='http://jabber.org/protocol/amp'>
<identity name='Shakespeare IM AMP Support' category='im' type='server'/>
...
<feature var='http://jabber.org/protocol/amp'/>
<feature var='http://jabber.org/protocol/amp?action=drop'/>
<feature var='http://jabber.org/protocol/amp?action=error'/>
<feature var='http://jabber.org/protocol/amp?action=notify'/>
<feature var='http://jabber.org/protocol/amp?condition=deliver'/>
<feature var='http://jabber.org/protocol/amp?condition=expire-at'/>
<feature var='http://jabber.org/protocol/amp?condition=match-resource'/>
...
</query>
</iq>指定语义
一旦支持被确定了, 发送者就可以附加期望的递送语义给消息:
例子 5. 一个伴随 AMP 语义的消息
<message
from='northumberland@shakespeare.lit'
id='richard2-4.1.247'
to='kingrichard@royalty.england.lit'>
<body>My lord, dispatch; read o'er these articles.</body>
<amp xmlns='http://jabber.org/protocol/amp'>
<rule condition='expire-at'
action='drop'
value='2004-01-01T00:00:00Z'/>
</amp>
</message>那些语义作为一组 <rule/> 元素定义在 <amp/> 根元素中. 每个 <rule/> 声明一个触发条件和触发后执行的动作.
缺省的, 规则集仅用于 "边缘服务器": 那些发送和接收实体所连接的服务器. (注意: 为了实现高级消息处理, 这里 "服务器" 被定义为在 XMPP Core 范畴之内并且不包括任何内部组件(可能在服务器实现或安装中提供功能), 如连接管理器 .)
通过增加"per-hop"属性给 <amp/> 元素, 规则集可以(MAY)应用于从发送实体到接收实体的路由中的 服务器-服务器 的每一"跳". 这个属性的值要么是 "true" (应用规则于每一跳) 要么是 "false" (保持缺省行为, 也就是, 规则仅应用于边缘服务器).
例子 6. 另一个伴随 AMP 语义的消息
<message
from='northumberland@shakespeare.lit'
id='richard2-4.1.247'
to='kingrichard@royalty.england.lit'>
<body>My lord, dispatch; read o'er these articles.</body>
<amp xmlns='http://jabber.org/protocol/amp'
per-hop='true'>
<rule condition='expire-at'
action='drop'
value='2004-01-01T00:00:00Z'/>
</amp>
</message>关于失败确认的例子, 参考本文的错误处理章.
注意: 即使 "per-hop" 处理被请求, 路由中的每一个服务器必须(MUST)忽略它无法应用的规则; 定义的条件说明了是否它们能被应用于每一跳.
服务器处理
服务器操作大多在此处执行. 接收到一个包含 AMP 扩展的消息之后, 服务器执行以下流程:
1. 确认语义 (E1, E2).
2. 决定缺省行为.
3. 处理规则直到条件吻合.
- 如果条件吻合, 执行那个规则的动作
- 如果没有条件吻合, 执行那个消息的 "缺省" 行为
4. 运行决定的动作 (UCE) (E3).
- E1: 已提供的语义 (条件和/或动作) 不被支持或不合法 (UCE 不成功的)
- E2: 请求的语义不可接受(UCE 不成功的)
- E3: 下一个服务器不支持此协议(UCE 不成功的)
确认语义
确认可以采取多种方式, 但是最少服务器必须(MUST)确认它理解每一个规则条件和动作, 并且条件内容是适当的. 服务器也可以(MAY)拒绝接受特定的条件和动作组合, 例如如果他们会导致违反安全策略的风险. 如果语义不合法, 不被支持, 或不被接受, 服务器必须(MUST)应答一个错误指出那些卷入的规则. 服务器应当(SHOULD)在返回错误之前确认所有语义. 关于和确认失败相关的错误处理语法和例子, 参考本文的错误处理章.
决定缺省动作
这一步是原本服务器通常应该做的, 除了那些不确定执行的动作. 它决定如果没有语义附加到一个消息的时候将会发生什么(例如分发给另一个服务器或离线存储). 在这一点, 服务器也应该(SHOULD)计算任何定时或日历需求(如果可以应用的话).
处理规则
在这一步, 服务器处理附加的语义. 服务器必须(MUST)顺序处理规则, 并且是按照它们在 <amp/> 元素中出现的顺序. 一旦一个规则的条件吻合, 处理结束于那一个动作并超越前面定义的缺省动作(除非这个动作允许继续处理).
执行决定的动作
一旦所有规则被处理或其他合理的理由, 服务器在这一点执行决定的动作.
服务器不应该(SHOULD NOT)分发一个包含 AMP 语义的 <message/> 节给另一个服务器, 除非它知道下一个服务器支持 AMP (这应该(SHOULD)通过服务发现协议来查询并可以(MAY)缓存以防止递送延迟). 如果下一个服务器不支持 AMP, 当前服务器应答给原始发送者一个 <service-unavailable/> 错误条件. 否则流程再次从那个消息已分发到其中的服务器开始.
返回事件
如果决定的动作包括返回一个事件(警告, 错误, 或通知) 给发送者, 服务器必须(MUST)发送一个<message/> 节给发送者, 包含那个吻合的规则. 这个 <message/> 节必须(MUST)包含初始的'id'属性值并且不应该(SHOULD NOT)包含开始发送者发送的非-AMP 的内容(例如, <body/> 子元素).
条件和动作
本文的前面章节中定义了关于 AMP 的一般行为. 本章概述怎样设置 <rule/> 动作和条件集. 它也提供定义的动作和条件集; 这些动作和条件集应该(SHOULD)被任何 AMP 的实现所支持, 但是对任何动作或条件集的支持不是必需的. (注意: 这里定义的动作和条件集可以在将来补充, 只要在 XMPP Registrar中注册新增的动作和条件集.)
规则条件指南
一个 <rule/> 条件必须(MUST)提供以下信息:
- 定义一个管理条件集的名字空间
- 定义条件:
-
- 定义 'condition' 属性值
-
- 指定 "per-hop" 标记(如果应用了的话)
-
- 定义 'value' 属性值的语法/格式
-
- 定义 "value" 如何与条件匹配
规则动作指南
一个 <rule/> 动作的定义必须(MUST)提供以下信息:
- 定义一个管理动作集的名字空间
- 定义动作:
-
- 定义每个 'action' 属性值
-
- 定义 <rule/> 被触发之后期望的行为
定义的条件
条件定义了一个典型的规则如何或何时被触发. 条件属性的值决定 <rule/> 内容的含义.
以下本文定义的条件应该(SHOULD)被所有实现支持.
在以下章节中, 术语 "content" 和 "contents" 参考包含在 <rule/> 元素中的XML字符数据.
递送
"deliver" 条件用于在以下五种情况下确保递送 (或不递送):
- 通过 XMPP 直接给指定的地址或帐号
- 延迟递送离线储存 (用于以后通过 XMPP 递送)
- 通过 XMPP 转发给替代的地址或帐号
- 通过一个网关非直接地发给一个替代的非XMPP系统地址或帐号
在条件吻合的时候在接收的这一刻处理器将对这些消息做些什么, 如下:
表 1: "deliver" 值
| 值 | 描述 |
|---|---|
| direct | 消息将被立刻递送给指定的接收者或路由到下一跳. |
| forward | 消息将被转发给另一个 XMPP 地址或帐号. |
| gateway | 消息将通过网关发送给一个 非XMPP 系统的地址或帐号. |
| none | 消息将根本不被递送 (例如, 因为指定的接收者离线并且消息存储不被允许). |
| stored | 消息将被离线存储用于以后递送给指定的接收者. |
这个条件可以(MAY)应用于服务器路由中的每一 "跳".
期满
"expire-at"条件用于确保在一个绝对的时间点之前递送. 很自然的, 这不保证4 从发送者的角度来看那个消息在那个时间之后不被发送, 因为本文没有假定所有机器(例如, 对于递送路由中的所有服务器)的时钟是同步的. 无论如何, 为了帮助确保这一条件正确地匹配, 那些实现了本文的服务器(或那些承载了这类服务的机器) 应该(SHOULD)使用网络时间协议(RFC 1305 5)和已确定的授时保持同步. 也要注意 期满 时间离当前时间越近则 期满 功能越不可靠(例如, 一个消息指定的 期满 时间为两秒比起设置为两小时或两天, 发送者将会更容易得到不可靠的递送).
'value'属性的内容定义了消息发送的准确时间之后的一些点; 它的内容必须(MUST)是一个 DateTime (定义在 XMPP Date and Time Profiles 6), 并且时区必须(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@montague.net/work", 伴随"exact"的"match-resource"条件 , 如果这个消息只能立刻被发送给"romeo@montague.net/work", 则条件吻合.
为了达到这个条件的目的, 一个没有资源的特定 JID 有以下行为:
- 如果值为"other", 仅当服务器将不递送给没有资源ID的目标JID时, 条件成立.
这个条件不能(MUST NOT)被应用于服务器路由的每一"跳", 只能用于边缘服务器. 如果一个 <amp/> 元素包含了这个条件并且指明它将被每一跳处理, 这个 <rule/> 将被忽略.
注意: 从设计上说, 这个协议不包含局部资源匹配的支持(它将导致, 例如, 资源ID"home/laptop"和"homeboy"都匹配"home").
定义的动作
动作定义了当一个特定的规则被触发时将发生什么. 动作属性的值决定如果一个规则的条件被触发之后的行为.
以下动作由本文定义.
警告
"alert"动作触发一个应答 <message/> 节给发送实体. 这个 <message/> 节必须(MUST)包含元素<amp status='alert'/>, 它本身包含触发这个动作的 <rule/> . 在所有其他的关系中In all other respects, 这个动作表现为"drop".
例子 7. 警告 应答
<message from='hamlet.lit'
to='bernardo@hamlet.lit/elsinore'
id='chatty2'>
<amp xmlns='http://jabber.org/protocol/amp'
status='alert'
from='francisco@hamlet.lit'
to='bernardo@hamlet.lit/elsinore'>
<rule action='alert' condition='deliver' value='stored'/>
</amp>
</message>丢弃
"drop"动作安静地从任何更多递送尝试中丢弃消息并确保它不会被离线存储. drop 不能(MUST NOT)导致任何其他应答.
错误
| 动作 | 值 | 描述 |
|---|---|---|
| alert | direct | 返回一个警告如果消息将被直接递送. |
| alert | forward | 返回一个警告如果消息将被转发给另一个 XMPP 地址. |
| alert | gateway | 返回一个警告如果消息将通过一个网关递送到一个非XMPP地址. |
| alert | none | 返回一个警告如果消息无法递送. |
| alert | stored | 返回一个警告如果消息将被离线存储用于以后通过 XMPP 递送. |
| drop | direct | 丢弃这个消息如果它将被直接递送. |
| drop | forward | 丢弃这个消息如果它将被转发到另一个 XMPP 地址. |
| drop | gateway | 丢弃这个消息如果它将通过一个网关递送到一个非XMPP地址. |
| drop | none | 丢弃这个消息如果它无法递送. |
| drop | stored | 丢弃这个消息如果它将被离线存储用于以后通过 XMPP 递送. |
| error | direct | 返回一个错误如果消息将被直接递送. |
| error | forward | 返回一个错误如果消息将被转发给另一个 XMPP 地址. |
| error | gateway | 返回一个错误如果消息将通过一个网关递送到一个非XMPP地址. |
| error | none | 返回一个错误如果消息无法递送. |
| error | stored | 返回一个错误如果消息将被离线存储用于以后通过 XMPP 递送. |
| notify | direct | 返回一个通知如果消息将被直接递送. |
| notify | forward | 返回一个通知如果消息将被转发给另一个 XMPP 地址. |
| notify | gateway | 返回一个通知如果消息将通过一个网关递送到一个非XMPP地址. |
| notify | none | 返回一个通知如果消息无法递送. |
| notify | stored | 返回一个通知如果消息将被离线存储用于以后通过 XMPP 递送. |
期满规则
当一个条件是"expire-at", 规则描述如下:
表 4: 期满规则
| 动作 | 描述 |
|---|---|
| alert | 返回一个警告如果消息将在指定的时间戳之后递送. |
| drop | 丢弃这个消息如果它将在指定的时间戳之后递送. |
| error | 返回一个错误如果消息将在指定的时间戳之后递送. |
| notify | 返回一个通知如果消息将在指定的时间戳之后递送. |
资源匹配规则
当一个条件是"match-resource", 规则描述如下:
表 5: 资源匹配规则
| 动作 | 值 | 描述 |
|---|---|---|
| alert | any | 返回一个警告如果消息将被递送给任何资源. |
| alert | exact | 返回一个警告如果消息将被递送给准确的资源. |
| alert | other | 返回一个警告如果消息将被递送给指定资源之外的资源. |
| drop | any | 丢弃这个消息如果它将被递送给任何资源. |
| drop | exact | 丢弃这个消息如果它将被递送给准确的资源. |
| drop | other | 丢弃这个消息如果它将被递送给指定资源之外的资源. |
| error | any | 返回一个错误如果消息将被递送给任何资源. |
| error | exact | 返回一个错误如果消息将被递送给准确的资源. |
| error | other | 返回一个错误如果消息将被递送给指定资源之外的资源. |
| notify | any | 返回一个通知如果消息将被递送给任何资源. |
| notify | exact | 返回一个通知如果消息将被递送给准确的资源. |
| notify | other | 返回一个通知如果消息将被递送给指定资源之外的资源. |
正式描述
<amp/>根元素
所有递送语义都被封装在 <amp/> 元素里. 这个元素包含一个或多个 <rule/> 元素指定特定的规则来处理. 它能选择性地拥有关于当前状态的属性, 原始发送者和接收者, 以及路由的适用性.
'status'属性为 <amp/> 元素指定原因. 当指定的语义被应用时(客户端到服务器), 这个属性不能(MUST NOT)出现. 当根据一个匹配的条件向一个发送实体应答时, 这个属性必须(MUST)出现并且应该(SHOULD)是已触发规则的'action'属性的值. (注意: 单独的动作定义可以(MAY)提供它们自己的要求.)
'from'属性指明包含 <message/> 节的原始发送者. 这个属性必须(MUST)由任何从支持的服务器发送的 <message/> 节指定, 不管接收者是什么情况. 它不应该(SHOULD NOT)以别的方式指定. 'from'属性值必须(MUST)是原始 <message/> 节的发送者的全JID (node@domain/resource).
'to'属性指明包含 <message/> 节的原始(期望的)接收者. 这个属性必须(MUST)由任何从支持的服务器发送的 <message/> 节指定, 不管接收者是什么情况. 它不应该(SHOULD NOT)以别的方式指定. 'to'属性值必须(MUST)是原始 <message/> 节的预定接收者的全JID (node@domain/resource).
'per-hop'属性标记是否在原始发送者和原始的预定接收者之间的路由的每一跳处理包含的规则集. 这个属性可以(MAY)出现, 并且必须(MUST)要么是"true"要么是"false". 如果不显示, 缺省是"false".
<rule/>元素
每个语义规则由一个 <rule/> 元素指定. 这个元素拥有一些属性用于条件, 值, 和动作.
'action'属性为这个规则定义结果. 这个属性必须(MUST)出现, 并且必须(MUST)要么是一个在
定义的动作 章节定义的值, 要么在 XMPP Registrar 中注册了.'condition'属性定义这个规则应用的全部条件. 这个属性必须(MUST)出现, 并且必须(MUST)要么是一个在 定义的条件 章节定义的值, 要么在 XMPP Registrar 中注册了.
'value'属性定义条件如何匹配. 这个属性必须(MUST)出现, 并且不能(MUST NOT)是空的字符串(""). 这个属性的值的解释由'condition'属性决定.
示例场景
可靠数据传输
<message/> 节对于数据传输来说几乎是完美的, 但是为了确保可靠性经常会要求某一消息不递送给任何指定资源之外的资源. 为了满足这个要求, 发送实体包含一个 <rule action='drop' condition='match-resource' value='other'/> (如果不需要失败通知的话) 或 <rule action='error' condition='match-resource' value='other'/> (如果需要失败通知的话). 以下例子使用 带内字节流 8 展示了这一场景:
例子 10. 发送一个可靠数据传输的消息
<message to='francisco@hamlet.lit/pda'
from='bernardo@hamlet.lit/elsinore'
id='ibb1'>
<data xmlns='http://jabber.org/protocol/ibb' sid='mySID' seq='0'>
qANQR1DBwU4DX7jmYZnncmUQB/9KuKBddzQH+tZ1ZywKK0yHKnq57kWq+RFtQdCJ
WpdWpR0uQsuJe7+vh3NWn59/gTc5MDlX8dS9p0ovStmNcyLhxVgmqS8ZKhsblVeu
IpQ0JgavABqibJolc3BKrVtVV1igKiX/N7Pi8RtY1K18toaMDhdEfhBRzO/XB0+P
AQhYlRjNacGcslkhXqNjK5Va4tuOAPy2n1Q8UUrHbUd0g+xJ9Bm0G0LZXyvCWyKH
kuNEHFQiLuCY6Iv0myq6iX6tjuHehZlFSh80b5BVV9tNLwNR5Eqz1klxMhoghJOA
</data>
<amp xmlns='http://jabber.org/protocol/amp' per-hop='true'>
<rule action='error' condition='expire-at' value='2004-09-10T08:33:14Z'/>
<rule action='error' condition='match-resource' value='other'/>
</amp>
</message>在以上案例中, 如果消息不能在指定的时间递送到指定的"francisco@hamlet.lit/pda"地址, 发送者将收到一个错误应答. 举例来说, 如果预定的资源在消息能够递送之前下线了, 处理服务器将返回以下错误:
例子 11. 失败的可靠数据传输消息
<message from='hamlet.lit'
to='bernardo@hamlet.lit/elsinore'
id='ibb1'>
<amp xmlns='http://jabber.org/protocol/amp'
from='bernardo@hamlet.lit/elsinore'
to='francisco@hamlet.lit/pda'>
<rule action='error' condition='match-resource' value='other'/>
</amp>
<error type='modify' code='500'>
<undefined-condition xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
<failed-rules xmlns='http://jabber.org/protocol/amp#errors'>
<rule action='error' condition='match-resource' value='other'/>
</failed-rules>
</error>
</message>时间敏感消息
时间敏感消息在某些环境是一个频繁发生的事情(例如, 全体决策人员例行通知其他人某些客户"事件", 意外的小憩, 以及特别的聚会). 要发送一个时间敏感消息, 发送实体可以在一个 <rule action='drop' condition='expire-at'/> 中包含事件发生的时间:
例子 12. 发送一个时间敏感消息
<message to='linuxwolf@outer-planes.net'
from='receptionist@outer-planes.net'
id='alert849'>
<subject>Guest Alert!</subject>
<body>
There will be clients in the conference room today around 1 PM!
As always, be courteous and quiet nearby...
</body>
<amp xmlns='http://jabber.org/protocol/amp'>
<rule action='drop' condition='expire-at' value='2003-06-23T23:00:00Z'/>
</amp>
</message>在上述例子中, 一旦时间超过 23:00 UTC (3:00 PM Pacific Daylight Time)， "linuxwolf@outer-planes.net"的服务器将不递送这个消息.
瞬时消息
瞬时消息是指那些永远不应该离线存储的消息. 要发送一个瞬时消息, 发送实体可以包含一个 <rule action='drop' condition='deliver' value='stored'/>:
例子 13. 发送一个瞬时消息
<message to='francisco@hamlet.lit'
from='bernardo@hamlet.lit/elsinore'
type='chat'
id='chatty1'>
<body>Who's there?</body>
<amp xmlns='http://jabber.org/protocol/amp'>
<rule action='drop' condition='deliver' value='stored'/>
</amp>
</message>作为选择, 发送实体可以包含一个 <rule action='alert' condition='deliver' value='stored'/> 来提出警告而不是安静地丢弃这个消息:
例子 14. 发送一个瞬时消息(请求警告)
<message to='francisco@hamlet.lit'
from='bernardo@hamlet.lit/elsinore'
type='chat'
id='chatty2'>
<body>Who's there?</body>
<amp xmlns='http://jabber.org/protocol/amp'>
<rule action='alert' condition='deliver' value='stored'/>
</amp>
</message>例子 15. 关于瞬时消息的发送者警告
<message from='hamlet.lit'
to='bernardo@hamlet.lit/elsinore'
id='chatty2'>
<amp xmlns='http://jabber.org/protocol/amp'
action='alert'
from='bernardo@hamlet.lit/elsinore'
to='francisco@hamlet.lit'>
<rule action='alert' condition='deliver' value='stored'/>
</amp>
</message>错误处理
条件
为了简化错误条件的讨论, 本文在名字空间 URIs 和名字空间前缀之间使用以下映射(注意: 这个映射仅用于简化讨论的目的而不是想在协议本身中使用它).
表 6: 名字空间映射
| 前缀 | URI |
|---|---|
| xmpp | urn:ietf:params:xml:ns:xmpp-stanzas |
| msg | http://jabber.org/protocol/amp |
| err | http://jabber.org/protocol/amp#errors |
接下来的表显示和一般的 AMP 规则,和条件以及 定义的动作 相关的可能的错误条件.
表 7: 错误条件
| 一般条件 | 错误类型 | 详细条件 | 描述 |
|---|---|---|---|
| <xmpp:bad-request/> | modify | <msg:unsupported-actions/> | 不支持一个或多个规则的指定动作. 元素 <msg:unsupported-actions/> 包含那个指定了不支持的动作的 <rule/> 元素. |
| <xmpp:bad-request/> | modify | <msg:unsupported-conditions/> | 不支持一个或多个规则的指定条件. 元素 <msg:unsupported-conditions/> 包含那个指定了不支持的条件的 <rule/> 元素. |
| <xmpp:not-acceptable/> | modify | <msg:invalid-rules/> | 服务器不接受一个或多个规则, 通常是因为条件/动作组合被限制. 元素 <msg:invalid-rules/> 包含那个不被接受的<rule/> 元素. |
| <xmpp:service-unavailable/> | cancel | NONE | 不支持本协议. 如果到达接收者的路由中的服务器没有实现本协议, 这个错误被返回给发送实体. |
| <xmpp:undefined-condition/> | modify | <err:failed-rules/> | 一个或多个 <rule/> 元素触发了 "error" 动作. 这个条件包含那个被触发的 <rule/> 元素. |
例子
本章显示上一章的错误条件的例子(关于 XMPP 错误条件和 Jabber 错误码的映射信息, 参考 错误条件映射 9).
不支持的动作
例子 16. 一个包含AMP语义的消息
<message
from='northumberland@shakespeare.lit'
id='richard2-4.1.247'
to='kingrichard@royalty.england.lit'>
<body>My lord, dispatch; read o'er these articles.</body>
<amp xmlns='http://jabber.org/protocol/amp'>
<rule action='drop' condition='expire-at' value='2004-01-01T00:00:00Z'/>
</amp>
</message>例子 17. 服务器不支持动作
<message
from='shakespeare.lit'
id='richard2-4.1.247'
to='northumberland@shakespeare.lit'
type='error'>
<amp xmlns='http://jabber.org/protocol/amp'>
<rule action='drop' condition='expire-at' value='2004-01-01T00:00:00Z'/>
</amp>
<error type='modify' code='400'>
<bad-request xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
<unsupported-actions xmlns='http://jabber.org/protocol/amp'>
<rule condition='expire-at'
action='drop'
value='2004-01-01T00:00:00Z'/>
</unsupported-actions>
</error>
</message>不支持的条件
例子 18. 一个包含AMP语义的消息
<message
from='shakespeare.lit'
id='richard2-4.1.247'
to='kingrichard@royalty.england.lit'>
<body>My lord, dispatch; read o'er these articles.</body>
<amp xmlns='http://jabber.org/protocol/amp'>
<rule action='drop' condition='expire-at' value='2004-01-01T00:00:00Z'/>
</amp>
</message>例子 19. 服务器不支持条件
<message
from='shakespeare.lit'
id='richard2-4.1.247'
to='northumberland@shakespeare.lit'
type='error'>
<amp xmlns='http://jabber.org/protocol/amp'>
<rule action='drop' condition='expire-at' value='2004-01-01T00:00:00Z'/>
</amp>
<error type='modify' code='400'>
<bad-request xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
<unsupported-conditions xmlns='http://jabber.org/protocol/amp'>
<rule action='drop' condition='expire-at' value='2004-01-01T00:00:00Z'/>
</unsupported-conditions>
</error>
</message>不被接受
例子 20. 一个包含AMP语义的消息
<message
from='northumberland@shakespeare.lit'
id='richard2-4.1.247'
to='kingrichard@royalty.england.lit'>
<body>My lord, dispatch; read o'er these articles.</body>
<amp xmlns='http://jabber.org/protocol/amp'>
<rule action='drop' condition='expire-at' value='2004-01-01T00:00:00Z'/>
</amp>
</message>例子 21. 规则不被服务器接受
<message
from='shakespeare.lit'
id='richard2-4.1.247'
to='northumberland@shakespeare.lit'
type='error'>
<amp xmlns='http://jabber.org/protocol/amp'>
<rule action='drop' condition='expire-at' value='2004-01-01T00:00:00Z'/>
</amp>
<error type='modify' code='405'>
<not-acceptable xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
<invalid-rules xmlns='http://jabber.org/protocol/amp'>
<rule action='drop' condition='expire-at' value='2004-01-01T00:00:00Z'/>
</invalid-rules>
</error>
</message>服务不可用
例子 22. 一个包含AMP语义的消息
<message
from='northumberland@shakespeare.lit'
id='richard2-4.1.247'
to='kingrichard@royalty.england.lit'>
<body>My lord, dispatch; read o'er these articles.</body>
<amp xmlns='http://jabber.org/protocol/amp'>
<rule action='drop' condition='expire-at' value='2004-01-01T00:00:00Z'/>
</amp>
</message>例子 23. AMP服务不可用
<message
from='royalty.england.lit'
id='richard2-4.1.247'
to='northumberland@shakespeare.lit'
type='error'>
<amp xmlns='http://jabber.org/protocol/amp'>
<rule action='drop' condition='expire-at' value='2004-01-01T00:00:00Z'/>
</amp>
<error type='cancel' code='503'>
<service-unavailable xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
</error>
</message>未定义的条件
例子 24. 一个包含AMP语义的消息
<message from='hamlet.lit'
to='bernardo@hamlet.lit/elsinore'
id='chatty2'>
<body>Who's there?</body>
<amp xmlns='http://jabber.org/protocol/amp'
status='error'
from='francisco@hamlet.lit'
to='bernardo@hamlet.lit/elsinore'>
<rule action='error' condition='deliver' value='stored'/>
</amp>
</message>例子 25. 失败的规则
<message from='hamlet.lit'
to='bernardo@hamlet.lit/elsinore'
type='error'
id='chatty2'>
<amp xmlns='http://jabber.org/protocol/amp'
status='error'
from='francisco@hamlet.lit'
to='bernardo@hamlet.lit/elsinore'>
<rule action='error' condition='deliver' value='stored'/>
</amp>
<error type='modify' code='500'>
<undefined-condition xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
<failed-rules xmlns='http://jabber.org/protocol/amp#errors'>
<rule action='error' condition='deliver' value='stored'/>
</failed-rules>
</error>
</message>实现备注
如果接收者的服务器实现了"离线存储", 它将需要跟踪那些离线消息以遵守期满规则并且不能递送那些过期的消息. 如何正确地做到这一点是实施的一个问题. 一个可能的实施是让服务器维护一个独立的可过期消息的数据库并定时扫描它; 发现一个过期的消息之后, 它可以把这个消息标记为符合丢弃条件并通知发送者, 但是直到接收者下次可用的时候才真正丢弃这个消息.
流特性
XMPP Core 10 定义了在流协商期间声明特性支持的方法. 为了提高效率, 服务器把AMP作为流特性支持来声明是值得的. 在 <stream:features/> 中用于报告这一支持的名字空间是 "http://jabber.org/features/amp". 从初始化实体接收到流头信息之后, 接收实体(通常是服务器)返回一个流头信息给初始化实体并且可以(MAY)通过注册相关的流特性宣告支持AMP:
例子 26. 宣告AMP为流特性之一
<?xml version='1.0' encoding='utf-8'?>
<stream:stream xmlns:stream='http://etherx.jabber.org/streams/'
xmlns='jabber:client'
from='somedomain'
version='1.0'>
<stream:features>
...
<amp xmlns='http://jabber.org/features/amp'/>
...
</stream:features>安全事项
大部分的 AMP 条件可能被用于未授权的个体获得IM服务器及其他基于出席信息的消息系统的用户的出席信息. 例如, 考虑以下场景: 用户 <romeo@montague.net> 不是用户 <nurse@capulet.com> 出席信息的一个授权订阅者, 但是发送了一个 <message/> 节给那个地址, 这个节包含了一个条件为 "deliver"值为"stored"的规则以及一个"alert"动作; 如果 Nurse 不在线, 在发现 Nurse 离线的过程中, Romeo 将接收到一个 AMP 警告那个消息已离线存储. 类似的场景可能出现在"match-resource"规则(发送给用户的常用资源)和"expire-at"规则(每分钟发送消息以获得出席信息). 如果一个服务器实现了如 RFC 3921 11定义的出席信息订阅, 如果一个通知将暴露接收者的在线或离线状态12, 这个服务器不应该(SHOULD NOT)返回警告, 错误, 或其他 AMP 通知给未被授权查看接收者出席信息(通过一个订阅 "both" 或 "from")的发送者.
关于这个问题有以下几种不同的实施指引:
- 不实现相关的条件, 作为结果, 如果那个条件被指定, 服务器必须(MUST)应答一个 <feature-not-implemented/> 错误条件; 无论如何, 这过度限制了支持的条件显著地削弱了 AMP 的功能, 所以它是不推荐的(NOT RECOMMENDED).
- 只在动作为"drop"时接受相关的条件, 作为结果, 如果这个动作为"alert", "error", 或"notify", 服务器必须(MUST)应答一个 <not-acceptable/> 错误条件; 这轻微地限制但仍是不必要地限制了系统的功能, 所以这是不推荐的(NOT RECOMMENDED).
- 只有发送者被授权可以获得接收者的出席信息的时候才接受相关的条件, 作为结果, 如果发送者未获得那样的授权, 服务器必须(MUST)应答一个 <not-acceptable/> 错误条件; 这是推荐的(RECOMMENDED)行为.
IANA事项
本文档与互联网编号分配授权机构 13无关。
XMPP注册事项
协议名字空间
XMPP Registrar 14在它的协议名字空间注册项中包含了 'http://jabber.org/protocol/amp' 和 'http://jabber.org/protocol/amp#errors' 名字空间.
流特性
XMPP注册在它的流特性名字注册项中包括'http://jabber.org/features/amp'名字空间.
知名服务发现节点
XMPP注册在它的知名服务发现节点的注册项中包括了'http://jabber.org/protocol/amp'.
注册项
规则条件注册项
XMPP登记处在 <http://www.xmpp.org/registrar/amp-conditions.html> 维护了一个AMP <rule/>条件的注册项 .
过程
为了给这个注册项提交新值, 注册者必须按以下格式定义一个 XML 片断并且要么把它包含在相关的 XMPP 扩展协议中要么把它用发送给email地址<registrar@xmpp.org>:
<condition>
<name>the value of the 'condition' attribute</name>
<ns>the namespace to be used as a service discovery feature</ns>
<per-hop>does the "per-hop" flag apply? [true|false]</per-hop>
<value>
The syntax (e.g., datatype or allowable values) of the
'value' attribute.
</value>
<processing>values that result in message processing</processing>
<doc>the document (e.g., XEP) in which this condition is specified</doc>
</condition>注册者可以同一时间注册多个条件, 每个包含在一个独立的 <condition/> 节之中.
注意: 这个条件集的名字空间将被包含在 服务器发现特性注册项中Service Discovery features registry.
最低要求
<condition>
<name>deliver</name>
<ns>http://jabber.org/protocol/amp?condition=deliver</ns>
<per-hop>true</per-hop>
<value>[direct|forward|gateway|none|stored]</value>
<processing>
The condition is met if (1) the value is "direct" and the message
can be immediately delivered or further dispatched, (2) the value
is "forward" and the message can be forwarded to another XMPP
address, (3) the value is "gateway" and the message can be sent
to a non-XMPP address via a gateway, (4) the value is "none" and
the message cannot be delivered at all, or (5) the value is
"stored" and the message can be stored for later delivery.
</processing>
<doc>XEP-0079</doc>
</condition>
<condition>
<name>expire-at</name>
<ns>http://jabber.org/protocol/amp?condition=expire-at</ns>
<per-hop>true</per-hop>
<value>DateTime per XEP-0082</value>
<processing>
The condition is met if the message would be delivered after
the specified DateTime.
</processing>
<doc>XEP-0079</doc>
</condition>
<condition>
<name>match-resource</name>
<ns>http://jabber.org/protocol/amp?condition=match-resource</ns>
<per-hop>false</per-hop>
<value>[any|exact|other]</value>
<processing>
The condition is met if (1) the value is "any" and the intended
recipient has at least one available resource (as defined in the
XMPP IM specification); (2) the value "exact" and the intended
recipient has an available resource that exactly matches the JID
specified in the 'to' address; (3) the value is "other" and the
intended recipient has an available resource whose full JID is
other than that specified in the 'to' address.
</processing>
<doc>XEP-0079</doc>
</condition>规则动作注册项
XMPP登记处在 <http://www.xmpp.org/registrar/amp-actions.html> 中维护了一个 AMP <rule/> 动作注册项.
过程
为了给这个注册项提交新值, 注册者必须按以下格式定义一个 XML 片断并且要么把它包含在相关的 XMPP 扩展协议中要么把它用发送给email地址<registrar@xmpp.org>:
<action>
<name>the value of the 'action' attribute</name>
<ns>the namespace to be used as a service discovery feature</ns>
<behavior>the expected behavior if the rule is triggered</behavior>
<doc>the document (e.g., XEP) in which this action is specified</doc>
</action>注册者可以同一时间注册多个动作, 每个包含在一个独立的 <action/> 节之中.
注意: 这个动作集的名字空间将被包含在 服务器发现特性注册项中Service Discovery features registry.
初始提交
<action>
<name>alert</name>
<ns>http://jabber.org/protocol/amp?action=drop</ns>
<behavior>
The message is silently discarded but an alert is returned to the
sender.
</behavior>
<doc>XEP-0079</doc>
</action>
<action>
<name>drop</name>
<ns>http://jabber.org/protocol/amp?action=drop</ns>
<behavior>
The message is silently discarded.
</behavior>
<doc>XEP-0079</doc>
</action>
<action>
<name>error</name>
<ns>http://jabber.org/protocol/amp?action=error</ns>
<behavior>
The message is not processed and an error is returned to the sender,
specifying which rule resulted in failed processing.
</behavior>
<doc>XEP-0079</doc>
</action>
<action>
<name>notify</name>
<ns>http://jabber.org/protocol/amp?action=notify</ns>
<behavior>
The message is processed and a notification message is returned to
the sender, specifying which rule was processed.
</behavior>
<doc>XEP-0079</doc>
</action>XML架构
AMP
<?xml version='1.0' encoding='UTF-8'?>
<xs:schema
xmlns:xs='http://www.w3.org/2001/XMLSchema'
targetNamespace='http://jabber.org/protocol/amp'
xmlns='http://jabber.org/protocol/amp'
elementFormDefault='qualified'>
<xs:annotation>
<xs:documentation>
The protocol documented by this schema is defined in
XEP-0079: http://www.xmpp.org/extensions/xep-0079.html
</xs:documentation>
</xs:annotation>
<xs:element name='amp'>
<xs:complexType>
<xs:sequence>
<xs:element ref='rule' minOccurs='1' maxOccurs='unbounded'/>
</xs:sequence>
<xs:attribute name='from' usage='optional' type='xs:string'/>
<xs:attribute name='per-hop' use='optional' type='xs:bool' default='false'/>
<xs:attribute name='status' usage='optional' type='xs:NCName'/>
<xs:attribute name='to' usage='optional' type='xs:string'/>
</xs:complexType>
</xs:element>
<xs:element name='invalid-rules'>
<xs:complexType>
<xs:sequence>
<xs:element ref='rule' minOccurs='1' maxOccurs='unbounded'/>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name='unsupported-actions'>
<xs:complexType>
<xs:sequence>
<xs:element ref='rule' minOccurs='1' maxOccurs='unbounded'/>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name='unsupported-conditions'>
<xs:complexType>
<xs:sequence>
<xs:element ref='rule' minOccurs='1' maxOccurs='unbounded'/>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name='rule'>
<xs:complexType>
<xs:attribute name='action' use='required' type='xs:NCName'/>
<xs:attribute name='condition' use='required' type='xs:NCName'/>
<xs:attribute name='value' use='required' type='xs:string'/>
</xs:complexType>
</xs:element>
</xs:schema>错误
<?xml version='1.0' encoding='UTF-8'?>
<xs:schema
xmlns:xs='http://www.w3.org/2001/XMLSchema'
targetNamespace='http://jabber.org/protocol/amp#errors'
xmlns='http://jabber.org/protocol/amp#errors'
elementFormDefault='qualified'>
<xs:annotation>
<xs:documentation>
The protocol documented by this schema is defined in
XEP-0079: http://www.xmpp.org/extensions/xep-0079.html
</xs:documentation>
</xs:annotation>
<xs:element name='failed-rules'>
<xs:complexType>
<xs:sequence>
<xs:element ref='rule' minOccurs='1' maxOccurs='unbounded'/>
</xs:sequence>
</xs:complexType>
</xs:element>
<xs:element name='rule'>
<xs:complexType>
<xs:attribute name='action' use='required' type='xs:NCName'/>
<xs:attribute name='condition' use='required' type='xs:NCName'/>
<xs:attribute name='value' use='required' type='xs:string'/>
</xs:complexType>
</xs:element>
</xs:schema>流特性
<?xml version='1.0' encoding='UTF-8'?>
<xs:schema
xmlns:xs='http://www.w3.org/2001/XMLSchema'
targetNamespace='http://jabber.org/features/amp'
xmlns='http://jabber.org/features/amp'
elementFormDefault='qualified'>
<xs:annotation>
<xs:documentation>
The protocol documented by this schema is defined in
XEP-0079: http://www.xmpp.org/extensions/xep-0079.html
</xs:documentation>
</xs:annotation>
<xs:element name='amp' type='empty'/>
<xs:simpleType name='empty'>
<xs:restriction base='xs:string'>
<xs:enumeration value=''/>
</xs:restriction>
</xs:simpleType>
</xs:schema>致谢
感谢 Marshall Rose 和 Craig Kaes 的评论.
附录
附录A:文档信息
系列：XEP
序号：0079
发布者：XMPP标准基金会
状态：草案
类型：标准跟踪
版本：1.2
最后更新：2005-11-30
批准机构：XMPP理事会
依赖标准：XMPP Core, XEP-0030, XEP-0082
替代标准：XEP-0023
被替代标准：无
缩略名：amp
amp名字空间的XML架构(Schema): <http://www.xmpp.org/schemas/amp.xsd>
amp#errors名字空间的XML方案(Schema): <http://www.xmpp.org/schemas/amp-errors.xsd>
feature名字空间的XML方案(Schema): <http://www.xmpp.org/schemas/amp-feature.xsd>
注册项： <http://xmpp.org/registrar/amp.html>
附录B:作者信息
Matthew Miller
Email: linuxwolf@outer-planes.net
JabberID: linuxwolf@outer-planes.net
Peter Saint-Andre
Email: stpeter@jabber.org
JabberID: stpeter@jabber.org
URI: https://stpeter.im/
附录C:法律通告
版权
XMPP扩展协议的版权(1999-2008)归XMPP标准化基金会(XSF)所有.
权限
特此授权,费用全免,对任何获得本协议副本的人,对使用本协议没有限制,包括不限制在软件程序中实现本协议,不限制在网络服务中布署本协议,不限制拷贝,修改,合并,发行,翻译,分发,转授,或销售本协议的副本,被允许使用本协议做了以上工作的人士,应接受前述的版权声明和本许可通知并且必须包含在所有的副本或实质性部分的规格中.除非单独的许可，被重新分发的修改工作，不得含有关于作者，标题，编号，或出版者的规格的误导性资料，并不得宣称修改工作是由本文的作者，作者所属的任何组织或项目，或XMPP标准基金会签注。
免责声明'
## 特别注意：本协议是提供的“原样”的基础，没有担保或任何形式的条件，明示或暗示，包括，但不限于任何担保或关于名称，非侵权性，适销性或适合作某一特定目的的条件. ##
责任限制
在任何情况下以及没有任何法律规定时，不论是侵权行为（包括疏忽），合同或其它方面，除非根据适用法律的要求（如蓄意和有严重疏忽行为）或以书面形式同意，XMPP标准基金会或任何作者不对本协议所造成的损失承担责任，包括任何直接，间接，特殊，偶发，或任何从本协议出，入，连接的字符产生的或实现，布署或其他对本协议的使用导致的相应的损害赔偿（包括但不限于善意的损失，停止作业，电脑失灵或故障，或任何和所有其他商业损害或损失） ，即使XMPP标准基金会或作者已被告知此类损害的可能性。
知识产权的一致性
XMPP扩展协议完全遵守XSF的知识产权策略(可在<http://www.xmpp.org/extensions/ipr-policy.shtml>找到副本或写信给XMPP标准基金会, 1899 Wynkoop Street, Suite 600, Denver, CO 80202 USA).
附录D:和XMPP的关系
可扩展的消息和出席信息协议 (XMPP) 定义于 XMPP Core (RFC 3920) 和 XMPP IM (RFC 3921) 规范里，由 XMPP标准基金会贡献到由依据RFC 2026成立的互联网工程人物组管理的互联网标准流程 Internet Standards Process. 本文定义的任何协议已在互联网标准流程之外开发，并且被理解为 XMPP 的扩展而不是一个XMPP本身的演化, 开发, 或修改.
附录E:讨论地点
主要的XMPP扩展协议讨论地点是 <standards@xmpp.org> 讨论列表.
在 xmpp.org 的其它讨论列表中的讨论可能也有合适的; 所有的列表见 <http://xmpp.org/about/discuss.shtml> .
勘误表可以发送邮件到 <editor@xmpp.org>.
附录F:需求一致性
以下用于本文的需求关键字的解释见于 RFC 2119: "MUST", "SHALL", "REQUIRED"; "MUST NOT", "SHALL NOT"; "SHOULD", "RECOMMENDED"; "SHOULD NOT", "NOT RECOMMENDED"; "MAY", "OPTIONAL".
附录G:备注
- RFC 3920: 可扩展的消息和出席信息协议 (XMPP): 核心 <http://tools.ietf.org/html/rfc3920>.
- RFC 3921: 可扩展的消息和出席信息协议 (XMPP): 即时消息和出席信息 <http://tools.ietf.org/html/rfc3921>.
- XEP-0030: Service Discovery <http://xmpp.org/extensions/xep-0030.html>.
- 担保(Guarantee)是一个很重的词. 本文定义的方法是为了使得消息递送在特定范围内更加可靠, 而不是为了伪称这个方法使用了任何保证递送的措施.
- RFC 1305: Network Time Protocol (Version 3) <http://tools.ietf.org/html/rfc1305>.
- XEP-0082: XMPP Date and Time Profiles <http://xmpp.org/extensions/xep-0082.html>.
- XEP-0045: Multi-User Chat <http://xmpp.org/extensions/xep-0045.html>.
- XEP-0047: In-Band Bytestreams <http://xmpp.org/extensions/xep-0047.html>.
- XEP-0086: Error Condition Mappings <http://xmpp.org/extensions/xep-0086.html>.
- RFC 3920: 可扩展的消息和出席信息协议 (XMPP): 核心 <http://tools.ietf.org/html/rfc3920>.
- RFC 3921: 可扩展的消息和出席信息协议 (XMPP): 即时消息和出席信息 <http://tools.ietf.org/html/rfc3921>.
- 一个例外可以是完全信任或封闭的网络.
- 互联网编号分配机构(IANA) 是用于互联网协议的唯一性参数值分配的核心协调者, 例如号码和URI计划. 更多信息, 见 <http://www.iana.org/>.
- XMPP登记员XMPP Registrar 维护着一个保留的协议名字空间以及用于由XMPP标准基金会批准的XMPP扩展协议的上下文参数的注册项的列表. 更多信息, 见 <http://xmpp.org/registrar/>.
附录H:修订历史
注意: 本协议的旧版本可能在 http://xmpp.org/extensions/attic/ 还可用
版本 1.2 (2005-11-30)
加强和概括了安全事项. (psa)
版本 1.1 (2005-10-19)
逆转了"期满"之外的条件的含义 (通过邮件列表的讨论); 纠正了特定的流特性. (psa)
版本 1.0 (2004-10-11)
根据Jabber理事会的一次投票, 提升到草案状态. (psa)
Version 0.12 (2004-09-09)
Relaxed server-to-server requirements; clarified discovery rules; removed expire-in condition. (lw)
Version 0.11 (2004-08-25)
Specified that the timestamp for an expire-at condition must be a UTC DateTime per XEP-0082; provided further explanation regarding expire-at and expire-in conditions. (lw/psa)
Version 0.10 (2004-07-14)
Changes to address Council feedback: clarified error handling and provided error examples; specified that server should validate all rule semantics before returning an error; specified that service discovery information can be cached (not necessary to send disco query before dispatching each message); added "forward" and "gateway" to values of "deliver" condition to handle redirection of messages to alternate XMPP addresses and non-XMPP systems respectively; more clearly specified processing rules for "expire-in" condition; changed milliseconds to seconds for "expire-in"; made explicit that partial JID-matching is not included for "match-resource" condition; added clarifying note to security consideration regarding "deliver" condition; corrected values of per-hop from [yes|no] to [true|false]; changed "standard" conditions to "defined" conditions and mandated that they should be supported; changed "http://jabber.org/protocol/amp#std-actions" namespace to "http://jabber.org/protocol/amp#errors". (lw/psa)
Version 0.9 (2004-04-25)
Editorial review: clarified some matters in the text; fully defined the XMPP Registrar Considerations. (psa)
Version 0.8 (2004-01-20)
Reorganized for Editorial preferences; revised error conditions to properly align with XMPP-Core (lw)
Version 0.7 (2003-12-10)
Incorported changes requested from Standards list discussions: Changed entity-to-server discovery behavior; s2s discovery behavior; Expanded application-specific error conditions; Reorganized for better presentation; Changed "per-hop" to apply to the entire ruleset; Fixed minor typos and missteps (lw)
Version 0.6 (2003-10-15)
Changed disco behavior; Changed schema to reflect customizations (lw)
Version 0.5.1 (2003-09-20)
Fixed many typos (lw)文章管理
Version 0.5 (2003-08-28)
Renamed to "amp" (thanks stpeter!); Added information about the original addressing; Added requirement for id attribute in <message/>; Restricted behavior within the "Security Considerations"; (lw)
Version 0.4 (2003-06-23)
Completely rewritten to better account for various suggested usage details and requirements; Completely reorganized to better codify the protocol(s) and their possible uses; Added more conditions; Added more actions; Added common usage scenarios (lw)
Version 0.3 (2003-04-21)
Clarified client-side processing; Removed semantics scope; Clarified "fail" action; Moved existing "use-cases" into "Usage" section in "Overview"; Added more relevant use cases; Added XMPP-style error conditions (lw)
Version 0.2 (2003-04-15)
Added XML Schema (with author's assistance). (psa)
Version 0.1 (2003-04-15)
Initial version. (lw)
2087
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
