[Standards] XEP-0220 unclear?

Philipp Hancke fippo at goodadvice.pages.de
Tue Apr 20 12:08:57 UTC 2010

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.

>> 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.


More information about the Standards mailing list