At 02:37 PM 11/15/1997 +0000, Ian Brown wrote:
I'm not sure what you mean. Do you mean safely holding an object while
it is transmitted by mail?
Armour was a very necessary part of PGP. But now we have MIME, which is
meant for the same purpose - safely transmitting binary data across
7-bit or less mail systems.
Same primary purpose, and it we were starting from scratch there'd be no need
for two similar but different systems. But we're not -
all the existing versions of PGP generate and read PGP-armor,
some parts of even PGP 5.0 don't have a mechanism for inputting MIME or binary,
like the Encrypt/Decrypt/Sign/Verify-From-Clipboard mechanisms,
and you'll lose compatibility with all of them if you drop armor.
MIME, on the other hand, tries to do far more than just armor,
with lots of complexity, registered object types, unregistered object types,
interaction with mail systems that should maybe leave the encrypted part alone,
and a whole lot of other ballast that may not belong in a pocket organizer.
And mail user agents aren't the only places people use PGP.
I'm not arguing that we should totally do away with armour - just that I
don't think it should be a MUST, so that people who want to use OpenPGP
in their program or standard minimally, with no need for backwards
compatibility, can do it with as little problem as possible.
Losing compatibility may be worthwhile for avoiding patent encumbrances,
but it's a serious mistake for an "OpenPGP" to do so just for aesthetic purity.
If you want S/MIME, use S/MIME. If you want PGP, you need to interact with PGP.
I agree that there were other choices of armor that PRZ should have used,
like uuencode or maybe btoa, but this is what we've got.
Meanwhile, while ASCII armor may mean adding another MIME type,
the amount of code involved is a small part of the total,
and it's easy for an OpenPGP program to tell which input it's getting.
Bill Stewart, stewarts(_at_)ix(_dot_)netcom(_dot_)com
Regular Key PGP Fingerprint D454 E202 CBC8 40BF 3C85 B884 0ABE 4639