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
from='target.tld'
...
Example 6:
recv: <db:verify
from='sender.tld'
...
Example 7:
recv: <db:verify
from='target.tld'
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
publication...
