Re: The issue of mime parsing

"clemens fischer" <[email protected]>:

> From: and To: labels are the delivery, not the storage part of
> im2000.  they could be substitited by an identifier, since for a
> publish/subscribe system, the receiver has to provide it and the
> storage has to know it.  but this the delivery part:  an im2000
> storage could cache storage-acess-IDs for unfinished/unexpired
> deliveries.  a hash or list used to store valid deliveries must point
> to the stored item, but i see no need to point from the storage item
> to the delivery item.  ok, for housekeeping this may well be
> neccessary, though, eg. to be able to run an independant storage
> reclaimer.

it so happens that storage and delivery don't even have to be
performed by the same host or entity.  indeed, we could not only
spread the load but also separate the tasks to be performed.

users submit their emails to a storage and the delivery instructions
are handled by another host, using yet other services for key
management.  this is possible by combining your ideas of "specialized
MIME" and the SIP protocol!

> then again, should im2000 grow to be "the grand unified thing(tm)",
> future generations might want to send streaming data within the
> im2000 framework: then this entire MIME-substitution business is
> voided.  delivery items may or may not point to storage items, and
> storage items could identify streams as well.

handling streams could well come into perspective today if we adhere
to the principle of "separation of concern"!

  clemens