XEP-0079

来自Jabber/XMPP中文翻译计划

跳转到：导航, 搜索

本文的英文原文来自XEP-0079

XEP-0079: 高级消息处理

摘要: 本文定义了一个XMPP协议扩展来实现实体请求,服务器执行的,高级XMPP message 节处理, 包括可靠数据传输, 时间敏感递送, 和临时消息的过期.

作者: Matthew Miller, Peter Saint-Andre

状态: 草案

类型: 标准跟踪

版本: 1.2

最后更新日期: 2005-11-30

注意: 这里定义的协议是XMPP标准化基金会的一个草案标准.对本协议的执行是被鼓励的,也适于布署到生产系统,但是在它成为最终标准之前可能还会有一些变动.

1 绪论
2 处理流程
- 2.1 发送者-到-服务器
  - 2.1.1 发现
  - 2.1.2 指定语义
- 2.2 服务器处理
3 条件和动作
4 正式描述
- 4.1 <amp/>根元素
- 4.2 <rule/>元素
5 示例场景
6 错误处理
- 6.1 条件
- 6.2 例子
7 实现备注
8 流特性
9 安全事项
10 IANA事项
11 XMPP注册事项
12 XML架构
13 致谢
14 附录

绪论

本文定义了一个协议让终端实体能够为一个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 有以下行为:

如果值为"exact", 仅当服务器将发送给一个没有资源ID的目标JID时,条件成立(例如, 一个多用户聊天 7 房间或离线存储).

如果值为"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)导致任何其他应答.

错误

"error"动作触发一个类型为"error"的应答 <message/> 节给发送实体. 这个 <message/> 节的 <error/> 子元素必须(MUST)包含一个 <failed-rules xmlns='http://jabber.org/protocol/amp#errors'/> 错误条件, 它本身包含触发这个动作的规则.

例子 8. 错误应答

  <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>

注意这个错误应该(SHOULD)类型为"modify", 并且一般错误条件应该(SHOULD) 是<undefined-condition xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>.

通知

"notify"动作触发一个应答 <message/> 节给发送实体. 这个 <message/> 节应该(MUST)包含元素 <amp status='notify'/>, 它本身包含触发这个动作的 <rule/> . 不像其他动作, 这个动作不超越服务器的缺省行为. 取而代之的是, 服务器在发送这个通知之后执行它的缺省行为.

例子 9. 通知应答

  <message from='hamlet.lit'
           to='bernardo@hamlet.lit/elsinore'
           id='chatty2'>
    <amp xmlns='http://jabber.org/protocol/amp'
         status='notify'
         from='francisco@hamlet.lit'
         to='bernardo@hamlet.lit/elsinore'>
      <rule action='notify' condition='deliver' value='stored'/>
    </amp>
  </message>

条件/动作联合描述

一般来说, 一个规则被视为"如果 {condition} 对于 {value} 是真就去做 {action}"; 无论如何, 为了便于理解, 本章以简单文字来描述多种多样的条件/动作联合.

递送规则

当条件是"deliver", 规则可能被描述如下:

表 3: 递送规则

动作	值	描述
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&apos;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&apos;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&apos;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>

原文控制： HTML RSS

本文的其它格式： XML PDF

附录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)

结束