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.
Agreed -- I'd forgotten that we resolved to limit message/* in this way. (I'm
still opposed to it but I can live with it.)
This argues strongly for making both message/MIC-clear and
application/Encrypted merge into a single content type,
application/pem-data.
This isn't a good idea; it requires that an implementation remember what was
specified at an outer level about the inner data. Information as to whether
or not the interior is encrypted needs to be available at the part level
associated with the data itself.
I suppose we could use a parameter for this, but why? The contents really are
completely different -- one can simply be viewed with an ordinary MIME message
viewer whereas the other requires significant PEM smarts to decipher.
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.
If by "PEM awareness" you mean "I added a line to my .mailcap file" then I
guess this is true. But there's a significant difference between a one-line
hack and having full PEM support around.
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.
But now you have to read forward, get the data from inside the part, skip
back, and interpret the part accordingly. Not only is this a lot of unnecessary
work, supporting this will require SIGNIFICANT enhancement of existing MIME
viewer facilities.
(I still think hiding the integrity only content type from non-pem
readers is going down the wrong path.)
We don't want to hide it from non-PEM readers, but I think we have to hide it
from MIME-aware gateways. My contention is that this sort of hiding can readily
be overcome as long as you're using pretty much any rationally designed MIME
reader.
Ned