Looks good. On Jun 30, 2012, at 4:42 PM, Mark Rejhon wrote: > 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
smime.p7s
Description: S/MIME cryptographic signature
