On Wed, Jun 27, 2012 at 2:44 AM, Kurt Zeilenga <[email protected]>wrote:
> On Jun 26, 2012, at 5:08 PM, Mark Rejhon wrote: > > Computers, networks, encryption is gradually becoming faster, and even > stanza-level encryption for RTT > > Maybe one day we'll have virtually unlimited bandwidth everywhere... but > that's simply not the case today and likely won't be the universally case > for many decades (if ever). > Even fast typing over real-time text, is still rate-limited to 1 stanza every interval (such as 700ms or 1 second) Multiple keypresses gets put into the same stanza if multiple keypresses in one interval cycle. Stanza level encryption performance is sufficient to support that, even on smartphone CPU's today. In borderline situations, you could adjust transmission intervals to violate the recommended range 0.3s-1.0s (I only made that range a 'SHOULD') -- such as transmitting real-time text at 2 second intervals instead. There would be a 2 second lag in typing and it would not comply with ITU-T F.703, but near-real-time-text ends up being more usable than line-by-line mode. Such situations where degraded near-real-time XEP-0301 is necessary is rare, but I left wiggle room in XEP-0301 to use long intervals -- i.e. ultra narrowband networks or extreme congestion (i.e. Iridium satellite style, Mobitex style, overloaded GPRS, rural dialup, etc.) (...Conversly, on the opposite side of extremes, private peer-to-peer XMPP using XEP-0301 could even use a 0s transmission interval -- instantly transmit stanzas on every keypress -- as it wouldn't be a public network loading concern.) > Regarding accessibility issues, I would welcome an XEP which discussed > accessibility issues in XMPP, especially core services such as IM and > presence. I'd also welcome addition of an "Accessible Considerations" > section to this and other XEPs detailing protocol extensions. That is an excellent idea. An Accessibility XEP is useful in the future, if someone wants to start it (I'd be happy to help). It should contain at least a section about Total Conversion for the Europeans (audio+video+RTT), coverage of ITU-T F.700 and F.703, the best-practices of always making RTT available on a best-effort basis, other Accessibility-related XEP's, applicability to other segments such as the blind, etc. As for an Accessibility section to XEP-0301, that could be a good idea too. Some material is already in the spec already, which could transferred to that section instead. Also mentioning the recommendation that clients that don't want to do RTT by default (i.e. mainstream clients), it is STRONGLY RECOMMENDED to advertise RTT support, and should still be receptive to incoming RTT (Even if it has to prompt a confirmation to recipient upon first incoming <rtt/>, much like confirming an incoming audio/video connection), in order to remain 'accessible'. This gives deaf & HOH senders a 'chance' to at least be able to attempt RTT with any software that supports XEP-0301 but has it dormant by default. i.e. it should be NOT RECOMMENDED to stop advertising RTT via iq query in Section 5 of the spec, or that prevents widespread availability of potentially-receptive recipients that RTT can be initiated to. (i.e. senders should always be notified of incoming RTT attempts, much like senders are always notified of incoming audio/video attempts in software supporting audio/video) Mark Rejhon
