On Sat, Jun 30, 2012 at 9:58 PM, Mark Rejhon <[email protected]> wrote: > On Sat, Jun 30, 2012 at 4:51 PM, Kevin Smith <[email protected]> wrote: >> >> > 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. > > > I know I can't prevent the implementor from doing this (If so, I'd prefer > them make it an opt-out Preferences/Options setting). > There are special consideration arises from this, as follows: > > Turning RTT off prevents incoming <rtt/> from even being signalled at all.
There's two issues. I know you believe that turning off RTT completely is evil and I think that not allowing users to do so is also not good - I'm not suggesting anything about defaults, or policy. The issue I'm addressing is just that if/when a user wants to disable RTT completely, the appropriate way of doing this in protocol is to stop advertising support for RTT. That is: advertising support for RTT is roughly saying "I'm happy to receive RTT from you. I may or may not reply with RTT, but I'll receive yours" - once you're not willing to receive it you should stop advertising it. This is both subtly different from and similar to A/V. With A/V each conversation is explicitly negotiated, so it's easy for a user to say 'no' before any A/V data are exchanged, so it's different. Yet in exactly the same way as I'm arguing above, if the user never wants to see an A/V invite, the appropriate thing to do is to stop advertising support. /K
