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

Mark Rejhon markybox at gmail.com
Mon Jul 9 19:58:29 UTC 2012

Regarding section 5 of XEP-0301:

On Mon, Jul 9, 2012 at 2:52 PM, Matthew Wild <mwild1 at gmail.com> wrote:

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

Matt brings up some good concerns to some passionate arguments, so there
should be some good agreement at least.
Prudent caution is warranted, for sure.  Many good standards in history are
filled with fueled debates, and the strongest standards often have some of
the strongest nay-sayers -- witness the browser wars, for example! :-)

Now, accessibility standards does influence implementers to an extent.
It bears worth noting that most of the information (such as
Activation/Deactivation) is in Implementation Notes.

Yes, having XEP-0301 move to draft status would be a good move now to be
able to reference it.

We have a *European standard* on the way for accessible public procurement,
similar to the american. We are just forming the version of it that will go
for member voting in August. We have made a structure for real-time text
requirements where XEP-0301 would fit in and be referenced, but we cannot
do it now when XEP-0301 is just experimental. We will see if there will be
a chance to get it in.

For the *American*, the web [U.S. Access Board -
www.access-board.gov] about the Section 255 - 508 refresh says about the
procedure, with a comment period that ended in March this year: "The Board
will follow-up with a proposed rule based on the input received that will
provide an additional round of comment before the rule is finalized."  That
has not happened yet, so there is likely time to make an effort to  be
mentioned in that regulation.

The cycle seems to be about 10- 15 years.


Matt, would you like to suggest some alternative mechanism to replace
Section 5?
I would welcome your comments.   At least a few (myself included) no longer
desire disco as the only method.
Re-surrecting XEP-0020 feature negotiation might be an option, and would be
a possible suitable alternative, but it is not presently appealing due to
increased complexity.   Certain other parts of the standard is getting
pretty well-designed -- there's been many compliments -- but we will
concede that Section 5 is controversial!

There are many usage scenarios that needs to be accomodated, such as
interop between an accessible client and a mainstream client, between
accessible clients, and between mainstream clients.  Some mainstream
clients may not advertise XEP-0301 capability until activated.    The model
of sender initiatability / recipient notifyability needs to be a permitted
methodology, and I am pretty sure that someone else has a better method of
meeting that model.   It might even be that Section 5 might be in flux for
longer than expected, or it might eventually be agreed to remove Section 5
altogether (eliminate disco), falling back into <rtt/> itself.

Ideas are welcome, for the Section 5 solution.

Mark Rejhon
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20120709/b97ba843/attachment.html>

More information about the Standards mailing list