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
