xmpp xep-0184 消息回执

本人英语非常不好，这篇文章仅供参考。

转载请注明出处：http://blog.csdn.net/frj463806056/article/details/38268013

XEP-0184:消息回执

摘要：该规范定义了一个XMPP协议扩展消息回执，即消息的发送方可以请求通知消息被传递给客户端控制的接收者。

 

作者：PeterSaint-Andre, Joe Hildebrand

版权：© 1999 - 2014 XMPP标准基础. SEELEGAL NOTICES.（看法律声明）

状态：草稿

排版：标准化过程

版本：1.2

最后更新：2011-03-01

 

注意：此处定义的协议是一个标准草案的XMPP标准的基础。履行协议支持和适合部署在生产系统中，但是对协议的一些修改之前可能是最后一个标准。

 

目录：

1.   介绍

2.   需求

3.   术语

4.   该协议提供了什么

5.   当请求交付

5.1        纯JID

5.2        全JID

5.3        群聊

5.4        应答消息

5.5        存档的消息

6.   确定支持

7.   验证方案的格式

8.   安全考虑

9.   IANA 注意事项

10. XMPP 注册注意事项

10.1       协议命名空间

11.XML 概要

12.确认

 

 

附件：

      A:文件信息

      B:作者信息

      C:法律告示

      D:与XMPP关系

      E:讨论地点

      F:需求一致性

      G:注释

      H:修订历史

 

 

1介绍

然而Advanced Message Processing (XEP-0079) 先进的消息处理（XEP-0079） 在服务器级提供消息确认，它不扩展模型到客户端。然而，有时客户端级别需要确认，例如提供“收到（receipts）”。本文定义了XMPP消息传递机制凭证，它在功能上相当于”已递送(delivered)”或“显示（displayed）”事件在消息事件MessageEvents (XEP-0022)，这种规范部分废止。

注意，这个规范并不区分已递送和显示，完成的消息事件的协议，部分原因在于没有实现xep-0022导致的区别。然而，在不注意这样一个区别，读者需要了解这个协议在客户已经收到信息，只能提供一个通知信息，即交付给客户，而不是消息一直被人类用户（如果有的话）活跃的阅读或理解。因此这个扩展功能相当于一个先进的信息处理规则的“收到”，尽管它通过客户端和中间路由器使用一个专用的命名空间来简化处理。

 

 

2需求

本文地址遵循以下需求：

1.   使发送方请求XMPP的通知信息节已经收到（即，交付给客户，但不一定被人类用户阅读或者理解，如果有的话）。

2.   如果需要表示“收到“，让收件人提供消息传递。

 

 

3术语

“内容信息”这一术语是指节的原始发件人想收到一个收据

“应答消息”这一术语指的是节的接收方确认收到消息的内容（即客户收到）

 

4该协议提供了什么

本文档定义一个协议，使发送方要求收件人收到消息后通过返回一个应答消息。

虽然由收件人ack返回消息让发送方知道内容消息被传递给客户机，但发件人可能有很多原因不能立即收到ack消息，包括但不限于以下：

·发送方向接收者发送纯[e-mail]的处理内容消息，因此收件人不知道支持消息交付收据协议。

·发送方不愿确定收件人是否支持消息交付数据协议。

·收件人（或特定目的资源消息发送方的地址内容）实际上并不支持消息交付数据协议。

·目的资源支付消息交付收据协议，但接收方的服务器提供内容消息到另一个不支持消息交付收据协议资源。

·收件人端收到内容消息但是生成ack消息之前经历了一个故障。

·收件人返回一个应答消息，但是ack消息丢失在从收件人到发送方的途中。（如：由于连接问题或者软件故障跳过）

·收件人根本不希望返回收据内容信息。

 

由于这些重要的限制，该协议没有提供完整，甚至部分交付可靠性或担保。因此没有收到ack的消息发送方不应归咎于任何意义的事实，除非它已经与收件人收到请求将付款；然而，这样的方法超出了本规范的范围，没有这样的方法不建议采取任何特殊措施（如：重新发送消息的内容）。

 

因为由收件人控制对于一个给定的消息内容分发到多个XMPP资源它是可能的。

 

最后，这个协议不允许发送方知道收件人阅读或理解消息的消息（如果收件人是一个人），收件人已处理消息（如果收件人是一个机器人或其他自动化系统），最终用户客户端提出了人类用户的消息（如果有的话），等等。本协议提供交付收据，不通知表示处理、阅读、理解或任何其他行动以外的相关消息交付给客户。

 

5当请求交付

发送方可以请求任何non-error收据内容信息（聊天，组聊天，标题或标准的）无论收件人的地址是一个纯[e-mail]或一个全[e-mail]/resource。这样做是否合适或明智是另一个问题。本节提供建议时，不要求收据，并在每个场景期待结果。

 

5.1纯JID

如果发送方只知道收件人的纯JID，它不能确定（通过服务发现（xep-0030）或实体功能(Service Discovery (XEP-0030) [5] or EntityCapabilities (XEP-0115) [6])）。收件人是否支持消息交付收据协议。在这种情况下，发送方可以请求收据发送内容的信息类型时“chat”，“headline”,“normal”给收件人的纯JID。然而，发送者必须不依赖于收到ack消息回复。

5.2全JID

如果发送方知道一个全JID的收件人（如：出席），它应该试图确定（通过服务迪斯科或实体功能）是否在全JID支持客户端消息交付收据协议之前请求收据。

如果发送方确定收件人的客户机不支持消息交付收据协议就不应该请求收据发送内容的信息时，完整的JID和不能取决于收到ack消息

5.3组聊天

发送内容的信息类型为“groupchat”时不推荐请求收据，在一个多用户聊天（xep-0045 Multi-User Chat (XEP-0045) ）的房间，因为决定当一个内容消息的逻辑确实是“收到”，所有房间的人是复杂的，并且由于发送者将从每个房间的主人获得一个ack消息，从而显著增加通过房间发送节的数量。

5.4应答消息

为了防止循环，一个实体必须不包括收到请求（即，<request />元素）在一个应答消息。（一个消息节，包括<received />元素）

5.5存档的消息

当用户视图的消息存档或存储在客户机或服务器上一个实体不能发送ack消息（例如：通过消息存档（sep-0136 Message Archiving (XEP-0136) ））,只有当第一次接收消息时才发送。

 

6确定支持

如果一个实体支持消息交付收据协议，必须报告，包括服务发现（xep-0030 Service Discovery (XEP-0030）的特点“urn:xmpp:receipts” 以响应disco#info 的请求。

示例1.初始的服务发现信息请求

<iq from='[e-mail]/westminster'
    id='disco1'
    to='[e-mail]/throne'
    type='get'>
  <query xmlns='http://jabber.org/protocol/disco#info'/>
</iq>

 

示例2.服务发现信息并响应

<iq from='[e-mail]/throne'    id='disco1'    to='[e-mail]/westminster'    type='result'>  <query xmlns='http://jabber.org/protocol/disco#info'>    <feature var='urn:xmpp:receipts'/>  </query></iq>

 

支持通过实体也可以确定功能（xep-0115 Entity Capabilities (XEP-0115)），选择”caps。

 

7验证方案的格式

为了使发送方为收件人请求和生成消息交付收据，我们定义了一个专门的协议扩展合格的’rn:xmpp:receipts’的命名空间。

在这个命名空间中有两个许可的元素：

      ·<request /> --消息内容包括在被发送的实体中，希望知道内容消息已经被收到，即交付给被接收者控制的客户端。

      ·<received />--ack消息包含在一个接收实体中，希望告知发送实体内容消息已经收到，即，交付给被接收者控制的客户端。

 

具体来说，如果内容消息被传递给被预期的接收者控制的客户端，接收实体应当返回ack消息包含<received/>扩展。一般来说，一个客户只能返回一个收据，如果客户处理消息的内容（如，如果客户端提供内容消息被人类用户或任何自动化处理内容的消息完成，比如如果应用程序确定消息内容不能被处理生成一个错误响应。）然而，消息交付收据协议没有提供通知人类用户阅读或理解内容的消息或一个自动化的系统已完成或采取行动的消息，等等。

下面是一个例子包括请求回执的内容消息。

示例3请求接收的一个内容消息

<message    from='[e-mail]/westminster'    id='richard2-4.1.247'    to='[e-mail]/throne'>  <body>My lord, dispatch; read o'er these articles.</body>  <request xmlns='urn:xmpp:receipts'/></message>  

 

注意：发送方在每个内容信息必须包括一个“id”属性，请求一个收据，以便发送方可以正常跟踪应答消息。

收件人将生成一个ack消息，当且仅当

1.   它支持消息交付收据协议

2.   它被配置为返回收据，全球或收件人。

否则不能返回一个收据，不应该返回一个错误。

 

示例4消息交付收据

<message    from='[e-mail]/throne'    id='bi29sg183b4v'    to='[e-mail]/westminster'>  <received xmlns='urn:xmpp:receipts' id='richard2-4.1.247'/></message>

 

当收件人发送ack消息，应该确保消息节只包含一个子元素，即<received/>元素合格的命名空间“urn:xmpp:receipts” 。此外，它应该包括一个”id“属性的内容信息。自然，中间实体可能其他扩展元素添加到消息路由或交付收据信息时，如：<delay/>元素中指定的延期交货（xep-0203DelayedDelivery (XEP-0203)）。

 

 

8安全考虑

收件人当返回消息交付收据有可能存在泄露；因此，接收方不应返回消息交付收据给发送者，不是否则授权查看它的存在。

 

 

9 IANA 注意事项

不与互联网的交互分配机构（IANA）由于本文档是必要的。

 

 

10 XMPP 注册注意事项

10.1协议命名空间

XMPP注册包含“urn:xmpp:receipts” 在注册中心的协议命名空间（见：http://xmpp.org/registrar/namespaces.html）。

 

11 XML概要

<?xml version='1.0' encoding='UTF-8'?><xs:schema    xmlns:xs='http://www.w3.org/2001/XMLSchema'    targetNamespace='urn:xmpp:receipts'    xmlns='urn:xmpp:receipts'    elementFormDefault='qualified'>  <xs:annotation>    <xs:documentation>      The protocol documented by this schema is defined in      XEP-0184: http://xmpp.org/extensions/xep-0184.html    </xs:documentation>  </xs:annotation>  <xs:element name='received'>    <xs:complexType>      <xs:simpleContent>        <xs:extension base='empty'>          <xs:attribute name='id' type='xs:string' use='optional'/>        </xs:extension>      </xs:simpleContent>    </xs:complexType>  </xs:element>  <xs:element name='request' type='empty'/>  <xs:simpleType name='empty'>    <xs:restriction base='xs:string'>      <xs:enumeration value=''/>    </xs:restriction>  </xs:simpleType></xs:schema>  

 

 

12确认

感谢Steven te Brinke, Bruce Campbell, Joe Kemp, Kevin Smith, RemkoTronçon, Matthew Wild, and Kurt Zeilenga的录入