[standards-jig] JEP:0015 Account Transfer

Iain Shigeoka iainshigeoka at yahoo.com
Fri Feb 1 18:40:42 UTC 2002


On 1/29/02 8:37 AM, "Casey Crabb" <debug at nafai.dyndns.org> wrote:

> On Sat, 2002-01-26 at 02:45, Iain Shigeoka wrote:
>> I'll try and comment when you've edited the JEP.  Please let me know when
>> you have.  I agree that seamless account transfers is a very handy feature.
>> I'm still concerned about the safety of doing it.
>> 
>> It would be just as handy to do auto transfers of email accounts, web site
>> accounts, etc but no similar standards have emerged (or even been suggested
>> as far as I know).  I think there are hidden dangers and practical concerns
>> still lingering...  It would be great if we could overcome or address them
>> though!
> 
> The JEP in CVS has been updated. I agree there are hidden dangers that
> we aren't seeing yet. I think a discussion will be necessary to rat them
> out. It might even be that we have to implement it and see where people
> attack it before we really find out.  I think the reason we haven't seen
> this in email is there are .forwards which work for the most part, at
> least until the server goes away and there is no definitive way to
> update an address book. In the web-world you can always just leave a
> hyperlink; and its impossible to know who is linking to you. In the
> jabber world we know who is subscribed to our presence.

Sorry for the delays.  I've been swamped with other tasks for the past few
days.

I think the revisions help to clarify how things work and eliminate my
initial problems.  I also like the addition of the "open issues" section.  I
agree that each poses some important issues that should be addressed (or at
least explicitly stated as "left to the implementer."

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...
Thoughts?

I think that we should give the initiator feedback on the process.  Perhaps
something along the lines of x:event?

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...  :)

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...

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.

-iain 


_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com




More information about the Standards mailing list