Interactive Mail Access Protocol: Version 3 (RFC1203)
Original Publication Date: 1991-Feb-01
Included in the Prior Art Database: 2019-Feb-11
Internet Society Requests For Comment (RFCs)
This RFC suggests a method for workstations to access mail dynamically from a mailbox server ("repository"). The following document is a modified version of RFC 1064, the definition of the IMAP2 protocol. This RFC specifies an Experimental Protocol for the Internet community. It does not specify any standard.
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 these problems.
- 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.
Rice [Page 1]
RFC 1203 IMAP3 February 1991
- 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 will serve to show that we believe strongly in the importance of mailbox abstraction level mail protocols and, after a couple of years of use of IMAP2 under RFC 1064 we believe that we have a good enough understanding of the issues involved to be able to take the next step.
It is important to take this next step because of the rapid pace of both mail system and user interface development. We believe that, for IMAP not to die in its infancy, IMAP must be ready to respond to emerging ISO and RFC standards in mail, such as for multi-media mail. We believe that RFC 1176 not only provide...