Scenario #1: PEM encapsulates MIME
This is, of course, quite allowable as PEM is content independent.
It will be up to the application to "feed" the PEM processed content
to the MIME UA.
This will work now so long as PEM does not care about Content-Type: and
a couple other headers. This is not the case I am worried over.
Scenario #2: MIME encapsulates PEM
This one is allowable too. MIME (presumably) defines some tags
which identify the next body part as PEM and feeds it to the PEM filter.
The output can then be parsed in any way fashionable. Perhaps it contains
additional MIME and even PEM protected parts. Note that this
is a superset of Scenario of #1 above.
This is the case which Marshall & I have mentioned. MIME does not currently
define any tags which identifies an enclosed message as PEM'd. It's `message'
type includes `rfc822', `digest', `multipart' &c, but not `pem'. It would
be presumptive of the MIME group to just go off and define content types for
every data format which might be carried around. Instead it was the scope
of the MIME group to define a framework within which to fit (and LABEL) any
object in a way which makes it e-mailable. And, as a practical consideration,
the group went ahead and defined a few objects to be carried around just to
give developers something to work with.
A particular thing left un-covered in MIME's typing hierarchy is any sort
of encryption or digital signatures, etc. After all, that is what the PEM
group has been working on. Further, few of us (none?) were at all expert
in these issues and could NOT have written anythng intelligent into an RFC.
Again, that is the job of the PEM group.
The plan, then, is that if some particular group wishes to define a way
for some particular object to be e-mailed that they write up a short RFC
describing the format, and register a tag with IANA. It should be a quick
and easy job to do and, I believe, has already been done once (or is in
the process) by the NETFAX group.
Just for fun please note that this works for other mail systems.
X.400 leaps to mind.
Yes, I understand this. After all, a PEM'd message is still in RFC-822.
BUT ...
Since the majority of PEM implementors are busy working hard on
their "PEM filters", perhaps the MIME folks should be preparing
to use these filters when they become available. It sounds like
an important 'value added' feature to MIME.
This is where the problem comes in. PEM includes multiple bodypart
encapsulations. As I recall it allows for some clear text to be included
in a separate body part, etc etc.
This means that a MIME implementer who wants their application to understand
and be able to rip apart a PEM message must write decoders for two
wildly different multi-body-part encapsulation systems. Namely, s/he must
write a MIME decoder to understand the outer part of the message. Then
to understand an included PEM message s/he must ALSO write an RFC-934 decoder.
(heavy sigh)
Yes it is important to add to MIME the ability to hold and properly label
PEM'd objects. As I have said above, it is the job of the PEM group to
define how this is done.
David