<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
    <title></title>
  </head>
  <body text="#000000" bgcolor="#ffffff">
    Mark, <br>
    I get the impression that it is better to make an assumption on how
    versioning can be handled, and have it included in next proposed
    version of the draft so that it can be viewed in its environment.
    Discussions can be taken from there.<br>
    <br>
    An example to follow might be XEP-0166 Jingle, saying this about
    version handling.<br>
    <br>
    <div class="indent">
      <h3>"15.2 <a id="registrar-versioning"
          name="registrar-versioning">Namespace Versioning</a></h3>
      <p>If the protocol defined in this specification undergoes a
        revision that is not fully backwards-compatible with an older
        version, the XMPP Registrar shall increment the protocol version
        number found at the end of the XML namespaces defined herein, as
        described in Section 4 of <span class="ref">XEP-0053</span>.<br>
        "<br>
      </p>
    </div>
    This ends up having numbered suffix. <br>
    <br>
    As usual, it is good to have a version control system, but you tend
    to try to avoid ticking the version, and instead do changes in the
    form of complete additions as long as possible.<br>
    <br>
    Gunnar<br>
    <pre class="moz-signature" cols="72">___________________________________________________
Gunnar Hellström
Omnitor
<a class="moz-txt-link-abbreviated" href="mailto:gunnar.hellstrom@omnitor.se">gunnar.hellstrom@omnitor.se</a>
+46708204288</pre>
    <br>
    Mark Rejhon skrev 2011-05-12 09:22:
    <blockquote
      cite="mid:BANLkTimEV_GHXJbv8Mq2hBR0wdN_r_gTsQ@mail.gmail.com"
      type="cite">Hello,
      <div><br>
      </div>
      <div>First, I'm on a good track to resubmit a simpified RTT
        standard:</div>
      <div>I have successfully shrunk the core Real Time Text standard
        by 50% in the core document, and simultaneously simplifying the
        protocol (while using roughly the same general concept).  I also
        implemented the new standard in C# and Java implementations.
         This gave me some more experience on the various different
        platform behaviours and how to simplify the programming.  </div>
      <div><br>
      </div>
      <div>My current concern:</div>
      <div>I've seen someone suggest "urn:xmpp:rtt:0" while another said
        "urn:xmpp:rtt".  My spec requires a namespace itself; however,
        at the same time some observed the need for versioning because
        of the nature of high quality Real Time Text Chat conversations
        using its own custom step-by-step XML 'micro language' (example
        -- insert text, delete text, move cursor, execute an
        inter-keypress delay --- basically a series of sequential
        steps).   I now have concern that versioning might be a major
        concern.</div>
      <div><br>
      </div>
      <div>-- Using numbered sufix "urn:xmpp:rtt:0"</div>
      <div>ADVANTAGE: Versioning by incrementing the final number;</div>
      <div>DISADVANTAGE: Many parser libraries make it difficult to
        provide forward/backward compatibility because they look for an
        exact xmlns value. (Example: Smack Java library).  I.e. an
        application would only work with a specific exact 'xmlns'</div>
      <div><br>
      </div>
      <div>-- Permanently sticking to "urn:xmpp:rtt"</div>
      <div>
        <div>ADVANTAGE: Easier forward/backwards compatibility if very
          careful during revisions to the standard; since the standard
          is designed to still work if I ignore unsupported codes, and
          the unsupported codes do not do critical actions, for regular
          traditional messaging.</div>
        <div>DISADVANTAGE: Can't detect version of RTT from the remote
          end.  </div>
        <div><br>
        </div>
        <div>There's a desire among my group of peers to detect the
          remote client's version of RTT.  If I do not use the final
          number of namespace for this technique, I'd potentially have
          to add a separate 'iq' query, or similiar, to provide this
          purpose, further complicating the protocol.  In addition,
          there are vendors regarding niche software (i.e. court
          reporting, LAN chat systems, etc) which may need to
          interoperate with industry-standard XMPP RTT.  I have to walk
          all fine lines.</div>
      </div>
      <div><br>
      </div>
      <div>I'd like some guidance from some XMPP veterans on some form
        of appropriate version-detection guidelines for an XMPP standard
        (namespace and otherwise); since this is one of the parts of the
        spec that has been most difficult to decide upon.</div>
      <div><br>
      </div>
      <div>Thanks!<br>
        Mark Rejhon</div>
    </blockquote>
  </body>
</html>