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

Peter Saint-Andre stpeter at stpeter.im
Mon Jul 9 23:00:58 UTC 2012

On 7/9/12 12:52 PM, Matthew Wild wrote:
> On 9 July 2012 17:45, Mark Rejhon <markybox at gmail.com> wrote:
>> Gunnar, do you have any suggestions of alternatives that still meets the
>> 1-2-3 accessibility requirements?
>> 1. It should be possible for senders to signal intent.  (even if some
>> recipients may ignore)
>> 2. It should be possible for recipients that want to be informed, to
>> continue to be informed -- even if they turn off RTT, and they don't want to
>> advertise RTT capability.
>> 3. It should be possible for recipients to completely ignore or reject (as
>> if not supported), and not even advertise at all. (A few people have been
>> adamant about being able to do this)
>> I also want to eliminate any accessibility blame from accessible
>> implementations.
>> Unfortunately, disco does not meet the 1-2-3 criteria above, all of which
>> have been asked by implementors.
>> So if the blank <rtt/> is not suitable, I am open to other ideas.  Please
>> feel free to suggest...
> I'm afraid all this is mixing up protocol with implementation and UI,
> which is rarely a good thing. I understand your concerns, but your
> proposals do not address them and additionally make for a rather poor
> protocol.
> The reality is that at the end of the day client implementations are
> beyond the control of you and I as protocol developers. If a client
> wants to have a global "Disable RTT" option then they will implement
> it, regardless of what you try to do to prevent it in this document. A
> client can just as easily ignore empty <rtt/> as it can remove a
> feature from disco.
> So that understood, we have to continue designing the protocol, not
> trying to anticipate clients. If a client says it does not support a
> feature then it is bad practice for another client to send that
> feature anyway.
> As long as there is a mechanism provided in the protocol for making
> more granular (e.g. per-conversation) decisions about RTT then there
> should be no question of needing to use service discovery for anything
> but "I don't support this feature" and "I REALLY don't want to use
> this feature AT ALL" - both cases where trying to use RTT anyway will
> get you nowhere.

What Matthew says makes a lot of sense.

Mark, your "1-2-3 accessibility requirements" are not clear to me.

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?

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?

3. It's always possible for a client to ignore anything it wants, so I
don't see what #3 is all about.



Peter Saint-Andre

More information about the Standards mailing list