Mark,
You must have thought that I proposed another change than I really did
for issue 1.
The only change I proposed was
------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
In 4.6.3.2, change:
"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."
to
"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."
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
This is a note just intended to remind developers of receiving clients
to code for robustness. If the transmitting side happens to send more
backspaces than there is message for, the excess shall be ignored by the
receiver.
On the transmitting side the action on excess user backspaces depends on
if XEP-0308 support is available of not. I suggest that nothing is added
to describe what the transmitting side does when the user makes excess
backspaces.
In reality, If XEP-0308 is supported and negotiated, then section 6.6.3
sufficiently describes what to do, and your view of what should be done
is good:
For XEP-0308, senders should break a long backspace sequence into
multiple <rtt/>, one for current message, and one for previous message.
Since this is not ignoring excess backspaces, the note is false as it is
and needs my adjustment to be valid only for receivers.
If XEP-0308 is not supported, and the transmitting user makes excess
backspaces, then it is true that they should be ignored, but I do not
want to complicate the sentence by including the different cases for the
transmitter.
4.6.3.2 is too early to start discussing what to do when XEP-0308 is
supported, and what to do when it is not, so I suggest instead just to
be silent here about what transmitters should do with excess
backspaces. It is possible to compose a sentence on it but I do not
think it is necessary. Agree?
Thanks for agreeing on issue 2 on excessive lag
Gunnar
------------------------------------------------------------------------
On 2013-04-09 15:33, Mark Rejhon wrote:
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 <mailto: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 avoidexcess
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
