[Standards] review of XEP-0301, sections 1-5 (Advice needed on Peter's comments)
stpeter at stpeter.im
Thu Aug 23 15:20:20 UTC 2012
-----BEGIN PGP SIGNED MESSAGE-----
On 8/22/12 1:24 PM, Mark Rejhon wrote:
> 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 (
> http://xmpp.org/extensions/xep-0301.html ) There are only five
> major areas of clarifications I need relating to Peter's recent
> ******* 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)
Although in general my advice would be "don't do that", yes it could
be helpful to provide some advice to implementers here.
> On Fri, Aug 17, 2012 at 11:00 PM, Mark Rejhon <markybox at gmail.com>
>>> 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?
>> [Comment] (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
>> Maybe a note is needed to mention about this somewhere?
It seems obvious, but then nothing is truly obvious, so it can't hurt.
> (MUC discussion in original message snipped out for brevity, this
> is covering one-on-one chat only)
> ******* CLARIFICATION #2 ********
> ******* CLARIFICATION #3 ******** Should I include additional text
> about why Erase Text <e/> is optional?
> Peter asked:
>>> 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.
>> [Comment] That's not true, because:
I hadn't been thinking about those use cases and applications, so
SHOULD works for me.
> ******* 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
>> [Comment] 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"
Right, that makes sense. I think I was ignoring the 10-second
guideline for resets.
>> The sender can be continuously typing, and the clients will
>> ensure that the real-time text keeps synchronized (resumes)
>> wherever possible. 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?
I suggest a few small text changes:
Recovery of in-progress real-time message via Message Reset is useful
in several situations:
Synchronization of in-progress real-time message via Message Reset is
useful in several situations:
Resuming after connecting (e.g. wireless reception, recipient started
or restarted software).
Synchronization when the recipient reconnects
Resuming after recipient discarded Stale Messages (e.g. sender resumes
composing hours later).
Synchronization after the recipient has discarded Stale Messages
Resuming after lost message stanzas (e.g. Congestion Considerations).
Synchronization after messages have been lost in transit
> ******* CLARIFICATION #5 ******** Peter complimented that the
> Unicode section was much better.
However, suggestions of further clarifications are also welcome:
>>> OLD Multiple Unicode code points (e.g. combining marks,
>>> accents) can form a combining character sequence.
>>> NEW 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
But implementers might not.
>> 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? :-)
Nothing is automatic and in specifications I prefer not to trust in
the power of implication. :)
>> I prefer a shorter version:
Why? The spec is awfully long as it is. :)
>> "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?
No, because it's not as accurate.
>>> 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."
I think I had missed the force of "If ... then complete". All this
says is, if you're sending combining character sequences then please
send the complete sequence. It's not actively recommending that
clients send combining character sequences instead of composite
characters. So I think it's fine as-is.
>>> 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.
>> [Comment] 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.
Only what 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?
Maybe just clarify that you're talking about "modifying a valid
complete combining character sequence, to a new valid combining
character sequence" -- that wasn't clear to me.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.18 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
-----END PGP SIGNATURE-----
More information about the Standards