RFC 3516 (rfc3516) - Page 2 of 8

IMAP4 Binary Content Extension

RFC 3516             IMAP4 Binary Content Extension           April 2003


   can give a noticeable reduction in resource consumption.  The Binary
   extension lets the server perform CTE decoding prior to transmitting
   message data to the client.

3.  Content-Transfer-Encoding Considerations

   Every IMAP4 body section has a MIME content-transfer-encoding.
   (Those without an explicit Content-Transfer-Encoding header are
   implicitly labeled as "7bit" content.)  In the terminology of [MIME-
   IMB], the CTE specifies both a decoding algorithm and the domain of
   the decoded data.  In this memo, "decoding" refers to the CTE
   decoding step described in [MIME-IMB].

   Certain CTEs use an identity encoding transformation.  For these CTEs
   there is no decoding required, however the domain of the underlying
   data may not be expressible in the IMAP4 protocol (e.g., MIME
   "binary" content containing NUL octets).  To accommodate these cases
   the Binary extension introduces a new type of literal protocol
   element that is fully eight bit transparent.

   Thus, server  processing of the FETCH BINARY command involves two
   logical steps:

   1)  perform any CTE-related decoding

   2)  determine the domain of the decoded data

   Step 2 is necessary to determine which protocol element should be
   used to transmit the decoded data.  (See FETCH Response Extensions
   for further details.)

4.  Framework for the IMAP4 Binary Extension

   This memo defines the following extensions to [IMAP4rev1].

4.1.  CAPABILITY Identification

   IMAP4 servers that support this extension MUST include "BINARY" in
   the response list to the CAPABILITY command.

4.2.  FETCH Command Extensions

   This extension defines three new FETCH command data items.

      BINARY[]

         Requests that the specified section be transmitted after
         performing CTE-related decoding.



Nerenberg                   Standards Track