Re: [Stox] core: connecting to remote domain

>> Yes, this is a scenario where an operator provides a service using
>> only one of the protocols (typically SIP) and only uses gateway for
>> bridging traffic transparently to other XMPP domains without users
>> having to know that the foreign user is using either SIP or XMPP. It
>> is the SIP server that has the logic to make this routing decision
>> and the gateway has a trusted relations ship with this server to
>> avoid fraudulent usage of such service. The clients only talk to
>> their respective native servers, not directly to the gateway. Same as
>> clients do not talk directly to PSTN gateways, they rely on their
>> servers to make such decisions.
> 
> Right, that makes sense.
> 
> I was thinking about the interdomain communication: if the SIP user
> romeo@example.com sends a message to juliet@example.org, he doesn't need
> to know or care if Juliet uses SIP or XMPP, but the service at
> example.org needs to determine how it will route the message to Juliet
> (i.e., using SIP or XMPP). So it needs to complete some kind of
> discovery or it needs to be configured to "just know" that example.org
> is (say) a SIP service.
> 
> However, while completing a copy edit on the groupchat spec this morning
> I noticed that we already have the following text:
> 
>   Upon receiving the INVITE, the SIP-to-XMPP gateway needs to determine
>   the identity of the remote domain, which it does by performing one or
>   more DNS SRV lookups [RFC2782].  The SIP-to-XMPP gateway SHOULD
>   resolve the address present in the To header of the INVITE to an im
>   URI, then follow the rules in [RFC3861] regarding the "_im" SRV
>   service for the target domain contained in the To header.  If SRV
>   address resolution fails for the "_im" service, the SIP-to-XMPP
>   gateway MAY attempt a lookup for the "_xmpp-server" service as
>   specified in [RFC6120] or MAY return an error to the sender (i.e. 502
>   Bad Gateway).

In practice we do lookup _xmmp_server, I  personally never saw a deployment of those _im records in the real world as of yet but others may confirm if this is the rule or the exception. Does anyone know a public service using those?

> Now, that text is probably old (we've been working on these mapping
> specs for a long time) and thus probably predates the updated XMPP RFCs.
> If we're not going to recommend use of the "_im" and "_pres" SRV
> records, then connections to remote domains a likely a matter for
> implementation and deployment.

It is a matter of implementation

> However, I'd hate to do all this work on
> the mapping specs and then leave the hard federation bits up to folks in
> the field who might not be able to easily configure these services.

Nothing breaks if a gateway tries to lookup those records too, it is harmless yet useless as far as I can see because of lack of adoption. 

> Peter
> 
> -- 
> Peter Saint-Andre
> https://stpeter.im/
> 
> 
> _______________________________________________
> stox mailing list
> stox@ietf.org
> https://www.ietf.org/mailman/listinfo/stox
> 