mirror of
https://github.com/moparisthebest/xeps
synced 2024-11-15 22:05:01 -05:00
29bee13867
git-svn-id: file:///home/ksmith/gitmigration/svn/xmpp/trunk@320 4b5297f7-1745-476d-ba37-a9c6900126ab
259 lines
11 KiB
XML
259 lines
11 KiB
XML
<?xml version='1.0' encoding='UTF-8'?>
|
|
<!DOCTYPE xep SYSTEM 'xep.dtd' [
|
|
<!ENTITY % ents SYSTEM "xep.ent">
|
|
%ents;
|
|
]>
|
|
<?xml-stylesheet type='text/xsl' href='xep.xsl'?>
|
|
<xep>
|
|
<header>
|
|
<title>Account Transfer</title>
|
|
<abstract>A proposal for enabling the ability to transfer an account from one Jabber server to another.</abstract>
|
|
&LEGALNOTICE;
|
|
<number>0015</number>
|
|
<status>Rejected</status>
|
|
<type>Standards Track</type>
|
|
<sig>Standards</sig>
|
|
<author>
|
|
<firstname>Casey</firstname>
|
|
<surname>Crabb</surname>
|
|
<email>crabbkw@nafai.dyndns.org</email>
|
|
<jid>airog@floobin.cx</jid>
|
|
</author>
|
|
<revision>
|
|
<version>0.4</version>
|
|
<date>2002-04-18</date>
|
|
<initials>cwc</initials>
|
|
<remark>Cleaned up the open issues and concerns section.</remark>
|
|
</revision>
|
|
<revision>
|
|
<version>0.3</version>
|
|
<date>2002-04-16</date>
|
|
<initials>cwc</initials>
|
|
<remark>Added more specific details to the protocol. Added more examples. Tried to make the whole document more readable.</remark>
|
|
</revision>
|
|
<revision>
|
|
<version>0.2</version>
|
|
<date>2002-02-26</date>
|
|
<initials>cwc</initials>
|
|
<remark>Setting scope, adding discussion about using jabber:iq:browse in the future for transports</remark>
|
|
</revision>
|
|
<revision>
|
|
<version>0.1</version>
|
|
<date>2002-01-24</date>
|
|
<initials>cwc</initials>
|
|
<remark>Added more pseudo-protocol information. Added a known issues section.</remark>
|
|
</revision>
|
|
<revision>
|
|
<version>1.0</version>
|
|
<date>2002-01-16</date>
|
|
<initials>psa</initials>
|
|
<remark>First release to CVS, including editorial changes and assignment of number.</remark>
|
|
</revision>
|
|
<revision>
|
|
<version>0.9</version>
|
|
<date>2001-12-04</date>
|
|
<initials>cwc</initials>
|
|
<remark>Initial version.</remark>
|
|
</revision>
|
|
</header>
|
|
<section1 topic='Introduction'>
|
|
|
|
<p>I have found the need in the past to migrate an account from
|
|
one server to another for various reasons. Many of the people who
|
|
ask me about Jabber ask if there is a way to migrate their account
|
|
from one server to another if the need arises. There is no reason
|
|
Jabber can not handle this internally and update all the
|
|
JID-references appropriately.</p>
|
|
|
|
<p>Jabber servers come and go, especially ones run by people who
|
|
are just playing with the technology. Computers also die and
|
|
funding runs out. It can be hard on users to have to re-create
|
|
their rosters every time they have to change to a different
|
|
server. Administrators also want to provide an 'out' for their
|
|
users, so that they feel more secure in the time spent setting up
|
|
rosters. For these reasons there should be a way to migrate an
|
|
account from one server to another. </p>
|
|
|
|
</section1>
|
|
<section1 topic='Main Body'>
|
|
|
|
<p>A basic overview of the behavior would be as follows.</p>
|
|
<section2 topic='Preconditions'>
|
|
<ul>
|
|
<li>Bob has a jabber account on a server, floobin.cx
|
|
specifically: olduser@floobin.cx.</li>
|
|
|
|
<li>Bob knows that the floobin.cx server is going to go down soon
|
|
and therefore needs to find a new jabber server.</li>
|
|
|
|
<li>He realizes that jabber.org offers accounts to anyone, so he
|
|
sets out to migrate his account to jabber.org.</li>
|
|
|
|
<li>Bob does not yet have an account on jabber.org.</li>
|
|
</ul>
|
|
</section2>
|
|
<section2 topic='Order of events'>
|
|
<p>Throughout most of the account transfer the server hosting
|
|
the old account will be acting for the user. The end client
|
|
should have very little to do with the actual transfer.</p>
|
|
|
|
<ol>
|
|
<li>Bob creates an account on Jabber.org:
|
|
bobsnewaccount@jabber.org.</li>
|
|
|
|
<li>Bob logs into both bobsnewaccount@jabber.org and
|
|
olduser@floobin.cx.</li>
|
|
|
|
<li>From olduser@floobin.cx he sends the 'I want to migrate my
|
|
account' packet to Floobin.cx. This packet includes the JID
|
|
to migrate to.</li>
|
|
|
|
<li>Floobin.cx sends the 'user wants to migrate account to
|
|
you' packet to bobsnewaccount@jabber.org. This packet contains
|
|
the JID of the old account.</li>
|
|
|
|
<li>bobsnewsaccount@jabber.org receives the 'user wants to
|
|
migrate account to you' packet and authorizes the
|
|
transfer.</li>
|
|
|
|
<li>Once the migration is authorized the floobin.cx server
|
|
will start the migration process. The first part is to
|
|
notify each person subscribed to olduser@floobin.cx's
|
|
presence that the account has moved to
|
|
bobsnewaccount@jabber.org.</li>
|
|
|
|
<li>Once that is complete the roster itself
|
|
must be added into bobsnewaccount@jabber.cx's roster. There are
|
|
many issues with that remain and should be dealt with in the
|
|
future. See the section on scope for more information.</li>
|
|
|
|
<li>finally floobin.cx informs olduser@floobin.cx that the
|
|
transfer was completed.</li>
|
|
</ol>
|
|
</section2>
|
|
|
|
<section2 topic='Protocol Example'>
|
|
|
|
<example caption="User initiates process">
|
|
<iq id='initacctxfer' to='floobin.cx' from='airog@floobin.cx' type='ask'>
|
|
<query xmlns='jabber:iq:accountxfer'>
|
|
<oldaccount>airog@jabber.org</oldaccount>
|
|
<newaccount>newaccount@jabber.org</newaccount>
|
|
</query>
|
|
</iq>
|
|
</example>
|
|
|
|
<example caption='Server asks for permission from newaccount@jabber.org'>
|
|
<iq id='acctxfer1' type='ask' from='floobin.cx' to='newaccount@jabber.org'>
|
|
<query xmlns='jabber:iq:accountxfer'>
|
|
<oldaccount>airog@jabber.org</oldaccount>
|
|
</query>
|
|
</iq>
|
|
</example>
|
|
|
|
<example caption="XML received at user's new account">
|
|
<iq id='acctxfer1' type='ask' from='floobin.cx' to='newaccount@jabber.org'>
|
|
<query xmlns='jabber:iq:accountxfer'>
|
|
<oldaccount>airog@jabber.org</oldaccount>
|
|
</query>
|
|
</iq>
|
|
</example>
|
|
|
|
<example caption="newaccount@jabber.org accepts the migration">
|
|
<iq id='acctxfer1' type='result' to='floobin.cx' from='newaccount@jabber.org'>
|
|
<query xmlns='jabber:iq:accountxfer'>
|
|
<allowed/>
|
|
</query>
|
|
</iq>
|
|
</example>
|
|
|
|
<p>On acceptance the server on which the old account resides
|
|
starts the migration process by sending this to each person
|
|
subscribed to the user's presence.</p>
|
|
<example caption="XML sent to each JID subscribed to airog@floobin.cx's presence">
|
|
<iq id='acctxferss1' type='set' from='floobin.cx' to='jabber.org'>
|
|
<query xmlns='jabber:iq:accountxfer'>
|
|
<oldaccount>airog@jabber.org</oldaccount>
|
|
<newaccount>newaccount@jabber.org</newaccount>
|
|
<rosteritem jid='frienduser@jabber.org'/>
|
|
</query>
|
|
</iq>
|
|
</example>
|
|
|
|
<example caption="The server hosting the account of the roster item responds">
|
|
<iq id='acctxferss1' type='result' to='floobin.cx' from='jabber.org'/>
|
|
</example>
|
|
|
|
<p>Once that update has been sent to all the contacts on the
|
|
roster the floobin.cx server sends to the jabber.org server airog@floobin.cx's roster as follows:</p>
|
|
<example caption="airog@floobin.cx's roster is transferred into newuser@jabber.org's roster">
|
|
<iq type='set' id='acctxferss2' from='floobin.cx' to='jabber.org'>
|
|
<query xmlns='jabber:iq:accountxfer'>
|
|
<oldaccount>airog@jabber.org</oldaccount>
|
|
<newaccount>newaccount@jabber.org</newaccount>
|
|
<item jid='frienduser@jabber.org' name='friend1' subscription='both'/>
|
|
<item jid='annoyuser@jabber.org' ask='subscribe'/>
|
|
<item jid='someone@jabber.org' subscription='from'/>
|
|
</query>
|
|
</iq>
|
|
</example>
|
|
|
|
<example caption="floobin.cx responds saying the roster transfer was successful">
|
|
<iq type='set' id='acctxferss2' to='floobin.cx' from='jabber.org'>
|
|
</example>
|
|
|
|
<p>Once the migration finishes a notification is sent to the user:</p>
|
|
<example caption="Process completed">
|
|
<iq id='initacctxfer' from='floobin.cx' to='airog@floobin.cx' type='result'/>
|
|
</example>
|
|
</section2>
|
|
</section1>
|
|
<section1 topic='Open Issues, Concerns and Scoping'>
|
|
<section2 topic='How do we handle transferring transport stuff?'>
|
|
<p>Because we cannot determine easily if the new server will
|
|
support the same transports as the old server we cannot
|
|
easily transfer entities that pass through the
|
|
transport. Therefore, until jabber:iq:browse matures, or
|
|
some other solution for determining if two transports
|
|
support the same functionality we should not attempt to
|
|
migrate transport information.</p>
|
|
|
|
<p>I propose the following algorithm for determining if a
|
|
particular roster item is a sub-item of a transport. There are
|
|
jabber roster items for each of the transports themselves,
|
|
something to the effect of icq.jabber.org or
|
|
aim.jabber.org. They contain no user portion of the jid. We
|
|
record all of these in a list that we will call the
|
|
'transport-list'. Then for each roster item we want to migrate
|
|
we compare its 'host' part of the jid to all items in the
|
|
'transport-list'. If the roster item matches, then the roster
|
|
item is a hosted through the transport and shouldn't be
|
|
migrated.</p>
|
|
</section2>
|
|
|
|
<section2 topic='Empty Pointer Accounts'>
|
|
<p>Does the server keep an empty account that redirects requests
|
|
to the new account? I've been hearing mass rumblings of 'NO'
|
|
here.</p>
|
|
</section2>
|
|
|
|
<section2 topic='vCards and private storage data'>
|
|
<p>How do we handle vCard information or server side stored
|
|
preferences? Since the account we're migrating to can be any
|
|
account some of that information might already be there, how do
|
|
we resolve conflicts?</p>
|
|
|
|
<p>Also, we cannot be sure that the new server supports
|
|
storage of private data. This again needs some sort of
|
|
features negotiation, discovery which could be provided by
|
|
jabber:iq:browse.</p>
|
|
|
|
<p> Until jabber:iq:browse is in the 'standards' stage, I
|
|
recommend we only transfer regular jabber users, and not
|
|
transfer anything but the roster. All the client software will
|
|
have to set their preferences for themselves on the new
|
|
server.</p>
|
|
</section2>
|
|
</section1>
|
|
</xep>
|