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

Emil Ivov <emcho@sip-communicator.org> Thu, 17 March 2011 22:12 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 EC6923A6A62 for <sixpac@core3.amsl.com>; Thu, 17 Mar 2011 15:12:11 -0700 (PDT)
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 4E6esGSHmfWZ for <sixpac@core3.amsl.com>; Thu, 17 Mar 2011 15:12:10 -0700 (PDT)
Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id 89C493A69E5 for <sixpac@ietf.org>; Thu, 17 Mar 2011 15:12:10 -0700 (PDT)
Received: by wyb42 with SMTP id 42so3568641wyb.31 for <sixpac@ietf.org>; Thu, 17 Mar 2011 15:13:38 -0700 (PDT)
Received: by 10.216.181.76 with SMTP id k54mr1447391wem.58.1300400018263; Thu, 17 Mar 2011 15:13:38 -0700 (PDT)
Received: from porcinet.local (shm67-5-88-165-90-188.fbx.proxad.net [88.165.90.188]) by mx.google.com with ESMTPS id o23sm922770wbc.44.2011.03.17.15.13.36 (version=TLSv1/SSLv3 cipher=OTHER); Thu, 17 Mar 2011 15:13:37 -0700 (PDT)
Message-ID: <4D82878F.8010102@sip-communicator.org>
Date: Thu, 17 Mar 2011 23:13:35 +0100
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.15) Gecko/20110303 Thunderbird/3.1.9
MIME-Version: 1.0
To: Peter Saint-Andre <stpeter@stpeter.im>
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>
In-Reply-To: <4D82732D.507@stpeter.im>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
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 22:12:12 -0000

На 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?

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?

Emil