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.

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.

Bob creates an account on Jabber.org:
bobsnewaccount@jabber.org.

Bob logs into both bobsnewaccount@jabber.org and
olduser@floobin.cx.

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.

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.

bobsnewsaccount@jabber.org receives the 'user wants to
migrate account to you' packet and authorizes the
transfer.

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.

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.

finally floobin.cx informs olduser@floobin.cx that the
transfer was completed.

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.

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.

Appendix B: Author Information

Casey Crabb

Appendix C: Legal Notices

Copyright

Permissions

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.

Disclaimer of Warranty

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

Limitation of Liability

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.

IPR Conformance

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 <http://xmpp.org/about-xmpp/xsf/xsf-ipr-policy/> or obtained by writing to XMPP Standards Foundation, P.O. Box 787, Parker, CO 80134 USA).

Appendix D: Relation to XMPP

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.

Appendix E: Discussion Venue

The primary venue for discussion of XMPP Extension Protocols is the <standards@xmpp.org> discussion list.

Appendix F: Requirements Conformance

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