IMAP4 Binary Content Extension
RFC 3516

• Status
• IESG evaluation record
• IESG writeups
• Email expansions
• History

• Versions
• 07

Network Working Group                                       L. Nerenberg
Request for Comments: 3516                               Orthanc Systems
Category: Standards Track                                     April 2003

                     IMAP4 Binary Content Extension

Status of this Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Copyright Notice

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

Abstract

   This memo defines the Binary extension to the Internet Message Access
   Protocol (IMAP4).  It provides a mechanism for IMAP4 clients and
   servers to exchange message body data without using a MIME content-
   transfer-encoding.

1.   Conventions Used in this Document

   The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY"
   in this document are to be interpreted as described in [KEYWORD].

   The abbreviation "CTE" means content-transfer-encoding.

2.   Introduction

   The MIME extensions to Internet messaging allow for the transmission
   of non-textual (binary) message content [MIME-IMB].  Since the
   traditional transports for messaging are not always capable of
   passing binary data transparently, MIME provides encoding schemes
   that allow binary content to be transmitted over transports that are
   not otherwise able to do so.

   The overhead of MIME-encoding this content can be considerable in
   some contexts (e.g., slow radio links, streaming multimedia).
   Reducing the overhead associated with CTE schemes such as base64

Nerenberg                   Standards Track                     [Page 1]
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<section-binary>[<partial>]

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

Nerenberg                   Standards Track                     [Page 2]
RFC 3516             IMAP4 Binary Content Extension           April 2003

         The <partial> argument, if present, requests that a subset of
         the data be returned.  The semantics of a partial FETCH BINARY
         command are the same as for a partial FETCH BODY command, with
         the exception that the <partial> arguments refer to the DECODED
         section data.

      BINARY.PEEK<section-binary>[<partial>]

         An alternate form of FETCH BINARY that does not implicitly set
         the \Seen flag.

      BINARY.SIZE<section-binary>

         Requests the decoded size of the section (i.e., the size to
         expect in response to the corresponding FETCH BINARY request).

         Note: client authors are cautioned that this might be an
         expensive operation for some server implementations.
         Needlessly issuing this request could result in degraded
         performance due to servers having to calculate the value every
         time the request is issued.

4.3.  FETCH Response Extensions

   This extension defines two new FETCH response data items.