<MONOINCUID> July 2005
Lemonade
Internet Draft: MONOINCUID S. H. Maes
Document: draft-maes-lemonade-monoincuid-01 R. Cromwell
(Editors)
Expires: January 2006 July 2005
Monotonically increasing IMAP UID
Status of this Memo
This document is an Internet-Draft and is subject to all provisions
of Section 10 of RFC2026. By submitting this Internet-Draft, each
author represents that any applicable patent or other IPR claims of
which he or she is aware have been or will be disclosed, and any of
which he or she becomes aware will be disclosed, in accordance with
Section 6 of BCP 79.
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
MONOINCUID defines an extension to the IMAPv4 Rev1 protocol [RFC3501]
for optimization in a mobile setting, aimed at delivering extended
functionality for mobile devices with limited resources. To reduce
client complexity, the IMAP UID in a server compliant to MONOINCUID
are fixed and monotonically increasing.
Conventions used in this document
In examples, "C:" and "S:" indicate lines sent by the client and
server respectively.
Maes Expires û January 2006 [Page 1]
<MONOINCUID> July 2005
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119].
An implementation is not compliant if it fails to satisfy one or more
of the MUST or REQUIRED level requirements for the protocol(s) it
implements. An implementation that satisfies all the MUST or REQUIRED
level and all the SHOULD level requirements for a protocol is said to
be "unconditionally compliant" to that protocol; one that satisfies
all the MUST level requirements but not all the SHOULD level
requirements is said to be "conditionally compliant." When
describing the general syntax, some definitions are omitted as they
are defined in [RFC3501].
Table of Contents
Status of this Memo...............................................1
Abstract..........................................................1
Conventions used in this document.................................1
Table of Contents.................................................2
1. Introduction...................................................2
2. Revisions to IMAPv4 Rev1 Behavior..............................2
2.1. UID.......................................................3
3. The CAPABILITY Command.........................................3
Security Considerations...........................................4
References........................................................4
Future Work.......................................................4
Version History...................................................4
Acknowledgments...................................................5
Authors Addresses.................................................5
Intellectual Property Statement...................................7
Full Copyright Statement..........................................7
1. Introduction
The Push-IMAP protocol (P-IMAP) is based on IMAPv4 Rev1 [RFC3501],
but contains additional enhancements for simplification of the
client. This is achieved by imposing that IMAP UID in a server
compliant to MONOINCUID are monotonically increasing. This enables a
certain class of very constrained mobile devices to efficiently
download new messages provided that they are not interested in
synchronizing dynamic message attributes or expunged messages.
2. Revisions to IMAPv4 Rev1 Behavior
The section describes the differences between how an IMAPv4 Rev1
server vs. a server compliant to MONOINCUID.
Maes Expires û January 2006 [Page 2]
<MONOINCUID> July 2005
A compliant server must implement all the commands in IMAPv4 Rev1,
with these revisions. The IMAPv4Rev1 syntax on commands and
responses are found in sections 6 and 7 in [RFC3501].
2.1. UID
As specified in RFC 3501, section 2.3.1.1, "The unique identifier of
a message MUST NOT change during the session, and SHOULD NOT change
between sessions." Changing the UID of email messages imposes a
heavy computational and bandwidth burden on resource constrained
mobile clients. For a server compliant to MONOINCUID, the UID MUST
always monotonically increase. When all of the message UIDs in a
mailbox have the monotonic property, an OK [MONOINCUID] status
response code will be reported during SELECT and EXAMINE commands.
The server MAY renumber and assign new UIDs to every message in a
folder, but as long as it restores the monotonic property and issues
a new UIDVALIDITY, it may continue to report MONOINCUID in status
responses codes. If the server needs to violate the monotonic
property between sessions, it can drop the MONOINCUID status
response, and clients will therefore have to fallback on more
expensive synchronization. Clients MUST NOT cache MONOINCUID status
between sessions, whenever a folder is SELECTed or EXAMINEd, the
client MUST use the currently reported MONOINCUID status. If the
UIDVALIDITY is different than the previously recorded value, the
client cannot use the MONOINCUID status unless it has performed a
full resynchronization.
Examples:
A1 SELECT INBOX
* 100 EXISTS
* 0 RECENT
* OK [UIDVALIDITY 1] UID validity status
* FLAGS (\Seen \Deleted \Answered \Flagged \Draft)
* OK [PERMANENTFLAGS ()] Permanent flags
* OK [UNSEEN 3] 3 is first unseen
* OK [MONOINCUID] UIDs monotonically increase
A1 OK [READ-WRITE] SELECT completed
A2 STATUS INBOX (MONOINCUID UIDVALIDITY)
* STATUS ôINBOXö (MONOINCUID 1 UIDVALIDITY 1)
A2 STATUS Completed
3. The CAPABILITY Command
The CAPABILITY command is defined in RFC3501, section 6.1.1. The
client sends a CAPABILITY command so it can query the server to find
out what commands it supports. In RFC3501, the IMAP server is
Maes Expires û January 2006 [Page 3]
<MONOINCUID> July 2005
allowed to specify additional capabilities not included in that
specification. A server that supports MONOINCUID conforms to that
requirement, and MUST list that it supports MONOINCUID.
A server can also enumerate individually the other commands that it
supports.
capability_cmd = tag SP "CAPABILITY"
Valid States: NOT AUTHENTICATED, AUTHENTICATED, SELECTED, or LOGOUT
Responses: REQUIRED untagged response: CAPABILITY
Result: OK - capability completed
BAD - command unknown or arguments invalid
Example: A P-IMAP server that implements MONOINCUID.
C: a001 CAPABILITY
S: * CAPABILITY IMAP4rev1 AUTH=LOGIN IDLE MONOINCUID
S: a001 OK CAPABILITY completed
Security Considerations
MONOINCUID does not introduce additional security consideration with
respect to IMAPv4Rev1.
References
[RFC2119] Brader, S. "Keywords for use in RFCs to Indicate
Requirement Levels", RFC 2119, March 1997.
http://www.ietf.org/rfc/rfc2119
[RFC3501] Crispin, M. "IMAP4, Internet Message Access Protocol
Version 4 rev1", RFC 3501, March 2003.
http://www.ietf.org/rfc/rfc3501
Future Work
TBD
Version History
Release 01
Updates to address comments received from Sun and from Alexey
Melnikov.
Release 00
Initial release published in June 2005
Maes Expires û January 2006 [Page 4]
<MONOINCUID> July 2005
Acknowledgments
The authors want to thank all who have contributed key insight and
extensively reviewed and discussed the concepts of MONOINCUID and its
early introduction in P-IMAP [P-IMAP].
The following contributed to the authoring of MONOINCUID.
Authors Addresses
Stephane H. Maes
Oracle Corporation
500 Oracle Parkway
M/S 4op634
Redwood Shores, CA 94065
USA
Phone: +1-650-607-6296
Email: stephane.maes@oracle.com
Rafiul Ahad
Oracle Corporation
500 Oracle Parkway
Redwood Shores, CA 94065
USA
Eugene Chiu
Oracle Corporation
500 Oracle Parkway
Redwood Shores, CA 94065
USA
Ray Cromwell
Oracle Corporation
500 Oracle Parkway
Redwood Shores, CA 94065
USA
Jia-der Day
Oracle Corporation
500 Oracle Parkway
Redwood Shores, CA 94065
USA
Vida Ha
Oracle Corporation
500 Oracle Parkway
Redwood Shores, CA 94065
USA
Maes Expires û January 2006 [Page 5]
<MONOINCUID> July 2005
Wook-Hyun Jeong
Samsung Electronics,CO., LTD
416, Maetan-3dong, Yeongtong-gu,
Suwon-city, Gyeonggi-do,
Korea 442-600
Tel: +82-31-279-8289
E-mail: wh75.jeong@samsung.com
Chang Kuang
Oracle Corporation
500 Oracle Parkway
Redwood Shores, CA 94065
USA
Rodrigo Lima
Oracle Corporation
500 Oracle Parkway
Redwood Shores, CA 94065
USA
Gustaf Rosell
Sony Ericsson
P.O. Box 64
SE-164 94 Kista,
Sweden
Tel: +46 8 508 780 00
Jean Sini
Symbol Technologies
6480 Via Del Oro
San Jose, CA 95119
USA
Sung-Mu Son
LG Electronics
Mobile Communication Technology Research Lab.
Tel: +82-31-450-1910
E-Mail: sungmus@lge.com
Fan Xiaohui
Product Development Division
R&D CENTER
CHINA MOBILE COMMUNICATIONS CORPORATION (CMCC)
ADD: 53A, Xibianmennei Ave.,Xuanwu District,
Beijing,100053
China
TEL:+86 10 66006688 EXT 3137
Maes Expires û January 2006 [Page 6]
<MONOINCUID> July 2005
Zhao Lijun
CMCC R&D
ADD: 53A, Xibianmennei Ave.,Xuanwu District,
Beijing,100053
China
TEL:.8610.66006688.3041
Dwayne Bennett
Consilient
P.O. Box 2172
St. John's, NL A1C 6E6
Canada
Tel: +1 709 576 1706
E-mail: bennett@consilient.com
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
intellectual property 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; neither does it represent that it
has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication 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 implementors or users of this specification can
be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive
Director.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
Full Copyright Statement
Copyright (C) The Internet Society (2005). 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.
Maes Expires û January 2006 [Page 7]
<MONOINCUID> July 2005
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.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
Maes Expires û January 2006 [Page 8]