WDIFF

draft-wener-lemonade-clearidle-00.txt --> draft-wener-lemonade-clearidle-01.txt

<<draft-wener-lemonade-clearidle-01.txt>>
Internet Draft: IMAP Extension for CLEARIDLE M. Wener
Document: draft-wener-lemonade-clearidle-00.txt draft-wener-lemonade-clearidle-01.txt Nokia, Inc.
Expires: March May 2005 October December 2004

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 CHECKPOINT extension [CHECKPOINT] MUST be supported if CLEARIDLE
is supported. The dictates of this extension only apply while an
IDLE CHECKPOINT session is active.

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.

Two new name attributes are defined:

\Deleted

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.

\Renamed
The mailbox has been renamed. A second LIST response MUST
immediately follow indicating the new name.

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
\Deleted
\NonExistent name attribute.

Example:
S: * LIST (\Deleted) (\NonExistent) "/" ~/NewFolder

3) If a folder is renamed two a LIST responses are response is sent. The first
indicating response
will contain both the old name and a \Renamed attribute and a second
response MUST immediately follow the first indicating the new name. The \Renamed attribute old name is very similar to
in the \Deleted attribute.
The reason place of the \Deleted attribute folder name in a normal LIST response. The
new name is not used communicated via a referral URL. All attribute
information is to allow the
client two distinct processing paths. One same for a delete both old and another
for a rename. It is likely that in the case of a delete new name folders. If
any attributes do change they should be communicated via a more
thorough removal of normal
LIST response using the folder would occur. new name.

Example:
S: * LIST (\Renamed) () "/" ~/OldName
S: * LIST (\Noinferiors) "/" ~/NewName 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 (\Deleted) (\NonExistent) UID 789)

New Message Arrival
An unsolicited FETCH response with envelope, body, flag and uid
data MUST be sent on all IDLE connections.

Example:
S: * 1 FETCH (UID 34 FLAGS (\Recent) ENVELOPE (...) BODY (...))

2.3 EXISTS STATUS Response

The EXISTS 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 a folder.

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 server.

LIST Response
RECENT Response
EXISTS
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 ")" [SP seqnumpart] CRLF
;See [CHECKPOINT] for "seqnumpart" definition

Example:
S: * 8 FETCH (FLAGS (\Seen) UID 789) (imap://mail/inbox/;UID=789)

The following BNF is used for mailbox specific responses: 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

mbxresponse

list-data = "RECENT" / "EXISTS"

mbxres-nocrlf = "*" "LIST" SP number mbxresponse
;See mailbox-list [SP "REFERRAL" SP mbxurl] CRLF
; See [IMAP4] for "number" definition mailbox-list

Example:
S: * LIST () "/" ~/OldName REFERRAL (imap://mail/newname)

The following BNF is used for mailbox specific responses:

d2response = mbxres-nocrlf SP "(" mbxurl ")" status-nocrlf [SP seqnumpart] CRLF
;See [CHECKPOINT] for "seqnumpart" definition

status-nocrlf = "STATUS" SP mailbox SP
"(" status-att2 *(SP status-att2) ")"

status-att2 = "MESSAGES" / "RECENT"

Example:
S: * 22 EXISTS (imap://mail/inbox) 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.

RECENT Response
EXISTS

STATUS Response
FETCH Response
EXPUNGE Response

4 Author

Michael J. Wener
Enterprise Mobility Systems
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

[CHECKPOINT] Wener, M., draft-wener-imapext-checkpoint-00.txt draft-wener-imapext-checkpoint-00

[LISTEXT] Leiba, B., Melnikov, A., IMAP4 LIST Command Extensions
draft-ietf-imapext-list-extensions-10

----