[Standards] LAST CALL: XEP-0308 (Last Message Correction)

Mark Rejhon markybox at gmail.com
Thu Sep 6 21:34:12 UTC 2012

On Thu, Sep 6, 2012 at 2:02 AM, Dave Cridland <dave at cridland.net> wrote:
> Oh, if you take it out of context like that, then yes... I was talking about
> my suggestion of a removable prefix

Ok, my apologies -- I didn't realize it was sender-appended prefixes.
Much like the "me" XEP-0245, where "/me " is a prefix transmitted as
cleartext by the sender.

In that case, I'm not sure I like the transmitted removable prefix
idea, either.  I generally prefer it be a recipient-appended prefix
(if prefixes are used), not a sender-appended-and-transmitted prefix.
  I feel that implementations should decide how to highlight
corrections and edits, and there's many completely reasonable ways to
highlight edits (recipient-added prefixes, highlights, color codes,
"Edited" tags, etc).

For example, one implementation of doing things with XEP-0308 is that
when edits are made, the message can also be moved orthographically to
the bottom of the history and an "Edited" tag added.  Enhancements in
a specific client, such as selecting (or even mouseovering) the Edited
tag, could possibly expand a list of previous versions of the same
message and the timestamps for them.   All of that can automatically
be done by a client implementation, without modifications to XEP-0308.

Then again, I also see the legitimacy of a removable prefix in
backwards-compatible situations, including MUC (clients with and
without 0308 support).   As long as an algorithm is clearly defined
for prefixes transmitted in XHTML-IM -- the simplest algorithm for
prefix removal in XHTML-IM is simply iterate through the XHTML tree to
the first non-blank innertext, and remove the leading prefix from it
if a match for the prefix is found at the first non-blank innertext in
the XHTML-IM tree.     (I wonder if that's how XEP-0245 works over

More information about the Standards mailing list