Re: [sixpac] Resolving SIP/XMPP URIs
"Elwell, John" <john.elwell@siemens-enterprise.com> Wed, 02 February 2011 07:44 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 2842B3A6E88 for <sixpac@core3.amsl.com>; Tue, 1 Feb 2011 23:44:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.536
X-Spam-Level:
X-Spam-Status: No, score=-102.536 tagged_above=-999 required=5 tests=[AWL=0.063, BAYES_00=-2.599, 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 TbDnQq6UTpwK for <sixpac@core3.amsl.com>; Tue, 1 Feb 2011 23:44:50 -0800 (PST)
Received: from ms01.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id E50763A6CBE for <sixpac@ietf.org>; Tue, 1 Feb 2011 23:44:49 -0800 (PST)
Received: from senmx11-mx ([62.134.46.9] [62.134.46.9]) by ms01.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-3238393; Wed, 2 Feb 2011 08:48:07 +0100
Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx11-mx (Server) with ESMTP id 548BB1EB82AB; Wed, 2 Feb 2011 08:48:07 +0100 (CET)
Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Wed, 2 Feb 2011 08:48:07 +0100
From: "Elwell, John" <john.elwell@siemens-enterprise.com>
To: "Markus.Isomaki@nokia.com" <Markus.Isomaki@nokia.com>, "Simo.Veikkolainen@nokia.com" <Simo.Veikkolainen@nokia.com>, "sixpac@ietf.org" <sixpac@ietf.org>
Date: Wed, 02 Feb 2011 08:48:06 +0100
Thread-Topic: Resolving SIP/XMPP URIs
Thread-Index: AQHLwgeGeNM0i3/v7kqPya3/zXRKm5Pt1IaA
Message-ID: <A444A0F8084434499206E78C106220CA06C2734A8C@MCHP058A.global-ad.net>
References: <F9E2FDAF48D4544F874A56A3A8BD68B13BC79A@008-AM1MPN1-003.mgdnok.nokia.com> <A444A0F8084434499206E78C106220CA06A858780C@MCHP058A.global-ad.net> <DD8B10B86502AB488CB2D3DB4C546E38E67FCD@008-AM1MPN1-004.mgdnok.nokia.com>
In-Reply-To: <DD8B10B86502AB488CB2D3DB4C546E38E67FCD@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="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
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: Wed, 02 Feb 2011 07:44:51 -0000
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. 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] FW: New Version Notification for draft-v… Simo.Veikkolainen
- Re: [sixpac] FW: New Version Notification for dra… Elwell, John
- Re: [sixpac] FW: New Version Notification for dra… Simo.Veikkolainen
- Re: [sixpac] FW: New Version Notification for dra… Markus.Isomaki
- Re: [sixpac] FW: New Version Notification for dra… Markus.Isomaki
- [sixpac] Resolving SIP/XMPP URIs Markus.Isomaki
- Re: [sixpac] Resolving SIP/XMPP URIs Elwell, John
- Re: [sixpac] Resolving SIP/XMPP URIs Emil Ivov
- Re: [sixpac] Resolving SIP/XMPP URIs Simo.Veikkolainen
- Re: [sixpac] Resolving SIP/XMPP URIs Elwell, John
- [sixpac] Capability and preference expression and… Gunnar Hellström
- Re: [sixpac] FW: New Version Notification for dra… Elwell, John
- Re: [sixpac] Capability and preference expression… Gunnar Hellström
- Re: [sixpac] Capability and preference expression… Joe Hildebrand
- Re: [sixpac] Capability and preference expression… Simo.Veikkolainen
- Re: [sixpac] Capability and preference expression… Gunnar Hellström
- Re: [sixpac] Capability and preference expression… Simo.Veikkolainen
- Re: [sixpac] Capability and preference expression… Gunnar Hellström