Re: [sixpac] Resolving SIP/XMPP URIs

"Elwell, John" <john.elwell@siemens-enterprise.com> Thu, 03 February 2011 17:26 UTC

Return-Path: <john.elwell@siemens-enterprise.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 9C2563A6A37 for <sixpac@core3.amsl.com>; Thu, 3 Feb 2011 09:26:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.25
X-Spam-Level:
X-Spam-Status: No, score=-101.25 tagged_above=-999 required=5 tests=[AWL=-1.101, BAYES_00=-2.599, MIME_CHARSET_FARAWAY=2.45, USER_IN_WHITELIST=-100]
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 50GLr3wpMO28 for <sixpac@core3.amsl.com>; Thu, 3 Feb 2011 09:26:51 -0800 (PST)
Received: from ms03.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id DA4A83A6A38 for <sixpac@ietf.org>; Thu, 3 Feb 2011 09:26:50 -0800 (PST)
Received: from senmx12-mx ([62.134.46.10] [62.134.46.10]) by ms03.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-3256995; Thu, 3 Feb 2011 18:29:47 +0100
Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx12-mx (Server) with ESMTP id 0F72623F028E; Thu, 3 Feb 2011 18:29:47 +0100 (CET)
Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Thu, 3 Feb 2011 18:29:46 +0100
From: "Elwell, John" <john.elwell@siemens-enterprise.com>
To: "Simo.Veikkolainen@nokia.com" <Simo.Veikkolainen@nokia.com>, "emcho@sip-communicator.org" <emcho@sip-communicator.org>
Date: Thu, 3 Feb 2011 18:29:45 +0100
Thread-Topic: [sixpac] Resolving SIP/XMPP URIs
Thread-Index: AQHLwrQcNz3WGAhyB0y3L8KdQqtgZZPvyYZggAA/5aA=
Message-ID: <A444A0F8084434499206E78C106220CA06C2998003@MCHP058A.global-ad.net>
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> <F9E2FDAF48D4544F874A56A3A8BD68B101029D32@008-AM1MPN1-004.mgdnok.nokia.com>
In-Reply-To: <F9E2FDAF48D4544F874A56A3A8BD68B101029D32@008-AM1MPN1-004.mgdnok.nokia.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="koi8-r"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "sixpac@ietf.org" <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 17:26:52 -0000

One scenario would be a user who has only a telephone number. That could be used to make a call to the other user, but it might be preferred to look at presence or send an IM first.

I agree this is perhaps not a very common situation. When only a telephone number is available, it tends to be for somebody outside one's organization, and probably presence / IM would not be available anyway.

Perhaps this is just a desirable, not a firm requirement. I will go with the majority.

John 

> -----Original Message-----
> From: Simo.Veikkolainen@nokia.com 
> [mailto:Simo.Veikkolainen@nokia.com] 
> Sent: 03 February 2011 13:40
> To: emcho@sip-communicator.org; Elwell, John
> Cc: Markus.Isomaki@nokia.com; sixpac@ietf.org
> Subject: RE: [sixpac] Resolving SIP/XMPP URIs
> 
> > -----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
> 
>