[Standards] dialback refactoring

Peter Saint-Andre stpeter at stpeter.im
Thu Jun 25 02:16:00 UTC 2009


-----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-----



More information about the Standards mailing list