Re: [sixpac] Resolving SIP/XMPP URIs

<Simo.Veikkolainen@nokia.com> Thu, 03 February 2011 13:37 UTC

Return-Path: <Simo.Veikkolainen@nokia.com>
X-Original-To: sixpac@core3.amsl.com
Delivered-To: sixpac@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1DB3A3A6919 for <sixpac@core3.amsl.com>; Thu, 3 Feb 2011 05:37:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.026
X-Spam-Level:
X-Spam-Status: No, score=-4.026 tagged_above=-999 required=5 tests=[AWL=-1.427, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L3wJ8jaNXzOZ for <sixpac@core3.amsl.com>; Thu, 3 Feb 2011 05:37:21 -0800 (PST)
Received: from mgw-da02.nokia.com (smtp.nokia.com [147.243.128.26]) by core3.amsl.com (Postfix) with ESMTP id C90253A68F8 for <sixpac@ietf.org>; Thu, 3 Feb 2011 05:37:21 -0800 (PST)
Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-da02.nokia.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id p13DeP2r025327; Thu, 3 Feb 2011 15:40:43 +0200
Received: from smtp.mgd.nokia.com ([65.54.30.6]) by vaebh105.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Thu, 3 Feb 2011 15:40:35 +0200
Received: from 008-AM1MMR1-004.mgdnok.nokia.com (65.54.30.59) by NOK-am1MHUB-02.mgdnok.nokia.com (65.54.30.6) with Microsoft SMTP Server (TLS) id 8.2.255.0; Thu, 3 Feb 2011 14:40:34 +0100
Received: from 008-AM1MPN1-004.mgdnok.nokia.com ([169.254.5.218]) by 008-AM1MMR1-004.mgdnok.nokia.com ([65.54.30.59]) with mapi; Thu, 3 Feb 2011 14:40:29 +0100
From: Simo.Veikkolainen@nokia.com
To: emcho@sip-communicator.org, john.elwell@siemens-enterprise.com
Thread-Topic: [sixpac] Resolving SIP/XMPP URIs
Thread-Index: AQHLwrQcNz3WGAhyB0y3L8KdQqtgZZPvyYZg
Date: Thu, 03 Feb 2011 13:40:27 +0000
Message-ID: <F9E2FDAF48D4544F874A56A3A8BD68B101029D32@008-AM1MPN1-004.mgdnok.nokia.com>
References: <F9E2FDAF48D4544F874A56A3A8BD68B13BC79A@008-AM1MPN1-003.mgdnok.nokia.com> <A444A0F8084434499206E78C106220CA06A858780C@MCHP058A.global-ad.net> <DD8B10B86502AB488CB2D3DB4C546E38E67FCD@008-AM1MPN1-004.mgdnok.nokia.com> <A444A0F8084434499206E78C106220CA06C2734A8C@MCHP058A.global-ad.net> <4D49172B.9050309@sip-communicator.org>
In-Reply-To: <4D49172B.9050309@sip-communicator.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginalArrivalTime: 03 Feb 2011 13:40:35.0474 (UTC) FILETIME=[EF779F20:01CBC3A7]
X-Nokia-AV: Clean
Cc: sixpac@ietf.org
Subject: Re: [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: Thu, 03 Feb 2011 13:37:23 -0000

> -----Original Message-----
> From: ext Emil Ivov [mailto:emcho@sip-communicator.org]
> Sent: 02 February, 2011 10:35
> To: Elwell, John
> Cc: Isomaki Markus (Nokia-CIC/Espoo); Veikkolainen Simo (Nokia-
> MS/Helsinki); sixpac@ietf.org
> Subject: Re: [sixpac] Resolving SIP/XMPP URIs
> 
> Hey folks,
> 
> На 02.02.11 09:48, Elwell, John написа:
> > I see now, this was meant to be a requirement to obtain the XMPP
> > address WITHOUT establishing a SIP call. If a SIP call were to be
> > established, that would be covered by REQ-2 (although expressed
> > slightly differently there).
> >
> > So the question is whether, without making a SIP call, there should
> > be a requirement to be able to discover the XMPP address. I don't
> > have a strong opinion, but it certainly sounds reasonable to require
> > this - I could check your presence status or send you an IM without
> > calling you.
> 
> Retrieving an XMPP URI from a SIP one _without_ a previous call seems
> somewhat exotic to me. I'd therefore say that allowing for OPTIONS the
> same headers that would otherwise carry XMPP URIs during call would be
> more than enough, and so be it if this doesn't always work.

I would also assume that the usual pattern is that you subscribe to XMPP presence and learn the SIP address that way.

But, as long as the requirement is concerned, would everyone be happy with this text:

         It must be possible for a user, who only knows another
         user’s SIP URI, to learn the other user’s XMPP URI, and
	   vice versa.


Regards,
Simo

> Cheers,
> Emil
> 
> > Concerning the solution space, OPTIONS might indeed be one method.
> > For example, if Call-Info were used to exchange the address during a
> > call, it could also be exchanged in OPTIONS. There is little else,
> > unless we have an event package, which seems unnecessarily complex.
> >
> > John
> >
> >> -----Original Message----- From: Markus.Isomaki@nokia.com
> >> [mailto:Markus.Isomaki@nokia.com] Sent: 01 February 2011 12:00 To:
> >> Elwell, John; Simo.Veikkolainen@nokia.com; sixpac@ietf.org Subject:
> >> Resolving SIP/XMPP URIs
> >>
> >> Hi,
> >>
> >> John Elwell wrote:
> >>>
> >>> 5. "REQ-4:  It must be possible for a user, who only knows
> >>> another user's 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...)
> >>
> >> Markus
> >>
> > _______________________________________________ sixpac mailing list
> > sixpac@ietf.org https://www.ietf.org/mailman/listinfo/sixpac
> >
> 
> --
> Emil Ivov, Ph.D.                               67000 Strasbourg,
> Project Lead                                   France
> SIP Communicator
> emcho@sip-communicator.org                     PHONE: +33.1.77.62.43.30
> http://sip-communicator.org                    FAX:   +33.1.77.62.47.31