home *** CD-ROM | disk | FTP | other *** search
/ Unix System Administration Handbook 1997 October / usah_oct97.iso / rfc / 1100s / rfc1154.txt < prev    next >
Text File  |  1990-04-15  |  12KB  |  395 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                                        D. Robinson
  8. Request for Comments: 1154                                    R. Ullmann
  9.                                                     Prime Computer, Inc.
  10.                                                               April 1990
  11.  
  12.  
  13.               Encoding Header Field for Internet Messages
  14.  
  15. 1. Status of the Memo
  16.  
  17.    This RFC proposes an elective experimental Encoding header field to
  18.    permit the mailing of multi-part, multi-structured messages.
  19.  
  20.    The use of Encoding updates RFC 1049 (Content-Type), and is a
  21.    suggested update to RFCs 1113, 1114, and 1115 (Privacy Enhancement)
  22.    [4,7,8].
  23.  
  24.    Distribution of this memo is unlimited.
  25.  
  26. 2. Introduction
  27.  
  28.    RFC 822 [2] defines an electronic mail message to consist of two
  29.    parts, the message header and the message body, separated by an
  30.    apparently blank line.
  31.  
  32.    The Encoding header field permits the message body itself to be
  33.    further broken up into parts, each part also separated from the next
  34.    by an apparently blank line.
  35.  
  36.    Thus, conceptually, a message has a header part, followed by one or
  37.    more body parts, all separated by blank lines.
  38.  
  39.    Each body part has an encoding type.  The default (no Encoding field
  40.    in the header) is a message body of one part of type "text".
  41.  
  42.    3. The Encoding Field
  43.  
  44.    The Encoding field consists of one or more subfields, separated by
  45.    commas.  Each subfield corresponds to a part of the message, in the
  46.    order of that part's appearance.  A subfield consists of a line
  47.    count, a keyword defining the encoding, and optional information
  48.    relevant only to the specific encoding.  The line count is optional
  49.    in the last subfield.
  50.  
  51. 3.1. Format of the Encoding Field
  52.  
  53.    The format of the Encoding field is:
  54.  
  55.  
  56.  
  57.  
  58. Robinson & Ullmann                                              [Page 1]
  59.  
  60. RFC 1154      Encoding Header Field for Internet Messages     April 1990
  61.  
  62.  
  63.      [<count> <keyword> [<options>], ]* [<count>] <keyword> [<options>]
  64.  
  65.      where:
  66.  
  67.         <count>   := a decimal integer
  68.         <keyword> := a single alphanumeric token starting with an alpha
  69.         <options> := keyword-dependent options
  70.  
  71. 3.2. <count>
  72.  
  73.    The line count is a decimal number specifying the number of text
  74.    lines in the part.  Parts are separated by a blank line, which is not
  75.    included in the count of either the proceeding or following part.
  76.    Because a count always begins with a digit and a keywords always
  77.    begins with an letter, it is always possible to determine if the
  78.    count is present.  (The count is first because it is the only
  79.    information of interest when skipping over the part.)
  80.  
  81.    The count is not required on the last or only part.
  82.  
  83. 3.3. <keyword>
  84.  
  85.    The keyword defines the encoding type.  The keyword is a common
  86.    single word name for the encoding type.  The keywords are not case-
  87.    sensitive.
  88.  
  89.    The list of standard keywords is intended to be the same as the list
  90.    used for the Content-Type: header described in [6].  This RFC
  91.    proposes additions to the list.  Implementations can then treat
  92.    "Content-Type" as an alias of "Encoding", which will always have only
  93.    one body part.
  94.  
  95. 3.4. <options>
  96.  
  97.    The optional information is used to specify additional keyword-
  98.    specific information needed for interpreting the contents of the
  99.    encoded part.  It is any sequence of tokens not containing a comma.
  100.  
  101. 3.5. Encoding Version Numbers
  102.  
  103.    In general, version numbers for encodings, when not actually
  104.    available within the contents of the encoded information, will be
  105.    handled as options.
  106.  
  107. 3.6. Comments
  108.  
  109.    Comments enclosed in parentheses may, of course, be inserted anywhere
  110.    in the Encoding field.  Mail reading systems may pass the comments to
  111.  
  112.  
  113.  
  114. Robinson & Ullmann                                              [Page 2]
  115.  
  116. RFC 1154      Encoding Header Field for Internet Messages     April 1990
  117.  
  118.  
  119.    their clients.  Comments must not be used by mail reading systems for
  120.    content interpretation; that is the function of options.
  121.  
  122. 4. Encodings
  123.  
  124.    This section describes some of the defined encodings used.
  125.  
  126.    As with the other keyword-defined parts of the header format
  127.    standard, extensions in the form of new keywords are expected and
  128.    welcomed.  Several basic principles should be followed in adding
  129.    encodings:
  130.  
  131.       - The keyword should be the most common single word name for the
  132.       encoding, including acronyms if appropriate.  The intent is that
  133.       different implementors will be likely to choose the same name for
  134.       the same encoding.
  135.  
  136.       - Keywords not be too general: "binary" would have been a bad
  137.       choice for the "hex" encoding.
  138.  
  139.       - The encoding should be as free from unnecessary idiosyncracies
  140.       as possible, except when conforming to an existing standard, in
  141.       which case there is nothing that can be done.
  142.  
  143.       - The encoding should, if possible, use only the 7 bit ASCII
  144.       printing characters if it is a complete transformation of a source
  145.       document (e.g., "hex" or "uuencode").  If it is essentially a text
  146.       format, the full range may be used.  If there is an external
  147.       standard, the character set may already be defined.
  148.  
  149.    Keywords beginning with "X-" are permanently reserved to
  150.    implementation-specific use.  No standard registered encoding keyword
  151.    will ever begin with "X-".
  152.  
  153. 4.1. Text
  154.  
  155.    This indicates that the message is in no particular encoded format,
  156.    but is to be presented to the user as is.
  157.  
  158.    The full range of the ASCII character set is used.  The message is
  159.    expected to consist of lines of reasonable length (less than 1000
  160.    characters).
  161.  
  162.    On some transport services, only the 7 bit subset of ASCII can be
  163.    used.  Where full 8 bit transparency is available, the text is
  164.    assumed to be ISO 8859-1 [3] (ASCII-8).
  165.  
  166.  
  167.  
  168.  
  169.  
  170. Robinson & Ullmann                                              [Page 3]
  171.  
  172. RFC 1154      Encoding Header Field for Internet Messages     April 1990
  173.  
  174.  
  175. 4.2. Message
  176.  
  177.    This encoding indicates that the body part is itself in the format of
  178.    an Internet message, with its own header part and body part(s).  A
  179.    "message" body part's message header may be a full internet message
  180.    header or it may consist only of an Encoding field.
  181.  
  182.    Using the message encoding on returned mail makes it practical for a
  183.    mail reading system to implement a reliable resending function, if
  184.    the mailer generates it when returning contents.  It is also useful
  185.    in a "copy append" MUA operation.
  186.  
  187.    Message encoding is also used when mapping to X.400 to handle
  188.    recursively included X.400 P2 messages.
  189.  
  190. 4.3. Hex
  191.  
  192.    The encoding indicates that the body part contains binary data,
  193.    encoded as 2 hexadecimal digits per byte, highest significant nibble
  194.    first.
  195.  
  196.    Lines consist of an even number of hexadecimal digits.  Blank lines
  197.    are not permitted.  The decode process must accept lines with between
  198.    2 and 1000 characters, inclusive.
  199.  
  200. 4.4. EVFU
  201.  
  202.    EVFU (Electronic Vertical Format Unit) specifies that each line
  203.    begins with a one-character "channel selector".  The original purpose
  204.    was to select a channel on a paper tape loop controlling the printer.
  205.  
  206.    This encoding is sometimes called "FORTRAN" format. It is the default
  207.    output format of FORTRAN programs on a number of computer systems.
  208.  
  209.    The legal characters are '0' to '9', '+', '-', and space.  These
  210.    correspond to the 12 rows (and absence of a punch) on a printer
  211.    control tape (used when the control unit was electromechanical).
  212.  
  213.    The channels that have generally agreed definitions are:
  214.  
  215.            1     advances to the first print line on the next page
  216.            0     skip a line, i.e., double-space
  217.            +     over-print the preceeding line
  218.            -     skip 2 lines, i.e., triple-space
  219.         (space)  print on the next line, single-space
  220.  
  221.  
  222.  
  223.  
  224.  
  225.  
  226. Robinson & Ullmann                                              [Page 4]
  227.  
  228. RFC 1154      Encoding Header Field for Internet Messages     April 1990
  229.  
  230.  
  231. 4.5. EDI
  232.  
  233.    The EDI (Electronic Document Interchange) keyword indicates that the
  234.    message or part is a business document, formatted according to ANSI
  235.    X12 or related standards.
  236.  
  237.    The first word after the EDI keyword indicates the particular
  238.    interchange standard.
  239.  
  240.    A message containing a note and 2 X12 purchase orders might have an
  241.    encoding of:
  242.  
  243.        Encoding: 17 TEXT, 146 EDI X12, 69 EDI X12
  244.  
  245. 4.6. X.400
  246.  
  247.    The Encoding header field provides a mechanism for mapping multi-part
  248.    messages between CCITT X.400 [1] and RFC 822.
  249.  
  250.    The X.400 keyword specifies a section that is converted from an X.400
  251.    body part type not known to the gateway, or not corresponding to a
  252.    useful internet encoding.
  253.  
  254.    If the message transits another gate, or if the receiving user has
  255.    the appropriate software, it can be decoded and used.
  256.  
  257.    The X.400 keyword is followed by a second token indicating the method
  258.    used.  The simplest form is "X.400 HEX", with the complete X.409
  259.    encoding of the body part in hexadecimal.  More compact is "X.400
  260.    3/4", using the 3-byte to 4-character encoding as specified in RFC
  261.    1113, section 4.3.2.4.
  262.  
  263. 4.7. uuencode
  264.  
  265.    The uuencode keyword specifies a section consisting of the output of
  266.    the uuencode program supplied as part of uucp.
  267.  
  268. 4.8. encrypted
  269.  
  270.    The encrypted keyword indicates that the section is encrypted with
  271.    the methods in RFC 1115 [8].  This replaces the possible use of RFC
  272.    934 [5] encapsulation.
  273.  
  274. References
  275.  
  276.   [1]  International Telegraph and Telephone Consultative Committee,
  277.        "Data Communication Networks: Message Handling Systems", In CCITT
  278.        Recommendations X.400 to X.430, VIIIth Plenary Assembly, Malaga-
  279.  
  280.  
  281.  
  282. Robinson & Ullmann                                              [Page 5]
  283.  
  284. RFC 1154      Encoding Header Field for Internet Messages     April 1990
  285.  
  286.  
  287.        Torremolinos, 1984, Fascicle VIII.7 ("Red Book").
  288.  
  289.   [2]  Crocker, D., "Standard for the Format of ARPA Internet Text
  290.        Messages", RFC 822, University of Delaware, August 1982.
  291.  
  292.   [3]  International Organization for Standardization, "Information
  293.        processing - 8-bit single-byte coded graphic character sets -
  294.        Part 1: Latin alphabet No. 1", ISO 8859-1, ISO, 1987.
  295.  
  296.   [4]  Linn, J., "Privacy Enhancement for Internet Electronic Mail: Part
  297.        I -- Message Encipherment and Authentication Procedures", RFC
  298.        1113, IAB Privacy Task Force, August 1989.
  299.  
  300.   [5]  Rose, M., and E. Stefferud, "Proposed Standard for Message
  301.        Encapsulation", RFC 943, University of Delaware and NMA, January
  302.        1985.
  303.  
  304.   [6]  Sirbu, M., "Content-type Header Field for Internet Messages", RFC
  305.        1049, CMU, March 1988.
  306.  
  307.   [7]  Kent, S., and J. Linn, "Privacy Enhancement for Internet
  308.        Electronic Mail: Part II -- Certificate-Based Key Management",
  309.        RFC 1114, IAB Privacy Task Force, August 1989.
  310.  
  311.   [8]  Linn, J., "Privacy Enhancement for Internet Electronic Mail: Part
  312.        III -- Algorithms, Modes, and Identifiers", RFC 1115, IAB Privacy
  313.        Task Force, August 1989.
  314.  
  315. Security Considerations
  316.  
  317.    Security issues are not addressed in this memo.
  318.  
  319. Authors' Addresses
  320.  
  321.    David Robinson 10-30
  322.    Prime Computer, Inc.
  323.    500 Old Connecticut Path
  324.    Framingham, MA 01701
  325.  
  326.    Phone: +1 508 879 2960 x1774
  327.  
  328.    Email: DRB@Relay.Prime.COM
  329.  
  330.  
  331.    Robert Ullmann 10-30
  332.    Prime Computer, Inc.
  333.    500 Old Connecticut Path
  334.    Framingham, MA 01701
  335.  
  336.  
  337.  
  338. Robinson & Ullmann                                              [Page 6]
  339.  
  340. RFC 1154      Encoding Header Field for Internet Messages     April 1990
  341.  
  342.  
  343.    Phone: +1 508 879 2960 x1736
  344.  
  345.    Email: Ariel@Relay.Prime.COM
  346.  
  347.  
  348.  
  349.  
  350.  
  351.  
  352.  
  353.  
  354.  
  355.  
  356.  
  357.  
  358.  
  359.  
  360.  
  361.  
  362.  
  363.  
  364.  
  365.  
  366.  
  367.  
  368.  
  369.  
  370.  
  371.  
  372.  
  373.  
  374.  
  375.  
  376.  
  377.  
  378.  
  379.  
  380.  
  381.  
  382.  
  383.  
  384.  
  385.  
  386.  
  387.  
  388.  
  389.  
  390.  
  391.  
  392.  
  393.  
  394. Robinson & Ullmann                                              [Page 7]
  395.