ned(_dot_)freed(_at_)mrochek(_dot_)com writes:
It seems like inline PGP messages just can't be eradicated, despite
all the PGP/MIME we have. I'm wondering if it would be reasonable
to produce an RFC on (1) how to tag this on the MIME level, and (2)
how to avoid character set problems.
Here's the simple proposal (in rough words), as currently
implemented in the Mutt mail user agent.
1. Inline PGP messages use text/plain as their MIME type. Inline
PGP material is announced in an additional MIME parameter (we call
it x-action right now), which can take the values "pgp-encrypt",
"pgp-sign".
Such usage clearly violates RFC 2046 section 4.1.3, which states
that text/plain is intended for material that isn't formatted in any way:
Plain text is intended to be displayed "as-is", that is, no
interpretation of
embedded formatting commands, font attribute specifications, processing
instructions, interpretation directives, or content markup should be
necessary
for proper display
It also violates the intended use of media type parameters, which are
supposed
to qualify the format being used rather than identifying it. Format
identification is supposed to be done by the media type.
FWIW, there is a standards track precedence for Thomas' approach; the
RFC 2646 format=flowed parameter that modifies how text/plain is
rendered.
I did and do have deep misgivings about format=flowed; it treads dangerously
close to the line and may indeed step a bit over it. But there's a huge
difference between something that says "it is OK to wrap these lines for
display" and something that says "Surprise! This is now structured material
containing an elaborate security object that requires extensive processing in
order to handle properly".
The two cases really aren't at all comparable IMO.
Ned