INTERIM_MEETING_REPORT_ Reported by Terry Gray/University of Washington Minutes of the Internet Message Access Protocol Working Group (IMAP) Administrivia o Two sessions were held (Tuesday afternoon and Wednesday morning). o Approximately 35 people attended, most attended both sessions. Conclusions o A new ``CAPABILITIES'' command was added. The intent is to provide a convenient way for a client to discover optional extensions on a server without having to ``go fishing'' (i.e., probing for individual capabilities). The approach was encouraged in part by statements that a similar philosophy in SMTPEXT has worked very well. o Several proposed functional extensions were deferred, as candidates for the new CAPABILITIES capability. (These included: Have server do MD5 validation; have server do MIME External/FTP fetching; provide per-message annotation; and provide for binary transfer of large MIME objects such as voice mail.) o Additional authentication schemes (beyond user/password and Kerberos) will be accommodated. o Some additional text is needed in the document to address disconnected use and failure/error conditions more fully. o Restructuring of the document into several self-standing ``chunks'' is needed, with some of those chunks turning into either appendices or separate documents. o There are still some open issues on FLAGS that need to be nailed down or intentionally not nailed down. Assigned Subtasks o Wording for new CAPABILITIES command (first cut done) o Revision of server flow control paragraph (first cut done) o Revision of section on authentication alternatives o Wording for extension to LIST response to denote ``interesting'' folders o Revision to FLAGS wording o New text on use in disconnected mode o More text on what happens in failure/error cases o Document restructuring o There will also be proposed extensions (e.g. per-message annotation), however, these will not be in the base document, so are not subject to the following schedule Schedule o Subcommittee inputs received no later than 15 April. o New draft available no later than 1 May. o New goal of Proposed Standard around 1 June. Details Several topics other than those on the preliminary agenda were discussed: o General extensibility mechanism o IMAP document format o IMAP document content re: examples, failure conditions o Proposed extension for binary transfer o Discussion of Posting (or lack thereof) o Schedule The discussion of extensibility (the ``topic that refused to die'') has led to consensus that a CAPABILITIES command will be added to the IMAP4 specification to allow for more graceful addition of new features. While the previous ``probing'' philosophy was held sufficient by some, a consensus emerged to add the new command based on the following: o Clients wishing to adapt their user-interface to currently available server capabilities (e.g., the greyed-out button case) will have an easier job with such a command. o It was reported that some clients are already failing to correctly use the probing philosophy, at the cost of interoperability, and that such a command will have a psychological benefit in discouraging mindless dependency on later extensions. o The existence of this command makes the task of adding extensions seem less intimidating, therefore it becomes more reasonable to defer action on certain proposed new features. Without it, there was a sense among many---correct or not---that adding a new (non-private) extension was tantamount to a major revision of the protocol. New Functionality o Per-message annotation fields (fixed or arbitrary length; how many?) Deferred as a candidate for the new extension mechanism o S/Key authentication? Draft text will be modified to allow for other authentication mechanisms besides user/password and Kerberos. There will be a way to communicate the challenge string to the client for challenge response systems. o How to handle FTP/external references (on client, server, or both)? Deferred as a candidate for the new extension mechanism. That is, it is currently a client problem. If there is constituency for having a way for the client to ask the server to fetch external body parts (e.g., via FTP), this would be appropriate as a candidate extension. The LIST Command o General discussion on hierarchy support, especially changes since the Houston IETF o Method to quickly discover which folders have unseen and/or recent messages o Should there be a fast way to determine if a server mailbox is unchanged since the time a client made a cache copy of it There was agreement that it would be useful to have a way to indicate when a folder might have something interesting in it. A subcommittee will provide a draft revision of the LIST description to accomplish this. FLAGS o Which are private, which are not (in a shared mailbox case)? There is widespread sentiment that it is impossible to agree on exactly which flags should always and only be per-user, and which ones---in a shared mailbox case---should be visible/settable by anyone with appropriate permissions. Thus, this is likely to remain implementation dependent. o Which should be preserved on Copy/Append (e.g., Del, user flag ``Saved'')? There is agreement to leave the current approach alone concerning Copy/Append, wherein COPY copies all reasonable flags, and APPEND allows the client to specify which flags will be copied. o How do user flags get created (explicitly, implicitly, or by preconfig)? There is agreement that the current wording concerning creation and storing of flags is okay. A server will indicate the flags it knows about, and whether it allows implicit creation of new ones. (There is an issue of deleting no-longer-used, or created-in-error flags.) o Should there be an UNSENT system flag (as opposed to a user flag)? A subcommittee has been tasked with recommending what to do about UNSENT (or DRAFT?) and any other open FLAGS related issues. Suggestions for Protocol Simplification o Deprecate BODY Fetch? Suggestion withdrawn by its proposer. o Remove STORE untagged response? Suggestion defeated and/or withdrawn by its proposer. o Remove MD5 fetch (at least do not do it implicitly)? Deferred as a possible extension. (The current draft allows the client to fetch the raw MD5 value and compute the value from other fetched body parts. The issue is whether to invent a way to ask the server to verify the message integrity.) Protocol Clarifications (aka FAQs) o Can clients make any assumptions about the context for non-FQNs, i.e., context-sensitive names? Answer: No. Issue noted; no changes to specification recommended. o Is IMAP capable of asynchronous operation? New wording will be incorporated to clarify what a server must do to avoid deadlock if it elects to send unsolicited data while not processing a client command. Miscellaneous Topics o Special information tokens for error conditions It was reported that a separate document that does not propose changes to the current IMAP draft will be forthcoming to address the question of parsing/presentation of messages coming from servers in a language other than English. o If body structure extensions must be in a defined order, doesn't this defeat their utility as an extensibility mechanism? The intent is to make sure that an IMAP4 client will not be upset if a later server sends additional elements it doesn't know about. No protocol change was recommended. Perhaps a wording clarification. o Should the address structure include a place for comments, since those are not always personal names? Changing the IMAP envelope structure definition will break existing clients. Clients wishing to obtain the entire RFC 822 header and parse the address locally (for purposes of extracting the comment field) may do so. Attendees Robert Austein sra@epilogue.com John Beck jbeck@cup.hp.com Luc Boulianne lucb@bunyip.com Michael Bringmann michael@rd.qms.com Rong Chang rong@watson.ibm.com Wallace Colyer wally+@cmu.edu Mark Crispin mrc@cac.washington.edu David Crowe crowed@osshe.edu Shane Davis shane@delphi.com Ian Duncan id@cc.mcgill.ca Richard Everman reverman@ka.reg.uci.edu Erik Fair fair@apple.com Roger Fajman raf@cu.nih.gov Ned Freed ned@innosoft.com Terry Gray gray@cac.washington.edu Steven Hubert hubert@cac.washington.edu Neil Katin katin@eng.sun.com David Katinsky dmk@pilot.njin.net John Klensin Klensin@infoods.unu.edu Michael Knezevich knezevich@pmel.noaa.gov Ben Levy seven@ftp.com Lars-Johan Liman liman@sunet.se Glenn McGregor glenn@lloyd.com David Miller dlm@cac.washington.edu Richard Moore moorerr@msu.edu Bob Morgan morgan@networking.stanford.edu John Myers jgm+@cmu.edu Clifford Neuman bcn@isi.edu Hilarie Orman ho@cs.arizona.edu Corey Satten corey@cac.washington.edu Michael Seibel mikes@cac.washington.edu William Simpson bsimpson@morningstar.com Einar Stefferud stef@nma.com Gregory Vaudreuil g.vaudreuil@octel.com Grace Wiechman gw@cray.com