Re: [Stox] core: connecting to remote domain

[Salvatore Loreto <[e-mail]>]

Hi,

On 6/20/13 9:22 AM, Saúl Ibarra Corretgé wrote:
> Hi!
>
> On Jun 20, 2013, at 12:35 AM, Peter Saint-Andre <[e-mail]> wrote:
>
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> While working on the sip-xmpp-groupchat spec today, Saúl and I found
>> what I think is an open issue wiht the sip-xmpp-core spec: it doesn't
>> say how you determine whether a remote domain supports SIP or XMPP (or
>> both). This is needed for interdomain routing of messages. Thus I
>> think the sip-xmpp-core spec needs to contain something like the text
>> in Section 11.2 of RFC 3921:
>>
>> ###
>>
>> 11.2. Outbound Stanzas
>>
>>
>>    If the hostname of the domain identifier portion of the address
>>    contained in the 'to' attribute of an outbound stanza matches a
>>    hostname of the server itself, the server MUST deliver the stanza to
>>    a local entity according the rules for Inbound Stanzas (Section
>>    11.1).
>>
>>    If the hostname of the domain identifier portion of the address
>>    contained in the 'to' attribute of an outbound stanza does not match
>>    a hostname of the server itself, the server MUST attempt to route the
>>    stanza to the foreign domain.  The recommended order of actions is as
>>    follows:
>>
>>    1.  First attempt to resolve the foreign hostname using an [SRV]
>>        Service of "xmpp-server" and Proto of "tcp", resulting in
>>        resource records such as "_xmpp-server._tcp.example.com.", as
>>        specified in [XMPP-CORE].
>>
>>    2.  If the "xmpp-server" address record resolution fails, attempt to
>>        resolve the "_im" or "_pres" [SRV] Service as specified in
>>        [IMP-SRV], using the "_im" Service for <message/> stanzas and the
>>        "_pres" Service for <presence/> stanzas (it is up to the
>>        implementation how to handle <iq/> stanzas).  This will result in
>>        one or more resolutions of the form "_im.<proto>.example.com." or
>>        "_pres.<proto>.example.com.", where "<proto>" would be a label
>>        registered in the Instant Messaging SRV Protocol Label registry
>>        or the Presence SRV Protocol Label registry: either "_xmpp" for
>>        an XMPP-aware domain or some other IANA-registered label (e.g.,
>>        "_simple") for a non-XMPP-aware domain.
>>
>>    3.  If both SRV address record resolutions fail, attempt to perform a
>>        normal IPv4/IPv6 address record resolution to determine the IP
>>        address using the "xmpp-server" port of 5269 registered with the
>>        IANA, as specified in [XMPP-CORE].
>>
>>    Administrators of server deployments are strongly encouraged to keep
>>    the _im._xmpp, _pres._xmpp, and _xmpp._tcp SRV records properly
>>    synchronized, since different implementations might perform the "_im"
>>    and "_pres" lookups before the "xmpp-server" lookup.
>>
>> ###
>>
> Well, the problem is that in practice a given domain would have records for both SIP and XMPP, so which one would we check first? I'm not sure if we can define an unequivocal mechanism to choose the right target, so I'm tempted to suggest not to define it for the moment and leave it as a local policy item.

if a domain has a record for both SIP and XMMP
then if you are an XMPP client, it seems normal to me try first the XMPP one
(and the other way around if I am a SIP UA)

or I am missing something here?

>   If we come up with a way to do it later on, maybe we can create a new document updating sip-xmpp core?
>
>> However, we'd need text describing the discovery and decision process
>> in both directions (and IMHO we need to drop the _im and _pres SRV
>> stuff, as we did when working on RFC 6121).
>>
> I have never seen _im and _pres out in the wild, so I'm +1 on removing the mention to them.
+1 on removing them

/Salvatore