Re: Mime-Version and no Content-Type

[Hrvoje Niksic <hniksic@srce.hr>]

Steinar Bang <sb@metis.no> writes:

> >>>>> Karl Kleinpaste <karl@justresearch.com>:
> 
> > Lars Magne Ingebrigtsen <larsi@ifi.uio.no> writes:
> >> ...should have neither of these headers actually included, since
> >> they are the default values and carry no information.  (But I'm
> >> unable to see where RFC2045 says this right now -- did I imagine it?)
> 
> > Not exactly.  I don't recall it in 2045 specifically, but it is
> > definitely present elsewhere, e.g., in Spencer's son-of-1036.
> 
> I most violently disagree with son-of-1036 in this respect, and think
> the CT and CTE headers should always be present.

Then you also disagree with rfc2045?  Here is the quote Lars doesn't
recall:

5.2.  Content-Type Defaults

   Default RFC 822 messages without a MIME Content-Type header are taken
   by this protocol to be plain text in the US-ASCII character set,
   which can be explicitly specified as:

     Content-type: text/plain; charset=us-ascii

   This default is assumed if no Content-Type header field is specified.
   It is also recommend that this default be assumed when a
   syntactically invalid Content-Type header field is encountered. In
   the presence of a MIME-Version header field and the absence of any
   Content-Type header field, a receiving User Agent can also assume
   that plain US-ASCII text was the sender's intent.  (...)

So, when SoR1036 says:

          Headers that merely state defaults explicitly (e.g., a Fol-
          lowup-To header with the same content as the Newsgroups
          header, or a MIME Content-Type header with contents
          "text/plain; charset=us-ascii") or state information that
          reading agents can typically determine easily themselves
          (e.g. the length of the body in octets) are redundant, con-
          veying no information whatsoever.

...it is in accordance with rfc2045.