On Jun 30, 2012, at 3:03 PM, Gregg Vanderheiden wrote: >> 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.
I think the send RTT default should be left to the software designer. I do think there is a mild security consideration in users may be caught aware of a default-on implementation will have their edits unknowingly disclosed to those they are conversing with. There are a number of ways a software designer can mitigate this risk, such as improving user awareness of the issue. I don't see the issue as severe enough to warrant a recommendation that RTT sending be opt-in. > Users SHOULD even be able to have an auto-reject for any invitations for RTT. > (so they never see it) We have to be careful here. An auto-reject mechanism can easily end up disclosing the validity of the JID when the user hasn't otherwise disclosed it to the sender, or disclose user's presence, etc.. > Clicking on the RTT button however should override this default session. I don't we should get too specific about the components a U/I should have. > And the client SHOULD NOT say they cannot technically handle RTT when they > can. I disagree. > 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. When a user disables a feature, it should not be advertised. > User choice is good. > Technical miscommunication of capabilities though is not a good idea I don't > think. It's not a miscommunication of the features enabled. I note that there's lots of features which a user might disable for which some other party might want to know are implemented in their client. Historically, we've not provided discovery for user disabled features. > > 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 > > > > > > > > >
