[Standards] XMPP-IM - presence subscription handling

Jiří Zárevúcký zarevucky.jiri at gmail.com
Tue Feb 24 20:32:27 UTC 2009

2009/2/24 Pavel Simerda <pavlix at pavlix.net>:
> It has some flaws. See my post about subscriptions, please.

I've seen them. The difference is you are looking at the problems from
the server perspective. I'm concentrating on the client perspective
and human interface itself.

>> Originally, I wanted to propose modifying roster pushes so they
>> contain all the state information (including eventual inbound
>> subscription request message), essentially leaving
>> subscription-managing presence stanzas only as the mean of requesting
>> the change, not presenting it to the other entity or the other
>> resources. Then one thing occured to me. Do we really need a separate
>> subscription handling for inbound and outbound presences? Users
>> generally don't want it separate. Users want mutual subscription. Is
>> there ever need to have one-side subscription?
> This would need a clean redesign. Not just a bunch of ideas.

What do you imagine under "clean redesign"?

>> Providing mechanism for just a mutual subscription, where there would
>> be only both-direction or pending or no subscription at all, would
>> immensely simplify things for both users and implementers.
> This would break things even further.... see my other post and consider
> what this change will do with the authority. Bidi-only association
> seems too simple to fit in the common needs IMO.

I see it the other way around. IMO the current way is too complicated
to fit in the common needs. As for the problems you described, any
inconsistency could just be reset to a clean no-subscription state.
How often could this happen?

>> Yes, I
>> agree that immediate effect would be increasing complexity and need of
>> additional effort to maintain backward compatibility. That would be a
>> tricky task, but I believe that with proper interoperability rules, it
>> would be possible to make transition relatively painless. I believe
>> that in a long run, such change would be a huge improvement.
> You'd need to know if the transition gives or takes.

First compare the protocol interface itself. My approach would
simplify new implementations significantly, once it is widely used.
Then look at the end-user client interface. I find it a bit
unintuitive. Also, the mutual subscription round-trips always annoy
me. You get the request, user approves and sends his request, contact
needs to approve again. This has been considered in the specification
by allowing preliminary approval, but that just adds need for the
server to track this, and there is no way to tell if there is one. I
would like a simple work-flow "Request presence sharing" - "Sharing
approved, both are subscribed" / "Sharing declined, nobody is

>> So, in case you are interested in this idea, I will continue with some
>> semantics I have on my mind. Otherwise, just tell me why do you think
>> it is not possible / feasible / wanted to implement it. I'm pretty
>> sure there is some hidden problem with this I don't realize. I suppose
>> many of you won't take me too seriously, since it would require too
>> massive change to the core protocol, but I'd appreciate if you thought
>> about it a bit. Thanks for any feedback.
> I believe it is impossible.
> But please provide your-words comparison.... and what it would bring. I
> might try to be the devil's advocate and add problems it would make :D.
> Pavel

I already stated the benefits. Cleaner protocol, simpler
implementation and user interface much closer to the real-life needs.

Just a question... did you ever need to have someone's subscription,
while he must not have it? Or the other way around? Now I'm talking
about human contacts. I never needed something like that. There are of
course automated services, that don't care about your presence, so it
is reasonable not to send any to cut down bandwidth. That could be
very easily done via an extension, that would allow discarding
unnecessary stanzas at the source server. User doesn't really care,
whether a dictionary sees his presence or not. If there is some
paranoid user who does, he can use privacy lists.

More information about the Standards mailing list