Re: [xmpp] 3921bis: probe + unavailable

Peter Saint-Andre <stpeter@stpeter.im> Thu, 04 February 2010 01:36 UTC

Return-Path: <stpeter@stpeter.im>
X-Original-To: xmpp@core3.amsl.com
Delivered-To: xmpp@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6C2713A6985 for <xmpp@core3.amsl.com>; Wed, 3 Feb 2010 17:36:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.64
X-Spam-Level:
X-Spam-Status: No, score=-2.64 tagged_above=-999 required=5 tests=[AWL=-0.041, BAYES_00=-2.599]
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 ybyVtFt53h5Q for <xmpp@core3.amsl.com>; Wed, 3 Feb 2010 17:36:46 -0800 (PST)
Received: from stpeter.im (stpeter.im [207.210.219.233]) by core3.amsl.com (Postfix) with ESMTP id 52FA03A6859 for <xmpp@ietf.org>; Wed, 3 Feb 2010 17:36:46 -0800 (PST)
Received: from squire.local (dsl-251-115.dynamic-dsl.frii.net [216.17.251.115]) (Authenticated sender: stpeter) by stpeter.im (Postfix) with ESMTPSA id D5CFD40126 for <xmpp@ietf.org>; Wed, 3 Feb 2010 18:37:29 -0700 (MST)
Message-ID: <4B6A1644.4000208@stpeter.im>
Date: Wed, 03 Feb 2010 17:35:16 -0700
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.1.7) Gecko/20100111 Thunderbird/3.0.1
MIME-Version: 1.0
To: xmpp@ietf.org
References: <4B6202CF.6070702@stpeter.im> <952A4B1F81123B479292D4B5FDC00D8503BA5E39@SRV-EXSC03.webex.local> <4B673DBC.1020406@stpeter.im> <201002011703.36954.justin@affinix.com>
In-Reply-To: <201002011703.36954.justin@affinix.com>
X-Enigmail-Version: 1.0
OpenPGP: url=http://www.saint-andre.com/me/stpeter.asc
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha1"; boundary="------------ms030101080705080206030905"
Subject: Re: [xmpp] 3921bis: probe + unavailable
X-BeenThere: xmpp@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: XMPP Working Group <xmpp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/xmpp>, <mailto:xmpp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/xmpp>
List-Post: <mailto:xmpp@ietf.org>
List-Help: <mailto:xmpp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/xmpp>, <mailto:xmpp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 04 Feb 2010 01:36:47 -0000

On 2/1/10 6:03 PM, Justin Karneges wrote:
> On Monday 01 February 2010 12:46:52 Peter Saint-Andre wrote:
>> I understand that the MUST here is an imposition on servers. IMHO the
>> deterministic nature of the unavailable has many benefits, but I can see
>> why large service providers would prefer to return a stanza to the
>> probing user only if the contact is online. So I think it's good that we
>> discuss the tradeoffs here.
> 
> A large benefit is to prevent a jabber:iq:last storm.  We don't want there to 
> be any reason for a client to poll its entire roster.

I completely agree with that sentiment!

> I can see why a mobile client might not be interested in having that 
> information pushed at it on login, to reduce resource usage.  Jonas' 
> suggestion of making this a client-controlled option is probably best, but I 
> don't know what the default behavior should be.

Right now we have no protocol for management of account settings such as
this (although we could use ad-hoc commands, XEP-0050). I don't think we
want to introduce such a dependency now, at least not for core delivery
semantics.

> Also, there has been discussion in the past about sending presence only of 
> certain contacts, groups, etc, when mobile, so the solution for filtering out 
> unavailable presence might fit right in with that maybe.

Maybe. :)

> Another thing: this issue is actually two-part: 1) should remote servers reply 
> to probes if the contact is unavailable?  and 2) should the local server send 
> unavailable presence to contacts that just logged in?  Both of these have 
> resource usage implications, but only the second one impacts the client.

I agree with Jonas that these are so closely connected as to be worth
keeping together in the spec.

Peter

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