SO WHY NOT? o Change in metaphor... people think about either bulk download or central databases o Need strong clients -At least as robust as Eudora -At least as user-attractive as MSMail or Lotus Notes -Message security (sig & maybe encryption) -At least "offline" with +compose and queue send +download some things (LISTs), disconnect, inspect, connect and get body parts -Or full "disconnected" with synchronization o And *very* robust, supported, manageable servers o And need stable spec (Potential buyers don't want to have to figure out the laundry list for a competent implementation.) o And an authentication model that works for more than a few 100K users. GETTING IMAP DEPLOYED -- THE CRITICAL PATH o POP is proving marginal when -User has no access to maildrop server -Maildrop provider cares about managing resources -Even a little synchronization is needed -Selective access to messages & parts is needed
There were demos of Mailstrom, Roam, and Simeon.
The most heavily attended BOF was on email security issues. There was discussion of both client-based and server-based security operations. There was consensus that support for client-based operations was mandatory; it was less clear how many people were interested in server-based operations.
A major point of consensus was that the IMAP community wanted the world to converge on a single email security technology and that such technology must not preclude the possibility of selective access to MIME body parts. That is, unless the sender of the message explicitly chooses to make the structure of the message opaque, it should be possible for an IMAP client to ask the server for the message structure and subsequently fetch individual body parts.
Chris Newman from CMU discussed the Past and future of IMSP. IMSP was originally conceived as a companion protocol to IMAP for those functions needed at CMU to fulfill their objectives for the Cyrus project. For example, scaling support to deal with multiple servers, and mobility of support files such as address books and personal configuration preferences. Experience with the initial version of IMSP proved the utility of these concepts. (Esys corporation is deploying IMSP for their clients, and confirms that access to remote address books is crucial.)
It was observed that the problem of remote access to configuration data is not unique to email clients; all network applications must face this issue. Moreover, the original IMSP spec included some things that might not be widely applicable. It also appeared that there was an opportunity to generalize the protocol and simplify it at the same time. As a result, the protocol is currently being re-designed, and a new draft will be posted as soon as possible.
The "M" in IMSP originally stood for "Mail", but "Mobility" seemed to better reflect the new emphasis on remote access to config files. (However, there is concern about application mobility being confused with IP-level mobility support, so a further name change is likely.)
Dave Crocker spoke about The Internet Mail Consortium, an initiative that he and Phil Hoffman are working on. It seeks to encourage an Internet messaging industry.
Lori Stevens of the University of Washington described some ideas for a possible UW IMAP Consortium, which would attempt to promote wider use of IMAP technology.
There was discussion of whether the messaging world needed or wanted both an IMAP consortium and a more general Internet Mail Consortium. Some felt that a separate IMAP consortium made sense, in order to provide maximum focus on getting the word out about IMAP's advantages. Others felt that it would be preferable to have just one organization, and that UW folks should work with IMC folks to see if there was some kind of alliance that made sense.
The wrap-up session consisted of a brief recap of a few BOF sessions and general comments about the meeting. There seemed to be strong consensus that it had been useful, and that there should be a "Second Annual" IMAP meeting.