[Standards] RTT, take 2
markybox at gmail.com
Wed Jun 22 17:05:48 UTC 2011
Thank you so much Kevin! Your comments are exactly what we need.
Most of your comments are easy to fix, but we have a couple of questions
within our comments:
On Wed, Jun 22, 2011 at 11:52 AM, Kevin Smith <kevin at kismith.co.uk> wrote:
> 4.2.2 Why SHOULD 0 (rather than MUST)?
I actually agree it should be a MUST. But see section 4.6.3 of the
specification (automatically sync to the seq value whenever type='new'), is
which is why MUST is not a MUST. If people enter chat later (or reconnect)
the seq value may already be a long way from 0. I will re-word this sentence
18.104.22.168 - Start shouldn't be used for discovery, disco/caps should
22.214.171.124 - Cancel would be more consistent with other specs.
Originally, I eliminated disco/caps from the spec for simplicity. The
purpose of 'start' was not for discovery but for session start/stop, so that
both ends can stay in sync. In fact, due to section 4.3.1 (backwards
compatible), it is not necessary to even use 'start' or 'stop' since RTT
clients can work without 'start' and 'stop'.
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.
It wasn't intended to be a UI recommendation. Section 4.3.2 makes this
Irregardless of UI design or layout or method, the *real time message* needs
to be replaced by the *delivered message *because that is an intrisinic
feature of XMPP RTT.
126.96.36.199 insert is ambiguous - what does 'at position p' mean?
> Forward delete should be explicitly rightwards, if that's the
> How does this play with RTL languages?
Forward delete is a string-index-incrementing delete.
For RTL messages, that results in a leftwards delete.
"Forward Delete" means leftwards delete in Arabic
"Forward Delete" means rightwards delete in English
The Mac Help file by Apple calls it a "Forward Delete" key.
188.8.131.52 Why are we dealing with utf-16 when everything is mandated utf-8?
UTF8 is automatically converted to UTF16 by many languages, worked on, then
converted back to UTF8 for transmission over XMPP. Many programming
languages such as Java don't store in UTF-8 (you have to use a byte array
for that). And it is very easy to implement real time text editing
operations using string functions:
String.Substring(realTimeMessage, offset, length)
String.Delete(realTimeMessage, offset, length)
Where offset is copied/derived from "p" attribute of action elements
And length is copied/derived from "n" attribute of action elements.
UTF16 and UTF16LE, and even UCS2 has same behaviour in my RTT spec, so I
just say "16-bit Unicode". Java, C#, ObjectiveC stores strings in 16-bit,
and the various flavours of Unicode C++ STL and stdlib++ also store strings
in 16-bit as well. Extensive research and testing shows they all process in
flat mode like an array of 16-bit integers, treating the string the same, so
it is cross-platform. (Some minor exceptions apply: Apple has two major
string types NSString versus CFString ...use the raw version instead --
i.e. CFStringGetLength for interoperability). It works even for combining
characters, surrogate pairs, Chinese, Arabic, etc. Our spec is optimized for
that for ease. I did a torture test transmissions that successfully
preserved mixed multi-language text.
Is there a better suggestion of wording, without complicating programming?
We are all ears, we've looked at alternatives too.
184.108.40.206 Discussions of counting whitespace scare me where whitespace
> isn't significant
> Would benefit from real numbers, and an example, I think. Ah,
> examples in section 6. Could do with a forward reference.
Thanks, I'll add a forward reference
220.127.116.11 We already have a spec for this
We added because it keeps TDD / TTY / RFC4103 / T.140 interoperability in
the same doc.
4.5.3 What does an empty rtt mean?
> Tier 2 being SHOULD isn't compatible with 18.104.22.168 saying it's
> I have a feeling that we need to normalise, not relying on
> transmission being unmodified.
I see what you mean -- But Tier 2 secton 22.214.171.124 is RECOMMENDED and Tier 2
section 126.96.36.199/6 is OPTIONAL. (Note: We almost made 188.8.131.52 REQUIRED. We
don't want to downgrade 184.108.40.206 on OPTIONAL)
4.6.2 MUST here seems overzealous, best efforts seem reasonable given
> the ultimate <body> correction.
The word MUST is important because: If we don't freeze the text, the text
starts getting scrambled or corrupted if we continue processing real time
action elements after missing a message. (i.e. if the lost action is a
mid-string delete/insert, then the next insert/delete can occur in the wrong
location in the message). We'll add additional wording to explain the
scrambling/corruption danger to rationalize the MUST.
5.1.1 Non-normative recommmended.
> SHOULD NOT here seems overzealous again.
You're right in that it's redundant because there's already a word
RECOMMENDED in the next sentence (it's the same thing) -- I will change it
into "This hurts usability of real-time text" because the next sentence
(5.1.2) has "RECOMMENDED" already.
> 5.2.1 seems like an implementation note
But section 5 is already "Implementation Notes" !!!
5.2.2 Non-normative SHOULD NOT
Aha, I'll fix that. Section 5 is Implementation Notes and the normative
SHOULD NOT is already mentioned in the first paragraph of section 4.4 .... I
was generally trying to keep strong normatives (except "MAY") away of
Implementation Notes. The only time "MUST" is mentioned is in section 4.
5.2.3 Non-normative SHOULD
> Shouldn't be describing the programming model used
The implementation of supporting Keypress Intervals is sufficiently
complicated, that it was necessary to write section 5.2.3 to give a general
Implementation Notes recommendation. These are generalized only.
> 5.4.1 Where does this maximum stanza size come from?
> Why do you need the final transmission? An earlier section says MUST
> be ignored, IIRC.
> All of 5 seems to be implementation notes, in fact
But Section 5 *is* "Implementation Notes"
> 6.9 - not sure the note about sums-to-1 is beneficial.
I will change the wording to "In order to accomplish the best and most fluid
typing playback, the total sum of the W elements is made equal to the
transmission interval". (without mentioning a number) It doesn't HAVE to
add up to 1000, unless you want fully smooth playback...
8. Should not be using UTF-16
See my reply above.
Can you help me by making an alternative suggestion that does not complicate
We've struggled over this, too. Thanks :-)
Security considerations might note that this scheme breaks FLOT labelling.
What is FLOT labelling?
(I apologize if I ask.)
Since most corrections are minor, we will resubmit the spec by this weekend.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Standards