Hey hey, On Thu, 19 Dec 2024 at 09:21, Daniel Gultsch <[email protected]> wrote:
> 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 [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 so. On the subject of whether it could be included within the scope of "last message editing", I think that's a clear no - "changing" a message to be retracted is a very different concept, with different implications, than "removing a message". > 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? > > No! But only because I don't really do much client stuff. It's possible, though, and if I do need to [try to] retract a message, it'll be with this specification. > 4. Do you have any security concerns related to this specification? > > Always! I think in this case the Security Considerations are quite light. In particular, there is no discussion of how a message might be deliberately retracted as a form of abuse - this is perhaps worst in cases where the tombstone support is implemented. In general, I think any specification which seeks to "change history" ought to have this as a consideration. > 5. Is the specification accurate and clearly written? > Yes. 6. Do I think it gets everything as right as can be before we set it in stone? I'm curious about the use of origin-id here. I thought from previous discussions we'd decided that origin-id only had value within certain MUC cases; whereas the origin-id is explicitly only for 1:1 messaging here. Does this mean any message to be retracted has to use an origin-id, and (therefore) a client must send all 1:1 messages with an origin-id? Do we want to make it use the stanza id attribute instead? If not, why not? It seems that XEP-0308 handles this fine without the use of origin-id. What do existing clients do? Do they all really inject an origin-id for this one case (are there any others?) Dave.
_______________________________________________ Standards mailing list -- [email protected] To unsubscribe send an email to [email protected]
