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

Tijl Houtbeckers thoutbeckers at splendo.com
Tue Sep 14 23:27:00 UTC 2004

On Tue, 14 Sep 2004 22:40:18 +0100, Mike Albon <mikea at yuri.org.uk> wrote:

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

Not sure what you mean here. Jabberd 1.4 doesn't do anything special with  
contacts in your roster with "none". I know of one client (Exodus) that  
have an option when you delete a contact "force this person to remove me  
 from their roster". That doesn't quite work though.

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

Not all clients to. In fact I wouldn't know one (didn't look *that* hard  
though), maybe Exodus cause it has that option, but it didn't work when I  
tried (maybe it's a setting somewhere). When someone removes your  
subscription to them (that could cause it to go to "none" or "from") most  
clients will notify you though.

Think about it. Why would you want someone to disappear from your roster  
just because they deleted you? I just want to be notified when they remove  

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

I have 'em in my roster as we speak (Jabberd 1.4). The only way to get  
someone out of your roster is a jabber:iq:roster query. XMPP IM also  
treats this as normal.

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

If someone deletes you from the roster some client will warn you, yes. Psi  
does this in a way simulair to when you get subscribed. My current version  
of Exodus does nothing at all (it keeps showing my contact in the status  
it was in before I deleted it till I log out)

> Whether or not it happened
> in the past? i.e. isn't it queued, like a pending subscription?

Not sure what you mean.. but the unsubscription packet always looks the  
same. So if use my legacy client to delete a contact, how does your  
transport communicate (using existing protocol) to a jabber client that  
the contact on my list should be deleted? And not just set to a "none"  
contact, as I'd *want* to happen when I'm using the transport and someone  
on the legacy network removes me from the roster. For that matter.. how  
will the user know the difference, other than remembering by rememnering  
the state of his roster?

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

That's correct, except that "unsubcribe" isn't a request (any server that  
handles this MUST stop the presence subscription).

It a common practise to send back "unsubscribed" to this (which makes it  
seem like a request), and I think jabberd1.4 actually waits till the  
remote server sends this (automated in Jabberd 1.4) before changing the  
subscription status. That is not XMPP behaviour though!

I think the most important issue is, when I delete a contact on the legacy  
network, and then use jabber and a transport, I want that contact to be  
gone from my list. Whether it's state is "both", "from", "to" or "none",  
it won't be online anyway. I just want it out of my list. (Ofcourse for  
transports (cause of the probes) "none" is much preferred.)

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

For example, people who switch between Jabber and a legacy network. We  
have several thousands of those users.

But like I said, if we make this into a decent protocol there can be  
plenty of other usecases. For example, let's say you're in a long running  
multiplayer game on a website that has some Jabber interaction. This way  
the Jabber "gateway" could automatically add players you're temporarly  
working with there, and remove them again when you've removed them in the  

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

well, I think it is a good protocal for doing initial imports of contact  
using existing protocol. Adding new contacts will work too. However, I  
think what most users want is an *automatic* import. And on top of that  
some users will really like their rosters to stay synchronized too,  
without getting any ghost contacts.

None of this will be accomplished by this proposal, or any other other  
proposal, without modifying clients (or servers). Proper synching will  
always require new work on protocols. On top of that far from all clients  
already support jabber:x:roster, and that backwards compatibility should  
not be the *deciding* factor when developing new specifications..

> 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

If you're saying client shouldn't have "none" contacts, you're effectivly  
argueing that if you have me in your roster, I can delete myself from  
that. I think even the legacy networks don't allow that. "none" contacts  
are valid contacts. Maybe you just want to look at your vCard sometimes  
after I deleted you from my roster. Maybe you decide your roster is too  
big and delete me from yours (making you a "none" contact in my roster),  
and I decide I'll just request subscription again when I have something  
important to say. If I keep the "none" contact, that's very easy to do.

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

The good thing about your protocol is it works for the intial import  
(including the meta-data), and "new" contacts later on (including the  
meta-data), all with existing protocols and some existing clients. Thus, I  
see no problems with using it for that.

It still doesn't do this very automated, and the "flow" won't be optimal  
in current clients. The interface will let clients *not* add certain  
contacts (and make that seem like a good thing) which could lead to  
confusing behaviour for the user, unless you're willing to tolerate a  
security risk.

Then there is the roster-subsync proposal. A new protocol, this does  
everything correctly, and can be completly automatic if it's supported by  
the client. This includes *full* synchronization, including removal. Also,  
if you implement roster-subsync on the transport, you've automatically  
also implemented a system that (with the proper, manual interaction from  
the user) will work for *every* client, you just don't get the meta-data.

Could you make a system based around JEP-0093 and <message/> that achieves  
the same thing? Sure.. but I don't think the protocol will be more  
elegant, and I don't believe it will be easier to implement, not even for  
clients already supporting JEP-0093.

If as a transport author also want to support clients that support neither  
JEP-0093 nor roster-subsync, roster-subsync will *definetly* be less work.  
However, once you've implemented roster-subsync you already have a lot  
done for adding your proposal.

That's why I think your proposal should stick to what it is now, a  
documentation on how to use JEP-0093 to help a client that does not  
support roster-subsync but does do JEP-0093 to import new contacts. You  
won't have to mention the security problem or the "semi"-removal you do  
now, since any roster-subsync supporting transport will take care of that,  
even for clients that don't support roster-subsync (or JEP-0093 for that  
matter) at all.

More information about the Standards mailing list