[Standards] review of XEP-0301, sections 1-5 (Advice needed on Peter's comments)

Mark Rejhon markybox at gmail.com
Wed Aug 22 20:52:44 UTC 2012


On Wed, Aug 22, 2012 at 4:40 PM, Gregg Vanderheiden <gv at trace.wisc.edu> wrote:
> I suggest we keep it simple.
> anytime the mode is switched the equivalent of "an ellipsis and SEND" is sent.
> - for real time text switched to message: the text will have already been sent up to the switch, so terminating that string with and ellipse and send...   and then sending the rest as a following message would seem logical.

Ellipsis is an idea, but that's a presentation related-behaviour, and
thus should not be included in the spec, and the ellipsis isn't
transmitted in the RTT channel (and shouldn't be for obvious reasons)
but rather a client can decide to handle messages (save them, clear
them, highlight them, show a temporary ellipsis, etc), and this is a
close cousin to the sectsion "Stale Messages"
http://xmpp.org/extensions/xep-0301.html#stale_messages
There are many user-friendly ways to highlight an incomplete real-time message.

I don't want to consider the message as sent, because the sender might
resume composing, then turn back on real-time text later, or actually
click Send.


> - for message switched to real-time text: the message up to that point would simply be transmitted as real-time text and the person would then continue in real time.

Yep.  The event=new or event=reset can be used either way for this purpose.

Technically, it is also possible for a sender to turn on real time
text on/off many times while in the middle of composing a message.
There may be use cases for "advanced clients", e.g. turning off
real-time text before pasting private information that needs to be
edited, then turning on real-time text when finishing editing private
information.

XEP-0301 is designed to gracefully allow sender clients to quickly
refresh the entire contents of the real-time messages on recipients in
all conceivable situations (whether connecting/joining/switching
clients/etc after sender started composing, or even simply turning on
real-time text while still composing mid-message)

Because real-time text can be turned on/off multiple times while in
middle of composing a message, a message is NOT considered "sent in
full" (from a XMPP-IM <body/> perspective) until the real <body/> is
actually sent.   However, recipients MAY decide to do
presentation-related behaviours whenever real-time is turned off
mid-message (e.g. receiving <rtt event='cancel'/> without receiving a
<body/> first) ... including, of course, automatically displaying an
artifical temporary ellipsis logo/graphic [...] .... at least until
the message is resumed (<rtt> resumes) or until the sender finishes
and sends the complete message (sends <body/>

Thanks,
Mark Rejhon



More information about the Standards mailing list