Re: 8bit & binary

Harald.T.Alvestrand@uninett.no Wed, 24 May 1995 12:25 UTC

Received: from ietf.nri.reston.va.us by IETF.CNRI.Reston.VA.US id aa01848; 24 May 95 8:25 EDT
Received: from CNRI.Reston.VA.US by IETF.CNRI.Reston.VA.US id aa01844; 24 May 95 8:25 EDT
Received: from dimacs.rutgers.edu by CNRI.Reston.VA.US id aa04633; 24 May 95 8:25 EDT
Received: (from daemon@localhost) by dimacs.rutgers.edu (8.6.12+bestmx+oldruq+newsunq+grosshack/8.6.12) id HAA06157 for ietf-822-list; Wed, 24 May 1995 07:32:01 -0400
Received: from domen.uninett.no (domen.uninett.no [129.241.131.10]) by dimacs.rutgers.edu (8.6.12+bestmx+oldruq+newsunq+grosshack/8.6.12) with SMTP id HAA06154 for <ietf-822@dimacs.rutgers.edu>; Wed, 24 May 1995 07:31:48 -0400
Received: from dale.uninett.no by domen.uninett.no with SMTP (PP) id <07139-0@domen.uninett.no>; Wed, 24 May 1995 13:31:23 +0200
Received: from dale.uninett.no (localhost [127.0.0.1]) by dale.uninett.no (8.6.9/8.6.9) with ESMTP id NAA14252; Wed, 24 May 1995 13:31:20 +0200
Message-Id: <199505241131.NAA14252@dale.uninett.no>
X-Mailer: exmh version 1.5.3 12/28/94
Sender: ietf-archive-request@IETF.CNRI.Reston.VA.US
From: Harald.T.Alvestrand@uninett.no
To: Brent Stilley <UCCXBRS@vm1.ucc.okstate.edu>
cc: ietf-822@dimacs.rutgers.edu
Subject: Re: 8bit & binary
In-reply-to: Your message of "Tue, 23 May 1995 16:26:32 CST." <199505240005.UAA26145@dimacs.rutgers.edu>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Wed, 24 May 1995 13:31:19 +0200
X-Orig-Sender: hta@dale.uninett.no

You are probably thinking of draft-ietf-822ext-mime-conf-01.txt,
which says:

4.  MIME Conformance

....
A mail user agent that is MIME-conformant MUST:
....
 (2)   Recognize the Content-Transfer-Encoding header field
       and decode all received data encoded with either the
       quoted-printable or base64 implementations.  Any non-
       7-bit data that is sent without encoding must be
       properly labelled with a content-transfer-encoding of
       8bit or binary, as appropriate.  If the underlying
       transport does not support 8bit or binary (as SMTP
       [RFC821] does not), the sender is required to both
       encode and label data using an appropriate Content-
       Transfer-Encoding such as quoted-printable or base64.


It is hard to see how this means that support of ESMTP is required.
I think, however, that the prose *should* say that the behaviour of
one certain gateway, whihc rejected any message containing 
"Content-transfer-encoding: 7bit", is completely broken.

Even display of messages containing "Content-transfer-encoding: 8bit"
and arriving over unextended SMTP (the 7-and-sometimes-8-bit transport)
should be displayed, I think.

                 Harald A