[Standards] XMPP-IM - presence subscription handling

Pavel Simerda pavlix at pavlix.net
Thu Feb 26 01:37:09 UTC 2009


On Thu, 26 Feb 2009 01:35:33 +0100
Jiří Zárevúcký <zarevucky.jiri at gmail.com> wrote:

> 2009/2/25 Pavel Simerda <pavlix at pavlix.net>:
> > 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.
> >
> 
> Sorry, you are right in this. I overlooked a part defining it as
> subject to configuration.
> I still think this can't be done without numerous problem.
> 

Ok, I might forget your bullying... and You might try to look again and
reconsider, with the rfc3920-1 and also the bis variants (as I will of
course do also, but I don't have so much time, you can imagine).

I recommend to finish this thread... and start a new one, rather
concentrating on the technical points and correct reasoning.

> For example:
> 
> You get an inbound request. You approve, believing that once you click
> "Approve", you are both subscribed. This can't be done, since you
> still depend on the other side to fulfill it's part of a "contract".
> If you wait for the other side to approve first, you are deadlocked if
> the other side implements the same behavior.
> 
> >> >> 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.
> >
> 
> Then I misunderstood you. What problems with the authority did you
> mean?
> 
> >>
> >> >> 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.
> >
> 
> Sure. It doesn't. It would still be closed as WONTFIX, since it can't
> be fixed.
> 
> >> >> 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.
> >
> 
> That's exactly my point.
> 
> >> >> 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.
> >
> 
> I meant that there is no way to figure out, whether the contact
> auto-approves my request before I actually send it. That's just a
> completely unimportant cosmetic flaw.
> 
> >> >> 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 :).
> >
> 
> If you don't consider writing twice as much code because of protocols
> "flexibility", making user interaction unreliable, being a valid
> reason, then I'm inventing limitations. Yes.
> 
> >> >> 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.
> >
> 
> Once I have time for changing my code to use protocol no one else
> uses, I'll send you a diff. Forgive me, if I consider you being
> arrogant in the first place. Even reducing number of possible states
> from nine to four IS a simplification. You simply ignore everything
> and generalize to "there is no difference".
> 
> >> >> 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).
> >
> 
> My question is purely rhetorical.
> 
> >>
> >> 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.
> >
> 
> What premises are that? I'm not aware of them.
> 
> >> >> 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?
> >
> 
> Right.
> 
> >> > 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.
> >
> 
> Ok, bad example.
> All I wanted to say is that client UI is dependent on the underlying
> protocol. You can separate it just like that.


-- 

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