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

[Gunnar Hellstrom]

On 2013-02-24 17:20, Kevin Smith wrote:

On Sat, Oct 13, 2012 at 6:46 AM, Gunnar Hellström
 wrote:

My conclusions are:
1. The feature will be allowed. ( deduced from your answer that Kev is asked
do do an update )
2. How edits are presented to the receiving user is out of scope, but a
recommendation to make it clearly displayed that there was an edit will be
included.
3. Edit any previous will be included. It is up to the transmitter to use it
or not. Receivers should be prepared to act on editing any previous.

I have updated 308 in Git. I believe I've addressed all feedback other
than allowing editing of any previous - for this I've made a note that
the protocol can be used as such, but that signalling is out of scope
and so 308 without further negotiation is only for the last message.
That is fine. I fully respect your decision and am glad that XEP-0308 
will be rescued from deferred state.


/Gunnar

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

[Kevin Smith]

On Sat, Oct 13, 2012 at 6:46 AM, Gunnar Hellström
 wrote:
> My conclusions are:
> 1. The feature will be allowed. ( deduced from your answer that Kev is asked
> do do an update )
> 2. How edits are presented to the receiving user is out of scope, but a
> recommendation to make it clearly displayed that there was an edit will be
> included.
> 3. Edit any previous will be included. It is up to the transmitter to use it
> or not. Receivers should be prepared to act on editing any previous.

I have updated 308 in Git. I believe I've addressed all feedback other
than allowing editing of any previous - for this I've made a note that
the protocol can be used as such, but that signalling is out of scope
and so 308 without further negotiation is only for the last message.
It's then easy to either add support to 308 later (I think better
not), or to add signalling to another XEP that needs or wants it; the
doors open, but we're not inviting anyone in just yet. I ended up
wanting not to add it to 308 because this thread has made it clear
that the security implications are nastier then, and I think there's
value in clients being able to implement the simple version (indeed,
I'm not sure I want to implement multi-message correction myself any
more).

/K

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

[Mark Rejhon]

On Sat, Oct 13, 2012 at 1:46 AM, Gunnar Hellström <
gunnar.hellst...@omnitor.se> wrote:

> On 2012-10-13 04:24, Peter Saint-Andre wrote:
>
>> I know that Kev has been quite busy, but he's quire reliable and I'm
>> sure he will incorporate the Last Call feedback as he has promised to do.
>>
> Was there any last call conclusion?
> The feedback was so varied,
> some saying that the feature was essential, some saying that it should not
> be allowed,
> some requiring that the edited message shall be shown last with
> changemarks, some accepting the change made in place.
> Edit any versus strictly edit last was also discussed.
>
> My conclusions are:
> 1. The feature will be allowed. ( deduced from your answer that Kev is
> asked do do an update )
> 2. How edits are presented to the receiving user is out of scope, but a
> recommendation to make it clearly displayed that there was an edit will be
> included.
> 3. Edit any previous will be included. It is up to the transmitter to use
> it or not. Receivers should be prepared to act on editing any previous.
>

This is my preference as well, though I seemed to recall that Kevin was
going to keep it as is, for editing just the last message.   Regardless,
the XEP-0301 protocol will be compatible with either method.

As for my XEP-0301 updates, keep tuned.  Workload and certain priorities
has increased as of late, but I will be catching up.   I know that the U.S.
access board has inquired asking about when it'll be ready.

Thanks,
Mark Rejhon

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

[Gunnar Hellström]

On 2012-10-13 04:24, Peter Saint-Andre wrote:

I know that Kev has been quite busy, but he's quire reliable and I'm
sure he will incorporate the Last Call feedback as he has promised to do.

Was there any last call conclusion?
The feedback was so varied,
some saying that the feature was essential, some saying that it should 
not be allowed,
some requiring that the edited message shall be shown last with 
changemarks, some accepting the change made in place.

Edit any versus strictly edit last was also discussed.

My conclusions are:
1. The feature will be allowed. ( deduced from your answer that Kev is 
asked do do an update )
2. How edits are presented to the receiving user is out of scope, but a 
recommendation to make it clearly displayed that there was an edit will 
be included.
3. Edit any previous will be included. It is up to the transmitter to 
use it or not. Receivers should be prepared to act on editing any previous.


Right?

/Gunnar

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

[Peter Saint-Andre]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 10/12/12 3:05 PM, Gunnar Hellström wrote:
> I have not seen any progress on XEP-0308 for a while. We dared to
> put in a reference to this useful feature in XEP-0301. Can we still
> hope that XEP-0308 will come out healthy from Last Call and not
> block completion of XEP-0301?

I know that Kev has been quite busy, but he's quire reliable and I'm
sure he will incorporate the Last Call feedback as he has promised to do.

Speaking of XEP-0301, I'm sure Mark has been busy as well, but if I
recall correctly he said that an updated version would be forthcoming.
I look forward to reviewing the revised spec.

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/

iEYEARECAAYFAlB40PoACgkQNL8k5A2w/vwDUgCeLn7TQGK+INcrLA8bg8UpXb5v
zeIAoN0kdadvbeyyHkWmbzYRcCCUrw+C
=phkz
-END PGP SIGNATURE-

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

[Gunnar Hellström]

I have not seen any progress on XEP-0308 for a while. We dared to put in 
a reference to this useful feature in XEP-0301.
Can we still hope that XEP-0308 will come out healthy from Last Call and 
not block completion of XEP-0301?


Regards
Gunnar

___
Gunnar Hellström
Omnitor
gunnar.hellst...@omnitor.se
+46708204288

On 2012-08-30 21:10, Kevin Smith wrote:

On Thu, Aug 30, 2012 at 8:02 PM, Gunnar Hellström
 wrote:

On 2012-07-31 22:52, XMPP Extensions Editor wrote:

This message constitutes notice of a Last Call for comments on XEP-0308
(Last Message Correction).

Abstract: This specification defines a method for marking a message as a
correction of the last sent message.

URL:http://xmpp.org/extensions/xep-0308.html

This Last Call begins today and shall end at the close of business on
2012-08-17.

Was there any conclusion on this last call?

I'm going to address the assorted comments, and then Council'll see
whether another Last Call is justified.

/K

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

[Mark Rejhon]

On Thu, Sep 6, 2012 at 2:02 AM, Dave Cridland  wrote:
> Oh, if you take it out of context like that, then yes... I was talking about
> my suggestion of a removable prefix

Ok, my apologies -- I didn't realize it was sender-appended prefixes.
Much like the "me" XEP-0245, where "/me " is a prefix transmitted as
cleartext by the sender.

In that case, I'm not sure I like the transmitted removable prefix
idea, either.  I generally prefer it be a recipient-appended prefix
(if prefixes are used), not a sender-appended-and-transmitted prefix.
  I feel that implementations should decide how to highlight
corrections and edits, and there's many completely reasonable ways to
highlight edits (recipient-added prefixes, highlights, color codes,
"Edited" tags, etc).

For example, one implementation of doing things with XEP-0308 is that
when edits are made, the message can also be moved orthographically to
the bottom of the history and an "Edited" tag added.  Enhancements in
a specific client, such as selecting (or even mouseovering) the Edited
tag, could possibly expand a list of previous versions of the same
message and the timestamps for them.   All of that can automatically
be done by a client implementation, without modifications to XEP-0308.

Then again, I also see the legitimacy of a removable prefix in
backwards-compatible situations, including MUC (clients with and
without 0308 support).   As long as an algorithm is clearly defined
for prefixes transmitted in XHTML-IM -- the simplest algorithm for
prefix removal in XHTML-IM is simply iterate through the XHTML tree to
the first non-blank innertext, and remove the leading prefix from it
if a match for the prefix is found at the first non-blank innertext in
the XHTML-IM tree. (I wonder if that's how XEP-0245 works over
XHTML-IM?)

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

[Dave Cridland]

Oh, if you take it out of context like that, then yes... I was talking
about my suggestion of a removable prefix.
On Sep 6, 2012 3:37 AM, "Mark Rejhon"  wrote:

> On Fri, Aug 31, 2012 at 7:09 AM, Dave Cridland  wrote:
> > Although this needs some thought to handle XHTML-IM, and it may prove
> > impossible - though we've done worse things with FLOTs before.
>
> Been away, so replying late, too.
>
> From first glance, XEP-0308 doesn't seem incompatible with XHTML-IM.
> It seems to be "naturally" usable with stanzas containing XHTML-IM --
> just send a standard XHTML-IM message (with both  and )
> but also include a  in stanza.  Problem solved.   The exact
> same reasonable UI suggestion can be followed as well.
>
> Can you explain the situation of impossibility?   I am interested in your
> POV.
>
> Thanks,
> Mark Rejhon
>

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

[Mark Rejhon]

On Fri, Aug 31, 2012 at 7:09 AM, Dave Cridland  wrote:
> Although this needs some thought to handle XHTML-IM, and it may prove
> impossible - though we've done worse things with FLOTs before.

Been away, so replying late, too.

>From first glance, XEP-0308 doesn't seem incompatible with XHTML-IM.
It seems to be "naturally" usable with stanzas containing XHTML-IM --
just send a standard XHTML-IM message (with both  and )
but also include a  in stanza.  Problem solved.   The exact
same reasonable UI suggestion can be followed as well.

Can you explain the situation of impossibility?   I am interested in your POV.

Thanks,
Mark Rejhon

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.

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

[Kevin Smith]

On Thu, Aug 30, 2012 at 8:02 PM, Gunnar Hellström
 wrote:
> On 2012-07-31 22:52, XMPP Extensions Editor wrote:
>>
>> This message constitutes notice of a Last Call for comments on XEP-0308
>> (Last Message Correction).
>>
>> Abstract: This specification defines a method for marking a message as a
>> correction of the last sent message.
>>
>> URL:http://xmpp.org/extensions/xep-0308.html
>>
>> This Last Call begins today and shall end at the close of business on
>> 2012-08-17.
>
> Was there any conclusion on this last call?

I'm going to address the assorted comments, and then Council'll see
whether another Last Call is justified.

/K

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

[Gunnar Hellström]

On 2012-07-31 22:52, XMPP Extensions Editor wrote:

This message constitutes notice of a Last Call for comments on XEP-0308 (Last 
Message Correction).

Abstract: This specification defines a method for marking a message as a 
correction of the last sent message.

URL:http://xmpp.org/extensions/xep-0308.html

This Last Call begins today and shall end at the close of business on 
2012-08-17.

Was there any conclusion on this last call?

Thanks
/Gunnar

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

[Andreas Kuckartz]

I think someone else also suggested this:

I would rename the title from "Last Message Correction" to "Message
Correction" and also eliminate "last" from the rest of the text,
"of the last sent message" -> "of a sent message"
"the most recently sent message" -> "a sent message"

I will suggest to the Jitsi and buddycloud developers to implement XEP-0308.

Cheers,
Andreas

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

[Peter Saint-Andre]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 8/15/12 9:16 AM, Kevin Smith wrote:
> On Wed, Aug 15, 2012 at 4:02 PM, Peter Saint-Andre
>  wrote:
>> In a chatroom I frequent, someone just used last message
>> correction, which my client does not support...
>> 
>> [08:18:52]  i though the old IPs work again? [08:18:56]
>>  i thought the old IPs work again?
> 
> That user's client gave them a warning before sending the
> correction to the MUC, mind, saying that some users in the MUC
> didn't support message correction and would see it as a duplicate
> message.
> 
>> I perceived it as retyping the entire message to make the
>> correction, which I suppose was reasonable. However, whether the
>> retyped message makes sense depends on how much was changed. This
>> would have been strange...
>> 
>> [08:18:52]  i though the old IPs work again? [08:18:56]
>>  did I hear correctly that the old IPs work again?
>> 
>> or even...
>> 
>> [08:18:52]  i though the old IPs work again? [08:18:56]
>>  Peter, you're a loser
>> 
>>> I do suspect that a social solution to this issue will be
>>> found.
>> 
>> Socially speaking, I think most corrections are slight. But 
>> potentially they could be significant and subject to abuse.
> 
> It certainly introduces ways for people to do odd things, but in
> terms of abuse I'm not convinced. That is - 308 is already clear (I
> think, and I can make it clearer) that clients will need to let the
> user know that the message has been modified,

Actually it says:

"A client SHOULD alert the user that the displayed message has been
edited since it was originally sent."

Isn't that a UI thing that doesn't deserve or require a SHOULD? ;-)

And does the alert/warning apply to the sending user, the receiving
users, or both?

> so there isn't much of a window for tricking people here (and I
> think a good UI is to expose the original message as well, although
> simply saying that the message has been edited is probably
> sufficient).
> 
> If there are real attacks here, rather than just a feeling that
> it's a bit odd and unexpected, we should enumerate them and address
> them.

So far it seems odd and unexpected, and open to pranks more than
serious attacks.

Peter

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


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

iEYEARECAAYFAlArwF0ACgkQNL8k5A2w/vxpeQCgwAbTkZcYa7MyBAqnOVX23f1b
+YoAoOwoHfrhLr6L8tnVje+aDA3xu3ze
=5HeO
-END PGP SIGNATURE-

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

[Kevin Smith]

On Wed, Aug 15, 2012 at 4:02 PM, Peter Saint-Andre  wrote:
> In a chatroom I frequent, someone just used last message correction,
> which my client does not support...
>
> [08:18:52]  i though the old IPs work again?
> [08:18:56]  i thought the old IPs work again?

That user's client gave them a warning before sending the correction
to the MUC, mind, saying that some users in the MUC didn't support
message correction and would see it as a duplicate message.

> I perceived it as retyping the entire message to make the correction,
> which I suppose was reasonable. However, whether the retyped message
> makes sense depends on how much was changed. This would have been
> strange...
>
> [08:18:52]  i though the old IPs work again?
> [08:18:56]  did I hear correctly that the old IPs work again?
>
> or even...
>
> [08:18:52]  i though the old IPs work again?
> [08:18:56]  Peter, you're a loser
>
>> I do suspect that a social solution to this issue will be found.
>
> Socially speaking, I think most corrections are slight. But
> potentially they could be significant and subject to abuse.

It certainly introduces ways for people to do odd things, but in terms
of abuse I'm not convinced. That is - 308 is already clear (I think,
and I can make it clearer) that clients will need to let the user know
that the message has been modified, so there isn't much of a window
for tricking people here (and I think a good UI is to expose the
original message as well, although simply saying that the message has
been edited is probably sufficient).

If there are real attacks here, rather than just a feeling that it's a
bit odd and unexpected, we should enumerate them and address them.

/K

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

[Peter Saint-Andre]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 8/15/12 8:54 AM, Kurt Zeilenga wrote:
> 
> On Aug 15, 2012, at 7:28 AM, Kevin Smith  
> wrote:
> 
>>> In fact, I'd argue that this spec is a technical solution to a 
>>> social problem
>> 
>> I note, after drafting many more acerbic replies, that this is 
>> consistent with all specs.
>> 
>> Messaging is a social problem.
> 
> Yes.
> 
> My concern is how effective our solution is in solving the social 
> problem, messaging between humans.
> 
> XMPP IM (without 308) has demonstrated itself to be an effective 
> solution.  XMPP IM with 308 implemented universally would also
> likely an effective solution.
> 
> It seems to me that XMPP IM, with some clients supporting 308 and 
> some not, will be less effective than either of the above
> solutions, simply because key information (this message is a
> correction) is lost on fallback in clients not supporting 308.

In a chatroom I frequent, someone just used last message correction,
which my client does not support...

[08:18:52]  i though the old IPs work again?
[08:18:56]  i thought the old IPs work again?

I perceived it as retyping the entire message to make the correction,
which I suppose was reasonable. However, whether the retyped message
makes sense depends on how much was changed. This would have been
strange...

[08:18:52]  i though the old IPs work again?
[08:18:56]  did I hear correctly that the old IPs work again?

or even...

[08:18:52]  i though the old IPs work again?
[08:18:56]  Peter, you're a loser

> I do suspect that a social solution to this issue will be found.

Socially speaking, I think most corrections are slight. But
potentially they could be significant and subject to abuse.

> I don't object to progressing 308 to Draft.

It's not a hill for me to die on.

Peter

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


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

iEYEARECAAYFAlAruhoACgkQNL8k5A2w/vz/PQCguVskRDKnj0fbKIAgahIuXK6f
qFUAoLU133X9nNQHTI+kthV+z+FIIwo6
=r/mm
-END PGP SIGNATURE-

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

[Matthew Miller]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1


On Aug 15, 2012, at 08:54, Kurt Zeilenga wrote:

> 
> On Aug 15, 2012, at 7:28 AM, Kevin Smith  wrote:
> 
>>> In fact, I'd argue that this spec is a technical solution to a social
>>> problem
>> 
>> I note, after drafting many more acerbic replies, that this is
>> consistent with all specs.
>> 
>> Messaging is a social problem.
> 
> Yes.
> 
> My concern is how effective our solution is in solving the social problem, 
> messaging between humans.
> 
> XMPP IM (without 308) has demonstrated itself to be an effective solution.  
> XMPP IM with 308 implemented universally would also likely an effective 
> solution.
> 
> It seems to me that XMPP IM, with some clients supporting 308 and some not, 
> will be less effective than either of the above solutions, simply because key 
> information (this message is a correction) is lost on fallback in clients not 
> supporting 308.
> 

I do not completely agree that key information will (always) be lost.  It does 
indeed matter significantly how a client renders corrected text:

1) delete of old, overwrite with new (lost information)
2) strikethrough of old, place new immediately next to it (no lost information)

And there's a couple of other ways I can see this going...


- - m&m

Matthew A. Miller


-BEGIN PGP SIGNATURE-
Version: GnuPG/MacGPG2 v2.0.17 (Darwin)
Comment: GPGTools - http://gpgtools.org

iQEcBAEBAgAGBQJQK7meAAoJEJq6Ou0cgrSPlGgH/idyONFgZueMp0vHgieGX2jx
uaQ6JwlBrJ/QCSgf7IjOWDBSENxJhg2Th72TI9RjmBCJv9842qXHmaKu2cf5nCNb
cle6rThuvqCeI0BTgsg8d9hgj2jdA65Tn4ljnyrL05JQlPMeg8wSaHIK+kmh7Z+2
DViszYVZXvJPLgNC98ZpttvJZsL9GXYS+zc5UO1JC0Ehgdr3/WdPMai8J8KVpnGl
pqWHHVTUieZc+jv25WgnIa89V+6YlCQlAj8bl4/5Cs6r/Dzx3uB19T+twFW2b/oh
gDnj1xlk0coQ6FUxeTSruPaCDxC90vdxH1Te2cCyktdEU9KhXnR2/Pu0aLeyfTA=
=5hoj
-END PGP SIGNATURE-

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

[Peter Saint-Andre]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 8/15/12 8:51 AM, Kevin Smith wrote:
> On Wed, Aug 15, 2012 at 3:45 PM, Peter Saint-Andre
>  wrote:
>> On 8/15/12 8:28 AM, Kevin Smith wrote:
 In fact, I'd argue that this spec is a technical solution to
 a social problem
>>> 
>>> I note, after drafting many more acerbic replies, that this is 
>>> consistent with all specs.
>>> 
>>> Messaging is a social problem.
>> 
>> Most people handle slight mistakes in messages quite gracefully
>> by typing some text in a new message ("oops, I meant thought,
>> not though"). We've all seen it and done it. Why after all this
>> time is it imperative that we give folks the ability to make such
>> corrections by changing the last message instead of explaining
>> the error in a new message?
> 
> I would have hoped that the wrong-headedness of "We shouldn't
> change things, we can make do with what we have" would be
> self-evident, but it doesn't seem so.
> 
> Now, if you'll excuse me, I've got a chisel and some slate that
> need interfacing.

Sorry, stone tools are too advanced for me. :P

/psa

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

iEYEARECAAYFAlAruF4ACgkQNL8k5A2w/vypWACgtwXsECD6dXcKLGw3NuzCh0iC
9ikAn0v0TBTRjR87euF8NeMemXiPZSFh
=+Ude
-END PGP SIGNATURE-

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

[Kurt Zeilenga]

On Aug 15, 2012, at 7:28 AM, Kevin Smith  wrote:

>> In fact, I'd argue that this spec is a technical solution to a social
>> problem
> 
> I note, after drafting many more acerbic replies, that this is
> consistent with all specs.
> 
> Messaging is a social problem.

Yes.

My concern is how effective our solution is in solving the social problem, 
messaging between humans.

XMPP IM (without 308) has demonstrated itself to be an effective solution.  
XMPP IM with 308 implemented universally would also likely an effective 
solution.

It seems to me that XMPP IM, with some clients supporting 308 and some not, 
will be less effective than either of the above solutions, simply because key 
information (this message is a correction) is lost on fallback in clients not 
supporting 308.

I do suspect that a social solution to this issue will be found.

I don't object to progressing 308 to Draft.

-- Kurt

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

[Kevin Smith]

On Wed, Aug 15, 2012 at 3:45 PM, Peter Saint-Andre  wrote:
> On 8/15/12 8:28 AM, Kevin Smith wrote:
>>> In fact, I'd argue that this spec is a technical solution to a
>>> social problem
>>
>> I note, after drafting many more acerbic replies, that this is
>> consistent with all specs.
>>
>> Messaging is a social problem.
>
> Most people handle slight mistakes in messages quite gracefully by
> typing some text in a new message ("oops, I meant thought, not
> though"). We've all seen it and done it. Why after all this time is it
> imperative that we give folks the ability to make such corrections by
> changing the last message instead of explaining the error in a new
> message?

I would have hoped that the wrong-headedness of "We shouldn't change
things, we can make do with what we have" would be self-evident, but
it doesn't seem so.

Now, if you'll excuse me, I've got a chisel and some slate that need
interfacing.

/K

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

[Peter Saint-Andre]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 8/15/12 8:28 AM, Kevin Smith wrote:
>> In fact, I'd argue that this spec is a technical solution to a
>> social problem
> 
> I note, after drafting many more acerbic replies, that this is 
> consistent with all specs.
> 
> Messaging is a social problem.

Most people handle slight mistakes in messages quite gracefully by
typing some text in a new message ("oops, I meant thought, not
though"). We've all seen it and done it. Why after all this time is it
imperative that we give folks the ability to make such corrections by
changing the last message instead of explaining the error in a new
message?

Realistically, so few clients will support this extension that it'll
be as if it doesn't exist.

Peter

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


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

iEYEARECAAYFAlArtiQACgkQNL8k5A2w/vwLtwCgydLS3lI/zCHwKe90mgeGclvq
Lz8AoPSh8vuID7HZ/cqKQ9R2Y9gA923h
=pLRh
-END PGP SIGNATURE-

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

[Kevin Smith]

> In fact, I'd argue that this spec is a technical solution to a social
> problem

I note, after drafting many more acerbic replies, that this is
consistent with all specs.

Messaging is a social problem.

/K

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

[Kurt Zeilenga]

On Aug 14, 2012, at 1:03 PM, Gunnar Hellström  
wrote:

> I think this extension gets rid of one annoying characteristic of XMPP IM. - 
> The message borderline being an artificial borderline for corrections.

308 doesn't take the messaging out of IM.

-- Kurt

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

[Mark Rejhon]

On Tue, Aug 14, 2012 at 1:44 PM, Kurt Zeilenga  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:
> 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 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
balanced way:
-- 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.

Thanks
Mark Rejhon

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

[Gunnar Hellström]

On 2012-08-14 20:09, Kurt Zeilenga wrote:

On Aug 14, 2012, at 8:57 AM, Peter Saint-Andre  wrote:


In fact, I'd argue that this spec is a technical solution to a social
problem, and thus is wrongheaded. It's easy enough to send a new
message correcting the old one (e.g., "sorry, I meant to say Y instead
of X" or "s/X/Y/"). People do that all the time. Magically and
invisibly changing a message after the fact strikes me as a really bad
idea.

The more I think about it, the more I think I that this XEP is a bad idea.

Basically, the kind of user confusion I illustrated in by prior post can really 
only be addressed if this extension is mandatory to implement (for all 
clients).  And, I don't think extensions should be mandatory to implement.  
They should be truly optional.

-- Kurt


I think this extension gets rid of one annoying characteristic of XMPP 
IM. - The message borderline being an artificial borderline for 
corrections.


If an implementer really thinks it is risky, and that it can cause 
undetected modifications, then the implementation can require from the 
user that there is no text in the current message before the last 
message may be entered for correction.  So, if you have started to type 
the new current message, you need to erase it before entering the 
previous message for correcting it.  That will make corrections appear 
with care and only when it is felt efficient by the typing user. There 
is no difference in the protocol for this feature, so it does not need 
to influence the specification.


I hope that the current discussion, with some voices saying that 
correction of last message should not be allowed, will not influence the 
acceptance of XEP-0308.


/Gunnar

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

[Kim Alvefur]

On 2012-08-14T20:09:28 CEST, Kurt Zeilenga wrote:
> The more I think about it, the more I think I that this XEP is a bad idea.

I think the concept itself is a bad idea, but since some people really 
want to have this feature, having a XEP for it might be better than not 
having one.  I do agree with Peter about this largely being a technical 
solution to a social problem.

--
Kim "Zash" Alvefur



signature.asc
Description: OpenPGP digital signature

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

[Kurt Zeilenga]

On Aug 14, 2012, at 8:57 AM, Peter Saint-Andre  wrote:

> In fact, I'd argue that this spec is a technical solution to a social
> problem, and thus is wrongheaded. It's easy enough to send a new
> message correcting the old one (e.g., "sorry, I meant to say Y instead
> of X" or "s/X/Y/"). People do that all the time. Magically and
> invisibly changing a message after the fact strikes me as a really bad
> idea.

The more I think about it, the more I think I that this XEP is a bad idea. 

Basically, the kind of user confusion I illustrated in by prior post can really 
only be addressed if this extension is mandatory to implement (for all 
clients).  And, I don't think extensions should be mandatory to implement.  
They should be truly optional.

-- Kurt

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

[Kurt Zeilenga]

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

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

[Peter Saint-Andre]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 8/14/12 9:51 AM, Peter Saint-Andre wrote:
> On 8/13/12 3:03 PM, Andreas Kuckartz wrote:
>> Kurt Zeilenga:
>>> From a user perspective, often what I want to correct isn't
>>> the last stanza I sent.
> 
>> I support that argument. Several Social Networking Services 
>> provide similar features and I expect XMPP to also support that.
> 
> Look, folks, if we want the ability to reach back and edit 
> everything under the sun, then by all means let's define that
> using pubsub under something like XEP-0277. IM, by contrast, is an 
> ever-flowing stream and sometimes you make mistakes when typing
> such messages (as people do in email messages to lists like this
> one). Do you have the ability to edit every email message you've
> ever sent? No, so just get over it.

In fact, I'd argue that this spec is a technical solution to a social
problem, and thus is wrongheaded. It's easy enough to send a new
message correcting the old one (e.g., "sorry, I meant to say Y instead
of X" or "s/X/Y/"). People do that all the time. Magically and
invisibly changing a message after the fact strikes me as a really bad
idea.

Peter

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


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

iEYEARECAAYFAlAqdXEACgkQNL8k5A2w/vxNAgCguIGgTZYYLeXFm/TkGPPkonQM
YFcAniN5KfWX2x9uY3jbasHs8+WDW9pT
=xURZ
-END PGP SIGNATURE-

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

[Peter Saint-Andre]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 8/13/12 3:03 PM, Andreas Kuckartz wrote:
> Kurt Zeilenga:
>> From a user perspective, often what I want to correct isn't the
>> last stanza I sent.
> 
> I support that argument. Several Social Networking Services
> provide similar features and I expect XMPP to also support that.

Look, folks, if we want the ability to reach back and edit
everything under the sun, then by all means let's define that using
pubsub under something like XEP-0277. IM, by contrast, is an
ever-flowing stream and sometimes you make mistakes when typing such
messages (as people do in email messages to lists like this one). Do
you have the ability to edit every email message you've ever sent? No,
so just get over it.

Peter

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


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

iEYEARECAAYFAlAqdAYACgkQNL8k5A2w/vy1bACggPxlTVpMwyUnQVvojBO6DOfO
d4cAoJnZ+wBlRfP9gpUerv0DiLCf0PEd
=gHS2
-END PGP SIGNATURE-

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

[Mark Rejhon]

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

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

[Andreas Kuckartz]

Kurt Zeilenga:
> From a user perspective, often what I want to correct isn't the last stanza I 
> sent.

I support that argument. Several Social Networking Services provide
similar features and I expect XMPP to also support that.

Cheers,
Andreas

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

[Mark Rejhon]

On Mon, Aug 13, 2012 at 4:38 PM, Philipp Hancke
 wrote:
> Am 13.08.2012 19:06, schrieb Kurt Zeilenga:
>>
>> I rather the client simply add the replacement message to the message
>> stream (as it would any other new message) and provide me some indication
>> that it's a replacement for another message and what that message is.
>
> I like that notion. It doesn't change the 'oh, I meant to say...' model that
> is (probably) widely used today, but still gives a hint which message is
> affected.

Agreed -- I suggest Kevin make a mention suggesting such behavior.

Note,  has no better/worse potential for amplification
attacks than XEP-0301 does (assuming you follow reasonable rules, such
as automatically transmit traffic when receiving traffic, etc --
neither of which is required for 0301 or 0308)

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

[Philipp Hancke]

Am 13.08.2012 19:06, schrieb Kurt Zeilenga:

I rather the client simply add the replacement message to the message stream 
(as it would any other new message) and provide me some indication that it's a 
replacement for another message and what that message is.


I like that notion. It doesn't change the 'oh, I meant to say...' model 
that is (probably) widely used today, but still gives a hint which 
message is affected.

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

[Mark Rejhon]

On Mon, Aug 13, 2012 at 4:23 PM, Philipp Hancke
 wrote:
> Am 13.08.2012 22:05, schrieb Mark Rejhon:
>>
>> In addition, it would likely be non-backwards compatible in a
>> "graceful degrade manner", e.g. MUC
>
> [...]
>>
>> The way both me and Kevin has currently specified, ensures that both
>> 0301 and 0308 will work and interop fine in mixed-MUC situations.
>
> Frankly, I would  recommend MUCs to filter out any RTT stuff. Unless they
> want to take part in amplification attacks of course. But that's not for the
> 0308 LC, is a problem that 0045 has in general and only shows when dealing
> with heavy traffic.

Not an option.  Some demos of Next Generation 911 uses MUC combined
with XEP-0301

Better option: Server control of enabling/disabling 0301 on a
per-chat-room basis

Mark Rejhon

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

[Philipp Hancke]

Am 13.08.2012 22:05, schrieb Mark Rejhon:

In addition, it would likely be non-backwards compatible in a
"graceful degrade manner", e.g. MUC

[...]

The way both me and Kevin has currently specified, ensures that both
0301 and 0308 will work and interop fine in mixed-MUC situations.


Frankly, I would  recommend MUCs to filter out any RTT stuff. Unless 
they want to take part in amplification attacks of course. But that's 
not for the 0308 LC, is a problem that 0045 has in general and only 
shows when dealing with heavy traffic.

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

[Mark Rejhon]

On Mon, Aug 13, 2012 at 3:00 AM, Gunnar Hellström
 wrote:
> That is both an opportunity and a risk.
> It is an opportunity for other extensions adding elements to the 
> to consider if they want to utilize XEP-0308 for replacing the contents.
> ( this could possibly be utilized by XEP-0301 instead of specifying its own
> way of doing replacements of real-time text, but it requires some more
> specific rules in XEP-0301 about how to apply it in that environment.)

In addition, it would likely be non-backwards compatible in a
"graceful degrade manner", e.g. MUC
A mixed MUC with all kinds of participants simultaneously:
- Clients that don't support XEP-0301
- Clients that support XEP-0301 but not XEP-0308
- Clients that support XEP-0308 but not XEP-0301
- Clients that support both XEP-0301 and XEP-0308

The way both me and Kevin has currently specified, ensures that both
0301 and 0308 will work and interop fine in mixed-MUC situations.
Therefore, I like the way XEP-0308 is specified: full stanza
replacement only, and keeping 0301 retroactive editing separate of
0308 retroactive.   It's far simpler and far more forgiving than
trying to specify ways of replacing specific  elements.

Mark Rejhon

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

[Mark Rejhon]

On Mon, Aug 13, 2012 at 12:22 PM, Kevin Smith  wrote:
>> Anyways, if there's no particularly strong reason to have the "last" message 
>> restriction, I think it should be removed.
>
> The spec originally allowed previous non-last correction, and the
> community cried foul so I removed it.
>
> I can add it back in if the community has now changed its mind!

It's useful for real-time text situations -- it goes hand-in-hand with
transcription/caption corrections, when using instant messaging as a
conduit of transmitting transcriptions, and needing to retroactively
fix transcription errors, or manually editing voice-recognition
errors.  It is a niche case, but certainly a legitimate one.

However, please bring the original people who cried foul, back into
this discussion.  I'd like to see if they now agree with the use
cases.

The only thing is that you need to either:
1. Define the bounds of corrections (e.g. X messages ago)
--or--
2. Define what to do if 'id' points to a non-existent message
(i.e. refers to a message that no longer exists on recipient's client
-- this can happen in multiple login situations, reconnect situations,
MUC situations with new participants joining after a message is
already sent)

For simplicity you may want to go for scenario (2) for now.  Treat
unrecognized id's as a new stanza.

The only problem is that we don't really know "how many messages ago
it was" -- for example, we don't know if it was 2 or 3 messages ago --
or 6 messages ago.  So corrections done in a random-access manner, and
out-of-order transmission, will show potential jumbling of order.
But that's acceptable, and potentially a client implementation could
automatically sort the 'id' parameter alphabetically, since the 'id'
is often always incrementing (either numerically or alphabetically),
though that's not always reliable.

Thanks,
Mark Rejhon

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

[Kurt Zeilenga]

On Aug 13, 2012, at 9:22 AM, Kevin Smith  wrote:

> On Mon, Aug 13, 2012 at 5:15 PM, Kurt Zeilenga  
> wrote:
>> Why is this restriction restricted to editing the "last" stanza sent?
>> 
>> Is this due to presentation issues?
>> 
>> If so, I think the clients are going to have to deal with them no matter 
>> what restrictions we place on senders...  because a sender cannot control 
>> other senders.  In short, receiving clients have to appropriately deal with 
>> replacements for non-last stanzas.  And as clients are certainly going to 
>> have to deal with this MUC, seems no big deal for them to deal with it 
>> general.
>> 
>> Anyways, if there's no particularly strong reason to have the "last" message 
>> restriction, I think it should be removed.
> 
> 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?


Anyways, here's my argument.


From a user perspective, often what I want to correct isn't the last stanza I 
sent.  And when I receive corrections, I rather my client not replace the 
original message in the presentation stream.  I rather the client simply add 
the replacement message to the message stream (as it would any other new 
message) and provide me some indication that it's a replacement for another 
message and what that message is.  And, I note, if a client receives a 
correction for a stanza it doesn't have, it still make use of the  
element, by using it to trigger that the newly presented content is a 
replacement for non-presented content.

Now, I can see some clients would replace the content in the presented stream 
it the replaced message "last" received message (before the replacement)... but 
that's an implementation detail.  No matter what what, clients need to be able 
to deal replaces coming in for something other than the "last" received 
message, like treating it as if the  element was absent.

From a protocol perspective, I see little reason to have the last sent 
restriction as clients have to deal with replace referencing non-last (possibly 
not previously seen) messages.



> so I removed it.
> 
> I can add it back in if the community has now changed its mind!
> 
> /K

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

[Kurt Zeilenga]

On Aug 13, 2012, at 9:22 AM, Kevin Smith  wrote:

> On Mon, Aug 13, 2012 at 5:15 PM, Kurt Zeilenga  
> wrote:
>> Why is this restriction restricted to editing the "last" stanza sent?
>> 
>> Is this due to presentation issues?
>> 
>> If so, I think the clients are going to have to deal with them no matter 
>> what restrictions we place on senders...  because a sender cannot control 
>> other senders.  In short, receiving clients have to appropriately deal with 
>> replacements for non-last stanzas.  And as clients are certainly going to 
>> have to deal with this MUC, seems no big deal for them to deal with it 
>> general.
>> 
>> Anyways, if there's no particularly strong reason to have the "last" message 
>> restriction, I think it should be removed.
> 
> 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?


Anyways, here's my argument.


From a user perspective, often what I want to correct isn't the last stanza I 
sent.  And when I receive corrections, I rather my client not replace the 
original message in the presentation stream.  I rather the client simply add 
the replacement message to the message stream (as it would any other new 
message) and provide me some indication that it's a replacement for another 
message and what that message is.  And, I note, if a client receives a 
correction for a stanza it doesn't have, it still make use of the  
element, by using it to trigger that the newly presented content is a 
replacement for non-presented content.

Now, I can see some clients would replace the content in the presented stream 
it the replaced message "last" received message (before the replacement)... but 
that's an implementation detail.  No matter what what, clients need to be able 
to deal replaces coming in for something other than the "last" received 
message, like treating it as if the  element was absent.

From a protocol perspective, I see little reason to have the last sent 
restriction as clients have to deal with replace referencing non-last (possibly 
not previously seen) messages.



> so I removed it.
> 
> I can add it back in if the community has now changed its mind!
> 
> /K

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

[Kevin Smith]

On Mon, Aug 13, 2012 at 5:15 PM, Kurt Zeilenga  wrote:
> Why is this restriction restricted to editing the "last" stanza sent?
>
> Is this due to presentation issues?
>
> If so, I think the clients are going to have to deal with them no matter what 
> restrictions we place on senders...  because a sender cannot control other 
> senders.  In short, receiving clients have to appropriately deal with 
> replacements for non-last stanzas.  And as clients are certainly going to 
> have to deal with this MUC, seems no big deal for them to deal with it 
> general.
>
> Anyways, if there's no particularly strong reason to have the "last" message 
> restriction, I think it should be removed.

The spec originally allowed previous non-last correction, and the
community cried foul so I removed it.

I can add it back in if the community has now changed its mind!

/K

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

[Kurt Zeilenga]

It may be that I'm reading a restriction into the spec that wasn't intended by 
the authors.  If so, then maybe a simple clarification is needed (like drop the 
"Last" from the title).


On Aug 13, 2012, at 9:15 AM, Kurt Zeilenga  wrote:

> Why is this restriction restricted to editing the "last" stanza sent?
> 
> Is this due to presentation issues?
> 
> If so, I think the clients are going to have to deal with them no matter what 
> restrictions we place on senders...  because a sender cannot control other 
> senders.  In short, receiving clients have to appropriately deal with 
> replacements for non-last stanzas.  And as clients are certainly going to 
> have to deal with this MUC, seems no big deal for them to deal with it 
> general.
> 
> Anyways, if there's no particularly strong reason to have the "last" message 
> restriction, I think it should be removed.
> 
> -- Kurt
> 
> 
> On Jul 31, 2012, at 1:52 PM, XMPP Extensions Editor  wrote:
> 
>> This message constitutes notice of a Last Call for comments on XEP-0308 
>> (Last Message Correction).
>> 
>> Abstract: This specification defines a method for marking a message as a 
>> correction of the last sent message.
>> 
>> URL: http://xmpp.org/extensions/xep-0308.html
>> 
>> This Last Call begins today and shall end at the close of business on 
>> 2012-08-17.
>> 
>> Please consider the following questions during this Last Call and send your 
>> feedback to the standards@xmpp.org discussion list:
>> 
>> 1. Is this specification needed to fill gaps in the XMPP protocol stack or 
>> to clarify an existing protocol?
>> 2. Does the specification solve the problem stated in the introduction and 
>> requirements?
>> 3. Do you plan to implement this specification in your code? If not, why not?
>> 4. Do you have any security concerns related to this specification?
>> 5. Is the specification accurate and clearly written?
>> 
>> Your feedback is appreciated!
> 

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

[Kurt Zeilenga]

Why is this restriction restricted to editing the "last" stanza sent?

Is this due to presentation issues?

If so, I think the clients are going to have to deal with them no matter what 
restrictions we place on senders...  because a sender cannot control other 
senders.  In short, receiving clients have to appropriately deal with 
replacements for non-last stanzas.  And as clients are certainly going to have 
to deal with this MUC, seems no big deal for them to deal with it general.

Anyways, if there's no particularly strong reason to have the "last" message 
restriction, I think it should be removed.

-- Kurt


On Jul 31, 2012, at 1:52 PM, XMPP Extensions Editor  wrote:

> This message constitutes notice of a Last Call for comments on XEP-0308 (Last 
> Message Correction).
> 
> Abstract: This specification defines a method for marking a message as a 
> correction of the last sent message.
> 
> URL: http://xmpp.org/extensions/xep-0308.html
> 
> This Last Call begins today and shall end at the close of business on 
> 2012-08-17.
> 
> Please consider the following questions during this Last Call and send your 
> feedback to the standards@xmpp.org discussion list:
> 
> 1. Is this specification needed to fill gaps in the XMPP protocol stack or to 
> clarify an existing protocol?
> 2. Does the specification solve the problem stated in the introduction and 
> requirements?
> 3. Do you plan to implement this specification in your code? If not, why not?
> 4. Do you have any security concerns related to this specification?
> 5. Is the specification accurate and clearly written?
> 
> Your feedback is appreciated!

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

[Kevin Smith]

On Mon, Aug 13, 2012 at 8:00 AM, Gunnar Hellström
 wrote:
> On 2012-07-31 22:52, XMPP Extensions Editor wrote:
>>
>> This message constitutes notice of a Last Call for comments on XEP-0308
>> (Last Message Correction).
>>
>> Abstract: This specification defines a method for marking a message as a
>> correction of the last sent message.
>>
>> URL: http://xmpp.org/extensions/xep-0308.html
>>
>> This Last Call begins today and shall end at the close of business on
>> 2012-08-17.
>>
>> Please consider the following questions during this Last Call and send
>> your feedback to the standards@xmpp.org discussion list:
>>
>> 1. Is this specification needed to fill gaps in the XMPP protocol stack or
>> to clarify an existing protocol?
>
> Yes, it is a quite important usability improvement.
>
>> 2. Does the specification solve the problem stated in the introduction and
>> requirements?
>
> Yes
>
>> 3. Do you plan to implement this specification in your code? If not, why
>> not?
>
> Yes
>
>> 4. Do you have any security concerns related to this specification?
>
> No other than other last call comments have expressed.
>
>> 5. Is the specification accurate and clearly written?
>
> Yes.
> However.
>
> It does not explicitly state what element of the  that is
> replaced.
> It is clear from the examples that  is what the author thought of.
>
> It mentions some items that shall not be replaced, but apart from that it
> seems to be open for replacing anything that has been delivered in a
> .
>
> That is both an opportunity and a risk.
> It is an opportunity for other extensions adding elements to the 
> to consider if they want to utilize XEP-0308 for replacing the contents.
> ( this could possibly be utilized by XEP-0301 instead of specifying its own
> way of doing replacements of real-time text, but it requires some more
> specific rules in XEP-0301 about how to apply it in that environment.)
>
> It is a risk that if other extensions adding new message elements do not
> specify if XEP-0308 can replace the contents of the new element.
> interoperability problems may appear, with a sender replacing an element
> that the recipient is not made for replacing.
>
> This could be moderated by inserting a sentence in the Business rules:
> "Extensions specifying  contents should specify if and how it can
> be replaced by the XEP-0308 'replace'."

Thanks for the feedback.

The XEP says that a correction is a replacement for the entire stanza.
I'll make sure I add text to make this clearer.

/K

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

[Gunnar Hellström]

On 2012-07-31 22:52, XMPP Extensions Editor wrote:

This message constitutes notice of a Last Call for comments on XEP-0308 (Last 
Message Correction).

Abstract: This specification defines a method for marking a message as a 
correction of the last sent message.

URL: http://xmpp.org/extensions/xep-0308.html

This Last Call begins today and shall end at the close of business on 
2012-08-17.

Please consider the following questions during this Last Call and send your 
feedback to the standards@xmpp.org discussion list:

1. Is this specification needed to fill gaps in the XMPP protocol stack or to 
clarify an existing protocol?

Yes, it is a quite important usability improvement.

2. Does the specification solve the problem stated in the introduction and 
requirements?

Yes

3. Do you plan to implement this specification in your code? If not, why not?

Yes

4. Do you have any security concerns related to this specification?

No other than other last call comments have expressed.

5. Is the specification accurate and clearly written?

Yes.
However.

It does not explicitly state what element of the  that is 
replaced.

It is clear from the examples that  is what the author thought of.

It mentions some items that shall not be replaced, but apart from that 
it seems to be open for replacing anything that has been delivered in a 
.


That is both an opportunity and a risk.
It is an opportunity for other extensions adding elements to the 
 to consider if they want to utilize XEP-0308 for replacing 
the contents.
( this could possibly be utilized by XEP-0301 instead of specifying its 
own way of doing replacements of real-time text, but it requires some 
more specific rules in XEP-0301 about how to apply it in that environment.)


It is a risk that if other extensions adding new message elements do not 
specify if XEP-0308 can replace the contents of the new element. 
interoperability problems may appear, with a sender replacing an element 
that the recipient is not made for replacing.


This could be moderated by inserting a sentence in the Business rules:
"Extensions specifying  contents should specify if and how it 
can be replaced by the XEP-0308 'replace'."




Your feedback is appreciated!

/Gunnar

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

[Mark Rejhon]

On Fri, Aug 10, 2012 at 8:56 AM, Kevin Smith  wrote:
>>
>> A MUC service might rewrite the id attribute, see
>> http://xmpp.org/extensions/xep-0045.html#message
>> "Note well that for tracking purposes this service assigns a new 'id' to
>>  each message it generates (here using a UUID as defined in RFC 4122)"
>>
>> I bet some services do this... making the id at the recipient unpredictable.
>
> We should probably fix MUC on this - I hadn't noticed in the examples
> what was going on and read the text to mean "The id sent to the room
> may not be the id you specified" not "Everyone in the room may get a
> different id" - which will break things.

So maybe define what happens if the id is not what you expect.
This should also cover simultaneous login scenarios:

1. Login starts typing a message and sends it.
2. New participant joins
3. Login starts correcting message.
4. New participant receives a  for an id that does not exist.

On the topic of simultaneous logins, don't forget to cover scenario
#2, where full JID is not available:

1. Login starts typing message, sends to MUC.
2. Simultaneous login starts typing message #2, sends to MUC.
3. Login starts doing message correction, it now refers to a message 2
messages ago.  (id is valid).

So what you need to do, is essentially specify that unrecognized or
unhandled 'id' should mean  should be ignored and the
re-transmitted message displayed as a brand new message.  Probably the
simplest solution.

Thanks,
Mark Rejhon

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

[Philipp Hancke]

since I'm halfway through anyway...


1. Is this specification needed to fill gaps in the XMPP protocol stack or to 
clarify an existing protocol?


Well, I think sending a message with s/airlock/window/ would be 
sufficient, but i'm rather old-fashioned :-)



2. Does the specification solve the problem stated in the introduction and 
requirements?


Piggybacking on the id seems like a dirty hack, but for the sake of 
traffic it's better than adding a new xml element to each message stanza.



3. Do you plan to implement this specification in your code? If not, why not?


server-dev, N/A


4. Do you have any security concerns related to this specification?


See my other messages.


5. Is the specification accurate and clearly written?


I would reorder the business rules in section 4 so that they deal with 
the topics in a less random order. Proposed order would be 1+4 (dealing 
with the id on the sender side), 5+6 (dealing with the sender) and 3+4 
last (dealing with the receiver).


The discovery examples in section 2 use a server jid which seems 
awkward, probably related to the text at the start of the section.


THIS PROTOXEP in the registrar considerations should have probably been 
replaced by XEP-0308 upon publication.

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

[Philipp Hancke]

I think the expectation is that it's OK to send corrections without
support being known (MUC etc.), as the body itself acts as a
correction even without support and no extra stanzas are involved
(you're going to be sending the correction one way or the other
anyway), but that it'd be smart to tell the sending user that support
isn't know. I'll add some text, ta.


I'd note that the same rationale applies to the (silly) muc service 
replacing the id. No harm, simply works better with services that don't 
behave like this.

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

[Philipp Hancke]

A MUC service might rewrite the id attribute, see
http://xmpp.org/extensions/xep-0045.html#message
"Note well that for tracking purposes this service assigns a new 'id' to
 each message it generates (here using a UUID as defined in RFC 4122)"

I bet some services do this... making the id at the recipient unpredictable.


We should probably fix MUC on this - I hadn't noticed in the examples
what was going on and read the text to mean "The id sent to the room
may not be the id you specified" not "Everyone in the room may get a
different id" - which will break things.


As you pointed out, message receipts is likely affected by this, too,
and http://xmpp.org/extensions/xep-0184.html#when-groupchat does not seem 
to expect id changes either. +1 on fixing MUC, this is somewhat unexpected 
and I doubt that per-participant is really needed for tracking.

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

[Kevin Smith]

On Fri, Aug 10, 2012 at 12:56 PM, Philipp Hancke
 wrote:
> On Fri, 10 Aug 2012, Kevin Smith wrote:
>>>
>>> There's no discussion of whether or not this extension can be used in MUC
>>> rooms, and if so, what if any discovery is required.
>>
>>
>> Will add, ta.
>>
>>> I'd argue that, given the nature of this extension, there's little need
>>> for any discovery. [[Because corrections are likely to be infrequent and
>>> there's fallback built into the protocol.]]  Regardless of whether the
>>> expectation is or is not that clients send corrections without performing
>>> discovery first, the expectation should be stated.
>>
>>
>> I think the expectation is that it's OK to send corrections without
>> support being known (MUC etc.), as the body itself acts as a
>> correction even without support and no extra stanzas are involved
>> (you're going to be sending the correction one way or the other
>> anyway), but that it'd be smart to tell the sending user that support
>> isn't know. I'll add some text, ta.
>
>
> A MUC service might rewrite the id attribute, see
> http://xmpp.org/extensions/xep-0045.html#message
> "Note well that for tracking purposes this service assigns a new 'id' to
>  each message it generates (here using a UUID as defined in RFC 4122)"
>
> I bet some services do this... making the id at the recipient unpredictable.

We should probably fix MUC on this - I hadn't noticed in the examples
what was going on and read the text to mean "The id sent to the room
may not be the id you specified" not "Everyone in the room may get a
different id" - which will break things.

/K

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

[Kevin Smith]

On Fri, Aug 10, 2012 at 1:31 PM, Kevin Smith  wrote:
> On Fri, Aug 10, 2012 at 1:12 PM, Philipp Hancke
>  wrote:
 "Note well that for tracking purposes this service assigns a new 'id' to
 each message it generates (here using a UUID as defined in RFC 4122)"

 I bet some services do this... making the id at the recipient
 unpredictable.
>>>
>>>
>>> Oh, and maybe I can replace your messages.
>>
>>
>> or rewrite the chat history after I left... even a same-fulljid requirement
>> doesn't help against that (is there one currently?)
>
> OK, so I need to add words about not allowing replacement between
> full-JID unavailables (to fix the MUC rejoin) and make sure it's
> explicit that it must be doing  correction only when full-JIDs match.

And also, as Fippo just pointed out to me, never do correction on MUC
join context.

I wonder if we should just not do it unless you have the real JIDs of
the occupants.

/K

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

[Kevin Smith]

On Fri, Aug 10, 2012 at 1:12 PM, Philipp Hancke
 wrote:
>>> "Note well that for tracking purposes this service assigns a new 'id' to
>>> each message it generates (here using a UUID as defined in RFC 4122)"
>>>
>>> I bet some services do this... making the id at the recipient
>>> unpredictable.
>>
>>
>> Oh, and maybe I can replace your messages.
>
>
> or rewrite the chat history after I left... even a same-fulljid requirement
> doesn't help against that (is there one currently?)

OK, so I need to add words about not allowing replacement between
full-JID unavailables (to fix the MUC rejoin) and make sure it's
explicit that it must be doing  correction only when full-JIDs match.

Thanks guys.

/K

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

[Philipp Hancke]

"Note well that for tracking purposes this service assigns a new 'id' to
each message it generates (here using a UUID as defined in RFC 4122)"

I bet some services do this... making the id at the recipient unpredictable.


Oh, and maybe I can replace your messages.


or rewrite the chat history after I left... even a 
same-fulljid requirement doesn't help against that (is there one 
currently?)

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

[Kurt Zeilenga]

On Aug 10, 2012, at 4:56 AM, Philipp Hancke  wrote:

> On Fri, 10 Aug 2012, Kevin Smith wrote:
>>> There's no discussion of whether or not this extension can be used in MUC 
>>> rooms, and if so, what if any discovery is required.
>> 
>> Will add, ta.
>> 
>>> I'd argue that, given the nature of this extension, there's little need for 
>>> any discovery. [[Because corrections are likely to be infrequent and 
>>> there's fallback built into the protocol.]]  Regardless of whether the 
>>> expectation is or is not that clients send corrections without performing 
>>> discovery first, the expectation should be stated.
>> 
>> I think the expectation is that it's OK to send corrections without
>> support being known (MUC etc.), as the body itself acts as a
>> correction even without support and no extra stanzas are involved
>> (you're going to be sending the correction one way or the other
>> anyway), but that it'd be smart to tell the sending user that support
>> isn't know. I'll add some text, ta.
> 
> A MUC service might rewrite the id attribute, see
> http://xmpp.org/extensions/xep-0045.html#message
> "Note well that for tracking purposes this service assigns a new 'id' to
> each message it generates (here using a UUID as defined in RFC 4122)"
> 
> I bet some services do this... making the id at the recipient unpredictable.

Oh, and maybe I can replace your messages.

-- Kurt

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

[Philipp Hancke]

On Fri, 10 Aug 2012, Kevin Smith wrote:

There's no discussion of whether or not this extension can be used in MUC 
rooms, and if so, what if any discovery is required.


Will add, ta.


I'd argue that, given the nature of this extension, there's little need for any 
discovery. [[Because corrections are likely to be infrequent and there's 
fallback built into the protocol.]]  Regardless of whether the expectation is 
or is not that clients send corrections without performing discovery first, the 
expectation should be stated.


I think the expectation is that it's OK to send corrections without
support being known (MUC etc.), as the body itself acts as a
correction even without support and no extra stanzas are involved
(you're going to be sending the correction one way or the other
anyway), but that it'd be smart to tell the sending user that support
isn't know. I'll add some text, ta.


A MUC service might rewrite the id attribute, see
http://xmpp.org/extensions/xep-0045.html#message
"Note well that for tracking purposes this service assigns a new 'id' to
 each message it generates (here using a UUID as defined in RFC 4122)"

I bet some services do this... making the id at the recipient 
unpredictable.

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

[Kevin Smith]

Thanks Kurt.

On Fri, Aug 3, 2012 at 6:24 PM, Kurt Zeilenga  wrote:
>
> On Jul 31, 2012, at 1:52 PM, XMPP Extensions Editor  wrote:
>
>> This message constitutes notice of a Last Call for comments on XEP-0308 
>> (Last Message Correction).
>>
>> Abstract: This specification defines a method for marking a message as a 
>> correction of the last sent message.
>
> Edit suggestion: s/marking/indicating/

Don't feel strongly.

>
>>
>> URL: http://xmpp.org/extensions/xep-0308.html
>>
>> This Last Call begins today and shall end at the close of business on 
>> 2012-08-17.
>
>
> In Section 2, the text "If a server implements message correction" ought to 
> be "If a client implements message correction" or possibly "If an XMPP entity 
> implements message correction".

Thanks.

> I note that the discovery example shows a query against a full jid, which of 
> course requires knowledge of the full jid to perform.  There may be use cases 
> where the full jid is not known.  It may be appropriate to note that 
> decloaking (XEP 276) can be used here.

Will mention decloaking, ta.

> There's no discussion of whether or not this extension can be used in MUC 
> rooms, and if so, what if any discovery is required.

Will add, ta.

> I'd argue that, given the nature of this extension, there's little need for 
> any discovery. [[Because corrections are likely to be infrequent and there's 
> fallback built into the protocol.]]  Regardless of whether the expectation is 
> or is not that clients send corrections without performing discovery first, 
> the expectation should be stated.

I think the expectation is that it's OK to send corrections without
support being known (MUC etc.), as the body itself acts as a
correction even without support and no extra stanzas are involved
(you're going to be sending the correction one way or the other
anyway), but that it'd be smart to tell the sending user that support
isn't know. I'll add some text, ta.

> I thought a bit about correcting messages with multiple body elements, or 
> various elements (e.g., ), and I think the specification is 
> reasonably clear already that the replacement stanza is a complete 
> replacement of the referenced stanza.  But it still might worth being even 
> more clear, adding to the end of 3:  The payload of the original message is 
> completely replaced by the payload of the replacement message payload.

Will do, ta.

> In section 4, I found "To deal with multiple payloads, the sender MUST 
> re-send the entire stanza with only the id and the corrections changed" to be 
> bit confusing as there are other changes to the stanza to be made, in 
> particular the addition of the  element.  Some rewording might in 
> order here.

Will mangle it a bit, ta.

> The specification is not clear as whether a corrected message can be 
> corrected.  I suggest the specification not, without very good reason, limit 
> itself to a single edit.  It sometimes takes me multiple edits to get a 
> message right.  I suggest the XEP state whether or not multiple corrections 
> are allowed, and if allowed, make sure the "re-send" text is appropriately 
> worded and an example provided.

Multiple corrections are fine, but I should make this explicit, ta.

> In the security consideration section, I think the 'warn' in "The replacement 
> message could have an entirely different meaning from the original message, 
> so clients will need to warn users that the displayed message has been 
> edited" is a bit too strong.  I suggest:
>
> The replacement message could have an entirely different meaning from 
> the original message.  The receiving client SHOULD indicate whether a stanza 
> has been replaced.  It is also suggested that the receiving client provide 
> access to the original message.

I don't feel all that strongly one way or the other, will change.

> There are certain sorts of replacements that I think should be precluded or, 
> at least, cause warnings.  For instance, if the original message was 
> digitally signed and the replacement not, it would be appropriate I think to 
> warn the reader.  I would like to see the digital signed issue specifically 
> mentioned in the security consideration section of this XEP.  Additionally, 
> any XEP providing for digital signatures should cover this.

I'll add some text for this.

> Also, it also may be appropriate to limit what portions of the original 
> payload can be altered.   In particular, I believe it generally inappropriate 
> for the original and replacement message to have different XEP 258 labels.  
> This is because different labels implies different authorizations, and this 
> implies that one might receive one or the other of the messages, and this is 
> somewhat problematic in certain security domains.  I might be appropriate to 
> say something like: The XEP 258  element SHOULD NOT be 
> edited.  It might be appropriate to add a note to XEP 258 as well here.

I'll add a note saying that labels shouldn't be repl

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

[Kurt Zeilenga]

On Jul 31, 2012, at 1:52 PM, XMPP Extensions Editor  wrote:

> This message constitutes notice of a Last Call for comments on XEP-0308 (Last 
> Message Correction).
> 
> Abstract: This specification defines a method for marking a message as a 
> correction of the last sent message.

Edit suggestion: s/marking/indicating/

> 
> URL: http://xmpp.org/extensions/xep-0308.html
> 
> This Last Call begins today and shall end at the close of business on 
> 2012-08-17.


In Section 2, the text "If a server implements message correction" ought to be 
"If a client implements message correction" or possibly "If an XMPP entity 
implements message correction".

I note that the discovery example shows a query against a full jid, which of 
course requires knowledge of the full jid to perform.  There may be use cases 
where the full jid is not known.  It may be appropriate to note that decloaking 
(XEP 276) can be used here.

There's no discussion of whether or not this extension can be used in MUC 
rooms, and if so, what if any discovery is required.

I'd argue that, given the nature of this extension, there's little need for any 
discovery. [[Because corrections are likely to be infrequent and there's 
fallback built into the protocol.]]  Regardless of whether the expectation is 
or is not that clients send corrections without performing discovery first, the 
expectation should be stated.

I thought a bit about correcting messages with multiple body elements, or 
various elements (e.g., ), and I think the specification is reasonably 
clear already that the replacement stanza is a complete replacement of the 
referenced stanza.  But it still might worth being even more clear, adding to 
the end of 3:  The payload of the original message is completely replaced by 
the payload of the replacement message payload.

In section 4, I found "To deal with multiple payloads, the sender MUST re-send 
the entire stanza with only the id and the corrections changed" to be bit 
confusing as there are other changes to the stanza to be made, in particular 
the addition of the  element.  Some rewording might in order here.

The specification is not clear as whether a corrected message can be corrected. 
 I suggest the specification not, without very good reason, limit itself to a 
single edit.  It sometimes takes me multiple edits to get a message right.  I 
suggest the XEP state whether or not multiple corrections are allowed, and if 
allowed, make sure the "re-send" text is appropriately worded and an example 
provided.

In the security consideration section, I think the 'warn' in "The replacement 
message could have an entirely different meaning from the original message, so 
clients will need to warn users that the displayed message has been edited" is 
a bit too strong.  I suggest:

The replacement message could have an entirely different meaning from 
the original message.  The receiving client SHOULD indicate whether a stanza 
has been replaced.  It is also suggested that the receiving client provide 
access to the original message.

There are certain sorts of replacements that I think should be precluded or, at 
least, cause warnings.  For instance, if the original message was digitally 
signed and the replacement not, it would be appropriate I think to warn the 
reader.  I would like to see the digital signed issue specifically mentioned in 
the security consideration section of this XEP.  Additionally, any XEP 
providing for digital signatures should cover this.

Also, it also may be appropriate to limit what portions of the original payload 
can be altered.   In particular, I believe it generally inappropriate for the 
original and replacement message to have different XEP 258 labels.  This is 
because different labels implies different authorizations, and this implies 
that one might receive one or the other of the messages, and this is somewhat 
problematic in certain security domains.  I might be appropriate to say 
something like: The XEP 258  element SHOULD NOT be edited.  It 
might be appropriate to add a note to XEP 258 as well here.

I have to wonder if there's other payload elements which should or should not 
be changed during correction.

> 
> Please consider the following questions during this Last Call and send your 
> feedback to the standards@xmpp.org discussion list:
> 
> 1. Is this specification needed to fill gaps in the XMPP protocol stack or to 
> clarify an existing protocol?

I believe this specification fills a small gap in the XMPP protocol stack.

> 2. Does the specification solve the problem stated in the introduction and 
> requirements?

Yes.

> 3. Do you plan to implement this specification in your code? If not, why not?

As a server developer, nothing for me to implement here.

> 4. Do you have any security concerns related to this specification?

Yes, see above.

> 5. Is the specification accurate and clearly written?

For the most part, see above.


> 
> Your feedback is appreciated!