lwj(_at_)cs(_dot_)kun(_dot_)nl wrote:
1) What is the reason to encapsulate clear-text PEM body parts in an
entity of type message/pem-clear, instead of including the body part
unencapsulated (e.g. as text/plain, but potentially any MIME type)?
The latter would provide better interoperation with MIME-capable UAs
that are not PEM-capable (MIME does not mandate any particular
treatment for unrecognized subtypes of message).
warlord(_at_)MIT(_dot_)EDU wrote:
If you DON'T do this, then how do you distinguish between signed
clear-text and non-signed clear-text? If all you use is text/plain,
then you have no way to distinguish the two (other than by context).
And I think context parsing isn't part of MIME (but I'm not sure about
this).
By the mere fact of its encapsulation into a multipart/pem construction.
I think my real question is why both message/pem-clear and
application/encrypted are needed whereas a single C-T may suffice.
On another note:
I did not recall seeing explanatory text on this, but the example seems to
indicated that within a message/pem-clear (and presumably within
an application/pem-encrypted) you can have essentially a MIME compliant
msg. but w/o the MIME-Version header. Is this the case? Perhaps requiring
the MIME-Version, making the stuff inside message/pem-clear & application/
pem-encrypted fully MIME compliant would actually simplify interpretation.
-Ray