XMPP, Connect Server, and SRV

Evan Schoenberg evan.s at dreskin.net
Fri Aug 8 13:03:04 EDT 2008


On Aug 7, 2008, at 8:32 PM, Stu Tomlinson <stu at nosnilmot.com> wrote:

> On Thu, 2008-08-07 at 18:24 -0400, Evan Schoenberg wrote:
>> Is there a reason we don't use SRV when a connect server is specified
>> for XMPP?  It seems that we should do an SRV lookup on the connect
>> server (as we do for the domain, if no connect server is specified)
>> and then fallback on the specified server/port.
>>
>> This would allow connecting to XMPP server foo with username at yourdomain.com
>>  by setting your connect server to foo without having to know foo's
>> actual server details (specific XMPP server address and port).
>>
>> Unless there are objections, I'd like to make this change.
>
> That's crazy ridiculous. Connect Server is there as an optional  
> override
> to SRV lookups, I see no other need for it.
>
> What exactly is the scenario where you think this is necessary?

I've been asked to produce a plugin similar to the Google Talk  
service, an XMPP account type with some values prefilled. The service  
allows JIDs as arbitrary email addresses - which, upon further  
consideration, I think may be the real problem. Should an XMPP service  
allow clients whose domains don't match the server, e.g.  
evan at adiumx.com connecting via an XMPP server on pidgin.im?

If this should be allowed, then specifying "evan at adiumx.com" ad the  
jid and pidgin.im as the connect server would be the method for  
connection. However, this then means that pidgin.im must resolve to  
the xmpp server directly. If we wanted to run pidgin.im on  
xmpp.pidgin.im, or via a load-balancer on several different machines  
(xmpp1.pidgin.im, xmpp2.pidgin.im, etc.) this wouldn't be possible  
with the connect server specified, as SRV would not be used.

Does that clarify? Is my client just abusing the connect server, and  
the correct behavior is to require that the jid have a specific domain  
rather than using the connect server in this way?

Cheers,
Evan




More information about the Devel mailing list