Too late for the LC, I realise, but earlier than the Council vote tomorrow.
4.2.2 - I'm aware than we've had debates in the past about how much needs to be MTI. As things currently stand, the XEP is fairly clear and straightforward, and I wonder if making all of these MTI would be much of an imposition on implementers. 4.7 "For implementation simplicity, recipient clients MAY track incoming <rtt/> elements per bare JID <[email protected]> to keep only one real-time message per sender" Would this really help implementors? Trying to do bare-JID only seems like it's going to involve more complexity and headache than doing full-JID. 4.7 "Alternatively, recipient clients MAY keep track of separate real-time messages per full JID <[email protected]/resource> and/or per <thread/> (Best Practices for Message Threads [9])." I think that some of the earlier instructions will be incompatible with having multiple RTT messages per full-JID. It would be worth someone else checking. 4.7.3 "The message refresh SHOULD be transmitted regularly at an average interval of 10 seconds during active typing or composing. This interval is frequent enough to minimize user waiting time, while being infrequent enough to not cause a significant bandwidth overhead. This interval MAY vary, or be set to a longer time period, in order to reduce average bandwidth (e.g. long messages, infrequent or minor message changes)." It feels to me like this is really saying "It is suggested that a message refresh be transmitted regularly at an..." - otherwise the SHOULD and the MAY seem contradictory. 4.8.2 "In addition, XML character entities are counted as a single character." Isn't the RTT editing calculated before XML encoding in the sender and after XML decoding in the recipient? This statement seems redundant (or worse, misleading) to me. 6.2.1 "it is inappropriate to send any further <rtt/> elements, until support is confirmed either by incoming <rtt/> elements or via discovery." This needs to be normative somewhere, I think, that clients MUST NOT start transmitting RTT edits until support has been confirmed. I don't think the non-normative information note here is going to be sufficient. Discovery for MUCs isn't covered - I think it needs to be; blithely sending RTT to an unsuspecting MUC would not be good. 6.4.4 - the seqs here aren't sequential - is that deliberate? 10.1 Some clients pop up chat windows when incoming messages are received - I think it's worth a note here that such behaviour isn't appropriate with RTT, as grabbing focus without the user's request can mean that passwords get stolen into chats with other people. It's still long, but I found the XEP much clearer and easier to read than I did the early versions, so thank you to the authors for the improvements they've made. /K
