Hi Michael,
--On Friday, January 24, 2003 01:53:29 PM -0500 Michael Young
<mwy-opgp97(_at_)the-youngs(_dot_)org> wrote:
| The main reason we went down the subtype path was that Ned balked at
| using text/plain with extra tags. (Thomas suggested the tags to let
| in-the-know MUAs take automatic action, and Ned balked there, too.)
| Experimenting with subtypes was a fine idea, but it hasn't been a
| complete success. I'm happy to back off to text/plain, and I'm happy
| with the extra tags.
One alternative, that may or not be as controversial as adding parameters
to Content-Type, would be to add a parameter to Content-Disposition
instead, e.g.:
Content-Disposition: inline; signed=pgp
This isn't what content-disposition parameters are for either: They are
supposed to be used to elaborate on the chosen disposition, in a fashion
similar to how media type parameters elaborate on the media type.
Another approach would be to make this a new content-disposition, however, the
default semantics of an unknown disposition (treat as attachment) are nowhere
near as good as the default semantics for an unknown text subtype (show or
offer to show the data to the user). There's also the issue that existing
dispositions seem largely (but not entirely) orthogonal to whether or not the
object is clearsigned.
This has the benefit of leaving Content-Type as-is, and its also easily
accessible to IMAP clients via the IMAP BODYSTRUCTURE response, removing
the need for such clients to retrieve individual MIME part headers, which
they would otherwise have to do if some X-Content header were used. The
argument against this is that this change may be against the original
design for Content-Disposition.
It is not, however, something existing client dispatch mechanisms are likely to
support. Support for dispatch based on media type is widely supported.
So there are five alternatives to choose from:
1) Do nothing (actually promote better support/understanding for PGP/MIME)
I note that several people appear to favor this approach. I certainly have
no problem with this choice.
2) Add a parameter to Content-Type
I find this unacceptable for the multiple reasons I've already given.
3) Use a different text subtype for Content-Type
This is the approach I favor.
4) Add a parameter to Content-Disposition
This has many of the same problems as adding a new content type parameter.
5) Add a new MIME part header
Yuck.
Ned