Peter, > > Section 4.2.3 > > > > XEP-0308 specifies use of "id" in <message> and <replace>. Could we > > not just use "<replace>" along with "<rtt>"? It would require some > > text in > > XEP-0308 that says that if <replace> is received without <body>, it > > shall be ignored. In -0301, it would not be ignored. "id" works, but > > I would not immediately recognize what that was for if I had not read > > this part of the spec. > > I don't quite follow your line of reasoning here.
Sorry for the lack of clarity on that one. I'm wondering how we enable text to be sent real-time for messages that are being replaced as described in XEP-0308. Consider examples 3 and 4 in XEP-0308. Can we do the following? User types: <message to='[email protected]/balcony' id='bad1'> <rtt><t>But soft, what</t></rtt> </message> <message to='[email protected]/balcony' id='bad1'> <rtt><t> light through yonder airlock breaks?</t></rtt> </message> <message to='[email protected]/balcony' id='bad1'> <body>But soft, what light through yonder airlock breaks?</body> </message> Now, the user wants to replace the word "airlock" with "window": <message to='[email protected]/balcony' id='good1'> <rtt><e p="36" n="7/></rtt> <replace id='bad1' xmlns='urn:xmpp:message-correct:0'/> </message> <message to='[email protected]/balcony' id='good1'> <rtt><w n="300"/><t p="36">bre</t></rtt> <replace id='bad1' xmlns='urn:xmpp:message-correct:0'/> </message> <message to='[email protected]/balcony' id='good1'> <rtt><w n="120"/><t p="39">ks</t></rtt> <replace id='bad1' xmlns='urn:xmpp:message-correct:0'/> </message> <message to='[email protected]/balcony' id='good1'> <rtt></rtt> <replace id='bad1' xmlns='urn:xmpp:message-correct:0'/> </message> <message to='[email protected]/balcony' id='good1'> <body>But soft, what light through yonder window breaks?</body> <replace id='bad1' xmlns='urn:xmpp:message-correct:0'/> </message> If this is valid, we need to say somewhere that <replaces> might be transmitted without a <body> element. XEP-0308 defines use of <replaces>, so it might need some wording. XEP-0301 might likewise need to consider some wording to describe this. > > Section 6.2.1: > > > > I think the activation logic is complex. Let each user turn it on or > > off as he sees fit. If you send <rtt> tags to my client, whether that > > gets renders or not depends on my local settings. I don't see a > > strong need to negotiate this. Just always send <rtt> and display it > > (if received) whenever the user enables RTT. > > The objection here is that if my client doesn't support RTT and you send > me RTT despite that fact, I will end up receiving a lot more data than I > need to or want to (e.g., this extra data might cost me money by running > up my bandwidth usage). Clients learn about RTT support via disco. This section has to do with alerting the user of a device that supports RTT, but has it disabled, that the remote user is sending RTT. It allows said user to accept RTT (perhaps turning on RTT display) or rejecting it (sending a "cancel"). I think. I'd rather not advertise RTT if I have it turned off. That way a sender will not even attempt to send it. I'm not sure what would happen if I turned on RTT during the middle of the chat session. Would devices be notified of the change in capabilities? In any case, this seemed like a confusing capability negotiation mechanism that allows for interaction with the user in each IM session. Perhaps it's useful, but if I want RTT on, I'll turn it on. If I want it off, I'll turn it off. I would not want to be asked on a per IM session basis if I want to enable RTT. It would annoy me to no end. I'm just looking for ways to make this spec simpler and still maintain the utility of XEP-0301, which I personally find valuable. The "init" and "cancel" events seem to make XEP-0301 unnecessarily more complex to develop and I get the feeling it will be frustrating to the end user. That said, I've been wrong before... Paul
