XMPP, Connect Server, and SRV

[Sebastiaan Deckers]

On Fri, Oct 17, 2008 at 3:13 PM, Andreas Monitzer <pidgin at monitzer.com>wrote:

> On Oct 17, 2008, at 10:55, Sebastiaan Deckers wrote:
>
>  Not as alien as you think it might be. In fact I'm involved in a project
>> just like.
>> Imagine a network of people who sign up with their existing email address.
>> These addresses could be used by the network as XMPP IDs. So a user could
>> log in with Pandion or Pidgin or any other XMPP client using an ID "
>> billg at microsoft.com" and set the connect server as "
>> some-huge-xmpp-cluster.org"
>> That cluster could support huge numbers of domains and users which don't
>> yet have SRV records.
>>
>> Seems like a valid use case to me, and SRV lookups of the connect server
>> makes it that much easier to implement.
>>
>
> Just because you're breaking the concepts of XMPP doesn't mean pidgin
> should be able to handle this. You wouldn't want anybody to be able to sign
> up for an email account for billg at microsoft.com on your server either,
> would you?
>

I don't see how xmpp-client SRV lookups of a user provided hostname "break
the concepts of XMPP." In fact it seems logical to do that.


Mind you, it's fine that you implement it that way as long as you keep it a
> walled garden, but adding support for your private changes to the protocol
> shouldn't be part of an official XMPP plugin.


Again, I don't really know about Pidgin's source code or how complicated it
is for libpurple developers to make SRV lookups. But frankly that doesn't
matter at all in designing the XMPP specification. The XSF is a standards
foundation, not a software foundation, and therefore there is no "official"
reference implementation.


btw, A records allow load balancing, too (just weights are not supported I
> think).
>

Sure, but SRV is more elegant as it makes the load balancing specifically
for XMPP services and not a blanket A-record which would affect other
services on that domain.


-Sebastiaan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://pidgin.im/pipermail/devel/attachments/20081017/2492012f/attachment.html>