-----BEGIN PGP SIGNED MESSAGE-----
Paul Hoffman / IMC wrote:
At 07:29 PM 10/20/97 -0500, William H. Geiger III wrote:
There is no need to modify the MIME toolkit or at least none above what
must be already done to accommodate incorporating PGP/MIME types. The
ascii armor encoding is handled by PGP and would be included in any PGP
toolkit a programmer may be using.
I don't understand why you think that everyone will use a PGP toolkit. One
of the main purposes of us doing the open spec work is so that people don't
have to use anyone else's toolkits. If we assume everyone will use a PGP
toolkit, there's no need to do this work in the IETF. Simply let PGP, Inc.
specify what is PGP x.y and be done with it.
This is a confusion of the two meanings of PGP - another issue in itself
that must be sorted out before we can really finish the standard.
Every programmer will use a toolkit that implements PGP format tools.
Whether they choose the one supplied by PGP, Inc is up to them.
Or, to put it another way, if your programmers are not using a toolkit,
then you have more problems than worrying about Ascii Armouring. In all
probability, they are using an old codebase that needs replacing with a
proper toolkit. PGP Inc have one, I recall there are a few floating
around, including a couple in the <plug> Cryptix </plug> libraries.
As a matter of fact any Open PGP
implementation would require a programmer be able to use ascii armor so
his program can process messages generated by older version of PGP.
We definitely have the option of requiring that. We also have the option of
not requiring it.
We only theoretically have the option to not require it. The number of
people using anything other than 2.6 or thereabouts is minute compared
to the installed base of "classic" PGP. Any clues on how many copies of
5.* have been sold?
You
are not seriously advocating that an Open PGP application be unable to
process these older formats are you??
I most certainly am. If the IETF Calendaring and Scheduling Working Group,
for example, wants to use OpenPGP for handing around scheduling events in
an automated environment (that is, without human intervention), there is
absolutely no reason why the must be able to process older PGP formats. If
our spec requires that they do so, it is that much harder for them to chose
it over competing specs.
Hardly. They simply choose not to choose on the basis of this unneeded
feature. All products are standardised around a set of features that is
good for most of the people and perfect for none of them. Ignoring
non-specific features is part of their selection process.
OpenPGP can be useful for many types of applications other than humans
sending email to each other. Many other IETF messaging protocols can use
the privacy and authentication offered by OpenPGP. They would have
absolutely no use for backwards compatibility with earlier versions.
True, we can construct these scenarios. Fact is, the majority of
implementators and the majority of interested parties are here because
they have existing applications, existing code bases, existing needs.
We'll worry about futures once we get out code into shape.
This isn't to say that we shouldn't try to get software to be able to
process and possibly even emit messages from earlier versions, but there is
no reason to *force* them to because what we specify will be complete and
secure by itself. We should make it as easy as possible for some who starts
with OpenPGP to add support for earlier versions without burdening them
with implementation issues that aren't relevant to OpenPGP.
"Complete and secure" is not the only goal. Standardisation necessarily
accomodates the existing implementations. Are you seriously suggesting
that the process of standardisation would ignore major features of
existing implementations, such as the favoured method of message
passing? That's not standardisation as I know it; that's a new
protocol.
This is silly, I really can't see anyone saying "I'm not going to support
PGP because it uses ASCII armor encoding".
By itself, no. But if we require lots of other things that make it that
much harder for people to implement (such as requiring them being able to
handle all the earlier packet formats), they will probably have the same
attitude as they have had up to now: "I won't bother". That hurts all of
us, and is one of the driving forces for us to make a simple and useful spec.
A simple and useful spec that doesn't talk to the millions of 2.6 users
out there is an contradiction in terms, at least if we are still talking
about standardisation. Just look at the chaos in the market place as
people bump into the allegedly compatible PGP 5 programs with their
incompatible default keys. Not that I don't sympathise with PGP Inc for
their patent grumbles, but what made them think the users would accept
PGP Inc's problems with willing arms? Users don't give a damn, they
just want to send messages. And if the messages don't get through, then
the program doesn't work.
- --
iang systemics.com
FP: 1189 4417 F202 5DBD 5DF3 4FCD 3685 FDDE on pgp.com
-----BEGIN PGP SIGNATURE-----
Version: Cryptix 2.21
iQCVAgUANEwe2pUdDk1bRs+FAQGr7gP+JkLK+XOKDskm9kdLSsklbw9PlAjWDPgW
MH+9btupRhMUezTaOt2jraja3sH3m9BxXOFcNE/7wk82yQmtald2eOplh6bRYMei
hx5m9vAEmIYnZfv33eBpGBP0v4uhpuP8grSo94DIAT+ZOuc3Qa1o2aNGCwW+o195
9ZXNJMV+NJM=
=AQFD
-----END PGP SIGNATURE-----