Mark, this appears to be a bit of a muddle. Comments inline. On 7/10/12 10:43 AM, Mark Rejhon wrote: > I'm going to simplify Section 5 simply by making a link to > Activation/Deactivation methods. > Please don't be alarmed, let's work together on Version 0.4, 0.5 and 0.6 > until everyone agrees :-) > > > On Mon, Jul 9, 2012 at 7:00 PM, Peter Saint-Andre <[email protected] > <mailto:[email protected]>> wrote: > > 1. What does it mean to "signal intent"? XEP-0030 provides a way to > signal support. By "signal intent" do you mean interest in exchanging > RTT data with a particular conversation partner, or for a particular > chat session or MUC room, or something else? > > > Signalling intent is chat session based: > 1. Client clicks a button
The user might click a button, but I don't think the client would. ;-) In any case, we're protocol designers, not UI designers. Some clients might expose this feature as a button, others as a configuration option in some wizard, etc. > 2. Client signals using <rtt event='start'/> That's what we're trying to figure out. :) > 3. Recipient can respond with one of the activation methods at: > http://xmpp.org/extensions/xep-0301.html#activating_and_deactivating_realtime_text > > Note: This might mean the recipient software prompts for confirmation > *before* activating RTT (i.e. before disco is turned on!). Clients don't turn on service discovery -- it's a core part of the client, and I have never seen it exposed as a user option to enable or disable it. > Privacy of > signalling RTT support is maintained until recipient confirms. Well, the initiating client sent something, so I don't see how it is private. > We want senders to be able to signal recipients, even when disco is off, Why??? Clients don't turn off disco! > because: > --> For privacy reasons, some vendors want to keep the existence of > real-time text support a secret until Activation occurs. (Vendors > should have the choice if they want to do this) Vendors have the choice to shoot themselves in the foot, too. Why are we designing the *protocol* around the mental limitations of these myopic vendors??? > --> But we can't wait until both users on both ends manually activate > real-time text simultaneously. > --> We need a simple method of sender signalling the recipient, so both > of them can synchronize activation simultaneously. I'm all for simplicity, but I wonder what exactly it means to you in this context. > The problem is that activation synchronization *and* privacy (of > existence of RTT) is not possible with disco alone, because disco > implies that senders should never transmit <rtt/> if disco denies the > existence of real-time text support. Disco does not *necessarily* imply any such thing. XEP-0030 just says "if you support the feature, here is how to advertise it". XEP-0301 can say "if you support the feature then you MUST include <feature var='urn:xmpp:rtt:0'/> in your service discovery response. XEP-0301 could also say "a client MUST NOT send any RTT data if the conversation partner does not advertise support for the RTT protocol using service discovery", but it does not *need* to say that. This is why we're having the conversation here. > Metaphorically speaking: > i.e. in a manner of speaking, we strongly believe senders should be > allowed to "dial the phone". > Even if we don't know if the phone number is good or not. i.e. senders > should be able to be allowed to try to dial. Sure, this is essentially the chat state notifications fallback for determining when to generate notifications, applied to the example of RTT data: http://xmpp.org/extensions/xep-0085.html#bizrules-gen > 2. What does it mean to "want to be informed"? Do you mean "want to > receive RTT data"? If so, again do you mean with a conversation partner > or for a session/room or something else? > > > When I say "want to be informed", means: > "I want to be informed of all incoming real-time text attempts without > revealing that my software supports real-time text". Why is it a requirement to not reveal RTT support? I really don't understand this. > Example: > **** Incoming Real-Time Text detected, but you have it turned off. > _Click to learn more_* > > Yes, yes, I know it's an implementation issue. > But I'm merely just trying to make it "possible" > But all I tried was to add a single sentence to Section 5, which is > causing all of these arguments! > > Help! (hint, hint) One solution is to remove this silly requirement to not advertise RTT support. We don't jump through these kinds of hoops in other protocols (say, Jingle). Yes, anyone can send anything they want -- I could try to initiate a Jingle audio session with you even if you don't support JIngle. If you want your client to pop up some text in this case, even if it doesn't support Jingle, then write your client that way. It's not part of the protocol to make that happen. At the protocol level, if we want to provide some kind of fallback method, as we did in XEP-0085 for chat state notifications, then let's have that conversation. But designing around silly non-requirements is just wasting our time. :) Peter -- Peter Saint-Andre https://stpeter.im/
