rfc2183.txt

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


RFC 2183                  Content-Disposition                August 1997


2.10  Content-Disposition and the Main Message

   It is permissible to use Content-Disposition on the main body of an
   [RFC 822] message.

3.  Examples

   Here is a an example of a body part containing a JPEG image that is
   intended to be viewed by the user immediately:

        Content-Type: image/jpeg
        Content-Disposition: inline
        Content-Description: just a small picture of me

         <jpeg data>

   The following body part contains a JPEG image that should be
   displayed to the user only if the user requests it. If the JPEG is
   written to a file, the file should be named "genome.jpg".  The
   recipient's user might also choose to set the last-modified date of
   the stored file to date in the modification-date parameter:

        Content-Type: image/jpeg
        Content-Disposition: attachment; filename=genome.jpeg;
          modification-date="Wed, 12 Feb 1997 16:29:51 -0500";
        Content-Description: a complete map of the human genome

        <jpeg data>

   The following is an example of the use of the `attachment'
   disposition with a multipart body part.  The user should see text-
   part-1 immediately, then take some action to view multipart-2.  After
   taking action to view multipart-2, the user will see text-part-2
   right away, and be required to take action to view jpeg-1.  Subparts
   are indented for clarity; they would not be so indented in a real
   message.















Troost, et. al.             Standards Track                     [Page 7]

RFC 2183                  Content-Disposition                August 1997


        Content-Type: multipart/mixed; boundary=outer
        Content-Description: multipart-1

        --outer
          Content-Type: text/plain
          Content-Disposition: inline
          Content-Description: text-part-1

          Some text goes here

        --outer
          Content-Type: multipart/mixed; boundary=inner
          Content-Disposition: attachment
          Content-Description: multipart-2

          --inner
            Content-Type: text/plain
            Content-Disposition: inline
            Content-Description: text-part-2

            Some more text here.

          --inner
            Content-Type: image/jpeg
            Content-Disposition: attachment
            Content-Description: jpeg-1

            <jpeg data>
          --inner--
        --outer--

4.  Summary

   Content-Disposition takes one of two values, `inline' and
   `attachment'.  `Inline' indicates that the entity should be
   immediately displayed to the user, whereas `attachment' means that
   the user should take additional action to view the entity.

   The `filename' parameter can be used to suggest a filename for
   storing the bodypart, if the user wishes to store it in an external
   file.










Troost, et. al.             Standards Track                     [Page 8]

RFC 2183                  Content-Disposition                August 1997


5.  Security Considerations

   There are security issues involved any time users exchange data.
   While these are not to be minimized, neither does this memo change
   the status quo in that regard, except in one instance.

   Since this memo provides a way for the sender to suggest a filename,
   a receiving MUA must take care that the sender's suggested filename
   does not represent a hazard. Using UNIX as an example, some hazards
   would be:

   +    Creating startup files (e.g., ".login").

   +    Creating or overwriting system files (e.g., "/etc/passwd").

   +    Overwriting any existing file.

   +    Placing executable files into any command search path
        (e.g., "~/bin/more").

   +    Sending the file to a pipe (e.g., "| sh").

   In general, the receiving MUA should not name or place the file such
   that it will get interpreted or executed without the user explicitly
   initiating the action.

   It is very important to note that this is not an exhaustive list; it
   is intended as a small set of examples only.  Implementors must be
   alert to the potential hazards on their target systems.

6.  References

   [RFC 2119]
        Bradner, S., "Key words for use in RFCs to Indicate Requirement
        Levels", RFC 2119, March 1997.

   [RFC 2184]
        Freed, N. and K. Moore, "MIME Parameter value and Encoded Words:
        Character Sets, Lanaguage, and Continuations", RFC 2184, August
        1997.

   [RFC 2045]
        Freed, N. and N. Borenstein, "MIME (Multipurpose Internet Mail
        Extensions) Part One: Format of Internet Message Bodies", RFC
        2045, December 1996.






Troost, et. al.             Standards Track                     [Page 9]

RFC 2183                  Content-Disposition                August 1997


   [RFC 2046]
        Freed, N. and N. Borenstein, "MIME (Multipurpose Internet Mail
        Extensions) Part Two: Media Types", RFC 2046, December 1996.

   [RFC 2047]
        Moore, K., "MIME (Multipurpose Internet Mail Extensions) Part
        Three: Message Header Extensions for non-ASCII Text", RFC 2047,
        December 1996.

   [RFC 2048]
        Freed, N., Klensin, J. and J. Postel, "MIME (Multipurpose
        Internet Mail Extensions) Part Four: Registration Procedures",
        RFC 2048, December 1996.

   [RFC 2049]
        Freed, N. and N. Borenstein, "MIME (Multipurpose Internet Mail
        Extensions) Part Five: Conformance Criteria and Examples", RFC
        2049, December 1996.

   [RFC 822]
        Crocker, D., "Standard for the Format of ARPA Internet Text
        Messages", STD 11, RFC 822, UDEL, August 1982.

7.  Acknowledgements

   We gratefully acknowledge the help these people provided during the
   preparation of this draft:

        Nathaniel Borenstein
        Ned Freed
        Keith Moore
        Dave Crocker
        Dan Pritchett


















Troost, et. al.             Standards Track                    [Page 10]

RFC 2183                  Content-Disposition                August 1997


8.  Authors' Addresses

   You should blame the editor of this version of the document for any
   changes since RFC 1806:

        Keith Moore
        Department of Computer Science
        University of Tennessee, Knoxville
        107 Ayres Hall
        Knoxville TN  37996-1301
        USA

        Phone: [phone]
        Fax: [phone]
        Email: [e-mail]


        The authors of RFC 1806 are:

        Rens Troost
        New Century Systems
        324 East 41st Street #804
        New York, NY, 10017 USA

        Phone: [phone]
        Fax: [phone]
        EMail: [e-mail]


        Steve Dorner
        QUALCOMM Incorporated
        6455 Lusk Boulevard
        San Diego, CA 92121
        USA

        EMail: [e-mail]


9. Registration of New Content-Disposition Values and Parameters

   New Content-Disposition values (besides "inline" and "attachment")
   may be defined only by Internet standards-track documents, or in
   Experimental documents approved by the Internet Engineering Steering
   Group.







Troost, et. al.             Standards Track                    [Page 11]

RFC 2183                  Content-Disposition                August 1997


   New content-disposition parameters may be registered by supplying the
   information in the following template and sending it via electronic
   mail to [e-mail]:

     To: [e-mail]
     Subject: Registration of new Content-Disposition parameter

     Content-Disposition parameter name:

     Allowable values for this parameter:
          (If the parameter can only assume a small number of values,
          list each of those values.  Otherwise, describe the values
          that the parameter can assume.)
     Description:
          (What is the purpose of this parameter and how is it used?)

10. Changes since RFC 1806

   The following changes have been made since the earlier version of
   this document, published in RFC 1806 as an Experimental protocol:

   +    Updated references to MIME documents.  In some cases this
        involved substituting a reference to one of the current MIME
        RFCs for a reference to RFC 1521; in other cases, a reference to
        RFC 1521 was simply replaced with the word "MIME".

   +    Added  a section on registration procedures, since none of the
        procedures in RFC 2048 seemed to be appropriate.

   +    Added new parameter types: creation-date, modification-date,
        read-date, and size.


   +    Incorporated a reference to draft-freed-pvcsc-* for encoding
        long or non-ASCII parameter values.

   +    Added reference to RFC 2119 to define MUST, SHOULD, etc.
        keywords.













Troost, et. al.             Standards Track                    [Page 12]