[Standards] XMPP-IM - presence subscription handling

Pavel Simerda pavlix at pavlix.net
Wed Feb 25 16:24:20 UTC 2009

On Tue, 24 Feb 2009 21:32:27 +0100
Jiří Zárevúcký <zarevucky.jiri at gmail.com> wrote:

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

Yes. That's because I am talking about the protocol.

The user interface may be easily fixed by client developers... and
possibly a very short Best Practice document.

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

I believe it is equally complicated to your proposal but more flexible.

From the client perspective, the current variant can work, according to
the specs:

Client A: [subscribed],[subscribe*]
Client B: [subscribed*],[subscribe*]

with some roster management stanzas around and A's server automatically
answering with [subscribed*].

(Hope I didn't do any mistake here, * denotes a more basic flow here,
if A's server doesn't respond - some IMO misinterpret the <presence
type="subscribed"/>, A's client does)

From user's perspective it's:

User A: Add contact B.
User B: Accept contact A (means to both grant subscription and add, of

Unfortunately, due to some server's not handling <presence

This seems perfectly correct and pretty easy to me.

> As for the problems you described, any
> inconsistency could just be reset to a clean no-subscription state.
> How often could this happen?

Too often to ignore. You cannot require users to reset it manually...
users don't care about protocols!

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

I don't believe it would simplify them significantly.

> Then look at the end-user client interface. I find it a bit
> unintuitive.

Go and file a bug report or feature request to your client's developer.

> 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 is simply not true.

> This has been considered in the specification
> by allowing preliminary approval, but that just adds need for the
> server to track this,

Which is very easy...

> and there is no way to tell if there is one. I

One what?

> would like a simple work-flow "Request presence sharing" - "Sharing
> approved, both are subscribed" / "Sharing declined, nobody is
> subscribed".

This usecase works well with the current specification

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

I haven't seen any.

> Cleaner protocol,

I don't think so.

> simpler implementation

I don't see the difference.

> and user interface much closer to the
> real-life needs.

And this is definitely your client's problem. 

> Just a question... did you ever need to have someone's subscription,
> while he must not have it?

Not yet.

> Or the other way around? 

Probably yes.

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

That seems unnecessarily complicated to me.

> User doesn't really care,
> whether a dictionary sees his presence or not.

User doesn't really care about protocol details either.

> If there is some
> paranoid user who does, he can use privacy lists.

Argh.... this seems to be overly complicated for me too.

I don't want to discourage you to think it through... you probably have
some good ideas...

But it would be much easier to read and to answer if you distinguish
between UI implementation details and protocol design.

Sure it might be tempting to build a protocol after UI design... but
does it really bring any advantage? Do you really need to break
something that works well just to gain no advantage (or advantages as
yet unknown)?




Freelance consultant and trainer
in networking, communications and security.

Web: http://www.pavlix.net/
Jabber, Mail: pavlix(at)pavlix.net
OpenID: pavlix.net

More information about the Standards mailing list