RE: MIME-Version Header Field

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

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

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

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

> RFC 822 and the MIME RFCs do not make this distinction, but other 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.

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

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 

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

Exactly.

				Ned