On Fri, Jul 20, 2012 at 2:49 PM, Gunnar Hellström <span dir="ltr"><<a href="mailto:gunnar.hellstrom@omnitor.se" target="_blank">gunnar.hellstrom@omnitor.se</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<br>
Your current sentence is:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">


<br>
"to have improved presentation of real-time text during message correction"<br>
</blockquote></blockquote></blockquote>
<br>
<br>
I understand now that there may be real-time display during last message correction. And that full support causes improved presentation. So you may keep the sentence.<br>
<br>
I am a bit afraid that all the cases you describe of mixed support or not for XEP-0301 and XEP-0308, and transmitting features with or without completed negotiation contain a lot of risks for unexpected behavior. </blockquote>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Will it for example be possible to return to appending text in a normal way at the end of the current message after you have completed editing corrections if your receiver does not understand the rtt id attribute but receive them and act on them. Do you have any rules for how to leave the current message, and how to return to it? Will the received messages with <body/> really erase the right part of the real-time delivered text?<br>

</blockquote><div><br></div><div>Two things:</div><div>(1) The modified text specifies that a message reset is used whenever switching between messages.  That solves the problem, irregardless of whether the clients acts on the 'id' attribute. </div>

<div><br></div><div>(2) The [[[Body Element]]] part of XEP-0301 requires you to clear the real-time message when a body is delivered.   <br>But actually, I just realized this point is 100% moot....because it is cleared/replaced anyway in the next <rtt event='new'/> or <rtt event='reset'/> anyway.   Which is exactly what also will occur when switching between messages (last message and current message).   A chat session only has one real-time message per sender, and it is always cleared/replaced by event='new' / event='reset'</div>

<div><br></div><div>(Note: Message resets are also used when switching computers, switching windows, and switching chat programs between the same participants)</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">

Would it not be safer to say that you must support receiving id= and reacting properly if you declare support of both XEP-0301 and XEP-0308, and that you shall not send id attributes if negotiation for support of both XEP-0308 and XEP-0301 fail?</blockquote>

<div><br></div><div>If several people say so, I can consider that. </div><div><br></div><div>But I agree with Kevin that XEP-0301 and XEP-0308 can be usable by senders and/or recipients not using 'id'</div><div>I'd rather fix the rest of the spec to be unambigiously clear about business rules -- let me know if there are confusing sentences in XEP-0301 that can be clarified, to ensure spec compliance (for full XEP-0301 / XEP-308 interop)</div>

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