This crossposting is hell. On Fri, 13 Feb 2009 11:52:19 +0100 Alexander Gnauck <[email protected]> wrote:
> > Thats an very interesting point - in many respects. Two more > > examples: > > - I have a service with many users from other servers subscribed. > > As there is no unsubscribe if the user has been deleted, I have > > many "zombie"-subscription. I can only check the subscriptions from > > my own server if the accounts still exist. And even that is not so > > easy. > > - A friend subscribed my presence. He was some time in hospital, so > > I never noticed, that his account was deleted on the server (due to > > inactivity?). As the jid came back online I wrote him gladly, how > > he is after the surgery... I realised very late, that the account > > was now new assigned. > > I had a similar problem when I unregistered my jabber.org account by > error with a beta version of a client. The subscription was out of > sync, and still is for > many of my contacts, because server don't route my subscription > requests. The only solution is to delete the contact on both sides > and subscribe again. I had similar problems in other scenarios too... > > I see only the solution, that there has to be an > > unsubscribe-request to every contact in the roster of an user if > > that user is going to be deleted. > > right, this is how it should (MUST) be done. This does not help enough (though it catches the easiest cases). I believe the subscription stuff in XMPP should be further re-thinked. There are many real-world cases that break integrity of subscriptions across servers. * User delete * Server switch (if you're not careful enough about the database) * User grants subscription without being asked (I believe this is an implementation issue) * Some important <presence/> stanza gets lost due to lost connection * Various server errors (happenes once, but the integrity is lost) * Other cases I believe the only way is to implement some sort of auto-correction that occures upon any sort of interaction. E.g. the server could check the subscription when the following suspicious (though many times valid) events occur. * You got a <presence/> from someone you're not subscribed to * You got a <message/> (or <iq/>) from someone you're subscribed to but you haven't got his presence * User tries to subscribe to someone he's already subscribed (and similar) * Of course, user deletion should trigger unsubscribe, but it would be better to distinguish it from regular unsubscribe. It would also be good to have some sort of redirection support that would allow an account to be in a state between registered and nonexistant. Could be as simple as a <redirect/> element in any error answers. Supporting clients could then offer the user to *delete* the contact or *replace* the contact with his new ID, request subscription and retain group, local name and comments. Pavel > > Alex > > -- > Alexander Gnauck > http://www.ag-software.de > xmpp:[email protected] -- Freelance consultant and trainer in networking, communications and security. Web: http://www.pavlix.net/ Jabber, Mail: pavlix(at)pavlix.net OpenID: pavlix.net -- Freelance consultant and trainer in networking, communications and security. Web: http://www.pavlix.net/ Jabber, Mail: pavlix(at)pavlix.net OpenID: pavlix.net
