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

Mark Rejhon markybox at gmail.com
Tue Jul 10 20:35:52 UTC 2012


On Tue, Jul 10, 2012 at 3:28 PM, Gunnar Hellström <
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20120710/2eec4af9/attachment.html>


More information about the Standards mailing list