Other than that, my one remaining question is whether or not RIPEM is really
an
alternative to PEM that's always going to be a distinct entity in its own
right. If so, specification of what this alternative looks like (either in
another RFC or in some document an RFC can reference) is an essential part of
defining application/ripem adequately. If not, then why not just use
multipart/pem and application/pem?
For this, I will wait until Mark Riordan returns and responds. The only
reason I brought this
up is because RIPEM is currently far from being compatible with PEM (although
RIPEM does use
the standard PEM boundaries!) and because Mark's User's Guide in its
instructions for use with
ELM's MIME features makes reference to application/ripem.
The advice to use application/ripem is mine, originally; I suggested it as
a quick (and dirty) way to increase RIPEM/mailer integration. I later
realized that this is in error; it should of course be application/x-ripem.
However, the correct solution is probably to use application/pem, once
the MIME/PEM interaction becomes more formalized. For now application/ripem
just makes using RIPEM more convenient for us...
Bill.