[Standards] XMPP-IM - presence subscription handling

Jiří Zárevúcký zarevucky.jiri at gmail.com
Wed Feb 25 17:14:40 UTC 2009

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

No, it can't, since behavior required for this is explicitly forbidden
by the specification. Also, implementing client's capabilities so
differently from the actual protocol makes a terrible mess.

>> 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
> course)
> Unfortunately, due to some server's not handling <presence
> type="subscribed"/>
> This seems perfectly correct and pretty easy to me.

Forbidden and not really a clean solution.

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

Read "Would it be so often for user to be bothered by vanishing of
subscription?". I really don't get the difference from current spec in
this area.

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

That's probably because you never tried.

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

I'm my 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.

Yet in practice, this is completely ordinary work-flow.

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

Preliminary approval.

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

Possible, but not really simple. Just thinking a moment about it gives
me a few possible problems.

>> I already stated the benefits.
> I haven't seen any.
>> Cleaner protocol,
> I don't think so.

Now I'm beginning to think you either have a very bad taste or haven't
read XMPP-IM at all. No offense intended.

>> simpler implementation
> I don't see the difference.

As I already told, you probably never written any.

>> and user interface much closer to the
>> real-life needs.
> And this is definitely your client's problem.

User interface is always constrained by the underlying protocol's
possibilities. That's not really a client's problem, is it?

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

It would move complication from the current protocol to the extension.
It wouldn't just pop up anywhere.
The "flexibility", you have been talking about, is completely useless
in more than 99% of real world usage. Don't you think it's an
unnecessary complication to define it in the core protocol, when it is
very simply possible separately?

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

User cares about client. Client can't dictate the community protocol.
Thus, user cares about protocol details.

>> If there is some
>> paranoid user who does, he can use privacy lists.
> Argh.... this seems to be overly complicated for me too.

Only a very little fraction of users would ever think of the
possibility of some dictionary forwarding your presences elsewhere.
That's a ridiculous idea.

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

How do you implement a remote desktop over SSH?

> 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)?

I stand for my previous arguments. The current subscription handling is a mess.
At the very least, it would probably stop developers from introducing
useless options to the user.
Who does it? For the XMPP everyone. Why? Protocol is built that way.
<= my personal opinion

More information about the Standards mailing list