[standards-jig] JEP:0015 Account Transfer
iainshigeoka at yahoo.com
Mon Feb 4 20:45:43 UTC 2002
On 2/1/02 2:35 PM, "Casey Crabb" <debug at nafai.dyndns.org> wrote:
>> 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.
Hmm. Well, there are no standards for transports right now (beyond the
iq:gateway standard for naming) so expecting common features of transports
between servers could be a stretch. Standardizing transports is entirely
another can of worms...
> 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
Same problems apply I think.
> 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)
Agreed. The problems basically stem from a lack of transport standards to
> Right now I think I would leave off transport handling and push that to
> the future.
I think this may be the best.
>> 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 think so but in a summary. Say sending an update once a day as long as
updates occurred during that time period. Otherwise someone with 1000
roster items could be in for quite a bit of extra messages!
>> 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.
Or make it VERY optional with tentative suggestions for those that wish to
provide the feature...
>> 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.
I had a similar thought. Multiple resources multiplied over multiple
accounts is a major problem. Or the race/deadlock nightmare scenario of
someone in the midst of an account transfer and another client logs into the
old account and a different new account and requests a transfer... Or logs
into the first new account then logs into a second new account and starts an
account transfer while the original account transfer is still in progress...
And what happens if you're in the middle of an account transfer and wish to
abort (or are forced to for some reason)... Defining the state of things,
backing out from the migrated roster moves, etc needs to be defined. And
I'm not sure it will be easy.
Sorry, just playing devil's advocate here... ;)
>> 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
> account removed.
OK. What happens if the client disconnects before the transfer is complete?
Would that abort the transfer or have no effect?
> 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.
Right. Well, you could use Jabber browse to do that... Of course, I don't
think that browse is "core" jabber so there is a chance that browse is not
supported on one of the servers. However, this may be the cleanest way of
Sorry for being such a pain in the rear.
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com
More information about the Standards