[Standards-JIG] rfc3920bis, RC4: Version Number Change?

Justin Karneges justin-keyword-jabber.093179 at affinix.com
Wed Oct 11 06:00:10 UTC 2006

On Tuesday 10 October 2006 22:24, Matthias Wimmer wrote:
> JD Conley schrieb:
> > A stream feature for it would be helpful for advertising support rather
> > than disco. It seems like a feature that a server might not support due
> > to configuration, such as StartTLS, SASL + DIGESTMD5, etc.
> I don't think that this is a stream feature. IMHO stream features should
> only advertize functionallity provided by the "stream layer" of the
> protocol. (For at least some of the server implementations, stream
> features are not accessable where there privacy list replacement has to
> be implemented.)
> As well that I don't think that a stream version number change whould be
> correct for this as we do not change the way XMPP / streams are working.
> It's just other payload we transport over XMPP - like when adding some
> other namespace.
> I feel that service discovery is still the right way to advertize this
> feature. I don't think service discovery has to be an XMPP feature
> itself for that. To find out if the privacy list replacement is
> available without using anything else than XMPP, you can just send a
> configuration query for it and see if you get back an error; if you
> choose to use more than basic XMPP, you will do service discovery.

+1 to all.  I'd written this mail, but Matthias beat me to it. :)

I'd like to add that if we do want some minimal feature support for XMPP-IM, 
then let it be inside XMPP-IM.  For example, the privacy feature could be 
noted in the IM sessions handshake.  Or we could put an XMPP-IM version in 
the IM sessions stream feature.  E.g.:

    <bind xmlns='urn:ietf:params:xml:ns:xmpp-bind'/>
    <session xmlns='urn:ietf:params:xml:ns:xmpp-session' version='1.1'/>


More information about the Standards mailing list