[Standards] XMPP-IM - presence subscription handling

Pavel Simerda pavlix at pavlix.net
Wed Feb 25 19:59:49 UTC 2009


On Wed, 25 Feb 2009 18:14:40 +0100
Jiří Zárevúcký <zarevucky.jiri at gmail.com> wrote:

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

Uh?

I'm afraid one of us must be very very mistaken then. As I read the
spec, it's not forbidden at all, on the contrary. I would like too see
something that shows I'm wrong.

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

Citation needed.

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

Vanishing of subscription is unrelated.

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

That doesn't prevent you from filing a bug report, does it? Pardon my
ignorance.

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

In practice, it is done, but I believe it is not needed.

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

It's not forbidden anywhere AFAIK.

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

I like my taste...

And I will not be as arrogant as you are... and will just say you
probably haven't read carefully and invented limitations that are not
there.

None taken :).

> >> simpler implementation
> >
> > I don't see the difference.
> >
> 
> As I already told, you probably never written any.
> 

You seem to use your arrogance instead of real evidence.

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

Your question is based on a premise that I don't believe (namely that
it applies to this case).

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

I will not answer questions that are based on doubtful premises.

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

And logical reasoning is locked in the cupboard, right?

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

It's already implemented, see the manual page of SSH and look for X
Forwarding.

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

Yes, your personal opinion.

Pavel

-- 

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