MIME-Version Header Field

> however, leaving it out violates the specification.

I would agree with that - RFC 2045 says "MUST include such a header
field" (that's not a MAY or a SHOULD), so it MUST be present in the
outgoing BEEP message a peer sends and MUST be verified to be present in
the incoming BEEP message a peer receives. 

However, if a BEEP implementation did this, it would currently
interoperate with no peer that is based on any existing BEEP
implementation - none of them use it! 

I see three possible solutions:

Solution 1) A BEEP implementation adds MIME-Version Header to all
outgoing messages, and does not accept any incoming messages without it
- a strict reading of the MIME and BEEP specs would mandate this. The
first message a peer will receive will be the greeting message on
channel zero, and RFC 3080 says "If a poorly-formed reply is received on
channel zero, the session is terminated without generating a response,
and it is recommended that a diagnostic entry be logged."

Solution 2) A BEEP implementation provides a (locally defined)
configuration option that specifies whether to add MIME-Version headers
on outgoing messages, and another configuration option that states
whether to REQUIRE it on incoming messages.  

Solution 3) That the MIME-Version header be added without changing any
of the implementations - the only way to do this is that in some future
revision, section 2.2. of RFC 3080 be updated with one line about the
MIME-Header:
"2.2 Messages and Frames
   A message is structured according to the rules of MIME.  Accordingly,
   each message may begin with "entity-headers" (c.f., MIME's Section 3
   [1]).  If none, or only some, of the "entity-headers" are present:
   o  the default "Content-Type" is "application/octet-stream"; and,
   o  the default "Content-Transfer-Encoding" is "binary".   
   o  the default "MIME-Version" is "1.0"."  <<<---------------- new
line

I would favour option 3. Is that acceptable to others?

=================================================

Jered Floyd wrote:

> While BEEP messages are structured according to the rules of MIME,
> I don't consider them to be RFC 2045's "Internet message bodies" ..

BEEP is a MIME-compliant protocol, and so should certainly comply with
all aspects of RFC 2045. I would certainly think that BEEP messages are
"Internet message bodies". Other protocols (e.g. HTTP) state they are
not MIME compliant, but reuse some of the MIME concepts (e.g. RFC 2616's
section 19.4.1) but have flexibility in what aspects of MIME they permit
(e.g. multiple body parts). 

Eamon