An overview of IMAP command implementation proposed for JAMES

Objective: A set of interfaces and basic implementations that provide:

• The core functionality of RFC 2060, IMAP4Rev1.
• Mailbox referrals - RFC 2193
• Login referrals - RFC 2221
• Access Control Lists - RFC 2086
• Quotas - RFC 2087

The IMAP protocol is based on single socket connections. Each connection may be in one of four official states: Non-Authenticated, Authenticated, Selected and Logout. In addition, there is an on-connection 'state'. Connections may be pre-authenticated, in which case they transition directly to the Authenticated state. Connections may also be rejected arbitrarily, in which case a response is sent and the connection tranistions directly to Logout. Once a connection enters the Logout state it must terminate and will terminate without further client input.

A connection can only 'select' one mailbox at a time, although the STATE command allows a limited view of another mailbox. A client may open more than one connection to a single server at once. The client is responsible for any coordination needed. Multiple connections may 'select' a mailbox at the same time. The server must coordinate access.

Clients are, in general, permitted to issue multiple commands in a single connection. That is they can issue a second command without waiting for a response to the first command. Servers may process multiple commands in parallel or in series. However, some combinations of commands cannot be processed in parallel, because they are ambiguous. According to RFC2060,

"Clients MUST NOT send multiple commands without waiting if an ambiguity would result. If the server detects a possible ambiguity, it MUST execute commands to completion in the order given by the client."

The following table aims to highlight which commands can or cannot be processed in parallel with other commands. In particular, commands that are sensitive to mailbox context or message sequence number cannot be processed in parallel with commands that change those respective facts.

IMAP servers can support multiple namespaces with mailboxes that, for clients, would otherwise have identical names. For example, a user could have a private mailbox called James and also have access to a workgroup mailbox called James. These are disambiguated by namespace tokens, which a client can discover by the Namespace command.

Mailboxes can, in general, be accessed on behalf of more than one user. Access Control Lists are used to on a per mailbox basis. Any command which explicitly or implicitly refers to a mailbox, which is every command apart from Capability, Noop, Logout, can be impacted by a change of ACL. I intend to tie administer rights for an ACL to full read-write rights for the mailbox and not to allow someone with administer rights to remove their own administer rights. Implementations not following this practice may need to disambiguate ACL sensitive commands.

The state of a mailbox (name, existence, ACL, number of messages, identity of messages and message attributes) may be changed outside a given connection which has the mailbox selected. Some of these changes should be notified to a client whether or noe a command is in progress and some should be notified only if a command is in progress.

The effects of a command noted here are ones which may affect processing multiple commands from one connection or impact multiply accessed mailboxes.

• Connection state change: will or may change the state of the connection
• Mailbox change: will or may change the state of an existing mailbox. Includes: changing name, altering size of mailbox (by adding or removing message) changing the access control list.
• Mailbox context change: changes the selection of a mailbox, which is the context for Selected state commands.
• Message Sequence Number Change: will or may change the message sequence number of a message known to this client, for example by provoking an untagged Expunge response. Note that any command in the selected state may send an untagged Expunge, except for Fetch, Store and Search. The entry 'likely' in this column indicates a proposed implementation.

The sensitivities noted are ones which may affect processing multiple commands from one connection or impact multiply accessed mailboxes.

• Current Mailbox: this command implicity refers to the currently selected mailbox so is sensitive to either a mailbox change or a mailbox context change
• Message sequence number change: this command may take an MSN as an argument

All commands which explicitly or implicitly refers to a mailbox, which is every command apart from Capability, Noop, Logout, can be impacted by a Mailbox change.

	State in which valid			Effects				Sensitivity
Command	Non-Authenticated	Authenticated	Selected	Connection State change	Mailbox change	Mailbox context change	Message Sequence Number Change	Mailbox context	Message Sequence Number
Core IMAP4 rev1 commands (RFC2060)
Capability	Yes	Yes	Yes
Noop	Yes	Yes	Yes				likely
Logout	Yes	Yes	Yes	Yes
Authenticate	Yes			Yes
Login	Yes			Yes
Select		Yes	Yes	Yes		Yes
Examine		Yes	Yes	Yes		Yes
Create		Yes	Yes
Delete		Yes	Yes		Yes
Rename		Yes	Yes		Yes
Subscribe		Yes	Yes
Unsubscribe		Yes	Yes
List		Yes	Yes
LSUB		Yes	Yes
Status		Yes	Yes
Append		Yes	Yes		Yes
Check			Yes				likely
Close			Yes	Yes	Yes		Must not	Yes
Expunge			Yes		Yes		Must	Yes
Search			Yes				Must not	Yes	Yes
Fetch			Yes				Must not	Yes	Yes
Store			Yes				Must not	Yes	Yes
Copy			Yes	Yes			likely	Yes	Yes
UID			Yes				likely	Yes
Access Control List commands (RFC2086)
SetACL		Yes	Yes		Yes
DeleteACL		Yes	Yes		Yes
GetACL		Yes	Yes
ListRights		Yes	Yes
MyRights		Yes	Yes
Namespace commands (RFC2342)
Namespace		Yes	Yes
Mailbox Referral commands (RFC2193)
RList		Yes	Yes
RLSUB		Yes	Yes
Quota commands (RFC2087)
SetQuota		Yes	Yes
GetQuota		Yes	Yes
GetQuotaRoot		Yes	Yes