🚀 go-pugleaf

Thus said andyr@wizzy.com (Andy Rabagliati):
>TW> I think pgp data should go so:
>TW> 
>TW> Content-Type: text/plain; charset=ISO-8859-1
>TW> Content-transfer-encoding: X-PGP-{VERSION}
>TW> 
>TW> Where {VERSION} would be: 2.0, 2.1, etc...
>TW> 
>TW> This would allow the benefit of transferring text, sounds,
>TW> graphics, etc...

Quoting from RFC 1341:

            However, unlike Content-Types and subtypes, the creation  of
            new   Content-Transfer-Encoding  values  is  explicitly  and
            strongly  discouraged,  as  it  seems   likely   to   hinder
            interoperability  with  little potential benefit.  Their use
            is allowed only  as  the  result  of  an  agreement  between
            cooperating user agents.

What's wrong with merely using a new Content-Type, something like
application/x-pgp or message/x-pgp, and having an encapsulated
Content-Type: contain the actual variety of data?

Or, you could model it after the MIME-PEM standard, and make a
multipart/x-pgp type.  That would be the ideal solution, but it's only
worth doing if you thing PGP's current mechanism for message
formatting will really become the (or at least a) long-term standard.

Including version is a good idea, but it doesn't need to be part of
the subtype, you can just throw in version=2.1.

Creating a new Content-Transfer-Encoding is a very bad idea.
-- 
Marc VanHeyningen    mvanheyn@whale.cs.indiana.edu    MIME & RIPEM accepted

What's the use of a good quotation if you can't change it?
		- Doctor Who