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

Gunnar Hellström gunnar.hellstrom at omnitor.se
Tue Jul 10 19:28:25 UTC 2012


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

2. it shall be possible to interrogate another client's support for 
receiving <rtt/>

3. It shall be possible to respond positively or negatively about the 
support for receiving <rtt/>

4. it shall be possible to start sending <rtt/> without previous 
negotiation and without really transmitting any visible text.

5. it shall be possible to request a transmitting party to stop sending 
<rtt/>

6. when a request to stop transmitting <rtt/> is received out of a 
multi-user chat room, the transmission of <rtt/> shall be stopped.

7. when receiving <rtt/> first time in a session, a client shall 
indicate its acceptance of receiving <rtt/>


Protocol elements and protocol

1. Declaration of support for reception is made through disco

2. Interrogate of support for reception is made through disco

3. Response on interrogation is made by disco

4. Sending empty <rtt/> without negotiation is done with empty <rtt/>

5. request to stop sending <rtt/> is made through event='cancel'

6. when receiving event='cancel'   <rtt/> transmission shall cease until 
there is a strong reason to send again

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.

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.


There are some elements of odd logic here, but maybe that can be 
discovered and explained that it is for the odd cases when disco support 
was not desirable.

Can this be  a possible structure to complete?

Gunnnar




More information about the Standards mailing list