ietf-smime
[Top] [All Lists]

RE: application/mime and binary data

1997-07-29 00:23:57
On Monday, July 28, 1997 6:22 PM, Ned Freed
[SMTP:Ned(_dot_)Freed(_at_)innosoft(_dot_)com] wrote:
The MIME specification, after all, clearly implies that this is the right
thing
to do. And in fact it is the right thing to do -- sometimes. When you don't
have MIME or signature support on the cc:Mail side you certainly don't want
things tunneled. But when you do have this support the right thing to do is
tunnel the multipart/signed through as a discrete object. I think tunneling
should be the default, as a matter of fact. And application/mime lets us
regain
this default at the hands of gateways. That's all the does, really. It is a
workaround for a major problem that is seriously jeopardizing the deployment
of
signature services -- the number of users on proprietary LAN email systems
is
enormous.

Exactly right!  This has been the position from which I and Bob have
discussed this issue in the past.  There needs to be a way to send and
receive a signed entity that will look exactly like a file attachment in
a LAN email environment.  This is one of the primary reasons why
signedData exists right now.  If the same characteristics will apply to
application/mime or application/signed, then I'm all for them.  The
problem with application/mime right now is that too much needs to be
promoted to the Content-Type as a requirement of the spec.  This is a
non-starter from our point of view, because we have very little control
what the LAN mail <--> MIME gateway (both directions) will produce, and
we cannot guarantee that even the Content-Type will be set correctly.
This is precisely why the file extensions are so important to us also.

In the event that we are able to come to some consensus on
application/signed (or even application/mime) that doesn't require
parameters for the Content-Type, and that has a particular file
extension mapping that makes it unambiguously an S/MIME multipart/signed
message transmitted in an outer wrapper that can be base64 encoded to
protect the contents, then I will be much happier about giving up the
ghost of signedData support.

And as an added bonus, we won't have to worry about the destruction of
our solar system, either.

John, this is all old news -- we've discussed these issues at enormous
length
in the past. I strongly suggest that you review the archives of this list so
as
not to spend a huge amount of time recovering old ground.

I think that this is a good thing for everyone to keep in mind -- a good
portion of the old discussion took place in September of last year on
SMIME-DEV which is archived at RSA.  We have been doing pretty well in
keeping to the application/mime and application/signed discussion which
is a new perspective on this old problem and is moving us forward.

Blake

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