[Standards] NEW: XEP-0308 (Last Message Correction)- Interop with XEP 0301 RTT
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.
> 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
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.
> Mark Rejhon
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Standards