Network Working Group L. Nerenberg
Internet Draft: IMAP4 Binary Content Extension MessagingDirect Ltd.
Document: draft-nerenberg-imap-binary-01.txt November 2000
Expires: May 2001
IMAP4 Binary Content Extension
Status of this memo
This document is an Internet Draft and is in full conformance with
all provisions of Section 10 of RFC 2026.
Internet Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet
Drafts.
Internet Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other
documents at any time. It is inappropriate to use Internet Drafts
as reference material or to cite them other than as "work in
progress."
The list of current Internet Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
A revised version of this draft document will be submitted to the
RFC editor as a Proposed Standard for the Internet Community.
Discussion and suggestions for improvement are requested.
Distribution of this draft is unlimited.
0. Administrivia
Changes from version -00
+ Renamed CHARALL to BINCHAR.
+ Changed syntax to "FETCH x BINARY ..."
+ Defined FETCH BINARY response.
+ Modified <literal8> syntax to distinguish it from <literal>.
+ Added examples section.
Nerenberg draft-nerenberg-imap-binary-01.txt [Page 1]
Internet Draft IMAP4 Binary Content Extension November 2000
1. Abstract
This memo defines the BINARY extension to the Internet Message
Access Protocol [IMAP4rev1]. It provides a mechanism for IMAP4
clients and servers to exchange certain MIME body parts in a raw
binary format, without the use of MIME content transfer encoding.
2. 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].
In examples, "C:" and "S:" preface lines sent by the client and the
server respectively.
3. Overview
The MIME extensions to Internet messaging allow for the transmis-
sion 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 normally capable of doing so. The overhead of MIME encod-
ing this content can be considerable in some contexts (e.g. clients
connected over slow radio networks).
The BINARY extension extends the FETCH command to allow clients to
request terminal MIME body parts be sent in a raw, unencoded, for-
mat, thus avoiding any content transfer encoding overhead.
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 two new FETCH command data items.
BINARY[<section_binary><<partial>>
The binary content of a particular terminal body section.
This data item acts as BODY does, with the following excep-
tions:
The server removes any MIME content transfer encoding from the
body part before transmitting it to the client. This content
conversion MUST NOT cause a loss of information. If the server
is unable to decode the MIME content transfer encoding, it
MUST reject the FETCH command with a NO response that includes
the "UNKNOWN-TRANSPORT-ENCODING" extended response code.
Nerenberg draft-nerenberg-imap-binary-01.txt [Page 2]
Internet Draft IMAP4 Binary Content Extension November 2000
Only terminal body parts can be requested. The part specifier
MUST NOT refer to non-terminal body parts, or to message head-
ers. Servers MUST reject such requests with a BAD response.
BINARY.PEEK[<section_binary><<partial>>
An alternate form of BINARY[<section>] that does not implic-
itly set the \Seen flag.
4.3. FETCH Response Extensions
This extension defines one new FETCH response data item.
BINARY[<section>]<<origin_octet>>
A <literal8> expressing the body content of the specified sec-
tion after the removal of any content transfer encoding.
If the origin octet is specified, this string is a substring
of the entire body contents, starting at that origin octet.
This means that BODY[]<0> MAY be truncated, but BODY[] is
NEVER truncated.
5. Examples
The examples in this section are illustrative only; they DO NOT
form part of this specification.
This example uses a message containing a text/plain body part, fol-
lowed by an image/jpeg body part, followed by a multipart/report
body part:
MIME Content
Part# Type
-----------------------------------------------
1 text/plain
2 image/jpeg (BASE64 encoded,
encoded size = 30448 octets)
3 multipart/report
3.1 text/plain
3.2 message/delivery-status
Here the client requests the image/jpeg part in binary format:
C: 1 fetch 1 binary[2]
S: * FETCH (BINARY[2] ~{22216}
S: <22216 octets of binary data>)
S: 1 OK Completed
Note the absence of a <CRLF> between the end of the binary data and
the closing parenthesis. Also, the size of the <literal8> string
(22216 octets) represents the size of the data after the content
transfer encoding has been removed. This is not the same as the
size in the BODYSTRUCTURE response (30448 octets) which represents
the BASE64 encoded size of the body part.
Nerenberg draft-nerenberg-imap-binary-01.txt [Page 3]
Internet Draft IMAP4 Binary Content Extension November 2000
If the server does not know how to undo the content transfer encod-
ing it issues a failure response:
S: 1 NO [UNKNOWN-CONTENT-ENCODING] Unknown encoding for
message 1, part 2
A BINARY fetch of the multipart/report is illegal; it contains
nested MIME parts:
C: 2 fetch 1 binary[3]
S: 2 BAD Non-terminal part (3) requested in FETCH BINARY for
message 1
For parts with no content transfer encoding, FETCH BODY and FETCH
BINARY return identical content:
C: 3 fetch 1 body[1]
S: * 1 FETCH (BODY[1] {80}
S: This is a test message to use in the examples section of the
S: IMAP BINARY RFC.
S: )
S: 3 OK Completed
C: 4 fetch 1 binary[1]
S: * 1 FETCH (BINARY[1] ~{80}
S: This is a test message to use in the examples section of the
S: IMAP BINARY RFC.
S: )
S: 4 OK Completed
6. Interoperability Considerations
Messaging clients and servers have been notoriously lax in their
adherance to the Internet CRLF convention for terminating lines of
textual data in Internet protocols. When sending data using the
BINARY extension, servers must take care to ensure that non-encoded
non-binary body parts are always transmitted using the IMAP4 CRLF
line termination syntax, regardless of the underlying storage rep-
resentation of the data on the server.
While the syntax allows for BINARY fetches of more than one body
part in a single command, such use is discouraged. In the event of
multiple partial failures, it can be difficult for the client to
map specific failures to individual components of the request.
Instead, clients SHOULD issue separate FETCH requests for each body
part.
This extension provides an optimization that is useful in certain
specific scenarios. It does not absolve clients from providing
basic functionality (content transfer decoding) that should be
available in all messaging clients. Clients supporting this exten-
sion SHOULD be prepared to provide their own content transfer
decoding of data, although they may decide not to retry a FETCH
BINARY request with a FETCH BODY request, if that is reasonable in
the context of their execution environment.
Nerenberg draft-nerenberg-imap-binary-01.txt [Page 4]
Internet Draft IMAP4 Binary Content Extension November 2000
7. Formal Protocol Syntax
The following syntax specification uses the augmented Backus-Naur
Form (BNF) notation as used in [IMAP4rev1].
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.
This syntax extends the grammar specified in [IMAP4rev1].
BINCHAR ::= <0x00 - 0xff>
fetch_att =/ "BINARY" [".PEEK"] section_binary
["<" number "." nz_number ">"]
literal8 ::= "~{" number "}" CRLF *BINCHAR
;; <number> represents the number of BINCHAR octets
;; in the response string.
resp_code_text =/ "UNKNOWN-TRANSPORT-ENCODING"
section_binary ::= "[" [ (nz_number *["." nz_number] ] "]"
;; MUST refer only to a terminal mime body part.
8. References
[IMAP4rev1] Crispin, M., "Internet Message Access Protocol Version
4rev1," RFC2060, University of Washington, December 1996
[KEYWORD] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels," BCP 9, RFC2119, March 1997
[MIME-IMB] Freed, N., N. Borenstein, "Multipurpose Internet Mail
Extensions (MIME) Part One: Format of Internet Message Bodies,"
RFC2045, November 1996.
9. Security Considerations
Sending binary data to servers and clients that are expecting well-
formed non-binary input is a method commonly used to attempt to
bypass security. The IMAP4 BINARY extension is only initiated at a
co-operating client's request, therefore the transmission of binary
content as defined in this memo should not affect legacy clients
that may be unable to properly cope with such binary content. A new
protocol syntax has been introduced to further distinguish between
<literal> and <literal8> data.
Nerenberg draft-nerenberg-imap-binary-01.txt [Page 5]
Internet Draft IMAP4 Binary Content Extension November 2000
10. Authors' Address
Lyndon Nerenberg
MessagingDirect Ltd.
Suite 900
10117 - Jasper Avenue
Edmonton, Alberta
Canada T5J 1W8
Email: lyndon@messagingdirect.com
Nerenberg draft-nerenberg-imap-binary-01.txt [Page 6]