xeps/xep-0015.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">
        &#60;iq id='initacctxfer' to='floobin.cx' from='airog@floobin.cx' type='ask'&#62;
          &#60;query xmlns='jabber:iq:accountxfer'&#62;
            &#60;oldaccount&#62;airog@jabber.org&#60;/oldaccount&#62;
            &#60;newaccount&#62;newaccount@jabber.org&#60;/newaccount&#62;
          &#60;/query&#62;
        &#60;/iq&#62;
      </example>

      <example caption='Server asks for permission from newaccount@jabber.org'>
        &#60;iq id='acctxfer1' type='ask' from='floobin.cx' to='newaccount@jabber.org'&#62;
          &#60;query xmlns='jabber:iq:accountxfer'&#62;
            &#60;oldaccount&#62;airog@jabber.org&#60;/oldaccount&#62;
          &#60;/query&#62;
        &#60;/iq&#62;
      </example>

      <example caption="XML received at user's new account">
        &#60;iq id='acctxfer1' type='ask' from='floobin.cx' to='newaccount@jabber.org'&#62;
          &#60;query xmlns='jabber:iq:accountxfer'&#62;
            &#60;oldaccount&#62;airog@jabber.org&#60;/oldaccount&#62;
          &#60;/query&#62;
        &#60;/iq&#62;
      </example>

      <example caption="newaccount@jabber.org accepts the migration">
        &#60;iq id='acctxfer1' type='result' to='floobin.cx' from='newaccount@jabber.org'&#62;
          &#60;query xmlns='jabber:iq:accountxfer'&#62;
            &#60;allowed/&#62;
          &#60;/query&#62;
        &#60;/iq&#62;
      </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">
        &#60;iq id='acctxferss1' type='set' from='floobin.cx' to='jabber.org'&#62;
          &#60;query xmlns='jabber:iq:accountxfer'&#62;
            &#60;oldaccount&#62;airog@jabber.org&#60;/oldaccount&#62;
            &#60;newaccount&#62;newaccount@jabber.org&#60;/newaccount&#62;
            &#60;rosteritem jid='frienduser@jabber.org'/&#62;
          &#60;/query&#62;
        &#60;/iq&#62;
      </example>

      <example caption="The server hosting the account of the roster item responds">
        &#60;iq id='acctxferss1' type='result' to='floobin.cx' from='jabber.org'/&#62;
      </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">
        &#60;iq type='set' id='acctxferss2' from='floobin.cx' to='jabber.org'&#62;
          &#60;query xmlns='jabber:iq:accountxfer'&#62;
            &#60;oldaccount&#62;airog@jabber.org&#60;/oldaccount&#62;
            &#60;newaccount&#62;newaccount@jabber.org&#60;/newaccount&#62;
            &#60;item jid='frienduser@jabber.org' name='friend1' subscription='both'/&#62;
            &#60;item jid='annoyuser@jabber.org' ask='subscribe'/&#62;
            &#60;item jid='someone@jabber.org' subscription='from'/&#62;
          &#60;/query&#62;
        &#60;/iq&#62;
      </example>

      <example caption="floobin.cx responds saying the roster transfer was successful">
        &#60;iq type='set' id='acctxferss2' to='floobin.cx' from='jabber.org'&#62;
      </example>

      <p>Once the migration finishes a notification is sent to the user:</p>
      <example caption="Process completed">
        &#60;iq id='initacctxfer' from='floobin.cx' to='airog@floobin.cx' type='result'/&#62;
      </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>