-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
I use mail agents that are PGP/MIME-naive (including one that is
MIME-aware, but that makes PGP/MIME messages painful to read),
so I'm generally appreciative of what Thomas is trying to do here.
But, I'll admit I'm not a MIME specification expert.
Quotes are from <ned(_dot_)freed(_at_)mrochek(_dot_)com>,
and "Thomas Roessler" <roessler(_at_)does-not-exist(_dot_)org>
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.
This only seems useful if you convince *forward-looking* user agents
to adopt it, for the benefit of those using naive user agents. That
seems unlikely, as many of them have picked up on PGP/MIME, and would
view this as a step backwards. But I'm happy for you to write it up.
Those of us using naive user agents will continue to clearsign by
hand. (I'm in no position to inject any MIME tags manually.)
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:
Based on my reading of the RFC excerpt that Ned provided, I disagree,
for clearsigned messages. No interpretation is *necessary* for
proper display -- an agent can simply show the whole mess.
(The MIME charset header would apply, I presume.)
Sounds fine, but it begs the question of why, if you're going to introduce a
major operationaal change to how PGP signs things, you don't just change to
generating multipart/signed.
It seems that the point is to use a simple MIME type that can be
displayed by PGP/MIME-naive agents, or that are acceptable in places
that discourage complicated MIME messages (like some newsgroups
and mailing lists).
Switching to yet another MIME multipart scheme won't help.
(I also wouldn't call this an operational change to how PGP signs
things -- the actual signing doesn't change. We're simply talking
about the MIME wrapping done by the mail user agent.)
3. Encrypted messages are likewise converted to UTF-8 before they
are passed to OpenPGP. Once again, there is no Charset header on
the ASCII armor. However, on the MIME level, the message will be
us-ascii -- we're using ASCII armor.
Here, it may be fair to argue that this violates the plain/text
guidelines. But, what's the harm, if that's what I really want my
agent to do in order to make (some of) my recipients happy?
Since some agents are going to do this technically-non-compliant
thing, Thomas is simply trying to reach agreement on how they do it.
-----BEGIN PGP SIGNATURE-----
Version: PGP Personal Privacy 6.5.3
iQA/AwUBPi7xS+c3iHYL8FknEQK/IgCgtOsOhHSyqW3sHsWtKvW/cMI2eyAAn26C
PrBeAm2691JS85PBq3+wkcnE
=auuv
-----END PGP SIGNATURE-----