[Standards] XEP-0220 unclear?
stpeter at stpeter.im
Wed Jun 2 22:14:52 UTC 2010
On 4/20/10 6:08 AM, 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:
>>>> 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
> 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
>> 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, do we need to add some implementation notes about this to XEP-0220?
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 6820 bytes
Desc: S/MIME Cryptographic Signature
More information about the Standards