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

Dave Cridland dave at cridland.net
Fri Aug 31 11:09:37 UTC 2012

I'm going to stagger in horribly late on this.

Firstly, I think this XEP is warranted - message correction is a useful
feature, and whilst it's a technical solution to a social problem, I really
don't see why this is an argument against it - if it weren't ultimately
solving a social problem at all, that would be a powerful argument against

Secondly, I, like many people, am concerned with the other social problems
this technology may introduce, as well as the technical problems:

1) As written, the specification allows replacement of an IBB stanza with
an IM message - possibly. This concerns me. The specification appears to
not only allow this, but encourage its support - I think that changes of
purpose should be ruled out of scope, very firmly.

2) I'm concerned that silent correction of previous messages could be
dangerous. The last received message restriction is probably unwarranted,
but needs to be balanced with a warning to implementors that the message
flow will need to be maintained, as well as replacements being clearly
indicated. That is, in Kurt's scenario, you should see:

Kurt: "Question?"
Me: "Yes"
Kurt: "Really?"

And when the correction comes in:

Kurt: "Question?"
*REPLACED* Me: "Yes"
Kurt: "Really?"
Me: "Yes"

Or some such - that is, replacing messages other than the last in a message
stream should not remove the original from view.

I'm still concerned that replacing any but the author's last message is
likely to cause problems with accurately presenting the data.

Essentially, this should be heavily discussed in the Security
Considerations section.

3) The naive fallback case is somewhat unpleasant, as PSA comments. My
thought is that if the messages were specifically annotated in the body of
the message, this would not be an issue:

<body>Correction: But soft, what light through yonder window breaks?</body>
<replace id='bad1' prefix='Correction: ' xmlns='...'/>

Although this needs some thought to handle XHTML-IM, and it may prove
impossible - though we've done worse things with FLOTs before.

Overall, although I'm relatively happy with the XEP as-is, I think it needs
more thought in terms of the more esoteric uses it might receive before
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20120831/f1af638f/attachment.html>

More information about the Standards mailing list