home *** CD-ROM | disk | FTP | other *** search
/ InfoMagic Internet Tools 1993 July / Internet Tools.iso / RockRidge / mail / pine / imap_archive / text0056.txt < prev    next >
Encoding:
Text File  |  1993-07-02  |  6.9 KB  |  149 lines

  1. Folks,
  2. Several of you have encouraged me in private communications to move ahead
  3. with getting IMAP onto the IETF standards track.
  4.  
  5. I took the first step toward that goal today by chairing a BOF at the
  6. Columbus IETF to gauge interest, discern commonality of objectives, and
  7. discuss a draft W.G. charter, which is appended herewith for your
  8. consideration.
  9.  
  10. (I'll post more info on the BOF discussion within a few days, but I want
  11. to get the BOF attendees onto this list first.)
  12.  
  13. In any case, the wording and objectives stated below were acceptable to
  14. the folks who were able to come to the BOF.  If you have objections or
  15. suggestions, please let me know soon.  (48 hours of silence will be
  16. interpreted as universal, unanimous, enthusiastic assent :) Seriously, I'd
  17. like to ask Russ Hobby (the area co-director) to forward it on to IESG
  18. fairly soon. 
  19.  
  20. Thanks... 
  21.  
  22. -teg
  23.  
  24. p.s. the long form "ietf-imap@cac.washington.edu" is an alias for
  25.      "imap@cac.washington.edu"  --likewise, the -request address.
  26.  
  27. --------------------------------------------------------------------------
  28.  
  29. Interactive Mail Access Protocol Working Group (imap)
  30.  
  31. Chair:
  32.  
  33.      Terry Gray             gray@cac.washington.edu
  34.  
  35. Mailing Lists:
  36.  
  37.      General Discussion:    ietf-imap@cac.washington.edu
  38.      To Subscribe:          ietf-imap-request@cac.washington.edu
  39.      Mail archive:          ftp.cac.washington.edu /imap/imap_archive
  40.  
  41. Description of Working Group:
  42.  
  43. The Internet Interactive Mail Access Protocol (IMAP) working group is
  44. chartered to refine and extend the current IMAP2 protocol as a candidate
  45. standard for a client-server Internet email protocol to manipulate remote
  46. mailboxes as if they were local.  An explicit objective is to retain
  47. compatibility with the growing installed base of IMAP2-compliant software. 
  48. It is expected that the resulting specification will replace both RFC-1176
  49. and the more recent (as yet unplublished) IMAP2bis extensions. 
  50.  
  51. A mail access protocol provides a uniform, OS-independent way of
  52. manipulating email message data on a remote mail store (repository).  Mail
  53. user agents implementing such a protocol can provide individuals with a
  54. consistent view of the mail store, regardless of what type of computer
  55. they are using, and regardless of where they are connected in the network. 
  56. Multiple concurrent sessions accessing a single remote mailbox, and single
  57. sessions accessing multiple remote mailboxes are both possible with this
  58. approach. 
  59.  
  60. There are no Internet standards in this area, and one is needed to define
  61. a consistent approach to the problem in the context of other Internet mail
  62. protocols including RFC-822, SMTP, and MIME.  IMAP appears to be the only
  63. existing *open* protocol that achieves the above goals. Hence, the choice
  64. is either to invent a new protocol from scratch, or to refine IMAP2. 
  65. IMAP2 is in production use at a number of large sites, and several
  66. commercial products based on it are now available. Operational experience
  67. has been very positive, and the installed base is growing.  In the absence
  68. of any serious problems with the current specifications (IMAP2 plus
  69. IMAP2bis extensions), it makes little sense to start over, nor to abandon
  70. compatibility with the installed base. 
  71.  
  72. Comparison to POP.  There is a Draft Standard describing the latest
  73. version of the Post Office protocol (POP3, RFC-1225).  POP is a
  74. store-and-forward transport protocol that allows an MUA to retrieve
  75. pending mail from a mail drop (where it is then usually deleted
  76. automatically).  IMAP, in contrast, is focused on remote mailbox
  77. manipulation rather than mail transport.  Although IMAP is a functional
  78. superset of POP and can operate in the same mode, the two have different
  79. purposes and should not be viewed as competing. 
  80.  
  81. Comparison to PCMAIL.  PCMAIL, defined in RFC-1056, uses the Distributed
  82. Mail System Protocol (DMSP).  It has been relegated to Informational
  83. status by the IAB.  A strength of DMSP is support for "disconnected
  84. operation" wherein a local message cache can be created for off-line
  85. processing, and later resynchronized with the main mail server. 
  86. (Preliminary discussions have taken place with members of the DMSP
  87. community on how to fold similar capabilities into IMAP2.  The working
  88. group needs to complete this effort.)
  89.  
  90. Commercial alternatives. Many of the vendor-specific remote mail access
  91. approaches are based on proprietary remote file system protocols that
  92. neither scale well nor support diverse types of client operating systems. 
  93. Others are unsuitable candidates for Internet standardization due to
  94. licensing  restrictions.
  95.  
  96. Comparison with NFS.  Achieving many of the stated goals is possible using
  97. a generic remote file access protocol such as NFS, rather than an
  98. application-specific email protocol.  However, there are also some
  99. significant drawbacks, including: file locking on the mail server in the
  100. face of concurrent local and (possibly multiple) remote updates;  network
  101. performance; and difficulty in implementing on small client machines. 
  102. Moreover, using an application-specific protocol allows the server to
  103. provide more efficient searching and message parsing.  The latter is
  104. particularly important in the context of MIME, so that the client can
  105. request message structure information from the server, and thereafter
  106. retrieve only the body parts it needs. 
  107.  
  108. Security.  Security-related tasks include how to incorporate secure
  109. authentication mechanisms when establishing a session, and interactions
  110. with Privacy Enhanced Mail. 
  111.  
  112. This working group's IMAP standardization activity complements (and does not
  113. compete with) parallel efforts to define the "IMSP" mail support protocol
  114. which will be layered on top of the resulting IMAP protocol.  The mail
  115. support protocol work addresses issues of managing large email sites, such
  116. as determining on which mail server a particular user's incoming mail
  117. resides. 
  118.  
  119.  
  120. Goals and Milestones:
  121.  
  122. It is expected that most of the work of this group will be conducted via
  123. email. Opportunities to meet face-to-face at IETF meetings will be used
  124. initially to review the charter and context for the work, as well as
  125. presentations to help members get up to speed on IMAP.  A goal is to have
  126. the IMAP2bis draft updated and submitted as an Internet draft in the July
  127. timeframe.  The November IETF WG meeting would then focus on detailed
  128. review of the draft standard. 
  129.  
  130. Mar 93 IETF   A BOF to review the working group charter, and discuss
  131.               its relationship to the broader remote mail issues
  132.               considered in previous IETF email BOFs.  
  133.  
  134. Jul 93 IETF   Foreign travel restrictions may preclude several of 
  135.               the key players from attending the Amsterdam IETF, however,
  136.               it may be possible to schedule a WG meeting for 
  137.               presentations and to solicit input from those who are 
  138.               normally unable to attend US IETF meetings.
  139.  
  140. Nov 93 IETF   Based on continuing email refinement of the text, use 
  141.               this meeting for a detailed review of Internet draft text.
  142.  
  143.  
  144.  
  145.  
  146.  
  147.  
  148.  
  149.