[Standards] dialback refactoring
fippo at goodadvice.pages.de
Thu Jun 25 17:48:31 UTC 2009
Peter Saint-Andre wrote:
> Phillip Hancke has done yeoman's work on simplifying XEP-0220 (Server
> 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:
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.
stream:features: I completely removed <required/> here. For backward
compability reasons, dialback is always required unless SASL is used.
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.
More information about the Standards