[Standards] RTT, take 2

Mark Rejhon markybox at gmail.com
Thu Jun 23 06:41:03 UTC 2011

Re: http://xmpp.org/extensions/inbox/realtimetext.html
Hello Peter, -- thank you so much for your comments.
I've addressed some of the comments in my reply to Kevin.
I wrote a very good response to Kevin.

On Thu, Jun 23, 2011 at 12:03 AM, Peter Saint-Andre <stpeter at stpeter.im>wrote:

> "Reliable message delivery."

Changed to "Reliable real-time text delivery." which is actually the intent.

> > 4.2.2 Why SHOULD 0 (rather than MUST)?
>  +1 to MUST.

It's not necessary for a MUST because the 'seq' synchronizes everytime
type='new' because of Section 4.6.3 in Error Recovery. One end may
disconnect and reconnect, so seq may be far away from 0.
That said, I've changed it to a MUST anyway -- it's no harm.

> > - Start shouldn't be used for discovery, disco/caps should.

We want to address this too, but a clarification: start isn't used for
disco, it's used for signalling:
"Experimentation during the Experimental stage is needed to determine best
interoperability for the process of *starting** *a real-time-text session
and *signalling* the remote end that a session has started (in the future,
it might be a process where one end starts a session, and the other end does
an Accept/Reject -- similiar to AOL AIM Real Time IM.   Or it might be a
different preferred method of starting a RTT session). Due to section 4.3.1,
failure of signalling is not a catastrophe at this early experimental
stage." ....

> 4.3.2 Seems inappropriate - we should only be suggesting UI
> > behaviours, where they're not security critical, not mandating them.

Section 4.3.2 is not UI -- it is a critical feature of XMPP Real Time Text.
For an animation that explains why 4.3.2 is necessary:
It also maintains backwards compatibility too with non-RTT clients.

That seems right.

> Looking at the text and examples, I wonder if just sending a message
> with a <body/> is enough information for the recipient to present the
> messages appropriately. Consider this example:
> <message to='juliet at capulet.lit' from='romeo at montague.lit/orchard'
> type='chat' id='a01'>
>  <rtt xmlns='urn:xmpp:rtt:0' seq='0' event='new'>
>    <t>Hello, </t>
>  </rtt>
> </message>
> <message to='juliet at capulet.lit' from='romeo at montague.lit/orchard'
> type='chat' id='a02'>
>  <rtt xmlns='urn:xmpp:rtt:0' seq='1'>
>    <t>my </t>
>  </rtt>
> </message>
> <message to='juliet at capulet.lit' from='romeo at montague.lit/orchard'
> type='chat' id='a03'>
>  <rtt xmlns='urn:xmpp:rtt:0' seq='2'>
>    <t>Juliet!</t>
>  </rtt>
> </message>
> <message to='juliet at capulet.lit' from='romeo at montague.lit/orchard'
> type='chat' id='a04'>
>  <body>Dude, what happened to my message?</body>
> </message>

It's legitimate -- it also happens in the real world:
Somebody immediately copies and pastes a message on top of the old message,
and then hits Enter immediately.

A client could do it fraudulently or by bug, but there are many things that
an XMPP client can also do fraudulently, too.  It is however, quite obvious,
and users would complain about the 'bug'

How does the recipient know that the last message is related or
> unrelated to the previous RTT fragments?

That is possible to happen, especially if there's out-of-order message
delivery, but I was told that does not happen -- so I removed the message
identifier that was in the 0.0.1 spec.

> We might consider including something like this in the last message:
> <message to='juliet at capulet.lit' from='romeo at montague.lit/orchard'
> type='chat' id='a04'>
>  <rtt xmlns='urn:xmpp:rtt:0' event='done'>
>  <body>Hello, my Juliet!</body>
> </message>
> That raises the question of whether we need identifiers for each RTT
> "sequence", as so:

I used to have message identifiers in XMPP RTT specification version 0.0.1
as the "msg" attribute!
I removed them.  They can still be used as a private extension, but I
removed them from the spec, because the message identifier was apparently
not necessary for things to work reliably. I'd had preferred to keep it
included (as you apparently prefer!). But then, simplification became a high

>From what I recall, I think Kevin agreed on erring on the side of
simplifying, when I asked if I should remove the msg identifier from the
last spec.  It can be re-added as an optional feature, as an additional
integrity layer to error recovery.

(At this stage, I'd like to hear agreement from several people first though
about this detail.)

> insert is ambiguous - what does 'at position p' mean?
> >       Forward delete should be explicitly rightwards, if that's the
> intent.
> > How does this play with RTL languages?
>  Good questions.

Forward Delete is a leftwards delete in Arabic, according to Wikipedia, and
in Apple Mac's help file.
I'm adding clarifying wording, though.

> Why are we dealing with utf-16 when everything is mandated utf-8?
> UTF-8 FTW.

What do you think of Simon's suggestion?
I am switching to "code point" (UCS4 counting) method.

In many languages (i.e. Java) it is difficult to easily calculate
positioning and indexing UTF-8 because most programming languages do not
have convenient routines for string-indexing UTF-8.  It is necessary to come
to a simple programming standard, due to the Unicode considerations such as
multiple Unicode characters representing one displayable Unicode character.

XMPP RTT is essentially a standard for editing an array of 16-bit integers
(counting on "code units"), and UTF-8 has variable character lengths that
complicate programming significantly.

However, I am thinking of following Simon's excellent suggestion.

What do you think of his suggestion of using "code point" counting for
length and position attributes?
That'd pretty much essentially turn XMPP RTT equivalently into a standard
for editing an array of 32-bit integers instead (allow use of native UCS4
string functions in programming languages that stores strings in UCS4
format).  It makes my 16-bit programming slightly more complicated, but much
easier than counting in UTF8.  It might be a better long term goal.


Also, this seems inconsistent with the forward delete function:
> "If the p attribute is omitted, the default value for p is the length of
> the current real-time message."
> How is that applied to the <d/> element? Is the 'p' attribute REQUIRED
> in that context? (You can't forward delete beyond the end of the message.)

Excess backspaces and deletes are ignored, so that ends up becoming a
do-nothing element.
Useless action elements shouldn't be used for bandwidth reasons, perhaps I
should mention that detail in the spec.  (making note to mention this.)

In Section 6.4:
> <message to='bob at example.com' from='alice at example.com/home' type='chat'
> id='a01'>
>  <rtt xmlns='urn:xmpp:rtt:0' seq='0' event='new'>
>    <t>Hello Bob, this is Alice!</t><d n='4' p='5'/>
>  </rtt>
> </message>
> Why not send two stanzas?

That can be done. The examples are merely at educating people on real time
text, at progressively more difficult levels.

In reality, the real world transmissions in all my test software, more
resemble section 6.9 with everything at a very fine-grain level. There are
over 60 action elements per second when you hold a key down (30 characters
per second, with 30 key press intervals embedded within), and results in
approximately 700-byte <rtt> elements.

Section 6.9 (the one that should happen in the real world with RECOMMENDED
key press intervals, which has high acclaim and rave reviews) however, is
the most complex example. So I wrote the examples in a
progressively-more-complex way in an attempt to educate the reader.

Section 7.1 talks about interoperability with RFC 4103 and T.140. How
> does an XMPP entity negotiate an RTT session with a SIP entity? (I'm
> wondering if we need a Jingle application type for RTT...)

The RFC4103 people are covering that.  I've published a SUPPLEMENT document
on realjabber.org that briefly touches upon this; and will be expanded.
 Gunnar Helstrom of Omnitor, is the go-to guy for this.

That's all for now. Good work!

Mark Rejhon
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20110623/866ee53c/attachment.html>

More information about the Standards mailing list