[Standards] Questions pertaining to upcoming resubmission of Real Time Text standard (0.0.2)
gunnar.hellstrom at omnitor.se
Sat May 14 18:34:33 UTC 2011
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
"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.hellstrom at omnitor.se
Mark Rejhon skrev 2011-05-12 09:22:
> 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.
> Mark Rejhon
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Standards