Any progress on gmail.com dialback issue?
alexmv at bestpractical.com
Fri Mar 27 03:49:59 UTC 2009
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
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.
More information about the Djabberd