Date: Sun, 18 Dec 1994 15:33:22 -0700 (PDT)
From: Ned Freed <NED(_at_)INNOSOFT(_dot_)COM>
> I'm missing something. Kazu's original question was about
> CR/LF/CRLF text canonnicalization. MIME deals with this correctly, yes?
Yes it does.
> Is what you're saying is that MIME/PEM does not, and that's a feature?
Well, MIME/PEM does complicate matters somewhat, and I guess that's a
feature. Specifically, anything encrypted is just a bag of bits to
everyone except the recipient, and this had some unpleasant effects
on automatic format converters and similar services. But there's no
problem in terms of canonicalization as far as I know.
Well, MIME/PEM could have dealt with it correctly.
I disagree. These are fundamental issues, and they apply regardless of
the encapsulation you pick. The apply equally to "classic" PEM, to MIME-PEM,
and to Schiller's proposal.
For example, if MIME deals with the text cannonicalization correctly,
then Jeff Schiller's simple MIME/PEM integration proposal would have
dealt the CR/LF/CRLF cannonicalization correctly, since in that proposal
the encryption was applied after MIME had done its magic rain dance and
just before the message was sent out on the while.
? This is exactly how the MIME/PEM approach works. But it doesn't solve the
problem in any way...
Similarily, upon
receipt of an encrypted message, the simplified MIME/PEM integration
decrypted the message, and then passed the result to the MIME processor
where the result could have the appropriate magic happen to it so that
text cannonicalization process could be completed properly.
Again, this is exactly how MIME/PEM works.
What I want to understand is why your MIME/PEM proposal doesn't support
similar functionality. The fact that it doesn't seems to be broken,
IMHO.
The present MIME/PEM proposal does support this. If it doesn't then there's
something broken that needs to be fixed, I agree.
Ned