<div class="gmail_quote">On Mon, Jul 23, 2012 at 10:32 AM, Kevin Smith <span dir="ltr"><<a href="mailto:kevin@kismith.co.uk" target="_blank">kevin@kismith.co.uk</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

Right, thoughts about 301 (consider them early Last Call feedback, I<br>
guess. I think it would be worth addressing them, or at least<br>
producing an errata list of your expected edits, before asking too<br>
many other people to review this (e.g. LC) as it took me a<br>
considerable time and it'd be a shame to waste people's effort<br>
commenting on things due to be changed):<br></blockquote><div><br></div><div>Excellent comments.  </div><div>Due to the large number of comments from a key person at XSF (you) I agree with you.    I have many comments and questions for you first, that I'd like you to address. I will reply in two emails -- this email is regarding section 1 through 5.  I have prefaced with [Comment], [Question], and [Change Made] in appropriate places for easy reading.</div>

<div></div></div><div class="gmail_quote"><div></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">== Introduction ==<br>
This seems mostly fine. I wonder about the reference to<br>
<a href="http://realjabber.org" target="_blank">realjabber.org</a>. Partly because it's a reference to a potentially less<br>
stable URL, and partly because I think the name is inflammatory - did<br>
the XSF or Cisco grant the trademark use?<br></blockquote><div><br></div><div>[Question]</div><div>Understood -- animation really helps explains real-time text, if they haven't seen it before.</div><div>Can we use a more well-known site (i.e. <a href="http://realtimetext.org" target="_blank">realtimetext.org</a>?) since we can put my animations there too?  Alternatively, can we embed an image, like XEP-0071 has an embedded image?  (If I make a generic animation, and convert it to animated GIF format)</div>

<div><i>P.S. Will inquire about the name concern (private inquiry to Peter).  I had talked to many at Cisco over the last two years. Paul E. Jones is a a member of R3TF who works at Cisco.  Nobody has ever brought up concern about the RealJabber name, but I will now inquire specifically about this.</i></div>

<div> </div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">== Requirements ==<br>
2.3.4 doesn't seem quite right - what we want is for it to be possible<br>
to produce gateways for interoperability - not that XEP 301<br>
implementations themselves interop with other networks?<br>
2.4 Doesn't seem to be about Accessibility.<br>
2.4.4 Doesn't make much sense to me.<br></blockquote><div><br></div><div>[Question]</div><div>Peter (or anyone else at XSF), any comments about these?  </div><div>I'd like a second set of comments on these points, and then I'd like to confer with the R3TF group about revisions.</div>

<div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">== Glossary ==<br>
"real-time text"'s definition seems wrong - it isn't necessarily<br>
transmitted instantly in 301. It would seem more natural to define<br>
this in terms of real-time, defined on the immediately preceding line.<br></blockquote><div><br></div><div>[Comment]</div><div>The Real Time Text Taskforce spent hours debating one of the shortest possible explanations of real-time text that is also understandable to laymen.  (The introduction needs to also be understandable by non-technical people -- the rest of the spec can be technical).  We agreed that the word was appropriate, because it is "instant" from a human perception timescale.</div>

<div><br></div><div>We discussed and decided it was was hugely consistent with today's usage of the word:</div><div>- The technology is called "Instant Messaging" -- which isn't necessarily instant, either.</div>

<div>- Other "instant" technologies like "Google Instant", has a latency, and also utilizes rate-limiting algorithms (like a transmission interval)</div><div>- Instant Oatmeal and Instant Rice, is less "instant" than the use of word "instant" here.</div>

<div>- "instant" is quite self-explanatory to a wide audience, without explaining metrics.   The scientific-minded people will have some mixed feelings, but even the scientific-minded in the R3TF has agreed that this is the lesser of evil when attempting to invent an explanation of real-time text less than 10 words long.   </div>

<div><br></div><div>Some considerations:</div><div>- Some of us disliked timescales such as "within 1 second", except when referring to a standardized interval (ITU-T Rec F.700), and this has to be left out of a one-sentence definition of real-time text.</div>

<div>- Some of us disliked saying "character by character" because it's not necessarily transmitted character by character in all situations.</div><div>- Some of us suggested "in real-time" instead of "instantly" but that's redundant, and too many people already think instant message is already real-time, so I need to put an 'unexpected' word there such as "immediately"(rejected word) / "within 1 seconds"(rejected phrase), "live" (formerly used, but confused too many people), etc ... until we finally areed that "instantly"(the chosen phrase) was the best compromise for a one-sentence quick explanation of real-time text (management-friendly, facebook-friendly, tweetable, introduction-friendly, joe-user friendly, etc).   </div>

<div><br></div><div>Believe me, we spent hours deciding on a how to explain real-time text in the shortest possible sentence :-)   This is also in the process of the many hours we also spent in the agreement of the International Real-Time Text Symbol (the one at <a href="http://www.fasttext.org" target="_blank">www.fasttext.org</a> ...)  It was a huge challenge, and I'm pleased that we were able to finally come up with something that even our older mothers (pre-computer era) can understand, and that confused people requires little further explanation to educate.   We are open to other suggestions, but keep in mind we are aiming at a standardized explanation of real-time text that works across a wide variety of audiences (including all levels of programmers).  We discussed separate technical and laymen explanation of real-time text, but even the technical explanations need a good one-sentence introduction, too.  It can be generally difficult to market and explain real-time text.</div>

<div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">== Protocol ==<br>
"to allow the recipient to see the sender type the message" - I'd<br>
suggest "to allow the recipient to receive the latest state of the<br>
message as it is being typed" - RTT doesn't allow us to see the sender :)<br></blockquote><div><br></div><div>[Change Made]</div><div>Replacement made: <i>"...to allow the recipient to see the latest message text..."</i></div>

<div>Good idea.  The sentence is already long, so I made a shorter change:   since the sender is already mentioned.   It's interpretable by people of both front-end and back-end mindsets -- it can even mean programmatnically, the recipient client software "sees" the text, even if it's not displayed.  </div>

<div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Example 1: I suggest that this could be better demonstrated by not<br>
cutting at the word boundaries "He", "llo, m", "y Juliet!" maybe, or<br>
something like that. Experience and/or cynicism say that implementers<br>
are quite likely to look at the examples, ignore the text, and<br>
misunderstand what's going on if the examples provide convenient<br>
semantics not required by the protocol.<br>
"The bounds of seq is 31-bits, the range of positive values of a<br>
signed integer" - I'd be inclined to make this something like "The seq<br>
attribute  has an upper bound of <a href="tel:2147483647" value="+12147483647" target="_blank">2147483647</a> (2^31 - 1). If this upper<br>
bound is reached the following RTT element will reset the seq<br>
attribute to 0, i.e. at the upper bound the values would be (in<br>
successive stanzas) <a href="tel:2147483646" value="+12147483646" target="_blank">2147483646</a>, <a href="tel:2147483647" value="+12147483647" target="_blank">2147483647</a>, 0, 1)" or words to that<br>
effect.<br></blockquote><div><br></div><div>[Comment & Question]</div><div>I agree, but I don't think it is worthwhile cluttering it by explaining wraparound:</div><div>-- Incrementing only occurs once every second or slightly less (0.7 seconds).  In practical situations, wraparounds will never happen. </div>

<div>-- Even so, incorrectly handled wraparounds are mostly harmless as it will only result in a brief pause (of less than 10 seconds) because of the regular "Message Reset" during "Keeping Real-Time Text Synchronized":</div>

<div><a href="http://xmpp.org/extensions/xep-0301.html#keeping_realtime_text_synchronized">http://xmpp.org/extensions/xep-0301.html#keeping_realtime_text_synchronized</a></div><div>What is your opinion?</div><div> </div>
<br></div><div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">== Protocol ==<br>"to allow the recipient to see the sender type the message" - I'd<br>

suggest "to allow the recipient to receive the latest state of the<br>message as it is being typed" - RTT doesn't allow us to see the sender<br>:)<br>Example 1: I suggest that this could be better demonstrated by not<br>

cutting at the word boundaries "He", "llo, m", "y Juliet!" maybe, or<br>something like that. Experience and/or cynicism say that implementers<br>are quite likely to look at the examples, ignore the text, and<br>

misunderstand what's going on if the examples provide convenient<br>semantics not required by the protocol.</blockquote><div><br></div><div>[Comment]</div><div>I don't like this change.  Are you sure?   
</div><div>In some earlier messages, I mentioned that word transmission is <b>*greatly preferable* </b>to broken-word transmission.</div><div>Also, if an implementer misunderstands, this detail is a more harmless misunderstanding than broken-word transmission.</div>

<div><br></div><div>There are other examples in the spec.</div></div><div>Comments welcome from people other than Kevin and Gunnar -- I need more comments because I have comments that they prefer this Introduction, so I need to reconcile conflicting advice about the Introductory example.  XEP-0301 permits you to transmit real-time text any way you want: character-at-a-time, word-at-a-time, word bursts, original typing intervals, time-smoothed, etc.   The Introductory Example is unable to demonstrate all of the possible methods.  IMHO, I chose the 'safest' introductory example.</div>

<div><br></div><div>Again, word transmission is greatly preferable over broken-word transmission.  (There's been arguments in some accessibility organizations in some countries, some say they prefer keypress intervals, some prefer word transmission instead of keypresses, etc.)   I am talking to a guy from a telco in UK, and he informed me of a political debate.  </div>

<div><br></div><div><div>Can at least a few more "outsiders" comment on this change, please?  Thanks :-)</div></div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

It's not clear to me why setting seq to a random initial value should<br>

help with MUC or multi-resource cases - in these cases you know the<br>
full JID of the entities involved and a random start point seems to<br>
make it harder to understand what's going on, rather than easier.<br></blockquote><div><br></div><div>[Question]</div><div>Imagine a simultaneous login, both logins somehow started typing and the client doesn't distinguish the two.  If both started at the same seq number (0), then there will be some situations where the seq looks like they are incrementing when recieving a <rtt/> from one client than an <rtt/> from a different client.   This will cause occasional text scrambling to occur (until it disppears in the next Message Reset).   </div>

<div>-- By randomizing, this doesn't happen in practical situations</div><div>-- Also, only a few incrementings get a chance to occur before it's randomized again during the next Message Reset.  During a 10 second Message Reset interval, and a 0.7s Transmit Interval, only approximately 15 increments will occur.  Overflow is never going to happen in such an implementation.</div>

<div>-- You can distinguish resources using <thread/> and/or the full JID.  However, this might not always be possible universally in all possible situations.</div><div>-- If it ever happens, overflow from a user experience standpoint will be fairly harmless -- manifesting itself as a small pause due to the regular "Message Reset" interval.</div>

<div><br></div><div>Implementers can just start at 0 for every event='new' and event='reset', and accept the risks, or use <thread/> at all times to distinguish the different RTT threads to avoid conflicts.  Slightly less risky is implementers to simply keep incrementing at all times, from the beginning of chat session.   Overflow becomes slightly more likely, but would still require a non-stop chat session lasting longer than a human lifetime!  </div>

<div><br></div><div>I'm open to alternate ideas than randomizing, or even simplifying, but I'd rather not complicate by having to explain wraparound situations, due to the above.  Of course, this is mainly of concern to reduce odds of conflict situations whenever there's no full JID support and no <thread/> -- otherwise recipients don't care what seq value you begin to use for a new real-time message. </div>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">"The event attribute MAY be omitted from the <rtt/> element during<br>
regular real-time text transmission" - what is the the alternative<br>
you're allowing clients, and what is "regular real-time text<br>
transmission"?<br></blockquote><div><br></div><div>[Change made]</div><div>Clarification made: "The event attribute is NOT required for <rtt/> when transmitting changes to an existing real-time message."</div>

<div><br></div><div>Regular real-time transmission is message changes, like the second and third stanza of the Introductory example.  </div><div>However, there are some situations where you always transmit an event attribute, such as Basic Real Time Text:</div>

<div><a href="http://xmpp.org/extensions/xep-0301.html#basic_realtime_text">http://xmpp.org/extensions/xep-0301.html#basic_realtime_text</a>
</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
4.2.2 - "Recipient clients MUST initialize a new real-time message for<br>
display" - how things are rendered in clients are generally not in<br>
scope for XEPs, maybe just remove 'for display'?<br></blockquote><div><br></div><div>[Change Made] -- Good suggestion.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

4.2.2 - "Senders MAY send subsequent <rtt/> elements that do not<br>
contain an event attribute" if clients want to always send event<br>
attributes, what would they send?<br></blockquote><div><br></div><div>[Change Made]</div><div>Clarification change: <i>"Sender MAY <b>transmit changes to the real-time message via </b>subsequent <rtt/> elements that do not contain an event attribute."   ...</i>I hope this makes things clearer, in conjunction to above?</div>

<div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">4.2.2 - "Recipients MUST treat 'reset' the same as 'new'." - I'm not<br>

sure that's quite right. If recipients want to render 'new'<br>
differently that seems to be fine. Maybe "Recipients MUST reset the<br>
state of the current real-time message when receiving a 'reset'<br>
(returning the real-time message to the same state as when receiving a<br>
'new')"?<br></blockquote><div><br></div><div>[Comment & Question]</div><div>Yes, rendering 'new' and 'reset' is the reason that the two still are treated separate.  </div><div>However:</div>

<div>(1) It's possible to receive <rtt event='reset'/> without ever receiving an <rtt event='new'/>.  (e.g. recipient logs on after sender starts composing, MUC participant joins, stanza with 'new' is lost, etc).</div>

<div>(2) Basic Real-Time Text at <a href="http://xmpp.org/extensions/xep-0301.html#basic_realtime_text">http://xmpp.org/extensions/xep-0301.html#basic_realtime_text</a></div><div>(3) The 'new' _also_ resets any existing real-time message if any is shown.  There is always only one real-time message per sending client.</div>

<div><br></div><div>Therefore, the behavior of 'new' and 'reset' needs to be identical, with the /sole/ exception of presentation (e.g. implementor automatically highlighting a new message being started.).  The wording that you suggested, doesn't seem consistent with compatibility for (1) and (2). </div>

<div>I propose to keep my existing wording, but add "<i>(except for presentation-related behavior)</i>", but adding implementer/user interface details to Protocol is generally a Bad Idea in most cases?   If so, can you suggest an alternative?</div>

<div><br></div><div>I could even merge 'new' and 'reset' since they are, for all practical intents, interchangeable in my existing implementation.   However, if I separate them, I would not be able to tell when a user *began* to compose a message, versus if the client simply retransmitted an already-in-progress message, one that might have started a long ago.  That's the only big (and good reason) why 'new' and 'reset' is separate.</div>

<div>Comments?</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">4.2.2 - event='init' - I'm reading the XEP linearly so maybe this will<br>

be clear later, but at this point in reading the XEP it's not clear to<br>
me what the inclusion of event='init' buys us.<br></blockquote><div><br></div><div>[Change Made]</div><div>New clarified sentence: <i>"Clients MAY use this value to signal that real-time text is being activated, <b>prior to sending real-time text</b>"</i>.   This allows activation to be done separately of creating a new real-time message, in order to permit implementor behaviours, such as Activation/Deactivation methods (which I do refer to), including per-session acceptance/rejection mechanisms that implementers may choose to do so. (and implementers have requested that such mechanisms be possible).</div>

<div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">4.2.2 - The normatives here don't seem to be congruent. event='cancel'<br>
is OPTIONAL, yet we have a SHOULD for behaviour on receiving them. Why<br>
not require recipient support?<br></blockquote><div><br></div><div>[Change Made]</div><div>Good observation.  I fixed the the chart to make it RECOMMENDED for recipient support, while continuing to keep it OPTIONAL for sender support.    I don't want to make it REQUIRED since there are situations where it's not necessary.   Yalso end a chat session to do the same thing as <rtt event='cancel'/>.   Also, many situations such as transcription services, might never need to send outgoing <rtt event='cancel'/> </div>

<div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">4.2.3 - I don't think the intent here is clear. Particularly it's not<br>
OPTIONAL if you're doing RTT correction. So I think we need to tighten<br></blockquote><div><br></div><div>[Comment]</div><div>It's still optional, so that's my intent.  But I can improve the wording.</div><div>

 </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
this up. There's a choice on discovery and it'll affect what needs to<br>
be said.<br>
  Choice 1) If you implement 308 and you also implement 301 you MUST<br>
support (at least receiving) RTT correction and ids are not OPTIONAL<br>
and MUST be included on the correction RTT.<br>
  Choice 2) You can implement 308 and 301 yet not support RTT<br>
correction - in which case supporting RTT correction is OPTIONAL, but<br>
if you do you MUST advertise appropriate disco features and MUST<br>
include ids etc.<br></blockquote><div><br></div><div>[Comment & Question]</div><div>If you implement 308 and 301, you can still do RTT correction without the 'id'.  The main difference is that the real-time text will show up where the new message normally is (i.e. it becomes a copy of the previous message).  I explained this carefully in a long email a few days ago to the standards mailing list -- this is because a Message Reset is done when switching between messages, so the real-time mesage will still continue to function even when doing RTT without the 'id' attributes.  When the last message is delivered, the real-time message disappears anyway (because of the "Body Element" chapter).  The inclusion of 'id' is merely to provide a better User Experience by allowing recipient clients to do thing such allow "in-place" real-time editing of the real-time message, rather than in the normal new real-time message.    </div>

<div>But the inclusion of 'id' isn't essential for real-time text to continue to function during retroactive message editing, thanks to my mentioning of requiring a message reset everytime you switch messages. (which allows backwards compatible behavior)</div>

<div><br></div><div>Some of my wording might be unclear, so I'd like ideas of clarifying the still-optional intent.  Comments?</div><div> </div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

4.3 - "The delivered message in the <body/> element is displayed<br>
instead of the real-time message" - maybe "The content of the <body/><br>
element is considered the final text, rather than the state of the RTT<br>
calculations"?<br></blockquote><div><br></div><div>[Change Made]</div><div>Replacement sentence: <i>"The delivered text in the <body/> element is considered the final text, and supersedes the real-time message."</i></div>

<div>(I think "RTT calculations" is best held off until the "Action Element" chapter.  Also the word "calculations" might not be appropriate if the implementer is simply using Basic Real-Time Text by only using message resets)</div>

<div> </div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">4.3 - "In the ideal case, the message from <body/> is redundant since<br>
this delivered message is identical to the final contents of the<br>
real-time message." - can we s/message/text/ here? Calling child<br>
elements of <message/> stanzas messages seems potentially confusing.<br></blockquote><div><br></div><div>[Change Made] -- good point</div><div> </div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

4.3.1 - Is this redundant?<br></blockquote><div><br></div><div>[Comment]</div><div>Enough people have asked that this information is necessary for clarification.  However, I can simplify or change the words -- but some variant of explaining backwards compatible is necessary, and some people such as Paul E. Jones (who's also at Cisco) really likes that XEP-0301 is backwards compatible, a major advantage of XEP-0301 -- it's not a standalone real-time text mechanism but an enhancement to an existing messaging network that generally doesn't even require server modifications for this protocol to work.    Also, the section heading is also a convenient linking anchor for "Backwards Compatible" links elsewhere in the document.</div>

<div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">4.4 - The discussion of throttling here feels a bit odd. I don't like<br>
having references to servers dropping messages as part of congestion<br>
handling, as that's not compliant behaviour. The comments about 0.7<br>
seconds being fine for not hitting throttles but smaller values<br>
hitting it seems a bit hit-and-miss - servers are free to implement<br>
whatever throttling they want, and I'm a little worried about<br>
recommending here what we think the state of the network is likely to<br>
be now or in the future.<br></blockquote><div><br></div><div>[Change Made]</div><div>I shortened the sentence: "<i>Conversely, a much shorter interval may lead to [[[Congestion Considerations(link)]]]</i>."</div>

<div>I've seen throttling at 1 message per second but I can agree to reduce talk of throttling/dropped messages in this section, and leave that talk within the Congestion Considerations section. (wording there can also be improved, too)</div>

<div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">4.5 - "the recipient can watch the sender" - this isn't quite right<br>
(similar to previous comment).<br></blockquote><div><br></div><div>[Change Made]</div><div>I have replaced the word "watch" with "see", because "see" is compatible with a software viewpoint.  (interpreted as "The software sees the changes to the message" even if the message is not displayed) -- To keep things simple for a wider variety of readers, I prefer terms that are both human-compatible and machine-compatible, and seems acceptable in both Merriam-Webster dictionary (meaning 2b, 3c) and Oxford dictionary (meaning 2)</div>

<div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">4.5.1 - I'm not sure that the use of quite cryptic one-character<br>
elements here is terribly useful.<br></blockquote><div><br></div><div>[Comment & Change]</div><div><div>Proposed edit: <i>"The elements are a kept compact in order to save bandwidth, since a single <rtt/> element can contain a huge number of action elements (e.g. during [[[Preserving Key Press Intervals(link)]]])"</i></div>

<div><br></div><div>There can be almost 100 action elements per <rtt/> transmission in certain situations such as a key press being held down.</div><div>Is this edit acceptable?   (I used to have a similar sentence there before)</div>

<br class="Apple-interchange-newline"></div><div>One-character elements are needed because if I preserve key press intervals, by a 120 word per minute typist (my typing speed), can result in almost 20 action elements per <message/> for a high-quality full-implementation with complete full playback of real-time text.  By using a one-character element, I save on bandwidth significantly.  </div>

<div><br></div><div>Also, if a key is held down and you are preserving key press intervals -- then this results in 60 action elements per <message/> stanza at a 1 second transmit interval.  (30 </t> keypresses per second and 30 <w/> pauses per second).  In this case a single <message/> stanza containing only real-time text, can becomes almost 1 kilobyte big.  If I made the action elements one letter bigger, that adds another 60 bytes per stanza.   If I used an average of five letters, I'm potentially adding an additional 300 bytes of extra overhead per message stanza.</div>

<div><br></div><div>Therefore, it is necessary to keep the size of action elements very small.  </div><div>Even though cryptic, the names were carefully while meeting the bandwidth reduction requirement.</div><div><br></div>

<div><t/> = insert <b>T</b>ext.  I avoided <i/> to prevent confusion with HTML Italics.</div><div><div><e/> = backspace (<b>E</b>rase).  I avoided <b/> to prevent confusion with HTML Bold.</div><div>

<d/> = forward <b>D</b>elete</div><div><w/> = <b>W</b>ait element</div><div><b>p = P</b>osition</div><b>n</b> = common name for count</div><div><br></div><div>So the shortness, saves a significant amount of bandwidth, while making it possible to preserving key press intervals as seen in:</div>

<div><u><a href="http://www.realjabber.org/anim/real_time_text_demo.html">http://www.realjabber.org/anim/real_time_text_demo.html</a></u></div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

4.5.1 - I think this has been commented on elsewhere, but using<br>
'characters' here seems to be less clear than talking about code<br>
points. I understand the desire to mask implementers from needing<br>
exposure to code points, but I don't think that's going to ultimately<br>
help uptake or interoperability.<br></blockquote><div><br></div><div>[Comment]</div><div>Further discussion is welcome.  </div><div> <br><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

4.5.1 - I think if there are going to be SHOULDs in supported features<br>
we should try to explain in what circumstances it's acceptable to<br>
ignore the SHOULDs.<br></blockquote><div><br></div><div>[Comment]</div><div>I say "For detailed information, see List of Action Elements." which refers to section 4.3.2</div><div>I already explain it subsequently in section  4.5.3 ( through</div>

<div>I also referenced Basic Real-Time Text.  <br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">4.5.2 - Talking about message length here probably needs clarification<br>

- is it the number of characters (whatever they mean to different<br>
people), code points, normalised code points, octets on the wire..<br></blockquote><div><br></div><div>[Change Made]</div><div><i>"The n attribute is a length value, <b>in number of characters</b>."</i></div><div>

and</div><div><i>"The p attribute is an absolute position value, <b>as a character position index into the message, where 0 represents the beginning of the message.</b>"</i></div><div><br></div><div>I already define what a character is, from the perspective  </div>

<div><i>"For text modifications, length and position (n and p) is based on [[[Unicode Character Counting]]]."</i></div><div>This defines the method of character counting that is being done.</div><div><br></div>
 </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> - This might become clearer later, but at this stage it's not<br>
clear what 'positions' are.<br></blockquote><div><br></div><div>[Comment & Question]</div><div>I thought it was already explained in section 4.5.2:</div><div><span style="font-family:Verdana,Arial,Helvetica,Geneva,sans-serif;line-height:16px;background-color:rgb(255,255,255)">The </span><span class="em" style="font-style:italic;font-family:Verdana,Arial,Helvetica,Geneva,sans-serif;line-height:16px;background-color:rgb(255,255,255)"><span class="strong" style="font-weight:bold">p</span></span><span style="font-family:Verdana,Arial,Helvetica,Geneva,sans-serif;line-height:16px;background-color:rgb(255,255,255)"> attribute is an absolute position value, as a 0-based index (0 represents beginning of message).</span><br style="font-family:Verdana,Arial,Helvetica,Geneva,sans-serif;line-height:16px;background-color:rgb(255,255,255)">

<span style="font-family:Verdana,Arial,Helvetica,Geneva,sans-serif;line-height:16px;background-color:rgb(255,255,255)">If </span><span class="em" style="font-style:italic;font-family:Verdana,Arial,Helvetica,Geneva,sans-serif;line-height:16px;background-color:rgb(255,255,255)"><span class="strong" style="font-weight:bold">p</span></span><span style="font-family:Verdana,Arial,Helvetica,Geneva,sans-serif;line-height:16px;background-color:rgb(255,255,255)"> is omitted, the default value of </span><span class="em" style="font-style:italic;font-family:Verdana,Arial,Helvetica,Geneva,sans-serif;line-height:16px;background-color:rgb(255,255,255)"><span class="strong" style="font-weight:bold">p</span></span><span style="font-family:Verdana,Arial,Helvetica,Geneva,sans-serif;line-height:16px;background-color:rgb(255,255,255)"> MUST be the current message length (</span><span class="em" style="font-style:italic;font-family:Verdana,Arial,Helvetica,Geneva,sans-serif;line-height:16px;background-color:rgb(255,255,255)"><span class="strong" style="font-weight:bold">p</span></span><span style="font-family:Verdana,Arial,Helvetica,Geneva,sans-serif;line-height:16px;background-color:rgb(255,255,255)"> defaults to end of message).</span></div>

<div>Perhaps that is too confusing -- do you mind if you can suggest an alternate wording, that would make it clearer to people like you?</div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> - Apart from adding complexity I'm not sure what forward<br>
delete is buying us vs. backspace.<br></blockquote><div><br></div><div>[Comment]</div><div><div style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:13px;background-color:rgb(255,255,255)">About complexity: It only adds 5 lines of complexity to the implementation:</div>

<div style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:13px;background-color:rgb(255,255,255)"><a href="http://code.google.com/p/realjabber/source/browse/trunk/Java/src/RealTimeText.java?r=24#551" target="_blank" style="color:rgb(17,85,204)">http://code.google.com/p/realjabber/source/browse/trunk/Java/src/RealTimeText.java?r=24#551</a></div>

<div style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:13px;background-color:rgb(255,255,255)">About reasoning: </div><div style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:13px;background-color:rgb(255,255,255)">

... Reason 1. There are situations where it made a lot of sense to have the two separate, including recipient-side time-smoothed display which was something you also suggested.  For example, <e n="5"/> can be automatically converted to the equivalent <e/><e/><e/><e/><e/> for time-smoothed display with the cursor animated backwards.  And <d p='10' n='5'/> can automatically be converted to the equivalent <d p='10'/><d p='10'/><d p='10'/><d p='10'/><d p='10'/> for time-smoothed display with the cursor staying stationary.   If we merged the two, then we can't have distinctive time-smoothed display of either. (Gunnar is a strong proponent of time-smoothed display)  But of course, it might not be that important, even to Gunnar.</div>

<div style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:13px;background-color:rgb(255,255,255)">... Reason 2. Ability to do accurate journalling of edits, for emergency purposes.  However, this reason can become moot, especially if we're not using the 'n' argument, since a single-character backspace transmitted can be indistinguishable from a single-character delete operation (even for time-smoothed display).   </div>

<div style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:13px;background-color:rgb(255,255,255)">... Reason 3. It slightly simplifies "Monitoring Key Presses Directly" for senders <a href="http://xmpp.org/extensions/xep-0301.html#monitoring_key_presses_directly" target="_blank" style="color:rgb(17,85,204)">http://xmpp.org/extensions/xep-0301.html#monitoring_key_presses_directly</a> ... (I know that's not the preferred method)</div>

<div style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:13px;background-color:rgb(255,255,255)">... Reason 4. It simplifies visualizing of text block deletes (i.e. cut operations), since you're deleting from normal start position. </div>

<div style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:13px;background-color:rgb(255,255,255)">... There are other reasons.</div></div><div style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:13px;background-color:rgb(255,255,255)">

<br></div><div style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:13px;background-color:rgb(255,255,255)">If discussion of merger of backspace and delete is warranted, let's split it into its own independent thread, as that is a major topic (if ventured) with its own subject (e.g. "XEP-0301 Backspace versus Forward Delete"), requires full and complete discussions of all angles and implications that can occur, making sure all advantages and disadvantages can be accomodated for (e.g. alternative mechnaisms of accomplishing the above reasons), before embarking on a significant change to XEP-0301 protocol.  It has merit and worth discussing, but it has distinct disadvantages that everyone needs to discuss through first.</div>

<div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">4.5.4 - I don't think trusting that nothing in the chain is going to<br>

transform unicode in any way is going to be sufficient for<br>
interoperability here. I think we need to consider normalising the<br>
text before RTT calculations are performed on it. I'm not entirely<br>
convinced, without going through specs in some detail, that an<br>
implementation that does choose to do normalisation somewhere on route<br>
is non-compliant, which is what's asserted here.<br></blockquote><div><br></div><div>[Question]</div><div>Can you re-evaluate 4.5.4 based on my comments below?</div><div> </div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> - Ah, OK. So you do require normalisation here - you need to<br>
say which type is required.<br></blockquote><div><br></div><div>[Comment]</div><div>It doesn't matter.  All normalizations work, as long as the normalization is done /before/ the encoding.  Therefore, it is not necessary to say which type is required.   It just merely say that all code point modifications need to occur beforehand.</div>

<div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> - This then forbids normalisation again.<br></blockquote><div><br></div><div>[Comment]</div>

<div>That's correct, it's a different part of the workflow.  See this flowchart:</div><div><a href="http://www.realjabber.org/flowchart_of_xmpp_rtt_path.pdf" target="_blank">http://www.realjabber.org/flowchart_of_xmpp_rtt_path.pdf</a></div>

<div>Normalization can occur outside of the RTT codec path.  Just that code point modification (including normalization) shouldn't happen *after* the sender client encoding of RTT or *before* the recipient client decoding of RTT.</div>

<div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> - Question for Unicode experts. Are there any code points that<br>
would be illegal to transmit on their own, but are legal in<br>
combination with others? If so, they'd get rejected with stream<br>
errors, which would probably be bad. This section seems to imply that<br>
illegal UTF-8 encoding is expected, which is in turn illegal XMPP.<br></blockquote><div><br></div><div>[Comment]</div><div>There is no illegal UTF-8 encoding.  </div><div>It should not imply illegal UTF-8.</div><div>A code point is a completely encoded UTF-8 character (including control codes and non-displayable characters, etc), and I don't say anywhere that a single code point can be ever broken down.  Therefore, a single UTF-8 code point is never broken down.</div>

<div>Can you suggest an alternative wording, that you are able to understand yourself?</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> - "A single UTF-8 encoded character equals one code point" -<br>
this isn't true, is it?<br></blockquote><div><br></div><div>[Question]</div><div>It's true.  Unless, you're misinterpreting "UTF-8 encoded character"?   </div><div>Unicode.org and Wikipedia agrees with me, and my computer programming tests show accurate (perfect) real-time text with this assumption, even with random code points.</div>

<div>"<span style="line-height:19px;font-size:13px;font-family:sans-serif">UTF-8 encodes each of the 1,112,064 code points </span><span style="line-height:19px;font-size:13px;font-family:sans-serif">in the Unicode character set using one to four 8-bit bytes"</span></div>

<div><span style="line-height:19px;font-size:13px;font-family:sans-serif">Can you suggest an alternative wording, so that my explanations are clearer to people like you?</span></div><div>
<span style="line-height:19px;font-size:13px;font-family:sans-serif"><br></span></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> - "different internal encodings (i.e. string formats) that is<br>
different" - s/is/are/<br></blockquote><div><br></div><div>[Change Made]</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">4.6 - "XMPP servers may drop <message/> elements (e.g. flooding<br>

protection)." - They can't.<br></blockquote><div><br></div><div>[Comment & Question]</div><div>Can you suggest an alternative wording that explains situations I've already observed.  I've seen this happen sometimes -- otherwise, they wouldn't survive a DoS scenario.   Picture the scenario where you hold down a keypress and you don't buffer the action elements (as recommended in transmission intervals).  Theoretically, such an implementation would results in about 30 XMPP messages a second (at the regular typematic output of 30 characters per second for a key held down).   Real-time text transmitted immediately per keypress, has resulted in lost messages during some of my tests in the past.  When done on a public server, the server may actually drop some of the messages through some kind of mechanism.   On a good day, many servers can handle 30 XMPP messages a second, but that's a bit extreme.    Also, if an XMPP server decides to buffer the messages instead, there will eventually be server resource-consumption issues if a book falls on a keyboard, or a cat sits on a keyboard.  But the servers (as a matter of DoS code) tends to have some logic to handle a situation of flooding.  Once this stops happening, I've seen "Keeping Real-Time Text Synchronized" detect the prescence of lost message stanzas from <a href="http://jabber.org">jabber.org</a> servers AND <a href="http://talk.l.google.com">talk.l.google.com</a> servers.   So the situation does happen with <a href="http://jabber.org">jabber.org</a> and with <a href="http://talk.l.google.com">talk.l.google.com</a> when I push boundaries of intervals to say, 16-30 millisecond transmission intervals by holding down a keypress.... Sometimes it works when the server is running fast (successfully delivering 30 XMPP messages per second in an extreme torture test), but if it's a busy day, the servers can't keep up.  However, if my wording is wrong with what the servers are actually doing (Are they kicking in DoS protection?   Are they kicking in flooding protection?  Are they kicking in buffer-overflow protection?),  Sometimes when I stop the flood test, and wait a few seconds, it all catches up, other times, I detect discontinuous 'seq' incrementing -- proof of lost message stanzas -- so some kind of network/flooding/DoS/security/etc protection mechanism seems to be kicking in, somewhere, somehow, along the chain. Of course, a 30ms transmit interval might be appropriate for a purpose-built low-latency gaming XMPP network that intentionally transmitted real-time text at much lower latencies, but I'm sure it's not appropriate for <a href="http://jabber.org">jabber.org</a> ....  </div>

<div>Can you describe an alternate wording to replace "XMPP servers may drop <message/> elements (e.g. flooding</div>protection)." that still opens the door for situations that lost message stanzas still, in certain situations, happen?<div>

<br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">4.6.1 - I think they need to do more than increment and check they<br>
increment - I think they need to increment/check in steps of 1.<br></blockquote><div><br></div><div>[Change Made].  I added "by 1" in appropriate places. </div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

4.6.1 - "Recipients MUST keep track of separate real-time messages per<br>
sender, including maintaining independent seq values" - I think what<br>
you mean is that they "MUST track RTT per full-JID, and not collate<br>
across multiple full JIDs", rather than the present text, which<br>
suggests that they must track multiple RTT streams for a single full<br>
JID without providing guidance how. I think this needs tightening up<br>
to be clear of the intent.<br></blockquote><div><br></div><div>[Comment & Question]</div><div>No, it is not necessary to tighten up, because I permit clients to simply use bare JID for tracking real-time text.   It does not need tightening up because in a scenario when there's a simultaneous login, one starts typing, pauses the message, and resumes typing on the other system.   The "Keeping Real-Time Text Synchronized" will automatically swap the real-time message with the real-time message from the other system (within 10 seconds) thanks to Message Reset.   This is an acceptable user experience, and I want to make full JID tracking optional, since it's simpler for implementations to keep track of only one real-time message.   </div>

<div><br></div><div>For example, an implementer might only support one real-time message per chat window.  In this case, tracking by bare JID is acceptable, as the "Keeping Real-Time Text Synchronized" will automatically and seamless handle the situation of switching clients during simultaneous logins.   Therefore, it's NOT necessary to tighten up (and shouldn't be done, because it complicates simple implementations that wish to do a one-real-time-message-per-chat-window method).    These clients would presumably not be implementing MUC either.</div>

<div><br></div><div>Single message-per-chat-window implementations (even with Simultaneous Logins):  </div><div>An explanation for this was given several times in the past -- the UX is actually quite acceptable even when multiple senders (of simultaneous logins) have multiple separate partially-composed messages in each concurrent login, and switches between them.   It works intuitively for end-users; the recipient just sees the whole real-time message gets replaced by the correct sending client's real-time message (within 10 seconds) thanks to Message Reset).   No scrambling becomes visible to end user, thanks to the "Keeping RTT Synchronized" mechanism.   Simultaneous Logins, in more than 99%+ of the cases, only has one typist active at a login, so the "Keeping RTT Synchronized" mechanism works well in these situations -- the recipient's view of the real-time message simply swaps to the correct one from the correct client automatically (during the next Message Reset, which would occur within 10 seconds). </div>

<div><br></div><div>It is acceptable and simpler for implementers to NOT REQUIRED keeping track per full JID, because I want to permit single-message-per-chat-window implementations for simplicity.<br>But do you think I should explain why full JID is NOT REQUIRED?   If so, I'd love to hear suggestions.</div>

<div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">4.6.2 - "Recipients MUST freeze the current real-time message" - it's<br>
not clear what freezing a message means.<br></blockquote><div><br></div><div>[Change Made]</div><div>I have made a change"Recipients MUST keep the pre-existing real-time message unchanged"</div><div>When I said "freeze", I meant pausing the message (not cleared, but unaffected by subsequent RTT elements).  In a vast majority of implementations, this would simply mean the user experience simply see a pause in incoming real-time text (if the software detects out-of-sync), until it automatically recovers during the next Message Reset where the user perceives the message text surging forwards and "catches up".   No scrambling occurs since subsequent conflicting RTT is ignored.</div>

<div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">4.6.3 - "Retransmission SHOULD be done at an average interval of 10<br>
seconds during active typing or composing." - this seems like a lot of<br>
data getting sent across if these messages are large. I'd be much<br>
happier saying something like "Retransmission SHOULD NOT be done more<br>
frequently than once every 10 seconds<br></blockquote><div><br></div><div>[Comment]</div><div>Technically, I agree, but I don't like the "SHOULD NOT" because:</div><div>This would contradict against Basic Real-Time Text which may use a Message Reset every 0.7 seconds for short messages:</div>

<div><a href="http://xmpp.org/extensions/xep-0301.html#basic_realtime_text">http://xmpp.org/extensions/xep-0301.html#basic_realtime_text</a> </div><div>Also, with stream compression, message resets actually use little bandwidth.  It requires far less CPU on a mobile device than the "Monitoring Message Changes Instead Of Key Press" method, as an example.   Although it has the disadvantage of not having key press intervals, it makes an implementation simple, especialy when you're writing software that only handles SMS-sized messages (160 characters or less).  There's often more than 160 characters in overhead in just the <message/> stanza.</div>

<div>In fact, two years ago -- I seem to remember that one of the people at XSF asked me why I didn't simply retransmit the message everytime a message text changed.  I explained that it would be quite a lot of data for large messages.   However, XEP-0301 technically allows it, for really simple implementations of transmitting really short messages, even though I prefer implementers to support preserving key press intervals (which would preclude the use of Basic Real-Time Text).</div>

<div><br></div><div>You notice that I did include wording that this interval can vary to optimize for long messages that are suggestive (i.e. short reset interval for short messages, long reset interval for long messages, less frequent reset intervals for slow message changes, more frequent reset intervals for fast/large amount of message changes)  I'm open to wording a warning/caution about bandwidth.   Comments?</div>

<div><br></div><div>(Replies about section 6 and beyond is split into a separate email message.  Feel free to go ahead and reply without waiting for me to reply about Section 6 and beyond, which might take me a while)</div>

<div><br></div><div>Thanks,</div><div>Mark Rejhon</div></div>