rfc2912.txt

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

       :
      --break

      Content-Type: image/tiff; name="document.tiff"
      Content-Transfer-Encoding: base64
      Content-Disposition: attachment; filename="document.tiff"

      AAAADgAAAA8AAAAQAAAAEQAAABIAAAATAAAAFAAAABUAAAAWAAAAFwAAABg
      GgAAABsAAAAcAAAAHQAAAB4AAAAfAAAAIAAAACEAAAAiAAAAIwAAACQAAAA
       :
      (more data)
       :
      --break--

4.3 Multipart/alternative data

   This example illustrates three points:

   o  Information about the various parts in a multipart/alternative can
      be made available before the alternative body parts are processed.
      This may facilitiate optimum one-pass processing of
      multipart/alternative data.





Klyne                       Standards Track                     [Page 6]

RFC 2912       Indicating Media Features for MIME Content September 2000


   o  There may be alternatives having the same basic MIME content-type,
      but differing in the content features that they use.

   o  There is NO defined correspondence between 'Content-features'
      headers and contained body parts.

      Mime-Version: 1.0
      Content-Type: multipart/alternative; boundary="break"
      Content-features: (& (Type="text/plain") (charset=US-ASCII) )
      Content-features:
        (& (Type="text/html") (charset=ISO-8859-1) (color=limited) )
      Content-features:
        (& (Type="text/html") (charset=ISO-8859-1) (color=binary) )

      --break
      Content-type: "text/plain";charset=US-ASCII
      Content-features: (color=binary)

       :
      (data)
       :
      --break
      Content-type: "text/plain";charset=US-ASCII
      Content-features: (color=limited)

       :
      (data)
       :
      --break


      Content-type: text/html;charset=iso-8859-1
      Content-features: (color=binary)

       :
      (data)
       :
      --break
      Content-type: text/html;charset=iso-8859-1
      Content-features: (color=limited)

       :
      (data)
       :
      --break--






Klyne                       Standards Track                     [Page 7]

RFC 2912       Indicating Media Features for MIME Content September 2000


4.4 Reference to external message data

      Mime-Version: 1.0
      Content-type: message/external-body; access-type=URL;
                    URL="http://www.foo.com/file1.html"

      Content-type: Multipart/mixed
      Content-features: (& (Type="text/plain") (charset=US-ASCII) )
      Content-features: (& (Type="image/tiff") (color=limited) )

      <end>

4.5 Compressed data

   This example shows how the 'Content-features' header can be used to
   overcome the problem noted in the MIME registration for
   'Application/zip' regarding information about the data content.

      Mime-Version: 1.0
      Content-type: application/zip
      Content-features: (& (Type="text/plain") (charset=US-ASCII) )
      Content-features: (& (Type="image/tiff") (color=limited) )
      Content-transfer-encoding: base64

       :
      (data)
       :
      <end>

4.6 Multipart/related data

   (See also: RFC 2387, "The MIME Multipart/Related Content-type" [8])

      Mime-Version: 1.0
      Content-Type: multipart/related; boundary="boundary-example";
                    type="text/html"; start="<foo3@[e-mail]>"
      Content-features: (& (type="text/html") (charset=US-ASCII) )
      Content-features: (type="image/gif")

      --boundary-example
      Content-Type: text/html;charset=US-ASCII
      Content-ID: <foo3@[e-mail]>

      referencing a resource in another body part, for example
      through a statement such as:
      <IMG SRC="http://www.ietf.cnri.reston.va.us/images/ietflogo.gif"
       ALT="IETF logo">




Klyne                       Standards Track                     [Page 8]

RFC 2912       Indicating Media Features for MIME Content September 2000


      --boundary-example
      Content-Location:
         http://www.ietf.cnri.reston.va.us/images/ietflogo.gif
      Content-Type: IMAGE/GIF
      Content-Transfer-Encoding: BASE64

      R0lGODlhGAGgAPEAAP/////ZRaCgoAAAACH+PUNvcHlyaWdodCAoQykgMTk5
      NSBJRVRGLiBVbmF1dGhvcml6ZWQgZHVwbGljYXRpb24gcHJvaGliaXRlZC4A
      etc...

      --boundary-example--

5. Security Considerations

   When applied to simple or multipart MIME formatted data, a media
   feature expression provides summary information about the message
   data, which in many cases can be determined by examination of the
   message content.  Under these circumstances, no additional security
   considerations appear to be raised.

   When applied to other message composites, especially encrypted
   message content, feature expressions may disclose information that is
   otherwise unavailable.  In these cases, some security considerations
   associated with media content negotiation [1,2] may have greater
   relevance.

   It is suggested here that media feature descriptions may be usefully
   employed with encrypted message content.  In doing this, take care to
   ensure that the purpose of encryption is not compromised  (e.g.
   encryption might be intended to conceal the fact that a particular
   application data format is being used, which fact might be disclosed
   by an injudiciously applied Content-features header).

   If a 'Content-features' header is applied to a multipart/signed
   object (or indeed outside any other form of signed data) the media
   feature information is not protected.  This unprotected information
   could be tampered with, possibly fooling implementations into doing
   inappropriate things with the contained material.  (Putting the media
   feature information inside the signed information would overcome
   this, at the cost of requiring implementations to parse the inner
   structure to find it.)










Klyne                       Standards Track                     [Page 9]

RFC 2912       Indicating Media Features for MIME Content September 2000


6. Acknowledgements

   This proposal draws from discussions with Dan Wing.  The fax message
   example was taken from a proposal by Mike Ruhl.  The
   multipart/related example is developed from RFC 2557 [7].

   The author would like to thank the following people who offered
   comments that led to significant improvements:  Mr Hiroshi Tamura,
   Ted Hardie, Maurizio Codogno, Jacob Palme, Ned Freed.

7. References

   [1]  Klyne, G., "A Syntax for Describing Media Feature Sets", RFC
        2533, March 1999.

   [2]  Holtman, K., Mutz, A. and T. Hardie, "Media Feature Tag
        Registration Procedure", RFC 2506, March 1999.

   [3]  Crocker, D. and P. Overell, "Augmented BNF for Syntax
        Specifications: ABNF", RFC 2234, November 1997.

   [4]  Crocker, D., "Standard for the format of ARPA Internet text
        messages", STD 11, RFC 822, August 1982.

   [5]  Freed, N. and N. Borenstein, "Multipurpose Internet Mail
        Extensions (MIME) Part 1: Format of Internet message bodies",
        RFC 2045, November 1996.

   [6]  Levinson, E., "The MIME Multipart/Related Content-type", RFC
        2387, August 1998.

   [7]  Palme, J., Hopmann, A. and N. Shelness, "MIME Encapsulation of
        Aggregate Documents, such as HTML (MHTML)", RFC 2557, March
        1999.

8. Author's Address

   Graham Klyne
   Content Technologies Ltd.
   1220 Parkview,
   Arlington Business Park
   Theale
   Reading, RG7 4SA
   United Kingdom

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



Klyne                       Standards Track                    [Page 10]

RFC 2912       Indicating Media Features for MIME Content September 2000


9. Full Copyright Statement

   Copyright (C) The Internet Society (2000).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph are
   included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other
   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.



















Klyne                       Standards Track                    [Page 11]