Peter Saint-Andre wrote:
Phillip Hancke has done yeoman's work on simplifying XEP-0220 (Server
Dialback):
http://xmpp.org/extensions/tmp/xep-0220-refactored.html
I've completed a review of his work and it looks quite good to me (the
URL above now includes my edits). Ralph Meijer sent me some review
comments via private email, most of which I have also incorporated. A
few issues remain:
1. The terminology can be a bit confusing. I really like the term
"domain pair" (introduced by Phillip). However, we now talk about
If we have sending domains A, B on one side and receiving domains X, Z
on the other side, dialback needs to be completed four times:
A->X
B->Z
A->Z
B->X
Is that clear from the text?
Originating Domain and Receiving Domain as well as Originating Server,
Receiving Server, and Authoritative Server. Perhaps it would be a bit
clearer to use the following terms?
- Sending Domain
- Receiving Domain
- Originating Host (actual machine that initiates the negotiation)
- Accepting Host (actual machine to which Originating Host connects)
- Authoritative Host (actual machine that Accepting Host checks with)
+1 on your latest proposal.
2. Error handling. Ralph pointed out that we could use stanza errors
instead of the 'condition' attribute. I rather like that idea (let's
re-use what we've already defined), which is probably why I was re-using
stream errors in version 0.3 of XEP-0220 (what is currently published).
However, the authoritative-host-unknown condition that Phillip has
defined does not have an exact counterpart in stanza errors, so we might
need to define something new.
stanza errors inside dialback not-stanzas? Works for me though.
Further issues:
stream:features: I completely removed <required/> here. For backward
compability reasons, dialback is always required unless SASL is used.
Any objections?
multiplexing: the section is way to short. The old version contains a
very good motivation paragraph which just needs minor tweeks.
I can write up something more detailed here, but first: do we have
consensus on the conditions (same host:port combination for "destination
piggybacking")? Unfortunately, jabberd code is rather cryptic and
I could not figure out what the original plan was :-/
no dial-back: I wonder if we should simply merge Dave's ideas (tls,
originating ip contained in srv) on that. That would be a subsection
under 2.1.1 where it is stated now that other methods are out-of-scope.
philipp
