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.
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.
A basic overview of the behavior would be as follows.
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.
<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>
<iq id='acctxfer1' type='ask' from='floobin.cx' to='newaccount@jabber.org'>
<query xmlns='jabber:iq:accountxfer'>
<oldaccount>airog@jabber.org</oldaccount>
</query>
</iq>
<iq id='acctxfer1' type='ask' from='floobin.cx' to='newaccount@jabber.org'>
<query xmlns='jabber:iq:accountxfer'>
<oldaccount>airog@jabber.org</oldaccount>
</query>
</iq>
<iq id='acctxfer1' type='result' to='floobin.cx' from='newaccount@jabber.org'>
<query xmlns='jabber:iq:accountxfer'>
<allowed/>
</query>
</iq>
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.
<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>
<iq id='acctxferss1' type='result' to='floobin.cx' from='jabber.org'/>
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:
<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>
<iq type='result' id='acctxferss2' to='floobin.cx' from='jabber.org'/>
Once the migration finishes a notification is sent to the user:
<iq id='initacctxfer' from='floobin.cx' to='airog@floobin.cx' type='result'/>
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.
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.
Does the server keep an empty account that redirects requests to the new account? I've been hearing mass rumblings of 'NO' here.
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?
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.
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.
This document in other formats: XML PDF
This XMPP Extension Protocol is copyright © 1999 – 2020 by the XMPP Standards Foundation (XSF).
Permission is hereby granted, free of charge, to any person obtaining a copy of this specification (the "Specification"), to make use of the Specification without restriction, including without limitation the rights to implement the Specification in a software program, deploy the Specification in a network service, and copy, modify, merge, publish, translate, distribute, sublicense, or sell copies of the Specification, and to permit persons to whom the Specification is furnished to do so, subject to the condition that the foregoing copyright notice and this permission notice shall be included in all copies or substantial portions of the Specification. Unless separate permission is granted, modified works that are redistributed shall not contain misleading information regarding the authors, title, number, or publisher of the Specification, and shall not claim endorsement of the modified works by the authors, any organization or project to which the authors belong, or the XMPP Standards Foundation.
## NOTE WELL: This Specification is provided on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, express or implied, including, without limitation, any warranties or conditions of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A PARTICULAR PURPOSE. ##
In no event and under no legal theory, whether in tort (including negligence), contract, or otherwise, unless required by applicable law (such as deliberate and grossly negligent acts) or agreed to in writing, shall the XMPP Standards Foundation or any author of this Specification be liable for damages, including any direct, indirect, special, incidental, or consequential damages of any character arising from, out of, or in connection with the Specification or the implementation, deployment, or other use of the Specification (including but not limited to damages for loss of goodwill, work stoppage, computer failure or malfunction, or any and all other commercial damages or losses), even if the XMPP Standards Foundation or such author has been advised of the possibility of such damages.
This XMPP Extension Protocol has been contributed in full conformance with the XSF's Intellectual Property Rights Policy (a copy of which can be found at <https://xmpp.org/about/xsf/ipr-policy> or obtained by writing to XMPP Standards Foundation, P.O. Box 787, Parker, CO 80134 USA).
The HTML representation (you are looking at) is maintained by the XSF. It is based on the YAML CSS Framework, which is licensed under the terms of the CC-BY-SA 2.0 license.
The Extensible Messaging and Presence Protocol (XMPP) is defined in the XMPP Core (RFC 6120) and XMPP IM (RFC 6121) specifications contributed by the XMPP Standards Foundation to the Internet Standards Process, which is managed by the Internet Engineering Task Force in accordance with RFC 2026. Any protocol defined in this document has been developed outside the Internet Standards Process and is to be understood as an extension to XMPP rather than as an evolution, development, or modification of XMPP itself.
The primary venue for discussion of XMPP Extension Protocols is the <standards@xmpp.org> discussion list.
Discussion on other xmpp.org discussion lists might also be appropriate; see <http://xmpp.org/about/discuss.shtml> for a complete list.
Errata can be sent to <editor@xmpp.org>.
The following requirements keywords as used in this document are to be interpreted as described in RFC 2119: "MUST", "SHALL", "REQUIRED"; "MUST NOT", "SHALL NOT"; "SHOULD", "RECOMMENDED"; "SHOULD NOT", "NOT RECOMMENDED"; "MAY", "OPTIONAL".
Note: Older versions of this specification might be available at http://xmpp.org/extensions/attic/
END