On Wed Jul 11 22:33:31 UTC 2012, Gregg Vanderheiden <[email protected]> wrote:
> Well one thing missed is that the emergency responder (9-1-1 PSAP) is > always responding. > So I think you should have it that the first message from EITHER party > should be able to use <rtt/> to ping. > What about if you are in the middle of a message and it becomes clear that > it should move to rtt? Good news -- This is already covered -- There are multiple mechanisms: 1. An implementer can choose to simply transmit the whole contents of the partially-composed message in a new real-time message via <rtt event='new'/>. Instead of the first key presses, it's the whole partially composed message being transmitted all at once. Much like a Message Reset - except you're using 'new' instead of 'reset'. 2. An implementer can choose to use Message Reset to transmit a partially-composed message that you started composing while real-time text was turned off. http://xmpp.org/extensions/xep-0301.html#message_reset Using <rtt event='reset'/> is a legal first <rtt/> element of a conversation. It is legal to use event='reset' without using event='new' first. http://xmpp.org/extensions/xep-0301.html#event I also mention that senders can start typing before a recipient logs on (see top of section 4.6). http://xmpp.org/extensions/xep-0301.html#keeping_realtime_text_synchronized I would suggest approach #2 since it signals that the message was already composed, rather than being a new message. It bears mentioning that the event attribute values of 'new' and 'reset' has been made virtually identical now, and some XEP-0301 implementations can treat both 'new' and 'reset' as exactly identical with no implemented differences at all. However, rich clients can implement distinguishing behavior if they wish to do so -- e.g. recording the start time of a message compose, or signalling differently for new versus existing real-time messages. (such as recipient logging on after sender starts composing). All of which would not be possible if new/reset is merged. Thanks Mark Rejhon
