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 the standards@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 to standards-leave@xmpp.org