Re: The issue of mime parsing

Rickard Armiento <[email protected]>:

>> you could make the manifest be a simple list [...]
>
> Yes, that is another alternative. It could then use some easily
> parsed format for ordered fields, not nessecarily using ASCII
> (perhaps djb:s netstrings is a good idea) also making it possible to
> abandon unnessecary labels, like 'From:', 'To:' ...

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.

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.

> Detached signatures seems like a good idea. I am not a crytography
> expert, but maybe it is possible to just keep a crypto signature of
> the manifest file? (Or rather: the parts of it that does not get
> changed during delivery). If the manifest file includes hashes of
> all included parts (such as md5), then messing with the part files
> should be "hard"? Or does this somehow severly impact the efficiency
> of the crypto signature?

my objection isn't about efficient crypto here, but simply this:
people might want to fetch a single part of a message, so this single
part needs its own checksum, delivery and storage IDs.

  clemens