[standards-jig] Some thoughts on JEP-0015
alexander at dietrich.cx
Fri Sep 6 17:52:14 UTC 2002
I've read JEP-0015 and I think that it would make a useful addition to the
Jabber protocol. But there were some things that should be changed, IMHO:
2.2 Order of events
I would describe this as a 2-stage process by default, because some people
might not be able to log into 2 accounts at once (mobile devices, AOL users).
Being able to do the transfer "live" by logging into 2 accounts is implicitly
It should also be made clear that removing the old account is completely up
2.3 Protocol example
Example 1 and following:
The JIDs used in the sample packets don't match the ones used in section 2.2.
For easier reading, why not use something like "bob at oldserver.foo" and
"bob at newserver.foo" ?
There is no attribute type="ask" for <iq> in the core protocol, AFAIK.
Should this be type="set" ?
Examples 2 and 3 are the same thing.
Would a simple type="result" <iq> packet be sufficient ? It seems to be for
the rest of the protocol.
This could be done differently. Instead of sending this packet to every JID
in Bob's roster, collect the ones that have a node part and are in the same
domain, then send this packet to the server hosting them with multiple
<rosteritem> elements. The server gets to work on these contacts' rosters.
If the people are online at the time, the server additionally sends <query>
packets in jabber:iq:roster to their clients to remove Bob's old address
and to add the new one.
When the server is done, it sends the packet from Example 6 to oldserver.foo
to confirm the change.
This method makes it possible to transfer roster items that are on other IM
systems. The transport receives the packet along with a bunch of ICQ or AIM
JIDs, which it just ignores, but it can change the registration from Bob's
old address to the new one.
(Moving a transport registration transport-to-transport is an entirely
different problem, IMHO.)
This step should only be done when oldserver.foo receives the packet from
Example 6 for a group of JIDs, and only for that group of JIDs. Also, if
the server that sent the confirmation packet is in Bob's roster (a.k.a.
a transport), the transport's roster entry should be transferred along
with the group of JIDs.
If oldserver.foo does NOT receive a confirmation from the server that hosts
the roster items (because it's currently unavailable for example), they
should stay on oldserver.foo, so the process can be partially repeated later.
Correct me if I'm wrong, but there is already a way to send roster items
in jabber:iq:roster, so it is not really necessary to define a new packet.
Shouldn't the headline of this example be "jabber.org responds..." ?
And the packet:
<iq type='result' id='acctxferss2' to='floobin.cx' from='jabber.org'/>
When this comes in, oldserver.foo can finally remove the group of roster
items (JIDs and optionally transport). As before, appropriate <query>
packets in jabber:iq:roster need to be sent to the old client, if logged
In the current JEP it's not clear whether oldserver.foo waits for a
confirmation of every single JID and aborts if one is missing, or if
it will just continue after all JIDs have been notified.
3.1 Transferring transports
As I wrote, transferring the current state of a transport registration to
another server should not be a problem, probably not even a special case
(except for the transport's roster entry). For transferring a registration
to a different transport that does the same thing, I guess the transport
authors will have to come up with a standard way.
Wow, I hope I didn't come up with a load of bullshit here... :)
( Alexander Dietrich <alexander at dietrich.cx> )
More information about the Standards