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

Tijl Houtbeckers thoutbeckers at splendo.com
Wed Sep 15 18:13:34 UTC 2004

On Wed, 15 Sep 2004 17:06:32 +0100, Mike Albon <mikea at yuri.org.uk> wrote:

>> 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.
> I'm not disagreeing with you, I just haven't seen that behaviour. I sat
> and read my roster file (that was fun I can tell you), but I have no
> 'none' items in my roster. It maybe because it has remained relatively
> static for a long time.

Well, have someone put you on their roster, then remove you, and see what  
happens. What client are you using? Maybe it hides them.

>> 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.)
> So we were talking cross purposes. You've sort of confused me on your
> position. Sometimes you mention you wish to have a haunted roster (which
> ghosts or 'none' items)

An item is only a "ghost" item as far as I'm concerned when I've already  
deleted it. For the rest I've called them "none" contacts, and explained  
they can have a legitemate persons.

I have items in my roster from contacts I deleted using legacy clients,  
though probably that is because of different implementation issues, since  
implementations work differently now. So I'd like to avoid such issues in  
the future.

> and yet you are advocating auto-removal of items
> that have been removed on the legacy roster.

I've *already* deleted these.

> What happens when the
> legacy service has such poor semantics that items just disappear from a
> roster because thats the way it handles it?

That would be a specific issue of that legacy network. Do you know any? If  
there is no way for a transport to find out wether a contact was removed  
cause of bad design or cause the user did it, an implementor *could*  
choose to take that into account.

>> 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
>> game.
> Yeah I also agree it could be nice generic, but for a game I thought
> Shared Rosters was being mooted for that application. (I'd love to see
> Stars! for xmpp).

This is a very simple protocol, not for sharing rosters, but for synching  
your own personal(ized) roster to your Jabber roster. If you have a game  
structure where 1 roster is shared with many people, it would make more  
sense to use Shared Rosters, a distrubuted PubSub architecture and what  

> You have a nice user population for testing if you have thousands of
> users. Luxury.

Well, I don't know the game, but if you have a personalized roster in it,  
you can see how this will work. I certainly wouldn't want to clean up  
"ghost" contacts every time I finish a game.

Another example for roster-subsync: a gateway that automatically adds  
contacts to your roster when they are in your proximity. Preferably with  
an anonymized JID ofcourse. When you get out of range it could remove the  
contact, but you might want to put in your prefs that any contact you  
exchanged a certain number of messages with will stay in there for a while  
or be put to "none" so you don't loose the contact.

What about a Jabber dating service that automatically puts available puts  
people that are available and match your critera into a group of your  
roster? (this is where you could imagine some use-cases with the "from"  
and "to" sunscriptions too).

And that's just me thinking up cool stuff we could do with this from the  
top of my head.. who knows what great ideas someone else will come up  
with? (maybe the JEP should reflect this a bit, since I'm not sure if you  
should call these things "legacy" services)

This isn't gonna work with your current proposal I'm afraid, and while it  
*could* work with Shared Roster groups (though not with the current  
proposal), I think that's not just overkill. I also think it's not a good  
match of technologies. PubSub was not meant to have a whole bunch of items  
that are secret, have 1 publisher, 1 subscriber and nothing else, used to  
send presence subscriptions. Shared Roster groups shines at what it's  
meant for, *sharing* a group of peolpe on your roster with others.

>> 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..
> That is ultimately the main thrust. People change their clients more
> often than transports change, and transports change a lot quicker than
> the servers/routers. The main advantage of my proposal is that the user
> can see all the importable contacts at a glance. Then the stuff that
> needs to happen can happen without any more user interaction. By no
> means am I saying my proposal is perfect.

The user can see them all, yes. But he's supposed to accept all of them in  
the first place right? Or at least, the subscription request the transport  
will make later on.

Like I said, I too appriciate how your proposal (adding contacts, with  
some meta data) works with existing clients and specs, therefore I see no  
reason not to use it. The roster-subsync proposal goes beyond what you  
propose though, and fixes problems your proposal doesn't even begin to  
look at. Roster-subsync is the right aproach to fixing a problem we want  
to solve, while your proposal is a way to enhance existing services for  
some clients.

>> 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.
> As I said, cross purposes. I think the suggestion of a 'your roster has
> zombies or is haunted' dialogue is sufficient. It is also the domain of
> the client authors how they wish to handle that.

Well, the client doesn't know which "none" contact is a zombie, and which  
one is. Again, if you delete me from your list I don't consider you a  
zombie contact on mine. If I delete you, and you don't go away, that's a  

>> >> 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.
> I don't see how it is not automated. Well really it depends on the
> clients and how they implement the semantics for that I suppose, but
> that is true of any proposal.

The "adding" is not fully automatic. (roster-subsync: put enough trust  
into this once, and it'll work from then on without touching it). How none  
automatic it is from then on depends on client implementation. Some will  
treat each separate JEP-0093 item as a seperate "attachment" perhaps, and  
some others might present a list. Some will require to select every  
JEP-0093 seperatly perhaps, etc. etc. That's just the JEP-0093 part. Then  
there's the subscriptions. Some users will configure their clients to  
automatically choose to allow all subscription requests (they'll have it  
easy), some will choose to allow for every contact they already have a  
subscription to themselves (so that would be every contact they chose to  
add from the JEP-0093) if their client has such an option, and some  
(including me) will choose to have to give permission to *every* contact  
(the default "safe" behaviour). so could still be a LOT of clicks if your  
clients supports JEP-0093.

Don't get me wrong, I'm not saying the number of clicks will be less  
(they'll be more) for clients that do neither JEP-0093 nor roster-subsync.  
I'm just saying roster-subsync allows the transport to tell the client to  
see the difference between adding, removing and changing of subscription  
states that *already* happend or are effectivly pre-approved, and the ones  
that are "real" and new that still need the users permission.

This is also the reason that any proposal attempting to cover all the  
issues that roster-subsync does, will be more elegant and easy to  
implement if it uses the <presence/> packet instead of <message/>. This is  
what most of the data is actually about, which is also why I think from a  
"clean protocol" standpoint, that's where it belongs.

>> 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.
> Yes that may be true from your perspective, and many other peoples on
> this list. I find that the roster-subsync proposal is a little too
> complex and really it only has a function during the importing/
> transition phase. While my proposal isn't perfect, it does perform the
> functions required for that phase, albiet with more coding from the
> client writers than the transport writers but let's keep the
> intelligence there for this. They can then define how they want their
> use cases to work.

I'll emphasize again, for what your proposal can handle -adding some  
contacts at import and later on- it's good (in fact you wonder why we  
haven't seen something like this used). Anything beyond that like removal,  
perfect syncing or real automation it doesn't shine.

If you as a user or the maker of client are content with that, fine. It's  
not what I hear from my users, it's not my experiance as client maker, nor  
that of some off-list contacts who are eager to try this. We also have at  
least one transport maker that seems to think it's a good idea (who  
undoubtly is also a user of it). but that doesn't mean *you* have to have  
the same opinion :) So I don't see your proposal as a reason not to have  
roster subsync, just like I've never seen roster-subsync as a reason not  
to have your proposal. Nor did I have the feeling you really did, for that  

>> 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.
> That is an assumption you are making, and I am not sure why. I don't
> think it'll be any easier or harder than roster-subsync, but as I
> haven't implemented it client-side I don't know.

It's not a crime to make an assumption when you design a protocol (hell  
no), as long as you have good reasons to.

Most of your data will presence related. When you put stuff it in a  
<message/> you're not making things easy for yourself I think. How will  
you use JEP-0093 in a way it can handle these new task without breaking up  
old client using the namespace or having a really ugly protocol? If you  
already have a framework dealing with presence (JEP-0093 or not, the  
transport and client have to set these subscriptions!) wouldn't it be  
easer to add roster-subsync to that rather than a JEP-0093+<message/>  
mechanism? And finally, if most of your data is related to presence  
subscriptions shouldn't it be in presence packets from a protocol  
perspective anyway?

These are some of the questions I asked and answered for myself.. I  
haven't seen them answered very differently by anyone yet, so that's what  
I base my assumption on. But like I always stated, I'd love to see someone  

>> 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.
> Well I've implemented my proposal in a transport and it took exactly...
> 8 lines of code for the import case. The subsiquent session case hasn't
> been done yet but it won't take that many lines or add that much
> complexity. :)

Let's ask James how many lines it took him to implement his original  
proposal (the <import/> based one). I honestly haven't asked him yet, but  
I'm guessing it was less than yours! Would saving a few lines of code be  
reason for you to ditch what you have now?

Of course when you have more functionality you'll end up with more code.  
But when your transport doesn't know the "to" or "from" state you won't  
have to implement that either. Still it's mostly adding some simple data  
already known to the transport to outgoing presence packets, and for the  
clients it's mostly looking at incoming subscription related presence  
packets a little better for a roster-subsync tag, sometimes automatically  
sending one back (which some clients already do), and a little prompt or  
setting for the user if they're OK with this. Not exactly rocket science  

>> 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.
> That is probably a good way of looking at it. I don't feel that the
> security issues or removal issues need to be taken care of specifically
> other than I have already identified. I have no problem with this being
> seen for what it is, one way to solve a problem, it isn't the be all and
> end all, and doesn't try to be.

I hope all my writing here too has shown that I have no problems with the  
idea of using JEP-0093 to send some contact, let alone you writing a guide  
on how to do that. I just think there are many legimate cases out there,  
which can't be fixed with existing protocol, and that the roster-subsync  
proposal will hopefully give us a powerfull but simple way to do that.

More information about the Standards mailing list