[Standards] XEP-0220 unclear?

Weasel weasel at tlen.pl
Tue Apr 20 10:00:50 UTC 2010


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"

> 
> 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
> (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"?


More information about the Standards mailing list