rfc1505.txt

RFC 的详细文档！

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.

   A simple text object encrypted with PEM has the header:

             Encoding: PEM Text

   Note that while this indicates that the text resulting from the PEM
   decryption is ISO-10646-UTF-1 text, the present version of PEM
   further restricts this to only the 7 bit subset.  A future version of
   PEM may lift this restriction.

   If the object resulting from the decryption starts with Internet
   message header(s), the encoding is:

             Encoding: PEM Message

   This is useful to conceal both the encoding within and the headers
   not needed to deliver the message (such as Subject:).

   PEM does not provide detached signatures, but rather provides the
   MIC-Clear mode to send messages with integrity checks that are not
   encrypted.  In this mode, the keyword PEM-Clear is used:

             Encoding: PEM-Clear EDIFACT

   The example being a non-encrypted EDIFACT transaction with a digital
   signature.  With the proper selection of PEM parameters and
   environment, this can also provide non-repudiation, but it does not
   provide confidentiality.

   Decoders that are capable of decrypting PEM treat the two keywords in
   the same way, using the contained PEM headers to distinguish the
   mode.  Decoders that do not understand PEM can use the PEM-Clear
   keyword as a hint that it may be useful to treat the section as text,
   or even continue the decode sequence after removing the PEM headers.

   When Encoding is used for PEM, the RFC934 [9] encapsulation specified
   in RFC1421 is not used.

3.11  PGP

   The PGP keyword indicates that the section is encrypted using the
   Pretty Good Privacy specification, or is a public key block, keyring,
   or detached signature meaningful to the PGP program.  (These objects



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


   are distinguished by internal information.)

   The keyword actually implies 3 different transforms:  a compression
   step, the encryption, and an ASCII encoding.  These transforms are
   internal to the PGP encoder/decoder.  A simple text message encrypted
   with PGP is specified by:

        Encoding: PGP Text

   An EDI transaction using ANSI X12 might be:

        Encoding: 176 PGP EDI-X12

   Since an evesdropper can still "see" the nested type (Text or EDI in
   these examples), thus making information available to traffic
   analysis which is undesirable in some applications, the sender may
   prefer to use:

        Encoding: PGP Message

   As discussed in the description of the Message keyword, the enclosed
   object may have a complete header or consist only of an Encoding:
   header describing its content.

   When PGP is used to transmit an encoded key or keyring, with no
   object significant to the mail user agent as a result of the decoding
   (e.g., text to display), the keyword is used by itself.

   Another case of the PGP keyword occurs in "clear-signing" a message.
   That is, sending an un-encrypted message with a digital signature
   providing authentication and (in some environments) non-deniability.

        Encoding: 201 Text, 8 PGP Signature, 4 Text Signature

   This example indicates a 201 line message, followed by an 8 line (in
   its encoded form) PGP detached signature.  The processing of the PGP
   section is expected (in this example) to result in a text object that
   is to be treated by the receiver as a signature, possibly something
   like:

        [PGP signed [e-mail] Robert L Ullmann  VALID/TRUSTED]

   Note that the PGP signature algorithm is applied to the encoded form
   of the clear-text section, not the object(s) before encoding.  (Which
   would be quite difficult for encodings like tar or FS).  Continuing
   the example, the PGP signature is then followed by a 4 line
   "ordinary" signature section.




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


3.12  Signature

   The signature keyword indicates that the section contains an Internet
   message signature.  An Internet message signature is an area of an
   Internet message (usually located at the end) which contains a single
   line or multiple lines of characters.  The signature may comprise the
   sender's name or a saying the sender is fond of.  It is normally
   inserted automatically in all outgoing message bodies.  The encoding
   keyword "Signature" must always be nested and follow another keyword.

        Encoding: 14 Text, 3 Text Signature

   A usenet news posting program should generate an encoding showing
   which is the text and which is the signature area of the posted
   message.

3.13  TAR

   The tar keyword specifies a section consisting of the output of the
   tar program supplied as part of Unix.

3.14  PostScript

   The PostScript keyword specifies a section formatted according to the
   PostScript [8] computer program language definition.  PostScript is a
   registered trademark of Adobe Systems Inc.

3.15  SHAR

   The SHAR keyword specifies a section encoded in shell archive format.
   Use of shar, although supported, is not recommended.

   WARNING:  Because the shell archive may contain commands you may not
   want executed, the decoder should not automatically execute decoded
   shell archived statements.  This warning also applies to any future
   types that include commands to be executed by the receiver.

3.16  Uniform Resource Locator

   The URL keyword indicates that the section consists of zero or more
   references to resources of some type.  URL provides a facility to
   include by reference arbitrary external resources from various
   sources in the Internet.  The specification of URL is a work in
   progress in the URI working group of the IETF.







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


3.17  Registering New Keywords

   New encoding keywords which are not reserved for implementation-
   specific use must be registered with the Internet Assigned Numbers
   Authority (IANA).  IANA acts as a central registry for these values.
   IANA may reject or modify the keyword registration request if it does
   not meet the criteria as specified in section 3.  Keywords beginning
   with "X-" are permanently reserved to implementation-specific use.
   IANA will not register an encoding keyword that begins with "X-".
   Registration requests should be sent via electronic mail to IANA as
   follows:

             To:  [e-mail]
             Subject:  Registration of a new EHF-MAIL Keyword

   The mail message must specify the keyword for the encoding and
   acronyms if appropriate.  Documentation defining the keyword and its
   proposed purpose must be included.  The documentation must either
   reference an external non-Internet standards document or an existing
   or soon to be RFC.  If applicable, the documentation should contain a
   draft version of the future RFC.  The draft must be submitted as a
   RFC according to the normal procedure within a reasonable amount of
   time after the keyword's registration has been approved.

4.  FS (File System) Object Encoding

   The file system encoding provides a standard, transportable encoding
   of file system objects from many different operating systems.  The
   intent is to allow the moving of a structured set of files from one
   environment to another while preserving common elements.  At the same
   time, files can be moved within a single environment while preserving
   all attributes.

   The representations consist of a series of nested sections, with
   attributes defined at the appropriate levels.  Each section begins
   with an open bracket "[" followed by a directive keyword and ends
   with a close bracket "]".  Attributes are lines, beginning with a
   keyword.  Lines which begin with a LWSP (linear white space)
   character are continuation lines.

   Any string-type directive or attribute may be a simple string not
   starting with a quotation mark ( " ) and not containing special
   characters (e.g.  newline) or LWSP (space and tab).  The string name
   begins with the first non-LWSP character on the line following the
   attribute or directive keyword and ends with the last non-LWSP
   character.





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


   Otherwise, the character string name is enclosed in quotes.  The
   string itself contains characters in ISO-10646-UTF-1 but is quoted
   and escaped at octet level (as elsewhere in RFC822 [2]).  The strings
   begin and end with a quotation mark ( " ).  Octets equal to quote in
   the string are escaped, as are octets equal to the escape characters
   (\" and \\).  The escaped octets may be part of a UTF multi-octet
   character.  Octets that are not printable are escaped with \nnn octal
   representation.  When an escape (\) occurs at the end of a line, the
   escape, the end of the line, and the first character of the next
   line, which must be one of the LWSP characters, are removed
   (ignored).

    [ file Simple-File.Name

    [ file "   Long file name starting with spaces and having a couple\
      [sic] of nasties in it like this newline\012near the end."

   Note that in the above example, there is one space (not two) between
   "couple" and "[sic]".  The encoder may choose to use the nnn sequence
   for any character that might cause trouble.  Refer to section 5.1 for
   line length recommendations.

4.1  Sections

   A section starts with an open bracket, followed by a keyword that
   defines the type of section.

   The section keywords are:

             directory
             entry
             file
             segment
             data

   The encoding may start with either a file, directory or entry.  A
   directory section may contain zero or more file, entry, and directory
   sections.  A file section contains a data section or zero or more
   segment sections.  A segment section contains a data section or zero
   or more segment sections.

4.1.1  Directory

   This indicates the start of a directory.  There is one parameter, the
   entry name of the directory:






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


             [ directory foo
             ...
             ]

4.1.2  Entry

   The entry keyword represents an entry in a directory that is not a
   file or a sub-directory.  Examples of entries are soft links in Unix,
   or access categories in Primos.  A Primos access category might look
   like this:

             [ entry SYS.ACAT
             type ACAT
             created 27 Jan 1987 15:31:04.00
             acl SYADMIN:* ARIEL:DALURWX $REST:
             ]

4.1.3  File

   The file keyword is followed by the entry name of the file.  The
   section then continues with attributes, possibly segments, and then
   data.

             [ file MY.FILE
             created 27 Feb 1987 12:10:20.07
             modified 27 Mar 1987 16:17:03.02
             type DAM
             [ data LZJU90
             * LZJU90
             ...
             ]]

4.1.4  Segment

   This is used to define segments of a file.  It should only be used
   when encoding files that are actually segmented.  The optional
   parameter is the number or name of the segment.

   When encoding Macintosh files, the two forks of the file are treated
   as segments:











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


             [ file A.MAC.FILE
             display "A Mac File"
             type MAC
             comment "I created this myself"
             ...
             [ segment resource
             [ data ...
             ...
             ]]
             [ segment data
             [ data ...
             ...
             ]]]

4.1.5  Data

   The data section contains the encoded data of the file.  The encoding
   method is defined in section 5.  The data section must be last within
   the containing section.

4.2  Attributes

   Attributes may occur within file, entry, directory, and segment
   sections.  Attributes must occur before sub-sections.

   The attribute directives are:

             display
             type
             created
             modified
             accessed
             owner
             group
             acl
             password
             block
             record
             application

4.2.1  Display

   This indicates the display name of the object.  Some systems, such as
   the Macintosh, use a different form of the name for matching or
   uniqueness.






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


4.2.2  Comment

   This contains an arbitrary comment on the object.  The Macintosh
   stores this attribute with the file.