Re: [sixpac] SIP AOR/GRUU discovery for offline XMPP contacts.

Peter Saint-Andre <stpeter@stpeter.im> Thu, 17 March 2011 23:37 UTC

Return-Path: <stpeter@stpeter.im>
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 1D39E3A6B42 for <sixpac@core3.amsl.com>; Thu, 17 Mar 2011 16:37:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.604
X-Spam-Level:
X-Spam-Status: No, score=-102.604 tagged_above=-999 required=5 tests=[AWL=-0.005, 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 mr7zc6IUlkDr for <sixpac@core3.amsl.com>; Thu, 17 Mar 2011 16:37:25 -0700 (PDT)
Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 65D583A6A77 for <sixpac@ietf.org>; Thu, 17 Mar 2011 16:37:25 -0700 (PDT)
Received: from squire.local (dsl-251-69.dynamic-dsl.frii.net [216.17.251.69]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id 2C9544006D; Thu, 17 Mar 2011 17:39:32 -0600 (MDT)
Message-ID: <4D829B8C.4000809@stpeter.im>
Date: Thu, 17 Mar 2011 17:38:52 -0600
From: Peter Saint-Andre <stpeter@stpeter.im>
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9
MIME-Version: 1.0
To: Emil Ivov <emcho@sip-communicator.org>
References: <4D792A10.4030506@sip-communicator.org> <F9E2FDAF48D4544F874A56A3A8BD68B1010AF1F1@008-AM1MPN1-002.mgdnok.nokia.com> <4D79E104.1030207@sip-communicator.org> <4D825BE8.3060301@stpeter.im> <4D8269EC.6020209@sip-communicator.org> <4D82732D.507@stpeter.im> <4D82878F.8010102@sip-communicator.org>
In-Reply-To: <4D82878F.8010102@sip-communicator.org>
X-Enigmail-Version: 1.1.1
OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha1; boundary="------------ms020501040503030401030003"
Cc: sixpac@ietf.org
Subject: Re: [sixpac] SIP AOR/GRUU discovery for offline XMPP contacts.
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, 17 Mar 2011 23:37:27 -0000

On 3/17/11 4:13 PM, Emil Ivov wrote:
> На 17.03.11 21:46, Peter Saint-Andre написа:
>> On 3/17/11 2:07 PM, Emil Ivov wrote:
>>>
>>>
>>> На 17.03.11 20:07, Peter Saint-Andre написа:
>>>> On 3/11/11 1:44 AM, Emil Ivov wrote:
>>>>> Hey Simo,
>>>>>
>>>>> На 11.03.11 08:43, Simo.Veikkolainen@nokia.com написа:
>>>>>>> Would it make sense to also allow uploading and retrieving that
>>>>>>> kind of information within a vCard? Of course, if available,
>>>>>>> information in a presence or a message stanza should always take
>>>>>>> precedence.
>>>>>>
>>>>>> This approach might be most straightforward. See
>>>>>> http://xmpp.org/extensions/xep-0054.html which I believe will be
>>>>>> superseded by http://xmpp.org/extensions/xep-0292.html
>>>>>
>>>>>
>>>>> Right, I was also thinking about them and I guess all that we need to do
>>>>> is indicate the elements where the AOR/GRUU would need to be stored and
>>>>> retrieved from.
>>>>
>>>> Would we use the vCard4 IMPP property for this?
>>>
>>> Syntax-wise it looks right. Semantically RFC 4770 seems to be declaring
>>> it as an IM or a presence address only.
>>>
>>> So I am wondering if this could be source of confusion for non-sixpac
>>> clients.
>>>
>>> An example on page 2 seems to explicitly point that a SIP uri would be
>>> used for SIMPLE chats and presence, and it is my understanding that most
>>> sixpac clients would be unreachable this way.
>>
>> You have a point.
>>
>> Perhaps the TEL property is appropriate, instead:
>>
>> http://tools.ietf.org/html/draft-ietf-vcarddav-vcardrev-16#section-6.4.1
> 
> It seems to come with a "*" cardinality so how would one distinguish
> between the sixpac SIP uri and the regular phones? Do we define a new
> scheme?

Do you mean that we'd need a new URI scheme to identify sixpac-aware SIP
UAs? That seems unnecessary.

However, we could define a vcard extension for a special property.

> Also, I am not sure how to read the following:
> 
>     It is expected that the URI scheme will be "tel", as
>     specified in [RFC3966]
> 
> Does this mean that use with URI other than "tel" should be avoided?

I see no reason why a "sip" URI would be problematic, but we can ask the
vcard folks about that.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/