rohrpost

A commandline mail client to change the world as we see it.
git clone git://r-36.net/rohrpost
Log | Files | Refs | README | LICENSE

rfc2049.txt (51207B)


      1 
      2 
      3 
      4 
      5 
      6 
      7 Network Working Group                                          N. Freed
      8 Request for Comments: 2049                                     Innosoft
      9 Obsoletes: 1521, 1522, 1590                               N. Borenstein
     10 Category: Standards Track                                 First Virtual
     11                                                           November 1996
     12 
     13 
     14                  Multipurpose Internet Mail Extensions
     15                            (MIME) Part Five:
     16                    Conformance Criteria and Examples
     17 
     18 Status of this Memo
     19 
     20    This document specifies an Internet standards track protocol for the
     21    Internet community, and requests discussion and suggestions for
     22    improvements.  Please refer to the current edition of the "Internet
     23    Official Protocol Standards" (STD 1) for the standardization state
     24    and status of this protocol.  Distribution of this memo is unlimited.
     25 
     26 Abstract
     27 
     28    STD 11, RFC 822, defines a message representation protocol specifying
     29    considerable detail about US-ASCII message headers, and leaves the
     30    message content, or message body, as flat US-ASCII text.  This set of
     31    documents, collectively called the Multipurpose Internet Mail
     32    Extensions, or MIME, redefines the format of messages to allow for
     33 
     34     (1)   textual message bodies in character sets other than
     35           US-ASCII,
     36 
     37     (2)   an extensible set of different formats for non-textual
     38           message bodies,
     39 
     40     (3)   multi-part message bodies, and
     41 
     42     (4)   textual header information in character sets other than
     43           US-ASCII.
     44 
     45    These documents are based on earlier work documented in RFC 934, STD
     46    11, and RFC 1049, but extends and revises them.  Because RFC 822 said
     47    so little about message bodies, these documents are largely
     48    orthogonal to (rather than a revision of) RFC 822.
     49 
     50    The initial document in this set, RFC 2045, specifies the various
     51    headers used to describe the structure of MIME messages. The second
     52    document defines the general structure of the MIME media typing
     53    system and defines an initial set of media types.  The third
     54    document, RFC 2047, describes extensions to RFC 822 to allow non-US-
     55 
     56 
     57 
     58 Freed & Borenstein          Standards Track                     [Page 1]
     59 
     60 RFC 2049                    MIME Conformance               November 1996
     61 
     62 
     63    ASCII text data in Internet mail header fields. The fourth document,
     64    RFC 2048, specifies various IANA registration procedures for MIME-
     65    related facilities. This fifth and final document describes MIME
     66    conformance criteria as well as providing some illustrative examples
     67    of MIME message formats, acknowledgements, and the bibliography.
     68 
     69    These documents are revisions of RFCs 1521, 1522, and 1590, which
     70    themselves were revisions of RFCs 1341 and 1342.  Appendix B of this
     71    document describes differences and changes from previous versions.
     72 
     73 Table of Contents
     74 
     75    1. Introduction ..........................................    2
     76    2. MIME Conformance ......................................    2
     77    3. Guidelines for Sending Email Data .....................    6
     78    4. Canonical Encoding Model ..............................    9
     79    5. Summary ...............................................   12
     80    6. Security Considerations ...............................   12
     81    7. Authors' Addresses ....................................   12
     82    8. Acknowledgements ......................................   13
     83    A. A Complex Multipart Example ...........................   15
     84    B. Changes from RFC 1521, 1522, and 1590 .................   16
     85    C. References ............................................   20
     86 
     87 1.  Introduction
     88 
     89    The first and second documents in this set define MIME header fields
     90    and the initial set of MIME media types.  The third document
     91    describes extensions to RFC822 formats to allow for character sets
     92    other than US-ASCII.  This document describes what portions  of MIME
     93    must be supported by a conformant MIME implementation. It also
     94    describes various pitfalls of contemporary messaging systems as well
     95    as the canonical encoding model MIME is based on.
     96 
     97 2.  MIME Conformance
     98 
     99    The mechanisms described in these documents are open-ended.  It is
    100    definitely not expected that all implementations will support all
    101    available media types, nor that they will all share the same
    102    extensions.  In order to promote interoperability, however, it is
    103    useful to define the concept of "MIME-conformance" to define a
    104    certain level of implementation that allows the useful interworking
    105    of messages with content that differs from US-ASCII text.  In this
    106    section, we specify the requirements for such conformance.
    107 
    108 
    109 
    110 
    111 
    112 
    113 
    114 Freed & Borenstein          Standards Track                     [Page 2]
    115 
    116 RFC 2049                    MIME Conformance               November 1996
    117 
    118 
    119    A mail user agent that is MIME-conformant MUST:
    120 
    121     (1)   Always generate a "MIME-Version: 1.0" header field in
    122           any message it creates.
    123 
    124     (2)   Recognize the Content-Transfer-Encoding header field
    125           and decode all received data encoded by either quoted-
    126           printable or base64 implementations.  The identity
    127           transformations 7bit, 8bit, and binary must also be
    128           recognized.
    129 
    130           Any non-7bit data that is sent without encoding must be
    131           properly labelled with a content-transfer-encoding of
    132           8bit or binary, as appropriate.  If the underlying
    133           transport does not support 8bit or binary (as SMTP
    134           [RFC-821] does not), the sender is required to both
    135           encode and label data using an appropriate Content-
    136           Transfer-Encoding such as quoted-printable or base64.
    137 
    138     (3)   Must treat any unrecognized Content-Transfer-Encoding
    139           as if it had a Content-Type of "application/octet-
    140           stream", regardless of whether or not the actual
    141           Content-Type is recognized.
    142 
    143     (4)   Recognize and interpret the Content-Type header field,
    144           and avoid showing users raw data with a Content-Type
    145           field other than text.  Implementations  must be able
    146           to send at least text/plain messages, with the
    147           character set specified with the charset parameter if
    148           it is not US-ASCII.
    149 
    150     (5)   Ignore any content type parameters whose names they do
    151           not recognize.
    152 
    153     (6)   Explicitly handle the following media type values, to
    154           at least the following extents:
    155 
    156           Text:
    157 
    158             -- Recognize and display "text" mail with the
    159             character set "US-ASCII."
    160 
    161             -- Recognize other character sets at least to the
    162             extent of being able to inform the user about what
    163             character set the message uses.
    164 
    165 
    166 
    167 
    168 
    169 
    170 Freed & Borenstein          Standards Track                     [Page 3]
    171 
    172 RFC 2049                    MIME Conformance               November 1996
    173 
    174 
    175             -- Recognize the "ISO-8859-*" character sets to the
    176             extent of being able to display those characters that
    177             are common to ISO-8859-* and US-ASCII, namely all
    178             characters represented by octet values 1-127.
    179 
    180             -- For unrecognized subtypes in a known character
    181             set, show or offer to show the user the "raw" version
    182             of the data after conversion of the content from
    183             canonical form to local form.
    184 
    185             -- Treat material in an unknown character set as if
    186             it were "application/octet-stream".
    187 
    188           Image, audio, and video:
    189 
    190             -- At a minumum provide facilities to treat any
    191             unrecognized subtypes as if they were
    192             "application/octet-stream".
    193 
    194           Application:
    195 
    196             -- Offer the ability to remove either of the quoted-
    197             printable or base64 encodings defined in this
    198             document if they were used and put the resulting
    199             information in a user file.
    200 
    201           Multipart:
    202 
    203             -- Recognize the mixed subtype.  Display all relevant
    204             information on the message level and the body part
    205             header level and then display or offer to display
    206             each of the body parts individually.
    207 
    208             -- Recognize the "alternative" subtype, and avoid
    209             showing the user redundant parts of
    210             multipart/alternative mail.
    211 
    212             -- Recognize the "multipart/digest" subtype,
    213             specifically using "message/rfc822" rather than
    214             "text/plain" as the default media type for body parts
    215             inside "multipart/digest" entities.
    216 
    217             -- Treat any unrecognized subtypes as if they were
    218             "mixed".
    219 
    220 
    221 
    222 
    223 
    224 
    225 
    226 Freed & Borenstein          Standards Track                     [Page 4]
    227 
    228 RFC 2049                    MIME Conformance               November 1996
    229 
    230 
    231           Message:
    232 
    233             -- Recognize and display at least the RFC822 message
    234             encapsulation (message/rfc822) in such a way as to
    235             preserve any recursive structure, that is, displaying
    236             or offering to display the encapsulated data in
    237             accordance with its media type.
    238 
    239             -- Treat any unrecognized subtypes as if they were
    240             "application/octet-stream".
    241 
    242     (7)   Upon encountering any unrecognized Content-Type field,
    243           an implementation must treat it as if it had a media
    244           type of "application/octet-stream" with no parameter
    245           sub-arguments.  How such data are handled is up to an
    246           implementation, but likely options for handling such
    247           unrecognized data include offering the user to write it
    248           into a file (decoded from its mail transport format) or
    249           offering the user to name a program to which the
    250           decoded data should be passed as input.
    251 
    252     (8)   Conformant user agents are required, if they provide
    253           non-standard support for non-MIME messages employing
    254           character sets other than US-ASCII, to do so on
    255           received messages only. Conforming user agents must not
    256           send non-MIME messages containing anything other than
    257           US-ASCII text.
    258 
    259           In particular, the use of non-US-ASCII text in mail
    260           messages without a MIME-Version field is strongly
    261           discouraged as it impedes interoperability when sending
    262           messages between regions with different localization
    263           conventions. Conforming user agents MUST include proper
    264           MIME labelling when sending anything other than plain
    265           text in the US-ASCII character set.
    266 
    267           In addition, non-MIME user agents should be upgraded if
    268           at all possible to include appropriate MIME header
    269           information in the messages they send even if nothing
    270           else in MIME is supported.  This upgrade will have
    271           little, if any, effect on non-MIME recipients and will
    272           aid MIME in correctly displaying such messages.  It
    273           also provides a smooth transition path to eventual
    274           adoption of other MIME capabilities.
    275 
    276     (9)   Conforming user agents must ensure that any string of
    277           non-white-space printable US-ASCII characters within a
    278           "*text" or "*ctext" that begins with "=?" and ends with
    279 
    280 
    281 
    282 Freed & Borenstein          Standards Track                     [Page 5]
    283 
    284 RFC 2049                    MIME Conformance               November 1996
    285 
    286 
    287           "?=" be a valid encoded-word.  ("begins" means: At the
    288           start of the field-body or immediately following
    289           linear-white-space; "ends" means: At the end of the
    290           field-body or immediately preceding linear-white-
    291           space.) In addition, any "word" within a "phrase" that
    292           begins with "=?" and ends with "?=" must be a valid
    293           encoded-word.
    294 
    295     (10)  Conforming user agents must be able to distinguish
    296           encoded-words from "text", "ctext", or "word"s,
    297           according to the rules in section 4, anytime they
    298           appear in appropriate places in message headers.  It
    299           must support both the "B" and "Q" encodings for any
    300           character set which it supports.  The program must be
    301           able to display the unencoded text if the character set
    302           is "US-ASCII".  For the ISO-8859-* character sets, the
    303           mail reading program must at least be able to display
    304           the characters which are also in the US-ASCII set.
    305 
    306    A user agent that meets the above conditions is said to be MIME-
    307    conformant.  The meaning of this phrase is that it is assumed to be
    308    "safe" to send virtually any kind of properly-marked data to users of
    309    such mail systems, because such systems will at least be able to
    310    treat the data as undifferentiated binary, and will not simply splash
    311    it onto the screen of unsuspecting users.
    312 
    313    There is another sense in which it is always "safe" to send data in a
    314    format that is MIME-conformant, which is that such data will not
    315    break or be broken by any known systems that are conformant with RFC
    316    821 and RFC 822.  User agents that are MIME-conformant have the
    317    additional guarantee that the user will not be shown data that were
    318    never intended to be viewed as text.
    319 
    320 3.  Guidelines for Sending Email Data
    321 
    322    Internet email is not a perfect, homogeneous system.  Mail may become
    323    corrupted at several stages in its travel to a final destination.
    324    Specifically, email sent throughout the Internet may travel across
    325    many networking technologies. Many networking and mail technologies
    326    do not support the full functionality possible in the SMTP transport
    327    environment.  Mail traversing these systems is likely to be modified
    328    in order that it can be transported.
    329 
    330    There exist many widely-deployed non-conformant MTAs in the Internet.
    331    These MTAs, speaking the SMTP protocol, alter messages on the fly to
    332    take advantage of the internal data structure of the hosts they are
    333    implemented on, or are just plain broken.
    334 
    335 
    336 
    337 
    338 Freed & Borenstein          Standards Track                     [Page 6]
    339 
    340 RFC 2049                    MIME Conformance               November 1996
    341 
    342 
    343    The following guidelines may be useful to anyone devising a data
    344    format (media type) that is supposed to survive the widest range of
    345    networking technologies and known broken MTAs unscathed.  Note that
    346    anything encoded in the base64 encoding will satisfy these rules, but
    347    that some well-known mechanisms, notably the UNIX uuencode facility,
    348    will not.  Note also that anything encoded in the Quoted-Printable
    349    encoding will survive most gateways intact, but possibly not some
    350    gateways to systems that use the EBCDIC character set.
    351 
    352     (1)   Under some circumstances the encoding used for data may
    353           change as part of normal gateway or user agent
    354           operation.  In particular, conversion from base64 to
    355           quoted-printable and vice versa may be necessary.  This
    356           may result in the confusion of CRLF sequences with line
    357           breaks in text bodies.  As such, the persistence of
    358           CRLF as something other than a line break must not be
    359           relied on.
    360 
    361     (2)   Many systems may elect to represent and store text data
    362           using local newline conventions.  Local newline
    363           conventions may not match the RFC822 CRLF convention --
    364           systems are known that use plain CR, plain LF, CRLF, or
    365           counted records.  The result is that isolated CR and LF
    366           characters are not well tolerated in general; they may
    367           be lost or converted to delimiters on some systems, and
    368           hence must not be relied on.
    369 
    370     (3)   The transmission of NULs (US-ASCII value 0) is
    371           problematic in Internet mail.  (This is largely the
    372           result of NULs being used as a termination character by
    373           many of the standard runtime library routines in the C
    374           programming language.) The practice of using NULs as
    375           termination characters is so entrenched now that
    376           messages should not rely on them being preserved.
    377 
    378     (4)   TAB (HT) characters may be misinterpreted or may be
    379           automatically converted to variable numbers of spaces.
    380           This is unavoidable in some environments, notably those
    381           not based on the US-ASCII character set.  Such
    382           conversion is STRONGLY DISCOURAGED, but it may occur,
    383           and mail formats must not rely on the persistence of
    384           TAB (HT) characters.
    385 
    386     (5)   Lines longer than 76 characters may be wrapped or
    387           truncated in some environments.  Line wrapping or line
    388           truncation imposed by mail transports is STRONGLY
    389           DISCOURAGED, but unavoidable in some cases.
    390           Applications which require long lines must somehow
    391 
    392 
    393 
    394 Freed & Borenstein          Standards Track                     [Page 7]
    395 
    396 RFC 2049                    MIME Conformance               November 1996
    397 
    398 
    399           differentiate between soft and hard line breaks.  (A
    400           simple way to do this is to use the quoted-printable
    401           encoding.)
    402 
    403     (6)   Trailing "white space" characters (SPACE, TAB (HT)) on
    404           a line may be discarded by some transport agents, while
    405           other transport agents may pad lines with these
    406           characters so that all lines in a mail file are of
    407           equal length.  The persistence of trailing white space,
    408           therefore, must not be relied on.
    409 
    410     (7)   Many mail domains use variations on the US-ASCII
    411           character set, or use character sets such as EBCDIC
    412           which contain most but not all of the US-ASCII
    413           characters.  The correct translation of characters not
    414           in the "invariant" set cannot be depended on across
    415           character converting gateways.  For example, this
    416           situation is a problem when sending uuencoded
    417           information across BITNET, an EBCDIC system.  Similar
    418           problems can occur without crossing a gateway, since
    419           many Internet hosts use character sets other than US-
    420           ASCII internally.  The definition of Printable Strings
    421           in X.400 adds further restrictions in certain special
    422           cases.  In particular, the only characters that are
    423           known to be consistent across all gateways are the 73
    424           characters that correspond to the upper and lower case
    425           letters A-Z and a-z, the 10 digits 0-9, and the
    426           following eleven special characters:
    427 
    428             "'"  (US-ASCII decimal value 39)
    429             "("  (US-ASCII decimal value 40)
    430             ")"  (US-ASCII decimal value 41)
    431             "+"  (US-ASCII decimal value 43)
    432             ","  (US-ASCII decimal value 44)
    433             "-"  (US-ASCII decimal value 45)
    434             "."  (US-ASCII decimal value 46)
    435             "/"  (US-ASCII decimal value 47)
    436             ":"  (US-ASCII decimal value 58)
    437             "="  (US-ASCII decimal value 61)
    438             "?"  (US-ASCII decimal value 63)
    439 
    440           A maximally portable mail representation will confine
    441           itself to relatively short lines of text in which the
    442           only meaningful characters are taken from this set of
    443           73 characters.  The base64 encoding follows this rule.
    444 
    445     (8)   Some mail transport agents will corrupt data that
    446           includes certain literal strings.  In particular, a
    447 
    448 
    449 
    450 Freed & Borenstein          Standards Track                     [Page 8]
    451 
    452 RFC 2049                    MIME Conformance               November 1996
    453 
    454 
    455           period (".") alone on a line is known to be corrupted
    456           by some (incorrect) SMTP implementations, and a line
    457           that starts with the five characters "From " (the fifth
    458           character is a SPACE) are commonly corrupted as well.
    459           A careful composition agent can prevent these
    460           corruptions by encoding the data (e.g., in the quoted-
    461           printable encoding using "=46rom " in place of "From "
    462           at the start of a line, and "=2E" in place of "." alone
    463           on a line).
    464 
    465    Please note that the above list is NOT a list of recommended
    466    practices for MTAs.  RFC 821 MTAs are prohibited from altering the
    467    character of white space or wrapping long lines.  These BAD and
    468    invalid practices are known to occur on established networks, and
    469    implementations should be robust in dealing with the bad effects they
    470    can cause.
    471 
    472 4.  Canonical Encoding Model
    473 
    474    There was some confusion, in earlier versions of these documents,
    475    regarding the model for when email data was to be converted to
    476    canonical form and encoded, and in particular how this process would
    477    affect the treatment of CRLFs, given that the representation of
    478    newlines varies greatly from system to system.  For this reason, a
    479    canonical model for encoding is presented below.
    480 
    481    The process of composing a MIME entity can be modeled as being done
    482    in a number of steps.  Note that these steps are roughly similar to
    483    those steps used in PEM [RFC-1421] and are performed for each
    484    "innermost level" body:
    485 
    486     (1)   Creation of local form.
    487 
    488           The body to be transmitted is created in the system's
    489           native format.  The native character set is used and,
    490           where appropriate, local end of line conventions are
    491           used as well.  The body may be a UNIX-style text file,
    492           or a Sun raster image, or a VMS indexed file, or audio
    493           data in a system-dependent format stored only in
    494           memory, or anything else that corresponds to the local
    495           model for the representation of some form of
    496           information.  Fundamentally, the data is created in the
    497           "native" form that corresponds to the type specified by
    498           the media type.
    499 
    500 
    501 
    502 
    503 
    504 
    505 
    506 Freed & Borenstein          Standards Track                     [Page 9]
    507 
    508 RFC 2049                    MIME Conformance               November 1996
    509 
    510 
    511     (2)   Conversion to canonical form.
    512 
    513           The entire body, including "out-of-band" information
    514           such as record lengths and possibly file attribute
    515           information, is converted to a universal canonical
    516           form.  The specific media type of the body as well as
    517           its associated attributes dictate the nature of the
    518           canonical form that is used.  Conversion to the proper
    519           canonical form may involve character set conversion,
    520           transformation of audio data, compression, or various
    521           other operations specific to the various media types.
    522           If character set conversion is involved, however, care
    523           must be taken to understand the semantics of the media
    524           type, which may have strong implications for any
    525           character set conversion, e.g. with regard to
    526           syntactically meaningful characters in a text subtype
    527           other than "plain".
    528 
    529           For example, in the case of text/plain data, the text
    530           must be converted to a supported character set and
    531           lines must be delimited with CRLF delimiters in
    532           accordance with RFC 822.  Note that the restriction on
    533           line lengths implied by RFC 822 is eliminated if the
    534           next step employs either quoted-printable or base64
    535           encoding.
    536 
    537     (3)   Apply transfer encoding.
    538 
    539           A Content-Transfer-Encoding appropriate for this body
    540           is applied.  Note that there is no fixed relationship
    541           between the media type and the transfer encoding.  In
    542           particular, it may be appropriate to base the choice of
    543           base64 or quoted-printable on character frequency
    544           counts which are specific to a given instance of a
    545           body.
    546 
    547     (4)   Insertion into entity.
    548 
    549           The encoded body is inserted into a MIME entity with
    550           appropriate headers. The entity is then inserted into
    551           the body of a higher-level entity (message or
    552           multipart) as needed.
    553 
    554    Conversion from entity form to local form is accomplished by
    555    reversing these steps. Note that reversal of these steps may produce
    556    differing results since there is no guarantee that the original and
    557    final local forms are the same.
    558 
    559 
    560 
    561 
    562 Freed & Borenstein          Standards Track                    [Page 10]
    563 
    564 RFC 2049                    MIME Conformance               November 1996
    565 
    566 
    567    It is vital to note that these steps are only a model; they are
    568    specifically NOT a blueprint for how an actual system would be built.
    569    In particular, the model fails to account for two common designs:
    570 
    571     (1)   In many cases the conversion to a canonical form prior
    572           to encoding will be subsumed into the encoder itself,
    573           which understands local formats directly.  For example,
    574           the local newline convention for text bodies might be
    575           carried through to the encoder itself along with
    576           knowledge of what that format is.
    577 
    578     (2)   The output of the encoders may have to pass through one
    579           or more additional steps prior to being transmitted as
    580           a message.  As such, the output of the encoder may not
    581           be conformant with the formats specified by RFC 822.
    582           In particular, once again it may be appropriate for the
    583           converter's output to be expressed using local newline
    584           conventions rather than using the standard RFC 822 CRLF
    585           delimiters.
    586 
    587    Other implementation variations are conceivable as well.  The vital
    588    aspect of this discussion is that, in spite of any optimizations,
    589    collapsings of required steps, or insertion of additional processing,
    590    the resulting messages must be consistent with those produced by the
    591    model described here.  For example, a message with the following
    592    header fields:
    593 
    594      Content-type: text/foo; charset=bar
    595      Content-Transfer-Encoding: base64
    596 
    597    must be first represented in the text/foo form, then (if necessary)
    598    represented in the "bar" character set, and finally transformed via
    599    the base64 algorithm into a mail-safe form.
    600 
    601    NOTE: Some confusion has been caused by systems that represent
    602    messages in a format which uses local newline conventions which
    603    differ from the RFC822 CRLF convention.  It is important to note that
    604    these formats are not canonical RFC822/MIME.  These formats are
    605    instead *encodings* of RFC822, where CRLF sequences in the canonical
    606    representation of the message are encoded as the local newline
    607    convention.  Note that formats which encode CRLF sequences as, for
    608    example, LF are not capable of representing MIME messages containing
    609    binary data which contains LF octets not part of CRLF line separation
    610    sequences.
    611 
    612 
    613 
    614 
    615 
    616 
    617 
    618 Freed & Borenstein          Standards Track                    [Page 11]
    619 
    620 RFC 2049                    MIME Conformance               November 1996
    621 
    622 
    623 5.  Summary
    624 
    625    This document defines what is meant by MIME Conformance. It also
    626    details various problems known to exist in the Internet email system
    627    and how to use MIME to overcome them. Finally, it describes MIME's
    628    canonical encoding model.
    629 
    630 6.  Security Considerations
    631 
    632    Security issues are discussed in the second document in this set, RFC
    633    2046.
    634 
    635 7.  Authors' Addresses
    636 
    637    For more information, the authors of this document are best contacted
    638    via Internet mail:
    639 
    640    Ned Freed
    641    Innosoft International, Inc.
    642    1050 East Garvey Avenue South
    643    West Covina, CA 91790
    644    USA
    645 
    646    Phone: +1 818 919 3600
    647    Fax:   +1 818 919 3614
    648    EMail: ned@innosoft.com
    649 
    650    Nathaniel S. Borenstein
    651    First Virtual Holdings
    652    25 Washington Avenue
    653    Morristown, NJ 07960
    654    USA
    655 
    656    Phone: +1 201 540 8967
    657    Fax:   +1 201 993 3032
    658    EMail: nsb@nsb.fv.com
    659 
    660    MIME is a result of the work of the Internet Engineering Task Force
    661    Working Group on RFC 822 Extensions.  The chairman of that group,
    662    Greg Vaudreuil, may be reached at:
    663 
    664    Gregory M. Vaudreuil
    665    Octel Network Services
    666    17080 Dallas Parkway
    667    Dallas, TX 75248-1905
    668    USA
    669 
    670    EMail: Greg.Vaudreuil@Octel.Com
    671 
    672 
    673 
    674 Freed & Borenstein          Standards Track                    [Page 12]
    675 
    676 RFC 2049                    MIME Conformance               November 1996
    677 
    678 
    679 8.  Acknowledgements
    680 
    681    This document is the result of the collective effort of a large
    682    number of people, at several IETF meetings, on the IETF-SMTP and
    683    IETF-822 mailing lists, and elsewhere.  Although any enumeration
    684    seems doomed to suffer from egregious omissions, the following are
    685    among the many contributors to this effort:
    686 
    687      Harald Tveit Alvestrand       Marc Andreessen
    688      Randall Atkinson              Bob Braden
    689      Philippe Brandon              Brian Capouch
    690      Kevin Carosso                 Uhhyung Choi
    691      Peter Clitherow               Dave Collier-Brown
    692      Cristian Constantinof         John Coonrod
    693      Mark Crispin                  Dave Crocker
    694      Stephen Crocker               Terry Crowley
    695      Walt Daniels                  Jim Davis
    696      Frank Dawson                  Axel Deininger
    697      Hitoshi Doi                   Kevin Donnelly
    698      Steve Dorner                  Keith Edwards
    699      Chris Eich                    Dana S. Emery
    700      Johnny Eriksson               Craig Everhart
    701      Patrik Faltstrom              Erik E. Fair
    702      Roger Fajman                  Alain Fontaine
    703      Martin Forssen                James M. Galvin
    704      Stephen Gildea                Philip Gladstone
    705      Thomas Gordon                 Keld Simonsen
    706      Terry Gray                    Phill Gross
    707      James Hamilton                David Herron
    708      Mark Horton                   Bruce Howard
    709      Bill Janssen                  Olle Jarnefors
    710      Risto Kankkunen               Phil Karn
    711      Alan Katz                     Tim Kehres
    712      Neil Katin                    Steve Kille
    713      Kyuho Kim                     Anders Klemets
    714      John Klensin                  Valdis Kletniek
    715      Jim Knowles                   Stev Knowles
    716      Bob Kummerfeld                Pekka Kytolaakso
    717      Stellan Lagerstrom            Vincent Lau
    718      Timo Lehtinen                 Donald Lindsay
    719      Warner Losh                   Carlyn Lowery
    720      Laurence Lundblade            Charles Lynn
    721      John R. MacMillan             Larry Masinter
    722      Rick McGowan                  Michael J. McInerny
    723      Leo Mclaughlin                Goli Montaser-Kohsari
    724      Tom Moore                     John Gardiner Myers
    725      Erik Naggum                   Mark Needleman
    726      Chris Newman                  John Noerenberg
    727 
    728 
    729 
    730 Freed & Borenstein          Standards Track                    [Page 13]
    731 
    732 RFC 2049                    MIME Conformance               November 1996
    733 
    734 
    735      Mats Ohrman                   Julian Onions
    736      Michael Patton                David J. Pepper
    737      Erik van der Poel             Blake C. Ramsdell
    738      Christer Romson               Luc Rooijakkers
    739      Marshall T. Rose              Jonathan Rosenberg
    740      Guido van Rossum              Jan Rynning
    741      Harri Salminen                Michael Sanderson
    742      Yutaka Sato                   Markku Savela
    743      Richard Alan Schafer          Masahiro Sekiguchi
    744      Mark Sherman                  Bob Smart
    745      Peter Speck                   Henry Spencer
    746      Einar Stefferud               Michael Stein
    747      Klaus Steinberger             Peter Svanberg
    748      James Thompson                Steve Uhler
    749      Stuart Vance                  Peter Vanderbilt
    750      Greg Vaudreuil                Ed Vielmetti
    751      Larry W. Virden               Ryan Waldron
    752      Rhys Weatherly                Jay Weber
    753      Dave Wecker                   Wally Wedel
    754      Sven-Ove Westberg             Brian Wideen
    755      John Wobus                    Glenn Wright
    756      Rayan Zachariassen            David Zimmerman
    757 
    758    The authors apologize for any omissions from this list, which are
    759    certainly unintentional.
    760 
    761 
    762 
    763 
    764 
    765 
    766 
    767 
    768 
    769 
    770 
    771 
    772 
    773 
    774 
    775 
    776 
    777 
    778 
    779 
    780 
    781 
    782 
    783 
    784 
    785 
    786 Freed & Borenstein          Standards Track                    [Page 14]
    787 
    788 RFC 2049                    MIME Conformance               November 1996
    789 
    790 
    791 Appendix A -- A Complex Multipart Example
    792 
    793    What follows is the outline of a complex multipart message.  This
    794    message contains five parts that are to be displayed serially:  two
    795    introductory plain text objects, an embedded multipart message, a
    796    text/enriched object, and a closing encapsulated text message in a
    797    non-ASCII character set.  The embedded multipart message itself
    798    contains two objects to be displayed in parallel, a picture and an
    799    audio fragment.
    800 
    801      MIME-Version: 1.0
    802      From: Nathaniel Borenstein <nsb@nsb.fv.com>
    803      To: Ned Freed <ned@innosoft.com>
    804      Date: Fri, 07 Oct 1994 16:15:05 -0700 (PDT)
    805      Subject: A multipart example
    806      Content-Type: multipart/mixed;
    807                    boundary=unique-boundary-1
    808 
    809      This is the preamble area of a multipart message.
    810      Mail readers that understand multipart format
    811      should ignore this preamble.
    812 
    813      If you are reading this text, you might want to
    814      consider changing to a mail reader that understands
    815      how to properly display multipart messages.
    816 
    817      --unique-boundary-1
    818 
    819        ... Some text appears here ...
    820 
    821      [Note that the blank between the boundary and the start
    822       of the text in this part means no header fields were
    823       given and this is text in the US-ASCII character set.
    824       It could have been done with explicit typing as in the
    825       next part.]
    826 
    827      --unique-boundary-1
    828      Content-type: text/plain; charset=US-ASCII
    829 
    830      This could have been part of the previous part, but
    831      illustrates explicit versus implicit typing of body
    832      parts.
    833 
    834      --unique-boundary-1
    835      Content-Type: multipart/parallel; boundary=unique-boundary-2
    836 
    837      --unique-boundary-2
    838      Content-Type: audio/basic
    839 
    840 
    841 
    842 Freed & Borenstein          Standards Track                    [Page 15]
    843 
    844 RFC 2049                    MIME Conformance               November 1996
    845 
    846 
    847      Content-Transfer-Encoding: base64
    848 
    849        ... base64-encoded 8000 Hz single-channel
    850            mu-law-format audio data goes here ...
    851 
    852      --unique-boundary-2
    853      Content-Type: image/jpeg
    854      Content-Transfer-Encoding: base64
    855 
    856        ... base64-encoded image data goes here ...
    857 
    858      --unique-boundary-2--
    859 
    860      --unique-boundary-1
    861      Content-type: text/enriched
    862 
    863      This is <bold><italic>enriched.</italic></bold>
    864      <smaller>as defined in RFC 1896</smaller>
    865 
    866      Isn't it
    867      <bigger><bigger>cool?</bigger></bigger>
    868 
    869      --unique-boundary-1
    870      Content-Type: message/rfc822
    871 
    872      From: (mailbox in US-ASCII)
    873      To: (address in US-ASCII)
    874      Subject: (subject in US-ASCII)
    875      Content-Type: Text/plain; charset=ISO-8859-1
    876      Content-Transfer-Encoding: Quoted-printable
    877 
    878        ... Additional text in ISO-8859-1 goes here ...
    879 
    880      --unique-boundary-1--
    881 
    882 Appendix B -- Changes from RFC 1521, 1522, and 1590
    883 
    884    These documents are a revision of RFC 1521, 1522, and 1590.  For the
    885    convenience of those familiar with the earlier documents, the changes
    886    from those documents are summarized in this appendix.  For further
    887    history, note that Appendix H in RFC 1521 specified how that document
    888    differed from its predecessor, RFC 1341.
    889 
    890     (1)   This document has been completely reformatted and split
    891           into multiple documents.  This was done to improve the
    892           quality of the plain text version of this document,
    893           which is required to be the reference copy.
    894 
    895 
    896 
    897 
    898 Freed & Borenstein          Standards Track                    [Page 16]
    899 
    900 RFC 2049                    MIME Conformance               November 1996
    901 
    902 
    903     (2)   BNF describing the overall structure of MIME object
    904           headers has been added. This is a documentation change
    905           only -- the underlying syntax has not changed in any
    906           way.
    907 
    908     (3)   The specific BNF for the seven media types in MIME has
    909           been removed.  This BNF was incorrect, incomplete, amd
    910           inconsistent with the type-indendependent BNF.  And
    911           since the type-independent BNF already fully specifies
    912           the syntax of the various MIME headers, the type-
    913           specific BNF was, in the final analysis, completely
    914           unnecessary and caused more problems than it solved.
    915 
    916     (4)   The more specific "US-ASCII" character set name has
    917           replaced the use of the informal term ASCII in many
    918           parts of these documents.
    919 
    920     (5)   The informal concept of a primary subtype has been
    921           removed.
    922 
    923     (6)   The term "object" was being used inconsistently.  The
    924           definition of this term has been clarified, along with
    925           the related terms "body", "body part", and "entity",
    926           and usage has been corrected where appropriate.
    927 
    928     (7)   The BNF for the multipart media type has been
    929           rearranged to make it clear that the CRLF preceeding
    930           the boundary marker is actually part of the marker
    931           itself rather than the preceeding body part.
    932 
    933     (8)   The prose and BNF describing the multipart media type
    934           have been changed to make it clear that the body parts
    935           within a multipart object MUST NOT contain any lines
    936           beginning with the boundary parameter string.
    937 
    938     (9)   In the rules on reassembling "message/partial" MIME
    939           entities, "Subject" is added to the list of headers to
    940           take from the inner message, and the example is
    941           modified to clarify this point.
    942 
    943     (10)  "Message/partial" fragmenters are restricted to
    944           splitting MIME objects only at line boundaries.
    945 
    946     (11)  In the discussion of the application/postscript type,
    947           an additional paragraph has been added warning about
    948           possible interoperability problems caused by embedding
    949           of binary data inside a PostScript MIME entity.
    950 
    951 
    952 
    953 
    954 Freed & Borenstein          Standards Track                    [Page 17]
    955 
    956 RFC 2049                    MIME Conformance               November 1996
    957 
    958 
    959     (12)  Added a clarifying note to the basic syntax rules for
    960           the Content-Type header field to make it clear that the
    961           following two forms:
    962 
    963             Content-type: text/plain; charset=us-ascii (comment)
    964 
    965             Content-type: text/plain; charset="us-ascii"
    966 
    967           are completely equivalent.
    968 
    969     (13)  The following sentence has been removed from the
    970           discussion of the MIME-Version header: "However,
    971           conformant software is encouraged to check the version
    972           number and at least warn the user if an unrecognized
    973           MIME-version is encountered."
    974 
    975     (14)  A typo was fixed that said "application/external-body"
    976           instead of "message/external-body".
    977 
    978     (15)  The definition of a character set has been reorganized
    979           to make the requirements clearer.
    980 
    981     (16)  The definition of the "image/gif" media type has been
    982           moved to a separate document. This change was made
    983           because of potential conflicts with IETF rules
    984           governing the standardization of patented technology.
    985 
    986     (17)  The definitions of "7bit" and "8bit" have been
    987           tightened so that use of bare CR, LF can only be used
    988           as end-of-line sequences.  The document also no longer
    989           requires that NUL characters be preserved, which brings
    990           MIME into alignment with real-world implementations.
    991 
    992     (18)  The definition of canonical text in MIME has been
    993           tightened so that line breaks must be represented by a
    994           CRLF sequence.  CR and LF characters are not allowed
    995           outside of this usage.  The definition of quoted-
    996           printable encoding has been altered accordingly.
    997 
    998     (19)  The definition of the quoted-printable encoding now
    999           includes a number of suggestions for how quoted-
   1000           printable encoders might best handle improperly encoded
   1001           material.
   1002 
   1003     (20)  Prose was added to clarify the use of the "7bit",
   1004           "8bit", and "binary" transfer-encodings on multipart or
   1005           message entities encapsulating "8bit" or "binary" data.
   1006 
   1007 
   1008 
   1009 
   1010 Freed & Borenstein          Standards Track                    [Page 18]
   1011 
   1012 RFC 2049                    MIME Conformance               November 1996
   1013 
   1014 
   1015     (21)  In the section on MIME Conformance, "multipart/digest"
   1016           support was added to the list of requirements for
   1017           minimal MIME conformance.  Also, the requirement for
   1018           "message/rfc822" support were strengthened to clarify
   1019           the importance of recognizing recursive structure.
   1020 
   1021     (22)  The various restrictions on subtypes of "message" are
   1022           now specified entirely on a subtype by subtype basis.
   1023 
   1024     (23)  The definition of "message/rfc822" was changed to
   1025           indicate that at least one of the "From", "Subject", or
   1026           "Date" headers must be present.
   1027 
   1028     (24)  The required handling of unrecognized subtypes as
   1029           "application/octet-stream" has been made more explicit
   1030           in both the type definitions sections and the
   1031           conformance guidelines.
   1032 
   1033     (25)  Examples using text/richtext were changed to
   1034           text/enriched.
   1035 
   1036     (26)  The BNF definition of subtype has been changed to make
   1037           it clear that either an IANA registered subtype or a
   1038           nonstandard "X-" subtype must be used in a Content-Type
   1039           header field.
   1040 
   1041     (27)  MIME media types that are simply registered for use and
   1042           those that are standardized by the IETF are now
   1043           distinguished in the MIME BNF.
   1044 
   1045     (28)  All of the various MIME registration procedures have
   1046           been extensively revised. IANA registration procedures
   1047           for character sets have been moved to a separate
   1048           document that is no included in this set of documents.
   1049 
   1050     (29)  The use of escape and shift mechanisms in the US-ASCII
   1051           and ISO-8859-X character sets these documents define
   1052           have been clarified: Such mechanisms should never be
   1053           used in conjunction with these character sets and their
   1054           effect if they are used is undefined.
   1055 
   1056     (30)  The definition of the AFS access-type for
   1057           message/external-body has been removed.
   1058 
   1059     (31)  The handling of the combination of
   1060           multipart/alternative and message/external-body is now
   1061           specifically addressed.
   1062 
   1063 
   1064 
   1065 
   1066 Freed & Borenstein          Standards Track                    [Page 19]
   1067 
   1068 RFC 2049                    MIME Conformance               November 1996
   1069 
   1070 
   1071     (32)  Security issues specific to message/external-body are
   1072           now discussed in some detail.
   1073 
   1074 Appendix C -- References
   1075 
   1076    [ATK]
   1077         Borenstein, Nathaniel S., Multimedia Applications
   1078         Development with the Andrew Toolkit, Prentice-Hall, 1990.
   1079 
   1080    [ISO-2022]
   1081         International Standard -- Information Processing --
   1082         Character Code Structure and Extension Techniques,
   1083         ISO/IEC 2022:1994, 4th ed.
   1084 
   1085    [ISO-8859]
   1086         International Standard -- Information Processing -- 8-bit
   1087         Single-Byte Coded Graphic Character Sets
   1088         - Part 1: Latin Alphabet No. 1, ISO 8859-1:1987, 1st ed.
   1089         - Part 2: Latin Alphabet No. 2, ISO 8859-2:1987, 1st ed.
   1090         - Part 3: Latin Alphabet No. 3, ISO 8859-3:1988, 1st ed.
   1091         - Part 4: Latin Alphabet No. 4, ISO 8859-4:1988, 1st ed.
   1092         - Part 5: Latin/Cyrillic Alphabet, ISO 8859-5:1988, 1st
   1093         ed.
   1094         - Part 6: Latin/Arabic Alphabet, ISO 8859-6:1987, 1st ed.
   1095         - Part 7: Latin/Greek Alphabet, ISO 8859-7:1987, 1st ed.
   1096         - Part 8: Latin/Hebrew Alphabet, ISO 8859-8:1988, 1st ed.
   1097         - Part 9: Latin Alphabet No. 5, ISO/IEC 8859-9:1989, 1st
   1098         ed.
   1099         International Standard -- Information Technology -- 8-bit
   1100         Single-Byte Coded Graphic Character Sets
   1101         - Part 10: Latin Alphabet No. 6, ISO/IEC 8859-10:1992,
   1102         1st ed.
   1103 
   1104    [ISO-646]
   1105         International Standard -- Information Technology -- ISO
   1106         7-bit Coded Character Set for Information Interchange,
   1107         ISO 646:1991, 3rd ed..
   1108 
   1109    [JPEG]
   1110         JPEG Draft Standard ISO 10918-1 CD.
   1111 
   1112    [MPEG]
   1113         Video Coding Draft Standard ISO 11172 CD, ISO
   1114         IEC/JTC1/SC2/WG11 (Motion Picture Experts Group), May,
   1115         1991.
   1116 
   1117 
   1118 
   1119 
   1120 
   1121 
   1122 Freed & Borenstein          Standards Track                    [Page 20]
   1123 
   1124 RFC 2049                    MIME Conformance               November 1996
   1125 
   1126 
   1127    [PCM]
   1128         CCITT, Fascicle III.4 - Recommendation G.711, "Pulse Code
   1129         Modulation (PCM) of Voice Frequencies", Geneva, 1972.
   1130 
   1131    [POSTSCRIPT]
   1132         Adobe Systems, Inc., PostScript Language Reference
   1133         Manual, Addison-Wesley, 1985.
   1134 
   1135    [POSTSCRIPT2]
   1136         Adobe Systems, Inc., PostScript Language Reference
   1137         Manual, Addison-Wesley, Second Ed., 1990.
   1138 
   1139    [RFC-783]
   1140         Sollins, K.R., "TFTP Protocol (revision 2)", RFC-783,
   1141         MIT, June 1981.
   1142 
   1143    [RFC-821]
   1144         Postel, J.B., "Simple Mail Transfer Protocol", STD 10,
   1145         RFC 821, USC/Information Sciences Institute, August 1982.
   1146 
   1147    [RFC-822]
   1148         Crocker, D., "Standard for the Format of ARPA Internet
   1149         Text Messages", STD 11, RFC 822, UDEL, August 1982.
   1150 
   1151    [RFC-934]
   1152         Rose, M. and E. Stefferud, "Proposed Standard for Message
   1153         Encapsulation", RFC 934, Delaware and NMA, January 1985.
   1154 
   1155    [RFC-959]
   1156         Postel, J. and J. Reynolds, "File Transfer Protocol", STD
   1157         9, RFC 959, USC/Information Sciences Institute, October
   1158         1985.
   1159 
   1160    [RFC-1049]
   1161         Sirbu, M., "Content-Type Header Field for Internet
   1162         Messages", RFC 1049, CMU, March 1988.
   1163 
   1164    [RFC-1154]
   1165         Robinson, D., and R. Ullmann, "Encoding Header Field for
   1166         Internet Messages", RFC 1154, Prime Computer, Inc., April
   1167         1990.
   1168 
   1169    [RFC-1341]
   1170         Borenstein, N., and N.  Freed, "MIME (Multipurpose
   1171         Internet Mail Extensions): Mechanisms for Specifying and
   1172         Describing the Format of Internet Message Bodies", RFC
   1173         1341, Bellcore, Innosoft, June 1992.
   1174 
   1175 
   1176 
   1177 
   1178 Freed & Borenstein          Standards Track                    [Page 21]
   1179 
   1180 RFC 2049                    MIME Conformance               November 1996
   1181 
   1182 
   1183    [RFC-1342]
   1184         Moore, K., "Representation of Non-Ascii Text in Internet
   1185         Message Headers", RFC 1342, University of Tennessee, June
   1186         1992.
   1187 
   1188    [RFC-1344]
   1189         Borenstein, N., "Implications of MIME for Internet Mail
   1190         Gateways", RFC 1344, Bellcore, June 1992.
   1191 
   1192    [RFC-1345]
   1193         Simonsen, K., "Character Mnemonics & Character Sets", RFC
   1194         1345, Rationel Almen Planlaegning, June 1992.
   1195 
   1196    [RFC-1421]
   1197         Linn, J., "Privacy Enhancement for Internet Electronic
   1198         Mail:  Part I -- Message Encryption and Authentication
   1199         Procedures", RFC 1421, IAB IRTF PSRG, IETF PEM WG,
   1200         February 1993.
   1201 
   1202    [RFC-1422]
   1203         Kent, S., "Privacy Enhancement for Internet Electronic
   1204         Mail:  Part II -- Certificate-Based Key Management", RFC
   1205         1422, IAB IRTF PSRG, IETF PEM WG, February 1993.
   1206 
   1207    [RFC-1423]
   1208         Balenson, D., "Privacy Enhancement for Internet
   1209         Electronic Mail:  Part III -- Algorithms, Modes, and
   1210         Identifiers",  IAB IRTF PSRG, IETF PEM WG, February 1993.
   1211 
   1212    [RFC-1424]
   1213         Kaliski, B., "Privacy Enhancement for Internet Electronic
   1214         Mail:  Part IV -- Key Certification and Related
   1215         Services", IAB IRTF PSRG, IETF PEM WG, February 1993.
   1216 
   1217    [RFC-1521]
   1218         Borenstein, N., and Freed, N., "MIME (Multipurpose
   1219         Internet Mail Extensions): Mechanisms for Specifying and
   1220         Describing the Format of Internet Message Bodies", RFC
   1221         1521, Bellcore, Innosoft, September, 1993.
   1222 
   1223    [RFC-1522]
   1224         Moore, K., "Representation of Non-ASCII Text in Internet
   1225         Message Headers", RFC 1522, University of Tennessee,
   1226         September 1993.
   1227 
   1228 
   1229 
   1230 
   1231 
   1232 
   1233 
   1234 Freed & Borenstein          Standards Track                    [Page 22]
   1235 
   1236 RFC 2049                    MIME Conformance               November 1996
   1237 
   1238 
   1239    [RFC-1524]
   1240         Borenstein, N., "A User Agent Configuration Mechanism for
   1241         Multimedia Mail Format Information", RFC 1524, Bellcore,
   1242         September 1993.
   1243 
   1244    [RFC-1543]
   1245         Postel, J., "Instructions to RFC Authors", RFC 1543,
   1246         USC/Information Sciences Institute, October 1993.
   1247 
   1248    [RFC-1556]
   1249         Nussbacher, H., "Handling of Bi-directional Texts in
   1250         MIME", RFC 1556, Israeli Inter-University Computer
   1251         Center, December 1993.
   1252 
   1253    [RFC-1590]
   1254         Postel, J., "Media Type Registration Procedure", RFC
   1255         1590, USC/Information Sciences Institute, March 1994.
   1256 
   1257    [RFC-1602]
   1258         Internet Architecture Board, Internet Engineering
   1259         Steering Group, Huitema, C., Gross, P., "The Internet
   1260         Standards Process -- Revision 2", March 1994.
   1261 
   1262    [RFC-1652]
   1263         Klensin, J., (WG Chair), Freed, N., (Editor), Rose, M.,
   1264         Stefferud, E., and Crocker, D., "SMTP Service Extension
   1265         for 8bit-MIME transport", RFC 1652, United Nations
   1266         University, Innosoft, Dover Beach Consulting, Inc.,
   1267         Network Management Associates, Inc., The Branch Office,
   1268         March 1994.
   1269 
   1270    [RFC-1700]
   1271         Reynolds, J. and J. Postel, "Assigned Numbers", STD 2,
   1272         RFC 1700, USC/Information Sciences Institute, October
   1273         1994.
   1274 
   1275    [RFC-1741]
   1276         Faltstrom, P., Crocker, D., and Fair, E., "MIME Content
   1277         Type for BinHex Encoded Files", December 1994.
   1278 
   1279    [RFC-1896]
   1280         Resnick, P., and A. Walker, "The text/enriched MIME
   1281         Content-type", RFC 1896, February, 1996.
   1282 
   1283 
   1284 
   1285 
   1286 
   1287 
   1288 
   1289 
   1290 Freed & Borenstein          Standards Track                    [Page 23]
   1291 
   1292 RFC 2049                    MIME Conformance               November 1996
   1293 
   1294 
   1295    [RFC-2045]
   1296         Freed, N., and and N. Borenstein, "Multipurpose Internet Mail
   1297         Extensions (MIME) Part One: Format of Internet Message
   1298         Bodies", RFC 2045, Innosoft, First Virtual Holdings,
   1299         November 1996.
   1300 
   1301    [RFC-2046]
   1302         Freed, N., and N. Borenstein, "Multipurpose Internet Mail
   1303         Extensions (MIME) Part Two: Media Types", RFC 2046,
   1304         Innosoft, First Virtual Holdings, November 1996.
   1305 
   1306    [RFC-2047]
   1307         Moore, K., "Multipurpose Internet Mail Extensions (MIME)
   1308         Part Three: Representation of Non-ASCII Text in Internet
   1309         Message Headers", RFC 2047, University of
   1310         Tennessee, November 1996.
   1311 
   1312    [RFC-2048]
   1313         Freed, N., Klensin, J., and J. Postel, "Multipurpose
   1314         Internet Mail Extensions (MIME) Part Four: MIME
   1315         Registration Procedures", RFC 2048, Innosoft, MCI,
   1316         ISI, November 1996.
   1317 
   1318    [RFC-2049]
   1319         Freed, N. and N. Borenstein, "Multipurpose Internet Mail
   1320         Extensions (MIME) Part Five: Conformance Criteria and
   1321         Examples", RFC 2049 (this document), Innosoft, First
   1322         Virtual Holdings, November 1996.
   1323 
   1324    [US-ASCII]
   1325         Coded Character Set -- 7-Bit American Standard Code for
   1326         Information Interchange, ANSI X3.4-1986.
   1327 
   1328    [X400]
   1329         Schicker, Pietro, "Message Handling Systems, X.400",
   1330         Message Handling Systems and Distributed Applications, E.
   1331         Stefferud, O-j. Jacobsen, and P. Schicker, eds., North-
   1332         Holland, 1989, pp. 3-41.
   1333 
   1334 
   1335 
   1336 
   1337 
   1338 
   1339 
   1340 
   1341 
   1342 
   1343 
   1344 
   1345 
   1346 Freed & Borenstein          Standards Track                    [Page 24]
   1347