[standards-jig] JEP:0015 Account Transfer
iainshigeoka at yahoo.com
Wed Feb 6 16:15:56 UTC 2002
On 2/5/02 5:45 PM, "Casey Crabb" <debug at nafai.dyndns.org> wrote:
> Sorry for the insane amount of quoting, but context certainly helps the
> short responses...
It does help.
>>> Right now I think I would leave off transport handling and push that to
>>> the future.
>> I think this may be the best.
> Ok; putting off transport migration for now.
>>>> I think that we should give the initiator feedback on the process. Perhaps
>>>> something along the lines of x:event?
>> 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!
> Would an account migration really take a day's worth of time? Sounds
> strange that it would take so long.
Ah. I was assuming things would be "best effort" so like email, when a
server is unreachable, it goes and retries every 6 hours or whatever
attempting to connect up via s2s and do the transfer. If that behavior is
not what is intended then the whole process should be relatively fast. A
few minutes perhaps... I think that implementations will take a long, best
effort attempt at the transfer unless the standard explicitly states that
transfers should be attempted once (immediately) and it either succeeds of
>> 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...
> Since the server is actually transferring the account it can simply deny
> the second request with the error that one is already in progress.
Sounds reasonable. This stipulation should be added to the standard so we
have well behaved implementations.
>> 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.
> I would say that there should never be a case where the account transfer
> would fail ungracefully. That said if a tertserver is unreachable it
> simply informs the user that a particular contact was unable to be
> reached and must be informed of the new account manually.
Sounds good. Once again, this should be added to the JEP.
> Before the roster transfer begins oldserver and newserver should agree
> that there is enough resources on newserver for the account to be
> transferred. I'll add that into the protocol.
> I'll just dictate that an account transfer can not be cancelled once
> begun. It'll continue to completion. If you want to 'undo' the
> transfer simply transfer back.
>> OK. What happens if the client disconnects before the transfer is complete?
>> Would that abort the transfer or have no effect?
> No effect. The account would still be transferred.
Good. Add to spec.
>>> 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
>> handling things.
> I'm not sure Jabber browse does everything this would require yet. I
> need to get up to speed on Jabber browsing, and add it into my client.
Yeah. I'm not that familiar with browse beyond the basics of how it
functions. Still, if it can be adopted for the purpose it saves you from
adding more to the transfer spec.
>> Sorry for being such a pain in the rear.
> Thanks for being a pain in the rear :)
:) And thank you for being such a good sport about it.
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com
More information about the Standards