Although I like some of the current PEM-MIME (MIME-PEM) draft
I think it has a number of problems. The main one is that there are
alot of MIME implementations out there now and from what I have seen
adding a multipart/headerset type is going to mean alot of code changes.
As you probably know, I agree with you insofar as the current header-set
mechanism goes. However, this is a separate issue from MIME-PEM and is
in the process of being dealt with in the header-set proposal itself.
Once we have a way to deal with header-set parameterization I believe most
of the more serious implementation problems go away.
Having the PEM stuff wrapped in an application/pem part does not need
changes.
I agree that fewer changes are needed. However, the larger question is whether
we should go for the cheap fix and the limitations it imposes or try to do this
right the first time. The issue of PGP integration is a good case in point. The
MIME-PEM proposal makes dual signatures pretty easy.
The main problem with the current PEM standard is that there is no mechanism
to allow some headers to be put into and then extracted from the enhanced
text. If we allowed a PEM content-domain for RFC822-Message with specifies
that there are some 822 header lines at the start of the enhanced text
then the alternative proposal of content domain MIME is covered already.
This is precisely what Jeff Schiller's proposal does now. By changing the
semantics of the inner object from plain text to a MIME object, you can
have all the headers you want in there, with whatever semantics you like.
The meaning of header lines such as From and To in an enhanced header
are not defined since they will have been excluded from the normal re-writing
that takes place. But Mime related headers can be used.
Actually, you can have From: and To: in there as well in either encapsulation
scheme, since both allow for nested messages. The lack of rewriting is the
price you pay for protecting them with a signature.
Ned