Greg, I am not sure I follow your characterization of the third option.
If I understand, you are identifying a detail of MIME carrying PEM body
parts, which was John's second suggestion.
Let me first say that I agree with John and Steve Kent that we should
not do anything right now to alter the progression of either PEM or
MIME. There will be time enough for that when each of the documents is
ready to advance from Proposed to Draft Standard.
I believe there are three options with respect to integrating PEM and
MIME.
1. As John pointed out, it is possible today to PEM a MIME message.
Keep in mind that PEM by design assumes its input a text based mail
message. A MIME message matches this criteria, so there is no issue.
2. Again from John, MIME could carry PEM messages as a body part. I
believe that Greg identified how this could be accomplished
relatively easily. Note that this is taking a message, PEM'ing it,
and inserting that message as a body part in MIME. This requires the
"registration" of the body part, but a little bit of programming MIME
could do this today. As John points out, this may be at the expense
of an extra encoding.
3. The option that I believe requires some discussion is a true
integration of the technologies. In particular, PEM should be
changed to operate on arbitrary input streams, or more precisely, a
canonical form of its input stream.
For example, for a given MIME body part, a canonical form
representation must be defined. PEM does this now for RFC 822
messages. This canonical form could be passed to PEM, and the
resulting PEM'ified stream included in MIME as a PEM body part.
This integration would require that PEM have the canonicalization
step removed. In addition, the conversion to a printable form via
base64 should be removed, since MIME will do that if its necessary.
This is not a technically difficult problem, nor should it be
undesirable. However, as has been stated before, each of the
technologies needs to be deployed so that this integration can be
explored.
Jim