Thank you for your response,
please note that the question is whether the _inner_ MIME-entity should have
MIME-Version included or not.
They argue as follows:
"Here are some arguments why the MIME-version header field should not be
required in an inner entity of a S/MIME message. I have chosen to refer to
the most recent RFC versions since these hopefully address some of the
ambiguities of the preceding versions.
In RFC 2045 (MIME Part One) chapter 3 "MIME Header Fields" the formal
definition of "entity-headers" does not contain the version header. The
version header is only part of "MIME-message-headers". And since RFC 3851
(S/MIME Version 3.1) concerns securing "MIME entities" it seems reasonable
to require the "entity-headers" to be included in the inner MIME entity but
not the "MIME-message-headers". Of course the outer S/MIME message itself
should have a version header. This itself implies (per definition) that the
contents (inner entity) is a MIME entity which thereby is described by the
"entity-headers" Content-Type etc."
I would be very happy to settle, this.
The key question is whether or not the inner object can be (a) a MIME
object, (b) an RFC 822 message, or (c) Something else. If only (a) is
possible then you're dealing with a MIME entity and the MIME version field
is superfluous. If (b) or (c) are possible then you're supposed to include
the field and use it to tell whether or not you're dealing with a MIME
object. (In practice most agents assume MIME is being used when they see
a competent content-type field, irrespective of MIME-Version. But this
isn't what the specifications call for.)
Ned