Any progress on gmail.com dialback issue?

[Alex Vandiver]

On Thu, 2009-03-26 at 17:31 -0700, Martin Atkins wrote:
> Having reviewed that discussion, it looks like DJabberd is in the wrong 
> here, but I'd like to see some clear reasoning for why djabberd is wrong 
> (based on what the spec says), what it should be doing instead, and what 
> is broken (if anything) by the change.

The RFC says ( http://xmpp.org/rfcs/rfc3920.html#rfc.section.4.6 ):

                If the initiating entity includes the 'version'
                attribute set to a value of at least "1.0" in the
                initial stream header, the receiving entity MUST send a
                <features/> child element (prefixed by the streams
                namespace prefix) to the initiating entity in order to
                announce any stream-level features that can be
                negotiated (or capabilities that otherwise need to be
                advertised)
                
In this case, djabberd is the _initiating_ entity, and as such, no
<features/> element is expected.  True, it never explicitly states that
servers initiating connections MUST NOT or SHOULD NOT send <features/>
elements, but it is heavily implied that the only context in which they
are expected is when the receiving server is declaring what features it
supports.  Since the iniator of the connection starts tls, etc, the
receiving entity doesn't particularly care what features it supports.

> As far as I can tell from the previous discussion, we aren't really sure 
> what implementation that hack was added for.

It was part of the initial commit which added s2s support.  As such, I
regard it as slightly suspect.
 - Alex