[Top] [All Lists]

RE: application/mime and binary data

1997-07-25 23:19:43
On Friday, July 25, 1997 6:19 PM, Ned Freed
[SMTP:Ned(_dot_)Freed(_at_)innosoft(_dot_)com] wrote:
Hmm. An interesting idea. It would certainly eliminate one level of MIME
structure and would limit the utility of this type. And perhaps gateways
learn to leave this alone, since its function is clearly associated with
signatures. I think I like it... Note, however, that the implications of

would also apply to application/signed.

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.


<Prev in Thread] Current Thread [Next in Thread>