Re: Standardizing inline PGP for e-mail?

[ned.freed@xxxxxxxxxxx]

> On 2003-01-22 14:30:48 -0500, Michael Young wrote:

> > 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.

> Maybe I should explain the rationale somewhat more.  First of all,
> with mutt, we generally try to parse things as late as possible --
> scanning text/plain for signs of encrypted or signed material is an
> action which explicitly has to be triggered by the user.  From that
> point of view, having a separate content type is certainly the thing
> to do.

> On the other hand, we had lots of complaints when we were using an
> application/ content type for inline PGP messages (from those who
> insisted in sending and receiving inline messages).  So we were
> looking for a way to generate inline messages which can (1) be
> handled by users with pgp-agnostic user agents, and (2) be
> recognized as PGP-messages early in the parsing process.  A MIME
> parameter for text/plain looked like an easy way to do this.

The default handling rules for unknown application types are very different
from those for unknown text subtypes. It seems to me that the default for text
subtypes is more or less what you want.

Of course not all user agents follow the rules for either one. But this will
hold true for any trick you use. For example, there's a popular user agent that
can fail in the presence of unexpected media type parameters. (Specifically,
its an older agent used in Japan that's sensitive both to unknown parameters
and parameter ordering, both entirely contrary to the MIME specification.)

Another example is how the original deployment of MIME was hindered by the
presence of agents that removed headers they did not recognize, such as
content-type or content-transfer-encoding.

There's a point where you have to say "enough" and move forward anyhow.
The real question is where that point lies.

				Ned