Re: [Stox] core: connecting to remote domain

Saúl Ibarra Corretgé <saul@ag-projects.com> Thu, 20 June 2013 06:23 UTC

Return-Path: <saul@ag-projects.com>
X-Original-To: stox@ietfa.amsl.com
Delivered-To: stox@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EAAB11E80D9 for <stox@ietfa.amsl.com>; Wed, 19 Jun 2013 23:23:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.927
X-Spam-Level:
X-Spam-Status: No, score=-0.927 tagged_above=-999 required=5 tests=[AWL=-0.109, BAYES_00=-2.599, HELO_MISMATCH_NET=0.611, MIME_8BIT_HEADER=0.3, SARE_MLH_Stock1=0.87]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NF4vmT1j8dre for <stox@ietfa.amsl.com>; Wed, 19 Jun 2013 23:22:59 -0700 (PDT)
Received: from mail.sipthor.net (node06.dns-hosting.info [85.17.186.6]) by ietfa.amsl.com (Postfix) with ESMTP id 8FDE211E8106 for <stox@ietf.org>; Wed, 19 Jun 2013 23:22:53 -0700 (PDT)
Received: by mail.sipthor.net (Postfix, from userid 5001) id 8B557B35DC; Thu, 20 Jun 2013 08:22:52 +0200 (CEST)
Received: from [192.168.99.48] (ip3e830637.speed.planet.nl [62.131.6.55]) by mail.sipthor.net (Postfix) with ESMTPSA id 87E44B017A; Thu, 20 Jun 2013 08:22:51 +0200 (CEST)
Content-Type: text/plain; charset="iso-8859-1"
Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\))
From: Saúl Ibarra Corretgé <saul@ag-projects.com>
In-Reply-To: <51C23237.30203@stpeter.im>
Date: Thu, 20 Jun 2013 08:22:54 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <1050DBB5-7660-477A-BF07-F8BE853D0DFA@ag-projects.com>
References: <51C23237.30203@stpeter.im>
To: Peter Saint-Andre <stpeter@stpeter.im>
X-Mailer: Apple Mail (2.1508)
Cc: "stox@ietf.org" <stox@ietf.org>
Subject: Re: [Stox] core: connecting to remote domain
X-BeenThere: stox@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: SIP-TO-XMPP Working Group discussion list <stox.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/stox>, <mailto:stox-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/stox>
List-Post: <mailto:stox@ietf.org>
List-Help: <mailto:stox-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/stox>, <mailto:stox-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 20 Jun 2013 06:23:05 -0000

Hi!

On Jun 20, 2013, at 12:35 AM, Peter Saint-Andre <stpeter@stpeter.im> 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