Subject: [imap5] top client tasks for IMAP5 client?

From: Chris Newman <[email-masked]>
Date: Tue, 05 Aug 2008 15:45:13 -0700

One primary motivation for this discussion is that IMAP is not approachable 
to clients.  If we want to make it approachable, I suggest we look at it 
from the perspective of what a client implementer needs to accomplish using 
the protocol.  Here's a first strawman at a priority-ordered list of the 
mail-access functions a client needs to accomplish to provide a basic mail 
client.  Perhaps we could organize the spec around these tasks and write it 
in a way that a client implementer knows what to do after  reading the spec.

====
1. Login to server securely.

2. How many "unseen" and "total" messages are available?

3. Fetch flags, size, a unique/persistent handle (for use in subsequent 
tasks), some information about attachments and interesting headers for 
message captions that fit in a display window (with X lines where X is 
typically less than 100).  Messages are sorted by key Y (any of the columns 
the client displays) and/or in thread order.  Helpful for new online 
clients if this decodes 2047 and returns UTF-8/5198.  Has to be positional 
to work with virtual scrollbar and the positions can't change except when 
the client is expecting them to change.

4. Fetch displayable inline portions of messages, where "displayable" may 
vary a bit based on client limitations.

5. Fetch a message "attachment".  Most helpful if server has decoded it 
already.

6. Fetch the entire canonical contents of a message

7. Move message(s) to trash

8. Empty trash.

9. Categorize/tag message in some way (might relate to mailbox in 
underlying store, but client shouldn't have to care).

10. View only messages that are in a category/tag (see 2).

11. Set/clear meaningful interoperable flags on messages.

12. fetch all headers.

13. do task 3 for messages which meet certain search criteria.
====

To keep IMAP5 smaller we might want to work on IMAP5 and IMAP5+ (a small 
package of extensions to base IMAP5) at the same time.  Some tasks I'd 
consider putting in IMAP5+:

====
14. Of the "stuff" this client has cached locally, fetch everything that 
has changed since the cache was last updated.

15. Include public and shared folders in steps 2-13.
====

An important secondary goal is to minimize the changes necessary to 
existing IMAP4 clients to allow them to basically work with IMAP5 (and 
changes for an IMAP4 server to offer IMAP5).  I suspect the primary and 
this secondary goal are a bit contradictory, so finding that fuzzy 
middle-ground is a good engineering challenge.

		- Chris

_______________________________________________
imap5 mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/imap5