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 >> 2000. >> >> 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. Peter -- Peter Saint-Andre https://stpeter.im/
smime.p7s
Description: S/MIME Cryptographic Signature
