Subject: SV: MIME-Version or not?

From: Joachim Abrahmsén <[email-masked]>
Date: Mon, 5 Jun 2006 15:04:29 +0200

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.

Best regards

Joachim Abrahmsén

-----Ursprungligt meddelande-----
Från: Paul Hoffman [mailto:[email-masked]]
Skickat: den 31 maj 2006 17:26
Till: Joachim Abrahmsén; [email-masked]
Ämne: Re: MIME-Version or not?

At 5:14 PM +0200 5/31/06, Joachim Abrahmsén wrote:
>Hi,
>
>The energy sector in Sweden decided to use S/MIME for exchanging
>EDIFACT-messages between different actors, where an EDIFACT-message is
>encoded in an inner MIME-entity (RFC 1767). However, an interoperability
>issue have turned up.
>
>Some system developers have interpreted the RFC's as the 'MIME-Version'
>should only be included in the outer MIME-entity and not in the inner
>MIME-entity, while others have included 'MIME-Version' in both inner and
>outer MIME-entity.
>
>When I read section 3.1 of RFC 2311 (S/MIME v2) and RFC 3851 (S/MIME 3.1) I
>would say that 'MIME-Version' should be included in both inner and outer
>MIME-entity as they are unrelated.

That is certainly how I would interpret it. What is the logic of the
people who say that there should not be a MIME-version on the outer
message?

--Paul Hoffman, Director
--Internet Mail Consortium

---

From: Ned Freed <[email-masked]>
Date: Mon, 05 Jun 2006 11:03:25 -0700 (PDT)

> 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

---

From: Joachim Abrahmsén <[email-masked]>
Date: Wed, 7 Jun 2006 13:32:27 +0200

Well, I thought the RFC's where designed to handle all cases you mention,
i.e. (a), (b) and (c) below, even if we only use case (a) for now. We prefer
not to make any assumptions about the contents of the inner object and would
like to follow the RFC's in order to achieve interoperability, even with
implementors outside our group (Swedish energy sector).

Should there be 'MIME-Version' or not in the _inner_ MIME-entity of an
S/MIME enveloped e-mail?
Is there a contradiction between the RFC's, or are we missing something?

Best regards

Joachim Abrahmsén

				Ned

---

From: "Bonatti, Chris" <[email-masked]>
Date: Wed, 7 Jun 2006 09:58:18 -0400

In theory, you're probably correct, but I think this is more of a
hidden assumption than a contradiction.  The operative assumption
seems to be that systems dealing with (a) and (b) might all use
CMS, they would not generally need to interoperate.  However,
this is not a very strong rationale for omitting the version.

Apart from the MIME design, I would say that the context of
whether the object is (a), (b) or (c) is usually quite clear from
the system context in which it's operating.  This kind of
discussion also occurred when we drafted RFCs 3854 and 3855 (CMS
with X.400).  On my secure e-mail client, I receive RFC 822
without exception.  On my X.400 client, I receive CMS wrapped
X.400 content without exception.  In my local file system, the
things I encrypt are files without exception.  The context is
clear in all cases, and never do the different cases need to
interoperate directly because they belong to different content
universes.  Now if you had some system that might handle RFC 822,
generalized MIME objects, and X.400 content and do something
sensible with each, you might have a problem (though I expect
differentiating these would not be hard anyway).  However, I have
never seen such a animal.

This is not so much a reason for omitting the MIME version, as a
explanation for where we are.

If you wanted to introduce this requirement, the trick would be
to do so in a way that does not declare the bulk of S/MIME
products already out there to be broken.

Regards,
Chris

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]] On Behalf Of Joachim
Abrahmsén
Sent: Wednesday, June 07, 2006 07:32
To: Ned Freed
Cc: Paul Hoffman; [email-masked]
Subject: SV: SV: MIME-Version or not?

Well, I thought the RFC's where designed to handle all cases you
mention, i.e. (a), (b) and (c) below, even if we only use case
(a) for now. We prefer not to make any assumptions about the
contents of the inner object and would like to follow the RFC's
in order to achieve interoperability, even with implementors
outside our group (Swedish energy sector).

When I read section 3.1 of RFC 2311 (S/MIME v2) and RFC 3851
(S/MIME 3.1) I would say that 'MIME-Version' should be included
in both inner and outer MIME-entity as they are unrelated.

Should there be 'MIME-Version' or not in the _inner_ MIME-entity
of an S/MIME enveloped e-mail? Is there a contradiction between
the RFC's, or are we missing something?

Best regards

Joachim Abrahmsén

> please note that the question is whether the _inner_
MIME-entity 
> should
have

> "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.

> 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