Re: [Standards] Call for Experience: Advancement of XEP-0301 (In-Band Real Time Text) to Final
On Thu, Oct 22, 2015 at 4:03 PM, Peter Saint-Andre - &yet 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: > Fellow members here will observe this is fairly quick for a CfE. Some background info: We decided to request CfE rather early, to get comments necessary to improve the standard as much as possible (if any changes needed). No protocol change is anticipated; just simple errata, editorial and implementation detail clarifications. 1 -- developer experience indicates XEP-0301 is well-engineered (despite over-engineering); 2 -- our annual review of standard repeatedly show virtually no need for changes; 3 -- there is a regulatory incentive 4 -- this october 2015, there is a sudden increase in RTT interest Access-Board.gov http://www.access-board.gov/guidelines-and-standards/communications-and-it/about-the-ict-refresh/proposed-rule/v-major-issues "Yet despite its potential benefits, the Board cannot incorporate XEP-0301 until it becomes a final standard. However, should the XEP-0301 standard be finalized before publication of the final rule, the Board plans to incorporate it by reference as an alternative technology to support transmission of RTT when interoperating with VoIP products or systems using XMPP. RFC 4103 would, in any event, be retained for ICT interoperating with VoIP products or systems using SIP technology." FCC Grants AT&T waiver to introduce real-time text to replace TTY: http://www.commlawmonitor.com/2015/10/articles/disabilities-access/fcc-grants-att-waiver-request-to-use-real-time-text-for-hearing-impaired-communications/ This will be RFC4103, but will need to interop with XEP-0301. AT&T plan is for 2017: https://www.fcc.gov/document/tty-rtt-transition-waiver-att AT&T mentions XEP-0301 in their RTT presentation: http://g3ict.org/design/js/tinymce/filemanager/userfiles/File/2015%20Summit/Aaron%20Bangor_Standards.pdf I should note I am not employed by AT&T and have no financial benefit from this.However, I want to be sure that XEP-0301 is absolutely as mature as possible in these short timescales we're asking, preferably far before 2017, given implementation timescales and the sudden increase in RTT interest in the telecom world. Also, proprietary implementations of XEP-0301-like real-time text already exist. http://www.beammessenger.com/ as an example. Having a clear standard that is promoted to FINAL sooner than one may expect is normal for certain XSF standard, would encourage more implementers to choose XMPP for messaging and, consequently, XEP-0301. Fortunately, developer experience on 0301 has been overall generally more-positive-than-expected (considering size of standard); and we look forward to hearing more CfE feeback. Thanks, Mark Rejhon
Re: [Standards] Call for Experience: Advancement of XEP-0301 (In-Band Real Time Text) to Final
On Thu, Oct 22, 2015 at 10:07 PM, Lance Stout wrote: > Several open-source libraries now support RTT: > > - Babbler (https://bitbucket.org/sco0ter/babbler) > - Strophe (via https://github.com/cvogler/trophyjs) > - Stanza.io (https://github.com/otalk/stanza.io + > https://github.com/otalk/rtt-buffer) > > Additionally, RTT is now being used in production by Talky ( > https://talky.io). > Generally positive developer testimonials on XEP-0301: https://blog.andyet.com/2015/10/19/talky-gets-real-time-text (Talky) "There are of course more little implementation [UX] details and potential Unicode issues that the XEP-0301 spec covers, but the fundamental model is *remarkably simple and fun to implement*." http://babbler-xmpp.blogspot.de/2015/07/xmpp-real-time-text-in-action.html (Babbler) "XMPP Real-time Text is definitively *one of the most fun XMPP extension out there*, from user's point of view as well as *from a developer's point of view*! Recently I've added support for it in the upcoming version 0.6.0 and I thought I'd make a short video which demonstrates this cool new feature in action!" Another project, jabber.el supports it as well (written in Emacs Lisp!): https://github.com/legoscia/emacs-jabber/blob/master/jabber-rtt.el We have privately received some minor non-compatibility-related errata from some of the developers of the aboveformentioned libraries: -- XML namespace correction (does not affect existing implementations) -- Minor implementation-related ambiguities (i.e. may need a little bit of additional text in implementation notes); no protocol change I'll let author(s) chime in directly (calling out, specifically, Christian Schudt -- babbler author) Thanks, Mark Rejhon Author of XEP-0301
Re: [Standards] Call for Experience: Advancement of XEP-0301 (In-Band Real Time Text) to Final
> 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] Several open-source libraries now support RTT: - Babbler (https://bitbucket.org/sco0ter/babbler) - Strophe (via https://github.com/cvogler/trophyjs) - Stanza.io (https://github.com/otalk/stanza.io + https://github.com/otalk/rtt-buffer) Additionally, RTT is now being used in production by Talky (https://talky.io). > 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. Quite the contrary! Implementing XEP-0301 was a very enjoyable experience, as every question I had while implementing ended up being directly answered in the XEP. I believe the XEP fully covers the problems it sets out to address. > 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. It is very clear and unambiguous. Seriously, Mark and Gunnar have gone remarkably out of their way to provide all of the guidance needed to create an implementation. Not only for a complete implementation, there is guidance on how to extract the most value out of partial support of RTT. — Lance smime.p7s Description: S/MIME cryptographic signature
[Standards] Call for Experience: Advancement of XEP-0301 (In-Band Real Time Text) to Final
[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 standards@xmpp.org discussion list. Thanks! Peter [1] http://xmpp.org/extensions/xep-0001.html#approval-std
