[Standards] NEW: XEP-0308 (Last Message Correction)- Interop with XEP 0301 RTT

Mark Rejhon markybox at gmail.com
Fri Jul 20 05:17:20 UTC 2012

On Fri, Jul 20, 2012 at 1:02 AM, Gunnar Hellström <
gunnar.hellstrom at omnitor.se> wrote:

>  1. I suggest that you add a small section "6.5.7 Editing last message."
> with general application information of this feature.
> Extensions should not be intertwined by too much information about each
> other, but some basic information would be in place here.
> Proposal:
> The last completed message can be edited through combined use of the *id*
> attribute of <rtt/> and application of XEP-0308 [ ]. If both XEP-0301 and
> XEP-0308 support is discovered and accepted, then real-time editing of last
> message MUST be supported.

This is unnecessary, as I already explained it is backwards compatible, and
Kevin did say it can be supported as-is.   I believe vendors should have
the choice of 0301+0308 without enhanced retroactive RTT, and the
suggestion I made (that was +1'd by Peter, Kevin, and Lance) is backwards

2. I suggest that you add a use case "7.5 Example of edit last message"
> with a short sequence of editing last and returning to editing new.
> Something based on the examples you have circulated would be fine.

Good idea, but there are a massively huge number of far higher-priority
examples I would like to introduce first (e.g. improved key press interval
examples).   I am aware you are also a strong advocate of key press

> 3. Would you consider that a sentence is needed towards the end of your
> proposed section on *id*  saying
> "Before switching from last message editing to current message editing,
> the completed last message MUST be committed according to the rules of
> XEP-0308 [ ].
> Or do you think that that is obvious, or do you intend that jumping back
> and forth between last and current may appear without committing the
> replacement of the last for every such jump to current?
> 4. I suggest the you delete the word "improved" on line 3. It is not about
> improving real-time presentation, t is about providing it at all.

This is not true.  I explained it was 100% backwards compatible, even it
was already pointed out and agreed that UX (User eXperience) may be strange
but nontheless acceptable.  Thus, an implementation rather than an interop
However, I can change the word "improved" into "enhanced" or other
appropriate word.

>  5. I suggest that you delete the words "at all" in the middle of the *id*
> section. "used" is sufficient.

Good idea.

Mark Rejhon
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20120720/0b0be722/attachment.html>

More information about the Standards mailing list