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

[Peter Saint-Andre]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 8/31/12 6:27 AM, Kurt Zeilenga wrote:
> 
> On Aug 31, 2012, at 4:09 AM, Dave Cridland 
> wrote:
> 
>> I'm still concerned that replacing any but the author's last
>> message is likely to cause problems with accurately presenting
>> the data.
> 
> I generally think it best to separately display the corrected text
> (as a new message) in the presentation stream with annotations that
> it is a replacement for a previously presented text, whether it's
> the last message or not.  This not only for security reasons, but
> to maintain conversational flow.

That seems like a reasonable user interface (not automagically
changing the original).

Peter

- -- 
Peter Saint-Andre
https://stpeter.im/


-BEGIN PGP SIGNATURE-
Version: GnuPG/MacGPG2 v2.0.18 (Darwin)
Comment: Using GnuPG with Mozilla - http://www.enigmail.net/

iEYEARECAAYFAlBA60sACgkQNL8k5A2w/vy37QCfdUijfj7AACvYi0+Ff//s2v3k
tOUAn2yjq+KOnS5s8EBLB4WC5ODSs285
=rxDI
-END PGP SIGNATURE-

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

[Kurt Zeilenga]

On Aug 31, 2012, at 4:09 AM, Dave Cridland  wrote:

> I'm still concerned that replacing any but the author's last message is 
> likely to cause problems with accurately presenting the data.

I generally think it best to separately display the corrected text (as a new 
message) in the presentation stream with annotations that it is a replacement 
for a previously presented text, whether it's the last message or not.  This 
not only for security reasons, but to maintain conversational flow.

-- Kurt

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

[Dave Cridland]

I'm going to stagger in horribly late on this.

Firstly, I think this XEP is warranted - message correction is a useful
feature, and whilst it's a technical solution to a social problem, I really
don't see why this is an argument against it - if it weren't ultimately
solving a social problem at all, that would be a powerful argument against
it.

Secondly, I, like many people, am concerned with the other social problems
this technology may introduce, as well as the technical problems:

1) As written, the specification allows replacement of an IBB stanza with
an IM message - possibly. This concerns me. The specification appears to
not only allow this, but encourage its support - I think that changes of
purpose should be ruled out of scope, very firmly.

2) I'm concerned that silent correction of previous messages could be
dangerous. The last received message restriction is probably unwarranted,
but needs to be balanced with a warning to implementors that the message
flow will need to be maintained, as well as replacements being clearly
indicated. That is, in Kurt's scenario, you should see:

Kurt: "Question?"
Me: "Yes"
Kurt: "Really?"

And when the correction comes in:

Kurt: "Question?"
*REPLACED* Me: "Yes"
Kurt: "Really?"
*CORRECTION* Me: "No"
Me: "Yes"

Or some such - that is, replacing messages other than the last in a message
stream should not remove the original from view.

I'm still concerned that replacing any but the author's last message is
likely to cause problems with accurately presenting the data.

Essentially, this should be heavily discussed in the Security
Considerations section.

3) The naive fallback case is somewhat unpleasant, as PSA comments. My
thought is that if the messages were specifically annotated in the body of
the message, this would not be an issue:


Correction: But soft, what light through yonder window breaks?



Although this needs some thought to handle XHTML-IM, and it may prove
impossible - though we've done worse things with FLOTs before.

Overall, although I'm relatively happy with the XEP as-is, I think it needs
more thought in terms of the more esoteric uses it might receive before
advancement.