IETF Logo Mail Archive

[xmpp] presence subscriptions + desync

Philipp Hancke <fippo@mail.symlynx.com> Thu, 16 July 2009 19:28 UTC

Return-Path: <fippo@mail.symlynx.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 EF6CF3A6DD2 for <xmpp@core3.amsl.com>; Thu, 16 Jul 2009 12:28:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.089
X-Spam-Level:
X-Spam-Status: No, score=-2.089 tagged_above=-999 required=5 tests=[AWL=0.160, BAYES_00=-2.599, HELO_EQ_DE=0.35]
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 Ym8P-0FZpKyS for <xmpp@core3.amsl.com>; Thu, 16 Jul 2009 12:28:32 -0700 (PDT)
Received: from lectern.tobij.de (lectern.tobij.de [62.75.216.40]) by core3.amsl.com (Postfix) with ESMTP id EECAF3A6DCE for <xmpp@ietf.org>; Thu, 16 Jul 2009 12:28:31 -0700 (PDT)
Received: from [192.168.2.21] (p579DD765.dip.t-dialin.net [87.157.215.101]) (authenticated bits=0) by lectern.tobij.de (8.14.0/8.14.0) with ESMTP id n6GJT0K2025098 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <xmpp@ietf.org>; Thu, 16 Jul 2009 21:29:03 +0200
Message-ID: <4A5F7F77.2000608@mail.symlynx.com>
Date: Thu, 16 Jul 2009 21:28:55 +0200
From: Philipp Hancke <fippo@mail.symlynx.com>
User-Agent: Thunderbird 2.0.0.22 (Windows/20090605)
MIME-Version: 1.0
To: xmpp@ietf.org
Content-Type: text/plain; charset="ISO-8859-15"; format="flowed"
Content-Transfer-Encoding: 7bit
Subject: [xmpp] presence subscriptions + desync
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, 16 Jul 2009 19:28:33 -0000

section 3.1.2 in 3921bis states:
| If the contact does not approve or deny the subscription request
| within some configurable amount of time, the user's server SHOULD
| resend the subscription request to the contact based on an
| implementation-specific algorithm

This change shifts the responsibility for error detection and handling
from client (rfc 3921, 8.2 step 5) to the server (smart servers!).
Why was this responsiblity shifted? Actually, are there clients that
implement the "old" version? Those that I tested did simply ignore the
error...

Resending the subscription request as proposed is hardly an option. If
the contact is offline for some weeks, the user's server will try to
resend for quite a number of times, without any necessicity.
The main problem is IMO that the <presence type=subscribe/>
lacks a immediate acknowledgment by the contact's server.
The acknowledgment is only sent after user interaction.
Is that because the subscription protocol predates the concept
of a "remote server"?

A possible solution is to provide a preliminary acknowledgement
for that request by sending an unavailable presence:
<presence from='contact@example.org' to='user@host'
           type='unavailable' id='subscription1' />
This implies that the contact is technically reachable, and - if the
original subscription request was tagged with an id attribute - is
an cheap alternative for an iq-based request response protocol.
Stop resending if you receive this ack.

A similar argument applies to <presence type='unsubscribed'/>, for which
there should be an acknowledgment as well.

philipp

v2.23.0 | Report a Bug | By Email