Am 07.03.2012 03:38, schrieb Mark Rejhon: > > The seq was developed, because, it was found in fact to be necessary. > -- Disconnect and reconnect cycles. Including those caused by bad wireless > reception (WiFi, 3G, mobile phone) > -- Not all servers support offline message delivery. > -- BOSH failures in a web browser at the client side (i.e. intermittent > HTTP request failures) > -- And less often, situations of extreme congestion has happened. > My XEP-0301 is intentionally designed to survive a wide variety of > situations that have actually happened in my tests. This attribute is > critical to my applications, as well as Next Generation 9-1-1 experimental > demos. See http://tools.ietf.org/html/draft-tschofenig-ecrit-xmpp-es-00 ... > "Emergency Services Functionality with the Extensible Messaging and > Presence Protocol (XMPP)", section 4.5 mentions XEP-0301 as one of the > possible functionalities that may become a part of NG9-1-1. Real-time text > technologies here is very useful for accessibility too; as it replaces the > need to carry around a teletypewriter (TTY). > 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. 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.
> We need to keep the 'seq' attribute, as it is essential for message > integrity during less-than-ideal situations. I actually expanded it to > recommend an event='reset' once every 10 XMPP messages, to improve > resilence even further -- the latest version of RealJabber now does this. > (you can the new RealJabber on two computers -- and test this concept by > disconnecting-reconnecting in the middle of a conversation while the other > person is still typing real-time in RealJabber, and the real-time text > recovers automatically within a few seconds of reconnecting because of the > automatic event='reset' occuring at regular intervals.) > 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... > Also, very rarely (it only happened on BlackBerry's Google Talk client) > when you've transmitted several XMPP messages simultaneously (i.e. network > congestion) and they all get the same timestamp, and then they get > delivered out-of-order (wrong order) that they were transmitted. This > should never happen, but it actually occasionally does. An earlier > version of XEP-0301 was more complex, having a 'msg' attribute for message > number. That was removed, reduced down to just one 'seq' value for > simplification. > Side note: I'd rather have us fix implementations than design protocols to survive them. XMPP does guarantee in-order delivery. > -- 'seq' does not need to start at 0. I'll eliminate that requirement > (clarification) > -- You can change the 'seq' value anytime there's an event='new' or > event='reset'. > Setting it back to 0 again works, although I prefer not to reset it to 0 > because of the danger of a user disconnecting while seq='0' and > reconnecting after it's incremented, reset back to '0' again, and > incremented to '1', and the user had reconnected, getting consecutive seq > numbers for totally different real-time messages that were never delivered. > In this case, the wrong <rtt> will be displayed, resulting in rare text > scrambling. This actually happened once in my random testing, so I stopped > resetting seq back to 0 everytime there was an event='reset'. > 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 are right, that 'start' and 'cancel' is not really required, so I may > be removing them. However, I think that 'cancel' may still be necessary to > signal the other recipient to stop transmitting incoming <rtt> for the > remainder of the chat session, in order to save bandwidth, whenever the > recipient wants to turn off RTT (i.e. via a button or switch, while in > middle of conversation). So there's still a usefulness for 'cancel' even > if 'start' is not neeed (the start of RTT during a chat session is simply > the first delivery of an <rtt> element.) > I'm not convinced "cancel" is needed. Not advertising the disco feature seems perfectly sufficient to avoid receiving RTT messages. I'm doubt there are cases where this is a per contact choice, or RTT would be disabled after half a conversation. It would also always be possible to politely ask the sender to turn off RTT as a last resort. > We have to keep "Unicode code points" (more on that later) but I agree that > normalization paragraph is definitely confusing, so I've modified it to the > following wording: > * > * > * "For interoperability of p and n values, processing MUST be done on > the transmitted Unicode real-time message. For senders , this is the > version of the Unicode message text after any Unicode normalization, > emoticon graphics images conversion to Unicode, display text > formatting, processing of Unicode combining marks, etc. For recipients > obtaining text from the <t> element, this is the Unicode text immediately > after XML processing, and before any further processing. From the > perspective of p and n values, a real-time message is treated as an > editable array of Unicode code points."* > This text seems fine to me. Notice that I did never question code points were the right thing to count. I fully agree with you there. > Also, I've actually stopped using <c/> because I realized an empty <t > p='#'/> element does exactly the same thing as <c p='#'/> ... > Therefore I am actually thinking of removing two action elements from the > next XEP-0301 > - Remove <c/> because I can use empty <t/> to do exactly the same thing. > - Remove <g/> because I can use XEP-0224 instead successfully anyway. > That reduces the number of action elements to just 4, and it makes it easy > to merge Tier 1 with Tier 2 into one unified table for simplicity. > 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. > Error recovery is actually simpler than it looks -- it consumes less than > 5% of the source code in RealTimeText.cs > One of my business clients had serious problems without error recovery (we > had an attempt to make it optional), so we actually expanded Error Recovery > to RECOMMEND event='reset' at regular intervals, such as once every 10 > <rtt> messages (or once every 10 seconds). Also, sometimes you can't > detect online/offline transitions, for example, Google Talk network > sometimes can't see the online/offline status of jabber.org users, and you > can have RTT conversations with users that appear offline (i.e. invisible). > Starting a RTT conversation with an already offline user should be impossible due to the requirement to check the stream feature. Also I tend to believe that when invisible users are talking to someone they should "smoke out" (as someone called it) first. Meaning an invisible user should send directed presence to whomever he is going to message first. Interop problems are always unfortunate, but again I'd rather see them fixed than designing protocols to work around them. I'm glad I could provide some helpful feedback, Florian
