idnits 2.17.1 draft-ietf-822ext-mime-hdrs-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-19) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 14 longer pages, the longest (page 1) being 59 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 80 instances of too long lines in the document, the longest one being 3 characters in excess of 72. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 166: '... characters MUST NOT appear between ...' RFC 2119 keyword, line 233: '...f ASCII mode, it MUST contain addition...' RFC 2119 keyword, line 251: '... MUST be able to accept either encod...' RFC 2119 keyword, line 298: '..._" (underscore), MAY be represented as...' RFC 2119 keyword, line 300: '...r, SPACE and TAB MUST NOT be represent...' (16 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (1 June 1996) is 10184 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '2' on line 86 == Unused Reference: 'RFC 822' is defined on line 604, but no explicit reference was found in the text == Unused Reference: 'RFC CHARSET' is defined on line 606, but no explicit reference was found in the text == Unused Reference: 'RFC MIME-CONF' is defined on line 609, but no explicit reference was found in the text == Unused Reference: 'RFC MIME-IMB' is defined on line 612, but no explicit reference was found in the text == Unused Reference: 'RFC MIME-IMT' is defined on line 615, but no explicit reference was found in the text == Unused Reference: 'RFC MIME-REG' is defined on line 618, but no explicit reference was found in the text ** Obsolete normative reference: RFC 822 (Obsoleted by RFC 2822) == Outdated reference: A later version (-03) exists of draft-freed-charset-reg-00 ** Downref: Normative reference to an Informational draft: draft-freed-charset-reg (ref. 'RFC CHARSET') Summary: 12 errors (**), 0 flaws (~~), 9 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group K. Moore 2 Internet-Draft University of Tennessee 3 Expires: 1 December 1996 1 June 1996 5 MIME (Multipurpose Internet Mail Extensions) Part Three: 6 Message Header Extensions for Non-ASCII Text 8 draft-ietf-822ext-mime-hdrs-00.txt 10 Status of this Memo 12 This document is an Internet Draft. Internet Drafts are working 13 documents of the Internet Engineering Task Force (IETF), its Areas, 14 and its Working Groups. Note that other groups may also distribute 15 working documents as Internet Drafts. 17 Internet-Drafts are draft documents valid for a maximum of six 18 months. Internet-Drafts may be updated, replaced, or obsoleted by 19 other documents at any time. It is not appropriate to use an 20 Internet-Draft as reference material or to cite one other than as a 21 "working draft" or "work in progress". 23 To learn the current status of any Internet-Draft, please check the 24 1id-abstracts.txt listing contained in the Internet-Drafts Shadow 25 Directories on ds.internic.net (US East Coast), nic.nordu.net 26 (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific 27 Rim). 29 This document is a revision of RFC 1522. If approved by the IETF 30 message format extensions working group, it will be submitted to the 31 IESG as a candidate for Draft Standard status. Distribution of this 32 memo is unlimited. Please send comments to 33 ietf-822@dimacs.rutgers.edu. 35 Abstract 37 STD 11, RFC 822, defines a message representation protocol specifying 38 considerable detail about US-ASCII message headers, and leaves the 39 message content, or message body, as flat US-ASCII text. This set of 40 documents, collectively called the Multipurpose Internet Mail 41 Extensions, or MIME, redefines the format of messages to allow for 43 (1) textual message bodies in character sets other than US-ASCII, 45 (2) an extensible set of different formats for non-textual message 46 bodies, 48 (3) multi-part message bodies, and 50 (4) textual header information in character sets other than US-ASCII. 52 These documents are based on earlier work documented in RFC 934, STD 53 11, and RFC 1049, but extends and revises them. Because RFC 822 said 54 so little about message bodies, these documents are largely 55 orthogonal to (rather than a revision of) RFC 822. 57 This particular document is the third document in the series. It 58 describes extensions to RFC 822 to allow non-US-ASCII text data in 59 Internet mail header fields. 61 Other documents in this series include: 63 + RFC MIME-IMB, which specifies the various headers used to describe 64 the structure of MIME messages. 66 + RFC MIME-IMT, which defines the general structure of the MIME media 67 typing system and defines an initial set of media types, 69 + RFC MIME-REG, which specifies various IANA registration procedures 70 for MIME-related facilities, and 72 + RFC MIME-CONF, which describes MIME conformance criteria and 73 provides some illustrative examples of MIME message formats, 74 acknowledgements, and the bibliography. 76 These documents are revisions of RFCs 1521, 1522, and 1590, which 77 themselves were revisions of RFCs 1341 and 1342. An appendix in RFC 78 MIME-CONF describes differences and changes from previous versions. 80 1. Introduction 82 RFC MIME-IMB describes a mechanism for denoting textual body parts 83 which are coded in various character sets, as well as methods for 84 encoding such body parts as sequences of printable US-ASCII 85 characters. This memo describes similar techniques to allow the 86 encoding of non-ASCII text in various portions of a RFC 822 [2] 87 message header, in a manner which is unlikely to confuse existing 88 message handling software. 90 Like the encoding techniques described in RFC MIME-IMB, the 91 techniques outlined here were designed to allow the use of non-ASCII 92 characters in message headers in a way which is unlikely to be 93 disturbed by the quirks of existing Internet mail handling programs. 94 In particular, some mail relaying programs are known to (a) delete 95 some message header fields while retaining others, (b) rearrange the 96 order of addresses in To or Cc fields, (c) rearrange the (vertical) 97 order of header fields, and/or (d) "wrap" message headers at 98 different places than those in the original message. In addition, 99 some mail reading programs are known to have difficulty correctly 100 parsing message headers which, while legal according to RFC 822, make 101 use of backslash-quoting to "hide" special characters such as "<", 102 ",", or ":", or which exploit other infrequently-used features of 103 that specification. 105 While it is unfortunate that these programs do not correctly 106 interpret RFC 822 headers, to "break" these programs would cause 107 severe operational problems for the Internet mail system. The 108 extensions described in this memo therefore do not rely on little- 109 used features of RFC 822. 111 Instead, certain sequences of "ordinary" printable ASCII characters 112 (known as "encoded-words") are reserved for use as encoded data. The 113 syntax of encoded-words is such that they are unlikely to 114 "accidentally" appear as normal text in message headers. 115 Furthermore, the characters used in encoded-words are restricted to 116 those which do not have special meanings in the context in which the 117 encoded-word appears. 119 Generally, an "encoded-word" is a sequence of printable ASCII 120 characters that begins with "=?", ends with "?=", and has two "?"s in 121 between. It specifies a character set and an encoding method, and 122 also includes the original text encoded as graphic ASCII characters, 123 according to the rules for that encoding method. 125 A mail composer that implements this specification will provide a 126 means of inputting non-ASCII text in header fields, but will 127 translate these fields (or appropriate portions of these fields) into 128 encoded-words before inserting them into the message header. 130 A mail reader that implements this specification will recognize 131 encoded-words when they appear in certain portions of the message 132 header. Instead of displaying the encoded-word "as is", it will 133 reverse the encoding and display the original text in the designated 134 character set. 136 NOTES 138 This memo relies heavily on notation and terms defined RFC 822 and 139 RFC MIME-IMB. In particular, the syntax for the ABNF used in this 140 memo is defined in RFC 822, as well as many of the terminal or 141 nonterminal symbols from RFC 822 are used in the grammar for the 142 header extensions defined here. Among the symbols defined in RFC 822 143 and referenced in this memo are: 'addr-spec', 'atom', 'CHAR', 144 'comment', 'CTLs', 'ctext', 'linear-white-space', 'phrase', 145 'quoted-pair', 'quoted-string', 'SPACE', and 'word'. Successful 146 implementation of this protocol extension requires careful attention 147 to the RFC 822 definitions of these terms. 149 When the term "ASCII" appears in this memo, it refers to the "7-Bit 150 American Standard Code for Information Interchange", ANSI X3.4-1986. 151 The MIME charset name for this character set is "US-ASCII". When not 152 specifically referring to the MIME charset name, this document uses 153 the term "ASCII", both for brevity and for consistency with RFC 822. 154 However, implementors are warned that the character set name must be 155 spelled "US-ASCII" in MIME message and body part headers. 157 This memo specifies a protocol for the representation of non-ASCII 158 text in message headers. It specifically DOES NOT define any 159 translation between "8-bit headers" and pure ASCII headers, nor is 160 any such translation assumed to be possible. 162 2. Syntax of encoded-words 164 An 'encoded-word' is defined by the following ABNF grammar. The 165 notation of RFC 822 is used, with the exception that white space 166 characters MUST NOT appear between components of an 'encoded-word'. 168 encoded-word = "=?" charset "?" encoding "?" encoded-text "?=" 170 charset = token ; see section 3 172 encoding = token ; see section 4 174 token = 1* 176 especials = "(" / ")" / "<" / ">" / "@" / "," / ";" / ":" / "\" / 177 <"> / "/" / "[" / "]" / "?" / "." / "=" 179 encoded-text = 1* 181 ; (but see "Use of encoded-words in message 182 ; headers", section 5) 184 Both 'encoding' and 'charset' names are case-independent. Thus the 185 charset name "ISO-8859-1" is equivalent to "iso-8859-1", and the 186 encoding named "Q" may be spelled either "Q" or "q". 188 An 'encoded-word' may not be more than 75 characters long, including 189 'charset', 'encoding', 'encoded-text', and delimiters. If it is 190 desirable to encode more text than will fit in an 'encoded-word' of 191 75 characters, multiple 'encoded-word's (separated by CRLF SPACE) may 192 be used. 194 While there is no limit to the length of a multiple-line header 195 field, each line of a header field that contains one or more 196 'encoded-word's is limited to 76 characters. 198 The length restrictions are included both to ease interoperability 199 through internetwork mail gateways, and to impose a limit on the 200 amount of lookahead a header parser must employ (while looking for a 201 final ?= delimiter) before it can decide whether a token is an 202 'encoded-word' or something else. 204 IMPORTANT: 'encoded-word's are designed to be recognized as 'atom's 205 by an RFC 822 parser. As a consequence, unencoded white space 206 characters (such as SPACE and HTAB) are FORBIDDEN within an 207 'encoded-word'. For example, the character sequence 209 =?iso-8859-1?q?this is some text?= 211 would be parsed as four 'atom's, rather than as a single 'atom' (by 212 an RFC 822 parser) or 'encoded-word' (by a parser which understands 213 'encoded-words'). The correct way to encode the string "this is some 214 text" is to encode the SPACE characters as well, e.g. 216 =?iso-8859-1?q?this=20is=20some=20text?= 218 The characters which may appear in 'encoded-text' are further 219 restricted by the rules in section 5. 221 3. Character sets 223 The 'charset' portion of an 'encoded-word' specifies the character 224 set associated with the unencoded text. A 'charset' can be any of 225 the character set names allowed in an MIME "charset" parameter of a 226 "text/plain" body part, or any character set name registered with 227 IANA for use with the MIME text/plain content-type. (See [RFC 228 CHARSET] for information about the MIME charset registry.) 230 Some character sets use code-switching techniques to switch between 231 "ASCII mode" and other modes. If unencoded text in an 'encoded-word' 232 contains a sequence which causes the charset interpreter to switch 233 out of ASCII mode, it MUST contain additional control codes such that 234 ASCII mode is again selected at the end of the 'encoded-word'. (This 235 rule applies separately to each 'encoded-word', including adjacent 236 'encoded-word's within a single header field.) 238 When there is a possibility of using more than one character set to 239 represent the text in an 'encoded-word', and in the absence of 240 private agreements between sender and recipients of a message, it is 241 recommended that members of the ISO-8859-* series be used in 242 preference to other character sets. 244 4. Encodings 246 Initially, the legal values for "encoding" are "Q" and "B". These 247 encodings are described below. The "Q" encoding is recommended for 248 use when most of the characters to be encoded are in the ASCII 249 character set; otherwise, the "B" encoding should be used. 250 Nevertheless, a mail reader which claims to recognize 'encoded-word's 251 MUST be able to accept either encoding for any character set which it 252 supports. 254 Only a subset of the printable ASCII characters may be used in 255 'encoded-text'. Space and tab characters are not allowed, so that 256 the beginning and end of an 'encoded-word' are obvious. The "?" 257 character is used within an 'encoded-word' to separate the various 258 portions of the 'encoded-word' from one another, and thus cannot 259 appear in the 'encoded-text' portion. Other characters are also 260 illegal in certain contexts. For example, an 'encoded-word' in a 261 'phrase' preceding an address in a From header field may not contain 262 any of the "specials" defined in RFC 822. Finally, certain other 263 characters are disallowed in some contexts, to ensure reliability for 264 messages that pass through internetwork mail gateways. 266 The "B" encoding automatically meets these requirements. The "Q" 267 encoding allows a wide range of printable characters to be used in 268 non-critical locations in the message header (e.g., Subject), with 269 fewer characters available for use in other locations. 271 4.1. The "B" encoding 273 The "B" encoding is identical to the "BASE64" encoding defined by RFC 274 MIME-IMB. 276 4.2. The "Q" encoding 278 The "Q" encoding is similar to the "Quoted-Printable" content- 279 transfer-encoding defined in RFC MIME-IMB. It is designed to allow 280 text containing mostly ASCII characters to be decipherable on an 281 ASCII terminal without decoding. 283 (1) Any 8-bit value may be represented by a "=" followed by two 284 hexadecimal digits. For example, if the character set in use 285 were ISO-8859-1, the "=" character would thus be encoded as 286 "=3D", and a SPACE by "=20". (Upper case should be used for 287 hexadecimal digits "A" through "F".) 289 (2) The 8-bit hexadecimal value 20 (e.g., ISO-8859-1 SPACE) may be 290 represented as "_" (underscore, ASCII 95.). (This character may 291 not pass through some internetwork mail gateways, but its use 292 will greatly enhance readability of "Q" encoded data with mail 293 readers that do not support this encoding.) Note that the "_" 294 always represents hexadecimal 20, even if the SPACE character 295 occupies a different code position in the character set in use. 297 (3) 8-bit values which correspond to printable ASCII characters other 298 than "=", "?", and "_" (underscore), MAY be represented as those 299 characters. (But see section 5 for restrictions.) In 300 particular, SPACE and TAB MUST NOT be represented as themselves 301 within encoded words. 303 5. Use of encoded-words in message headers 305 An 'encoded-word' may appear in a message header or body part header 306 according to the following rules: 308 (1) An 'encoded-word' may replace a 'text' token (as defined by RFC 822) 309 in any Subject or Comments header field, any extension message 310 header field, or any MIME body part field for which the field body 311 is defined as '*text'. An 'encoded-word' may also appear in any 312 user-defined ("X-") message or body part header field. 314 Ordinary ASCII text and 'encoded-word's may appear together in the 315 same header field. However, an 'encoded-word' that appears in a 316 header field defined as '*text' MUST be separated from any adjacent 317 'encoded-word' or 'text' by 'linear-white-space'. 319 (2) An 'encoded-word' may appear within a 'comment' delimited by "(" and 320 ")", i.e., wherever a 'ctext' is allowed. More precisely, the RFC 321 822 ABNF definition for 'comment' is amended as follows: 323 comment = "(" *(ctext / quoted-pair / comment / encoded-word) ")" 325 A "Q"-encoded 'encoded-word' which appears in a 'comment' MUST NOT 326 contain the characters "(", ")" or "\". In addition, an 327 'encoded-word' that appears in a 'comment' MUST be separated from 328 any adjacent 'encoded-word' or 'ctext' by 'linear-white-space'. 330 It is important to note that 'comment's are only recognized inside 331 "structured" field bodies. In fields whose bodies are defined as 332 '*text', "(" and ")" are treated as ordinary characters rather than 333 comment delimiters, and rule (1) of this section applies. (See RFC 334 822, sections 3.1.2 and 3.1.3) 336 NOTE IN DRAFT: It has been suggested that these rules be relaxed, 337 and that any RFC 822 'special' character be allowed to appear 338 adjacent to 'encoded-word's in either unstructured and structured 339 field bodies. This would create a slight incompatibility with RFC 340 1522, but it may be that mail readers that understand RFC 1522 do 341 not treat structured fields differently from unstructured fields 342 anyway. 344 (3) As a replacement for a 'word' entity within a 'phrase', for example, 345 one that precedes an address in a From, To, or Cc header. The ABNF 346 definition for 'phrase' from RFC 822 thus becomes: 348 phrase = 1*( encoded-word / word ) 350 In this case the set of characters that may be used in a "Q"-encoded 351 'encoded-word' is restricted to: . An 'encoded-word' that appears within a 354 'phrase' MUST be separated from any adjacent 'word', 'text' or 355 'special' by 'linear-white-space'. 357 These are the ONLY locations where an 'encoded-word' may appear. In 358 particular: 360 + An 'encoded-word' MUST NOT appear in any portion of an 'addr-spec'. 362 + An 'encoded-word' MUST NOT appear within a 'quoted-string'. 364 + An 'encoded-word' MUST NOT be used in a Received header field. 366 + An 'encoded-word' MUST NOT be used in parameter of a MIME Content-Type 367 or Content-Disposition field, or in any structured field body except 368 within a 'comment' or 'phrase'. (NOTE IN DRAFT: A means of encoding 369 non-ASCII strings in MIME parameters has been proposed, and an 370 internet-draft describing it is expected shortly.) 372 The 'encoded-text' in an 'encoded-word' must be self-contained; 373 'encoded-text' MUST NOT be continued from one 'encoded-word' to another. 374 This implies that the 'encoded-text' portion of a "B" 'encoded-word' 375 will be a multiple of 4 characters long; for a "Q" 'encoded-word', any 376 "=" character that appears in the 'encoded-text' portion will be 377 followed by two hexadecimal characters. 379 Each 'encoded-word' MUST encode an integral number of octets. The 380 'encoded-text' in each 'encoded-word' must be well-formed according to 381 the encoding specified; the 'encoded-text' may not be continued in the 382 next 'encoded-word'. (For example, "=?charset?Q?=?= =?charset?Q?AB?=" 383 would be illegal, because the two hex digits "AB" must follow the "=" in 384 the same 'encoded-word'.) 386 Each 'encoded-word' MUST represent an integral number of characters. A 387 multi-octet character may not be split across adjacent 'encoded-word's. 389 Only printable and white space character data should be encoded using 390 this scheme. However, since these encoding schemes allow the encoding 391 of arbitrary octet values, mail readers that implement this decoding 392 should also ensure that display of the decoded data on the recipient's 393 terminal will not cause unwanted side-effects. 395 Use of these methods to encode non-textual data (e.g., pictures or 396 sounds) is not defined by this memo. Use of 'encoded-word's to 397 represent strings of purely ASCII characters is allowed, but 398 discouraged. In rare cases it may be necessary to encode ordinary text 399 that looks like an 'encoded-word'. 401 6. Support of 'encoded-word's by mail readers 403 6.1. Recognition of 'encoded-word's in message headers 405 A mail reader must parse the message and body part headers according 406 to the rules in RFC 822 to correctly recognize 'encoded-word's. 408 'encoded-word's are to be recognized as follows: 410 (1) Any message or body part header field defined as '*text', or any 411 user-defined header field, should be parsed as follows: Beginning 412 at the start of the field-body and immediately following each 413 occurrence of 'linear-white-space', each sequence of up to 75 414 printable characters (not containing any 'linear-white-space') 415 should be examined to see if it is an 'encoded-word' according to 416 the syntax rules in section 2. Any other sequence of printable 417 characters should be treated as ordinary ASCII text. 419 (2) Any header field not defined as '*text' should be parsed 420 according to the syntax rules for that header field. However, 421 any 'word' that appears within a 'phrase' should be treated as an 422 'encoded-word' if it meets the syntax rules in section 2. 423 Otherwise it should be treated as an ordinary 'word'. 425 (3) Within a 'comment', any sequence of up to 75 printable characters 426 (not containing 'linear-white-space'), that meets the syntax 427 rules in section 2, should be treated as an 'encoded-word'. 428 Otherwise it should be treated as normal comment text. 430 (4) A MIME-Version header field is NOT required to be present for 431 'encoded-word's to be interpreted according to this 432 specification. One reason for this is that the mail reader is 433 not expected to parse the entire message header before displaying 434 lines that may contain 'encoded-word's. 436 6.2. Display of 'encoded-word's 438 Any 'encoded-word's so recognized are decoded, and if possible, the 439 resulting unencoded text is displayed in the original character set. 441 NOTE: Decoding and display of encoded-words occurs *after* a 442 structured field body is parsed into tokens. It is therefore 443 possible to hide 'special' characters in encoded-words which, when 444 displayed, will be indistinguishable from 'special' characters in the 445 surrounding text. For this and other reasons, it is NOT generally 446 possible to translate a message header containing 'encoded-word's to 447 an unencoded form which can be parsed by an RFC 822 mail reader. 449 When displaying a particular header field that contains multiple 450 'encoded-word's, any 'linear-white-space' that separates a pair of 451 adjacent 'encoded-word's is ignored. (This is to allow the use of 452 multiple 'encoded-word's to represent long strings of unencoded text, 453 without having to separate 'encoded-word's where spaces occur in the 454 unencoded text.) 456 In the event other encodings are defined in the future, and the mail 457 reader does not support the encoding used, it may either (a) display 458 the 'encoded-word' as ordinary text, or (b) substitute an appropriate 459 message indicating that the text could not be decoded. 461 If the mail reader does not support the character set used, it may 462 (a) display the 'encoded-word' as ordinary text (i.e., as it appears 463 in the header), (b) make a "best effort" to display using such 464 characters as are available, or (c) substitute an appropriate message 465 indicating that the decoded text could not be displayed. 467 If the character set being used employs code-switching techniques, 468 display of the encoded text implicitly begins in "ASCII mode". In 469 addition, the mail reader must ensure that the output device is once 470 again in "ASCII mode" after the 'encoded-word' is displayed. 472 6.3. Mail reader handling of incorrectly formed 'encoded-word's 474 It is possible that an 'encoded-word' that is legal according to the 475 syntax defined in section 2, is incorrectly formed according to the 476 rules for the encoding being used. For example: 478 (1) An 'encoded-word' which contains characters which are not legal 479 for a particular encoding (for example, a "-" in the "B" 480 encoding, or a SPACE or HTAB in either the "B" or "Q" encoding), 481 is incorrectly formed. 483 (2) Any 'encoded-word' which encodes a non-integral number of 484 characters or octets is incorrectly formed. 486 A mail reader need not attempt to display the text associated with an 487 'encoded-word' that is incorrectly formed. However, a mail reader 488 MUST NOT prevent the display or handling of a message because an 489 'encoded-word' is incorrectly formed. 491 7. Conformance 493 A mail composing program claiming compliance with this specification 494 MUST ensure that any string of non-white-space printable ASCII 495 characters within a '*text' or '*ctext' that begins with "=?" and ends 496 with "?=" be a valid 'encoded-word'. ("begins" means: at the start of 497 the field-body, immediately following 'linear-white-space', or 498 immediately following a "(" for an 'encoded-word' within '*ctext'; 499 "ends" means: at the end of the field-body, immediately preceding 500 'linear-white-space', or immediately preceding a ")" for an 501 'encoded-word' within '*ctext'.) In addition, any 'word' within a 502 'phrase' that begins with "=?" and ends with "?=" must be a valid 503 'encoded-word'. 505 A mail reading program claiming compliance with this specification must 506 be able to distinguish 'encoded-word's from 'text', 'ctext', or 'word's, 507 according to the rules in section 6, anytime they appear in appropriate 508 places in message headers. It must support both the "B" and "Q" 509 encodings for any character set which it supports. The program must be 510 able to display the unencoded text if the character set is "US-ASCII". 511 For the ISO-8859-* character sets, the mail reading program must at 512 least be able to display the characters which are also in the ASCII set. 514 8. Examples 516 The following are examples of message headers containing 517 'encoded-word's: 519 From: =?US-ASCII?Q?Keith_Moore?= 520 To: =?ISO-8859-1?Q?Keld_J=F8rn_Simonsen?= 521 CC: =?ISO-8859-1?Q?Andr=E9?= Pirard 522 Subject: =?ISO-8859-1?B?SWYgeW91IGNhbiByZWFkIHRoaXMgeW8=?= 523 =?ISO-8859-2?B?dSB1bmRlcnN0YW5kIHRoZSBleGFtcGxlLg==?= 525 Note: In the first 'encoded-word' of the Subject field above, the 526 last "=" at the end of the 'encoded-text' is necessary because each 527 'encoded-word' must be self-contained (the "=" character completes a 528 group of 4 base64 characters representing 2 octets). An additional 529 octet could have been encoded in the first 'encoded-word' (so that 530 the encoded-word would contain an exact multiple of 3 encoded 531 octets), except that the second 'encoded-word' uses a different 532 'charset' than the first one. 534 From: =?ISO-8859-1?Q?Olle_J=E4rnefors?= 535 To: ietf-822@dimacs.rutgers.edu, ojarnef@admin.kth.se 536 Subject: Time for ISO 10646? 538 To: Dave Crocker 539 Cc: ietf-822@dimacs.rutgers.edu, paf@comsol.se 540 From: =?ISO-8859-1?Q?Patrik_F=E4ltstr=F6m?= 541 Subject: Re: RFC-HDR care and feeding 543 From: Nathaniel Borenstein 544 (=?iso-8859-8?b?7eXs+SDv4SDp7Oj08A==?=) 545 To: Greg Vaudreuil , Ned Freed 546 , Keith Moore 547 Subject: Test of new header generator 548 MIME-Version: 1.0 549 Content-type: text/plain; charset=ISO-8859-1 550 The following examples illustrate how text containing 'encoded-word's 551 which appear in a structured field body. The rules are slightly 552 different for fields defined as '*text' because "(" and ")" are not 553 recognized as 'comment' delimiters. [Section 5, paragraph (1)]. 555 In each of the following examples, if the same sequence were to occur in 556 a '*text' field, the "displayed as" form would NOT be treated as encoded 557 words, but be identical to the "encoded form". This is because each of 558 the encoded-words in the following examples is adjacent to a "(" or ")" 559 character. 561 encoded form displayed as 562 --------------------------------------------------------------------- 563 (=?ISO-8859-1?Q?a?=) (a) 565 (=?ISO-8859-1?Q?a?= b) (a b) 567 Within a 'comment', white space MUST appear between an 568 'encoded-word' and surrounding text. [Section 5, 569 paragraph (2)]. However, white space is not needed between 570 the initial "(" that begins the 'comment', and the 571 'encoded-word'. 573 (=?ISO-8859-1?Q?a?= =?ISO-8859-1?Q?b?=) (ab) 575 White space between adjacent 'encoded-word's is not 576 displayed. 578 (=?ISO-8859-1?Q?a?= =?ISO-8859-1?Q?b?=) (ab) 580 Even multiple SPACEs between 'encoded-word's are ignored 581 for the purpose of display. 583 (=?ISO-8859-1?Q?a?= (ab) 584 =?ISO-8859-1?Q?b?=) 586 Any amount of linear-space-white between 'encoded-word's, even 587 if it includes a CRLF followed by one or more SPACEs, is 588 ignored for the purposes of display. 590 (=?ISO-8859-1?Q?a_b?=) (a b) 592 In order to cause a SPACE to be displayed within a portion 593 of encoded text, the SPACE MUST be encoded as part of the 594 'encoded-word'. 596 (=?ISO-8859-1?Q?a?= =?ISO-8859-2?Q?_b?=) (a b) 598 In order to cause a SPACE to be displayed between two strings 599 of encoded text, the SPACE MAY be encoded as part of one of the 600 'encoded-word's. 602 9. References 604 [RFC 822] Crocker, D., "Standard for the Format of ARPA Internet Text 605 Messages", RFC 822, UDEL, August 1982. 606 [RFC CHARSET] N. Freed and J. Postel, "IANA Character Set Registration 607 Procedures", Internet-Draft draft-freed-charset-reg-00.txt, 29 April 608 1996. 609 [RFC MIME-CONF] N. Borenstein and N. Freed, "Multipurpose Internet Mail 610 Extensions (MIME) Part Five: Conformance Criteria and Examples". 611 Internet-Draft draft-ietf-822ext-mime-conf-05.txt, 13 March 1996. 612 [RFC MIME-IMB] N. Borenstein and N. Freed, "Multipurpose Internet Mail 613 Extensions (MIME) Part One: Format of Internet Message Bodies". 614 Internet-Draft draft-ietf-822ext-mime-imb-06.txt, 13 March 1996. 615 [RFC MIME-IMT] N. Borenstein and N. Freed, "Multipurpose Internet Mail 616 Extensions (MIME) Part Two: Media Types". Internet-Draft draft- 617 ietf-822ext-mime-imt-04.txt, 13 March 1996. 618 [RFC MIME-REG] N. Freed, J. Klensin, and J. Postel. "Multipurpose 619 Internet Mail Extensions (MIME) Part Four: Registration Procedures", 620 Internet-Draft draft-ietf-822ext-mime-reg-03.txt, 14 March 1996. 622 10. Security Considerations 624 Security issues are not discussed in this memo. 626 11. Acknowledgements 628 The author wishes to thank Nathaniel Borenstein, Issac Chan, Lutz 629 Donnerhacke, Paul Eggert, Ned Freed, Andreas M. Kirchwitz, Olle 630 Jarnefors, Mike Rosin, Yutaka Sato, Bart Schaefer, and Kazuhiko 631 Yamamoto, for their helpful advice, insightful comments, and 632 illuminating questions in response to earlier versions of this 633 specification. 635 12. Author's Address 637 Keith Moore 638 University of Tennessee 639 107 Ayres Hall 640 Knoxville TN 37996-1301 642 EMail: moore@cs.utk.edu 643 Appendix - changes since RFC 1522 (in no particular order) 645 + explicitly state that the MIME-Version is not requried to use 646 'encoded-word's. 648 + add explicit note that SPACEs and TABs are not allowed within 649 'encoded-word's, explaining that an 'encoded-word' must look like an 650 'atom' to an RFC822 parser.values, to be precise). 652 + add examples from Olle Jarnefors (thanks!) which illustrate how 653 encoded-words with adjacent linear-white-space are displayed. 655 + explicitly list terms defined in RFC822 and referenced in this memo 657 + fix transcription typos that caused one or two lines and a couple of 658 characters to disappear in the resulting text, due to nroff quirks. 660 + clarify that encoded-words are allowed in '*text' fields in both 661 RFC822 headers and MIME body part headers, but NOT as parameter 662 values. 664 + clarify the requirement to switch back to ASCII within the encoded 665 portion of an 'encoded-word', for any charset that uses code switching 666 sequences. 668 + add a note about 'encoded-word's being delimited by "(" and ")" 669 within a comment, but not in a *text (how bizarre!). 671 + fix the Andre Pirard example to get rid of the trailing "_" after 672 the =E9. (no longer needed post-1342). 674 + clarification: an 'encoded-word' may appear immediately following 675 the initial "(" or immediately before the final ")" that delimits a 676 comment, not just adjacent to "(" and ")" *within* *ctext. 678 + add a note to explain that a "B" 'encoded-word' will always have a 679 multiple of 4 characters in the 'encoded-text' portion. 681 + add note about the "=" in the examples 683 + note that processing of 'encoded-word's occurs *after* parsing, and 684 some of the implications thereof. 686 + explicitly state that you can't expect to translate between 687 1522 and either vanilla 822 or so-called "8-bit headers". 689 + explicitly state that 'encoded-word's are not valid within a 690 'quoted-string'.