WDIFF

draft-nerenberg-imap-binary-00.txt --> draft-nerenberg-imap-binary-01.txt

Network Working Group Lyndon L. Nerenberg
Internet Draft: IMAP4 Binary Content Extension MessagingDirect Ltd.
Document: draft-nerenberg-imap-binary-00.txt 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

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- Internet
Drafts.

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- Internet Drafts
as reference material or to cite them other than as "work in
progress."

The list of current Internet-Drafts Internet Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt

The list of Internet-Draft 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

I need

Changes from version -00

+ Renamed CHARALL to define "terminal" (as in "terminal MIME body part"). 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," "MUST NOT", "SHOULD", NOT," "SHOULD," "SHOULD NOT", 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.

Nerenberg draft-nerenberg-imap-binary-00.txt [Page 1]

Internet Draft IMAP4 Binary Content Extension November 2000

3. Overview

The MIME extensions to Internet messaging allow for the transmis-
sion of non-textual (binary) message content [MIME]. [MIME-IMB]. Since the
traditional transports for messaging are not always capable of
passing binary data transparently, MIME provides encoding schemes
that allow binary ("8 bit") content to be transmitted over trans-
ports transports that
are not normally capable of doing so.

As the size of binary message attachments increases, the The overhead of MIME encoding encod-
ing this content can be substantial, especially for
IMAP4 considerable in some contexts (e.g. clients connecting
connected over slow (e.g. radio) networks. radio networks).

The BINARY extension to IMAP4 extends the FETCH command to allow
the client clients to
request terminal MIME body parts be sent in a raw, unencoded, format. 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

4.1. CAPABILITY Identification

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

4.2 BINARY Extension to the

4.2. FETCH Command

The Extensions

This extension defines two new FETCH command is extended to allow a client to specify that data items.

BINARY[<section_binary><<partial>>
The binary content of a particular terminal MIME body part be transmitted as a raw (unencoded) octet
stream:

C: 0 FETCH 1 BODY[x.y.BINARY] section.
This variant of the FETCH command retrieves the terminal MIME body
part x.y data item acts as a "literal8" string. BODY does, with the following excep-
tions:

The server removes any MIME con-
tent content transfer encoding from the
body part before transmitting it to the client. This content
conversion MUST NOT cause a loss of infor-
mation. information. If the server
is unable to decode the MIME content transfer
encoding of the requested body part encoding, it
MUST reject the FETCH com-
mand command with a NO response that includes
the "UNKNOWN-TRANSPORT-ENCOD-
ING" "UNKNOWN-TRANSPORT-ENCODING" extended response code. A client that receives such an
extended response code can then retry the FETCH command without the
BINARY extension and attempt to decode the data itself.

The BINARY extension MUST only be used for terminal (leaf) MIME
body parts. It MUST NOT be used to retrieve headers or composite
MIME body parts. If a client uses the BINARY extension to request
the transmission of a non-terminal MIME body part the server MUST
reject the command with a NO response.

Nerenberg draft-nerenberg-imap-binary-00.txt draft-nerenberg-imap-binary-01.txt [Page 2]

Internet Draft IMAP4 Binary Content Extension November 2000

5. Interoperability Considerations

Messaging clients and servers have been notoriously lax in their
adherance

Only terminal body parts can be requested. The part specifier
MUST NOT refer to the Internet CRLF convention for terminating lines 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
textual BINARY[<section>] that does not implic-
itly set the \Seen flag.

4.3. FETCH Response Extensions

This extension defines one new FETCH response data in Internet protocols. When 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].

CHARALL

BINCHAR ::= <0x00 - 0xff>

fetch_att =/ "BINARY" [".PEEK"] section_binary
["<" number "." nz_number ">"]

literal8 ::= "{" "~{" number "}" CRLF *CHARALL *BINCHAR
;; Number <number> represents the number of CHARALL BINCHAR octets in
;; in the response string.

resp_code_text /= =/ "UNKNOWN-TRANSPORT-ENCODING"

section_text /= "BINARY"

section_binary ::= "[" [ (nz_number *["." nz_number] ] "]"
;; BINARY is valid ONLY for MUST refer only to a terminal MIME mime body parts.

7. part.

8. References

[IMAP4rev1] Crispin, M., "Internet Message Access Protocol Version
4rev1",
4rev1," RFC2060, University of Washington, December 1996

[KEYWORD] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", Levels," BCP 9, RFC2119, March 1997

[MIME]

[MIME-IMB] Freed, N., N. Borenstein, "Multipurpose Internet Mail Exten-
sions
Extensions (MIME) Part One: Format of Internet Message Bodies", Bodies,"
RFC2045, November 1996.

9. Security Considerations

Sending binary data to servers and clients that are expecting well-formed well-
formed non-binary input is a common method commonly used to attempt to
bypass secu-
rity. security. The IMAP4 BINARY extension is only initiated at a co-operat-
ing
co-operating client's request, therefore the transmission of binary
content as defined in this memo does 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-00.txt draft-nerenberg-imap-binary-01.txt [Page 3] 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-00.txt draft-nerenberg-imap-binary-01.txt [Page 4] 6]

----