[Standards] LAST CALL: XEP-0308 (Last Message Correction)
markybox at gmail.com
Wed Aug 15 04:10:20 UTC 2012
On Tue, Aug 14, 2012 at 1:44 PM, Kurt Zeilenga <Kurt.Zeilenga at isode.com> wrote:
> I think XEP 308 is actually going to lead to a lot of user confusion. The problem is that corrections are actually counter to the chat or "conversational" model.
> In the real world (i.e., face-to-face conversation), there's no rewind button. If you make an error, you have to say something like:
> Pardon me, I meant "no" when I said "yes".
> And in today's XMPP IM use, we have shorthands for this, like, I can send:
> to correct a previous "yes".
> The problem I have with XEP 308, is that that the fact that's a correction is a correction will be lost upon users which don't use clients which support XEP 308. Illustration:
> you: Question?
> me: yes
> then as you send "Really?", I send correction from yes to no. If your client doesn't support corrections, you see:
> you: Really?
> me: no
> and I see:
> you: Question?
> me: no
> you: Really?
> to which I now respond, yes. So we've conclude our discussion, but without understanding that I corrected my first answer to your first question.
> Now if XEP 308 were only sent when the client new the receiving client(s) supported XEP 308, then we'd assured to that at some indication of correction was presented to the reader. But 308 doesn't require sending clients do discovery and not offer correction when the receiving clients(s) don't support XEP 308. And even if 308 did mandate such, many client developers would likely ignore the requirement. But a mandate would be a good start.
> Use in MUC will always be problematic, me thinks.
Kurt brings up a good case for making 0308 disco a requirement, though
several considerations first, arguing towards 0308 from another angle:
1. Kurt's scenario can also occur during traditional corrections "no"
-> "oops, yes", when there's a high network latency for delivery.
(causing "message-crossed-each-other" scenarios) In such a situation,
the message history order on the recipient is not necessarily the same
as the message history order on the sender. This problem is
widespread when network latencies become very high (and when message
delivery receipts timestamps are not used to reorder the messages to
sync message history order on both sender and recipient). It's a
common problem on other networks, such as SMS. It's already caused
huge numbers of misunderstandings, when the word "yes" references a
different message at the recipient end than sender end. Also,
overloaded servers, including for MUC, inject latency sufficient
enough to cause message-crossed-each-other scenarios too.
2. In such scenarios (overloading) user behaviour has already adapted
to be cautious of sending one-word responses to rapid questions.
Users already adapt to behavior.
3. The advantages outweigh the disadvantages. Present instant
messaging has its own existing social problems, and general purpose
instant messaging (or even texting) is already a (mostly great)
technical solution to many of them already. Messaging is an
artificial invented solution that has its own excellent pros and cons.
I'll compare the "social problems" with the "social advantages" in a
-- e.g. messaging social problems include multitasking distractions,
wrong-window messaging, lack of emotion transmission, message
boundaries preventing natural conversation afforded via alternate
means (e.g. audio, video, real time text), the average increase of
information overload for the average human, etc. Instant messaging is
already an artifical solution to life in society.
-- e.g. messaging social advantages include catering to fastest human
method of input: reading - humans can speedread hundreds of WPM
(usually faster than listening), ability to re-read text easily (you
can't replay a live telephone conversation easily), asynchronousness
of message-by-message makes it easier to multitask multiple
conversations at the same time discreetly, the quietness of text based
communications keeping work environments less noisy, the ease of
logging text-based conversations, etc.
Given such a perspective (chat is just a technical solution to a
social problem), I believe it's just merely status quo feelings that
is providing 0308 resistance.
More information about the Standards