[Standards] Call for Experience: Advancement of XEP-0301 (In-Band Real Time Text) to Final

Mark Rejhon markybox at gmail.com
Sun Oct 25 16:55:49 UTC 2015

On Sat, Oct 24, 2015 at 5:33 PM, Christian Schudt <christian.schudt at gmx.de>

> XEP-0301 is one of the best written XEP out there (and I’ve read most of
> them and implemented many)! It is very comprehensive and generally feels
> well-thought-out and high quality. Development was fun and mostly straight
> forward. Congrats to the authors, good work!

Thanks for the compliment! It appears Lance agrees, too.
So far your excellent comments, leads to some small editorial improvements
(changes technically otherwise allowed even in a FINAL standard).


> 1. The tracking of RTT messages confused me. § 4.7 states „MUST track
> per-contact“. For me: contact == bare JID. Later it also says: MAY track
> per full JID.

That's not mutually exclusive. Implementations MAY choose to track either
by full JID or bare JID. There are existing implementations going either
way, and they interop.
The word "MUST" exists simply to *avoid implementations that use only one
real-time message app-wide for all conversations *(i.e. chatting with
multiple JIDs).

ACTION: Editorial improvement (4.7).


> 2. Deactivating RTT: It can be done for every contact individually, right?


> Furthermore the spec does not state, if senders, who deactivate RTT while
> typing, MAY/SHOULD/MUST NOT send further RTT elements or if they at least
> may finish their current RTT message.

The already covers some of this, section 6.2:
"Senders deactivating real-time text while in the middle of composing a
message can continue composing their message without real-time text being

We kept RFC2119 language ("MAY", "SHOULD", etc) out of implementation notes
(Section 6 onwards). In existing clients such as RealJabber, for the local
message being composed, there's no UX difference between "message" and
"real time message". Basically composing continues merrily uninterrupted
regardless of whether RTT is being cycled ON/OFF or even repeatedly
multiple times during the same message.  Message Refresh handles the case
of catching up the message if activating mid-message.

Regarding a library (i.e. babbler) that keeps sending RTT after
deactivation (but only until the message is completed):
-- This isn't tecnnically disallowed behavior. Your library is compliance
with the spec.
-- However, an implementer of a library may not want this behavior due to
UX requirements. This is the problem.
Best to allow a choice, and default to the RECOMMENDED way.

ACTION: Editorial improvement (6.2)

> I did not understand, when a sender deactivates RTT, why the recipient
> should do so as well ("Stop transmitting <rtt/> elements as well“).

It's only a "SHOULD". There are different use cases. It's not mandatory.

-- For consistent user experience, real time text is intended to be an
ON/OFF feature similar to audio and video.
-- Usually, terminating audio/video on one end disables it on both ends.
The same is true for RTT.
-- Like the "Mute" feature found in audio/video, you can essentially do a
"Mute RTT" feature, too.
-- You can even have both features in an app; "Mute" (stop sending RTT) and
"Deactivate" (stop sending RTT; and send event="stop" to tell remote to
deactivate too)
-- This is an implementation detail. (The spec job is is interop, not
-- The job of <rtt event="cancel"> should NOT be used by a "Mute RTT"
feature (stop sending, continue receiving).
-- For muting outgoing RTT while preserving incoming RTT, you simply avoid
sending <rtt event="cancel">

That said, I see other implementers might get confused regarding a feature
that an implementer may call "Mute RTT" versus a feature called "Deactivate
RTT", both of which may or may not be simultaneously implemented.

ACTION: Editorial improvement (6.2)

3. The incorrect XML schema (Mark has already sent a mail about it)

Correct. Fortunately, all existing implementations ignores that schema

> 4. Encryption:
> Is there any security concern, if the <body> is encrypted, while the
> <rtt/> is not?
> It also mentions XEP-0027 as deprecated, although it’s "obsolete“.

This is already covered, see "Security Considerations"

> 5. Should referenced/dependent XEPs (especially XEP-308) be Final before
> this one becomes Final?

Not necessary. Many examples include:
XEP-0203 (FINAL) references XEP-0045 (DRAFT)
XEP-0174 (FINAL) references XEP-0115 (DRAFT)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20151025/340a6c2a/attachment.html>

More information about the Standards mailing list