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

Kevin Smith kevin.smith at isode.com
Wed Mar 4 12:12:53 UTC 2020

At the risk of AOLing, I think I agree with pretty much everything Marvin says here.


> On 4 Mar 2020, at 11:45, Marvin W <xmpp at larma.de> wrote:
> 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.
> _______________________________________________
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: Standards-unsubscribe at xmpp.org
> _______________________________________________

More information about the Standards mailing list