At 06:01 PM 11/25/97 -0800, Jon Callas wrote:
or transmitted in any environment that may not be safe to raw binary data.
so does MIME.
For example, PGP key servers transmit keys both to and from the server in
so can MIME.
Armor is also useful for future applications.
so is MIME.
Lastly, there are systems that use (or would like to use) PGP over systems
that are not the internet.
Then they are not relevant to an Internet standards process.
Furthermore, I disagree with this strongly. MIME is a preferrered way (by
MIME is the standard way. As I try to make clear, that's not just a matter
of bureaucratic formaltiy, it is a matter of actual use. The purpose of a
standard is to achieve interoperability. The more choices there are, the
less interoperability there is.
Absent a strong claim as to the technical superiority of armour or
something else, the only reason to support an alternative mechanism which
does the same job is... well, nothing constructive.
text describing it was done by Paul Hoffman, who used MIME as a base. So
it's quite easy to do both.
The question remains: what functional basis is there for retaining
armouring in the standards-based specification. The argument of
compatibility with the pre-standards installed base has already been
countered for a number of different issues, not just armouring. The idea
of possible uses in the future is an argument for MIME, not a legacy
mechanism.
The compromise that I, as editor am working with (with thanks to Ian Brown,
who came up with it) is as follows:
Jon, those who serve as working group chairs and document editors have a
difficult job. They are usually senior, talented folk. They get to work
hard and almost never are adequately appreciated.
Worst of all, they are often architects who do not see their own
preferences chosen.
The editor of an IETF working group document is required to be responsive
to the rough consensus of the working group. I hope no one has forgotten
this minor point.
(1) I'm going to remove anything in OP-FORMAT that requires the use of
ascii armor. Following my touchstone that any feature needed for backwards
compatibility is a SHOULD, it'll be a SHOULD.
Now if you just move it to an appendix and note that it has been the basis
for "packaging" PGP in pre-standards versions of the technology, then we'd
be in perfect shape. This would leave the document with one standard way
to do the packaging, but with full documentation about the prior
(non-standard) way of doing it.
d/
--------------------
Dave Crocker
dcrocker(_at_)imc(_dot_)org
Internet Mail Consortium +1 408 246 8253
675 Spruce Dr. fax: +1 408 249 6205
Sunnyvale, CA 94086 USA info(_at_)imc(_dot_)org ,
http://www.imc.org