Some questions

I haven't had much luck searching for an archive of this list, but I would
have thought that a summary of the current answers/issues of the 'Some
questions' area of Dans im2000 page would have evolved by now. Could someone
try and address them please?

http://cr.yp.to/im2000.html

--
How should receivers be identified? How will the sender's ISP find the
receiver's ISP? Recipients will want to move transparently from one host to
another.
--

I've been thinking about the 'Some questions' area of the above web page,
particularly the first question about having recipients change their ISP
while transparently allowing senders to still reach them. Lets say the
receivers are identified as usual with a username, and a hostname
representing the ISP. The recipient could define a file called 'migration'
somewhere in a known location under their home directory and put the new
hostname and username information in there. Then when a message notification
from a senders ISP arrives at the recipients ISP servers im2000 udp
listener, it would find the file and update its in memory information
regarding where this new users location is as well as acknowledging back
within its return packet to the senders ISP that there is a transition
taking place. The senders ISP makes an in-memory note of this change as
well, and can even have a notification marked ready for the original sender
the next time he/she checks their mail. Then the senders client can feel
free to update its contact list with the new 'current' entry for this
particular recepient, while still preserving the previous contact
information in its history.

Alternatively, having a DNS entry maintained for each username at the ISP
that is accepting mail for im2000. Normally an IP would be returned
indicating the recipients host that is listening on a standard UDP port for
im2000 traffic. But if 127.0.0.1 were to be returned instead, or some other
magic value like 0.0.0.0, then the senders ISP server would attempt a second
dns lookup for something like 'username-change' or 'username-migration' that
would potentially indicate the new ISP hostname that the user is migrating
to. Users would still define a file in their home directory to include this
new hostname content but an extra trigger would be needed at some stage of
delivery or a few times a day to allow the DNS server to update itself with
this migration info. At the new ISP, the recipient will have to already
defined a file such as 'migration-previous' which contains their old
username and hostname information. Thats because once the senders ISP sends
a notification packet to the recipients new ISP server it won't yet know the
destination username. It would have to provide the previous username and ISP
hostname information, which will need to match an in-memory mapping to the
username at the new ISP.

ISPs could allow 30 days or so for a migration, before killing all
resemblence of the account. In other words the in-memory data at the
recipients previous ISP would expire at some point. A central cdb file could
contain the same info so that the expiration data survives server reboots,
even if the home directory is wiped out and the original migration file is
gone. Senders that have been away for a while and try to contact the
recipient may still have a problem though.

Perhaps im2000 could require that participants have their own domains, such
as optionally dyndns.org type entries that map to their dynamic IPs, along
with zoneedit.com style DNS services which are all free, so that they can
point their own DNS entries to their current ISP that is handling im2000
mail for them. Lets say I have bliptune.dyndns.org registered and set the MX
record to my current ISPs im2000 listening server. My username remains as
the one I have at my ISP, and the hostname stays as bliptune.dyndns.org. I
have control over that MX record via the free dyndns services and can set it
to a new ISP as soon as I feel like migrating elsewhere.

But really I haven't noticed much talk here of implementing the UDP notifier
that Dan suggests at his im2000 page. It seems to me the questions at his
page should be addressed before implementing anything, and also that a final
solution would not require much parsing ala XML etc as has been suggested on
the list recently but instead be a rather simple and straitforward
implementation after the remaining questions and issues are examined.

Where am I going wrong here?

Lester