> > 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) >
Correction: **recipients** should always be notified of incoming RTT attempts, much like **recipients** are always notified of incoming audio/video attempts in software supporting audio/video. (Apologies -- long day for me!)
