Re: [Stox] core: connecting to remote domain

[Salvatore Loreto <[e-mail]>]

On 6/20/13 9:28 AM, Adrian Georgescu wrote:
> XMPP has defined DNS records for both C2S and S2S connections. One domain may have a server to server XMPP capability but would not accept client connections (missing correspondent  DNS record), this would give me a clue that that foreign domain has such XMPP 2 SIP gateway in place and if I am a client of that domain I know I cannot use an XMPP client for it.
sorry but what would be the reason to have (and expose thru DNS) an 
XMPP2SIP gateway and then not let it to be accessible from a client?
are you assuming that a XMPP2SIP gateway is always only an outbound one?

/Salvatore

> For SIP however, is not clear as the same DNS records are used both by clients and servers to locate the Proxy/Registrar for a given domain. This is the missing piece that makes a heuristic approach not 100% accurate.
>
> Adrian
>
>
> On Jun 20, 2013, at 8:22 AM, Saúl Ibarra Corretgé <[e-mail]> 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 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.
>>
>> --
>> Saúl Ibarra Corretgé
>> AG Projects
>>
>>
>>
>> _______________________________________________
>> stox mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/stox
>>
> _______________________________________________
> stox mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/stox