There was also debate about
whether <application/pem> or <message/pem> would be the best answer,
with (as I recall) returns from some precincts suggesting different
answers for the cases of encrypted vs. signed-only messages.
The implicit encoding restriction that message/pem gives you is a real
advantage. Aside from this they are just names, really. And once again, I feel
we're in need of a quick fix now rather than waiting for a comprehensive
solution to come out later, so I'd opt for the one that gives the right results
right now and worry about cleaning it all up later when we've agreed on a Grand
Unified Message Format.
The MIME spec (RFC 1341, p. 8) describes the "message" Content-Type as
follows:
message -- an encapsulated message. A body of
Content-Type "message" is itself a fully formatted
RFC 822 conformant message which may contain its
own different Content-Type header field. The
primary subtype is "rfc822". The "partial"
subtype is defined for partial messages, to permit
the fragmented transmission of bodies that are
thought to be too large to be passed through mail
transport facilities. Another subtype,
"External-body", is defined for specifying large
bodies by reference to an external data source.
Is the statement "...is itself a fully formatted RFC 822 conformant
message..." actually intended to apply only to specific subtypes, or
does it refer to all subtypes of message? If the latter, inclusion of a
PEM object immediately following the proposed pair of MIME headers
appears illegal under the message type, since a PEM object doesn't
include the creation time, author ID, and at least one 822-format
address which are required in order to satisfy RFC 822 (sec 4.1) syntax.
--jl