Dear Matthew, Thank you for your reply. As you pointed out, the initial stream header stanza from google talk server didn't include a 'version' attribute.
And I found this in RFC6120: >4. If either entity receives a stream header with no 'version' > attribute, the entity MUST consider the version supported by the > other entity to be "0.9" and SHOULD NOT include a 'version' > attribute in the response stream header. I'll fix my implementation. And then, by switching the server's behavior after confirming exist of a version attribute (or is whether 0.9 or 1.0), my server will be able to support both google talk server and jabber.org server. However, how can I support the other server which will send initial stream header without the 'version' attribute (or with the version='0.9') and require the features stanza. I didn't see such server for now but I think it meets the requirements of current RFC and XEP so there is a possibility of such server would appear in the future. According to the XEP-220, > Although this method of advertising protocol support has been superseded by > the use of stream features as originally defined in RFC 3920, the server > dialback > protocol predates the existence of stream features and therefore the namespace > declaration method is still used in this instance. Is this imply " if 'version=0.9' then MUST NOT send features stanza, if 'version=1.0' or higher then MUST send features stanza" ? If such rules or restriction is not yet clearly described in any RFCs or XEPs, I think it should be clearly described in RFC or XEP for future developers. By restricting to develop a new server which says version=0.9 and require features stanza, I think we can avoid a inconsistency problem in the future. Anyway, my implementation will employ the method which switch a behavior by checking exist of version attribute. Regards, Nobuo Ogashiwa <[email protected]> JID: [email protected], [email protected] Web: http://nlab.jp/xmpp/ 2012/1/6 Matthew Wild <[email protected]>: > Hi, > > On 5 January 2012 14:42, Nobuo Ogashiwa <[email protected]> wrote: >> 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. >> > > Perhaps Google's stream did not have version='1.0' in the header? If > not, I don't think you should send <stream:features>. > > I would also make sure you have xmlns:db correctly set in your stream header. > >> If someone knows the right solution, standard sequence, or pointer to >> standards of this, >> please let me know. >> > > Double-check the things I suggested above. Existing server > implementations do not have any problems, so you're definitely missing > something. > >> 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; } >> > > Ick. > >> (2) wait <db:verify> stanza to receive for 5 seconds, if nothing >> received, then send <stream:features> stanza >> > > Ick. > >> Both of these workarounds works well for now. >> > > If you say so :) > > Regards, > Matthew > _______________________________________________ > JDev mailing list > Info: http://mail.jabber.org/mailman/listinfo/jdev > Unsubscribe: [email protected] > _______________________________________________ _______________________________________________ JDev mailing list Info: http://mail.jabber.org/mailman/listinfo/jdev Unsubscribe: [email protected] _______________________________________________
