Dear list, While working on the MUC join history support in aioxmpp, I stumbled across the fact that all server implementations I tested (they have been notified) do not strip <delay/> elements, even if the @from matches the domain of the MUC service.
This is against a SHOULD in XEP-0203: > Although the recipient's server SHOULD discard a delayed delivery notation whose 'from' attribute matches the server's JabberID (or return a <not- acceptable/> error to the originator) […] When discussing the issue with the developers, we came to the conclusion that the SHOULD is not tremendously useful, since clients can not rely on this. We thought that it would be good to have a mechanism like for XEP-0359 (Unique and Stable Stanza IDs) <stanza-id/> elements. The wording would be something like this: > If an entity exposes disco#info <feature/> "urn:xmpp:delay", it MUST either strip <delay/> elements with a @from matching their address from all stanzas they process or reject those stanzas with <not-acceptable/>. It MUST NOT forward stanzas with a <delay/> with a @from matching their address. This would allow MUC services to expose that feature and clients could know that they are safe against clients spoofing history (of course, there’s still no certainty that no entity which sits between the MUC service and the client didn’t forge the timestamp, but that’s usually only the MUC service’ server and the users server, both of which the client has to trust anyways to interact with the MUC in a meaningful manner). (Since XEP-0203 is Final, I wanted to hear the list before proposing a wording via a PR.) kind regards, Jonas
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: [email protected] _______________________________________________
