RFC 1203 (rfc1203) - Page 2 of 49

Interactive Mail Access Protocol: Version 3

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 "*"
        tag.  RFC 1176 preserves the original RFC 1064 terminology that
        calls all such data sent by the server "unsolicited" even when



Rice