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
