Mime-Version and no Content-Type

Mime-Version and no Content-Type

[Lars Magne Ingebrigtsen]

All messages sent out by Message these days bear a "Mime-Version: 1.0" 
header, whether the contents of the message is exciting or not.  From
my reading of RFC2045, this is how things are supposed to be.  A
message that does not contain a Mime-Version header should be assume
by the recipient to be something that is sent out by an agent that is
not MIME-aware, and no assumptions can be made of the body of the
message.

A message with a Mime-Version header and without a Content-Type header 
(RFC2045 says) should be interpreted as a "text/plain;
charset=us-ascii" message.  Furthermore, a message that is
"Content-Type: text/plain; charset=us-ascii" and
"Content-Transfer-Encoding: 7bit" 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?)

So, naturally, some MTAs, when faced with a message that has a MV
header and no CT header slap on a "text/plain; charset=unknown-8bit"
header.

Eh.

So.  Should message start plonking in CT and CTE headers on all
messages it sends out to make these MTAs happy?

(For instance, people who use Outlook to read their mail will have all 
mail from Gnus users presented as attachments.  *snicker*)

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@ifi.uio.no * Lars Magne Ingebrigtsen

Re: Mime-Version and no Content-Type

[Karl Kleinpaste]

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.

Re: Mime-Version and no Content-Type

[Steinar Bang]

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

Re: Mime-Version and no Content-Type

[Hrvoje Niksic]

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.

Re: Mime-Version and no Content-Type

[Steinar Bang]

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

Re: Mime-Version and no Content-Type

[Lars Magne Ingebrigtsen]

Steinar Bang <sb@metis.no> writes:

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

Yup.  Does RFC2045 (or any of the following) say anything at all about 
adding headers that express default values, and whether that is nice
or not?  I can't find anything...

Anyway, we live in the real world, and since not adding the CT and CTE
header breaks other people's stupid software, I think Gnus should
always add CT and CTE.

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: Mime-Version and no Content-Type

[Harry Putnam]

Hrvoje Niksic <hniksic@srce.hr> writes:

Looking at Hrvoje's message brings to mind a somewhat related, but very minor
nitpick.   A friend helping me get mail working properly on a
laptop I'm using,  noticed my "MIME" header and commented that this is
normally in uppercase as shown in Hrvoje's quotes:

>    Default RFC 822 messages without a MIME Content-Type header are taken

>    the presence of a MIME-Version header field and the absence of any

 My setup always shows the mime header like so:

Mime-Version: 1.0

Is this something that is normally set locally?  Or is there anything
to the idea that it should be in upper-case?

-- 
Harry Putnam <reader@newsguy.com>
Running Redhat Linux 5.1

Re: Mime-Version and no Content-Type

[Colin Rafferty]

Harry Putnam writes:

> A friend helping me get mail working properly on a
> laptop I'm using,  noticed my "MIME" header and commented that this is
> normally in uppercase as shown in Hrvoje's quotes:

>  My setup always shows the mime header like so:

> Mime-Version: 1.0

RFC 822 (section 3.4.7.) explicitly says that case doesn't matter in
headers tags, and you can do anything you want:

        When matching any other syntactic unit, case is to be ignored.
        For  example, the field-names "From", "FROM", "from", and even
        "FroM" are semantically equal and should all be treated ident-
        ically.

Personally, I think that capitalizing each word is the easiest to
read.  Especially in my own headers.

-- 
Colin

Re: Mime-Version and no Content-Type

[Harry Putnam]

Colin Rafferty <craffert@ms.com> writes:

> Harry Putnam writes:
> 
> > A friend helping me get mail working properly on a
> > laptop I'm using,  noticed my "MIME" header and commented that this is
> > normally in uppercase as shown in Hrvoje's quotes:
> 
> >  My setup always shows the mime header like so:
> 
> > Mime-Version: 1.0
> 
> RFC 822 (section 3.4.7.) explicitly says that case doesn't matter in
> headers tags, and you can do anything you want:
> 
>         When matching any other syntactic unit, case is to be ignored.
>         For  example, the field-names "From", "FROM", "from", and even
>         "FroM" are semantically equal and should all be treated ident-
>         ically.
> 
> Personally, I think that capitalizing each word is the easiest to
> read.  Especially in my own headers.

Me too.

The point mentioned earlier may be some sort of agreed courtesy,
rather than a hard RFC type rule.  Possibly becaue there is some older
software in common  use that only recognizes upper case MIME.

Does this ring a bell with anyone?

-- 
Harry Putnam <reader@newsguy.com>
Running Redhat Linux 5.1

Re: Mime-Version and no Content-Type

[Lars Magne Ingebrigtsen]

Harry Putnam <reader@newsguy.com> writes:

> The point mentioned earlier may be some sort of agreed courtesy,
> rather than a hard RFC type rule.  Possibly becaue there is some older
> software in common  use that only recognizes upper case MIME.

Is there such a beast?

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: Mime-Version and no Content-Type

[Harry Putnam]

Lars Magne Ingebrigtsen <larsi@gnus.org> writes:

> Harry Putnam <reader@newsguy.com> writes:
> 
> > The point mentioned earlier may be some sort of agreed courtesy,
> > rather than a hard RFC type rule.  Possibly becaue there is some older
> > software in common  use that only recognizes upper case MIME.
> 
> Is there such a beast?

Haven't researched this myself but here is a quote from the friend
mentioned earlier that points to some documentation:

This is quoted from a recieved message


 >> Harry Putnam in <m3n24m4c79.fsf@reader.newsguy.com>:
 >> 
 >> > I've gotten myself into a discussion with Gnus developers on the mail
 >> > list "ding@gnus.org"  Mentioning your point about my mime headers as
 >> > below has quickly brought me to the end of my non-extensive knowledge.
 >> > 
 >> > Can you explain How your reasoning ran on that again?   : )
 >> 
 >> Sure, Harry. No problem. 
 >> 
 >> First off, mime postdates rfc822 so it's not really appropriate
 >> to be quoting rules from that rfc, however correct they might be.
 >> Rfc 822 does state the correct general case though, as one of
 >> your correspondents pointed out. 
 >> 
 >> I don't have full references on this point, although it's quite
 >> well known, but it appears that there are some mime
 >> implementations which parse for the "mime" portion of
 >> "MIME-Version" in upper case only, failing to recognise any other
 >> case. 
 >> 
 >> This is a breach of the mime rfcs as well, which specifically
 >> state that these headers are case insensitive. Once the genie is
 >> out of the bottle, though, the problem becomes one of
 >> interoperability rather than standards. 
 >> 
 >> A quick search of my internet drafts finds the following
 >> reference in the usefor ietf working group (revising rfc 1036)
 >> 
 >> | draft-ietf-usefor-article-01
 >> |
 >> |           Header-names are case-insensitive. There is a preferred case
 >> |           convention, which posters and posting agents SHOULD use:
 >> |           each hyphen-separated "word" has its initial letter (if any)
 >> |           in uppercase and the rest in lowercase, except that some
 >> |           abbreviations have all letters uppercase (e.g. "Message-ID"
 >> |           and "MIME-Version"). The forms used in this standard are the
 >> |           preferred forms for the headers described herein. Relaying and
 >> |           reading agents MUST, however, tolerate articles not obeying
 >> |           this convention.
 >> 
 >> That maintains the case insensitive rule but provides a SHOULD on
 >> the preferred format of the upper case version. It doesn't say
 >> why they're "preferred" in this case so it could be quoted there
 >> purely for stylistic reasons. 
 >> 
 >> The drums ietf working group (revising rfc 821/822) don't cover
 >> this topic because their charter specifically excludes any
 >> consideration of mime. 
 >> 
 >> Cheers
 >> 
 >> Jim Hill
 >> 
-- 
Harry Putnam <reader@newsguy.com>
Running Redhat Linux 5.1

Re: Mime-Version and no Content-Type

[Hrvoje Niksic]

Harry Putnam <reader@newsguy.com> writes:

>  >> > Can you explain How your reasoning ran on that again?   : )
>  >> 
>  >> Sure, Harry. No problem. 
>  >> 
>  >> First off, mime postdates rfc822 so it's not really appropriate
>  >> to be quoting rules from that rfc, however correct they might
>  >> be.

This makes no sense, given that MIME is explicitly designed to fit
into rfc822.

>  >> I don't have full references on this point, although it's quite
>  >> well known, but it appears that there are some mime
>  >> implementations which parse for the "mime" portion of
>  >> "MIME-Version" in upper case only,

I don't consider this "well-known" at all.  Never heard of it myself.

>  >> | draft-ietf-usefor-article-01
>  >> |
>  >> |           Header-names are case-insensitive. There is a preferred case
>  >> |           convention, which posters and posting agents SHOULD use:
>  >> |           each hyphen-separated "word" has its initial letter (if any)
>  >> |           in uppercase and the rest in lowercase, except that some
>  >> |           abbreviations have all letters uppercase (e.g. "Message-ID"
>  >> |           and "MIME-Version").

As I said: aesthetics, pure and simple.

Re: Mime-Version and no Content-Type

[Hrvoje Niksic]

Harry Putnam <reader@newsguy.com> writes:

>  My setup always shows the mime header like so:
> 
> Mime-Version: 1.0
> 
> Is this something that is normally set locally?  Or is there
> anything to the idea that it should be in upper-case?

No, it's only a matter of aesthetics.  To most people `MIME-Version'
looks slightly nicer than `Mime-Version'.

Re: Mime-Version and no Content-Type

[François Pinard]

Hrvoje Niksic <hniksic@srce.hr> writes:

> Harry Putnam <reader@newsguy.com> writes:

> >  My setup always shows the mime header like so:
> > 
> > Mime-Version: 1.0
> > 
> > Is this something that is normally set locally?  Or is there
> > anything to the idea that it should be in upper-case?

> No, it's only a matter of aesthetics.  To most people `MIME-Version'
> looks slightly nicer than `Mime-Version'.

For one, when I had to generate such headers, I used `MIME-Version' not
by personal taste, but because it was written this way in the MIME RFC's
(if I remember correctly :-).

-- 
François Pinard                            mailto:pinard@iro.umontreal.ca
Join the free Translation Project!    http://www.iro.umontreal.ca/~pinard

Re: Mime-Version and no Content-Type

[Hrvoje Niksic]

François Pinard <pinard@iro.umontreal.ca> writes:

> > No, it's only a matter of aesthetics.  To most people `MIME-Version'
> > looks slightly nicer than `Mime-Version'.
> 
> For one, when I had to generate such headers, I used `MIME-Version'
> not by personal taste, but because it was written this way in the
> MIME RFC's (if I remember correctly :-).

Yes, but the very same RFC explicitly states that all header names are 
case-insensitive.

Re: Mime-Version and no Content-Type

[Dale Hagglund]

Hrvoje Niksic <hniksic@srce.hr> writes:

> François Pinard <pinard@iro.umontreal.ca> writes:
> 
> > For one, when I had to generate such headers, I used `MIME-Version'
> > not by personal taste, but because it was written this way in the
> > MIME RFC's (if I remember correctly :-).
> 
> Yes, but the very same RFC explicitly states that all header names are 
> case-insensitive.

Oh come on, who reads documentation?  Isn't the real concern here
providing for broken mail readers that have been programmed ``by
example''.

The *safest* thing to do is probably to use the capitalization shown
in the MIME RFCs in outgoing messages.  I don't think the aesthetics
of it are all that relevant, since gnus doesn't normally show us the
MIME-Version (or Mime-Version, or mImE-vErSiOn, or whatever) header
anyway.

Dale.

Re: Mime-Version and no Content-Type

[Hrvoje Niksic]

Dale Hagglund <rdh@best.com> writes:

> > Yes, but the very same RFC explicitly states that all header names
> > are case-insensitive.
> 
> Oh come on, who reads documentation?

Anyone who wants their mail reader *not* to be totally broken.  Has
anyone provided a specific example of a mail reader known to be broken 
that way?

> Isn't the real concern here providing for broken mail readers that
> have been programmed ``by example''.

The example is provided by the very documentation you claim noone to
read.

Please get my point right here: I *prefer* `MIME-Version' to
`Mime-Version'; I've even sent out a patch that changes what
message.el emits, but I want things named correctly.  Emitting
MIME-Version vs. emitting Mime-Version is aesthetics.  Parsing
MIME-Version but not parsing Mime-Version is brokenness.

If there is a mailer that parses internet headers case-sensitively, it 
will break before it goes out of the house.

> The *safest* thing to do is probably to use the capitalization shown
> in the MIME RFCs in outgoing messages.  I don't think the aesthetics
> of it are all that relevant,

Of course it is; aestheics is the reason why that particular case was
used in the RFCs.

Re: Mime-Version and no Content-Type

[Lars Magne Ingebrigtsen]

Hrvoje Niksic <hniksic@srce.hr> writes:

> > Oh come on, who reads documentation?
> 
> Anyone who wants their mail reader *not* to be totally broken.

That would be half the mail reader writing population, then.  :-)

> Has anyone provided a specific example of a mail reader known to be
> broken that way?

I haven't seen anyone giving a specific example; no.  It would be
interesting to know.

(The MIME tests I had people try out were all with "Mime-Version", and 
all the readers did grok them as MIME messages, so it would seem that
at least the bigger mail readers (Outlook, Mozilla, Eudora, etc.) do
this OK.)

-- 
(domestic pets only, the antidote for overdose, milk.)
  larsi@gnus.org * Lars Magne Ingebrigtsen

Re: Mime-Version and no Content-Type

[Hrvoje Niksic]

Lars Magne Ingebrigtsen <larsi@ifi.uio.no> writes:

> So, naturally, some MTAs, when faced with a message that has a MV
> header and no CT header slap on a "text/plain; charset=unknown-8bit"
> header.

Not only that (see my and Zlatko's reports); Solaris' /usr/bin/mail
slaps `Content-Type: text' in the same circumstances, which is perhaps 
even worse.

> So.  Should message start plonking in CT and CTE headers on all
> messages it sends out to make these MTAs happy?

Yes.  That's what I proposed in my bug report, too.