[jdev] features stanza on a s2s dialback connection

[Nobuo Ogashiwa]

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 <ogashiwa at c.kyoai.ac.jp>
JID: ogashiwa at c.kyoai.ac.jp, ogashiwa at nlab.im
Web: http://nlab.jp/xmpp/



2012/1/6 Matthew Wild <mwild1 at gmail.com>:
> Hi,
>
> On 5 January 2012 14:42, Nobuo Ogashiwa <ogashiwa at 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
> _______________________________________________
> JDev mailing list
> Info: http://mail.jabber.org/mailman/listinfo/jdev
> Unsubscribe: JDev-unsubscribe at jabber.org
> _______________________________________________