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

Mark Rejhon markybox at gmail.com
Sat May 14 22:15:04 UTC 2011

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 <gunnar.hellstrom at omnitor.se>

>  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
> Omnitorgunnar.hellstrom at omnitor.se+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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20110514/a8a5e545/attachment.html>

More information about the Standards mailing list