ietf-openpgp
[Top] [All Lists]

Re: New Draft... going forward

1997-10-20 18:04:30
In 
<3(_dot_)0(_dot_)3(_dot_)32(_dot_)19971020163740(_dot_)008bfc20(_at_)mail(_dot_)imc(_dot_)org>,
 on 10/20/97 
   at 04, Paul Hoffman / IMC <phoffman(_at_)imc(_dot_)org> said:

The primary reason ascii armor was chosen was for the case of encrypted
messages.  The way RFC2015 is currently worded, a non-MIME mail user can
simply pipe the whole message to pgp and everything will work just fine
without the need for any additional software.  It also makes even
MIME-compliant software easier to write.

I have to agree here, so long as there is a *large* userbase of 2.6.x
users Ascii Armor is far from outdated. I see very little advantage here
of switching from Ascii Armor to Base64 other than adding one more PITA
for backward compatibility.

The advantage is that using standard MIME is more easily specified and
implemented than using ASCII armor. That is, a developer who has a MIME
toolkit must modify that toolkit in order to use ASCII armor. Forcing
ASCII armor when it shows no noticable value over standard MIME is one
more impediment to new developers adopting OpenPGP.

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. 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. You
are not seriously advocating that an Open PGP application be unable to
process these older formats are you??

Another is that the spec does not fully specify how to do ASCII armor,
specifically how to create the checksum. Not only does the draft not
specify how to do this, it references a book that is "out of stock
indefinitely" according to the publisher.

That's what source code is for. :) Serriously I had not noticed that RFC
1991 did not have the checksum info and it should be updated to include
that info.

I strongly favor backward compatibility with the installed base, but not
at the expense of losing developers over unneeded features. Since a
description of ASCII armor has already been published (well, minus how to
do th checksums) in RFC 1991, any developer who cares about backward
compatibilty can become backward compatible.

This is silly, I really can't see anyone saying "I'm not going to support
PGP because it uses ASCII armor encoding". As far as I can see there is
nothing incompatible with using ascii armor in MIME formatted messages
neither can I see any significant improvement by not using it especially
considering the ability to process ascii armor messages will be required
in any PGP application for the forseeable future. Backward compatibility
is a serious issue, especially if you are working with one of the
"unblessed" Operating Systems.

-- 
---------------------------------------------------------------
William H. Geiger III  http://www.amaranth.com/~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://www.amaranth.com/~whgiii/pgpmr2.html                 
       
---------------------------------------------------------------


<Prev in Thread] Current Thread [Next in Thread>