[Standards-JIG] Roster block importing and synchronisation using JEP-0093
mikea at yuri.org.uk
Wed Sep 15 16:06:32 UTC 2004
> 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.
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.
> 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)
> 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.)
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) and yet you are advocating auto-removal of items
that have been removed on the legacy roster. What happens when the
legacy service has such poor semantics that items just disappear from a
roster because thats the way it handles it?
> 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
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).
You have a nice user population for testing if you have thousands of
> > 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..
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.
> > 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.
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.
> >> 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.
> 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.
> 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.
> 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
> 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.
More information about the Standards