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
- Re: [sixpac] SIP AOR/GRUU discovery for offline X… Simo.Veikkolainen
- [sixpac] SIP AOR/GRUU discovery for offline XMPP … Emil Ivov
- Re: [sixpac] SIP AOR/GRUU discovery for offline X… Emil Ivov
- Re: [sixpac] SIP AOR/GRUU discovery for offline X… Peter Saint-Andre
- Re: [sixpac] SIP AOR/GRUU discovery for offline X… Emil Ivov
- Re: [sixpac] SIP AOR/GRUU discovery for offline X… Peter Saint-Andre
- Re: [sixpac] SIP AOR/GRUU discovery for offline X… Emil Ivov
- Re: [sixpac] SIP AOR/GRUU discovery for offline X… Peter Saint-Andre
- Re: [sixpac] SIP AOR/GRUU discovery for offline X… Emil Ivov