On Tue, Jul 10, 2012 at 3:28 PM, Gunnar Hellström < [email protected]> 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
