Hello, (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="[email protected]" from="[email protected]" type="chat" id="100"> <rtt xmlns="urn:xmpp:rtt:0" seq="0" event="new"><t>*First*</t></rtt> </message> <message to="[email protected]" from="[email protected]" type="chat" id="101"> <rtt xmlns="urn:xmpp:rtt:0" seq="1" ><t>* Lixne*</t></rtt> </message> <message to="[email protected]" from="[email protected]" type="chat" id="102"> <body>*First Lixne*</body> </message> <message to="[email protected]" from="[email protected]" type="chat" id="103"> <rtt xmlns="urn:xmpp:rtt:0" seq="2" event="new"><t>*Second*</t></rtt> </message> <message to="[email protected]" from="[email protected]" type="chat" id="104"> <rtt xmlns="urn:xmpp:rtt:0" seq="3"><t>* Line*</t></rtt> </message> <message to="[email protected]" from="[email protected]" type="chat" id="105"> <body>*Second Line*</body> </message> <message to="[email protected]" from="[email protected]" type="chat" id="106"> <rtt xmlns="urn:xmpp:rtt:0" seq="4" *id="102"* event="reset"><t>*First Lixne*</t></rtt> </message> *<!-- begins replacement RTT by referencing message 102 -->* <message to="[email protected]" from="[email protected]" type="chat" id="107"> <rtt xmlns="urn:xmpp:rtt:0" seq="5"><d p=8/></rtt> </message> *<!-- deletes the letter "x" -->* * * <message to="[email protected]" from="[email protected]" type="chat" id="108"> <replace *id="102"* xmlns='urn:xmpp:message-correct:0'/><body>*First Line *</body> </message> *<!-- final replacement body for message 102 -->* The advantages of the above, is that it's backwards compatible in all situations: - 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" behavior.* __ 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)? Thanks, Mark Rejhon
