XMPP, Connect Server, and SRV

[Peter Saint-Andre]

Peter Saint-Andre wrote:
> 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
>>>>>>> the
>>>>>>>   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
>>>>>> misunderstand
>>>>>> you.
>>>>> Hmm, it seems that I don't have a) captured in the specs yet:
>>>>> http://www.xmpp.org/internet-drafts/draft-saintandre-rfc3920bis-06.html#tcp-resolution
>>>> 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
>> reason.
> 
> I agree. If you did SRV lookups on the SRV lookups, you could get into
> an infinite regress. :)

Clarified here:

http://is.gd/43Ce

/psa