home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / ietf / imap / imap-minutes-94dec.txt < prev    next >
Text File  |  1995-02-28  |  5KB  |  114 lines
  1.  
  2. CURRENT_MEETING_REPORT_
  3.  
  4. Reported by Terry Gray/University of Washington
  5.  
  6. Minutes of the Internet Message Access Protocol Working Group (IMAP)
  7.  
  8.  
  9. Summary
  10.  
  11. Meta-summary:  the group has declared victory and are ready to move on.
  12.  
  13. Last week the IESG approved the latest IMAP4 draft as a Proposed
  14. Standard.  Accordingly, the original charter objectives of the working
  15. group have been accomplished and no further IMAP Working Group meetings
  16. are planned.
  17.  
  18. Several pending extension proposals and informational documents will
  19. continue to be worked on informally, and in due course will be advanced
  20. as appropriate.  Likewise for the companion support protocol (IMSP). The
  21. imap@cac.washington.edu e-mail list will remain available to facilitate
  22. these activities.
  23.  
  24.  
  25. Minutes
  26.  
  27. The status of the latest (version 7) draft of the IMAP4 specification is
  28. that the IESG has approved it as a Proposed Standard.  However, it is
  29. not known how soon the RFC based on the draft will be published due to a
  30. backlog in the RFC Editor's queue.
  31.  
  32. There was some discussion of IMAP4 implementation experience.  Both IMAP
  33. server implementors mentioned that their first implementations of the
  34. extended searching in IMAP4 were wrong.  Sun has a disconnected IMAP
  35. client (ROAM) that does not yet use IMAP4 UIDs for resynchronization
  36. (they started before the specification was stable).  They will upgrade
  37. when the IMAP4 c-client library becomes available.
  38.  
  39. The group discussed disconnected use implementation experience and Rob
  40. Austein's draft on message cache resynchronization using IMAP4.  The Sun
  41. folks indicated that IMAP has served them very well for their
  42. nomadic/disconnected mail client.  Rob's document needs some additional
  43. review, and could benefit by some additional implementation wisdom.
  44. (Bill Yeager is to review it by end-of-year.)  This document is
  45. Informational, not standards track.
  46.  
  47. Previously proposed extensions were discussed.  (These would all use the
  48. IMAP4 CAPABILITY mechanism for negotiating extensions, and would be
  49. standardized independently of the base protocol.)
  50.  
  51.  
  52.    o Status
  53.       -  Universally accepted as a Good Idea.
  54.       -  Already implemented in the CMU Cyrus server.
  55.       -  Additional practical experience desired before advancing the
  56.          document.
  57.  
  58.    o Annotate
  59.       -  Document needs to include the ``silent'' form of STORE.
  60.       -  Document needs to state that annotations do not change RFC 822
  61.          content.
  62.       -  Additional feedback solicited.
  63.  
  64.    o Protocol timeout negotiation for dialup clients.
  65.       -  Proponents (Austein/Klensin) need to write proposal.
  66.  
  67.    o Binary
  68.       -  The Wollongong Group will be doing this.
  69.       -  Draft extension and implementation to follow.
  70.  
  71.    o Non-ascii mailbox names
  72.       -  John Myers (CMU) presented a proposal that is a compromise
  73.          between the two that have been discussed on the mailing list.
  74.          There seemed to be broad support for John's approach, which he
  75.          will write-up and submit to the list shortly.
  76.  
  77.  
  78. Interrupt handling.  Bill Yeager (Sun) argued that the ability to
  79. interrupt a long server response (e.g.  via TCP Urgent) is invaluable
  80. when using low-speed lines.  This facility requires an extension to the
  81. protocol.  Yeager and Crispin to discuss further.
  82.  
  83. Latest PEM/MIME draft.  The question was raised as to whether the latest
  84. PEM/MIME draft had any impact on IMAP. The answer was:  everything
  85. should work OK as is, but there might be an opportunity for performance
  86. optimization via a future extension to IMAP.
  87.  
  88. Namespace draft.  The IMAP4 specification leaves a ``hook'' for multiple
  89. namespace identifiers (The ``#'' symbol at the beginning of a mailbox
  90. name.)  A document needs to be published on how this might/should be
  91. used.  It is not yet clear whether this would take the form of an
  92. informational ``conventions'' document, or whether it might even lead to
  93. a protocol extension proposal.
  94.  
  95. IMSP. The companion support protocol to IMAP (providing such services as
  96. user-to-server binding in a large site) is evolving, but not yet ready
  97. for standardization.
  98.  
  99. Procedure for extensions becoming standards.  As any of the above
  100. extension proposals reach maturity, they will be brought to the
  101. attention of the area director(s), and a decision will be made then as
  102. to whether a (hopefully short-lived) working group should be chartered,
  103. or whether an ``extended Last Call'' might be sufficient to obtain
  104. feedback/consensus.  This decision will be made on a case-by-case basis.
  105.  
  106. Working group wind down.  The original working group charter objectives
  107. were achieved with the approval of IMAP4 draft 7 as a Proposed Standard
  108. (and only a year behind the original schedule!).  Further, the working
  109. group does not need to persist in order for extensions to be brought
  110. forward.  Accordingly, it was agreed that this should be the last IMAP
  111. Working Group meeting, and that the IESG should decommission the IMAP
  112. Working Group.
  113.  
  114.