I disagree with Lewis' comment. Application/mime pulls the MIME type and
parameters up from the encapsulated MIME entity so the software processing
it knows what is encapsulated. That is pretty fundamental to the
application/mime being of any use (I agree with Lewis on that). Thus the
MIME type of an S/MIME message might be:
C-T: application/mime; content-type="multipart/signed";
protocol="application/pcks7-signature"; micalg=zodnots
The advantage that application/signed has over this is that many MUAs and
MTAs may not be able to dispatch on MIME parameters while they can do so on
MIME types. OTOH, the advantage of application/mime is that it is very
generic and may be implemented in many MUAs and thus become more widespread
than application/signed. I expect application/mime may become very useful
for multipart/related, which is also going to be destroyed by gateways and
for which I anticipate there being stand-alone viewers.
So maybe the analogy I'd choose is a benevolent cloud, rather than
splattering chainsaw, but maybe I've been around too many marketing folks
lately...
A further way type information about the encapsulated object can be carried
across gateways (in either direction) is with the filename parameter to
Content-Disposition. It does require a file extension just for the
particular encapsulated MIME type though. For example:
.aps -> multipart/signed; protocol="application/pkcs7-signature"
.mht -> multipart/related; type="text/html"
Most MUAs are pretty good about dispatching viewers based on the file
extension. For Windows this particular capability comes with the OS.
LL
At 11:20 PM -0700 7/25/97, Blake Ramsdell wrote:
.....
In the barrage of messages that formed the Great multipart/signed vs.
signedData War of '96, a very small exchange took place with the subject
"application/smime". For this discussion, the most pertinent paragraph
from that exchange was:
From: "Lewis Geer (Exchange)" <lewisg(_at_)Exchange(_dot_)Microsoft(_dot_)com>
Date: Sun, 22 Sep 1996 12:34:33 -0700
The mime in application/mime is probably too generic. It's possible
that people would start using it to tunnel other standards that might
not make it intact thru gateways, like mime encapsulated html (mhtml).
The problem with this is there is no easy way for the receiving agent
to tell if the application/mime content is s/mime, mhtml, or any other
standard (mhtml in particular is difficult as it is just a subclass of
multipart/related). Because of this, it's possible that the receiving
agent may send mhtml to an s/mime helper app. The fix is to call
application/mime something like application/smime.
The prospect of making Lewis' idea more generic to accommodate *any*
multipart/signed entity (the application/signed type that is being
discussed) is probably a good idea, and it isn't as much of a chainsaw
as application/mime, so innocent bystanders will be safe.
The idea is that any multipart/signed thing can be tunneled using
application/signed, presumably using appropriate CTE on the
application/signed part, the opacity is not as objectionable as
signedData, and it is not overly general to allow potential misuse.
Special language can also be drafted that explains why this might be a
good thing and what situations you might use it in, and the work does
not have to be redone for any other multipart/signed tunneling effort.
Blake