> I've only glanced at it late on a Saturday night, but it seems sensible. > >> QUESTIONS as follows: >> 1. Are there other scenarios that XEP-0301 implementors want to see "made >> possible", not currently possible with the current protocol? > > I know the 'disable RTT completely' option isn't popular, but I do > think that if a user wants to never receive RTT (and I do think that's > a valid user choice, especially if they're paying for bandwidth or > whatever) that removing RTT from caps is the way to signal this, and > it's worth calling this out. > > /K
If I am misunderstanding what you mean -- then ignore this. Are you saying that (if the user doesn’t want RTT) the client should say that it can't handle RTT (the client won't include that capability in its list of capabilities when asked)? The problem here is that in emergency situations -- RTT becomes critical - as in life saving. Have it turned off all the time is fine. But the client software should not say that it CAN'T do RTT when it is just that the user wants it to be turned off. Otherwise emergency personnel can't determine that it could be turned on and ask the user to push the button to do so. (Emergency personnel don't want to be telling a caller to look for a button that is not there). Often emergency personnel want to have a continual conversation (or continual text flow) so they can keep the person alert and can tell if the person is becoming incoherent before they pass out etc. Users SHOULD be able to turn RTT off. Users SHOULD even be able to have an auto-reject for any invitations for RTT. (so they never see it) Clicking on the RTT button however should override this default session. And the client SHOULD NOT say they cannot technically handle RTT when they can. Perhaps it might answer NO on first query -- but answer yes if asked a second time (this is a not-unusual behavior). But it should not consistently say that it cannot handle RTT when it can - and it is just not the user's preference. User choice is good. Technical miscommunication of capabilities though is not a good idea I don't think. It is clear what I am getting at? thanks Gregg -------------------------------------------------------- Gregg Vanderheiden Ph.D. Director Trace R&D Center Professor Industrial & Systems Engineering and Biomedical Engineering University of Wisconsin-Madison Co-Director, Raising the Floor - International and the Global Public Inclusive Infrastructure Project http://Raisingthefloor.org --- http://GPII.net
smime.p7s
Description: S/MIME cryptographic signature
