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

Kurt Zeilenga Kurt.Zeilenga at Isode.COM
Tue Aug 14 17:44:18 UTC 2012


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:
	s/yes/no/
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


More information about the Standards mailing list