Internet DRAFT - draft-wener-lemonade-clearidle
draft-wener-lemonade-clearidle
Internet Draft: IMAP Extension for CLEARIDLE M. Wener
Document: draft-wener-lemonade-clearidle-02.txt Nokia, Inc.
Expires: August 2005 February 2005
IMAP Extension for CLEARIDLE
Status of this Memo
By submitting this Internet-Draft, I certify that any applicable
patent or other IPR claims of which I am aware have been disclosed,
or will be disclosed, and any of which I become aware will be
disclosed, in accordance with RFC 3668.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other
documents at any time. It is inappropriate to use Internet-Drafts
as reference material or to cite them other than as "work in
progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Abstract
The IMAPRev4 specification supports unsolicited responses being sent
to a client at any time. The IDLE specification defines a way for a
client to sit in an idle connection waiting to receive these
responses. This document clarifies and extends the set of responses
that a client may receive while in the idle state. The desire is to
allow a client to predict exactly what set of unsolicited responses
it can rely on receiving when listening on an idle connection.
1. Introduction and Overview
The CLEARIDLE extension is present in any IMAP implementation that
returns "CLEARIDLE" as a supported extension in the CAPABILITY
response.
The current set of IMAP RFCs provide an unambiguous way to deliver
unsolicited responses to a client. A client may use these responses
to gain information about the current state of the mailboxes on the
server. The problem is that the set of responses a client may
receive is ambiguous. A client has no way to reliably predict that
given a certain state change on the server a response communicating
this change will be sent.
The IMAP specification allows unsolicited responses to be sent on a
client connection at any time. This extension adds predictability to
the set of responses sent by a server during an IDLE session.
Predictability is accomplished by stating what responses must be sent
as the result of a corresponding event on the server. A new extension
is used to allow servers to clearly state if this more rigorous
definition of IDLE is adhered to.
The IDLE command is a legal command in both the Authenticated and
Selected state. While in the Selected state it is intuitive that only
responses related to the selected mailbox would be returned. It is
not as clear what should be returned while in the Authenticated
state. This document clarifies this.
When a response is received while in the Authenticated state it may
be that the response alone would be ambiguous as to which mailbox
the response pertained to. When this situation occurs an IMAP URL
is appended to the response to clarify which mailbox the response
is associated with.
2. IMAP Protocol
The following set of responses are listed as the set needed for client
clarification. It is intended that this set be adequate for a client
to maintain synchronization of all information except the message body
part content.
2.1 LIST Response
Currently the LIST response occurs as the result of a LIST command.
This document modifies the syntax of a LIST response and also defines
it's occurrence as a legal unsolicited response that could be received
on IDLE connections associated with a user.
The following attribute is re-used from [LISTEXT].
\NonExistent
The mailbox has been deleted and no longer exists. After a LIST
response with this attribute is seen the server will no longer
show the named folder in any LIST commands. There MUST NOT be
any other name attributes sent along with this attribute that
may imply the mailbox currently exists.
A server MUST send a LIST response on all idle connections if one of
the following events occurs on the server:
1) If a new folder is created a LIST response is sent with all name
attributes that apply at the time of creation. The name of the
folder MUST be fully qualified.
Example:
S: * LIST (\Noinferiors) "/" ~/NewFolder
2) If a folder is deleted a LIST response is sent with only the
\NonExistent name attribute.
Example:
S: * LIST (\NonExistent) "/" ~/NewFolder
3) If a folder is renamed a LIST response is sent. The response
will contain both the old name and a new name. The old name is
in the place of the folder name in a normal LIST response. The
new name is communicated via a referral URL.
Example:
S: * LIST () "/" ~/OldName (REFERRAL imap://mail/newname)
2.2 FETCH Response
Currently the FETCH response occurs as the result of a FETCH command
or as an unsolicited response on an IDLE connection. This document
clarifies exactly what form of response should be sent when the
specified events occur on the server.
There are two forms of the FETCH response to be sent while this
extension is in play. The first is if the message flag state changes,
and the second is if a new message arrives. The response indicates
the current state of the message.
Flag State Change
An unsolicited FETCH response with flag and uid data MUST be sent
on all IDLE connections.
Example:
S: * 8 FETCH (FLAGS (\Seen) UID 789)
New Message Arrival
An unsolicited FETCH response with bodystructure, flag and uid
data MUST be sent on all IDLE connections.
Example:
S: * 1 FETCH (UID 34 FLAGS (\Recent) ENVELOPE (...)
BODYSTRUCTURE (...))
2.3 STATUS Response
The STATUS response MUST be sent on all IDLE connections if the size
of a mailbox changes. This does not include when the size decreases
due to an EXPUNGE.
2.4 EXPUNGE Response
The EXPUNGE response MUST be sent on all IDLE connections if a message
is deleted from any folder and the IDLE command was issued in the
Authenticated state. If the IDLE command was issued in the Selected
state then only expunges from the currently selected folder are sent.
3 Response Clarification
A server supporting the CLEARIDLE extension must send a well defined
set of responses depending on which state the server is in. The
client must be able to predict that it will receive specific responses
on an idle connection given a particular event on the sever.
3.1 Authenticated State
If the IDLE command is sent while in the Authenticated state then
the following unsolicited responses MUST be sent if the
corresponding event occurs on the serve for any folder.
LIST Response
STATUS Response
FETCH Response
EXPUNGE Response
Those that require disambiguation MUST contain an IMAP URL as per
section 3.1.1.
3.1.1 Mailbox Identification Syntax
While in the Authenticated state there is no way to implicitly
determine which mailbox the response applies to. While this is not a
problem for some responses such as the LIST response it does pose a
problem for responses that are mail message specific.
The URL syntax standardized [IMAP-URL] for IMAP MUST be used to
disambiguate a response when it is required. The following BNF is
used for message specific responses:
msgurl = "imap://" iserver "/" imessagepart
;See [IMAP-URL] for "iserver" definition
imessagepart = enc_mailbox [uidvalidity] iuid
;See [IMAP-URL] for "enc_mailbox" definition
iuid = "/;UID=" nz-number
;See [IMAP4] for "nz-number" definition
uidvalidity = ";UIDVALIDITY=" nz-number
;See [IMAP4] for "nz-number" definition
msgresponse = "FETCH" / "EXPUNGE"
msgres-nocrlf = "*" SP nz-number msgresponse
d1response = msgres-nocrlf SP "(" msgurl ")" CRLF
Example:
S: * 8 FETCH (FLAGS (\Seen) UID 789) (imap://mail/inbox/;UID=789)
The following BNF is used for LIST reponses. All LIST responses are
as defined in [IMAP4] except in the case of a renamed folder.
mbxurl = "imap://" iserver "/" enc_mailbox
;See [IMAP-URL] for "enc_mailbox" definition
list-data = "LIST" SP mailbox-list [SP "REFERRAL" SP mbxurl] CRLF
; See [IMAP4] for mailbox-list
Example:
S: * LIST () "/" ~/OldName REFERRAL (imap://mail/newname)
The following BNF is used for mailbox specific responses:
status-nocrlf = "STATUS" SP mailbox SP
"(" status-att2 *(SP status-att2) ")"
status-att2 = "MESSAGES" / "RECENT"
Example:
S: * STATUS INBOX (MESSAGES 231 RECENT 7)
3.2 Selected State
If the IDLE command is sent while in the Selected state then the
following unsolicited responses MUST be sent if the corresponding
event occurs on the server. All of the following responses only occur
if the response applies to teh currently selected mailbox.
STATUS Response
FETCH Response
EXPUNGE Response
LIST Response
EXISTS Response
RECENT Response
4 Author
Michael J. Wener
Nokia, Inc.
EMail: Michael.Wener@Nokia.com
5 Full Copyright Statement
Copyright (C) The Internet Society (2004). This document is
subject to the rights, licenses and restrictions contained in BCP
78, and except as set forth therein, the authors retain all their
rights.
This document and the information contained herein are provided on
an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES,
EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT
THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR
ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A
PARTICULAR PURPOSE.
6 Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed
to pertain to the implementation or use of the technology
described in this document or the extent to which any license
under such rights might or might not be available; nor does it
represent that it has made any independent effort to identify any
such rights. Information on the procedures with respect to rights
in RFC documents can be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use
of such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository
at http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention
any copyrights, patents or patent applications, or other
proprietary rights that may cover technology that may be required
to implement this standard. Please address the information to the
IETF at ietf-ipr@ietf.org."
References
[IMAP4] Crispin, M., "Internet Message Access Protocol Version
4rev1", RFC 3501, March 2003.
[IDLE] Leiba, B., "IMAP4 IDLE command", RFC 2177, June 1997.
[IMAP-URL] Newman, C., "IMAP URL Scheme", RFC 2192, September 1997
[LISTEXT] Leiba, B., Melnikov, A., IMAP4 LIST Command Extensions
draft-ietf-imapext-list-extensions-11
