home *** CD-ROM | disk | FTP | other *** search
- Folks,
- Several of you have encouraged me in private communications to move ahead
- with getting IMAP onto the IETF standards track.
-
- I took the first step toward that goal today by chairing a BOF at the
- Columbus IETF to gauge interest, discern commonality of objectives, and
- discuss a draft W.G. charter, which is appended herewith for your
- consideration.
-
- (I'll post more info on the BOF discussion within a few days, but I want
- to get the BOF attendees onto this list first.)
-
- In any case, the wording and objectives stated below were acceptable to
- the folks who were able to come to the BOF. If you have objections or
- suggestions, please let me know soon. (48 hours of silence will be
- interpreted as universal, unanimous, enthusiastic assent :) Seriously, I'd
- like to ask Russ Hobby (the area co-director) to forward it on to IESG
- fairly soon.
-
- Thanks...
-
- -teg
-
- p.s. the long form "ietf-imap@cac.washington.edu" is an alias for
- "imap@cac.washington.edu" --likewise, the -request address.
-
- --------------------------------------------------------------------------
-
- Interactive Mail Access Protocol Working Group (imap)
-
- Chair:
-
- Terry Gray gray@cac.washington.edu
-
- Mailing Lists:
-
- General Discussion: ietf-imap@cac.washington.edu
- To Subscribe: ietf-imap-request@cac.washington.edu
- Mail archive: ftp.cac.washington.edu /imap/imap_archive
-
- Description of Working Group:
-
- The Internet Interactive Mail Access Protocol (IMAP) working group is
- chartered to refine and extend the current IMAP2 protocol as a candidate
- standard for a client-server Internet email protocol to manipulate remote
- mailboxes as if they were local. An explicit objective is to retain
- compatibility with the growing installed base of IMAP2-compliant software.
- It is expected that the resulting specification will replace both RFC-1176
- and the more recent (as yet unplublished) IMAP2bis extensions.
-
- A mail access protocol provides a uniform, OS-independent way of
- manipulating email message data on a remote mail store (repository). Mail
- user agents implementing such a protocol can provide individuals with a
- consistent view of the mail store, regardless of what type of computer
- they are using, and regardless of where they are connected in the network.
- Multiple concurrent sessions accessing a single remote mailbox, and single
- sessions accessing multiple remote mailboxes are both possible with this
- approach.
-
- There are no Internet standards in this area, and one is needed to define
- a consistent approach to the problem in the context of other Internet mail
- protocols including RFC-822, SMTP, and MIME. IMAP appears to be the only
- existing *open* protocol that achieves the above goals. Hence, the choice
- is either to invent a new protocol from scratch, or to refine IMAP2.
- IMAP2 is in production use at a number of large sites, and several
- commercial products based on it are now available. Operational experience
- has been very positive, and the installed base is growing. In the absence
- of any serious problems with the current specifications (IMAP2 plus
- IMAP2bis extensions), it makes little sense to start over, nor to abandon
- compatibility with the installed base.
-
- Comparison to POP. There is a Draft Standard describing the latest
- version of the Post Office protocol (POP3, RFC-1225). POP is a
- store-and-forward transport protocol that allows an MUA to retrieve
- pending mail from a mail drop (where it is then usually deleted
- automatically). IMAP, in contrast, is focused on remote mailbox
- manipulation rather than mail transport. Although IMAP is a functional
- superset of POP and can operate in the same mode, the two have different
- purposes and should not be viewed as competing.
-
- Comparison to PCMAIL. PCMAIL, defined in RFC-1056, uses the Distributed
- Mail System Protocol (DMSP). It has been relegated to Informational
- status by the IAB. A strength of DMSP is support for "disconnected
- operation" wherein a local message cache can be created for off-line
- processing, and later resynchronized with the main mail server.
- (Preliminary discussions have taken place with members of the DMSP
- community on how to fold similar capabilities into IMAP2. The working
- group needs to complete this effort.)
-
- Commercial alternatives. Many of the vendor-specific remote mail access
- approaches are based on proprietary remote file system protocols that
- neither scale well nor support diverse types of client operating systems.
- Others are unsuitable candidates for Internet standardization due to
- licensing restrictions.
-
- Comparison with NFS. Achieving many of the stated goals is possible using
- a generic remote file access protocol such as NFS, rather than an
- application-specific email protocol. However, there are also some
- significant drawbacks, including: file locking on the mail server in the
- face of concurrent local and (possibly multiple) remote updates; network
- performance; and difficulty in implementing on small client machines.
- Moreover, using an application-specific protocol allows the server to
- provide more efficient searching and message parsing. The latter is
- particularly important in the context of MIME, so that the client can
- request message structure information from the server, and thereafter
- retrieve only the body parts it needs.
-
- Security. Security-related tasks include how to incorporate secure
- authentication mechanisms when establishing a session, and interactions
- with Privacy Enhanced Mail.
-
- This working group's IMAP standardization activity complements (and does not
- compete with) parallel efforts to define the "IMSP" mail support protocol
- which will be layered on top of the resulting IMAP protocol. The mail
- support protocol work addresses issues of managing large email sites, such
- as determining on which mail server a particular user's incoming mail
- resides.
-
-
- Goals and Milestones:
-
- It is expected that most of the work of this group will be conducted via
- email. Opportunities to meet face-to-face at IETF meetings will be used
- initially to review the charter and context for the work, as well as
- presentations to help members get up to speed on IMAP. A goal is to have
- the IMAP2bis draft updated and submitted as an Internet draft in the July
- timeframe. The November IETF WG meeting would then focus on detailed
- review of the draft standard.
-
- Mar 93 IETF A BOF to review the working group charter, and discuss
- its relationship to the broader remote mail issues
- considered in previous IETF email BOFs.
-
- Jul 93 IETF Foreign travel restrictions may preclude several of
- the key players from attending the Amsterdam IETF, however,
- it may be possible to schedule a WG meeting for
- presentations and to solicit input from those who are
- normally unable to attend US IETF meetings.
-
- Nov 93 IETF Based on continuing email refinement of the text, use
- this meeting for a detailed review of Internet draft text.
-
-
-
-
-
-
-
-