Re: LAST CALL: XEP-0424 (Message Retraction)
JC Brand <[email protected]> Fri, 3 Jul 2026 12:30:25 +0200
| Newsgroups | gmane.network.jabber.standards-jig |
|---|---|
| Message-ID | <[email protected]> |
This is a multi-part message in MIME format. --===============4696649248834267056== Content-Type: multipart/alternative; boundary="------------3dlwAA7v66f6ddHZIRGne45K" Content-Language: en-US This is a multi-part message in MIME format. --------------3dlwAA7v66f6ddHZIRGne45K Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable 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=C3=A9cembre 2024, 10:21:07 heure normale d=E2=80=99Europe= centrale Daniel > Gultsch a =C3=A9crit : >> 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 [email protected] 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 Libe= rvia, I > show history for message correction, and just a tombstone for retractio= n). > >> 2. Does the specification solve the problem stated in the introduction >> and requirements? > yes > > =20 >> 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 req= uest for > a message with non-messaging payloads. For example, a sender MUST NOT s= end 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, b= ecause > the <body> is only a fallback there, and it's not clear if it's a messa= ging > payload or not. > > With my council hat on, I'll most probably vote +1 on this one, I'm jus= t > waiting for Daniel feedback and mine above to be resolved. And in any c= ase, > thanks to the authors for their contributions. > > _______________________________________________ > Standards mailing list [email protected] > To unsubscribe send an email [email protected] --------------3dlwAA7v66f6ddHZIRGne45K Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <!DOCTYPE html> <html> <head> <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3DUTF= -8"> </head> <body> <p>Hi Goffi and Daniel,<br> <br> Thank you both for the detailed feedback.<br> <br> I've made a PR which addresses your feedback:<br> <a class=3D"moz-txt-link-freetext" href=3D"https://github.com/xsf/x= eps/pull/1551">https://github.com/xsf/xeps/pull/1551</a><br> <br> Goffi wrote:<br> > I just find that the section "The Sender MUST NOT send a retraction<br> > request for a message with non-messaging payloads. [...]" could state<br> > more explicitly that things like SFS (XEP-0447) can be removed,<br> > because the <body> is only a fallback there, and it's not clear if<br> > it's a messaging payload or not.<br> <br> Agreed. The Business Rules now define "non-messaging payloads" as<b= r> messages that serve as a transport for protocol signalling and aren't<br> displayed as messages to the user.<br> <br> And we now state that a message that conveys user-visible content is<br> considered to have a messaging payload, even when that content lies<br> outside the <body> (with XEP-0447 mentioned as an example).<b= r> <br> Daniel wrote:<br> > However if there is no suggested limited and no way to discover that<br> > in the XEP than different clients may pick very different limits<br> > (ranging from none to 5 seconds)<br> <br> I've now added a way to discover a retraction time limit. An entity<br> that enforces one SHOULD advertise a `max-age` via XEP-0128 in its<= br> disco#info response.<br> <br> > I have some concerns with regards to the fallback message. If you<br> > deliberately put some completely unrelated content into the body<br> > clients that support retractions will render that very differently<br> > (meaning not at all) from clients that do support retraction. This<br> > can especially be a problem (and this depends on the implementation)<br> > if the retraction is for a message that simply doesn't exist. I'm<br> > worried that some clients will then not render anything.<br> <br> Good catch. The Business Rules now say that a supporting client MUST<br> NOT display the <body> of a message containing a <retract/> element<br> regardless of whether the body carries a XEP-0428 fallback marker or not.<br> And also when no message matching the given id can be found.<br> <br> There's also a new Security Considerations section which describes<= br> the abuse you outlined: unrelated fallback content combined with an id<br> that matches no message.<br> <br> > Especially now that I have mentioned the downside of fallbacks for<br> > reactions I'm unsure what the real upside is<br> <br> I think the fact that someone retracts a message is potentially<br> important information (a signal of intent that can change the meaning<br> of a conversation) and so should be communicated to non-supporting<= br> clients.<br> <br> It also helps non-supporting servers to archive the message (based on the<br> `body`).<br> <br> > origin id is still mentioned in<br> > <a class=3D"moz-txt-link-freetext" href=3D"https://xmpp.org/ex= tensions/xep-0424.html#usecase">https://xmpp.org/extensions/xep-0424.html= #usecase</a><br> > [...] This should be message id<br> <br> Fixed.<br> <br> I hereby request another Last Call round for this XEP.<br> <br> Thanks again for the reviews.<br> JC<br> <br> </p> <div class=3D"moz-cite-prefix">On 2/4/25 18:48, Goffi wrote:<br> </div> <blockquote type=3D"cite" cite=3D"mid:2211835.irdbgypaU6@tazar3"> <pre wrap=3D"" class=3D"moz-quote-pre">Le jeudi 19 d=C3=A9cembre 20= 24, 10:21:07 heure normale d=E2=80=99Europe centrale Daniel=20 Gultsch a =C3=A9crit : </pre> <blockquote type=3D"cite"> <pre wrap=3D"" class=3D"moz-quote-pre">This message constitutes n= otice 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: <a class=3D"moz-txt-link-freetext" href=3D"https://xmpp.org/extensio= ns/xep-0424.html">https://xmpp.org/extensions/xep-0424.html</a> 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 <a class=3D"moz-txt-link-abbreviated" href=3D"mailto= :[email protected]">[email protected]</a> discussion list: 1. Is this specification needed to fill gaps in the XMPP protocol stack or to clarify an existing protocol? </pre> </blockquote> <pre wrap=3D"" class=3D"moz-quote-pre"> Yes, I think it's a different use case that message correction (in Liberv= ia, I=20 show history for message correction, and just a tombstone for retraction)= . </pre> <blockquote type=3D"cite"> <pre wrap=3D"" class=3D"moz-quote-pre">2. Does the specification = solve the problem stated in the introduction and requirements? </pre> </blockquote> <pre wrap=3D"" class=3D"moz-quote-pre"> yes =20 </pre> <blockquote type=3D"cite"> <pre wrap=3D"" class=3D"moz-quote-pre">3. Do you plan to implemen= t this specification in your code? If not, why not? </pre> </blockquote> <pre wrap=3D"" class=3D"moz-quote-pre"> It's implemented in Libervia. </pre> <blockquote type=3D"cite"> <pre wrap=3D"" class=3D"moz-quote-pre">4. Do you have any securit= y concerns related to this specification? </pre> </blockquote> <pre wrap=3D"" class=3D"moz-quote-pre"> No more that was has already been stated. </pre> <blockquote type=3D"cite"> <pre wrap=3D"" class=3D"moz-quote-pre">5. Is the specification ac= curate and clearly written? </pre> </blockquote> <pre wrap=3D"" class=3D"moz-quote-pre"> Globally yes. I just find that the section "The Sender MUST NOT send a retraction reque= st for=20 a message with non-messaging payloads. For example, a sender MUST NOT sen= d a=20 retraction for a roster item exchange request or a file transfer part." c= ould=20 state more explicitly that things like SFS (XEP-0447) can be removed, bec= ause=20 the <body> is only a fallback there, and it's not clear if it's a m= essaging=20 payload or not. With my council hat on, I'll most probably vote +1 on this one, I'm just=20 waiting for Daniel feedback and mine above to be resolved. And in any cas= e,=20 thanks to the authors for their contributions.</pre> <br> <fieldset class=3D"moz-mime-attachment-header"></fieldset> <pre wrap=3D"" class=3D"moz-quote-pre">____________________________= ___________________ Standards mailing list -- <a class=3D"moz-txt-link-abbreviated" href=3D"m= ailto:[email protected]">[email protected]</a> To unsubscribe send an email to <a class=3D"moz-txt-link-abbreviated" hre= f=3D"mailto:[email protected]">[email protected]</a> </pre> </blockquote> </body> </html> --------------3dlwAA7v66f6ddHZIRGne45K-- --===============4696649248834267056== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ Standards mailing list -- [email protected] To unsubscribe send an email to [email protected] --===============4696649248834267056==--