Because I think the same decoupling can be achieved in a
bottom-up deployment of the classical PEM. MIME-PEM is a
bottom-up deployment of PEM but it requires MIME.
You see this as a disadvantage. I see it as a HUGE advantage. MIME gives me the
machinery I need to do everything in PEM but the cryptography. Support for all
this stuff is already in my product, to say nothing of being in lots of other
products as well. Leveraging off this very large code base is highly
desireable.
Any sort of integration into existing messaging agents is hard -- be it MIME or
PEM or whatever. But the problem with classic PEM is that I end up paying the
cost twice, once for MIME and once for PEM. With MIME/PEM I only pay once, and
in lots of cases its already paid for.
As for those without MIME, MIME/PEM is not appreciably harder to implement than
classic PEM when there's no MIME engine around. As a matter of fact I'd say it
is considerably easier, given the way things are labelled in each scheme.
I have a MIME mailer. I have been waiting for a MIME/PEM integration for
*years* now. How long should I wait before giving up on this working group?
MIME/PEM does not replace classic PEM. Classic PEM still works.
It is an addition to it, and should speed adoption of PEM in general
(including classic PEM, I suspect).
I resist the idea that we should wait on defining how to use PEM in MIME until
there is wider deployment of non-MIME PEM, which is what you seem to be asking
for.
I completely agree. I tried to implement classic PEM within my MIME mailer, but
it was just too complex and never worked well enough.
Ned