RFC 1203 (rfc1203) - Page 1 of 49

Interactive Mail Access Protocol: Version 3

Alternative Format: Original Text Document
Next >
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.

Scope

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