Hello! Thanks for your reply -- your comments are useful in guiding areas that I need to clarify to make sections of XEP-0301 less confusing to others.
On Wed, Mar 7, 2012 at 1:15 PM, Florian Zeitz <[email protected]>wrote: > > The seq was developed, because, it was found in fact to be necessary. > [snip] One of my main points here was that I don't see the use specifically for > reconnects. Upon reconnect it is clearly the sender's responsibility to > start a new session with the receiver. After all the receiver might have > lost all state at that point. Actually, in real practice, disconnects and reconnects are seamless in a lot of software. For example, many mobile chat programs are designed to automatically reconnect (even while in the middle of composing a long instant message) when reception comes back & the original XMPP session timed out due to lack of reception. It is very simple, and very "in-line" with the way of prevailing use cases that are common in certain brands of wireless mobile chat applications (iPhone, Android). Although not all of them do things this way, many of them do the following, for disconnect-reconnect: SITUATION: Automatic disconnect-reconnect cycle done in background EXAMPLE: Cellphone loses reception. Server times out the connection. Spontaneous disconnect. User still has a partially composed message that's not yet sent. WHAT HAPPENS: Chat window stays open. Send button becomes disabled. Partially composed message is not erased (he can copy and paste it somewhere else or reconnect) In polite software design, the chat window is still visible so that the user can still view chat history even though the user lost connection. Often, the user will have a partially-composed message when the chat software suddenly disconnected. (You're on a train that just moved through a tunnel, and the reception suddenly got lost. You've suddenly walked into an elevator, etc) Suddenly, the chat client reconnects in the background, and the chat window becomes "live" again. The user now has an opportunity to send the partially-composed message. Both the seq number, as well as the event='reset' makes really easy (yet still optional) for a chat client to be able to resume the real-time message. I found it a rather simple programming practice in RealJabber because event='reset' behaves exactly like event='new' with the only difference that 'new' starts a new message, and 'reset' starts the current message over. (In RealJabber, event='new' and event='reset' is actually treated identically at the moment) > I think it would be way more sensible to > specify that the first RTT message sent to a resource that was > previously offline needs to have event="new" or event="reset". > For stanzas getting lost on life streams sequence numbers appear like a > sane solution though. > I actually already specify this -- I already mention this as part of the "Error Recovery" -- that a client SHOULD do an event="new" or event="reset" if the user comes back online. It is not currently a MUST because if the client doesn't do it, it is not fatal to interoperability of real-time text -- it just means real-time text automatically resumes a little bit later. (Using fewer "MUST"s is beneficial to a specification) > As stated above I do believe sync should be explicit and instant upon > reconnect. Effectively transmitting everything that has already been > typed every 10 messages just to compensate congestion control seems like > overdoing it to me... > True, I thought so too, and I already specify that sync should be instant upon reconnect. However, the retransmission is only useful for the lost stanzas. Lost stanzas actually does happen in actual practice, mostly caused by bad cellular reception, but also sometimes over unreliable BOSH connections. Also, imagine being lost in a forest or at sea with only 1 bar of reception, and the deaf person needs to make a text-based "phone call" using NG9-1-1 over a real time text protocol (XEP-0301 is one of the candidates). The phone drops and regains reception randomly. XEP-0301 must survive that. It's already being covered in documents internally, as well as in some public documents -- like the proposed IETF document that I already linked to. When real-time text is enabled, sometimes people stop hitting Enter, and start typing large messages (i.e. 500+ characters). For a slow typist, that could mean more than 1 or 2 minutes before real-time text resumes, unless I specified retransmission. That time lost can be dangerous during a Next Generation 9-1-1 telephone call by a deaf person. A single real-time transmission of a few keypresses can often be over 250 bytes (about 500 bytes when including keypress delays) , but can expand to up to 1 kilobyte for or about 400 bytes when including TCP/IP overhead. That would be 2.5 kilobytes over 10 seconds. (About 5 kilobytes if including keypress delays). The average length of an instant message is actually less than 40 characters. So this adds only about 2-3% bandwidth to require retransmission. For a 500 byte message, that includes keypress delays, the retransmission adds only 10% bandwidth (500 extra bytes every 10 seconds of continuous typing). Note that retransmissions are OPTIONAL. (the planned addendum to XEP-0301) Note that no retransmissions occur when no typing is done. (so we don't lose bandwidth during idle moments) Disclaimer: With one of my clients, I have done work to help implement XEP-0301 in a Next Generation 9-1-1 experimental demo, and this retransmission is actually added because of this paid-work experience. Work for NG9-1-1 is currently one of my sources of income for XEP-0301. Side note: I'd rather have us fix implementations than design protocols > to survive them. XMPP does guarantee in-order delivery. > Agreed. It does not, however, impact some other very good reasons to keep 'seq' and the error recovery/optional redundancy. > Which reminds me of something I forgot to mention in my last message. > Unless I overlooked it there is no defined behaviour once 'seq' is > incremented past 2^32-1. Assuming wrap around, it would be nice to have > a note that implementations need to make sure to not accidentally assume > desynchronization when this happens. > You're right -- I knew I should have added a note -- but then I then realized it would take more about 50,000 years for this to happen, and the desynchronization would only be very temporary (it would only last until the next event='new' or event='reset'). Since seq increments once per second during continuous typing, it would take 50,000 years of continuous typing at a default transmission interval, for the wraparound scenario to happen. And if it even did wraparound, the penalty is only a stall of a few seconds caused by not defining wraparound behaviour. Also, some programming languages (i.e. Java) do not have unsigned integers (only signed integers), which compliates trying to a note about an event that would never happen in normal practice. Would you like to suggest an idea of a single-sentence note that can be added? > However, I've found enough reason to keep both <d> and <e> -- but our team > > can still be swayed by further arguments against having both. > > > I like that approach. Always having cursor repositioning implicit in the > edit actions seems compelling to me. At that point having both <d/> and > <e/> would not seem as icky to me either. As I understand it the main > change here would be that <d/> and <e/> are redefined to perform > absolute repositioning of the cursor instead of performing a relative > movement of 0 and -1 respectively. This also addresses my other concern > about the possibility of positioning the cursor outside of the text. Actually, there's a bit of a confusion here: XEP-0301 always use absolute cursor positioning for all action elements. Cursor positioning has never been relative for XEP-0301. No action element in XEP-0301 depended on the cursor position of the previous action element. I suspect that your confusion might be caused by the fact that "n" is relative, but "p" is always absolute. The omission of "p" simply means the cursor is absolutely put at the end of the line (p = length of real time message), as specified by section 4.5.1.3 "Rules for Attribute Values" .... And section 4.5.3 say to always keep the cursor within the confines of the real-time message. http://xmpp.org/extensions/xep-0301.html#rules_for_attribute_values However, yes, I agree, this is probably confusing. I am now re-wording things to try to clear up confusion; I will contact you later with a draft wording to confirm, before submitting v0.2 of XEP-0301 to XSF. You are right, I confused you, so I will fix the spec to avoid that. > Interop problems are always unfortunate, but again I'd rather see them fixed than designing protocols to work around them. > Agreed, agreed! I do agree some justifications are not good (i.e. out-of-order message delivery). However, the below fully justifies the usage of rudimentary (and mostly optional) error recovery that XEP-0301 supports: -- Wireless reception is not always good. We can't always do perfect wireless signal. -- And a group of us needs to meet requirements for mission-critical reliability of Next Generation 9-1-1 Thanks, Mark Rejhon
