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
Omnitor
[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
