Hello Gunnar, Thanks for your comments about XEP-0301 In-Band Real-Time Text:
On Tue, Apr 9, 2013 at 2:02 AM, Gunnar Hellstrom < gunnar.hellst...@omnitor.se> wrote: > It is good to see a new version of the XMPP Real Time Text extension. > [snip] > On 2013-04-08 17:47, XMPP Extensions Editor wrote: > URL: http://xmpp.org/extensions/xep-0301.html > [/snip] The general impression is that it is in a good and mature condition. > I have a couple of small comments. > > 1. Erasure over message border. > In 4.6.3.2, it is said about the Erase element: > "Note: Excess backspaces MUST be ignored. Thus, text is backspaced only > to the beginning of the message, in situations where n is larger than p." > This can be perceived in three ways. Support of XEP-0308 for last message > correction may change the situation a bit. > > 1. Seen from the transmitting user perspective, with XEP-0308 support, > backspacing over the message border may be the natural way to return to the > previous message and make a small correction. Without XEP-0308 support, > the statement is true. > > 2. Seen from the transmitting client perspective. If XEP-0308 is > supported, then a user backspace at the beginning of the message should not > be ignored, but instead activate last message correction, providing a > <reset/> and start acting in the previous message. IF XEP-0308 is not > supported, then the statement is true. > > 3. Seen from the receiving client perspective, the statement is true. > "Excess" backspaces shall be caught by the transmitting client and either > ignored or caused to generate the move to the previous message before > continuing to erase, depending on XEP-0308 support. > > I suggest that the XEP-0308 influence is kept largely isolated to section > 6.6.3 and therefore no discussion on its influence put in here. > This proposed change would increase client complexity (on average) for BOTH the sender and recipient. Not good. For XEP-0308, senders should break a long backspace sequence into multiple <rtt/>, one for current message, and one for previous message. This is simpler and isolates complexity only to senders. See this section to understand why your change is bad: http://xmpp.org/extensions/xep-0301.html#usage_with_last_message_correction 1. Refer to previous discussions, many hours were spent (in two different months, I believe) discussing over: - XEP-0301 and XEP-0308 sent to clients that only support XEP-0301 - XEP-0301 and XEP-0308 sent to clients that only support XEP-0308 - Etc. (I often listed 5 situations). To prevent refreshing people's memory yet a third surge of messages in a row; search this mailing list for previous "XEP-0301 + XEP-0308" discussions and read the big message-surges on this matter. We ended up mostly agreeing disco should prevent such things, and maybe it won't be used mixed in group chat (but the ability is there anyway to use XEP-0301 and XEP-0308 safely in a mixed-mode manner in a groupchat, in theory -- if an implementer REALLY wanted to do so). I like a robust standard that can degrade gracefully in as many situations as possible. The way it's coded right now, already maximizes 'reasonable' fallback behavior. The suggested change would break this elegance that was already discussed. 2. Last message may not exist on recipient. See "Keeping Real-Time Text" synchronized for some cases where this can happen: http://xmpp.org/extensions/xep-0301.html#keeping_realtime_text_synchronized Theoretically, the sender could try to monitor for some of these (but not possibly all), but that's additional complexity on both the sender and recipients. It is simpler the way they are currently, the XEP-0301 requires a Message Refresh everytime you go back to the previous message, so that recovers the previous message (even if it may be handled as a current message due to an 'id' parameter pointing to a missing message). The behavior becomes more predictable with the existing specification in this edge case, and the proposed change would worsen this inconsistency. 3. Message #1, #2, #3 was sent, but recipient only has message #1 and #3 (see "Keeping Real-Time Text Synchronized" again). This would cause backspacing into the wrong message. The proposed change is non-deterministic, while my current spec is currently more deterministic. This is because the XEP-0301 spec requires an "id" attribute referencing the correct message to modify. A recipient would realize that #2 is missing and either blindly treat missing id's as a message correction to the current message (graceful fallback behavior, because of the Message Refresh eliminates conflict between the two messages; I already explained the graceful fallback behavior) or re-populate the message immediately preceding (another possible behavior). Again, XEP-0308 requires a message refresh on the correct message "id" so message #2 would reappear one way or another. So in such situations it would behave as a message-switching-in-place between the previous message and the next message. If we just let senders handle the complexity of breaking long backspaces into two, here's an example of graceful fallback behavior in an XEP-0301 recipient that has a missing Last Message, following current XEP-0301 and XEP-0308 to a tee, this is what would happen: As the sender backspaces to previous message, this is what happens on the recipient side: The full copy of current real-time message instantly changes to a full copy of the previous message (not already existing on recipient anyway) because a message refresh was sent as required, edits made while they are received, then when finished a <body> is received which re-commits the previous message that didn't already previously exist and now the previous message exists permanently, the newer real-time message instantly reappears (message refresh was sent, as required), edits continues, and then commited as <body>, now two permanent messages in a row, exist on recipient instead of just one (the missing message essentially "came back"). The sender didn't know the last message was missing from the recipient. Nor did the recipient know there was a last message. Yet it still worked because the current protocol was followed! This is GRACEFUL fallback behavior. Some *minor* UX problem (real-time message buffer refreshing in place back-and-fourth a copy of last message and a copy of current message), but no text corruption occurs. Corruption is MUCH WORSE than this graceful fallback behavior. My proposal is to keep things the way they are, the sender clients simply break long sequences of excess backspaces into two separate message stanzas, one with <rtt/> (without an "id" attribute) addressed to the current message, immediately followed by another <rtt/> (with an "id" attribute) to modify the previous message. This will maximize backwards compatibility. Recipients SHALL continue to ignore excess backspaces within the same <rtt/>. We prefer that the complexity remain in the sender (handling breaking backspaces into separate messages), rather than the recipient (figuring out wrapover for excess backspaces), to maintain maximum backwards compatibility & protocol elegance in unusual & adverse edge cases. In fact, it brings up a new discussion too: Whether or not to commit the current message first using a <body> in between the message stanzas, once backspacing for current message is finished. The way the spec works right now is skipping doing so, would still degrade gracefully (reasonable fallback behavior of message switching) regardless of whether this was done. The UX probably would be better if the <body> was sent, but "at the end of the day" you essentially have the same result once the sender finished both messages (two complete permanent committed messages). > Instead, if anything shall be done, I suggest to just insert words "by the > receiving client", so that the note reads: > "Note: Excess backspaces MUST be ignored by the receiving client. Thus, > text is backspaced only to the beginning of the message, in situations > where n is larger than p." > > 2. Risk for excessive lag. > In "6.5 Receiving Real-Time Text", I think this text is scaring: > "In processing Element <w/> – Wait > Interval<http://xmpp.org/extensions/xep-0301.html#element_w_wait_interval>, > excess lag in incoming real-time text might occur if multiple delayed > <rtt/> elements suddenly get delivered" > > I think that in most applications, the users prefer rapid presentation > over exact replication of timing of typing. > An easy way out is to be just a little bit more prescriptive: > > "In processing Element <w/> – Wait > Interval<http://xmpp.org/extensions/xep-0301.html#element_w_wait_interval>, > excess lag in incoming real-time text might occur if multiple delayed > <rtt/> elements suddenly get delivered (e.g. congestion, intermittent > wireless reception). Recipients should avoid excess sustained lag by > monitoring the queue for excess <w/> action elements (e.g. unprocessed <w/> > elements from more than one <rtt/> element before the latest received ) > and then ignoring or shortening the intervals in <w/> elements. This allows > lagged real-time text to "catch up" quickly." > This is a reasonable change. > These two comments are on a level that could be left without action. I > think that the draft is good now and can be taken through last call as was > discussed already for the previous version. > I would like people's opinion on the brand new "4.3 Processing Rules" section: http://xmpp.org/extensions/xep-0301.html#processing_rules It actually significantly shortened/simplified the "4.2 RTT Attributes" section http://xmpp.org/extensions/xep-0301.html#rtt_attributes It recently helped some implementers (including one from Gallaudet University who just joined this mailing list). But, it needs far more peer review, and it feels somewhat redundant to some text already in "4.7 Keeping Real-Time Text Synchronized" http://xmpp.org/extensions/xep-0301.html#keeping_realtime_text_synchronized However, some people don't say it's redundant. Thanks, Mark Rejhon
