Interactive Mail Access Protocol: Version 3 (RFC1203)
Original Publication Date: 1991-Feb-01
Included in the Prior Art Database: 2000-Sep-12
Internet Society Requests For Comment (RFCs)
The intent of the Interactive Mail Access Protocol, Version 3 (IMAP3) is to allow a (possibly unreliable) workstation or similar machine to access electronic mail from a reliable mailbox server in an efficient manner.
Network Working Group J. Rice
Request for Comments: 1203 Stanford
Obsoletes: RFC 1064 February 1991
INTERACTIVE MAIL ACCESS PROTOCOL - VERSION 3
Status of this Memo
This RFC suggests a method for workstations to access mail
dynamically from a mailbox server ("repository"). This RFC specifies
a standard for the SUMEX-AIM community and 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.
The following document is a modified version of RFC 1064, the
definition of the IMAP2 protocol. This RFC has been written
specifically as a counter proposal to RFC 1176, which itself proposes
modifications to IMAP2. Sadly, RFC 1176 was made without internal
consultation with the IMAP community, so we are in a position of
feeling we have to present a counter proposal to what, if we do not
act, will become a de facto standard. The reasons for this counter
proposal are numerous but fall mostly into the following categories:
- IMAP2 is insufficiently powerful for a number of server/client
interactions which we believe to be important. RFC 1176
negligibly enhances the functionality of IMAP2.
- IMAP2 makes what we believe to be an erroneous definition for
unsolicited vs. solicited data. IMAP3 as specified herein
attempts to correct this. RFC 1176 makes no effort to remedy
- RFC 1176 has explicitly modified the intent of RFC 1064 by
allowing the server to make assumptions about the client's
caching architecture. We believe this to be a grave error
and do not support it in this proposal.
- RFC 1176 specifies a number of "optional" features in the
protocol without specifying a suitable metaprotocol by which
servers and clients can adequately negotiate over the set of
implemented features. This proposal specifies a mechanism
by which servers and clients can come to an unambiguous
understanding about which features are usable by each party.
- RFC 1176 pays only lip-service to being network protocol
independent and, in fact assumes the use of TCP/IP. Neither
RFC 1064 nor this proposal make any such assumption.
Although there are numerous other detailed objections to RFC 1176, we
believe that the above ...