Given the above, and the way MIME-PEM was introduced:
1) First drafts used "obsolete RFC 1422" (now re-phrased)
Hmm. I tend to discount this because it has been, in fact, rephrased.
We're not debating promoting past proposals.
2) Removal of the only Internet
reference implementation of RFC 1422
This is not true, unless TIS/PEM was granted special status as the reference
implementation in some way other than its simple availability (which is
certainly possible, but I must have missed it). RIPEM also implments RFC 1422
(it's what I use for "classic PEM" email), and version 2.0, which was recently
released, adds as much certificate and CRL support as TIS/PEM, and isn't tied
to MH (one of TIS/PEM's large drawbacks).
I also suspect that TIS could be fairly easily convinced to put TIS/PEM 6.1
back up as a reference implementation for non-MIME environments.
I am not convinced that the statement "MIME/PEM does nothing to
restrict the set of environments in which PEM can be deployed, only
to expand it." is an accurate portrayal of the reality and a
valid prediction for the future course of this WG.
At the risk of sounding cynical, the most valid prediction I feel I can make
for the future course of this WG, given both the current debate and the
archives of this mailing list, is that it will continue to rehash the same
arguments endlessly, while the user community and industry go their own way,
and PEM becomes relegated to becoming a historical curiousity, only used in
isolated enclaves. This is effectively where it is now, unless we define a
way to allow PEM and MIME to be used simultaneously.
I don't want to see that happen, since this group *has* done a lot of good
work, and has solved problems that other groups (such as the PGP community)
are just now discovering. I would rather adapt PEM to the market than try to
adapt the market to PEM. The latter is doomed to failure.
Amanda Walker
InterCon Systems Corporation