[jdev] features stanza on a s2s dialback connection
Nobuo Ogashiwa
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 <ogas...@c.kyoai.ac.jp>
JID: ogas...@c.kyoai.ac.jp
Web: http://nlab.jp/xmpp/
_______________________________________________
JDev mailing list
Info: http://mail.jabber.org/mailman/listinfo/jdev
Unsubscribe: JDev-uns...@jabber.org
_______________________________________________
Matthew Wild
On 5 January 2012 14:42, Nobuo Ogashiwa <ogas...@c.kyoai.ac.jp> 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
Nobuo Ogashiwa
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 <ogas...@c.kyoai.ac.jp>
JID: ogas...@c.kyoai.ac.jp, ogas...@nlab.im
Web: http://nlab.jp/xmpp/
2012/1/6 Matthew Wild <mwi...@gmail.com>:
Matthew Wild
> Dear Matthew,
>
> 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.
>
It doesn't meet the requirements. There are two versions of the
protocol, the "old" one (0.9) and the new one (1.0). 1.0 was the first
official XMPP standard.
Before 1.0, there were no stream:features. A server that does not
support version='1.0' and requires <stream:features> would just be
silly.
> 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" ?
No, XEP-0220 is not talking about sending <stream:features>, it is
talking about advertising dialback support *inside* <stream:features>.
Obviously you would only send <stream:features> on a 1.0 stream, but
XEP-0220 is just telling you that you should also support the old
method of advertising dialback support (xmlns:db) too.
> 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.
Your worry is a server that uses a protocol version <1.0, but also
requires <stream:features> (a >=1.0 feature). Even if such a server
exists, why should it suddenly be updated just because a new RFC/XEP
is published? If it isn't updated to 1.0, I don't see why it would be
updated to anything else.
If you ever do find such a server, first file a bug report against it,
and second... let me know :)