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

Yes.

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