[Standards] XEP-0301 Accessibility (resurrected)

Gunnar Hellström gunnar.hellstrom at omnitor.se
Mon Jul 9 15:07:08 UTC 2012


Mark wrote:
> ....Peter/Kevin did express last year it was not "xmpp-ish", but a 
> majority of people I correspond with, say Accessibility concerns is 
> more important.  (See above)
> ....XEP-0301 is slightly an outlier of a standard here, because it 
> contains lots of elements normally reserved for other layers.  It 
> essentially has its own error detection and recovery, which is already 
> proven necessary in real-world testing (mentioned in past messages, 
> and now encapsulated at 
> http://xmpp.org/extensions/xep-0301.html#keeping_realtime_text_synchronized ). 
>  It's so self-contained that it's making better and better sense (due 
> to Accessibility, too), to put activation/deactivation capabilities 
> inline into it, irregardless of disco.
> ....Bandwidth concern was mentioned last year but sending a single 
> <rtt/> element actually uses less bandwidth than sending a disco iq. 
>  So the bandwidth concern is essentially moot.
> ....Again, I also like the simplification that putting 
> activation/deactivation features inline into <rtt/> does, making 
> "XEP-0301 plugins" much easier for many existing clients using their 
> existing XMPP libraries?
>
>
> I'd like to hear comments from other people about this "Accessible" 
> improvement to "Determining Support".
> If there are anybody here who dislikes this, I'd like suggestions of 
> alternatives that still meets the 1-2-3 accessibility requirements 
> mentioned above.
>
> Thanks,
> Mark Rejhon

Mark,
Was it my comment 28 that caused your response about accessibility?

28. Chapter 5. last paragraph. I hesitate a lot about this simple way of 
detecting support. We need a proper way to detect RTT capability before 
we start to use it. There may be systems that have to select between 
different protocols for RTT, and they should not need to start sending 
in one protocol to try to discover if RTT is supported.
Still, I realize the convenience of this simple method, and would let a 
discussion decide if it shall be kept.
If it is kept, the paranthesis characters on the second line should be 
deleted so that the rapid response on this initiation is made part of 
the protocol.
----------------------------------------------------------------------------------------------------------------

I did not understand your reasoning, why the empty <rtt> method to start 
RTT would be more accessible than the Determining support with Disco. 
Please explain!

I wanted to say that I liked the Disco method, because then a multimedia 
system can interrogate what ways it has available to get a real-tine 
text media channel going with another party.
We see some efforts to declare XMPP media in SIP, and we have RTP 
possibilities in XMPP through Jingle. For these cross-technogy efforts, 
it will be crucial to be able to check detailed functionality of the 
other party to decide what media transport to use.
It is not sufficient to know that XMPP is supported for a text channel. 
We also need to be able to check if XEP-0301 is supported before we 
select to go the XMPP way with media establishment. Similarly as with 
the text/t140 sdp declaration for RFC 4103.

Sending empty rtt implies that we have already selected to use XMPP, and 
then want to try to initiate real-time text in that channel. What if the 
other party did not have that support, but had RTP based RFC 4103. Do we 
then need to continue with clunky message-wise texting just because we 
took a chance to check if RTT was available the XMPP-way. That is not 
what we wantwith accessibility.

However in my comment 28, I also say that I realize that it is simple 
and convenient for cases when you only have XMPP at hand, and need to 
select between clunky or smooth. And thatI want discussions like this 
lead to a decision if both methods shall be mentioned. Options are 
usually harmful and lead to uninteroperability.


Gunnar





-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20120709/e2ffc51b/attachment.html>


More information about the Standards mailing list