XMPP, Connect Server, and SRV

[Daniel Atallah]

2008/8/9 Evan Schoenberg <evan.s at dreskin.net>:
>
> On Aug 9, 2008, at 7:52 PM, Mark Doliner wrote:
> >
> > So the user's jid is "evan at adiumx.com"?  Why would it matter what the
> > SRV record is for pidgin.im?  Couldn't you set the SRV record of
> > adiumx.com to point to xmpp.pidgin.im?
>
> This is not for the case in which pidgin.im manages all adiumx.com JIDs.
>  adiumx.com is still running its own XMPP server.  So setting adiumx.com's
> recor dto xmpp.pidgin.im would disable adium's server entirely.
> The adiumx/pidgin domain names are just example; imagine that pidgin.im is a
> nonfederated server, which is not the realworld case.

I don't follow - why would you want to have two separate networks that
you connect to for the same JID?  That just seems like a recipe for
problems.

>
> >  Or set the connect server to
> > xmpp.pidgin.im?
>
> You could, and that would work.  However, that prevents the server from
> managing the connection destination, which is the entire problem SRV
> resolves.  pidgin.im's SRV record could be updated at a later time, or more
> usefully could be managed via a load balancer which distributes clients to
> xmpp1.pidgin.im
> xmpp2.pidgin.im
> or
> xmpp3.pidgin.im

This could be done by using several A records for xmpp.pidgin.im.

> > Doing an SRV record lookup on the connect server doesn't seem like a
> > good idea to me.  The connect server is kind of an ugly workaround for
> > people who don't have the ability to use SRV records for whatever
> > reason.  Doing an SRV lookup on that seems like it could cause
> > confusion.
>
> The SRV lookup, of course, automatically falls back on the specified
> server/port if it fails.  It seems to me that doing the lookup fixes edge
> cases (such as I've described) and will effectively continue the current
> behavior for most users (for whom the connect server is indeed used because
> SRV fails on the domain portion of the JID for whatever reason).

It seems to me that this change would effectively cause the same
"problem" that you're trying to avoid by not specifying SRV records at
the JID domain another layer up - what if the "connect server" has a
SRV record set up, but you still want to connect to it directly -
you'd be unable to.  At least now, you can set the connect server to
the right value and it'll work.

I think that this tries to a fix something that would be better
avoided from a sane configuration perspective.  The connect server is
already an override - if you specify a value, you're already making a
manual configuration, in which case using the correct full
configuration will just work.

-D