[Standards] Carbons of XEP-0184 Receipts (Was: XEP-0280 (Carbons) proposals)
georg at op-co.de
Wed Nov 7 09:19:44 UTC 2018
So I spent another half hour today debugging why the green checkmark on
my outgoing messages only appeared on two of my three clients for one
contact, and only on one of my clients for another contact(*). It turned
out to be standard compliant behavior.
XEP-0184 indicates (but doesn't mandate) type=normal for Receipts, which
is followed by most implementations. And thus, Receipts don't fall under
| A <message/> is eligible for carbons delivery if it is of type
| "normal" and it contains a <body> element.
There is an old PR to improve the Carbons rules
<https://github.com/xsf/xeps/pull/434> but it doesn't address this
* Georg Lukas <georg at op-co.de> [2017-06-01 13:55]:
> Modern clients send bodyless messages with 0085 CSNs and 0184 ACKs to
> provide additional communication metadata. There is value in
> carbon-copying both of these message types, but there might be existing
> use-cases for bodyless messages where carbon-copying would do harm.
> Because I don't know all the use-cases for bodyless messages, I struggle
> to provide a rule for how to handle CSNs and ACKs.
As XEP-0409 (IM Routing-NG) doesn't see wide adoption yet, I'd like to
move forward with improving 0280 / 0184, by one of the following:
a) make 0280 apply to all 'normal' messages to a bare JID (akin to
Routing-NG) and state in 0184 that the Receipt should go to bare-JID.
b) explicitly mention in 0184 that for chat content the Receipt should
also be of type=chat.
c) All of the above.
As 0280 rules are weasel-worded, changing them doesn't require a
namespace bump. In 0184 there is no mandate of the recipient JID form
(bare/full) nor the message type, so adding Business Rules for those
shouldn't require a bump either.
(*) One of my contacts sends Receipts to the bare JID, the other to the
full JID. Without carbons, normal RFC6121 rules apply. As one of my
devices has a negative priority, it's not receiving the to-bare message.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 833 bytes
Desc: not available
More information about the Standards