Hi Vinod, I just wanted to mention that I ran into the same trouble. When I was working on my server implementation, I had compatibility problems because other servers went against RFC 3920 by including version='1.0' in s2s when they didn't actually support SASL.
The RFC definitely needs to be updated about this. I think this topic has come up often enough that it is not something to brush aside as an implementation note. For now, servers implementors seem to be taking matters into their own hands, and so not only do we have 1.0 without SASL, but we have TLS+dialback. These things are not in the RFC. -Justin On Friday 30 December 2005 02:42, Vinod Panicker wrote: > On 12/30/05, Matthias Wimmer <[EMAIL PROTECTED]> wrote: > > The point of version="1.0" is that you will get the <stream:features/> > > element. > > Yes, but RFC 3920 states - > > 3. When a receiving entity that complies with this specification > receives an initial stream header that includes the 'version' > attribute set to a value of at least "1.0", after sending a > stream header in reply (including the version flag), it MUST > include a <starttls/> element (qualified by the > 'urn:ietf:params:xml:ns:xmpp-tls' namespace) along with the list > of other stream features it supports. > > And since the RFC also states - > > 12. If the TLS negotiation is successful, the initiating entity MUST > continue with SASL negotiation. > > So I infer from the above that any entity that would specify its > version to be 1.0 would have support for TLS as well. And if TLS is > done successfully, SASL MUST be done as well. > > Thats why I said that any server that advertises version=1.0 MUST also > support TLS+SASL. Pls do correct me if I'm wrong. > > Regards, > Vinod.
