I accidentally substituted application/pem-clear for message/pem-clear.
Well this accident is needed! Using message/pem-clear does not
completely solve the gateway problem. If a message/PEM-Clear content
reaches a gateway and must be downconverted from 8 bit to 7, the
gateway is compelled to bounce the message. Message/* type cannot be
encoded with anything but 7 bit, 8 bit or binary and the whole intent
of the content type message/pem-clear is to prevent the gateway from
recursing though the data.
Application/* is not subject to this restriction so it would be more
appropriate for an encapsulated PEM data.
From Ned Freed
There are two reasons for the addition of this layer:
(1) It makes the structure of mic-clear and encrypted messages match up. While
this is not a real requirement, it is nice thing to have.
This argues strongly for making both message/MIC-clear and
application/Encrypted merge into a single content type,
application/pem-data. Neither part can be read without at least a
minimum of PEM awareness, they both have the same structure and are
both subject to the same gateway restrictions. The PEM processing (or
lack of) required is clearly identified in the PROC-TYPE field in the
Application/PEM data. This merging further reduces redundancy and the
possiblity of silly states by making it impossible for PROC-TYPE and
the data portion content-type from getting out of sync.
Greg V.
(I still think hiding the integrity only content type from non-pem
readers is going down the wrong path.)