IETF Logo Mail Archive

Re: [xmpp] 3921bis: probe + unavailable

Jonas Lindberg <jonasl@google.com> Tue, 02 February 2010 10:08 UTC

Return-Path: <jonasl@google.com>
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 3D10928C154 for <xmpp@core3.amsl.com>; Tue, 2 Feb 2010 02:08:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -104.644
X-Spam-Level:
X-Spam-Status: No, score=-104.644 tagged_above=-999 required=5 tests=[AWL=1.334, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_MED=-4, 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 JBMAJGm6eGgl for <xmpp@core3.amsl.com>; Tue, 2 Feb 2010 02:08:44 -0800 (PST)
Received: from smtp-out.google.com (smtp-out.google.com [216.239.33.17]) by core3.amsl.com (Postfix) with ESMTP id 2949828C0F3 for <xmpp@ietf.org>; Tue, 2 Feb 2010 02:08:43 -0800 (PST)
Received: from spaceape12.eur.corp.google.com (spaceape12.eur.corp.google.com [172.28.16.146]) by smtp-out.google.com with ESMTP id o12A9KQE014375 for <xmpp@ietf.org>; Tue, 2 Feb 2010 10:09:20 GMT
DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=google.com; s=beta; t=1265105360; bh=jvBWtKm/u5fG5IOQn48ebL15WEc=; h=MIME-Version:In-Reply-To:References:From:Date:Message-ID:Subject: To:Cc:Content-Type:Content-Transfer-Encoding; b=qIfi6i/zBle+M2W73Y+Q5zBCbkF/y6mrQuKJPAcm0Hn93BN77bp8W9qEFoIQ9oW5o g4K7ksi4RGSCXEvtSYOVw==
DomainKey-Signature: a=rsa-sha1; s=beta; d=google.com; c=nofws; q=dns; h=mime-version:in-reply-to:references:from:date:message-id: subject:to:cc:content-type:content-transfer-encoding:x-system-of-record; b=U96mh6PLs3gpFOFwT8qAEnTMKg6Rgybc8GuIzUZ/ydO38t3Me1T3kBF2PzbAS+ttx uHWArdKPbV0IoPIMe/Gxw==
Received: from ywh13 (ywh13.prod.google.com [10.192.8.13]) by spaceape12.eur.corp.google.com with ESMTP id o12A9ITx007915 for <xmpp@ietf.org>; Tue, 2 Feb 2010 02:09:19 -0800
Received: by ywh13 with SMTP id 13so1614736ywh.26 for <xmpp@ietf.org>; Tue, 02 Feb 2010 02:09:18 -0800 (PST)
MIME-Version: 1.0
Received: by 10.150.128.21 with SMTP id a21mr8301455ybd.24.1265105358147; Tue, 02 Feb 2010 02:09:18 -0800 (PST)
In-Reply-To: <201002011703.36954.justin@affinix.com>
References: <4B6202CF.6070702@stpeter.im> <952A4B1F81123B479292D4B5FDC00D8503BA5E39@SRV-EXSC03.webex.local> <4B673DBC.1020406@stpeter.im> <201002011703.36954.justin@affinix.com>
From: Jonas Lindberg <jonasl@google.com>
Date: Tue, 02 Feb 2010 11:08:58 +0100
Message-ID: <a74e91db1002020208t7b591281yc84c7c5d193d70e2@mail.gmail.com>
To: Justin Karneges <justin@affinix.com>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
X-System-Of-Record: true
Cc: xmpp@ietf.org
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: Tue, 02 Feb 2010 10:08:45 -0000

Peter's new proposal sounds good to me.

A few more comments inline below:

On Tue, Feb 2, 2010 at 2:03 AM, Justin Karneges <justin@affinix.com> 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 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.

I wouldn't want to change the default behavior in a way that breaks
the user experience on clients that work well today.

> 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.
>
> 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'd prefer continuing to treat these as one in the spec to keep it
simple. I also would not want it to be a MUST for (1).

> -Justin
> _______________________________________________
> xmpp mailing list
> xmpp@ietf.org
> https://www.ietf.org/mailman/listinfo/xmpp
>

v2.23.0 | Report a Bug | By Email