<div class="gmail_quote">Re: <a href="http://xmpp.org/extensions/inbox/realtimetext.html">http://xmpp.org/extensions/inbox/realtimetext.html</a></div><div class="gmail_quote">Hello Peter, -- thank you so much for your comments.</div>

<div class="gmail_quote">I've addressed some of the comments in my reply to Kevin. </div><div class="gmail_quote">I wrote a very good response to Kevin.</div><div class="gmail_quote"><br></div><div class="gmail_quote">



<br></div><div class="gmail_quote">On Thu, Jun 23, 2011 at 12:03 AM, Peter Saint-Andre <span dir="ltr"><<a href="mailto:stpeter@stpeter.im" target="_blank">stpeter@stpeter.im</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">



"Reliable message delivery."<br></blockquote><div><br></div><div>Changed to "Reliable real-time text delivery." which is actually the intent.</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 Why SHOULD 0 (rather than MUST)?<br>
 +1 to MUST.<br></blockquote><div><br></div><div>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.  </div>

<div>That said, I've changed it to a MUST anyway -- it's no harm.</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.3 - Start shouldn't be used for discovery, disco/caps should.<br>
</blockquote><div><br></div><div><span style="border-collapse:collapse;color:rgb(51, 51, 51);font-family:arial, sans-serif;font-size:13px">We want to address this too, but a clarification: </span>start isn't used for disco, it's used for signalling:</div>


<div>"<span style="border-collapse:collapse;color:rgb(51, 51, 51);font-family:arial, sans-serif;font-size:13px">Experimentation during the Experimental stage is needed to determine best interoperability for the process of <i>starting</i><i> </i>a real-time-text session and <i>signalling</i> 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." .... </span></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.3.2 Seems inappropriate - we should only be suggesting UI<br>
> behaviours, where they're not security critical, not mandating them.<br></blockquote><div><br></div><div>Section 4.3.2 is not UI -- it is a critical feature of XMPP Real Time Text.</div>
<div>For an animation that explains why 4.3.2 is necessary:</div><div><a href="http://www.marky.com/realjabber/real_time_text_demo.gif" target="_blank">http://www.marky.com/realjabber/real_time_text_demo.gif</a></div><div>

It also maintains backwards compatibility too with non-RTT clients.</div>
<div> </div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
That seems right. </blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Looking at the text and examples, I wonder if just sending a message<br>
with a <body/> is enough information for the recipient to present the<br>
messages appropriately. Consider this example:<br>
<br>
<message to='juliet@capulet.lit' from='romeo@montague.lit/orchard'<br>
type='chat' id='a01'><br>
  <rtt xmlns='urn:xmpp:rtt:0' seq='0' event='new'><br>
    <t>Hello, </t><br>
  </rtt><br>
</message><br>
<br>
<message to='juliet@capulet.lit' from='romeo@montague.lit/orchard'<br>
type='chat' id='a02'><br>
  <rtt xmlns='urn:xmpp:rtt:0' seq='1'><br>
    <t>my </t><br>
  </rtt><br>
</message><br>
<br>
<message to='juliet@capulet.lit' from='romeo@montague.lit/orchard'<br>
type='chat' id='a03'><br>
  <rtt xmlns='urn:xmpp:rtt:0' seq='2'><br>
    <t>Juliet!</t><br>
  </rtt><br>
</message><br>
<br>
<message to='juliet@capulet.lit' from='romeo@montague.lit/orchard'<br>
type='chat' id='a04'><br>
  <body>Dude, what happened to my message?</body><br>
</message><br></blockquote><div><br></div><div>It's legitimate -- it also happens in the real world:</div><div>Somebody immediately copies and pastes a message on top of the old message, and then hits Enter immediately.</div>

<div><br>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'</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">How does the recipient know that the last message is related or<br>
unrelated to the previous RTT fragments?<br></blockquote><div><br></div><div>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.</div>

<div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
We might consider including something like this in the last message:<br>
<br>
<message to='juliet@capulet.lit' from='romeo@montague.lit/orchard'<br>
type='chat' id='a04'><br>
  <rtt xmlns='urn:xmpp:rtt:0' event='done'><br>
  <body>Hello, my Juliet!</body><br>
</message><br>
<br>
That raises the question of whether we need identifiers for each RTT<br>
"sequence", as so:<br></blockquote><div><br></div><div>I used to have message identifiers in XMPP RTT specification version 0.0.1 as the "msg" attribute!</div><div>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.</div>


<div><br></div><div>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.</div>

<div><br></div><div>(At this stage, I'd like to hear agreement from several people first though about this detail.)</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.1 insert is ambiguous - what does 'at position p' mean?<br>
>       Forward delete should be explicitly rightwards, if that's the intent.<br>
> How does this play with RTL languages?<br>
 Good questions.</blockquote><div><br></div><div>Forward Delete is a leftwards delete in Arabic, according to Wikipedia, and in Apple Mac's help file.</div><div>I'm adding clarifying wording, though.</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.5.1.3 Why are we dealing with utf-16 when everything is mandated utf-8?<br>

<br>
UTF-8 FTW.<br></blockquote><div><br></div><div>What do you think of Simon's suggestion?</div><div>I am switching to "code point" (UCS4 counting) method.</div><div><br></div><div>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.<br>


</div><div><br></div><div>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.  </div>

<div><br></div><div>However, I am thinking of following Simon's excellent suggestion.</div><div><br></div><div>What do you think of his suggestion of using "code point" counting for length and position attributes?  </div>

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

<div><br>Opinion?</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">Also, this seems inconsistent with the forward delete function:<br>


<br>
"If the p attribute is omitted, the default value for p is the length of<br>
the current real-time message."<br>
<br>
How is that applied to the <d/> element? Is the 'p' attribute REQUIRED<br>
in that context? (You can't forward delete beyond the end of the message.)<br></blockquote><div><br></div><div>Excess backspaces and deletes are ignored, so that ends up becoming a do-nothing element. <br>Useless action elements shouldn't be used for bandwidth reasons, perhaps I should mention that detail in the spec.  (making note to mention this.)</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">In Section 6.4:<br>
<br>
<message to='<a href="mailto:bob@example.com" target="_blank">bob@example.com</a>' from='<a href="http://alice@example.com/home" target="_blank">alice@example.com/home</a>' type='chat'<br>
id='a01'><br>
  <rtt xmlns='urn:xmpp:rtt:0' seq='0' event='new'><br>
    <t>Hello Bob, this is Alice!</t><d n='4' p='5'/><br>
  </rtt><br>
</message><br>
<br>
Why not send two stanzas?<br></blockquote><div><br></div><div>That can be done. The examples are merely at educating people on real time text, at progressively more difficult levels.  </div><div><br></div><div>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.</div>

<div><br></div><div>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.</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">
Section 7.1 talks about interoperability with RFC 4103 and T.140. How<br>
does an XMPP entity negotiate an RTT session with a SIP entity? (I'm<br>
wondering if we need a Jingle application type for RTT...)<br></blockquote><div><br></div><div>The RFC4103 people are covering that.  I've published a SUPPLEMENT document on <a href="http://realjabber.org">realjabber.org</a> that briefly touches upon this; and will be expanded.  Gunnar Helstrom of Omnitor, is the go-to guy for this.</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">That's all for now. Good work!<br></blockquote><div><br></div><div>Thanks!</div><div>

Mark Rejhon</div></div>