Hi Goffi and Daniel, Thank you both for the detailed feedback. I've made a PR which addresses your feedback: https://github.com/xsf/xeps/pull/1551 Goffi wrote:
I just find that the section "The Sender MUST NOT send a retraction request for a message with non-messaging payloads. [...]" could state more explicitly that things like SFS (XEP-0447) can be removed, because the <body> is only a fallback there, and it's not clear if it's a messaging payload or not.
Agreed. The Business Rules now define "non-messaging payloads" as messages that serve as a transport for protocol signalling and aren't displayed as messages to the user. And we now state that a message that conveys user-visible content is considered to have a messaging payload, even when that content lies outside the <body> (with XEP-0447 mentioned as an example). Daniel wrote:
However if there is no suggested limited and no way to discover that in the XEP than different clients may pick very different limits (ranging from none to 5 seconds)
I've now added a way to discover a retraction time limit. An entity that enforces one SHOULD advertise a `max-age` via XEP-0128 in its disco#info response.
I have some concerns with regards to the fallback message. If you deliberately put some completely unrelated content into the body clients that support retractions will render that very differently (meaning not at all) from clients that do support retraction. This can especially be a problem (and this depends on the implementation) if the retraction is for a message that simply doesn't exist. I'm worried that some clients will then not render anything.
Good catch. The Business Rules now say that a supporting client MUST NOT display the <body> of a message containing a <retract/> element regardless of whether the body carries a XEP-0428 fallback marker or not. And also when no message matching the given id can be found. There's also a new Security Considerations section which describes the abuse you outlined: unrelated fallback content combined with an id that matches no message.
Especially now that I have mentioned the downside of fallbacks for reactions I'm unsure what the real upside is
I think the fact that someone retracts a message is potentially important information (a signal of intent that can change the meaning of a conversation) and so should be communicated to non-supporting clients. It also helps non-supporting servers to archive the message (based on the `body`).
origin id is still mentioned in https://xmpp.org/extensions/xep-0424.html#usecase [...] This should be message id
Fixed. I hereby request another Last Call round for this XEP. Thanks again for the reviews. JC On 2/4/25 18:48, Goffi wrote:
Le jeudi 19 décembre 2024, 10:21:07 heure normale d’Europe centrale Daniel Gultsch a écrit :
This message constitutes notice of a Last Call for comments on XEP-0424.
Title: Message Retraction Abstract: This specification defines a method for indicating that a message should be retracted.
URL:https://xmpp.org/extensions/xep-0424.html
This Last Call begins today and shall end at the close of business on 2025-01-06.
Please consider the following questions during this Last Call and send your feedback to thestandards@xmpp.org discussion list:
1. Is this specification needed to fill gaps in the XMPP protocol stack or to clarify an existing protocol? Yes, I think it's a different use case that message correction (in Libervia, I show history for message correction, and just a tombstone for retraction).
2. Does the specification solve the problem stated in the introduction and requirements? yes
3. Do you plan to implement this specification in your code? If not, why not? It's implemented in Libervia.
4. Do you have any security concerns related to this specification? No more that was has already been stated.
5. Is the specification accurate and clearly written? Globally yes.
I just find that the section "The Sender MUST NOT send a retraction request for a message with non-messaging payloads. For example, a sender MUST NOT send a retraction for a roster item exchange request or a file transfer part." could state more explicitly that things like SFS (XEP-0447) can be removed, because the <body> is only a fallback there, and it's not clear if it's a messaging payload or not.
With my council hat on, I'll most probably vote +1 on this one, I'm just waiting for Daniel feedback and mine above to be resolved. And in any case, thanks to the authors for their contributions.
_______________________________________________ Standards mailing list --standards@xmpp.org To unsubscribe send an email tostandards-leave@xmpp.org