No Description
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.

xep-0015.xml 11KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172737475767778798081828384858687888990919293949596979899100101102103104105106107108109110111112113114115116117118119120121122123124125126127128129130131132133134135136137138139140141142143144145146147148149150151152153154155156157158159160161162163164165166167168169170171172173174175176177178179180181182183184185186187188189190191192193194195196197198199200201202203204205206207208209210211212213214215216217218219220221222223224225226227228229230231232233234235236237238239240241242243244245246247248249250251252253254255256257258259260261262263264
  1. <?xml version='1.0' encoding='UTF-8'?>
  2. <!DOCTYPE xep SYSTEM 'xep.dtd' [
  3. <!ENTITY % ents SYSTEM "xep.ent">
  4. %ents;
  5. ]>
  6. <?xml-stylesheet type='text/xsl' href='xep.xsl'?>
  7. <xep>
  8. <header>
  9. <title>Account Transfer</title>
  10. <abstract>A proposal for enabling the ability to transfer an account from one Jabber server to another.</abstract>
  11. &LEGALNOTICE;
  12. <number>0015</number>
  13. <status>Rejected</status>
  14. <type>Standards Track</type>
  15. <sig>Standards</sig>
  16. <dependencies>
  17. <spec>XMPP Core</spec>
  18. </dependencies>
  19. <supersedes/>
  20. <supersededby/>
  21. <shortname>N/A</shortname>
  22. <author>
  23. <firstname>Casey</firstname>
  24. <surname>Crabb</surname>
  25. <email>crabbkw@nafai.dyndns.org</email>
  26. <jid>airog@floobin.cx</jid>
  27. </author>
  28. <revision>
  29. <version>0.4</version>
  30. <date>2002-04-18</date>
  31. <initials>cwc</initials>
  32. <remark>Cleaned up the open issues and concerns section.</remark>
  33. </revision>
  34. <revision>
  35. <version>0.3</version>
  36. <date>2002-04-16</date>
  37. <initials>cwc</initials>
  38. <remark>Added more specific details to the protocol. Added more examples. Tried to make the whole document more readable.</remark>
  39. </revision>
  40. <revision>
  41. <version>0.2</version>
  42. <date>2002-02-26</date>
  43. <initials>cwc</initials>
  44. <remark>Setting scope, adding discussion about using jabber:iq:browse in the future for transports</remark>
  45. </revision>
  46. <revision>
  47. <version>0.1</version>
  48. <date>2002-01-24</date>
  49. <initials>cwc</initials>
  50. <remark>Added more pseudo-protocol information. Added a known issues section.</remark>
  51. </revision>
  52. <revision>
  53. <version>1.0</version>
  54. <date>2002-01-16</date>
  55. <initials>psa</initials>
  56. <remark>First release to CVS, including editorial changes and assignment of number.</remark>
  57. </revision>
  58. <revision>
  59. <version>0.9</version>
  60. <date>2001-12-04</date>
  61. <initials>cwc</initials>
  62. <remark>Initial version.</remark>
  63. </revision>
  64. </header>
  65. <section1 topic='Introduction'>
  66. <p>I have found the need in the past to migrate an account from
  67. one server to another for various reasons. Many of the people who
  68. ask me about Jabber ask if there is a way to migrate their account
  69. from one server to another if the need arises. There is no reason
  70. Jabber can not handle this internally and update all the
  71. JID-references appropriately.</p>
  72. <p>Jabber servers come and go, especially ones run by people who
  73. are just playing with the technology. Computers also die and
  74. funding runs out. It can be hard on users to have to re-create
  75. their rosters every time they have to change to a different
  76. server. Administrators also want to provide an 'out' for their
  77. users, so that they feel more secure in the time spent setting up
  78. rosters. For these reasons there should be a way to migrate an
  79. account from one server to another. </p>
  80. </section1>
  81. <section1 topic='Main Body'>
  82. <p>A basic overview of the behavior would be as follows.</p>
  83. <section2 topic='Preconditions'>
  84. <ul>
  85. <li>Bob has a jabber account on a server, floobin.cx
  86. specifically: olduser@floobin.cx.</li>
  87. <li>Bob knows that the floobin.cx server is going to go down soon
  88. and therefore needs to find a new jabber server.</li>
  89. <li>He realizes that jabber.org offers accounts to anyone, so he
  90. sets out to migrate his account to jabber.org.</li>
  91. <li>Bob does not yet have an account on jabber.org.</li>
  92. </ul>
  93. </section2>
  94. <section2 topic='Order of events'>
  95. <p>Throughout most of the account transfer the server hosting
  96. the old account will be acting for the user. The end client
  97. should have very little to do with the actual transfer.</p>
  98. <ol>
  99. <li>Bob creates an account on Jabber.org:
  100. bobsnewaccount@jabber.org.</li>
  101. <li>Bob logs into both bobsnewaccount@jabber.org and
  102. olduser@floobin.cx.</li>
  103. <li>From olduser@floobin.cx he sends the 'I want to migrate my
  104. account' packet to Floobin.cx. This packet includes the JID
  105. to migrate to.</li>
  106. <li>Floobin.cx sends the 'user wants to migrate account to
  107. you' packet to bobsnewaccount@jabber.org. This packet contains
  108. the JID of the old account.</li>
  109. <li>bobsnewsaccount@jabber.org receives the 'user wants to
  110. migrate account to you' packet and authorizes the
  111. transfer.</li>
  112. <li>Once the migration is authorized the floobin.cx server
  113. will start the migration process. The first part is to
  114. notify each person subscribed to olduser@floobin.cx's
  115. presence that the account has moved to
  116. bobsnewaccount@jabber.org.</li>
  117. <li>Once that is complete the roster itself
  118. must be added into bobsnewaccount@jabber.cx's roster. There are
  119. many issues with that remain and should be dealt with in the
  120. future. See the section on scope for more information.</li>
  121. <li>finally floobin.cx informs olduser@floobin.cx that the
  122. transfer was completed.</li>
  123. </ol>
  124. </section2>
  125. <section2 topic='Protocol Example'>
  126. <example caption="User initiates process">
  127. &#60;iq id='initacctxfer' to='floobin.cx' from='airog@floobin.cx' type='ask'&#62;
  128. &#60;query xmlns='jabber:iq:accountxfer'&#62;
  129. &#60;oldaccount&#62;airog@jabber.org&#60;/oldaccount&#62;
  130. &#60;newaccount&#62;newaccount@jabber.org&#60;/newaccount&#62;
  131. &#60;/query&#62;
  132. &#60;/iq&#62;
  133. </example>
  134. <example caption='Server asks for permission from newaccount@jabber.org'>
  135. &#60;iq id='acctxfer1' type='ask' from='floobin.cx' to='newaccount@jabber.org'&#62;
  136. &#60;query xmlns='jabber:iq:accountxfer'&#62;
  137. &#60;oldaccount&#62;airog@jabber.org&#60;/oldaccount&#62;
  138. &#60;/query&#62;
  139. &#60;/iq&#62;
  140. </example>
  141. <example caption="XML received at user's new account">
  142. &#60;iq id='acctxfer1' type='ask' from='floobin.cx' to='newaccount@jabber.org'&#62;
  143. &#60;query xmlns='jabber:iq:accountxfer'&#62;
  144. &#60;oldaccount&#62;airog@jabber.org&#60;/oldaccount&#62;
  145. &#60;/query&#62;
  146. &#60;/iq&#62;
  147. </example>
  148. <example caption="newaccount@jabber.org accepts the migration">
  149. &#60;iq id='acctxfer1' type='result' to='floobin.cx' from='newaccount@jabber.org'&#62;
  150. &#60;query xmlns='jabber:iq:accountxfer'&#62;
  151. &#60;allowed/&#62;
  152. &#60;/query&#62;
  153. &#60;/iq&#62;
  154. </example>
  155. <p>On acceptance the server on which the old account resides
  156. starts the migration process by sending this to each person
  157. subscribed to the user's presence.</p>
  158. <example caption="XML sent to each JID subscribed to airog@floobin.cx's presence">
  159. &#60;iq id='acctxferss1' type='set' from='floobin.cx' to='jabber.org'&#62;
  160. &#60;query xmlns='jabber:iq:accountxfer'&#62;
  161. &#60;oldaccount&#62;airog@jabber.org&#60;/oldaccount&#62;
  162. &#60;newaccount&#62;newaccount@jabber.org&#60;/newaccount&#62;
  163. &#60;rosteritem jid='frienduser@jabber.org'/&#62;
  164. &#60;/query&#62;
  165. &#60;/iq&#62;
  166. </example>
  167. <example caption="The server hosting the account of the roster item responds">
  168. &#60;iq id='acctxferss1' type='result' to='floobin.cx' from='jabber.org'/&#62;
  169. </example>
  170. <p>Once that update has been sent to all the contacts on the
  171. roster the floobin.cx server sends to the jabber.org server airog@floobin.cx's roster as follows:</p>
  172. <example caption="airog@floobin.cx's roster is transferred into newuser@jabber.org's roster">
  173. &#60;iq type='set' id='acctxferss2' from='floobin.cx' to='jabber.org'&#62;
  174. &#60;query xmlns='jabber:iq:accountxfer'&#62;
  175. &#60;oldaccount&#62;airog@jabber.org&#60;/oldaccount&#62;
  176. &#60;newaccount&#62;newaccount@jabber.org&#60;/newaccount&#62;
  177. &#60;item jid='frienduser@jabber.org' name='friend1' subscription='both'/&#62;
  178. &#60;item jid='annoyuser@jabber.org' ask='subscribe'/&#62;
  179. &#60;item jid='someone@jabber.org' subscription='from'/&#62;
  180. &#60;/query&#62;
  181. &#60;/iq&#62;
  182. </example>
  183. <example caption="floobin.cx responds saying the roster transfer was successful">
  184. &#60;iq type='result' id='acctxferss2' to='floobin.cx' from='jabber.org'/&#62;
  185. </example>
  186. <p>Once the migration finishes a notification is sent to the user:</p>
  187. <example caption="Process completed">
  188. &#60;iq id='initacctxfer' from='floobin.cx' to='airog@floobin.cx' type='result'/&#62;
  189. </example>
  190. </section2>
  191. </section1>
  192. <section1 topic='Open Issues, Concerns and Scoping'>
  193. <section2 topic='How do we handle transferring transport stuff?'>
  194. <p>Because we cannot determine easily if the new server will
  195. support the same transports as the old server we cannot
  196. easily transfer entities that pass through the
  197. transport. Therefore, until jabber:iq:browse matures, or
  198. some other solution for determining if two transports
  199. support the same functionality we should not attempt to
  200. migrate transport information.</p>
  201. <p>I propose the following algorithm for determining if a
  202. particular roster item is a sub-item of a transport. There are
  203. jabber roster items for each of the transports themselves,
  204. something to the effect of icq.jabber.org or
  205. aim.jabber.org. They contain no user portion of the jid. We
  206. record all of these in a list that we will call the
  207. 'transport-list'. Then for each roster item we want to migrate
  208. we compare its 'host' part of the jid to all items in the
  209. 'transport-list'. If the roster item matches, then the roster
  210. item is a hosted through the transport and shouldn't be
  211. migrated.</p>
  212. </section2>
  213. <section2 topic='Empty Pointer Accounts'>
  214. <p>Does the server keep an empty account that redirects requests
  215. to the new account? I've been hearing mass rumblings of 'NO'
  216. here.</p>
  217. </section2>
  218. <section2 topic='vCards and private storage data'>
  219. <p>How do we handle vCard information or server side stored
  220. preferences? Since the account we're migrating to can be any
  221. account some of that information might already be there, how do
  222. we resolve conflicts?</p>
  223. <p>Also, we cannot be sure that the new server supports
  224. storage of private data. This again needs some sort of
  225. features negotiation, discovery which could be provided by
  226. jabber:iq:browse.</p>
  227. <p> Until jabber:iq:browse is in the 'standards' stage, I
  228. recommend we only transfer regular jabber users, and not
  229. transfer anything but the roster. All the client software will
  230. have to set their preferences for themselves on the new
  231. server.</p>
  232. </section2>
  233. </section1>
  234. </xep>