Worried about MUA's and multipart/*

[Laurence Lundblade <[e-mail]>]

The current MIME conformance draft says that multipart/* should be treated
as multipart/mixed when you don't know what * is. This is a nice default or
inheritance characteristic that has works well for a number of things like
appledouble and multipart/report.

However, I think we're about to see multipart things where this isn't going
to work well if at all. The two examples that come to mind are
multipart/signed where you have an external signature verifier, and
multipart/related where you have an external compound document viewer
(e.g., HTML or PDF). What is going to happen with just about every MIME
compliant MUA I know of is that the multipart will be split apart with no
way to put it back together to give to an application that understands the
format. If support for some new multipart is implemented directly in the
MUA then all will be fine and well for that part, but changing an MUA is
very difficult comparted to configuring a new viewer for it.

What seems to me is the issue is whether we want to encourage MUA
implementors to allow spawning of external viewers for multipart things
that are not explicitly built into the MUA. I believe there is nothing in
the spec that precludes them from doing that, but there is also nothing to
encourage it. I believe the way to implement it would be to default to
multipart/mixed unless a specific handler is configured (e.g., in mailcap)
for the type in question.

If we encourage MUA's to preserve the internal multipart structure and be
able to save it to a file or hand it off to another application, then I
think we will make them much more useful. A designer of a new data format
will be able to create it so it is readable by many in a degraded form as
it defaults to multipart/mixed, and readable in original form to those with
the viewer configured.

The most acute problem right now is with multipart/signed in S/MIME.
Because stand alone applications for verifying S/MIME signatures exist and
it is desirable to make these applications useful with existing MUA's there
is strong motivation to use application/x-pkcs7-mime instead of
multipart/signed.  By using application/x-pkcs7-mime the existing MUA's
save the item to a file with a file extension or type where the signature
can be verified easily by the stand alone S/MIME app. When attempting to do
the same thing with multipart/signed defaulted to multipart/mixed, there is
no way to use a stand alone app to verify the signature. The signature is
saved in one file, and the signed content may be written to several files,
transfer decoded and decanonicalized. Even if it were possible to easily
get two files into the S/MIME app easily, the signature will be invalid
because of the local transformations.

The reason I'm bringing this up here is because I think this is a general
MIME problem. Or stated another way, if we make headway for S/MIME we'll
make headway for a lot of other things. What I have in mind doing is making
some recommendation (not sure in what form) that a modern MIME MUA should
support saving multipart entities to a file, and that it support spawning
viewers for multipart entities. Perhaps an addition to the conformance
document if it is not too late?

Also if there is some consensus for support of such a thing here in the
MIME community, we'll be better able encourage the use of multipart/signed
for S/MIME (and MSP, PGP, MOSS...).


Laurence Lundblade            <[e-mail]>
QUALCOMM, Inc.                 619-658-3584