[Standards] XEP-0220 unclear?

Peter Saint-Andre 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:
>>>> 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.
> 

Philipp, do we need to add some implementation notes about this to XEP-0220?

Peter

-- 
Peter Saint-Andre
https://stpeter.im/



-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 6820 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mail.jabber.org/pipermail/standards/attachments/20100602/7a27f417/attachment.bin>


More information about the Standards mailing list