home *** CD-ROM | disk | FTP | other *** search
/ Magazyn WWW 1998 October / Image.iso / info / ogonki / rfc1522.txt < prev    next >
Text File  |  1998-09-09  |  47KB  |  1,170 lines
  1. Network Working Group                                           K. Moore
  2. Request for Comments: 1522                       University of Tennessee
  3. Obsoletes: 1342                                           September 1993
  4. Category: Standards Track
  5.  
  6.  
  7.          MIME (Multipurpose Internet Mail Extensions) Part Two:
  8.               Message Header Extensions for Non-ASCII Text
  9.  
  10. Status of this Memo
  11.  
  12.    This RFC specifies an Internet standards track protocol for the
  13.    Internet community, and requests discussion and suggestions for
  14.    improvements.  Please refer to the current edition of the "Internet
  15.    Official Protocol Standards" for the standardization state and status
  16.    of this protocol.  Distribution of this memo is unlimited.
  17.  
  18. Abstract
  19.  
  20.    This memo describes an extension to the message format defined in RFC
  21.    1521 [1], to allow the representation of character sets other than
  22.    ASCII in RFC 822 (STD 11) message headers.  The extensions described
  23.    were designed to be highly compatible with existing Internet mail
  24.    handling software, and to be easily implemented in mail readers that
  25.    support RFC 1521.
  26.  
  27. 1. Introduction
  28.  
  29.    RFC 1521 describes a mechanism for denoting textual body parts which
  30.    are coded in various character sets, as well as methods for encoding
  31.    such body parts as sequences of printable ASCII characters.  This
  32.    memo describes similar techniques to allow the encoding of non-ASCII
  33.    text in various portions of a RFC 822 [2] message header, in a manner
  34.    which is unlikely to confuse existing message handling software.
  35.  
  36.    Like the encoding techniques described in RFC 1521, the techniques
  37.    outlined here were designed to allow the use of non-ASCII characters
  38.    in message headers in a way which is unlikely to be disturbed by the
  39.    quirks of existing Internet mail handling programs.  In particular,
  40.    some mail relaying programs are known to (a) delete some message
  41.    header fields while retaining others, (b) rearrange the order of
  42.    addresses in To or Cc fields, (c) rearrange the (vertical) order of
  43.    header fields, and/or (d) "wrap" message headers at different places
  44.    than those in the original message.  In addition, some mail reading
  45.    programs are known to have difficulty correctly parsing message
  46.    headers which, while legal according to RFC 822, make use of
  47.    backslash-quoting to "hide" special characters such as "<", ",", or
  48.    ":", or which exploit other infrequently-used features of that
  49.  
  50.  
  51.  
  52. Moore                                                           [Page 1]
  53. =0C
  54. RFC 1522                     MIME Part Two                September 1993
  55.  
  56.  
  57.    specification.
  58.  
  59.    While it is unfortunate that these programs do not correctly
  60.    interpret RFC 822 headers, to "break" these programs would cause
  61.    severe operational problems for the Internet mail system.  The
  62.    extensions described in this memo therefore do not rely on little-
  63.    used features of RFC 822.
  64.  
  65.    Instead, certain sequences of "ordinary" printable ASCII characters
  66.    (known as "encoded-words") are reserved for use as encoded data.  The
  67.    syntax of encoded-words is such that they are unlikely to
  68.    "accidentally" appear as normal text in message headers.
  69.    Furthermore, the characters used in encoded-words are restricted to
  70.    those which do not have special meanings in the context in which the
  71.    encoded-word appears.
  72.  
  73.    Generally, an "encoded-word" is a sequence of printable ASCII
  74.    characters that begins with "=3D?", ends with "?=3D", and has two "?"s i=
  75. n
  76.    between.  It specifies a character set and an encoding method, and
  77.    also includes the original text encoded as graphic ASCII characters,
  78.    according to the rules for that encoding method.
  79.  
  80.    A mail composer that implements this specification will provide a
  81.    means of inputting non-ASCII text in header fields, but will
  82.    translate these fields (or appropriate portions of these fields) into
  83.    encoded-words before inserting them into the message header.
  84.  
  85.    A mail reader that implements this specification will recognize
  86.    encoded-words when they appear in certain portions of the message
  87.    header.  Instead of displaying the encoded-word "as is", it will
  88.    reverse the encoding and display the original text in the designated
  89.    character set.
  90.  
  91.    NOTES
  92.  
  93.       This memo relies heavily on notation and terms defined STD 11, RFC
  94.       822 and RFC 1521.  In particular, the syntax for the ABNF used in
  95.       this memo is defined in STD 11, RFC 822, as well as many of the
  96.       terms used in the grammar for the header extensions defined here.
  97.       Successful implementation of this protocol extension requires
  98.       careful attention to the details of both STD 11, RFC 822 and RFC
  99.       1521.
  100.  
  101.       When the term "ASCII" appears in this memo, it refers to the "7-
  102.       Bit American Standard Code for Information Interchange", ANSI
  103.       X3.4-1986.  The MIME charset name for this character set is "US-
  104.       ASCII".  When not specifically referring to the MIME charset name,
  105.       this document uses the term "ASCII", both for brevity and for
  106.  
  107.  
  108.  
  109. Moore                                                           [Page 2]
  110. =0C
  111. RFC 1522                     MIME Part Two                September 1993
  112.  
  113.  
  114.       consistency with STD 11, RFC 822.  However, implementors are
  115.       warned that the character set name must be spelled "US-ASCII" in
  116.       MIME message and body part headers.
  117.  
  118. 2. Syntax of encoded-words
  119.  
  120.    An "encoded-word" is defined by the following ABNF grammar.  The
  121.    notation of RFC 822 is used, with the exception that white space
  122.    characters MAY NOT appear between components of an encoded-word.
  123.  
  124.    encoded-word =3D "=3D?" charset "?" encoding "?" encoded-text "?=3D"
  125.  
  126.    charset =3D token    ; see section 3
  127.  
  128.    encoding =3D token   ; see section 4
  129.  
  130.    token =3D 1*<Any CHAR except SPACE, CTLs, and especials>
  131.  
  132.    especials =3D "(" / ")" / "<" / ">" / "@" / "," / ";" / ":" / "
  133.                <"> / "/" / "[" / "]" / "?" / "." / "=3D"
  134.  
  135.    encoded-text =3D 1*<Any printable ASCII character other
  136.                      than "?" or SPACE>
  137.                      ; (but see "Use of encoded-words in message
  138.                      ; headers", section 5)
  139.  
  140.    Both "encoding" and "charset" names are case-independent.  Thus the
  141.    charset name "ISO-8859-1" is equivalent to "iso-8859-1", and the
  142.    encoding named "Q" may be spelled either "Q" or "q".
  143.  
  144.    An encoded-word may not be more than 75 characters long, including
  145.    charset, encoding, encoded-text, and delimiters.  If it is desirable
  146.    to encode more text than will fit in an encoded-word of 75
  147.    characters, multiple encoded-words (separated by CRLF SPACE) may be
  148.    used.
  149.  
  150.    While there is no limit to the length of a multiple-line header
  151.    field, each line of a header field that contains one or more
  152.    encoded-words is limited to 76 characters.
  153.  
  154.    The length restrictions are included not only to ease
  155.    interoperability through internetwork mail gateways, but also to
  156.    impose a limit on the amount of lookahead a header parser must employ
  157.    (while looking for a final ?=3D delimiter) before it can decide whether
  158.    a token is an encoded-word or something else.
  159.  
  160.    The characters which may appear in encoded-text are further
  161.    restricted by the rules in section 5.
  162.  
  163.  
  164.  
  165. Moore                                                           [Page 3]
  166. =0C
  167. RFC 1522                     MIME Part Two                September 1993
  168.  
  169.  
  170. 3. Character sets
  171.  
  172.    The "charset" portion of an encoded-word specifies the character set
  173.    associated with the unencoded text.  A charset can be any of the
  174.    character set names allowed in an RFC 1521 "charset" parameter of a
  175.    "text/plain" body part, or any character set name registered with
  176.    IANA for use with the MIME text/plain content-type [3].  (See section
  177.    7.1.1 of RFC 1521 for a list of charsets defined in that document).
  178.  
  179.    Some character sets use code-switching techniques to switch between
  180.    "ASCII mode" and other modes.  If unencoded text in an encoded-word
  181.    contains control codes to switch out of ASCII mode, it must also
  182.    contain additional control codes such that ASCII mode is again
  183.    selected at the end of the encoded-word.  (This rule applies
  184.    separately to each encoded-word, including adjacent encoded-words
  185.    within a single header field.)
  186.  
  187.    When there is a possibility of using more than one character set to
  188.    represent the text in an encoded-word, and in the absence of private
  189.    agreements between sender and recipients of a message, it is
  190.    recommended that members of the ISO-8859-* series be used in
  191.    preference to other character sets.
  192.  
  193. 4. Encodings
  194.  
  195.    Initially, the legal values for "encoding" are "Q" and "B".  These
  196.    encodings are described below.  The "Q" encoding is recommended for
  197.    use when most of the characters to be encoded are in the ASCII
  198.    character set; otherwise, the "B" encoding should be used.
  199.    Nevertheless, a mail reader which claims to recognize encoded-words
  200.    MUST be able to accept either encoding for any character set which it
  201.    supports.
  202.  
  203.    Only a subset of the printable ASCII characters may be used in
  204.    encoded-text.  Space and tab characters are not allowed, so that the
  205.    beginning and end of an encoded-word are obvious.  The "?" character
  206.    is used within an encoded-word to separate the various portions of
  207.    the encoded-word from one another, and thus cannot appear in the
  208.    encoded-text portion.  Other characters are also illegal in certain
  209.    contexts.  For example, an encoded-word in a "phrase" preceding an
  210.    address in a From header field may not contain any of the "specials"
  211.    defined in RFC 822.  Finally, certain other characters are disallowed
  212.    in some contexts, to ensure reliability for messages that pass
  213.    through internetwork mail gateways.
  214.  
  215.    The "B" encoding automatically meets these requirements.  The "Q"
  216.    encoding allows a wide range of printable characters to be used in
  217.    non-critical locations in the message header (e.g., Subject), with
  218.  
  219.  
  220.  
  221. Moore                                                           [Page 4]
  222. =0C
  223. RFC 1522                     MIME Part Two                September 1993
  224.  
  225.  
  226.    fewer characters available for use in other locations.
  227.  
  228. 4.1. The "B" encoding
  229.  
  230.    The "B" encoding is identical to the "BASE64" encoding defined by RFC
  231.    1521.
  232.  
  233. 4.2. The "Q" encoding
  234.  
  235.    The "Q" encoding is similar to the "Quoted-Printable" content-
  236.    transfer-encoding defined in RFC 1521.  It is designed to allow text
  237.    containing mostly ASCII characters to be decipherable on an ASCII
  238.    terminal without decoding.
  239.  
  240.    (1) Any 8-bit value may be represented by a "=3D" followed by two
  241.        hexadecimal digits.  For example, if the character set in use
  242.        were ISO-8859-1, the "=3D" character would thus be encoded as
  243.        "=3D3D", and a SPACE by "=3D20".  (Upper case should be used for
  244.        hexadecimal digits "A" through "F".)
  245.  
  246.    (2) The 8-bit hexadecimal value 20 (e.g., ISO-8859-1 SPACE) may be
  247.        represented as "_" (underscore, ASCII 95.).  (This character may
  248.        not pass through some internetwork mail gateways, but its use
  249.        will greatly enhance readability of "Q" encoded data with mail
  250.        readers that do not support this encoding.)  Note that the "_"
  251.        always represents hexadecimal 20, even if the SPACE character
  252.        occupies a different code position in the character set in use.
  253.  
  254.    (3) 8-bit values which correspond to printable ASCII characters other
  255.        than "=3D", "?", "_" (underscore), and SPACE may be represented as
  256.        those characters.  (But see section 5 for restrictions.)
  257.  
  258. 5. Use of encoded-words in message headers
  259.  
  260.    An encoded-word may appear in a message header or body part header
  261.    according to the following rules:
  262.  
  263.    (1) An encoded-word may replace a "text" token (as defined by RFC
  264.        822) in any Subject or Comments header field, any extension
  265.        message header field, or any RFC 1521 body part field for which
  266.        the field body is defined as "*text".  An encoded-word may also
  267.        appear in any user-defined ("X-") message or body part header
  268.        field.
  269.  
  270.        Ordinary ASCII text and encoded-words may appear together in the
  271.        same header field.  However, an encoded-word that appears in a
  272.        header field defined as "*text" MUST be separated from any
  273.        adjacent encoded-word or "text" by linear-white-space.
  274.  
  275.  
  276.  
  277. Moore                                                           [Page 5]
  278. =0C
  279. RFC 1522                     MIME Part Two                September 1993
  280.  
  281.  
  282.    (2) An encoded-word may appear within a comment delimited by "(" and
  283.        ")", i.e., wherever a "ctext" is allowed.  More precisely, the
  284.        RFC 822 ABNF definition for "comment" is amended as follows:
  285.  
  286.        comment =3D "(" *(ctext / quoted-pair / comment / encoded-word) ")"
  287.  
  288.        A "Q"-encoded encoded-word which appears in a comment MUST NOT
  289.        contain the characters "(", ")" or " encoded-word that appears in
  290.        a "comment" MUST be separated from any adjacent encoded-word or
  291.        "ctext" by linear-white-space.
  292.  
  293.    (3) As a replacement for a "word" entity within a "phrase", for
  294.        example, one that precedes an address in a From, To, or Cc
  295.        header.  The ABNF definition for phrase from RFC 822 thus
  296.        becomes:
  297.  
  298.        phrase =3D 1*(encoded-word / word)
  299.  
  300.        In this case the set of characters that may be used in a "Q"-
  301.        encoded encoded-word is restricted to: <upper and lower case
  302.        ASCII letters, decimal digits, "!", "*", "+", "-", "/", "=3D", and
  303.        "_" (underscore, ASCII 95.)>.  An encoded-word that appears
  304.        within a "phrase" MUST be separated from any adjacent "word",
  305.        "text" or "special" by linear-white-space.
  306.  
  307.    These are the ONLY locations where an encoded-word may appear.  In
  308.    particular, an encoded-word MUST NOT appear in any portion of an
  309.    "addr-spec".  In addition, an encoded-word MUST NOT be used in a
  310.    Received header field.
  311.  
  312.    Each encoded-word MUST encode an integral number of octets.  The
  313.    encoded-text in each encoded-word must be well-formed according to
  314.    the encoding specified; the encoded-text may not be continued in the
  315.    next encoded-word.  (For example, "=3D?charset?Q?=3D?=3D =3D?charset?Q?A=
  316. B?=3D"
  317.    would be illegal, because the two hex digits "AB" must follow the "=3D"
  318.    in the same encoded-word.)
  319.  
  320.    Each encoded-word MUST represent an integral number of characters. A
  321.    multi-octet character may not be split across adjacent encoded-words.
  322.  
  323.    Only printable and white space character data should be encoded using
  324.    this scheme.  However, since these encoding schemes allow the
  325.    encoding of arbitrary octet values, mail readers that implement this
  326.    decoding should also ensure that display of the decoded data on the
  327.    recipient's terminal will not cause unwanted side-effects.
  328.  
  329.    Use of these methods to encode non-textual data (e.g., pictures or
  330.    sounds) is not defined by this memo.  Use of encoded-words to
  331.  
  332.  
  333.  
  334. Moore                                                           [Page 6]
  335. =0C
  336. RFC 1522                     MIME Part Two                September 1993
  337.  
  338.  
  339.    represent strings of purely ASCII characters is allowed, but
  340.    discouraged.  In rare cases it may be necessary to encode ordinary
  341.    text that looks like an encoded-word.
  342.  
  343. 6. Support of encoded-words by mail readers
  344.  
  345. 6.1. Recognition of encoded-words in message headers
  346.  
  347.    A mail reader must parse the message and body part headers according
  348.    to the rules in RFC 822 to correctly recognize encoded-words.
  349.  
  350.    Encoded-words are to be recognized as follows:
  351.  
  352.    (1) Any message or body part header field defined as "*text", or any
  353.        user-defined header field, should be parsed as follows: Beginning
  354.        at the start of the field-body and immediately following each
  355.        occurrence of linear-white-space, each sequence of up to 75
  356.        printable characters (not containing any linear-white-space)
  357.        should be examined to see if it is an encoded-word according to
  358.        the syntax rules in section 2.  Any other sequence of printable
  359.        characters should be treated as ordinary ASCII text.
  360.  
  361.    (2) Any header field not defined as "*text" should be parsed
  362.        according to the syntax rules for that header field.  However,
  363.        any "word" that appears within a "phrase" should be treated as an
  364.        encoded-word if it meets the syntax rules in section 2.
  365.        Otherwise it should be treated as an ordinary "word".
  366.  
  367.    (3) Within a "comment", any sequence of up to 75 printable characters
  368.        (not containing linear-white-space), that meets the syntax rules
  369.        in section 2, should be treated as an encoded-word.  Otherwise it
  370.        should be treated as normal comment text.
  371.  
  372. 6.2. Display of encoded-words
  373.  
  374.    Any encoded-words so recognized are decoded, and if possible, the
  375.    resulting unencoded text is displayed in the original character set.
  376.  
  377.    When displaying a particular header field that contains multiple
  378.    encoded-words, any linear-white-space that separates a pair of
  379.    adjacent encoded-words is ignored.  (This is to allow the use of
  380.    multiple encoded-words to represent long strings of unencoded text,
  381.    without having to separate encoded-words where spaces occur in the
  382.    unencoded text.)
  383.  
  384.    In the event other encodings are defined in the future, and the mail
  385.    reader does not support the encoding used, it may either (a) display
  386.    the encoded-word as ordinary text, or (b) substitute an appropriate
  387.  
  388.  
  389.  
  390. Moore                                                           [Page 7]
  391. =0C
  392. RFC 1522                     MIME Part Two                September 1993
  393.  
  394.  
  395.    message indicating that the text could not be decoded.
  396.  
  397.    If the mail reader does not support the character set used, it may
  398.    (a) display the encoded-word as ordinary text (i.e., as it appears in
  399.    the header), (b) make a "best effort" to display using such
  400.    characters as are available, or (c) substitute an appropriate message
  401.    indicating that the decoded text could not be displayed.
  402.  
  403.    If the character set being used employs code-switching techniques,
  404.    display of the encoded text implicitly begins in "ASCII mode".  In
  405.    addition, the mail reader must ensure that the output device is once
  406.    again in "ASCII mode" after the encoded-word is displayed.
  407.  
  408. 6.3. Mail reader handling of incorrectly formed encoded-words
  409.  
  410.    It is possible that an encoded-word that is legal according to the
  411.    syntax defined in section 2, is incorrectly formed according to the
  412.    rules for the encoding being used.   For example:
  413.  
  414.    (1) An encoded-word which contains characters which are not legal for
  415.        a particular encoding (for example, a '-' in the "B" encoding),
  416.        is incorrectly formed.
  417.  
  418.    (2) Any encoded-word which encodes a non-integral number of
  419.        characters or octets is incorrectly formed.
  420.  
  421.    A mail reader need not attempt to display the text associated with an
  422.    encoded-word that is incorrectly formed.  However, a mail reader MUST
  423.    NOT prevent the display or handling of a message because an encoded-
  424.    word is incorrectly formed.
  425.  
  426. 7. Conformance
  427.  
  428.    A mail composing program claiming compliance with this specification
  429.    MUST ensure that any string of non-white-space printable ASCII
  430.    characters within a "*text" or "*ctext" that begins with "=3D?" and
  431.    ends with "?=3D" be a valid encoded-word.  ("begins" means: at the
  432.    start of the field-body or immediately following linear-white-space;
  433.    "ends" means: at the end of the field-body or immediately preceding
  434.    linear-white-space.) In addition, any "word" within a "phrase" that
  435.    begins with "=3D?" and ends with "?=3D" must be a valid encoded-word.
  436.  
  437.    A mail reading program claiming compliance with this specification
  438.    must be able to distinguish encoded-words from "text", "ctext", or
  439.    "word"s, according to the rules in section 6, anytime they appear in
  440.    appropriate places in message headers.  It must support both the "B"
  441.    and "Q" encodings for any character set which it supports.  The
  442.    program must be able to display the unencoded text if the character
  443.  
  444.  
  445.  
  446. Moore                                                           [Page 8]
  447. =0C
  448. RFC 1522                     MIME Part Two                September 1993
  449.  
  450.  
  451.    set is "US-ASCII".  For the ISO-8859-* character sets, the mail
  452.    reading program must at least be able to display the characters which
  453.    are also in the ASCII set.
  454.  
  455. 8. Examples
  456.  
  457.       From: =3D?US-ASCII?Q?Keith_Moore?=3D <moore@cs.utk.edu>
  458.       To: =3D?ISO-8859-1?Q?Keld_J=3DF8rn_Simonsen?=3D <keld@dkuug.dk>
  459.       CC: =3D?ISO-8859-1?Q?Andr=3DE9_?=3D Pirard <PIRARD@vm1.ulg.ac.be>
  460.       Subject: =3D?ISO-8859-1?B?SWYgeW91IGNhbiByZWFkIHRoaXMgeW8=3D?=3D
  461.        =3D?ISO-8859-2?B?dSB1bmRlcnN0YW5kIHRoZSBleGFtcGxlLg=3D=3D?=3D
  462.  
  463.       From: =3D?ISO-8859-1?Q?Olle_J=3DE4rnefors?=3D <ojarnef@admin.kth.se>
  464.       To: ietf-822@dimacs.rutgers.edu, ojarnef@admin.kth.se
  465.       Subject: Time for ISO 10646?
  466.  
  467.       To: Dave Crocker <dcrocker@mordor.stanford.edu>
  468.       Cc: ietf-822@dimacs.rutgers.edu, paf@comsol.se
  469.       From: =3D?ISO-8859-1?Q?Patrik_F=3DE4ltstr=3DF6m?=3D <paf@nada.kth.se>=
  470.  
  471.       Subject: Re: RFC-HDR care and feeding
  472.  
  473.       From: Nathaniel Borenstein <nsb@thumper.bellcore.com>
  474.             (=3D?iso-8859-8?b?7eXs+SDv4SDp7Oj08A=3D=3D?=3D)
  475.       To: Greg Vaudreuil <gvaudre@NRI.Reston.VA.US>, Ned Freed
  476.          <ned@innosoft.com>, Keith Moore <moore@cs.utk.edu>
  477.       Subject: Test of new header generator
  478.       MIME-Version: 1.0
  479.       Content-type: text/plain; charset=3DISO-8859-1
  480.  
  481. 9. References
  482.  
  483.    [1] Borenstein N., and N. Freed, "MIME (Multipurpose Internet Mail
  484.        Extensions) Part One:  Mechanisms for Specifying and Describing
  485.        the Format of Internet Message Bodies", RFC 1521, Bellcore,
  486.        Innosoft, September 1993.
  487.  
  488.    [2] Crocker, D., "Standard for the Format of ARPA Internet Text
  489.        Messages", STD 11, RFC 822, UDEL, August 1982.
  490.  
  491.    [3] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2,
  492.        RFC 1340, USC/Information Sciences Institute, July 1992.
  493.  
  494.  
  495.  
  496.  
  497.  
  498.  
  499.  
  500.  
  501.  
  502.  
  503. Moore                                                           [Page 9]
  504. =0C
  505. RFC 1522                     MIME Part Two                September 1993
  506.  
  507.  
  508. 10. Security Considerations
  509.  
  510.    Security issues are not discussed in this memo.
  511.  
  512. 11. Author's Address
  513.  
  514.    Keith Moore
  515.    University of Tennessee
  516.    107 Ayres Hall
  517.    Knoxville TN 37996-1301
  518.  
  519.    EMail: moore@cs.utk.edu
  520.  
  521.  
  522.  
  523.  
  524.  
  525.  
  526.  
  527.  
  528.  
  529.  
  530.  
  531.  
  532.  
  533.  
  534.  
  535.  
  536.  
  537.  
  538.  
  539.  
  540.  
  541.  
  542.  
  543.  
  544.  
  545.  
  546.  
  547.  
  548.  
  549.  
  550.  
  551.  
  552.  
  553.  
  554.  
  555.  
  556.  
  557.  
  558.  
  559. Moore                                                          [Page 10]
  560. =0C
  561.  
  562. --------------6FBF2D311082--
  563.  
  564.  
  565. From uu1236@kvalitetsdata.se  Fri Feb  2 09:30:01 1996
  566. Return-Path: <uu1236@kvalitetsdata.se>
  567. Received: from mail.pi.se (mail.pi.se [194.52.20.8]) by uci.agh.edu.pl (8.6.12/ALLMAN-8.6.12) with ESMTP id JAA17814 for <js@uci.agh.edu.pl>; Fri, 2 Feb 1996 09:29:46 +0100
  568. Organization: University of Mining and Metallurgy
  569. Address: Mickiewicza 30, 30-059 Krakow, POLAND
  570. Received: from pi.se (d314.sth.pi.se [194.52.20.154]) by mail.pi.se (8.6.10/8.6.9) with SMTP id JAA04385 for <js@uci.agh.edu.pl>; Fri, 2 Feb 1996 09:29:03 +0100
  571. Message-ID: <3111CC87.5B57@kvalitetsdata.se>
  572. Date: Fri, 02 Feb 1996 09:34:15 +0100
  573. From: JacekMG <uu1236@kvalitetsdata.se>
  574. X-Mailer: Mozilla 2.0b6a (Win95; I)
  575. MIME-Version: 1.0
  576. To: js@uci.agh.edu.pl
  577. Subject: RFC 1541 + Mazovia?
  578. Content-Type: multipart/mixed; boundary="------------6FBF2D311082"
  579. X-Status: 
  580. Status: RO
  581.  
  582. This is a multi-part message in MIME format.
  583.  
  584. --------------6FBF2D311082
  585. Content-Type: text/plain; charset=us-ascii
  586. Content-Transfer-Encoding: 7bit
  587.  
  588. Czesc,
  589.  
  590. Zalaczam   RFC 1541. Poniewaz jest w formacie *.txt, przesylam "as is" 
  591. (bez konwersji na plain/text).
  592. Rozumiem, ze otrzymales moja stone z polskim tekstem, plik ietfdtum.txt 
  593. i moje pytania (min. o specyfikacje Mazovii)
  594. Do 10.15 jestem tutaj. Jetesmy w kontakcie.
  595. Czesc
  596. Jacek
  597.  
  598. --------------6FBF2D311082
  599. Content-Type: text/plain; charset=iso-8859-1
  600. Content-Transfer-Encoding: quoted-printable
  601. Content-Disposition: inline; filename="rfc1522.txt"
  602.  
  603.  
  604.  
  605.  
  606.  
  607.  
  608.  
  609. Network Working Group                                           K. Moore
  610. Request for Comments: 1522                       University of Tennessee
  611. Obsoletes: 1342                                           September 1993
  612. Category: Standards Track
  613.  
  614.  
  615.          MIME (Multipurpose Internet Mail Extensions) Part Two:
  616.               Message Header Extensions for Non-ASCII Text
  617.  
  618. Status of this Memo
  619.  
  620.    This RFC specifies an Internet standards track protocol for the
  621.    Internet community, and requests discussion and suggestions for
  622.    improvements.  Please refer to the current edition of the "Internet
  623.    Official Protocol Standards" for the standardization state and status
  624.    of this protocol.  Distribution of this memo is unlimited.
  625.  
  626. Abstract
  627.  
  628.    This memo describes an extension to the message format defined in RFC
  629.    1521 [1], to allow the representation of character sets other than
  630.    ASCII in RFC 822 (STD 11) message headers.  The extensions described
  631.    were designed to be highly compatible with existing Internet mail
  632.    handling software, and to be easily implemented in mail readers that
  633.    support RFC 1521.
  634.  
  635. 1. Introduction
  636.  
  637.    RFC 1521 describes a mechanism for denoting textual body parts which
  638.    are coded in various character sets, as well as methods for encoding
  639.    such body parts as sequences of printable ASCII characters.  This
  640.    memo describes similar techniques to allow the encoding of non-ASCII
  641.    text in various portions of a RFC 822 [2] message header, in a manner
  642.    which is unlikely to confuse existing message handling software.
  643.  
  644.    Like the encoding techniques described in RFC 1521, the techniques
  645.    outlined here were designed to allow the use of non-ASCII characters
  646.    in message headers in a way which is unlikely to be disturbed by the
  647.    quirks of existing Internet mail handling programs.  In particular,
  648.    some mail relaying programs are known to (a) delete some message
  649.    header fields while retaining others, (b) rearrange the order of
  650.    addresses in To or Cc fields, (c) rearrange the (vertical) order of
  651.    header fields, and/or (d) "wrap" message headers at different places
  652.    than those in the original message.  In addition, some mail reading
  653.    programs are known to have difficulty correctly parsing message
  654.    headers which, while legal according to RFC 822, make use of
  655.    backslash-quoting to "hide" special characters such as "<", ",", or
  656.    ":", or which exploit other infrequently-used features of that
  657.  
  658.  
  659.  
  660. Moore                                                           [Page 1]
  661. =0C
  662. RFC 1522                     MIME Part Two                September 1993
  663.  
  664.  
  665.    specification.
  666.  
  667.    While it is unfortunate that these programs do not correctly
  668.    interpret RFC 822 headers, to "break" these programs would cause
  669.    severe operational problems for the Internet mail system.  The
  670.    extensions described in this memo therefore do not rely on little-
  671.    used features of RFC 822.
  672.  
  673.    Instead, certain sequences of "ordinary" printable ASCII characters
  674.    (known as "encoded-words") are reserved for use as encoded data.  The
  675.    syntax of encoded-words is such that they are unlikely to
  676.    "accidentally" appear as normal text in message headers.
  677.    Furthermore, the characters used in encoded-words are restricted to
  678.    those which do not have special meanings in the context in which the
  679.    encoded-word appears.
  680.  
  681.    Generally, an "encoded-word" is a sequence of printable ASCII
  682.    characters that begins with "=3D?", ends with "?=3D", and has two "?"s i=
  683. n
  684.    between.  It specifies a character set and an encoding method, and
  685.    also includes the original text encoded as graphic ASCII characters,
  686.    according to the rules for that encoding method.
  687.  
  688.    A mail composer that implements this specification will provide a
  689.    means of inputting non-ASCII text in header fields, but will
  690.    translate these fields (or appropriate portions of these fields) into
  691.    encoded-words before inserting them into the message header.
  692.  
  693.    A mail reader that implements this specification will recognize
  694.    encoded-words when they appear in certain portions of the message
  695.    header.  Instead of displaying the encoded-word "as is", it will
  696.    reverse the encoding and display the original text in the designated
  697.    character set.
  698.  
  699.    NOTES
  700.  
  701.       This memo relies heavily on notation and terms defined STD 11, RFC
  702.       822 and RFC 1521.  In particular, the syntax for the ABNF used in
  703.       this memo is defined in STD 11, RFC 822, as well as many of the
  704.       terms used in the grammar for the header extensions defined here.
  705.       Successful implementation of this protocol extension requires
  706.       careful attention to the details of both STD 11, RFC 822 and RFC
  707.       1521.
  708.  
  709.       When the term "ASCII" appears in this memo, it refers to the "7-
  710.       Bit American Standard Code for Information Interchange", ANSI
  711.       X3.4-1986.  The MIME charset name for this character set is "US-
  712.       ASCII".  When not specifically referring to the MIME charset name,
  713.       this document uses the term "ASCII", both for brevity and for
  714.  
  715.  
  716.  
  717. Moore                                                           [Page 2]
  718. =0C
  719. RFC 1522                     MIME Part Two                September 1993
  720.  
  721.  
  722.       consistency with STD 11, RFC 822.  However, implementors are
  723.       warned that the character set name must be spelled "US-ASCII" in
  724.       MIME message and body part headers.
  725.  
  726. 2. Syntax of encoded-words
  727.  
  728.    An "encoded-word" is defined by the following ABNF grammar.  The
  729.    notation of RFC 822 is used, with the exception that white space
  730.    characters MAY NOT appear between components of an encoded-word.
  731.  
  732.    encoded-word =3D "=3D?" charset "?" encoding "?" encoded-text "?=3D"
  733.  
  734.    charset =3D token    ; see section 3
  735.  
  736.    encoding =3D token   ; see section 4
  737.  
  738.    token =3D 1*<Any CHAR except SPACE, CTLs, and especials>
  739.  
  740.    especials =3D "(" / ")" / "<" / ">" / "@" / "," / ";" / ":" / "
  741.                <"> / "/" / "[" / "]" / "?" / "." / "=3D"
  742.  
  743.    encoded-text =3D 1*<Any printable ASCII character other
  744.                      than "?" or SPACE>
  745.                      ; (but see "Use of encoded-words in message
  746.                      ; headers", section 5)
  747.  
  748.    Both "encoding" and "charset" names are case-independent.  Thus the
  749.    charset name "ISO-8859-1" is equivalent to "iso-8859-1", and the
  750.    encoding named "Q" may be spelled either "Q" or "q".
  751.  
  752.    An encoded-word may not be more than 75 characters long, including
  753.    charset, encoding, encoded-text, and delimiters.  If it is desirable
  754.    to encode more text than will fit in an encoded-word of 75
  755.    characters, multiple encoded-words (separated by CRLF SPACE) may be
  756.    used.
  757.  
  758.    While there is no limit to the length of a multiple-line header
  759.    field, each line of a header field that contains one or more
  760.    encoded-words is limited to 76 characters.
  761.  
  762.    The length restrictions are included not only to ease
  763.    interoperability through internetwork mail gateways, but also to
  764.    impose a limit on the amount of lookahead a header parser must employ
  765.    (while looking for a final ?=3D delimiter) before it can decide whether
  766.    a token is an encoded-word or something else.
  767.  
  768.    The characters which may appear in encoded-text are further
  769.    restricted by the rules in section 5.
  770.  
  771.  
  772.  
  773. Moore                                                           [Page 3]
  774. =0C
  775. RFC 1522                     MIME Part Two                September 1993
  776.  
  777.  
  778. 3. Character sets
  779.  
  780.    The "charset" portion of an encoded-word specifies the character set
  781.    associated with the unencoded text.  A charset can be any of the
  782.    character set names allowed in an RFC 1521 "charset" parameter of a
  783.    "text/plain" body part, or any character set name registered with
  784.    IANA for use with the MIME text/plain content-type [3].  (See section
  785.    7.1.1 of RFC 1521 for a list of charsets defined in that document).
  786.  
  787.    Some character sets use code-switching techniques to switch between
  788.    "ASCII mode" and other modes.  If unencoded text in an encoded-word
  789.    contains control codes to switch out of ASCII mode, it must also
  790.    contain additional control codes such that ASCII mode is again
  791.    selected at the end of the encoded-word.  (This rule applies
  792.    separately to each encoded-word, including adjacent encoded-words
  793.    within a single header field.)
  794.  
  795.    When there is a possibility of using more than one character set to
  796.    represent the text in an encoded-word, and in the absence of private
  797.    agreements between sender and recipients of a message, it is
  798.    recommended that members of the ISO-8859-* series be used in
  799.    preference to other character sets.
  800.  
  801. 4. Encodings
  802.  
  803.    Initially, the legal values for "encoding" are "Q" and "B".  These
  804.    encodings are described below.  The "Q" encoding is recommended for
  805.    use when most of the characters to be encoded are in the ASCII
  806.    character set; otherwise, the "B" encoding should be used.
  807.    Nevertheless, a mail reader which claims to recognize encoded-words
  808.    MUST be able to accept either encoding for any character set which it
  809.    supports.
  810.  
  811.    Only a subset of the printable ASCII characters may be used in
  812.    encoded-text.  Space and tab characters are not allowed, so that the
  813.    beginning and end of an encoded-word are obvious.  The "?" character
  814.    is used within an encoded-word to separate the various portions of
  815.    the encoded-word from one another, and thus cannot appear in the
  816.    encoded-text portion.  Other characters are also illegal in certain
  817.    contexts.  For example, an encoded-word in a "phrase" preceding an
  818.    address in a From header field may not contain any of the "specials"
  819.    defined in RFC 822.  Finally, certain other characters are disallowed
  820.    in some contexts, to ensure reliability for messages that pass
  821.    through internetwork mail gateways.
  822.  
  823.    The "B" encoding automatically meets these requirements.  The "Q"
  824.    encoding allows a wide range of printable characters to be used in
  825.    non-critical locations in the message header (e.g., Subject), with
  826.  
  827.  
  828.  
  829. Moore                                                           [Page 4]
  830. =0C
  831. RFC 1522                     MIME Part Two                September 1993
  832.  
  833.  
  834.    fewer characters available for use in other locations.
  835.  
  836. 4.1. The "B" encoding
  837.  
  838.    The "B" encoding is identical to the "BASE64" encoding defined by RFC
  839.    1521.
  840.  
  841. 4.2. The "Q" encoding
  842.  
  843.    The "Q" encoding is similar to the "Quoted-Printable" content-
  844.    transfer-encoding defined in RFC 1521.  It is designed to allow text
  845.    containing mostly ASCII characters to be decipherable on an ASCII
  846.    terminal without decoding.
  847.  
  848.    (1) Any 8-bit value may be represented by a "=3D" followed by two
  849.        hexadecimal digits.  For example, if the character set in use
  850.        were ISO-8859-1, the "=3D" character would thus be encoded as
  851.        "=3D3D", and a SPACE by "=3D20".  (Upper case should be used for
  852.        hexadecimal digits "A" through "F".)
  853.  
  854.    (2) The 8-bit hexadecimal value 20 (e.g., ISO-8859-1 SPACE) may be
  855.        represented as "_" (underscore, ASCII 95.).  (This character may
  856.        not pass through some internetwork mail gateways, but its use
  857.        will greatly enhance readability of "Q" encoded data with mail
  858.        readers that do not support this encoding.)  Note that the "_"
  859.        always represents hexadecimal 20, even if the SPACE character
  860.        occupies a different code position in the character set in use.
  861.  
  862.    (3) 8-bit values which correspond to printable ASCII characters other
  863.        than "=3D", "?", "_" (underscore), and SPACE may be represented as
  864.        those characters.  (But see section 5 for restrictions.)
  865.  
  866. 5. Use of encoded-words in message headers
  867.  
  868.    An encoded-word may appear in a message header or body part header
  869.    according to the following rules:
  870.  
  871.    (1) An encoded-word may replace a "text" token (as defined by RFC
  872.        822) in any Subject or Comments header field, any extension
  873.        message header field, or any RFC 1521 body part field for which
  874.        the field body is defined as "*text".  An encoded-word may also
  875.        appear in any user-defined ("X-") message or body part header
  876.        field.
  877.  
  878.        Ordinary ASCII text and encoded-words may appear together in the
  879.        same header field.  However, an encoded-word that appears in a
  880.        header field defined as "*text" MUST be separated from any
  881.        adjacent encoded-word or "text" by linear-white-space.
  882.  
  883.  
  884.  
  885. Moore                                                           [Page 5]
  886. =0C
  887. RFC 1522                     MIME Part Two                September 1993
  888.  
  889.  
  890.    (2) An encoded-word may appear within a comment delimited by "(" and
  891.        ")", i.e., wherever a "ctext" is allowed.  More precisely, the
  892.        RFC 822 ABNF definition for "comment" is amended as follows:
  893.  
  894.        comment =3D "(" *(ctext / quoted-pair / comment / encoded-word) ")"
  895.  
  896.        A "Q"-encoded encoded-word which appears in a comment MUST NOT
  897.        contain the characters "(", ")" or " encoded-word that appears in
  898.        a "comment" MUST be separated from any adjacent encoded-word or
  899.        "ctext" by linear-white-space.
  900.  
  901.    (3) As a replacement for a "word" entity within a "phrase", for
  902.        example, one that precedes an address in a From, To, or Cc
  903.        header.  The ABNF definition for phrase from RFC 822 thus
  904.        becomes:
  905.  
  906.        phrase =3D 1*(encoded-word / word)
  907.  
  908.        In this case the set of characters that may be used in a "Q"-
  909.        encoded encoded-word is restricted to: <upper and lower case
  910.        ASCII letters, decimal digits, "!", "*", "+", "-", "/", "=3D", and
  911.        "_" (underscore, ASCII 95.)>.  An encoded-word that appears
  912.        within a "phrase" MUST be separated from any adjacent "word",
  913.        "text" or "special" by linear-white-space.
  914.  
  915.    These are the ONLY locations where an encoded-word may appear.  In
  916.    particular, an encoded-word MUST NOT appear in any portion of an
  917.    "addr-spec".  In addition, an encoded-word MUST NOT be used in a
  918.    Received header field.
  919.  
  920.    Each encoded-word MUST encode an integral number of octets.  The
  921.    encoded-text in each encoded-word must be well-formed according to
  922.    the encoding specified; the encoded-text may not be continued in the
  923.    next encoded-word.  (For example, "=3D?charset?Q?=3D?=3D =3D?charset?Q?A=
  924. B?=3D"
  925.    would be illegal, because the two hex digits "AB" must follow the "=3D"
  926.    in the same encoded-word.)
  927.  
  928.    Each encoded-word MUST represent an integral number of characters. A
  929.    multi-octet character may not be split across adjacent encoded-words.
  930.  
  931.    Only printable and white space character data should be encoded using
  932.    this scheme.  However, since these encoding schemes allow the
  933.    encoding of arbitrary octet values, mail readers that implement this
  934.    decoding should also ensure that display of the decoded data on the
  935.    recipient's terminal will not cause unwanted side-effects.
  936.  
  937.    Use of these methods to encode non-textual data (e.g., pictures or
  938.    sounds) is not defined by this memo.  Use of encoded-words to
  939.  
  940.  
  941.  
  942. Moore                                                           [Page 6]
  943. =0C
  944. RFC 1522                     MIME Part Two                September 1993
  945.  
  946.  
  947.    represent strings of purely ASCII characters is allowed, but
  948.    discouraged.  In rare cases it may be necessary to encode ordinary
  949.    text that looks like an encoded-word.
  950.  
  951. 6. Support of encoded-words by mail readers
  952.  
  953. 6.1. Recognition of encoded-words in message headers
  954.  
  955.    A mail reader must parse the message and body part headers according
  956.    to the rules in RFC 822 to correctly recognize encoded-words.
  957.  
  958.    Encoded-words are to be recognized as follows:
  959.  
  960.    (1) Any message or body part header field defined as "*text", or any
  961.        user-defined header field, should be parsed as follows: Beginning
  962.        at the start of the field-body and immediately following each
  963.        occurrence of linear-white-space, each sequence of up to 75
  964.        printable characters (not containing any linear-white-space)
  965.        should be examined to see if it is an encoded-word according to
  966.        the syntax rules in section 2.  Any other sequence of printable
  967.        characters should be treated as ordinary ASCII text.
  968.  
  969.    (2) Any header field not defined as "*text" should be parsed
  970.        according to the syntax rules for that header field.  However,
  971.        any "word" that appears within a "phrase" should be treated as an
  972.        encoded-word if it meets the syntax rules in section 2.
  973.        Otherwise it should be treated as an ordinary "word".
  974.  
  975.    (3) Within a "comment", any sequence of up to 75 printable characters
  976.        (not containing linear-white-space), that meets the syntax rules
  977.        in section 2, should be treated as an encoded-word.  Otherwise it
  978.        should be treated as normal comment text.
  979.  
  980. 6.2. Display of encoded-words
  981.  
  982.    Any encoded-words so recognized are decoded, and if possible, the
  983.    resulting unencoded text is displayed in the original character set.
  984.  
  985.    When displaying a particular header field that contains multiple
  986.    encoded-words, any linear-white-space that separates a pair of
  987.    adjacent encoded-words is ignored.  (This is to allow the use of
  988.    multiple encoded-words to represent long strings of unencoded text,
  989.    without having to separate encoded-words where spaces occur in the
  990.    unencoded text.)
  991.  
  992.    In the event other encodings are defined in the future, and the mail
  993.    reader does not support the encoding used, it may either (a) display
  994.    the encoded-word as ordinary text, or (b) substitute an appropriate
  995.  
  996.  
  997.  
  998. Moore                                                           [Page 7]
  999. =0C
  1000. RFC 1522                     MIME Part Two                September 1993
  1001.  
  1002.  
  1003.    message indicating that the text could not be decoded.
  1004.  
  1005.    If the mail reader does not support the character set used, it may
  1006.    (a) display the encoded-word as ordinary text (i.e., as it appears in
  1007.    the header), (b) make a "best effort" to display using such
  1008.    characters as are available, or (c) substitute an appropriate message
  1009.    indicating that the decoded text could not be displayed.
  1010.  
  1011.    If the character set being used employs code-switching techniques,
  1012.    display of the encoded text implicitly begins in "ASCII mode".  In
  1013.    addition, the mail reader must ensure that the output device is once
  1014.    again in "ASCII mode" after the encoded-word is displayed.
  1015.  
  1016. 6.3. Mail reader handling of incorrectly formed encoded-words
  1017.  
  1018.    It is possible that an encoded-word that is legal according to the
  1019.    syntax defined in section 2, is incorrectly formed according to the
  1020.    rules for the encoding being used.   For example:
  1021.  
  1022.    (1) An encoded-word which contains characters which are not legal for
  1023.        a particular encoding (for example, a '-' in the "B" encoding),
  1024.        is incorrectly formed.
  1025.  
  1026.    (2) Any encoded-word which encodes a non-integral number of
  1027.        characters or octets is incorrectly formed.
  1028.  
  1029.    A mail reader need not attempt to display the text associated with an
  1030.    encoded-word that is incorrectly formed.  However, a mail reader MUST
  1031.    NOT prevent the display or handling of a message because an encoded-
  1032.    word is incorrectly formed.
  1033.  
  1034. 7. Conformance
  1035.  
  1036.    A mail composing program claiming compliance with this specification
  1037.    MUST ensure that any string of non-white-space printable ASCII
  1038.    characters within a "*text" or "*ctext" that begins with "=3D?" and
  1039.    ends with "?=3D" be a valid encoded-word.  ("begins" means: at the
  1040.    start of the field-body or immediately following linear-white-space;
  1041.    "ends" means: at the end of the field-body or immediately preceding
  1042.    linear-white-space.) In addition, any "word" within a "phrase" that
  1043.    begins with "=3D?" and ends with "?=3D" must be a valid encoded-word.
  1044.  
  1045.    A mail reading program claiming compliance with this specification
  1046.    must be able to distinguish encoded-words from "text", "ctext", or
  1047.    "word"s, according to the rules in section 6, anytime they appear in
  1048.    appropriate places in message headers.  It must support both the "B"
  1049.    and "Q" encodings for any character set which it supports.  The
  1050.    program must be able to display the unencoded text if the character
  1051.  
  1052.  
  1053.  
  1054. Moore                                                           [Page 8]
  1055. =0C
  1056. RFC 1522                     MIME Part Two                September 1993
  1057.  
  1058.  
  1059.    set is "US-ASCII".  For the ISO-8859-* character sets, the mail
  1060.    reading program must at least be able to display the characters which
  1061.    are also in the ASCII set.
  1062.  
  1063. 8. Examples
  1064.  
  1065.       From: =3D?US-ASCII?Q?Keith_Moore?=3D <moore@cs.utk.edu>
  1066.       To: =3D?ISO-8859-1?Q?Keld_J=3DF8rn_Simonsen?=3D <keld@dkuug.dk>
  1067.       CC: =3D?ISO-8859-1?Q?Andr=3DE9_?=3D Pirard <PIRARD@vm1.ulg.ac.be>
  1068.       Subject: =3D?ISO-8859-1?B?SWYgeW91IGNhbiByZWFkIHRoaXMgeW8=3D?=3D
  1069.        =3D?ISO-8859-2?B?dSB1bmRlcnN0YW5kIHRoZSBleGFtcGxlLg=3D=3D?=3D
  1070.  
  1071.       From: =3D?ISO-8859-1?Q?Olle_J=3DE4rnefors?=3D <ojarnef@admin.kth.se>
  1072.       To: ietf-822@dimacs.rutgers.edu, ojarnef@admin.kth.se
  1073.       Subject: Time for ISO 10646?
  1074.  
  1075.       To: Dave Crocker <dcrocker@mordor.stanford.edu>
  1076.       Cc: ietf-822@dimacs.rutgers.edu, paf@comsol.se
  1077.       From: =3D?ISO-8859-1?Q?Patrik_F=3DE4ltstr=3DF6m?=3D <paf@nada.kth.se>=
  1078.  
  1079.       Subject: Re: RFC-HDR care and feeding
  1080.  
  1081.       From: Nathaniel Borenstein <nsb@thumper.bellcore.com>
  1082.             (=3D?iso-8859-8?b?7eXs+SDv4SDp7Oj08A=3D=3D?=3D)
  1083.       To: Greg Vaudreuil <gvaudre@NRI.Reston.VA.US>, Ned Freed
  1084.          <ned@innosoft.com>, Keith Moore <moore@cs.utk.edu>
  1085.       Subject: Test of new header generator
  1086.       MIME-Version: 1.0
  1087.       Content-type: text/plain; charset=3DISO-8859-1
  1088.  
  1089. 9. References
  1090.  
  1091.    [1] Borenstein N., and N. Freed, "MIME (Multipurpose Internet Mail
  1092.        Extensions) Part One:  Mechanisms for Specifying and Describing
  1093.        the Format of Internet Message Bodies", RFC 1521, Bellcore,
  1094.        Innosoft, September 1993.
  1095.  
  1096.    [2] Crocker, D., "Standard for the Format of ARPA Internet Text
  1097.        Messages", STD 11, RFC 822, UDEL, August 1982.
  1098.  
  1099.    [3] Reynolds, J., and J. Postel, "Assigned Numbers", STD 2,
  1100.        RFC 1340, USC/Information Sciences Institute, July 1992.
  1101.  
  1102.  
  1103.  
  1104.  
  1105.  
  1106.  
  1107.  
  1108.  
  1109.  
  1110.  
  1111. Moore                                                           [Page 9]
  1112. =0C
  1113. RFC 1522                     MIME Part Two                September 1993
  1114.  
  1115.  
  1116. 10. Security Considerations
  1117.  
  1118.    Security issues are not discussed in this memo.
  1119.  
  1120. 11. Author's Address
  1121.  
  1122.    Keith Moore
  1123.    University of Tennessee
  1124.    107 Ayres Hall
  1125.    Knoxville TN 37996-1301
  1126.  
  1127.    EMail: moore@cs.utk.edu
  1128.  
  1129.  
  1130.  
  1131.  
  1132.  
  1133.  
  1134.  
  1135.  
  1136.  
  1137.  
  1138.  
  1139.  
  1140.  
  1141.  
  1142.  
  1143.  
  1144.  
  1145.  
  1146.  
  1147.  
  1148.  
  1149.  
  1150.  
  1151.  
  1152.  
  1153.  
  1154.  
  1155.  
  1156.  
  1157.  
  1158.  
  1159.  
  1160.  
  1161.  
  1162.  
  1163.  
  1164.  
  1165.  
  1166.  
  1167. Moore                                                          [Page 10]
  1168.  
  1169.  
  1170.