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.
I wasn't aware that message/ was special. I guess some accidents are
good. :-)
This is actually a recent change to MIME. I'm afraid it is going to force
a change to application/pem-clear.
The current proposal deals well with this problem by making integrity
checked message intentionally not readable by a non-PEM aware gateways
or MIME readers. But by doing this, it throws out the more important
goal of MIME/PEM <=> MIME interworking! If I send an Integrity checked
message to you, if you do not have a PEM aware implementation, you
can't read it!!
I don't why you are making this assertion. As I recall, with application/
C-Ts, the MIME mailer should, if it doesn't know the C-T, just save
the part as a 8 bit file... which in the MIC-ONLY case may be easily
viewed. Presumably, a good mailer should offer the option to display
the item as well, which will also allow the user to read it.
More to the point is the ability to apply the UA's regular message part
decoder. Most implementations make this easy to do.
Ned