<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <div class="moz-cite-prefix"><br>
      <pre class="moz-signature" cols="72">___________________________________________________
On 2012-07-10 22:35, Mark Rejhon wrote:
</pre>
    </div>
    <blockquote
cite="mid:CAA79oDnOwxJPVVkG6MDRVVUqav78n6o3iXqstvfPFJ22rhtEHg@mail.gmail.com"
      type="cite">
      <div class="gmail_quote">On Tue, Jul 10, 2012 at 3:28 PM, Gunnar
        Hellström <span dir="ltr"><<a moz-do-not-send="true"
            href="mailto:gunnar.hellstrom@omnitor.se" target="_blank">gunnar.hellstrom@omnitor.se</a>></span>
        wrote:<br>
        <blockquote class="gmail_quote" style="margin:0 0 0
          .8ex;border-left:1px #ccc solid;padding-left:1ex">
          On 2012-07-10 20:57, Mark Rejhon wrote:<br>
          <blockquote class="gmail_quote" style="margin:0 0 0
            .8ex;border-left:1px #ccc solid;padding-left:1ex">
            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)<br>
          </blockquote>
        </blockquote>
        <div> </div>
        <blockquote class="gmail_quote" style="margin:0 0 0
          .8ex;border-left:1px #ccc solid;padding-left:1ex">
          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:<br>
          1. It shall be possible for a client to be able to declare its
          support for receiving <rtt/><br>
        </blockquote>
        <div>Yes.  Section 5.</div>
        <div> </div>
        <blockquote class="gmail_quote" style="margin:0 0 0
          .8ex;border-left:1px #ccc solid;padding-left:1ex">2. it shall
          be possible to interrogate another client's support for
          receiving <rtt/><br>
        </blockquote>
        <div>Yes.  Section 5 and 6.2.  (Subtle note: Design of protocol
          allows recipients to ignore interrogation)</div>
        <div> </div>
        <blockquote class="gmail_quote" style="margin:0 0 0
          .8ex;border-left:1px #ccc solid;padding-left:1ex">
          3. It shall be possible to respond positively or negatively
          about the support for receiving <rtt/><br>
        </blockquote>
        <div>Yes.  Section 4.2.2 protocol with init/cancel, with section
          6.2 explaining implementor usage</div>
        <div> </div>
        <blockquote class="gmail_quote" style="margin:0 0 0
          .8ex;border-left:1px #ccc solid;padding-left:1ex">4. it shall
          be possible to start sending <rtt/> without previous
          negotiation and without really transmitting any visible text.<br>
        </blockquote>
        <div>Yes.   Last part of Section 5, using a single <rtt
          event='init'/></div>
        <div> </div>
        <blockquote class="gmail_quote" style="margin:0 0 0
          .8ex;border-left:1px #ccc solid;padding-left:1ex">5. it shall
          be possible to request a transmitting party to stop sending
          <rtt/><br>
        </blockquote>
        <div>Yes.   Section 4.2.2 with cancel.</div>
        <div> </div>
        <blockquote class="gmail_quote" style="margin:0 0 0
          .8ex;border-left:1px #ccc solid;padding-left:1ex">6. when a
          request to stop transmitting <rtt/> is received out of a
          multi-user chat room, the transmission of <rtt/> shall
          be stopped.<br>
        </blockquote>
        <div>No.  The MUC section discourages 'cancel' because one
          person shouldnt stop the whole channel's RTT.  </div>
        <div>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.</div>
        <div><br>
        </div>
        <div> </div>
        <blockquote class="gmail_quote" style="margin:0 0 0
          .8ex;border-left:1px #ccc solid;padding-left:1ex">7. when
          receiving <rtt/> first time in a session, a client shall
          indicate its acceptance of receiving <rtt/><br>
        </blockquote>
        <div>Correctly reworded as:</div>
        <div>7. when receiving <rtt/> first time in a session, it
          is possible for a client to indicate its acceptance of
          receiving <rtt/>
        </div>
        <div>Yes.  (implementors have the flexibility to ignore or
          deny.)</div>
        <div>____________________</div>
        <div><br>
        </div>
        <blockquote class="gmail_quote" style="margin:0 0 0
          .8ex;border-left:1px #ccc solid;padding-left:1ex">
          1. Declaration of support for reception is made through disco<br>
        </blockquote>
        <div>Flawed (see previous big email messages), unless fallback
          mechanism is permitted.</div>
        <div><br>
        </div>
        <blockquote class="gmail_quote" style="margin:0 0 0
          .8ex;border-left:1px #ccc solid;padding-left:1ex">
          2. Interrogate of support for reception is made through disco<br>
        </blockquote>
        <div>Flawed (see previous big email messages), unless fallback
          mechanism is permitted.</div>
        <div> </div>
        <blockquote class="gmail_quote" style="margin:0 0 0
          .8ex;border-left:1px #ccc solid;padding-left:1ex">
          3. Response on interrogation is made by disco<br>
        </blockquote>
        <div>This is not appropriate use of disco.</div>
        <div> </div>
        <blockquote class="gmail_quote" style="margin:0 0 0
          .8ex;border-left:1px #ccc solid;padding-left:1ex">
          4. Sending empty <rtt/> without negotiation is done with
          empty <rtt/><br>
        </blockquote>
        <div>Only as fallback mechanism.  (Empty <rtt
          event='init'/> method described in section 6.2)</div>
        <div> </div>
        <blockquote class="gmail_quote" style="margin:0 0 0
          .8ex;border-left:1px #ccc solid;padding-left:1ex">
          5. request to stop sending <rtt/> is made through
          event='cancel'<br>
        </blockquote>
        <div>Yes.</div>
        <div> </div>
        <blockquote class="gmail_quote" style="margin:0 0 0
          .8ex;border-left:1px #ccc solid;padding-left:1ex">
          6. when receiving event='cancel'   <rtt/> transmission
          shall cease until there is a strong reason to send again<br>
        </blockquote>
        <div>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)</div>
        <div> </div>
        <blockquote class="gmail_quote" style="margin:0 0 0
          .8ex;border-left:1px #ccc solid;padding-left:1ex">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.<br>
        </blockquote>
        <div>Correctly reworded as:</div>
        <div>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. </div>
        <div>Yes.  </div>
        <div><br>
        </div>
        <div>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.</div>
        <div><br>
        </div>
        <div> </div>
        <blockquote class="gmail_quote" style="margin:0 0 0
          .8ex;border-left:1px #ccc solid;padding-left:1ex">
          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.<br>
        </blockquote>
        <div>Correct, and only as fallback mechanism (similiar to
          allowed by section 5.1 of XEP-0085 Chat States)</div>
        <div><br>
        </div>
        <div><br>
        </div>
        <div>Thanks</div>
        <div>Mark Rejhon</div>
      </div>
    </blockquote>
    <br>
    For 6 I had bad wording,<br>
    I meant<br>
    6. when a request to stop transmitting <rtt/> is received
    (outside of any multi-user chat room), the transmission of
    <rtt/> shall be stopped.<br>
    So there we agree.<br>
    <br>
    Why do you say that protocol items 1,2 and 3 are flawed?<br>
    <br>
    Gunnar<br>
  </body>
</html>