Subject: Re: [xmpp] presence subscriptions + desync

From: Jiří Zárevúcky <[email-masked]>
Date: Sat, 01 Aug 2009 16:30:08 +0200

On 08/01/2009 12:11 AM, Peter Saint-Andre wrote:
>> 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.
>>      
> 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...
>    

Just out of interest...

Presence:

<presence type="subscribe" to="[email-masked]"/>

Total: 50 bytes

IQ:

<iq type="set" id="254"><query xmlns="urn:xmpp:subscription" 
type="subscribe" to="[email-masked]"/></iq>
<iq type="result" id="254"/>

Total: 134 bytes, increase of 84 bytes per request

Well, it's more than a double, but I doubt anyone would even notice.
How big share of traffic could possibly belong to subscription requests?

---

From: Jiří Zárevúcky <[email-masked]>
Date: Sat, 01 Aug 2009 21:04:14 +0200

On 08/01/2009 08:54 PM, Waqas Hussain wrote:
> 2009/8/1 Jiří Zárevúcky <[email-masked] 
> <mailto:[email-masked]>>
>
>
>     Just out of interest...
>
>
>     Presence:
>
>     <presence type="subscribe" to="[email-masked]
>     <mailto:[email-masked]>"/>
>
>     Total: 50 bytes
>
>     IQ:
>
>     type="subscribe" to="[email-masked]
>     <mailto:[email-masked]>"/></iq>
> That argument doesn't really apply. Compression pretty much reduces 
> the size difference to nothing. And such minor differences in size 
> have no real impact, thanks to the nature of packet switching 
> networks. The IQ reply though doubles the packet count.
>
> But as a counter argument, the IQ would happen just once, while the 
> subscription request may be resent more than once, until the contact 
> accepts or rejects it.
>
> That said, I think the current model is just fine, and changing it 
> would be much much more effort than it's worth.

Unless you count in how nicer would it look in the XML console (just 
joking ;)).

> What would IQs (or the presence based acks Philipp argued for) 
> achieve? Acknowledgement that the remote server received the request? 
> Stream management would do that just fine.

Indeed.

> --
> Waqas Hussain

---

From: Klaus Hartke <[email-masked]>
Date: Sun, 2 Aug 2009 17:24:06 +0200

2009/8/1 Jiří Zárevúcky <[email-masked]>:
>> What would IQs (or the presence based acks Philipp argued for) achieve?
>> Acknowledgement that the remote server received the request? Stream
>> management would do that just fine.
>
> Indeed.

<presence/> (and <message/>) stanzas are generally one-way -- except
if they generate an error. The *only* way to handle these errors is to
bubble them up to the user interface, regardless of what initiated the
stanza, because the corresponding code will already have "moved on".

On the other hand, code that sends an <iq/> request usually blocks and
waits for an <iq/> result/error, so the error can be handled by the
code itself and will not unconditionally be shown to the user. The
code can decide itself what to with the error, whether to show it to
the user, perform a different action or just ignore it.

I think it's be desirable to have this behavior for actions that can
fail. One-way stanzas should be used only if an action cannot fail or
if the initiator doesn't need to be informed. Replies to one-way
stanzas should be informational at most.

Just my two (euro)cents.

--K

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 03 Aug 2009 19:03:58 -0600

> stanzas should be informational at most.

In theory, yes.

Are you proposing a modification to the presence subscription protocol?

Peter

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

---

From: Philipp Hancke <[email-masked]>
Date: Wed, 05 Aug 2009 10:38:36 +0200

Peter Saint-Andre wrote:
> On 7/16/09 9:28 PM, Philipp Hancke wrote:
>> 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!).
> 
> 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).
>
>> Why was this responsiblity shifted? Actually, are there clients that
>> implement the "old" version? Those that I tested did simply ignore the
>> error...
> 
> Correct.

This - in combination with servers not handling subscription-related
errors - might well be responsible for >90% of the problems.

It might be worthwile to describe some presence subscription related
error flows in more detail - subscribe is probably the most important
one.

>> 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.
> 
> 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.

presence subscriptions don't have a big impact on the network anyway -
Matthias once said they make up 0.6 percent of all stanzas. And I think
it is even less than that.

>> The main problem is IMO that the <presence type=subscribe/>

Too much backward compat hassle. The current protocol is mostly fine.

>> Is that because the subscription protocol predates the concept
>> of a "remote server"?
> 
> Certainly not -- Jabber technologies were never envisioned as a service
> silo, even at the very beginning.

Neither was IRC, but then Jarko wrote killer.c :-)

>> 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' />
> 
> Presence leak! That's simply not going to fly.

[email-masked] is a bare JID. That stanza would be sent by the
contacts server when processing the inbound subscription request.

>> 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.
> 
> 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.

You don't need a new type value either, because the proposed ack is
uniquely identified by type=unavailable and the id attribute.

The polling method is good and should be used especially when an
error occured during the subscription mechanism (but not for error
cases where the user mistyped the host-part of the JID).

>> A similar argument applies to <presence type='unsubscribed'/>, for which
>> 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

Which might be hours or days later or might never happen at all.

> 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".

Sending unsubscribed already helps alot, yes.

> 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.

so does my proposal :-)

philipp

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 05 Aug 2009 06:05:27 -0600

> error flows in more detail - subscribe is probably the most important

Feel free. :) I probably won't have time to do that until Monday.

> it is even less than that.

Sounds about right.

> contacts server when processing the inbound subscription request.

Ah, I see, you meant the bare JID. That might work. Essentially that
tells the user "as far as you're concerned, the contact is offline right
now" (if that presence stanza is even delivered by the user's server to
the user's client).

> uniquely identified by type=unavailable and the id attribute.

I think that no clients use 'id' on presence, but naturally they are
free to do so if they want tracking.

> cases where the user mistyped the host-part of the JID).

Yes, that makes sense.

>> that probe with "unsubscribed" (because according to the contact's

That's the nature of presence. :) I really don't see much need for an
ack here, but if we defined one what would you propose?

>> presence leaks or new values of the presence 'type' attribute.

I think that unavailable from the bare JID would work fine as an ack for
subscribe. It would be interesting to map out some of the error cases.

Peter

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

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 05 Aug 2009 07:41:52 -0600

>> error flows in more detail - subscribe is probably the most important

<snip/>

> subscribe. It would be interesting to map out some of the error cases.

I was just thinking about this topic some more -- I think that for the
true error scenarios (bad hostname in the presence subscription request,
server not found, remote connection failed, etc.), it would be helpful
to define the appropriate conditions and strongly recommend inclusion of
the 'id' attribute for tracking purposes. These are really just the
regular old standard error cases, but perhaps it would be helpful to
spell them out for people. Then perhaps recommend unavailable presence
from the bare JID as an ack so that the user's server knows that the
contact's server now has responsibility for the subscription request. As
far as I can see, that would handle most of the current failure cases.

Peter

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

---

From: Justin Karneges <[email-masked]>
Date: Wed, 5 Aug 2009 09:08:30 -0700

> subscribe. It would be interesting to map out some of the error cases.

I don't know if we should address this here.  A lost subscription request is 
unfortunate, but then so is a lost message and we don't do anything about 
that.  Let XEP-198 take care of it.

-Justin

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 10 Aug 2009 15:36:06 -0600

> that.  Let XEP-198 take care of it.

Good point.

/psa