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

Mark Rejhon markybox at gmail.com
Tue Aug 14 15:45:04 UTC 2012

On Mon, Aug 13, 2012 at 1:06 PM, Kurt Zeilenga <Kurt.Zeilenga at isode.com> wrote:
>> The spec originally allowed previous non-last correction, and the community cried foul
> I found a thread that occurred during the initial consideration of the XEP (when it was proposed), starting at:
>    http://mail.jabber.org/pipermail/standards/2011-November/025394.html
> I noticed that the original title did say "Last".
> I see Ben Langfeld arguing that it shouldn't be restricted to last.
> I see Dave Cridland being "mildly terrified" about allowing change to any previous message.
> And your response.
> Not much crying.  Was there some other thread?

Ok, perhaps it's just illustrates the need to be very plainly clear
within Security Considerations -- about the privacy/security
implications of permitting message correction, and to mention that the
UI needs to be very plainly clear that message correction is going on.
  In fact, message correction doesn't have to "defacto" replace the
old stanza, but display it as an addendum (with a very clear "EDITED"
tag or icon).    Discussion forums, Facebook, etc, allowing editing --
they often to give you access to old versions of the text (revision
history accessible by end user).   And the edited version can be color
coded out.  Implementers are smart enough to be creative here, but we
don't need to include such implementation detail.

So I'd say, just enhance the Security Considerations to satisfy the
terrified people -- obvious stuff to make sure implementers avoid
abuse. We know we don't want it to be 'abused' for general-purpose
messaging, and the pressure for accountability will ensure that
implementers do it properly, if implementers choose to permit it
during general-purpose messaging.

Also, make sure that the protocol and spec is written as such that
multi-message correction doesn't screw up with 1-message orrection.
As I've learned with 0301 (har har) there's also the temptation to
include the kitchen sink (e.g. disco for # of messages allow to
correct, server disco for permissions, disco for time limit of message
correction, etc) but I'd leave that out today -- and theoretically
that can be dealt with separately "someday" (e.g. separate "Message
Correction Extensions" XEP), provided the protocol is written
generically enough today to be acceptable without that now, while
being co-operative with future disco extensions.

Mark Rejhon

More information about the Standards mailing list