[Standards] RTT, take 2

Peter Saint-Andre stpeter at stpeter.im
Fri Jun 24 01:54:12 UTC 2011

On 6/23/11 12:41 AM, Mark Rejhon wrote:
> 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
> <mailto: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." .... 

OK, I'll put more thought into the start process. Somehow I think a
Jingle negotiation would be overkill. ;-) Something along the lines of
XEP-0084 might be appropriate (and you might be able to borrow some text).

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

That was Kev, not me. :)

> 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:
> http://www.marky.com/realjabber/real_time_text_demo.gif
> It also maintains backwards compatibility too with non-RTT clients.

Kev meant we don't need to use MUST or SHOULD with regard to user
interface, instead we can use gentler words like "clients are encouraged
to..." and such.

>     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'

Or even just misbehavior by the other party. There are no good technical
solutions to social problems. :)

>     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.

I was not concerned about out-of-order stanza processing.

>     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 priority.

I don't prefer them. I was asking a question, not putting forth
preferences. We use this list as a venue for just thinking, sometimes. :)

> 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.)

Kev was right about simplification. I just wanted to gain some clarity
on whether we had a problem to be solved here.

>     > 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.
> Opinion?

On the wire is no such thing as a code point, there are only code points
that are encoded using an encoding form like UTF-8 or UTF-16. For
details, see:


Given that XMPP is pure UTF-8, I don't see a compelling reason to count
UTF-16-encoded code points or UTF-32-encoded code points.

>     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 <mailto:bob at example.com>'
>     from='alice at example.com/home <http://alice@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.

Yes, I figured that out, I just wasn't sure why we needed that kind of
complexity. I'll look at it again.

>     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 <http://realjabber.org> that briefly touches
> upon this; and will be expanded.  Gunnar Helstrom of Omnitor, is the
> go-to guy for this.

OK. For XMPP<=>SIP interworking here, we might need to use Jingle, since
I would imagine that SIP uses standard session management techniques
(e.g., SDP) to establish an RTT session.


Peter Saint-Andre

More information about the Standards mailing list