Re: [xmpp] 3921bis: probe + unavailable

Jonathan Schleifer <js-xmppwg@webkeks.org> Sun, 31 January 2010 01:41 UTC

Return-Path: <js-xmppwg@webkeks.org>
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 7BD1A3A683D for <xmpp@core3.amsl.com>; Sat, 30 Jan 2010 17:41:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.000, 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 GeNUMBwYAfJ5 for <xmpp@core3.amsl.com>; Sat, 30 Jan 2010 17:41:32 -0800 (PST)
Received: from webkeks.org (webkeks.org [IPv6:2a01:170:103b::1]) by core3.amsl.com (Postfix) with ESMTP id 30E0A3A67A8 for <xmpp@ietf.org>; Sat, 30 Jan 2010 17:41:32 -0800 (PST)
Received: from avalon.webkeks.org (avalon.webkeks.org [192.168.1.12]) (Authenticated sender: js) by webkeks.org (Postfix) with ESMTP id 75C19DA4D; Sun, 31 Jan 2010 02:41:57 +0100 (CET)
Message-Id: <310544DA-9BBF-4824-B170-4A188B8EEFF1@webkeks.org>
From: Jonathan Schleifer <js-xmppwg@webkeks.org>
To: Jonas Lindberg <jonasl@google.com>
In-Reply-To: <a74e91db1001301429g6c69bc10xddfc3a59baf2ac5b@mail.gmail.com>
Content-Type: text/plain; charset="US-ASCII"; format="flowed"; delsp="yes"
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v936)
Date: Sun, 31 Jan 2010 02:41:54 +0100
References: <4B6202CF.6070702@stpeter.im> <14795.1264714828.295077@puncture> <42E4D3A6-6F8A-4005-8563-18F8CF934971@webkeks.org> <4B62F78E.1030400@stpeter.im> <12A2144C-5AEB-44B4-BFC6-C8D8DC66CC3E@webkeks.org> <4B63609C.2000702@stpeter.im> <1764944E-D3E1-4BD5-BAF2-D84380983438@webkeks.org> <a74e91db1001301429g6c69bc10xddfc3a59baf2ac5b@mail.gmail.com>
X-Mailer: Apple Mail (2.936)
Cc: XMPP <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: Sun, 31 Jan 2010 01:41:33 -0000

Am 30.01.2010 um 23:29 schrieb Jonas Lindberg:

> While I agree this would simplify the protocol a little, I am not  
> convinced it is a change worth making.
>
> First of all, not responding to probe when unavailable is a pretty  
> good optimization. A large part of Xmpp traffic is presence. This  
> change would further significantly increase the presence traffic,  
> making scaling more challenging and adding load to c2s and s2s  
> connections. For example, a cell phone xmpp client may be better off  
> not getting potentially thousands of presence unavailable stanzas  
> for offline friends when connecting over gprs.
>
> I'm also not convinced this change make it significantly easier to  
> implement xmpp clients/servers. Especially if we are going to  
> recommend that clients and servers SHOULD cope with no response for  
> legacy reasons.

I think you got something wrong here: We are not talking about what  
happens when you connect. We are talking about presence probes sent  
from one client to a server. A mobile client would not get any  
unavailable presence more than it would get now, expect it requests it  
by doing a probe.

--
Jonathan