home *** CD-ROM | disk | FTP | other *** search
/ InfoMagic Internet Tools 1993 July / Internet Tools.iso / RockRidge / mail / pine / imap_archive / text0108.txt < prev    next >
Encoding:
Text File  |  1993-07-02  |  4.4 KB  |  106 lines
  1. >    Security.  Security-related tasks include how to incorporate secure
  2. >    authentication mechanisms when establishing a session, and possible
  3. >    interactions with Privacy Enhanced Mail.
  4.  
  5.     Since IMAP would be an online, interactive protocol
  6. (as opposed to store-and-forward), CAT mechanisms would be more
  7. appropriate to secure it than PEM.  I don't see any interactions
  8. with PEM.
  9.  
  10. -- Steve
  11.  
  12. Steven J. Lunt                     lunt@bellcore.com
  13. Information Technology Security    RRC 1L-213
  14. Bellcore                           444 Hoes Lane
  15. (908) 699-4244                     Piscataway, NJ 08854
  16.  
  17. > Subject: WG ACTION: Interactive Mail Access Protocol (imap)
  18. > Date: Thu, 10 Jun 93 15:12:33 -0400
  19. > From: Greg Vaudreuil <gvaudre@cnri.reston.va.us>
  20. > 
  21. > A new working group has been formed in the Applications Area of the
  22. > IETF.  Please contat the working group chairman of the Internet area
  23. > directors for more information.
  24. > 
  25. > Greg Vaudreuil
  26. > IESG Secretary
  27. > 
  28. > 
  29. > Interactive Mail Access Protocol (imap)
  30. > ---------------------------------------
  31. >  
  32. >  Charter 
  33. >  
  34. >  Chair(s):
  35. >      Terry Gray  <gray@cac.washington.edu>
  36. >  
  37. >  Applications Area Director(s) 
  38. >      Brewster Kahle  <Brewster@wais.com>
  39. >      Erik Huizer  <Erik.Huizer@SURFnet.nl>
  40. >  
  41. >  Mailing lists: 
  42. >      General Discussion:imap@cac.washington.edu
  43. >      To Subscribe:      imap-request@cac.washington.edu
  44. >      Archive:           ftp.cac.washington.edu:~/imap/imap_archive
  45. >  
  46. > Description of Working Group:
  47. >  
  48. >    The Internet Interactive Mail Access Protocol (IMAP) working group
  49. >    is chartered to refine and extend the current IMAP2 protocol as a
  50. >    candidate standard for a client-server Internet email protocol to
  51. >    manipulate remote mailboxes as if they were local.  An explicit
  52. >    objective is to retain compatibility with the growing installed base
  53. >    of IMAP2-compliant software.  It is expected that the resulting
  54. >    specification will replace both RFC-1176 and the more recent (as yet
  55. >    unplublished) IMAP2bis extensions document.
  56. > 
  57. >    The IMAP Working Group will also investigate how to provide for
  58. >    ``disconnected operation'' capabilities similar to the DMSP protocol
  59. >    (RFC-1056, recently relegated to Informational Status) with a goal
  60. >    of making it possible for IMAP to replace DMSP.
  61. > 
  62. >    A mail access protocol provides a uniform, OS-independent way of
  63. >    manipulating message data (email or bulletin board) on a remote
  64. >    message store (repository).  Mail user agents implementing such a
  65. >    protocol can provide individuals with a consistent view of the
  66. >    message store, regardless of what type of computer they are using,
  67. >    and regardless of where they are connected in the network.  Multiple
  68. >    concurrent sessions accessing a single remote mailbox, and single
  69. >    sessions accessing multiple remote mailboxes are both possible with
  70. >    this approach.
  71. > 
  72. >    This differs from POP3 (RFC-1225) in that POP is a store-and-forward
  73. >    transport protocol that allows an MUA to retrieve pending mail from
  74. >    a mail drop (where it is then usually deleted automatically),
  75. >    whereas IMAP is focused on remote mailbox manipulation rather than
  76. >    transport. IMAP differs from various vendor-specific remote access
  77. >    approaches in that IMAP is an open protocol designed to scale well
  78. >    and accommodate diverse types of client operating systems.
  79. > 
  80. >    Security.  Security-related tasks include how to incorporate secure
  81. >    authentication mechanisms when establishing a session, and possible
  82. >    interactions with Privacy Enhanced Mail.
  83. > 
  84. >    It is expected that most of the work of this group will be conducted
  85. >    via email.  A goal is to integrate and update RFC-1176 and the
  86. >    existing IMAP2bis draft, then submit the result as an Internet draft
  87. >    well before the November IETF WG meeting, which would then focus on
  88. >    detailed review of the text in preparation for submission as a
  89. >    Proposed Standard before the end of 1993.
  90. > 
  91. >  
  92. >  Goals and Milestones: 
  93. >  
  94. >    Aug 93 Post an Internet Draft of the revised IMAP 2 protocol.               
  95. > 
  96. >    Aug 93 Hold an Interim Working Meeting at UW or CMU.                        
  97. > 
  98. >    Nov 93 Hold a Working Group meeting to review the IMAP document.            
  99. > 
  100. >    Nov 93 Hold a Working Group meeting at the November IETF meeting.           
  101. > 
  102. >    Dec 93 Submit the IMAP protocol to the IESG for consideration as a Proposed 
  103. >           Standard.                                                            
  104.  
  105.  
  106.