CURRENT_MEETING_REPORT_ Reported by Terry Gray/University of Washington Minutes of the Internet Message Access Protocol Working Group (IMAP) Summary Meta-summary: the group has declared victory and are ready to move on. Last week the IESG approved the latest IMAP4 draft as a Proposed Standard. Accordingly, the original charter objectives of the working group have been accomplished and no further IMAP Working Group meetings are planned. Several pending extension proposals and informational documents will continue to be worked on informally, and in due course will be advanced as appropriate. Likewise for the companion support protocol (IMSP). The imap@cac.washington.edu e-mail list will remain available to facilitate these activities. Minutes The status of the latest (version 7) draft of the IMAP4 specification is that the IESG has approved it as a Proposed Standard. However, it is not known how soon the RFC based on the draft will be published due to a backlog in the RFC Editor's queue. There was some discussion of IMAP4 implementation experience. Both IMAP server implementors mentioned that their first implementations of the extended searching in IMAP4 were wrong. Sun has a disconnected IMAP client (ROAM) that does not yet use IMAP4 UIDs for resynchronization (they started before the specification was stable). They will upgrade when the IMAP4 c-client library becomes available. The group discussed disconnected use implementation experience and Rob Austein's draft on message cache resynchronization using IMAP4. The Sun folks indicated that IMAP has served them very well for their nomadic/disconnected mail client. Rob's document needs some additional review, and could benefit by some additional implementation wisdom. (Bill Yeager is to review it by end-of-year.) This document is Informational, not standards track. Previously proposed extensions were discussed. (These would all use the IMAP4 CAPABILITY mechanism for negotiating extensions, and would be standardized independently of the base protocol.) o Status - Universally accepted as a Good Idea. - Already implemented in the CMU Cyrus server. - Additional practical experience desired before advancing the document. o Annotate - Document needs to include the ``silent'' form of STORE. - Document needs to state that annotations do not change RFC 822 content. - Additional feedback solicited. o Protocol timeout negotiation for dialup clients. - Proponents (Austein/Klensin) need to write proposal. o Binary - The Wollongong Group will be doing this. - Draft extension and implementation to follow. o Non-ascii mailbox names - John Myers (CMU) presented a proposal that is a compromise between the two that have been discussed on the mailing list. There seemed to be broad support for John's approach, which he will write-up and submit to the list shortly. Interrupt handling. Bill Yeager (Sun) argued that the ability to interrupt a long server response (e.g. via TCP Urgent) is invaluable when using low-speed lines. This facility requires an extension to the protocol. Yeager and Crispin to discuss further. Latest PEM/MIME draft. The question was raised as to whether the latest PEM/MIME draft had any impact on IMAP. The answer was: everything should work OK as is, but there might be an opportunity for performance optimization via a future extension to IMAP. Namespace draft. The IMAP4 specification leaves a ``hook'' for multiple namespace identifiers (The ``#'' symbol at the beginning of a mailbox name.) A document needs to be published on how this might/should be used. It is not yet clear whether this would take the form of an informational ``conventions'' document, or whether it might even lead to a protocol extension proposal. IMSP. The companion support protocol to IMAP (providing such services as user-to-server binding in a large site) is evolving, but not yet ready for standardization. Procedure for extensions becoming standards. As any of the above extension proposals reach maturity, they will be brought to the attention of the area director(s), and a decision will be made then as to whether a (hopefully short-lived) working group should be chartered, or whether an ``extended Last Call'' might be sufficient to obtain feedback/consensus. This decision will be made on a case-by-case basis. Working group wind down. The original working group charter objectives were achieved with the approval of IMAP4 draft 7 as a Proposed Standard (and only a year behind the original schedule!). Further, the working group does not need to persist in order for extensions to be brought forward. Accordingly, it was agreed that this should be the last IMAP Working Group meeting, and that the IESG should decommission the IMAP Working Group.