Re: Latin 1 in non-MIME news postings?

[Karl Kleinpaste <karl@jprc.com>]

Stainless Steel Rat <ratinox@peorth.gweep.net> 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.