[sixpac] Resolving SIP/XMPP URIs

<Markus.Isomaki@nokia.com> Tue, 01 February 2011 11:56 UTC

Return-Path: <Markus.Isomaki@nokia.com>
X-Original-To: sixpac@core3.amsl.com
Delivered-To: sixpac@core3.amsl.com
Received: from localhost (localhost []) by core3.amsl.com (Postfix) with ESMTP id 4A24A3A6CC7 for <sixpac@core3.amsl.com>; Tue, 1 Feb 2011 03:56:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.571
X-Spam-Status: No, score=-3.571 tagged_above=-999 required=5 tests=[AWL=-0.972, BAYES_00=-2.599]
Received: from mail.ietf.org ([]) by localhost (core3.amsl.com []) (amavisd-new, port 10024) with ESMTP id oZite0pvcDsK for <sixpac@core3.amsl.com>; Tue, 1 Feb 2011 03:56:38 -0800 (PST)
Received: from mgw-sa01.nokia.com (smtp.nokia.com []) by core3.amsl.com (Postfix) with ESMTP id 2D66C3A6CC6 for <sixpac@ietf.org>; Tue, 1 Feb 2011 03:56:37 -0800 (PST)
Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com []) by mgw-sa01.nokia.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id p11BxrPT004697; Tue, 1 Feb 2011 13:59:54 +0200
Received: from smtp.mgd.nokia.com ([]) by vaebh105.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Tue, 1 Feb 2011 13:59:49 +0200
Received: from 008-AM1MMR1-006.mgdnok.nokia.com ( by NOK-AM1MHUB-04.mgdnok.nokia.com ( with Microsoft SMTP Server (TLS) id; Tue, 1 Feb 2011 12:59:48 +0100
Received: from 008-AM1MPN1-004.mgdnok.nokia.com ([]) by 008-AM1MMR1-006.mgdnok.nokia.com ([]) with mapi; Tue, 1 Feb 2011 12:59:47 +0100
From: <Markus.Isomaki@nokia.com>
To: <john.elwell@siemens-enterprise.com>, <Simo.Veikkolainen@nokia.com>, <sixpac@ietf.org>
Thread-Topic: Resolving SIP/XMPP URIs
Thread-Index: AQHLwgeGeNM0i3/v7kqPya3/zXRKmw==
Date: Tue, 1 Feb 2011 11:59:47 +0000
Message-ID: <DD8B10B86502AB488CB2D3DB4C546E38E67FCD@008-AM1MPN1-004.mgdnok.nokia.com>
References: <F9E2FDAF48D4544F874A56A3A8BD68B13BC79A@008-AM1MPN1-003.mgdnok.nokia.com> <A444A0F8084434499206E78C106220CA06A858780C@MCHP058A.global-ad.net>
In-Reply-To: <A444A0F8084434499206E78C106220CA06A858780C@MCHP058A.global-ad.net>
Accept-Language: en-US
Content-Language: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginalArrivalTime: 01 Feb 2011 11:59:49.0097 (UTC) FILETIME=[86B83590:01CBC207]
X-Nokia-AV: Clean
Subject: [sixpac] Resolving SIP/XMPP URIs
X-BeenThere: sixpac@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "The SIXPAC \(SIP Interworking with XMPP in Presence Aware Clients\) list is dedicated to discussion of dual-stack SIP/XMPP user agents." <sixpac.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/sixpac>, <mailto:sixpac-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sixpac>
List-Post: <mailto:sixpac@ietf.org>
List-Help: <mailto:sixpac-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sixpac>, <mailto:sixpac-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 01 Feb 2011 11:56:39 -0000


John Elwell wrote:
>5. "REQ-4:  It must be possible for a user, who only knows another
>           SIP URI, to learn the other user's XMPP URI."
>Is there a particular reason this is asymmetrical? Should there also be
>a requirement for a user who knows another user's XMPP URI to learn that
>user's SIP URI?

>From requirements and user experience perspective this should be symmetric, so I would agree adding that to the requirements.

The actual protocol realization may be more challenging. In the SIXPAC "model" presence information is exchanged via XMPP. So, if a SIXPAC client knows an XMPP address, it can conveniently use presence to learn about the corresponding SIP address (using the envisioned presence data extensions). But if the SIXPAC client knows a SIP address to start with, what would be preferred way for learning the corresponding XMPP address? Would SIP OPTIONS be a good approach? That's the only realistically deployable method that I can think of. Can we assume OPTIONS would work at least to a reasonable extent between SIP UAs in current SIP deployments? (On paper it does, but unfortunately we always need to ask this question due to the deployment realities...)