RFC 1342

RFC 1342 🎀 Representation of Non-ASCII Text in Internet Message Headers

okay bestie, here's the title block tea ☕

• Request for Comments: 1342 💖
• Title: Representation of Non-ASCII Text in Internet Message Headers
• Working group: Network Working Group 🧚
• Author: K. Moore, University of Tennessee 👑
• Date: June 1992 📅
• Category: IAB standards track protocol 🔥
• Obsoletes / Updates: not listed in this title block 🙈

Status of this Memo 📋

so this RFC is an IAB standards track protocol for the Internet community, and it's literally asking for discussion and suggestions for improvements 🫶 For the standardization state and status of this protocol, go check the current edition of the "IAB Official Protocol Standards" 📚 That's your source of truth, periodt. Distribution of this memo is unlimited 🌈

Abstract ✨

okay so this memo adds an extension to the message format from [1] (the IETF Mail Extensions Working Group calls it "RFC 1341" 🎀) so you can put character sets other than ASCII into RFC 822 message headers 💅 It was designed to be highly compatible with existing Internet mail handling software, and easy to implement in mail readers that support RFC 1341 🦋

Introduction 🌸

bestie, RFC 1341 is giving body parts 💖 It lets you label textual body parts that are coded in different character sets, and it has ways to turn those bodies into sequences of printable ASCII 🧁 This memo does the same vibe for the header of an RFC 822 [2] message 🧚 and it's built so existing mail software is unlikely to get confused 🙈

Honestly, the quirks of existing mail programs are the real main character 💀 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. Some mail reading programs also have trouble parsing headers that are legal according to RFC 822 but use backslash-quoting to "hide" special characters such as "<", ",", or or which exploit other infrequently-used features of that specification 😭

It's unfortunate that these programs don't correctly interpret RFC 822 headers, but to "break" them would cause severe operational problems for the Internet mail system 💅 So the extensions in this memo do not rely on little-used features of RFC 822 ✨ Instead, certain sequences of "ordinary" printable ASCII characters (which are assumed to be unlikely to otherwise appear in message headers) are reserved for use as encoded data 🍓 The characters used in these encodings are restricted to those which do not have special meanings in the context where the encoded text appears 🫶

Encodings 🎀

An "encoded-word" is a sequence of printable ASCII characters that begins with =?, ends with ?=, and has two ?s in between 🦋 It specifies a character set and an encoding method, and it also includes the original text encoded as ASCII characters, following the rules for that encoding method 💖

A mail composer that implements this specification will provide a way to input non-ASCII text in header fields, but will translate those fields (or the right portions of them) into encoded-words before inserting them into the message header 💅

A mail reader that implements this specification will recognize encoded-words when they show up in certain portions of the message header 👑 Instead of displaying the encoded-word "as is," it will reverse the encoding and display the original text in the designated character set ✨

An "encoded-word" is more precisely defined by the following EBNF grammar, using the notation of RFC 822:

encoded-word = "=" "?" charset "?" encoding "?" encoded-text "?" "="

charset = token    ; legal charsets defined by RFC 1341

encoding = token   ; Either "B" or "Q"

token = 1*<Any CHAR except SPACE, CTLs, and tspecials>

tspecials = "(" / ")" / "<" / ">" / "@" / "," / ";" / ":" / "\" /
            <"> / "/" / "[" / "]" / "?" / "." / "="

encoded-text = 1*<Any printable ASCII character other than "?" or
               ; SPACE> (but see "Use of encoded-words in message
               ; headers", below)

An encoded-word may not be more than 75 characters long, including charset, encoding, encoded-text, and delimiters 🙈 If you need to encode more text than fits in one encoded-word of 75 characters, you can use multiple encoded-words (separated by SPACE or newline) 🧩 Message header lines that contain one or more encoded-words should be no more than 76 characters long ✨ NOTE: These restrictions are included not only to ease interoperbility through internetwork mail gateways, but also to impose a limit on the amount of lookahead a header parser must employ (while looking for a final ?= delimiter) before it can decide whether a token is an encoded-word or something else 🧠

Initially, the legal values for "encoding" are "Q" and "B" 💜 These encodings are described below. The "Q" encoding is recommended for use with Latin character sets, and the "B" encoding for all others. Still, a mail reader which claims to recognize encoded-words MUST be able to accept either encoding for any character set which it supports 🔥

Only a subset of the printable ASCII characters may be used in encoded-text 🎀 The SPACE character is not allowed, so the beginning and end of an encoded-word are obvious 👀 The "?" character separates the various portions of an encoded-word from one another, so it cannot appear in the encoded-text portion 🙅‍♀️ Other characters are also illegal in certain contexts. For example, an encoded-word in a "phrase" preceeding an address in a From header field may not contain any of the "specials" defined in RFC 822 💅 Finally, certain other characters are disallowed in some contexts, to keep messages that pass through internetwork mail gateways reliable 🫶

The "B" encoding automatically meets these requirements 💖 The "Q" encoding lets a wide range of printable characters be used in non-critical locations in the message header (e.g., Subject), with fewer characters available for other locations 🌈

The "B" encoding 🧁

The "B" encoding is identical to the "BASE64" encoding defined by RFC 1341 ✨

The "Q" encoding 🦋

The "Q" encoding is similar to the "Quoted-Printable" content-transfer-encoding defined in RFC 1341 🌸 It's designed so text that's mostly ASCII can be read on an ASCII terminal without decoding 👑

1. Any 8-bit value may be represented by a = followed by two hexadecimal digits. For example, if the character set in use were ISO-8859-1, the = character would be encoded as =3D, and a SPACE by =20 💅
2. The 8-bit hexadecimal value 20 (e.g., IS0-8859-1 SPACE) may be represented as _ (underscore, ASCII 95.). (This character may not pass through some internetwork mail gateways, but its use will greatly enhance readability of "Q" encoded data with mail readers that do not support this encoding.) Note that the _ always represents hexadecimal 20, even if the SPACE character occupies a different code position in the character set in use 🍓
3. 8-bit values which correspond to printable ASCII characters other than =, ?, _ (underscore), and SPACE may be represented as those characters. (But see "Use of encoded-words in message headers," below.) 🧚

Character sets 🌈

In an encoded-word, the character set tied to the unencoded text is specified by a charset 💖 A charset can be any of the character set names allowed in an RFC 1341 "charset" parameter of a "text/plain" body part. (See section 7.1.1 of RFC 1341 for a list of valid charset parameters.) 📚

When there's a possibility of using more than one character set to represent the text in an encoded-word, and in the absence of private agreements between senders and recipients of a message, it is recommended that members of the ISO-8859-* series be used in preference to other character sets 🫶 Among the various ISO-8859-* character sets, the lowest-numbered set that contains all of the required characters should be used 🔢

Use of encoded-words in message headers 💅

A sequence of one or more encoded-words is used to represent non-ASCII textual data within a header field 🎀 An encoded-word must be separated from an adjacent encoded-word, "word", "text", "ctext", or "special" by a linear white-space character or a newline 🧩 When displaying a particular header field" (in the RFC 822 sense) containing one or more encoded-words, an unencoded SPACE character that immediately follows the encoded-word is not displayed 👀 A newline that immediately follows an encoded-word is not displayed unless the encoded-word is the last token in that "field". (This lets you use multiple encoded-words for long strings of unencoded text, without having to split encoded-words wherever spaces occur in the unencoded text 🌸)

An encoded-word may appear in a message header or body part header according to the following rules:

• An encoded-word may replace a "text" token (as defined by RFC 822) in: (1) a Subject or Comments header field, (2) any extension message header field, (3) any user-defined message header field, or (4) any RFC 1341 body part header field (such as Content-Description) for which the field body contains only "text"s ✨
• An encoded-word may appear within a comment delimited by "(" and ")", i.e., wherever a "ctext" is allowed. More precisely, the RFC 822 EBNF definition for "comment" is amended as follows 🧠

comment = "(" *(ctext / quoted-pair / comment / encoded-word) ")"

A "Q"-encoded encoded-word which appears in a comment MUST NOT contain the characters "(", ")", or "\" 🙅‍♀️

• As a replacement for a "word" entity within a "phrase," for example one that precedes an address in a From, To, or Cc header. The EBNF definition for phrase from RFC 822 thus becomes 💖

phrase = 1*(encoded-word / word)

In this case the set of characters that may be used in a "Q"-encoded encoded-word is restricted to: <upper and lower case ASCII letters, decimal digits, "!", "*", "+", "-", "/", "=", and "_" (underscore, ASCII 95.)> 🦋

These are the ONLY locations where an encoded-word may appear. In particular, an encoded-word MUST NOT appear in any portion of an "address". In addition, an encoded-word MUST NOT be used in a Received header field 🚫 Lowkey the strictest part of the whole thing 😤

Whenever such words appear in a header being displayed, an enlightened mail reader will decode the text and render it appropriately 👑

Only textual data (printable and white space characters) should be encoded using this scheme 🌈 However, since these encoding schemes allow the encoding of arbitrary 8-bit values, mail readers that implement this decoding should also make sure that displaying the decoded data on the recipient's terminal won't cause unwanted side-effects 🫶

Using these methods to encode non-textual data (e.g., pictures or sounds) is not defined by this memo 🙈 Using encoded-words to represent strings of purely ASCII characters is allowed, but discouraged 💅

Recognition of encoded-words in message headers 🦋

okay so how do you tell an encoded-word apart from a regular "word", "text", or "ctext"? 👀 here's the vibe check: an encoded-word begins with =?, ends with ?=, contains exactly four ? characters including the delimiters, and is followed by a SPACE or a newline. ✨ if the "word", "text", or "ctext" doesn't pass those tests, it should be displayed as it appears in the message header. no cap, that's the whole check 💅

if the mail reader doesn't support the character set used, it may either display the encoded-word as ordinary text (exactly as it appears in the header) or swap in a message saying the decoded text couldn't be displayed. 🙈 both are valid choices, periodt 💖

Conformance ✨

okay now the rules, bestie 📜

if your mail composing program claims compliance with this specification, it MUST make sure that any string of printable ASCII characters in a message header that begins with "=?" and ends with "?=" is a valid encoded-word. 💌 no skipping this one!

a mail reading program that claims compliance must be able to tell encoded-words apart from "text", "ctext", or "word"s anytime they show up in appropriate places in message headers. 👀 it must be able to display unencoded text if the character set is "US-ASCII" 🫶 and, for the ISO-8859-* character sets, it must at least be able to display the characters that are also in the ASCII set. 🌸

Examples 🎀

here are the examples, straight from the source, no edits 💖

   From: =?US-ASCII?Q?Keith_Moore?= <moore@cs.utk.edu>
   To: =?ISO-8859-1?Q?Keld_J=F8rn_Simonsen?= <keld@dkuug.dk>
   CC: =?ISO-8859-1?Q?Andr=E9_?= Pirard <PIRARD@vm1.ulg.ac.be>
   Subject: =?ISO-8859-1?B?SWYgeW91IGNhbiByZWFkIHRoaXMgeW8=?=
    =?ISO-8859-2?B?dSB1bmRlcnN0YW5kIHRoZSBleGFtcGxlLg==?=

   From: =?ISO-8859-1?Q?Olle_J=E4rnefors?= <ojarnef@admin.kth.se>
   To: ietf-822@dimacs.rutgers.edu, ojarnef@admin.kth.se
   Subject: Time for ISO 10646?

   To: Dave Crocker <dcrocker@mordor.stanford.edu>
   Cc: ietf-822@dimacs.rutgers.edu, paf@comsol.se
   From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= <paf@nada.kth.se>
   Subject: Re: RFC-HDR care and feeding
   From: Nathaniel Borenstein <nsb@thumper.bellcore.com>
        (=?iso-8859-8?b?7eXs+SDv4SDp7Oj08A==?=)
   To: Greg Vaudreuil <gvaudre@NRI.Reston.VA.US>, Ned Freed
   <ned@innosoft.com>,
        Keith Moore <moore@cs.utk.edu>
   Subject: Test of new header generator
   MIME-Version: 1.0
   Content-type: text/plain; charset=ISO-8859-1

References 📚

• [1] Borenstein N., and N. Freed, "MIME (Multipurpose Internet Mail Extensions): Mechanisms for Specifying and Describing the Format of Internet Message Bodies", RFC 1341, Bellcore, Innosoft, June 1992.
• [2] Crocker, D., "Standard for the Format of ARPA Internet Text Messages", RFC 822, UDEL, August 1982.

Security Considerations 🔒

Security issues are not discussed in this memo. 💀 literally zero words on security here, so keep that in mind, bestie.

Author's Address 🦋

Keith Moore
University of Tennessee
107 Ayres Hall
Knoxville TN 37996-1301

EMail: moore@cs.utk.edu