-
Notifications
You must be signed in to change notification settings - Fork 0
/
xep-0015.xml
265 lines (235 loc) · 11 KB
/
xep-0015.xml
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
<?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>
<approver>Council</approver>
<dependencies>
<spec>XMPP Core</spec>
</dependencies>
<supersedes/>
<supersededby/>
<shortname>N/A</shortname>
<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='result' 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>