[Standards] review of XEP-0301, sections 1-5 (Advice needed on Peter's comments)
markybox at gmail.com
Wed Aug 22 19:24:55 UTC 2012
I've managed to address most of Peter's section 1-5 concerns.
However, for the remainder -- I need advice from anyone on unaddressed
parts of Peter's comments about XEP-0301 (
There are only five major areas of clarifications I need relating to
Peter's recent comments.
******* CLARIFICATION #1 ********
Issue: Should I define an Implementation note about how sender clients
should handle enabling/disabling of real-time text while in the middle
of composing a message. (e.g. sender user types a message partially,
and then clicks a button to deactivate real-time text, then resumes
typing, etc). This is not covered in the spec, and might not be
clear to all. (Context from Peter below)
On Fri, Aug 17, 2012 at 11:00 PM, Mark Rejhon <markybox at gmail.com> wrote:
>> What if the sending client disables RTT? Does it send a message with a
>> body element and then no subsequent messages containing <rtt/>
>> elements? Does it need to signal that it has disabled RTT? Could
>> 'cancel' be used for that purpose?
> (1) Sender disabling RTT while in the middle of typing shouldn't
> automatically send a body element. The user should hit Enter or click
> Send, before the message is transmitted. Turning off audio/video
> abruptly stops audio/video, so turning off RTT should abruptly stop
> real-time text. The message is still be waiting in the sender's send
> textbox, still in the middle of being composed -- and the sender might
> want to finish composing the message without RTT. The <body> only
> occurs when the message is actually "sent" (send button or hitting
> Enter as usual).
> (2) The sender software preferably should send <rtt event='cancel'/>
> (the only element transmitted in response to a user manually disabling
> RTT). When I say "clients", that means either the sender or
> recipient, either or both ends can transmit <rtt event='cancel'/>.
> It's not necessary for the receiver of <rtt event='cancel'> to
> automatically transmit <rtt event='cancel'>
> Maybe a note is needed to mention about this somewhere?
(MUC discussion in original message snipped out for brevity, this is
covering one-on-one chat only)
******* CLARIFICATION #2 ********
Issue: Confusion about XEP-0308, about the use of refreshing the
message (message reset) during the beginning of editing a new message
Context from Peter:
>> 13. "This id attribute refers to the <message/> stanza containing the
>> <body/> that is being edited (See 'Business Rules' in XEP-0308). When
>> used, id MUST be included in all <rtt/> elements transmitted during
>> message correction of the previous message. The whole message MUST be
>> retransmitted via <rtt event='reset'/> (Message Reset) when beginning
>> to edit the previous message, or when switching between messages (e.g.
>> editing the new partially-composed message versus editing of the
>> previously delivered message)."
>> Examples would help here. In particular, when you say "the whole
>> message MUST be retransmitted" I assume that means something like this:
> The actual existing text is: "The whole message MUST be retransmitted
> via <rtt event='reset'/> (Message Reset) when beginning to edit the
> previous message, or when switching between messages (e.g. editing the
> new partially-composed message versus editing of the previously
> delivered message)."
> I don't say retransmitting the message via <body>. Just only via <rtt
> event='reset'/> at the beginning of beginning to edit a message.
> Can you clarify how I can fix the sentence, to be more clear? As
> explained in talks between me and Kevin, the Message Reset is useful
> to re-populate the real-time message buffer with the text of the
> message currently being edited; and this also allows it to function
> properly even if the sender lost chat history, improves compatibility
> with concurrent logins and MUC, and this also allows graceful
> backwards-compatibility degradation so it doesn't "fail ungracefully"
> (e.g. trying to edit a non-existent message, or unsynchronized message
> text between sender and recipient). That's the only real purpose of
> doing a Message Reset
> The <body> only occurs when the message is actually "sent" (send
> button or hitting Enter as usual).
> XEP-0301 should (in most cases) ideally cause no changes at all to
> <body> sending behaviour.
> Refer to my XEP-0308/XEP-0301 combined examples in the August 4th
> emails to the mailing list.
> Suggestions welcome for a clarified sentence!
Kevin, any comments on clarifying the section about 'id' (for
******* CLARIFICATION #3 ********
Should I include additional text about why Erase Text <e/> is optional?
>> 16. Why is support for the <e/> element only RECOMMENDED for senders?
>> Given that most users will hit the backspace key (or equivalent)
>> fairly frequently, I'd argue for REQUIRED.
> That's not true, because:
> 1. Transcription. Many transcription engines don't support
> backspacing, Sprint Captioned Telephone display corrections in
> brackets right after the error.
> 2. Bots don't need spell checkers :-) News ticker bots. Real-time
> stock quote bots.
> 3. Basic Real Time Text.
> All message changes are transmitted only using message resets, which
> only needs <t/> ... all message edits including backspace is supported
> without <e/>
> 4. Combining Append-Only Real-Time Text
> (for <t/>)
> and Basic Real-Time Text (whenever <e/> is otherwise needed). A major
> potential implementer has indicated they prefer this method for
> simplicity (low CPU overhead compared to section 6.4.1 "Avoid Bursty
> Text Presentation").
> That's why <e/> only RECOMMENDED for senders.
> It appears I created a failure of the spec to explain clearly why <e/>
> isn't REQUIRED for senders, so I'm curious: Why you thought it should
> be REQUIRED? I thought the spec already made it clear about many use
> cases that don't require <e/>. Suggestion welcome!
******* CLARIFICATION #4 ********
I am wondering if I need to better explain XEP-0301's goal of allowing
senders to be able to refresh the full contents of the real-time
message on late-joining participants (e.g. messages that the sender
started writing before the recipients joins/connects/etc -- applicable
to all situations, MUC and non-MUC)
Context from Peter below:
>> 18. I find the bullet points in Section 4.6 slightly confusing, e.g.,
>> "resuming after connecting". What is exactly is being resumed and who
>> exactly is connecting? If I come online and you're in the midst of
>> sending me messages, my client doesn't have anything to "resume",
>> although it does need to adjust to the fact that there's a real-time
>> text message in progress (somehow).
> 1. Sender user is typing a message.
> 2. Recipient user (or MUC participant) signs on.
> 3. Sender client sends a message reset in the background within 10
> seconds or less (section 4.6.3 --
> http://xmpp.org/extensions/xep-0301.html#message_reset )
> 4. Sender user, blissfully unaware, is still continuously typing the message.
> 5. The Recipient user (or MUC participant) sees sender real-time text
> suddenly "catch up and resume"
> The sender can be continuously typing, and the clients will ensure
> that the real-time text keeps synchronized (resumes) wherever
> Can you help me re-word the bullet, to make this clearer?
> The Message Reset mechanism (section 4.6.3) provide the magic
> ingredient to resume real-time messages, independently of recipient
> timing of logging on & independently of existence of recipient client
> at the moment of time the sender started typing message. This
> enhances usability and user experience, and prevents real-time text
> from becoming lost, including in switching clients, and during MUC
> (e.g. transcription/professor/conference presenter sender real-time
> text, and allowing quick resumption of real-time text on all
> recipients, thanks to the Message Reset mechanism)
> Can you help suggest a change to the sentence/phrase, that would make
> this a little clearer?
(Note: The section "Message Reset" is being renamed to "Message
Refresh" based on another separate thread of discussion, to attempt to
make things clearer. However, I am wondering if should specifically
explicitly mention that XEP-0301 is capable of allowing senders to
allow late-joining recipients to "resume" seeing real-time messages
that was started before the recipient signed on)
******* CLARIFICATION #5 ********
Peter complimented that the Unicode section was much better.
However, suggestions of further clarifications are also welcome:
>> Multiple Unicode code points (e.g. combining marks, accents) can form
>> a combining character sequence.
>> Multiple Unicode code points (e.g. combining marks, accents) can form
>> a combining character sequence. In addition, some combining character
>> sequences (represented by multiple code points) can be transformed
>> into a visually equivalent composite character (represented by a
>> single code point), or vice-versa (e.g., under Unicode normalization).
> [Comment & Change Made]
> That's true. But as we already both know, not all combining character
> sequences can be sent as a single composite character (e.g. single
> code point). So I had hoped that was automatically implied, but I
> guess I have to teach more Unicode here, eh? :-)
> I prefer a shorter version:
> "Multiple Unicode code points (e.g. combining marks, accents) can form
> a combining character sequence. This can also occur in situations
> where there isn't a visually equivalent composite character of a
> single code point (e.g. when doing Unicode normalization)"
> Is this shorter version acceptable?
>> 32. "If Unicode combining character sequences (e.g. letter with
>> multiple accents) are used for Element <t/> – Insert Text, then
>> complete combining character sequences SHOULD be sent." This seems
>> more consistent with NFD than NFC (which performs recomposition). That
>> is: are you recommending that applications perform compability
>> decomposition so that they break a composite character into a
>> combining sequence? If so, then you really want NFD, not NFC. IMHO it
>> would be safer to use composite characters wherever possible, rather
>> than decomposing composite characters into combining sequences as a
>> recommended practice. In any case, NFC will perform recomposition
>> anyway, so this advice might be moot (or at least confusing).
> Yes, but not all combining character sequences can be represented by a
> composite character. NFC is better and more-bandwidth efficient, and
> is more commonly used. It is more frequently used for networked
> Unicode. So if a network channel rudely does NFC on my Unicode (e.g.
> RFC5198 compliant transmission), the Unicode is not corrupted. I'd
> rather be immune to subsequent unwanted normalization passes by the
> most common normalization standard, so NFC is better. In compliant
> architectures, this is moot, but everyone has told me I need to
> specify a normalization standard, so I am following RFC5198
> recommendation of using NFC.
> Decomposition is not needed; the fact remains: Not all combining
> character sequences can be represented by a single code point.
>> "It is possible for Element <t/> – Insert Text to contain any subset
>> sequence of Unicode code points from the sender’s message. This can
>> result in situations where text transmitted in <t/> elements is an
>> incomplete combining character sequence (e.g. Unicode combining
>> mark(s) without a base character) which becomes a complete sequence
>> when inserted within the recipient's real-time message (e.g.
>> additional accent for an existing combining character sequence). These
>> are still complete individual code points, even if the sequence is
> When you follow Section 6.4.1
> You may run into situations where the difference of text is a single
> combining accent character. You have two choices:
> (1) Make section 6.4.1 much more complicated. (not acceptable)
> (2) Keep this paragraph instead. Allow implementers to use
> differental encoders (section 6.4.1 compliant), like RealJabber
> Pick your poison. I prefer the latter.
> Which poison do you prefer? :-)
> Granted, most GUI controls will automatically not display a Unicode
> character until the combining sequence is complete. In this case,
> this paragraph is "moot".
> (A) However, sometimes in some GUI controls on some platforms,
> accent-addition is real-time accumulative, so a text change event
> might occur whenever every additional accent is added.
> (B) Also, even if the GUI buffers until the sequence is complete --
> there are also situations where a person might intentionally overwrite
> a shorter combined character sequence with a longer combined character
> (in situations where composite characters are not available for
> This is the rasion d'être for the existence of the paragraph. Doing a
> simple differential real-time text encoder (section 6.4.1 monitoring
> message changes instead of key presses) will have the issue of picking
> out an incomplete combining character sequence, in both of the above
> cases (A) and/or (B). Therefore, it's not a moot issue.
>> I'm not sure how the recipient's client will show a combining mark
>> without a base character, but the potential for user confusion might
>> be high, here.
> That situation should not happen.
> I am talking about modifying a valid complete combining character
> sequence, to a new valid combining character sequence.
> The standalone combining mark will never be displayed -- it's only
> during transmission.
> See differential encoding according to section 6.4.1 (e.g. turning a
> valid two-character sequence into a valid three-character sequence, by
> transmitting only the combining mark detected by differential encoder
> algorithm in section 6.4.1)
> Perhaps I need to add an additional sentence to make this little tidbit clearer?
> If so, what do you suggest?
Much appreciated for advice.
More information about the Standards