Re: [sixpac] Resolving SIP/XMPP URIs

"Elwell, John" <> Wed, 02 February 2011 07:44 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2842B3A6E88 for <>; Tue, 1 Feb 2011 23:44:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -102.536
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id TbDnQq6UTpwK for <>; Tue, 1 Feb 2011 23:44:50 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id E50763A6CBE for <>; Tue, 1 Feb 2011 23:44:49 -0800 (PST)
Received: from senmx11-mx ([] []) by with ESMTP id BT-MMP-3238393; Wed, 2 Feb 2011 08:48:07 +0100
Received: from (unknown []) by senmx11-mx (Server) with ESMTP id 548BB1EB82AB; Wed, 2 Feb 2011 08:48:07 +0100 (CET)
Received: from ([]) by ([]) with mapi; Wed, 2 Feb 2011 08:48:07 +0100
From: "Elwell, John" <>
To: "" <>, "" <>, "" <>
Date: Wed, 2 Feb 2011 08:48:06 +0100
Thread-Topic: Resolving SIP/XMPP URIs
Thread-Index: AQHLwgeGeNM0i3/v7kqPya3/zXRKm5Pt1IaA
Message-ID: <>
References: <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
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-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." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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.


> -----Original Message-----
> From: [] 
> Sent: 01 February 2011 12:00
> To: Elwell, John;;
> 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