At its recent meeting, the XMPP Council decided not to accept http://xmpp.org/extensions/inbox/realtimetext.html as an Experimental XEP, not because of the feature it provides, but because they felt there were shortcomings in this proposal. At the time, I promised to start a discussion here, on the premise that community discussion will either lead to updates to the proposal and it could be resubmitted, or that another approach would present itself. My comments on the proposal follow, in no particular order or clarity.
1) This is a huge XEP for a relatively simple feature - I copy/pasted the non-boilerplate content into `wc` and ended up with ~=11,600 words. This is a concern (although not a reason to avoid publication on its own, it is daunting). 2) This is a fairly client-complex solution to the problem. Some years ago, I also needed to solve this problem, and deployed a very simple "Send <message ...><fragment>I'm not done typing this messa</fragment></message> every so often" protocol that seemed to work fine. It may be that this approach is unsuitable for the general case, but given the relative complexities of the two approaches, this needs to be discussed (and possibly rejected) as I'd far prefer a simple solution than a complex one. 3) Niggle: "Although real-time text benefits everyone in many situations" - I don't see any support for the 'everyone' in this statement. 4) Goal "Make it easy for developers/implementors to implement Real Time Text in steps, with a minimum of code." may not be being met (see (1)). 5) Goal "Allow multiple modes of chat, including traditional IM user interface, split-screen chat, and other modes." seems like a UI feature, not a protocol feature. 6) Goal "Meet the quality requirements for real-time text. This is specified in ITU-T F.703 [4] with an end-to-end delay of less than two seconds and transmission loss of less than 0.2%." - this seems to primarily be a feature of the networks and servers involved, rather than this protocol. 7) 2.3 Server Performance - I'm picking this out over the other cases for no good reason. Quite a lot of this XEP sounds like it's comments to Council justifying acceptance, rather than a part of the specification. I'd have thought that moving large amounts of this into a trailing Implementation Notes section would make it read better. 8) 2.4 Real-Time Message Editing - isn't half of this just repeating the introduction and AIM advert from the start of the document? 9) 2.6 Multi-User Chat. This needs a great deal of care, as the stanza amplification possibilities for large rooms are horrid. I accept that this has a big experimental warning on the paragraph, but feel it should be noted. 10) 2.7 User Interface Considerations. I think how to design a UI is largely down to the reader and doesn't belong in Requirements, although I'm not opposed to something in Implementation Notes. 11) 3.1 Functional Goals of the Specification. Another set of goals? 12) 3.2 "Clients that do not support real-time text will only receive the full message at once" - they'll receive everything, they'll only understand the full message body. 13) 3.2 "SHOULD show the text immediately" - this sounds like an odd thing to have in a protocol spec. What does 'immediately' even mean here? Are we saying that the client needs to skip any other processing it needs to do to render these data? 14) 3.2 "For senders, the default interval SHOULD be 1 second (1000 milliseconds)" - I don't think this is required for interoperability, so RFC2119 language seems inappropriate here. I think we probably want a reference to a suggested period in Implementation Notes or similar. 15) 3.3 "There MAY also be multiple <rtt> elements in a single <message>" - I'm not sure why you'd want to do this, and it does add client complexity. 16) 3.3 msg/seq Attributes. This says that the attributes should be incremented, but not the magnitude of the delta (I assume 1). 17) I'm not convinced by the need for both msg and seq, given later comments about XMPP compliance (and I note that the simple protocol in comment (2) does away with the need altogether). 18) General - all the protocol outlined in the XEP is illegal, as it's happening in the jabber:client (and jabber:server) namespaces. The new stanza children need to be namespaced away. 19) 3.3.3 "Recipients MUST be able to process type='reset' when transmitting <rtt> with type='reset'" I don't follow the requirement here. 20) A thought - how does this interplay with XEP-0258? (I suspect that many people write messages first, and then label them). This is just an interesting aside. 21) 3.4 Use of <html>. I note that the simple protocol from (2) can trivially support <html> elements. 21) 3.5.2 should probably be clarified that 'empty' means 'with no text child' or such, so that a reader doesn't believe that they may omit the required attributes. 22) 3.5.3 Didn't we earlier read that it was ok to include many <rtt> elements? 23) 3.5.6 "In evaluations of relative values of attributes, values of counters recently wrapped around shall be considered higher than those approaching its maximum value." If we're going to say something like this, we need to be clear what it means. When has a client 'recently wrapped around'? 24) 3.6 Error Recovery. Messages can get lost, certainly, (although -0198 mitigates significantly), but I'm not sure where the assertion about overloaded servers comes from. Servers that deliver messages out of order are incompliant, and we should file bug reports against them so the authors can know about it and fix it, rather that writing (complex) protocol around this. For the little it's worth, I don't know of any current mainstream servers delivering messages out of sequence. I note, again, that the simple (2) protocol is not subject to the problems that this section addresses. 25) 3.6.1 You have to try pretty hard to get duplicate messages through, but it is possible. 26) 3.6.2.3 This has a SHOULD on processing msg, while earlier it was OPTIONAL (I assume you mean OPTIONAL, I don't believe NOT REQUIRED is covered by RFC2119). 27) 3.6.3 "a client MUST immediately pause updating" - this doesn't really need a MUST, there's no requirement for interop here. 28) 3.6.3.2 Why is this OPTIONAL? It sounds like an interop requirement. 29) 3.6.3.3 Given in-order delivery, I don't think this one's necessary. 30) 3.6.4 Here you're using 2119 in a section about UI, in the middle of the Protocol section of the document, and I've no idea what the Google advert is doing in there. 31) 3.7 Is XEP-0020 the appropriate negotiation method here? I'd have thought negotiating a simple Jingle session would be more appropriate? 32) 3.7.1.1.3 The right way of querying for support will be disco/caps. 33) 3.8.3 Some clarification of what a message position is would be beneficial here. I'm cutting off the blow-by-blow review here, as I don't have more time to spend on this, but hopefully this will start sufficient discussion to work out what the next steps are. /K
