Re: [Standards] Call for Experience: Advancement of XEP-0301 (In-Band Real Time Text) to Final

[Lance Stout]

> 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

Re: [Standards] Call for Experience: Advancement of XEP-0301 (In-Band Real Time Text) to Final

[Mark Rejhon]

On Thu, Oct 22, 2015 at 4:03 PM, Peter Saint-Andre -  
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 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 plan is for 2017:
https://www.fcc.gov/document/tty-rtt-transition-waiver-att

AT 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 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