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