Hi Pawel,
please see my replies inline.
On 18.05.20 10:15, Pawel Chrzaszcz wrote:
Thanks for your response JC.
There are a few more details that I think would be good to clarify.
Currently when a retraction message is processed by the server, the
following criteria are used to find the original message - let's focus
on 1-to-1 chat messages:
* The |id| attribute specified in the |apply-to| element of the
retraction message has to be the same as the |id| attribute of the
|origin-id| element of the original message (required by XEP-0424).
* Both messages need to originate from the same user (also required
by the XEP).
* Both messages need to be addressed to the same user - not required
by the XEP, but it does not make sense to send a retraction
message to a different user.
This is done by the sender's server (outgoing message) and the
recipient's server (incoming message). The operation is also done
twice if there is one common server for both users.
If more than one message matches the criteria, only the most recent
one is retracted (replaced with a tombstone).
The origin ID is supposed to be globally unique, so there shouldn't ever
be more than one message that matches and if there is, then there is an
implementation error somewhere.
If no messages match the criteria, no messages are retracted.
The problem is that if the sender made a mistake and sent a message
with an incorrect origin-id or to a wrong user, there would be no
direct feedback to the sender. Do you think it is an issue?
I'm not sure whether there's anything that the server can do here. How
would it know that the retraction was sent to the wrong user? It might
be that someone is trying to retract a message that's no longer in any
server-side archive or cache, but which might still be stored
client-side, and the correct thing to do then is to simply relay the
retraction to the recipient.
Regards
JC
On Sun, May 17, 2020 at 10:14 PM JC Brand <li...@opkode.com
<mailto:li...@opkode.com>> wrote:
Hi Pawel,
sorry for taking so long to respond, this email didn't come up on
my radar.
On Mon, May 04, 2020 at 01:48:52PM +0200, Pawel Chrzaszcz wrote:
---- 8-< ----
> According to the XEP: "If a client or service implements message
> retraction, it MUST specify the 'urn:xmpp:message-retract:0'
feature in
> its service discovery information features".
> When should the server include this feature in its discovery
information?
> If a client sends a discovery request to the address of the
main XMPP
> service, should the server response contain this feature if
the server
> archives retraction messages in MAM (XEP-0313)? This should
be enough to
> satisfy the only mandatory server-side requirement of the XEP.
Yes, I agree and will update the text to make this more explicit.
> Another option would be to advertise this feature only if
messages are
> really removed or replaced with tombstones whenever a retract
message is
> received. However, support for actual removal of messages is
not mandatory
> in the XEP.
Yes, so for tombstones we can be more specific and let the XMPP
server advertise
"urn:xmpp:message-retract:0#tombstones" if it supports turning
retracted
messages into tombstones.
I'll update the XEP accordingly.
> MongooseIM would replace the messages with tombstones if such
> a feature is enabled by the user.
> I think that whatever rule is chosen, the same should apply
for a MUC
> service if message archive/retraction is enabled for it.
Yes, agreed.
Regards
JC
_______________________________________________
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
<mailto:standards-unsubscr...@xmpp.org>
_______________________________________________
_______________________________________________
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
_______________________________________________
_______________________________________________
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
_______________________________________________
