Browse Prior Art Database

Interactive Mail Access Protocol: Version 3 (RFC1203) Disclosure Number: IPCOM000002017D
Original Publication Date: 1991-Feb-01
Included in the Prior Art Database: 2000-Sep-12

Publishing Venue

Internet Society Requests For Comment (RFCs)

Related People



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.

This text was extracted from a ASCII document.
This is the abbreviated version, containing approximately 2% of the total text.

Network Working Group J. Rice

Request for Comments: 1203 Stanford

Obsoletes: RFC 1064 February 1991


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.

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