[About the reason for message/pem-clear]
(2) It limits the amount of "automatic interoperation" that occurs with
MIME-aware MTAs and gateways.
The important point here is why (2) is a Good Thing and not a Bad Thing.
Unfortunately, the reasoning here requires a fair amount of technical MIME
knowledge, so please bear with me.
[rather long explanation deleted]
Thanks for the explanation. It would be nice to include something like
this is draft, though.
2) What is the reason for the "privacy" parameter to multipart/pem?
Doesn't it follow from the type of the first subpart and/or the
application/pem subpart?
Yes it does. If we retain message/pem-clear encapsulation I'll remove the
privacy parameter from multpart/pem. Sorry I missed this; I don't like
duplication of information that can only lead to silly states.
Exactly.
3) Would a non-MIME PEM-capable user agent be able to recognize MIME-encoded
PEM messages? Is it at all possible to achieve this?
However, such a reader can then only deal with PEM-izing and unPEM-izing MIME
messages; the actual MIME content may or may not make much sense. You clearly
cannot handle the full range of MIME without having some significant MIME
smarts.
Of course not, but is would be nice if at least text/plain messages just
``worked''. Otherwise you would need to choose between MIME-PEM and
non-MIME PEM when sending a message with a MIME-aware PEM implementation.
For this reason, and also because MIME is deploying a lot quicker than PEM is,
I think the more important question is how hard is fitting PEM capabilities
into a MIME reader. This turns out to be pretty easy given the fact that MIME
is so modular and therefore most MIME readers can be extended in a modular
fashion.
Of course, but backwards compatiblity is always nice to have if the
price is not too high.
--
Luc Rooijakkers Internet:
lwj(_at_)cs(_dot_)kun(_dot_)nl
Faculty of Mathematics and Computer Science UUCP: uunet!cs.kun.nl!lwj
University of Nijmegen, the Netherlands tel. +3180652271