As per Relevance of the word extension, we have this rfc below:
Network Working Group J.
Request for Comments: 2359 Netscape
Category: Standards Track June 1998
IMAP4 UIDPLUS
Status of this
This document specifies an Internet standards track protocol for
Internet community, and requests discussion and suggestions
improvements. Please refer to the current edition of the "
Official Protocol Standards" (STD 1) for the standardization
and status of this protocol. Distribution of this memo is unlimited
Copyright
Copyright (C) The Internet Society (1998). All Rights Reserved
IESG
The IMAP extension described here assumes a particular means of
IMAP to support disconnected operation. However, this means
supporting disconnected operation is not yet documented. Also,
are multiple theories about how best to do disconnected operation
IMAP, and as yet, there is no consensus on which one should
adopted as a standard
This document is being approved as a Proposed Standard because
does not appear to have technical flaws in itelf. However,
of this document as a Proposed Standard should not be considered
IETF endorsement of any particular means of doing
operation in IMAP
Table of
1. Abstract .............................................. 2
2. Conventions Used in this Document ..................... 2
3. Introduction and Overview ............................. 2
4. Features .............................................. 2
4.1. UID EXPUNGE Command ................................... 2
4.2. APPENDUID response code ............................... 3
4.3. COPYUID response code ................................. 4
5. Formal Syntax ......................................... 4
6. References ............................................ 4
7. Security Considerations ............................... 5
8. Author's Address ...................................... 5
9. Full Copyright Statement .............................. 6
Myers Standards Track [Page 1]
RFC 2359 IMAP4 UIDPLUS extension June 1998
1.
The UIDPLUS extension of the Internet Message Access Protocol [IMAP4]
provides a set of features intended to reduce the amount of time
resources used by some client operations. The features in
are primarily intended for disconnected-use clients
2. Conventions Used in this
In examples, "C:" and "S:" indicate lines sent by the client
server respectively
The key words "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY
in this document are to be interpreted as defined in "Key words
use in RFCs to Indicate Requirement Levels" [KEYWORDS].
3. Introduction and
The UIDPLUS extension is present in any IMAP4 server
which returns "UIDPLUS" as one of the supported capabilities to
CAPABILITY command. The UIDPLUS extension contains one
command and additional data returned with successful APPEND and
commands
Clients that wish to use the new command in UIDPLUS must of
first test for the presence of the extension by issuing a
command. Each of the features in UIDPLUS are optimizations;
can provide the same functionality, albeit more slowly, by
commands in the base protocol. With each feature, this
recommends a fallback approach to take when the UIDPLUS extension
not supported by the server
4.
4.1. UID EXPUNGE
Arguments: message
Data: untagged responses:
Result: OK - expunge
NO - expunge failure (e.g. permission denied
BAD - command unknown or arguments
Myers Standards Track [Page 2]
RFC 2359 IMAP4 UIDPLUS extension June 1998
The UID EXPUNGE command permanently removes from the
selected mailbox all messages that both have the \Deleted flag
and have a UID that is included in the specified message set.
a message either does not have the \Deleted flag set or is has
UID that is not included in the specified message set, it is
affected
This command may be used to ensure that a replayed EXPUNGE
does not remove any messages that have been marked as \
between the time that the user requested the expunge operation
the time the server processes the command
If the server does not support the UIDPLUS capability, the
should fall back to using the STORE command to temporarily
the \Deleted flag from messages it does not want to remove.
client could alternatively fall back to using the EXPUNGE command
risking the unintended removal of some messages
Example: C: A003 UID EXPUNGE 3000:3002
S: * 3
S: * 3
S: * 3
S: A003 OK UID EXPUNGE
4.2. APPENDUID response
Successful APPEND commands return an APPENDUID response code in
tagged OK response. The APPENDUID response code contains
arguments the UIDVALIDITY of the destination mailbox and the
assigned to the appended message
If the server does not support the UIDPLUS capability, the client
only discover this information by selecting the destination
and issuing FETCH commands
Example: C: A003 APPEND saved-messages (\Seen) {310}
C: Date: Mon, 7 Feb 1994 21:52:25 -0800 (PST
C: From: Fred Foobar
C: Subject: afternoon
C: To: mooch@owatagu.siam.
C: Message-Id:
C: MIME-Version: 1.0
C: Content-Type: TEXT/PLAIN; CHARSET=US-
C
C: Hello Joe, do you think we can meet at 3:30 tomorrow
C
S: A003 OK [APPENDUID 38505 3955] APPEND
Myers Standards Track [Page 3]
RFC 2359 IMAP4 UIDPLUS extension June 1998
4.3. COPYUID response
Successful COPY and UID COPY commands return a COPYUID response
in the tagged OK response whenever at least one message was copied
The COPYUID response code contains as an argument the UIDVALIDITY
the appended-to mailbox, a message set containing the UIDs of
messages copied to the destination mailbox, in the order they
copied, and a message containing the UIDs assigned to the
messages, in the order they were assigned. Neither of the
sets may contain extraneous UIDs or the symbol '*'.
If the server does not support the UIDPLUS capability, the client
only discover this information by selecting the destination
and issuing FETCH commands
Example: C: A003 COPY 2:4
S: A003 OK [COPYUID 38505 304,319:320 3956:3958]
C: A003 UID COPY 305:310
S: A003 OK
5. Formal
The following syntax specification uses the augmented Backus-
Form (BNF) notation as specified in [RFC-822] as modified by [IMAP4].
Non-terminals referenced but not defined below are as defined
[IMAP4].
Except as noted otherwise, all alphabetic characters are case
insensitive. The use of upper or lower case characters to
token strings is for editorial clarity only. Implementations
accept these strings in a case-insensitive fashion
resp_code_apnd ::= "APPENDUID" SPACE nz_number SPACE
resp_code_copy ::= "COPYUID" SPACE nz_number SPACE set SPACE
uid_expunge ::= "UID" SPACE "EXPUNGE" SPACE
6.
[IMAP4] Crispin, M., "Internet Message Access Protocol -
Version 4rev1", RFC 2060, December 1996.
[KEYWORDS] Bradner, S., "Key words for use in RFCs to
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC-822] Crocker, D., "Standard for the Format of ARPA
Text Messages", STD 11, RFC 822, August 1982.
Myers Standards Track [Page 4]
RFC 2359 IMAP4 UIDPLUS extension June 1998
7. Security
There are no known security issues with this extension
8. Author's
John Gardiner
Netscape
501 East Middlefield
Mail Stop MV-029
Mountain View, CA 94043
EMail: jgmyers@netscape.
Myers Standards Track [Page 5]
RFC 2359 IMAP4 UIDPLUS extension June 1998
9. Full Copyright
Copyright (C) The Internet Society (1998). All Rights Reserved
This document and translations of it may be copied and furnished
others, and derivative works that comment on or otherwise explain
or assist in its implementation may be prepared, copied,
and distributed, in whole or in part, without restriction of
kind, provided that the above copyright notice and this paragraph
included on all such copies and derivative works. However,
document itself may not be modified in any way, such as by
the copyright notice or references to the Internet Society or
Internet organizations, except as needed for the purpose
developing Internet standards in which case the procedures
copyrights defined in the Internet Standards process must
followed, or as required to translate it into languages other
English
The limited permissions granted above are perpetual and will not
revoked by the Internet Society or its successors or assigns
This document and the information contained herein is provided on
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED,
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE
Myers Standards Track [Page 6]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
