[Stox] core: connecting to remote domain

Peter Saint-Andre <stpeter@stpeter.im> Wed, 19 June 2013 22:35 UTC

Return-Path: <stpeter@stpeter.im>
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 046B221F9F3F for <stox@ietfa.amsl.com>; Wed, 19 Jun 2013 15:35:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.535
X-Spam-Level:
X-Spam-Status: No, score=-102.535 tagged_above=-999 required=5 tests=[AWL=0.064, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
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 sgitvsy5EDqx for <stox@ietfa.amsl.com>; Wed, 19 Jun 2013 15:35:39 -0700 (PDT)
Received: from stpeter.im (mailhost.stpeter.im [207.210.219.225]) by ietfa.amsl.com (Postfix) with ESMTP id 839F821F9F3E for <stox@ietf.org>; Wed, 19 Jun 2013 15:35:39 -0700 (PDT)
Received: from ergon.local (unknown [64.101.72.59]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 50A14410F9; Wed, 19 Jun 2013 16:35:37 -0600 (MDT)
Message-ID: <51C23237.30203@stpeter.im>
Date: Wed, 19 Jun 2013 16:35:35 -0600
From: Peter Saint-Andre <stpeter@stpeter.im>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:17.0) Gecko/20130509 Thunderbird/17.0.6
MIME-Version: 1.0
To: "stox@ietf.org" <stox@ietf.org>
X-Enigmail-Version: 1.5.1
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
Subject: [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: Wed, 19 Jun 2013 22:35:44 -0000

-----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.

###

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).

Thoughts?

Peter

- -- 
Peter Saint-Andre
https://stpeter.im/


-----BEGIN PGP SIGNATURE-----
Version: GnuPG/MacGPG2 v2.0.19 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJRwjI3AAoJEOoGpJErxa2pL48QAIMtAOVzfirffe9yZotJ3NCi
9Y+vVAAr2dk9I0f9WOVPFLjP0ylESObRzq6GUyJ2k0iYycTWEyRgz4pBXN8XDgtJ
cjMI7A4zLtYHEvuXXEOSgRQi8L27CpHAZGuBoZLhTyZ1GcPuGNt/NDJIQntP7tRr
KD8grRTMg9Sxel0HaEeMJmggyYIvs85mdoZZBHuGrCSwgaYuy+JfdhgfCJCIxMNc
RbVDfL4xEg0Mgx5seJ/sfojjJ7NT6yXk1SBNXGcj3eCTy5vwn1TvVDUi025/DEcM
lX6lOlOLi2c+FWkVr2qXfRNntyDFTPbYTSDX/r8jnHvfKd06ciaM0NHai6QN7nUp
nbvE+Zyv2lTgTkyJMsM16JBKGJfhBdtKIuhi5KRvbqRlcvNz1RLbDOBAV7whS/xO
XcouS+TA3Txwb5tMRUSQ6AJYiN0i1cWwGCRcFufZBk0fCbo1qzEf56D6lF45QRCJ
TTRGTIJaE6mNtVTd08gUYcUVfcTh5fkIbs+ZQd5hfwvPfWycpEA/05GoKPWSgY/8
E5nzFdAGtBu/ivUOxtAZLakqhwgOlCyK+p2qE2LXBmgXVLHf9PUm+RIod78PN9/K
y1/q6DDe+rMQ339zWkznh8lUR0ibtmXqIsjmEa1Tcisn7CFzqYQ7vI58zG3Xpc4h
lhwqWW3Oc5olL74eU8g3
=uhYH
-----END PGP SIGNATURE-----