*DRAFT*DRAFT*DRAFT*DRAFT*DRAFT*DRAFT*DRAFT*DRAFT*DRAFT*DRAFT*DRAFT*DRAFT*





Network Working Group                                         M. Crispin
Request for Comments: ????                                    Washington
Extends: RFC 1176                                          December 1992


              IMAP2BIS -- EXTENSIONS TO THE IMAP2 PROTOCOL


Status of this Memo

   This RFC defines optional extensions to the IMAP2 procotol for
   multi-part textual and non-textual Internet messages as per the
   Internet DRAFT "MIME (Multipurpose Internet Mail Extensions):
   Mechanisms for Specifying and Describing the Format of Internet
   Message Bodies" by Borenstein and Freed.

   This document also defines several additional optional functional
   enhancements to IMAP2.

   [ ** Delete this note upon publication as an RFC **
    The extensions discussed in this document are experimental and
    subject to change.  It documents the state of these extensions
    as of December 1992.  It is distributed for informational purposes
    only.
     In particular, additions may be made to IMAP2bis in subsequent
    versions of this draft of the IMAP2bis document.  Persons planning
    on implementing these extensions are STRONGLY URGED to get in touch
    with the author before embarking on such a project.]

   The name of the resulting protocol is IMAP2bis.  IMAP2bis extends
   but does not obsolete the base protocol described in RFC-1176.  A
   few changes are made to the base protocol described in RFC-1176.
   It is believed that no existing implementations are affected by
   these changes; however, implementors may wish to verify that their
   IMAP2 implementations are IMAP2bis compatible.

   Although the IMAP2bis functional extensions are separable from each
   other based upon function, an RFC-1176 implementation is NOT IMAP2bis
   compliant (as opposed to IMAP2bis compatible) unless it implements
   ALL of the functional extensions and changes described here.

   Discussion and suggestions for improvement are requested.  Please
   refer to the current edition of the "IAB Official Protocol Standard"
   for the standardization state and status of this protocol.
   Distribution of this memo is unlimited.

   This specification does not purport to apply to the IMAP3 protocol
   described in RFC-1203.

Conventions

   Please refer to RFC-1176 for all conventions used in this document.


I.a. MIME Command Extensions

   tag FETCH sequence data

      The FETCH command is extended as follows:

      FULL             Macro equivalent to:
                      (FLAGS INTERNALDATE RFC822.SIZE ENVELOPE BODY)

      BODY            The body of the message.  The body is computed
                      by the server by parsing the RFC 822 header and
                      body into the component parts, defaulting various
                      fields as necessary.

      BODY[section]   The text of a particular body section.  The
                      section specification is a set of one or more
                      part numbers delimited by periods.

                      Single-part messages only have a part 1.

                      Multi-part messages as assigned consecutive
                      part numbers, as they occur in the message.
                      If a particular part is itself multi-part, its
                      parts must be indicated by a period followed by
                      that part number within that nested multi-part
                      part.  It is not permitted to fetch the text of
                      a nested multi-part part.

                      A part of type MESSAGE also has nested parts,
                      which are the parts of the MESSAGE part's body.

                      Every message has at least one part.

                      EXAMPLE: Here is a very complex message with its
                      associated section specifications.
                           1   TEXT
                           2   BINARY
                           3   MESSAGE
                           3.1   TEXT
                           3.2   BINARY
                               MULTIPART
                           4.1   IMAGE
                           4.2   MESSAGE
                           4.2.1   TEXT
                      Note that there is no section specification for
                      the Multi-part part itself.


I.b. MIME Response Extensions

   * number message_data

      FETCH data
              Data fetching is extended to add the following properties:

        BODY          An S-expression format list that describes the
                      body of a message.  The body is computed by the
                      server by parsing the RFC 822 header and body into
                      the component parts, defaulting various fields
                      as necessary.

                      Multiple parts are indicated by S-expression
                      nesting.  In this case, instead of a body type
                      as the first element of the list there is a nested
                      body.  The last element of the list is the multipart
                      subtype (mixed, digest, parallel, alternative, etc.).

                      The basic fields of a non-multipart body are in the
                      following order:
                        body type - an atom giving the content type name
                          as defined in MIME
                        body subtype - a string giving the content subtype
                          name as defined in MIME
                        body parameter list - an s-expression list of
                          attribute/value pairs [e.g. (foo bar baz rag)
                          where `bar' is the value of `foo' and `rag' is
                          the value of `baz'] as defined in MIME.
                        body id - a string giving the content id as
                          defined in MIME.
                        body description - a string giving the content
                          description as defined in MIME.
                        body encoding - a string giving the content
                          transfer encoding as defined in MIME.
                        body size - a number giving the size of that
                          body in bytes.  Note that this size is the
                          size in its transfer encoding and not the
                          resulting size.

                      A body type of type MESSAGE and subtype RFC822
                      contains, immediately after the basic fields,
                      the envelope of the encapsulated message, its
                      body structure, and its size in text lines.

                      A body type of type TEXT contains, immediately
                      after the basic fields, the size of the body
                      in text lines.

        BODY[section] A string expressing the body contents of the
                      specified section.  This string is transmitted
                      as 7-bit US-ASCII, encoded as according to MIME
                      content transfer encoding.  The string is
                      interpreted according to the content transfer
                      encoding and the body type and subtype.

                      Note that 7-bit US-ASCII is the transport format
                      and NOT necessarily the byte size or character
                      set of the result.  The resulting data may be
                      8-bit of some other character set or even binary!


II.a. Mailbox Management Command Extensions

   The following extensions are in the area of mailbox management.  They
   are intended to provide basic mailbox management services in a simple
   (single server) configuration.  Mailbox management in more complex
   environments is dealt with by a separate distributed management
   protocol.

   tag FIND MAILBOXES pattern

      The FIND MAILBOXES command as described in RFC-1176 is hereby
      more thoroughly defined.  This command returns the mailboxes
      that the user has declared as being "active" or "subscribed."

      The restriction that FIND MAILBOXES does not return the name
      INBOX is removed.  The name INBOX is returned by FIND MAILBOXES
      if that name has been subscribed (see SUBSCRIBE MAILBOX below).

      The functionality is otherwise unchanged.

      The exact meaning of this is implementation-dependent, since
      the concept of a set of `active' or `subscribed' mailboxes that
      is preserved across sessions may not be meaningful for a
      particular server or server implementation.  If the SUBSCRIBE
      MAILBOX and UNSUBSCRIBE MAILBOX commands are implemented then
      this command returns the list manipulated by those commands.

   tag FIND ALL.MAILBOXES pattern

      The FIND ALL.MAILBOXES command is similar to FIND MAILBOXES;
      however, it should return a complete list of all mailboxes
      available to the user.  Data is returned as in FIND MAILBOXES.

      The special name INBOX is included in the output from
      FIND ALL.MAILBOXES unless INBOX is not supported by this server
      or for this user.  The criteria for omitting INBOX is whether
      or not SELECT INBOX will return failure; it is not relevant
      whether or not the user's actual INBOX resides on this or some
      other server (see FIND MAILBOXES and SUBSCRIBE MAILBOX for a
      mechanism for the user to identify that this is the real INBOX).

      If FIND ALL.MAILBOXES is implemented FIND MAILBOXES must also
      be implemented, even if it returns the same information.  Also,
      FIND ALL.MAILBOXES must, at least, return all the mailbox names
      that are returned by FIND MAILBOXES.

      The exact meaning of this is implementation-dependent, since
      the concept of a bounded or deterministic set of `mailboxes
      available to the user' may not be meaningful for a particular
      server or server implementation.

   tag FIND BBOARDS pattern

      The FIND BBOARDS command as described in RFC-1176 is hereby
      more thoroughly defined.  This command returns the bboards
      that the user has declared as being "active" or "subscribed."
      The functionality is otherwise unchanged.

      The exact meaning of this is implementation-dependent, since
      the concept of a set of `active' or `subscribed' bboards that
      is preserved across sessions may not be meaningful for a
      particular server or server implementation.  If the SUBSCRIBE
      BBOARD and UNSUBSCRIBE BBOARD commands are implemented then
      this command returns the list manipulated by those commands.

   tag FIND ALL.BBOARDS pattern

      The FIND ALL.BBOARDS command is similar to FIND BBOARDS;
      however, it should return a complete list of all bulletin
      boards available to the user.  Data is returned as in
      FIND BBOARDS.

      If FIND ALL.BBOARDS is implemented FIND BBOARDS must also
      be implemented, even if it returns the same information.  Also,
      FIND ALL.BBOARDS must, at least, return all the bboard names
      that are returned by FIND BBOARDS.

      The exact meaning of this is implementation-dependent, since
      the concept of a bounded or deterministic set of `bboards
      available to the user' may not be meaningful for a particular
      server or server implementation.

   tag CREATE mailbox

      The CREATE command creates a mailbox with the given name.  This
      command returns an OK response only if a new mailbox with that
      name has been created.  It is an error to attempt to create a
      mailbox with a name that refers to an extant mailbox.  Any error
      in creation will return a NO response.

      Creating INBOX is not permitted.  If there is a primary or default
      mailbox for this user, it MUST exist and be called INBOX; hence it
      may not be created.  Otherwise, the name INBOX can not be used; see
      section VI, "INBOX Requirement Loosened", for more details.

   tag DELETE mailbox

      The DELETE command deletes a mailbox with the given name.  This
      command returns an OK response only if a mailbox with that name
      has been deleted.  It is an error to attempt to delete a mailbox
      name that does not exist.  Any error in deletion will return a
      NO response.

      A server SHOULD NOT attempt to test that a mailbox is empty prior
      to permitting deletion; this would prevent the deletion of a mailbox
      which for some reason can not be opened or expunged, leaving to
      possible denial of service problems.  Any such checking should be
      left to the discretion of the client.

      Deleting INBOX is not permitted.

   tag RENAME oldmailbox newmailbox

      The RENAME command changes the name of a mailbox.  This command
      returns an OK response only if a mailbox with the old name exists
      and has been successfully renamed to the new name.  It is an error
      to attempt to rename with an old mailbox name that does not exist
      or a new mailbox name which already exists.  Any error in renaming
      will return a NO response.

      Renaming INBOX is permitted.  A new, empty INBOX is created in its
      place.

   tag SUBSCRIBE MAILBOX mailbox

      The SUBSCRIBE MAILBOX command adds the specified mailbox name to
      the list of "active" or "subscribed" mailboxes as returned by
      the FIND MAILBOXES command.  This command returns an OK response
      only if the subscription is successful.

      If SUBSCRIBE MAILBOX is implemented then FIND MAILBOXES must also
      be implemented, and FIND ALL.MAILBOXES should be implemented.

      Subscriptions should be preserved between sessions.

   tag UNSUBSCRIBE MAILBOX mailbox

      The UNSUBSCRIBE MAILBOX command removes the specified mailbox name
      from the list of "active" or "subscribed" mailboxes as returned by
      the FIND MAILBOXES command.  This command returns an OK response
      only if the unsubscription is successful.

      If UNSUBSCRIBE MAILBOX is implemented then SUBSCRIBE MAILBOXES and
      FIND MAILBOXES must also be implemented, and FIND ALL.MAILBOXES
      should be implemented.

      Unsubscriptions should be preserved between sessions.

   tag SUBSCRIBE BBOARD bboard

      The SUBSCRIBE BBOARD command adds the specified mailbox name to
      the list of "active" or "subscribed" bulletin boards as returned
      by the FIND BBOARDS command.  This command returns an OK response
      only if the subscription is successful.

      If SUBSCRIBE BBOARD is implemented then FIND BBOARDS must also
      be implemented, and FIND ALL.BBOARDS should be implemented.

      Subscriptions should be preserved between sessions.

   tag UNSUBSCRIBE BBOARD bboard

      The UNSUBSCRIBE BBOARD command removes the specified mailbox name
      from the list of "active" or "subscribed" bulletin boards as
      returned by the FIND BBOARDS command.  This command returns an OK
      response only if the unsubscription is successful.

      If UNSUBSCRIBE BBOARD is implemented then SUBSCRIBE BBOARDS and
      FIND BBOARDS must also be implemented, and FIND ALL.BBOARDS
      should be implemented.

      Unsubscriptions should be preserved between sessions.


II.b. Mailbox Management Response Extensions

   No response extensions are made in the area of mailbox management.


III.a. Cache Management Command Extensions

   RFC-1176 specifies that a server is not obligated to transmit data
   in response to a FETCH command that it has already transmitted
   earlier in the session.  This can place an unreasonable burden on
   clients which lack the resources to maintain a local copy of the
   state transmitted by the server during this session.  To address
   this problem, the PURGE command has been defined.

   The previous exemption of texts made to this rule is hereby revoked
   and replaced with this new mechanism.

   Servers which refrain from sending data previously sent MUST implement
   the PURGE command.  Clients which do not cache all data sent from the
   server MUST implement the PURGE command.  It can be assumed that any
   server which returns BAD to any PURGE command does not exploit any
   caching at the client.

   As of this writing, the only exploitation of client caching by known
   server implementation is that some servers do not send EXISTS or
   RECENT updates in response to a CHECK command under certain
   circumstances.  The requirement that a client cache this information
   is unaffected by the new PURGE functionality.

   PURGE STATUS sequence

      The PURGE STATUS command informs the server that the client has
      deleted all information about the status (flags, internal date,
      and RFC-822 size) of the specified messages from its cache.

   PURGE STRUCTURE sequence

      The PURGE STRUCTURE command informs the server that the client has
      deleted all information about the structure (envelope and body)
      of the specified messages from its cache.

   PURGE TEXTS sequence

      The PURGE TEXTS command informs the server that the client has
      deleted all information about the texts (header, text, or body
      parts) of the specified messages from its cache.

   PURGE ALWAYS

      The PURGE ALWAYS command informs the server that the client has
      no capability to cache any data.  The server must re-send data
      whenever requested by the client.

      Note: PURGE ALWAYS does not affect information returned by the
      EXISTS and RECENT unsolicited responses.  Such information MUST
      be remembered by even a non-caching client, since there is NO
      guarantee that ANY command will return EXISTS or RECENT information
      on demand.

   PURGE token sequence

      Any unknown subcommand of PURGE should be rejected with a NO
      response instead of a BAD response.

III.b. Cache Management Response Extensions

   No response extensions are made in the area of cache management.


IV.a. Mailbox Append Command Extensions

   tag APPEND mailbox string

      The APPEND command appends the string, which is in the format
      of an RFC-822 message, to the specified mailbox.  If the append
      is unsuccessful for any reason the mailbox must be restored to
      its state prior to the append; no partial appending is permitted.

      Note that this functionality is unsuitable for message delivery,
      because it does not provide a mechanism to transfer RFC 821 (SMTP).
      envelope information.  Its primary purpose is to provide for a
      `saved outgoing mail' mailbox which resides on the remote server.


IV.b. Mailbox Append Response Extensions

   If the specified mailbox is open by a SELECT or BBOARD command, the
   normal new mail action should be taken.


V.a. Partial Text Fetching Command Extensions

   tag PARTIAL msgno RFC822 start_byte byte_count
   tag PARTIAL msgno RFC822.HEADER start_byte byte_count
   tag PARTIAL msgno RFC822.TEXT start_byte byte_count
   tag PARTIAL msgno BODY[section] start_byte byte_count

      The PARTIAL command is equivalent to the associated FETCH command,
      with the added functionality that only the specified number of
      bytes, beginning at the specified starting byte, are returned.
      Note as well that only a single message can be fetched at a time.
      The first byte of a message, and hence the minimum for the
      starting byte, is byte 1.

      Any partial fetch which attempts to read beyond the end of the
      text is truncated as appropriate.  If the starting byte is beyond
      the end of the text, an empty string is returned.

      The data is returned with the FETCH response.  There is no
      indication of the range of the partial data in this response; thus
      it is not possible to assume caching with PARTIAL data.  Any
      knowledge of caching from a FETCH command of that data is
      invalidated as with a PURGE command.  It is also not possible
      to stream multiple PARTIAL commands of the same data item without
      processing and synchronizing at each step, since each PARTIAL
      fetch of data replaces any prior (PARTIAL) FETCH of that data.

      Note that when partial fetching it is possible to break in the
      middle of a a line or a criticial sequence such as a BASE64
      quadruple or QUOTED-PRINTABLE shift.  Implementations using
      partial fetching should keep this in mind.  There is no requirement
      that partial fetches follow any sequence; so if it turns out that
      a partial fetch of bytes 1 through 10000 breaks in an awkward place,
      it is permitted to continue with a partial fetch of 9987 through
      19987, etc.

V.b. Partial Text Fetching Response Extensions

   No response extensions are made in the area of partial text fetching.


VI. INBOX Requirement Loosened

   RFC-1176 required all server implementations to make available a
   mailbox named "INBOX" on the server to be that user's primary mailbox
   on that server.  Examples have come up of shared mailbox or bulletin
   board only servers on which this requirement is unreasonable.

   The requirement is hereby modified as follows: SELECT's argument is
   implementation-dependent; however the word "INBOX" is reserved to
   mean a primary or default mailbox for this user, independent of any
   other server semantics.  It is permitted for a server not to have an
   INBOX if there is no concept of a primary or default mailbox for this
   user.  The name "INBOX" MUST NOT be used for any other purpose.


VII. Authentication Clarification

   RFC-1176 specifies that "until identity and access authorization have
   been established, no operations other than LOGIN or LOGOUT are
   permitted."  RFC-1176 specifies that authentication may be established
   through the LOGIN command, or may have "already been accomplished
   through other means, e.g. Kerberos."  RFC-1176 does not specify these
   "other means" or how they are done.

   Pre-authentication is only possible when the connection to the IMAP2
   service is made through some protocol other than a TCP connection to
   port 143 and this protocol provides its own authentication mechanism.

   Although RFC-1176 gives Kerberos as an example of an alternate means
   of authentication, it is not a good example of pre-authentication as
   Kerberos does not provide a connection service.  A better example of
   such a protocol is the BSD "RSH" protocol which provides authentication
   through a "trusted host" facility.  Another example would be of a
   manual invocation of an IMAP server from a logged-in timesharing job.

   A pre-authenticated IMAP server should recognize that authentication
   has already happened, and enter the post-login state.  In its greeting
   message, it should use the heretofore undocumented unsolicited reply
   "PREAUTH" instead of "OK" to indicate that external authentication has
   taken place.  For example, here is a pre-authentication scenario:

        S: * PREAUTH IMAP Server pre-authenticated as user `Smith'
        U: A001 SELECT INBOX
        S: * FLAGS (\Answered \Flagged \Deleted \Seen)
        S: * 19 EXISTS
        S: * 2 RECENT
        S: A001 OK SELECT complete

   While a connection that is not pre-authenticated is currently
   constrained to using the LOGIN command for establishing
   authentication, that does not mean that authentication systems such as
   Kerberos cannot be used.  While the examples show the "password"
   argument to the LOGIN as being a short string typed in by the user,
   this need not be the case.  If a server supports authentication via
   Kerberos version 4, it may accept the string "@KERBEROS:" followed by
   the hexadecimal representation of a Kerberos authenticator.

   For example, the following is a Kerberos login scenario (note that the
   line breaks in the sample authenticator are for editorial clarity and
   are not in a real authenticator):

   S: * OK Kerberos IMAP2 Server
   U: a001 LOGIN smith @KERBEROS:040700414e445245572e434d552e4544550
      038202c868f3890b377fc8266acc1bedb96b80d3fa76489898e74cd1c952dc
      4003ea3428f29f1c470016cf5adc22f939e6deff2747254c1815d5b0b90d4c
      5a2cba21eb0abe32f9acbf568d751bf4cc13f5ba4e6d82c638a8b5421
   S: a001 OK [df84a4cb8323454f] Login OK via Kerberos

   The token in the brackets in the OK response is the Kerberos
   authentication response, encrypted with the session key in network
   byte order and an incremented checksum as in the usual Kerberos
   procedure.


VIII. Change to the Syntax of Dates

   With the impending end of the century and the necessity of having a
   more general syntax for timezones than presently exists, the format
   of IMAP2 internal dates has become inadequate.

   The BNF for the date syntax is hereby amended to be:

   date            ::= date_new / date_old

   date_new        ::= string in form "dd-mmm-yyyy hh:mm:ss -zzzz"

   date_old        ::= string in form "dd-mmm-yy hh:mm:ss-zzz"

   In date_new, the year is now a 4-digit year, and the timezone is a
   signed four-digit value of hhmm representing hours and minutes west
   of Greenwich (that is, the amount that the given time differs from
   Universal Time).  Subtracting the timezone from the given time will
   give the UT form.

   Universal Time is expressed as "+0000".

   date_old is hereby declared obsolete, and its usage in new software
   is STRONGLY discouraged.  However, client implementations MUST
   recognize and properly parse it.

   RFC-1176 documents the argument to the SEARCH criteria BEFORE, ON, and
   SINCE as being either "date" in the text and "string" in the BNF.
   These SEARCH criteria arguments are hereby amended to be "day", with
   the following syntax:

   day             ::= day_new / day_old

   day_new         ::= string in form "dd-mmm-yyyy"

   day_old         ::= string in form "dd-mmm-yy"

   day_old is hereby declared obsolete, and its usage in new software
   is STRONGLY discouraged.  However, server implementations MUST
   recognize and properly parse it.


IX. COPY Command and the Unsolicited COPY Response

   RFC-1176 specifies that if the destination mailbox specified by a COPY
   command does not exist, the server should create it.  With the advent
   of the CREATE command, it is intended that this functionality will
   eventually be deprecated.  Server implementations SHOULD continue to
   create new mailboxes as needed with a COPY command, but SHOULD also
   note to the user at the client, via an unsolicited OK response, that a
   new mailbox was created.

   An unsolicited COPY response is mentioned in RFC-1176's documentation
   of the COPY command, and in the BNF, but is not otherwise documented.
   This response was intended to provide status of a COPY command, and
   indicate how much of the COPY was done in the event of a COPY which
   failed midway.

   This response was not implemented by many servers.  The definition of
   the COPY command is hereby amended to REQUIRE that a COPY fully
   complete the requested operation.  If this is not possible, then COPY
   should do NONE of the requested operation, and back out of any partial
   COPY as necessary.  This eliminates the ambiguity.

   The unsolicited COPY response is hereby declared obsolete.  It MUST
   NOT be used in new server implementations.  Clients should ignore any
   unsolicited COPY responses seen.


X. Reiteration on the Unsolicited STORE Response

   Some server implementations return an unsolicted STORE response as a
   result of a change caused by a STORE.  This was referenced in passing in
   RFC-1064, but had already become obsolete.  The correct behavior is to
   return an unsolicited FETCH response for both a FETCH and a STORE.

   As stated in RFC-1176, the unsolicited STORE response is obsolete.  It
   MUST NOT be used in new server implementations.  Clients SHOULD treat any
   unsolicited STORE responses as equivalent to unsolicited FETCH.


XI. Anonymous Convention Established

   Some servers may wish to allow non-authenticated access to certain
   mailboxes or bulletin boards.  The means by which this is accomplished
   is with a LOGIN command using a userid of "anonymous".  A password is
   still required; it is implementation-dependent what requirements, if
   any, are placed upon the password.  It is also implementation-dependent
   what access restrictions are placed on anonymous users.

   Since this is a convention, and not strictly a protocol extension or
   change, implementations are NOT required to support the anonymous
   convention in order to be considered IMAP2bis compliant.


XII. Clarification of RFC822.HEADER

   RFC-1176 states that the concatenation of the strings returned by
   fetching RFC822.HEADER and RFC822.TEXT is equivalent to the string
   returned by fetching RFC822.  It was implicit that the delimiting
   blank line would be included in RFC822.HEADER, because otherwise
   there would be a leading blank line in RFC822.TEXT, but never
   explicitly stated.

   The string returned by RFC822.HEADER includes the empty line that
   delimits the header from the text in RFC-822.  In other words, all
   non-null RFC822.HEADER strings end with a sequence of four ASCII
   bytes: CR LF CR LF (0C 0A 0C 0A).


XIII. SEARCH string extension

   The BODY and TEXT qualifiers in the SEARCH are hereby extended to
   permit an RFC-1342 format multinational character string.  Due to
   compatibility constraints, RFC-1432 format strings must be quoted.
   For example:
     SEARCH TEXT "=?US-ASCII?Q?leaping lizards?="
   and
     SEARCH TEXT "leaping lizards"
   are equivalent.


Formal Syntax

   The syntax of RFC-1176 is extended with the following rules.  Where
   a rule is already defined in RFC-1176, this rule replaces it.

   The following syntax specification uses the augmented Backus-Naur
   Form (BNF) notation as specified in RFC 822 with one exception; the
   delimiter used with the "#" construct is a single space (SP) and not
   a comma.

   append          ::= "APPEND" SP mailbox SP string

   body            ::= "(" body_structure ")"

   body_basic      ::= body_type SP body_subtype SP body_parameter SP
                       body_id SP body_description SP body_encoding SP
                       body_size_byte

   body_description::= nil / string

   body_encoding   ::= "7BIT" / "8BIT" / "BINARY" / "BASE64"/
                       "QUOTEDPRINTABLE" / "X-UNKNOWN"

   body_id         ::= nil / string

   body_msg        ::= body_basic SP envelope SP body

   body_parameter  ::= nil / string

   body_section    ::= NUMBER / NUMBER "." body_section

   body_size_byte  ::= NUMBER

   body_size_line  ::= NUMBER

   body_structure  ::= body_basic / body_msg / body_text /
                       1#body_structure SP body_subtype

   body_subtype    ::= nil / string

   body_text       ::= body_basic SP body_size_line

   body_type       ::= "TEXT" / "MULTIPART" / "MESSAGE" / "APPLICATION" /
                       "AUDIO" / "IMAGE" / "VIDEO" / "X-UNKNOWN"

   create          ::= "CREATE" SP mailbox

   date            ::= date_new / date_old

   date_new        ::= string in form "dd-mmm-yyyy hh:mm:ss -zzzz"

   date_old        ::= string in form "dd-mmm-yy hh:mm:ss-zzz" ;; obsolete

   day             ::= day_new / day_old

   day_new         ::= string in form "dd-mmm-yyyy"

   day_old         ::= string in form "dd-mmm-yy" ;; obsolete

   delete          ::= "DELETE" SP mailbox

   fetch           ::= "FETCH" SP sequence SP ("ALL" / "FULL" /
                       "FAST" / fetch_att / "(" 1#fetch_att ")")

   fetch_att       ::= fetch_att_other / fetch_att_text

   fetch_att_other ::= "BODY" / "ENVELOPE" / "FLAGS" / "INTERNALDATE" /
                       "RFC822.SIZE"

   fetch_att_text  ::= "BODY[" body_section "]" / "RFC822" /
                       "RFC822.HEADER" / "RFC822.TEXT"

   find_option     ::= "MAILBOXES" / "BBOARDS" / "ALL.MAILBOXES" /
                       "ALL.BBOARDS"

   istring         ::= string / RFC-1342 format multinational string

   msg_copy        ::= "COPY" ;; obsolete

   msg_data        ::= msg_exists / msg_recent / msg_expunge /
                       msg_fetch / msg_copy / msg_store

   msg_fetch       ::= "FETCH" SP "(" 1#("BODY" SP body /
                       "BODY[" body_section "]" string / "ENVELOPE" SP
                       envelope / "FLAGS" SP "(" 1#(recent_flag
                       flag_list) ")" / "INTERNALDATE" SP date /
                       "RFC822" SP string / "RFC822.HEADER" SP string /
                       "RFC822.SIZE" SP NUMBER / "RFC822.TEXT" SP
                       string) ")"

   msg_store       ::= "STORE" SP "(" 1#("FLAGS" SP "(" 1#(recent_flag
                       flag_list) ")" ) ")" ;; obsolete

   partial         ::= "PARTIAL" SP NUMBER SP fetch_att_text SP NUMBER SP
                       NUMBER

   purge           ::= "PURGE" SP ("ALWAYS" / purge_option SP sequence)

   purge_option    ::= "STATUS" / "STRUCTURE" / "TEXTS" / token

   rename          ::= "RENAME" SP mailbox SP string

   search          ::= "SEARCH" SP 1#("ALL" / "ANSWERED" /
                       "BCC" SP string / "BEFORE" SP day /
                       "BODY" SP istring / "CC" SP string / "DELETED" /
                       "FLAGGED" / "KEYWORD" SP atom / "NEW" / "OLD" /
                       "ON" SP day / "RECENT" / "SEEN" /
                       "SINCE" SP day / "TEXT" SP istring /
                       "TO" SP string / "UNANSWERED" / "UNDELETED" /
                       "UNFLAGGED" / "UNKEYWORD" / "UNSEEN")

   subscribe       ::= "SUBSCRIBE" SP subscribe_opt SP string

   subscribe_opt   ::= "MAILBOX" / "BBOARD"

   unsubscribe     ::= "UNSUBSCRIBE" SP subscribe_opt SP string

   userid          ::= string / "anonymous"


Implementation Status

   The University of Washington IMAP2bis distribution supports this
   specification.  It can be obtained as mail/imap.tar.Z via anonymous
   FTP from host ftp.cac.washington.edu; this is a compressed UNIX `tar'
   format file.

   The University of Washington IMAP2bis distribution includes external
   authentication using the Unix r-protocols.  Sites can enable or
   disable rimap at their discretion; users can control rimap behavior
   (provided the site has enabled it) by use of the standard .rhosts
   and hosts.equiv files.  The anonymous convention is also included
   for anonymous access to newsgroups is can also be enabled or disabled
   on a site basis.

   A Kerberized IMAP2bis is in test at a few organizations, but is not yet
   available for public release.


Design Discussion

   IMAP2 as specified in RFC-1176 is a 7-bit protocol.  These extensions
   make it possible to support 8-bit textual and binary mail through the
   IMAP mode.

   Some thought was made on whether or not the body contents fetch should
   return the decoded version of BASE64 and QUOTED-PRINTABLE sections, or
   if there should be an option to get either the encoded or the decoded
   form.  It was rejected on these grounds:
    1) It makes the extensions unimplementable in any environment where
       an 8-bit data stream is not possible.
    2) It creates multiple ways of doing the same thing and hence
       exponentially multiplies the possiblity of non-interoperable
       implementations.
    3) It introduces binary in the same data stream as commands, and
       hence makes the protocol more vulnerable to synchronization
       problems.

   If server-based decoding of BASE64 and QUOTED-PRINTABLE turns out
   to be important, it should be transmitted out of band from the IMAP2
   command stream.  This would have the necessary but unfortunate effect
   of making the protcol more complicated.


Unresolved issues

   The following issues are unresolved by IMAP2bis.  It is anticipated that
   these will be dealt with in future specifications.

   The management capabilities of IMAP2bis are inadequate for complex
   distributed mail configurations.  A separate specification, under
   development at CMU, addresses this.

   The SEARCH command lacks MIME awareness, regular expressions, complex
   logical qualifiers, etc.  This should be addressed in future versions of
   the IMAP2 specification.

   It isn't clear that the RFC-1342 extensions to SEARCH are adequate for
   the task.

   Message posting is orthogonal to the scope of a mail access protocol, and
   it is undesirable for a number of reasons to shoehorn the two into a
   single protocol.  However, issues of authentication and what to do with a
   uni-channel link (e.g. IMAP over a dialup line) have come up.  The
   IETF-REMMAIL working group is wrestling with these issues at this writing.

   Envelopes do not carry information such as resend data, newsgroups,
   etc.  Newsgroups can probably be encoded within the existing address list
   syntax.

   The question has come up as to whether or not there should be a way for
   the server to build client browser lines.


Acknowledgements

   Special thanks go to John Gardiner Myers, Chris Newman, Karl Jacob, Hisao
   Nojima, Terry Gray, Adam Treister, Laurence Lundblade, and Mike Seibel for
   their hard work in reviewing the present status of IMAP2, and for reaching
   concensus and closure on a number of issues in record time.

   My thanks to everyone in the IETF-822 group for their hard work in
   getting the Internet Message Bodies draft out the door, and
   especially to Nathaniel Borenstein and Ned Freed for putting together
   something we could all live with.

   Any mistakes, flaws, or sins of omission in this IMAP2bis protocol
   extension are, however, strictly my own; and no endorsement on the
   part of anyone is implied.


Security Considerations

   Security issues are discussed in this memo only as far as authentication
   for the purpose of accessing an IMAP2bis server are concerned.


Author's Address

   Mark R. Crispin
   Networks and Distributed Computing
   University of Washington
   Seattle, WA  98105

   Phone: (206) 842-2385

   EMail: MRC@CAC.Washington.EDU
