<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, 4 Mar 2020 at 11:45, Marvin W <<a href="mailto:xmpp@larma.de">xmpp@larma.de</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">XEP-0184 is doing one job, that is to notify the sender when a message<br>
was delivered to the recipient's client. That's literally what the title<br>
is. While in setups with MAM and SM, far less messages get lost, the<br>
pure specification of XMPP does not guarantee every message to be<br>
delivered to the recipient's client, so it makes sense to have this<br>
information per message. XEP-0184 does this job perfectly well, so I<br>
wonder why you are saying it only does half the job.<br>
<br>
XEP-0184 is widely implemented both in receiving and sending.<br>
<br></blockquote><div><br></div><div>Agreed.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
The only thing I personally don't like about XEP-0184 is that it doesn't<br>
allow to ack several messages with one message. I do agree though that<br>
the overhead of using multiple messages isn't that much and in most<br>
cases you don't have a bunch of messages to ack at the same time.<br>
<br></blockquote><div><br></div><div>Broad agreement to that - I don't see the inability to send a receipt for and explicit set of multiple messages as a problem, and I think it would massively complicate the protocol for little gain.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
---<br>
<br>
In contrast XEP-0333 serves a mostly different purpose: it notifies the<br>
sender only of the last received/displayed/acknowledged message. This<br>
means it can not be used as a means to verify that a specific message<br>
was received, displayed or acknowledged. It also is weird that it<br></blockquote><div><br></div><div>Received: This has potential problems since message loss would defeat the point, but in general, recent XMPP deployments tend to get messages in sequence to a client, or not at all - so it is a very close approximation. A single message lost would still be a problem, of course. So overall, I can go along with '184 instead.</div><div><br></div><div>Displayed: A message displayed really implies that all previous messages have been displayed to all intents and purposes - they might not have been rendered on screen depending on UX, but the existence of the message has been displayed to the user in some form, I'm fine with that. A lost message would of course break this - but I'm working on the assumption that we handle this by '184.</div><div> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
specifies that you have to interact with a message to acknowledge it,<br>
but then only the last message that was acknowledged is transferred, so<br>
the user interaction with previous messages can actually get lost. In<br>
general, I'd say that XEP-0333 is way less mature then XEP-0184 and<br>
serves an unclear set of goals.<br></blockquote><div> </div><div>I think Acknowledged is badly thought through. I think we want acknowledged as per-message, but perhaps I just don't understand the expected UX here at all.</div><div><br></div><div>I'd want to explicitly request an acknowledgement for certain messages, I think - and I'd be fine if that implied displayed, as now.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
The XEP-0333 displayed feature is supported by many clients. The<br>
received feature of XEP-0333 is not often implemented in sending and<br>
sometimes also has very weird behavior in receiving (e.g. contrary to<br>
the XEP, only the message that was referenced in the received marker is<br>
marked as received, not all previous messages - which makes sense<br>
because XEP-0333 does not give any guarantee for previous messages, yet<br>
claims to). The acknowledged feature also seems to be barely used (also<br>
because it is questionable how to realize it UI wise).<br>
<br></blockquote><div><br></div><div>We definitely only do displayed (but we operate in an environment with one server and '198 on every client, so message loss is really not an issue).</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Therefor deprecating/obsoleting XEP-0184 seems like a very bad idea to<br>
me, I'd rather remove the received/acknowledged feature from XEP-0333<br>
and rename it to read markers (which is the only part most implement<br>
anyway) so we don't have an overlap in features and people stop claiming<br>
that XEP-0184 might be obsoleted by XEP-0333. Also reducing the feature<br>
set of XEP-0333 could make it easier to advance to Draft/Final state.<br>
<br></blockquote><div><br></div><div>I'd like to:</div><div><br></div><div>* Drop received. I like the notion, but I don't think it provides solid guarantees, and the overlap with '184 isn't persuading me it's worth keeping.</div><div>* Keep Displayed. Works well and widely implemented.</div><div>* Either drop Acknowledged, or make it an explicit request on a marked message.</div><div><br></div><div>The downside of replacing '333's Received with '184 is that '333's Displayed (and Acknowledged) no longer automatically imply received, which is a little frustrating. But I don't really see an alternative.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
On 3/4/20 11:04 AM, Andrew Nenakhov wrote:<br>
> But seriously, 0184 is a half-baked XEP that does only half the job<br>
> done. XMPP is currently extremely bloated with redundant XEPs, and<br>
> instead of trimming it down and streamlining it, you suggest setting<br>
> an already obsolete XEP in stone. If anyone here is worried about<br>
> bringing this protocol to the masses, it's not the way to go.<br>
> <br>
_______________________________________________<br>
Standards mailing list<br>
Info: <a href="https://mail.jabber.org/mailman/listinfo/standards" rel="noreferrer" target="_blank">https://mail.jabber.org/mailman/listinfo/standards</a><br>
Unsubscribe: <a href="mailto:Standards-unsubscribe@xmpp.org" target="_blank">Standards-unsubscribe@xmpp.org</a><br>
_______________________________________________<br>
</blockquote></div></div>