[Standards] dialback refactoring
stpeter at stpeter.im
Thu Jun 25 02:16:00 UTC 2009
-----BEGIN PGP SIGNED MESSAGE-----
On 6/24/09 2:49 PM, Ralph Meijer wrote:
> On Wed, 2009-06-24 at 14:16 -0600, Peter Saint-Andre wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>> 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
>> 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)
> Yeah, that seems ok, although I would probably keep 'Server' instead of
> 'Host' and 'Receiving Server' to keep in sync with RFC 3920 and
- - Sending Domain
- - Accepting Domain
- - Originating Server
- - Receiving Server
- - Authoritative Server
> To make it more real, make sure the hosts have different
> hostnames (duck.example.org, swan.example.org and elephant.example.com)
> from the domains (example.org, example.com). Maybe also show the
> associated DNS records (SRV and A).
I have DNS records and IP addresses in version 0.3 of the spec, so it
would be fairly straightforward to port those over. I agree that they
>> 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.
> We can go two ways here for which we would need to define a new
> condition in the dialback namespace: have a application specific error
> condition like stanza errors to go with a general host-unknown
> condition, or only have one error element and use the new one there for
> this case.
Looking more closely, I would pair them up as follows:
DB authoritative-host-unknown = stanza remote-server-not-found (sent
from receiving server to originating server if the authoritative server
does not service the domain asserted by the originating server)
DB host-unknown = stanza item-not-found
DB remote-connection-failed = recipient-unavailable
DB remote-server-timeout = stanza remote-server-timeout
>> Ralph, do you have further feedback?
> I think you removed the confusing switching of roles of the servers
> between sections, per my request. I.e. you switched the hosts in two
> sections, but forgot to make the associated changes to the hash and
> session IDs. I expect to see only one stream ID (D60000229F) and one
> hash (37c69b1cf07a3f67c04a5ef5902fa5114f2c76fe4a2686482ba5b89323075643).
> The hash calculation would also need to updated to that effect.
> Obviously, if you change the Receiving domain to example.com, this needs
> to be recalculated anyway.
Correct. I ran out of time to do that (in fact I don't remember how I
generated those since openssl doesn't support HMAC-SHA256, but I'll
figure it out again).
> I expect the title for example 13 to be from the other perspective.
So "Authoritative Server Receives Verification Request"?
> "already use for domain 'A' if"
> "already used for domain 'A', if"
> I'd like to see a paragraph on how bouncing works exactly, with an
Yes, that would be helpful. I'll write new subsection about that (we'll
need to add the triggering message so that we can show it being bounced
by the receiving server).
> Thanks for the refactoring. It is a way better read overall.
It's mostly Philipp's work, so thanks Philipp!
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
-----END PGP SIGNATURE-----
More information about the Standards