On Mon, Aug 13, 2012 at 1:06 PM, Kurt Zeilenga <kurt.zeile...@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
