-----BEGIN PGP SIGNED MESSAGE-----
In <34786ED3(_dot_)13100E24(_at_)systemics(_dot_)com>, on 11/23/97
at 12:58 PM, Ian Grigg <iang(_at_)systemics(_dot_)com> said:
Adam Back wrote:
Doesn't seem like a big deal implementation-wise -- the complexity
saving of removing the checksum probably more than compensates for
having to output and parse a fixed Content-Type: string.
I don't think it is a big deal implementation-wise either. It is
deployment that is my concern. Changing all those servers over, changing
all the scripts over, upgrading all pgp script copies to handle mime
because they can no longer get the AA keys from where ever they got them
from before.
All those interoperability issues can be solved in one of two ways: by
having one software source (as in pgp2.6 up to nowish) and by having a
standard that insists on interoperable feature sets.
We write standards to solve the problem of interoperability in the
absence of common source. We do not write standards to make it easier to
implement, except as a secondary opportunity.
As interoperability is the issue, IMNSHO, and everything that is out
there with the label PGP attached to it uses Armour, then Armour it is.
Add MIME to the standard if we believe this is the "way to go" by all
means. But that's in the opportunity basket, not the interoperability
basket. People like Dave Crocker are going to be possible proven "right"
by events here But this is small change compared to the cost of
breaking the current user base, no matter how "wrong" it might be.
I think that there is another issue regarding Ascii-Armor that is beeing
missed. That of compatability between OpenPGP implementations.
While most of the debate has centered around providing backward
compatablity with the current user base I have some concers regarding
future implementations.
What is going to happen when OpenPGP from vendor A sends a rfc822
clearsigned message to OpenPGP from vendor B who has not implemented the
Ascii-Armor code??
You could add a large set of preferance codes to the public key outlining
the capabilities of the various implementations but this restricts
portability of keys between implementations. Also it only is vaible in a
one->one communications. In a one->many environment (which PGP is quite
frequently used) you need a core set of functions that ALL implementations
support.
- --
- ---------------------------------------------------------------
William H. Geiger III http://users.invweb.net/~whgiii
Geiger Consulting Cooking With Warp 4.0
Author of E-Secure - PGP Front End for MR/2 Ice
PGP & MR/2 the only way for secure e-mail.
OS/2 PGP 2.6.3a at: http://users.invweb.net/~whgiii/pgpmr2.html
- ---------------------------------------------------------------
-----BEGIN PGP SIGNATURE-----
Version: 2.6.3a-sha1
Charset: cp850
Comment: Registered_User_E-Secure_v1.1b1_ES000000
iQCVAwUBNIULFo9Co1n+aLhhAQLqZAQAw1raIQBNKmez9FabQ9VqXqQfUUzmtLWx
za5xHMRNcER1OUY1qZVFNzcyM944lgDwvWO7cpOflGtCDUJGp2gEKRHQceq/FqaG
6I1jrQ93zTVXGchumoYqcC41+3bgs8O/yIj4E7ghfvDMPTAJjHLoEL/iIEntOdMC
aSeZFsveUZI=
=LmVg
-----END PGP SIGNATURE-----