[Standards] XEP-0220 unclear?

Weasel weasel at tlen.pl
Tue Apr 20 12:36:24 UTC 2010


On 2010-04-20, at 14:08, Philipp Hancke wrote:

> Weasel schrieb:
>> On 2010-04-20, at 08:36, Philipp Hancke wrote:
>>> Hi Luke,
>>>> I've ran on some hickup during server dialback implementation. Mr. Saint-Andre recommended me to post a message here. Here's this exact problem (only 4 years ago) with stanzas to follow:
>>>> http://mail.jabber.org/pipermail/jdev/2006-July/083520.html
>>>> I'd be grateful for any pointers.
>>> That is described in section 2.1.2:
>>> "To do so, either it can reuse an existing XML stream or it needs to
>>> establish a new connection."
>>> or in step 5 in RFC 3920, section 8.3:
>>> "(Note: As an optimization, an implementation MAY reuse an existing
>>> connection here.)"
>> I dont think that's even slightly clear that "reuse EXISTING connection" means "quickly establish new one and pretend like nothing happened"
> 
> This definition of "existing" is creative, indeed ;-)
> 
> But there is the race condition that the other server wants to send you a stanza and therefore establishes its own connection just when you send your dialback request. This will result in the flow below, too.
> Therefore, your implementation must be able to deal with this.
Understood. It makes sense now. I just wish they didn't use this "race condition" as normal behaviour.
> 
>>> The order of dialback steps described by Ben is:
>>> ME-GT  --> step 1
>>> GT-ME  --> step 1
>>> ME2-GT --> step 2
>>> ME2-GT <-- step 3
>>> GT-ME  --> step 4
>>> GT-ME  <-- step 2
> should be --> actually.
> 
>>> (connection identifier, stanza direction, dialback step)
>>> 
>>> GT is a little impolite by initiating it's own dialback before sending
>>> the verification key. While that is a valid optimization, it makes
>>> dialback flows very hard to read.
>>> XEP 220 recommends (see 2.1.1) that the originating server does not initiate dialback unless it has queued any stanzas for the peer.
>>> 
>>> hope that helps
>>> 
>>> philipp
>> Also ejabberd implementation does exactly the same thing. While I dont mean to be negative, dont you think it's a little "over-optimized"?
> 
> File a bug and ask them to be "polite". However, they are not doing anything wrong and you should consider that behaviour a test of your implementation instead - there is no order imposed for result and verify.
> 
> The 220 recommendation is there so that when I send a <iq/> to your server, the flow will be as follows:
> ME-YOU --> step 1
> YOU-ME --> step 2
> YOU-ME <-- step 3
> ME-YOU --> step 4
> ME-YOU --> <iq type='get' />
> YOU-ME --> step 1
> ME-YOU --> step 2
> ME-YOU <-- step 3
> YOU-ME --> step 4
> YOU-ME --> <iq type='result'/>
> i.e. two non-interleaved dialback actions. But that is mainly for improving readability for humans.
> 
> philipp

Thanks for clarifying!




More information about the Standards mailing list