[Standards-JIG] Re: stream:error for dialback with no SASL support

JD Conley jconley at winfessor.com
Fri Jul 30 20:24:11 UTC 2004


> -----Original Message-----
> From: Peter Saint-Andre [mailto:stpeter at jabber.org]
> Sent: Friday, July 30, 2004 10:31 AM
> To: standards-jig at jabber.org
> Subject: [Standards-JIG] Re: stream:error for dialback with no SASL
> support
> 


> I would say STARTTLS first, then dialback. Essentially, SASL replaces
> dialback for s2s authentication (while dialback is not really an
> authentication mechanism, it was pretty much used as such in the older
> Jabber protocols). So to me it makes sense to do TLS then dialback
just
> as we do TLS then SASL (which is the ordering of layers defined in
XMPP
> Core). I will add something about this to the implementation guide.


Agreed.


> This seems fine. I disagree with JD's comment that you won't receive
the
> xmlns:db declaration -- you probably will at least receive it on the
> very first stream from another domain because for the sake of
backwards
> compatibility all implementations will do both SASL and dialback for
> quite some time, I think.

The reason I said that was because that's the way our implementation
currently works.  IIRC, if a version="1.0" was supplied j2 would assume
the connection was c2s XMMPP and not s2s dialback.  This may have been
fixed since we implemented this feature (many months ago).  I think
there was similar behavior with other XMPP servers.

With the xmlns:db declaration on the initial stream open as well as the
version="1.0" the receiver should respond with stream:features and a
version="1.0" if it supports starttls and/or SASL.  If xmlns:db is
included in the reply the initiator will assume the connection is
dialback.  Otherwise the initiator will assume the connection will be
authenticated through SASL.

Does that sound about right?  This is much friendlier than how we do
things in our current implementation.

JD




More information about the Standards mailing list