[jdev] S2S questions - from attribute and version support

[Justin Karneges]

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 <m at tthias.net> 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.