WDIFF

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

Network Working Group L. Nerenberg
Internet Draft: IMAP4 Binary Content Extension MessagingDirect Ltd. ACI/MessagingDirect
Document: draft-nerenberg-imap-binary-01.txt November 2000
Expires: May draft-nerenberg-imap-binary-02.txt February 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."
progress.rq

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 -01

Defined the use of <literal8> syntax to APPEND binary data.

Added BINARYSTRUCTURE.

Removed the restriction for terminal body sections only.

Added missing ']' in section 4.2 definitions of BINARY and
BINARY.PEEK.

Clarified when to return [UNKNOWN-TRANSFER-ENCODING] reponse.

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

Internet Draft IMAP4 Binary Content Extension February 2001

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 data encoded with the use of MIME content transfer encoding. BINARY
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 otherwise able to do so. The overhead of MIME encod-
ing encoding
this content can be considerable in some contexts (e.g. clients
connected over slow radio networks). links).

The BINARY extension extends the FETCH command IMAP4 protocol to allow clients
and servers to
request terminal MIME body parts be sent exchange data in a raw, unencoded, for-
mat, thus avoiding any content transfer encoding overhead. binary (unencoded) format.

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.

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

Internet Draft IMAP4 Binary Content Extension February 2001

4.2. FETCH Command Extensions

This extension defines two three new FETCH command data items.

BINARY[<section_binary><<partial>>

BINARY[<section_binary>]<<partial>>
The binary content of a particular terminal body section. This data
item acts as the [IMAP4rev1] BODY data item does, but with the
following excep-
tions: modifications:

The server removes any converts the MIME content transfer encoding from content-transfer-encoding of the
body part section to BINARY before transmitting it to the client.
This content conversion MUST NOT cause a loss of information.
If the server
is unable to decode cannot convert the MIME content transfer encoding, content-transfer-encoding to
BINARY it MUST reject the FETCH command with a NO response
that includes the "UNKNOWN-TRANSPORT-ENCODING" "UNKNOWN-TRANSFER-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

When performing a partial FETCH, the offset argument refers to non-terminal
the offset into the CONVERTED body parts, or to message head-
ers. Servers MUST reject such requests with a BAD response.

BINARY.PEEK[<section_binary><<partial>> section.

BINARY.PEEK[<section_binary>]<<partial>>
An alternate form of BINARY[<section>] that does not implic-
itly set the \Seen flag.

BINARYSTRUCTURE
The MIME body structure of the message after converting all
body sections to the BINARY content-transfer-encoding. The
server computes this by parsing the MIME structure of the mes-
sage after performing any required content-transfer-encoding
modifications.

4.3. FETCH Response Extensions

This extension defines one two new FETCH response data item. items.

BINARY[<section>]<<origin_octet>>
A <literal8> expressing the body content of the specified sec-
tion body
section after converting the removal of any content transfer encoding. content-transfer-encoding to
BINARY.

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 offset refers to the body part: contents after
conversion to the BINARY content-transfer-encoding.

BINARYSTRUCTURE
A parenthesized list describing the 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 body structure of the client requests
message after converting all the image/jpeg part in binary format:

C: 1 fetch 1 binary[2]
S: * FETCH (BINARY[2] ~{22216}
S: <22216 octets sections to the BINARY con-
tent-transfer-encoding. The contents and format of binary data>)
S: 1 OK Completed

Note the absence list
are identical to those of a <CRLF> between the end [IMAP4rev1] BODYSTRUCTURE
response, but describe the converted body.

Calculating the sizes of the binary data and converted content may impose

Nerenberg draft-nerenberg-imap-binary-02.txt [Page 3]

Internet Draft IMAP4 Binary Content Extension February 2001

considerable overhead on some implementations. A server MAY
choose to defer this calculation until the client fetches the closing parenthesis. Also,
item. In this case, all size-related fields where the size of
the converted content is unknown MUST be set to NIL. If the
server reports a non-NIL value for the message size it MUST
match the size of the <literal8> string
(22216 octets) represents in a corresponding FETCH
BINARY response. For a complex message the server might defer
the size calculations for only a subset of the data after sections. In
this case the server SHOULD report the sizes for those sec-
tions where they can be easily determined. For example, given
a message with a 7BIT-encoded section and a BASE64-encoded
section, the server should return the size for the 7BIT-
encoded section, since the 7BIT- and BINARY-encoded sizes will
be the same.

If the server is unable to convert the content-transfer-encod-
ing of a section to BINARY, it MUST report the corresponding
content
transfer encoding has been removed. This and message size fields as NIL, and SHOULD
report any other size-related fields as NIL. A section report-
ing NIL for content encoding and message size cannot be
retrieved using FETCH BINARY, and servers MUST reject such
requests with a NO response that includes the "UNKNOWN-TRANS-
FER-ENCODING" extended response code.

Reporting a message encoding of NIL with a non-NIL message
size is a protocol error; servers MUST NOT return this combi-
nation of values.

4.4. APPEND Command Extensions

The APPEND command is extended to allow the client to append binary
data by specifying the octet count using <literal8> syntax. The
server SHOULD NOT perform any content-transfer-encoding conversion
of the data.

If the specified mailbox does not support the same as storage of binary
content the
size in server MUST reject the BODYSTRUCTURE APPEND command with a NO
response (30448 octets) which represents that includes the BASE64 encoded size "UNKNOWN-TRANSFER-ENCODING" extended
response code.

5. Examples

The examples in this section are illustrative only; they DO NOT
form part of the body part. this specification.

Most of these examples uses a message containing two sections: a
text/plain and an application/octet-stream.

MIME Content MIME Encoded Unencoded
Part# Type Encoding Size Size
----------------------------------------------------------------
1 text/plain 7bit 105 105
2 application/octet-stream base64 3324344 2429327

Nerenberg draft-nerenberg-imap-binary-01.txt draft-nerenberg-imap-binary-02.txt [Page 3] 4]

Internet Draft IMAP4 Binary Content Extension November 2000

If February 2001

First, the server does not know how to undo client requests the content transfer encod-
ing it issues a failure response: BODYSTRUCTURE:

C: 42 fetch 6 bodystructure
S: 1 NO [UNKNOWN-CONTENT-ENCODING] Unknown encoding for
message 1, part * 6 FETCH (BODYSTRUCTURE (("TEXT" "PLAIN" ("CHARSET" "us-ascii")
"<1070.981005923.1@localhost>" NIL "7BIT" 105 2

A BINARY fetch of NIL NIL NIL)
("APPLICATION" "OCTET-STREAM" NIL "<1070.981005923.2@localhost>"
"The latest BSD kernel" "BASE64" 3324344 NIL NIL NIL) "MIXED"
("BOUNDARY" "----- =_aaaaaaaaaa0") NIL NIL))
S: 42 OK FETCH completed

Next the multipart/report is illegal; it contains
nested MIME parts: client asks for the BINARYSTRUCTURE:

C: 2 43 fetch 1 binary[3] 6 binarystructure
S: * 6 FETCH (BINARYSTRUCTURE (("TEXT" "PLAIN" ("CHARSET" "us-ascii")
"<1070.981005923.1@localhost>" NIL "BINARY" 105 2 BAD Non-terminal part (3) requested in NIL NIL NIL)
("APPLICATION" "OCTET-STREAM" NIL "<1070.981005923.2@localhost>"
"The latest BSD kernel" "BINARY" 2429327 NIL NIL NIL) "MIXED"
("BOUNDARY" "----- =_aaaaaaaaaa0") NIL NIL))
S: 43 OK FETCH BINARY completed

Notice that the content transfer encoding for both sections has
changed to BINARY. The size for the second section has changed to
reflect the conversion of the BASE64 encoding for that section; the
size of the first section (both message 1 size and line count) has
not changed, since the transformation from 7BIT to BINARY did not
result in any change to the data.

For parts sections with no transparent content transfer encoding, encodings (7BIT,
8BIT, BINARY), FETCH BODY and FETCH BINARY return identical content: con-
tent:

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

Nerenberg draft-nerenberg-imap-binary-02.txt [Page 5]

Internet Draft IMAP4 Binary Content Extension February 2001

Here is a misbehaving client trying to retrieve a body the server
cannot decode:

C: 1 fetch 13 bodystructure
S: * 13 FETCH (BODYSTRUCTURE ("TEXT" "PLAIN" ("CHARSET"
"iso-8859-1") NIL NIL "FROBOZZ" 1716 49 NIL NIL NIL))
S: 1 OK Completed
C: 2 fetch 13 binarystructure
S: * 13 FETCH (BINARYSTRUCTURE ("TEXT" "PLAIN" ("CHARSET"
"iso-8859-1") NIL NIL NIL NIL NIL NIL NIL NIL))
S: 2 OK Completed
C: 3 fetch 13 binary[1]
S: 2 BAD [UNKNOWN-TRANSFER-ENCODING] Unknown content encoding
(FROBOZZ) for message 13 section 1

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 MUST ensure that non-encoded
non-binary textual line-oriented
body parts sections are always transmitted using the IMAP4 CRLF line termination ter-
mination syntax, regardless of the underlying storage rep-
resentation representa-
tion 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. situations. 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 data.

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].

append =/ "APPEND" SPACE mailbox [SPACE flag_list]
[SPACE date_time] SPACE literal8

BINCHAR ::= <0x00 - 0xff>

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

Nerenberg draft-nerenberg-imap-binary-02.txt [Page 6]

Internet Draft IMAP4 Binary Content Extension February 2001

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

resp_code_text =/ "UNKNOWN-TRANSPORT-ENCODING" "UNKNOWN-TRANSFER-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.
ACI/MessagingDirect
Suite 900
10117 - Jasper Avenue
Edmonton, Alberta
Canada T5J 1W8

Email: lyndon@messagingdirect.com

Nerenberg draft-nerenberg-imap-binary-01.txt draft-nerenberg-imap-binary-02.txt [Page 6] 7]

----