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

Mark Rejhon markybox at gmail.com
Tue Jul 17 21:38:20 UTC 2012


(scroll below to see a proposed XEP-0301 modification to gain full benefits
of XEP-0308)

One person in our group has been quite determined to see last message
correction be made compatible with real-time text (i.e. make XEP-0308
compatible with XEP-0301).   I am reluctant to further complicate the RTT
specification, and this can easily be done as a private extension, but the
situation arises where someone wants to be able to edit the last message
"in place" in real-time, by knowing which message is being edited.

I need opinion if this can stay as a private extension (for now -- because
it can fairly safely be added in a backwards compatible manner later),
since I feel talking so much about interactions between XEP-0301 and other
still-experimental standards (such as XEP-0308), is not productive at this
early stage as almost no chat programs take advantage or XEP-0308 yet.
However, one of the members in the Real Time Text Taskforce has been pretty
interested in this, despite the high probability that this wouldn't be
beneficial for public interop the next several years.   (And for single
vendor solutions, it can still be used as a private extension to XEP-0301
for now, between their own brands of clients for now).

Here's a 9-stanza example, of last-message editing.
All 9 stanzas are pre-existing XMPP standards, with the sole exception of
the 7th stanza (the 3rd last one) where I add an 'id' attribute to <rtt/>
containing an event 'reset' attribute.  (subsequent <rtt/>'s then go
editing that specifically referenced message).

<message to="alice at wonderland.lit" from="bob at wonderland.lit" type="chat"
   <rtt xmlns="urn:xmpp:rtt:0" seq="0" event="new"><t>*First*</t></rtt>

<message to="alice at wonderland.lit" from="bob at wonderland.lit" type="chat"
    <rtt xmlns="urn:xmpp:rtt:0" seq="1" ><t>* Lixne*</t></rtt>

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

<message to="alice at wonderland.lit" from="bob at wonderland.lit"
type="chat" id="103">
    <rtt xmlns="urn:xmpp:rtt:0" seq="2" event="new"><t>*Second*</t></rtt>

<message to="alice at wonderland.lit" from="bob at wonderland.lit"
type="chat" id="104">
   <rtt xmlns="urn:xmpp:rtt:0" seq="3"><t>* Line*</t></rtt>

<message to="alice at wonderland.lit" from="bob at wonderland.lit"
type="chat" id="105">
   <body>*Second Line*</body>

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

<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>
</message>  *<!-- deletes the letter "x" -->*
<message to="alice at wonderland.lit" from="bob at wonderland.lit"
type="chat" id="108">
   <replace *id="102"* xmlns='urn:xmpp:message-correct:0'/><body>*First Line
</message> *<!-- final replacement body for message 102  -->*

The advantages of the above, is that it's backwards compatible in all

- Clients that support XEP-0308 only
*The real time text is ignored.  (Note: This case shouldn't happen anyway
if the client complies properly with "Determining Support" and refrains
from transmitting rtt if disco says it is not supported)*

- Clients that support XEP-0308 and pre-existing XEP-0301 (non-retroactive)
*The real time text will show up separately (as if it was a new message),
then the old message gets replaced with it when completed.  It would not
know which message the real time text is editing, but the real time text
remains usable!   (This is the prviate extension use case)*

- Clients that support XEP-0308 and updated XEP-0301
*It's possible for the client to display the real time text 'in place' of
the previous message.  Since the id parameter of the first <rtt/> element
of a retroactive edit, allows implementors to know which message is now
being edited, the real-time editing can be presented "in-place" in the
previous message if desired.*
*- *Will still work fine when users switch computers, etc.
*Any last-message edit attempts that occur to nonexistent messages that
have not been received (i.e. recipient logs on after the sender already
transmitted the last message, and that last message was already delivered
to a different login) -- it will just be treated as if it was a new
message, so the last message is displayed as a new message.  Still "usable"


Right now, my opinion is that because I don't even see implementations
using XEP-0308 yet (not even Pidgin!), I feel it is too early to add this
capability to XEP-0301.  It is my opinion that it is not the end of the
world, and is only of interest to vendors who want interoperability with
widepspread clients that has last-message editing.  (And right now, that
doesn't exist yet).

NOTE: One past suggestion was to use <replace/> for <rtt/> but that isn't
practical.  Sometimes there's just one or two <rtt/> and sometimes there's
hundreds of <rtt/> for one message, and sometimes it's just one keypress,
while others are huge numbers of key presses, and there's also a need to be
able to preserve key press delays (via Wait Interval elements <w/>).  So
the rule would be to not include <rtt/> elements in <replace>, but instead
to add an optional message 'id' attribute to the <rtt event='reset'/>
element and allow XEP-0301 last message editing to run independently of
XEP-0308, while allowing merging of UI behaviour of the two for
implementers that implements both.

Does anyone outside the Real Time Text Taskforce, think I should expand the
XEP-0301 standard to allow implementors to do in-place real-time text of
last message, by the addition of the 'id' parameter?
Or since it's a backwards-compatible modification, I should wait until
XEP-0308 is considered a Draft standard before adding it to XEP-0301?
Personally, my opinion is that it is 5 years to early, the one vendor that
might really need it today, can use a private extension for now, knowing
that it's backwards compatible.

Opinions about updating XEP-0301 to allow the optional id attribute for
<rtt event='reset'/> elements?  (for seamless operation with XEP-0308)?

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

More information about the Standards mailing list