[Standards] XEP-0220 unclear?

Peter Saint-Andre stpeter at stpeter.im
Tue Apr 20 11:47:26 UTC 2010


On 4/20/10 4:00 AM, Weasel wrote:
> 
> 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"?

I think so. At least sending the verification key first seems like the
right way to go.

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/20100420/f2d2a91c/attachment.bin>


More information about the Standards mailing list