I've written up some specifications for extensions to the IMAP2 protocol
(described in RFC-1176) to cover RFC-XXXX. There isn't a completely perfect
fit, but I believe that I have more or less the function of RFC-XXXX covered.
If anyone here is interested in IMAP I would appreciate comments or at least a
sanity check on this specification.
*DRAFT*DRAFT*DRAFT*DRAFT*DRAFT*DRAFT*DRAFT*DRAFT*DRAFT*DRAFT*DRAFT*DRAFT*
Network Working Group M. Crispin
Request for Comments: ???? Washington
Extends: RFC 1176 July 1991
INTERNET MESSAGE BODY EXTENSIONS TO IMAP2
Status of this Memo
This RFC defines an optional extension to the IMAP2 procotol for
multi-part textual and non-textual Internet messages as per the
Internet DRAFT "Mechanisms for Specifying and Describing the Format
of Internet Message Bodies" by Borenstein and Freed. It extends
but does not obsolete RFC 1176. This RFC also clarifies the question
of authentication in IMAP2.
This RFC specifies an Experimental Protocol for the Internet
community. Discussion and suggestions for improvement are requested.
Please refer to the current edition of the "IAB Official Protocol
Standards" for the standardization state and status of this protocol.
Distribution of this memo is unlimited.
This specification does not purport to apply to the IMAP3 protocol
described in RFC-1203.
Conventions
Please refer to RFC-1176 for all conventions used in this document.
Authentication
RFC-1176 requires authentication, although it only specifies a LOGIN
command, which has the undesirable attribute of sending passwords over
the network in plaintext. As noted on page 6 of RFC-1176, a LOGIN
command is required "unless...[authentication] has already been
accomplished through other means, e.g. Kerberos." RFC-1176 does not
specify how this should be done.
It is the intent of the IMAP2 specification not to specify how any
particular authentication mechanism is to work. That rightfully
belongs in the specification of the authentication mechanism. It is
envisioned, but not required, that an externally-authenticated IMAP2
server not be started until authentication has been completed, and
that the IMAP2 server recognize that authentication has already
happened and immediately enter the post-login state.
In the case of Kerberos, it is intended that IMAP2 should be
Kerberized exactly as FTP has been.
Command extensions
tag FETCH sequence data
The FETCH command is extended as follows:
ALL.BODY Macro equivalent to:
(FLAGS INTERNALDATE RFC822.SIZE ENVELOPE BODY)
BODY The body of the message. The body is computed
computed by the server by parsing the RFC 822
header and body into the component parts,
defaulting various fields as necessary.
BODY[section] The text of a particular body section. The
section specification is a set of one or more
part numbers delimited by periods.
Single-part messages only have a part 1.
Multi-part messages as assigned consecutive
part numbers, as they occur in the message.
If a particular part is itself multi-part, its
parts must be indicated by a period followed by
that part number within that nested multi-part
part. It is not permitted to fetch the text of
a nested multi-part part.
A part of type MESSAGE also has nested parts,
which are the parts of the MESSAGE part's body.
Every message has at least one part.
EXAMPLE: Here is a very complex message with its
associated section specifications.
1 TEXT
2 BINARY
3 MESSAGE
3.1 TEXT
3.2 BINARY
MULTIPART
4.1 IMAGE
4.2 MESSAGE
4.2.1 TEXT
Note that there is no section specification for
the Multi-part part itself.
Response Extensions
* number message_data
FETCH data
Data fetching is extended to add the following properties:
BODY An S-expression format list that describes the
body of a message. The body is computed by the
server by parsing the RFC 822 header and body into
the component parts, defaulting various fields
as necessary.
Multiple parts are indicated by S-expression
nesting.
The basic fields of the body are in the following
order: body type, body subtype, body parameter
list, body id, body description. Body type is an
atom; the others are strings.
Body types that convey data (presently, all those
other than type APPLICATION) contain, immediately
following the basic fields, the body encoding (an
atom), and the size of the body contents in bytes.
A body type of type MESSAGE contains, immediately
after the data fields, the envelope of the
encapsulated message and its body structure.
A body type of type TEXT or TEXT-PLUS contains,
immediately after the data fields, the size of
the body contents in text lines.
BODY[section] A string expressing the body contents of the
specified section.
Formal Syntax
The syntax of RFC-1176 is extended with the following rules. Where
a rule is already defined in RFC-1176, this rule replaces it.
The following syntax specification uses the augmented Backus-Naur
Form (BNF) notation as specified in RFC 822 with one exception; the
delimiter used with the "#" construct is a single space (SP) and not
a comma.
body ::= "(" (body_basic / body_basic SP body_extended) ")"
body_basic ::= body_type SP body_subtype SP body_parameter SP
body_id SP body_description
body_data ::= body_encoding SP body_size_byte
body_data_msg ::= body_data SP envelope SP body
body_data_text ::= body_data SP body_size_line
body_encoding ::= "7BIT" / "8BIT" / "BINARY" / "BASE64"/
"QUOTEDPRINTABLE" / "X-UNKNOWN"
body_extended ::= body_data / body_data_text / body_data_msg
body_description::= nil / string
body_id ::= nil / string
body_parameter ::= nil / string
body_section ::= NUMBER / NUMBER "." body_section
body_size_byte ::= NUMBER
body_size_line ::= NUMBER
body_subtype ::= nil / string
body_type ::= "TEXT" / "MULTIPART" / "TEXT-PLUS" / "MESSAGE" /
"BINARY" / "APPLICATION" / "AUDIO" / "IMAGE" /
"VIDEO" / "X-UNKNOWN"
fetch ::= "FETCH" SP sequence SP ("ALL" / "ALL.BODY" /
"FAST" / fetch_att / "(" 1#fetch_att ")")
fetch_att ::= "BODY" / "BODY[" body_section "]" / "ENVELOPE" /
"FLAGS" / "INTERNALDATE" / "RFC822" /
"RFC822.HEADER" / "RFC822.SIZE" / "RFC822.TEXT"
msg_fetch ::= ("FETCH" / "STORE") SP "(" 1#("BODY" SP body /
"BODY[" body_section "]" string / "ENVELOPE" SP
envelope / "FLAGS" SP "(" 1#(recent_flag
flag_list) ")" / "INTERNALDATE" SP date /
"RFC822" SP string / "RFC822.HEADER" SP string /
"RFC822.SIZE" SP NUMBER / "RFC822.TEXT" SP
string) ")"
Implementation Status
The University of Washington IMAP2 distribution fully supports this
specification as of the August 1991 release. Refer to RFC-1176 for
more information about this and other IMAP2 implementations.
A Kerberized IMAP2 is in test at a few organizations, but is not yet
available for public release.
Design Discussion
IMAP2 as specified in RFC-1176 is a 7-bit protocol. These extensions
make it possible to support 8-bit textual and binary mail through the
IMAP mode and offers the possibility of retiring the RFC822* fetch
attributes in the future.
Some thought was made on whether or not the body contents fetch should
return the decoded version of BASE64 and QUOTED-PRINTABLE sections, or
if there should be an option to get either the encoded or the decoded
form. I eventually decided against it on these grounds:
1) It makes the extensions unimplementable in any environment where
an 8-bit data stream is not possible.
2) It creates multiple ways of doing the same thing and hence
exponentially multiplies the possiblity of non-interoperable
implementations.
3) It introduces binary in the same data stream as commands, and
hence makes the protocol more vulnerable to synchronization
problems.
If server-based decoding of BASE64 and QUOTED-PRINTABLE turns out
to be important, I feel it should be transmitted out of band from
the IMAP command stream. This would have the necessary but
unfortunate effect of making the protcol more complicated.
Acknowledgements
My thanks to everyone in the IETF-822 group for their hard work in
getting the Internet Message Bodies draft out the door, and
especially to Nathaniel Borenstein and Ned Freed for putting together
something we could all live with.
Any mistakes, flaws, or sins of omission in this IMAP2 protocol
extension are, however, strictly my own; and no endorsement on the
part of anyone is implied.
Security Considerations
Security issues are not discussed in this memo.
Author's Address
Mark R. Crispin
Panda Programming
6158 Lariat Loop NE
Bainbridge Island, WA 98110-2098
Phone: (206) 842-2385
EMail: MRC(_at_)CAC(_dot_)Washington(_dot_)EDU