Re: Mime-Version and no Content-Type

[Steinar Bang <sb@metis.no>]

>>>>> Hrvoje Niksic <hniksic@srce.hr>:

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

No... can't see I disagree with anything here.

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

Nowhere in the 2045 quote above _recommends_ that headers are left
out.  At least nowhere I can see.  The quote only describes what
*should* happen if the headers aren't there.

The So1036 quote places this information into the group "redundant"
which is obviously wrong.  

"Obviously" because there is legacy software out there that uses
just-send-8 (here in Norway there is plenty), and there is MTA
software out there that tries to do cater to this software by being
"user friendly" and wrapping it in headers declaiming that it has
charset=iso-8859-1 and is CTE 8bit.

Explicitly marking something as text/plain with charset=us-ascii and a 
CTE of 7bit should make things more robust for email.

What it does for USENET I'm not sure about, since I can't guarantee
that people may not be looking at So1036 and make software that does
strange things with explicit markup of text/plain; charset=us-ascii or 
refuse a stamp-of-approval for this reason, or something...