Jeremey Barret wrote:
Plain old non-MIME ASCII-armored PGP is one of the most
useful crypto tools out there, not to mention the sole basis of PGP
integration into most mail readers that support it.
This actually misses one of the main benefits of MIME. In almost all
cases, a MIME-compliant mailer will do the decoding for you. If PGP/MIME
had a specific pgp-data type bodypart, *any* MIME-compliant mailer would
be configurable, upon receiving such a bodypart, to:
a) Remove the base64 (or whatever) encoding and
b) present the resulting binary data to any OP/PGP program
William Geiger wrote:
As far as KISS what can be more simpler than rfc822 with a PGP Ascii
Armor Block?
Binary data handed straight to your program?
This has further benefits:
Greg Vaudreuil wrote:
One of the strongest reasons to use MIME encoding, even for plain text
messages is MIME's ability to support multiple languages and character
sets. While I am new to PGP, I do not believe that multi-lingual
support is part of PGP 2.6.X.
There is some support for using different codepages for text. But Greg
points to the main problem with continued use of armour - we have to
continue solving exactly the same problems as the MIME people. Different
character sets (Unicode would be very useful, for instance), multi-part
messages, and so on are issues armour and MIME both have to deal with.
Why not just leverage the work the MIME people are doing?
Multilingual support is an IESG requirement for all IETF protocols
going forward. At a minimum this requires identification of the
selected character set, and in the mail context, a way to encooding
these 8 or 16 bit characters into a 7 bit transfer format such as
Quoted Printable.
I don't think PGP has an easy method of encoding 16-bit systems such as
Unicode.
Ian.