[Standards-JIG] Roster block importing and synchronisation using JEP-0093

Mike Albon mikea at yuri.org.uk
Tue Sep 14 21:40:18 UTC 2004


Tijl,


> That's Tijl actually (some fonts will do that to you).

Oops sorry. :) I think it may have been me not reading closely enough.

> > Ok, I may be being naive or just plain dumb, but could you illustrate
> > this case as I don't understand what you are driving at here. Other than
> > to say if there was an item on the roster, then the client would 'auto-
> > prune' it.
> 
> Your goal is that when remove a contact while you use the legacy client,  
> it gets removed when log into Jabber using the transport right? You  
> propose doing this by having the transport send "unsubscribe" and  
> "unsubsribed". That will lead to the user still having a contact on his  
> list.

No I wouldn't say that was my goal. I was assuming that deleted contact
behaviour worked the same way as it does currently with jabberd1.4.
(Rule #1 again) 

Certainly a 'none' item in the roster should trigger some client event,
like a 'you have zombies' dialogue? 

Is this 'none' item behaviour demonstrable with an existing server
implementation?

> No client should automatically delete such a contact it were a normal  
> contact. For example let's say I accidently delete you from my roster.  
> That means I get set to "none" in your roster. If your client  
> automatically deletes that contact (just cause it's "none") it means you  
> have no way of getting back to me. You don't want *me* to have that kind  
> of control over your roster do you?

Agreed. That is quite sound logic. However are you not notified the same
way as a subscribe to an unsubscribe event? Whether or not it happened
in the past? i.e. isn't it queued, like a pending subscription?

As far as I understood subscriptions and how the effected presence, if I
send an 'unsubscribed' disallows you to see my presence. If I send an
'unsubscribe' I am requesting not to see your presence.


> A reason for when I want a contact deleted automatically from my roster,  
> is when I *already* deleted when I was using my legacy client. In your  
> proposal there is no way to distinguish between a "sync" (the transport  
> telling you: "You deleted this contact already") and a normal case of the  
> contact on the other legacy network removing you from their roster. So  
> "smart" clients wouldn't know what to do either.

No that is true. It comes down to a matter of scale. While I am not
saying that you don't have a point, how many people are going to
significantly change their roster between jabber sessions? 

The importing seemed extreemly rational, and then manipulation and
importing of new contacts between sessions by virtue of solving the
initial import are also solved for free. I know this isn't entirely
clean, it isn't a 'hack', it is another assumption.

This is first pass, so hopefully something will fall into place here.

> Like I said, it's no issue if you don't mind having "ghost" contacts on  
> your list. Without changes this would be the case with every client  
> anyway, but even attempts to makes clients "smarter" couldn't work without  
> changing this protocol.

I think that really depends on what a client is expected to do with a
'none' item in the roster. You could say a generic solution to that
problem may be better

> > As it happens I have had a similar experience in part with people de-
> > registering and not unsubscribing their contacts. Each time they log in
> > they send lots of probe presences which I have been tempted to reply to
> > with an 'unsubscribed'.
> 
> That would be allowed...
> 
> >> Also, JEP-0093 doesn't define what a client should do if it chooses not  
> >> to
> >> "accept" a contact/item in the list. I assume it does nothing, rather  
> >> then
> >> send unsubscribe and unsubscribed presence stanzas to it. Do you really
> >> want people to know you rejected to put them on your list?
> >
> > Yes, guilty as charged. Looks like I broke rule #1 - Always state your
> > assumptions.
> >
> > I did assume that the unhandled items would be handled at the next login
> > by more prompting of the user, with a jabber:x:roster under the post
> > roster updating case.
> 
> Would you suggest doing that by JEP-0093 or by sending a subscription  
> request? (not sure what you mean exactly)

OK, I need to work on that bit then. :) 

How I had envisaged it was that all 'out of jabber' added contacts would
be sent via the jep-0093 and the mechanism previously suggested. All
pending contacts not enacted apon would be added using the normal add
contact use case.

I do appreciate the comments that have been put into your replies, and
the effort James has spent on documenting his own preffered solution. I
personally don't agree with his approach, hense my proposal, but the
fundamental thinking and observations behind it are clear and useful.

Regards

Mike





More information about the Standards mailing list