Interactive Mail Access Protocol: Version 3
RFC 1203

Document Type RFC - Historic (February 1991; No errata)
Obsoletes RFC 1064
Last updated 2013-03-02
Stream Legacy
Formats plain text pdf html bibtex
Stream Legacy state (None)
Consensus Boilerplate Unknown
RFC Editor Note (None)
IESG IESG state RFC 1203 (Historic)
Telechat date
Responsible AD (None)
Send notices to (None)
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                                                            [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 provides a very small increment in
   functionality over RFC 1064 but also adds a number of bugs, which
   would be detrimental to the IMAP cause.  Thus we propose the
   following definition for IMAP3.

Compatibility notes:

   In revising the IMAP2 protocol it has been our intent, wherever
   possible to make upwards compatible changes to produce IMAP3.  There
   were, however, some places that had to be changed incompatibly in
   order to compensate for either ambiguities in the IMAP2 protocol as
   defined by RFC 1064 or behavior that proved undesirable in the light
   of experience.

   It is our goal, however, that existing IMAP2 clients should still be
   supported and that, at least for the foreseeable future, all IMAP3
   servers will support IMAP2 behavior as their default mode.

   The following are the major differences between this proposal, RFC
   1176 and RFC 1064:

      - In this proposal we specify a difference between "solicited" and
        "unsolicited" data sent from the server.  It is generally the
        case that data sent by the server can be sent either in response
        to an explicit request by the client or by the server of its own
        volition.  Any data that the server is required to sent to the
        client as the result of a request is said to be solicited and
        carries the same tag as the request that provoked it.  Any data
        sent by the server to the client that is not required by the
        protocol is said to be unsolicited and carries the special "*"
Show full document text