I cannot believe I missed this. Now this is a precedent I can use, I will reuse that wording in Experimential/Draft periods.
2011/5/14 Gunnar Hellström <[email protected]> > Mark, > 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. > > An example to follow might be XEP-0166 Jingle, saying this about version > handling. > > "15.2 Namespace Versioning > > 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 XEP-0053. > " > This ends up having numbered suffix. > > 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. > > Gunnar > > ___________________________________________________ > Gunnar Hellström > [email protected]+46708204288 > > > Mark Rejhon skrev 2011-05-12 09:22: > > Hello, > > First, I'm on a good track to resubmit a simpified RTT standard: > 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. > > My current concern: > 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. > > -- Using numbered sufix "urn:xmpp:rtt:0" > ADVANTAGE: Versioning by incrementing the final number; > 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' > > -- Permanently sticking to "urn:xmpp:rtt" > 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. > DISADVANTAGE: Can't detect version of RTT from the remote end. > > 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. > > 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. > > Thanks! > Mark Rejhon > >
