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