On Thursday, July 24, 1997 4:13 PM, John Gardiner Myers
[SMTP:jgmyers(_at_)netscape(_dot_)com] wrote:
The msg document makes use of the application/mime media type, which the
IESG has not approved. I have serious concerns with application/mime.
It has a far-reaching impact on MIME implementations which is both
non-obvious and subtle, and this impact is not mentioned at all in
draft-crocker-wrap-01.txt.
Yup -- I mentioned this to Paul just today. Apparently it just fell
through the cracks, and application/mime will rise from the ashes of
expiration in short order. I can't speak about the concerns you have
about application/mime itself -- Laurence is the man for that.
This "binary MIME object" problem is also an issue for the
application/pkcs7-mime type. I've already heard reports of
noninteroperability between different S/MIME implementations, because
some senders imbed binary MIME objects inside an application/pkcs7-mime
objects and some readers cannot handle binary MIME objects contained
inside application/pkcs7-mime objects.
I can see how this could happen, and I don't know what the answer is.
On one side, you have the need to minimize the message size (if the
interior is base64 and the exterior is base64, then you can remove one
of the base64 steps to reduce your size). On the other hand, it blows
some people's minds if you send them binary data inside of an
application/pkcs7-mime object, including my case of converting
signedData to multipart/signed and then trying to stick it back on the
(7-bit) wire. How do you balance this?
One possibility is that we could add another SMIMECapability that is
something like "preferBinaryInside" or something like that. I'm
somewhat hesitant to suggest this, because I'm not sure if this is an
overloading of the SMIMECapabilities to be MIMECapabilities also. My
gut feeling is that it might help, but I don't know if there are going
to be any concerns about the user having multiple mail agents,
intermediate gateway processing, etc.
The bottom line is that non-interoperability is not cool. Do we get
tough with the language (the inside MUST be 7-bit clean), do we come up
with a protocol patch (preferBinaryInside), or is there some other
answer.
I'd like to suggest that we get tough with the language which keeps the
interoperability, but loses the ability to slim down the message. If
that's too harsh, then my next choice would be preferBinaryInside.
Blake