[Standards-JIG] Roster block importing and synchronisation using JEP-0093
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:
>> 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
>> > to say if there was an item on the roster, then the client would
>> > 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 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
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
>> 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
>> 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
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