Following up on Mark's msg. and the thread on supporting binaries in RIPEM, I
would like to suggest the following format, by example, and solicit your
input.
I think using a format similar to multipart/pem for RIPEM is a very good idea,
as long as RIPEM always intends to be a format distinct from PEM.
I'll also mention in passing that editing of a new version of MIME-PEM document
is for the most part done. I'm just waiting to get closure from the coauthors
before posting a new draft publicly. I expect it will be out in fairly short
order.
It is basically a modification of Steve Crocker's draft note on PEM/MIME
interaction. It differs in that I've defined application/ripem instead of
application/pem and that I've also additionally defined
application/encoded-file
subtype.
The application/ripem usage is fine. application/encoded-file, however, is at
best beyond the purview of this discussion and at worst totally superfluous.
Consider: There's already a perfectly reasonable subtype to carry
undifferentiated binary files; it is called application/octet-stream. Now, it
is perhaps true that apple-single requires indentification in its own right. If
so, then it needs to be a subtype of its own. However, this has nothing to do
with PEM. If you want to define a MIME subtype to carry apple-single
information by all means do so, but do it in a separate RFC, and discuss it
on the ietf-822 group. I know that various folks at Apple have been looking
at the problem of how to transport Macintosh files using MIME, but I have
yet to see an RFC describing this. One may not be too far off, however, and
by bringing this up on the ietf-822 group you'll probably be in a good position
to force this issue.
Ned