[Top] [All Lists]

RFC-XXXX extensions to the IMAP2 protocol (RFC-1176)

1991-07-30 13:32:07
I've written up some specifications for extensions to the IMAP2 protocol
(described in RFC-1176) to cover RFC-XXXX.  There isn't a completely perfect
fit, but I believe that I have more or less the function of RFC-XXXX covered.
If anyone here is interested in IMAP I would appreciate comments or at least a
sanity check on this specification.


Network Working Group                                         M. Crispin
Request for Comments: ????                                    Washington
Extends: RFC 1176                                              July 1991


Status of this Memo

   This RFC defines an optional extension to the IMAP2 procotol for
   multi-part textual and non-textual Internet messages as per the
   Internet DRAFT "Mechanisms for Specifying and Describing the Format
   of Internet Message Bodies" by Borenstein and Freed.  It extends
   but does not obsolete RFC 1176.  This RFC also clarifies the question
   of authentication in IMAP2.

   This RFC specifies 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.

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


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


   RFC-1176 requires authentication, although it only specifies a LOGIN
   command, which has the undesirable attribute of sending passwords over
   the network in plaintext.  As noted on page 6 of RFC-1176, a LOGIN
   command is required "unless...[authentication] has already been
   accomplished through other means, e.g. Kerberos."  RFC-1176 does not
   specify how this should be done.

   It is the intent of the IMAP2 specification not to specify how any
   particular authentication mechanism is to work.  That rightfully
   belongs in the specification of the authentication mechanism.  It is
   envisioned, but not required, that an externally-authenticated IMAP2
   server not be started until authentication has been completed, and
   that the IMAP2 server recognize that authentication has already
   happened and immediately enter the post-login state.

   In the case of Kerberos, it is intended that IMAP2 should be
   Kerberized exactly as FTP has been.

Command extensions

   tag FETCH sequence data

      The FETCH command is extended as follows:

      ALL.BODY        Macro equivalent to:

      BODY            The body of the message.  The body is computed
                      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
                           4.1   IMAGE
                           4.2   MESSAGE
                           4.2.1   TEXT
                      Note that there is no section specification for
                      the Multi-part part itself.

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

                      The basic fields of the body are in the following
                      order: body type, body subtype, body parameter
                      list, body id, body description.  Body type is an
                      atom; the others are strings.

                      Body types that convey data (presently, all those
                      other than type APPLICATION) contain, immediately
                      following the basic fields, the body encoding (an
                      atom), and the size of the body contents in bytes.

                      A body type of type MESSAGE contains, immediately
                      after the data fields, the envelope of the
                      encapsulated message and its body structure.

                      A body type of type TEXT or TEXT-PLUS contains,
                      immediately after the data fields, the size of
                      the body contents in text lines.

        BODY[section] A string expressing the body contents of the
                      specified section.

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.

   body            ::= "(" (body_basic / body_basic SP body_extended) ")"

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

   body_data       ::= body_encoding SP body_size_byte

   body_data_msg   ::= body_data SP envelope SP body

   body_data_text  ::= body_data SP body_size_line

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

   body_extended   ::= body_data / body_data_text / body_data_msg

   body_description::= nil / string

   body_id         ::= nil / string

   body_parameter  ::= nil / string

   body_section    ::= NUMBER / NUMBER "." body_section

   body_size_byte  ::= NUMBER

   body_size_line  ::= NUMBER

   body_subtype    ::= nil / string

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

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

   fetch_att       ::= "BODY" / "BODY[" body_section "]" / "ENVELOPE" /
                       "FLAGS" / "INTERNALDATE" / "RFC822" /
                       "RFC822.HEADER" / "RFC822.SIZE" / "RFC822.TEXT"

   msg_fetch       ::= ("FETCH" / "STORE") 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) ")"

Implementation Status

   The University of Washington IMAP2 distribution fully supports this
   specification as of the August 1991 release.  Refer to RFC-1176 for
   more information about this and other IMAP2 implementations.

   A Kerberized IMAP2 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 and offers the possibility of retiring the RFC822* fetch
   attributes in the future.

   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.  I eventually decided against it 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
    3) It introduces binary in the same data stream as commands, and
       hence makes the protocol more vulnerable to synchronization

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


   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 IMAP2 protocol
   extension are, however, strictly my own; and no endorsement on the
   part of anyone is implied.

Security Considerations

   Security issues are not discussed in this memo.

Author's Address

   Mark R. Crispin
   Panda Programming
   6158 Lariat Loop NE
   Bainbridge Island, WA 98110-2098

   Phone: (206) 842-2385

   EMail: MRC(_at_)CAC(_dot_)Washington(_dot_)EDU

<Prev in Thread] Current Thread [Next in Thread>
  • RFC-XXXX extensions to the IMAP2 protocol (RFC-1176), Mark Crispin <=