RE: MIME-Version Header Field

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