From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/16673 Path: main.gmane.org!not-for-mail From: Karl Kleinpaste Newsgroups: gmane.emacs.gnus.general Subject: Re: Latin 1 in non-MIME news postings? Date: 03 Sep 1998 13:35:40 -0400 Sender: owner-ding@hpc.uh.edu Message-ID: References: NNTP-Posting-Host: coloc-standby.netfonds.no X-Trace: main.gmane.org 1035155507 29237 80.91.224.250 (20 Oct 2002 23:11:47 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Sun, 20 Oct 2002 23:11:47 +0000 (UTC) Return-Path: Original-Received: from gizmo.hpc.uh.edu (gizmo.hpc.uh.edu [129.7.102.31]) by sclp3.sclp.com (8.8.5/8.8.5) with ESMTP id NAA00715 for ; Thu, 3 Sep 1998 13:36:45 -0400 (EDT) Original-Received: from sina.hpc.uh.edu (sina.hpc.uh.edu [129.7.3.5]) by gizmo.hpc.uh.edu (8.7.6/8.7.3) with ESMTP id MAF06767; Thu, 3 Sep 1998 12:07:49 -0500 Original-Received: by sina.hpc.uh.edu (TLB v0.09a (1.20 tibbs 1996/10/09 22:03:07)); Thu, 03 Sep 1998 12:36:36 -0500 (CDT) Original-Received: from sclp3.sclp.com (root@sclp3.sclp.com [209.195.19.139]) by sina.hpc.uh.edu (8.7.3/8.7.3) with ESMTP id MAA00170 for ; Thu, 3 Sep 1998 12:36:23 -0500 (CDT) Original-Received: from pocari-sweat.jprc.com (POCARI-SWEAT.JPRC.COM [207.86.147.217]) by sclp3.sclp.com (8.8.5/8.8.5) with ESMTP id NAA00704 for ; Thu, 3 Sep 1998 13:36:11 -0400 (EDT) Original-Received: (from karl@localhost) by pocari-sweat.jprc.com (8.8.7/8.8.7) id NAA20993; Thu, 3 Sep 1998 13:35:40 -0400 Original-To: ding@gnus.org X-Face: "5(T0tZd{6}pd~YzBG8O/*EW,.]6]@`m^e;fv65W^Y&=d"M\1H}>T~4_.kcDD.O~y3k)a6h R;Nmi>9|>Nm${2IpM0^RcUEa\jcq?KOP)C&~x51l~zCHTulL^_T|u0I^kB'z@]{`2YjQu In-Reply-To: Stainless Steel Rat's message of "03 Sep 1998 12:30:43 -0400" Original-Lines: 94 User-Agent: Pterodactyl Gnus v0.13/XEmacs 20.4 - "Emerald" Precedence: list X-Majordomo: 1.94.jlt7 Xref: main.gmane.org gmane.emacs.gnus.general:16673 X-Report-Spam: http://spam.gmane.org/gmane.emacs.gnus.general:16673 Stainless Steel Rat writes: > MIME in and of itself sits on top of RFC 822. MIME specifies that 8-bit > data be encoded into a 7-bit format, usually base64. > Recent incarnations of SMTP allow for 8-bit data over 8-bit clean networks > between 8-bit clean MTAs, (ab)using aspects of MIME to accomplish this. And later writes: > Vanilla MIME is 100% compliant with RFC 822. 8-bit data is *NOT* allowed > in a MIME message; it must be encoded into a 7-bit format. Nonsense, as even a minimal review of the RFCs shows. MIME specifies no such thing as a 7bit encoding requirement. "Vanilla MIME" is explicitly an extension of RFC822 beyond its original intended domain. MIME specifies that 8bit data has the identity transformation when "Content-Transfer-Encoding: 8bit" is present. MIME sits comfortably atop both RFC822 format and RFC821 transport, as RFC-modified for 8bit data passage (e.g., RFC1652, RFC2045) -- and the RFCs specifically state that such formats and transports have been redefined and extended -- so that it is by no means "(ab)using aspects of MIME" to do so. For the pedantic, relevant RFC citations follow. --karl RFC 2045, _MIME Part 1_, Format of Internet Message Bodies, page 1, Abstract: ...This set of documents, collectively called the Multipurpose Internet Mail Extensions, or MIME, redefines the format of messages to allow for ^^^^^^^^^ (1) textual message bodies in character sets other than US-ASCII... ...Because RFC 822 said so little about message bodies, these documents are largely orthogonal to (rather than a revision of) RFC 822. Page 3, Introduction: One of the notable limitations of RFC 821/822 based mail systems is the fact that they limit the contents of electronic mail messages to relatively short lines (e.g. 1000 characters or less [RFC-821]) of 7bit US-ASCII. This forces users to convert any non-textual data that they may wish to send into seven-bit bytes representable as printable US-ASCII characters... Page 4: This document describes several mechanisms that combine to solve most of these problems... (3) A Content-Transfer-Encoding header field, which can be used to specify both the encoding transformation that was applied to the body and the domain of the result. Encoding transformations other than the identity transformation are usually applied to data in order to allow it to pass through mail transport mechanisms which may have data or character set limitations. Page 14, Content-Transfer-Encoding Header Field: Many media types which could be usefully transported via email are represented, in their "natural" format, as 8bit character or binary data. Such data cannot be transmitted over some transfer protocols... ...Proper labelling of unencoded material in less restrictive formats for direct use over less restrictive transports is also desireable. This document specifies that such encodings will be indicated by a new "Content- Transfer-Encoding" header field. This field has not been defined by any previous standard. Pages 15-16, Content-Transfer-Encoding Semantics: Three transformations are currently defined: identity, the "quoted- printable" encoding, and the "base64" encoding. The domains are "binary", "8bit" and "7bit". The Content-Transfer-Encoding values "7bit", "8bit", and "binary" all mean that the identity (i.e. NO) encoding transformation has been performed. As such, they serve simply as indicators of the domain of the body data... ...[E]stablishing only a single transformation into the "7bit" domain does not seem possible. 8bit data is perfectly legal, as-is, in a MIME context (i.e. identified as such), when riding through an RFC1652 8bit transport.