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

Gunnar Hellström gunnar.hellstrom at omnitor.se
Tue Jul 10 20:58:54 UTC 2012


___________________________________________________
On 2012-07-10 22:35, Mark Rejhon wrote:

> On Tue, Jul 10, 2012 at 3:28 PM, Gunnar Hellström 
> <gunnar.hellstrom at omnitor.se <mailto:gunnar.hellstrom at omnitor.se>> wrote:
>
>     On 2012-07-10 20:57, Mark Rejhon wrote:
>
>         The flexibility provided in XEP-0301 and the freedom of
>         implementations possible, while also simultaneously
>         maintaining maximum interoperability, encourages wider
>         adoption, and improves accessibility.   I strongly feel that
>         that the fallback mechanism is a good design from that
>         perspective.  (and has precedent in section 5.1 of XEP-0085)
>
>     I think we have tried to nail down the requirements in simple
>     logic terms a couple of times before. Evenso, I think it is time
>     to do it again:
>     1. It shall be possible for a client to be able to declare its
>     support for receiving <rtt/>
>
> Yes.  Section 5.
>
>     2. it shall be possible to interrogate another client's support
>     for receiving <rtt/>
>
> Yes.  Section 5 and 6.2.  (Subtle note: Design of protocol allows 
> recipients to ignore interrogation)
>
>     3. It shall be possible to respond positively or negatively about
>     the support for receiving <rtt/>
>
> Yes.  Section 4.2.2 protocol with init/cancel, with section 6.2 
> explaining implementor usage
>
>     4. it shall be possible to start sending <rtt/> without previous
>     negotiation and without really transmitting any visible text.
>
> Yes.   Last part of Section 5, using a single <rtt event='init'/>
>
>     5. it shall be possible to request a transmitting party to stop
>     sending <rtt/>
>
> Yes.   Section 4.2.2 with cancel.
>
>     6. when a request to stop transmitting <rtt/> is received out of a
>     multi-user chat room, the transmission of <rtt/> shall be stopped.
>
> No.  The MUC section discourages 'cancel' because one person shouldnt 
> stop the whole channel's RTT.
> Also, it is beyond the scope of XEP-0301 to design a session 
> negotiation methodology for MUC, and I don't plan to include it.
>
>     7. when receiving <rtt/> first time in a session, a client shall
>     indicate its acceptance of receiving <rtt/>
>
> Correctly reworded as:
> 7. when receiving <rtt/> first time in a session, it is possible for a 
> client to indicate its acceptance of receiving <rtt/>
> Yes.  (implementors have the flexibility to ignore or deny.)
> ____________________
>
>     1. Declaration of support for reception is made through disco
>
> Flawed (see previous big email messages), unless fallback mechanism is 
> permitted.
>
>     2. Interrogate of support for reception is made through disco
>
> Flawed (see previous big email messages), unless fallback mechanism is 
> permitted.
>
>     3. Response on interrogation is made by disco
>
> This is not appropriate use of disco.
>
>     4. Sending empty <rtt/> without negotiation is done with empty <rtt/>
>
> Only as fallback mechanism.  (Empty <rtt event='init'/> method 
> described in section 6.2)
>
>     5. request to stop sending <rtt/> is made through event='cancel'
>
> Yes.
>
>     6. when receiving event='cancel'   <rtt/> transmission shall cease
>     until there is a strong reason to send again
>
> Yes.  Client would be permitted to send a single <rtt event='init'/>. 
>   (example: activated on button activation, menu, preference, 
> settings, or other user-initiated mechanism)
>
>     7. When receiving <rtt/> first time in a session, or after a
>     silence caused by 'cancel', <rtt/> shall be sent in response, with
>     or without text.
>
> Correctly reworded as:
> 7. When receiving <rtt/> first time in a session, (or when <rtt 
> event='init'/> is received after an <rtt event='cancel'/>), it is 
> possible to respond by sending <rtt/>, and with or without text.
> Yes.
>
> The reason I reworded your sentence is because of Section 6.2 .... 
> There is no "silence caused by a cancel".  You have to restart the 
> chat session (if you've designed to always send RTT), or you have to 
> re-initiate (if you've designed to have user-activated initiation 
> features).   There's a lot of flexibility in the spec to allow many 
> activation behaviors.
>
>     8. Transmission of <rtt/> SHOULD not be done if response no 4 is
>     negative, but MAY be done if no response is received on disco.
>
> Correct, and only as fallback mechanism (similiar to allowed by 
> section 5.1 of XEP-0085 Chat States)
>
>
> Thanks
> Mark Rejhon

For 6 I had bad wording,
I meant
6. when a request to stop transmitting <rtt/> is received (outside of 
any multi-user chat room), the transmission of <rtt/> shall be stopped.
So there we agree.

Why do you say that protocol items 1,2 and 3 are flawed?

Gunnar
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20120710/2ee81c79/attachment.html>


More information about the Standards mailing list