rfc1203.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 1,409 行 · 第 1/5 页

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



Rice                                                            [Page 2]

RFC 1203                         IMAP3                     February 1991


        it is, in fact, solicited.

      - This proposal introduces the experimental concept of
        distinguishing between Generic, Canonical and Concrete keys,
        allowing the mailbox to be viewed as a relational database
        indexed by these keys.  This should allow the IMAP protocol
        to evolve away from its current reliance on RFC 822.  RFC 1176
        does not have such a unifying model.

      - The SEARCH command has been changed so as to allow multiple
        simultaneous searches to be made and to allow unsolicited
        search messages to be sent by the server.  Such a change is
        essential to allow more sophisticated servers that can process
        commands asynchronously, possibly substantially delaying
        searches over slow backing storage media, for example.  It is
        also important to allow servers to be able to send unsolicited
        search messages that might inform the client of interesting
        patterns of messages, such as new and unseen mail.

      - This proposal introduces a specific protocol for the negotiation
        of protocol versions and server features.  This is important
        because it allows client/server pairs to come to an agreement on
        what behavior is really available to it.  RFC 1176 introduces a
        number of "optional" commands, which are in some way analogous
        to "feature-introduced" commands in this proposal.  The principle
        distinction between these is that in RFC 1176 there is no way
        for a client to discover the set of optional commands, nor is
        there a way for it to determine whether a specific command
        really is supported, since RFC 1176 requires the use of the
        "BAD" response if a feature is not supported.  There is,
        therefore, no way for the client to determine why the attempted
        command did not work.  This also means that, for example, a
        client cannot disable certain user commands or make them
        invisible on menus if they are not supported, since there
        is no way for the client to discover whether the commands are
        indeed supported without trying to execute such a command.

      - This proposal introduces a mechanism for clients to create and
        delete user flags (keywords).  This is nor supported in either
        RFC 1176 or RFC 1064, requiring the user to add keys manually
        on the server, generally by editing some form of "init" file.

      - RFC 1064 has no mechanism for determining whether a mailbox is
        readonly or not.  RFC 1176 introduces a non-enforced convention
        of encoding data about the readonly status of a mailbox in the
        SELECT message's OK respose comment field.  This is not regular
        with respect to the rest of the protocol, in which the comment
        field is used for no purpose other than documentation.  This



Rice                                                            [Page 3]

RFC 1203                         IMAP3                     February 1991


        proposal introduces specific protocol additions for the dynamic
        determination and modification of the readonly/readwrite status
        of mailboxes.

Introduction

   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.

   Although different in many ways from POP2 (RFC 937), IMAP3 may be
   thought of as a functional superset of POP2, and the POP2 RFC was
   used as a model for this RFC.  There was a cognizant reason for this;
   RFC 937 deals with an identical problem and it was desirable to offer
   a basis for comparison.

   Like POP2, IMAP3 specifies a means of accessing stored mail and not
   of posting mail; this function is handled by a mail transfer protocol
   such as SMTP (RFC 821).  A comparison with the DMSP protocol of
   PCMAIL can be found at the end of "System Model and Philosophy"
   section.

   This protocol assumes a reliable data stream such as provided by TCP
   or any similar protocol.  When TCP is used, the IMAP server listens
   on port 220.  When CHAOS is used the IMAP server listens for the
   logical contact name "IMAP3".

   Communication in IMAP is defined to be using the ASCII character
   interpretation of data.  Communication using other conventions may be
   possible by the selection of features on some servers.

System Model and Philosophy

   Electronic mail is a primary means of communication for the widely
   spread SUMEX-AIM community.  The advent of distributed workstations
   is forcing a significant rethinking of the mechanisms employed to
   manage such mail.  With mainframes, each user tends to receive and
   process mail at the computer he used most of the time, his "primary
   host".  The first inclination of many users when an independent
   workstation is placed in front of them is to begin receiving mail at
   the workstation, and, in fact, many vendors have implemented
   facilities to do this.  However, this approach has several
   disadvantages:

      (1)  Workstations (especially Lisp workstations) have a software
           design that gives full control of all aspects of the system
           to the user at the console.  As a result, background tasks,



Rice                                                            [Page 4]

RFC 1203                         IMAP3                     February 1991


           like receiving mail, could well be kept from running for
           long periods of time either because the user is asking to
           use all of the machine's resources, or because, in the course
           of working, the user has (perhaps accidentally) manipulated
           the environment in such a way as to prevent mail reception.
           This could lead to repeated failed delivery attempts by
           outside agents.

      (2)  The hardware failure of a single workstation could keep its
           user "off the air" for a considerable time, since repair of
           individual workstation units might be delayed.  Given the
           growing number of workstations spread throughout office
           environments, quick repair would not be assured, whereas a
           centralized mainframe is generally repaired very soon after
           failure.

      (3)  It is more difficult to keep track of mailing addresses when
           each person is associated with a distinct machine.  Consider
           the difficulty in keeping track of a large number of postal
           addresses or phone numbers, particularly if there was no
           single address or phone number for an organization through
           which you could reach any person in that organization.
           Traditionally, electronic mail on the ARPANET involved
           remembering a name and one of several "hosts" (machines)
           whose name reflected the organization in which the
           individual worked.  This was suitable at a time when most
           organizations had only one central host.  It is less
           satisfactory today unless the concept of a host is changed
           to refer to an organizational entity and not a particular
           machine.

      (4)  It is very difficult to keep a multitude of heterogeneous
           workstations working properly with complex mailing protocols,
           making it difficult to move forward as progress is made in
           electronic communication and as new standards emerge.  Each
           system has to worry about receiving incoming mail, routing
           and delivering outgoing mail, formatting, storing, and
           providing for the stability of mailboxes over a variety of
           possible filing and mailing protocols.

   Consequently, while the workstation may be viewed as an Internet host
   in the sense that it implements IP, it should not be viewed as the
   entity which contains the user's mailbox.  Rather, a mail server
   machine (sometimes called a "repository") should hold the mailbox,
   and the workstation (hereafter referred to as a "client") should
   access the mailbox via mail transactions.  Because the mail server
   machine would be isolated from direct user manipulation, it could
   achieve high software reliability easily, and, as a shared resource,



Rice                                                            [Page 5]