Subject: [xmpp] presence subscriptions + desync

From: Philipp Hancke <[email-masked]>
Date: Thu, 16 Jul 2009 21:28:55 +0200

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=[email-masked]' 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

---

From: Peter Saint-Andre <[email-masked]>
Date: Sat, 01 Aug 2009 00:11:18 +0200

> from client (rfc 3921, 8.2 step 5) to the server (smart servers!).

Not exactly, because nothing prevents the client from sending a
subscription request again, too. But in practice clients do not
automatically resend subscription requests, and I expect that end users
rarely use the manual "resend subscription request" feature in clients
like Psi (plus, many clients do not even include such a feature).

> implement the "old" version? Those that I tested did simply ignore the

Correct.

> resend for quite a number of times, without any necessicity.

Let's say that the user's server resends the subscription request once a
day while the contact is on vacation for five weeks (we'll assume that
the contact lives in Europe :P). That's 35 additional presence stanzas,
and such stanzas are extremely small. I don't see a huge network impact
here.

> The acknowledgment is only sent after user interaction.

Hey, let's change presence subscriptions to use IQ stanzas. But then
we'd ack every one and really add some stanzas to the network...

> Is that because the subscription protocol predates the concept

Certainly not -- Jabber technologies were never envisioned as a service
silo, even at the very beginning.

>           type='unavailable' id='subscription1' />

Presence leak! That's simply not going to fly.

> Stop resending if you receive this ack.

If we really think we need this, we'll need to define an ack other than
"unavailable", or specify the polling method that I described in the
text you quoted.

> there should be an acknowledgment as well.

"SHOULD" on what basis? If the "unsubscribed" from the contact never
reaches the user, the user's server will send a presence probe to the
contact when the user comes online, and the contact's server will answer
that probe with "unsbuscribed" (because according to the contact's
server the user is not subscribed to the contact). This will happen
every time that the contact comes online. I rather doubt that the
connectivity from the contact's server to the user's server will be so
fubar'd that none of these "unsubscribed" stanzas will ever be passed
over the s2s link (and if that is the case, there are bigger problems
than subscription state synchronization). Therefore I don't think that
we would ever need to ack "unsubscribed".

Therefore I conclude that the only direction we need to heal is the
outbound subscription from user to contact. Here the user (or the user's
server) can simply poll once in a while to make sure that the subscribe
request went through and will be answered at some point. No, it's not
beautiful and elegant, but it works with existing infrastructure without
presence leaks or new values of the presence 'type' attribute.

Peter

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