Re: [sixpac] Resolving SIP/XMPP URIs

Emil Ivov <emcho@sip-communicator.org> Wed, 02 February 2011 08:31 UTC

Return-Path: <emcho@sip-communicator.org>
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 E46E73A6AF0 for <sixpac@core3.amsl.com>; Wed, 2 Feb 2011 00:31:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level:
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
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 ZLrrE27YCFgB for <sixpac@core3.amsl.com>; Wed, 2 Feb 2011 00:31:38 -0800 (PST)
Received: from mail-ew0-f44.google.com (mail-ew0-f44.google.com [209.85.215.44]) by core3.amsl.com (Postfix) with ESMTP id A3F7E3A6965 for <sixpac@ietf.org>; Wed, 2 Feb 2011 00:31:37 -0800 (PST)
Received: by ewy8 with SMTP id 8so4002986ewy.31 for <sixpac@ietf.org>; Wed, 02 Feb 2011 00:34:56 -0800 (PST)
Received: by 10.213.33.17 with SMTP id f17mr11422750ebd.6.1296635695933; Wed, 02 Feb 2011 00:34:55 -0800 (PST)
Received: from porcinet.local (87-126-226-239.btc-net.bg [87.126.226.239]) by mx.google.com with ESMTPS id t50sm18012634eeh.18.2011.02.02.00.34.53 (version=TLSv1/SSLv3 cipher=RC4-MD5); Wed, 02 Feb 2011 00:34:54 -0800 (PST)
Message-ID: <4D49172B.9050309@sip-communicator.org>
Date: Wed, 02 Feb 2011 10:34:51 +0200
From: Emil Ivov <emcho@sip-communicator.org>
Organization: SIP Communicator
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; bg; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7
MIME-Version: 1.0
To: "Elwell, John" <john.elwell@siemens-enterprise.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>
In-Reply-To: <A444A0F8084434499206E78C106220CA06C2734A8C@MCHP058A.global-ad.net>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
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: Wed, 02 Feb 2011 08:31:40 -0000

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.

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