RFC 3516 (rfc3516) - Page 2 of 8
IMAP4 Binary Content Extension
Alternative Format: Original Text Document
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
