[Standards] Fwd: XEP-0301 Accessibility (resurrected)

Peter Saint-Andre stpeter at stpeter.im
Tue Jul 10 17:17:11 UTC 2012

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 <stpeter at stpeter.im
> <mailto:stpeter at stpeter.im>> 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

> 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

> --> 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:


>     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

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 Saint-Andre

More information about the Standards mailing list