rfc4978.txt

广泛使用的邮件服务器！同时

   apply, but the base-64 encoding adds another problem.  8-bit
   compression algorithms such as deflate work well on 8-bit file
   formats, however base-64 turns a file into something resembling 6-bit
   bytes, hiding most of the 8-bit file format from the compressor.

   When using the zlib library (see [RFC1951]), the functions
   deflateInit2(), deflate(), inflateInit2(), and inflate() suffice to
   implement this extension.  The windowBits value must be in the range
   -8 to -15, or else deflateInit2() uses the wrong format.
   deflateParams() can be used to improve compression rate and resource
   use.  The Z_FULL_FLUSH argument to deflate() can be used to clear the
   dictionary (the receiving peer does not need to do anything).

   A client can improve downstream compression by implementing BINARY
   (defined in [RFC3516]) and using FETCH BINARY instead of FETCH BODY.
   In the author's experience, the improvement ranges from 5% to 40%
   depending on the attachment being downloaded.

   A server can improve downstream compression if it hints to the
   compressor that the data type is about to change strongly, e.g., by
   sending a Z_FULL_FLUSH at the start and end of large non-text
   literals (before and after '*CHAR8' in the definition of literal in
   RFC 3501, page 86).  Small literals are best left alone.  A possible
   boundary is 5k.



Gulbrandsen                 Standards Track                     [Page 5]

RFC 4978              The IMAP COMPRESS Extension            August 2007


   A server can improve the CPU efficiency both of the server and the
   client if it adjusts the compression level (e.g., using the
   deflateParams() function in zlib) at these points, to avoid trying to
   compress incompressible attachments.  A very simple strategy is to
   change the level to 0 at the start of a literal provided the first
   two bytes are either 0x1F 0x8B (as in deflate-compressed files) or
   0xFF 0xD8 (JPEG), and to keep it at 1-5 the rest of the time.  More
   complex strategies are possible.

5.  Formal Syntax

   The following syntax specification uses the Augmented Backus-Naur
   Form (ABNF) notation as specified in [RFC4234].  This syntax augments
   the grammar specified in [RFC3501].  [RFC4234] defines SP and
   [RFC3501] defines command-auth, capability, and resp-text-code.

   Except as noted otherwise, all alphabetic characters are case-
   insensitive.  The use of upper or lower case characters to define
   token strings is for editorial clarity only.  Implementations MUST
   accept these strings in a case-insensitive fashion.

       command-auth =/ compress

       compress    = "COMPRESS" SP algorithm

       capability  =/ "COMPRESS=" algorithm
                     ;; multiple COMPRESS capabilities allowed

       algorithm   = "DEFLATE"

       resp-text-code =/ "COMPRESSIONACTIVE"

   Note that due the syntax of capability names, future algorithm names
   must be atoms.

6.  Security Considerations

   As for TLS compression [RFC3749].

7.  IANA Considerations

   The IANA has added COMPRESS=DEFLATE to the list of IMAP capabilities.









Gulbrandsen                 Standards Track                     [Page 6]

RFC 4978              The IMAP COMPRESS Extension            August 2007


8.  Acknowledgements

   Eric Burger, Dave Cridland, Tony Finch, Ned Freed, Philip Guenther,
   Randall Gellens, Tony Hansen, Cullen Jennings, Stephane Maes, Alexey
   Melnikov, Lyndon Nerenberg, and Zoltan Ordogh have all helped with
   this document.

   The author would also like to thank various people in the rooms at
   meetings, whose help is real, but not reflected in the author's
   mailbox.

9.  References

9.1.  Normative References

   [RFC1951]  Deutsch, P., "DEFLATE Compressed Data Format Specification
              version 1.3", RFC 1951, May 1996.

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

   [RFC3501]  Crispin, M., "INTERNET MESSAGE ACCESS PROTOCOL - VERSION
              4rev1", RFC 3501, March 2003.

   [RFC4234]  Crocker, D. and P. Overell, "Augmented BNF for Syntax
              Specifications: ABNF", RFC 4234, October 2005.

9.2.  Informative References

   [RFC1962]  Rand, D., "The PPP Compression Control Protocol (CCP)",
              RFC 1962, June 1996.

   [RFC3516]  Nerenberg, L., "IMAP4 Binary Content Extension", RFC 3516,
              April 2003.

   [RFC3749]  Hollenbeck, S., "Transport Layer Security Protocol
              Compression Methods", RFC 3749, May 2004.

   [RFC4346]  Dierks, T. and E. Rescorla, "The Transport Layer Security
              (TLS) Protocol Version 1.1", RFC 4346, April 2006.

   [RFC4422]  Melnikov, A. and  K. Zeilenga, "Simple Authentication and
              Security Layer (SASL)", RFC 4422, June 2006.

   [V42BIS]   ITU, "V.42bis: Data compression procedures for data
              circuit-terminating equipment (DCE) using error correction
              procedures", http://www.itu.int/rec/T-REC-V.42bis, January
              1990.



Gulbrandsen                 Standards Track                     [Page 7]

RFC 4978              The IMAP COMPRESS Extension            August 2007


   [MNP]      Gilbert Held, "The Complete Modem Reference", Second
              Edition, Wiley Professional Computing, ISBN 0-471-00852-4,
              May 1994.

Author's Address

    Arnt Gulbrandsen
    Oryx Mail Systems GmbH
    Schweppermannstr. 8
    D-81671 Muenchen
    Germany

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





































Gulbrandsen                 Standards Track                     [Page 8]

RFC 4978              The IMAP COMPRESS Extension            August 2007


Full Copyright Statement

   Copyright (C) The IETF Trust (2007).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
   THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.

Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   [e-mail].












Gulbrandsen                 Standards Track                     [Page 9]