CURRENT_MEETING_REPORT_ Reported by Terry Gray/University of Washington Minutes of the Internet Message Access Protocol Working Group (IMAP) Summary On Monday, twenty-seven people convened for the first of two scheduled IMAP Working Group sessions (although not everyone signed the attendance sheet). On Tuesday, a proper subset of around a dozen stalwarts carried on. For the continuation session after dinner, we were down to six, and two different ad hoc ``midnight subcommittee'' meetings were held. The fifteen original agenda items and four new ones were considered. Considerable progress was made on all fronts. One notable result: on Monday the group agreed that the acronym ``IMAP'' should be remapped to the words ``Internet Message Access Protocol'' to better reflect what the protocol has evolved into. There are three remaining work items: 1. John Myers to propose an additional set of protocol-specified special information tokens. 2. Chris Newman to propose a revised hierarchy support solution based on conceptual agreement reached at the meeting. 3. Chris Newman to propose a syntax for an IMAP ``meta'' namespace, to allow unambiguous identification of multiple namespaces. A new draft, incorporating at least some of the above three pending items and all of the other agreed upon items is expected around 12 November 1993. All in all, it was a very productive meeting! Resolution Of Specific Agenda Items 1. Is the UID AFTER construct now superfluous? o Yes; delete UID AFTER. 2. Should John Myers' Quota extension be included in the draft? o No; requires future study. 3. How useful is selective header fetch (versus fetch 822 and grep)? o Useful enough to keep in the specification. 4. Format of special information tokens which have args (UNSEEN). o Change syntax so value is inside square brackets. 5. Definition of special information tokens for error conditions. o Agreed they are useful if situation might require client to take action ``behind the scenes,'' e.g. TRYCREATE. o No consensus on using these protocol-specified strings as an interim method to allow internationalization (client could index into local-language error message table.) o John Myers to formulate specific proposal for additions to specification. 6. Mstring grammar. o Objection to current definition was dropped. 7. RFC 1522 search strings. Is current specification wording OK? o Wording revised. 8. Additional non-ascii issues (cf. Peter Svanberg, Olle Jarnefors). o New wording resulted. 9. Extended search. (Define in imap2bis, or defer to separate RFC?) o John Myer's proposal accepted with some modifications; especially not will be allowed in front of groups, and patterns (wildcards) will not be allowed at this time because of unknown interactions with international character strings. 10. How to support hierarchy. o Conceptual agreement reached on a hybrid proposal; abandoned idea that client should define hierarchy, lest there be no hope of any consistency across clients. Rather, client should present server (mailbox driver's) view of hierarchy to allow users to use pathnames discovered via documents, voice, or messages. o Chris Newman to do syntax engineering and submit revised proposal. 11. Global versus private flags... consistency across servers/clients o New unsolicited responses will indicate which flags are stored permanently on the server, and which ones the client can update, and whether a client can add new ones. 12. Namespace/driver selection, especially for non-filesystem drivers. o ``Rough consensus'' that there are multiple well-entrenched namespaces in the world that we need to deal with, and they don't divide cleanly into the MAILBOX and BBOARD namespaces. o Examples: filesystem-based mail, news, FTP archives, Gopher collections, other non-filesystem mailbox namespaces. o Chris Newman to propose constructs to allow specification and/or merging of multiplicity of namespaces into one IMAP ``meta'' namespace. 13. How useful is the BBOARD construct? o ``Rough consensus'' that if Chris is able to come up with a satisfactory namespace syntax that BBOARD construct should be deprecated on the grounds that eliminating BBOARD simplifies the protocol, ``two'' namespaces is either too few or too many, and in some cases forcing ``real world'' namespaces into either MAILBOX or BBOARD can result in artificial and confusing distinctions for the user. 14. Should ``IMAP'' == ``Internet Message Access Protocol'' o Yes. Agreed that the new words are more descriptive of what the protocol has evolved into. 15. Revise the milestones in the working group's charter. o No revision required (yet). December goal for Proposed Standard submission still thought plausible. Additional Issues (The agenda was posted before the meeting.) 1. Protocol feature negotiation o Prevailing wisdom was sustained, namely: if there had been two clear epochs of IMAP software, it might make sense to have a version mechanism, but capabilities of both clients and servers have evolved gradually, so there is a real hodgepodge of capabilities in the installed base. Accordingly, the client must probe individually each post-RFC 1176 function anyway to see if the server supports it. If individual probing is necessary, then having a single command to return capabilities doesn't offer any significant simplification of the client. o Each new feature must have a specified way of probing for its existence without changing server state. 2. Change definition of internal date o Agreed to change definition of internal date to be the ``date of final delivery as defined in RFC 821.'' o Agreed to preserve internal date on COPY and APPEND. 3. PEM versus MIME versus IMAP (compute checksum on server?) o Integrity-protected PEM messages allow for the possibility of having the server compute the MD5 checksum, and let the client compare it with the sealed checksum sent in the message. The advantage is that the client can then verify integrity without fetching the entire message, as long as it is willing to trust the server to send the real message on subsequent fetches. It was agreed that, given the prospect of large body parts the client might not want, this would be a good feature to include. o Confidentiality-protected (encrypted) PEM messages (or individual body parts), will be structurally opaque. However, it is possible to fetch the portion of the message containing the sealed key, unseal it on the client, hand it back to the server, and have the server decrypt the body part, thence allowing the server to parse the MIME structure and allow subsequent fetching of individual body parts. o A ``midnight ad hoc task force'' identified wording to define extensions for both of the above cases. 4. Fetch Peek o This was a non-controversial extension to allow fetching messages without setting the \SEEN flag, as one might like to do for disconnected operation. Attendees Harald Alvestrand Harald.T.Alvestrand@uninett.no Robert Austein sra@epilogue.com Luc Boulianne lucb@cs.mcgill.ca James Conklin jbc@bitnic.educom.edu Mark Crispin mrc@cac.washington.edu Walt Drummond drummond@noc.rutgers.edu Urs Eppenberger eppenberger@switch.ch Erik Fair fair@apple.com Patrik Faltstrom paf@nada.kth.se Ned Freed ned@innosoft.com Terry Gray gray@cac.washington.edu Jeroen Houttuin houttuin@rare.nl Ben Levy seven@ftp.com Lars-Johan Liman liman@ebone.net Chip Matthes chip@delphi.com Bob Morgan morgan@networking.stanford.edu John Myers jgm+@cmu.edu Chris Newman chrisn+@cmu.edu Kenneth Rossen kenr@shl.com Mark Smith mcs@umich.edu Bradley Wilson wilson@ftp.com Jackie Wilson Jackie.Wilson@msfc.nasa.gov Peter Yee yee@atlas.arc.nasa.gov