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

Tijl Houtbeckers thoutbeckers at splendo.com
Tue Sep 14 19:20:15 UTC 2004

On Tue, 14 Sep 2004 19:33:36 +0100, Mike Albon <mikea at yuri.org.uk> wrote:

> Tiji,

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

> Thanks for the comments. :)
>> A gateway can't use presence packets to remove someone from the clients
>> roster. It can only set the subscription state to "none". This is  
>> because
>> in Jabber presence subscription related task are done in the presence
>> stanza, and roster related stuff with jabber:iq:roster infoqueries. The
>> only exception to this is when you remove a contact from your roster,  
>> then
>> the *server* will make sure the subscription state of that contact will  
>> be
>> set to "none".
> 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  

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?

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.

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.

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

More information about the Standards mailing list