>
> I guess that depends on whether you think that im2000 is something
> likely to be achieve in that year or that century... There are a
> number of hurdles to surmount - in particular the issue of
> notification. It strikes me that notification has the same issues that
> email currently does - one party has to send something to an uncertain
> address and the other party has to accept something from an uncertain
> sender.
>
I would think that it would work something like this:
1) A dial in user (for example) would transfer a message to a well connected
server at their ISP. The ISP would provide the disk space used to store the
message.
2) The server would then send a packet to each MX host listed for the
destination(s) of the message.
3) Each MX server could do one of several things when notified:
If the MX server was the best server for the destination it would handle the
processing. If the destination was a dial in user it could cache the
notification until the account was active and asked about mail. The account
holder could defer action, transfer the message directly to their mailbox,
request the message be moved to the destinations server or reqest that the
remote message be rejected. Most of this could be done with just one packet
being sent to the destination. Users with expensive connectivity would see
less noise.
4) If the MX server was not the best choice it could determine the status of
the best MX and act as required. In most cases just caching the notification
until the primary became available.
5) The sending server would resend notifications until a time limit expired.
This kind of arrangement could store and forward data with strong
encryption. I would not have to have a key for you. I would have a key for
my ISP, my ISP would have a key for your ISP and your ISP would have a key
for you.
