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

Lance Stout lancestout at gmail.com
Tue Jul 17 23:47:59 UTC 2012

> Imagine situations where the original message took 2 seconds to create (Enter was accidentally hit), but last message editing take minutes.    How do you replace 2 or 3 <rtt/> elements in a proper manner, with over 100 to 1000 <rtt/> elements, while preserving all behaviour of XEP-0301?  You could transmit 1000 action elements in a single <rtt/>, but that becomes quite unwieldly, especially, if you continue, and then go back to edit some more.  So for this reason, I feel that <rtt/> doesn't belong in <replace/>

Ah, I think we had different scenarios playing in our heads then. I was imagining just tagging all of the RTT updates with the <replace /> element referring to the original, complete message that was being changed. Like so:

<message to="alice at wonderland.lit" from="bob at wonderland.lit" type="chat" id="102">
   <body>First Lixne</body>


<message to="alice at wonderland.lit" from="bob at wonderland.lit" type="chat" id="106">
  <rtt xmlns="urn:xmpp:rtt:0" seq="4" event="reset"><t>First Lixne</t></rtt>
  <replace id="102" xmlns='urn:xmpp:message-correct:0'/>
</message>  <!-- begins replacement editing RTT by including <replace /> --> 

<message to="alice at wonderland.lit" from="bob at wonderland.lit" type="chat" id="107">
  <rtt xmlns="urn:xmpp:rtt:0" seq="5"><d p=8/></rtt>
  <replace id="102" xmlns='urn:xmpp:message-correct:0'/>
</message> <!-- replacement editing continues --> 

<message to="alice at wonderland.lit" from="bob at wonderland.lit" type="chat" id="108">
   <body>First Line</body>
   <replace id="102" xmlns='urn:xmpp:message-correct:0'/>
</message> <!-- final replacement body for message 102  --> 

No changes in XEP-0301 behaviour or protocol; in fact, it plays out identically to your proposal, just with more overhead. The advantage is the increased explicitness that those RTT events are happening within the context of last message correction. It just would probably need an update in XEP-0308 to allow this to be compliant. (I would consider RTT events to be messaging content which satisfies the requirement for inclusion of <replace />, but it's borderline enough that it would need clarification in XEP-0308).

Anyway, the above adds a lot of extra bytes in those cases where there are 1000 RTT updates during editing, so your proposed method would be preferable in that regard.

> I can see already that the description of the reset event will need to be updated to cover the new semantics. For example, the current XEP-0301 text does not sound like this method would be acceptable if one attempted to replace a message sent before RTT was enabled.
> That wouldn't be a problem.
> This is because <rtt event='reset'/> is treated exactly like <rtt event='new'/> if there was no existing message.   My version 0.3 update made that clearer.   Can you clarify?

I meant that XEP-0301 makes references to the use of those events in terms of real-time messages, which a message sent before RTT is enabled I would not think qualified under those terms. And, if RTT is enabled and immediately used to edit a message sent before RTT, then the current text mandates that an event="new" be sent instead of event="reset" (since it is the first <rtt /> element containing action elements). A very minor issue and I'm probably just confused by the particular scenario used in your example, but I just want to be sure there isn't an edge case complicating things.

-- Lance
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20120717/37d0628c/attachment.html>

More information about the Standards mailing list