I'm amending my original proposal to use octet-stream as follows:
Content-Type: application/octet-stream; conversions="x-AppleSingle"
(or x-MacBinary, etc.)
This is fine. I don't know if the conversions stuff is going to survive the
next round of standards activity with MIME's move to draft standard, but until
there's a standard subtype for AppleSingle and/or MacBinary this is the right
way to do it.
However, in the case of encrypted RIPEM msgs, the name option should
be explicitly excluded to avoid revealing this information.
You can even include the name option simply by nesting everything inside one
extra multipart structure. I'm not sure how much this reveals in any case; I
suppose that depends on context.
Use of name= does not depend on this particular usage in any case. It can be
used with any application/octet-stream (and another proposed enhancement
to MIME is to replace this with a filename= parameter that can be used with
any content type).
Come to think of it, we'd best add some language about this to the MIME-PEM
document. I'll take care of it.
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?
Ned