XMPP, Connect Server, and SRV
stpeter at stpeter.im
Mon Oct 13 18:50:05 EDT 2008
Mark Doliner wrote:
> On Thu, Sep 18, 2008 at 7:49 PM, Evan Schoenberg <evan.s at dreskin.net> wrote:
>> On Sep 18, 2008, at 11:35 AM, Peter Saint-Andre <stpeter at stpeter.im> wrote:
>>> Peter Saint-Andre wrote:
>>>> Ethan Blanton wrote:
>>>>> Bron Gondwana spake unto us the following wisdom:
>>>>>> My idea of the correct behaviour is:
>>>>>> a) if an explicit server name is specified, use that always
>>>>>> b) otherwise, lookup up the _jabber._tcp or _xmpp-client._tcp for
>>>>>> domain part of the username.
>>>>>> c) finally, try the A record for the domain part.
>>>>> I'm pretty sure this is the *current* behavior, unless I
>>>> Hmm, it seems that I don't have a) captured in the specs yet:
>>> OK, I just added the following text to my working copy:
>>> Note: If the initiating entity has been explicitly configured to
>>> associate a particular hostname (and potentially port) with the
>>> original hostname of the receiving entity (say, to "hardcode" an
>>> association between an original hostname of example.net and a
>>> configured hostname and of webcm.example.com:80), the initiating
>>> entity SHALL use the configured name instead of the original name
>>> when following the resolution process described above.
>>> Does that explain scenario (a) more clearly?
>> I remain unclear on whether an SRV lookup should be performed using
>> the "overridden" server or not.
> Sorry to bring up an old thread, I just happened to be looking at it.
> No, I do not think an SRV lookup should be performed when the
> "overridden" server is used. The "connect server" field is an
> alternative to using DNS SRV records. And it should really only be
> used at times when the DNS SRV record can't be used for whatever
I agree. If you did SRV lookups on the SRV lookups, you could get into
an infinite regress. :)
More information about the Devel