[Standards] UPDATED: XEP-0220 (Server Dialback)
stpeter at stpeter.im
Tue Apr 26 20:32:31 UTC 2011
On 4/26/11 1:27 AM, Philipp Hancke wrote:
> On Mon, 25 Apr 2011, XMPP Extensions Editor wrote:
>> Version 0.9 of XEP-0220 (Server Dialback) has been released.
>> Abstract: This specification defines the Server Dialback protocol,
>> which is used between XMPP servers to provide identity verification.
>> Server Dialback uses the Domain Name System (DNS) as the basis for
>> verifying identity; the basic approach is that when a receiving server
>> accepts a server-to-server connection from an originating server, it
>> does not process traffic over the connection until it has verified a
>> key with an authoritative server for the domain asserted by the
>> originating server. Although Server Dialback does not provide strong
>> authentication or trusted federation and although it is subject to DNS
>> poisoning attacks, it has effectively prevented most instances of
>> address spoofing on the XMPP network since its development in the year
>> 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. That is not ridiculous, that is a disagreement.
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, or you can
ask me to remove you from the list of authors.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 6105 bytes
Desc: S/MIME Cryptographic Signature
More information about the Standards