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

Gunnar Hellström gunnar.hellstrom at omnitor.se
Fri Jul 20 06:16:11 UTC 2012

On 2012-07-20 07:17, Mark Rejhon wrote:
> On Fri, Jul 20, 2012 at 1:02 AM, Gunnar Hellström 
> <gunnar.hellstrom at omnitor.se <mailto: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 compatible.
OK, I modify the end of my proposal to: " then reception of real-time 
editing of last message MUST be supported."

>     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 intervals.
We already have key-press intervals in examples.
It is a risk that real-time editiing of last message will not be fully 
understood without an example.
>     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?
What are your thoughts on this?  I guess that you think about completing 
the edits and send a <body> with replace before sending any edits in the 
current message. Is that required? Do you think it is implied by saying 
that a 'reset' or other event is needed when you move to editing another 
>     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 issue.
> However, I can change the word "improved" into "enhanced" or other 
> appropriate word.
Your current sentence is:

"to have improved presentation of real-time textduring message correction"

Without the added feature of real-time edit, there is no presentation of real-time text during message correction. There will be a freeze and wait until the edit is done and sent as an XEP-0308 replace. So there is nothing there that can be enhanced or improved. Real-time text presentation during correction is introduced by the feature.
therefore my proposal is still:

"to have presentation of real-time textduring message correction"

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

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

More information about the Standards mailing list