On Wed, Jun 27, 2012 at 5:42 AM, Mark Rejhon <[email protected]> wrote: > 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.
Given reliable underlying streams (i.e. XEP-0198 between the servers) you should, in all of these cases, receive either an unavailable presence from the recipient or receive message bounces if an RTT element is missed. Retransmission seems entirely appropriate when an entity that previously didn't support RTT (e.g. because it was offline) starts to support RTT - but frequent retransmission because some entity along the path has failed seems wrong to me. With that said: If retransmission only occurs during transmission of a stanza that would otherwise have already been sent containing an edit, this is probably not going to have a significant detrimental effect on most networks (although I'm aware of some networks where RTT sounds like a good idea but the extra bandwidth could tip it over the edge), except in the case of these hypothetical 64k and upwards copy/paste messages (and I suspect the XEP should suggest that RTT be disabled for copy/paste messages), which horrify me. /K
