[jdev] features stanza on a s2s dialback connection

[Nobuo Ogashiwa]

Dear all,

Now I'm developing a XMPP server software which supports s2s connection,
and now I faced a problem of features stanza on a s2s dialback connection.
If someone knows a right solution, please let me know. The problem is following:

In a case of s2s dialback connection from google talk server,
If it send a <stream:features> stanza to the google talk server,
then the google talk server replies a 'not yet authorized' error.
If it don't send <stream:features> stanza,
the google talk server replies a <db:verify> stanza and it can
continue a dial back sequence.

However, in a case of jabber.org,
if it don't send a <stream:features> stanza, jabber.org server replies nothing
and it can't continue dial back authentication sequence.
If it send a <stream:features> stanza to jabber.org server, jabber.org
server replies a <db:verify> stanza.

Collectively,
if it dose not send <stream:features> stanza, google => OK, jabber.org => NG
if it send <stream:features> stanza,  google => NG,  jabber.org => OK.

How should our implementation support these incompatible behaviors?

I have read RFCs, XEPs and jdev mailing list archive carefully, but I
couldn't find
the right sequence of sending <stream:features> stanza on a dial back
connection.
If someone knows the right solution, standard sequence, or pointer to
standards of this,
please let me know.


Anyway, we have temporarily implemented a following two workarounds :

(1) 50% send features stanza, 50% don't send a features stanza,
 it is just like following code:
 if (rand()%2==0) { send_features_stanza(); return; }
 else { return; }

(2) wait <db:verify> stanza to receive for 5 seconds, if nothing
received, then send <stream:features> stanza

Both of these workarounds works well for now.

Regards,

Nobuo Ogashiwa <ogashiwa at c.kyoai.ac.jp>
JID: ogashiwa at c.kyoai.ac.jp
Web: http://nlab.jp/xmpp/