On Aug 13, 2012, at 9:22 AM, Kevin Smith <[email protected]> wrote:
> On Mon, Aug 13, 2012 at 5:15 PM, Kurt Zeilenga <[email protected]> > 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 <replace/> 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 <replace/> 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
