-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 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 >> 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 >> 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 > XEP-0185.
OK. So: - - 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 are helpful. >> 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"? > 2.5: > "already use for domain 'A' if" > "already used for domain 'A', if" Fixed. > I'd like to see a paragraph on how bouncing works exactly, with an > example. 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! Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkpC3eAACgkQNL8k5A2w/vwQOACgj48YEZyS/P+LrKwMzn+kRjEB 71MAn0qbtwlyKo9rgF+ek9Ss11tj7zga =FqLM -----END PGP SIGNATURE-----
