On Jun 30, 2012, at 11:59 PM, Gregg Vanderheiden wrote: > Kurt > > You did not comment on the fact that turning off RTT in a way that emergency > personnel cannot determine that RTT is an option can put users at greater > risk in an emergency. Did you note that?
Yes. I had intended to respond to that later. In short, I think the potential use of XMPP IM/RTT in emergency services should not only be beyond the scope of this spec, and used as basis for making any design design or stating of any particular requirement/recommendation. The use of non-specialized XMPP software/systems for emergency services seems quite speculative. > What did you think is the risk in letting people know that a software client > has a capability but the user does not prefer to use it? Well, this would more directly disclose a choice made by the user, and any time software discloses choices made by a user there can be privacy concerns. Given that it generally easy to determine what client software a person is using, one can hence already deduce the software configuration choices they made. So, from a privacy perspective, I don't presently see this as a significant concern. There's also those who like security through obscurity that might suggest it better not to disclose the capabilities of client. But I don't see buy into this, at least not in this case. > > 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 > > > > > > > > > On Jul 1, 2012, at 1:14 AM, Kurt Zeilenga wrote: > >> >> 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 >>> >>> >>> >>> >>> >>> >>> >>> >>> >> >
