[Standards] XEP-0301 -- starting and stopping real-time text in a chat session.

Kurt Zeilenga kurt.zeilenga at isode.com
Sun Jul 1 15:34:19 UTC 2012


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
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>>> 
>> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20120701/8d2df1ef/attachment.html>


More information about the Standards mailing list