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).
I have not read the I-D closely yet but on a first impression, I have
the same question.
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).
I think that the tagging of the clear data is important.
Is tagging anything more than the MD5 stuff? If so you could have
Content-Type: text/plain
Content-MD5: whatever
...plain text in clear...
That is, put the tagging (digital signature and such) in the mini-header
describing the particular bodypart.
Can you have a tag'd but other wise NON-TEXT thing (IMAGE/GIF for instance)?
Again you could put the header in the IMAGE/GIF's mini-header.
On the other hand ...
Most (all) MIME UAs will have some defaulting rules. For subtypes they
don't recognize the behaviour will default in ways dependant on the type.
So message/pem-clear will default to message/rfc822 (right?), and the
UA should give the user access to any body parts enclosed within. Thus
the tagging will be ignored, but at least the user will still have access
inwards.
So I can certainly see both sides to this and see that it won't make much
difference either way.
<- David Herron <david(_at_)twg(_dot_)com> (work)
<david(_at_)davids(_dot_)mmdf(_dot_)com> (home)
<-
<-
<- Where su-b-tlety is taken to an art!