I know this is an awfully late time to bring this up. Why was the
"cleartext" feature of PEM's Base64 removed from MIME's Base64. It
seems, now, this is a gratuitious incompatibility which may make us
non-interoperable with PEM's Base64. Having a cleartext capability
may, in fact, be useful. Are the PEM people going to adopt MIME's
modification of Base64, which would make the point moot? What should a
Base64 decoder do when it see's a `*'?
Jim Galvin already pointed out that this discrepancy is no longer an issue;
the latest PEM drafts have removed this clear text option as well.
However, I think you might be interested in why this option was removed. The
answer is easy to arrive at once you try to answer a different question: If
there's clear text in the middle of a base64 encoded object, what exactly does
that text MEAN?
Is the text part of the object that just didn't need encoding? Is it
out-of-band information that should be processed separately? What octets
are implied by end of line sequences in the clear text? And what should
be done about the very real possibility of character corruption in the case
where base64 is being used to get through gateways with restricted character
availability (this is one very important reason to use base64 in the first
place)?
PEM only deals with encoding. It says nothing about what the content of the
encoded document means -- it does not have to because its beyond the purview
of PEM. But MIME deals intimately with what the content of something means.
When I tried to reconcile the usage of embedded clear text in PEM with MIME
usage of base64, I ran into real trouble. There simply was no way to define it
that was clear, consistent, and didn't introduce problems somewhere. I don't
recall if all this was ever discussed on the mailing list; it may have been
taken care of entirely in conversations between Nathaniel and myself.
So the net result was that the clear text embedding was left out. I think
it was a very wise choice, and I'm glad PEM has gone this way as well.
Ned