From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/19904 Path: main.gmane.org!not-for-mail From: Steinar Bang Newsgroups: gmane.emacs.gnus.general Subject: Re: Mime-Version and no Content-Type Date: 16 Dec 1998 18:44:21 +0100 Sender: owner-ding@hpc.uh.edu Message-ID: References: NNTP-Posting-Host: coloc-standby.netfonds.no Mime-Version: 1.0 X-Trace: main.gmane.org 1035158169 13982 80.91.224.250 (20 Oct 2002 23:56:09 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Sun, 20 Oct 2002 23:56:09 +0000 (UTC) Return-Path: Original-Received: from karazm.math.uh.edu (karazm.math.uh.edu [129.7.128.1]) by sclp3.sclp.com (8.8.5/8.8.5) with ESMTP id MAA24814 for ; Wed, 16 Dec 1998 12:45:29 -0500 (EST) Original-Received: from sina.hpc.uh.edu (lists@Sina.HPC.UH.EDU [129.7.3.5]) by karazm.math.uh.edu (8.9.1/8.9.1) with ESMTP id LAB29958; Wed, 16 Dec 1998 11:45:12 -0600 (CST) Original-Received: by sina.hpc.uh.edu (TLB v0.09a (1.20 tibbs 1996/10/09 22:03:07)); Wed, 16 Dec 1998 11:44:47 -0600 (CST) Original-Received: from sclp3.sclp.com (root@sclp3.sclp.com [204.252.123.139]) by sina.hpc.uh.edu (8.7.3/8.7.3) with ESMTP id LAA05615 for ; Wed, 16 Dec 1998 11:44:39 -0600 (CST) Original-Received: from viffer.oslo.metis.no (viffer.oslo.metis.no [195.0.254.249]) by sclp3.sclp.com (8.8.5/8.8.5) with ESMTP id MAA24793 for ; Wed, 16 Dec 1998 12:44:28 -0500 (EST) Original-Received: (from sb@localhost) by viffer.oslo.metis.no (8.8.7/8.8.7) id SAA24867; Wed, 16 Dec 1998 18:44:21 +0100 Original-To: ding@gnus.org In-Reply-To: Hrvoje Niksic's message of "16 Dec 1998 17:39:18 +0100" User-Agent: Gnus/5.070065 (Pterodactyl Gnus v0.65) XEmacs/20.4 (Emerald) Precedence: list X-Majordomo: 1.94.jlt7 Original-Lines: 54 Xref: main.gmane.org gmane.emacs.gnus.general:19904 X-Report-Spam: http://spam.gmane.org/gmane.emacs.gnus.general:19904 >>>>> Hrvoje Niksic : > 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...