[Standards] XEP-0301 -- starting and stopping real-time text in a chat session.
kurt.zeilenga at isode.com
Sun Jul 1 06:14:34 UTC 2012
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.
> 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.
> 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?
> 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...
More information about the Standards