Re: The issue of mime parsing

Rickard:
>> is it perhaps nessecary to abandon MIME for im2000?

clemens:
> i think this is a good idea.  im2000 servers could have
> capabilities:  if some server can MIME store HTML and PNG files,
> say, but no big audio streams, it could tell the sender that
> either parts of his message will be advertised or none.
[...]
> maybe MIME should be enhanced a bit for this to work?

I'm not sure I fully understand what you mean by "MIME store" a file.
It sounds to me as you are thinking of storing the parts as separate
files, but in some kind of MIME-specified ASCII-encoding? Since a
new im2000 protocol replacing SMTP can be designed to allow full
binary transfer of files, I do not understand why any data during the
send-delivery cycle needs to be ASCII-encoded?

That said, I do see the point of basing a new, more parse-friendly,
format on some kind of "simplified" MIME. Refering to my previous
mail, my thoghts are along the lines of combining binary part-files
with a 'manifest'-file describing their roles. It may be the best
solution to use a MIME-like format for this file, but with all
actual content specified as "stored externally in binary", giving
relative filenames (which may *not* contain directory traversal
characters! :-).

clemens:
> btw:  with SMIME servers will have to do MIME in "compatibility
> mode" anyway, because they will have to contact key-brokers on
> behalf of senders/receivers.

I have only very briefly browsed the SMIME specifications; but to me
it looks parse-heavy. Is this actually being considered for becoming
an integrated part of im2000? It seems easier to implement some
simpler mechanism for signing and encryption through the new im2000
protocols.

//Rickard