UW Home > Discover UW > IT Connect > IMAP Information Center

IMAP4 Status

These notes were revised on Feb. 15th, 1996 to include input from the attendees of the First Annual IMAP Meeting.

Terry Gray
Director, Networks & Distributed Computing
University of Washington
gray@cac.washington.edu

IMAP4 PROTOCOL STATUS

RFC 1730: Internet Message Access Protocol - Version 4

Became Proposed Standard in December 1994

Open issues...

RFC822.HEADER.LINES: full vs. partial return values.
PARTIAL: full vs. partial return values.
Adding Content-Disposition to the BODY structure.
IMAP vs. PEM/MOSS/PGP/S-MIME etc.

There is a glitch in the RFC-1730 specification: partial return values from the RFC822.HEADER.LINES command and the PARTIAL command are not distinguishable from full return values. This makes it difficult for clients to know exactly what message data they have cached.

Whether or not to add "Content-disposition" to the IMAP MIME structures at this time is problematic because the "Content-disposition" spec is not yet even a Proposed Standard.

The issue with IMAP vs. email security techniques is whether IMAP's selective fetching primitives are sufficient to perform local security operations, e.g. message integrity checks, on a particular MIME message part, or whether the entire message would need to be fetched and re-parsed on the client. The answer is believed to be "No" because some of the email security technologies require computing a message digest over the MIME headers themselves -- which are not currently transmitted to an IMAP client unless the entire (raw) message is fetched.

RFC 1731: IMAP4 Authentication Mechanisms

Became Proposed Standard in December 1994

Open issue...

Should server tell client which mechanisms are available?

There was no resolution of this issue at the meeting.

MOVING TO DRAFT STANDARD

Resolution of open issues affecting base document
Possible re-convening of IETF Working Group
Determine if we need to re-submit as PROPOSED
- Deletions don't require re-setting clock
- Additions or substantive changes do
Implementations:
- Need 2 independent clients and servers
- Must demonstrate use of all features, e.g. disconnected and hierarchy support

The consensus of the group was that the base document should be updated to fix the PARTIAL response problem, and add the Fetch items needed to support client-verification of secure message parts. The revised base spec will be submitted as a new IETF draft, and after a period for discussion on the IMAP list, will be submitted to Applications Area Directors for consideration as a Proposed Standard to replace RFC-1730.

Although this strategy implies some delay before the protocol can be advanced to Draft Standard status, it was felt that the delay was worthwhile. Further, there are not yet two independent clients that support all of the IMAP4 features, so we aren't quite ready for that step in any case. (The Sun "ROAM" client is the only one we know about that supports all IMAP4 functionality; others are missing either hierarchy support or disconnected operation.)

IMAP4 PROPOSED EXTENSIONS


  IMAP4 ANNOTATE Extension		C. Newman

  IMAP4 Internationalized Mailboxes	J. Myers

  IMAP4 STATUS Extension		M. Crispin

  IMAP4 QUOTA Extension			J. Myers

  IMAP4 ACL Extension			J. Myers

  IMAP4 SORT Extension*			M. Crispin

  IMAP4 SCAN Extension*			M. Crispin

  Low-Bandwidth extensions*		W. Yeager

  Server-based forwarding*		Newly proposed

 * Draft isn't written yet.

There was some (limited) discussion of including STATUS in the revised base spec. Although not too many people were in the room when this was mentioned, it is probably not controversial to add STATUS along with the new Fetch items.

IMAP4 DOCUMENTATION STATUS

FINISHED:: RFC 1732: IMAP4 Compatibility with IMAP2 and IMAP2bis
RFC 1733: Distributed Electronic Mail Models in IMAP4
UNFINISHED:: Synchronization Operations for Disconnected IMAP4 Clients
UNSTARTED:: IMAP4 Overview and Tutorial

IMAP IMPLEMENTATION STATUS

AVAILABLE NOW

Servers...
  NT:		UW
  Unix:		CMU, UW
  VMS:		Innosoft/UW

Clients...
  DOS:		PC-Pine
  Mac:		Mail Drop, Mailstrom 1, Mulberry
  Next:		EasyMail, Eloquent, MailManager
  Unix/Char:	AirMail, MS, Pine
  Unix/X:	AirMail, ML, MMail, Roam, Simeon
  VMS:		Pine
  Windows:	Air Mail, Atismail, Embla, PC-Pine,
		Simeon, Siren Mail

COMING SOON

Servers...
  NT:		WinSMTP
  Unix:		Accordance, Software.Com, Netscape

Clients...
  Mac:		Mailstrom 2, MMail, Netscape 3, Simeon, Zmail, Siren
  Unix/X:	Netscape 3, Zmail, Sun DTMail
  Windows:	Chameleon, Mail-It, MMail, Netscape 3, pcMail,
		Pronto, Roam, SuperTCP Email, Zmail, MAPI-IMAP driver
  OS/2:		AirMail

Please note: the statements on this page reflect the state of affairs at the time of the First Annual IMAP Meeting in early 1996. The IMAP Connection, however, contains regularly updated status, documentation, and implementation information on IMAP.

To First IMAP Meeting