[Standards-JIG] Roster block importing and synchronisation using JEP-0093
mikea at yuri.org.uk
Wed Sep 15 18:54:04 UTC 2004
Thanks for you comments .However I feel we have reached the point where
we will be going round in circles. So it is probably best to park this
discussion here as I believe it has no further useful purpose.
On Wed, 2004-09-15 at 20:13 +0200, Tijl Houtbeckers wrote:
> 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.
> Standards-JIG mailing list
> Standards-JIG at jabber.org
More information about the Standards