[standards-jig] JEP:0015 Account Transfer
debug at nafai.dyndns.org
Fri Feb 1 22:35:32 UTC 2002
> Transports really depend on how a server handles them. Even with the
> iq:gateway protocol, it may not be possible to provide a seamless way of
> transferring subs that aren't "pure jabber". The only solution I can see is
> that either the spec says that the server attempts some "best try" algorithm
> for transferring the transport accounts, drops them, or we establish a
> case-by-case spec for particular transports to make them easier to transfer.
> All of these options are unsatisfactory in one way or the other...
There is also the issue of the oldserver having a transport that
newserver doesn't. This can create massive problems.
In the case where oldserver and newserver both have the same transport:
The transport itself should have code for contacting other transports of
its kind and moving things over. This would have to include versioning,
and attention to security so transports can't be migrated separatly from
accounts (actually migration of transports by themselves might be
beneficial, we should think about that).
I think that solve the same transport situation.
In the case where oldserver and newserver have two different transports
that do the same thing: like icq-transport and aim-transport(acting like
an icq transport). things get hairier here. How do we 'map' compatible
There is also the naming problem, I might have my icq transport
listening on icq2.floobin.cx and jabber.org has it on icq.jabber.org.
How do we know icq2 and icq are the same thing? This gets into the
mapping problem. We need a method to query what a transport really is (a
name, version number combination)
Right now I think I would leave off transport handling and push that to
> I think that we should give the initiator feedback on the process. Perhaps
> something along the lines of x:event?
Agreed. Feedback is definately good. What sort of feedback should be
given though, and at what point? For each user contacted and updated?
What part the of process its in?
> I don't think its practical to keep empty accounts with redirects as part of
> the spec. At least for myself, I wouldn't want to support users that aren't
> really users... :)
Hrm.. yeah. Probably best just to remove it.
> Synchronizing info on accounts will be tough. There doesn't seem to be very
> many ways of doing this well without specifying a lot of behavior. For
> example, what if the new server doesn't support private storage but there is
> ton of info on the old server with private storage data?
> I realize that a lot of the value of the spec is in offloading these issues
> from the client. However, many of these things, esp things like sync'ing
> private data may be better left to the client to handle...
What if the user uses different clients at different times? If the
account is destroyed at the end of the process then they might lose all
that data the other client uses.
> It is also unclear if the client must remain logged in to both accounts
> while the account transfer is occurring or if they only need to be logged in
> to initiate things then can log out.
I would assume they would remain logged into both clients, then be
kicked off the old client when the account transfer is done and the
How about something like this:
A capabilities discovery whereby the oldserver can ask the newserver
what it supports. This list can include private data limits, transports,
etc. Then this data is fed back to the user so they can see what can and
can't be transferred? I think this might be the 'easy' way out of the
problems we've been encountering.
More information about the Standards