[Standards] UPDATED: XEP-0220 (Server Dialback)

Philipp Hancke fippo at goodadvice.pages.de
Mon May 2 07:55:20 UTC 2011

On Tue, 26 Apr 2011, Peter Saint-Andre wrote:
>>> Changelog: To reduce the possibility of confusion, harmonized the
>>> protocol sections so that they show only the first dialback
>>> negotiation from Originating Server to Receiving Server. (psa)
>> Congratulations, you managed not to fix the from/to bugs, despite having
>> a patch ( http://hancke.name/jabber/ilovelovelovebugsinexamples.patch )
>> This is ridiculous.
> I posted to this list about two possible paths: (1) describe only the
> unidirectional dialback negotiation from Originating Server to Receiving
> Server, or (2) describe the bidirectional dialback negotiation (the
> negotiation that authorizes the Originating Server to generate stanzas
> from the Sender Domain, and the negotiation that authorizes the
> Receiving Server to generate stanzas from the Target Domain).
> I said that I leaned heavily toward documenting only the unidirectional
> negotiation. Your patch assumed that we just needed to do a bit of
> cleanup to option #2, whereas I decided to choose option #1 because it
> is confusing to describe both directions.
> Thus your patch did not really apply.

Example 5:
send: <db:verify

Example 6:
recv: <db:verify

Example 7:
recv: <db:verify

My patch, which changed the 'from' attribute in example 
7 to 'sender.tld' did not apply?

Narrative version: the server that sent a <db:verify/> from target.tld
in example 5 receives a stanza from target.tld in example 7?

Using your words this is a "serious bug".

> That is not ridiculous, that is a disagreement.

I have not (yet) reviewed the changes or commented on them.

> However, if you think it is ridiculous to choose option #1 (despite the
> fact that this is what RFC 3920 did), then we can continue to discuss
> the topic on this list, you can appeal to the XMPP Council,

I had evaluated option #1 when writing the initial 0.4. It is much less 
useful when debugging because typically dialback happens twice during a 
bidirectional session and with this option it is harder to figure out 
which packet belongs to which session.

I would not advise people who can not deal with the confusion perceived by 
you in the (corrected) version 0.8 to attempt implementing dialback,
because what happens on the wire is even more complicated.

So I do not see why now, after 18 months, this change is necessary nor why 
it has to be done over the weekend.

> or you can ask me to remove you from the list of authors.

It is not like I currently get to review and approve new versions before 

More information about the Standards mailing list