Just a couple of notes on that poster that Jon and I did showing how
MIME could be used as a container format for those
blobs^H^H^H^H^Hpackages of metadata
MIME seemed kind of neat as the deployment mechanism:
. already specified
. widely implemented
. widely deployed
. basis for multi-media support in HTTP
What's more:
. object types, charsets, encodings, etc are tagged
in a standardised way
. supports nesting via multipart/{mixed,alternative}
. somebody already looking after tag registrations!
I guess that last one maybe isn't so good, if you subscribe to the view
that the registration process for new content types isn't working... :-(
Another fly in the ointment is that the use of MIME in HTTP and its
(original) use in email are slightly disjoint - e.g. CRLF
canonicalisation, 8 bit clean versus ASCII, and different header names.
In our example we were using the mail variant of MIME, rather than the
HTTP one. Note that the "Content-Location:" header we refer to is
drawn from an Internet Draft by Jacob Palme "The Text/HTML Content Type
and the Content-Location MIME Header", aka draft-palme-text-html-02.txt.
This suggests borrowing the "Location:" header from HTTP for use in
email as a way of referring to external bodyparts. This was just a
private submission, but now that the MHTML working group has been
started up we can perhaps expect it to become a standard (eventually).
Likewise the "Content-MD5:" header isn't a standard part of MIME, but
is standards track - see RFC 1864. Some mailers have some support for
it, but WWW usage seems to have been caught up in the wrangling over
HTTP 1.1.
In HTTP we already have the important header - "Location:", but I don't
believe there is much experience with deploying multipart aware clients
and servers. Does anyone else know better ? This probably wouldn't be
much of a problem, since plenty of code has already been written to
support it in mailers and newsreaders ? :-)
Martin
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|