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 <[email protected]> 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 to clarify. 4.2.3.3 - Start shouldn't be used for discovery, disco/caps should 4.2.3.4 - 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 possible: http://www.marky.com/realjabber/real_time_text_demo.gif 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. 4.5.1.1 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? > 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 http://en.wikipedia.org/wiki/Delete_key The Mac Help file by Apple calls it a "Forward Delete" key. 4.5.1.3 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.Insert(realTimeMessage, offset) String.Delete(realTimeMessage, offset, length) etc. 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. 4.5.2.1 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 4.5.2.6 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 4.5.2.6 saying it's > OPTIONAL > I have a feeling that we need to normalise, not relying on > transmission being unmodified. > I see what you mean -- But Tier 2 secton 4.5.2.4 is RECOMMENDED and Tier 2 section 4.5.2.5/6 is OPTIONAL. (Note: We almost made 4.5.2.4 REQUIRED. We don't want to downgrade 4.5.2.4 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 programming? 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.) Thank you! Since most corrections are minor, we will resubmit the spec by this weekend.
