Re: Request for IMAP4rev1 to Proposed Standard

[Terry Gray <[e-mail]>]

> Terry,
> could you summarize the changes from RFC 1730 to this draft?
> I'll glance through the document and send it in for Last Call asap
> - it'll have to be a 4-week Last Call since it hasn't been reviewed
> by a formal IETF working group.

Thanks Harald.  Be happy to.  Below are two sections: the first provides
the background and primary drivers for making the Rev1 spec.  The second
is the appendix from the draft that enumerates all of the changes. 

-teg


-------------------------------------------------------------------------
BACKGROUND ON IMAP4rev1 CHANGES
-------------------------------------------------------------------------

At the IMAP meeting UW hosted in January, there was consensus that
the base protocol spec should be updated for two primary reasons:

 1. A problem was discovered with the PARTIAL primitive: namely,
    that partial responses were indistinguishable from full responses,
    so that a client wouldn't know how to update its cache if a
    PARTIAL command were ever used.

 2. IMAP as defined in 1730 is in conflict with the Multipart/Signed
    MIME type defined in RFC-1847.  The latter requires that a
    signature verification be computed over the MIME headers as
    well as body content, but IMAP did not provide a way to fetch
    the original MIME headers.

Since 1847 came after 1730, this wasn't an indictment of IMAP, but
everyone agreed that secure email is important and this needed to get
fixed.

The result was a more general fetch syntax that allowed for getting MIME
headers as well as body parts, and also allowed obsoleting some
special-case constructs.  At the same time, there was sentiment for adding
one proposed extension to the base spec (a "no brainer" called STATUS),
plus recognition of a couple of new MIME headers, and there were a bunch
of clarifications.  Also, the obsolete syntax section and some
compatibility info was moved into separate (informational) documents to
streamline the base spec.


-------------------------------------------------------------------------
ENUMERATION OF IMAP4rev1 CHANGES (from draft-crispin-imap-base-04.txt)
-------------------------------------------------------------------------

INTERNET DRAFT                   IMAP4                        April 1996


B.      Changes from RFC 1730


   1) The STATUS command has been added.

   2) Clarify in the formal syntax that the "#" construct can never
   refer to multiple spaces.

   3) Obsolete syntax has been moved to a separate document.

   4) The PARTIAL command has been obsoleted.

   5) The RFC822.HEADER.LINES, RFC822.HEADER.LINES.NOT, RFC822.PEEK, and
   RFC822.TEXT.PEEK fetch attributes have been obsoleted.

   6) The "<" origin "." size ">" suffix for BODY text attributes has
   been added.

   7) The HEADER, HEADER.FIELDS, HEADER.FIELDS.NOT, MIME, and TEXT part
   specifiers have been added.

   8) Support for Content-Disposition and Content-Language has been
   added.

   9) The restriction on fetching nested MULTIPART parts has been
   removed.

   10) Body part number 0 has been obsoleted.

   11) Server-supported authenticators are now identified by
   capabilities.

   12) The capability that identifies this protocol is now called
   "IMAP4rev1".  A server that provides backwards support for RFC 1730
   SHOULD emit the "IMAP4" capability in addition to "IMAP4rev1" in its
   CAPABILITY response.  Because RFC-1730 required "IMAP4" to appear as
   the first capability, it should be listed first in the response.

   13) A description of the mailbox name namespace convention has been
   added.

   14) A description of the international mailbox name convention has
   been added.

   15) The UID-NEXT and UID-VALIDITY status items are now called UIDNEXT
   and UIDVALIDITY.  This is a change from the IMAP STATUS
   Internet-Draft and not from RFC-1730

   16) Add a clarification that a null mailbox name argument to the LIST
   command returns an untagged LIST response with the hierarchy
   delimiter and root of the reference argument.

-------------------------------------------------------------------------