rfc1505.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

Network Working Group                                        A. Costanzo
Request for Comments: 1505                                AKC Consulting
Obsoletes: 1154                                              D. Robinson
                                              Computervision Corporation
                                                              R. Ullmann
                                                             August 1993


              Encoding Header Field for Internet Messages

Status of this Memo

   This memo defines an Experimental Protocol for the Internet
   community.  It does not specify an Internet standard.  Discussion and
   suggestions for improvement are requested.  Please refer to the
   current edition of the "IAB Official Protocol Standards" for the
   standardization state and status of this protocol.  Distribution of
   this memo is unlimited.

IESG Note

   Note that a standards-track technology already exists in this area
   [11].

Abstract

   This document expands upon the elective experimental Encoding header
   field which permits the mailing of multi-part, multi-structured
   messages.  It replaces RFC 1154 [1].

Table of Contents

          1.      Introduction . . . . . . . . . . . . . . . . . . . . 3
          2.      The Encoding Field . . . . . . . . . . . . . . . . . 3
          2.1       Format of the Encoding Field . . . . . . . . . . . 3
          2.2       <count>  . . . . . . . . . . . . . . . . . . . . . 4
          2.3       <keyword>  . . . . . . . . . . . . . . . . . . . . 4
          2.3.1       Nested Keywords  . . . . . . . . . . . . . . . . 4
          2.4       Comments . . . . . . . . . . . . . . . . . . . . . 4
          3.      Encodings  . . . . . . . . . . . . . . . . . . . . . 5
          3.1       Text . . . . . . . . . . . . . . . . . . . . . . . 5
          3.2       Message  . . . . . . . . . . . . . . . . . . . . . 6
          3.3       Hex  . . . . . . . . . . . . . . . . . . . . . . . 6
          3.4       EVFU . . . . . . . . . . . . . . . . . . . . . . . 6
          3.5       EDI-X12 and EDIFACT  . . . . . . . . . . . . . . . 7
          3.6       FS   . . . . . . . . . . . . . . . . . . . . . . . 7
          3.7       LZJU90 . . . . . . . . . . . . . . . . . . . . . . 7
          3.8       LZW  . . . . . . . . . . . . . . . . . . . . . . . 7



Costanzo, Robinson & Ullmann                                    [Page 1]

RFC 1505                 Encoding Header Field               August 1993


          3.9       UUENCODE . . . . . . . . . . . . . . . . . . . . . 7
          3.10      PEM and PEM-Clear  . . . . . . . . . . . . . . . . 8
          3.11      PGP  . . . . . . . . . . . . . . . . . . . . . . . 8
          3.12      Signature  . . . . . . . . . . . . . . . . . . .  10
          3.13      TAR  . . . . . . . . . . . . . . . . . . . . . .  10
          3.14      PostScript . . . . . . . . . . . . . . . . . . .  10
          3.15      SHAR . . . . . . . . . . . . . . . . . . . . . .  10
          3.16      Uniform Resource Locator . . . . . . . . . . . .  10
          3.17      Registering New Keywords . . . . . . . . . . . .  11
          4.      FS (File System) Object Encoding . . . . . . . . .  11
          4.1       Sections . . . . . . . . . . . . . . . . . . . .  12
          4.1.1       Directory  . . . . . . . . . . . . . . . . . .  12
          4.1.2       Entry  . . . . . . . . . . . . . . . . . . . .  13
          4.1.3       File . . . . . . . . . . . . . . . . . . . . .  13
          4.1.4       Segment  . . . . . . . . . . . . . . . . . . .  13
          4.1.5       Data . . . . . . . . . . . . . . . . . . . . .  14
          4.2       Attributes . . . . . . . . . . . . . . . . . . .  14
          4.2.1       Display  . . . . . . . . . . . . . . . . . . .  14
          4.2.2       Comment  . . . . . . . . . . . . . . . . . . .  15
          4.2.3       Type . . . . . . . . . . . . . . . . . . . . .  15
          4.2.4       Created  . . . . . . . . . . . . . . . . . . .  15
          4.2.5       Modified . . . . . . . . . . . . . . . . . . .  15
          4.2.6       Accessed . . . . . . . . . . . . . . . . . . .  15
          4.2.7       Owner  . . . . . . . . . . . . . . . . . . . .  15
          4.2.8       Group  . . . . . . . . . . . . . . . . . . . .  16
          4.2.9       ACL  . . . . . . . . . . . . . . . . . . . . .  16
          4.2.10      Password . . . . . . . . . . . . . . . . . . .  16
          4.2.11      Block  . . . . . . . . . . . . . . . . . . . .  16
          4.2.12      Record . . . . . . . . . . . . . . . . . . . .  17
          4.2.13      Application  . . . . . . . . . . . . . . . . .  17
          4.3       Date Field . . . . . . . . . . . . . . . . . . .  17
          4.3.1       Syntax . . . . . . . . . . . . . . . . . . . .  17
          4.3.2       Semantics  . . . . . . . . . . . . . . . . . .  17
          5.      LZJU90: Compressed Encoding  . . . . . . . . . . .  18
          5.1       Overview . . . . . . . . . . . . . . . . . . . .  18
          5.2       Specification of the LZJU90 compression  . . . .  19
          5.3       The Decoder  . . . . . . . . . . . . . . . . . .  21
          5.3.1       An example of an Encoder . . . . . . . . . . .  27
          5.3.2       Example LZJU90 Compressed Object . . . . . . .  33
          6.      Alphabetical Listing of Defined Encodings  . . . .  34
          7.      Security Considerations  . . . . . . . . . . . . .  34
          8.      References . . . . . . . . . . . . . . . . . . . .  34
          9.      Acknowledgements . . . . . . . . . . . . . . . . .  35
          10.     Authors' Addresses . . . . . . . . . . . . . . . .  36







Costanzo, Robinson & Ullmann                                    [Page 2]

RFC 1505                 Encoding Header Field               August 1993


1.  Introduction

   STD 11, RFC 822 [2] defines an electronic mail message to consist of
   two parts, the message header and the message body, separated by a
   blank line.

   The Encoding header field permits the message body itself to be
   further broken up into parts, each part also separated from the next
   by a blank line.  Thus, conceptually, a message has a header part,
   followed by one or more body parts, all separated by apparently blank
   lines.  Each body part has an encoding type.  The default (no
   Encoding field in the header) is a one part message body of type
   "Text".

   The purpose of Encoding is to be descriptive of the content of a mail
   message without placing constraints on the content or requiring
   additional structure to appear in the body of the message that will
   interfere with other processing.

   A similar message format is used in the network news facility, and
   posted articles are often transferred by gateways between news and
   mail.  The Encoding field is perhaps even more useful in news, where
   articles often are uuencoded or shar'd, and have a number of
   different nested encodings of graphics images and so forth.  In news
   in particular, the Encoding header keeps the structural information
   within the (usually concealed) article header, without affecting the
   visual presentation by simple news-reading software.

2.  The Encoding Field

   The Encoding field consists of one or more subfields, separated by
   commas.  Each subfield corresponds to a part of the message, in the
   order of that part's appearance.  A subfield consists of a line count
   and a keyword or a series of nested keywords defining the encoding.
   The line count is optional in the last subfield.

2.1  Format of the Encoding Field

   The format of the Encoding field is:

        [  <count> <keyword> [ <keyword> ]* ,  ]*
                [ <count> ] <keyword> [ <keyword> ]*

        where:

        <count>    := a decimal integer
        <keyword>  := a single alphanumeric token starting with an alpha




Costanzo, Robinson & Ullmann                                    [Page 3]

RFC 1505                 Encoding Header Field               August 1993


2.2  <count>

   The line count is a decimal number specifying the number of text
   lines in the part.  Parts are separated by a blank line, which is not
   included in the count of either the preceding or following part.
   Blank lines consist only of CR/LF.  Count may be zero, it must be
   non-negative.

   It is always possible to determine if the count is present because a
   count always begins with a digit and a keyword always begins with a
   letter.

   The count is not required on the last or only part.  A multi-part
   message that consists of only one part is thus identical to a
   single-part message.

2.3  <keyword>

   Keyword defines the encoding type.  The keyword is a common single-
   word name for the encoding type and is not case-sensitive.

             Encoding: 107 Text

2.3.1  Nested Keywords

   Nested keywords are a series of keywords defining a multi-encoded
   message part.  The encoding keywords may either be an actual series
   of encoding steps the encoder used to generate the message part or
   may merely be used to more precisely identify the type of encoding
   (as in the use of the keyword "Signature").

   Nested keywords are parsed and generated from left to right.  The
   order is significant.  A decoding application would process the list
   from left to right, whereas, an encoder would process the Internet
   message and generate the nested keywords in the reverse order of the
   actual encoding process.

        Encoding: 458 uuencode LZW tar (Unix binary object)

2.4  Comments

   Comments enclosed in parentheses may be inserted anywhere in the
   encoding field.  Mail reading systems may pass the comments to their
   clients.  Comments must not be used by mail reading systems for
   content interpretation.  Other parameters defining the type of
   encoding must be contained within the body portion of the Internet
   message or be implied by a keyword in the encoding field.




Costanzo, Robinson & Ullmann                                    [Page 4]

RFC 1505                 Encoding Header Field               August 1993


3.  Encodings

   This section describes some of the defined encodings used.  An
   alphabetical listing is provided in Section 6.

   As with the other keyword-defined parts of the header format
   standard, new keywords are expected and welcomed.  Several basic
   principles should be followed in adding encodings.  The keyword
   should be the most common single word name for the encoding,
   including acronyms if appropriate.  The intent is that different
   implementors will be likely to choose the same name for the same
   encoding.  Keywords should not be too general:  "binary" would have
   been a bad choice for the "hex" encoding.

   The encoding should be as free from unnecessary idiosyncracies as
   possible, except when conforming to an existing standard, in which
   case there is nothing that can be done.

   The encoding should, if possible, use only the 7 bit ASCII printing
   characters if it is a complete transformation of a source document
   (e.g., "hex" or "uuencode").  If it is essentially a text format, the
   full range may be used.  If there is an external standard, the
   character set may already be defined.  Keywords beginning with "X-"
   are permanently reserved to implementation-specific use.  No standard
   registered encoding keyword will ever begin with "X-".

   New encoding keywords which are not reserved for implementation-
   specific use must be registered with the Internet Assigned Numbers
   Authority (IANA).  Refer to section 3.17 for additional information.

3.1  Text

   This indicates that the message is in no particular encoded format,
   but is to be presented to the user as-is.

   The text is ISO-10646-UTF-1 [3].  As specified in STD 10, RFC 821
   [10], the message is expected to consist of lines of reasonable
   length (less than or equal to 1000 characters).

   On some older implementations of mail and news, only the 7 bit subset
   of ISO-10646-UTF-1 can be used.  This is identical to the ASCII 7 bit
   code.  On some mail transports that are not compliant with STD 10,
   RFC 821 [10], line length may be restricted by the service.

   Text may be followed by a nested keyword to define the encoded part
   further, e.g., "signature":

        Encoding: 496 Text, 8 Text Signature



Costanzo, Robinson & Ullmann                                    [Page 5]

RFC 1505                 Encoding Header Field               August 1993


   An automated file sending service may find this useful, for example,
   to differentiate between and ignore the signature area when parsing
   the body of a message for file requests.

3.2  Message

   This encoding indicates that the body part is itself in the format of
   an Internet message, with its own header part and body part(s).  A
   "message" body part's message header may be a full Internet message
   header or it may consist only of an Encoding field.

   Using the message encoding on returned mail makes it practical for a
   mail reading system to implement a reliable automatic resending
   function, if the mailer generates it when returning contents.  It is
   also useful in a "copy append" MUA (mail user agent) operation.

   MTAs (mail transfer agents) returning mail should generate an
   Encoding header.  Note that this does not require any parsing or
   transformation of the returned message; the message is simply
   appended un-modified; MTAs are prohibited from modifying the content
   of messages.

        Encoding: 7 Text (Return Reason), Message (Returned Mail)

3.3  Hex

   The encoding indicates that the body part contains binary data,
   encoded as 2 hexadecimal digits per byte, highest significant nibble
   first.

   Lines consist of an even number of hexadecimal digits.  Blank lines
   are not permitted.  The decode process must accept lines with between
   2 and 1000 characters, inclusive.

   The Hex encoding is provided as a simple way of providing a method of
   encoding small binary objects.

3.4  EVFU

   EVFU (electronic vertical format unit) specifies that each line
   begins with a one-character "channel selector".  The original purpose
   was to select a channel on a paper tape loop controlling the printer.

   This encoding is sometimes called "FORTRAN" format.  It is the
   default output format of FORTRAN programs on a number of computer
   systems.





Costanzo, Robinson & Ullmann                                    [Page 6]

RFC 1505                 Encoding Header Field               August 1993


   The legal characters are '0' to '9', '+', '-', and space.  These
   correspond to the 12 rows (and absence of a punch) on a printer
   control tape (used when the control unit was electromechanical).

   The channels that have generally agreed definitions are:

        1          advances to the first print line on the next page
        0          skip a line, i.e., double-space
        +          over-print the preceeding line
        -          skip 2 lines, i.e., triple-space
        (space)    print on the next line, single-space

3.5  EDI-X12 and EDIFACT

   The EDI-X12 and EDIFACT keywords indicate that the message or part is
   a EDI (Electronic Document Interchange) business document, formatted
   according to ANSI X12 or the EDIFACT standard.

   A message containing a note and 2 X12 purchase orders might have an
   encoding of:

        Encoding: 17 TEXT, 146 EDI-X12, 69 EDI-X12

3.6  FS

   The FS (File System) keyword specifies a section consisting of
   encoded file system objects.  This encoding method (defined in
   section 4) allows the moving of a structured set of files from one
   environment to another while preserving all common elements.

3.7  LZJU90

   The LZJU90 keyword specifies a section consisting of an encoded
   binary or text object.  The encoding (defined in section 5) provides
   both compression and representation in a text format.

3.8  LZW

   The LZW keyword specifies a section consisting of the data produced
   by the Unix compress program.

3.9  UUENCODE

   The uuencode keyword specifies a section consisting of the output of
   the uuencode program supplied as part of uucp.






Costanzo, Robinson & Ullmann                                    [Page 7]

RFC 1505                 Encoding Header Field               August 1993


3.10  PEM and PEM-Clear

   The PEM and PEM-Clear keywords indicate that the section is encrypted
   with the methods specified in RFCs 1421-1424 [4,5,6,7] or uses the
   MIC-Clear encapsulation specified therein.