From donn@hpfcrn.fc.hp.com Tue Apr 14 21:28:04 1992 Received: from relay.hp.com by dkuug.dk via EUnet with SMTP (5.64+/8+bit/IDA-1.2.8) id AA16401; Tue, 14 Apr 92 21:28:04 +0200 Received: from hpfcrn.fc.hp.com by relay.hp.com with SMTP (16.6/15.5+IOS 3.13) id AA19368; Tue, 14 Apr 92 12:03:58 -0700 Received: from hpfcdonn.fc.hp.com by hpfcrn.fc.hp.com with SMTP (16.8/15.5+IOS 3.22) id AA03245; Tue, 14 Apr 92 13:03:46 -0600 Message-Id: <9204141903.AA03245@hpfcrn.fc.hp.com> To: xojig%xopen.co.uk@hplb.hpl.hp.com, WG15RIN@dkuug.dk Cc: ralph@techcomm.uniforum.org Subject: Non-ASCII mail Date: Tue, 14 Apr 92 12:03:44 MST From: Donn Terry X-Charset: ASCII X-Char-Esc: 29 I18n folks: I just received the following message, and thought you might be interested. The issue of having non-ASCII without breaking ASCII could be interesting. I don't have more details but they are available as described in the message. Donn - ------- Forwarded Message From: Internet Engineering Steering Group To: Bob Braden -- IAB Executive Director , Internet Activities Board Cc: Internet Engineering Task Force Subject: Protocol Action: Multipurpose Mail Extensions to Proposed Standard Date: Mon, 13 Apr 92 14:38:40 -0400 Sender: gvaudre@NRI.Reston.VA.US Message-Id: <9204131438.aa03848@ietf.NRI.Reston.VA.US> Recommendation: The IESG recommends that the Internet Drafts "MIME (Multipurpose Internet Mail Extensions)" and "Representation of Non-ASCII Text in Internet Message Headers" jointly as a Proposed Standard. These documents are the product of the Internet Message Extensions Working Group of the IETF. Abstract: These documents redefine the format of RFC 822 based messages to allow multi-part textual and non-textual message bodies and the use of non-ASCII character sets to be represented. The mechanisms defined in these two documents allows the use of non-ascii text in both the headers and bodies of mail messages. These changes are backward compatable and extend RFC 822. Technical Summary: MIME ---- RFC 822 defines a message representation protocol which specifies considerable detail about message headers, but which leaves the message content, or message body, as flat ASCII text. This document redefines the format of message bodies to allow multi-part textual and non-textual message bodies to be represented and exchanged without loss of information. This is based on earlier work documented in RFC 934 and RFC 1049, but extends and revises that work. Because RFC 822 said so little about message bodies, this document is largely orthogonal to (rather than a revision of) RFC 822. In particular, this document is designed to provide facilities to include multiple objects in a single message, to represent body text in character sets other than US- ASCII, to represent formatted multi-font text messages, to represent non-textual material such as images and audio fragments, and generally to facilitate later extensions defining new types of Internet mail for use by cooperating mail agents. Message Headers --------------- MIME describes a mechanism for denoting textual body parts which are coded in various character sets, as well as methods for encoding such body parts as sequences of printable ASCII characters. This memo describes similar techniques to allow the encoding of non-ASCII text in various portions of a RFC 822 [2] message header, in a manner which is unlikely to confuse existing message handling software. Like the encoding techniques described in MIME, the techniques outlined here were designed to allow the use of non-ASCII characters in message headers in a way which is unlikely to be disturbed by the quirks of existing Internet mail handling programs. In particular, some mail relaying programs are known to (a) delete some message header fields while retaining others, (b) rearrange the order of addresses in To or Cc fields, (c) rearrange the (vertical) order of header fields, and/or (d) "wrap" message headers at different places than those in the original message. In addition, some mail reading programs are known to have difficulty correctly parsing message headers which, while legal according to RFC 822, make use of backslash-quoting to "hide" special characters such as "<", ",", or ":", or which exploit other infrequently-used features of that specification. - ------- End of Forwarded Message ------- End of Forwarded Message