[Standards] Questions pertaining to upcoming resubmission of Real Time Text standard (0.0.2)

Mark Rejhon markybox at gmail.com
Thu May 12 07:22:01 UTC 2011


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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20110512/5e94020e/attachment.html>


More information about the Standards mailing list