Subject: [BEEPwg] MIME-Version Header Field

From: "Eamon O'Tuathail" <[email-masked]>
Date: Mon, 23 Sep 2002 16:53:28 +0100

Do BEEP messages require the MIME-Version header field?

RFC 2045 states:

 "Messages composed in accordance with this document MUST include such
  a header field, with the following verbatim text:

     MIME-Version: 1.0"

As BEEP carries MIME messages, one could argue that MIME-Version is a
mandatory header. 

However, the main practical purpose of this header is to tell a RFC
(2)822 user agent that the message they receive is MIME or not - as BEEP
messages are always MIME, it is not needed (unless someone decides to
invent a new version of MIME, which seems unlikely for the near future).

Eamon

_______________________________________________
BEEPwg mailing list
[email-masked]
http://lists.beepcore.org/mailman/listinfo/beepwg

---

From: Jered Floyd <[email-masked]>
Date: 23 Sep 2002 13:00:20 -0400

> As BEEP carries MIME messages, one could argue that MIME-Version is a

(For those playing along with the home game, this is RFC 2045 
Section 4, "MIME-Version Header Field".)

I interpret the "Messages" in the quoted sentence to mean "RFC 822
messages", since this RFC is all w.r.t Internet message bodies.
While BEEP messages are structured according to the rules of MIME,
I don't consider them to be RFC 2045's "Internet message bodies"
and thus are exempt from needing the MIME-Version header.

All existing specifications and implementations of which I am aware
do not use the MIME-Version header.

--Jered

---

From: Dave Crocker <[email-masked]>
Date: Mon, 23 Sep 2002 10:19:20 -0700

At 04:53 PM 9/23/2002 +0100, Eamon O'Tuathail wrote:
>messages are always MIME, it is not needed

however, leaving it out violates the specification.

information redundancy does not make things stop working.  violating a 
specification does.

d/

----------
Dave Crocker <mailto:[email-masked]>
TribalWise, Inc. <http://www.tribalwise.com>
tel +1.408.246.8253; fax +1.408.850.1850

---

From: Marshall Rose <[email-masked]>
Date: Mon, 23 Sep 2002 11:00:07 -0700

> information redundancy does not make things stop working.  violating a 

then there's the "be liberal in what you expect and conservative in what you generate" thing. conservatisms says you should always send it. liberalism says you should never care whether you receive it...

/mtr

ps: it's easy enough for me to add the one line to my implementation to generate it. i don't think i'm going to be modifying the mime package that i'm using to actually require it though...

/mtr

---

From: [email-masked]
Date: Mon, 23 Sep 2002 14:23:20 -0700 (PDT)

> As BEEP carries MIME messages, one could argue that MIME-Version is a

This is quite true, however, you've missed a crucial definition: When RFC 2045
talks about "messages" it is talking about RFC 822 messages specifically. This
is clearly stated in section 2.3.

I don't believe it is the case that BEEP is defined to carry RFC 822 messages,
so I don't believe this requirement applies to BEEP.

> invent a new version of MIME, which seems unlikely for the near future).

It isn't the main practical purpose of the header; it is the only purpose.

I should also point out that we have plenty of examples of protocols, including
some that deal with "messages", which use MIME labelling and do not see a need
to use a MIME-Version field. The obvious example here is HTTP.

				Ned

---

From: [email-masked]
Date: Mon, 23 Sep 2002 14:36:34 -0700 (PDT)

> and thus are exempt from needing the MIME-Version header.

Exactly right and even supported by a careful reading of RFC 2045.

				Ned

---

From: "Eamon O'Tuathail" <[email-masked]>
Date: Tue, 24 Sep 2002 00:35:11 +0100

Ned,

>> When RFC 2045 talks about "messages" it is talking about RFC 822
messages
>> specifically. This is clearly stated in section 2.3.

There are two aspects to RFC 822 messages - one we might call the
generic structure (we see this aspect reused by MIME entities, HTTP,
SIP, etc.) - it defines a generic message as divided into headers and
body by a CRLF, multipart bodies are supported, the headers are of the
format "<field-name>: <field-value>" and folding lines etc. are
supported. BEEP messages follow this aspect. 

The other aspect to RFC 822 is the mail related collection of headers
(From:, To:, Subject:, References:, etc.) and a variety of rules around
email format. BEEP messages certainly do not follow this aspect. 

RFC 822 and the MIME RFCs do not make this distinction, but other RFCs
do (e.g. HTTP - RFC2616, section 4.1). 

> I don't believe it is the case that BEEP is defined to carry RFC 822 
> messages, so I don't believe this requirement applies to BEEP.

So would it be accurate to state that BEEP carries MIME entities - BEEP
does not carry MIME messages? (RFC 3080, section 2.2 only states " A
message is structured according to the rules of MIME.", and then goes on
to discuss entity headers.)

If that is the case, then the BEEP message (the MIME entity) can only
carry MIME entity headers, and I agree that MIME message headers, such
as MIME-Version, are not needed.

Eamon

---

From: [email-masked]
Date: Tue, 24 Sep 2002 00:53:58 -0700 (PDT)

> supported. BEEP messages follow this aspect.

Yes, this is referred to as an entity in the MIME RFCs. See section 2.4 of RFC
2045.

> email format. BEEP messages certainly do not follow this aspect.

"Message" refers to a subset of possible RFC 822 messages in the MIME RFCs.

> do (e.g. HTTP - RFC2616, section 4.1).

On the contrary, this distinction is very clearly made in the MIME RFCs. Entity
and message are very different things and the MIME RFCs are careful to make
this distinction.

The issue here seems to be that how the MIME RFCs use the term message.
Unfortunately this is unavoidable given that MIME was intiially concieved
entirely in the context of email, which uses the term "message" in a fairly
specific way. But by the time RFC 2045-2049 came out it had become clear that
MIME constructs had broader applicability. That's why the term "entity" was
defined and the specifications were changed to use it when it was appropriate.

We went round and round and round on all this before RFCs 2045-2049 came out.

> to discuss entity headers.)

That would be correct. Saying something like a "a BEEP message is a MIME entity
as defined in RFC 2045 ..." or something similar would be a useful
clarification 

> as MIME-Version, are not needed.

Exactly.

				Ned

---

From: "Eamon O'Tuathail" <[email-masked]>
Date: Tue, 24 Sep 2002 16:33:33 +0100

Ned

Thanks for that - it is much clearer to me now. 

Eamon