> > 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. >
Ok -- good point, I see your point that this is how disco is ment to be used -- I just inserted the following text to XEP-0301 at the bottom of Section 5: "While NOT RECOMMENDED, if there is no affirmative discovery response, sending a single blank <rtt/> element upon start of a chat session, is an alternative method of indicating that real-time text is permitted until end of chat session. Senders SHOULD NOT send any further <rtt/> until incoming <rtt/> is received during the same chat session, or when support is confirmed via discovery." This satisfies the general needs, while this leaves the door open for the ability for vendors to choose to write software that notifies users that incoming RTT attempts that are denied. This is a required capability for at least a couple of clients. Mark Rejhon
