On Wed, Jun 27, 2012 at 12:01 AM, Peter Saint-Andre <[email protected]>wrote:
> On 6/26/12 5:58 PM, Mark Rejhon wrote: > > About section 4.6.4 of XEP-0301: > > http://xmpp.org/extensions/xep-0301.html#message_retransmission > > > > 1. When the recipient's presence changes. (i.e. offline to online) > > > > So let's say you are typing a message to me and my presence changes > from > > normal availability to do not disturb or whatever. Why does your > client > > need to retransmit what you have typed so far? Are there specific > > presence scenarios that you have in mind here? > > > > Problem: Without retransmit > > - Sender: Starts typing message while recipient is offline > > Why is the sender generating RTT messages if it doesn't know whether the > recipient supports the protocol? > No, I think I mis-worded. Sorry. Let me try again -- The sender is not generating RTT messages while the recipient is offline. The sender waits until the recipient is online, then start sending RTT mid-message when the recipient logs on. This is assuming RTT is already turned on / already accepted. (Note event='reset' does not require a preceding event='new'. It's okay for event='reset' to be the first RTT ever received.) The sender and recipient needs to do no further initiating action if both ends have RTT configured to be on and auto-accepted. Let me re-phrase: 1. Sender is typing a message while a recipient is offline. 2. No RTT elements is transmitted. 3. Recipient logs on and reopens window to the same sender. 5. Sender software notices the recipient logs on begins sending RTT (Beginning with transmitting the whole partially-typed message first via message retransmission via event='reset') 6. Recipient software sees the sender's whole partially-typed message message immediately, and continues being able to read the continued typing 7. The sender is continuously typing through all these steps, easily unaware that the software has automatically 'caught up' the real time text. Perhaps the confusion is the terminology used, "message retransmission" should be called "message catchup event" instead, when it's used during the offline-back-to-online cycle. But we're also considering this scenario too: 1. Sender is typing a message while a recipient is online. 2. Recipient is reading real time text. 3. Sender is continuously typing (recipient is online, with intact RTT) 4. Recipient loses wireless reception / server timeout / disconnects / logs off-on cycle / server reboots / crashes / restarts / whatever 5. Sender is continuously typing (recipient now observed to be offline, so RTT transmission automatically stops) 6. Recipient comes back online. 7. Sender is continuously typing (RTT message retransmission event occurs, and then RTT resumes) 8. Recipient software sees the sender's whole partially-typed message message immediately, and continues being able to read the continued typing 9. The sender is continuously typing through all these steps, easily unaware that the software has automatically 'caught up' the real time text. 10. Everything has resumed gracefully regardless of what happened in step 4! 11. In fact, the sender and recipient may be unaware what has happend (i.e. server reboot / wifi loss-regain / software auto disconnect-reconnect) and everything is blissfully good. We cannot require waiting for the next message for resumption of real-time text. Real-time text (XEP-0301) MUST be designed to auto-resume on the fly in all situations. This is a requirement of XEP-0301. In fact, there's an additional situation, by modifying steps 4 through 8: [same steps 1,2,3] 4. Recipient closes window, or recipient crashes (server has to timeout first). Sender doesn't notice recipient going offline. 5. Sender is continuously typing (Recipient still appears 'online', RTT still transmitting & becoming lost) 6. Recipient reopens window, or recipient restarts software. Sender doesn't notice recipient has come back. 7. Sender is continuously typing (RTT is continuing normally, with automatic message reset occurs every 10 seconds according to section 4.6.4). 8. Within 10 seconds, recipient software sees the sender's partially-typed message come back. [same steps 9,10,11 as above] See, automatic resumption of real-time text occurs regardless of what happens (wireless reception / server timeout / disconnects / intermittent WiFi / logs off-on cycle / server reboots / client crashes / client restarts / window open+close / MUC room exits and joins / etc) and regardless of whether or not recipient notices any offline/online status changes, even if the JID remains completely unchanged. If the retransmission in 4.6.4 is not desirable, can you tell us how to _universally_ satisfy ALL scenarios _reliably_. We require immediate resumption of RTT, without waiting for the start of a new message. Ideas are welcome for improvements to section 4.6. Peter? Anyone? Thanks Mark Rejhon
