Hi everyone, and apologies for jumping in so late - 1. I've implemented XEP-0301 in Trophy.js, which is a module for Strophe.js. Code and live implementation can be found at http://tap.gallaudet.edu/rtt/
2. No problems whatsoever - in fact, the spec was remarkably easy to implement overall. Any issues and frustrations had much more to do with Javascript's warty support for Unicode than the spec itself. And the spec is very clear about how Unicode is supposed to be handled. 3. The spec is very well written and very clear. Just a few minor comments: a. I don't see the use case for tracking RTT state by full JID. It seems to me that in most situations, tracking by bare JID would result in the most consistent and best user experience. This could perhaps be made clearer. b. RTT init and RTT cancel look like a lot of extra work to implement, and since XEP-0301 is fully compatible with turn-based messaging, there is no apparent usability benefit. The only benefit seems to be to cut down on network bandwidth, by not transmitting RTT if the remote side is not interested in displaying RTT. Is this worth the price of a more complicated spec? Best wishes Christian On Tue, Nov 3, 2015 at 1:03 PM, Mark Rejhon <[email protected]> wrote: > +Cc: Christian Vogler > > For completeness sake, I'm very interested in seeing Christian follow up. > He is the author of http://tap.gallaudet.edu/rtt/ supporting XEP-0301. > > On Thu, Oct 22, 2015 at 4:03 PM, Peter Saint-Andre - &yet < > [email protected]> wrote: > >> [sending on behalf of the XSF's Editor Team] >> >> At its meeting on October 21, 2015, the XMPP Council agreed to issue a >> "Call for Experience" regarding XEP-0301 (In-Band Real Time Text), in >> preparation for perhaps advancing this specification from Draft to Final in >> the XSF's standards process. To help the Council decide whether this XEP is >> ready to advance to a status of Final, the Council would like to gather the >> following information: >> >> 1. What software has implemented XEP-0301? Please note that the protocol >> must be implemented in at least two separate codebases (at least one of >> which must be free or open-source software) in order to advance from Draft >> to Final. [1] >> >> 2. Have developers experienced any problems with the protocol as defined >> in XEP-0301? If so, please describe the problems and, if possible, >> suggested solutions. >> >> 3. Is the text of XEP-0301 clear and unambiguous? Are more examples >> needed? Is the conformance language (MAY/SHOULD/MUST) appropriate? Have >> developers found the text confusing at all? Please describe any >> suggestions you have for improving the text. >> >> If you have any comments about advancing XEP-0301 from Draft to Final, >> please provide them by the close of business on Friday, November 6, 2015. >> After the Call for Experience, this XEP might undergo revisions to >> address feedback received, after which it will be presented to the XMPP >> Council for voting to a status of Final. >> >> You can review the specification here: >> >> http://www.xmpp.org/extensions/xep-0301.html >> >> Please send all feedback to the [email protected] discussion list. >> >> Thanks! >> >> Peter >> >> [1] http://xmpp.org/extensions/xep-0001.html#approval-std >> > > -- Christian Vogler, PhD Director, Technology Access Program Department of Communication Studies SLCC 1116 Gallaudet University http://tap.gallaudet.edu/ VP: 202-250-2795
