[Standards] XEP-0184: Message Delivery Receipts and XEP-0333: Chat Markers

Marvin W xmpp at larma.de
Wed Mar 4 11:45:36 UTC 2020

XEP-0184 is doing one job, that is to notify the sender when a message
was delivered to the recipient's client. That's literally what the title
is. While in setups with MAM and SM, far less messages get lost, the
pure specification of XMPP does not guarantee every message to be
delivered to the recipient's client, so it makes sense to have this
information per message. XEP-0184 does this job perfectly well, so I
wonder why you are saying it only does half the job.

XEP-0184 is widely implemented both in receiving and sending.

The only thing I personally don't like about XEP-0184 is that it doesn't
allow to ack several messages with one message. I do agree though that
the overhead of using multiple messages isn't that much and in most
cases you don't have a bunch of messages to ack at the same time.


In contrast XEP-0333 serves a mostly different purpose: it notifies the
sender only of the last received/displayed/acknowledged message. This
means it can not be used as a means to verify that a specific message
was received, displayed or acknowledged. It also is weird that it
specifies that you have to interact with a message to acknowledge it,
but then only the last message that was acknowledged is transferred, so
the user interaction with previous messages can actually get lost. In
general, I'd say that XEP-0333 is way less mature then XEP-0184 and
serves an unclear set of goals.

The XEP-0333 displayed feature is supported by many clients. The
received feature of XEP-0333 is not often implemented in sending and
sometimes also has very weird behavior in receiving (e.g. contrary to
the XEP, only the message that was referenced in the received marker is
marked as received, not all previous messages - which makes sense
because XEP-0333 does not give any guarantee for previous messages, yet
claims to). The acknowledged feature also seems to be barely used (also
because it is questionable how to realize it UI wise).

Therefor deprecating/obsoleting XEP-0184 seems like a very bad idea to
me, I'd rather remove the received/acknowledged feature from XEP-0333
and rename it to read markers (which is the only part most implement
anyway) so we don't have an overlap in features and people stop claiming
that XEP-0184 might be obsoleted by XEP-0333. Also reducing the feature
set of XEP-0333 could make it easier to advance to Draft/Final state.

On 3/4/20 11:04 AM, Andrew Nenakhov wrote:
> But seriously, 0184 is a half-baked XEP that does only half the job
> done. XMPP is currently extremely bloated with redundant XEPs, and
> instead of trimming it down and streamlining it, you suggest setting
> an already obsolete XEP in stone. If anyone here is worried about
> bringing this protocol to the masses, it's not the way to go.

More information about the Standards mailing list