Hello all,
1. Is this specification needed to fill gaps in the XMPP protocol
stack or to clarify an existing protocol?
Yes. While I agree there is some overlap with XEP-0308, this is not
limited to the last message. I know that in practice, XEP-0308 works for
older messages too, but the XEP title explicitly forbids it, doesn't it?
Also, I believe clients could benefit, UX-wise, from treating edits
(LMC) differently than retractions, e.g., hide notifications for
retracted messages. And finally, tombstones are not covered by anything
else, AFAIK.
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 slidge. I also drafted a patch for gajim a while
ago, but it's still a WIP.
4. Do you have any security concerns related to this specification?
Maybe the XEP is not the place for this, but I would like clients to
make it explicit that this is a "convenience" feature and not a a
security one. Something like "consider anything you have sent (password,
credit card number…) as now disclosed, retracting the message is not
enough" (words are hard).
5. Is the specification accurate and clearly written?
Yes. I have a minor concern with Example 4 and its body "This person
attempted to retract a previous message, but it's unsupported by your
client.". I believe using a XEP-0428 fallback indication that the body
is a fallback for XEP-0424, and setting this body to "/me retracted this
message" is the way to go — this is how I implemented it in slidge. ;-)
-- nicoco
_______________________________________________
Standards mailing list -- [email protected]
To unsubscribe send an email to [email protected]
