XEP-0184:关于XMPP扩展协议和openfire中的消息回执和聊天状态

最新推荐文章于 2022-03-03 17:33:45 发布

攻城狮YanGo

最新推荐文章于 2022-03-03 17:33:45 发布

阅读量513

点赞数

分类专栏： XMPP

XMPP 专栏收录该内容

1 篇文章 0 订阅

订阅专栏

本文翻译于(https://xmpp.org/extensions/xep-0184.html)
关于XMPP扩展协议的和openfire中的消息回执和聊天状态

原因：本猿英文不太好，看原文档很吃力，所以一边理解一边翻译，然后再理解（注：可能会有翻译不好的地方，请指出来一起交流）

XEP-0184:消息传递收据

摘要	此规范为消息传递收据定义了XMPP协议扩展，消息的发送方可以通过XMPP协议扩展请求通知消息已被传递到目标接收方控制的客户机
作者	Peter Saint-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. Ack 消息（回执）
    5.5. 存档消息
6. 确定支持
7. 协议格式
8. 安全考虑
9. IANA 注意事项
10. XMPP注册注意事项
    10.1. 协议命名空间
11. XML 概要
12. 致谢

1. 简介

虽然Advanced Message Processing (XEP-0079) [1]在服务器级别提供消息确认，但它没有将该模型一直扩展到客户机。然而，有时需要客户端级别的确认，例如提供“收据”。本文档为XMPP消息传递收据定义了一种机制，它在功能上等价于Message Events (XEP-0022) [3]中的“已传递”或“显示”事件，本规范在一定程度上废除了该事件。

注意，该规范没有像在message events协议中那样区分交付和显示，部分原因是XEP-0022的实现没有做出这种区分。但是，在没有这种区别的情况下，读者需要理解，该协议只能提供在客户机上接收到消息的通知，即发送到客户机的通知，而不能提供消息已被人类用户(如果有的话)主动读取或理解的通知。因此，这个扩展在功能上等价于高级消息处理规则，尽管它使用专用的名称空间来简化客户机和中间路由器的处理。

2. 要求

本文档涉及以下要求：

使发件人能够请求已收到XMPP消息节的通知（即，传递给客户端，但不一定由人类用户读取或理解，如果有的话）。
如果需要，允许收件人提供邮件传递收据。

3. 术语

术语“content message（内容消息)”是指原始发件人希望收到收据的节。

术语“ack message(确认消息)”指的是接收方确认在客户端接收到内容消息（即，传递给客户端）的节。

4. 本协议提供的内容

该文档定义了一种协议，该协议使发送者能够通过返回确认消息来要求接收者确认收到内容消息。虽然ack消息的返回允许发送者知道内容消息已经被传送到由预期接收者控制的客户端，但是有很多原因导致发送者可能不立即或根本不接收ack消息，包括但不限于下列：

发件人将内容消息发送给收件人的纯 JID <localpart@domain.tld>，因此不知道收件人是否支持邮件传递收据协议。
发件人没有费心去确定收件人是否支持邮件传递收据协议。
收件人（或发件人寻址内容消息的特定预期资源）实际上不支持邮件传递收据协议。
目标资源支持邮件传递收据协议，但收件人的服务器将内容邮件传递给另一个不支持邮件传递收据协议的资源。
收件人的客户端收到内容消息但在生成确认消息之前遇到故障。
接收方返回ack消息，但ack消息在从接收方返回到发送方的路上丢失（例如，由于连接问题或任何一跳的软件故障）。
收件人根本不希望返回内容消息的收据。

由于这些重要的限制，该协议不提供完整或甚至部分可靠性或保证交付。因此，发件人不应对其未收到确认消息的事实加以任何含义，除非已与收件人确认接收请求将得到兑现; 但是，这样做的方法超出了本规范的范围，并且不建议在没有这些方法的情况下采取任何特定操作（例如重新发送内容消息）。[ 4 ]

因为给定内容消息可以被传递到由接收者控制的多个XMPP资源，所以内容消息的发送者需要准备好接收多个ack消息。

最后，此协议不允许发件人知道预期收件人已阅读邮件或理解邮件（如果预期收件人是人），目标收件人已处理邮件（如果预期收件人是僵尸程序）或者其他自动化系统），终端用户客户端已经向人类用户（如果有的话）提供了消息等。该协议仅提供递送收据，而不是关于呈现，处理，阅读，理解或与之相关的任何其他动作的通知。除了交付给某种客户之外的消息。

5. 何时索取收据

无论收件人的地址是纯JID <localpart@domain.tld>还是全JID <localpart@domain.tld/，发件人都可以请求收到任何非错误内容消息（聊天，群聊，标题或正常）的收据资源>。这样做是否合适或可取是另一个问题。本节提供有关何时和何时不请求收据以及每种方案中预期结果的建议。

5.1 纯JID

如果发件人只知道收件人的纯JID，则无法确定（通过服务发现（XEP-0030） [ 5 ]或实体功能（XEP-0115） [ 6 ]）目标收件人是否支持邮件传递收据协议。在这种情况下，发件人可以在向收件人的裸JID发送类型为“chat”，“headline”或“normal”的内容消息时请求收据。但是，发送方不得依赖于收到回复的确认消息。

5.2 全JID

如果发送方知道接收方的完整JID（例如，通过在线状态），它应该尝试确定（通过服务迪斯科或实体功能）该完整JID上的客户端是否支持邮件传递收据协议，然后再尝试请求收据。

如果发件人确定收件人的客户端不支持邮件传递收据协议，那么在向完整JID发送内容邮件时，它不应该请求收据，并且不得依赖于收到确认消息。

如果发件人确定收件人的客户端支持邮件传递收据协议，那么它可以在向该完整JID发送类型为“chat”，“headline”或“normal”的内容消息时请求收据。但是，即使在这种情况下，发件人也不应该依赖于收到确认消息。

5.3 群聊

在多用户聊天（XEP-0045） [ 7 ]会议室中发送类型为“群聊 ”的内容消息时，不建议请求收据，因为用于确定何时真正“接收”内容消息的逻辑房间的居住者很复杂，并且因为发送者会从房间的每个占用者那里收到一条ack消息，因此显着增加了通过房间发送的节的数量。

5.4 ACK 消息

为了防止循环，实体不得在ack消息中包含接收请求（即<request />元素）（即包含<received />元素的消息节）。

5.5 存档消息

当用户查看已存档或存储在客户端或服务器上的消息（例如，通过消息存档（XEP-0136） [ 8 ]）时，实体不得发送确认消息，仅在首次接收消息时。

6. 确定支持

如果一个实体支持Message Delivery Receipts协议，它必须通过在响应disco #info请求时包含“urn：xmpp：receipts” 的服务发现（XEP-0030） [ 5 ]功能来报告：

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

<iq from='northumberland@shakespeare.lit/westminster'
    id='disco1'
    to='kingrichard@royalty.england.lit/throne'
    type='get'>
  <query xmlns='http://jabber.org/protocol/disco#info'/>
</iq>

示例2.服务发现信息响应（个人见解：这里接收到消息后需要给服务器端发送回执，下面的回执消息是直接指向发件人的，应该是先给服务器端发送回执，然后服务器端再发送给发件人，所以下面的to应该是服务器而不是发件人，官方应该是省略的中间这一步，个人见解，有错直接指出来）

<iq from='kingrichard@royalty.england.lit/throne'
    id='disco1'
    to='northumberland@shakespeare.lit/westminster'
    type='result'>
  <query xmlns='http://jabber.org/protocol/disco#info'>
    <feature var='urn:xmpp:receipts'/>
  </query>
</iq>

支持也可以通过实体能力（XEP-0115） [ 6 ]，又名 ‘caps’

7. 协议格式

为了使发件人能够请求和收件人生成邮件传递收据，我们定义了一个由'urn：xmpp：receipts'命名空间限定的专用协议扩展。

此命名空间中有两个允许的元素：

<request /> - 由发送实体包括在内容消息中，该发送实体希望知道是否已经接收到内容消息，即，传送到由预期接收者控制的客户端。
<received /> - 由接收实体包括在ack消息中，该接收实体希望通知发送实体已经接收到内容消息，即，传送到由预期接收者控制的客户端。

具体地，如果内容消息已被传递到由预期接收者控制的客户端，则接收实体应返回包含<received />扩展的ack消息。通常，仅当客户端已经处理了内容消息时（例如，如果客户端已经向人类用户呈现内容消息或者已经完成对内容消息的任何自动处理，例如生成错误），客户端将返回收据。如果应用程序确定无法处理内容消息，则响应。但是，消息传递接收协议不提供人类用户已阅读或理解内容消息的通知，自动系统已完成处理或对消息采取行动等的通知。

以下是包含回执请求的内容消息的示例。

示例3.请求收据的内容消息

<message
    from='northumberland@shakespeare.lit/westminster'
    id='richard2-4.1.247'
    to='kingrichard@royalty.england.lit/throne'>
  <body>My lord, dispatch; read o'er these articles.</body>
  <request xmlns='urn:xmpp:receipts'/>
</message>

注意：发件人必须在每个请求收据的内容邮件中包含“id”属性，以便发件人可以正确跟踪确认消息。

当且仅当以下情况时，收件人才应生成确认消息：

它支持Message Delivery Receipts协议; 和
它被配置为全局或为此收件人返回收据。

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

示例4.消息传递收据

<message
    from='kingrichard@royalty.england.lit/throne'
    id='bi29sg183b4v'
    to='northumberland@shakespeare.lit/westminster'>
  <received xmlns='urn:xmpp:receipts' id='richard2-4.1.247'/>
</message>

当收件人发送确认消息时，它应该确保消息节只包含一个子元素，即由'urn：xmpp：receipts'命名空间限定的<received />元素。此外，它应该包含一个'id'属性，它回显内容消息的'id'属性。当然，中间实体可以在路由或传递接收消息时向消息添加其他扩展元素，例如，在延迟传递（XEP-0203） [ 9 ]中指定的<delay />元素。

8. 安全考虑

当收到邮件传递收据时，收件人可能会泄露其存在; 因此，收件人不应该向没有被授权查看其存在的发件人返回邮件传递收据。

9. IANA注意事项

作为本文档的结果，不需要与互联网号码分配机构（IANA） [ 10 ]进行任何互动。

10. XMPP注册商注意事项

10.1 协议命名空间

的XMPP注册 [ 11 ]包括其通信协议的命名空间的注册表“瓮：：XMPP协议收据”（见< https://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和Kurt Zeilenga的投入。

(声明：源文档后面还有附件说明，可以到源文档看：https://xmpp.org/extensions/xep-0184.html)

攻城狮YanGo

关注

0
点赞
踩
1

收藏

觉得还不错? 一键收藏
0
评论
XEP-0184:关于XMPP扩展协议和openfire中的消息回执和聊天状态

本文翻译于(https://xmpp.org/extensions/xep-0184.html)关于XMPP扩展协议的和openfire中的消息回执和聊天状态原因：本猿英文不太好，看原文档很吃力，所以一边理解一边翻译，然后再理解（注：可能会有翻译不好的地方，请指出来一起交流） XEP-0184:消息传递收据摘要此规范为消息传递收据定义了XMPP协议扩展，消息的发...
复制链接

扫一扫