Re: The issue of mime parsing

Rickard Armiento <[email protected]>:

> 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?

you're right, there would be no need to do todays MIME on message
parts, only a brief "directory listing" with a description of the
contents is needed.  thus the only "MIME types" needed in im2000
would be "related" and "single", and related parts of a message would
be treated like a single part, with descriptions forwarded to the
receiver(s) in notifications.

> 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! :-).

could you describe this manifest format, please?

> 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.

then how about "detached signatures" as used for securing (tar-) file
distributions?  this can not be optional, though, as this _is_ an
integral part of im2000.  thus every file transmitted as im2000 gets
its detached signature.  you could make the manifest be a simple list
like:

(think simplified Backus Naur)

  file-URL:  file-type; URL;
  detached-sig:  key-type; sig-data;
  entry:  notification data; file-URL; detached-sig; checksum;
  manifest:  entry+; checksum;

where the checksum has to assure the integrity of an entry and the
manifest itself.  where `-type' is mentioned, i'd like to see a
specification of the "agent" responsible for providing the data, this
would have to be a server or a server-class where the sending client
has relevant data-items stored.  for the keys we need a light-weight
distribution scheme, possibly with additional DNS resource records,
and possibly not using openssl, more along the lines of current
"hkp://" keyservers, because (at least i) prefer the web of trust
over a tree.  note that this cannot mean preferring PGP and excluding
X509, since supplying (but also using!) keys should be up to users.

i think your idea for substituting manifests for MIME is a very good
one indeed!  :)

  clemens

-----BEGIN PGP SIGNATURE-----

iD8DBQE+gZH8pdlrZyFBkK8RAsIrAJ0UThEofBJY1Sp4cFRDl4BFDVS/YACdFl5j
+LdaUfTmUyk7SzTMRTdHftM=
=USda
-----END PGP SIGNATURE-----