[Standards] XEP-0424: Service discovery on the server side

JC Brand lists at opkode.com
Thu May 28 10:40:56 UTC 2020


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 <lists at opkode.com 
> <mailto:lists at 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-unsubscribe at xmpp.org
>     <mailto:Standards-unsubscribe at xmpp.org>
>     _______________________________________________
>
>
> _______________________________________________
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: Standards-unsubscribe at xmpp.org
> _______________________________________________



More information about the Standards mailing list